From: Jerry Van Baren <gvb.linuxppc.dev@gmail.com>
To: Milton Miller <miltonm@bga.com>
Cc: linuxppc-dev@ozlabs.org, Jon Loeliger <jdl@jdl.com>
Subject: Re: [PATCH dtc take 2] Fix reserve map output for asm format.
Date: Sun, 15 Apr 2007 20:24:06 -0400 [thread overview]
Message-ID: <4622C226.1070304@gmail.com> (raw)
In-Reply-To: <aa6a7bd73be20ea11e3e98f87a66e478@bga.com>
Milton Miller wrote:
> Sometime around Sun Apr 15 12:29:14 EST 2007, Jerry Van Baren wrote:
>> Add extra reserve map slots output for asm format (previously done for
>> dtb
>> output).
>>
>> Signed-off-by: Gerald Van Baren <vanbaren at cideas.com>
>> ---
>>
>> Hi Jon, David,
>>
>> Here is a patch that fixes the asm output without the (unnecessary)
>> calloc change.
>>
>> Best regards,
>> gvb
>
>
> The previous description had
>> Use cmalloc to pre-zero memory (for dtb input) and handle dtb (binary)
>> input being shorter than the total blob length (result of putting
>> extra space in the blob).
>
>
> Which at least said in the description the unrelated things it was
> doing.
That was my added comment WRT the change from malloc to cmalloc. David
wasn't wild about using cmalloc, so I removed it. Using cmalloc is not
necessary.
>> while (sizeleft) {
>> - if (feof(f))
>> - die("EOF before reading %d bytes of DT blob\n",
>> - totalsize);
>> + if (feof(f)) {
>> + WARNMSG("EOF after reading %d of %d bytes of
>> DT blob, assuming there is extra space in the blob.\n",
>> + totalsize - sizeleft, totalsize);
>> + break;
>> + }
>
> I thnk the above should be an ERROR and cause failure without
> the -f (force) option.
>
> The total_size says how much data should be copied. Anything
> less and there is data missing. Assuming zeros is wrong for
> most sections (the exception being the memory reserve list
> that had a terminating 0 entry within the read portion).
>
> milton
The reason total_size is bigger than the actual size is because I
created the blob with extra space using the -S parameter. It is
intentionally bigger. The extra space is ignored by dtc when creating a
dts/asm format output which is why cmalloc() is unnecessary.
I suppose we could require a -f force but I'm not wild about creating a
nanny program. There is nothing wrong with the blob - it parses just
fine. If there were problems with the blob contents, other errors would
be raised.
Best regards,
gvb
next prev parent reply other threads:[~2007-04-16 0:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-15 2:29 [PATCH dtc take 2] Fix reserve map output for asm format Jerry Van Baren
2007-04-15 19:59 ` Milton Miller
2007-04-16 0:24 ` Jerry Van Baren [this message]
2007-04-16 0:51 ` David Gibson
2007-04-16 1:20 ` Jerry Van Baren
2007-04-16 3:49 ` Milton Miller
2007-04-16 4:16 ` David Gibson
2007-04-16 5:08 ` Milton Miller
2007-04-16 6:30 ` David Gibson
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=4622C226.1070304@gmail.com \
--to=gvb.linuxppc.dev@gmail.com \
--cc=jdl@jdl.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=miltonm@bga.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).