On Tue, Nov 26, 2013 at 12:22:19PM +0530, Lokesh Vutla wrote:
Hi Chao, On Tuesday 26 November 2013 10:32 AM, Chao Xu wrote:
Thank you! Please see the inline reply.
On Mon, Nov 25, 2013 at 10:40 PM, Lokesh Vutla lokeshvutla@ti.com wrote:
Hi, On Tuesday 26 November 2013 09:55 AM, Abraham V. wrote:
Hello Chao, (cc R.Sricharan from TI)
Quite frankly, I have no idea why your pandaboard fails to work if CONFIG_SYS_ENABLE_PADS_ALL isn't defined in the omap4_common.h file. From the logs this patch was committed on 13/June/2012 by R.Sricharan. He might have a better explanation so I'm adding him to this discussion. The git log message says this,
If we enable CONFIG_SYS_ENABLE_PADS_ALL, pin mux for non essential pads for u-boot will be configured. Ideally this configuration should be taken care by kernel. This is the main reason to remove this config option. Due to this reason the following is added to ./doc/feature-removal-schedule.txt
"What: Remove CONFIG_SYS_ENABLE_PADS_ALL and CONFIG_SYS_CLOCKS_ENABLE_ALL When: Release v2013.07
Why: When set these options enable "all" of the pads and clocks found on OMAP4/5 platforms, so that the Linux Kernel does not have to. It has been agreed that this goes against the U-Boot design philosophy and since f3f98bb0 we have not enabled more than is used in U-Boot. The kernel has been updating drivers to enable rather than assume pads/clocks have been enabled already. Our expectation is that by v2013.07 a suitable kernel shall exist that does not need these options set for a reasonable I/O set to function.
Who: Tom Rini trini@ti.com and Sricharan R r.sricharan@ti.com"
Please let me know if I am not clear.
The explanation is crystal clear. So the setup of non-essential pins are left to the kernel. Then do I need to enable any linux kernel config options to instruct the kernel to take over? I just copied the old .config from my v3.7 kernel to build v3.12 kernel.
No need to enable any config in kernel for this. Your dts should contain the required pin mux details. I am not sure what is in 3.7 kernel. May be its good to use omap2plus_defconfig.
"ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
Currently on OMAP4/5 platforms, many kernel drivers are dependent upon the bootloaders for mux, dpll and clock configurations. This should not be the case and bootloaders should set only the minimum required for the uboot functionality and kernel boot. Note that this is going to break the kernel drivers. But this is the only way to get things fixed in the kernel. Signed-off-by: R Sricharan <r.sricharan@ti.com>"so I'm curious now. Chao - was your problem that uboot refused to start or were you seeing crashes in the linux kernel? If it's the former, then the kernel doesn't even come into the picture.
Yes even I am not clear at this point. Chao can you please clarify. Ideally the above config will not harm U-Boot to come up on your board.
I think it's the uboot refused to start. Because there was no single character from the serial port. I enabled the early_printk option in .config and added it to uEnv.txt. After I added the CONFIG_SYS_CLOCKS_ENABLE_ALL, the board can boot until "Starting Kernel". I then fixed some other issue of the kernel, like copy the .dtb to /media/boot, and then kernel booted just fine. I'm curious, too. Is there anything I can do to further debugging? Thank you both very much!
I think I got the problem. I grabbed my panda and tried latest mainline. As you said U-Boot didn't come up for me either. I did a bisect and verified which patch is causing th issue. Below is the patch which breaks omap4.
"6789e84 i2c, omap24xx: convert driver to new mutlibus/mutliadapter framework" I think because of the linker code added in this patch for omap-common/u-boot-spl.lds
. = ALIGN(4); .u_boot_list : { KEEP(*(SORT(.u_boot_list*_i2c_*))); } >.sram
If I comment out this code, u-boot comes up as usual. Tom/Heiko, can you give a pointer why this is causing the issue. Please correct me if I am wrong.
Those lines keep the i2c adapter information in the binary (see the lists created in the driver now) so that omap3_beagle for example works. I think we need some further digging going on here.