Re: [Qemu-devel] [PATCH prep for-1.5 v2] prep: Add ELF support for -bios

[Andreas Färber]

Am 02.07.2013 15:39, schrieb Julio Guerra:
> 2013/5/5 Andreas Färber <address@hidden>:
>> This prepares for switching from OpenHack'Ware to OpenBIOS.
>>
>> While touching the error handling code, switch from aborting hw_error()
>> to fprintf()+exit() and suppress failing without -bios for qtest.
>>
> 
> I still can't run bare-metal elf programs from -bios option. Where is
> the instruction pointer set to the elf program entry address ?

By definition, bare-metal programs run on real hardware and thus need to
have their entry point where the hardware expects it - either 0xfffffffc
or 0xfff00100 depending on -cpu model.

Note that when you run a -bios, no other firmware is loaded before, so
you need to populate the exception vectors yourself, such as 0xfff00700
below. You can peek at how OpenBIOS handles this for an example.

Magically changing the CPU's reset vector would be a clear deviation
from the hardware we're modelling. But if you spot differences between
real hardware and QEMU please do report that.

If you want to load a kernel on top of firmware (i.e., not bare-metal),
use -kernel instead.
On PReP that currently uses OpenHack'Ware; my latest attempts to switch
to OpenBIOS exited unexpectedly from the Forth runtime - any help with
debugging appreciated.

Andreas

> E.g. trying to run a bare-metal infinite loop linked at 0x4XXX. adresses :
> ./qemu-system-ppc -M prep -m 256M -bios loop.elf -nographic -d in_asm
> QEMU 1.5.50 monitor - type 'help' for more information
> (qemu)
> invalid/unsupported opcode: 00 - 00 - 00 (00000000) fffffffc 0
> IN:
> 0xfffffffc:  .long 0x0
> 
> invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff00700 0
> IN:
> 0xfff00700:  .long 0x0
> 
> --
> Julio Guerra
>