AM67A: PCIE Endpoint support appears missing from Linux kernel DTSI etc

Hi James,

We currently do not have a kernel tree that has PCIe endpoint mode support publicly. Let me check with the internal development team to see if there is something that is currently being worked on.

Regards,

Takuma

Thanks, that would be very helpful.  Initially I'd thought to try and craft it based on the AM64 files, but I'm not sure I have all the information required, it would be a shame to get into a bunch of debugging if such a known functional file already exists somewhere.  Appreciate any help you can offer.

One other question if I might; the TRM doc SPRUJB3 – MARCH 2024 states in relation to root complex vs end point mode (page 23):

"•Dual mode: Root Port (RP) or End Point (EP) operation modes, selectable via bootstrap pins"

I'm struggling to find documented anywhere what are these bootstrap pins that change the operation mode of the PCIE interface; I've tried searching the documentation and designs I could find, but to no avail; the BOOTMODE pins certainly don't seem to be it.  If these bootstrap pins do exist and must be configured a particular way, I need to be sure that the hardware I'm doing my testing on can be modified to correctly configure these pins.  If you could point me in the right direction here, that would be very much appreciated.

(edit - note I did find the following info: "The operational mode is selected with the CTRLMMR_PCIE0_CTRL[7] MODE_SEL register bit within the device Control Module (CTRL_MMR)" - but I note that a register bit isn't a bootstrap pin... so I'm still left wondering if I haven't found some critical information, or the description of the selection mechanism is just wrong)

Kind regards

James

Hi James,

I have less confidence whether we have support for EP mode on AM67A EVM. Still awaiting a response from our development team.

However, I have found in schematics that "ONLY RC MODE is supported". So it could be that the TRM has some artifacts from reusing the same documentation for our other platforms that do have EP and RC mode support.

As an example of what it should look like, J721E has a DIP switch that can select between EP and RC mode:

https://www.ti.com/lit/ug/spruis4e/spruis4e.pdf

AM67A EVM does not seem to have this pin.

Regards,

Takuma

Hi, Takuma,

Thanks for the prompt reply.  I've seen these PCIe_1L_MODE_SEL etc DIP switches before in these schematics for the reference boards.  But they seem to be hooked up to I2C expander pins, not actual straps on the SOC - so I expect that on the reference boards they're being read by something (uBoot perhaps?) and just setting the register in the SOC to change mode?  That kind of thing I could work around, it was more if there is any pin of the SOC with a strapping requirement that can't be worked around easily...  I see the MODE_SEL DIP switch also seem to be used to control some basic logic gating of the PCIe reset pin.  I planned to do that just with modification to cabling between the two units.  I did see though there is some difference on the board population for endpoint mode with the PCIe reference clock signals.  

I'm actually using Beagley-AI at the moment and not the TI reference board.

Kind regards

James

JAMES FINNIE said:

I'm actually using Beagley-AI at the moment

We were working with this too, not on PCIe. The base device tree is referencing stuff from the am62 and others. What I looked at is missing base device tree definitions. Tried to get some of the stuff up by defining it and found the manuals do not have all the information. Go into your .dtsi and follow the trail upstream and you will see what is going on.

I suppose it is to be expected to some extent, the devices are marked as Preview still on TI.com (a bit surprising as the Beagley-AI boards are all over distribution).  I saw there is some reorganisation happening of the DTSI files in 6.6 kernel (I was on 6.1 here following the latest Debian release on BeagleyAI) albeit nothing that helped with my particular issue.  Maybe with some more reorganisation all the common parts will be more logically split out.

I'm my case I've now been able to piece together my own DTSI file enabling the PCIe endpoint functionality by inspecting how this was done on AM64 (which used same base address for PCIe controller) and guessing that in all likelihood it follows the same patterns, adjusting pins and other things as per the PCIe host definition on AM67A.  Pleased to say I've been able to bring up the PCIe endpoint.

Not sure if you are aware, but there is a huge Excel spreadsheet of register definitions for the AM67A in the Technical Reference Manual archive SPRUJB3.zip.  The names don't always exactly match with how they are described elsewhere in the docs..  And some of the tables are marked Public, so I expect there may be some Private tables.

Hi Takuma,

I've managed to craft my own DTSI for the PCIe endpoint functionality on AM67A.

I extended what was there for the root complex in k3-j722s.dtsi, and guessed at which things to use from AM64, as that seemed most similar (same base address, similar root complex definitions minus some pins).  Then I recompiled kernel with EP instead of RC driver.   After bringing up the EP from console following some other guides and adapting steps as req,  I now have the endpoint at least instantiated between two AM67A BeagleyAI boards, and appearing in LSPCI on the host device, using some modified cables and adapters between them (just PCIe TX and RX crossed over, no clocks or resets etc connected).  

So at least on the surface, it seems like no strapping is actually required of the SOC device to switch between root complex and endpoint modes, so maybe the TRM is incorrect in that respect.   I'm pretty sure those config DIP switches and resistors on the EVM you showed are just to give a "nice" way of making the connections with more standard cables, and not breaking things... :). Of course it's possible I've just not yet found out why straps are necessary...

It would be nice to know if this functionality of the SOC is to be officially supported, and if so it would be really useful to get some "official" tree with support for this functionality.

Thanks and kind regards

James

JAMES FINNIE said:

Not sure if you are aware, but there is a huge Excel spreadsheet of register definitions for the AM67A in the Technical Reference Manual archive SPRUJB3.zip. 

Yes, I did find that, thank you for reaching out. Located the interupt for i2c4. However base has defined i2c2 and i2c3 with some additional power connect parameters that I have not been able to find and sysconfig does not provide that. Assuming that i2c4 would also require that information. When the .dts is loaded with only the reg and interupt values and mux info it breaks USB... Also had it break the kernel on boot with another set of values. Not sure if the driver is even compatible, did not find any clues as to where to find the "driver" .c or the actual name of it.

Hopefully if you reach out they can provide the missing info.  I'm finding it quite hard navigating some of the docs as sometimes the bits of registers seem to use slightly different names in different places, which can make searching non-trivial, maybe the info is there somewhere...

In my case I got lucky a bit I suppose because although the power connect and other parameters are different between AM67A and AM64 for PCIe, on the AM64 they follow a pattern that the endpoint uses the same config as the root complex for these parameters.  So I guessed this may still be the case and tried cloning the values from the AM67A root complex into the AM64 end point definition and merged it all, seemed to work and so far to be good enough to work.

I've not tried using it in anger yet, though, so there's still some chance I'm going to come unstuck on something or other.  It at least gets the link up and some basic comms across the link, so can't be too far off... (Famous last words!)

Hi James,

I checked with our internal development team and it seems like there is no plan to support EP-mode on the AM67 EVM. For reasoning, they said although the SoC supports switching between EP and RC mode, the TI EVM board does not have some hardware designed in to switch between the two modes. 

So as a warning, configuring for EP-mode on TI AM67 EVM seems like it is not possible. Or at least, nobody at TI has tried this out on AM67 EVM board.

However, looking through schematics for a different SoC in the same family of processor, J784S4 EVM, it seems like there is a DIP switch that just gates the PERSTz signal that is called PCIe0_4L_MODE_SEL and this is what the userguides mean for a switch to choose EP vs RC:

And if you are seeing some communication going across the link, then it could be that it is possible to configure as EP on AM67 EVM board despite the big bold red letters in schematics saying "ONLY RC MODE is supported". 

In any case, let us know how it goes.

Regards,

Takuma

Hi Takuma,

Well, I have EP "working" it seems between two AM67A Beagley-AI boards with just the cable with TX and RX swapped (no reset / clocks connected between the boards).  The cabling is limited to operation at PCI2.0 speed (5.0GT/s).  I've been able to use the pci_endpoint_test (at root complex side), pci_epf_test (at endpoint side) drivers and the pcitest / pcitest.sh utilities at the root complex side,  and things appear to work. MSI/MSI-X interrupts are working as well as DMA and non-DMA transfers.

I'm a bit disappointed with the performance using the pcitest and test drivers (broadly as discussed in the latter parts here https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/06_01_01_02/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/PCIe/PCIe_End_Point.html) , and I don't know why it is seemingly poor.  

The best I've achieved so far with DMA is about 55MB/sec, without DMA it's around 1/10th of this performance on writes/copy (reads similar to the below).  Reads/writes are similar to copy with DMA.  This performance around 55MB/sec would seem to be around 1/8th what you might expect to be able to achieve over a single PCIe 2.0 lane.  No errors appear in dmesg etc.

root@BeagleBone:~# time pcitest -d -c -s 4190208
COPY (4190208 bytes):           OKAY
real    0m0.076s
user    0m0.001s
sys     0m0.050s
root@BeagleBone:~# time pcitest -d -c -s 2190208
COPY (2190208 bytes):           OKAY
real    0m0.040s
user    0m0.000s
sys     0m0.030s

I'm not sure if this is some issue with the endpoint framework test drivers / tool, the Linux endpoint framework itself, the endpoint drivers, the cabling, configuration of the endpoint controller, capability of the SOC, etc. 

Would appreciate some input from anyone who is familar with the performance expectation for PCIe endpoint on these kind of SOC devices; we are trying to evaluate the feasibility of using such a SOC instead of FPGA for our application. 

Thanks and kind regards

James

Actually my previous message about performance is perhaps not the full story, it seems measuring from root complex side is maybe not very good (or at least, measuring it the way I did...!).  I see the endpoint test driver has some performance recording in it, here are the results from a script I made to test a range of different transfer sizes with and without DMA across all the various operations.  Still falls a bit short of what I would hope for I suppose; seems to be hitting around 50-60% of what you might expect for a single PCIE 2.0 lane?  What do you think about this?

[ 1507.238808] pci_epf_test pci_epf_test.0: WRITE => Size: 1024 B, DMA: YES, Time: 0.000198641 s, Rate: 5155 KB/s
[ 1507.246829] pci_epf_test pci_epf_test.0: WRITE => Size: 2048 B, DMA: YES, Time: 0.000194846 s, Rate: 10510 KB/s
[ 1507.254817] pci_epf_test pci_epf_test.0: WRITE => Size: 4096 B, DMA: YES, Time: 0.000188196 s, Rate: 21764 KB/s
[ 1507.266859] pci_epf_test pci_epf_test.0: WRITE => Size: 8192 B, DMA: YES, Time: 0.000202327 s, Rate: 40488 KB/s
[ 1507.274978] pci_epf_test pci_epf_test.0: WRITE => Size: 16384 B, DMA: YES, Time: 0.000229757 s, Rate: 71310 KB/s
[ 1507.283188] pci_epf_test pci_epf_test.0: WRITE => Size: 32768 B, DMA: YES, Time: 0.000275627 s, Rate: 118885 KB/s
[ 1507.291608] pci_epf_test pci_epf_test.0: WRITE => Size: 65536 B, DMA: YES, Time: 0.000375578 s, Rate: 174493 KB/s
[ 1507.300467] pci_epf_test pci_epf_test.0: WRITE => Size: 131070 B, DMA: YES, Time: 0.000580319 s, Rate: 225858 KB/s
[ 1507.314183] pci_epf_test pci_epf_test.0: WRITE => Size: 262140 B, DMA: YES, Time: 0.000972112 s, Rate: 269660 KB/s
[ 1507.329549] pci_epf_test pci_epf_test.0: WRITE => Size: 524280 B, DMA: YES, Time: 0.001748443 s, Rate: 299855 KB/s
[ 1507.352362] pci_epf_test pci_epf_test.0: WRITE => Size: 1048560 B, DMA: YES, Time: 0.003354325 s, Rate: 312599 KB/s
[ 1507.393952] pci_epf_test pci_epf_test.0: WRITE => Size: 2097120 B, DMA: YES, Time: 0.006464108 s, Rate: 324425 KB/s
[ 1507.472422] pci_epf_test pci_epf_test.0: WRITE => Size: 4190208 B, DMA: YES, Time: 0.012496407 s, Rate: 335313 KB/s
[ 1507.482793] pci_epf_test pci_epf_test.0: READ => Size: 1024 B, DMA: YES, Time: 0.000193591 s, Rate: 5289 KB/s
[ 1507.494757] pci_epf_test pci_epf_test.0: READ => Size: 2048 B, DMA: YES, Time: 0.000186877 s, Rate: 10959 KB/s
[ 1507.502825] pci_epf_test pci_epf_test.0: READ => Size: 4096 B, DMA: YES, Time: 0.000201192 s, Rate: 20358 KB/s
[ 1507.510827] pci_epf_test pci_epf_test.0: READ => Size: 8192 B, DMA: YES, Time: 0.000212572 s, Rate: 38537 KB/s
[ 1507.518855] pci_epf_test pci_epf_test.0: READ => Size: 16384 B, DMA: YES, Time: 0.000240247 s, Rate: 68196 KB/s
[ 1507.526940] pci_epf_test pci_epf_test.0: READ => Size: 32768 B, DMA: YES, Time: 0.000305173 s, Rate: 107375 KB/s
[ 1507.535091] pci_epf_test pci_epf_test.0: READ => Size: 65536 B, DMA: YES, Time: 0.000431104 s, Rate: 152019 KB/s
[ 1507.543376] pci_epf_test pci_epf_test.0: READ => Size: 131070 B, DMA: YES, Time: 0.000687881 s, Rate: 190541 KB/s
[ 1507.551915] pci_epf_test pci_epf_test.0: READ => Size: 262140 B, DMA: YES, Time: 0.001200643 s, Rate: 218333 KB/s
[ 1507.568973] pci_epf_test pci_epf_test.0: READ => Size: 524280 B, DMA: YES, Time: 0.002201431 s, Rate: 238154 KB/s
[ 1507.595118] pci_epf_test pci_epf_test.0: READ => Size: 1048560 B, DMA: YES, Time: 0.004201251 s, Rate: 249582 KB/s
[ 1507.635523] pci_epf_test pci_epf_test.0: READ => Size: 2097120 B, DMA: YES, Time: 0.008287211 s, Rate: 253054 KB/s
[ 1507.716144] pci_epf_test pci_epf_test.0: READ => Size: 4190208 B, DMA: YES, Time: 0.016256910 s, Rate: 257749 KB/s
[ 1507.726820] pci_epf_test pci_epf_test.0: COPY => Size: 1024 B, DMA: YES, Time: 0.000210347 s, Rate: 4868 KB/s
[ 1507.738764] pci_epf_test pci_epf_test.0: COPY => Size: 2048 B, DMA: YES, Time: 0.000189707 s, Rate: 10795 KB/s
[ 1507.750763] pci_epf_test pci_epf_test.0: COPY => Size: 4096 B, DMA: YES, Time: 0.000191521 s, Rate: 21386 KB/s
[ 1507.762768] pci_epf_test pci_epf_test.0: COPY => Size: 8192 B, DMA: YES, Time: 0.000206272 s, Rate: 39714 KB/s
[ 1507.774834] pci_epf_test pci_epf_test.0: COPY => Size: 16384 B, DMA: YES, Time: 0.000244651 s, Rate: 66968 KB/s
[ 1507.786892] pci_epf_test pci_epf_test.0: COPY => Size: 32768 B, DMA: YES, Time: 0.000316947 s, Rate: 103386 KB/s
[ 1507.799035] pci_epf_test pci_epf_test.0: COPY => Size: 65536 B, DMA: YES, Time: 0.000460474 s, Rate: 142322 KB/s
[ 1507.811308] pci_epf_test pci_epf_test.0: COPY => Size: 131070 B, DMA: YES, Time: 0.000735730 s, Rate: 178149 KB/s
[ 1507.819872] pci_epf_test pci_epf_test.0: COPY => Size: 262140 B, DMA: YES, Time: 0.001287894 s, Rate: 203541 KB/s
[ 1507.832971] pci_epf_test pci_epf_test.0: COPY => Size: 524280 B, DMA: YES, Time: 0.002385893 s, Rate: 219741 KB/s
[ 1507.859204] pci_epf_test pci_epf_test.0: COPY => Size: 1048560 B, DMA: YES, Time: 0.004584464 s, Rate: 228720 KB/s
[ 1507.899516] pci_epf_test pci_epf_test.0: COPY => Size: 2097120 B, DMA: YES, Time: 0.008941471 s, Rate: 234538 KB/s
[ 1507.980883] pci_epf_test pci_epf_test.0: COPY => Size: 4190208 B, DMA: YES, Time: 0.018247124 s, Rate: 229636 KB/s
[ 1507.994587] pci_epf_test pci_epf_test.0: WRITE => Size: 1024 B, DMA: NO, Time: 0.000008885 s, Rate: 115250 KB/s
[ 1508.006625] pci_epf_test pci_epf_test.0: WRITE => Size: 2048 B, DMA: NO, Time: 0.000016110 s, Rate: 127126 KB/s
[ 1508.018631] pci_epf_test pci_epf_test.0: WRITE => Size: 4096 B, DMA: NO, Time: 0.000033120 s, Rate: 123671 KB/s
[ 1508.030703] pci_epf_test pci_epf_test.0: WRITE => Size: 8192 B, DMA: NO, Time: 0.000067885 s, Rate: 120674 KB/s
[ 1508.038876] pci_epf_test pci_epf_test.0: WRITE => Size: 16384 B, DMA: NO, Time: 0.000136236 s, Rate: 120261 KB/s
[ 1508.047178] pci_epf_test pci_epf_test.0: WRITE => Size: 32768 B, DMA: NO, Time: 0.000273972 s, Rate: 119603 KB/s
[ 1508.059772] pci_epf_test pci_epf_test.0: WRITE => Size: 65536 B, DMA: NO, Time: 0.000561319 s, Rate: 116753 KB/s
[ 1508.072957] pci_epf_test pci_epf_test.0: WRITE => Size: 131070 B, DMA: NO, Time: 0.001112783 s, Rate: 117785 KB/s
[ 1508.087420] pci_epf_test pci_epf_test.0: WRITE => Size: 262140 B, DMA: NO, Time: 0.002290516 s, Rate: 114445 KB/s
[ 1508.108261] pci_epf_test pci_epf_test.0: WRITE => Size: 524280 B, DMA: NO, Time: 0.004481848 s, Rate: 116978 KB/s
[ 1508.141850] pci_epf_test pci_epf_test.0: WRITE => Size: 1048560 B, DMA: NO, Time: 0.008963470 s, Rate: 116981 KB/s
[ 1508.189166] pci_epf_test pci_epf_test.0: WRITE => Size: 2097120 B, DMA: NO, Time: 0.017947192 s, Rate: 116849 KB/s
[ 1508.290860] pci_epf_test pci_epf_test.0: WRITE => Size: 4190208 B, DMA: NO, Time: 0.035319875 s, Rate: 118635 KB/s
[ 1508.306764] pci_epf_test pci_epf_test.0: READ => Size: 1024 B, DMA: NO, Time: 0.000188126 s, Rate: 5443 KB/s
[ 1508.314949] pci_epf_test pci_epf_test.0: READ => Size: 2048 B, DMA: NO, Time: 0.000373987 s, Rate: 5476 KB/s
[ 1508.327307] pci_epf_test pci_epf_test.0: READ => Size: 4096 B, DMA: NO, Time: 0.000747920 s, Rate: 5476 KB/s
[ 1508.340062] pci_epf_test pci_epf_test.0: READ => Size: 8192 B, DMA: NO, Time: 0.001501041 s, Rate: 5457 KB/s
[ 1508.353581] pci_epf_test pci_epf_test.0: READ => Size: 16384 B, DMA: NO, Time: 0.002999577 s, Rate: 5462 KB/s
[ 1508.364604] pci_epf_test pci_epf_test.0: READ => Size: 32768 B, DMA: NO, Time: 0.006016704 s, Rate: 5446 KB/s
[ 1508.386624] pci_epf_test pci_epf_test.0: READ => Size: 65536 B, DMA: NO, Time: 0.012029923 s, Rate: 5447 KB/s
[ 1508.418691] pci_epf_test pci_epf_test.0: READ => Size: 131070 B, DMA: NO, Time: 0.024072167 s, Rate: 5444 KB/s
[ 1508.474860] pci_epf_test pci_epf_test.0: READ => Size: 262140 B, DMA: NO, Time: 0.048201880 s, Rate: 5438 KB/s
[ 1508.586834] pci_epf_test pci_epf_test.0: READ => Size: 524280 B, DMA: NO, Time: 0.096155732 s, Rate: 5452 KB/s
[ 1508.795381] pci_epf_test pci_epf_test.0: READ => Size: 1048560 B, DMA: NO, Time: 0.192530445 s, Rate: 5446 KB/s
[ 1509.211606] pci_epf_test pci_epf_test.0: READ => Size: 2097120 B, DMA: NO, Time: 0.384569111 s, Rate: 5453 KB/s
[ 1510.043912] pci_epf_test pci_epf_test.0: READ => Size: 4190208 B, DMA: NO, Time: 0.768469969 s, Rate: 5452 KB/s
[ 1510.058790] pci_epf_test pci_epf_test.0: COPY => Size: 1024 B, DMA: NO, Time: 0.000194641 s, Rate: 5260 KB/s
[ 1510.070960] pci_epf_test pci_epf_test.0: COPY => Size: 2048 B, DMA: NO, Time: 0.000396828 s, Rate: 5160 KB/s
[ 1510.079337] pci_epf_test pci_epf_test.0: COPY => Size: 4096 B, DMA: NO, Time: 0.000780636 s, Rate: 5247 KB/s
[ 1510.092133] pci_epf_test pci_epf_test.0: COPY => Size: 8192 B, DMA: NO, Time: 0.001563567 s, Rate: 5239 KB/s
[ 1510.105707] pci_epf_test pci_epf_test.0: COPY => Size: 16384 B, DMA: NO, Time: 0.003137068 s, Rate: 5222 KB/s
[ 1510.116894] pci_epf_test pci_epf_test.0: COPY => Size: 32768 B, DMA: NO, Time: 0.006290071 s, Rate: 5209 KB/s
[ 1510.135186] pci_epf_test pci_epf_test.0: COPY => Size: 65536 B, DMA: NO, Time: 0.012594977 s, Rate: 5203 KB/s
[ 1510.167762] pci_epf_test pci_epf_test.0: COPY => Size: 131070 B, DMA: NO, Time: 0.025147384 s, Rate: 5212 KB/s
[ 1510.232897] pci_epf_test pci_epf_test.0: COPY => Size: 262140 B, DMA: NO, Time: 0.050252778 s, Rate: 5216 KB/s
[ 1510.347331] pci_epf_test pci_epf_test.0: COPY => Size: 524280 B, DMA: NO, Time: 0.100598667 s, Rate: 5211 KB/s
[ 1510.571979] pci_epf_test pci_epf_test.0: COPY => Size: 1048560 B, DMA: NO, Time: 0.201115268 s, Rate: 5213 KB/s
[ 1511.005548] pci_epf_test pci_epf_test.0: COPY => Size: 2097120 B, DMA: NO, Time: 0.402508692 s, Rate: 5210 KB/s
[ 1511.871634] pci_epf_test pci_epf_test.0: COPY => Size: 4190208 B, DMA: NO, Time: 0.804165798 s, Rate: 5210 KB/s

Script:

#!/bin/bash
for op in r w c ; do
        for i in 1024 2048 4096 8192 16384 32768 65536 131070 262140 524280 10488
560 2097120 4194240 4190208 ; do
                pcitest -d -$op -s $i
        done
done
for op in r w c ; do
        for i in 1024 2048 4096 8192 16384 32768 65536 131070 262140 524280 10488
560 2097120 4194240 4190208 ; do
                pcitest -$op -s $i
        done
done

Hi James,

Yes, 50%~60% of theoretical throughput is currently the max actual throughput that we have measured on our end as well. We are looking into how (or rather, whether) we can improve this, but we do not have a timeline on when (or if) we can get improvements.

Regards,

Takuma

Hi Takuma,

Thanks for the info.  It's useful to know this is in line with expectation, and not because I'm missing something obvious.  Should we expect the throughput to scale in line with the 50-60% ratio of theoretical max as the number of available lanes and / or PCIe revision are changed - or is there some MB/s limit in the internal SOC architecture?

We're only currently using the BeagleyAI board and cheap modified PCIe 2.0 cabling as a testbed to learn about the TI SOC and PCIe ecosystem before investing in "Proper" EVMs etc.  In an actual design we would most likely end up with at least 2 lanes of PCIe3.0 (maybe with something like DRA821U or similar).  If those 2 lanes are capable of achieving 50-60% of PCIe 3.0 expectation, it would seem be comparable / maybe surpass the altenative FPGA option we are considering, that can only do PCIe 2.0 in its hard function.

Kind regards

James

Hi James,

Transfer speeds will depend on the application. 

Using the EP/RC test, I get around 1~1.5GB/s which is 25% of theoretical throughput of 4GB/s on AM69/J784S4 that has the same PCIe controller as AM67/J722S when using 4 lanes of PCIe3.0. 

However, I get 70% of theoretical throughput on the same processor when using the tool FIO to a SSD card with 2 lanes of PCIe3.0. I get around 1.4GB/s which is 70% of theoretical throughput of 2GB/s.

Internally, there should not be a limitation due to internal bus throughput, since the SoC was designed to handle max throughput. On the other hand, things such as the speed of the A72 CPU cores generating the random data, or block size of the data transfer, could affect throughput.

Regards,

Takuma