sorear[m] changed the topic of #riscv to: Matrix users: #riscv:libera.chat will be ending operation NET Jul 25; please test #riscv:catircservices.org as a replacement | RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
GenTooMan has quit [Ping timeout: 258 seconds]
EchelonX has quit [Quit: Leaving]
GenTooMan has joined #riscv
esv has quit [Remote host closed the connection]
esv has joined #riscv
frkzoid has joined #riscv
_whitelogger has quit [Ping timeout: 246 seconds]
_whitelogger has joined #riscv
mturquette has quit [Ping timeout: 245 seconds]
mturquette has joined #riscv
frkazoid333 has quit [Ping timeout: 246 seconds]
vagrantc has quit [Quit: leaving]
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #riscv
rvalles has quit [Quit: rvalles]
rvalles has joined #riscv
EchelonX has joined #riscv
aerkiaga has joined #riscv
BootLayer has joined #riscv
junaid_ has joined #riscv
unsigned has joined #riscv
joev1 has quit [Ping timeout: 245 seconds]
joev1 has joined #riscv
crabbedhaloablut has joined #riscv
joev1 has quit [Ping timeout: 246 seconds]
joev1 has joined #riscv
eroux has quit [Ping timeout: 240 seconds]
eroux has joined #riscv
joev1 has quit [Ping timeout: 260 seconds]
joev1 has joined #riscv
joev1 has quit [Ping timeout: 244 seconds]
joev1 has joined #riscv
geertu has quit [Ping timeout: 240 seconds]
geertu has joined #riscv
hightower2 has joined #riscv
cousteau_ has joined #riscv
cousteau has quit [Ping timeout: 244 seconds]
deflated8837 has quit [Read error: Connection reset by peer]
deflated8837 has joined #riscv
aburgess has quit [Ping timeout: 250 seconds]
MarvelousWololo has quit [Read error: Connection reset by peer]
meta-coder has joined #riscv
joev1 has quit [Ping timeout: 260 seconds]
joev1 has joined #riscv
unsigned has quit [Quit: .]
joev1 has quit [Ping timeout: 260 seconds]
joev1 has joined #riscv
junaid_ has quit [Quit: leaving]
Leopold has quit [Remote host closed the connection]
Leopold has joined #riscv
ntwk has joined #riscv
joev1 has quit [Ping timeout: 264 seconds]
joev1 has joined #riscv
aburgess has joined #riscv
joev1 has quit [Ping timeout: 264 seconds]
joev1 has joined #riscv
pecastro has joined #riscv
Stat_headcrabed has joined #riscv
meta-coder has quit [Ping timeout: 260 seconds]
Tenkawa has joined #riscv
jmdaemon has quit [Ping timeout: 246 seconds]
aerkiaga has quit [Remote host closed the connection]
meta-coder has joined #riscv
meta-coder has quit [Client Quit]
sauce has quit [Ping timeout: 246 seconds]
<pabs3> nice, Debian is starting to bootstrap an official riscv64 port https://deb.debian.org/debian/dists/sid/main/binary-riscv64/
Andre_Z has joined #riscv
<Stat_headcrabed> Nice
<Tenkawa> Yeah nice indeed
<gurki> im having a hard time finding companies offering riscv chiplets. does someody in here know of any such offerings?
<gurki> im shooting for low qty
<gurki> this is for a random poc that crossed my mind a while ago, im not even set on a specific rv implementation. id probably prefer a small one though
<Stat_headcrabed> Seems some companies are working on JH7110 SOMs
<Stat_headcrabed> Including milkv
<sorear> i had no idea it was possible or useful to buy chiplets in low qty, full stop
aerkiaga has joined #riscv
<gurki> yes to both
<gurki> its not exactly sth a consumer would do ofc
<sorear> everything i've heard about chiplets has been in the high end
aredridel has joined #riscv
<hightower2> great pabs3
JanC has quit [Ping timeout: 240 seconds]
JanC has joined #riscv
freakazoid332 has joined #riscv
frkzoid has quit [Ping timeout: 260 seconds]
pecastro has quit [Remote host closed the connection]
GenTooMan has quit [Ping timeout: 260 seconds]
junaid_ has joined #riscv
aerkiaga has quit [Ping timeout: 246 seconds]
junaid_ has quit [Remote host closed the connection]
GenTooMan has joined #riscv
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #riscv
vagrantc has joined #riscv
vagrantc has quit [Quit: leaving]
junaid_ has joined #riscv
troglodi1o has quit [Read error: Connection reset by peer]
___nick___ has joined #riscv
___nick___ has quit [Client Quit]
___nick___ has joined #riscv
___nick___ has quit [Client Quit]
___nick___ has joined #riscv
troglodito has joined #riscv
junaid_ has quit [Quit: Lost terminal]
aerkiaga has joined #riscv
aerkiaga has quit [Remote host closed the connection]
Andre_Z has quit [Quit: Leaving.]
markus-zzz has joined #riscv
junaid_ has joined #riscv
<markus-zzz> Is it possible to configure Linux with CONFIG_RISCV_M_MODE while using a MMU? I can't seem to find that option in the 'make menuconfig' ..
<markus-zzz> I'd like to start playing around with mmu stuff without having to also include opensbi at the same time
<sorear> no
<markus-zzz> why is that?
<sorear> M-mode instruction and (by default) data accesses bypass the MMU, S-mode linux assumes that it's running at a virtual address and that kernel and user virtual addresses are equivalent
raym has quit [Ping timeout: 240 seconds]
<markus-zzz> ah, I see
<markus-zzz> so opensbi would be the only way then I guess
junaid_ has quit [Remote host closed the connection]
<markus-zzz> Regarding OpenSBI, looking at e.g. platform/generic/objects.mk I see comments that FW_PAYLOAD_OFFSET needs to be 4MB aligned for 32-bit system. What does that mean exactly, that I need to 4MB on just the OpenSBI blob or are these some kind of virtual addresses at this point?
<sorear> on the linux side it's documented as a constraint on physical addresses, not virtual
<markus-zzz> hmm, right. so then, at least for simplistic schemes, one would end up with quite a big hole when putting the opensbi and linux images in physical memory.
<sorear> i feel like this should be easy to fix, especially now that linux maps itself with 4K pages to avoid mapping firmware-reserved areas
<sorear> but tiny memory, especially on rv32, isn't something that's gotten a lot of attention
<markus-zzz> so it used megapages (is that what the spec calls them) to map itself before then?
<sorear> i think so
<markus-zzz> Anyway I guess I should just consider that a temporary inconvenience then and move on. Hoping that it will solve itself in the meantime. Thanks for the info!
<sorear> also the riscv linux kernel is historically NOT position-independent code, so it would need to be loaded in such a way that it can be mapped at the correct link address. support for multiple paging depths + KASLR complicates this
Stat_headcrabed has quit [Quit: Stat_headcrabed]
JanC_ has joined #riscv
JanC has quit [Read error: Connection reset by peer]
JanC_ is now known as JanC
JanC_ has joined #riscv
JanC has quit [Read error: Connection reset by peer]
JanC_ is now known as JanC
junaid_ has joined #riscv
sauce has joined #riscv
junaid__ has joined #riscv
junaid__ has quit [Quit: leaving]
junaid_ has quit [Remote host closed the connection]
cronos has quit [Quit: ZNC - https://znc.in]
cronos has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
markus-zzz has quit [Quit: Client closed]
___nick___ has quit [Ping timeout: 260 seconds]
<muurkha> sorear: I'm thinking that relinking my kernel at boot time would be far preferable to slowing down every system call by 5% or whatever during the whole time the system is running. if we were talking about a kernel that booted in 10 milliseconds or something I might feel different
<sorear> no proper relocations either
BootLayer has quit [Quit: Leaving]
<muurkha> but Linux takes like a minute typically, even on my cellphone
<sorear> (and it's not 5%, this isn't i386)
<muurkha> yeah, you'd have to give it proper relocations, and actually write a linker
<muurkha> maybe, but doesn't conventional PIC still imply you lose a register, and constantly indirect your accesses to global through a GOT?
<sorear> something that applies text relocations can be much simpler than a linker, no need for symbol name -> address lookups or section layout calculations
<muurkha> I'm pretty ignorant about dynamic linking so maybe I'm making some kind of basic error here
<muurkha> losing a register on RISC-V is less serious than on ARM32 or amd64 I guess
<muurkha> [or especially i386]
<sorear> (lose a register) this only applies on architectures that have no native support for PC-relative addressing (globals through a GOT) yes for -fPIC, no for -fPIE, the latter is appropriate here
vagrantc has joined #riscv
<muurkha> hmm, interesting, why is that?
vagrantc has quit [Client Quit]
vagrantc has joined #riscv
merry has joined #riscv
<sorear> which half?
vagrantc has quit [Quit: leaving]
vagrantc has joined #riscv
Tenkawa has joined #riscv
jmdaemon has joined #riscv
Tenkawa has quit [Quit: ... ... ... ... ...]
Tenkawa has joined #riscv
flip214_ has joined #riscv
flip214 has quit [Read error: Connection reset by peer]
Tenkawa has quit [Quit: Was I really ever here?]
<muurkha> sorry, I meant the latter
<muurkha> why yes for -fPIC but no for -fPIE?
MarvelousWololo has joined #riscv
joev1 has quit [Ping timeout: 260 seconds]
joev1 has joined #riscv
joev1 has quit [Ping timeout: 260 seconds]
joev1 has joined #riscv