From e00f75675d4696f1de8aebc1d2801eed06368f44 Mon Sep 17 00:00:00 2001 From: Thomas Huth Date: Wed, 1 Sep 2021 11:16:41 +0200 Subject: Mention the CR vs. LF problem in the documentation Let's hope that this will help to avoid that people run into the same problem again in the future. At least we've got some lines of documentation this way where we can point people to who try to use "nc" in the wrong way. Signed-off-by: Thomas Huth Signed-off-by: Alexey Kardashevskiy --- README | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/README b/README index 2944588..a06d2d8 100644 --- a/README +++ b/README @@ -266,6 +266,20 @@ New assembly code submitted to SLOF should follow the coding style guidelines for the Linux kernel [4], i.e. indent with tabs, not with spaces. +6.0 Tips and tricks +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +- Note that the serial console support is written with serial terminals in + mind. Thus SLOF only looks for CR (0x0d) characters as line endings at the + command prompt. If you want to connect to the console with a program like + "ncat" for example, you have to make sure that it indeed sends CR characters + instead of plain LF (0x0a) characters. For ncat that means that you have to + use "nc -C ..." to enable the CR-LF mode, or even better, switch the terminal + to raw mode instead, for example like this: + + stty raw -echo ; nc -U /path/to/chardev-socket-from-qemu ; stty sane + + Documentation +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -- cgit v1.1