[mkroot] Status triage.

[Rob Landley]

It's coming up on time for another release (past time, two new kernel
versions have come out an there's an -rc3 on a third), so where did I
leave off...

Here's how to test target status:

1) ls output

This gives you the target list. You can skip the .failed targets, they
didn't build properly. (You can also ./run.sh without arguments to see
just the successfully built targets.)

2) ./run.sh $TARGET -hda log.txt

This runs the specified $TARGET image up qemu, with the file "log.txt"
(present in all builds under the same name) attached to the first
virtual hard drive.

If it doesn't give you a shell prompt, you may have to killall

3) date; ifconfig; tail /dev/?da; exit

Those four commands should A) give you a current date, B) show a network
card with an IP address, C) show the tail end of the kernel build
messages, D) exit qemu an give your host shell prompt back. If it can do
all four of those things, we've passed our basic smoke test.

By those metrics, the armv5l, armv7l, i486, i686, mips, mipsel, powerpc,
s390x, an x86_64 targets fully work.

The aarch64 target hasn't got a working disk or network card. I was
pretty sure I had that target fully working, but it isn't now. Need to
figure out what bit-rotted.

The powerpc64 target hangs when you try to launch it, the kernel and
qemu don't agree on the emulation. (Separate problem: it thinks it
should run qemu-system-ppc instead of qemu-system-ppc64. I should fix
that.) I've gotten boot messages out of one boar using (of all things)
the mac99 emulation, but I'm pretty sure that's the serial port being
where it looks for it more or less by coincidence. The boot hangs before
it can finish extracting initramfs and launch init, possibly the memory
map on the mac99 board doesn't agree with the kernel config. (I'd like
to avoid a full openbios machine becuase it takes SO LONG for that bios
to finish playing with itself and get on with launching the kernel.)

The sh4 target has 4 problems: 1) The serial problem is still there (it
only notices input when the 16 char UART input buffer fills up, there's
no timeout; this is due to qemu and linux's serial hardware support
diverging last year), 2) no battery backed up clock in the r2d board
emulation (missing feature?), 3) only 64 megs of ram in the r2d board
emulation, 4) no disk. (I've gotten the disk to work before, need to
figure out what's wrong there.) Really, we need a better board emulation
in qemu for this target. (What would be involved in sticking a full sh4
into the j-core soc? :)

Five targets (armv7m, armv7r, mips64, microblaze, and sh2eb) fail to
build because of a missing kernel config. I _think_ all provide working
userspace, but not working kernel/qemu? Haven't tested them properly yet.

For the nommu arm systems it's because we don't have a matching vanilla
kernel config and qemu board emulation for them. The sh2eb system can
run under an sh4 kernel, but that has to build with an sh4 toolchain.
(It's sort of an i386 vs i686 or armv5l vs armv7l thing. Really this is
also "lack of qemu support", there's just a known workaround that the
mkroot infrastructure doesn't have a special case for. We always build
an entire target, kernel an userspace, with one toolchain. That's part
of how we're simple.)

The microblaze target has something funky with... floating point maybe?
It can't run toybox, segfaults trying. Toolchain and runtime environment
have conflicting expectations, I need to track that down. There's also
the problem that nommu microblaze and with-mmu microblaze don't have
obviously distinguishable short names, so I can't currently support
both. (That's a todo item. Hmmm, possibly all the nommu targets should
have a -nommu suffix? armv7m-nommu?)

The mips64 target had a toolchain bug in musl-libc, which got fixed
upstream. Unfortunately musl hasn't had a release in a while, an
musl-cross-make hasn't _ever_ had a release. I need to poke rich about
that. (I can update my local toolchain build, but I've wanted to get
actually release binaries to test against and that's been blocked
forever by Rich and myself both being really busy.)

Before next release I should really get aarch64 fully working, and
probably mips64. And maybe fix microblaze.

The sh2eb target presents a design issue: it's not a qemu target, it's a
real hardware (mimas v2 or turtle) target. As with nommu, I haven't
quite come up with a way to distinguish them yet. Design todo item.

Rob