Installer support for U-Boot
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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-Boot3) 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