Recent posts

#1

DUINOMITE / Displays for Duinomite

Last post by KeesZagers - June 20, 2026, 03:50:44 PM

Based on the old DMBasic 2.7 I developed my own extensions to Basic, e.g. for all kind of CAN commands, but also some other controls as two kind of displays. The MOD-OLED-128x64 and the MOD-LCD2.8RTP are supported by one Basic statement called OLED which copies the VGA memory on to the screen. Also the touch screen of the MOD-LCD2.8RTP is supported by this statement. This week I ordered a new display module and determined that the touch is not working. Reading the details of the product, I noticed that the touch controller has been changed and the software seems not to be compatible. I will try to make the OLED statement also compatible with the new controller. For those people using my free software be noticed. For Olimex: If a product has software which is not upwards compatible with an old version, give it a new number, or at least specify it more clearly.

#2

A64 / Overheating on mainline Linux

Last post by Roman - June 20, 2026, 12:48:44 PM

With the current Linux-libre, I observe that A64-OLinuXino may overheat under heavy prolonged load.

Interestingly, when I try "stress-ng -c 0", which fully loads all four cores of the CPU, the temperature stabilizes right above the default lower temperature trip point of 75 degrees, even without a heatsink and in BOX-A64-BLACK inside an unventilated cabinet. But that load is synthetic and even.

Under a real-world load, for example, when I run "guix pull", which produces an uneven load over a long period of time (probably an hour), the temperature drifts and at some point may exceed 110 degrees. The last message that I see in the serial console says that 110 degrees were reached and the device is going into reboot. The reboot probably happens too fast for the chip to cool down because the board never starts by itself.

I conclude that the temperature fluctuates too fast under an uneven high load. The default configuration of the kernel does not handle that well. The configuration could probably be changed by configuring the power allocator. But I think that adding even a small heatsink on the A64 BGA should completely resolve the issue. The heatsink will be absorbing heat and should smooth the temperature spikes.

Olimex lists ALUMINIUM-HEATSINK-20x20x6MM as a related product for Allwinner A64. I suppose that it is appropriate for the task. I also saw a member of the forum reporting that a 15x15x15 is the right size for A64 and fits perfectly inside BOX-A64-BLACK. A datasheet for A64 says that it comes in "15x15mm" FBGA396 package. So, I probably should be looking for a 15x15 heatsink. Most of the readily available radiators are 14x14 mm in my local market, however.

If anyone has any advice on preventing overheating or on choosing a heatsink, it will be much appreciated.

Code Select Expand

$ uname -r
7.0.12-arm64-generic
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | uniq
schedutil
$ ls -l /sys/class/thermal/thermal_zone*/cdev*
lrwxrwxrwx 1 root root    0 Jun 20 12:18 /sys/class/thermal/thermal_zone0/cdev0 -> ../cooling_device0
-r--r--r-- 1 root root 4096 Jun 20 12:18 /sys/class/thermal/thermal_zone0/cdev0_trip_point
-rw-r--r-- 1 root root 4096 Jun 20 12:18 /sys/class/thermal/thermal_zone0/cdev0_weight
lrwxrwxrwx 1 root root    0 Jun 20 12:18 /sys/class/thermal/thermal_zone0/cdev1 -> ../cooling_device0
-r--r--r-- 1 root root 4096 Jun 20 12:18 /sys/class/thermal/thermal_zone0/cdev1_trip_point
-rw-r--r-- 1 root root 4096 Jun 20 12:18 /sys/class/thermal/thermal_zone0/cdev1_weight
$ cat /sys/class/thermal/cooling_device0/type
cpufreq-cpu0
$ cat /sys/class/thermal/thermal_zone0/trip_point_1_type
hot
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_type
passive
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_temp
75000
$ cat /sys/class/thermal/thermal_zone0/cdev0_trip_point
0
$ cat /sys/class/thermal/thermal_zone0/cdev1_trip_point
1
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_hyst
2000
$ cat /sys/class/thermal/thermal_zone0/k_po
0
$ cat /sys/class/thermal/thermal_zone0/k_d
0
$ cat /sys/class/thermal/thermal_zone0/sustainable_power
0


#3

ESP32 / Re: ESP32-PoE-ISO UART1 issue

Last post by LubOlimex - June 18, 2026, 04:50:04 PM

Here is the experimental firmware version 6 - it should have better support for half duplex mode and work fine with Modbus:

https://www.olimex.com/Products/Modules/Interface/MOD-RS485-ISO/resources/MOD-RS485_FIRMWARE_V6.zip

There is also Arduino library and examples inside (ZIP the sub-folder and import in Arduino IDE).

