is SATA working yet in the kernel

hi,

is SATA working yet in the kernel ? .. as far as i can make out we are waiting for driver fixes to be committed to the GIT code before SATA will be working ?? or are the driver fixes (and kernel config changes) already in there ?
rgds

ian



Edited 1 time(s). Last edit at 07/18/2012 07:46AM by gnexus.

Jeff must not have liked my first reply! ;) Anyway, if you saw it before it was deleted I apologize for being so terse.

I was rather pissed at the time. The last thing I wanted, after recompiling the kernel 30 times, was to possibly find out the SATA wasn't working in it. That would really ruin an entire day, or even an entire week.

As a more appropriate reply to your post after checking:

modprobe sw_ahci_platform

[ 1101.500000] sw_ahci sw_ahci.0: controller can't do PMP, turning off CAP_PMP
[ 1101.520000] sw_ahci sw_ahci.0: forcing PORTS_IMPL to 0x1
[ 1101.540000] sw_ahci sw_ahci.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[ 1101.570000] sw_ahci sw_ahci.0: flags: ncq sntf pm led clo only pio slum part ccc 
[ 1101.600000] scsi1 : sw_ahci_platform
[ 1101.640000] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 56
[ 1102.030000] ata1: SATA link down (SStatus 0 SControl 300)

. . . inserts SATA drive into Mele SATA bay:

[ 1395.710000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0xe frozen
[ 1395.740000] ata1: irq_stat 0x00400040, connection status changed
[ 1395.750000] ata1: SError: { RecovComm PHYRdyChg CommWake DevExch }
[ 1395.770000] ata1: hard resetting link
[ 1399.280000] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1399.740000] ata1.00: ATA-8: WDC WD5000BEVT-22A0RT0, 01.01A01, max UDMA/133
[ 1399.760000] ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[ 1399.780000] ata1.00: configured for UDMA/133
[ 1399.790000] ata1: EH complete
[ 1401.000000] scsi 1:0:0:0: Direct-Access     ATA      WDC WD5000BEVT-2 01.0 PQ: 0 ANSI: 5
[ 1401.040000] sd 1:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[ 1401.080000] sd 1:0:0:0: [sdb] Write Protect is off
[ 1401.100000] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 1401.120000] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1401.190000] ata1.00: exception Emask 0x12 SAct 0x1 SErr 0x1080500 action 0x6 frozen
[ 1401.220000] ata1.00: irq_stat 0x08000000, interface fatal error
[ 1401.250000] ata1: SError: { UnrecovData Proto 10B8B TrStaTrns }
[ 1401.280000] ata1.00: failed command: READ FPDMA QUEUED
[ 1401.310000] ata1.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0 ncq 4096 in
[ 1401.310000]          res 40/00:04:00:00:00/00:00:00:00:00/40 Emask 0x12 (ATA bus error)
[ 1401.400000] ata1.00: status: { DRDY }
[ 1401.400000] ata1: hard resetting link
[ 1401.780000] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1401.860000] ata1.00: configured for UDMA/133
[ 1401.870000] ata1: EH complete
[ 1401.910000] ata1: limiting SATA link speed to 1.5 Gbps
[ 1401.920000] ata1.00: exception Emask 0x12 SAct 0x1 SErr 0x80500 action 0x6 frozen
[ 1401.940000] ata1.00: irq_stat 0x08000000, interface fatal error
[ 1401.960000] ata1: SError: { UnrecovData Proto 10B8B }
[ 1401.980000] ata1.00: failed command: READ FPDMA QUEUED
[ 1402.000000] ata1.00: cmd 60/08:00:00:00:00/00:00:00:00:00/40 tag 0 ncq 4096 in
[ 1402.000000]          res 50/00:00:2f:60:38/00:00:3a:00:00/e0 Emask 0x12 (ATA bus error)
[ 1402.060000] ata1.00: status: { DRDY }
[ 1402.060000] ata1: hard resetting link
[ 1402.430000] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 1402.500000] ata1.00: configured for UDMA/133
[ 1402.520000] ata1: EH complete
[ 1402.710000]  sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 >
[ 1402.780000] sdb: detected capacity change from 0 to 500107862016
[ 1402.800000] sd 1:0:0:0: [sdb] Attached SCSI disk

mount /dev/sdb5 /mnt/misc
ls /mnt/misc

bin   core  etc   initrd.img      lib         media  opt   root  sbin     srv  tmp  var      vmlinuz.old
boot  dev   home  initrd.img.old  lost+found  mnt    proc  run   selinux  sys  usr  vmlinuz

So to answer your question: yes it works!

Edit: If the SATA module is probed after boot the SATA tends to reset and drop down to 1.5 Gbps. But if the module is loaded at boot it runs fine at 3.0 Gbps:

ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Edit: Even when SATA is loaded at boot it tends to reset and drop down to 1.5 Gbps with my WD drive. That could be due to a poor quality cable/connector in the Mele. It will take more testing to determine what is at fault.

SATA seems to work fine, at least at 1.5 Gbps, in most cases.



Edited 2 time(s). Last edit at 07/23/2012 07:58AM by gnexus.

sadly getting in to linux and having to take abuse are all too commonplace so im thick skinned in this respect anyway :-(

incidently I was probably screwing around with GIT A10 uboot and compiling it 30x on its own until the people maintaining the A10 GIt code fessed up that they had screwed the live code up fiddling with it .. likewise the same with the kernel ..newcomers (like me) havnt the first clue which version of what on GIt works and which doesnt and i must have wasted many days x-compiling kernels and uboot only to find out later it would never have worked in the first place because its messy and chaotic (why i know some GIt codebases work with SATA and some dont .. hence my question)

look ... the reason why jeff's forum became so popular in the first place was that it provided a simple way for ordinary people to get in to hacking these little devices without the horrific abuse and steep learing curve of linux .. its like chicken and egg .. jeffs dockstar script drove people to get the dockstars which drove people to contribute and post to the forum and if the same approach is followed with the A10 the same thing will happen

the simple script and uboot hack he provided for dockstars got many people in to linux who would never have given it houseroom and made these pretty useless devices in to something useful and in simple terms thats whats needed for the A10

One kind person actually wrote a script which is not bad (i have to say it is variable in when it works and having tried it quite a few times) to automate uboot/kernel and ROOTFS generation (usually from source) incl wheezy/SD card creation BUT it relies on the default config on GIT which is a very basic excluding SATA amongst others ...

heres a link to the script ... it might be the case that just modifying the script * a couple of suitable configs for maxmem/SSH headless(server) as well as a full fat framebuffer/display driver variant could be accomodated meaning you wouldnt have to mess about posting big files and keeping images updated (and many people probably have security issues with using other ppl's images) .. it would also be kind of nice from a nostalgic viewpoint to get back to jeffs dockstar " script" approach which many people feel was just great.

(you can probably see where my "patching" defconfig thought came from here not knowing much about GIT or the linux kernel compilation process in detail)

* the script has a messy workaround for the time when the GIT uboot code wasnt working

hope it helps ...

http://rhombus-tech.net/allwinner_a10/hacking_the_mele_a1000/script_for_installing_debian_on_sdcard/



Edited 1 time(s). Last edit at 07/18/2012 02:25PM by hyena.

Quote
hyena
it would also be kind of nice from a nostalgic viewpoint to get back to jeffs dockstar " script" approach which many people feel was just great.

My Mele A2000 should be arriving this weekend. Stay tuned.

Quote

incl wheezy/SD card creation

I think there are some issues on that script in that respect also.

AFAIK armhf is only available in Sid. If so there is a conflict there with the preceding armhf line. I may be wrong on armhf. But it does not really matter. Wheezy is too old of a version for decent Arm support. Sid is VERY stable (never had an issue in over two years now on my Dockstar). So there is no excuse to use Wheezy. There are countless drawbacks to using it. I had Wheezy on my tablet's chroot, as it is the last one to support TDE. It runs like rubbish on the A10. The only distro I can recommend without getting nauseous is Sid. But I have not tried Ubuntu armhf. That may be a decent alternative.

That script is a decent starting template, however.

The only potential issue i would have with sid is that the version of perl running on wheezy still isnt supported in squeezebox server (despite me even compiling the squeezebox server CPAN modules to match) and presumably sid is more uptodate which can cause problems with things like squeezebox server which receive not much development effort and are a bit behind the times.

The great thing about using a script like this (or jeff's original one) is that you can (as the person that wrote the script did) just leave a few other options commented out (to let people choose) and make it quite flexible .. and cloning a SID script from a wheezy script should be one would have thought very easy .. but as you say there are quitre a few issues still in the script (and workarounds that probably are not needed now)

getting someone who is proficient in scripting with a knowledge of GIT/linux x-compilation together with someone who knows whats what in the mess on GIT that is the A10 linux would probably produce THE simple flexible way to install debian on the A10 for 99% of mere mortals much like jeff did for the dockstar ;-)

one issue to think about though is the frequency that crap commits kill GIT A10 and uboot code .. it might be better for the scripts to take stable GIT forks (if thats the right jargon) and update periodically when its been checked that the commits work.

rgds

ian

Quote

one issue to think about though is the frequency that crap commits kill GIT A10 and uboot code .. it might be better for the scripts to take stable GIT forks (if thats the right jargon) and update periodically when its been checked that the commits work.

That is why I can never resync my kernel git for this version. It could, and most likely would, break things, or at least make any comparisons impossible. You can't use git as a stable source. Things get changed and broken way too often. That is why there are normally stable sources, in addition to git, for most things like the kernel, u-boot, etc.

We can't go advising people to use git here, or to support its use. That is just asking for massive loads of trouble and nasty forum comments about broken things. I am with Jeff in saying that we will have to host our own kernel and u-boot binaries. Everything else can be pulled down from Debian via the scripts.

Git is great. But it is not a solution for end users. It should never be used in production systems or what we release here. We will have to just settle on a single git pull. Then build on that until a stable image with all the features we want is obtained.
Fortunately any major u-boot changes are very infrequent and are usually not critical. The kernel is another story. My idea is that we update at each allwinner version change, or any other changes that add new features or performance. Otherwise it is best to stick with what is known to be working successfully. Most kernel changes have little to no benefit for end users.

yep .. i totally agree GIT is a real "GIT" for newbies like me and caused much much too much pain :-)