'memcpy' example: program does not end

[psrawke]

Hey Jamey, I was exploring different platforms where we can share memory between an FPGA and a processor, and I think Connectal would be very useful tool for it.

I tried to run your 'memcpy' example, in which a source memory is initialized in software and hardware copies it to destination location. But it looks like program does not finish after the memory allocation. It would be very helpful if you suggest any necessary changes.

Thanks!

Regards, Prasanna

[jameyhicks]

Hi Prasanna,

Sorry for the delay in responding. This weekend was a U.S. holiday and I was out in the woods.

I would like to help you get the example working. Do you get any error messages before it stops? Please attach a transcript of the program as it runs. Which board are you building for? Which version of Linux are you running? Did you install connectal from the ubuntu packages?

Best regards, Jamey

On Sat, May 28, 2016 at 1:56 PM Prasanna Rawke notifications@github.com wrote:

Hey Jamey, I was exploring different platforms where we can share memory between an FPGA and a processor, and I think Connectal would be very useful tool for it.

I tried to run your 'memcpy' example, in which a source memory is initialized in software and hardware copies it to destination location. But it looks like program does not finish after the memory allocation. It would be very helpful if you suggest any necessary changes.

Thanks!

Regards, Prasanna

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cambridgehackers/connectal/issues/119, or mute the thread https://github.com/notifications/unsubscribe/ACU3s3w01aBX7EuotcR5apH1pqnoNKLfks5qGIG5gaJpZM4IpIDU .

[psrawke]

Hello Jamey,

I am able to build the memcpy example properly (there are no error messages, but there are signature mismatch warnings). But while running the application, it never stops after initial memory allocation.

Same is the case for other examples like memread, memwrite which use memReadEnginge / memWriteEngine for shared memory. I have attached transcript of the memcpy program and what happens after forcibly quitting the application (it might be helpful for traceback). Simple example works properly but leds doesn't.

I am working on Zedboard and Connectal 16.05.2 on my ubuntu 14.04 machine. I have installed Connectal from ubuntu packages itself.

Thanks!

[jameyhicks]

Hi Prasanna,

Which version of zynq-boot did you install on your zedboard? I suspect that the kernel modules are out of sync with connectal.

Current zynq-boot is Android based, but we just got Ubuntu 16.04 working on the zedboard. I need to write installation instructions and update the connectal package before you would be able to use it.

On Wed, Jun 1, 2016 at 4:55 AM Prasanna Rawke notifications@github.com wrote:

Hello Jamey,

I am able to build the memcpy example properly (there are no error messages, but there are signature mismatch warnings). But while running the application, it never stops after initial memory allocation.

Same is the case for other examples like memread, memwrite which use memReadEnginge / memWriteEngine for shared memory. I have attached transcript https://github.com/cambridgehackers/connectal/files/292854/memcpy_log.txt of the memcpy program and what happens after forcibly quitting the application (it might be helpful for traceback). Simple example works properly but leds doesn't.

I am working on Zedboard and Connectal 16.05.2 on my ubuntu 14.04 machine. I have installed Connectal from ubuntu packages itself.

Thanks!

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/cambridgehackers/connectal/issues/119#issuecomment-222933004, or mute the thread https://github.com/notifications/unsubscribe/ACU3sysGVXGQ3_V3SJO932jFS6qG8pSeks5qHUkVgaJpZM4IpIDU .

[psrawke]

Hi Jamey,

I had installed the pre-built image of zync-boot v15.08.1 provided here. I suppose that it is Android based.

If the kernel modules aren't with sync, would creating the boot.bin and compiling the linux kernel resolve the problem ?

Thanks.

[jameyhicks]

Can you run echo or simple example?

The kernel drivers (zynqportal.ko and portalmem.ko) for connectal are in /mnt/sdcard

What kernel version is reported by: adb shell uname -a

You should be able just to update the drivers.

On Wed, Jun 1, 2016 at 9:04 AM Prasanna Rawke notifications@github.com wrote:

Hi Jamey,

I had installed the pre-built image of zync-boot v15.08.1 provided here https://github.com/cambridgehackers/zynq-boot-filesystems/blob/v15.08.1/bootbin-zedboard-00e00c009603.zip. I suppose that it is Android based.

If the kernel modules aren't with sync, would creating the boot.bin and compiling the linux kernel resolve the problem ?

