[U-Boot-Users] [PATCH] MPC85xx: Change traps.c to not reference non-addressable memory
From: Becky Bruce becky.bruce@freescale.com
Currently, END_OF_RAM is used by the trap code to determine if we should attempt to access the stack pointer or not. However, on systems with a lot of RAM, only a subset of the RAM is guaranteed to be mapped in and accessible. Change END_OF_RAM to use get_effective_memsize() instead of using the raw ram size out of the bd.
Signed-off-by: Becky Bruce becky.bruce@freescale.com --- cpu/mpc85xx/traps.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/cpu/mpc85xx/traps.c b/cpu/mpc85xx/traps.c index 2381fb0..fd36658 100644 --- a/cpu/mpc85xx/traps.c +++ b/cpu/mpc85xx/traps.c @@ -50,10 +50,12 @@ int (*debugger_exception_handler)(struct pt_regs *) = 0; extern unsigned long search_exception_table(unsigned long);
/* - * End of memory as shown by board info and determined by DDR setup. + * End of addressable memory. This may be less than the actual + * amount of memory on the system if we're unable to keep all + * the memory mapped in. */ -#define END_OF_MEM (gd->bd->bi_memstart + gd->bd->bi_memsize) - +extern ulong get_effective_memsize(void); +#define END_OF_MEM (gd->bd->bi_memstart + get_effective_memsize())
static __inline__ void set_tsr(unsigned long val) {
On Wed, 14 May 2008 13:10:04 -0500 becky.bruce@freescale.com wrote:
From: Becky Bruce becky.bruce@freescale.com
Currently, END_OF_RAM is used by the trap code to determine if we should attempt to access the stack pointer or not. However, on systems with a lot of RAM, only a subset of the RAM is guaranteed to be mapped in and accessible. Change END_OF_RAM to use get_effective_memsize() instead of using the raw ram size out of the bd.
Signed-off-by: Becky Bruce becky.bruce@freescale.com
what, no love for 4xx, 83xx, and 74xx_7xx?
can also be made a single patch for WD to apply directly.
Kim
On May 14, 2008, at 1:57 PM, Kim Phillips wrote:
On Wed, 14 May 2008 13:10:04 -0500 becky.bruce@freescale.com wrote:
From: Becky Bruce becky.bruce@freescale.com
Currently, END_OF_RAM is used by the trap code to determine if we should attempt to access the stack pointer or not. However, on systems with a lot of RAM, only a subset of the RAM is guaranteed to be mapped in and accessible. Change END_OF_RAM to use get_effective_memsize() instead of using the raw ram size out of the bd.
Signed-off-by: Becky Bruce becky.bruce@freescale.com
what, no love for 4xx, 83xx, and 74xx_7xx?
The other platforms currently set a hard limit that should still be valid - I just changed the ones that were reading memsize directly out of the bd.
can also be made a single patch for WD to apply directly.
Sure, I just split it up in case there was some reason we shouldn't do it for one of them.
-B
On Wed, 14 May 2008 15:31:43 -0500 Becky Bruce becky.bruce@freescale.com wrote:
On May 14, 2008, at 1:57 PM, Kim Phillips wrote:
On Wed, 14 May 2008 13:10:04 -0500 becky.bruce@freescale.com wrote:
From: Becky Bruce becky.bruce@freescale.com
Currently, END_OF_RAM is used by the trap code to determine if we should attempt to access the stack pointer or not. However, on systems with a lot of RAM, only a subset of the RAM is guaranteed to be mapped in and accessible. Change END_OF_RAM to use get_effective_memsize() instead of using the raw ram size out of the bd.
Signed-off-by: Becky Bruce becky.bruce@freescale.com
what, no love for 4xx, 83xx, and 74xx_7xx?
The other platforms currently set a hard limit that should still be valid - I just changed the ones that were reading memsize directly out of the bd.
sure, 5xx, 82xx and 8xx are hardcoded, but 74xx_7xx (albeit only AMIGAONE), all 83xx, and all 4xx use the bd just like in your current patchseries. I'm just trying to maintain some level of consistency.
can also be made a single patch for WD to apply directly.
Sure, I just split it up in case there was some reason we shouldn't do it for one of them.
ah, I thought you wanted individual maintainers to pick them up individually. Either way works, really.
Kim
On May 14, 2008, at 3:54 PM, Kim Phillips wrote:
On Wed, 14 May 2008 15:31:43 -0500 Becky Bruce becky.bruce@freescale.com wrote:
On May 14, 2008, at 1:57 PM, Kim Phillips wrote:
On Wed, 14 May 2008 13:10:04 -0500 becky.bruce@freescale.com wrote:
From: Becky Bruce becky.bruce@freescale.com
Currently, END_OF_RAM is used by the trap code to determine if we should attempt to access the stack pointer or not. However, on systems with a lot of RAM, only a subset of the RAM is guaranteed to be mapped in and accessible. Change END_OF_RAM to use get_effective_memsize() instead of using the raw ram size out of the bd.
Signed-off-by: Becky Bruce becky.bruce@freescale.com
what, no love for 4xx, 83xx, and 74xx_7xx?
The other platforms currently set a hard limit that should still be valid - I just changed the ones that were reading memsize directly out of the bd.
sure, 5xx, 82xx and 8xx are hardcoded, but 74xx_7xx (albeit only AMIGAONE), all 83xx, and all 4xx use the bd just like in your current patchseries. I'm just trying to maintain some level of consistency.
74xx_7xx only does it if CONFIG_AMIGA-something-or-the other is defined, and I have no idea about that particular platform, so I left it alone in that case. Otherwise 74xx_7xx hardcodes it. I actually think perhaps the right answer there is to change the whole thing to use get_effective_memsize in both cases. Does anyone have a contrary opinion on this.
You're right that I missed 83xx, and I will patch that one (sorry, too much grep output, and I missed this one).
I'm also happy to do 4xx if we're pretty sure this it The Right Thing (TM).
Cheers, B
On Wed, May 14, 2008 at 1:10 PM, becky.bruce@freescale.com wrote:
From: Becky Bruce becky.bruce@freescale.com
Currently, END_OF_RAM is used by the trap code to determine if we should attempt to access the stack pointer or not. However, on systems with a lot of RAM, only a subset of the RAM is guaranteed to be mapped in and accessible. Change END_OF_RAM to use get_effective_memsize() instead of using the raw ram size out of the bd.
Signed-off-by: Becky Bruce becky.bruce@freescale.com
Applied, merci
Andy
participants (4)
-
Andy Fleming -
Becky Bruce -
becky.bruceļ¼ freescale.com
-
Kim Phillips