Device-tree improvements

[summers]

env import is how arch used to do uboot, and its still used on some architectures such as nsa325.

I think I prefer boot.src, even though it has to be compiled every time, you can do commands far more easily with a script. With environment variables, you can still do I think everything, but it becomes with iterative variables that call each other. Thats far more confusing.

E.g. on my nsa325 look at how I had to modify the device tree:
$this->bbcode_second_pass_code('', 'loadfdt=echo loading ${fdtdir}/${fdtfile} ...; load ${devtype} ${bootpart} ${fdtaddr} ${fdtdir}/${fdtfile}; fdt addr ${fdtaddr}; fdt set /mbus@f1000000/nand@12f chip-delay <45>')
So first you have to discover that the boot command runs loadfdt at some stage, and then need to modify that variable, to do what you want. That to me is less clear that the boot.src script ...

[summers]

Oh yes - on bluetooth, worth saying that : https://github.com/torvalds/linux/blob/master/drivers/bluetooth/btrtl.c indicates that firmware is loaded:
$this->bbcode_second_pass_code('', 'rtl_bt/rtl8723bs_fw.bin
rtl_bt/rtl8723bs_config')
Guess its worth checking if armbian etc have these files, my guess is in /lib/firmware ...

[TheSaint]

I asked to the Armbian staff.
The USB quirks are for some of their interest regarding to fix a HD detection, within their settings. Whilst for the bluetooth there is some change on the kernel configuration.
Actually I'd say that the system works pretty good, the issues are lesser

[summers]

Yes the HCI UART 3wire (thats the hci_h5 code) is what I'll modify to be auto loaded by the device tree. Its not clear if btrtl needs to be loaded or not, but I'm assuming that hci_h5 takes care of that ...

[TheSaint]

Latest experiment gave some head scratching
I tried to understand whether the newest rk3288-tinker.dtb is good enough to use. So I started manually u-boot and passed the parameters. Everything gone fine upto to switch initramfs into the rootfs. It isn't able to find the root partition
So rk3288-tinkerS.dtb still have that little extra to get me the system going
What is that ?

[summers]

When you say latest rk3288-tinker.dtb which one do you mean?

rk3288-tinker-s.dtb will come out with kernel 4.20. It should do eMMC but won't do wifi/bluetooth - that still needs work.

An official rk3288-tinker.dtb won't support the eMMC, just the sd card, as the Asus tinker board just has an sd slot ...

[TheSaint]

$this->bbcode_second_pass_quote('summers', 'W')hen you say latest rk3288-tinker.dtb which one do you mean?

[summers]

Oh yes, in the initrd you should have enough commands to see why the root file system wasn't loaded. My guess it it couldn't find the PARTUUID. Probably because it could only see the sd card and not the eMMC.

[TheSaint]

$this->bbcode_second_pass_quote('summers', 'P')robably because it could only see the sd card and not the eMMC.

[summers]

Thing is the devnum is I think only used in uboot. eg the distro set up only scans certain devices for boot.scr. Now you got as far as the initrd. That says that you managed to find the kernel, and the initrd, and almost certainly the dtb. So the uboot bit seemed to work fine.

So question is what went wrong in the kernel. Now the initrd, when it can't mount root, drops you into a minimal busybox shell - which is enough to see whats up on the system. E.g. you can check the device tree in /proc/device-tree; and check which sd/emmc cards have been detected in dmesg. So you have enough to probe what went wrong, and that brings understanding.