Am Freitag, 29. November 2024, 13:46:12 CET schrieb Diederik de Haas:
> Hi,
>
> On Fri Nov 29, 2024 at 1:20 PM CET, Heiko Stübner wrote:
> > Am Freitag, 29. November 2024, 01:24:19 CET schrieb FUKAUMI Naoki:
> > > since Radxa devices use device tree overlays[1][2][3], make base .dts
> > > support them.
> >
> > this essentially doubles the sizes of generated DTBs.
> >
> > In previous iterations there were concerns that this might overload
> > allocated memory in legacy firmware that might still run on people's
> > devices.
> >
> > I'm not sure if someone did look deeper into that meanwhile and you
> > can't of course not require people to update u-boot just for a kernel
> > upgrade. Hence previous overlays do not enable those options but instead
> > depend on "distributions" to handle that.
> >
> > So I'm definitly not sure how to proceed with this.
>
> In my recollection this was brought up when the restructuring of the arm
> (not arm64) dts 'tree' was discussed.
> So hopefully Rob can recall the details?
>
> But IIRC, the objection was about enabling it *globally* and instead it
> should be done more granually, be it on the SoC manufacturer level
> ('rockchip') or on the SoC ('rk3588') or on the board level as is
> proposed in this patch.
>
> e925743edc0d ("arm: dts: bcm: Enable device-tree overlay support for RPi devices")
> is where it got enabled for RPi devices
>
> I can't speak for the Debian kernel team, but the general approach is:
> get it fixed (or in this case enabled) *upstream*.
> That's why Aurelien Jarno (who's a DD) send it upstream.
I actually meant that less broadly and way more Rockchip-specific ;-)
I.e. I think it was Dragan that brought it up that old firmware binaries
(u-boot, tf-a, ...) may occupy memory regions that may run over by an
overly large dtb, but can't find the mail right now.
Hence when unsuspecting people update their kernel on a
(i.e. Radxa-)device with really old firmware there might be a possibility
that stuff may break when the dtb handed around doubles in size.
Heiko
