** Resending with the right lists **
after talking at devconf with David Cantrell about the best way to support setting up uboot on arm devices in anaconda, the best approach going forward is pretty clear, ill get to it in a bit first i want to describe things as I see them.
Unified kernel while solving many issues introduces some. platform detection was kinda simple with separate kernels. unified kernel means that while we dont need to worry about having the right kernel, we do need to worry about loading the right dtb.
platform detection is also needed to know where in ram we should load the kernel and offsets for initramfs and dtb to be loaded. anaconda can tell us the filesystem and device that we are installing to, but depending on the exact way support is done in uboot we may need to put in different values, SCSI vs SATA vs USB etc we also need to ensure we use the right dtb file. for instance a pandaboard ES can use a pandaboard dtb but will be 1ghz vs the 1.2ghz its capable of. some systems like the highbank ones have the dtb in their uboot. while others need to load an external file.
so as i see it we need a library that anaconda can import and use to work out the right values for the system we are installing to. probably the library should write out the uboot template and run mkconfig on it. we could then reuse the library in a tool to say setup a boot sdcard to run the installer on a system. we have an issue where it is really not possible to make the equivilent of a boot.iso that will be bootable everywhere.
I think we should take this up to the cross distro list at linaro and ideally have the distros work on a database at the least of platforms and the values and types needed. if not the whole library that can be used in different places to set things up.
this is only needed for 32 bit arm, 64 bit will have UEFI, ACPI and grub2. potentially we also want to consider if we can implement http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec since we need to implement something anyway.
Dennis
Thanks for sending this- some comments below.
On 02/27/2013 12:47 PM, Dennis Gilmore wrote:
** Resending with the right lists **
after talking at devconf with David Cantrell about the best way to support setting up uboot on arm devices in anaconda, the best approach going forward is pretty clear, ill get to it in a bit first i want to describe things as I see them.
Unified kernel while solving many issues introduces some. platform detection was kinda simple with separate kernels. unified kernel means that while we dont need to worry about having the right kernel, we do need to worry about loading the right dtb.
Yes, though during the transition we have to worry about both! This includes loading a device specific kernel at the start of a release, but loading a unified kernel during the support cycle of the same release. As an example, we have kernel-highbank-3.6.x in Fedora 18 GA, but it's a unified kernel in 3.8.
platform detection is also needed to know where in ram we should load the kernel and offsets for initramfs and dtb to be loaded. anaconda can tell us the filesystem and device that we are installing to, but depending on the exact way support is done in uboot we may need to put in different values, SCSI vs SATA vs USB etc we also need to ensure we use the right dtb file. for instance a pandaboard ES can use a pandaboard dtb but will be 1ghz vs the 1.2ghz its capable of. some systems like the highbank ones have the dtb in their uboot. while others need to load an external file.
It's important that anaconda have this information, but this data needs to be available outside of anaconda as well, suggesting a library....
so as i see it we need a library that anaconda can import and use to work out the right values for the system we are installing to. probably the library should write out the uboot template and run mkconfig on it. we could then reuse the library in a tool to say setup a boot sdcard to run the installer on a system. we have an issue where it is really not possible to make the equivilent of a boot.iso that will be bootable everywhere.
Agree. As I mentioned in private emails, I favor in-uboot auto-detection with hush scripts in a combined /etc/uboot.d, but this might be too limited to support some eccentricities (Your panda vs panda-es example is tricky). If you do most of the dirty work inside uboot itself you have a better chance of making a unified Fedora image.
Do you see this library as a new package or an extension to an existing package? Right now we have some uboot information embedded in grubby in a not-entirely-satisfactory way. I think a new package that grubby and anaconda require on arm on would be preferable.
I think we should take this up to the cross distro list at linaro and ideally have the distros work on a database at the least of platforms and the values and types needed. if not the whole library that can be used in different places to set things up.
The Ubuntu guys have (had?) flash-kernel (https://launchpad.net/flash-kernel), but it's not entirely satisfactory IMHO. Seems a bit dated though- perhaps they've moved on to some other db.
this is only needed for 32 bit arm, 64 bit will have UEFI, ACPI and grub2. potentially we also want to consider if we can implement http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec since we need to implement something anyway.
Agree. One other thought I've been kicking around is to get grub2 configuration management up and running (without actually installing the bootloader), then reparse the grub.cfg to create a viable boot.scr. This would make transitioning to UEFI easier.
The goals for this endeavor that I can see:
1. Seamless handling of kernel updates on ARM for any Fedora release. The end user should be able to update (or remove) a released kernel and have their system continue to function assuming at least 1 kernel is installed.
2. Ship a single unified prebuilt image for the widest range of systems possible: In Fedora 19, provide a single prebuilt image that supports vexpress, highbank, trimslice and panda, with and without X (Subject to kernel support for X of course). Beagle* would require manual MLO replacement. If MVEBU (Armada XP) support lands in time that'd be nice too.
3. Ship a single unified prebuilt anaconda installer image: In Fedora 19, provide a single prebuilt anaconda installer image to support anaconda-style installations on Highbank, Trimslice, and MVEBU (if kernel support lands in time).
On 03/04/2013 04:40 PM, Brendan Conoboy wrote:
Agree. As I mentioned in private emails, I favor in-uboot auto-detection with hush scripts in a combined /etc/uboot.d, but this might be too limited to support some eccentricities (Your panda vs panda-es example is tricky). If you do most of the dirty work inside uboot itself you have a better chance of making a unified Fedora image.
Do you see this library as a new package or an extension to an existing package? Right now we have some uboot information embedded in grubby in a not-entirely-satisfactory way. I think a new package that grubby and anaconda require on arm on would be preferable.
For those who are interested I've put together a proof of concept of the above at placed it on my people page:
http://people.fedoraproject.org/~blc/fedora-arm/gruboot/
There is a readme in the tarball, but briefly: Running gruboot will regenerate your boot.scr with a significantly more sophisticated version using hush scripting. The new version autodetects the kind of system you are using and generates menus for all the kernels and dtbs you have installed. While it nominally provides support for trimslice, panda*, beagle*, highbank, and armadaxp I've only tested it on trimslice with both bootm and bootz. Feel free to try it out and send feedback. If this is a path we want to go down we will need to integrate with either the kernel or grubby package such that it is called after every kernel is installed or uninstalled. And a new name would be nice, too. Anybody who finds a bug or makes an enhancement is welcome to suggest a better name ;-)
-
Brendan Conoboy -
Dennis Gilmore