Wiadomość napisana przez [email protected] w dniu 31.01.2019, o godz. 21:57: > > 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)
Please see my post on ports@ group (I posted a patch for A64 enabling sxitemp), It should work for H5 with no additional changes, if you really want to have it. > > I am now getting > > oppc2obsd$ dwxe_watchdog I am not using separate DTB just the one built into u-boot-sunxi-with-spl.bin flashed on to SD card, I do not have any dump from serial console but I think I saw this one a few times on Pine A64+. I switched to WiFi dongle anyway and it is fine now. Other than that A64+ is stable. > > 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 <[email protected]> > Sent: January 31, 2019 11:46 AM > To: Mark Kettenis <[email protected]> > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: crashes on orangepi pc2 > > On Thu, Jan 31, 2019 at 08:20:21PM +0100, Mark Kettenis wrote: >>> From: <[email protected]> >>> 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: [email protected] <[email protected]> On Behalf Of Patrick > Wildt >>> Sent: January 31, 2019 7:11 AM >>> To: Mark Kettenis <[email protected]> >>> Cc: [email protected]; [email protected] >>> Subject: Re: crashes on orangepi pc2 >>> >>> On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote: >>>>> From: <[email protected]> >>>>> 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>
