headers
Andreas Färber | 1 May 2011 19:11
Picon
Gravatar

Re: Getting Closer With Booting AIX? I Would Like to Help Please.

Am 25.04.2011 um 07:32 schrieb Kenneth Salerno:

> Hello, I would like to help debug booting AIX with qemu-system-ppc.  
> Here is what I have so far, please let me know what further  
> information I should provide to aid in pinpointing where the  
> following hang occurs:
>
> ====================================================
> Booting AIX in QEMU+OpenBIOS (CPU type PowerPC,750)
> ====================================================
>
> -------------------------------------------------------------------------------
>                                 Welcome to AIX.
>                        boot image timestamp: 00:39 35/2D
>                  The current time and date: 01:10:58 04/25/2011
>         processor count: 1;  memory size: 2047MB;  kernel size:  
> 2293829
>                     boot device: cd:\ppc\chrp\bootfile.exe
> [hangs here...]

After some QEMU patching I'm able to confirm this.
QEMU hangs a lot on my Darwin/ppc64 host though, not just here. My  
Haiku/i386 guest keeps hanging for multiple seconds.

It appears there's some QEMU regression, introduced within the last  
four weeks. Any help bisecting/fixing would be appreciated.

Andreas
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas Färber | 1 May 2011 19:36
Picon
Gravatar

Re: Getting Closer With Booting AIX? I Would Like to Help Please.

Am 26.04.2011 um 10:52 schrieb Artyom Tarasenko:

>> As stated earlier elsewhere, SVN HEAD does
>> not yet work for AIX; patches are needed for RTAS (and QEMU).
>
> BTW, is probably an off topic on this list, but do you know whether
> Slimline Open Firmware (http://www.ibm.com/developerworks/power/pa-slof/ 
> )
> under qemu would be an easier way for booting AIX?

Since we don't have a real IBM machine emulation yet, I haven't played  
with any real firmware for POWER.

I had inquired whether the recent pSeries patch series would help with  
AIX emulation but understood it was only used to boot a Linux kernel  
directly using a special SLOF.

Andreas
Permalink | Reply | 0 comments |
headers
Mark Cave-Ayland | 1 May 2011 22:33
Picon

[PATCH] Disable mixing of DMA and FIFO messages in the Solaris ESP kernel module.

QEMU's ESP emulation currently does not support the mixing of DMA and FIFO
messages. Setting the scsi-options property prevents the Solaris ESP kernel
module from trying to use this feature by default, which otherwise would
cause boot to fail.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@...>
---
 openbios-devel/drivers/esp.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/openbios-devel/drivers/esp.c b/openbios-devel/drivers/esp.c
index 2dfc2bd..78478f6 100644
--- a/openbios-devel/drivers/esp.c
+++ b/openbios-devel/drivers/esp.c
 <at>  <at>  -383,6 +383,14  <at>  <at>  ob_esp_initialize(__attribute__((unused)) esp_private_t **esp)
     push_str("scsi");
     fword("device-type");

+    /* QEMU's ESP emulation does not support mixing DMA and FIFO messages. By
+       setting this attribute, we prevent the Solaris ESP kernel driver from
+       trying to use this feature when booting a disk image (and failing) */
+    PUSH(0x58);
+    fword("encode-int");
+    push_str("scsi-options");
+    fword("property");
+
     PUSH(0x24);
     fword("encode-int");
     PUSH(0);
--

--
(Continue reading)

Permalink | Reply | 5 comments |
headers
Mark Cave-Ayland | 1 May 2011 22:36
Picon

[PATCH] Fix the Forth boot word if the current package is not /chosen.

Make sure that we explicitly state the /chosen package for the words
in the boot process that require it.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@...>
---
 openbios-devel/forth/admin/userboot.fs   |    6 ++++--
 openbios-devel/forth/debugging/client.fs |   11 ++++++-----
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/openbios-devel/forth/admin/userboot.fs b/openbios-devel/forth/admin/userboot.fs
index dd76958..e6ff9ab 100644
--- a/openbios-devel/forth/admin/userboot.fs
+++ b/openbios-devel/forth/admin/userboot.fs
 <at>  <at>  -12,8 +12,10  <at>  <at> 
   then

   \ Execute platform-specific boot code, e.g. kernel
-  s" platform-boot" $find if 
-    execute		
+  s" platform-boot" s" /chosen" find-package if
+    find-method if
+      execute
+    then
   then

   (encode-bootpath)	\ Setup bootpath/bootargs
diff --git a/openbios-devel/forth/debugging/client.fs b/openbios-devel/forth/debugging/client.fs
index f964ed0..45a931e 100644
--- a/openbios-devel/forth/debugging/client.fs
+++ b/openbios-devel/forth/debugging/client.fs
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nathan Kunkee | 2 May 2011 18:20
Picon
Favicon

