Hi Tom, On Tuesday 26 November 2013 08:06 PM, Tom Rini wrote: > 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 <lokeshvu...@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 <tr...@ti.com> and Sricharan R <r.sricha...@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.sricha...@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. After digging more into it, I observed few points Currently the Section memory map is like below. Section size start end .text 00005db0 40304350 4030a100 .rodata 000022a5 4030a100 4030c3a5 .data 000007f8 4030c3a8 4030cba0 .u_boot_list 000000a0 4030cba0 4030cc40
But as per TRM, SRAM memory map is given as below: start end Down loadable Image 40300000 4030C000 Public Stack 4030c000 4030d000 Looks like our data and u_boot_list sections are overlapping with Public stack. I compared the section map when I comment out the u_boot_list section in linker script. Below shows the description: Section size start end .text 000055e8 40304350 40309938 .rodata 00001e07 40309938 4030b73f .data 000007f8 4030b740 4030bf38 This doesn't overlap with our Public stack. So I did the follwoing change and tried CONFIG_SPL_TEXT_BASE to 0x40300000 CONFIG_SPL_MAX_SIZE to (0x4030C000 - CONFIG_SPL_TEXT_BASE) Then I am able to come to u-boot prompt. I compared the sections also, no overlapping happens. But the problem here is this change will not work on HS devices..:( Any suggestions ? Please correct me if I am wrong. Thanks and regards, Lokesh > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot