initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

s_graf
I just realized that the cpu speed on these boards defaults on start-up, the
pc2 to 816Mhz and the one to 1008 Mhz. Both of these machines should be able
to run at 1300Mhz.
The pc2 speed can be changed with hw.setperf, but not the one.
Can the sxiccmu module be changed to read a value from the dtb to use as the
initial cpu speed?

Reply | Threaded
Open this post in threaded view
|

Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

Krystian Lewandowski
Wiadomość napisana przez [hidden email] w dniu 02.02.2019, o godz. 18:26:
>
> I just realized that the cpu speed on these boards defaults on start-up, the
> pc2 to 816Mhz and the one to 1008 Mhz. Both of these machines should be able
> to run at 1300Mhz.
> The pc2 speed can be changed with hw.setperf, but not the one.
> Can the sxiccmu module be changed to read a value from the dtb to use as the
> initial cpu speed?
>

Does the DT for OrangePi One have the "operating-points-v2" property?

It seems H3 is already supported by OpenBSD:
https://github.com/openbsd/src/blob/master/sys/dev/fdt/sxiccmu.c#L110

--
Krystian

Reply | Threaded
Open this post in threaded view
|

FW: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

s_graf
In reply to this post by s_graf


-----Original Message-----
From: [hidden email] <[hidden email]>
Sent: February 2, 2019 11:29 AM
To: 'Krystian Lewandowski' <[hidden email]>
Subject: RE: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

Thank you for your reply.
The stock dtbs do not have the "operating-points-v2" and it follows that there is no frequency set by the dtb.
Can you point me to a dtb block that has the property with an example of setting the frequency.

One dtb:
                clock@1c20000 {
                        reg = < 0x1c20000 0x400 >;
                        clocks = < 0x0e 0x0f >;
                        clock-names = "hosc\0losc";
                        #clock-cells = < 0x01 >;
                        #reset-cells = < 0x01 >;
                        compatible = "allwinner,sun8i-h3-ccu";
                        phandle = < 0x03 >;
                };

Pc2 dtb:

                clock@1c20000 {
                        reg = < 0x1c20000 0x400 >;
                        clocks = < 0x0e 0x0f >;
                        clock-names = "hosc\0losc";
                        #clock-cells = < 0x01 >;
                        #reset-cells = < 0x01 >;
                        compatible = "allwinner,sun50i-h5-ccu";
                        phandle = < 0x03 >;
                };

Stephen Graf

-----Original Message-----
From: Krystian Lewandowski <[hidden email]>
Sent: February 2, 2019 10:53 AM
To: [hidden email]
Cc: [hidden email]
Subject: Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

Wiadomość napisana przez [hidden email] w dniu 02.02.2019, o godz. 18:26:
>
> I just realized that the cpu speed on these boards defaults on start-up, the
> pc2 to 816Mhz and the one to 1008 Mhz. Both of these machines should be able
> to run at 1300Mhz.
> The pc2 speed can be changed with hw.setperf, but not the one.
> Can the sxiccmu module be changed to read a value from the dtb to use as the
> initial cpu speed?
>

Does the DT for OrangePi One have the "operating-points-v2" property?

It seems H3 is already supported by OpenBSD:
https://github.com/openbsd/src/blob/master/sys/dev/fdt/sxiccmu.c#L110

--
Krystian

Reply | Threaded
Open this post in threaded view
|

Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

Krystian Lewandowski
Wiadomość napisana przez [hidden email] w dniu 02.02.2019, o godz. 21:30:

>
>
>
> -----Original Message-----
> From: [hidden email] <[hidden email]>
> Sent: February 2, 2019 11:29 AM
> To: 'Krystian Lewandowski' <[hidden email]>
> Subject: RE: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards
>
> Thank you for your reply.
> The stock dtbs do not have the "operating-points-v2" and it follows that there is no frequency set by the dtb.
> Can you point me to a dtb block that has the property with an example of setting the frequency.
>

Maybe this one?
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/sun8i-h3.dtsi#L46 <https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/sun8i-h3.dtsi#L46>

--
Krystian

