[fedora-arm] Kernels for common arm devices

[Andy Green]

On 07/21/10 21:18, Somebody in the thread at some point said:

Hi -

>> What're you thinking about there in terms of "cooperation with the
>> bootloader and boot device"?
>
> the normal sequence is kernel rpm =>  grubby =>  bootable kernel on
> device, but on ARM platforms there are multiple bootloaders and they
> support different device to boot from

Yes the bootloader is the guy who chooses where the kernel image is to 
come from and what name it'll have, and it'd be a loser on arm platforms 
to make assumptions about that; it's not like just having grub in all 
cases and /boot/grub/grub.conf.  Unfortunately the bootloader doesn't 
publish a path where it got the kernel from to the kernel itself.

The physical platform, based on what bootloader / bootloader state it 
can be expected to have, is in control of where the kernel image needs 
to be dropped in the filesystem, even if it's a common SoC shared with 
other platforms.

> I think we need to divide the devices first - there are developer
> devices like *Plug or BeagleBoard and then there are commercial devices
> like QNAP NAS etc. The commercial ones can be based on development
> boards, but their configuration capabilities are limited.

Well real devices will have special peripherals and stuff that need 
specific support, I guess often it can be modularized fine but not always.

>> A related issue I found is that the package name "kernel" seems to be
>> magic.  I tried making my xxx-kernel package Provides: kernel-2.6.blah,
>> but it wasn't enough.  If it isn't fixed (possibly already, this was in
>> F12 time), that might get a bit messy with a bunch of
>> identically-named-and-arched binary packages for the different board
>> kernels.
>
> If I remember correctly then Debian provides one kernel per SOC and we
> should do the same, have per-SOC subpackages built from one kernel
> source package. If they can be integrated with the primary kernel
> package, I can't tell.

Sounds good but I mentioned it because yum could not solve the initial 
packageset if the base name for the kernel package was anything other 
than "kernel".  What's the plan for tagging these binary kernel packages 
with SoC names in a reliable way, ie, what will those package names look 
like then if they all have "kernel" basename?

> Also having a relatively tiny kernel and the rest in initramfs (dracut
> is an invaluable tool for ARM) helps to include as many devices and boot
> styles as possible.

It makes sense from a distro POV.

IIRC there's some kconfig business where you can bind an initramfs to 
the kernel image itself.  If you don't take that approach, you are into 
requiring the bootloader knows where the initramfs is according to the 
bootloader's partition scheme and to pull it in and tell the kernel to 
use it; some bootloaders might not be that configurable or capable.  It 
seems especially dodgy if "grubby" is going to sed the U-Boot 
environment or whatever.   (Even then the crazy U-Boot environment 
scheme usually has a hardcoded image size given in there, eg, it only 
pulls the first 2MB of a kernel and drops dead if the kernel is any bigger).

-Andy