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
troglodito has joined #fedora-riscv
davidlt has joined #fedora-riscv
kalev has quit [Ping timeout: 272 seconds]
davidlt has quit [Ping timeout: 260 seconds]
Kevinsadminaccou has quit [Quit: You have been kicked for being idle]
davidlt has joined #fedora-riscv
<davidlt[m]> Less than <2000 packages left in mass rebuild queue.
<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 :)
davidlt has quit [Ping timeout: 272 seconds]
davidlt has joined #fedora-riscv
<davidlt[m]> So Rocket core supports bitmanip and crypto (non-release version)?
<davidlt[m]> Yeah, it seems they might support: RV64IZba_Zbb_Zbc_Zbkb_Zbkc_Zbkx_Zbs_Zknd_Zkne_Zknh_Zksed_Zksh
<davidlt[m]> In not-so-far-away future these ISA strings will be super long :)
<davidlt[m]> HiFive Pro P550 CAD render.
<davidlt[m]> The 3rd slot between PCIe is OCP DC-SCM slot.
<davidlt[m]> Typically this slot is mostly demoed for BMC.
<davidlt[m]> Really nothing new, but that picture :)
<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]> [PATCH 0/4] Zbb + fast-unaligned string optimization
<davidlt[m]> > From: Heiko Stuebner <heiko.stuebner at vrull.eu>... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/faa2b20da8f65792c8af488e5d9a109f73d2e4c8>)
<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).
davidlt has quit [Ping timeout: 260 seconds]
esv_ has quit [Remote host closed the connection]