Wolfgang Denk wrote: > Dear Roman Zeyde, > > In message <6d23e4ef0911030355j47a653a0iea7b6cae2f3cb...@mail.gmail.com> you > wrote: >> I have noticed that the same error as described here >> (http://lists.denx.de/pipermail/u-boot/2009-October/061913.html) >> happens when compiling the latest version of U-boot (v2009-11-rc1) >> using arm-cortex_a8-linux-gnueabi gcc version 4.4.0 >> (crosstool-ng-hg_defa...@1620_187e06178dcb). > > This has been discussed here before. Please see the archives. > >> Could you please apply the patch described above to resolve this issue? > > No, I will not. This has to go through the ARM custodian first. > > Best regards, > > Wolfgang Denk >
I am currently reviewing this patch. After reviewing the history. There is a interest in #if-defing this code. The reason I can see is at least 2 of the start.S call bl coloured_LED_init bl red_LED_on In general, what happens is they call into the weak stubs. Only if the cpu/board provides an overriding function does these calls cause anything meaningful to happen. A good candidate for an if-def variable is the existing CONFIG_STATUS_LED. I am testing this change now. Since it effects all the boards, I am using the regressions of undefined symbol from MAKEALL arm to verify. When this change is done there will only be a handful of failures for the inline weak problem. Then this patch to remove the inlines will take care of them. I have looked at the assembly these produce and it does not look different for non-inline to inline. There was a slight increase in the binary size (zoom2) of 8 bytes using the code sourcry 2009. For my roll-your-own gcc 4.4.2, the size was about 400 bytes larger. Of course it is harder to tell since it wouldn't compile without the fix. After I run through some more testing, I will send out the patch set. Tom _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot