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

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

[Peter Tyser]

Hi Grant,
I put U-Boot ML on CC.

On Wed, 2009-12-30 at 16:02 -0700, Grant Likely wrote:
> On Mon, Dec 21, 2009 at 6:50 PM, Peter Tyser <ptyser@xes-inc.com> wrote:
> > The PowerPC architecture has the ability to embed the ramdisk located
> > at arch/powerpc/boot/ramdisk.image.gz into a bootable kernel image.  If
> > the bootable kernel is in the Flattened Image Tree (FIT) format, the
> > ramdisk should be a node in the tree instead of being embedded directly
> > in the kernel executable.
> >
> > A FIT uImage with a ram filesystem can be generated using the command:
> > "make uImage.fit.initrd.<boardname>" where <boardname> is one of
> > arch/powerpc/boot/dts/<boardname>.dts.  The command will generate a FIT
> > uImage at arch/powerpc/boot/uImage.fit.initrd.<boardname> that contains
> > a kernel image, device tree blob, and a ram filesystem.
> >
> > The ramdisk at arch/powerpc/boot/ramdisk.image.gz can either be an older
> > style "ramdisk" or a newer "ramfs" gzipped cpio archive.
> >
> > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > ---
> > Changes since v1:
> > - Don't strip leading 0x from dts ramdisk address
> >
> >  arch/powerpc/boot/Makefile |    3 +++
> >  arch/powerpc/boot/wrapper  |   20 ++++++++++++++++----
> >  scripts/mkits.sh           |   34 ++++++++++++++++++++++++++++++++--
> >  3 files changed, 51 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> > index e56ec21..c2a6591 100644
> > --- a/arch/powerpc/boot/Makefile
> > +++ b/arch/powerpc/boot/Makefile
> > @@ -313,6 +313,9 @@ $(obj)/uImage: vmlinux $(wrapperbits)
> >  $(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> >        $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
> >
> > +$(obj)/uImage.fit.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
> > +       $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
> > +
> 
> IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
> Makefile so that make behaves more consistently.

Makes sense.

> Speaking of which,
> the number of '.' in the name is getting rather large.  Would you
> consider using 'fitImage' instead of 'uImage.fit'?

Sure, I don't have a strong opinion about the name.  I settled on
uImage.fit because all the U-Boot documentation describes the FIT images
as type of uImage.  Eg the readme is located in doc/uImage.fit, its
referred to as the "new uImage" format, etc.  So using the
"uimage.fit.*" name goes along with the concept that a FIT image is a
type of uImage.  A target like fitImage loses the uImage<->FIT
connection.

But I do agree that "."s are a bit overwhelming.  I could rework these
patches with your suggested fitImage target name and follow-up with
U-Boot patches to clear up its documentation.  In my opinion, there's
not much reason to keep the uImage<->FIT connection that currently
exists in U-Boot.  Right now U-Boot documents the "Legacy uImage" and
"FIT uImage" format when logically it would make sense to rename the
formats to "uImage" and "FIT" as there isn't much in common between the
2 formats.  The FIT image is just a blob generated by the device tree
compiler, its not tied to U-Boot in any way.

Does anyone in the U-Boot community have an opinion about this?  I'm
fine with keeping the uImage.fit naming or using fitImage for this
patch, but I think U-Boot's documentation should be on the same page
either way.

Thanks for the review,
Peter

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

[Grant Likely]

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.  Is it
expected or even "recommended" that fit images will *always* contain a
.dtb image?  The current patch only handles the case of a .dtb
embedded inside the fit image.

Personally, I don't get any benefit out of the new image format, so I
haven't spent any time looking at it.  However, 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.  I
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.  If 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.

g.

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

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

[Peter Tyser]

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.  Is it
> expected or even "recommended" that fit images will *always* contain a
> .dtb image?  The 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.  For 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, transfer the uImage to to boardX, transfer the .dtb file to
boardX, set some U-Boot variables, then boot to Linux.  For boardY they
would have to redo the steps with the exception of recreating the legacy
uImage.  (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 FIT+.dtb patches I sent make it so the same process is shortened to:
make a FIT image for boardX which contains a .dtb, download it to
boardX, and boot it.  Then repeat the same steps for boardY.

> Personally, I don't get any benefit out of the new image format, so I
> haven't spent any time looking at it.  However, 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.  I
> 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.  If 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.  The main goal of the patch was to introduce FIT image
support as its the new, more flexible, "better", standard image format
for U-Boot going forward.  Also, 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:)

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.  If 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.  Or 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.

Thanks,
Peter

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

[Grant Likely]

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. ?Is it
>> expected or even "recommended" that fit images will *always* contain a
>> .dtb image? ?The 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. ?For 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. ?For boardY they
> would have to redo the steps with the exception of recreating the legacy
> uImage. ?(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. ?However, 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. ?I
>> 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. ?If 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. ?The main goal of the patch was to introduce FIT image
> support as its the new, more flexible, "better", standard image format
> for U-Boot going forward. ?Also, 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. ?If 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. ?Or 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.

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

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

[Wolfgang Denk]

Dear Grant Likely,

In message <fa686aa41001022108i92596d6qdf2da0e24c34767e@mail.gmail.com> you wrote:
> 
> > 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.

Note that the FIT image can also be made to contain a number of DT
blobs, and selection of a "board profile" then can be used to boot the
very sane FIT image file on any of the supported boards - so FIT
images inherently support multibooting.

> > I see your point.  The main goal of the patch was to introduce FIT image
> > support as its the new, more flexible, "better", standard image format
> > for U-Boot going forward.  Also, 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'.  :-)

FIT images are better than the old uImage format because they:

- allow for strong checksum algorithms like MD5, SHA1, ... (the plain
  CRC32 method is not good enough if you for example want to run
  software in a slot machine in Las Vegas).

- can combine multiple kernel images, device tree blobs and root file
  system images in arbitrary combinations; this allows for example
  for multibooting the same image on different boards by selecting
  the right DTB, for software updates with automatic fall-back, etc.

- can be extended to add new features, images types or whatever in a
  standard way, using a standard technology (device tree support)
  which is already present anyway, i. e. without additional code
  overhead.

> 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

How do you boot systems over network, then? Normally you always
download only a single image file.

How do you explain this to system vendors? They have a very reasonable
request to offer only one image file to their customers.

> 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

Right. So let's be able to provide kernel images that fit intot he
same pattern - that can be used on a range of platforms, for example
by embedding multiple DTBs.

Requesting that we manage a kernel mage plus a collection of DTBs and
that eveybody has to install the only working correctly combination
seems to be a bad idea to me.

> 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

You misunderstand. FIT images do not scuttle multiplatform kernels.
Instead they support this much better, as they allow to bundle the
repsective DTBs into one image file.

> 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)

Even if the boot loader supports it, it is usually pretty benefical
(especially during development) if you can do this.

> 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.

Is this just your personal opinion, or do you think that this is
really what a majority of kernel developers and users are wanting?

Speaking for myself, I have to admit that I don't understand and don't
share this attitude.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The optimum committee has no members.
                                                   - Norman Augustine

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

[Peter Tyser]

<snip>

> Note that the FIT image can also be made to contain a number of DT
> blobs, and selection of a "board profile" then can be used to boot the
> very sane FIT image file on any of the supported boards - so FIT
> images inherently support multibooting.

I agree with Wolfgang.  Additionally, if a FIT image does contain a .dtb 
file, firmware can ignore it and load a different .dtb file.  So for the 
fitImage.<boardname> target you could think of it as including a 
"default/fallback" .dtb file, not a mandatory one.  So the FIT image 
could still be used as a multiplatform image even if it contained dtbs.

>>> I see your point.  The main goal of the patch was to introduce FIT image
>>> support as its the new, more flexible, "better", standard image format
>>> for U-Boot going forward.  Also, 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'.  :-)
>
> FIT images are better than the old uImage format because they:
>
> - allow for strong checksum algorithms like MD5, SHA1, ... (the plain
>    CRC32 method is not good enough if you for example want to run
>    software in a slot machine in Las Vegas).
>
> - can combine multiple kernel images, device tree blobs and root file
>    system images in arbitrary combinations; this allows for example
>    for multibooting the same image on different boards by selecting
>    the right DTB, for software updates with automatic fall-back, etc.
>
> - can be extended to add new features, images types or whatever in a
>    standard way, using a standard technology (device tree support)
>    which is already present anyway, i. e. without additional code
>    overhead.

Other advantages of FIT images that I see day-to-day include:
- Adding meta-data such as timestamps and version information for each 
component of the FIT image.  Its great to be able to easily display the 
contents of a FIT image to determine which kernel versions it contains, etc.

- Embed multiple OS/dtb images in one FIT image.  As a board vendor its 
nice to give a customer 1 image that has example dtb(s) and Linux, 
VxWorks, QNX, diagnostic, etc kernels.  They can boot a number of OSes 
on a number of different boards with 1 image.

- You can extract the images contained in a FIT image using 'dtc' to 
convert the FIT image to a ".dts" file that has the raw image contents. 
  Other image formats are more difficult to extract contents from.

<snip>

>> 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.
>
> Is this just your personal opinion, or do you think that this is
> really what a majority of kernel developers and users are wanting?
>
> Speaking for myself, I have to admit that I don't understand and don't
> share this attitude.

I agree with Wolfgang that many people would find the combined 
kernel/dtb/ramfs useful, but understand Grant's reservations.  Assuming 
I rework the patch to include a "fitImage" (no dtb) target, for the 
users that basic multiplatform images are important to, they could build 
this kernel-only FIT image.  For people such as Wolfgang, Peter, and 
myself who would like to bundle a kernel + dtb(s), we could use the 
fitImage.<boardname> target.  Wouldn't both parties be happy then?  I 
could make the FIT documentation explain the benefits of multiplatform 
images or warn about the combined kernel/dtb FIT images if that made a 
difference too.

Best,
Peter

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

[Grant Likely]

On Sun, Jan 3, 2010 at 3:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant Likely,
>
> In message <fa686aa41001022108i92596d6qdf2da0e24c34767e@mail.gmail.com> you wrote:
>
> Note that the FIT image can also be made to contain a number of DT
> blobs, and selection of a "board profile" then can be used to boot the
> very sane FIT image file on any of the supported boards - so FIT
> images inherently support multibooting.
>> > I see your point. ?The main goal of the patch was to introduce FIT image
>> > support as its the new, more flexible, "better", standard image format
>> > for U-Boot going forward. ?Also, 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'. ?:-)
>
> FIT images are better than the old uImage format because they:
>
> - allow for strong checksum algorithms like MD5, SHA1, ... (the plain
> ?CRC32 method is not good enough if you for example want to run
> ?software in a slot machine in Las Vegas).
>
> - can combine multiple kernel images, device tree blobs and root file
> ?system images in arbitrary combinations; this allows for example
> ?for multibooting the same image on different boards by selecting
> ?the right DTB, for software updates with automatic fall-back, etc.
>
> - can be extended to add new features, images types or whatever in a
> ?standard way, using a standard technology (device tree support)
> ?which is already present anyway, i. e. without additional code
> ?overhead.

That's a lot of variability.  More on this at the end of my email...

>> 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
>
> You misunderstand. FIT images do not scuttle multiplatform kernels.
> Instead they support this much better, as they allow to bundle the
> repsective DTBs into one image file.

I believe I do understand.  The problem with this model is that it
makes the assumption that the kernel image builder has access to ahead
of time the full set of bootable platforms.  That assumption doesn't
hold anymore for a lot of markets where many vendors use the same SoC
in slightly different ways.  I think hardware vendors should be
encouraged to manage dtb blobs separately from the kernel so that we
can get out of the current paradigm of only supporting boards we know
about.

Practical example: Ubuntu on ARM netbooks.  Ubuntu is really not
interested in generating new kernel images every time a vendor
releases a new or modified piece of hardware.

If a vendor still decides that they want a kernel+dtb image then fine;
but I don't think it does the Linux ecosystem any favors to make it
the default choice.

>> 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)
>
> Even if the boot loader supports it, it is usually pretty benefical
> (especially during development) if you can do this.

