This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Can't burn image eMMc
#21
Thanks, I already solved it, was a typo in dd command. I edited my post.

Do I need 'skip=64' parameter btw? I did not use it, all looks ok.
Reply
#22
(10-22-2018, 09:14 AM)Tinker Board Wrote:
Code:
sudo dd if=20180622-tinker-board-linaro-stretch-alip-v2.0.7.img of=/dev/mmcblk1 skip=64 seek=64 bs=512 count=8192
count should be 8192 -64 = 8128. Otherwise the first partition gets overwritten of 64 blocks Wink
Light blue words might be a link. Have you try to click on them? Big Grin
[-] The following 1 user Likes Im4Tinker's post:
  • Tinker Board
Reply
#23
(10-22-2018, 11:16 AM)Im4Tinker Wrote:
(10-22-2018, 09:14 AM)Tinker Board Wrote:
Code:
sudo dd if=20180622-tinker-board-linaro-stretch-alip-v2.0.7.img of=/dev/mmcblk1 skip=64 seek=64 bs=512 count=8192
count should be 8192 -64 = 8128. Otherwise the first partition gets overwritten of 64 blocks Wink

You maybe right, we would take double confirm with RD team again.

-- update --
Should be 8192-64 = 8128
Reply
#24
Thanks again.

Is the usage of just 'sudo dd if=/home/linaro/20180622-tinker-board-linaro-stretch-alip-v2.0.7.img of=/dev/mmcblk1' not correct?
I didn't see any errors now, all stuff works fine.

