00:07 <xypron> Tartarus: U-Boot SPL loads the device-tree immediately after the kernel leaving no space for the BSS section. Before relocation we don't zero out the BSS section (which looks like another bug to me). On RISC-V I have seen that the initialization of the debug UART which writes a local static variable in the BSS section corrupts the device-tree. To me the cleanest solution would be adding an offset between main U-Boot image and DT for the BSS section. Writing a

00:07 <xypron> load address for the DT into the .itb would look like the cleanest approach to me.

00:10 <xypron> cf. spl_fit_append_fdt()

00:29 <Tartarus> xypron: First thing is, we don't enforce proper alignment of the device tree in SPL, and aren't we relocating the device tree? Also, the Image should say how big the BSS is, and so we don't overlap

00:30 <Tartarus> Sounds like we aren't relocating the device tree and that's the, or at least a, problem

00:30 <xypron> Tartarus: where should the BSS size info be in u-boot.itb?

00:30 <Tartarus> No, the kernel Image says what the BSS size is, and we use that to ensure we don't overlap

00:31 <xypron> Tartarus: the conflict occurs before relocating U-Boot. Nothing to do with any OS kernel.

00:32 <Tartarus> Why did you say "kernel" ? You lost me

00:32 <xypron> You said kernel first.

00:32 <xypron> Sorry

00:33 <xypron> SPL loads DT directly after main U-Boot

00:33 <xypron> leaving no space for BSS

00:33 <Tartarus> Yes, and we don't have the DT properly aligned

00:33 <Tartarus> Sounds like you need to set / change some of the SPL_BSS* options?

00:34 <xypron> do other archs but RISC-V relocate the DT?

00:34 <Tartarus> I have vague feelings that RISC-V isn't doing some things right, based on as a tangent, disabling device tree relocation for the kernel

00:35 <xypron> SPL_BSS options would not have an effect on spl_fit.c?

00:36 <Tartarus> afk dinner

00:42 <xypron> Tartarus: I see bunches of variables explictely assigned to the data section, e.g. `static int has_been_read __section(".data");` This looks like a work-around for no initializing the BSS section.

00:45 <Tartarus> no, those are very special cases for pre-DDR init stuff and crt0.S should be init'd BSS, iirc. afk dinner, really, now.

13:23 <marex> pivi: that MX8MP PCIe discussion just makes me smile, all the SoM vendors are hell bent to enable it :)

13:23 <marex> pivi: this is becoming a competition who will test it first

21:17 <pivi> marex: I am all in for enabling it! and it was already tested on verdin imx8mp :-)

21:18 <pivi> marex: I just wanted to said it loudly that there is no real drawback on enaling it in the default config

21:19 <pivi> marex: we had in the past concern about size and/or bootime, but 32k in the binary size from my point of view is no point discussing. I am just happy linaro is using our board

21:20 <pivi> marex: I could hit marcel phisically, unfortunately he is not in the office this week :-)

21:58 <marex> pivi: no no no nono ... it is clear you did not want that enabled on your board, so it has to be enabled on another board instead :)

21:58 <marex> pivi: I already have a candidate board

22:06 <pivi> marex: you know that we can enable this on every board we want, there is not much value in the ius primae noctis ;-)

23:10 <marex> pivi: oh that was good :)

23:17 <marex> pivi: was nice to laugh hard again, now back to CI, yay