How to correctly fuse LS1028A processor families?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to correctly fuse LS1028A processor families?

1,571 Views
jclsn
Contributor IV

I am trying to fuse our LS1017A using this guide. I have provided TA_PROG_SFP with 1.8V and am trying to program the OTPMK and SRKH using the fuse_fip.bin using the commands below. Unfortunately I am always getting the error below. Is there something wrong with the fuse_fip.bin?

 

Model: MBLS1028A starterkit
DRAM:  958 MiB (DDR4, 32-bit, CL=11, ECC on)
caam_jr: caam not found
Initialized clockgen
Using SERDES1 Protocol: 60248 (0xeb58)
PCIe2: pcie@3500000 Root Complex: no link
Core:  40 devices, 20 uclasses, devicetree: separate
WDT:   Started watchdog@c000000 with servicing (60s timeout)
WDT:   Started watchdog@c010000 with servicing (60s timeout)
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from SPIFlash... SF: Detected mx66u51235f with page size 256 Bytes, erase size 64 KiB, total 64 MiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
SEC0:  RNG instantiated
Net:   
Warning: enetc-0 (eth0) using random MAC address - 82:e5:78:5e:a0:4d
eth0: enetc-0 [PRIME]
Warning: enetc-1 (eth1) using random MAC address - 4a:ed:d9:50:d0:c2
, eth1: enetc-1
Warning: enetc-2 (eth2) using random MAC address - 92:e6:66:05:46:85
, eth2: enetc-2, eth3: swp0, eth4: swp1, eth5: swp2, eth6: swp3
Hit any key to stop autoboot:  0 
=> load mmc 0 $loadaddr fuse_fip.bin
224 bytes read in 5 ms (43 KiB/s)
=> protect off 64880000 +$filesize
=> erase 64880000 +$filesize
=> cp.b $loadaddr 64880000 $filesize
"Synchronous Abort" handler, esr 0x96000045
elr: 0000000082077888 lr : 000000008201371c (reloc)
elr: 00000000b7b6d888 lr : 00000000b7b0971c
x0 : 0000000064880000 x1 : 0000000092000000
x2 : 00000000000000e0 x3 : 0000000000000000
x4 : 12345678aa640001 x5 : 0000000000000000
x6 : 00000000b7b7d09e x7 : 0000000000000044
x8 : 0000000000000010 x9 : 0000000000000008
x10: 0000000000000000 x11: 00000000b78fa708
x12: 0000000000000000 x13: 0000000000000200
x14: 00000000b78ea340 x15: 0000000000000020
x16: 00000000b7b09688 x17: 0000000000000000
x18: 00000000b78f1da0 x19: 0000000000000001
x20: 00000000b78f7350 x21: 0000000064880000
x22: 0000000092000000 x23: 0000000000000000
x24: 0000000000000000 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 00000000b78f68a0 x29: 00000000b78e9eb0

Code: eb03005f 540001c1 d65f03c0 f8636824 (f8236804) 
Resetting CPU ...

### ERROR ### Please RESET the board ###

 

6 Replies

1,351 Views
kenli
NXP Employee
NXP Employee

The purpose is to enable secure boot?

If yes, I strongly suggest you go through the process with the mirror register first according to the LSDK2108 userguide, the fuse is OTP.
OTPMK needs to comply with the Hamming check and also must to be programmed into the fuse during the verification phase (or development phase)
For other references, please refer to LSDK. Pay attention to the endian difference between using codewarrior and uboot.

Best regards
0 Kudos
Reply

1,471 Views
jclsn
Contributor IV

So, I had a bit of progress today. I did not supply the input_fuse_file correctly to the gen_fusecr script. Now that I did, the fuses are blown correctly. atf built with -DDEBUG flag shows

INFO: Fuse: Program SRKH

I did realize that the SRKH was written again and again though. Is this normal behavior when atf is build with the -DDEBUG flag? I would imagine that the fuse addresses are exchanged with some normal address in memory for debugging purposes. Since the I

INFO: Error in Fuse Provisioning: c

message is only shown when atf is built with -DDEBUG, this doesn't make sense.

Anyway, I could verify the blown fuses with in U-Boot now:

=> md 0x01e80254 10

01e80254: xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx ..some chars..
01e80264: xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx ..some chars..

