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
alexfanqi has quit [Ping timeout: 255 seconds]
alexfanqi has joined #fedora-riscv
davidlt has joined #fedora-riscv
davidlt has quit [Ping timeout: 244 seconds]
zsun has joined #fedora-riscv
zsun has quit [Client Quit]
davidlt has joined #fedora-riscv
<davidlt[m]> There are a couple of issue blocking building a new disk image, working on it
<davidlt[m]> BTW, U-Boot RC6 is built now too
<davidlt[m]> and one more problem :)
<davidlt[m]> This will take some time, not to mention how long it takes to build the disk image due to xz compression :)
<davidlt[m]> Well this is cooking now: xz -z --block-size=16777216 -T 0 /var/tmp/imgcreate-s9jvdv4e/tmp-3k4qipn6/Fedora-Developer-Rawhide-20220705.n.0-sda.raw
<rwmjones> davidlt[m]: it's the age old issue - https://github.com/facebook/zstd/issues/395#issuecomment-535875379
<rwmjones> I believe I added that comment last time you complained about this :-)
<davidlt[m]> Ah, that's for nbdkit?
<davidlt[m]> Yeah, I just left it as xz. Takes our, but I don't need to patch anything :)
<rwmjones> well it's generally that if we had a seekable zstd then we could use zstd for disk images
<davidlt[m]> I think getting a faster hardware gonna happen faster :)
<davidlt[m]> In this case someone designed a new core, manufacturing it and making a board will be faster than changes happening on the software side :D
zsun has joined #fedora-riscv
bkeys has joined #fedora-riscv
bkeys has quit [Ping timeout: 244 seconds]
bkeys has joined #fedora-riscv
pierosimonet has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
bkeys has quit [Ping timeout: 276 seconds]
pierosimonet has quit [Ping timeout: 276 seconds]
bkeys has joined #fedora-riscv
pierosimonet has joined #fedora-riscv
pierosimonet has quit [Client Quit]
pierosimonet has joined #fedora-riscv
pierosimonet has quit [Client Quit]
pierosimonet has joined #fedora-riscv
pierosimonet has quit [Read error: Connection reset by peer]
<davidlt[m]> New disk image cooked, but haven't yet post-processed it for Unmatched
<davidlt[m]> Esmil: Do you plan to send out PWM LEDs changes?
<Esmil> I can do that, but I didn't follow any previous discussion. Was there a reason the previous patches didn't end up upstream yet?
<davidlt[m]> The only reason why Unleashed and Unmatched doesn't have them because all the patches assigned functions for LED by default instead of leaving that to user-space (e.g. udev rules).
<davidlt[m]> So it's all good, as long as you don't device what specific function LED is assigned for.
<davidlt[m]> In that case it should be OK.
<Esmil> Ok, cool. I'll send them then
bkeys has quit [Ping timeout: 244 seconds]
<Esmil> davidlt[m]: btw. do you still get this at boot: kernel: L2CACHE: DataError @ 0x0000001C.30700230
<davidlt[m]> Yes, IIRC this is mostly some garbage on the line that driver reads at load time.
<Esmil> Yeah, ok. I just noticed the IRQs on the jh7100 was in the wrong order, so that is actually the same interrupt they have trouble with
<davidlt[m]> This happens on FU540 and FU740. I assume that would happen on JH7100 too, and probably JH7110.
<Esmil> on the jh7100 it just keeps firing whereas on the Unmatched it only fires once at boot
<davidlt[m]> Ah, yes, I forgot that there is a bug on JH7100 L2 cache controller.
bkeys has joined #fedora-riscv
<davidlt[m]> I wonder what is impl. register value on JH7100.
pierosimonet has joined #fedora-riscv
davidlt has quit [Ping timeout: 240 seconds]
pierosimonet has quit [Ping timeout: 240 seconds]
pierosimonet has joined #fedora-riscv
davidlt has joined #fedora-riscv
pierosimonet has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 276 seconds]