From mboxrd@z Thu Jan 1 00:00:00 1970 From: Reinhard Meyer Date: Sun, 14 Nov 2010 14:46:30 +0100 Subject: [U-Boot] RFC: Aligning arch initialisation sequences In-Reply-To: <4CDF6070.20503@emk-elektronik.de> References: <4CD67A22.9040802@gmail.com> <201011091835.38581.vapier@gentoo.org> <4CDE1107.80108@gmail.com> <4CDE30CF.9010509@emk-elektronik.de> <20101113081712.C5D85150ADD@gemini.denx.de> <4CDF04A8.4050802@emk-elektronik.de> <20101113215302.6BEA3CEA55B@gemini.denx.de> <4CDF137E.2000902@emk-elektronik.de> <20101113224554.64D72CEA55B@gemini.denx.de> <4CDF15BB.1090107@emk-elektronik.de> <20101114000758.51B6ED302CB@gemini.denx.de> <4CDF2C8B.3060401@gmail.com> <20101114003501.82985CEA55B@gemini.denx.de> <4CDF6070.20503@emk-elektronik.de> Message-ID: <4CDFE836.30702@emk-elektronik.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Wolfgang Denk, To make it crystal clear now, and put the complete context: That simple change would rid us of all alignment concerns: Setting stack to end of initial storage will certainly be aligned, and the auto_gd will be aligned as the toolchain deems necessary. We would not need GENERATED_GBL_DATA_SIZE anymore. The auto_gd space on stack will be valid even into the call to relocate_code. > void board_init_f (ulong bootflag) > { > bd_t *bd; > init_fnc_t **init_fnc_ptr; > gd_t *id; > ulong addr, addr_sp; > + gd_t auto_gd; > > /* Pointer is writable since we allocated a register for it */ > - gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR); > + gd =&auto_gd; > /* compiler optimization barrier needed for GCC>= 3.4 */ > /* Q: why is that needed anyway ??? */ > __asm__ __volatile__("": : :"memory"); > > memset ((void*)gd, 0, sizeof (gd_t)); > .... > debug ("relocation Offset is: %08lx\n", gd->reloc_off); > memcpy (id, (void *)gd, sizeof (gd_t)); > > relocate_code (addr_sp, id, addr); > > /* NOTREACHED - relocate_code() does not return */ > } > > This, and setting CONFIG_SYS_INIT_SP_ADDR to an aligned value in > initial storage (SRAM, pinned down Cache, or other) removes alot > of the headache about making stuff aligned. > This three line change DOES NOT propose any different method of handling gd other then it is currently done. It is ONLY a more elegant way to allocate the pre-relocation storage for gd. Best Regards, Reinhard