I just received my 5A today, plugged in hdmi and power and … nothing. No blue LED, nothing on the screen, no activity as far as I can tell. I also bought a 16G eMMC module onto which I flashed the Dietpi image, zero activity whatsover.
I see the 5B board has a maskrom mode which would then be picked up by the computer to verify the board is not dead, but the 5A has no such feature(?).
Did I get a dead board or did I skip a step?
[updated details]
I’m using the 30W power supply and usb-c cord that raxda sells
Sigh, stupid user error. I mistook the dietpi image for the 5B, not compatible with the 5A. Bloated debian image seems to be booting just fine. Sorry for the false alarm. Thank you.
There is no such thing as bloated Debian. Its Debian image with more or with less starting packages. I guess then bloatware and sales BS must be coming from Dietpi. Point of open source is that work is done together, with common goals and code is reviewed, so BS is not spread really far … here even htop is patched to fool you … why do “developers” needs to patch htop? To support ideology or to add real value? If Debian is bloated, then Dietpi is super bloated.
Don’t mind me, I come from Gentoo where computers have exactly what software I want and nothing more. Given that the stock debian image I’ve just installed for this rockpi 5a clocks in at 5gigs and the last dietpi setup I did was barely 1gig, you’ll have a hard time convincing me there isn’t unnecessary software included with the stock debian image FOR MY USECASE.
Anyways. After writing the B16 Debian image to emmc and booting it, it hangs with ext4 file corruption and the root partition is read-only. Reflashed the emmc a second time, verified the file system before putting it in the 5a, and it still ends up corrupting itself and going read-only on first boot. Just tried reflashing a third time and sure enough, read-only root partition after ext4 corruption on first boot.
Buildroot and Yocto is better way for that, but perhaps too complicated from end user perspective … Gentoo is trying to do something else, but I get your point.
If you want nothing more, then you should look what Dietpi provides without shame … Even calling home comes by default.
Comparing desktop images from vendors with server image is a terrible justification. Compare minimal Debian or better minimal Armbian, where Dietpi is taking the value from. Kernel / firmware is everything that is important and they are doing exactly nothing regarding this even they claim “support”. The rest is Debian packages + excessive branding, suspicious scripts / art that has nothing to improve OS functions. If some hardware related function (all what actually matters, the problem you have) works or not, its not related to Dietpi and often not to HW manufacturer (this forum) as hardware interface is not maintained by them.
5A does have maskrom mode, but it’s tricky: you need to short two pins (in fact, holes), and use a USB-A to USB-A cable together with power… More info here.
I’m going to RMA this 5A because it’s clear there’s something wrong. It consistently corrupts the file system on every boot. I’m pretty sure it’s the 5A because I can read & write the eMMC on my pc (through the eMMC-SD card adapter) all day and it doesn’t have any problem. But place the eMMC on the 5A and it’s corrupted.
I’ve even tried the Android image, and it too corrupts the various partitions on first boot (which never completes)
Now this is interesting: I’ve got exactly the same problem with my unit, eMMC file system always gets corrupted on the first boot!
When I use microSD card, everything’s fine though…
I did put it back but are you sure it wont boot without it? I flashed the B16 radxa OS onto a microSD and it boots fine without the SPI module installed. Doesn’t corrupt itself either like the eMMC does.
Been using TF card on 5A just fine until I switched to eMMC and I found similar file system corruption. It usually happens shortly after the system starts, such as when using apt update. The eMMC module works fine on Rock 5B. I also tried the latest kernel “5.10.160-rockchip-rk3588” with no luck.
It kinda feels like it’s getting corrupted anytime there’s a write operation (those are buffered and cached, of course, which is why it takes a few seconds before queued writes are flushed).
idk if this was said here already but u do realise that the emmc that comes with the rock 5a is not an freely emmc for storage but an spi flasher thing ?
Meaning you need your own / other emmc to flash in your Rock 5A image.