<somlo>
davidlt[m]: it's weird, but simply just enabling CONFIG_PRINTK_INDEX=y on top of the options used with the f33 kernel config (which worked fine on rocket) results in a crash right at the start: https://pastebin.com/qJLnU2xG
Kevinsadminaccou has joined #fedora-riscv
<somlo>
when the only difference is that I comment out CONFIG_PRINTK_INDEX=y, I get this (working) boot log instead: https://pastebin.com/prCV06V5
<somlo>
so I think I have multiple orthogonal ways to crash in the list of "new" CONFIG_* options; first I'll isolate them all, then address each one individually :)
<somlo>
btw I have bootargs = "console=liteuart earlycon=liteuart,0x12009000 swiotlb=noforce ro root=/dev/mmcblk0p2 LANG=en_US.UTF-8 systemd.default_timeout_start_sec=360s systemd.unit=multi-user.target enforcing=0";
<davidlt[m]>
It could be a bug hiding somewhere and just CONFIG_* makes it crash in a different way.
<somlo>
this particular one fails in "unflatten_dt_nodes()" (the "Error -11 processing FDT" message I'm getting), in drivers/of/fdt.c
<somlo>
how PRINTK_INDEX makes a difference, I have yet to figure out
<davidlt[m]>
Are you sure that your memory map/layout is fine and nothing is overwriting DT stuff (happened before)?
<davidlt[m]>
I think we had these situation before where kernel damaged DT while loading because we had some overlap on the memory map.
<davidlt[m]>
Not a common thing these days.
<somlo>
dt is built into the opensbi blob, which is 0x1ED48 in size, and gets loaded at 0x80000000; the next thing (kernel image) is loaded at 0x80200000
<somlo>
and then initrd at 0x83000000
<somlo>
so nothing *should* clobber the DT, at least not in a way I'd feel personally responsible for :)
<somlo>
but that's a good theory, and figuring out who *is* responsible is probably how I'm going to hopefully fix it :)
<dtometzki>
I registered for updates when available
<somlo>
davidlt[m]: good catch, I should update the isa string in my "manually maintained" DTS file(s)
<davidlt[m]>
somlo: are you using a release version or master branch?
<somlo>
master branch, updated occasionally
<somlo>
I did grab the latest Z* stuff a couple of days ago, but didn't notice the isa string going from "rv64imafdc" to "rv64imafdcXrocket" (whatever *that* all means) :)
<davidlt[m]>
x stands for vendor specific extensions
<somlo>
so "Xrocket" should mean something to the kernel, in terms of available opcodes for certain functions, etc.
<davidlt[m]>
I bet there is nothing
<somlo>
not sure if the Z stuff is implicit in there somewhere, or if I need to do fancy tricks with the chisel builder to turn it on deliberately
<davidlt[m]>
bitmanip and crypto doesn't add new registers IIRC (didn't check crypto) thus those are interesting things to play around
<davidlt[m]>
there is a patch for in-kernel Zbb for string functions under review
<davidlt[m]>
there are was also for zbb + unaligned access optimized versions too.
<davidlt[m]>
somlo: how Rocket handles unaligned stuff? Fast or slow? Is that in HW, or it traps into OpenSBI?
<davidlt[m]>
I think the decision was not to land it until such HW is available :)
<somlo>
I think I'll need to explicitly enable Z* extensions before (re)generating the verilog, and that *should* probably get reflected in the isa string being dumped into the sample dts as well
<somlo>
question is whether the new configuration will still fit on an ecp5 FPGA, or otherwise will require using Xilinx chips (thus precluding "self-hosting" capability)
<somlo>
I got lots of things to play with for after fosdem :)
<davidlt[m]>
Yeah, but if it fits it could improve Linux perf (mostly in the future).