[Qemu-devel] qemu-system-ppc broken ?

[Qemu-devel] qemu-system-ppc broken ?

[François Revol]

Just to let you know it seems the ppc target it broken as of r5643:

$ qemu-system-ppc -M prep -serial stdio -k fr -vnc :8 -hda generated-
ppc-gcc4/haiku.image -cdrom generated-ppc-gcc4/haiku-boot-cd-ppc.iso
/home/revol/devel/qemu/trunk/tcg/tcg.c:1356: tcg fatal error
Abandon

(image isn't bootable yet but at least it didn't crash lots of revs
before)

I'm on debian stable on x86.

François.



I used:

$ ./configure --target-list=i386-softmmu,ppc-softmmu
WARNING: "gcc" looks like gcc 4.x
Looking for gcc 3.x
Found "gcc-3.3"
Install prefix    /usr/local
BIOS directory    /usr/local/share/qemu
binary directory  /usr/local/bin
Manual directory  /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path       /home/revol/devel/qemu/trunk
C compiler        gcc-3.3
Host C compiler   gcc
ARCH_CFLAGS       -m32
make              make
install           install
host CPU          i386
host big endian   no
target list       i386-softmmu ppc-softmmu
gprof enabled     no
sparse enabled    no
profiler          no
static build      no
-Werror enabled   no
SDL support       yes
SDL static link   yes
curses support    yes
mingw32 support   no
Audio drivers     oss
Extra audio cards
Mixer emulation   no
VNC TLS support   no
kqemu support     yes
brlapi support    no
Documentation     no
NPTL support      yes
vde support       no
AIO support       yes
KVM support       no

Re: [Qemu-devel] qemu-system-ppc broken ?

[Aurelien Jarno]

On Fri, Nov 07, 2008 at 04:16:12AM +0100, François Revol wrote:
> Just to let you know it seems the ppc target it broken as of r5643:
> 
> $ qemu-system-ppc -M prep -serial stdio -k fr -vnc :8 -hda generated-
> ppc-gcc4/haiku.image -cdrom generated-ppc-gcc4/haiku-boot-cd-ppc.iso
> /home/revol/devel/qemu/trunk/tcg/tcg.c:1356: tcg fatal error
> Abandon
> 
> (image isn't bootable yet but at least it didn't crash lots of revs
> before)
> 
> I'm on debian stable on x86.
> 

>From what I see, it has been broken in revision 5493. It seems that the
i386 TCG backend is not able to alloc/free a temp variable. The problem 
also occurs when in single step mode, when only *2* temp variables are
allocated. The x86-64 TCG backend is not affected.

The quick and dirty patch below is able to workaround the problem.

Any one has an idea what happens?

diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index a01ff89..f54225c 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -2588,52 +2588,42 @@ GEN_HANDLER(lq, 0x38, 0xFF, 0xFF, 0x00000000, PPC_64BX)
 #define GEN_ST(width, opc, type)                                              \
 GEN_HANDLER(st##width, opc, 0xFF, 0xFF, 0x00000000, type)                     \
 {                                                                             \
-    TCGv EA = tcg_temp_new(TCG_TYPE_TL);                                      \
-    gen_addr_imm_index(EA, ctx, 0);                                           \
-    gen_qemu_st##width(cpu_gpr[rS(ctx->opcode)], EA, ctx->mem_idx);       \
-    tcg_temp_free(EA);                                                        \
+    gen_addr_imm_index(cpu_T[0], ctx, 0);                                           \
+    gen_qemu_st##width(cpu_gpr[rS(ctx->opcode)], cpu_T[0], ctx->mem_idx);       \
 }
 
 #define GEN_STU(width, opc, type)                                             \
 GEN_HANDLER(st##width##u, opc, 0xFF, 0xFF, 0x00000000, type)                  \
 {                                                                             \
-    TCGv EA;                                                                  \
     if (unlikely(rA(ctx->opcode) == 0)) {                                     \
         GEN_EXCP_INVAL(ctx);                                                  \
         return;                                                               \
     }                                                                         \
-    EA = tcg_temp_new(TCG_TYPE_TL);                                           \
     if (type == PPC_64B)                                                      \
-        gen_addr_imm_index(EA, ctx, 0x03);                                    \
+        gen_addr_imm_index(cpu_T[0], ctx, 0x03);                                    \
     else                                                                      \
-        gen_addr_imm_index(EA, ctx, 0);                                       \
-    gen_qemu_st##width(cpu_gpr[rS(ctx->opcode)], EA, ctx->mem_idx);           \
-    tcg_gen_mov_tl(cpu_gpr[rA(ctx->opcode)], EA);                             \
-    tcg_temp_free(EA);                                                        \
+        gen_addr_imm_index(cpu_T[0], ctx, 0);                                       \
+    gen_qemu_st##width(cpu_gpr[rS(ctx->opcode)], cpu_T[0], ctx->mem_idx);           \
+    tcg_gen_mov_tl(cpu_gpr[rA(ctx->opcode)], cpu_T[0]);                             \
 }
 
 #define GEN_STUX(width, opc2, opc3, type)                                     \
 GEN_HANDLER(st##width##ux, 0x1F, opc2, opc3, 0x00000001, type)                \
 {                                                                             \
-    TCGv EA;                                                                  \
     if (unlikely(rA(ctx->opcode) == 0)) {                                     \
         GEN_EXCP_INVAL(ctx);                                                  \
         return;                                                               \
     }                                                                         \
-    EA = tcg_temp_new(TCG_TYPE_TL);                                           \
-    gen_addr_reg_index(EA, ctx);                                              \
-    gen_qemu_st##width(cpu_gpr[rS(ctx->opcode)], EA, ctx->mem_idx);           \
-    tcg_gen_mov_tl(cpu_gpr[rA(ctx->opcode)], EA);                             \
-    tcg_temp_free(EA);                                                        \
+    gen_addr_reg_index(cpu_T[0], ctx);                                              \
+    gen_qemu_st##width(cpu_gpr[rS(ctx->opcode)], cpu_T[0], ctx->mem_idx);           \
+    tcg_gen_mov_tl(cpu_gpr[rA(ctx->opcode)], cpu_T[0]);                             \
 }
 
 #define GEN_STX(width, opc2, opc3, type)                                      \
 GEN_HANDLER(st##width##x, 0x1F, opc2, opc3, 0x00000001, type)                 \
 {                                                                             \
-    TCGv EA = tcg_temp_new(TCG_TYPE_TL);                                      \
-    gen_addr_reg_index(EA, ctx);                                              \
-    gen_qemu_st##width(cpu_gpr[rS(ctx->opcode)], EA, ctx->mem_idx);           \
-    tcg_temp_free(EA);                                                        \
+    gen_addr_reg_index(cpu_T[0], ctx);                                              \
+    gen_qemu_st##width(cpu_gpr[rS(ctx->opcode)], cpu_T[0], ctx->mem_idx);           \
 }
 
 #define GEN_STS(width, op, type)                                              \


-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] qemu-system-ppc broken ?

[François Revol]

> > Just to let you know it seems the ppc target it broken as of r5643:
>
> From what I see, it has been broken in revision 5493. It seems that
> the
> i386 TCG backend is not able to alloc/free a temp variable. The
> problem
> also occurs when in single step mode, when only *2* temp variables
> are
> allocated. The x86-64 TCG backend is not affected.
>
> The quick and dirty patch below is able to workaround the problem.

Indeed, I can confirm it "works" again now. :)

Though I still can't seem to get OpenHackware to read the CD:
ERROR: ATAPI TEST_UNIT_READY : status 50 != 0x40

But that's another story.

> Any one has an idea what happens?

Can't help you there, sorry.

François.

[Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[François Revol]

> Though I still can't seem to get OpenHackware to read the CD:
> ERROR: ATAPI TEST_UNIT_READY : status 50 != 0x40

Replying to myself, it seems this works around the issue, at least it
goes further.
I suppose OpenHackware only compares instead of checking the ready
bit...

Btw, it seems the OH website is gone.
http://perso.magic.fr/l_indien just gives a 403...
For the time being archive.org can be used to dig the sources though:
http://web.archive.org/web/%2a/perso.magic.fr/l_indien/OpenHackWare/%2a

François.


Index: hw/ide.c
===================================================================
--- hw/ide.c	(révision 5643)
+++ hw/ide.c	(copie de travail)
@@ -1088,7 +1088,7 @@
 static void ide_atapi_cmd_ok(IDEState *s)
 {
     s->error = 0;
-    s->status = READY_STAT | SEEK_STAT;
+    s->status = READY_STAT /*| SEEK_STAT*/;
     s->nsector = (s->nsector & ~7) | ATAPI_INT_REASON_IO |
ATAPI_INT_REASON_CD;
     ide_set_irq(s);
 }

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[François Revol]

> > Though I still can't seem to get OpenHackware to read the CD:
> > ERROR: ATAPI TEST_UNIT_READY : status 50 != 0x40
>
> Replying to myself, it seems this works around the issue, at least it
> goes further.
> I suppose OpenHackware only compares instead of checking the ready
> bit...

It seems I'm not the only one:
http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/6937d731e3d4d4a8

I could try to fix the code in OH but I likely don't have the toolchain
required to rebuild it.

François.

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[François Revol]

[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]

> > > Though I still can't seem to get OpenHackware to read the CD:
> > > ERROR: ATAPI TEST_UNIT_READY : status 50 != 0x40
> >
> > Replying to myself, it seems this works around the issue, at least
> > it
> > goes further.
> > I suppose OpenHackware only compares instead of checking the ready
> > bit...
>
> It seems I'm not the only one:
> http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/6937d731e3d4d4a8
> >
> I could try to fix the code in OH but I likely don't have the
> toolchain
> required to rebuild it.
>

Ok...
The attached patch makes OpenHackware happy again.
At least qemu-system-ppc can now start debian iso, and mine as well
(though I had to remove the chrp script as OH only checks the CRC on it
instead of interpreting...)

So now I can debug the bootloader at least.

Just posting it in case someone really urgently needs ppc back, as it's
ugly.

OpenHackware should be fixed instead, but it seems the binary in svn
has been updated after the last sources I found (archive.org has a
mirror of the dead website):
r3309 | j_mayer | 2007-10-01 08:44:33 +0200 (lun, 01 oct 2007) | 2
lines
Quickly hack PowerPC BIOS able to boot on CDROM again.
...
r1354 | bellard | 2005-04-07 01:06:54 +0200 (jeu, 07 avr 2005) | 2
lines
Open Hack'Ware version 0.4.1

Seems the last update was already about ATAPI...
Anyone has the latest source used ?
I could at least fix it to check for bits on errors...

Of course it'd be much better to switch to a real OF instead...
but I don't have the time for that, couldn't find usable OpenBIOS
images, and it sees CoreBoot v2 and v3 don't support ppc yet.

François.


[-- Attachment #2: qemu-openhackware-workaround-r5663.diff.txt --]
[-- Type: text/plain, Size: 2181 bytes --]

Index: hw/ide.c
===================================================================
--- hw/ide.c	(révision 5663)
+++ hw/ide.c	(copie de travail)
@@ -835,7 +835,7 @@
     int64_t sector_num;
     int ret, n;
 
-    s->status = READY_STAT | SEEK_STAT;
+    s->status = READY_STAT | 0/*SEEK_STAT*/;
     s->error = 0; /* not needed by IDE spec, but needed by Windows */
     sector_num = ide_get_sector(s);
     n = s->nsector;
@@ -940,7 +940,7 @@
 
     /* end of transfer ? */
     if (s->nsector == 0) {
-        s->status = READY_STAT | SEEK_STAT;
+        s->status = READY_STAT | 0/*SEEK_STAT*/;
         ide_set_irq(s);
     eot:
         bm->status &= ~BM_STATUS_DMAING;
@@ -1088,7 +1088,7 @@
 static void ide_atapi_cmd_ok(IDEState *s)
 {
     s->error = 0;
-    s->status = READY_STAT | SEEK_STAT;
+    s->status = READY_STAT | 0/*SEEK_STAT*/;
     s->nsector = (s->nsector & ~7) | ATAPI_INT_REASON_IO | ATAPI_INT_REASON_CD;
     ide_set_irq(s);
 }
@@ -1100,6 +1100,7 @@
 #endif
     s->error = sense_key << 4;
     s->status = READY_STAT | ERR_STAT;
+    s->status = DRQ_STAT;
     s->nsector = (s->nsector & ~7) | ATAPI_INT_REASON_IO | ATAPI_INT_REASON_CD;
     s->sense_key = sense_key;
     s->asc = asc;
@@ -1202,7 +1203,7 @@
     if (s->packet_transfer_size <= 0) {
         /* end of transfer */
         ide_transfer_stop(s);
-        s->status = READY_STAT | SEEK_STAT;
+        s->status = READY_STAT | 0/*SEEK_STAT*/;
         s->nsector = (s->nsector & ~7) | ATAPI_INT_REASON_IO | ATAPI_INT_REASON_CD;
         ide_set_irq(s);
 #ifdef DEBUG_IDE_ATAPI
@@ -1280,10 +1281,10 @@
     s->io_buffer_index = 0;
 
     if (s->atapi_dma) {
-    	s->status = READY_STAT | SEEK_STAT | DRQ_STAT;
+    	s->status = READY_STAT | 0/*SEEK_STAT*/ | DRQ_STAT;
 	ide_dma_start(s, ide_atapi_cmd_read_dma_cb);
     } else {
-    	s->status = READY_STAT | SEEK_STAT;
+    	s->status = READY_STAT | 0/*SEEK_STAT*/;
     	ide_atapi_cmd_reply_end(s);
     }
 }
@@ -1298,7 +1299,7 @@
     s->io_buffer_index = sector_size;
     s->cd_sector_size = sector_size;
 
-    s->status = READY_STAT | SEEK_STAT;
+    s->status = READY_STAT | 0/*SEEK_STAT*/;
     ide_atapi_cmd_reply_end(s);
 }
 

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[François Revol]

> The attached patch makes OpenHackware happy again.
> At least qemu-system-ppc can now start debian iso, and mine as well
> (though I had to remove the chrp script as OH only checks the CRC on
> it
> instead of interpreting...)
>
> So now I can debug the bootloader at least.
>
> Just posting it in case someone really urgently needs ppc back, as
> it's
> ugly.

Btw, it works for mac99 and g3bw targets, prep seems still broken.

François.

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[Andreas Färber]

Am 09.11.2008 um 23:07 schrieb François Revol:

>>>> Though I still can't seem to get OpenHackware to read the CD:
>>>> ERROR: ATAPI TEST_UNIT_READY : status 50 != 0x40
>>>
>>> I suppose OpenHackware only compares instead of checking the ready
>>> bit...
>>
>
> The attached patch makes OpenHackware happy again.
> At least qemu-system-ppc can now start debian iso, and mine as well
[...]
> OpenHackware should be fixed instead, but it seems the binary in svn
> has been updated after the last sources I found
[...]
> Seems the last update was already about ATAPI...
> Anyone has the latest source used ?
> I could at least fix it to check for bits on errors...

Rene Rebe recently posted some diff against qemu's OHW diff, but it  
appeared to be whitespace-damaged.

> Of course it'd be much better to switch to a real OF instead...
> but I don't have the time for that, couldn't find usable OpenBIOS
> images,

I once tried to get OpenBIOS working but failed, Laurent appeared to  
get some further - any update on that?

> and it see[m]s CoreBoot v2 and v3 don't support ppc yet.

I believe CoreBoot is unrelated to ppc, it replaces the x86 BIOS. It  
does allow to use OpenBIOS (Open Firmware) as payload but not the  
other direction - Blue Swirl used some assembler wizardry to bootstrap  
the sparc OpenBIOS.

Andreas

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[François Revol]

> > The attached patch makes OpenHackware happy again.
> > At least qemu-system-ppc can now start debian iso, and mine as well
> [...]
> > OpenHackware should be fixed instead, but it seems the binary in
> > svn
> > has been updated after the last sources I found
> [...]
> > Seems the last update was already about ATAPI...
> > Anyone has the latest source used ?
> > I could at least fix it to check for bits on errors...
>
> Rene Rebe recently posted some diff against qemu's OHW diff, but it
> appeared to be whitespace-damaged.

Ohhh, I didn't even notice ohw.diff in pc-bios/ despite looking for
one!
I'll try to dig that one on gmane.org.

I just hope it's easier to build than OpenBIOS...

> > Of course it'd be much better to switch to a real OF instead...
> > but I don't have the time for that, couldn't find usable OpenBIOS
> > images,
>
> I once tried to get OpenBIOS working but failed, Laurent appeared to
> get some further - any update on that?

I tried building it for PPC yesterday, but I only had an powerpc-apple-
haiku- gcc around, and it didn't like it... Even after pointing it to
find our stdint.h and endian.h (WTF does it need OS headers to build a
BIOS ???).
It seems to be doing nasty things with m4 macros on C headers, really
ugly.

> > and it see[m]s CoreBoot v2 and v3 don't support ppc yet.
>
> I believe CoreBoot is unrelated to ppc, it replaces the x86 BIOS. It
> does allow to use OpenBIOS (Open Firmware) as payload but not the
> other direction - Blue Swirl used some assembler wizardry to
> bootstrap
> the sparc OpenBIOS.

CoreBoot actually supports more arch than just x86:
http://www.coreboot.org/Supported_Chipsets_and_Devices

But only v1 seemed to have ppc support.

François.

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[Andreas Färber]

Am 10.11.2008 um 21:27 schrieb François Revol:

>>> Of course it'd be much better to switch to a real OF instead...
>>> but I don't have the time for that, couldn't find usable OpenBIOS
>>> images,
>>
>> I once tried to get OpenBIOS working but failed, Laurent appeared to
>> get some further - any update on that?
>
> I tried building it for PPC yesterday, but I only had an powerpc- 
> apple-
> haiku- gcc around, and it didn't like it... Even after pointing it to
> find our stdint.h and endian.h

Try a Linux (cross-)compiler, I tried natively on Linux/ppc.

> (WTF does it need OS headers to build a
> BIOS ???).

It also builds a version you can execute from the shell.

Andreas

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[François Revol]

> >>> Of course it'd be much better to switch to a real OF instead...
> >>> but I don't have the time for that, couldn't find usable OpenBIOS
> >>> images,
> >>
> >> I once tried to get OpenBIOS working but failed, Laurent appeared
> > > to
> >> get some further - any update on that?
> >
> > I tried building it for PPC yesterday, but I only had an powerpc-
> > apple-
> > haiku- gcc around, and it didn't like it... Even after pointing it
> > to
> > find our stdint.h and endian.h
>
> Try a Linux (cross-)compiler, I tried natively on Linux/ppc.

I don't have a native linux ppc around... and I was too lazy to build
yet another cross gcc

> > (WTF does it need OS headers to build a
> > BIOS ???).
>
> It also builds a version you can execute from the shell.

Hmm right, specifically for a "cross-ppc" named target, really logical
:)

François.

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[Blue Swirl]

Cross-posted to OpenBIOS list.

On 11/10/08, François Revol <revol@free.fr> wrote:
> > >>> Of course it'd be much better to switch to a real OF instead...
>  > >>> but I don't have the time for that, couldn't find usable OpenBIOS
>  > >>> images,
>  > >>
>  > >> I once tried to get OpenBIOS working but failed, Laurent appeared
>  > > > to
>  > >> get some further - any update on that?
>  > >
>  > > I tried building it for PPC yesterday, but I only had an powerpc-
>  > > apple-
>  > > haiku- gcc around, and it didn't like it... Even after pointing it
>  > > to
>  > > find our stdint.h and endian.h
>  >
>  > Try a Linux (cross-)compiler, I tried natively on Linux/ppc.
>
>
> I don't have a native linux ppc around... and I was too lazy to build
>  yet another cross gcc
>
>
>  > > (WTF does it need OS headers to build a
>  > > BIOS ???).
>  >
>  > It also builds a version you can execute from the shell.
>
>
> Hmm right, specifically for a "cross-ppc" named target, really logical
>  :)

I see, Unix version is incorrectly enabled. Should be easy to fix.

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[Andreas Färber]

Am 11.11.2008 um 18:31 schrieb Blue Swirl:

>
>>>> (WTF does it need OS headers to build a
>>>> BIOS ???).
>>>
>>> It also builds a version you can execute from the shell.
>>
>>
>> Hmm right, specifically for a "cross-ppc" named target, really  
>> logical
>> :)
>
> I see, Unix version is incorrectly enabled. Should be easy to fix.

Last time I checked, there was only the cross-ppc config files -  
before you remove the Unix version from the config, please derive a  
copy for native ppc.

Thanks,
Andreas

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[Blue Swirl]

Crossposted to OpenBIOS and Coreboot lists.


On 11/10/08, François Revol <revol@free.fr> wrote:
> > > The attached patch makes OpenHackware happy again.
>  > > At least qemu-system-ppc can now start debian iso, and mine as well
>  > [...]
>  > > OpenHackware should be fixed instead, but it seems the binary in
>  > > svn
>  > > has been updated after the last sources I found
>  > [...]
>  > > Seems the last update was already about ATAPI...
>  > > Anyone has the latest source used ?
>  > > I could at least fix it to check for bits on errors...
>  >
>  > Rene Rebe recently posted some diff against qemu's OHW diff, but it
>  > appeared to be whitespace-damaged.
>
>
> Ohhh, I didn't even notice ohw.diff in pc-bios/ despite looking for
>  one!
>  I'll try to dig that one on gmane.org.
>
>  I just hope it's easier to build than OpenBIOS...
>
>
>  > > Of course it'd be much better to switch to a real OF instead...
>  > > but I don't have the time for that, couldn't find usable OpenBIOS
>  > > images,
>  >
>  > I once tried to get OpenBIOS working but failed, Laurent appeared to
>  > get some further - any update on that?
>
>
> I tried building it for PPC yesterday, but I only had an powerpc-apple-
>  haiku- gcc around, and it didn't like it... Even after pointing it to
>  find our stdint.h and endian.h (WTF does it need OS headers to build a
>  BIOS ???).
>  It seems to be doing nasty things with m4 macros on C headers, really
>  ugly.

The M4 macro nastiness seems to be limited to the asm files only and
even then the macros  are not used. It should be possible to remove
the macros with little effort.

Maybe they are a leftover from something earlier?

>  > > and it see[m]s CoreBoot v2 and v3 don't support ppc yet.
>  >
>  > I believe CoreBoot is unrelated to ppc, it replaces the x86 BIOS. It
>  > does allow to use OpenBIOS (Open Firmware) as payload but not the
>  > other direction - Blue Swirl used some assembler wizardry to
>  > bootstrap
>  > the sparc OpenBIOS.
>
>
> CoreBoot actually supports more arch than just x86:
>  http://www.coreboot.org/Supported_Chipsets_and_Devices
>
>  But only v1 seemed to have ppc support.

Perhaps PPC support can be revived?

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[Laurent Vivier]

Le lundi 10 novembre 2008 à 21:01 +0100, Andreas Färber a écrit :
> Am 09.11.2008 um 23:07 schrieb François Revol:
> 
> >>>> Though I still can't seem to get OpenHackware to read the CD:
> >>>> ERROR: ATAPI TEST_UNIT_READY : status 50 != 0x40
> >>>
> >>> I suppose OpenHackware only compares instead of checking the ready
> >>> bit...
> >>
> >
> > The attached patch makes OpenHackware happy again.
> > At least qemu-system-ppc can now start debian iso, and mine as well
> [...]
> > OpenHackware should be fixed instead, but it seems the binary in svn
> > has been updated after the last sources I found
> [...]
> > Seems the last update was already about ATAPI...
> > Anyone has the latest source used ?
> > I could at least fix it to check for bits on errors...
> 
> Rene Rebe recently posted some diff against qemu's OHW diff, but it  
> appeared to be whitespace-damaged.
> 
> > Of course it'd be much better to switch to a real OF instead...
> > but I don't have the time for that, couldn't find usable OpenBIOS
> > images,
> 
> I once tried to get OpenBIOS working but failed, Laurent appeared to  
> get some further - any update on that?

No, I stopped working on this because I had no time.

In fact, if I remember correctly, OpenHW initializes PCI devices whereas
OpenBIOS doesn't, I've started working on this but it is too much work
form me. I had a working OpenBIOS, able to start a kernel (at some
time), but stopping during boot.

If someone is interested (perhaps) I can find my patches and send them
(privately).

> > and it see[m]s CoreBoot v2 and v3 don't support ppc yet.
> 
> I believe CoreBoot is unrelated to ppc, it replaces the x86 BIOS. It  
> does allow to use OpenBIOS (Open Firmware) as payload but not the  
> other direction - Blue Swirl used some assembler wizardry to bootstrap  
> the sparc OpenBIOS.

Regards,
Laurent
-- 
------------------ Laurent.Vivier@bull.net  ------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[Blue Swirl]

On 11/11/08, Laurent Vivier <Laurent.Vivier@bull.net> wrote:
> Le lundi 10 novembre 2008 à 21:01 +0100, Andreas Färber a écrit :
>
> > Am 09.11.2008 um 23:07 schrieb François Revol:
>  >
>  > >>>> Though I still can't seem to get OpenHackware to read the CD:
>  > >>>> ERROR: ATAPI TEST_UNIT_READY : status 50 != 0x40
>  > >>>
>  > >>> I suppose OpenHackware only compares instead of checking the ready
>  > >>> bit...
>  > >>
>  > >
>  > > The attached patch makes OpenHackware happy again.
>  > > At least qemu-system-ppc can now start debian iso, and mine as well
>  > [...]
>  > > OpenHackware should be fixed instead, but it seems the binary in svn
>  > > has been updated after the last sources I found
>  > [...]
>  > > Seems the last update was already about ATAPI...
>  > > Anyone has the latest source used ?
>  > > I could at least fix it to check for bits on errors...
>  >
>  > Rene Rebe recently posted some diff against qemu's OHW diff, but it
>  > appeared to be whitespace-damaged.
>  >
>  > > Of course it'd be much better to switch to a real OF instead...
>  > > but I don't have the time for that, couldn't find usable OpenBIOS
>  > > images,
>  >
>  > I once tried to get OpenBIOS working but failed, Laurent appeared to
>  > get some further - any update on that?
>
>
> No, I stopped working on this because I had no time.
>
>  In fact, if I remember correctly, OpenHW initializes PCI devices whereas
>  OpenBIOS doesn't, I've started working on this but it is too much work
>  form me. I had a working OpenBIOS, able to start a kernel (at some
>  time), but stopping during boot.
>
>  If someone is interested (perhaps) I can find my patches and send them
>  (privately).

I would be interested. I finally created a PowerPC cross compiler and
I'd like to test OpenBIOS for PPC.

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[Laurent Vivier]

Le 16 nov. 08 à 20:32, Blue Swirl a écrit :

> On 11/11/08, Laurent Vivier <Laurent.Vivier@bull.net> wrote:
>> Le lundi 10 novembre 2008 à 21:01 +0100, Andreas Färber a écrit :
>>
>>> Am 09.11.2008 um 23:07 schrieb François Revol:
>>>
>>>>>>> Though I still can't seem to get OpenHackware to read the CD:
>>>>>>> ERROR: ATAPI TEST_UNIT_READY : status 50 != 0x40
>>>>>>
>>>>>> I suppose OpenHackware only compares instead of checking the  
>>>>>> ready
>>>>>> bit...
>>>>>
>>>>
>>>> The attached patch makes OpenHackware happy again.
>>>> At least qemu-system-ppc can now start debian iso, and mine as well
>>> [...]
>>>> OpenHackware should be fixed instead, but it seems the binary in  
>>>> svn
>>>> has been updated after the last sources I found
>>> [...]
>>>> Seems the last update was already about ATAPI...
>>>> Anyone has the latest source used ?
>>>> I could at least fix it to check for bits on errors...
>>>
>>> Rene Rebe recently posted some diff against qemu's OHW diff, but it
>>> appeared to be whitespace-damaged.
>>>
>>>> Of course it'd be much better to switch to a real OF instead...
>>>> but I don't have the time for that, couldn't find usable OpenBIOS
>>>> images,
>>>
>>> I once tried to get OpenBIOS working but failed, Laurent appeared to
>>> get some further - any update on that?
>>
>>
>> No, I stopped working on this because I had no time.
>>
>> In fact, if I remember correctly, OpenHW initializes PCI devices  
>> whereas
>> OpenBIOS doesn't, I've started working on this but it is too much  
>> work
>> form me. I had a working OpenBIOS, able to start a kernel (at some
>> time), but stopping during boot.
>>
>> If someone is interested (perhaps) I can find my patches and send  
>> them
>> (privately).
>
> I would be interested. I finally created a PowerPC cross compiler and
> I'd like to test OpenBIOS for PPC.

Yes, Andreas had the same request.
For the moment I'm trying to re-create a cross-compiler to test and  
sort my patches.

Regards,
Laurent

-------------------- laurent@lvivier.info --------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]

