> 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.
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.
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
>
>
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
> 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
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.
> ./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
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
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.
