[Qemu-devel] qemu/pc-bios ppc_rom.bin

[Qemu-devel] qemu/pc-bios ppc_rom.bin

[Jocelyn Mayer]

CVSROOT:	/sources/qemu
Module name:	qemu
Changes by:	Jocelyn Mayer <j_mayer>	07/10/01 06:44:33

Modified files:
	pc-bios        : ppc_rom.bin 

Log message:
	Quickly hack PowerPC BIOS able to boot on CDROM again.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/ppc_rom.bin?cvsroot=qemu&rev=1.7

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Avi Kivity]

Jocelyn Mayer wrote:
> CVSROOT:	/sources/qemu
> Module name:	qemu
> Changes by:	Jocelyn Mayer <j_mayer>	07/10/01 06:44:33
>
> Modified files:
> 	pc-bios        : ppc_rom.bin 
>
> Log message:
> 	Quickly hack PowerPC BIOS able to boot on CDROM again.
>
> CVSWeb URLs:
> http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/ppc_rom.bin?cvsroot=qemu&rev=1.7
>
>
>   

There really should be a pointer to the sources used to generate this. 
Ideally the full sources.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Bob Deblier]

On Mon, 2007-10-01 at 09:05 +0200, Avi Kivity wrote:
> Jocelyn Mayer wrote:
> > CVSROOT:	/sources/qemu
> > Module name:	qemu
> > Changes by:	Jocelyn Mayer <j_mayer>	07/10/01 06:44:33
> >
> > Modified files:
> > 	pc-bios        : ppc_rom.bin 
> >
> > Log message:
> > 	Quickly hack PowerPC BIOS able to boot on CDROM again.
> >
> > CVSWeb URLs:
> > http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/ppc_rom.bin?cvsroot=qemu&rev=1.7
> >
> >
> >   
> 
> There really should be a pointer to the sources used to generate this. 
> Ideally the full sources.

Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
working on this?

Sincerely,

Bob Deblier

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Aurelien Jarno]

Bob Deblier a écrit :
> On Mon, 2007-10-01 at 09:05 +0200, Avi Kivity wrote:
>> Jocelyn Mayer wrote:
>>> CVSROOT:	/sources/qemu
>>> Module name:	qemu
>>> Changes by:	Jocelyn Mayer <j_mayer>	07/10/01 06:44:33
>>>
>>> Modified files:
>>> 	pc-bios        : ppc_rom.bin 
>>>
>>> Log message:
>>> 	Quickly hack PowerPC BIOS able to boot on CDROM again.
>>>
>>> CVSWeb URLs:
>>> http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/ppc_rom.bin?cvsroot=qemu&rev=1.7
>>>
>>>
>>>   
>> There really should be a pointer to the sources used to generate this. 
>> Ideally the full sources.
> 
> Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> working on this?
> 

I have given a quick look, enough to know that's it is not just a matter
of compiling the current PowerPC code and feed it to QEMU. The way
OpenBIOS, OpenHackware and PearPC are too different.

Unfortunately I won't have time to work further on this before roughly 2
months.

Cheers,
Aurelien

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Bob Deblier]

On Mon, 2007-10-01 at 13:40 +0200, Aurelien Jarno wrote:
> Bob Deblier a écrit :
> > On Mon, 2007-10-01 at 09:05 +0200, Avi Kivity wrote:
> >> Jocelyn Mayer wrote:
> >>> CVSROOT:	/sources/qemu
> >>> Module name:	qemu
> >>> Changes by:	Jocelyn Mayer <j_mayer>	07/10/01 06:44:33
> >>>
> >>> Modified files:
> >>> 	pc-bios        : ppc_rom.bin 
> >>>
> >>> Log message:
> >>> 	Quickly hack PowerPC BIOS able to boot on CDROM again.
> >>>
> >>> CVSWeb URLs:
> >>> http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/ppc_rom.bin?cvsroot=qemu&rev=1.7
> >>>
> >>>
> >>>   
> >> There really should be a pointer to the sources used to generate this. 
> >> Ideally the full sources.
> > 
> > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > working on this?
> > 
> 
> I have given a quick look, enough to know that's it is not just a matter
> of compiling the current PowerPC code and feed it to QEMU. The way
> OpenBIOS, OpenHackware and PearPC are too different.
> 
> Unfortunately I won't have time to work further on this before roughly 2
> months.
> 
> Cheers,
> Aurelien

Okay - I'm perfectly willing to start and/or help working on this. My
question was just to avoid duplicating work.

Thanks,

Bob

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Andreas Färber]

Am 01.10.2007 um 09:12 schrieb Bob Deblier:

> Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> working on this?

I had looked into this recently but it turned out that PearPC and  
others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is  
incompatible with QEMU, expecting some raw image. I have no idea how  
to go about this; the (working) sparc version uses some "weird"  
assembler initializations. ;-)

Me too, I believe that OpenBIOS would be a better long-term solution.  
Maybe OHW can be merged into OpenBIOS for not having to start from zero?

