Actually booting into android

#10

Do you mean an nvme reader? The current image only works by using the rkdeveloptool to flash the image from maskrom mode directly to the nvme installed on the rock 5B, so a usb to nvme reader is not needed

#11

There are two image formats with different suffix in the image name:

  • rkupdate image: it’s the rockchip private format, you need the RKDevTool to flash it. This image format doesn’t support dd to SD card. To flash this image, you need to go to the Upgrade Firmware tab and choose Firmware button to load and Upgrade button to flash.

  • gpt image: it’s the raw image that you can mount on your PC, you can just use dd to write the image to SD card or eMMC module to boot, you can also use the RKDevTool Download Image tab Write by Address to write it from USB OTG.

Currently the Android NVMe image released only support rkupdate format. Please pay attention to the image suffix when flashing the image.

1 Like
#12

A little bit offtopic: Is there a debug port to see what the error is?

#13

When I try this it never switches to nvme storage, it writes something to spi and waits for loader the errors out, does the nvme drive need to be a specific format? There are so many extra veritables that are just not covered in tutorials.

1 Like
#14

I got mine on the nvme using RKDevTool_v2.93 and ROCK-5B-Android12-rkr10-20221103-spi-nvme-rkupdate.img it shows Rock Kernel and than hangs. Not sure if my cable can handle 4K because it defaults to 4K output.

#15

same here (but with 1440p screen) and many problems afterwards: MASKROM operations error/fail

#16

Yeah I get weird resolution issues too, I have had to not have a HDMI cable connected on boot at times.

#17

any known working way to boot android from SD card (without mmc nor nvme plugged in)?
I’ve tried both writing this image ROCK-5B-Android12-rkr10-20221008-1808-gpt.zip with etcher or dd command but still not booting.
I only manage to boot linux image from that sd.

#18

Use dd to put it on the SD card. Get one of the -gpt images.

Once it’s on SD, edit the partition table:

  • Use gdisk to create a new protective MBR. Save and exit.
  • Use gdisk again to write the existing partition table. It’ll ask you if the EFI footer can be moved; let it do so.
  • Delete and recreate userdata. Make sure it’s partition name in the EFI table is “userdata”.

Once you’re done there, format userdata with a new ext2 volume.

Reboot and it should come up to Android. (It worked here.)

4 Likes
#19

thanks for your help. will try that and see how it goes.

#20

Any chance you could share the actual commands?

#21

Replacing /dev/sde with the block name of your SD card:

$ sudo dd if=ROCK-5B-Android12-rkr10-20221008-gpt.img of=/dev/sde bs=1048576 oconv=sync
$ sudo gdisk /dev/sde
Go to expert mode and replace the protective MBR: it’s only for a 4 gig image, we have a larger piece of media
Command (? for help): x
Expert command (? for help): n
Expert command (? for help): w
It sees the secondary header is in the wrong place. Let it move that header.
Warning! Secondary header is placed too early on the disk! Do you want to
correct this problem? (Y/N): y
And then let it write the adjusted protective MBR + gpt secondary header
Do you want to proceed? (Y/N): y
$ sudo gdisk /dev/sde
Now that the GPT table is fitted to the media, adjust the userdata partition. Delete it and then recreate it, since GPT fdisk doesn’t include a “change end” command
Command (? for help): d
Partition number (1-14): 14

Command (? for help): n
Partition number (14-128, default 14): enter
First sector (34-124704734, default = 8366080) or {±}size{KMGTP}: enter
Last sector (8366080-124704734, default = 124704734) or {±}size{KMGTP}: enter
Hex code or GUID (L to show codes, Enter = 8300): enter

Command (? for help): c
Partition number (1-14): 14
Enter name: userdata

Command (? for help): w
And accept the warnings
Do you want to proceed? (Y/N): y

Now create an ext2 filesystem on the new userdata volume
$ sudo mke2fs /dev/sde14

Then take the SD card and toss it into your Rock 5B.

Edit to include: it might take a moment to come up on the first boot: the first round, it seems to boot into recovery, and then it boots into system.

5 Likes
#22

Thank you! I assume I can flash eMMC using the same method too?

#23

I would imagine so. I did much the same thing through an Android root shell from the SD card boot to the eMMC boot.

There appears to be one catch, and that’s that Android will boot partially from eMMC and partially from SD if both contain an Android style partition table, with Android’s “super” partition on eMMC and userdata on SD.

#24

Thanks for these detailed steps, was really helpfull as I’m not an expert in partitioning from cmd line.
Just a question for last step, when creating ext2 FS on userdata.
Currently my SD is /dev/mmcblk1. After following your steps, I can print from gdisk, the different partitions:

Number  Start (sector)    End (sector)  Size       Code  Name
   1            8192           16383   4.0 MiB     8300  security
   2           16384           24575   4.0 MiB     8300  uboot
   3           24576           32767   4.0 MiB     8300  trust
   4           32768           40959   4.0 MiB     8300  misc
   5           40960           49151   4.0 MiB     8300  dtbo
   6           49152           51199   1024.0 KiB  8300  vbmeta
   7           51200          133119   40.0 MiB    8300  boot
   8          133120          385023   123.0 MiB   8300  recovery
   9          385024         1171455   384.0 MiB   8300  backup
  10         1171456         1957887   384.0 MiB   8300  cache
  11         1957888         1990655   16.0 MiB    8300  metadata
  12         1990656         1992703   1024.0 KiB  8300  baseparameter
  13         1992704         8366079   3.0 GiB     8300  super
  14         8366080       249737182   115.1 GiB   8300  userdata

but when listing from shell, I only see two partitions: p1 and p2

rock@rock-5b:~$ ls /dev/mmcblk1*
/dev/mmcblk1  /dev/mmcblk1p1  /dev/mmcblk1p2

how do you manage to create FS on 14th partition?

#25

On the Rock5 itself, I’ve noticed the SD is always mmcblk0 and eMMC is always mmcblk1.

In either case, when you wrote the partition table on mmcblk1, did you get a notice indicating that the table may not be in use by the kernel yet? It’s possible that some partition was automounted off of the device, and since the media is busy, Linux won’t re-read the partition table.

Options here:

  1. Reboot the machine. This will typically take care of it, but remember the caveat I mentioned above.
  2. Make sure everything on mmcblk1 is unmounted, then force Linux to re-read the table. This can be done with gdisk again (run gdisk on the media again, then save and exit) or with partprobe (which just informs the kernel that it needs to check the partition table again).
#26

exactly, I just rebooted and can now see the 14 partitions as expectede, seems like it was sync/refresh issue.
gonna run last command and check if android launch

#27

Just rebooted, but for now doesn’t seems android is running. At the beginning can see green/blue leds flashing. After a while blue stays on forever but I don’t see any video output.

Tried unpluggin peripherals like NVMe and wifi card to be sure wasn’t hardware related but didn’t change anything.

Will restart from beginning (redoing previous steps) in case something wrong happened.

#28

2nd attempt: SUCCESS :slight_smile:
not sure what happened the first time, now I see android launching as expected.
Thanks a lot for your support, now having Linux on NVMe, and Android on SD :slight_smile:

2 Likes
#29

OK so I managed to boot android from eMMC using your method, but I think that (as for other people as well), the HDMI cable needs to be disconnected to boot. Or maybe it just didn’t work at first. I will need to figure it out.
Also, after creating the protective MBR in gdisk I just resized partition 14 in the gnome-disks GUI - no need to remove and recreate it.