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
WARNING: multiple messages have this Message-ID (diff)
From: John Bonesio <bones-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
To: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [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-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
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
next prev parent reply other threads:[~2011-03-21 18:36 UTC|newest]
Thread overview: 20+ 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 21:58 ` John Bonesio
2011-03-09 23:05 ` Ben Dooks
2011-03-09 23:05 ` Ben Dooks
2011-03-12 8:44 ` Grant Likely
2011-03-12 8:44 ` Grant Likely
2011-03-15 3:44 ` Shawn Guo
2011-03-15 3:44 ` Shawn Guo
2011-03-15 7:52 ` Shawn Guo
2011-03-15 7:52 ` Shawn Guo
2011-03-15 8:03 ` Grant Likely
2011-03-15 8:03 ` Grant Likely
2011-03-17 18:42 ` Nicolas Pitre
2011-03-17 18:42 ` Nicolas Pitre
2011-03-21 17:35 ` John Bonesio
2011-03-21 17:35 ` John Bonesio
2011-03-21 18:22 ` Nicolas Pitre
2011-03-21 18:22 ` Nicolas Pitre
2011-03-21 18:36 ` John Bonesio [this message]
2011-03-21 18:36 ` John Bonesio
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.