Unable to restart Alta boards via software. Only through power removal and reconnect

General
, ,
1

Hi everyone,

I got my 2 Alta boards yesterday and I’m having an issue.

I am using the 23.04 Ubuntu images. I am powering my boards with different power supplies to test, including $80 gan and even official raspberry pi supplies.

I am using good quality Samsung evo micro sd cards. I write the images with the win32 imager. (Although I’ve tried etcher and the raspberry pi one to test) I have tried the basic package as well as the desktop image.

So, I think I’m covering all the bases. I’m really trying to do it right. Although, I haven’t tried any other distros like Debian.

I can boot ok. I get to desktop ok. It seemed very flakey when it came to network connectivity. It would frequently disconnect from the network. (This is a wired 1gig connection)

To try to combat this in case there was an ip conflict, I manually assigned an IP.

The issue is, when I restart the boards, it will get into a state where it times out reading the pxelinux.cfg file. And it will take 10 minutes and then just quit and enter into a hung state.

I’ve tried to search around but I’m not sure where to go so apologies.

Have there been any reports of anything similar or can you suggest anything?

IMG_8192
IMG_81923024×4032 2.01 MB

2

I am using a different sd card and put raspian on it from earlier in the month.

My method is to download image. For instance:

https://distro.libre.computer/ci/ubuntu/23.04/ubuntu-23.04-preinstalled-desktop-arm64%2Barm64.img.xz

Extract the img file using 7zip.

Use win32diskimager to put on the Samsung cards.

Unfortunately, with Debian, It’s the same process.

Works fine on a fresh power cycle, but fails on a soft restart.

IMG_8202
IMG_82023024×4032 2.13 MB

I would think it’s the sd card because of the lines: “card did not respond to voltage select!” But it works just fine on a hard boot.

3

Hi, I just received my Alta and tried powering it up for the first time today as well.
For reference, the label printed on my board is AML-A311D-CC-V1.0C.

The first time I powered it on, I tried it with no SD card (or EMMC card) attached, just to see what it would display on the debug port. The messages displayed looked pretty much like what you are showing above.

Next, I flashed an SD card with the latest Raspian release from Libre’s Distro Server (2023-10-10-raspbian-bookworm-arm64-full+arm64.img.xz, dated 2023-Dec-03). I inserted the SD card in the Alta and powered it up (I noticed that the SD slot is not spring-loaded - you just push the card in and there is no latch or anything - this is not like the Le Potato or Sweet Potato boards). It powered up and I was able to get to the desktop.

I was able to reboot by issuing a sudo reboot command from the terminal, or by selecting “Logout” and “Reboot” from the Rasberry Pi Menu in the Desktop. I rebooted a couple of times without issue.

However, my Ethernet also appears a little flaky…
The first time I booted (even without an SD card), the DHCP service was able to get an IP address from my router. I could see it connected in the Router’s admin screen. I assigned it a reserved IP address in the router and the board updated to use the new address. But, after I tested the re-boot sequence a couple of times and was in the Raspian desktop, I noticed that it kept popping up messages about the network being unavailable. ifconfig did not show any IP address at all.

Doing a full shutdown and completely removing power from the board, then restarting seemed to have fixed the Ethernet, but I will have to keep an eye on it.

Anyway, you may want to verify that you have the latest version of the SPI flash firmware installed. These can be found here: https://boot.libre.computer/ci/.
As of today, the latest firmware is dated Dec 14, 2023. Surprisingly, it appeared that mine was already up to date. Maybe yours is not?

See this post for details: https://hub.libre.computer/t/libre-computer-board-bios-firmware-update-images/3113.

If that doesn’t do it, you might want to give the Raspian OS a try. Your symptoms don’t sound like an operating system problem to me, but I’m no expert.

-Good Luck!

4

Thanks for your reply!

I tried raspian but I agree, I don’t think it’s the OS. I think it’s on reboot, it’s unable to read the sd card.

But on Ubuntu, it didn’t same thing as yours. It would download, say new update, get 5 seconds into it and say “network unavailable. “ and then 2 seconds later “network unavailable”

I appreciate the link to the firmware update!

This may sound remedial, but how do I update it? I tried to put it on a usb with JUST that file in it, stick it in one of the usb ports, but there is no response on boot to it. (I’m removing the os sd card. )

5

Ok. I figured out how to flash the bios. Looks like I already had the updated one on both boards.

It looks like I also figured out that:

Despite working just fine on raspberry pi’s, the Samsung evo cards will not come out of a soft boot on these boards.

I over nighted a Samsung extreme card (the gold ones) and they work just fine. I can reboot all day long on them.

Oi vey.

6

Glad you got it working.

The only card I tried so far in this board was a Samsung Pro Plus (Blue one) purchased through Amazon. It’s Class 10, V30, A2, U3, so should be pretty fast and Samsung is supposedly a good brand name.

I know that Libre has a few posts where they say that some SD cards can be problematic and they recommend only using high quality cards. But, I’ve used a mix of Samsung, PNY, and Lexar cards of various speeds on the LePotato and Sweet Potato with no noticeable issues so far.

I haven’t seen any more Ethernet problems since I posted last. I did discover that audio over HDMI doesn’t seem to work. Haven’t figured out why yet. I may start a separate thread to get help on that if I don’t figure it out soon.

1 Like
7

Okay so how to flash the Bios? Please do tell?

8

The issue is that the MicroSD card maintains VDDIO and turns off VCC on shutdown. Some SD cards will leak power from VDDIO to VCC, keeping the card in a half on state when it should be off. We mitigated the issue by lowering the VDDIO during certain kinds of reboot like shutdown/start but reboot uses a different power sequence that we do not fully control. We are looking at improving the situation for cards that have this behavior.