> From: <s_g...@telus.net> > Date: Fri, 1 Feb 2019 14:29:28 -0800 > > How is the cpu voltage and cpu clock speed set on arm64? How can I tell what > is set? > I would like to try running the orangepi pc2 with a higher voltage and > lower speed to see if it becomes stable. > > As Artturi pointed out there is much discussion about the speed capabilities > or lack thereof on the h5 SOC.
Changing the CPU clock frequency and voltage is supported on arm64 if: 1. The CPU nodes in the DT have a "operating-points-v2" property. 2. There is a driver that implements setting the frequency of associated clock. 3. There is a driver that implements setting the voltage of the associated voltage regulator. I implemented 3) in sxiccmu(4), and sypwr(4) implements 2 for the OrangePi PC2. So if your DT has 1), it should work. You can change the speed using sysctl hw.serperf. This is a percentage between 0 and 100. You can see the resulting clock speed by using sysctl hw.cpuspeed. If you want to change the operating points you'll have to edit the DT. Cheers, Mark > -----Original Message----- > From: s_g...@telus.net <s_g...@telus.net> > Sent: January 31, 2019 11:05 PM > To: 'Artturi Alm' <artturi....@gmail.com>; 'Mark Kettenis' > <mark.kette...@xs4all.nl> > Cc: 'patr...@blueri.se' <patr...@blueri.se>; 'arm@openbsd.org' > <arm@openbsd.org> > Subject: RE: crashes on orangepi pc2 > > I managed to change the Armbian dtb to set the cpu voltage to 1.3v: > > sypwr0 at iic0 addr 0x65: 1.30 VDC > > But it did not change anything - still crashes in perl when trying to add > packages. > > Does the openbsd kernel change cpu power and speed to minimize power > consumption? > > -----Original Message----- > From: s_g...@telus.net <s_g...@telus.net> > Sent: January 31, 2019 12:58 PM > To: 'Artturi Alm' <artturi....@gmail.com>; 'Mark Kettenis' > <mark.kette...@xs4all.nl> > Cc: 'patr...@blueri.se' <patr...@blueri.se>; 'arm@openbsd.org' > <arm@openbsd.org> > Subject: RE: crashes on orangepi pc2 > > 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. > > > > > > > > > > > > >
