[Aboriginal] what fork should I use to get q800-capable qemu-m68k?

[Rob Landley]

On 12/20/2015 07:53 AM, Warren Postma wrote:
> Because my tastes run towards antiquity, when I found out about
> aboriginal linux, I of course wanted to try the oldest  and weirdest
> port you had.   Nobody has gotten Linux running on an emulated PDP-11
> yet, have they? 
> 
> The  m68k q800 emulator appears from the mailing list archive to be a
> simulation of the last of the 68030 macintosh systems, so that's the
> first one I downloaded, natch.   Back in the day, my sympathies were
> with the 680x0 Amigas, but that's close enough.
> 
> Google, salva nos inscius, lead me to
> https://github.com/vivier/qemu-m68k/wiki which hath  branch 680x0-v2.3.0

Hmmm,
http://landley.net/hg/aboriginal/file/2c312362813d/sources/targets/m68k
is still pointing at gitorious, which went down. I forgot to update that
link. :)

You want https://github.com/vivier/qemu-m68k and specifically the q800
branches, ala q800-v2.4.0

I would love to see this go upstream into qemu, but repeated poking has
not helped it happen.

> I have never built qemu from sources, so I found this ask
> ubuntu-question to get me past the DTC lib issue, I manually grabbed the
> tarball and unzipped into the /dtc/ folder...
> 
> http://askubuntu.com/questions/424329/error-trying-to-compile-qemu-from-source

Blah, I had to do this recently. It detects you don't have libtool and
disables that, then insists on me manually installing libz-dev and
libglib2.0-dev with apt-get (after working out the non-redhat names for
both), then configure dies with subrepo installs but the git init
suprepo thingy line it suggests does work if you cut and paste it. That
does dtc and pixman.

After that configure completes, but then the _build_ dies because I
didn't have either autoconf or automake installed. I think once I
installed that it actually started working?

> After that ./configure complains about broken libtool,

Missing libtool. Specifically, libtool exists to make non-elf systems
behave like elf. Linux switched from a.out to elf in 1996, almost 20
years ago, so libtool has nothing to do on linux. Yet the FSF keeps
insisting on using it because they think it's "proper" to have a NOP shim.

It breaks cross compiles if you do install it. It won't stay out of the
way, and _tries_ to do stuff it shouldn't. Failure to do nothing
correctly is a trademark of the Free Software Foundation.

> but completes.
> make got in a fair way, and the compile breaks while building
> aarch64-linux-user.

That's new, I hadn't seen it. Try checking out a release version?

> I am too much of a noob to figure out what to
> configure out to make this go away or if aarch64-linux-user is some
> basic part of this qemu build:

Nah: ./configure --target-list=m68k-softmmu

> /home/wpostma/qemu-m68k/linux-user/syscall.c: In function
> ‘host_to_target_data_link_rtattr’:
> /home/wpostma/qemu-m68k/linux-user/syscall.c:1513:10: error:
> ‘IFLA_LINK_NETNSID’ undeclared (first use in this function)
>      case IFLA_LINK_NETNSID:
>           ^
> /home/wpostma/qemu-m68k/linux-user/syscall.c:1513:10: note: each
> undeclared identifier is reported only once for each function it appears in
> /home/wpostma/qemu-m68k/rules.mak:57: recipe for target
> 'linux-user/syscall.o' failed
> make[1]: *** [linux-user/syscall.o] Error 1
> Makefile:173: recipe for target 'subdir-aarch64-linux-user' failed
> make: *** [subdir-aarch64-linux-user] Error 2

This is why checking out the repo snapshot du jour as your first
experience with a project is seldom a good idea.

https://patchwork.ozlabs.org/patch/430969/

This was added to the kernel in january of this year, current qemu won't
build against ubuntu LTS. Bravo qemu devs, bravo.

> Just judging from the folder name, linux-user, this appears to be a part
> of the userland application-emulation features in qemu itself.

There are two modes in qemu, system emulation and user emulation. User
emulation runs an elf binary and translates system calls. System
emulation runs a kernel and translates hardware access.

Of the two, system emulation works a lot better because it's got a much
narrower and more well-defined interface to the outside world to handle.
Reading from some sysfs file and trying to translate the contents, "this
ioctl takes this structure and this field has different offset and
alignment and endianness and that's before we even get to its MEANING on
a different type of hardware..."

> The line that breaks is an undefined identifier, so I commented it out,
> it's a "case
> IFLA_LINK_NETNSID:" inside a large list of cases. 
> 
> After that I get stuck here, which I have no idea how to fix:

Those are qemu questions, but first I'd try to build a release version,
then I'd try to build laurent's q800-v2.4.0 branch.

> Has anyone built an m68k q800 capable qemu on Ubuntu?

Yes but it was the old 2.3.0 branch.

> Are there any
> more tricks? Could I just turn off some element of the qemu build and
> get the qemu cpu-emulator up without any userland emulation?

Yes, in "./configure --target-list=m68k-softmmu" the "softmmu" means
system emulation (possibly hardmmu was kvm but they don't use that
anymore, now it's a command line option for softmmu).

> I'm
> guessing this syscall mechanism is actually central to qemu +
> aboriginal-linux functionality as it's probably how I/O occurs inside
> the emulator.

No, it's the user mode system call translation. System emulation doesn't
use it, it runs a kernel that handles its own system calls and then
hardware access is what's translated.

It's pretty easy to fake a serial port or an old-style IDE controller.
You can configure a kernel to use easily emulated hardware.
("Paravirtualization" means inventing new pretend hardware that's even
more easily emulated, and writing drivers in your guest kernel for the
emulator instead of actual silicon. But since it's often big iron guys
like IBM and Red Hat behind that, the user interface tends to be
craptacular so I wouldn't bother with that.)

Rob