Re: [OpenBIOS] [sparc64] Problematic pci at 0 and pci nodes in the device tree

[Mark Cave-Ayland]

> Hi,
>
> I have the following problem with the OpenBIOS device tree (the
> current Qemu version):
> In the root directory, there are currently two pci nodes:
>
> ffd97778 pci at 0
> ffd98808 pci
>
> The "screen" alias is defined as:
> /pci/pci/pci/QEMU,VGA
>
> When HelenOS attempts to lookup this path, it fails, because it
> matches /pci instead of /pci at 0 and /pci does not have any

children. > HelenOS is normally designed to cope with ambiguous node 
names, but in > this case the /pci node matches and sends it to the 
wrong direction. I > think the "screen" alias should be either defined 
using the
> non-ambiguous pci at 0 path components or the /pci node should not
> exist at all.
>
> Can you confirm this is a problem in the tree?

Hi Jakub,

I too am interested in getting Sparc64 working in Qemu in order to 
resurrect some old Solaris disk images I have here. Can you explain some 
more about the debugging methods you are using to analyse the forth 
dictionaries?

At the moment I am struggling in that when running Qemu with "-vnc :1" 
on the command line, qemu-system-sparc64 simply hangs :(

Many thanks,

Mark.

[sparc64] Problematic pci at 0 and pci nodes in the device tree

[Jakub Jermar]

Hi Mark,

Mark Cave-Ayland wrote:
> I too am interested in getting Sparc64 working in Qemu in order to 
> resurrect some old Solaris disk images I have here. Can you explain some 
> more about the debugging methods you are using to analyse the forth 
> dictionaries?

I don't inspect the forth dictionaries directly because I am not strong
in Forth. I used indirect methods like starting the sparc64 qemu without
specifying the boot device and then manually navigating myself in the
OpenBIOS device tree using the standard commands such as dev / ls and
.properties.

The other method was printing the device tree nodes and their properties
as they were discovered by the HelenOS boot loader. The loader uses the
client interface provided by OpenBIOS both to learn about those nodes
and properties and also to print them.

In the case of this particular problem, I simply noticed that the path
used by the screen alias was too ambiguous and the /pci node looked
strange and didn't have any children.

Jakub

[sparc64] Problematic pci at 0 and pci nodes in the device tree

[Mark Cave-Ayland]

Jakub Jermar wrote:
> I don't inspect the forth dictionaries directly because I am not strong
> in Forth. I used indirect methods like starting the sparc64 qemu without
> specifying the boot device and then manually navigating myself in the
> OpenBIOS device tree using the standard commands such as dev / ls and
> .properties.

Ah I see. Can I ask which options you are using to start 
qemu-system-sparc64? If I start with "-nographic" then the system 
starts, but when the boot process stops with an error, the console 
freezes and I cannot manually enter forth commands.

If I use "-vnc :1" on qemu-system-sparc then when the boot fails, I can 
manually type forth commands into the interpreter; however adding the 
"-vnc :1" option on qemu-system-sparc64 causes it to crash on startup 
for me so I cannot do the same here :(

ATB,

Mark.

[sparc64] Problematic pci at 0 and pci nodes in the device tree

[Jakub Jermar]

Mark Cave-Ayland wrote:
> Jakub Jermar wrote:
> > I don't inspect the forth dictionaries directly because I am not strong
> > in Forth. I used indirect methods like starting the sparc64 qemu without
> > specifying the boot device and then manually navigating myself in the
> > OpenBIOS device tree using the standard commands such as dev / ls and
> > .properties.
>
> Ah I see. Can I ask which options you are using to start 
> qemu-system-sparc64? If I start with "-nographic" then the system 
> starts, but when the boot process stops with an error, the console 
> freezes and I cannot manually enter forth commands.

All I do is:

qemu-system-sparc64 -cdrom path/to/my/image -boot d

when I omit -boot d, then I get the ok prompt. I configured qemu
with no special options other than the target and prefix.

My svn revision is several days old now (will know the exact number
in the evening).

Jakub

[sparc64] Problematic pci at 0 and pci nodes in the device tree

[Mark Cave-Ayland]

Jakub Jermar wrote:
> All I do is:
>
> qemu-system-sparc64 -cdrom path/to/my/image -boot d
>
> when I omit -boot d, then I get the ok prompt. I configured qemu
> with no special options other than the target and prefix.
>
> My svn revision is several days old now (will know the exact number
> in the evening).
>
> Jakub

Right I see. I'm currently trying to fire up a hard drive image from an 
old sun4u machine. Perhaps I shall try a Solaris CDROM-type distro instead?

ATB,

Mark.

[sparc64] Problematic pci at 0 and pci nodes in the device tree

[Blue Swirl]

On 1/22/09, Mark Cave-Ayland  wrote:
> Jakub Jermar wrote:
> > I don't inspect the forth dictionaries directly because I am not strong
> > in Forth. I used indirect methods like starting the sparc64 qemu without
> > specifying the boot device and then manually navigating myself in the
> > OpenBIOS device tree using the standard commands such as dev / ls and
> > .properties.
>
> Ah I see. Can I ask which options you are using to start
> qemu-system-sparc64? If I start with "-nographic" then the system starts,
> but when the boot process stops with an error, the console freezes and I
> cannot manually enter forth commands.
>
> If I use "-vnc :1" on qemu-system-sparc then when the boot fails, I can
> manually type forth commands into the interpreter; however adding the "-vnc
> :1" option on qemu-system-sparc64 causes it to crash on startup for me so I
> cannot do the same here :(

Should be fixed in Qemu r6391.

[sparc64] Problematic pci at 0 and pci nodes in the device tree

[Mark Cave-Ayland]

Blue Swirl wrote:
> > Ah I see. Can I ask which options you are using to start
> > qemu-system-sparc64? If I start with "-nographic" then the system starts,
> > but when the boot process stops with an error, the console freezes and I
> > cannot manually enter forth commands.
> >
> > If I use "-vnc :1" on qemu-system-sparc then when the boot fails, I can
> > manually type forth commands into the interpreter; however adding the "-vnc
> > :1" option on qemu-system-sparc64 causes it to crash on startup for me so I
> > cannot do the same here :(
>
> Should be fixed in Qemu r6391.

Confirmed.

Many thanks,

Mark.

[sparc64] Problematic pci at 0 and pci nodes in the device tree

[Mark Cave-Ayland]

Jakub Jermar wrote:
> I don't inspect the forth dictionaries directly because I am not strong
> in Forth. I used indirect methods like starting the sparc64 qemu without
> specifying the boot device and then manually navigating myself in the
> OpenBIOS device tree using the standard commands such as dev / ls and
> .properties.

Yeah, I am totally new to Forth and so am struggling a little to get to 
grips with the language. However there is a great tutorial on the OLPC 
website which explains how OpenBIOS works there which has been very 
helpful - http://wiki.laptop.org/go/Forth_Lesson_0 if you want the lowdown.
> The other method was printing the device tree nodes and their properties
> as they were discovered by the HelenOS boot loader. The loader uses the
> client interface provided by OpenBIOS both to learn about those nodes
> and properties and also to print them.
>
> In the case of this particular problem, I simply noticed that the path
> used by the screen alias was too ambiguous and the /pci node looked
> strange and didn't have any children.

The pci node does look strange on Sparc64. At the moment I currently see 
this:

0 > show-devs
ffd899a0 /
ffd89b78 /aliases
ffd89ca0 /openprom (BootROM)
ffd92a30 /openprom/client-services
ffd89f58 /options
ffd8a038 /chosen
ffd8a1d8 /builtin
ffd8a300 /builtin/console
ffd924f8 /packages
ffd940a0 /packages/disk-label
ffd947a0 /packages/cmdline
ffd95a60 /packages/deblocker
ffd960b8 /packages/misc-files
ffd96640 /packages/sun-parts
ffd94da0 /memory@0,0
ffd94ef0 /virtual-memory
ffd96900 /pci@0,80000000 (pci)
ffd970c0 /pci@0,80000000/pci@0 (pci)
ffd977f8 /pci@0,80000000/pci@0/pci@0 (pci)
ffd97f08 /pci@0,80000000/pci@0/pci@0/QEMU,VGA@0 (display)
ffd987a8 /pci@0,80000000/pci@0/pci@0/ebus@0 (pci)
ffd98f38 /pci@0,80000000/pci@0/pci@0/ebus@0/fdthree@0 (block)
ffd99438 /pci@0,80000000/pci@0/pci@0/ebus@0/su@0,1 (serial)
ffd996f8 /pci@0,80000000/pci@0/pci@0/ebus@0/kb_ps2 (keyboard)
ffd999c8 /pci@0,80000000/pci@0/pci@0/NE2000@0 (network)
ffd9a090 /pci@0,80000000/pci@0/pci@0/pci-ata@0 (pci-ide)
ffd9a808 /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide0@0,5 (ide)
ffd9aad8 /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide0@0,5/disk@0 (block)
ffd9b128 /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide1@0,6 (ide)
ffd9b3f8 /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide1@0,6/cdrom@0 (block)
ffd9ba48 /SUNW,UltraSPARC-II (cpu)
ffd9bda0 /SUNW,UltraSPARC-II/mmu
  ok
0 > test-all
Testing device /aliases: no self-test method.
Testing device /openprom: no self-test method.
Testing device /openprom/client-services: no self-test method.
Testing device /options: no self-test method.
Testing device /chosen: no self-test method.
Testing device /builtin: no self-test method.
Testing device /builtin/console: no self-test method.
Testing device /packages: no self-test method.
Testing device /packages/disk-label: no self-test method.
Testing device /packages/cmdline: no self-test method.
Testing device /packages/deblocker: no self-test method.
Testing device /packages/misc-files: no self-test method.
Testing device /packages/sun-parts: no self-test method.
Testing device /memory@0,0: no such device.
Testing device /virtual-memory: no self-test method.
Testing device /pci@0,80000000: no such device.
Testing device /pci@0,80000000/pci@0: no such device.
Testing device /pci@0,80000000/pci@0/pci@0: no such device.
Testing device /pci@0,80000000/pci@0/pci@0/QEMU,VGA@0: no such device.
Testing device /pci@0,80000000/pci@0/pci@0/ebus@0: no such device.
Testing device /pci@0,80000000/pci@0/pci@0/ebus@0/fdthree@0: no such device.
Testing device /pci@0,80000000/pci@0/pci@0/ebus@0/su@0,1: no such device.
Testing device /pci@0,80000000/pci@0/pci@0/ebus@0/kb_ps2: no such device.
Testing device /pci@0,80000000/pci@0/pci@0/NE2000@0: no such device.
Testing device /pci@0,80000000/pci@0/pci@0/pci-ata@0: no such device.
Testing device /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide0@0,5: no such 
device.
Testing device /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide0@0,5/disk@0: no 
such device.
Testing device /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide1@0,6: no such 
device.
Testing device /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide1@0,6/cdrom@0: 
no such device.
Testing device /SUNW,UltraSPARC-II: no self-test method.
Testing device /SUNW,UltraSPARC-II/mmu: no self-test method.
  ok
0 >

I think the repeated pci@0 is not right, and the fact that during 
testing "no such device" is reported cannot be a good thing. Off to dig 
further...

ATB,

Mark.

[sparc64] Problematic pci at 0 and pci nodes in the device tree

[Blue Swirl]

On 1/25/09, Mark Cave-Ayland  wrote:
> Jakub Jermar wrote:
> > I don't inspect the forth dictionaries directly because I am not strong
> > in Forth. I used indirect methods like starting the sparc64 qemu without
> > specifying the boot device and then manually navigating myself in the
> > OpenBIOS device tree using the standard commands such as dev / ls and
> > .properties.
>
> Yeah, I am totally new to Forth and so am struggling a little to get to
> grips with the language. However there is a great tutorial on the OLPC
> website which explains how OpenBIOS works there which has been very helpful
> http://wiki.laptop.org/go/Forth_Lesson_0 if you want the
>
> lowdown.
> > The other method was printing the device tree nodes and their properties
> > as they were discovered by the HelenOS boot loader. The loader uses the
> > client interface provided by OpenBIOS both to learn about those nodes
> > and properties and also to print them.
> >
> > In the case of this particular problem, I simply noticed that the path
> > used by the screen alias was too ambiguous and the /pci node looked
> > strange and didn't have any children.
>
> The pci node does look strange on Sparc64. At the moment I currently see
> this:
>
> 0 > show-devs
>  ffd899a0 /
>  ffd89b78 /aliases
>  ffd89ca0 /openprom (BootROM)
>  ffd92a30 /openprom/client-services
>  ffd89f58 /options
>  ffd8a038 /chosen
>  ffd8a1d8 /builtin
>  ffd8a300 /builtin/console
>  ffd924f8 /packages
>  ffd940a0 /packages/disk-label
>  ffd947a0 /packages/cmdline
>  ffd95a60 /packages/deblocker
>  ffd960b8 /packages/misc-files
>  ffd96640 /packages/sun-parts
>  ffd94da0 /memory@0,0
>  ffd94ef0 /virtual-memory
>  ffd96900 /pci@0,80000000 (pci)
>  ffd970c0 /pci@0,80000000/pci@0 (pci)
>  ffd977f8 /pci@0,80000000/pci@0/pci@0 (pci)
>  ffd97f08 /pci@0,80000000/pci@0/pci@0/QEMU,VGA@0 (display)
>  ffd987a8 /pci@0,80000000/pci@0/pci@0/ebus@0 (pci)
>  ffd98f38 /pci@0,80000000/pci@0/pci@0/ebus@0/fdthree@0
> (block)
>  ffd99438 /pci@0,80000000/pci@0/pci@0/ebus@0/su@0,1
> (serial)
>  ffd996f8 /pci@0,80000000/pci@0/pci@0/ebus@0/kb_ps2
> (keyboard)
>  ffd999c8 /pci@0,80000000/pci@0/pci@0/NE2000@0 (network)
>  ffd9a090 /pci@0,80000000/pci@0/pci@0/pci-ata@0 (pci-ide)
>  ffd9a808 /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide0@0,5
> (ide)
>  ffd9aad8
> /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide0@0,5/disk@0
> (block)
>  ffd9b128 /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide1@0,6
> (ide)
>  ffd9b3f8
> /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide1@0,6/cdrom@0
> (block)
>  ffd9ba48 /SUNW,UltraSPARC-II (cpu)
>  ffd9bda0 /SUNW,UltraSPARC-II/mmu
>   ok
>  0 > test-all
>  Testing device /aliases: no self-test method.
>  Testing device /openprom: no self-test method.
>  Testing device /openprom/client-services: no self-test method.
>  Testing device /options: no self-test method.
>  Testing device /chosen: no self-test method.
>  Testing device /builtin: no self-test method.
>  Testing device /builtin/console: no self-test method.
>  Testing device /packages: no self-test method.
>  Testing device /packages/disk-label: no self-test method.
>  Testing device /packages/cmdline: no self-test method.
>  Testing device /packages/deblocker: no self-test method.
>  Testing device /packages/misc-files: no self-test method.
>  Testing device /packages/sun-parts: no self-test method.
>  Testing device /memory@0,0: no such device.
>  Testing device /virtual-memory: no self-test method.
>  Testing device /pci@0,80000000: no such device.
>  Testing device /pci@0,80000000/pci@0: no such device.
>  Testing device /pci@0,80000000/pci@0/pci@0: no such device.
>  Testing device /pci@0,80000000/pci@0/pci@0/QEMU,VGA@0: no
> such device.
>  Testing device /pci@0,80000000/pci@0/pci@0/ebus@0: no such
> device.
>  Testing device
> /pci@0,80000000/pci@0/pci@0/ebus@0/fdthree@0: no such
> device.
>  Testing device /pci@0,80000000/pci@0/pci@0/ebus@0/su@0,1:
> no such device.
>  Testing device /pci@0,80000000/pci@0/pci@0/ebus@0/kb_ps2:
> no such device.
>  Testing device /pci@0,80000000/pci@0/pci@0/NE2000@0: no
> such device.
>  Testing device /pci@0,80000000/pci@0/pci@0/pci-ata@0: no
> such device.
>  Testing device
> /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide0@0,5: no such
> device.
>  Testing device
> /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide0@0,5/disk@0: no
> such device.
>  Testing device
> /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide1@0,6: no such
> device.
>  Testing device
> /pci@0,80000000/pci@0/pci@0/pci-ata@0/ide1@0,6/cdrom@0: no
> such device.
>  Testing device /SUNW,UltraSPARC-II: no self-test method.
>  Testing device /SUNW,UltraSPARC-II/mmu: no self-test method.
>   ok
>  0 >
>
> I think the repeated pci@0 is not right, and the fact that during testing
> "no such device" is reported cannot be a good thing. Off to dig further...

No, it should really be like:
/pci@1f,0/pci@1/pci@1/

The first device is UPA-PCI device, then two PCI bridges.