Alejandro Wolf

  • Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    Alejandro Wolf got a reaction from JColvin in Using Open CV with Zybo board   
    That actually was just a demo I did for some students. The end result can be appreciated here. In the end I used a HDMI input instead of the camera because of the faster frame rate. I tested it using a video from  my personal computer or a GoPro camera. 
    I have a tutorial for running OpenCV on the Zybo board from scratch, but it is in spanish and does not cover the hdmi capture.
    I'm not quite confortable sharing my proyect because its messy and I kind of hacked the AXI HP ports to capture the HDMI input and output the video with no Linux graphical interface. I'm not using DMA at all and yet I'm transfering full video frames from the FPGA to the processor at enought speed to capture [email protected] video.
    I can clean up the proyect for the HDMI capture/VGA output and translate the tutorial, but it would take me a while.
    best regards
  2. Like
    Alejandro Wolf got a reaction from JColvin in Real time Linux on Zybo   
    I have a tutorial to build the kernel from scratch, but It's in spanish. With the help of google translate and some carefull reading, I believe that you can make it work ignoring all the OpenCV stuff and using your linux distribution instead of arch:
    If there are enough interested people, I could translate it.
    Reading your post I realized that maybe it's hangs up because is triying to boot Ramdisk. If you compiled u-boot by youtself edit the zynq_zybo.h in /include/configs/.

    Change this:
    "sdboot=if mmcinfo; then " \ "run uenvboot; " \ "echo Copying Linux from SD to RAM fs... && " \ "fatload mmc 0 0x3000000 ${kernel_image} && " \ "fatload mmc 0 0x2A00000 ${devicetree_image} && " \ "fatload mmc 0 0x2000000 ${ramdisk_image} && " \ "bootm 0x3000000 0x2000000 0x2A00000; " \ "fi\0" \ to this:
    "sdboot=if mmcinfo; then " \ "run uenvboot; " \ "echo Copying Linux from SD to RAM fs... && " \ "fatload mmc 0 0x3000000 ${kernel_image} && " \ "fatload mmc 0 0x2A00000 ${devicetree_image} && " \ "bootm 0x3000000 - 0x2A00000; " \ "fi\0" \ then compile u-boot and try again.
    Best regards
  3. Like
    Alejandro Wolf reacted to jamey.hicks in Zybo: Linaro/Archlinux and physicall memory buffers   
    Hi Alejandro,
    Use DMA: I kind of know how to use DMA on baremetal on the software side, but I have no idea how to make a custom IP that comunicates with the DMA modules. I have a decent understanding how master and slave AXI full interfaces works tough. By "Use DMA", I assume you mean the central DMA controller, since you already have AXI masters that can read and write system DRAM via the HP ports. I do not think this approach will solve any problems for you, because you still would need a way to allocate memory to use as buffers.
    Write a custom driver that works the way my IP needs. We wrote a couple of fairly generic device drivers. One simplifying assumption we made was to add address translation to our hardware. It's pipelined and it is not very big, but it's implemented in Bluespec System Verilog so you might not be able to use it. However, the design is simple, so I do not think it would take you long to implement something similar.
    The MMU is simplified because portalmem allocates the largest physically contiguous regions it can, starting at 2^8 pages, then 2^4 pages, then single pages.
    The first driver we have is portalmem, which enables user-space programs to allocate dma-bufs. Each memory region allocated has a corresponding file descriptor, so the regions can be passed between processes atomically and memory-mapped. Also, the file descriptor can be passed to an FPGA device driver, which can get the virtual->phys mapping for the region as a scatter-gather list.
    The second driver is zynqportal, which passes the scatter-gather address translation info to the hardware. It also enables user-space to mmap the hardware registers and wait for interrupts via the poll() system call. This driver depends on just a few registers being implemented in the logic plus a command and response FIFO to interact with the MMU.
    In case this is helpful, here are pointers to the drivers and the MMU:
    Hack with things like dma-mapping, contiguous memory allocations, memory maps, etc. I looked for a way to do DMA from user-space but did not find it. Did I miss something?
    Make a "don't touch" region of ram for Linux, so the HW can work with it. I do not know how many memory regions you need to allocate, but the simplest way to get contiguous physical memory from the kernel is to reserve it off the top, passing "mem=xxx" in the kernel cmdline, where "xxx" is less than the amount of memory on the board.
  4. Like
    Alejandro Wolf got a reaction from Alex in Using Open CV with Zybo board   
    Yes it can. Currently I have a Zybo board running arch linux and running OpenCV. It's not that fast to process video at a good framerate using only the CPU, you need to use some kind of hardware aceleration for processing video.