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
tg has quit [Quit: tg]
<davidlt[m]> rwmjones: nujive is not talking to Koji
jcajka has joined #fedora-riscv
<rwmjones> hmmm, looking ...
Kevinsadminaccou has joined #fedora-riscv
<rwmjones> it looks totally fine, but I'm going to reboot it anyway
<rwmjones> looks like it is back after the reboot
Kevinsadminaccou has quit [Remote host closed the connection]
<thefossguy> The official Golang documentation for installation from source says that it supports installation on riscv, meaning riscv is on _some_ tier of official support. Being tier 1 or the last tier doesn't matter (to me).
<thefossguy> But then this "first party" library (https://pkg.go.dev/golang.org/x/arch) doesn't have any arch information for riscv.
<thefossguy> Can anyone help clarify why this is?
<thefossguy> Note, I'm not a Go developer. Just stumbled upon this because of a project I'm working on.
<davidlt[m]> Not all packages are ported to riscv64.
<davidlt[m]> And supporting riscv64 in the compiler doesn't tell about how much ecosystem is ported.
<thefossguy> That library is for the riscv asm support for golang
<thefossguy> without that, how does golang support riscv 🙃
<davidlt[m]> "The parts needed in the main Go repository are copied in."
<davidlt[m]> So it's not used directly, but some copy & pasting is used.
<thefossguy> Ah, so it is more like a spec than a library?
<davidlt[m]> I got impression that this package is required for some kind of interfacing.
<cwt[m]> I think rust is much better at RISC-V supported.
<thefossguy> Yes, I'm a rust dev B)
<cwt[m]> Cool
<thefossguy> But I'm looking at this library because it has asm :)
<thefossguy> I can read the ARM ARM, but I just want a list of all opcodes
<davidlt[m]> Looking at something random it seems some of it is used for disasm.
<davidlt[m]> Which might not be supported for riscv64 :)
<thefossguy> Same for X86, just want a list of opcodes.
<thefossguy> davidlt[m]: Ah, gotcha
<thefossguy> I'll have to wander into LLVM/GCC then
<thefossguy> Because qemu points to this XD
<dtometzki> lichee Pi 4a the debian image has an unusual /boot dir https://pastebin.com/tWSuMzmZ
<thefossguy> It is fdt: flattened directory tree
<thefossguy> 😆
<thefossguy> Looks like they did the bare minimum to get the image up and running
<thefossguy> Do you have a Lichee Pi 4a? dtometzki
<dtometzki> yes
<thefossguy> How does it feel compared to the VF2?
<dtometzki> but if you want build you own kernel it is impossible
<thefossguy> Ouch
<dtometzki> because config and so on is missing
<davidlt[m]> It looks like there are two binary blobs.
<davidlt[m]> Seems to firmware bits.
<davidlt[m]> Not sure why fw_dynamic is there.
<dtometzki> Pratham Patel: the first impression was good. Connect the board and it runs with a preinstalled image
<dtometzki> i dont know where are the sources located.
<dtometzki> ah cool
<davidlt[m]> It's probably revealing too much :)
<davidlt[m]> For example, beagleV-Ahead :)
<dtometzki> If you read the SPDX * Copyright (C) 2022 Alibaba Group Holding Limited.
<davidlt[m]> Yeah, the IP vendor.
<dtometzki> from this perspective VF2 is better more standard
<davidlt[m]> What do mean by more standard?
<dtometzki> How the kernel is build dir setup and so on
<davidlt[m]> It doesn't matter. All of these are some form of hacks (typically) until things land upstream.
<davidlt[m]> Things might look radically different by the time everything is in upstream.
<thefossguy> That's just because they're probably waiting for upstream
<dtometzki> yes correct
<dtometzki> i hope it will change in the future
<davidlt[m]> I generated a new distro repo, and trying to cook a new disk image
<thefossguy> Would you be willing to create a new image mid-release if VF2 were to be supported by Linux mainline?
<davidlt[m]> Yeah
<davidlt[m]> Fedora 39 already has 6.4 kernel.
<davidlt[m]> The plan is to release F38 + 6.2 ASAP, followed by F38 + 6.3, and get F39 rolling with 6.4.
<thefossguy> That reminds me, the qemu image for f37 (I think) has a feature where the password for riscv resets to riscv_rocks!. Any plan to change this?
<davidlt[m]> Well, at least I have some hope in this 😄 We'll see if I manage it.
<thefossguy> Ah, okay :)
<davidlt[m]> I have no idea why it resets. Never seen this before.
<thefossguy> Oh well, let's see if it is different on real hardware with the VF2 image then
<davidlt[m]> I have changed password in the past without any issues.
<thefossguy> Maybe it has to do with how I "expanded" the image then
<davidlt[m]> It also depends if you are running some kind of COW layer on top, which is not saved or something
<thefossguy> That's probably what I was doing to save disk space
<davidlt[m]> Anyways, if you remind me a bit later I could test it with a new disk image.
<thefossguy> Though I also recall using dd 🤷
<thefossguy> Absolutely
<davidlt[m]> If I manage to generate one. We'll know within a few hours.
<thefossguy> Sure, ping me when it generates and I'll manage to break it 😛
zsun has joined #fedora-riscv
<davidlt[m]> It seems there might be a new disk image today.
zsun has quit [Quit: Leaving.]
tg has joined #fedora-riscv
somlo has quit [Ping timeout: 240 seconds]
somlo has joined #fedora-riscv
<thefossguy> It's late here now, busy tomorrow until at least 15:00 (IST), will check the disk image then
<davidlt[m]> It's not bootable out of the Koji.
<davidlt[m]> Well, unless you are booting in QEMU.
<thefossguy> I’ve yet to install QEMU on the VF2 but idk if it will work without the hypervisor extension 
jcajka has quit [Quit: Leaving]
djdelorie has quit [Quit: Leaving]
djdelorie has joined #fedora-riscv
esv has quit [Ping timeout: 256 seconds]
esv has joined #fedora-riscv
esv has quit [Ping timeout: 268 seconds]
esv has joined #fedora-riscv