EMMC not booting while SD does.

[dukla2000]

OK, methinks this is something to do with the "weird" setup of eMMC (at least to me).

My eMMC (from Pine) has 4 hard "partitions"

Code:

~$ lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mtdblock0     31:0    0     4M  0 disk
mtdblock1     31:1    0    32K  0 disk
mtdblock2     31:2    0   256K  0 disk
mmcblk1      179:0    0  14.5G  0 disk
└─mmcblk1p1  179:1    0  14.5G  0 part
mmcblk1boot0 179:32   0     4M  1 disk
mmcblk1boot1 179:64   0     4M  1 disk
mmcblk1rpmb  179:96   0     4M  0 disk
mmcblk0      179:128  0 119.3G  0 disk
├─mmcblk0p1  179:129  0   3.9M  0 part
├─mmcblk0p2  179:130  0    64K  0 part
├─mmcblk0p3  179:131  0     4M  0 part
├─mmcblk0p4  179:132  0     4M  0 part
├─mmcblk0p5  179:133  0     4M  0 part
├─mmcblk0p6  179:134  0   112M  0 part
└─mmcblk0p7  179:135  0 119.1G  0 part
zram0        252:0    0 165.9M  0 disk [SWAP]
zram1        252:1    0 165.9M  0 disk [SWAP]
zram2        252:2    0 165.9M  0 disk [SWAP]
zram3        252:3    0 165.9M  0 disk [SWAP]
zram4        252:4    0 165.9M  0 disk [SWAP]
zram5        252:5    0 165.9M  0 disk [SWAP]
nvme0n1      259:0    0 119.2G  0 disk
└─nvme0n1p1  259:1    0 119.2G  0 part /

Note the mmcblk1boot0, mmcblk1boot1 & mmcblk1rpmb partitions/things are all on the eMMC with mmcblk1p1. I suspect you all do not have this structure. And, I think, lacking the boot1 is why you cant boot from your eMMC. And, I think, the common denominator is you all got your eMMC from Ameridroid? And, I suspect, you may be able to get this structure by flashing an Android image onto the eMMC first?

<I stopped booting from my eMMC way back as the NVMe is faster. I was trying to reformat my eMMC as a single partition to use for data or something and noticed these damn "carbuncles" that I cant get rid of.>

[_fs]

Yes, I did get my equipment from ameridoid. Just checked, I also have the 4 blocks you posted for the mmc:

Code:

rock64@rockpro64:~$ lsblk | grep mmcblk1
mmcblk1      179:32   0 29.1G  0 disk
├─mmcblk1p1  179:33   0  3.9M  0 part
├─mmcblk1p2  179:34   0   64K  0 part
├─mmcblk1p3  179:35   0    4M  0 part
├─mmcblk1p4  179:36   0    4M  0 part
├─mmcblk1p5  179:37   0    4M  0 part
├─mmcblk1p6  179:38   0  112M  0 part /boot/efi
└─mmcblk1p7  179:39   0  3.6G  0 part
mmcblk1boot0 179:64   0    4M  1 disk
mmcblk1boot1 179:96   0    4M  1 disk
mmcblk1rpmb  179:128  0    4M  0 disk

[Takenover83]

Code:

root@DietPi:~# lsblk | grep mmcblk1
mmcblk1      179:0    0   7.3G  0 disk
├─mmcblk1p1  179:1    0   3.9M  0 part
├─mmcblk1p2  179:2    0    64K  0 part
├─mmcblk1p3  179:3    0     4M  0 part
├─mmcblk1p4  179:4    0     4M  0 part
├─mmcblk1p5  179:5    0     4M  0 part
├─mmcblk1p6  179:6    0   112M  0 part /boot/efi
└─mmcblk1p7  179:7    0   7.2G  0 part /
mmcblk1boot0 179:32   0     4M  1 disk
mmcblk1boot1 179:64   0     4M  1 disk
mmcblk1rpmb  179:96   0     4M  0 disk

Above is what my emmc currently looks like. I have never flashed a android image to it. That is not to say Ameridroid did not before selling it to me.

[dukla2000]

OK - bad assumption on my part (that you would be missing mmcblk1boot0 etc).

But, to stop my machine trying to boot from my eMMC it wasn't sufficient to clear mmcblk1p1-p7, I also had to clear mmcblk1boot0 and mmcblk1boot1.

To do that I had to disable the Read-Only bit:
su (or login as root - sudo did not work for me)
echo 0 > /sys/block/mmcblk1boot0/force_ro

