S805X 1GB version boots nice but not its 512MB brother

Hello everyone,
The stroy so far: I bought 2 “Lafrite” end of february, one 1GB ram and one 512MB ram. I received them mid march. Of course, I didn’t check, the “lafrite” doesn’t boot from an SDCard but an emmc module and I didn’t bought any.
But it is OK it can boots from USB. I try my luck with Armbian Light version on the 1GB version, it works fine I can reach a terminal, create a user and all.

So I try the 512MB version with the same install, I though it would work. But when it starts I get an error : ** Reading file would overwrite reserved memory **

Maybe the “installed” image does only work with a specific version, so I reflashed the same USB Drive and try to boot it up but I always get the same error (the one above).

I tried :

  • different version or Armbian
  • Raspbian

I use :

  • 3Amp 5V Power supply
  • Samsung Fit 128GB as Usb drive

If someone has an idea to help me out here I don’t have a clue about why the 512MB doesn’t boot.

I am not much help here, but have you tried the official Libre Computer image on this board? The error indicates an attempt to access an address in memory that it should not, hints of some incorrect or mis-configured details as they relate to memory addresses allocated for distinct purposes in the early stages of boot (i.e. attempts to prepare for loading the kernel – could be related to the version of u-Boot being employed in the Armbian image).

I too like Armbian, but sometimes wonder how much testing they can achieve with so many variants of SoCs that they produce images to support. It seems possible that the 512 MB variant of the La Frite may not exist in their test hardware inventory, which is just one guess as to how a problem like this might exist.

So, if you have not tried the official Libre Computer image for this board, try that one out…?

Good luck and let us know if you attempt this with the Libre official images and corresponding results.

I just tried the ubuntu server available on the libre computer website, and I got this error on both version of the lafrite :

And also tried the Raspbian-lite image :

I’m new to this, also ordered this board assuming it had microSD. The only image I’ve been able to get to boot on my 512MB model is ubuntu-22.04.1-preinstalled-base-arm64+aml-s805x-ac.img from 12/13/22 in the distro. I’m poking around at compiling an armbian image myself and see in their tool that the s805x is listed with 1GB of RAM.

Ubuntu base and server should both be supported.
Raspbian lite and desktop should both be supported.
Try flashing the latest bootloader. Burn the download to an empty flash drive and boot the device.

Are your boards different revs in addition to different RAM sizes? I also have a 512MB that’s V1.0A and is showing the same error on USB boot. My 1GB board is V1.0B, which has an additional NOR/eMMC switch next to the uboot button and came with the eMMC standoffs pre-installed, and it boots fine with the same USB flash drive.

Flash the latest bootloader onto the board and try. https://boot.libre.computer/ci/aml-s805x-ac-spiflash
You can use libretech-flash-tool on a Linux machine (or one of our boards) and flash an USB. Plug it into the La Frite board and let it update. Then try to boot the USB again.

I updated both boards to the 2021-07-r1 firmware. No change in behavior. Also tried booting from eMMC using an image that works on the 1GB board and get the same error.

Maybe Armbian’s builds only support the 1GB model or the V1.0B board. Is there an image confirmed to work on the 512MB V1.0A board?

2021-07-r1 is very old firmware. Use the link we provided.

Is it possible to flash that version with a uboot script or only with a direct USB connection?

Apparently the instructions at https://forum.loverpi.com/discussion/713/u-boot-firmware-guide-for-la-frite-aml-s805x-ac are outdated and there is newer firmware that needs to be installed in a completely different way.

I can’t figure out how to flash the spiflash file with libretech-flash-tool. All it does is download an ~800k bootloader file and write this to the device, which the board seems to completely ignore.

It would be nice if up to date documentation for this were in a single place that was easy (or even possible) to fine.

Writing the spiflash file directly to a USB drive (libretech-flash-tool is something completely different so I don’t know why it was mentioned in connection with that file) does make the board update itself. However it still does not boot the Armbian USB drive correctly.

The Ubuntu 22.10 image does work, so it is probably some compatibility problem with the Armbian build. But Ethernet does not work under ubuntu:

[ 254.129436] meson8b-dwmac c9410000.ethernet eth0: no phy at addr -1
[ 254.130085] meson8b-dwmac c9410000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
RTNETLINK answers: No such device

I’m starting to think the two 512MB boards I bought are destined to be nothing more than paperweights.

Armbian is not compatible with the device tree built into our firmware until Armbian updates to Linux 6.2+.

The issue is that the SPI firmware provides the latest device tree to Linux. Armbian is designed for an older kernel so it doesn’t know how to initiate the Ethernet port with the newer device tree. You have to get the system to boot from the Armbian firmware/bootloader instead of ours.

Flash Armbian to eMMC and then erase the SPI NOR. Erasing the SPI NOR also erases the built-in firmware and you will have to re-flash via pyamlboot if you want to boot from USB again. This is for experts only. Ideally Armbian provides the device-tree for their kernel version using a standard boot process. This is something you have to ask the Armbian devs to do to avoid the issue.

Thanks for the information about Armbian, it sounds like it could be something on their end. But I am not having Ethernet problems with Armbian (on the 1GB board where it boots). Using both the Ubuntu 22.04 and 22.10 images from Index of /ci/ubuntu/ the systems boots but the Ethernet device does not work on the 512MB board. 1GB board works fine.

Do you know if there are any differences between the V1.0A 512MB and V1.0B 1GB that would cause this? Are the current bootloader and OS images supposed to support both versions or was some support for the older board dropped at some point? So far the only thing I can do with the 512MB board is run Ubuntu with no network.

If you’re using the 2021 firmware you mentioned earlier, Armbian should work with ethernet.

If you’re using the latest firmware, you need Linux 6.2+ or have your image provide the device tree that came with the kernel in the standard search path.

You can also flash the image to eMMC (boot from USB, download the image, and dd to eMMC). The wipe the SPI NOR to have it boot from eMMC on V1.0A.

V1.0A is supported. There’s no change except adding the switch for boot selection to make it easier.

Like I said, Ethernet works with Armbian.

The two problems I am having with the 512MB board (which additionally is V1.0A) are that Armbian doesn’t boot at all, and Ubuntu, while it does boot, cannot find the Ethernet PHY.

The current images are from December before the Ethernet updates. We will be releasing new images this week and they should work.


Since between Linux 6.3 and 6.4 ethernet got broken:

Linux version 6.4.11-gcbd8a1d32bd1 (root@runner-yyhtcik-project-9705-concurrent-0) (aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT Fri Aug 18 21:49:16 UTC 2023
[    0.000000] Machine model: Libre Computer AML-S805X-AC
[    2.337786] meson8b-dwmac c9410000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[    2.340775] meson8b-dwmac c9410000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
[    2.349612] IP-Config: Failed to open eth0

could you refer to the patch which fix it (we need the specific patch, we use our images for Mesa3D CI testing)? I didn’t found any in nor stable or -next branch of Linux kernel.

Thank you!

Hi David,

There was a new implementation of the MDIO MUX for Amlogic GXL series. This fixes rarely occurring Ethernet problems with the old MDIO code.


This is both a DT change, config, and driver change.

Thank you for the link. The critical feature for our case is adjusting our config snippet. Since we boot directly from NFS, we have ETH driver compiled in. The new kernel option remained set as module (=m).

1 Like