1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
.. 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 {
ZERO,
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.
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.
|
