[U-Boot] Question regarding MLO size
Hi all,
I am using a Gumstix Overo (omap3), running the u-boot v2015.04 and have the following issue:
I have made a few modifications to the misc_init_r() routine in the board/overo/overo.c file; the resulting MLO file is 61,220 bytes and the console hangs at "reading u-boot.img" during the boot process. In the absence of those changes to the misc_init_r() the MLO size is 61,212 bytes and the u-boot is loaded without any issues.
misc_init_r() is not even called from any SPL related code, so I am not sure why changes to this routine is causing MLO size to change. I verified this by doing the following: I put a few debug statements in misc_init_r() and rebuilt both u-boot.img and MLO. First, I replaced only the new MLO in my target and the debug statement did not appear while it appeared when I replaced the u-boot.img in the target.
If anybody has an idea what is going on, it would be very helpful. Thanks!
FYI: The change I am trying to make in misc_init_r() : @@ -295,6 +295,7 @@ int misc_init_r(void) expansion_config.fab_revision); MUX_GUMSTIX(); setenv("defaultdisplay", "lcd35"); + setenv("expansionname", "palo35"); break; case GUMSTIX_PALO43: printf("Recognized Palo43 expansion board (rev %d %s)\n",
-Arun
On Tue, Apr 21, 2015 at 11:56:05AM -0700, Arun Bharadwaj wrote:
Hi all,
I am using a Gumstix Overo (omap3), running the u-boot v2015.04 and have the following issue:
I have made a few modifications to the misc_init_r() routine in the board/overo/overo.c file; the resulting MLO file is 61,220 bytes and the console hangs at "reading u-boot.img" during the boot process. In the absence of those changes to the misc_init_r() the MLO size is 61,212 bytes and the u-boot is loaded without any issues.
misc_init_r() is not even called from any SPL related code, so I am not sure why changes to this routine is causing MLO size to change. I verified this by doing the following: I put a few debug statements in misc_init_r() and rebuilt both u-boot.img and MLO. First, I replaced only the new MLO in my target and the debug statement did not appear while it appeared when I replaced the u-boot.img in the target.
If anybody has an idea what is going on, it would be very helpful. Thanks!
You're running into https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 which is that even if the function is being garbage collected the strings are not. Sadly it may make sense to move some SPL-only functions out into a file that is only built/linked for SPL due to this bug.
On Tue, Apr 21, 2015 at 12:23 PM, Tom Rini trini@konsulko.com wrote:
Sadly it may make sense to move some SPL-only functions out into a file that is only built/linked for SPL due to this bug.
Ah---that is a funky bug. Is it reasonable to wrap the offending lines in a #ifndef CONFIG_SPL_BUILD <u-boot code with strings that bloat SPL> #endif // CONFIG_SPL_BUILD ? Would this restrict it to be included only in u-boot (where the code is needed) rather than getting unnecessarily pulled into SPL?
--Ash
On Tue, Apr 21, 2015 at 01:12:37PM -0700, Ash Charles wrote:
On Tue, Apr 21, 2015 at 12:23 PM, Tom Rini trini@konsulko.com wrote:
Sadly it may make sense to move some SPL-only functions out into a file that is only built/linked for SPL due to this bug.
Ah---that is a funky bug. Is it reasonable to wrap the offending lines in a #ifndef CONFIG_SPL_BUILD
<u-boot code with strings that bloat SPL> #endif // CONFIG_SPL_BUILD ? Would this restrict it to be included only in u-boot (where the code is needed) rather than getting unnecessarily pulled into SPL?
That starts getting pretty messy looking which is why I was thinking of following the mx6 model of having boardname.c and boardname_spl.c or just board.c and spl.c
Hi Tom,
Thanks for your inputs. I have cleaned up the board/overo/ code like you suggested. I will send a separate email with the patches requesting for review.
-Arun
On Tue, Apr 21, 2015 at 1:16 PM, Tom Rini trini@konsulko.com wrote:
On Tue, Apr 21, 2015 at 01:12:37PM -0700, Ash Charles wrote:
On Tue, Apr 21, 2015 at 12:23 PM, Tom Rini trini@konsulko.com wrote:
Sadly it may make sense to move some SPL-only functions out into a file that is only built/linked for SPL due to this bug.
Ah---that is a funky bug. Is it reasonable to wrap the offending lines in a #ifndef CONFIG_SPL_BUILD
<u-boot code with strings that bloat SPL> #endif // CONFIG_SPL_BUILD ? Would this restrict it to be included only in u-boot (where the code is needed) rather than getting unnecessarily pulled into SPL?
That starts getting pretty messy looking which is why I was thinking of following the mx6 model of having boardname.c and boardname_spl.c or just board.c and spl.c
-- Tom
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
participants (3)
-
Arun Bharadwaj -
Ash Charles -
Tom Rini