• From: Australia
  • Registered: 2011-05-24
  • Posts: 92

Topic: Kernel upgrade for CHB

In collaboration with another user from this forum, I'm working updating the kernel sources for the CHB by merging the source from the official Chumby 2.6.28 kernel with the more recent kernels from Freescale's git repository.

I thought I'd mention this here incase anyone else is working on the same issue, or has expertise to lend.

The first step was to determine the point at which Chumby's sources diverge from the Freescale sources.  It appears that the point of divergence was SHA ec75a15b9fab3e16e456838d79420a3cfab06573 (determined by measuring the size of the diff between the falconwing source and successive imx commits). At that closest point there are 327 files that differ between the Chumby and Freescale sources.

The process I'm using is to merge successive groups of commits from the Freescale repository into the falconwing code, resolve conflicts, test that it builds and boots.  The repository for this is on GitHub.  Unfortunately because I'm merging such old commits, GitHub's network view fails to show the connections that would illustrate what is going on.

The first milestone will be to catch up with Freescale's imx_2.6.28 branch.  After that we will shoot for imx_2.6.31 which is their next tagged release.

2 Reply by guyc (edited by guyc 2012-02-16 20:52:49)

  • From: Australia
  • Registered: 2011-05-24
  • Posts: 92

Re: Kernel upgrade for CHB

We are getting close to the first milestone which is a working 2.6.28_5.1.0 kernel.  It builds and boots.  At the bottom of that page is a diff between the boot log from the stock kernel and the boot log from the new one which highlights a few of the differences.

The one obvious remaining problem is related to the USB hub.  The USB code has been substantially refactored in the Freescale code, and it now throws this error on boot:

 hub 1-1:1.0: config failed, hub has too many ports! (err -19)

and as a consequence the USB ports are not functional in this build.  We will have to resolve that before we move forward.

Update: After rebuilding the kernel with additional logging to help isolate the USB failure I have not been able to repeat the problem!  Despite numerous reboots served both cold and warm, USB is working fine and the console shows "hub 1-1:1.0: 4 ports detected".  I guess we can move on.

  • Registered: 2012-04-02
  • Posts: 3

Re: Kernel upgrade for CHB

I would like to be kept updated on this... When do you think you'll have a fully operational build done?

Also, what kind of changes have been made (the updated Freescale stuff vs. legacy Chumby sources)? What sort of functionality would I gain? What would I lose?

  • From: Australia
  • Registered: 2011-05-24
  • Posts: 92

Re: Kernel upgrade for CHB

I've been using the 2.6.28_5.1.0 kernel for a month or more now with no evident problems.  At this point it doesn't provide anything important above previous OpenEmbedded builds.  There have been a few internal changes including a refactoring of the USB support.  AFAIK what you lose is the proprietary ActionScript code that was on the Chumby-provided image, although I imagine if you wanted that it would just copy over.  I don't use it, I haven't tried, YMMV.

If you really want to know what changed, you can browse the merges of 2.6.28_4.5.1 and 2.6.28_5.1.0 in github.  Check out this fix... gasp!

The next milestone will be 2.6.31 and you can look at the mainline Linux kernel release notes to see what features that will bring in.

Where this upgrade gets risky is where I have to manually merge updates from Freescale with custom Chumby code.  For example there are some memory timing tables that have been tweaked for the Chumby and the table was later refactored in the Freescale tree to add some new fields.  Filling in the missing fields takes a certain amount of guess work.  So far nothing that has been too problematic, but it does take time to pick through all of the merge conflicts, read and understand the surrounding code, and then manually repair the merge.  A subtle error in I/O timing could also be overlooked in acceptance testing.