Hello everybody,
Im trying to setup a Jetson Xavier 8GB production module on an Avermedia EN715 carrier board with Secure Boot (RSA 2K) under Jetpack 5.1.2 with the latest BSP (2023-09-18 EN715-NX-R2.3.0.5.1.2 (BETA)) supplied by Avermedia on their product page EN715 - AVerMedia | AVerMedia.
Following Secure Boot — Jetson Linux Developer Guide documentation I was able to burn the fuses for the parameters I think I require. See the output of sudo ./odmfuseread.sh -i 0x19 -k /mypath_outside_bsp_folder/pkc.pem -S /mypath_outside_bsp_folder/sbk.key jetson-xavier-nx-en715 below
< all values overwritten for privacy reasons; cs and ds have some meaning vs kek256 though. >
PublicKeyHash: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
SecureBootKey: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
Kek0: cccccccccccccccccccccccccccccccc
Kek1: dddddddddddddddddddddddddddddddd
Kek2: eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
Kek256: ccccccccccccccccccccccccccccccccdddddddddddddddddddddddddddddddd
BootSecurityInfo: 00000005
< cut here, all other values are 0 >
- PublicKeyHash corresponds to the value that I generated with tegrakeyhash behind the leading 0x. Ie tegrakeyhash tegra-fuse format (big-endian): would be 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa while the odmfuseread.sh output lacks the 0x - same for all other values in the odmfuseread output.
- SecureBootKey corresponds to what is on the sbk.key file. The contents of sbk.key are in the format 0xbbbbbbbb 0xbbbbbbbb 0xbbbbbbbb 0xbbbbbbbb
Flashing an image to that device via
sudo ./install.sh -u /mypath_outside_bsp_folder/pkc.pem -v /mypath_outside_bsp_folder/sbk.key
gets the jetson into a state from which it does not seem to boot at all. Everything I can see is a rather constant power consumption of ca 0.24A at 12V.
I would be grateful for any pointers in the right direction.
hello spam8pw3w,
please setup serial console to gather the bootloader logs for digging into it.
Hello JerryChang,
thanks for your reply!
I connected an FTDI USB cable as follows (using the pin number from https://s3.us-west-2.amazonaws.com/storage.avermedia.com/web_release_www/EN715/User+Manual/AVerMedia_UM_EN715_NO111B_NX211B_TN111B+20240221.pdf):
- FTDI RX ↔ EN715 TX (pin 6)
- FTDI TX ↔ EN715 RX (pin 8)
- FTDI GND ↔ EN715 GND (pin 4)
Settings in gtkterm: 115200-8-N-1
I left the micro USB cable connected to the EN715.
Results as follows:
- when turning on the power to the EN715:
- 00 is received on the debug console
- The device shows up in dmesg as normal, ie
[ 3374.622795] usb 1-3.2: new high-speed USB device number 20 using xhci_hcd
[ 3374.739751] usb 1-3.2: New USB device found, idVendor=0955, idProduct=7e19
[ 3374.739756] usb 1-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3374.739759] usb 1-3.2: Product: APX
[ 3374.739762] usb 1-3.2: Manufacturer: NVIDIA Corp.
- when turning off the power: FF is received on the debug console
hello spam8pw3w,
according to the user manual, you should setup debug console via pin-6 and pin-8 of J8, 20-Pin GPIO expansion header.
please see-also NVIDIA Jetson Xavier - Serial Console for reference.
Hello JerryChang,
thank you for your help!
As far as I can see you are saying that I correctly wired the FTDI adapter? I can confirm that I am using pin 6 and 8 of J8 (with the connections as specified in my previous post).
In case you were suggesting to remove the GND line (pin 4): Without that the pins are free floating and I receive gibberish over the serial adapter.
Since there was just no sign of life from the device I used above I retried a second setup with the same hardware components (but without any attempts on secure boot configuration). That one seems to do what is expected (ie output the bootloader logs).
Is it possible that the first setup was broken through a wrong sequence of fuse burn commands?
Then I would retry to burn the secure boot fuses again on the second setup. (So far above I have only been talking about getting the serial port to work)
hello spam8pw3w,
FYI,
once you’ve turn-on secureboot. part of bootloader logs will be disabled (i.e. mb1,mb2).
the UART messages it’ll start with logging UEFI and then kernel messages.
please refer to some similar topic for the steps of fuse burning,
such as… Topic 273585, and Topic 158361.
please initial another new forum topic if you need further supports.
let’s close this discussion thread, thanks
Hello JerryChang,
im not following - if the messages are disable when SecureBoot is enabled, then why did you ask me to attach the serial console in the first place? To verify the messages are disabled?
My problem remains unsolved, the first setup I did still does not boot at all. I am happy to open another topic, but the contents in that topic would be an exact copy of the content in here.
I will read up on the two other topics you referenced to see whether they contain helpful information, but I would kindly ask you to mark this topic as “unsolved/open” since it might mislead other users otherwise.
Thanks for your help again!
as mentioned, UART logs it’ll still output with UEFI and then kernel messages.
I understand. What would be your advise for the device that only outputs 00 or FF as a reaction to power on/off?
hello spam8pw3w,
please also check the flash configuration to confirm it’s not disabling kernel log outputs.
for example,
kernel logs will be disabled if there’s quiet property in kernel cmdline.
i.e. CMDLINE_ADD="console=tty0 fbcon=map:0 net.ifnames=0 quiet";
I checked the whole BSP path for matches of CMDLINE_ADD and non of them contains the “quiet” flag. Since I did not touch the content of any files inside the BSP folder, I would assume that no quiet flag is set.
I also tried to flash another image with the serial adapter attached - This also gives me output on the serial port while the image is being installed (therefore I would assume the serial adapter is connected correctly). After the flashing process the device is in the same state as before though.
This time I used
root# ./flash.sh -u /path_to/pkc.pem -v /path_to/sbk_xml.key jetson-xavier-nx-en715 mmcblk0p1
to flash the device.
However, if I understand correctly, you would expect serial output on the serial port (on J8), with the device just set to boot normally from the image that has been flashed previously?
I now used the aforementioned second setup to attempt another burning process as follows:
- burn second setup’s fuses setting Kek0, Kek1, Kek2, PublicKeyHash, and SecureBootKey (“burn run 1”)
- result 1: everything normal, since i have not enabled any security
- burn second setup’s fuses to BootSecurityInfo = 0x01 (“burn run 2”)
- result 2: i can flash an emmc image and the board does boot, messages on serial as expected
- burn the additional bit, so that BootSecurityInfo = 0x05 (“burn run 3”)
- result 3: i can flash an emmc image but the board does not boot anymore. no messages on serial anymore.
in all cases i have verified that the fuses were burned correctly and in all cases I receive serial messages during the flashing process.
I am out of ideas here. You can find the flash.sh and the serial logs attached.
flash.sh.log (131.9 KB)
serial2.log (11.3 KB)
Maybe one more idea: I am trying to achieve an RSA2K setup. During the flashing process I can see many calls to tegrasign_v3.py which cannot be used for my setup (Xavier NX) - at least for the public key hash (according to the note in Secure Boot — Jetson Linux Developer Guide documentation)
I discovered the issue since the documentation only mentioned that the v3 tool should not be used for my setup and I had already generated a hash according to the instructions (which didnt match the hash generated with the old tool).
Might this be something?
hello spam8pw3w,
may I know what’s your host environment setup?
for example, is it a desktop or laptop? are you using native ubuntu OS or virtual machine?
Sure!
Host computer is a normal desktop PC, all USB connections (to Avermedia carrier board + FTDI adapter) are made through an external active USB3 hub.
Host OS is native Ubuntu 18.04, no virtual machine.
Small update: I also receive messages on the serial port when using odmfuseread.sh (to get the fuses values) on the devices that dont boot.
is it due to USB communication has failed? since it’ll have several trails of USB connection/disconnection during the flash process.
No, same result when connecting it directly to the PC’s USB port.
(I have flashed all the other working images through the hub)
Also the same result when trying to flash from a fresh Ubuntu 20.04 install on the host machine, connected natively through USB.
hello spam8pw3w,
is the only difference is BootSecurityInfo?
please access [Jetson Xavier NX Fuse Specification Application Note],
you may looking for fuse name, FUSE_BOOT_SECURITY_INFO for the fuse descriptions.
BTW,
since you’ve burn the fuse correctly, is it possible for flashing the latest JP-5.1.3 public release onto this target for quick confirmation?
Im slightly unsure whether I understand your first question correctly.
- I have checked the Fuse App note before flashing (to verify I dont have any fuse sequence dependencies before burning)
- The way I interpreted FUSE_BOOT_SECURITY_INFO is as follows
- After burn run 2 (see here) odmreadfuse gave me
BootSecurityInfo: 00000001 - my interpretation:
- bit 0 set to 1 => 2048 bit RSA
- After burn run 3:
BootSecurityInfo: 00000005 which would mean
- “secure boot encryption scheme, enables encryption using SBK when set to 1” and additionally
- 2048 bit RSA from above
- Now it might be I confused little/big endian, however having
BootSecurityInfo: 00000001 the board was asking for the right key (to accept new images in), so I assume I started burning the fuses “from the right side” ;)
Flashing JP 5.1.3. is not straightforward, since 5.1.2. is the latest version supported by Avermedia here: https://www.avermedia.com/professional/product-detail/EN715 (DOWNLOAD => BSP for NX).
If there is a way to flash it in an unsupported (by Avermedia) manner im happy to try.
Let me know if this answers your question.