Slackware inside Pandora.


Thanks for you answers.
The Pandora OS kernel shows the boot process in CLI mode, i.e. what we read in dmesg. How to restore that ?

About the random suspends, this is what I read from dmesg:
PM: suspend entry (deep)
Nothing particular seems to trigger this in 15.0.
I suppose I can fix that with a kernel parameter ? Or in udev or elogind ?
 
I was able to fix the random suspend issue by using this tutorial:

First part is for /etc/elogind/logind.conf .

Code:
stopping elogind from doing crazy things

how to stop elogind on slackware from doing things like automagick shutdowns or suspend.

i have an immense dislike of automatic things trying to be clever. elogind, while a noble cause,
is the former child of systemd and thus is totally broken if you don't follow it's way of doing things.

one thing it does are automatic actions on low battery. i don't want my device to power down if i only have 5% battery left.
I can do that myself, thanks. unfortunately, being the spawn of systemd, it's nearly unconfigurable.
You might tune some knobs, but disabling this behavior completely isn't supported without things that are, quoting the manpage,

    [...] for local use only and should be considered hacks.

thanks, i hate it!

so, here's how to hopefully disable the shitty behaviors of elogind:

    set these settings in the config:
[Login]
HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore IdleAction=ignore

[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no
AllowPowerOffInterrupts=yes
AllowSuspendInterrupts=yes

    AllowPowerOffInterrupts=yes and AllowSuspendInterrupts=yes enables canceling of shutdown and suspend by placing a hook script into /etc/elogind/system-shutdown/.
We just add a script which always fails. note that "fail" is something different in systemd-land, the exit-status is ignored. the scripts seem to have to print magic words (from loginctl(1)):

    Whether the executables in these directories run successfully or not is of no concern to elogind. If you want the scripts to cause the action to be cancelled if one fails,
you can set "AllowPowerOffInterrupts" and/or "AllowSuspendInterrupts" to "yes" in /etc/elogind/logind.conf.
For this to work the executables in question must print an error message to "STDOUT" that begins with either of these keywords: "CANCELLED", "CRITICAL", "ERROR" or "FAILED".
If you want any of these words in a message without causing the action to be cancelled, just re-arrange the sentence in question so that the keyword is not the first word.

.. systemd folks are twisted if you'd ask me. but nobody does, so we are left with this mess!11

so this script should be fine:

#!/bin/sh
echo "CANCELLED"
echo "CRITICAL"
echo "ERROR"
echo "FAILED"
exit 255

place it into /etc/elogind/system-shutdown/fail and make it executable. as we have disabled suspend in the config, that should be enough to disable the shenanigans elogind does.

all it would have taken is a config switch.
 
The Pandora OS kernel shows the boot process in CLI mode, i.e. what we read in dmesg. How to restore that ?
Ah, I see what you want to achieve...
The standard kernel command line sends the boot process to the serial console (/dev/ttyO2 = UART2) and not to the screen.
Try to change in boot.txt
Code:
setenv console "ttyO2,115200n8"
to
Code:
setenv console "tty7"
(and build a new boot.scr using mkimage).
I am not sure if there is a syntax to have both. And if this only works with Debian this way. So you may have to change.
In total it needs to specify a /dev/tty* that prints text characters to the framebuffer (/dev/fb0).
 
Last edited:
Ok thanks, I'll try that.

Today, I was able to launch Xfce4 with a basic fbdev setup, touchscreen works.

About the speed problem, looks like it's not related to the SD bandwidth as a dd 1M test went up to 18MB/s.
Is there any heavy debug stuff compiled in Letux ?
 
  • Like
Reactions: hns
Yay, modifying this autoboot.txt line was sufficient to get back the boot screen. I guess that serial is still enabled.
Code:
setenv bootargs "console=${console} console="tty1" ubi.mtd=${nand} root=${mmcroot} rootfstype=${mmcrootfstype} ro"

Could be more clean with a console=${console2} parameter... Not now !
 
I'm doing more advanced stuff now. It's incredibly slow, like almost unusable.
Is there a way to debug that ? This is very erratic, I can't pinpoint anything (e.g. "adduser" can take ages).
 
Last edited:
Got something (endless adduser), looks like sometimes I have to wait for:
"omap2_i2c ... controller timed out waiting for start condition to finish"
"pandora_nub ... read failed with -110"
"omap2_i2c ... controller timed out waiting on XUDF bit"

After that I get hand on the system again.
 
Last edited:
I'm doing more advanced stuff now. It's incredibly slow, like almost unusable.
Is there a way to debug that ? This is very erratic, I can't pinpoint anything (e.g. "adduser" can take ages).
Maybe, run the "top" command, it tells which processes eat up processor power (or memory?).
And yes, SD bandwidth with dd should be around 20 MB/s.
Post automatically merged:

Got something, looks like sometimes I have to wait for:
"omap2_i2c ... controller timed out waiting for start condition to finish"
"pandora_nub ... read failed with -110"
"omap2_i2c ... controller timed out waiting on XUDF bit"

After that I get hand again.
This is something I have seen as well, but only on the Pandora and no other OMAP device. It is not clear what the reason for this is. Either some I2C bus is not managed properly, or some I2C device isn't. Especially as the NUB driver is involved which isn't working for me as well.
If I find time (in 2 months :) I can have another look into that. Maybe it got broken by some upstream Linux kernel patch and if I find a good and a bad version it can be bisected. We had a similar issue with the GTA04 where the BMG160 sensor was broken. And it turned out that someone thought about an improvement of the i2c driver "for a situation that can not happen", which did make the sensor chip get into a hickup... [https://lkml.rescloud.iu.edu/2502.3/10142.html]
 
Last edited:
I tested the big development version of my Slackware 15.0 image, left nub is working under Xfce4, I can use it as a mouse.
No click unfortunately.
What's very strange is that under Zaxxon (Pandora OS) kernel, it's been a long time that I can't go in the top right direction, one day I even desoldered the nub to clean it up without success.
Now I can more or less move this way...
I guess it should work for you too if you wait long enough (maybe in conjunction with waiting before launching X, can't tell as my CLI adduser command took a long time to succeed and I left my OP apart).
 
Back
Top