LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Milton Miller <miltonm@bga.com>
To: david@gibson.dropbear.id.au, grant.likely@secretlab.ca,
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [RFC][POWERPC] bootwrapper: Add a firmware-independent
Date: Mon, 11 Feb 2008 01:07:39 -0600	[thread overview]
Message-ID: <31202713659663348734.1957747793.miltonm@bga.com> (raw)

On Friday, Feb 8, 2008 David Gibson wrote:
> On Fri, Feb 01, 2008 at 11:55:42PM -0700, Grant Likely wrote:
> From: Grant Likely <grant.likely at secretlab.ca>

[snip]
>> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
>> +   unsigned long r6, unsigned long r7)
>> +{
>> +const u32 *na, *ns, *reg, *timebase;
>> +u64 memsize64;
>> +int node, size, i;
>> +
>> +/* Allocate initial heap for probing the tree */
>> +simple_alloc_init(initial_heap, sizeof(initial_heap), 32, 64);
>> +
>> +/* Make sure FDT blob is sane */
>> +if (fdt_check_header(_dtb_start) != 0)
>> +fatal("Invalid device tree blob\n");
> 
> I think most of these fatal()s are pretty pointless.  This is
> platform_init(), so the console won't even have been initialized to
> actually print any of the messages.  Precisely because this is
> simpleboot, in which every bit of information the wrapper has comes
> from teh device tree, if the provided blob is so bad as to fail these
> basic tests, we're totally stuffed anyway.  It'll take a hardware
> debugger to track down, and I don't think the fatal()s will actually
> help much at that point.


My experience is the opposite: fatal is very useful even with a hardware debugger.  Since the code knows what is wrong, one only has to get the printf assembly buffer out of the map and dump it out.  Also, one can find which function called fatal from the nia and/or lr.  Much much easier than figuring out what happend when the prcessor jumps into the middle of code because it took an exception.

Also, one can patch in a debug output routine, possibly even in the __zlib_init.  Having the assertions is good.

That said, we should be conservative in calling something an error.

milton

                 reply	other threads:[~2008-02-11  7:54 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=31202713659663348734.1957747793.miltonm@bga.com \
    --to=miltonm@bga.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=grant.likely@secretlab.ca \
    --cc=linuxppc-dev@ozlabs.org \
    /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