Kernels for common arm devices

[Peter Robinson]

Hi All,

With the ARM secondary arch slowly ramping up and more cheap arm
devices becoming available I think it would be useful to provide some
ARM kernel images for some common devices out there to make it easier
for developers and testers to get involved without having to compile
their own kernel first. How hard would this be to do, sort of like
i386 provides a PAE and non PAE kernel.

I think the 3 devices that would be a good start are the ones that are
already running in the koji instance as they are commonly available
and someone has obviously done the work to work out what is needed.

> From there the other devices that come to mind are the Nokia n900
(should be able to borrow the kernel config from MeeGo) and
BeagleBoard (I think MeeGo has one for this too). It might even be
possible to use the MeeGo kernels with a Fedora rootfs.

Thoughts?

Cheers,
Peter

[Adam Miller]

I really like this idea, I think it will make widespread distribution and
adoption of Fedora much easier for those interested. What all would need
doing in terms of logistics and planning for providing this sort of thing or
is it really just a simple "compile different kernel packages"?

-AdamM

[Bernhard Schuster]

I think its better to start off with BeagleBoard/GuruPlug/SheevaPlug and
alike instead of focusing on mobilephones. There are allready a lot linux
based (successfull) OSes out and have pretty good shape. I think the focues
should be on "hackaway gadgets" (as BeagleBoard/...) and multi usage
devices.

I would be willing (with help of some mastermind) to setup, update, keep
updated a rootfs/kernel/howto for guruplug server plus.

Regards

Bernhard

[Peter Robinson]

On Wed, Jul 21, 2010 at 6:53 PM, Bernhard Schuster
<schuster.bernhard(a)googlemail.com&gt; wrote:
>  I think its better to start off with BeagleBoard/GuruPlug/SheevaPlug
> and
>  alike instead of focusing on mobilephones. There are allready a lot linux
>  based (successfull) OSes out and have pretty good shape. I think the focues
>  should be on "hackaway gadgets" (as BeagleBoard/...) and multi usage
>  devices.
>  I would be willing (with help of some mastermind) to setup, update, keep
>  updated a rootfs/kernel/howto for guruplug server plus. 
Marvell released an open source installer for their sheeva plugs.

http://www.linuxfordevices.com/c/a/News/Marvell-Easy-Plug-Computer-Installer

Peter

[Dan Horák]

Adam Miller píše v St 21. 07. 2010 v 11:44 -0500:
>  I really like this idea, I think it will make widespread
> distribution
>  and adoption of Fedora much easier for those interested. What all
>  would need doing in terms of logistics and planning for providing this
>  sort of thing or is it really just a simple "compile different kernel
>  packages"? 
building the kernel is only one part (and it can be solved with multiple
kernel packages built from different configs), but the more tricky part
is the cooperation with the booloader and boot device ...


		Dan

[Bernhard Schuster]

I doubt it is possible to provide for, even only *Plug/BeagleBoard a kernel
rpms. At least *Plugs use a cut down version of uboot, which only (I did not
see anything else) supports kernel flashing from tftp.
I think it is only possible to achieve the goal of multiple platforms with
setup howto for each pseudoplatform and a base rootfs with bash, tty, ssh,
and other "basic" components plus maybe some package groups like
"guruplug",
"sheevaplug" to enable full support of each devices functionality.

Regards

Bernhard

[Dan Horák]

