Re: Wandboard Quad can't boot anymore

2016-08-31 Thread Joe Gidi
Thanks for the reply. I worked back through some previous snapshot kernels
and narrowed down the point where the problem was introduced:

Cold boot successful:
OpenBSD 6.0-current (GENERIC) #32: Tue Aug 23 03:13:41 MDT 2016

Cold boot hangs, warm boot ok:
OpenBSD 6.0-current (GENERIC) #34: Wed Aug 24 18:29:38 MDT 2016

I don't have kernel #33 (might not have been available as a snapshot).

Snapshot kernels subsequent to #34 all behave the same way: cold boots
hang, warm boots are successful.

It appears something is not being initialized properly on cold boots. I'll
have to go back through CVS commits to see if I can pinpoint a likely
cause.

Thanks,

On Wed, August 31, 2016 1:09 pm, Daniel Bolgheroni wrote:
> On Tue, Aug 30, 2016 at 08:44:44PM -0400, Joe Gidi wrote:
>> I suspect/fear that the answer might be, "your hardware died", but since
>> the armv7 port is under heavy development, maybe this information will
>> be
>> of some value to the devs...
>>
>> I've been running snapshots on my Wandboard Quad for the past few weeks
>> without incident. Sometime yesterday or last night, the system went down
>> (no response to pings or serial console) and wouldn't boot back up. I
>> pulled the SD card and mounted it in a working machine, and found
>> nothing
>> in the logs indicating what might have gone wrong.
>>
>> Both bsd and bsd.rd hang during boot, with this as the last line of
>> dmesg:
>>
>> simplebus5 at mainbus0: "regulators"
>
> It's not something specific to your hardware as I can see it too.
>
> --
> db


--
Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



Re: Wandboard Quad can't boot anymore

2016-08-31 Thread Daniel Bolgheroni
On Tue, Aug 30, 2016 at 08:44:44PM -0400, Joe Gidi wrote:
> I suspect/fear that the answer might be, "your hardware died", but since
> the armv7 port is under heavy development, maybe this information will be
> of some value to the devs...
> 
> I've been running snapshots on my Wandboard Quad for the past few weeks
> without incident. Sometime yesterday or last night, the system went down
> (no response to pings or serial console) and wouldn't boot back up. I
> pulled the SD card and mounted it in a working machine, and found nothing
> in the logs indicating what might have gone wrong.
> 
> Both bsd and bsd.rd hang during boot, with this as the last line of dmesg:
> 
> simplebus5 at mainbus0: "regulators"

It's not something specific to your hardware as I can see it too.

-- 
db



Wandboard Quad can't boot anymore

2016-08-30 Thread Joe Gidi
I suspect/fear that the answer might be, "your hardware died", but since
the armv7 port is under heavy development, maybe this information will be
of some value to the devs...

I've been running snapshots on my Wandboard Quad for the past few weeks
without incident. Sometime yesterday or last night, the system went down
(no response to pings or serial console) and wouldn't boot back up. I
pulled the SD card and mounted it in a working machine, and found nothing
in the logs indicating what might have gone wrong.

Both bsd and bsd.rd hang during boot, with this as the last line of dmesg:

simplebus5 at mainbus0: "regulators"

>From previous successful boots, this should be followed by:

scsibus1 at sdmmc2: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0:  SCSI2 0/direct fixed
sd0: 61056MB, 512 bytes/sector, 125042688 sectors
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
boot device: sd0
root on sd0a (3c6fd48d06a0.a) swap on sd0b dump on sd0b
WARNING: CHECK AND RESET THE DATE!

While I had the SD card out, I copied over the latest snapshot bsd.rd,
which also hangs at the same point.

As I said, I suspect bad hardware. The only reason why I suspect there
*might* be a software issue is that the machine has had nothing but warm
boots for the past few weeks. I pulled the power plug to reset the machine
this morning, and that's the first time it's had a cold boot since the
initial installation. Maybe something's not initializing properly from a
cold boot?

Is there anything worthwhile I can provide to the developers before
pursuing warranty replacement?