Changing the firmware of MOD-RS485-ISO requires PIC-compatible programmer, there is a hex inside the archive, load it on each RS485-ISO board.

I tested the examples with ESP32-POE-ISO and all seems to work fine but feedback is more than welcome.

#4

A64 / Re: A64-OLinuXino-2Ge16G-IND: ...

Last post by ericstokes - June 18, 2026, 11:47:36 AM

I am developing a Yocto 5.0 (Scarthgap) Linux image for the A64-OLinuXino-2Ge16G-IND board and have encountered a critical issue with warm reboot that I have been unable to resolve.

Issue:
The board hangs on every reboot (warm reset and cold reset) after the following boot log line:

INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x4a000000
INFO: SPSR = 0x3c9
[HANG - no U-Boot output]

First cold power-on always works correctly. The hang occurs every time after any reboot command.

Setup:
- Board: A64-OLinuXino-2Ge16G-IND
- U-Boot: 2024.01 (mainline, from Yocto Scarthgap / poky)
- TF-A: 2.10.4 with SUNXI_PSCI_USE_NATIVE=1 SUNXI_PSCI_USE_SCPI=1
- Crust SCP: v0.6.0 (a64-olinuxino_defconfig)
- Kernel: Linux 6.6.85
- Boot device: SD card (mmcblk0)

What I have tried:
- Added Crust SCP firmware (scp.bin embedded in U-Boot SPL)
- Added R_WDOG fix for A64 in reset_cpu() in board.c
- Added PLL6 lock timeout in clock_init_safe() in clock_sun6i.c
- TF-A rebuilt with LOG_LEVEL=40 - confirmed BL31 completes successfully and hands off to U-Boot at 0x4a000000
- U-Boot freezes before printing a single character

The hang is confirmed to be between BL31 exit and U-Boot's first UART output.

Question:
Can anyone please share which U-Boot version and if any specific patches you use in your Olimage builds for the A64-OLinuXino to make reboot work correctly?
Any guidance would be greatly appreciated.

Best regards,
Bratiranjan Acharya
bratiranjan12@gmail.com

The issue is most likely not TF-A, since BL31 successfully hands off to U-Boot at 0x4a000000. A64 warm-reset problems are often caused by SPL/DRAM/clock state not being fully reinitialized after reboot.

I'd recommend testing a newer mainline U-Boot (2024.10+ or current master) or enabling CONFIG_DEBUG_UART to see how early it hangs.

#5

New Products release / Home Automation with Phone Not...

Last post by olimex - June 11, 2026, 02:46:54 PM

Yes, It's Possible!
How to do it with EUR 4.95 ESP32-C3-DevKit-LiPo tutorial https://olimex.wordpress.com/2026/06/11/home-automation-with-phone-notifications-for-under-e5-yes-its-possible/
#esp32 #espressif #telegram #homeautomation #iot #notifications #door #monitoring #motion #detection

#6

A13 / Re: How update nand flash of m...

Last post by colpamax - June 10, 2026, 01:01:50 PM

New script is ready! Now you can move Linux to NAND without step 4) of previous instruction. Also 7 different Android partitions are combined into nandc. After all you have 3 partitions nanda (uboot and kernel),nandb (configuration), nandc (root).
Please be patient during tar working part.
1) Install Android to NAND using LiveSuit
2) Install Debian to SD card.
3) Run Debian from SD card and run script.
All the steps are described thoroughly in previous posts.

Code Select Expand

#!/bin/sh

python -c '
import struct, zlib, os, sys
p = "/sys/class/block/nand/size"
if not os.path.exists(p):
    print "Error"
    sys.exit(1)
with open(p, "r") as f:
    t = int(f.read().strip())
L = [("bootloader", 2048, 32768), ("env", 34816, 4096), ("rootfs", 38912, t - 36864)]
e = ""
for idx, (n, st, sz) in enumerate(L):
    if idx == 0:
        l1 = struct.pack("<BBB5sII", 0, 0, 3, "\x00" * 5, st, 0)
    else:
        l1 = struct.pack("<QII", 0, st, 0)
    e += l1 + struct.pack("<I4sQ", sz, "DISK", 0) + n.ljust(16, "\x00") + "\x00" * 16
b = (struct.pack("<II8s", 0, 0x100, "softw311") + e).ljust(1024, "\x00")
out = ""
for i in range(4):
    c = b[:17] + struct.pack("B", i) + b[18:]
    out += struct.pack("<I", zlib.crc32(c[4:]) & 0xffffffff) + c[4:]
with open("nand_part.bin", "wb") as f:
    f.write(out)
print "Done"
'

dd if=nand_part.bin of=/dev/nand bs=1k count=4
sleep 1
sync
sleep 1
sync
sleep 1

