installing gstreamer-1.0 on Olimex A10 Lime

The standard OS of A10-Lime is Debian Wheezy, which doesn’t provide gstreamer-1.0 in its default repositories.

But fortunatly gstreamer-1.0 is part of the Wheezy-Backports.

so you have to add the following line to /etc/apt/sources.lists

deb http://http.debian.net/debian wheezy-backports main

 

and run

$ sudo apt-get update

 

unfortunatly though – there seem to be some issue with the liborc libraries – so I cam up with this workaround – i downloaded the files manually and installed them with dpkg.

$ wget http://ftp.at.debian.org/debian/pool/main/o/orc/liborc-0.4-0_0.4.19-1~bpo70+1_armhf.deb
$ wget http://ftp.at.debian.org/debian/pool/main/o/orc/liborc-0.4-dev_0.4.19-1~bpo70+1_armhf.deb
$ sudo dpkg -i --force-all liborc-0.4-0_0.4.19-1~bpo70+1_armhf.deb
$ sudo dpkg -i --force-all liborc-0.4-dev_0.4.19-1~bpo70+1_armhf.deb

after that i just installed gstreamer1.0-tools and the plugins

$ sudo apt-get install gstreamer1.0-tools gstreamer1.0-plugins-base gstreamer1.0-plugins-good
Advertisements

reconstructing rgb images

after playing around more with the v4l2-driver I could reconstruct an RGB-image. This proves that all signallines from the VideoBrick to the A10 are working:

Red-Channel:

r

Green-Channel:

g

Blue-Channel:

b

I opened all these 3 Images in GIMP (as individual Layers) and converted them to grayscale using the Menu Colors->Components->Recompose. This way I could recreate the orignial image:

rgb-compose

Which is working – unfourtunatly though the RGB-Format used in V4L2 – is one byte R, one byte G, one byte B – but with this driver i get a planar output of Image-R, Image-G, Image-B. I still have to figure out what common color space the the ADV7611 provides that can be used with the Allwinner CSI-Perihperal and V4L2.

The next test was to force the ADV7611 into YUV4:2:2 16Bit output mode – this way i could receive a Grayscale Image (because the Luma-Channel (Y) equals basically the grayscale information):

gray8As you might notice there are still issues with the offset of the image …

As for testing I also switchted to gstreamer-1.0 – making the gst-plugin-cedar (H264 Encoder) currently unavailable because this is a gst-0.10 plugin.

you can capture grayscale Images using the Source from the github: https://github.com/videobrick/vb_software/tree/master/vb_module

$ sudo ./loadmodules

loads the needed modules

$ ./stillcapture

captures the Grayscale image…

some progress in the new year

I assembled two more VideoBrick Prototypes – unfourunatly I mounted the LDO the wrong way around which caused all kinds of wired behaviour including exhibiting the ADV7611 to 2,1 V instead of 1,8 V core voltage – to figure out this issue I had to desoldered one of the ADV7611. Somehow it seemed that the ADV7611 survived this mistake because i could correct the LDOs on both boards and both of them are working now (one with changed ADV7611 the other with the ADV7611 soldered in first place)

DSC00028

and by patching the sun4i_csi1.ko Kernel Module I could get the output to look like this in 720p50:

The patch was to force the CSI1 periheral of the Allwinner A10 into 24-Bit RGB/YUV444 Input mode (see for more details in the User manual of the Allwinner A10 which can be found on linux-sunxi.org)

the file sun4i_csi_reg.c was patched in the following way:


/* configure */
void bsp_csi_configure(struct csi_dev *dev,__csi_conf_t *mode)
{
    u32 t;
    W(dev->regs+CSI_REG_CONF, //mode->input_fmt << 20 | /* [21:20] */
                              4 << 20 | /* 24Bit YUV or RGB input */    
                              mode->output_fmt<< 16 | /* [18:16] */
                              mode->field_sel << 10 | /* [11:10] */
                              mode->seq       << 8  | /* [9:8] */
                              mode->vref      << 2  | /* [2] */
                              mode->href      << 1  | /* [1] */
                              mode->clock     << 0    /* [0] */
      );

  t = R(dev->regs+CSI_REG_CONF);

}

Happy new year to all readers of this blog. btw. 🙂

H264 encoder – gst-plugin-cedar

The support from the linux-sunxi community for the Allwinner Chips is quite impressive – because 720p50 Video is producing a lot of data it is good to have a working encoder solution available, while debugging our V4L2 – Kernel Module.

Adding support for compressing Video to h264 on the Allwinner A10/A20 is as easy as the following steps – which are copy and pasted from n8body’s Blog which relies on the gst-plugin-cedar. We are compiling the plugin directly on the target Hardware.

1. get gst-plugin-cedar Source


$ git clone https://github.com/ebutera/gst-plugin-cedar

2. get tools needed for building


$ sudo apt-get install gstreamer0.10-tools libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev

3. compile the code


$ ./autogen.sh && make

4. place the plugins in the appropriate directory (/usr/lib/arm-linux-gnueabihf/gstreamer-0.10/)

One question that still bothers me is if gst-plugin-cedar is using the full capabilities of Allwinners H.264 Hardware-Encoder or if its only supporting I-Frames – because the Wiki from linux-sunxi.org is showing a Proof of Concept Status for this binary blob free encoder. sure this can be determined very quickly by looking at the statistics of a encoded file.

Happy Holidays btw.

Update:

