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

[Simon Glass]

Hi Stephen,

On Tue, Jan 8, 2013 at 2:37 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 01/08/2013 10:58 AM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Tue, Jan 8, 2013 at 9:37 AM, Stephen Warren <swarren at 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 at 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 at cumulusnetworks.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 01/07/2013 12:12 PM, Wolfgang Denk wrote:
>>>>>>>>
>>>>>>>> Dear Curt Brune,
>>>>>>>>
>>>>>>>> In message <50EB0D92.2020707 at 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.

I'm not sure what to do about that. Every ARM board is going to end up
with a kernel FDT at some point but it isn't clear how many will move
to CONFIG_OF_CONTROL.

I suppose we could have a $compatible in addition, for those boards
that dont't? It isn't possible in general to derive it. One day it
might make sense to enumerate the FDTs in the boards.cfg file, but not
yet.

>
> 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...

Certainly it's not for everyone. I'm not sure of all the reasons, but some are:

1. It's a self-contained image that can be built, packaged and
delivered as a single file (like a zImage but better IMhO)
2. It doesn't require an FS in U-Boot (e.g. you may be using raw flash)
3. It has built-in support for configurations, images, compression,
ramdisk, FDT, etc.
4. It can be hashed/verified easily (see my verified FIT series
http://patchwork.ozlabs.org/bundle/sjg/vboot/)

Regards,
Simon