Rev C Beagleboard issues

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.

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

Many of those patches are taken from the people whio are working on
getting the patches accepted upstream. Our policy is to try and get
patches accepted upstream, but in some cases that is not practical.
For example we carry a few patches to get packages to compile against
gcc-4.3, later versions of the packages have the patches, but the
version we originally built still need them.

The linux-omap git kernel is a very dynamic project, so it is not
surprising we are carrying a large number of patches to make specific
pieces of hardware work. In general, we do not write the patches, but
colelct from the various OMAP3 related kernel projects.

Hopefully, this addresses your concerns,

Philip

That's because all of those are under active development and in this
stage they must be independent.

Recently I tried DSS2 and DSP bridge and they don't play along
together very well unless you have the latest patches from Hiroshi. I
put a stable kernel based on 2.6.28 with DSS2 and DSP bridge here:
http://github.com/felipec/linux-omap/tree/v2.6.28-felipec1

Please let me know if it works for you.