From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
Date: Fri, 29 Apr 2011 06:09:40 -0700 [thread overview]
Message-ID: <20110429130939.GB3755@atomide.com> (raw)
In-Reply-To: <BANLkTi=jcb8Piki6RrijGOQG=wJ=ULv5Gw@mail.gmail.com>
* Grant Likely <grant.likely@secretlab.ca> [110429 05:59]:
> On Fri, Apr 29, 2011 at 4:26 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * Tony Lindgren <tony@atomide.com> [110427 07:41]:
> >
> > If the compressed image is smaller than BSS, then we end up
> > having DT data in the BSS area. In this case the compressed
> > image is about 2.3 MB for LZMA.
> >
> > The uncompress code does not know about the kernel BSS,
> > and does not necessarily relocate anything depending on the
> > compressed image load address.
> >
> > So in which code do we want to relocate the DT data?
> >
> > We could do it based on estimated BSS size in uncompress code,
> > or based on the real BSS size in __mmap_switched before BSS
> > gets reset.
>
> How about telling the wrapper what the final size will be by scraping
> the __bss_end value out of System.map?
That sounds doable to me. It should probably be done in the uncompress
code so the kernel code can stay generic for the DT data handling.
BTW, with the relocation of DT data we may end up overwriting
an initrd, but I guess bootloaders typically place the initrd to
the end of the memory.
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage
Date: Fri, 29 Apr 2011 06:09:40 -0700 [thread overview]
Message-ID: <20110429130939.GB3755@atomide.com> (raw)
In-Reply-To: <BANLkTi=jcb8Piki6RrijGOQG=wJ=ULv5Gw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> [110429 05:59]:
> On Fri, Apr 29, 2011 at 4:26 AM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [110427 07:41]:
> >
> > If the compressed image is smaller than BSS, then we end up
> > having DT data in the BSS area. In this case the compressed
> > image is about 2.3 MB for LZMA.
> >
> > The uncompress code does not know about the kernel BSS,
> > and does not necessarily relocate anything depending on the
> > compressed image load address.
> >
> > So in which code do we want to relocate the DT data?
> >
> > We could do it based on estimated BSS size in uncompress code,
> > or based on the real BSS size in __mmap_switched before BSS
> > gets reset.
>
> How about telling the wrapper what the final size will be by scraping
> the __bss_end value out of System.map?
That sounds doable to me. It should probably be done in the uncompress
code so the kernel code can stay generic for the DT data handling.
BTW, with the relocation of DT data we may end up overwriting
an initrd, but I guess bootloaders typically place the initrd to
the end of the memory.
Regards,
Tony
next prev parent reply other threads:[~2011-04-29 13:09 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 23:18 [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage John Bonesio
2011-03-24 23:18 ` John Bonesio
2011-03-24 23:37 ` Nicolas Pitre
2011-03-24 23:37 ` Nicolas Pitre
2011-03-28 9:13 ` Shawn Guo
2011-03-28 9:13 ` Shawn Guo
2011-04-13 14:00 ` Tony Lindgren
2011-04-13 14:00 ` Tony Lindgren
2011-04-20 5:47 ` Shawn Guo
2011-04-20 5:47 ` Shawn Guo
2011-04-20 7:34 ` Shawn Guo
2011-04-20 7:34 ` Shawn Guo
2011-04-21 8:02 ` Tony Lindgren
2011-04-21 8:02 ` Tony Lindgren
2011-04-21 12:46 ` Tony Lindgren
2011-04-21 12:46 ` Tony Lindgren
2011-04-27 14:23 ` Tony Lindgren
2011-04-27 14:23 ` Tony Lindgren
2011-04-27 14:38 ` Tony Lindgren
2011-04-27 14:38 ` Tony Lindgren
2011-04-27 14:40 ` Nicolas Pitre
2011-04-27 14:40 ` Nicolas Pitre
2011-04-27 14:43 ` Tony Lindgren
2011-04-27 14:43 ` Tony Lindgren
2011-04-29 10:26 ` Tony Lindgren
2011-04-29 10:26 ` Tony Lindgren
2011-04-29 13:02 ` Grant Likely
2011-04-29 13:02 ` Grant Likely
2011-04-29 13:08 ` Grant Likely
2011-04-29 13:08 ` Grant Likely
2011-04-29 13:09 ` Tony Lindgren [this message]
2011-04-29 13:09 ` Tony Lindgren
2011-04-29 13:21 ` Nicolas Pitre
2011-04-29 13:21 ` Nicolas Pitre
2011-04-29 13:16 ` Nicolas Pitre
2011-04-29 13:16 ` Nicolas Pitre
2011-04-29 13:53 ` Russell King - ARM Linux
2011-04-29 13:53 ` Russell King - ARM Linux
2011-04-29 19:14 ` Nicolas Pitre
2011-04-29 19:14 ` Nicolas Pitre
2011-05-04 7:23 ` Tony Lindgren
2011-05-04 7:23 ` Tony Lindgren
2011-05-04 13:12 ` Tony Lindgren
2011-05-04 13:12 ` Tony Lindgren
2011-05-04 13:38 ` Nicolas Pitre
2011-05-04 13:38 ` Nicolas Pitre
2011-05-09 11:19 ` [PATCH] ARM: Make sure appended device tree data won't overlap kernel BSS Tony Lindgren
2011-05-09 11:19 ` Tony Lindgren
2011-05-09 14:49 ` Tony Lindgren
2011-05-09 14:49 ` Tony Lindgren
2011-05-12 12:59 ` Tony Lindgren
2011-05-12 12:59 ` Tony Lindgren
2011-05-13 7:39 ` Nicolas Pitre
2011-05-13 7:39 ` Nicolas Pitre
2011-05-13 11:21 ` Tony Lindgren
2011-05-13 11:21 ` Tony Lindgren
2011-05-13 13:09 ` Nicolas Pitre
2011-05-13 13:09 ` Nicolas Pitre
2011-05-13 13:28 ` Tony Lindgren
2011-05-13 13:28 ` Tony Lindgren
2011-06-07 12:43 ` Tony Lindgren
2011-06-07 12:43 ` Tony Lindgren
2011-06-07 13:14 ` Nicolas Pitre
2011-06-07 13:14 ` Nicolas Pitre
2011-06-07 13:22 ` Tony Lindgren
2011-06-07 13:22 ` Tony Lindgren
2011-06-12 6:14 ` Nicolas Pitre
2011-06-12 6:14 ` Nicolas Pitre
2011-06-13 10:49 ` Tony Lindgren
2011-06-13 10:49 ` Tony Lindgren
2011-05-09 11:23 ` [PATCHv3] ARM:boot:device tree: Allow the device tree binary to be appended to zImage Tony Lindgren
2011-05-09 11:23 ` Tony Lindgren
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=20110429130939.GB3755@atomide.com \
--to=tony@atomide.com \
--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.