| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the bbremote script with operations to perform binary i2c
read/write operations.
E.g.:
barebox:/ i2c_read -b 0 -a 0x68 -r 0x06A0 -c 4 -w
0x8f 0x30 0x00 0x00
barebox:/ i2c_write -b 0 -a 0x68 -r 0x06A0 -w 0x87 0x30 0x00 0x00
barebox:/ i2c_read -b 0 -a 0x68 -r 0x06A0 -c 4 -w
0x87 0x30 0x00 0x00
barebox:/ i2c_write -b 0 -a 0x68 -r 0x06A0 -w 0x8f 0x30 0x00 0x00
barebox:/ i2c_read -b 0 -a 0x68 -r 0x06A0 -c 4 -w
0x8f 0x30 0x00 0x00
===================================================================
$ ./scripts/bbremote --port /dev/ttyUSB2 i2c-read 0x00 0x68 0x06A0 0x01 4
8f300000
$ ./scripts/bbremote --port /dev/ttyUSB2 i2c-write 0x00 0x68 0x06A0 0x01 "87300000"
4 bytes written
$ ./scripts/bbremote --port /dev/ttyUSB2 i2c-read 0x00 0x68 0x06A0 0x01 4
87300000
$ ./scripts/bbremote --port /dev/ttyUSB2 i2c-write 0x00 0x68 0x06A0 0x01 "8f300000"
4 bytes written
$ ./scripts/bbremote --port /dev/ttyUSB2 i2c-read 0x00 0x68 0x06A0 0x01 4
8f300000
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
Don't reuse unrelated subparser variables for new command subparsers,
make each subparser have its own variable.
Just for consistency really, not a bugfix.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reference says:
5.2.3. SYN-RECEIVED
...
Departures
- A CLOSE request is made by the user. Create a packet with
FIN set. Send it and go to the FIN-WAIT state.
Add this missing step.
Probably not a real usecase for barebox anyway as there is no user
triggered close.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an input packet arrives H1 that has data in it, we need to:
* track sn_received
* if we have data pending, send it
* if we don't have data pending, send a plain ACK
This process, as noted in RFC916, is the same as the I1 procedure, so
go and run it:
Go to the ESTABLISHED state and execute procedure I1 to process
any data which might be in this packet.
This fix allows the peer to queue data in the last packet doing the
connection establishment. It doesn't apply to the barebox<->bbremote
interaction because bbremote won't queue data until the connection is
completely established, but it allows third party ratp implementations
to do that.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Section 3.4 in the RFC916 shows a packet flow for the connection close
where the initial packet sent by the endpoint starting the close has
just the FIN flag set, without an ACK:
--> <SN=0><AN=1><CTL=FIN>
<SN=1><AN=1><CTL=FIN,ACK> <--
--> <SN=1><AN=0><CTL=ACK>
This may lead to think that it is actually allowed to send the initial
packet with just FIN set, without ACK-ing any other packet from the
peer.
But, this is actually not possible, the packet MUST be ACK-ing a
previous packet from the peer, even if this is just a duplicated ACK,
because otherwise the packet with the FIN wouldn't get processed in
the H2 behavior (FIN processing) of the peer, as the F2 behavior (ACK
processing) would filter it out.
This is actually the same reasoning why data packets always have ACK
set, even if the same ACK has already been sent previously (e.g. with
a simple ACK packet without data); if they didn't have it, they would
be filtered out in the F2 behavior, never arriving the I1 behavior,
which is where the received data is processed.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SN validation was being completely ignored if the packet had no
data (e.g. for RST, FIN or SYN or plain ACKs). This condition is now
removed so that the SN check is done.
The second check removed was actually never being used, as it was
already being tested for not having data in the first one.
These two fixes are a cleanup to follow the protocol correctly.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Looking at the "data length" and SO flag isn't enough to declare a
packet with or without data, because SYN flagged packets will also use
the "data length" field to define MDL.
So, improve the check to match against SYN|RST|FIN flagged packets,
which can never have data.
This commit fixed a segfault in barebox when an unexpected SYN packet
was sent in the middle of a connection; barebox thought the packet had
data because the "data length" in the SYN packet was different than 0.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
| |
Otherwise they get removed by make distclean.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
This contains the host tool for barebox remote control. It is written in
Phython with its own implementation of the RATP protocol. Currently this
is a very simple tool which needs more work, but the code can also be
used as a library.
Example output:
console: '. '
console: '.. '
console: 'dev '
console: 'env '
console: 'mnt '
console: '\n'
Result: BBPacketCommandReturn(exit_code=0)
Signed-off-by: Jan Lübbe <j.luebbe@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Tested-by: Andrey Smirnov <andrew.smirnov@gmail.com>
|
