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
esv_ is now known as esv
esv_ has joined #fedora-riscv
esv_ has quit [Remote host closed the connection]
<davidlt[m]> djdelorie: online?
<djdelorie> yes
<davidlt[m]> djdelorie: try now, you should have admin rights
<djdelorie> davidlt[m]: yup, it works. Yay!
<djdelorie> thanks :-)
rwmjones_ has joined #fedora-riscv
rwmjones has quit [Ping timeout: 252 seconds]
Eighth_Doctor has left #fedora-riscv [#fedora-riscv]
Eighth_Doctor has joined #fedora-riscv
<Eighth_Doctor> 👋
<Eighth_Doctor> Now I'm on the right side of the bridge :)
Eighth_Doctor has left #fedora-riscv [#fedora-riscv]
Eighth_Doctor has joined #fedora-riscv
mbohun[m] has joined #fedora-riscv
<Eighth_Doctor> that was weird
<Eighth_Doctor> meep
<mbohun[m]> (on my HiFive Unmatched PC) yesterday: `dmesg -T | nc termbin.com 9999` => https://termbin.com/6gfx
<mbohun[m]> There seem to be some "weird" problem with changing the `riscv` user's password? like i change the password, reboot the PC, and the user riscv password is reset back to that default (fedora_rocks!) password
Eighth_Doctor has left #fedora-riscv [#fedora-riscv]
<davidlt[m]> mbohun: that shouldn't be the case. You you try to sync before rebooting?
<mbohun[m]> no, i just did `passwd` and entered new password
<mbohun[m]> in fact i tried already 3 times:
<mbohun[m]> - riscv user changing their password
<mbohun[m]> - su changing riscv user's passwor
<mbohun[m]> - today after i installed GNOME, i tried to to change the password through the GUI
<mbohun[m]> I am going to test something, like i am going to add the `riscv` user to some group like "dialout" or whatever and then reboot the PC, and check if that additional group was persisted
<mbohun[m]> I think i see "the" or at least "a" problem:... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/04169dbf9ef2092fa54c6ecb82f56442683681f7>)
jcajka has joined #fedora-riscv
<mbohun[m]> meh maybe not, i was just confused by those "GNOME mounts" at the bottom, previously i had an issue when `/boot` partition was correctly mounted from the nvme0n1p1, but the `/` partition was incorrectly pointing to mmcblk0p2
davidlt has joined #fedora-riscv
<mbohun[m]> I am worried i could have introduce some problem, while i was "re-sizing" the nvme partitions, basically that i could made some file read-only, have to retest again, i think i am getting irrational and paranoid
<davidlt[m]> My advice is avoid having /boot on different boot media
<davidlt[m]> So if you are using NVMe, keep firmware-only on microSD or SPI-NOR Flash.
<davidlt[m]> It sounds that you have full setups on microSD card and NVMe, and that could lead to some annoying issues.
<davidlt[m]> (but nothing serious)
<davidlt[m]> Yeah, because they are the same.
<mbohun[m]> <davidlt[m]> "So if you are using NVMe, keep..." <- my HiFive Unmatched is in a hard-to-access casing, so i did not yet play with those jumpers to setup a boot without microSD
<davidlt[m]> Also there are two /boot partitions with legacy boot flag set now. That shouldn't be an issue as there is a boot order, but systemd might not like non unique UUIDs, etc.
<mbohun[m]> what should i do to fix that?
<davidlt[m]> Remember that rootfs is mounted based on UUIDs.
<davidlt[m]> So maybe you are changing the password, but it's on a wrong thing.
<davidlt[m]> Nuke all partitions (expect fimware) on microSD card.
<davidlt[m]> Or just flash mmc-firmware image into microSD, whichever is easier.
<mbohun[m]> davidlt: on an unrelated topic, is there some workaround/fix for those watchdog "soft lockups" during the boot?
<mbohun[m]> `watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [systemd-udevd:406]`
<davidlt[m]> No
<mbohun[m]> complete dmesg => https://termbin.com/6gfx
<mbohun[m]> fair enough
<davidlt[m]> Those have existed since FPGA designs IIRC
<davidlt[m]> Even on QEMU you tend to get some CPUs stuck messages.
<davidlt[m]> It is improving with newer kernels I would say. So it's becoming less rare.
<davidlt[m]> Ops, it's becoming less common :)
<mbohun[m]> Testing the password change now, i did:... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/2b7c3895fb1bcd95c7fa66535687e22f8c666814>)
<mbohun[m]> ☚ī¸ fedora_rocks!
<mbohun[m]> riscv just logged in
<mbohun[m]> no, not yet, what exactly should i do?
<davidlt[m]> Did you fix the partitions?
<mbohun[m]> nuke those, i remember
<davidlt[m]> flash a different image on microSD, or use fdisk, parted, gparted, etc. to destroy boot and rootfs partitions
<davidlt[m]> I would advice flashing a new image on microSD, just easier, less ways to make mistakes.
<mbohun[m]> where is the firmware on the microSD actually?
<mbohun[m]> yeah, i normally use fdisk
<davidlt[m]> I think, it's part 1 and 2
<davidlt[m]> two partitions, those are small should be easy to identify
<mbohun[m]> i am booting now - actually there was just something weird - today after installing GNOME, the PC shutdown twice on its own after a boot
<mbohun[m]> so basically i can delete `/dev/mmcblk0p3` and `/dev/mmcblk0p4`, right?
<davidlt[m]> FSBL and BBL is firmware
<mbohun[m]> yes, OK
<mbohun[m]> Is there a fedora rawhide for `SiFive VisionFive v1` ? I know there is ubuntu for it, but i am kinda avoiding ubuntu, the ubuntu for HiFive Unmatched was running some ancient kernel, couldn't poweroff, nor reboot
<davidlt[m]> For V1 no. That probably will never get proper upstream support (?).
<davidlt[m]> V2 will be supported.
<mbohun[m]> i want to try to use that VisionFive v1 for a "dashcam" system, basically hook cams and maybe some sensor-s to it
<davidlt[m]> I advice against that.
<davidlt[m]> JH7100 was basically a test chip. It has L2 bug, it has stuff connected to a wrong port on the SoC.
<mbohun[m]> oh :-(
<davidlt[m]> It's not even manufactured anymore. It's a limited run thing.
<davidlt[m]> V2 is the real thing (hopefully).
<mbohun[m]> well, i have only: Unmatched, VisionFive v1, and nezha; i saw the article that VisionFive v2 is now ready for order
<davidlt[m]> Pre-order.
<mbohun[m]> yes, i noticed that, i shipping starts from DEC for the simpler/crappier version
davidlt has quit [Ping timeout: 264 seconds]
<mbohun[m]> no matter what i try after a reboot, or halt/start, riscv's password is back to fedora_rocks!
<Esmil> mbohun[m]: maybe your /etc/fstab doesn't point to the right mount for /, so it's still mounted read-only
Esmil[m] has joined #fedora-riscv
davidlt has joined #fedora-riscv
<davidlt[m]> That's strange. Sadly I cannot test it right now (but your are the 1st one ever to report something like that).
* davidlt[m] testing new fans, thermals, etc.
<mbohun[m]> Is there a wiki page / install guide for installing fedora rawhide no HiFive Unmatched?
<mbohun[m]> - I am more than willing to redo the installation from scratch; unfortunately the docs i read were not very nvme specific, and the fedora wiki page actually mentions only the Unleashed (not Unmatched)
<mbohun[m]> - Even give you ssh access to that box I was using today, if you like.
<davidlt[m]> Wiki is outdated right now. README.md next to the disk images is the newest information (and specific to that disk image, i.e. Unmatched).
<davidlt[m]> Yes, these are the latest images we have right now, but that should be changed to F37 sooner than later I guess (depends how fast I am).
<mbohun[m]> yup, that is the README.md file i was using, but it not very detailed about that nvme isntallation, the mmc installation was without any problems - although that was just an intermediate step to have a look, etc.
<mbohun[m]> i am more than happy to help with updating documentation
<davidlt[m]> I don't need SSH access to your personal box. If you want to connect your Unmatched to Fedora/RISCV Koji infrastructure I still don't need SSH access. I could provide information/create certs/etc for that if you are interested.
<davidlt[m]> If you have FAS accounts (Fedora Account System) you most likely directly can modify Fedora Wiki :)
<davidlt[m]> There are some policy rules (Fedora specific) at which point you get permissions to edit wiki pages directly IIRC.
chuangzhu has quit [Quit: Bridge terminating on SIGTERM]
mhroncok has quit [Quit: Bridge terminating on SIGTERM]
Kevinsadminaccou has quit [Quit: Bridge terminating on SIGTERM]
davidlt[m] has quit [Quit: Bridge terminating on SIGTERM]
Esmil[m] has quit [Quit: Bridge terminating on SIGTERM]
RichardJones[m]1 has quit [Quit: Bridge terminating on SIGTERM]
mbohun[m] has quit [Quit: Bridge terminating on SIGTERM]
nirik[m] has quit [Quit: Bridge terminating on SIGTERM]
jim-wilson[m] has quit [Quit: Bridge terminating on SIGTERM]
acharles has quit [Quit: Bridge terminating on SIGTERM]
defolos has quit [Quit: Bridge terminating on SIGTERM]
varlad[m] has quit [Quit: Bridge terminating on SIGTERM]
leah2 has quit [Ping timeout: 264 seconds]
chuangzhu has joined #fedora-riscv
Kevinsadminaccou has joined #fedora-riscv
defolos has joined #fedora-riscv
acharles has joined #fedora-riscv
jim-wilson[m] has joined #fedora-riscv
Esmil[m] has joined #fedora-riscv
masami has joined #fedora-riscv
nirik[m] has joined #fedora-riscv
varlad[m] has joined #fedora-riscv
mbohun[m] has joined #fedora-riscv
mhroncok has joined #fedora-riscv
davidlt[m] has joined #fedora-riscv
RichardJones[m] has joined #fedora-riscv
leah2 has joined #fedora-riscv
<somlo> davidlt[m]: so i simply did a `touch drivers/tty/serial/liteuart.c` followed by `make` to see what would happen :)
<somlo> took 7 hours (I did not use -j8, silly me :) and there was one line reading "BTF [M] every/single/module.ko" for, well, every single module :D
<somlo> I'll try again with -j8 to see if that's any faster (probably still going to take a few hours)
<davidlt[m]> somlo: ouch, that's painful :)
<somlo> I was hoping once everything is built, make will be smart enough to save some time, but I guess we're well past that in practice, since on "real" hardware it's probably not even noticeable as an "issue" :D
cyberpear has quit [Quit: Connection closed for inactivity]
nirik[m] has quit [*.net *.split]
nirik[m] has joined #fedora-riscv
cyberpear has joined #fedora-riscv
davidlt has quit [Ping timeout: 268 seconds]
rwmjones_ is now known as rwmjones
jcajka has quit [Quit: Leaving]
davidlt has joined #fedora-riscv
<somlo> davidlt: "only" 2 hours with `make -j8` -- even though a single file (built-in driver, *not* module) was touched, make did the whole "BTF" thing on every single .ko module. All such modules now have different checksums w.r.t. the previous `make [modules_insall]` run -- although the new kernel binary seems to load the old modules just fine, so they weren't modified in a *meaningful* way :)
<davidlt[m]> somlo: for the kernel modules that works because the kernel version doesn't change IIR.
<davidlt[m]> somlo: you could try looking into ccache too.
davidlt has quit [Ping timeout: 268 seconds]
<somlo> huh... but wouldn't ccache help only with "CC ..." and not with this "BTF" stuff? I don't think there's a `gcc` command behind the per-module "BTF" thing, whatever that is -- I may have to look into *that* first :)
<javierm> somlo: you could disable by not setting CONFIG_DEBUG_INFO_BTF in your .config
<javierm> somlo: for ccache I use the following: export ARCH=riscv CROSS_COMPILE="ccache riscv64-linux-gnu-"
iooi has quit [Ping timeout: 248 seconds]
iooi has joined #fedora-riscv
<somlo> javierm: I was beginning to formulate a thought that maybe that whole BTF thing might be optional --thanks for fast-tracking that for me! :)
<somlo> I'll probably have to rebuild the whole kernel one more time after turning that off, but if that ends up working OK with fedora it will most likely result in a (much) faster test/rebuild cycle time :)
<javierm> somlo: no worries. I usually disable so that I can rebuild a kernel module to test with an existing kernel image
<javierm> i.e: make M=drivers/gpu/drm/solomon/
<javierm> and then cp drivers/gpu/drm/solomon/ssd130x.ko /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/solomon/
<javierm> which isn't possible if BTF is enabled
masami has quit [Quit: Leaving]