Xavier NX on custom board, stuck at tegrarcm_v2 --isapplet

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
,
1

I am very new to this, just barely got a build of JetPack 4.6 going. That works, and now I am trying to build for JetPack 5.1.1.
I have modified my device tree, because I am flashing a p3668 on a custom carrier board.
nvbuild.sh works, but flash.sh gets stuck at tegrarcm_v2 --isapplet.
I have found that this seems to be related to carrier boards without EEPROMs. My custom board does not have an EEPROM. I tried the comments in the .cfg lines here:

and here:

Does anyone know how to get JetPack 5.1.1 to flash to a Jetson Xavier NX on a carrier board without EEPROM, or might I have some other problem?

Attached is the log when I flash. I let it print to terminal, then copied all my terminal output.
My board is named myCarrierBoard, and the dts files have myCarrierBoard_reva1 in the name. These are all copies of files that had p3509 in the name, modified for my carrier board.
jetsonFlash_tegrarcmv2_isapplet.txt (53.1 KB)

3

You can try to dump flash log but not some posts I shared before. I don’t need those posts…

4

Ok, I have edited my post with an upload of my flash log. Let me know if there is any other info I can get you!

5

Please also get the uart log when your board gets hang.

6

Ok, thanks Wayne. I hooked up, and when I powered Jetson on, nothing happened.
Then, when I ran
sudo ./flash.sh myCarrierBoard_reva1+p3668-0000-qspi-sd mmcblk0p1

I got the attached file on the terminal.
jetsonFlash_uartOutput.txt (3.5 KB)

At the end, the flash script was stuck for 5 min before I powered off.
Interestingly, the UART says SDMMC is not present, but I do have the SD card inserted, and this flash process worked on JetPack 4.6.

Another possibly related question: How do I run menuconfig? I noticed UFS errors in the UART output, and I would like to turn it off.
Also, in future we will need to select modules.
I don’t see any instructions in here:
https://docs.nvidia.com/jetson/archives/r35.3.1/DeveloperGuide/text/HR/JetsonModuleAdaptationAndBringUp/JetsonXavierNxSeries.html#hr-jetsonmoduleadaptationandbringup-jetsonxaviernxseries

Am I missing some guides on configuring, building, and flashing?
Thank you for your help,

7

I have tried commenting out all lines referencing
eeprom.cvb_eeprom_xxx
And I have also tried leaving them in, but changing the read size to 0.
eeprom.cvb_eeprom_read_size = 0;
I have not had any change with either the stock files, commented out, or size set to 0. My carrier board does not have an EEPROM, if that matters.

8

HI,

That log has nothing to do eeprom and nothing to do with UFS. Please just ignore those things.

The thing that matters is what is “myCarrierBoard_reva1+p3668-0000-qspi-sd.conf”. What content is it? How did you make this config file out?

9

Wayne,
I found all the files for p3509 flash configs, copied, then edited them for myCarrierBoard. I tried to leave the parts relating to p3668 alone, and change p3509 parts to be compatible with myCarrierBoard.
Here are the stock files
p3509-0000+p3668-0000-qspi.conf (1.9 KB)
p3509-0000+p3668-0000-qspi-sd.conf (2.4 KB)
p3509-0000+p3668-0001-qspi-emmc.conf (2.4 KB)
p3668.conf.common (6.1 KB)
Here are my modified files.
myCarrierBoard_reva1+p3668-0000-qspi.conf (2.1 KB)
myCarrierBoard_reva1+p3668-0000-qspi-sd.conf (2.6 KB)
myCarrierBoard_reva1+p3668-0001-qspi-emmc.conf (2.6 KB)
myCarrierBoard_reva1.conf.common (6.6 KB)

10

Hi,

Could you just tell me what files got modified in your conf file? I really don’t have time to check your file one by one.

Actually, it should be just few files.

11

Or change it to another way.

Are you able to flash your board with default config file? I think only kernel dtb and pinmux change are sufficient.

12

Wayne,
I have provided the stock baseline files so that you can diff the two files and see just my changes. I think this would be the easiest way to see the changes.
Well I can describe the changes for you if you’d like:
From p3668.conf.common to myCarrierBoard_reva1.conf.common, I changed the names of the pinmux, padvoltage, .dtb and .dtbo files that it points to, from 3509.
In p3509-0000+p3668-0000-qspi.conf, I just changed names p3509 to myCarrierBoard_reva1.
In p3509-0000+p3668-0000-qspi-sd.conf I changed names from p3509 to myCarrierBoard_reva1.
In myCarrierBoard_reva1+p3668-0001-qspi-emmc.conf I changed names from p3509 to myCarrierBoard_reva1.

I am looking for solutions. If you don’t have time to investigate this, could you please point me to some documentation regarding the flash process?
If this problem is not about the flash process, or EEPROM, could you please point me toward something else to try?

I have read and followed the guides in the nvidia bring-up page I linked, and am still here. I need help to know what IS wrong and what to change. I am new to building Linux and to Jetson in particular. I got 4.6 working, but now can’t get 5.1.1 working. Could you please help me figure out what has gone wrong, after I followed all the guides I have found as best as I am able?
If I knew exactly what you are looking for, I would have fixed it. Just keep letting me know what information you need and I can get it for you, and hopefully you can find my mistakes.
Thank you for your patience.

EDIT, to reply to your last comment: Do you think I could use the stock .3509.cfgs to flash? Well, they reference .dtb files for the p3509. I could try that, if you’re sure that it won’t mux pins improperly during the flash process.

13

Hi,

Please just forget about what you saw on the document and follow my guidance first.

Please download the pure BSP again. Only disable the cvb eeprom and do the full flash. Do not change anything else. If flash fails, share me the log.

14

Ok, I will check on the carrier board schematic and see if it’s ok if I flash with the p3509 configs. If so, I can try today. If not, I’ll have to have them ship me a p3509 to flash onto.
I would assume that will work fine. My end goal is to flash onto our custom board. If I can flash onto p3509, that would only make sure that I haven’t somehow broken the SOM. I will try that. If you have any other ideas, feel free to let me know.

What do you mean by “disable the CVB eeprom”?
Thanks,

15

You already answer your own question…

16

I have tried two different things, in multiple different files, but those are all in bootloder config folder: commenting out all 3 lines the CVB eeprom flags section, OR setting eeprom.cvb_eeprom_read_size = 0;
Which of these options, if any, will help the flash process?
Do the bootloader configs, in Linux_for_Tegra/bootloader get used during flashing?
Or should I #undef them in the .cfgs in Linux_for_Tegra (what I think of as flasher config files)?

I would like you to state clearly what I should do, so that I can be sure I am doing it properly.

17

  1. setting eeprom.cvb_eeprom_read_size = 0 is sufficient.

  2. Do the bootloader configs, in Linux_for_Tegra/bootloader get used during flashing?

All the files under this Linux_for_Tegra directory have chance to get flashed on your board. You should not remove anything here.

  1. I feel you are totally not understanding what yourself is doing. That is why I asked you to just follow my instructions to use default board config to flash first. It is always dangerous to directly create a custom board file but not knowing how things work here.
    You created too many variables all at once. It is hard to tell what goes wrong in this situation.
18

Ok, thanks for the answer, I will just set the read_size = 0;

Also, I will get another p3668, and a p3509, and do a fresh build of completely stock 5.1.1 jetPack on the 3509.

I’ll let you know when I have that up and running. I have to order them so it’ll be next week.

Is there any more documentation on how to build a custom board? I have followed all the directions I have found. I know I don’t know how it all works, but my job is to learn how and figure it out, so I’d love to learn more!

19

Hi,

if you only want to make it able to get correctly flashed,
actually only kernel/uefi dtb files and pinmux files require to get changed. Other files should all be same as what we provided.

20

Wayne,
I received two eMMC Jetson Xavier NX modules, on p3509 carrier boards.
I copied the folder that SDKmanager downloaded to JetPack_5.1.1_Linux_p3509_TARGET, and built, and flashed, and that worked great! Flash worked and it booted.

Then I moved back to JetPack_5.1.1_Linux_MYCARRIERBOARD_TARGET folder, I noticed some differences. I needed files for p3668-0001, both .dts, .dtb, and .cfg for flashing.
I got those all set, mirroring the myCustomBoardp3668-0000.dt files.

I have the same problem. When I flash, either -k kernel dtb or not, I get stuck here:

[timestamp] tegrarcm_v2 --boot recovery
[timestamp] Applet version 01.00.000
[timestamp] tegrarcm_v2 --isapplet

I need help finding my issue. To the best of my knowledge, I have modified the .dtb and .cfg files in kernel and bootloader areas, and it’s not working…

21

Wayne,
I hope you have had a good weekend. I have not had any progress since my last post. I am still stuck between working stock config and this tegrarcm_v2 --isapplet hang when flashing custom config.
Again, I can build all files for the custom board, and flashing seems to work up until this point.
I need help to fix this issue, since I have not found any mention of it in the documentation.
If you cannot provide support for this issue, could you forward my case to someone who can, or recommend learning resources?