OpenBIOS July 2011

openbios@openbios.org

8 participants
14 discussions

by Nick Couchman

> Hi Nick, > > Thanks again for testing this. The issue with Solaris not detecting the > disks is a known one - the following guide should point you in the right > direction: > > http://virtuallyfun.blogspot.com/2010/10/formatting-disks-for-solaris.html > > Also don't forget the "set scsi_options" part from Artyom's SPARC/QEMU > howto here: http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html > > I think it may actually be possible to come up with a patch for OpenBIOS > so that the scsi_options change isn't required - let me know how you get > on with the above links, and if it all seems to work I'll look at > creating the patch for you. > > Okay, I got passed the issue with formatting the root filesystem. Apparently there are some limitations on the C/H/S parameters you use for the disk that correspond with how UFS wants to format a new filesystem. I'm not sure what exactly those limitations are at this point, but, by adjusting a couple of the C/H/S settings when using format to set up the disk I was able to get it to work correctly. So, I now have Solaris 9 installed on qemu-system-sparc with OpenBIOS! I'll probably go back to Solaris 8 as that one has a free binary license while Solaris 9 is a commercial license, IIRC. I do own a Solaris 9 commercial license, but I like the free idea, better. Anyway, now I'm on to an issue with networking - I've used the following two qemu network parameter combinations: -net nic -net tap,ifname=tap0 -net nic -net user In the first instance, tap0 was configured on my Linux box and added to my bridge br0. In both cases the Solaris system is unable to obtain a DHCP address - the DHCP client times out. Not sure if I should be using a different parameter set, or if this is another area that needs some work either for OpenBIOS or qemu? -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

10 years, 4 months

Re: [OpenBIOS] OpenBios Sparc64

by Tarl Neustaedter

On 2011-Jul-19 09:45 , Ghitulete Razvan wrote: > So I kinda got rid of that MMU Miss error, but now, when i try and > open-dev the display adapter i get a 0 return code on the stack. The > output being something like this. > > ok showstack > ok " /pci/SUNW,m64B " open-dev > 0 ok > That usually means the "open" method of your driver didn't succeed. For whatever reason, the SUNW,m64B driver returned a failure at open - either some allocation failed or it decided it didn't like the hardware it found.

10 years, 5 months

Re: [OpenBIOS] [Qemu-devel] [Bug 818645] [NEW] Unhandled OF service in FreeBSD loader - "unimplemented service milliseconds"

by Blue Swirl

On Sat, Jul 30, 2011 at 9:03 PM, Wojciech Koszek <818645(a)bugs.launchpad.net> wrote: > Public bug reported: > > wkoszek@wkoszek:~/bin/qemu/qemu$ git log | head -1 > commit c886edfb851c0c590d4e77f058f2ec8ed95ad1b5 > > built with default settings. > > Run like that: > /home/wkoszek/bin/qemu-dynamic/bin/qemu-system-sparc64 -m 1024 -cdrom ~/Pulpit/iso/FreeBSD-7.4-RELEASE-sparc64-bootonly.iso -hda ~/Pulpit/iso/freebsd_sparc64.qcow2 -nographic -boot d > > Configuration device id QEMU version 1 machine id 0 > kernel cmdline > CPUs: 1 x SUNW,UltraSPARC-IIi > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:17 > Type 'help' for detailed information > Trying cdrom:f... > Not a bootable ELF image > Loading a.out image... > Loaded 7680 bytes > entry point is 0x4000 > > Jumping to entry point 0000000000004000 for type 0000000000000005... > switching to new context: entry point 0x4000 stack 0x00000000ffe86b49 > >>> FreeBSD/sparc64 boot block > Boot path: cdrom:f > Boot loader: /boot/loader > Consoles: Open Firmware console > > Booting with sun4u support. > Boot path set to cdrom:a > > FreeBSD/sparc64 bootstrap loader, Revision 1.0 > (root(a)warner.cse.buffalo.edu, Fri Feb 18 05:38:31 UTC 2011) > bootpath="cdrom:a" > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x8d1f48+0x82f88 syms=[0x8+0x88ec0+0x8+0x76966] > | > Unimplemented service milliseconds ([0] -- [1]) > Hit [Enter] to boot immediately, or any other key for command prompt. > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > > This basically loops here unless I press CTRL+C. > > Was there any OpenBIOS release that didn't have this problem? "milliseconds" has not implemented for Sparc, but there is a similar service for PPC machines which could be used as a starting point. > > ** Affects: qemu > Importance: Undecided > Status: New > > > ** Tags: freebsd > > -- > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > https://bugs.launchpad.net/bugs/818645 > > Title: > Unhandled OF service in FreeBSD loader - "unimplemented service > milliseconds" > > Status in QEMU: > New > > Bug description: > wkoszek@wkoszek:~/bin/qemu/qemu$ git log | head -1 > commit c886edfb851c0c590d4e77f058f2ec8ed95ad1b5 > > built with default settings. > > Run like that: > /home/wkoszek/bin/qemu-dynamic/bin/qemu-system-sparc64 -m 1024 -cdrom ~/Pulpit/iso/FreeBSD-7.4-RELEASE-sparc64-bootonly.iso -hda ~/Pulpit/iso/freebsd_sparc64.qcow2 -nographic -boot d > > Configuration device id QEMU version 1 machine id 0 > kernel cmdline > CPUs: 1 x SUNW,UltraSPARC-IIi > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:17 > Type 'help' for detailed information > Trying cdrom:f... > Not a bootable ELF image > Loading a.out image... > Loaded 7680 bytes > entry point is 0x4000 > > Jumping to entry point 0000000000004000 for type 0000000000000005... > switching to new context: entry point 0x4000 stack 0x00000000ffe86b49 > > >> FreeBSD/sparc64 boot block > Boot path: cdrom:f > Boot loader: /boot/loader > Consoles: Open Firmware console > > Booting with sun4u support. > Boot path set to cdrom:a > > FreeBSD/sparc64 bootstrap loader, Revision 1.0 > (root(a)warner.cse.buffalo.edu, Fri Feb 18 05:38:31 UTC 2011) > bootpath="cdrom:a" > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x8d1f48+0x82f88 syms=[0x8+0x88ec0+0x8+0x76966] > | > Unimplemented service milliseconds ([0] -- [1]) > Hit [Enter] to boot immediately, or any other key for command prompt. > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > > This basically loops here unless I press CTRL+C. > > Was there any OpenBIOS release that didn't have this problem? > > To manage notifications about this bug go to: > https://bugs.launchpad.net/qemu/+bug/818645/+subscriptions > >

10 years, 5 months

OpenBIOS PowerPC missing open firmware commands

by Alexander von Gluck

Just a few things I noticed while hacking away at Haiku on PowerPC: The following OpenFirmware commands aren't implemented: erase-screen toggle-cursor The following paths are missing essential information: cpu node -> clock-frequency cpu node -> timebase-frequency cpu node -> bus-frequency Example: cd / cd cpus cd PowerPC,750@0 .properties These properties are present on real PowerPC hardware, but are set to 0 (or missing in the case of bus-frequency) on the qemu OpenBIOS. Thoughts? Thanks! -- Alex

10 years, 6 months

Re: [OpenBIOS] OpenBios Sparc64

by Ghitulete Razvan

> I started playing with the OpenFirmware(I got a SunBlade in the > meanwhile). But i'm not able to get an instance of the SUNW,m64B, and > as a matter of fact of nothing, as I get a Fast Data Access MMU Miss > every time i try the open-dev command. I know I don't need an instance > to get the .properties of the device, but I think that MUU miss > couldn't be a good thing... > So I kinda got rid of that MMU Miss error, but now, when i try and open-dev the display adapter i get a 0 return code on the stack. The output being something like this. ok showstack ok " /pci/SUNW,m64B " open-dev 0 ok Is there anything wrong with this approach. I mean a reason for the 0 return code? -- Razvan Ghitulete Universitatea Politehnica Bucuresti

10 years, 6 months

Re: [OpenBIOS] OpenBios Sparc64

by Tarl Neustaedter

