Forum Managers
  • Content count

  • Joined

  • Last visited

  • Days Won


sbobrowicz last won the day on May 28

sbobrowicz had the most liked content!


About sbobrowicz

  • Rank
    Prolific Poster

Profile Information

  • Gender
  • Location
    Pullman, WA

Recent Profile Visitors

2,875 profile views
  1. No video support in u-boot. I'm pretty sure that is true across the board, but it is definitely true for our video output solution (because we didn't do the work). That said, usually splash screens are handled once Linux is booted. Since our HDMI output looks like a standard DRM device, you should be able to just google how to add a custom splash screen to Linux and that should work. I think there is even a way to do this at the kernel level, but I may be wrong.
  2. The number of data bits and the clock frequency is set at the block diagram by double clicking the Quad SPI IP core. IMO, this is a major downside of the AXI QUAD SPI IP core, because it means you can not change the clock speed from software without rebuilding the bitstream. Unfortunately we don't currently have an alternative. So you will need to open your block diagram in Vivado and change the clock divider values for the Quad SPI core, then rebuild and import into petalinux. Note the SCLK frequency will be equal to the frequency of the ext_spi_clock signal divided by the ratio value. 10 MHz for the SCLK frequency should be good. The number of data bits should be set to 8.
  3. Sorry all, didn't realize Jon was testing with the same bitfile already. You don't need to retest with that file again. Next steps are to investigate the power source as I mentioned above and the USB thumb drive models.
  4. Jon, can you provide Nico with a bitfile that works on the nexys 3 you are using? I just want to be very certain this is not caused by some bitgen settings (e.g. compression). Nico, this could be a compatibility issue with the thumbdrives you are using. Can you please provide information on the drives you are using? Links to them on Amazon would be useful. Another possibility is that this is caused by excess power draw. How are you powering the Nexys 3? If you are using a thumbdrive, I recommend using an external 5V wallwort power supply, not USB power. If you don't have a 5 V power supply, you could try powering from a USB wall brick, like the ones that commonly ship with phones. Those are capable of providing more current than your standard USB connector on your computer.
  5. The microcontroller firmware that reads the bitfile is pretty simple... Maybe try renaming the filename so that it only contains one "."
  6. Yea, that old driver just bit-bangs out SPI on the GPIO controller, that's one of the reasons we don't want to invest the time to keep using it. Also, we are trying to move away from any sort of custom kernel drivers in general, unless it really makes sense (like in the case of audio and video). We have been working on some examples this summer that use the generic UIO driver to communicate with Pmods from user space. These demos will be distributed as a petalinux 2017.1 (or newer) project. We are shooting for end of summer, but I can't guarantee that timeline. My suggested approach for now for using the PmodOLED IP or most other Pmod IP's will be to just use the UIO driver with them, and then port over the bare-metal libraries/demos included with the IP's to linux user space. This can be done in most cases by just replacing the register accesses with accesses that use the mmap-ed UIO device instead. You can post again if you need some help using UIO, but we have a few UIO related posts already that should help you get started. I recommend this guide to learn about the Generic UIO driver in general: . It suggests writing your own driver, but you can get around this by using the uio_pdrv_genirq driver and modifying the bootargs to add generic-uio to the compatibility list. For some select pmods, it makes more sense to load existing drivers that are targeted for the device the pmod is designed around. One example of this is the PmodRTCC, a real-time clock and calendar, that will automatically set the system time at boot if you use the correct device tree node.
  7. @Ciprian @JCer Actually, we have been able to tie our video output pipeline into the DRM framework for a while now. We had to write a very simple encoder driver to make this work (see drivers/gpu/drm/xilinx/digilent-encoder.c at linux-digilent on our github), but our petalinux example projects include this and implement the proper device tree. Our officially released petalinux project and a guide to use it are linked from the Arty Z7 resource center on our wiki. As for HDMI input, I just got this working last week using a mmap hack as you described above. If you want to give it a try, you can use a pre-release version of the 2017.1 Arty-Z7 petalinux project here: . It doesn't include the HDMI input capability yet, I will push it up tomorrow, and post a demo userspace program here that DMAs the HDMI input directly onto the HDMI output.
  8. Hey Mike, That pmodoled driver is from an old demo, and we did not intend to continue supporting it. It is not intended to work with the PmodOLED IP core in the vivado project. Here's what you will need to do to get it to work in a newer project: 1) In Vivado IPI, open the Zynq Processing system IP, enable GPIO over EMIO with a width of 7. 2) Make the new EMIO GPIO interface on the Zynq IP block external. 3) Open your XDC and add the following constraints (replace gpio with name of external emio gpio bus as found in your block diagram wrapper): set_property PACKAGE_PIN G17 [get_ports {gpio[0]}]; # "OTG-RESETN" set_property PACKAGE_PIN U11 [get_ports {gpio[1]}]; # "OLED-VBAT" set_property PACKAGE_PIN U12 [get_ports {gpio[2]}]; # "OLED-VDD" set_property PACKAGE_PIN U9 [get_ports {gpio[3]}]; # "OLED-RES" set_property PACKAGE_PIN U10 [get_ports {gpio[4]}]; # "OLED-DC" set_property PACKAGE_PIN AB12 [get_ports {gpio[5]}]; # "OLED-SCLK" set_property PACKAGE_PIN AA12 [get_ports {gpio[6]}]; # "OLED-SDIN" You should then be able to build the project and import it into your petalinux project. Be sure to include the zed_oled device tree node as you have written it in a previous post.
  9. Are you sure you didn't skip over it? It should be there. Maybe try searching (using '/' key) for UIO?
  10. If you have a single IP core with multiple AXI interfaces, you will need to make sure the "reg" line in your IP's device tree node declares both spaces: reg = <addr1 size1 addr2 size2> In newer versions of petalinux the devicetree generator automatically does this for you, so running petalinux-config --get-hw-description should automatically update pl.dtsi to include the proper reg declaration. I'm not sure if the version of the DTG in petalinux 2015.4 does this, so you might have to fix the reg line your self. With the proper reg line, you should see the driver get loaded for your IP core in /sys/class/uio/uio*. The multiple address spaces will show up as different maps in /sys/class/uio/uio*/maps/map*
  11. Step 8 here: That project is broken up into several different instructables, all of which are listed here:
  12. I think @D@n is correct, that is a program meant to run on microblaze (or maybe picoblaze). I would bet that the .mcs wraps up the bit and fw files so that they are programmed into the correct Flash addresses. This is a common solution for packaging microblaze projects that utilize a bootloader because the processor program cannot fit inside the FPGA's Block RAM.
  13. All of our examples for the ZYBO are found here: . I'd recommend running through the getting started guides there to get a first touch with the tools. To answer your question, XPAR_SCUGIC_SINGLE_DEVICE_ID and XPAR_XUARTPS_1_INTR are found in xparameters_ps.h, and XPAR_XUARTPS_0_DEVICE_ID should be found in xparameters.h . I also think you should be using XPAR_XUARTPS_1_DEVICE_ID instead. Note that the first block of the #ifdef is not active, so those 4 do not need to exist (the #ifdef is detecting whether or not your code is being built for a Zynq system or a microblaze system).
  14. You are correct, Pmod WIFI is not suitable for Linux. Microchip does not provide linux drivers for the Wifi solution we used on it. I'd recommend using either a USB Wifi dongle, or a module that can be plugged into a pmod port and uses the SDIO interface (TI and Cypress make them I believe). This board from avnet should do the trick: . I think you will have to buy the WL1835MODGBMOCR board separately though, which will put the total price in the $60 range :(.
  15. The blinking DONE LED is concerning... That means the FPGA is being programmed, then immediately reset. This can happen when powering from USB due to the ZYBO trying to draw too much current. How are you powering the ZYBO? What do you see at the UART terminal when that occurs? Please also provide the output of dmesg when you use your workaround.