[SOLVED] Kernel driver for GPIO
Where can we find the kernel driver for the Up^2?
My applications requires an RT kernel (which available in upstream Debian), so I can't use the kernel that comes with ubilinux.
Are there any instructions on how to compile a kernel for the Up^2?
The documentation (here) is very sparse.
Comments
-
I accidentally posted in the wrong section - can you please move it to the software section.
-
This is the gpio / pinctrl driver for the upboard.
But there are some other files and drivers that are probably also required, I'd suggest to use the Find File function of github, search for upboard and just copy everything to your kernel that looks like it is Up specific.Compiling the kernel for an UP Board is no different from compiling a linux kernel for any other system (there are plenty of guides on how to do that on the internet). If you do it on the board directly, it is pretty slow, even when you use all 4 cores, so maybe also look into how to compile on a different PC and then copying the compiled kernel to the Up board.
-
Actually, you could also just compile the drivers by themselves, might be easier (and faster to compile) then merging them into your kernel.
-
Thanks a lot, I got it up and running. Next step would be to extend the driver for mmap. Has anyone already achieved this?
-
@nukular Taking a closer look at the driver I understand that the FPGA just acts as a level converter between the RPi pins and the GPIOs of the UP^2, is this correct?
Data is passed to the FPGA via pin wiggling: https://github.com/emutex/ubilinux-kernel/blob/upboard-4.9/drivers/mfd/upboard-fpga.c#L192
-
Yes, as far as I know the FPGA is just used as a level converter.
Regarding mmap: There have been some threads here where people talked about this, but I don't know if anyone has achieved this or if it is possible. I haven't really looked into it.If you do and you get it to work and update here would be nice. It would also be interesting to see if that increases the speed at which GPIOs can be accessed. Right now gpio_set_value() takes about 5µs, which is pretty long.
-
-
Yes, the kernel driver is up and running.
-
@machinekoder have you ported the GPIO driver to a new kernel version? If so, have you made the code available somewhere? I am interested in getting GPIO working on 4.18 but would love a shortcut.
-
@Gnurou No, I have used the same kernel already available for the Up2. You can find more details about how I applied the RT patches here: https://machinekoder.com/compiling-an-rt-kernel-for-the-up-suared/
-
@machinekoder thanks for the reply. After some efforts I eventually managed to port the GPIO driver to 4.18 (some kernel interfaces have changed since 2016 and the initial patchset) and got it working as I wanted... excepted for the fact that contrary to the Raspberry Pi, the Up board does not have internal pull-up resistors, which makes the GPIO pins useless for what I need them to do (detect when push-buttons are pressed).
Fully Raspberry Pi compatible eh? Well not so much. With the lack of proper upstream support for things as basic as the GPIO pin header, this board turns out to be quite a disappointment.
-
@Gnurou could you please let me know the procedure to patch kernel-4.18 ?
I have downloaded patches from https://aur.archlinux.org/linux-up.git during kernel compilation I see following error.
MODPOST vmlinux.o
WARNING: vmlinux.o(.data+0x2235c8): Section mismatch in reference from the variable up_board_info to the variable .init.data:up_pinmux_maps
The variable up_board_info references
the variable __initdata up_pinmux_maps
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console -
@harishom please give me a few days and I will post my 4.18 kernel tree. It includes working GPIO (GPIO numbering has changed since 4.9 so the patches had to be updated), and a WIP pinctrl fix for GPIO interrupts. Does the job for me, now I'm hooking some pullup resistors on a protopal board to get the behavior I need...
-
Thanks @Gnurou in the mean time if you have kernel patch that would be great so I can try myself..?
-
Sorry for the time it took me to come back to this! I have finally updated the 4.19 tree with working GPIO for the UP board: https://github.com/Gnurou/linux/commits/up_board_4_19
It is made of the first RFC patches that have been published back in 2016 (!), plus fixup patches of my own to make it easy to understand the changes I have made. With these fixes I can use the GPIOs as expected, and also listen to interrupts on them (that required some extra fixes in the Cherrytrail pinctrl driver which I am not very fond of, hence the hacky status).
Hope this helps!
-
thanks @Gnurou , I will give it a shot..
