| 9 Apr 2026 |
 dramforever | * at least just let me pass CROSS_COMPILE=riscv64-unknown-linux-gnu- or whatever it is | 15:05:09 |
| dramforever | oh i knew i did this https://mastodon.social/@dramforever/114787497271979789 | 15:06:42 |
| dramforever | having said that, i wonder if you can "just" add unknown as a kernel type | 15:10:53 |
| dramforever | apparently yes, you can just patch nixpkgs like this https://fars.ee/gAvi and use (import <nixpkgs> { crossSystem.config = "riscv64-unknown-elf"; }).stdenvNoLibc.cc | 15:15:13 |
| dramforever | stdenv.cc doesn't work because we "obviously" don't have a libc for the "unknown" operating system | 15:16:23 |
 Alex | I wouldn't expect it to work for none OS either, though? | 15:17:09 |
| dramforever | so... | 15:24:42 |
| dramforever | on the none os we use newlib | 15:24:46 |
| 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 |
