[Balloon] Fw: Re: Did you have any luck building a CUED Ball…

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Wookey
Date:  
To: Balloon
Subject: [Balloon] Fw: Re: Did you have any luck building a CUED Balloon distro back in June?
Forwarding in case anyone else finds this info useful, or has any
bright ideas about wheezy init might be problematic.

----- Forwarded message from Paul Fidler <> -----

Date: 21 Sep 2012 18:46:31 +0100
From: Paul Fidler <>
To: Wookey <>
Subject: Re: Did you have any luck building a CUED Balloon distro back in June?
X-Spam-Status: No, score=-3.8 required=4.5 tests=AWL,BAYES_00 autolearn=no
    version=3.3.1



Hi Wookey,

Just a quick update.

After asking you about latest recommended versions etc. and having
touble with 2.6.37.6 and I2C myself, I remembered that I'd actually
looked at this a while ago and had successfully built a 2.6.39.4
kernel last year. I'd given up on it because PCMCIA was broken, and then
forgot all about it and we carried on with OABI for another year.
Thinking back however I didn't recall I2C being broken...

Anyway, for the last week or so I've been running a 2.6.39.4 kernel
that I built a year ago and which has working I2C. I'd built this
version with arm-linux-gnueabi-gcc 4.3.2.

Until just now I was unable to reproduce this kernel. It did not seem
to match the version in trunk, and I couldn't remember whether or not
I'd had to do any balloon3.c or patch file hackery to get I2C working.
Building 2.6.39.4 from the most recent revision of trunk (8 months old)
resulted in a kernel that hung after the 'Uncompressing Linux, booting
the kernel' message.)

However I've now managed to produce a working kernel on another
box, with arm-linux-gnueabi-gcc version 4.4.5 and all is well.
I actually had to use an old revision from the SVN repository to
achieve this:-

svn co -r {2011-09-16} svn://balloonboard.org/balloon/trunk

I built the generic build, not the -CUED build, and haven't (yet)
changed any of the default kernel-menuconfig options. Using the latest
trunk and 2.6.39.4 did not work - it seemed to hang after
Uncompressing Linux, booting the kernel... I've not investigated what
broke I2C in 2.6.37.6.

So it looks like there was some breakage in trunk between September last
year and 8 months ago when it was last touched.


So I'm now running Debian Squeeze, EABI, 2.6.39.4-pxa270 with working I2C,
all built using the same version of the compiler that's in Squeeze.

I did try both using the baloonboard.org build system, and upgrading
from Squeeze to make a Wheezy distribution. Both Wheezys got stuck
after Failing to find /linuxrc, attempting defaults. (Although both
could be chrooted into, so I suspect there is a problem with init in
Wheezy... It's probably a minor issue, but I think for the 2nd year
course we'll be sticking with Squeeze for now.

Best wishes,

Paul.


On Sep 14 2012, Wookey wrote:

> +++ Paul Fidler [2012-09-14 16:52 +0100]:
>> Hi Wookey,
>>
>> Many thanks for this. I did eventually manage to get a trunk built
>> and installed. It was mainly using the default options so the kernel
>> is a 2.6.37.6 vintage. I also have the I2C problem you had, which
>> is a bit of a show stopper for us. I shall investigate and let
>> you know how I get on... (I wonder if it's something to do with
>> all the PCF857X GPIO code for the leds that's now in balloon.c?)
>
> I suspect some bit of platform-device enablement that's simply got
> dropped along the way (or something you have to do differently on
> newer kernels and we aren't). But I haven't looked at all. I'll be
> very interested if you find it. And with such a fix checked-in then I
> think we'll have a nicely-updated CUED-loon set of code.
>
>> I'll also have a go with 2.6.29.4 which seems to be the latest
>> kernel supported by trunk.
>
> There have definately been some kernel 3.x patches go by on the
> balloon-svn list. They are in the menuconfig2 branch, which I
> understand to be 'effective trunk' these days. 3.2.9 seems to be latest.
>
>> I think you were probably correct about the ordering of the
>> bootldr, fpga upgrade. I basically had to load an old bootldr
>> using the jtagger. It seemed to cope with the old fpga, and then
>> used the old bootldr to load the new bootldr and new fpga before
>> daring to reboot.
>
> Yep - that's the ticket. You can upgrade the FPGA _before_ bootldr and
> that OK too IIRC (well, it'll boot, just not read anything from nand).
> It's only new bootldr and old FPGA that is fatal.
>
> Wookey
>


Paul Fidler
-- 
University of Cambridge Department of Engineering | Tel: +44 1223 332816
Trumpington Street, Cambridge, CB2 1PZ, U.K.      | Fax: +44 1223 332662




----- End forwarded message -----
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/