[U-Boot] No single character output after update to latest u-boot on pandaboard

[Lokesh Vutla <lokeshvutla@ti.com>]

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



>