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_ has joined #fedora-riscv
esv has quit [Ping timeout: 240 seconds]
<cwt[m]> I already asked the following question in the Arch Linux room, but someone here may give me some light.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/fd86f9dc843be4a804cc40f06212c35b53379abb>)
<cwt[m]> (hmm... why element make my first like bold?)
<cwt[m]> s/like/line/
<davidlt[m]> Maybe it's Markdown like?
<cwt[m]> yep, I put --- between the first line and my question.
<drewfustini> davidlt[m]: are you in Barcelona for the RISC-V Summit?
<davidlt[m]> drewfustini: no
<davidlt[m]> drewfustini: is there anything interesting?
<drewfustini> ah, ok, someone had thought you were
<drewfustini> it is more techincal than the california one
<drewfustini> but overall not much operating system / firmware content
<drewfustini> though emil and heinrich are here :)
<drewfustini> I was hoping Ved would have been here for the SoC Infrastructure group since I worked on the QoS spec with him but he wasn't able to come
<drewfustini> Kumar from Ventana is here but not anyone else like Anup, Drew Jones or Sunil
<drewfustini> overall, it is not very "linux-y"
<davidlt[m]> Well, that's typical (and that's way I avoid these summits)
<davidlt[m]> There aren't too much reason to go there, and YouTube videos are plenty enough to catch up, I guess.
<drewfustini> yeah... I combined it with trip to BayLibre in Nice so it was worhtwhile but probably not be worth it on its own
<davidlt[m]> That makes sense.
<drewfustini> will you come to Prague for the Embedded Linux Conference later this month?
<drewfustini> I'm a little sad no rivos people as far as I can tell here. It was a lot of fun working on the QoS contract earlier a few months ago.
<davidlt[m]> No, I am/was thinking about DevConf in Brno this moth, but don't know.
<drewfustini> ah ok
jcajka has joined #fedora-riscv
<drewfustini> you're still rivos right?
<davidlt[m]> Yes
<drewfustini> ever come to the california officE?
<davidlt[m]> No, not yet.
<davidlt[m]> I haven't been in US since I left SiFive.
* davidlt[m] goes to check Embedded Linux Conference schedule
<drewfustini> I am on the ELC program committee
<drewfustini> I tried to make it interesting :)
<drewfustini> unfortunately, we had 4 times more proposals than we had room to accept
<davidlt[m]> This one is way more interesting than the summit :)
<drewfustini> Yeah!
<drewfustini> I
<drewfustini> I'll be back for that end of the month
<davidlt[m]> I used to love Zephyr, also a user of Yocto, there are typically other topics like pipewire, etc.
<drewfustini> Yeah, I put pipewire and wireplumber on my "accept" list because they seem important topics
<davidlt[m]> Well, majority of the talks on ELC schedule are interesting.
<davidlt[m]> Oh, Simon Glass will talk about U-Boot.
<drewfustini> yeah!
<drewfustini> I had that high on my list
<drewfustini> (there were 5 other people and we all ranked all the submissions)
<davidlt[m]> I most likely will never go to ELC physically because of the related costs :( There has to be a good reason to justify that.
<Entei[m]> davidlt: I rebuilt the redhat-rpm-config package with the added optflag for riscv64 `-march=rv64imafd_zicsr_zifencei` as you suggested, and installed the package. During the rpmbuild the output did show flag being applied, but inspecting the binary with `objdump` I can see compressed instructions being utilised.
<Entei[m]> Did I miss something? Even used `--target=riscv64` during build
<Entei[m]> I built the simple package called banner
<davidlt[m]> Note that you are still linking to libraries that are built with C extension.
<davidlt[m]> Verify that object files during the build don't have C.
<davidlt[m]> Also GCC runtime probably is compiled with C too. You might need to recompile GCC anyways.
<Entei[m]> Oh
<davidlt[m]> We don't do multilib.
<davidlt[m]> I checked GCC and there is an option for rv64imafd in muiltilib.
<davidlt[m]> You might want to enable multilib and incl. rv64imafd and rv64imafdc (default).
<davidlt[m]> You shouldn't need to do that as all run-time bits are object files that get linked-in IIRC.
<Entei[m]> davidlt[m]: Isn't multilib enabled in the gcc binary on Fedora riscv image?
<davidlt[m]> No. Well, we have it enabled, but only select one (this is related to paths GCC decides to install).
<davidlt[m]> But in general we don't support multilib.
<davidlt[m]> It's pure 64-bit, one ABI, no CONFIG_COMPAT too.
<Entei[m]> So right now my only option is to edit spec file for gcc and rebuild gcc. Did I get it right?
<davidlt[m]> Yeah, you will need to do that sooner or later.
<davidlt[m]> But you might want to figure out where from C comes in right now.
<davidlt[m]> I assume the 1st thing you recompiled was glibc :)
<davidlt[m]> Which pretty much links to nothing IIRC.
<Entei[m]> Ok. I am kinda novice in this field to be very honest. But thanks for additional info, I'll look it up.
<davidlt[m]> Scan the binaries for C, and identify if that belongs to the project or it comes from somewhere else.
<davidlt[m]> If it comes from a package that was compiled without C then investigate object files.
<davidlt[m]> If you find that object file contains C instructions check logs to make sure that GCC execution was as expected.
<davidlt[m]> The 1st thing is to figure out why this happen before doing something more expensive.
<davidlt[m]> Recompiling GCC requires loads of time thus you want to be sure for doing anything.
<Entei[m]> I think I could achieve this (with --nodeps probably) on my image built with openembedded which already has a default CPU target and all libraries are built with my desired ISA extensions as well
<davidlt[m]> That would be a traditional bootstrap from zero, which will be expensive too.
<davidlt[m]> Those typically happens in multiple stages.
<davidlt[m]> s/happens/happen/
<davidlt[m]> You start small (package and feature wise) and in each stage you expand as you get more things available.
<Entei[m]> davidlt[m]: Yeah I started with OE to skip most stages, but I am finding myself in a predicament with `mock`. I am really unsure what's causing it to prompt "Password is invalid" no matter what I do.
<Entei[m]> That's why I had decided to turn to Fedora's image....
<davidlt[m]> You don't need mock to being width.
<davidlt[m]> And OE will help, but will not solve all the problems.
<davidlt[m]> The idea basically is build all the RPMs to replace existing OE image. That's your stage 0, I guess.
<davidlt[m]> So --nodeps, faking RPMs, hacking is the way to go.
<davidlt[m]> The only thing you need to make sure you have RPM available in existing rootfs.
<davidlt[m]> Then things like fedora-release, redhat-rpm-config, and probably a few others to bring in the needed configuration.
<davidlt[m]> The 1st target is to build RPM itself (so that means you need to build all required depencies).
<Entei[m]> davidlt[m]: Yeah it was initially the plan. OE provided surprising amounts of recipes including containers, so I thought I would skip all the way to mock, and start rebuilding in the clean chroot. But can't get mock to run.
<davidlt[m]> So like zlib is probably the 1st thing to build.
<davidlt[m]> Nah.
<davidlt[m]> Mock has no repository to work with.
<davidlt[m]> Until you do stage 0 there are 0 RPMs and there is nothing from which you can construct a new rootfs.
<Entei[m]> davidlt[m]: We had done rebuilding a few minimal packages. together with OE rpms, the plan was to provide a local repo
<davidlt[m]> Any path you choose will require quite a large investment (mainly time if compute is not a problem).
<davidlt[m]> Here is our RISCV bootstrap (might help, might not): https://github.com/rwmjones/fedora-riscv-bootstrap/tree/master
<davidlt[m]> This is like 5-7 years old now thus probably is not that useful.
<davidlt[m]> This predates any Buildroot, OE, and anything else.
<davidlt[m]> Heck we didn't even have stable ABI on Linux yet :)
<Entei[m]> So what do you suggest would be the best course of action for me? I have an OE image, should I just use it as a base image to rebuild all RPMs from scratch? Or if you have something in your mind that would be appreciated as well
<davidlt[m]> It's not that easy to answer on the spot.
<davidlt[m]> Both are valid cases, not sure which one would deliver you something useful faster.
<davidlt[m]> I would most likely go with existing Fedora, because it exist and C or no C, ABI doesn't change.
<davidlt[m]> From GCC mutlilib: march.rv64imafdc/mabi.lp64d=march.rv64imafd/mabi.lp64d \
<davidlt[m]> So you can basically through a ton of compute at this problem instead of manual labor.
<davidlt[m]> I would check GCC RPMs, very carefully review SPEC again and recompile with C extension.
<davidlt[m]> I would would disable tests and bootstrap on GCC to test it locally in the QEMU.
<davidlt[m]> I would build it, scp it out of QEMU to save it.
<davidlt[m]> Then install it in the existing QEMU to see how system reacts.
<davidlt[m]> If that crashes while using then we probably messed up somewhere.
<davidlt[m]> If not, then I would probably setup another Koji instance, import existing repo. Build the "production" GCC into the tag.
<davidlt[m]> And that point I would start building from smaller things, like glibc, zlib, etc.
<davidlt[m]> I probably would test it in that same QEMU. Smaller packages with no dependencies (or little of them).
<davidlt[m]> Target @core pacakges.
<davidlt[m]> If all looks good, then just mass rebuild (a few times).
<davidlt[m]> Write a script that would scan binaries to check for C extension use.
<davidlt[m]> I would build enough stuff for a builder without C, change QEMU to disable C.
<davidlt[m]> Something like that.
<davidlt[m]> I don't think I would have much more options as a single person.
<Entei[m]> Thanks a lot for this. I am gonna try this approach. Will report when gcc is done rebuilding
<davidlt[m]> There will be issues as some packages most likely have -march or -mtune hardcoded somewhere that assumes RV64GC / RVA22 / RVA23 / RVA20 or something else.
<Entei[m]> davidlt[m]: yeah seen that in some spec files
<davidlt[m]> Entei: remember that you can go up to 32-cores on QEMU (don't know about the scaling benefits of MTTCG).
<davidlt[m]> Disable bootstrap (GCC is built in a single stage), and disable all the tests.
<davidlt[m]> If you hardware is fast you should get some form of GCC within a day.
<davidlt[m]> Well within 8-12 hours if you HW is really good :)
<davidlt[m]> Before building on physical HW I used to run 170-180 QEMU VMs (4-core mostly) via libvirt.
<Entei[m]> davidlt[m]: I doubt it. It's decent enough though I think. It's dual Xeon 5118 (24 cores total)
<davidlt[m]> Oh yes, that's old.
<davidlt[m]> I think, I used EPYC 7000-series for GCC experiments.
<davidlt[m]> So let's say 1-2 days most likely for your GCC.
<Entei[m]> <davidlt[m]> "Disable bootstrap (GCC is..." <- By this you mean disable bootstrap in spec file right? And not build gcc with autoconf but rebuild the rpm?
<davidlt[m]> GCC is typically built in stages (bootstrap).
<davidlt[m]> Disabling that to a single build saves time for testing.
ach0verflow[m] is now known as mochaaP[m]
<Entei[m]> Yeah so I just apply --disable-bootstrap flag in the spec file right?
<davidlt[m]> and modify make line too
<davidlt[m]> by default it will call profiledbootstrap
<Entei[m]> Ok. Then that's fine. For a moment I thought you had suggested building gcc binaries with autoconf and make and then rebuild the gcc rpm
<davidlt[m]> Nah, the traditional GCC build does it 3 times.
<davidlt[m]> It builds stage 0 with host GCC, then stage 2, then stage 3 using stage 2.
<davidlt[m]> It compares stage 2 with stage 3 IIRC and if all matches you get the final GCC.
<davidlt[m]> It's also profiles thus there might be another stage to collect profile for the final GCC optimization.
<Entei[m]> I see. Are there any benefits to this traditional build approach? Especially when it's native building?
<davidlt[m]> That's the way it's always done.
<davidlt[m]> This ensures you get a sane compiler.
esv_ has quit [Ping timeout: 250 seconds]
esv_ has joined #fedora-riscv
zsun has joined #fedora-riscv
zsun has quit [Client Quit]
esv_ has quit [Remote host closed the connection]
esv_ has joined #fedora-riscv
esv_ is now known as esv
zsun has joined #fedora-riscv
<davidlt[m]> sxa: are you around?
zsun has quit [Quit: Leaving.]
<davidlt[m]> sxa: your account information, certificates, and initial instructions are sent to you.
esv has quit [Ping timeout: 240 seconds]
esv has joined #fedora-riscv
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
jcajka has quit [Quit: Leaving]
fuwei has quit [Ping timeout: 250 seconds]
fuwei has joined #fedora-riscv
foxtran has quit [Read error: Connection reset by peer]