| 9 Apr 2026 |
 Alex | That doesn't sound ideal to me, unless there's perhaps a way of building a custom stdenv without newlib even entiring the build closure (maybe via replaceStdenv?) | 15:26:41 |
| Alex | Anyway, that is purely theoretical, since nobody right now is asking about bare metal dev. | 15:27:14 |
 dramforever | riscv64-unknown-elf is without a doubt baremetal dev | 15:28:17 |
| Alex | Arguably, the behaviour Nixpkgs does on none should perhaps instead be for OS newlib, but maybe there's already precedent for this in other package repositories? | 15:31:19 |
| 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 |
