AnsweredAssumed Answered

LS1088A RDB Secure Boot (Development Mode)

Question asked by Carl Jones on Jul 26, 2019
Latest reply on Jul 28, 2019 by Carl Jones



We have been trying to implement Secure Boot in development mode on our LS1088A RDB but we were unsuccessful so far. We were getting this error during boot up “ERROR :: 400 :: Public key hash comparison failed”. Afterwards, the system will proceed to boot in Non Secure State. Here are the steps we followed to implement Secure Boot, reference used is LSDK 18.03.


1. Burn OTPMK in LS1088A RDB

      a. Enable POVDD by shorting J10

      b. Generate OTPMK using gen_otpmk_drbg tool

      c. @uboot prompt, Check initial SNVS state

         md 1e90014


      d. Write OTPMK values to shadow register

         mw.l 1e80234 <OTPMK1>

         mw.l 1e80238 <OTPMK2>

         mw.l 1e8023c <OTPMK3>

         mw.l 1e80240 <OTPMK4>

         mw.l 1e80244 <OTPMK5>

         mw.l 1e80248 <OTPMK6>

         mw.l 1e8024c <OTPMK7>

         mw.l 1e80250 <OTPMK8>

      e. Check SNVS state

         md 1e90014


      f. Check for parity error

         md 1e80024


      g. Command write to INGR register

         mw 1e80020 0x2

      h. Reset and Check SNVS state

         md 1e90014


Note: At this point SNVS state says that OTPMK fuse were blown already.


2. Modify rcw_1600_qspi.rcw to include SB_EN=1 (enabling secure boot in RCW thus avoiding blowing ITS fuse)


3. Generate Secure Boot image using flexbuild

      a. flex-builder clean

      b. flex-builder -c firmware -m ls1088ardb

      c. flex-builder -c linux -a arm64

      d. flex-builder -i mkdistroscr -e

      e. flex-builder -i signimg -m ls1088ardb -b qspi -s -e

      f. flex-builder -i mkfw -m ls1088ardb -b qspi -B uboot -s

      g. flex-builder -i mkbootpartition -a arm64 -s

      h. flex-builder -b build/images/bootpartition_arm64_lts.tgz -r build/rfs/rootfs_ubuntu_xenial_arm64/ -m ls1088ardb -d /dev/sdc


4. Burn firmware_ls1088ardb_uboot_qspiboot_secure.img to qspi address 0 using CodeWarrior ARMv8.


5. Write SRK hash value in mirror registers – this is where the RDB is not going according to the instructions

      a. Put SoC in RSP (@uboot prompt)

         i2c mw 66 66 7f

         i2c mw 66 10 20

         i2c mw 66 10 21

Note: After the last command, RSP immediately takes effect. The RDB restarts and ASLEEP LED lights up. Uboot prompt is no longer responding. CCS also can't access the RDB.


      b. Reset and use CCS to write SRKH in the registers

Note: After reset, the board is no longer in RSP and would proceed to boot normally. We also tried to switch to alternate QSPI bank, but it would also boot normally (not in RSP state). What we did was just reset and halt to uboot prompt so we could write the SRKH. (@ccs prompt)


         config cc cwtap:<ip addr>

         ccs::config_chain {ls1043a dap}

         display ccs::get_config_chain

Note: We tried to config using ls1088a but we get this error “can't read "::ccs::core(ls1088a)": no such element in array” so we used ls1043a since it has the same ARM cpu type (A53). The DAP is found in chain position 48. Then we continued on as told by the instruction.


         ccs::write_mem 2 0x7 0x001000d0 4 0 0x800

Note: This command would return “Unimplemented”


         ccs::write_mem 48 0x1e80254 4 0 <SRKH1>

         ccs::write_mem 48 0x1e80258 4 0 <SRKH2>

         ccs::write_mem 48 0x1e8025c 4 0 <SRKH3>

         ccs::write_mem 48 0x1e80260 4 0 <SRKH4>

         ccs::write_mem 48 0x1e80264 4 0 <SRKH5>

         ccs::write_mem 48 0x1e80268 4 0 <SRKH6>

         ccs::write_mem 48 0x1e8026c 4 0 <SRKH7>

         ccs::write_mem 48 0x1e80270 4 0 <SRKH8>


         ccs::write_mem 2 0x7 0x001000d0 4 0 0x400

Note: This command would also return “Unimplemented”


6. Upon reset, the RDB would boot, will prompt “ERROR :: 400 :: Public key hash comparison failed” then proceeds to boot in Non Secure State.


Any advise would be appreciated on how can we successfully put the RDB in RSP mode so we could write the SRKH properly and then command the system to continue booting up? We also tried to turn SW5[4] to 0 however, CCS can’t access the RDB at this state as well. Or is the process we were doing is completely wrong? Please advise.


Best regards,