Finally I got to this point too. Sorry I got to learn newer things along this experiments.
The I started to think why there are three different dtf for this board. One is u-boot's rk3288-tinker.dts +rk3288-tinker.dtsi, another is kernel's rk3288-tinker.dts and the last is rk3288-miniarm. All of these concurring to do something which should make tinker board work. Less probable that would work for the added eMMC model.
So I thought there's a difference that is given by the age of every one of them. Anyway no one is good enough to give us the chance to start a kernel. I think that if the dft is good it won't make any difference to start any kernel.
I saw that at github/u-boot they just update rk3288-tinker.dtsi, few days back.
I don't know yet what exactly these dtf are doing, I'm studying them by comparison and see if the declaration are congruent.
I wrote to TB web site and I hope some volunteer will come over.
Today I tried another u-boot image, without patches because I thought the configuration is given for good. But I was wrong and it failed.
EDITI can't deny that the patches are necessary and specific for TB
S, so u-boot drive up to the kernel as expected. Furthermore, most of the patches are Mr Jamess Hung (Asus engineer).
I set up with the latest u-boot commit. I saw a little difference
- Code: Select all
U-Boot SPL 2018.09-rc2-00160-gc3c19c2743-dirty (Sep 02 2018 - 11:54:38 +0800)
Returning to boot ROM...
U-Boot 2018.09-rc2-00160-gc3c19c2743-dirty (Sep 02 2018 - 11:54:38 +0800)
DRAM: 2 GiB
PC event = 0x0
usb_current_limit_ctrl: unlock_current = 0
MMC: dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
The (fail -5) is gone and seems to find two mmc locations. But there was only eMMC during the boot. The polling for the SD card still flooding the kernel log in dmseg. It must have a SD card to calm it down.
So, the only perspective for TB S is this kind of u-boot, which can't be generalized, then remain specific for this board, as much as many other SBC.
The rest might go into device-tree file to guide the kernel in a correct manner. I feel that there's a concern in the way to handle the iommu. There's a error
- Code: Select all
[ 3.642859] rk_iommu ff930300.iommu: Failed to get clk 'aclk': -2
[ 3.643686] rk_iommu ff940300.iommu: Failed to get clk 'aclk': -2
Warning: /lib/modules/4.18.5-1-ARCH/modules.devname not found - ignoring
starting version 239
TB-MM-root: Superblock last mount time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set)
TB-MM-root: Superblock last write time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set)
TB-MM-root: clean, 96127/262144 files, 724106/1048576 blocks
[ 6.294101] rk_iommu ff930300.iommu: Error during raw reset. MMU_DTE_ADDR is not functioning
[ 6.348387] rk_iommu ff940300.iommu: Error during raw reset. MMU_DTE_ADDR is not functioning
I've also tried LXDE and it is there. Just with the plain framebuffer using mesa
