<thefossguy>
Is there a way to check if OpenSBI is working correctly on the board? Preferably from Linux userspace.
ahs3 has quit [Ping timeout: 246 seconds]
<davidlt[m]>
I package them just in case you need/want them to cook some kind of firmware.
<davidlt[m]>
Well if you booted it's already a good test. After that you could try to use linux features that would trigger specific extensions in OpenSBI.
<thefossguy>
Testing those features is what I'm interested in :)
<thefossguy>
Don't know how
<davidlt[m]>
E.g poweroff and reboot works?
<thefossguy>
Well no XD
<thefossguy>
Okay I forgot to mention, poweroff works
<thefossguy>
Reboot doesn't
<thefossguy>
Well well well
<thefossguy>
Look how the tun...tables!
<thefossguy>
Reboot works too
<thefossguy>
Fixed the dtb in uboot's vf2 defconfig
<thefossguy>
Though, I'm booting off the SD Card so will now flash this to the QSPI flash and see things for real XD
<thefossguy>
Any other way to verify if OpenSBI is working as intended other than poweroff and/or reboot?
<davidlt[m]>
Well all implemented functions
<davidlt[m]>
Reset and ppweroff is one particular extension.
<davidlt[m]>
The fact that you booted already is a good test.
<davidlt[m]>
Even if you test OpenSBI for features that doesn't test for bugs ;)
<thefossguy>
That's what I want to test though :D
<thefossguy>
<thefossguy> "Though, I'm booting off the SD..." <- Flashed it. Reboots work :)
<thefossguy>
i happi
<thefossguy>
gets excited IT'S COOL WHEN THINGS ARE UPSTREAMED AND YOU JUST make AND IT GOES BRRRRRRRRR
<thefossguy>
No extra headache, at least when building and deploying.
<davidlt[m]>
Yeah, but it takes time.
<davidlt[m]>
I think Intel is already upstreaming the next 3 generations (or more) for client compute arch.
<davidlt[m]>
I think they are upstreaming Meteor Lake, Arrow Lake and Lunar Lake right now.
<davidlt[m]>
I need a new laptop at the worst time :D
<davidlt[m]>
I bet we will see Meteor Lake announcement (or some kind of update) in Computex, with availability for back to school.
<davidlt[m]>
If they could add a large L4 (Intel ADM) in the base tile and add Thunderbolt 5 it would be a killer probably.
<davidlt[m]>
Both, AMD and Intel plans to go against Apple M chips.
<thefossguy>
The new Framework just launched
<davidlt[m]>
Yeah, but it's Q3.
<davidlt[m]>
And it's not available in my country, and Framework tries to avoid all package forwarding services IIRC.
<thefossguy>
y, same
<thefossguy>
no shipping in India
<davidlt[m]>
I would go with Framework, but they make it complicated.
<davidlt[m]>
The easiest is to get Apple hardware. You can simply go to many local shops and get it the same day.
<davidlt[m]>
Conan Kudo: What's the status of Fedora Asahi?
<davidlt[m]>
Tuxedo just announced Intel 13th gen laptop.
<davidlt[m]>
But iGPU difference between 13th and 14th will be massive.
<thefossguy>
I have a 2018 MBP. Really hate this device.
<thefossguy>
I prefer socketed RAM. But if you're gonna solder it, give me ECC RAM then.
<thefossguy>
RAM, I understand why you want it soldered. It really helps with signaling and perf.
<thefossguy>
But give me an NVMe slot!
<thefossguy>
I don't even need upgradability. Just let me repair it.
<davidlt[m]>
Time to finish morning walk 🚶♂️ and get back to golang.
<davidlt[m]>
Okay. Blood is pumping, I am awake, time to start this again :)
<davidlt[m]>
🎶 are playing too.
jcajka has joined #fedora-riscv
<Eighth_Doctor>
<davidlt[m]> "Conan Kudo: What's the status of..." <- we're probably going to have a "stable" release based on F38 soon
<Eighth_Doctor>
note the quotes, though
<Eighth_Doctor>
bunch of fun caveats, but hopefully mostly daily driver ready
<thefossguy>
What are the current caveats?
<thefossguy>
Are they because an upstream kernel is being used?
<davidlt[m]>
Does this already incl. speakers working?
<thefossguy>
i.e. work done but not yet merged upstream
<thefossguy>
davidlt[m]: Last I heard the lead dev (can't remember his name but it starts with an M) got a satisfactory curve that doesn't blow up the speakers
<Eighth_Doctor>
<thefossguy> "What are the current caveats?" <- non-upstream kernel, 16k pages means some applications blow up and no performant x86 emulators work, etc.
<thefossguy>
The last one is the biggest ouchie
<thefossguy>
A bigger problem imho is Flatpaks
<thefossguy>
Obviously not against them, but when the distro maintainers have control over packaging, they are responsible for porting to another arch.
<thefossguy>
If you're a one man army, you're probably not bothering with non-x86 support
<thefossguy>
You gain some, you lose some ig :)
<davidlt[m]>
I am bit surprised that aarch64 in RHEL is 64K.
<davidlt[m]>
I bet 16K was a decent middle ground here, but I have no data.
<davidlt[m]>
Anyways, change from 4K -> 64K originally was not a nice experience. Some firmware wanted to talk in pages, and that also required newer firmware blobs.
<davidlt[m]>
These days I would expect things to work like 95-97+%
<davidlt[m]>
As long as developers didn't assume things and checked at run-time what system supports.
<davidlt[m]>
Wait.
<davidlt[m]>
Fedora on aarch64 is 4K!
<Eighth_Doctor>
RHEL 9 is 4K too.
<davidlt[m]>
I am shocked :D
<Eighth_Doctor>
... and 64K
<Eighth_Doctor>
* and 64K as of RHEL 9.1.
<davidlt[m]>
What?
<Eighth_Doctor>
* and 64K as of RHEL 9.2.
<davidlt[m]>
Was that a mistake?
<davidlt[m]>
Someone messed up kernel-ark config or what?
<davidlt[m]>
Customers complained about regression?
<Eighth_Doctor>
nope, there are now two kernel variants: the default (4k) and an alternate kernel-64k for 64k pages
<Eighth_Doctor>
davidlt[m]: this, I think?
<Eighth_Doctor>
mostly because some databases abused the 64k pages for performance
<davidlt[m]>
Oh, that's kinda cool (must be annoying to some).
<davidlt[m]>
Oh yeah, databases probably gains the most from larger page size.
<davidlt[m]>
Is it me or Golang ecosystem is not that well maintained in Fedora compared to Rust?
<davidlt[m]>
For example there is no way to rebuild golang-x-exp
<davidlt[m]>
Nothing even provides, e.g. golang(go.opentelemetry.io/otel/metric/metrictest).
<davidlt[m]>
It does exist, in an old Fedora 36 package.
<davidlt[m]>
Newer version provide golang(go.opentelemetry.io/otel/sdk/metric/metrictest)
<davidlt[m]>
There is a super old otel package, 0.20 version in Fedora tool. But those strings incl. "otel-0.20" in provides thus that will never work.
<davidlt[m]>
To my surprise there are several golang packages with boostrap in F38.
<davidlt[m]>
There is one from Fedora 36 + bootstrap!
<davidlt[m]>
And that's golang-k8s-kubernetes.
esv has quit [Remote host closed the connection]
Eighth_Doctor has quit [Quit: Bridge terminating on SIGTERM]
defolos has quit [Quit: Bridge terminating on SIGTERM]
mhroncok has quit [Quit: Bridge terminating on SIGTERM]
davide has quit [Quit: Bridge terminating on SIGTERM]
cmagina has quit [Quit: Bridge terminating on SIGTERM]
Kevinsadminaccou has quit [Quit: Bridge terminating on SIGTERM]
dtometzki has quit [Quit: Bridge terminating on SIGTERM]
nirik has quit [Quit: Bridge terminating on SIGTERM]
hiredman[m] has quit [Quit: Bridge terminating on SIGTERM]
zbyszek[m] has quit [Quit: Bridge terminating on SIGTERM]
ol has quit [Quit: Bridge terminating on SIGTERM]
lorbus has quit [Quit: Bridge terminating on SIGTERM]
alexsaezm has quit [Quit: Bridge terminating on SIGTERM]
davidlt[m] has quit [Quit: Bridge terminating on SIGTERM]
jim-wilson[m] has quit [Quit: Bridge terminating on SIGTERM]
cwt[m] has quit [Quit: Bridge terminating on SIGTERM]
gotmax23 has quit [Quit: Bridge terminating on SIGTERM]
thefossguy has quit [Quit: Bridge terminating on SIGTERM]
defolos has joined #fedora-riscv
Kevinsadminaccou has joined #fedora-riscv
jim-wilson[m] has joined #fedora-riscv
esv has joined #fedora-riscv
nirik has joined #fedora-riscv
ol has joined #fedora-riscv
Eighth_Doctor has joined #fedora-riscv
lorbus has joined #fedora-riscv
mhroncok has joined #fedora-riscv
davidlt[m] has joined #fedora-riscv
dtometzki has joined #fedora-riscv
thefossguy has joined #fedora-riscv
zbyszek[m] has joined #fedora-riscv
alexsaezm has joined #fedora-riscv
gotmax23 has joined #fedora-riscv
davide has joined #fedora-riscv
hiredman[m] has joined #fedora-riscv
cwt[m] has joined #fedora-riscv
cmagina has joined #fedora-riscv
<rwmjones>
fyi I'm investigating that ghc "target code interpreter" thing now
<davidlt[m]>
cool.
<rwmjones>
davidlt[m]: you don't recall whta this was for?
<rwmjones>
Add riscv64 to ghc_unregisterized_arches (David Abdurachmanov)
<rwmjones>
in ghc.spec
<rwmjones>
--enable-unregisterised Build a toolchain with the unregisterised ABI
<rwmjones>
(disabled by default on platforms with registerised
<rwmjones>
support)
<rwmjones>
(whatever that means)
<rwmjones>
ok I see something to do with bootstrapping
<rwmjones>
I'm going to try building ghc (locally) without that
<rwmjones>
one other ghc problem we have is ...
<rwmjones>
$ ghci
<rwmjones>
<command line>: not built for interactive use
<rwmjones>
which may or may not be related to this, but I'm trying to get that one fixed
zsun has joined #fedora-riscv
<davidlt[m]>
rwmjones: we use unregistered variant.
<davidlt[m]>
Basically that's running C backend.
<davidlt[m]>
To build it locally will take 30-40+ hours.
<davidlt[m]>
There is no native riscv backend in GHC.
<rwmjones>
hmm
<davidlt[m]>
They are lagging behind LLVM releases too. Officially it supports up to LLVM 12, but that fails even to build. It works with LLVM 13 (OpenSUSE use that) and that works way better.
<rwmjones>
I still don't understand why ghci wouldn't work since it's supposed to be a bytecode interpreter
<davidlt[m]>
All those builds are available in Koji if you want to pull in.
<davidlt[m]>
But either there are bugs in LLVM + riscv backend (tool old LLVM?) or mixing two backends might not be the option.
<davidlt[m]>
See logs, maybe some configuration bit disables it.
<rwmjones>
so why would ghc need support for riscv if it's just using llvm?
<davidlt[m]>
You can also try older GHC builds and see if that used to work.
<davidlt[m]>
Maybe it's a regression.
<davidlt[m]>
I think LLVM is one of backends, but not all arches use LLVM IIRC.
<davidlt[m]>
Only ARMv7 and S390x are with LLVM backend.
<davidlt[m]>
That probably means that x86_64, aarch64, ppc64le, etc. have native backend implementations.
<davidlt[m]>
Then for not-so-popular you can pick between C or LLVM backend.
<davidlt[m]>
But they don't mix. Somehow it feel that changing backend changes ABI or something.
<davidlt[m]>
Easy and annoying thing would be to tag again GHC + LLVM 13 build and then rebuild all GHC packages.
<davidlt[m]>
Might solve the problem, and we have to do that anyways at some point.
<davidlt[m]>
Also LLVM backend is faster, GHC build itself is like 10+ hours faster with LLVM backend.
<rwmjones>
still looking ..
<davidlt[m]>
It would take several days for this rebuild, and you need to koji list --latest f38 ghc* and save that list of builds just in case you need to revert back all those ~700 packages.
<davidlt[m]>
If I started GHC rebuild there is chance I will be blocked to make a new disk image.
<davidlt[m]>
It seems someone folks at Red Hat love Haskell and it's everywhere.
kalev_ has quit [Quit: leaving]
<rwmjones>
don't worry, still investigating!
<davidlt[m]>
That 64-core dev kit would allow to solve this in hours or day :)
<davidlt[m]>
We mainly need GHC working (and ecosystem) to have pandoc. That one is in way too many things.
<davidlt[m]>
and pandoc pretty much requires the whole GHC ecosystem :D
<davidlt[m]>
It's one of those that will pull in almost full world.
<rwmjones>
yeah it's a shame pandoc can't be built as bytecode
<rwmjones>
if it was anything like ocaml you could then just build a noarch pkg and copy it around
<rwmjones>
but anyway
zsun has quit [Quit: Leaving.]
jcajka has quit [Quit: Leaving]
<davidlt[m]>
Go is actively fighting me, but I keep pushing forward.
<rwmjones>
this ghc package is actually building [locally]
<davidlt[m]>
Yeah, building it is not a problem :)
somlo_ has joined #fedora-riscv
somlo has quit [Quit: Leaving]
somlo_ is now known as somlo
somlo has quit [Remote host closed the connection]
somlo has joined #fedora-riscv
somlo has quit [Read error: Connection reset by peer]
somlo has joined #fedora-riscv
<thefossguy>
Waking up fresh at Brahmamuhurta and starting work at 05:30. Nothing like this drug 😎