> One dtb:
>                clock@1c20000 {
>                        reg = < 0x1c20000 0x400 >;
>                        clocks = < 0x0e 0x0f >;
>                        clock-names = "hosc\0losc";
>                        #clock-cells = < 0x01 >;
>                        #reset-cells = < 0x01 >;
>                        compatible = "allwinner,sun8i-h3-ccu";
>                        phandle = < 0x03 >;
>                };
>
> Pc2 dtb:
>
>                clock@1c20000 {
>                        reg = < 0x1c20000 0x400 >;
>                        clocks = < 0x0e 0x0f >;
>                        clock-names = "hosc\0losc";
>                        #clock-cells = < 0x01 >;
>                        #reset-cells = < 0x01 >;
>                        compatible = "allwinner,sun50i-h5-ccu";
>                        phandle = < 0x03 >;
>                };
>
> Stephen Graf
>
> -----Original Message-----
> From: Krystian Lewandowski <[hidden email]>
> Sent: February 2, 2019 10:53 AM
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards
>
> Wiadomość napisana przez [hidden email] w dniu 02.02.2019, o godz. 18:26:
>>
>> I just realized that the cpu speed on these boards defaults on start-up, the
>> pc2 to 816Mhz and the one to 1008 Mhz. Both of these machines should be able
>> to run at 1300Mhz.
>> The pc2 speed can be changed with hw.setperf, but not the one.
>> Can the sxiccmu module be changed to read a value from the dtb to use as the
>> initial cpu speed?
>>
>
> Does the DT for OrangePi One have the "operating-points-v2" property?
>
> It seems H3 is already supported by OpenBSD:
> https://github.com/openbsd/src/blob/master/sys/dev/fdt/sxiccmu.c#L110
>
> --
> Krystian
>

Reply | Threaded
Open this post in threaded view
|

Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

s_graf
In reply to this post by s_graf
On my pc2 I am using a dtb from Armbian that has operating points, but I am not sure if sxiccmu uses it.

 

Maybe Mark could comment.

 

It is interesting to note that Armbian sets the voltage to 1.3v at 816Mhz,

whereas Openbsd starts up at 816Mhz and 1.2v.

 

