【Resolved】Finally Successful burn fuses on xavier and the experience share, thanks

I record my test process here:
【xavier】Jetpack 4.3, L4T R32.3.1
【host】ubuntu desktop, 18.04.4 LTS
【boards】2 brand new Jetson AGX Xavier (32G), as decribed Board-A & Board-B below

  1. First Test
    【Board ID】Board-A
    【odmfuse.sh】official version
    【Burn cmd】sudo ./odmfuse.sh -c NS -i 0x19 --KEK2 fuse-key/kek2.txt jetson-xavier
    【Fail reason】AS Jerry point,NS mode does NOT accept any key files,
    update 2020.05.20】based on sixth test on Board-B,“NS mode does not accept any key files” seems NOT right,I finally burn kek2 fuse successfull with “-c NS”

  2. Second Test
    【Board ID】Board-A
    【odmfuse.sh】official version
    【Burn cmd】sudo ./odmfuse.sh -c pkc -i 0x19 -k fuse-key/rsa_priv.pem --KEK2 fuse-key/kek2.txt jetson-xavier
    【fail reason】Boot Rom Communication failed,

  3. Third Test
    【Board ID】Board-A
    【odmfuse.sh】official version + custome change
    【odmfuse.sh change】change odmfuse.sh and hardcode the boad info, to make call Boot Rom Communication only once, patch
    【Burn cmd】sudo ./odmfuse.sh -c pkc -i 0x19 -k fuse-key/rsa_priv.pem --KEK2 fuse-key/kek2.txt jetson-xavier
    【Fail reason】Stat for RECFILE failed, zerosbk

  4. Fourth Test
    【Board ID】Board-A
    【odmfuse.sh】NOT used
    【Burn cmd】NOT used *not burn, directly write to /sys/devices/platform/tegra-fuse/ node **
    【Attention】This IS NOT THE WRIGHT WAY by L4T official doc, But it seems works for KEK0/1/2 fuses
    【write & test cmd】
    cd /sys/devices/platform/tegra-fuse/
    echo 0x112233445566778899aabbccddeeff00 > kek2
    cat kek2 — will show what you write above,
    echo 0x1 > odm_profuction_mode
    cat kek2 — still show kek0 value
    reboot
    cd /sys/devices/platform/tegra-fuse/
    cat kek2 ---- after reboot, production_mode effect, read kek2 will show all 0xff
    【Attention】when using TA call se_derive_ekb_ek → se_aes_ecb_operation(…, SE_AES_KEYSLOT_KEK2)128B) to devrive the key,I firstly found it‘s SAME as KEK2 = default 0 value. But IT‘s NOT TRUE.
    【The reason】 is R32.3.1 demo TA keystore-demo, after derive key by calling se_derive_ekb_ek, it call se_derive_aes_keyslots(keystore-demo.c, line 162), which clean ALL SE keyslots(11-15) includng KEK0/1/2, before my TA work. When My test TA works, all SE keyslots become zero again

  5. Fifth Test
    【Board ID】Board-B
    【odmfuse.sh】official version
    【burn cmd】sudo ./odmfuse.sh -c pkc -p -i 0x19 -k fuse-key/rsa_priv.pem --KEK0 fuse-key/kek0.txt --KEK2 fuse-key/kek2.txt jetson-xavier (newly add -p)
    【Failed reason】SAME as above Second Test, Failed at the secondly Boot Rom Communication .

  6. Sixth Test
    【Board ID】Board-B
    【odmfuse.sh】official R32.4.2 version(including below solution2) + solution3 + TWO-Step burn process
    【Burn cmd】
    sudo ./odmfuse.sh -c NS -i 0x19 --KEK2 fuse-key/kek2.txt --noburn jetson-xavier
    …untar fuseblob.tbz2 , check the odmfuse_pkc.xml , run fusecmd.sh…
    sudo ./fusecmd.sh
    【results】successful burn kek2 fuse