mirror of
				https://github.com/smaeul/u-boot.git
				synced 2025-11-03 21:48:15 +00:00 
			
		
		
		
	Coreboot provides the CMOS layout in the tables it passes to U-Boot. Use that to build an editor for the CMOS settings. Signed-off-by: Simon Glass <sjg@chromium.org>
		
			
				
	
	
		
			176 lines
		
	
	
		
			5.9 KiB
		
	
	
	
		
			ReStructuredText
		
	
	
	
	
	
			
		
		
	
	
			176 lines
		
	
	
		
			5.9 KiB
		
	
	
	
		
			ReStructuredText
		
	
	
	
	
	
.. SPDX-License-Identifier: GPL-2.0+
 | 
						|
 | 
						|
Configuration Editor
 | 
						|
====================
 | 
						|
 | 
						|
Introduction
 | 
						|
------------
 | 
						|
 | 
						|
U-Boot provides a configuration editor which allows settings to be changed in
 | 
						|
a GUI or text environment.
 | 
						|
 | 
						|
 | 
						|
This feature is still in development and has a number of limitations. For
 | 
						|
example, cedit only supports menu items (there is no numeric or text entry),
 | 
						|
provides no support for colour text and does not support scrolling. Still it is
 | 
						|
possible to use it for simple applications.
 | 
						|
 | 
						|
 | 
						|
Overview
 | 
						|
--------
 | 
						|
 | 
						|
The configuration editor makes use of :doc:`expo` to build a description of the
 | 
						|
configuration screens and allow user to interact with it.
 | 
						|
 | 
						|
To create a single-scene cedit for your application:
 | 
						|
 | 
						|
#. Design the scene, i.e. the objects that need to be present and what their
 | 
						|
   possible values are
 | 
						|
 | 
						|
#. Enter this in .dts format
 | 
						|
 | 
						|
#. Create a header file containing the IDs
 | 
						|
 | 
						|
#. Run the 'expo.py' tool to generate a .dtb file containing the layout, which
 | 
						|
   can be used by U-Boot
 | 
						|
 | 
						|
#. Use the :doc:`../usage/cmd/cedit` to create the cedit, read the settings,
 | 
						|
   present the cedit to the user and save the settings afterwards.
 | 
						|
 | 
						|
Each of these is described in a separate section. See :ref:`expo_example` for
 | 
						|
an example file.
 | 
						|
 | 
						|
 | 
						|
Design a scene
 | 
						|
--------------
 | 
						|
 | 
						|
Using a piece of paper or a drawing tool, lay out the objects you want in your
 | 
						|
scene. Typically you will use the default layout engine, which simply puts items
 | 
						|
one after the other from top to bottom. So use a single column and show the
 | 
						|
prompt and value for each object.
 | 
						|
 | 
						|
For menu items, show one of the values, but keep in mind what else you need.
 | 
						|
 | 
						|
 | 
						|
Create an expo-format file
 | 
						|
--------------------------
 | 
						|
 | 
						|
The description is in the form of a devicetree file, as documented at
 | 
						|
:ref:`expo_format`. Since everything in an expo has an ID number (an integer
 | 
						|
greater than 1) the description is written terms of these IDs. They each have
 | 
						|
an enum value. which is typically taken care of by the `expo.py` tool.
 | 
						|
 | 
						|
The expo should have a `scenes` node with a named scene as a subnode. Within the
 | 
						|
scene, add properties for the scene, then a subnode for each object in the
 | 
						|
scene.
 | 
						|
 | 
						|
All object nodes require an `id` value and a `type` property. Other properties
 | 
						|
depend on the type. For example, a menu has a `title` and an `item-label` list
 | 
						|
proving the text for the menu items, as well as an `item-id` list providing the
 | 
						|
ID of each menu item, so it can be selected.
 | 
						|
 | 
						|
Text properties may have two variants. For example `title` specifies the title
 | 
						|
of a menu, but you can instead use `title-id` to specify the string ID to use as
 | 
						|
the title. String are defined in a separate area, common to the whole expo,
 | 
						|
which contains a subnode for each string. Within that subnode are the ID and the
 | 
						|
`value` (i.e. the text). For now only English is supported, but in future it may
 | 
						|
be possible to append a language identifier to provide other values (e.g.
 | 
						|
'value-es' for Spanish).
 | 
						|
 | 
						|
 | 
						|
Create an ID header-file
 | 
						|
------------------------
 | 
						|
 | 
						|
