Foresee NCEMASLG-64G 64 GB eMMC module unreadable

[lucho]

Not sure whether this is the right place for this topic. Please excuse me if this is not so.

I'm using the HardKernel microSD to eMMC adapter (connected to a USB-2 card reader) with the Foresee NCEMASLG-64G 64 eMMC module that I purchased from the Pine64 store along with the RockPro64 v2.1. After writing the 3 GB uncompressed RockPro64 LXDE image on the eMMC, the "Etcher" utility starts verifying the image and gets stuck at 16% and after some time I get "EIO: i/o error, read error". My second attempt gave the same error, but this time as early as at 8%. And my third attempt – at 9%. I.e., the error occurs each time at a different place. I have previously used the same adapter with an 16 GB eMMC module for the ODROID-XU4 and it worked normally. Is this a sign of a bad eMMC module, or something else? I can try booting the board from a slow microSD card and then writing the image from there if the eMMC is OK. Thanks a lot for your help!

[paradise]

If it fails at different locations it sounds more like a timing issue to me.
Did you try writing it with another machine or OS? (Linux Live CD or something)
Also try other USB ports, I have some issues sometimes and I switch from USB 3 to 2 or visa versa and it just works fine.

Or you could be brave and do what I did at first when I didn't have a USB to eMMC module so...
Boot the Pine from SD and insert the eMMC at a time it will accept it. (for me that was after u-boot started I pressed a key to pause u-boot) inserted the eMMC and used mmc probe ; mmc dev 1 ; mmc write ... to get the SPL on the eMMC so at least does not hang at boot when it notices the empty eMMC.

[lucho]

Thanks! I just wrote the image to a slow microSD card and to the eMMC module (in the latter case, using "dd", without trying to read it again from the module), moved both the microSD card and the eMMC module to the RockPro64, and turned it on. It booted OK, I managed to log in and it turned out that the it had booted from the eMMC module, not the microSD card. So far, so good. Just in case, I read the eMMC module with "sudo dd if=/dev/mmcblk1 of=/dev/null bs=1M" and it did read the (almost) entire module successfully, with 157 MB/s. So you're right that it must have been a timing issue. I just learned that the eMMC still supports the serial interface of the original MMC and SD cards, and that's how the Hardkernel microSD-to-eMMC adapter works. But because of the very high reading speed of this eMMC, the timings must have been be "at the edge" with it, which leads to occasional errors. Fortunately, this occurs only on reading and not on writing when it's slower so the timings are not "at the edge" – a "blessing in disguise".

Now the question is how to resize the image to the full 64 GB size of the eMMC card. I tried the "/usr/local/sbin/resize_rootfs.sh" script but it turned out that it can resize non-mounted partitions only:

Code:

rock64@rockpro64:/usr/local/sbin$ sudo ./resize_rootfs.sh
Resizing /dev/mmcblk0 (sd/emmc -- /dev/mmcblk0p7)...
+ sgdisk -e /dev/mmcblk0
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
+ echo ,+,,,
+ sfdisk /dev/mmcblk0 -N7 --force
Checking that no-one is using this disk right now ... FAILED

This disk is currently in use - repartitioning is probably a bad idea.
Umount all file systems, and swapoff all swap partitions on this disk.
Use the --no-reread flag to suppress this check.

Disk /dev/mmcblk0: 3.7 GiB, 3949985792 bytes, 7714816 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B2791BBA-7718-4413-BA41-9137CCF92DD2

Old situation:

Device          Start     End Sectors  Size Type
/dev/mmcblk0p1     64    8063    8000  3.9M Linux filesystem
/dev/mmcblk0p2   8064    8191     128   64K Linux filesystem
/dev/mmcblk0p3   8192   16383    8192    4M Linux filesystem
/dev/mmcblk0p4  16384   24575    8192    4M Linux filesystem
/dev/mmcblk0p5  24576   32767    8192    4M Linux filesystem
/dev/mmcblk0p6  32768  262143  229376  112M Microsoft basic data
/dev/mmcblk0p7 262144 7714782 7452639  3.6G Linux filesystem

/dev/mmcblk0p7:
New situation:
Disklabel type: gpt
Disk identifier: B2791BBA-7718-4413-BA41-9137CCF92DD2

Device          Start     End Sectors  Size Type
/dev/mmcblk0p1     64    8063    8000  3.9M Linux filesystem
/dev/mmcblk0p2   8064    8191     128   64K Linux filesystem
/dev/mmcblk0p3   8192   16383    8192    4M Linux filesystem
/dev/mmcblk0p4  16384   24575    8192    4M Linux filesystem
/dev/mmcblk0p5  24576   32767    8192    4M Linux filesystem
/dev/mmcblk0p6  32768  262143  229376  112M Microsoft basic data
/dev/mmcblk0p7 262144 7714782 7452639  3.6G Linux filesystem

The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).
Syncing disks.
+ partprobe /dev/mmcblk0
+ resize2fs /dev/mmcblk0p7
resize2fs 1.44.1 (24-Mar-2018)
The filesystem is already 931579 (4k) blocks long.  Nothing to do!

So, in fact, it did nothing. How should I do the resizing then? (This may now be off-topic but I can start a new topic if needed.)

[Bullet64]

Code:

/dev/mmcblk0

is the SD-Card!

eMMC-Modul is

Code:

/dev/mmcblk1

[dukla2000]

Looks like you are nearly there. I would shutdown, remove SDcard, and check how things look. You may need to run resize_rootfs.sh again.

What you have done is essentially what I did (and wrote up here.)

This may now be off-topic but I can start a new topic if needed.

Hey - it is your thread - you get to determine what is on or off topic IMHO

[paradise]

 I just learned that the eMMC still supports the serial interface of the original MMC and SD cards, and that's how the Hardkernel microSD-to-eMMC adapter works. But because of the very high reading speed of this eMMC, the timings must have been be "at the edge" with it, which leads to occasional errors. Fortunately, this occurs only on reading and not on writing when it's slower so the timings are not "at the edge" – a "blessing in disguise".

You are correct, I see it as just another type of sd-card only with a couple more pins for datatransfer. I don't think they talk SPI anymore but the protocol is pretty close. Instead of 1(SPI) 2(DPI) or 4(QPI) channels to talk data it uses up to 8 wires for datatransfer. If you bit bang these things you usually don't have any issues but if you want to get the max out of them you need to tweak your timing and the capabilities of the controller so you get less bit errors. 

The big thing with these ARM's is the clock tree; to get stuff at a specific frequency you may have to switch more clocks and dividers then you like and end up messing up the timing for some other components (USB, etc).

Just take a quick look at the 'Clock Tree' of the Allwinner datasheet for instance and you will understand. 

Also for eMMC to go 'fast' the driver needs to calibrate the delay chain so if the driver fails to do that or doesn't do it correctly the timing will be wrong and neither the device or card will be a happy camper and most likely start yelling at you trough dmesg. :-)

[lucho]

The big thing with these ARM's is the clock tree; to get stuff at a specific frequency you may have to switch more clocks and dividers then you like and end up messing up the timing for some other components (USB, etc).

Just take a quick look at the 'Clock Tree' of the Allwinner datasheet for instance and you will understand.

Yes, the A10 datasheet v1.21 for example shows a spectacular clock tree on pp. 53–55!

I just removed the microSD card and rebooted. Voila! The filesystem on the eMMC card turned out to be already resized:

Code:

rock64@rockpro64:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           388M  464K  388M   1% /run
/dev/mmcblk1p7   57G  2.1G   53G   4% /
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/mmcblk1p6  112M   18K  112M   1% /boot/efi
tmpfs           388M     0  388M   0% /run/user/1000

Now that I'm sure the microSD card is really not needed, I can prepare the Z5B enclosure for the SBC before continuing with the system configuration and installation of the additional packages.

Also for eMMC to go 'fast' the driver needs to calibrate the delay chain so if the driver fails to do that or doesn't do it correctly the timing will be wrong and neither the device or card will be a happy camper and most likely start yelling at you trough dmesg. :-)

How do I verify that the eMMC driver has calibrated the delay chain correctly, and if it hasn't, how do I make it do it?

[paradise]

You will notice when you have an eMMC module that should do 200Mhz and your device tells you it's running at 52Mhz.
They only get at the real high speeds if they calibrate the delay chain in the driver before talking to the eMMC.