| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Introduce three new RATP commands that allow getting and setting GPIO
values as well as configuring the direction of the GPIO pins.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce two new RATP commands that allow running i2c read/write
operations, very similar in format to the already existing md/mw
RATP commands.
The messages are defined with a fixed 16-bit long register field, but
it will only be treated as a 16-bit address if I2C_FLAG_WIDE_ADDRESS
is set in the message flags field. If this flag is unset, the start
register address is assumed 8-bit long.
If the message includes the I2C_FLAG_MASTER_MODE flag, the start
register field is ignored and a i2c master send/receive operation is
performed.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
| |
E.g.:
$ ./bbremote -v --port /dev/ttyUSB2 reset
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces support for running the md and mw commands
using the binary interface provided by RATP. This allows clients to
read and write memory files without needing to do custom string
parsing on the data returned by the console 'md' and 'mw' operations.
The request and response messages used for these new operations are
structured in the same way:
* An initial fixed-sized section includes the fixed-sized
variables (e.g. integers), as well as the size and offset of the
variable-length variables.
* After the initial fixed-sized section, the buffer is given, which
contains the variable-length variables in the offsets previously
defined and with the size previously defined.
The message also defines separately the offset of the buffer
w.r.t. the start of the message. The endpoint reading the message will
use this information to decide where the buffer starts. This allows to
extend the message format in the future without needing to break the
message API, as new fields can be appended to the fixed-sized section
as long as the buffer offset is also updated to report the new
position of the buffer.
E.g.:
$ ./bbremote --port /dev/ttyUSB2 md /dev/pic_eeprom_rdu 0x107 5
0000000000
$ ./bbremote --port /dev/ttyUSB2 mw /dev/pic_eeprom_rdu 0x107 0102030405
5 bytes written
$ ./bbremote --port /dev/ttyUSB2 md /dev/pic_eeprom_rdu 0x107 5
0102030405
$ ./bbremote --port /dev/ttyUSB2 mw /dev/pic_eeprom_rdu 0x107 0000000000
5 bytes written
$ ./bbremote --port /dev/ttyUSB2 md /dev/pic_eeprom_rdu 0x107 5
0000000000
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The RATP implementation now allows executing generic commands with a
binary interface: binary requests are received and binary responses
are returned.
Each command can define its own RATP request contents (e.g. to specify
command-specific options) as well as its own RATP response contents
(if any data is to be returned).
Each command is associated with a pair of numeric unique request and
response IDs, and for easy reference these IDs are maintained in the
common ratp_bb header. Modules may override generic implemented
commands or include their own new ones (as long as the numeric IDs
introduced are unique).
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
| |
This struct type is used in the RATP FS implementation, but was never
used as a list element anywhere.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
| |
The ratp_run_command() is really an implementation detail of the
barebox ratp 'command' operation support. Move it to the barebox
specific header and rename it with the correct prefix.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
This adds the ability to control barebox over serial lines. The regular
console is designed for human input and is unsuitable for controlling
barebox from scripts since characters can be lost on both ends, the data
stream contains escape sequences and the prompt cannot be easily matched
upon.
This approach is based on the RATP protocol. RATP packages start with a
binary 0x01 which does not occur in normal console data. Whenever a
0x01 character is detected in the console barebox goes into RATP mode.
The RATP packets contain a simple structure with a command/respone
type and data for that type. Currently defined types are:
BB_RATP_TYPE_COMMAND (host->barebox):
Execute a command in the shell
BB_RATP_TYPE_COMMAND_RETURN (barebox->host)
Sends return value of the command back to the host, also means
barebox is ready for the next command
BB_RATP_TYPE_CONSOLEMSG (barebox->host)
Console message from barebox
Planned but not yet implemented are:
BB_RATP_TYPE_PING (host->barebox)
BB_RATP_TYPE_PONG (barebox->host)
For testing purposes
BB_RATP_TYPE_GETENV (host->barebox)
BB_RATP_TYPE_GETENV_RETURN (barebox->host)
Get values of environment variables
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Andrey Smirnov <andrew.smirnov@gmail.com>
|
