Like I did when receiving the Cosmo Communicator, I want to share the first impressions while unboxing the brand new Astro Slide, I have received yesterday. About two and a half years ago I have backed Planet Computers Astro Slide Indiegogo campaign. Again Planet Computers has promised a device that is different from anything else, that is available for purchase. The Astro Slide is a slider class device with a fully integrated keyboard and touchscreen and full phone usability that is designed for Android, but will also be capable of running Linux or Sailfish OS. No need to go through the full specs here, everything interesting regarding these can be read on Planet Computers web page. Originally Planet Computers was planning the device in March 2021, then Covid-19 appeared… Yesterday, after a long time of waiting the parcel with the Astro Slide finally arrived. When receiving the parcel I had to pay an additional 33€ import fees.
Parcel containing the Astro Slide
Inside the parcel has been a single box.
Box containing the Astro Slide
Before opening the box has to be fold out.
Fold out Astro box
After Opening the box one can see the well packed Astro in there.
Opened Astro box
The full content of the box can be seen below. One can see the Cosmo wrapped well in foil as well as an envelope containing a quick start manual and the Sim card tool. Still in the box are two smaller boxes containing the charger and the USB cable.
Astro box content
After some further unboxing we can see charger and user manual.
Astro box content
After removing the foil we can see the Astros full beauty.
The Astro Slide
From the back side we can see camera and rubber feet.
Back side of the Astro
With the opened device we can see the display and the German QWERTZ keyboard. The keyboard again feels more solid as with the Cosmo.
When opened we can see the sliding mechanism from the back. The sliding mechanism is a bit clumpsy as others described before. It will take some time to get the feel for it.
Astros sliding mechansim from the back
After completing the initial setup process the Astro shows the Android desktop.
Astro running Android
Below we can see the desktop in landscape while the keyboard is slided out and its backlit is turned on. Unfortunately the display corners are far rounder than with the Cosmo.
Slided out Astro with running Android
I am hoping you have enjoyed the photo series and some first impressions of the Cosmo. Further articles regarding testing some aspects of the device, and hopefully some solutions will follow. Stay tuned for updates.
The Resin 3D DLP printer Wanhao Duplicator 7 originally has been offered with the free slicing software Creation Workshop available for download.1 Later on Wanhao seems to have bought the software company behind Creation Workshop and have developed new version, Wanhao D7 Workshop. The original download locations for the free software vanished. Users who have bought the printer after November 2018 were able to get a free license key. Others, who bought it before or obtained a used printer, had to buy one. Fortunately a user made the binaries of the original free opensource version available for download again at dropbox.2
Creation Workshop has been developed using .Net C# and can be used with Mono with Linux. Unfortunately this version of the Software does not work with mono on Linux depending on graphics hardware. There also has been a report of Creation Workshop crashing on the Raspberry Pi.3 45 From what I can tell it works with Intel graphics boards, but crashes with NVIDIA graphics boards. When running Creation Workshop with nvidia-drivers, it shortly opens a black window and then crashes with the console output below:
X11 Error encountered:
Error: BadMatch (invalid parameter attributes)
Request: 151 (5)
Resource ID: 0x840006E
Serial: 1568
Hwnd: Hwnd, Mapped:False ClientWindow:0x840006E, WholeWindow:0x840006D, Zombie=False, Parent:[Hwnd, Mapped:True ClientWindow:0x8400064, WholeWindow:0x8400063, Zombie=False, Parent:[Hwnd, Mapped:True ClientWindow:0x8400062, WholeWindow:0x8400061, Zombie=False, Parent:[Hwnd, Mapped:True ClientWindow:0x8400060, WholeWindow:0x840005F, Zombie=False, Parent:[Hwnd, Mapped:True ClientWindow:0x840005E, WholeWindow:0x840005D, Zombie=False, Parent:[Hwnd, Mapped:True ClientWindow:0x840005C, WholeWindow:0x840005B, Zombie=False, Parent:[Hwnd, Mapped:True ClientWindow:0x840005A, WholeWindow:0x8400059, Zombie=False, Parent:[Hwnd, Mapped:True ClientWindow:0x8400058, WholeWindow:0x8400057, Zombie=False, Parent:[<null>]]]]]]]]
Control: UV_DLP_3D_Printer.GUI.Controls.ctlGL at System.Environment.get_StackTrace () [0x00000] in <a6a5ba8fc13a4797a32a4dc4ae25c772>:0
at System.Windows.Forms.XplatUIX11.HandleError (System.IntPtr display, System.Windows.Forms.XErrorEvent& error_event) [0x00000] in <f8f55e5d29ae400f8589d196b5502445>:0
at OpenTK.Platform.X11.Glx.MakeCurrent (System.IntPtr , System.IntPtr , System.IntPtr ) [0x00000] in <6e87929761c543a4bfb6d5acaea62619>:0
at OpenTK.Platform.X11.Glx.MakeCurrent (System.IntPtr display, System.IntPtr drawable, OpenTK.ContextHandle context) [0x00000] in <6e87929761c543a4bfb6d5acaea62619>:0
at OpenTK.Platform.X11.X11GLContext.MakeCurrent (OpenTK.Platform.IWindowInfo window) [0x00000] in <6e87929761c543a4bfb6d5acaea62619>:0
at OpenTK.Graphics.GraphicsContext.MakeCurrent (OpenTK.Platform.IWindowInfo window) [0x00000] in <6e87929761c543a4bfb6d5acaea62619>:0
at OpenTK.GLControl.MakeCurrent () [0x00000] in <1b9440a0f8834418a8d369f909728a32>:0
at OpenTK.GLControl.OnHandleCreated (System.EventArgs e) [0x00000] in <1b9440a0f8834418a8d369f909728a32>:0
at System.Windows.Forms.Control.WmCreate (System.Windows.Forms.Message& m) [0x00000] in <f8f55e5d29ae400f8589d196b5502445>:0
at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x00000] in <f8f55e5d29ae400f8589d196b5502445>:0
at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message& m) [0x00000] in <f8f55e5d29ae400f8589d196b5502445>:0
...
From the output there seems to be a problem with OpenTK.Graphics, which turns out to be an incompatibility of the bundled version of the OpenTK .Net wrappers libraries bundled with this version of Creation Workshop. To fix this problem one can download newer versions of the wrapper dlls, which work together with nvidia-drivers, from nuget.org.
After downloading, the dlls can be extracted from the nupk files using unzip. Then replace the the files OpenTK.dll and OpenTK.GLControl.dll in the Creation Workshop directory with the newer ones from the nuget packages.
Creation Workshop-1.0.0.75 running on Linux with NVIDIA Graphics
Afterwards Creation Workshop can simply be started from the terminal:
This way Creation Workshop has been run on Gentoo Linux on X86_64 architecture and on a NVIDIA Jetsons TX2 board with ARM64 architecture. Other platforms like the Raspberry, reported to be problematic, might work as well.
Bosch’s BME680 is a very interesting component. It is a four in one sensor, which can measure temperature, humidity, pressure and air quality. Unfortunately there is no official support for using the sensor with arm64 linux. This article shows a kernel based approach to use this sensor with NVIDIA’s arm64 based Jetson boards.
bme680 sensor breakout board which is connected to a NVIDIA Jetson TX2
Connecting the sensor First of all the sensor has to be connected to an i2c port of the Jetson board. There is no difference whether we use a TX2, Nano or Xavier board for this. The pin Layout of the Raspberry based GPIO connector (for example J12 on Xavier NX, J42 on Nano and J21 on TX2)123 is the same with all these boards. After connecting the sensor to the pins 1-9-5-3, as shown above, we can check the connection using i2detect. If we can see a device with i2c address 0x77 or 0x76 everything is connected properly.
root@jetson:/usr/src# i2cdetect -ry 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1 using receive byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n]
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- 77
Building the kernel modules During Google Sommer of Code 2018 Himanshu Jha has developed a kernel based driver for the bme680 sensor4. The kernel supplied by nvidia (4.9.140) does not support the BME680 sensor. Mainline kernel started supporting this sensor with version 4.19. Fortunately the required kernel module can also be built against the older NVIDIA supplied kernel. So we just have to get the kernel source of a kernel version supporting the sensor. This time we will use the most recent 4.19 kernel:
We just need to extract the drivers/iio/chemical subtree of the kernel source for building the bme680 sensors kernel module.
tar --strip-components=3 -xzf linux-4.19.116.tar.gz linux-4.19.116/drivers/iio/chemical
After extracting, we have to configure the build. To do so, prepend the following lines to the Makefile in this subtree:
CONFIG_BME680=m
CONFIG_BME680_I2C=m
Afterwards build the kernel module5 and install the binaries to the modules folder:
make -C /lib/modules/`uname -r`/build M=$PWD
make -C /lib/modules/`uname -r`/build M=$PWD modules_install
Once the kernel modules have been installed as shown above, we can load the the kernel module with modprobe bme680_i2c. This can be automated on startup by adding the module to /etc/modules-load.d/modules.conf.
Using the sensor via sysfs To use the sensor we have to register it with the kernels i2c subsystem6. This could be added to a startup script, for example /etc/rc.local.
Depending on sensor configuration the i2c address can be 0x76 or 0x77. Once the sensor is registered, the sensors readings can be acquired using the sysfs interface:
Unfortunately the kernel driver does not support the calibration of the sensor and just outputs the resistance value of the air quality sensor. So calculating CO2 equivalent or air quality from the sensors readings has to be done in userspace. Usually this calculation is being done using Bosch’s closed source BSEC library which cannot be used on arm64 architecture or within kernel context. A promising approach on self-calculating the air quality from the raw sensors readings has been shown in pimoronii forums7. According to this, the IAQ8 air quality index ranging from 0 to 500, can be calculated from the bme680 readings using the following formula:
iaq = log(gas_reading) + 0.04 * humidity_reading
For completeness, the bme680 device can be unregistered6 from the kernels i2c subsystem as follows:
After my last kernel upgrade I tried to build the iptables mirror target that I have published the last time here. The iptables mirror target takes the packet sent to your machine and returns the same packet to the machine the packet came from. Thus, let’s say someone tries to scan your machine or tries an attack he would scan his own machine or even attack his own machine.
When I tried it with kernel version 5.4, it did not build anymore with the current linux kernel. This time there has been a API change in kernel 5.0. Thus I had to replace the call to skb_make_writable() with a call to skb_ensure_writable. Furthermore a call to dst_neigh_output() had to be replaced by a call to neigh_output(). Also a small Makefile change has been necessary. Starting with kernel 5.4 the outdated SUBDIRS=$(PWD) argument gets ignored and M=$(PWD) has to be supplied instead. You can download the newer release for kernel version 5.4 and probably future kernels here:
The kernel module has been tested with kernel version 5.4.15-zen1. To build the module, boot the kernel you want to use the module with. Afterwards unpack the archive and run the compile.sh script to build the module. Then run the install.sh script for installing the compiled module into the /lib/modules directory for your kernel. Unfortunately the mirror target does not work with iptables version 1.6 and newer due to removal of the ipt_MIRROR extension (libipt_MIRROR.so). To use the MIRROR target one has to use iptables 1.4.21 or below.
Now you may use the mirror target in place of the REJECT or DROP target in the INPUT, FORWARD and PREROUTING chains, like this in your firewall script:
$IPTABLES -A INPUT -j MIRROR
Beware: The use of the mirror target may lead to strange results, in example if you want to connect to an iptables protected machine which uses the mirror target, you may end up connecting to the local machine without recognizing it. It also may use much bandwith. The worst case occurs if you have two machines using the module. These machines may end up playing ping pong. So you have been warned, use with caution and at your own risk. For more information see: MIRROR target.
Downloads for older kernel versions are below. Notice the version numbering 2.6.25 works for kernels up to 2.6.27. 2.6.28 also works for 2.6.29 and 2.6.30 kernels. The 2.6.13 version of the module should work up to kernel version 2.6.16.
Cosmo Communicator with exfat formatted micro sd card
Unfortunately the Cosmo Communicator, like many other Android phones, does not support the exFAT filesystem. Most vendors do so due to exFAT being covered by software patents in the USA, which is a problem for companies selling to the USA. exFAT might not be the most sophisticated filesystem available, but is needed for interoperability with other devices and to get rid of the 4GB file size limit of fat32. This article shows how to enable exFAT support for the Cosmo. Since it is not much effort to also get NTFS support this is done by the way.
Setup the kernel sources
To get exfat support, first of all we need a kernel module providing exfat support. Fortunately some time ago Samsung has released their exfat driver under the GPL license. The derivate of this driver can be found on github¹ This module has to be built against the kernel used on the device. The kernel source for the Cosmo has also been made available on github². The two source trees can be combined, as described in the documentation for the exfat module by editing the relevant Makefile an Kconfig. Furthermore CONFIG_EXFAT_FS for exFAT support CONFIG_NTFS_FS for NTFS have to be enabled as modules in kernel configuration. The resulting kernel source tree with the included exfat submodule has been placed on github.
Setup the build environment
To build the kernel modules on better uses a compiler that is as near as possible to the one that has been originally for building the kernel. We can easily find this out via procfs on the target device.
clang version used for the Cosmos kernel build
When compiling on an arm64 system the build environment can easily be installed. I.e. by executing apt install llvm clang on an Ubuntu arm64 system. When using a different architecture for compiling, the appropriate cross toolchain has to be installed.
Build the kernel modules
Once all is set up the kernel modules can be built.
make O=../KERNEL_OUT -C cosmo-linux-kernel-4.4 ARCH=arm64 k71v1_64_bsp_defconfig
make -j4 O=../KERNEL_OUT ARCH=arm64 CC=clang CLANG_TRIPLE=aarch64-linux-gnu- CROSS_COMPILE=aarch64-linux-gnu- modules
As result we get the two kernel modules ntfs.ko and exfat.ko
Creating a magisk module
The resulted kernel modules have to get loaded on Android startup. Starting with Android Pie it is not possible any more to mount the system partition for writing. One possibility would be to create an own system image containing the kernel modules and necessary scripts. Since Magisk is the recommended way for rooting the Cosmo Communicator anyways, we can take a different approach. Fortunately Magisk gives the possibility to create on overlay filesystem which gets injected into the android system partition, so we can get the same result with less effort.
To create the Magisk module containing the filesystem support we start with the Magisk Module Template4 and copy the two kernel modules to system/lib/modules/. Furthermore we need some additional binaries for filesystem checking and mounting. So we add the filesystem support binaries and volume daemon built for the Pixel 2 from fsbinaries.zip and Magisk-v18.1-extrafs.zip³. Next we need a service.sh script which loads the kernel modules on startup an restarts vold once the user is present. With an earlier restart the volumes do not get added.
#!/system/bin/sh
# load kernel modules
insmod /system/lib/modules/exfat.ko
# kernel ntfs support is ro
# comment this line to use fuse ntfs (rw)
insmod /system/lib/modules/ntfs.ko
_SLEEP_INTERVAL=2
# wait for startup
while [ "$(getprop sys.boot_completed)" != "1" ]; do
sleep ${_SLEEP_INTERVAL}
done
# wait user to unlock
while dumpsys trust | grep -c "deviceLocked=1"; do
sleep ${_SLEEP_INTERVAL}
echo "device locked"
echo $(dumpsys trust | grep -c "deviceLocked=1")
done
#kill vold to restart
killall vold
echo "vold restarted"
One can comment the line loading the ntfs module to decide whether ntfs kernel support, which is read only or fuse ntfs, which is read/write shall be used. For this a simple wrapper script replacing mount.ntfs has been added.
#!/system/bin/sh
# call mount for in kernel ntfs and mount.ntfs3g without
if cat /proc/filesystems | grep "ntfs" &> /dev/null ; then
echo "using kernel ntfs (ro)"
params=$(echo "$@" | sed 's/,shortname=mixed//')
params=$(echo "$params" | sed 's/,dirsync//')
mount $params
echo no ntfs.ko
mount.ntfs3g $@
else
echo "using fuse ntfs (rw)"
mount.ntfs3g $@
fi
Finally LATESTARTSERVICE=true has to be set config.sh to execute the service.sh script on startup and some Selinux policies have to be added to avoid the need of running in permissive mode.
The final result can be found on github. For those who do not want to perform the procedure or parts of it themselves, the installable Magisk module can be downloaded from here:
It can be installed using the Magisk Manager App. Best for all users would be if Planet Computes could include this in the stock ROM. This would give exFAT/NTFS support also for non-rooted devices. Assuming they are fearing software patents, they might consider joining the Open Invention Network to get access to the relevant Microsoft patents in the future.
Like I did when receiving the Gemini PDA, I want to share the first impressions while unboxing the brand new Cosmo Communicator, I have received today. About one year ago I have backed Planet Computers Cosmo Communicator Indiegogo campaign. Planet Computers has promised a device that is different from anything else, that is available for purchase. The Cosmo Communicator is a clamp-shell class device with a fully integrated keyboard and touchscreen and full phone usability that is designed for Android, but will also be capable of running Linux or Sailfish OS. Major improvements compared to the Gemini PDA, beside better specs, are the outside cover display and the backlit keyboard. No need to go through the full specs here, everything interesting regarding these can be read on Planet Computers web page. Yesterday, after a long time of waiting the parcel with the Cosmo finally arrived.
Parcel containing the Cosmo Communicator
Inside the parcel has been a single box
Box containing the Cosmo Communicator
Before opening the box has to be fold out.
Fold out Cosmo box
After Opening the box one can see the well packed Cosmo in there.
Opened Cosmo box
The full content of the box can be seen below. One can see the Cosmo wrapped well in foil as well as an envelope containing a quick start manual and the Sim card tool. Still in the box are two smaller boxes containing the charger and the USB cable.
Cosmo box content
After removing the foil we can see the Cosmos full beauty.
The Cosmo Communicator
With the opened device we can see the display and the German QWERTZ keyboard. Keyboard and hinge even feel more solid as with the Gemini PDA.
Opened Cosmo booting Android
After booting the Cosmo shows the initial welcome screen. With a press to the start button one could start the initial setup process.
Cosmo welcome screen
The outer cover touch display, which shows the caller id and allows to accept calls can be seen below.
Cosmo Communicators outer touchscreen showing date and time
For the Cosmo Communicator I also ordered a third party belt case which can be seen below with the Cosmo inside and a Adonit Dash2 stylus attached.
Third party belt case with the Cosmo
I am hoping you have enjoyed the photo series and some first impressions of the Cosmo. Further articles regarding testing some aspects of the device, and hopefully some solutions will follow. Stay tuned for updates.
Recently Adam Boardman and I have managed to integrate the modular kernel for the Gemini PDA into the gemian kernel repository. So, from now on, whenever the kernel gets improved, the modular kernel gets built and the update is available for Debian via apt.
Installing the modular kernel
From now on, the modular kernel for the Gemini PDA can be installed easily using apt:
sudo apt install gemian-modular-kernel
When using the new bootloader the kernel gets flashed to the boot partition automatically. This works because the new bootloader passes the current boot partition’s name to the kernel using the kernel cmdline. The cmdline can be examined with:
cat /proc/cmdline
When using the old bootloader with the Gemini PDA this information is not available to the kernel and consecutively to the operating system, thus one still has to flash the kernel image manually after installing or updating the kernel package. For this one has to carefully decide which boot partition the Linux system is being booted from. Using the wrong partition name can render other installed operating systems unbootable. To recover, flashing the wrongly overwritten boot partition using the flash tool might be necessary. When knowing the boot partition the new kernel can be flashed using dd (the X in bootX has to be replaced with the number of the boot partition) as shown below.
After flashing the kernel the either or the other way a reboot is necessary. The boot partition number can be determined from the scatter file that has been used initially to flash the Gemini. Alternatively it can be found out from the key combination that has been used to boot the Gemini. Detailed information on this can be found in the Gemini bootloader documentation.
Building out of tree modules
For building out of tree modules with the Gemini (in example for using USB devices that are not supported with the kernel), in addition to the kernel, the kernel-headers package has to be installed:
sudo apt install gemian-modular-kernel-headers
With the kernel headers and the appropriate build toolchain (gcc, etc.) additional kernel modules can be compiled on the Gemini. Instructions on how to do this can usually be found with the module source.
MyGNU.de
Loading...
![[Valid RSS]](https://validator.w3.org/feed/images/valid-rss.png "Validate my RSS feed")
