All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <jacmet@sunsite.dk>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Peter Tyser <ptyser@xes-inc.com>, u-boot <u-boot@lists.denx.de>,
	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 09:01:22 +0100	[thread overview]
Message-ID: <87skartvvx.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <fa686aa40912301601s6cd0ec4y85b88976159a36af@mail.gmail.com> (Grant Likely's message of "Wed, 30 Dec 2009 17:01:35 -0700")

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

WARNING: multiple messages have this Message-ID (diff)
From: Peter Korsgaard <jacmet@sunsite.dk>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org, Peter Tyser <ptyser@xes-inc.com>,
	linux-kbuild@vger.kernel.org, u-boot <u-boot@lists.denx.de>
Subject: Re: [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Date: Thu, 31 Dec 2009 09:01:22 +0100	[thread overview]
Message-ID: <87skartvvx.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <fa686aa40912301601s6cd0ec4y85b88976159a36af@mail.gmail.com> (Grant Likely's message of "Wed, 30 Dec 2009 17:01:35 -0700")

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

WARNING: multiple messages have this Message-ID (diff)
From: Peter Korsgaard <jacmet@sunsite.dk>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Date: Thu, 31 Dec 2009 09:01:22 +0100	[thread overview]
Message-ID: <87skartvvx.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <fa686aa40912301601s6cd0ec4y85b88976159a36af@mail.gmail.com> (Grant Likely's message of "Wed, 30 Dec 2009 17:01:35 -0700")

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

  parent reply	other threads:[~2009-12-31  8:01 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 [this message]
2009-12-31  8:01           ` 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
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=87skartvvx.fsf@macbook.be.48ers.dk \
    --to=jacmet@sunsite.dk \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=ptyser@xes-inc.com \
    --cc=u-boot@lists.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.