ETA PRIME in new video get almost 650k points in ANTUTU benchmark on firefly itx 3588 board.
Video link: https://youtu.be/XrEmmXMXzXU?t=573
ROCK5 Android12 Bringup Status Update
3 Likes
Yes I’ve one already. It works quite well.
Still too early for me to test mainline linux but using bsp linux is a good experience.
Hi. Is there any status update ? Please share with us.
1 Like
没有更新状态进度了么？话说成品安卓12固件是否与正式版5B一统上线，安卓12固件是否也可nvme启动，谢谢。
I would also like to know if android can be booted from nvme.
Any usable Android 12 firmware for Rock 5B that I may just download and use (e.g. dd to TF card)? I can find Debian desktop and Ubuntu server auto-build images on github, but not Android.
Besides, if I want to look into building my own AOSP for Rock 5B, any tutorial available?
We do have it here, but last time I tried it does not boot from TF card(hang at boot screen for half an hour), but it boots from emmc just fine.
Wow thanks for the link! It says bootable from TF and eMMC now, just not NVMe yet 
I really prefer using Android for the time being, unless something like Elementary OS would start to support ARM based SBC like Rock 5B 
It seems to be a build env, so perhaps besides just download and use the image, I can also try to build it myself and learn about the build process.
It says bootable from TF, but last time I tried and I failed. It just shows the boot screen like forever.
Finally have time to try it, and you’re right that it is still not bootable with TF. So far I see no screen output at all with either my USB-C monitor, nor HDMI when I boot it from TF. Then I tried Debian to make sure my board really works (as it was newly received), and it is fine (boot from TF okay), though there are screen tearing (I hope with Android it would have no such issue). One catch is that there should be no m.2 SSD attached, as with one attached even Debian won’t boot.
So, maybe I would need to spend another US$10 to buy a 16GB eMMC? all images so far are 4GB uncompressed, so I think 16GB would still be sufficient, if I just want to use it to boot successfully. But of course, have ways to work on boot configuration should be better.
If you attached an nvme and it does not boot, probably you should check your power supply or your SSD’s power consumption. I have boot from emmc/tf card with the nvme plugged in just fine on debian.
The screen tearing comes from the very broken arm mali driver, hope it would improve over time and eventually we would have a better desktop on Linux. Android does not have screen tearing, but the default DPI setting is terrible and every thing is just way to big for a desktop screen.
16GB is okay if you don’t install some very space-consuming games on Android, if you do probably you will need 32 even 64 like a modern smartphone would have.
It connects direct to my monitor’s USB-C port which supply up to 90W PD, so I don’t think it would be an issue; I also tried connecting it to another 100W PD PSU and it just behave the same.
Thanks for letting me know that the it is the Mali driver’s issue
Yes, I that’s really the reason why I want to go with Android… but there is no way to set that just like Windows? Since I’m getting old, I routinely go for a larger icon / font size nowadays, so as long as it is not really “too big” then Android should be no issue to me.
What I’m thinking is to have an OS running on either TF (preferred) or eMMC and then data in m.2 SSD, with Android as the “desktop OS”, that’s why I am interested in starting up my Rock 5B with Android only. Just tried again with the setup that could start Debain but rewrite TF card with Android 12, but it does not work either. Maybe I should try out a few more like IPFire and see what works and what’s not.
do you know to where I should ask for help in making Android 12 works on TF?
I have attached serial, and found odd stuffs…
-
u-boot seems to have issue seeing mmc > (selective entries only)
U-Boot SPL 2017.09-gc060f28d70-220414 #zyf (Apr 18 2022 - 18:13:34)
Model: Rockchip RK3588 Evaluation Board
Trying to boot from MMC2
no mmc device at slot 1
mmc@fe2c0000: 1 (SD), mmc@fe2e0000: 0
Bootdev(atags): mmc 1
boot mode: recovery (misc) -
during kernel load > (selective entries only)
[ 11.612384][ T167] dwmmc_rockchip fe2d0000.mmc: IDMAC supports 32-bit address mode.
[ 11.615377][ T167] mmc_host mmc2: card is non-removable.
[ 11.627714][ T167] mmc_host mmc2: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[ 11.644321][ T203] mmc1: SDHCI controller on fe2e0000.mmc [fe2e0000.mmc] using ADMA
[ 11.668289][ T59] mmc_host mmc2: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
[ 11.710983][ T59] mmc_host mmc2: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
[ 11.763544][ T59] mmc_host mmc2: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
recovery filesystem table
=========================
0 /mnt/internal_sd vfat /dev/block/platform/ff0f0000.dwmmc/by-name/user 0
1 /mnt/external_sd vfat /dev/block/mmcblk0p1 0
exit=================
111
emmc_point is
sd_point is (null)
sd_point_2 is (null)
read cmdline
[ 13.029916][ T60] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000)
[ 14.607615][ T60] dwmmc_rockchip fe2c0000.mmc: Busy; trying anyway
[ 15.121669][ T60] dwmmc_rockchip fe2c0000.mmc: failed to set rate 100000Hz
[ 16.147509][ T60] mmc_host mmc0: Timeout sending command (cmd 0x202000 arg 0x0 status 0x80202000)
E:failed to stat /dev/block/by-name/misc try 1: No such file or directory
So, it looks like TF card is not “correctly identified”, like the boot process is looking at fe2e0000 while it should be fe2c0000 instead (fe2e0000 should be emmc I guess?)
Hope that there would be official Radxa Android 12 or 13 soon.
It is not correctly identified indeed. I tried to boot from the emmc and plug the tf card in, and Android seems does not seeing that sdcard at all. It looks like a platform support issue to me rather than a bootloader config issue.
Was thinking kernel param is wrong, but double checking it, it is passing right mmc addresses. Can’t do much as end user, so let others look into it first.
And you’re also right on the power issue: when my Rock 5B boots, using my USB-C power meter, I found that it will start at 5V@0.5A, then some time later AFTER kernel is loaded (maybe only after RK806 driver is loaded?), it would become 12V@0.5A (power negotiation completed).
Maybe my power cable is one sided and not “universal plug” or whatever, that in some cases Rock 5B will NOT negotiate PD, stay in 5V@0.5A then cannot finish boot process (to the point it normally hangs). Now I attached my m.2 SSD, and I found the boot process never get to a point where PD would be negotiated, and thus not enough power to complete the boot process. Maybe it is why NVMe boot is not supported yet?
@jack sorry to bother you here, but do you think there’s anything at your side that can be done?
About the PD issue: it was already identified in early builds that the PD negotiation took too long and the power source just cut the power. I think Radxa already added the PD negotiation ability to u-boot so that it could be completed before the kernel is loaded. From my own experience: the UART console would delay the negotiation and breaks the compatibility with a lot of PD chargers. My workaround is to connect GPIO pin 40, UART2_RTSN to the UART cable and it could boot with most PD chargers I have. If your UART cable does not have RTSN pin, simply disconnect UART and wait for a few seconds, when the LED blinking blue connect it back.
1 Like
Not very sure, but the u-boot build date was [ Apr 18 2022 ], so it may not have PD negotiation in u-boot code yet in the latest Android build; in terms of RK806 PD negotiation, based on what I see in the kernel log, the first entry is at [ 11.326173 ] and then the last entry before reboot is [ 12.146567 ], so it means negotiation takes >0.82 seconds? it sounds taking way too long indeed, but of course I have serial console attached. Too much testing, so I didn’t try to find out how it goes without UART attached to 5B.
I never see a cheap USB UART supporting RTS or CTS or alike (normally only Vcc, GND, TX and RX), so unlikely I can do what you’d said. Given that I am just an end user (i.e. at most I would do some testing), I think I would stop here for now, and see if Radxa would come up with something really work soon… and of course, Android 13 is even better if we can have that (it has better KVM support)
That u-boot build date is way to early to have PD support.
This commit added PD support to u-boot at July 28, 2022, about 3 months later than the u-boot you currently have.
tried to flash SPI with the latest image by following the tutorial, but it cannot be done via either my desktop (AMD) or laptop (Intel Thinkpad)… with Ubuntu 22.04 on my laptop, I failed at uploading the loader; then I tried using my Windows VM with PCI passthrough USB controller, I can finish the loader part, but right after it is successful, the masked ROM is not detected anymore; the same also happen when I use my desktop which runs 22.04 as well. so, basically I cannot proceed anymore…
forget to say… another “funny” thing is that if I connect Rock 5B directly to my machines’ port, masked ROM mode is never detected; if I add a USB hub in between, however, masked ROM can be detected. but as mentioned above, I cannot complete the SPI flash either… I tried using Thinkpad’s “charger port” that always output up to 5V@2.4A, and my USB meter tells me it only use around 200mA in masked ROM mode, so it should not be that not enough power provided during the flash process, but still it fails.