Runtime Machine Configuration (RMC) -------------------------------------------------------------------------------- Table of Contents Introduction Usage Enable RMC Feature Examples Troubleshooting When you (don't) need RMC feature Introduction: -------------------------------------------------------------------------------- RMC Project - a light-weight project provide developers a mechanism to keep their software implementation board-type agnostic, yet still able to customize software behavior according to the type of a running board at runtime. Recipes and bbclasses are available for other components to reuse to construct their own RMC database. RMC Feature - An end-to-end solution based on RMC project to have a generic image capable to apply board-type-specific quirks and configurations for a board at runtime. It consists of a modified bootloader (systemd-boot), an updated EFI installer, recipes, bbclass and RMC project. RMC feature supports special customizations cannot be covered by conventional auto-detection features based on probing a hardware module because they happen at a board or a product level. For example: - tty console for kernel log output in kernel cmdline - default audio route configuration - network configuration - UI layout - requirement to software driven by a mechanical design - or static configuration bits for a physical bus that doesn't support to identify devices or their presence at runtime An image with the feature has ability to configure supported boards with data associated only to a type of board to get full functionality of the target at runtime, yet still with a single image. Effect after installation is identical to what a conventional image specially customized for a type of board (depending on the way to deploy image). Main functions of RMC Feature: Show board-specific boot entries in boot menu and boot system with configuration (boot title, boot options, etc) in a selected boot entry. Support a "global" kernel boot command line fragment which is effective for all boot entries. Deploy file blobs and create directories specific to the type of running board. Beside from this document, you can also find several built-in examples in common/recipes-bsp/rmc/boards/. Refer to "Examples" section. You can also add new board types in your layer via a simple variable. Usage -------------------------------------------------------------------------------- Developers are suggested to organize all board-specific files in their own layer following this example, so that RMC recipes can pick up them correctly in build. - my_top_dir/ Top directory of your board (Note 0) |- rmc-db.bbappend bbappend file to rmc-db recipe at a lower level |- rmc/ |- target_board_1/ subdirectory of a board. | |- board1.fp fingerprint file must be provided (NOTE 1) | |- BOOTENTRY.CONFIG optional config file for boot entries. (NOTE 2) | |- INSTALLER.CONFIG optional config file for installer. (NOTE 3) | |- POSTINSTALL.sh optional script hook for installer (NOTE 4) | |- board_file_1 A file blob specific to the type of board | |- board_file_2 An another file specific to the type of board | |- ...more files |- target_board_2/ subdirectory of another board. |- board_2_v2.fp fingerprint file for board 2. |- BOOTENTRY.CONFIG |- INSTALLER.CONFIG |- board_file_1 |- ...more files Note 0: Developers are expected to use variable RMC_BOARD_DATA_DIRS to specify data of boards packed into RMC database file generated in a build. The default value of the variable in meta-intel specifies a group of boards. They work as examples and necessary quirks for these boards to function properly. Developers can override, append to the default boards with data of their own boards in the database file, or even disable the generation of the database file. For example, in your local.conf file: This line adds your boards along with the default boards into RMC database file, assuming you have a directory named "rmc" which has a subdirectory for each board: RMC_BOARD_DATA_DIRS_append = " /path_of/rmc" This line directs RMC to pack data of your boards only, without data of the default boards in meta-intel: RMC_BOARD_DATA_DIRS = "/path_of/rmc" And this line disables database generation: RMC_BOARD_DATA_DIRS = "" Please also refer to the "Example 1" in this document. Subdirectory is not supported in a board's directory. Note 1: Fingerprint files must be provided and with ".fp" at the end of their names. Fingerprint can be obtained by running RMC tool on your board. An easy way is to live-boot USB stick flashed with any image enabled this feature on your board, then run this command: # rmc -F -o my_board.fp Or you will need to build RMC tool for the architecture of your board, 32 or 64 bit x86, from RMC project. You can run RMC tool without any argument to get usage and examples. DO NOT NAME ANY FILE ENDING WITH '.fp' IF IT IS NOT A RMC FINGERPRINT FILE. If you do need a .fp file deployed onto target, please rename it in source and specify the real name of file on target in INSTALLER.CONFIG. Note 2: At runtime, RMC bootloader tries to fetch this file specific to the board at run time, then tries to fetch each boot entry file specified in BOOTENTRY.CONFIG and show them in boot menu options. The format of this file is very simple. Each line is the name of a boot entry file: boot.conf Install.conf myrmcboot.conf Name of a boot entry file is defined by developer so it can be anything. But the name of config file is what RMC bootloader looks up in RMC database, so it must be named BOOTENTRY.CONFIG. Bootloader skips loading entry conf files from disk once any entry is loaded from RMC database. Note 3: At runtime, RMC installer tries to fetch INSTALLER.CONFIG file specific to the board, then tries to fetch each file specified in this config file, and then deploy the file onto target with its permissions, UID, GID and other attributes also specified in this config file if file for the board can be retrieved from RMC database. The format of this file is (# is for comment line) # name:uid:gid:mode:path_on_target # to create a directory, add a “/” at the end of path_on_target: audio_policy:0:0:600:/etc/audio/ audio_def_policy:0:0:600:/etc/audio/audio_policy The above example creates /etc/audio directory first, then fetch a file named “audio_def_policy” from RMC database for the board, then copy it to /etc/audio/ with a new name “audio_policy”. If this config file is not provided, No data in RMC database is deployed to the target. Some steps defined by developers could not be supported on a filesystem. Installer simply ignores any errors in RMC deployment stage. The name of this config file is what installer looks up first, so it must be INSTALLER.CONFIG. Note 4: At the end of RMC deployment during installation, RMC installer queries a script file POSTINSTALL.sh from RMC database file, and execute it when query is successful on the running board. This hook provides developers almost ultimate flexibility to retouch what have been deployed on the target. There are some steps still can override results from this hook for boot entries and KBOOTPARAM. Enable RMC Feature -------------------------------------------------------------------------------- To enable the RMC feature please add the following variables to your local.conf. DISTRO_FEATURES_append = " rmc" EFI_PROVIDER = "rmc-boot" The default EFI bootloader used with RMC is systemd-boot. To change the default bootloader please overwrite the RMC_BOOTLOADER variable in your local.conf Note: Image could be still bootable if you only have either of two lines, but RMC feature could not be fully functional, depending on the availability of the database file, installer and the rmc tool. Examples -------------------------------------------------------------------------------- We checked in configuration data in common/recipes-bsp/rmc/boards/ for several boards, to help users to understand the RMC feature. These examples are also for validation. For any example you find not working as what this section depicts, it should be treated as a bug to be fixed. To test this feature with examples, enable it and build an image first, then boot the built image on supported boards. Examples are always built in when the feature is enabled, except for the EXAMPLE 1. EXAMPLE 1: Support a new board type: (1) enable the feature and do a build to get a live-boot image by adding these lines in conf/local.conf: DISTRO_FEATURES_append = " rmc" EFI_PROVIDER = "rmc-boot" (2) flash the image to a USB stick and boot it on your board (3) in super user mode, run "rmc -F -o my_board.fp" (4) create directories in your host "mkdir -p my_top_dir/my_rmc/my_board" (5) copy my_board.fp from target to my_top_dir/my_rmc/my_board/ on host (6) create a file my_top_dir/my_rmc/my_board/KBOOTPARAM, put some fake and harmless options in a single line, say, "loglevel=7" (7) create a file my_top_dir/rmc-db.bbappend, put this single line in it: RMC_BOARD_DATA_DIRS_append := " ${THISDIR}/my_rmc" From parent directory of my_top_dir, the tree should look like: my_top_dir/ my_rmc/ my_board/ KBOOTPARAM my_board.fp rmc-db.bbappend Later, you can add more board directories in my_rmc directory. (8) modify build configuration to add my_top_dir into build, for example, put this line in a bblayers.conf: BBFILES += "/full/path/of/my_top_dir/rmc-db.bbappend" (9) build image again then boot it on your board (10) Once you login to shell, new options should be effective, run this command "cat /proc/cmdline" to verify the result. EXAMPLE 2: Board-specific boot entry MinnowBoard MAX and B3 version: common/recipes-bsp/rmc/boards/minnowmax common/recipes-bsp/rmc/boards/minnowmaxB3 We have found two identities (type of board) exist for the "same" Minnow Max hardware, so they have to be treated as two different types of hardware. The two examples show you a boot entry specific to a type of board. Titles shown in boot menu have different names according to the type of running board, "Minnow Max boot" or "Minnow Max B3 boot". in /proc/cmdline, "console=ttyS0,115200n8" shall be there. Kernel prints logs from 6-pin FTDI serial port on Minnow Max(s). This console setting is in board-specific entries, so you won't see it effective if you select default "boot" entry to boot the device. EXAMPLE 3: Board-specific boot entry, global kernel cmdline and installer NUC Gen 6: common/recipes-bsp/rmc/boards/nucgen6 This is a combo example with all supported configuration data for NUC Gen 6 product. It shows two boot entries in bootloader menu when you boot image on NUC Gen 6 product, with "NUC Gen6" in entry titles. There shall no any "console=" in /proc/cmdline when you boot with either of two "NUC Gen6"entries. We designed it this way because there is no accessible tty port on NUC Gen 6 with housing. The post-install hook is also provided in this example. This example also includes a global kernel cmdline fragment KBOOTPARAM. Content of KBOOTPARAM shall be at the end of /proc/cmdline no matter which boot entry you selected to boot NUC Gen6. INSTALLER.CONFIG directs installer to create a directory and deploy a file in it when install the image on NUC Gen6. Choose "NUC Gen6 install" boot entry to boot shall start installation. Once the device reboots after installation, we can verify the configurations. The boot entry "NUC Gen6 boot" shall be shown in boot menu. The content of KBOOTPARAM shall be in /proc/cmdline too. A directory /etc/mylib/ is created and a file "mylib.conf" is there. The content of that file shall be what we put in mylib.conf in common/recipes-bsp/rmc/boards/nucgen6 POSTINSTALL.sh shows how we get rid of an error message caused by no serial console available on NUC Gen 6, without creating another static board configuration. EXAMPLE 4: For validation only T100 (32bit): common/recipes-bsp/rmc/boards/T100-32bit This example is provided for validation on 32 bit X86 architecture. It doesn't provide any new function not mentioned in above examples. Troubleshooting -------------------------------------------------------------------------------- Issue: Cannot obtain RMC fingerprint for a board RMC tool requires UEFI BIOS and SMBIOS support in firmware. It doesn't support other type of firmware, e.g. legacy BIOS. It also requires EFI driver enabled in Linux kernel. Issue: Configuration for a board seems not effective at runtime. Check if board is booted from the storage where the image or installation lives when you have multiple boot options in BIOS. On some old hardwares it is not that obvious as you assume. A build image can support boot from both of legacy and UEFI mode, but RMC only works with UEFI boot so far. Make sure configuration files (BOOTENTRY.CONFIG, INSTALLER.CONFIG and, KBOOTPARAM ...) are properly named in the board directory. Make sure configuration files have correct contents. Some file attributes could not be supported by targeted file system. Installer cannot setup file blobs as you wish. It simply move to the next step if a step fails. Kernel command line can be customized globally with KBOOTPARAM or just in a boot entry for the type of board. They have different effective scopes. If no any board-specific configuration becomes effective on your board but it works on other boards of same product, you can run rmc tool to obtain fingerprint file on your board and compare it with fingerprint of a working board. It is possible they have different firmware versions and unluckily, some information for fingerprint changes between two versions. You can update BIOS on every board to the same BIOS version if it is feasible. Otherwise you have to treat them as two different type of boards. We could extend rmc design to allow multiple fingerprints in a board directory as a workaround. Issue: RMC reports error because it cannot find fingerprint when building image. Make sure you have a fingerprint file. Its name must be ended with '.fp'. You can put a fingerprint file in a board directory and provide data later. Issue: Any problems the above troubleshooting cannot help Please report it to us. Extra information like the type of your board or a dump file from dmidecode tool is helpful. We will investigate the problem and keep improving this feature. When you (don't) need RMC feature -------------------------------------------------------------------------------- RMC feature is designed to as generic as possible, in order to support a large number of types of boards. And it shall be designed not to break things when it is disabled. These considerations help users to decide if they really need or enable it. If you are satisfied with a dedicated build target and image for each board in your development cycle (source, build, validation, release, etc), you don't need this feature. If you have a generic build for multiple type of boards and features supported by that build meet your needs to functionality on all of boards, you don't need to have this feature or you can disable it until you need to check in the first board's data, in order to apply a quirk or customization only for that board. If you want this feature but have concerns to see more and more boards' finger- prints and data in a generic project, you can have another layer to hold all of board-specific data to split them from a generic layer at source level. Another suggestion is always seeking chances not to clone or copy a common configuration to each board's directory. Thanks Jianxun Zhang