Custom carrier with nano read error eeprom

Autonomous Machines Jetson & Embedded Systems Jetson Orin Nano
,
1

Hi, way out of my depth here so hoping for some help!

I’m trying to boot up an Orin Nano with an SSD in the M.2 slot using a custom carrier board. The Nano was flashed using a script from “BootFromExternalStorage” from JetsonHacks github.

It seems it’s not booting with the custom board so I’ve connected to debug console. The following is the last bit of that output:

I> Task: Prepare eeprom data (0x50017bd8)
E> I2C: slave not found in slaves.
E> I2C: Could not write 0 bytes to slave: 0x00ae with repeat start true.
E> I2C_DEV: Failed to send register address 0x00000000.
E> I2C_DEV: Could not read 256 registers of size 1 from slave 0xae at 0x00000000 via instance 0.
E> eeprom: Failed to read I2C slave device
C> Task 0x0 failed (err: 0x1f1e050d)
E> Top caller module: I2C_DEV, error module: I2C, reason: 0x0d, aux_info: 0x05
I> Busy Spin

  1. This suggests we have the wrong address set up for the eeprom on our custom board?

When I plug the Nano and SSD into a Dev Kit, it boots fine. I then go to /boot/ and look for DTBs. Here, I have no idea what I’m looking at. There’s a bunch of dtb and dtbo files. Two files stand out to me:
kernel-tegra234-p3767-0003-p3768-0000-a0.dtb
kernel-tegra234-p3767-0004-p3768-0000-a0.dtb

  1. Is it normal to have these two files? If I decompile them and look into them I see:

eeprom-manager {
data-size = <0x100>;

            bus@0 {
                    i2c-bus = <0x2c1>;

                    eeprom@0 {
                            slave-address = <0x50>;
                            label = "cvm";
                    };

                    eeprom@1 {
                            slave-address = <0x57>;
                            label = "cvb";
                    };
            };

            bus@1 {
                    i2c-bus = <0x2c2>;

                    eeprom@1 {
                            slave-address = <0x50>;
                            label = "super-module";
                    };
            };
    };

Is this related to the error I see on the debug console?

Any help appriciated.

3

Hi,

did you set the EEPROM read size on your custom board to 0?
https://docs.nvidia.com/jetson/archives/r35.3.1/DeveloperGuide/text/HR/JetsonModuleAdaptationAndBringUp/JetsonOrinNxNanoSeries.html#eeprom-modifications

4

Hi Dave, would this be it?

data-size = <0x100>;

I see this in both files:
kernel_tegra234-p3767-0003-p3768-0000-a0.dts
kernel_tegra234-p3767-0004-p3768-0000-a0.dts

Again, not sure which one of these I need to compile again once I’ve made my changes. I also get some warnings when I first decompile it but either way, I managed to dtb → dts so I could take a look at them.

So I need to change that to <0x100> and compile it again?

Thanks for your help.

5

Hi,

No, you don’t need to play with kernel dtb directly.
Please just make changes in this file as specified in the guide, and flash again:

Linux_for_Tegra/bootloader/t186ref/BCT/tegra234-mb2-bct-misc-p3767-0000.dts

- cvb_eeprom_read_size = <0x100>
+ cvb_eeprom_read_size = <0x0>

You don’t need to care about other files or do compiling/decompiling manually.
Or you think the guide is not clear?

6

No, I’m sure the guide is okay, I’ve just never worked with device tree configuration so I’m not really sure what I’m doing. For example, I don’t see Linux_for_Tegra in my root directory. This suggests the flashing of the Jetson was done incorrectly?

output of /etc/nv_tegra_release:

#R35 (release), REVISION 3.1, GCID: 32827747, BOARD: t186ref, EABI: aarch64, DATE: Sun Mar 19 15:19:21 UTC 2023

7

I mean, you have to do it on your host, and flash the device again.
These operations are not done on your device…

Just curious that if the custom board is made by yourself, how can you have not worked with device tree configuration? If the board is from some 3rd party vendors, they should provide a patched BSP, and you don’t have to do it yourself.

8

It’s a good question. We built the board with help from a 3rd party. We then placed an older Nano into it and saw that it booted fine. HDMI, USB, debug works. But that Nano is booting from micro ssd, so I guess that means it was flashed differently (JetPack 4.4 I believe).

Was hoping I could just flash this Orin Nano and place it into our custom board and boot it but I see that’s a bit naive. Definitely seems necessary to outsource this for a full BSP.

Although, I will see how far this change to eeprom takes me. Anything that we can get working is a win.

Update:
Changing cvb_eeprom_read_size to <0x0> didn’t seem to help but I’m sure many other settings need to be changed as per your comments from above. In case anyone wants to have a look at the debug output, here’s the entire file:
debug.txt (23.3 KB)

Appriciate any help!

Update
Scratch that last update. I must have failed to save the dts file after changing read_size. I went through it again and flashed. I get a desktop screen now!

@DaveYYY, I don’t understand the change, so I will try to read up on it, but it seemed to do the trick. Thanks so much.

1 Like
10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.