From: "André Przywara" <andre.przywara@arm.com>
To: u-boot@lists.denx.de
Subject: [PATCH 1/7] arm: juno: Fix Juno address variables
Date: Thu, 26 Mar 2020 16:14:03 +0000 [thread overview]
Message-ID: <ffdfbc6e-47d5-0c52-08b7-b8de0e4d0857@arm.com> (raw)
In-Reply-To: <20200326023805.GW5793@bill-the-cat>
On 26/03/2020 02:38, Tom Rini wrote:
Hi,
> On Wed, Mar 25, 2020 at 02:46:56PM +0000, Andre Przywara wrote:
>
>> The U-Boot documentation explains that variables ending with "_r" hold
>> addresses in DRAM, while those without that ending point to flash/ROM.
>> The default variables for the Juno board pointing to the kernel and DTB
>> load addresses were not complying with this scheme: they lack the
>> extension, but point to DRAM. This is particularly confusing since the
>> Juno board features parallel NOR flash, so there *is* a memory mapped
>> NOR address holding a DTB, for instance.
>>
>> Fix the variables to use the proper names. On the way adjust the FDT
>> load address to be situated *before* the kernel, since users happened
>> to overwrite the DTB by the kernel clearing its .BSS section during
>> initialisation.
>>
>> That fixes loading debug kernels, which happened to overwrite the DTB on
>> certain setups.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
> [snip]
>> - "fdt_addr=0x83000000\0" \
>> + "fdt_addr_r=0x80000000\0" \
>> "fdt_high=0xffffffffffffffff\0" \
>> "initrd_high=0xffffffffffffffff\0" \
>
> On a related note, using fdt_high=0xff... to disable relocation is a bad
> idea and can lead to U-Boot knowing we have it at an invalid (unaligned)
> location but doing nothing and causing problems down the chain. Please
> use bootm_size or similar (documented in the README, still) to limit
> where the fdt can be. Thanks!
Thanks, looks like I will drop this then. arm64 kernels before 4.2 had a
limit of placing the DTB with 512MB of the kernel image, but this has
been lifted since then. I might address this later shall people complain.
On a related note: I just see we use initrd_* variables here, where
there are more users of ramdisk_addr*. Shall I fix this here as well?
Seems like only ramdisk_addr* is mentioned in README.
Cheers,
Andre
next prev parent reply other threads:[~2020-03-26 16:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 14:46 [PATCH 0/7] Arm Juno board OF_CONTROL upgrade Andre Przywara
2020-03-25 14:46 ` [PATCH 1/7] arm: juno: Fix Juno address variables Andre Przywara
2020-03-26 2:38 ` Tom Rini
2020-03-26 16:14 ` André Przywara [this message]
2020-03-26 16:18 ` Tom Rini
2020-03-26 22:29 ` Linus Walleij
2020-03-25 14:46 ` [PATCH 2/7] uart: pl011: Add proper DM clock support Andre Przywara
2020-03-26 16:20 ` Simon Glass
2020-03-26 17:06 ` André Przywara
2020-03-26 21:30 ` Simon Glass
2020-03-26 22:34 ` Linus Walleij
2020-03-25 14:46 ` [PATCH 3/7] arm: juno: Fix UART clock rate Andre Przywara
2020-03-27 21:17 ` Linus Walleij
2020-03-25 14:46 ` [PATCH 4/7] arm: juno: Enable OF_CONTROL Andre Przywara
2020-03-27 21:22 ` Linus Walleij
2020-03-25 14:47 ` [PATCH 5/7] arm: juno: Use PSCI based reset Andre Przywara
2020-03-27 21:23 ` Linus Walleij
2020-03-25 14:47 ` [PATCH 6/7] arm: juno: enable USB Andre Przywara
2020-03-27 21:24 ` Linus Walleij
2020-03-25 14:47 ` [PATCH 7/7] arm: vexpress64: Remove unneeded CONFIG_ check Andre Przywara
2020-03-27 21:26 ` Linus Walleij
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=ffdfbc6e-47d5-0c52-08b7-b8de0e4d0857@arm.com \
--to=andre.przywara@arm.com \
--cc=u-boot@lists.denx.de \
/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