New from our forum – experimental NixOS image for TERES DIY OSHW Laptop

nixos.png

Recent post from our forum explains how to build experimental NixOS image for TERES-I  – Do It Yourself, Environmental friendly, modular Open Source Hardware ARM Laptop.

Writing applications for OLinuXino with GTK

GPIO

Many times I hear from customers – Linux has no good UI, it’s made for servers but we want to make apps with windows drop boxes, check boxes etc.

Recently we found Simon Long’s C GUI Programming book and made two “windows” examples for OLinuXino.

We recommend you first to download the book and read it then to look at the code we made and uploaded to GitHub.

In the README.TXT you will find step by step instructions how to install and configure GTK for OLinuXino.

Then you can try the code and modify for your need.

GPIO example allow you to read or write GPIO state to any of the GPIO connectors of OLinuXino.

I2C example will allow you to interface to any of our UEXT boards with I2C interface. The example we test with MOD-IO.

I2C

How to choose best LCD for your Linux computer? This is why we made LCD-OLinuXino selection guide

LCD10-METAL-FRAME-1

LCD-OLinuXino selection guide will help you to select best solution for your OLinuXino Linux SBC.

Inside we explain the different LCD connectors available in OLinuXino.

What LCD variants are available: 4.3″, 5″, 7″, 10.1″, 15.6″.

What signals are there when the interface is RGB or LVDS on the 40 pin connector.

How we implement plug and play capability with our latest Linux images and LCD driver boards, so you do not have to configure the LCDs, but they are recognized at boot time and all drivers configured.

What are the pro and cons and differences between resistive and capacitive touch screen technologies.

How to enable digital touch interface on A20 boards.

How to configure the software and drivers for the older LCD driver boards.

 

 

Long Term OLinuXino supply – How it works?

Screenshot from 2019-05-16 14-50-39

We got question from customer of ours: “We are using your A20-OLinuXino in our product and I’ve heard that you are going to stop the production soon, is this true?”

Most of our customers are industrial machine producers and they need long term supply from their vendors. They do certification for their machines which cost a lot and they can’t afford to spend more money every year because the Linux module is not produced or changed. We already wrote several post on our blog that we supply our boards until there is demand for them and that we have long term supply agreement with Allwinner, but some people spread rumors and I have to write it and make it clear again: We will produce OLinuXino boards until there is demand. It’s even included in our GTC.

When back in 2014 I posted that we can supply OLinuXino forever many people were skeptical (well yes it is exaggerated 🙂 ) and wrote back – do not believe Chinese suppliers, they will let you down etc. etc.

Allwinner though is keeping their promise and we can buy all Allwinner SOCs we use without problem. Our volumes allow us to meet their MOQ.

For instance A13 SOC is very old and Allwinner discontinued it several years ago, it’s even not listed on their web as product, but we still keep buying it and producing A13 boards for our customers. We have also many customers which used our boards as template to make their own variants and now we supply them with A13 SOCs so they keep manufacturing them. You will not find A13 for sale anywhere even in China, but we are expecting next lot of 90Kpcs A13 to come from Allwinner in few weeks. Yes we have to order such quantities as Allwinner need 3 month to produce the SOCs from the order to shipment.

Many customers ask can you guarantee 10-15-20 years of supply? I doubt anyone in industry can see so long ahead. Allwinner is young company, founded September 2007, i.e. less 12 years old. Who knows what they will do after 20 years? We see that Western companies with much more history change owners every year and no one knows what the new owner will decide to do, so no one can give you 10-20 years prediction or will simply intentionally or unintentionally mislead you.

For A13 and A20 this agreement works well last 7 years. Both we at Olimex and Allwinner has no reason stop production, which brings money to both of us. We got visit from Allwinner sales manager in March this year and he said that they never though they can sell A13 and A20 for so long time. Most of other SOCs they sell target consumer market where lifetime is 1-2 years top.

Linux and Open Source Hardware works well for them and prolong their sales.

Linux Users Group Bulgaria annual meeting is April 6th in Plovdiv

LUGBG_1

Linux Users Group is annual meeting of people who use and develop with Linux in Bulgaria. The LUG-BG meeting this year is on 6th of April in Plovdiv. The web page of the meeting is here.

I signed for discussion about how to make one ARM Linux system tamper proof.

This is topic which is very interesting for all our OLinuXino customers. OLinuXino is used in many industrial product and machines and the designers want to be sure that no one except them can change the Linux image as these machines pass safety approvals etc and any intervention in the code is illegal.

The Allwinner SoCs do have TrustZone support and also crypto hardware to support a secure boot path for it, but parts of the ARM TrustZone specifications is under NDA and no one has seen it. The secure boot paths are also undocumented. Last time I attempt to receive any useful information about this I got reply: A20 is 5 years old processor and we do not offer technical support for the old processors, when I asked them for info how TrustZone and Secure boot is implemented in their newer processors I didn’t got any reply. My guess is this is something licensed from ARM which they never used so can’t support.

Currently all Allwinner SOC boot without using TrustZone and Secure boot path, they has so caller BROM a small code located in SOC ROM, which initializes the memory and processor registers with some safe values then try to boot from different peripherals. If UBOOT GPIO is held low they enter FEL mode where you can type some commands and load code via USB, else they try to boot from SD-CARD, if fails then try -> internal NAND Flash if fails then try -> SD-CARD2/eMMC, if fails then try -> SPI Flash, if all fails it go in FEL mode.

