From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Tue, 15 Aug 2017 23:07:30 +0200
Subject: [U-Boot] Initializing global_data on SuperH before board_init_f() ?
Message-ID: <20170815230730.680cdcd8@windsurf>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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'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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com