All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Tyser <ptyser@xes-inc.com>
To: Wolfgang Denk <wd@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	linuxppc-dev@ozlabs.org, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Date: Thu, 31 Dec 2009 17:10:38 -0600	[thread overview]
Message-ID: <1262301038.29396.137.camel@localhost.localdomain> (raw)
In-Reply-To: <20091231224439.AF5353F6D1@gemini.denx.de>

Hi Wolfgang,

> > IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
> > Makefile so that make behaves more consistently.  Speaking of which,
> > the number of '.' in the name is getting rather large.  Would you
> > consider using 'fitImage' instead of 'uImage.fit'?
> 
> Why chose a different name at all? We could still call it "uImage",
> meaning "U-Boot image" - U-Boot is clever enought o detect
> automatically if we pass it an old style or a fit image.

I agree with your point to an extent, but having 2 types of uImages is
somewhat confusing to a user, even if U-Boot can differentiate between
them.  And if the legacy image and FIT image had the same Make target,
how does a user specify which type they want to build?  The fact that
both "legacy" and FIT images would reside at arch/powerpc/boot/uImage
doesn't make things any less confusing to Joe User.

Currently U-Boot supports booting:
1 "legacy" uImages
2 "new" Flattened Image Tree (FIT) uImages

What do you think about changing the U-Boot documentation to rename
those 2 image types to:
1 uImages
2 FIT Images

The FIT image is a relatively generic image type - its just a blob that
dtc created from a device tree and some input binaries.  In my mind its
not intimately tied to U-Boot, at least not conceptually.  The "legacy"
uImages have to agree with U-Boot's header format defined in the U-Boot
source code, so the uImage name does make sense with respect to the
"legacy" uImages.

My vote would be to make the Linux FIT target rule "fitImage" and then
update the U-Boot documentation to make obvious the differences between
uImages and FIT images.

What do you think of that?

Thanks,
Peter




WARNING: multiple messages have this Message-ID (diff)
From: Peter Tyser <ptyser@xes-inc.com>
To: Wolfgang Denk <wd@denx.de>
Cc: linuxppc-dev@ozlabs.org, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Date: Thu, 31 Dec 2009 17:10:38 -0600	[thread overview]
Message-ID: <1262301038.29396.137.camel@localhost.localdomain> (raw)
In-Reply-To: <20091231224439.AF5353F6D1@gemini.denx.de>

Hi Wolfgang,

> > IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
> > Makefile so that make behaves more consistently.  Speaking of which,
> > the number of '.' in the name is getting rather large.  Would you
> > consider using 'fitImage' instead of 'uImage.fit'?
> 
> Why chose a different name at all? We could still call it "uImage",
> meaning "U-Boot image" - U-Boot is clever enought o detect
> automatically if we pass it an old style or a fit image.

I agree with your point to an extent, but having 2 types of uImages is
somewhat confusing to a user, even if U-Boot can differentiate between
them.  And if the legacy image and FIT image had the same Make target,
how does a user specify which type they want to build?  The fact that
both "legacy" and FIT images would reside at arch/powerpc/boot/uImage
doesn't make things any less confusing to Joe User.

Currently U-Boot supports booting:
1 "legacy" uImages
2 "new" Flattened Image Tree (FIT) uImages

What do you think about changing the U-Boot documentation to rename
those 2 image types to:
1 uImages
2 FIT Images

The FIT image is a relatively generic image type - its just a blob that
dtc created from a device tree and some input binaries.  In my mind its
not intimately tied to U-Boot, at least not conceptually.  The "legacy"
uImages have to agree with U-Boot's header format defined in the U-Boot
source code, so the uImage name does make sense with respect to the
"legacy" uImages.

My vote would be to make the Linux FIT target rule "fitImage" and then
update the U-Boot documentation to make obvious the differences between
uImages and FIT images.

What do you think of that?

