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

[Lokesh Vutla]

On Wednesday 04 December 2013 02:07 AM, Tom Rini wrote:
> On Fri, Nov 29, 2013 at 01:48:12PM +0530, Lokesh Vutla wrote:
>> 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 at 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 at ti.com> and Sricharan R <r.sricharan at 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 at 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 ?
> 
> I think we're at the point where OMAP4 HS devices will need to be
> supported in a separate build from OMAP4 non-HS devices.  There's ways
> forward for them still, I spent a bit hacking things out, but without
> removing functionality and I made it all fit again, mainly moving some
> strings to debug so we optimized them out, and ifndef'ing out some
> functions that we discarded, but had strings that we couldn't drop :(
> 
> So  lets correct the MAX_SIZE and move TEXT_BASE down to the non-HS
> limit, and if people need OMAP4 HS devices working in mainline U-Boot we
> can start doing more re-factoring of files to work around the gcc
> strings issue.
Thanks Tom, Will post a patch for correcting MAX_SIZE and move TEXT_BASE.

Regards,
Lokesh
>