Hello,
i am trying get my Lime2 home server kit set up. SDD connected on SATA and battery disconnected.
The board is A20-OLinuXino-LIME2-s16M Rev.L
The SD card with A20-OLinuXino-buster-minimal-20210513-112230.img is not able to boot to Linux. It loads the u-boot script, kernel, ramdisk, overlays then there is a message "data abort" followed by reboot.
What could be the issue? Am i missing something?
Below is the serial console output.
U-Boot SPL 2021.04+olimex-1-20210507.081028 (May 07 2021 - 08:11:19 +0000)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
Loading configuration from EEPROM: OK
Verifying data: OK
Trying to boot from MMC1
U-Boot 2021.04+olimex-1-20210507.081028 (May 07 2021 - 08:11:19 +0000) Allwinney
CPU: Allwinner A20 (SUN7I)
ID: A20-OLinuXino-LIME2-s16M Rev.L
SN: 0001885E
MAC: 30:1F:9A:D0:CE:25
I2C: ready
DRAM: 1 GiB
SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
MMC: mmc@1c0f000: 0
Loading Environment from EXT4... *** Warning - bad CRC, using default environmet
Loading Environment from FAT... ** No device specified **
HDMI connected: Setting up a 1920x1200 dvi console (overscan 0x0)
In: serial
Out: vga
Err: vga
Allwinner mUSB OTG (Peripheral)
Net: eth0: ethernet@1c50000, eth1: usb_ether
starting USB...
Bus usb@1c14000: USB EHCI 1.00
Bus usb@1c14400: USB OHCI 1.0
Bus usb@1c1c000: USB EHCI 1.00
Bus usb@1c1c400: USB OHCI 1.0
scanning bus usb@1c14000 for devices... 1 USB Device(s) found
scanning bus usb@1c14400 for devices... 2 USB Device(s) found
scanning bus usb@1c1c000 for devices... 1 USB Device(s) found
scanning bus usb@1c1c400 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
2274 bytes read in 4 ms (554.7 KiB/s)
## Executing script at 43100000
Boot script loaded from mmc
Checking for /uEnv.txt...
Checking for /boot/uEnv.txt...
1156 bytes read in 4 ms (282.2 KiB/s)
Loaded environment from /boot/uEnv.txt
Loading FIT image...
15523843 bytes read in 860 ms (17.2 MiB/s)
## Loading kernel from FIT Image at 58000000 ...
Using 'config-8946' configuration
Trying 'kernel-1' kernel subimage
Description: Linux kernel 5.10.36-olimex
Type: Kernel Image
Compression: uncompressed
Data Start: 0x580000d0
Data Size: 6414152 Bytes = 6.1 MiB
Architecture: ARM
OS: Linux
Load Address: 0x40080000
Entry Point: 0x40080000
Hash algo: crc32
Hash value: a6e6e901
Hash algo: sha1
Hash value: 6791058a7c1ed71979ece1d244e3609d23327ecf
Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading ramdisk from FIT Image at 58000000 ...
Using 'config-8946' configuration
Trying 'ramdisk-1' ramdisk subimage
Description: Ramdisk for kernel 5.10.36-olimex
Type: RAMDisk Image
Compression: Unknown Compression
Data Start: 0x5861e14c
Data Size: 8654935 Bytes = 8.3 MiB
Architecture: ARM
OS: Linux
Load Address: 0x4fe00000
Entry Point: 0x4fe00000
Hash algo: crc32
Hash value: 0f2f8d73
Hash algo: sha1
Hash value: c17389d16b5b92de9f95871a5957f31fe9638137
Verifying Hash Integrity ... crc32+ sha1+ OK
Loading ramdisk from 0x5861e14c to 0x4fe00000
WARNING: 'compression' nodes for ramdisks are deprecated, please fix your .its !
## Loading fdt from FIT Image at 58000000 ...
Using 'config-8946' configuration
Trying 'fdt-3' fdt subimage
Description: unavailable
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x58e74584
Data Size: 43253 Bytes = 42.2 KiB
Architecture: ARM
Load Address: 0x4fa00000
Hash algo: crc32
Hash value: e4f82e0a
Hash algo: sha1
Hash value: bb32d6e6fcd23ba7ec8536766841d0e67abc0e0c
Verifying Hash Integrity ... crc32+ sha1+ OK
Loading fdt from 0x58e74584 to 0x4fa00000
## Loading fdt from FIT Image at 58000000 ...
Trying 'overlay-1' fdt subimage
Description: unavailable
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x58eca9a0
Data Size: 1001 Bytes = 1001 Bytes
Architecture: ARM
Load Address: 0x4fa10000
Hash algo: crc32
Hash value: d1d51f29
Hash algo: sha1
Hash value: fa0c14efb55dbe4bdf8aa7241a3e600b486e3ef6
Verifying Hash Integrity ... crc32+ sha1+ OK
Loading fdt from 0x58eca9a0 to 0x4fa10000
## Loading fdt from FIT Image at 58000000 ...
Trying 'overlay-2' fdt subimage
Description: unavailable
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x58ecae6c
Data Size: 436 Bytes = 436 Bytes
Architecture: ARM
Load Address: 0x4fa20000
Hash algo: crc32
Hash value: 00f3a93c
Hash algo: sha1
Hash value: efa518e1ffcc7c09a7d8010de6a7b363f1345b30
Verifying Hash Integrity ... crc32+ sha1+ OK
Loading fdt from 0x58ecae6c to 0x4fa20000
Booting using the fdt blob at 0x4fa00000
data abort
pc : [<7ef80ac8>] lr : [<00000011>]
reloc pc : [<4a015ac8>] lr : [<cb095011>]
sp : 7af3ebe8 ip : 00000000 fp : 7efdcd4c
r10: 00000020 r9 : 7af4aec0 r8 : 7af87c28
r7 : 6c616972 r6 : 00000010 r5 : e759e5a2 r4 : 7af87c28
r3 : 7af87c30 r2 : 7af87c20 r1 : 7af8af18 r0 : 00000019
Flags: nzCv IRQs off FIQs off Mode SVC_32 (T)
Code: d005 f027 0501 441d (686d) 07ed
Resetting CPU ...
resetting ...
P.S.
I tried the libreelec image which works ok as well as the "debianon" which is also ok apart from the ethernet interface. I would rather use "olimage" instead of having to deal with u-boot in "debianon" (https://wiki.debian.org/InstallingDebianOn/Allwinner#Olimex_A20-OLinuXino-LIME2_rev._K)
Thanks for your support
Can you try with the focal base instead, the archive is here:
http://images.olimex.com/release/a20/A20-OLinuXino-focal-base-20210513-112230.img.7z
This would help us narrow down if the issue is related to specific build and image or wide spread across all builds.
I have the same results with A20-OLinuXino-LIME2-e16Gss16M Rev.L and A20-OLinuXino-buster-base-20210513-112230.img.7z.
Following your suggestion, I tried A20-OLinuXino-focal-base-20210513-112230.img.7z, it is the same.
Can you share some pictures with us? Take pictures of your hardware setup and upload them to an image hosting web-site and post links here so we can understand the setup better. Make sure the pictures show everything connected, as when you try to boot (with power supply applied and all).
Will look into this.
I can make pictures but the setup is easy to explain. There are the following connections:
- 5V 1.2A power that I purchased with the board
- ethernet to my home network
- HDMI to 1080p HDMI monitor
- USB keyboard
- micro SD card in the board micro SD card slot
Or do you want pictures showing what is visible on the monitor? It would be easier for me to provide logs with a serial console but I don't know how to get that. Any suggestion is welcome.
I will redo it today but what I checked yesterday: all values in the final dump were exactly identical to the initial post except for one register. Beginning and ending on the log were almost 100% identical.
One more thing: I have just put the image on the SD card with dd without any option, let me know if anything else to do.
Try writing the image with the free version of Balena Etcher software, dd might require additional parameters to wipe the SD card clean.
I want a few pictures of the hardware setup. That shows the board, everything connected to it and the power supply.
Hi,
I am facing the same issue on the A20-OLinuXino-MICRO-e16Gs16M, with both A20-OLinuXino-buster-base-20210513-112230.img.7z and A20-OLinuXino-focal-base-20210513-112230.img.7z images.
My setup is as simple as this:
- A20-OLinuXino-MICRO-e16Gs16M Rev.L
- 12V/1.5A bench top power supply
- LCD-OLinuXino-7CTS
- Logitech K200 USB keyboard
- Ethernet connected to my home network
- 8GB Micro-SD card
The system boots correctly the first time and when I reboot, that's when things go wrong. I have one extra line of text, right before the "data abort" line there is one that says "EHCI failed to shut down host controller.". The rest above is the same or very similar, below it is exactly the same.
I have been trying to find the problem for a few days and don't have a clue of what it could be. After finding and reading this thread I have overwritten the SD card with
dd if=/dev/zero of=/dev/sdb bs=1M conv=fsync
to erase it completely before writing the OS image. No improvement.
I was able to successfully boot some older OS images on this board, repeatedly.
I hope this information helps finding the cause. I am looking forward for a solution too as I am trying to convert a 7 year-old project into the Olimage base.
Hi,
thanks for looking into it.
I could not find a way to upload an image here. It seems there is no such option.
So here are pictures of my basic setup. Please note - the battery is not and has never been connected by me.
1. Power cord, usb dongle for keyboard, hdmi cable, ssd connected from bay.
(https://webinutzu.spdns.de/s/P6DHrQkzqpZNcQW/preview)
2. Close-up of HDD connection
(https://webinutzu.spdns.de/s/DLS9xkB5yK2EQjW/preview)
3. top off
(https://webinutzu.spdns.de/s/baNXi6HeJk6CkWA/preview)
My current setup is based on debianon - which works fine so far: boots from SD and loads the kernel and rest of linux from SSD. I tested today again with the olimage and it fails to boot the SD or disk.
Next thing i will try is balena etcher for linux: i wonder what would be the difference? But one never stops learning.
I think there is a bug in latest release that stops boot process when you have a keyboard attached. Can you try to remove the keyboard during boot and connect it after 40-50 seconds?
I can confirm: if i boot without the USB keyboard it works as expected and I get a login prompt.
Thanks for sorting it out. But where did you find the indication for USB keyboard being the issue? I could not see anything suspect in the serial console log.
I received an e-mail from another customer and empirically tested it myself. During my tests I also discovered that mouse doesn't affect the boot, and neither the USB flash memory I had here, only keyboard causes it. Also it didn't exist in previous images, so it is clearly a software issue and regression. I've notified the Linux team and they are working on a fix.
Hi,
I can confirm the issue also goes away on my A20-OLinuXino-MICRO-e16Gs16M by disconnecting the keyboard.
Thank you.
Same behavior here. I need to disconnect USB keyboard (Logitech K120, either directly connected or via powered USB hub) in order to exit from the reset loop.
Image is A20-OLinuXino-focal-base-20210707-172415.img
It depends on the image because older raspbian images correctly boot with keyboard connected
It does not depend on the A20 (crossed tests with different images on 2 SD cards on 2 A20 boards)
I'll be glad to be notified about solutions or workarouds