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
bkeys has joined #fedora-riscv
bkeys has quit [Ping timeout: 246 seconds]
cyberpear has quit [Quit: Connection closed for inactivity]
jcajka has joined #fedora-riscv
somlo has quit [Ping timeout: 250 seconds]
somlo has joined #fedora-riscv
<davidlt[m]> rwmjones: my fingers are rusty a bit, slow to type all the commands, but opensbi is built and gnutls is cooking :)
<davidlt[m]> I guess I will need to order a bucket of vitamins for my eyes :D
<davidlt[m]> U-boot build should follow sometime later today
<davidlt[m]> I think I got access to cfarm openstack instace too, but haven't tried yet
<davidlt[m]> Hopefully Fedora will start building v5.18.X sooner than later
<davidlt[m]> It will be nightmare to adjust the CONFIG_* flags for this :/
<davidlt[m]> Stupid question time.
<davidlt[m]> Today we mostly assume that "riscv64" arch string is RV64GC + LP64D.
<davidlt[m]> What would we do for RVA22U64 or RVA23U64 profiles? (once profiles land)
<davidlt[m]> If one would like to extend the default ISA, would you build for RVA23U64 profile and continue to use riscv64 as the arch string? maybe riscv64a22 or something?
<davidlt[m]> RVA22U64 is somewhat OK ABI wise, but RVA23U64 would add V extensions, which could trigger ABI change (vectors passed in registers instead of stack).
<davidlt[m]> At least that's how it works on x86_64 IIRC.
<davidlt[m]> Of course psABI for riscv is not yet ratified too :)
<davidlt[m]> 1st attempt at U-Boot with 2022.07-rc without updating all the patches.
masami has joined #fedora-riscv
msalter has quit [Quit: Leaving]
zsun has joined #fedora-riscv
bkeys has joined #fedora-riscv
<rwmjones|holiday> ok
<rwmjones|holiday> davidlt[m]: I'm not super-keen to change the arch string, that has been a pain for armv7
<davidlt[m]> rwmjones|holiday: I don't think there is other option.
<davidlt[m]> Unless we want to make a large user base angry :)
<davidlt[m]> To my surprise most patches applied :)
<davidlt[m]> Fetching that SRPM and adjusting the patches
<rwmjones|holiday> davidlt[m]: which bit of arch string would change? do you mean what the kernel reports or RPM or ...?
<davidlt[m]> RPM/Koji
<davidlt[m]> For example RVA{22,23} are significantly larger in term of extensions marked as "mandatory"
zsun has quit [Quit: Leaving.]
bkeys1 has joined #fedora-riscv
bkeys has quit [Ping timeout: 258 seconds]
bkeys1 is now known as bkeys
<somlo> davidlt[m]: now that MMC support for LiteX is upstream, what are the chances for enabling LiteX support in riscv64 fedora? (essentially, enable LITEX_SOC_CONTROLLER, SERIAL_LITEUART[_CONSOLE], LITEX_LITEETH, and MMC_LITEX in the kernel config file)
<davidlt[m]> somlo: send me full list of CONFIG_* options that needs to explicitly enabled =y =m
<somlo> davidlt[m]: it's the list above; SERIAL_LITEUART_CONSOLE is bool, all the rest are tristate; I'm not quite sure which of the tristate ones MUST be =y (I assume at least LITEX_SOC_CONTROLLER and SERIAL_LITEUART); the rest (LITEX_LITEETH and MMC_LITEX) can probably be =m (assuming they're included on the initrd image), I think
jcajka has quit [Quit: Leaving]
bkeys1 has joined #fedora-riscv
bkeys has quit [Ping timeout: 256 seconds]
bkeys1 is now known as bkeys
bkeys has quit [Quit: With every step we take, danger will follow closely]
bkeys has joined #fedora-riscv
bkeys has quit [Ping timeout: 240 seconds]
bkeys has joined #fedora-riscv
<rwmjones|holiday> davidlt[m]: why do we actually have to change those strings though? just change the baseline (as we do with x86-64) and get glibc to fail loudly when an extension is not present
<rwmjones|holiday> exactly as we do in x86-64 too
<davidlt[m]> rwmjones|holiday: because most boards that people can buy are still (and will be) RV64GC?
<davidlt[m]> Would we be happy to sacrifice that part of the community because there are ratified standards and performance increase?
<davidlt[m]> There has been multiple armv7* in the past. It kinda worked.
<rwmjones|holiday> you're doing the work so do what you think is best, but I just think that for armv7 it didn't really work that well
<rwmjones|holiday> is the plan to build parallel streams for (old) RV64GC and the new platform?
<rwmjones|holiday> I mean to say, will we abandon hifive <= unmatched (so they have to use Fedora 33) and only upgrade Fedora for the new platform, or will there be new Fedora for both platforms?
<davidlt[m]> rwmjones|holiday: I am just asking the question :) What happens once we have the standards (psABI, Profiles, Platforms, IOMMU, etc.)
<rwmjones|holiday> also might be an idea to find out what Debian are doing
<davidlt[m]> Kinda, we would abandon BeagleBoard, new VisionFive board, some other boards.
<rwmjones|holiday> my opinion is the closer to x86-64 it works, the better
<rwmjones|holiday> just as a principle / direction of travel, it may not be possible
<davidlt[m]> It's gonna take a year to ratify that Profiles spec and probably even more time to get cores that comply with that, not to mention Platforms spec.
<rwmjones|holiday> qemu will be able to run it now though? or at least, what we build now?
<davidlt[m]> I keep telling (myself) that every board right now helps SW ecosystem, but they are also e-waste :)
<rwmjones|holiday> well my hifive unleashed boards are museum pieces :-)
<davidlt[m]> What we build now is kinda RVA20U64 Profile (if that happens to be ratified).
<davidlt[m]> Hey, they their SoC is pretty much as fast as Unmatched :)
<rwmjones|holiday> how many did they make? I heard it was only like 300
<davidlt[m]> BealgeV?
<rwmjones|holiday> no the original unleashed
<davidlt[m]> Yeah, 300 for developers, but a new one is about to launch!
<davidlt[m]> Ah, don't know.
<rwmjones|holiday> right, but the boards are museum pieces :-) I'll donate mine to
<davidlt[m]> Hehe :)
<rwmjones|holiday> https://www.tnmoc.org/
<rwmjones|holiday> (one day, not yet!)
<davidlt[m]> Yeah, so we need to think about this Profiles/Platforms/psABI/etc. thing.
<davidlt[m]> Right now we don't even have psABI ratified and ratified one does not match reality :)
<rwmjones|holiday> this might actually be the one time that asking the fedora community is a good idea
<davidlt[m]> *frozen one
<rwmjones|holiday> I would rarely say that, but in this case they might have experience of armv7 and sound opinions
<davidlt[m]> Profiles are not even frozen yet :)
<rwmjones|holiday> I mean just asking about the general principle of it
<davidlt[m]> To my knowledge new extensions (especially bitnamip) is huge perf. improvement, but I don't have data to back that up.
<davidlt[m]> It's like armv8 -> armv9, rva20u64 -> rva23u64
<davidlt[m]> Gazillion of new extensions become mandatory.
<rwmjones|holiday> right, but it's also (a bit) like x86_64 -> x86_64-v2 (etc)
<davidlt[m]> Depends.
pierosimonet has joined #fedora-riscv
<davidlt[m]> What do do once you get to x86_64-v3 and have ability to pass those 256-bit vectors in registers instead of stack?
<rwmjones|holiday> well in the case of RHEL 9 we made glibc print an error when you run it on older hardware :-(
<rwmjones|holiday> that's really my question about are we going to build Fedora twice for the old & new hardware, or just once?
<davidlt[m]> So yeah, in general the ABI doesn't change (unless we want).
<rwmjones|holiday> in RHEL we didn't have to support the old hardware
<davidlt[m]> In that case it's just making a lot of risc-v e-waste :)
<davidlt[m]> So that's a thing, how much of community will be stuck with RVA20U64 because that's the only affordable thing?
<rwmjones|holiday> so the other thing is we could build for the old hardware, and then (in a year or whenever the new hardware becomes available) start building for the new hw
<davidlt[m]> Anyway you still make some folks sad :)
<rwmjones|holiday> :-)
<davidlt[m]> Fedora didn't switch to x86_64-v2 or v3 :)
<davidlt[m]> I would love to run v3 ;)
<davidlt[m]> Just something to think about :)
<rwmjones|holiday> IMHO (and you're free to ignore me as you're doing the work not me) can you put the issues into an email for fedora-devel-list?
<rwmjones|holiday> there are people like hans de goede there who really know about armv7 / aarch64 and will have an opinion
<davidlt[m]> I don't think it's a time to discuss that. Profiles are not ratified, not frozen and we don't know the final picture of all of this.
<davidlt[m]> As I said we don't even have psABI ratified :)
<rwmjones|holiday> understood
<rwmjones|holiday> I've got to go; I won't be around much til Tuesday because of the queen's jubilee stuff
<davidlt[m]> (worse, it the frozen doc doesn't match reality)
<rwmjones|holiday> I'll read scrollback though
<davidlt[m]> Have fun! :)
<rwmjones|holiday> sure :-)
bkeys has quit [Quit: With every step we take, danger will follow closely]
bkeys has joined #fedora-riscv
bkeys has quit [Ping timeout: 246 seconds]
pierosimonet has quit [Remote host closed the connection]
bkeys has joined #fedora-riscv
bkeys has quit [Ping timeout: 246 seconds]
bkeys has joined #fedora-riscv
bkeys1 has joined #fedora-riscv
bkeys has quit [Ping timeout: 258 seconds]
bkeys1 is now known as bkeys
bkeys has quit [Read error: Connection reset by peer]
bkeys has joined #fedora-riscv
cyberpear has joined #fedora-riscv
<droidrage> can i search all bugs filtered to riscv only? like all flatpak or pipewire or "audio" related issues?
<droidrage> and are these bugs comprehensiveish or do users not bother putting many bugs still on the bugtracker?
<droidrage> im trying to see if i.e vision5 with fedora is bugfreeish enough to buy yet