Actually booting into android

#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.

#30

Right, I did this entirely through the CLI, never bothered with trying to find GUI tools for it.

As far as HDMI being connected, I haven’t had any issues there: first boot is a recovery boot - probably because the ‘metadata’ partition and such aren’t initialized in the image; from then on, it’s a normal Android startup, with HDMI working at boot time.

#31

do i need to do anything during recovery boot? without anything appear on the screen, i didnt know if it does something. tried press enter multiple time will just make the led stay green.
adb reboot bootloader didnt help too.

#32

OK, I messed around with this for longer than I’d like to admit… :-/

Here is what finally worked for me to get the Android image on SD card booting (make sure it is gpt).

Follow the super helpful steps outlined by Sarah (command line)… then… Android only boots for me if I have Debian installed on an nvme SSD on the Rock5 and then do a reboot from the Debian software… then I get into Android… otherwise it fails to boot. But hey, got into Android!

#33

Not sure if we are speaking about same issue, but I observed boot issues with android (blue led staying on forever).
At first I tought it was a mistake during sdcard setup, but then I saw it booting and failing again on reboot.
Didn’t identify cause yet. Will check if it has something to do with HDMI.

#34

Everything seems to have worked fine for me. The board acts the same as when I run Linux with the blue flashing light, just no video output. Tried waiting a bit before plugging in the HDMI but still no luck. Maybe something is up with the HDMI?