Re: Help?? SATA problems when trying to add WD Sharespace support to kernel

On Thu, Oct 28, 2010 at 8:43 PM, David Hicks <dave@nastylittlehorse.net> wrote:

Hi there,

I'm a n00b at kernel hacking, though I have about 10 years software experience and I've been running debian on ARM devices for a few years now. I'm trying to get a modern kernel to boot on a WD Sharespace at the moment and would appreciate some advice/help.

Background -

WD sell a 4TB NAS box called the sharespace. Inside it's running a WD customised (I think) version of the Marvell kernel tree, version 2.6.12, on a 500MHz feroceon core, 88F5281. It has 128MB RAM, 16MB of NOR flash, 4 SATA ports, gigabit ethernet and 3 usb ports. SATA is done by a Marvell 88SX7042 on the PCI bus.

I decided it was slow and limited and wanted to try and at least fix the limited part. Debian chroot images wouldn't work because the kernel was too old, or (in the case of sarge, I went back a way) the ABI was incompatible. So I embarked on the foolish errand of trying to make the current squeeze kernel boot on the box.

Thanks to some advice and a tutorial link from Martin M and some poking around with a multimeter I have made progress -

Serial access via a pulled apart nokia USB -> serial cable

Kernel for orion5x built on a sheevaplug because my attempt at cross compilation failed
uboot environment tweaked to read uImage from a hard disk
Kernel booting, RTC, USB, UART(s), NOR and ethernet initialised and loaded (modules for ehci and other devices built in to kernel)

PCI... mostly initialised, SATA not really working

That's the bit I need help on. I've attached my sharespace-setup.c file that handles the device initialisation, modelled on the other files in arch/arm/mach-orion5x with values taken from the Marvell/WD source, and the kernel console output and would be grateful for any advice on how to fix what is going on.

In short - everything seems to go fine until it tries to speak to the hard disk, where it recognises the drive and then fails to do... something -

[ 28.126559] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 28.147053] ata4.00: ATA-6: ST9402115AS, 3.01, max UDMA/100
[ 28.152616] ata4.00: 78140160 sectors, multi 0: LBA48 NCQ (depth 1)

[ 28.177148] ata4.00: configured for UDMA/100
[ 28.182020] scsi 3:0:0:0: Direct-Access ATA ST9402115AS 3.01 PQ: 0 ANSI: 5
[ 28.191070] sd 3:0:0:0: [sda] 78140160 512-byte logical blocks: (40.0 GB/37.2 GiB)

[ 28.199976] sd 3:0:0:0: [sda] Write Protect is off
[ 28.205046] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 28.215561] sda:
[ 58.816573] ata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen

[ 58.823799] ata4.00: failed command: READ FPDMA QUEUED
[ 58.828985] ata4.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0 ncq 4096 in
[ 58.829002] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

[ 58.843761] ata4.00: status: { DRDY }
[ 58.847458] ata4: hard resetting link

Anyone seen this before? It goes on like that for a while, setting slower UDMA modes before finally admitting defeat.

Is there anything desperately wrong with what I've done so far?

The only weirdnesses I've encountered otherwise are -
1. The Marvell/WD source claims to have three PCI slots, but if I set the .nr_controllers field of the pci struct to 2 or 3 the machine just sits there after " Uncompressing Linux... done, booting the kernel" and does nothing, so I only initialise PCI 0

2. The kernel console output says that the ata controllers are using irq 44, which I can see further up is the irq for the (uninitialised) pci slots 1 and 2...
I've tried returning the slot 0 irq for the other slot and it doesn't help at all. Same console output.

Right, I've written a lot here and if you;ve read this far then thanks. This is most frustrating as it feels like the final hurdle before I can mount the root partition and run the second stage debootstrap...

Dave.