Nothing prevents using a custom install script to wrap up a custom fit
image when copying it into the tftp directory (or wherever).

>> 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.
>
> Is this just your personal opinion, or do you think that this is
> really what a majority of kernel developers and users are wanting?

I've stated my opinion, my reasons for it, and what I'm willing to
merge.  However, I'm not the only PowerPC maintainer and the others
may disagree.  While I don't particularly like the fit image format,
it won't stop me from merging fitImage and fitImage.initrd patches.

I will not merge fitImage.% and fitImage.initrd.% targets because of
the variability I commented on above.  As you mentioned, there is a
huge amount of flexability in what sections are placed into a fit
image, such as carrying multiple dtb blobs.  However, a fitImage.%
pattern can only express a very specific subset (one kernel image +
one dtb image).  I do not want to codify a particular pattern into the
build system when it seems quite apparent that make targets are
nowhere near expressive enough to do what you're talking about with
fit images.  As is, the targets with embedded .dtbs are already rife
with special cases and other nastiness.

So, I choose to punt it out of the kernel.  If you want to build fit
images beyond just containing an kernel image, then use a custom
install or postprocessing script to assemble the vmlinux, dtb and
initrd building blocks into the image you need.

g.

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

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

[Peter Korsgaard]

>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:

Hi,

 Grant> Personally, I don't get any benefit out of the new image format,
 Grant> so I haven't spent any time looking at it.  However, I'm
 Grant> concerned about the drift back towards a different image per
 Grant> target when the move over the last 4 years has been towards
 Grant> multiplatform kernel images.  I certainly don't want to
 Grant> encourage embedding the device tree blob into the kernel image,
 Grant> and I'm not very interested in merging code to do that into the
 Grant> kernel tree.  If someone really needs to do that for their
 Grant> particular target, it is certainly easy enough for them to weld
 Grant> in the .dtb after the fact before transferring the image to the
 Grant> target, but I want that mode to be the exception, not the rule.

I understand the advantages of being able to compile multiplatform
kernels - But for the typical embedded device, having the device tree
together with the kernel makes stuff a lot simpler when upgrading
because of the version depencies of the dts.

That's also why I submitted the (nacked) multifile uimage support some
time ago:

http://thread.gmane.org/gmane.linux.ports.ppc64.devel/46825/

The fitimage stuff is the logical continuation of that.

-- 
Bye, Peter Korsgaard

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

[Wolfgang Denk]

Dear Grant,

In message <fa686aa40912301601s6cd0ec4y85b88976159a36af@mail.gmail.com> you wrote:
>
> Thinking further, I do actually have another concern, at least with
> regard to the way the current patch set implements things.  Is it
> expected or even "recommended" that fit images will *always* contain a
> .dtb image?  The current patch only handles the case of a .dtb
> embedded inside the fit image.

I think this can be expected.

Historically, the need to pass the dtb image to the Linux kernel,
too, was what actually triggered the development of the FIT image
format, as it turned out that the old image format with it's fixed
binary header was too inflexible. So bundling the kernel image and
the device tree blob into one image file is the specific use case
this image format was created for (which does not mean that other
usage would be impossible).

> Personally, I don't get any benefit out of the new image format, so I
> haven't spent any time looking at it.  However, I'm concerned about

