linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: bones@secretlab.ca (John Bonesio)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
Date: Mon, 21 Mar 2011 11:36:56 -0700	[thread overview]
Message-ID: <4D879AC8.9080901@secretlab.ca> (raw)
In-Reply-To: <alpine.LFD.2.00.1103211413560.11889@xanadu.home>

Comments below.

- John

On 03/21/2011 11:22 AM, Nicolas Pitre wrote:
> On Mon, 21 Mar 2011, John Bonesio wrote:
> 
>> Hi Nicolas,
>>
>> Thanks for the comments. I have a question (below).
>>
> [...]

[snip]

>>>
>>> Now if no dtb was found, or if that code is not configured, then lr 
>>> contains garbage and that may have random consequences with the code 
>>> that follows, which would explain the reported bad behaviors with this 
>>> patch applied even if not configured in the kernel.
>>
>> I'm probably not understanding something here. When I look at the code
>> prior to my patch, it looks like lr is not initialized by head.S.
> 
> Exact.
> 
>> It also looks like this code makes use of lr when it relocates the 
>> code and leaves it uninitialized when it jumps back to 'restart'.
> 
> Exact.
> 
>> Is this a bug in the previous code too?
> 
> No.
> 
>> What should lr be initialized to, or should we just be preserving it's
>> value?
> 
> No.  The problem is that you do use lr further down in your patch when 
> adjusting GOT entries, assuming it contains the size of the dtb.  If no 
> DTB is found then lr contains random stuff that will mess up the GOT for 
> .bss references.

Oh! Good catch. Thanks.

> 
>> I saw the comment about the performance is different with this patch -
>> something about a pause between 'Uncompressing Linux...' and the kernel
>> boot output. I'm not sure what's going on here. By the time
>> 'Uncompressing Linux...' comes out all relocations and dtb discovery is
>> complete. Do you really think having lr uninitialized would cause this?
> 
> Certainly.  See above.
> 
> 
> Nicolas

      reply	other threads:[~2011-03-21 18:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-09 21:58 [PATCH] ARM:boot:device tree: Allow the device tree binary to be appended to zImage John Bonesio
2011-03-09 23:05 ` Ben Dooks
2011-03-12  8:44   ` Grant Likely
2011-03-15  3:44 ` Shawn Guo
2011-03-15  7:52   ` Shawn Guo
2011-03-15  8:03     ` Grant Likely
2011-03-17 18:42 ` Nicolas Pitre
2011-03-21 17:35   ` John Bonesio
2011-03-21 18:22     ` Nicolas Pitre
2011-03-21 18:36       ` John Bonesio [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=4D879AC8.9080901@secretlab.ca \
    --to=bones@secretlab.ca \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).