23 Sep 2025 |
outfoxxed | made it to stage1 by manually loading everything, extlinux still won't | 09:17:41 |
outfoxxed |  Download image.png | 09:17:42 |
| kenji changed their display name from a-kenji to kenji. | 10:37:26 |
Alex | In reply to @outfoxxed:outfoxxed.me I've also copied the init binary in the nix store to /init in the rootfs, though I don't know if the kernel is trying to load from there or initrd The kernel always tries to load binaries in the initramfs (or initrd).
After that, userspace can do whatever it wants.
Typically, that means mounting the rootfs and execing the rootfs' init program.
If you don't see NixOS' "Stage 1" prompt, then it's likely failing to load the initramfs' init program. | 12:36:08 |
Alex | In reply to @outfoxxed:outfoxxed.me Continuing from last night in the main room here https://matrix.to/#/#users:nixos.org/$9PGx1smm5r8lM79J9wKW3uiI3zyGLogHe7d0t9DOjn0, I'm attempting to get a milkv jupiter booting. So far I've made it here with an sdcard image:
[ 2.094640] Warning: unable to open an initial console.
[ 2.108202] Freeing unused kernel image (initmem) memory: 11332K
[ 2.118470] Checked W+X mappings: passed, no W+X pages found
[ 2.121250] Run /init as init process
[ 2.124855] with arguments:
[ 2.127799] /init
[ 2.130048] with environment:
[ 2.133182] HOME=/
[ 2.135523] TERM=linux
[ 2.252879] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[ 2.257607] CPU: 1 PID: 1 Comm: init Not tainted 6.6.63 #1-NixOS
[ 2.263589] Hardware name: Milk-V(M1) Jupiter (DT)
[ 2.268364] Call Trace:
[ 2.270797] [<ffffffff800070f2>] dump_backtrace+0x28/0x30
[ 2.276177] [<ffffffff811e6ac6>] show_stack+0x38/0x44
[ 2.281211] [<ffffffff8120863e>] dump_stack_lvl+0x44/0x5c
[ 2.286593] [<ffffffff8120866e>] dump_stack+0x18/0x20
[ 2.291627] [<ffffffff811e6dbc>] panic+0x11a/0x302
[ 2.296401] [<ffffffff80026b2e>] do_exit+0x930/0x936
[ 2.301349] [<ffffffff80026cd6>] do_group_exit+0x30/0x80
[ 2.306644] [<ffffffff80026d4a>] __wake_up_parent+0x0/0x2c
[ 2.312114] [<ffffffff81209318>] do_trap_ecall_u+0x12a/0x13e
[ 2.317756] [<ffffffff8121575c>] ret_from_exception+0x0/0x64
[ 2.323404] SMP: stopping secondary CPUs
[ 2.327332] Kernel Offset: 0x0 from 0xffffffff80000000
[ 2.332431] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 ]---
with the commandline:
[ 0.000000] Kernel command line: earlycon=sbi console=ttyS0,115200n8 loglevel=8 swiotlb=65536 init=/nix/store/yqr77mh0018a3ln6m57qks91vv0ms1dq-nixos-system-jupiter-sd-card-25.11pre-git/init debug lsm=landlock,yama,bpf boot.debugtrace
and I'm not sure where to go from here, because it doesn't seem to be starting init (or I'm just getting no logs, I see nothing about ttyS0 actually coming online) IIRC both initramfs and rootfs use systemd as the init program. In my experience, systemd is very picky of what state it expects the system to be in and doesn't touch the stdout or stderr provided by the kernel even if it can't/hasn't set up logging yet. Maybe there is an option or environment variable to make it less stupid? See if you can get ahold of any logs recorded by journald? | 12:41:14 |
25 Sep 2025 |
dramforever | @outfoxxed:outfoxxed.me: https://gist.github.com/cyyself/a07096e6e99c949ed13f8fa16d884402#off-topic-strange-pxa-uart | 20:44:28 |
dramforever |
A simple work around can be turn on CONFIG_RISCV_SBI_V01, CONFIG_NONPORTABLE and CONFIG_HVC_RISCV_SBI, then use console=hvc0 so we will have a pulling based uart for debugging purpose.
| 20:44:46 |
dramforever | i'm not entirely sure what the vendor kernel has | 20:45:18 |
dramforever | but it should have the sbi stuff and hvc_riscv_sbi | 20:45:33 |
outfoxxed | I've seen pxa-uart in dmesg before at least | 20:45:46 |
dramforever | and maybe also earlycon_sbi, but i forgot what that's called | 20:45:46 |
dramforever | yeah but remember "unable to open an initial console"? | 20:46:10 |
dramforever | i think this is why init isn't printing anything before dying | 20:46:22 |
outfoxxed | yeah I've been ignoring those issues and booting with booti + bootargs | 20:46:25 |
outfoxxed | which does work for some reason | 20:46:34 |
dramforever | do you get "unable to open an initial console" with booti+bootargs? | 20:46:50 |
outfoxxed | nope | 20:46:57 |
dramforever | oh, hmm | 20:47:11 |
outfoxxed | I've managed to boot to a full wayland environment at this point | 20:47:12 |
dramforever | ah | 20:47:20 |
dramforever | then i don't see why you think it's a miscompile? | 20:47:42 |
outfoxxed | because if i add v to the isa section we'll ge a panic or pid1 death | 20:48:13 |
outfoxxed | *isa string | 20:48:17 |
outfoxxed | Currently I have this set in nixpkgs config
gcc.arch = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zfhmin_zkt_zba_zbb_zbc_zbs_zbkc_zvfh_zvfhmin_zvkt";
#gcc.arch = "rv64imafdc_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zfhmin_zkt_zba_zbb_zbc_zbs_zbkc";
| 20:48:41 |
outfoxxed | * Currently I have this set in nixpkgs config
#gcc.arch = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zfhmin_zkt_zba_zbb_zbc_zbs_zbkc_zvfh_zvfhmin_zvkt";
gcc.arch = "rv64imafdc_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zfhmin_zkt_zba_zbb_zbc_zbs_zbkc";
| 20:48:55 |
outfoxxed | I wanted to sort the gcc flags out while the set of packages I'm compiling to test with is as small as possible | 20:49:31 |
dramforever | oh, yeah, i didn't expect seeing tweaking gcc.arch | 20:51:09 |
outfoxxed | I figured I'd iron that out first because I don't want to fix it later and spend 2 days recompiling the world | 20:51:36 |
outfoxxed | was also trying to pass -misa-spec=2.2 but withCFlags seemed to break php somehow | 20:51:58 |
outfoxxed | a lot of packages need -fPIC as well, which I've been manually overriding for each one at this point | 20:52:30 |