[U-Boot] [GENERIC_BOARD] env problems before relocation with ppc8360

[Simon Glass]

+York

Hi Valentin,

On 30 September 2014 01:03, Valentin Longchamp
<valentin.longchamp at keymile.com> wrote:
> Hi Simon,
>
> I'm very glad you answered this, I was busy with other stuff these last weeks
> but I had planed to pick this issue again this week.
>
> On 09/28/2014 06:27 AM, Simon Glass wrote:
>> Hi,
>>
>> On 26 August 2014 09:17, Valentin Longchamp
>> <valentin.longchamp at keymile.com> wrote:
>>>
>>> Hello,
>>>
>>> Here is the outcome of my debug session today:
>>>
>>> On 08/25/2014 05:42 PM, Valentin Longchamp wrote:
>>>> Hello,
>>>>
>>>> I am currently porting all the Keymile boards to CONFIG_SYS_GENERIC_BOARD.
>>>> On u-boot 2014.10-rc1 I have all of them working quite well (at least booting
>>>> and showing no obvious problem), except for our boards using a MPC8360
>>>> from Freescale (kmcoge5ne and kmeter1, both using km8360.h as config) that do
>>>> not boot at all.
>>>>
>>>> I have found out that u-boot crashes as soon as a getenv function call happens
>>>> before relocation. When I disable them, u-boot seems to work fine. I am
>>>> currently trying to debug further, but it's not clear yet exactly what causes
>>>> the crash.
>>>
>>> So the problem is that for an unknown reason, the gd->flags are not correct and
>>> getenv actually calls hsearch_h to look for the desired env variable. This fails
>>> before relocation (due to the small stack ?).
>>>
>>> If I replace the board_f getenv_ulong calls in board_f.c with my getenv_f_ulong
>>> function that explicitely calls getenv_f the board boots up nicely.
>>>
>>> Now the question is, why are my gd->flags not correct/corrupted ? Has someone
>>> already seen something similar ? I unfortunateley cannot access gd easily with
>>> the BDI, since it is located in the INIT_RAM which is a data cache, for which I
>>> have no LAW configured (could work on that).
>>
>> I just saw this. There is condition code at the start of
>> board_init_f() in board_f.c that might exclude your board. So your
>> global data might not be zeroed.
>>
>
> That's not exactly the problem here, since defining
> CONFIG_SYS_GENERIC_GLOBAL_DATA did not solve the problem. However it made me
> look at the right place and I have noticed that gd->flags are set in the generic
> board_inif_f() and were not in the previous powerpc specific board_init_f(). If
> I comment out the gd->flags = boot_flags in the board_init_f() function, then
> everything works well.
>
> Since board_init_f() is called from the assembly code (in my case
> mpc83xx/start.S), I guess the ulong boot_flags argument ends up being a register
> (if the arguments are passed in register ... which I am not sure of for
> powerpc). Since prior to the bl board_init_f call in the start.S file, there is
> a call another C function (cpu_init_f()), I guess the register passed as
> argument has an undefined content ... that ends up in gd->flags.
>
> I think that the best way to fix this is to make sure from start.S that
> boot_flags (so the register) has a defined (zeroed ?) content ? But how to make
> sure which register it is and that this will not change, since the compiler
> comes into play here ?

I don't have a lot of knowledge of this platform. On ARM we are moving
to a model where the global data is set up before calling
board_init_f() and then again before board_init_r(). ARM uses r9
always which seems to work nicely.

I wonder if the same solution can be used here? I added York in case
he has ideas.

Regards,
Simon