Orange Pi Zero 2W at first glance

Orangi Pi has recently introduced the Orangi Pi Zero 2W single-board computers. There are a couple of variants, with changing amount of RAM, maxing at 4 GB. The CPU is a 4 core Allwinner H618 Cortex-A53. The main board houses CPU, some system chips, antenna connector, micro-SD socket and 16 MB flash. There is also mini-HDMI socket as well as 2 USB-C sockets, one for power in and one for general peripherals. There is also handy 2 x 20 pin hole grid in the main board, and thank heavens they have not soldered the provided pin header in because it would actually more than double the height of the construction. They played this very smart. This does not happen often in electronics industry.

One side of the main board has a flat cable connection possibility to external daughter card housing IR receiver, RJ45 Ethernet, some buttons, 2 regular USB ports and audio jack. The board is incredibly thin. Everything in this design hints it will be a killer app for so-called “smart” TVs.

We took a short exploration tour of the product tour with the vendor-provided Debian Linux  (Note: Daughter card was NOT connected nor tested.) Read more below.

Continue reading “Orange Pi Zero 2W at first glance”

Forcing VMware virtual machines to appear 32-bit on 64-bit hosts

There are sometimes needs to run 32-bit VMware guest images on a 64-bit host. This is possible, for example in VMware Workstation 15 Player. The out-of-the-box behavior, however, is that the Player passes trough the CPU information more or less as such. The result is that the guest sees a x86_64 processor, not a x86 processor. Frequently this detection is made by reading the CPUID 29th feature bit for so-called “long mode” (see: ). As this is seen by the guest, it might think it needs to run 64-bit image (Player does not force this, it is a decision of the image itself). The long mode bit seen from Linux /proc/cpuinfo :

Continue reading “Forcing VMware virtual machines to appear 32-bit on 64-bit hosts”

Portable Position-Independent Code (PIC) bootloader and firmware for ARM Cortex-M0 and Cortex-M4

Disclaimer 2024-05-07

Although PIC was a very interesting trek in the deep embedded territory, I’m not that confident about the benefits as of today, 2024-05-07. See the comment below from “manne”.  He discovered that even though some aspects of my solution works, it is basically unusable in the comprehensive scale. Therefore, for the time being, I am discouraging people from using PIC in real-world applications, and only exploring the subject for academic interest. I will write later more in-depth analysis of shortcomings and will also propose some compiler changes to tackle the main issue and also some some generic PIC optimizations.

Rest of the text is kept for posterity.

How to implement Position-Independent Code for microcontroller (MCUs) is a question which has been asked countless and countless of times all over the Internet. The answers and “solutions” are usually whippersnappering comments dropping a couple of key terms they probably just googled up without any kind of intrinsic knowledge about how the system should be working.

Sometimes the answer is “OK I got it working” followed by eternal silence from people asking clarifications. In other words, it looks like the task is very difficult and once people get it to work, it is so valuable they want to hide the details. In a way I cannot blame them much; it took me 6 months of half-time work every now and then to understand everything.

So, some 6 months ago I set myself a goal: “Create a portable solution where an intelligent bootloader can boot firmware images from any address in flash on Cortex-M0 or Cortex-M4 platform.” Finally, as of today 2022-01-16, I consider I have solved the problem in an intelligent and understandable way.

Funnily, I think I am the only person on planet Earth who has made available readily working example code and documented the code in a way I am doing now in this post.

Those impatient can explore the fully working STM32CubeIde codes at GitHub, for Cortex-M0:  and for Cortex-M4:  . (One might ask why one would use this kind of bloated stock configuration for developing on MCUs. Believe me, I’m doing it here only for pedagogical reasons. This way it is easier for noobs having the needed evaluation boards to verify that the code is working.)

The set of code I have created is a proof-of-concept, working for the C language. There might, and I underline, might be unforeseen problems when amount of global variable gets absurdly high. In any case, comments and criticism is more than welcome.

If you are ready to dive into the deep end of Cortex-M boot process, PIC constructs, esoteric debugging and linker script optimizations, continue reading…

Continue reading “Portable Position-Independent Code (PIC) bootloader and firmware for ARM Cortex-M0 and Cortex-M4”

