[PATCH v2 15/16] ratp: consolidate setting the next AN or SN flags

Setting the next AN or SN flag was being done in two different ways throughout the code; e.g. here for AN: ratp_set_an(ratp_sn(hdr) + 1); or: ratp_set_an(!ratp_sn(hdr)); We define a pair of new ratp_set_next_sn() and ratp_set_next_an() macros that make it clear that the next value is

[PATCH v2 14/16] 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

[PATCH v2 16/16] 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

[PATCH v2 12/16] ratp: prefer using ratp_send_ack() in behaviour I1

Instead of manually constructing an ACK, use the ratp_send_ack() method, which already does that properly. Signed-off-by: Aleksander Morgado --- lib/ratp.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/lib/ratp.c b/lib/ratp.c index

[PATCH v2 13/16] ratp: send initial data in behaviour B if any pending

And also, use ratp_send_ack() instead of manually constructing an ACK if no data is pending to be sent. The current barebox implementation doesn't allow any queueing of data until the connection is established, so this is probably not a case that would get run anyway. Signed-off-by: Aleksander

[PATCH v2 09/16] 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: -->

[PATCH v2 10/16] ratp: fix sending ACKs without data

All ACKs without data must be built in the same way from the input message:

[PATCH v2 11/16] ratp: consolidate ratp_sn_expected() and ratp_an_expected()

This is no code change in ratp_sn_expected(), it's just rewritten in the same way as ratp_an_expected(), which follows the RFC916 approach. Signed-off-by: Aleksander Morgado --- lib/ratp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/ratp.c

[PATCH v2 08/16] 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

[PATCH v2 06/16] 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

[PATCH v2 05/16] ratp: completely ignore RST flagged packets in behavior G

The reference says: This procedure represents the behavior of the CLOSED state of a connection. All incoming packets are discarded. If the packet had the RST flag set take no action. Otherwise it is necessary to build a RST packet. So, skip building the RST packet if the incoming

[PATCH v2 03/16] ratp: send missing RST in behavior C2

The reference says: If SYN was set we assume that the other end crashed and has attempted to open a new connection. We respond by sending a legal reset:

[PATCH v2 04/16] ratp: add missing RST flag in behavior G

The reference says: If the ACK flag was set then send:

[PATCH v2 00/16] RATP logic fixes and improvements

Hey Sascha, This v2 series of patches includes just changes in the commit messages, trying to explain which of the patches apply to barebox and/or the barebox<->bbremote interactions. I did test all these patches also with RATP FS, and I didn't see any regression. I did see issues in RATP FS

[PATCH v2 07/16] ratp: fix single byte sending flagged with SO

When a single data byte is sent, it is flagged as SO and the actual data goes in the length byte within the header. Worth noting that this issue wasn't found in any barebox<->bbremote interaction because all data packets sent between them always have more than one byte (due to the barebox command

[PATCH v2 01/16] ratp: add missing transition to SYN-RECEIVED in behavior B

The reference says: If the SYN flag was set but the ACK was not set then the other end of the connection has executed an active open also. Acknowledge the SYN, choose your MDL, and send:

[PATCH v2 02/16] ratp: avoid unnecessary variable initializations

This is just a cleanup; the variables are completely initialized later on so the initial values are totally discarded anyway. Signed-off-by: Aleksander Morgado --- lib/ratp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/ratp.c

Re: Fwd: Barebox 2017.02 works great but no Linux Framebuffer... :-/

Am Mittwoch, den 21.06.2017, 17:18 +0200 schrieb gianluca: > On 06/21/2017 01:50 PM, Lucas Stach wrote: > > > The fbdev emulation in the imx-drm driver defaults to 16bpp. If you want > > to change this you need to provide the module parameter > > "legacyfb_depth=32". > > > > > > > Debian

Re: Fwd: Barebox 2017.02 works great but no Linux Framebuffer... :-/

On 06/21/2017 01:50 PM, Lucas Stach wrote: The fbdev emulation in the imx-drm driver defaults to 16bpp. If you want to change this you need to provide the module parameter "legacyfb_depth=32". Debian GNU/Linux 8 edelin ttymxc2 edelin login: root Password: Linux edelin 4.9.7-EK20170621 #1

[PATCH v2] lib/fonts: add 6x8 font

From: Sven Schneider This font is derived from linux lib/fonts/font_6x10.c. Signed-off-by: Sven Schneider [rhi: fix indentation for block /* 36 0x28 '$' */] Signed-off-by: Roland Hieber ---

[PATCH] lib/fonts: add 6x8 font

From: Sven Schneider This font is derived from linux lib/fonts/font_6x10.c. Signed-off-by: Sven Schneider --- lib/fonts/Kconfig|8 +- lib/fonts/Makefile |1 + lib/fonts/font_6x8.c | 2581

Re: Fwd: Barebox 2017.02 works great but no Linux Framebuffer... :-/

Am Mittwoch, den 21.06.2017, 13:35 +0200 schrieb gianluca: > On 06/21/2017 08:32 AM, Sascha Hauer wrote: > > Hi Gianluca, > > > > On Mon, Jun 19, 2017 at 05:49:41PM +0200, gianluca wrote: > >> Hello Lucas, Sascha and the barebox mailing list guys! > >> > >> I am back with the new boards batch

Re: Fwd: Barebox 2017.02 works great but no Linux Framebuffer... :-/

On 06/21/2017 08:32 AM, Sascha Hauer wrote: Hi Gianluca, On Mon, Jun 19, 2017 at 05:49:41PM +0200, gianluca wrote: Hello Lucas, Sascha and the barebox mailing list guys! I am back with the new boards batch release (now QuadPlus and DualLite iMX6) Now I adapted barebox to fit both processors

Re: [PATCH 0/3] Fix "i.MX: vf610: Ramp CPU clock to maximum frequency"

On Tue, Jun 20, 2017 at 08:41:59PM -0700, Andrey Smirnov wrote: > On Tue, Jun 20, 2017 at 12:35 AM, Sascha Hauer wrote: > > On Mon, Jun 19, 2017 at 07:40:36AM -0700, Andrey Smirnov wrote: > >> Everyone, > >> > >> It looks like my test setup was somehow contaminated --

Re: Fwd: Barebox 2017.02 works great but no Linux Framebuffer... :-/

Hi Gianluca, On Mon, Jun 19, 2017 at 05:49:41PM +0200, gianluca wrote: > Hello Lucas, Sascha and the barebox mailing list guys! > > I am back with the new boards batch release (now QuadPlus and DualLite iMX6) > > Now I adapted barebox to fit both processors and it works quite well. > > From