I borrowed the dtb from the Armbian system (attached file) and it ran for quite a bit longer than with the stock dtb, but then crashed in the middle of adding php. It got through adding nano and wget.
The Armbian dtb also exposed the temperature sensors and the gpio voltage controller: sypwr0 at iic0 addr 0x65: 1.20 VDC oppc2obsd$ sysctl hw.sensors hw.sensors.sxitemp0.temp0=35.54 degC (CPU) hw.sensors.sxitemp0.temp1=36.61 degC (GPU) I am now getting oppc2obsd$ dwxe_watchdog and the lan connection no loner works. I had set up ntpd to set the time on boot which worked. oppc2obsd$ tail /var/log/daemon Jan 31 12:42:52 oppc2obsd ntpd[85416]: set local clock to Thu Jan 31 12:42:52 PST 2019 (offset 594.341118s) Jan 31 12:42:53 oppc2obsd savecore: no core dump Jan 31 12:43:11 oppc2obsd ntpd[98046]: peer 204.11.201.12 now valid Jan 31 12:43:14 oppc2obsd ntpd[98046]: peer 38.229.71.1 now valid Jan 31 12:43:15 oppc2obsd ntpd[98046]: peer 45.79.187.10 now valid Jan 31 12:43:17 oppc2obsd ntpd[98046]: peer 23.131.160.7 now valid Jan 31 12:43:40 oppc2obsd ntpd[98046]: peer 45.79.187.10 now invalid Jan 31 12:43:41 oppc2obsd ntpd[98046]: peer 38.229.71.1 now invalid Jan 31 12:43:42 oppc2obsd ntpd[98046]: peer 204.11.201.12 now invalid Jan 31 12:43:48 oppc2obsd ntpd[98046]: peer 23.131.160.7 now invalid oppc2obsd$ -----Original Message----- From: Artturi Alm <artturi....@gmail.com> Sent: January 31, 2019 11:46 AM To: Mark Kettenis <mark.kette...@xs4all.nl> Cc: s_g...@telus.net; patr...@blueri.se; arm@openbsd.org Subject: Re: crashes on orangepi pc2 On Thu, Jan 31, 2019 at 08:20:21PM +0100, Mark Kettenis wrote: > > From: <s_g...@telus.net> > > Date: Thu, 31 Jan 2019 11:04:25 -0800 > > > > It seems to be related to network usage, although I cannot confirm that. > > Interesting... > > The crash always seems to involve perl as far as I can tell. I've > seen it crash in the daily job as well. That doesn't rule out there > is some network-related corrpution going on though. > > > As to the unstableness, I loaded Armbian, download, installed and > > ran xfce and Firefox, all without problems. > > > > Something else that I notice is that the boot sometimes fails and I > > have to power off and on again to get it going. > > I think I've seen that as well. Seems U-Boot/ATF doesn't properly > reset the SoC. I believe this is fixed in newer ATF versions. > H5 has some known issues, some u-boots might come w/correct combination of voltage+freq(cpu+ddr), but apparently[0] ppl hacking on these with linux aren't yet sure about what it is either, and it's likely not the same for all revisions(later revs have the voltage adjustable via gpio). -Artturi ps. these issues have been chatted about for some time, i just linked to the most recent one from today i saw. [0]: https://freenode.irclog.whitequark.org/linux-sunxi/2019-01-31#23970760; > > Stops after this: > > > > U-Boot SPL 2019.01 (Jan 27 2019 - 23:00:53 -0700) > > DRAM: 1024 MiB > > Trying to boot from MMC1 > > > > I am going to experiment with different u-boots and dtbs. > > > > Should the dtb be put into the dos partition in the allwinner directory? > > Yes. > > > -----Original Message----- > > From: owner-...@openbsd.org <owner-...@openbsd.org> On Behalf Of Patrick Wildt > > Sent: January 31, 2019 7:11 AM > > To: Mark Kettenis <mark.kette...@xs4all.nl> > > Cc: s_g...@telus.net; arm@openbsd.org > > Subject: Re: crashes on orangepi pc2 > > > > On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote: > > > > From: <s_g...@telus.net> > > > > Date: Wed, 30 Jan 2019 23:11:00 -0800 > > > > > > > > I thought I would give openbsd arm64 a try and purchased an orangepi pc2. > > > > I followed the INSTALL directions and the install of the system went > > > > smoothly. > > > > I used the lan connection at 1000Mbps to load the system install packages. > > > > > > > > Simple things like top and df worked fine. Then I tried to add a package > > > > which resulted in the crash detailed below. > > > > Since the kernel on the miniroot seemed to download the installation > > > > packages I rebooted to the > > > > bsd.sp kernel and tested again with the same results. File systems had to be > > > > repaired and it looks like the pkg db was corrupted also. > > > > But the crash was very similar. See bsd.sp below. > > > > > > > > Has anyone have any experiences with the orangepi pc2? The documentation > > > > suggests that it is a targeted machine. > > > > > > > > I noticed that the boot complains about the dtb when booting from power up: > > > > > > > > Scanning mmc 0:1... > > > > Found EFI removable media binary efi/boot/bootaa64.efi > > > > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > > > > Scanning disks on usb... > > > > > > > > Is this because there is no longer a dtb on the dos partition after the > > > > install recreates the partition? > > > > > > > > > > > > > > > > bsd.mp crash > > > > > > > > oppcsobsd# pkg_add nano > > > > quirks-3.83 signed on 2019-01-17T20:44:02Z > > > > quirks-3.83: ok > > > > nano-3.2:libiconv-1.14p3: ok > > > > nano-3.2:gettext-0.19.8.1p3: ok > > > > > > > > > > > > > > > > panic: amap_pp_adjref: negative reference count > > > > Stopped at panic+0x148: TID PID UID PRFLAGS PFLAGS > > > > C > > > > PU COMMAND > > > > *447051 73332 0 0x1015 0 2K perl > > > > db_enter() at panic+0x144 > > > > panic() at uvm_unmap_detach+0x7c > > > > uvm_unmap_detach() at uvmspace_exec+0x1d0 > > > > uvmspace_exec() at sys_execve+0x5a8 > > > > sys_execve() at svc_handler+0x264 > > > > svc_handler() at do_el0_sync+0x1b0 > > > > do_el0_sync() at handle_el0_sync+0x74 > > > > https://www.openbsd.org/ddb.html describes the minimum info required in bug > > > > reports. Insufficient info makes it difficult to find and fix bugs. > > > > ddb{2}> > > > > ddb{2}> > > > > ddb{2}> > > > > ddb{2}> trace > > > > db_enter() at panic+0x144 > > > > panic() at uvm_unmap_detach+0x7c > > > > uvm_unmap_detach() at uvmspace_exec+0x1d0 > > > > uvmspace_exec() at sys_execve+0x5a8 > > > > sys_execve() at svc_handler+0x264 > > > > svc_handler() at do_el0_sync+0x1b0 > > > > do_el0_sync() at handle_el0_sync+0x74 > > > > handle_el0_sync() at 0x1859d328e0 > > > > address 0x7ffffdd418 is invalid > > > > --- trap --- > > > > > > I see the exact same error on my Orange Pi PC2. It is still unclear > > > to me if this issue is specific to that board or a generic issue with > > > the Allwinner H5 SoC. I've never seen the error on the Allwinner A64 > > > though. > > > > > > > My NanoPi Neo2, which is H5 based as well, is also rather unstable. > > > > > > >
sun50i-h5-orangepi-pc2.dtb
Description: Binary data
