Re: Running m68k on qemu with external initramfs?

[John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>]

On 4/12/20 2:48 PM, Rob Landley wrote:
> Install debian to a block device to see why initramfs isn't working?

d-i uses a ramdisk so I assume that should be similar to what you are
using.

> I already downloaded and ran
> http://landley.net/aboriginal/downloads/binaries/system-image-m68k.tar.gz to
> make sure laurent's tip of tree qemu-m68k is working, and that booted to a shell
> prompt fine, but that's using a static initramfs instead of an external once,
> which is why I thought that was the issue. (It used to be back when I first made
> that work, which was something like 2014.)

Not sure I understand what your particular configuration is but I have never
run into issues with an initramfs and the root filesystem in RAM on m68k,
native or with qemu.

> I also ran my toybox binary under qemu-m68k to smoketest that the compiler was
> making binaries that ran, but it turns out that I had two problems:
> 
> 1) I'd run "make defconfig in the wrong directory and toybox switched the shell
> back off (because it's still in "pending" until I finish it), hence the not
> finding init. I stuck enough printk(KERN_ERR) into init/initramfs.c to list all
> the filenames it was extracting and figured that one out.
> 
> 2) THEN the problem was that gcc is doing something in cd_main so that the
> "chdir ." at the start of the shell setup (to set $PWD and friends) is
> segfaulting, but it's a segfault that went away when I got near it with printf()
> calls, and even write(1, "", 0); right before it made it go away. Given that
> this code has run on 32 and 64 bit, big and little endian, glibc musl and
> bionic, and on a target that's both nommu and cares about alignment?
> 
> Someday I might build gdb for m68k, but until then I should check it next time I
> upgrade compiler versions. (Or go through disabling every optimization one by
> one until I find the one that's making the registers go nuts the way sh4 had
> that https://landley.net/notes-2020.html#29-01-2020 thing.)
> 
> Rob
> 
> P.S: For context, I built a musl-cross-make toolchain and symlinked it into
> toybox, and then used "make root CROSS=m68k LINUX=~/linux" to build a system:
> 
> git clone https://github.com/landley/musl-cross-make
> git clone https://github.com/landley/toybox
> cd musl-cross-make
> sed -Ei 's/(BINUTILS_VER =).*/\1 2.32/;s/(LINUX_VER =).*/\1 4.19.90/' Makefile
> ../toybox/scripts/mcm-buildall.sh i686:: m68k::
> cd ../toybox
> ln -s ccc ../musl-cross-make/ccc
> make root CROSS=i686 LINUX=~/linux
> make root CROSS=m68k LINUX=~/linux
> 
> If you (cd root/i686; ./qemu-*.sh) it boots to a shell prompt.... well, if you
> KARGS=rdinit=/bin/sh it does, running the init script still says:
> 
> ln: cannot create symbolic link from '/proc/self/fdi/,*/}' to 'dev/i/*,/}': No y
> ln: cannot create symbolic link from '/proc/self/fdi/,*/}' to 'dev/i/*,/}': No y
> ln: cannot create symbolic link from '/proc/self/fdi/,*/}' to 'dev/i/*,/}': No y
> ln: cannot create symbolic link from '/proc/self/fdi/,*/}' to 'dev/i/*,/}': No y
> sh: exec /etc/rc/*: No such file or directory
> Type exit when done.
> oneit: /dev/CONSOLE:-console}: No such file or directory
> 
> Because I'm still halfway through teaching toysh about all the ${} constructs.
> (Also, remind me to stick echo -e '\e[?7h' at the start of my init script to
> undo the STUPID wordwrap disable escape that qemu's bios outputs, which screws
> up bash's command line history too!)
> 
> Anyway, at least it's known behavior. But in root/m68k I'm getting:
> 
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> CPU: 0 PID: 1 Comm: init Not tainted 5.6.0 #1
> Stack from 0f81bdfc:

So, do I understand correctly that this is buildroot with musl?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913