I can guess that both commands 'skip=64 seek=64' force dd just to skip the first 64 bytes, but why its required?
Reply
#25
For the device name is better to check by
Code:
$ sudo fdisk-l
If there's an SD card you may distinguish according the partition scheme used. For linaro there's the first partition of 64 Mb FAT32 formatted.
Regarding skip  or seek
man dd Wrote:seek=N skip N obs-sized blocks at start of output

      skip=N skip N ibs-sized blocks at start of input[/quote
So is logically necessary to seek the first 64 block (512 byte X 64) from the input file and also to skip the first portion of the output destination.
The bs is 512 bytes, which is the default of one sector, is not one byte Smile. So the first portion to leave alone is 64 X 512 = 32 Kbytes.

I admit that I was not aware of the skip and seek definitions, but now I understand better.

DVE Wrote:'skip=64 seek=64' force dd just to skip the first 64 bytes, but why its required?
Because if the eMMC contains already an installation it will be maintained. Usually in the first 64 sectors is allocated for GPT or MBR partitioning details. Then avoiding to overwrite such area will preserve the partition table.
Light blue words might be a link. Have you try to click on them? Big Grin
Reply
#26
Hi,

Since, the U-Boot only locate at 0x40 to 0x2000 (64~8192, blocksize=512).
Then if use that dd command, it can just replace U-Boot, and let your system keep working.

skip=64, it can let dd get U-Boot by skip 0x40 "-*-----" at input image.
seek=64, it can let dd when push data into eMMC would start at 0x40 "-*-----".
count=8128, it can let dd only push U-Boot data and not overwrite more data.

So this method just tries to enable the UMS function by replacing new U-Boot, and let device can re-mountable to PC.
But of course, you can also directly dd whole image.
Reply
#27
(10-23-2018, 02:06 AM)Tinker Board Wrote: But of course, you can also directly dd whole image.
In suspicion that the system won't work that's right. But it's worth a try to write 4Mb rather than 3 Gb. The latter might take several minutes.

I suggest to add into the TinkerOS the u-boot, as Armbian staff doing Wink
Even better if it will be available to the github repository.
Then to inform the user to retrieve it in case of disaster, so it will be only half Mbyte c.a. to write at the mentioned offset.
Light blue words might be a link. Have you try to click on them? Big Grin
Reply
#28
(10-23-2018, 07:18 PM)Im4Tinker Wrote:
(10-23-2018, 02:06 AM)Tinker Board Wrote: But of course, you can also directly dd whole image.
In suspicion that the system won't work that's right. But it's worth a try to write 4Mb rather than 3 Gb. The latter might take several minutes.

Because, whatever he done, he would going to re-flash whole image in eMMC.
And he was booting from SD card, so this would be one of quick and better option too.

(10-23-2018, 07:18 PM)Im4Tinker Wrote: I suggest to add into the TinkerOS the u-boot, as Armbian staff doing Wink
Even better if it will be available to the github repository.

Sorry, not get your point.
Do you mean we ASUS need to add some kind of U-Boot as Armbian's? in TinkerOS image?
May we know which part of functions?
BTW soft remind, our Kernel & U-Boot all following the GPL, and all public at GitHub.
Reply
#29
Tinker Board Wrote:he would going to re-flash whole image in eMMC
Definitely less prone to errors Smile
I meant that the u-boot file, which is used to boot, should be available to use somewhere in the first partition, better than copying the first 4 Mbytes. Also a good option if the file will be readily compiled at the github.
Light blue words might be a link. Have you try to click on them? Big Grin
[-] The following 1 user Likes Im4Tinker's post:
  • Radioman
Reply
#30
(10-03-2018, 03:17 AM)Im4Tinker Wrote:
(10-02-2018, 10:16 PM)franckm Wrote: UMS from SD card
eMMC’s U-Boot is broken to booting or not built-in the UMS function (e.g. 3rd party custom image).


If your eMMC is not found while you plug to a PC. then you can recover it by preparing a OS into SD card. Which should contain also the image to write to the eMMC, or just copy the SD card to the eMMC directly. Better similar size to eMMC.
The former option will do to copy the file directly to the eMMC. Supposed that is a zip file
Code:
sudo zcat /path/to/TinkerOS.zip >/dev/mmcblkX    ## see explanation below for the partition naming
Assuming the latter option. You need to write the image to SD card, boot the SD card by setting the jumper to MASKROM.
Once you have the system running, then you need to go to a console like lxterminal and prepare to copy the system back to eMMC. Unless you've logged in by a SSH connection.
Operations
  •  check the size of SD card against the eMMC
    Code:
    $ sudo fdisk -l
  •  note the highest number of sectors used on the SD card, it must be less than eMMC. Otherwice chose the smallest.
  • Found the smaller size e.g.
    Code:
    Disk /dev/sdc: 14,4 GiB, 15489564672 bytes, 30253056 sectors      ## use 30253056 / 2 = 15126528
    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: dos
    copy the system over the eMMC
    Code:
    $ sudo dd if=/dev/mmcblkX of=/dev/mmcblkY bs=1K count=(sizeof_SD/2) conv=notrunc,noerror,sync


Last command explanation :
  • X = kernel device number referred to the SD card
  • Y = kernel device number referred to the eMMC
  • sizeof_SD = size of SD card in sectors or which is the smallest device. This avoid to overflow the eMMC. Once the system is recovered it should take a further partition adjustment.
  • There could be some 10 minutes waiting to complete.
Once is done, you might put the jumper in PARK position and try to plug the TB S on a PC. If it'll appear as UMS, then you have recovered the function. Then you'll need linux OS to check the partitions for consistency, whether you want to keep that installation.

There's even a shortcut, but the eMMC won't have any reliable partition table. It'll take to copy the u-boot back to eMMC.

So these are the steps, preferred to use linux OS:
  • unpack the OS in a image.
  • check where the first partition starts
    Code:
    $ sudo fdisk -l unpacked.img
    That should be the limit to stop copying.
  • If less than 4 Mb, then recalculate how many blocks to put on the count= statement
  • take the first 4 Mbytes from the image
    Code:
    dd if=unpacked.img of=my_u-boot.img bs=512 seek=64 count=8128
  • write the unpacked.img to SD card. Mount the SD card and write the my_u-boot.img to the /home/$user directory. (The $user may vary according which OS you want to use)
  • boot the SD card with MASKROM enabled
  • copy the my_u-boot.img to eMMC.
  • similar to the previous method referred to the partition numbering.
    Code:
    $ sudo dd if=my_u-boot.img of=/dev/mmcblkY bs=512 seek=64
Done, you should have your installation came back as previously installed, according to the partition table that was set before the damage. It may take few seconds to complete. But is preferred to check for consistency. Anyway the UMS functionality is back to use and will allow to write to eMMC.

Thank you! I used as you wrote the smallest sector size of the 2 (my case was the eemc as my SD was 32GB) rest as normal waited 10' about and with parking position finally emmc is on my windows 10.
I bet your other tOS.img is also ok. Next time :-) Wink
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)