linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: Scott Wood <scottwood@freescale.com>
Cc: peterz@infradead.org, mingo@redhat.com,
	linuxppc-dev@lists.ozlabs.org,
	"Ira W. Snyder" <iws@ovro.caltech.edu>
Subject: Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
Date: Fri, 10 Sep 2010 13:29:01 +0200	[thread overview]
Message-ID: <20100910112901.0BACA1506AA@gemini.denx.de> (raw)
In-Reply-To: <20100909173735.503c4cc0@schlenkerla.am.freescale.net>

Dear Scott Wood,

In message <20100909173735.503c4cc0@schlenkerla.am.freescale.net> you wrote:
>
> It actually can load an ELF file, but it doesn't currently support
> passing a device tree to it (only argc/argv text arguments, or some
> vxworks stuff).

I see no problems to extend U-Boot such that we support booting Linux
kernel images in form of ELF files. Ideally these should be wrapped
into FIT images to allow for easy combination of kernel and FDT into a
single file (useful for netboot).

> > I've never understood the reasoning for that uImage wrapper
> > thingy. Definitely causes more problems than it solves in my experience.
> 
> Wolfgang was just defending it on the U-Boot list the past couple
> days...  seems like the main thing in its favor is the CRC, especially
> as a final check before reflashing an image.

The additional file header serves a number of purposes; even if they
seem of little use to a developer they are really helpful in
production and maintenance/repair.

Assume you were to find out why a system (returned from a customer)
does not boot any more. Being able to identify the kernel image in
flash, with information about version (name string), image build time
and size is really, really helpful then. Of course it's also helpful
to be able to check if the image is OK or for example has been
(partially) overwritten.


The checksum protection is indeed a VERY useful thing.


If we hade similar checksum protection on the device tree we would
have been able to recognize the memory corruption that triggered this
thread MUCH easier.


Acutally this is my biggest critique on the FDT blob: that we cannot
detect corruptions like this.

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@denx.de
It is a good thing for an uneducated man to read books of quotations.
                        - Sir Winston Churchill _My Early Life_ ch. 9

      parent reply	other threads:[~2010-09-10 11:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-08 23:21 CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?) Ira W. Snyder
2010-09-09  1:02 ` Benjamin Herrenschmidt
2010-09-09  2:52   ` Ira W. Snyder
2010-09-09  2:58     ` Benjamin Herrenschmidt
2010-09-09 16:23       ` Ira W. Snyder
2010-09-09 18:44         ` Ira W. Snyder
2010-09-09 19:10           ` Timur Tabi
2010-09-09 19:36             ` Ira W. Snyder
2010-09-09 19:40               ` Timur Tabi
2010-09-09 20:06                 ` Ira W. Snyder
2010-09-09 20:13                   ` Timur Tabi
2010-09-09 20:31                     ` Ira W. Snyder
2010-09-09 20:36                       ` Timur Tabi
2010-09-09 20:55                         ` Ira W. Snyder
2010-09-09 21:19                           ` Timur Tabi
2010-09-09 22:01               ` Benjamin Herrenschmidt
2010-09-09 19:33           ` Ira W. Snyder
2010-09-09 21:58         ` Benjamin Herrenschmidt
2010-09-09 22:11           ` Scott Wood
2010-09-09 22:13             ` Benjamin Herrenschmidt
2010-09-09 22:16               ` Benjamin Herrenschmidt
2010-09-09 22:37               ` Scott Wood
2010-09-09 22:49                 ` Benjamin Herrenschmidt
2010-09-10 11:29                 ` Wolfgang Denk [this message]

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=20100910112901.0BACA1506AA@gemini.denx.de \
    --to=wd@denx.de \
    --cc=iws@ovro.caltech.edu \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=scottwood@freescale.com \
    /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;
as well as URLs for NNTP newsgroup(s).