RFC: Replacing ixp4xx-kernel with style-compliant updated linux-ixp4xx

RFC: Replacing ixp4xx-kernel with style-compliant updated linux-ixp4xx

[Rod Whitby]

Now that SRCREV is assumed available in bitbake and OE, it is time to
revisit the ixp4xx-kernel recipes and use modern-day ways of doing things.

To accomplish this, I intend gradually replacing the ixp4xx-kernel
recipes with linux-ixp4xx recipes which more closely follow OE best
practices, and allow for sensible usage of linux-ixp4xx kernel recipes
for all ixp4xx devices (not just those used by nslu2-linux firmware).

For example:

1) Use SRC_URI and SRCREV to pull down the ixp4xx kernel patchset from
nslu2-linux.org, in the same way that linux-openmoko does it, instead of
doing in an nslu2-linux-specific way.

   The main advantages here are that the patchset tarball will be
permanently stored on the downloads mirror, and we can use sane-srcrevs
to control the svn revision of the patches that is used.  This removes
the complaint that OE is dependent upon a third-party svn repository.

2) Use the new linux.inc and remove the stuff that it already does

   The main advantage here is to do things the same way as other linux
recipes do, by including the same linux.inc file.  This also gives us
the opportunity to start to migrate things from linux-ixp4xx.inc to
linux.inc if they are applicable to a wider range of machines (e.g. the
endian patch I submitted earlier today).

3) Remove the python code which automatically determines the SRC_URI

   It's clear that this type of automation is not welcome, and has not
been used recently to it's full effect anyway, so we'll just remove it.

4) Move the arm-kernel-shim stuff out to a separate file or class,
instead of it being always part of ixp4xx kernel builds.  This stuff
should only happen when MACHINE is a variant of nslu2 with a stupid
bootloader, not when you're building for ixp4xx machines which have
sensible bootloaders (either a sensible vendor bootloader, or a
replacement Apex bootloader).  So it's probably a DISTRO thing, rather
than a MACHINE thing.

This will happen over the coming weeks, and I'll make sure the whole set
of linux-ixp4xx recipes and supporting files are in place well before
removing or changing any of the existing ixp4xx-kernel recipes.

Comments welcome.

-- Rod

Re: RFC: Replacing ixp4xx-kernel with linux-ixp4xx

[Rod Whitby]

Rod Whitby wrote:
> Now that SRCREV is assumed available in bitbake and OE, it is time to
> revisit the ixp4xx-kernel recipes and use modern-day ways of doing things.
> 
> To accomplish this, I intend gradually replacing the ixp4xx-kernel
> recipes with linux-ixp4xx recipes which more closely follow OE best
> practices, and allow for sensible usage of linux-ixp4xx kernel recipes
> for all ixp4xx devices (not just those used by nslu2-linux firmware).
...
> This will happen over the coming weeks, and I'll make sure the whole set
> of linux-ixp4xx recipes and supporting files are in place well before
> removing or changing any of the existing ixp4xx-kernel recipes.

Well, I had a spurt of productivity last night, and can build angstrom
using the new linux-ixp4xx kernel, so I've checked in linux-ixp4xx
replacements for all the old ixp4xx-kernel recipes.

I'll wait a reasonable time for review and testing of the new recipes
before removing any old ixp4xx-kernel recipes (and will double check
that nothing else is still using them before doing so).  I will mail
again with a notification before doing so.

Style comments on the new linux-ixp4xx kernel recipes are welcome.
(I guess I should have run them through oe-style-thingo before saying
that ...)

-- Rod

Re: RFC: Replacing ixp4xx-kernel with linux-ixp4xx

[Leon Woestenberg]

Rod,

On Nov 28, 2007 7:03 AM, Rod Whitby <rod@whitby.id.au> wrote:
> Rod Whitby wrote:
> Well, I had a spurt of productivity last night, and can build angstrom
> using the new linux-ixp4xx kernel, so I've checked in linux-ixp4xx
> replacements for all the old ixp4xx-kernel recipes.
>
Just wanted to say thank you.

I would like to devote some of my time to trace down any .22 and .23
issues that hold back the release. I am eager to get the (recent)
realtime patches to run on this platform.

Regards,
-- 
Leon