* bjdooks
wonders when debian will make riscv64 a standard port
<thefossguy>
There’s an existing and working port in Sid, no?
<pabs3>
likely after bookworm sometime
<thefossguy>
For an official port, the riscv arch missed the window because they didnt have enough hardware that could do the final rebuild in time for release
<thefossguy>
So Debian 13 is the target now.
<bjdooks>
it's not in the standard pool, it's part of the ports so there's packages for sid/unstable
<thefossguy>
More so because more powerful RISC-V hardware is coming now
<bjdooks>
I am a generous god, so will install both emacs and vim on this system
<thefossguy>
NO.
MaxGanzII__ has joined #riscv
pecastro has joined #riscv
Raito_Bezarius has quit [Ping timeout: 252 seconds]
elastic_dog has quit [Killed (osmium.libera.chat (Nickname regained by services))]
elastic_dog has joined #riscv
MaxGanzII__ has quit [Ping timeout: 240 seconds]
ximet4 has joined #riscv
Stat_headcrabed has joined #riscv
pecastro has quit [Ping timeout: 260 seconds]
pecastro has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
awita has joined #riscv
jacklsw has quit [Ping timeout: 268 seconds]
MaxGanzII__ has joined #riscv
prabhakar has joined #riscv
awita has quit [Ping timeout: 240 seconds]
BootLayer has quit [Quit: Leaving]
prabhakarlad has joined #riscv
wingsorc has quit [Ping timeout: 240 seconds]
MaxGanzII__ has quit [Ping timeout: 240 seconds]
awita has joined #riscv
rneese has joined #riscv
BootLayer has joined #riscv
Raito_Bezarius has joined #riscv
peepsalot has quit [Ping timeout: 265 seconds]
Tenkawa has joined #riscv
prabhakarlad has quit [Quit: Client closed]
Stat_headcrabed has joined #riscv
wiagn has joined #riscv
Stat_headcrabed has quit [Ping timeout: 250 seconds]
wiagn is now known as Stat_headcrabed
jmdaemon has quit [Ping timeout: 248 seconds]
MaxGanzII__ has joined #riscv
prabhakarlad has joined #riscv
SpaceCoaster has quit [Ping timeout: 252 seconds]
awita has quit [Ping timeout: 268 seconds]
aerkiaga has joined #riscv
rneese_ has joined #riscv
rneese has quit [Read error: Connection reset by peer]
PobodysNerfect has joined #riscv
SpaceCoaster has joined #riscv
ffcc has joined #riscv
elastic_dog has quit [Ping timeout: 246 seconds]
awita has joined #riscv
elastic_dog has joined #riscv
SpaceCoaster has quit [Ping timeout: 250 seconds]
<tusko>
show me the more powerful RISC-V hardware on the doll
<tusko>
is mor powerful RISC-V hardware in the room with us now?
<tusko>
whew, I thought you were going to point at Pine64 for a sec
<thefossguy>
Lol no
<thefossguy>
They’re probably faster than the Unmatched but not fast enough
<tusko>
They somehow turned non-functioning hardware into a business model.
<thefossguy>
tusko: Tell me about it 🥹
<thefossguy>
Though I do want a PinePhone. They dont sell where I live because my country has stricter laws on radio.
<tusko>
Let me give you some advice, don't.
<thefossguy>
That still feels like a WIP even though it has been in the mark since 2+ years IIRC
<tusko>
I met a few people who have it. None of them were happy people.
<tusko>
One told me the PinePhone ruined his life.
<thefossguy>
Yeah. Learnt from looking at the struggle some PostmarketOS devs went through and then Pine64 started recommending Manjaro lol.
<thefossguy>
That was hard af to witness
<thefossguy>
tusko: 🙃
<tusko>
lol, Manjaro is still better, but somehow like the guy who uses Mint and pretends he doesn't actually use Ubuntu
<thefossguy>
The point was that the PostmarketOS guy did a lot of work for the PinePhone. And Manjaro on the other hand shipped clearly WIP stuff. Manjaro has a reputation of doing downstream work, **poorly**.
jacklsw has joined #riscv
SpaceCoaster has joined #riscv
PobodysNerfect_ has joined #riscv
PobodysNerfect has quit [Ping timeout: 276 seconds]
jay321 has joined #riscv
<geertu>
thefossguy: RGB tower cooler fan ;-)
<geertu>
Obviously they have their priorities right...
<q66>
seems tempting but i already ordered an 80-core Altra devboard so no expensive hardware for me for a while
<q66>
ordering from china is also a pain probably
<geertu>
q66: If the shipper takes care of VAT and import duties, that should be OK. But I haven't ordered anything from China since last year's new EU rules, and after the Chinese sellers adapted to these new rules...
<conchuod>
RGB tower fan or otherwise, if someone wants to give me one of those things ;)
<thefossguy>
<geertu> "Pratham Patel: RGB tower..." <- Huh? I don't get it...
<Tenkawa>
thefossguy: they have those led lighted fans
<Tenkawa>
I think thats what he means
<thefossguy>
Pine64 has RGB fans?
<Tenkawa>
I even have a nvme case with 2 cycling led color strips... unfortunately I can't adjust/turn it off
<Tenkawa>
thefossguy: no.. .I think he's attached it on the PCI-E slot
<Tenkawa>
or on top of the cpu
<Tenkawa>
Mine was in the PCI-E slot
<Tenkawa>
on my rockpro64
<Tenkawa>
bright but annoying at t imes
<thefossguy>
<geertu> "Pratham Patel: RGB tower..." <- Oh you mean the Milk-V platform. Lol yeah. But from what I heard, the hardware is a bit powerful than what's available on the RISC-V ecosystem as of now.
<Tenkawa>
thefossguy: risc-v has the capability too.. at least on units like the visionfive2
<thefossguy>
I'm not talking about capability. Of course it does.
<thefossguy>
I mean performance to deploy it in production.
<thefossguy>
That's missing, but is on the way
<Tenkawa>
Well that's a matter of perspective
<thefossguy>
That's the main reason why Debian doesn't have RISC-V as an arch in Debian 12.
<thefossguy>
There isn't enough performance or enough machines needed to rebuild all the packages for release in such a short time.
<thefossguy>
> In a nutshell, we need to rebuild all packages from sid to unstable immediately under the control of the
<thefossguy>
official Debian DSA team. The problem is that the debian RISC-V buildd team can only find 5 unmatched boards so far, one of which can only be used as a portbox[5], so 4 unmatched boards may not be enough as buildd machine. What you need to know is that building packages such as gcc will takes 2d 10+h on unmatched and we also need to give the porting team some time to deal with some of the trickier ftbfs issue during the rebuild.
<thefossguy>
* a portbox\[5, * [5\], so
* q66
will wait for p550 and hope it's not worse at building stuff than the current qemu-user arrangement
<thefossguy>
I think Horse Creek ought to work well for porting and developers
<q66>
i need a distro build machine though
<q66>
so i'm not quite sure
<q66>
currently doing qemu-user on beefy hardware because it's much faster than hifive unmatched
<q66>
but it has its drawbacks
<thefossguy>
How powerful?
<q66>
well at least enough to beat qemu :P
<thefossguy>
I think at a certain point you just need more cores instead of a fast core
<rneese_>
what os u buildin
<thefossguy>
q66: That's a rather low target. I think the VF2 already beats it.
<rneese_>
or distro
<q66>
hardly
<q66>
not if you scale it to 32 emulators
<q66>
vf2 shouldn't be more powerful than hifive unmatched
<thefossguy>
rneese_: Not building any OS per se. But I'm actively making an Arch Linux image for the VF2 and also working with some people on EL clone.
<thefossguy>
q66: Well, that 's because QEMU doesn't scale linearly :)
<q66>
it's slow at running configure scripts and stuff but in practice it evens out to be much faster overall
<q66>
i'd say on average it's uh, about half the performance of my aarch64 builder (which is 16x ampere emag)
<q66>
but considering it fully loads a ryzen 5950x box just to get that, it's not ideal
<thefossguy>
If I'm on x86, I just cross compile
MaxGanzII__ has quit [Ping timeout: 240 seconds]
<q66>
plus qemu has various shortcomings of its own (unit tests sometimes fail because of qemu unimplemented syscall etc)
<q66>
cross compiling is janky for non-embedded things
<rneese_>
I find building and compiling on arm64 for riscv right now faster then x86
<thefossguy>
q66: Yeah. That's why Debian wants physical hardware for the final rebuild.
<q66>
that depends solely on how powerful the host hardware is
<rneese_>
we us a nanopi t4 with a 512gig ssd
<rneese_>
to build and store our data
<q66>
i'm not gonna move riscv64 out of tier 3 until i can have native hardware that is capable of building the whole thing and keeping up
<q66>
though it works quite well as it is, outside of some nits like not building with systemwide LTO like other archs because of llvm still having that broken
<q66>
though lto would just make the build even slower and more unbearable with the emulated setup
<thefossguy>
Do you own a VF2? q66
<q66>
so it's probably good i can't use it yet
<q66>
no
<q66>
i'm not quite sure if i want to either
<thefossguy>
I don't recommend buying it but if you want a taste of it, I'd say get it.
<q66>
it does not seem any better than unmatched
<q66>
and at least unmatched can run mainline kernel well
<Tenkawa>
so can the VF2
<q66>
not last time i checked
<q66>
and i checked like 3 weeks ago
<Tenkawa>
I am
<Tenkawa>
Its Esmil's work
<q66>
besides powervr gpu means proprietary userland gpu drivers, which means it's useless with musl
<Tenkawa>
q66: "many" of us could care less about the gpu in it ...
<thefossguy>
The basic support (enough to get Linux up and running) is merged in upstream.
<thefossguy>
u-boot has basic support for booting from SD Card. PCIe (NVMe) and GMAC (eth) boot are not merged (though the patches have been sent).
<thefossguy>
Linux should work with 6.4 at the earliest, but I'd wait for the cleanup in v6.5.
<thefossguy>
OpenSBI is 100% upstreamed.
<q66>
yeah so it doesn't work with mainline
<Tenkawa>
I don't use any video on 20+ sbc's I have in production
<q66>
working with mainline == i can take the most recent lts kernel (6.1) and have all the functionality work out of box
<thefossguy>
I don't use the GPU, serial and SSH only. Your mileage may vary.
<q66>
or *at very least* latest released stable kernel (i.e. 6.3)
<Tenkawa>
q66: "working out of the box" = means you don't want to be responsible to know what you are running
<ch>
lol
<thefossguy>
q66: Well, Linux 6.4 is right around the corner!
<thefossguy>
I personally built upstream uboot and opensbi. The vendor kernel boots! (Ethernet doesn't work because u-boot doesn't have patches for GMAC yet.) That's a big achievement.
<ch>
what an argument!
<q66>
yeah, shit ass argument
<thefossguy>
That's a bad take Tenkawa
<Tenkawa>
ch: no.. its not. If you don't its the "easiest" way to be burnt in the future.
<q66>
thefossguy: if i want that specific soc i'd rather buy a star64 anyway
<conchuod>
Why would you rather a star64?
<Tenkawa>
I'm still not convinced its vaporware.... its still "sold out" everywhere
<conchuod>
At least the VF2 has 1st party support...
<Tenkawa>
Since Apr 1 I've been checking everyday and havent seen it avail
<rneese_>
star6r4
<conchuod>
Isn't the whole pine thing to not really do any sw support?
<Tenkawa>
conchuod: sadly yes
<rneese_>
star64 is also out there
<thefossguy>
Dont do that. VF2 has great community forums. The SBC support might be a hit or miss based on how Pine64 do their DTS.
<Tenkawa>
conchuod: I like my PBP but Pine is a distant company
<thefossguy>
rneese_: Haven’t seen anyone in public talk about it.
<thefossguy>
I mean owning it
<conchuod>
I should tried to get the dude at FOSDEM to give me or Emil his prototype but I was too shy.
<Tenkawa>
thefossguy: I was suspicious that it got "Announced" on Apr 1 and its been sold out ever since
<conchuod>
I'll believe it is real when I get CCed on some dts patches Tenkawa :)
<Tenkawa>
Indeed or even a "click here to order" on Ameridroid/Pine
<Tenkawa>
he
<Tenkawa>
h
<Tenkawa>
I did btw for any VF2 owners discover 2 major speedups yesterday
<Tenkawa>
there is a nvme command to change the block size (I had to update the utility and library though to make it work)
<Tenkawa>
and adjusting the core nvme subsystem settings helped a lot for me.
<thefossguy>
Tenkawa: I don't have an NVMe but I'm interested. Please share the link :D
<Tenkawa>
well going from a 512byte block to a 4k is a substantial switch
<Tenkawa>
Especially with reads
<q66>
conchuod: unlikely to be much different software-wise by the end, better availability once actually available, already got a bunch of pine64 boards and mostly happy enough with them
<q66>
but also i'm not actually gonna buy either of them for the time being
<q66>
i'll wait if p550 is any good and then we'll see
<q66>
i'm not particularly interested in owning yet another u74 potato
heat has quit [Ping timeout: 240 seconds]
<thefossguy>
Yeah, if you want performance, I'd wait for Horse Creek too
<thefossguy>
But that's going to be at least USD 400/500 plus
<conchuod>
q66: yeah, u74 or otherwise tbh. I don't think the milkv yoke is gonna be that interesting of an SBC either.
<q66>
i just paid 3k for an altra devboard, 500 bucks isn't that much :P
<conchuod>
Apart from core count, there's not much of interest in it.
<q66>
well, as a build machine it would probably be fine
<thefossguy>
Then you're definitely the target audience for this :D
<q66>
even if you gotta rely on some vendor kernel junk or whatever
<conchuod>
Aye
heat has joined #riscv
<q66>
i think p550 is gonna be more than 500
<q66>
considering unmatched was iirc 750 when i got it
<q66>
but either way it's not a huge deal
<thefossguy>
:)
<q66>
i'm more worried about the crappy ass cooling from the pics i've seen
<q66>
i think sifive is deliberately trolling with these
<q66>
unmatched already had way worse cooling than it necessarily had to be
<q66>
and i saw the pics for p550 and they *still* went for a 20mm fan despite using a far larger heatsink
<q66>
using some plastic contraption to hold it in place, and same shitty plastic frame clipping below the soc for the heatsink attachment
<q66>
just why, all it would take is two holes in pcb
<thefossguy>
I'd be more worried about their PCIe implementation.
<thefossguy>
Even Ampere couldn't get it compliant to the point where a GPU just work OOTB
<q66>
gpu works fine on my unmatched
<thefossguy>
There was a whole thing about this a few months ago so I don't recall the details much
<thefossguy>
q66: There's a rather limited number of GPUs whose drivers work on RISC-V. This will unearth when more GPUs are working on RISC-V
<q66>
anything from amd that is polaris and older will work
<q66>
stuff newer than polaris will not work but that's not a pcie problem, that's amd driver problem
<thefossguy>
Oddly weird that it works. But hey, that's good :)
<q66>
they use hardware fp in the display engine code and that needs specific hookup for each arch
<q66>
i know that because i was involved in this for ppc64le and for aarch64
<thefossguy>
Oh well
<q66>
aarch64 was kinda impossible to do properly until recently because the code did basically like
<q66>
void foo() { DC_FP_ENABLE(); ... some fp crap here ... DC_FP_DISABLE(); }
<q66>
and then it just compiled the file containing these things with hardfloat
<q66>
that sorta works on x86_64 and ppc64le where you have stuff like softp abis and separate floating point regs etc, so the compiler is not as likely to touch fp/vector-related stuff where it "shouldn't"
<q66>
but not on aarch64 where asimd is a part of the base thing and the way linux kernel disables that is compiling everything with -mgeneral-regs-only
<q66>
so removing -mgeneral-regs-only results in the compiler suddenly touching stuff it shouldn't even outside the boundaries, and everything goes wrong
<q66>
so the last few kernel releases had a major refactoring going on, to move everything that should touch floats into separate translation units and then guard the calls to those from the outside
<q66>
from 6.2 onwards it should be working
<q66>
but obviously nobody did the arch-specific hookup work for riscv yet, so...
<thefossguy>
Ah. Gotcha, thanks.
<q66>
it probably isn't too hard to do, you have an enable/disable macro and each is like 3 lines, e.g. on ppc64 it needs to disable preemption + set the right bit in MSR, etc
MaxGanzII__ has quit [Remote host closed the connection]
MaxGanzII__ has joined #riscv
<meowray>
clang --target=riscv64 -S -g a.c; clang --target=riscv64 -c a.s; line number information for assembly files doesn't work with -mrelax. Does anyone know an existing bug? Otherwise I'll file one.