- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#1
STMP1 / STM32MP1-OLinuXino-LIME: suppo...
Last post by dry - Today at 04:18:02 PMI noticed that microSD R,W performance seems very slow. I don't belive its the card's issue - C10, V30, U3, A2.
The card under test is a SanDisk Extreme 64GB, marked V30 / U3 / A2. It is detected as mmcblk1:
mmc1: new high speed SDXC card at address aaaa
mmcblk1: mmc1:aaaa SN64G 59.5 GiB
EXT4-fs (mmcblk1p4): mounted filesystem
The debugfs MMC status shows:
clock: 50000000 Hz
actual clock: 49500000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
bus width: 2 (4 bits)
timing spec: 2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)
In dmesg I also see the controller reported with "pio":
mmci-pl18x 58005000.sdmmc: mmc1: PL180 manf 53 rev1 at 0x58005000 irq 56,0 (pio)
My measured performance on /test, using diskspd-for-linux with O_DIRECT/O_SYNC, is approximately:
Sequential read: ~10.6 MiB/s
Sequential write: ~2.1 MiB/s
Random 4K read: ~898 IOPS
Random 4K write: ~81 IOPS
Could you please clarify:
1. The STM32MP157 SoC can support better SDMMC modes than plain 50 MHz SD High-Speed,
so do I undersand it correctly, the Olimex board microSD slot wired for fixed 3.3V SD High-Speed operation, it cannot do 1.8V / UHS-I?
2. Is DMA expected to be available for this SDMMC controller, or is PIO mode normal on this board/kernel configuration?
3. Are there any recommended device-tree or kernel settings required to enable the best supported SDMMC performance?
My kernel:
Linux stm32mp1-olinuxino-lime 5.10.180-olimex #075247 SMP Tue Jun 30 07:54:18 UTC 2026 armv7l GNU/Linux
And my enabled overlays are:
stm32mp1-hdmi.dtbo STM32MP1-OLinuXino Enable HDMI
stm32mp1-mmc3.dtbo Enable MMC3 extension
(So i tested both slots: on board, and through slot on the shield extension board, almost same results)
The card under test is a SanDisk Extreme 64GB, marked V30 / U3 / A2. It is detected as mmcblk1:
mmc1: new high speed SDXC card at address aaaa
mmcblk1: mmc1:aaaa SN64G 59.5 GiB
EXT4-fs (mmcblk1p4): mounted filesystem
The debugfs MMC status shows:
clock: 50000000 Hz
actual clock: 49500000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
bus width: 2 (4 bits)
timing spec: 2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)
In dmesg I also see the controller reported with "pio":
mmci-pl18x 58005000.sdmmc: mmc1: PL180 manf 53 rev1 at 0x58005000 irq 56,0 (pio)
My measured performance on /test, using diskspd-for-linux with O_DIRECT/O_SYNC, is approximately:
Sequential read: ~10.6 MiB/s
Sequential write: ~2.1 MiB/s
Random 4K read: ~898 IOPS
Random 4K write: ~81 IOPS
Could you please clarify:
1. The STM32MP157 SoC can support better SDMMC modes than plain 50 MHz SD High-Speed,
so do I undersand it correctly, the Olimex board microSD slot wired for fixed 3.3V SD High-Speed operation, it cannot do 1.8V / UHS-I?
2. Is DMA expected to be available for this SDMMC controller, or is PIO mode normal on this board/kernel configuration?
3. Are there any recommended device-tree or kernel settings required to enable the best supported SDMMC performance?
My kernel:
Linux stm32mp1-olinuxino-lime 5.10.180-olimex #075247 SMP Tue Jun 30 07:54:18 UTC 2026 armv7l GNU/Linux
And my enabled overlays are:
stm32mp1-hdmi.dtbo STM32MP1-OLinuXino Enable HDMI
stm32mp1-mmc3.dtbo Enable MMC3 extension
(So i tested both slots: on board, and through slot on the shield extension board, almost same results)
#2
STMP1 / An intern / EE student wanted ...
Last post by dry - Today at 02:22:19 AMThis is probably a shot in the dark, but I'll shoot:
Seeking an intern/EE Student work in return for experience, reference(s), connections, not paid work.
Any EE student wants to work as intern for our start-up project/co?
In return, you get experience and a good reference. (In longer term, possible paid sub-contract work if this turns productive).
In brief, the scope would be making a custom extension board to plug ontop of Olimex's STMP157-OLinuXino-LIME2, into its GPIO connetors. There are requirements which should make this interesting.
Note that, while Olimex's board is open OSHW, the extension board will not be.
This should fit a Unni student with EE knowledge and preferably some basic PCB design experience, or enough ground knowledge to make it your first design, send to production, and then test/debug as needed.
Remote work is Ok, but You need to be in timezone such that we can chat between 9 am - 9 pm my time which is Melbourne, Australia.
If you interested, send me a message on the forum, just with your email and name - I'll ack and send you email to start the conversation.
Seeking an intern/EE Student work in return for experience, reference(s), connections, not paid work.
Any EE student wants to work as intern for our start-up project/co?
In return, you get experience and a good reference. (In longer term, possible paid sub-contract work if this turns productive).
In brief, the scope would be making a custom extension board to plug ontop of Olimex's STMP157-OLinuXino-LIME2, into its GPIO connetors. There are requirements which should make this interesting.
Note that, while Olimex's board is open OSHW, the extension board will not be.
This should fit a Unni student with EE knowledge and preferably some basic PCB design experience, or enough ground knowledge to make it your first design, send to production, and then test/debug as needed.
Remote work is Ok, but You need to be in timezone such that we can chat between 9 am - 9 pm my time which is Melbourne, Australia.
If you interested, send me a message on the forum, just with your email and name - I'll ack and send you email to start the conversation.
#3
A20 / Recurring SATA HD error on Lim...
Last post by mbosschaert - June 26, 2026, 07:02:03 PMOn my Lime2 RevL with latest olimex kernel I keep getting these errors frequently. The power supply of the board is 15W. I've replaced the SATA cable as in different fora this is suggested to be the cause. The WD 1TB 2.5" disk can be checked on another board and seems to be OK. As the enclosures have ventilation openings around the board it is unlikely caused by overheating.
Are there other Lime2 users experiencing the same disk failures and if so what was your solution?
Are there other Lime2 users experiencing the same disk failures and if so what was your solution?
Code Select
[ 1.863904] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.985543] ata1.00: ATA-10: WDC WD20SPZX-22UA7T0, 01.01A01, max UDMA/133
[ 1.985558] ata1.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth 32)
[ 1.986234] ata1.00: configured for UDMA/133
[ 1.987153] scsi 0:0:0:0: Direct-Access ATA WDC WD20SPZX-22U 1A01 PQ: 0 ANSI: 5
[ 1.988597] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 1.988969] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[ 1.988985] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 1.989111] sd 0:0:0:0: [sda] Write Protect is off
[ 1.989127] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1.989332] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 2.033446] ata1.00: exception Emask 0x10 SAct 0x1 SErr 0x10200 action 0xe frozen
[ 2.040997] ata1.00: irq_stat 0x00400000, PHY RDY changed
[ 2.046412] ata1: SError: { Persist PHYRdyChg }
[ 2.050961] ata1.00: failed command: READ FPDMA QUEUED
[ 2.056126] ata1.00: cmd 60/08:00:a8:88:e0/00:00:e8:00:00/40 tag 0 ncq dma 4096 in
res 40/00:00:a8:88:e0/00:00:e8:00:00/40 Emask 0x10 (ATA bus error)
[ 2.071679] ata1.00: status: { DRDY }
[ 2.075376] ata1: hard resetting link
[ 4.537398] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 4.563816] ata1.00: configured for UDMA/133
[ 4.563875] ata1: EH complete
[ 4.581413] ata1.00: exception Emask 0x10 SAct 0x2 SErr 0x10200 action 0xe frozen
[ 4.588926] ata1.00: irq_stat 0x00400000, PHY RDY changed
[ 4.594344] ata1: SError: { Persist PHYRdyChg }
[ 4.598898] ata1.00: failed command: READ FPDMA QUEUED
[ 4.604061] ata1.00: cmd 60/08:08:a8:88:e0/00:00:e8:00:00/40 tag 1 ncq dma 4096 in
res 40/00:08:a8:88:e0/00:00:e8:00:00/40 Emask 0x10 (ATA bus error)
[ 4.619613] ata1.00: status: { DRDY }
[ 4.623298] ata1: hard resetting link
[ 7.073395] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 7.074625] ata1.00: configured for UDMA/133
[ 7.074673] ata1: EH complete
[ 7.101461] sda: sda1
[ 7.118603] sd 0:0:0:0: [sda] Attached SCSI disk
[ 7.119786] sda: detected capacity change from 0 to 2000398934016
[ 7.120824] sda: detected capacity change from 0 to 2000398934016
[ 7.124345] Freeing unused kernel memory: 1024K
[ 7.133670] Run /init as init process
[ 7.133679] with arguments:
[ 7.133684] /init
[ 7.133688] with environment:
[ 7.133693] HOME=/
[ 7.133697] TERM=linux
[ 8.614356] axp20x-gpio axp20x-gpio: DMA mask not set
[ 8.621828] ata1.00: exception Emask 0x10 SAct 0x2 SErr 0x10200 action 0xe frozen
[ 8.622945] axp20x-gpio axp20x-gpio: AXP209 pinctrl and GPIO driver loaded
[ 8.629443] ata1.00: irq_stat 0x00400000, PHY RDY changed
[ 8.629460] ata1: SError: { Persist PHYRdyChg }
[ 8.639505] ata1.00: failed command: READ FPDMA QUEUED
[ 8.644749] ata1.00: cmd 60/08:08:00:00:00/00:00:00:00:00/40 tag 1 ncq dma 4096 in
res 40/00:08:00:00:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error)
[ 8.660369] ata1.00: status: { DRDY }
[ 8.664137] ata1: hard resetting link
[ 11.177427] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 11.178773] ata1.00: configured for UDMA/133
[ 11.178872] sd 0:0:0:0: [sda] tag#1 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=2s
[ 11.178888] sd 0:0:0:0: [sda] tag#1 Sense Key : 0x5 [current]
[ 11.178900] sd 0:0:0:0: [sda] tag#1 ASC=0x21 ASCQ=0x4
[ 11.178919] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x28 28 00 00 00 00 00 00 00 08 00
[ 11.178933] blk_update_request: I/O error, dev sda, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 11.189293] ata1: EH complete
[ 15.568456] ata1: limiting SATA link speed to 1.5 Gbps
[ 18.093501] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 18.096975] ata1.00: configured for UDMA/133
#4
A64 / Re: Battery wont charge
Last post by mauricio - June 26, 2026, 05:34:00 PMHello.
Yes you are right, some of the batteries come with diferent pinout position, but is not the case here, they are both the same and good for the A64 and A20.
Ok, I tried a new clean SD and image, same results, the "tic" is there.
Change parts, its just a last resort to try to get it back ... and to try my luck. I know its very hard to change in a good manner this small and BGA IC's.
I used AI to elaborate some tests, based on revision G schematic. By now, I'll remove L17 and L15, because they showing almost no resistance to ground, with them removed I'm specting to find if the A64 is short circuited.
Hopefully I'll came back with a happy end
Thanks
Yes you are right, some of the batteries come with diferent pinout position, but is not the case here, they are both the same and good for the A64 and A20.
Ok, I tried a new clean SD and image, same results, the "tic" is there.
Change parts, its just a last resort to try to get it back ... and to try my luck. I know its very hard to change in a good manner this small and BGA IC's.
I used AI to elaborate some tests, based on revision G schematic. By now, I'll remove L17 and L15, because they showing almost no resistance to ground, with them removed I'm specting to find if the A64 is short circuited.
Hopefully I'll came back with a happy end
Thanks
#5
A64 / Re: Battery wont charge
Last post by LubOlimex - June 26, 2026, 03:35:37 PM> Almost impossible to connect batteries reversed, they have jst ph connectors attached.
Yes, but the pinout assignments are not standard. Some batteries have the + and - in the jst connector swapped. You need to double check every different battery and match the + and - of the Olimex board - notice the on-board connector has white print "1" that indicates the "+" pin. But still it probably should just kill the charger circuit not alter it to work until certain point.
About the new problem - first try re-writing the SD card, some of the error messages might be due to corrupted image. Yes, chances are slim but it cost you nothing to first test with a fresh image or another SD card.
This sound that you hear can be also from some capacitor or inductor around the PMIC.
If you start changing the components first test all tests pads on the boards for the voltages; then inspect and measure around the components around the AXP803, finally try replacing the AXP803, we have it here:
https://www.olimex.com/Products/Components/IC/AXP803/
In any case double check why this might have occurred, since we test the boards with a battery here, chances of receiving board with such a problem are already really low and then having two like that is straight up impossible.
Yes, but the pinout assignments are not standard. Some batteries have the + and - in the jst connector swapped. You need to double check every different battery and match the + and - of the Olimex board - notice the on-board connector has white print "1" that indicates the "+" pin. But still it probably should just kill the charger circuit not alter it to work until certain point.
About the new problem - first try re-writing the SD card, some of the error messages might be due to corrupted image. Yes, chances are slim but it cost you nothing to first test with a fresh image or another SD card.
This sound that you hear can be also from some capacitor or inductor around the PMIC.
If you start changing the components first test all tests pads on the boards for the voltages; then inspect and measure around the components around the AXP803, finally try replacing the AXP803, we have it here:
https://www.olimex.com/Products/Components/IC/AXP803/
In any case double check why this might have occurred, since we test the boards with a battery here, chances of receiving board with such a problem are already really low and then having two like that is straight up impossible.
#6
FPGA / Re: SPI Programming Sequence f...
Last post by LubOlimex - June 26, 2026, 01:06:52 PMMaybe there is some parasitic powering via the SPI lines.
#7
FPGA / Re: SPI Programming Sequence f...
Last post by cdan - June 26, 2026, 11:11:24 AMHello,
sorry for the late response.
LubOlimex, thank you for the confirmation.
olin,
My modification implements the S_CMD_S_PIN_STATE command plus it pulls CRESET down before acquiring the bus and pulls it back high after releasing the bus.
I am using flashrom to read/write the Flash IC
The issue I have is that the communication between the iCE40HX8K board and my Pico is working as expected (I can read/write) if I first remove the power from iCE40HX8K, pull CRESET down then apply the power to iCE40HX8K.
If CRESET is pulled down while the iCE40HX8K board is powered on, the SPI communication stops working. Probing the SPI bus with a logic analyzer, during this setup, shows garbage being read from the Flash IC.
My iCE40HX8K is Rev. B
Regards,
Dan
sorry for the late response.
LubOlimex, thank you for the confirmation.
olin,
Quotecan you clarify what you try to do?Yes, I have a Raspberry Pi Pico on which I run a modified version of the https://github.com/stacksmashing/pico-serprog
a) program the Flash IC on iCE40HX8K via SPI?
My modification implements the S_CMD_S_PIN_STATE command plus it pulls CRESET down before acquiring the bus and pulls it back high after releasing the bus.
I am using flashrom to read/write the Flash IC
Code Select
flashrom -V -p serprog:dev=/dev/tty.usbmodem1301:4800 ...The issue I have is that the communication between the iCE40HX8K board and my Pico is working as expected (I can read/write) if I first remove the power from iCE40HX8K, pull CRESET down then apply the power to iCE40HX8K.
If CRESET is pulled down while the iCE40HX8K board is powered on, the SPI communication stops working. Probing the SPI bus with a logic analyzer, during this setup, shows garbage being read from the Flash IC.
My iCE40HX8K is Rev. B
Regards,
Dan
#8
A64 / Re: Battery wont charge
Last post by mauricio - June 25, 2026, 08:24:30 PMHello.
I had only one now, the other is with my customer (and see below please, now neither one).
Yes, I measured the input voltage at jack barrel 5.2V, and at pin1 on 40 pin connector 5V.
Almost impossible to connect batteries reversed, they have jst ph connectors attached.
I've tried olimex original 5v 1.2A transfo, another 5v 2a transfo, and an adjustable power source.
Sadly I was on the middle of this investigation when the A64 return this output through serial at boot
Since then, it wont work, I just can hear a periodoc "tic" comming from axp803 (guessing).
I'm now with the plan to identify burned components, aventually to purchase RAM, an A64 IC and an axp803 pmic to replace them.
If it doesn't work, you'll have me purchasing another olinuxino A64 ... I need this thing.
Thanks
I had only one now, the other is with my customer (and see below please, now neither one).
Yes, I measured the input voltage at jack barrel 5.2V, and at pin1 on 40 pin connector 5V.
Almost impossible to connect batteries reversed, they have jst ph connectors attached.
I've tried olimex original 5v 1.2A transfo, another 5v 2a transfo, and an adjustable power source.
Sadly I was on the middle of this investigation when the A64 return this output through serial at boot
Code Select
Starting kernel ...
[ 0.988284] sun50i-de2-bus 1000000.bus: Error couldn't map SRAM to device
[ 0.988831] sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO
[ 1.323668] sun8i-dw-hdmi 1ee0000.hdmi: Couldn't get regulator
[ 1.324092] sun4i-drm display-engine: Couldn't bind all pipelines components
[ 1.340432] sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO
Loading, please wait...
[ 1.855559] BUG: Bad page state in process udevadm pfn:4511b
[ 1.861950] BUG: Bad page state in process udevadm pfn:4517c
[ 1.944754] BUG: Bad page state in process udevadm pfn:bfbc5
[ 1.950715] BUG: Bad page state in process udevadm pfn:49eb4
[ 1.956618] BUG: Bad page state in process udevadm pfn:41080
Since then, it wont work, I just can hear a periodoc "tic" comming from axp803 (guessing).
I'm now with the plan to identify burned components, aventually to purchase RAM, an A64 IC and an axp803 pmic to replace them.
If it doesn't work, you'll have me purchasing another olinuxino A64 ... I need this thing.
Thanks
#9
New Products release / LoRa antennas, Desoldering pum...
Last post by olimex - June 25, 2026, 03:24:16 PMNew Products in stock: LoRa antenna, desoldering pump, PCB-holder, CH32V006 dev board, ESP32-CAM 8MB https://olimex.wordpress.com/2026/06/25/new-products-in-stock-lora-antennas-soldering-pcb-holders-ch32v006-riscv-dev-board/ #Lora #rf #riscv #esp32 #esp32cam
#10
A64 / Re: Battery wont charge
Last post by LubOlimex - June 25, 2026, 11:25:19 AMAnd you have two A64 boards behaving exactly the same when it comes to the charging?
Did you measure the input voltage at the boards when the battery is connected, is it 5V exactly? The power is applied to the power jack right?
Did you measure the voltages of batteries to see if the voltage reported by the Linux is the same as the voltage measured by voltage meter?
I did some test with A64 board (found revision G to be exact) and 3000mAh battery and it works fine:
You see my battery is nearing 4.1V which is higher the point your stopped, I use the same revision board and the same software. Which excludes a lot of of the things that might have went wrong.
The thing is I can't remember ever seen charging circuit failed in such a way that would charge batteries only half-way. Chances of board failed in such a way are slim, let alone two boards with the same issue (unless both boards got damaged in the same way, e.g. if you connected a battery with reverse polarity connector, but then again they won't charge at all, not just charge up to 44% or 66%). I would suspect power supply somehow can't deliver enough current and maintain voltage or somehow failed batteries. My guesses:
1. Bad external PSU / cable / barrel connector / input voltage at board
Measure 5V directly on the A64 board while battery is connected. PSU display alone is not enough.
2. Battery/protection/connector issue
Especially since both A64 boards behave the same. Test with new Li-Po. Double check Li-Po connectors.
3. Maybe try to re-write the base image and use the default config settings, remember to once reboot the software to load optimal defaults. Maybe try to increase the charge current:
Did you measure the input voltage at the boards when the battery is connected, is it 5V exactly? The power is applied to the power jack right?
Did you measure the voltages of batteries to see if the voltage reported by the Linux is the same as the voltage measured by voltage meter?
I did some test with A64 board (found revision G to be exact) and 3000mAh battery and it works fine:
Quoteroot@a64-olinuxino:~# cat /sys/class/power_supply/axp20x-battery/status
cat /sys/class/power_supply/axp20x-battery/voltage_now
cat /sys/class/power_supply/axp20x-battery/current_now
cat /sys/class/power_supply/axp20x-battery/constant_charge_current
cat /sys/class/power_supply/axp813-ac/input_current_limit
Charging
4097000
1394000
1200000
1500000
root@a64-olinuxino:~#
You see my battery is nearing 4.1V which is higher the point your stopped, I use the same revision board and the same software. Which excludes a lot of of the things that might have went wrong.
The thing is I can't remember ever seen charging circuit failed in such a way that would charge batteries only half-way. Chances of board failed in such a way are slim, let alone two boards with the same issue (unless both boards got damaged in the same way, e.g. if you connected a battery with reverse polarity connector, but then again they won't charge at all, not just charge up to 44% or 66%). I would suspect power supply somehow can't deliver enough current and maintain voltage or somehow failed batteries. My guesses:
1. Bad external PSU / cable / barrel connector / input voltage at board
Measure 5V directly on the A64 board while battery is connected. PSU display alone is not enough.
2. Battery/protection/connector issue
Especially since both A64 boards behave the same. Test with new Li-Po. Double check Li-Po connectors.
3. Maybe try to re-write the base image and use the default config settings, remember to once reboot the software to load optimal defaults. Maybe try to increase the charge current:
Quoteecho 1200000 > /sys/class/power_supply/axp20x-battery/constant_charge_current
cat /sys/class/power_supply/axp20x-battery/current_now