How to Write an Image to the eMMC Module Tutorial

[MarkHaysHarris777]

I edited your previous post to put your logs in a code block;  always do this please, it makes reading your post much easier for everyone.  thanks.

---

Why installation is not done by just like this:
1) insert an SD card card with the "minimal" linux.
2) snap an empty eMMC in
3) turn the board on, boot from SD
4) download an image and flash it into eMMC by that smartass script.

I know it's obvious and hardly nobody could think of it before, rather there are some obstacles to do so. What they are?

Hi, the reason your simplified approach will not work is that boot precedence and eMMC initialization create two problems which prevent it.  If there is an image on the eMMC already, then the eMMC will boot 'first'.  If there is no image on the eMMC then either the machine will not boot, or if it does boot,  both devices will not be 'seen' by the OS during initialization; both mmcblk0 and mmcblk1 must be present, AND the machine has to be booted from SD.

The jumper used has one function,  it grounds the clock line of the eMMC, deactivating it temporarily;  that way the SD card will boot-up because (for all intents and purposes) the eMMC is not there.  We interrupt the boot-up at the uboot timer and then continue the bootup with the jumper removed--  this allows the boot-up to continue on SD, but also allows the OS to 'see' the eMMC module during initialization.

Thanks for the question.

Seems I'm missing something here because

booted from sd



Can you enlight me?

What is your question , please ?

[z4v4l]

Thank you, Mark, for the response.

If there is no image on the eMMC then either the machine will not boot, or if it does boot,  both devices will not be 'seen' by the OS during initialization; both mmcblk0 and mmcblk1 must be present, AND the machine has to be booted from SD.

Is this a current linux/uboot limitation? I can't see any other reasons for both devices to be "not seen" due to lacking the boot image on eMMC.
If this is the case of the current state of linux support, it's ok, I worry about it not being a persistent SoC/board design "choice". Of screwing up eMMC and SD coexistence.

PS. Just looked at the PM, and there is no SD/MMC controllers part! Must be in the second part. Does anybody know is it planned to get released?

[rhille]

I have this situation z4v4l was talking about.
I put the image onto emmc with dd without using cable and jumper and
it looks ok for me. When sd is put in, it boots from sd and if there is no sd card in then it boots
from emmc. I got the impression you are saying that this shouldn't work and now I'm wondering
why it does work. Or did I misunderstood your post to z4v4l?

[MarkHaysHarris777]

I have this situation z4v4l was talking about.
I put the image onto emmc with dd without using cable and jumper and
it looks ok for me. When sd is put in, it boots from sd and if there is no sd card in then it boots
from emmc. I got the impression you are saying that this shouldn't work and now I'm wondering
why it does work. Or did I misunderstood your post to z4v4l?

What you are describing is normal for the Pinebook, but not for the Rock64;  because the SD has boot priority over eMMC in the Pinebook.   The eMMC has boot priority on the Rock64 ( at least its supposed to ). 

You can put the image on the eMMC ( Rock64 ) with several techniques.  This tutorial is just ONE way that is straight-forward and usually works with the least amount of worries.  Sounds like your system is booting and running fine.

[z4v4l]

BUT since then I do have a message

blk_update_request: I/O error, dev mmcblk0rpmb, sector 0

in syslog which I'm a little bit scared of.

mmcblk0rpmb is a linux designation for "Replay Protected Memory Block", a special eMMC  partition (4MB here) for "dat security". Writes and reads there are signed, encrypted, all that thing. I think linux should not touch it without the specific reason. And I am not sure the support for this works (and works as needed) in the current linux build. It's a pretty capricious feature. I guess everything OK with it. linux just touches what it shouldn't. and gets rejected.

PS. Btw, see, the eMMC module has two boot areas, 4MB each

mmcblk0boot0 179:32 0 4M 1 disk
mmcblk0boot1 179:64 0 4M 1 disk

for firmware storage and booting. this is exactly what i was talking about when said about two SPI NOR chips for redundancy and robustness. It's safer. eMMC standard incorporates this and we have a duplicated (backed up) special firmware booting device inside an eMMC card. without touching a User Area, so that the user could use all of the bytes there for their needs. But vendors aren't bothered with such things like efficient and proper technology application. Instead they have produced 7 (!) partitions in the user area! For nothing. well.

[rhille]

@MarkHaysHarris777,

thank you, so basically you say I had luck   - nice to know, but on the other side I would really like to understand why 
But I guess I should be happy - rock64 runs so ok.

@z4v4l,

thank you for clarification - I found out that this message appears as soon as I call parted.
In addition found a post in chromium forum saying basically the same - message is annoying but harmless.

Thank you
Reinhard

[WhiskerBiscuit]

I haven't gotten my Rock64 yet, but I was perusing the setup guides. I've setup similar SBC machines before. Will I be able to take one of the Jessie images and use a program like etcher to write that to an EEMC drive?

[freebsd]

That is not the behaviour I am seeing.   I have Android 7.1.2 on an eMMC and the community MATE install of Ubuntu 16.04 on the MicroSD.
The MATE comes up, not Android if both are installed.

[WhiskerBiscuit]

What happens if you just don't have the SD plugged in?

---

I have this situation z4v4l was talking about.
I put the image onto emmc with dd without using cable and jumper and
it looks ok for me. When sd is put in, it boots from sd and if there is no sd card in then it boots
from emmc. I got the impression you are saying that this shouldn't work and now I'm wondering
why it does work. Or did I misunderstood your post to z4v4l?

What you are describing is normal for the Pinebook, but not for the Rock64;  because the SD has boot priority over eMMC in the Pinebook.   The eMMC has boot priority on the Rock64 ( at least its supposed to ). 

You can put the image on the eMMC ( Rock64 ) with several techniques.  This tutorial is just ONE way that is straight-forward and usually works with the least amount of worries.  Sounds like your system is booting and running fine.

Is one of those ways by using a windows machine and etcher to burn the image to eMMC using a USB to microSD adapter, like the Transcend as seen here?

[rhille]

What happens if you just don't have the SD plugged in?

---

I have this situation z4v4l was talking about.
I put the image onto emmc with dd without using cable and jumper and
it looks ok for me. When sd is put in, it boots from sd and if there is no sd card in then it boots
from emmc. I got the impression you are saying that this shouldn't work and now I'm wondering
why it does work. Or did I misunderstood your post to z4v4l?

What you are describing is normal for the Pinebook, but not for the Rock64;  because the SD has boot priority over eMMC in the Pinebook.   The eMMC has boot priority on the Rock64 ( at least its supposed to ). 

You can put the image on the eMMC ( Rock64 ) with several techniques.  This tutorial is just ONE way that is straight-forward and usually works with the least amount of worries.  Sounds like your system is booting and running fine.

Is one of those ways by using a windows machine and etcher to burn the image to eMMC using a USB to microSD adapter, like the Transcend as seen here?

Why not giving it a try? The critical part is, as far as I understand that if you have an emmc imaged you might loose
the possibility to boot from sd afterwards (although didn't happen to me). If this is the case you need to do the procedure with
the serial cable as described by PMarkHaysHarris777.

Good luck
Reinhard