I'm back to working on beaglebox again after a long pause.  The holidays were the first delay, but now I'm down to working only weekends on BeagleBox because my weekday nights are taken up with working on the 2nd edition of my last gimp book (promised to the publisher, No Starch Press, to coincide with GIMP's 2.8 release which is due out sometime this year).  It's going to be awhile before I get that done, so I'll just have to squeeze in as much as I can on BeagleBox on the weekends.

Anyway, today I dove back into trying to get X11 up on the board.  It's unclear to me exactly how this should be done.  The first problem is that there are two versions of kernel space drivers for the board, effectively known as dss and DSS2.  The latter appears to be what Angstrom is using if I'm reading the bitbake configurations correctly.  I spent a lot of time figure this one out.  To get a working version of DSS2 I went to the primary kernel git repo for it, Tomi Valkeinen's on gitorious.org.  This kernel seems to behave correctly given the options for both TV out and hdmi out.  So I stuck with that.

The next step was to find a working xorg driver module.  Comparing xorg.conf files from Angstrom's source, a Narcissus build and Koon's latest BB-demo image it would appear they all make use of the omapfb xorg driver.  The last public release of this appears to be pushing 2 years old.  So it doesn't seem likely this is based on DSS2.  The question here is whether a kernel driver is required for this xorg driver and, if so, which one?  And if it is is DSS and not DSS2, why does Angstrom build the kernel with the DSS2 patches?  Confusing, to say the least.  Koon suggested on the mailing list (I don't have the reference handy) that there was info in /boot in the BB-demo image about this but the version of the demo image rootfs I have doesn't have any such information.  I need to boot the narcissus image and the bb-demo image again and see if the kernel config is in /proc/config.gz.  That may help clear this up a little.

I created a buildroot package to grab the latest omapfb driver snapshot and built it.  This was fairly easy but I ran into the next problem:  this xorg driver can be built using the neon extensions in the OMAP3 processor.  However, my crosstool-NG build doesn't appear to support this.  If I configure the driver with –enable-neon and build I get an error about unknown assembler instructions.  Take this option out of the configure step and build and the driver builds fine.  So now I need to figure out how to get the NEON extensions into my cross toolchain, if that's possible.  I may have to drop using my own toolchain and start using CodeSourcery's instead.  Not a horrible idea, but I wanted to be able to build everything from the ground up.  I'd hate to give in on that idea at this point.

Anyway, I built the xorg driver without NEON and tried it on the board.  It locked up after loading the xorg driver.  So I'm back to square one at this point, at least with respect to getting x11 running.  I don't know if I need kernel support for the xorg driver nor, if I do, which version of that support.  I don't have NEON enabled in the my cross toolchain but it would be nice to have it and apparently it can be used by the xorg omapfb driver. 

To make matters worse, sourceforge got hacked this past weekend so they reset all their passwords.  I've reset my passwords but now I can't get to my cvs.  I really should pull all of this out of CVS anyway and stick it in GIT now that I'm getting a little more familiar with its use (we use Mercurial at work and there are many similarities).   If had done that then I would be able to tell what was new in my sandbox right now.  Unfortunately, with CVS, I can't do that without SourceForge's assistance and they aren't responding yet.