21:07 <xypron> Tartarus: why do you want to disable CONFIG_EFI_LOADER globally on ARMv7 while FreeBSD and OpenBSD need it for booting?

21:08 <marex> xypron: bloat ?

21:09 <xypron> Marex: booting OpenBSD is bloat? Are you kidding?

21:10 <marex> xypron: EFI is bloat, you can boot openbsd on arm32 with bootefi as far as I can tell, no ?

21:10 <xypron> Marex: current OpenBSD is delivered with a loader using UEFI.

21:11 <marex> xypron: on what ?

21:19 <sjg1> xypron: I think we should disable it all by default. The situation with n900 is quite scary

21:20 <marex> sjg1: we should also find a way to trim down the overhead of DM, it is way overdue

21:21 <sjg1> The tiny-dm thing turned into a dead end I think. Did you try of-platdata-inst?

21:24 <marex> sjg1: it should be possible to use DT while keeping the DM overhead small I'd say

21:24 <sjg1> Do you have any ideas? I have dug into it quite extensively and proposed some paths forward

21:25 <marex> maybe turn DT into C code (or some sort of IL) and link it with U-Boot, and then let optimizer do its magic on the result

21:25 <marex> with LTO that might in fact help a bit, although that might be quite some undertaking

21:29 <sjg1> Have you looked at of-platdata?

21:29 <marex> sjg1: does that work with DT now ?

21:30 <sjg1> yes, it always did. It turned it into C structures

21:30 <sjg1> *turns

21:30 <marex> sjg1: and does the compiler actually optimize it at all ?

21:30 <sjg1> are you thinking of what Zephyr does with #defines for each CONFIG ?

21:34 <marex> I didn't look at what they do, I only hear it from someone

21:34 <marex> *heard

21:34 <marex> sjg1: but that's not what I asked -- is the compiler doing any optimization of the result, where your DT is turned into structures ?

21:34 <marex> btw is this to->struct automatic ?

21:50 <sjg1> marex: I don't understand your question about the compiler. Can you be more specific? Optimisations are not turned off, but I'm not sure what you are expecting. It is just C structs being accessed at runtime, removing the need for libfdt and devicetree blob

21:50 <sjg1> marex: yes dtoc converts DT to C structs

21:50 <sjg1> marex: I can do a little talk on it at the next contributor meeting if you like

21:50 <marex> sjg1: well I suppose you could somehow take the values out of the structures and inline them into the code

21:51 <marex> which might permit optimizing things further, since the structures are constant

21:54 <sjg1> marex: That's only possible in particular situations, such as when there is only one struct for each driver (i.e. a single device using the driver)

21:54 <sjg1> Zephyr handles this with for loops in the C preprocessor, so that the data is instantiated multiple times.

21:55 <marex> sjg1: in other words, majority of cases :)

21:55 <sjg1> However the result is the same, data in C structures

21:55 <marex> sjg1: not necessarily

21:55 <sjg1> I'd be interested to see if this actually produces a benefit

21:55 <marex> if you can inline constants, the compiler might be able to optimize out a whole lot of things

21:56 <sjg1> Bear in mind that even with of-platdata, it copies the data to the normal private structs used by the driver

21:56 <sjg1> We don't try to create an entirely separate code path

21:59 <sjg1> I think what you are asking for could be done by duplicating more of the driver code for of-platadata

21:59 <sjg1> a bit like what was done with tiny-dm

22:28 <Tartarus> If we wanna borrow something from zephyr, we should drop kbuild and just turn .config in to something for make/cmake.

22:28 <Tartarus> but that's blocked on 100% Kconfig migration.

22:29 <Tartarus> xypron: As I put below the ---, I was wondering if I missed something. Debian doesn't use it, armbian never uses it (not on aarch64, even), I didn't see a Fedora armv7 but I guess I missed it, and OE got very unhappy even trying to build grub-efi.

22:29 <Tartarus> Turns out that yes, I missed something.

23:55 <sjg1> Tartarus: what is the advantage of that? It would be good to get rid of the boards with unmigrated Kconfig options

23:55 <sjg1> I am not a fan of cmake from my experience in Zephyr, but perhaps it is just ninja that is awful