[itchyjunk] has quit [Remote host closed the connection]
PyroPeter has quit [Ping timeout: 258 seconds]
PyroPeter has joined #riscv
<adjtm>
solrize, has alibaba an armv9's architecture license?
<adjtm>
I don't think that ISA patents is a good thing, but anyway
<adjtm>
and I don't think it's made at 28nm, so it's probably made by tsmc
<adjtm>
maybe ARM China has the right to license armv9 even if they don't have arm's armv9 core designs
<adjtm>
anyway good news that they are releasing open source riscv designs
<davidlt>
that seems expensive
<davidlt>
DDR5, PCIe Gen 5
jamtorus has joined #riscv
jellydonut has quit [Ping timeout: 264 seconds]
EchelonX has joined #riscv
<solrize>
adjtm, no idea
Jmabsd has joined #riscv
jacklsw has quit [Ping timeout: 252 seconds]
<Jmabsd>
sorear,pierce,rjek,*: Can you let me know the approx real world power consumption of the SiFive Unmatched. The 150W figure on their web site is so weird. The Raspberr Pi takes like, 5-7 watts ballpark
<davidlt>
Jmabsd, depends on the configuration
<davidlt>
the lowest is 30-50W from the wall
<davidlt>
the max <200W I pulled with RX 580 IIRC
<davidlt>
but I don't recall exact numbers
<pierce>
I don't have a way of measuring it I'm sorry
<Jmabsd>
davidlt: that's interesting. all what consumes power is really the SoC and the PCI switch. i see.
<adjtm>
Jmabsd, 150 W (Fully Loaded). Fully Loaded implies Board + PCIe Card(not requiring external power source) + M.2 Wi-Fi Module + M.2 NVME SSD Module + SD Card + Quad-USB and Ethernet Connectors Loaded + Both Chassis Fans
<adjtm>
^ from the web
<Jmabsd>
okay yeah so it's a nice safe desktop, however as "mini toss away home server" in a house that is not electrically heated, it is some expense to run
<davidlt>
30+W was with WiFi card removed, GPU removed, nothing on USB, fans removed, etc.
<Jmabsd>
mhm
<davidlt>
but with M.2
<Jmabsd>
30W = 262 watt hours per year
<davidlt>
and that's with CPU stress testing IIRC
<Jmabsd>
oh!
<Jmabsd>
davidlt: and in idle?
<davidlt>
don't recall
<davidlt>
I recall that rage was 30-50W for what I needed, but more like 30-40+W from the wall
<Jmabsd>
davidlt: I'd absolutely love to know. by chance would you be able to check next days?
<Jmabsd>
30+W for actually doing anything, is fine.
<davidlt>
don't know
<davidlt>
I might try to find this in the notes somewhere
<Jmabsd>
davidlt: that would be great
<Jmabsd>
by the way, at CPU overheat the Unmatched will just speedcap, will it?
<davidlt>
my notes state: The board was consuming 25-27W, let's say <30W, super max-impossible <40W.
<Jmabsd>
instead of physically melt down
<davidlt>
Jmabsd, no, it will trigger power off
<davidlt>
there is no DVFS
<davidlt>
For the test it was:
<Jmabsd>
ouch i see. hmm. so it needs a fan then
<davidlt>
Launched stress-ng --cpu 6, stress-ng --class io --seq 4 and fio benchmark with 4 threads (random read/write mix).
<Jmabsd>
davidlt: by chance do you have an Unmatched where you are, if so what about power it on and see what the idle power is
<davidlt>
cannot, have to run in a few minutes
<Jmabsd>
ic. what about later today/tomorrow
<pierce>
Jmabsd: you seem very interested in these numbers, what’s the urgency?
<Jmabsd>
pierce: just curious how much it would cost per year as home server
<Jmabsd>
10 watts => 87 watt hours per year
<adjtm>
Jmabsd, because pcie x16 should provide 75W to the card, it means that the maximum power without a card on the pcie x16 slot is 75W
<Jmabsd>
sure i know peripherals may eeat a loot
davidlt has quit [Ping timeout: 260 seconds]
riff-IRC has quit [Remote host closed the connection]
riff-IRC has joined #riscv
ntwk has quit [Ping timeout: 258 seconds]
ntwk has joined #riscv
BOKALDO has joined #riscv
freakazoid343 has joined #riscv
kito-cheng has quit [Quit: Connection closed for inactivity]
freakazoid12345 has quit [Ping timeout: 258 seconds]
freakazoid12345 has joined #riscv
jacklsw has joined #riscv
brsvh has joined #riscv
freakazoid343 has quit [Ping timeout: 258 seconds]
brsvh has quit [Client Quit]
brsvh has joined #riscv
brsvh has quit [Quit: brsvh]
brsvh has joined #riscv
<Jmabsd>
what is DVFS an abbreviation for?
crabbedhaloablut has quit [Ping timeout: 276 seconds]
brsvh has quit [Quit: brsvh]
brsvh has joined #riscv
reinhardt has joined #riscv
cronos has quit [Ping timeout: 245 seconds]
GenTooMan has quit [Ping timeout: 245 seconds]
brsvh has quit [Quit: brsvh]
solrize has quit [Ping timeout: 245 seconds]
GenTooMan has joined #riscv
brsvh has joined #riscv
brsvh has quit [Remote host closed the connection]
solrize has joined #riscv
brsvh has joined #riscv
jack_lsw has joined #riscv
jacklsw has quit [Ping timeout: 245 seconds]
crabbedhaloablut has joined #riscv
ntwk has quit [Ping timeout: 264 seconds]
brsvh has quit [Quit: brsvh]
ntwk has joined #riscv
brsvh has joined #riscv
winterflaw has joined #riscv
brsvh has quit [Quit: brsvh]
brsvh has joined #riscv
smartin has joined #riscv
davidlt has joined #riscv
winterflaw has quit [Remote host closed the connection]
brsvh has quit [Quit: brsvh]
freakazoid343 has joined #riscv
jack_lsw has quit [Quit: Back to the real world]
jacklsw has joined #riscv
freakazoid12345 has quit [Ping timeout: 268 seconds]
pecastro has joined #riscv
ntwk has quit [Ping timeout: 252 seconds]
ntwk has joined #riscv
<adjtm>
Jmabsd, what it explains in all the first entries when you search "dvfs" in google and probably any other search engine :)
<adjtm>
dynamic voltage and frequency scaling
<Jmabsd>
ahaaaa yesyes ic
<Jmabsd>
okay, in other words it won't dynamically consume less power when the computer is idling. ic.
<Jmabsd>
the software could change frequency though?
<Jmabsd>
or only at boot perhaps
<adjtm>
Jmabsd, the cpu consumes less power when idling, even without dvfs
<Jmabsd>
oh reilly! okay! thanks for telling. ok. i look forward to learn the idle consumption later.
<adjtm>
I don't know if SiFive Unmatched's soc allows changing frequency, I only own riscv uc
<pierce>
I don't think anyone committed to providing you more power consumption figures Jmabsd
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
<Jmabsd>
pierce: mm. perhaps davidlt later let's see
<davidlt>
the frequency can be changed in U-Boot (but I advice against it)
<davidlt>
you can change freq in Linux with some DT changes (define opp tables), but again I advice against it
<davidlt>
FU540 and FU740 are very simple / minimalist SoCs which are not designed to be in any particular product, just as dev/eval board
<davidlt>
thus it's not like from Allwinner, Rockchip, Qualcomm, etc. It lacks a lot of features compared to those SoCs
X-Scale` has joined #riscv
X-Scale has quit [Ping timeout: 252 seconds]
X-Scale` is now known as X-Scale
freakazoid12345 has joined #riscv
freakazoid343 has quit [Ping timeout: 258 seconds]
hendursa1 has joined #riscv
hendursaga has quit [Ping timeout: 276 seconds]
frost has joined #riscv
frost has quit [Changing host]
frost has quit [Quit: Connection closed]
frost has joined #riscv
aburgess has joined #riscv
kgz has quit [Ping timeout: 260 seconds]
mithro has quit [Ping timeout: 245 seconds]
freakazoid343 has joined #riscv
mithro has joined #riscv
dermato has quit [Ping timeout: 252 seconds]
dermato has joined #riscv
freakazoid12345 has quit [Ping timeout: 265 seconds]
<Jmabsd>
davidlt: oh awesome you're back! would you mind checking idle watt consumption next few days?
<Jmabsd>
davidlt: 1.4Ghz is safe for the Unmatched isn't it
<Jmabsd>
minimalist is cool
<kaddkaka[m]>
What are the rules on a riscv assembler? For example, how should the `lui` instruction be expressed? Is it `lui x8, 0xfffff000` or `lui x8, 0xfffff`? Is `lui x8, -1` allowed?
<kaddkaka[m]>
I haven't been to find any clear documentation about this.
<kaddkaka[m]>
* haven't been able to find
jack_lsw has quit [Read error: Connection reset by peer]
<jimwilson>
kaddkaka[m], 4-1058 does not fit in c.beqz offset field, try c.beqz x8,.+4 if you want to branch to the current address plus 4, but better to use a label
jacklsw has quit [Quit: Back to the real life]
<jimwilson>
kaddkaka[m], the arg to branches is an address not an offset
EchelonX has quit [Quit: Leaving]
freakazoid12345 has quit [Remote host closed the connection]
freakazoid12345 has joined #riscv
compscipunk has joined #riscv
brettgilio has quit [Quit: Leaving...]
brettgilio has joined #riscv
gbrlwck has quit [Quit: Client closed]
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #riscv
[itchyjunk] has quit [Read error: Connection reset by peer]
Andre_H has joined #riscv
freakazoid343 has joined #riscv
freakazoid12345 has quit [Ping timeout: 268 seconds]
freakazoid12345 has joined #riscv
freakazoid343 has quit [Ping timeout: 268 seconds]
vagrantc has joined #riscv
freakazoid333 has joined #riscv
freakazoid12345 has quit [Ping timeout: 258 seconds]
adjtm_ has joined #riscv
adjtm has quit [Remote host closed the connection]
davidlt has joined #riscv
Bluefoxicy has joined #riscv
Jmabsd has quit [Ping timeout: 260 seconds]
BOKALDO has quit [Quit: Leaving]
radu242407 has joined #riscv
radu242407 has quit [Ping timeout: 260 seconds]
davidlt has quit [Ping timeout: 260 seconds]
smartin has quit [Quit: smartin]
<KombuchaKip>
What is the right way to programmatically set a breakpoint on riscv64? I've tried asm volatile("cbreak");, which halts execution properly in gdb, but you can't step to the next instruction after that. You can manually update the program counter register, but that's cumbersome.
Andre_H has quit [Ping timeout: 260 seconds]
<KombuchaKip>
I am aware of using raise() or kill(), but I need to be able to create a macro via #define that does this without requiring an external #include - hence needing the asm.
Andre_H has joined #riscv
<jrtc27>
how is that situation any different to other architectures?
<jrtc27>
it's not like there's a magic breakpoint() function you can call on other architectures
<muurkha>
sure, that's what the 8086 INT3 opcode 0xCC is for
<muurkha>
but most commonly your debugger inserts it dynamically and then patches it out in order to continue
<geist>
yah i think cbreak is what you want, you can just bump the pc forward 2 and you're set
<geist>
if you want some sort of hardware that compares the PC and traps without modifying the code that's a different story
<muurkha>
but "self halt." is a pretty common thing to type in Smalltalk for example
freakazoid343 has joined #riscv
freakazoid333 has quit [Ping timeout: 265 seconds]
<KombuchaKip>
jrtc27: On mips it's "teq $0, $0". POWER it's "twge %r2, %r2". On x86 it's "int $0x03". On arm64 it's "brk #0", etc. You roll that into a macro and it works. On riscv64 gdb will stop at the "cbreak" instruction, but you can't step over it.
<jrtc27>
(c.)break is the equivalent
<jrtc27>
architecturally they are all the same thing
<jrtc27>
an instruction that always traps
<jrtc27>
how software responds to that trap is purely up to that software
<jrtc27>
so go file a bug with gdb and/or the linux kernel if it's being inconsistent with other architectures
avoidr has quit [Ping timeout: 258 seconds]
radu242407 has joined #riscv
<KombuchaKip>
jrtc27: cbreak isn't the equivalent, as I just indicated. It's not clear that it's a bug in gdb either, but it might be worth opening an issue.
<jrtc27>
at the hardware level it is
<jrtc27>
it is entirely up to software how the generated trap is interpreted
<KombuchaKip>
jrtc27: Not really.
<jrtc27>
yes, yes it is
<KombuchaKip>
jrtc27: No, it's not actually. But thanks.
<muurkha>
KombuchaKip: oh awesome, I didnt know about mips and power
<muurkha>
or arm
freakazoid343 has quit [Remote host closed the connection]
freakazoid343 has joined #riscv
<muurkha>
I feel like probably if your kernel (or debugger, if standalone) returns control to the instruction that always traps on MIPS, POWER, or arm64, it will probably trap again
<muurkha>
for 8086 I'm sure of it
<KombuchaKip>
muurkha: Yeah, it's a useful trick to be able to programmatically set a breakpoint. It's sometimes faster than trying to find in gdb's man page how to conditionally set one in some very specific situation and then not being sure if it actually understood correctly what you were trying to do.
<muurkha>
yeah, I know why it's useful; I explained above that people do it often in Smalltalk too
<muurkha>
it's also handy for programming in the debugger, but nobody does that nowadays
<muurkha>
I'm guessing that either the debugger or the kernel has a hack to advance the instruction pointer on those architectures
* KombuchaKip
nods
<muurkha>
or, I guess, the CPU could invoke the trap handler with the following PC instead of with the PC pointing to the trapping instruction
<muurkha>
but in that case the kernel or debugger would have to step it backwards in the case where you had fixed the problem from the debugger and wanted to retry
<muurkha>
because normally just running the code after an instruction that faulted is not what you want to do except for, like, missing instruction emulation
<muurkha>
so I think that what jrtc27 said about it not being the responsibility of the hardware makes sense
<jrtc27>
for system calls, architectures vary on whether PC points to the system call instruction or the next instruction to execute
<muurkha>
(actually I think you can resume after the 8086 INT3 breakpoint with just a RETI, but you usually don't want to because you usually overwrote some other instruction with the INT3)
<jrtc27>
riscv takes a purist philosophy and always sets it to the current PC, treating ecall just like any other trapping instruction
<jrtc27>
aarch64 has brk set elr to pc, but svc sets elr to pc+4
<jrtc27>
which saves software the trouble, at a tiny bit of architectural edge-casing
<muurkha>
stepping forward is a lot easier than stepping backward with most variable-length instruction encodings
<jrtc27>
yep
radu242407 has quit [Ping timeout: 260 seconds]
rlittl01 has quit [Quit: -a- Connection Timed Out]
rlittl01 has joined #riscv
freakazoid12345 has joined #riscv
freakazoid343 has quit [Ping timeout: 258 seconds]
winterflaw has quit [Remote host closed the connection]
jwillikers has quit [Remote host closed the connection]
winterflaw has joined #riscv
rlittl01 has quit [Quit: -a- Connection Timed Out]
rlittl01 has joined #riscv
Andre_H has quit [Ping timeout: 258 seconds]
<jimwilson>
I don't believe the cbreak/gdb problem is a gdb bug. It is a trap, not a breakpoint. MIPS has an arg, and defines one arg value to be a breakpoint. But riscv break doesn't take an arg so we can't do that.
<jrtc27>
if you want just a trap there's unimp, break is clearly primarily for software breakpoints
<muurkha>
so the debugger and/or OS should be reconfigured to advance the PC before resuming, right?
Gravis has quit [Ping timeout: 268 seconds]
freakazoid343 has joined #riscv
<jrtc27>
and yes it might generate a trap as the means to redirect control to a handler, but its cause code is literally called Breakpoint in the spec
<muurkha>
I mean, if the handler handed control to the debugger, then resuming the same instruction that is going to go right back into the debugger is kind of pointless
<muurkha>
unless there's no kernel and the software is in RAM so your debugger sets breakpoints by patching cbreak instructions into the code, which seems like it's not a very common thing in the last quarter century, even if it was normal 40 years ago
freakazoid12345 has quit [Ping timeout: 265 seconds]
<muurkha>
maybe I don't understand all the issues
[itchyjunk] has joined #riscv
freakazoid12345 has joined #riscv
freakazoid343 has quit [Ping timeout: 265 seconds]
hendursaga has joined #riscv
freakazoid12345 has quit [Read error: Connection reset by peer]
winterflaw has quit [Ping timeout: 276 seconds]
freakazoid12345 has joined #riscv
freakazoid343 has joined #riscv
pecastro has quit [Ping timeout: 260 seconds]
<jrtc27>
muurkha: gdb already knows about ebreaks it inserted and will fix those up appropriately
<jrtc27>
this is just ones that it didn't insert itself
freakazoid12345 has quit [Ping timeout: 265 seconds]
<muurkha>
right, of course
<muurkha>
I have't actually looked at how gdb sets breakpoints with ebreak