[U-Boot] [PATCH] 85xx: Fix mapping of 0xfffffxxx when CONFIG_MP
Previously, boot page translation was enabled while U-Boot executed. This resulted in the address range 0xfffff000 - 0xffffffff being translated to SDRAM which made the 0xfffffxxx address space unusable for other peripherals.
This change disables boot page translation after the secondary CPU cores have been initialized which allows the 0xfffffxxx address space to be properly accessed.
Signed-off-by: Peter Tyser ptyser@xes-inc.com --- This was tested on the XPedite5370 which has flash mapped in the 0xfffffxxx adddress space. I verified the flash was accessible as expected and Linux properly brought up 2 cores.
I wasn't sure how the MPC8572 handled caching with respect to the boot page translation. I didn't add any cache flushes/invalidates, but they may be necessary if the 0xfffffxxx range is not mapped as uncachable. Anyone at Freescale have any comments on this?
Best, Peter
cpu/mpc85xx/mp.c | 14 ++++++++++++-- cpu/mpc85xx/release.S | 30 +++++++++++++++++++++++++----- 2 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/cpu/mpc85xx/mp.c b/cpu/mpc85xx/mp.c index 76f02a4..0019cec 100644 --- a/cpu/mpc85xx/mp.c +++ b/cpu/mpc85xx/mp.c @@ -129,7 +129,7 @@ ulong get_spin_addr(void)
ulong addr = (ulong)&__spin_table - (ulong)&__secondary_start_page; - addr += 0xfffff000; + addr += determine_mp_bootpg();
return addr; } @@ -137,7 +137,8 @@ ulong get_spin_addr(void) static void pq3_mp_up(unsigned long bootpg) { u32 up, cpu_up_mask, whoami; - u32 *table = (u32 *)get_spin_addr(); + /* The table is at 0xfffffxxx due to boot page translation below */ + u32 *table = (u32 *)(0xfffff000 | get_spin_addr()); volatile u32 bpcr; volatile ccsr_local_ecm_t *ecm = (void *)(CONFIG_SYS_MPC85xx_ECM_ADDR); volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR); @@ -146,6 +147,8 @@ static void pq3_mp_up(unsigned long bootpg) int timeout = 10;
whoami = in_be32(&pic->whoami); + + /* Translate 0xfffffxxx 'bootpg' address range to SDRAM */ out_be32(&ecm->bptr, 0x80000000 | (bootpg >> 12));
/* disable time base at the platform */ @@ -194,6 +197,9 @@ static void pq3_mp_up(unsigned long bootpg)
devdisr &= ~(MPC85xx_DEVDISR_TB0 | MPC85xx_DEVDISR_TB1); out_be32(&gur->devdisr, devdisr); + + /* Disable translation of 0xfffffxxx 'bootpg' */ + out_be32(&ecm->bptr, 0x0); }
void cpu_mp_lmb_reserve(struct lmb *lmb) @@ -206,9 +212,13 @@ void cpu_mp_lmb_reserve(struct lmb *lmb) void setup_mp(void) { extern ulong __secondary_start_page; + extern ulong __bootpg_addr; ulong fixup = (ulong)&__secondary_start_page; u32 bootpg = determine_mp_bootpg();
+ /* Store the bootpg's SDRAM address for use by secondary CPU cores */ + __bootpg_addr = bootpg; + memcpy((void *)bootpg, (void *)fixup, 4096); flush_cache(bootpg, 4096);
diff --git a/cpu/mpc85xx/release.S b/cpu/mpc85xx/release.S index fbefc2c..6799633 100644 --- a/cpu/mpc85xx/release.S +++ b/cpu/mpc85xx/release.S @@ -114,23 +114,38 @@ __secondary_start_page: stw r3,ENTRY_R6_UPPER(r10) stw r3,ENTRY_R6_LOWER(r10)
+ /* load r13 with the address of the 'bootpg' in SDRAM */ + lis r13,toreset(__bootpg_addr)@h + ori r13,r13,toreset(__bootpg_addr)@l + lwz r13,0(r13) + /* setup mapping for AS = 1, and jump there */ lis r11,(MAS0_TLBSEL(1)|MAS0_ESEL(1))@h mtspr SPRN_MAS0,r11 lis r11,(MAS1_VALID|MAS1_IPROT)@h ori r11,r11,(MAS1_TS|MAS1_TSIZE(BOOKE_PAGESZ_4K))@l mtspr SPRN_MAS1,r11 - lis r11,(0xfffff000|MAS2_I)@h - ori r11,r11,(0xfffff000|MAS2_I)@l + oris r11,r13,(MAS2_I)@h + ori r11,r13,(MAS2_I)@l mtspr SPRN_MAS2,r11 - lis r11,(0xfffff000|MAS3_SX|MAS3_SW|MAS3_SR)@h - ori r11,r11,(0xfffff000|MAS3_SX|MAS3_SW|MAS3_SR)@l + oris r11,r13,(MAS3_SX|MAS3_SW|MAS3_SR)@h + ori r11,r13,(MAS3_SX|MAS3_SW|MAS3_SR)@l mtspr SPRN_MAS3,r11 tlbwe
bl 1f 1: mflr r11 - addi r11,r11,28 + /* + * OR in 0xfff to create a mask of the bootpg SDRAM address. We use + * this mask to fixup the cpu spin table and the address that we want + * to jump to, eg change them from 0xfffffxxx to 0x7ffffxxx if the + * bootpg is at 0x7ffff000 in SDRAM. + */ + ori r13,r13,0xfff + and r11, r11, r13 + and r10, r10, r13 + + addi r11,r11,(2f-1b) mfmsr r13 ori r12,r13,MSR_IS|MSR_DS@l
@@ -200,6 +215,11 @@ __secondary_start_page: mtspr SPRN_SRR1,r13 rfi
+ /* Allocate some space for the SDRAM address of the bootpg */ + .globl __bootpg_addr +__bootpg_addr: + .long 0 + .align L1_CACHE_SHIFT .globl __spin_table __spin_table:
On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:
Previously, boot page translation was enabled while U-Boot executed. This resulted in the address range 0xfffff000 - 0xffffffff being translated to SDRAM which made the 0xfffffxxx address space unusable for other peripherals.
This change disables boot page translation after the secondary CPU cores have been initialized which allows the 0xfffffxxx address space to be properly accessed.
Signed-off-by: Peter Tyser ptyser@xes-inc.com
This was tested on the XPedite5370 which has flash mapped in the 0xfffffxxx adddress space. I verified the flash was accessible as expected and Linux properly brought up 2 cores.
I wasn't sure how the MPC8572 handled caching with respect to the boot page translation. I didn't add any cache flushes/invalidates, but they may be necessary if the 0xfffffxxx range is not mapped as uncachable. Anyone at Freescale have any comments on this?
Best, Peter
I'm concerned about this because we specifically avoid the 0xfffff000 - 0xffffffff range since if we reset a core we want it to go through boot page translation. Can you explain what you are putting at that address?
- k
On Tue, 2009-07-07 at 16:59 -0500, Kumar Gala wrote:
On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:
Previously, boot page translation was enabled while U-Boot executed. This resulted in the address range 0xfffff000 - 0xffffffff being translated to SDRAM which made the 0xfffffxxx address space unusable for other peripherals.
This change disables boot page translation after the secondary CPU cores have been initialized which allows the 0xfffffxxx address space to be properly accessed.
Signed-off-by: Peter Tyser ptyser@xes-inc.com
This was tested on the XPedite5370 which has flash mapped in the 0xfffffxxx adddress space. I verified the flash was accessible as expected and Linux properly brought up 2 cores.
I wasn't sure how the MPC8572 handled caching with respect to the boot page translation. I didn't add any cache flushes/invalidates, but they may be necessary if the 0xfffffxxx range is not mapped as uncachable. Anyone at Freescale have any comments on this?
Best, Peter
I'm concerned about this because we specifically avoid the 0xfffff000
- 0xffffffff range since if we reset a core we want it to go through
boot page translation. Can you explain what you are putting at that address?
Most of our boards (MPC8548, MPC8640, MPC8572-based) have two 128MB flashes - 1 from 0xf0000000-0xf7f00000 and the other from 0xf8000000 - 0xffffffff. We've used this convention for a while, before we started using MPC8572s.
U-Boot is always stored at in the flash at 0xfff80000 on the MPC85xx-based boards we support. Thus I couldn't reprogram U-Boot when CONFIG_MP was defined since the top 4K of flash was really accessing SDRAM because of the boot page translation.
With this patch boot page translation is still used to bring up the secondary cores on power on. This change just makes it so that boot page translation is disabled after the other cores are brought up.
Best, Peter
On Jul 7, 2009, at 5:13 PM, Peter Tyser wrote:
On Tue, 2009-07-07 at 16:59 -0500, Kumar Gala wrote:
On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:
Previously, boot page translation was enabled while U-Boot executed. This resulted in the address range 0xfffff000 - 0xffffffff being translated to SDRAM which made the 0xfffffxxx address space unusable for other peripherals.
This change disables boot page translation after the secondary CPU cores have been initialized which allows the 0xfffffxxx address space to be properly accessed.
Signed-off-by: Peter Tyser ptyser@xes-inc.com
This was tested on the XPedite5370 which has flash mapped in the 0xfffffxxx adddress space. I verified the flash was accessible as expected and Linux properly brought up 2 cores.
I wasn't sure how the MPC8572 handled caching with respect to the boot page translation. I didn't add any cache flushes/invalidates, but they may be necessary if the 0xfffffxxx range is not mapped as uncachable. Anyone at Freescale have any comments on this?
Best, Peter
I'm concerned about this because we specifically avoid the 0xfffff000
- 0xffffffff range since if we reset a core we want it to go through
boot page translation. Can you explain what you are putting at that address?
Most of our boards (MPC8548, MPC8640, MPC8572-based) have two 128MB flashes - 1 from 0xf0000000-0xf7f00000 and the other from 0xf8000000 - 0xffffffff. We've used this convention for a while, before we started using MPC8572s.
U-Boot is always stored at in the flash at 0xfff80000 on the MPC85xx-based boards we support. Thus I couldn't reprogram U-Boot when CONFIG_MP was defined since the top 4K of flash was really accessing SDRAM because of the boot page translation.
With this patch boot page translation is still used to bring up the secondary cores on power on. This change just makes it so that boot page translation is disabled after the other cores are brought up.
I understand what the patch does. It just removes the capability of soft-resetting a core back into the boot translation code. I understand your problem I'm just not keen on solving it by completely disabling boot translation.
We had a similar memory map and I moved away from it because of the reset vector issues. Additionally, things like >4G of memory also start creeping up.
- k
On Tue, 2009-07-07 at 17:24 -0500, Kumar Gala wrote:
On Jul 7, 2009, at 5:13 PM, Peter Tyser wrote:
On Tue, 2009-07-07 at 16:59 -0500, Kumar Gala wrote:
On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:
Previously, boot page translation was enabled while U-Boot executed. This resulted in the address range 0xfffff000 - 0xffffffff being translated to SDRAM which made the 0xfffffxxx address space unusable for other peripherals.
This change disables boot page translation after the secondary CPU cores have been initialized which allows the 0xfffffxxx address space to be properly accessed.
Signed-off-by: Peter Tyser ptyser@xes-inc.com
This was tested on the XPedite5370 which has flash mapped in the 0xfffffxxx adddress space. I verified the flash was accessible as expected and Linux properly brought up 2 cores.
I wasn't sure how the MPC8572 handled caching with respect to the boot page translation. I didn't add any cache flushes/invalidates, but they may be necessary if the 0xfffffxxx range is not mapped as uncachable. Anyone at Freescale have any comments on this?
Best, Peter
I'm concerned about this because we specifically avoid the 0xfffff000
- 0xffffffff range since if we reset a core we want it to go through
boot page translation. Can you explain what you are putting at that address?
Most of our boards (MPC8548, MPC8640, MPC8572-based) have two 128MB flashes - 1 from 0xf0000000-0xf7f00000 and the other from 0xf8000000 - 0xffffffff. We've used this convention for a while, before we started using MPC8572s.
U-Boot is always stored at in the flash at 0xfff80000 on the MPC85xx-based boards we support. Thus I couldn't reprogram U-Boot when CONFIG_MP was defined since the top 4K of flash was really accessing SDRAM because of the boot page translation.
With this patch boot page translation is still used to bring up the secondary cores on power on. This change just makes it so that boot page translation is disabled after the other cores are brought up.
I understand what the patch does. It just removes the capability of soft-resetting a core back into the boot translation code. I understand your problem I'm just not keen on solving it by completely disabling boot translation.
We had a similar memory map and I moved away from it because of the reset vector issues. Additionally, things like >4G of memory also start creeping up.
I'm not super familiar with how the MP support in U-Boot is used. Would you be resetting a secondary core for debug purposes? Or is there an example of when you'd reset one in normal operation? I thought normal operation was to use the "cpu release" command, or to let the OS manually take the secondary cores out of their wait loops.
What if I spruced up cpu_reset() to temporarily re-enable boot page translation, then disabled it again? (And maybe re-initialized the cpus MP table so that it could properly ack the primary core similar to in pq3_mp_up().
It seems somewhat dirty to me to constantly keep boot page translation enabled, even when its not needed. Especially since it would require us to change our memory map, environment variable scripts, documentation, etc on all our boards:)
I'd be happy to look into an alternate workaround if you have an idea for a cleaner implementation.
Best, Peter
On Jul 7, 2009, at 5:38 PM, Peter Tyser wrote:
On Tue, 2009-07-07 at 17:24 -0500, Kumar Gala wrote:
On Jul 7, 2009, at 5:13 PM, Peter Tyser wrote:
On Tue, 2009-07-07 at 16:59 -0500, Kumar Gala wrote:
On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:
Previously, boot page translation was enabled while U-Boot executed. This resulted in the address range 0xfffff000 - 0xffffffff being translated to SDRAM which made the 0xfffffxxx address space unusable for other peripherals.
This change disables boot page translation after the secondary CPU cores have been initialized which allows the 0xfffffxxx address space to be properly accessed.
Signed-off-by: Peter Tyser ptyser@xes-inc.com
This was tested on the XPedite5370 which has flash mapped in the 0xfffffxxx adddress space. I verified the flash was accessible as expected and Linux properly brought up 2 cores.
I wasn't sure how the MPC8572 handled caching with respect to the boot page translation. I didn't add any cache flushes/invalidates, but they may be necessary if the 0xfffffxxx range is not mapped as uncachable. Anyone at Freescale have any comments on this?
Best, Peter
I'm concerned about this because we specifically avoid the 0xfffff000
- 0xffffffff range since if we reset a core we want it to go
through boot page translation. Can you explain what you are putting at that address?
Most of our boards (MPC8548, MPC8640, MPC8572-based) have two 128MB flashes - 1 from 0xf0000000-0xf7f00000 and the other from 0xf8000000 - 0xffffffff. We've used this convention for a while, before we started using MPC8572s.
U-Boot is always stored at in the flash at 0xfff80000 on the MPC85xx-based boards we support. Thus I couldn't reprogram U-Boot when CONFIG_MP was defined since the top 4K of flash was really accessing SDRAM because of the boot page translation.
With this patch boot page translation is still used to bring up the secondary cores on power on. This change just makes it so that boot page translation is disabled after the other cores are brought up.
I understand what the patch does. It just removes the capability of soft-resetting a core back into the boot translation code. I understand your problem I'm just not keen on solving it by completely disabling boot translation.
We had a similar memory map and I moved away from it because of the reset vector issues. Additionally, things like >4G of memory also start creeping up.
I'm not super familiar with how the MP support in U-Boot is used. Would you be resetting a secondary core for debug purposes? Or is there an example of when you'd reset one in normal operation? I thought normal operation was to use the "cpu release" command, or to let the OS manually take the secondary cores out of their wait loops.
What if I spruced up cpu_reset() to temporarily re-enable boot page translation, then disabled it again? (And maybe re-initialized the cpus MP table so that it could properly ack the primary core similar to in pq3_mp_up().
It seems somewhat dirty to me to constantly keep boot page translation enabled, even when its not needed. Especially since it would require us to change our memory map, environment variable scripts, documentation, etc on all our boards:)
I'd be happy to look into an alternate workaround if you have an idea for a cleaner implementation.
The idea is after u-boot if you soft-reset a core that it would go back into the spin table code. U-boot is long gone at this point.
- k
On Wed, 2009-07-08 at 10:52 -0500, Kumar Gala wrote:
On Jul 7, 2009, at 5:38 PM, Peter Tyser wrote:
On Tue, 2009-07-07 at 17:24 -0500, Kumar Gala wrote:
On Jul 7, 2009, at 5:13 PM, Peter Tyser wrote:
On Tue, 2009-07-07 at 16:59 -0500, Kumar Gala wrote:
On Jul 7, 2009, at 1:43 PM, Peter Tyser wrote:
Previously, boot page translation was enabled while U-Boot executed. This resulted in the address range 0xfffff000 - 0xffffffff being translated to SDRAM which made the 0xfffffxxx address space unusable for other peripherals.
This change disables boot page translation after the secondary CPU cores have been initialized which allows the 0xfffffxxx address space to be properly accessed.
Signed-off-by: Peter Tyser ptyser@xes-inc.com
This was tested on the XPedite5370 which has flash mapped in the 0xfffffxxx adddress space. I verified the flash was accessible as expected and Linux properly brought up 2 cores.
I wasn't sure how the MPC8572 handled caching with respect to the boot page translation. I didn't add any cache flushes/invalidates, but they may be necessary if the 0xfffffxxx range is not mapped as uncachable. Anyone at Freescale have any comments on this?
Best, Peter
I'm concerned about this because we specifically avoid the 0xfffff000
- 0xffffffff range since if we reset a core we want it to go
through boot page translation. Can you explain what you are putting at that address?
Most of our boards (MPC8548, MPC8640, MPC8572-based) have two 128MB flashes - 1 from 0xf0000000-0xf7f00000 and the other from 0xf8000000 - 0xffffffff. We've used this convention for a while, before we started using MPC8572s.
U-Boot is always stored at in the flash at 0xfff80000 on the MPC85xx-based boards we support. Thus I couldn't reprogram U-Boot when CONFIG_MP was defined since the top 4K of flash was really accessing SDRAM because of the boot page translation.
With this patch boot page translation is still used to bring up the secondary cores on power on. This change just makes it so that boot page translation is disabled after the other cores are brought up.
I understand what the patch does. It just removes the capability of soft-resetting a core back into the boot translation code. I understand your problem I'm just not keen on solving it by completely disabling boot translation.
We had a similar memory map and I moved away from it because of the reset vector issues. Additionally, things like >4G of memory also start creeping up.
I'm not super familiar with how the MP support in U-Boot is used. Would you be resetting a secondary core for debug purposes? Or is there an example of when you'd reset one in normal operation? I thought normal operation was to use the "cpu release" command, or to let the OS manually take the secondary cores out of their wait loops.
What if I spruced up cpu_reset() to temporarily re-enable boot page translation, then disabled it again? (And maybe re-initialized the cpus MP table so that it could properly ack the primary core similar to in pq3_mp_up().
It seems somewhat dirty to me to constantly keep boot page translation enabled, even when its not needed. Especially since it would require us to change our memory map, environment variable scripts, documentation, etc on all our boards:)
I'd be happy to look into an alternate workaround if you have an idea for a cleaner implementation.
The idea is after u-boot if you soft-reset a core that it would go back into the spin table code. U-boot is long gone at this point.
Are there common scenarios where a core would be reset after its already booted an OS? If an OS did need to soft-reset a secondary core, shouldn't the OS be responsible for ensuring boot page translation is enabled, its translating to the proper location, etc? For example, I imagine non-Linux OSes bring up secondary cores in different manners and some wouldn't re-utilize U-Boot's boot page code located in SDRAM at all, thus they wouldn't want the boot page translation always enabled.
It just seems less than ideal to have a chunk of memory space that somewhat magically accesses a completely different, unintuitive address space. Someone else ran into the same issue already: http://www.mail-archive.com/u-boot@lists.denx.de/msg08361.html
I realize there's a tradeoff between keeping the translation enabled vs disabled, I'm just not familiar with how OSes utilize the secondary cores to know what the downsides of disabling translation are...
Best, Peter
Hi Kumar,
I understand what the patch does. It just removes the capability of soft-resetting a core back into the boot translation code. I understand your problem I'm just not keen on solving it by completely disabling boot translation.
We had a similar memory map and I moved away from it because of the reset vector issues. Additionally, things like >4G of memory also start creeping up.
I'm not super familiar with how the MP support in U-Boot is used. Would you be resetting a secondary core for debug purposes? Or is there an example of when you'd reset one in normal operation? I thought normal operation was to use the "cpu release" command, or to let the OS manually take the secondary cores out of their wait loops.
What if I spruced up cpu_reset() to temporarily re-enable boot page translation, then disabled it again? (And maybe re-initialized the cpus MP table so that it could properly ack the primary core similar to in pq3_mp_up().
It seems somewhat dirty to me to constantly keep boot page translation enabled, even when its not needed. Especially since it would require us to change our memory map, environment variable scripts, documentation, etc on all our boards:)
I'd be happy to look into an alternate workaround if you have an idea for a cleaner implementation.
The idea is after u-boot if you soft-reset a core that it would go back into the spin table code. U-boot is long gone at this point.
Are there common scenarios where a core would be reset after its already booted an OS? If an OS did need to soft-reset a secondary core, shouldn't the OS be responsible for ensuring boot page translation is enabled, its translating to the proper location, etc? For example, I imagine non-Linux OSes bring up secondary cores in different manners and some wouldn't re-utilize U-Boot's boot page code located in SDRAM at all, thus they wouldn't want the boot page translation always enabled.
It just seems less than ideal to have a chunk of memory space that somewhat magically accesses a completely different, unintuitive address space. Someone else ran into the same issue already: http://www.mail-archive.com/u-boot@lists.denx.de/msg08361.html
I realize there's a tradeoff between keeping the translation enabled vs disabled, I'm just not familiar with how OSes utilize the secondary cores to know what the downsides of disabling translation are...
Any feedback on my last email above, or is disabling boot page translation just a no-go?
Or is there an more ideal alternative? I really don't want to change up the memory map on all our Freescale boards, documentation, dts files, etc because of an optional 4KB chunk of memory space:) I'm more than willing to implement a different workaround if it means we can keep our current memory map...
Thanks, Peter
On Jul 22, 2009, at 10:47 AM, Peter Tyser wrote:
Hi Kumar,
I understand what the patch does. It just removes the capability of soft-resetting a core back into the boot translation code. I understand your problem I'm just not keen on solving it by completely disabling boot translation.
We had a similar memory map and I moved away from it because of the reset vector issues. Additionally, things like >4G of memory also start creeping up.
I'm not super familiar with how the MP support in U-Boot is used. Would you be resetting a secondary core for debug purposes? Or is there an example of when you'd reset one in normal operation? I thought normal operation was to use the "cpu release" command, or to let the OS manually take the secondary cores out of their wait loops.
What if I spruced up cpu_reset() to temporarily re-enable boot page translation, then disabled it again? (And maybe re-initialized the cpus MP table so that it could properly ack the primary core similar to in pq3_mp_up().
It seems somewhat dirty to me to constantly keep boot page translation enabled, even when its not needed. Especially since it would require us to change our memory map, environment variable scripts, documentation, etc on all our boards:)
I'd be happy to look into an alternate workaround if you have an idea for a cleaner implementation.
The idea is after u-boot if you soft-reset a core that it would go back into the spin table code. U-boot is long gone at this point.
Are there common scenarios where a core would be reset after its already booted an OS? If an OS did need to soft-reset a secondary core, shouldn't the OS be responsible for ensuring boot page translation is enabled, its translating to the proper location, etc? For example, I imagine non-Linux OSes bring up secondary cores in different manners and some wouldn't re-utilize U-Boot's boot page code located in SDRAM at all, thus they wouldn't want the boot page translation always enabled.
It just seems less than ideal to have a chunk of memory space that somewhat magically accesses a completely different, unintuitive address space. Someone else ran into the same issue already: http://www.mail-archive.com/u-boot@lists.denx.de/msg08361.html
I realize there's a tradeoff between keeping the translation enabled vs disabled, I'm just not familiar with how OSes utilize the secondary cores to know what the downsides of disabling translation are...
Any feedback on my last email above, or is disabling boot page translation just a no-go?
It is at this point.
Or is there an more ideal alternative? I really don't want to change up the memory map on all our Freescale boards, documentation, dts files, etc because of an optional 4KB chunk of memory space:) I'm more than willing to implement a different workaround if it means we can keep our current memory map...
I'd be fine if we want to add a CONFIG_ option to do the disable so board ports that need/want it can do it.
- k
Any feedback on my last email above, or is disabling boot page translation just a no-go?
It is at this point.
Or is there an more ideal alternative? I really don't want to change up the memory map on all our Freescale boards, documentation, dts files, etc because of an optional 4KB chunk of memory space:) I'm more than willing to implement a different workaround if it means we can keep our current memory map...
I'd be fine if we want to add a CONFIG_ option to do the disable so board ports that need/want it can do it.
OK, that sounds good. I'll implement and test. Thanks,
Peter
participants (2)
-
Kumar Gala -
Peter Tyser