[U-Boot] OMAP 3530 - BeagleBoard Rev. C4

[Derald Woods]

On Thu, May 5, 2016 at 10:46 AM, Tom Rini <trini at konsulko.com> wrote:

> On Wed, May 04, 2016 at 10:45:09PM -0500, Derald D. Woods wrote:
>
> > Hi Tom,
> >
> > Is anyone still attempting to boot the OMAP 3530 BeagleBoard with
> > U-Boot master?
>
> Yes, but...
>
> > In order to boot my BeagleBoard Rev. C4, I need to basically
> > undefine CONFIG_SPL_EXT_SUPPORT and CONFIG_SYS_THUMB_BUILD.
> >
> > There is some background in this old thread from last year:
> > - http://lists.denx.de/pipermail/u-boot/2015-July/220332.html
> >
> > The thread ended without an apparent solution.
> >
> > What does work is this patch from EEWiki:
> > -
> https://github.com/eewiki/u-boot-patches/blob/master/v2016.03/0001-omap3_beagle-uEnv.txt-bootz-n-fixes.patch
> >
> > If there is some additional useful information, I would be happy to
> > take a look.
> >
> > I use the board for testing generic code intended for other OMAP3
> systems.
>
> So, here's where things are hard, and well, arg.  I really don't want to
> throw out SPL_EXT support from beagleboard as that's one of the generic
> distro features which is used by distros.
>
>
OK.


> So here's what I've come up with.  For older (pre gcc-6.x) toolchains,
> with the patch that I will do for the next release to allow maximizing
> the download space, shuffling some of board/ti/beagle/beagle.c around to
> hide some functions (and _strings_ most importantly) that we don't need
> in SPL to shove under !CONFIG_SPL_BUILD, disabling falcon mode and SPL
> I2C (we initialize but don't appear to use in this case) and dropping
> ISO partition support (strings and we don't need in this case), I can
> get omap3_beagle back into size constraints with thumb build disabled.
>


That sounds reasonable. I can now see why migrating older OMAP3 boards to
'Kconfig', with bootable defaults, is really important. For now, I can
continue tracking master with a side patch. I will take a look at the
default configuration after the release.

Thanks for the detailed response. It is appreciated.

Derald



> We appear to have all of the required errata enabled but it's also a
> known nest of problems to get the right ones on (or disabled) depending
> on exact CPU revision.
>
> --
> Tom
>