| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
We need to advance the input buffer used to create messages when the
data doesn't fit in a single RATP packet.
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>
|
|
|
This patch adds support for Reliable Asynchronous Transfer Protocol (RATP)
as described in RFC916.
Communication over RS232 is often unreliable as characters are lost or
misinterpreted. This protocol allows for a reliable packet based communication
over serial lines.
The implementation simply follows the state machine described in the RFC
text with one exception. RFC916 uses a plain checksum for the
transferred data. We decided to use CRC16 for greater robustness. Since
this is the only RFC916 implementation we currently know of interoperability
with other implementations should not matter.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Andrey Smirnov <andrew.smirnov@gmail.com>
|
