Xavier NX can't find mmcblk0p1 on custom carrier board

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
, ,
1

Here is my situation:
I have a Jetson Xavier NX with eMMC, a p3509, and a custom carrier board that we developed.
My co-worker has a Xavier NX with SD card, a p3509, and another custom carrier board, same rev, etc.

I have the Ubuntu 18.04 host, building JP 5.1.1, r35.3.1. I have successfully flashed my eMMC Xavier NX and booted to its Ubuntu desktop, both on p3509 and custom carrier, using flash.sh over USB to my p3668-0001.
I can flash on p3509 and it boots on custom carrier, and vice-versa.
I can also flash on custom carrier and it boots fine.

I have run Linux_for_Tegra/tools/jetson-disk-image-creator.sh to generate an SDcard image for my co-worker to flash onto his SD-card Jetson p3668-0000.

sudo ./jetson-disk-image-creator.sh -o sdImage_xxx.img -b <custom_board_name>+p3668-0000-qspi-sd -d SD

For that to succeed, I had to edit jetson-disk-image-creator to accept the name of our carrier board. I copied the default xavier-nx-devkit name and changed its name to <custom_board_name>, to point to my .conf files. These .conf files work on my computer to flash to my p3668-0001 with flash.sh

Our problem is that my co-worker’s p3668-0000 boots fine when on his p3509 board, but does not boot when moved into his custom carrier board.

We have found some problems that other people had when they corrupted their EEPROM chips on their CVB:

Our carrier boards do not have an EEPROM.
Here is a picture of his boot status. It gets into Linux OS before failing, and sitting forever:

customBoot_screen_error
customBoot_screen_error943Ă—1324 220 KB

Notice at 27.913261 mmcblk1: mmc1:aaaa SC64G 59.5GB
Notice at 28.007279 it says Root device found: mmcblk0p1
Then at 30.353997 ERROR: mmcblk0p1 not found
(sorry for the blurry image).

Is there some file that jetson-disk-image-creator.sh looks for that flash.sh does not use, that is messing up the image?

I don’t see any posts on the forum regarding this issue, where not having an EEPROM is causing an issue, but that is what I suspect is the problem…

3

Hi,

if it’s really about EEPROM, which I’m not sure about, then please try changing the eeprom.cvb_eeprom_read_size variable in both

Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-bct-misc-flash.cfg
Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-bct-misc-l4t.cfg

to 0 and try again.

But is there any reason you have to stick with the SD card image method?
I don’t think it’s meant to be used with custom boards, and if flash.sh works fine, then just go for it.

4

Dave,
Thanks for the tip.
We have multiple systems in the field, and my Ununtu 18.04 computer is the only build machine.
The systems in the field we have sent with SD p3668 boards, so that the users can swap the SD card to update the system.
So I do need to develop an SD image that works, first boot, on our custom board, and we can’t just re-flash each board from the build PC.
I see that tegra194-mb1-bct-misc-flash.cfg and tegra194-mv1-bct-misc-l4t.cfg are included by p3668.conf.common, and it also includes
tegra194-mv1-bct-misc-sd-l4t.cfg
I will change the line
eeprom.cvb_eeprom_read_size = 256;
to
eeprom.cvb_eeprom_read_size = 0;
in all three files:
Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-bct-misc-flash.cfg
Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-bct-misc-l4t.cfg
Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-bct-misc-sd-l4t.cfg

I modified all three files, then ran jetson-disk-image-creator.sh.
When I sent the image to my co-worker, he flashed it to an SD card, booted, and got the same error.

Also, I noticed a bunch of .cfg files with “-jaxi” in the name in the BCT folder.
Are those ever used, and what does “jaxi” mean?

Any more ideas? We do need to get the SD image working.

5

Can you please dump the log as a text file?
Get a TTL-USB cable and enter the serial console like this:

No, and JAXi stands for AGX Xavier Industrial.

6

Ok,
Attached is the log on boot, from UART2, the debug UART.
I have built a debug UEFI in the past, but I think this issue is past UEFI.
If there is anything I can rebuild to aid debugging, let me know.
teraterm2_forumSanitized.log (112.7 KB)

7

Hi, I just noticed that I’m not sure what method you tried when you said but does not boot when moved into his custom carrier board.
Was is with the SD card image? Or a full re-flash with flash.sh?

[    0.028304] DTS File Name: /home/jetsonbuilder/nvidia/nvidia_sdk/JetPack_5.1.1_Linux_myCustomBoard_TARGET/Linux_for_Tegra/sources/kernel/kernel-5.10/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t19x/myCustomBoard/kernel-dts/tegra194-p3668-0000-myCustomBoard_reva1.dts

If it does not even boot with a full re-flash, then maybe there are some issues with your device trees.

8

Dave,
My co-worker does not have access to a build PC, he cannot run flash.sh.
I can run flash.sh, but do not have p3668 with SD card slot.
I generate and send him SD card images.
When he puts the SD image onto SD card, and puts his p3668 into p3509, it boots fine.
When he puts the SD image onto SD in his p3668 in our custom board, we get the error log that I attached.

I only have a p3668 with eMMC, and I have the build PC, so I always use flash.sh, and have no problem booting on either p3509 or our custom board.

