linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: Jon Loeliger <jdl@freescale.com>
Cc: "linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>,
	Jon Loeliger <jdl@jdl.com>,
	u-boot-users <u-boot-users@lists.sourceforge.net>
Subject: Re: [U-Boot-Users] [PATCH: dtc take 2] Assemble the blob in memory before writing	it out.
Date: Thu, 19 Apr 2007 14:49:43 -0400	[thread overview]
Message-ID: <4627B9C7.8010800@smiths-aerospace.com> (raw)
In-Reply-To: <1177007241.14328.21.camel@ld0161-tx32>

Jon Loeliger wrote:
> On Wed, 2007-04-18 at 20:59, Jerry Van Baren wrote:
>> This makes padding out the blob if the user requested extra size much
>> easer.  The assembly and writing to the file is more straight forward too.
>>
>> Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>
>> ---
>>
>> Hi David, Jon,
>>
>> I wasn't happy with David's suggestion on the -S handling.  I also wasn't
>> all that wild about how the blob was assembled and then written to the
>> file piecemeal with "ad-hoc" alignment padding.  I realized I could fix
>> both by assembling the blob in memory as a "struct data" and then write
>> the whole thing out in one fell swoop.
>>
>> Makes it a lot simpler and cleaner to my eyes.
>>
>> Hope y'all agree,
>> gvb
> 
> Jerry and David,
> 
> Sorry.  I've been out sick for a couple days here and am
> just now catching up.  I've read through the last week's
> worth of mail here now, so let me see if I have properly
> summarized where things stand and what's needed for the DTC:
> 
> These patches need to be applied:
> 
>     [PATCH dtc] Add -o <output file> to the usage message.
>     Sat, 14 Apr 2007 18:16:47 -0400
> 
>     [PATCH dtc take 3] Fix reserve map output for asm format.
>     Tue, 17 Apr 2007 18:14:41 -0400
> 
>     [PATCH: dtc take 2] Assemble the blob in memory before writing it out.
>     Wed, 18 Apr 2007 21:59:51 -0400
> 
> The last patch there replaces the "Improve -S handling" patches.
> But does the last patch replace or depend on the second one?
> 
> And I agree with David that last patch is a better approach.
> 
> Thanks,
> jdl

Yes, you have that right.

Patch #1 is good to go
   [PATCH dtc] Add -o <output file> to the usage message.
   Sat, 14 Apr 2007 18:16:47 -0400

Patch #2 and #3...
   [PATCH dtc take 3] Fix reserve map output for asm format.
   Tue, 17 Apr 2007 18:14:41 -0400
   [PATCH: dtc take 2] Assemble the blob in memory before writing it out.
   Wed, 18 Apr 2007 21:59:51 -0400

...you force me to make a confession.  The third patch depends on the 
second patch because I snuck in a fix to the ASM output into the third 
patch: the last two chunks fix the ASM header output - I padded the blob 
out but didn't change the size properly in the header.  In the third 
patch above, I added a label "%s_blob_abs_end" and used that to 
calculate the total blob size (including the padding) in the header:

-	fprintf(f, "\t.long\t_%s_blob_end - _%s_blob_start /* totalsize */\n",
+	fprintf(f, "\t.long\t_%s_blob_abs_end - _%s_blob_start /* totalsize */\n",

--------

AAAARGH!  Sorry, I see I left a debug statement in flattree.c around 
line 390:

@@ -383,28 +370,46 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int 
version,
:
:
+fprintf(stderr, "minsize = %d, totalsize = %d, padlen = %d\n", minsize, 
be32_to_cpu(bph.totalsize), padlen);

Your option:
1) Take the last two patches as is and remove the fprintf yourself
2) I'll fix it tonight and provide a New Improved patch

Thanks,
gvb

  reply	other threads:[~2007-04-19 18:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-19  1:59 [PATCH: dtc take 2] Assemble the blob in memory before writing it out Jerry Van Baren
2007-04-19  2:05 ` David Gibson
2007-04-19 18:27 ` Jon Loeliger
2007-04-19 18:49   ` Jerry Van Baren [this message]
2007-04-19 19:03     ` [U-Boot-Users] " Jon Loeliger
2007-04-19 22:31     ` Jon Loeliger
2007-04-19 23:45       ` Jerry Van Baren

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=4627B9C7.8010800@smiths-aerospace.com \
    --to=gerald.vanbaren@smiths-aerospace.com \
    --cc=jdl@freescale.com \
    --cc=jdl@jdl.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=u-boot-users@lists.sourceforge.net \
    /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).