From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Sat, 13 Nov 2010 20:51:37 +1100 Subject: [U-Boot] RFC: Aligning arch initialisation sequences In-Reply-To: <4CDE3251.6080402@emk-elektronik.de> References: <4CD67A22.9040802@gmail.com> <201011091835.38581.vapier@gentoo.org> <4CDE1107.80108@gmail.com> <4CDE30CF.9010509@emk-elektronik.de> <4CDE3251.6080402@emk-elektronik.de> Message-ID: <4CDE5FA9.4000309@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 13/11/10 17:38, Reinhard Meyer wrote: > On 13.11.2010 07:31, Reinhard Meyer wrote: >> Dear Graeme Russ, Dear All, >>> On 10/11/10 10:35, Mike Frysinger wrote: >>>> On Sunday, November 07, 2010 05:06:26 Graeme Russ wrote: >>>>> Should all architectures strive to look as much like one another as >>>>> possible? Should we accept that maybe this particular issue be thrown in >>>>> the too hard basket? >>>> >>>> imo, we should strive to have these things in one common place and not >>>> just >>>> have the different files look the sam >>> >>> I was afraid someone would say that. I've been having a look and a think >>> about the situation for x86, and I cannot come up with a sane way to >>> emulate the way the global data pointer is handled by the other arches. >>> >>> I essence, the gd pointer is a unique global variable available prior to >>> relocation. On all other arches, this is achieved by using a reserved >>> register which I do not have the luxury of on x86 :( >>> >>> Unless I can resolve this, I cannot move x86 in line with the other arches >>> (i.e. init functions can only be done after relocation). >> >> >> I *personally* prefer code without tool-chain specific, out of "C" >> constructs. So I would be fine with passing gd as a parameter to all >> pre-relocation functions. The way they are called with a function array >> that would probably only marginally increase code size. And instead of >> all the funky stack calculations to get the space for gd, it could be >> achieved in a much simpler way: >> >> in asm: set stack to end (or begin) of SRAM (or whatever) >> >> in c: >> board_early_init(void) >> { >> gd_t auto_gd; >> ... >> call all pre-relocation functions with&auto_gd as parameter >> ... >> relocate and fixup (preferably in C) - would probably >> have arch-specific parts in the ELF fix-up >> ... >> memcpy (&static_gd,&auto_gd, sizeof auto_gd); >> ... >> setup final stack and jump to relocated code... >> that should be a *small* assembly helper function >> } >> >> You get the idea ;) >> >> > > Ok, ok, I forgot the hitch that some functions called from > the pre-relocation functions also would need the auto_gd passed on, > *if* they need to use gd. That might become ugly, but x86 has solved > that somehow? > Yes, by declaring gd as a global (static) variable and only referencing it after relocation (well actually, it is passed as a parameter to board_init_f (in lieu of boot_params) where the relocation is performed Regards, Graeme