I have a bunch of ARMv7a boards at home. They are from different years, have misc CPUs and GPUs. All I think that some of them suck for some reasons.
Pandaboard was great board when got released. Then Texas Instruments fired everyone involved so now it is crap. Sure, mainline kernel works fine but no audio/video decoding in hardware, no OpenGLES due to PowerVR stuff which no one cares about because it is proprietary.
Wandboard Quad. Cool, fast, 2GB of memory, SATA. And hardcoded XGA (1024×768) resolution which can not be changed. Awesome? Not so much when you connect it to FullHD monitor. And forget about community — they are mostly stuck on 3.0 and 3.10 kernels based on Freescale code drops. I should dig deeper when looked at i.mx6 hardware ;(
Looks like it is time to check other boards. Minnowboard Max probably — x86 will fully open drivers.
As guys from/around Texas Instruments promised there is new Beaglebone Black on a market. Faster, cheaper, with video output and other extras. For me it looks like Raspberry/Pi killer done right.
What is on board?
There is a lot of goods:
- 1GHz TI AM355x cpu with ARM Cortex-A8 core supporting ARMv7-a instruction set
- PowerVR GPU with OpenGL ES support (closed source driver)
- HDMI output (with audio)
- 512MB ram
- 2GB eMMC
- 92 expansion pins
- USB Host
- USB device
- microSD slot
- user controlled LEDs
- serial port header
And it still supports (most of) expansion boards from the original Beaglebone which can add extra functionality so possibilities are uncountable. All that for only 45$.
But why it is better?
ARMv7-a cpu core. It means that you can run any Linux distribution on it. Think Ubuntu/armhf, Debian/armhf, Fedora/armhf. No need to reinvent a wheel (aka armhfv6 done for Raspbian distribution).
No dependencies on closed source components. You can boot board and use it with what ever you want and still have control on all sources used. Sure, there are some binary blobs for OpenGL ES but if you do not need this then you are fine. Try to boot R/Pi without binary blobs…
Texas Instruments level of support. Sure, we heard that they abandoned mobile market but Sitara line of processors is still in development, there are new CPUs and they provide documentation and source code for product. Also amount of work done in mainline kernel is not something to be ignored.
Expansion headers. Compare 26 pins of R/Pi with 92 of Beaglebone… Then add capes to this.
So which one to choose?
Beaglebone Black of course ;D
As people on IRC told there are other cheap devices made in China with faster cpus and more memory. But for me Beaglebone is not ‘yet another ARM computer’ but rather ‘yet another microcontroller on ultra steroids’ and this is where the true power of this board resides.
Few people already asked me how open Samsung Chromebook is. So let’s take a look.
Kernel is open. Git tree is available and so are instructions on how to build it. You can check post by Olof Johansonn or take a look at Chromium ebuild. Remember that images need to have DeviceTree attached.
There are few firmware blobs but most of them are available in “linux-firmware” package in Ubuntu. The only exception is “mrvl/sd8797_uapsta.bin” file which is present in Marvell’s firmware repo.
You also need to sign kernels. But tools and developer keys are available as well. We have preliminary version of package for it.
X11 drivers are available as well. Both video (armsoc) and input (cmt) are open. You can run X11 just fine without them even. I provide armsoc one but decided to skip “cmt” one cause “evdev” one works ok.
So where are those ugly binary blobs? In standard places…
One is OpenGL ES support. There is “libmali.0.0.35” which works as libEGL and libGLESv2 but no source for it (kernel part is open). Also license is missing. You can copy it from Chromium (I made package for Ubuntu) but results vary. I would love to get it working cause it can make Chromium browser faster.
Other is video acceleration. Under Chromium there is set of OpenMAX libraries. Under Ubuntu I see only crashes.
Flash plugin is yet another story. Rune K. Svendsen got it partially working but it is still not like it could be.
There is also Google Hangouts plugin under Chromium. So far no information will it work under non-Chromium distribution.
If you have anything to add here then write a comment. And consider joining “Samsung Chromebook (ARM) hackers” team to help us in getting our distros working better and better.
As we plan to move from Poznań to Szczecin this week we are spending at Ania’s parents house.
To have better work equipment then my Dell D400 laptop I grabbed some unused components from home to build computer. The list was not so long:
- 120GB ATA hard disk (it was system one some time ago)
- DFI RS482 mainboard with 2.1GB ram and Athlon64 X2 cpu (my previous desktop)
- cpu cooler
- PS/2 mouse (which I used before buying wireless one)
- power supply
- USB->Serial adapter and some other USB gadgets
- some cables
The only thing which was needed to make it computer was case. And this shown that Szczecin lacks good computer shops — I had to visit 4 of them just to buy decent case as most of time they only had cheap ones.
Anyway I am using this machine for few days now (connected to old 17″ CRT which I used in 2006) with on-board ATI graphics card. It has many names… “RS485, ATI Radeon x1250 Chipset” etc… And this is crap never mind which drivers are used ;(
First I started with “xf86-video-ati” one. Version shipped in Debian ‘sid’ (6.8.0) is very old and reports that I have the same monitor connected to VGA and DVI outputs. Result is not funny. Driver from “experimental” is much better. But 1024×768@85Hz resolution which is default is not so nice — 1280×1024@85Hz is much better but needs to be set by XRandR call or tweaking of X11 config file.
So I tried to use official ATI driver: “fglrx”. As usual it required patching to build with last release kernel (2.6.25) but patches are already in Debian so it took less time then my last fight with NVidia driver. Effect is also strange — this time monitor started in 2048×1536@60Hz which is just insane on 17″ CRT. After switching with XRandR to sane 1280×1024@85Hz it is much more usable.
Good side is that I do not need to use this machine too often so it will stay like it is for some time. When we move it will be one of my build machines.
And if I ever will have to use it I will put NVidia card into this — they at least works perfect in X11.
Recently my machine got series of instability problems. Current situation is — machine stable if Geforce 6600GT card removed. But this leaves me with ATI RS482 on-board graphics… And this chipset just suxx!
I use free driver — ‘radeon’ one. Does it works? Sort of. Problems noticed:
- lack of EDID reading — so my 22″ lcd panel works in 1280×768 mode instead of 1680×1050
- unreadable screen after switching to VT
- X11 crash if qemu/SDL started
- X11 crash if MPlayer with ‘x11’ driver used
- X11 crash if VirtualBox started any virtual machine
Is it usable? Only if there is no other way. But I will rather work on getting my Geforce card working again then trying to get that ATI crap working properly.
TIP: to get 1680×1050 resolution working few commands needs to be run:
xrandr --newmode "1680x1050R" 119.00 1680 1728 1760 1840 1050 1053 1059 1080 +hsync -vsync
xrandr --addmode DVI-0 "1680x1050R"
xrandr --output DVI-0 --mode "1680x1050R"
Anyway according to XRandR there are no monitors connected at all:
12:36 hrw@home:~$ xrandr
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 2560 x 1200
VGA-0 disconnected 1280x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
DVI-0 disconnected 1680x1050+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
S-video disconnected (normal left inverted right x axis y axis)
1280x768 (0x41) 80.1MHz
h: width 1280 start 1344 end 1480 total 1680 skew 0 clock 47.7KHz
v: height 768 start 769 end 772 total 795 clock 60.0Hz
Today I wanted to check status support of TC6393XB companion chip (used in Zaurus SL-6000 for USB Host and few other things) in Linux kernel as the last working version which we (OpenEmbedded kernel hacking team) have is 2.6.17 (a bit old). Most of Google search results pointed to our patches so I tried to search also for “Toshiba Mobile I/O Controller” which also gave me pointer to handhelds.org fork of Linux kernel.
I fetched CVS HEAD (had to remind how to use it since most of projects which I use switched to Subversion or Git). After browsing their repository it looked like they have driver but marked as non functional so no use for me rather.
By curiousity I diffed handhelds.org fork against vanilla 2.6.21 (as hh.org kernel is still 2.6.21). Result was 10 megabytes file (with
-X dontdiff -x CVS switches) — I wonder did they ever considered merging with upstream…