ImprovedSubarchitectureDetection

  • Launchpad Entry: other-arm-natty-improved-subarch-detection

  • Created: May 4th, 2010

  • Contributors: Michael Casadevall

  • Packages affected: libdebian-installer, base-installer, debian-cd infrastructure, ubiquity, flash-kernel

Summary

The current sub-architecture detection mechanism limits installation to the set of boards targeted for a release, and post-release updates are quite difficult. This is a significant concern for armel, where it is common for each board to require a separate sub-architecture to handle variation in kernels and boot mechanisms. This shall be replaced with a more flexible framework to ease support for devices that become available post-release.

Release Note

Ubuntu on ARM now includes a more generalised sub-architecture detection framework, allowing boot-time specification of sub-architecture to ease installation for devices not predefined in the release.

Rationale

The current sub-architecture detection is based on the Hardware field from /proc/cpuinfo. This is board-specific, and causes installation on otherwise compatible boards to fail when the underlying code is correct. Making the detection code more flexible allows the images to be used on any board for which the kernel is known compatible without changes to the installer source code.

Assumptions

  • All devices sharing a sub-architecture have a compatible boot mechanism.
  • A single kernel binary is suitable for all devices sharing a sub-architecture.
  • Users wishing to take advantage of the generalised mechanism are able to modify the image sufficiently to provide hints to the sub-architecture detection code.

Design

Where the current mapping between known boards and sub-architectures fails, the fallback option will check for additional hinting mechanisms to detect the appropriate sub-architecture to use during the install. These hints shall include the contents of /proc/soc-info (if available), the kernel name and the kernel command line.

Implementation

The current white-list will continue to exist in libdebian-installer, and exist as the canonical source of board->subarchitecture lookups. In cases where that lookup fails, d-i should attempt to check the kernel command line for a specific subarch line which will become the the subarchitecture used in-place of unknown. Should no kernel command line be found, the kernel version string will be searched for the subarch as it exists on official kernels such as 2.6.37-1-omap

Current image builds for ARM should set subarchitecture=*subarch*, as its a safe assumption that if a board can boot a pre-existing image, it is a member of that subarchitecture.

d-i and ubiquity will display a warning that the installer is using a generic fallback for kernel/initramfs installation, and doesn't promise that the resulting installation will be usable.

flash-kernel will develop generic fallbacks on sub-architectures where it is reasonable to assume such a fallback is safe to implement (dove, omap, omap4; imx51 is likely going to be difficult to have a generic fallback if it is using SD cards to boot due to varied bootloaders on this subarchitecture). These generic fallbacks should also set the subarchitecture kernel command line option unless a more accurate detection mechanism becomes available.

Code Changes

  • libdebian-installer
    • - Needs fallback code to look for the subarchitecture if the board whitelist isn't matched
  • debian-cd
    • - Default command line of ARM images
  • flash-kernel
    • - Needs generic fallback implementation
  • flash-kernel-installer
    • - Needs generic fallback - Needs to signal a warning if a board isn't whitelisted

Migration

No migration is expected for libdebian-installer, debian-cd, or flash-kernel-installer, as these are typically used only at install time, and not present on installed systems.

The new flash-kernel code will be tested through upgrade testing from lucid for boards known to be working in maverick to ensure that no device is rendered unbootable from these changes.

Test/Demo Plan

Primary testing will be through regular installation testing on targeted platforms.

Testing of hinting mechanisms will be encouraged if hardware can be identified that would benefit from such hinting pre-release, prior to adding such hardware to the whitelists. Additional testing on otherwise unsupported hardware will be solicited from subscribers to the ubuntu-mobile@lists.ubuntu.com mailing list.

Upgrade testing will be performed as discussed in Migration above.

Unresolved issues

  • No explicit protection will be offered to users who attempt to use incorrect sub-architecture hinting: it is hoped that the kernel will not boot in such circumstances, or the bootloader initialisation does not overwrite any hardware-critical data.
  • There will be no extensive generalisation of bootloader initialisation frameworks, so subtle differences may cause otherwise compatible boards using the same SoC to fail to install using this sub-architecture detection mechanism.

BoF agenda and discussion

Current installer looks into /proc/cpuinfo
Dove X0 DB board and Avengers board look exactly same from /proc/cpuinfo        


 * current status is: individual whitelisting of boards is required
 
 * ongoing discussions on adding /proc/soc-info
  * http://lkml.org/lkml/2010/5/11/380
  * Looks like Russell may be receptive to this idea: http://lkml.org/lkml/2010/5/11/171

 * using kernel version to detect sub-architecture
 ** if the kernel can boot on a system, it can also set the current sub-arch
 
 3 changes for new platform
 * libdebian-installer
 * flash-kernel
 * base-installer

Example of the lookup table in libdebian-installer:
    { "co-EBSA285" , "netwinder" },
    { "Compaq-PersonalServer" , "netwinder" },
    { "Freescale MX51 Babbage Board", "imx51" }, /* iMX51 reference hardware. */
    { "Marvell DB-MV88F6781-BP Development Board", "dove" }, /* Marvell Dove SoC */
    { "OMAP3 Beagle Board", "omap" }, /* first OMAP hw platform, more to come */
    { "ADS" , "ads" }, /* Matches only ADS boards. Put any exceptions before. */
    { "Applied Data Systems" , "ads" }, /* More ADS boards. */
    { "Marvell DB-88F6281-BP Development Board", "kirkwood" },
    { "Marvell RD-88F6192-NAS Development Board", "kirkwood" },
    { "Marvell RD-88F6281 Reference Board", "kirkwood" },

Action Items:
 * Override subarchitecture based on kernel command line, or maybe kernel version string
 * get subarch exposed in /proc/cpuinfo - or /proc/soc-info?
 * flash-kernel should look for a specific board lookup, if not found, go to a subarch generic detectoin (which isn't promised to work, but may work better than what is currently there)
 * DeviceTree will help in improving subarchitecture detection by passing in information on what hardware is supported
 * Have the installer show a warning that its on a generic fallback


CategorySpec

Specs/ARM/ImprovedSubarchitectureDetection (last edited 2010-11-16 10:17:59 by 076-076-148-180)