Documentation problem: FLASHING THE COMPUTE MODULE EMMC

[wittend]

The process described for flashing the eMMC on a Compute Module 3 is seriously unclear and confusing. It commingles instructions for Linux platforms with Windows-Cygwin in a way that even experienced users of both find difficult to understand. Instructions for all platforms are incomplete. This page should be divided into three or four distinct sets of instructions, one for each host environment.

[alicemirror]

Correct Dave! I am testing the CM3 as Element14 road tester and in flashing I have found discordances with the real behaviour. I'll try to resume below, hope this can be helpful.

1. The issue on Mac is declared as solved in a previous note but as a matter of fact it works only partially, not always. The only full working mechanism is under Windows10 (tried on desktop Debian jessie, Raspberry Pi B3, Mac OSX 10.12).
2. The Windows 10 flashing procedure only works on new CM3 boards. Then is you try to reflash it it is impossible (Win10 32 bit on desktop, no VM). What happens is that after the device is correctly saw there are two partition, as expected, boot and the filesystem. From Windows 10 I delete all volumes and leave the board - in theory - intact. Then I launch the flashing program (I use both
   etcher and win image (suggested by the documentation). Around flashing 20% you get a message of timeout and always stops. At the end of the process I can see the two main partitions available with the boot partition readable.
3. Only after deleting all the partitions with a Mac OSX disk utility the CM3 can be reflashed, sometimes also with Mac and always with Windows.

I suspect that the problem of Windows in reflashing is some kind of issue in the Windows 10 disk utility that is unable to really delete the entire eMMC (maybe the swap partition remain on it?) but it is just a supposition.

Enrico

[JamesH65]

I'm a bit busy elsewhere at the moment, and Gordon is on holiday, so I'm not going to be able to dive straight in on this. Will be a week or two at least.

…

On 30 August 2017 at 11:14, Enrico Miglino ***@***.***> wrote: Correct Dave! I am testing the CM3 as Element14 road tester and in flashing I have found discordances with the real behaviour. I'll try to resume below, hope this can be helpful. 1. The issue on Mac is declared as solved in a previous note but as a matter of fact it works only partially, not always. The only full working mechanism is under Windows10 (tried on desktop Debian jessie, Raspberry Pi B3, Mac OSX 10.12). 2. The Windows 10 flashing procedure only works on new CM3 boards. Then is you try to reflash it it is impossible (Win10 32 bit on desktop, no VM). What happens is that after the device is correctly saw there are two partition, as expected, boot and the filesystem. From Windows 10 I delete all volumes and leave the board - in theory - intact. Then I launch the flashing program (I use both etcher and win image (suggested by the documentation). Around flashing 20% you get a message of timeout and always stops. At the end of the process I can see the two main partitions available with the boot partition readable. 3. Only after deleting all the partitions with a Mac OSX disk utility the CM3 can be reflashed, sometimes also with Mac and always with Windows. I suspect that the problem of Windows in reflashing is some kind of issue in the Windows 10 disk utility that is unable to really delete the entire eMMC (maybe the swap partition remain on it?) but it is just a supposition. Enrico — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#720 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADqrHWPmS9C-22uujuLI33iEecNdB9i1ks5sdTX-gaJpZM4PGzGx> .

-- James Hughes Principal Software Engineer, Raspberry Pi (Trading) Ltd

[wittend]

I have been trying to flash 6 CM3 boards off and on for about 4 weeks. I have been trying to use Mint/Ubuntu Linux (Mint 18.1) and Windows 7.1 to get this done with equally unproductive results. It is frustrating to be unable to get even one board usable. The boards never appear as mountable volumes in Linux in /dev. Even worse behavior in Windows.

CM3 Flashing problems.txt

[alicemirror]

David, I am answering with the best detailed possible explanation based on my experience on Element14 post you wrote.
Enrico

[wittend]

Enrico, Thank you very much. I really appreciate your prompt reply. Dave

…

On Thu, Aug 31, 2017 at 4:43 AM, Enrico Miglino ***@***.***> wrote: David, I am answering with the best detailed possible explanation based on my experience on Element14 post you wrote. Enrico — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#720 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUmIoFb1MlN9SmHF_kDUMUSsyVb_gI4ks5sdoBHgaJpZM4PGzGx> .

[JamesH65]

@ghollingworth Gordon, any chance you can take a look at this?

[ghollingworth]

Sounds like a Windows problem, not sure why though...

Maybe it's because Windows 'mounts' the filesystems when you first plug it in and then half way through writing to the disk it tries to remount the filesystems?

I'm surprised this isn't a generic problem with a flash drive as well though. It would be interesting to see if you end up with the same result if you try flashing an SD card with the image and then try to reflash it...

Gordon

[JamesH65]

@wittend Is this still a problem? There have been some change to that documentation area since this issue was raised.

[wittend]

I finally got one board flashed, but I had to use some weird sequence of actions that by now may have faded from my memory. All the aggravation caused me to move in other directions. I will check out the new documentation. I believe that I have 5 more that need to be initialized. Thanks, Dave

…

On Mon, Nov 20, 2017 at 4:03 AM, James Hughes ***@***.***> wrote: @wittend <https://github.com/wittend> Is this still a problem? There have been some change to that documentation area since this issue was raised. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#720 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUmIopYkaiKAy13MEcuIPCVkpp7LzGZks5s4U5dgaJpZM4PGzGx> .

[JamesH65]

@wittend Any news on this - inclined to close if there is no further activity.

[wittend]

No news. Thanks!

…

On Mon, Mar 12, 2018 at 7:51 AM, James Hughes ***@***.***> wrote: @wittend <https://github.com/wittend> Any news on this - inclined to close if there is no further activity. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#720 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUmIjObMeOSuOQGOVv1u7p_ArWMQmTYks5tdm9GgaJpZM4PGzGx> .

[JamesH65]

Assuming no news is good news, closing.