(03-31-2016, 10:42 AM)pine.tree Wrote: 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
(03-31-2016, 10:59 AM)rahlquist Wrote: 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
