So, I bought a BeagleBone last week, and it finally arrived today. I'm excited to try it out, but one of the things I need to decide (as Jonimus reminded me on IRC) is pick an OS. There's the stock Angstrom, and things like Debian and Arch. My requirements:

(1) I want to be able to write a custom framebuffer for boot
(2) I want to be able to play with the GPIO a lot
(3) I want to be able to write LCD and keyboard drivers (although an LCD driver for the display I'm getting might already exist, which means I want to be able to get some very simple WM going)

Any thoughts? Also, I'm going to be using this topic for general questions and notes as I start playing with the Beaglebone.

Want to tell us a little more about BeagleBones and why you're excited to try yours out?

I'd be happy to! I have a very specific project in mind, hence why I have been excited about the Raspberry Pi slash Beaglebone. Basically, any small, cheap board with a lot of GPIO (digital and a few analog), a fast ARM CPU, and the ability to run Linux is what I wanted. The Raspberry Pi fulfilled those criteria, but it's anyone's guess when people will actually get any at this rate, between the six-month push-back of the initial release, greedy redistributors raising prices, and CE compliance testing. Therefore, I went (for now) with the Beaglebone, based around a TI ARM SoC next to 256MB of RAM. It can run 500-720 MHz at top speed, depending on the power source, and runs Angstrom Linux out of the box. It seems that version of Debian and Arch have also been optimized for it. I have a 320x240 color LCD on its way, should it ever happen to wander here from far, far away, and I'll be resurrecting the matrix keyboard I had been wiring for the now-defunct Ultimate Calculator 3 project to use with it.

Ooooh. Do I have a strong inkling where this is going?

The answer to all of these is sysfs. Provided your kernel has OMAP support, it'll export the GPIOs in /sys for your wiggly pleasure. The BeagleBone's onboard LEDs, for example, are exported as /sys/class/leds/beaglebone/.

I'm not sure what you'd do to write a kernel-space driver for a LCD on GPIO, but I assume it's possible. Would be easier to do it in userspace.
As far as a keyboard driver, you can use the uinput subsystem to create an input device driven from userspace but accessible as if it were provided by the kernel.

Oh, that's amazing. Yeah, I've been playing with the Beaglebone for a few hours today. I figured out how to use /sys/class/gpio to export and use things as input and output, which is fun, although I worry a lot about the speed. I also see that I can play with the OMAP mappings to make it by default have LCD pins broken out, so it doesn't look like I need to do much in that department. And as far as I can tell the four-wire touchscreen just hooks right into the SPI bus. I also went through the staggeringly difficult process of writing the latest 3.2.14 kernel to a spare 4GB microSD card and unpack a root file system with build-essentials and GNOME. Huzzah. Thanks for the feedback, Tari. Can I assume that sysfs is not the solution for the custom framebuffer, though?

If you are sticking with angstrom I suggest you look into narcissus their automated online rootfs image builder. There is also the option of building them yourself using the OE build system, IE bitbake. But this takes close to 10GB of free hdd space not to mention a long time for the initial build, after that things are cached of course but its still not instant.

Not sure how you need to talk to your LCD, but probably not at any rate. You'll probably want to go digging in the kernel source/docs. I know there's no framebuffer equivalent of uinput, so it'll involve some amount of kernel module construction.

I'm perfectly happy with Arch on my Beaglebone. It was simple enough to set up, and mucking about with anything is easy to do without much chance or unexpectedly breaking other components.

Another suggestion for neat things to do with it: look into the USB gadget kernel subsystem. Just offhand, you could do something like connect an input device (keyboard) to the beaglebone, and replicate inputs to another system on which the 'bone is a USB device. Or be an MSD. Or be a USB CDC for gCn bridge. Or any number of neat things, with relative ease.

And now that the Android things are being merged I think with a custom kernel being an adb target should also be possible, though I have no clue why you'd want to do that on something that isn't running android...

Great suggestions, guys; I really appreciate it. As of this afternoon, I have discovered the following interesting items:

:: A fresh Angstrom Linux image accepts any password for the superuser account. So if you think it's accepting your password, it will also accept any other password. passwd is important!
:: There's a nifty little package manager, 'opkg'. I used it to grab the kernel headers, but then found that I actually had the kernel-module-uinput package already.
:: Contrary to some documentation, the BeagleBone uinput udev node is /dev/uinput, not /dev/input/uinput.

Time to start experimenting with uinput, then.

Opkg is an updated fork of ipkg which itself is based in some parts to debians dpkg, which apt* wraps. Openwrt is another user of opkg as well as a few other embedded distro's.

Have you played around with building your own images with bitbake? Then again if you have proper networking on the device just using opkg to grab things from the repo's is most likely much easier and time efficient.

Yup, it was plugging into Ethernet and giving the IP address to Tari that let to my discovery about the root password. I started looking at Narcissus, which looks superb, but as of yet I don't have a need to build myself a whole new kernel. My image is currently 1.1GB of the 4GB MicroSD card, so I'd say I'm safe for now. Once I add more software and drivers, I might need to trim some stuff out, but I'll wait and see.

*bump* Interesting things I noticed in a few minutes with my Beaglebone this morning:

:: You can safely kill the cloud9 IDE and all the node/node4 processes to take down the web-facing development and demo stuff
:: Doing so makes the Beaglebone idle with just 26MB of RAM used, including and SSH session running htop.
:: You can't kill dropbear, or your SSH session dies (and luckily the Beaglebone restarts dropbear)

A discovery of my own from yesterday:

Arch ARM doesn't give you the pin mux controls in /sys/kernel/debug/omap_mux like the stock Angstrom does by default, but it's easy to get that stuff just by mounting a debugfs:

Code:

Pretty cool, good to know. It seems that opkg has no gfortran, and that its gcc has no fortran, which makes me sad. I am not looking forward to trying to compile GCC from source on the Beaglebone; can you think of any good way around it?

*bump* Question above still stands. My 320x240 LCD from China finally arrived. As far as I can tell, I'll be using the LIDD piece of the AM3359 CPU, which has the following slightly-odd pin mappings:

LCD D0-D15: What you'd expect
LCD_VSYNC -> RS (also called Command/Data or CD; NOT reset)
LCD_HSYNC -> Write-bar
LCD_PCLK -> Read-bar
LCD_AC_ENB_CS -> Chip Select 0
LCD_MCLK -> Chip Select 1 (?)

I have it connected, and it displays some beautiful white (well, my cell phone camera disagrees) light:



As you can see, my ribbon cable is a Frankenstein's monster, but at least it's mechanically more sound than the fragile solder job I was planning to do. Now the big problem is of course drivers. From the AM3359 and BeagleBone documentation, I know I need to put the CPU in GPIO Mode 0 for the LCD to be mapped properly. I was really hoping there was already a driver for this kind of display that would work properly with what seems to be an HX8347 display controller chip in the 320x240 display and TI's LIDD controller, but so far I'm coming up empty-handed. I found some initialization sequences in C code from shady Chinese sites, but nothing approaching a real driver.

Any thoughts?

*bump* Spent all day and a good chunk of today compiling and testing Angstrom kernel after Angstrom kernel for my Beaglebone. At this point, I've decided that the LCD definitely has either an SSD1289 or HX8347 display driver. I poked around with the Angstrom kernel enough to discover that the DaVinci da8xx driver supports the AM335x of the Beaglebone, maybe. Here's a full log of my current progress and final collapse to the shameful step of asking for help on the Beagleboard Google Group:

https://groups.google.com/d/topic/beagleboard/IlDGhHQcTwA/discussion

Edit: I have confirmed that it does in fact have an SSD1289 controller, which I _think_ may work with the AM3358x's LIDD 8080 mode.

**Mega-post!** So not too much from the mailing list thus far, other than a few vague pointers and the knowledge that I'm not alone in being lost adding an LCD to the Beaglebone. I have finally found the non-build/tmp-.../ directory where Beaglebone-based patches are applied for the Angstrom Bitbake toolchain:

sources/meta-ti/recipes-kernel/linux/linux-ti33x-psp-3.2/beaglebone

In here, I see such interesting files as:

0002-da8xx-fb-add-DVI-support-for-beaglebone.patch
0026-beaglebone-fix-3.5-lcd-cape-support.patch

Presumably searching through those and understanding how they work will let me port over this patch and use it as a patch without doing something super-hacky:

http://www.lpclinux.com/pub/Forums/LPC313xLinuxPatch0003/0002-Add-support-for-Solomon-Systech-SSD1289-framebuffer_1.patch

I was mucking about with mine today, too. Turns out the kernel lies about how pin muxes are configured (to some extent):

Code:

Bit 5 of the mux register controls I/O direction, but the kernel wrongly claims I had the rxd line set to output. Echoing things to the UART through a loopback (just shove a wire into pins 24 and 26 on the P9 connector) works fine, though.

Kernel driver writing is really hard and really slow. It turns out that part of the problem in seeing a Tux logo on my display is that some genius in the Beaglebone dev team replaced logo_linux_clut224.ppm with a custom, 600-pixel-wide logo, which means it never gets drawn. The proper thing for them to do, of course, would have been to use the CONFIG_EXTRA_LOGO features. But at any rate, although text stubbornly refuses to display and Deferred I/O seems out to lunch, I have a Tux!



Edit: Notes to self, modified/added files:
- Added drivers/video/ssd1289.c
- Modified drivers/video/Kconfig and drivers/video/Makefile
- Modified arch/arm/mach-omap2/board-am335xevm.c
- Reverted/replaced drivers/video/logo/logo_linux_clut224.ppm
- Added debug output in sysimgblt.c, fbmem.c, fbcon.c, and fb_defio.c, but I don't think any of my changes to those files should be part of the final patch

Edit: It's a little tiny htop! It's impossible to read here, since it's in 4x6 pixel font, but trust me that it's all intact.