<clever>
sorear: my understanding, is that this will assemble to a nop, and if CONFIG_RISCV_ISA_ZBB=y is set, AND the device-tree advertises zbb support, the kernel will rewrite the nop into a `j strlen_zbb` at boot
<sorear>
my understanding is that is correct
<clever>
but now you have a nop of overhead in the non-zbb case, including if you set CONFIG_RISCV_ISA_ZBB=n
<clever>
why not move the first opcode, on line 23, into that macro?
<clever>
then the CONFIG_RISCV_ISA_ZBB=n case, is as-if you never had zbb support in the first place
<sorear>
slightly more complicated
<sorear>
worse consistency with aarch64, where you would ideally limit patch points to use the subset of instructions that can be asynchronously modified from other cores without triggering undefined behavior (which includes nops, jumps, a few esoteric instructions, and not much else)
<clever>
ah, so if you patch it mid execution, it doesnt malfunction too much
<clever>
at least for this strlen case, i cant see any way it could malfunction if you modify it during execution?
rsjw has quit [Ping timeout: 240 seconds]
<sorear>
the formal memory model is completely silent about and doesn't constrain fetch behavior, but you could have instruction fetches be torn depending on alignment, or some exceptional condition require emulation in M-mode/hypervsior but the instruction has changed in the meantime
<clever>
sorear: but i thought all opcodes are 32bits in size, and 32bit aligned (assuming no compressed extensions)
<clever>
so with a 32bit bus, you cant have a torn write
<clever>
but if your running on an 8bit bus for some reason.......
<sorear>
I normally assume people are using the compressed extension
<clever>
compressed means 16bit opcodes right? so a given 32bit write would overwrite 2 opcodes
<clever>
and you may want some read/modify/write behavior
<clever>
but you still have the same problem
<clever>
whats to say that changing a nop into a j wont tear?
<clever>
why is nop savfe and mv not?
<sorear>
it isn't; to be safe you have to stop all other cores before text patching, which I'm pretty sure the alternatives system does
<sorear>
but aarch64 has "Concurrent modification and execution of instructions can lead to the resulting instruction performing any behavior that can be achieved by executing any sequence of instructions that can be executed from the same Exception level, except where each of the instruction before modification and the instruction after modification is one of a B, BL, BRK, HVC, ISB, NOP, SMC, or SVC instruction" (0487F.c §B2.2.5)
<clever>
that kind of sounds like aarch64 is doing i-fetch and i-decode several times?
<clever>
and it can malfunction and dream up any opcode if the data changes under its feet?
<sorear>
rva20 has "Ziccif Main memory regions with both the cacheability and coherence PMAs must support instruction fetch, and any instruction fetches of naturally aligned power-of-2 sizes up to min(ILEN,XLEN) (i.e., 32 bits for RVA20) are atomic." " Ziccif is a new extension name capturing this feature. The fetch atomicity requirement facilitates runtime patching of aligned instructions. " which is not quite enough
<sorear>
basically, yes
<clever>
but certain opcodes like nop and branch, are simple enough that they dont need a second stage of decoding
<sorear>
think about how many times a load or store is fetched and decoded if it's misaligned and maybe also page faults
<clever>
so it only sees the before or after
<sorear>
arm has given themselves a lot of latitude to do that
rsjw has joined #riscv
<clever>
last i saw, arm and riscv both require the opcodes to be aligned to the size of the opcode
<sorear>
and they've clearly erred on the side of "we don't need to emulate this NOW, but we also don't clearly need it for patching so allow it to be emulated in the future"
<sorear>
32-bit instructions on riscv + C and arm32/thumb only require 16-bit alignment not 32-bit
<clever>
oh, i see why, because a 16bit compressed opcode would mis-align things, and you dont want to pad out the next 32bit opcode
<clever>
my view is tainted, by looking at a non-c core, so that cant happen
<clever>
but when mixing 16bit and 32bit opcodes, 32bit alignment becomes a problem for the wide ones
<sorear>
i think the only non-c core you can actually buy is the VEGA board
<clever>
in my case, i'm working with a rv32ima emulator
<clever>
i now have virtio block, input and network working, and just today i fixed wfi to sleep for longer then 500uSec
BootLayer has joined #riscv
EchelonX has joined #riscv
jacklsw has joined #riscv
damian101 has joined #riscv
damian101 has quit [Ping timeout: 240 seconds]
EchelonX has quit [Quit: Leaving]
unlord has quit [Ping timeout: 260 seconds]
Nixkernal_ has joined #riscv
Nixkernal has quit [Ping timeout: 272 seconds]
unlord has joined #riscv
zjason`` is now known as zjason
damian101 has joined #riscv
damian101 has quit [Remote host closed the connection]
loki_val has joined #riscv
crabbedhaloablut has quit [Ping timeout: 264 seconds]
BootLayer has quit [Quit: Leaving]
mlw has joined #riscv
alexghiti has joined #riscv
jfsimon1981_c has quit [Remote host closed the connection]
jfsimon1981_c has joined #riscv
jfsimon1981_c has quit [Remote host closed the connection]
alperak has joined #riscv
jfsimon1981_c has joined #riscv
<drmpeg>
Linux 6.10.0-rc1 is not working at all on Unmatched. Doesn't get past "Starting kernel ..."
ldevulder has joined #riscv
paddymahoney has quit [Ping timeout: 240 seconds]
paddymahoney has joined #riscv
ldevulder has quit [Quit: Leaving]
danilogondolfo has joined #riscv
<mps>
uncompressing kernel fail maybe?
<drmpeg>
Maybe. There was a change with that.
stolen has joined #riscv
jfsimon1981_c has quit [Remote host closed the connection]
jfsimon1981_c has joined #riscv
bjoto has quit [Remote host closed the connection]
loki_val has quit [Ping timeout: 256 seconds]
crabbedhaloablut has joined #riscv
<mps>
iirc I saw something about in git log
<Esmil>
drmpeg: if you're using something like make install, tar-pkg or bindeb-pkg and not using EFI_ZBOOT=y then you need to set CONFIG_KERNEL_UNCOMPRESSED=y to use the uncompressed arch/riscv/boot/Image
<drmpeg>
Yup, I'm using bindeb-pkg.
<drmpeg>
I'll give it a try.
<Esmil>
(if you're booting using EFI anyway, i'd recommend trying EFI_ZBOOT though ;)
mlw has quit [Quit: Lost terminal]
mlw has joined #riscv
<conchuod>
There's been a report of a broken clock driver on the sifive stuff
ntwk has quit [Read error: Connection reset by peer]
<drmpeg>
It's the clock driver.
ntwk has joined #riscv
pecastro has joined #riscv
wingsorc has quit [Ping timeout: 256 seconds]
eightthree has quit [Ping timeout: 264 seconds]
eightthree has joined #riscv
jacklsw has quit [Ping timeout: 240 seconds]
<drmpeg>
Esmil: CONFIG_KERNEL_GZIP gets set with oldefconfig, so the old behavior is preserved.
<Esmil>
drmpeg: except with CONFIG_KERNEL_GZIP=y now targets like make install, tar-pkg and bindeb-pkg will actually use arch/riscv/boot/Image.gz as the vmlinuz installed
<drmpeg>
I'm pretty sure it was doing that before.
<drmpeg>
At least with bindeb-pkg.
<Esmil>
i don't think bindeb-pkg did that fx. scripts/package/builddeb is using whatever make -s image_name says, which is the value of $(KBUILD_IMAGE) that was always set to arch/riscv/boot/Image before
<Esmil>
you can use file /boot/vmlinuz-.. to figure out if it's "gzip compressed data" or an uncompressed "PE32+ executable"
<drmpeg>
They all say "gzip compressed data, max compression, from Unix, original size modulo 2^32 ..."
<Esmil>
interesting. i have no idea how that happens then. i'm pretty sure make -s image_name always said just arch/riscv/boot/Image before
chripo has quit [Remote host closed the connection]
Andre_Z has joined #riscv
chripo has joined #riscv
chripo is now known as Guest434
<drmpeg>
Just another mystery.
<Esmil>
Ah no, sorry. It was the other way around. make -s image_name would always say Image.gz, but make install would then change it to the uncompressed Image
jfsimon1981_c has quit [Remote host closed the connection]
jfsimon1981_c has joined #riscv
ntwk has quit [Ping timeout: 255 seconds]
damian101 has joined #riscv
jfsimon1981_c has quit [Remote host closed the connection]
jfsimon1981_c has joined #riscv
ntwk has joined #riscv
haritz has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
haritz has joined #riscv
haritz has quit [Changing host]
haritz has joined #riscv
unlord has quit [Changing host]
unlord has joined #riscv
jacklsw has joined #riscv
mlw has quit [Ping timeout: 240 seconds]
mlw has joined #riscv
jacklsw has quit [Ping timeout: 264 seconds]
ntwk has quit [Ping timeout: 240 seconds]
jfsimon1981_c has quit [Remote host closed the connection]
jfsimon1981_c has joined #riscv
<conchuod>
smaeul: Could you look at the sifive prci issue <ZlSJkCtx6eYPCQwG@shell.armlinux.org.uk>? I figure that you'll be running into it yourself soon enough.
ntwk has joined #riscv
s3 has joined #riscv
ntwk has quit [Quit: ntwk]
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
jfsimon1981_c has quit [Remote host closed the connection]
jfsimon1981_c has joined #riscv
psydroid has quit [Read error: Connection reset by peer]
BootLayer has joined #riscv
mlw has quit [Ping timeout: 264 seconds]
psydroid has joined #riscv
mlw has joined #riscv
vagrantc has joined #riscv
stolen has quit [Quit: Connection closed for inactivity]
jfsimon1981_c has quit [Remote host closed the connection]
heat has joined #riscv
stolen has joined #riscv
Andre_Z has quit [Quit: Leaving.]
khem has quit [Quit: WeeChat 4.2.2]
khem has joined #riscv
alperak has quit [Quit: Connection closed for inactivity]
scrts0 has quit [Ping timeout: 240 seconds]
damian101 has quit [Ping timeout: 255 seconds]
alexghiti has quit [Ping timeout: 268 seconds]
alexghiti has joined #riscv
BootLayer has quit [Quit: Leaving]
mlw has quit [Ping timeout: 268 seconds]
LangerJan has joined #riscv
<LangerJan>
Hi! Beginner's question: Why is the immediate field of JAL (page 16 von riscv-spec 2.2 pdf) twirled the way it is? bit 20 is the MSB of the instruction, bit 12 is the LSB of the immediate part, why is that?
<courmisch>
makes it easier to share decoding hardware with other instructions
<courmisch>
for software, not so much
vagrantc has quit [Quit: leaving]
<LangerJan>
courmisch: thanks! I struggle with the document a little bit. It says that this is a J-Type instruction, and I can see that. But "Preface to Version 2.0" says it would move JAL to the U-Type Format. What am I missing?
alexghiti has quit [Ping timeout: 256 seconds]
<courmisch>
J and U formats are the same, except for the reshuffling of the immediate
<LangerJan>
yeah, and it seems that the authors changed their minds past 2.0 again