Can you check with the latest kernel?
sudo apt update
sudo apt dist-upgrade
We had to revert some patches that broke other things. Can you please post here: ROC RK3328/RK3399 No Video on Monitor
I am completely new to the libre boards, but very well versed in the rpi world. Looking for alternate hardware options these days.
I have so far been completely unable to get any signs of intelligence from 2 brand-new le-potato boards. No matter what image I try, using rpi-imager, win32 imager, all I get is the solid red and blue LEDs. HDMI never turns on, just a lot of nothing.
Tried multiple dedicated USB power supplies that are known good and I don’t see the LED go out ever.
I have been following this page, but seem to be banging up against something fundamental.
Any ideas where I might be going wrong?
Probably flashed the wrong image? Did you download the right file with +aml-s905x-cc.img.xz and extract it before flashing?
Yes, I have been using the 2022-09-22-raspbian-buster-armhf+aml-s905x-cc.img.xz and 2022-09-22-raspbian-bullseye-arm64-lite+aml-s905x-cc.img.xz images, extract them with 7-zip to a folder where the img files reside respectively
I then burn them to a 16GB flash disk using win-32 disk imager. Extract the card and install in the OBC and power up. Blue and red leds only.
Tried a bunch of images, and finally found that the Armbian Bullseye CLI image will boot, so I know the hardware is good finally, but would like to understand why all of the raspbian images are not working.
Can you confirm on your hardware the images that are currently hosted are functional?
The only raspbian one I got any sign of life on (a barely perceivable green flicker) was the 2022-09-22-raspbian-bullseye-arm64-lite+aml-s905x-cc.img. Beyond this green flicker, no signs of life beyond the blue and red leds
I then burn them to a 16GB flash disk using win-32 disk imager.
MicroSD card or USB stick? USB sticks won’t work.
Can you confirm on your hardware the images that are currently hosted are functional?
The images are all CI’ed meaning that they’re tested before being uploaded to the server.
Please see the general troubleshooting page. Your issue is either flash corruption or power if more than one board is experiencing the same issue. The green LED should turn on if the bootloader was flashed correctly.
Same here. Exactly the same.
I was curious and had some time, so I did a quick check. I downloaded the latest 2022-09-22-raspbian-bullseye-arm64+aml-s905x-cc.img, flashed it to a new SanDisk Ultra 16GB card, and it booted right up first try, prompted me for the usual first-boot questions and is installing updates right now.
I personally use Balena Etcher to flash my images (which isn’t recommended), but other than that I have a pretty standard test setup. 2A tablet power supply for the Potato, Ethernet connection. Using a generic HDMI USB-C-powered monitor connected to a separate power supply, generic wireless keyboard/trackpad combo.
In the time it took to write the above, the updates finished and after rebooting I’m into Raspbian and it seems okay.
I verified the checksum of my downloaded image against the one listed in the SHA256SUMS file and it matches.
EDIT: Just went through the same test sequence with 2022-09-22-raspbian-bullseye-arm64-lite+aml-s905x-cc.img and it appears to work okay as well.
We don’t track Balena Etcher changelogs but previous version included some optimizations that screwed up images. To avoid said optimizations asking users what version they use, we just advise users to avoid it altogether. That said, the latest Balena Etcher will probably work fine.
Hi,
I am having the same issue here. I tried both methods: using the Raspbian imager & doing an image copy & adding the userconfig file & the empty ssh file.
I currently have access to HDMI monitors, to a USB pointer device (trackball, actually) but do not have access to a USB keyboard so I thought I might ssh from my laptop to set up various things. This implies I need some kind of a headless setup.
Do we perhaps need to use the lite image for this to work or am I missing something other step to get this to work. I would, at some point, need the full image rather than the lite. The install was on an eMMC and those steps seemed to work without problems; but like jtrmal, on the first run it still was asking me to set up an account.
Yes, even with the lite image this is not working. I got it to the point where I can reach it on the network (add the supplicant.conf file) but then I get the warning that:
Please note that SSH may not work until a valid user has been set up
And it is clear that there has been no such user set up on first boot (the password I set up for it does not work).
The file is userconf.txt or userconf and not userconfig.
Oops!
Now I feel foolish! 
But that’s an easy fix, so that’s very good. I definitely could not get it working from the Raspberry Pi Imager but it does seem to be working in this way.
Thanks!
Thanks for the report, we will check out the Raspberry Pi imager.
It looks like the files will work even with the full.
Yes, it should work for both. Can you please confirm that Raspberry Pi imager configuration doesn’t work for you? Are you able to use the tool and then check for the files after it finishes flashing?
OK. I seem to almost have things working the way I want on one board but I “broke” the setup on the other one so I tried doing the install again on that it.
For reference, I downloaded the ‘imager_1.7.3_amd64.deb’ file and installed the Raspberry Pi imager from that.
I did an eMMC erase.
I ran the script to make the eMMC show up as USB mass storage.
I used the imager and picked the ‘2022-09-22-raspbian-bullseye-arm64+aml-s905x-cc.img.xz’ image (so the full one).
There, in settings, I made image customizations setting hostname, checking ‘Enable SSH’ (set to use password authentication), set username & password, checked the configure wireless LAN box (I have a USB dongle) and entered those settings, set localization & for persistent settings clicked checked ‘Play sound when finished’ & ‘Eject media when finished.’ This was done with the image customization options dropdown list at the top of the dialog set as ‘to always use’. Then I clicked on the ‘Save’ button.
It didn’t put the obvious files (the obvious ones —the ones I used/altered when setting this up manually and that worked— are the userconf.txt, the empty ssh, the wpa_supplicant.conf and, under the /etc directory of the root, an altered hostname & hosts files), but it did place a script in the /boot mount (called ‘firstrun.sh’) that seems set to run first (it’s set that way in the boot parameters file) that included all of the information from the imager settings and that looks like it should do the right thing.
However, when actually booting the board it is still starting out by asking for localization information that should already have been set by the imager; as well as it asks me for a username.
P1 should be mounted at /boot/efi and not /boot if I am not mistaken as we prefer the normal setup paths on EFI systems. MicroSD vs eMMC shouldn’t matter.
Are you referring to these files you asked about?
It might be that I am looking in the wrong place.
When setting the board to be seen as USB mass storage, I get two new locations on my laptop (running Linux Mint). These are a boot location & a rootfs location.
Under the boot location, at the root of that, I can find the ‘firstrun.sh’ file that has been clearly customized by the imager.
Elsewhere, I have not found anything; but I don’t really know what I am looking for. If it’s something like userconf or userconf.txt, it doesn’t exist (under either boot or rootfs). If it’s something else (other than firstrun.sh), I do not know if it exists.
This is all after doing the imaging and before trying to boot it.
Booting, again, produces the dialog to set up the first user.
boot and rootfs are the partition labels, not the mounting points. You can find the mounting points in rootfs: /etc/fstab
Will check the firstrun.sh file and get back to you.
1 Like