Bernhard Schuster píše v St 21. 07. 2010 v 20:20 +0200:
>  I doubt it is possible to provide for, even only *Plug/BeagleBoard a
>  kernel rpms. At least *Plugs use a cut down version of uboot, which
>  only (I did not see anything else) supports kernel flashing from tftp.
>  I think it is only possible to achieve the goal of multiple platforms
>  with setup howto for each pseudoplatform and a base rootfs with bash,
>  tty, ssh, and other "basic" components plus maybe some package groups
>  like "guruplug", "sheevaplug" to enable full support of each
>  devices functionality. 
on sheevaplug I have a kernel and initramfs (made by dracut) on ext3
partition of a SD card, so it looks like a normal PC, little hacking to
the uboot config was needed, but nothing much special 
and Debian has a flasher for a range of commercial devices (submitted
for review https://bugzilla.redhat.com/show_bug.cgi?id=548422)


Dan

[Bernhard Schuster]

2010/7/21 Dan Horák <dan(a)danny.cz&gt;

>  Bernhard Schuster píše v St 21. 07. 2010 v 20:20 +0200:
>  > I doubt it is possible to provide for, even only *Plug/BeagleBoard a
>  > kernel rpms. At least *Plugs use a cut down version of uboot, which
>  > only (I did not see anything else) supports kernel flashing from tftp.
>  > I think it is only possible to achieve the goal of multiple platforms
>  > with setup howto for each pseudoplatform and a base rootfs with bash,
>  > tty, ssh, and other "basic" components plus maybe some package groups
>  > like "guruplug", "sheevaplug" to enable full support of each
>  > devices functionality.
>
>  on sheevaplug I have a kernel and initramfs (made by dracut) on ext3
>  partition of a SD card, so it looks like a normal PC, little hacking to
>  the uboot config was needed, but nothing much special
>  and Debian has a flasher for a range of commercial devices (submitted
>  for review https://bugzilla.redhat.com/show_bug.cgi?id=548422) 

Guruplugs marvell edited uboot version does not provide sdcard access from
uboot. Only USB boot support as far as I can tell (using latest git)

[Andy Green]

On 07/21/10 19:06, Somebody in the thread at some point said:
>  Adam Miller píše v St 21. 07. 2010 v 11:44 -0500:
> > I really like this idea, I think it will make widespread distribution
> > and adoption of Fedora much easier for those interested. What all
> > would need doing in terms of logistics and planning for providing this
> > sort of thing or is it really just a simple "compile different kernel
> > packages"?
>
>  building the kernel is only one part (and it can be solved with multiple
>  kernel packages built from different configs), but the more tricky part
>  is the cooperation with the booloader and boot device ... 
What're you thinking about there in terms of "cooperation with the 
bootloader and boot device"?

Either the kernel is configured to use a built-in commandline which 
isn't very flexible, or those configuration elements are coming from the 
bootloader on a kernel commandline.  If it's the latter case, it's out 
of scope for a kernel package to change that.

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.

-Andy

[Dan Horák]

Andy Green píše v St 21. 07. 2010 v 19:32 +0100: 
>  On 07/21/10 19:06, Somebody in the thread at some point said:
>  > Adam Miller píše v St 21. 07. 2010 v 11:44 -0500:
>  >> I really like this idea, I think it will make widespread distribution
>  >> and adoption of Fedora much easier for those interested. What all
>  >> would need doing in terms of logistics and planning for providing this
>  >> sort of thing or is it really just a simple "compile different kernel
>  >> packages"?
>  >
>  > building the kernel is only one part (and it can be solved with multiple
>  > kernel packages built from different configs), but the more tricky part
>  > is the cooperation with the booloader and boot device ...
>  
>  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

>  Either the kernel is configured to use a built-in commandline which 
>  isn't very flexible, or those configuration elements are coming from the 
>  bootloader on a kernel commandline.  If it's the latter case, it's out 
>  of scope for a kernel package to change that. 
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.

>  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.

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.


Dan

[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

[Peter Robinson]

On Wed, Jul 21, 2010 at 7:32 PM, Andy Green <andy(a)warmcat.com&gt; wrote:
>  On 07/21/10 19:06, Somebody in the thread at some point said:
> > Adam Miller píše v St 21. 07. 2010 v 11:44 -0500:
> >> I really like this idea, I think it will make widespread distribution
> >> and adoption of Fedora much easier for those interested. What all
> >> would need doing in terms of logistics and planning for providing this
> >> sort of thing or is it really just a simple "compile different kernel
> >> packages"?
> >
> > building the kernel is only one part (and it can be solved with multiple
> > kernel packages built from different configs), but the more tricky part
> > is the cooperation with the booloader and boot device ...
>
>  What're you thinking about there in terms of "cooperation with the
>  bootloader and boot device"?
>
>  Either the kernel is configured to use a built-in commandline which
>  isn't very flexible, or those configuration elements are coming from the
>  bootloader on a kernel commandline.  If it's the latter case, it's out
>  of scope for a kernel package to change that. 
I'm not sure about much of the bootloader issue but does any of the
stuff that Ubuntu and others are doing though Linaro any help?

Some details

http://lwn.net/Articles/364654/
http://lwn.net/Articles/391189/

Peter