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.
ROCK5 Android12 Bringup Status Update
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.
any chance of having a newer build that really support booting from TF? current one seems only support eMMC boot.
Completely different on my side - I can connect Rock5 straight to usb-c ports on my thinkpad P52 or it’s dock station and rkdevtools update always finds it and there is no problem with power or so. Something for sure was changed because right now I can’t do the same with Rock3 (I still would like to get back my UART function).
any luck on getting android bootable on microsd?
Android has booted from microSD/TF card every time for me. It has booted from Nvme once, and I haven’t got it to do it again. Any update when nvme boot will be fixed?
which image are you using for sdcard booting?
I have booted it from both the 9/29 and the 10/19 versions so far.
Where did you find them? The latest I tried is 20221008 and there is neither 9/29 nor 10/19 available on the release page:https://github.com/radxa/manifests/releases
repo is at rkr8 with a uboot with no nvme support
the images are from a rkr10 bsp wich i dont see a raxda repo to see wich u-boot
the u-boot linux repo on raxda github has since 6 sept nvme boot function
sd ,emmc should just work only make sure that you format the sd before flashing a android image
first boot takes a longer time
ow would be nice now with the latest 5.10 kernel also rk356x could work on android 12
and a update would be nice so the mpp in android works with the latest kernel
You guys who have Android 12 up and running when you do the benchmarks are you getting anywhere near there initial postings for the GPU with Geekbench & Antutu ?
do i need special tools to format those sd card? i tried format those sd with exfat first with windows disk management, still no go (no hdmi output), image tested: 20220902(rkr8), 20220922(rkr10), 20221008 (rkr10). such issues doesnt persist on debian.
i havent check with serial console yet, but i think android might be bootable, just the display were not showing.
added: just checked with serial console, android is running of course, guess i need to sort out those no issue display then.
dmesg |grep -E ‘hdmi|mali’
[ 10.499935] rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy init success
[ 10.500101] rockchip-hdptx-phy-hdmi fed70000.hdmiphy: hdptx phy init success
[ 10.531739] rockchip-drm display-subsystem: failed to get hdmi0_phy_pll: -2
[ 10.531743] rockchip-drm display-subsystem: failed to get hdmi1_phy_pll: -2
[ 10.543607] dwhdmi-rockchip fde80000.hdmi: registered ddc I2C bus driver
[ 10.543761] rockchip-drm display-subsystem: bound fde80000.hdmi (ops dw_hdmi_rockchip_ops)
[ 10.544220] dwhdmi-rockchip fdea0000.hdmi: registered ddc I2C bus driver
[ 10.544351] rockchip-drm display-subsystem: bound fdea0000.hdmi (ops dw_hdmi_rockchip_ops)
[ 10.812400] rk_hdmirx fdee0000.hdmirx-controller: No reserved memory for HDMIRX, use default CMA
[ 10.812420] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_probe: cpu_aff:0x400, Bound_cpu:4, wdt_cfg_bound_cpu:5
[ 10.812897] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_audio_interrupts_setup: 0
[ 10.813623] rk_hdmirx fdee0000.hdmirx-controller: rk_hdmirx_hdcp_register success
[ 10.813640] rk_hdmirx fdee0000.hdmirx-controller: fdee0000.hdmirx-controller driver probe ok!
[ 10.992587] mali fb000000.gpu: Kernel DDK version g12p0-01eac0
[ 10.993198] mali fb000000.gpu: leakage=16
[ 10.995189] mali fb000000.gpu: pvtm=861
[ 10.995222] mali fb000000.gpu: pvtm-volt-sel=3
[ 10.995874] mali fb000000.gpu: avs=0
[ 10.997455] rockchip-dmc dmc: hdmirx_rate = 2112000000
[ 10.998090] W : [File] : drivers/gpu/arm/bifrost/platform/rk/mali_kbase_config_rk.c; [Line] : 136; [Func] : kbase_platform_rk_init(); power-off-delay-ms not available.
[ 10.998908] mali fb000000.gpu: GPU hardware issue table may need updating:\x0ar0p0 status 5 is unknown; treating as r0p0 status 0
[ 10.998930] mali fb000000.gpu: GPU identified as 0x7 arch 10.8.6 r0p0 status 0
[ 10.999023] mali fb000000.gpu: No priority control manager is configured
[ 10.999037] mali fb000000.gpu: No memory group manager is configured
[ 10.999064] mali fb000000.gpu: Protected memory allocator not available
[ 11.000878] mali fb000000.gpu: Couldn’t find power_model DT node matching ‘arm,mali-simple-power-model’
[ 11.000903] mali fb000000.gpu: Error -22, no DT entryle-power-model.static-coefficient = 1*[0]
[ 11.001292] mali f2, no DT entry: mali-simple-power-model.dynamic-coefficient = 1* mali fb000000.gpu: Error -22, no DT entry: mali-simple-power-mo11.002010] mali fb000000.gpu: Error -22, no DT entry: mali-simpl-zone = ‘’
[ 11.007357] mali fb000000.gpu: Using configured px-power-model, and fallback mali-simple-power-model
[ 11.0075u: l=10000 h=85000 hyst=5000 l_limit=0 h_limit=800000000 h_tablekchip-drm display-subsystem: failed to get hdmi0_phy_pll: -2
[ p-drm display-subsystem: failed to get hdmi1_phy_pll: -2
[ 11000.gpu: Probed as mali0
[ 11.030224] dwhdmi-rockchip fde8000 I2C bus driver
[ 11.031324] rockchip-drm display-subsystem: (ops dw_hdmi_rockchip_ops)
[ 11.033302] dwhdmi-rockchip fdea0 I2C bus driver
[ 11.034159] rockchip-drm display-subsystem: (ops dw_hdmi_rockchip_ops)
[ 11.050059] input: rockchip-hdmi0/devices/platform/hdmi0-sound/sound/card1/input2
[ 11.052060]1 rockchip-hdmi1 as /devices/platform/hdmi1-sound/sound/card2/in I : [File] : drivers/gpu/arm/mali400/mali/linux/mali_kernel_lin[Func] : mali_module_init(); svn_rev_string_from_arm of this malis ‘5’, built at ‘17:29:33’, on ‘Oct 8 2022’.
[ 11.104278] #
[ 11.104284] #1: rockchip-hdmi0
[ 11.104288] #2: rockchip-[ 12.881059] rk_hdmirx fdee0000.hdmirx-controller: hdmirx_cancel_cpu_limit_freq freq qos nod add
there is a custom one from a few months old
https://drive.google.com/file/d/114Zg7HHf56slNFcxfxPOf-RtbDz18dWP/view
and for newer raxda first has to update the repos it has been months since they updated it .
and just a image is just bad we cannot remove the bad rockchip code .
1 Like
I just see a new “NVMe only” Android 12 being available now, which you have to flash it via masked rom mode (or perhaps if you have a “removable” NVMe adapter?)
No time to play with it for these couple weeks, maybe I’ll try during weekend(s).
But it depends on whether the Android image can “see” my NVMe SSD in the first place…