summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/README.POST12
-rw-r--r--doc/README.fec_mxc8
-rw-r--r--doc/README.fsl-ddr4
-rw-r--r--doc/README.fsl-dpaa10
-rw-r--r--doc/README.kwbimage2
-rw-r--r--doc/README.link-local2
-rw-r--r--doc/README.pxe8
-rw-r--r--doc/arch/m68k.rst4
-rw-r--r--doc/arch/sandbox/sandbox.rst2
-rw-r--r--doc/arch/x86.rst4
-rw-r--r--doc/develop/devicetree/control.rst2
-rw-r--r--doc/develop/distro.rst2
-rw-r--r--doc/develop/process.rst12
-rw-r--r--doc/develop/release_cycle.rst2
-rw-r--r--doc/develop/sending_patches.rst18
-rw-r--r--doc/develop/system_configuration.rst6
-rw-r--r--doc/develop/uefi/uefi.rst6
-rw-r--r--doc/sphinx/requirements.txt2
-rw-r--r--doc/uImage.FIT/source_file_format.txt3
-rw-r--r--doc/usage/cmd/qfw.rst2
-rw-r--r--doc/usage/cmd/sound.rst41
-rw-r--r--doc/usage/environment.rst2
-rw-r--r--doc/usage/index.rst1
23 files changed, 96 insertions, 59 deletions
diff --git a/doc/README.POST b/doc/README.POST
index 5d92f3fe6e9..1366f95c662 100644
--- a/doc/README.POST
+++ b/doc/README.POST
@@ -649,15 +649,15 @@ not need any modifications for porting them to another board/CPU.
For verifying the I2C bus, a full I2C bus scanning will be performed
using the i2c_probe() routine. If a board defines
-CONFIG_SYS_POST_I2C_ADDRS the I2C test will pass if all devices
-listed in CONFIG_SYS_POST_I2C_ADDRS are found, and no additional
-devices are detected. If CONFIG_SYS_POST_I2C_ADDRS is not defined
+CFG_SYS_POST_I2C_ADDRS the I2C test will pass if all devices
+listed in CFG_SYS_POST_I2C_ADDRS are found, and no additional
+devices are detected. If CFG_SYS_POST_I2C_ADDRS is not defined
the test will pass if any I2C device is found.
-The CONFIG_SYS_POST_I2C_IGNORES define can be used to list I2C
+The CFG_SYS_POST_I2C_IGNORES define can be used to list I2C
devices which may or may not be present when using
-CONFIG_SYS_POST_I2C_ADDRS. The I2C POST test will pass regardless
-if the devices in CONFIG_SYS_POST_I2C_IGNORES are found or not.
+CFG_SYS_POST_I2C_ADDRS. The I2C POST test will pass regardless
+if the devices in CFG_SYS_POST_I2C_IGNORES are found or not.
This is useful in cases when I2C devices are optional (eg on a
daughtercard that may or may not be present) or not critical
to board operation.
diff --git a/doc/README.fec_mxc b/doc/README.fec_mxc
index d17dfb676f7..2ccd4288d28 100644
--- a/doc/README.fec_mxc
+++ b/doc/README.fec_mxc
@@ -18,16 +18,10 @@ CONFIG_PHYLIB
CONFIG_FEC_MXC_NO_ANEG
Relevant only if PHYLIB not used. Skips auto-negotiation restart.
-CONFIG_FEC_MXC_PHYADDR
+CFG_FEC_MXC_PHYADDR
Optional, selects the exact phy address that should be connected
and function fecmxc_initialize will try to initialize it.
-CONFIG_FEC_FIXED_SPEED
- Optional, selects a fixed speed on the MAC interface without asking some
- phy. This is usefull if there is a direct MAC <-> MAC connection, for
- example if the CPU is connected directly via the RGMII interface to a
- ethernet-switch.
-
Reading the ethaddr from the SoC eFuses:
if CONFIG_FEC_MXC is defined and the U-Boot environment does not contain the
ethaddr variable, then its value gets read from the corresponding eFuses in
diff --git a/doc/README.fsl-ddr b/doc/README.fsl-ddr
index 10e63f3be1d..f44bb2aa25d 100644
--- a/doc/README.fsl-ddr
+++ b/doc/README.fsl-ddr
@@ -56,8 +56,8 @@ Table of 2-way interleaving modes supported in cpu/8xxx/ddr/
The ways to configure the ddr interleaving mode
==============================================
1. In board header file(e.g.MPC8572DS.h), add default interleaving setting
- under "CONFIG_EXTRA_ENV_SETTINGS", like:
- #define CONFIG_EXTRA_ENV_SETTINGS \
+ under "CFG_EXTRA_ENV_SETTINGS", like:
+ #define CFG_EXTRA_ENV_SETTINGS \
"hwconfig=fsl_ddr:ctlr_intlv=bank" \
......
diff --git a/doc/README.fsl-dpaa b/doc/README.fsl-dpaa
deleted file mode 100644
index 3ef5eeb32e1..00000000000
--- a/doc/README.fsl-dpaa
+++ /dev/null
@@ -1,10 +0,0 @@
-This file documents Freescale DPAA-specific options.
-
-FMan (Frame Manager)
- - CONFIG_FSL_FM_10GEC_REGULAR_NOTATION
- on SoCs T4240, T2080, LS1043A, etc, the notation between 10GEC and MAC as below:
- 10GEC1->MAC9, 10GEC2->MAC10, 10GEC3->MAC1, 10GEC4->MAC2
- on SoCs T1024, etc, the notation between 10GEC and MAC as below:
- 10GEC1->MAC1, 10GEC2->MAC2
- so we introduce CONFIG_FSL_FM_10GEC_REGULAR_NOTATION to identify the new SoCs on
- which 10GEC enumeration is consistent with MAC enumeration.
diff --git a/doc/README.kwbimage b/doc/README.kwbimage
index 762b2e3acb7..a1d247c32dd 100644
--- a/doc/README.kwbimage
+++ b/doc/README.kwbimage
@@ -42,7 +42,7 @@ Board specific configuration file specifications:
kwbimage.cfg. The name can be set as part of the full path
to the file using CONFIG_SYS_KWD_CONFIG (probably in
include/configs/<yourboard>.h). The path should look like:
- $(CONFIG_BOARDDIR)/<yourkwbimagename>.cfg
+ $(CFG_BOARDDIR)/<yourkwbimagename>.cfg
2. This file can have empty lines and lines starting with "#" as first
character to put comments
3. This file can have configuration command lines as mentioned below,
diff --git a/doc/README.link-local b/doc/README.link-local
index 148b4987f27..ec2ef940e4c 100644
--- a/doc/README.link-local
+++ b/doc/README.link-local
@@ -51,7 +51,7 @@ by env variables. It depends on CONFIG_CMD_LINK_LOCAL, CONFIG_CMD_DHCP,
and CONFIG_BOOTP_MAY_FAIL.
If both fail or are disabled, static settings are used.
-#define CONFIG_EXTRA_ENV_SETTINGS \
+#define CFG_EXTRA_ENV_SETTINGS \
"ipconfigcmd=if test \\\"$dhcpenabled\\\" -ne 0;" \
"then " \
"dhcpfail=0;dhcp || dhcpfail=1;" \
diff --git a/doc/README.pxe b/doc/README.pxe
index d14d2bdcc9b..172201093d0 100644
--- a/doc/README.pxe
+++ b/doc/README.pxe
@@ -179,11 +179,19 @@ initrd <path> - if this label is chosen, use tftp to retrieve the initrd
at <path>. it will be stored at the address indicated in
the initrd_addr_r environment variable, and that address
will be passed to bootm.
+ For FIT image, the initrd can be provided with the same value than
+ kernel, including configuration:
+ <path>#<conf>[#<extra-conf[#...]]
+ In this case, kernel_addr_r is passed to bootm.
fdt <path> - if this label is chosen, use tftp to retrieve the fdt blob
at <path>. it will be stored at the address indicated in
the fdt_addr_r environment variable, and that address will
be passed to bootm.
+ For FIT image, the device tree can be provided with the same value
+ than kernel, including configuration:
+ <path>#<conf>[#<extra-conf[#...]]
+ In this case, kernel_addr_r is passed to bootm.
devicetree <path> - if this label is chosen, use tftp to retrieve the fdt blob
at <path>. it will be stored at the address indicated in
diff --git a/doc/arch/m68k.rst b/doc/arch/m68k.rst
index 770327fea21..a9180fd7850 100644
--- a/doc/arch/m68k.rst
+++ b/doc/arch/m68k.rst
@@ -93,10 +93,10 @@ Configuration to use a pre-loader
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If U-Boot should be loaded to RAM and started by a pre-loader
-CONFIG_MONITOR_IS_IN_RAM must be defined. If it is defined the
+CONFIG_MONITOR_IS_IN_RAM must be enabled. If it is enabled the
initial vector table and basic processor initialization will not
be compiled in. The start address of U-Boot must be adjusted in
-the boards config header file (CONFIG_SYS_MONITOR_BASE) and Makefile
+the boards defconfig file (CONFIG_SYS_MONITOR_BASE) and Makefile
(CONFIG_TEXT_BASE) to the load address.
ColdFire CPU specific options/settings
diff --git a/doc/arch/sandbox/sandbox.rst b/doc/arch/sandbox/sandbox.rst
index e6d84036516..cd7f8a2cb0d 100644
--- a/doc/arch/sandbox/sandbox.rst
+++ b/doc/arch/sandbox/sandbox.rst
@@ -615,7 +615,7 @@ Addr Config Usage
======= ======================== ===============================
0 CONFIG_SYS_FDT_LOAD_ADDR Device tree
c000 CONFIG_BLOBLIST_ADDR Blob list
- 10000 CONFIG_MALLOC_F_ADDR Early memory allocation
+ 10000 CFG_MALLOC_F_ADDR Early memory allocation
f0000 CONFIG_PRE_CON_BUF_ADDR Pre-console buffer
100000 CONFIG_TRACE_EARLY_ADDR Early trace buffer (if enabled). Also used
as the SPL load buffer in spl_test_load().
diff --git a/doc/arch/x86.rst b/doc/arch/x86.rst
index 634387ac095..725a1ae5863 100644
--- a/doc/arch/x86.rst
+++ b/doc/arch/x86.rst
@@ -355,8 +355,8 @@ environment variables if you add this to minnowmax.h:
"ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; " \
"run boot"
- #undef CONFIG_EXTRA_ENV_SETTINGS
- #define CONFIG_EXTRA_ENV_SETTINGS "boot=zboot 03000000 0 04000000 ${filesize}"
+ #undef CFG_EXTRA_ENV_SETTINGS
+ #define CFG_EXTRA_ENV_SETTINGS "boot=zboot 03000000 0 04000000 ${filesize}"
and change CONFIG_BOOTARGS value in configs/minnowmax_defconfig to::
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
index c71570d64b4..0b3b32be1bb 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -135,7 +135,7 @@ control the boot process of Linux with bootm/bootz commands.
To use this, put something like this in your board header file::
- #define CONFIG_EXTRA_ENV_SETTINGS "fdtcontroladdr=10000\0"
+ #define CFG_EXTRA_ENV_SETTINGS "fdtcontroladdr=10000\0"
Build:
diff --git a/doc/develop/distro.rst b/doc/develop/distro.rst
index bc72aa951ef..8016acad098 100644
--- a/doc/develop/distro.rst
+++ b/doc/develop/distro.rst
@@ -214,7 +214,7 @@ Required Environment Variables
The U-Boot "syslinux" and "pxe boot" commands require a number of environment
variables be set. Default values for these variables are often hard-coded into
-CONFIG_EXTRA_ENV_SETTINGS in the board's U-Boot configuration file, so that
+CFG_EXTRA_ENV_SETTINGS in the board's U-Boot configuration file, so that
the user doesn't have to configure them.
fdt_addr:
diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index 0fa0143bf37..92477d05dd8 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -165,8 +165,8 @@ document.
<https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`_
and similar additional tags.
-* Reviewed-by: The patch has been reviewed and found acceptible according to
- the `Reveiwer's statement of oversight
+* Reviewed-by: The patch has been reviewed and found acceptable according to
+ the `Reviewer's statement of oversight
<https://www.kernel.org/doc/html/latest/process/submitting-patches.html#reviewer-s-statement-of-oversight>`_.
A *Reviewed-by:* tag is a statement of opinion that the patch is an
appropriate modification of the code without any remaining serious technical
@@ -193,8 +193,8 @@ document.
* Cc: If a person should have the opportunity to comment on a patch, you may
optionally add a *Cc:* tag to the patch. Git tools (git send-email) will then
- automatically arrange that they receives a copy of the patch when you submit it
- to the mainling list. This is the only tag which might be added without an
+ automatically arrange that they receives a copy of the patch when you submit
+ it to the mailing list. This is the only tag which might be added without an
explicit action by the person it names. This tag documents that potentially
interested parties have been included in the discussion.
For example, when your change affects a specific board or driver, then makes
@@ -209,7 +209,7 @@ like this:
#. The responsible custodian inspects this patch, especially for:
#. The commit message is useful, descriptive and makes correct and
- appropraite usage of required *git tags*.
+ appropriate usage of required *git tags*.
#. :doc:`codingstyle`
@@ -251,7 +251,7 @@ like this:
workflows and environments however.
#. Although a custodian is supposed to perform their own tests it is a
- well-known and accepted fact that they needs help from other developers who
+ well-known and accepted fact that they need help from other developers who
- for example - have access to the required hardware or other relevant
environments. Custodians are expected to ask for assistance with testing
when required.
diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst
index 6ee67ef4459..9af63731cdc 100644
--- a/doc/develop/release_cycle.rst
+++ b/doc/develop/release_cycle.rst
@@ -69,7 +69,7 @@ For the next scheduled release, release candidates were made on::
* U-Boot v2023.01-rc3 was released on Mon 05 December 2022.
-.. * U-Boot v2023.01-rc4 was released on Mon 05 December 2022.
+* U-Boot v2023.01-rc4 was released on Mon 19 December 2022.
.. * U-Boot v2023.01-rc5 was released on Mon 19 December 2022.
diff --git a/doc/develop/sending_patches.rst b/doc/develop/sending_patches.rst
index 173075687e9..ba73d0d11b4 100644
--- a/doc/develop/sending_patches.rst
+++ b/doc/develop/sending_patches.rst
@@ -20,8 +20,8 @@ LWN article `How to Get Your Change Into the Linux Kernel
Using patman
------------
-You can use a tool called patman to prepare, check and sent patches. It creates
-change logs, cover letters and patch notes. It also simplified the process of
+You can use a tool called patman to prepare, check and send patches. It creates
+change logs, cover letters and patch notes. It also simplifies the process of
sending multiple versions of a series.
See more details at :doc:`patman`.
@@ -41,7 +41,7 @@ General Patch Submission Rules
past commits might have input to your change, so also CC them if you think
they may have feedback.
-* Patches should always contain exactly one complete logical change, i. e.
+* Patches should always contain exactly one complete logical change, i.e.
* Changes that contain different, unrelated modifications shall be submitted
as *separate* patches, one patch per changeset.
@@ -68,7 +68,7 @@ General Patch Submission Rules
as such -- that *precedes* your substantive patch.
* For minor modifications (e.g. changed arguments of a function call),
- adhere to the present codingstyle of the module. Relating checkpatch
+ adhere to the present coding style of the module. Relating checkpatch
warnings can be ignored in this case. A respective note in the commit or
cover letter why they are ignored is desired.
@@ -93,7 +93,7 @@ General Patch Submission Rules
visible as headline of your commit message. Make sure the subject does not
exceed 60 characters or so.
-* The start of the subject should be a meaningfull tag (arm:, ppc:, tegra:,
+* The start of the subject should be a meaningful tag (arm:, ppc:, tegra:,
net:, ext2:, etc)
* Include the string "PATCH" in the Subject: line of your message, e. g.
@@ -247,14 +247,14 @@ When re-posting such a new version of your patch(es), please always make sure
to observe the following rules.
* Make an appropriate note that this is a re-submission in the subject line,
- eg. "[PATCH v2] Add support for feature X". ``git format-patch
+ e.g. "[PATCH v2] Add support for feature X". ``git format-patch
--subject-prefix="PATCH v2"`` can be used in this case (see the example
below).
-* Please make sure to keep a "change log", i. e. a description of what you have
+* Please make sure to keep a "change log", i.e. a description of what you have
changed compared to previous versions of this patch. This change log should
be added below the "---" line in the patch, which starts the "comment
- section", i. e. which contains text that does not get included into the
+ section", i.e. which contains text that does not get included into the
actual commit message.
Note: it is *not* sufficient to provide a change log in some cover letter
that gets sent as a separate message with the patch series. The reason is
@@ -312,7 +312,7 @@ Notes
2. All code must follow the :doc:`codingstyle` requirements.
3. Before sending the patch, you *must* run some form of local testing.
- Submitting a patch that does not build or function correct is a mistake. For
+ Submitting a patch that does not build or function correctly is a mistake. For
non-trivial patches, either building a number of platforms locally or making
use of :doc:`ci_testing` is strongly encouraged in order to avoid problems
that can be found when attempting to merge the patch.
diff --git a/doc/develop/system_configuration.rst b/doc/develop/system_configuration.rst
index 52e4e1df15c..40be46b0823 100644
--- a/doc/develop/system_configuration.rst
+++ b/doc/develop/system_configuration.rst
@@ -86,12 +86,12 @@ When to use each mechanism
^^^^^^^^^^^^^^^^^^^^^^^^^^
While there are some cases where it should be fairly obvious where to use each
-mechanism, as for example a command would done via Kconfig, a new I2C driver
+mechanism, as for example a command would be done via Kconfig, a new I2C driver
should use Kconfig and be configured via driver model and a header of values
generated by an external tool should be ``CFG``, there will be cases where it's
less clear and one needs to take care when implementing it. In general,
configuration *options* should be done in Kconfig and configuration *settings*
-should done in driver model or ``CFG``. Let us discuss things to keep in mind
+should be done in driver model or ``CFG``. Let us discuss things to keep in mind
when picking the appropriate mechanism.
A thing to keep in mind is that we have a strong preference for using Kconfig as
@@ -122,7 +122,7 @@ to use Kconfig in this case, it would result in using calculated rather than
constructed values, resulting in less clear code. Consider the example of a set
of register values for a memory controller. Defining this as a series of logical
ORs and shifts based on other defines is more clear than the Kconfig entry that
-set the calculated value alone.
+sets the calculated value alone.
When it has been determined that the practical solution is to utilize the
``CFG`` mechanism, the next decision is where to place these settings. It is
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index e0835beba41..a944c0fb803 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -14,7 +14,7 @@ Development target
------------------
The implementation of UEFI in U-Boot strives to reach the requirements described
-in the "Embedded Base Boot Requirements (EBBR) Specification - Release v1.0"
+in the "Embedded Base Boot Requirements (EBBR) Specification - Release v2.1.0"
[2]. The "Server Base Boot Requirements System Software on ARM Platforms" [3]
describes a superset of the EBBR specification and may be used as further
reference.
@@ -799,8 +799,8 @@ Links
-----
* [1] http://uefi.org/specifications - UEFI specifications
-* [2] https://github.com/ARM-software/ebbr/releases/download/v1.0/ebbr-v1.0.pdf -
- Embedded Base Boot Requirements (EBBR) Specification - Release v1.0
+* [2] https://github.com/ARM-software/ebbr/releases/download/v2.1.0/ebbr-v2.1.0.pdf -
+ Embedded Base Boot Requirements (EBBR) Specification - Release v2.1.0
* [3] https://developer.arm.com/docs/den0044/latest/server-base-boot-requirements-system-software-on-arm-platforms-version-11 -
Server Base Boot Requirements System Software on ARM Platforms - Version 1.1
* [4] :doc:`iscsi`
diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt
index 5baec4d93e3..f9f6cc6e928 100644
--- a/doc/sphinx/requirements.txt
+++ b/doc/sphinx/requirements.txt
@@ -1,6 +1,6 @@
alabaster==0.7.12
Babel==2.9.1
-certifi==2021.10.8
+certifi==2022.12.7
charset-normalizer==2.0.12
docutils==0.16
idna==3.3
diff --git a/doc/uImage.FIT/source_file_format.txt b/doc/uImage.FIT/source_file_format.txt
index 4640e38e3cc..269e1fa0b58 100644
--- a/doc/uImage.FIT/source_file_format.txt
+++ b/doc/uImage.FIT/source_file_format.txt
@@ -247,6 +247,7 @@ o config-1
|- kernel = "kernel sub-node unit name"
|- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...]
|- loadables = "loadables sub-node unit-name"
+ |- script = "
|- compatible = "vendor,board-style device tree compatible string"
@@ -268,6 +269,8 @@ o config-1
of strings. U-Boot will load each binary at its given start-address and
may optionally invoke additional post-processing steps on this binary based
on its component image node type.
+ - script : The image to use when loading a U-Boot script (for use with the
+ source command).
- compatible : The root compatible string of the U-Boot device tree that
this configuration shall automatically match when CONFIG_FIT_BEST_MATCH is
enabled. If this property is not provided, the compatible string will be
diff --git a/doc/usage/cmd/qfw.rst b/doc/usage/cmd/qfw.rst
index b3704b92d6d..cc0e27c2779 100644
--- a/doc/usage/cmd/qfw.rst
+++ b/doc/usage/cmd/qfw.rst
@@ -31,7 +31,7 @@ kernel_addr
initrd_addr
address to which the file specified by the -initrd parameter of QEMU shall
be loaded. Defaults to environment variable *ramdiskaddr* and further to
- the value of *CONFIG_RAMDISK_ADDR*.
+ the value of *CFG_RAMDISK_ADDR*.
Examples
--------
diff --git a/doc/usage/cmd/sound.rst b/doc/usage/cmd/sound.rst
new file mode 100644
index 00000000000..d3fac243b13
--- /dev/null
+++ b/doc/usage/cmd/sound.rst
@@ -0,0 +1,41 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright 2022, Heinrich Schuchardt <xypron.glpk@gmx.de>
+
+sound command
+=============
+
+Synopsis
+--------
+
+::
+
+ sound init
+ sound play [len [freq]]
+
+Description
+-----------
+
+The *sound* command is used to play a beep sound.
+
+sound init
+ initializes the sound driver.
+
+sound play
+ plays a square wave sound. It does not depend on previously calling
+ *sound init*.
+
+len
+ duration of the sound in ms, defaults to 1000 ms
+
+freq
+ frequency of the sound in Hz, defaults to 400 Hz
+
+Configuration
+-------------
+
+The sound command is enabled by CONFIG_CMD_SOUND=y.
+
+Return value
+------------
+
+The return value $? is 0 (true) if the command succeeds, 1 (false) otherwise.
diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index 83f210d2d05..2c44e5da6aa 100644
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -89,7 +89,7 @@ Old-style C environment
Traditionally, the default environment is created in `include/env_default.h`,
and can be augmented by various `CONFIG` defines. See that file for details. In
-particular you can define `CONFIG_EXTRA_ENV_SETTINGS` in your board file
+particular you can define `CFG_EXTRA_ENV_SETTINGS` in your board file
to add environment variables.
Board maintainers are encouraged to migrate to the text-based environment as it
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 0bc82887e9e..bbd40a6e189 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -73,6 +73,7 @@ Shell commands
cmd/scp03
cmd/setexpr
cmd/size
+ cmd/sound
cmd/temperature
cmd/tftpput
cmd/true
generated by cgit v1.2.3 (git 2.0.4) at 2025-10-25 16:37:27 +0000