[U-Boot] [PATCH] DEBUG 8xxx cpu_numcores
The following debug patch shows that gd->cpu is not being relocated to ddr. Linux may not be able to boot due to "fdt board" crashing if flash has been erased or changed.
On mpc8572ds:
=> fdt board fdt board cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2
Signed-off-by: Ed Swarthout Ed.Swarthout@freescale.com --- cpu/mpc8xxx/cpu.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/cpu/mpc8xxx/cpu.c b/cpu/mpc8xxx/cpu.c index d191263..268c1b4 100644 --- a/cpu/mpc8xxx/cpu.c +++ b/cpu/mpc8xxx/cpu.c @@ -22,7 +22,7 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, * MA 02111-1307 USA */ - +#define DEBUG #include <config.h> #include <common.h> #include <command.h> @@ -98,6 +98,8 @@ struct cpu_type *identify_cpu(u32 ver) int cpu_numcores() { struct cpu_type *cpu; cpu = gd->cpu; + debug("cpu_numcores gd=%x cpu=%x n=%x\n", + (int)gd, (int)cpu, cpu->num_cores); return cpu->num_cores; }
On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote:
The following debug patch shows that gd->cpu is not being relocated to ddr. Linux may not be able to boot due to "fdt board" crashing if flash has been erased or changed.
On mpc8572ds:
=> fdt board fdt board cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2
Signed-off-by: Ed Swarthout Ed.Swarthout@freescale.com
cpu/mpc8xxx/cpu.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
I agree w/Ed that we broke the relocation of gd->cpu with commit:
commit a0e2066f392782730f0398095e583c87812d97f2 Author: Peter Tyser ptyser@xes-inc.com Date: Mon Sep 21 11:20:27 2009 -0500
ppc: Remove board.c relocation fixups
Signed-off-by: Peter Tyser ptyser@xes-inc.com
...
-#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) - gd->cpu += gd->reloc_off; -#endif
Peter, Joakim,
any suggestions on how to properly fix this?
- k
On Tue, 2009-12-15 at 08:49 -0600, Kumar Gala wrote:
On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote:
The following debug patch shows that gd->cpu is not being relocated to ddr. Linux may not be able to boot due to "fdt board" crashing if flash has been erased or changed.
On mpc8572ds:
=> fdt board fdt board cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2
Signed-off-by: Ed Swarthout Ed.Swarthout@freescale.com
cpu/mpc8xxx/cpu.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
I agree w/Ed that we broke the relocation of gd->cpu with commit:
commit a0e2066f392782730f0398095e583c87812d97f2 Author: Peter Tyser ptyser@xes-inc.com Date: Mon Sep 21 11:20:27 2009 -0500
ppc: Remove board.c relocation fixups Signed-off-by: Peter Tyser <ptyser@xes-inc.com>...
-#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
gd->cpu += gd->reloc_off;-#endif
Peter, Joakim,
any suggestions on how to properly fix this?
Hmm, the cpu pointer is set with a flash address since probecpu() is called before relocation. The relocation fixups only update initialized pointers, so the cpu pointer isn't touched during relocation fixups.
Do we really need to call probecpu() so early? Calling it after relocation would resolve the problem. Calling it both before and after relocation would resolve the issue too, but seems kind of hokey.
Otherwise we could re-add a fixup to board.c, eg: diff --git a/lib_ppc/board.c b/lib_ppc/board.c index 765f97a..f245a10 100644 --- a/lib_ppc/board.c +++ b/lib_ppc/board.c @@ -645,6 +645,14 @@ void board_init_r (gd_t *id, ulong dest_addr) /* The Malloc area is immediately below the monitor copy in DRAM */ malloc_start = dest_addr - TOTAL_MALLOC_LEN;
+#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) + /* + * The cpu pointer is set to an address in flash prior to relocation. + * We need to update it to point to the same CPU entry in RAM. + */ + gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE; +#endif + #ifdef CONFIG_SERIAL_MULTI serial_initialize(); #endif
What's less dirty, adding some magical relocation fixup math, or calling a function two times to magically update a variable? Or can we just call probecpu() once after relocation?
Peter
On Dec 15, 2009, at 10:17 AM, Peter Tyser wrote:
On Tue, 2009-12-15 at 08:49 -0600, Kumar Gala wrote:
On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote:
The following debug patch shows that gd->cpu is not being relocated to ddr. Linux may not be able to boot due to "fdt board" crashing if flash has been erased or changed.
On mpc8572ds:
=> fdt board fdt board cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2
Signed-off-by: Ed Swarthout Ed.Swarthout@freescale.com
cpu/mpc8xxx/cpu.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
I agree w/Ed that we broke the relocation of gd->cpu with commit:
commit a0e2066f392782730f0398095e583c87812d97f2 Author: Peter Tyser ptyser@xes-inc.com Date: Mon Sep 21 11:20:27 2009 -0500
ppc: Remove board.c relocation fixups
Signed-off-by: Peter Tyser ptyser@xes-inc.com
...
-#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
gd->cpu += gd->reloc_off;-#endif
Peter, Joakim,
any suggestions on how to properly fix this?
Hmm, the cpu pointer is set with a flash address since probecpu() is called before relocation. The relocation fixups only update initialized pointers, so the cpu pointer isn't touched during relocation fixups.
Do we really need to call probecpu() so early? Calling it after relocation would resolve the problem. Calling it both before and after relocation would resolve the issue too, but seems kind of hokey.
Otherwise we could re-add a fixup to board.c, eg: diff --git a/lib_ppc/board.c b/lib_ppc/board.c index 765f97a..f245a10 100644 --- a/lib_ppc/board.c +++ b/lib_ppc/board.c @@ -645,6 +645,14 @@ void board_init_r (gd_t *id, ulong dest_addr) /* The Malloc area is immediately below the monitor copy in DRAM */ malloc_start = dest_addr - TOTAL_MALLOC_LEN;
+#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
/** The cpu pointer is set to an address in flash prior to relocation.* We need to update it to point to the same CPU entry in RAM.*/gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE;+#endif
#ifdef CONFIG_SERIAL_MULTI serial_initialize(); #endif
What's less dirty, adding some magical relocation fixup math, or calling a function two times to magically update a variable? Or can we just call probecpu() once after relocation?
Where would we call it if it was after relocation?
- k
On Tue, 2009-12-15 at 10:57 -0600, Kumar Gala wrote:
On Dec 15, 2009, at 10:17 AM, Peter Tyser wrote:
On Tue, 2009-12-15 at 08:49 -0600, Kumar Gala wrote:
On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote:
The following debug patch shows that gd->cpu is not being relocated to ddr. Linux may not be able to boot due to "fdt board" crashing if flash has been erased or changed.
On mpc8572ds:
=> fdt board fdt board cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2
Signed-off-by: Ed Swarthout Ed.Swarthout@freescale.com
cpu/mpc8xxx/cpu.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
I agree w/Ed that we broke the relocation of gd->cpu with commit:
commit a0e2066f392782730f0398095e583c87812d97f2 Author: Peter Tyser ptyser@xes-inc.com Date: Mon Sep 21 11:20:27 2009 -0500
ppc: Remove board.c relocation fixups
Signed-off-by: Peter Tyser ptyser@xes-inc.com
...
-#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
gd->cpu += gd->reloc_off;-#endif
Peter, Joakim,
any suggestions on how to properly fix this?
Hmm, the cpu pointer is set with a flash address since probecpu() is called before relocation. The relocation fixups only update initialized pointers, so the cpu pointer isn't touched during relocation fixups.
Do we really need to call probecpu() so early? Calling it after relocation would resolve the problem. Calling it both before and after relocation would resolve the issue too, but seems kind of hokey.
Otherwise we could re-add a fixup to board.c, eg: diff --git a/lib_ppc/board.c b/lib_ppc/board.c index 765f97a..f245a10 100644 --- a/lib_ppc/board.c +++ b/lib_ppc/board.c @@ -645,6 +645,14 @@ void board_init_r (gd_t *id, ulong dest_addr) /* The Malloc area is immediately below the monitor copy in DRAM */ malloc_start = dest_addr - TOTAL_MALLOC_LEN;
+#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
/** The cpu pointer is set to an address in flash prior to relocation.* We need to update it to point to the same CPU entry in RAM.*/gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE;+#endif
#ifdef CONFIG_SERIAL_MULTI serial_initialize(); #endif
What's less dirty, adding some magical relocation fixup math, or calling a function two times to magically update a variable? Or can we just call probecpu() once after relocation?
Where would we call it if it was after relocation?
Either near the top of lib_ppc/board.c:board_init_r() or possibly in cpu/mpc8[5|6]xx/cpu_init.c:cpu_init_r().
I added Ed's debug, and it looks like cpu_numcores() is called many times prior to relocation though. So I'd assume we can't just call it once after relocation.
So the options are: 1. Add "gd->cpu +=" fixup to lib_ppc/board.c where it used to be (We can't put the manual fixup in cpu/mpc8[5|6]xx/cpu_init.c since that code won't have the relocation offset needed for fixing up). 2. Re-call probecpu() in lib_ppc/board.c 3. Re-call probecpu() in cpu/mpc8[5|6]xx/cpu_init.c
I'd slightly lean towards #1, but its not particularly pretty either...
Peter
On Dec 15, 2009, at 11:29 AM, Peter Tyser wrote:
On Tue, 2009-12-15 at 10:57 -0600, Kumar Gala wrote:
On Dec 15, 2009, at 10:17 AM, Peter Tyser wrote:
On Tue, 2009-12-15 at 08:49 -0600, Kumar Gala wrote:
On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote:
The following debug patch shows that gd->cpu is not being relocated to ddr. Linux may not be able to boot due to "fdt board" crashing if flash has been erased or changed.
On mpc8572ds:
=> fdt board fdt board cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2 cpu_numcores gd=3fe6df68 cpu=effed578 n=2
Signed-off-by: Ed Swarthout Ed.Swarthout@freescale.com
cpu/mpc8xxx/cpu.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
I agree w/Ed that we broke the relocation of gd->cpu with commit:
commit a0e2066f392782730f0398095e583c87812d97f2 Author: Peter Tyser ptyser@xes-inc.com Date: Mon Sep 21 11:20:27 2009 -0500
ppc: Remove board.c relocation fixups
Signed-off-by: Peter Tyser ptyser@xes-inc.com
...
-#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
gd->cpu += gd->reloc_off;-#endif
Peter, Joakim,
any suggestions on how to properly fix this?
Hmm, the cpu pointer is set with a flash address since probecpu() is called before relocation. The relocation fixups only update initialized pointers, so the cpu pointer isn't touched during relocation fixups.
Do we really need to call probecpu() so early? Calling it after relocation would resolve the problem. Calling it both before and after relocation would resolve the issue too, but seems kind of hokey.
Otherwise we could re-add a fixup to board.c, eg: diff --git a/lib_ppc/board.c b/lib_ppc/board.c index 765f97a..f245a10 100644 --- a/lib_ppc/board.c +++ b/lib_ppc/board.c @@ -645,6 +645,14 @@ void board_init_r (gd_t *id, ulong dest_addr) /* The Malloc area is immediately below the monitor copy in DRAM */ malloc_start = dest_addr - TOTAL_MALLOC_LEN;
+#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
/** The cpu pointer is set to an address in flash prior to relocation.* We need to update it to point to the same CPU entry in RAM.*/gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE;+#endif
#ifdef CONFIG_SERIAL_MULTI serial_initialize(); #endif
What's less dirty, adding some magical relocation fixup math, or calling a function two times to magically update a variable? Or can we just call probecpu() once after relocation?
Where would we call it if it was after relocation?
Either near the top of lib_ppc/board.c:board_init_r() or possibly in cpu/mpc8[5|6]xx/cpu_init.c:cpu_init_r().
I added Ed's debug, and it looks like cpu_numcores() is called many times prior to relocation though. So I'd assume we can't just call it once after relocation.
So the options are:
- Add "gd->cpu +=" fixup to lib_ppc/board.c where it used to be (We
can't put the manual fixup in cpu/mpc8[5|6]xx/cpu_init.c since that code won't have the relocation offset needed for fixing up). 2. Re-call probecpu() in lib_ppc/board.c 3. Re-call probecpu() in cpu/mpc8[5|6]xx/cpu_init.c
I'd slightly lean towards #1, but its not particularly pretty either...
I'm for #1 as well. Can you send a clean patch w/signoff. I'll test it right away.
- k
Dear Kumar Gala,
In message 9053D472-817A-484D-93C1-657CF15D190B@kernel.crashing.org you wrote:
I agree w/Ed that we broke the relocation of gd->cpu with commit:
I was on the verge of releasing v2009.11 - shall I wait for a fix?
Best regards,
Wolfgang Denk
On Dec 15, 2009, at 11:01 AM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message 9053D472-817A-484D-93C1-657CF15D190B@kernel.crashing.org you wrote:
I agree w/Ed that we broke the relocation of gd->cpu with commit:
I was on the verge of releasing v2009.11 - shall I wait for a fix?
Yes, please do.
- k
participants (4)
-
Ed Swarthout -
Kumar Gala -
Peter Tyser -
Wolfgang Denk