Thanks.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/cambridgehackers/connectal/issues/119#issuecomment-222985727, or mute the thread https://github.com/notifications/unsubscribe/ACU3sxJA8MvRaquwvH2s8QKb_FMO3AKUks5qHYNogaJpZM4IpIDU .

[psrawke]

I am able to run simple example. Linux kernel version is: 3.9.0-00064-g4828241.

I will try updating the driver and then running other examples. Will report you the status once done.

Thanks

[jameyhicks]

Hi Prasanna, Either the "old" or "new" branches work with Android for zynq-boot v16.05.1 or older.

If you change branches, you will need to make a new boot.bin (which contains a zImage) as well as zynqdrivers.

Starting in zynq-boot v16.05.2 the Makefile uses the kernel branch name. Branch connectal-xilinx-v2016.1 only works with ubuntu at the moment because the dts specifies root=/dev/mmcblock0p1 instead of root=/dev/ram

On Wed, Jun 1, 2016 at 9:58 AM Prasanna Rawke notifications@github.com wrote:

Reopened #119 https://github.com/cambridgehackers/connectal/issues/119.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/cambridgehackers/connectal/issues/119#event-678449943, or mute the thread https://github.com/notifications/unsubscribe/ACU3s-UmMyencKGZDxw8Qzvhd6_WAJSdks5qHY_vgaJpZM4IpIDU .

[psrawke]

Hi Jamey,

I tried all the procedure to generate boot files. But there are some errors due to which i am not able to proceed further! Can you please provide me with zynq boot files which you are working for connectal, so that I can speed up my development work. I am stuck at this point and need your help. Thanks a lot!

[jameyhicks]

Prasanna,

I would be able to help more if you told me what the errors were that you saw. It's helpful in such reports if you include the versions of zynq-boot, connectal, etc. that you used. Please attach a transcript. That way I can try to make the scripts and instructions more robust.

I'll make a new release of zynq boot binaries now.

I know the timezone is a problem, but we could chat on freenode IRC

connectal or via Google Hangout if you're online.

On Fri, Jun 3, 2016 at 6:54 AM Prasanna Rawke notifications@github.com wrote:

Hi Jamey,

I tried all the procedure to generate boot files. But there are some errors due to which i am not able to proceed further! Can you please provide me with zynq boot files which you are working for connectal, so that I can speed up my development work. I am stuck at this point and need your help. Thanks a lot!

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/cambridgehackers/connectal/issues/119#issuecomment-223550038, or mute the thread https://github.com/notifications/unsubscribe/ACU3s5n3L1dO1_IcJeJFS_Df_KPCqM9Mks5qIAf9gaJpZM4IpIDU .

[jameyhicks]

Please try this release of zynq-boot: https://github.com/cambridgehackers/zynq-boot/releases/tag/v16.05.3

On Fri, Jun 3, 2016 at 7:56 AM Jamey Hicks jamey.hicks@gmail.com wrote:

Prasanna,

I would be able to help more if you told me what the errors were that you saw. It's helpful in such reports if you include the versions of zynq-boot, connectal, etc. that you used. Please attach a transcript. That way I can try to make the scripts and instructions more robust.

I'll make a new release of zynq boot binaries now.

I know the timezone is a problem, but we could chat on freenode IRC

connectal or via Google Hangout if you're online.

On Fri, Jun 3, 2016 at 6:54 AM Prasanna Rawke notifications@github.com wrote:

Hi Jamey,

I tried all the procedure to generate boot files. But there are some errors due to which i am not able to proceed further! Can you please provide me with zynq boot files which you are working for connectal, so that I can speed up my development work. I am stuck at this point and need your help. Thanks a lot!

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/cambridgehackers/connectal/issues/119#issuecomment-223550038, or mute the thread https://github.com/notifications/unsubscribe/ACU3s5n3L1dO1_IcJeJFS_Df_KPCqM9Mks5qIAf9gaJpZM4IpIDU .

[psrawke]

Hi Jamey,

Thank you for uploading new image. Most of the examples are working with the newer release of the zynq-boot.

In case of memcpy, the program finishes with status 0 (successfully) unlike previously with older images. But when I print the src and dst array in software's done function, some of the locations are overwritten (or initialized as 0). If I initialize, the memory after 'portalCacheFlush' src and dst are initialized properly. Can that be happening because of 'portalCacheFlush'?

