Am 02.07.2013 15:39, schrieb Julio Guerra: > 2013/5/5 Andreas Färber <andreas.faer...@web.de>: >> 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 >
