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
bkeys has quit [Ping timeout: 240 seconds]
Cirro has joined #fedora-riscv
<Cirro> Hi there! I have access to a Sifive Hifive Unmatched and managed to get a fedora image booting.
<Cirro> Does anyone know how I can share this knowledge or start adding a new process in the official builds (PR or whatever) to support the new platform?
<davidlt[m]> You can write guides/tutorials/etc on GitHub or similar places, e.g. https://github.com/carlosedp/riscv-bringup/tree/master/unmatched
<Cirro> Haha, that was actually the starting point :)
<Cirro> * of my research
<Cirro> And how will fedora devs integrate such changes?
<Cirro> i.e. building ready-to-use images like the unleashed.
<davidlt[m]> I am updating it, but never finishing.
<davidlt[m]> Started updating the packages again this weekend.
<davidlt[m]> Let's see if I can manage to finish it this time.
<Cirro> Ah, cool :) So you can boot the unmatched as well?
<davidlt[m]> I have something locally, but that's not in Koji repos yet.
<davidlt[m]> I started to push it again this weekend, but some packages (e.g. kernel) is a very time consuming build thus will take some time.
<Cirro> ok. Then I'll wait for this before a PR into riscv-bringup, as building the image manually is a bit tedious.
<Cirro> In the meantime, i wanted to look into the onboard SPI-Flash and the required u-boot env.
<Cirro> Do you have something to read about how fedora usually builds "install"-images and the process of that?
<davidlt[m]> This is currently not enabled in the upstream U-Boot or FUSDK/meta-sifive, but technically should work the same way as on Unleashed/FU540.
<Cirro> e.g. "install" from an SD-Card into the SPi-Flash and Nvme
<davidlt[m]> What we use is a kickstart file hosted in the GitHub repository. Then we start a task within Koji to create appliance.
<davidlt[m]> This is the same method that was used for armv7hl builds ~2 years ago.
<davidlt[m]> After that there are a few manual stages, but at this point it's board specific.
<davidlt[m]> If it's QEMU all is good and nothing needs to be changed (these days, unless you want a newer/special OpenSBI firmware)
<davidlt[m]> Unleashed and Unmatched pretty much has the same structure, nothing is different regarding layout.
<davidlt[m]> It's different for PolarFire SoC and BeagleV
<Cirro> Is the intention of the built images to just run out-of-the-box, or is it viewed as a bootable installer for the system?
<davidlt[m]> Out-of-the-box will not work until things are stable and EFI is merged upstream.
<Cirro> OK, makes sense.
<davidlt[m]> GRUB2 still doesn't have the EFI patches merged IIRC.
<davidlt[m]> and still it depends on the boards providing the firmware (OpenSBI, U-Boot) with EFI interface that you can rely on.
<davidlt[m]> These days it's not the case.
<davidlt[m]> There is work in progress standards for RISC-V: Profiles and Platforms that will define a lot of that.
<Cirro> Yes, my area of interest is especially OpenSBI
<davidlt[m]> So technically you can do that with the FW/SW stack these days (out-of-tree patches will be required, but posted on the mailing list).
<davidlt[m]> It's the standards that describe the boundaries, the interfaces, minimal requirements for that platforms that are yet to be finished and ratified.
<Cirro> Yes, I am aware of that
<davidlt[m]> Platforms specs are here: https://github.com/riscv/riscv-platform-specs
<Cirro> I am a co-author of a virtual hardware platform that emulates the Hifive1 and the unleashed in a certain way
<davidlt[m]> Profile specs: https://github.com/riscv/riscv-profiles
<davidlt[m]> Cool!
<Cirro> But we mainly mocked the behaviour until it bootet
<Cirro> But we mainly mocked the behaviour until it booted
<Cirro> (https://github.com/agra-uni-bremen/riscv-vp if you are interested)
<Cirro> This is way slower than QEMU, but our focus is on modelling additional hardware-units or just general research (e.g. symbiolic executiuon of the software running on that)
<davidlt[m]> I see
<Cirro> Ok thanks that was a lot of info. I'll see when I tinker around with the board-specific implementation of openSBI/u-Boot on SPI and an Nvme.
<davidlt[m]> Well additional HW units you could do it in QEMU, but it might not be easy to use for your specific research
<davidlt[m]> Yeah, so SPI stuff should work the same way as on Unleashed, but it wasn't tested.
<davidlt[m]> Otherwise it should be trivial (assuming everything works as I imagine)
<davidlt[m]> NVMe is enabled in upstream in the boot order and it works, but we know that some NVMe might have difficulty (especially no-name NVMes)
<davidlt[m]> Have not seen issues reported for well known brands like Samsung or similar.
<Cirro> Haha, let's see how trivial it will be :D At least it will be documented somehow, so that when standards settle, there can be an autoamted process for users to iunstall fedora
<davidlt[m]> You can achieve that per-board and kinda in a not-distro-specific way these days.
<davidlt[m]> Unmatched ships with an empty SPI-NOR Flash. So basically once things get stable that's when you can try to put firmware into it.
<davidlt[m]> Not all Unmatched patches are yet merged into upstream.
<Cirro> Yup, this was the plan.
<Cirro> Progress is fast anyway, I wanted to put a PR into riscv-bringup because the patches with U-Boot are already in master
<Cirro> (and following strictly will cause it to hang upon kernel-load)
<davidlt[m]> Yeah, upcoming 2021.10 should be good enough, probably still a few smaller patches missing.
<Cirro> Would you need/like an "firmware" image in boot-partition that a user would flash on SPI-Nor in order to not need the SD-Card? Or are you / fedora devs not interested?
<davidlt[m]> That's the end goal, but uSD card is also a good place to have it.
<davidlt[m]> E.g. if you mess up flashing on SPI-NOR Flash you can always use the one of the uSD card by changing DIP switches.
<davidlt[m]> Think of it as a dual-BIOS mode.
<davidlt[m]> Also it's very useful if you use SD Muxer for CI/testing :)
<Cirro> Haha, I also thought about this after having the same SD card flashed 10 times per day ;D
<Cirro> But probably only if I can talk to the university superiors to aquire it.
<Cirro> The Boards are intended to being used by the community as dev/testboards, so this will match up.
<Cirro> How would you manage multiple firmwares in your Kojira automation? Just two files with different names?
<davidlt[m]> Yes, if you need that.
<davidlt[m]> By default you get the latest one.
<davidlt[m]> The latest tagged NVR (which is typically the newest one) is the one that gets included.
<davidlt[m]> NVR - Name Version Revision
<Cirro> I did not catch the way you include the "firmware" part in the kickstart file
<davidlt[m]> it's not
<davidlt[m]> it's board specific thing
<davidlt[m]> long-term there shouldn't be any firmware specific things
<Cirro> Yes, I understand
<davidlt[m]> it's just sgdisk to create layout and disk image, mount it, dd required bits
<Cirro> Then I did not understand where in the process you include these specific things, because the image I got with virt-buiolder (https://fedoraproject.org/wiki/Architectures/RISC-V/Installing) had the parts populated
<Cirro> *included
<davidlt[m]> These are not documented in Wiki, but the final image is provided in the virt-builder final images.
<davidlt[m]> Note, if a proper firmware would be available in SPI-NOR Flash in that case direct image from Koji would work.
<Cirro> Yes. This is the thing I wanted to improve.
<davidlt[m]> For ARM there is a python installer that have information what needs to be done for each board.
<davidlt[m]> So far there aren't too much boards folks can get their hands on so there is no real need.
<Cirro> Ok, I just see if I build a current board-specific how-to for that, and maybe it will just be a userland script to "install" bootloader to Flash
<davidlt[m]> There are some Unleashed boards (not manufactured anymore), Unmatched and PolarFire boards.
<davidlt[m]> BeagleV is dead, there is like ~300 of such boards out in the wild.
<davidlt[m]> Installing to SPI flash is easy as you can simply dd to it :)
<davidlt[m]> (once booted)
<Cirro> yes, we are at a very early-adopter position.
<Cirro> >BeagleV is dead
<Cirro> Sad
<davidlt[m]> There will be more SBCs soonish I would say
<Cirro> I recon that the third sifive board will be a bit more user-usable
<Cirro> Especially in the BBB-Niche (high-power Linux cores and low-power realtime m-mode) I see demand
<Cirro> Lets say in the 3d-printer/automation world.
<Cirro> >Installing to SPI flash is easy as you can simply dd to it :)
<Cirro> yes, i meant a tested image with options, so that the "average, but interested" user can actually just dd a pre-built image to it
<Cirro> Without having to build the openSBI/U-Boot with highly special configurations (e.g. find nvme and sd, not yet documented well)
bkeys has joined #fedora-riscv
jimwilson has quit [Quit: Leaving]
bkeys has quit [Ping timeout: 245 seconds]
bkeys1 has joined #fedora-riscv
bkeys1 is now known as bkeys
jimwilson has joined #fedora-riscv
bkeys has quit [Ping timeout: 240 seconds]
Cirro has quit [Ping timeout: 245 seconds]
bkeys has joined #fedora-riscv
bkeys1 has joined #fedora-riscv
bkeys1 has quit [Remote host closed the connection]
bkeys has quit [Ping timeout: 240 seconds]
bkeys has joined #fedora-riscv
Cirro has joined #fedora-riscv
Cirro has quit [Quit: Leaving]
<djdelorie> davidlt[m]: do we have documentation on how to mod a polarfire to builder status? I notice the kernel it comes with doesn't have pcie drivers or nbd
bkeys has quit [Ping timeout: 245 seconds]