On Mon, 4 Apr 2011, Andy Green wrote: > 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.
I don't think it is a general assumption that any bootloaders woule become users of DT. If anything, DT used to be _created_ by the bootloader not the reverse. If a bootloader is generic enough at runtime to require DT data to function, it is not a bootloader anymore but an OS. Nicolas _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