Andreas

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Blue Swirl]

On 10/1/07, Andreas Färber <andreas.faerber@web.de> wrote:
>
> Am 01.10.2007 um 09:12 schrieb Bob Deblier:
>
> > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > working on this?
>
> I had looked into this recently but it turned out that PearPC and
> others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> incompatible with QEMU, expecting some raw image. I have no idea how
> to go about this; the (working) sparc version uses some "weird"
> assembler initializations. ;-)

You can use:
objcopy -O binary in.elf out.bin

Alternatively, Qemu could be enhanced to try loading ELF first and
binary if that fails.

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Jocelyn Mayer]

On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
> On 10/1/07, Andreas Färber <andreas.faerber@web.de> wrote:
> >
> > Am 01.10.2007 um 09:12 schrieb Bob Deblier:
> >
> > > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > > working on this?
> >
> > I had looked into this recently but it turned out that PearPC and
> > others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> > incompatible with QEMU, expecting some raw image. I have no idea how
> > to go about this; the (working) sparc version uses some "weird"
> > assembler initializations. ;-)
> 
> You can use:
> objcopy -O binary in.elf out.bin
> 
> Alternatively, Qemu could be enhanced to try loading ELF first and
> binary if that fails.

This is even not an option. With "normal" full system emulation, Qemu
boots like real hardware does. I don't know any CPU able to load ELF
images. As the goal is to emulate real hardware, what is to be given is
a ROM image, able to boot a real machine.
You can try to ehance the -kernel option to do weird hacks if you like
but the CPU state at the start of a normal boot process should be as
near as possible as a real CPU after a hard reset. Any other behavior is
a bug to fix asap.
Imho Qemu can be a very great development tool (and I already used it
for this purpose), not just a geek toy, then hacks that do not reflect
what real hardware does have to be avoided any time it's possible. Then,
adding an ELF loader in the CPU initialisation code seems to be a
nonsense. The goal to achieve, imho, is to be able to run real ROM
images extracted from real machine, not to "extend" the CPU features
with stuffs that has no reality (and are even not useful as long as no
machine would never accept to boot on this "firmware").

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Blue Swirl]

On 10/1/07, Jocelyn Mayer <l_indien@magic.fr> wrote:
> On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
> > On 10/1/07, Andreas Färber <andreas.faerber@web.de> wrote:
> > >
> > > Am 01.10.2007 um 09:12 schrieb Bob Deblier:
> > >
> > > > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > > > working on this?
> > >
> > > I had looked into this recently but it turned out that PearPC and
> > > others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> > > incompatible with QEMU, expecting some raw image. I have no idea how
> > > to go about this; the (working) sparc version uses some "weird"
> > > assembler initializations. ;-)
> >
> > You can use:
> > objcopy -O binary in.elf out.bin
> >
> > Alternatively, Qemu could be enhanced to try loading ELF first and
> > binary if that fails.
>
> This is even not an option. With "normal" full system emulation, Qemu
> boots like real hardware does. I don't know any CPU able to load ELF
> images. As the goal is to emulate real hardware, what is to be given is
> a ROM image, able to boot a real machine.

The effect is exactly the same from the emulated CPU perspective. With
ELF image we gain symbols in the out_asm dump.

> You can try to ehance the -kernel option to do weird hacks if you like
> but the CPU state at the start of a normal boot process should be as
> near as possible as a real CPU after a hard reset. Any other behavior is
> a bug to fix asap.
> Imho Qemu can be a very great development tool (and I already used it
> for this purpose), not just a geek toy, then hacks that do not reflect
> what real hardware does have to be avoided any time it's possible. Then,
> adding an ELF loader in the CPU initialisation code seems to be a
> nonsense. The goal to achieve, imho, is to be able to run real ROM
> images extracted from real machine, not to "extend" the CPU features
> with stuffs that has no reality (and are even not useful as long as no
> machine would never accept to boot on this "firmware").

Qemu is not limited to just hardware emulation. Please consider for
example snapshot load/save support, built-in gdbstub and monitor. No
real hardware has any of these, or perhaps you could do similar things
with ICE or JTAG.

Qemu is not also aimed for 100% accurate emulation of the hardware.
There are no caches or cycle counters and hardware devices run
unrealistically fast from CPU standpoint. Emulating performance
counters or the errata the most CPUs have would be extremely
difficult. I doubt Qemu CPU emulation can ever pass POST of real
BIOSes. Real BIOSes are also closed source, proprietary binary blobs.
Making open source BIOSes a viable alternative is in my opinion a much
more important goal.

Maybe there is some misunderstanding, the change amounts to this:

     bios_offset = ram_size + vga_ram_size;
     snprintf(buf, sizeof(buf), "%s/%s", bios_dir, BIOS_FILENAME);
