[U-Boot] [PATCH v3 3/4] tegra: config: Enable FIT and device tree for all boards

[Stephen Warren]

On 11/24/2014 04:49 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 24 November 2014 at 10:11, Stephen Warren <swarren at 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.