pabs3 has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
pabs3 has joined #riscv
aerkiaga has quit [Remote host closed the connection]
davidlt has joined #riscv
frkzoid has joined #riscv
Trifton_ has quit [Remote host closed the connection]
Trifton_ has joined #riscv
frkazoid333 has quit [Ping timeout: 246 seconds]
paddymahoney has quit [Ping timeout: 246 seconds]
pabs3 has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
pabs3 has joined #riscv
pabs3 has quit [Client Quit]
valdemaras has joined #riscv
pabs3 has joined #riscv
ldevulder has joined #riscv
ezulian has joined #riscv
cousteau has quit [Ping timeout: 260 seconds]
handsome_feng has joined #riscv
ssb has joined #riscv
valdemaras has quit [Quit: valdemaras]
danilogondolfo has joined #riscv
<mps>
Stat_headcrabed: in my case behavior is opposite. Without nvme drive installed it boots but with it kernel boots but it is stuck probing for nvme
danilogondolfo has quit [Remote host closed the connection]
Wickram has joined #riscv
valdemaras has joined #riscv
<muurkha>
I am pleased to see that Godbolt's compiler explorer displays relocations in disassembly: https://godbolt.org/z/arxe8o8qz
valdemaras has quit [Quit: valdemaras]
danilogondolfo has joined #riscv
jacklsw has quit [Ping timeout: 240 seconds]
jacklsw has joined #riscv
prabhakarlad has joined #riscv
MaxGanzII has quit [Ping timeout: 246 seconds]
cousteau has joined #riscv
sakman has quit [Remote host closed the connection]
jacklsw has quit [Ping timeout: 244 seconds]
sakman has joined #riscv
Andre_Z has joined #riscv
BootLayer has quit [Quit: Leaving]
EchelonX has joined #riscv
ntwk has joined #riscv
EchelonX has quit [Quit: Leaving]
EchelonX has joined #riscv
valdemaras has joined #riscv
MaxGanzII has joined #riscv
joev1 has quit [Ping timeout: 246 seconds]
joev1 has joined #riscv
joev1 has quit [Ping timeout: 246 seconds]
joev1 has joined #riscv
jmdaemon has quit [Ping timeout: 260 seconds]
Tenkawa has joined #riscv
hightower2 has joined #riscv
hightower4 has quit [Ping timeout: 244 seconds]
ntwk has quit [Quit: ntwk]
hightower2 has quit [Ping timeout: 246 seconds]
handsome_feng has quit [Quit: Connection closed for inactivity]
prabhakarlad has quit [Quit: Client closed]
BootLayer has joined #riscv
prabhakarlad has joined #riscv
Andre_Z has quit [Quit: Leaving.]
Stat_headcrabed has joined #riscv
stolen has joined #riscv
pabs3 has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
<Tenkawa>
leah2: the bigger question is that someone needs to ask them: Where do each of these match up in the categories... They obviously aren't apples to apples units to each other for performance specs
<leah2>
yes
<Tenkawa>
Part of the problem is its so hard to get good comparisons yet
<sorear>
ask who?
<leah2>
but building gcc is close to my target usage, and the only thing the lpi4a seems to do better in is having more ram and perhaps a vector unit
<leah2>
vs able to work with no fan, nvme and being cheaper...
<Tenkawa>
sorear: These are like comparing a street car and a purpose tuned car in certain situations... these test cases are not good
<sorear>
which test cases?
<leah2>
linked in the hn post
<Tenkawa>
The various ones in that post and others over the last 2-3 weeks
cronos has joined #riscv
<Tenkawa>
There needs to be an actual benchmark suite built
<leah2>
i think the vf2 is a better deal atm, has more community support behind it too
<Tenkawa>
I sure like mine
<leah2>
and can be simply bought from amazon
hightower2 has quit [Ping timeout: 240 seconds]
<Tenkawa>
My Star64 is "ok"... but needs more to get it to the VF2's level
<drewfustini>
I
<Tenkawa>
It has nice performance but the kernel still needs work
<Tenkawa>
the VF2
<Tenkawa>
is easy to get up to 6.x
<leah2>
also vf2 seems to have less fucked boot
<mps>
Tenkawa: how long it takes to build kernel on VF2 for you
<mps>
with FS on nvme
<Tenkawa>
mps: I'd have to run another one.. I usually set it and walk away... I'm also running 2 nodes clustered with ccache
<mps>
in my test it takes 2 hours
<Tenkawa>
icecc + ccache
<Tenkawa>
mine are also trimmed down a lot in the config
<drewfustini>
For a RISC-V system without an MMU, I know that Linux supports !MMU for RISC-V which is used on the K210. I am wondering if it is possible for Linux to run in S-Mode, instead of M-Mode, with !MMU. I am thinking S-Mode would be a problem because no virtual memory. Anyone have opinion on that?
<drewfustini>
My interest in S-Mode is that I would like to still run SBI firmware in M-Mode and I wasn't sure how that would work if Linux was also in M-ode
random-jellyfish has joined #riscv
fanta1 has left #riscv [#riscv]
davidlt has joined #riscv
<jrtc27>
S-mode can be run MMU-less as much as M-mode; SATP has Bare translation mode
<jrtc27>
question is whether you should I guess...
<jrtc27>
Linux currently conflates no-MMU and M-mode
<jrtc27>
(I mean, I'm of the view that no-MMU shouldn't exist at all, but... :))
<sorear>
CONFIG_RISCV_M_MODE and CONFIG_MMU are separate symbols, although I doubt anyone has tested RISCV_M_MODE=n MMU=n
<sorear>
I also am unsure if any existing MMU-less hardware implements S-mode
<drewfustini>
Thanks for the insights jrtc27 and sorear ... it sounds like it might make more sense for me to figure out if M-Mode Linux can ECALL into OpensBI
<sorear>
that wouldn't work
<jrtc27>
huh, didn't know they were separate
<sorear>
you can only have one M-mode trap handler and it's either defined by linux or opensbi
<drewfustini>
hmm... I'm trying to figure out how the trap-n-emulate functionality already in OpenSBI could be used if Linux is in M-Mode
<drewfustini>
ah
<jrtc27>
~~save opensbi's mtvec on entry to linux and jump to that with the right CSR state as needed~~
<drewfustini>
interesting
<jrtc27>
please don't, all manner of things can go wrong :P
<jrtc27>
that's just the cursed option
heat has joined #riscv
<drewfustini>
this is just a prototype... the are multiple RV64GC cores without MMU and the desire is to see if possible to boot Linux. The production version would have MMU on the cores.
<sorear>
more or less cursed to run linux in U-mode and patch opensbi to emulate priv-1.10?
<drewfustini>
interesting idea
<sorear>
adding 1.9.1 support to linux might be an option now that everything is already saturated with ALTERNATIVE()s for other vendors
<drewfustini>
sorry, I should have said RV64IMC (no atomics) for the prototype. Thus I am interested in trying to see how to still make use of the trap and emulate in OpenSBI
<jrtc27>
that's the one that needs an M-mode call to change the translation mode as it lives in mstatus, with satp being sptbr?
<sorear>
yes
<jrtc27>
the mind boggles as to how that was ever believed to be the right choice
Wickram has quit [Quit: WeeChat 4.0.2]
<sorear>
i could say the same thing about the current approach - there's no guarantee that the system will be able to identity-map *any* RAM on Sv39/Sv48
Andre_Z has joined #riscv
<sorear>
"don't bother with an identity map, load satp, take a page fault, and jump to the next-instruction address in stvec" works but is cursed
<sorear>
things would sort of work if kernel addresses were positive! but we have to treat address 0 as a user-space address for OMAGIC a.out compatibility
<jrtc27>
that cursed approach is what freebsd does
<sorear>
need to support programs that save their state with write(fd, 0, brk(0));
<jrtc27>
CHERI doesn't :)
<jrtc27>
and brk doesn't exist on FreeBSD/arm64+riscv :)
<jrtc27>
come join us in the future :D
<sorear>
the cursed approach works significantly less well for turning _off_ paging
<sorear>
(is that a requirement for uefi runtime services?)
<heat>
uefi RT only requires identity mappings
<heat>
and in fact IIRC riscv UEFI requires MMU on
<heat>
(the only arch that doesn't require an MMU for EFI is IIRC 32-bit x86)
<sorear>
i guess it's expected that you can't do uefi if your RAM doesn't live in 0..2^38 or 0..2^47?
davidlt has quit [Ping timeout: 244 seconds]
<heat>
yes
<heat>
EFI also kinda allocates top-down, so if you have too much memory and not enough lower half address space... yeah, boom
<jrtc27>
32-bit x86 requires an MMU
<jrtc27>
how else are you in 32-bit aka protected mode?
<heat>
protected mode doesn't require MMU
<jrtc27>
I guess if you define MMU to be paging but not segmentation..
<heat>
yes
<sorear>
i've been interpreting it as "a page table is configured"
<heat>
yeah personally i wouldn't really call segmentation MMU, but i guess that's also a valid definition
<jrtc27>
on all but x86 there is no segmentation option, so the two are coincident
<jrtc27>
32-bit x86 is the interesting one
<sorear>
"mmu" is a chip, not an architectural property, and is really a misnomer for how linux is using it
<sorear>
and "requires MMU on" is underspecified if you have several supported memory management modes
random-jellyfish has quit [Quit: Client closed]
<mps>
whenever I see 'P/MMU' word I have hardware in my mind
<gurki>
but what about mpu? :3
<gurki>
(thats the cut-down version in stm32 you can make boot linux with a royal pita)