Unable to update RT registers of Xavier SOC (Carmel cores)

Hello,

With the new DRIVE OS 5.1.6.1 that is shipped with DRIVE Software 10.0, we are unable to update Xavier SOC’s i.e. Carmel cores’ RT registers. We were able to update those with previous release (DRIVE Software 9.0 and DRIVE OS 5.1.0.2).

On Jetson Xavier and previous DRIVE OS release, we used to update these registers along with RedHawk tuning in order to achieve low latency and real-time performance. Please let us know if there has been any change to the behavior of these registers in terms of how they are updated or their channel index.

Xavier TRM, page 496:
http://developer.nvidia.com/embedded/dlc/xavier-technical-reference-manual

Hi pablo.ongini99501,
Did you mean you cannot access NV_ERXPFGCTL_EL1 with v5.1.6.1? What’s the error message? Could you provide your code and binary for us to reproduce the issue?

Please also check if any relevant information in the release notes (~/nvidia/nvidia_sdk/DRIVE_Software_10.0_Linux_OS_E3550/documentations/drive_linux_release_notes/NVIDIA_DRIVE_Linux_5.1_AGX_Release_Notes_5.1.6.0.zip).

Hello VickNV,

No, I am referring to NVGINDEX_EL1 and NVGDATA_EL1 registers where we are using the channels (information/commands) RT_SAFE_MASK, RT_WINDOW_US and RT_FWD_PROGRESS_US mentioned on page 496. Sorry for the wrong terms used before, but I just referred to the email that was sent to us by one of the NVIDIA engineers.

Anyway, the code itself is part of the kernel and there’s no separate binary but below is a snippet of the code we are running on Jetson Xavier:

int set_rt_safe_mask_reg(void)
{
	asm volatile (
		"msr $NVGINDEX_EL1, %0	\n"
		"msr $NVGDATA_EL1, %1	\n"
		:: "r" (80),
		"r" (rt_safe_mask));

	return 0;
}

“rt_safe_mask” variable is any value between 0-255 ($(NUM_CORES):0 bits) which is passed in through the grub command line. It has been verified that the value passed through the kernel arguments has been passed to code which should have set these values but something in the assembly code itself is failing.

The above code is ported in exactly the same way on DRIVE OS 5.1.6.1 or the previous DRIVE OS.

Similarly, we are updating other registers where NVGINDEX_EL1 is set to 81 or 82. Also, care has been taken to reset RT_SAFE_MASK register before setting other two registers.

Also, there’s no error code displayed in the kern.log or syslog. Dunno if there’s any other log file we should refer to.

Hello,

Some more update on this issue.

It has come to our attention that the value of the RT_SAFE_MASK register on Xavier A and Xavier B of the DRIVE AGX Developer with 5.1.6.1 is different.

On Xavier A:
RT_SAFE_MASK is equal to 0. It can’t be updated through OS level i.e. EL1 even though the register should be modifiable.

On Xavier B:
RT_SAFE_MASK is equal to 252. Same behavior as above but there’s no info about it in any of the log messages. We don’t know how or why the value of the register has been set to 252.

Please provide a solution for this issue as re-/setting the values of these registers is important to achieve RT performance.

Hi pablo.ongini99501,

RT_SAFE_MASK is equal to 0. It can’t be updated through OS level i.e. EL1 even though the register should be modifiable.
I think it should be 252 (0xFC) too. Could you share your way to check RT_SAFE_MASK value? I would like to check on my side.

From this release, Hypervision blocks write access to all NVG registers so guest os cannot cange the values. That’s why you cannot change the value.

Hello VickNV,

Thank you for your reply.

I think it should be 252 (0xFC) too. Could you share your way to check RT_SAFE_MASK value? I would like to check on my side.

We have been checking the value like below:

asm volatile (
	"msr $NVGINDEX_EL1, %0	\n"
	:: "r" (80));
asm volatile (
	"mrs %0, $NVGDATA_EL1	\n"
	:"=r" (rt_safe_mask));

return rt_safe_mask;

And we try to update it the way I have mentioned in comment #3.

From this release, Hypervision blocks write access to all NVG registers so guest os cannot cange the values. That’s why you cannot change the value.

Is there a way we can play with it on the host side before flashing? I mean can we change the values this register so that different value can be flashed as required?

Is there a way we can play with it on the host side before flashing? I mean can we change the values this register so that different value can be flashed as required?
As I replied in your other topic, the current DRIVE Sofware release isn’t ready for performance development. If you have critical need on this, please contact your NVIDIA representative for further discussion. Thanks!

Hello VickNV,

Thanks again for the response.

I understand NVIDIA’s stand. We will check with the NVIDIA representative for our requirements.

However, will we have a firmware update (or a solution) for below?

Hi AnishAney,

Are both Xavier A and B on DRIVE Software 10?

Due to some reasons, we didn’t enable RT mode in DRIVE Software 10.
So RT_SAFE_MASK as 0 is expected on either Xaver A or B and we cannot help on the configuration here.

Hello VickNV,

Yes, both the Xaviers are flashed with DRIVE Software 10.

Due to some reasons, we didn’t enable RT mode in DRIVE Software 10.
So RT_SAFE_MASK as 0 is expected on either Xaver A or B and we cannot help on the configuration here.

Do you know if any future DRIVE Software releases will have RT mode enabled on both Xaviers?

Yes, RT mode was enabled in our master branch (internal) so if “no surprise”, I believe the next release will have it enabled.