-    bios_size = load_image(buf, phys_ram_base + bios_offset);
+    bios_size = load_elf(buf, 0, NULL, NULL, NULL);
+    if (bios_size < 0)
+        bios_size = load_image(buf, phys_ram_base + bios_offset);
     if (bios_size < 0 || bios_size > BIOS_SIZE) {
         cpu_abort(env, "qemu: could not load PPC PREP bios '%s'\n", buf);

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Jocelyn Mayer]

On Mon, 2007-10-01 at 19:36 +0300, Blue Swirl wrote:
> On 10/1/07, Jocelyn Mayer <l_indien@magic.fr> wrote:
> > On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
> > > On 10/1/07, Andreas Färber <andreas.faerber@web.de> wrote:
> > > >
> > > > Am 01.10.2007 um 09:12 schrieb Bob Deblier:
> > > >
> > > > > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > > > > working on this?
> > > >
> > > > I had looked into this recently but it turned out that PearPC and
> > > > others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> > > > incompatible with QEMU, expecting some raw image. I have no idea how
> > > > to go about this; the (working) sparc version uses some "weird"
> > > > assembler initializations. ;-)
> > >
> > > You can use:
> > > objcopy -O binary in.elf out.bin
> > >
> > > Alternatively, Qemu could be enhanced to try loading ELF first and
> > > binary if that fails.
> >
> > This is even not an option. With "normal" full system emulation, Qemu
> > boots like real hardware does. I don't know any CPU able to load ELF
> > images. As the goal is to emulate real hardware, what is to be given is
> > a ROM image, able to boot a real machine.
> 
> The effect is exactly the same from the emulated CPU perspective. With
> ELF image we gain symbols in the out_asm dump.
> 
> > You can try to ehance the -kernel option to do weird hacks if you like
> > but the CPU state at the start of a normal boot process should be as
> > near as possible as a real CPU after a hard reset. Any other behavior is
> > a bug to fix asap.
> > Imho Qemu can be a very great development tool (and I already used it
> > for this purpose), not just a geek toy, then hacks that do not reflect
> > what real hardware does have to be avoided any time it's possible. Then,
> > adding an ELF loader in the CPU initialisation code seems to be a
> > nonsense. The goal to achieve, imho, is to be able to run real ROM
> > images extracted from real machine, not to "extend" the CPU features
> > with stuffs that has no reality (and are even not useful as long as no
> > machine would never accept to boot on this "firmware").
> 
> Qemu is not limited to just hardware emulation. Please consider for
> example snapshot load/save support, built-in gdbstub and monitor. No
> real hardware has any of these, or perhaps you could do similar things
> with ICE or JTAG.

gdbstub and monitor like features are available with (usually)
proprietary debug tools on most hardwares I know. Most of the
development environment have many more features than Qemu currently
implements. It would be really great if Qemu would be able to become a
tool that could replace all those proprietary tools, but we are really
very far from this point.
I've never seen snapshot and load/store features on real hardware but it
seems to be doable with available debug tools. I did things quite like
that with JTAG scripts sometimes (CPU, RAM and a few simple devices
initialisation, cause I would have been to lazy to do more !).
But I also have to admit those are features I never use in Qemu...

> Qemu is not also aimed for 100% accurate emulation of the hardware.
> There are no caches or cycle counters and hardware devices run
> unrealistically fast from CPU standpoint. Emulating performance
> counters or the errata the most CPUs have would be extremely
> difficult.

I never said that it's a full accurate emulation. I just said 'the
closest as possible to the real machine'. Which means from the execution
context point of view it has to have the same behavior, not that we
emulate every internal hardware states. Having other behaviors that are
not present on the real hardware can be fun but it gives nothing in
terms of emulation.

>  I doubt Qemu CPU emulation can ever pass POST of real
> BIOSes.

This is an admission of failure...

>From my point of view, it's a requirement that Qemu would be able:
1/ to be used to develop new firmwares and systems
2/ to be as accurate as needed so a firmware developped under Qemu would
run without modification on real hardware (means, takes the binary
image, flash it and power on, it runs...)
3/ would be able to run proprietary firmware, especially when trying to
emulate some targets with non-documented "blackboxes" that cannot be
easily reimplemented in OSS firmwares due to a lack of documentation, or
to "discover" hardware on which it's not easy to find any available OSS
distribution.

As an example, my goal, while implementing PowerPC 4xx targets, is to
take raw binary proprietary flash images from misc vendors and (try to)
run them without modification. For now, I'm able to run one of those.
Each other one I would be able to run would proove the emulation is
getting more accurate and is going to become really usable for any
usage.
It's even almost the only way I have to do it because there are
currently not a single complete OSS environment which I can get from the
net and boot at once for validation.
But Qemu may also be a great chance to make people that cannot afford
having real development board go and develop for embedded targets (I
hope so !).

>  Real BIOSes are also closed source, proprietary binary blobs.
> Making open source BIOSes a viable alternative is in my opinion a much
> more important goal.

I fully agree with that point of view. Then, validating open sources
firmwares means that you have to run the exact same image on your
emulated machine than the one you want to run on the real hardware. Or
you won't validate anything. Then, build your flash image and run, the
same way you would do if you do it on the real hardware...

