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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131126/ad7340a3/attachment.pgp>