From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Thu, 29 Mar 2012 08:41:47 +0200 Subject: [U-Boot] [PATCH v3 0/6] Introduce generic relocation feature In-Reply-To: References: <1324923878-8176-1-git-send-email-sjg@chromium.org> <4F1674AF.9050000@aribaud.net> <4F2C5A67.8040807@aribaud.net> Message-ID: <4F74042B.1000602@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.