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/)

Quote:

Originally Posted by abga (Post 5959957)

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 loos 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/

FWIW the built in help says "... if unsure say N" so, there goes (from the horse's mouth) ;)

Since its introduction, I believe it was with the kernel 3.x series, everyone enabled it (all distros), including Slackware, like they all were suffering from some form of obsessive–compulsive disorder. It's a sad development and again, a broken security model, module loading requires root and if one is already root, then there's not much you can protect anymore.

I won't try building kernels on this Zero for a while:

make -j 2 was stable with ~80% ish CPU load (according to my remote gkrellm) over the course of 6 hours on the current (4.19.20) kernel.

The make -j3 seems to pretty much saturate the CPU to 100% already?

Eventually it ended in filling up my already heavy pruned install on that tight 8GB card

Might even get rid of the swap (500mb for hibernation tests) but won't attempt any kernel builds for the while.

The furthest I'm ready to go is to build a single module in or outside the tree, or, eventually, cross compile the whole kernel on a x86 machine.

Public service announcement
I need you burn up your electricity under the excuse we're making progress :D

file: kernel-arm.SlackBuild

Code:

#!/bin/sh



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

#



image="zImage"

installpath=`pwd`"/installdir"



echo "seeking for the assumed linaro toolchain:"

####

#

# comment out this section to save on time

#

#####

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

#####

#

# up to here - if you don't change the toolchain

#

####

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`/kernel-build



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



${CC}gcc --version



echo "we are building here:"

echo ${KBUILD_OUTPUT}

# comment out next two lines to preserve the ouput across invocations

mkdir -vp ${KBUILD_OUTPUT}

rm -vrf ${KBUILD_OUTPUT}/*

#



echo "Preparing sources:"



for kcheck in $(ls -d *linux*)

do

  if [ -f $kcheck ]; then

    echo "we seem to have to decompress the kernel sources here:"

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

    STREE=`echo "$kcheck" | sed "s/.tar.*//"`

  elif [ -d $kcheck ]; then

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

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

  else

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

    echo "try from:  https://www.kernel.org/"

    echo "Good luck."

    exit 2

  fi

done

echo "Detected: ["$STREE"]"



VER=`echo ${STREE} | awk -F- '{print $2}'`"-armv7"

# don't worry about the extension - compression is auto detected

archive=`pwd`/"kernel-${VER}.tar.xz"



echo "entering source tree"

cd $STREE



our_target=""



#real loaders here:



make ARCH=arm CROSS_COMPILE=${CC} distclean



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



# this is so we can load any alternate config while not changing this file:

# ../<default> is a cood option

# just place that ".config" alongide this script

 make ARCH=arm CROSS_COMPILE=${CC} nconfig



time make -j4 ARCH=arm CROSS_COMPILE=${CC} modules



time make -j4 ARCH=arm CROSS_COMPILE=${CC} zImage



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



rm -vrf ${installpath}/*

echo "we are installing here:"

echo ${installpath}

mkdir -vp ${installpath}/boot





file=${KBUILD_OUTPUT}"/arch/arm/boot/"${image}

if [ -a $file ]; then

  echo "copying image:"

  ls -h $file

  cp $file $installpath"/boot/${image}-${VER}"

else

  echo "error, no valid output"

  exit 1

fi



sysmap=${KBUILD_OUTPUT}/"System.map"

if [ -a $sysmap ]; then

  echo "copying System map:"

  ls -h $sysmap

  cp $sysmap $installpath"/boot/System-${VER}.map"

else

  echo "something went wrong"

  exit 1

fi



kconfig=${KBUILD_OUTPUT}/".config"

if [ -a $kconfig ]; then

  echo "copying Kernel config"

  ls -h $kconfig

  cp $kconfig $installpath"/boot/config-${VER}"

else

  echo "something else went wrong"

  exit 1

fi



echo "copying modues:"



export INSTALL_MOD_PATH=$installpath



time make -s -j4 ARCH=arm CROSS_COMPILE=${CC} modules_install



echo "everything is ready for packing now:"

if rm -v $archive; then

  echo "...the stale archive"

fi



# we try make all files referenced relative to /

# further, we're  converting all files into 

# root:root on the fly while archiving:

time tar --owner=0:0 -caf $archive -C $installpath .



echo "all ready for shippiong now:"

ls -lah $archive

Disclaimer:
1. no one is willing to guarantee this script will fail every time to produce any useful kernel
2. there might be fun
3. it is absolutely impossible to claim this whole endeavor will yield zero gain in knowledge
4. it was completely written from me over quite few attempts (and failures while doing so)

But it yielded me one archive I intend to try on my opi0, and I will try to report back!

Just wanted to share this - so you can waste electricity too :hattip:

USER MANUAL
1. Congratulations, blah, blah!
2. Safety warnings, blah, blah!
3. Use a proven running kernels config and load it from the make nconfig [F6] load prompt
maybe change it to make xconfig for the more convenient file selector
4. have it run and hopefully finished well - don't change too much at a single pass and try save intermediate steps should a pass fail ("undo levels")
5. You need manually download an Linaro toolchain and a kernel source tar archive - all info will be provided by the script - run it without any fear - on your own risk ;)
6. My final footprint is around 2.8GB (!) maybe have like 4GB to spare before trying this

please feedback and is all goes well - maybe i should start a dedicated thread for this and the u-boot tools?

1. i didn't run the new kernel yet
2. i fiddled with the dts/dtb back and forth with the dtc tool and have enabled the serial ports on my opi0
3. the gps dongle connected on the serial port is registered and my time on the opi0 is from GPS :D

file:/etc/ntp.conf

Code:

#server 127.127.1.0    # local clock

#fudge  127.127.1.0 stratum 10



# GPS Serial data reference

#server 127.127.28.0

#fudge 127.127.28.0 time1 0.9999 refid GPS



server 127.127.28.0 minpoll 4 maxpoll 4 prefer

fudge 127.127.28.0 refid GPS stratum 4

fudge 127.127.28.0 time1 0.113  # coarse processing delay offset

fudge 127.127.28.0 flag1 1      # ignore difference limit



# GPS PPS reference

#server 127.127.28.1 prefer

#fudge 127.127.28.1 refid PPS



# NTP server (list one or more) to synchronize with:

#server 0.pool.ntp.org iburst

#server 1.pool.ntp.org iburst

#server 2.pool.ntp.org iburst

#server 3.pool.ntp.org iburst

statsdir /var/lib/ntp/stats

logfile /var/log/ntp

driftfile /var/lib/ntp/drift

pidfile /var/run/ntpd.pid

restrict default limited kod nomodify notrap nopeer noquery

restrict -6 default limited kod nomodify notrap nopeer noquery

"puding":

Code:

# ntpq -p

    remote          refid      st t when poll reach  delay  offset  jitter

==============================================================================

*SHM(0)          .GPS.            4 l    4  16  377    0.000  63.712  90.701

:hattip:
all that's left to do now is:
1. fiddle some more
2. make the TFT SPI screen work

why i post this:
supposedly this ntp config makes it possible to start the clock from the "cold boot"
feedback welcome

Was fiddling, couldn't find any cross reference for the GPIO pins from Orange to Raspberry
According to here one is needed.
Had to make one...

Have the attached image handy for future reference ;), the dark one might be useful as a desktop IMHO

note post 19 has had edits to the script posted (2x $check > $kcheck)

it should maybe work better now

the screen is ON!

Finally got the wiring of the tiny 1.8" panel right.

https://github.com/notro/fbtft/wiki/LCD-Modules is the home of the fbtft module we use in this project

Since we still have no orpi native frame-buffer device, our TFT maps to /dev/fb0 on this 4.19.20 kernel build.

1. check your silk screen names against the names on the commonly used on the wiki page and try make a map (attachment)

2. therefrom compare your device pins to the pins of the compatible driver (i used sainsmart18)

3. connect them to your device (Orange Pi GPIO pins do not match Raspberry Pi GPIO pins)

4. once all is mapped as shoud (photos due) you should (re)boot the device

5. make the module parameters known to the system:
file: /etc/modprobe.d/fbtft

Code:

options fbtft_device custom name=sainsmart18 gpios=dc:18,reset:2,led:19 speed=16000000 busnum=1 rotate=90

6. have it be loaded by the
file:/etc/rc.d/rc.modules.local

Code:

[snip]

/sbin/modprobe fbtft_device custom name=sainsmart18 gpios=dc:18,reset:2,led:19 speed=16000000 busnum=1 rotate=90

[snip]

(i am not sure why the parameters are needed again here)

7. let the system know you have the console ready for output
file:/etc/rc.d/rc.local

Code:

[snip]

#and route display to it:

con2fbmap 1 0

[snip]

(route console 1 to framebuffer 0)

8. have the kernel use a font best suited for your display size:
file:boot.cmd(has to be converted)

Code:

[snip]

fbcon=map:10 fbcon=font:MINI4x6 3

[snip]

(map:<1st fb#><fallback fb#>, "3" is initlevel)

9. reboot for effect to take action

postcard:

Code:

$ neofetch 

                  :::::::                      root@orpi.eth.lan 

            :::::::::::::::::::                ----------------- 

        :::::::::::::::::::::::::            OS: Slackware 14.2 arm (post 14.2 -current) armv7l 

      ::::::::cllcccccllllllll::::::          Host: Xunlong Orange Pi Zero 

    :::::::::lc              dc:::::::        Kernel: 4.19.20-armv7 

  ::::::::cl  clllccllll    oc:::::::::      Uptime: 39 mins 

  :::::::::o  lc::::::::co  oc::::::::::    Packages: 1014 (pkgtool) 

 ::::::::::o    cccclc:::::clcc::::::::::::    Shell: bash 5.0.0 

 :::::::::::lc        cclccclc:::::::::::::    Terminal: /dev/pts/1 

::::::::::::::lcclcc          lc::::::::::::  CPU: Allwinner sun8i Family (4) @ 1.008GHz 

::::::::::cclcc:::::lccclc    oc:::::::::::  Memory: 55MiB / 495MiB 

::::::::::o    l::::::::::l    lc:::::::::::

 :::::cll:o    clcllcccll    o:::::::::::                            

 :::::occ:o                  clc:::::::::::

  ::::ocl:ccslclccclclccclclc:::::::::::::

  :::oclcccccccccccccllllllllllllll:::::

    ::lcc1lcccccccccccccccccccccccco::::

      ::::::::::::::::::::::::::::::::

        ::::::::::::::::::::::::::::

          ::::::::::::::::::::::

                ::::::::::::

and the dump of the frame-buffer (ain't that fresh?) :D

Quote:

Originally Posted by SCerovec (Post 5959935)

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) ...

Whilst looking at the Banana Pi thread, I decided to upgrade to the latest u-boot binary Debian are providing (which is the one I provide).
It worked but also couldn't save the environment. I wonder if this is why:
http://u-boot.10912.n7.nabble.com/Un...-td351182.html

It might be a case of simply making a FAT partition on the 'sd card' image.
Provision was added for making two partitions for something I was hacking on ages ago, but I never finished it.

ftp://ftp.arm.slackware.com/slackwar...y_imagefile.sh

Are you able to have a hack on it?
I'm not concerned with updating the u-boot for the Banana Pi A20 though, since the version from 2016 works just fine for me; but it might help the H3 issue here.

Quote:

Originally Posted by drmozes (Post 5962057)

As noted before - it seemed like a FS / disk label (partition table) issue to me :scratch:

Having failed to build an operating 4.20.x kernel so far (:hattip:), i might as well go for the u-boot and try perfect the partition support:

1. get FAT "out of the box" as a last resort option
2. get ext4 too, so we don't have to resort to "last resort" and waste 100MB for no good reason (better have if for swap IMO)
3. do we really benefit of saveenv this much more than from boot.cfg? I personally really seldom touch the u-boot if ever (once i have the sequence the way i see fit) and only ever tweak the boot.cfg (with a tool i will publish here), but agreed it's just silly not to be working none the less...
4. especially i tweak the dtb with yet another wrapper i made as well. Just my :twocents:

will report back (stay tuned...)

current status:
a. struggling the final stretch to scale the GTK widgets on tangoGPS since i don't have the 640x400 frame buffer i had on my Raspberry PI when i last time did this
b. gather all the little and immaculate tools and scripts that Slackware does not ship, but which make this sort of stuff possible at all.

Quote:

Originally Posted by SCerovec (Post 5962215)

As noted before - it seemed like a FS / disk label (partition table) issue to me :scratch:

I'm finishing off making a 2-partition image, 1 x FAT and 1 x ext4, as I intended to do this ages ago.
It also means that if someone wants to configure u-boot, they can do so by editing the config on the FAT partition.

My thinking is along the lines you said, but I think it's not a disk label - it's whether the FAT partition is marked as bootable). Without reading any of the u-boot docs, I am thinking that 'saveenv' attempts to write the config to the (1st) FAT partition (which also needs to be marked as bootable), rather than wherever it previously wrote those settings to.
The previous SD card images had no partitions, so that may be the problem.
If it still doesn't work, I'll put out these new format SD images with the 2016 version of U-Boot.

I probably could just read the docs, but where's the fun in that? :-)

Quote:

2. get ext4 too, so we don't have to resort to "last resort" and waste 100MB for no good reason (better have if for swap IMO)

This is also one of the reasons I'm not particularly interested in accommodating such arrangements. Using an SD card for a running OS will burn your SD card out quickly. I know because I did it when I was building Slackware on the Sheevaplugs. If you want the OS running off an SD card, you'd need to tune the default Slackware installation to stop writing logs and all that sort of stuff. In which case, if you're already along that path, typically you're rolling more of your own stuff anyway and so our paths diverge.

Quote:

3. do we really benefit of saveenv

Yes because it allows you to configure from the boot loader. When you're playing with the boot loader configuration, you need to keep editing, saving and rebooting into your changes. If you cannot save changes directly from u-boot, you need to boot into Linux each time, mount the device, load an editor, save it, reboot back to U-boot. That's a huge time sink.

Quote:

Originally Posted by drmozes (Post 5962344)

do i smell a Mac user here? ;)

Quote:

My thinking is along the lines you said, but I think it's not a disk label - it's whether the FAT partition is marked as bootable). Without reading any of the u-boot docs, I am thinking that 'saveenv' attempts to write the config to the (1st) FAT partition (which also needs to be marked as bootable), rather than wherever it previously wrote those settings to.
The previous SD card images had no partitions, so that may be the problem.
If it still doesn't work, I'll put out these new format SD images with the 2016 version of U-Boot.

I probably could just read the docs, but where's the fun in that? :-)

For a FAT write (er ext4 write) to fail there can be only following checks:
1. MMC access (low level) but since we're loaded from said MMC device this has to be working already
1. Partition table (GPT or DOS only viable) - "where are my partitions"
2. FAT or inode table lookup for the file (code as old as the hills) "where do i put the bytes to"
3. inode/file allocation (overwrite) "how do i connect the bytes i wrote to a file"
I can't see any of those fail and why?

What does the Build your own latest kernel documentation say? ;)
(there is a saying: "If the documentation is right the software has to be obsolete." :study:)

Quote:

Maybe an big fat warning about "We're here to get You rolling only!" is in order?
And a link of where to start hacking on...
Someone might get the impression ("supported devices") that Slackware is endorsing heavy loads for the vanilla install?

Quote:

we seem to have come to following boot edits:
1. offline (FAT is a benefit there)
2. off boot (save env has to work)
3. online (from the running system)
the more we make to work - the merrier, and less likely some ex_soviet_state hacker comes and rubs our noses :o about a single conf line we might have missed?

omw to hunt those down...

I realised that the original topic of this thread has been taken over by u-boot.

Moved to this thread.

Update to the GPS project:

file: ~/bin/center

Code:

#!/bin/sh



# make full screen

#wmctrl -r tangoGPS -b add,fullscreen



#bring to workspace, exact position and size

wmctrl -r tangoGPS -e 0,-55,0,241,138

emphasis on wmctrl a tool that makes virtual mouse clicks and WM operations for the process spawned within the X session.

this file takes care to center the application of interest - namely some buttons obscured the view and i really only want it to show the map in the middle of the window.

i moved the window 55 pixels to the right (to hide buttons) and grew it 241x138 to hide the status line and the zoom control slider as well.

wmctrl is available thru sbotools and is maintained on Slack Builds org.

next update: the auto-login process:
many a word has been shed for this, but lets try keep it short (and civil) ;)

file: main.c

Code:

#include <unistd.h>



int main()

{

  execlp( "login", "login", "-f", "<put your username here>", 0);

}

command:

Code:

$ gcc main.c -o autologin

I copied the autologin binary to /usr/local/bin on my system.

I call this binary as the last command in /etc/rc.d/rc.local and it triggers my ~/.bash_profile:

file: .bash_profile

Code:

#!/bin/bash



# echo pathing up:

PATH="~/bin:"$PATH

export PATH



# echo $PATH



echo "Starting X server as this user:"

startx

alternative file:

Code:

#!/bin/bash

echo additional configuration



echo aliasing:

alias ls="ls --color"

alias mc="mc -S gotar"

alias mcedit="mcedit -S gotar"

alias xterm="xterm -rv -sb -rightbar"



PS1="[\u@\h:\w (\$(lsbytesum) Mb)]\$ "



# echo pathing up:

PATH="~/bin:"$PATH

export PATH



# echo $PATH

case $(setterm -blank) in

0)

  echo no blank terminal detected

  ;;

*)

  echo blanked terminal detected

  setterm -blank poke

  ;;

esac



echo "Starting X server as this user:"

startx

So we are slowly cascading towards a x start ;)

file: .xinitrc

Code:

#!/bin/sh

# $XConsortium: xinitrc.cpp,v 1.4 91/08/22 11:41:34 rws Exp $



userresources=$HOME/.Xresources

usermodmap=$HOME/.Xmodmap

sysresources=/etc/X11/xinit/.Xresources

sysmodmap=/etc/X11/xinit/.Xmodmap



# merge in defaults and keymaps



if [ -f $sysresources ]; then

    xrdb -merge $sysresources

fi



if [ -f $sysmodmap ]; then

    xmodmap $sysmodmap

fi



if [ -f $userresources ]; then

    xrdb -merge $userresources

fi



if [ -f $usermodmap ]; then

    xmodmap $usermodmap

fi



# Start the window manager:

#if [ -z "$DESKTOP_SESSION" -a -x /usr/bin/ck-launch-session ]; then

#  exec ck-launch-session /usr/bin/startblackbox

#else

#  exec /usr/bin/startblackbox

#fi



# do away with undue mouse pointers:

/usr/bin/unclutter --timeout 5 --exclude-root --ignore-scrolling --fork



#perpetual run

loopd tangogps X &



#perpetual center

loopd /home/cest/bin/center tangogps &



exec blackbox

the riddle is sloved in the next file:

/usr/local/bin/loopd

Code:

# ISC cest73@ya.ru 

# maintain a process running alongside another one



Maintain=$1

Expect=${2:-init}



waste () {

  for (( n= 0 ; n < 5 ; n++ )) {

    sleep 2

    echo -ne "."

  }

}



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

 echo "Usage $ loopd {maintain} [expect]"

 exit 1

fi



echo -ne "Checking for ${Expect}\n"

until pgrep ${Expect} 1> /dev/null ; do

  echo -ne "\r            \rWaiting"

  waste

done



while true; do

  ${Maintain}

  echo -ne "\r                    \rExited, pausing"

  waste

done



echo "Done"

all that is left to do is to install the unclutter via sboinstall unclutter.

:hattip:

more yet details will follow, stay tuned
P.S.
I found the tip for #include on the edge of going insane so the simple program actually builds again as it did back then :D