* 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 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
<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>
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.
<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