On Tue, 2015-03-10 at 12:52 -0500, Bansal Aneesh-B39320 wrote: > > > > -----Original Message----- > > From: Wood Scott-B07421 > > Sent: Tuesday, March 10, 2015 10:34 PM > > To: Bansal Aneesh-B39320 > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431; > > Kushwaha Prabhakar-B32579 > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND > > secure boot target for P3041 > > > > On Tue, 2015-03-10 at 03:50 -0500, Bansal Aneesh-B39320 wrote: > > > > -----Original Message----- > > > > From: Wood Scott-B07421 > > > > Sent: Thursday, March 05, 2015 10:38 PM > > > > To: Bansal Aneesh-B39320 > > > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431 > > > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND > > > > secure boot target for P3041 > > > > > > > > On Thu, 2015-03-05 at 01:26 -0600, Bansal Aneesh-B39320 wrote: > > > > > > -----Original Message----- > > > > > > From: Wood Scott-B07421 > > > > > > Sent: Thursday, March 05, 2015 2:41 AM > > > > > > To: Bansal Aneesh-B39320 > > > > > > Cc: u-boot@lists.denx.de; Sun York-R58495; Gupta Ruchika-R66431 > > > > > > Subject: Re: [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- > > > > > > NAND secure boot target for P3041 > > > > > > > > > > > > Where does the 3.5G limitation come from? Even if the physical > > > > > > address needs to be elsewhere due to bootrom constraints, we > > > > > > should be able to map it wherever we want in the TLB once U-Boot > > > > > > takes > > > > control. > > > > > > > > > > > The 3.5G limitation comes from BootROM in case of secure Boot. > > > > > Initially U-Boot has to run from CPC configured as SRAM with > > > > > address Within 3.5G. Once U-boot has relocated to DDR, we have > > > > > removed the Corresponding TLB entry. > > > > > > > > Again, you could relocate the virtual address of L3 much earlier. > > > > > > > > -Scott > > > > > > > Are you suggesting the following: > > > 1. PBI Commands to configure CPC as SRAM with address 0xBFF0_0000. > > > 2. Compile U-boot with TEXT BASE as 0xFFF40000. > > > 3. Copy the U-boot from NAND via PBI commands to CPC (SRAM) on > > > address 0xBFF4_0000 4. The BootROM will validate the U-boot and transfer > > the control to 0xBFFF_FFFC. > > > 5. When U-boot is executing, then in the last 4K code, when shifting from > > AS=0 to AS=1, > > > we change the address of SRAM from 0xBFF0_0000 to 0xFFF0_0000. > > > (Similar to what is done for NOR Boot) > > > > Something like that, except in step 5 it would only be changing the virtual > > address, not the physical address (unless you can do a similar trick as NOR > > does, to have the L3 cache repeat and cover both addresses at once). > > > > -Scott > > > The problems that I see here are: > 1. Can SRAM address be changed without disabling and re-configuring CPC as > SRAM ?
Again, I'm only talking about changing the virtual address. > 2. Assuming that above is possible, > > We are executing from CPC configured as SRAM with address as 0xBFF0_0000. > (Because of 3.5 G Limitation) > We create a LAW for 0xFFF0_0000 to map to CPC and > change the address of SRAM in CPC controller from BFF0_0000 to 0xFFF0_0000. > (If it is possible... need to check this) > But now the Code which was executing is executing from 0xBFFx_xxxx. So the > CPC controller will reject this since configured address for SRAM is > different. > NOR can have two addresses as IFC controller ignores the upper bit but this > is not possible with CPC. ...and this is why. > To avoid this, even if we create a TLB Entry to map the virtual address > 0xBFFx_xxxx to 0xFFFx_xxxx, then we have a race condition. Which step to do > first? Why is there a race condition? You can have two virtual addresses pointing at the same physical address. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot