14:15 <Stat_headcrabed> mps: I didn't found any code passing mac address to linux kernel in vf2's mainline uboot implementation. Is it actually works?

14:58 <mps> Stat_headcrabed: TBH also I didn't looked to code.

14:58 <mps> so, I'm not sure if it works (if it exists in u-boot)

15:00 <mps> and nowadays I'm using vf2 as server so I don't reboot it often and test it much

15:01 <Stat_headcrabed> Hmmm

15:02 <Stat_headcrabed> I just asked about that in Heinrich's Mars CM board support series.

15:09 <mps> Stat_headcrabed: I'm not even sure this feature is needed, except maybe in some special cases

15:09 <mps> or I don't understand issue well

15:10 <Stat_headcrabed> emmm?

15:10 <Stat_headcrabed> I think we should use vendor-provided mac address as default

15:10 <mps> Stat_headcrabed: is it essentially needed that u-boot pass mac address to kernel?

15:11 <Stat_headcrabed> Kernel doesn't have a method to read mac address from eeprom

15:11 <Stat_headcrabed> And adding a driver for that to kernel is completely a mess

15:12 <mps> ah, understand

15:12 <Stat_headcrabed> We have vendor-defined mac address stored in the on-board eeprom now

15:12 <mps> ok, I will check on next reboot

15:12 <Stat_headcrabed> OK

15:13 <mps> maybe even this weekend

15:13 <marex> search for fdt_fixup_ethernet() , that's what patches local-mac-address into DT via /aliases/ethernet%d entries

15:13 <marex> boot/fdt_support.c:void fdt_fixup_ethernet(void *fdt)

15:15 <mps> marex: grep doesn't show it for me

15:15 <mps> sorry

15:16 <mps> it is there

15:21 <Stat_headcrabed> marex: So that function would automatically patch dtb passed to kernel?

15:24 <marex> Stat_headcrabed: it does insert content of environment variable(s) ethaddr/eth%daddr into DT nodes referenced by /aliases/ethernet%d as local-mac-address property

15:25 <marex> that's how MAC address is passed from U-Boot to Linux

15:25 <marex> make sure your DT does contain the aliases and U-Boot env does contain ethaddr variables

15:26 <Stat_headcrabed> Thanks

15:26 <Stat_headcrabed> got it

21:25 <jmontleon> Is anyone familiar with chain booting on riscv, specifically on the Lichee Pi 4a? I can chain boot upstream u-boot from the vendor u-boot, but when I actually try to run Linux it fails with `Unhandled exception: Environment call from M-mode`. I was wondering if there is a way to make this work at present?

21:32 <marex> booting U-Boot proper from U-Boot proper was never officially supported

21:52 <jmontleon> Oh, the process was described here. I thought there was a purpose to it. https://github.com/u-boot/u-boot/blob/master/doc/board/thead/lpi4a.rst#booting

21:52 <Tartarus> It's one of those neat tricks that's been possible for forever, but not "supported" because really, you should just have proper u-boot itself in the right place

22:02 <jmontleon> That makes sense, ideally. I'm having trouble trying to efi boot with the vendor u-boot. It's seems based off something pretty old, 2020.01 or something I believe, and thought maybe something newer would work better. The VisionFive2 works ok, but not stuck with a custom u-boot.

22:18 <conchuod> The solution I guess is improving mainline U-Boot so that the vendor one isn't needed, but there's not a massive amount of interest in these boards with mainline anything I feel :/

22:27 <conchuod> Most of the T-Head SoCs, or maybe all?, require you to use mainline OpenSBI to boot a mainline kernel because the vendor SDKs all use the ancient version that doesn't set up something (I think the interrupt controller) how mainline expects.

22:29 <conchuod> If that barrier wasn't there, perhaps there'd be more interest in them.

23:02 <jmontleon> i've been able to boot 6.8.9, im just stuck using extlinux and decompressing the kernel, since fedora kernels have CONFIG_EFI_ZBOOT enabled. And using opensbi 1.4 fw_dynamic.bin. though the old 0.9 one would boot as well. I'm just hung up on efi booting with `Failed to update FDT and exit boot services`, like so https://paste.centos.org/view/284f82ac I'm building a debug kernel to see if I can see any more but that'll be a bit.

23:04 <jmontleon> similar flow on vf2 works pretty nicely, u-boot -> grub2 -> fedora.