Gpio + uart (not the debug-port)

Hi, anyone tried the gpio-pins or knows if any kernel-patch is needed? I want to communicate to an arduino via uart/serial and reset the bpi via the arduino (maybe reset-switch is accessable via pins)

there are 4 Pins behind the rst/pwr-switch, are these the Pins for the switches? In Gitbook there are only holes, here ( ) there is a socket

Regards frank

i’m just taking some time to refer to the broken schematic on hand, hope that would help you step a little

  1. uart2 is for console output while uart0/1 all available on the 40 pins out called U[R,T] XD[0,1]. They should use the same driver as uart2. please feel free to enable those uart nodes in your dts files, they would be mapped to ttyS0, and ttyS1 after system boots, but also note your console has to utilize ttyS2 if you enable ttyS0 and ttyS1 all, otherwise you can’t any get kernel messages out.

  2. No reset is exported to user pin. you could make the reset using software scheme that controls the reboot also with your uart as discussed in 1) delivering some specific commands.

thanks for your answer


There is only uart2 active (as i understand the dsi). How do i get params for uart 0/1?

  1. the reset-option ist last backup.
  • first call script (via uart) to enable internet-connection if that hangs (maybe also restart full network)
  • reboot-command via uart
  • last (if no success,no response on uart) do hard-reset via transistor-circuit over reset-switch
1 Like

please refer and add the missing uart nodes to the dtsi BPI providing. and also notes it is better to send pull request back to BPI. :slight_smile: sharing is the force and helps the next one person doesn’t make the same mistake again and concentrate what we need to care.

maybe is it required to add hardware link to your arduino with SYSRSTB_MT6323 to imitate manual operation as long press X second to reset.

UART0=Con1 Pin 8/10,UART1=Con1 Pin 11/13 (TX/RX)?

in schematics it looks like uart0/1 are swapped (8/10=UTXD1 and 11/13 UTXD0)

where is uart3 (is it connected or only available in chip)?

Hi Frank,

Looks like the serial port isn’t connected a header, if you need it, I will let hardware engineer to find where the TP47 and TP48 are.

This is just for info :slight_smile: additionally (to serial console) 2 uart are enough for me. are my pin-infos correct (and uart-correlation 0 vs. 1)?

The UCTS2 and URTS2 can be routed to UART3,


Yes, the pin information for UART0 and UART1 is correct.

@garywang which dts will be used (where do i have to add uart0/1)?

i have: mt7623a-evb.dts mt7623.dtsi mt7623n-bpi-r2.dts / dtb <<< maybe this dts mt7623n-evb.dts

i assume that only bpi-r2.dts will be used (dtb is compiled), but maybe uart should be added to mt7623n.dts (where uart 2 is defined)…in bpi-r2.dts it seems uart2 is only enabled via


did i need such line also for uart0/1?

what does that mean: chosen {stdout-path=&uart2;} i think thats the definition of debug-console (which port is used for serial-console)

You can change both mt7623.dtsi and mt7623n-bpi-r2.dts to add the devices you need,

how is the correct way to replace the kernel (debian jessie lite)? is it needed to replace uboot?

Please follow above steps to update kernel

I’ve read that, i asked because there may be an easier way doing manually without the script (replace zimage+dtb and copy modules).

i tried to found out, what the script does, but no luck till now

Hi Frank