This is why I suspect something with EEPROM, because my boards are always flashed with flash.sh, but his are only SD image booted, never touched by flash.sh.

9

I think it’s hard to further debug without validating with flash.sh.
We can’t make it clear whether the issues is about the BSP you use, or maybe some bug in the SD card image script.

10

Everything has always worked fine when I use flash.sh.
Again, to reiterate, the problem is with SD card image booting on our custom board. That is what I have provided the log from.
What do we need to do to make the SD card image see mmcblk0p1 and run it?

13

Hi,

[   27.383211] mmc0: SDHCI controller on 3440000.sdhci [3440000.sdhci] using ADMA 64-bit
[   27.362993] mmc1: SDHCI controller on 3400000.sdhci [3400000.sdhci] using ADMA 64-bit

can you check if your custom board is designed to have an SD card slot, or you just accidentally enable sdhci@3440000 in your device tree?

The logic is that because of the priority in device trees, sdhci@3440000 (probably the one on your custom board) now becomes mmc0, whereas sdhci@3400000 (the one on the module) is mmc1, so your SD card is recognized as mmcblk1p1, but the system still tries to boot from mmcblk0p1 and fails.

14

Dave,
We do have a microSD slot on our board, so sdhci@3440000 will need to be enabled in our device tree. Your explanation of the problem makes sense.
How do I fix this so that it continues to boot from the Jetson’s microSD?

15

Let it boot from mmcblk1p1 as your Jetson micro SD slot is now becoming mmcblk1p1.

16

Wayne,
That sounds like a great idea.
Could you please provide me some information on how to do this, links to documentation, or mention which scripts I should edit?
I know that I need to modify something, I have posted here in the hope that someone knowledgeable would provide information to help solve my problem.
There are many files that mention “mmcblk”, and I am looking through them now. If anyone has information, please let me know.

17

How did you flash your board?

18

method 1. You can try to change the order of the sdhci@xxxx in device tree so that the mmc0 will become the module sdcard.

method 2. Just change the kernel cmdline root=/dev/mmclkxxxx to 1p1 in your extlinux.conf.

19

See original post, I need to generate an SD card image for my co-worker to boot from. What I have generated so far with
sudo ./jetson-disk-image-creator.sh -o sdImage_xxx.img -b <custom_board_name>+p3668-0000-qspi-sd -d SD
has booted on his p3509 but not on our custom board.

20

Wayne,
In “Method 1”, do you mean the order that the sdhci devices are listed in the .dts file?
I modeled my .dts files after the p3509 files found in sources_hardware/nvidia/platform/t19x/jakku (changed to myCustomBoard)/kernel-dts.

The Makefile has

# CBM renamed dtb-$(BUILD_ENABLE) += tegra194-p3668-all-p3509-0000.dtb
dtb-$(BUILD_ENABLE) += tegra194-p3668-myCustomBoard_reva1.dtb
# CBM renamed dtb-$(BUILD_ENABLE) += tegra194-p3668-0000-p3509-0000.dtb
dtb-$(BUILD_ENABLE) += tegra194-p3668-0000-myCustomBoard_reva1.dtb
# CBM renamed dtb-$(BUILD_ENABLE) += tegra194-p3668-0001-p3509-0000.dtb
dtb-$(BUILD_ENABLE) += tegra194-p3668-0001-myCustomBoard_reva1.dtb

I define sdhci@3440000 in tegra194-p3668-myCustomBoard_reva1.dts

It seems that that gets built first, so does that mean that it will become mmcblk0?
Should I move the declaration of sdhci@3440000 to another file, and list it in the Makefile later, so that the custom board SD card becomes mmcblk1?

Regarding Method 2:
Where is the extlinux.conf file that I should edit? I assume it’s in the SD card image somewhere?
There is a file in Linux_for_Tegra/bootloader/extlinux.conf, but that doesn’t look right.
How do I make jetson-disk-image-creator.sh generate the correct extlinux.conf file?

21

It seems that that gets built first, so does that mean that it will become mmcblk0?
Should I move the declaration of sdhci@3440000 to another file, and list it in the Makefile later, so that the custom board SD card becomes mmcblk1?

Check your finalized dtb file by converting it from dtb to dts using a dtc tool.

Regarding Method 2:
Where is the extlinux.conf file that I should edit? I assume it’s in the SD card image somewhere?
There is a file in Linux_for_Tegra/bootloader/extlinux.conf, but that doesn’t look right.
How do I make jetson-disk-image-creator.sh generate the correct extlinux.conf file?

Default path is /boot/extlinux in your rootfs.

22

Ok, I will check the order with dtc.
I still don’t know how to change the order of the devices in the .dtb file?
Can I specify the order, so that the Jetson’s SD card stays at mmcblk0?

Also, I inserted the SD image, mounted the big partition, and I do see /boot/extlinux/extlinux.conf
I have edited root=/dev/mmcblk1p1. I will have my co-worker do the same on his SD card, save the file as root so he can edit it, and try a boot. Thank you for this tip!

23

example,

If the device tree gives you the order like this

sdhci@123
sdhci@456

then sdhci@123 will be mmc0.

If the result gives you

sdhci@456
sdhci@123

then sdhci@456 will be mmc0 this time.