[Gta04-owner] building the kernel

[NeilBrown]

On Wed, 25 Jul 2012 20:31:09 -0700 (PDT) Kevin Hremeviuc
<khremeviuc at yahoo.com> wrote:

> Hi all,
> 
> I have had no luck using kernels built from branches in Neil Brown's git repository. Changing the console does not result in screen output. 
> So I took another tack and grabbed the v3.2-gta04-qtmoko-v46 branch kernel sourcecode from Radek's https://github.com/radekp/linux-2.6 git repository. I also had to grab the gta04-init stuff in order to build the kernel. Once built, I installed the kernel and modules onto my sd card (2 partitions for the uImage) and my gta04 booted successfully first time. Now I have a kernel with the media controller and alsa sequencer included so I can play.
> 
> I guess some things spring to mind after the process I have just been through. They are:
> 
> 1.) Which is our master repository?

"master" is determined by acclamation, not proclamation.  i.e. no-one can say
"this is it", but if everybody uses one, then that because it by default.
As far as I know all 3.x kernels for the GTA04 come from my repository.
People may well make changes, particularly to the config.

> 2.) Why don't the kernels built from Neil Brown's repository and branches work for me? Are there bits missing or extra documentation required?

The v3.2-gta04-qtmoko-v46 is almost identical to my kernel - close enough
that the difference definitely won't affect booting.  So presumably the
config is different.
It seems that qtmoko uses an initrd where as I don't.  That might cause
confusion.  If you take the defconfig from the qtmoko tree and build my
kernel with it, it might then work.  Or maybe you could turn off the
dependence on an initrd, I don't really know how that works for qtmoko.


> 3.) Where are the various distributions (SHR, Replicant (although android requires some extra kernel modifications) etc) getting their kernels from? Do we have a controlled kernel release process (master repository, controlled push and merging, build and release processes - one place to put and get built kernels and modules from)? If we don't, should we start moving towards one? As much as I love geekdom, I find the whole git thing a bit anarchic - at some point the whole thing needs to be tied together into a coherent release system. Are we at that point now? Are we waiting for everything to be mainlined? What should we do in the short term if we are heading towards mainlining?
> 

If you see a need, the best thing to do is try to fill it yourself :-)

I think qtmoko does have a coherent release system.  But if you want to run a
kernel from elsewhere you are naturally outside that system.
Ditto for SHR and Replicant.

The way this works in "the real world" is that kernel.org gets that latest
kernel from Linus, then every distro grabs that whenever they want, makes
whatever changes they need, and hopefully feed those changes back into the
kernel.org distro.  Then they start again for the next release.
No distro (that I'm aware of) actually runs a pure kernel.org as their main
supported kernel.

The same thing is happening here.  I'm making kernel.org kernels available
with the extra bits to work on a GTA04.  Distros pick the versions they want
and modify as appropriate.  If they add generally useful patches they feed it
back to me.

If you want to run a generic kernel on your distro, you might need to put a
bit of work into it, as you are finding.  I'm guessing that all you need is
the use the qtmoko defconfig file.

If any distro wants to publish their defconfig file in my repo so that it is
easily available to others I'm perfectly happy to do that.  I'll probably
even update it for each new release.  You could even start the ball rolling
by sending me a working config if you manage to get one of my kernels running
under qtmoko.

NeilBrown

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20120726/35e10dc9/attachment.bin>