The uImage(with dtb) is in partition 1 and modules of kernel is in partition 2 of SD card, there is a script for you reference. mount /dev/mmcblk0p1 /mnt/ cp SD/BPI-BOOT/bananapi/bpi-r2/linux/* /mnt/bananapi/bpi-r2/linux/ umount /mnt

mount /dev/mmcblk0p2 /mnt/ cp SD/BPI-ROOT/* /mnt/ -rf umount /mnt

copied uimage to boot and modules to root-partition seems not to work:

Filesystem: FAT16 "BPI-BOOT   "                                                 
Boot from SD                                                                    
reading bananapi/bpi-r2/linux/uEnv.txt                                          
771 bytes read in 10 ms (75.2 KiB/s)                                            
Loaded environment from uEnv.txt                                                
Banana Pi bpi-r2 chip: mt7623n Service: linux                                   
reading bananapi/bpi-r2/linux/uImage                                            
8132578 bytes read in 1062 ms (7.3 MiB/s)                                       
reading bananapi/berryboot.img                                                  
** Unable to read file bananapi/berryboot.img **                                
bootm flag=0, states=70f                                                        
## Booting kernel from Legacy Image at 84000000 ...                             
   Image Name:   Linux-4.4.70-BPI-R2-Kernel                                     
   Image Type:   ARM Linux Kernel Image (uncompressed)                          
   Data Size:    8132514 Bytes = 7.8 MiB                                        
   Load Address: 80008000                                                       
   Entry Point:  80008000                                                       
   Verifying Checksum ... OK                                                    
   Loading Kernel Image ... OK                                                  
Starting kernel ...                                                             

then it stops…no more messages

do i have to change uboot, too? had kernel 4.4.43 before (default for jessie-lite-image).

full log attached: uart_kernel.log (18.0 KB)

Did you change the code of BPI-R2-bsp, if yes, can you please share me the differences?

And I assume you’re using the latest code of BPI-R2-bsp from github.

only added block for uart0/1 to dtsi and set them to “&uart2{status=“okay”;}” in bpi-r2.dts

have run “git pull” before build…maybe that’s enough

enabled_uart0 (14.7 KB)

Can you please try to change the order of uart controller in mt7623.dtsi: uart2 uart0 uart1 uart3

seems that fixed that:

root@bpi-iot-ros-ai:~# uname -r


now i must enable uart0/1 in debian…currently i have no ttyAMAx

root@bpi-iot-ros-ai:~# find /sys/ -name 'serial*'
  /sys/fs/cgroup/systemd/system.slice/system-serial\x2dgetty.slice/[email protected]















i assume that the last 3 devices are my serial ports (remember such numbers from dtsi…)

uart0: serial@11002000 { };

uart1: serial@11003000 { };

From bootlog:

[ 4.737895] 11002000.serial: ttyS1 at MMIO 0x11002000 (irq = 31, base_baud = 1625000) is a ST16650V2

[ 4.767828] 11003000.serial: ttyS2 at MMIO 0x11003000 (irq = 32, base_baud = 1625000) is a ST16650V2

on that kernel net is not working right ;( interface exists, but no transmission possible (only own ip-stack),

=> found out that eth0 and eth1 are swapped with kernel-upgrade (eth0=lan-switch, eth1=wan-port)

also poweroff is not working

=> found nothing related in kernel-config

how can i set kernel-parameters (modules, build-in) like “make menuconfig” with the right config-file?

=> option 4 in, needs “libncurses-dev” to be installed

connected an arduino (with levelshifter) to GPIO Pin 8/10 (should be uart0=11002000=ttyS1)

set speed via stty -F /dev/ttyS1 9600 raw

cat /dev/ttyS1

nothing happens

now using minicom (9600 8n1,flow:off) with ttys2 and i’ve got the input from arduino (keepalives every 60 seconds), why ttyS2??

seems that i have an error in my notes…looked in schematics again.


pin 8/10 = uart1 (tx/rx) = 11003000 = ttyS2
pin 11/13 = uart0 (tx/rx) = 11002000 = ttyS1

read works, but i can not send via minicom/bash

while read line; do
    echo "["$(date "+%Y-%m-%d %H:%M:%S")"] from Arduino: "$line
done < <(cat $DEV)

here i see my keepalives…if i try to send via

echo "AT" >/dev/ttyS2

i get no response (my arduino sends back “AT”-Strings)…arduino is connected also via usb to my workstation, if i send same string via ardiono-console, i see the response in the console and my script-output…so there is a problem with sending to the device (same construction works with raspi [script+send on another terminal via echo])

seems gpio (also uart) are not set to high-level…further debug here: