405gp PCI?

405gp PCI?

[Denton Gentry]

  I'm attempting to bring up a PCI ethernet card in a 405GP
Walnut platform. The PCI device signals a Master Abort, and
from probing the PCI bus it is clear that it does: no target
asserts DEVSEL in response to its DMA.
  My first thought was of a simple byte ordering problem. I
tried reversing the byte order of the addresses handed to the
PCI device. It gets no further than it did before: no target
responds with DEVSEL, so it times out and asserts a master abort.

  I've printed out and checked the I/O addresses, and haven't
made any progress. So I thought I'd step back and validate some
assumptions. I'm using a kernel compiled from the fsmlabs source
as of last Tuesday (I have not pulled over new code since the
boot reorganization was done, I want to get this working first).

  Is the PCI bus in the 405gp known to work in recent kernels?

  Also, though I'm certain that this problem is not caused by
stale data, one of the next things I'll need to tackle is cache
coherency. Can anyone point me to a driver which properly marks
memory as non-cacheable, to use as an example?

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405gp PCI?

[Dan Malek]

Denton Gentry wrote:

> ....I'm using a kernel compiled from the fsmlabs source
> as of last Tuesday (I have not pulled over new code since the
> boot reorganization was done, I want to get this working first).

Hmmm...I know it works with PCI slave devices, but I don't know
if it will for masters.  I know the Linux support functions for
virt_to_bus and friends will provide the proper addresses.  Sounds
like there is some missing 405 register initialization.  Are you
doing this on a custom board, or in the Walnut eval board?  I
suspect on the Walnut we rely on the boot rom for some of this
405 PCI initialization.

>   Also, though I'm certain that this problem is not caused by
> stale data, one of the next things I'll need to tackle is cache
> coherency.

I have just recently finished the pci_consistent_* functions and
software cache mangement functions so they will do the right thing
on the IBM4xx and MPC8xx processors.  Assuming the driver has these
functions in place, they are either no-ops on a cache coherent
processor or provide the proper function on a non-coherent
processor.  The eepro-100 driver used to work with some hacks, and
I'm going to ensure it works without them :-).  It's in the update
patch back to FSM Labs, so it should be there soon.  We are also
adding the PCI auto-probe so we don't rely on the boot rom for
any of the PCI initialization.

The on-board 405 Ethernet driver is an example of how to use the
consistent_* functions for memory management and the cache management
functions.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405gp PCI?

[Denton Gentry]

> Hmmm...I know it works with PCI slave devices, but I don't know
> if it will for masters.  I know the Linux support functions for
> virt_to_bus and friends will provide the proper addresses.  Sounds
> like there is some missing 405 register initialization.  Are you
> doing this on a custom board, or in the Walnut eval board?  I
> suspect on the Walnut we rely on the boot rom for some of this
> 405 PCI initialization.

  The addresses returned by virt_to_bus look reasonable. The virtual
address of the buffer in question is 0xc0261940, and the DMA address
returned by virt_to_bus is 0x00261940. I assume that the lower few megs
of physical RAM are pinned memory for the kernel, and that a 1:1 mapping
of physical pages in this pinned memory is done starting at a kernel
offset in the virtual address space, so these addresses look reasonable
to me.

  This is the Walnut eval board. I am using IBM's firmware to tftpboot
a kernel, which the NFS mounts its root filesystem.

  I'll keep digging into it. Since no-one has piped up to confirm that
PCI DMA works in PPC 405gp systems, I'll start looking at the PCI
controller initialization code as well.

> >   Also, though I'm certain that this problem is not caused by
> > stale data, one of the next things I'll need to tackle is cache
> > coherency.
>
> I have just recently finished the pci_consistent_* functions and
> software cache mangement functions so they will do the right thing
> on the IBM4xx and MPC8xx processors.

  Ok, thanks.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405gp PCI?

[Frank Rowand]

