From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 08 Jan 2013 15:37:27 -0700 Subject: [U-Boot] Selecting from multiple device trees at runtime In-Reply-To: References: <50EB0D92.2020707@cumulusnetworks.com> <20130107201240.52C9120DA7E@gemini.denx.de> <50EB4A4C.9050201@cumulusnetworks.com> <50EC4C79.3050806@wwwdotorg.org> <50EC5949.7030708@wwwdotorg.org> Message-ID: <50EC9FA7.60703@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 01/08/2013 10:58 AM, Simon Glass wrote: > Hi Stephen, > > On Tue, Jan 8, 2013 at 9:37 AM, Stephen Warren wrote: >> On 01/08/2013 09:51 AM, Simon Glass wrote: >>> Hi Stephen, >>> >>> On Tue, Jan 8, 2013 at 8:42 AM, Stephen Warren wrote: >>>> On 01/07/2013 08:16 PM, Simon Glass wrote: >>>>> Hi, >>>>> >>>>> On Mon, Jan 7, 2013 at 2:21 PM, Curt Brune 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...