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

[aneesh.bansal at freescale.com]

> -----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.

> > 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.
>
We can have two virtual addresses pointing to same physical address but we can't have
two addresses for SRAM in CPC controller. CPC controller will accept fetches with only one address
0xBFFx_xxxx or 0xFFFx_xxxx.
This is not a problem with NOR because IFC controller neglects the upper bits in address and hence
having  two virtual address was not an issue.
 
The code is currently executing from PC 0xBFFx_xxxx and CPC is configured with SRAM address 0xBFFx_xxxx.
If SRAM address in CPC is changed to 0xFFFx_xxxx before creation of TLB entry for virtual address 0xFFFx_xxxx,
Then the CPC controller will reject fetches for address 0xBFFx_xxxx when PC moves to next instruction.

If TLB entry is created to change the virtual address to 0xFFFx_xxxx, then CPC being still configured with address 0xBFFx_xxxx
will reject fetches for address 0xFFFx_xxxx. 
> -Scott
>