Linux 3.8.1 pin output inversed, cannot boot

[Fabio Estevam]

Guanx,

Does the .config differ between the 3.8 and 3.7 or are you using the same one?

[guanx]

Guanx, FYI you can still use your 5V debug cable to capture the console output - just don't connect all the wires - just the GND and TxD out of the iMX233 to the RxD of the cable.  Leave RxD on the iMX233 (TxD of the cable) unconnected.  The logic voltage thresholds may be out of spec, but it generally works.  Kean

Thank you, Kean. Good idea.

[guanx]

Guanx,

Does the .config differ between the 3.8 and 3.7 or are you using the same one?

They are different because 3.8 cannot use the same old one. Looks like I can't attach files here, so please find the configs under the links:

http://5mao.bbsindex.com/tmp/config-3.7.10
http://5mao.bbsindex.com/tmp/config-3.8.1

[Fabio Estevam]

Ok, on 3.7 config you have:
CONFIG_LEDS_TRIGGER_GPIO=y

and on 3.8:

# CONFIG_LEDS_TRIGGER_GPIO is not set

Please select CONFIG_LEDS_TRIGGER_GPIO=y in 3.8 config and LED should work as well.

[Fabio Estevam]

Also, and this mismatch happens because you are not generating your .config from mxs_defconfig.

mxs_defconfig does have CONFIG_LEDS_TRIGGER_GPIO=y selected on 3.8.1.

You can see it at:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/configs/mxs_defconfig?id=refs/tags/v3.8.1

When building your kernel you should do:

make mxs_defconfig
make -j4 uImage

and then the LED will turn on.

[guanx]

Ok, on 3.7 config you have:
CONFIG_LEDS_TRIGGER_GPIO=y

and on 3.8:

# CONFIG_LEDS_TRIGGER_GPIO is not set

Please select CONFIG_LEDS_TRIGGER_GPIO=y in 3.8 config and LED should work as well.

In the beginning I did not remove this option. So when I started this thread this option was set.

Also, I tried to set this option and rebuild the kernel just now then saw it does not affect this problem. What does have a definitive effect is the change you suggested me to revert in the dts.

I tested:
CONFIG_LEDS_TRIGGER_GPIO=y   gpios = <&gpio2 1 1>; Inverted LED signal, microSD not detected
CONFIG_LEDS_TRIGGER_GPIO=y   gpios = <&gpio2 1 0>; linux,default-trigger = "default-on";   Works
CONFIG_LEDS_TRIGGER_GPIO=n   gpios = <&gpio2 1 0>; linux,default-trigger = "default-on";   Works


Is this because the LED shares the card detect pin?

[guanx]

Also, and this mismatch happens because you are not generating your .config from mxs_defconfig.

mxs_defconfig does have CONFIG_LEDS_TRIGGER_GPIO=y selected on 3.8.1.

You can see it at:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/configs/mxs_defconfig?id=refs/tags/v3.8.1

When building your kernel you should do:

make mxs_defconfig
make -j4 uImage

and then the LED will turn on.

No I manually removed it along with few other things when making menuconfig AFTER I modified the dts to get a working 3.8 kernel. I removed this specific option because from its help text it seems to be unuseful.

[Fabio Estevam]

Ok, on 3.7 config you have:
CONFIG_LEDS_TRIGGER_GPIO=y

and on 3.8:

# CONFIG_LEDS_TRIGGER_GPIO is not set

Please select CONFIG_LEDS_TRIGGER_GPIO=y in 3.8 config and LED should work as well.

In the beginning I did not remove this option. So when I started this thread this option was set.

Also, I tried to set this option and rebuild the kernel just now then saw it does not affect this problem. What does have a definitive effect is the change you suggested me to revert in the dts.

I tested:
CONFIG_LEDS_TRIGGER_GPIO=y   gpios = <&gpio2 1 1>; Inverted LED signal, microSD not detected
CONFIG_LEDS_TRIGGER_GPIO=y   gpios = <&gpio2 1 0>; linux,default-trigger = "default-on";   Works
CONFIG_LEDS_TRIGGER_GPIO=n   gpios = <&gpio2 1 0>; linux,default-trigger = "default-on";   Works


Is this because the LED shares the card detect pin?

I will test this on my board during the week.

Can you test this change below, please?

            led_pin_gpio2_1: led_gpio2_1@0 {
               reg = <0>;
               fsl,pinmux-ids = <
                  0x2013 /* MX23_PAD_SSP1_DETECT__GPIO_2_1 */
               >;
               fsl,drive-strength = <0>;
               fsl,voltage = <1>;
               fsl,pull-up = <1>;
            };
         };

I changed fsl, pull-up from 0 to 1 in the board dts.

[guanx]

I will test this on my board during the week.

Can you test this change below, please?

            led_pin_gpio2_1: led_gpio2_1@0 {
               reg = <0>;
               fsl,pinmux-ids = <
                  0x2013 /* MX23_PAD_SSP1_DETECT__GPIO_2_1 */
               >;
               fsl,drive-strength = <0>;
               fsl,voltage = <1>;
               fsl,pull-up = <1>;
            };
         };

I changed fsl, pull-up from 0 to 1 in the board dts.

No effect. Same problem.

[guanx]

Exactly the same problem with Linux 3.9-rc1.

[Fabio Estevam]

Ok, I haven't gotten a chance to work on it yet.

Will revert my patch if it really causes the breakage.

Regards,

Fabio Estevam

[guanx]

I'm not sure if it is your patch or something else that should get fixed. Possibly your patch only exposed another bug ...

Am having too little time on my hobby recently and got no time to reason it out, sorry!

Regards,
Guan

[Niii]

No problem for me with 3.9-rc1 on imx233 micro
Default mxs build for zImage and imx23-olinuxino.dtb.
Boot with uboot is ok and led is green.

Guanx, how can I reproduce problem ?

[Fadil Berisha]

No problem for me too. 

[guanx]

I put a ***working*** disk image here:
http://5mao.bbsindex.com/iMX233-OLinuXino-MICRO/disk_image/
This whole-disk-image has Linux 3.7.10. To use Linux 3.8.2 or 3.9-rc1, follow the instructions in the README file.

I cannot guarantee failure by using the Linux 3.8.2 and 3.9-rc1 images here. This is because a non-properly initialized state can be undefined and not a defined incorrect value.