Hi Stephen, On 25 November 2014 at 09:23, Stephen Warren <swar...@wwwdotorg.org> wrote: > On 11/24/2014 04:49 PM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 24 November 2014 at 10:11, Stephen Warren <swar...@wwwdotorg.org> >> wrote: >>> >>> On 11/23/2014 09:12 AM, Simon Glass wrote: >>>> >>>> >>>> Modern kernels require a device tree to boot. >>> >>> >>> >>> True. >>> >>>> Enable FIT support to permit >>>> >>>> booting these images, rather than just legacy images. >>> >>> >>> >>> I don't understand this? Modern kernels boot perfectly well without FIT >>> support. U-Boot supports the kernel's standard separate DTB and zImage >>> file >>> formats just fine. >>> >>> To be honest, I'd strongly prefer not to enable support for non-universal >>> (bootloader-specific) formats such as FIT. >> >> >> In U-Boot? FIT is U-Boot's standard format > > > That's rather my point: FIT is *U-Boot's* standard format, not a global > standard format. > > I want to strongly guide anyone using Tegra towards globally standard > formats, not intimate that they should be using bootloader-specific formats. > > zImage (without appended DTB) is a standard Linux format that all > booatloaders should support. > > Raw DTB in a separate file (or perhaps provided by earlier firmware directly > in RAM/ROM) is a standard Linux format that all bootloaders should support. > > extlinux.conf is something that all bootloaders should support. > > Linux distros that install binaries or config files in those standard > formats should expect them to work with any bootloader, on any board. This > way, distros won't have to write explicit support for any board; they'll > just install standard files and everything will just work anywhere. >
Just so I am clear, on ARM what is the list of bootloaders that you are concerned with? FIT is actually not a difficult thing to add to a boot loader. Presumably they all support libfdt, so it is just a case of plumbing in the FIT access stuff. I'm really not keen on this lowest-common-denominator approach, it's just a sad situation. Also I don't see why extlinux.conf should preclude people using FIT if they want to. >> and avoids all the mess that is zImage with a single attached DTB, etc. > > Yes, we should avoid appended DTB where possible. However, there's no need > to use appended DTB even when not using FIT; just put the zImage and DTB in > separate files. To load them, either use a simple extlinux.conf config file, > or a set of U-Boot commands to load each file; see > https://github.com/NVIDIA/tegra-uboot-scripts for something that'll > generates some examples. > > Example /boot/extlinux.conf (for media-based booting) or > pxelinux.cfg/default (for network booting via syslinux command): > > TIMEOUT 100 > > MENU TITLE TFTP boot options > > LABEL jetson-tk1-emmc > MENU LABEL ../zImage root on Jetson TK1 eMMC > LINUX ../zImage > FDTDIR ../ > APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw > earlyprintk root=/dev/mmcblk0p1 > #root=UUID=8eac677f-8ea8-4270-8479-d5ddbb797450 > > LABEL sdcard > MENU LABEL ../zImage, root on 2GB sdcard > LINUX ../zImage > FDTDIR ../ > APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw > earlyprintk root=PARTUUID=b2f82cda-2535-4779-b467-094a210fbae7 > > LABEL venice2-emmc > MENU LABEL ../zImage root on Venice2 eMMC > LINUX ../zImage > FDTDIR ../ > APPEND console=ttyS0,115200n8 console=tty1 loglevel=8 rootwait rw > earlyprintk root=PARTUUID=5f71e06f-be08-48ed-b1ef-ee4800cc860f > ... Sounds good. I guess if the zImage were an image.fit then this would still work on U-Boot. We could even enable verified boot! How does U-Boot select which device tree to pass to the kernel with the scheme above? We shouldn't rely on the user, right? With FIT we use CONFIG_FIT_BEST_MATCH. > >>>> This allows booting of Chrome OS kernels, among other things. >>> >>> >>> >>> This might be a reasonable justification to support FIT. However, it'd be >>> best to enable FIT support only on boards that are actually supported by >>> ChromeOS, so as not to pollute other boards' configuration. >> >> >> I feel that FIT is a pretty core feature for U-Boot. Are you worried >> about the space? > > > I'm worried about guiding people towards non-standard file formats and > protocols that lock people into a particular boot-loader. > > For use-cases where it makes sense, I think it's fine to enable FIT. As a > general feature across all boards, I would strongly prefer not to. One > use-case that makes sense might be to boot ChromeOS. Of course, that's only > applicable to boards that ChromeOS (or ChromiumOS) supports, and hence FIT > should only be enabled in those boards' config files, not globally. Without it we wouldn't be able to boot a kernel. Still I don't see why enabling the feature is going to break anything. It's like bike owners wanting to ban cars. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