from Armbian dtb:

 

        opp_table0 {

                compatible = "operating-points-v2";

                opp-shared;

                phandle = < 0x30 >;

 

                opp@120000000 {

                        opp-hz = < 0x00 0x7270e00 >;

                        opp-microvolt = < 0xfde80 0xfde80 0x13d620 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@240000000 {

                        opp-hz = < 0x00 0xe4e1c00 >;

                        opp-microvolt = < 0xfde80 0xfde80 0x13d620 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@480000000 {

                        opp-hz = < 0x00 0x1c9c3800 >;

                        opp-microvolt = < 0xfde80 0xfde80 0x13d620 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@648000000 {

                        opp-hz = < 0x00 0x269fb200 >;

                        opp-microvolt = < 0xfde80 0xfde80 0x13d620 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@816000000 {

                        opp-hz = < 0x00 0x30a32c00 >;

                        opp-microvolt = < 0x10c8e0 0x10c8e0 0x13d620 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@960000000 {

                        opp-hz = < 0x00 0x39387000 >;

                        opp-microvolt = < 0x124f80 0x124f80 0x13d620 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@1008000000 {

                        opp-hz = < 0x00 0x3c14dc00 >;

                        opp-microvolt = < 0x124f80 0x124f80 0x13d620 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@1056000000 {

                        opp-hz = < 0x00 0x3ef14800 >;

                        opp-microvolt = < 0x142440 0x142440 0x142440 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@1104000000 {

                        opp-hz = < 0x00 0x41cdb400 >;

                        opp-microvolt = < 0x142440 0x142440 0x142440 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@1152000000 {

                        opp-hz = < 0x00 0x44aa2000 >;

                        opp-microvolt = < 0x142440 0x142440 0x142440 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@1200000000 {

                        opp-hz = < 0x00 0x47868c00 >;

                        opp-microvolt = < 0x142440 0x142440 0x142440 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@1224000000 {

                        opp-hz = < 0x00 0x48f4c200 >;

                        opp-microvolt = < 0x147260 0x147260 0x147260 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@1248000000 {

                        opp-hz = < 0x00 0x4a62f800 >;

                        opp-microvolt = < 0x147260 0x147260 0x147260 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@1296000000 {

                        opp-hz = < 0x00 0x4d3f6400 >;

                        opp-microvolt = < 0x147260 0x147260 0x147260 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@1344000000 {

                        opp-hz = < 0x00 0x501bd000 >;

                        opp-microvolt = < 0x155cc0 0x155cc0 0x155cc0 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

 

                opp@1368000000 {

                        opp-hz = < 0x00 0x518a0600 >;

                        opp-microvolt = < 0x155cc0 0x155cc0 0x155cc0 >;

                        clock-latency-ns = < 0x3b9b0 >;

                };

        };

 

 

                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 >;

                };

 

 

From: Krystian Lewandowski <[hidden email]>
Sent: February 2, 2019 12:44 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

 

Wiadomość napisana przez [hidden email] <mailto:[hidden email]>  w dniu 02.02.2019, o godz. 21:30:

 



-----Original Message-----
From: [hidden email] <mailto:[hidden email]>  <[hidden email] <mailto:[hidden email]> >
Sent: February 2, 2019 11:29 AM
To: 'Krystian Lewandowski' <[hidden email] <mailto:[hidden email]> >
Subject: RE: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

Thank you for your reply.
The stock dtbs do not have the "operating-points-v2" and it follows that there is no frequency set by the dtb.
Can you point me to a dtb block that has the property with an example of setting the frequency.

 

Maybe this one?

https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/sun8i-h3.dtsi#L46

 

--

Krystian





One dtb:
               clock@1c20000 {
                       reg = < 0x1c20000 0x400 >;
                       clocks = < 0x0e 0x0f >;
                       clock-names = "hosc\0losc";
                       #clock-cells = < 0x01 >;
                       #reset-cells = < 0x01 >;
                       compatible = "allwinner,sun8i-h3-ccu";
                       phandle = < 0x03 >;
               };

Pc2 dtb:

               clock@1c20000 {
                       reg = < 0x1c20000 0x400 >;
                       clocks = < 0x0e 0x0f >;
                       clock-names = "hosc\0losc";
                       #clock-cells = < 0x01 >;
                       #reset-cells = < 0x01 >;
                       compatible = "allwinner,sun50i-h5-ccu";
                       phandle = < 0x03 >;
               };

Stephen Graf

-----Original Message-----
From: Krystian Lewandowski <[hidden email] <mailto:[hidden email]> >
Sent: February 2, 2019 10:53 AM
To: [hidden email] <mailto:[hidden email]>
Cc: [hidden email] <mailto:[hidden email]>
Subject: Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

Wiadomość napisana przez [hidden email] <mailto:[hidden email]>  w dniu 02.02.2019, o godz. 18:26:




I just realized that the cpu speed on these boards defaults on start-up, the
pc2 to 816Mhz and the one to 1008 Mhz. Both of these machines should be able
to run at 1300Mhz.
The pc2 speed can be changed with hw.setperf, but not the one.
Can the sxiccmu module be changed to read a value from the dtb to use as the
initial cpu speed?


Does the DT for OrangePi One have the "operating-points-v2" property?

It seems H3 is already supported by OpenBSD:
https://github.com/openbsd/src/blob/master/sys/dev/fdt/sxiccmu.c#L110

--
Krystian

 

Reply | Threaded
Open this post in threaded view
|

Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

Mark Kettenis
Any OS will boot with the CPU clock frequency and voltage that was set
up by the firmware/bootloader.  Those are supposed to be "safe"
settings in the sense that the OS can run without overheating the SoC.

If the DT provides a set of operating points, and there is clock and
regulator support, OpenBSD will allow changing the clock frequency.
For each frequency it will select the associated voltage in the
operating points table.  When there is support for changing the clock
frequency, OpenBSD will switch to the operating point that has an
associated clock frequency that not higher than the clock frequency
the system booted with.

Reply | Threaded
Open this post in threaded view
|

Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

s_graf
In reply to this post by s_graf
Thank you for the information. I can now see where the various frequencies
come from when I change setperf.
Is it possible to see the cpu voltage anywhere, to go along with the
hw.cpuspeed?

I want to do further testing with the stress program as I do not think the
H5 stability problems are to do with speed/voltage.
I suspect something to do with network.  I started out with the dwxe0 lan
plugged into a 1000Mhz switch and failures were quite often. I then
downgraded to a 100Mhz port and the system seemed to hang in there longer.
I then tested with an old usb wifi adapter(run0) which was very slow and the
system behaved even better, although it did fail in the same fashion.

Has anyone tried to trace back the crash reports?  It always seems to be a
consistent crash no matter the program that was running.

Stephen Graf

-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of Mark
Kettenis
Sent: February 3, 2019 11:54 AM
To: [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: initial cpu speed on orangepi one and orangepi pc2 - probably
other H5 and H3 boards

Any OS will boot with the CPU clock frequency and voltage that was set
up by the firmware/bootloader.  Those are supposed to be "safe"
settings in the sense that the OS can run without overheating the SoC.

If the DT provides a set of operating points, and there is clock and
regulator support, OpenBSD will allow changing the clock frequency.
For each frequency it will select the associated voltage in the
operating points table.  When there is support for changing the clock
frequency, OpenBSD will switch to the operating point that has an
associated clock frequency that not higher than the clock frequency
the system booted with.


Reply | Threaded
Open this post in threaded view
|

Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

Megan
I am seeing what looks like the same issue, also with an Orange Pi PC 2,
on both 6.8 and snapshot.  Is it worth filing another bug report on this?

Has there been any progress on this since this was raised?

Thanks
Megan

On 2/4/19 2:48 PM, [hidden email] wrote:

> Thank you for the information. I can now see where the various frequencies
> come from when I change setperf.
> Is it possible to see the cpu voltage anywhere, to go along with the
> hw.cpuspeed?
>
> I want to do further testing with the stress program as I do not think the
> H5 stability problems are to do with speed/voltage.
> I suspect something to do with network.  I started out with the dwxe0 lan
> plugged into a 1000Mhz switch and failures were quite often. I then
> downgraded to a 100Mhz port and the system seemed to hang in there longer.
> I then tested with an old usb wifi adapter(run0) which was very slow and the
> system behaved even better, although it did fail in the same fashion.
>
> Has anyone tried to trace back the crash reports?  It always seems to be a
> consistent crash no matter the program that was running.
>
> Stephen Graf
>
> -----Original Message-----
> From: [hidden email] <[hidden email]> On Behalf Of Mark
> Kettenis
> Sent: February 3, 2019 11:54 AM
> To: [hidden email]
> Cc: [hidden email]; [hidden email]
> Subject: Re: initial cpu speed on orangepi one and orangepi pc2 - probably
> other H5 and H3 boards
>
> Any OS will boot with the CPU clock frequency and voltage that was set
> up by the firmware/bootloader.  Those are supposed to be "safe"
> settings in the sense that the OS can run without overheating the SoC.
>
> If the DT provides a set of operating points, and there is clock and
> regulator support, OpenBSD will allow changing the clock frequency.
> For each frequency it will select the associated voltage in the
> operating points table.  When there is support for changing the clock
> frequency, OpenBSD will switch to the operating point that has an
> associated clock frequency that not higher than the clock frequency
> the system booted with.
>

Reply | Threaded
Open this post in threaded view
|

Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

Bodie-3


On 15.12.2020 00:26, Megan Smith wrote:
> I am seeing what looks like the same issue, also with an Orange Pi PC
> 2, on both 6.8 and snapshot.  Is it worth filing another bug report on
> this?
>
> Has there been any progress on this since this was raised?
>


Hi,

Orange Pi One user here with -current. I have 1008Mhz set after boot.
I can remember looking around and found something related to this
https://linux-sunxi.org/Xunlong_Orange_Pi_One_%26_Lite#CPU_clock_speed_limit

Some guy was playing with voltage requirements and explaining why it
works this way. Of course I can't find it now :-)

But when I see that dvfs voltage-frequency table then maybe it has
something to do with
this error on end of dmesg:

WARNING: bad clock chip time
WARNING: CHECK AND RESET THE DATE!
cpu0: DVFS failed


plus obvious:

{89} dmesg | grep 'not configured'
"clock" at simplebus0 not configured
"mixer" at simplebus0 not configured
"dma-controller" at simplebus0 not configured
"lcd-controller" at simplebus0 not configured
"usb" at simplebus0 not configured
"phy" at simplebus0 not configured
"timer" at simplebus0 not configured
"dram-controller" at simplebus0 not configured
"hdmi" at simplebus0 not configured
"hdmi-phy" at simplebus0 not configured
"codec-analog" at simplebus0 not configured
"deinterlace" at simplebus0 not configured
"video-codec" at simplebus0 not configured
"crypto" at simplebus0 not configured
"gpu" at simplebus0 not configured

> Thanks
> Megan
>
> On 2/4/19 2:48 PM, [hidden email] wrote:
>> Thank you for the information. I can now see where the various
>> frequencies
>> come from when I change setperf.
>> Is it possible to see the cpu voltage anywhere, to go along with the
>> hw.cpuspeed?
>>
>> I want to do further testing with the stress program as I do not think
>> the
>> H5 stability problems are to do with speed/voltage.
>> I suspect something to do with network.  I started out with the dwxe0
>> lan
>> plugged into a 1000Mhz switch and failures were quite often. I then
>> downgraded to a 100Mhz port and the system seemed to hang in there
>> longer.
>> I then tested with an old usb wifi adapter(run0) which was very slow
>> and the
>> system behaved even better, although it did fail in the same fashion.
>>
>> Has anyone tried to trace back the crash reports?  It always seems to
>> be a
>> consistent crash no matter the program that was running.
>>
>> Stephen Graf
>>
>> -----Original Message-----
>> From: [hidden email] <[hidden email]> On Behalf Of Mark
>> Kettenis
>> Sent: February 3, 2019 11:54 AM
>> To: [hidden email]
>> Cc: [hidden email]; [hidden email]
>> Subject: Re: initial cpu speed on orangepi one and orangepi pc2 -
>> probably
>> other H5 and H3 boards
>>
>> Any OS will boot with the CPU clock frequency and voltage that was set
>> up by the firmware/bootloader.  Those are supposed to be "safe"
>> settings in the sense that the OS can run without overheating the SoC.
>>
>> If the DT provides a set of operating points, and there is clock and
>> regulator support, OpenBSD will allow changing the clock frequency.
>> For each frequency it will select the associated voltage in the
>> operating points table.  When there is support for changing the clock
>> frequency, OpenBSD will switch to the operating point that has an
>> associated clock frequency that not higher than the clock frequency
>> the system booted with.
>>

adr
Reply | Threaded
Open this post in threaded view
|

Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

adr
In reply to this post by Megan
On Tue, Dec 15, 2020 at 12:26:48PM +1300, Megan Smith wrote:

> I am seeing what looks like the same issue, also with an Orange Pi PC 2, on
> both 6.8 and snapshot.  Is it worth filing another bug report on this?
>
> Has there been any progress on this since this was raised?
>
> Thanks
> Megan
>
> On 2/4/19 2:48 PM, [hidden email] wrote:
> > Thank you for the information. I can now see where the various frequencies
> > come from when I change setperf.
> > Is it possible to see the cpu voltage anywhere, to go along with the
> > hw.cpuspeed?
> >
> > I want to do further testing with the stress program as I do not think the
> > H5 stability problems are to do with speed/voltage.
> > I suspect something to do with network.  I started out with the dwxe0 lan
> > plugged into a 1000Mhz switch and failures were quite often. I then
> > downgraded to a 100Mhz port and the system seemed to hang in there longer.
> > I then tested with an old usb wifi adapter(run0) which was very slow and the
> > system behaved even better, although it did fail in the same fashion.
> >
> > Has anyone tried to trace back the crash reports?  It always seems to be a
> > consistent crash no matter the program that was running.
> >
> > Stephen Graf
> >
> > -----Original Message-----
> > From: [hidden email] <[hidden email]> On Behalf Of Mark
> > Kettenis
> > Sent: February 3, 2019 11:54 AM
> > To: [hidden email]
> > Cc: [hidden email]; [hidden email]
> > Subject: Re: initial cpu speed on orangepi one and orangepi pc2 - probably
> > other H5 and H3 boards
> >
> > Any OS will boot with the CPU clock frequency and voltage that was set
> > up by the firmware/bootloader.  Those are supposed to be "safe"
> > settings in the sense that the OS can run without overheating the SoC.
> >
> > If the DT provides a set of operating points, and there is clock and
> > regulator support, OpenBSD will allow changing the clock frequency.
> > For each frequency it will select the associated voltage in the
> > operating points table.  When there is support for changing the clock
> > frequency, OpenBSD will switch to the operating point that has an
> > associated clock frequency that not higher than the clock frequency
> > the system booted with.

H5 has a mix of problems. One, shared with H3 _was_ this:

https://marc.info/?t=159333011500004&r=1&w=2

Now is solved. Other one is this:

https://marc.info/?t=160451196500005&r=1&w=2

Read the corrections in my second mail (too much coffee).

The dtb doesn't have an opp table, and the frequency
set by u-boot is wrong. I don't know why they are doubling the freq:

./arch/arm/mach-sunxi/dram_sunxi_dw.c:
        if (socid == SOCID_A64 || socid == SOCID_R40) {
                clock_set_pll11(CONFIG_DRAM_CLK * 2 * 1000000, false);
                clrsetbits_le32(&ccm->dram_clk_cfg,
                                CCM_DRAMCLK_CFG_DIV_MASK |
                                CCM_DRAMCLK_CFG_SRC_MASK,
                                CCM_DRAMCLK_CFG_DIV(1) |
                                CCM_DRAMCLK_CFG_SRC_PLL11 |
                                CCM_DRAMCLK_CFG_UPD);
        } else if (socid == SOCID_H3 || socid == SOCID_H5 || socid == SOCID_V3S) {
                clock_set_pll5(CONFIG_DRAM_CLK * 2 * 1000000, false);
                clrsetbits_le32(&ccm->dram_clk_cfg,
                                CCM_DRAMCLK_CFG_DIV_MASK |
                                CCM_DRAMCLK_CFG_SRC_MASK,
                                CCM_DRAMCLK_CFG_DIV(1) |
                                CCM_DRAMCLK_CFG_SRC_PLL5 |
                                CCM_DRAMCLK_CFG_UPD);
        }
======================
./arch/arm/mach-sunxi/clock_sun6i.c:
        /* PLL5 rate = 24000000 * n * k / m */
        if (clk > 24000000 * k * max_n / m) {
                m = 1;
                if (clk > 24000000 * k * max_n / m)
                        k = 2;
        }
        writel(CCM_PLL5_CTRL_EN |
               (sigma_delta_enable ? CCM_PLL5_CTRL_SIGMA_DELTA_EN : 0) |
               CCM_PLL5_CTRL_UPD |
               CCM_PLL5_CTRL_N(clk / (24000000 * k / m)) |
               CCM_PLL5_CTRL_K(k) | CCM_PLL5_CTRL_M(m), &ccm->pll5_cfg);
======================

The problem with the orange pi one, lite, etc is that the regulator can't
match the opp table (based on the soc, not the board) because there is
no gpio regulator driver, the code is split among functions... well read
the mail:

https://marc.info/?l=openbsd-tech&m=159484418907996&w=2

I was thinking about writing a simple driver, but I have little
little time, I'm not an openbsd developer and no one shown interest.

In fact I'm felling really stupid searching the archives for my
own mails.

With the changes I suggested these boards work great. Just add some cooling
if you want to stressed them.

adr.

P.S. I don't understand how can't you find this on the list archives. Really.

Reply | Threaded
Open this post in threaded view
|

Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

wilfried.meindl
[hidden email] wrote:

> On Tue, Dec 15, 2020 at 12:26:48PM +1300, Megan Smith wrote:
> > I am seeing what looks like the same issue, also with an Orange Pi PC 2, on
> > both 6.8 and snapshot.  Is it worth filing another bug report on this?
> >
> > Has there been any progress on this since this was raised?
> >
> > Thanks
> > Megan
> >
> > On 2/4/19 2:48 PM, [hidden email] wrote:
> > > Thank you for the information. I can now see where the various frequencies
> > > come from when I change setperf.
> > > Is it possible to see the cpu voltage anywhere, to go along with the
> > > hw.cpuspeed?
> > >
> > > I want to do further testing with the stress program as I do not think the
> > > H5 stability problems are to do with speed/voltage.
> > > I suspect something to do with network.  I started out with the dwxe0 lan
> > > plugged into a 1000Mhz switch and failures were quite often. I then
> > > downgraded to a 100Mhz port and the system seemed to hang in there longer.
> > > I then tested with an old usb wifi adapter(run0) which was very slow and the
> > > system behaved even better, although it did fail in the same fashion.
> > >
> > > Has anyone tried to trace back the crash reports?  It always seems to be a
> > > consistent crash no matter the program that was running.
> > >
> > > Stephen Graf
> > >
> > > -----Original Message-----
> > > From: [hidden email] <[hidden email]> On Behalf Of Mark
> > > Kettenis
> > > Sent: February 3, 2019 11:54 AM
> > > To: [hidden email]
> > > Cc: [hidden email]; [hidden email]
> > > Subject: Re: initial cpu speed on orangepi one and orangepi pc2 - probably
> > > other H5 and H3 boards
> > >
> > > Any OS will boot with the CPU clock frequency and voltage that was set
> > > up by the firmware/bootloader.  Those are supposed to be "safe"
> > > settings in the sense that the OS can run without overheating the SoC.
> > >
> > > If the DT provides a set of operating points, and there is clock and
> > > regulator support, OpenBSD will allow changing the clock frequency.
> > > For each frequency it will select the associated voltage in the
> > > operating points table.  When there is support for changing the clock
> > > frequency, OpenBSD will switch to the operating point that has an
> > > associated clock frequency that not higher than the clock frequency
> > > the system booted with.
>
> H5 has a mix of problems. One, shared with H3 _was_ this:
>
> https://marc.info/?t=159333011500004&r=1&w=2
>
> Now is solved. Other one is this:
>
> https://marc.info/?t=160451196500005&r=1&w=2
>
> Read the corrections in my second mail (too much coffee).
>
> The dtb doesn't have an opp table, and the frequency
> set by u-boot is wrong. I don't know why they are doubling the freq:
>
> ./arch/arm/mach-sunxi/dram_sunxi_dw.c:
>         if (socid == SOCID_A64 || socid == SOCID_R40) {
>                 clock_set_pll11(CONFIG_DRAM_CLK * 2 * 1000000, false);
>                 clrsetbits_le32(&ccm->dram_clk_cfg,
>                                 CCM_DRAMCLK_CFG_DIV_MASK |
>                                 CCM_DRAMCLK_CFG_SRC_MASK,
>                                 CCM_DRAMCLK_CFG_DIV(1) |
>                                 CCM_DRAMCLK_CFG_SRC_PLL11 |
>                                 CCM_DRAMCLK_CFG_UPD);
>         } else if (socid == SOCID_H3 || socid == SOCID_H5 || socid == SOCID_V3S) {
>                 clock_set_pll5(CONFIG_DRAM_CLK * 2 * 1000000, false);
>                 clrsetbits_le32(&ccm->dram_clk_cfg,
>                                 CCM_DRAMCLK_CFG_DIV_MASK |
>                                 CCM_DRAMCLK_CFG_SRC_MASK,
>                                 CCM_DRAMCLK_CFG_DIV(1) |
>                                 CCM_DRAMCLK_CFG_SRC_PLL5 |
>                                 CCM_DRAMCLK_CFG_UPD);
>         }
> ======================
> ./arch/arm/mach-sunxi/clock_sun6i.c:
>         /* PLL5 rate = 24000000 * n * k / m */
>         if (clk > 24000000 * k * max_n / m) {
>                 m = 1;
>                 if (clk > 24000000 * k * max_n / m)
>                         k = 2;
>         }
>         writel(CCM_PLL5_CTRL_EN |
>                (sigma_delta_enable ? CCM_PLL5_CTRL_SIGMA_DELTA_EN : 0) |
>                CCM_PLL5_CTRL_UPD |
>                CCM_PLL5_CTRL_N(clk / (24000000 * k / m)) |
>                CCM_PLL5_CTRL_K(k) | CCM_PLL5_CTRL_M(m), &ccm->pll5_cfg);
> ======================
>
> The problem with the orange pi one, lite, etc is that the regulator can't
> match the opp table (based on the soc, not the board) because there is
> no gpio regulator driver, the code is split among functions... well read
> the mail:
>
> https://marc.info/?l=openbsd-tech&m=159484418907996&w=2
>
> I was thinking about writing a simple driver, but I have little
> little time, I'm not an openbsd developer and no one shown interest.
>
> In fact I'm felling really stupid searching the archives for my
> own mails.
>
> With the changes I suggested these boards work great. Just add some cooling
> if you want to stressed them.
>
> adr.
>
> P.S. I don't understand how can't you find this on the list archives. Really.
>

I can confirm that with lowering the memory frequency the H5 now is absolutely
stable. Things that failed before, like pkg_check, installing texlive or
compiling the kernel and userland now finish reliably without errors on my
Nanopi Neo2.

Thanks adr for finding this out!

To work around the u-boot bug I took adr's solution and just put a boot.scr
file in the boot partition. This file was compiled from a boot.cmd that
contains

echo Setting DDR3 freq to 648MHz
mw 0x01C20020 0x80101A00
run scan_dev_for_efi

I think the cleanest solution would be to file a bug with u-boot instead of
patching the u-boot port in OpenBSD.

wime12

Reply | Threaded
Open this post in threaded view
|

Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

Colin Tree
Hi,

I have been comparing decompiled dtb files from working linux
(friendlyarm, armbian, dietpi) installs with decompiled openbsd dtb.

home$  dtc -O dts -I dtb -o board.dts board.dtb

checking results against the various datasheets and circuit.



Colin


On 15/12/20 4:47 pm, [hidden email] wrote:

> [hidden email] wrote:
>
>> On Tue, Dec 15, 2020 at 12:26:48PM +1300, Megan Smith wrote:
>>> I am seeing what looks like the same issue, also with an Orange Pi PC 2, on
>>> both 6.8 and snapshot.  Is it worth filing another bug report on this?
>>>
>>> Has there been any progress on this since this was raised?
>>>
>>> Thanks
>>> Megan
>>>
>>> On 2/4/19 2:48 PM, [hidden email] wrote:
>>>> Thank you for the information. I can now see where the various frequencies
>>>> come from when I change setperf.
>>>> Is it possible to see the cpu voltage anywhere, to go along with the
>>>> hw.cpuspeed?
>>>>
>>>> I want to do further testing with the stress program as I do not think the
>>>> H5 stability problems are to do with speed/voltage.
>>>> I suspect something to do with network.  I started out with the dwxe0 lan
>>>> plugged into a 1000Mhz switch and failures were quite often. I then
>>>> downgraded to a 100Mhz port and the system seemed to hang in there longer.
>>>> I then tested with an old usb wifi adapter(run0) which was very slow and the
>>>> system behaved even better, although it did fail in the same fashion.
>>>>
>>>> Has anyone tried to trace back the crash reports?  It always seems to be a
>>>> consistent crash no matter the program that was running.
>>>>
>>>> Stephen Graf
>>>>
>>>> -----Original Message-----
>>>> From: [hidden email] <[hidden email]> On Behalf Of Mark
>>>> Kettenis
>>>> Sent: February 3, 2019 11:54 AM
>>>> To: [hidden email]
>>>> Cc: [hidden email]; [hidden email]
>>>> Subject: Re: initial cpu speed on orangepi one and orangepi pc2 - probably
>>>> other H5 and H3 boards
>>>>
>>>> Any OS will boot with the CPU clock frequency and voltage that was set
>>>> up by the firmware/bootloader.  Those are supposed to be "safe"
>>>> settings in the sense that the OS can run without overheating the SoC.
>>>>
>>>> If the DT provides a set of operating points, and there is clock and
>>>> regulator support, OpenBSD will allow changing the clock frequency.
>>>> For each frequency it will select the associated voltage in the
>>>> operating points table.  When there is support for changing the clock
>>>> frequency, OpenBSD will switch to the operating point that has an
>>>> associated clock frequency that not higher than the clock frequency
>>>> the system booted with.
>> H5 has a mix of problems. One, shared with H3 _was_ this:
>>
>> https://marc.info/?t=159333011500004&r=1&w=2
>>
>> Now is solved. Other one is this:
>>
>> https://marc.info/?t=160451196500005&r=1&w=2
>>
>> Read the corrections in my second mail (too much coffee).
>>
>> The dtb doesn't have an opp table, and the frequency
>> set by u-boot is wrong. I don't know why they are doubling the freq:
>>
>> ./arch/arm/mach-sunxi/dram_sunxi_dw.c:
>>          if (socid == SOCID_A64 || socid == SOCID_R40) {
>>                  clock_set_pll11(CONFIG_DRAM_CLK * 2 * 1000000, false);
>>                  clrsetbits_le32(&ccm->dram_clk_cfg,
>>                                  CCM_DRAMCLK_CFG_DIV_MASK |
>>                                  CCM_DRAMCLK_CFG_SRC_MASK,
>>                                  CCM_DRAMCLK_CFG_DIV(1) |
>>                                  CCM_DRAMCLK_CFG_SRC_PLL11 |
>>                                  CCM_DRAMCLK_CFG_UPD);
>>          } else if (socid == SOCID_H3 || socid == SOCID_H5 || socid == SOCID_V3S) {
>>                  clock_set_pll5(CONFIG_DRAM_CLK * 2 * 1000000, false);
>>                  clrsetbits_le32(&ccm->dram_clk_cfg,
>>                                  CCM_DRAMCLK_CFG_DIV_MASK |
>>                                  CCM_DRAMCLK_CFG_SRC_MASK,
>>                                  CCM_DRAMCLK_CFG_DIV(1) |
>>                                  CCM_DRAMCLK_CFG_SRC_PLL5 |
>>                                  CCM_DRAMCLK_CFG_UPD);
>>          }
>> ======================
>> ./arch/arm/mach-sunxi/clock_sun6i.c:
>>          /* PLL5 rate = 24000000 * n * k / m */
>>          if (clk > 24000000 * k * max_n / m) {
>>                  m = 1;
>>                  if (clk > 24000000 * k * max_n / m)
>>                          k = 2;
>>          }
>>          writel(CCM_PLL5_CTRL_EN |
>>                 (sigma_delta_enable ? CCM_PLL5_CTRL_SIGMA_DELTA_EN : 0) |
>>                 CCM_PLL5_CTRL_UPD |
>>                 CCM_PLL5_CTRL_N(clk / (24000000 * k / m)) |
>>                 CCM_PLL5_CTRL_K(k) | CCM_PLL5_CTRL_M(m), &ccm->pll5_cfg);
>> ======================
>>
>> The problem with the orange pi one, lite, etc is that the regulator can't
>> match the opp table (based on the soc, not the board) because there is
>> no gpio regulator driver, the code is split among functions... well read
>> the mail:
>>
>> https://marc.info/?l=openbsd-tech&m=159484418907996&w=2
>>
>> I was thinking about writing a simple driver, but I have little
>> little time, I'm not an openbsd developer and no one shown interest.
>>
>> In fact I'm felling really stupid searching the archives for my
>> own mails.
>>
>> With the changes I suggested these boards work great. Just add some cooling
>> if you want to stressed them.
>>
>> adr.
>>
>> P.S. I don't understand how can't you find this on the list archives. Really.
>>
> I can confirm that with lowering the memory frequency the H5 now is absolutely
> stable. Things that failed before, like pkg_check, installing texlive or
> compiling the kernel and userland now finish reliably without errors on my
> Nanopi Neo2.
>
> Thanks adr for finding this out!
>
> To work around the u-boot bug I took adr's solution and just put a boot.scr
> file in the boot partition. This file was compiled from a boot.cmd that
> contains
>
> echo Setting DDR3 freq to 648MHz
> mw 0x01C20020 0x80101A00
> run scan_dev_for_efi
>
> I think the cleanest solution would be to file a bug with u-boot instead of
> patching the u-boot port in OpenBSD.
>
> wime12
>

adr
Reply | Threaded
Open this post in threaded view
|

Re: initial cpu speed on orangepi one and orangepi pc2 - probably other H5 and H3 boards

adr
In reply to this post by adr
[hidden email] wrote:

> I can confirm that with lowering the memory frequency the H5 now is absolutely
> stable. Things that failed before, like pkg_check, installing texlive or
> compiling the kernel and userland now finish reliably without errors on my
> Nanopi Neo2.

Don't forget to add the opp table so you can put the cpus to the max freq:

hw.cpuspeed=1344
hw.setperf=100

Has I said, just add some cooling.

> I think the cleanest solution would be to file a bug with u-boot
> instead of patching the u-boot port in OpenBSD.

I did it some months ago. I didn't subscribe to the list so I
received a message telling me to wait for the administrator approval.
I got tired of checking the list. I didn't want to subscribe to
the list because no one shown interest and as I said before I have
little time on my hands, this list has a lot of traffic. I will
try again this weekend.


Colin Tree <[hidden email]> wrote:

> I have been comparing decompiled dtb files from working linux
> (friendlyarm, armbian, dietpi) installs with decompiled openbsd dtb.
> home$   dtc -O dts -I dtb -o board.dts board.dtb
> checking results against the various datasheets and circuit.

There is nothing to check, you can trust me, really. The issue is
clear. But if you want to experiment with other dtbs be aware,
openbsd is using defines in the code to match phandles in the dtb,
so if one is changed, you are screwed.

Regards,
adr.