bauruine has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
Andre_H has quit [Quit: Leaving.]
cousteau has joined #riscv
<cousteau>
Hi
<cousteau>
Is there a blog entry or a document or something explaining the details of the removal of the N extension? I recall it was because it was incomplete and needed some rework but I'd like to read on the topic
<cousteau>
I see that N is "tentatively reserved for user-level interrupts extension" so I assume this means at least it'll be coming back
EchelonX has joined #riscv
EchelonX has quit [Client Quit]
Noisytoot has quit [Ping timeout: 252 seconds]
prabhakarlad has joined #riscv
conordooley has joined #riscv
<conordooley>
mmind00: or atishp[m][m]: who would know better than I - is the d1 meant to be the only cmo errata chip?
<mmind00>
conordooley: in an ideal world every chip would implement the one and only zicbom extension ... but then real life happens ;-)
<conordooley>
Aye, but at what point do you go "well zicbom exists, so use that or you're not acceptable upstream"
<conordooley>
Because that is s/zicbom/* as time progresses haha
<mmind00>
conordooley: historically the kernel always tried to not prevent support for exotic hardware ... but I guess it's always a matter of how complex the "variant" is
<mmind00>
conordooley: i.e. on the d1, cmo is just zicbom with different instructions ... and we do have ALTERNATIVE_2 (and possibly _3 etc) ;-)
<mmind00>
but for everything else it will be a hard uphill battle for the chip-maker, because doing a suitable implementation will be in their shoulders, and be under heavy scrutiny
<jrtc27>
if they have PMAs then make firmware create a WB NC etc region and pass that as a DMA-capable memory area to the kernel?
<jrtc27>
then the kernel can remain blissfully unaware of the horrors of how that gets implemented
<jrtc27>
like the BeagleV and derivatives
<conordooley>
I need to actually read though the detail of this andes stuff if there's gonna be talk of it in a bof
<geertu>
conordooley: Ah, I guess that was the missing CAOnJCUKLpRz4Fbx1XiMnap-ELw2k1c8E9V8bZiSP+x7z9Z5QrA@mail.gmail.com email?
<conordooley>
yup!
* geertu
found the email in his overful mbox, too. It's lore that doesn't have it...
<jrtc27>
regular reminder that the world isn't just linux and doing too many generic firmware things at linux-specific events excludes people from other communities in those discussions...
<jrtc27>
as much as people in the riscv ecosystem like to equate os/kernel == linux
<conordooley>
*BSD hasn't left my brain that quickly ;)
<conordooley>
My interest in stuff like SBI extensions is from an AMP pov, so other OSes/RTOSes is fairly central haha
<jrtc27>
sure
<jrtc27>
was more talking about the acpi side
<jrtc27>
vendor sbi extensions, whatever, that's boring crap that just sits in some vendor.c file
<jrtc27>
and specific to certain devices
<jrtc27>
acpi we have to live with forever, across all devices and oses
<geertu>
It's been a while I looked at proprietary BSD-derived OS code...
<conordooley>
Jess made me download freeBSD so I didn't break her crap :)
<conordooley>
Not run it outside of QEMU though..
cousteau_ has joined #riscv
<prabhakarlad>
jrtc27: can you please point me to BeagleVÂ implementation of the PMA.
aerkiaga has joined #riscv
<jrtc27>
I have not seen the implementation, that's just what I've been told happens
<conordooley>
prabhakarlad: try their github I guess
cabal704 has joined #riscv
<conordooley>
starfive-tech I think it is
cabal704 has quit [Ping timeout: 268 seconds]
cabal704 has joined #riscv
\subline has quit [Ping timeout: 260 seconds]
cabal704 has quit [Read error: Connection reset by peer]
cabal704 has joined #riscv
conordooley has quit [Quit: Client closed]
vagrantc has joined #riscv
BootLayer has joined #riscv
\subline has joined #riscv
cabal704 has quit [Read error: Connection reset by peer]
<prabhakarlad>
conordooley: thanks.
cabal704 has joined #riscv
BootLayer has quit [Read error: Connection reset by peer]
BootLayer has joined #riscv
Trifton has quit [Ping timeout: 252 seconds]
aerkiaga has quit [Remote host closed the connection]
Trifton has joined #riscv
Andre_H has joined #riscv
indy has joined #riscv
jmdaemon has joined #riscv
cabal704 has quit [Ping timeout: 268 seconds]
cabal704 has joined #riscv
Trifton has quit [Ping timeout: 244 seconds]
cabal704 has quit [Read error: Connection reset by peer]
cabal704 has joined #riscv
frkzoid has joined #riscv
jellydonut has joined #riscv
matt__ has quit [Ping timeout: 255 seconds]
cabal704 has quit [Read error: Connection reset by peer]
eroux has quit [Ping timeout: 252 seconds]
cabal704 has joined #riscv
eroux_ has joined #riscv
cabal704 has quit [Read error: Connection reset by peer]
cabal704 has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
cabal704 has quit [Read error: Connection reset by peer]
zns has joined #riscv
cabal704 has joined #riscv
davidlt has joined #riscv
Andre_H has quit [Ping timeout: 260 seconds]
eroux has joined #riscv
eroux_ has quit [Ping timeout: 244 seconds]
KombuchaKip has quit [Ping timeout: 244 seconds]
nvmd has joined #riscv
cabal704 has quit [Read error: Connection reset by peer]
prabhakarlad has quit [Quit: Client closed]
cabal704 has joined #riscv
<atishp[m][m]>
conchuod: There is visionfive board V1 which was produced in very limited numbers
<atishp[m][m]>
I hope their new one doesn't have any of those issues. V1 had different issues around non-coherent DMA though
<conchuod>
From what Icynow/dram/Emil have said, it does not have the same issues.
<atishp[m][m]>
I have submitted the RISC-V BoF for Linux plumbers. Once it is up in the schedule, I can share.
<atishp[m][m]>
Sorry for the html formatting. Didnot realize that until I got the bounce notification :(
<conchuod>
You will never be forgiven
<conchuod>
;)
<atishp[m][m]>
:D
<muurkha>
heh
<atishp[m][m]>
FYI: The RISC-V BoF is planned towards the patch acceptance policy for ACPI & vendor SBI extension in Linux
<atishp[m][m]>
Any generic ACPI related discussions will/should happen within RVI
cabal704 has quit [Ping timeout: 260 seconds]
<conchuod>
I meant to point that out earlier ^
<conchuod>
Mustve forgot :(
<conchuod>
I guess I shall not be forgiven either
cabal704 has joined #riscv
cousteau_ has quit [Read error: Connection reset by peer]
eroux has quit [Ping timeout: 244 seconds]
eroux has joined #riscv
BootLayer has quit [Quit: Leaving]
cabal704 has quit [Read error: Connection reset by peer]
orionwl is now known as laanwj
cabal704 has joined #riscv
Noisytoot has quit [Excess Flood]
Noisytoot has joined #riscv
<zns>
whats a good mcu for a beginner to get familiar with the riscv isa?
<zns>
i only have experience with atmega328p (not using arduino-core) and C
<zns>
or is it a better starting place to just emulate? not sure what the options for emulation are on apple silicon
<jrtc27>
qemu
<jrtc27>
or spike if you want to for some reason
<jrtc27>
never got why people care about it so much, qemu isn't hard to extend
<conchuod>
What's ron's IRC name again
<muurkha>
different people have different balances of preferences for writing fresh programs or extending existing ones
<muurkha>
reading somebody else's code, much less navigating a strange codebase, isn't exactly the same skillset as writing and debugging your own
<mps>
zns: today I'm working on upgrading qemu VM for alpine linux on apple silicon
<jrtc27>
but qemu goes fast and has io
<jrtc27>
spike is slow and does not have io
<conchuod>
What about renode :thinking:
radu242 has quit [Ping timeout: 268 seconds]
<zns>
i haven't messed around with qemu yet, looks like quite a bit of flags to learn lol, time to read up i guess
<muurkha>
I set up qemu-user to be able to run cross-compiled RISC-V binaries as if they were native
<muurkha>
for some reason this was a bit of a struggle on Ubuntu
<mps>
muurkha: I also use qemu-user to build VM images from shell scripts for different arches
<muurkha>
I'm not using qemu-user to build things, just to run them
<muurkha>
I'm just building things with a cross-compiler
<courmisch>
cross compilation broke for me
<courmisch>
well compilation is OK, but static linking is busted
cabal704 has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 244 seconds]
Andre_H has joined #riscv
<muurkha>
static linking was easier to get working, getting dynamic linking to work required some setup in qemu
matt__ has joined #riscv
<muurkha>
well, above all in binfmt_misc, but later I found that there was a way to do it configuring just qemu without messing with the binfmt_misc stuff
<mps>
is it possible to make static binary with glibc
<muurkha>
pretty much
frkzoid has quit [Ping timeout: 244 seconds]
<mps>
afaik no
<muurkha>
I mean gcc -static generates a binary that doesn't need ld.so to run
<muurkha>
even if you're using glibc
<mps>
from which glibc version
<mps>
I still didn't saw fully static binary made with glibc
<mps>
but I'm not using glibc in last 3-4 years
matt__ is now known as freakazoid333
<muurkha>
not sure what "fully static" means in this context, but file(1) says "ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked"
<muurkha>
ldd says "not a dynamic executable"
<muurkha>
and objdump --full-contents doesn't show an .interp
Andre_H has quit [Ping timeout: 252 seconds]
<mps>
ah, maybe it works now with glibc
<muurkha>
this is with a version of glibc many years old
<mps>
not sure is it still possible when some specific libs are needed
<muurkha>
cat /proc/11360/maps shows only 7 mappings: two for the executable, [heap], [stack], [vdso], and [vsyscall]
<muurkha>
none for ld.so or any dynamic libraries
<muurkha>
maybe by "not fully static" you are referring to the [vdso] and [vsyscall] mappings?
<muurkha>
that's not a glibc thing but a Linux thing
<mps>
hmm, I'm not sure, long time didn't checked this
<muurkha>
maybe you mean that things like PAM want to be able to load, say, PAM modules, dynamically?
<mps>
no, not this
<muurkha>
I'm sure it's possible for some library to have a bug that is masked when linked dynamically
<mps>
iirc programs which need some network or nss libs can't be fully static, but I could be wrong
<muurkha>
I think the nss thing is the same thing as PAM
<dh`>
I remember at one point there were issues, but not what, just filed it in my head in the 'drepper' bin along with everything else
<dh`>
nss is the same issue as pam (plugin libs) but not the same thing :-)
<muurkha>
yeah
<mps>
I could ask on #musl
<mps>
guess someone there know current state
<dh`>
one of the things on my never-ending todo list is to improve netbsd's nsswitch, and part of that (to avoid certain regressions) was figuring out a way to allow something like plugins to work on a statically-linked system
<muurkha>
heh
<dh`>
came to the conclusion that for any of this kind of plugin it's sufficient to be able to open a pipe and fork a subprocess
<muurkha>
as a general rule you can do things with IPC or library calls as you wish
<muurkha>
but it's not always equally easy
<dh`>
(pam is harder but pam should just be turned off unconditionally)
<muurkha>
nsswitch is harder to just turn off unconditionally
<dh`>
right
nvmd has quit [Quit: WeeChat 3.6]
aerkiaga has joined #riscv
KombuchaKip has joined #riscv
prabhakarlad has joined #riscv
wingsorc has quit [Remote host closed the connection]
wingsorc__ has quit [Quit: Leaving]
wingsorc has joined #riscv
Noisytoot has quit [Excess Flood]
Noisytoot has joined #riscv
<conchuod>
palmer: for-next question: If I want to base on top of something that only made it in in rc5 how do I go about that in a way that doesnt make a mess at PR time? Just wait til second week of the MW for my PR?
<conchuod>
I could easily split things, I am just wondering that's all.
Starfoxxes has quit [Ping timeout: 252 seconds]
eroux has quit [Ping timeout: 244 seconds]
Starfoxxes has joined #riscv
<palmer>
if it landed via my fixes tree, they're all on top of rc1