From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Wed, 1 Oct 2014 08:37:59 -0700 Subject: [U-Boot] [GENERIC_BOARD] env problems before relocation with ppc8360 In-Reply-To: References: <1408981371-29932-1-git-send-email-valentin.longchamp@keymile.com> <53FCA523.4040301@keymile.com> <542A55D1.3080902@keymile.com> Message-ID: <542C1FD7.1010005@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de +Kim. Valentin, I haven't touched 83xx for a while. I remember I had to fix gd->flags when converting some 85xx boards to use generic board. Please see these commits 701e640145474131161de53a407d95d0d2f77082 8bae330f5c6542638da7136f39bc9c13214592cc 15672c6dbd7e5a110773480ccfe47b98ba1dc6f8 York On 10/01/2014 08:27 AM, Simon Glass wrote: > +York > > Hi Valentin, > > On 30 September 2014 01:03, Valentin Longchamp > 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 >>> 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 >