+York Hi Valentin,
On 30 September 2014 01:03, Valentin Longchamp <valentin.longch...@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.longch...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
