| Message ID | 1416759162-25445-3-git-send-email-sjg@chromium.org |
|---|---|
| State | Superseded |
| Delegated to: | Tom Warren |
| Headers | show |
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. > 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.
Hi Stephen, On 24 November 2014 at 10:11, Stephen Warren <swarren@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 and avoids all the mess that is zImage with a single attached DTB, etc. > >> 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? Regards, Simon
On 11/24/2014 04:49 PM, Simon Glass wrote: > Hi Stephen, > > On 24 November 2014 at 10:11, Stephen Warren <swarren@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. > 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 ... >>> 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.
Hi Stephen, On 25 November 2014 at 09:23, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 11/24/2014 04:49 PM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 24 November 2014 at 10:11, Stephen Warren <swarren@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
On 11/25/2014 10:44 AM, Simon Glass wrote: > Hi Stephen, > > On 25 November 2014 at 09:23, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 11/24/2014 04:49 PM, Simon Glass wrote: >>> >>> Hi Stephen, >>> >>> On 24 November 2014 at 10:11, Stephen Warren <swarren@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 believe that Barebox supports extlinux.conf too. > 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. It doesn't. My point is that it's unlikely people will want FIT support except in certain specific cases (such as ChromeOS compatibility), and we shouldn't enable it except where there's a demonstrable use-case, so we don't confuse people with non-standard options and accidentally lead them down the wrong path. ... >> Example /boot/extlinux.conf (for media-based booting) or >> pxelinux.cfg/default (for network booting via syslinux command): ... > 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. extlinux.conf can specify a particular DTB filename if it wants. Alternatively, it can specify a directory containing a set of DTBs, and the bootloader must select which DTB to load. If $fdtfile is set in U-Boot's environment, that file is used. Otherwise, the U-Boot syslinux code uses some other environment variables to calculate a default DTB filename; ${soc}-${board}.dtb.
Hi Stephen, On 1 December 2014 at 11:41, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 11/25/2014 10:44 AM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 25 November 2014 at 09:23, Stephen Warren <swarren@wwwdotorg.org> >> wrote: >>> >>> On 11/24/2014 04:49 PM, Simon Glass wrote: >>>> >>>> >>>> Hi Stephen, >>>> >>>> On 24 November 2014 at 10:11, Stephen Warren <swarren@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 believe that Barebox supports extlinux.conf too. OK so I wonder if this problem would go away if Barebox supported FIT. I haven't played with Barebox but could perhaps take a look. > >> 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. > > > It doesn't. My point is that it's unlikely people will want FIT support > except in certain specific cases (such as ChromeOS compatibility), and we > shouldn't enable it except where there's a demonstrable use-case, so we > don't confuse people with non-standard options and accidentally lead them > down the wrong path. My use case is to have one or more kernels, lots of device trees and be able to boot on any arch. I think that is the same for you, but in your case you rely on a filesystem to provide a large number of FDTs. This means that we can't provide a kernel release as a single file, nor can we support verified boot. With FIT we can support these. > > ... >>> >>> Example /boot/extlinux.conf (for media-based booting) or >>> pxelinux.cfg/default (for network booting via syslinux command): > > ... >> >> 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. > > > extlinux.conf can specify a particular DTB filename if it wants. > Alternatively, it can specify a directory containing a set of DTBs, and the > bootloader must select which DTB to load. > > If $fdtfile is set in U-Boot's environment, that file is used. > > Otherwise, the U-Boot syslinux code uses some other environment variables to > calculate a default DTB filename; ${soc}-${board}.dtb. OK I remember your patches now, sounds good. Let me know if there is some other blocker (besides Barebox) to supporting FIT more widely for kernel + device tree distribution. Regards, Simon
diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index 5d2b12a..c8c2366 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -162,6 +162,9 @@ #define CONFIG_BOUNCE_BUFFER #define CONFIG_CRC32_VERIFY +#define CONFIG_FIT +#define CONFIG_OF_LIBFDT + #ifndef CONFIG_SPL_BUILD #include <config_distro_defaults.h> #endif
Modern kernels require a device tree to boot. Enable FIT support to permit booting these images, rather than just legacy images. This allows booting of Chrome OS kernels, among other things. Signed-off-by: Simon Glass <sjg@chromium.org> --- Changes in v3: - Add new patch to enable FIT support for Tegra boards Changes in v2: None include/configs/tegra-common.h | 3 +++ 1 file changed, 3 insertions(+)