<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