Re: qemu-system-alpha (was: Re: [Qemu-devel] [PATCH] Fix extlh instruction on Alpha)

[Rob Landley]

On Monday 21 September 2009 08:31:49 Brian Wheeler wrote:
> On Sun, 2009-09-20 at 21:20 -0500, Rob Landley wrote:
> > On Thursday 17 September 2009 14:28:52 Vince Weaver wrote:
> > > The extlh instruction on Alpha currently doesn't work properly.
> > > It's a combination of a cut/paste bug (16 where it should be 32) as
> > > well as a "shift by 64" bug.
> > >
> > > This improves on an earlier patch that used labels, conditional jumps,
> > > and local variables.  Thanks go especially to Aurelien Jarno and
> > > Andreas Schwab who have a much better eye for bit-wise TCG optimization
> > > than I do.
> > >
> > > Vince
> >
> > Any idea how hard it would be to whip up a qemu-system-alpha emulation? 
> > I note that several real-world alpha boards were essentially just a PC
> > with a different processor.
>
> Yep.  The ES40 used the ALI1543 chipset and was pretty pc-ish is most
> respects.  There were a couple of DEC specific chips on board (such as
> an IOMMU).
>
> But the hardware isn't the real problem, I don't think.  I think the
> real problems (for QEMU, at least) are the PAL and SRM.
>
> The PAL adds several os-specific pseudo-instructions to the instruction
> set.  MILO has a linux palcode, but no other open source ones are
> available that I know of.  Without VMS or Tru64 Palcode you're limited
> to linux.  I think the BSDs use the Tru64 Palcode.  I suppose its
> possible to have the palcode routines hard-coded into qemu, though you'd
> need several sets of them (one for each supported OS type)

What I'd really like to use is the -kernel option to boot Linux.

I have a project (http://impactlinux.com/fwl) that's trying to build a simple 
uclibc/busybox Linux system image for each qemu-system target, plus a native 
compiler (gcc,binutils,make,bash), and then using distcc to call out to the 
host's cross compiler through the virtual network to speed up native builds 
without all the other complexity of cross compiling (lying to ./configure in 
three dozen different ways while keeping two different toolchains with their 
own 
sets of headers and libraries from leaking into each other).

It's also a fun way to do nightly regression tests of busybox, uClibc, and the 
linux kernel on various different targets, so things like 2.6.30's mips bug or 
the current sh4 weirdness in 2.6.31 get caught early enough that the 
developers remember what changed.

It boots a kernel via -kernel and feeds in a root filesystem as /dev/hda or 
/dev/sda (or initramfs in a pinch, but that seldom gives you enough space 11 
megabytes of compressed toolchain before the memory mappings go "boing" during 
initramfs extract).  The way I'm booting uses a serial console, emulated hard 
drive (ide or scsi), emulated network card, 256 megs of ram, and optionally a 
battery-backed clock (I can fake it with rdate if the network card works, make 
gets really unhappy otherwise), the processor emulation in question, and a 
kernel configured to boot on that particular qemu setup.

So far I've got ppc, arm, mips, sh4, x86, x86-64, and a very buggy sparc 
booting to a shell prompt, and all of 'em except sparc can build and run 
"hello world" natively.  (uClibc's sparc support is not happy, hopefully 
current -git sucks less.)

I whipped up an Alpha config back when I started the project, but there's never 
been a way to test it, so it got lost.  Similar with m68k and cris.  (Last I 
checked the emulated cris boards were toys with a fixed small amount of memory, 
no hard drive, no way to add a network card, and I don't remember if they even 
emulated a battery-backed clock.)

> There doesn't seem to be an open source SRM which can be used to boot
> the machine and provide the initial user interface.  MILO also performs
> this function, but its hard to build and pretty old.
>
> I believe that charon axp solves this problem by having their own
> mini-implementation of the srm (and presumably the PAL) which only
> supports setting/viewing the environment and booting.  The real SRM has
> lots of features that aren't really needed on emulated hardware.

Reminds me of the nightmare getting openbios/openhackware on ppc to feed in a 
coherent device tree.  I just want enough setup to make -kernel work, but 
that's often nontrivial. :(

> > I'd like to boot Alpha Linux on qemu, and it doesn't seem like there's
> > _that_ much more to do.  But last I asked (a couple years ago) I was told
> > the Alpha protected mode stuff wasn't implemented yet...
>
> There were patches last year for an es40, but they never made it to the
> main tree...and weren't quite finished.

I'm happy to test (and document) something that almost works.  But if it 
doesn't almost work, I'm unlikely to be much help. :(

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds