> 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.
>
> Nick - do you think you could do a quick test on this one?
>
This patch for the scsi_options seems to work fine - system boots with
the patch applied and with the line removed from /etc/system.
-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.
Hi folks,
The attached patch changes OFMEM so that instead of allocating new space
within the Forth dictionary every time the /memory and /virtual-memory
available/translations nodes are updated, we simply change the property
to point directly to a static buffer. This has the effect of saving
substantial amounts of memory during OpenSolaris 10 boot (in fact the
final dictionary size after boot is now < 256K once again).
Blue/Andreas: please could you take a look at this patch and make sure
it doesn't break anything in your SPARC64/PPC tests?
On the plus side, with this patch applied Milax gets to the end of its
natural boot without crashing giving the following output:
OpenBIOS for Sparc64
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 Oct 14 2010 20:18
Type 'help' for detailed information
Trying cdrom:f...
Not a bootable ELF image
Not a bootable a.out image
Loading FCode image...
Loaded 7084 bytes
entry point is 0x4000
Ignoring failed claim for va 1000000 memsz bf34e!
Ignoring failed claim for va 1402000 memsz 303b3!
Ignoring failed claim for va 1800000 memsz 60a30!
Jumping to entry point 00000000010071d8 for type 0000000000000001...
switching to new context: entry point 0x10071d8 stack 0x00000000ffe06b49
warning:interpret: exception -13 caught
SunOS Release 5.11 Version MilaX_0.3.2 64-bit
Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
spacex@:interpret: exception -13 caught
kdbg-words:interpret: exception -13 caught
cb-r/w:interpret: exception -13 caught
(Can't load tod module) EXIT
-1 >
Does anyone know what the tod modules does? Is it Time Of Day (i.e. we
are missing some kind of hardware clock emulation?)
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
On Fri, 2011-04-22 at 08:08 +0100, Mark Cave-Ayland wrote:
> With my previously posted patched applied:
>
> Wow. All I can say is thank you so much to everyone who helped me get
> this far - in particular Blue, Artyom and Tarl. Does anyone know if we
> are the first non-Sun firmware to be able to boot a Solaris kernel?
>
> Blue - I think you owe me that 1.1 release soon!
>
>
> Happy Easter everyone!
>
> Mark.
>
Thanks, again, Mark - this is fantastic!
After booting the install successfully from the Solaris ISO/CDROM and
getting through the initial configuration (on both Solaris 8 and 9), the
install fails trying to label the hard drive. First, I see the
following during the installer boot:
WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 (sd0):
corrupt label - wrong magic number
Then, after doing the system identification, I get the following:
One or more disks are found, but one of the
following problems exists:
> Hardware failure
> Unformatted disk.
At which point I get dropped to a shell. If I try to use the format
command from the shell, format cannot auto-configure the disk. Even if
I try manually setting C/H/S parameters (either at qemu run time or in
the format command), it does not seem to want to use the disk. This
seems to happen whether I'm using an LVM volume or a file-based disk.
Also, seems as though all changes are lost on the disk when I exit
format and then immediately go back in.
Ideas? Any further help/input/debugging I could provide?
-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.
Author: mcayland
Date: Wed Apr 27 21:20:10 2011
New Revision: 1037
URL: http://tracker.coreboot.org/trac/openbios/changeset/1037
Log:
Fix up LANCE ethernet DMA mapping under Solaris 8 on SPARC32.
It seems that Solaris doesn't set up a DMA mapping for the LANCE DMA buffers
and hence must inherit this from OpenBIOS. To make things more complicated,
Solaris appears to assume that the buffers are fixed at 0xff000000 rather
than detecting this information from the OpenBIOS IOMMU pagetable before
switching. Mimicking this behaviour with a fixed location allows Solaris
8 to correctly use the network card under QEMU.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk>
Modified:
trunk/openbios-devel/config/examples/sparc32_config.xml
trunk/openbios-devel/drivers/sbus.c
Modified: trunk/openbios-devel/config/examples/sparc32_config.xml
==============================================================================
--- trunk/openbios-devel/config/examples/sparc32_config.xml Wed Apr 27 21:20:06 2011 (r1036)
+++ trunk/openbios-devel/config/examples/sparc32_config.xml Wed Apr 27 21:20:10 2011 (r1037)
@@ -63,6 +63,7 @@
<!-- Drivers -->
<option name="CONFIG_DRIVER_SBUS" type="boolean" value="true"/>
+ <option name="CONFIG_DEBUG_SBUS" type="boolean" value="false"/>
<option name="CONFIG_DRIVER_OBIO" type="boolean" value="true"/>
<option name="CONFIG_DRIVER_ESP" type="boolean" value="true"/>
<option name="CONFIG_DRIVER_FLOPPY" type="boolean" value="true"/>
Modified: trunk/openbios-devel/drivers/sbus.c
==============================================================================
--- trunk/openbios-devel/drivers/sbus.c Wed Apr 27 21:20:06 2011 (r1036)
+++ trunk/openbios-devel/drivers/sbus.c Wed Apr 27 21:20:10 2011 (r1037)
@@ -29,6 +29,20 @@
#define SS600MP_ESPDMA 0x00081000ULL
#define SS600MP_ESP 0x00080000ULL
#define SS600MP_LEBUFFER (SS600MP_ESPDMA + 0x10) // XXX should be 0x40000
+#define LEDMA_REGS 0x4
+#define LE_REGS 0x20
+
+#ifdef CONFIG_DEBUG_SBUS
+#define DPRINTF(fmt, args...) \
+ do { printk(fmt , ##args); } while (0)
+#else
+#define DPRINTF(fmt, args...)
+#endif
+
+typedef struct le_private {
+ uint32_t *dmaregs;
+ uint32_t *regs;
+} le_private_t;
static void
ob_sbus_node_init(uint64_t base)
@@ -57,8 +71,36 @@
}
static void
-ob_le_init(unsigned int slot, unsigned long leoffset, unsigned long dmaoffset)
+ob_le_init(unsigned int slot, uint64_t base, unsigned long leoffset, unsigned long dmaoffset)
{
+ le_private_t *le;
+
+ le = malloc(sizeof(le_private_t));
+ if (!le) {
+ DPRINTF("Can't allocate LANCE private structure\n");
+ return;
+ }
+
+ /* Get the IO region for DMA registers */
+ le->dmaregs = (void *)ofmem_map_io(base + (uint64_t)dmaoffset, LEDMA_REGS);
+ if (le->dmaregs == NULL) {
+ DPRINTF("Can't map LANCE DMA registers\n");
+ return;
+ }
+
+ /* Now it appears that the Solaris kernel forgets to set up the LANCE DMA mapping
+ and so it must inherit the one from OpenBIOS. The symptom of this is that the
+ LANCE DMA base addr register is still zero, and so we start sending network
+ packets containing random areas of memory.
+
+ The correct fix for this should be to use dvma_alloc() to grab a section of
+ memory and point the LANCE DMA buffers to use that instead; this gets
+ slightly further but still crashes. Time-consuming investigation on various
+ hacked versions of QEMU seems to indicate that Solaris always assumes the LANCE
+ DMA base address is fixed 0xff000000 when setting up the IOMMU for the LANCE
+ card. Hence we imitate this behaviour here. */
+ le->dmaregs[3] = 0xff000000;
+
push_str("/iommu/sbus/ledma");
fword("find-device");
PUSH(slot);
@@ -72,6 +114,13 @@
push_str("reg");
fword("property");
+ /* Get the IO region for Lance registers */
+ le->regs = (void *)ofmem_map_io(base + (uint64_t)leoffset, LE_REGS);
+ if (le->regs == NULL) {
+ DPRINTF("Can't map LANCE registers\n");
+ return;
+ }
+
push_str("/iommu/sbus/ledma/le");
fword("find-device");
PUSH(slot);
@@ -371,7 +420,7 @@
#endif
// NCR 92C990, Am7990, Lance. See http://www.amd.com
- ob_le_init(slot, offset + 0x00c00000, offset + 0x00400010);
+ ob_le_init(slot, base, offset + 0x00c00000, offset + 0x00400010);
// Parallel port
//ob_bpp_init(base);
@@ -430,7 +479,7 @@
ob_esp_init(slot, base, SS600MP_ESP, SS600MP_ESPDMA);
#endif
// NCR 92C990, Am7990, Lance. See http://www.amd.com
- ob_le_init(slot, 0x00060000, SS600MP_LEBUFFER);
+ ob_le_init(slot, base, 0x00060000, SS600MP_LEBUFFER);
// Power management (APC) XXX should not exist
ob_apc_init(slot, APC_OFFSET);
break;
On Mon, Apr 25, 2011 at 7:48 PM, Mark Cave-Ayland
<mark.cave-ayland(a)siriusit.co.uk> wrote:
> It seems that Solaris doesn't set up a DMA mapping for the LANCE DMA buffers
> and hence must inherit this from OpenBIOS. To make things more complicated,
> Solaris appears to assume that the buffers are fixed at 0xff000000 rather
> than detecting this information from the OpenBIOS IOMMU pagetable before
> switching. Mimicking this behaviour with a fixed location allows Solaris
> 8 to correctly use the network card under QEMU.
>
> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk>
Would it make any difference if IOMMU region were 16M so that the base
would start at 0xff000000?
Otherwise the patch looks OK.
Am 25.04.2011 um 18:48 schrieb Mark Cave-Ayland:
> It seems that Solaris doesn't set up a DMA mapping for the LANCE DMA
> buffers
> and hence must inherit this from OpenBIOS. To make things more
> complicated,
> Solaris appears to assume that the buffers are fixed at 0xff000000
> rather
> than detecting this information from the OpenBIOS IOMMU pagetable
> before
> switching. Mimicking this behaviour with a fixed location allows
> Solaris
> 8 to correctly use the network card under QEMU.
>
> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk>
> ---
> openbios-devel/drivers/sbus.c | 55 ++++++++++++++++++++++++++++++++
> ++++++--
> 1 files changed, 52 insertions(+), 3 deletions(-)
>
> diff --git a/openbios-devel/drivers/sbus.c b/openbios-devel/drivers/
> sbus.c
> index f4a6d66..1107c1d 100644
> --- a/openbios-devel/drivers/sbus.c
> +++ b/openbios-devel/drivers/sbus.c
> @@ -29,6 +29,20 @@
> #define SS600MP_ESPDMA 0x00081000ULL
> #define SS600MP_ESP 0x00080000ULL
> #define SS600MP_LEBUFFER (SS600MP_ESPDMA + 0x10) // XXX should be
> 0x40000
> +#define LEDMA_REGS 0x4
> +#define LE_REGS 0x20
> +
> +#ifdef CONFIG_DEBUG_SBUS
Missing a corresponding sparc32_config.xml patch?
> +#define DPRINTF(fmt, args...) \
> + do { printk(fmt , ##args); } while (0)
> +#else
> +#define DPRINTF(fmt, args...)
> +#endif
Andreas
> In terms of graphics, there is definitely some work that needs to be
> done. For example, if I try and run the Solaris installer from the VNC
> viewer then rather than launching the installer it outputs "Starting
> OpenWindows" and then freezes. Then again, this is not something that is
> really on my priority list (as my aim was to virtualise a headless
> server) so it's unlikely to happen in the short term.
Yeah, I knew there were some challenges with graphics, and it's great
just to have a working emulated Sparc platform, so, don't get me wrong,
this is not a complaint!
>
> For running QEMU in this way, have you seen Artyom's post here?
> http://tyom.blogspot.com/2010/04/ultimate-way-of-starting-qemu-under.html.
>
Aha - that's what I was looking for. I'll have to spend some more time
reading through Artyom's blog so that I don't have to ask questions like
this that he's already answered.
> > Did the serial port patch ever get checked off and pushed to SVN?
>
> No, not yet. Once Blue has approved both patches then I'll send them up
> to the SVN repository.
>
Cool - sounds good.
-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.