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
zsun has joined #fedora-riscv
davidlt has joined #fedora-riscv
<davidlt[m]> @rwmjones ^^
zsun has quit [Quit: Leaving.]
zsun has joined #fedora-riscv
davidlt has quit [Ping timeout: 265 seconds]
zsun has quit [Quit: Leaving.]
zsun has joined #fedora-riscv
jcajka has joined #fedora-riscv
<rwmjones> morning
<rwmjones> davidlt[m]:
<rwmjones> 2043874 root 20 0 572956 119724 23196 R 97.7 0.7 2:50.34 dnf
<rwmjones> 2043854 root 20 0 569420 116308 23332 R 95.4 0.7 2:54.02 dnf
<rwmjones> they are both doing dnf builddep
<rwmjones> smt solver hit an NP case??
<davidlt[m]> :D
* rwmjones is only half joking, it might actually be the problem
<rwmjones> do you want me to restart kojid?
<davidlt[m]> Yeah
<rwmjones> ok one sec
<rwmjones> ok done
<rwmjones> gitlab-- just killed off all my CI by implementing some very restrictive minutes policy
zsun has quit [Quit: Leaving.]
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
zsun has joined #fedora-riscv
masami has joined #fedora-riscv
cyberpear has quit [Ping timeout: 260 seconds]
cyberpear has joined #fedora-riscv
<davidlt[m]> This is boring (but good, I am tired).
<davidlt[m]> I am booting most of Unmatched boards (still missing some PSUs)
<davidlt[m]> So many buttons to press, so many firmware binaries to flash.
<davidlt[m]> And it's cable nightmare :D
<davidlt[m]> I might consider adding a swap partition by default in the future.
davidlt has joined #fedora-riscv
* davidlt[m] improving my own world record of swapping microSD card and rebooting Unmatched
<davidlt[m]> and a new board is ready to boot
<davidlt[m]> new board, new song time. Playing: Coldplay - Adventure Of A Lifetime
<davidlt> javierm, palmer confirmed that 6.0 kernel should boot D1
<davidlt[m]> ant a new board is ready :) next...
<varlad[m]> <davidlt> "javierm, palmer confirmed that 6..." <- Reminds me
<varlad[m]> I don't have enough money to buy one but man do I hope it sells, even if domestically xD
<varlad[m]> Laptops incoming :x
<davidlt[m]> C906 or C910 based ones?
<varlad[m]> * Reminds me
<varlad[m]> RISCV Laptops incoming :x
<varlad[m]> I don't have enough money to buy one but man do I hope it sells, even if domestically xD
<davidlt[m]> T-Head TH1520 might be decent enough.
<davidlt> djdelorie, have you noticed [PATCH v2] stdlib/strfrom: Add copysign to fix NAN issue on riscv (BZ #29501) ?
<varlad[m]> <davidlt[m]> "C906 or C910 based ones?" <- Yeah
<varlad[m]> I _really_ hope it sells xD
<varlad[m]> 1500 dollars :x
<davidlt[m]> Oh, that crypto, NFT, Web3, etc. laptop?
<varlad[m]> davidlt[m]: Yeah... I almost forgot that was a part of the deal xD
<varlad[m]> Although, they promise free Sillicon upgrades for a few years
<davidlt[m]> Don't trust such things :)
<varlad[m]> davidlt[m]: I'm not against the crypto trend (since I don't have much idea about it) xD
<varlad[m]> I do wonder though, who did they release it for.... who'll buy this over say, VisionFive 2...
<davidlt[m]> Probably no many. I think you can get it via RVI developer program. I would assume it's a small batch mainly targeting that.
<varlad[m]> 1000 laptops it seems
<varlad[m]> I can see SiFive staff or Alibaba staff running it though xD
<davidlt[m]> The problem was their product announcement. No one would trust a company with a such announcement with all the magic words NFT, crypto, blockchain, Web3, etc. The hardware has nothing to do with that.
<javierm> davidlt: awesome. Thanks for letting me know. I'm in a conf this week but next week I'll then open a MR for kernel-ark so that fedora kernel could work OOTB
<varlad[m]> davidlt[m]: True
<varlad[m]> It was super shady and I didn't believe it until I saw XCalibyte at RISCV Summit (with some interesting stuff too)
<davidlt[m]> My advice is to save that money in your wallet/pocket until time proves that the company is trustworthy.
<davidlt[m]> And also a lot depends on companies approach towards upstream support.
<davidlt[m]> Having hardware with no upstream efforts would make it annoying.
<varlad[m]> davidlt[m]: I'm saving it for the first company who says "we fitted a bunch of RVV cores in this SBC/Laptop" (at an affordable rate)
<varlad[m]> I'm expecting stuff from StarFive's Dubhe oe maybe Sipeed :D
<varlad[m]> I wonder if Esperanto will release a consumer model of ET-SoC1... does that use RVV though?
masami has quit [Quit: Leaving]
<varlad[m]> * I'm saving it for the first company who says "we fitted a bunch of RVV cores in this SBC/Laptop" (at an affordable rate)
<varlad[m]> I'm expecting stuff from StarFive's Dubhe or maybe Sipeed using these new processors :D
<varlad[m]> I wonder if Esperanto will release a consumer model of ET-SoC1... does that use RVV though?
<davidlt[m]> I don't expect Esperanto to do low cost option :)
<davidlt[m]> Dubhe will probably be a good value option.
davidlt has quit [Ping timeout: 260 seconds]
<djdelorie> davidlt[m]: and v3, v4, and v5...
jcajka has quit [Quit: Leaving]
<palmer> davidlt[m]: that v2 of the T-Head ISA is functionally the same as the v1, it's just renamed the extensions
nirik is now known as gone-nirik
kalev is now known as gone-kalev
davidlt has joined #fedora-riscv
<davidlt[m]> djdelorie: so fast? :)
<djdelorie> new contributors, learning the little things like spacing
<davidlt[m]> palmer: there is a new chip with C906 (got a picture).
zsun has quit [Quit: Leaving.]
<somlo> davidlt[m]: could my problems with qemu be related to the fact that the included `vmlinuz-5.18.8-200.0.riscv64.fc33.riscv64` "gzip compressed data" (in effect an `Image.gz` rather than a "proper" vmlinuz)?
<davidlt[m]> somlo: are you booting OpenSBI -> Kernel? In that case it wouldn't boot. Something needs to uncompress it.
<somlo> it's basically the same as what I get under arch/riscv/boot/Image.gz
<somlo> so are you naming it `vmlinuz-...` just by convention?
<davidlt[m]> Yes, I think so.
<somlo> I thought `vmlinuz` and `Image[.gz]` are somewhat differently formatted binaries of the kernel
<davidlt[m]> InstallName=${5:-vmlinuz}
<davidlt[m]>
<somlo> and qemu-system-riscv64's help says "-kernel bzImage -- use 'bzImage' as kernel image" -- where bzImage is yet another thing, not sure how closely related to `Image.gz` and/or `vmlinuz` :D
<davidlt[m]> Remember that arm64/aarch64 and riscv64 does not have self-extracting kernels.
<davidlt[m]> U-Boot is uncompressing the kernel for us.
<somlo> davidlt[m]: I've given up on trying to boot via u-boot, so just attempting to sideload the kernel into qemu with "-kernel ..."; and now doubting whether the included file is in the proper format to even do that...
<somlo> I gunzipped the included vmlinuz file to use it as uncompressed `Image` -- that works fine on LiteX
<somlo> but loading even that (uncompressed `Image`) into qemu gets me nowhere
<somlo> so not quite sure what qemu expects as the file format for `-kernel <foo>` on riscv64
<somlo> ok, got it working: I did (in my `boot` folder: `cat vmlinuz-5.18.8-200.0.riscv64.fc33.riscv64 | gunzip > Image`), then:
<somlo> qemu-system-riscv64 -machine virt -smp 4 -m 2G \
<somlo> -display none -serial stdio \
<somlo> -kernel boot/Image \
<somlo> -initrd boot/initramfs-5.18.8-200.0.riscv64.fc33.riscv64.img \
<somlo> -append "console=ttyS0 earlycon=ttyS0 ro root=UUID=896b7a83-da20-42d2-98f3-bb3ee1717443 LANG=en_US.UTF-8" \
<somlo> -device virtio-blk-device,drive=hd0 \
<somlo> -drive file=Fedora-Developer-Rawhide-20220726.n.0-sda.raw,format=raw,id=hd0
<somlo> for some reason I remember that *not* working during a previous attempt, but maybe there's something else I was doing wrong at the time
<davidlt[m]> that looks correct
<somlo> either way, on qemu the u-boot stuff does not work for me, but sideloading the uncompressed kernel `Image` with the above command line and explicit arguments *does*
<somlo> the "missing instructions" are: "1. gunzip the included vmlinuz-* kernel file; 2. use the gunzipped Image as argument to -kernel;" :)
<somlo> that's progress -- now I can use the qemu VM to build test kernels with debug flags and candidate fixes for liteUART to figure out why things crash on LiteX
<somlo> oh and the `earlycon=ttyS0` bit does nothing, so there's a bit of "suspense" before one starts seeing any sign of the linux kernel booting :D
<davidlt[m]> We don't use it anymore.
<davidlt[m]> It's enough to to have "earlycon". The kernel will pick it up from the DT.
<somlo> huh, that worked -- thanks!
<davidlt[m]> Legacy OpenSBI putchar/getchar is disabled.
<davidlt[m]> There is a new SBI standard proposal for debug console IIRC.
<davidlt[m]> https://lists.riscv.org/g/tech-os-a-see/topic/sbi_debug_console_extension/92016510?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,20,92016510,previd%3D1656435373242207414,nextid%3D1646948416762973434&previd=1656435373242207414&nextid=1646948416762973434
<somlo> I noticed -- one of my earlier plans was to try using *that* to bypass the LiteUART driver altogether (on the fpga/hardware directly) -- except it wasn't there, so I had to move to plan B :D
<somlo> which plan B involves (probably repeatedly) rebuilding the kernel, hence my need for qemu :)
<davidlt[m]> You can always enable that CONFIG_* option :)
<somlo> and I can cross-compile a kernel on my Intel machine, but if I'm going to go the [S]RPM route it's nicer to do it on a "native" riscv "machine"
<davidlt[m]> That's expensive, something like ~14 hours IIRC
<somlo> since I also want matching initrd and all that "integrated" stuff to boot the *real* Fedora on Litex -- I already did the "boot my own kernel, then chroot to the fedora root partition" bit, but it's much more anti-climactic than one would think :)
<somlo> and besides, the LiteUART driver is "rock solid" on my kernel, the crash only happens when I try to boot Fedora, so I need everything as close to what you're publishing as possible, with minimal (a kernel debug flag here, a small change to liteUART there) changes, but otherwise I want everything done the Fedora way
<somlo> I'll just give the rv64gc-fedora VM as many cores (16-20) as I can, and lots of RAM, and hope the kernel SRPM uses %{?_smp_mflags} :)
<davidlt[m]> It does
<davidlt[m]> By default max vCPU was 8, but that might have changed now.
<davidlt[m]> Fedora kernel is configured for max NCPU, which is/was 32.
davidlt has quit [Ping timeout: 265 seconds]
bkeys has quit [Remote host closed the connection]
bkeys1 has joined #fedora-riscv
bkeys1 is now known as bkeys
<rwmjones> the risc-v summit should really say in the first few lines where it's located :-/
<rwmjones> after going through two links, the answer is san jose, ca
<rwmjones> virtual registation is $99 so I might join
<varlad[m]> rwmjones: Is it that much of an inconvenience? xD