Na_Klar has quit [Remote host closed the connection]
davidlt has joined #fedora-riscv
<davidlt[m]>
Na_Klar: It's not Fedora package, it's RPM Fusion package.
<somlo>
davidlt[m]: I'm back to where I need to get fedora-riscv working with qemu -- I need to be able to (re)build the fedora kernel (and initrd) with my own changes (to the liteuart driver, a bunch of kernel debug flags, etc.) as I try to troubleshoot my crashing litex situation
<somlo>
so, since u-boot keeps going around in an infinite loop, I wanted to try side-loading the kernel directly, e.g.
<somlo>
but thag just gets me a bunch of OpenSBI bootsplash text, and nothing after that
<somlo>
is the vmlinuz kernel the wrong format for what qemu expects via `-kernel` ? Am I using the wrong serial terminal? Has anyone recently gotten qemu working with this image? I've got lots of questions :D
<somlo>
btw, for context, the infinite-loop u-boot command was:
<davidlt[m]>
somlo: give me some time, I will try to play with it.
<somlo>
thanks, any clue much appreciated!
<davidlt[m]>
The kernel should work fine. Similar to how aarch64 works. It's EFI kernel, and it contains a 64-byte header for bootloader, but there are some clever magic.
<davidlt[m]>
-bios by default is OpenSBI (some version) + FW_DYNAMIC
<davidlt[m]>
What that means is that OpenSBI should fill a struct with information about the next bootloader stage and jump IIRC.
<somlo>
so that's where the opensbi splash screen comes from, then :)
<davidlt[m]>
Well, I will attempt not to think right now :) I't s 6 AM and I just got coffee :)
<somlo>
no worries, it's 11:30pm here and I'm about to fall over :)
zsun has quit [Quit: Leaving.]
<davidlt[m]>
palmer:Did you run any benchmarks for your proposed GCC default tuning change?
<palmer>
nope, and one big outstanding issue we have is that it appears nobody actually knows what the c906 codegen should look like (as per the by_pieces patches)
<davidlt[m]>
I think there might a "new c906" too, V2 or something. Don't have details.
<palmer>
there's a c910
<palmer>
Sonny has mine, he's got code running it but I don't think it was all that exciting
<davidlt[m]>
Yeah, but someone mentioned me of an updated C906 as a thing, but again I don't have details.
<davidlt[m]>
Does 6.0 now support C906? There is an interested to boot default Fedora image on it.
<palmer>
the D1 should be supported in 6.0, but it's only been out for a few days so I'd be pretty surprised if there were no bugs -- there's a lot of poorly documented stuff floating around in there
<palmer>
IIRC we could boot 5.19, but not talk to any of the peripherals so it was kind of useless
<davidlt[m]>
Ok, so it sounds I might need to get one at some point. More and more folks are asking about it.
<palmer>
there's one on my desk, but not sure how that helps you
<palmer>
I guess in theory we have the lab? I can plug it in somewhere, but they're so cheap it's probably better to just buy it
<davidlt[m]>
I just hope PINE64 Star64 and StarFive VisionFive V2 will become the dominating board in 2023.
<palmer>
ya, I think we're in for a few years of the popular boards being horrible ;)
<palmer>
but worse, because we can't even keep the ISA sane ;)
<davidlt[m]>
Yeah, that's too.
<palmer>
at least the Arm vendors couldn't horribly screw up the core
<davidlt[m]>
Expect JH7110 to be quite popular. I mean the thing is up to 1.5X in perf (or could be) for way cheaper price (even <100 USD).
<davidlt[m]>
And technically it has bitmanip (even if that's not publicly mentioned in their datasheet).
<davidlt[m]>
And that's currently unused in their benchmarks.
<palmer>
you're assuming it works this time ;)
<davidlt[m]>
Yeah. Well to be seen.
<palmer>
yep
<davidlt[m]>
At least I managed to convince them to send up initial upstream patches ;)
<palmer>
for the second one?
<davidlt[m]>
They need to learn some upstreaming 101 (clearly visible from their v1 patches)
<davidlt[m]>
Yeah
<palmer>
ah, cool
<davidlt[m]>
It's already posted. Minimal support (UART, networking works IIRC).
<palmer>
ya, I just found it
<davidlt[m]>
Expect issues, but be kind :) Again, they are learning the process :) Cannot avoid that, I gues.
<davidlt[m]>
I want them to send more stuff later :)
<palmer>
ya, I think we're not so hard on new SOC vendors -- it doesn't really help, the problems aren't the SW team's fault
davidlt has quit [Ping timeout: 265 seconds]
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
davidlt has joined #fedora-riscv
<varlad[m]>
<davidlt[m]> "Expect JH7110 to be quite..." <- I was expecting something which had the vector extensions 1.0
<varlad[m]>
I guess next product will probably have it
<davidlt[m]>
Could be. It takes quite some time from the specs to the silicon to the products.
<davidlt[m]>
A rough example Intel showed Meteor Lake chip, but that's probably a late 2023 (?) product.
<davidlt[m]>
Probably all upcoming SoCs are not that exciting from new ISA extensions point of view. Most of that was designed before specifications were ratified.
<varlad[m]>
davidlt[m]: Lets see
<varlad[m]>
They already have a bunch of cores running the 1.0 spec right?
<varlad[m]>
Like the Dubhe from StarFive. Just waiting for themto put it (or x280) into an SoC and sell it
<varlad[m]>
I think currently Xiangshan's Nanhu supports Vector Extensions too
<varlad[m]>
* Lets see
<varlad[m]>
They already have a bunch of cores running the 1.0 spec right?
<varlad[m]>
Like the Dubhe from StarFive. Just waiting for them to put it (or x280) into an SoC and sell it
<davidlt[m]>
Yeah, T-HEAD too supports vectors, but 0.7.1 (before it was finalized)
<varlad[m]>
davidlt[m]: I have that
<varlad[m]>
I bought it over VisionFive even though inferior specs for that very reason xD
<davidlt[m]>
x280 was available also before vectors were ratified. In most cases those are probably used for small AI chips (cameras, etc.) thus final spec might have not been an issue as no one will ever touch those chips.
<varlad[m]>
davidlt[m]: I thought SiFive is marketing x280 like hell so it must be RVV 1.0 compliant
<varlad[m]>
Currently they released that Google's using it too
<davidlt[m]>
T-HEAD problem is now upstream support for those vectors. Not sure when/if that happens. I think there were some discussions about it in the last several months.
<davidlt[m]>
x280 was announced before vectors were ratified. Again maybe the latest version of it is compliant (most likely).
<varlad[m]>
I think they'll just focus on the 1.0 in the future
<davidlt[m]>
Yeah, in the future T-HEAD should become compliant.
<davidlt[m]>
A bunch of T-HEAD vendor extensions were recently merged into binutils IIRC. That incl. some non-ratified stuff, I think. Kinda "T-HEAD variant" of what is standard now.
<varlad[m]>
I was somewhat excited since I thought VisionFive 2 would have Dubhe
<varlad[m]>
Guess I was wrong xD
<varlad[m]>
Makes sense for StarFive to try to sell it
<varlad[m]>
It got announced in December with perf tools and everything
<davidlt[m]>
T-HEAD ISA v2.0 has: XTheadBa, XTheadBb, XTheadBs, XTheadCmo, XTheadCondMov, XTheadFMemIdx, XTheadMemIdx, XTheadMemPair, XTheadMac, and XTheadSync.
<davidlt[m]>
Oh no, announcement is very long before things happening in reality :)
<varlad[m]>
davidlt[m]: Darn, haven't heard about any of those extensions
<davidlt[m]>
Well, Ba is probably Zba (?)
<davidlt[m]>
same with Bb, Bs
<varlad[m]>
davidlt[m]: Ah, that makes sense
<varlad[m]>
By the way, I'm running Fedora on the 512MB LicheeRV Dock
<varlad[m]>
It works! :)
<davidlt[m]>
Ah. I was wondering what "improved" C906 / V2 could have been. It's maybe ISA V2.0 (but I didn't read the doc).