Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hi Mads,

We are actually considering moving all of our SOM linux capable products to Yocto (which is pretty close given we already have a chunk of the meta-mitydsp layers complete). Are the failures you are dealing with a result of the local packages/recipes from Critical Link not being available? YOu can work around that by simply removing them to start. They are not critical to getting a bootable image up and running (or just make a basic console image recipe).

The TI images might work if you replace the u-Boot and Kernel images with the ones from Critical Link. Our git server has a meta-mitydsp layer with recipes to build these images up using bitbake that you could clone.

My guess is that the startup scripts from TI are looking at the wrong UARTS and/or the kernel pin-mux logic is not consistent with the MityDSP-L138 SOMs.

Can you post details of your OE build failures (or send them to me via email?)

-Mike

Hello,

I have decided to use the Yocto framework for building my rootfs. Together with the 3.2 kernel compiled from the critical link git repository, I am able to to bring up all the resources that I need except for one - the sata interface. After enabling it in the kernel config the following lines were showing up in the kernel log just as in the stock 2.6.34 kernel delivered with the card:

ahci ahci: forcing PORTS_IMPL to 0x1
ahci ahci: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
ahci ahci: flags: ncq sntf pm led clo only pmp pio slum part ccc
scsi0 : ahci
ata1: SATA max UDMA/133 irq 67

However, when I connect a disk, the two kernels reacts different:

2.6.34 kernel - detecting and mounting nicely:

ata1: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0xe frozen
ata1: irq_stat 0x00400040, connection status changed
ata1: SError: { RecovComm PHYRdyChg CommWake DevExch }
ata1: hard resetting link
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-8: Corsair Accelerator SSD, 5.02, max UDMA/133
ata1.00: 117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
ata1.00: configured for UDMA/133
ata1: EH complete
scsi 0:0:0:0: Direct-Access ATA Corsair Accelera 5.02 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 117231408 512-byte logical blocks: (60.0 GB/55.8 GiB)
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI disk
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sda.
kjournald starting. Commit interval 5 seconds
EXT3-fs (sda1): using internal journal
EXT3-fs (sda1): recovery complete
EXT3-fs (sda1): mounted filesystem with writeback data mode

The 3.2 kernel fails:

ata1: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0xe frozen
ata1: irq_stat 0x00400040, connection status changed
ata1: SError: { RecovComm PHYRdyChg CommWake DevExch }
ata1: hard resetting link
ata1: link is slow to respond, please be patient (ready=0)
ata1: softreset failed (device not ready)
ata1: hard resetting link
ata1: link is slow to respond, please be patient (ready=0)
ata1: softreset failed (device not ready)
ata1: hard resetting link
ata1: link is slow to respond, please be patient (ready=0)

Any obvious reason for this? - Still some more kernel configuration required or is there a more relevant branch in the critical link git repository that I should use. (The reason that I cannot use the 2.6.34 kernel is that udevd in my new file system does not work with this kernel. The meta-ti layer in Yocto 1.3 has only support for kernel 2.6.37 for the am81xx.)

Mads-l

Hello,

We've actually seen this issue on both kernels, and in general have traced the issue back to an Errata on the OMAP-L138/AM-1808 SATA controller - there is an issue with the link negotiation with SATA-III based drives that causes the controller to potentially timeout repeatedly. Are you using a SATA-III or SATA-II drive? Many SATA-III drives have jumpers to force SATA-II link speeds. This has worked for us in the past (with either kernel).

