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).
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
_______________________________________________
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
