sorear changed the topic of #riscv to: RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv | Matrix: #riscv:catircservices.org
itrsea has quit [Remote host closed the connection]
tgamblin has quit [Ping timeout: 240 seconds]
tgamblin has joined #riscv
Armand|X13s has joined #riscv
handsome_feng has joined #riscv
Armand|X13s has quit [Quit: Leaving]
BootLayer has joined #riscv
BootLayer has quit [Quit: Leaving]
haritz has quit [Ping timeout: 265 seconds]
tgamblin has quit [Ping timeout: 268 seconds]
haritz has joined #riscv
haritz has quit [Changing host]
haritz has joined #riscv
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #riscv
zjason` is now known as zjason
<shadows> dramforever[m]1: adding a delay was successful, thanks... tuning that now down to figure out the minimum
<dramforever[m]1> <shadows> dramforever: adding a delay was successful, thanks... tuning that now down to figure out the minimum
<dramforever[m]1> nice
<dramforever[m]1> if it's like on the order of one second i'll just leave it there
<dramforever[m]1> or ask milk-v about it
agentcasey_ has joined #riscv
agentcasey has quit [Ping timeout: 244 seconds]
<shadows> dramforever[m]1: okay it's different than I remembered it, so, the firmware fails to load if I use the pwrseq and a delay, but it loads correctly if that pinctrl in &mmc1
<shadows> dramforever[m]1: how is the host wake supposed to be wired up?
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #riscv
<dramforever[m]1> <shadows> dramforever: how is the host wake supposed to be wired up?
<dramforever[m]1> uh.... the same way as in rk3308-bpi-p2-pro.dts?
<dramforever[m]1> what do you have now? i think the way we're talking about it now it's a bit abstract to see what could be going wrong
<dramforever[m]1> can you post like a pastebin or have the linux tree somewhere i could see?
ldevulder has joined #riscv
fossdd has joined #riscv
hightower2 has joined #riscv
coldfeet has joined #riscv
coldfeet has quit [Client Quit]
Trifton has quit [Remote host closed the connection]
Trifton has joined #riscv
mahk has quit [Ping timeout: 252 seconds]
<sorear> the current glibc CFI patches, https://inbox.sourceware.org/libc-alpha/20250711135255.1732496-11-jesse.huang@sifive.com/, change the size of jmp_buf depending on whether __riscv_shadow_stack is defined. I don't like this but I'm not certain it's actually a problem or that I'm the best one to bring it up
prabhakalad has joined #riscv
<sorear> the jmp_buf struct has 14 spare words (in a rather silly place) and aarch64 gcs / x86_64 shstk use one of them to enable shadow stack unwinding without changing struct sizes. risc-v does not, at the moment
<sorear> if people think the right way to handle rva23 is a forced break, rebootstrap everything, all software everywhere goes rva23 only immediately, then this probably isn't an issue, but it's a problem if you want to run some rva23 on a rva20 os image or use rva20 precompiled software on a rva23 OS
mahk has joined #riscv
drmpeg has quit [Ping timeout: 276 seconds]
mahk has quit [Ping timeout: 248 seconds]
mahk has joined #riscv
drmpeg has joined #riscv
mahk has quit [Ping timeout: 260 seconds]
mahk has joined #riscv
Andre_Z has joined #riscv
<xypron> sorear: If you think of snaps and flatpaks, you can expect running code compiled for RVA20 on RVA23 OSes.
<ganboing> The cover letter of that patchset says: ABI Breakage Notes
<ganboing> [1] SSP is appended at the end of 'struct __jmp_buf_internal_tag'.
<sorear> there is no acknowledgement that this is a bad thing or attempt to argue it's a good thing, i'd like one or the other
<sorear> you can have a legitimate patch that breaks ABI and has breakage notes, and the patch isn't marked [WIP]
<sorear> xypron: surely snap/flatpak could treat rva23 as an entirely new architecture?
<ganboing> Why not raise a question/concern on that v2 patchset thread?
<dramforever[m]1> that's the question right why seemingly has nobody else objected to this
<dramforever[m]1> it's not exactly hidden
<dramforever[m]1> so why was nobody pointing it out
<ganboing> Yea, looks like nobody had concern on jmp_buf change with v1
<xypron> sorear: I don't expect all snaps to be rebuilt.
<xypron> And I would expect maintainers who have been slow at providing riscv64 snaps to build two versions of it.
<xypron> would not expect
coldfeet has joined #riscv
matrixbrain has quit [Quit: Leaving]
<sorear> that's good, if it's intentional they'll hopefully reply to that effect
<dramforever[m]1> i don't think it highlights the severity enough but interop between [realistically rv64gc] and RVA23 is the great point
kf has quit [Remote host closed the connection]
raghavgururajan has quit [Remote host closed the connection]
tusf has quit [Remote host closed the connection]
sm2n has quit [Remote host closed the connection]
jakzale has quit [Remote host closed the connection]
shreyasminocha has quit [Remote host closed the connection]
pld has quit [Remote host closed the connection]
OctopusET has quit [Remote host closed the connection]
nmeum has quit [Remote host closed the connection]
<sorear> i get the impression there are a lot of people who wish rva20 would go away completely asap
nmeum has joined #riscv
<dramforever[m]1> has rva20 even happened
<dramforever[m]1> i am not aware of any software that targets rva20
<dramforever[m]1> admittedly, i haven't been looking very hard
<sorear> nobody targets profiles as a whole but some of the rva20 inventions like Ziccif are used for ftrace I think
coldfeet has quit [Quit: Lost terminal]
<sorear> the common "rv64gc" hw has most or all of the extra properties implied by rva20
<dramforever[m]1> yeah that's just text
<dramforever[m]1> sure, a reasonable rva20 hardware
<sorear> my general position is that rv64gc/rva20 is actually a _research_ profile, since it was designed for reasonable individual or small team implementations in ways that rva23 wasn't and shouldn't have been
<sorear> and until we have a new research-class profile rva20 can never be truly obsolete, regardless of what happens with commercial hardwar
<sorear> it would be cool if at least one of the well-supported distros maintained at least some support for a profile that can be implemented by individuals, as long as possible
<dramforever[m]1> my personal vision is always that the point of riscv is having baselines in the mariana trench if possible. not that my view particularly matters
<sorear> broadly agree but if I had a time machine Zimop would be part of RVA20 if not I itself
<dramforever[m]1> no comment on anything "it should have been included"
<dramforever[m]1> but... i kinda always want to know is there anyone else even thinking of moving on to RVA23
<dramforever[m]1> like in 2030 maybe but in like a few years
<dramforever[m]1> it would certainly be very unlike debian to do that, even in 2030, for example
<sorear> define "anyone" "else" and "moving on". the server platform spec requires RVA23 from inception, AFAIK all of the serious commercial hardware vendors are targeting RVA23 for in-development products, Ubuntu has publicly committed to RVA23, Fedora has publicly committed to target server platform once it exists
<dramforever[m]1> thanks, that's helpful information
<dramforever[m]1> i didn't know about the fedora part
<sorear> i don't know if fedora has set a timeline for the rva23 mass rebuild like ubuntu did, haven't been following that closely
<sorear> might be redoing things as part of a switch from personal to community infra?
<dramforever[m]1> i'm sure i find it extremely very wild that ubuntu is taking on the equivalent of basically x86_64-v6 this year
<dramforever[m]1> uh, i'm sure i'm not alone in finding it...
<dramforever[m]1> (the difference of course is we know exactly what RVA23 has)
<dramforever[m]1> like imagine if ubuntu says "in 25.20 we will stop support for x86-64 processors without APX"
<dramforever[m]1> s/25.20/25.10/
<sorear> did ubuntu drop x86-64-v1 yet and how close did it happen to the x86-64-v1 patent expiry in ~sep 2020?
<sorear> or 2023 if you count from actually available chips
<sorear> instead of the programmer's manual
naoki has joined #riscv
prabhakalad has quit [Quit: Konversation terminated!]
naoki has quit [Client Quit]
prabhakalad has joined #riscv
prabhakalad has quit [Client Quit]
prabhakalad has joined #riscv
kf has joined #riscv
OctopusET has joined #riscv
jakzale has joined #riscv
pld has joined #riscv
sm2n has joined #riscv
raghavgururajan has joined #riscv
tusf has joined #riscv
shreyasminocha has joined #riscv
nmeum has quit [Remote host closed the connection]
nmeum has joined #riscv
alperak has joined #riscv
katzia has quit [Ping timeout: 252 seconds]
prabhakalad has quit [Read error: Connection reset by peer]
tgamblin has joined #riscv
haritz has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
Andre_Z has quit [Quit: Leaving.]
pecastro has joined #riscv
Pokey has quit [Quit: Hecc! My server must have died!]
prabhakalad has joined #riscv
coldfeet has joined #riscv
coldfeet has quit [Client Quit]
haritz has joined #riscv
haritz has quit [Changing host]
haritz has joined #riscv
<ncopa> Hi! I'm testing network speed on starfive v2 using iperf. Sometimes it shows pretty low numbers.
<ncopa> 530 Mbits/sec
<ncopa> and sometimes it is up to 941 Mbits/sec
<ncopa> I am considering replacing an old x86 pcengines with starfive
<ncopa> the old pcengines machine always gives ~940 Mbits/sec
<jrtc27> riscv sbcs aren't generally known for their performance
<ncopa> it is comparable to the pcengines machine
<ncopa> and bit faster in my tests
<jrtc27> I don't know what you should expect of the visionfive but it doesn't at all surprise me
<ncopa> except that network speed all of a sudden drops
<ncopa> it usually gives 941 Mbits/sec
<ncopa> anyway, i know it is not a speed monster, but it is slightly faster than the old pcengines machine, and uses less energy, so I will retire my pcengines
haritz has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
haritz has joined #riscv
haritz has quit [Changing host]
haritz has joined #riscv
BootLayer has joined #riscv
<mps> ncopa: try to experiment with cpu schedulers
<mps> I have 'echo 750000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq' on VF2
<ncopa> right, it may be the cpu that scales down and up
handsome_feng has quit [Quit: Connection closed for inactivity]
Armand|5800x has joined #riscv
<mps> VF2 is quite fine for my 400Mbit link
<ncopa> yeah. Its the LAN side im testing
<ncopa> the VF2 is faster than the old pcengines in my tests
Andre_Z has joined #riscv
<ncopa> whoa! im back!
<ncopa> that was a smooth migration. I just copied the apkovl from the x86 machine, changed some paths (mmcblk0p1 -> mmcblk1p3) refreshed the apk cache and that was it basically
<ncopa> dmvpn works. everythign seems to work
ldevulder has quit [Ping timeout: 240 seconds]
persist has joined #riscv
coldfeet has joined #riscv
jacklsw has joined #riscv
<ncopa> I wonder how to connect an RTC to it
coldfeet has quit [Quit: Lost terminal]
jacklsw has quit [Ping timeout: 276 seconds]
persist has quit [Quit: Leaving]
<mps> ncopa: chronyd works fine in my case, though I thought to by rtc module and attach it to gpio (spi or i2c) but didn't found it
<mps> are you using linux-lts kernel
<ncopa> yes linux-lts. yes an rtc I could plug into gpio
<mps> there are many of rtc modules on market. thing is find one which is simple to add setup to not write kernel module/driver
<mps> i tried to write rtf driver for visionfive V1 but newer finished it
<mps> s/rtf/rtc
mahk has quit [Changing host]
mahk has joined #riscv
Anarchos has joined #riscv
coldfeet has joined #riscv
hightower3 has joined #riscv
hightower2 has quit [Ping timeout: 252 seconds]
coldfeet has quit [Ping timeout: 240 seconds]
coldfeet has joined #riscv
hightower4 has joined #riscv
hightower3 has quit [Ping timeout: 260 seconds]
jjido has joined #riscv
vagrantc has joined #riscv
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]
Armand|5800x has quit [Quit: Leaving]
BootLayer has quit [Quit: Leaving]
wgrant has quit [Ping timeout: 252 seconds]
wgrant has joined #riscv
pabs3 has quit [Ping timeout: 245 seconds]
coldfeet has quit [Ping timeout: 240 seconds]
coldfeet has joined #riscv
pabs3 has joined #riscv
wgrant has quit [Ping timeout: 248 seconds]
wgrant has joined #riscv
cronos has quit [Ping timeout: 248 seconds]
cronos has joined #riscv
coldfeet has quit [Quit: Lost terminal]
alperak has quit [Quit: Connection closed for inactivity]
Anarchos has quit [Ping timeout: 260 seconds]
hightower3 has joined #riscv
hightower4 has quit [Ping timeout: 260 seconds]
ldevulder has joined #riscv
zjason` has joined #riscv
jjido has joined #riscv
zjason has quit [Ping timeout: 252 seconds]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #riscv
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]
<palmer> I’ve got a meeting tomorrow morning, so I have to skip the patchwork meeting
ldevulder has quit [Ping timeout: 240 seconds]
dramforever[m]1 has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #riscv
<shadows> ncopa: what U-Boot are you using?
Andre_Z has quit [Quit: Leaving.]
katzie has joined #riscv
_ghostbyte_ has quit [Ping timeout: 260 seconds]
_ghostbyte_ has joined #riscv
<shadows> ncopa: there is a conflict with the addressing of commonly available rtc modules FYI and the eeprom write function
itrsea has joined #riscv
pecastro has quit [Ping timeout: 240 seconds]
hightower4 has joined #riscv