<conchuod>
Doing a WARN() in a peripheral is a bit daft, unless you're doing it for your own debugging purposes.
prabhakarlad has joined #riscv
pedja has joined #riscv
MaxGanzII__ has quit [Ping timeout: 240 seconds]
hrberg has quit [Read error: Connection reset by peer]
hrberg has joined #riscv
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_dog has joined #riscv
danilogondolfo has quit [Ping timeout: 250 seconds]
danilogondolfo has joined #riscv
BootLayer has quit [Quit: Leaving]
MaxGanzII__ has joined #riscv
heat_ has quit [Read error: Connection reset by peer]
heat_ has joined #riscv
JanC has quit [Read error: Connection reset by peer]
JanC has joined #riscv
elastic_dog has quit [Ping timeout: 240 seconds]
JanC_ has joined #riscv
JanC has quit [Killed (calcium.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
prabhakarlad has quit [Quit: Client closed]
elastic_dog has joined #riscv
Tenkawa has joined #riscv
aerkiaga has joined #riscv
<unlord>
does the VisionFive2 have V instructions?
aerkiaga has quit [Remote host closed the connection]
<bjdooks_>
I don't think so
<bjdooks_>
The U74 cores don't have the V extension
MaxGanzII_ has joined #riscv
MaxGanzII__ has quit [Ping timeout: 240 seconds]
MaxGanzII_ has quit [Ping timeout: 240 seconds]
BootLayer has joined #riscv
<Tenkawa>
Interesting discovery though... the Star64 JH7110 might actually have more extensions than the VF2
<Tenkawa>
Few of us were researching what each supported last night and they don't "quite" match
<Tenkawa>
"according to the docs".... but noone can/has confirmed those either
<unlord>
Tenkawa: is there something special that needs to be done in bring-up to enable these extensions?
<bjdooks_>
csrs 0x7c1 and 0x7c2 might have feature disables in them IIRC
<Tenkawa>
bjdooks_: yeah I'm not sure... I've got both and I've finally got 2 working Debian based installs on them.. so now I can finally really dig into the internal core workings after all these years of arm....
<bjdooks_>
not sure if they're the only core tuning registers (and they can only be set at start time in uboot)
<Tenkawa>
I've had my VF2 for a while but I just got the Star64 (and getting Debian on there was .... fun)
<conchuod>
Tenkawa: Can you elaborate on "more extensions" please?
<conchuod>
Specifically what extensions
<Tenkawa>
conchuod: I would have to find the lengthy discussion between the two people
<Tenkawa>
It was on discord
<conchuod>
Would you mind digging it up for me?
<Tenkawa>
The short version is that it appears Pine's Star64 should only be
<Tenkawa>
This claims that the U7 core is RV64GCB:
<Tenkawa>
Each U7 core supports machine, supervisor, and user privilege modes, as well as standard Multiply (M), Single-Precision Floating Point (F), Double-Precision Floating Point (D), Atomic (A), Compressed (C), and Bit Manipulation (B) RISC-V extensions (RV64GCB).
<Tenkawa>
and the VF2 is a different RV64
MaxGanzII_ has joined #riscv
<Tenkawa>
That's what they were trying to confirm or not
<conchuod>
StarFive said the S7 is rv64imac_zba_zbb
<conchuod>
And that the u74s are rv64imafdc_zba_zbb
<Tenkawa>
Yeah the consensus is the Pine is using a lower grade soc
<Tenkawa>
(featureset)
<conchuod>
Shite, that'll be annoying if tree.
<conchuod>
true
<Tenkawa>
I really like what I've seen on this Star64 so far too
<Tenkawa>
Is there a conclusive way to test for zba_zbb etc?
<conchuod>
I dunno, try to boot a mainline kernel with those in your dt & RISCV_ISA_ZBB set and you should find out quickly enough
<Tenkawa>
No ml kernel support yet
<conchuod>
Or just try to use the instructions in userspace..
<Tenkawa>
It has quite a different dt
<conchuod>
I feel like it is unlikely that they're different.
<Tenkawa>
it is
<Tenkawa>
I already triedi t
<mps>
my expectation is that the riscv will be become bigger jungle than arm especially for open source devs
<conchuod>
different being different in terms of extensions, not devicetree Tenkawa
<conchuod>
Jess and I went digging in old sifive documentation to try and guess if the jh7110 supported zb{a,b}, their documentation didn't originally say it iirc
<Tenkawa>
conchuod: yeah who knows... documentation from both companies is bad
<Tenkawa>
mps: sadly I'm concerned and agree with you
<Tenkawa>
mps: at the same time I think there is a lot to be gained
<mps>
Tenkawa: yes, also I do
<mps>
and I for sure prefer riscv to any other current arch
<Tenkawa>
same
<Tenkawa>
I've already transitioned mydaily development to it
<mps>
oh, nice
<conchuod>
Okay, yeah the dt files do seem rather different in terms of structure in the repos I can find!
<Tenkawa>
conchuod: yeah I was in shock when I saw them
<mps>
Tenkawa: what hardware you use for daily dev. just curious
<Tenkawa>
the wifi is bifurcated on the usb if that tells you anything lol
<Tenkawa>
mps: dont laugh.... a Macbook Pro M1 running Linux VMS
<mps>
Tenkawa: hm, I use m1pro macbook
<Tenkawa>
Ok I guess you won't laugh :)
<mps>
just typing on it
<Tenkawa>
same
<mps>
how fast is riscv emulation on it
<Tenkawa>
I use Parallels so very
<mps>
I just used qemu-user to create alpine riscv disk imagesm nothing more
<bjdooks_>
I run Debian/testing because i'm that cutting edge
<mps>
ahm yes, I test riscv in qemu on it
<Tenkawa>
I can embed it inside a normal arm64 Linux VM
<mps>
Tenkawa: you run this VM on macos?
<Tenkawa>
bjdooks_: yeah I have to run unstable too since I'm using risc-v
<Tenkawa>
mps: yep
<mps>
understand. (I'm using linux only)
<Tenkawa>
Even running FreeBSD on here
<mps>
didn't booted to macos for months
<bjdooks_>
I should either replace my ryzen9 or work out why it tends to fallover afrer a fw days
<Tenkawa>
I've been running OS X as my primary os for 20+ years
<mps>
aha
<mps>
and I used debian for 20+ years
<Tenkawa>
same
<mps>
but switched to alpine few years ago
<Tenkawa>
Debian on my non-macs
<Tenkawa>
1994
<mps>
never used windows or macos for any work
<Tenkawa>
Slackware in 1993
<mps>
ah, same years same OSes
<Tenkawa>
I'm an old Unix geek (1979)
<mps>
I switched from slackware to debian in 1994
<mps>
my real works with unix started with slackware
<Tenkawa>
I had my days at NCR/AT&T/Bell/Lucent
<Tenkawa>
those were an "experience"
<mps>
I guess ;)
<Tenkawa>
haahaa
<Tenkawa>
I'm just waiting to lose my internet (work being done on outside of house deconstructing outside layer of walls for painting/relayering)
<Tenkawa>
I live in an old enough house (almost 120 years) I just wait on one of my lines to get hit
<mps>
I keep my irssi running on always-on server in tmux and access it over mosh. so loose of connection to irc rare
<Tenkawa>
tmux/screen is handy
<pierce>
<mps> "how fast is riscv emulation on..." <- I have an M2 Max, it's not that fast...
<pierce>
You're better off getting a th1520 if you're looking for speed
<mps>
pierce: yes, it looks tempting but I will see what will be good enough investment
<pierce>
It doesn't have PCI-E, and limited ram
<pierce>
But even the jh7110 than qemu
<pierce>
If you're looking at emulating RISC-V, there's rvvm which removes a lot of the drift qemu carries due to its multi arch support
<mps>
pierce: I'm waiting visionfive V2, and will see how fast it is. if it is ok for development I will add nvme and use it over network
<mps>
even on VF V1 I write some simple drivers for learning
<pierce>
Development in what way?
<mps>
I'm interested in comiling and porting/testing some bigger programs with musl to alpine
<Tenkawa>
pierce: the JH7110 itself isn't "that" fast... right now the emphasis should be on "expanding/correcting" where RISC-V is headed... so what if the M1 emulation is a bit slow
<pierce>
Yeah compile times aren't great, you're beat off crows compiling
<pierce>
Tenkawa: My point being, it's faster than qemu on an M2 max
<Tenkawa>
But not near as convenient if you want to "pick up and learn/teach it anywhere"
<pierce>
pierce: Wow, biffed that autocorrect
<pierce>
Better off cross compiling*
<Tenkawa>
I am deconstructing my arm rack today and going to rebuild it to be my risc-v rack lol
pedja has quit [Quit: Leaving]
<Tenkawa>
Thisway I can carry it around with me
<pierce>
Tenkawa: Sure, but to say the m1 pro is "blazing" fast, is disingenuous
<Tenkawa>
I'll have to plug/unplug my pci-e card... but thus it is
<pierce>
pierce: ...when emulating RISC-V
<Tenkawa>
I don't personally emulate anything... now for building/dev on it... that machine would be a racecar for risc-v
<pierce>
Tenkawa: But I'm telling you it's not
<Tenkawa>
pierce: I know it is... because I'm doing it right now
<Tenkawa>
I can build a risc-v kernel in 3 minutes
<pierce>
The M2 pro under qemu is slower than a few u74 cores
<Tenkawa>
Read ...
<Tenkawa>
Don't use it as your os... build things "for" it
<pierce>
I assumed you misread and lead mps astray
<Tenkawa>
nope
<mps>
pierce: no worries, it is not easy to lead me where I'm not ready to go ;-)
<pierce>
I reckon so, evidence there is clear, they asked something specific and you answered it incorrectly
<pierce>
Parallels does not make RISC-V emulation faster
<Tenkawa>
pierce: noone said it did... drop it
<pierce>
pierce: See figure 1.
<pierce>
Exhibit A.
<bjoto>
The shortest PW sync ever! :D
<pierce>
I rest my case your honour
JanC_ has joined #riscv
<pierce>
Lock him up
JanC is now known as Guest9588
JanC_ is now known as JanC
Guest9588 has quit [Killed (lithium.libera.chat (Nickname regained by services))]
<palmer>
ya, we've had some short ones but I think this takes the cake
<Tenkawa>
pierce: and you did not read "any" context before that we were discussing images and embedding... and btw yes running risc-v inside it "does" run faster fyi
<Tenkawa>
Cheers all... time to go build a replacement rack
Tenkawa has quit [Quit: Was I really ever here?]
JanC has quit [Ping timeout: 265 seconds]
JanC has joined #riscv
MaxGanzII_ has quit [Ping timeout: 240 seconds]
MaxGanzII_ has joined #riscv
pharonix71 has quit [Remote host closed the connection]
pharonix71 has joined #riscv
PobodysNerfect has quit [Ping timeout: 240 seconds]
PobodysNerfect has joined #riscv
jacklsw has joined #riscv
heat_ is now known as heat
jay321 has joined #riscv
MaxGanzII_ has quit [Ping timeout: 240 seconds]
JanC_ has joined #riscv
JanC is now known as Guest4186
JanC_ is now known as JanC
Guest4186 has quit [Killed (lead.libera.chat (Nickname regained by services))]
somlo_ has joined #riscv
somlo has quit [Remote host closed the connection]
<dh`>
realistically what's important about panic/assert messages is that they're identifiable (so if one shows up in a bug report you don't need to waste time trying to figure out exactly what version's on the other end) and say as much as can reasonably be anticipated about what broke (which usually isn't a lot)
<dh`>
ideally they should also have enough encoding redundancy that they don't become incomprehensible when relayed by illiterate marketroids
<dh`>
stuff like "kernel BUG on line 50!" fails badly on all these counts :-|
<muurkha>
my experience with users reporting errors is that usually they don't know what the error message said or if there wass one
<muurkha>
I mean, they saw it, but error message text has never been important to them, so it doesn't register in their memory
<dh`>
right, that often happens but there's nothing you can do about it
<dh`>
what you can do is try to avoid things getting lost by inaccurate transcription from console to phone, or by being relayed through a customer support specialist because engineers aren't allowed to talk to customers
<muurkha>
you might be able to get them to let the software send you the error message directly, if it's networked; Ubuntu does this
<dh`>
enough people get upset about software that phones home that it's not worthwhile
<dh`>
though it depends on context
<muurkha>
a lot of companies have found it worthwhile even when people got upset
<dh`>
well
<dh`>
a lot of companies also do user tracking even when people get upset
<dh`>
and that serves no real purpose besides exploitation
danilogondolfo has quit [Remote host closed the connection]
<muurkha>
that's also true, and I guess I don't have inside knowledge of how helpful voluntary automated crash reports from the field are, and you're right that we can't infer that the answer is "very" simply from the fact that people do it
<muurkha>
all I have is hearsay
<conchuod>
I love the classic, copy-paste the very last line of the error
wingsorc has joined #riscv
Andre_Z has quit [Ping timeout: 265 seconds]
<jrtc27>
nah, screenshot the very last page
<jrtc27>
that's even more painful
<jrtc27>
but yes, make[1]: Error code 1 or whatever is not a very helpful
paulk-bis has quit [Ping timeout: 256 seconds]
<jrtc27>
that or "I cross-compiled the binary and tried to run it but I get executable file format error, help"
<jrtc27>
you'd be surprised how many people genuinely ask that
<jrtc27>
as if somehow they can just run a CHERI-RISC-V CheriBSD binary on an x86_64 Linux system
<jrtc27>
(and I don't think they're aware of qemu-user, so it's not that)
paulk-bis has joined #riscv
<dh`>
then there are the ones who don't understand what you mean when you ask for more information
DynamiteDan has quit [Ping timeout: 268 seconds]
DynamiteDan has joined #riscv
DynamiteDan has quit [Excess Flood]
DynamiteDan has joined #riscv
DynamiteDan has quit [Excess Flood]
DynamiteDan has joined #riscv
<muurkha>
jrtc27: I had that problem just the other day myself ;)
<muurkha>
does qemu-user support CHERI-RISC-V yet?
<jrtc27>
I believe so, though Morello is more widely tested because we use it to build packages there
<jrtc27>
of course, you need to run it atop FreeBSD not Linux though :)
somlo_ is now known as somlo
koorogi has left #riscv [WeeChat 3.7.1]
pecastro has quit [Ping timeout: 268 seconds]
vagrantc has quit [Quit: leaving]
<muurkha>
hmm, I hadn't thought of that
<muurkha>
I suppose running a Linux RISC-V binary with qemu-user on amd64 FreeBSD would probably work fine, though, right?
<muurkha>
because FreeBSD has a Linux system call personality
<jrtc27>
in theory that works
<jrtc27>
dunno if anyone's been crazy enough to try it
<muurkha>
heh
<muurkha>
well probably someone somewhere is developing firmware for a RISC-V Linux embedded system using a FreeBSD dev workstation