Peter:
Regarding your query on #fedora-arm last week...
I have been working on installer options for ARM, and have been testing
some of this on a couple of different platforms. I have posted
information regarding this on the Wiki:
http://fedoraproject.org/wiki/Architectures/ARM/Installer
http://fedoraproject.org/wiki/Architectures/ARM/Anaconda
Through this effort I have made a few observations.
1) We currently support two basic types of installations for ARM, image
creation (livemedia-creator) and kickstart installs (anaconda). Which
is used will depend on the specific platform, for example highbank would
typically use a kickstart install where omap and tegra would use an
image creation, although highbank may still use image creation.
NOTE: Both types require a kickstart file to drive the installation.
Neither currently supports interactive installations. This would
require full U-Boot support in anaconda for all supported platforms.
2) There is little in common in the U-Boot environment among the various
ARM platforms. The specific load commands, load addresses, etc. vary
widely, as does support for device-tree.
3) Adding U-Boot support into anaconda will require a lot of
platform-specific details, which adds to the maintenance issue as
platforms are added or details change.
4) Even if we have the above mentioned U-Boot support included in
anaconda, it will not address the differences between boards of a given
platform, i.e., for OMAP - BeagleBoard, BeagleBone, Panda, etc.
5) While we could include some default image for each platform, we can't
provide support for all variants that users may desire, for example,
Trim Slice can be installed on SDCard (mmc) or hard drive (usb), but we
can only provide one 'default' image for 'tegra' in anaconda.
5) Changes to U-Boot itself would also require corresponding changes in
anaconda, for example adding uEnv.txt or bootz support (again, a
maintenance issue).
Based on these observations, I'd like to suggest that we consider our
approach and look at alternatives that would 1) be readily accepted
upstream, 2) be supportable/maintainable, and 3) meet the installation
needs of the community. Just to summarize some possible approaches:
1) Include support for all ARM platforms in Anaconda (U-Boot classes)
2) Use the %post script in Kickstart to configure for U-Boot
3) Hybrid approach (some support in anaconda, and the remainder in
kickstart)
4) Use 'generic' platform images and a separate 'deployment tool' for
board specific images.
Each of these approaches has pros and cons, some mentioned above.
Currently we are using #2 (%post script in Kickstart). It works well
enough for some boards, and can be board-specific without any changes to
anaconda. The biggest issue so far is that it will not support the OMAP
boards, due to partition issues (first partition must be VFAT and
include MLO and U-Boot). I'm sure we would encounter similar issues on
some other boards (i.e., *plugs)
I would like us to consider two approaches...
#3 - Hybrid approach, add only "minimal" U-Boot support to anaconda
(i.e., set up a uboot partition for OMAP), but not populate the U-Boot
partition or set up the boot.scr. These 'board specific details' could
be kept in the kickstart file %post script. This would keep anaconda
"cleaner" (less platform-specific code) and remain flexible, by adding
or changing board-specific support in the kickstart scripts.
#4 - Deployment Tool would not require any U-Boot support in anaconda,
but instead would create a 'standard format' image (one that includes
the 'platform' bits, e.g. correct kernel, but not the board-specifics)
and would use a deployment tool like the one Jon Chiappetta did for the
Raspberry Pi to create the actual 'image' (board-specific partitions,
loader/u-boot, device tree, etc.) This would only be needed for boards
that use the livemedia-creator images. Perhaps the Raspberry Pi
deployment tool could be updated to handle other boards as well.
I understand that neither of these two approaches would support
interactive installations, but I don't see this as a huge issue at this
time, since most of the current platforms either would not support a
full anaconda install running natively anyway (resource constraints) or
will typically be installed via PXE-boot/kickstart in a server environment.
I think either of the last two approaches could work for us, and provide
a supportable yet flexible approach for creating images for ARM systems
which use U-Boot. Please share you thoughts on these, and possibly
other approaches that we should consider. Hopefully we can come to a
consensus on an approach to implement for F18.
Thank you,
d.marlin
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
