From: wmb@firmworks•com (Mitch Bradley)
To: linux-arm-kernel@lists•infradead.org
Subject: Where to put a large bootloader-supplied device tree on ARM ?
Date: Wed, 11 Jul 2012 20:52:43 -1000 [thread overview]
Message-ID: <4FFE743B.6080504@firmworks.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1207090015270.31100@xanadu.home>
On 7/8/2012 6:30 PM, Nicolas Pitre wrote:
> On Fri, 6 Jul 2012, Mitch Bradley wrote:
>
>> On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
>>> The kernel *must* go where it is linked, but the FDT contains only relative
>>> references and is thus free to go anywhere. The same is true of ramdisks,
>>> which
>>> are usually placed after the kernel.
>
> The kernel must go where it is linked *only* if you are using the
> 'Image' output. When using 'zImage' you can put the kernel anywhere in
> memory, or in the first 128MB of RAM if CONFIG_AUTO_ZRELADDR is used.
>
>> Right, but the kernel image is compressed, so after decompression it expands
>> into the area just after it. Also, the .bss segment is in that vicinity.
>
> To be exact, the compressed kernel moves itself out of the region where
> the decompressed kernel will end up before doing the decompression, but
> only if necessary. So it is a good idea to load zImage away from the
> decompressed kernel area to avoid this extra move and save some fraction
> of a second on boot time.
>
>> There's some code in arch/arm/boot/compressed/head.S to relocate
>> device tree blobs, but it requires CONFIG_ARM_APPENDED_DTB which
>> is not recommended - arch/arm/Kconfig recommends using the
>> documented boot protocol istead .
>
> This is in case a DTB is appended to zImage. When the DTB is detected,
> the moving of zImage out of the decompressed area must take care of
> moving the DTB as well.
>
>> Documentation/arm/Booting says
>> to put the dtb "in a region of memory where the kernel decompressor
>> will not overwrite it", further recommending the first 16KiB.
>>
>> As noted, the first 16KiB loses if the dtb is too large. And
>> "where the kernel decompressor will not overwrite it" says what
>> won't work, not what will. It appears that the decompressor works
>> out its addresses dynamically, so there's no hard prescription even
>> for what to avoid.
>
> A good rule of thumb is to take the size of the decompressed kernel and
> multiply this by 3. Rounding up is also fine. So for example if your
> arch/arm/boot/Image is 5MB, then putting anciliary data such as a
> ramdisk or a large DTB from 16MB into RAM or above should be fine.
>
>> For now, I'm putting the initrd at the end of memory and the dtb
>> below that. That seems to work, but I'm unsure whether or not
>> I'm just "getting lucky".
>
> That's also perfectly fine.
Alas, that worked for machines with 512 MiB of main memory, but failed
on 1 GiB machines. My guess is that, when the initrd and dtb are near
the top of a 1 GiB memory, the virtual address gets too near the top of
the kernel's 1 GiB of virtual space (which starts at 0xc0000000),
perhaps colliding with the VMALLOC space.
Putting them just below the 128 MiB boundary seems to work.
>
>
> Nicolas
>
next prev parent reply other threads:[~2012-07-12 6:52 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-03 14:22 [PATCH v2 00/12] IRQ, GPIO SPI, I2C, etc DTC support Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers Andrew Lunn
2012-07-05 8:15 ` Andrew Lunn
2012-07-05 9:02 ` Thomas Petazzoni
2012-07-05 9:48 ` Andrew Lunn
2012-07-05 10:10 ` Thomas Petazzoni
2012-07-05 10:25 ` Andrew Lunn
2012-07-05 10:11 ` Arnaud Patard (Rtp)
2012-07-05 10:20 ` Thomas Petazzoni
2012-07-05 10:38 ` Arnaud Patard (Rtp)
2012-07-05 11:42 ` Thomas Petazzoni
2012-07-05 11:48 ` Andrew Lunn
2012-07-05 12:09 ` Sebastian Hesselbarth
2012-07-05 12:58 ` Thomas Petazzoni
2012-07-05 13:15 ` Andrew Lunn
2012-07-05 13:28 ` Thomas Petazzoni
2012-07-05 13:33 ` Andrew Lunn
2012-07-05 13:36 ` Thomas Petazzoni
2012-07-05 12:25 ` Arnd Bergmann
2012-07-05 13:08 ` Andrew Lunn
2012-07-05 13:47 ` Arnd Bergmann
2012-07-05 13:54 ` Andrew Lunn
2012-07-05 15:47 ` Arnd Bergmann
2012-07-05 14:14 ` Sebastian Hesselbarth
2012-07-05 14:43 ` Andrew Lunn
2012-07-05 14:54 ` Arnd Bergmann
2012-07-05 15:51 ` Sebastian Hesselbarth
2012-07-05 16:30 ` Arnaud Patard (Rtp)
2012-07-05 16:16 ` Andrew Lunn
2012-07-06 20:08 ` Arnd Bergmann
2012-07-06 21:00 ` Andrew Lunn
2012-07-07 0:24 ` Where to put a large bootloader-supplied device tree on ARM ? Mitch Bradley
2012-07-07 1:23 ` David VomLehn (dvomlehn)
2012-07-07 1:59 ` Mitch Bradley
2012-07-09 4:30 ` Nicolas Pitre
2012-07-12 6:52 ` Mitch Bradley [this message]
2012-07-12 18:16 ` Nicolas Pitre
2012-07-12 20:34 ` Rob Herring
2012-07-12 21:38 ` [U-Boot] " Albert ARIBAUD
2012-07-12 21:47 ` Wolfgang Denk
2012-07-13 1:28 ` Rob Herring
2012-07-13 6:45 ` Albert ARIBAUD
2012-07-05 18:36 ` [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers Mitch Bradley
2012-07-03 14:22 ` [PATCH v2 02/12] SPI: Refactor spi-orion to use SPI framework queue Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 03/12] spi-orion: remove uneeded spi_info Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 04/12] spi-orion: add device tree binding Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 05/12] ARM: kirkwood: use devicetree for orion-spi Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 06/12] ARM: kirkwood: use devicetree for SPI on dreamplug Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 07/12] I2C: MV64XXX: Add Device Tree support Andrew Lunn
2012-07-03 15:59 ` Florian Fainelli
2012-07-03 16:58 ` Andrew Lunn
2012-07-04 19:49 ` Florian Fainelli
2012-07-05 6:52 ` Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 08/12] Kirkwood: Add basic device tree support for QNAP TS219 Andrew Lunn
2012-07-03 15:47 ` Florian Fainelli
2012-07-03 17:09 ` Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 09/12] ARM: Kirkwood: DTify the watchdog timer Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 10/12] ATA: sata_mv: Add device tree support Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 11/12] ARM: Kirkwood: Use DT to configure SATA device Andrew Lunn
2012-07-03 14:52 ` Josh Coombs
2012-07-03 15:32 ` Andrew Lunn
2012-07-03 14:22 ` [PATCH v2 12/12] Crypto: CESA: Add support for DT based instantiation Andrew Lunn
2012-07-03 15:50 ` Florian Fainelli
2012-07-03 17:03 ` Andrew Lunn
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=4FFE743B.6080504@firmworks.com \
--to=wmb@firmworks$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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