Hi Albert, On Wed, Mar 28, 2012 at 11:41 PM, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: > 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.
(sorry what follows is pretty hard to follow, but I think it is correct, and shows how I got to where I am with this) That has a certain elegance about it, but it means that I need to access global_data structure members from assembly. I need relocaddr, start_addr_sp and the new gd pointer. These are all calculated in board_init_f() and passed to relocate_code() as parameters at present. I know it is possible to access global data from assembly using the offsets header or similar, but I think we currently avoiding this on ARM at present, to my delight. It also means that board_init_f() would need to return, which puts ARM at odds with every other architecture (it will have to have its own prototype for board_init_f()). Even sandbox uses this no-return prototype. So to recap the reason for my change to the code that calls board_init_r() is that relocate_code() used to be an assembly routine. It did the relocation and then called board_init_r() in the new location with the new stack. Now relocate_code() is entirely written in C, but we still need to call board_init_r() with a new stack when relocation is done. So the grubby stack change stuff is no longer at the end of relocate_code() but in the new pivot_to_board_init_r(), although still in start.S. It's actually quite a minor change. Part of the reason for this change is that there is no need for relocate_code() to be written in assembly (in any architecture I think). The pivot stack thing is all that remains. > > >> 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 That was the idea behind my original proc.S, but it's not exactly an inspiring name. > > >>> 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. > Thanks. > >> Regards, >> Simon > > > Amicalement, > -- > Albert. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
