How to access ttyS0 and ttyS1 from Debian

[vik]

Hi there,

I just bought an A13-OLinuXino and I am porting an existing project on it. I got the following problem:

When attempting to access any of the ttyS0 or ttyS1 ports I get a permission denied message. I can access the ttyS2 and ttyS3 ports. I have added myself to the tty and dialout groups.

I know that ttyS0 is the console port, so this could be the reason I cannot access it. And I also know how to disable the console too. So as a last resort I could disable the console and use ttyS0. But the specs for the board say that there are 2 UARTs.

So where is the second UART and how to use it? The MOD-RS232 connects to the ttyS0. That's UART1 - there is also a 4 pin connector next to the UEXT, also labelled UART1 - I guess that the pins are connected to the UEXT pins.

There is also a set of 4 holes with no connector soldered just on the opposite side of the boards. This is labelled UART0. But to which ttyS port is this labelled and what type of adaptor can be used?

And are ttyS2 and ttyS3 connected to any phisical outputs at all?

Does anyone know the answer to these questions? Has anyone successfully used both UARTs?

Thanks!

[JohnS]

You can see the uarts in the schematic.  From there you can see the pins.  You can look in the A13 datasheet, too.  Plus the User Manual.

Then there's things like dmesg

Check the device file permissions.  You may need to add yourself to the group(s) they have.

John

[laskov]

In A20 ttyS0 is busy. If I want to use it I must comment the line in /etc/inittab

Code Select Expand

T0:2345:respawn:/sbin/getty -L -a root ttyS0 115200 linuxand restart.

[vik]

Thanx Laskov,

I have already done that so I was able to use ttyS0 from my code. But there is also the Kernel command:

console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait loglevel=8 panic=10

So during boot the A13 still sends text to ttyS0. Since my slave devices are always connected to the port there is some (very small) chance that some of the text can be interpreted as a command and cause problems.

I have not been able to change the Kernel command line on the Debian for A13 yet. If someone has done it already, I would appreciate a short description how it's done.

BTW, another thing I have already figured out is that the UART0 is multiplexed with the SD card pins and is quite useless in most cases. Of course one can write some drivers or custom code, but this is way beyond the scope of what I am trying to accomplish. After all the A13 is just one of many microcomputers that I am testing. The main idea is to find a board that would require least customization for the purpose.

I saw a post with instructions on how to flash a Debian image on the NAND. Also seemed way to complicated. That could potentially free the UATR0, but this is a hack and also quite undesirable for the purposes.

Anyway, since I believe that the purpose of the forum is to share solutions, not to post obvious advice, like RFM, I will keep everyone posted on the progress. If I find a solution I will make sure to share it with everyone. So other people don't have to waste time reinventing the wheel.

[laskov]

Hi Vik,
I think you can consider using additional RS-232 devices.

console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait loglevel=8 panic=10

This may be a command passed to the kernel by bootloader or may be compiled in the kernel. I know LiLo and GRUB but I don't know how A13 (or A20) boots. This is easy to find I think.

[vik]

Well, as a matter of fact the MOD-RS232 is actually required to connect to the serial port ttyS0. The pins for UART1 are wired to the pins of the UEXT (3 - TXD, 4 - RXD) so one needs the converter to connect to a COM port. Seems like the MOD-RS232 is a simple TTL to RS232 adapter. It has the MAX3232C chip and that's all.

The bottom line is - the MOD-RS232 will not add another port. It just lets you use the existing one.

And I already have it anyway, or I wouldn't have been able to connect at all. Actually, I would probally have been able to use one of the several other converters that I have, but anyway, I just wanted to buy one from Olimex. Just to give the guys some business, they do a good job and deserve some appreciation.

So, the question boils down to how to edit the Kernal command line and remove the "console=ttyS0,115200" from it.

I bet someone knows how to do this, because someone compiled that kernel and built the SD card image. So speak-up, please!

I promise to buy a beer to whoever tells me in a simple set of instructions how to do this. If I ever get within 1h drive of where he lives I will stop there and buy him a good beer!

[MBR]

The easiest way how to modify kernel command line: put the options into the text file uEnv.txt (name is case sensistive), for example something like console=tty1,38400. The file must be situated on the same place as the kernel file uImage and the FEX config script.bin - on the root directory of the first FAT32 partition /dev/mmcblk0p1. The UBoot loader will override the default option with them.

[laskov]

In script.bin are stored parameters for pins, video modes and others for the board. You may make script.bin human readable by bin2fex program from directory /opt/sunxi-tools/

Code Select Expand

/opt/sunxi-tools/bin2fex script.bin > script.fexIn script.fex for A20 I saw

[uart_para]
uart_debug_port = 0
uart_debug_tx = port:PB22<2><1><default><default>
uart_debug_rx = port:PB23<2><1><default><default>

[uart_force_debug]
uart_debug_port = 0
uart_debug_tx = port:PB22<2><1><default><default>
uart_debug_rx = port:PB23<2><1><default><default>

I don't know what is in A13, but I'd tried to change both
uart_debug_port = 0
to
uart_debug_port = 2
Then you must generate new script.bin using fex2bin and replace it in fat partition.

If you have change_display_a13_OlinuXino.sh or similar script take a look on it.

[vik]

Thank you guys,

Your suggestions were quite helpful. First I added just the line "console=" to the uEnv.txt file. This generally reverts the console to the default - which is he LCD screen in the case. The crap being sent to the serial port was immediately reduced by more than 50%.

Then I tried to modify the script.bin file as suggested by laskov. While I learned a lot from examining the file contents, the overall effect to the output was zero. Nevertheless it was an useful exercise.

Here comes the final verdict - I will have to bite the bullet and recompile Uboot myself. That really sucks, as I have very little time and I had high hopes for the Olimex board, but everything points to that. Here is what Uboot sends to the UART right away upon power-up:

U-Boot SPL 2014.01-rc1-09151-ga5f58fb (Jan 03 2014 - 08:28:20)
Board: A13-OLinuXino
DRAM: 512 MiB
CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2
spl: not an uImage at 1600


U-Boot 2014.01-rc1-09151-ga5f58fb (Jan 03 2014 - 08:28:20) Allwinner Technology

CPU:   Allwinner A13/A10s (SUN5I)
Board: A13-OLinuXino
I2C:   ready
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  3 [08][08][08] 2 [08][08][08] 1 [08][08][08] 0
reading uEnv.txt <- It's reading uEnv here !
9 bytes read in 2 ms (3.9 KiB/s)
Loaded environment from uEnv.txt
reading boot.scr
** Unable to read file boot.scr **
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
reading script.bin <- It's reading script.bin here !
28808 bytes read in 4 ms (6.9 MiB/s)
etc...


Note that both uEnv.txt and script.bin are being processed quite late in the game. Note also the "In:, Out: and Err:" outputs sent to serial right under the bad CRC warning. Now, I have not saved the environment yet, this is why I am getting the warning. But I will wait with that for a while.

In any case - Uboot starts writing to serial right away. Most likely this is done intentionally by Allwinner developers, because their chips are used mostly in Android tablets. No one (except the die-hard geeks, like me) wants to see some debug output on the screen. Everybody seems to prefer a nice friendly stupid bitmap...

On the other hand the console leaves the developers with some way of controlling the boot process and seeing what is going on. So they redirected the Uboot to the console port. That would all have been very nice if there were more UARTs. But as it stands now there are only 2 (more likely 1.5 because UART0 is multiplexed with the SD card slot).

Anyway, I got my program to run on the board and the devices connected to ttyS0 seem to ignore the junk sent there by Uboot. Then my program takes over and everything is peachy! So far - so good. This is a lot of progress for the 2 weeks I have been playing with the board. Keeping in mind that this is not the only project I am working and not the only problem with the board either.

So I am not elliminating the A13 board from the list. To be continued...

[laskov]

Note that both uEnv.txt and script.bin are being processed quite late in the game.

Yes. All these messages are sent from bootloader, i.e. recompiling kernel will not stop them.

I have another crazy idea: Is it possible to switch ttyS0 to your device after boot and before starting your program using additional hardware driven by GPIO output like this:

Code Select Expand

#!/bin/bash

echo 47 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio47_ph2/direction
echo 1 > /sys/class/gpio/gpio47_ph2/value

This is from /opt/led_blink.sh in A20

[vik]

Hi Laskov,

I think that I said that I will have to recompile the Uboot, not the kernel. Clearly I will need to make some modifications in it. Finding where and what mods to do could be time consuming, so I will leave this as a last resort.

Regarding your idea - it's not that crazy at all. But for industrial product design it could be expensive. It will need some extra hardware to switch on/off the communication channels and this will make every unit more expensive.

While changing the bootloader will require some up-front expense, but then the problem would be solved once and for ever.

The beauty of the open hardware projects is that we have access to the board design. Once I determine that the overall design is fine, we can load the CAD files into our system and change the board to our liking. E.g. remove all the components we don't need. Make the board more compact. I am tninking about integrating the LCD adaptor into the main board - this will make a lot of sense. Etc.

But for now I am satisfied. There are few more things to figure out...

So, you'we got an A20. How do you like it? It looks very similar to the Cubieboard2 that I have. I might buy an A20 and compare the two.

[vinifr]

You can use UART1 and UART3, despite the LED PG9.

[vik]

Vinifr, would you bother to be more specific?

[vinifr]

Ah, sorry. Edit script.fex:

Code Select Expand


[uart_para3]
uart_used                = 1
uart_port                = 3
uart_type                = 2
uart_tx                  = port:PG09<3>
uart_rx                  = port:PG10<3>

and

Code Select Expand


[spi1_para]
spi_used = 0  <----------
spi_cs0 = port:PG09<2><default><default><default>
spi_cs1 = port:PG13<2><default><default><default>
spi_sclk = port:PG10<2><default><default><default>
spi_mosi = port:PG11<2><default><default><default>
spi_miso = port:PG12<2><default><default><default>

and

Code Select Expand


[audio_para]
audio_used               = 1
audio_pa_ctrl            = port:PB4<1><default><default><0>
;default: audio_pa_ctrl  = port:PG10<1><default><default><0>

[gpio_para]
NO entry for PG9 and PG10


[vik]

Thanx Vinifr,

This is the right answer. The A13 board has one more UART lurking in the shadows. It is using the same pins as the SPI1, so the SPI must be disabled. The code shown by Vinifr does that. Actually, the script.bin file included with the latest Debian image has already the right fix. The only difference from what Vinifr suggests is that the port number for UART3 is set to 1. I.e. it should be accessed as ttyS1, not ttyS3. So I didn't have to recompile the script.bin at all...

Then one can just trace where the corresponding pins are wired on the board's connectors. Here it is:

UART1
uart_tx = port:PG03<4> - pin 152 - UEXT pin 3
uart_rx = port:PG04<4> - pin 151 - UEXT pin 4

UEXT pin 1 - 3.3V
UEXT pin 2 - GND

UART3
uart_tx = port:PG09<3> - pin 12 - GPIO-2 pin 10
uart_rx = port:PG10<3> - pin 13 - GPIO-2 pin 8

GPIO-2 pin 1 - 5V
GPIO-2 pin 3 - 3.3V
GPIO-2 pin 2 & 4 - GND

So, just disconnect the MOD-RS232 cable from the UEXT. Then using 4 Dupont wires (male to female) connect pin 1 of the UEXT to pin 1 of the MOD-RS232 cable, pin 2 to pin 2, then pin 10 of GPIO-2 to pin 3 and pin 8 of the GPIO-2 to pin 4. If you want to completely free the UEXT port and plug something else there, then use the GPIO-2 pin 3 for the 3.3V and either pin 2 or 4 for the ground.

This port is initially set to 9600 baud. So if you connect a terminal emulator to the COM port of the PC, set it to 8N1 9600bps. Then type

echo 1234 > /dev/ttyS1

from the console on the A13 board and you will see 1234 on the terminal emulator. (if you wired everything correctly, otherwise - some bluish smoke above your board)

I kept the emulator on during the boot-up and shutdown. I get a little [00] on boot. Not a big deal. It is not going to cause trouble.

Instead of the MOD-RS232 one can buy a TTL to RS232 converter from eBay. These go for less than $2, wires are sometimes included.

So Vinifr gets the beer. How far from Colorado are you? 

BTW, Olimex, if you are reading this, you list SparkFun Electronics among your distributors, but I went to their Web site - they do not carry the OLinuXino boards. Would be nice if they did, after all they are just few miles from my home.