Busybox devmem on Thor

I try to config the padctrl register of CAN. but when I use devmem it report error.

car@car:~$ sudo -S busybox devmem 0x8110310000 w 0xc458
[sudo] password for car:
[ 778.884775] CPU:0, Error: top-cbb-fabric@0x8100800000, irq=16
[ 778.884841] **************************************
[ 778.884864] CPU:0, Error:top-cbb-fabric, Errmon:1
[ 778.885969] Error Code : FIREWALL_ERR
[ 778.890162]
[ 778.895397] MASTER_IDe : CCPLEXLL_ERR
[ 778.898890] Address : 0x8110310000
[ 778.902732] Cache : 0x0 – Device Non-Bufferable
[ 778.907623] Protection : 0x2 – Unprivileged, Non-Secure, Data Access
[ 778.914609] Access_Type : Write
[ 778.918101] Access_ID : 0x0
[ 778.918109] Fabric_Id : 0x14
[ 778.924389] Fabric : fsi-fabric
[ 778.927889] Slave_Id : 0x1
[ 778.937314] Beat_sizeeth : 0x2
[ 778.940457] VQC : 0x0
[ 778.946046] FALCONSEC : 0x0e
[ 778.949191] **************************************
[ 778.954126] WARNING: CPU: 0 PID: 5723 at drivers/soc/tegra/cbb/tegra234-cbb.c:648 tegra234_cbb_isr+0x148/0x180
[ 778.955050] —[ end trace 0000000000000000 ]—

how to config the register in Thor?

BR//

If you are talking about pinmux, then please configure it from the pinmux spreadsheet first.

Yes, I have configure the Pinmux. I think it’s also need configure these register:

Hi,

What I mean is this change is happened in the pinmux spreadsheet and then got changed by the MB1 bct during board flash. You don’t need to busybox write it again in CPU.

OK, we have config the pinmux spreadsheet , and generate dts like this:

But CAN0 don’t work. Is there any way for trouble shooting?

Hi @ekeechg,

Are you developing the custom carrier board for Thor?
Which Jetpack release are you using?
Could you share the result of cat /etc/nv_tegra_release on your board?

I can reproduce the similar firewall issue on the AGX Thor devkit + Jetpack 7.0 GA(r38.2.0) with the following commands. Please let me check with internal team.

$ sudo busybox devmem 0x8110310000 w 0xc458
$ sudo busybox devmem 0x8110310020 w 0xc400

But the CAN loopback test is working as expected as following. (you do not need to connect any cable externally)

$ sudo ip link set can0 type can bitrate 500000 loopback on
$ sudo ip link set can0 up
$ candump can0 &
$ cansend can0 123#abcdabcd
  can0  123   [4]  AB CD AB CD
  can0  123   [4]  AB CD AB CD

I do see the pinmux for CAN0 pins are configured for CAN usage by default: (in v1.3 pinmux spreasheet)
image