On 14/11/10 11:35, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message <4cdf2c8b.3060...@gmail.com> you wrote: >> >>> You cannot and must not touch SDRAM in board_early_init_f(). And even >>> more, you must not at all run relocate_code() there! >>> >> >> See: >> arch/powerpc/lib/board.c >> arch/m68k/lib/board.c >> arch/arm/lib/board.c >> >> They all malloc the final global data structure, memcpy the temporary >> global data to the malloc'd global data, and call relocate_code passing a >> pointer to the new global data all at the very end board_init_f() and >> therefore after SDRAM has been initialised > > Yes, and this is correct. board_init_f != board_early_init_f >
Ah, I see... board_early_init_f() is (in most cases) the very first entry in the init_sequence[] So if global data is defined on the stack in board_init_f() and copied to the heap at the end of board_init_f() we should be OK. Is global data needed prior to board_init_f()? For x86, I allocate global data in asm and set three members. The sticking point for me is the single ulong parameter to board_init_f() which does not present enough flexibility to pass all the information I need. I could create a stub x86_board_init_f which has all the parameters I need, allocate global_data on it's stack, setup global data based on the parameters and call board_init_f() passing the pointer to global data. x86 could then do the same as the other arches and copy global data to a malloc'd version. One step closer to unification. One nit-pick is that, in reality, the stack space used by board_init_f() is never reclaimed because it never returns. What we could do is reset the stack pointer prior to calling board_init_r() I still have no way to globalise gd prior to relocation though :( (still thinking) Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
