Linux 3.8.1 pin output inversed, cannot boot

[Niii]

But, how you build your kernel from source ?
With what commands ?

[guanx]

But, how you build your kernel from source ?
With what commands ?

With the command "make", after adding aufs3 to the kernel source.

[Niii]

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

Code Select Expand


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/".

[guanx]

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.

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.

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.

[Niii]

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.

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.

[Fabio Estevam]

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

[guanx]

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.

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.

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.

[guanx]

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

[guanx]

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

[Fabio Estevam]

Hi Guan,

Thanks for the feedback.

We still need a volunteer for upstreaming the mx23 audio support :-)

Regards,

Fabio Estevam