On Wed, May 20, 2020 at 11:38 PM Greg Gallagher <g...@embeddedgreg.com> wrote:
> Hi, > > On Fri, May 15, 2020 at 5:22 PM Joshua Karch <jkarc...@hotmail.com> wrote: > >> >> >> ------------------------------ >> *From:* Greg Gallagher <g...@embeddedgreg.com> >> *Sent:* Friday, May 15, 2020 2:08 PM >> *To:* Joshua Karch <jkarc...@hotmail.com> >> *Cc:* xenomai@xenomai.org <xenomai@xenomai.org> >> *Subject:* Re: Unable to get xeno-gpio-xilinx to work on Zynq Ultrascale >> + platform >> >> Hi, >> >> >> On Fri, May 15, 2020 at 4:53 PM Joshua Karch <jkarc...@hotmail.com> >> wrote: >> >> >> >> >> >> Sent from Mail >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgo.microsoft.com%2Ffwlink%2F%3FLinkId%3D550986&data=02%7C01%7C%7Cd9b9eae8db584bc9d4e608d7f9143295%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637251737447796792&sdata=YpnIgV7MML6mL8EyYWK64fewpiXvmLtO2I5rY16Im3k%3D&reserved=0> >> for Windows 10 >> >> >> >> *From: *Greg Gallagher <g...@embeddedgreg.com> >> *Sent: *Friday, May 15, 2020 4:46 PM >> *To: *Joshua Karch <jkarc...@hotmail.com> >> *Cc: *xenomai@xenomai.org >> *Subject: *Re: Unable to get xeno-gpio-xilinx to work on Zynq Ultrascale >> + platform >> >> >> >> HI, >> >> >> >> On Fri, May 15, 2020 at 4:42 PM Joshua Karch <jkarc...@hotmail.com> >> wrote: >> >> Hi Greg! >> >> >> >> *From:* Greg Gallagher <g...@embeddedgreg.com> >> *Sent:* Friday, May 15, 2020 1:35 PM >> *To:* Joshua Karch <jkarc...@hotmail.com> >> *Cc:* xenomai@xenomai.org <xenomai@xenomai.org> >> *Subject:* Re: Unable to get xeno-gpio-xilinx to work on Zynq Ultrascale >> + platform >> >> >> >> Hi, >> >> On Fri, May 15, 2020 at 4:29 PM Joshua Karch via Xenomai >> <xenomai@xenomai.org> wrote: >> > >> > Hello, >> > >> > This my first post in 10 years to the Xenomai group, just as the EVL >> project comes online! I'm trying to get the xeno-gpio-xilinx driver >> working but am encountering the following difficulties: >> > (1) It seems the standard non Xenomai gpio-xilinx driver SysFS are >> prerequisites to making the driver work. Unlike the SJA1000 CAN Drivers I >> used in the past which were standalone, I'm seeing a lot of clues that the >> Xeno GPIO drivers need to piggyback on top of the core Linux Drivers. I >> guess this is a change from when I last worked with Xenomai 10 years ago >> where I used xeno-16550A and SJA1000 as RTSER and RTCAN drivers. >> > >> > When I attempt to modprobe xeno-gpio-xilinx I receive a message stating: >> > >> > modprobe: ERROR: could not insert 'xeno_gpio_xilinx': No such device >> > Device Tree: >> > # cat /proc/device-tree/axigpio@a0000000/compatible >> > xlnx,xps-gpio-1.00.a >> > >> > In Xenomai gpio-xilinx.c: >> > return rtdm_gpiochip_scan_of(NULL, "xlnx,xps-gpio-1.00.a", >> > RTDM_SUBCLASS_XILINX); >> > >> > >> > I instrumented the Xenomai gpio-xilinx.c and gpio-core.c to see if the >> of_find_compatible_node function fails and indeed it does find no such >> device. Also I noted that there are no Xilinx specific registers in the >> gpio-core.c or in gpio-xilinx.c, making me believe that this driver is >> piggybacking on top of the Xilinx driver. >> > >> > However: when I modprobe gpio-xilinx the of_find_compatible_node >> function no longer fails, so I guess of_find_compatible_node works only >> with loaded drivers / GPIO Chips. The issue is, gpio-xilinx has already >> done the SYSFS registration, so I get the following errors: Seems the >> driver wants to use the same names for RT with SYSFS as non RT. The key >> error is " >> > kobject_add_internal failed for !axigpio@a0000000 with -EEXIST, d >> > on't try to register things with the same name in the same directory. >> > " >> > >> > Thoughts? >> > >> > Josh Karch >> > >> > >> > modprobe xeno-gpio-xilinx >> > [ 55.778656] test probing xilinx gpio rt >> > [ 55.782753] sysfs: cannot create duplicate filename >> '/class/!axigpio@a0000000 >> > ' >> > [ 55.789991] CPU: 1 PID: 237 Comm: modprobe Tainted: G W >> O 4.19.5 >> > 5 #8 >> > [ 55.797470] Hardware name: ZynqMP ZCU102 Rev1.0 (DT) >> > [ 55.802422] I-pipe domain: Linux >> > [ 55.805643] Call trace: >> > [ 55.808090] dump_backtrace+0x0/0x160 >> > [ 55.811748] show_stack+0x14/0x20 >> > [ 55.815056] dump_stack+0xcc/0xf4 >> > [ 55.818363] sysfs_warn_dup+0x60/0x80 >> > [ 55.822016] sysfs_create_dir_ns+0xcc/0xf0 >> > [ 55.826106] kobject_add_internal+0xac/0x2a0 >> > [ 55.830367] kset_register+0x50/0x80 >> > [ 55.833937] __class_register+0xbc/0x170 >> > [ 55.837850] __class_create+0x50/0x90 >> > [ 55.841507] rtdm_gpiochip_add+0x30/0x260 >> > [ 55.845507] rtdm_gpiochip_alloc+0x50/0xe0 >> > [ 55.849596] rtdm_gpiochip_scan_of.part.1+0x138/0x1e0 >> > [ 55.854640] rtdm_gpiochip_scan_of+0x20/0x30 >> > [ 55.858905] xilinx_gpio_init+0x28/0x1000 [xeno_gpio_xilinx] >> > [ 55.864554] do_one_initcall+0x74/0x178 >> > [ 55.868382] do_init_module+0x54/0x1d0 >> > [ 55.872122] load_module+0x1b90/0x2120 >> > [ 55.875864] __se_sys_finit_module+0xb8/0xd0 >> > [ 55.880127] __arm64_sys_finit_module+0x18/0x20 >> > [ 55.884650] el0_svc_common+0xbc/0x1a0 >> > [ 55.888390] el0_svc_handler+0x68/0x80 >> > [ 55.892131] el0_svc+0x8/0x18 >> > [ 55.895114] kobject_add_internal failed for !axigpio@a0000000 with >> -EEXIST, d >> > on't try to register things with the same name in the same directory. >> > [ 55.908254] [Xenomai] cannot create sysfs class >> > [ 55.912796] sysfs: cannot create duplicate filename >> '/class/!axigpio@a0000000 >> > ' >> > [ 55.920021] CPU: 1 PID: 237 Comm: modprobe Tainted: G W >> O 4.19.5 >> > 5 #8 >> > [ 55.927500] Hardware name: ZynqMP ZCU102 Rev1.0 (DT) >> > [ 55.932453] I-pipe domain: Linux >> > [ 55.935672] Call trace: >> > [ 55.938115] dump_backtrace+0x0/0x160 >> > [ 55.941769] show_stack+0x14/0x20 >> > [ 55.945077] dump_stack+0xcc/0xf4 >> > [ 55.948384] sysfs_warn_dup+0x60/0x80 >> > [ 55.952038] sysfs_create_dir_ns+0xcc/0xf0 >> > [ 55.956127] kobject_add_internal+0xac/0x2a0 >> > [ 55.960389] kset_register+0x50/0x80 >> > [ 55.963957] __class_register+0xbc/0x170 >> > [ 55.967872] __class_create+0x50/0x90 >> > [ 55.971527] rtdm_gpiochip_add+0x30/0x260 >> > [ 55.975529] rtdm_gpiochip_alloc+0x50/0xe0 >> > [ 55.979618] rtdm_gpiochip_scan_of.part.1+0x138/0x1e0 >> > [ 55.984663] rtdm_gpiochip_scan_of+0x20/0x30 >> > [ 55.988925] xilinx_gpio_init+0x28/0x1000 [xeno_gpio_xilinx] >> > [ 55.994576] do_one_initcall+0x74/0x178 >> > [ 55.998403] do_init_module+0x54/0x1d0 >> > [ 56.002144] load_module+0x1b90/0x2120 >> > [ 56.005886] __se_sys_finit_module+0xb8/0xd0 >> > [ 56.010149] __arm64_sys_finit_module+0x18/0x20 >> > [ 56.014672] el0_svc_common+0xbc/0x1a0 >> > [ 56.018412] el0_svc_handler+0x68/0x80 >> > [ 56.022153] el0_svc+0x8/0x18 >> > [ 56.025128] kobject_add_internal failed for !axigpio@a0000000 with >> -EEXIST, d >> > on't try to register things with the same name in the same directory. >> > [ 56.038263] [Xenomai] cannot create sysfs class >> > [ 56.042798] Xeno Scan returns -17 >> > # >> > >> > >> > >> I can take a look. This was working on the Zynq-7000, but I haven't >> tested it on the Ultrascale. I'll see if I can reproduce. >> >> >> Thanks >> >> Greg >> >> >> >> >> >> >> >> Thank you for your help with this! The other thing I had to do to make >> this work was to edit drivers/xenomai/gpio/Kconfig to enable depends on >> >> ARCH_ZYNQ || ARCH_ZYNQMP because I assume the AXI driver should be the >> same for either ZYNQ or ZYNQMP, is that a safe assumption? >> >> >> >> I assume that is correct, but I'll double check. I have a Ultra96 here >> that I can fire up and test on. >> >> >> >> >> >> >> >> config XENO_DRIVERS_GPIO_XILINX >> >> >> >> depends on ARCH_ZYNQ >> >> >> >> depends on ARCH_ZYNQ || ARCH_ZYNQMP >> >> >> >> tristate "Support for Xilinx GPIOs" >> >> >> >> >> >> Yep, these will need to be enabled for the AXI gpios to build for the >> ZynqMP arch. >> >> >> >> help >> >> >> >> Best, >> >> >> >> Josh >> >> I'll answer the questions you have in your first post once I look at the >> driver again, I want to make sure my assumptions are correct. I haven't >> looked at the GPIO core in a couple of months. >> >> >> >> Thanks >> >> >> >> Greg >> >> >> >> Greg, sounds great! Thank you! We are running Linux 4.19.55 which is >> based on the Linux-xlnx 4.19 distribution, with Xenomai 3.1 and Cobalt >> Core. Currently I have Sysfs and the kernel module enabled. >> >> You’ll need to disable the non rt one. I’ll have a more in-depth >> explanation once I test it out. >> >> >> >> One other funky thing that might be involved is with the base gpio-xilinx >> driver. I get a message and a trace that gpio-xilinx is not “pipeline >> safe” when loading up on the dmesg. However the base, non-Xenomai GPIO >> driver does seem to communicate with hardware. >> >> >> >> 13.389070] ------------[ cut here ]------------ >> >> [ 13.393691] irqchip xgpio is not pipeline-safe! >> >> [ 13.393711] WARNING: CPU: 0 PID: 145 at kernel/irq/chip.c:55 >> irq_set_chip+0xb4/0xd0 >> >> [ 13.405883] Modules linked in: gpio_xilinx(+) >> >> [ 13.410240] CPU: 0 PID: 145 Comm: systemd-udevd Not tainted 4.19.55 #9 >> >> [ 13.416758] Hardware name: ZynqMP ZCU102 Rev1.0 (DT) >> >> [ 13.421713] I-pipe domain: Linux >> >> [ 13.424935] pstate: 40000005 (nZcv daif -PAN -UAO) >> >> [ 13.429720] pc : irq_set_chip+0xb4/0xd0 >> >> [ 13.433546] lr : irq_set_chip+0xb4/0xd0 >> >> [ 13.437372] sp : ffffff8009543820 >> >> [ 13.440679] x29: ffffff8009543820 x28: ffffff8000a33200 >> >> [ 13.445985] x27: ffffff8000a307f0 x26: ffffff8000a30b20 >> >> [ 13.451289] x25: ffffff8000a30410 x24: ffffff8008df9688 >> >> [ 13.456593] x23: ffffff80080f7300 x22: ffffff8000a33000 >> >> [ 13.461897] x21: ffffffc85d39be00 x20: ffffff8000a33000 >> >> [ 13.467201] x19: ffffff8008df9688 x18: 0000000000000010 >> >> [ 13.472505] x17: 0000000000000001 x16: 0000000000000007 >> >> [ 13.477809] x15: ffffffffffffffff x14: 0720072007200720 >> >> [ 13.483113] x13: 0720072007200720 x12: 0720072007200720 >> >> [ 13.488417] x11: 0720072007200720 x10: 0720072007200720 >> >> [ 13.493721] x9 : ffffff8009543820 x8 : 61732d656e696c65 >> >> [ 13.499025] x7 : ffffff8008e97000 x6 : 0000000000000164 >> >> [ 13.504329] x5 : 0000000000000001 x4 : ffffffc87ff50988 >> >> [ 13.509633] x3 : ffffffc87ff50988 x2 : 0000000000000007 >> >> [ 13.514937] x1 : f90b249e3d9add00 x0 : 0000000000000000 >> >> [ 13.520242] Call trace: >> >> [ 13.522682] irq_set_chip+0xb4/0xd0 >> >> [ 13.526164] irq_set_chip_and_handler_name+0x20/0x50 >> >> [ 13.531125] xgpio_irq_setup+0xe4/0x180 [gpio_xilinx] >> >> [ 13.536175] xgpio_of_probe+0x25c/0x560 [gpio_xilinx] >> >> [ 13.541219] platform_drv_probe+0x50/0xa0 >> >> [ 13.545217] really_probe+0x1d0/0x280 >> >> [ 13.548871] driver_probe_device+0x54/0xf0 >> >> [ 13.552960] __driver_attach+0xe4/0xf0 >> >> [ 13.556703] bus_for_each_dev+0x70/0xc0 >> >> [ 13.560532] driver_attach+0x20/0x30 >> >> [ 13.564099] bus_add_driver+0x1dc/0x210 >> >> [ 13.567926] driver_register+0x60/0x110 >> >> [ 13.571755] __platform_driver_register+0x44/0x50 >> >> [ 13.576455] xgpio_init+0x20/0x1000 [gpio_xilinx] >> >> [ 13.581151] do_one_initcall+0x74/0x178 >> >> [ 13.584978] do_init_module+0x54/0x1d0 >> >> [ 13.588719] load_module+0x1b90/0x2120 >> >> [ 13.592461] __se_sys_finit_module+0xb8/0xd0 >> >> [ 13.596722] __arm64_sys_finit_module+0x18/0x20 >> >> [ 13.601247] el0_svc_common+0xbc/0x1a0 >> >> [ 13.604987] el0_svc_handler+0x68/0x80 >> >> [ 13.608728] el0_svc+0x8/0x18 >> >> [ 13.611686] ---[ end trace 8ee7549559e499e0 ]--- >> >> >> >> For reference: my device tree entry if needed: >> >> axi_gpio_0: axigpio@a0000000 >> >> { >> >> #gpio-cells = <2>; >> >> #interrupt-cells = <2>; >> >> compatible = "xlnx,xps-gpio-1.00.a"; >> >> gpio-controller ; >> >> interrupt-parent = <&gic>; >> >> interrupts = < 0 89 4 >; >> >> reg = < 0x0 0xa0000000 0x0 0x1000 >; >> >> xlnx,all-inputs = <0x0>; >> >> xlnx,all-inputs-2 = <0x0>; >> >> xlnx,dout-default = <0x0>; >> >> xlnx,dout-default-2 = <0x0>; >> >> xlnx,gpio-width = <0x4>; >> >> xlnx,gpio2-width = <0x4>; >> >> xlnx,interrupt-present = <0x1>; >> >> xlnx,is-dual = <0x1>; >> >> xlnx,tri-default = <0xffffffff>; >> >> xlnx,tri-default-2 = <0xffffffff>; >> >> }; >> >> >> >> Best, >> >> Josh >> >> >> >> Greg, Sounds great re your explanation about disabling the non rt >> driver. The question I'll have is, where in the GPIO core does the >> register magic take place? For example, the AXI Core has the following >> register offsets from the base: Are these offsets standard? >> >> Best, Josh >> >> >> >> CH1_OFFSET 0x00000000 >> CH2_OFFSET 0x00000008 >> GLOBAL_INTERRUPT_ENABLE_OFFSET 0x0000011C >> AXI_IP_INTERRUPT_ENABLE_OFFSET 0x00000128 >> INTERRUPT_STATUS_REGISTER_OFFSET 0x00000120 >> TRISTATE_CONTROL_CH1_OFFSET 0x00000004 >> TRISTATE_CONTROL_CH2_OFFSET 0x0000000C >> >> > I had some time to test this on the Zynq-7000 and I can see we are failing > when inserting the module. I'll continue to dig further into this. The > gpio driver can exist with or without the non-rt version (that's my > conclusion for now) . > Correction, the above is incorrect. The non rt driver needs to be inserted in the system before the xenomai driver can load properly. The xenomai gpio-core looks to see if the gpiochip exists in the system before it creates an rtdm gpio device for the rt gpio driver. > We use some functions from the gpiolib that don't rely on the Linux > kernel resources to pull information from the devicetree and then register > the gpio pins under /dev/rtdm/<gpio_pin>. We don't pick up specific node > values from the devicetree and we don't ask the non-rt driver for those > values either. Pulling specific values could be added but that should go > into the xilinx-gpio rtdm driver not the rtdm gpiolib code. > One other issue that I found is that the gpio-xilinx driver in the xilinx > linux tree has an interrupt chip where in mainline (at least 4.19) there is > no interrupt chip in the gpio code. This is why you are seeing the warn > saying it's not pipeline safe. If you require these gpios to be interrupt > sources then you'll need to add the code that allows these interrupts to be > pipeline safe. I can help with that. I'll also follow up with the > upstream kernel as to why this hasn't made its way to mainline, it's > possible xilinx just never upstreamed those changes. > > I'll keep working on this, > > Greg > -------------- next part -------------- A non-text attachment was scrubbed... Name: 288EE41577FB40D7ABA30D438BAB4428.png Type: image/png Size: 160 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20200522/48958ec3/attachment.png>
