[U-Boot] [U-Boot, 1/2, v4] powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041

[Scott Wood <scottwood@freescale.com>]

On Tue, 2015-03-10 at 13:27 -0500, Bansal Aneesh-B39320 wrote:
> 
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, March 10, 2015 11:29 PM
> > To: Bansal Aneesh-B39320
> > Cc: u-boot at 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 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 at 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 at 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 at 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.
> > 
> If we just change the virtual address to 0xFFF0_0000, how will it work?
> The SRAM address configured in CPC controller is 0xBFF0_0000.
> So, won't the CPC controller reject fetches with address 0xFFFx_xxxx.

It's a virtual address.  The CPC will never see it.

> > Why is there a race condition?  You can have two virtual addresses pointing at
> > the same physical address.
> >
> We can have two virtual addresses pointing to same physical address but we can't have
> two addresses for SRAM in CPC controller.

And you don't need to.

-Scott