Can not get board to boot up reliably

[Leo]

*** I have read many of the threads regarding power and firmware and tried without success

Sometimes boots up or fails due to 'soft lockup' CPU#0 stuck for 22 seconds
at a point when calling cfg80211. I have tried all the combinations below and still not reliable

Pine A64+ 1GB board (A64-DB-Rev_B 2016-03-21)
Using serial cable on EXP header with Putty terminal and Ethernet connected.
No Wi-Fi or HDMI or USB connected

Have tried two different power supply - 5V 20VA adapter and 5V 100VA ATX computer supply
Have soldered power wires (0.5mm) onto pcb directly, to bypass use of usb power connector small pins
Added 100uf capacitor at that point to help any surge or length of wire (only 30cm!)

Then tried Euler bus DC-IN (4 and 6) with same power supplies.
Tried 6V SLA battery and diode so that 5.3V and lowest 5.208V at boot and still problem - you do not get more clean power than this.
Added 100nF, 10uf and 100uf caps on Euler header and still no help
When try ATX at lowest 5.098 it works and then sometimes not

Have tried soft reset button on Euler Bus and hard power reset on power
Tried changing the AXP803 bypass cap on pin 57/58 (C45) to 10nf and adding in 10uf - no change

Experiencing same problem with
pine64-image-debianmate-310102bsp-2.img and
pine64-image-debianbase-310102bsp-2.img

Using two different types of Scandisk Micro HC I sd-cards (8GB and 16GB) that work on other small board computers
Format SD-Card for linux
Burn image to SD using Win32DiskImager.
First boot - Serial Cable and Ethernet only
Burn again and First boot Serial Cable only

Expanded image as suggested ($resize_rootfs.sh)

Updated Kernel as suggested (from 3.10.102-2 to 3.10.105-0)
$pine64_update_kernel.sh

Make sure the cfg80211 is up to date
$sudo apt-get install wireless-regdb iw crda

Disable DHCP:
$ sudo update-rc.d -f dhcpcd5 remove
$ sudo update-rc.d -f isc-dhcp-server remove

Set Network Interface:
$sudo nano /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet static

[dkryder]

just a note that if you do not use ethernet the boot has to wait for a timeout and it's a fairly long time so you might think it is not booting.

[pfeerick]

just a note that if you do not use ethernet the boot has to wait for a timeout and it's a fairly long time so you might think it is not booting.

Fairly long being 5 minutes  (or 300 seconds) IIRC :-P 

This is starting to look like the WiFi driver being a pain again, unless it is still the ethernet waiting for the link to be established.

When you say no WiFi connected... do you have the WiFi module, and is it installed?

Try editing /etc/network/interfaces so that it says

Code:

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static

(i.e. remove the 'auto eth0' line as I'm pretty sure it isn't needed when you do allow-hotplug.) 

Other than that, hard to say .... you've done most of the normal troubleshooting and tests.

[Leo]

Thanks dkryder,

I do not have a Wifi board, and have no refrence to WLAN in the Interfaces file.

I have tried your suggestion and set the Interfaces to your code and cycle power several times again. Still not reliable - no change.
My mental score-sheet says that more of a chance if you shutdown, remove power, wait 30 sec and power again (cold start).
It does not work every time, but certainly more often than a software reboot or the reset input on the Euler bus.
I mention 30 sec because it seems better than 10 or 20.

Are we sure that there is not a floating voltage that must be drained?
Everyone keeps pointing to in-rush current and supply filter and ripple but maybe the problem is inductance?
I will next try to put a load on the Wifi header (led or two) to use up that empty space from a power perspective.
Maybe that will drain things a bit? Who knows?

Thanks

[dkryder]

leo, if you have some spare time give the q4os image a try and see how that one behaves for you.

[pfeerick]

My mental score-sheet says that more of a chance if you shutdown, remove power, wait 30 sec and power again (cold start).
It does not work every time, but certainly more often than a software reboot or the reset input on the Euler bus.
I mention 30 sec because it seems better than 10 or 20.

Are we sure that there is not a floating voltage that must be drained?

You have the same gut feeling that I do... I was suggesting before that like another user connecting the HDMI seemed to be resolving the headless boot issue for me, but it didn't *always* resolve it... I still got one or two bookup lockups. It seemed to go away more when I also pulled the battery, and left it for 30 seconds to fully kill any residual power/memory. But I don't have any empirical evidence of that, and I was pulling the power completely because it was still being stupid, so couldn't put the finger on it being power disconnect rather than simply another reboot.

[Leo]

leo, if you have some spare time give the q4os image a try and see how that one behaves for you.

Hello dkryder,

Ran out to get another SD-Card (Scandisk 8GB) for clean start to test...
It seems to act the same way as my other images.What is the cold-start clearing?
My shorthand notes for your interest:

Downloaded q4os-pine64-1803 from https://q4os.org and burn with Win32DiskImager.

#define cold-start = Power down and wait 30sec and power again
#define boot-failed = On boot, does not get past cfg80211 and software lock as mentioned in post
#define reset-failed = taking the Reset input connected to EXT but pin to ground, does not get past cfg80211 and software lock

First boot Ethernet + Serial adapter on EXP only
(boot-failed)
(cold-start ok)

Resize image:
$sudo resize_rootfs.sh

Bootloader and Kernel update:
$sudo pine64_update_uboot.sh
$reboot
(boot-failed, reset-failed)
(cold start failed x3)
$sudo pine64_update_kernel.sh
(You are already latest version - abort)

Os update:
$sudo apt-get update
(error - must manually run 'sudo dpkg --configure a ' to correct)
$sudo dpkg -a
$sudo apt-get update
$sudo apt-get dist-upgrade
$sudo reboot
(boot-failed, reset-failed)
(cold-start ok)

Login and test a reboot
$sudo reboot
(boot-failed, reset-failed)
(cold-start Ok)

---

My mental score-sheet says that more of a chance if you shutdown, remove power, wait 30 sec and power again (cold start).
It does not work every time, but certainly more often than a software reboot or the reset input on the Euler bus.
I mention 30 sec because it seems better than 10 or 20.

Are we sure that there is not a floating voltage that must be drained?

You have the same gut feeling that I do... I was suggesting before that like another user connecting the HDMI seemed to be resolving the headless boot issue for me, but it didn't *always* resolve it... I still got one or two bookup lockups. It seemed to go away more when I also pulled the battery, and left it for 30 seconds to fully kill any residual power/memory. But I don't have any empirical evidence of that, and I was pulling the power completely because it was still being stupid, so couldn't put the finger on it being power disconnect rather than simply another reboot.

My reason to try decouple the AXP803 with a 10nf as close to the VBUS input (which never helped).
The Reset input on the EXT Bus is an input to the AXP803 and my worry is that the 'glitch' is behind this circuit and Reset is not removing it like the cold-start seems to and the AX is stuck in the same problem.

[pkfpeters]

*** I have read many of the threads regarding power and firmware and tried without success

Hi Leo,

I also have/had these kind of startup problems. I did some test to see if they were power related, but
i don't think that is the case. If there is an issue i believe it has to do with correct initialisation order of
some registers in the Allwinner. I did not have the time to really do some in depth research, so I first
made a workaround by letting the kernel panic on soft lockups and auto reboot. At least this will result
in an auto retry without having to toggle power. 

I used the latest kernel from longsleep and did some custom kernel options. I have noticed that i was
unable to get my board to lockup at boot. Even with bad power supply (only 4.3Volt) the board still
boots fine. I think the fix is triggered by compiling the kernel without preemptive support; see also my
kernel config. If you don't want to compile the kernel you can also download my version at:
https://pkfpeters.stackstorage.com/s/mL1bQL0Dlj8Xw04

Sorry, i forgot my setup:

-Using a Pine A64+ 2GB (tested with and without the wifi addon module)
-Tested with apacer 16GB and 32GB MicroSD card.
-Tested with hdmi to vga converter (and monitor connected) and without converter (headless setup).
-Using standard debian image from forum and updated with -> apt-get update followed by apt-get upgrade and followed by pine64_update scipt from longsleep to get latest kernel and uboot
-Downloaded latest kernel source from longsleep and made custom changes to kernel settings with 'make ARCH=arm64 -j4 menuconfig all' -> see config attached to this item.
-Compiled kernel on the Pine64 with custom config by using -> 'make ARCH=arm64 -j4 all'
-Installed kernel modules with 'make ARCH=arm64 -j4 install'
-Reused initrd and dtd from longsleep; only replaced kernel in /boot dir and changed uboot kernel name.

Rebooted the unit and did many power tests. Low power, reboots, quick power off/on etc....

[dkryder]

so i was wondering while looking at your work if someone wanted to implement your work if it is a direct replacement of stock directories with your directories and during the unpacking some files were flagged as being the same with one set of those files iwith lower case filenames and the other with upper case filenames. i chose to not replace the uppercase with the lowercase. was that the correct choice? also the screen resolution listed in your Uenv.txt, is that the only resolution available or can i provide another like 1080p60? thanks

[pkfpeters]

so i was wondering while looking at your work if someone wanted to implement your work if it is a direct replacement of stock directories with your directories and during the unpacking some files were flagged as being the same with one set of those files iwith lower case filenames and the other with upper case filenames. i chose to not replace the uppercase with the lowercase. was that the correct choice? also the screen resolution listed in your Uenv.txt, is that the only resolution available or can i provide another like 1080p60? thanks

Sorry i just found out, that some files (in the netfilter kernel modules directory) are duplicated in the tar.gz You should be safe if you
select the latest version. I will make a new .tar.gz tomorrow. I did not disable any device driver option, so you should be able to select other resolutions. Although i only tested with the one in the config (i think 720p50).

Hopefully other people who are also having bootup problems can test with this kernel (settings) and let us know if it fixed the bootup problem.
This is still a workaround, but once confirmed working helps in finding a real solution.

If i have some time left i will also do some power measurements with a scope to see how the 5Volt line is behavng at startup. Just to rule out power issues that people are reporting. I don't know if anybody has done this already?