Submit i.MX53 & i.MX28 Linux kernel patches

[admin]

Dear i.MX Developers,

We have created a maintenance GIT branch for both MX28 EVK and MX53 QSB platforms. The branch can be found at this  location:

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/

Branch name: imx_2.6.35_maintain

In the future we will be making bug fix/maintain releases for MX53QSB and MX28EVK platform from this branch.

Please submit any Linux kernel bug-fix patches that you might have to this discussion forum. Generate the patches against the imx_2.6.35_maintain branch, internally the Freescale BSP team will review these patches. Once approved for integration, your patches will be pushed to the above mentioned GIT repository branch.

Below are the steps to follow to submit your patches:

1.       Ensure you make your changes against the latest imx_2.6.35_maintain available at http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/

2.       Include an appropriate subject and description for your patch. Subject should include the platform name and driver being fixed.

3.       Use the below command to submit your patch.

git send-email -1 --to discussions-community-imx@freescale-phx.hosted.jivesoftware.com --subject-prefix=PATCH

Below are some sample GIT config files to make sure your patch submission e-mails get accepted by the i.MX Community forum.

[A] For developers outside the Freescale network using gmail:

[xxxx]$ more ~/.gitconfig

[user]

    email = <user>@gmail.com

    name = <user name>

[sendemail]

        smtpencryption = tls

        smtpserver = smtp.gmail.com

        smtpuser = <user>@gmail.com

        smtppass = ********

        smtpserverport = 587

[B] For developers inside the Freescale network:

[xxxx]$ more ~/.gitconfig

[user]

    email = <core id>@freescale.com

    name = <user name>

[sendemail]

        smtpserver = remotesmtp.freescale.net

        smtpserverport = 25

{Note: The e-mail & name should match what you used to register with community.freescale.com}

[TomE]

In almost all Freescale kernels for the i.MX25,  i.MX51 and i.MX53 (at least) the IOMUX pin programming is corrupted.

This is detailed here:

IMX53: Floating GPIO Pins due to MUX_PAD_CTRL(NO_PAD_CTRL) bug.

https://community.freescale.com/message/608067#

IOMUX pins default on CPU reset to high drive strength and weak pullups or pulldown resistors. Due to a bug in a patch that Freescale applies to most of their 2.6.35 kernels (and 2.6.38 Android ones), the IOMUXC_SW_PAD_CTL_PAD registers get overwritten with zero. This disables the pullups/pulldowns, the Hysteresis and forces low drive strength and slew rate. That may not be what the hardware design requires, and certainly isn't what the hardware designer assumed.

The bug is the definition of "NO_PAD_CTRL" in "arch/arm/plat-mxc/include/mach/iomux-v3.h" that shifts the mask too far, effectively disabling the function of "NO_PAD_CTRL".

This bug was made to the mainstream and appeared in 2.6.38:

http://lxr.free-electrons.com/source/arch/arm/plat-mxc/include/mach/iomux-v3.h?v=2.6.38

The bug was fixed between there and 3.1:

http://lxr.free-electrons.com/source/arch/arm/plat-mxc/include/mach/iomux-v3.h?v=3.1

The following (and attached) patch is the one that fixed this in the mainline. It applies to 2.6.35_maintain:

https://lkml.org/lkml/2011/9/28/573

http://lists.infradead.org/pipermail/linux-arm-kernel/2011-June/054695.html

There are other related bugs in the iomux setting that should be looked at as well, detailed here:

https://community.freescale.com/thread/384340

Tom

[TomE]

I seem to have missed adding this problem with this version of Linux to this list:

"i.MX Linux FEC Driver Drops IPV6 Multicasts & Promiscuous Setting".

https://community.nxp.com/message/536359

Tom

[TomE]

I missed adding this post, which details problems with the PWM Hardware that result in the outputs glitching. There have been multiple patches to these drivers, but they don't fix all the problems.

https://community.nxp.com/message/522832

Tom

[TomE]

The following patch leads to a compilation error when CONFIG_USB_STORAGE_DEBUG is enabled:

Author: Dinh Nguyen <r00091@freescale.com>  2009-12-11 14:08:45
Committer: Alan Tull <r80115@freescale.com>  2010-08-26 02:52:12
Parent: 39f2f080b39ceb7ccbc0da4bc13fea5698f7fa3a (usb-storage: always print quirks)
Child:  0000000000000000000000000000000000000000 (Local uncommitted changes, not checked in to index)
Branches:  remotes/origin/remote/freescale/imx_2.6.35, remotes/origin/remote/freescale/imx_2.6.35_1.1.0,
 remotes/origin/remote/freescale/imx_2.6.35_10.10.01, remotes/origin/remote/freescale/imx_2.6.35_10.11.01,
 remotes/origin/remote/freescale/imx_2.6.35_10.12.01, remotes/origin/remote/freescale/imx_2.6.35_11.04.01,
 remotes/origin/remote/freescale/imx_2.6.35_11.05.01, remotes/origin/remote/freescale/imx_2.6.35_11.09.01
, remotes/origin/remote/freescale/imx_2.6.35_android_r10.3, remotes/origin/remote/freescale/imx_2.6.35_maintain
Follows: v2.6.35.3
Precedes: imx-android-r10.4, rel_imx_2.6.35_10.10.01, rel_imx_2.6.35_10.11.01, rel_imx_2.6.35_10.12.01_RC4, rel_imx_2.6.35_11.03.00

    ENGR00118363 Fix SATA drive failure on Ubuntu 9.10
    
    Fix SATA drive failure on Ubuntu 9.10
    BugLink: https://bugs.launchpad.net/bugs/431963
    
    Signed-off-by: Dinh Nguyen <r00091@freescale.com>

