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

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 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 <ansuelsmth@gmail.com> 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 <ansuelsmth@gmail.com> 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 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 <ansuelsmth@gmail.com> 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

Hi Christian,

Trying to revive this thread...

On Thu, 13 Jun 2024 at 18:51, Christian Marangi <ansuelsmth@gmail.com> wrote:
> 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 <ansuelsmth@gmail.com> 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)

FTR, I did provide my Tested-by for the first patch in [1].
I still have this series in my local tree, which I test regularly on
a variety of Renesas ARM32 platforms and on BeagleBone Black.

In fact, I had completely forgotten about this series, to the point
that I bisected a failure in booting mainline on one of my boards
using my current .config to the absence of the first patch ;-)
Apparently during the past years, I had modified my .config to make it
more generic, and make better use of the DTB (incl. chosen/bootargs),
which has a dependency on the first patch...

The second patch is a different story (I don't need it ;-), and enabling
the option may indeed not be suitable for distro kernels.

Thank you!

[1] https://lore.kernel.org/CAMuHMdX0dpQdZSCJGuOM0MgM3N-8OA29skARvXEkm87eOPEWBA@mail.gmail.com

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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 Mon, Feb 02, 2026 at 11:26:49AM +0100, Geert Uytterhoeven wrote:
> FTR, I did provide my Tested-by for the first patch in [1].
> I still have this series in my local tree, which I test regularly on
> a variety of Renesas ARM32 platforms and on BeagleBone Black.
> 
> In fact, I had completely forgotten about this series, to the point
> that I bisected a failure in booting mainline on one of my boards
> using my current .config to the absence of the first patch ;-)
> Apparently during the past years, I had modified my .config to make it
> more generic, and make better use of the DTB (incl. chosen/bootargs),
> which has a dependency on the first patch...

What I would like to know is why anyone is using appended DTBs in this
day and age, when surely by now, Arm based boot loaders have realised
that Arm moved to use device trees ages ago, and the kernel requires
a DTB in addition to the kernel image itself.

Appended DTB support was only there as a stop-gap for those boot
loaders that were around before DTB support was added, and have no
capability of dealing with a separate DTB.

Come on. It's 2026. DTB has been supported on 32-bit ARM for fifteen
years. Surely everyone's now got modern boot loaders.

If not, it's time to say this: fix the boot loader.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Il giorno lun 2 feb 2026 alle ore 11:58 Russell King (Oracle)
<linux@armlinux.org.uk> ha scritto:
>
> On Mon, Feb 02, 2026 at 11:26:49AM +0100, Geert Uytterhoeven wrote:
> > FTR, I did provide my Tested-by for the first patch in [1].
> > I still have this series in my local tree, which I test regularly on
> > a variety of Renesas ARM32 platforms and on BeagleBone Black.
> >
> > In fact, I had completely forgotten about this series, to the point
> > that I bisected a failure in booting mainline on one of my boards
> > using my current .config to the absence of the first patch ;-)
> > Apparently during the past years, I had modified my .config to make it
> > more generic, and make better use of the DTB (incl. chosen/bootargs),
> > which has a dependency on the first patch...
>
> What I would like to know is why anyone is using appended DTBs in this
> day and age, when surely by now, Arm based boot loaders have realised
> that Arm moved to use device trees ages ago, and the kernel requires
> a DTB in addition to the kernel image itself.
>
> Appended DTB support was only there as a stop-gap for those boot
> loaders that were around before DTB support was added, and have no
> capability of dealing with a separate DTB.
>
> Come on. It's 2026. DTB has been supported on 32-bit ARM for fifteen
> years. Surely everyone's now got modern boot loaders.
>
> If not, it's time to say this: fix the boot loader.
>

The main problem is that sometimes it's not possible to update the bootloader
at all. Either they never provided the source or Uboot is not even used.

And on some device updating the bootloader is risky as you would end up
in a brick. (no way to recover it)

Also other case usually sign the bootloader and permit to load whatever
image you want so also problematic to update the bootloader.

Sadly for these device, it's full of corner situation where the Vendor used
a badly configured SDK and made a single bootloader on it.

For example QCOM Uboot SDK still target ancient 2012 version if I'm not
wrong.

