On Mon, Apr 4, 2011 at 4:21 AM, Andy Green <a...@warmcat.com> wrote: >> Matt and I may differ a little on the responsibilities of the >> bootloader. I think it should do the bare minimum needed to get the >> kernel loaded and to feed it a device tree. Matt has it doing more >> like setting up all of the pin configurations. But I don't have a >> strong opinion on this. > > Well, in the iMX31 case there is only a 2KByte SRAM on-die that gets > auto-filled by the ROM. In the case of SD Card boot which I implemented - > the bootloader is on the SD Card at a defined place - it means you need to > fit your SD init, "mmc stack" and mmc host driver inside the 2KBytes so it > can load the rest of the bootloader. > > That works fine but it will never be implementable with DT in bootloader. I > don't mean it as a problem for DT I mean that it seems we all need to maybe > challenge our assumptions a bit in the face of this new stuff being > introduced. Matt is assuming the bootloader will consume DT data, if it > does do so it will only ever need a small fraction of it and doing so at all > is optional, since no bootloader does it today. > > 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, but they need to provide the DTs to OS. 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. 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. -- Jon Smirl jonsm...@gmail.com _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