Re: Solaris anyone? Q2


>>>>> Ah that will probably be the problem - config/script/switch-arch
>>>>> contains the logic which detects how
>>>>> NATIVE_BITWIDTH_EQUALS_HOST_BITWIDTH and SWAP_ENDIANNESS should be set
>>>>> and adds them to CFLAGS in Makefile.target as appropriate.
>>>>>
>>>> OK. I'll start looking to see how to change that for by build
>>>> environment.
>>> Great - thanks!
>> I figured it out!
>>
>> /bin/sh, the default choice if you just run switch-arch, on OpenSolaris is
>> ksh93, which silently fails on the $...bigendian tests. If I run switch-arch
>> with /usr/xpg4/bin/sh or bash, it works fine and my builds from x86 and
>> sparc are now correct and load. It looks like testing for $KSH_VERSION would
>> be a way to find out if the shell isn't going to work, but I don't know if
>> this would come up enough to warrant adding logic to check it.
> Maybe we have a bashism somewhere (should be fixed), or more likely
> since ksh93 is not fully Posix compatible, we use some Posix features
> which are not implemented by ksh93 (maybe avoidable). Please send
> again the output from sh -x for the bigendian test.
>
As run on my Ultra60 which should set CONFIG_BIG_ENDIAN:

nathan <at> valhalla:/export/home/nathan/openbios-devel$ LANG=C /bin/sh -x 
./config/scripts/switch\-arch sparc32
+ MOLPATH=/export/home/nathan//mol-0.9.71
+ [ xsparc32 = x -o sparc32 = -help ]
+ test -f utils/dist/debian/rules
+ chmod 755 utils/dist/debian/rules
(Continue reading)

Permalink | Reply | 13 comments |
headers
Andreas Färber | 2 May 2011 19:33
Picon
Gravatar

Re: Solaris anyone? Q2

Am 02.05.2011 um 18:20 schrieb Nathan Kunkee:

>>> /bin/sh, the default choice if you just run switch-arch, on  
>>> OpenSolaris is
>>> ksh93, which silently fails on the $...bigendian tests. If I run  
>>> switch-arch
>>> with /usr/xpg4/bin/sh or bash, it works fine and my builds from  
>>> x86 and
>>> sparc are now correct and load. It looks like testing for  
>>> $KSH_VERSION would
>>> be a way to find out if the shell isn't going to work, but I don't  
>>> know if
>>> this would come up enough to warrant adding logic to check it.
>> Maybe we have a bashism somewhere (should be fixed), or more likely
>> since ksh93 is not fully Posix compatible, we use some Posix features
>> which are not implemented by ksh93 (maybe avoidable). Please send
>> again the output from sh -x for the bigendian test.
>>
> As run on my Ultra60 which should set CONFIG_BIG_ENDIAN:
>
> nathan <at> valhalla:/export/home/nathan/openbios-devel$ LANG=C /bin/sh - 
> x ./config/scripts/switch\-arch sparc32
> + MOLPATH=/export/home/nathan//mol-0.9.71
> + [ xsparc32 = x -o sparc32 = -help ]
> + test -f utils/dist/debian/rules
> + chmod 755 utils/dist/debian/rules
> + chmod 755 config/scripts/switch-arch
> + chmod 755 config/scripts/reldir
> + test x = x
> + archname
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kenneth Salerno | 3 May 2011 02:57
Picon
Favicon

Re: Solaris anyone? Q2

----- Original Message -----

From: Nathan Kunkee <nkunkee42@...>
To: The OpenBIOS Mailinglist <openbios@...>
Cc: 
Sent: Monday, May 2, 2011 12:20 PM
Subject: Re: [OpenBIOS] Solaris anyone? Q2

>>>>> Ah that will probably be the problem - config/script/switch-arch
>>>>> contains the logic which detects how
>>>>> NATIVE_BITWIDTH_EQUALS_HOST_BITWIDTH and SWAP_ENDIANNESS should be set
>>>>> and adds them to CFLAGS in Makefile.target as appropriate.
>>>>> 
>>>> OK. I'll start looking to see how to change that for by build
>>>> environment.
>>> Great - thanks!
>> I figured it out!
>> 
>> /bin/sh, the default choice if you just run switch-arch, on OpenSolaris is
>> ksh93, which silently fails on the $...bigendian tests. If I run switch-arch
>> with /usr/xpg4/bin/sh or bash, it works fine and my builds from x86 and
>> sparc are now correct and load. It looks like testing for $KSH_VERSION would
>> be a way to find out if the shell isn't going to work, but I don't know if
>> this would come up enough to warrant adding logic to check it.
> Maybe we have a bashism somewhere (should be fixed), or more likely
> since ksh93 is not fully Posix compatible, we use some Posix features
> which are not implemented by ksh93 (maybe avoidable). Please send
> again the output from sh -x for the bigendian test.
> 
As run on my Ultra60 which should set CONFIG_BIG_ENDIAN:
(Continue reading)

