How to Communicate the DDR memory locations of Zedboard

Hi,

It's not clear to me what you're attempting to do. If you want to copy some data to a specific address in physical memory space (e.g. a certain region in the DDR memory), you'll have to write a small kernel driver for this. At a minimum, this kernel driver needs to map the specific physical memory chunk into virtual address space. Otherwise it can't be reached from Linux.

As a side note, it looks like you want to communicate data with the PL (logic part) of the device. You may want to use the Xillybus streams for this purpose (see http://xillybus.com)

Note that you may configure (and immediately download) your custom Xillybus IP core online to meet your communication needs.

   Eli

Hi Eli,

Thanks for ur reply...
here i am trying to accessing the some memory region's of Zed for moving my input data's to corresponding location's.

For this communication's needed the linux driver's..
wt u mentioned in the above,

In the same way,on Standalone OS,zedboard.org provided some API's and examples for communicating with DDR,OCM,PL region's through DMA,
here i am able to accessing the memory region's of Zed,
But in my code files,i used c-format  fopen()and other file function's.
By using this function call's i am trying to accessing the my hexa data from input.txt files and then trying to move my data's to OCM or other memory region's of Zed.

Compilation of my c-codes in SDK is fine,
when i am trying to debugging the my code,step by step,the fopen() system call giving the problem,
for example: File *fp=fopen("cur.txt","r");
i am using this way for reading my data from input files,
But in SDK,in Debugging time my *fp is always going to NULL,

can you please let me know about this isssue,where i am doing wrong,
Is it fopen() and c-forat file function's are able to use in the xilinx SDK or Not?
Please provide some help in this issue?

When using Xillinux, I recommend compiling the C code on the Zedboard itself with gcc (possibly using "make" as well). A lot of things can go wrong when cross-compiling user space applications.

Another thing to keep in mind, is that examples that were written for a bare-metal ("standalone"?) setting, i.e. without Linux, are irrelevant. In the bare-metal situation, you can access any peripheral just by setting a pointer to its address in physical memory, and use the pointer. Linux (or any decent OS) doesn't let you do that.

So that leaves you with two choices:
(1) Write a small driver for the kernel to mediate between the user space program and the physical resources.
(2) Use some existing kit. For general-purpose I/O with the logic fabric, Xillybus or Xillybus Lite may come handy. These are already installed in Xillinux.

As for your question about the return value of fopen() being NULL, this simply indicates that opening the file failed. The most plausible reason is that the file didn't exist.

A final note: Xillinux is a full-blown Linux OS, which behaves very much like a desktop distribution of Linux (Ubuntu 12.04 for PCs in particular). If you're struggling a bit with the plain C programming part, I would suggest installing Linux on a desktop, and get those issues sorted out first, possibly with Eclipse for C/C++. I wouldn't install Eclipse on Xillinux itself, but you should be able to export the project into a plain sources + Makefile bundle in any decent IDE for Linux.

For the purpose of plain programs in C, anything that runs on the desktop should run on Xillinux exactly the same.

Hope this moves you forward,
    Eli

Hi Eli,

Thanks for ur reply and your suggession's.......

Previously i created xillinx Linux(Ubuntu) on Zedboard by using xillybus,i compiled and executed large c,c++ codes on xillinux successfully,

For communication,can u please provide some sample link's or sample example stuff on this Linux side.

HEVC codes also i executed successfully on this.

But now i am trying on Standalone OS Zed,
As now i am trying to compiling and executing nearly 10 c-code files on Standalone Zed,
In this files i used file operation's on c-format file sys calls(fopen,etc)...

same files i am trying to running on Zed(standalone),
there i given  exact path to my input file in the fopen(),file also exist...
but still my still my *fp is always goes to NULL,

can u plz let me know is c-format file related sys calls is possible to xilinx SDK?
for same purpose any changes required on SDK environment?

Please provide some help on this..................

Xillybus' documentation explains the communication issue pretty extensively, and the demo bundle's code shows an initial setting to start off with.

As for a non-Linux setting, I can't help much, as my focus is working with Linux.

   Eli

Hi Eli,

I followed the steps in the below pdf document for AMP running,
http://www.xilinx.com/support/documentation/application_notes/xapp1078-amp-linux-bare-metal.pdf

Here i am able to debugging the code files related to app_cpu1 project,amp_fsbl project by using Standalone OS in  xilinx SDK,
when i am trying to debugging Softuart and rwmem projeccts created using Linux OS on xilinx SDK,

i am facing error as

.gdbinit: No such file or directory.
kill
The program is not being run.

can you please provide some solution for this problem.

Here my main theme is to debug the sample program which is created by using the Linux OS in xilinx SDK.

can u please provide some help for this debugging using Linux OS.

Personally, I don't use debuggers at all, but the common basic tool used on Linux is gdb. It's not very convenient to use, because it's a command-line tool. But it has several graphical front ends (ddd is an ancient one, and I suppose there are newer tools).

Anyhow, it seems like there's no ready-to-run graphical front-end for gdb packaged for Ubuntu 12.04 on ARM.

To make things even worse, there is no gdb server either, so one can't run a remote debugger front end.

I don't know how much this is helpful, but if you have a friendly debugger for ARM, which can attach to a remote target running gdbserver (see http://en.wikipedia.org/wiki/Gdbserver ) then this is the way to install it on Xillinux (by native compilation). But I'm really not sure about how to set up the client.

(the first command gets libtermcap, which is necessary for the compilation)

# apt-get install libncurses5-dev
# wget http://ftp.gnu.org/gnu/gdb/gdb-7.6.tar.gz
# tar -xzf gdb-7.6.tar.gz
# cd gdb-7.6/
# ./configure
# make

Another alternative seems to be to compile a graphical debugger tool, but that isn't all that easy.

I hope this helps somehow.
   Eli

Hi Eli,
Thank's for ur reply and your great suggestion's to me...

please check the pdf document once(in this Linux OS steps availble form page no 18 to 34....) for debugging the codes using Linux OS,
currently i am following these steps for xmd debugging,
http://www.xilinx.com/support/documentation/application_notes/xapp1078-amp-linux-bare-metal.pdf
Here also,able to debugging the codes related to app_cpu1 using with standalone OS,
and SoftUart ,rwmem project created using with Linux OS in xilinx SDK,
But when debugging the Linux OS related project using with XMD,
i am facing the error as
.gdbinit: No such file or directory.
kill
The program is not being run.
and launching debug has encountered a problem.

can u please provide some help for this way of debugging using XMD in xilinx SDK using Linux OS.

As I mentioned earlier, I don't use debuggers at all myself (or more precisely, "printf" is my debugger). Besides, debuggers that are integrated with an IDE may not cooperate when you try to debug something that wasn't compiled with the integrated compiler. I don't know how the SDK (which is derived from Eclipse) behaves on this matter.

And compiling user space application is best done natively, mostly because they depend on libraries.

Ideally, you would be able to connect the SDK's debugger to the gdbserver running directly on the board. The docs say that XDB behaves like a GDB server, so this could work. You may want to give this a go.

Anyhow, I suggest opening a new thread on this forum about running debuggers. Others may answer better than myself, but they probably haven't seen your second question because of the subject of the entire thread.

Ok,sure....
I will try  to open the new thread on this forum for debugging.