| Message ID | 1408981371-29932-1-git-send-email-valentin.longchamp@keymile.com |
|---|---|
| State | Not Applicable |
| Delegated to: | Tom Rini |
| Headers | show |
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). > > We also have quite a few MPC8321 boards (for instance tuxx1.h or suvd3.h) and > there the problem is not present, while the environment is also in the NOR > flash as on km8360 and their core also a e300 (so their initialization is VERY > similar). I have checked and there it's clearly getenv_f that gets called by getenv before relocation. That's why no problem is seen there. Valentin
Hi, On 26 August 2014 09:17, Valentin Longchamp <valentin.longchamp@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. > > > > > > We also have quite a few MPC8321 boards (for instance tuxx1.h or suvd3.h) and > > there the problem is not present, while the environment is also in the NOR > > flash as on km8360 and their core also a e300 (so their initialization is VERY > > similar). > > I have checked and there it's clearly getenv_f that gets called by getenv before > relocation. That's why no problem is seen there. > > Valentin > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Regards, Simon
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@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 ? Valentin
+York Hi Valentin, On 30 September 2014 01:03, Valentin Longchamp <valentin.longchamp@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@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
+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 > <valentin.longchamp@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@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 >
diff --git a/common/board_f.c b/common/board_f.c index 6203d85..9f034ab 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -133,7 +133,8 @@ void board_add_ram_info(int) static int init_baud_rate(void) { - gd->baudrate = getenv_ulong("baudrate", 10, CONFIG_BAUDRATE); + //gd->baudrate = getenv_ulong("baudrate", 10, CONFIG_BAUDRATE); + gd->baudrate = CONFIG_BAUDRATE; return 0; } @@ -798,7 +799,7 @@ static init_fnc_t init_sequence_f[] = { setup_ram_buf, #endif setup_mon_len, - setup_fdt, + //setup_fdt, trace_early_init, #if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) /* TODO: can this go into arch_cpu_init()? */ @@ -933,7 +934,7 @@ static init_fnc_t init_sequence_f[] = { reserve_logbuffer, #endif #ifdef CONFIG_PRAM - reserve_pram, + //reserve_pram, #endif reserve_round_4k, #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF)) && \ diff --git a/include/configs/km8360.h b/include/configs/km8360.h index f5ac32a..c21c194 100644 --- a/include/configs/km8360.h +++ b/include/configs/km8360.h @@ -51,6 +51,8 @@ #define CONFIG_QE /* Has QE */ #define CONFIG_MPC8360 /* MPC8360 CPU specific */ +#define CONFIG_SYS_GENERIC_BOARD + #define CONFIG_SYS_TEXT_BASE 0xF0000000 /* include common defines/options for all 83xx Keymile boards */
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. We also have quite a few MPC8321 boards (for instance tuxx1.h or suvd3.h) and there the problem is not present, while the environment is also in the NOR flash as on km8360 and their core also a e300 (so their initialization is VERY similar). Has anybody seen a similar problem so far ? Has anybody a clue why this could be a HW related problem (I don't think so) ? or what is the difference in both configs (km8360 and tuxx1 for intance) that causes this behaviour ? Best Regards Valentin Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com> --- common/board_f.c | 7 ++++--- include/configs/km8360.h | 2 ++ 2 files changed, 6 insertions(+), 3 deletions(-)