[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sarge kernel frozen (2.4.27 and 2.6.8), and plans for post-sarge powerpc kernels.



Dropping debian-boot, as i don't think further discussion concerns them.

On Mon, Apr 04, 2005 at 09:58:05AM +0200, Gabriel Paubert wrote:
> > Plans on my part for 2.6 powerpc kernels are : 
> > 
> >   1) abandonement of the ppc32 power3 and power4 kernels in favour of ppc64
> >   variants.
> 
> Fine, I don't have any of these, but the rule becomes 64 bit processors
> must run 64 bit kernels looks sane.

Yep. current ppc32 power3/4 kernels don't even get build-tested it seems, as
2.6.11 was broken on them out of the box :)

> >   2) migration to a common and single kernel package for all arches.
> 
> What do you mean?

Single source package building all the kernel of a given version. See what i
did for the 2.4.27 kernel, it now builds kernels for apus, nubus, and the
standard powerpc stuff.

> Some PPC variants are so fundamentally incompatible that a single 
> kernel is impossible (completely different MMU). So you mean putting 
> several kernel images in a single debian package?

no, just putting them in the same source package, so making the building of
upgraded kernel for security or bugfix reason less of a headache. All fixes in
2.6 currently go into kernel-source-2.6.11 anyway.

The current aim is to distinguish in a given kernel version, between arches,
subarches (which need individual kernel patches) and flavours (which need
incompatible config options, like powerpc/power3/power4 and smp/non-smp).

> OTOH, I'd like to see PowerPlus and MVME5100 being considered
> as PreP and not specific. I don't have MVME5100 but 2[467]00 series,
> the only real difference is the memory map at boot. My bootloader 
> actually remaps my board to look like an MVME5100 because it 
> gives more room to map the VME bus and nobody needs 1GB of PCI
> I/O space.

Would be nice, currently the debian kernels produce only the plain toplevel
vmlinux, and the mkvmlinuz tool is used to take the object files in
arch/ppc/boot and create the needed images, currently pmac, coff, chrp (which
is chrp-rs6k), prep and ppcbug, if i am not mistaken. Adding support for the
above would only be a matter of adding the needed code to the mkvmlinuz shell
script, which is invoked cleanly at install time.

Patches against mkvmlinuz for PowerPlus and MVME5100 are welcome, as are
bug reports against the 2.6.11 and beyond kernel packages to fix the config
options needed for those arches.

> >   3) forward porting of the above mentioned patches and inclusion in the main
> >   2.6 kernels.
> > 
> >   4) work on some way to move the serial console and other fbdev drivers to
> >   modules which are loaded as early as possible from the ramdisk, to further
> >   reduce the size of the kernel.
> 
> Great. 
> 
> > 
> >   5) maybe start including some embedded kernels, depending on availability of
> >   hardware and interest.
> 
> As I said above, some embedded CPU really need different mm handling.
> BookE is an abomination, and fun with the 64 bit BookE implemetations
> if they come one day: they use different instruction encoding than
> standard PPC64.

So, they just need a different kernel config, and maybe a couple of patches to
be merged, and will produce a separate kernel-image file.

> > Anything else needed for the powerpc post-sarge kernels, please comment here.
> 
> As said above, I might try to push upstream patches to merge PreP,
> PowerPlus and MVME5100. But these are not really embedded boards,
> except for memory size (I have to run in 16MB, root on NFS, no disk,
> no swap, serial console only). I'm starting this week to resurrect 
> my old bootloader which included an x86 emulator to initialize VGA 
> boards by running their BIOS code.

Ok, patches welcome. My motorola powerstack II is also broken in 2.6.11, but i
am hunting that stuff.

> However, I'll still compile my kernels. So I don't care very much
> about what you put in the package.

The idea is that you would then have a debian-installer image, so you can
netboot it and do the installation, and then if need be, recompile your own
kernel. Custom d-i images are more difficult than in the past, but i guess you
probably just debootstrap the disks or upgrade from older versions.

Friendly,

Sven Luther



Reply to: