AM623: Configuring firewall for DMA buffer pool

Hello,

I am not very familiar with the DMA architecture but the firewalls only cares about protecting a given memory address space. If there are multiple address spaces, like for descriptors and buffers as you said, associated with the DMA then you would need to firewall such address spaces.

Regards,

Prashant

Hello,

my current firewall configuration is as you suggested:

• Background region for the whole address space 0x80000000 - 0xe0000000 with these permissions:
  • Allow access to everyone using wildcard privid 0xC3.
  • Allow access to everyone using wildcard privid 0xC3 (redundant).
  • Block access to DMA (privid = 0).
• Foreground regions 0xb0000000-0xb0200000 with the following three permission settings:
  
  • Allow access to everyone using wildcard privid 0xC3.
  • Allow access to everyone using wildcard privid 0xC3 (redundant).
  • Allow access to everyone using wildcard privid 0xC3 (redundant).

The descriptor ring is located at 0xb0000000, frame buffers are allocated starting at 0xa0000000.

From the Firewall config I would assume, that DMA should not be able to write at 0xa0000000, but it can. On the other hand when the foreground region is somewhere else, DMA no longer works because of missing access to 0xb0000000.

So to me it looks like the Firewall does not properly protect memory accesses from DMA. I also tried adding priv ID 192 (DMA Reserved Priv-ID) to the blocked list, but without change.

I noticed that the Frame buffers use ASEL (another system I do not fully understand) and the TRM states that the Firewall on DDR is not ASEL capable. 
Could this be the problem here? Could you explain what ASEL is used for?

Thanks

Hello,

M K said:

From the Firewall config I would assume, that DMA should not be able to write at 0xa0000000, but it can.

It should unless the DMA transaction was tagged with another PRIVID.

You could create another foreground regions for the frame buffers address space with the permissions to block access for everyone (0xC30000). Then, you can get the PRIVID from the firewall exception logging by SYSFW.

Regards,

Prashant

Hello,

how can I enable firewall logging?

Thanks

Hello,

Please refer to the following guide for enabling TIFS logs:

https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/10_01_10_04/exports/docs/linux/How_to_Guides/Host/SYSFW_Trace_Parser.html

The TIFS logs, if enabled correctly, would come on the MAIN_UART1 instance.

Regards,

Prashant

Hello,

thank you for the link. I need some time for this because on our board UART1 is not easily accessible externally.

Hello,

The traces could also be collected from the memory buffer as described here:

https://software-dl.ti.com/tisci/esd/latest/4_trace/trace.html#trace-memory-buffer-location

However, since these buffers are circular ones, the traces captured may not be full and not provide the relevant information. But, it can be given a try if it's too much to enable UART1.

Regards,

Prashant

Hello,

I managed to read the trace from the memory buffer.

Here are my findings:

Blocking the descriptor ring (priv-id 0, starting at 0xB0200000) :

Because only priv-id 0 is blocked here, this should originate from the DMA.

FWL Bit  0x1
Exception addr  0x45B0000
FWL Exception  0x1000100
 0x60000
 0xB0200000
 0x0
 0x821000
 0x8

FWL Bit  0x1
Exception addr  0x45B08000
FWL Exception  0x1000100
 0x60000
 0xB02002C8
 0x0
 0x821000
 0x8

FWL Bit  0x1
Exception addr  0x45B08000
FWL Exception  0x1000100
 0x60000
 0xB0200570
 0x0
 0x821000
 0x8

Blocking the buffer ring (priv-id 0xc3, starting at 0x8FFF0000):

Here the initiator should be the dma, because the address is not accessed before receiving data (AFAIK).

FWL Bit  0x1
Exception addr  0x45B08000
FWL Exception  0x1000100
 0x70000
 0x8FFF2040
 0x0
 0x42201
 0x40
 
FWL Bit  0x1
Exception addr  0x45B08000
FWL Exception  0x1000100
 0x70000
 0x8FFF4040
 0x0
 0x42201
 0x40

FWL Bit 
0x1
Exception addr  0x45B08000
FWL Exception  0x1000100
 0x70000
 0x8FFF5040
 0x0
 0x42201
 0x40

FWL Bit  0x1
Exception addr  0x45B08000
FWL Exception  0x1000100
 0x70000
 0x8FFF6040
 0x0
 0x42201
 0x40

FWL Bit  0x1
Exception addr  0x45B08000
FWL Except
on  0x1000100
 0x70000
 0x8FFF7040
 0x0
 0x42201
 0x40

Could you please help me understanding these logs?
I can identify the accessed address and assume the FWL Bit being the firewall ID (1=DDR). How can I find the priv-id causing the transaction?

