Run Ubuntu Linux for ARM on Zedboard

I got it up and working, but their flow on generating the bitstream is not the way Xilinx wants people to do Zynq development. I'm going to spend the weekend trying to get their steps condensed into PlanAhead.

Also, they don't have the LED/Button/OLED drivers, so I'm also going to look into that.

Hi,

Several issues were left out in the preview release. Given the computer monitor, keyboard and mouse interfaces, supporting the GPIO buttons, LEDs and OLED screen was not in priority. But these will be supported quite soon.

As for the build flow, it's in line with other Xillybus evaluation kits (e.g. for Xillybus streams over PCIe) but maybe it is time to move on to Planahead.

Anyhow, please note that getting the package built in one mouse click is not the only criterion: The idea is to allow straightforward development of custom logic based upon the kit, further down the road. Building the processor project separately, and once and for all, keeps the actual working environment slim and easier to understand. Or so I hope.

Thanks for your input.
   Eli

Hi Eli,

I understand it's a work in progress, and by all means, don't change a thing in your development if it's working (if it ain't broke, don't fix it).

I have already converted it to PlanAhead, with no issues to the source files or constraint files. I did run into an issue with XPS throwing an error about a ref clock being 50MHz when it needed to be 62.5MHz, but that was an easy fix in the Clock Generator. I haven't gotten to re-doing the boot.bin (to not overwrite what I have done in the current OS, I need to get a new SDCard), but I expect it to work no problem (it uses the same flow that you're doing).

Can I suggest that you look into adjusting your code to work with the HDMI output? I am not sure how difficult it would be, but it would be very beneficial.

Overall, best setup I've had to deal with in a LONG time. Keep up the good work, and I look forward to future releases.

Hi,

There are several formats for sending pixel data to the HDMI interface, but my impression is that the way the video chip is wired (only inputs D8-D23 connected), it allows only YCbCr input. And I take it that 4:4:4 input is not possible with this wiring. That means it's going to look lousy for use as a PC monitor, with pixel pairs forced to share the color, and most likely some pixel smearing by the chip to cover it up. It's good for HD movies, not for GUI.

Besides, the one time I tried to use my computer's graphics card's HDMI output with my multi-input monitor, the display looked pretty blurry. I didn't investigate this further, but it's quite plausible that a monitor expects a television-oriented signal when it comes as HDMI, so the default way to display the picture is with an anti-aliasing filter. Somewhat blurry, in other words.

Using the HDMI chip to produce a proper VESA signal in DVI format would be a nice path to take, but it looks like the chip's wiring prevents that. I will be glad to stand corrected on this.

So it seems like the bottom line is that the HDMI chip is useful only for rendering video. I'm really not sure how useful it will be to represent the chip as a framebuffer in Linux, though. I have serious doubts whether the processors are powerful enough to decode an HD clip without some serious co-processing. Given the rather slow I/O limitation presented by the system in general, my best guess is that whatever solution is made to play a clip, it will have to include a fast rendering system in logic, working directly with the video chip. So a framebuffer interface will just come in the way.

So this is my reasoning behind not implementing a framebuffer interface for the HDMI chip. It's an open invitation to prove me wrong, in which case I may very well change that decision.

Cheers,
   Eli

I got Ubuntu with HDMI video working by following instructions on:

http://wiki.analog.com/resources/tools-software/linux-drivers/platforms/zynq

I got there from the Community Project "Analog Devices ADV7511 HDMI Transmitter Reference Design" but cannot get audio to work. Anyway, maybe Xilinux can get HDMI interface, since hardware should not be the problem?

I got Ubuntu with HDMI video working by following instructions on:

http://wiki.analog.com/resources/tools-software/linux-drivers/platforms/zynq

I got there from the Community Project "Analog Devices ADV7511 HDMI Transmitter Reference Design" but cannot get audio to work. Anyway, maybe Xilinux can get HDMI interface, since hardware should not be the problem?

I've tried to follow this tutorial but I don't  know how to build a u-boot image for this design. Can you help me?

I get the following when using an u-boot image from another tutorial:

...
reading zImage

2729960 bytes read
reading devicetree.dtb

6779 bytes read
reading ramdisk8M.image.gz

** Unable to read "ramdisk8M.image.gz" from mmc 0:1 *

Thank you

Your question is buried in the middle of this long thread, and is practically invisible, and it's not clear to me if it's related to the topic (which is Xillinux).

Also, please offer some details about what tutorial you attempted to follow, what you did, what happened vs. what you expected to happen.

I'm not sure it's relevant or helpful, but I'll just mention that there is no ramdisk image in Xillinux. The U-boot still expects one, fails to find it and therefore kicks off the kernel without it. This is the normal bootup behavior of Xillinux (contrary to most other distributions, which need a ramdisk image).

Regards,
   Eli