Primer and use case of Position-Independent Code in ARM Cortex-M MCU environment

Recently I described my friend that I was working with Position-Independent Code on a Cortex-M0 and Cortex-M4 environment. To my surprise, he was more interested about “why” and not “how”. I think before revealing the nitty-gritty details of this domain, I can give readers an overview about things.

Continue reading “Primer and use case of Position-Independent Code in ARM Cortex-M MCU environment”

PC Engines APU2E0 – a tiny fanless server with Intel NICs

My earlier gateway box, the Lanner NCA-1010B decided to stop working, leaving everything as a messy chaos. I gobbled up my retired Zotac Zbox and hastily built a makeshift router.

A long term solution was however needed. I had heard good things from this no-bullshit-geeky Swiss company called PC Engines GmbH. They make a board called APU2E0, among other things. It is a AMD GX-412TC-based SOC product with 2 Intel i211AT NICs. And it does not have regular monitor connections. Instead, there is a DB9 serial port for installation purposes.

The board’s sister version is pictured below for reference.

Continue reading “PC Engines APU2E0 – a tiny fanless server with Intel NICs”

Building Raspberry Pi Alpine Linux drivers (splix) for Samsung SCX-3205

(Executive summary: Some prebuilt packages also available at my site )

Remember my old war horse, the Samsung SCX-3205 black & white printer/scanner? I recently moved in to a house. My girlfriend did not want printer near TV (with my ESXi shoebox) anymore, so I had to invent something else.

I had old Raspberry Pi 2 Model B v. 1.1 around, so I thought I should hook it up with the printer. Unfortunately I ended up compiling the necessary drivers myself because Alpine Linux did not have anything relevant. (I don’t blame them, this is quite outdated and rare.)

BTW Some Prebuilt packages are available at

Continue reading “Building Raspberry Pi Alpine Linux drivers (splix) for Samsung SCX-3205”

Installing WhatsApp on VMware ESXi (6.7) Android x86 7.1

The journey continues. In this blog post we learn how to get WhatsApp installed on our freshly installed Android x86 7.1 . This article exists for 2 reasons:

  1. To offer completeness in our efforts to get virtualized WhatsApp instances to authorize regular WhatsApp web clients
  2. To show the minor differences there are involved in the process compared to normal WhatsApp install

This is the second article in our 3 article series:

Installing Android x86 7.1 on VMware ESXi 6.7

Installing WhatsApp on VMware ESXi (6.7) Android x86 7.1

Complicatedly authorizing WhatsApp Web clients for VMware ESXi (6.7) Android x86 7.1

Again, as always, lets get started.

Continue reading “Installing WhatsApp on VMware ESXi (6.7) Android x86 7.1”

Installing Android x86 7.1 on VMware ESXi 6.7

I am one of those people who are perfectly fine with old style dumb 3G phones. But unfortunately some people are reluctant to communicate nowadays with regular phone calls, SMS or IRC, so I basically need to keep Android at hand for running WhatsApp.

Recently I found a way to run Android x86 7.1 on VMware ESXi 6.7. After a lot of teeth grinding, I was able to get WhatsApp running inside it. And after enormous test and debug efforts, I was even able to authorize WhatsApp Web clients. But with a lot of hoop-running. Extremely lot.

I chose Android x86 7.1 because it seems to be working completely for my desired purposes without (much) graphical glitches. For example 8.1 has horrible glitches which actually make many parts of initial setup widgets invisible 😀 . I chose VMware ESXi 6.7 as host because it is of the most stable main branch of the hypervisor. Host hardware is Intel NUC8i7HVK with 32GB RAM.

This is the list of articles of the whole operation (split due to big amount of screenshots):

Installing Android x86 7.1 on VMware ESXi 6.7

Installing WhatsApp on VMware ESXi (6.7) Android x86 7.1

Complicatedly authorizing WhatsApp Web clients for VMware ESXi (6.7) Android x86 7.1

Props to this external blog post for guiding me to the right direction. But now lets get started with our own stuff.

Continue reading “Installing Android x86 7.1 on VMware ESXi 6.7”