How to start the P4080DS/T2080 secure boot

[liyan]

Hello ,we are working on a P4080ds secure boot project . According to the Document of SDK 2.0, we have generate keys and some header , but we don't know how to modify the uboot  souce code for supporting secure boot ,and we don't know how to set the hardware to supporting secure boot ,and we don't know where are the header and the bin file  should be load ? It seems the imx6 have the detailed documents for this , do you have a detailed documents for P4080 & T2080 ? We are desperate to get it ,thank you very much.

[yipingwang]

Hello Li Yan,

After programing mirror register values to fuse array, please write SFP_INGR[INST] to 01 to Read the entire fusebox and load the contents into the corresponding mirror registers back. Then read mirror registers to check whether blowing fuse operation took effect.

Thanks,

Yiping

[ramakrishna_bik]

You need to burn OTPMK and please make sure bits OTPMK_ZERO, OTMPK_SYNDROME and PE are 0 of the status register of sec mon block.

Where can I find information about these registers (0xfe314014 and SCRATCH) for different boards? I am interested in P4080DS and P5040 boards. What is the address and which bits represent OTPMK_ZERO, OTPMK_SYNDROME and PE? I am not able to find them in SDK 2.0 documentation and TRM for the boards.

If I mistakenly wrote wrong OTPMK values to 0xfe0e805c, how can I re-write new values assuming it has mirror? When I do "md 0xfe0e805c", all I see is "0". How do I verify if I wrote the correct values for OTPMK fuses? 

For the status register I see 
=> md 0xfe314014
fe314014: 80f70b00 00000002 00000000 00000000 ................

Does this value indicate an error? If so, what are the errors and how can I fix them?

Greatly appreciate your help in this regard. Thank you!

[liyan]

Hi Yiping,

It seems the value have not be set to fuse array

=> mm 0xfe0e821c

fe0e821c: 00000000 ? 88888888

fe0e8220: ffffffff ? 77777777

fe0e8224: ffffffff ? 66666666

fe0e8228: ffffffff ? 55555555

fe0e822c: ffffffff ? 44444444

fe0e8230: ffffffff ? 33333333

fe0e8234: ffffffff ? 22222222

fe0e8238: ffffffff ? 11111111

fe0e823c: 00000000 ? e814394d

fe0e8240: 00000000 ? eb4b3c5e

fe0e8244: 00000000 ? a74d8688

fe0e8248: 00000000 ? 0c92fa19

fe0e824c: 00000000 ? 58173dfa

fe0e8250: 00000000 ? 67a8f87b

fe0e8254: 00000000 ? 89750515

fe0e8258: 00000000 ? 34487261

fe0e825c: 00000000 ? =>

[liyan]

#LAW for ESBC

  09000cd0 00000000

  09138000 00000000 (Flush command)

Do you mean use “mm” command in uboot to write the register ?

what is the mean of  09138000 00000000 (Flush command) ？ After write 09000cd0 ，write 09138000 to 0 ， am I right？

And I use the default secure boot u-boot and rcw which is in SDK 2.0 ? But it seems the board cannot be boot , ,there is no any output in com1, is this problem  disapper after I set the register correctly ? Or the default secure boot cannot be used in P4080DS board ?

[yipingwang]

Hello Li Yan,

The following commands are PBI commands, you need to generate PBL image(including RCW+PBI), you could use QCVS Tool to generate PBL, SDK document contains detailed description regarding how to use QCVS.

#LAW for ESBC

  09000cd0 00000000

  09138000 00000000 (Flush command)

  09000cd4 c0000000

  09138000 00000000 (Flush command)

  09000cd8 81f0001d

  09138000 00000000(FLUSH command)

# Scratch Register

  090e0200 c0b00000

The condition of secure u-boot executing is that he validation is success.

Please refer the procedure in my first post, these steps are all necessary for secure boot setting up.

Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[yipingwang]

Hello Li Yan,

In the file meta-freescale/conf/machine/p4080ds.conf of SDK 2.0, secure boot option has already been included in UBOOT_CONFIG, when you run "bitbake u-boot", the secure u-boot should been deployed in build_p4080ds/tmp/deploy/images/p4080ds/ folder.

The target board configuration to support secure boot, program the ITS fuse or use RCW with SB_EN=1.

For protyping phase, please don't blow the ITS fuse, and use RCW with SB_EN=1.

For images deployment, please refer to QorIQ SDK 2.0 Document->Boot Loaders->U-Boot->Secure Boot->PBL Based Platforms->Address Map used for demo.

Here are some steps for running a basic secure boot test.

1. Generate a public/private RSA key pair.

2. Sign the image to be validated (U-Boot) using the private key.

3. Create a header containing information regarding the image, keys, signature etc.

4. Deploy the U-Boot and header image on to the target memory.

5. Configure PBL(RCW) with SB_EN=1, BOOT_HO = 1 and location of header programmed in DCFG SCRATCHRW1 register via PBI commands. For PBI commands, please refer to the section QorIQ SDK 2.0 Document->Boot Loaders->U-Boot->Secure Boot->PBL Based Platforms->Pre-Boot Phase.

