PROCEDURE TO FLASH eMMC

[igorpec]

but Etcher does not see it, nor does my WIN10 laptop.  I cannot seem to access it.  Is it dead?

Boot loader from this "Ubuntu mate" is probably not UMS capable or  you flash it wrong. 

Is there any hope?

Yes.

[Im4Tinker]

I cannot seem to access it.  Is it dead?

No, don't dispair

Is there any hope?

It take just a a small procedure, see this post or even better the entire thread.
Or you may install the Armbian u-boot, included in the zip file, whether you plan to install Armbian mode.

Code:

$ sudo dd if=rk3288_boot.bin of=/dev/<kernel_name> bs=512 seek=64  ## or
$ sudo dd if=u-boot-rockchip-with-spl.bin of=/dev/<kernel_name> bs=512 seek=64

If you plan to use ELAR or TinkerOS, then you should copy the u-boot from the TinkerOS included in the zip file.

Code:

$ sudo dd if=tOS.img of=/dev/<kernel_name> bs=512 seek=64

[jschwart]

So is there a quick way to check whether a given image provides the UMS capable bootloader?

[Radioman]

I cannot seem to access it.  Is it dead?

No, don't despair

Is there any hope?

It take just a a small procedure, see this post or even better the entire thread.
Or you may install the Armbian u-boot, included in the zip file, whether you plan to install Armbian mode.

Code:

$ sudo dd if=rk3288_boot.bin of=/dev/<kernel_name> bs=512 seek=64  ## or
$ sudo dd if=u-boot-rockchip-with-spl.bin of=/dev/<kernel_name> bs=512 seek=64

If you plan to use ELAR or TinkerOS, then you should copy the u-boot from the TinkerOS included in the zip file.

Code:

$ sudo dd if=tOS.img of=/dev/<kernel_name> bs=512 seek=64

Im4Tinker,  You have the patience of Job!  Thank you for your help and encouragement.  I believe that you have provided the answer to my problem.  As a Noobie, I have a final (maybe ) question.  How do I find what the "kernel_name" is?  I have looked on the ELAR site, nothing there.  It must be known to those of you who have the experience in Linux.  Thanx again,  Joe

[lobo]

So for the case we may give the command

Code:

$ sudo dd if=TinkerBoard-Lubuntu18.04LTS_ELAR-Systems-SD-v2.img of=/dev/sdc bs=512 seek=212992 skip=139264

seek means where to start reading and skip where to start writing.

Hi Im4Tinker,
let me say that your posts are always very informative and I like.
But here maybe there is a typo, as from the man page for dd:

Code:

seek=N skip N obs-sized blocks at start of output
skip=N skip N ibs-sized blocks at start of input

As I also learned the hard way to find the correct values for reading and writing the boot.img from Android sdcard.
So, I think it must be vice versa, to not produce garbage:

Code:

$ sudo dd if=TinkerBoard-Lubuntu18.04LTS_ELAR-Systems-SD-v2.img of=/dev/sdc bs=512 skip=212992 seek=139264

I ried it with a sdcard, first flashed tinker-board-linaro-stretch to it and then the command as above. I rebooted and saw some errors, but ELAR booted. I saw that there was no network at all and no modules loaded. Then I flashed also the boot partition:

Code:

sudo dd if=TinkerBoard-Lubuntu18.04LTS_ELAR-Systems-SD-v2.img of=/dev/sdg bs=512 skip=8192 seek=8192 count=131072

As one can see, only the 64M as this is the size of the boot partition on the sdcard and to not overwrite the second partition.
The ELAR booted and made some rootfs resize and rebooted.
After that there is also network.
   
Sadly, I have no TB S model to check if it can be flashed this way also to the emmc.

[Im4Tinker]

Thank you lobo! You helped me to find my oversight
In facts there is a difference between the two installation regarding the size of the boot partition, but coarsely checked I didn't find differences.
SD card and eMMC have no big differences. The only problem is the first 4Mbytes which contains the functionality to let access the eMMC as UMS. When that is damaged, then here comes the problem that we're talking about.

How do I find what the "kernel_name" is?

The kernel_name is the definition that is given to a device by the kernel. So for pluggable devices you may find a notification on the bottom of kernel debug message, just do after plugged in

Code:

$ dmesg |tail

So for certain distro, such device will be named sdXY, which X stands for the device number and Y stands for the partition number. See this
I didn't state any of those names, because it vary from a PC and the TB itself, which they are named mmcblkNpP, where N is the device number and P the partition number. Also because using dd for windows the naming convention is very much different.

There's also a trick to write the u-boot file. We must write it on no partition, but at the device beginning, so there won't be the partition definition to issue to shell command. In particular the file is place at 64 sectors away from the begin.

These distinctions are necessary, because depend where one will do the operations. If doing on a PC will be mostly as per the former statement, whereas doing directly on the tinker board, would be the latter.

[Im4Tinker]

So is there a quick way to check whether a given image provides the UMS capable bootloader?

It's difficult. It takes to write u-boot to the media and test it. Practically all the installation should provide such function.
In details it might be possible to scan the first 4 Mbytes in search of a stream of code that is used to start UMS function. Thereafter write a small program that will check such code.
AFAIK, it should need to compile an u-boot without the UMS function and compare it with one which has it. So it will be distinguished the relevant part of code.

[Im4Tinker]

Hi folks, I spent this afternoon to write a little document. Hope it will be useful.

EDIT
a small update to the document.
If anybody wants to review it and correct the bad grammar, I'll appreciate it.

[Grulle]

@Im4Tinker:

Yes! That's exactly what I was searching for!

Thanks a lot!

I will try it soon, not because I need it right now,
but to be prepared... and for just playing a bit.


Greetings

Grulle

[Radioman]

Hi folks, I spent this afternoon to write a little document. Hope it will be useful.

Hello Friend,

I appreciated very much your document on the eMMC recovery.  It was very helpful in explaining the terms I didn't understand.   However... I still couldn't get the eMMC working. UNTIL I looked at the memory using gparted which recognized the memory as "unallocated".  I've been home from work with a nasty virus (the human-type ) so, I set to thinking about this. Nothing to lose, I used gparted to put two ext4 partitions on the eMMC.  Next I connected the TBS to my trusty ASUS laptop (a shameless plug for ASUS) and fired up Etcher.  Sure enough, the PC and Etcher recognized it and I flashed the TOS to the eMMC, hooked the TBS back to power and monitor, and presto, its alive again!  Parted told me I needed two files, mtools & dosfstools which I downloaded.  Back in business.  Thank you for your patience and sharing the knowledge you have!  Radioman