Run Ubuntu Linux for ARM on Zedboard

Somewhat earlier than expected, the preview release is available for immediate download:

http://xillybus.com/xillinux/

Documentation:
http://xillybus.com/downloads/doc/xillybus_getting_started_zynq.pdf

Have fun,
   Eli

I have all the bits and will get playing right away!

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.

Up and running.  Thanks!

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 it up and running but mouse and keyboard are not working (have JP2 shorted but no power on OTG, tried also short JP3 with the same result). There is no message in dmesg nor in syslog.

The original SD image had USB keyboard/mouse working, got light on the mouse and shell showed that plugged in device was properly recognized.

To start with, I'd like to point out that the host has no control on the supply voltage of the USB port, so if you had power with the original SD image, it's there in any occasion. The LED being off may indicate that the device was detected by the host, but rejected for some reason (so the host commanded the LED off).

To figure this out, I would like you to repeat this check with the original Linux image and then with Xillinux. Could you please isolate the sections it the kernel message log (/var/log/syslog or /var/log/messages) that are related to USB, and post them here? Searching for the string "usb" in the log is fine.

Please note that I'm interested not only in what happened when you plugged in devices, but also the log messages related to the detection of the USB interface of the processor. Everything related to USB in the logs is important.

What is really weird, is that you got absolutely no message when you plugged in your device. Log messages are always produced when any USB device is plugged in, even if they end up to be unknown.

I would also suggest trying random USB device that you have lying around, even if they're not expected to do any good. Just to see what happens.

Thanks in advance,
   Eli

Here are log messages from Xillinux after plugging 4 different usb devices (usb key, keyboard, mouse, different mouse):

root@localhost:~# cat /var/log/dmesg | grep usb
[    0.390000] usbcore: registered new interface driver usbfs
[    0.390000] usbcore: registered new interface driver hub
[    0.390000] usbcore: registered new device driver usb
[    1.320000] usb_hcd_xusbps_probe: No OTG assigned!
[    1.320000] usb_hcd_xusbps_probe: OTG now assigned!
[    1.330000] xusbps-ehci xusbps-ehci.0: Xilinx PS USB EHCI Host Controller
[    1.330000] xusbps-ehci xusbps-ehci.0: new USB bus registered, assigned bus number 1
[    1.370000] xusbps-ehci xusbps-ehci.0: irq 53, io mem 0x00000000
[    1.390000] xusbps-ehci xusbps-ehci.0: USB 2.0 started, EHCI 1.00
[    1.410000] usbcore: registered new interface driver usb-storage
[    1.450000] usbcore: registered new interface driver uvcvideo
[    1.500000] usbcore: registered new interface driver usbhid
[    1.500000] usbhid: USB HID core driver
root@localhost:~# cat /var/log/syslog | grep usb
Jan  1 00:00:06 localhost kernel: [    0.390000] usbcore: registered new interface driver usbfs
Jan  1 00:00:06 localhost kernel: [    0.390000] usbcore: registered new interface driver hub
Jan  1 00:00:06 localhost kernel: [    0.390000] usbcore: registered new device driver usb
Jan  1 00:00:06 localhost kernel: [    1.320000] usb_hcd_xusbps_probe: No OTG assigned!
Jan  1 00:00:06 localhost kernel: [    1.320000] usb_hcd_xusbps_probe: OTG now assigned!
Jan  1 00:00:06 localhost kernel: [    1.330000] xusbps-ehci xusbps-ehci.0: Xilinx PS USB EHCI Host Controller
Jan  1 00:00:06 localhost kernel: [    1.330000] xusbps-ehci xusbps-ehci.0: new USB bus registered, assigned bus number 1
Jan  1 00:00:06 localhost kernel: [    1.370000] xusbps-ehci xusbps-ehci.0: irq 53, io mem 0x00000000
Jan  1 00:00:06 localhost kernel: [    1.390000] xusbps-ehci xusbps-ehci.0: USB 2.0 started, EHCI 1.00
Jan  1 00:00:06 localhost kernel: [    1.410000] usbcore: registered new interface driver usb-storage
Jan  1 00:00:06 localhost kernel: [    1.450000] usbcore: registered new interface driver uvcvideo
Jan  1 00:00:06 localhost kernel: [    1.490000] usbcore: registered new interface driver usbhid
Jan  1 00:00:06 localhost kernel: [    1.500000] usbhid: USB HID core driver
Jan  1 00:00:09 localhost kernel: [    0.390000] usbcore: registered new interface driver usbfs
Jan  1 00:00:09 localhost kernel: [    0.390000] usbcore: registered new interface driver hub
Jan  1 00:00:09 localhost kernel: [    0.390000] usbcore: registered new device driver usb
Jan  1 00:00:09 localhost kernel: [    1.320000] usb_hcd_xusbps_probe: No OTG assigned!
Jan  1 00:00:09 localhost kernel: [    1.320000] usb_hcd_xusbps_probe: OTG now assigned!
Jan  1 00:00:09 localhost kernel: [    1.330000] xusbps-ehci xusbps-ehci.0: Xilinx PS USB EHCI Host Controller
Jan  1 00:00:09 localhost kernel: [    1.330000] xusbps-ehci xusbps-ehci.0: new USB bus registered, assigned bus number 1
Jan  1 00:00:09 localhost kernel: [    1.370000] xusbps-ehci xusbps-ehci.0: irq 53, io mem 0x00000000
Jan  1 00:00:09 localhost kernel: [    1.390000] xusbps-ehci xusbps-ehci.0: USB 2.0 started, EHCI 1.00
Jan  1 00:00:09 localhost kernel: [    1.410000] usbcore: registered new interface driver usb-storage
Jan  1 00:00:09 localhost kernel: [    1.450000] usbcore: registered new interface driver uvcvideo
Jan  1 00:00:09 localhost kernel: [    1.500000] usbcore: registered new interface driver usbhid
Jan  1 00:00:09 localhost kernel: [    1.500000] usbhid: USB HID core driver
root@localhost:~#

