Re: crashes on orangepi pc2 - results at low speed and high voltage

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: crashes on orangepi pc2 - results at low speed and high voltage

s_graf
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: [hidden email] <[hidden email]> On Behalf Of Mark
Kettenis
Sent: February 1, 2019 3:44 PM
To: [hidden email]
Cc: [hidden email]; [hidden email]; [hidden email]
Subject: Re: crashes on orangepi pc2

> From: <[hidden email]>
> 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: [hidden email] <[hidden email]>
> Sent: January 31, 2019 11:05 PM
> To: 'Artturi Alm' <[hidden email]>; 'Mark Kettenis'
> <[hidden email]>
> Cc: '[hidden email]' <[hidden email]>; '[hidden email]'
> <[hidden email]>
> 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: [hidden email] <[hidden email]>
> Sent: January 31, 2019 12:58 PM
> To: 'Artturi Alm' <[hidden email]>; 'Mark Kettenis'
> <[hidden email]>
> Cc: '[hidden email]' <[hidden email]>; '[hidden email]'
> <[hidden email]>
> 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 <[hidden email]>
> Sent: January 31, 2019 11:46 AM
> To: Mark Kettenis <[hidden email]>
> Cc: [hidden email]; [hidden email]; [hidden email]
> Subject: Re: crashes on orangepi pc2
>
> On Thu, Jan 31, 2019 at 08:20:21PM +0100, Mark Kettenis wrote:
> > > From: <[hidden email]>
> > > 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: [hidden email] <[hidden email]> On Behalf Of
Patrick

> Wildt
> > > Sent: January 31, 2019 7:11 AM
> > > To: Mark Kettenis <[hidden email]>
> > > Cc: [hidden email]; [hidden email]
> > > Subject: Re: crashes on orangepi pc2
> > >
> > > On Thu, Jan 31, 2019 at 11:26:48AM +0100, Mark Kettenis wrote:
> > > > > From: <[hidden email]>
> > > > > 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.
> > >
> > >
> > >
> >
>
>