6. Use CCS to connect to the target, to write OTPMK and SFP_SRKRH to shadow registers.

7. Write the register to get the core out of boot hold off. Boot ROM will read the SCRATCH REGISTER for location of the HEADER and then perform the validation.

Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[liyan]

Hi Yiping,

   Thank you for your feedback ,and It seems the chapter of t”QorIQ SDK 2.0 Document->Boot Loaders->U-Boot->Secure Boot->” is missing ,could you please provide us a whole one ?

[yipingwang]

You need to login then access SDK 2.0  Web page.

Please refer to the following content

NOR SECURE BOOT

P3/P4/P5

#LAW for ESBC

  09000cd0 00000000

  09138000 00000000 (Flush command)

  09000cd4 c0000000

  09138000 00000000 (Flush command)

  09000cd8 81f0001d

  09138000 00000000(FLUSH command)

# Scratch Register

  090e0200 c0b00000

T1/T2/T4/B4

#LAW for ESBC

  09000c10 00000000

  09000c14 c0000000

  09000c18 81f0001b

# LAW for CPC/SRAM

  09000d00 00000000

  09000d04 bff00000

  09000d08 81000013

# Scratch Registers

  090e0200 c0b00000

  090e0208 c0c00000

# CPC SRAM

  09010100 00000000

  09010104 bff00009

# CPC Configuration

  09010f00 08000000

  09010000 80000000

Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[marcboillot]

Hi. from the illustrations above, the LAW for ESBC is at C000000 and the SCRATCH pointers are also in the C0xxxxxx address space. OK, this is the address range to be in the 0-3.5GB space for secure boot requirements (<D0000000), and this is where we would like to have uBoot and ESBC Header, yes? However, the ESBC Header and uBoot are actually physically in NOR at EBF40000 and EFF4000 which is beyond the 0-3.5GB (0-D0000000) address space, yes?

Question: So how can ISBC find uBoot header at EBF4000 and uBoot at EFF4000 by way of the PBI commands above that initialize the LAW ESBC in C0000000? Are additional commands required to copy uBoot & Header from NOR into the lower C0000000 address space, or does the LAW ESBC PBI command somehow map one-to-one with the NOR memory map (starting at E8000000)? In short, how are those PBI commands above referencing any access to the UBoot and Header in NOR that ISBC needs to find?

Are additional steps required? for example, more PBI commands to place uBoot and header in the CPC? But isnt the CPC fixed to BFF00000? The LAW for CPC/SRAM its address bff00000, it is configured in the later CPC SRAM and CONFIG PBI commands (blue font). But how did NOR get remapped from 0xE800xxxx to 0xC800xxxx, if the CPC is already configured (for use with the House Keeping area with ISBC)? Code Warrior can confirm the images in 0xE8000 shown the first slide below. But, how does one change the system map to make NOR appear in the lower C8000000 address space?
     
Thank you

[liyan]

Hi Marc Boillot ,

        We have resloved this issue ,the root cause is the PAMU bypass was set to 0, after we set it to ffff ,this issue disapper .

       But we have another issue , In p4080/T2080 board ,if we generate a key hash key1, and burn it into flash ,then we use other key key2 to sign the u-boot. when we boot the device , the u-boot can boot up , U-boot Cannot be verified ,but it can boot up . is it a bug ?

     we just change set the SB_EN in rcw ,and don't burn the ITS fuse .

[marcboillot]

Hi.

Thank you for the prompt reply, however, the post does not relate or answer the question asked, or at least, help to solve the problem we have. Could you please elaborate the context of your response (e.g., what does PAMU have to do with the PBI commands, or key hash; these seem entirely unrelated to our post)? Can you please review the question we posted with the accompanied Freescale slides and specifically help us understand or explain why NOR XIP flash is in the E000_0000+ range, but any uboot or header images in this space will not be recognized by the ISBC because it exceeds the 0-3.5GB address space (0 t0 D000_000), and how to configure the PBI commands to read uBoot in this lower 0-3.5GB range, or otherwise map the address spaces. I posted specific Freescale images that show how NOR flash is in E000_0000 address then all of a sudden (without explanation) it appears in the next slide as C000_0000 address space. The PBI commands shown are pointing to the 0xC000_xxxx regions yet the images are in 0xE000_xxxx locations. We would be very appreciative if we could receive answers to the specific questions posted.

Again, thank you.

[marcboillot]

NXP answered this in a recent email: The address mapping to 0xe000000 happens in the boot code where the IFC controller and the LAW is configured to map NOR flash to this address.  Before this when Boot Rom comes into the picture, we configure the LAW for the IFC in such a way that same NOR flash maps to 0xC000_0000  which explains why the PBI commands for LAW and SCRATCHRW are in the 0xCxxxxxxx instead of the NOR address space of 0xExxxxxxxx.  Thank you