- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#1
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
#2
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
#3
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.
#4
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.
#5
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
#6
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
#7
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
#8
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
#9
A64 / Re: Battery wont charge
Last post by mauricio - June 24, 2026, 04:14:22 PMHello.
Capacity of first battery is 1000mAh. Second one is 3100mAh.
First one charges up to 66% at A64, 100% at A20. Second one 44% at A64, not tested on A20.
Yes, I did poweroff on A64 and look for current, regulated power says 0.001A.
When A64 is on, power or current doesn't go up. It stays ~330mA.
Thanks.
Capacity of first battery is 1000mAh. Second one is 3100mAh.
First one charges up to 66% at A64, 100% at A20. Second one 44% at A64, not tested on A20.
Yes, I did poweroff on A64 and look for current, regulated power says 0.001A.
When A64 is on, power or current doesn't go up. It stays ~330mA.
Thanks.
#10
A64 / Re: Battery wont charge
Last post by LubOlimex - June 24, 2026, 11:47:38 AMWhat is the capacity of the battery?
Is this the exact same battery used with A20-OLinuXino-MICRO (where it charges fully)?
Since you use external power supply, you can easily check if the battery is charging, check the power draw without the battery, and check again with the battery. If the battery is charging the current draw should be considerably higher.
Is this the exact same battery used with A20-OLinuXino-MICRO (where it charges fully)?
Since you use external power supply, you can easily check if the battery is charging, check the power draw without the battery, and check again with the battery. If the battery is charging the current draw should be considerably higher.