Hi Thomas, On Wednesday 16 August 2017 02:37 AM, Thomas Petazzoni wrote: > Hello, > > As you probably noticed with the few patches I sent late July, I am > porting U-Boot to an old SH7786 platform. As part of this effort, I > stumbled across a bug: the global_data structure is not initialized to > zero by the SuperH architecture code before calling board_init_f(). > > The SuperH architecture code defines the global data in > arch/sh/lib/start.S: > > mov.l ._gd_init, r13 /* global data */ > [...] > mov.l ._sh_generic_init, r0 > jsr @r0 > [...] > ._gd_init: .long (_start - GENERATED_GBL_DATA_SIZE) > ._sh_generic_init: .long board_init_f > > So basically, it makes r13 points to the global data (which is expected > on this architecture), and then calls board_init_f(). > > Hence, we enter board_init_f() with global_data uninitialized, which > have caused me quite some troubles, as I was seeing semi-random > behavior: in various places, we test if a pointer in global_data is > NULL or not to decide to do something (or not). This obviously goes > really bad when global_data contains garbage. > > Should we put global_data within the .bss section, so that it gets > zero-initialized automatically? Should we zero-initialize it explicitly?
I am not sure how SuperH allocates the space for global data but typically the following two function takes care of allocating and zeroing global data(at least for arm): In file common/init/board_init.c board_init_f_alloc_reserve() board_init_f_init_reserve() May be, using these two functions might solve your problem. Thanks and regards, Lokesh > > I've currently worked-around the problem by adding a memset() to zero > of the global_data at the beginning of board_init_f(), but I'd prefer > to find an upstreamable fix. > > Thanks! > > Thomas Petazzoni > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
