Cubieboard2 A20

Any further updates on Cubieboard2 performance (excluding networking which we've already examined) or its features or community support or anything else of interest?  Is the SATA working properly?

If I understand it correctly, S/PDIF output is available only on a Cubieboard2 header as TTL, but I'd like to get that converted and socketed in the usual coaxial or optical form.  I have a big x86 machine currently acting as my digital audio gateway delivering audio notifications from the computer room, and I'd like to have that function served by a frugal ARM board instead.

What a pity that the Wandboard never appeared in the UK, as it provides optical S/PDIF output directly.

Morgaine Dinova wrote:

 

Any further updates on Cubieboard2

Not really, I've not had a lot of time to spend on it just yet.

What has appeared is that it's locking up randomly, mostly overnight, but can take up to 3-4 days to do so.  I've been trying to work out why, but it's slow going.  Nothing helpful in the logs or any output to the serial console when it happens.  I've gradually been taking bits of software out of the Debian image I'm using, trying to eliminate possible causes, but no luck so far.

Despite the Debian image, the kernel they're using for it is built for Android, so I don't yet know if it's a case of missing a bit of android userspace that's supposed to be doing something, or whether it's a hardware problem.

A couple of thing I have left to try are to boot the Android image from NAND and see if that has the same problem, and to build my own kernel that has enough features in it to hopefully get some debugging info.

There seems to be a community that spans most of the Allwinner based boards centered around http://sunxi.org/ you'll find Olimex stuff there too. Havent dug too deeply yet, mostly looking for resources on building a new kernel. A20 stuff seems a bit scarce so far, there's much more A10 info available.

Looking at the schematics, spdif does go to one of the expansion headers, but it looks like there a resistor (R132) that may not be installed. Unfortunately most of the components don't have any refdes on the silk screen, so finding it will be fun.

This is exactly what I’ve been looking for!

I want to build a device that runs Android, with LCD + touch screen, and enough grunt to run a V4L2 kernel with the STK1160/EasyCap driver (which has been in the mainline kernel since 3.7, I believe) to give me video over USB.  Longer term, I also need to extend this to run more than one instance of the STK1160 driver (for dual and maybe quad camera feeds) and utilise the available I/O.  I want fairly good video quality (at least 720p, 30fps) and the ability to record the video/audio to an MPEG file onto mass storage, so I guess I’m also going to need to build a Kernel with ffmpeg (or libav, or whatever it’s called now)?

My SBC of choice has so far boiled down to the BBB and the ODroid-U2, but looking at it's specs, the Cubieboard2 could be a winner, at least on paper.

The BBB is good for having a big developer community and small price, and the availability of cheap add-ons, like the LCD+touch and a ton of I/O goodies.  The thing that concerns me is - as far as I can make out – the processor may not have enough power to run the V4L2 and ffmpeg at the required rate.  Not many dev’s seem to be using the BBB for video capture in this way (which is a clue in itself!), so I can find very little info about it, but as far as I can tell, it may not be fast enough.  There’s also not much about how easy or hard it would be to get Android onto it.

Then there’s the Odroid-U2.  This is the cheapest of the Hardkernel devices, but costs a fair bit more than the BBB, though is still just within my target budget.  The small size is excellent and the fast quad-core processor looks to be easily up to the job of A/V capture from USB.  On the downside, the ‘community’ is that much smaller and I’d need to add more hardware in order to get a LCD touch screen on board, and yet more hardware to get at the I/O.  This starts to push the price up a fair bit, not to mention the fact that the parts are only available to buy from Hardkernel direct (no distribution network), which puts shipping costs on the high side.  It’s not already rooted, so I’d need to do that before I could make a proper start, making it a steep learning curve (at least for me).  The X/2 addresses some of those issues, but it costs a lot more and is starting to look quite big with all that on-board connectivity!

So, enter the new Cubieboard2, looking like it would be the happy medium I need:  It has all the I/O brought out to a couple of headers, including connections for an LCD and a touch interface (I think, though I’m not sure if this is resistive or capacitive), plus, I read somewhere that it has 4 CVBS inputs!  It comes with Android 4.2.2 and there seems to be a fair bit of info on the Cubieboard Wiki links on how to build custom kernels for it, for use with Android.  Being a 1GHz dual-core processor, I think there should be enough power to do all the processing I need, and the SATA interface is the icing on the cake for me – easy access to HUGE bulk storage!

I’m a bit new to Linux and Kernel building in particular, so I’d be interested in the views of the other contributors here on my choice of SBC, or if I’m totally barking up the wrong tree!

Bit of a long post this one, but does anybody agree that Cubieboard2 is the way to go for my project?  Do my assumptions stack up, or am I likely to be heading down a blind alley with the Cubieboard2?

Any comments would be most welcome!

Message was edited by: Douglas Ponsford

Douglas Ponsford wrote:

 

STK1160/EasyCap driver (which has been in the mainline kernel since 3.7, I believe) to give me video over USB. 

The current kernel support is 3.3, you're very much into the 'experimental' areas for anything newer. There's details for an experimental 3.10 here http://sunxi.org/Linux

I want fairly good video quality (at least 720p, 30fps)

The STK1160 driver doesn't appear to support 720p according to http://linuxtv.org/wiki/index.php/Stk1160_based_USB_2.0_video_and_audio_capture_devices

so I guess I’m also going to need to build a Kernel with ffmpeg (or libav, or whatever it’s called now)?

ffmpeg is an application, nothing to do with the kernel.

Your obvious problem is going to be that you're converting to MPEG in software, so the board you chose will need to have sufficient cpu power to do this at your chosen resolution and for the number of capture devices you're using simultaneously.  Use of the CedarX engine on the Allwinner chips may be possible depending on what libraries are available and whether the software you want to use has these specific customisations.

somewhere that it has 4 CVBS inputs!

That's unclear, the A20 user manual suggests it has a Transport Stream controller, so you could theoretically do DVB or ATSC with an appropriate Tuner. However, looking at the Cubieboard schematics it seems that the required pins are not connected to anything.

Being a 1GHz dual-core processor, I think there should be enough power to do all the processing I need,

912Mhz, not 1GHz, seemingly this is what Allwinner currently rate the chip to run at.

I’m a bit new to Linux and Kernel building in particular,

Kernel building is relatively straight forward, the challenge is more in finding the right kernel that includes drivers for the SoC to cover the features you need.  It's unlikely to matter which SBC you chose, there will be a learning curve. How steep the curve is will depend a lot on your current experience as well as where the community around the SBC is with regards to non mainline kernel patches. It's unlikely you'll be able to simply download a http://kernel.org kernel and have everything work.

I should also add that the supplied Android image in the Cubie2 appears to disable one of the cores on the A20 and use only one core.

I don't know enough about Android to understand why it might be doing that, but it's worth investigation if you intend to use Android.

Hmm, OK.  Sounds like I'm trying to bite off way more than I can chew here!

I read the bit about "720x576px" and assumed that meant 720p.  To be honest, I don't care if it's not true 720p, as long as it's no worse than VGA.  I've seen the videos on the Hardkernel website showing the 4 USB-webcam feeds and they look pretty ropey, so I assumed they were just really low-res UVC cameras.  I then picked up on the stk1160 as the blurb in  http://easycap.blogspot.co.at/  made it look fairly straight forward.  I guess if you know your way around Linux, then it probably is!

As for Android suppressing one of the cores: wow, that's definitely a show-stopper!  There's certainly no mention of that in the product specs!  I have experience of developing Android apps, which would help speed up the application development, but if that's what they do, then that's out of the question.  Out of interest, where did you find that out?  Do you know if that's the same with the ODroid devices?

I have no idea what you mean by "it has a Transport Stream controller, so you could theoretically do DVB or ATSC with an appropriate Tuner.".  I'm not planning to use a tuner - the inputs will be straight composite video.

I have 25 years of experience developing embedded control systems written in C, but I have to admit that reading up on how to build kernels and getting the right distro for what I need is like trying to read a foreign language.  I honestly had no idea it would be this difficult for a seasoned programmer to get to grips with Linux, but it seems fairly clear that I'm nowhere near clued up enough to tackle this at the moment and am likely to have a year or so's graft in front of me to get to grips with what I need to do before I'll be able to get anything up and running.  In that time, I suspect the SBC landscape will have changed enough to cancel out any gains I might have made playing around with this board.

So I guess it's back to the drawing board!

Anyway, thanks for your comments - they're much appreciated.  At least it's saved me a hundred quid or so and a whole heap of wasted time going nowhere!

Douglas Ponsford wrote:

 

I'm not planning to use a tuner - the inputs will be straight composite video.

 

Hi Douglas,

In that case, you will need some sort of hardware compression device, because a single SD composite signal will consume most of the USB 2.0 bandwidth, as far as I am aware (I'm no expert on this). Also, I notice the easycap site says:

Probably supported but not tested:

• Two (or more) stk1160 devices working side by side on one system
  (If this is not possible, it's not a driver issue, but rather about USB bandwidth)

Douglas Ponsford wrote:

I read the bit about "720x576px" and assumed that meant 720p.  To be honest, I don't care if it's not true 720p, as long as it's no worse than VGA.

720 refers to the vertical resolution, the 'p' on the end means 'progressive', or in other words non-interlaced.  720x576 on the other hand is 576 vertical, but also it's interlaced, so the effective resolution is something like 288 (half of 576). There are de-interlacing techniques, but ultimately it depends on the actual resolution of the camera whether it's helpful. http://en.wikipedia.org/wiki/Deinterlacing has some reasonable descriptions of the proces along with some of the problems it causes.

'VGA' is typically thought of as 640x480, so yes interlaced composite video can be worse than vga.

As for Android suppressing one of the cores: wow, that's definitely a show-stopper!  There's certainly no mention of that in the product specs!  I have experience of developing Android apps, which would help speed up the application development, but if that's what they do, then that's out of the question.  Out of interest, where did you find that out?  Do you know if that's the same with the ODroid devices?

Boot the Cubieboard2 from the supplied Android image on NAND, type 'dmesg' from a serial console. Towards the end there's some messages about it killing the second core.  This may be particular to the specific Android image supplied with the board, and may be due to the A20 being very new.  Looking at http://sunxi.org/Linux_mainlining_effort under the 'Work In Progress' section you'll see that they're still working on SMP support for A20 and A31.  I expect the situation will improve given time.

No idea if the ODroid does the same, however I'd expect that there will be a way to use more than one core at some point. It would seem silly for the manufacturers to produce multi-core devices and then not use them to their potential.

I have no idea what you mean by "it has a Transport Stream controller, so you could theoretically do DVB or ATSC with an appropriate Tuner.".  I'm not planning to use a tuner - the inputs will be straight composite video.

Basically the A20 doesn't appear to have composite inputs, it has inputs suitable for 'Digital TV'.

I have 25 years of experience developing embedded control systems written in C, but I have to admit that reading up on how to build kernels and getting the right distro for what I need is like trying to read a foreign language.

It's like anything else, there's a learning curve.  Your 25 years experience in C didn't happen overnight after all   With a little experience, building kernels isn't that hard.

In that time, I suspect the SBC landscape will have changed enough to cancel out any gains I might have made playing around with this board.

the SBC landscape has changed a lot over the last year or so, I expect it will over the next year too. The experience probably wouldn't be wasted though, there are a lot of common themes and you find that the SoC manufacturers tend to do things in similar ways on the newer, faster versions. So the latest Allwinner device in a years time will likely have a lot in common with todays version.

You need to start somewhere after all, and there's no particular reason to think the Cubie2 is any worse a starting point than many of the other SBC's, there's challenges to be had on all of them

Douglas Ponsford wrote:

I read the bit about "720x576px" and assumed that meant 720p.  To be honest, I don't care if it's not true 720p, as long as it's no worse than VGA.

720 refers to the vertical resolution, the 'p' on the end means 'progressive', or in other words non-interlaced.  720x576 on the other hand is 576 vertical, but also it's interlaced, so the effective resolution is something like 288 (half of 576). There are de-interlacing techniques, but ultimately it depends on the actual resolution of the camera whether it's helpful. http://en.wikipedia.org/wiki/Deinterlacing has some reasonable descriptions of the proces along with some of the problems it causes.

'VGA' is typically thought of as 640x480, so yes interlaced composite video can be worse than vga.

As for Android suppressing one of the cores: wow, that's definitely a show-stopper!  There's certainly no mention of that in the product specs!  I have experience of developing Android apps, which would help speed up the application development, but if that's what they do, then that's out of the question.  Out of interest, where did you find that out?  Do you know if that's the same with the ODroid devices?

Boot the Cubieboard2 from the supplied Android image on NAND, type 'dmesg' from a serial console. Towards the end there's some messages about it killing the second core.  This may be particular to the specific Android image supplied with the board, and may be due to the A20 being very new.  Looking at http://sunxi.org/Linux_mainlining_effort under the 'Work In Progress' section you'll see that they're still working on SMP support for A20 and A31.  I expect the situation will improve given time.

No idea if the ODroid does the same, however I'd expect that there will be a way to use more than one core at some point. It would seem silly for the manufacturers to produce multi-core devices and then not use them to their potential.

I have no idea what you mean by "it has a Transport Stream controller, so you could theoretically do DVB or ATSC with an appropriate Tuner.".  I'm not planning to use a tuner - the inputs will be straight composite video.

Basically the A20 doesn't appear to have composite inputs, it has inputs suitable for 'Digital TV'.

I have 25 years of experience developing embedded control systems written in C, but I have to admit that reading up on how to build kernels and getting the right distro for what I need is like trying to read a foreign language.

It's like anything else, there's a learning curve.  Your 25 years experience in C didn't happen overnight after all   With a little experience, building kernels isn't that hard.

In that time, I suspect the SBC landscape will have changed enough to cancel out any gains I might have made playing around with this board.

the SBC landscape has changed a lot over the last year or so, I expect it will over the next year too. The experience probably wouldn't be wasted though, there are a lot of common themes and you find that the SoC manufacturers tend to do things in similar ways on the newer, faster versions. So the latest Allwinner device in a years time will likely have a lot in common with todays version.

You need to start somewhere after all, and there's no particular reason to think the Cubie2 is any worse a starting point than many of the other SBC's, there's challenges to be had on all of them