On Mon, 02 Feb 2026 11:03:24 +0000,
"Christian Marangi (Ansuel)" <ansuelsmth@gmail.com> wrote:
> 
> Il giorno lun 2 feb 2026 alle ore 11:58 Russell King (Oracle)
> <linux@armlinux.org.uk> ha scritto:
> >
> > On Mon, Feb 02, 2026 at 11:26:49AM +0100, Geert Uytterhoeven wrote:
> > > FTR, I did provide my Tested-by for the first patch in [1].
> > > I still have this series in my local tree, which I test regularly on
> > > a variety of Renesas ARM32 platforms and on BeagleBone Black.
> > >
> > > In fact, I had completely forgotten about this series, to the point
> > > that I bisected a failure in booting mainline on one of my boards
> > > using my current .config to the absence of the first patch ;-)
> > > Apparently during the past years, I had modified my .config to make it
> > > more generic, and make better use of the DTB (incl. chosen/bootargs),
> > > which has a dependency on the first patch...
> >
> > What I would like to know is why anyone is using appended DTBs in this
> > day and age, when surely by now, Arm based boot loaders have realised
> > that Arm moved to use device trees ages ago, and the kernel requires
> > a DTB in addition to the kernel image itself.
> >
> > Appended DTB support was only there as a stop-gap for those boot
> > loaders that were around before DTB support was added, and have no
> > capability of dealing with a separate DTB.
> >
> > Come on. It's 2026. DTB has been supported on 32-bit ARM for fifteen
> > years. Surely everyone's now got modern boot loaders.
> >
> > If not, it's time to say this: fix the boot loader.
> >
> 
> The main problem is that sometimes it's not possible to update the bootloader
> at all. Either they never provided the source or Uboot is not even used.
> 
> And on some device updating the bootloader is risky as you would end up
> in a brick. (no way to recover it)
> 
> Also other case usually sign the bootloader and permit to load whatever
> image you want so also problematic to update the bootloader.
> 
> Sadly for these device, it's full of corner situation where the Vendor used
> a badly configured SDK and made a single bootloader on it.
> 
> For example QCOM Uboot SDK still target ancient 2012 version if I'm not
> wrong.

If you can boot the kernel, you can also boot a secondary bootloader
that will do the right thing by exposing a DT. Fixing the boot flow
should be the priority, rather than adding more band-aids to the
kernel.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

On Mon, Feb 2, 2026 at 12:11 PM Marc Zyngier <maz@kernel.org> wrote:

> If you can boot the kernel, you can also boot a secondary bootloader
> that will do the right thing by exposing a DT. Fixing the boot flow
> should be the priority, rather than adding more band-aids to the
> kernel.

I have used this approach with some Broadcom machines equipped
with the CFE thing they are using. I have that boot U-Boot and
U-boot boots the kernel. Works fine.

However, I think it is a thick requirement to put on hobbyist
contributors to go and write entite boot loaders from scratch,
I think it's a fine requirement to put on Qualcomm or Renesas
paid maintainers.

Another reason would be that appended DTB is in the same
league as the GPIO sysfs despite we GPIO maintainers hate it:
a feature users highly desire because it's easy and convenient
and practical and quick and thus refuse to let us drop. Every time
we try to deprecate it more we get a good beating.

Yours,
Linus Walleij

Linus,

On Wed, 04 Feb 2026 00:36:29 +0000,
Linus Walleij <linusw@kernel.org> wrote:
> 
> On Mon, Feb 2, 2026 at 12:11 PM Marc Zyngier <maz@kernel.org> wrote:
> 
> > If you can boot the kernel, you can also boot a secondary bootloader
> > that will do the right thing by exposing a DT. Fixing the boot flow
> > should be the priority, rather than adding more band-aids to the
> > kernel.
> 
> I have used this approach with some Broadcom machines equipped
> with the CFE thing they are using. I have that boot U-Boot and
> U-boot boots the kernel. Works fine.
> 
> However, I think it is a thick requirement to put on hobbyist
> contributors to go and write entite boot loaders from scratch,
> I think it's a fine requirement to put on Qualcomm or Renesas
> paid maintainers.

It really isn't a large requirement, and you don't have to write a
full bootloader. All you need is a small shim that wraps the kernel
and enters it as it currently expects. You can even have that as a
separate binary that is loaded independently of the kernel.

Yes, this is an extra bit to carry outside of the kernel itself, and
extra stuff to package for generic distros, but appended DTB is
already a blocker for those.

> Another reason would be that appended DTB is in the same
> league as the GPIO sysfs despite we GPIO maintainers hate it:
> a feature users highly desire because it's easy and convenient
> and practical and quick and thus refuse to let us drop. Every time
> we try to deprecate it more we get a good beating.

I don't think appended DTB is ABI. The GPIO sysfs definitely is.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

On Wed, Feb 4, 2026 at 10:24 AM Marc Zyngier <maz@kernel.org> wrote:

> > Another reason would be that appended DTB is in the same
> > league as the GPIO sysfs despite we GPIO maintainers hate it:
> > a feature users highly desire because it's easy and convenient
> > and practical and quick and thus refuse to let us drop. Every time
> > we try to deprecate it more we get a good beating.
>
> I don't think appended DTB is ABI. The GPIO sysfs definitely is.

The reason the GPIO sysfs is demanded is not so much because
of ABI, like if applications are using it.

It's more about developers wanting to play with their systems
interactively to figure things out or do makerspace projects
using GPIO.

Likewise I think appended DTB is appealing to developers because...
"it boots, ship it". ;)

Yours,
Linus Walleij

