On Fri, 2025-04-25 at 11:10 +0200, Salvatore Bonaccorso wrote: > Control: tags -1 + moreinfo > > On Mon, Jul 31, 2023 at 10:03:52AM +0200, Diederik de Haas wrote: > > On Monday, 31 July 2023 04:28:31 CEST MOESSBAUER, Felix wrote: > > > On Sun, 12 Feb 2023 18:52:07 +0100 Nicolas Frattaroli > > > <frattaroli.nico...@gmail.com> wrote: > > > > I realise this is quite an old bug, but it would still be of > > > > interest > > > > to me to get this enabled. The -@ option will increase the size > > > > of > > > > the compiled device tree blobs somewhat, but on the flipside, > > > > u-boot-menu's device tree overlay functionality will actually > > > > be useful. > > > > > > The increase is around 30% in average. For the linux-image-6.1.0- > > > 10- > > > arm64, we have around 30MB of dtb files (uncompressed). By that, > > > the > > > package would grow by 10MB (uncompressed) or even less when > > > compressed. > > > > I'm not a kernel maintainer, but I wouldn't expect it to be applied > > to > > Debian's Stable kernel, ie the 6.1 series. > > > > > On many (if not most) arm based boards, these device tree > > > overlays are > > > very useful. There are also many kernel patches about enabling > > > the > > > symbol support on a per-device basis. However, kernel devs seem > > > to have > > > some mixed feelings about that. A proposed solution is to enable > > > this > > > at distro level [1]. > > > @Ben: Would it be an accepted solution to enable the DTC_FLAGS += > > > -@ > > > for all armhf, armmp, arm64 and riscv devices? > > > > AFAIUI, the upstream kernel devs were against such a blanket > > enablement. > > (Consequently it sounds like a bad idea if Debian would do it) > > > > https://lore.kernel.org/all/20220328000915.15041-1-ansuels...@gmail.com/ > > was a > > renewed attempt at restructuring the various .dts* into vendor > > directories and > > with 6.5 that got merged into the upstream kernel. > > And (AFAIUI) that was seen as a prerequisite to start enabling the > > "-@" flag on > > a vendor/directory level, with optionally a subselection if it > > didn't make > > sense to enable it for all boards ... pretty much (exactly) as you > > proposed. > > > > Doing it at the distro level was rejected (at least for Debian) > > with the > > argument that it should be done upstream. > > As there is some (?) coordination/synchronization wrt DeviceTrees > > between the > > upstream kernel and u-boot, that also seems required for the > > functionality > > quoted at the top of this email. > > > > You mentioned you proposed it for RISC-V boards and some DDs > > proposed it for > > RPi boards and both got accepted. I think/expected that we would > > see (many?) > > more such patches getting accepted going forward now that the above > > mentioned > > dts directory restructuring has taken place. > > > > IOW: I agree with the reasoning you brought up in your patch > > submission thread > > and keep targeting inclusion in the upstream kernel. > > Was there progress here, or what should we further do? If it's not > something which is going to land upstream then I would suggest that > we > close the bug.
That's quite an old one... Upstream still only enables the symbol flag on a per device basis, but for most (all?) relevant boards we now have it. Note, this is only fixed for Trixie (6.12) and bookworm backports kernels, as these kind of patches are not backported. Anyways, feel free to close this. Felix > > Regards, > Salvatore -- Siemens AG Linux Expert Center Friedrich-Ludwig-Bauer-Str. 3 85748 Garching, Germany
