I have begun doing work with OpenBIOS. I was wondering if it is
possible to compile OpenBIOS for PowerPC on Mac OS X? If not, what
Linux distro should I use? Any advice would really help.
Hi folks,
I've been trying to use OpenBIOS with QEMU, and I've had trouble
getting it to boot any PowerPC-based OS discs (Linux, Mac OS X, etc).
OpenBIOS just doesn't seem to find anything bootable. If I try booting
QEMU with -nographic, I get this output (I get the same with a
self-built openbios-qemu.elf from the OpenBIOS SVN as well):
---- snip ----
>> =============================================================
>> OpenBIOS 1.0 [Apr 12 2009 00:55]
>> Configuration device id QEMU version 1 machine id 1
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,970FX
Welcome to OpenBIOS v1.0 built on Apr 12 2009 00:55
>> ELF - yaboot_startup: Entering boot, no path
>> ELF - try_bootinfo: Trying hd:0,ppc\bootinfo.txt
>> ELF - try_bootinfo: Can't open hd:0,ppc\bootinfo.txt
>> ELF - try_path: Trying hd:2,\ofclient
>> ELF - try_path: Can't open hd:2,\ofclient
>> ELF - try_path: Trying hd:2,\yaboot conf=hd:2,\yaboot.conf
>> ELF - try_path: Can't open hd:2,\yaboot
>> *** Boot failure! No secondary bootloader specified ***
---- snip ----
Laurent Vivier suggested in this conversation in February
(http://lists.openbios.org/pipermail/openbios/2009-February/003476.html)
that there could be a bug in partition map decoding. Has such a bug
been confirmed? I was trying to find the bug myself (I am an
experienced C/C++ programmer), but the bug seems to be subtle, and my
lack of familiarity with the code base doesn't help much.
I've been trying to figure this out for 7 hours straight now... Any
advice or other help would be much appreciated!
- Steven
On Mon, Dec 28, 2009 at 1:15 PM, <svn(a)openbios.org> wrote:
> Author: blueswirl
> Date: 2009-12-28 11:15:33 +0100 (Mon, 28 Dec 2009)
> New Revision: 648
>
> Modified:
> trunk/openbios-devel/arch/sparc64/entry.S
> trunk/openbios-devel/drivers/pci.c
> trunk/openbios-devel/drivers/vga_vbe.c
> Log:
> Map VGA buffer only during PCI probe
>
> Also pass physical addresses instead of bus addresses to VGA init.
>
> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com>
>
> Modified: trunk/openbios-devel/drivers/vga_vbe.c
> ===================================================================
> --- trunk/openbios-devel/drivers/vga_vbe.c 2009-12-21 09:57:53 UTC (rev 647)
> +++ trunk/openbios-devel/drivers/vga_vbe.c 2009-12-28 10:15:33 UTC (rev 648)
> @@ -25,6 +25,7 @@
> #include "asm/io.h"
> #include "libc/vsprintf.h"
> #include "video_subr.h"
> +#include "ofmem.h"
>
> /* VGA init. We use the Bochs VESA VBE extensions */
> #define VBE_DISPI_INDEX_ID 0x0
> @@ -142,7 +143,10 @@
> depth = d;
> linebytes = (width * ((depth + 7) / 8));
> }
> +#ifdef CONFIG_SPARC64
> + ofmem_map_page_range(fb, fb, fb_size, 0x36);
> #endif
> +#endif
>
> vga_vbe_set_mode(width, height, depth);
You pass flags so mapping is unlocked, this can cause
problems with translations being evicted from tlb table.
Do you see any issues? Linux kernel has it's own idea
of address translations, and we still do not switch trap
handlers so probably framebuffer should be mapped
locked into tlb table (mode=0x76)
--
Kind regards,
Igor V. Kovalenko
The following series implements alternative approach
to solve issue where qemu provides i/o and pci memory
spaces within physical RAM address space, which makes
low memory addresses unusable.
Instead of changing qemu to move i/o and pci spaces
out of RAM space we can remap 64M of i/o and pci
spaces to above 32bit accessible by client program.
Then we map physical RAM at 64M offset to start of
virtual memory.
A few extra changes are required. At very least we
need to find where framebuffer virtual address is
placed by startup code, helper change is provided.
NOTE: this approach may hide up to 128M from client
allocations, therefore default qemu memory size
is not sufficient. Please use at least '-m 256'
on qemu command line to test with these changes.
In my test these series are as efficient as
qemu change to remap i/o and pci spaces in
allowing milax032sparc.iso to not step over
cmd646 registers. Currently milax loader
gets a bit further and fails with
Can't open /ramdisk-root
byte-load: exception caught!
v0 -> v1: split ofmem_find_virtual changes into separate patches
---
Igor V. Kovalenko (5):
sparc64: remap first 64M physical address space
sparc64: claim memory mapped by startup code
ofmem: helper to find first virtual address map entry
ofmem: use helper to access command line parameters from qemu
ofmem: use helper to find framebuffer virtual address on sparc64
arch/sparc64/entry.S | 68 +++++++++++++++++++-----------------------
arch/sparc64/ofmem_sparc64.c | 2 +
arch/sparc64/openbios.c | 19 ++++++++----
include/ofmem.h | 1 +
modules/ofmem_common.c | 25 +++++++++++++++
modules/video.c | 9 +++++-
6 files changed, 80 insertions(+), 44 deletions(-)
--
Kind regards,
Igor V. Kovalenko