Board not booting

[martin173]

My board is not booting after attempting to enable the i2c following this guide:

How to Test I2C Interface on DSBOARD-NX2 in Python?

Following the instruction, I misread one and input:

sudo usermod -a -G i2c [My User Name]
reboot

instead of:

sudo usermod -a -G i2c $USER
reboot

upon reboot I get a null MAC address, DT failed -99, and i2c failure.

after power off and on again, the device now just sits at the NVidia logo.
I believe what I’ve done is overwritten the i2c address, I’m hoping this can be fixed via serial comms, which I’ve ordered a cable for and am waiting on it being delivered.

But I could use help in knowing if this is what I’ve broken, and if it is fixable?
And what steps I should take to fix this, or further diagnose it.

Thanks

[WayneWWW]

Based on lots of previous experience, your cvm eeprom data, which could be accessed by i2c is probably corrupted.

Whether we can fix it or not depends on whether you can still access the terminial.
So waiting for your cable comes first.

[martin173]

I’ve reflashed it again using the newest version of Jetpak this time, and not the one we’re using, and it’s allowed it to boot.
Is there anything I should check before I power it off?

[martin173]

ran: sudo i2cdump -y 0 0x50
and the memory location can be read.

on reboot, the same error messages appeared, it did a bunch of scrolling checks, but it did allow it to boot.

I’m guessing there was a fix/workaround for this issue in newer version, how can I fix it so that I can jump back to 4.6?

[WayneWWW]

Hi,

It is not only whether you can read the memory or not. What matters is the content…

[martin173]

I seem to have the device fully working again, but as of now can’t get my I2C code to function.
I’m getting a: OSError: [Errno 121] Remote I/O error

Could the previous mistake be the cause?
What should I do to check the I2C adresses and EEPROM are working as intended?

[WayneWWW]

Check sudo i2cdump -y 0 0x50 and it shall match the same content as what we describe in the document.

To locate the document, go to below website

Jetson Linux Archive

→ choose your l4t version and l4t developer guide → search “eeprom” in the document and it will lead to the eepom section.

[martin173]

Hi, I got one of the devices working completely, and another 2 that looked like they were working completely, but they will not recognise an ethernet cable when it plugs into them (but use wifi fine).
The i2cdump -y 0 0x50 for the working board is:

00: 01 00 fc 00 54 0e 00 00 03 41 00 00 00 00 00 00
10: 00 00 00 00 36 39 39 2d 31 33 36 36 38 2d 30
20: 30 30 2d 33 30 31 30 20 41 2e 30 00 00 00 00 00 00
30: 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
40: ff ff ff ff 6C 63 3d 2d b0 48 31 34 32 34 38 32
50: 31 30 38 32 39 33 38 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 4e 56 43 42 1c 00 4d 31 00 00
a0: ff ff ff ff ff ff ff ff ff ff ff ff 6C 63 3d 2d
b0: bo 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Co: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
do: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1d

and the dump for one of the not working boards is:

00: 00 00 00 00 00 00 00 00 03 41 00 00 00 00 00 00
10: 00 00 00 00 36 39 39 2d 31 33 36 36 38 2d 30 30
20: 30 30 2d 33 30 31 20 41 2e 30 00 00 00 00 00 00
30: 00 00 FF Ff ff ff ff ff ff ff ff ff ff ff ff ff
40: Ff ff ff ff bO 64 3d 2d bo 48 31 34 32 34 38 32
50: 31 30 38 32 39 35 32 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 4e 56 43 42 1c 00 4d 31 00 00
a0: ff ff ff ff ff ff ff ff ff ff ff ff bo 64 3d 2d
b0: b0 48 00 00 00 00 00 00 00 00 00 00 00 00 00 00
cO: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
do: 00 00 00 00 00 00 0o of 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
fo: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 be

The main difference I can see is in line 01, where it doesn’t seem to pick the same EEPROM version, as well as different module ID’s, and “NVidia reserved” memory.
Worth noting is that the non-functioning device is on a completely fresh flashing of ubuntu 5.2.

[WayneWWW]

Please share the screen shot of what you dumped. It would be easier for us to directly check the human readable text.

Also, don’t know what ubuntu 5.2 you are talking about. No such thing here.

Please also tell us what question you want to ask now. It has been almost 3 weeks since you last comment.

[martin173]

image 1 is the working board, image 2’s board is not detecting anything in it’s ethernet port. (or not detecting the ethernet port as existing at all).
I’m assuming this is related to the prior issue as it’s the only thing that has been done to this board.

Sorry for the late reply, I hadn’t noticed this issue until today when working with the board.
The intent is to have this board on-site and using a LAN network via a router to control devices on the network, so the missing ethernet connection was what brought my attention to this issue.

And I meant Jetpak 5.0.2.

[WayneWWW]

Maybe you should check the last bit in your eeprom is correct or not. As my previous comment said, you should read the document to know the meaning of it.

The last bit is the CRC checksum bit. And it is the most common one that user hit issue.

[martin173]

Hi,
your assumption was correct, the crc for the non-working device is wrong, how can I overwrite this section, or is this non-writeable?

Thanks

[WayneWWW]

You can just use i2c tool to modify it.