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.

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

shabaz wrote:

 

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,

Relatively simple calculation

720x576 @25fps, assume RGB and 8 bits per colour per pixel. Sometimes to make things easier they'll align to 32bits rather than 24 making the problem worse, but it's all implementation specific and the requested capture mode obviously makes a difference too. Maybe you're using YUV instead of RGB or whatever..

720x576 = 414720 

414720 x 3 = 1244160

1244160 x 25 = 31104000 or approx 30MBytes/s

USB 2 is 480Mbits/s or approx 60MBytes/s theoretical max. Reality is that the max is more like 35-40MBytes/s due to protocol overheads and simple inefficiencies. So more than one of these per USB host controller is likely to be problematic and your capture resolution limited by USB bandwidth.  Maybe it's possible to do 320x240 captures with multiple devices, but that's obviously worse than what Douglas is looking for.

OK, that makes sense so far - thanks.  What I'm hearing is that whatever board I go for, there will be a fair ramp up time (for me) to get something up and running, and that I'm going to need to become very familiar with Linux regardless of whether I go for Android or not.  Is that a fair summary?  My desire to use Android is due to the dead-easy-to-develop UI, but if Linux can operate in a similar way, then I guess I could drop the Android?

I understand all the comments about video resolution and the limitations that USB bandwidth will impose, but some things still confuse me:

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

Looking at http://kernel.org, they list a stable release at 3.11.4. Or do you mean that the sunxi.org kernels are specific to the Cubieboard/2, i.e., these are only ones that would run on this board (in which case, isn't 3.4 the latest and greatest)?  Does that mean when the sunxi.org 3.10 kernel stops being 'experimental' and becomes 'stable', then it will contain all of the features that are in the mainline (kernel.org) kernel, including the stk1160 driver I need?  If that's the case, then as a newbie to all this, I assume I'd be better off waiting the sunxi 3.10 to stabilise before using it?

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.

That's a mighty long list of unfinished software!  If 3.3/3.4 is the only 'stable' release, then it looks like a huge amount of A20 hardware isn't yet supported.  Looks like they released this board somewhat on the early side!  The mainlining effort list goes up to 3.13, but - as you point out - 3.10 is still experimental, so 3.13 seems to be a ways off yet and SMP support isn't even assigned a target version number!

Am I even close to understanding all of this?

Hi shabaz,

You're right, the EasyCap page makes no guarantees about running 2 or more devices simultaneously.  I shouldn't attempt to run before I can even crawl, so getting just one running properly is looking like a mammoth task all of it's own so far!  One step at a time.......

I'd prefer to use hardware compression, but this type of hardware seems very expensive and would probably blow a hole in my budget.  Unless you know of a source of cheap (and software supported!) hardware compression devices?

Hi Douglas,

I'm afraid I've never attempted this, so I don't know of how it would be done.

One way is to use an analog video decoder that can take a composite input,

and outputs a H.264 video stream (ethernet interface). There are commercial boards that

will do that. Then, the code is greatly simplified, since it just needs to write the

stream to disk.

In other words, I've avoided the problem in the past by using off-the-shelf products for this.

