[Qemu-devel] First OOPS

[Qemu-devel] First OOPS

[Laurent Vivier]

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

Hi,

I've got my first oops under linux booted with OpenBIOS.

The kernel (2.6.28-rc9) was hanging into probe_machine() because it  
didn't recognize the machine.

The following patch correct this:

---
  arch/ppc/qemu/tree.fs |    1 +
  1 file changed, 1 insertion(+)

Index: openbios-devel/arch/ppc/qemu/tree.fs
===================================================================
--- openbios-devel.orig/arch/ppc/qemu/tree.fs	2008-12-22  
00:32:26.000000000 +0100
+++ openbios-devel/arch/ppc/qemu/tree.fs	2008-12-22 00:32:31.000000000  
+0100
@@ -15,6 +15,7 @@

  " chrp" device-type
  " OpenSource,QEMU" model
+" Power Macintosh" encode-string " compatible" property
  1 encode-int " #interrupt-cells" property
  1 encode-int " #size-cells" property


[-- Attachment #2: qemu-linux --]
[-- Type: application/octet-stream, Size: 547 bytes --]

---
 arch/ppc/qemu/tree.fs |    1 +
 1 file changed, 1 insertion(+)

Index: openbios-devel/arch/ppc/qemu/tree.fs
===================================================================
--- openbios-devel.orig/arch/ppc/qemu/tree.fs	2008-12-22 00:32:26.000000000 +0100
+++ openbios-devel/arch/ppc/qemu/tree.fs	2008-12-22 00:32:31.000000000 +0100
@@ -15,6 +15,7 @@
 
 " chrp" device-type
 " OpenSource,QEMU" model
+" Power Macintosh" encode-string " compatible" property
 1 encode-int " #interrupt-cells" property
 1 encode-int " #size-cells" property
 

[-- Attachment #3: Type: text/plain, Size: 57 bytes --]




BTW tree.fs needs more cleanup...

Some screenshots:


[-- Attachment #4: Capture-QEMU-1.png --]
[-- Type: image/png, Size: 29103 bytes --]

[-- Attachment #5: Type: text/plain, Size: 23 bytes --]




and after a while:


[-- Attachment #6: Capture-QEMU-2.png --]
[-- Type: image/png, Size: 30919 bytes --]

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

[Qemu-devel] First OOPS ARM User Mode

[Martin Mohring]

Hi,

I tracked down that one commit between svn trunk -r 6082 and svn trunk
-r 6098 causes the ARM user mode to fail with:

qemu: uncaught target signal 11 (Segmentation fault) - exiting

svn trunk -r 6082 was the last revision working, 6098 was the first
found not to be working. I have not tracked it down more precise which
commit between the two caused it.


Martin

[Qemu-devel] Re: First OOPS

[Blue Swirl]

On 12/22/08, Laurent Vivier <laurent@lvivier.info> wrote:
> Hi,
>
>  I've got my first oops under linux booted with OpenBIOS.
>
>  The kernel (2.6.28-rc9) was hanging into probe_machine() because it didn't
> recognize the machine.
>
>  The following patch correct this:

Thanks, applied as r305.

What kernel and command line have you been using? None of the install
CD images I have tried are able to boot at all.

Re: [Qemu-devel] First OOPS ARM User Mode

[Laurent Desnogues]

On Mon, Dec 22, 2008 at 1:17 AM, Martin Mohring
<martin.mohring@opensuse.org> wrote:
>
> I tracked down that one commit between svn trunk -r 6082 and svn trunk
> -r 6098 causes the ARM user mode to fail with:
>
> qemu: uncaught target signal 11 (Segmentation fault) - exiting
>
> svn trunk -r 6082 was the last revision working, 6098 was the first
> found not to be working. I have not tracked it down more precise which
> commit between the two caused it.

You'll have to provide more details than that.  For me svn head works
for the few tests I ran (hello world, some SPEC2k tests).

So:
   - provide a small test
   - how did you configure qemu
   - what cross compiler did you use
   - how do you invoke qemu


Laurent

[Qemu-devel] Re: First OOPS

[Laurent Vivier]

Le 22 déc. 08 à 07:22, Blue Swirl a écrit :

> On 12/22/08, Laurent Vivier <laurent@lvivier.info> wrote:
>> Hi,
>>
>> I've got my first oops under linux booted with OpenBIOS.
>>
>> The kernel (2.6.28-rc9) was hanging into probe_machine() because it  
>> didn't
>> recognize the machine.
>>
>> The following patch correct this:
>
> Thanks, applied as r305.
>
> What kernel and command line have you been using? None of the install
> CD images I have tried are able to boot at all.


In fact, I've installed a debian sarge on an external disk drive with  
my iBook G4 and I use this image with qemu.

Then I cross-compile a linux kernel from GIT and I use yaboot (I've  
compiled it on x86_64) to update the disk image:

kpartx -a sarge-ppc.img
mount /dev/mapper/loop0p3 mnt
cp linux-2.6/vmlinux mnt/boot/vmlinux-2.6-test
sudo umount mnt
yaboot-1.3.14/ybin/ybin -o hd:2 -b /dev/mapper/loop0p2 --config  
yaboot.conf --nonvram
kpartx -d /dev/loop0

My yaboot.conf is:

boot=/dev/hda2
device=hd:
partition=3
root=/dev/hda3
timeout=5000
install=yaboot-1.3.14/second/yaboot
magicboot=yaboot-1.3.14/first/ofboot
enablecdboot

image=/boot/vmlinux-2.6-test
	label=Linux-test
	read-only
	append="console=ttyS0"

image=/boot/vmlinux
	label=Linux
	read-only
	initrd=/boot/initrd.img
	append="console=ttyS0"

image=/boot/vmlinux.old
	label=old
	read-only
	initrd=/boot/initrd.img.old

On an install CD there is a forth script which start yaboot with good  
parameters but currently OpenBIOS is not able to decode this script  
(inside XML tags).

Regards,
Laurent
----------------------- Laurent Vivier ----------------------
"The best way to predict the future is to invent it."
- Alan Kay

[Qemu-devel] Re: First OOPS

[Blue Swirl]

On 12/22/08, Laurent Vivier <laurent@lvivier.info> wrote:
>  On an install CD there is a forth script which start yaboot with good
> parameters but currently OpenBIOS is not able to decode this script (inside
> XML tags).

Did OHW ever handle this?

[Qemu-devel] Re: First OOPS

[Laurent Vivier]

Le 22 déc. 08 à 12:20, Blue Swirl a écrit :

> On 12/22/08, Laurent Vivier <laurent@lvivier.info> wrote:
>> On an install CD there is a forth script which start yaboot with good
>> parameters but currently OpenBIOS is not able to decode this script  
>> (inside
>> XML tags).
>
> Did OHW ever handle this?

It does, but it is a hack: it computes the checksum of the script to  
identify it, and according the checksum the things to do are hardcoded  
into OHW.

You have a big "switch()" and a "case" for each known script (for  
instance "debian etch install CD", "debian sarge install CD", etc).

Regards,
Laurent
----------------------- Laurent Vivier ----------------------
"The best way to predict the future is to invent it."
- Alan Kay

[Qemu-devel] Re: First OOPS

[Blue Swirl]

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

On 12/22/08, Laurent Vivier <laurent@lvivier.info> wrote:
>
>  Le 22 déc. 08 à 12:20, Blue Swirl a écrit :
>
>
>
> > On 12/22/08, Laurent Vivier <laurent@lvivier.info> wrote:
> >
> > > On an install CD there is a forth script which start yaboot with good
> > > parameters but currently OpenBIOS is not able to decode this script
> (inside
> > > XML tags).
> > >
> >
> > Did OHW ever handle this?
> >
>
>  It does, but it is a hack: it computes the checksum of the script to
> identify it, and according the checksum the things to do are hardcoded into
> OHW.
>
>  You have a big "switch()" and a "case" for each known script (for instance
> "debian etch install CD", "debian sarge install CD", etc).

Well, it wasn't that hard. The patch o_2_use_bootinfo.diff adds
parsing of CHRP file ppc\bootinfo.txt. Still, the loaded yaboot does
not work. Maybe a problem with ELF loader?

I've shuffled the patch series a bit, so here are all pending patches.
Would anyone mind if I applied them?

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

[-- Attachment #3: q_2_ppc_use_prom_env.diff --]
[-- Type: plain/text, Size: 4414 bytes --]

[-- Attachment #4: q_3_ppc_use_fw_cfg.diff --]
[-- Type: plain/text, Size: 1222 bytes --]

[-- Attachment #5: o_1_ppc_add_boot.diff --]
[-- Type: plain/text, Size: 3628 bytes --]

[-- Attachment #6: o_2_use_bootinfo.diff --]
[-- Type: plain/text, Size: 3279 bytes --]

[-- Attachment #7: o_3_ppc_use_fw_cfg.diff --]
[-- Type: plain/text, Size: 5114 bytes --]

[Qemu-devel] Re: First OOPS

[Laurent Vivier]

Le 22 déc. 08 à 17:23, Blue Swirl a écrit :

> On 12/22/08, Laurent Vivier <laurent@lvivier.info> wrote:
>>
>> Le 22 déc. 08 à 12:20, Blue Swirl a écrit :
>>
>>
>>
>>> On 12/22/08, Laurent Vivier <laurent@lvivier.info> wrote:
>>>
>>>> On an install CD there is a forth script which start yaboot with  
>>>> good
>>>> parameters but currently OpenBIOS is not able to decode this script
>> (inside
>>>> XML tags).
>>>>
>>>
>>> Did OHW ever handle this?
>>>
>>
>> It does, but it is a hack: it computes the checksum of the script to
>> identify it, and according the checksum the things to do are  
>> hardcoded into
>> OHW.
>>
>> You have a big "switch()" and a "case" for each known script (for  
>> instance
>> "debian etch install CD", "debian sarge install CD", etc).
>
> Well, it wasn't that hard. The patch o_2_use_bootinfo.diff adds
> parsing of CHRP file ppc\bootinfo.txt. Still, the loaded yaboot does
> not work. Maybe a problem with ELF loader?
>
> I've shuffled the patch series a bit, so here are all pending patches.
> Would anyone mind if I applied them?
> < 
> q_1_ppc_openbios 
> .diff 
> > 
> < 
> q_2_ppc_use_prom_env 
> .diff 
> > 
> < 
> q_3_ppc_use_fw_cfg 
> .diff 
> > 
> < 
> o_1_ppc_add_boot.diff><o_2_use_bootinfo.diff><o_3_ppc_use_fw_cfg.diff>


I don't totally agree with some of them, but it is a good start and  
all are really needed, so please apply...

Regards,
Laurent
----------------------- Laurent Vivier ----------------------
"The best way to predict the future is to invent it."
- Alan Kay

Re: [Qemu-devel] First OOPS ARM User Mode

[Martin Mohring]

Laurent Desnogues wrote:
> On Mon, Dec 22, 2008 at 1:17 AM, Martin Mohring
> <martin.mohring@opensuse.org> wrote:
>   
>> I tracked down that one commit between svn trunk -r 6082 and svn trunk
>> -r 6098 causes the ARM user mode to fail with:
>>
>> qemu: uncaught target signal 11 (Segmentation fault) - exiting
>>
>> svn trunk -r 6082 was the last revision working, 6098 was the first
>> found not to be working. I have not tracked it down more precise which
>> commit between the two caused it.
>>     
>
> You'll have to provide more details than that.  For me svn head works
> for the few tests I ran (hello world, some SPEC2k tests).
>
> So:
>    - provide a small test
>    - how did you configure qemu
>    - what cross compiler did you use
>    - how do you invoke qemu
>
>   
I had discussed that with Laurent already.

I have now tracked the problem down to svn commit -r 6095. E.g. qemu svn
trunk -r 6094 works, 6095 not. I try to find the command that fails and
extract exactly those needed.