Re: Converting MIPS to Device Tree

[David Daney <ddaney@caviumnetworks.com>]

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@linux-mips.org>  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.