From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Date: Fri, 01 Jan 2010 15:12:05 +0100 [thread overview]
Message-ID: <20100101141205.6F0B13F6FF@gemini.denx.de> (raw)
In-Reply-To: <fa686aa40912301601s6cd0ec4y85b88976159a36af@mail.gmail.com>
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
next prev parent reply other threads:[~2010-01-01 14:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1261446643-21714-1-git-send-email-ptyser@xes-inc.com>
[not found] ` <1261446643-21714-4-git-send-email-ptyser@xes-inc.com>
[not found] ` <fa686aa40912301502x48785614ya4dd5c71815a7633@mail.gmail.com>
2009-12-30 23:39 ` [U-Boot] [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages Peter Tyser
2009-12-31 0:01 ` Grant Likely
2009-12-31 1:10 ` Peter Tyser
2010-01-03 5:08 ` Grant Likely
2010-01-03 10:10 ` Wolfgang Denk
2010-01-04 1:07 ` Peter Tyser
2010-01-04 8:27 ` Grant Likely
2009-12-31 8:01 ` Peter Korsgaard
2010-01-01 14:12 ` Wolfgang Denk [this message]
2010-01-03 5:18 ` Grant Likely
2010-01-03 10:15 ` Wolfgang Denk
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=20100101141205.6F0B13F6FF@gemini.denx.de \
--to=wd@denx.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox