BPI M1+ UART3 (TTYS2) not Working

Banana Pi BPI-M1/BPI-M1+/BPI-R1
12

After enabling Uart 3 (see post above) i’m pretty sure the fex and pin configs are correct for uart 3 and that its been assigned to ttyS2.

But i still cant get it to work, even performing a simple loop back test using minicom by connecting Tx to RX does not work so i don’t think it can be anything to do with logic level conversion, i seems that the BPI is still not using the uart correctly ?

Has anybody out there successfully used the uart on con 3, pins 8 + 10 (PH00,PH01) ???, i am beginning to wonder if Banana Pi Pro/M1/M1+ has a manufacturing defect that prevents the use of uart3 successfully which is why its been disabled in the default fex file ?

I installed the BPI build of the gpio utility and performing a ‘readall’ outputs the following

Can anybody confirm if ALT0 is the correct mode for pins 8 + 10 to work in uart mode ?

Any comments much appreciated …

Cheers Jay

13

http://forum.lemaker.org/thread-2937-1-1.html

There was the ‘official’ forum before the ‘official’ forum became the one at bananapi.com (that is now abandoned because the next weeks/months this here will be the ‘official’ forum where you don’t get any support by the vendor). Back at that time there were people being paid for supporting the Banana Pi.

14

@tkaiser,

I’m a bit confused by your description of the history forums … I think what you are saying is that this is now/soon to be the correct forum for BPI M1+ but there is no official support for it so everyone use the other forum ?

if so then thats a bit crap isn’t it ?

I already found that post you linked but its of no help … that post seems to be related to 1st gen BPI with 26 pin GPIO header and separate headers for the other uarts …BPI PRo/M1+ has all in one 40 pin gpio header … however what is outlined in that post is basically what i’ve done but it still does not work … so can only conclude that there is some sort of design fault hence the reason its disabled by default in fex file ?

Comparing gpio readall to rpi B+ (with uart3 woking) indicates that ALT0 is correct so completely at a loss now …

This is getting to the point where its not worth the effort I must have spent at least 20 hours trying to get uart3 to work on BPI M1+ GPIO … might just be simpler to chuck it in the bin and get something that works or at least has official support and documentation.

Very disappointed now with M1+

Jay

15

Have a look at http://linux-sunxi.org/Banana_Pi#Variants (and also on the top of that page that might clarify the situation why there was more than one company claiming it’s the Banana vendor). SinoVoip tried to copy LeMaker’s BananaPro exactly so that software should be interchangeable 1:1 – but they failed regarding audio_pa_ctrl and maybe other things are also routed differently – we will never know since SinoVoip doesn’t answer support questions).

Now that LeMaker had to give up on supporting the Bananas it’s a product without support at all :frowning:

That’s a bit sad because I like the M1+ more than the Pro since it has all the stuff that might get hot (SoC and PMU) on the upper PCB side so that enclosures don’t lead to thermal issues under full load as it’s the case with Banana Pi M1 and Pro.

16

@tkaiser,

Many thanks for your posts and explanations, had i known that BPI M1+ has such poor official support i would have thought twice about going this route. As you say its a shame as the hardware is mostly very good and it is running all of our software extremely well from a ssd via sata2 interface and communicating with mobile devices via built in wifi (configured as AP) all of this works much better and faster than Rasp PI.

I didn’t realise that M1+ is a clone of a clone and the mixed manufacturing vendors and poor history of Banana Pi with regards to official vendor support, i guess you only find out about these issues when you run into problems and start reading the small print …

I think you maybe correct about the problem with the audio_pa_ctrl not not being the only diffrance with regards to pin changes between the A20 and the external interfaces … so for me it time to call it quits with Banana Pi M1+

Unless someone can chime in and tell me categorically that uart3 (ttyS2) does work on M1+ gpio and what needs to be done to make it work i can not spend any more time on this. For now we will have to go back to Raspberry Pi … it maybe slow but it does work.

We may revisit it in the future … it should be possible to use the debug uart ttyS0 on con4 (assuming that works) to communicate with our daughter board but we will need to make a new hardware revision of our DB as currently all I/O is via gpio connector.

