Hello,
I just tried Linux 3.8.1 on iMX233 OLinuXino Micro and could not boot. Because I don't have a console I am using the LED as debug output. Until now I found two problems:
The LED output is inversed;
microSD not detected.
There is no mmcblk* device in the devtmpfs. If I manually mknod them the mmcblk* devices are still not usable. I suspect this problem is related to the inversed output. So what should I do next?
Thanks in advance!
Hi,
No problem for me.
I've built kernel and dtb file, put them on sdcard and boot with uboot.
Led is green as expected.
For the first issue:
can you try reverting https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/imx23-olinuxino.dts?id=b34aa18502446379494529b863eb0743856b1a25 ?
For the second one, I need to check Are you using both dts and kernel from 3.8.1?
It would be nice if you could have a serial console to extract some logs to help debugging.
Thank you both!
I reverted the commit and everything worked again as before (like in 3.7.x), both LED and mmcblk.
BTW, I also added a line in my initrd to pipe messages through ethernet. I think this is easier than going out to find a level converter during this weekend :) (I do have a serial cable but it is 5V instead of 3.3V.)
Interesting, I do not understand why reverting my original commit fixed the mmc problem.
Any idea? Are you sure you are using both the dts and kernel from 3.8.1?
Also, Nill reported that he has no issues, so I am a bit confused here (I don't have my board handy).
By the way, can't we just start a thread at the Olimex yahoo groups? I found easier to reply to emails than forum.
Same question as Fabio.
Are you sure you use imx23-olinuxino.dtb from 3.8.1 for build your raw file ?
Quote from: Fabio Estevam on March 02, 2013, 11:07:31 PM
Interesting, I do not understand why reverting my original commit fixed the mmc problem.
Any idea? Are you sure you are using both the dts and kernel from 3.8.1?
Also, Nill reported that he has no issues, so I am a bit confused here (I don't have my board handy).
By the way, can't we just start a thread at the Olimex yahoo groups? I found easier to reply to emails than forum.
Yes both dts and kernel from the same version. It seems the LED is on the card detect pin. Am I mistaken? I will make more tests if you doubt it. Am now compiling the kernel because I want to apply every patch again to make sure of what I have done.
If the yahoo group the official olinuxino group? If so I will try to join that. Can I use that group without a yahoo account? I have only a google account.
Quote from: Niii on March 02, 2013, 11:31:43 PM
Same question as Fabio.
Are you sure you use imx23-olinuxino.dtb from 3.8.1 for build your raw file ?
I think so. I have been following every kernel update since 3.7 and when compiling a new kernel I always copy the old config but not the dts/dtb.
Quotebut not the dts/dtb.
That's the problem.
On each version, dts file might have an update.
You need to apply your modifications on recent dts file and build dtb file to avoid issue like this.
Quote from: Niii on March 03, 2013, 12:57:56 AM
Quotebut not the dts/dtb.
That's the problem.
On each version, dts file might have an update.
You need to apply your modifications on recent dts file and build dtb file to avoid issue like this.
What modifications specifically? I made no change before.
To make the kernel work properly no mod was necessary for the 3.7.x official dts, and the only mod needed for the 3.8.x dts is to revert the LED init lines to the same as that in 3.7.x, as Fabio suggested.
In your 3.8.1 kernel tree:
make imx23-olinuxino.dtb
Then take this generated dtb and use it with the kernel from 3.8.1.
This way you should have everything working without any patch.
Sorry, I am totally confused.
Niii says I should always use the old dts/dtb. I never did and it always worked.
Fabio says I should always use the new dts/dtb. I always did and it stopped working when I moved from Linux 3.7.10 to 3.8, until I reverted the change to the LED init code.
Can we sum up a little bit? Too many ends in this tangled thread ...
QuoteNiii says I should always use the old dts/dtb. I never did and it always worked.
What ? I don't say this, maybe I misspoke.
Like Fabio says, you should use dts file from your current archive kernel.
Apply your modifications like i2c/spi, but if you don't have modifications you can leave that part, the default file is ok.
Quoteand when compiling a new kernel I always copy the old config but not the dts/dtb.
QuoteFabio says I should always use the new dts/dtb. I always did and it stopped working when I moved from Linux 3.7.10 to 3.8
You never or you always use dts/dtb file from current kernel archive ? :)
Quote from: Niii on March 03, 2013, 02:11:41 AM
QuoteNiii says I should always use the old dts/dtb. I never did and it always worked.
What ? I don't say this, maybe I misspoke.
No you did not misspoke. I misunderstood.
Quote from: Niii on March 03, 2013, 02:11:41 AM
Quoteand when compiling a new kernel I always copy the old config but not the dts/dtb.
QuoteFabio says I should always use the new dts/dtb. I always did and it stopped working when I moved from Linux 3.7.10 to 3.8
You never or you always use dts/dtb file from current kernel archive ? :)
"I always copy the old config but not the (old) dts/dtb" -- from the old kernel.
i.e. Always use the dts coming from the same new kernel.
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
Guanx,
Does the .config differ between the 3.8 and 3.7 or are you using the same one?
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.
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
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.
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.
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?
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.
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.
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.
Exactly the same problem with Linux 3.9-rc1.
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
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
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 ?
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.
But, how you build your kernel from source ?
With what commands ?
Quote from: Niii on March 10, 2013, 12:32:54 PM
But, how you build your kernel from source ?
With what commands ?
With the command "make", after adding aufs3 to the kernel source.
No problem for me with 3.9-rc1 and aufs3, boot is ok and led is green.
If you need more help about this, you should explain a little more your process build ...
root@itx:~# dmesg | grep aufs
[ 0.940000] aufs 3.x-rcN-20130311
root@itx:~# uname -a
Linux itx 3.9.0-rc1 #1 Sun Mar 10 19:42:11 CET 2013 armv5tejl GNU/Linux
root@itx:~# mkdir /tmp/rw /tmp/aufs
root@itx:~# mount -t aufs -o br=/tmp/rw:${HOME} none /tmp/aufs
[ 74.200000] aufs test_add:264:mount[390]: uid/gid/perm /root 0/0/0700, 0/0/0755
root@itx:~# ls /tmp/aufs/
d.sh g.sh i2c-tool i2c-tool.c spi spi2 spi2.c spi.c
root@itx:~# df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 26M 0 26M 0% /lib/init/rw
udev 10M 28K 10M 1% /dev
tmpfs 26M 0 26M 0% /dev/shm
rootfs 1.9G 412M 1.4G 24% /
tmpfs 26M 12K 26M 1% /tmp
none 26M 12K 26M 1% /tmp/aufs
Ps : "aufs_type.h" file should be in "include/linux/" directory tree not in "include/uapi/linux/".
Quote from: Niii on March 10, 2013, 08:47:19 PM
No problem for me with 3.9-rc1 and aufs3, boot is ok and led is green.
Obviously because you did not try my test case. You did not even look at my kernel config, nor README, nor anything.
Quote from: Niii on March 10, 2013, 08:47:19 PM
If you need more help about this, you should explain a little more your process build ...
I can already fix it with Fabio's suggestion (to revert his patch) so I do not need more help about this. I fear that you and me cannot help the community regardless of my explaining more or not, because when I provide more information you simply overlook it.
Quote from: Niii on March 10, 2013, 08:47:19 PM
Ps : "aufs_type.h" file should be in "include/linux/" directory tree not in "include/uapi/linux/".
If you have a text editor you can open "include/linux/aufs_type.h" and find that that file simply #include <uapi/linux/aufs_type.h> and does nothing else.
Quote
Obviously because you did not try my test case. You did not even look at my kernel config, nor README, nor anything.
Because I don't want to search your modifications about config file .
If a clean build with aufs3 patch compile fine and boot is ok, for me error is somewhere else.
Quote
I can already fix it with Fabio's suggestion (to revert his patch) so I do not need more help about this.
I just don't understand why you need that patch when a clean build is ok, that's all.
Anyway, if all works for you with patch, I'll stop trying to understand why.
Guanx,
Please feel free to submit a patch to linux-arm-kernel mailing list reverting my LED patch.
I did not do this myself because I honestly do not understand why it would have caused any regression and I still didn't have time to look in details into this yet.
It seems that you were the only one that noticed it. Myself, Nii and Fadil were not able to see it in our tests.
So, please go ahead and submit a patch, adding an explanation in the commit log as to why it breaks things for you.
Thanks,
Fabio Estevam
Quote from: Niii on March 10, 2013, 09:56:02 PM
Because I don't want to search your modifications about config file .
I have provided a complete test case from source code to compiled binary and disk image. You can start directly from the disk image. No one asked you to look at the config file.
Quote from: Niii on March 10, 2013, 09:56:02 PM
If a clean build with aufs3 patch compile fine and boot is ok, for me error is somewhere else.
Your logic is that "If it works
somehow, everything
must be ok". This does not apply to kernel development.
Quote from: Niii on March 10, 2013, 09:56:02 PM
Quote
I can already fix it with Fabio's suggestion (to revert his patch) so I do not need more help about this.
I just don't understand why you need that patch when a clean build is ok, that's all.
Because Fabio's patch has already gone into the "clean" upstream. Therefore I need the patch to get it
reverted.
This is plain fact and is readily visible to anyone who has access to the official Linux kernel source. If you refuse to look at even the unmodified, official kernel source, I wonder why you post in this thread.
Quote from: Fabio Estevam on March 11, 2013, 05:15:43 PM
... I did not do this myself because I honestly do not understand why it would have caused any regression and I still didn't have time to look in details into this yet.
The same for me. Your patch, which has already gone into the official kernel, looks reasonable. I would not claim so curtly that your patch is causing problems.
I will leave the test case open for download. It should cost anybody less than one minute (not including the download time) to reproduce the problem.
Guan
Quote from: Fabio Estevam on March 11, 2013, 05:15:43 PM
Guanx,
Please feel free to submit a patch to linux-arm-kernel mailing list reverting my LED patch.
I did not do this myself because I honestly do not understand why it would have caused any regression and I still didn't have time to look in details into this yet.
It seems that you were the only one that noticed it. Myself, Nii and Fadil were not able to see it in our tests.
So, please go ahead and submit a patch, adding an explanation in the commit log as to why it breaks things for you.
Thanks,
Fabio Estevam
Hi Fabio,
Thank you very much for fixing the LED status!
commit e5cdd90cd72b16e49cec2357674f0d8c63e751df
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date: Tue Apr 14 11:05:04 2015 -0300
ARM: dts: imx23-olinuxino: Fix polarity of LED GPIO
Best regards,
Guan
Hi Guan,
Thanks for the feedback.
We still need a volunteer for upstreaming the mx23 audio support :-)
Regards,
Fabio Estevam