On 11/16/08, Laurent Vivier <laurent@lvivier.info> wrote:
>
>  Le 16 nov. 08 à 20:32, Blue Swirl a écrit :
>
>
>
> > On 11/11/08, Laurent Vivier <Laurent.Vivier@bull.net> wrote:
> >
> > > Le lundi 10 novembre 2008 à 21:01 +0100, Andreas Färber a écrit :
> > >
> > >
> > > > Am 09.11.2008 um 23:07 schrieb François Revol:
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > > Though I still can't seem to get OpenHackware to read the CD:
> > > > > > > > ERROR: ATAPI TEST_UNIT_READY : status 50 != 0x40
> > > > > > > >
> > > > > > >
> > > > > > > I suppose OpenHackware only compares instead of checking the
> ready
> > > > > > > bit...
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > The attached patch makes OpenHackware happy again.
> > > > > At least qemu-system-ppc can now start debian iso, and mine as well
> > > > >
> > > > [...]
> > > >
> > > > > OpenHackware should be fixed instead, but it seems the binary in svn
> > > > > has been updated after the last sources I found
> > > > >
> > > > [...]
> > > >
> > > > > Seems the last update was already about ATAPI...
> > > > > Anyone has the latest source used ?
> > > > > I could at least fix it to check for bits on errors...
> > > > >
> > > >
> > > > Rene Rebe recently posted some diff against qemu's OHW diff, but it
> > > > appeared to be whitespace-damaged.
> > > >
> > > >
> > > > > Of course it'd be much better to switch to a real OF instead...
> > > > > but I don't have the time for that, couldn't find usable OpenBIOS
> > > > > images,
> > > > >
> > > >
> > > > I once tried to get OpenBIOS working but failed, Laurent appeared to
> > > > get some further - any update on that?
> > > >
> > >
> > >
> > > No, I stopped working on this because I had no time.
> > >
> > > In fact, if I remember correctly, OpenHW initializes PCI devices whereas
> > > OpenBIOS doesn't, I've started working on this but it is too much work
> > > form me. I had a working OpenBIOS, able to start a kernel (at some
> > > time), but stopping during boot.
> > >
> > > If someone is interested (perhaps) I can find my patches and send them
> > > (privately).
> > >
> >
> > I would be interested. I finally created a PowerPC cross compiler and
> > I'd like to test OpenBIOS for PPC.
> >
>
>  Yes, Andreas had the same request.
>  For the moment I'm trying to re-create a cross-compiler to test and sort my
> patches.

