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

[Simon Glass]

Hi Stephen,

On 25 November 2014 at 09:23, Stephen Warren <swarren at 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 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.
>

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