Maybe we should add some JTAG (or anything like) emulation, to make this
easier ;-)

[...]

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Thiemo Seufer]

Blue Swirl wrote:
> On 10/1/07, Jocelyn Mayer <l_indien@magic.fr> wrote:
> > On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
> > > On 10/1/07, Andreas Färber <andreas.faerber@web.de> wrote:
> > > >
> > > > Am 01.10.2007 um 09:12 schrieb Bob Deblier:
> > > >
> > > > > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > > > > working on this?
> > > >
> > > > I had looked into this recently but it turned out that PearPC and
> > > > others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> > > > incompatible with QEMU, expecting some raw image. I have no idea how
> > > > to go about this; the (working) sparc version uses some "weird"
> > > > assembler initializations. ;-)
> > >
> > > You can use:
> > > objcopy -O binary in.elf out.bin
> > >
> > > Alternatively, Qemu could be enhanced to try loading ELF first and
> > > binary if that fails.
> >
> > This is even not an option. With "normal" full system emulation, Qemu
> > boots like real hardware does. I don't know any CPU able to load ELF
> > images. As the goal is to emulate real hardware, what is to be given is
> > a ROM image, able to boot a real machine.

FWIW, I don't regard the on-disk format of the BIOS as essential, as
long as the emulated CPU sees the same bits as a real cpu does.

Accepting ELF as a (possibly alternative) container for a BIOS image
is a matter of convenience.

> The effect is exactly the same from the emulated CPU perspective. With
> ELF image we gain symbols in the out_asm dump.
> 
> > You can try to ehance the -kernel option to do weird hacks if you like
> > but the CPU state at the start of a normal boot process should be as
> > near as possible as a real CPU after a hard reset. Any other behavior is
> > a bug to fix asap.
> > Imho Qemu can be a very great development tool (and I already used it
> > for this purpose), not just a geek toy, then hacks that do not reflect
> > what real hardware does have to be avoided any time it's possible. Then,
> > adding an ELF loader in the CPU initialisation code seems to be a
> > nonsense. The goal to achieve, imho, is to be able to run real ROM
> > images extracted from real machine, not to "extend" the CPU features
> > with stuffs that has no reality (and are even not useful as long as no
> > machine would never accept to boot on this "firmware").
> 
> Qemu is not limited to just hardware emulation. Please consider for
> example snapshot load/save support, built-in gdbstub and monitor. No
> real hardware has any of these, or perhaps you could do similar things
> with ICE or JTAG.
> 
> Qemu is not also aimed for 100% accurate emulation of the hardware.
> There are no caches or cycle counters and hardware devices run
> unrealistically fast from CPU standpoint. Emulating performance
> counters or the errata the most CPUs have would be extremely
> difficult. I doubt Qemu CPU emulation can ever pass POST of real
> BIOSes.

I am working on making the Malta emulation boot a unaltered YAMON
image. I don't see why a PC BIOS would be harder to accomodate.

> Real BIOSes are also closed source, proprietary binary blobs.

At least YAMON, CFE and PMON are not closed source. YAMON has a funny
license which - I hope - will change.

> Making open source BIOSes a viable alternative is in my opinion a much
> more important goal.

The one doesn't exclude the other. That said, I regard the ability to
boot unaltered real-world firmare as an important test of the quality
of a system emulation.


Thiemo

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Blue Swirl]

On 10/1/07, Thiemo Seufer <ths@networkno.de> wrote:
> Blue Swirl wrote:
> > On 10/1/07, Jocelyn Mayer <l_indien@magic.fr> wrote:
> > > On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
> > > > On 10/1/07, Andreas Färber <andreas.faerber@web.de> wrote:
> > > > >
> > > > > Am 01.10.2007 um 09:12 schrieb Bob Deblier:
> > > > >
> > > > > > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > > > > > working on this?
> > > > >
> > > > > I had looked into this recently but it turned out that PearPC and
> > > > > others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> > > > > incompatible with QEMU, expecting some raw image. I have no idea how
> > > > > to go about this; the (working) sparc version uses some "weird"
> > > > > assembler initializations. ;-)
> > > >
> > > > You can use:
> > > > objcopy -O binary in.elf out.bin
> > > >
> > > > Alternatively, Qemu could be enhanced to try loading ELF first and
> > > > binary if that fails.
> > >
> > > This is even not an option. With "normal" full system emulation, Qemu
> > > boots like real hardware does. I don't know any CPU able to load ELF
> > > images. As the goal is to emulate real hardware, what is to be given is
> > > a ROM image, able to boot a real machine.
>
> FWIW, I don't regard the on-disk format of the BIOS as essential, as
> long as the emulated CPU sees the same bits as a real cpu does.
>
> Accepting ELF as a (possibly alternative) container for a BIOS image
> is a matter of convenience.
>
> > The effect is exactly the same from the emulated CPU perspective. With
> > ELF image we gain symbols in the out_asm dump.
> >
> > > You can try to ehance the -kernel option to do weird hacks if you like
> > > but the CPU state at the start of a normal boot process should be as
> > > near as possible as a real CPU after a hard reset. Any other behavior is
> > > a bug to fix asap.
> > > Imho Qemu can be a very great development tool (and I already used it
> > > for this purpose), not just a geek toy, then hacks that do not reflect
> > > what real hardware does have to be avoided any time it's possible. Then,
> > > adding an ELF loader in the CPU initialisation code seems to be a
> > > nonsense. The goal to achieve, imho, is to be able to run real ROM
> > > images extracted from real machine, not to "extend" the CPU features
> > > with stuffs that has no reality (and are even not useful as long as no
> > > machine would never accept to boot on this "firmware").
> >
> > Qemu is not limited to just hardware emulation. Please consider for
> > example snapshot load/save support, built-in gdbstub and monitor. No
> > real hardware has any of these, or perhaps you could do similar things
> > with ICE or JTAG.
> >
> > Qemu is not also aimed for 100% accurate emulation of the hardware.
> > There are no caches or cycle counters and hardware devices run
> > unrealistically fast from CPU standpoint. Emulating performance
> > counters or the errata the most CPUs have would be extremely
> > difficult. I doubt Qemu CPU emulation can ever pass POST of real
> > BIOSes.
>
> I am working on making the Malta emulation boot a unaltered YAMON
> image. I don't see why a PC BIOS would be harder to accomodate.

