I have no idea what exactly could be triggering this Serror but I do not that it consistently prevents the system from booting.
For the record, I am not using Jetpack and expect to be able to solve this without having to use it at all.
I also don’t have a devkit so it’s not like I could use it without modification.
What I do have is access to Nvidia’s source code (release 32.5.1) and everything available in readable form there.
I’ve attached our current linux.config and board.dts just in case you might spot something that could be really important.
We don’t know either. The common way to debug such issue is check the usecase and configuration. There is no definitive answer to SError. I mean it is not possible to just use these few lines of log to find out where the cause comes from.
Can you just modify the dts only, flash the board and see if this issue is still? Checking what you have modified one by one and we may find the cause in the end.
Hi @WayneWWW
After loosing about two weeks checking things a hundred times and doing a lot of debug, I finally managed to catch the problem.
The error was trusting the Pinmux Generation Spreadsheet to do a decent job.
Not only has it failed to generate a dtsi that would compile properly but it has also failed to generate a dtsi that would run error free.
So, the system would completely freeze with the above mentioned message when doing a pxm_write to the following items: vcomp_alert_ps4, pwr_i2c_scl_ps0, pwr_i2c_sda_ps1 and batt_oc_ps2.
Regarding why this is happening or what the right configuration would be, I don’t know since those options look like something that is internal to the SoM and should not be modified.
Could you share what setting you’ve done to these pins? Also, are you using dtsi for them instead of the mb1 cfg file?
For TX2 series and Xavier series, the general way to use pinmux spreadsheet are different from Nano/TX1 case. We use the cfg file instead of directly copying dtsi to your dts files.
Hi @WayneWWW,
I’m using the cfg generated from the dtsi files with the pinmux-dts2cfg.py .
At the same time, I’m also using the dtsi files generated with the Pinmux Generation Spreadsheet inside my linux dts.
I see a comment in the Jetson TX2 Platform Adaptation and Bring-Up Guide about having only the bootloader configure the pins.
I think it is quite uncommon to expect this on any embedded platform.
It’s often the job of uboot and linux to do this.
The setting I had on those pins is the one you’d get from running the spreadsheet (it goes like this)
Hi @WayneWWW,
Since I’ve already made this work and you’ve already mentioned what Nvidia expects there’s probably no reason to continue with the discussion.
I’d love it if future versions had a simpler boot flow and relied on the more conventional way of using uboot and linux dts files.