Unable to format sdcard

[Nova136]

Tried to burn the android image onto my sdcard but fails every time.
Phoenixcard is running as administrator.
Reformatted sdcard a few times still no luck.
The partition of the sdcard after phoenixcard reformatted it seems very weird.
Attached the images of error for reference.
Any help or advise would be appreciated.

[tkaiser]

Are you aware of issue 2: http://forum.pine64.org/showthread.php?tid=514

[Milkman]

https://www.youtube.com/watch?v=mGBSGaGteAc
in the description there is a link to a card for-matter worked for me!

[tkaiser]

https://www.youtube.com/watch?v=mGBSGaGteAc
in the description there is a link to a card for-matter worked for me!

But more importantly he did two other things that are more important to get RemixOS booting:

• He used a genuine Samsung EVO and not a fake card (with counterfeit cards that fake a larger capacity using Phoenix Card you'll always already fail after the '[boot]Burn success' message since Phoenix Card will then try to write to the system partition that is beyond the card's real capacity. Phoenix Card always expands the partition scheme to the maximum and the largest partition is a data partition in the middle. So using Phoenix Card you can already spot fake cards)
  
• He did not connect Ethernet on 1st boot. If he would've connected Ethernet neither RemixOS nor Android will get past the Pine64 logo
  

[Nova136]

https://www.youtube.com/watch?v=mGBSGaGteAc
in the description there is a link to a card for-matter worked for me!

But more importantly he did two other things that are more important to get RemixOS booting:

• He used a genuine Samsung EVO and not a fake card (with counterfeit cards that fake a larger capacity using Phoenix Card you'll always already fail after the '[boot]Burn success' message since Phoenix Card will then try to write to the system partition that is beyond the card's real capacity. Phoenix Card always expands the partition scheme to the maximum and the largest partition is a data partition in the middle. So using Phoenix Card you can already spot fake cards)
  
• He did not connect Ethernet on 1st boot. If he would've connected Ethernet neither RemixOS nor Android will get past the Pine64 logo
  

Apparently , phoenixcard cant work with the sdcard-usb readers.
Fixed it by using the sdadapter.
Remix running well now.
Thanks guys.

[tkaiser]

Apparently , phoenixcard cant work with the sdcard-usb readers.

WRONG! Phoenix Card is interface agnostic!

You just ignored issue N° 2 from the list of the most common reasons why Pine64 won't boot: http://forum.pine64.org/showthread.php?tid=514

Your USB reader corrupted data while writing to the card and Phoenix Card was able to detect that. If you would have tried to burn a Linux image, burning would have suceeded but Linux would have crashed later. What to do: Always use H2testw or f3 first. It's so easy and nobody does it.

[rahlquist]

Apparently , phoenixcard cant work with the sdcard-usb readers.

WRONG! Phoenix Card is interface agnostic!

You just ignored issue N° 2 from the list of the most common reasons why Pine64 won't boot: http://forum.pine64.org/showthread.php?tid=514

Your USB reader corrupted data while writing to the card and Phoenix Card was able to detect that. If you would have tried to burn a Linux image, burning would have suceeded but Linux would have crashed later. What to do: Always use H2testw or f3 first. It's so easy and nobody does it.

USB ports on a computer seem to have more issues than most realize, and when using low level software like Phoenix Card, Win32Image, and even android adb the communication used is low level, and doesn't always do a lot of good error checking. When you are using an OS to read/write from a USB device using file system access there is more error checking going on than when you are using one of the 3 above. 

When using Phoenix or Win32Image they both appear to issue a command to write to a specific address(sector) and then the next and the next. This is how an image works. After the image is written, Phoenix then will look at the storage and say, hey you have another 3GB free and the instructions in the image file say to expand partition X if there is free space, so it does. Without the source for Phoenix its hard to say for sure but my guess is it finishes each partitions writes and then verifies the data, and if a address is bad it then simply fails. 

