Linux 3.8.1 pin output inversed, cannot boot

Started by guanx, March 02, 2013, 04:40:31 PM

Previous topic - Next topic

Fabio Estevam

Guanx,

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

guanx

Quote from: Kean on March 03, 2013, 08:28:00 AM
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

Quote from: Fabio Estevam on March 03, 2013, 02:28:20 PM
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

Quote from: Fabio Estevam on March 03, 2013, 04:27:41 PM
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

Quote from: Fabio Estevam on March 03, 2013, 04:36:40 PM
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

Quote from: guanx on March 03, 2013, 04:49:54 PM
Quote from: Fabio Estevam on March 03, 2013, 04:27:41 PM
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

#23
Quote from: Fabio Estevam on March 03, 2013, 05:06:13 PM
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 ?


guanx

#29
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.