If the problem is reproducible between the two kernel builds (tracks the software, as you suggest), then this is news for Critical Link. I can check the differences in the driver, I know there may be a patch or two on the older kernel that may not have been submitted to the mainline by TI. (our 2.6.XX kernels were tracking TI's PSP development tree, but TI kept rewriting history on their servers which made tracking updates nearly impossible, our 3.XX kernels now track the mainline which allows a very easy path to upgrade to newer released kernels).

-Mike

Hi,

Just compared the drivers/ata for kernel version 2.6.34 and 3.2. It seems obvious that the 3.2 branch is lacking a lot... The ahci-ti.c file is not even present in the 3.2 branch. Is there another branch which has this issue fixed? Is it possible to apply a patch for this?

Mads-l

Hello,

I'm fairly certain that TI submitted the ahci-ti.c stuff originally in their PSP into the mainline and it got shuffled around a bit. That code is primarily platform specific and the driver folks wanted it out of the driver area. I think the bulk of what is in ahci-ti.c is now located in the arch/arm/mach-davinci/devices-da8xx.c in the da850_sata_init() call.

My understanding is that pretty much everything that was originally in the PSP is now in the mainline (which the 3.2 kernel is derived from, and there is a 3.5 branch and we'll be also porting up to 3.7 soon). The original 2.6.34 / TI PSP code had a lot of out-of-tree patches that could not be reliably tracked. This is why we transitioned to following the mainline from 3.1 and forward. TI has been incrementally submitting all of the PSP patches to the mainline, and a lot of it has been reworked as it was reviewed by the full linux community. It's not a great answer, and simply comparing the code base is not as trivial as looking for missing files such as the case of the SATA/AHCI support.

Can you please confirm if you tested more than once and the problem follows the software and is not a random failure as mentioned in my last post? Are you using a SATA-II drive or a SATA-III drive?

Thanks.

-Mike

Hi,

Mike, thanks for your clarification.

I have two sata disks, one SSD which is sata-II (3.0gb) and one old mechanical drive which is sata-I (1.5gb). What I experience is:

kernel 2.6.34 from git/SSD drive:
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-8: Corsair Accelerator SSD, 5.02, max UDMA/133
ata1.00: 117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
ata1.00: configured for UDMA/133
kernel 2.6.34/HD drive:
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7: Hitachi HTS541680J9SA00, SB2OC7BP, max UDMA/100
ata1.00: 156301488 sectors, multi 0: LBA48
ata1.00: configured for UDMA/100

Kernel 3.2 from git SSD drive and HD drive
ata1: link is slow to respond, please be patient (ready=0)
ata1: softreset failed (device not ready)
ata1: link is slow to respond, please be patient (ready=0)
ata1: softreset failed (device not ready)
ata1: link is slow to respond, please be patient (ready=0)
ata1: softreset failed (device not ready)
ata1: limiting SATA link speed to 1.5 Gbps
ata1: softreset failed (device not ready)
ata1: reset failed, giving up

I have also compiled and tried branch 3.1 and 3.5 from the git repository - same problem as 3.2
Please note that the "industrial config" for the 3.x kernels has the config parameter "Platform AHCI SATA support" disabled. Without this parameter set, the sata interface was not enabled, so I had to enable this parameter, could there be some more missing? This parameter was enabled by default in 2.6.34.

I have booted a lot of times, the 2.6.34 kernel is absolute stable when it comes to this issue - detecting both disks every time, while the 3.x kernels have never worked.

regards

Mads-l

Thanks for the information.

We have at least one active customer using the 3.2 kernel on an Industrial-IO board with Seagate SATA-II drive (here is a link to the drive) that does not present this issue. It is using a MityDSP-L138F, but the OMAP-L138 and AM-1808 are supposed to have the same controlling silicon for the SATA control. We actually have a unit running in the lab here with this configuration. So I am also wondering if this is configuration issue.

I am attaching the config file for the kernel that they are running (from "zcat /proc/config.gz"). Do you mind trying this configuration out and seeing if there is a difference in the connection with the 3.2 kernel? I am assuming you are using the Industrial I/O board for testing?

Thanks.

-Mike

Mike,

You are right - it was a config problem. By comparing the config you attached with the default "industial io config" I was able to pin point the problem. In the "industial IO config" from git repository the "Plaform AHCI SATA support" CONFIG_SATA_AHCI_PLATFORM was not set. I have recognized this, but the thing that caused the trouble was that "SATA Port Multiplier support" CONFIG_SATA_PMP was set in the default config. Turning it off fixed the problem. It may be a good thing fixing these two parameters in the "industrial io default config" to reflect a minimal sata solution as the 2.6.34 kernel supports. Anyway I am happy right now!