blockdev --rereadpt /dev/nand
sleep 2
blockdev --rereadpt /dev/nand
sleep 2
blockdev --rereadpt /dev/nand
sleep 2

umount /dev/nandc
mkfs.ext4 /dev/nandc
tune2fs -o journal_data_writeback /dev/nandc
tune2fs -O ^has_journal /dev/nandc
e2fsck -f /dev/nandc


mkdir /mnt/nandroot
mount /dev/nandc /mnt/nandroot

tar --exclude=/proc/* \
    --exclude=/sys/* \
    --exclude=/dev/* \
    --exclude=/tmp/* \
    --exclude=/run/* \
    --exclude=/mnt/* \
    --exclude=/media/* \
    --exclude=/var/log/* \
    --exclude=/var/tmp/* \
    -cf - / | (cd /mnt/nandroot && tar -xf -)

cat << 'EOF' > /mnt/nandroot/etc/fstab
/dev/nandc    /              ext4    defaults,noatime,nodiratime,commit=60    0    1
tmpfs         /tmp           tmpfs   defaults,noatime,mode=1777,size=64M      0    0
tmpfs         /var/log       tmpfs   defaults,noatime,mode=0755,size=32M      0    0
tmpfs         /var/tmp       tmpfs   defaults,noatime,mode=1777,size=32M      0    0
EOF

umount  /mnt/nandroot
rmdir /mnt/nandroot


mkdir -p /mnt/sdboot
mount /dev/mmcblk0p1 /mnt/sdboot

mkdir -p /mnt/nandboot
mount /dev/nanda /mnt/nandboot

cp /mnt/sdboot/uImage /mnt/nandboot/
cp /mnt/sdboot/script.bin /mnt/nandboot/
umount /mnt/sdboot
rmdir /mnt/sdboot
umount /mnt/nandboot
rmdir /mnt/nandboot


cat << 'EOF' > u-boot.txt
baudrate=115200
bootdelay=1
console=ttyS0,115200
loglevel=8
machid=102a
nand_root=/dev/nandc
init=/sbin/init
setargs=setenv bootargs console=${console} root=${nand_root} rootwait init=${init} loglevel=${loglevel}
boot_normal=fatload nand 0:0 0x44000000 uImage; bootm 0x44000000
bootcmd=run setargs boot_normal
EOF


python -c "
import zlib, struct
with open('u-boot.txt', 'r') as f:
    lines = [line.strip() for line in f if line.strip()]
data = '\x00'.join(lines) + '\x00'
target_size = 131072 - 4
data = data.ljust(target_size, '\x00')
crc = zlib.crc32(data) & 0xffffffff
header = struct.pack('<I', crc)
with open('env.bin', 'wb') as f:
    f.write(header + data)
print('env.bin reafy! filesize:', len(header + data))
"
sudo dd if=env.bin of=/dev/nandb bs=1k
sync

rm env.bin u-boot.txt

echo "All done! Now power off the board, remove SD card and next time it will boot Linux from NAND!"


#7

FPGA / Re: First time issues programm...

Last post by LubOlimex - June 10, 2026, 09:15:26 AM

Thanks for the feedback and the repo, I will make sure to link at the product page, under "Community".

#8

FPGA / Re: First time issues programm...

Last post by nachoworks - June 09, 2026, 09:53:35 PM

To make up for the critique of my last comment, I thought I'd help out:

Enjoy fellow travellers! https://github.com/kerstensrobin/iCE40HX1k-EVB-exploration

Scraping together some documentations and clarifying things that were not necessarily clear to me in the beginning, being out of practice when it comes to FGPA development.

#9

FPGA / First time issues programming ...

Last post by nachoworks - June 09, 2026, 12:26:58 PM

I did not find a similar topic, but wanted to share this information to avoid other people bumping into the same issue  I spent about two nights trying to program the iCE40HX1K-EVB using my RPi 4 with no success, checking connections, switching pins on the RPi.

Dear fellow FPGA-traveller: The PGM-1 connector does not have pin 1 in the top left corner!



In the documentation and schematics this is rotated 180 degrees



The average reader: "PCB layout does not follow the schematic!!!"
I know, pebkac, this is probably due to my own experience in placing pin1 always in the same orientation on schematic/board.

I just wanted to have this highlighted somewhere

Also: the documentation for this board is somewhat outdated as it mentions RPi2's and some dead links at the bottom when it comes to RPi programming.

#10

A64 / Re: Debian GNU/Linux 13 (Trixi...

Last post by mossroy - June 07, 2026, 09:58:51 AM

Could you tell which revisions of the board you have?

All my A64 boards are A64-OLinuXino-2Ge8G-IND rev E