Default order for memory initialization in memcpy example: In this case, some parts of the src and dst array are not initialzed properly.

  srcAlloc = portalAlloc(alloc_sz, 0);
  dstAlloc = portalAlloc(alloc_sz, 0);

  srcBuffer = (unsigned int *)portalMmap(srcAlloc, alloc_sz);
  dstBuffer = (unsigned int *)portalMmap(dstAlloc, alloc_sz);

  for (int i = 0; i < numWords; i++){
     srcBuffer[i] = i;
     dstBuffer[i] = 0x5a5abeef;
  }
  portalCacheFlush(srcAlloc, srcBuffer, alloc_sz, 1);
  portalCacheFlush(dstAlloc, dstBuffer, alloc_sz, 1);

  unsigned int ref_srcAlloc = dma->reference(srcAlloc);
  unsigned int ref_dstAlloc = dma->reference(dstAlloc);

Following modifications in the order solves the issue:

  srcAlloc = portalAlloc(alloc_sz, 0);
  dstAlloc = portalAlloc(alloc_sz, 0);

  srcBuffer = (unsigned int *)portalMmap(srcAlloc, alloc_sz);
  dstBuffer = (unsigned int *)portalMmap(dstAlloc, alloc_sz);

  portalCacheFlush(srcAlloc, srcBuffer, alloc_sz, 1);
  portalCacheFlush(dstAlloc, dstBuffer, alloc_sz, 1);

  unsigned int ref_srcAlloc = dma->reference(srcAlloc);
  unsigned int ref_dstAlloc = dma->reference(dstAlloc);

  for (int i = 0; i < numWords; i++){
     srcBuffer[i] = i;
     dstBuffer[i] = 0x5a5abeef;
  }

[jameyhicks]

Hi Prasanna,

Please open a new issue for the new problem and let's close #119 since the new files seem to have solved this problem.

On Mon, Jun 6, 2016 at 9:02 AM Prasanna Rawke notifications@github.com wrote:

Hi Jamey,

Thank you for uploading new image. Most of the examples are working with the newer release of the zynq-boot.

In case of memcpy, the program finishes with status 0 (successfully) unlike previously with older images. But when I print the src and dst array in software's done function, some of the locations are overwritten (or initialized as 0). If I initialize, the memory after 'portalCacheFlush' src and dst are initialized properly. Can that be happening because of ' portalCacheFlush'?

Default order for memory initialization in memcpy example: In this case, some parts of the src and dst array are not initialzed properly.

srcAlloc = portalAlloc(alloc_sz, 0); dstAlloc = portalAlloc(alloc_sz, 0);

srcBuffer = (unsigned int )portalMmap(srcAlloc, alloc_sz); dstBuffer = (unsigned int )portalMmap(dstAlloc, alloc_sz);

for (int i = 0; i < numWords; i++){ srcBuffer[i] = i; dstBuffer[i] = 0x5a5abeef; } portalCacheFlush(srcAlloc, srcBuffer, alloc_sz, 1); portalCacheFlush(dstAlloc, dstBuffer, alloc_sz, 1);

unsigned int ref_srcAlloc = dma->reference(srcAlloc); unsigned int ref_dstAlloc = dma->reference(dstAlloc);

Following modifications in the order solves the issue:

srcAlloc = portalAlloc(alloc_sz, 0); dstAlloc = portalAlloc(alloc_sz, 0);

srcBuffer = (unsigned int )portalMmap(srcAlloc, alloc_sz); dstBuffer = (unsigned int )portalMmap(dstAlloc, alloc_sz);

portalCacheFlush(srcAlloc, srcBuffer, alloc_sz, 1); portalCacheFlush(dstAlloc, dstBuffer, alloc_sz, 1);

unsigned int ref_srcAlloc = dma->reference(srcAlloc); unsigned int ref_dstAlloc = dma->reference(dstAlloc);

for (int i = 0; i < numWords; i++){ srcBuffer[i] = i; dstBuffer[i] = 0x5a5abeef; }

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/cambridgehackers/connectal/issues/119#issuecomment-223951871, or mute the thread https://github.com/notifications/unsubscribe/ACU3s2eG6ciEdn56-e0ehBDPNAzhBXKWks5qJBo7gaJpZM4IpIDU .