A20 Micro SPI and mmap

[mMerlin]

I have been handed a project to do some development using a couple of A20-OLinuXino-MICRO boards.  This needs some reasonable fast I/O on GPIO pins, plus SPI to custom hardware.  The example GPIO access did not look even close to handling the speed that was needed, so I have been exploring options.

I did a small standalone program based on the u-boot hello_world program, and got I/O rates up to 8 MHz.  Plenty for the planned project, but when I tried to expand the program to do the calculations with the data, it crashed.  Research says that the cause is attempting to do math operations without first initializing the FPU.  I have not tracked down the initialization sequence needed yet, but have a couple of leads.  This got put on hold, because in parallel:

Using mmap to access GPIO registers regular (running from linux) program looked to be potentially fast enough, and doing the development for linux instead of standalone would simplify the project.  The GPIO registers are not in the first 1 MB of memory, so I needed to rebuild the kernel without CONFIG_STRICT_DEVMEM=y.  To do that, I did the research and learned to rebuild the sd card from scratch / sources with the legacy U-Boot and 3.4 kernel using:
https://github.com/linux-sunxi/sunxi-tools
https://github.com/linux-sunxi/sunxi-boards.git
https://github.com/linux-sunxi/linux-sunxi.git
https://github.com/linux-sunxi/u-boot-sunxi.git
debian_FS_34_90_camera_A20-olimex.tgz
and information from multiple sources, to cross compile from Fedora 21.  This is outside most of my existing expertise, to I was careful to as much as possible clone the configuration of the supplied sd card. 

After the rebuild, bit-banging GPIO ports through mmap was a little, but not significantly, slower than the standalone program.  Around 7.5MHz.  All good so far.  The needed math was already available from a simulation program that was available before I even started the project, and merged in after a bit of tweaking to separate the simulated input from the calculations. The next step is to add the SPI communications.  Stuck again.  It **appears** that the rebuilt environment does not have full support for SPI.  At least (without any hardware attached), I can not locate any SPI devices to try running the spidev_test.c program from Documentation/spi/

Research again.  I found reference to adding SPI drivers to an A20 cubie board, and also notes about spi support being added into the mainline 3.15 kernel.  In the mean time, my dev environment moved from Fedora 21 to 22.  Opps.  I can not longer make the legacy U-Boot or kernel.  gcc5 not supported by the build scripts.  Choices again.  Add an older gcc4 to my dev environment, or move to mainline U-Boot and kernel.  I went with the later.  Following (starting from) https://linux-sunxi.org/Mainline_Kernel_Howto, I have been able to create an sd card with the mainline build information, but only when still using the 3.4.90 rootfs.  Everything else I have tried fails in init with errors that look like incompatible versions.  Wrong architecture, or mismatched compile options, if I interpret correctly.  With that rootfs, I can boot to the console, but there are a bunch of errors about not being able to find kernel modules, and hdmi screen never shows up:

Code Select Expand


FATAL: Module sw_ahci_platform not found.
FATAL: Module lcd not found.
FATAL: Module hdmi not found.
FATAL: Module ump not found.
FATAL: Module disp not found.
FATAL: Module 8192cu not found.
FATAL: Module gpio-sunxi not found.
FATAL: Module sunxi_cedar_mod not found.
FATAL: Module sunxi-gmac not found.
FATAL: Module sunxi-emac not found.
FATAL: Module leds-sunxi not found.
FATAL: Module sun4i-keyboard not found.
FATAL: Module nand not found.
FATAL: Module gt2005 not found.
FATAL: Module sun4i_csi0 not found.
FATAL: Module pwm-sunxi not found.
FATAL: Module g-ether not found.

Looks like something missing in my build process, or the used rootfs is not good with the kernel I built.  Since this a mainline kernel, I probably need to copy code for drivers, and maybe adjust some more config flags.  Hitting the limits of my knowledge, and I need some input to try to prune the number of things I need to look at.  Too many places that MIGHT get things going forward again, but without enough direct knowledge to know which one(s), and if I am doing them correctly.

