> On Aug 4, 2016, at 10:45 AM, Tom Zanussi <tom.zanu...@linux.intel.com> wrote:
>
> On 08/04/2016 12:39 PM, Jianxun Zhang wrote:
>>
>>> On Aug 4, 2016, at 7:43 AM, Tom Zanussi <tom.zanu...@linux.intel.com> wrote:
>>>
>>> On 08/03/2016 01:04 PM, Jianxun Zhang wrote:
>>>> Provide a README for RMC feature. Also check in fingerprints and
>>>> configuration data for several boards as examples for users.
>>>> They can be used for validation too.
>>>>
>>>> Signed-off-by: Jianxun Zhang <jianxun.zh...@linux.intel.com>
>>>> ---
>>>> .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 +
>>>> .../rmc/boards/T100-32bit/T100-32bit.fp | Bin 0 -> 116 bytes
>>>> common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 +
>>>> .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 +
>>>> .../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 +
>>>> common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 +
>>>> .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes
>>>> .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG | 1 +
>>>> .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 +
>>>> .../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes
>>>> .../rmc/boards/nucgen6/BOOTENTRY.CONFIG | 2 +
>>>> .../rmc/boards/nucgen6/INSTALLER.CONFIG | 6 +
>>>> common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM | 1 +
>>>> common/recipes-bsp/rmc/boards/nucgen6/boot.conf | 4 +
>>>> common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 +
>>>> common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 +
>>>> common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes
>>>> documentation/rmc/README | 343
>>>> +++++++++++++++++++++
>>>> 18 files changed, 387 insertions(+)
>>>> create mode 100644
>>>> common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
>>>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp
>>>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
>>>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/install.conf
>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/boot.conf
>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp
>>>> create mode 100644
>>>> common/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG
>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/boot.conf
>>>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/minnowmaxB3.fp
>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/BOOTENTRY.CONFIG
>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/INSTALLER.CONFIG
>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM
>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/boot.conf
>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/install.conf
>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/mylib.conf
>>>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp
>>>> create mode 100644 documentation/rmc/README
>>>>
>>>> diff --git a/common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
>>>> b/common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
>>>> new file mode 100644
>>>> index 0000000..b2fabe8
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
>>>> @@ -0,0 +1,2 @@
>>>> +boot.conf
>>>> +install.conf
>>>> diff --git a/common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp
>>>> b/common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp
>>>> new file mode 100644
>>>> index
>>>> 0000000000000000000000000000000000000000..86ecea7344bfc744f7f9d57f3f1810d6f7ba0db1
>>>> GIT binary patch
>>>> literal 116
>>>> zcmZQ%Ehx%QDNQbk&r8frWe71eFbHvEV8SZOB2boERGgWg$KaV)lA5Ctq^aOolAo&)
>>>> p;;X6P91yAyWo&L@px~fjsAp{K?oq{1&rp<FoLW?tn!<p>1_02dA-n(p
>>>>
>>>> literal 0
>>>> HcmV?d00001
>>>>
>>>> diff --git a/common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
>>>> b/common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
>>>> new file mode 100644
>>>> index 0000000..f1578e0
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
>>>> @@ -0,0 +1,4 @@
>>>> +title T100T(32bit) boot
>>>> +linux /vmlinuz
>>>> +initrd /initrd
>>>> +options LABEL=boot loglevel=8
>>>> diff --git a/common/recipes-bsp/rmc/boards/T100-32bit/install.conf
>>>> b/common/recipes-bsp/rmc/boards/T100-32bit/install.conf
>>>> new file mode 100644
>>>> index 0000000..67e7eb1
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/boards/T100-32bit/install.conf
>>>> @@ -0,0 +1,4 @@
>>>> +title T100T(32bit) install
>>>> +linux /vmlinuz
>>>> +initrd /initrd
>>>> +options LABEL=install-efi
>>>> diff --git a/common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
>>>> b/common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
>>>> new file mode 100644
>>>> index 0000000..cb01ced
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
>>>> @@ -0,0 +1 @@
>>>> +boot.conf
>>>> diff --git a/common/recipes-bsp/rmc/boards/minnowmax/boot.conf
>>>> b/common/recipes-bsp/rmc/boards/minnowmax/boot.conf
>>>> new file mode 100644
>>>> index 0000000..6e789cd
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/boards/minnowmax/boot.conf
>>>> @@ -0,0 +1,4 @@
>>>> +title Minnow Max boot
>>>> +linux /vmlinuz
>>>> +initrd /initrd
>>>> +options LABEL=boot console=ttyS0,115200n8
>>>> diff --git a/common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp
>>>> b/common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp
>>>> new file mode 100644
>>>> index
>>>> 0000000000000000000000000000000000000000..3c5a286f33ad2e6b17de3bb610160532ce5d65cf
>>>> GIT binary patch
>>>> literal 143
>>>> zcmZQ%Ehx%QDNQbk&r8frWe9Wh@o|j|^K=bYa5PW|@No=r^AGZ6U_w>po0*rFU+$Ej
>>>> zSd^mR>lnenB2boERGgWg$KaV)lA5Ctq^aOolAo&);;X6P91yCY;A(7PWU8RxpkSzH
>>>> XZ0zn)#Zb>slv<oxRF;~;fWig<I@~II
>>>>
>>>> literal 0
>>>> HcmV?d00001
>>>>
>>>> diff --git a/common/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG
>>>> b/common/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG
>>>> new file mode 100644
>>>> index 0000000..cb01ced
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG
>>>> @@ -0,0 +1 @@
>>>> +boot.conf
>>>> diff --git a/common/recipes-bsp/rmc/boards/minnowmaxB3/boot.conf
>>>> b/common/recipes-bsp/rmc/boards/minnowmaxB3/boot.conf
>>>> new file mode 100644
>>>> index 0000000..577e5d6
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/boards/minnowmaxB3/boot.conf
>>>> @@ -0,0 +1,4 @@
>>>> +title Minnow Max B3 boot
>>>> +linux /vmlinuz
>>>> +initrd /initrd
>>>> +options LABEL=boot console=ttyS0,115200n8
>>>> diff --git a/common/recipes-bsp/rmc/boards/minnowmaxB3/minnowmaxB3.fp
>>>> b/common/recipes-bsp/rmc/boards/minnowmaxB3/minnowmaxB3.fp
>>>> new file mode 100644
>>>> index
>>>> 0000000000000000000000000000000000000000..ad3f0d6d7cfdada14a35227643c5c67e0c608f7a
>>>> GIT binary patch
>>>> literal 148
>>>> zcmZQ%Ehx%QDNQbk&r8frW$?|+%gZlM%1<mxQSeQyP;fF<2=H+Xaq|!IWnjXl)Cr>0
>>>> zF@k|bpe(hhI5R(w!85NUHAf>zQ^Bz$KUX8fS5v_`AXGuY)!4$wR6)T(!BEfG*xjRw
>>>> Sp`M{AwK%n?EH#Azg$)3>EG<0%
>>>>
>>>> literal 0
>>>> HcmV?d00001
>>>>
>>>> diff --git a/common/recipes-bsp/rmc/boards/nucgen6/BOOTENTRY.CONFIG
>>>> b/common/recipes-bsp/rmc/boards/nucgen6/BOOTENTRY.CONFIG
>>>> new file mode 100644
>>>> index 0000000..b2fabe8
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/boards/nucgen6/BOOTENTRY.CONFIG
>>>> @@ -0,0 +1,2 @@
>>>> +boot.conf
>>>> +install.conf
>>>> diff --git a/common/recipes-bsp/rmc/boards/nucgen6/INSTALLER.CONFIG
>>>> b/common/recipes-bsp/rmc/boards/nucgen6/INSTALLER.CONFIG
>>>> new file mode 100644
>>>> index 0000000..7d5378b
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/boards/nucgen6/INSTALLER.CONFIG
>>>> @@ -0,0 +1,6 @@
>>>> +# This file specifies which file or dir RMC will install onto target.
>>>> +# Note the absolute path is referred from mount points in installation.
>>>> +efi_entry_dir:root:disk:770:/boot/loader/entries/
>>>> +boot.conf:root:disk:770:/boot/loader/entries/rmcboot.conf
>>>> +mylibdir:root:root:770:/tgt_root/etc/mylib/
>>>> +mylib.conf:root:root:660:/tgt_root/etc/mylib/mylib.conf
>>>> diff --git a/common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM
>>>> b/common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM
>>>> new file mode 100644
>>>> index 0000000..27943b4
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM
>>>> @@ -0,0 +1 @@
>>>> +i915.preliminary_hw_support=1
>>>> diff --git a/common/recipes-bsp/rmc/boards/nucgen6/boot.conf
>>>> b/common/recipes-bsp/rmc/boards/nucgen6/boot.conf
>>>> new file mode 100644
>>>> index 0000000..e6ecb02
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/boards/nucgen6/boot.conf
>>>> @@ -0,0 +1,4 @@
>>>> +title NUC Gen6 boot
>>>> +linux /vmlinuz
>>>> +initrd /initrd
>>>> +options LABEL=boot
>>>> diff --git a/common/recipes-bsp/rmc/boards/nucgen6/install.conf
>>>> b/common/recipes-bsp/rmc/boards/nucgen6/install.conf
>>>> new file mode 100644
>>>> index 0000000..916bb04
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/boards/nucgen6/install.conf
>>>> @@ -0,0 +1,4 @@
>>>> +title NUC Gen6 install
>>>> +linux /vmlinuz
>>>> +initrd /initrd
>>>> +options LABEL=install-efi
>>>> diff --git a/common/recipes-bsp/rmc/boards/nucgen6/mylib.conf
>>>> b/common/recipes-bsp/rmc/boards/nucgen6/mylib.conf
>>>> new file mode 100644
>>>> index 0000000..fd8357c
>>>> --- /dev/null
>>>> +++ b/common/recipes-bsp/rmc/boards/nucgen6/mylib.conf
>>>> @@ -0,0 +1,7 @@
>>>> +# This is a demo conf file read by an imagined program or library
>>>> +# which reads this file at runtime to customize its behavior.
>>>> +# rmc will deploy it to the location specified in INSTALLER.CONFIG.
>>>> +
>>>> +lib.info = "V1.0 for rmc demo"
>>>> +lib.board = "NUC gen 6"
>>>> +prog.ui.layout = "minimal"
>>>> diff --git a/common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp
>>>> b/common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp
>>>> new file mode 100644
>>>> index
>>>> 0000000000000000000000000000000000000000..834f800b63bc9cc2cd42e46059bafaec3701a9a2
>>>> GIT binary patch
>>>> literal 149
>>>> zcmZQ%Ehx%QDNQbk&r8frWl$gl7?@Bs_=P%~Wts*@Ix(;al%*CGXXfWIc;=O)=4b?I
>>>> yDmdpCrD}xuYAR%!>Y5pu8H6f02ZSm(C>ZKl7`S^>G1M~@r52|am8GUIps)do>LySC
>>>>
>>>> literal 0
>>>> HcmV?d00001
>>>>
>>>> diff --git a/documentation/rmc/README b/documentation/rmc/README
>>>> new file mode 100644
>>>> index 0000000..ba476b0
>>>> --- /dev/null
>>>> +++ b/documentation/rmc/README
>>>> @@ -0,0 +1,343 @@
>>>> +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)
>>>> + | |- 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:
>>>> +To add your boards into RMC feature, simply put this line in your
>>>> +rmc-db.bbappend:
>>>> +
>>>> +RMC_BOARD_DATA_DIRS_append := " ${THISDIR}/my_top_dir"
>>>> +
>>>> +RMC db recipe takes all top directories specified in RMC_BOARD_DATA_DIRS
>>>> to
>>>> +construct and deploy a central RMC database inside image. The bbclass of
>>>> the
>>>> +bare RMC project also provide function for other components to construct
>>>> their
>>>> +own RMC database file. Please refer to rmc-db.bbclass for more
>>>> information.
>>>> +
>>>> +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.
>>>> +
>>>> +
>>>> +
>>>> +Enable RMC Feature
>>>> +--------------------------------------------------------------------------------
>>>> +To Enable RMC feature in build, add the below lines in a conf file:
>>>> +DISTRO_FEATURES_append = " rmc"
>>>> +EFI_PROVIDER = "rmc-systemd-boot"
>>>> +
>>>> +Note:
>>>> +Image could be still bootable if you only have either of two lines, but
>>>> RMC
>>>> +feature won't be fully functional.
>>>> +
>>>
>>> In what way? Please explain. What do you mean by it 'could still be
>>> bootable'. Under what conditions? And please explain what it means
>>> that the 'RMC feature won't be fully functional'. Which parts will be
>>> functional and which parts won’t?
>>>
>> I will amend this in README, but it is a bit complex now.
>>
>> Now we have 2 switches, so we have to cover 2^2 = 4 possibilities. I tested
>> these but think it is too overwhelming to user if we have lengthy sections
>> to explain result from each of them.
>>
>> Actually, the more we say in this section here, the more possibly users
>> gonna say “hey, man, why don’t just tell us how to fully enable/disable this
>> thing?!”.
>>
>
> The other option is to just fix it, so that there are only two options,
> as it should be. But I guess it won't happen overnight, so needs to be
> documented as long as this situation exists.
>
Just kindly remind you the installer. The current design in OE ties up
installer and bootloader. If we apply the idea of discussion on bootloader to
installer case and you want RMC image not to “override” original installer, we
get 2^3 = 8… I think we gonna either have a single distro feature which you
disapprove or break functions into a component basis in README. Any cases in
the middle ground is asking trouble.
I think I should do something to redesign these parts in OE if people accept my
thoughts.
> Tom
>
>> I will file a bug to amend README to make it shorter, within 150 lines
>> somehow. I believe we will have more talk on this topic.
>>
>>> Thanks,
>>>
>>> Tom
>>>
>>>> +
>>>> +
>>>> +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-systemd-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.
>>>> +
>>>> +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
>>>> +
>>>> +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 <jianxun.zh...@linux.intel.com>
>>>>
>>>
>>
>
--
_______________________________________________
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
