Struggling to boot up

[tsago]

edit-2: Issue resolved by reflashing an image onto eMMC outside of the PBP, via a usb-to-eMMC adapter. So it was a human error after all. 

---

I'm trying to boot via SD card, as the current bootability status of the eMMC is unclear. 
Here's a log of my woes:

etcher 1.5.59, Win 10
pinebookpro-debian-desktop-mrfixit-190905.img.xz

older SD -  sandisk 8GB

boot #1:
waited 2 mins after "Starting kernel", nothing.
screen was black, power led on

boot #2:
same issue

boot #3:
same issue

=============
new SD - sandisk 16G (A)

boot #4:
screen on
stuck -> [  OK  ] Started Boot and Home Patition Mount Service.

boot #5:
screen on
stuck Starting kernel ...

boot #6:
screen on
stuck -> [    0.653905] pwm-backlight edp-backlight: using lookup tables for GPIO lookup

boot #7:
screen on
stuck -> Starting kernel ...

==> emmc switch DOWN (I'm assuming "down", towards the mousepad is "off")

boot #8:
screen OFF
stuck -> Starting kernel ...

==> emmc switch UP
boot #9:
screen ON
stuck -> Starting kernel ...

==> emmc REMOVED
boot #10:
screen ON, "open sesame", ON(black), power led OFF
stuck -> "Starting Daily apt download activities..."


boot #11:
kernel panic, reboot, reboot, LOGIN SCREEN reached
-> login, do nothing for a bit
-> shut down (power button -> click shut down)

boot #12:
screen ON
stuck -> "Starting udev Coldplug all Devices..."

Any ideas? I'm about to jump off a cliff... Serial console logs of all boot attempts attached.


edit: turns out I failed to attach the boot logs. Attached now.

[tsago]

Edited extlinux.conf and removed "quiet loglevel=3", got this result. If anyone has any tips, I would really appreciate that.

Code:

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.4.190 (adam@adam-vb) (gcc version 7.1.1 20170707 (Linaro GCC 7.1-2017.08) ) #1 SMP Tue Sep 3 20:36:12 EDT 2019
[    0.000000] Boot CPU: AArch64 Processor [410fd034]
[    0.000000] earlycon: Early serial console at MMIO32 0xff1a0000 (options '')
[    0.000000] bootconsole [uart0] enabled
[    0.000000] Reserved memory: failed to reserve memory for node 'drm-logo@00000000': base 0x0000000000000000, size 0 MiB
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.0 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] PERCPU: Embedded 21 pages/cpu @ffffffc0f7ed2000 s46056 r8192 d31768 u86016
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: enabling workaround for ARM erratum 845719
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 999432
[    0.000000] Kernel command line: console=ttyS2,1500000n8 rw root=/dev/mmcblk0p2 rootwait rootfstype=ext4 panic=10 init=/sbin/init coherent_pool=1M ethaddr=c2:64:53:7b:27:d4 eth1addr=c2:64:53:7b:27:f4 serial=a6a15fd9caa02ca cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 zswap.enabled=1 video=HDMI-A-1:1920x1080@60 video=eDP-1:1920x1080@60 vga=current earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 usbcore.autosuspend=-1 net.ifnames=0
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.000000] software IO TLB: mapped [mem 0xf7e8a000-0xf7eca000] (0MB)
[    0.000000] Memory: 3961876K/4061184K available (15614K kernel code, 2182K rwdata, 6152K rodata, 1216K init, 744K bss, 99308K reserved, 0K cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     modules : 0xffffff8000000000 - 0xffffff8008000000   (   128 MB)
[    0.000000]     vmalloc : 0xffffff8008000000 - 0xffffffbdbfff0000   (   246 GB)
[    0.000000]       .init : 0xffffff80095d0000 - 0xffffff8009700000   (  1216 KB)
[    0.000000]       .text : 0xffffff8008080000 - 0xffffff8008fc0000   ( 15616 KB)
[    0.000000]     .rodata : 0xffffff8008fc0000 - 0xffffff80095d0000   (  6208 KB)
[    0.000000]       .data : 0xffffff8009700000 - 0xffffff8009921808   (  2183 KB)
[    0.000000]     vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000   (     8 GB maximum)
[    0.000000]               0xffffffbdc0008000 - 0xffffffbdc3e00000   (    61 MB actual)
[    0.000000]     fixed   : 0xffffffbffe7fb000 - 0xffffffbffec00000   (  4116 KB)
[    0.000000]     PCI I/O : 0xffffffbffee00000 - 0xffffffbfffe00000   (    16 MB)
[    0.000000]     memory  : 0xffffffc000200000 - 0xffffffc0f8000000   (  3966 MB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  Build-time adjustment of leaf fanout to 64.
[    0.000000]  RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=6.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=6
[    0.000000] NR_IRQS:64 nr_irqs:64 0
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] ITS: /interrupt-controller@fee00000/interrupt-controller@fee20000
[    0.000000] ITS: allocated 65536 Devices @f3080000 (psz 64K, shr 0)
[    0.000000] ITS: using cache flushing for cmd queue
[    0.000000] GIC: using LPI property table @0x00000000f3010000
[    0.000000] ITS: Allocated 1792 chunks for LPIs
[    0.000000] CPU0: found redistributor 0 region 0:0x00000000fef00000
[    0.000000] CPU0: using LPI pending table @0x00000000f3020000
[    0.000000] GIC: using cache flushing for LPI property table
[    0.000000] GIC: PPI partition interrupt-partition-0[0] { /cpus/cpu@0[0] /cpus/cpu@1[1] /cpus/cpu@2[2] /cpus/cpu@3[3] }
[    0.000000] GIC: PPI partition interrupt-partition-1[1] { /cpus/cpu@100[4] /cpus/cpu@101[5] }

[zaius]

Please see here:

https://forum.pine64.org/showthread.php?tid=8162

[tsago]

Please see here:

https://forum.pine64.org/showthread.php?tid=8162

Hi zaius, thanks for the idea! I take it you meant to point out the dead-beef-02 UUID, right?
I noticed that too, but I assumed that it's a placeholder that somehow gets overidden on boot (by the u-boot code?).
When I look at the boot logs it does seem to get updated indeed:

Code:

[    0.000000] Kernel command line: console=ttyS2,1500000n8 rw root=/dev/mmcblk0p2 rootwait

Seems correct? (afaik SD is mmcblk0, eMMC is mmcblk1; at least when checking this from a working install some days ago)
Anyway, it won't hurt to try, especially since others reported this working. I'll update once I'm back home and finished with the test.

[tsago]

Got back home to edit the extlinux.conf file again... turns out the file was automatically modified on last night's boot to `root=/dev/mmcblk0p2`.
Makes me wonder whether that was what actually helped the others in the linked thread...

[tsago]

Interim update, if anyone's interested.
I can boot up fairly reliably when the eMMC is disabled. When enabled, I always get stuck on something after "Starting kernel", regardless of what image I try to boot from with an SD card. Currently waiting for an USB-to-eMMC adapter to wipe the eMMC and then dd some working image onto it.

[zaius]

Interim update, if anyone's interested.
I can boot up fairly reliably when the eMMC is disabled. When enabled, I always get stuck on something after "Starting kernel", regardless of what image I try to boot from with an SD card. Currently waiting for an USB-to-eMMC adapter to wipe the eMMC and then dd some working image onto it.

So are you are saying the Ubuntu images won't boot from SD either?

[tsago]

Interim update, if anyone's interested.
I can boot up fairly reliably when the eMMC is disabled. When enabled, I always get stuck on something after "Starting kernel", regardless of what image I try to boot from with an SD card. Currently waiting for an USB-to-eMMC adapter to wipe the eMMC and then dd some working image onto it.

So are you are saying the Ubuntu images won't boot from SD either?

With the eMMC enabled an slotted in, I tried the ChromiumOS, "default" debina, and bionic lxde (ayufan). Neither was able to boot.
Once I disable/remove the eMMC, I am able to boot into Chromium, bionic-lxde (haven't tried the default debian yet).
Seems like I somehow messed up the data on the eMMC enough to prevent me from booting in any way with it in.

[electriccrowbar]

Seems like I somehow messed up the data on the eMMC enough to prevent me from booting in any way with it in.

Well you're not alone there. I'm having the same problem. With the eMMC on I get stuck in a very early boot loop. I don't have a serial cable to verify exactly where. (though i may make one)

Additionally I have been unable to boot the stock debian image from SD cards at all. It's failing to boot so early in the process that the power light wont even come on.

[Depau]

I seem to be having the same issue.

This is the ticket I opened to support desk, with a lot of info and logs I retrieved from UART: https://notes.depau.eu/kZh232qERoWN9WlKs_jV8Q

Now it usually gets stuck like this (removed quiet loglevel=3 from cmdline): https://pastebin.com/PQW193b9

Last time I tried I also got this kernel oops which mentions mmc in the stacktrace: https://notes.depau.eu/NYazVHnZQ-O4z4CH1P5dag

A friend suggests it might be a RAM/RAM initialization issue.