Emulating microcode, or firmware blobs loaded to misc devices. Think
writing a BIOS for Transmeta, Alpha or a SoC.

> > Real BIOSes are also closed source, proprietary binary blobs.
>
> At least YAMON, CFE and PMON are not closed source. YAMON has a funny
> license which - I hope - will change.
>
> > Making open source BIOSes a viable alternative is in my opinion a much
> > more important goal.
>
> The one doesn't exclude the other. That said, I regard the ability to
> boot unaltered real-world firmare as an important test of the quality
> of a system emulation.

Maybe. The CPU probes for cacheline size, checks for errata #42 vs
#45, reads debug registers, attempts to identify the bus speed by
comparing I/O access times, tries to verify the system using a TPM and
fails all cases. What can you do?

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[J. Mayer]

On Mon, 2007-10-01 at 22:31 +0300, Blue Swirl wrote:
> On 10/1/07, Thiemo Seufer <ths@networkno.de> wrote:
> > Blue Swirl wrote:
> > > On 10/1/07, Jocelyn Mayer <l_indien@magic.fr> wrote:
> > > > On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
> > > > > On 10/1/07, Andreas Färber <andreas.faerber@web.de> wrote:
> > > > > >
> > > > > > Am 01.10.2007 um 09:12 schrieb Bob Deblier:
> > > > > >
> > > > > > > Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
> > > > > > > working on this?
> > > > > >
> > > > > > I had looked into this recently but it turned out that PearPC and
> > > > > > others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
> > > > > > incompatible with QEMU, expecting some raw image. I have no idea how
> > > > > > to go about this; the (working) sparc version uses some "weird"
> > > > > > assembler initializations. ;-)
> > > > >
> > > > > You can use:
> > > > > objcopy -O binary in.elf out.bin
> > > > >
> > > > > Alternatively, Qemu could be enhanced to try loading ELF first and
> > > > > binary if that fails.
> > > >
> > > > This is even not an option. With "normal" full system emulation, Qemu
> > > > boots like real hardware does. I don't know any CPU able to load ELF
> > > > images. As the goal is to emulate real hardware, what is to be given is
> > > > a ROM image, able to boot a real machine.
> >
> > FWIW, I don't regard the on-disk format of the BIOS as essential, as
> > long as the emulated CPU sees the same bits as a real cpu does.
> >
> > Accepting ELF as a (possibly alternative) container for a BIOS image
> > is a matter of convenience.

If it would really bring extra features, why not. But what does booting
from ELF brings ? Debug symbols ? GDB is the right tool to use them and
does not need the boot to be from an ELF file. Symbols in qemu.log are
not so useful as, at least for me, it is an great help to debug qemu
itself, but not very useful to debug the running code, excluding maybe
for the starter code, for which you can easily follow the asm code.

