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
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
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
On Wed, Jul 21, 2010 at 6:53 PM, Bernhard Schuster schuster.bernhard@googlemail.com 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
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
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
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
2010/7/21 Dan Horák dan@danny.cz
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)
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
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
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
On Wed, Jul 21, 2010 at 7:32 PM, Andy Green andy@warmcat.com 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
-
Adam Miller -
Andy Green -
Bernhard Schuster -
Dan Horák -
Peter Robinson