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 <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 ?
>
> 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
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
