[U-Boot] [PATCH] Set IVPR to kenrel entry point in second core boot page
Assuming the OSes exception vectors start from the base of kernel address, and the kernel physical starting address can be relocated to an non-zero address. This patch enables the second core to have a valid IVPR for debugger before kernel setting IVPR in CAMP mode. Otherwise, IVPR is 0x0 and it is not a valid value for second core which runs kernel at different physical address other than 0x0.
Signed-off-by: Haiying Wang Haiying.Wang@freescale.com --- cpu/mpc85xx/release.S | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/cpu/mpc85xx/release.S b/cpu/mpc85xx/release.S index 7c3e8a1..d35e4ee 100644 --- a/cpu/mpc85xx/release.S +++ b/cpu/mpc85xx/release.S @@ -157,6 +157,7 @@ __secondary_start_page: mfspr r0,SPRN_PIR stw r0,ENTRY_PIR(r10)
+ mtspr IVPR,r12 /* * Coming here, we know the cpu has one TLB mapping in TLB1[0] * which maps 0xfffff000-0xffffffff one-to-one. We set up a
On Dec 3, 2008, at 9:08 AM, Haiying Wang wrote:
Assuming the OSes exception vectors start from the base of kernel address, and the kernel physical starting address can be relocated to an non-zero address. This patch enables the second core to have a valid IVPR for debugger before kernel setting IVPR in CAMP mode. Otherwise, IVPR is 0x0 and it is not a valid value for second core which runs kernel at different physical address other than 0x0.
Signed-off-by: Haiying Wang Haiying.Wang@freescale.com
cpu/mpc85xx/release.S | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/cpu/mpc85xx/release.S b/cpu/mpc85xx/release.S index 7c3e8a1..d35e4ee 100644 --- a/cpu/mpc85xx/release.S +++ b/cpu/mpc85xx/release.S @@ -157,6 +157,7 @@ __secondary_start_page: mfspr r0,SPRN_PIR stw r0,ENTRY_PIR(r10)
- mtspr IVPR,r12
/*
- Coming here, we know the cpu has one TLB mapping in TLB1[0]
- which maps 0xfffff000-0xffffffff one-to-one. We set up a
-- 1.6.0.2
Acked-by: Kumar Gala galak@kernel.crashing.org
- kq
As stated in the subject, we used multiple 460EXs tied together via PCI and been able to boot the master from flash and all the slaves are now able to boot via PCI and run linux. There were several config changes in u-boot that I made to get this to work (one of which I have a question about). BTW, this is custom hardware, not an amcc board.
Here is the general process that I used
1) boot master via the normal methods, but make sure to leave some RAM "unused" by linux with a parameter like mem=112M (leaving 16Mb) free for the "flash" image.
2) Generate a flash image that contains u-boot, kernel, ramdisk, dt I used perl to just make a pseudo-flash file that is 16Mb, then compress it.
3) I use a userland app to read the image and load it into the contiguous memory reserved in step 1 (this is the only way I know of to get a large, physical contiguous space).
4) Then the app will setup the local PIM registers and remote POM registers, enable bus mastering in the slave CMD register and finally tell the slave to go.
5) The slave fetches addresses (and prefetches, so you have to pay careful attention to the logic analyzer) across PCI. The master claims the transaction and then reads from its DRAM, putting what would normally be the flash back onto the PCI bus.
6) At that point it is done and pretty much just works.
A couple of things I had to do in u-boot, define CONFIG_SYS_NO_FLASH. This resulted in a compile error for IMLS. change the TLB to point to the pci bus and change the CONFIG_SYS_FLASH_BASE_PHYS to point to PCI space (not sure it was required, but I did it anyway).
The biggest question is that since the processor is used in adapter mode, the host is going to configure the POM registers via the PCI bus. This works great until u-boot overwrites those in the file 4xx_pci.c At this point it is running out of ram, but later it needs to go back to get the kernel/ramdisk/dt. So for the moment, I've commented out the writes to POM in the file. But what is the "right" way to do this?
Thanks Ayman
participants (3)
-
Ayman M. El-Khashab -
Haiying Wang -
Kumar Gala