Re: [U-Boot] [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages

[Grant Likely <grant.likely@secretlab.ca>]

Hi Peter,

On Wed, Dec 30, 2009 at 6:10 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> On Wed, 2009-12-30 at 17:01 -0700, Grant Likely wrote:
>> On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
>> > Hi Grant,
>> > I put U-Boot ML on CC.
>>
>> Thinking further, I do actually have another concern, at least with
>> regard to the way the current patch set implements things. =A0Is it
>> expected or even "recommended" that fit images will *always* contain a
>> .dtb image? =A0The current patch only handles the case of a .dtb
>> embedded inside the fit image.
>
> I'm not aware of any recommendations as far as what FIT images should
> contain and there isn't a requirement that it should contain a .dtb
> image - its just a flexible image format.
>
> I believe in the most common FIT usage scenario the image would contain
> both a kernel image and .dtb file though. =A0For example, most people I
> deal with just have boardX and boardY that they want to boot Linux on.
>
> Currently they have to make a "legacy" uImage, manually run the device
> tree compiler with the proper flags to generate a board-specific .dtb
> file,

... or put the .dts files into arch/powerpc/boot/dts and use 'make <board>.=
dtb'

multiple <board>.dtb targets can also be added to CONFIG_EXTRA_TARGETS
so that a plain 'make' will build all needed files.

> transfer the uImage to to boardX, transfer the .dtb file to
> boardX, set some U-Boot variables, then boot to Linux. =A0For boardY they
> would have to redo the steps with the exception of recreating the legacy
> uImage. =A0(To add to the confusion, the format of device trees is a
> somewhat moving target, so .dtb files aren't always compatible with
> different kernel versions.)

The are no guarantees that new dtb files will work with old kernels,
but old dtb files should continue to work with new kernels.  There
have been growing pains in this regard, and there are a number of
examples where this hasn't been the case especially as we were
learning how best to use the device tree.  It is a lot more stable now
than it had been and new cases can be considered a kernel bug.

>> Personally, I don't get any benefit out of the new image format, so I
>> haven't spent any time looking at it. =A0However, I'm concerned about
>> the drift back towards a different image per target when the move over
>> the last 4 years has been towards multiplatform kernel images. =A0I
>> certainly don't want to encourage embedding the device tree blob into
>> the kernel image, and I'm not very interested in merging code to do
>> that into the kernel tree. =A0If someone really needs to do that for
>> their particular target, it is certainly easy enough for them to weld
>> in the .dtb after the fact before transferring the image to the
>> target, but I want that mode to be the exception, not the rule.
>
> I see your point. =A0The main goal of the patch was to introduce FIT imag=
e
> support as its the new, more flexible, "better", standard image format
> for U-Boot going forward. =A0Also, lots people aren't aware of FIT images
> and the cool stuff they can do with them, so what better way to get the
> word out than getting support for FIT images included in the kernel
> proper:)

Define 'better'.  :-)

I do understand your use-case and what problem fit images solve for
you.  However, from a "long term strategy" point of view it is a use
case that I'm not interested in actively supporting for two reasons.
The first is that I think it is in our best interest to encourage the
mind set that the hardware description is separate from the operating
system image, and so they should be stored and updated separately.  I
look at the unexpected ecosystem of distributions that has sprung up
around wireless routers (ie OpenWRT and the like) and Linux cell
phones (ie. Cyanogen Mod) where there is a huge range of hardware.
The userspace can pretty much run on any of them excepting minor
configuration changes.  The embedded space is becoming more PCs in
this regard, and I know that multiplatform is a big deal for some of
the users.  I'm not interested in encouraging any behaviour that will
scuttle deployment of multiplatform kernels.  (That being said, I'm
not going to actively sabotage people who want to put dtb sections
into the kernel images either.  I understand that at times it is
necessary, and there are numerous examples of this already in the
kernel tree; specifically to support firmware that doesn't implement
arch/powerpc's boot interface)

The second is that I no longer think it is a good idea to be building
bootloader specific image fomats if we can help it.  U-Boot is not the
only game bootloaders, especially when talking about ARM or MIPS, and
some folks are even using kexec to go from one kernel to the next.
Having the same image format for all firmware and also kexec is far
more interesting to me than the a new u-boot format.  Some form of
zImage seems to be a more likely format to standardize around than the
FIT format, mostly because kexec and a lot of firmware already
understand zImages, and it doesn't require firmware to link in libfdt.

> I think it would be nice to generate a FIT image that contained the
> kernel + .dtb as it significantly simplifies the process of booting
> Linux for the common case for lots of U-Boot users and showcases one of
> the benefits of the FIT format. =A0If you'd prefer not to have this
> portion of the patch included, I can respin so that the FIT image
> created only contains a kernel image, not a .dtb or initramfs. =A0Or I
> could make targets of fitImage (no dtb included), fitImage.<board> (dtb
> included), and fitImage.initrd.<board> (dtb and initramfs included).
> Either way is fine with me, it'd just be nice to see FIT support get in
> in some form.

I'd be okay (perhaps not happy, but okay) with merging fitImage and
fitImage.initrd targets (no dtb).  I will resist merging fitImage.%
and fitImage.initrd.% targets because I see that very much as a
project specific deployment target and I'm not convinced yet that it
the pattern is right or that it is even needed in the kernel at all.

Cheers,
g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.