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@1 { ... }; fdt@1 { incbin ... (binary contains: compatible = "google,snow";) }; fdt@2 { incbin ... (binary contains: compatible = "google,flax";) }; }; configurations { conf@1 { kernel = "kernel@1"; fdt = "fdt@1"; }; conf@2 { kernel = "kernel@1"; fdt = "fdt@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