On Wed, Feb 04, 2026 at 10:49:24AM +0100, Linus Walleij wrote:
> On Wed, Feb 4, 2026 at 10:24 AM Marc Zyngier <maz@kernel.org> wrote:
> 
> > > Another reason would be that appended DTB is in the same
> > > league as the GPIO sysfs despite we GPIO maintainers hate it:
> > > a feature users highly desire because it's easy and convenient
> > > and practical and quick and thus refuse to let us drop. Every time
> > > we try to deprecate it more we get a good beating.
> >
> > I don't think appended DTB is ABI. The GPIO sysfs definitely is.
> 
> The reason the GPIO sysfs is demanded is not so much because
> of ABI, like if applications are using it.
> 
> It's more about developers wanting to play with their systems
> interactively to figure things out or do makerspace projects
> using GPIO.
> 
> Likewise I think appended DTB is appealing to developers because...
> "it boots, ship it". ;)

Right, but what we have in the kernel works for those platforms that
it has been needed for. That's what it was for - a stop-gap for
transitioning 32-bit ARM to DT. It shouldn't be extended to new
platforms.

No one answered my question whether there was a regression or whether
this was for new platforms. Given that lack of engagement, I'm just
going to say a flat NO to this, since we don't seem to be able to
communicate effectively.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

On Wed, Feb 04, 2026 at 01:36:29AM +0100, Linus Walleij wrote:
> However, I think it is a thick requirement to put on hobbyist
> contributors to go and write entite boot loaders from scratch,
> I think it's a fine requirement to put on Qualcomm or Renesas
> paid maintainers.

If we're talking about older boards, then why have they only recently
became a problem, when, presumably, they've been working fine for a
decade or so?

If we're talking about more modern boards, then I have zero sympathy.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Hi Russell,

On Wed, 4 Feb 2026 at 02:27, Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
> On Wed, Feb 04, 2026 at 01:36:29AM +0100, Linus Walleij wrote:
> > However, I think it is a thick requirement to put on hobbyist
> > contributors to go and write entite boot loaders from scratch,
> > I think it's a fine requirement to put on Qualcomm or Renesas
> > paid maintainers.
>
> If we're talking about older boards, then why have they only recently
> became a problem, when, presumably, they've been working fine for a
> decade or so?

These boards may have been working fine, given the right "legacy"
kernel config options were used.  However, some of these option make
the resulting kernel limited to that platform or even to a specific
board (e.g. when CONFIG_CMDLINE needs to be used).

The KZM-A9-GT I "need" this for never had upstream U-Boot (I don't
think I ever had any U-Boot sources).  I can boot a shmobile_defconfig
multi-platform kernel[*] fine, iff the first patch is applied.

[*] I mean vmlinux, as the actual image used for booting will still be
    different (uImage/zImage with/without appended DTB).

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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 Wed, Feb 04, 2026 at 11:53:30AM +0100, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Wed, 4 Feb 2026 at 02:27, Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> > On Wed, Feb 04, 2026 at 01:36:29AM +0100, Linus Walleij wrote:
> > > However, I think it is a thick requirement to put on hobbyist
> > > contributors to go and write entite boot loaders from scratch,
> > > I think it's a fine requirement to put on Qualcomm or Renesas
> > > paid maintainers.
> >
> > If we're talking about older boards, then why have they only recently
> > became a problem, when, presumably, they've been working fine for a
> > decade or so?
> 
> These boards may have been working fine, given the right "legacy"
> kernel config options were used.  However, some of these option make
> the resulting kernel limited to that platform or even to a specific
> board (e.g. when CONFIG_CMDLINE needs to be used).

The 32-git ARM kernel has had a way to pass the command line to the
kernel from the boot loader since day one.

	First it was the struct param_struct.
	Then it was the ATAGs that was introduced pre-git.
	Now it is DT.

The kernel retains code to parse all three methods of passing data
from the boot loader to the kernel. The decompressor has support
for merging the ATAGs into the appended DTB, which includes merging
the command line into the DTB.

Without an appended DTB, the pointer to one of the above will be
passed to the kernel, the kernel will figure out what it has and
parse one of the three ways, and use the command line there.

The only case where CONFIG_CMDLINE should be used is when there is
no command line passed, no way to change it, etc. At that point
there are two options:

1. Augment the kernel's generated FDT with the command line node
   and load that modified FDT or append it to the compressed image.

2. Use CONFIG_CMDLINE, which means that the kernel _will_ become
   specific to the platform that needs those arguments. No getting
   away from that in this case.

Maybe you haven't explained the problem very well, but I don't see
any issue with this.

> The KZM-A9-GT I "need" this for never had upstream U-Boot (I don't
> think I ever had any U-Boot sources).  I can boot a shmobile_defconfig
> multi-platform kernel[*] fine, iff the first patch is applied.

So, what have you been doing for the last 14 years to boot this
platform (merged in 2012) without this patch?

Please explain:

- how it worked before - I want to know how the DTB is passed to the
  kernel, what information is provided from the boot loader, whether
  that gets merged into the DTB, etc. All the fine nitty gritty of
  how it worked and what doesn't work, what the problems were etc.

- what changed (it sounds like you want extra features)

- why (in detail) it doesn't work now.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Hi Russell,