On 2011-Jul-18 03:09 , Ghitulete Razvan wrote: >> > Ah - on SPARCs, the video is not at a fixed address. The "display" >> > device tree node will tell you what the physical address is (which >> > varies from platform to platform) with the "reg" property, and you have >> > to "map-in" that physical address to a virtual address. > Do you happen to know/have any books/papers on this aspect of the > sparc architecture. On the oracle web site I only found the V9, and it > doesn't mention anything about this stuff, as far as i've read. > Mostly in the IEEE 1275 specification. Look at the "reg" and "assigned-address" properties, and the semantics of "map-in". On SBus machines, the FCode of the SBus cards would created these properties indicating where the PIO space of video card would be, on PCI machines, the BARs will do this and be reflected in the "reg" and "assigned-address" properties.

10 years, 6 months

Re: [OpenBIOS] OpenBios Sparc64

by Ghitulete Razvan

> ./configure --target-list=sparc64-softmmu > Mark. Thanks I'll give this a try. > Ah - on SPARCs, the video is not at a fixed address. The "display" > device tree node will tell you what the physical address is (which > varies from platform to platform) with the "reg" property, and you have > to "map-in" that physical address to a virtual address. Do you happen to know/have any books/papers on this aspect of the sparc architecture. On the oracle web site I only found the V9, and it doesn't mention anything about this stuff, as far as i've read. Thanks, -- Razvan Ghitulete Universitatea Politehnica Bucuresti

10 years, 6 months

fcode rom loading

by Bob Breuer

I'm trying to get the sparc32 OpenBIOS to load an fcode rom, but it's not working. After byte-load, it reports out of memory. Here's the steps I'm using to setup a simple rom which just sets the device name to "QEMU,test", and then trying to run it: fd000000 1000 l! 00000020 1004 l! 12095145 1008 l! 4d552c74 100c l! 65737401 1010 l! 1412046e 1014 l! 616d6501 1018 l! 10000000 101c l! cd /iommu/sbus " /iommu/sbus" select-dev new-device 1000 1 byte-load Here, OpenBIOS will report out of memory. Bob

10 years, 6 months

[commit] r1045 - trunk/openbios-devel/arch/sparc32

by repository service

Author: mcayland Date: Thu Jul 14 16:37:34 2011 New Revision: 1045 URL: http://tracker.coreboot.org/trac/openbios/changeset/1045 Log: Fix Fcode table initialisation on SPARC32. Increase the Forth machine memory to 128K (also requiring a corresponding increase in OFMEM to 384K) to allow enough space for the Fcode tables to be initialised, and hence allow Fcode to be executed under SPARC32. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> Acked-by: Bob Breuer <breuerr(a)mc.net> Modified: trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c trunk/openbios-devel/arch/sparc32/openbios.c Modified: trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c Fri Jun 17 02:55:04 2011 (r1044) +++ trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c Thu Jul 14 16:37:34 2011 (r1045) @@ -21,7 +21,7 @@ #define OF_MALLOC_BASE ((char*)OFMEM + ALIGN_SIZE(sizeof(ofmem_t), 8)) -#define MEMSIZE (256 * 1024) +#define MEMSIZE (384 * 1024) static union { char memory[MEMSIZE]; ofmem_t ofmem; Modified: trunk/openbios-devel/arch/sparc32/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/openbios.c Fri Jun 17 02:55:04 2011 (r1044) +++ trunk/openbios-devel/arch/sparc32/openbios.c Thu Jul 14 16:37:34 2011 (r1045) @@ -27,7 +27,7 @@ #include "arch/common/fw_cfg.h" #include "libopenbios/ofmem.h" -#define MEMORY_SIZE (16*1024) /* 16K ram for hosted system */ +#define MEMORY_SIZE (128*1024) /* 128K ram for hosted system */ #define UUID_FMT "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x" #define FW_CFG_SUN4M_DEPTH (FW_CFG_ARCH_LOCAL + 0x00)

10 years, 6 months

Re: [OpenBIOS] OpenBios Sparc64

by Tarl Neustaedter

On 2011-Jul-12 07:51 , Ghitulete Razvan wrote: > Also, if anyone has any ideea whatsoever, could i write directly to > the video memory on a sparc, and if so at what address does the video > card mapping starts? Ah - on SPARCs, the video is not at a fixed address. The "display" device tree node will tell you what the physical address is (which varies from platform to platform) with the "reg" property, and you have to "map-in" that physical address to a virtual address.

10 years, 6 months