Assume you want to boot over DHCP or similar, where you can provide
just a single image file for download. Here it is definitely nice if
you can bundle the kernel image and the DTB into one image file. We
were able to extend the old so-called "multi-file" uImage format to
handle this situation, too, but it was clear that further extensions
were not really possible.

We consider the old legace uImage format as something we want to move
away from, and the new FIT image format shall be the new default.

> the drift back towards a different image per target when the move over
> the last 4 years has been towards multiplatform kernel images.  I
> 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.  If 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.

This is specific for particular targets, but for  specific  modes  of
operation,  like  booting  over  the network or other szenarios where
transferring a single image file is essential - another example where
we often see this request is upgrade procedures for devics, where the
vendor wants to be able to distribute a single file  for  his  target
systems   to  avoid  customers  bricking  their  devices  by  chosing
incompatible combinations.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Perfection is reached, not when there is no longer anything  to  add,
but when there is no longer anything to take away.
                                           - Antoine de Saint-Exupery

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

[Grant Likely]

On Fri, Jan 1, 2010 at 7:12 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant,
>
> In message <fa686aa40912301601s6cd0ec4y85b88976159a36af@mail.gmail.com> you wrote:
>>
>> Thinking further, I do actually have another concern, at least with
>> regard to the way the current patch set implements things. ?Is it
>> expected or even "recommended" that fit images will *always* contain a
>> .dtb image? ?The current patch only handles the case of a .dtb
>> embedded inside the fit image.
>
> I think this can be expected.
>
> Historically, the need to pass the dtb image to the Linux kernel,
> too, was what actually triggered the development of the FIT image
> format, as it turned out that the old image format with it's fixed
> binary header was too inflexible. So bundling the kernel image and
> the device tree blob into one image file is the specific use case
> this image format was created for (which does not mean that other
> usage would be impossible).
>
>> Personally, I don't get any benefit out of the new image format, so I
>> haven't spent any time looking at it. ?However, I'm concerned about
>
> Assume you want to boot over DHCP or similar, where you can provide
> just a single image file for download. Here it is definitely nice if
> you can bundle the kernel image and the DTB into one image file. We
> were able to extend the old so-called "multi-file" uImage format to
> handle this situation, too, but it was clear that further extensions
> were not really possible.
>
> We consider the old legace uImage format as something we want to move
> away from, and the new FIT image format shall be the new default.
>
>> the drift back towards a different image per target when the move over
>> the last 4 years has been towards multiplatform kernel images. ?I
>> 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. ?If 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.
>
> This is specific for particular targets, but for ?specific ?modes ?of
> operation, ?like ?booting ?over ?the network or other szenarios where
> transferring a single image file is essential - another example where
> we often see this request is upgrade procedures for devics, where the
> vendor wants to be able to distribute a single file ?for ?his ?target
> systems ? to ?avoid ?customers ?bricking ?their ?devices ?by ?chosing
> incompatible combinations.