Expo needs to know the integer value to use for every ID referenced in your
 | 
						|
expo-format file. For example, if you have defined a `cpu-speed` node with an
 | 
						|
id of `ID_CPU_SPEED`, then Expo needs to know the value of `ID_CPU_SPEED`.
 | 
						|
 | 
						|
When you write C code to use the expo, you may need to know the IDs. For
 | 
						|
example, to find which value the user selected in `cpu-speed` menu, you must
 | 
						|
use the `ID_CPU_SPEED` ID. The ID is the only way to refer to anything in Expo.
 | 
						|
 | 
						|
Since we need a shared set of IDs, it is best to have a header file containing
 | 
						|
them. Expo supports doing this with an enum, where every ID is listed in the
 | 
						|
enum::
 | 
						|
 | 
						|
    enum {
 | 
						|
        ID_PROMPT = EXPOID_BASE_ID,
 | 
						|
 | 
						|
        ID_PROMPT,
 | 
						|
 | 
						|
        ID_SCENE1,
 | 
						|
        ID_SCENE1_TITLE,
 | 
						|
        ...
 | 
						|
    };
 | 
						|
 | 
						|
The C compiler can parse this directly. The `expo.py` tool parses it for expo.
 | 
						|
 | 
						|
Create a header file containing every ID mentioned in your expo. Try to group
 | 
						|
related things together.
 | 
						|
 | 
						|
 | 
						|
Build the expo layout
 | 
						|
---------------------
 | 
						|
 | 
						|
Use the `expo.py` tool to build a .dtb for your expo::
 | 
						|
 | 
						|
    ./tools/expo.py -e expo_ids.h -l expo_layout.dts -o expo.dtb
 | 
						|
 | 
						|
This uses the enum in the provided header file to get the ID numbers, grabs
 | 
						|
the `.dts` file, inserts the ID numbers and then uses the devicetree compiler to
 | 
						|
build a `.dtb` file.
 | 
						|
 | 
						|
If you get an error::
 | 
						|
 | 
						|
    Devicetree compiler error:
 | 
						|
    Error: <stdin>:9.19-20 syntax error
 | 
						|
    FATAL ERROR: Unable to parse input tree
 | 
						|
 | 
						|
that means that something is wrong with your syntax, or perhaps you have an ID
 | 
						|
in the `.dts` file that is not mentioned in your enum. Check both files and try
 | 
						|
again.
 | 
						|
 | 
						|
Note that the first ID in your file must be no less that `EXPOID_BASE_ID` since
 | 
						|
IDs before that are reserved. The `expo.py` tool automatically obtains this
 | 
						|
value from the `expo.h` header file, but you must set the first ID to this
 | 
						|
enum value.
 | 
						|
 | 
						|
 | 
						|
Use the command interface
 | 
						|
-------------------------
 | 
						|
 | 
						|
See the :doc:`../usage/cmd/cedit` command for information on available commands.
 | 
						|
Typically you will use `cedit load` to load the `.dtb` file and `cedit run` to
 | 
						|
let the user interact with it.
 | 
						|
 | 
						|
 | 
						|
Multiple scenes
 | 
						|
---------------
 | 
						|
 | 
						|
Expo supports multiple scenes but has no pre-determined way of moving between
 | 
						|
them. You could use selection of a menu item as a signal to change the scene,
 | 
						|
but this is not currently implemented in the cedit code (see `cedit_run()`).
 | 
						|
 | 
						|
 | 
						|
Themes
 | 
						|
------
 | 
						|
 | 
						|
The configuration editor uses simple expo themes. The theme is read from
 | 
						|
`/bootstd/cedit-theme` in the devicetree.
 | 
						|
 | 
						|
 | 
						|
Reading and writing settings
 | 
						|
----------------------------
 | 
						|
 | 
						|
Cedit provides several options for persistent settings:
 | 
						|
 | 
						|
- Writing an FDT file to a filesystem
 | 
						|
- Writing to U-Boot's environment variables, which are then typically stored in
 | 
						|
  a persistent manner
 | 
						|
- Writing to CMOS RAM registers (common on x86 machines). Note that textline
 | 
						|
  objects do not appear in CMOS RAM registers
 | 
						|
 | 
						|
For now, reading and writing settings is not automatic. See the
 | 
						|
:doc:`../usage/cmd/cedit` for how to do this on the command line or in a
 | 
						|
script. For x86 devices, see :ref:`cedit_cb_load`.
 |