Q: i.Mx53 and a kernel based on our latest Linux BSP (Kernel Version 2.6.35) – They do see problems when mounting SATA Disk which is used for their rootfs.
Has anyone seen this before? I am just wondering if the upcoming release might address and fix this?
From the MCU i MX Product Update Call_May 2013.ppt presentation
- i.MX53 external release June 30th 2013, freescale.com
• There will be patches/features for i.MX53 including Yocto for this kernel L2.6.35 BSP release
• Validation testing
Where can I check which patches / features are in this release? Is there already a Release Note?
this is the kernel for the legacy release:
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_maintain
The main proposal for the next legacy release is not upgrade kernel, is only make a yocto release.
And if you take meta-fsl-arm on master you will find everything from legacy release. I upstreamed every change I made internaly
A:
Rootwait is in the command line. Please note they can boot with Kernel version 3.2 - but customer requires 2.6.35 Kernel for other reasons.
Please find attached the log files I received.
A text bootlog (note sometimes booting works) but it is not stable and reliable on 2.6.35 - same HW seems stable on 3.2 Kernel
Regarding to the failed messages contained in customer's log, it's a random issue. SATA driver reports that there is an " SError: { DevExch }" on the PHY connection.
It seems that the SATA PHY connection is not stable enough.
Can you make a double check on the cable connection and the power supply?
You can disable the following configuration when build the 2.6.35 kernel image
config SATA_AHCI_FSL_NO_HOTPLUG_MODE
bool "Freescale i.MX SATA AHCI NO HOTPLUG mode"
depends on SATA_AHCI_PLATFORM != n
default n
help
In order to decrease the pwr consumption, release the CLK resources such as usb_phy1_clk, when there is no SATA device adaptored into the AHCI SATA port. The HOTPLUG feature can't be enabled in this situation. Please disable this option if the HOTPLUG is mandatory required.
If unsure, say N.
============================
BTW, I just verified the RFS on SATA on i.MX53 LOCO. It's ok.
Here is the log:
Starting kernel ...
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.35.3-01275-ge6b3f3b (r65037@shlinux1) (gcc version 4.7.3 20121001 (prerelease) (crosstool-NG hg+-946d6d133a90) ) #52 PREEMPT Tue Jul 30 11:27:17 CST 2013
CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c53c7d
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Freescale MX53 LOCO Board
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 250880
Kernel command line: noinitrd console=ttymxc0,115200 root=/dev/sda1 rootwait rw
...
mxc_rtc mxc_rtc.0: setting system clock to 1970-01-01 00:00:01 UTC (1)
Waiting for root device /dev/sda1...
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: SanDisk SSD P4 32GB, SSD 8.00, max UDMA/133
ata1.00: 62533296 sectors, multi 1: LBA48
ata1.00: configured for UDMA/133
ata1: EH complete
scsi 0:0:0:0: Direct-Access ATA SanDisk SSD P4 3 SSD PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB)
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 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
VFS: Mounted root (ext2 filesystem) on device 8:1.
Is there a possibility to tweak timing parameters? Maybe that could help to get it more robust?
Are there other parameters we can try to play with and could explain failing Sata RFS on some i.Mx53 boards?
I got more info from customers and also "hints" to other forum entries realted to that problem.
http://lists.debian.org/debian-arm/2012/03/msg00059.html
http://debian.2.n7.nabble.com/Linux-2-6-35-3-Kernel-for-ARM-and-SATA-problems-td1664800.html
"""
Linux version 2.6.35.3-mx53qsb (mike@ubuntu) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #3 PREEMPT Sat Mar 17 15:34:48 PDT 2012
CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Freescale MX53 LOCO Board
...
ata1: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 28
...
ata1: SATA link down (SStatus 1 SControl 300)
ata1: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen t4
ata1: irq_stat 0x00000040, connection status changed
ata1: SError: { DevExch }
ata1: hard resetting link
ata1: SATA link down (SStatus 1 SControl 300)
ata1: EH complete
"""
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=9&t=4256&start=175
As mentioned custoemr sees simlar problems with our test image.
Maybe one way to check, can you provide me our u-boot and uImae you did the test with? Customer confirmed their HW is compatible with MX53 LOCO Board so I would like to make sure they use correct SW and use what you tested.
A bit strange is also that this Problem shows never up on a 3.2 based kernel. However the end customer requires to stay on 2.6.35 for other reasons.
- kernel 3.2 which is able to initialize always.
- protocol logs for good and bad case
trans -p uImage.mx5.35
File keyword is ngbl7927a
Data transfer to Austin Transcend repository started.
File size is 2.94 MB.
Transfer Method: Serial with no encryption.
File 'uImage.mx5.35' (size 2.94 MB) transcended.
Retrieve the file with the keyword: ngbl7927a
TransWeb URL: http://transweb.freescale.net/index.cgi?go=KEYWORD&KEYWORD=ngbl7927a
This file will be deleted in three working days.
Local Deletion Time: Thu Aug 15 23:51:16 2013 CST
Greenwich Mean Time: Fri Aug 16 04:51:16 2013 GMT
I know that i.MX53 SATA doesn't have the adjust-window like the adjust window contained by i.MX6Q SATA.
As I know that we didn‘t release 3.2 kernel version BSP, right?
Regarding to the experience of ”http://debian.2.n7.nabble.com/Linux-2-6-35-3-Kernel-for-ARM-and-SATA-problems-td1664800.html”,
it seems that the updates of the SATA stack of Linux level up the timing-compatibility of SATA.
Derived from the URL listed above.
”I did trace the problems I having to the ahci code in the kernel not properly handling an ahci CONINIT event generated by my WD5000BEVT drive. Seems this drive has extra SATA features implemented so that it can be used in hot-plug arrays and these features aren't recognized by the kernel driver so it just seems to shut down the drive and ignore it. The other SATA drive that I do have working with the kernel doesn't implement the extra features so the kernel is happy. Presumably these problems were fixed in later kernels and the patches didn't make it into Freescales 2.6.35.3 branch. On the other hand, the kernel might be fine and the firmware in the drive isn't conforming to the ahci specs, but I think that wold cause problems with the drive on other systems. ”
This document was generated from the following discussion: i.MX53 Sata rootfs problem