<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]>
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.