The 6 most common reasons why Pine64 won't boot

[Andrew2]

The order of the reasons is not intentional, it's just the order things come to my mind based on Forum posts:

1. The official Android and RemixOS images can't be burned the usual way to an SD card (dd, Rufus, WinDiskimager) but need Phoenix Card instead (Windows only and causing all sorts of troubles for users that do not use this strange operating system). Burning an Android image the wrong way will result in the Pine64 waiting endlessly while showing already a red led lighting. PhoenixCard images can only be burned with the PhoenixCard software. DD images can be burned using the dd command (Linux/Mac) Rufus, Win32DiskImager (Windows), Etcher, ApplePi Baker (Mac). Attempting to burn a DD image in PhoenixCard will result in a 'script not found' error. Likewise attempting to burn a PhoenixCard image with one of the above-named DD processes/applications will not work either.
   
2. Data written to SD card got corrupted either because you unfortunately bought a counterfeit SD card or the card is faulty. Another common problem are SD card readers that start to overheat when used with a fast card and corrupt data 'on the fly'. Checking for both problems is simple: Never use any flash based media without verifying it before.
   
3. Insufficient power supply: unfortunately Pine64 uses Micro USB for DC-IN, many USB cables have a resistance way to high (leading to severe voltage drops) and this combined with crappy PSUs (the old phone charger you found in the drawer) will lead to the Pine64 crashing in early boot stage
   
