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

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

[Curt Brune]

Hello,

I am following up on this thread:
"Merging device trees at runtime for module-based systems"
http://lists.denx.de/pipermail/u-boot/2012-November/139618.html

I do not have a modular based system, so I do not need the full 
flexibility of merging DT fragments at runtime.  However, I am very 
interested in being able to select a full DT from a list of DT's at 
runtime.  I believe this is a degenerate case of the more general N x M 
modular case.

The background:  I have a number of different platforms running u-boot. 
  They all use the same Linux kernel and initramfs, but different DT.

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.

The uImage would contain a list of dtb's and u-boot would select the 
correct one at runtime.  u-boot could iterate through the list 
inspecting the "model" property of the  root node.

Thoughts on that approach?

Cheers,
Curt

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

[Stephen Warren]

On 01/07/2013 11:01 AM, Curt Brune wrote:
> Hello,
> 
> I am following up on this thread:
> "Merging device trees at runtime for module-based systems"
> http://lists.denx.de/pipermail/u-boot/2012-November/139618.html
> 
> I do not have a modular based system, so I do not need the full
> flexibility of merging DT fragments at runtime.  However, I am very
> interested in being able to select a full DT from a list of DT's at
> runtime.  I believe this is a degenerate case of the more general N x M
> modular case.
> 
> The background:  I have a number of different platforms running u-boot.
>  They all use the same Linux kernel and initramfs, but different DT.
> 
> 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.
> 
> The uImage would contain a list of dtb's and u-boot would select the
> correct one at runtime.  u-boot could iterate through the list
> inspecting the "model" property of the  root node.

For this scenario, why not just put each DTB file into the file-system
under a separate name, and use U-Boot's board variable to select the
correct one at run-time, e.g.:

ext2load ${devtype} ${devnum}:${rootpart} ${kernel_addr_r} /boot/zImage
ext2load ${devtype} ${devnum}:${rootpart} ${fdt_addr_r} \
	/boot/${soc}-${board}.dtb
bootz ${kernel_addr_r} - ${fdt_addr_r}

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

[Curt Brune]

On 01/07/2013 10:36 AM, Stephen Warren wrote:
> On 01/07/2013 11:01 AM, Curt Brune wrote:
>> Hello,
>>
>> I am following up on this thread:
>> "Merging device trees at runtime for module-based systems"
>> http://lists.denx.de/pipermail/u-boot/2012-November/139618.html
>>
>> I do not have a modular based system, so I do not need the full
>> flexibility of merging DT fragments at runtime.  However, I am very
>> interested in being able to select a full DT from a list of DT's at
>> runtime.  I believe this is a degenerate case of the more general N x M
>> modular case.
>>
>> The background:  I have a number of different platforms running u-boot.
>>   They all use the same Linux kernel and initramfs, but different DT.
>>
>> 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.
>>
>> The uImage would contain a list of dtb's and u-boot would select the
>> correct one at runtime.  u-boot could iterate through the list
>> inspecting the "model" property of the  root node.
>
> For this scenario, why not just put each DTB file into the file-system
> under a separate name, and use U-Boot's board variable to select the
> correct one at run-time, e.g.:
>
> ext2load ${devtype} ${devnum}:${rootpart} ${kernel_addr_r} /boot/zImage
> ext2load ${devtype} ${devnum}:${rootpart} ${fdt_addr_r} \
> 	/boot/${soc}-${board}.dtb
> bootz ${kernel_addr_r} - ${fdt_addr_r}
>

That is a good idea, except for one small wrinkle I forgot to include in 
the use case -- the platforms I am using arrive from the vendors with 
u-boot installed and nothing else.  All I can count on is a u-boot in 
the NOR flash and an uninitialized mass storage device.

The uImage with all the dtb's I'm thinking of is an installer that would 
provision the mass storage device and bootstrap our software.  After 
that step I could use your idea for subsequent boots.

I would like all my vendors to adopt a u-boot feature whereby I can use 
a single installer uImage without defining how the mass storage device 
should be partitioned.

Cheers,
Curt

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

[Wolfgang Denk]

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

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Anyone who isn't confused here doesn't really know what's going on.

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

[Curt Brune]

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.

Cheers,
Curt

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

[Simon Glass]

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.

>
> Cheers,
> Curt
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

[Stephen Warren]

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!

As a general comment here, I think the main issue Curt is facing is how
to select the correct DT in U-Boot. Whether the n DTBs to be selected
between are stored in a single FIT file, or stored in separate *.dtb
files, seems pretty irrelevant to that core problem of how to select
between them.

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

[Simon Glass]

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";
}

>
> As a general comment here, I think the main issue Curt is facing is how
> to select the correct DT in U-Boot. Whether the n DTBs to be selected
> between are stored in a single FIT file, or stored in separate *.dtb
> files, seems pretty irrelevant to that core problem of how to select
> between them.

FIT selects between them already if you know the model - define
CONFIG_FIT_BEST_MATCH and it should work.

Regards,
Simon

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

[Stephen Warren]

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.

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

[Simon Glass]

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.

So the snow device tree has something like:

{
	compatible = "google,snow", "google,daisy", "samsung,smdk5250",
		   "samsung,exynos5250";
...
};

and we put a similar string in the kernel FDTs. U-Boot then picks up
the correct FDT based on preference (google,snow is the best,
google,daisy the next best...)

FITs don't have filenames, although I suppose you are free to add any
properties you want. To my mind, a compatible name is more device-tree
friendly than introducing filenames to specify this info. We already
have things like nvidia,seaboard and the like, so that should be good
enough.

As you know FIT images do have a 'configurations' section, so you can
do things like:

images {
   kernel at 1 {
      ...
   };
   fdt at 1 {
      incbin ...      (binary contains: compatible = "google,snow";)
   };
   fdt at 2 {
      incbin ...      (binary contains: compatible = "google,flax";)
   };
};
configurations {
   conf at 1 {
      kernel = "kernel at 1";
      fdt = "fdt at 1";
   };
   conf at 2 {
      kernel = "kernel at 1";
      fdt = "fdt at 2";
   };
   ...
};

At present it looks at the compatible property in each of the fdt@
nodes and compares it against the compatible string in  U-Boot.

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.

Perhaps for your use case what is missing is a bootm command to
specify a compatible string to search for (rather than pulling it out
of the control FDT). But for Tegra at least, the current approach
should work OK.

I quite like the idea of detected an FDT compatible string from the
board where auto-detection is required, because then there is only one
concept of what a board is and only one way of describing it. Also, it
is ultimately the compatible string which selects which FDT we pass to
the kernel, and the kernel understands the compatible strings too.

I happen to be fiddling with the FIT code at present and am working on
a series to tidy up the code a bit and introduce sandbox support so we
can test it more easily.

Regards,
Simon

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

[Stephen Warren]

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

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

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

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

[Curt Brune]

On 01/08/2013 02:37 PM, Stephen Warren wrote:
> 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...

For my case the hardware vendor makes the u-boot not me.  Since I now 
know about FIT images my one FIT image will support many vendors.

Any one vendor won't be too keen to put other vendors' dtb's on their 
board by default.  Also there's no way they could know a priori what 
other vendors my software would support.

Putting a bunch of dtb's in a file is great for me.

-Curt