Thanks.

Hello,

According to the table "Table 3-5 Firewall Violation Parameters"

https://www.ti.com/document-viewer/lit/html/SPRUIV7B#GUID-26BD43DA-22BA-4EC0-A0BA-0E6F7AD6EE27/TITLE-SPRUIM0INT_SPRUIM0_SA_00050

The privid is part of the DATA2 register. In the logs, the second last value in the exception log is DATA2 register value. So,

M K said:

Blocking the buffer ring (priv-id 0xc3, starting at 0x8FFF0000):

Those exceptions are for the write transactions from the privid 1.

According to the following, the privid 1 is associated with the A53.

https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62x/firewalls.html#list-of-priv-ids

Unless the DMA is inheriting the initiator privid, the write transaction could be originating from the Linux Kernel. Are you sure that no one except DMA is writing to those buffers?

Regards,

Prashant

Hello,

indeed it looks like DMA is inheriting the A53 priv Id. After some more testing I identified that the required permission in the DMA buffer region is Non-Secure/User/Cache. If this is enabled, frames are properly received, but if it is disabled, neither DMA nor Linux can access the region. I tested it with only this single permission, which shows to me that it is also used by the DMA, otherwise it would trigger another exception. Also I do not see a write access to the RX buffers in the Linux code.

Hello Prashant,

what could be the reason for DMA inheriting the A53 priv ID? Could the incoming transaction be handled by A53 after the descriptor was fetched?

I see that ASEL is set to 15 for the buffer addresses, can this change the priv ID? But I am having issues, when I set it to 0 in the device tree.

Thanks.

Hello Prashant Shivhare,

Any update on this issue?

Hello,

Apologies for the delayed response.

I tested the UDMA_MEMCPY_POLLING example for A53 core from the MCU+ SDK. And I do not see DMA using different PrivIDs for descriptors and frame buffers.

// Descriptor buffer
FWL Bit  0x1
Exception addr  0x45B08000
FWL Exception  0x1000100
 0x60000
 0xA0000000
 0x0
 0x801000
 0x10

// Tx and Rx buffers
FWL Bit  0x1
Exception addr  0x45B08000
FWL Exception  0x1000100
 0x60000
 0xA0100000
 0x0
 0x801000
 0x40

Can you share your current firewall configurations?

Thanks!

Hello Prashant,

thank you for the test. This gives me the hope that the hardware supports my goal and I might miss some configurations.

Here is my current firewall configuration with some annotations:

TI UDMA (INFO)>: fwl_id=1, region=0, n_permission_regs=3
TI UDMA (INFO)>: control=0x11a
TI UDMA (INFO)>: perm[0]=0xc3ffff
TI UDMA (INFO)>: perm[1]=0xc3ffff
TI UDMA (INFO)>: perm[2]=0x008888 <- Disallow UDMA
TI UDMA (INFO)>: Range: 0x80000000 - 0xefffffff <- full memory range
TI UDMA (INFO)>: fwl_id=1, region=1, n_permission_regs=3
TI UDMA (INFO)>: control=0x1a
TI UDMA (INFO)>: perm[0]=0xc3ffff
TI UDMA (INFO)>: perm[1]=0xc3ffff
TI UDMA (INFO)>: perm[2]=0xc3ffff
TI UDMA (INFO)>: Range: 0xb0000000 - 0xb007ffff <- buffer descriptor ring
TI UDMA (INFO)>: fwl_id=1, region=2, n_permission_regs=3
TI UDMA (INFO)>: control=0x1a
TI UDMA (INFO)>: perm[0]=0xc38888
TI UDMA (INFO)>: perm[1]=0xc38888
TI UDMA (INFO)>: perm[2]=0x018888 <- Kernel cannot boot
                         0x018c88 (user,nsec,cache) <- Kernel can boot and frames can be received
TI UDMA (INFO)>: Range: 0xa0000000 - 0xa8000fff <- Linux Kernel + frame buffers

With the last region I am experimenting to see what works and what not. I identified the cache permission flag to enable memory access from Linux. However, with this flag set, also DMA can write to memory. Maybe there is some cache configuration missing?

Thanks and regards

Hello Prashant,

any remarks on my firewall configuration?

I have now figured out that with setting the cache bit in control register (0x200) I can get some better control over the access and the read/write permissions perform more like I expected.

However, I still only catch accesses to the frame buffers with priv-id 1. 

What could be the reason for DMA inheriting the A53 priv ID? Could the incoming transaction be handled by A53 after the descriptor was fetched?

I see that ASEL is set to 15 for the buffer addresses, can this change the priv ID?

Thanks.