Device trees as ABI -- flag the stable ones

Posted Jul 31, 2013 15:10 UTC (Wed) by etienne (guest, #25256)
In reply to: Device trees as ABI -- flag the stable ones by rvfh
Parent article: Device trees as ABI

So you assume that there is only one Hard Disk with one /boot partition (with a known partition scheme and known filesystem) and containing one DT with a discoverable name.
In the PC world, people would say: try everything you can think of to find that DT, and yes by specification a hard disk can take 31 seconds to appear - the process might take time.
In embedded world, people would say: the list of non-volatile memory devices is not known, define it in the DT; the priority of those devices is not known, in the DT; the partition scheme (MBR, GPT, BSD disk slices,...) is not known, in the DT; the filesystem of /boot is not known, in the DT; the filename of the DT is not known, write it in the DT...

Remember that if something is wrong on a PC, you can always count on the BIOS to get to the point you can fix things - not so on an ARM embedded board.

Also, if a new device (new name) appears and is 100% compatible with an old one, you have to modify the DT to add a "compatible = "new_device_name";" line - so you have to be able to update the DT.

Device trees as ABI -- flag the stable ones

Posted Jul 31, 2013 15:26 UTC (Wed) by rvfh (guest, #31018) [Link] (2 responses)

> So you assume that there is only one Hard Disk with one /boot partition (with a known partition scheme and known filesystem) and containing one DT with a discoverable name.

On a PC the bootloader knows where to load the kernel and initrd from. If it needs a DT then all it needs is store that info too. And yes the BIOS does the init before the kernel re-discovers everything (but I am sure you know all that!)

> In the PC world, people would say: try everything you can think of to find that DT, and yes by specification a hard disk can take 31 seconds to appear - the process might take time.

See reply below, if I understand what you are saying correctly...

> In embedded world, people would say: the list of non-volatile memory devices is not known, define it in the DT; the priority of those devices is not known, in the DT; the partition scheme (MBR, GPT, BSD disk slices,...) is not known, in the DT; the filesystem of /boot is not known, in the DT; the filename of the DT is not known, write it in the DT...

And again the bootloader is what knows where the DT is, so it can
- use it
- pass it to the kernel

> Remember that if something is wrong on a PC, you can always count on the BIOS to get to the point you can fix things - not so on an ARM embedded board.

I don't understand this fully... The BIOS is a pre-bootloader program as you find in the ROM code of your SoC, no?

> Also, if a new device (new name) appears and is 100% compatible with an old one, you have to modify the DT to add a "compatible = "new_device_name";" line - so you have to be able to update the DT.

I don't understand that, sorry. How can a new device 'appear'? Embedded systems tend not to evolve, which I think is the definition of embedded, compare to a PC to which you can change/add/remove core components such as CPU/GPU/memory/storage...

Sorry if I am missing your point, which I am sure is valid.

Device trees as ABI -- flag the stable ones

Posted Jul 31, 2013 16:33 UTC (Wed) by etienne (guest, #25256) [Link] (1 responses)

> > Remember that if something is wrong on a PC, you can always count on the BIOS to get to the point you can fix things - not so on an ARM embedded board.
>
> I don't understand this fully... The BIOS is a pre-bootloader program as you find in the ROM code of your SoC, no?

On that SOC, you have a very small ROM which can do DHCP/TFTP boot when the FLASH is blank, but that is a recovery system only.
A standard boot (i.e. cold reset vector) brings you to U-boot without any other layer, U-boot has to initialise itself the external DDR ram; you have no other software whatsoever.
If you are using the new NOR FLASH (bigger size for lower price), only the first few sectors of that FLASH are present in the address space; you also need to have a driver to read the other sectors.

So U-boot runs in a very restricted environment, and cannot access the DT which is stored in FLASH before initialising both DDR ram and FLASH.
So the constants to initialise the DDR ram and the FLASH are not really needed in the DT.
Once U-boot can access DDR ram and FLASH, it has basically finished its job and just loads two files in memory (linux kernel and DT) without looking at their content.

> I don't understand that, sorry. How can a new device 'appear'?

I was more talking of a DT on a PC, but even on embedded you have chips upgraded during production without software change, or external USB connectors where newer devices can be connected and not auto-probed.
In short you cannot store the DT in real ROM, you may have to update it.

> Sorry if I am missing your point, which I am sure is valid.

For instance, in the PC world the PCI interface is at well-known I/O address 0xCF8; that is compiled as a constant into every ia32/amd64 Linux kernel. There is no point to write that address into a DT located on a hard disk because the hard disk cannot be discovered before the PCI address.
In the embedded world there is no well-know addresses, but there is no place to store such a database neither.

Device trees as ABI -- flag the stable ones

Posted Aug 2, 2013 8:58 UTC (Fri) by rvfh (guest, #31018) [Link]

> Once U-boot can access DDR ram and FLASH, it has basically finished its job and just loads two files in memory (linux kernel and DT) without looking at their content.

OK. On TI OMAPs we have U-Boot/SPL initialising the DDR ans SD card, so U-Boot is directly loaded into it (and the DT could be too.) To some extent, this means the DT info is partly duplicated into U-Boot/SPL.

> In the embedded world there is no well-know addresses, but there is no place to store such a database neither.

Yes, and anyway, there is not necessary a way to determine the board type (and thus choose the correct DT), so the board type is likely hard-coded into the boot loader.

But that's OK to me: it's the SoC case. It remains IMO that in the PC case a DT can be in the /boot partition because we can get there thanks to BIOS/standards/...