This series try to address a long lasting problem with legacy device
that require an appended DTB and the use of AUTO_ZRELADDR.
With these device AUTO_ZRELADDR is not possible if for some reason at
the start of the RAM it's needed to reserve some space. (example qcom SoC
that allocate reserved space for SMEM)
In the current implementation with appended DTB and AUTO_ZRELADDR,
the memory start is only derived from the PC register and it can't be
changed by declaring additional info in the DTS.
In a normal setup, we have an intentional undocumented chosen property
to handle this and the memory node to declare the start of the memory.
With this applied and ARM_ATAG_DTB_COMPAT_IGNORE_MEM enabled (more
info in the related patch) ipq806x can boot right away with AUTO_ZRELADDR
enabled and a correct memory node defined in DTS.
It's needed to ignore MEM ATAGs as most of the time the values from the
bootloader are hardcoded and OEM didn't care to actually provide them
resulting in funny situation where a Netgear R7800 with 512Mb of RAM
have Uboot passing 1.7GB of RAM with ATAGS.
While MEM ATAG may be broken, other ATAG like serial number or bootargs
might still be useful for partition declaration (cmdlinepart) or other
info hence DTB_COMPAT is still needed in these case and can't be
disabled.
I'm open to any suggestion on how this can be improved and I would love
some additional testing on other legacy platform but I assume this will
permit many legacy device to be correctly supported without having to
hardcode address.
Changes v2:
- Add Review and Ack Tags
- Use IS_ENABLED instead of global variable
Christian Marangi (2):
ARM: decompressor: support memory start validation for appended DTB
ARM: decompressor: add option to ignore MEM ATAGs
arch/arm/Kconfig | 12 ++++++++++++
arch/arm/boot/compressed/atags_to_fdt.c | 4 ++++
arch/arm/boot/compressed/head.S | 22 ++++++++++++++++++++++
3 files changed, 38 insertions(+)
--
2.43.0
There is currently a problem with a very specific sets of kernel config
and AUTO_ZRELADDR.
For the most common case AUTO_ZRELADDR check the PC register and
calculate the start of the physical memory. Then fdt_check_mem_start is
called to make sure the detected value makes sense by comparing it with
what is present in DTB in the memory nodes and if additional fixup are
required with the use of linux,usable-memory-range in the chosen node to
hardcode usable memory range in case some reserved space needs to be
addressed. With the help of this function the right address is
calculated and the kernel correctly decompress and loads.
Things starts to become problematic when in the mix,
CONFIG_ARM_APPENDED_DTB is used. This is a particular kernel config is
used when legacy systems doesn't support passing a DTB directly and a
DTB is appended at the end of the image.
In such case, fdt_check_mem_start is skipped in AUTO_ZRELADDR iteration
as the appended DTB can be augumented later with ATAGS passed from the
bootloader (if CONFIG_ARM_ATAG_DTB_COMPAT is enabled).
The main problem and what this patch address is the fact that
fdt_check_mem_start is never called later when the appended DTB is
augumented, hence any fixup and validation is not done making AUTO_ZRELADDR
detection inconsistent and most of the time wrong.
Add support in head.S for this by checking if AUTO_ZRELADDR is enabled
and calling fdt_check_mem_start with the appended DTB and the augumented
values permitting legacy device to provide info in DTB instead of
disabling AUTO_ZRELADDR and hardcoding the physical address offsets.
Signed-off-by: Christian Marangi <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
---
arch/arm/boot/compressed/head.S | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 9f406e9c0ea6..2ff38a8df1f0 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -443,6 +443,28 @@ restart: adr r0, LC1
add r6, r6, r5
add r10, r10, r5
add sp, sp, r5
+
+#ifdef CONFIG_AUTO_ZRELADDR
+ /*
+ * Validate calculated start of physical memory with appended DTB.
+ * In the first iteration for physical memory start calculation,
+ * we skipped validating it as it could have been augumented by
+ * ATAGs stored at an offset from the same start of physical memory.
+ *
+ * We now have parsed them and augumented the appended DTB if asked
+ * so we can finally validate the start of physical memory.
+ *
+ * This is needed to apply additional fixup with
+ * linux,usable-memory-range or to make sure AUTO_ZRELADDR detected
+ * the correct value.
+ */
+ sub r0, r4, #TEXT_OFFSET @ revert to base address
+ mov r1, r8 @ use appended DTB
+ bl fdt_check_mem_start
+
+ /* Determine final kernel image address. */
+ add r4, r0, #TEXT_OFFSET
+#endif
dtb_check_done:
#endif
--
2.43.0
Some bootloaders can pass broken MEM ATAGs that provide hardcoded
information about mounted RAM size and physical location.
Example booloader provide RAM of size 1.7Gb but actual mounted RAM
size is 512Mb causing kernel panic.
Add option CONFIG_ARM_ATAG_DTB_COMPAT_IGNORE_MEM to ignore these ATAG
and not augument appended DTB memory node.
Signed-off-by: Christian Marangi <[email protected]>
Acked-by: Linus Walleij <[email protected]>
---
arch/arm/Kconfig | 12 ++++++++++++
arch/arm/boot/compressed/atags_to_fdt.c | 4 ++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b2ab8db63c4b..6bb5c6b28106 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1549,6 +1549,18 @@ config ARM_ATAG_DTB_COMPAT
bootloaders, this option allows zImage to extract the information
from the ATAG list and store it at run time into the appended DTB.
+config ARM_ATAG_DTB_COMPAT_IGNORE_MEM
+ bool "Ignore MEM ATAG information from bootloader"
+ depends on ARM_ATAG_DTB_COMPAT
+ help
+ Some bootloaders can pass broken MEM ATAGs that provide hardcoded
+ information about mounted RAM size and physical location.
+ Example booloader provide RAM of size 1.7Gb but actual mounted RAM
+ size is 512Mb causing kernel panic.
+
+ Enable this option if MEM ATAGs should be ignored and the memory
+ node in the appended DTB should NOT be augumented.
+
choice
prompt "Kernel command line type" if ARM_ATAG_DTB_COMPAT
default ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER
diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
index 627752f18661..b5bce4dad321 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -170,6 +170,10 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
setprop_string(fdt, "/chosen", "bootargs",
atag->u.cmdline.cmdline);
} else if (atag->hdr.tag == ATAG_MEM) {
+ /* Bootloader MEM ATAG are broken and should be ignored */
+ if (IS_ENABLED(CONFIG_ARM_ATAG_DTB_COMPAT_IGNORE_MEM))
+ continue;
+
if (memcount >= sizeof(mem_reg_property)/4)
continue;
if (!atag->u.mem.size)
--
2.43.0
On Sun, Jan 21, 2024 at 09:29:32PM +0100, Christian Marangi wrote:
> This series try to address a long lasting problem with legacy device
> that require an appended DTB and the use of AUTO_ZRELADDR.
>
> With these device AUTO_ZRELADDR is not possible if for some reason at
> the start of the RAM it's needed to reserve some space. (example qcom SoC
> that allocate reserved space for SMEM)
>
> In the current implementation with appended DTB and AUTO_ZRELADDR,
> the memory start is only derived from the PC register and it can't be
> changed by declaring additional info in the DTS.
>
> In a normal setup, we have an intentional undocumented chosen property
> to handle this and the memory node to declare the start of the memory.
>
> With this applied and ARM_ATAG_DTB_COMPAT_IGNORE_MEM enabled (more
> info in the related patch) ipq806x can boot right away with AUTO_ZRELADDR
> enabled and a correct memory node defined in DTS.
>
> It's needed to ignore MEM ATAGs as most of the time the values from the
> bootloader are hardcoded and OEM didn't care to actually provide them
> resulting in funny situation where a Netgear R7800 with 512Mb of RAM
> have Uboot passing 1.7GB of RAM with ATAGS.
>
> While MEM ATAG may be broken, other ATAG like serial number or bootargs
> might still be useful for partition declaration (cmdlinepart) or other
> info hence DTB_COMPAT is still needed in these case and can't be
> disabled.
>
> I'm open to any suggestion on how this can be improved and I would love
> some additional testing on other legacy platform but I assume this will
> permit many legacy device to be correctly supported without having to
> hardcode address.
>
> Changes v2:
> - Add Review and Ack Tags
> - Use IS_ENABLED instead of global variable
>
> Christian Marangi (2):
> ARM: decompressor: support memory start validation for appended DTB
> ARM: decompressor: add option to ignore MEM ATAGs
>
> arch/arm/Kconfig | 12 ++++++++++++
> arch/arm/boot/compressed/atags_to_fdt.c | 4 ++++
> arch/arm/boot/compressed/head.S | 22 ++++++++++++++++++++++
> 3 files changed, 38 insertions(+)
>
>
Any news for this?
--
Ansuel
On Wed, Feb 21, 2024 at 5:57 PM Christian Marangi <ansuelsmth@gmailcom> wrote:
> Any news for this?
Can you please put the patches into Russell's patch tracker so he can
apply them?
https://www.arm.linux.org.uk/developer/patches/
If you run into any problems, ping me on IRC and I'll help out.
Yours,
Linus Walleij
On Thu, Feb 22, 2024 at 01:07:56PM +0100, Linus Walleij wrote:
> On Wed, Feb 21, 2024 at 5:57 PM Christian Marangi <[email protected]> wrote:
>
> > Any news for this?
>
> Can you please put the patches into Russell's patch tracker so he can
> apply them?
> https://www.arm.linux.org.uk/developer/patches/
>
> If you run into any problems, ping me on IRC and I'll help out.
>
God I totally missed this email where I had to put the 2 patch in the
tracking system. Just did now... my bad!
--
Ansuel
On Wed, Feb 21, 2024 at 05:57:00PM +0100, Christian Marangi wrote:
> On Sun, Jan 21, 2024 at 09:29:32PM +0100, Christian Marangi wrote:
> > This series try to address a long lasting problem with legacy device
> > that require an appended DTB and the use of AUTO_ZRELADDR.
> >
> > With these device AUTO_ZRELADDR is not possible if for some reason at
> > the start of the RAM it's needed to reserve some space. (example qcom SoC
> > that allocate reserved space for SMEM)
> >
> > In the current implementation with appended DTB and AUTO_ZRELADDR,
> > the memory start is only derived from the PC register and it can't be
> > changed by declaring additional info in the DTS.
> >
> > In a normal setup, we have an intentional undocumented chosen property
> > to handle this and the memory node to declare the start of the memory.
> >
> > With this applied and ARM_ATAG_DTB_COMPAT_IGNORE_MEM enabled (more
> > info in the related patch) ipq806x can boot right away with AUTO_ZRELADDR
> > enabled and a correct memory node defined in DTS.
> >
> > It's needed to ignore MEM ATAGs as most of the time the values from the
> > bootloader are hardcoded and OEM didn't care to actually provide them
> > resulting in funny situation where a Netgear R7800 with 512Mb of RAM
> > have Uboot passing 1.7GB of RAM with ATAGS.
> >
> > While MEM ATAG may be broken, other ATAG like serial number or bootargs
> > might still be useful for partition declaration (cmdlinepart) or other
> > info hence DTB_COMPAT is still needed in these case and can't be
> > disabled.
> >
> > I'm open to any suggestion on how this can be improved and I would love
> > some additional testing on other legacy platform but I assume this will
> > permit many legacy device to be correctly supported without having to
> > hardcode address.
> >
> > Changes v2:
> > - Add Review and Ack Tags
> > - Use IS_ENABLED instead of global variable
> >
> > Christian Marangi (2):
> > ARM: decompressor: support memory start validation for appended DTB
> > ARM: decompressor: add option to ignore MEM ATAGs
> >
> > arch/arm/Kconfig | 12 ++++++++++++
> > arch/arm/boot/compressed/atags_to_fdt.c | 4 ++++
> > arch/arm/boot/compressed/head.S | 22 ++++++++++++++++++++++
> > 3 files changed, 38 insertions(+)
> >
> >
>
> Any news for this?
Sorry for asking again... but any news for this?
I have also added the 2 patch here [1] [2].
Been in incoming from a long time and I have seen other patch getting
accepted. Did I do something wrong in submitting the 2 patch?
[1] https://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=9394/1
[2] https://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=9395/1
--
Ansuel
On Thu, Jun 13, 2024 at 1:24 PM Christian Marangi <[email protected]> wrote:
> Sorry for asking again... but any news for this?
>
> I have also added the 2 patch here [1] [2].
>
> Been in incoming from a long time and I have seen other patch getting
> accepted. Did I do something wrong in submitting the 2 patch?
Hm Russell must have had some concerns, Russell?
If for nothing else I think some Tested-by:s would be appreciated,
do we have some people who use this that can provide Tested-by
tags?
I would rebase on v6.10-rc1 and mark the old versions as superseded
in any case so it is clear it will merge fine.
Yours,
Linus Walleij
On Thu, Jun 13, 2024 at 03:50:58PM +0200, Linus Walleij wrote:
> On Thu, Jun 13, 2024 at 1:24 PM Christian Marangi <[email protected]> wrote:
>
> > Sorry for asking again... but any news for this?
> >
> > I have also added the 2 patch here [1] [2].
> >
> > Been in incoming from a long time and I have seen other patch getting
> > accepted. Did I do something wrong in submitting the 2 patch?
>
> Hm Russell must have had some concerns, Russell?
I've been snowed under for about the last six weeks - with only the
occasional day that isn't silly. It's that kind of frustrating snowed
under where each problem is a bit like a brick wall placed every 1m
and you're supposed to be doing a 100m sprint race - you can't see
the next brick wall until you've climbed over the first.
Whether I have time to read the mailing lists or not depends entirely
on what is happening on any particular day.
> If for nothing else I think some Tested-by:s would be appreciated,
> do we have some people who use this that can provide Tested-by
> tags?
Yes, tested-by's would be a really good idea, because my gut feeling
is that this change has moderate risk of causing regressions. I'm
not talking about "it works for me on the setup it's intended for"
I'm talking about other platforms.
I'm also wondering about distros, and what they're supposed to do
with the config option with their "universal" kernel that's
supposed to boot across as many platforms as possible, what they
should set the config option to, and what impact it has when enabled
on platforms that it isn't originally intended for.
I haven't really read much of the patch because I've been so busy,
so I may be being overly cautious. Given that I am quite busy, I
would appreciate a summary of the situation rather than being fed
with lots of results! In other words, the tested-bys, and "it works
on all the xyz platforms that we've testsed, nothing appears to have
regressed" would be ideal.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Sun, Jan 21, 2024 at 9:30 PM Christian Marangi <[email protected]> wrote:
> There is currently a problem with a very specific sets of kernel config
> and AUTO_ZRELADDR.
>
> For the most common case AUTO_ZRELADDR check the PC register and
> calculate the start of the physical memory. Then fdt_check_mem_start is
> called to make sure the detected value makes sense by comparing it with
> what is present in DTB in the memory nodes and if additional fixup are
> required with the use of linux,usable-memory-range in the chosen node to
> hardcode usable memory range in case some reserved space needs to be
> addressed. With the help of this function the right address is
> calculated and the kernel correctly decompress and loads.
>
> Things starts to become problematic when in the mix,
> CONFIG_ARM_APPENDED_DTB is used. This is a particular kernel config is
> used when legacy systems doesn't support passing a DTB directly and a
> DTB is appended at the end of the image.
>
> In such case, fdt_check_mem_start is skipped in AUTO_ZRELADDR iteration
> as the appended DTB can be augumented later with ATAGS passed from the
> bootloader (if CONFIG_ARM_ATAG_DTB_COMPAT is enabled).
>
> The main problem and what this patch address is the fact that
> fdt_check_mem_start is never called later when the appended DTB is
> augumented, hence any fixup and validation is not done making AUTO_ZRELADDR
> detection inconsistent and most of the time wrong.
>
> Add support in head.S for this by checking if AUTO_ZRELADDR is enabled
> and calling fdt_check_mem_start with the appended DTB and the augumented
> values permitting legacy device to provide info in DTB instead of
> disabling AUTO_ZRELADDR and hardcoding the physical address offsets.
>
> Signed-off-by: Christian Marangi <[email protected]>
> Reviewed-by: Geert Uytterhoeven <[email protected]>
> Reviewed-by: Linus Walleij <[email protected]>
I have been including this series in my local tree for a few months,
and so far no regressions on any of the Renesas ARM32 platforms
I regularly test on.
Tested-by: Geert Uytterhoeven <[email protected]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Jun 13, 2024 at 04:59:49PM +0100, Russell King (Oracle) wrote:
> On Thu, Jun 13, 2024 at 03:50:58PM +0200, Linus Walleij wrote:
> > On Thu, Jun 13, 2024 at 1:24 PM Christian Marangi <[email protected]> wrote:
> >
> > > Sorry for asking again... but any news for this?
> > >
> > > I have also added the 2 patch here [1] [2].
> > >
> > > Been in incoming from a long time and I have seen other patch getting
> > > accepted. Did I do something wrong in submitting the 2 patch?
> >
> > Hm Russell must have had some concerns, Russell?
>
> I've been snowed under for about the last six weeks - with only the
> occasional day that isn't silly. It's that kind of frustrating snowed
> under where each problem is a bit like a brick wall placed every 1m
> and you're supposed to be doing a 100m sprint race - you can't see
> the next brick wall until you've climbed over the first.
>
> Whether I have time to read the mailing lists or not depends entirely
> on what is happening on any particular day.
>
> > If for nothing else I think some Tested-by:s would be appreciated,
> > do we have some people who use this that can provide Tested-by
> > tags?
>
> Yes, tested-by's would be a really good idea, because my gut feeling
> is that this change has moderate risk of causing regressions. I'm
> not talking about "it works for me on the setup it's intended for"
> I'm talking about other platforms.
>
> I'm also wondering about distros, and what they're supposed to do
> with the config option with their "universal" kernel that's
> supposed to boot across as many platforms as possible, what they
> should set the config option to, and what impact it has when enabled
> on platforms that it isn't originally intended for.
>
> I haven't really read much of the patch because I've been so busy,
> so I may be being overly cautious. Given that I am quite busy, I
> would appreciate a summary of the situation rather than being fed
> with lots of results! In other words, the tested-bys, and "it works
> on all the xyz platforms that we've testsed, nothing appears to have
> regressed" would be ideal.
>
The current patch are used downstream on the OpenWrt ipq806x target that
is a mix of legacy (what this affects) and non legacy targets. (old
bootloader support loading DTB from the image and older ones require it
to be appended)
I think I need some help from the community to test this.
I can also move these patches to our "generic" target on OpenWrt so that
they will be enabled by every arm target we support.
Anyway thanks for the feedback, my only concern was that I messed
submitting the patch on the tracking system. Hope community can help
with this since it's a big feature for legacy devices that was broken
from a looong time (and only solution currently is to hardcode the PHY
offset values)
--
Ansuel