On 4/12/20 12:29 AM, Finn Thain wrote:
It sounds more like a "modify kernel .config" problem. But it could be a
regression; what versions of qemu and kernel did you try?
"Works for me", got it. I'll keep digging.
If you want to try a kernel binary that works for me, so as to narrow down
the problem, you can get one from here:
https://sourceforge.net/projects/linux-mac68k/files/
You have 4.1 and 4.14 kernels. The last one I had in my old build system (which
works but was uClibc based using gcc 4.2.1) was 4.3:
http://landley.net/aboriginal/downloads/binaries/system-image-m68k.tar.gz
But that was a static initramfs, not an external intitramfs.
QEMU is the one Laurent Vivier maintains that's been out of tree for
something like 12 years now, the default branch claims to be "q800-dev"
and the last commit was in december.
Should be fine. For the last few months I've used mainline QEMU instead.
Oh cool. (My last qemu build apparently just predated the merge, and hadn't had it.)
That works for me, with a few tweaks:
qemu-system-m68k -M q800 -serial none -serial mon:stdio -nographic
-no-reboot -m 256 -kernel vmlinux-4.14.167-mac-backport+
-initrd sysroot.cpio.gz -append console=ttyS0
Yeah, it's looking like it's something about my userspace build. (A problem
which is unique to m68k because all the other targets are working. Sigh.)
I'll keep digging...
And this makes the segfault go away:
--- a/toys/pending/sh.c
+++ b/toys/pending/sh.c
@@ -2575,7 +2588,7 @@ void cd_main(void)
if (to-dd>1 && to[-1]=='/') to--;
*to = 0;
}
-
+write(1, "", 0);
if (bad || chdir(dd)) perror_msg("chdir '%s'", dd);
else {
if (pwd) {
So that's reassuring. I should run it under gdb to see what the segfault that
heisenbugs acutally _is_ but given it doesn't show up on any other architecture
(32 or 64 bit, big or little endian, sh4 cares about alignment, and I've built
it under glibc musl and bionic), I'm going to throw m68k back on the todo heap
for now.
Rob