On Wed, 4 Feb 2026 at 12:55, Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
> On Wed, Feb 04, 2026 at 11:53:30AM +0100, Geert Uytterhoeven wrote:
> > On Wed, 4 Feb 2026 at 02:27, Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> > > On Wed, Feb 04, 2026 at 01:36:29AM +0100, Linus Walleij wrote:
> > > > However, I think it is a thick requirement to put on hobbyist
> > > > contributors to go and write entite boot loaders from scratch,
> > > > I think it's a fine requirement to put on Qualcomm or Renesas
> > > > paid maintainers.
> > >
> > > If we're talking about older boards, then why have they only recently
> > > became a problem, when, presumably, they've been working fine for a
> > > decade or so?
> >
> > These boards may have been working fine, given the right "legacy"
> > kernel config options were used.  However, some of these option make
> > the resulting kernel limited to that platform or even to a specific
> > board (e.g. when CONFIG_CMDLINE needs to be used).
>
> The 32-git ARM kernel has had a way to pass the command line to the
> kernel from the boot loader since day one.
>
>         First it was the struct param_struct.
>         Then it was the ATAGs that was introduced pre-git.
>         Now it is DT.
>
> The kernel retains code to parse all three methods of passing data
> from the boot loader to the kernel. The decompressor has support
> for merging the ATAGs into the appended DTB, which includes merging
> the command line into the DTB.
>
> Without an appended DTB, the pointer to one of the above will be
> passed to the kernel, the kernel will figure out what it has and
> parse one of the three ways, and use the command line there.
>
> The only case where CONFIG_CMDLINE should be used is when there is
> no command line passed, no way to change it, etc. At that point
> there are two options:
>
> 1. Augment the kernel's generated FDT with the command line node
>    and load that modified FDT or append it to the compressed image.
>
> 2. Use CONFIG_CMDLINE, which means that the kernel _will_ become
>    specific to the platform that needs those arguments. No getting
>    away from that in this case.
>
> Maybe you haven't explained the problem very well, but I don't see
> any issue with this.

I am fully aware I didn't explain it sufficiently, but I don't remember
all the details.  The important part is that I never got the kernel
commandline passing from U-Boot env to the kernel to work on KZM-A9-GT,
until after I had applied "[PATCH v2 1/2] ARM: decompressor: support
memory start validation for appended DTB".
And without that patch, my current .config no longer boots.

> > The KZM-A9-GT I "need" this for never had upstream U-Boot (I don't
> > think I ever had any U-Boot sources).  I can boot a shmobile_defconfig
> > multi-platform kernel[*] fine, iff the first patch is applied.
>
> So, what have you been doing for the last 14 years to boot this
> platform (merged in 2012) without this patch?
>
> Please explain:
>
> - how it worked before - I want to know how the DTB is passed to the
>   kernel, what information is provided from the boot loader, whether
>   that gets merged into the DTB, etc. All the fine nitty gritty of
>   how it worked and what doesn't work, what the problems were etc.
>
> - what changed (it sounds like you want extra features)
>
> - why (in detail) it doesn't work now.

I'll add this investigation to my (too long) list of TODOs (so I may
or may not get to it this decade ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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 Wed, Feb 04, 2026 at 11:54:59AM +0000, Russell King (Oracle) wrote:
> On Wed, Feb 04, 2026 at 11:53:30AM +0100, Geert Uytterhoeven wrote:
> > Hi Russell,
> > 
> > On Wed, 4 Feb 2026 at 02:27, Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> > > On Wed, Feb 04, 2026 at 01:36:29AM +0100, Linus Walleij wrote:
> > > > However, I think it is a thick requirement to put on hobbyist
> > > > contributors to go and write entite boot loaders from scratch,
> > > > I think it's a fine requirement to put on Qualcomm or Renesas
> > > > paid maintainers.
> > >
> > > If we're talking about older boards, then why have they only recently
> > > became a problem, when, presumably, they've been working fine for a
> > > decade or so?
> > 
> > These boards may have been working fine, given the right "legacy"
> > kernel config options were used.  However, some of these option make
> > the resulting kernel limited to that platform or even to a specific
> > board (e.g. when CONFIG_CMDLINE needs to be used).
> 
> The 32-git ARM kernel has had a way to pass the command line to the
> kernel from the boot loader since day one.
> 
> 	First it was the struct param_struct.
> 	Then it was the ATAGs that was introduced pre-git.
> 	Now it is DT.
> 
> The kernel retains code to parse all three methods of passing data
> from the boot loader to the kernel. The decompressor has support
> for merging the ATAGs into the appended DTB, which includes merging
> the command line into the DTB.
> 
> Without an appended DTB, the pointer to one of the above will be
> passed to the kernel, the kernel will figure out what it has and
> parse one of the three ways, and use the command line there.
> 
> The only case where CONFIG_CMDLINE should be used is when there is
> no command line passed, no way to change it, etc. At that point
> there are two options:
> 
> 1. Augment the kernel's generated FDT with the command line node
>    and load that modified FDT or append it to the compressed image.
> 
> 2. Use CONFIG_CMDLINE, which means that the kernel _will_ become
>    specific to the platform that needs those arguments. No getting
>    away from that in this case.
> 
> Maybe you haven't explained the problem very well, but I don't see
> any issue with this.
> 
> > The KZM-A9-GT I "need" this for never had upstream U-Boot (I don't
> > think I ever had any U-Boot sources).  I can boot a shmobile_defconfig
> > multi-platform kernel[*] fine, iff the first patch is applied.
> 
> So, what have you been doing for the last 14 years to boot this
> platform (merged in 2012) without this patch?
> 
> Please explain:
> 
> - how it worked before - I want to know how the DTB is passed to the
>   kernel, what information is provided from the boot loader, whether
>   that gets merged into the DTB, etc. All the fine nitty gritty of
>   how it worked and what doesn't work, what the problems were etc.
> 
> - what changed (it sounds like you want extra features)
> 
> - why (in detail) it doesn't work now.

