From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH 1/7] arm: juno: Fix Juno address variables
Date: Thu, 26 Mar 2020 12:18:29 -0400 [thread overview]
Message-ID: <20200326161829.GZ5793@bill-the-cat> (raw)
In-Reply-To: <ffdfbc6e-47d5-0c52-08b7-b8de0e4d0857@arm.com>
On Thu, Mar 26, 2020 at 04:14:03PM +0000, Andr? Przywara wrote:
> 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.
Thanks.
> 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.
initrd_high is the other "do not relocate" variable. For anything else,
yes, matching other platforms so that distro boot can be used at some
point (I assume it's not on Juno today) would be good.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200326/d2eb1be5/attachment.sig>
next prev parent reply other threads:[~2020-03-26 16:18 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
2020-03-26 16:18 ` Tom Rini [this message]
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=20200326161829.GZ5793@bill-the-cat \
--to=trini@konsulko.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