Accessing UART3 pins on Hikey 960 Board

Products Support HiKey 960
#1

Hi,

I am trying to connect UART based device to UART3_ pins on J2002 (pin no. 3, 5, 7, 9) and unable to communicate with it.

It appears that driver is registered for UART4 and UART6 but not UART3. Following is the dmesg log:

535 [ 2.172451] fdf01000.uart: ttyAMA4 at MMIO 0xfdf01000 (irq = 17, base_baud = 0) is a PL011 rev2
536 [ 2.172845] fff32000.uart: ttyAMA6 at MMIO 0xfff32000 (irq = 18, base_baud = 0) is a PL011 rev2

From user space, opening /dev/ttyASM4 and /dev/ttyASM6 works. But I am not able to find how to communicate with UART3. Any pointers ?

Thanks

#2

Could you try below change in kernel dts:

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index ea54efa..6f160da 100755
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -80,6 +80,10 @@
                        status = "ok";
                };
 
+               uart3: uart@ffd74000 {
+                       status = "ok";
+               };
+
                ufs: ufs@ff3b0000 {
                        reset-gpio = <&gpio18 1 0>;
                        //vcc-supply = <&ldo15>;
#3

Thanks for your prompt response. With your DTS patch UART3 is now enabled successfully. However it appears there could still be a problem with AMBA driver as it throws “no DMA platform data” message. I am not too familiar with this so not sure why is it failing to probe the DMA.

536 [ 2.163217] ffd74000.uart: ttyAMA3 at MMIO 0xffd74000 (irq = 17, base_baud = 0) is a PL011 rev2
1730 [ 25.590955] uart-pl011 ffd74000.uart: no DMA platform data

Would you be able to tell what is the default baud rate of UART3 ? And what is the max baud rate supported by UART3 ?

#4

536 [ 2.163217] ffd74000.uart: ttyAMA3 at MMIO 0xffd74000 (irq = 17, base_baud = 0) is a PL011 rev2
1730 [ 25.590955] uart-pl011 ffd74000.uart: no DMA platform data

Will check this.

Would you be able to tell what is the default baud rate of UART3 ? And what is the max baud rate supported by UART3 ?

From clock driver, I can see UART3 clock is derived from PPLL0/1.8GHz. If the UART clock divider value is 9, 1.8GHz / 9 = 200MHz. This is quite high for serial bus.

Let me check internally for this.

#5

Thanks for your response. Do you have an update on this ? If you could help me confirm the max baud rate on UART3, will be highly appreciated.

Meantime got a chance to debug this little further and found that baud rate of 115200, 9600 etc. are all producing garbage on UART3. The problem is that the baud rate is halved on the actual h/w line. So if you set 115200, the actual UART output is 57600.

To reproduce this, sort the UART3 and UART6 pins as below and check the output:
UART3_TXD <-> DEBUG_UART6_RXD
UART3_RXD <-> DEBUG_UART6_TXD

// Set UART3 to 230400 (so actual line is set to 115200). UART6 is already running at 115200 by default.
// Now read output of UART6_TXD on UART3_RXD, kmsg logs appears fine.
busybox stty -F /dev/ttyAMA3 raw ispeed 230400 ospeed 230400 cs8 -ignpar -cstopb -echo -crtscts
cat < /dev/ttyAMA3

This issue appears to be known bug here - https://bugs.96boards.org/show_bug.cgi?id=520
Is it possible to raise the priority of this bug and provide a fix ASAP ?

#6

@amit AFAIK, this bug is a high priority; please aware that UART3 has some setting issue internally, so Hislicon is working on this. I also have shared your question for UART clock frequency with Hisilicon, so far we cannot confirm this from public SoC Manual.

So thanks a lot for your debugging, the info is important so I will log them into the bug tracking (you are also welcomed to fill info in the bug system!), and will carefully check your mentioned the half baud rate issue internally.

#7

Hi @amit, if you still are interesting in Hikey960 UART3, I just received one patch for UART3 clock fixing: http://archive.armlinux.org.uk/lurker/message/20170807.145156.7457d9f5.en.html

BTW, I heard Hisilicon engineer mentioned the clock is safe at 100MHz, but it’s not stable when set to 200MHz, this is consistent with the patch. FYI.

#8

Hello @leo-yan ,

I am trying to re-evalute of Hikey960 boards with kernel 4.9 and hence back on this :slight_smile:
Thank you for your updates. Looks like UART3 clock issue is resolved now from the patch you mentioned.

However i see a different problem now. The UART3 data throughput is very low. When I probe through the H/W lines, it is observed that a each byte sent out from the driver goes every 2-3 millisecond (ms) apart. This is huge. Each byte should go out about 2-3 microseconds (us) apart.

So it appears the serial driver is neither using DMA nor write FIFO. Seemed like the driver is directly writing to the tax register byte by byte and the delay is caused by the turn around time by the driver that is varying.

Note this issue appears to be independent of baudrate setting, which I verified from the waveform is applied on the h/w line correctly. Also UART6 do not have this issue.

Is it a known issue with UART3? Is there some special setting for UART3? Any pointers to help resolve this is much appreciated.

#9

Hi @amit, I checked the DTS binding and don’t find any difference between UART3 and UART6 and these two ports use the same IP and driver. I checked UART6, it also doesn’t bind any DMA port.

@guodong, do you think there have any updating in sec_xloader.img for UART clocks? And if there have any known issue for this?

#10

So, UART3 is equipped with hardware handshake, CTS/RTS. Is this part of the problem? @amit

#11

Hi @leo-yan, @guodong, Thank you for your inputs.

The CTS/RTS lines are connected to our h/w. But it should not come to play for small payload. This issue appear to exist for any payload since it is related to how 2 bytes are sent out in timeline. Couple of observations:

[1] Added some logs at the start and end of pl011_tx_chars() function and got the below timing. UART3 throughput is very low for same baud rate.

//UART 6 - write 65 bytes in 0.000031 secs (i.e 31 us)
[ 15.033673] uart-pl011 fdf01000.serial: pl011_tx_chars begin
[ 15.033704] uart-pl011 fdf01000.serial: pl011_tx_chars bytes:65

// UART3 - write 73 bytes in 0.172648 secs (i.e 172648 us) i.e about 5000 times slower.
[ 497.576983] uart-pl011 ffd74000.serial: pl011_tx_chars begin
[ 497.749631] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:73

[2] UART 3 write pattern looks strange with 1 byte after every n byte:
[ 496.616515] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:1
[ 496.649172] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:3
[ 496.699532] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:1
[ 496.745374] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:9
[ 496.801104] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:1
[ 496.833762] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:3
[ 497.428857] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:1
[ 497.461514] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:3
[ 497.563149] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:1
[ 497.749631] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:73
[ 497.798891] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:1
[ 498.279839] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:207
[ 498.329160] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:1
[ 498.810108] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:207
[ 499.141016] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:1
[ 499.622023] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:207
[ 499.671344] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:1
[ 500.152291] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:207
[ 500.201614] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:1
[ 500.682561] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:207
[ 500.731948] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:1

[3] Between end of one write to the start of another, there is random delay of 10-50ms. This is also quite high.
[ 500.187186] uart-pl011 ffd74000.serial: pl011_tx_chars begin
[ 500.201614] uart-pl011 ffd74000.serial: pl011_tx_chars bytes:1
[ 500.215448] uart-pl011 ffd74000.serial: pl011_tx_chars begin

I am not too familiar with AMA driver implementation so any pointers will be very helpful. Thank you.

#12

Hi @leo-yan, @guodong, Did you get a chance to take a look at this ? Would you know if UART3 performance on Hikey960 is tested ?

#13

Hi @leo-yan @guodong, I have the same problem with Amit.
Can I know how to improve Hikey 960’s UART3 performance? Thanks a lot.

#14

@Vito_Li @amit

Can you submit a bug in https://bugs.96boards.org/enter_bug.cgi?product=HiKey960
?

After that, I will follow up with HiSilicon.