Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Device trees as ABI -- flag the stable ones
Posted Jul 31, 2013 15:10 UTC (Wed) by etienne (subscriber, #25256)
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.
Posted Jul 31, 2013 15:26 UTC (Wed) by rvfh (subscriber, #31018)
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.
Posted Jul 31, 2013 16:33 UTC (Wed) by etienne (subscriber, #25256)
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.
Posted Aug 2, 2013 8:58 UTC (Fri) by rvfh (subscriber, #31018)
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/...
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds