[Qemu-devel] powerpc system emulation and the need for ppc-rom.bin (firmware)

[Qemu-devel] powerpc system emulation and the need for ppc-rom.bin (firmware)

[Martin]

Jocelyn mentioned some time ago that powerpc (system)emulation could be 
broken at the moment because there are some majore changes in progress.
At the moment it does build just fine only it is not usable because it 
thinks it needs a powerpc rom bios (firmware)
This loading is done in hw/ppc_prep.c (and hw/ppc_chrp.c)
up and until revision 1.10 of ppc_prep.c the loading was done in the 
else part of if(linux_boot)
In other words, if you load a linux kernel directly you don't need 
ppc_rom.bin

from version 1.11 and on qemu always tries to load ppc_rom.bin (and 
always fails because it is not there: "could not load PPC PREP bios 
'/usr/local/share/qemu/ppc_rom.bin'")

Is there a special reason for this?
Otherwise I would suggest moving it back in the else clause so we can 
still use recent cvs snapshots (with new features and bugfixes like pci 
support)
It would of course also be great if a (working) ppc_rom firmware would 
be available.
How is the progress on this going?
Jocelyn, what are you using at the moment, an existing firmware for a 
real device or an opensource openfirmware implementation?

I also found that there is a new commandline option -prep
I think this chooses between prep and chrp emulation.
How different are the two emulations at the moment?

Greetings,
Martin


hw/ppc_prep.c
Revision: 1.10

if (linux_boot) {
/* Do stuff to load linux kernel */
} else
{
/* allocate and load BIOS ppc_rom.bin */
}

hw/ppc_prep.c
Revision: 1.11, Wed May 26 22:53:03 2004 UTC (2 weeks ago) by bellard

/* allocate and load BIOS ppc_rom.bin */
if (linux_boot) {
/* Do stuff to load linux kernel */
}

Re: [Qemu-devel] powerpc system emulation and the need for ppc-rom.bin (firmware)

[J. Mayer]

On Thu, 2004-06-10 at 23:04, Martin wrote:
> Jocelyn mentioned some time ago that powerpc (system)emulation could be 
> broken at the moment because there are some majore changes in progress.

Me ? It's being a long time I didn't post here... I think Fabrice said
this...

> At the moment it does build just fine only it is not usable because it 
> thinks it needs a powerpc rom bios (firmware)

I didn't notice that Fabrice didn't commit the BIOS image. I'll ask him
to do it, if he still have a version which can boot the PREP target with
the current CVS code.
My work version can't (I'm focusing on Mac emulation).

> This loading is done in hw/ppc_prep.c (and hw/ppc_chrp.c)
> up and until revision 1.10 of ppc_prep.c the loading was done in the 
> else part of if(linux_boot)
> In other words, if you load a linux kernel directly you don't need 
> ppc_rom.bin
> 
> from version 1.11 and on qemu always tries to load ppc_rom.bin (and 
> always fails because it is not there: "could not load PPC PREP bios 
> '/usr/local/share/qemu/ppc_rom.bin'")
> 
> Is there a special reason for this?

I think the linux_boot case has been broken for a long time for the PPC
target. The next working versions will always need a BIOS, like i386
target does, to probe and initialize some hardware, then load and start
a boot image from disk or memory. The memory image is just another boot
device, seen from BIOS side.

> Otherwise I would suggest moving it back in the else clause so we can 
> still use recent cvs snapshots (with new features and bugfixes like pci 
> support)
> It would of course also be great if a (working) ppc_rom firmware would 
> be available.
> How is the progress on this going?
> Jocelyn, what are you using at the moment, an existing firmware for a 
> real device or an opensource openfirmware implementation?

I'm currently hacking a BIOS I wrote last year in order to boot Linux.
At this time, it was completely host-sided. I ported it to be PPC
native. I'm currently working on PCI integration and dynamic OF tree
updates.
It's not a real Open-Firmware as it knows nothing about Forth but can
"emulate" the standard OF and RTAS interfaces. It can also handle some
known requests from MacOS and friends (calls to "interpret" method): the
needed results are hardcoded in C.
It also can be used as a conventional firmware, with no OF support
(which is optional for PREP).

> I also found that there is a new commandline option -prep
> I think this chooses between prep and chrp emulation.
> How different are the two emulations at the moment?

Some Mac devices have been included (I think) in the repository by
Fabrice (cuda, ADB, PCI for PREP). I also added Open-Pic and I'm
currently trying to get a configuration near mac99 machines,
implementing BIOS support at the same time.
Chrp is just Mac, for now... RS6000, and others could come later if some
ones really want it :-)

I hope I'll be able to send patches and a new functional BIOS with PCI
support to Fabrice in a few days so the real work (ie debugging...) will
start.

-- 
J. Mayer <l_indien@magic.fr>
Never organized