Skip to content

CentOS on ARM SBC design considerations

Uli Middelberg edited this page Jul 5, 2016 · 4 revisions

CentOS on ARM SBC design considerations

Boot loader

Most boards still support u-boot only (no EFI support available at this time).

  • mainline u-boot vs. vendor/BSP u-boot?
  • chainloading GRUB (not applicable on Aarch64) as an alternative?

=> Taking the vendor's u-boot seems to be the most reasonable solution.

Disk layout

  • VFAT for u-boot environment (/bootenv, 4 M), (when needed, e.g. for the Pine64)
  • EXT4 for boot partition (/boot, 128 M), (u-boot does not support XFS and VFAT doesn't support symbolic links), with journaling disabled
  • XFS for root file system (instead of ext4), with MMC optimized journaling
  • Disable swap for MMC based devices (using ZRAM as an alternative)
  • MBR in favour of GPT (stock u-boot probably doesn't know much about GPT)

Kernel

###Option 1.: Vendor/BSP kernel

  • Extensive device support
  • HW acceleration
  • Vendor/community support

###Option 2.: CentOS upstream (LTS) kernel?

  • compatibility

###Option 3.: Mainline kernel?

  • recent features (e.g. UAS)
  • security fixes
  • growing SBC support

=> Suggestion: First option 1, second option 3 (if available) -> finally Option 2 after SBC has reached mainline support.

Degree of customization

defaultconfig

  • minimal/standard set of common kernel options (mandatory) CentOS relies on
  • recommended options which are useful but not essential (e.g. support for various USB devices)

Something like Docker's check-config.sh would be very helpful. Boards which have reached mainline kernel support come along with a tiny defconfig (hundreds of lines) while config-4.2.3-200.el7.armv7hl has more than 3000 entries.

####Patches from CentOS upstream (option 1 and option 2)?

  • compatibility
  • QA effort (no one else is probably using this kernel)?

####multidevice kernel package (e.g. one package for all ARMv7 devices)

  • only for mainlined devices, for which the CentOS standard kernel is applicable
  • CM/QA effort?

Default settings

  • device tree (e.g. optimized for headless usage, saves RAM)
  • kernel parameters
  • root with password disabled
  • centos with password '...' and sudo capability
  • keyboard
  • i18n
  • timezone
  • network devices
  • ...

Build process

  • firmware image
    • SPL, u-boot, u-boot environment
    • partition stubs for /bootenv and /boot
  • 'official' universal / minimalistic root file system available as .tar.xz
  • kernel image (rpm package?)
  • board specific configuration/tweaks/libraries (X11, Audio, Wifi, BT, GPIO, etc.) (rpm package?)
  • automated assembly procedure / toolset?

Configuration upon first boot

  • set password for user CentOS
  • resize /
  • minimalistic installer, e.g. for timezone, i18n, ...
  • extensive README (e.g. how to set-up graphic environment, install different roles/profiles)

Organization:

  • Git Repos?
  • CI (Jenkins, Travis, ...)?
  • QA?
  • Collaboration with other initiatives like Armbian (e.g. for boot loader, BSP kernel and other HW related issues) ?