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

[Jakub Jermar]

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@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@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@0 path components or the /pci node should not exist at all.

Can you confirm this is a problem in the tree?

Thanks,
Jakub

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

[Blue Swirl]

On 1/16/09, Jakub Jermar  wrote:
> 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@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@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@0 path components or the /pci node should not exist at all.
>
> Can you confirm this is a problem in the tree?

Yes, there is a duplicate for some reason for most PCI devices. Also
the address is 0, except for IDE and serial.

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

[Jakub Jermar]

Blue Swirl wrote:
> On 1/16/09, Jakub Jermar  wrote:
> > 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@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@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@0 path components or the /pci node should not exist at all.
> >
> > Can you confirm this is a problem in the tree?
>
> Yes, there is a duplicate for some reason for most PCI devices. Also
> the address is 0, except for IDE and serial.

After some recent changes in Qemu, this is no longer a problem and HelenOS finds
the QEMU,VGA node.

The properties needed to find the physical address of the framebuffer seem to
be still wrong. Is this fixed in the upstream version of OpenBIOS (I still haven't
figured out how to build openbios :-()? Basically what is needed is the reg property
in the screen node and ranges properties in all the nodes above screen up to the
root. I believe the address property is normally used to hold a virtual address
valid for ofw-managed mappings (not the physical address), but I may be wrong.

Jakub

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

[Blue Swirl]

On 1/18/09, Jakub Jermar  wrote:
> Blue Swirl wrote:
> > On 1/16/09, Jakub Jermar  wrote:
> > > 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@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@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@0 path components or the /pci node should not exist at all.
> > >
> > > Can you confirm this is a problem in the tree?
> >
> > Yes, there is a duplicate for some reason for most PCI devices. Also
> > the address is 0, except for IDE and serial.
>
> After some recent changes in Qemu, this is no longer a problem and HelenOS finds
>  the QEMU,VGA node.
>
> The properties needed to find the physical address of the framebuffer seem to
>  be still wrong. Is this fixed in the upstream version of OpenBIOS (I still haven't
>  figured out how to build openbios :-()? Basically what is needed is the reg property

First, you need binutils and gcc. For cross compiling I'd recommend
sparc64-elf target, then you avoid a lot of unneeded Linux
headers/libgcc stuff. At least binutils 2.18 and gcc 4.2.4 build
working binaries. I still don't have a working cross gdb for Sparc64,
the obvious configuration (--target=sparc64-elf) doesn't work.

Then OpenBIOS:
./config/scripts/switch-config cross-sparc64 (or just sparc64 for native)
make
> in the screen node and ranges properties in all the nodes above screen up to the
>  root. I believe the address property is normally used to hold a virtual address
>  valid for ofw-managed mappings (not the physical address), but I may be wrong.

Ok, I'll check.

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

[Jakub Jermar]

Blue Swirl wrote:
> On 1/18/09, Jakub Jermar  wrote:
> > Blue Swirl wrote:
> > > On 1/16/09, Jakub Jermar  wrote:
> > > > 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@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@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@0 path components or the /pci node should not exist at all.
> > > >
> > > > Can you confirm this is a problem in the tree?
> > >
> > > Yes, there is a duplicate for some reason for most PCI devices. Also
> > > the address is 0, except for IDE and serial.
> >
> > After some recent changes in Qemu, this is no longer a problem and HelenOS finds
> >  the QEMU,VGA node.
> >
> > The properties needed to find the physical address of the framebuffer seem to
> >  be still wrong. Is this fixed in the upstream version of OpenBIOS (I still haven't
> >  figured out how to build openbios :-()? Basically what is needed is the reg property
>
> First, you need binutils and gcc. For cross compiling I'd recommend
> sparc64-elf target, then you avoid a lot of unneeded Linux
> headers/libgcc stuff. At least binutils 2.18 and gcc 4.2.4 build
> working binaries.

Ok, I will try sparc64-elf.
> I still don't have a working cross gdb for Sparc64,
> the obvious configuration (--target=sparc64-elf) doesn't work.

What exactly is the problem, maybe I can help???
I built cross-gdb for sparc64-linux-gnu. On another computer,
I had some problems with newer versions of gcc, so I built
using gcc-3.4.
> > in the screen node and ranges properties in all the nodes above screen up to the
> >  root. I believe the address property is normally used to hold a virtual address
> >  valid for ofw-managed mappings (not the physical address), but I may be wrong.
>
> Ok, I'll check.

Thanks.

Jakub

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

[Blue Swirl]

On 1/18/09, Jakub Jermar  wrote:
> Blue Swirl wrote:
> > On 1/18/09, Jakub Jermar  wrote:
> > > Blue Swirl wrote:
> > > > On 1/16/09, Jakub Jermar  wrote:
> > > > > 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@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@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@0 path components or the /pci node should not exist at all.
> > > > >
> > > > > Can you confirm this is a problem in the tree?
> > > >
> > > > Yes, there is a duplicate for some reason for most PCI devices. Also
> > > > the address is 0, except for IDE and serial.
> > >
> > > After some recent changes in Qemu, this is no longer a problem and HelenOS finds
> > >  the QEMU,VGA node.
> > >
> > > The properties needed to find the physical address of the framebuffer seem to
> > >  be still wrong. Is this fixed in the upstream version of OpenBIOS (I still haven't
> > >  figured out how to build openbios :-()? Basically what is needed is the reg property
> >
> > First, you need binutils and gcc. For cross compiling I'd recommend
> > sparc64-elf target, then you avoid a lot of unneeded Linux
> > headers/libgcc stuff. At least binutils 2.18 and gcc 4.2.4 build
> > working binaries.
>
> Ok, I will try sparc64-elf.
> > I still don't have a working cross gdb for Sparc64,
> > the obvious configuration (--target=sparc64-elf) doesn't work.
>
> What exactly is the problem, maybe I can help???
>  I built cross-gdb for sparc64-linux-gnu. On another computer,
>  I had some problems with newer versions of gcc, so I built
>  using gcc-3.4.

This one:
http://lists.gnu.org/archive/html/qemu-devel/2009-01/msg00476.html
;-)

Does the version compiled with gcc 3.4 work without the packet size problem?

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

[Jakub Jermar]

Blue Swirl wrote:
> > What exactly is the problem, maybe I can help???
> >  I built cross-gdb for sparc64-linux-gnu. On another computer,
> >  I had some problems with newer versions of gcc, so I built
> >  using gcc-3.4.
>
> This one:
> http://lists.gnu.org/archive/html/qemu-devel/2009-01/msg00476.html
> ;-)

Aha, ok :-)
> Does the version compiled with gcc 3.4 work without the packet size problem?

Yes, I need to use set architecture sparc:v9.
Besides architecture, there are some other suspicious settings:

endian
gnutarget
osabi
remoteaddresssize
remotewritesize

But I am just guessing.

Jakub