- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#1
A20 / difference between A20-OLinuXi...
Last post by oeren - Today at 02:12:33 PMIs only difference between A20-OLinuXino-LIME and A20-OLinuXino-LIME2 size of ram and speed of ethernet? Thank you.
#2
A20 / Re: update to Debian 12 (Bookw...
Last post by oly - Today at 12:06:01 PMQuote from: gregh on April 06, 2026, 05:23:24 PMIt seems that there are Olimex bookworm images now:
https://images.olimex.com/release/a20/
It also seems that they contain only the old kernel versions from Bullseye:
https://repository.olimex.com/dists/bookworm/main/binary-armhf/Packages
How secure are those old kernels?
https://www.cybersecurity-help.cz/vdb/soft/linux_foundation/linux_kernel/5.15.105/
https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.105
#3
New Product Ideas / Re: can a lime 2 or pico 2 xxl...
Last post by Roman - September 09, 2026, 11:16:28 AMI couldn't find a specification, but, looking at their marketing materials, it appears that the Open Printer project implements the control module as a HAT on top of a Raspberry Pi Zero W and tailors the shape of the control module to accommodate the board of that particular size. Assuming that it is the case, it sets constraints on what the board must be. I doubt that Open Printer will want to adapt their design, even in a future iteration of their printer, to accommodate the shape of one of Olimex boards, which are comparably less widespread.
Olimex doesn't sell a drop-in replacement for Raspberry Pi Zero. Olimex boards are typically larger with more interfaces and are not pin-compatible with that board. Also, the market is already crowded with Raspberry Pi Zero clones, so I assume that it is hard to justify developing yet another one.
Unfortunately, all the ARM-based clones of the board that I am aware of require some binary blobs to boot.
However, there is an existing product on the market from another manufacturer that you may consider. There is a pin-compatible board in the same form factor as Raspberry Pi Zero, which is known to boot without proprietary blobs in uboot and in the Linux kernel, and on which it should be possible to run CUPS. There are several caveats to keep in mind. It is based on Allwinner D1, and thus, is RISC-V, not ARM. Also, I could only find versions with built-in Wi-Fi, which is not expected to work without a blob. But the onboard WiFi module could be kept uninitialized, or, alternatively, desoldered completely. So, it can be used entirely with free software. And it should be possible to adapt it for use in Open Printer.
Speaking of Wi-Fi. Open Printer only lists two options to connect the printer: either over USB Type-C directly to a computer or over Wi-Fi. They left Ethernet out, so one will have to write a USB driver for the board and connect the printer to another computer. That another computer could be an Olimex board, but it does not require any customization by Olimex to work.
Considering the above, it probably makes little sense for Olimex to get interested in Open Printer at this point.
Olimex doesn't sell a drop-in replacement for Raspberry Pi Zero. Olimex boards are typically larger with more interfaces and are not pin-compatible with that board. Also, the market is already crowded with Raspberry Pi Zero clones, so I assume that it is hard to justify developing yet another one.
Unfortunately, all the ARM-based clones of the board that I am aware of require some binary blobs to boot.
However, there is an existing product on the market from another manufacturer that you may consider. There is a pin-compatible board in the same form factor as Raspberry Pi Zero, which is known to boot without proprietary blobs in uboot and in the Linux kernel, and on which it should be possible to run CUPS. There are several caveats to keep in mind. It is based on Allwinner D1, and thus, is RISC-V, not ARM. Also, I could only find versions with built-in Wi-Fi, which is not expected to work without a blob. But the onboard WiFi module could be kept uninitialized, or, alternatively, desoldered completely. So, it can be used entirely with free software. And it should be possible to adapt it for use in Open Printer.
Speaking of Wi-Fi. Open Printer only lists two options to connect the printer: either over USB Type-C directly to a computer or over Wi-Fi. They left Ethernet out, so one will have to write a USB driver for the board and connect the printer to another computer. That another computer could be an Olimex board, but it does not require any customization by Olimex to work.
Considering the above, it probably makes little sense for Olimex to get interested in Open Printer at this point.
#4
A20 / Re: Working Linux driver for U...
Last post by sasha2002 - September 08, 2026, 02:25:09 PMChipset info :
#5
ESP32 / Works! Olimex esp32-poe-iso(lx...
Last post by mihaiadrian - September 06, 2026, 10:27:09 PMSucceed doing a local voice intercom with Olimex esp32-poe-iso(lx6) as primary and ESP32-S3-DevKit-Lipo(lx7) as DSP with ECHO cancellation . The voice communication is full duplex. Initially tried without the lx7 and was impossible to make a full duplex communication due to big noise echo. So, lx7 is doing a good job in canceling the echo.
#6
New Products release / Neo6502kbd all in one neo6502 ...
Last post by olimex - September 04, 2026, 02:11:45 PMDo you remember Karateka, Lode Runner, and Cross Fire on the Apple ][? Our Neo6502kbd brings it all back — an all-in-one retro computer with a real 6502 processor which you can connect to your home TV https://olimex.wordpress.com/2026/09/04/new-open-source-hardware-variant-of-neo6502-now-includes-keyboard-4-usb-hosts-uext-power-switch-and-usb-c-for-power-and-programming-all-in-one-keyboard-body/
#retrocomputing #retrogaming #w65c02
#retrocomputing #retrogaming #w65c02
#7
A20 / Re: Working Linux driver for U...
Last post by sasha2002 - September 01, 2026, 11:15:48 AMCode Select
root@a20-olinuxino:~# lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 350b:f179 ZTOP ztop CDROM
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 003 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
root@a20-olinuxino:~# eject /dev/sr0
lsusb
dmesg | grep -Ei '350b|9612|f179|ztop|zt9612|firmware|wlan|wifi|usb' | tail -120
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 003 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
[ 1.828739] usbcore: registered new interface driver usbhid
[ 1.828749] usbhid: USB HID core driver
[ 2.032252] ehci-platform 1c14000.usb: EHCI Host Controller
[ 2.032504] ehci-platform 1c14000.usb: new USB bus registered, assigned bus number 1
[ 2.033061] ehci-platform 1c14000.usb: irq 42, io mem 0x01c14000
[ 2.048376] ehci-platform 1c14000.usb: USB 2.0 started, EHCI 1.00
[ 2.048798] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.10
[ 2.048814] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.048824] usb usb1: Product: EHCI Host Controller
[ 2.048832] usb usb1: Manufacturer: Linux 5.10.180-olimex ehci_hcd
[ 2.048840] usb usb1: SerialNumber: 1c14000.usb
[ 2.049933] hub 1-0:1.0: USB hub found
[ 2.051596] ehci-platform 1c1c000.usb: EHCI Host Controller
[ 2.051641] ehci-platform 1c1c000.usb: new USB bus registered, assigned bus number 2
[ 2.052131] ehci-platform 1c1c000.usb: irq 47, io mem 0x01c1c000
[ 2.064494] ehci-platform 1c1c000.usb: USB 2.0 started, EHCI 1.00
[ 2.065002] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.10
[ 2.065017] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.065027] usb usb2: Product: EHCI Host Controller
[ 2.065035] usb usb2: Manufacturer: Linux 5.10.180-olimex ehci_hcd
[ 2.065043] usb usb2: SerialNumber: 1c1c000.usb
[ 2.066353] hub 2-0:1.0: USB hub found
[ 2.068075] ohci-platform 1c14400.usb: Generic Platform OHCI controller
[ 2.068118] ohci-platform 1c14400.usb: new USB bus registered, assigned bus number 3
[ 2.068768] ohci-platform 1c14400.usb: irq 43, io mem 0x01c14400
[ 2.132724] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.10
[ 2.132749] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.132759] usb usb3: Product: Generic Platform OHCI controller
[ 2.132767] usb usb3: Manufacturer: Linux 5.10.180-olimex ohci_hcd
[ 2.132776] usb usb3: SerialNumber: 1c14400.usb
[ 2.133686] hub 3-0:1.0: USB hub found
[ 2.135445] ohci-platform 1c1c400.usb: Generic Platform OHCI controller
[ 2.135491] ohci-platform 1c1c400.usb: new USB bus registered, assigned bus number 4
[ 2.136113] ohci-platform 1c1c400.usb: irq 48, io mem 0x01c1c400
[ 2.196737] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.10
[ 2.196755] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.196765] usb usb4: Product: Generic Platform OHCI controller
[ 2.196774] usb usb4: Manufacturer: Linux 5.10.180-olimex ohci_hcd
[ 2.196781] usb usb4: SerialNumber: 1c1c400.usb
[ 2.197750] hub 4-0:1.0: USB hub found
[ 2.199591] usb_phy_generic usb_phy_generic.0.auto: supply vcc not found, using dummy regulator
[ 2.199874] usb_phy_generic usb_phy_generic.0.auto: dummy supplies not allowed for exclusive requests
[ 2.201177] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[ 2.201225] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 5
[ 2.201767] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.10
[ 2.201782] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.201791] usb usb5: Product: MUSB HDRC host driver
[ 2.201799] usb usb5: Manufacturer: Linux 5.10.180-olimex musb-hcd
[ 2.201807] usb usb5: SerialNumber: musb-hdrc.1.auto
[ 2.202741] hub 5-0:1.0: USB hub found
[ 2.388525] usb 2-1: new high-speed USB device number 2 using ehci-platform
[ 2.546304] usb 2-1: New USB device found, idVendor=350b, idProduct=f179, bcdDevice= 2.00
[ 2.546329] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.546341] usb 2-1: Product: ztop CDROM
[ 2.546350] usb 2-1: Manufacturer: ZTOP
[ 2.548251] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 2.549888] scsi host1: usb-storage 2-1:1.0
[ 2.564570] usb 3-1: new low-speed USB device number 2 using ohci-platform
[ 2.793204] usb 3-1: New USB device found, idVendor=046d, idProduct=c31c, bcdDevice=64.00
[ 2.793230] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.793241] usb 3-1: Product: USB Keyboard
[ 2.793250] usb 3-1: Manufacturer: Logitech
[ 2.807901] input: Logitech USB Keyboard as /devices/platform/soc/1c14400.usb/usb3/3-1/3-1:1.0/0003:046D:C31C.0001/input/input1
[ 2.865050] hid-generic 0003:046D:C31C.0001: input,hidraw0: USB HID v1.10 Keyboard [Logitech USB Keyboard] on usb-1c14400.usb-1/input0
[ 2.878423] input: Logitech USB Keyboard Consumer Control as /devices/platform/soc/1c14400.usb/usb3/3-1/3-1:1.1/0003:046D:C31C.0002/input/input2
[ 2.937519] input: Logitech USB Keyboard System Control as /devices/platform/soc/1c14400.usb/usb3/3-1/3-1:1.1/0003:046D:C31C.0002/input/input3
[ 2.938166] hid-generic 0003:046D:C31C.0002: input,hidraw1: USB HID v1.10 Device [Logitech USB Keyboard] on usb-1c14400.usb-1/input1
[ 3.562006] scsi 1:0:0:0: CD-ROM S9612USB CDROM AUTORUN V1.0 PQ: 0 ANSI: 0 CCS
[ 3.704440] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 4.016501] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 4.316520] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 4.616554] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 4.912531] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 5.212368] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 5.512348] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 5.812345] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 6.307796] usbcore: registered new interface driver uas
[ 6.520386] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 6.820356] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 7.120347] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 7.420343] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 7.712348] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 8.012347] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 8.312348] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 8.612345] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 9.120384] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 9.420352] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 9.720344] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 10.020347] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 10.312351] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 10.612346] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 10.912344] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 11.212350] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 14.961210] systemd[1]: Reached target paths.target - Path Units.
[ 20.084539] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 20.480511] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 20.792520] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 21.100487] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 21.400510] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 21.692534] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 22.008524] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 22.308484] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 22.616537] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 22.932555] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 23.232540] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 23.532594] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 23.832491] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 24.152041] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 24.472461] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 24.776525] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 25.080624] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 25.948531] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 26.248479] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 26.548463] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 26.848439] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 27.144401] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 27.448399] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 27.752372] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 28.060371] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[ 921.293484] usb 2-1: USB disconnect, device number 2
root@a20-olinuxino:~# lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 350b:9612 ZTOP 802.11ax 2x2 WLAN Adapter
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 003 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
root@a20-olinuxino:~#
#8
A64 / Re: A64-OlinuXino-2Ge16G-IND E...
Last post by LubOlimex - August 31, 2026, 11:39:25 AMThank you for this. I want to post update in this topic since it had been recently brought up by another customer.
The reset circuit of the Ethernet can be handled passively or via GPIO pin connected to the main chip.
There are advantages and disadvantages of each option. In the hardware design of our A64 boards we have chosen the second option - connect the Ethernet reset to a GPIO of the A64 chip (in our case specifically pin "PD24") - this allows to reset just the Ethernet, by toggling this GPIO PD24, if a problem with the Ethernet appears. It is very convenient for systems where reliability is important and where the whole board shouldn't be power cycled when Ethernet hangs. Now - the down-side is that your software should take care of the GPIO pin that is routed to the reset of the Ethernet (e.g. during power-up either keep it in reset long enough, or maybe even simpler, just run one time reset at some point during boot). This software work is now done in our Olimage Linux, it handles PD24 during power-up.
Of course, if you use custom Linux and you have Ethernet issues during power up or reset, you can add some software control for PD24 and fix it.
Alternatively, give up on the software method and go the hardware option we have provided. Simply unsolder R117 (1K) and solder it to R118 position. This will disconnect the Ethernet reset from PD24 GPIO, and connect it to the passive auto-reset circuit. This simplifies the design but disables the option to reset ONLY the Ethernet via GPIO (e.g. if the Ethernet hangs and it is not possible to recover you will need to reset the whole board).
The reset circuit of the Ethernet can be handled passively or via GPIO pin connected to the main chip.
There are advantages and disadvantages of each option. In the hardware design of our A64 boards we have chosen the second option - connect the Ethernet reset to a GPIO of the A64 chip (in our case specifically pin "PD24") - this allows to reset just the Ethernet, by toggling this GPIO PD24, if a problem with the Ethernet appears. It is very convenient for systems where reliability is important and where the whole board shouldn't be power cycled when Ethernet hangs. Now - the down-side is that your software should take care of the GPIO pin that is routed to the reset of the Ethernet (e.g. during power-up either keep it in reset long enough, or maybe even simpler, just run one time reset at some point during boot). This software work is now done in our Olimage Linux, it handles PD24 during power-up.
Of course, if you use custom Linux and you have Ethernet issues during power up or reset, you can add some software control for PD24 and fix it.
Alternatively, give up on the software method and go the hardware option we have provided. Simply unsolder R117 (1K) and solder it to R118 position. This will disconnect the Ethernet reset from PD24 GPIO, and connect it to the passive auto-reset circuit. This simplifies the design but disables the option to reset ONLY the Ethernet via GPIO (e.g. if the Ethernet hangs and it is not possible to recover you will need to reset the whole board).
#9
A20 / Re: Working Linux driver for U...
Last post by LubOlimex - August 26, 2026, 04:55:44 PMAh, it is probably with a different chipset. What does it list as before ejecting, e.g. unplug/plug?
lsusb
After ejecting is clear but still what does this return:
eject /dev/sr0
lsusb
dmesg | grep -Ei '350b|9612|f179|ztop|zt9612|firmware|wlan|wifi|usb' | tail -120
lsusb
After ejecting is clear but still what does this return:
eject /dev/sr0
lsusb
dmesg | grep -Ei '350b|9612|f179|ztop|zt9612|firmware|wlan|wifi|usb' | tail -120
#10
A64 / Re: Debian GNU/Linux 13 (Trixi...
Last post by Roman - August 23, 2026, 10:18:34 PMQuote from: Roman on June 06, 2026, 08:09:08 PMBut I would rather see the issue fixed in the upstream.
I was pointed to the documentation about the Ethernet PHY modes. It explains which mode to use depending on how the 2 ns RGMII delay is implemented.
Quote# One option is to make the clock traces on the PCB longer than the
# data traces. A sufficiently difference in length can provide the 2ns
# delay. If both the RX and TX delays are implemented in this manner,
# 'rgmii' should be used, so indicating the PCB adds the delays.
#
# If the PCB does not add these delays via extra long traces,
# 'rgmii-id' should be used. Here, 'id' refers to 'internal delay',
# where either the MAC or PHY adds the delay.
I tried calculating the legths of the tracks and counting resistrors in the PCB schematics and concluded that they are unlikely to bring any significant delays. I tried 'rgmii-id' and it worked without additional adjustments to both RX and TX delays in the device tree, so the driver configures the delays for that mode.
Assuming that the submitted upstream patch is accepted into Linux release 7.3, a kernel with that fix to the device tree may eventually become available in Debian backports.