The **goal** is to get an environment setup that supports high speed GPIO and SPI to custom hardware, plus serial (uart) communications to a more standard system to provide control and data logging.  The final system will be headless, but I am trying to simplify some of the development by working directly with the board, instead of cross-compiling everything.  Which would just introduce more places for things to go wronnngggggggg.  Especially since none of the documentation I have found is for working with Fedora.  Most seems to be Ubuntu based.  In general, I have been able to work from the existing, and adjust the details.  The exception so var is using debbootstrap.  I have not figured out how to get the needed arm-static file to install on Fedora 22.  I could probably just download it, but that is just one more path for the rootfs.  Eventually, this needs to move to NAND, but I'll ignore that until it actually works.

• Is there a better rootfs source that will work with the mainline kernel?
• Is there someplace to look to better configure a mainline kernel for an A20-OLinuXino-MICRO board?
• will one or both of the above get SPI working?
• Should I go back to the modified legacy build, and add SPI drivers?
• Did I just mess something up, and SPI should already be in the legacy environment?
• is there a better distro to start from?  I saw references to openwrt, archlinux and more, but have not followed up.  I expected I would need to rebuild those from sources anyway, to get mmap support.
• given the project constraints (continuous 100Khz complete cycle times), do I need to start over, and look for a RT distro?

Any pointers much appreciated

[martinayotte]

You can look at this page where there are several kernel images with SPI already built-in :
http://www.armbian.com/olimex-micro/

[mMerlin]

You can look at this page where there are several kernel images with SPI already built-in :
http://www.armbian.com/olimex-micro/

I looked at that, and have it on my list as a possible path, but would need to still rebuild from sources to get mmap support for the GPIO.  From the quick look I did, those are all pre built images.  I would need the sources and config parameters to recreate them, and change the (probably single) config flag.

[Gerrit]

I would need the sources and config parameters to recreate them, and change the (probably single) config flag.

to get the config from the active kernel

Code Select Expand

zcat /proc/config.gz > .config

[mMerlin]

I would need the sources and config parameters to recreate them, and change the (probably single) config flag.

to get the config from the active kernel

Code Select Expand

zcat /proc/config.gz > .config

OK, but what source version / tag / commit was used to build the image?  What patches were applied?  To recreate (with changes) needs all of those details.

[Gerrit]

OK, but what source version / tag / commit was used to build the image?  What patches were applied?  To recreate (with changes) needs all of those details.

kernel version is mentioned in the .config file, which patches are used can only get that info from the source where you got the kernel from.

[mMerlin]

OK, but what source version / tag / commit was used to build the image?  What patches were applied?  To recreate (with changes) needs all of those details.

kernel version is mentioned in the .config file, which patches are used can only get that info from the source where you got the kernel from.

I had not realized the kernel version was a comment in the .config.  But the patches were sort of the point.  My initial post said I needed both SPI and mmap (without CONFIG_STRICT_DEVMEM=y).  I got pointed to http://www.armbian.com/olimex-micro/ as a source of images with SPI.  Without enough information to rebuild them without the CONFIG_STRICT_DEVMEM flag, they are of no use to me.

I had a look at the armbian documentation pages.  There is probably enough information to do a rebuild, but it is all scripted in a ubuntu based system.  I would need to spin up a new VM, create their development environment, build with modified flag.  Then test to see if it worked, or I missed something again.  A few days work, and I would then need to keep that process around to be able to recreate a base image again later.  I was 'hoping' to be able to keep the number of environments needed to support the project later down.

I am currently working (slowly) to get a gcc4.9.3 arm cross compile into fedora 22.  That should at least let me recreate the legacy image that worked.  Without SPI.

Any hints on why my attempt to build from the mainline sources is so broken?

[dlombardo]

I propose "spin up a new VM, create their development environment".

Usually, I have a separate VM for this kind of tasks. Headless (no X-Windows) or XFCE.
VMs are easy to store, low maintenance and always ready to run if needed.

These way (re)building of Kernel, building some custom applications or sometimes even testing scripts is easy and predictable.
Maintaining current MAIN Workstation OS with all the previously used compilers, tools etc. is a pain.

Just my two pence.