Re: [Qemu-devel] Open Hack'Ware 0.4 release candidate

[J. Mayer]

On Tue, 2005-03-22 at 23:27 +0000, Natalia Portillo wrote:
[...]
> > It seems BeFS is not well documented. There was a BeFS project for 
> > Linux
> > but it seems that it has been stopped (no activity for a few years) and
> > was never integrated into standard kernels.
> > If BeBox is just a PREP machine, the first step to emulate it would be
> > to try to boot the BeOS kernel using Qemu PREP target with -kernel
> > argument.
> > Then, we may don't need any BeFS emulation to start it.
> Uh, as far as I know the BeFS filesystem for Linux is in the kernel ^o)

Damned, you're right !

> You can download a fully explanation of the BeFS from Dominic 
> Giampaolo's webpage (the designer of BeFS).

Yes, but this documentation says "this book does not contain exhaustive
bit-level details of BFS". But it may be sufficient to have a read-only
implementation...

> Also the OpenBeOS project has a working filesystem driver (at least 
> readonly)
> 
> Without that in OHW or a BeOS/PPC compatible machine I'm not able to 
> extract the kernel (the drivers I said are for little endian BeFS and 
> not for big endian one)

I guess there's some other way to extract the kernel, but I must make
some tests in order to be sure of this...

> >> I think NT should boot with only the support for the executable 
> >> format,
> >> at least to a point that shows anything interesting on screen (surely 
> >> a
> >> big blue screen of death xD).
> >
> > Well, I'd have to merge the code I got for NT XCOFF loading, then and
> > retry...
> Say me
> 
> >> MorphOS SHOULD work if we mix the qemu's PC emulation with OHW and
> >> PowerPC cpu, as Pegasos is a standard PC motherboard with an OF clone
> >> and a PowerPC G3/G4 chip.
> >
> > Then, it's exactly what a PREP board is...
> > So, a few modifications from PREP target (mostly base addresses, I
> > guess) should be OK.
> The qemu prep emulation currently emulates the serial controller?
> Remember that we debugged the mos kernel and find that it was trying to 
> access a non implemented command in the rs232 controller

Qemu PREP emulates all the basic devices of a PREP machine, including
serial drivers. But Pegasos IO seem to be completely different, as far
as I remember. Then, a way of guessing where the device are would be:
1/ copy hw/ppc_prep.c into hw/ppc_pegasos.c, modify hw/ppc.c and vl.c to
recognize "pegasos" board type
2/ Display all IO and memory accesses out of known ranges.
3/ Launch the kernel and try to guess what it tries to do when accessing
devices.
I did guess it tries to probe a serial port and enter an infinite loop
when it does not find it.

-- 
J. Mayer <address@hidden>
Never organized