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
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
