05:50 <tlwoerner> Kwiboo: thank you!! your hint from the other day (variables set by bootmeth) was exactly what i was trying to find ($devtype $devnum and $distro_bootpart)

05:51 <tlwoerner> using those i can write a u-boot rauc script that will work regardless whether the device is booting from emmc or sdcard

15:03 <marex> xypron: hey, do you know what this arm systemready stuff is all about ? Is U-Boot doing something in that direction ?

15:03 <marex> apalos: ^

15:12 <Tartarus> marex: what parts, exactly? "make sure U-Boot can be used for systemready IR" has been part of it since the beginning

15:13 <Tartarus> The higher levels start to be iffy only around what levels of ACPI "fun" we can truly provide

15:16 <marex> Tartarus: oh

16:26 <qschulz> tlwoerner: I'm interested BTW, if I can avoid modifying boot_targets from C code, I'll take it :)

16:27 <qschulz> Tartarus: any plan on updating dts/upstream to v6.9 for next?

16:27 <qschulz> Tartarus: I've run the script myself but no clue if I'm supposed to send a patch with it or if this is handled by you only... etc

16:28 <qschulz> Tartarus: whenever you have time, would like your opinion on https://lore.kernel.org/u-boot/59c3ee19-f1c5-425d-912d-d418c7a2990b@cherry.de/ as well :)

16:29 <Tartarus> Ah, right, yeah, v6.9 is out

16:29 <Tartarus> I guess my hard question is, too late for master, or not.

16:29 <Tartarus> I should start by seeing if I put something in doc/

16:30 <Tartarus> But I think, next is open, so yeah, too late for master

16:31 <Tartarus> So next, yes, I should go fire that off again. It's not something that send-email's well

16:32 <qschulz> Tartarus: ack, will not try then. No hurry if it's for next, just wanted to know what was the process to get it bumped :)

16:33 <Tartarus> Gotta think how I came up with a CC list last time

16:42 <Tartarus> Done

16:46 <qschulz> Tartarus: thanks <3

18:08 <conchuod> xypron: Do you have any interest in moving any of the riscv stuff to OF_UPSTREAM btw?

18:09 <conchuod> We've got some stuff for other mpfs boards that'll be sent soonTM and I was gonna get icicle moved over then, wondering about the others.

18:19 <conchuod> marex: Did you have a particular reason for wanting the fallback in https://lore.kernel.org/all/d73d4435-75d6-4cea-b38e-07c7ceae3980@foss.st.com/ ?

19:54 <marex> conchuod: last time I checked, the IP they have on MP15 (the older SoC) and MP13 (the newer SoC) was virtually identical

19:54 <marex> conchuod: that's why I pitched the idea of using fallback compatible

19:57 <conchuod> marex: The latest response was a bit ENOPARSE to me, but ye I still think it should have a fallback. I was mostly wondering if you already had some code using the older SoC's compatible that'd benefit from the fallback since that'd be increased motivation for me insisting on one.

19:57 <marex> conchuod: yeah, comparing RM0436 and RM0475 , they did add a bunch of bits

19:57 <marex> (RM0436 is MP15 datasheet, RM0475 is MP13 datasheet)

19:58 <marex> conchuod: the ... stuff about "secure" device tree (I wanted to ask about that, but decided not to) and all that is I think related to their TFA/OpTee-OS efforts

19:58 <marex> conchuod: those two projects seems to have invented their own bindings for a lot of things :(

20:00 <marex> conchuod: I wouldn't hard-insist on the fallback compatible, but unless they can point out a bit that changed meaning (which I dont see so far), I think it is the more right way

20:00 <conchuod> I'm probably just gonna ignore anything to do with that, since it apparently uses a compatible that got NAKed already.

20:01 <marex> conchuod: I think that's for the best

22:08 <xypron> conchuod: Linux distributions have an interest in minimizing the number of U-Boot images they have to provide. In HSS's copy of OpenSBI you anyway need device-trees. Identifying the specific MPFS board in HSS and providing the matching dtb from HSS might make maintaining the different MPFS boards in U-Boot easier. We still should set $fdtfile according to the board, e.g. based on the compatible string.

22:09 <conchuod> xypron: "In HSS's copy of OpenSBI you anyway need device-trees." That's not actually true, I wish it were.

22:10 <conchuod> We only use a handful of files from OpenSBI due to space constraints, we can't even use the libraries it provides as they're too big.

22:13 <xypron> conchuod: Anyway we should find a way to support all MFPS boards by one U-Boot binary.

22:13 <conchuod> I think there might already be support in the HSS for passing a DTB to U-Boot though, just that it's not been used so far. I'm pretty sure the other boards do absolutely nothing differently to the icicle in U-Boot, so using a single binary should work.

22:14 <xypron> How would U-Boot detect which board it is running from?

22:15 <xypron> Currently we have multiple device-trees in Linux.

22:15 <conchuod> The dtb would be different, so it could use the compatible as you mentioned earlier, no?

22:16 <xypron> That would be a clean design.

22:21 <conchuod> xypron: I need to check up on how the HSS handles the dtb, I think it requires that it be built into the payload, so you could have the same U-Boot binary but you still need a per-board payload.bin. I dunno if that is problematic.

22:24 <xypron> It might be helpful, if we could ecall HSS to get the board type.

22:26 <xypron> conchuod: Then we could translate the result in the board file.

22:27 <xypron> Have a look at VisionFive 2 and Milk-V Mars. One defconfig for both.

22:27 <conchuod> Ye, I've seen your patches for that.

22:27 <conchuod> Obviously that'd require a new HSS, but that's far from impossible. Would you want to get a string back from that or some numerical identifier?

22:28 <xypron> Do you already use different imlementation IDs?

22:29 <conchuod> I don't think the different boards report different implementation IDs, no.

22:30 <xypron> You could use Get machine implementation ID (FID #6)

22:31 <conchuod> I'll mention it to Ivan tomorrow though, that might be something we could plumb in, given we already report a custom mvendorid/march and don't need to worry about conflicting with some SiFive indetifiers.

22:31 <xypron> Or a vendor specific SBI extension.

22:32 <xypron> conchuod: good night

22:33 <conchuod> 👍