Messages

1

Zaurus - Arch Linux ARM support / Update: C1000 / Akita support

« on: June 17, 2019, 02:53:31 am »

Sure thing, can do. I will have a look tomorrow and can build the kernel with this flag enabled. Unfortunately I have no C1000 to test myself.

Happy to test. Did you document the required cross-compilation toolchain somewhere? I'd be happy to compile the kernel myself.

Have you booted the 5.0 kernel with ALARM on your C1000 ?

Yes.

It seems that the latest (old) rootfs for ALARM still worked fine for initial setup, but could you do a clean upgrade with pacman -Syu ?

Yes. See my first post for the steps it took me.
Another important change I had to make (and somehow forgot to document at first): One needs to manually create /etc/dropbear/ - otherwise dropbear will fail to accept any SSH connection requests.

(...)
You may want to try the Void port that is available too, but it may lack some packages... still WIP. You can request packages in the voidz thead for the next build if needed.

Yeah, I had a look but wanted to stay with a more common distro first as it makes troubleshooting and trying out things a little bit easier.
What would be the main benefits of using Voidz in you opinion?

2

General Discussion / Keyboards comparable to the Zaurus?

« on: June 11, 2019, 05:42:56 am »

Is there any current (clamshell) PDA out there that has a keyboard which is comparable to the Zaurus keyboards?

The main reason why I'm currently trying to resurrect my Zaurus SL-C1000 is its keyboard that allows for eyes-free two-thumb typing while on the go. That's absolutely great for taking notes during meetings, adding tasks/events, etc., without having to focus on the device.

So far, neither the Gemini PDA nor the (still upcoming) Dragonbox Pyra seem to have keyboards which are suited for my use case.

Any opinions on this topic?

3

Zaurus - Arch Linux ARM support / Update: C1000 / Akita support

« on: June 10, 2019, 07:37:28 pm »

Hmm, maybe this is the culprit:

Code: [Select]

CONFIG_GPIO_PCA953X is not set (from greguu's 5.0 kernel config)

The PCA953X driver is responsible for making the MAX7310  IO expander's GPIO pins available to the system - and spitz.c seems to try to register the GPIO pins:

Code: [Select]

#if defined(CONFIG_I2C_PXA) || defined(CONFIG_I2C_PXA_MODULE)
  static struct pca953x_platform_data akita_pca953x_pdata = {
          .gpio_base              = AKITA_IOEXP_GPIO_BASE,
  };
  
  static struct i2c_board_info spitz_i2c_devs[] = {
          {
                  .type           = "wm8750",
                  .addr           = 0x1b,
          }, {
                  .type           = "max7310",
                  .addr           = 0x18,
                  .platform_data  = &akita_pca953x_pdata,
          },
  };
@greguu : would it be possible for you to recompile the 5.0 kernel with this flag enabled?

4

Zaurus - Arch Linux ARM support / Update: C1000 / Akita support

« on: June 10, 2019, 06:38:46 pm »

Oh, I seem to have gotten something wrong:

arch/arm/mach-pxa/include/mach/spitz.h:

Code: [Select]

#define SPITZ_GPIO_BACKLIGHT_ON          (SPITZ_SCP2_GPIO_BASE + 7)

Code: [Select]

#define AKITA_GPIO_BACKLIGHT_ON          (AKITA_IOEXP_GPIO_BASE + 3)
(That's probably where GPIO207 is coming from).

So, why does the kernel think that it is running on a Spitz?

I was wrong. GPIO207 is the right one for Akita. So, the Machine ID is set correctly. However, for some reason, the IO Expander (Max7310 connected via I2C) does not show GPIO pins to the kernel.
Still stumped.

5

Zaurus - Arch Linux ARM support / Update: C1000 / Akita support

« on: June 10, 2019, 06:16:14 pm »

Thanks for your reply (and the wonderful forum)!
I dug a little bit through kernel sources.
I guess that the root cause for most problems (also battery power not being available via sysfs) is that the kernel thinks that this is a Spitz device, not an Akita.
Spitz and Akita handle many things (e.g., backlight) differently, because the Spitz devices have an additional (SCOOP) controller which they need for the internal drive.
On Spitz, the backlight GPIO seems to be attached to this controller, whereas the Akita has to handle things via another GPIO.

arch/arm/mach-pxa/include/mach/spitz.h:

Code: [Select]

#define SPITZ_GPIO_BACKLIGHT_ON          (SPITZ_SCP2_GPIO_BASE + 7)

Code: [Select]

#define AKITA_GPIO_BACKLIGHT_ON          (AKITA_IOEXP_GPIO_BASE + 3)
(That's probably where GPIO207 is coming from).

So, why does the kernel think that it is running on a Spitz? My guess is that somehow the wrong ARM machine ID is set (see http://www.simtec.co.uk/products/SWLINUX/f...ng_article.html and https://www.arm.linux.org.uk/developer/machines/).
But I haven't yet found out why the wrong machine ID is set.
The code setting the machine ID seems to be in arch/arm/boot/compressed/head-sharpsl.S
It checks whether 16 MiB of flash are available (-> Spitz), and if not: if a second SCOOP chip is available (-> Borzoi). If neither of these conditions are true, it stores the Akita Machine ID in the CPU register.

Maybe the kexecboot loader somehow changes the machine ID?

6

Zaurus - Arch Linux ARM support / Update: C1000 / Akita support

« on: June 09, 2019, 06:50:26 am »

An excerpt from dmesg showing power management errors:
[div class=\'codetop\']CODE[/div][div class=\'codemain\' style=\'height:200px;white-space:pre;overflow:auto\'][ 2106.573003] PM: noirq suspend of devices failed
[ 2106.648693] usb usb1: root hub lost power or was reset
[ 2106.915414] corgi-lcd spi2.1: failed to request GPIO207 for backlight_on
[ 2106.916743] OOM killer enabled.
[ 2106.916759] Restarting tasks ... done.
[ 2106.960863] PM: suspend exit
[ 2120.801892] sharpsl-pm sharpsl-pm: Fatal Off
[ 2120.801994] PM: suspend entry (deep)
[ 2120.802008] PM: Syncing filesystems ... done.
[ 2121.022417] Freezing user space processes ... (elapsed 0.005 seconds) done.
[ 2121.027627] OOM killer disabled.
[ 2121.027639] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 2121.029158] Suspending console(s) (use no_console_suspend to debug)
[ 2121.191199] max1111 spi2.2: spi_sync failed with -108
[ 2121.191199] max1111 spi2.2: spi_sync failed with -108
[ 2121.191199] max1111 spi2.2: spi_sync failed with -108
[ 2121.191199] max1111 spi2.2: spi_sync failed with -108
[ 2121.191199] max1111 spi2.2: spi_sync failed with -108
[ 2121.191199] sharpsl-pm sharpsl-pm: Error: AC check failed: voltage -108.
[ 2121.191199] sharpsl-pm sharpsl-pm: Offline Charger: Error occurred.
[ 2121.191199] sharpsl-pm sharpsl-pm: Charging Error!
[ 2122.028649] usb usb1: root hub lost power or was reset
[ 2122.294406] OOM killer enabled.
[ 2122.294422] Restarting tasks ...
[ 2122.295445] corgi-lcd spi2.1: failed to request GPIO207 for backlight_on
[ 2122.349729] done.
[ 2122.360647] PM: suspend exit
[ 5576.875554] export_store: invalid GPIO 207
[/div]

7

Zaurus - Arch Linux ARM support / Update: C1000 / Akita support

« on: June 09, 2019, 06:36:01 am »

Hi all,

@greguu: Thank you for your work!

I have installed ALARM on my C1000 following the installation howto yesterday. Here are some observations:

Installing the 2.6-kexecboot firmware worked like a charm.

I used the most recent rootfs and replaced the kernel with the slightly updated/fixed one provided by greguu (file date of zImage: 20.02.2018 vs. 11.02.2018)
Rootfs: https://github.com/greguu/alarm-zaurus-c3x00/releases (Attention: the release on the top is NOT the most recent one. Scroll down.)
Kernel: https://github.com/greguu/linux-4.14.18-c3x00/releases

I made the following changes to the rootfs.
All paths are absolute paths, so you need to adjust them if you are changing the rootfs on a SD card mounted on your main computer.

Create /etc/dropbear/ directory
This directory is missing in the rootfs which causes dropbear to drop any SSH connection requests.

Code: [Select]

mkdir /etc/dropbear/

Swap file instead of partition (might have drawbacks).

[div class=\'codetop\']CODE[/div][div class=\'codemain\' style=\'height:200px;white-space:pre;overflow:auto\']dd if=/dev/zero of=/swapfile bs=1024 count=400000
mkswap /swapfile
swapon /swapfile
[/div]

in /etc/sysctl.d/zaurus:

Code: [Select]

vm.swappiness=10
in /etc/fstab (i also changed rootfs type to ext3 here):

Code: [Select]

/swapfile  none  swap  sw 0  0
Upgrading Arch

The following was necessary to upgrade Arch (I used a CF network card to connect to the internet):

[div class=\'codetop\']CODE[/div][div class=\'codemain\' style=\'height:200px;white-space:pre;overflow:auto\']pacman -Syu
pacman-key --init
pacman-key --populate
pacman-key --refresh

pacman -S vim # etc...[/div]

Backlight problem
The backlight on my Akita can not be controlled by the kernel:

Code: [Select]

corgi-lcd spi2.1: failed to request GPIO207 for backlight_on
There are two gpiochips available in /sys/class/gpio/:

[div class=\'codetop\']CODE[/div][div class=\'codemain\' style=\'height:200px;white-space:pre;overflow:auto\']root: ~ $ cat /sys/class/gpio/gpiochip0/label
gpio-pxa
root: ~ $ cat /sys/class/gpio/gpiochip0/base
0
root: ~ $ cat /sys/class/gpio/gpiochip0/ngpio
121
root: ~ $ cat /sys/class/gpio/gpiochip192/label
sharp-scoop.0
root: ~ $ cat /sys/class/gpio/gpiochip192/base  
192
root: ~ $ cat /sys/class/gpio/gpiochip192/ngpio
12
[/div]

So, no GPIO 207 seems to be available. I'm not sure about the mapping.
As backlight control does not work, the backlight will not switch off on suspend.
I would appreciate any hints on how to fix this issue.

USB device/gadget mode
The Zaurus boots with USB host mode, i.e. one may attach USB devices with a OTG adapter cable.
I would have liked to activate USB device mode but did not get it to work yet.
It is possible to load the pxa27x_udc and g_ether modules. However, these do not automatically switch the USB port to device mode. IIRC, one might need to toggle some GPIO pins?

Power management
The MAX1111 ADC seems to report battery voltage / temp and charging voltage.
One can read out values via

Code: [Select]

/sys/class/hwmon/hwmon0/device/in0_input (etc.).
However, an error message appears in dmesg:

Code: [Select]

max1111 spi2.2: spi_sync failed with -108There are no files in

Code: [Select]

/sys/class/power_supply/. Thus, it is not possible to directly read battery status.

Drawing on framebuffer
I do not want to run X11. Therefore, I tried running PyQt apps directly on the framebuffer.
This works (in principle) in this way (after installing python-pyqt5):
[div class=\'codetop\']CODE[/div][div class=\'codemain\' style=\'height:200px;white-space:pre;overflow:auto\']$ export QT_QPA_PLATFORM=linuxfb
$ python demo.py -qws
[/div]

This shows my demo app directly (and fullscreen) on the display. However, text is not rendered at all, and the widgets do not receive touchscreen or keyboard input. I haven't had time to address these issues yet.

I would greatly appreciate any tips regarding the aforementioned issues.