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: Sun, 03 Jan 2010 17:52:46 -0600	[thread overview]
Message-ID: <4B412DCE.4030509@xes-inc.com> (raw)
In-Reply-To: <20100101104449.6DAC63F6FF@gemini.denx.de>

Hi Wolfgang,

> The "new" FIT image type should become the default, and old "legacy"
> images should only be generated upon special request (i. e. if some-
> one needs these for compatibility with an old, not yet FIT-aware
> version of the boot loader).

Agreed.

>> What do you think about changing the U-Boot documentation to rename
>> those 2 image types to:
>> 1 uImages
>> 2 FIT Images
>
> Let's make this "uImage.old" (or "uImage.legacy" similar) and
> "uImage", then.

I'm in favor of keeping the old uImage format/naming the same, and 
calling the new image format a FIT Image.  ie no mention of uImage for 
FIT images.

<snip>

>> 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.
>
> Well, you can read "uImage" as "universal Image", which kind of fits
> the FIT approach :-)

I agree that the FIT image is a type of "universal Image", but I think 
"FIT image" is much more descriptive and accurate than "universal 
Image".  The FIT naming convention is designed to match device tree 
naming, which has lots of meaning.  eg:
   Flattened Device Tree (FDT) -> Flattened Image Tree (FIT)
   device tree source (.dts) -> image tree source (.its)
   device tree blob (.dtb) -> image tree blob (.itb)

>> 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.
>
> I think we should not try to support both legacy and FIT images on the
> same level - the idea is clearly that legacy images is the old, to be
> replaced format, while FIT images is the new, to be used as standard
> format.

Agreed.

In this sense I vote for using plain and simple "uImage" for
> the (new) standard format, and marking the old format by some ".old"
> or ".legacy" suffix.

I disagree here.  I don't think calling FIT images "FIT uImages" adds 
much value and it would add confusion as there are now multiple uImage 
formats that a user needs to keep straight.  Keeping the legacy uImage 
naming/format the same, and calling the new FIT images "fitImage" (or 
possibly itbImage to line up with the dtbImage target) would make more 
sense to me.  Is there a compelling reason to keep the uImage word 
connected to FIT images?

Best,
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: Sun, 03 Jan 2010 17:52:46 -0600	[thread overview]
Message-ID: <4B412DCE.4030509@xes-inc.com> (raw)
In-Reply-To: <20100101104449.6DAC63F6FF@gemini.denx.de>

Hi Wolfgang,

> The "new" FIT image type should become the default, and old "legacy"
> images should only be generated upon special request (i. e. if some-
> one needs these for compatibility with an old, not yet FIT-aware
> version of the boot loader).

Agreed.

>> What do you think about changing the U-Boot documentation to rename
>> those 2 image types to:
>> 1 uImages
>> 2 FIT Images
>
> Let's make this "uImage.old" (or "uImage.legacy" similar) and
> "uImage", then.

I'm in favor of keeping the old uImage format/naming the same, and 
calling the new image format a FIT Image.  ie no mention of uImage for 
FIT images.

<snip>

>> 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.
>
> Well, you can read "uImage" as "universal Image", which kind of fits
> the FIT approach :-)

I agree that the FIT image is a type of "universal Image", but I think 
"FIT image" is much more descriptive and accurate than "universal 
Image".  The FIT naming convention is designed to match device tree 
naming, which has lots of meaning.  eg:
   Flattened Device Tree (FDT) -> Flattened Image Tree (FIT)
   device tree source (.dts) -> image tree source (.its)
   device tree blob (.dtb) -> image tree blob (.itb)

>> 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.
>
> I think we should not try to support both legacy and FIT images on the
> same level - the idea is clearly that legacy images is the old, to be
> replaced format, while FIT images is the new, to be used as standard
> format.

Agreed.

In this sense I vote for using plain and simple "uImage" for
> the (new) standard format, and marking the old format by some ".old"
> or ".legacy" suffix.

I disagree here.  I don't think calling FIT images "FIT uImages" adds 
much value and it would add confusion as there are now multiple uImage 
formats that a user needs to keep straight.  Keeping the legacy uImage 
naming/format the same, and calling the new FIT images "fitImage" (or 
possibly itbImage to line up with the dtbImage target) would make more 
sense to me.  Is there a compelling reason to keep the uImage word 
connected to FIT images?

Best,
Peter

  parent reply	other threads:[~2010-01-04  0:54 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
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 [this message]
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=4B412DCE.4030509@xes-inc.com \
    --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.