gehen Sie bitte mit, hier ist Nix zu sehen
Tue, 02 Jan 2018 12:08:23 +0000
[ Meta: I don't actually speak German. I hope the pun works, but I have no particular reason to suppose it should do. ]
Happy New Year, if you observe the Gregorian Calendar. This week in NixWRT was typified by lots of beating head on brick wall followed by an unexpected achievement: I have a working rootfs in qemu!
Look, isn't it cool?
[nix-shell:~/src/nixwrt]$ qemu-system-mipsel -M malta -m 64 -nographic -kernel linux-*/vmlinux -append 'root=/dev/sr0 console=ttyS0 init=/bin/sh' -blockdev d river=file,node-name=squashed,read-only=on,filename=tftproot/rootfs.image -block dev driver=raw,node-name=rootfs,file=squashed,read-only=on -device ide-cd,drive= rootfs -nographic Linux version 4.14.1 (dan@loaclhost) (gcc version 6.4.0 (GCC)) #2 SMP Tue Jan 2 14:58:10 UTC 2018 [...] BusyBox v1.27.2 () built-in shell (ash)
# LD_TRACE_LOADED_OBJECTS=1 /nix/store/*-rsync*/bin/rsync --version linux-vdso.so.1 (0x77cc8000) libpopt.so.0 => /nix/store/79ffdcjvk5bpbm1vgrxii935vhjbdg5p-popt-1.16-mi psel-unknown-linux-gnu/lib/libpopt.so.0 (0x77c70000) libc.so.6 => /nix/store/7njknf9mhcj7jd3l0axlq8ql0x7396pk-glibc-2.26-75-m ipsel-unknown-linux-gnu-mipsel-unknown-linux-gnu/lib/libc.so.6 (0x77ad4000) /nix/store/7njknf9mhcj7jd3l0axlq8ql0x7396pk-glibc-2.26-75-mipsel-unknown -linux-gnu-mipsel-unknown-linux-gnu/lib/ld.so.1 (0x77c98000)
Points of note here:
- I fixed the stupid-huge image size I talked about last week
by removing dontStrip in
. Although I don't know if this is correct, it Seems To Work. My
hypothesis is that the derivation was previously running an x86 strip
on target (in this case, MIPS) binaries and trashing them, and so
dontStripwas added to stop it doing that. Now it's using a
stripthat understands MIPS, so it can be re-enabled. Is my guess.
mksquashfsis super fussy about trailing slashes on filenames when you use the
-root-becomesoption to regraft directories. For best results, don't use any
(-> head wall)
I spent a lot of time, with no actual result yet, on getting the Yun to tftp its kernel and rootfs and run them in-place without having to write anything to flash. Motivation here is: it's not my Yun, it belongs to my employer who will probably want it back next time we do a hackathon or something. So I don't want to brick the device accidentally, nor use all the flash erase cycles, and anyway it's probably slower than running from RAM.
This is my theory which almost works but for some reason not quite: we
should be able to tftp the root fs into RAM then use the MTD "phram"
driver to emulate an MTD device at that address, and the
option to hide that region of memory from the Linux system (so it
doesn't overwrite it)
ar7240> setenv kernaddr 0x81000000 ar7240> setenv rootaddr 1178000 ar7240> setenv rootaddr_useg 0x$rootaddr ar7240> setenv rootaddr_ks0 0x8$rootaddr ar7240> setenv bootargs keep_bootcon console=ttyATH0,250000 panic=10 oops=panic init=/bin/sh phram.phram=rootfs,$rootaddr_ks0,9Mi root=/dev/mtdblock0 memmap=10M\$$rootaddr_useg ar7240> setenv bootn "tftp $kernaddr /tftp/kernel.image ; tftp $rootaddr_ks0 /tftp/rootfs.image; bootm $kernaddr" ar7240> run bootn
Here's where it gets weird. With those options, it rus most of the
way through boot then hangs after printing
NET: Registered protocol
family 17 (that's netlink, if you were wondering). If I misspell the
console device name, though, it gets slightly further. wat?
NET: Registered protocol family 17 Warning: unable to open an initial console. VFS: Mounted root (squashfs filesystem) readonly on device 31:0. Freeing unused kernel memory: 208K This architecture does not have kernel memory protection. Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
So it's identified that there is a squashfs filesystem there, which is a positive sign, but it's not going to run init without a console.
Also falling into the "known unknowns" quadrant: you will note that we randomly set and unset the high bit on some of our addresses there: this is because the same physical RAM is mapped into more than one place in the MIPS address space and I sort of think I have a handle on how it works but not really.
[ Postemporaneous edit: the next thrilling installment in this series is now up at https://ww.telent.net/2018/1/7/baud_games ]