[U-Boot] OMAP 3530 - BeagleBoard Rev. C4
Hi Tom,
Is anyone still attempting to boot the OMAP 3530 BeagleBoard with U-Boot master?
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_bea...
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.
Derald
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:
The thread ended without an apparent solution.
What does work is this patch from EEWiki:
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.
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. 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.
On Thu, May 5, 2016 at 10:46 AM, Tom Rini trini@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:
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_bea...
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
participants (3)
-
Derald D. Woods -
Derald Woods
-
Tom Rini