[U-Boot] Selecting from multiple device trees at runtime

[Stephen Warren <swarren@wwwdotorg.org>]

On 01/08/2013 10:58 AM, Simon Glass wrote:
> Hi Stephen,
> 
> On Tue, Jan 8, 2013 at 9:37 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 01/08/2013 09:51 AM, Simon Glass wrote:
>>> Hi Stephen,
>>>
>>> On Tue, Jan 8, 2013 at 8:42 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> On 01/07/2013 08:16 PM, Simon Glass wrote:
>>>>> Hi,
>>>>>
>>>>> On Mon, Jan 7, 2013 at 2:21 PM, Curt Brune <curt@cumulusnetworks.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 01/07/2013 12:12 PM, Wolfgang Denk wrote:
>>>>>>>
>>>>>>> Dear Curt Brune,
>>>>>>>
>>>>>>> In message <50EB0D92.2020707@cumulusnetworks.com> you wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> What I would love is to have a single multi-file uImage I could use on
>>>>>>>> all my platforms.  The idea is to introduce a new image type that is a
>>>>>>>> list of device tree blobs.
>>>>>>>
>>>>>>>
>>>>>>> In addition to the file system based approach suggested by Stephen,
>>>>>>> you should have a look into using FIT images (see doc/uImage.FIT/ ).
>>>>>>> One of the reasons for creating these was to deal with situations
>>>>>>> exactly as you describe...
>>>>>>
>>>>>>
>>>>>> I think that will work perfectly.  Thank you for the suggestion.
>>>>>
>>>>> Note also there is code in mainline now to select the correct FDT from
>>>>> a list of them in a FIT. based on the model name. Then it can pass
>>>>> this to the kernel. So if you have a way of getting the model name in
>>>>> U-Boot, it might just work.
>>>>
>>>> Hmmm. What's the model name compared against? U-Boot board name variable
>>>> would be nice!
>>>
>>> At the moment it compares against the model in the U-Boot FDT
>>> (CONFIG_OF_CONTROL). When flashing a board, you pack u-boot.bin with
>>> the selected .dtb file containing this model name. Then when U-Boot
>>> runs it knows what its model is.
>>>
>>> You could do what you describe, but it is then a compile-time check, I think.
>>>
>>> There could be other ways to decide on the model name, such as looking
>>> at strapping GPIOs, for example:
>>>
>>> static const char *detect_model(void)
>>> {
>>>     if (gpio_get_value(36))
>>>         return "snow";
>>>     else
>>>         return "flax";
>>> }
>>
>> Right - I believe the TI guys introduced the board_name variable or
>> similar to indicate the runtime-detected board ID for this purpose
>> (whereas the board variable I introduced is the board U-Boot was
>> compiled for). It'd be nice to be able to select a DTB from FIT based on
>> $board_name instead of U-Boot's own DTB's model given all this. Do the
>> sub-images in the FIT image have filenames that could be selected as
>> e.g. ${soc}-${board}.dtb? Using $board or $board_name would also help
>> where U-Boot doesn't use a DT itself.

> Actually I had this a bit wrong - it's actually the compatible strings
> that are compared - the model is just a friendly name of course. So we
> use compatible = "nvidia,seaboard", etc.

Ah right, compatible does sound better indeed.

...
> It would be easy enough to add a feature to look up an FDT based on an
> environment variable, but keep in mind that the bootm command already
> mostly supports this. You can specify the configuration name to bootm
> and it will boot with that configuration. We need to make sure we
> don't create too many ways to do the same thing. In other words,
> people can probably script this today if they want to.

The one thing I worry about his is that it isn't clear that every single
U-Boot port is going to use device tree to configure U-Boot (as opposed
to the other feature of being able to pass a DT to the kernel). As such,
U-Boot isn't always going to have knowledge of what compatible value it
should be looking for; hard-coding a specific FTB filename, or
generating one using $board or $board_name is much more in line with
what various boot scripts already do, so if you're looking for a single
generic solution, I'm not convinced that DT compatible value is it,
although admittedly it does sound nice.

Besides, it seems that storing a bunch of *.dtb in /boot is far easier
than screwing around with FIT images, which just seem like a hopeless
mess to me; why put a filesystem inside a file when there's already a
/boot filesystem that you could use...