dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
<cwt[m]> <davidlt[m]> "There is no ld.gold support..." <- can you use ld.lld?
<davidlt[m]> Most likely yes, but default is still ld.bfd.
<thefossguy> Just noticed, basic uboot support is merged upstream for the VF2
<davidlt[m]> They did that already?
davidlt_ has joined #fedora-riscv
<thefossguy> Maybe because DTS were accepted in -next for 6.4?
<davidlt[m]> There was another large patchset for EEPROM support.
<davidlt[m]> I thought that was part of the basic support.
<davidlt[m]> I pinged StarFive folks about fdtfile value.
<davidlt[m]> Hopefully I wrote something meaningful 😄 It's early morning.
<thefossguy> What about the fdtfile? Do you mean about patching it because of the hw revisions
<thefossguy> *^?
<davidlt[m]> Yes
<davidlt[m]> Linux has 2 DTBs, fdtfile only points to 1.3B.
<davidlt[m]> While they are patching Etherent thing now based on EEPROM (That's the patchset I saw yesterday).
<davidlt[m]> They also need to patch fdtfile for EXTLINUX to pick the right one.
<davidlt[m]> Well, if you use fdtdir.
<thefossguy> Okay :)
<davidlt[m]> July is important now.
<davidlt[m]> 2023.04 is out, next one should be in July.
<davidlt[m]> Plenty of time to have it polished for the final release.
<thefossguy> So I tinkered with my image a bit and noticed one thing... When the VF2 is set to boot from SD/EMMC, the firmware stored on the SPI flash doesn't load and initialize the HW.
<thefossguy> The dip switches seem to physically change the boot media
<thefossguy> Unlike what I thought
<davidlt[m]> Because that's for firmware, or in other words where to find the next boot stage.
<davidlt[m]> Same as on Unleashed and Unmatched.
<thefossguy> Ah, so at least that's not a weird quirk
<thefossguy> Off to more hacking then :D
<davidlt[m]> Those bits will tell ZSBL (Zero-stage in boot ROM) where to look for the next stage.
<thefossguy> Gotcha
<davidlt[m]> This is great, because if you flash a wrong firmware in SPI-NOR all you need to recover is microSD card :)
<thefossguy> I assumed that the board would at least initialize itself from the firmware in spi and then proceed to boot from sd/mmc/whatever
<davidlt[m]> Or if you want automation, you can use SDMuxer :)
<thefossguy> Oh tell me about SDMuxer
<thefossguy> that sounds interesting! :D
<davidlt[m]> SD card compatibility might be a bit of a problem.
<davidlt[m]> So this if cool if you want to have OpenSBI or/and U-Boot under a CI :)
<thefossguy> YOU MEAN TO SAY THAT I CAN DIRECTLY SERVE THE IMAGE VIA USB TO THE BOARD? 🤯
<thefossguy> Oh wait no
<thefossguy> I heard "mux" and was excited lol
<thefossguy> But this seems nice :)
<thefossguy> It would be nice to have a direct SD to USB wire where the USB end on the computer mmaps to the disk image
<davidlt[m]> Yes, you can.
<davidlt[m]> It muxes between host and device under test (DUT), i..e. the board.
<thefossguy> Understood
<davidlt[m]> This is used for testing, unless you want to break my world record for microSD swaps :D
<thefossguy> Oh I have a huge record too lol
<davidlt[m]> There are more powerful things like MuxPI: https://3mdeb.com/shop/open-source-hardware/muxpi/
<thefossguy> Had my days of not cooling the Pi4-s properly XD
<davidlt[m]> That can control jumpers too :)
<thefossguy> This is more expensive than the board :cry: 😆
<davidlt[m]> So you could switch (via host machine) DIP switches, etc.
<davidlt[m]> Yeah, but it depends how much your hour costs :)
<davidlt[m]> This + 24/7 operation might be extremely cheaper :)
<thefossguy> I understand, i was only kidding :D
<thefossguy> And more convenient
<davidlt[m]> and have it's own problems too :)
<thefossguy> well, you get some you loose some
davidlt_ has quit [Ping timeout: 246 seconds]
<thefossguy> davidlt: I assume you have a VF2... In the vendor provided image, the `uEnv.txt` file says that the "distro" is one of the boot targets. Do you have any idea as to what this might be?
<thefossguy> I can't seem to find anything related to this in the uboot readthedocs
<davidlt[m]> I recall that in vendor uboot tree, but not the details.
<thefossguy> Ah so it's not an upstream thing.
<davidlt[m]> They have long environment stuff of how to boot which seems quite complicated.
<thefossguy> That at least narrows it down XD
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv
kalev_ has joined #fedora-riscv
xxxxen0n is now known as xen0n
iooi has quit [Ping timeout: 320 seconds]
kalev has quit [Ping timeout: 305 seconds]
davidlt_ has joined #fedora-riscv
esv has quit [Read error: Connection reset by peer]
esv has joined #fedora-riscv
zsun has joined #fedora-riscv
davidlt_ has quit [Remote host closed the connection]
zsun has quit [Quit: Leaving.]
nirik-libera has quit [Quit: ZNC 1.8.2 - https://znc.in]
nirik-libera has joined #fedora-riscv
jednorozec has quit [*.net *.split]
jednorozec has joined #fedora-riscv