bbremote: implement support for GPIO operations ...

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

bbremote: implement i2c read/write support ...

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>

bbremote: add missing 'md' packet handler ...

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: new reset command ...

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>

ratp: new md and mw commands ...

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>

bbremote: rename command subparser variables ...

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>

ratp: user close may happen in SYN-RECEIVED state ...

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>

ratp: don't ignore data that may arrive in behaviour H1 ...

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>

ratp: remove FIXME comment: FIN always requires ACK ...

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>

ratp: remove bogus data checks in behavior C2 ...

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>

ratp: fix data presence check ...

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>

scripts: make __init__.py nonempty ...

Otherwise they get removed by make distclean.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

host side for barebox remote control ...

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>