Thanks,
Peter

  reply	other threads:[~2009-12-31 23:10 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-22  1:50 [PATCH v2 0/3] powerpc: Add support for FIT uImages Peter Tyser
2009-12-22  1:50 ` Peter Tyser
2009-12-22  1:50 ` [PATCH v2 1/3] powerpc: Use scripts/mkuboot.sh instead of 'mkimage' Peter Tyser
2009-12-22  1:50   ` Peter Tyser
2009-12-30 22:25   ` Grant Likely
2009-12-30 22:25     ` Grant Likely
2009-12-22  1:50 ` [PATCH v2 2/3] powerpc: Add support for creating FIT uImages Peter Tyser
2009-12-22  1:50   ` Peter Tyser
2009-12-22  3:48   ` Olof Johansson
2009-12-22  4:50     ` Peter Tyser
2009-12-30 22:57   ` Grant Likely
2009-12-30 22:57     ` Grant Likely
2010-01-01 14:18     ` Wolfgang Denk
2010-01-01 14:18       ` Wolfgang Denk
2010-01-03  5:23       ` Grant Likely
2010-01-03  5:23         ` Grant Likely
2009-12-22  1:50 ` [PATCH v2 3/3] powerpc: Add support for ram filesystems in " Peter Tyser
2009-12-22  1:50   ` Peter Tyser
2009-12-30 23:02   ` Grant Likely
2009-12-30 23:02     ` Grant Likely
2009-12-30 23:39     ` Peter Tyser
2009-12-30 23:39       ` [U-Boot] " Peter Tyser
2009-12-30 23:39       ` Peter Tyser
2009-12-31  0:01       ` Grant Likely
2009-12-31  0:01         ` [U-Boot] " Grant Likely
2009-12-31  0:01         ` Grant Likely
2009-12-31  1:10         ` Peter Tyser
2009-12-31  1:10           ` [U-Boot] " Peter Tyser
2009-12-31  1:10           ` Peter Tyser
2010-01-03  5:08           ` [U-Boot] " Grant Likely
2010-01-03  5:08             ` Grant Likely
2010-01-03  5:08             ` Grant Likely
2010-01-03 10:10             ` Wolfgang Denk
2010-01-03 10:10               ` Wolfgang Denk
2010-01-03 10:10               ` Wolfgang Denk
2010-01-04  1:07               ` Peter Tyser
2010-01-04  1:07                 ` Peter Tyser
2010-01-04  1:07                 ` Peter Tyser
2010-01-04  8:27               ` Grant Likely
2010-01-04  8:27                 ` Grant Likely
2010-01-04  8:27                 ` Grant Likely
2009-12-31  8:01         ` Peter Korsgaard
2009-12-31  8:01           ` [U-Boot] " Peter Korsgaard
2009-12-31  8:01           ` Peter Korsgaard
2010-01-01 14:12         ` Wolfgang Denk
2010-01-01 14:12           ` [U-Boot] " Wolfgang Denk
2010-01-01 14:12           ` Wolfgang Denk
2010-01-03  5:18           ` Grant Likely
2010-01-03  5:18             ` [U-Boot] " Grant Likely
2010-01-03  5:18             ` Grant Likely
2010-01-03 10:15             ` Wolfgang Denk
2010-01-03 10:15               ` [U-Boot] " Wolfgang Denk
2010-01-03 10:15               ` Wolfgang Denk
2009-12-31 22:44     ` Wolfgang Denk
2009-12-31 22:44       ` Wolfgang Denk
2009-12-31 23:10       ` Peter Tyser [this message]
2009-12-31 23:10         ` Peter Tyser
2010-01-01 10:44         ` Wolfgang Denk
2010-01-01 10:44           ` Wolfgang Denk
2010-01-03  5:13           ` Grant Likely
2010-01-03  5:13             ` Grant Likely
2010-01-03 10:12             ` Wolfgang Denk
2010-01-03 10:12               ` Wolfgang Denk
2010-01-03  8:06           ` Peter Korsgaard
2010-01-03  8:06             ` Peter Korsgaard
2010-01-03  9:50             ` Wolfgang Denk
2010-01-03  9:50               ` Wolfgang Denk
2010-01-03 14:27               ` Peter Korsgaard
2010-01-03 14:27                 ` Peter Korsgaard
2010-01-04  8:34                 ` Grant Likely
2010-01-04  8:34                   ` Grant Likely
2010-01-03 23:52           ` Peter Tyser
2010-01-03 23:52             ` Peter Tyser
2010-01-03  5:10       ` Grant Likely
2010-01-03  5:10         ` Grant Likely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1262301038.29396.137.camel@localhost.localdomain \
    --to=ptyser@xes-inc.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=wd@denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.