Date: Mon, 7 Sep 2020 13:13:08 -0700 From: Mark Millard <marklmi@yahoo.com> To: tech-lists <tech-lists@zyxst.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: rpi4 won't overclock Message-ID: <20E5C2A1-86CE-4C6A-8630-96537E13B460@yahoo.com> In-Reply-To: <20200907144212.GB62420@bastion.zyxst.net> References: <2F772350-6832-44CE-BCB4-F877173D320A.ref@yahoo.com> <2F772350-6832-44CE-BCB4-F877173D320A@yahoo.com> <20200907144212.GB62420@bastion.zyxst.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Sep-7, at 07:42, tech-lists <tech-lists at zyxst.net> wrote: Hi, On Sun, Sep 06, 2020 at 05:31:15PM -0700, Mark Millard wrote: >>> . . . >>=20 >> Have you tried making config.txt a strict copy of config_rip4.txt >> with no other changes and it still fails to boot? >=20 > Yes, just tried that. It will boot but it fails to boot if I set = overclocking parameters in > config.txt. Then my next question would be: does a modern RasbPiOS boot from microsd card media with those same overclocking parameters in the config.txt? If not, there is little hope for FreeBSD booting and operating well with such parameter values (given the same equipement, power, etc.). If RasbPiOS does boot, then it may be that some setting(s) are outside the range that u-boot handles and need to be set later. May be over_voltage can stay in config.txt but the equivalent of arm_freq needs to be done from FreeBSD, say via powerd or /etc/sysctl.conf assigning dev.cpu.0.freq to some value. > I get to a screen that complains about newer firmware. It doesn't > get as far as u-boot. I took the card out and amended it on another = machine, > then put it back in the rpi4. It boots, and config.txt looks like = this: >=20 > arm_control=3D0x200 > arm_64bit=3D1 > dtoverlay=3Ddisable-bt > dtoverlay=3Dmmc > device_tree_address=3D0x4000 > kernel=3Du-boot.bin > armstub=3Darmstub8-gic.bin > #gpu_mem=3D16 > #over_voltage=3D6 > #arm_freq=3D2100 >=20 >> . . . >=20 > On my rpi3 12.1-STABLE r363237 GENERIC I have the following in > /boot/msdos/config.txt: >=20 > arm_control=3D0x200 > dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don > dtoverlay=3Dmmc > dtoverlay=3Dpwm > dtoverlay=3Ddisable-bt > device_tree_address=3D0x4000 > kernel=3Du-boot.bin > #force_turbo=3D1 > gpu_mem=3D16 > arm_freq=3D1500 > over_voltage=3D4 >=20 > which normally gives 1.5GHz under load, nothing in /etc/sysctl.conf is = setting > this parameter. I have just enabled powerd powerd is what is changing the frequency in that context. (I've not been using powerd. For one, I do not expect that the uefi boot is providing what powerd needs to operate.) I expect that that at the command prompt after boot -s you would find that the frequency has not changed yet, indicating that the arm_freq has been ignored. (powerpd is started later in the sequence and can adjust the frequency.) > and rebooted, but it hasn't come > back so I suspect in my case it's applying config.txt but there's a = powerd <-> > config.txt interaction happening preventing it from booting. powerd is not started until very late as I remember. It seems your failure is before powerd is involved, if I understand right. >> . . . >>=20 >> I did do some margin testing initially and figures around 2100 were >> not reliable for keeping the RPi4B's operating. Of course, various >> things can contribute to what setting work with some margin for >> environment variability. I've got heatsinks, fans, and (apparently) >> good power. >=20 > I'm using dedicated power supplies made for rpi3 and rpi4. Am using = heatsinks > on the rpi3 in a clear plastic case on the rpi3 and a FLIRC aluminium = heatsink > case on the rpi4. RPi4B: I use CanaKit USB-C Power Supplies: 5.1V 3.5A, so slightly over = 17.8W. This is somewhat more than the official power supplies provide as far as the 3.5A figure (and Watts) goes. >> . . . > On my rpi4 I have that sysctl, and can modify > it: >=20 > freebsd@rpi4 ~ % sysctl dev.cpu.0.freq > dev.cpu.0.freq: 600 > freebsd@rpi4 ~ % sudo sysctl dev.cpu.0.freq=3D2000 > dev.cpu.0.freq: 600 -> 1500 I expect that either u-boot or the .dtb material (and handling of the dtb material) is constraining the arm_frequency to 1500. It may also be that the over_voltage does not survive (is replaced) and that the frequency has to be kept consistent with whatever over_voltage ends up at. (The uefi style booting by default uses what config.txt specifies for these, although uefi settings can be saved. But there are tradeoffs in what devices are usable. I use a USB3 Ethernet device, for example.) > reebsd@rpi4 ~ % sysctl -a | grep dev.cpu.0. > dev.cpu.0.temperature: 49.0C > dev.cpu.0.freq_levels: 1500/-1 600/-1 > . . . . 2000 is not > available. My guess is either u-boot or FreeBSD's interpretation of the .dtb material leads to the other speeds not being available. I'll note that, for example, ubuntu uses the arm_freq to set which frequencies are compatible with configuring to allow the target frequency. For example, with arm_freq=3D2000 the allowed frequency list is shown as: # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 666666 800000 1000000 1333333 2000000=20 By contrast, booting with arm_freq=3D2000 commented out results in: # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies=20= 600000 750000 1000000 1500000 (I do not know why FreeBSD does not provide the middle frequencies in that list.) Only one frequency is common to both lists. Trying arm_freq=3D2100 results in: # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 600000 700000 840000 1050000 1400000 2100000 That has one frequency in common with the prior two lists, in fact with only one of the two lists. (Again, while I've been able to boot with arm_freq=3D2100, the result has never been reliable when tested for such. So I do not use it beyond such boot-and-look activities.) My guess is that either the u-boot used or FreeBSD or both do not deal with making the matching frequency lists for a specified boot-time goal frequency. The uefi context ends up giving no control after booting (for as much as is currently supported by both uefi and FreeBSD) and so does not (yet) need to have to have any alternative frequencies. > If I don't set it in the sysctl, speed becomes dynamic according to > load. dynamic via powerd vs. without powerd (or other such)? >> . . . >=20 > How are you booting your rpi4s if not via u-boot? You're setting = parameters in > config.txt for the rpi4 ? I've been using material from https://github.com/pftf/RPi4/releases/ as reported in an earlier reply. None of the environments are complete combinations of materials yet. Each has its tradeoffs or things to manage. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20E5C2A1-86CE-4C6A-8630-96537E13B460>