A textline is a line of text which can be edited by the user. It has a
maximum length (in chracters) but otherwise there are no restrictions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add the CLI state, a buffer to hold the old value of the text being
edited and a place to save vidconsole entry context. These will be use
by the textline object.
Set an upper limit on the maximum number of characters in a textline
object supported by expo, at least for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
So far only menus have a background. When other object types are
rendered, they may have a background too. Make this code more generic
so it will be usable by new object types.
Signed-off-by: Simon Glass <sjg@chromium.org>
When the devicetree is too small for the property being written, we need
to expand the devicetree and retry the write.
Put this logic into a function so it can be reused.
Signed-off-by: Simon Glass <sjg@chromium.org>
So far only menus can be highlighted. With the coming addition of
text lines we need to be able to highlight other objects. Add a function
to determine whether an object can be highlighted.
Signed-off-by: Simon Glass <sjg@chromium.org>
In a lot of cases menus are the only objects which are have their own
behaviour in the cedit, e.g. to move between menus. With expo expanding
to support text, this is no-longer true.
Use a switch() statement so that we can simply insert a new 'case' for
the new object types.
Signed-off-by: Simon Glass <sjg@chromium.org>
When building an expo fails, show some information about which node
caused the problem. Use -ENOENT consistently when the ID is missing.
This makes it easier for the user to debug things.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add rudimentary support for displaying a cursor on a vidconsole. This
helps the user to see where text is being entered.
The implementation so far is very simple: the cursor is just a vertical
bar of fixed width and cannot be erased. To erase the cursor, the text
must be redrawn over it.
This is good enough for expo but will need enhancement to be useful for
the command-line console. For example, it could save and restore the
area behind the cursor.
For now, enable this only for expo, to reduce code size.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this is called only when a newline is detected, since this
indicates the start of a line of text being entered.
Export this function so it can be used by expo, which may start a new
text line itself, without first writing out a newline.
Signed-off-by: Simon Glass <sjg@chromium.org>
Text entry operates within a context which includes quite a bit of
information. For example, with Truetype fonts, each character in the
text string has a position stored, so that it is possible to
backspace to that character. This information is built up as strings
are drawn on the display.
For the command line, there is just a single context. It is created
when command-line entry starts and it is destroyed (or at least not
needed anymore) when the user presses <enter> to enter the command.
By contrast, expo needs to be able to switch in and out of a text-entry
context, since it is also displaying other objects in the scene.
Add a way to save and restore the entry context for a vidconsole. This
is only needed for the truetype vidconsole, so add a method for that,
storing the information in an abuf struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present there is a method for measuring text, but if the actual text
string is not known, it cannot be used.
For text editor we want to set the size of the entry box to cover the
expected text size. Add the concept of a 'norminal' size with a method
to calculate that for the vidconsole.
If the method is not implemented, fall back to using the font size,
which is sufficient for fixed-width fonts.
Signed-off-by: Simon Glass <sjg@chromium.org>
When inputting text outside the command line we don't want to use tab
for command completion. Add an option to control this.
Signed-off-by: Simon Glass <sjg@chromium.org>
When inputting text outside the command line we don't want history to be
accessible. Add an option to control this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than relying on the caller, terminate the string inside this
function. Do this each time we return, whether input is finished or
not. It is not needed when the input is aborted, since the string will
be discarded in that case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move most of the inner loop from cread_line() into a new function. This
will allow using it from other code.
This involves adding a few more members to the state struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reduce the indentation level of this code so it is easier to review the
next patch, which moves it into a function.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to reuse the editing code elsewhere. As a first step, move the
common variables into a struct. This will allow us to eventually put the
contents of the inner loop in a function, so it can be called from
elsewhere.
Signed-off-by: Simon Glass <sjg@chromium.org>
The index values are not very large so it makes no sense to use a long
integer. Change these to uint instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
The Ctrl-W option is implemented in the cread_line_simple() but not in
the full version. This seems odd, so add an implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is a function for this but it is never used. Showing the history is
a useful feature, so add a new 'history' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is part of a longer series, which isn't quite ready. Revert this
for now at least.
This reverts commit 4cb6c8e5f0.
Signed-off-by: Tom Rini <trini@konsulko.com>
To quote the author:
I'm submitting a patch series that ports the gen_compile_commands.py
script from the Linux kernel's sources to U-Boot. This script,
originally located in scripts/clang-tools/gen_compile_commands.py,
enables the generation of compile_commands.json file for improved code
navigation and analysis. The series consists of the initial script
import, the necessary modifications for U-Boot compatibility, and
finally some documentation.
Replace mentions to 'kernel' by 'U-Boot' to avoid confusion.
Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
Add 'Integration with IDEs' chapter.
For now, this chapter is mostly a reference to the documentation of
gen_compile_commands, in doc/build, but it can be futurely used as
a guide for other IDE-friendly features.
Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
This documentation briefly explains what is a compilation database,
and how to use the script to generate one.
This is not a portage, as there was no original documentation in the
Linux sources.
Acknowledge the documentation in the script's header and in doc/build
index.
Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
Add Clang's compilation database file (i.e. compile_commands.json) to
.gitignore, at the root of the repository.
Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
Add acknowledgments for porting and modifying the script. Of course, the
license, author, and copyright notice remain the same as in the original
script.
Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
The referred tool is now in U-Boot. Replace "the Linux kernel" by
"U-Boot" to make the docstring coherent.
Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
For U-Boot's context, the regular expression defined by _LINE_PATTERN
should be adapted. Replace 'savedcmd' by 'cmd'.
Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
This script generates a database of compiler flags, namely
compile_commands.json. It is quite useful for text editors that use
clangd LSP (e.g. Vim, Neovim).
It was ported from Linux's sources:
- tag: v6.4
- revision 6995e2de6891c724bfeb2db33d7b87775f913ad1
Modifications for U-Boot compatibility will be added in a follow-up
commit.
Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
- Assorted TI K3 updates, use ".dtso" for device tree overlays to match
general usage, mkimage fixes/improvements, assorted platform
updates/fixes, other assorted driver/platform fixes.
All K3 boards now are secure by default, instead of setting this in each
defconfig, make it implied by the ARCH config.
The only exception is IOT2050, which I do not believe will have any
problems with being a TI_SECURE_DEVICE, but for now turn it off to keep
its config the same.
Signed-off-by: Andrew Davis <afd@ti.com>
Tested-by: Tom Rini <trini@konsulko.com>
K3 devices have runtime type board detection. Make the default defconfig
include the secure configuration. Then remove the HS specific config.
Non-HS devices will continue to boot due to runtime device type detection.
Signed-off-by: Andrew Davis <afd@ti.com>
Tested-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
As the code to switch an ARM core from secure to the non-secure state
needs to know the base address of the Generic Interrupt Controller
(GIC), we read an Arm Cortex defined system register that is supposed to
hold that base address. However there are SoCs out there that get this
wrong, and this CBAR register either reads as 0 or points to the wrong
address. To accommodate those systems, so far we use a macro defined in
some platform specific header files, for affected boards.
To simplify future extensions, replace that macro with a Kconfig variable
that holds this override address, and define a default value for SoCs
that need it.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>
DM_DRIVER_GET will redeclare the fs_loader driver without the correct
alignment. This causes GCC to use the default section alignment of 32
bytes. This in turn creates a gap in the linker list due to the padding
required to achieve the correct alignment, corrupting all further entries.
Use DM_DRIVER_REF instead, which doesn't redeclare anything.
Fixes: 0998a20cfc ("misc: fs_loader: Add function to get the chosen loader")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
The man page correctly said that -B was ignored without -E, while the
`mkimage -h` output suggested otherwise. Now that -B can actually be
used by itself, update the man page.
While at it, also amend the `mkimage -h` line to mention the
connection with -E.
The FDT header is a fixed 40 bytes, so its size cannot (and is not)
modified, while its alignment is a property of the address in RAM one
loads the FIT to, so not something mkimage can affect in any way. (In
the file itself, the header is of course at offset 0, which has all
possible alignments already.)
Reported-by: Sean Anderson <seanga2@gmail.com>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Moving towards using .dtso for overlay sources, update the
documentation examples to follow that pattern.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Distinguish more clearly between source files meant for producing .dtb
from those meant for producing .dtbo. No functional change, as we
currently have rules for producing a foo.dtbo from either foo.dts or
foo.dtso.
Note that in the linux tree, all device tree overlay sources have been
renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Distinguish more clearly between source files meant for producing .dtb
from those meant for producing .dtbo. No functional change, as we
currently have rules for producing a foo.dtbo from either foo.dts or
foo.dtso.
Note that in the linux tree, all device tree overlay sources have been
renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Distinguish more clearly between source files meant for producing .dtb
from those meant for producing .dtbo. No functional change, as we
currently have rules for producing a foo.dtbo from either foo.dts or
foo.dtso.
Note that in the linux tree, all device tree overlay sources have been
renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Distinguish more clearly between source files meant for producing .dtb
from those meant for producing .dtbo. No functional change, as we
currently have rules for producing a foo.dtbo from either foo.dts or
foo.dtso.
Note that in the linux tree, all device tree overlay sources have been
renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
