[U-Boot] [PATCH] Set IVPR to kenrel entry point in second core boot page

[U-Boot] [PATCH] Set IVPR to kenrel entry point in second core boot page

[Haiying Wang]

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

[U-Boot] [PATCH] Set IVPR to kenrel entry point in second core boot page

[Kumar Gala]

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

[U-Boot] 460EX PCI Boot SUCCESS and question

[Ayman M. El-Khashab]

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