I want to know:

- Where RAM is located.
- Where the kernel is being loaded.
- Whether the platform reserves any RAM that may overlap with the kernel
  or where the kernel wants to locate itself in RAM.

From what I can see from arch/arm/boot/dts/renesas/sh73a0-kzm9g.dts,
memory is at 0x4000000..0x5fffffff - 512MiB.

So, provided you load and execute the compressed kernel image within
the first 128Mi of memory (0x40000000 - 0x48000000), then it will select
0x40008000 to decompress itself. I can find no mention of any reserved
memory regions in the DT file, so this should be fine.

If you're loading the compressed kernel at some wildly different
address, then yes, it probably won't work.

This is documented in Documentation/arch/arm/booting.rst:

 The zImage may also be placed in system RAM and called there.  The
 kernel should be placed in the first 128MiB of RAM.  It is recommended
 that it is loaded above 32MiB in order to avoid the need to relocate
 prior to decompression, which will make the boot process slightly
 faster.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Hi Russell,

On Wed, 4 Feb 2026 at 13:48, Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
> On Wed, Feb 04, 2026 at 11:54:59AM +0000, Russell King (Oracle) wrote:
> > On Wed, Feb 04, 2026 at 11:53:30AM +0100, Geert Uytterhoeven wrote:
> > > On Wed, 4 Feb 2026 at 02:27, Russell King (Oracle)
> > > <linux@armlinux.org.uk> wrote:
> > > > On Wed, Feb 04, 2026 at 01:36:29AM +0100, Linus Walleij wrote:
> > > > > However, I think it is a thick requirement to put on hobbyist
> > > > > contributors to go and write entite boot loaders from scratch,
> > > > > I think it's a fine requirement to put on Qualcomm or Renesas
> > > > > paid maintainers.
> > > >
> > > > If we're talking about older boards, then why have they only recently
> > > > became a problem, when, presumably, they've been working fine for a
> > > > decade or so?
> > >
> > > These boards may have been working fine, given the right "legacy"
> > > kernel config options were used.  However, some of these option make
> > > the resulting kernel limited to that platform or even to a specific
> > > board (e.g. when CONFIG_CMDLINE needs to be used).
> >
> > The 32-git ARM kernel has had a way to pass the command line to the
> > kernel from the boot loader since day one.
> >
> >       First it was the struct param_struct.
> >       Then it was the ATAGs that was introduced pre-git.
> >       Now it is DT.
> >
> > The kernel retains code to parse all three methods of passing data
> > from the boot loader to the kernel. The decompressor has support
> > for merging the ATAGs into the appended DTB, which includes merging
> > the command line into the DTB.
> >
> > Without an appended DTB, the pointer to one of the above will be
> > passed to the kernel, the kernel will figure out what it has and
> > parse one of the three ways, and use the command line there.
> >
> > The only case where CONFIG_CMDLINE should be used is when there is
> > no command line passed, no way to change it, etc. At that point
> > there are two options:
> >
> > 1. Augment the kernel's generated FDT with the command line node
> >    and load that modified FDT or append it to the compressed image.
> >
> > 2. Use CONFIG_CMDLINE, which means that the kernel _will_ become
> >    specific to the platform that needs those arguments. No getting
> >    away from that in this case.
> >
> > Maybe you haven't explained the problem very well, but I don't see
> > any issue with this.
> >
> > > The KZM-A9-GT I "need" this for never had upstream U-Boot (I don't
> > > think I ever had any U-Boot sources).  I can boot a shmobile_defconfig
> > > multi-platform kernel[*] fine, iff the first patch is applied.
> >
> > So, what have you been doing for the last 14 years to boot this
> > platform (merged in 2012) without this patch?
> >
> > Please explain:
> >
> > - how it worked before - I want to know how the DTB is passed to the
> >   kernel, what information is provided from the boot loader, whether
> >   that gets merged into the DTB, etc. All the fine nitty gritty of
> >   how it worked and what doesn't work, what the problems were etc.
> >
> > - what changed (it sounds like you want extra features)
> >
> > - why (in detail) it doesn't work now.
>
> I want to know:
>
> - Where RAM is located.
> - Where the kernel is being loaded.

