Hi On 07/12/2013 11:03 PM, Michael Cashwell wrote: > On Jul 11, 2013, at 1:29 PM, Tom Rini <[email protected]> wrote: > >> On Thu, Jul 11, 2013 at 01:01:30PM -0400, Michael Cashwell wrote: >>> I've been absent for a while and couldn't find a way to search the >>> list archives so I apologize if this has already been discussed? >>> >>> I've been fighting the SPL binary growing too large on OMAP4 (using >>> custom configs and features). It's annoying that too large just fails >>> to run with no build or runtime notice. But that's a different issue. >> >> What version are you using? When SPL is too large a build-time failure >> is expected. > > I've seen that happen in gross cases where it exceeds the 38K limit in > omap4_common.h's CONFIG_SPL_MAX_SIZE but I currently have two configs > that are both well below that size yet the larger one doesn't run. > > The larger MLO is 0x8a21 bytes (0x8c29 with the GP header) and _end is > 0x4030cd74. This loops endlessly at 0x30080. I get no console output. > Even if the additional code is buggy it's not called early enough to > prevent at least the banner from going out so I'm pretty sure it's the > ROM not even starting it. > > The smaller MLO is 0x757c bytes (0x7784 with the GP header) and _end is > 0x4030b8cc. This runs OK. > > I am still exploring. >
41K Jul 12 15:07 MLO I have an hybrid booting (serial + eMMC raw) or (sdcard + eMMC raw) both are working. Michael >> This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 which seems to >> have gotten little attention after initial triage. I guess I need to >> find a little time to show it's still there. > > Yes, I'd seen that. What I don't understand is why gcc doesn't just put > such strings into different sections like it does with its own __func__ > strings. Then it would all just work. > > I also don't get them implementing anonymous string merging while ignoring > GC. Both are size optimizations and the one they don't seem to care about > I'd expect to produce more savings. > >>> Is there a work around I haven't thought of? I'm thinking along the >>> lines of disabling all printfs in SPL in the hope that will take the >>> strings away (since many are some sort of debug / progress message). >> >> One option would be to add a "disable all output" option to SPL that >> would get all of the strings dropped. I'm not sure how cleanly this can >> be done, but I know it has been done. > > I have a pile of WIP to submit (a tiny one went today). I'm loath to > do anything major that would be unlikely to be accepted upstream because > of the work to keep it clean when I pull. > > I'm thinking about a config option for SPL that would define away all > printf() and puts() calls. That would cover most of the low-hanging fruit. > It's not a complete solution and would mean no console output in SPL but > I'd think it could be done with a small source impact. Still noodling. > >> Another option would be to do some careful splitting and #ifdef'ery of >> files so that we can just never link in the stuff with strings we don't >> need. > > Yes, lacking a toolchain that has any vowels in it's tray I must agree. > > -Mike > > _______________________________________________ > U-Boot mailing list > [email protected] > http://lists.denx.de/mailman/listinfo/u-boot > _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
