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, wilfried.mei...@gmail.com wrote:
a...@sdf.org 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, s_g...@telus.net 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: owner-...@openbsd.org <owner-...@openbsd.org> On Behalf Of Mark
Kettenis
Sent: February 3, 2019 11:54 AM
To: s_g...@telus.net
Cc: k.lewandow...@icloud.com; arm@openbsd.org
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
