Orange Pi PC: fix ttyS3 serial

image: https://circuitpython.org/blinka/orange_pi_pc/

Recently I was working with Orange Pi PC and getting a lot of problems trying to read the serial information from uart3. I generated my image with debos, creating an image base with only the basic folders to build the Operating System.

Trying to find where was the problem I generate an Armbian image also with the basic system, based on a suggestion from an issue that I opened on Armbian Forum https://forum.armbian.com/topic/26181-armbianenvtxt-should-be-loaded-when-booted/. The system was build correctly getting all information from uart3, so the question was where the system was doing all definitions and where I supposed to change that. 

In this post I will present a solution for treat ttyS3 fails on Orange Pi PC when using debos to create an image.

What is debos and why to use it?

Raspberry Pi, Orange Pi and all "fruit family" receive a sd-card that contains files and information to boot your system, the image. You can use an image provided by Armbian, Raspbian and others, that are already ready to be added to your sd-card and later to your Single Board Computer. The point is that with those images you'll not be allowed to make some changes or build your system with specific things like only the necessary packages, for example, that could save memory.

Customize an Operation System is very useful when you need of specific aspects and tools. Nowadays you can use Yocto, for example, that is a great example of how to build all the layers of your image. To this case debos was used.

Debos is a tool to create an image based on Debian OS. All definitions are made by an yaml file that contains a lot of actions that are defined by debos. You can check here an example from debos repository of a simple and basic yaml for build an image: https://github.com/go-debos/debos/blob/main/tests/debian/test.yaml.

The problem

On the project that I was working on, I supposed to generate two images for different boards: Raspberry Pi and Orange Pi, both containing the same files and packages. Those ones have different systems and also boot in a different way. Working with Raspberry Pi the serial used was serial0, and for Orange Pi ttyS3. Everything worked fine on Raspberry Pi, but not for Orange Pi PC.

Some changes were made trying to resolve this, for example:

• Reboot image, of course;
• Try others versions of Debian OS;
• Use picocom to check the connection;
• Invastigate ttyS3 on dmesg;
• Add armbianEnv file.

Those are only some of all changes that were made, and at the end the conclusion was that something was not defining this correctly, so the guess was: let's search something on boot files.

Solution

A great point about Open Source Projects is that everyone share issues and bugs about some problems, and here was not different. Somebody had the same problem (looking at mail lists about this topic) and give a tip about what could be, and with some other changes it works! Two files received changes:

• extlinux.conf
• armbianEnv.txt

On the previous extlinux.conf file we had the following lines:

linux /boot/vmlinuz-5.15.89-sunxi
initrd /boot/initrd.img-5.15.89-sunxi
fdtdir /usr/lib/linux-image-5.15.89-sunxi/

The change was comment one of then and add to other lines to configure uart3:

linux /boot/vmlinuz-5.15.89-sunxi
initrd /boot/initrd.img-5.15.89-sunxi
#fdtdir /usr/lib/linux-image-5.15.89-sunxi/
fdt /boot/dtb-5.15.89-sunxi/sun8i-h3-orangepi-pc.dtb
fdtoverlays /boot/dtb-5.15.89-sunxi/overlay/sun8i-h3-uart3.dtbo

Besides that, was also added armbianEnv.txt file to /boot, that's because this file was searched during boot. I didn't find yet the right reason for this to happen, but what I know is that the image was using some Armbian mirrors, that were looking specific for this file. The armbianEnv.txt file: 

verbosity=1
bootlogo=false
console=both
disp_mode=1920x1080p60
overlay_prefix=sun8i-h3
rootfstype=ext4
overlays=uart3

To do

After a long time struggling with this problem was great to find a solution! Of course that if you paid attention you noticed that add those lines on extlinux.conf file is not the ideal, especially keeping the sunxi version (5.15.89) static. An idea to upgrade this code is to create an script on boot that read the answer of the uname -a  command and get the correct sunxi version. 

I don't know if keeping it static like this will generate some problem with others sunxi versions. For now it is working, so I'll just let this problem for the future me.