OpenEmbedded for Tegra
Jetson Agx (jaxi) Return Value 8 from tegrarcm_v2 after sending bct_mem #1217
Replies: 6 comments 16 replies
-
|
Thanks @gsally-sarcos! To add on, this is our attempt to add support for the JAXI SOM. We have made what we think are appropriate updates in a local meta-tegra branch, including the creation of a new machine.conf file, a flashvars file, and appropriate changes to the flash-helper script to account for the Board ID and version number for JAXI. Any insight would be greatly appreciated as we continue debugging and tweaking things from our end. |
Beta Was this translation helpful? Give feedback.
-
|
Can you add |
Beta Was this translation helpful? Give feedback.
-
|
Hi @madisongh, thank you for being able to help, we've been working through this as best we can and need some expert assistance. For both of these scripts, I put the L4T log, this is working The project is public, so the files should be reachable; please let me know if there's trouble accessing them. |
Beta Was this translation helpful? Give feedback.
-
|
OK, I ran the This first one is probably the cuplrit (OE listed first, stock L4T second): This next one might cause issues later - you should remove the This last one is probably minor, and a result of only half-accommodating a change between R32.x and R35.x in the way I was handling the compressed forms of the BPMP DTB files: I've pushed a branch with a fix to the helper script for the 1st and 3rd problem above. Add those changes to any others you've made, fix your machine config to remove the extra overlay DTB, and give it another try. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much @madisongh I've added your suggested changes, and we seem to get through the flashing process now. We get through to the end of the flashing script, where it reboots the device. We have the board connected up to a monitor through the HMDI port and it doesn't seem to boot up again once the flashing script finishes. We have just acquired a serial cable to try and see a little more of what's happening on the board. In the meantime, I've attached the latest log for our "successful" run. I've also bumped our commit to a20e966, as this seems to be the last one before the BSP version was bumped to 35.2.1, just in case we were missing anything else. |
Beta Was this translation helpful? Give feedback.
-
|
Great that you're making progress. Watching the serial console should help in figuring out the next steps to take. |
Beta Was this translation helpful? Give feedback.
-
|
@madisongh, this is a bit frustrating in that we're not seeing anything from the serial or console, leading us to think this is an issue with the BCT or MB1. Far as we can tell, both of these are largely data-driven: the executable bits are from NVIDIA, the code reads data from tables to configure the machine and sets the instruction pointer for the uefi bootloader. For our environment, we're not getting to the uefi bootloader. Reading the documentation, we're stuck at one of the following
We've been looking at the various config files with a jaxi counterpart. The key difference detected is the enablement of ECC and the SCE in the bct configuration file (./tegra194-mb1-bct-misc-l4t-jaxi.cfg)
Digging through the docs, APE is the audio processing sub-system and SCE is for Safety Cluster Engine. There's information in the bring-up for disabling ECC, that seems to be a reasonable next step; by doing so, we'd have a configuration more closely approximating the standard Jetson board. |
Beta Was this translation helpful? Give feedback.
-
|
So the flashing completes, and when it reboots after flashing, there's absolutely no output from the serial console? Yeah, definitely something very early in the boot sequence isn't right then. Can you refresh your repo with the latest flashing logs (again with Also, I notice that the |
Beta Was this translation helpful? Give feedback.
-
|
Hi, Sorry for the slow reply. We don't have a board here where I can see the output from MB1 (we have a seeeeed studios carrier and one from Diamond systems) depriving me of some information that might tell me what is going wrong. I was comparing the configuration files between the working (l4t) and non-working (open embedded) for MB1 and they appear to be the same. Maybe I missed something? I re-ran the programming tools and posted the log file. Thanks for you help. |
Beta Was this translation helpful? Give feedback.
-
|
Can you repeat the stock L4T flashing also, and add the log for that which includes all of the actual partition writes? I've filtered and compared the new OE flashing log with that L4T flashing log, and up to the point where the L4T log ends, everything matches up between the two. With the full L4T log, we might find something added there that I'm missing. |
Beta Was this translation helpful? Give feedback.
-
|
Here's the logs from the stock flashing process. Sorry I didn't get those to you the first time around. |
Beta Was this translation helpful? Give feedback.
-
|
Any chance you could use the exact same L4T version as what we're using in whichever rev of meta-tegra you're at? That log you posted was from R34.1.1, which has quite a few differences from R35.2.1 and R35.3.1, making it harder to tell what might be relevant in the discrepancies between the two logs. |
Beta Was this translation helpful? Give feedback.
-
|
After (much) experimentation, I found that if I used the following binary files from my working L4T distribution, I was able to program/boot the Jetson Industrial with the Diamond systems carrier board: badpage.bin nvdisp-init.bin uefi_jetson.bin Here are the md5sums of the files I changed to get things working These are the md5 sums of the old files I copied this files into the output directory with the I looked in this (meta-tegra) project and didn't see these files, I'll need have a look to understand the origin of these files. |
Beta Was this translation helpful? Give feedback.
-
|
Great, thanks! I'm willing to add it in as a "community supported" machine, and let folks that use it help with keeping it maintained. |
Beta Was this translation helpful? Give feedback.
-
|
Of course. Like I said, we'd love to contribute these changes, as I know how I felt when I first looked here and saw it was not supported. Just want to make sure we're clear from a legal standpoint first. We hope to have an answer shortly. As an aside, I noticed you have some meeting notes listed in your wiki. Are these public meetings? Could I potentially request an invitation? I've learned a lot here and would love to be able to sit in and listen through the discussions. |
Beta Was this translation helpful? Give feedback.
-
|
This discussion should get updated with the invite for each month's meeting. Dan also posts them in our main Gitter channel. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @plyons72 Regarding
Yes all meetings are public and it would be great if you could attend. Monthly meetings and notes are tracked in the discussion at #515 and you can find a link there each month. See #515 (comment) for the upcoming May meeting. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you both! I look forward to attending! |
Beta Was this translation helpful? Give feedback.
-
Working to get the kirkstone branch L4T 35.1.0 working on our jetson AGX (@plyons72 is my colleague here) and we're stuck getting the flash.sh script to work. We've been checking the differences between the various files in the L4T code and the meta-tegra project. We're currently at revision 2512444
Any help getting past this problem, so we can use this project with yocto (which is so much better than the nvidia l4t tooling) to build and program our Jetson would be greatly appreciated.
Here's the tail end of the script (entire output will follow).
We're digging through the various xml/setting files see how br_bct_BR.bct is built (guessing there's some issue with the contents of this file?) didn't turn-up anything yet and looking at the strace results
It looks like the failure has to do with the USB port going down on the Jetson board, which leads to believe the tegrarcm_v2 --download bct_bootrom put the Jetson into reset. Just a guess. Next step us to use wireshark to compare the USB traffic to know for sure what's different about the data being sent in these two steps.
Using the Nvidia L4T software, we're seeing nearly identical logs, except the process succeeds:
Here's the complete log from the meta-tegra flash.sh program:
Beta Was this translation helpful? Give feedback.
All reactions