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
zsun has joined #fedora-riscv
tibbs has quit [Quit: ZNC 1.8.2 - https://znc.in]
zsun has quit [Quit: Leaving.]
tibbs has joined #fedora-riscv
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
troglodito has quit [Ping timeout: 248 seconds]
troglodito has joined #fedora-riscv
<thefossguy> Is there a release schedule for OpenSBI?
<thefossguy> No particular reason, just want a tag to clone instead of a mutating master branch
<davidlt[m]> No
<davidlt[m]> You would need to raise the need for a new tag on the mailing list.
<davidlt[m]> If there is enough positive, it might happen.
<davidlt[m]> I would say right now it's more based on features.
<davidlt[m]> There is SBI v2.0-rc1.
<davidlt[m]> Thus, the new OpenSBI release might happen after that gets ratified.
<thefossguy> Ah, thanks!
<thefossguy> (So much to learn still hehe :D)
somlo has quit [Remote host closed the connection]
somlo_ has joined #fedora-riscv
<davidlt[m]> Usually any commit works.
<thefossguy> That’s what I did
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
<rwmjones> davidlt[m]: I'm having one more go at reproducing the dnf5 thing today by using a mockbuild
<rwmjones> if that still fails, then I will suggest just stubbing out the test
<davidlt[m]> It's most likely mock environment.
<davidlt[m]> I should probably spend more time and enable bootstrap, systemd-nspawn instead of chroot.
<rwmjones> davidlt[m]: what's the mockbuild command you use? I can't get it to use the riscv koji profile ..
<davidlt[m]> I don't use one. I just boot into a brand new VM (or swap a drive on the board).
<davidlt[m]> You can grab the mock config file from a running job.
<davidlt[m]> There is job on nufive.
<davidlt[m]> That's what I do when I need to use mock.
<davidlt[m]> We should probably most that on wiki, and add to our mock-configs.
* rwmjones wonders where it puts the mock config
<davidlt[m]> In temporary work directory :)
<davidlt[m]> It's probably in /var/lib/mock/f38-build-709212-92804
<davidlt[m]> Or something similar.
<rwmjones> yeah I'm looking in there
<rwmjones> what's the file called? not anything obvious
<davidlt[m]> Or it's in /etc/mock/some directory.
<rwmjones> it may not have installed mock yet
<davidlt[m]> it's probably called "f38-build-709212-92804" .cfg or something.
<rwmjones> still doing dnf install
<davidlt[m]> It's running in mock.
<rwmjones> oh I found it
<davidlt[m]> What's the path?
<rwmjones> it's actually in /etc/mock/koji/
<rwmjones> /etc/mock/koji/f38-build-709212-92804.cfg
<davidlt[m]> Yeah.
<davidlt[m]> So you can use that as a template.
<davidlt[m]> Could you fpaste that one?
<davidlt[m]> I might do a smart thing today/tomorrow and that into mock-core-configs so it would work out-of-the-box.
<rwmjones> ok ...
<rwmjones> trying ...
<rwmjones> $ fedpkg --release f38 mockbuild -n --root koji/f38-build-709212-92804.cfg
<davidlt[m]> You might need to modify it a bit.
<davidlt[m]> As it might have paths for existing running job in it.
<davidlt[m]> And you really don't want to mess up existing buildroot as a task is cooking.
<rwmjones> I'm running it on the other machine
<rwmjones> and in fact it seems fine
<davidlt[m]> Could you fpaste cfg?
<rwmjones> sure ..
<davidlt[m]> The only thing you want to change is bareurl.
<davidlt[m]> Well, in general it would point to "latest", not a particular koji internal repo.
<rwmjones> ok
<rwmjones> it's running now so I'll leave it alone
<davidlt[m]> Those are garbage collected. So in the future replace 92804 to latest.
<rwmjones> yup
<davidlt[m]> The only other two things you might want to do is to switch to systemd-nspawn (i.e. container) instead of chroot.
<davidlt[m]> We used to do that back in 2018 (and it mostly worked), but we switched back to chroot as that's what Fedora used.
<davidlt[m]> Now Fedora is using systemd-nspawn by default (we aren't).
<davidlt[m]> Just incase chroot itself is what causes a problem.
<rwmjones> ok, I'll see if this one fails first
<davidlt[m]> Bootstrapping probably will not cause any issues (at least with DNF5).
<rwmjones> grrr python--
<rwmjones> this is not going well
<rwmjones> what's the setting for changing chroot to systemd-nspawn?
<rwmjones> hmm the manual says the default should be systemd-nspawn
<rwmjones> no it is using chroot according to the messages
<rwmjones> ok let's try ...
<rwmjones> $ fedpkg --release f38 mockbuild -n --root /etc/mock/koji/f38-build-709212-92804.cfg -- --isolation=nspawn
<davidlt[m]> It's in site-defaults.cfg
<davidlt[m]> There is one variable that defines that. Just place that into your config.
<rwmjones> ok
<rwmjones> weird, it still uses chroot ...
<rwmjones> I can't get past this one:
<rwmjones> ERROR: Command failed: # /usr/bin/dnf --installroot /var/lib/mock/f38-build-709212-92804-bootstrap/root/ --setopt=install_weak_deps=0 --disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock install dnf dnf-plugins-core
<rwmjones> Unable to detect release version (use '--releasever' to specify release version)
<rwmjones> No matches found for the following disable plugin patterns: local, spacewalk, versionlock
<rwmjones> [Errno 2] No such file or directory: '/var/lib/mock/f38-build-709212-92804-bootstrap/root/var/cache/yum/metadata_lock.pid'
<rwmjones> also nothing I seem to do will make it use systemd-nspawn
<rwmjones> unclear if the error is related to chroot, it's plausible it mightbe
<rwmjones> that directory does exist, but maybe if it was already in the chroot then it would not
<davidlt[m]> So it seems that bootstrap is enabled in your configuration.
<davidlt[m]> Or it assumes it's enabled.
<rwmjones> it is enabled
<rwmjones> I'm not sure what that is
<rwmjones> ok it builds a "bootstrap container" with dnf
<davidlt[m]> Basically this is to avoid using host's package manager (DNF).
<rwmjones> that sounds .. good?
<rwmjones> ok I'll try setting it to false
<davidlt[m]> It will create a container with a new DNF. Then use that to create buildroot.
<davidlt[m]> So it's you are running CentOS which has old package manager which doesn't understand new provides/requires it would fail generate buildroot.
<davidlt[m]> So with bootstrap you first get new package manager. One more step.
<rwmjones> this is f37 host so I guess that wouldn't be an issue
<rwmjones> trying a non-bootstrap build now
<davidlt[m]> Yeah, it's more for CentOS as a host thing.
<davidlt[m]> config_opts['use_bootstrap'] = False in your config should disable it.
<rwmjones> yup
<rwmjones> similar error again
<rwmjones> [Errno 2] No such file or directory: '/var/lib/mock/f38-build-709212-92804/root/var/cache/yum/metadata_lock.pid'
<rwmjones> oh wait, that dir really doesn't exist, shouldn't it be created by mock?
<rwmjones> anyway let's make it by hand
<davidlt[m]> It might be faster to look at the code to see what needs to happen here.
<rwmjones> ok lunchtime
<rwmjones> failed again
<rwmjones> I think I'm just going to run mock directly
<davidlt[m]> And how are you running it now?
<rwmjones> from fedpkg mockbuild
<davidlt[m]> ah, via fedpkg
<davidlt[m]> Never tried that combo on riscv64.
<rwmjones> well even direct mock fails in the same place
<rwmjones> ERROR: Command failed: # /usr/bin/dnf --installroot /var/lib/mock/f38-build-709212-92804/root/ --setopt=install_weak_deps=0 --disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock groupinstall build
<rwmjones> Unable to detect release version (use '--releasever' to specify release version)
<davidlt[m]> Well it used to work :)
<rwmjones> No matches found for the following disable plugin patterns: local, spacewalk, versionlock
<rwmjones> [Errno 2] No such file or directory: '/var/lib/mock/f38-build-709212-92804/root/var/cache/yum/metadata_lock.pid'
<davidlt[m]> Well it still works (in the builders).
<davidlt[m]> Stupid question. Have you tried using sudo?
<rwmjones> yeah, same thing
<davidlt[m]> Or/and disabling SELinux (just in case).
<rwmjones> is disabled
<davidlt[m]> Does this directory exist /var/lib/mock/f38-build-709212-92804/root/var/cache/yum/?
<davidlt[m]> Is it only lock.pid file that's missing?
<davidlt[m]> You could try to remove existing site-defaults.cfg, and get a brand new one from the RPM. Just don't use new site-defaults.cfg on the builder.
<davidlt[m]> I don't think that would help, but worth a try.
<davidlt[m]> We only change a few things there.
<rwmjones> yeah it all exists beforehand, makes no difference
<rwmjones> I'm going to see if that one test can be disabled and push a fix for that, while bumping the issue upstream
<rwmjones> upstream issue ^
<davidlt[m]> I don't think this is an upstream issue, but just our environment.
<rwmjones> well maybe, but let's see what they say
<rwmjones> hey by the way I am not able to come to devconf.cz owing to budget issues here
<rwmjones> which is annoying but here we are
<thefossguy> Anyone here know how to create `visionfive2_fw_payload.img`? [The official documentation](https://github.com/starfive-tech/tools#uboot_its) feels VERY incomplete.
<thefossguy> That was my first goto
<thefossguy> But its not up-to-date with upstream uboot
<thefossguy> This is also where I started from 😃
<davidlt[m]> I asked them to open source the tool, so things changed.
<thefossguy> But then deviated to other sources and finally went to [u-boot docs](https://u-boot.readthedocs.io/en/latest/board/starfive/visionfive2.html).
<davidlt[m]> There is a patch for U-Boot that explains how to use the existing tool.
<davidlt[m]> Long time ago I asked them to integrate that into U-Boot build process, but that didn't happen.
<thefossguy> The thing is, uboot needs opensbi to build, opensbi needs uboot to build :cry:
<thefossguy> davidlt[m]: Oh there is, I got u-boot working somehow. That was a few days ago, when I posted about the EEPROM thing.
tg has joined #fedora-riscv
<thefossguy> Whats missing is OpenSBi as payload now :)
<davidlt[m]> The patch got initial review like 5 days ago, so it's not yet landed.
<thefossguy> Not exactly "missing" per se
<davidlt[m]> Yes.
<davidlt[m]> It contains all instructions from zero to boot screen.
<thefossguy> Well, that's the thing... It (u-boot) works, with upstream documentation :)
<thefossguy> I can build it and even boot the 5.15.0 vendor kernel
<davidlt[m]> At this point it might be better to grab 6.4 + patches from mailing list for the rest.
<davidlt[m]> I think Conor said he had better user experience with upstream vs. vendor kernel.
<thefossguy> If you look on the SUSE wiki, it essentially doesn't provide any targets to `make` for u-boot. That doesn't work because I get the following error when I don't specify the OpenSBI `fw_dynamic.bin`:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/2dc0725a3c0dc2b6409ba4eb8984ad19674d2130>)
<davidlt[m]> I think SUSE stuff was written for early stuff.
<thefossguy> davidlt[m]: Again, Linux at least boots fine. That's not the main issue here.
<thefossguy> The problem is building OpenSBI as a payload to u-boot. ;)
<davidlt[m]> What problem?
<davidlt[m]> Just build FW_DYNAMIC variant, you get a binary, point environment variable to it and build U-boot.
<davidlt[m]> U-Boot will place DTB, U-Boot proper and OpenSBI bianry into ITS file (well, DTB).
<thefossguy> Just a sec, I'll remove a few changes and share my build script
<davidlt[m]> Looks Ok.
<davidlt[m]> I don't like FW_TEXT_START
<davidlt[m]> Oh this will be annoying.
<thefossguy> I'm using FW_TEXT_START. Maybe that could be it?
<thefossguy> davidlt[m]: well, this is
<thefossguy> <thefossguy> "But then deviated to other..." <- what I shared here ;)
<davidlt[m]> The problem is that all other boards use default. I only build one OpenSBI for all the targets, that's generic.
<davidlt[m]> Changing FW_TEXT_START might mean I cannot reuse existing binary, and might need to do a board specific OpenSBI build :/
<thefossguy> What value do you use right now?
<davidlt[m]> default is 0x80000000.
<thefossguy> 🙃
<davidlt[m]> We used to build multiple OpenSBI per different platform in "old days".
<thefossguy> <thefossguy> "Just a sec, I'll remove a few..." <- Here is the **WIP** PKGBUILD
<davidlt[m]> You lack: PLATFORM=generic FW_TEXT_START=0x40000000 FW_OPTIONS=0
<davidlt[m]> Oh, sorry.
<davidlt[m]> Head is not working properly.
<thefossguy> Haha, no problem
<davidlt[m]> You don't set environment variable.
<thefossguy> davidlt[m]: Which one?
<davidlt[m]> Ah you do :D
<davidlt[m]> OPENSBI
<thefossguy> That one I did XD
<davidlt[m]> Looks okay.
<thefossguy> Calm down haha
<davidlt[m]> My head isn't working today, I am way too sleepy :D
<thefossguy> Mind if I ask what your /etc/localtime points to? 😝
<davidlt[m]> Vilnius, Lithuania, GMT+3
<davidlt[m]> I bet we are on the similar/the same timezone :D
<thefossguy> Ah, I wondered why you were so close to mine lol
<thefossguy> Mine is Kolkata, India, GMT+5:30
<davidlt[m]> Yeah, very similar.
<thefossguy> davidlt[m]: It's only 19:00, how are you sleepy? XD
<davidlt[m]> Well that happens if you go to sleep at midnight or later :)
<thefossguy> Good thing I needed a reminded of it
<thefossguy> Had a bad habit of staying up late, working
<thefossguy> Either way, we're offtopic now XD
<thefossguy> You go sleep well, I'll tinker with this for 15 or so minutes
<davidlt[m]> Nah, it's way too early to sleep :)
<davidlt[m]> risc
<thefossguy> I'm at a point where I remember urls of almost all git repos that I need to visit
<thefossguy> nervous laughter That's good, right? hahahaaaaaaaa
<davidlt[m]> Well, I have a good view of 23'000 packages in Fedora.
<davidlt[m]> That's insane.
<thefossguy> XD
<thefossguy> I'm off to bed, but here's today's quiz... I'm now trying to get `visionfive2_fw_payload.img` using starfive's tool. Following is how I do it, along with the error I get:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/440f4c9bb7bc9daf454ae9d52689ce44c59ff8c7>)
<davidlt[m]> Seems Ventana is working on something interesting: [PATCH v2 0/4] SPL NVme support in U-Boot.
<rwmjones> (by cheating and turning off the tests %ifarch riscv64)
<rwmjones> I pushed that change to rawhide
<rwmjones> anyway tomorrow I'll look at another package, hopefully quicker this time ...
<drewfustini> anyone have experience running docker on a riscv target?