This is done intentionally so you can never brick your board if internal NAND or EMMC or SPI Flash get corrupted you can always boot from SD-card or USB and replace the image. This of course is big security hole, as anyone with physical access to your board can always replace your images with his own.

The TrustZone and Secure boot path solve this issue, but no one has documentation how this is done on Allwinner SOCs.

I hope to get some interesting ideas how this could be solved, one radical approach is to remove physically the SD-card connectors 🙂

A64-OLinuXino got mainline Linux Kernel 5.0 images

Linux-Kernel-5-featured

Linux kernel 5.0 was just released and as we were working this week to the release of mainline Linux image for A64-OLinuXino (as till now it has the ugly android based 3.10 kernel) we decided to release latest kernel.

The images are available on our FTP.

There are two images Debian headless or Ubuntu desktop.

Known issues with these images:

  • LCDs are not supported yet, HDMI output is only available, we need one more week to figure out how to automatically detect if the Ethernet or LCD are enabled (there is jumper on the board which switch between LCD or Ethernet as both share pins and can’t work together). So to make the DTS configurations  automatic at boot time.
  • eMMC do not work in the fastest possible mode yet. We need some time, right now 50MB/s is the max speed to read write instead of 100-200MB/s which the installed eMMC supports, we will update the image soon with HS200/400 modes enabled.
  • No CPU thermal. A64 has 3 thermal zones – CPU, GPU0 and GPU1. The driver doesn’t support monitoring them.

How to build the images is explained here.

Mainline Linux Kernel 5.0 images for A13, A20 and A33 OLinuXino and SOMs is in progress.

Working with A20 OLinuXino or SOM GPIOs when using new Armbian based A20 universal Linux image

a20

A20 GPIO ports are 32 bit registers listed in alphabetical order PA, PB, PC, PD, PE, PF, PG, PH, PI.

In Armbian GPIO ports are numbered from 0 to 287 corresponding from PA0 to PI31.

The GPIO number is calculating using this formula:

gpioNumber = (Port Letter - 'A') * 32 + pinNumber

 

For instance GREEN STATUS LED on A20-OLinuXino-LIME2 is connected to port PH2. This will correspond to GPIO number:

('H'-'A' = 7) * 32 + 2 = 226

 

All GPIO operations in shell should be made as super user. First we have to register the gpio in the Linux Kernel with this command:

sudo echo 226 > /sys/class/gpio/export

 

to check if we did registered this gpio successfully we use ls command:

sudo ls /sys/class/gpio

 

If you did everything correctly you will see gpio226 listed.

Then you have to specify what will be this GPIO input or output. This is done with writing “in” or “out” in gpioxx direction directory. In this case we want to drive the STATUS LED so we have to make it output:

sudo echo out > /sys/class/gpio/gpio226/direction

 

Once we set the GPIO as output we can write 1 or 0 to it’s value and this will make GPIO port to supply 3.3V when 1 is written or 0V when 0 is written.

To switch the LED on we have to write 1:

sudo echo 1 > /sys/class/gpio/gpio226/value

 

Yay the green LED is now lighting. If we want to switch it off we have to write 0:

sudo echo 0 > /sys/class/gpio/gpio226/value

 

To read the GPIO state it has to be set as input first with the command:

sudo echo in > /sys/class/gpio/gpioXXX/direction

 

where XXX is GPIO port number calculated as described above. Then to read the GPIO state you use this command:

sudo cat /sys/class/gpio/gpioXXX/value

the result will be 0 if the GPIO voltage is between 0.0-1.0V and 1 if the voltage is between 2.3-3.3V. If the voltage on the GPIO is between 1.0 and 2.3V the attempt to read will return randomly value 0 or 1.

Be careful when playing with the GPIO ports, some of them are wired to important peripherials like LCD, Ethernet, USB, SATA etc and writing bad values may break the functionality or even damage the board. Test your knowledge on GPIOs which are not connected to anything is best approach.

We are prepare now new version of PyA20 Python module which will add access to GPIO, SPI, I2C, Serial resources of A20 directly from Python code to work with the new universal A20 Armbian Linux image.

EDIT 2019-01-25 14:24:

We got question how fast is the access to the GPIOs via shell. Sure it’s not fast and made just for slow processes like switching on and off relays, or polling status of buttons or sensors which do not change often their state. Running this code below:

nano toggle_led_lime2.sh

 

Enter inside the file this code:

#!/bin/bash
# the lime2 led is PH2 - 32*(8-1) + 2 = 226

echo 226 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio226/direction
while [ 1 -eq 1 ]
do
echo 1 > /sys/class/gpio/gpio226/value
echo 0 > /sys/class/gpio/gpio226/value
done

 

Save and exit, then make executable and run

chmod +x toggle_led_lime2.sh
./toggle_led_lime2.sh

 

We can see square wave with oscilloscope on PH2 with frequency between 3 and 4 kHz. i.e. pulses with high state 125-150uS and low state 125-150uS.

Shell is slow, if we write same code in C:

#include <stdio.h>
#include <fcntl.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>

#define PH2        226    // (32 * 7) + 2
#define GPIO_PATH  "/sys/class/gpio/gpio226/value"

int main() {
    int ret;
    int fd;

    fd = open(GPIO_PATH, O_RDWR);
    if (fd < 0)
        return errno;

    while(1) {
        ret = write(fd, "1", 1);
        ret = write(fd, "0", 1);
    }

    return 0;
}

 

The new code produces square wave with 2.13 us high and low state i.e. approx 235 kHz or about 50 times faster than access via shell.

Previous Older Entries