dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
codedude44 has joined #fedora-riscv
codedude44 has quit [Client Quit]
esv_ has joined #fedora-riscv
AurabindoJ[m] has joined #fedora-riscv
esv has quit [Ping timeout: 252 seconds]
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv
tg has quit [Quit: tg]
jcajka has joined #fedora-riscv
esv_ is now known as esv
omac777_2022 has joined #fedora-riscv
omac777_2022 has quit [Quit: Leaving]
jcajka has quit [Quit: Leaving]
<somlo> palmer: ping
<palmer> what's up?
<somlo> so I'm running Fedora on a fpga based rocketchip (with litex around it); had to use the latest available linus kernel plus liteuart patches, but otherwise I've been trying to stick with the "stock" fedora kernel configuration maintained by davidlt here: http://fedora.riscv.rocks:3000/rpms/kernel/src/branch/f37-riscv64/kernel-riscv64-fedora.config
<somlo> trouble is, if any *one* of the following config options is enabled, the kernel crashes during boot on the rocketchip/litex rig:
<somlo> CONFIG_PRINTK_INDEX=y
<somlo> CONFIG_FB_EFI=y
<somlo> CONFIG_COMPAT_32BIT_TIME=y
<somlo> CONFIG_DTPM_CPU=y
<somlo> CONFIG_IMA_KEXEC=y
<somlo> CONFIG_CRYPTO_ECDH=y
<somlo> CONFIG_FPROBE=y
<somlo> no idea why, doesn't make any sense to me :) For instance, if I turn on CONFIG_PRINTK_INDEX, I get this: https://pastebin.com/zHLtNvf1
<somlo> if all of the above are commented out, it boots fine, with no problems whatsoever
<somlo> anyway, I'm looking for advice on how to even start debugging something like this (unless you somehow have run into pending riscv related issues that might provide a clue)
<palmer> if it reproduces on QEMU that's easiest, can you check if similar stuff is going on?
<palmer> it could also just be some sort of size-related issue, there's some baked in memory layouts in various firmwares
<Esmil> somlo: btw. i never got to ask you at fosdem. How come you're using rocketchip and not VexRiscv? that's what i see most other use to run linux on fpgas. is it because vexriscv doesn't come in 64bit yet?
<somlo> no such luck, works perfectly fine on qemu :(
<somlo> palmer: tried leaving more room for the initrd (there's plenty of room for the kernel after opensbi and before initrd, might try more of that but it's a shot in the dark at this point
<somlo> Esmil: vexriscv is 32-bit, fedora needs 64-bit
<Esmil> right, ok. so the goal is to run a regular distro and not something like yocto or buildroot
<somlo> rocket was (is?) the most feature-complete 64-bit soft-core I'm currently aware of, and since I'm integrating so many moving parts from so many different places, I wanted to go with the path of least resistance
<Esmil> yeah, makes sense
<somlo> Esmil: right, since fedora already has all those nice RPM packages for things like gcc, yosys, trellis, nextpnr -- that one can just run and rebuild one's underlying bitstream
<somlo> also, the long-term goal is a self-hosting *computer* (that might one day do useful computer-y things), not "merely" an embedded system :D
<Esmil> yeah. btw. you know about bunnie huang's precursor project right? he talks about a lot of the same reasons for going with an fpga so he can "hash" the hardware and trust it
<Esmil> (except i think the goal is more of a secure mobile phone than a secure workstation)
<somlo> yeah, I was aware of it -- it's really a complementary (rather than competing/overlapping) project: they focus a lot on physical ability to inspect the PCB, traces, etc., but don't have "ability to build itself *on* itself" as a goal
<Esmil> right