Device-tree improvements

[TheSaint]

$this->bbcode_second_pass_quote('summers', 'T')hing is the devnum is I think only used in uboot.

[summers]

Looks to me like uboot sees the eMMC, but linux only sees the sd card anot not the eMMC. This is what you would expect with a tinker board dtb, as the tinker board doesn't have an eMMC, whereas the S does. Its probably the device trees catching up with where they should be ...

You should be able to check inn the device tree that the relevant device isn't enabled ....

[TheSaint]

Just for tinkering. Results with rk3288-tinkerS.dtb$this->bbcode_second_pass_code('', '$ ls /proc/device-tree/dwmm*
/proc/device-tree/dwmmc@ff0c0000:
broken-cd card-detect-delay disable-wp name reset-names vqmmc-supply
bus-width clock-names fifo-depth pinctrl-0 resets
cap-mmc-highspeed clocks interrupts pinctrl-names status
cap-sd-highspeed compatible max-frequency reg vmmc-supply

/proc/device-tree/dwmmc@ff0d0000:
bus-width clock-names interrupts non-removable reset-names
cap-sd-highspeed clocks keep-power-in-suspend num-slots resets
cap-sdio-irq compatible max-frequency pinctrl-0 sd-uhs-sdr104
clock-freq-min-max disable-wp mmc-pwrseq pinctrl-names status
clock-frequency fifo-depth name reg supports-sdio

/proc/device-tree/dwmmc@ff0e0000:
clock-names compatible interrupts name reset-names status
clocks fifo-depth max-frequency reg resets

/proc/device-tree/dwmmc@ff0f0000:
bus-width compatible max-frequency non-removable reg
cap-mmc-highspeed disable-wp mmc-ddr-1_8v num-slots reset-names
clock-names fifo-depth mmc-hs200-1_8v pinctrl-0 resets
clocks interrupts name pinctrl-names status

$ cat /proc/device-tree/dwmmc\@ff0d0000/status
okay
$ cat /proc/device-tree/dwmmc\@ff0c0000/status
okay')
With rk3288-tinker.dtb stock$this->bbcode_second_pass_code('', '# ls /proc/device-tree/dwmm*
/proc/device-tree/dwmmc@ff0c0000:
broken-cd clocks name resets
bus-width compatible phandle status
cap-mmc-highspeed disable-wp pinctrl-0 vmmc-supply
cap-sd-highspeed fifo-depth pinctrl-names vqmmc-supply
card-detect-delay interrupts reg
clock-names max-frequency reset-names

/proc/device-tree/dwmmc@ff0d0000:
clock-names fifo-depth name reset-names
clocks interrupts phandle resets
compatible max-frequency reg status

/proc/device-tree/dwmmc@ff0e0000:
clock-names fifo-depth name reset-names
clocks interrupts phandle resets
compatible max-frequency reg status

/proc/device-tree/dwmmc@ff0f0000:
clock-names fifo-depth name reset-names
clocks interrupts phandle resets
compatible max-frequency reg status

# cat /proc/device-tree/dwmmc\@ff0d0000/status
disabled
# cat /proc/device-tree/dwmmc\@ff0c0000/status
okay')
As you wrote, the second one is disabled. So the relevant part in the dtf is missing

My curiosity asks how to automatically detect the difference between the two boards ? Will it be possible ?
For example there is a u-boot command which makes a test$this->bbcode_second_pass_code('', 'itest.b ${devnum} == 0 && echo "U-boot loaded from SD"
itest.b ${devnum} == 1 && echo "U-boot loaded from eMMC"')
Extracted from Armbian 5.50
So if that results applicable, there could be a chance to set which statement to make eMMC available.

Anyway, it's obvious to think that the Asus engineers added the hardware without giving any input to the kernel.org regarding the variation.

[summers]

Well I'd say the dtb is correct - as designed for the tinker board which doesn't have eMMC. Suspect its just the community catching up with the tinker family.

It would be technically possible to detect the difference between tinker board and tinker board s in uboot, one of the patches on a previous thread showed where the difference is in flash. This is what is done in the beagle familly - so uboot automatically selects the right dtb on beagle boards.

Now is it worth doing the same on tinker boards? Needs someone to write the code, and send a patch into uboot.

Oh yes, in the bit of the device tree for the relevent device, you can check the status file to see if that device is enabled.

I think it would be hard to get a patch into mainline uboot to print that sd or eMMC card is used - problem is that uboot doesn't see any difference between the two devices, they are just sdio devices - so both the same ...

I think the ASUS engineers did the patches just for their debian distribution. As it was their own patches were automatically accepted. With the mainline kernel you can't do that, e.g. I'm on to something like the 5th version of the wifi patch, and for good reason. The ASUS engineers didn't want that hassle ....

With the devnum, am not sure - but are they predictable, or does it depend on thing like how and if the interface comes up? {e.g. it would be possible for the sd card to be devnum 0 on the TB, but the eMMC to be devnum 0 on the TBS ...)

[TheSaint]

$this->bbcode_second_pass_quote('summers', 'd')oes it depend on thing like how and if the interface comes up? {e.g. it would be possible for the sd card to be devnum 0 on the TB, but the eMMC to be devnum 0 on the TBS ...)

[summers]

One of the debian patches from ASUS showed that the TB and TBS can be distinguished through a setting in flash. So if uboot need to make a distinction between the two, then reading the flash would be the way to do it.

Practically though the way that the distro part of uboot is configured, is that the board definition in uboot specifies which partitions/devices to scan, its usually MMC + USB + a few others. Distro scans the first (maybe few) partitions of each device looking for boot.scr /boot/bot.scr and a few other things - where this is found IIRC it takes that location (by default - you can override) as containing the kernel/dtb/initrd etc.

After that the kernel makes all decisions.

Now should TB and TBS have the same dtb. To my mind the simple answer is that the DTB is 90% describing hardware, and how boards are wired up. Now the TB and TBS are different, the TBS has an eMMC chip wired into the SDIO emmc connection of the CPU. That difference needs to be described, so to my mind yes its necessary for there to be separate dtb - and thats how the kernel plays it as well. This said though its recognised these two are 95% the same, its why both are based on an rk3288-tinker.dtsi file.

dtb selection to my mind should be 100% dependent on the board you are using, in conjunction with what other boards you have plugged in. Plug in boards I think ideally should be done with overlays. In the context of your board, I'd say your TBS should use a TBS dtb, possibly with your own hand designed overlays - as I know you want to use the IO pins for specific purposes.

Then again I'm an opinionated old goat, and what are my thoughts worth ...

[TheSaint]

As per your descriptions I do convene that you're entirely right.
Then I hope that upstream will whip up some good solution.

[TheSaint]

Today I tried the newest kernel, but the dtb is not changed. I get dropped on the initrd.
I'm looking to set up an RTC, see this. Just consider that I switched to Alarm instead fo Armbian.
Can I input the data by the u-boot variable environment ?
Or should I add something like that, on the device-tree file ?

[summers]

The tinker-s.dtb is due to arrive in 4.20 so we have to wait. It should support the emmc, but its known it won't do the WiFi. I need to get back to the WiFi - its quite a bit to mainline.

[summers]

Oh yes, the rtc needs a change to the device tree. Best to either write an overlay or in uboot create the new node ...