MPC85xx git branch - problem with Marvel SATA driver...

I am looking for ideas here about a problem I am having.

 

I am working with a new git branch that is supposed to PCI Express on
the CDS.

 

I have a MPC8548E CDS system plugged into an Arcadia motherboard. I 

have a PCI Marvel Sata Card plugged into the same Arcadia mother board.

 

The driver works flawless when there is NO actual SATA Drive plugged
into

this card (the sata_mv driver recognizes and enumerates the ports on
marvel card). 

 

The problem comes when I plug a SATA drive into one of the SATA ports on
this card.

When I boot the kernel after doing this and as the sata/ata driver
starts probing the

Sata card/jport for devices - it jumps off to 'never never land' (never
returns from the 

second write flush of the control register (writing 0x301 to SCR_CONTROL
(and 

reading it  back) and then writing 0x300 to same register - it never
actually returns

from the writefl of that 0x300 value  to the SCR_Control.  

 

FWIW, I have cross ported this driver (and its slightly different ata
infrastructure to a

x86 platform (running a 2.6.19.x kernel) and it does work in that
environment . Further, 

I have cross ported the original working 2.6.19.1 driver to this git
branch - and it fails 

in exactly the same spot.

 

It smells that there is some type of interrupt / configuration mismatch
for the PCI bus for the 

CDS that is executed upon this probe sequence of a valid SATA/ATA Port?

 

Has anyone experienced this problem themselves? What can I do? Thanks in
advance 

for all of your support!

Tom Morrison
Principal Software Engineer

EMPIRIX 
20 Crosby Drive - Bedford, MA  01730
p: 781.266.3567 f: 781.266.3670 
email: tmorrison@empirix.com <mailto:tmorrison@empirix.com>  
www.empirix.com <http://www.empirix.com/> 




 

On Feb 16, 2007, at 14:25, Morrison, Tom wrote:

It smells that there is some type of interrupt / configuration  
mismatch for the PCI bus for the

CDS that is executed upon this probe sequence of a valid SATA/ATA  
Port?

Which slot is the CDS carrier card in, and which slot is the SATA  
card in.  And what interrupt is it trying to register for?

More importantly, what version of u-boot are you running on the  
board, and what versions of the Carrier Card and Arcadia are you  
using?  U-Boot rearranges the interrupt-map for PCI based on the slot  
the CDS Carrier Card is in (which has to be set by a switch on the  
card).

The code in the tree on opensource.freescale.com only works on the  
3.1 Arcadia (assuming you also used the DTS that came with it).

Andy

Andy,

CDS is in slot #2, marvel sata card is in Slot #5

I am using the new u-boot git branch from freescale for=20
the MPC85xx_cds. I was told to use this with the new=20
software - which is also using the device tree as well...

Can't tell what version of Arcadia board - where is this located?

All switches on all boards (mother/carrier/cds) are believed
to be in default position as referenced in the cds manual:

    mpc8548_cds_reference.pdf

We haven't done any rocket science here!

Tom


-----Original Message-----
From: Andy Fleming [mailto:afleming@freescale.com]=20
Sent: Friday, February 16, 2007 3:43 PM
To: Morrison, Tom
Cc: linuxppc-dev@ozlabs.org; Geary Sean-R60898; Zhang Wei-r63237
Subject: Re: MPC85xx git branch - problem with Marvel SATA driver...


On Feb 16, 2007, at 14:25, Morrison, Tom wrote:

It smells that there is some type of interrupt / configuration =20
mismatch for the PCI bus for the

CDS that is executed upon this probe sequence of a valid SATA/ATA =20
Port?

Which slot is the CDS carrier card in, and which slot is the SATA =20
card in.  And what interrupt is it trying to register for?

More importantly, what version of u-boot are you running on the =20
board, and what versions of the Carrier Card and Arcadia are you =20
using?  U-Boot rearranges the interrupt-map for PCI based on the slot =20
the CDS Carrier Card is in (which has to be set by a switch on the =20
card).

The code in the tree on opensource.freescale.com only works on the =20
3.1 Arcadia (assuming you also used the DTS that came with it).

Andy

On Feb 16, 2007, at 16:02, Morrison, Tom wrote:

Andy,

CDS is in slot #2, marvel sata card is in Slot #5

I am using the new u-boot git branch from freescale for
the MPC85xx_cds. I was told to use this with the new
software - which is also using the device tree as well...

Can't tell what version of Arcadia board - where is this located?

Sorry for the delay.  I wasn't quite sure how to find that  
information.  However, back channels have indicated you may be using  
a 3.0 Arcadia.  In that case, you need to use the dts in arch/powerpc/ 
boot/dts/mpc8548cds_legacy.dts.  It's not a very useful name (sorry),  
but that's what it's called internally right now.  The interrupt maps  
for 3.0 and 3.1 PCI are different, and that would explain your  
problem, I hope.


Andy

Will try this out and let you know!

t

-----Original Message-----
From: Andy Fleming [mailto:afleming@freescale.com]=20
Sent: Tuesday, February 20, 2007 2:41 PM
To: Morrison, Tom
Cc: linuxppc-dev@ozlabs.org; Geary Sean-R60898; Zhang Wei-r63237
Subject: Re: MPC85xx git branch - problem with Marvel SATA driver...


On Feb 16, 2007, at 16:02, Morrison, Tom wrote:

Andy,

CDS is in slot #2, marvel sata card is in Slot #5

I am using the new u-boot git branch from freescale for
the MPC85xx_cds. I was told to use this with the new
software - which is also using the device tree as well...

Can't tell what version of Arcadia board - where is this located?

Sorry for the delay.  I wasn't quite sure how to find that =20
information.  However, back channels have indicated you may be using =20
a 3.0 Arcadia.  In that case, you need to use the dts in arch/powerpc/=20
boot/dts/mpc8548cds_legacy.dts.  It's not a very useful name (sorry), =20
but that's what it's called internally right now.  The interrupt maps =20
for 3.0 and 3.1 PCI are different, and that would explain your =20
problem, I hope.


Andy

All,

I have yet to successfully gone through full initialization /=20
registration of this driver for this board.

I have both a Marvell PCI SATA Card (with 6042 chip)=20
and a Marvell PCI Express SATA card (with 7042 chip).

PCI/6042 Chip Marvel SATA Card
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
   On PCI Bus - the card is probed, and finds the SATA drive -=20
   goes through an ata add device process - up to adding scsi device -
   even goes all the way to checking the file system -and lastly says:

       SCSI device sda: write cache: enabled, read cache: enabled,=20
        sda: unknown partition table
       sd 0:0:0:0: Attached scsi disk sda

   After full boot (I am nfs mounting my root file system until I get
   this working), I try to mount drive - no good - I can't mount it
   (it also doesn't create a /dev/sda or /dev/sda1 device - I assume=20
   that if it knew the partitioning table - it would actually create
   these devices and Yes, I have ms-dos file system support compiled in?

   Is there anything else that=20

PCI Express/7042 Marvell Sata Card:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
   On PCI Express Bus - it never performs the probe - even though
   the bus was scanned and device was found ("lspci" shows this device)

   FYI, I tried the PCI Express SATA Card in an X86 running Fedora
   Core 6 (2.6.19.1-2xxx) and this seemingly is the same behavior
   on this platform?

   Are there other things I need to configure or initialize to=20
   allow the to recognize/probe the SATA drive on the PCI Express bus?

   Or there has to be other PCI Express SATA Cards out there that
   Do NOT have this problem? How do they get around this?


Am I really missing something here or just going crazy?

Thank you for all your suggestions!!!

Sincerely,

Tom Morrison
Principal Software Engineer
EMPIRIX=20
20 Crosby Drive - Bedford, MA  01730
p: 781.266.3567 f: 781.266.3670=20
email: tmorrison@empirix.com=20
www.empirix.comz

On Fri, Feb 23, 2007 at 02:57:38PM -0500, Morrison, Tom wrote:

PCI Express/7042 Marvell Sata Card:
===================================
   On PCI Express Bus - it never performs the probe - even though
   the bus was scanned and device was found ("lspci" shows this device)

   FYI, I tried the PCI Express SATA Card in an X86 running Fedora
   Core 6 (2.6.19.1-2xxx) and this seemingly is the same behavior
   on this platform?

A patch went into 2.6.20 quite late to add the PCI ids for at least
one 7042 controller (Highpoint). You might have to add the ids of your
controller as well.


-Olof

Olof,

Are you saying that it must 'know' about the PCI id(s)
for this SATA card before it even probes that device???

Even though the module is compiled into the kernel and=20
I've verified that:

  a) the pci scan bus has detected this device
  b) that the sata_mv driver is registering itself
     as a PCI Device driver?

????

Also, fyi, its also complaining about the PCI Express=20
Root Bridge on the MPC8548 as an unknown device...

   manufacturer: 0x1957 (aka: Freescale)
   class: 0xFFFF

although that doesn't explain why the same PCI=20
Express SATA card / ~same sata_mv driver on an=20
Intel X86 platform doesn't get recognized either.

Thank you for any additional insight you have on this Olof!

Tom

-----Original Message-----
From: Olof Johansson [mailto:olof@lixom.net]
Sent: Fri 2/23/2007 3:29 PM
To: Morrison, Tom
Cc: Andy Fleming; Geary Sean-R60898; linuxppc-dev@ozlabs.org; Zhang =
Wei-r63237
Subject: Re: Update on: MPC85xx git/MPC8548cds - PCI/PCIE problemS with =
Marvel SATA driver...
=20
On Fri, Feb 23, 2007 at 02:57:38PM -0500, Morrison, Tom wrote:

PCI Express/7042 Marvell Sata Card:
=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

   On PCI Express Bus - it never performs the probe - even though
   the bus was scanned and device was found ("lspci" shows this =

device)

=20
   FYI, I tried the PCI Express SATA Card in an X86 running Fedora
   Core 6 (2.6.19.1-2xxx) and this seemingly is the same behavior
   on this platform?

A patch went into 2.6.20 quite late to add the PCI ids for at least
one 7042 controller (Highpoint). You might have to add the ids of your
controller as well.


-Olof

On Fri, Feb 23, 2007 at 05:47:22PM -0500, Morrison, Tom wrote:

Olof,

Are you saying that it must 'know' about the PCI id(s)
for this SATA card before it even probes that device???

Even though the module is compiled into the kernel and 
I've verified that:

  a) the pci scan bus has detected this device
  b) that the sata_mv driver is registering itself
     as a PCI Device driver?