> > > The effect is exactly the same from the emulated CPU perspective. With
> > > ELF image we gain symbols in the out_asm dump.
> > >
> > > > You can try to ehance the -kernel option to do weird hacks if you like
> > > > but the CPU state at the start of a normal boot process should be as
> > > > near as possible as a real CPU after a hard reset. Any other behavior is
> > > > a bug to fix asap.
> > > > Imho Qemu can be a very great development tool (and I already used it
> > > > for this purpose), not just a geek toy, then hacks that do not reflect
> > > > what real hardware does have to be avoided any time it's possible. Then,
> > > > adding an ELF loader in the CPU initialisation code seems to be a
> > > > nonsense. The goal to achieve, imho, is to be able to run real ROM
> > > > images extracted from real machine, not to "extend" the CPU features
> > > > with stuffs that has no reality (and are even not useful as long as no
> > > > machine would never accept to boot on this "firmware").
> > >
> > > Qemu is not limited to just hardware emulation. Please consider for
> > > example snapshot load/save support, built-in gdbstub and monitor. No
> > > real hardware has any of these, or perhaps you could do similar things
> > > with ICE or JTAG.
> > >
> > > Qemu is not also aimed for 100% accurate emulation of the hardware.
> > > There are no caches or cycle counters and hardware devices run
> > > unrealistically fast from CPU standpoint. Emulating performance
> > > counters or the errata the most CPUs have would be extremely
> > > difficult. I doubt Qemu CPU emulation can ever pass POST of real
> > > BIOSes.
> >
> > I am working on making the Malta emulation boot a unaltered YAMON
> > image. I don't see why a PC BIOS would be harder to accomodate.
> 
> Emulating microcode, or firmware blobs loaded to misc devices. Think
> writing a BIOS for Transmeta, Alpha or a SoC.

Being thinking of this for Alpha for a long time (and even started...).
Hope someday I (or someone else) will have the motivation to really do
it ! But Alpha is quite easy as it's quite well documented... I admit it
may be quite impossible for Transmeta...

> > > Real BIOSes are also closed source, proprietary binary blobs.
> >
> > At least YAMON, CFE and PMON are not closed source. YAMON has a funny
> > license which - I hope - will change.
> >
> > > Making open source BIOSes a viable alternative is in my opinion a much
> > > more important goal.
> >
> > The one doesn't exclude the other. That said, I regard the ability to
> > boot unaltered real-world firmare as an important test of the quality
> > of a system emulation.
> 
> Maybe. The CPU probes for cacheline size, checks for errata #42 vs
> #45, reads debug registers, attempts to identify the bus speed by
> comparing I/O access times, tries to verify the system using a TPM and
> fails all cases. What can you do?

Most of the actual issues are in the chipset and it seems to me that the
less documented platforms are PC and Macs. A lot of other architectures
use quite well documented features and hardcoding some 'answers' can
often be sufficient to please the firmware. And even PowerPC Macs have a
great advantage: the firmware drivers are written in Forth, which is a
great help to understand what to do...
Then, yes, emulating PC chipsets is a real nightmare. But doing this for
a lot of other platforms, for which there is only a few or none open
source firmware or even OS running on, is really doable and is even a
requested feature by some hardware / software developpers.

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

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Aurelien Jarno]

Blue Swirl a écrit :
> On 10/1/07, Thiemo Seufer <ths@networkno.de> wrote:
>> Blue Swirl wrote:

>> The one doesn't exclude the other. That said, I regard the ability to
>> boot unaltered real-world firmare as an important test of the quality
>> of a system emulation.
> 
> Maybe. The CPU probes for cacheline size, checks for errata #42 vs
> #45, reads debug registers, attempts to identify the bus speed by
> comparing I/O access times, tries to verify the system using a TPM and
> fails all cases. What can you do?

Emulate a simpler architecture like mips or arm? ;-)

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Laurent Desnogues]

Aurelien Jarno a écrit :
>> Maybe. The CPU probes for cacheline size, checks for errata #42 vs
>> #45, reads debug registers, attempts to identify the bus speed by
>> comparing I/O access times, tries to verify the system using a TPM and
>> fails all cases. What can you do?
> 
> Emulate a simpler architecture like mips or arm? ;-)

I don't think ARM qualifies as a simple architecture, it certainly
isn't in the same league as MIPS, at least not ARMv6 and ARMv7 :)


			Laurent

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Thiemo Seufer]

Blue Swirl wrote:
[snip]
> > > Qemu is not also aimed for 100% accurate emulation of the hardware.
> > > There are no caches or cycle counters and hardware devices run
> > > unrealistically fast from CPU standpoint. Emulating performance
> > > counters or the errata the most CPUs have would be extremely
> > > difficult. I doubt Qemu CPU emulation can ever pass POST of real
> > > BIOSes.
> >
> > I am working on making the Malta emulation boot a unaltered YAMON
> > image. I don't see why a PC BIOS would be harder to accomodate.
> 
> Emulating microcode, or firmware blobs loaded to misc devices. Think
> writing a BIOS for Transmeta,

Writing the emulation for a transmeta is IMHO more challenging than
writing the "BIOS". Btw, if you are interested in the x86 mode, you can
handle the transmeta just as a x86 variant (with a much more standard BIOS).

> Alpha or a SoC.

Writing "Firmware for a SoC" is part of my dayjob.

> > > Real BIOSes are also closed source, proprietary binary blobs.
> >
> > At least YAMON, CFE and PMON are not closed source. YAMON has a funny
> > license which - I hope - will change.
> >
> > > Making open source BIOSes a viable alternative is in my opinion a much
> > > more important goal.
> >
> > The one doesn't exclude the other. That said, I regard the ability to
> > boot unaltered real-world firmare as an important test of the quality
> > of a system emulation.
> 
> Maybe. The CPU probes for cacheline size, checks for errata #42 vs
> #45, reads debug registers, attempts to identify the bus speed by
> comparing I/O access times, tries to verify the system using a TPM and
> fails all cases. What can you do?

