OESF Portal | OESF Forum | OESF Wiki | LinuxPDA | #planetgemini chat on matrix.org | #gemini-pda chat on Freenode | #zaurus and #alarmz chat on Freenode | ELSI (coming soon) | Ibiblio

IPB

Welcome Guest ( Log In | Register )

> Update: C1000 / Akita support, Experimental Support for C1000 / Akita
greguu
post May 26 2017, 11:40 PM
Post #1





Group: Moderators
Posts: 360
Joined: 14-November 05
From: New Zealand
Member No.: 8,535



Hi,

as you may know, current 3.10.y and previous 3.x kexecboot kernels fail to boot on C1000 / Akita.

There is a workaround to boot the latest 4.12-rc1 kernel on Akita by using a 2.6.26 based kexecboot kernel that supports kexecboot 0.6.

If you are an C1000/Akita owner and would like to try ArchLinux ARM on your Zaurus, please follow the below steps:

- Prepare a SD card with the latest C3x00 rootfs (yes, it will work on C1000 once you change your kexecboot kernel)
- For more information see : https://www.oesf.org/forum/index.php?showtopic=34421
- Install Guide : https://github.com/greguu/ZALARM-install (Note: This guide needs updating, please share your experience and ask in this thread for help if needed)
- Make sure you format your SD card with ext3!

- Flash the 2.6.26 based "frankenstein" kexecboot kernel. (Experimental release)
- See the linux-2.6.26-c1000-frankenstein.tar.gz attached.
- This kernel does allow booting to ext2/3 only. There is NO support for ext4 or F2FS. If you like to use a ext4 or F2FS for root, you need to create a seperate ext3 /boot parition
- This kernel features kexecboot 0.6 and does recognize the recent boot.cfg format.

- Enter the SD card and boot into Arch Linux ARM.
- Note: There may be unforeseen issues with C1000 / Akita. This is an experimental test release.
- Please advise of any issues in this thread. We need some Akita testers !


Hopefully we can get an unified kexecboot kernel for all Cxx00 series Zaurus soon. In the meantime this is the only workaround for C1000 users.

Cheers!

This post has been edited by greguu: Jun 8 2017, 11:12 PM
Attached File(s)
Attached File  linux_2.6.26_c1000_frankenstein.tar.gz ( 1.06MB ) Number of downloads: 154
 
Go to the top of the page
 
+Quote Post
 
Start new topic
Replies
raphman
post Jun 9 2019, 02:36 AM
Post #2





Group: Members
Posts: 7
Joined: 15-October 17
Member No.: 811,808



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
mkdir /etc/dropbear/


Swap file instead of partition (might have drawbacks).

CODE
dd if=/dev/zero of=/swapfile bs=1024 count=400000
mkswap /swapfile
swapon /swapfile


in /etc/sysctl.d/zaurus:
CODE
vm.swappiness=10


in /etc/fstab (i also changed rootfs type to ext3 here):
CODE
/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):

CODE
pacman -Syu
pacman-key --init
pacman-key --populate
pacman-key --refresh

pacman -S vim # etc...


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

CODE
corgi-lcd spi2.1: failed to request GPIO207 for backlight_on


There are two gpiochips available in /sys/class/gpio/:

CODE
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


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
/sys/class/hwmon/hwmon0/device/in0_input
(etc.).
However, an error message appears in dmesg:
CODE
max1111 spi2.2: spi_sync failed with -108

There are no files in
CODE
/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):
CODE
$ export QT_QPA_PLATFORM=linuxfb
$ python demo.py -qws


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.
Go to the top of the page
 
+Quote Post
Varti
post Jun 10 2019, 05:16 AM
Post #3





Group: Admin
Posts: 914
Joined: 30-April 08
From: Italy
Member No.: 21,713



QUOTE(raphman @ Jun 9 2019, 12:36 PM) *
Backlight problem
The backlight on my Akita can not be controlled by the kernel:

CODE
corgi-lcd spi2.1: failed to request GPIO207 for backlight_on


There are two gpiochips available in /sys/class/gpio/:

CODE
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


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.

Hi,

I can confirm that backlight control doesn't work on my Akita, too, and it seems only these models are affected.
@greguu: I might find some free time during these days to help debugging this issue with the serial Zaurus cable I have.

Varti
Go to the top of the page
 
+Quote Post
raphman
post Jun 10 2019, 02:16 PM
Post #4





Group: Members
Posts: 7
Joined: 15-October 17
Member No.: 811,808



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
#define SPITZ_GPIO_BACKLIGHT_ON          (SPITZ_SCP2_GPIO_BASE + 7)

CODE
#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?
Go to the top of the page
 
+Quote Post
raphman
post Jun 10 2019, 02:38 PM
Post #5





Group: Members
Posts: 7
Joined: 15-October 17
Member No.: 811,808



Oh, I seem to have gotten something wrong:

QUOTE(raphman @ Jun 11 2019, 12:16 AM) *
arch/arm/mach-pxa/include/mach/spitz.h:
CODE
#define SPITZ_GPIO_BACKLIGHT_ON          (SPITZ_SCP2_GPIO_BASE + 7)

CODE
#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.
Go to the top of the page
 
+Quote Post
raphman
post Jun 10 2019, 03:37 PM
Post #6





Group: Members
Posts: 7
Joined: 15-October 17
Member No.: 811,808



Hmm, maybe this is the culprit:

CODE
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
#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?
Go to the top of the page
 
+Quote Post
greguu
post Jun 16 2019, 10:22 PM
Post #7





Group: Moderators
Posts: 360
Joined: 14-November 05
From: New Zealand
Member No.: 8,535