tftp 0x43000000 kzm9g/zImage.dtb
bootz

> - Whether the platform reserves any RAM that may overlap with the kernel
>   or where the kernel wants to locate itself in RAM.
>
> From what I can see from arch/arm/boot/dts/renesas/sh73a0-kzm9g.dts,
> memory is at 0x4000000..0x5fffffff - 512MiB.

Correct.

> So, provided you load and execute the compressed kernel image within
> the first 128Mi of memory (0x40000000 - 0x48000000), then it will select
> 0x40008000 to decompress itself. I can find no mention of any reserved
> memory regions in the DT file, so this should be fine.
>
> If you're loading the compressed kernel at some wildly different
> address, then yes, it probably won't work.

It also works when loaded at e.g. 0x42000000 or 0x44000000,
but not at 0x41000000 (all with [PATCH 1/2] applied).

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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 Wed, Feb 04, 2026 at 01:58:21PM +0100, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Wed, 4 Feb 2026 at 13:48, Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> > On Wed, Feb 04, 2026 at 11:54:59AM +0000, Russell King (Oracle) wrote:
> > > On Wed, Feb 04, 2026 at 11:53:30AM +0100, Geert Uytterhoeven wrote:
> > > > On Wed, 4 Feb 2026 at 02:27, Russell King (Oracle)
> > > > <linux@armlinux.org.uk> wrote:
> > > > > On Wed, Feb 04, 2026 at 01:36:29AM +0100, Linus Walleij wrote:
> > > > > > However, I think it is a thick requirement to put on hobbyist
> > > > > > contributors to go and write entite boot loaders from scratch,
> > > > > > I think it's a fine requirement to put on Qualcomm or Renesas
> > > > > > paid maintainers.
> > > > >
> > > > > If we're talking about older boards, then why have they only recently
> > > > > became a problem, when, presumably, they've been working fine for a
> > > > > decade or so?
> > > >
> > > > These boards may have been working fine, given the right "legacy"
> > > > kernel config options were used.  However, some of these option make
> > > > the resulting kernel limited to that platform or even to a specific
> > > > board (e.g. when CONFIG_CMDLINE needs to be used).
> > >
> > > The 32-git ARM kernel has had a way to pass the command line to the
> > > kernel from the boot loader since day one.
> > >
> > >       First it was the struct param_struct.
> > >       Then it was the ATAGs that was introduced pre-git.
> > >       Now it is DT.
> > >
> > > The kernel retains code to parse all three methods of passing data
> > > from the boot loader to the kernel. The decompressor has support
> > > for merging the ATAGs into the appended DTB, which includes merging
> > > the command line into the DTB.
> > >
> > > Without an appended DTB, the pointer to one of the above will be
> > > passed to the kernel, the kernel will figure out what it has and
> > > parse one of the three ways, and use the command line there.
> > >
> > > The only case where CONFIG_CMDLINE should be used is when there is
> > > no command line passed, no way to change it, etc. At that point
> > > there are two options:
> > >
> > > 1. Augment the kernel's generated FDT with the command line node
> > >    and load that modified FDT or append it to the compressed image.
> > >
> > > 2. Use CONFIG_CMDLINE, which means that the kernel _will_ become
> > >    specific to the platform that needs those arguments. No getting
> > >    away from that in this case.
> > >
> > > Maybe you haven't explained the problem very well, but I don't see
> > > any issue with this.
> > >
> > > > The KZM-A9-GT I "need" this for never had upstream U-Boot (I don't
> > > > think I ever had any U-Boot sources).  I can boot a shmobile_defconfig
> > > > multi-platform kernel[*] fine, iff the first patch is applied.
> > >
> > > So, what have you been doing for the last 14 years to boot this
> > > platform (merged in 2012) without this patch?
> > >
> > > Please explain:
> > >
> > > - how it worked before - I want to know how the DTB is passed to the
> > >   kernel, what information is provided from the boot loader, whether
> > >   that gets merged into the DTB, etc. All the fine nitty gritty of
> > >   how it worked and what doesn't work, what the problems were etc.
> > >
> > > - what changed (it sounds like you want extra features)
> > >
> > > - why (in detail) it doesn't work now.
> >
> > I want to know:
> >
> > - Where RAM is located.
> > - Where the kernel is being loaded.
> 
> tftp 0x43000000 kzm9g/zImage.dtb
> bootz
> 
> > - Whether the platform reserves any RAM that may overlap with the kernel
> >   or where the kernel wants to locate itself in RAM.
> >
> > From what I can see from arch/arm/boot/dts/renesas/sh73a0-kzm9g.dts,
> > memory is at 0x4000000..0x5fffffff - 512MiB.
> 
> Correct.
> 
> > So, provided you load and execute the compressed kernel image within
> > the first 128Mi of memory (0x40000000 - 0x48000000), then it will select
> > 0x40008000 to decompress itself. I can find no mention of any reserved
> > memory regions in the DT file, so this should be fine.
> >
> > If you're loading the compressed kernel at some wildly different
> > address, then yes, it probably won't work.
> 
> It also works when loaded at e.g. 0x42000000 or 0x44000000,
> but not at 0x41000000 (all with [PATCH 1/2] applied).

