Attempt to use uart0 on Zybo Z7

[Milan Obuch]

On Sat, 3 Aug 2019 09:10:19 +0200
Milan Obuch <freebsd-arm at dino.sk> wrote:

> Hi,
> 
> Zynq SoC has several peripherals available on its PS/ARM side of
> thing. Currently supported list contains UART, USB, ethernet, SDIO
> and GPIO. No driver yet for SPI, I2C and CAN.
> 
> Available GPIO pins are on JF6 (MIO pmod connector), I tested them as
> inputs and they are working as expected.

Also, I did a 'hardware loopback' - connected pins 9 and 10, which
should be MIO14 and MIO15, one of them configured as output, and it was
doing what it should - toggling the output makes toggle the input, as
expected.

> All other peripherals are present in pairs, so I decided to try the
> simplest one - UART.
>
> On Zybo Z7 we use uart1 as console for both u-boot and kernel, so the
> unused one is uart0. In order to create its driver instance, it was
> necessary to add just
> 
> &uart0 {status = "okay";};
> 
> into dts, create dtb from it and use it for boot. This is enough for
> uart0 to present itself as
> 
> uart0: <Cadence UART> mem 0-0xfff irq 6 on simplebus1
> 
> in dmesg (or
> 
> uart0: <Cadence UART> mem 0-0xfff irq 6 on simplebus1
> uart0: fast interrupt
> uart0: PPS capture mode: DCD
> 
> in verbose boot dmesg).
> 
> That was really easy. Now we need uart0 interface (rx and tx) to
> appear on some available pins. According to MIO-at-a-glance table in
> Zynq TRM (section 2.5.4) there are two possibilities - MIO10 and
> MIO11 or MIO14 and MIO15.
> 
> I played a bit with zy7_slcr_attach() function in
> arm/xilinx/zy7_slcr.c file. With some printf and RD4 calls I can see
> MIO pin configuration - currently we have no pinmux for Zynq, so I
> decided to try register access to check and eventually program.
> Studying existing configuration and Zynq TRM, appendix B.28 for
> registers detail of slcr leads me to believe I need something like
> 
> WR4(sc, ZY7_SLCR_MIO_PIN(14), 0x16E0);
> WR4(sc, ZY7_SLCR_MIO_PIN(15), 0x16E1);
> 
> to do the necessary pinmuxing. As access to slcr register is locked,
> it was necessary to add call
> 
> zy7_slcr_unlock(sc);
> 
> before in order for write to be executed at all, which I verified with
> values being read back correctly. Without this call no change to
> registers was done.
>

In Zynq TRM, section 19.5.1 - MIO programming is description of what
should be done for pinmux, using 0x12E0 and 0x12E1 for 1.8 V instead of
3.3 V as I did, so this should be OK.

> Unfortunatelly, I am still missing something - I tried to create
> physical loop connecting pins MIO14 and MIO15 (on my board connected
> to JF9 and JF10 pins) but nothing - typing anything to 'cu
> -l /dev/cuau0' does not make to read it back.
> 
> Did anybody any clue what I am missing? I verified I am connecting the
> right pins, but I see nothing arriving back when typing...
> 

Could this be interrupt issue? Output of 'vmstat -i' command is
something like

interrupt                                             total       rate
gic0,p13: mp_tmr0                                   1692019         28
gic0,s22: cgem0                                        2985          0
gic0,s24:-dhci_fdt0                                    1103          0
gic0,s50: uart1                                         200          0
cpu0:rendezvous                                           5          0
cpu1:rendezvous                                          31          0
cpu0:preempt                                         192954          3
cpu1:preempt                                         258906          4
cpu0:hardclock                                           17          0
Total                                               2148220         36

When I am doing something on console, there is increase in number on
line beginning with gic0,s50: uart1.

In another session, I am invoking 'cu -l /dev/cuau0 -s 9600'. No sign
of activity when typing here - no echo, no interrupt for uart0 seen. In
fact, I need to issue 'vmstat -ia' to see all interrupts, grepping for
uart gives me

gic0,s27: uart0                                           0          0
gic0,s50: uart1                                         232          0

(I did something on console in between.)
Part of 'devinfo -r' output is

      uart0
          Interrupts:
              0x6
          Device Memory:
              0xe0000000-0xe0000fff
      uart1
          Interrupts:
              0x7
          Device Memory:
              0xe0001000-0xe0001fff

And here the question: how does those numbers relate to each other? I
mean, in devinfo output uart0 has interrupt 6, in vmstat line begins
with gic0,s27 and for uart they are interrupt 7 and gic0,s50.

I see interrupts 27 and 50 in zynq-7000.dtsi, I do not know where 6 and
7 is coming from - it looks like they are in order of device discovery
on boot.

Is here something to be done for interrupts?

One more difference between uart0 and uart1 are clocks - 'clocks'
property in dts differs, whereas 'clock-names' does not. Is here
something to be done to enable uart0?

Any hint appreciated...

Regards,
Milan