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