Denton Gentry wrote:
>
> > Hmmm...I know it works with PCI slave devices, but I don't know
> > if it will for masters.  I know the Linux support functions for
> > virt_to_bus and friends will provide the proper addresses.  Sounds
> > like there is some missing 405 register initialization.  Are you
> > doing this on a custom board, or in the Walnut eval board?  I
> > suspect on the Walnut we rely on the boot rom for some of this
> > 405 PCI initialization.
>
>   The addresses returned by virt_to_bus look reasonable. The virtual
> address of the buffer in question is 0xc0261940, and the DMA address
> returned by virt_to_bus is 0x00261940. I assume that the lower few megs
> of physical RAM are pinned memory for the kernel, and that a 1:1 mapping
> of physical pages in this pinned memory is done starting at a kernel
> offset in the virtual address space, so these addresses look reasonable
> to me.
>
>   This is the Walnut eval board. I am using IBM's firmware to tftpboot
> a kernel, which the NFS mounts its root filesystem.

What is the version of the firmware?  (It is reported on the console
when you turn on the power, eg "405GP 1.13 ROM Monitor (4/7/00)".)


>   I'll keep digging into it. Since no-one has piped up to confirm that
> PCI DMA works in PPC 405gp systems, I'll start looking at the PCI
> controller initialization code as well.
>
> > >   Also, though I'm certain that this problem is not caused by
> > > stale data, one of the next things I'll need to tackle is cache
> > > coherency.
> >
> > I have just recently finished the pci_consistent_* functions and
> > software cache mangement functions so they will do the right thing
> > on the IBM4xx and MPC8xx processors.


-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405gp PCI?

[Denton Gentry]

>>   This is the Walnut eval board. I am using IBM's firmware to tftpboot
>> a kernel, which the NFS mounts its root filesystem.
>
> What is the version of the firmware?  (It is reported on the console
> when you turn on the power, eg "405GP 1.13 ROM Monitor (4/7/00)".)

  It says: "405GP 1.15 ROM Monitor (8/9/00)"

  Anticipating another question: according to the silkscreen on the
package, it is a rev D of the 405gp. The ROM Monitor says the processor
PVR is 401100c4  (though I have no idea how to interpret that).

--Denny

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405gp PCI?

[Frank Rowand]

Denton Gentry wrote:
>
> >>   This is the Walnut eval board. I am using IBM's firmware to tftpboot
> >> a kernel, which the NFS mounts its root filesystem.
> >
> > What is the version of the firmware?  (It is reported on the console
> > when you turn on the power, eg "405GP 1.13 ROM Monitor (4/7/00)".)
>
>   It says: "405GP 1.15 ROM Monitor (8/9/00)"

That's the problem....  That version of the OpenBios changed the PLB to
PCI address mapping (the mapping is in the PMM0 registers).  The kernel
expects PLB address 0x8000'0000 to map to PCI address 0x0000'0000, and the
PMM registers should map PCI address 0x0000'0000 to PLB address 0x0000'0000.
A near future kernel will fix up the PTM and PMM registers (on the Walnut
only) to match what the kernel expects.


>   Anticipating another question: according to the silkscreen on the
> package, it is a rev D of the 405gp. The ROM Monitor says the processor
> PVR is 401100c4  (though I have no idea how to interpret that).

That PVR means Rev D.


-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405gp PCI?

[John Cagle]

On Tue, May 01, 2001 at 04:44:37PM -0700, Frank Rowand wrote:
>
> That's the problem....  That version of the OpenBios changed the PLB to
> PCI address mapping (the mapping is in the PMM0 registers).  The kernel
> expects PLB address 0x8000'0000 to map to PCI address 0x0000'0000, and the
> PMM registers should map PCI address 0x0000'0000 to PLB address 0x0000'0000.
> A near future kernel will fix up the PTM and PMM registers (on the Walnut
> only) to match what the kernel expects.
>

Until a newer kernel is released by Monta Vista, you can use setpci to
change the settings of the PCI bridge as follows:

  setpci -s 0:0.1 14.L=0x8

Regards,
John

------------------------------
John Cagle <jcagle@kernel.org>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/