On 06/07/2011 04:02 PM, David VomLehn wrote:
On Sun, Jun 05, 2011 at 11:41:10PM -0500, Grant Likely wrote:
On Sun, Jun 5, 2011 at 7:07 PM, Ralf Baechle<ralf@xxxxxxxxxxxxxx> wrote:
Over the past few days I've started to convert arch/mips to use DT.
Nice!
So
far none of the platforms (except maybe PowerTV?) seems to have a
firmware that is passing a DT nor is there any 2nd stage bootloader that
could do so.
FWIW, U-Boot now has pretty generic support for manipulating and
passing a dtb at boot. That doesn't do much good for existing
deployed systems though.
I took a look at the issue of passing device trees to the kernel and started
by surveying the methods currently in use for passing information from the
bootloader to the kernel. I came up with the ten approaches:
How MIPS Bootloaders Pass Information to the Kernel
---------------------------------------------------
Apologies for any errors; this was meant more to be a quick survey
rather than a detailed analysis.
[...]
5. a0 - unused
a1 - unused
a2 - unused
Boot descriptor in a3.
Platforms: cavium-octeon
I have augmented the boot descriptor with a field that contains the
*physical* address of the DTB.
[...]
10. a0 - argc
a1 - argv
a2 - unused
a3 - memory size
The command line is assumed to already be a single string, pointed
to by argv.
Platforms: powertv
It seems like everything ultimately does create a command line. We could then
use a parameter like "devtree=<virtual-address>" on the command line, passed
in any way the bootloader likes.
Some u-boots for non-mips platforms pass it in the environment of the
bootm protocol.
I would say to pass the pointer to the DTB in the environment, but not
all platforms (like powertv) have an environment. So I guess the
command line has to do.
Also I think we should pass the physical address of the DTB, not the
virtual address. It would be the kernel's responsibility to figure out
what the virtual address is.
David Daney
In this case, the<virtual-address> will be
a kseg0 address so we don't have to set up any mappings. If we allow multiple
device trees to be built in or appended to the end of the kernel, we can use
the existing "dtb_compat" command line parameter to select which one to use.
I would propose that "devtree" take precedence over "dtb_compat", but that's
really just a desire to pick one over the other, whichever is the preferred
one.