Hi Wolfgang and all,
On Tue, Nov 13, 2012 at 08:09:19AM +0100, Wolfgang Denk wrote:
Dear Angelo Dureghello,
please don't top-post / full quote.
Ack.
I am really surprised about your claim that the -O2 compiled code is actually running faster than the -Os compiled one on a low-end system as yours (90 MHz CPU clock, 8 kB cache size).
Which exact tool chain are you using to build the code?
I tested 2 different toolchains,
m68k-elf-gcc (Sourcery CodeBench Lite 2011.09-21) 4.6.1
and another older downloaded from uClinux site, based on
m68k-elf-gcc (GCC) 4.2.4
Nothing change, issue is the same.
Also, i don't understand why "-g" is set by default.
It is set because it is useful to some (those in the need of debugging their code) and does not hurt others.
My question becouse sometime embedded programmers fight for a bite free in the flash. On limited boards like mine (4M Flash) once kernel and some apps are stored, very small size remain for u-boot and some n.v. data storage. But no problem for me, i change flags as needed eventually.
I am not convinced that it makes sense to change settings on a per-cpu base. A 90 MHz CPU should be more than sufficient to receive data at 115kbps. I can only compare against 50 MHz PowerQuicc I systems (which is about the lowest end machines I have at hands now), and there no such problem exists.
Sure, 20 Mhz boards are able to handle 115200 as well. So there is clearly something non working properly in my custom board. First thought is the sdram not well initialized, resulting in very slow execution of the u-boot code. Is there a way in u-boot to test code execution speed ?
Best Regards, Angelo Dureghello