I have prepared a customized image for my custom carrier board and flashed in my NX dev kit and Custom Carrier board.
here is my observation…
While flashing image in NX Dev kit.
getting logs in display (hdmi) and in Micro usb connector (putty), getting console/shell access ,
logs attached in SoM_Logs_in_nx_dev_kit.txt
While Flashing same image in custom carrier board.
getting unstopable continous logs in micro usb connector (putty) , display in HDMI NOT working (HDMI is detected but showing " no signal" message), NOT getting console/shell access.
logs attached in putty_1.txt
Please help me with the possible solution to resolve this issue
may I know what’s the commands to flash your custom carrier board.
please check Pinmux Changes session, if your board schematic differs from that for Jetson Xavier NX Developer Kit board, you must change the pinmux configuration applied by the software. please refer to developer guide for the instructions.
thanks
I have refered the above link [Pinmux Changes] , and my understanding is like if i consider Signal name SPI0_CS1* then the GPIO number of SPI0_CS1 should be 320+(8*25)+7 = 527 .
In which file i should mention this GPIO number as 527 ?
Do i need to make these changes for all the signals mentioned in [Jetson Xavier NX pinmux table] .
I could not locate the README file in location , Linux_for_Tegra/kernel/pinmux/t19x/.
Please refer the refer the above logs as well and share the possible solution, as i am stuck in my bring-up process
the offset values seem incorrect,
please check kernel init messages for the allocation ranges.
for example,
the pin number, SPI0_CS1 / GPIO3_PZ.07 = (25 * 8) + 7 + 288 = 495.
$ dmesg | grep "registered GPIOs"
[ 0.778827] gpiochip_setup_dev: registered GPIOs 288 to 511 on device: gpiochip0 (tegra-gpio)
[ 0.788475] gpiochip_setup_dev: registered GPIOs 248 to 287 on device: gpiochip1 (tegra-gpio-aon)
[ 0.964370] gpiochip_setup_dev: registered GPIOs 240 to 247 on device: gpiochip2 (max77620-gpio)
you should only modify the signals the differ with developer kits.
had you download the JetPack release image with SDKManger? there’s readme file for your reference,
i.e. ~/nvidia/nvidia_sdk/JetPack_4.6_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/kernel/pinmux/t19x/README.txt
Firstly i am not getting shell terminal access , as logs are contiously repeating (LOGS ATTACHED ABOVE),
As discussed , it seems that there is some issue in pinmux changes like , assigning wrong GPIO number might be the possible issue.
How can i verify that what GPIO number is assigned to any particular signal.
As per the above formula ( the pin number, SPI0_CS1 / GPIO3_PZ.07 = (25 * 8) + 7 + 288 = 495) if i get the pin number for all gpios , HOW CAN I CHANGE THESE VALUE , IN WHICH FILE THESE CUSTOM CHANGES WILL BE MADE.
After making relevant changes , How can i cross check that whether the GPIO number are changed or not.
If improper Pinmux changes are not allowing to boot the board, then why their is no error in the logs (putty_1.txt).
Thank you for your patience… putty_1.log (392.4 KB)
please check the header file, you’ll see the GPIO port and its index values.
for example, $L4T_Sources/r32.6.1/Linux_for_Tegra/source/public/kernel/nvidia/include/dt-bindings/gpio/tegra194-gpio.h
in addition, those register GPIOs were by default allocated within the fix range, i.e. 288-511 for TEGRA194_MAIN_GPIO. 248-287 for TEGRA194_AON_GPIO.
As per the logs (complete logs are in putty_1.log)
[0001.520] I> Reading eeprom i2c=1 address=0x50
[0001.521] E> I2C: slave not found in slaves.
[0001.522] E> I2C: Could not write 0 bytes to slave: 0x00a0 with repeat start true.
[0001.523] E> I2C_DEV: Failed to send register address 0x00000000.
[0001.523] E> I2C_DEV: Could not read 256 registers of size 1 from slave 0xa0 at 0x00000000 via instance 1.
[0001.532] E> eeprom: Retry to read I2C slave device.
[0001.537] E> I2C: slave not found in slaves.
[0001.541] E> I2C: Could not write 0 bytes to slave: 0x00a0 with repeat start true.
[0001.549] E> I2C_DEV: Failed to send register address 0x00000000.
[0001.554] E> I2C_DEV: Could not read 256 registers of size 1 from slave 0xa0 at 0x00000000 via instance 1. [0001.564] E> eeprom: Failed to read I2C slave device [0001.569] I> Eeprom read failed 0x3526070d
[0001.573] I> create_pm_ids: id: 3668-0000-200-J, len: 15
[0001.578] I> config: mem-type:00,power-config:00,misc-config:00,modem-config:00,touch-config:00,display-config:00, len: 93
[0001.589] I> create_pm_ids: id: XXXX-XXXX-XXX-X, len: 15
[0001.594] I> config: mem-type:ff,power-config:ff,misc-config:ff,modem-config:ff,touch-config:ff,display-config:ff, len: 93
[0001.605] I> Adding plugin-manager/ids/3668-0000-200=/i2c@3160000:module@0x50
[0001.612] W> “i2c@3160000” doesn’t exist, creating
[0001.617] W> “module@0x50” doesn’t exist, creating
[0001.621] I> Adding plugin-manager/ids/XXXX-XXXX-XXX=/i2c@3160000:module@0x57
[0001.628] W> “module@0x57” doesn’t exist, creating
[0001.635] I> Adding plugin-manager/cvm
[0001.637] W> “chip-id” doesn’t exist, creating
[0001.641] I> Adding plugin-manager/chip-id/A02P
[0001.645] I> Plugin-manager override starting
=> We have connected EEPROM (in Device Address: 1010111 = 0x57H , I2C2) in our custom carrier board… But possibly it is not getting detected , is this the reason the board is not booting?
=> Even the default SD card image (Jetson Download Center | NVIDIA Developer) is also not working (logs of default sd card image flashed in Custom carrier board default_log.txt ). default_log (306.8 KB)
If we do not connect SoM to our carrier board and power-up the board , their is no power glitch in POWER_EN line of SoM.
But , whenever we connect the SoM in carrier board and Power Up it , we observe a ver very small glitch (the power get low for 4.3 usec, pls see in image power_glitch_while_SOM_is connected.jpeg) in power squencing at pin POWER_EN , Is this the reason that Our SoM is not booting.
I would like to update on this ticket, i believe this was not harware issue because…
because in my custom carrier board , the power supply distribution was made by PIC MCU (i generated MCU code by MPLAB MCC), and output of one of the MCU gpio (Port RB7) was input to SoM (at POWER_EN) , and i was getting 4.3usec power glitch at this pin.
Changes i made:-
In Mplab MCC (mplab code configurator), previously RB7 was selected as Analog Output port, but now i enabled all output gpio port as digital by unchecking the analog checkbox
Sorry that I couldn’t understand what you are trying to say.
Your comment said " i believe this was not harware issue because…:" and then your comment is totally none of jetson’s software at all.
Please be aware that if you don’t change anything on the jetson software and it worked, then it has nothing to do with the software. If this is MCU configuration problem, then it is not our software issue either. To jetson, it is a hardware problem.
