On 04/04/2011 12:12 PM, Somebody in the thread at some point said:
Hi -
Specifically: the bootloader prerequisites for accessing the DT data may entirely mandate private bootloader knowledge of ALL the information it would have required from DT. For example, bootloader must init SDRAM, knowing the size and start address and memory types, must init the storage device, must contain a stack for accessing data on the storage device to even get at the DT information stored in files on the storage device... what's actually left to do for the bootloader using the DT information? It could go straight to getting the kernel from the same storage and boot that with internal DT tables and leave the bootloader blissfully unaware of DT info at no cost in terms of increasing the hardcoded knowledge in the bootloader.
Bootloaders don't need use the DTs
Alright.
but they need to provide the DTs to OS.
It "can" provide a DT to the OS, it does not need to do it in the same sense that the bootloader truly needs to set up SDRAM to bring in Linux at all. You may chose to have it do it but that's slightly different.
Given the complexity and configurability of OMAP ROM, which has an MMC stack and FAT parser built-in, it's even within sight there will be NO bootloader, you just stick a header on your kernel image which is only data interpreted by the ROM that tells it how to set up SDRAM and so on, and tells it the length of the following kernel image to pull in. In this case, the kernel would take care of business itself.
This get implements in lots of different ways. In bootloaders
I worked on we wrote custom code in the bootloader to initialize everything. This code knew nothing of the DT. I wrote the DTs to match the specific hardware. They were compiled and merged into the bootloader binary. The bootloader didn't know how to read them, it just knew how to pass them onto the OS. But other bootloader implementations do this differently. Some of those implementations (open firmware) actually build the DTs on the fly. It's your choice on how the DT gets created.
The DT is just supposed to be a generic description of the hardware that is provided to the OS so that the OS will know what hardware is there when that hardware can't be probed.
So in this MX31 case did your 2K of code directly boot the kernel or was it a two stage boot process? If it is two stage the second stage should load the DT and pass it to the kernel. If it is booting direct to the kernel then the kernel will need the DT image built into it.
It was two-stage but in one binary; the first 2K of the bootloader had these critical bits placed there by linker script. It sets up SDRAM and pulls the whole of the same bootloader image into SDRAM and runs that. The post-2K part has useful things like VFAT and ext2+ parsers that enable getting ahold of the kernel image in a reasonable way via filesystem.
The point about it was to establish the understanding that we cannot eliminate the considerable amount of required hardcoded magic from the bootloader by usage of DT, and it follows there is no requirement for DT parser in a minimal bootloader, it seems we reached agreement about that.
The two stage boot process is the more general solution. What happens when we get 6,000 variants of hardware like we have we PCs? It is unreasonable for the kernel to load 6,000 different device trees and select one. Instead you want the bootloader to provide the DT and then the kernel just interprets it. If you don't do this then something like Ubuntu can't ship generic kernels. What if Ubuntu has shipped their kernel before your hardware is released? It can't possibly have the DT for your hardware built into it.
Well, I see 134 defconfigs in arch/arm/configs, but it's reasonable to take it to an extreme to see if it scales.
You are right as it stands bloating the kernel with 6K discrete DTBs with nothing in common won't fly. However if you look at arch/arm there is a great deal of platform-level commonality to be found there. At least, no less commonality and presumably much more should be possible between the device trees, eg, the overo / beagle case should be sharing 90%+ of their tree one way or another, same with panda / sdp4430 and so on. Eg, for identical boards adding another should boil down to pointing to the already-introduced parent and just setting a new name field.
I don't know much about DT but I assume that reflects the source of it that you basically do like #include "omap4430.devtree" and meddle with adding the unique bits of your board, and it's not the case there is a massive panda.devtree or whatever that has all omap4430 asset details copied in there for every board.
-Andy