@@ -334,8 +334,11 @@ static int usb_stor_control_thread(void * __us)
 
           /* we've got a command, let's do it! */
           else {
-               US_DEBUG(usb_stor_show_command(us->srb));
-               us->proto_handler(us->srb, us);
+               US_DEBUGP(usb_stor_show_command(us->srb));
+#ifdef CONFIG_MACH_MX51_BABBAGE
+               if (us->srb->cmnd[0] != 0x85)
+#endif
+                    us->proto_handler(us->srb, us);
           }

The accidental change from "US_DEBUG()" to "US_DEBUGP()" causes the following:

arm-linux-gnueabi-gcc -Wp,-MD,drivers/usb/storage/.usb.o.d ... -c -o drivers/usb/storage/usb.o drivers/usb/storage/usb.c
drivers/usb/storage/usb.c: In function ‘usb_stor_control_thread’:
drivers/usb/storage/usb.c:337:4: error: expected ‘)’ before ‘usb_stor_show_command’
make[3]: *** [drivers/usb/storage/usb.o] Error 1
make[2]: *** [drivers/usb/storage] Error 2
make[1]: *** [drivers/usb] Error 2
make: *** [drivers] Error 2

Tom

[TomE]

Here's some patches to get the FlexCAN driver working.

Bugs detailed here:

https://community.freescale.com/message/593606

https://community.freescale.com/thread/381075

[TomE]

The Freescale Linux 2.6.35 FlexCAN driver has an interrupt hazard that causes the transmitter to lock up. This is detailed here:

https://community.freescale.com/message/593606

The patch to fix this one (applied after the other four patches) is here:

Tom

[TomE]

If you have a disconnected CAN bus (no other devices on it), but you attempt to send a message, you can seriously slow down the CPU.

This problem was covered half way down this post:

https://community.freescale.com/message/458619#458619
"Missing error-passive state interrupt"

If you've got both ports doing this on an i.MX53 at 1MBit/second, they generate 87,000 interrupt/second. This isn't too bad on an i.MX53, but on older and slower parts can take up most of the CPU.

"0006..." is a one-line patch to get rid of that at the expense of then not signalling any of the other error interrupts.

Tom

[TomE]

The FlexCAN Driver Bus Off Recovery code doesn't work at all. It shuts the port down with a "soft reset" and then never brings it back.

Details here:

https://community.freescale.com/message/599099#599099

Patch file to fix it is the "0008" one. This probably isn't a complete fix as the standard error-socket signalling may not work. We don't need that so I haven't tested this.

As a separate minor problem, the driver doesn't support the interface that allows CAN states and errors to be retrieved. In our code we need access to the Receive and Transmit Error Counters. The "0007" patch adds that. I can't see it being useful to anyone else - we've got a standard CAN device interface that has this.

Tom

[MichaelMcTernan]

Does this mean MX53 will only be supported on 2.6.35 forever?  What happened to Freescale's Linaro effort?

[admin]

This GIT repository is used for patches on that kernel, but other repositories may be established to capture patches for future releases.

[sinanakman]

Hi Grant, thanks for the effort for coordinating potential patches for 2.6.35. I just wonder wouldn't it be easier for everyone if we all kept supporting mainline instead of a specific old kernel version. The reason I am suggesting this, there will be many fixes/patches would have to go into that 2.6.35 that has probably already part of mainline. I feel focusing on a mainline kernel and making sure it supports your boards completely and continuously would be probably beneficial for everyone and would have much wider contribution base. If there are many patches in your 2.6.35 and not in mainline yet, we should probably encourage people to try to mainline them as much as possible. This will keep everything much more alive. I just thought I'd bring up that perspective.

Regards

Sinan Akman

[a_l_e-x]

Very much agree with Sinan.

I should be able to apply a set of i.mx53 QSB related Linux kernel PATCHES over the latest mainline ( plain vanilla ) kernel, from the source root, and just able to build and install in SD-CARD and boot from QSB. I assume a working rootFS available.

Is there a place/link/website, from where I can download these patches, available as a tar/zip file or from a git repository ??

Thanks

Alx

P.S -- I already have a booting/working kernel+FS from yocto for my QSB, but I want to do from scratch. Hence my above post.

[TomE]

I suspect the "maintain branch" has been partially obsoleted by the 2.6.38 branches (although 2.6.35_maintain is two years newer than them).

For various historical reasons I'm stuck on 2.6.35 and started from the above-mentioned "2.6.35_maintain" branch.

But the eCSPI driver has all sorts of problems in that version. It only works with 8-bit transfers (12, 16, 24, 32 don't work at all), doesn't support "GPIO Chip Select" and generates way out of spec baud rates. It was completely replaced with a "mainline derived" version in 2.6.38 that fixes all these problems, but we can't easily use that version.

I reported the problems in the following thread, and there are patches there to fix the various problems.

https://community.freescale.com/message/585208#585208

I don't have a Freescale Development Kit so can't generate or TEST patches to run on them, so I can't follow the instructions in this thread. The patches in the above link should be enough to get anyone out of trouble and could form the basis for a set of "real patches" to the "maintain branch" if anyone wants to do them.

Tom

[TomE]

Kernel 2.6.35 (and 2.6.35_maintain) has a bug that causes problems with the ECSPI hardware, and may also cause PWM problems as well.

The Kernel sets up the ECSPI and PWM IPG clocks to turn off when the CPU goes into idle. That stops the ECSPI transmissions dead when the CPU goes idle!

The investigation of this is documented here:

https://community.freescale.com/message/585911#585911

I've attached a patch that fixes it on 2.6.35.

Tom