On 04/03/2011 09:09 PM, Somebody in the thread at some point said:
Hi -
Can you describe why code in the bootloader is a better place than code in the kernel early init? I mean if you go and look in say U-Boot sources, it's a lot less beautiful and elegant than kernel code.
You shouldn't just move the init code into uboot, instead you should figure out how to encode the hardware specific information into the device tree using a generic schema. Then have code in the kernel that knows how to interpret this generic data.
Sounds good.
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.
The way things are set up currently I also don't believe you can remove all board specific code from the kernel. The goal with device trees is to start hacking away at the board specific code and make the piles of it smaller. In the future we may be able to remove it all like on the PC platform.
Sure.
-Andy