<shadows>
the LED on Milk-V Mars CM / CM Lite is green, and on Pine64 Star64 it is blue
<drmpeg>
It's probably better to be generic in the device tree and then use systemd to enable the heartbeat.
<shadows>
also I note that at least the Debian Kconfig for riscv64 has the actual heartbeat trigger compiled as a module which is not loaded by default
<shadows>
so on whole by default it does nothing when configured from devicetree as a heartbeat
<shadows>
drmpeg: you have VisionFive2 1.3b ? it is green LED ?
<drmpeg>
yes
<shadows>
great to know that
<shadows>
please do feel free to comment on the patch sent to LKML
vagrantc has quit [Quit: leaving]
<shadows>
'label=' is deprecated and in absence of both 'function=' and 'color=' it appears as /sys/class/leds/led-0
<shadows>
I would like to know on DeepComputing Framework 13v01 mainboard but that I did not find any schematic for
<shadows>
the others in mainline I was able to look up a schematic and all had an LED of some form or other on the PMU GPIO domain as the fourth GPIO there.
<palmer>
NP, it’s super easy to forget the b4 options. I’ve been meaning to add some post-commit hook that checks them for me, but I keep forgetting...
jacklsw has quit [Quit: Back to the real life]
JanC is now known as Guest6542
Guest6542 has quit [Killed (lead.libera.chat (Nickname regained by services))]
<nathanchance>
Sorry if that message came through twice, my internet is pretty spotty right now…
<alexghiti>
That's weird, it never reached the linux-riscv ML
jjido has joined #riscv
itrsea has quit [Remote host closed the connection]
itrsea has joined #riscv
smaeul_ has joined #riscv
smaeul has quit [Ping timeout: 260 seconds]
<palmer>
nathanchance alexghiti: ya, weird. It’s not in patchwork either… I’m going to pick it up, I’m still staring at this hwprobe thing
smaeul_ is now known as smaeul
ldevulder has quit [Ping timeout: 252 seconds]
JanC has quit [Quit: 'k zien d'r mee weh zi]
JanC has joined #riscv
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]
matrixbrain has quit [Quit: Leaving]
BootLayer has quit [Quit: Leaving]
JanC has quit [Killed (calcium.libera.chat (Nickname regained by services))]
JanC has joined #riscv
Armand|5800x has quit [Quit: Leaving]
<palmer>
xypron: rv23 or not, fence.i is banned by the Linux uABI (unless you make the prctl, but that’s really aimed at JITs). So it shouldn’t get generated in normal binaries.
<xypron>
palmer: Thanks for pointing me to prctl(). GCC, LLVM probably never generate fencei by themselves. Having Zicfencei in the defaults is more a question of whether an inline assembly fencei instruction should lead to a build error by default.
peeweep has quit [Server closed connection]
peeweep has joined #riscv
RamonaZero has quit [Ping timeout: 260 seconds]
<palmer>
xypron: I guess it’s up to the application, kind of like any other “can I use this instruction in inline asm” type question. If it’s gated with whatever checks need to be there to make the instruction valid then it’s fine, if not it’s a problem. fence.i is just special because it’s in all the HW and is broken for SW reasons, and because you won’t get a trap (just silently corrupt instructions).
<xypron>
palmer: thanks
<palmer>
Not sure if it’s helpful, it’s kind of a non-answer ;)
<xypron>
palmer: __riscv_flush_icache
<xypron>
is probably what sane software should use on Linux.
itrsea has quit [Remote host closed the connection]
itrsea has joined #riscv
<palmer>
xypron: ya, and the compiler should generate that already (from whatever builtins and generic stuff there is)
<palmer>
Yep, looks like it’s hooked to prioritize the libcall (which ends up in the vdso): https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/riscv.md;h=c3b504d088360f591837c4a0c64cdd10e78f553a;hb=HEAD#l2842
<palmer>
So on Linux you should get the same codegen from GCC for yes-zifencei and no-zifencei targets