Whereas with the OS saving a file to a USB device it pushes a file and says basically store this, the OS then looks for blank space in the file table and drops the file into it, during write the OS is monitoring for things like worn out cells(sectors) etc. if it finds one the OS says "mark that bad and find me another location to write this to" (if the usb hardware even allows that some USB flash drives handle all that without the OS even seeing it). 

One thing many android phone hackers learned is that the USB ports not soldered to their motherboard can increase the number of incidents with these issues. Front panel ports connected using cheap internal non shielded cables seem to be the culprit. 

I know it sounds like nonsense but plenty of people over at XDA have bricked/softbricked phones by flashing new firmware using the front ports on their PC. I am no USB expert but likley you ran afoul of some issue like that Nova136. I have a perfectly good USB 3 flash card adapter that was giving me trouble when I put the microsd card driectly in it last week. When I put the microsd into a microsd to sd card adapter and then used it in the same device, things worked. 

So a few pieces of advice when using usb to flash your microsd with an image. 

Use the USB ports on the back of your dekstop when possible.

If you are having trouble, dont use hubs, USB extension cables, etc. 

Do not plug/unplug anything from the PC while writing an image. 

If you use a KVM, do not switch machines while writing an image. 

Above all test those cards.

[tkaiser]

After the image is written, Phoenix then will look at the storage and say, hey you have another 3GB free and the instructions in the image file say to expand partition X if there is free space, so it does.

I will only comment on this Phoenix Card behaviour and add a link to one of the many problems related to USB card readers on high speed ports: Overheating paired with data corruption. And it's as easy as always to detect that using h2testw and/or f3.

Phoenix Card in Startup mode first partitions the card and then tries to write specific blocks of data to the card (that are not necessarily inside partitions, for example the bootloader and env stuff is just a few sectors at the beginning even before the partition table itself). Phoenix Card uses a rather primitive checksum algorithm to verify some of the written data. But at least this checksumming succeeds most of the times in detecting both data corruption and counterfeit cards (since the system partition is located beyond the card's real capacity).

Anyway: the technical background is close to irrelevant if people would simply learn to use h2testw or f3 first to check both card and burning process. If Phoenix Card or WinDiskImager will fail, those two test tools will fail for sure and also show the reason.

[rahlquist]

After the image is written, Phoenix then will look at the storage and say, hey you have another 3GB free and the instructions in the image file say to expand partition X if there is free space, so it does.

I will only comment on this Phoenix Card behaviour and add a link to one of the many problems related to USB card readers on high speed ports: Overheating paired with data corruption. And it's as easy as always to detect that using h2testw and/or f3.

Phoenix Card in Startup mode first partitions the card and then tries to write specific blocks of data to the card (that are not necessarily inside partitions, for example the bootloader and env stuff is just a few sectors at the beginning even before the partition table itself). Phoenix Card uses a rather primitive checksum algorithm to verify some of the written data. But at least this checksumming succeeds most of the times in detecting both data corruption and counterfeit cards (since the system partition is located beyond the card's real capacity).

Anyway: the technical background is close to irrelevant if people would simply learn to use h2testw or f3 first to check both card and burning process. If Phoenix Card or WinDiskImager will fail, those two test tools will fail for sure and also show the reason.

Thanks for the detail on the checksum thats more info than I had. It would be nice if Phoenix and/or win32imager would include the same function as h2testwe and f3 in their own products.

[tkaiser]

It would be nice if Phoenix and/or win32imager would include the same function as h2testwe and f3 in their own products.

I don't use Windows but the other Armbian folks recommend using Rufus when running Windows 8 or higher (supports normal SD card readers and at least a verify).

And I think if Phoenix Card would not only spit out "Error" but "Checksum error" instead when it detects exactly that it would also help. But since this is Allwinner's software I don't think they'll improve it since most Allwinner devices are factory flashed (tablets and OTT boxes with internal NAND/eMMC) and they even might not be able to imagine in which trouble users get when having to rely on this software.

So still using h2testw and f3 is the best option. Since they're also able to disclose problems related to the burning process in question (the USB reader that overheats, the USB front ports that lead to data corruption due to unshielded cables and so on)