I then did a dd if=/dev/zero there: you have to do the reverse probably dd a u-boot there. (Note the ro bit resets after a reboot so no need to revert it)
This page seems to be dealing with a similar challenge.

PPS - just discovered mmc-utils - have installed and busy playing with it to try fully clean my eMMC. Would imagine you can add uboot with it?

PPPs - cant find major use for mmc-utils except removing ro bit, guess you folks will still need to figure manual dd of uboot?

[Apokalypz]

It is most likely NOT the emmc card or an ameridroid specific issue. I had sent that emmc card back to ameridroid where he tested it with a working rockpro64 and the emmc worked for him. So it is likely a hardware failure on the board. I have a replacement rockpro64 being shipped to me after sending the bad one back and he said he couldnt get it to boot emmc either. He told me they are going to send it back to Pine. Hopefully they can find the issue and fix it for future production.

The strange thing is how it is seen perfectly once the kernel loads and puts the card in high-speed mode. It makes me think something is attenuating the signal at low frequencies. Or it's unable to switch to a higher voltage mode when running at the slower boot clock. My test showed the clock was 1.86V peak to peak at 24MHz at boot. I'm not sure if that is spec or not.

Either way, I get the replacement on Friday, so I'll test it out, see if it boots, and report back.

EDIT: I forgot to reply to the weird situation where a thumbdrive will "boot" the emmc image. This kinda happened to me while having an SD card in along with the eMMC (both have the same ayufan image). I think what happens is the bootloader loads the kernel off the non-emmc device (in this case a flashdrive) which then ends up loading the root filesystem off of the eMMC (which is now visible because the kernel is loaded.) because the partitions are loaded by their label not unique identifiers (which are all the same anyway if you use the same image on both the USB/SD and the eMMC.) I found that I could boot the kernel off the SD while loading the rootfs off the eMMC by changing the uuid of the root partition on the eMMC and changing the SD's kernel command line to load root from that uuid. As mentioned, it's a workaround, but not a very good one.

EDIT 2: In response to the boot0, boot1, and rpmb partitions. These (minus the rpmb) seem to be an alternative way to boot off of an eMMC to make flashing a bootloader easier for OEM. Every eMMC device after 4.something has these partitions as something called "alternate boot mode". Instead of putting the uboot and other boot bins on the main userspace area of the eMMC (/dev/mmcblk0), you can put them in a boot partition to keep it separate from the kernel and roots. The rockpro64 doesn't require the use of these extra partitions and instead loads the uboot and friends from the userspace partition.

[Apokalypz]

I just tested the new board and it boots off the eMMC without any problems! So it definitely is a board defect if the board won't boot eMMC. Ameridroid said they suspect the eMMC card connector might be at fault.

[Takenover83]

I somehow screwed my board up hooking a fan up. No longer boots anything :/
But I will have a new one from Ameridroid in a couple days. Hopefully it boots.

Edit: No go. New board and the emmc still does not boot.

[dukla2000]

I just tested the new board and it boots off the eMMC without any problems! So it definitely is a board defect if the board won't boot eMMC. Ameridroid said they suspect the eMMC card connector might be at fault.

Glad all is well that ends in your case.

Interesting Takenover83 report that the same eMMC fails on a different board as well. Earlier I was not throwing stones at Ameridroid - I was just wondering if they were unfortunate to get a contiguous batch of something bad.

[jnoxon]

I got my first RockPro64 today (ordered directly from Pine), and mine also will not boot from eMMC (I tried using etcher with both Ubuntu and Debian.) When I connect the serial console I get nothing but garbage out when I use Pine's adapter, and I get nothing at all when I use a FTDI adapter. Both adapters test fine with RX/TX jumpered together.

After seeing this thread, I decided to try using a microSD card, and it booted straight up. I guess there is no point trying to RMA this board back to China, but I am open to suggestions.

[mocara]

Hi,

Just received v2.1 RockPro64 board yesterday, together with NAS Case, 64GB EMMC card and SATA board.


For the first boot, I wanted to keep it as simple as possible.

I didn't order the USB/EMMC adaptor.  Instead as per Wiki and forum instructions I used Etcher on a Windows 10 PC to burn the latest Linux distro to an existing SanDisk 8GB SDCard.  Used apt-get to update software.  Once I was happy that RockPro64 booted from that, then added EMMC card and DD'd to it using instructions on this forum.

Removed SDCard and rebooted to make sure I was really booting from EMMC card.  I know a bit paranoid!!.  Again, used forum instructions to manually expand the file system.  All went fine for me, so next steps are to complete build with SATA board, and SSD's, then try the same approach but this time with the OMV build.

So far, so good.

Mocara