Yes. There's the device on the bus, and there's the PCI bus code that will
walk all busses and enumerate all devices. Then there's the driver. All
drivers have a small table that they use to specify which PCI devices
they are usable with, so if the device isn't listed, the driver won't
get involved.

See the sata_mv sources for more info, search for '7042' and you'll find
the table, at least if you're looking at the 2.6.20 sources.

Also, fyi, its also complaining about the PCI Express 
Root Bridge on the MPC8548 as an unknown device...

   manufacturer: 0x1957 (aka: Freescale)
   class: 0xFFFF

What complains? lspci? Or the kernel? lspci is just a high-level program
that has a database that maps the numerical codes to manufacturers and
devices. The database might be out of date, or someone forgot to submit
the device IDs to it. It happens all the time.

although that doesn't explain why the same PCI 
Express SATA card / ~same sata_mv driver on an 
Intel X86 platform doesn't get recognized either.

Same thing -- PCI id missing from the driver.

Thank you for any additional insight you have on this Olof!

-Olof

On Fri, 2007-02-23 at 14:57 -0500, Morrison, Tom wrote:

All,

I have yet to successfully gone through full initialization / 
registration of this driver for this board.

I have both a Marvell PCI SATA Card (with 6042 chip) 
and a Marvell PCI Express SATA card (with 7042 chip).

