ok I saw its the connection type. I dont know but I can find out if you want
Could you ask your hardware guy about the pcie C5 controller diff on your board and devkit?
It is weird that you use a custom board and you keep asking me “I don’t know what is that”. You should ask your hardware engineer.
You are absolutely right. It’s my first experience with these stuff so I’m learn from each answer of yours.
The reason that I’m saying that I don’t know its because sometimes we can progress without all the details and sometimes not.
I’ll do my homework regarding the hardware and answer back here.
In the meantime, is it ok to ask about the sudo issue? because I can’t do anything without it.
Are you sure your device tree is not something from jetpack4.x? When I asked you “is your device tree a pure one from jetapck”, my actual point is if this is pure jetpack 5.0.2.
Please prevent some silly case that you think jetpack 4.x Device tree is also a “pure one from jetpack”…
If you are using jetpack5, then your device tree should be from jetpack5.0.2 too…
I checked my devkit but I couldn’t see anything like “‘msi-parent’: FDT_ERR_NOTFOUND”. Which means you may probably always use a wrong device tree in this time.
Thank you for your answer.
I’m sure because it happens when I use the SDK as well (not with the devkit).
I noticed another thing:
There are differences between the JP4.6 and JP5.0.2 drivers and dts files regarding the msi-parent property.
You can see them in the kernel and you can see that there are no dts files containing this property in JP4.6
So I think I experience a porting problem.
JP 4.6 “msi-parent” grep:
JP4.6_msi_parent_grep (12.7 KB)
JP 5.0.2 “msi-parent” grep:
JP5.0.2_msi_parent_grep (24.7 KB)
Currently after disabling the dt “pcie@141a0000” node, the target boots without the missing property error but I don’t have access to an internal PCIe switch in my system. I think its connected through this disabled channel (it uses the 4x lanes PCIe connection and not the 1x lane connection)
No, My point is I couldn’t see this error when I use UEFI debug build on devkit.
I am not asking about your custom board case. I am asking about your devkit case because you said “you saw the same error when using devkit”. That is the only thing I want to clarify now.
Also, WHY DO YOU EXPERIENCE A “porting problem”??? Why are you “porting” something? I already said this for multiple times. We are asking you to use the device tree from jetpack 5 directly.
There is nothing to “porting” in this part if you are using jetpack5 device tree.
You don’t need to grep anything in jetpack4. We don’t care and shouldn’t check anything about jetpack4 anymore.
I think there is a misunderstanding here.
the devkit works fine with JP 5.0.2 . That was never my problem.
I wrote it in the title and I wrote it here:
Jetson UEFI firmware hangs on custom carrier board - #29 by BSP_User
I apologize for my misuse of “porting” term.
I just meant to say that my same hardware , same custom board, works with JP4.6 and not with JP5.0.2 hence I need to “port” it. Maybe a bad choose of words
Could you just try to scroll down a little bit from the link you just posted?
You already answered my question that you said you also saw this error in devkit log. So is this true or not?
Please be aware that I am not asking whether you can boot up or not. I am just asking if you also see that error log in your log or not.
Whether it can boot up does not matter to me.
I’ll flash it again using the SDK and update just to be sure again.
Please be aware that you need UEFI debug build when flashing.
and the boot log:
boot.log (234.7 KB)
Sorry for the late response, have you managed to get issue resolved or still need the support? Thanks
I provided images following @WayneWWW reply.
UEFI does not get hang in your log…
You asked me if the error msg appears.
Sorry that I forgot what this topic is talking about.
Will review this again.
BTW, when you reproduce it on devkit, did you also have nvme connected?
I have it only internally on my custom board.
Thank you very much for your help and patience.
Are you able to add some debug print to the UEFI driver hangs the device and see where it got hang?
We cannot tell what got hang there but only which driver gets hang.
Just to make sure we understood each other:
When I use the devkit there is no hang. The UEFI hangs only when I use the custom carrier board without disabling one of the pcie@XXXX properties in the final dtb.
The error msg appears in both cases (custom carrier board and devkit)
- I noticed that if I use JP5.0 I get the same UEFI hang but with some more prints. Can it be helpful?
- Are there any instructions regarding how to modify the UEFI source code and build it?