mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Aleksander Morgado <aleksander@aleksander.es>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 00/16] RATP logic fixes and improvements
Date: Mon, 19 Jun 2017 11:37:12 +0200	[thread overview]
Message-ID: <20170619093712.qyb2uvi64xjjnznd@pengutronix.de> (raw)
In-Reply-To: <437cc444-41fc-0cb4-57ce-8fdb6b0af74e@aleksander.es>

On Mon, Jun 19, 2017 at 11:07:09AM +0200, Aleksander Morgado wrote:
> Hey,
> 
> On 19/06/17 08:46, Sascha Hauer wrote:
> >> I went through the RFC916 and ended up preparing a set of fixes and improvements for the RATP logic in barebox.
> >> Let me know what you think.
> > As far as I can say the patches look good. It's quite a while since I
> > last looked at the RATP code, so I can't really judge. To which extent
> > are the patches tested? Have you explicitly tested for the corner cases
> > you fix in each patch? You probably have tested against your new
> > library. Have you also tested against the python implementation?
> 
> I did test against bbremote, and also did several fixes there as well.
> I haven't tested against the "ratp filesystem support" feature though,
> maybe I should do that as well.

That would be great, yes.

> 
> Regarding which corner cases are tested, well, some of them apply to
> code paths that I believe wouldn't really apply to barebox right now
> (e.g. barebox doing active open at the same time as bbremote doing
> active open), so that's hard to test.

Indeed, yes. This path has been untested before aswell.

> I could go one by one over each
> patch and try to provide logs before/after applying the patch, how
> about that?

I don't think that's necessary. It might be worth noting to the commit
messages which patches you made because there was something not working
and which patches you made because the standard was not correctly
implemented.

> 
> BTW; how would you debug barebox (e.g. get the debug messages
> generated) while testing the RATP link over the TTY? Right now I
> validated the barebox behavior just by looking at which RATP messages
> were returned to me.

Use different consoles for debug messages and RATP. During development
we used a board with two serial ports, but you could also use network
console as an alternative console.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

      reply	other threads:[~2017-06-19  9:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-15 11:14 Aleksander Morgado
2017-06-15 11:14 ` [PATCH 01/16] ratp: add missing transition to SYN-RECEIVED in behavior B Aleksander Morgado
2017-06-15 11:14 ` [PATCH 02/16] ratp: avoid unnecessary variable initializations Aleksander Morgado
2017-06-15 11:14 ` [PATCH 03/16] ratp: send missing RST in behavior C2 Aleksander Morgado
2017-06-15 11:14 ` [PATCH 04/16] ratp: add missing RST flag in behavior G Aleksander Morgado
2017-06-15 11:14 ` [PATCH 05/16] ratp: completely ignore RST flagged packets " Aleksander Morgado
2017-06-15 11:14 ` [PATCH 06/16] ratp: fix data presence check Aleksander Morgado
2017-06-15 11:14 ` [PATCH 07/16] ratp: fix single byte sending flagged with SO Aleksander Morgado
2017-06-15 11:14 ` [PATCH 08/16] ratp: remove bogus data checks in behavior C2 Aleksander Morgado
2017-06-15 11:14 ` [PATCH 09/16] ratp: remove FIXME comment: FIN always requires ACK Aleksander Morgado
2017-06-15 11:14 ` [PATCH 10/16] ratp: fix sending ACKs without data Aleksander Morgado
2017-06-15 11:14 ` [PATCH 11/16] ratp: consolidate ratp_sn_expected() and ratp_an_expected() Aleksander Morgado
2017-06-15 11:14 ` [PATCH 12/16] ratp: prefer using ratp_send_ack() in behaviour I1 Aleksander Morgado
2017-06-15 11:14 ` [PATCH 13/16] ratp: send initial data in behaviour B if any pending Aleksander Morgado
2017-06-15 11:14 ` [PATCH 14/16] ratp: don't ignore data that may arrive in behaviour H1 Aleksander Morgado
2017-06-15 11:14 ` [PATCH 15/16] ratp: consolidate setting the next AN or SN flags Aleksander Morgado
2017-06-15 11:14 ` [PATCH 16/16] ratp: user close may happen in SYN-RECEIVED state Aleksander Morgado
2017-06-19  6:46 ` [PATCH 00/16] RATP logic fixes and improvements Sascha Hauer
2017-06-19  9:07   ` Aleksander Morgado
2017-06-19  9:37     ` Sascha Hauer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170619093712.qyb2uvi64xjjnznd@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=aleksander@aleksander.es \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox