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
<davidlt[m]> I switched back the main kojid to 256 maxjobs. What I don't like is probably the default Koji priorities. I might try to play with custom policies later on.
somlo has quit [Remote host closed the connection]
somlo has joined #fedora-riscv
tibbs has quit [Quit: ZNC 1.8.2 - https://znc.in]
tibbs has joined #fedora-riscv
<somlo> if I run that test on the fedora kernel I built from latest upstream (with the official un-edited f37 .config), it comes in *below* 0x2200000
<somlo> and yet, manually increasing that to 0x2400000 fixes all my issues -- which means portions of my kernel were getting clobbered by opensbi when it copied the DTB to 0x82200000
<somlo> not sure why that specific list of config options made a difference, but I was basically testing for what config options get my kernel to be small *enough* not to get trampled by opensbi and the dtb :D
<somlo> I now have a new problem, though: if I use the rocket-chip's "official" isa string ("rv64imafdcZicsr_Zifencei_Zihpm_Xrocket"), I get an "illegal opcode" crash when the boot process hits this: https://github.com/torvalds/linux/blob/master/arch/riscv/kvm/mmu.c#L765
<somlo> but that's clearly on the rocket chip implementation (using just "rv64imafdc" boots fine, as linux doesn't think it can actually use hypervisor mode)
<somlo> since rocket advertises the capability, it shouldn't throw an exception when someone actually tries to use it, so I'll be opening an issue on rocket-chip once I do some more measurements
<somlo> probably should bring up the opensbi thing with their upstream as well (since I have a clear counter-example to their instructions)