Permalink | Reply | 11 comments |
headers
Artyom Tarasenko | 4 May 2011 09:57
Picon

Re: [PATCH] RFC: Change ofmem_common.c to set memory translation properties by reference

On Fri, Oct 15, 2010 at 3:43 PM, Mark Cave-Ayland
<mark.cave-ayland@...> wrote:
> Artyom Tarasenko wrote:
>
>>> I think so. Actually m48t59 is emulated in sparc32, but not connected
>>> in case of sparc64.
>>
>> The referencing comment in the opensolaris source:
>>
>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sun4u/os/fillsysinfo.c#136
>>
>> * Appropriate tod module will be dynamically selected while booting
>> * based on finding a device tree node with a "device_type" property value
>> * of "tod". If such a node describing tod is not found, for backward
>> * compatibility, a node with a "name" property value of "eeprom" and
>> * "model" property value of "mk48t59" will be used. Failing to find a
>> * node matching either of the above criteria will result in no tod module
>> * being selected; this will cause the boot process to halt
>>
>> On the real U30 machine:
>>
>> ok cd /pci <at> 1f,4000/ebus <at> 1/eeprom <at> 14,0
>> ok .properties
>> address                  fffa4000
>> reg                      00000014 00000000 00002000
>> model                    mk48t59
>> name                     eeprom
>> ok
>
> Oh, that's interesting. If I look in drivers/obio.c then I can see an eeprom
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark Cave-Ayland | 4 May 2011 11:19
Picon

Re: [PATCH] RFC: Change ofmem_common.c to set memory translation properties by reference

On 04/05/11 08:57, Artyom Tarasenko wrote:

>>>> I think so. Actually m48t59 is emulated in sparc32, but not connected
>>>> in case of sparc64.
>>>
>>> The referencing comment in the opensolaris source:
>>>
>>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sun4u/os/fillsysinfo.c#136
>>>
>>> * Appropriate tod module will be dynamically selected while booting
>>> * based on finding a device tree node with a "device_type" property value
>>> * of "tod". If such a node describing tod is not found, for backward
>>> * compatibility, a node with a "name" property value of "eeprom" and
>>> * "model" property value of "mk48t59" will be used. Failing to find a
>>> * node matching either of the above criteria will result in no tod module
>>> * being selected; this will cause the boot process to halt
>>>
>>> On the real U30 machine:
>>>
>>> ok cd /pci <at> 1f,4000/ebus <at> 1/eeprom <at> 14,0
>>> ok .properties
>>> address                  fffa4000
>>> reg                      00000014 00000000 00002000
>>> model                    mk48t59
>>> name                     eeprom
>>> ok
>>
>> Oh, that's interesting. If I look in drivers/obio.c then I can see an eeprom
>> device named "mk48t08" rather than "mk48t59". Is this a typo, or does it
>> need a new explicit device defined in pci.c's ebus_config_cb() somewhere?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Artyom Tarasenko | 4 May 2011 12:14
Picon

Re: [PATCH] RFC: Change ofmem_common.c to set memory translation properties by reference

On Wed, May 4, 2011 at 11:19 AM, Mark Cave-Ayland
<mark.cave-ayland@...> wrote:
> On 04/05/11 08:57, Artyom Tarasenko wrote:
>
>>>>> I think so. Actually m48t59 is emulated in sparc32, but not connected
>>>>> in case of sparc64.
>>>>
>>>> The referencing comment in the opensolaris source:
>>>>
>>>>
>>>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sun4u/os/fillsysinfo.c#136
>>>>
>>>> * Appropriate tod module will be dynamically selected while booting
>>>> * based on finding a device tree node with a "device_type" property
>>>> value
>>>> * of "tod". If such a node describing tod is not found, for backward
>>>> * compatibility, a node with a "name" property value of "eeprom" and
>>>> * "model" property value of "mk48t59" will be used. Failing to find a
>>>> * node matching either of the above criteria will result in no tod
>>>> module
>>>> * being selected; this will cause the boot process to halt
>>>>
>>>> On the real U30 machine:
>>>>
>>>> ok cd /pci <at> 1f,4000/ebus <at> 1/eeprom <at> 14,0
>>>> ok .properties
>>>> address                  fffa4000
>>>> reg                      00000014 00000000 00002000
>>>> model                    mk48t59
>>>> name                     eeprom
(Continue reading)

Permalink | Reply | 0 comments |

Gmane