December 29, 2025

Kyu - Allwinner H3/H5 cleanup

I have decided to rename "orange_pi" and "orange_pi64" to H3 and H5 in the Kyu source tree.

I am also introducing an "allwinner" directory to hold shared driver code for these two chips. I make links from the h3 and h5 directories to these source files. There is some danger that I might make changes to a file while working on the H3 that breaks the H5 (or vice versa), but so far this has not arisen.

There are several reasons for this. First is that h3 and h5 involve less typing. More important is that there are interesting boards from other manufacturers (such as Neopi) that use these chips.

Doing this also involves updating the Kyu "config" script, and then doing a build for both H3 and H5 to see what issues turn up.

Build Kyu for the H3 - stupid linker warnings

This is something I have not done for several years, and the questions will be if compiler changes will require fixing things. It turns out that I get a clean compile with almost no issues.

One issue is missing "dhry_main()". I introduce a Kyu config option "WANT_DHRY" and simply don't define it to fix this issue.

I get warnings from the linker. This is a stupid business that should not affect someone doing embedded development. The people working on Gnu ld are thinking only of the linux kernel and application code.
So I see this: 

rm-none-eabi-ld.bfd --no-warn-rwx-segments -r -o ../machine.o locore.o armv6_start.o hardware.o ram.o interrupts.o cache.o cache_v7.o mmu.o show_regs.o cpufunc_asm_armv7.o eabi_stubs.o
arm-none-eabi-ld.bfd: warning: eabi_stubs.o: missing .note.GNU-stack section implies executable stack
arm-none-eabi-ld.bfd: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
And this: 
arm-none-eabi-ld.bfd: warning: machine.o: requires executable stack (because the .note.GNU-stack section is executable)
I already have this option on the linker command line, which suppresses one set of stupid warnings. 
arm-none-eabi-ld.bfd --no-warn-rwx-segments
There are two possible solutions. One is to use the "-z noexecstack" linker option, which you may need to pass like this if you use "cc" as your linker: 
-Wl,-z,noexecstack

The other is to add this weird bit of boilerplate to each assembly source file: 

.note.GNU-stack,"",@progbits
I add this to: 
src/armv7/armv7_cache.S
The other ".S" files in this directory already have the boilerplate. But this is not sufficient to suppress the warning. I end up needing to add the "-z noexecstack" option to the link line in the top level makefile.

Build for the BBB -- a choice of aarch32 compilers

I just did the build for the H3 using arm-none-eabi-gcc. When I go to try the build for the BBB, I get: 
arm-linux-gnu-gcc: command not found
So, there are two ARM gcc compilers available in the Fedora packages for aarch32. Apparently I used one for the BBB and the other for H3, for no particular reason.

I take some time now to read about this. The claim is that the "linux" flavor expects the full glibc and is for applications that will run on the linux OS. The noeabi is for what I am doing (embedded, bare metal coding). A person could drag in "newlib" to get various library routines (but I don't do this).
The easy thing is to just install the other compiler: 

su
dnf install gcc-arm-linux-gnu
After installing the compiler, we type make and get a clean build!

Board conditionals

Once we configure the Kyu source tree for a given build, we have a directory "board" that is a symlink to h5, fire3, bbb, or whatever. Each directory has its own "board.h" which typically defines: 
#define BOARD_H5
#define BOARD_ORANGE_PI_PC2
The first define is the one most often used. The second board specific define is used to cope with actual differences among H5 based boards. For example the NeoPi boards use a different IO pin for the status LED than does the OrangePi board.

The game now is to go through the code and clean up the use of these BOARD selection definitions, using H5 or H3 whereever possible and the actual board specific ones only as strictly needed.

Note that our "config" script deals only with H5 vs H3 vs BBB, but not specific boards within H5 or H3. To build for a specific board requires hand editing the definitions in board.h before running make.

Migration to the allwinner directory

This is a mess of my own making. The first two files (timer.c and serial.c) were easy. I am working on gpio.c now, which is more of a tangle.

I have to remember that the H3 files are well tested. The H5 files are in most cases simply copies of H3 files and untested. Sometimes I have made changes to the H3 files subsequent to the copy, and those changes need to be reviewed.

There are some files in the H3 directory that are links to files in the bbb directory. These are hardware independent i2c files that ought to get moved to a "driver" directory (which does not yet exist).

Blink an LED

We know about two LED on this board: 
Red "status" LED on PA15
Green "power" LED on PL10
The H5 manual calls the mysterious last GPIO the "L" gpio.
The H3 manual called this the "R" GPIO.
I call it the "J" GPIO (since it follows GPIO-I.
Have any comments? Questions? Drop me a line!

Tom's electronics pages / tom@mmto.org