cyberpear has quit [Quit: Connection closed for inactivity]
<davidlt[m]>
oh, I have some emails to reply :)
<davidlt[m]>
Coffee and email writing.
<davidlt[m]>
Conan Kudo: I replied to RISCV sub-arch thread.
<davidlt[m]>
nirik: you might want to look at it too.
<davidlt[m]>
rwmjones: same for you.
<davidlt[m]>
In general we need to agree on future path we want to take. From many years discussing with various folks I understand the need to support systems based on standards. I have been asking companies to focus on that building their next IP/SoC/SBC (long process).
<davidlt[m]>
Not support existing stuff (i.e. RVA20) would be a big impact to existing RISCV community, but we also cannot stay in existing situation.
<davidlt[m]>
I don't want to mix RVA20, 22, 23, 24, etc. because that's a huge psABI rick and complexity on Fedora infra side.
<davidlt[m]>
Storage costs less and does not require significant engineering resources.
<davidlt[m]>
I would skip RVA22 as I don't think we will see it a lot. We can always get that enabled if there is plenty of SoCs/SBCs (or some company interest).
<davidlt[m]>
I bet even Android will require RVA23 (or newer).
<davidlt[m]>
(Well, I cannot be 100% sure).
<davidlt[m]>
There will also be a new psABI later this year (or should be) that will incl. more TLS, ULEB128, vector calling conventions, (I assume), etc.
<davidlt[m]>
A lot of things are aligned on RVA23.
zsun has joined #fedora-riscv
<Eighth_Doctor>
davidlt: I'm just tired of people not considering normal people when making new architectures for people to adopt/use/develop for
<davidlt[m]>
We cannot ignore majority of folks.
<davidlt[m]>
Very few folks will be able to afford standards compliant high-perf enterprise systems.
<davidlt[m]>
Most developers (not working for a large companies) will not get them too.
<davidlt[m]>
It will take years (if we manage at all) to get SBCs compliant with standards the same way as large systems.
<davidlt[m]>
I was and still am pushing towards every company towards that, but you never know.
iooi has joined #fedora-riscv
<Eighth_Doctor>
the failure of SystemReady in ARM for affordable computers, IMO, is directly attributable to a lack of desire by Arm to push that
<Eighth_Doctor>
in RISC-V, we don't even have equivalent standards by RISC-V International, much less anyone to push it as a baseline expectation for RISC-V computers
<davidlt[m]>
You have to understand one thing. The SoCs and SBCs that exist today aren't making any meaningful money.
<Eighth_Doctor>
oh I know
<davidlt[m]>
They exist only as test chips and to help software ecossytem.
<Eighth_Doctor>
I used to be in the embedded space as well
<davidlt[m]>
The standards are incoming, but it takes time and they have to have in a specific order.
<Eighth_Doctor>
I know how this stuff comes into existence, the problem is that everyone thinks those early decisions are inconsequential, but they matter a lot
<Eighth_Doctor>
because they turn into backwards compatibility questions
<davidlt[m]>
It was pretty much clear from the early days that it will be a decade old mess :)
<Eighth_Doctor>
and you have the ugly decision of figure out where you want to strike and induce pain to fix things, if you even can
<davidlt[m]>
You cannot really avoid that. We tried to push for standards in RVI early, but there was lack of proper interest.
<Eighth_Doctor>
yeah
<Eighth_Doctor>
every architecture except x86 has gone through this mess
<davidlt[m]>
Now there is a lot more interest, large companies, high-perf stuff,. tons of money and thus finally folks want something standard.
<Eighth_Doctor>
well, and PowerPC
<Eighth_Doctor>
both of them had IBM defining everything from the beginning
<davidlt[m]>
Well, we got ISA first without a stable ABI :) That's how we started :D
<Eighth_Doctor>
m68k never matured because PC-types switched to PowerPC
<Eighth_Doctor>
SGI did define a MIPS type computer, but it never became part of the platform spec
<Eighth_Doctor>
ARM didn't get a standard because Arm didn't care, so everyone cribbed off the PowerPC OpenFirmware standards to create a subset for ARM
<Eighth_Doctor>
which is how we got DeviceTree :D
<davidlt[m]>
DevConf.CZ, Flock, maling-list. We need to arrive some decisions before the end of the year.
<davidlt[m]>
IIRC even Apple is using DevideTree.
<davidlt[m]>
Or at least Asahi Linux does.
<Eighth_Doctor>
Asahi Linux uses DT because we have nothing else
<Eighth_Doctor>
Apple invented their own boot protocol for iPhones twenty years ago
<Eighth_Doctor>
that's what ARM Macs use today for macOS
<davidlt[m]>
Yeah, Apple likes not to re-invent things as long as they work.
<Eighth_Doctor>
most PC makers were like that
<davidlt[m]>
Even Apple M1, M2 chips still contain the same IP blocks from early iPhone days.
<Eighth_Doctor>
the reason x86 is so standards compliant is because all x86 PCs are clones of the IBM PC
<davidlt[m]>
RISCV Profiles solves the problem regarding default binaries distribution needs to ship.
<Eighth_Doctor>
the reason why there are no ARM PCs is simple: there is no cost effective path to mass production
<Eighth_Doctor>
with long term maintenance
<davidlt[m]>
Well if something cheap + standard comes it most likely will come from Chinese market.
<davidlt[m]>
Right now most of their investments don't have a direct product.
<davidlt[m]>
Well except Alibaba / T-HEAD. They are moving fast and breaking some RVI stuff while doing it.
<Eighth_Doctor>
yeah, it's going to be a while before that's a thing
<Eighth_Doctor>
and Ubuntu isn't quite as far ahead as people think :)
<davidlt[m]>
SiFive could deliver something (most likely with some partner). For example Intel + SiFive Horse Creek is a nice partnership.
<PrathamPatel[m]>
I heard a few hardware vendors selling SoCs but not news about anyone promising/hinting something that will have RVA23 (or later) in their [future] products
<Eighth_Doctor>
there have been a few hints, but no promises from what I've heard
<davidlt[m]>
Intel is doing their Foundries v2.0 and they need to spend the money to attract orders.
<davidlt[m]>
Well, you need to look between lines regarding RVA23.
<davidlt[m]>
For the majority of things if you ingest large amount of data (announcements, roadmaps, mailing-lists, conferences, etc.) you can see where things are headed.
<davidlt[m]>
Like RVA23 wasn't a thing a year ago. Minor/Major wasn't a thing too.
<davidlt[m]>
It just we failed to ratify a number of extensions needed for a proper systems (incl. Android) before 2022 arrived.
<davidlt[m]>
So instead of every 2 years, now we have RVA23, and minor/major. RVA22 is minor (i.e. don't expect distributions to support it).
<davidlt[m]>
I could bet Ventana V2 stuff will be RVA23 compatible.
<davidlt[m]>
I bet SiFive will have something RVA23 ASAP as they did with RVA22.
<davidlt[m]>
I expect T-HEAD (and others) to follow sooner than later too.
<Eighth_Doctor>
I think if we get Android and regular Linux harmonized on standards, we'll probably be okay
<Eighth_Doctor>
most of the fuckup for ARM was that nobody tried to do that
<davidlt[m]>
Google explicitly mentioned on the slides that standards are still not set.
<Eighth_Doctor>
yes
<Eighth_Doctor>
which is why it's an opportunity
<davidlt[m]>
We don't even have RVI IOMMU :)
<davidlt[m]>
or a new interrupt controller ratified :)
<PrathamPatel[m]>
Yep, if the Linux distros (including Android) specify a profile as a base, hardware vendors will build around it.
<Eighth_Doctor>
not just that, we need the hardware<->software interaction model standardized too
<davidlt[m]>
That too. It's called OS-A SEE specification.
<Eighth_Doctor>
ideally, we'd use UEFI or something that forces the boards to have the definition baked on rather than having Linux try to define the boards
<PrathamPatel[m]>
I heard a few people say DT is better than UEFI
<Eighth_Doctor>
DT is not a standard
<Eighth_Doctor>
it's whatever the Linux kernel people feel like
<PrathamPatel[m]>
But I get your sentiment though :)
<davidlt[m]>
Some parts regarding firmware, interfaces, runtime services, etc. was moved from RISCV Platforms specs into OS-A SEE.
<davidlt[m]>
We have SMBIOS, UEFI, ACPI, DT, etc. We have them for a long time.
<Eighth_Doctor>
the important thing to me is that if we can avoid u-boot as a critical chain component, then we've succeeded
<PrathamPatel[m]>
Or better yet, PC-like firmware that just works(TM)
<Eighth_Doctor>
u-boot is the key indicator of failure, because u-boot means that the distro has to do hardware support
<davidlt[m]>
RISCV is part of EBBR (FYI), but that's not what folks want.
<davidlt[m]>
The server, or OS-A Server Profile will require specific OS-A SEE spec compliance. It will be UEFI.
<PrathamPatel[m]>
I've not dived into u-boot yet, but i noticed it had UEFI support. Would someone be able to replace EDK2 with u-boot or is u-boot used as a grub-like bootloader?
<davidlt[m]>
Now does U-Boot satisfy those requirement, I don't know.
<davidlt[m]>
U-Boot has enough stuff to run GRUB2 basically. That's it.
<Eighth_Doctor>
u-boot is typically used as a stage1 bootloader
<davidlt[m]>
I mean GRUB2 EFI.
<Eighth_Doctor>
it initializes the hardware, brings up hardware-to-software interfaces, and hands off to the OS bootloader
<davidlt[m]>
We have Tianocore for RISCV.
<davidlt[m]>
And ACPI/UEFI and Tiancore stuff is being upstreamed for QEMU virt machine.
<Eighth_Doctor>
it can also work as a direct OS bootloader too, since it has extlinux capabilities built-in
<PrathamPatel[m]>
Well if u-boot can load GRUB, most of my concerns are gone. But something similar to the PC BIOS where the user can tweak settings like boot disk, partition, fan speeds etc are a must.
<davidlt[m]>
Tianocore booted on FU540 :) HPE started work on it many years ago.
<Eighth_Doctor>
PrathamPatel[m]: if uboot boots grub, you can't have what you're asking for
<davidlt[m]>
Not sure (didn't check the last couple iterations).
<davidlt[m]>
Conan Kudo: Basically we have pretty much everything incoming.
<PrathamPatel[m]>
Eighth_Doctor: Yep, that's why I italicized 'my' :)
<PrathamPatel[m]>
Most of my need for computing is an appliance like. "Just boot the OS in the most standard way and I will handle the userspace, thank you."
<davidlt[m]>
SMBIOS, UEFI, ACPI, OS-A SEE, IOMMU, interrupt controllers, Platoforms, you name it.
<Eighth_Doctor>
in an ideal world, we'd get Google to make the Android spec require UEFI
<davidlt[m]>
External or Internal. Folks are constantly working on it (for years now).
<Eighth_Doctor>
that basically forces every platform type to include it
<PrathamPatel[m]>
But google doesn't use UEFI neither on arm nor on x86 afaik
<PrathamPatel[m]>
x86 tablets need a custom port of u-boot/abl to even start android :(
<davidlt[m]>
The main question is: can we finish specification work before RVA23 happens.
<davidlt[m]>
Or, as Jeff mentioned in the emails, RVA24 will be required to finish it up.
<Eighth_Doctor>
PrathamPatel[m]: actually, that depends
<PrathamPatel[m]>
PrathamPatel[m]: by this I mean for Android
<PrathamPatel[m]>
Not sure about chromebooks
<davidlt[m]>
It's basically depends on multiple companies agreeing on stuff within RVI.
<davidlt[m]>
Most of ISA stuff is done, non-ISA stuff is still cooking.
<Eighth_Doctor>
> <@thefossguy:matrix.org> by this I mean for Android
<Eighth_Doctor>
> Not sure about chromebooks
<Eighth_Doctor>
Android has UEFI support for "regular x86 platforms" of which there were a few such products. Chromebooks are all UEFI.
<davidlt[m]>
IOMMU is under public review now (last 45 days).
<davidlt[m]>
OS-A SEE target date is 2023 Q2.
<davidlt[m]>
ah, but it doesn't have ratification deadline yet.
<Eighth_Doctor>
EDK2 has RISC-V QEMU platform support as of March
<davidlt[m]>
Advanced Interrupt Architecture (AIA) is almost finished, but blocked by IOMMU parts. I think folks want IOMMU ratification to go 1st before ratifying AIA.
<davidlt[m]>
AIA is needed for RVA23, as it's gonna have a few new CSRs probably (maybe more).
<davidlt[m]>
Priv 1.13 spec is also part of RVA23.
<davidlt[m]>
and Priv 1.13 is not ratified.
<Eighth_Doctor>
if the Android and ChromeOS teams could both agree to a unifying standard with community Linux distributions, then we have a lock
<Eighth_Doctor>
and this is where I think Fedora can shine here
<davidlt[m]>
Conan Kudo: do you want to elaborate?
<Eighth_Doctor>
one of the strengths Fedora has is connections to upstream projects
<Eighth_Doctor>
through that, we have a large network we can get in touch with to establish these agreements and build Fedora as a reference community platform for those standards
<davidlt[m]>
I want to build Fedora for the future RISCV Platforms, but I cannot leave existing (and future) folks without Fedora.
<Eighth_Doctor>
sure
<Eighth_Doctor>
I'm not saying that you must do that
<davidlt[m]>
Which mean nirik will be unhappy with storage usage 😺
<Eighth_Doctor>
I think we all accepted that for a while to come :)
<Eighth_Doctor>
we've done multiple arm subarches before
<davidlt[m]>
But storage is cheap comparing to all the other work in my opinion.
<Eighth_Doctor>
same for powerpc and x86
<davidlt[m]>
As I said in the emails perf just between profiles will be way more singnificant compared to x86_64 baseline to v2/v3/v4.
<Eighth_Doctor>
yup
<Eighth_Doctor>
consequence of a young architecture
<davidlt[m]>
Yeah, the true momentum happened just very recently.
<davidlt[m]>
Just bitmanip perf bump alone is significant IIRC from some SPEC benchmarks.
zsun has quit [Quit: Leaving.]
<davidlt[m]>
RVA23 might incl. the 1st two extensions for JIT run-times too.
<Eighth_Doctor>
my concern for compatibility goes as far as making an architecture accessible
<davidlt[m]>
I wouldn't expect to run RVA20 on RVA37 HW or something like that.
<Eighth_Doctor>
despite what some people think, I don't automatically hate non-x86 platforms :)
<davidlt[m]>
Some significant folks publicly mentioned on RVI mailing list that they want to replace extensions if better options arrive.
<davidlt[m]>
That probably means you are OK for 10-20 years or whatever enterprise requires.
<Eighth_Doctor>
uhhh
<davidlt[m]>
It's a different story for "optional" extensions.
<Eighth_Doctor>
that's probably fine now, but not fine down the road
<davidlt[m]>
RVA23 already removes scalar crypto extensions as optional.
<davidlt[m]>
(You can still incl. them as long as they are not breaking compatibility)
<Eighth_Doctor>
they're gone entirely or mandatory now?
<davidlt[m]>
Gone.
<davidlt[m]>
Because vector is required and thus crypto vector replaces scalar crypto.
<davidlt[m]>
It's just that software explicity built for RVA23 no longer needs to "assume" scalar crypto extensions are available.
<davidlt[m]>
They can still be on the silicon (I think), because aren't introducing compatibility issues.
<davidlt[m]>
BUT, note that kernel doesn't care about RISCV Profiles.
<davidlt[m]>
You can still IFUN or whatever.
<davidlt[m]>
As long as you don't break compatibility it's all good.
<davidlt[m]>
There are extensions that are listed as not supported, because those would break compatibility in profile.
<davidlt[m]>
E.g. some extensions designed for embedded market.
<davidlt[m]>
You will never see those on anything else.
<davidlt[m]>
Mandatory + Optional Supported is not the full list of extensions we can use. Other extensions (incl. vendor extensions) can be used as long as compatibility is not broken with the profile.
<davidlt[m]>
So that means that software built for RVA20 on T-HEAD TH1520 or SOPHGO SoCs with T-HEAD API can use their TheadBitManip whatever extensions.
<davidlt[m]>
Bitmanip has not state (no new registers), etc. Has no affect on psABI too.
<davidlt[m]>
HW Probe syscall will not tell a profile. Similar to like x86_64 variants are done. You will need to check various things to calculate RVA22, 23, etc.
<davidlt[m]>
StarFive is working on solutions were all cores are compliant to a profile, but have different optional or/and vendor extensions.
<davidlt[m]>
That will be interesting if it becomes are product.
<davidlt[m]>
So far we didn't need to think about big.LITTLE designs.
<davidlt[m]>
Thus in general I would prefer us to hop on the profiles train instead of glibc hwcaps and expect that psABI will allow us probably mixing the binaries.
<davidlt[m]>
Rebuilding fedora for a new profile shouldn't be a hard task. Done way too many times already. Expect for modularity support.
<davidlt[m]>
vendor repositories is another thing. Vendors love/want to have their own optimized libraries.
<davidlt[m]>
and RISCV openly supports vendor extensions (T-HEAD has plenty of those; all except vectors are even supported by GCC, binutils and LLVM/Clang).
<davidlt[m]>
I would expect in-kernel and glibc IFUNCs to arrive sooner or later.