From owner-freebsd-arm@freebsd.org Tue Aug 6 14:14:23 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0E3C4C2D00 for ; Tue, 6 Aug 2019 14:14:23 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 462xTT702Tz448w for ; Tue, 6 Aug 2019 14:14:21 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Tue, 06 Aug 2019 16:14:18 +0200 id 00F406AA.5D498B3A.00005A6B Date: Tue, 6 Aug 2019 16:14:15 +0200 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Re: Attempt to use uart0 on Zybo Z7 Message-ID: <20190806161415.4be2a991@zeta.dino.sk> In-Reply-To: <20190803091019.2d067756@zeta.dino.sk> References: <20190803091019.2d067756@zeta.dino.sk> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; i386-portbld-freebsd11.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 462xTT702Tz448w X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-arm@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-arm@dino.sk X-Spamd-Result: default: False [-6.23 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; RCVD_IN_DNSWL_NONE(0.00)[72.65.245.84.list.dnswl.org : 127.0.10.0]; IP_SCORE(-2.94)[ip: (-8.32), ipnet: 84.245.64.0/18(-4.16), asn: 16160(-2.30), country: SK(0.06)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16160, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 14:14:23 -0000 On Sat, 3 Aug 2019 09:10:19 +0200 Milan Obuch 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: mem 0-0xfff irq 6 on simplebus1 > > in dmesg (or > > uart0: 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