From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 20 May 2015 08:04:45 -0600 Subject: [U-Boot] [PATCH 20/20] tegra: config: nyan-big: Add options required by Chrome OS boot In-Reply-To: References: <1424212195-7501-1-git-send-email-sjg@chromium.org> <1424212195-7501-21-git-send-email-sjg@chromium.org> <54EE5B66.7040003@wwwdotorg.org> <5556121B.4060502@wwwdotorg.org> <555B59B5.3070308@wwwdotorg.org> Message-ID: <555C947D.6060709@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 05/20/2015 07:40 AM, Simon Glass wrote: > Hi Peter, > > On 20 May 2015 at 04:21, Peter Robinson wrote: >> Hi Simon, >> >>>>> I wonder what would be involved in adjusting config_distro_bootcmd to >>>>> support FIT? >>>> >>>> >>>> Well, it goes against the very idea of config_distro_bootcmd, which is to >>>> provide a single standard mechanism that doesn't rely on any >>>> bootloader-specific file formats etc. That mechanism is a raw zImage, a raw >>>> initrd, and a plain text extlinux.cfg file to specify things like file >>>> paths/names, command-line, etc. >>>> >>>> The boot.scr support there is legacy, and not something that should be built >>>> upon going forward. So, that's not an argument for adding support for a >>>> third mechanism! >>> >>> Do we need to adjust the mechanism? The only difference I see is that >>> FIT brings the files together. >> >> Speaking as one of the ARM maintainers that's not what we want. We >> want to be able to use the standard kernel, initrd and then a DT so we >> can boot a single image across any device that the kernel supports. >> >> In Fedora at the moment we can boot around a 100 odd devices off a >> single kernel by specifying the DT separately. I've not looked at FIT >> closely but I don't believe it provides us that. > > My comment was not to adjust the standard mechanism, but to adjust the > internal details of how U-Boot implements it such that FIT could be > supported. I reviewed the U-Boot config_distro implementation at the > time - I was careful to confirm that the mechanism itself was defined > separately from U-Boot's implementation. > > From my understanding we could package the bzImage kernel and all the Nit: On ARM there's an Image (I think that's the uncompressed kernel build output) and a zImage (that is the compressed kernel build output). bzImage is x86-specific. > DTs/ramdisk into the FIT and make it work. This is what Chrome OS > does, for example. Actually this all came up after Stephen asked how > to make U-Boot's Chrome OS boot scripts look more like config_distro. > > It may actually be simpler for U-Boot to implement I think, since it > would be using pre-wired feature. But that needs to be looked at with > config_distro. The main thing I asked was for the ChromeOS stuff to re-use existing environment variables rather than re-inventing its own for the same purpose. I'm not sure whether there could be much more unification than that, since the model that ChromeOS and config_distro_bootcmd use to select the boot device and partition probably vary quite a bit?