<djdelorie>
I admit it, we're addicted to internet...
<davidlt[m]>
djdelorie: oh yeah, it's like electricity, water and air :)
<djdelorie>
we make our own electricity, water, and air around here
<davidlt[m]>
Your node went offline after ~120 hours of GCC 13 build, it usually takes ~130 (at least in the past). I bet the build finished, but later it couldn't phone back to Koji Hub.
<davidlt[m]>
Once it came back it restarted the build.
<djdelorie>
yeah the board is still up, and idle
<djdelorie>
or was idle before the internet came back
<davidlt[m]>
It's not idle, it's building again :)
<davidlt[m]>
Yeah, my brain didn't account for extreme weather conditions in US :)
<davidlt[m]>
Yet I see that on the news pretty much daily.
<davidlt[m]>
Now we are running 4 builds of GCC 13 in 3 different geographical locations ;)
<djdelorie>
hoping that one will succeed
<davidlt[m]>
I got too much used to your board being rock solid :) Thus typically heavy stuff goes to that board.
<djdelorie>
sadly, my ISP doesn't have a backup generator. When they loose power, I'm disconnected.
<djdelorie>
s/loose/lose/
<davidlt[m]>
You could have LTE fall back on the router ;)
<davidlt[m]>
I am spoiled with a very good LTE on a cheap :)
<djdelorie>
only if my isp were my cell provider - they're not, so IP addresses would have to change
<djdelorie>
I have gigabit over cable here
<djdelorie>
but LTE in USA is expensive
<neil>
your isp doesn't have a ... generator? 🤔
<neil>
have you called the FCC? :P
<davidlt[m]>
True, unlimited here is 10-20 EUR a month (tax incl.)
<djdelorie>
the weird thing is that gas stations don't have generators... it's not like they're going to run out of fuel
<davidlt[m]>
My old phone (which is now LTE model + UPS thingie) pull <300Mbps on LTE.
<djdelorie>
we pay 2-3x as much for "unlimited" - and it's in quotes because it's actually limited.
<davidlt[m]>
djdelorie: are these storms common and thus generator (and similar stuff) is also an expected thing to own, or this happens so rarely that no one cares if things go down for a day or few (e.g. gas station)?
<djdelorie>
power failures are common but not often around here. Power is reliable but the weather isn't, and a typical year will have at least one big storm that takes out a lot of power
<djdelorie>
but we're very good at restoring power
<davidlt[m]>
We aren't good at that here :) But it never really happens in the city.
<neil>
yeah the US is pretty good at restoring power quickly (well, most of the US...)
<davidlt[m]>
I am not gonna lie. Hiking in the woods with plenty of snow and ~-30C is really nice (but you need to be careful).
<djdelorie>
heh, there's one mountain around here were the weather is so dangerous you can die of frostbite in the summer
<davidlt[m]>
That sounds when trees are breaking due to a snow or/and ice..
<djdelorie>
we hate that sound
<neil>
"Widowmakers"
<davidlt[m]>
There is another sound in the mountains when glacier is breaking. That's like a thunder.
<neil>
sounds terrifying
<davidlt[m]>
I was once told to relax, because you only make one mistake in mountains :) the rest doesn't matter ;)
troglodito has quit [Ping timeout: 252 seconds]
troglodito has joined #fedora-riscv
<neil>
heh. i guess that's true!
tg has joined #fedora-riscv
davidlt has quit [Ping timeout: 252 seconds]
zsun has joined #fedora-riscv
<dtometzki>
davidlt: I'll take a look and get back to you if I have any questions
tg has quit [Quit: tg]
davidlt has joined #fedora-riscv
<davidlt[m]>
dtometzki: in most cases you will find a fix in our dist-git overlay ( http://fedora.riscv.rocks:3000/ ). You might need to update/rebase it locally (test it, e.g. rpmbuild / mock) and submit it as PR + RHBZ item for tracking.
<davidlt[m]>
This should help you to get familiar with workflow. Figure out how things work.
<davidlt[m]>
All 4 GCC 13 builds are cooking.
zsun has quit [Quit: Leaving.]
davidlt has quit [Remote host closed the connection]
zsun has joined #fedora-riscv
mbohun[m] has joined #fedora-riscv
davidlt has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
tg has joined #fedora-riscv
<dtometzki>
davidlt: Perhaps we find a time slot where we do the start together ? Perhaps next week we find a time slot ?
esv has quit [Ping timeout: 252 seconds]
esv has joined #fedora-riscv
<davidlt[m]>
dtometzki: sure, but I am traveling to FOSDEM next week thus I am only available in the 1st half of the week.
<dtometzki>
davidlt: i will check my calendar
<dtometzki>
davidlt: do you have some time on Monday morning ? Perhaps from 8-9 am CET
<dtometzki>
?
<dtometzki>
or later
<somlo>
davidlt[m]: I enabled Z* extensions on Rocket, and (again, thankfully) this didn't blow up the number of logic slices used on my FPGAs by a significant amount -- single full rocket core still fits on ecp5, 4xCore still fits on nexys-video
<somlo>
linux now prints "isa: rv64imafdck" -- I hadn't noticed the "k" before
<somlo>
a cursory googling isn't yielding much useful detail on what "k" means
<davidlt[m]>
dtometzki: around that time is probably OK. Maybe 10 AM CET is better if Google time zone conversion doesn't lie.
<davidlt[m]>
somlo: k is crypto, bit I don't see bit manip stuff.
<davidlt[m]>
Crypto stuff depends on it.
<davidlt[m]>
Also these single letter exntensions are annoying me.
<somlo>
I added " WithBitManip WithBitManipCrypto WithCryptoNIST WithCryptoSM" options to the rocket scala/chisel configurator before re-building the verilog
<davidlt[m]>
somlo: Linux will print what's in DTB.
<somlo>
went w/o errors, then I rebuilt the litex bitstream and loaded the (same-as-before) linux kernel on it
<davidlt[m]>
If you boot QEMU with all the latest extensions you will get a very long ISA string :)
<somlo>
that isa string is what came out :)
<somlo>
I'm very much *not* up to speed on what it all means :)
<davidlt[m]>
So B is not a thing (kinda).
<somlo>
heh... my DTS has "rv64imafdcXrocket" (we talked about that before)
<davidlt[m]>
There are 4 Zb{a,b,c,d} extensions.
<davidlt[m]>
So it should be _Zba_Zbb_Zbc_Zbd
<davidlt[m]>
_Xrocket
<davidlt[m]>
(probably)
<somlo>
but I suppose opensbi and linux do their own pass of voodoo magic over the initial DTB, so it's not a direct cut'n'paste from what I provided
<davidlt[m]>
There is 6 crypto extensions IIRC.
<somlo>
it had "rv64imafdcXrocket" before I turned on Z and crypto and all that -- that didn't change (in their dynamically generated dts sample) after I enabled the extra options
<davidlt[m]>
It's direct copy & paste.
<somlo>
it's just linux doing some of its own detection and reporting, I think
<davidlt[m]>
There is no other way to know :) So DTB is what tells things about the HW :)
<davidlt[m]>
There is no cpuid or anything like that. It's ISA string passed from DTB what kernel will trust.
<somlo>
well, since I am actively compiling "rv64imafdcXrocket" into the DTB I compile into opensbi, and on the other side, linux prints "rv64imafdck", *something* inbetween is doing some editing
<somlo>
might be opensbi, or linux, not much else in the way of prime suspects :)
<davidlt[m]>
Actually there are 13 crypto extensions :)
<somlo>
I know for a fact that opensbi adds a reserved memory area where it resides in the address space to the dtb it provides to the kernel
<somlo>
so I'm not surprised that the dtb is edited from what I provided
<somlo>
I'm just not sure how thorough the checks are, and what layer they're happening at, and how much I can trust (heh, there's that word, again :) ) the result :D
<somlo>
s/layer/stage/ but yeah...
<davidlt[m]>
Yeah, DT bindings say this is the pattern: pattern: ^rv(?:64|32)imaf?d?q?c?b?v?k?h?(?:_[hsxz](?:[a-z])+)*$
<davidlt[m]>
To my understanding if there is B, that means all _Zb* extensions.
<dtometzki>
<davidlt[m]> "dtometzki: around that time is..." <- Its good for me. Iwill ping you
<davidlt[m]>
For example, my QEMU is: rv64imafdch_zicsr_zifencei_zba_zbb_zbc_zbs
<somlo>
my qemu (6.2.0-16.fc36) says "isa: rv64imafdc"
<davidlt[m]>
Extension that don't have "x-" are supported and ratified.
<davidlt[m]>
These ISA strings are getting longer and longer :)
<davidlt[m]>
As you can see there is no such thing as "k" in QEMU at all.
<davidlt[m]>
There is "Zk".
<somlo>
yeah, explains why I had trouble finding it on google :)
<davidlt[m]>
There is this renaming thing to from single to multi-letter stuff.
<somlo>
but it's still unclear to me how the "Xrocket" portion of my original string got translated into "k" by the time linux showed it to me via /proc/cpuinfo
<davidlt[m]>
Linux definitely has a parser, which seems to be constantly updated.
<davidlt[m]>
U-Boot parser doesn't even understanding anything non-single letter.
<davidlt[m]>
I think Rocket scripts don't generate a proper up-to-date ISA string.
<somlo>
you mean update the kernel a few more times over the next weeks, and that output might change -- got it! :D
<davidlt[m]>
I think only H (hypervisor stuff) still don't have a new fancy string.
<somlo>
the rocket chisel-to-verilog build script generates "rv64imafdcXrocket", which is what I cut'n'pasted into my own DTS, which I turned into DTB, and then linked into the opensbi blob I'm loading into RAM at boot
<somlo>
from there, it's between opensbi, and the (mostly) Fedora-specific kernel (the one I'm debugging CONFIG_* options for at the moment)
<davidlt[m]>
I am debugging QEMU + OpenSBI/U-Boot stuff :)
<somlo>
but since it "Works(TM", I see no reason to worry too much about what "k" means, got other fires to put out right now :)
<davidlt[m]>
I am off to maybe get some sleep.
<somlo>
it just would have been so much more conclusive to see "Z-blahblah" explicitly added to Rocket's own generated dts sample -- oh well, maybe after a few more updates *there* that will start happening
<somlo>
I've tried to teach myself Scala so I can have a better change of debugging and fixing chisel things in rocket, but I'm not there yet :)
<somlo>
allright, good night, chat later!
<davidlt[m]>
somlo: in their CI scripts they have: RV64IZba_Zbb_Zbc_Zbkb_Zbkc_Zbkx_Zbs_Zknd_Zkne_Zknh_Zksed_Zksh
<davidlt[m]>
Something like that is what I would expect.
<davidlt[m]>
rv64imafdc_zicsr_zifencei + the rest + _xrocket
<somlo>
it's possible that the code creating the sample dts is out of date, and if I simply cut'n'pasted the fancier isa strings matching the bitmanip support it would be "correct"
<somlo>
fixing (or at least debugging) their dts generating code was one reason I wanted to know more about scala