Improve the emulation to handle at least one probing path.


Thiemo

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Natalia Portillo]

Hi all,

Just to resume,
I'm in position with Fabrice, Thiemo and Jocelyn.

And, to note.

Current BIOS are very bloated assembler hacks that everytime I use them make 
me think "miracle, it POSTs!"

No way, in a far far away galaxy, there was a simple BIOS, that WONT RUN 
UNDER QEMU.

Why?
Timing?
Doesn't matter to it.

Strange hardware bugs?
Too early for ever knowing they were there.

Source available?
Yes, it is, I don't know the license, but Compaq used it to make the cloned 
BIOS, so we should be able to use it to make QEMU able to POST-It (trademark 
lol)

And if any firmware wants to be an alternative open-source firmware it 
should meet the following requirements:
1.- Be able to boot, unmodified, in real hardware (REAL!)
2.- Be able to boot the same operating systems a closed-source firmware for 
that platform will be. (in REAL hardware)

It is desiderable for QEMU,
no way,
IT IS A MUST FOR QEMU,
to be able to boot real firmware that boots in the real hardware QEMU is 
emulating.

(That is, if QEMU emulates a PIIX4 with Pentium II, it must support booting 
a BIOS for P2+PIIX4, but must not support booting a BIOS for a 
Athlon+nForce)

And, extrapolate what I say to PowerPC, MIPS, ARM, Alpha, Sparc, so on!

Regards,
Natalia Portillo

----- Original Message ----- 
From: "Thiemo Seufer" <ths@networkno.de>
To: "Blue Swirl" <blauwirbel@gmail.com>
Cc: <l_indien@magic.fr>; <qemu-devel@nongnu.org>
Sent: Monday, October 01, 2007 10:57 PM
Subject: Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin


> Blue Swirl wrote:
> [snip]
>> > > Qemu is not also aimed for 100% accurate emulation of the hardware.
>> > > There are no caches or cycle counters and hardware devices run
>> > > unrealistically fast from CPU standpoint. Emulating performance
>> > > counters or the errata the most CPUs have would be extremely
>> > > difficult. I doubt Qemu CPU emulation can ever pass POST of real
>> > > BIOSes.
>> >
>> > I am working on making the Malta emulation boot a unaltered YAMON
>> > image. I don't see why a PC BIOS would be harder to accomodate.
>>
>> Emulating microcode, or firmware blobs loaded to misc devices. Think
>> writing a BIOS for Transmeta,
>
> Writing the emulation for a transmeta is IMHO more challenging than
> writing the "BIOS". Btw, if you are interested in the x86 mode, you can
> handle the transmeta just as a x86 variant (with a much more standard 
> BIOS).
>
>> Alpha or a SoC.
>
> Writing "Firmware for a SoC" is part of my dayjob.
>
>> > > Real BIOSes are also closed source, proprietary binary blobs.
>> >
>> > At least YAMON, CFE and PMON are not closed source. YAMON has a funny
>> > license which - I hope - will change.
>> >
>> > > Making open source BIOSes a viable alternative is in my opinion a 
>> > > much
>> > > more important goal.
>> >
>> > The one doesn't exclude the other. That said, I regard the ability to
>> > boot unaltered real-world firmare as an important test of the quality
>> > of a system emulation.
>>
>> Maybe. The CPU probes for cacheline size, checks for errata #42 vs
>> #45, reads debug registers, attempts to identify the bus speed by
>> comparing I/O access times, tries to verify the system using a TPM and
>> fails all cases. What can you do?
>
> Improve the emulation to handle at least one probing path.
>
>
> Thiemo
>
>
>
> 

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Blue Swirl]

On 10/5/07, Natalia Portillo <claunia@claunia.com> wrote:
> It is desiderable for QEMU,
> no way,
> IT IS A MUST FOR QEMU,
> to be able to boot real firmware that boots in the real hardware QEMU is
> emulating.
>
> (That is, if QEMU emulates a PIIX4 with Pentium II, it must support booting
> a BIOS for P2+PIIX4, but must not support booting a BIOS for a
> Athlon+nForce)
>
> And, extrapolate what I say to PowerPC, MIPS, ARM, Alpha, Sparc, so on!

Please send your patches to fix the bugs in this area to the list. ;-)

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[Fabrice Bellard]