So let's assume the kernel is loaded at 0x43000000.

                mov     r0, pc
                and     r0, r0, #0xf8000000

This will result in r0 being 0x40000000. This becomes the mem_start
argument in fdt_check_mem_start().

We look for an appended DTB, and skip the validation that
fdt_check_mem_start() does. If this were to go ahead, then this would
find that 0x40000000 is within the memory@40000000 node, and thus this
would return "mem_start".

Then:

                /* Determine final kernel image address. */
                add     r4, r0, #TEXT_OFFSET

will place the decompressed kernel at 0x40008000.

However, as placing the kernel at 0x41000000 doesn't boot, that
suggests some memory is being removed from the kernel. If adding a
call to fdt_check_mem_start() after the ATAG-to-FDT parsing has
been performed fixes this, it suggests the ATAGs change this.

So, with a booted kernel, what does:

$ hexdump -e '"%8.8_ax  " 8/4 "%08x " "\n"' /sys/firmware/devicetree/base/memory\@40000000/reg

say? Has this been modified from 00000040 00000020 ? I think it
will be.

That means there's a simple fix: as there is likely reserved memory
at the start of RAM, reflecting that in this platform's .dts would
fix this issue without needing to change the decompressor.

If you don't want to change the reg in the memory@ node, then there's
/chosen/linux,usable-memory-range which can be used to specify the
usable memory base and size (same format as reg).

Another option would be to add linux,usable-memory to the memory@
node that specifies the range of usable memory while still specifying
the full memory range in the reg property.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Hi Russell,

On Wed, 4 Feb 2026 at 14:29, Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
> On Wed, Feb 04, 2026 at 01:58:21PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 4 Feb 2026 at 13:48, Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> > > On Wed, Feb 04, 2026 at 11:54:59AM +0000, Russell King (Oracle) wrote:
> > > > On Wed, Feb 04, 2026 at 11:53:30AM +0100, Geert Uytterhoeven wrote:
> > > > > On Wed, 4 Feb 2026 at 02:27, Russell King (Oracle)
> > > > > <linux@armlinux.org.uk> wrote:
> > > > > > On Wed, Feb 04, 2026 at 01:36:29AM +0100, Linus Walleij wrote:
> > > > > > > However, I think it is a thick requirement to put on hobbyist
> > > > > > > contributors to go and write entite boot loaders from scratch,
> > > > > > > I think it's a fine requirement to put on Qualcomm or Renesas
> > > > > > > paid maintainers.
> > > > > >
> > > > > > If we're talking about older boards, then why have they only recently
> > > > > > became a problem, when, presumably, they've been working fine for a
> > > > > > decade or so?
> > > > >
> > > > > These boards may have been working fine, given the right "legacy"
> > > > > kernel config options were used.  However, some of these option make
> > > > > the resulting kernel limited to that platform or even to a specific
> > > > > board (e.g. when CONFIG_CMDLINE needs to be used).
> > > >
> > > > The 32-git ARM kernel has had a way to pass the command line to the
> > > > kernel from the boot loader since day one.
> > > >
> > > >       First it was the struct param_struct.
> > > >       Then it was the ATAGs that was introduced pre-git.
> > > >       Now it is DT.
> > > >
> > > > The kernel retains code to parse all three methods of passing data
> > > > from the boot loader to the kernel. The decompressor has support
> > > > for merging the ATAGs into the appended DTB, which includes merging
> > > > the command line into the DTB.
> > > >
> > > > Without an appended DTB, the pointer to one of the above will be
> > > > passed to the kernel, the kernel will figure out what it has and
> > > > parse one of the three ways, and use the command line there.
> > > >
> > > > The only case where CONFIG_CMDLINE should be used is when there is
> > > > no command line passed, no way to change it, etc. At that point
> > > > there are two options:
> > > >
> > > > 1. Augment the kernel's generated FDT with the command line node
> > > >    and load that modified FDT or append it to the compressed image.
> > > >
> > > > 2. Use CONFIG_CMDLINE, which means that the kernel _will_ become
> > > >    specific to the platform that needs those arguments. No getting
> > > >    away from that in this case.
> > > >
> > > > Maybe you haven't explained the problem very well, but I don't see
> > > > any issue with this.
> > > >
> > > > > The KZM-A9-GT I "need" this for never had upstream U-Boot (I don't
> > > > > think I ever had any U-Boot sources).  I can boot a shmobile_defconfig
> > > > > multi-platform kernel[*] fine, iff the first patch is applied.
> > > >
> > > > So, what have you been doing for the last 14 years to boot this
> > > > platform (merged in 2012) without this patch?
> > > >
> > > > Please explain:
> > > >
> > > > - how it worked before - I want to know how the DTB is passed to the
> > > >   kernel, what information is provided from the boot loader, whether
> > > >   that gets merged into the DTB, etc. All the fine nitty gritty of
> > > >   how it worked and what doesn't work, what the problems were etc.
> > > >
> > > > - what changed (it sounds like you want extra features)
> > > >
> > > > - why (in detail) it doesn't work now.
> > >
> > > I want to know:
> > >
> > > - Where RAM is located.
> > > - Where the kernel is being loaded.
> >
> > tftp 0x43000000 kzm9g/zImage.dtb
> > bootz
> >
> > > - Whether the platform reserves any RAM that may overlap with the kernel
> > >   or where the kernel wants to locate itself in RAM.
> > >
> > > From what I can see from arch/arm/boot/dts/renesas/sh73a0-kzm9g.dts,
> > > memory is at 0x4000000..0x5fffffff - 512MiB.
> >
> > Correct.
> >
> > > So, provided you load and execute the compressed kernel image within
> > > the first 128Mi of memory (0x40000000 - 0x48000000), then it will select
> > > 0x40008000 to decompress itself. I can find no mention of any reserved
> > > memory regions in the DT file, so this should be fine.
> > >
> > > If you're loading the compressed kernel at some wildly different
> > > address, then yes, it probably won't work.
> >
> > It also works when loaded at e.g. 0x42000000 or 0x44000000,
> > but not at 0x41000000 (all with [PATCH 1/2] applied).
>
> So let's assume the kernel is loaded at 0x43000000.
>
>                 mov     r0, pc
>                 and     r0, r0, #0xf8000000
>
> This will result in r0 being 0x40000000. This becomes the mem_start
> argument in fdt_check_mem_start().
>
> We look for an appended DTB, and skip the validation that
> fdt_check_mem_start() does. If this were to go ahead, then this would
> find that 0x40000000 is within the memory@40000000 node, and thus this
> would return "mem_start".
>
> Then:
>
>                 /* Determine final kernel image address. */
>                 add     r4, r0, #TEXT_OFFSET
>
> will place the decompressed kernel at 0x40008000.
>
> However, as placing the kernel at 0x41000000 doesn't boot, that
> suggests some memory is being removed from the kernel. If adding a
> call to fdt_check_mem_start() after the ATAG-to-FDT parsing has
> been performed fixes this, it suggests the ATAGs change this.
>
> So, with a booted kernel, what does:
>
> $ hexdump -e '"%8.8_ax  " 8/4 "%08x " "\n"' /sys/firmware/devicetree/base/memory\@40000000/reg
>
> say? Has this been modified from 00000040 00000020 ? I think it
> will be.

