LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 02-09-2019, 05:16 PM   #16
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 2,502

Original Poster
Blog Entries: 2

Rep: Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997
Talking


Quote:
Originally Posted by abga View Post
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)
 
1 members found this post helpful.
Old 02-09-2019, 05:22 PM   #17
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930Reputation: 930
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.
 
1 members found this post helpful.
Old 02-10-2019, 04:02 AM   #18
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 2,502

Original Poster
Blog Entries: 2

Rep: Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997
Unhappy

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.
 
Old 02-10-2019, 12:47 PM   #19
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 2,502

Original Poster
Blog Entries: 2

Rep: Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997
Post

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

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

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?

Last edited by SCerovec; 02-12-2019 at 05:40 PM. Reason: found bugs in script
 
Old 02-10-2019, 03:09 PM   #20
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 2,502

Original Poster
Blog Entries: 2

Rep: Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997
Post

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

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

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
 
Old 02-12-2019, 03:49 PM   #21
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 2,502

Original Poster
Blog Entries: 2

Rep: Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997
Lightbulb

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
Attached Thumbnails
Click image for larger version

Name:	Orpi0-kernel-pin-map.jpg
Views:	36
Size:	139.7 KB
ID:	29775   Click image for larger version

Name:	Orpi0-kernel-pin-map_inverted.png
Views:	34
Size:	181.0 KB
ID:	29778  

Last edited by SCerovec; 02-13-2019 at 03:51 AM. Reason: more images
 
Old 02-12-2019, 05:42 PM   #22
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 2,502

Original Poster
Blog Entries: 2

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

it should maybe work better now
 
Old 02-13-2019, 04:21 PM   #23
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 2,502

Original Poster
Blog Entries: 2

Rep: Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997
Lightbulb 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?)
Attached Thumbnails
Click image for larger version

Name:	final pinout.png
Views:	33
Size:	203.2 KB
ID:	29787   Click image for larger version

Name:	framebuffer.png
Views:	36
Size:	2.2 KB
ID:	29792  
 
Old 02-14-2019, 01:00 PM   #24
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,647

Rep: Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358
Quote:
Originally Posted by SCerovec View Post
latest u-boot build with the defconfig out of the box plain fails to save the env - confirmed
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

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.
 
Old 02-14-2019, 07:58 PM   #25
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 2,502

Original Poster
Blog Entries: 2

Rep: Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997
Thumbs up

Quote:
Originally Posted by drmozes View Post
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.
As noted before - it seemed like a FS / disk label (partition table) issue to me

Having failed to build an operating 4.20.x kernel so far (), 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

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.
 
Old 02-15-2019, 06:03 AM   #26
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,647

Rep: Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358
Quote:
Originally Posted by SCerovec View Post
As noted before - it seemed like a FS / disk label (partition table) issue to me
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.

Last edited by drmozes; 02-15-2019 at 06:06 AM.
 
1 members found this post helpful.
Old 02-15-2019, 08:35 AM   #27
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 2,502

Original Poster
Blog Entries: 2

Rep: Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997
Talking warning: funny

Quote:
Originally Posted by drmozes View Post
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.
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." )
Quote:
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.
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:
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.
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 about a single conf line we might have missed?

omw to hunt those down...
 
Old 02-15-2019, 10:57 AM   #28
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,647

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

Moved to this thread.
 
1 members found this post helpful.
Old 02-15-2019, 11:39 AM   #29
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 2,502

Original Poster
Blog Entries: 2

Rep: Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997
Arrow

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.
 
Old 02-15-2019, 12:01 PM   #30
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 2,502

Original Poster
Blog Entries: 2

Rep: Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997
Lightbulb

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.



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
 
  


Reply

Tags
arm, gps, howto, orange pi zero


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Wireless crazed Orange Pi boasts 4G LTE, WiFi, BT, FM, and GPS LXer Syndicated Linux News 0 03-23-2018 05:10 PM
LXer: Orange Pi Zero Overview LXer Syndicated Linux News 0 04-04-2017 03:12 AM
LXer: $10 Orange Pi One pits quad-core Cortex-A7 against Pi Zero LXer Syndicated Linux News 0 01-29-2016 02:33 PM
LXer: Canonical's cloud-in-a-box: The Ubuntu Orange Box LXer Syndicated Linux News 0 05-19-2014 12:00 PM
Help With Java Problem Please"""""""""""" suemcholan Linux - Newbie 1 04-02-2008 06:02 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 09:52 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration