mpc83xx: New board support SIMPC8313
PATCH v3 1/1 mpc83xx: New board support SIMPC8313
In response to my own email:
Quoted 6 lines
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
PATCH v3 1/1 mpc83xx: New board support SIMPC8313
Quoted 18 lines · On Fri, 21 Nov 2008 16:44:18 -0800 (PST) Ron Madrid <[email protected]>…
In response to my own email:
Quoted 6 lines
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_splbootstrap 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 instart.S
(mpc83xx) in front of this (see below) part of the code?
Quoted 7 lines
. =
EXC_OFF_SYS_RESET.globl
_startThis would allow for more board specific
nand_splboot 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
PATCH v3 1/1 mpc83xx: New board support SIMPC8313
Quoted 7 lines · Kim Phillips
Quoted 3 lines · On Fri, 21 Nov 2008 16:44:18 -0800 (PST) Ron Madrid <[email protected]>…
This would allow for more board specific
nand_splboot 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.
Quoted 2 lines
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. :-)
Quoted 2 lines
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
PATCH v3 1/1 mpc83xx: New board support SIMPC8313
In reply to Kim PhillipsDear Kim Phillips,
Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 7 lines
Quoted 7 lines
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.
...
Quoted 2 lines
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
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Unsichtbar macht sich die Dummheit, indem sie immer gr??ere Ausma?e annimmt. -- Bertold Brecht: Der Tui-Roman