I just verified that the current gst-plugin-cedar only produces I-Frames. This can be done using ffprobe from the ffmpeg project.


$ ffprobe -show_frames ~/test.mkv

which shows the detail of all frames inside the video. All frames where flaged at keyframes which is synonymous to I-Frames.

first video

The V4L2 driver for the ADV7611 shows some first signes of live 🙂

sure there are some issues but this is a video already captured with gstreamer 😉

As an HDMI-Source I also used a Lime

IMG_20141211_160102

Settings are 480p – the green color most likely is a result of a wrong colorspace – we are inputing RGB888 into the CSI1 of the A10 and this looks like that the data is interpreted as YUV..

further the Image is a bit offset to the bottom right … but it is a stable picture this is telling us that PIXEL_CLOCK, HSYNC and VSYNC are working 🙂

The flickering is because the V4L2 currently reports a Framerate of 100 Hz but the input signal is 60 Hz.

The adv7611 module can be found at the github – Makefile still needs to be written.

the module depends on other modules (videobuf-core, videobuf-dma-contig, sun4i_csi1), load it in the following order

modprobe videobuf-core
modprobe videobuf-dma-contig
insmod adv7611.ko
modprobe sun4i_csi1

In order to use the module, also the script.bin file at the first partition of the LIME A10 – sdcard needs to be adjusted there for sunxi-tools are needed. Find more info here and here. You can also download script.bin from the github.

Hackathon Report Day2

Day two of the Hackathon started with a discovery that the pinout of the cyrstal we ordered was mirrored – that was also the reason why we couldn’t measure the clock on the crystal – to resolve this issue we flipping the crystal and soldered it in dead bug style

OLYMPUS DIGITAL CAMERAyou can also see that we used some capton-tape in order to avoid shorts on the pads – after making this modifaction the board came up fine with working crystal (no need to enable a register in the ADV7611) as it comes up by default with clock enabled. We were very happy to have this part working 🙂

OLYMPUS DIGITAL CAMERAThe next step was to initialize the ADV7611 to a point where we could establish a HDMI Link – for this reason we basically copied the register settings from a adv761x – v4l2 patch for the linux kernel. This worked pretty straight forward but we came accross the following issue: The ADV7611 uses a one fixed I2C Address and and additionally 7 programmable I2C addresses. But when using i2cdetect for some reason the programmable I2C Addresses where not shown up correctly – So Georg had the idea that we should just try to communicate to these addresses via i2cget to see if we get some response, which worked out fine – so this problem was an issue with i2cdetect on the LIME Hardware. The problem showed up with addresses in the 0x60-0x6x Range … Strange, but once we knew that everything is fine we continued.

We used another LIME as HDMI Source and connected the two devices together.

OLYMPUS DIGITAL CAMERA

With the basic settings taken from the v4l2 patch we could establish a 480p60 link between the two boards. To see if everything was working we checked the Register 0x6A to see if Bit 4 (TMDS_CLK_A_RAW – TMDS clock detected on port A) and Bit 6 (TMDSPLL_LCK_A_RAW – TMDS PLL on port A is locked to the incoming clock) were set. Next we veryfied the Pixel Clock which was coming out of the ADV7611 which was about 27 Mhz, what was expected.

the code for reading the CLK/PLL Info is:

i2cget -y 1 0x4c 0x6A

When measuring HSYNC and VSYNC we noticed some strange behaviour caused by shorts on the PCB – we continuied working with the second prototyp, which didn’t showed this problem – and Fritz was fixing Prototype 1 in the meantime.

By tweaking the Framerate setting to 50Hz we could establish a 720p50 link with a pixel clock of about 75 Mhz.

We tested further to see if there was real data coming out of the ADV7611 by displaying a simple zebra-pattern.

pattern_lines_black_white_720_480

This way we could count the White-Pixels on the Dataline in respect to the pixel clock and on the osziloskope we could really count the 30 white and 30 black alternating pixels in each line. – So we proven that we are producing a picture on the parallel CSI-Bus, which still may have some issues but could already be clearly distinguished from noise.

So the first steps on the Hardware are looking good – the next step is to import a still image using the CSI-Peripheral of the Allwinner A10 – after a short discussion we decided that it would be necessary to implement this as linux kernel module – so we followed the instructions of Olimex to cross compile the kernel for Olimex Lime and started crafting a kernel module. The process described in the howto was straight forward – Only the indenting of the of the kernel module Makefile – that we copied and pasted made some problems. With an working environment to build kernel modules we wanted to read a register of the CSI1-Peripheral to veryify its after-reset state. – This was a bit tricky because we had to enable the clock of the CSI1-Peripheral first – so at the End of Day 2 we couldn’t make this step.

But the day after I had a look at the i2c-sunxi.c driver to see how to enable the peripherals in a proper way – so after some playing around and releasing the CSI1 from reset state we could read the cfg register.


[  818.413777] ahb_csi1 Clk enabled!
[  818.419033] csi1 Clk enabled!
[  818.427087] ccm_csi1_clk: 0x80000000!
[  818.433797] ahb1 clock gating: 0x0014fa3c!
[  818.445265] after reset ccm_csi1_clk: 0xc0000000!
[  819.242955] ioremap ok!
[  819.247678] Register = 0x00300205

So we can communicate with the CSI1-Peripheral – The Source can be found on github – Next we need a linux kernel module that initializes the CSI1-Peripheral and tries to capture a single from to a allocated memory location.