<somlo>
my initial informed guess (based on grepping through the sources) is the second one (no emulation), but I might be missing something elementary :)
<somlo>
(in which case the platform_requirements.md document should probably be reworded a bit for clarification...
<jrtc27>
no emulation, and it never should have existed in bbl
frost has joined #riscv
<jrtc27>
if your hardware doesn't have an FPU, don't build a software stack that assumes there is one
<somlo>
jrtc27: then platform_requirements.txt is needlessly "teasing" uninformed n00bs about the possibility :)
<jrtc27>
no, it's just saying that you build the firmware as rv64ima(c) and if there's an FPU then it'll work
<somlo>
and if my hardware doesn't have an FPU, it'd still be nice to run someone *else's* software stack that assumes stuff, so I mildly disagree with your hard-line stance :D
<jrtc27>
who else is emulating an FPU in privileged firmware?
<jrtc27>
you can't take code that uses SSE and run it on an early 386
<jrtc27>
at that point just use qemu, it'll be faster anyway...
<somlo>
my (admittedly pretty far out there on the fringe) use case doesn't prioritize raw speed -- rather, ability to self-host the entire stack
<somlo>
but being fringe and "out there", I can always carry around some out-of-tree patches for fpu emulation (at some point in the future, if/when I get the my head wrapped around the rest of opensbi)
<somlo>
so, IMHO, it was quite nice of the BBL folks to allow FD emulation, whether or not that's now considered to be "in poor taste" :D
Ivii has quit [Remote host closed the connection]
hexteex has quit [Remote host closed the connection]
jacklsw has joined #riscv
freakazoid343 has joined #riscv
<dh`>
from an OS perspective I'd say that FPU emulation is nice in some cases but usually userlevel softfloat is going to be faster
<dh`>
(as well as less likely to stuff up the machine by having bugs in machine-mode code)
freakazoid12345 has quit [Ping timeout: 240 seconds]
<dh`>
so basically it boils down to: it would be great to have an off-the-shelf softfloat library; and it's up to the OS to handle its configuration management such that it can have hardfloat and softfloat installs that don't get mixed up with each other
<dh`>
this is something OSes are bad at (because it's expensive to have lots of userland builds and they proliferate rapidly)
<dh`>
but it's the Right Way (TM)
<sorear>
alternatively the mips(?) approach where the kernel hotpatches fp instructions in user binaries *hides*
<somlo>
then I built a single payload containing both kernel and fdt (just like I am doing with bbl): `make CROSS_COMPILE=riscv64-unknown-linux-gnu- PLATFORM=generic FW_PAYLOAD_PATH=~/linux/arch/riscv/boot/Image FW_FDT_PATH=~/litex_dts/nexys4ddr_fpu.dts`
<somlo>
the resulting `fw_payload.bin` (renamed as `boot.bin`) loads via tftp to the nexys4ddr (bitstream built with a single fpu-capable 64-bit rocket chip), and ... cricets
<somlo>
luckily, I have an LED "device" and I can write values to it that then show up in the LED configuration, so I can have low-bit-width "debugging printf's" :D
<somlo>
It hangs somewhere *after* `_start` in fw_base.S, and definitely before trying to locate the liteuart in `lib/utils/serial/fdt_serial.c`.
<somlo>
So my platform probably is a bit less "generic" than I would have preferred...
<dh`>
welcome to kernel debugging :-)
<somlo>
At least I have a way to print out 16 bit debug codes to determine whether it made it to a certain spot in the source code or not -- at least it's not boring :)
<dh`>
yeah that's the basic process...
<jrtc27>
rocket has a debug module implementation, I suggest you use it
<somlo>
dh`: this is way before the kernel would even come into play -- I get to output blinkenlight binary codes to determine how far through the sources I've made it, so it's more like the late 60s or something ;P
<somlo>
jrtc27: yeah, it'
<somlo>
it's probably time I took that detour, figuring out how to use the rocket debug module
<jrtc27>
hook it up to jtag, point openocd at it and attach gdb
<somlo>
always felt like figuring that out is its own project worth of work, so I've been putting it off :)
RNeese has left #riscv [#riscv]
RNeese has joined #riscv
<somlo>
jrtc27: then there's the whole of LiteX wrapped all around Rocket, so I need to figure out how that comes into play (or not, whatever)
<jrtc27>
WithJtagDTM(System)
<somlo>
I mean, I need to somehow connect rocket's debug signals to something that eventually travels over usb to openocd running on my host.
<jrtc27>
don't know why both exist, maybe just a public/private interface thing
<jrtc27>
FPGAs normally have IP that deal with JTAG for you
<jrtc27>
you just create a block connected to the wires and it handles all that for you
<somlo>
jrtc27: that's the part I'm (very) unfamiliar with, plus how it may or may not interfere/interact with the rest of LiteX -- the "it's a whole 'nother project" part, at least for me ;)
<somlo>
but yeah, I'm getting to where that's on my critical path...
<RNeese>
what riscv boards are you guys playing with ?
<RNeese>
or are you using vm
<jrtc27>
alternatively, simulate it?
<somlo>
something something about "granting me the serenity to learn the things I can't avoid, stay blissfully ignorant about everything else, and the wisdom to know the difference" :D :D
<jrtc27>
if it's early opensbi boot, shoving it all through verilator is presumably not too atrociously slow
<somlo>
jrtc27: that (verilator) might definitely be the path of least resistance
<somlo>
I think there's a way to "side-load" stuff into the simulated RAM, so I don't have to wait the couple of hours it would take to simulate a 15MB file transfer over "tftp" :D
<somlo>
so I'll try that first. But it definitely bothers me that I'm scared of the jtag debugging thing, so I might set aside a few hours/days/weeks to force myself and go through it once...
<jrtc27>
there's also the lazy option of hooking up external pmod/gpio/whatever pins you have on this board directly to rocket's jtag
<somlo>
huh, it would definitely have the advantage of reducing one's cognitive load -- have a separate cable, know where the wires are going, avoid fighting the rest of the SoC and its own ideas about trying to help you do jtag debugging, etc.