| 9 Apr 2026 |
 dramforever | i think newlib is precedent but i don't know why | 15:32:57 |
 GenericNerdyUsername | the "official" riscv toolchain for baremetal is github:riscv-collab/riscv-gnu-toolchain so everything that touches baremetal (like riscv-arch-test, which is what im trying to run) expects you to have that one specifically and nothing else | 20:37:41 |
| GenericNerdyUsername | in general, yes i agree with you, but most of what this is used for is assembly so the problem isnt as big of an issue | 20:38:57 |
| 10 Apr 2026 |
| dramforever | either they don't support anything other than riscv-gnu-toolchain, which means woes for you trying to run this on nixpkgs cross toolchain, probably just patch it | 00:36:00 |
| dramforever | or they've hard coded the compiler name, i.e. doing it wrong | 00:36:16 |
| dramforever | of course i haven't checked so maybe it actually is overridable solving the problem for everyone | 00:36:40 |
 Alyssa Ross | I don't know off the top of my head. I remember support for bare metal platforms in general in Nixpkgs being pretty broken, but that was a few years ago, so maybe it got better. | 09:08:26 |
 cleverca22 | ive done a decent amount of baremetal with nixpkgs
for risc-v, i was mostly building nommu linux and userland
for arm, i was building custom kernels (32bit and 64bit), and also linux and userlands
and ive also built custom kernels for the VPU, which first required adding a new target to nixpkgs | 12:16:23 |
| GenericNerdyUsername | That reminds me, what extensions do the normal riscv linux toolchains assume the processor has? | 12:32:37 |
| cleverca22 | i dont know about userland side, but i have looked into the kernel side of things
linux basically assumes no extensions at boot time, and the CONFIG_ flags enable support for them, but dont enable actually using them
if the relevant flag is detected in the device-tree, it will patch its own code at runtime, to turn the feature on | 12:36:15 |
| cleverca22 | the reason ive looked into this, is because patching the code, requires the code to be r/w, which conflicts with XIP (where the kernel is in a ROM)
XIP risc-v requires an MMU, so it can copy the changes to ram and map them overtop the ROM
except, i wanted XIP linux on a risc-v nommu, which linux just doesnt support! | 12:37:20 |
| GenericNerdyUsername | Could you set the checks to constants at compile time? | 12:38:20 |
 Alex | In reply to @genericnerdyusername:matrix.org
That reminds me, what extensions do the normal riscv linux toolchains assume the processor has? IMACDF_Zicsr_Zifencei | 12:38:28 |
| cleverca22 | last i checked, linux doesnt support that, it always assumes the lack of a feature, and the CONFIG_ just enables support for it
enabling the usage happens at runtime | 12:38:54 |
| cleverca22 | its burried in the alternates macros | 12:39:32 |
| GenericNerdyUsername | Probably would break if you had something that implemented the misa and had no mmu | 12:39:39 |
| GenericNerdyUsername | But thats so esoteric that i think youd have bigger problems | 12:39:51 |
| cleverca22 | arch/riscv/kernel/entry.S: ALTERNATIVE("sfence.vma", "nop", 0, RISCV_ISA_EXT_SVVPTC, 1)
| 12:40:29 |
| GenericNerdyUsername | How much effort would it be to remove the DF requirement or do them in software? | 12:40:32 |
| cleverca22 | basically, this macro will generate 2 different opcodes, and update a table with the address, so other code can patch things at bootup | 12:40:52 |
| Alex | In reply to @genericnerdyusername:matrix.org
How much effort would it be to remove the DF requirement or do them in software? It's not a requirement, just what most toolchains assume.
I think you could probably get away with I_Zicsr for a simple single-core bare metal program.
It would entirely depend on what program you're looking to run. | 12:42:11 |
| cleverca22 | arch/riscv/lib/strcmp.S: __ALTERNATIVE_CFG("nop", "j strcmp_zbb", 0, RISCV_ISA_EXT_ZBB,
IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && IS_ENABLED(CONFIG_TOOLCHAIN_HAS_ZBB))
in this case, it can either be a nop where it falls thru to a non-zbb implementation
or a jump to the zbb implementation
| 12:42:31 |
| cleverca22 | it defaults to the nop case i believe | 12:42:42 |
| GenericNerdyUsername | The end goal is booting a minimal nixos install and running some neofetch derivative | 12:42:57 |
| Alex | In reply to @genericnerdyusername:matrix.org
The end goal is booting a minimal nixos install and running some neofetch derivative You can try different ISAs by setting gcc.arch.
My suggestion: try IMA_Zicsr_Zifencei (you might not need to specify the Zi instructions with GCC) | 12:44:10 |
| GenericNerdyUsername | Set that where? | 12:45:26 |
| cleverca22 | arch/riscv/include/asm/alternative-macros.h
reading more, i can see it will generate the first opcode, nop, and force it to not be compressed (so both options are 32bits)
then it will use an assembly .if statement gated on the config flag, to maybe push the 2nd opcode into the .alternative section of the binary, along with some offsets to the nop | 12:45:26 |
| cleverca22 | oh, but i also see things now gated by CONFIG_RISCV_ALTERNATIVE, hmmmm? | 12:49:04 |
| cleverca22 | ah, when CONFIG_RISCV_ALTERNATIVE=n it just doesnt support the extensions at all, and always goes with the non-zbb case (in the strcmp example) | 12:49:51 |
| cleverca22 | https://github.com/torvalds/linux/blob/master/arch/riscv/Kconfig#L542-L555 | 12:51:54 |
