I had thought that getting my new RevC board up and running *anything*
would be fairly simple - pull the SD from my working RevB board, put
it in the RevC, make the connections, boot.
So far it has NOT been that simple. I thought I'd share some of my
issues with the world, both to help others and to get help myself.
1) Building a working kernel. For my Rev B board, I was able to build
and boot kernels from a wide variety of sources:
linux-omap-2.6
linux-omap-dss2
Mainstream linux git.
I was able to do this with a cross-complier environment build from
scratch given the sources for GCC, binutils, the Linux kernel, and
glibc.
I have been unable to get any kernels from the tips of those sources
to recognize the USB hardware on the Rev C board at all. In fact, as
of yesterday (9 April 2009) the linux-omap-2.6 tip wouldn't even boot
- it would get a paging error on startup.
I have had several pointers of the form "Pull this specific version,
apply this large patch set, and it should work."
However, there doesn't seem to be a single source with working DSS2,
GLES2.0 kernel support, and RevC USB support anywhere.
2) Loading Angstrom. Given the problems in #1, I pulled down the
Angstrom images with the intention of flashing them onto the RevC's
onboard NAND Flash, and worrying about getting anything else working
second.
However, attempting to flash the uImage (as per
http://code.google.com/p/beagleboard/wiki/BeagleNANDFlashing) onto
the Rev C board fails (as noted on that page). The problem has been
noted back in December, but nobody has posted an update.
3) Getting advanced features working. While there is much development
going on in the OMAP community - DSS2 work for the display driver,
power management, DSP bridge support, OpenGLES drivers, hardware
accelerated video - it seems each area of development is going on in
splendid isolation from any other area: at least I have not been able
to find any place where I can easily get a kernel source tree with
DSS2, DSP bridge, and OpenGLES support.
While I applaud the work the OpenEmbedded folks are doing, they seem
to be keep all of their fixes in their "recipes" rather than working
to push the patches upstream. Perhaps I am not seeing work going on
behind the scenes, but that's what it looks to somebody who "just
walked in the door".
As it stands now, it seems to me to be unnecessarily complicated to
get a Rev C Beagleboard working to the levels one might hope for given
the potential of the platform.