- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#1
A20 / Re: Wich board to correctly mo...
Last post by oly - Today at 01:45:19 PMHello,
Sorry, for the delay.
Sorry, for the delay.
Code Select
root@TOTO:~# olinuxino-sd-to-sata
Detecting board...
Detecting the root device...
Root partition: /dev/sda1
Root device: /dev/sda
Detecting SATA device...
Failed to detect SATA device!
Code Select
root@TOTO:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 111,8G 0 disk
└─sda1 8:1 0 111,8G 0 part /
mmcblk0 179:0 0 14,8G 0 disk
└─mmcblk0p1 179:1 0 1,1G 0 part
Code Select
root@TOTO:~# df .
Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
/dev/sda1 114784676 1262712 107645052 2% /
#2
ESP32 / Re: ESP32-POE (ISO) LiPo Batte...
Last post by LubOlimex - Today at 08:13:43 AMRemoving FET2 won't work in your case. You need to carefully unsolder and remove U3 TP4054 (the battery charger IC). Refer to the schematic. It is SOT23-5 package, chip with 5 pins.
#3
ESP32 / Re: ESP32-POE (ISO) LiPo Batte...
Last post by oguzhan306 - October 27, 2026, 08:16:33 PMHi LubOlimex,
I have a similar question, but my use case is slightly different.
I'm using an ESP32-POE-ISO Rev. M in a device that will operate in cold environments, potentially below 0°C.
The device is normally powered via PoE, and I want to use a Li-ion battery strictly as a backup power source in case PoE fails.
I do not want the battery to be charged by the board under any circumstances, particularly because charging Li-ion batteries at sub-zero temperatures can be unsafe.
My requirements are:
When PoE is available, the device should operate from PoE.
When PoE is lost, the battery should automatically take over.
When PoE returns, the device should switch back to PoE.
The battery must never be charged by the board.
A brief power interruption or ESP32 reset during switching is acceptable.
In your earlier reply, you mentioned removing FET2 to disable the charging circuit.
Would removing FET2 on the ESP32-POE-ISO Rev. M completely disable battery charging while preserving the automatic battery backup functionality?
If not, is there another component that could be removed or a simple hardware modification you would recommend?
Thank you for your help!
I have a similar question, but my use case is slightly different.
I'm using an ESP32-POE-ISO Rev. M in a device that will operate in cold environments, potentially below 0°C.
The device is normally powered via PoE, and I want to use a Li-ion battery strictly as a backup power source in case PoE fails.
I do not want the battery to be charged by the board under any circumstances, particularly because charging Li-ion batteries at sub-zero temperatures can be unsafe.
My requirements are:
When PoE is available, the device should operate from PoE.
When PoE is lost, the battery should automatically take over.
When PoE returns, the device should switch back to PoE.
The battery must never be charged by the board.
A brief power interruption or ESP32 reset during switching is acceptable.
In your earlier reply, you mentioned removing FET2 to disable the charging circuit.
Would removing FET2 on the ESP32-POE-ISO Rev. M completely disable battery charging while preserving the automatic battery backup functionality?
If not, is there another component that could be removed or a simple hardware modification you would recommend?
Thank you for your help!
#4
New Products release / Build smart home Matter Light ...
Last post by olimex - October 26, 2026, 03:07:37 PMTurn the OLIMEX OSHW ESP32-C6-DevKit-Lipo into a Matter-over-Wi-Fi light 💡 It's commissioned over BLE and controlled locally from an Android phone.
You get On/Off and brightness control of the onboard LED, and the physical button reports its state back to the app.
https://olimex.wordpress.com/2026/10/26/esp32-c6-devkit-lipo-becomes-a-matter-light-a-step-by-step-guide/
#Matter #ESP32C6 #IoT #OpenSourceHardware #SmartHome #OSHW #Olimex
You get On/Off and brightness control of the onboard LED, and the physical button reports its state back to the app.
https://olimex.wordpress.com/2026/10/26/esp32-c6-devkit-lipo-becomes-a-matter-light-a-step-by-step-guide/
#Matter #ESP32C6 #IoT #OpenSourceHardware #SmartHome #OSHW #Olimex
#5
A64 / Re: Realtime scheduling for au...
Last post by LubOlimex - October 26, 2026, 01:13:47 PMNo idea but let me know if something breaks.
#6
A64 / Realtime scheduling for audio ...
Last post by winfried - October 24, 2026, 01:11:36 PMTrying to setup a streaming station, I found, getting crackled audio with puredata:
"priority 8 scheduling failed" for dsp process and "priority 6 scheduling failed." for GUI...
Test:
Fix the security limits `ulimit -r`-> 0:
- add a group audio, I set the limits in security:
so
But still
With AI help, I found:
Solution: build and installed new kernel from last branch with new config like described in Olimage-guide.pdf:
So the issue is now fixed and working without crackling.
The questions:
Was there a reason for "CONFIG_RT_GROUP_SCHED=y", maybe the stability of the system might be affected or something other does not work ?
Is it this fix save ?
Any hint or discussion about this is welcomed.
Mfg winfried
"priority 8 scheduling failed" for dsp process and "priority 6 scheduling failed." for GUI...
Test:
Code Select
$ ulimit -r
0
$ /usr/bin/chrt -f 8 true
chrt: failed to set pid 0's policy: Operation not permitted
Fix the security limits `ulimit -r`-> 0:
- add a group audio, I set the limits in security:
Code Select
sudo -s
cat > /etc/security/limits.d/99-audio.conf << EOF
@audio - rtprio 20
@audio - memlock unlimited
#@audio - nice -19
EOF
so
Code Select
ulimit -r is now 20, which is correct.But still
Code Select
chrt -f 8 true fails, so I looked in kernel config:Code Select
grep -E 'CONFIG_(CGROUPS|CGROUP_SCHED|RT_GROUP_SCHED|PREEMPT_RT)=|# CONFIG_(CGROUPS|CGROUP_SCHED|RT_GROUP_SCHED|PREEMPT_RT) is not set' "/boot/config-$(uname -r)"
CONFIG_CGROUPS=y
CONFIG_CGROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
With AI help, I found:
QuoteCONFIG_RT_GROUP_SCHED=y. With that option, a task in any cgroup other than the root cgroup can only use realtime scheduling if that cgroup has cpu.rt_runtime_us > 0. systemd puts your login session in user.slice/user-1000.slice/session-N.scope, and those cgroups default to 0. The kernel then returns EPERM even though rtprio is 20 in limits.conf
Solution: build and installed new kernel from last branch with new config like described in Olimage-guide.pdf:
Code Select
scripts/config --disable RT_GROUP_SCHED
make olddefconfig
grep RT_GROUP_SCHED .config # should show "is not set"
So the issue is now fixed and working without crackling.
The questions:
Was there a reason for "CONFIG_RT_GROUP_SCHED=y", maybe the stability of the system might be affected or something other does not work ?
Is it this fix save ?
Any hint or discussion about this is welcomed.
Mfg winfried
#7
TERES DIY Laptop / Adrian Black's Turbo VCFMW 202...
Last post by DesSony7 - October 23, 2026, 08:17:19 AM
#8
A64 / Re: Use USB OTG in host mode
Last post by winfried - October 22, 2026, 04:11:20 PMThanks, I understand now. 
#9
A64 / Re: Use USB OTG in host mode
Last post by LubOlimex - October 22, 2026, 02:58:29 PMThe phys property is a software ownership reference, not the physical USB connection.
On A64, PHY0 is shared and dynamically routed:
- Device mode → MUSB
- Host mode → EHCI0/OHCI0
MUSB and the Sun4i PHY driver manage PHY0, VBUS, and role switching. EHCI0/OHCI0 still use PHY0 electrically when it is routed to them, but must not claim it separately because that forces PHY0 permanently into host mode and breaks OTG switching.
This is specific to the A64 chip board which requires different routing (as compared to A20) - PHY0 has to be dual-routed. Fixes are only for the A64 board since the OTG in other Allwinner boards (A20,A13..) works fine. For example A20 uses a different architecture where PHY0 remains attached to MUSB and EHCI/OHCI use separate PHYs.
On A64, PHY0 is shared and dynamically routed:
- Device mode → MUSB
- Host mode → EHCI0/OHCI0
MUSB and the Sun4i PHY driver manage PHY0, VBUS, and role switching. EHCI0/OHCI0 still use PHY0 electrically when it is routed to them, but must not claim it separately because that forces PHY0 permanently into host mode and breaks OTG switching.
This is specific to the A64 chip board which requires different routing (as compared to A20) - PHY0 has to be dual-routed. Fixes are only for the A64 board since the OTG in other Allwinner boards (A20,A13..) works fine. For example A20 uses a different architecture where PHY0 remains attached to MUSB and EHCI/OHCI use separate PHYs.
#10
A64 / Re: Use USB OTG in host mode (...
Last post by winfried - October 22, 2026, 01:12:15 PMConfirmed !
Did update and reboot and there was the mouse and Codec:
Thanx a lot.
Just for understanding:
Why the ehci0: (usb@1c1a000) and ohci0: ( usb@1c1a400) does not need any phys ?
Did update and reboot and there was the mouse and Codec:
Code Select
Bus 004 Device 002: ID 08bb:2902 Texas Instruments PCM2902 Audio Codec
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 04b3:310c IBM Corp. Wheel Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Thanx a lot.
Just for understanding:
Why the ehci0: (usb@1c1a000) and ohci0: ( usb@1c1a400) does not need any phys ?