Thank you. Output is:

    00000000  00000041 0000001f

So the first 16 MiB was indeed removed.

> That means there's a simple fix: as there is likely reserved memory
> at the start of RAM, reflecting that in this platform's .dts would
> fix this issue without needing to change the decompressor.

Unfortunately that does not seem to work.

> If you don't want to change the reg in the memory@ node, then there's
> /chosen/linux,usable-memory-range which can be used to specify the
> usable memory base and size (same format as reg).

Neither does this...

> Another option would be to add linux,usable-memory to the memory@
> node that specifies the range of usable memory while still specifying
> the full memory range in the reg property.

... or this.

Don't all of these methods rely on fdt_check_mem_start() operating on
the appended DTB, i.e. on what [PATCH v2 1/2] does?

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Il giorno lun 2 feb 2026 alle ore 11:27 Geert Uytterhoeven
<geert@linux-m68k.org> ha scritto:
>
> Hi Christian,
>
> Trying to revive this thread...
>
> On Thu, 13 Jun 2024 at 18:51, Christian Marangi <ansuelsmth@gmail.com> wrote:
> > 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 <ansuelsmth@gmail.com> 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)
>
> FTR, I did provide my Tested-by for the first patch in [1].
> I still have this series in my local tree, which I test regularly on
> a variety of Renesas ARM32 platforms and on BeagleBone Black.
>
> In fact, I had completely forgotten about this series, to the point
> that I bisected a failure in booting mainline on one of my boards
> using my current .config to the absence of the first patch ;-)
> Apparently during the past years, I had modified my .config to make it
> more generic, and make better use of the DTB (incl. chosen/bootargs),
> which has a dependency on the first patch...
>

I mean we also use this patch from a long time on ipq806x on OpenWrt.
Would really love to have this merged as it does fix a big problem
and would permit full upstream support on all kind of """""legacy""""""
devices.

We just need more wide testing. Any clue how we can achieve this?

> The second patch is a different story (I don't need it ;-), and enabling
> the option may indeed not be suitable for distro kernels.
>

Yes the second patch is so minor it's both harmless and can also be
ignored. But it's really a 3 line change so can't see why it should be
problematic.

> Thank you!
>
> [1] https://lore.kernel.org/CAMuHMdX0dpQdZSCJGuOM0MgM3N-8OA29skARvXEkm87eOPEWBA@mail.gmail.com
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> 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 Wed, Feb 21, 2024 at 5:57 PM Christian Marangi <ansuelsmth@gmail.com> 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 <ansuelsmth@gmail.com> 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