<davidlt[m]>
Very interesting Intel new ISA changes.
<davidlt[m]>
GPRs 16 -> 32, AVX10 to allow running on both, E and P cores.
<davidlt[m]>
Well, AVX10.2 IIRC.
<davidlt[m]>
Having double GPRs is really nice.
<Entei[m]>
I tried looking at the installed_packages log from koji to figure out the minimal number of packages I would need to set up my repository (in case I am unable to use your koji repository). I built banner which would be one of the smallest dependency packages.
<Entei[m]>
One of the packages being installed as dependency is `fedora-gpg-keys`. Don't understand the use of it...
<davidlt[m]>
To verify Fedora repository RPMs.
<davidlt[m]>
RPMs are signed.
<Entei[m]>
But Fedora RPMs would be signed by fedora people right? At the beginning when there are no packages for a particular architecture, and people like you and me are building ourselves, there shouldn;t be a need for signed rpms
<Entei[m]>
Do I build this package just for the sake of dependency resolution? I know it's just gpg keys, wouldn't take any time
<davidlt[m]>
It doesn't hurt you to have it.
<davidlt[m]>
As I said before just copy & paste this stuff.
<davidlt[m]>
You can also import all noarch packages without waiting, which probably is half of Fedora.
<davidlt[m]>
So v6.4.6 was released overnight just for the Zenbleed.
<davidlt[m]>
drewfustini: is BayLibre working on upstreaming TH1520 support?
fuwei has quit [Ping timeout: 264 seconds]
fuwei has joined #fedora-riscv
<drewfustini>
Yes, I am working on it
<davidlt[m]>
I noticed the patches from you for MMC (well, eMMC) and also BayLibre email :) Thus I assume TH1520 or/and BeagleBoard support is probably partially your day job thing now :)
<davidlt[m]>
v6.4.4 kernel is built, time to prep v6.4.6
fuwei has quit [Ping timeout: 260 seconds]
kalev is now known as kalev-guadec
<Entei[m]>
Replicating other's approach while building koji, I see we start with a tag, say f37, then create a child tag called f37-build. Now we use f37-build as build tag (this tag provides information about what packages to be installed in buildroot, repos and arch) and f37 as destination tag. Why do we use parent tag as destination tag?
<Entei[m]>
And now since f37-build inherits from f37, now it has those packages too that were built and tagged under f37. Kinda feels redundant.
<Entei[m]>
* Replicating other's approach while building with koji, I see we start with a tag, say f37, then create a child tag called f37-build. Now we use f37-build as build tag (this tag provides information about what packages to be installed in buildroot, repos and arch) and f37 as destination tag. Why do we use parent tag as destination tag?
fuwei has joined #fedora-riscv
fuwei has quit [Ping timeout: 260 seconds]
Jo[m]1 has quit [Remote host closed the connection]
<davidlt[m]>
You have to remember that Koji itself is just one of the gears in the machinery.
<davidlt[m]>
Tags are being used by other tools to mark specific state too.
<davidlt[m]>
And there are other tools that "move" builds through the tags as it slowly gets approved and lands in the user visible repository.
fuwei has joined #fedora-riscv
<davidlt[m]>
There is also fXY-override, fXY-updates, before fXX.
<davidlt[m]>
Infra/Rel team might need to fix something very fast and bypass other tags used by the tooling and put a build into fXY-override to fix something, and similar.
<Entei[m]>
I still don't get it...We are essentially tagging a package twice since inheritance exists between 2 tags. As soon as builds get finished, they are being tagged under `fxy` but since `fxy-build` was the child tag to `fxy`, now the package is being tagged under `fxy-build` as well. If build is completed in the name of parent tag, the changes would be reflected in all the child tags as well.
<Entei[m]>
So the tagging system doesn't make too much sense.
<davidlt[m]>
That's expected. In Rawhide (in older days, and still to this day kinda) for some times builds directly get into the tag.
<davidlt[m]>
Which is not the case once Bodhi point is activated.
<davidlt[m]>
In that case builds are submitted to Bodhi, there is extra CI gating there too.
<davidlt[m]>
Once the update gets approved, CI passes, karma is acquired the build lands in the final tag.
<davidlt[m]>
But again you can have minimal set of tags, but it's typically not fXY and fXY-build only.
<davidlt[m]>
There is more between those.
<davidlt[m]>
For Koji you don't need much, but as soon as you attempt to plug more gears from infra side that will work based on tags.
fuwei has quit [Ping timeout: 250 seconds]
<Entei[m]>
davidlt[m]: I see. Maybe exploring Bodhi a bit more would make it easier to make sense of tags
<davidlt[m]>
You don't really need Bodhi unless you really plan to have customers or similar expecting you to provide a proper thing.
<Entei[m]>
For now, I feel the build and destination tags don't need to share a parent-child relationship.
<davidlt[m]>
They need.
<davidlt[m]>
You want to use package X in your buildroot for the next builds ASAP.
<davidlt[m]>
Otherwise you need manually tag the build into the destination tag (well, Bodhi).
<davidlt[m]>
Otherwise as soon as build finishes it's available for the next build.
<rwmjones>
davidlt[m]: the lichee is really slow (less than half the speed of the VF2)
<rwmjones>
davidlt[m]: I'm suspecting this may be caused by the external USB disk
<davidlt[m]>
That's impossible, I think.
<rwmjones>
right, unexpected
<davidlt[m]>
Well, we cannot really use eMMC or SD card.
<davidlt[m]>
USB should be the fastest option.
<rwmjones>
I'm just doing the test over again
<rwmjones>
well apart from NVMe directly wired to the SoC which is what VF2 has
<davidlt[m]>
Well, there are no PCIe on TH1520, but it does have USB.
<rwmjones>
unfortunately this kernel doesn't support iotop
<rwmjones>
oh really, I didn't know that
<davidlt[m]>
That's how we get those USB-A 3.0 ports on the board.
<davidlt[m]>
I don't know how many ports there are in TH1520.
<davidlt[m]>
There might USB hub there too.
<rwmjones>
just looking at the lichee vs vf2, it's obvious the vf2 is way faster at compiling
<rwmjones>
I mean, looking at the ninja build output
<davidlt[m]>
It shouldn't.
<davidlt[m]>
Unless SiFive L2 prefetcher does some magical work there.
<rwmjones>
well, something about the config may be wrng, but it is what it is
<davidlt[m]>
Otherwise C910 are faster cores, and it has faster memory too.
<rwmjones>
since the lichee is still using tmp-on-tmpfs (because the OS is running off the SD-card) I'll try a build on /tmp in a min
<rwmjones>
it'll rule out USB
<davidlt[m]>
Could you run something non-compile based? Also something that doesn't depend on storage.
<rwmjones>
what would be a good test?
<davidlt[m]>
Old school dhrystone and similar?
<davidlt[m]>
SD card is even worse than eMMC, I bet.
<rwmjones>
for sure
<rwmjones>
but hopefully it's not actually using the SD card very much during these builds
<rwmjones>
I wish I had iotop to confirm that
<davidlt[m]>
There is a tool. I added it to Fedora or FUSDK a long time ago that allows you to load binaries/shared libraries into the cache.
<rwmjones>
I know the one you mean, can't recall the name
<davidlt[m]>
vmtouch, I think.
<davidlt[m]>
I used to do some really stupid things with it :)
<rwmjones>
no surprise that the hifive unmatched is the slowest of all
<davidlt[m]>
Oh yeah, super old pre-production U74 + some memory issues
<davidlt[m]>
But do more tests.
<davidlt[m]>
I am thinking about branching F39 sooner than later, doing v6.5 kernel and maybe adding a bit more of VF2 patches.
<davidlt[m]>
I enabled a lot of VF2 bits in v6.4.X kernels (untested of course). The last important bits were approved for v6.6.
<davidlt[m]>
There are still a few not approved bits, that would incl. USB and PCIe IIRC. Somehow I hope those should get ironed out for v6.6 too.
fuwei has joined #fedora-riscv
<rwmjones>
the ramdisk isn't looking much better
<rwmjones>
I don't think there's enough spare space on the eMMC to try that
<davidlt[m]>
Could you test their original kernel?
<davidlt[m]>
Maybe drewfustini could double check your work on BeagleBoard?
<rwmjones>
the original kernel is the sipeed debian one?
<davidlt[m]>
Yes
<davidlt[m]>
Well, whatever vendor provides.
<rwmjones>
ok
<rwmjones>
building on the ramdisk made very little difference, so let me try the debian kernel now
* rwmjones
is lost in a maze of random u-boots
<rwmjones>
I flashed the lichee to boot off SD-card, and I can't find the original u-boot right now