Christos
-
Posts
306 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Christos
-
-
-
Flash is actually connected to SPI, which should be way faster than I2C. Also amount of it is enough only for U-Boot. I guess many of developers (me included) will pursue this way.
Yep, seen schematic too (lol rare for orange to give schematics fast, still wait for the OPiPC+..), mistakenly read somewhere that it is I2C though yes it is SPI, faster obviously but still I prefer eMMC when/if they will get it out.
-
Hopefully the guys in Armbian will give us some nice 64bit distro for the M3 soon.
(+1 for beggars in Armbian for M3 crowd..
) -
Think I'll wait for the Plus version, hopefully they'll give some eMMC soon.
Flash addition is nice, but I2C is slow..
-
Update 2: Schematic uploaded to linux-sunxi wiki. Same SY8113B voltage regulator switching between 1.1V and 1.3V so I would assume all that's needed to support the board is adding xradio driver for Wi-Fi and fiddling around in fex file to support TV out.
How on earth have you digged this up?
Is there a OPi-Zero page in sunxi site??
If you happen to have such good friends, can you please tell them to give the OPi-PC-Plus schematic too?
-
I have succesfull builds with Ubuntu Xenial 16.04.1 as host build system for all my H3 boards so far.
-
Interesting, mine is also a 5.24 Jessie 3.4.113 built on 27 Oct and its ok..
U-Boot SPL 2016.09-armbian (Oct 27 2016 - 20:59:21) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2016.09-armbian (Oct 27 2016 - 20:59:21 +0300) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi One DRAM: 512 MiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: phy interface0 eth0: ethernet@1c30000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2092 bytes read in 152 ms (12.7 KiB/s) ## Executing script at 43100000 Booting from SD 123 bytes read in 114 ms (1000 Bytes/s) 3138262 bytes read in 320 ms (9.4 MiB/s) 5093640 bytes read in 466 ms (10.4 MiB/s) ** File not found /boot/.next ** ** File not found .next ** 35908 bytes read in 424 ms (82 KiB/s) ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 3138198 Bytes = 3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Using machid 0x1029 from environment Starting kernel ... Loading, please wait... Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.25.2 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 /dev/mmcblk0p1: clean, 48462/938336 files, 325441/3850384 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. Welcome to Debian GNU/Linux 8 (jessie)! Expecting device dev-ttyS0.device... [ OK ] Reached target Remote File Systems (Pre). [ OK ] Reached target Encrypted Volumes. [ OK ] Set up automount Arbitrary Executable File Formats F...utomount Point. [ OK ] Reached target Paths. [ OK ] Created slice Root Slice. [ OK ] Created slice User and Session Slice. [ OK ] Listening on Delayed Shutdown Socket. [ OK ] Listening on /dev/initctl Compatibility Named Pipe. [ OK ] Listening on Journal Socket (/dev/log). [ OK ] Listening on udev Control Socket. [ OK ] Listening on udev Kernel Socket. [ OK ] Listening on Journal Socket. [ OK ] Created slice System Slice. [ OK ] Created slice system-getty.slice. [ OK ] Created slice system-serial\x2dgetty.slice. Starting Increase datagram queue length... Starting Restore / save the current clock... Starting Load Kernel Modules... Mounting Debug File System... Mounting POSIX Message Queue File System... Starting udev Coldplug all Devices... Starting Create list of required static device nodes...rrent kernel... Starting LSB: Set keymap... [ OK ] Reached target Slices. [ OK ] Mounted POSIX Message Queue File System. [ OK ] Mounted Debug File System. [ OK ] Started Increase datagram queue length. [ OK ] Started Restore / save the current clock. [ OK ] Started Load Kernel Modules. [ OK ] Started Create list of required static device nodes ...current kernel. [ OK ] Started LSB: Set keymap. [ OK ] Started udev Coldplug all Devices. Starting Create Static Device Nodes in /dev... Mounting FUSE Control File System... Starting Apply Kernel Variables... [ OK ] Listening on Syslog Socket. Starting Journal Service... [ OK ] Started Journal Service. [ OK ] Mounted FUSE Control File System. [ OK ] Started Create Static Device Nodes in /dev. [ OK ] Started Apply Kernel Variables. Starting udev Kernel Device Manager... [ OK ] Started udev Kernel Device Manager. Starting Copy rules generated while the root was ro... Starting LSB: Tune IDE hard disks... Starting LSB: Set preliminary keymap... [ OK ] Started Copy rules generated while the root was ro. [ OK ] Started LSB: Tune IDE hard disks. [ OK ] Reached target Sound Card. [ OK ] Created slice system-ifup.slice. [ OK ] Found device /dev/ttyS0. [ OK ] Started LSB: Set preliminary keymap. Starting Remount Root and Kernel File Systems... [ OK ] Started Remount Root and Kernel File Systems. Activating swap /var/swap... Starting Load/Save Random Seed... [ OK ] Reached target Local File Systems (Pre). Mounting /tmp... [ OK ] Activated swap /var/swap. [ OK ] Mounted /tmp. [ OK ] Started Load/Save Random Seed. [ OK ] Reached target Local File Systems. Starting Create Volatile Files and Directories... [ OK ] Reached target Remote File Systems. Starting Trigger Flushing of Journal to Persistent Storage... Starting LSB: Prepare console... Starting LSB: Raise network interfaces.... [ OK ] Reached target Swap. [ OK ] Started Create Volatile Files and Directories. [ OK ] Started LSB: Prepare console. [ OK ] Started Trigger Flushing of Journal to Persistent Storage. Starting LSB: Set console font and keymap... Starting Update UTMP about System Boot/Shutdown... [ OK ] Started Update UTMP about System Boot/Shutdown. [ OK ] Started LSB: Raise network interfaces.. Starting ifup for eth0... [ OK ] Started ifup for eth0. [ OK ] Reached target Network. [ OK ] Reached target Network is Online. [ OK ] Started LSB: Set console font and keymap. [ OK ] Reached target System Initialization. [ OK ] Listening on D-Bus System Message Bus Socket. [ OK ] Reached target Sockets. [ OK ] Reached target Timers. Starting Restore Sound Card State... [ OK ] Reached target Basic System. Starting Entropy daemon using the HAVEGE algorithm... [ OK ] Started Entropy daemon using the HAVEGE algorithm. Starting Regular background program processing daemon... [ OK ] Started Regular background program processing daemon. Starting Network Manager... Starting OpenBSD Secure Shell server... [ OK ] Started OpenBSD Secure Shell server. Starting /etc/rc.local Compatibility... Starting Login Service... Starting LSB: disk temperature monitoring daemon... Starting LSB: Load kernel modules needed to enable cpufreq scaling... Starting LSB: Start/stop sysstat's sadc... Starting LSB: Armbian gathering hardware information... Starting LSB: Starts LIRC daemon.... Starting LSB: Advanced IEEE 802.11 management daemon... Starting LSB: Start NTP daemon... Starting D-Bus System Message Bus... [ OK ] Started D-Bus System Message Bus. Starting System Logging Service... Starting Permit User Sessions... [ OK ] Started System Logging Service. [ OK ] Started Restore Sound Card State. [ OK ] Started /etc/rc.local Compatibility. [ OK ] Started LSB: disk temperature monitoring daemon. [ OK ] Started LSB: Load kernel modules needed to enable cpufreq scaling. [ OK ] Started LSB: Start/stop sysstat's sadc. [ OK ] Started LSB: Armbian gathering hardware information. [ OK ] Started LSB: Starts LIRC daemon.. [ OK ] Started LSB: Advanced IEEE 802.11 management daemon. [ OK ] Started LSB: Start NTP daemon. [ OK ] Started Permit User Sessions. [ OK ] Started Login Service. Starting Authenticate and Authorize Users to Run Privileged Tasks... Starting LSB: set CPUFreq kernel parameters... Starting Getty on tty1... [ OK ] Started Getty on tty1. Starting Serial Getty on ttyS0... [ OK ] Started Serial Getty on ttyS0. [ OK ] Reached target Login Prompts. [ OK ] Started LSB: set CPUFreq kernel parameters. [ OK ] Started Authenticate and Authorize Users to Run Privileged Tasks. [ OK ] Started Network Manager. Starting LSB: Set sysfs variables from /etc/sysfs.conf... Stopping LSB: Starts LIRC daemon.... [ OK ] Started LSB: Set sysfs variables from /etc/sysfs.conf. [ OK ] Stopped LSB: Starts LIRC daemon.. Starting LSB: Starts LIRC daemon.... Starting WPA supplicant... [ OK ] Started LSB: Starts LIRC daemon.. [ OK ] Reached target Multi-User System. [ OK ] Reached target Graphical Interface. Starting Update UTMP about System Runlevel Changes... [ OK ] Started WPA supplicant. [ OK ] Started Update UTMP about System Runlevel Changes. Debian GNU/Linux 8 orangepione ttyS0 orangepione login: root Password: Last login: Wed Nov 2 16:27:15 EET 2016 on ttyS0 Linux orangepione 3.4.113-rt143-sun8i #14 SMP PREEMPT RT Thu Oct 27 21:11:25 EEST 2016 armv7l ___ ____ _ ___ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) / _ \ _ __ ___ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | | | | | '_ \ / _ \ | |_| | | | (_| | | | | (_| | __/ | __/| | | |_| | | | | __/ \___/|_| \__,_|_| |_|\__, |\___| |_| |_| \___/|_| |_|\___| |___/ Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.113-rt143-sun8i System load: 0.12 Up time: 1 min Memory usage: 11 % of 490Mb IP: 192.168.1.12 CPU temp: 33°C Usage of /: 8% of 15G root@orangepione:~#Dont know if the latest commits after 27 Oct. did something weird, so @zador.blood.stained might have the answer to this.
-
Though do not know if it applies to your case, in a similar situation with my OPi ONE, I just used another SD card and it was booting ok.
(the other SD was even the exact same brand/model as the first one.. so it could be some write issue)
Have you tried a second new SD?
-
If there was only a schematic of it..
They have not even got out a schematic for PC+ that is out for quite some months now..
-
Ok,
My OPi made me be and feel really embarrassed..
Dir a reboot and now the darn thing works.. since this morning it gives me hard time and lots of frustration and now it simply works..
It looks the busy came after I did a "modprobe gpio-sunxi"
@jernej thank you very much, you are right, that mainline way of gpio arithmetic is also used in legacy.
Guys I feel very sorry for the noise and wasted bandwidth..
The bottom line is that the sunxi gpio docs need update to reflect that the mainline arithmetic is also employed in the legacy too nowadays, at least at 3.4.113..
Someone put a [solved] on the title
Thanks to all
Christos
-
Yes, you are right. Sorry. This is the right place to check: https://github.com/igorpecovnik/linux/blob/sun8i/drivers/gpio/gpio-sunxi.c
compared to old linux-sunxi kernel which uses [gpio_para] data: https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/gpio/gpio-sunxi.c
If you think this is right, then here it comes the legitimate question..
what sysfs commands should I put to set high the physical pin 29 of the 40 pin connector in OrangePi ONE?
-
I'm 100% sure that arithmetic is correct. Check https://github.com/igorpecovnik/linux/blob/sun8i/drivers/pinctrl/pinctrl-sunxi.h#L23and https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/include/mach/pinctrl.h#L19
You will get busy for sure if pins are claimed by some other driver, in this case uart, if fex has "uart_used = 1" for uart2.
No, that is not the case.
Not PA07, nor PA03 are reserved in anything else in FEX.
And that is on the OPi ONE.
For my NanoPi NEO though, (with Armbian 5.24, 3.4.113) everything works by using FriendlyArm's matrix example framework and the sysfs.. that is even without the FEX gpio parameters enabled!!
Most likely the sysfs gpio is broken, please @jernej dont get me wrong but I firmly believe that someone should look into it in kernel 3.4.x unless of course nobody cares..
-
This is definitely the scheme for the mainline kernel, but I don't think it applies to 3.4.x which still uses FEX for configuring pin numbers.
Exactly
@jernej
Did the mainline arithmetic and got
root@orangepione:/sys/class/gpio# ls -l total 0 --w------- 1 root root 4096 Oct 30 14:38 export lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/sunxi-pinctrl/gpio/gpiochip0 --w------- 1 root root 4096 Oct 30 14:25 unexport root@orangepione:/sys/class/gpio# echo 7 > export -bash: echo: write error: Device or resource busy root@orangepione:/sys/class/gpio#
which is not correct as the gpio pin 7 according to FEX is used by UART2 (PA3)
Will continue the tests here but it looks to me that there is something broken in sysfs gpio..
-
Ok,
Thanks zador, but you didnt replied on why I see different gpio names.. is it just a newer thing and sunxi gpio docs did not catch up?
There has to be something that I miss entirely since I cannot do a single led turn on with plain sysfs gpio.
(by using WiringOP and their somehow different gpio numbering, the leds do work ok though.. but I want to have plain sysfs gpio access without WiringOP)
So,
Got my OPi ONE, Armbian 5.24, jessie kernel 3.4.113
The script.fex compiled to .bin and rebooted with
gpio_used = 1 gpio_num = 19 gpio_pin_1 = port:PA06<1><default><default><0> gpio_pin_2 = port:PA13<1><default><default><0> gpio_pin_3 = port:PA14<1><default><default><0> gpio_pin_4 = port:PA01<1><default><default><0> gpio_pin_5 = port:PD14<1><default><default><0> gpio_pin_6 = port:PA00<1><default><default><0> gpio_pin_7 = port:PA03<1><default><default><0> gpio_pin_8 = port:PC04<1><default><default><0> gpio_pin_9 = port:PC07<1><default><default><0> gpio_pin_10 = port:PA02<1><default><default><0> gpio_pin_11 = port:PA21<1><default><default><0> gpio_pin_12 = port:PA07<1><default><default><0> gpio_pin_13 = port:PA08<1><default><default><0> gpio_pin_14 = port:PG08<1><default><default><0> gpio_pin_15 = port:PA09<1><default><default><0> gpio_pin_16 = port:PA10<1><default><default><0> gpio_pin_17 = port:PG09<1><default><default><0> gpio_pin_18 = port:PG06<1><default><default><0> gpio_pin_19 = port:PG07<1><default><default><0>
Also got the ONE's schematic from here
-> http://linux-sunxi.org/File:ORANGE_PI-ONE-V1_1.pdf
Now, lets say that I want to use the physical pin 29 of the 40pin connector. That is named PA07.
In script.bin I see that PA07 is gpio_pin_12 so I guess I have to use and export pin 12.
root@orangepione:~# root@orangepione:~# cd /sys/class/gpio root@orangepione:/sys/class/gpio# ls -l total 0 --w------- 1 root root 4096 Oct 30 14:16 export lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/sunxi-pinctrl/gpio/gpiochip0 --w------- 1 root root 4096 Oct 30 14:16 unexport root@orangepione:/sys/class/gpio# echo 12 > export root@orangepione:/sys/class/gpio# ls -l total 0 --w------- 1 root root 4096 Oct 30 14:17 export lrwxrwxrwx 1 root root 0 Oct 30 14:17 gpio12 -> ../../devices/platform/sunxi-pinctrl/gpio/gpio12 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/sunxi-pinctrl/gpio/gpiochip0 --w------- 1 root root 4096 Oct 30 14:16 unexport root@orangepione:/sys/class/gpio# cd gpio12 root@orangepione:/sys/class/gpio/gpio12# ls -l total 0 -rw-r--r-- 1 root root 4096 Oct 30 14:17 active_low lrwxrwxrwx 1 root root 0 Oct 30 14:17 device -> ../../../sunxi-pinctrl -rw-r--r-- 1 root root 4096 Oct 30 14:17 direction -rw-r--r-- 1 root root 4096 Oct 30 14:17 edge drwxr-xr-x 2 root root 0 Oct 30 14:17 power lrwxrwxrwx 1 root root 0 Oct 30 14:17 subsystem -> ../../../../../class/gpio -rw-r--r-- 1 root root 4096 Oct 30 14:17 uevent -rw-r--r-- 1 root root 4096 Oct 30 14:17 value root@orangepione:/sys/class/gpio/gpio12# echo out > direction root@orangepione:/sys/class/gpio/gpio12# echo 1 > value root@orangepione:/sys/class/gpio/gpio12#
At this moment, I expected to have high on the pin, but.. nope!!
When I do the WiringOP exercise for the same physical pin, it does work though..
So, please guys... is there something that I miss here?
Is there some pin numbering or conversion that I have to take into account?
Christos
-
WiringOP library uses C code as a backend, so you can take their implementation that uses /dev/mem for accessing registers directly: https://github.com/zhaolei/WiringOP/blob/h3/wiringPi/wiringPi.c
or sysfs based access: https://github.com/zhaolei/WiringOP/blob/h3/gpio/gpio.c
Can't help with the "simple" part, sorry
Is WiringOP the ONLY module that gives proper GPIO functionality on sunxi?
Can we have sysfs GPIO without WiringOP or not?
I'm asking this because I'm a bit puzzled with sunxi gpio and armbian.
As I see in sunxi gpio docs
-> http://linux-sunxi.org/GPIO
the names of pins in the sysfs supposedly are "gpio1_pe0" but I get instead "gpio1" (and so far its not working..)
(Got the script.bin gpio enabled ok)
-
I didn't realize that RT patching was a supported feature in Armbian.
Is this turned on in the build tool or ??
I tried searching for RT_PREEMPT and RealTime.
Interested in turning on for H3 (Neo and M1) for machinekit testing on board other than BBB.
Would be great if we had a table of features and levels of support that folks could update as they test them on their boards, something like the mainline kernel one.
Maybe this also exists and I can't find it.
Great work again as I see we are on 4.9 in Dev.
Allan
This is how-to
-
Hi
Struggling here with Orange's GPIO so I would be glad to see any pointer to a working gpio example for 3.4.x kernel.
Even a simple one pin state switching would be great.
Christos
-
If you rotate 90degrees the heatsink and bolt it again, you will see that it has proper opennings for pin soldering..
Christos
-
Yep,
Seen the commit in github a couple of minutes ago, tried it and its succeeding now, its fine.
Thanks!
-
@Igor
Just an hour ago did a new build and got
[ warn ] ... 30-real-time143-full-plus-rt-fixes.patch [ failed ]
Up until this morning everything was fine but now the patch fails.
It seems today's commits brake the RT.
-
Lets continue this here
BTW, everything looks ok now in Armbian 5.24 (jessie 3.4.112)
-
Ok Igor, thanks for answering here.
Quite a bit though of info in just two lines.. and also eye-openning too
Some clarifications/questions
If you are using your own kernel build
1. My own means even if I do a plain (no mods/no patches) build?
2. I usualy enable your own provided real time patch, that means the build falls into the 'my own build' category and thus should avoid upgrades?
Remove repository, use pin, ...
3. how can I remove repository and what do you mean 'use pin' ?
Next. 8192cu driver from kernel is broken. If you use self build driver, than you need to issue depmod -a / rebuild the driver on each kernel upgrade.
As of today, with build Armbian 5.24 (jessie 3.4.112), I am able to work with 8192cu (with whatever driver/firmware is there in repository) out of the box.
Just need an inclusion of "8192cu" in /etc/modules-load.d/modules.conf
After that and a restart, using nmtui got AP list and can connect succesfully.
This has tested in OPiONE & NanoPiNEO.
Christos
-
Build today a new 5.23 jessie 3.4.112 (with rt143) for H3 (NanoPiNEO)
Configured all wifi ok (8192cu)
Later on, saw the indicated upgrade on 3 packages
linux-headers-sun8i
linux-image-sun8i
tzdata
First I installed the tzdata and all were still working ok.
The
linux-headers-sun8i
linux-image-sun8i
when installed made wifi (8192cu driver) to vanish.
After a hint for install the armbian-firmware-full, the dongle became visible in ifconfig as wlan0 but
not being able to connect anymore on any AP although previously, before the upgrade, everything was connecting and working ok.
Though it might be proper to report it also here in development section (reported it in H3 but got no replies), although I do not know if those upgrades come from here.
Christos
-
As I reported yesterday, after an upgrade, wifi was lost.
Although wlan devices were visible via ifconfig, no connection to AP was possible.
(8192cu driver)
Today I tried to have fresh Armbian build , got a 5.23 jessie
login as: root root@192.168.1.15's password: _ _ ____ _ _ _ | \ | | __ _ _ __ ___ | _ \(_) | \ | | ___ ___ | \| |/ _` | '_ \ / _ \| |_) | | | \| |/ _ \/ _ \ | |\ | (_| | | | | (_) | __/| | | |\ | __/ (_) | |_| \_|\__,_|_| |_|\___/|_| |_| |_| \_|\___|\___/ Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.112-rt143-sun8i System load: 1.31 Up time: 3 min Memory usage: 15 % of 490Mb IP: 192.168.10.2,192.168.1.15 CPU temp: 34°C Usage of /: 8% of 15G [ 2 updates to install: apt-get upgrade ] Last login: Wed Oct 26 16:48:52 2016 from 192.168.1.6 root@nanopineo:~#
As you see got the RT also build in 3.4.112-rt143-sun8i
WiFi 8192cu driver was up and running just fine,
As there were updates indicated, did the apt-get update and upgrade..
After that, AGAIN WiFi (8192cu) got lost and no connection was possible any more.
Tried the armbian-firmware-full, but obviously the firmware there has some difference, the driver is no longer able to connect although shows up in ifconfig.
ALSO, the kernel got a different name.. instead of "3.4.112-rt143-sun8i" now the RT was missing from title, dont know if that means anything deeper like RT mods gone for real, but I do report it.
And thats the new banner
login as: root root@192.168.1.11's password: _ _ ____ _ _ _ | \ | | __ _ _ __ ___ | _ \(_) | \ | | ___ ___ | \| |/ _` | '_ \ / _ \| |_) | | | \| |/ _ \/ _ \ | |\ | (_| | | | | (_) | __/| | | |\ | __/ (_) | |_| \_|\__,_|_| |_|\___/|_| |_| |_| \_|\___|\___/ Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.112-sun8i System load: 0.36 Up time: 1 min Memory usage: 8 % of 494Mb IP: 192.168.1.11 CPU temp: 36°C Usage of /: 8% of 15G Last login: Wed Oct 26 16:51:18 2016 from 192.168.1.6 root@nanopineo:~#
So far the experience on upgrade shows that its untrusted at least..
One question, guys, is there any chance that my 8192cu driver wifi dongles work again in Armbian as they were a couple of days before?
or should I forget about that?..
[NanoPi M3] Cheap 8 core (35$)
in Beginners
Posted
@lex
At least I managed to get a full image generated from the info and repositories mentioned in the thread (artik7 though.. "./release.sh -c config/artik710.cfg -m").
I mean performed succesful compilation and generation of u-boot, kernel, rootfs and all of them combined in a image specifically for SD. The way is there in the driver developer's guide.
But when booted did nothing, not even uboot prompt on M3's tty/uart port.
Either way though that means the necessary components are there and just sit and waiting for some armbian-team guru ( @Igor , @tkaiser ) to come and see how this can be tailored for the M3 ..just sayin..
Christos