Simon Glass | 40eb3c3 | 2023-08-14 16:40:29 -0600 | [diff] [blame] | 1 | .. SPDX-License-Identifier: GPL-2.0+ |
| 2 | |
| 3 | Configuration Editor |
| 4 | ==================== |
| 5 | |
| 6 | Introduction |
| 7 | ------------ |
| 8 | |
| 9 | U-Boot provides a configuration editor which allows settings to be changed in |
| 10 | a GUI or text environment. |
| 11 | |
| 12 | |
| 13 | This feature is still in development and has a number of limitations. For |
| 14 | example, cedit only supports menu items (there is no numeric or text entry), |
| 15 | provides no support for colour text and does not support scrolling. Still it is |
| 16 | possible to use it for simple applications. |
| 17 | |
| 18 | |
| 19 | Overview |
| 20 | -------- |
| 21 | |
| 22 | The configuration editor makes use of :doc:`expo` to build a description of the |
| 23 | configuration screens and allow user to interact with it. |
| 24 | |
| 25 | To create a single-scene cedit for your application: |
| 26 | |
| 27 | #. Design the scene, i.e. the objects that need to be present and what their |
| 28 | possible values are |
| 29 | |
| 30 | #. Enter this in .dts format |
| 31 | |
| 32 | #. Create a header file containing the IDs |
| 33 | |
| 34 | #. Run the 'expo.py' tool to generate a .dtb file containing the layout, which |
| 35 | can be used by U-Boot |
| 36 | |
| 37 | #. Use the :doc:`../usage/cmd/cedit` to create the cedit, read the settings, |
| 38 | present the cedit to the user and save the settings afterwards. |
| 39 | |
| 40 | Each of these is described in a separate section. See :ref:`expo_example` for |
| 41 | an example file. |
| 42 | |
| 43 | |
| 44 | Design a scene |
| 45 | -------------- |
| 46 | |
| 47 | Using a piece of paper or a drawing tool, lay out the objects you want in your |
| 48 | scene. Typically you will use the default layout engine, which simply puts items |
| 49 | one after the other from top to bottom. So use a single column and show the |
| 50 | prompt and value for each object. |
| 51 | |
| 52 | For menu items, show one of the values, but keep in mind what else you need. |
| 53 | |
| 54 | |
| 55 | Create an expo-format file |
| 56 | -------------------------- |
| 57 | |
| 58 | The description is in the form of a devicetree file, as documented at |
| 59 | :ref:`expo_format`. Since everything in an expo has an ID number (an integer |
| 60 | greater than 1) the description is written terms of these IDs. They each have |
| 61 | an enum value. which is typically taken care of by the `expo.py` tool. |
| 62 | |
| 63 | The expo should have a `scenes` node with a named scene as a subnode. Within the |
| 64 | scene, add properties for the scene, then a subnode for each object in the |
| 65 | scene. |
| 66 | |
| 67 | All object nodes require an `id` value and a `type` property. Other properties |
| 68 | depend on the type. For example, a menu has a `title` and an `item-label` list |
| 69 | proving the text for the menu items, as well as an `item-id` list providing the |
| 70 | ID of each menu item, so it can be selected. |
| 71 | |
| 72 | Text properties may have two variants. For example `title` specifies the title |
| 73 | of a menu, but you can instead use `title-id` to specify the string ID to use as |
| 74 | the title. String are defined in a separate area, common to the whole expo, |
| 75 | which contains a subnode for each string. Within that subnode are the ID and the |
| 76 | `value` (i.e. the text). For now only English is supported, but in future it may |
| 77 | be possible to append a language identifier to provide other values (e.g. |
| 78 | 'value-es' for Spanish). |
| 79 | |
| 80 | |
| 81 | Create an ID header-file |
| 82 | ------------------------ |
| 83 | |
| 84 | Expo needs to know the integer value to use for every ID referenced in your |
| 85 | expo-format file. For example, if you have defined a `cpu-speed` node with an |
| 86 | id of `ID_CPU_SPEED`, then Expo needs to know the value of `ID_CPU_SPEED`. |
| 87 | |
| 88 | When you write C code to use the expo, you may need to know the IDs. For |
| 89 | example, to find which value the user selected in `cpu-speed` menu, you must |
| 90 | use the `ID_CPU_SPEED` ID. The ID is the only way to refer to anything in Expo. |
| 91 | |
| 92 | Since we need a shared set of IDs, it is best to have a header file containing |
| 93 | them. Expo supports doing this with an enum, where every ID is listed in the |
| 94 | enum:: |
| 95 | |
| 96 | enum { |
Simon Glass | 53a0a2f | 2024-10-14 16:31:57 -0600 | [diff] [blame] | 97 | ID_PROMPT = EXPOID_BASE_ID, |
Simon Glass | 40eb3c3 | 2023-08-14 16:40:29 -0600 | [diff] [blame] | 98 | |
| 99 | ID_PROMPT, |
| 100 | |
| 101 | ID_SCENE1, |
| 102 | ID_SCENE1_TITLE, |
| 103 | ... |
| 104 | }; |
| 105 | |
| 106 | The C compiler can parse this directly. The `expo.py` tool parses it for expo. |
| 107 | |
| 108 | Create a header file containing every ID mentioned in your expo. Try to group |
| 109 | related things together. |
| 110 | |
| 111 | |
| 112 | Build the expo layout |
| 113 | --------------------- |
| 114 | |
| 115 | Use the `expo.py` tool to build a .dtb for your expo:: |
| 116 | |
| 117 | ./tools/expo.py -e expo_ids.h -l expo_layout.dts -o expo.dtb |
| 118 | |
| 119 | This uses the enum in the provided header file to get the ID numbers, grabs |
| 120 | the `.dts` file, inserts the ID numbers and then uses the devicetree compiler to |
| 121 | build a `.dtb` file. |
| 122 | |
| 123 | If you get an error:: |
| 124 | |
| 125 | Devicetree compiler error: |
| 126 | Error: <stdin>:9.19-20 syntax error |
| 127 | FATAL ERROR: Unable to parse input tree |
| 128 | |
| 129 | that means that something is wrong with your syntax, or perhaps you have an ID |
| 130 | in the `.dts` file that is not mentioned in your enum. Check both files and try |
| 131 | again. |
| 132 | |
Simon Glass | 53a0a2f | 2024-10-14 16:31:57 -0600 | [diff] [blame] | 133 | Note that the first ID in your file must be no less that `EXPOID_BASE_ID` since |
| 134 | IDs before that are reserved. The `expo.py` tool automatically obtains this |
| 135 | value from the `expo.h` header file, but you must set the first ID to this |
| 136 | enum value. |
| 137 | |
Simon Glass | 40eb3c3 | 2023-08-14 16:40:29 -0600 | [diff] [blame] | 138 | |
| 139 | Use the command interface |
| 140 | ------------------------- |
| 141 | |
| 142 | See the :doc:`../usage/cmd/cedit` command for information on available commands. |
| 143 | Typically you will use `cedit load` to load the `.dtb` file and `cedit run` to |
| 144 | let the user interact with it. |
| 145 | |
| 146 | |
| 147 | Multiple scenes |
| 148 | --------------- |
| 149 | |
| 150 | Expo supports multiple scenes but has no pre-determined way of moving between |
| 151 | them. You could use selection of a menu item as a signal to change the scene, |
| 152 | but this is not currently implemented in the cedit code (see `cedit_run()`). |
Simon Glass | 82adc29 | 2023-08-14 16:40:30 -0600 | [diff] [blame] | 153 | |
| 154 | |
| 155 | Themes |
| 156 | ------ |
| 157 | |
| 158 | The configuration editor uses simple expo themes. The theme is read from |
| 159 | `/bootstd/cedit-theme` in the devicetree. |
Simon Glass | 9b68f94 | 2023-08-14 16:40:39 -0600 | [diff] [blame] | 160 | |
| 161 | |
| 162 | Reading and writing settings |
| 163 | ---------------------------- |
| 164 | |
| 165 | Cedit provides several options for persistent settings: |
| 166 | |
| 167 | - Writing an FDT file to a filesystem |
| 168 | - Writing to U-Boot's environment variables, which are then typically stored in |
| 169 | a persistent manner |
Simon Glass | 00f6c40 | 2023-10-01 19:13:40 -0600 | [diff] [blame] | 170 | - Writing to CMOS RAM registers (common on x86 machines). Note that textline |
| 171 | objects do not appear in CMOS RAM registers |
Simon Glass | 9b68f94 | 2023-08-14 16:40:39 -0600 | [diff] [blame] | 172 | |
| 173 | For now, reading and writing settings is not automatic. See the |
| 174 | :doc:`../usage/cmd/cedit` for how to do this on the command line or in a |
Simon Glass | 3434420 | 2024-10-14 16:32:11 -0600 | [diff] [blame] | 175 | script. For x86 devices, see :ref:`cedit_cb_load`. |