With the attached hack I'm able to boot
debian-40r5-powerpc-businesscard.iso, though it hangs after:
Calling quiesce ...
returning from prom_init

The same happens with 0.8.2, so I think Qemu is in a way "correct".
Now all I need to do is to find a nice OS that really can be
installed. Any suggestions?

[-- Attachment #2: ohw_ide_hack.diff --]
[-- Type: plain/text, Size: 5920 bytes --]

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[René Rebe]

Blue Swirl wrote:
> On 11/16/08, Laurent Vivier <laurent@lvivier.info> wrote:
>   
>>  Le 16 nov. 08 à 20:32, Blue Swirl a écrit :
>>
>>
>>
>>     
>>> On 11/11/08, Laurent Vivier <Laurent.Vivier@bull.net> wrote:
>>>
>>>       
>>>> Le lundi 10 novembre 2008 à 21:01 +0100, Andreas Färber a écrit :
>>>>
>>>>
>>>>         
>>>>> Am 09.11.2008 um 23:07 schrieb François Revol:
>>>>>
>>>>>
>>>>>           
>>>>>>>>> Though I still can't seem to get OpenHackware to read the CD:
>>>>>>>>> ERROR: ATAPI TEST_UNIT_READY : status 50 != 0x40
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> I suppose OpenHackware only compares instead of checking the
>>>>>>>>                 
>> ready
>>     
>>>>>>>> bit...
>>>>>>>>
>>>>>>>>                 
>>>>>>>               
>>>>>> The attached patch makes OpenHackware happy again.
>>>>>> At least qemu-system-ppc can now start debian iso, and mine as well
>>>>>>
>>>>>>             
>>>>> [...]
>>>>>
>>>>>           
>>>>>> OpenHackware should be fixed instead, but it seems the binary in svn
>>>>>> has been updated after the last sources I found
>>>>>>
>>>>>>             
>>>>> [...]
>>>>>
>>>>>           
>>>>>> Seems the last update was already about ATAPI...
>>>>>> Anyone has the latest source used ?
>>>>>> I could at least fix it to check for bits on errors...
>>>>>>
>>>>>>             
>>>>> Rene Rebe recently posted some diff against qemu's OHW diff, but it
>>>>> appeared to be whitespace-damaged.
>>>>>
>>>>>
>>>>>           
>>>>>> Of course it'd be much better to switch to a real OF instead...
>>>>>> but I don't have the time for that, couldn't find usable OpenBIOS
>>>>>> images,
>>>>>>
>>>>>>             
>>>>> I once tried to get OpenBIOS working but failed, Laurent appeared to
>>>>> get some further - any update on that?
>>>>>
>>>>>           
>>>> No, I stopped working on this because I had no time.
>>>>
>>>> In fact, if I remember correctly, OpenHW initializes PCI devices whereas
>>>> OpenBIOS doesn't, I've started working on this but it is too much work
>>>> form me. I had a working OpenBIOS, able to start a kernel (at some
>>>> time), but stopping during boot.
>>>>
>>>> If someone is interested (perhaps) I can find my patches and send them
>>>> (privately).
>>>>
>>>>         
>>> I would be interested. I finally created a PowerPC cross compiler and
>>> I'd like to test OpenBIOS for PPC.
>>>
>>>       
>>  Yes, Andreas had the same request.
>>  For the moment I'm trying to re-create a cross-compiler to test and sort my
>> patches.
>>     
>
> With the attached hack I'm able to boot
> debian-40r5-powerpc-businesscard.iso, though it hangs after:
> Calling quiesce ...
> returning from prom_init
>
> The same happens with 0.8.2, so I think Qemu is in a way "correct".
> Now all I need to do is to find a nice OS that really can be
> installed. Any suggestions?
>   
That's probably due:

 > Second, Linux 2.6 flatten_device_tree stuff in 
arch/powerpc/kernel/prom_init.c
 > check for a return value of 1, as I do not have the IEEE spec on my desk
 > I assumed it means success, and with the change the flattened device
 > tree is no longer empty, helping a great deal continuing to boot ...

As I reported and provided a patch for on 05/06/2008 06:00 PM.
[Qemu-devel] [PATCH] fix PPC OpenHackWare for Linux 2.6

Yours,
  Rene

-- 
  René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[Andreas Färber]

Am 24.11.2008 um 09:34 schrieb René Rebe:

> Blue Swirl wrote:
>> With the attached hack I'm able to boot
>> debian-40r5-powerpc-businesscard.iso, though it hangs after:
>> Calling quiesce ...
>> returning from prom_init
>>
>> The same happens with 0.8.2, so I think Qemu is in a way "correct".
>> Now all I need to do is to find a nice OS that really can be
>> installed. Any suggestions?
>>
> That's probably due:
>
> > Second, Linux 2.6 flatten_device_tree stuff in arch/powerpc/kernel/ 
> prom_init.c
> > check for a return value of 1, as I do not have the IEEE spec on  
> my desk
> > I assumed it means success, and with the change the flattened device
> > tree is no longer empty, helping a great deal continuing to boot ...
>
> As I reported and provided a patch for on 05/06/2008 06:00 PM.
> [Qemu-devel] [PATCH] fix PPC OpenHackWare for Linux 2.6

Your patch unfortunately seemed whitespace-damaged, it did not apply  
for me.
If it contains further fixes, could you please resubmit it?

Regards,
Andreas

Re: [Qemu-devel] atapi on ppc issue (was Re: qemu-system-ppc broken ?)

[Shin-ichiro KAWASAKI]

Blue Swirl wrote:
> With the attached hack I'm able to boot
> debian-40r5-powerpc-businesscard.iso, though it hangs after:
> Calling quiesce ...
> returning from prom_init
> 
> The same happens with 0.8.2, so I think Qemu is in a way "correct".
> Now all I need to do is to find a nice OS that really can be
> installed. Any suggestions?

I tried debian-31r8-powerpc-binary-1.iso.  Even though it can't
complete installation, it can go farther.  It's available here.

http://riksun.riken.go.jp/pub/pub/Linux/debian/debian-cdimage/archive/3.1_r8/powerpc/iso-cd/

Don't forget to choose 2.4 kernel installation menu on the boot prompt,
because 2.6 kernel seems to fail to boot.  Rene's patch might solve it.
The menu 'expert-2.4' worked for me. 

It took half an hour to complete installation, but rebooting
from HDD fails.  Yaboot dumps something like configuration file and
says 'Unable to load boot file'.  Does anyone have suggestions to
solve this problem?

I tried debian-31r8-powerpc-businesscard.iso, also.  It requires
ftp site to download packages for network installation. But
there exists no site for debian-3x and installation fails.

I hope this report help works on ppc.


Regards,
Shin-ichiro KAWASAKI

Re: [Qemu-devel] qemu-system-ppc broken ?

[Laurent Desnogues]

[-- Attachment #1: Type: text/plain, Size: 416 bytes --]

On Fri, Nov 7, 2008 at 8:08 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
>
> Any one has an idea what happens?

It looks like the i386 runs out of registers for allocation due
to too many global registers allocated by the ppc target.

Here is a quick and dirty fix that seems to solve the problem.
This should be considered as temporary.


Laurent

Signed-off-by: Laurent Desnogues <laurent.desnogues@gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ppc-i386.patch --]
[-- Type: text/x-patch; name=ppc-i386.patch, Size: 1534 bytes --]

Index: target-ppc/cpu.h
===================================================================
--- target-ppc/cpu.h	(revision 5645)
+++ target-ppc/cpu.h	(working copy)
@@ -530,8 +530,12 @@
      * during translated code execution
      */
 #if TARGET_LONG_BITS > HOST_LONG_BITS
-    target_ulong t0, t1, t2;
+    target_ulong t0, t1;
 #endif
+     /* XXX: this is a temporary workaround for i386. cf translate.c comment */
+#if (TARGET_LONG_BITS > HOST_LONG_BITS) || defined(HOST_I386)
+    target_ulong t2;
+#endif
 #if !defined(TARGET_PPC64)
     /* temporary fixed-point registers
      * used to emulate 64 bits registers on 32 bits targets
Index: target-ppc/translate.c
===================================================================
--- target-ppc/translate.c	(revision 5645)
+++ target-ppc/translate.c	(working copy)
@@ -97,8 +97,17 @@
 #else
     cpu_T[0] = tcg_global_reg_new(TCG_TYPE_TL, TCG_AREG1, "T0");
     cpu_T[1] = tcg_global_reg_new(TCG_TYPE_TL, TCG_AREG2, "T1");
+#ifdef HOST_I386
+    /* XXX: This is a temporary workaround for i386.
+     *      On i386 qemu_st32 runs out of registers.
+     *      The proper fix is to remove cpu_T.
+     */
+    cpu_T[2] = tcg_global_mem_new(TCG_TYPE_TL,
+                                  TCG_AREG0, offsetof(CPUState, t2), "T2");
+#else
     cpu_T[2] = tcg_global_reg_new(TCG_TYPE_TL, TCG_AREG3, "T2");
 #endif
+#endif
 #if !defined(TARGET_PPC64)
     cpu_T64[0] = tcg_global_mem_new(TCG_TYPE_I64,
                                     TCG_AREG0, offsetof(CPUState, t0_64),

Re: [Qemu-devel] qemu-system-ppc broken ?

[Aurelien Jarno]

On Fri, Nov 07, 2008 at 05:38:32PM +0100, Laurent Desnogues wrote:
> On Fri, Nov 7, 2008 at 8:08 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> >
> > Any one has an idea what happens?
> 
> It looks like the i386 runs out of registers for allocation due
> to too many global registers allocated by the ppc target.
> 
> Here is a quick and dirty fix that seems to solve the problem.
> This should be considered as temporary.
> 

Thanks, applied.

> Laurent
> 
> Signed-off-by: Laurent Desnogues <laurent.desnogues@gmail.com>

> Index: target-ppc/cpu.h
> ===================================================================
> --- target-ppc/cpu.h	(revision 5645)
> +++ target-ppc/cpu.h	(working copy)
> @@ -530,8 +530,12 @@
>       * during translated code execution
>       */
>  #if TARGET_LONG_BITS > HOST_LONG_BITS
> -    target_ulong t0, t1, t2;
> +    target_ulong t0, t1;
>  #endif
> +     /* XXX: this is a temporary workaround for i386. cf translate.c comment */
> +#if (TARGET_LONG_BITS > HOST_LONG_BITS) || defined(HOST_I386)
> +    target_ulong t2;
> +#endif
>  #if !defined(TARGET_PPC64)
>      /* temporary fixed-point registers
>       * used to emulate 64 bits registers on 32 bits targets
> Index: target-ppc/translate.c
> ===================================================================
> --- target-ppc/translate.c	(revision 5645)
> +++ target-ppc/translate.c	(working copy)
> @@ -97,8 +97,17 @@
>  #else
>      cpu_T[0] = tcg_global_reg_new(TCG_TYPE_TL, TCG_AREG1, "T0");
>      cpu_T[1] = tcg_global_reg_new(TCG_TYPE_TL, TCG_AREG2, "T1");
> +#ifdef HOST_I386
> +    /* XXX: This is a temporary workaround for i386.
> +     *      On i386 qemu_st32 runs out of registers.
> +     *      The proper fix is to remove cpu_T.
> +     */
> +    cpu_T[2] = tcg_global_mem_new(TCG_TYPE_TL,
> +                                  TCG_AREG0, offsetof(CPUState, t2), "T2");
> +#else
>      cpu_T[2] = tcg_global_reg_new(TCG_TYPE_TL, TCG_AREG3, "T2");
>  #endif
> +#endif
>  #if !defined(TARGET_PPC64)
>      cpu_T64[0] = tcg_global_mem_new(TCG_TYPE_I64,
>                                      TCG_AREG0, offsetof(CPUState, t0_64),


-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net