As I said in a previous email; I understand the need for certain
scenarios, but in the general case it is not the mode that I think
should be encouraged.  I don't want to merge additional targets for
.dtb embedded in the kernel image unless absolutely necessary, and I
want developers to have the mindset that .dtbs should be separate from
the kernel; and should be quasi-stable (or at least more stable than
the kernel itself) because I think that multiplatform is important,
and is going to become more important in the future.

So I don't want to support it by default; but OTOH, I'm not going to
actively prevent embedded .dtb blobs either.

g.

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

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

[Wolfgang Denk]

Dear Grant Likely,

In message <fa686aa41001022118w6b41765ld145c646bfca9423@mail.gmail.com> you wrote:
>
> As I said in a previous email; I understand the need for certain
> scenarios, but in the general case it is not the mode that I think
> should be encouraged.  I don't want to merge additional targets for
> .dtb embedded in the kernel image unless absolutely necessary, and I
> want developers to have the mindset that .dtbs should be separate from
> the kernel; and should be quasi-stable (or at least more stable than
> the kernel itself) because I think that multiplatform is important,
> and is going to become more important in the future.
> 
> So I don't want to support it by default; but OTOH, I'm not going to
> actively prevent embedded .dtb blobs either.

But by blocking the addition of such a make target you do actively
prevent this, don;t you?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The years of peak mental activity are undoubtedly between the ages of
four and eighteen. At four we know all the questions, at eighteen all
the answers.