PCI/6042 Chip Marvel SATA Card
==============================
   On PCI Bus - the card is probed, and finds the SATA drive - 
   goes through an ata add device process - up to adding scsi device -
   even goes all the way to checking the file system -and lastly says:

       SCSI device sda: write cache: enabled, read cache: enabled, 
        sda: unknown partition table
       sd 0:0:0:0: Attached scsi disk sda

   After full boot (I am nfs mounting my root file system until I get
   this working), I try to mount drive - no good - I can't mount it
   (it also doesn't create a /dev/sda or /dev/sda1 device - I assume 
   that if it knew the partitioning table - it would actually create
   these devices and Yes, I have ms-dos file system support compiled in?

The above looks like it's working and you don't have a proper partition
table on the disk or you haven't compiled in support for the right type
of partition map (this is different from the filesystem type)....

Make sure you enable MS-DOS partition type support in addition to file
system type.

Ben.

Benjamin Herrenschmidt wrote:

The above looks like it's working and you don't have a proper partition
table on the disk or you haven't compiled in support for the right type
of partition map (this is different from the filesystem type)....

Make sure you enable MS-DOS partition type support in addition to file
system type.

Yeah, I made the same mistake once too.

The trick is not to confuse a file system with a partition type. 
They're completely separate options.  You can select any combination of 
file systems and partition types, even combinations that can never exist 
in the real world.  So if you turn on MS-DOS file system support, you 
also need to turn on MS-DOS partition support.

Yup, missed that! Thank you=20

-----Original Message-----
From: Timur Tabi [mailto:timur@freescale.com]=20
Sent: Sunday, February 25, 2007 7:18 PM
To: Morrison, Tom
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Update on: MPC85xx git/MPC8548cds - PCI/PCIE problemS with
Marvel SATA driver...

Benjamin Herrenschmidt wrote:

The above looks like it's working and you don't have a proper

partition

table on the disk or you haven't compiled in support for the right

type

of partition map (this is different from the filesystem type)....
=20
Make sure you enable MS-DOS partition type support in addition to file
system type.

Yeah, I made the same mistake once too.

The trick is not to confuse a file system with a partition type.=20
They're completely separate options.  You can select any combination of=20
file systems and partition types, even combinations that can never exist

in the real world.  So if you turn on MS-DOS file system support, you=20
also need to turn on MS-DOS partition support.

As indicated before, I got the SATA drive fully=20
accessed via the PCI interface (that uses the Marvell=20
6042 chip).

With some help from Freescale and based upon the CDS/Carrier/
Motherboard combination that I have (2.2/1.2/3.0), I was
required to merge the PCI Express piece of the Standard=20
DTS file into the legacy version. Further, I modified=20
the standard sata_mv.c to recognize the Marvell 7042 chip=20
as a valid/supportable id.

The question now is:  What do I do with these changes?

I am assuming that someone from Freescale will update the
DTS changes, but what about the change to sata_mv.c?

It is a one line change to add the Marvell version of=20
7042 chip to the pci_device_id table (mv_pci_tbl):

	{ PCI_VDEVICE(MARVELL, 0x7042), chip_7042 },

I know that for Marvell, the only difference between the=20
PCI version (6042) and PCI Express version (7042) is=20
the external bridge interface (PCI to PCI bridge for the=20
6042 & PCI to PCI Express bridge for the 7042) which
is transparent to this driver anyways. Thus, I am=20
pretty sure it's a safe change?

But, I've never submitted a change and/or I do not=20
want to step on anyone else's toes (J.G. comes in mind)=20
if they are already staging this change.

Suggestions/Comments?

Thanks in advance...

Tom Morrison
Principal Software Engineer
EMPIRIX=20
20 Crosby Drive - Bedford, MA  01730
p: 781.266.3567 f: 781.266.3670=20
email: tmorrison@empirix.com=20
www.empirix.com

On Feb 27, 2007, at 10:45 AM, Morrison, Tom wrote:

As indicated before, I got the SATA drive fully
accessed via the PCI interface (that uses the Marvell
6042 chip).

With some help from Freescale and based upon the CDS/Carrier/
Motherboard combination that I have (2.2/1.2/3.0), I was
required to merge the PCI Express piece of the Standard
DTS file into the legacy version. Further, I modified
the standard sata_mv.c to recognize the Marvell 7042 chip
as a valid/supportable id.

The question now is:  What do I do with these changes?

I am assuming that someone from Freescale will update the
DTS changes, but what about the change to sata_mv.c?

For the sata_mv.c change I would create a patch as per Documentation/ 
SubmittingPatches and email Jeff Garzik with the patch and copy linux- 
ide@vger.kernel.org.	

It is a one line change to add the Marvell version of
7042 chip to the pci_device_id table (mv_pci_tbl):

	{ PCI_VDEVICE(MARVELL, 0x7042), chip_7042 },

I know that for Marvell, the only difference between the
PCI version (6042) and PCI Express version (7042) is
the external bridge interface (PCI to PCI bridge for the
6042 & PCI to PCI Express bridge for the 7042) which
is transparent to this driver anyways. Thus, I am
pretty sure it's a safe change?

But, I've never submitted a change and/or I do not
want to step on anyone else's toes (J.G. comes in mind)
if they are already staging this change.

Suggestions/Comments?

Thanks in advance...

Tom Morrison
Principal Software Engineer
EMPIRIX
20 Crosby Drive - Bedford, MA  01730
p: 781.266.3567 f: 781.266.3670
email: tmorrison@empirix.com
www.empirix.com

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

On Feb 27, 2007, at 10:45, Morrison, Tom wrote:

As indicated before, I got the SATA drive fully
accessed via the PCI interface (that uses the Marvell
6042 chip).

With some help from Freescale and based upon the CDS/Carrier/
Motherboard combination that I have (2.2/1.2/3.0), I was
required to merge the PCI Express piece of the Standard
DTS file into the legacy version. Further, I modified
the standard sata_mv.c to recognize the Marvell 7042 chip
as a valid/supportable id.

The question now is:  What do I do with these changes?

I am assuming that someone from Freescale will update the
DTS changes, but what about the change to sata_mv.c?

Actually, if you could send a patch for this, I'd appreciate it.  I'm  
not completely clear on which changes you made, here.

I want to make sure we get them all.

Andy