Here are log messages from original Linux after plugging 4 different usb devices (usb key, keyboard, mouse, different mouse):

zynq> ls /var/log/
zynq> dmesg | grep usb
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
usb_hcd_xusbps_probe: No OTG assigned!
usb_hcd_xusbps_probe: OTG now assigned!
xusbps-ehci xusbps-ehci.0: Xilinx PS USB EHCI Host Controller
xusbps-ehci xusbps-ehci.0: new USB bus registered, assigned bus number 1
xusbps-ehci xusbps-ehci.0: irq 53, io mem 0x00000000
xusbps-ehci xusbps-ehci.0: USB 2.0 started, EHCI 1.00
usbcore: registered new interface driver usb-storage
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usb 1-1: new high speed USB device number 2 using xusbps-ehci
scsi0 : usb-storage 1-1:1.0
usb 1-1: USB disconnect, device number 2
usb 1-1: new full speed USB device number 3 using xusbps-ehci
usb 1-1.1: new low speed USB device number 4 using xusbps-ehci
input: Mitsumi Electric Apple USB Keyboard as /devices/amba.0/e0002000.usb/xusbps-ehci.0/usb1/1-1/1-1.1/1-1.1:1.0/input/input0
evbug: Connected device: input0 (Mitsumi Electric Apple USB Keyboard at usb-xusbps-ehci.0-1.1/input0)
generic-usb 0003:05AC:0201.0001: input: USB HID v1.00 Keyboard [Mitsumi Electric Apple USB Keyboard] on usb-xusbps-ehci.0-1.1/input0
usb 1-1: USB disconnect, device number 3
usb 1-1.1: USB disconnect, device number 4
usb 1-1: new low speed USB device number 5 using xusbps-ehci
input: Targus USB Mouse as /devices/amba.0/e0002000.usb/xusbps-ehci.0/usb1/1-1/1-1:1.0/input/input1
evbug: Connected device: input1 (Targus USB Mouse at usb-xusbps-ehci.0-1/input0)
generic-usb 0003:0461:4D03.0002: input: USB HID v1.00 Mouse [Targus USB Mouse] on usb-xusbps-ehci.0-1/input0
usb 1-1: USB disconnect, device number 5
usb 1-1: new low speed USB device number 6 using xusbps-ehci
input: Macally Peripherals  Macally ECOMouse  as /devices/amba.0/e0002000.usb/xusbps-ehci.0/usb1/1-1/1-1:1.0/input/input2
evbug: Connected device: input2 (Macally Peripherals  Macally ECOMouse  at usb-xusbps-ehci.0-1/input0)
generic-usb 0003:2222:3100.0003: input: USB HID v1.00 Mouse [Macally Peripherals  Macally ECOMouse ] on usb-xusbps-ehci.0-1/input0
usb 1-1: USB disconnect, device number 6
zynq>

Hope this helps. Have to say this is a great project and I really enjoy playing with it.
Regards,

Roman