Kernel UART log: ERROR: camera-ip/isp5/isp5.c:1985 [isp5_pm_init] “ERROR: Failed to turn isp power on”


I just upgrade my BSP version to R35.4.1, and after I flash my Orin NX, it showed some errors after UEFI:

ERROR: camera-ip/isp5/isp5.c:1985 [isp5_pm_init] “ERROR: Failed to turn isp power on”
BUG: core/init/init.c:85 [init_all] “*** FIRMWARE INIT FAILED AT LEVEL 95 ***”

The carrier board is customized by us. The SOM is Orin NX 8G. The UEFI and Linux kernel are modified by me, also their versions are latest.


This is actually a weird question because this should be a problem that was already resolved by you before if this is a “upgrade” from some old release.

What I mean is this issue does not matter to upgrade to rel-35.4.1 or using rel-35.3.1.
Every custom board requires same customization as what you did during bring up period.

So please clarify if this is really a “upgrade” or this is your first time brining up…

This problem occured after I upgrade the BSP version of our custom system. We’re not using official Ubuntu, but the Yocto distribution released by OE4T.

Everything was fine before this upgrade. And I can not find any source code about this log, or any related information.


I am not sure if you know about it or not. If this is a “upgrade”, it means it does not know your original software… it will reinstall the latest software but only keep the filesystem things remained…

For example, you must already add some customization when you brought up your custom board before… but after this upgrade, those customization got overwritten and no longer existed…

Hello. Of course I already cherry-pick all the customization to new baseline. And what I mean is just upgrade the baseline of all BSP version, and also add all customization code to the projects. Including kernel, UEFI, and FileSystem Softwares.

The thing is I dont know what caused this problem, and how to fix it? Thank you.


This is related to the ODMDATA…

The point I keep telling is this thing does not matter to rel-35.4.1. Rel-35.3.1 has same thing too… If you didn’t configure this before, then even using rel-35.3.1 will hit issue…

That is what I don’t get. How come you didn’t hit this in your previous release if you don’t know the update of UPHY setting?

I’ve searched this log in this forum. It seems all the same error log occured on AGX Orin platforms, and the solution is disable the MGBE. from: ISP power on issue cause Orin boot failed But there is no MGBE config on Orin NX/Nano platforms.

Yeah, I’ve read this article yesterday. I never changed ODMDATA before, and the value is always: “gbe-uphy-config-8,hsstp-lane-map-3,hsio-uphy-config-0”. Also I never met this error before, and the image built before upgrade works well. So I made the false judgement.

If you even hit issue after updating ODMDATA, please share full flash log and boot up log from uart.

Sure. Here are the flashing log on Host and Target device. The target device log was got from the debug UART.
flash_qspi_host.log (68.0 KB)
flash_qspi_target.log (53.4 KB)

BTW, the bootup log is in the end of the flash_qspi_target.log. It begins with

[0000.066] I> MB1 (version:
[0000.071] I> t234-A01-0-Silicon (0x12347) Prod

Thank you!

Are you talking about you already added the ODMDATA data here?

The ODMDATA is here in the flash command:

MACHINE=apollo-nx ./ tegra234-p3767-apollo-evt.dtb tegra234-p3767-0000-sdram-l4t.dts gbe-uphy-config-8,hsstp-lane-map-3,hsio-uphy-config-0 boot.img saha-image-debug.ext4 "$@"


I have no idea about what you are doing. This whole command seems not our official tool.

To me, I think this didn’t apply the odmdata correctly.

The tool is released from GitHub - OE4T/meta-tegra: BSP layer for NVIDIA Jetson platforms, based on L4T.

Then please check with those github community about how to use their tool.

Of course I know how to use this tool and I’m sure it works. The point is what is the error log means and how to deal with it? Do you mean the ODMDATA did not work well?


The point is I don’t feel this tool flash the odmdata correctly.
If you want us to help check, then please move to use nvidia official tool.

I found the solution.

The config BPF_FILE was wrong for the Orin NX module. So it could load the correct binary file. The evidence is in the bootup log:

FATAL ERROR [FILE=platform/top/bpmp/startup/sku.c, ERR_UID=598]: chip sku 0xd3 not in <nv>/sku/te990m_0

Anyway. Thank you for your helps! I’ll close this topic.


The problem here should be how come this thing is needed to got modification…
This was never needed.

Please check with the Yocto distribution community if you are always using their tool to flash…

1 Like

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