Thank you for the reply.
1. The dtb from Armbian that I am using has the operating points property
and I think I have seen it on the dtb from packages.
cpus {
#address-cells = < 0x01 >;
#size-cells = < 0x00 >;
cpu@0 {
compatible = "arm,cortex-a53\0arm,armv8";
device_type = "cpu";
reg = < 0x00 >;
enable-method = "psci";
clocks = < 0x03 0x0e >;
clock-names = "cpu";
operating-points-v2 = < 0x30 >;
#cooling-cells = < 0x02 >;
cooling-min-level = < 0x00 >;
cooling-max-level = < 0x0f >;
cpu-supply = < 0x31 >;
phandle = < 0x2b >;
};
cpu@1 {
compatible = "arm,cortex-a53\0arm,armv8";
device_type = "cpu";
reg = < 0x01 >;
enable-method = "psci";
operating-points-v2 = < 0x30 >;
};
cpu@2 {
compatible = "arm,cortex-a53\0arm,armv8";
device_type = "cpu";
reg = < 0x02 >;
enable-method = "psci";
operating-points-v2 = < 0x30 >;
};
cpu@3 {
compatible = "arm,cortex-a53\0arm,armv8";
device_type = "cpu";
reg = < 0x03 >;
enable-method = "psci";
operating-points-v2 = < 0x30 >;
};
};
2. Clock driver is there.
3. The dtb has a block for the voltage regulator and I changed the fixed
voltage to make it 1.3v. The original had 1.2v.
The packages dtb does not have this block.
i2c@1f02400 {
compatible = "allwinner,sun6i-a31-i2c";
reg = < 0x1f02400 0x400 >;
interrupts = < 0x00 0x2c 0x04 >;
pinctrl-names = "default";
pinctrl-0 = < 0x28 >;
clocks = < 0x26 0x09 >;
resets = < 0x26 0x05 >;
status = "okay";
#address-cells = < 0x01 >;
#size-cells = < 0x00 >;
phandle = < 0x66 >;
regulator@65 {
compatible = "silergy,sy8106a";
reg = < 0x65 >;
regulator-name = "vdd-cpux";
silergy,fixed-microvolt = < 0x13d620 >;
regulator-min-microvolt = < 0xf4240 >;
regulator-max-microvolt = < 0x155cc0 >;
regulator-ramp-delay = < 0xc8 >;
regulator-boot-on;
regulator-always-on;
phandle = < 0x31 >;
};
};
sxitwi0 at simplebus0
iic0 at sxitwi0
sypwr0 at iic0 addr 0x65: 1.30 VDC
On startup the system has:
oppc2opbsd# sysctl hw
hw.machine=arm64
hw.model=ARM Cortex-A53 r0p4
hw.ncpu=4
hw.byteorder=1234
hw.pagesize=4096
hw.disknames=sd0:1e111df47ad2925f
hw.diskcount=1
hw.sensors.sxitemp0.temp0=33.39 degC (CPU)
hw.sensors.sxitemp0.temp1=34.23 degC (GPU)
hw.cpuspeed=816
hw.setperf=56
hw.product=Xunlong Orange Pi PC 2
hw.physmem=944402432
hw.usermem=944390144
hw.ncpufound=4
hw.allowpowerdown=1
hw.perfpolicy=manual
hw.ncpuonline=4
which would imply that the max cpu frequency is 1300Mhz.
I set the cpu speed to 25%
oppc2opbsd# sysctl hw.setperf=25
hw.setperf: 100 -> 25
oppc2opbsd# sysctl hw.cpuspeed
hw.cpuspeed=240
I expected about 325 but the multipliers might not work out..
Anyway with this speed setting and voltage at 1.3v, I started to add
packages and soon crashed in perl as before.
At the 25% speed setting the idle temperatures are:
oppc2opbsd# sysctl hw.sensors
hw.sensors.sxitemp0.temp0=32.80 degC (CPU)
hw.sensors.sxitemp0.temp1=33.99 degC (GPU)
At 100% speed idle temperatures are:
oppc2opbsd# sysctl hw.sensors
hw.sensors.sxitemp0.temp0=38.28 degC (CPU)
hw.sensors.sxitemp0.temp1=38.28 degC (GPU)
I have to think that the crashes are not due to cpu speed or power.
Stephen Graf.
----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Mark
Kettenis
Sent: February 1, 2019 3:44 PM
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: crashes on orangepi pc2
> From: <[email protected]>
> 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: [email protected] <[email protected]>
> Sent: January 31, 2019 11:05 PM
> To: 'Artturi Alm' <[email protected]>; 'Mark Kettenis'
> <[email protected]>
> Cc: '[email protected]' <[email protected]>; '[email protected]'
> <[email protected]>
> 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: [email protected] <[email protected]>
> Sent: January 31, 2019 12:58 PM
> To: 'Artturi Alm' <[email protected]>; 'Mark Kettenis'
> <[email protected]>
> Cc: '[email protected]' <[email protected]>; '[email protected]'
> <[email protected]>
> 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 <[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.
> > >
> > >
> > >
> >
>
>
