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