I have tried booting an unsigned image to test the correct behavior, but no error is shown, although I have set SB_EN in the RCW. A colleague from TQ Systems said that the LS1017A does not have a CAMM and does thus not support secure boot at all. I wonder if this is correct.

0 Kudos
Reply

1,496 Views
Hector_Villarruel
NXP TechSupport
NXP TechSupport

Hello @jclsn 

Hope this email finds you well,

Does the fuse of the device is already open?

Could you please provide the logs from OTPMK & SRKH?

We highly recommend you to follow the steps located on section 6.1.1.5.2 Prepare board for Secure boot from our Layerscape Software Development Kit User Guide, Rev. 21.08

You can also find this documentation attached to this case.

Thank you so much.

Best Regards,

Hector Villarruel

0 Kudos
Reply

1,481 Views
jclsn
Contributor IV

Well, I am trying to use a fuse file and not do it manually, since we want to fuse multiple boards with the same SRKH in the long run. I already read the whole security section of your guide like 10 times. Still haven't got it completely, since it is very bloated. The HAB guide for i.MX SoCs was definitely easier to wrap your head around! We are alsing using a mainline U-Boot version and the SNVS_HPSR_REG variables etc are not in the environment yet.

After reading in the qoriq-atf code, we discovered that the debug flag needs to be enabled to see what atf is actually doing. Why isn't that mentioned in any guide? It makes it much easier to verify successful fusing. I also added some more prints. Seems like a fusing of the SRKH is not attempted. So my gues is the FLAG_SRKH_SHIFT is not set. Why could that be?

NOTICE:  1 GB DDR4, 32-bit, CL=11, ECC on                     
INFO:    Time used by DDR driver 209 ms                       
NOTICE:  BL2: v1.5(debug):zeus.TQMLS1028A.BSP.SW.0103-dirty   
NOTICE:  BL2: Built : 13:42:35, Jun  6 2023                   
INFO:    Configuring TrustZone Controller                     
INFO:    Value of region base = bfe00000                      
INFO:    Value of region base = ffe00000                      
INFO:    Value of region base = bbe00000                      
INFO:    Loading image id=41 at address 0x81000000            
INFO:    Image id=41 loaded: 0x81000000 - 0x81000080          
NOTICE:  Loaded FUSE PRIV image successfully                  
INFO:    Checking barker code                                 
INFO:    Checking if GPIO pin to be set for POVDD             
INFO:    Checking for write protect fuse                      
INFO:    Checking for SRKH to be blown or not                 
INFO:    Checking for OEMUID to be blown or not               
INFO:    Checking for OTPMK values to be blown or not         
INFO:    Fuse: Program OTPMK                                  
INFO:    Error in Fuse Provisioning: c                        
INFO:    BL2: Doing platform setup                            
INFO:    BL2: Loading image id 3                              
INFO:    Loading image id=3 at address 0xbbe00000             
INFO:    Image id=3 loaded: 0xbbe00000 - 0xbbe0a169           
INFO:    BL2: Loading image id 5                              
INFO:    Loading image id=5 at address 0x82000000             
INFO:    Image id=5 loaded: 0x82000000 - 0x820bfa08           
NOTICE:  BL2: Booting BL31                                    
INFO:    Entry point address = 0xbbe00000                     
NOTICE:  BL31: v1.5(release):zeus.TQMLS1028A.BSP.SW.0103-dirty
NOTICE:  BL31: Built : 11:59:46, Jun  6 2023                  
NOTICE:  Welcome to LS1028 BL31 Phase                         

 

I also wonder if we are actually supposed to flash an OTPMK or if TQ Systems does this during manufacturing of the compute module?

0 Kudos
Reply

1,385 Views
Hector_Villarruel
NXP TechSupport
NXP TechSupport

Hello @jclsn 

This post is to inform you that I keep working into this case.

Did you have any new update?

I'll keep you updated.

BR,

Hector

0 Kudos
Reply

1,536 Views
jclsn
Contributor IV

I have used the input_fuse_file in the ls2088_1088 folder and chosen PLATFORM=LS1088, because they were only LS2088/LS1088 options. Maybe some offset is wrong here?

I can also not read from the location using md 60880000 $filesize. It seems the region is write protected, although the POVDD is high.

0 Kudos
Reply