On 31/03/2011 17:17, Peter Clifton wrote:
> On Thu, 2011-03-31 at 16:56 +0100, Chris Jones wrote:
>> I've been working on this for days now and I still don't know quite what
>
>> - check out head of menuconfig2 branch from svn
>
> Surely the Balloon kernel tree is not kept in SVN? Also, the fact you
> are maintaining kernel patches in quilt sounds quite dodgy to me too.
>
> The only sane way to manage kernel branches is in git, possibly
> (although not necessarily) using stgit to manage patch stacks on top of
> that. (stgit has its pros and cons, but basically works like quilt).
The Balloon kernel patches are maintained as various quilt series for
different customers and variants of the board. That's what's checked out
of the balloonboard.org svn repository.
The build system downloads the kernel source tarball as required,
unpacks it, applies the YAFFS patches and quilt series, and kicks off
the build.
>> My workflow goes something like this:
>> - build kernel (make at menuconfig2 top level)
>> - download to board, test, discover bugs as expected
>> - in build tree:
>> - quilt pop balloon3-i2s
>
> I think you need to push the patches into place before you edit their
> contents.
My example there assumed that the quilt series were all applied (pushed)
after the previous build, so popping back to the one I wanted to modify
made sense.
>> - edit various files. Some of these are in the patch, others won't
>> be. For example, I've put debug code in /arch/arm/mach-pxa/mfp-pxa2xx.c
>> which I don't expect to become part of the patch but makes my
>> development job easier.
>
> It might make sense to make a new quilt patch for those temporary
> changes - so you can pop them on and off easily.
But then that patch has to go into the series, which risks getting me
and my svn checkout even more confused. You're right, it might make them
easier to manage, though.
>> - quilt refresh
>> - back at menuconfig2 top level, make again.
>>
>> What happens now seems to be unpredictable. My kernel .config tends to
>> get forgotten, which wastes a lot of time. I have to copy that into
>> /package/kernel/.../balloon3config-whatever..., don't I?
>
>
>> It's quite common that the kernel just won't build. For example, at this
>> very moment, if I try to make, it dies with 'balloon3_gpio_vbus
>> undeclared'. It seems not to have reapplied the patch series. Why not?
>
> Is that menuconfig2's job? Or do you have to do it manually I wonder?
Normally it does that, but sometimes it doesn't. One of my problems is
not being able to divine a mental model which adequately represents its
behaviour!
> Slightly off at a tangent - but you can ease the pain of rebuilds by
> installing "ccache" if you haven't already got it. This makes rebuilds
> of already cached compilations really fast. (Often in cases where make
> cannot assume a file does not need to be rebuilt).
>
> I've no idea how to setup ccache for a cross compile build though -
> sorry.
Thank you for the hint. When things are going right, recompiling a
couple of kernel modules and relinking the kernel takes only seconds.
>> If I quilt push -a, then try make again, it starts asking me config
>> questions. Why? Why? Note that I'm making in menuconfig2, not /build/kernel.
>
> I think if your patch touches Kconfig stuff, it will automatically want
> to check up on your config. "make oldconfig" is something I use quite
> often when building PC kernels.
>
>> To get to this state, all I did was move some edits from one patch to
>> another. I'd patched balloon3.c in balloon3-i2s.patch, which is bad news
>> because that file is already patched in balloon3.patch. So I decide to
>> fix that. No problem:
>
> Sounds like stgit would be useful to you guys.
>
>> I don't want to throw my source tree away and start again because it's
>> got changes in which aren't part of a patch, and I don't want to spend
>> time tracking them down and recording them. I shouldn't have to do this,
>> surely?
>
> git diff ?
>
> (Or is your kernel tree not a git checkout?)
You got it. It's not a git checkout. The balloonboard project doesn't
use git.
>> What's the *right* way to do this? Tell me, and I'll write it down
>> somewhere that everyone can see.
>>
>> This sort of documentation is essential. We have a complex build system
>> and no documentation on how it works, so anything other than a
>> straightforward distro build feels dangerous. I want to help change that.
>
> I have to confess feeling lost with a lot of automated kernel build
> stuff. I can just about build a custom Ubuntu kernel, but I don't grok
> all the custom configurations stuff for multiple targets.
>
> Once I have a known working .config file, I save that - use it all the
> time, and just build using "make", "make modules_install" and "make
> install" from the kernel tree. That might be more a PC kernel workflow -
> and it could well have been customised by Ubuntu, as I use their git
> repositories for my kernel.
Yes, I think that's a different case: we're cross-building here and
changing the possible .config options on the fly, so everything gets
more complicated!
Thank you for the discussion - it does help us to think about and
publicise how all of this works, which has got to be a good thing.
Chris
--
Chris Jones -
chris@martin-jones.com
Martin-Jones Technology Ltd c/o Element Energy Ltd
Twenty Station Road, Cambridge, CB1 2JD, UK
Phone +44 (0) 1223 655611 Fax +44 (0) 870 112 3908
(text/plain)