Re: [U-Boot] [PATCH v3] mpc83xx: New board support SIMPC8313
In response to my own email:
I did not see this when I built before submitting my patch. It seems to build fine using ELDK version 4.1. I just tried building with 4.2 and am seeing the errors that you described. For some reason, the 4.2 build has about 48 extra bytes to it, and is once again putting me over the 4K bootstrap limit. I'm going to look into getting the size down, but that's a decent number of bytes to try to optimize out.
I've been trying to trim down my nand_spl bootstrap so that it will be below the 4K limit allowed by the processor. However this is proving to be very challenging. I have noticed that there is a little over 100 (decimal) bytes that are being unused at the beginning of the resulting binary (after the HRCW and version string). Would it be possible to move some functions in start.S (mpc83xx) in front of this (see below) part of the code?
. = EXC_OFF_SYS_RESET
.globl _start
This would allow for more board specific nand_spl boot code. Would something like this be allowed or am I barking up the wrong tree?
Ron
On Fri, 21 Nov 2008 16:44:18 -0800 (PST) Ron Madrid ron_madrid@sbcglobal.net wrote:
In response to my own email:
I did not see this when I built before submitting my patch. It seems to build fine using ELDK version 4.1. I just tried building with 4.2 and am seeing the errors that you described. For some reason, the 4.2 build has about 48 extra bytes to it, and is once again putting me over the 4K bootstrap limit. I'm going to look into getting the size down, but that's a decent number of bytes to try to optimize out.
I've been trying to trim down my nand_spl bootstrap so that it will be below the 4K limit allowed by the processor. However this is proving to be very challenging. I have noticed that there is a little over 100 (decimal) bytes that are being unused at the beginning of the resulting binary (after the HRCW and version string). Would it be possible to move some functions in start.S (mpc83xx) in front of this (see below) part of the code?
. = EXC_OFF_SYS_RESET .globl _startThis would allow for more board specific nand_spl boot code. Would something like this be allowed or am I barking up the wrong tree?
I'd rather we find stuff that can be ifdeffed out or moved elsewhere - the moment we move something in there, someone will find the need to enhance and grow whatever moved there.
what was the 4.2 toolchain doing differently than the 4.1 toolchain? maybe that's an area worth looking into.
Kim
Kim Phillips wrote:
On Fri, 21 Nov 2008 16:44:18 -0800 (PST) Ron Madrid ron_madrid@sbcglobal.net wrote:
This would allow for more board specific nand_spl boot code. Would something like this be allowed or am I barking up the wrong tree?
I'd rather we find stuff that can be ifdeffed out or moved elsewhere -
That's great if it's possible, but it's a very tight image and we're currently wasting 1/16 of it.
the moment we move something in there, someone will find the need to enhance and grow whatever moved there.
So put something in there that is unlikely to grow, and if it does grow, swap it with something else. I think you've gotten spoiled by the lack of resource constraints. :-)
what was the 4.2 toolchain doing differently than the 4.1 toolchain? maybe that's an area worth looking into.
Agreed, code size regressions with -Os should warrant a bug report.
-Scott
Dear Kim Phillips,
In message 20081124183714.07cf1670.kim.phillips@freescale.com you wrote:
I did not see this when I built before submitting my patch. It seems to build fine using ELDK version 4.1. I just tried building with 4.2 and am seeing the errors that you described. For some reason, the 4.2 build has about 48 extra bytes to it, and is once again putting me over the 4K bootstrap limit. I'm going to look into getting the size down, but that's a decent number of bytes to try to optimize out.
...
what was the 4.2 toolchain doing differently than the 4.1 toolchain? maybe that's an area worth looking into.
This area has been looked into before, carefully. The size increase results from a bug fix in GCC.
The GCC maintainers explained that this change was a bug-fix to the old compiler, the essence of the bug being that the ldmw/stmw should not be used when the sequence of registers is "broken" by the use of "-ffixed=" options and global register variables, as in the case of U-Boot. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
Best regards,
Wolfgang Denk
participants (4)
-
Kim Phillips -
Ron Madrid -
Scott Wood -
Wolfgang Denk