On Wed, 2013-12-04 at 00:50 +0800, Niew, Sh. wrote: > On Tue, Dec 3, 2013 at 4:44 PM, Ian Campbell <i...@hellion.org.uk> wrote: > > It looks like the old imx flavour only had CONFIG_PATA_IMX=m and this > > was carried over to the armmp flavour. It looks like AHCI_IMX was never > > enabled. > > > > I suppose the pata driver isn't working for you? Did you ever try the > > old imx flavour and did it work? > > You mean the *-mx5 kernel package? > I don't think it can boot in Boundary Devices SABRELite board, which is i.MX6 > And i did try...
Sorry, I keep forgetting that the old flavour was mx5 not mx*. > > In general the move has been from PATA to AHCI, I suppose we ought to > > transition here too? Does AHCI_IMX actually work if enabled? > > I tried recompiled the debian kernel 3.11-2-armmp_3.11.8-1_armhf > with a single add module AHCI_IMX, but it failed too... > The board did bootup but drop me in initramfs, and i tried modprobe > modules ahci_platform and ahci_imx, but it just don't work... > > Also, the DT blob that i testing is the imx6q-sabrelite.dtb > which include in the package and install in /usr/lib/`uname -r` > > Finally, I take a look to the linux-source-3.11 and figure out that the > DT source is neither defined any SATA or AHCI related in > imx6q-sabrelite.dts nor imx6q.dtsi... > > Probably, no chance. I can't actually see any device tree which declare a device compatible with fsl,imx6q-ahciq, which is what the driver binds too. Very suspicious... I'm going to enable AHCI_IMX anyway, assuming it at least builds for me. The DTS thing is something which would be best resolved by you approaching the upstream developers directly. Ian.
signature.asc
Description: This is a digitally signed message part