QUOTE(raphman @ Jun 11 2019, 11:37 AM) *
@greguu : would it be possible for you to recompile the 5.0 kernel with this flag enabled?


Hi raphman,
Sure thing, can do. See kernel attached. Unfortunately I have no C1000 to test myself.

This flag is actually part of the akita defconfig and I must have missed it some time ago..

Nice to see some usage of the 5.0 kernel and the old rootfs.
Battery status could be read via apm tools in the distant past, but I have not looked into it since then.
Last time I used framebuffer with QT amd GTK was via DirectFB. This worked surprisingly well but the project is abandoned for several years now.

Cheers!


This post has been edited by greguu: Jun 16 2019, 11:02 PM
Attached File(s)
Attached File  akita_kernel_5.0_test.tar.gz ( 13.14MB ) Number of downloads: 7
 
Go to the top of the page
 
+Quote Post
raphman
post Jun 16 2019, 10:53 PM
Post #8





Group: Members
Posts: 7
Joined: 15-October 17
Member No.: 811,808



QUOTE(greguu @ Jun 17 2019, 08:22 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.

QUOTE(greguu @ Jun 17 2019, 08:22 AM) *
Have you booted the 5.0 kernel with ALARM on your C1000 ?


Yes.

QUOTE(greguu @ Jun 17 2019, 08:22 AM) *
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.

QUOTE(greguu @ Jun 17 2019, 08:22 AM) *
(...)
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?
Go to the top of the page
 
+Quote Post
greguu
post Jun 16 2019, 11:07 PM
Post #9





Group: Moderators
Posts: 360
Joined: 14-November 05
From: New Zealand
Member No.: 8,535



I updated the previous post in the meantime and added the kernel for testing.

I use the xbps-src tool from void linux nowadays to build the kernel. All required is on my github.

Voidz is more lightweight, uses less memory. Downside is packages are not prebuild as with ALARM.
Go to the top of the page
 
+Quote Post

Posts in this topic
greguu   Update: C1000 / Akita support   May 26 2017, 11:40 PM
Varti   I have done some tests in the past days on my Akit...   Jun 8 2017, 01:22 AM
Varti   I have found the culprit, I have modified the root...   Jun 8 2017, 04:59 PM
greguu   QUOTE(Varti @ Jun 9 2017, 01:59 AM) I hav...   Jun 8 2017, 10:57 PM
Varti   QUOTE(greguu @ Jun 9 2017, 08:57 AM) well...   Jun 8 2017, 11:36 PM
Varti   Hi, I have modified the fstab entry as you sugges...   Jun 12 2017, 04:42 AM
greguu   QUOTE(Varti @ Jun 12 2017, 01:42 PM) Hi, ...   Jul 26 2017, 10:18 PM
Varti   QUOTE(greguu @ Jul 27 2017, 08:18 AM) Apa...   Jul 28 2017, 12:46 AM
slaanesh   I also have an SL-C1000 and would be interested in...   Jul 27 2017, 04:12 PM
slaanesh   Okay I have installed ALARM on both an SL-C1000 an...   Aug 13 2017, 03:49 AM
Varti   QUOTE(slaanesh @ Aug 13 2017, 01:49 PM) I...   Aug 13 2017, 10:47 AM
slaanesh   QUOTE(Varti @ Aug 14 2017, 04:47 AM) QUOT...   Aug 13 2017, 01:09 PM
greguu   I need to check, I have not used USB Ethernet driv...   Aug 14 2017, 10:31 PM
slaanesh   Just found a problem on the SL-C1000: Some of cap...   Aug 13 2017, 06:33 PM
greguu   I noticed that too, I think this was introduced in...   Aug 14 2017, 10:26 PM
slaanesh   QUOTE(greguu @ Aug 15 2017, 04:26 PM) I n...   Aug 15 2017, 02:02 AM
greguu   QUOTE(slaanesh @ Aug 15 2017, 11:02 AM) Q...   Aug 15 2017, 10:23 PM
slaanesh   QUOTE(greguu @ Aug 16 2017, 04:23 PM) Tha...   Aug 16 2017, 09:06 PM
greguu   QUOTE(slaanesh @ Aug 17 2017, 06:06 AM) Q...   Aug 17 2017, 08:55 PM
slaanesh   Seems that guide is old as some of the directories...   Aug 18 2017, 03:25 AM
greguu   QUOTE(slaanesh @ Aug 18 2017, 12:25 PM) S...   Aug 28 2017, 09:25 PM
raphman   Hi all, @greguu: Thank you for your work! I...   Jun 9 2019, 02:36 AM
raphman   An excerpt from dmesg showing power management err...   Jun 9 2019, 02:50 AM
Varti   QUOTE(raphman @ Jun 9 2019, 12:36 PM) Bac...   Jun 10 2019, 05:16 AM
raphman   Thanks for your reply (and the wonderful forum)...   Jun 10 2019, 02:16 PM
raphman   Oh, I seem to have gotten something wrong: QUOTE(...   Jun 10 2019, 02:38 PM
raphman   Hmm, maybe this is the culprit: CODECONFIG_GPIO_P...   Jun 10 2019, 03:37 PM
Varti   Nice detective work, and thanks for your kind word...   Jun 11 2019, 01:00 AM
greguu   QUOTE(raphman @ Jun 11 2019, 11:37 AM) @g...   Jun 16 2019, 10:22 PM
raphman   QUOTE(greguu @ Jun 17 2019, 08:22 AM) Sur...   Jun 16 2019, 10:53 PM
greguu   I updated the previous post in the meantime and ad...   Jun 16 2019, 11:07 PM


Reply to this topicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd September 2019 - 05:58 AM