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