Blue Swirl wrote:
> On 10/1/07, Jocelyn Mayer <l_indien@magic.fr> wrote:
>> On Mon, 2007-10-01 at 17:55 +0300, Blue Swirl wrote:
>>> On 10/1/07, Andreas Färber <andreas.faerber@web.de> wrote:
>>>> Am 01.10.2007 um 09:12 schrieb Bob Deblier:
>>>>
>>>>> Ideally we should have an OpenBIOS compiled for QEMU/PPC. Is anyone
>>>>> working on this?
>>>> I had looked into this recently but it turned out that PearPC and
>>>> others using OpenBIOS/ppc use an ELF format OpenBIOS binary that is
>>>> incompatible with QEMU, expecting some raw image. I have no idea how
>>>> to go about this; the (working) sparc version uses some "weird"
>>>> assembler initializations. ;-)
>>> You can use:
>>> objcopy -O binary in.elf out.bin
>>>
>>> Alternatively, Qemu could be enhanced to try loading ELF first and
>>> binary if that fails.
>> This is even not an option. With "normal" full system emulation, Qemu
>> boots like real hardware does. I don't know any CPU able to load ELF
>> images. As the goal is to emulate real hardware, what is to be given is
>> a ROM image, able to boot a real machine.
> 
> The effect is exactly the same from the emulated CPU perspective. With
> ELF image we gain symbols in the out_asm dump.
> 
>> You can try to ehance the -kernel option to do weird hacks if you like
>> but the CPU state at the start of a normal boot process should be as
>> near as possible as a real CPU after a hard reset. Any other behavior is
>> a bug to fix asap.
>> Imho Qemu can be a very great development tool (and I already used it
>> for this purpose), not just a geek toy, then hacks that do not reflect
>> what real hardware does have to be avoided any time it's possible. Then,
>> adding an ELF loader in the CPU initialisation code seems to be a
>> nonsense. The goal to achieve, imho, is to be able to run real ROM
>> images extracted from real machine, not to "extend" the CPU features
>> with stuffs that has no reality (and are even not useful as long as no
>> machine would never accept to boot on this "firmware").
> 
> Qemu is not limited to just hardware emulation. Please consider for
> example snapshot load/save support, built-in gdbstub and monitor. No
> real hardware has any of these, or perhaps you could do similar things
> with ICE or JTAG.
> 
> Qemu is not also aimed for 100% accurate emulation of the hardware.
> There are no caches or cycle counters and hardware devices run
> unrealistically fast from CPU standpoint. Emulating performance
> counters or the errata the most CPUs have would be extremely
> difficult. I doubt Qemu CPU emulation can ever pass POST of real
> BIOSes. Real BIOSes are also closed source, proprietary binary blobs.
> Making open source BIOSes a viable alternative is in my opinion a much
> more important goal.

I know at least one real PC BIOS which "almost" work in QEMU. "almost" 
because a few fixes are needed in the PIIX3 bridge and I never found the 
time to publish them. Another point was the timing accuracy which made 
the BIOS hang sometimes, but it can also be solved.

> [...]

Fabrice.

Re: [Qemu-devel] qemu/pc-bios ppc_rom.bin

[J. Mayer]

On Mon, 2007-10-01 at 09:05 +0200, Avi Kivity wrote:
> Jocelyn Mayer wrote:
> > CVSROOT:	/sources/qemu
> > Module name:	qemu
> > Changes by:	Jocelyn Mayer <j_mayer>	07/10/01 06:44:33
> >
> > Modified files:
> > 	pc-bios        : ppc_rom.bin 
> >
> > Log message:
> > 	Quickly hack PowerPC BIOS able to boot on CDROM again.
> >
> > CVSWeb URLs:
> > http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/ppc_rom.bin?cvsroot=qemu&rev=1.7
> >
> >
> >   
> 
> There really should be a pointer to the sources used to generate this. 
> Ideally the full sources.

To answer to this, I can say I did took the sources from the version 0.4.1
http://perso.magic.fr/l_indien/OpenHackWare/0.4/OpenHackWare-0.4.1.tar.bz2
and did a hacky mix with the patch from Fabrice, commited in Qemu (which
has good things but also breaks some features) and quick "minute" fixes.
The fact is that the online version of OHW is really outdated but my
working repository is not in a stable state and seems absolutelly not
usable as it is, then I'd prefer not to make it public for now...

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

[Qemu-devel] qemu/pc-bios ppc_rom.bin

[Fabrice Bellard]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Branch: 	
Changes by:	Fabrice Bellard <bellard@savannah.gnu.org>	05/04/06 23:06:54

Modified files:
	pc-bios        : ppc_rom.bin 

Log message:
	Open Hack'Ware version 0.4.1

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/pc-bios/ppc_rom.bin.diff?tr1=1.3&tr2=1.4&r1=text&r2=text

[Qemu-devel] qemu/pc-bios ppc_rom.bin

[Fabrice Bellard]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Branch: 	
Changes by:	Fabrice Bellard <bellard@savannah.gnu.org>	05/03/13 16:51:00

Modified files:
	pc-bios        : ppc_rom.bin 

Log message:
	fpu init fix (Jocelyn Mayer)

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/qemu/qemu/pc-bios/ppc_rom.bin.diff?tr1=1.2&tr2=1.3&r1=text&r2=text