After attaching power, the Red and Blue LEDs should light up. This indicates that the board is powered. Nothing will show up on HDMI or CVBS yet.
At no point after attaching power should the Red LED blink or turn off. If this happens, it means that your power supply is inadequate. Please make sure that you are using a 5V power supply capable of supplying at least 1.5A (1500mA). Not having enough power could cause spontaneous reboots or software errors.
The board will try to read the bootloader from the eMMC and then the MicroSD card from sector 1 (512B). If the correct signed bootloader is detected, the board will begin loading it and turn the Green LED on. If the Green LED does not turn on, it means that the software is not properly flashed onto the storage device.
After about 3 seconds, the bootloader should turn on HDMI and displaying the loading sequence. Certain types of displays with odd resolutions are not supported at this stage and it might not display anything during this step and the next steps. If the Green LED turns green and nothing shows on your screen, please post your screen brand, model, and EDID here.
The bootloader will attempt to EFI boot from a list of block devices:
eMMC
MicroSD
USB Flash Drive
It looks for an FAT/EFI partition with /boot/bootaa64.efi, loads the file into memory, and executes the it. On our images, bootaa64.efi is GRUB.
Can eMMC and uSD checks be reversed, such that it checks uSD first, and then eMMC next? This will be easier to recover from an unbootable eMMC when the potato is stuck in a case.
No, eMMC takes precedence. Just mount the eMMC and delete the boot area from sector 1 to 2048 and leave sector 0 with the MBR partition table in tack to boot the MicroSD.
This doesn’t really solve dual-booting, or quick recovery if the primary system is installed to emmc and gets corrupted further in the boot process - preventing a useable system or a state where the emmc boot can be deleted.
Hopefully a future version will give boot preference to the uSD card, allowing quick override of emmc boot when a bootable uSD is present.
I’m not sure what is going on then… with my S905X-CC, it will get stuck in a boot loop when a USB is plugged in… I assumed that was a search for some kind of USB boot? If I knew how to stop that it would be great, as it would enable us to do a remote reboot while leaving USB drives plugged in.
Might be an power issue. The board will provide up to 1A per USB stack as long as the power supply is good. In your case, it might not be so try using a powered USB hub.
I got a boot screen I simply must grab… had a few Atmel chips connected through the hub like you said. But, then I connected a USB drive to that same hub and the boot loop started… this time much slower. So I got an HDMI screen, plugged in, and the output was garbled; but something looking like a GRUB boot screen showed up. I couldn’t read the text, need to find a new screen with right HDMI input… but I do plan to get to the bottom of this now.
u-boot’s USB support is not as robust as Linux. It is what you see until after GRUB launches Linux. Sometimes certain devices do not enumerate properly in u-boot causing boot delay issues. This improves with every passing version of u-boot but could also be a cause. If you have garbled HDMI, do report your monitor information on this thread: AML GXL No Video on Monitor
In that case, I think I have pinned down the exact Drive that is the problem, was picking them up from Costco:
SanDisk NVMe 1TB Extreme Portable SSD - Model SDSSDE61-1T00-AC
Anyways, Thanks for what you do. Keep up the good work. I can see this stuff is getting complex…
No pressure. For now I’m putting the USB line through a relay closed by LePotato’s GPIOs after full boot and user login.
Some of these portable drives are designed for 1.5A power consumption which exceeds what the USB stacks can put out. USB 2.0 normally provides 0.5A and USB 3.0 provides 0.9A. Le Potato provides up to 1A per stack. That drive requires CDP current levels so that is probably why it enumerates improperly. We recommend going with eMMC for the reason that it provide very good performance while not using much power.
Still can’t find a screen that shows a good output while data lines to the SanDisk are connected… But the GPIO to relay to USBHub to Drive method works great.
I got a little extra security out of the deal by forcing a legit login before anything can get to that drive.
And if it is not broke, don’t fix it.
I did… And I would strongly recommend anyone with hardware boot issues to use the same method an 8 Channel DC 5V Relay Module with Optocoupler is only ~10$ and this LePotato has the power to turn them all on. Why not do it that way? Not that you will need to turn them all on at boot time. Anyways, I would like to work on getting one of these things running Guix. I assume opening a topic on that would be in Software.
Luke, I had the same issue, it drove me nutz, until I found the solution in a raspberry pi forum somewhere. I had downloaded the OS, then flashed it to SD card, and then I got the reboot loop problem. You have to unzip of unpack the downloaded OS, and THEN flash the SD card. I did the same stupid thing! the zipped or compressed file WILL flash to SD card, but it’s missing the boot stuff!