The Beaglebone: Exploration and Notes

KermMartian

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.
_________________

elfprince13

Want to tell us a little more about BeagleBones and why you're excited to try yours out?
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

KermMartian

elfprince13 · Posted: 12 Apr 2012 12:19:04 pm Post subject:

Ooooh. Do I have a strong inkling where this is going?
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

Tari

KermMartian · Posted: 12 Apr 2012 08:09:08 pm Post subject:

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. Smile

Can I assume that sysfs is not the solution for the custom framebuffer, though? Cool

_________________

TheStorm · NOU! Joined: 26 Mar 2007 Posts: 2375

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.
_________________

"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live" -Unknown

"If you've done something right no one will know that you've done anything at all" -Futurama

"Have a nice day, or not, the choice is yours." Tom Steiner

<Michael_V> or create a Borg collective and call it The 83+
<Michael_V> Lower your slide cases and prepare to be silent linked. Memory clears are futile.

Tari · Posted: 12 Apr 2012 10:03:51 pm Post subject:

TheStorm · NOU! Joined: 26 Mar 2007 Posts: 2375

KermMartian · Posted: 13 Apr 2012 01:29:01 pm Post subject:

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.
_________________

TheStorm · NOU! Joined: 26 Mar 2007 Posts: 2375

KermMartian · Posted: 13 Apr 2012 06:27:13 pm Post subject:

Yup, it was plugging into Ethernet and giving the IP address to Tari that let to my discovery about the root password. Smile

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.
_________________

KermMartian · Posted: 19 Apr 2012 10:41:56 am Post subject:

*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)
_________________

Tari · Posted: 19 Apr 2012 01:35:50 pm Post subject:

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:

KermMartian · Posted: 19 Apr 2012 01:45:44 pm Post subject:

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?
_________________

KermMartian · Posted: 28 Apr 2012 09:32:55 pm Post subject:

*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?
_________________

KermMartian · Posted: 30 Apr 2012 07:39:56 pm Post subject:

*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.
_________________

KermMartian · Posted: 03 May 2012 03:25:02 pm Post subject:

**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
_________________

Tari · Posted: 03 May 2012 05:30:13 pm Post subject:

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

KermMartian · Posted: 11 May 2012 01:57:47 pm Post subject:

Kernel driver writing is really hard and really slow. Sad

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. Sad

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.

_________________