LinuxQuestions.org - Orange PI Zero (H2+) as a GPS "compass" from box to works

- Slackware - ARM (https://www.linuxquestions.org/questions/slackware-arm-108/)

- - Orange PI Zero (H2+) as a GPS "compass" from box to works (https://www.linuxquestions.org/questions/slackware-arm-108/orange-pi-zero-h2-as-a-gps-compass-from-box-to-works-4175647485/)

Orange PI Zero (H2+) as a GPS "compass" from box to works

Hi,
I've got an Opi Zero (Opi0 now on) to be the backend of an GPS navigation device i made.

It was originally a home for an Early Raspberry PI B model but it's idle power draw was just "not it"...

The Opi0 comes with an H2+, i opted for 512 RAM, one host USB plug, one USB OTG plug, 5V PoE ready (so not really PoE ready) ethernet receptacle, WiFi antenna, one more USB port on the pin soldered header (and what not there), TF slot and the non soldered 26 pin "PI pin header" layout of which is identical to every other R-pi shield there is.

Quite a mouth full

first impressions:
1. cheaper ($16 -ish to the doorstep)
2. compatible 26 pin header
3. nimble power draw on idle
4. decent quality (no objections there)
5. tiny! :3
6. boots the H3 boot loader and works with other H2 code
7. has two LEDs one of which can have hear-beat pulse (so 100% cool factor guaranteed :hattip:)

TODO:
- photos
- howtos
- optimizations (if any)
- modules for the wireless if present in kernel (so we can list it in supported devices)
- benchmarks
- more photos

stay tuned ...

So far I've got to making the Device tree parameter match my board and reboot was successful.
:twocents:

still no trace of WiFi
and i seem to be missing the SPI console for my TFT

so far updating the system (running current) seems to put the power draw at 150-300mA averaging in higher end of 200mA

The wireless radio is an XR819 it is reportedly a b/g/n capable chip,

just found this info...

This, while by far not a show stopper, it generally a bad sign.

Out of tree, dtb and binary blob usually means footwork on each kernel update.

Investigating

Adding few more links of interest as I prepare:
A guy who made a serial display work on the Zero.

Sources for the fbtft we depend on.

I hope the frame-buffer driver is both in mainline and configured in Slackware ARM, and all there is left to do is to map the pins correctly.

Nice read and video there.

I'm looking for an alternative to Raspberry Pi2B (quad core armv7) for specific networking solutions and this Orange PI Zero (H2+) looks promising. I don't need WiFi, anyways the implementation with that wired antenna looks pretty dumb, but it has an Ethernet port and that is just excellent for my needs.
I'm wondering if that armv7 SoC is stable under constant heavy load (no overheating/throttling) and what is the performance of openvpn on a single core (openvpn is not multi-core able) with the cipher AES-128-CBC. The Raspberry Pi2B provides some ~20Mbps constantly on one core and that's what I'm looking after for the alternative.
If you use openvpn in your setup, please be so kind and do some speed measurements and post the results.
Thanks!

@abga
if you can provide a simple way to benchmark it - i will try to supply the result (had no intention to use any vpn)

@drmozes
kind sir, would there be an easy way to add support for Orange Pi zero here:

ftp://ftp.arm.slackware.com/slackwar...H3/u-boot/bin/

So I can report back if any issue is found?

Other than that, added a heatsink (photos still due) to the H3 and the DDR RAM module - and the lockups went away.

Quote:

Originally Posted by SCerovec (Post 5958183)

@abga
if you can provide a simple way to benchmark it - i will try to supply the result (had no intention to use any vpn)

Well, the way to benchmark the vpn speed isn't really that simple and I'll divert the topic of this thread too much. I could provide you with the instructions privately (PM). Basically you need two hosts, this Orange Pi Zero and another one, more powerful (just to not bias the results - x86 maybe) and setup a simple openvpn tunnel between them, then test the speed over this tunnel with iperf:
https://openvpn.net/community-resour...ey-mini-howto/
https://www.slackbuilds.org/reposito...network/iperf/

For the moment, the openssl speed test will suffice (just post the last 3 lines from the output please):

Code:

#This was done on a Rpi Pi 2B

/usr/bin/openssl speed -evp aes-128-cbc

#output (last 3 lines):

The 'numbers' are in 1000s of bytes per second processed.

type            16 bytes    64 bytes    256 bytes  1024 bytes  8192 bytes  16384 bytes

aes-128-cbc      16836.63k    21461.35k    22901.25k    23324.67k    23431.85k    23445.50k

Monitoring the cpu frequency while putting the system under pressure for more than 10 minutes (it takes some time to overheat and maybe throttle) during some compilations will also suffice to understand how stable the performance is.

Quote:

Originally Posted by SCerovec (Post 5958183)

@abga

kind sir, would there be an easy way to add support for Orange Pi zero here:

ftp://ftp.arm.slackware.com/slackwar...H3/u-boot/bin/

They'll appear in the next upload. I'm sticking with v2018.07-rc1 though because more recent versions don't let me 'save env' the environment to the SD card.
I haven't had time to report that issue to u-boot yet. Anybody else is welcome to do test and report that. Ideally we'd have a newer version so that HDMI support works, but I'm not upgrading it until that issue is resolved.

Quote:

Originally Posted by drmozes (Post 5958590)

headsup (find the >>env<< string on that list)

will attempt building and report later

Quote:

Originally Posted by SCerovec (Post 5958921)

headsup (find the >>env<< string on that list)

will attempt building and report later

Thanks!
In a nut shell, if you follow the INSTALL doc, you put u-boot on an SD card, and set the u-boot environment variables, then run 'save env'
This fails to write the environment to the SD Card.
I looked at whether it was just some default setting, but couldn't figure it out -- and wasn't sure if it was a bug or a deliberate change.

The u-boot for Orange Pi zero is now on the FTP site. I tried building the other "zero" ("zero plus" I think), but it would not compile.

@SCerovec
Regarding the vpn speed test & performance stability, I got an old review on youtube:
https://www.youtube.com/watch?v=MzxLYGWQddA
(at minute 6 - load test - it starts to throttle...)
Here's another interesting statement:
https://linux-sunxi.org/H3
"If you run it without heatsink, fan and proper dvfs settings, you risk overheating."

I looked around at the possible sources to obtain such an Orange Pi board and considering the Pi One (even without WiFi) the best deal. It has a larger surface, maybe dissipates the heat better and improved connectivity (HDMI, audio out, etc.)
Orange Pi Zero 256MB RAM - 17,6 EUR
Orange Pi Zero 512MB RAM - 19 EUR
Orange Pi One 512MB RAM - 19 EUR

I considered the armv7 pretty stable and only read about the newer armv8/v9 overheating and throttling.
(end of off-topic)

Quote:

Originally Posted by abga (Post 5959522)

the price is too big when compared to newer boards such as rock64 with 1GB of memory - 24.95 USD

re off topic:
The market really makes a tough choice now days.

I merely picked a known OEM and the most affordable board for my task.
/OT

I'm revving up my tools slowly:
file: u-boot.SlackBuild

Code:

#!/bin/sh



# cest73@ya.ru under ISC license for Slackware-current 2017 onward

#

image="u-boot-sunxi-with-spl.bin"



echo "seeking linaro toolchain:"

for check in $(ls -d *linaro*)

do

  if [ -f $check ]; then

    echo "we seem to have to decompress an archive here:"

    tar -xf $check && echo "extracted."

  elif [ -d $check ]; then

    echo "we seem to have an directory to delete here:"

    rm -rf $check && echo "deleted."

  else

    echo "you have to download an appropriate toolchain for this script."

    echo "try from:  https://releases.linaro.org/components/toolchain/binaries/"

    echo "Or on:    https://linux-sunxi.org/Toolchain."

    echo "Good luck."

    exit 2

  fi

done



for recheck in $(ls -d *linaro*)

do

  if [ -f $recheck ]; then

    echo

  elif [ -d $recheck ]; then

    toolchain=$recheck

  fi

done

echo "Toolchain:["$toolchain"]"



export KBUILD_OUTPUT=`pwd`/u_boot-build



export CC=`pwd`/${toolchain}/bin/arm-linux-gnueabihf-





${CC}gcc --version



echo "we are building here:"

echo ${KBUILD_OUTPUT}

mkdir -vp ${KBUILD_OUTPUT}

rm -vrf ${KBUILD_OUTPUT}/*



echo "entering source tree"



cd u-boot



echo "checking for target:"



configs=$(ls configs | awk -F_defconfig '{print $1 "_defconfig " $1 }')





dialog --backtitle "Board selection list, cancel to abort" --no-tags --menu "Boards to pick from:" 0 0 12 ${configs} 2>/dev/shm/result



selection=$(cat /dev/shm/result)

echo "our target is: ["$selection"]"



if [[ "X$selection" == "X" ]]; then

  echo "nothing selected, aborting."

  exit 0

fi

our_target=$selection



make ARCH=arm CROSS_COMPILE=${CC} distclean



make ARCH=arm CROSS_COMPILE=${CC} ${our_target}



 make ARCH=arm CROSS_COMPILE=${CC} nconfig



make -j4 ARCH=arm CROSS_COMPILE=${CC} all



echo "if all went well, here we have the image ready"





file=${KBUILD_OUTPUT}/${image}

if [ -a $file ]; then

  echo "image found :"

  ls -h $file

else

  echo "error, no valid output"

  exit 1

fi



echo "partition the device, and issue as root:"

echo "dd if=$file of=\"/dev/<yourMMC>\" bs=1k seek=8"

alpha quality - feedback highly welcome
CAVEATS:
the script relies on you to get the correct u-boot from git:

Code:

git clone -b sunxi https://github.com/linux-sunxi/u-boot-sunxi.git

and pick and download a favorable toolchain:
I picked gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabihf.tar.xz
the script will provide hopefully helpful links on the first dry run

Besides not git-cloning the script builds outside the cloned directory - to keep it as tidy as possible across multiple builds.

I find it somewhat annoying to re-extract the toolchain every time - you can comment out the few lines that take care it's always the correct one and a fresh extract for the while you stick to the same one.

Would you be in any doubt how to do it - just leave as is - and replace the toolchain with a more recent one if you hit into build errors of any sort.

Should that fial, try upgrading the git-cloned directory of the u-boot sources as well.

Once the toolchain is extracted, the script will parse the available board options and provide an lengthily list to pick from. This might be used for more than Orange Pi Zero, and so i provide it here in hopes it will eventually be so.

After the pick the script offers a nconfig (can be changed to any - xconfig for instance) to conveniently mess up or finely tune the u-boot options (add or remove options to boot to or from).

Past that all that is left is to build the image - being built on a desktop (yes this is cross compiling after all) provides speedy build times versus native compiling.

At the end the script locates the file of interest for you and lists it along with a short "survival guide" type of command to have it "stamped" onto a SD card of choice.

The script is run on an up to date 14.2 and i see no reason it would not run on -current as well. Only dependency (on the toolchain) seems to be glibc-2.14 or more recent one (2.23 here).

In no way is this script provided here to belittle or obsolete any of the provided work by our good host drmozes, contrary its merely a tool for us who hack to play with in hopes we get some handy options uncovered and have them become part of the official configs of the boards we use.

In hope this will further our efforts to streamline more boards into becoming supported, yours truly :hattip:

P.S.
One of the reasons i post this is following: I noticed that i come back after a while and find this info (and scripts) useful for the next project :D

P.P.S.
one of the reasons i will hack the u-boot is - i will try to make my SPI serial LCD screen active as soon as possible.

Quote:

Originally Posted by drmozes (Post 5959015)

latest u-boot build with the defconfig out of the box plain fails to save the env - confirmed :thumbsdown:
managed to build a u-boot with access to the onboard NOR SPI flash

I happen to have the config stored on a ext4, the u-boot doesn't seem to support writing on it - and that seems to be due to more build options across all over the place :scratch:

my attempt to build FB_TFT failed with the likes to require full kernel rebuild (missing module symbols) (module built just fine, can't load it after depmod -a)

Stay tuned (i know i will) ...

You might want to disable the modules symbols checking in the new kernel you're building if you plan to play again with building external modules. Set the CONFIG_MODVERSIONS=n in the kernel .config file and disable the symbols checking "safety" mechanism. It'll save you a few hours of recompiling the kernel for every attempt to build an external module, in case you loose the Module.symvers file that will be generated with this new kernel build.
This safety mechanism, while providing some safety by not allowing "unsigned" modules to be loaded in the running kernel, is utterly stupid and totally broken from security PoV (you need to be root in the first place to be able to load a module), just an annoyance and I hope it'll "die" soon:
https://lwn.net/Articles/707520/