Hi Simon,
Le 20/02/2012 23:38, Simon Glass a écrit :
You should keep the code that jumps to board_init_r as it is.
I have had a look at this and I don't believe that I can. I need to
call it from C and so it needs to conform to the C calling standard. I
will send a new series showing what I mean.
No need to call it from C. The most correct flow should be that the
start.S code would call board_init_f, relocate_code() and board_init_r,
so that no C code should call assembly language code, and setting the C
environment or modifying it would only happen outside of C code.
Are you saying that you want a start.S in arch/arm/cpu and each
arch/arch/cpu/*/ ? I would prefer there was only one file named
start.S.
OK and I hope that file is not arch/arm/cpu/start.S which would
introduce confusion I think.
I don't want multiple homonym files either. I want a start.S file
responsible for the generic ARM startup and another asm or include file
responsible for the ARM-architecture specifics (i.e. ARM1176, ARM926EJS
etc) if required. The name of that second file I'll think over, but it
won't be start.S
What is the code size increase of using arch-specific mem ops?
About 800 bytes for me:
text data bss dec hex filename
177653 3932 218240 399825 619d1 u-boot
178429 3932 218240 400601 61cd9 u-boot
Thanks.
One problem remains which causes mx31pdk to fail to build. It doesn't
have string.c in its SPL code and the architecture-specific versions of
memset()/memcpy() are too large. I propose to add a local change to
reloc.c that uses inline code for boards that use the old legacy SPL
framework. We can remove it later. This is not included in v2 but I am
interested in comments on this approach. An alternative would be just
to add simple memset()/memcpy() functions just for this board (and one
other affected MX31 board).
I am not too fond of the "later removal" approach. In my experience, this
invariably tends to the "old bloat in the code no one knows the reason
of"
situations.
Me neither. The only board affected is the tx25. We could let the
maintainer fix it up, I suppose. I have no way of testing it.
John: ping?
Since I didn't hear anything I have elected to patch this up a
different way - basically splitting out memcpy() and memset() from
string.c. See what you think of the new series. It introduces no
breakages now, at least.
I'll look this up today.
Regards,
Simon
Amicalement,
--
Albert.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