Thanks for getting me this far.

Cheers Jay

17

justin have to test it ,and will let you know result later . sorry for delay.

18

I would wait and let Justin test and confirm. If you got that far (official answer from SinoVoip) it’s too early to give up! :smile:

Apart from that I would believe https://www.olimex.com is worth a look. Their OLinuXinos come with 160 GPIO pins and I believe they route everything to the outside that’s possible. And since they follow the ‘open source hardware’ rules you find there excellent documentation ‘by design’.

19

Thank you, i hope you can help as this is a very frustrating situation as everything else is working on M1+, please be sure to read this entire thread from post #10 onwards as i have tried very hard to get uart3 working and believe that i have done everything correct,

Fingers crossed that SinoVoip can find the answer …

Cheers Jay

20

The dts file for bpi-m1-plus is here https://github.com/BPI-SINOVOIP/BPI-Mainline-uboot/tree/master/arch/arm/dts

The diff against mainline uboot is here. http://users.utu.fi/jmjmak/tmp/uboot-bananapi.patch

This 4.2 kernel also works, but it’s quite bloated with extra config:

21

As stated in post #6 onwards I am using the BPI Debian/Jessie 15.08 release which uses u-boot so fex files are used for pin config not DTS … We just cant afford to spend any more time trying to get uart3 working right now …

However since my last post we have had very good success using uart7 (GPIO pins 36 & 38) as an alternative which has allowed us to progress with testing BPI M1+ … unfortunately it also meant we have had to create a prototype BPI M1+ specific version of our daughter board with a 40 pin connector which will not be backwards compatible with Rasp Pi which was our original intention.

However having seen the performance gains between BPI M1+ against Rasp Pi Model B this may not be so much of an issue now

For now please consider this thread closed, but we would always be interested if anyone is eventually successful in getting uart3 working in the future …

Cheers Jay

22

In case you haven’t already had an eye on the ODROID C1+ it’s worth a look.

23

@tkaiser,

Many thanks for the heads up on ODROID C1+ , very interesting … no sata port for SSD but e.MMC option should offer similar performance which also has the option to boot from it :yum: and is a neater solution not requiring external sata and power cables, smaller form factor … etc

I’m guessing performance would be up a bit on M1+ A20 dual core SOC ?

My only real concern is lack of built in wifi … M1+ has built in AP6010 wifi chipset which works very well in AP mode, of course we could add wifi via USB but have had so many issues with external usb wifi dongles (in Ap Mode) with Rasp Pi we would need to investigate what works well … it was this issue that led us to BPI M1+ …

Will definitely keep an eye on it … would like to see some comparison benchmarks …

Cheers Jay

24

The S805 is over twice as fast as the A20 on the M1+. I did some tests (also with thermal measurements) when I reviewed another SoC a few weeks ago: http://forum.armbian.com/index.php/topic/311-quick-review-of-lemakers-guitar/

And you will find also results to compare with at mikronauts.com (use the results of Banana Pi or Pro since all A20 based devices perform identical). Regarding an AP capable USB stick we had discussions at armbian.com recently if I remember correctly (but I might be wrong since Wi-Fi available on SBCs is of no interest for our use cases)

25

I have exactly the same problem jaymonkey reported.

I changed the fex file to use uart on PH0 and PH1 which are correct according to the provided schematic. I’m using Multi4 function as per A20 user manual. Changed script.bin and after rebooting I have uart3 on ttyS2. Testing with screen /dev/ttyS2 19200 and a scope on pin 8 of CON3 (UART3.TX according to the schematic) but nothing is coming out.

Any update on this?

Did justine from sinovoip answered the question?

Regards Snafutzz

26

Just to add some more info to the problem.

I’ve reconfigured succesfully UART5 and UART6 on CON3 instead of SPI0

UART5 TX -> PI10 Multi3 -> CON3 24 RX -> PI11 Multi3 -> CON3 23

UART6 TX -> PI12 Multi3 -> CON3 19 RX -> PI13 Multi3 -> CON3 21

But still no success with UART3

Regards Snafutzz

27

you can reference this document:

https://bananapi.gitbooks.io/bpi-m1/content/bpi-m1uartinterface.html

28

Thank for your reply,

I’m using BPI-M1+ with linux 3.4.108-bananian (the link provied in your reply refers to BPI-M1 instead)

Apart from this I’ve succesfully used UART0/UART2/UART5/UART6/UART7 accessing their pins from 40Pins header or 3Pins debug uart header respectively.

But UART3 doesen’t work.

With dmesg | grep ttyS I get [ 0.661743] sunxi-uart.0: ttyS0 at MMIO 0x1c28000 (irq = 33) is a U6_16550A [ 1.307066] sunxi-uart.2: ttyS1 at MMIO 0x1c28800 (irq = 35) is a U6_16550A [ 1.350781] sunxi-uart.3: ttyS2 at MMIO 0x1c28c00 (irq = 36) is a U6_16550A [ 1.394495] sunxi-uart.5: ttyS3 at MMIO 0x1c29400 (irq = 50) is a U6_16550A [ 1.438175] sunxi-uart.6: ttyS4 at MMIO 0x1c29800 (irq = 51) is a U6_16550A [ 1.481843] sunxi-uart.7: ttyS5 at MMIO 0x1c29c00 (irq = 52) is a U6_16550A

So all the uart configured in the script.bin file are correclty started UARTs configuration is correct for both MemoryMappedIO and IRQ according to A20 user manual.

The script.fux/script.bin file uart sections have the following entries:

[uart_para0] uart_used = 1 uart_port = 0 uart_type = 2 uart_tx = port:PB22<2><1> uart_rx = port:PB23<2><1>

[uart_para2] uart_used = 1 uart_port = 2 uart_type = 4 uart_tx = port:PI18<3><1> uart_rx = port:PI19<3><1> uart_rts = port:PI16<3><1> uart_cts = port:PI17<3><1>

[uart_para3] uart_used = 1 uart_port = 3 uart_type = 2 uart_tx = port:PH00<4><1> uart_rx = port:PH01<4><1>

[uart_para5] uart_used = 1 uart_port = 5 uart_type = 2 uart_tx = port:PI10<3><1> uart_rx = port:PI11<3><1>

[uart_para6] uart_used = 1 uart_port = 6 uart_type = 2 uart_tx = port:PI12<3><1> uart_rx = port:PI13<3><1>

[uart_para7] uart_used = 1 uart_port = 7 uart_type = 2 uart_tx = port:PI20<3><1> uart_rx = port:PI21<3><1>

Which seem correct looking at BPI-M1+V1_0 20150202.pdf schematic and A20 SoC manual for pin MultiFuncion configuration.

I’m using screen /dev/ttySx 19200 for opening a terminal connected to UARTx. To test the uart I connect Rx and Tx pins of the same UART port (loopback) and also look at Tx pin with an oscilloscope.

Nothing comes out from UART3 Tx (ttyS2) pin, all other UARTs work fine.

What can possibly go wrong? Did you ever tested UART3 with bananian? Which fux configuration are you using to test it?

Looking at the schematics I’ve noticed that BananaPi-M1+ is different in UART assignement BananaPro from Lemaker. BananaPro uses UART4 on PH4 and PH5 pins of A20 SoC to connect 40Pin gpio header on pins 8 and 10. BananaPi-M1+ uses UART3 on PH0 and PH1 pins of A20 SoC to connect 40Pin gpio header on pins 8 and 10.

Regards Snafutzz

29

At the end I solved the problem.

In script.fux file in usbc configuration the same SoC pins PH00 and PH01 were reconfigured to drive USB_VBUS which is not necessary in BPI-M1+ cause VBUS is directly tied to 5V.

Regards Snafutzz

30

Hi snafutzz,

Sorry i missed you earlier posts … i was never able to solve the issue and i never received any amore help from BPI or Justine from sinovoip … but it sounds like you where able to fix it :+1: , do you mind posting the code changes to your fex and script files … ?

Hope fully BPI can incorporate these fixes in a future build …

Cheers Jay

31

Can you please help me with the procedure to test the UART2,4, 5,6,7 based on your post? Thanks, Rohit