GPMC speeds

zorgee

I was looking at the following link:

http://valentfx.com/wiki/index.php?title=Logi-Bone_User_Guide#BBB_GPMC_to_FPGA_Interface

In this page, you mention that "the current LOGI GPMC drivers have a theoretical bandwidth of 76MB/s and measured up to 69MB/s in user space for transfer of 128KB blocks". Do you have a project that performs this test? I'm assuming it would be something similar to the logi-com-test but without any of the wishbone components. 

If I need to create my own GPMC test, would the following changes to the device tree overlay make sense?:

• Change "gpmc, sync-clk-ps = <20000>;"  to "gpmc, sync-clk-ps = <10000>;"
• Uncomment "gpmc, burst-write" and "gpmc, burst-read"

I'm trying to get as much speed out of the GPMC bus without having to write an application-specific kernel module.

jpiat

Hi,

the best performance with the GPMC is obtained with burst omde enabled (uncomment the two lines you see in the dts file) and with transfer of blocks as big as possible. The ptoblem with small blocks being that restarting a transfer takes sometime between of the switch between user space and kernel space. One other sthing to change is the beaglebone cpu speed. By default the BBB boots in a conservative mode with a clock of 300Mhz and then the clock speed scales on demand up to 1Ghz (this allow to save power). To change the clock speed you need to do a cpufreq-set --governor performance (install cpufreq if needed using apt-get). Changnig the gpmc,sync-clk-ps is a bad idea though. This will change the clock speed of the GPMC module and the clock that is being used to drive the FPGA during transfers. With the change you propose the clock speed will become 100Mhz and considering the connector style of the BBB there is a good chance it will fail ...

Another option with which someone got better transfer speed was to use the GPMC in an asynchronous mode and then sample the GPMC signals in the FPGA. With a 150Mhz FPGA clock speed, this allowed to have a transfer taking only three 100Mhz clock cycles, but was not reliable depending on design placement in the FPGA.

The project used for this was the com-test, but we would not check the data back. To use the gpmc in burst mode you also need to set the "burst" generic attribute to "true" in the gpmc_wishbone_wrapper component (in the top level of the project).

This burst mode was proved to work fine, we just choose to enabled a more conservative communication mode in the default support.

Regards,

Jonathan Piat

jpiat

here is the link to some code for testing gpmc speeds :
https://github.com/fpga-logi/logi-projects/blob/master/logi-wishbone/sw/logibone/test_wishbone.c

here is the output on my system running the latest ubuntu but with burst access disabled (note the difference in write and read speeds).

ubuntu@arm:~$ sudo ./test_wishbone
Time in Microsecond=4368
W Speed=====30007 KB/Sec
Time in Microsecond=11417
R Speed=====11480 KB/Sec (~70% of theoretical speed)

the burst access greatly improves the read speed. In normal mode, a read takes 120ns to complete (hence a 16.6MB/s theoretical speed). in burst mode accessing 32 bytes takes 120ns+15*20=420ns which gives a theoretical speed of  76.19MB/s. The timing used on the GPMC are conservative, and could be adjusted with a risk of getting unstable data. From what i observed timings can be lower but sometime the results depends on the placement choice in the FPGA (placement performed by the ISE tool).

Regards,

Jonathan Piat

jpiat

If you want to profile the kernel module speed in kernel space (where the speed is the greates), you can compile the kernel (see instruction on the wiki : http://valentfx.com/wiki/index.php?title=Develop_new_driver_for_LOGI-Bone) and then edit the driver file to enable profiling (there is a commented #PROFILE macro). This will print the transfer speed in the logs (can have look using dmesg).

zorgee

Thank you for the answers. I am now a bit confused about how to have changes in the dts file be reflected in the BBB. I tried generating a dtbo file from my changed dts file using the following command:

dtc -O dtb -o BB-BONE-LOGIBONE-00R1.dtbo

I placed the resulting dtbo file in "/lib/firmware" directory. This didn't seem to apply my change. I also saw the answer you provided at the following link:

http://valentfx.com/vanilla/discussion/comment/129/#Comment_129

I'm assuming these steps take place on a computer external to the BBB. What is not clear to me is how the results of these steps get transferred onto the BBB. Is there a command that copies all relevant files to an SD card that the BBB can boot from? 

jpiat

Unfortunately to get a cape detected upon boot, the dts file has to be compiled in the kernel ... So if you want to make a change to the dts file, you'll have to compile the kernel yourself by followinf instructions at http://valentfx.com/wiki/index.php?title=Develop_new_driver_for_LOGI-Bone on an external computer running linux. If you want i can compile the kernel for you, i'll just need your kernel informations. To do so, just type uname -a in a terminal on your beaglebone and copy paste the result in this forum thread.

zorgee

I complied the kernel based on the instructions you linked to above. Once the kernel is compiled on an external computer and I have modified the dts file, do I need to recompile the kernel? 

Also, how do I get the newly compiled kernel written to the SD card that the BBB boots from? 

jpiat

Once you have modified the dts file, you'll need to recompile the kernel by running the script tools/rebuild.sh (in the logi-dev folder). Once everything is built, you'll end up with files in the deploy folder. From these files, you need to use the *.zImage file to replace your kernel uImage and the *-dtbs.tar.gz file to replace the device tree files of your boot folder. If you run latest Debian or Ubuntu, the kernel files and dtbs folder are in the boot directory of your root filesystem. There should be a uImage file that need to be replaced by the *.zImage(renamed uImage) file and a dtbs folder in which you need to copy the generated *-dtbs.tar.gz file and untar it. You can keep the existing uImage file by renaming it in case you want to get back to the original kernel.