Is the baud rate for the uarts limited

christian.moll · Oct 31st 2013

Hi,

we use the PicoCOM4 with a self compiled version of the latest 1.4 Kernel. And run now in the problem that the port ttySAC1 seams not to run on the right baud rate. I changed the serial example to cfsetispeed(&options, B115200);
cfsetospeed(&options, B115200);

where case B115200: inputSpeed = 115200; break;

after opening the port I send known data to the port but only get crap. For control I read the stream with a logic analyzer in parallel. These data is correct. I notized that the logic analyzer determined the baud rate of some packages I send from the ttySAC1 to the test device is only 39215 bps.

Any idea where this behaviour comes from? I suspected the serial console in the kernel parameters, but redirecting the console to tty0 doesn't change anything.

Sincerely yours

Christian Moll

fs-support_HK · Oct 31st 2013

The serial console is by default configured for 38400 bps. This is done in NBoot. However this is no big deal as NBoot does not send anything during a standard boot sequence. But then U-Boot is starting. U-Boot will output some messages and will use 38400 for this. The kernel will use the speed that is configured on the kernel command line, i.e. in the bootargs variable in U-Boot. And finally buildroot may also use a fix speed when starting its getty on the serial line (see /ect/inittab).

So you have to change the speed in several places:

1. U-Boot (can be done by setting some environment variable as far as I know)
2. Kernel (can be done by setting the bootargs variable in U-Boot)
3. The getty in buildroot (/etc/inittab)
4. In your own application

Your F&S Support Team

christian.moll · Nov 4th 2013

Thanks for your reply.

I redirected the kernel console to /dev/tty0 (no speed specified) by console=/dev/tty0
And disabled the framebuffer console support in the Kernel.
I commented the getty call in inittab.
I didn't change anything for the uboot.
I set the speed with the simpleserial example. Once to B19200 and once to B115200 (which I added to the switch case statement).

When sniffing on the serial line with a logic analyzer I always get 38400 as a result for the outgoing stream.
Is it really necessary to change the speed on all stages? My understanding was that I only have to redirect the kernel console and set the speed I like to have via terminos API.

Any idea?

Christian Moll

P.S.
With setserial -a I get:

Quote

# setserial -a /dev/ttySAC0
/dev/ttySAC0, Line 0, UART: undefined, Port: 0x0000, IRQ: 70
Baud_base: 0, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal

# setserial -a /dev/ttySAC1
/dev/ttySAC1, Line 1, UART: undefined, Port: 0x0000, IRQ: 73
Baud_base: 0, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal

Display More

fs-support_HK · Nov 4th 2013

Just to be sure: you set the serial speed in your program and use the serial line directly within the same program? Or do you set the serial speed with one program and then want to output data in a different program, without setting the speed again? The second approach will not work. When the serial port is closed again, the port is reset again to the original speed. So the second program will use the default speed again. You always have to set the speed when you open a serial port, before you output anything to the port. The speed is not persistent after closing the port until opening it again.

christian.moll · Nov 5th 2013

That is clear to me. I use the simpleserial example to set the speed, write and read to the port. But when sniffing on the port I get always 38.4kbps independent from the speed I set in the example.

christian.moll · Nov 5th 2013

Did some more research on the problem.

When I change
#define CONFIG_BAUDRATE 57600
in the picocom4.h of the uboot 1.4 sources.

I have the baud rate of ttySAC1 afterwards on 57600 (also checked this by the logic analyzer)

Then I found a interesting comment in the file mach-picocom4.c of the Kernel

Quote

/* UART1 is the debug port and it is already configured by the boot
loader U-Boot/NBoot; nothing to do here */

looks for me that the console I set in the bootargs is not respected in total. In my understanding it should close the serial port I use to access the uboot and open the device I specified in the bootargs with the given speed. And the device not used for the console should be fully usable after Kernel is up.

fs-support_HK · Nov 12th 2013

The comment in the Linux file simply means that we do not need to configure the pin multiplexing (UART function) and pad control (pull-up/down, drive strength, etc) anymore as it was already done earlier. This has nothing to do with the baud rate. As you can see, the other ports also don't get any baud rate set in this place.

And yes, if you set a baud rate in U-Boot, then this baud rate will be used in U-Boot, and if you don't set a different baud rate for Linux, it will also be used as default baud rate in Linux. So if you open this port in Linux and don't set your own speed, you will get this baud rate.

Let's summarize.

Case 1: You set "console=ttySAC1,sss" in U-Boot
Then the kernel will open this serial line with the given speed sss to send boot messages. Then the Buildroot system takes over and the init function will execute /etc/inittab. There a getty is started, that also uses the debug line. This used to be a fix port (ttySAC1) and a fix speed (38400), but in V1.4 this was changed and now the getty is opened on the first console found in /proc/consoles and the speed is left on the kernel default. Whether this now results in the speed configured in U-Boot or the one set with console= above I can not say at the moment. I would have assumed that it is the speed set with console=, but if the console is actually closed again before getty is started, then the speed of this port may be reset to the default speed, i.e. the speed promoted by U-Boot.

Case 2: You don't set "console=ttySAC1,sss" in U-Boot
Then the kernel will not open the serial console and in V1.4 there will also be no getty on the serial port. So the speed of ttySAC1 will remain at the default speed, i.e. the speed set in U-Boot.

In any case
However in any case, if you want to use this port, you have to open the ttySAC1 device and as one of the first actions you set a new speed, transfer format, flow control, etc for this file handle. And when doing this, you can set whatever speed you like. This speed will remain active until you close the filehandle again and then the port will either stay on this speed or it may switch back to the default speed, whichever it is what Linux does when a port is closed.

So using a serial port is always:

1. open the port
2. set transfer speed and other transmission parameters
3. use the port
4. close the port

And *not*:

1. open the port
2. use the port
3. close the port

Because then you'll never know for sure what the default parameters are and you may end up sending crap.

So where is the problem? Why can't you set a speed after opening the device and before sending/receiving anything? Or do I miss your point?

Your F&S Support Team

christian.moll · Nov 12th 2013

Seams so.

I repeated the hole experiment.

1. new PicoCOM4
2. I installed the 1.4 Kernel provided by F&S
3. I installed the buildrootFS 1.4 provided by F&S
4. set root password to access by ssh, deleted S99.. S35... and S01fs... scripts in /etc/init.d
5. changed bootargs console to console=tty0
6. commented out the the getty line in /etc/inittab. (removed it to be sure it has not a side effect)
7. reboot the system and executed the simpleserial example. See source code below...

Quote

Case 2: You don't set "console=ttySAC1,sss" in U-Boot
Then the kernel will not open the serial console and in V1.4 there will also be no getty on the serial port. So the speed of ttySAC1 will remain at the default speed, i.e. the speed set in U-Boot.

The example states that the baud rate was 9600! In the u-boot the baud is set to 38400!
The example also states that the speed is set to 115200bps, and writes "Testmessage" to the port.
I record this "Testmessage" with a logic-analyzer. It has some nice protocol analysis features like determine the baud rate and what data where in the stream.
It says the speed is ~38400bps and the Message was "Testmessage". If I set it to 1115200bps it only gets crap as incoming message.

As you can see below the port is set to 115200 8N1.

Quote

So using a serial port is always:

1. open the port --> fopen(...)
2. set transfer speed and other transmission parameters --> initport(...)
3. use the port-->write(...)
4. close the port-->close(...)

Looks like the example is doing as you described.

To summarize.
1. Buad rate set in u-boot doesn't have an effect on default baud rate when console=<virtual console> is set in bootargs. Terminos claims that it is 9600 on first open.
2. Setting baud rate with terminos claims the right buad is set, but in real it stays on the rate set in u-boot.

If I repeat the experiment with a different baud rate set in u-boot. That baud rate will be the measured value by the logic analyzer.

So why is the the speed not set? Why is the first speed read out of the port 9600 and not the one from the u-boot?

C

/* ser.c
*/
#include <stdio.h> /* Standard input/output definitions */
#include <string.h> /* String function definitions */
#include <unistd.h> /* UNIX standard function definitions */
#include <fcntl.h> /* File control definitions */
#include <termios.h> /* POSIX terminal control definitions */
int getbaud(int fd) {
struct termios termAttr;
int inputSpeed = -1;
speed_t baudRate;
tcgetattr(fd, &termAttr);
/* Get the input speed. */
baudRate = cfgetispeed(&termAttr);
switch (baudRate) {
case B0: inputSpeed = 0; break;
case B50: inputSpeed = 50; break;
case B110: inputSpeed = 110; break;
case B134: inputSpeed = 134; break;
case B150: inputSpeed = 150; break;
case B200: inputSpeed = 200; break;
case B300: inputSpeed = 300; break;
case B600: inputSpeed = 600; break;
case B1200: inputSpeed = 1200; break;
case B1800: inputSpeed = 1800; break;
case B2400: inputSpeed = 2400; break;
case B4800: inputSpeed = 4800; break;
case B9600: inputSpeed = 9600; break;
case B19200: inputSpeed = 19200; break;
case B38400: inputSpeed = 38400; break;
case B115200: inputSpeed = 115200; break;
}
return inputSpeed;
}
int initport(int fd) {
struct termios options;
// Get the current options for the port...
tcgetattr(fd, &options);
// Set the baud rates to 19200...
cfsetispeed(&options, B115200);
cfsetospeed(&options, B115200);
// Enable the receiver and set local mode...
options.c_cflag |= (CLOCAL | CREAD);
options.c_cflag &= ~PARENB;
options.c_cflag &= ~CSTOPB;
options.c_cflag &= ~CSIZE;
options.c_cflag |= CS8;
// Set the new options for the port...
tcsetattr(fd, TCSAFLUSH, &options); //TCSANOW
return 1;
}
int main(int argc, char **argv) {
int fd=-1;
int ret=-1;
//char sResult[254];
char text[] = "Testmessage";
fd = open("/dev/ttySAC1", O_RDWR | O_NOCTTY | O_NONBLOCK | O_SYNC);
if (fd == -1) {
perror("open_port: Unable to open /dev/ttySAC1 - ");
return 1;
}
else {
fcntl(fd, F_SETFL, 0);
}
printf("baud=%d \n", getbaud(fd));
initport(fd);
printf("baud=%d \n", getbaud(fd));
ret = write(fd,text,11);
printf("wrote %u bytes \n",ret);
printf("reading from port...\n");
/*ret = read(fd, &sResult, sizeof(sResult));
sResult[ret-1] = 0x00;
printf("read %u bytes from port. Message is %s\n", ret, sResult);
*/
close(fd);
return 0;
}

Display More

fs-support_HK · Nov 14th 2013

OK, i have checked the serial driver and found some special handling for the debug port (ttySAC1) on PicoCOM4, that may have had some meaning in the past, but I don't see that it is still required today. This special handling causes the baud rate setting not to function correctly. The following patch will remove this special handling and then the serial port speed should behave as expected.

Sorry, I was not aware that this special handling existed in the kernel.

Diff

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 168ac5f..6d2407b 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -693,10 +693,7 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
if (ourport->clksrc != clksrc || ourport->baudclk != clk) {
dbg("selecting clock %p \n", clk);
-#ifdef CONFIG_MACH_PICOCOM4
- if(port->line != 1)
-#endif
- s3c24xx_serial_setsource(port, clksrc);
+ s3c24xx_serial_setsource(port, clksrc);
if (ourport->baudclk != NULL && !IS_ERR(ourport->baudclk)) {
clk_disable(ourport->baudclk);
@@ -764,14 +761,9 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
dbg("setting ulcon to %08x, brddiv to %d, udivslot %08x\n",
ulcon, quot, udivslot);
-#ifdef CONFIG_MACH_PICOCOM4
- if(port->line != 1)
-#endif
- {
- wr_regl(port, S3C2410_ULCON, ulcon);
- wr_regl(port, S3C2410_UBRDIV, quot);
- wr_regl(port, S3C2410_UMCON, umcon);
- }
+ wr_regl(port, S3C2410_ULCON, ulcon);
+ wr_regl(port, S3C2410_UBRDIV, quot);
+ wr_regl(port, S3C2410_UMCON, umcon);
if (ourport->info->has_divslot)
wr_regl(port, S3C2443_DIVSLOT, udivslot);

Display More

The patch is also attached to this posting. Just go to the top directory of the kernel source and type

Code

patch -p1 < Remove-special-handling-of-debug-port.patch

Then recompile the kernel.

Sorry for the inconvenience.

Your F&S Support Team

christian.moll · Nov 15th 2013

Hello,

thanks for the patch. I applied it, but didn't made it better. The ttySAC0 doesn't talk at all now. Openening and setting baud in terminos still gives the right answers, but the test message is now not send and simpleserial example doesn't close the port any more.

On ttySAC1 is sending data out, but the closing of the port hangs the simpleserial example too.

Any educated guess?

Christian Moll

christian.moll · Nov 26th 2013

Hi,

is this issue closed for F&S or can we hope for a solution?

Sincerely yours

Christian Moll

fs-support_HK · Nov 28th 2013

We will investigate this further, but at the moment we have to bring a Vybrid release on the way.

fs-support_MR · Dec 13th 2013

Hello,
I tried your program with a new Kernel V1.4 and the patch above and it worked.

All steps I did: I downloaded and installed the newest available Kernel source (V1.4) and the newest toolchain (4.7.2). The above patch was applied in the kernel root path (e.g. ~/linux/linux-2.6.38-f+s-V1.4/). Then I built the kernel with make picocom4_defconfig and make.

After downloading and starting the kernel on the PicoCOM4, I remounted the rootfilesystem (mount -o remount,rw /) and created a new user telnet (adduser -D telnet) with no password (passwd -d telnet). The telnet client needs to be started on booting. So the file /etc/S70telnetd was created with the following lines:

Shell-Script

#!/bin/sh
ifconfig eth0 10.0.0.27 up
telnetd

In the file /etc/inittab I commented the login_tty configuration and removed the console in the uboot. To do this I viewed my enviroment variables with printenv bootargs and then copied everything from bootargs. The content of the bootargs variables is listed below.

Code

mtdparts=pc4nand0:3m@0x100000(Kernel),-(TargetFS) init=linuxrc root=/dev/mtdblock1 rw rootfstype=jffs2 ethaddr=00:05:51:04:9B:F3

Then I rebooted the board, logged in via telnet and started your test program. After those steps a serial connection with 115200 baudrate showed â€œTestmessageâ€. It also worked with ttySAC0.

christian.moll · Dec 16th 2013

Hello,

something is different on the two systems. I have done the hole thing today two times with different PicoCOM4 boards. Both have the the buildroot and uboot 1.4 installed. Everything is default.
Kernel is patched as you described and the inittab is edited. in init.d I removed the S01fssetup.

I tested on first board without telnet and with it. But I guess it is only for remote access, I normally use the ssh server that is already running.

If I do so the ttySAC1 doesn't speak at all independent of the set speed. ttySAC0 is working as expected.
Interesting is that I can run the simpleserial example two times the third time it hangs on closing the interface. I expect its buffer is full or something like that.

Maybe you can send me your Kernel Image and I can test it.

Best Christian

fs-support_MR · Dec 16th 2013

Hello,

Iâ€™m sorry, but we cannot reproduce your problem.

Could you please provide us with a step-for-step instruction, what you do, starting with the download of the newest kernel sources. Please also use the newest toolchain (4.7.2) and the provided binaries of the uboot and rootfs.

Best regards, Micha

christian.moll · Dec 17th 2013

Hello Micha,

okay found the problem. I was not started with fresh sources in the last attempt from yesterday. There were the lines

Code

//Baudrate bug
if(port->line == 0 && (rd_regl(port, S3C2410_UBRDIV) >= 0x1B1)) {
udelay(500);
}

commented. I managed to do all the patches necessary to run our capacitive touch and display and it seams to run now without a flair.

Thanks for your help.

Christian

fs-support_MR · Dec 18th 2013

Hello Christian,
I am glad you found the problem. Good to hear that your system runs now.
Best regards,
Micha

Share