Axis have devices that will accept 4 video inputs, but they are not cheap :-(

Douglas Ponsford wrote:

 

OK, that makes sense so far - thanks.  What I'm hearing is that whatever board I go for, there will be a fair ramp up time (for me) to get something up and running, and that I'm going to need to become very familiar with Linux regardless of whether I go for Android or not.  Is that a fair summary? 

It may not be as clear cut as that. Android is based on the linux kernel, with some android specific additions.  However the user applications are very different between Android and a traditional distribution like Debian or Fedora. So some knowledge applies to both, some doesn't.

My desire to use Android is due to the dead-easy-to-develop UI, but if Linux can operate in a similar way, then I guess I could drop the Android?

Android being easy to develop for is only really the case if you have that experience. The Cubieboard is my first real experience of Android and I'm finding it very difficult to use, the tools I'm used to are not there. So the development environment and target are personal preference, if you're comfortable with Android then it's probably the best choice for you. Using something else means another learning curve.  There's no wrong answer, only you can decide if it's worthwhile to spend the time learning something new.

Looking at http://kernel.org, they list a stable release at 3.11.4. Or do you mean that the sunxi.org kernels are specific to the Cubieboard/2, i.e., these are only ones that would run on this board (in which case, isn't 3.4 the latest and greatest)? 

Yes, currently the 3.11.4 from kernel.org will not run on the A20 as not enough of the drivers are present.

The kernels from sunxi.org include drivers (and whatever other stuff) needed by the A20.  I'm not absolutely clear on whether that 3.10 experimental kernel is actually useable or includes all the drivers etc. Even if it doesn't include everything, as long as it includes enough of the things you're interested in then I don't see a reason not to use it other than that the experimental tag implies there may be problems.

3.4 is the current kernel on sunxi.org, what ships with the Cubieboard2 is 3.3.0+ and that's what's available from cubieboard.org. What significance there is to that I can't say.

Does that mean when the sunxi.org 3.10 kernel stops being 'experimental' and becomes 'stable', then it will contain all of the features that are in the mainline (kernel.org) kernel, including the stk1160 driver I need?  If that's the case, then as a newbie to all this, I assume I'd be better off waiting the sunxi 3.10 to stabilise before using it?

It'll include everything in the 3.10 kernel.org kernel yes. Mainline will have moved on to include other things.  Effectively that's only relevant when a driver/feature/bugfix you need is only available in a newer kernel than what's available for your SBC.

The slightly unfortunate problem is that SoC manufacturers tend to develop their drivers away from mainline and it can take a long time to catch up.  For example if you look at the official Freescale kernel releases for the i.MX6, they're still back on 3.0.35.  sunxi.org and beagleboard.org are somewhat better in this regard as they are actively trying to get their stuff into mainline, but it does all take time

That's a mighty long list of unfinished software!  If 3.3/3.4 is the only 'stable' release, then it looks like a huge amount of A20 hardware isn't yet supported.  Looks like they released this board somewhat on the early side! 

That's debatable.  Realise that it probably takes at least a year to get some driver into the mainline kernel and things become a bit clearer. Nobody is going to sit on a product for a year or more while that gets sorted out. There has to be some overlap where people have access to the board so that they can develop and test the software before it makes it into the mainline kernel. That's exactly why you have the experimental stuff in the sunxi.org kernels.

Am I even close to understanding all of this?

If you are, you're doing better than I am

This is interesting: http://blog.lemoneerlabs.com/post/BBB-webcams

In terms of USB bandwidth and processing video, it looks like the BBB is able to read and process the video stream, if it comes from a camera that has MJPEG compression on-the-fly.  Choice of camera is obviously important here, but this blog, at least, indicates that it is feasible on the BBB.  This blog lists a Logitech C920 as having H.264 compression, which sound exactly right for me!

But ,clearly, I've still got a steep hill to climb if I go this route!

I've still got to establish whether I can reliably store the resultant video stream to a file (with ffmpeg, I assume), but whether that's on a SATA disk on the Cubieboard2, or SDCard on the BBB is probably acedemic at this stage.

Hi Douglas,

I don't know what the use-case is, but in general you'll get much better results if your camera is H.264. The MJPEG is good for video stills (e.g. a snapshot every second), but H.264 is better for motion video (and saves a lot of disk space).

The BBB (or any Linux platform) can handle any of these streams, since it is just network traffic.

EDIT: Sorry I thought Ethernet was being used. If USB, then a driver that runs on the platfom is needed.

Hi Douglas,

I don't know what the use-case is, but in general you'll get much better results if your camera is H.264. The MJPEG is good for video stills (e.g. a snapshot every second), but H.264 is better for motion video (and saves a lot of disk space).

The BBB (or any Linux platform) can handle any of these streams, since it is just network traffic.

EDIT: Sorry I thought Ethernet was being used. If USB, then a driver that runs on the platfom is needed.

If USB, then a driver that runs on the platfom is needed

By that, do you mean V4L2, or a BBB-specific USB driver?

Hi Douglas,

Some webcams will be supported in Linux, and a driver may already be compiled and available on the platform, or it may need to be compiled. However, I think not all webcams are supported in Linux because the manufacturer may not have made a driver available for Linux, compiled for the target device (e.g. ARM).

As long as the driver is in source form then it should be possible to compile it for any linux distro. The problem usually appears when your kernel is 3.11.4 and the vendor driver only supports 2.6.24 or vice versa.

Supplying binary drivers for linux is difficult, since you'd need to supply one for every possible distro and kernel version.  The likes of nvidia sidestep that problem by providing a driver that's mostly binary but that comes with an adaption layer that you compile against your kernel. This mostly reduces the problem to needing three versions for x86, x86_64 and Arm.

Whether cheap webcams go to those extremes is uncertain.

So.... I don't need V4L2 then, if the webcam I'm using is already supported in Linux?  Or do you mean that there are different 'flavours' of V4L2 for different types of webcam?  Or have I completely misundestood what V4L2 is, and what it's used for (which wouldn't surprise me!)?

Having scoured the internet for months on end on this subject, it seems to me that V4L2 is the minimum requirement to read a video from USB, but I've yet to find a website that states what it actually is, whether or not it is always required, and how you build a version of it for the specific SBC and camera that you are using.

All the websites I've visited about Linux - and in particular, about video capture - seems to be aimed at people who already know what they're talking about, but I've yet to find one that describes the process to a newbie.

Douglas Ponsford wrote:

 

If USB, then a driver that runs on the platfom is needed

By that, do you mean V4L2, or a BBB-specific USB driver?

A linux driver specific to the USB webcam.  You can get some idea of what's easily available here http://linuxtv.org/wiki/index.php/Webcam_Devices the problem of course is that it's sometimes difficult to work out which driver goes with any given webcam as they don't tend to tell you which chip is inside on the outside of the box.  You can find out by plugging it in and reading the vendor and device ID's, but you've spent the money by that point !