4. HDMI issues: You connected a screen but Pine64 and display disagree about settings (no idea whether EDID is implemented in Allwinner's 3.10.x Android kernel that is currently also used for all available Linux images)
   
5. The Pine64 boots fine but you don't notice still staring at the red led indicating 'error'
   
6. You use either the RemixOS or an Android image and have Ethernet connected at first boot. This will prevent the board from doing so, so please consider disconnecting Ethernet after burning an Android/RemixOS image and only connect it back when you already see the desktop.
   

What to add?

Important to know: 

• pre-production samples were equipped with a green led, the production batch replaced this with a red led. So red doesn't indicate failure but 'power available' instead. Unfortunately you get no other feedback whether the Pine64 actually boots or not. The red led will light even if the A64 waits patiently for a bootable OS available on a SD card an hour or endlessly.
  
• combining 'smart USB chargers' with devices that are 'dumb' on the other end of the cable might not work: If you use a 'charging hub' to power your Pine64 then chances are pretty high that the charger only provides 500mA (max. current defined by USB2.0 specs) which might be not enough to allow the Pine64 to boot (5.1V/2A!). Most 'smart chargers' will only provide more than 500mA if the device in question implements any of the USB power specifications (Pine64 implements none of them since it's just DC-IN)
  
• 2GB boards suffer from crashing or rebooting loops when Ethernet is connected since there's a integer overflow present in older kernel variants. Fixed by longsleep in early April, so Linux images can be updated using the instructions from "Linux Development" forum an a new RemixOS release should fix this also.
  

[pine.tree]

Add the common peripherals in first boot issue- mouse, keyboard, wifi dongle, whatever; shouldn't be plugged in while the board first boots up on a new image. After the first boot, you can restart and add all peripherals and be fine. I've heard this from some on the forums, and in my development team. Couldn't get it to boot until we unplugged our mouse.

EDIT: No longer true. Narrowed it down to the Ethernet issue.

[rahlquist]

The order of the reasons is not intentional, it's just the order things come to my mind based on Forum posts:

1. The official Android and RemixOS images can't be burned the usual way to an SD card (dd, Rufus, WinDiskimager) but need Phoenix Card instead (Windows only and causing all sorts of troubles for users that do not use this strange operating system). Burning an Android image the wrong way will result in the Pine64 waiting endlessly while showing already a red led lighting.
   

I just love it when people make computer function sound like voodoo. 

So in other words the Android and RemixOS images were made with something other than a real img file compatible source. Gotcha.

p.s. how about instructions on how to use Phoenix card, maybe on the wiki.

[Andrew2]

Add the common peripherals in first boot issue- mouse, keyboard, wifi dongle, whatever; shouldn't be plugged in while the board first boots up on a new image. After the first boot, you can restart and add all peripherals and be fine. I've heard this from some on the forums, and in my development team. Couldn't get it to boot until we unplugged our mouse.

I don't buy this since I do extensive testing/monitoring and think about the 'psychology' as well. People fail to boot the Pine64 successfully, try out everything that comes to their mind and if it works then after a few wasted hours, they try to remember what led to success and then steps were collected that sound reasonable. This way urban myths are born (same with writing OS images to SD cards, you can do it right or do it wrong, but there's no magic involved like 'first try this, then do the opposite and then quickly the third method and it will magically work now').

There might be reasons why a board does not start with connected peripherals, for example since hardware isn't initialised correctly in u-boot (such an issue existed for example with the Banana Pi M3, I reported that to the vendor back in Dec and they fixed it just recently by increasing voltage limits in u-boot). Then on every (re)boot the board will fail when a disk is connected for example and it will work when you connect it later (when the Linux kernel take over and did hardware initialisation correctly).

But that's definitely not the case for longsleep's OS images, they boot with a few power hungry USB peripherals connected. No idea about Android/RemixOS though. But when 1st boot behaviour should really differ from subsequent boots then the OS image would have to change something on the first boot (funny enough we do it just this way with the Armbian distribution I contribute too, but this still does not apply to Pine64)

We should refrain from creating urban myths like this since what might look reasonable based on several reports is most probably just the result of using a crappy PSU (and/or USB cable) to power the board in the beginning that has been replaced by something better in the meantime. Since it's easy to verify this (and I did it several times) I would only buy this if someone is able to reproduce this using absolutely identical conditions (at least same PSU/cable).

It's important to know and communicate the real reasons why users will fail booting the Pine64 to prevent further users from wasting hours of their live.

BTW: All this is nothing new, the issues are well known and understood if you deal with (sunxi) SBCs a bit longer. I just added this paragraph to Armbian's documentation this morning: https://github.com/igorpecovnik/lib/blob...oubleshoot

---

So in other words the Android and RemixOS images were made with something other than a real img file compatible source. Gotcha.

I explained the reason several times in the forums why Android images 'need' Phoenix card (the data partition somewhere inside will be resized to the medium's maximum capacity) and also how the Pine64 folks could deal with: prepare a bunch of dd-able Android images with fixed sizes: 7.5, 15.5, 31.5 and 63.5 GB. Or by expanding the partition on first boot -- that's easy with Linux but maybe not with Android. No idea since I'm not interested in Android at all

[pine.tree]

Our team was trying to boot the Android image, it wasn't working. I suggested that we unplug the keyboard and mouse, thinking that on the first boot it might be confused (Android is expecting a touchscreen), and it booted up fine. After that we connected the peripherals and it worked. I think that Android, after the first boot, got the drivers/similar for the keyboard and mouse after it was initially set up.

EDIT: It was an ethernet cable issue. Mice and keyboards are A-OK when first booting!

[rahlquist]

I explained the reason several times in the forums why Android images 'need' Phoenix card (the data partition somewhere inside will be resized to the medium's maximum capacity) and also how the Pine64 folks could deal with: prepare a bunch of dd-able Android images with fixed sizes: 7.5, 15.5, 31.5 and 63.5 GB. Or by expanding the partition on first boot -- that's easy with Linux but maybe not with Android. No idea since I'm not interested in Android at all

And that sir is a more apt explanation. So the Android type images want to be able to adjust their data partition size on install. Good to know. Thank you!

[Andrew2]

Our team was trying to boot the Android image, it wasn't working. I suggested that we unplug the keyboard and mouse, thinking that on the first boot it might be confused (Android is expecting a touchscreen), and it booted up fine.

If you're able to reproduce this in exactly the same fashion with same PSU/cable at least 2 times I start to believe this (sorry, I do professional IT support for a living and had to learn to never trust explanations that sound 'reasonable')

[pine.tree]

I can ask my team members to do it- i personally don't have a Pine yet, my dev board was sent out last week.

[Andrew2]

So the Android type images want to be able to adjust their data partition size on install. Good to know. Thank you!

I wouldn't call this 'on install' but 'on writing the image to the media' instead. Historically Allwinner devices have been tablets or OTT boxes with included NAND/eMMC and vendors used PhoenixSuit (or LiveSuit on Mac) to burn images onto the internal flash storage (size obviously varying between different devices). That's where this strange Android image format originates from and that this hasn't changed in all the years is mostly because none of the vendors selling Allwinner hardware spends a dime on software improvements

[Andrew2]

Since this thread has been unpinned in the meantime obviously the forum admins and/or Pine64 people think all issues have been successfully resolved in the meantime.

Puh, time to leave this place...