Following is the complete dmesg, up to the point of hanging:

Connected to /dev/cuaU0 (speed 115200)

U-Boot SPL 2016.07 (Aug 06 2016 - 00:03:39)
Trying to boot from MMC1


U-Boot 2016.07 (Aug 06 2016 - 00:03:39 -0600)

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
Reset cause: POR
Board: Wandboard rev C1
I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment

No panel detected: default to HDMI
Display: HDMI (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
reading /imx6q-wandboard.dtb
32385 bytes read in 19 ms (1.6 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
reading efi/boot/bootarm.efi
65276 bytes read in 27 ms (2.3 MiB/s)
## Starting EFI application at 0x1200 ...
Scanning disks on usb...
Scanning disks on mmc...
MMC: no card present
MMC Device 2 not found
MMC Device 3 not found
Found 5 disks
>> OpenBSD/armv7 BOOTARM 0.1
boot> bsd.rd
booting sd0a:bsd.rd: 2161764+7975440+428488 [64+309040+151709]=0xa8455c

OpenBSD/armv7 booting ...
arg0 0x1000 arg1 0x113c arg2 0x1800
Allocating page tables
freestart = 0x10d85000, free_pages = 520827 (0x0007f27b)
IRQ stack: p0x10db3000 v0xc0db3000
ABT stack: p0x10db4000 v0xc0db4000
UND stack: p0x10db5000 v0xc0db5000
SVC stack: p0x10db6000 v0xc0db6000
Creating L1 page table at 0x10d88000
Mapping kernel
Constructing L2 page tables
undefined page pmap board type: 4412
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2016 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 6.0-current (RAMDISK) #21: Sun Aug 28 18:06:23 MDT 2016
dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/RAMDISK
real mem  = 2147483648 (2048MB)
avail mem = 2091839488 (1994MB)
mainbus0 at root: Wandboard i.MX6 Quad Board
cpu0 at mainbus0: ARM Cortex A9 R2 rev 10 (ARMv7 core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB(32b/l,4way) I-cache, 32KB(32b/l,4way) wr-back D-cache
cortex0 at mainbus0
amptimer0 at cortex0: tick rate 396000 KHz
armliicc0 at cortex0: rtl 7 waymask: 0x000f
imx0 at mainbus0
imxccm0 at imx0: imx6 rev 1.5 CPU freq: 792 MHz
imxiomuxc0 at imx0
imxocotp0 at imx0
simplebus0 at mainbus0: "soc"
ampintc0 at simplebus0 nirq 160
simplebus1 at simplebus0: "aips-bus"
simplebus2 at simplebus1: "spba-bus"
imxuart0 at simplebus2: console
imxgpio0 at simplebus1
imxgpio1 at simplebus1
imxgpio2 at simplebus1
imxgpio3 at simplebus1
imxgpio4 at simplebus1
imxgpio5 at simplebus1
imxgpio6 at simplebus1
imxdog0 at simplebus1
simplebus3 at simplebus1: "anatop"
imxgpc0 at simplebus1
simplebus4 at simplebus0: "aips-bus"
imxehci0 at simplebus4
usb0 at imxehci0: USB revision 2.0
uhub0 at usb0 "i.MX6 EHCI root hub" rev 2.00/1.00 addr 1
imxehci1 at simplebus4
usb1 at imxehci1: USB revision 2.0
uhub1 at usb1 "i.MX6 EHCI root hub" rev 2.00/1.00 addr 1
fec0 at simplebus4
fec0: address 00:1f:7b:b4:22:5f
atphy0 at fec0 phy 1: AR8035 10/100/1000 PHY, rev. 4
imxesdhc0 at simplebus4
imxesdhc0: 198 MHz base clock
sdmmc0 at imxesdhc0: 4-bit, mmc high-speed, dma
imxesdhc1 at simplebus4
imxesdhc1: 198 MHz base clock
sdmmc1 at imxesdhc1: 4-bit, mmc high-speed, dma
imxesdhc2 at s