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
