Cboot failure after editing cbo.dts and digest problem

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
1

Hi,
I edited the cbo.dts file with the following boot-order line:
boot-order = “nvme”, “emmc”;

In the bootloader dir I compiled it with:
dtc -I dts -O dtb -o cbo.dtb cbo.dts
and then flashed it with:
sudo ./flash.sh -k CPUBL-CFG my_conf mmcblk0p1

The problem now is that the Cboot ignores the file and use some defualts values.
log:
boot.log (14.9 KB)

  1. Why it happens?
  2. Sometimes I get the digest error (not in this particular case)
    I found here:
    Kernel-dtb loading error on R32.3.1 - #6 by 295839633

Can you explain me a little bit what is exactly happen and why?
How I know the exact commands suitable for my setup? (I will use CPUBL-CFG instead of kernel-dtb of course but what regarding the other arguments such as chip)

thanks!

3

Are you sure your cbo.dts has a correct format?

Looks like the cboot tries to parse it and fails. If you want to dig into this, you can also check the cboot source code for this part directly.

4

Yes.
Ok, now I have a deadlock:

  1. I noticed that the nvme0n1p1 extlinux.conf file was still with the root=mmcblk0p1. For some reason the changes were not saved. Maybe its because I mounted the nvme0n1p1 file system , edited the extlinux.conf saved it and restarted without unmounting first.

  2. Now it tries to use the nvme0n1p1 extlinux.conf file but I have the sig error:
    [09:44:10:571] [0006.207] I> Loading extlinux.conf …␍␊
    [09:44:10:571] [0006.210] I> Loading extlinux.conf binary from rootfs …␍␊
    [09:44:10:571] [0006.216] I> rootfs path: /nvme/boot/extlinux/extlinux.conf␍␊
    [09:44:10:571] [0006.222] I> Loading extlinux.conf sig file from rootfs …␍␊
    [09:44:10:571] [0006.226] I> rootfs path: /nvme/boot/extlinux/extlinux.conf.sig␍␊
    [09:44:10:571] [0006.233] I> Validate extlinux.conf …␍␊
    [09:44:10:571] [0006.236] I> T19x: Authenticate extlinux.conf (bin_type: 54), max size 0x2000␍␊
    [09:44:10:611] [0006.243] E> digest on binary did not match!!␍␊
    [09:44:10:611] [0006.247] C> OEM authentication of extlinux.conf payload failed!␍␊
    [09:44:10:611] [0006.253] W> Failed to validate extlinux.conf binary from rootfs (err=1077936152, fail=0)␍␊

I read that I need to take the nvme ssd extlinux.conf , sign it with the l4t_sign_image.sh and then put back the extlinux.conf and extlinux.conf.sig files at the nvme /boot/extlinux path.
I can’t reach the nvme files because it is internal nvme.

  1. I try to boot from the emmc but the bootloader ignores my cbo.dtb for some reason as I wrote before.
    So I basically locked outside.
    this is the dts:

    1
    1953×522 66.2 KB

  2. Where I can find the cboot source in order to try and debug?

Thanks

5

There is a bug in rel32.7.2 and you need a patch.

https://elinux.org/Jetson/L4T/r32.7.x_patches

Please search l4t archive website and you will find the code.

6

I apologize, I’m new in these area. When you say there is a patch - you mean there is some kind of tarball I need to open and recompile the cbo.dts again? or you referring to your reply with the new lines you added and you want me to do that manually by myself with the cboot sources and rebuild it?

thanks

7

You need to build the cboot with the patch added. I mean the first link in the elinux org page I shared.

8

It says len is missing:

1
11712×129 33.8 KB

9

I can add it manually ?

10

maybe there is a mismatch between the cboot version I use and the specified patch?
I’m using the L4T 32.6.1 and this patch (according to the title) is for 32.7.2.

I think there is a mismatch because the original ext4.c file doesn’t contain the lines that should be removed according to the patch. In addition, it doesn’t recognizes the variable len.

11

Hi,

Is the cboot you are using on your carrier board a 32.6.1 one or 32.7.2 one? If your cboot is 32.6.1 one, then you don’t need to add the patch…

12

I’m using L4T 32.6.1.
Still face the same error I described in my previous post. I need to solve the digest problem and sign the files but I can’t reach them since they are located on internal SSD. I try to modify cbo to boot from emmc but it ignores that and still tries to boot from nvme and fails.

13

How about you dumped your full log here instead of just that partial log?

Also, are we testing this on devkit or your custom board?

And does your board enable secure boot or not?

14

Thanks you.

  1. boot log:
    cboot.log (46.3 KB)

  2. custom board. (I have another one on which everything is working and they are identical. that;s why it a little bit strange)

  3. yes, but I used flash.sh and not initrd flashing

15

Hi,

Maybe you can try to use the default cbo.dts file first… I think the format is wrong or something similar to that.

The real error is this one:

[11:14:24:990] [0002.268] I> Load in CBoot Boot Options partition and parse it␍␊
[11:14:24:990] [0002.268] E> Failed to get number of boot devices from CBO file.␍␊
[11:14:24:990] [0002.269] W> parse_ip_info: tftp-server-ip info not found in CBO options file␍␊
[11:14:24:990] [0002.276] W> parse_ip_info: static-ip info not found in CBO options file␍␊
[11:14:25:018] [0002.283] W> Failed to parse GUID␍␊
16

I did the following steps:

  1. Re-flashed the emmc with all the partitions (and a new CBO file).
    At that point the module booted up successfully using rootfs from emmc.

  2. Modified both extlinux.conf files with:
    APPEND ${cbootargs} quiet root=/dev/nvme0n1p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

( I have two rootfs, one on the emmc and one on the nvme. I wish to boot the rootfs from the nvme)

  1. Signed both extlinux.conf files with ./l4t_sign_image.sh to solve the digset issue after modifying the extlinux.conf files manually.

  2. Edited the cbo.dts to boot from nvme first.

I get strange boot order and the target is not booting up.

boot.log:
cboot.log (36.1 KB)

original cbo.dts:
cbo_backup.dts (918 Bytes)

modified cbo.dts:
cbo.dts (918 Bytes)

It seems like modifying the cbo.dts is troubling the cboot and causing strange boot sequence.

17

Hi,

Can you just restore everything to original jetpack, no need to change anything in exlinux.conf and just focus on flashing cbo.dtb?

Try to flash the cbo.dtb only and see if it would reproduce the same error.

18

Hi,
I re-flashed everything and used the default files. the system hangs since it tries to boot from nvme, fails and not trying to boot from emmc afterwards (we know all partitions located on the emmc).
At this point I usually switch between nvme and emmc in the cbo.dts in order to boot properly (I didn’t do it now)

cboot_error.log (46.0 KB)

19

Hi,

Is this log you just shared a boot log with pure sdkmanager flash and even without updating cbo.dtb? Or it is one that already updates the cbo.dtb?

20

Without updating the cbo.dtb. fresh from the sources (didn’t use sdkmanager)

21

Hi,

Could you try to update to rel-32.7.1 and see if this issue is still there? I feel the issue is cbo.dtb somehow cannot take effect to change boot order. Sounds like a bug.

Sorry that I don’t have any rel-32 device anymore so cannot check this directly.