Re: Raspberry Pi POE+ hat overlay

(...)

Using:

[pi4]
over_voltage=6
arm_freq=2000
sdram_freq_min=3200
force_turbo=1

Start to like force_turbo on :)

Cheers!

Nuno Teixeira <eduardo@freebsd.org> escreveu no dia sexta, 19/05/2023 à(s)
08:37:

> Thanks for great explanation about overclocking and firmware.
> I was lost between firmware versions used in raspberry linux and freebsd
> port.
>
> Now I have a better picture of why this setup make sense for a specific
> firmware.
>
> I will stick with freq 2000 as my first goal was to set to 1800.
>
> And for now on, I will be watching firmware port version updates to check
> changes carefully.
>
> Yours,
>
> Mark Millard <marklmi@yahoo.com> escreveu no dia quinta, 18/05/2023 à(s)
> 18:07:
>
>> On May 18, 2023, at 05:48, Nuno Teixeira <eduardo@freebsd.org> wrote:
>>
>> > Indeed, voltage was the missing bit!
>> >
>> > I'm trying to setup 1800 as default now for revs >= 1.4 following
>> https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/
>> that only talk about setting arm_freq=1800 but doesn't mention to adjust
>> voltage.
>> > It was nice that raspberry tell us what voltage exacly value they use
>> for new default 1800.
>> >
>> > What I've got now is:
>> >
>> > [pi4]
>> > over_voltage=6
>> > arm_freq=2000
>> > sdram_freq_min=3200
>> > ### force_turbo=1
>> >
>> > My tests shows that we don't need force_turbo=1 for a normal running
>> and system do an auto 600 -> 2000 change when needed. Thats nice.
>>
>> I will note that the RPi* firmware itself varies the
>> frequency and voltages by default --but the way of
>> disabling that also disables powerd from being
>> effective as I understand. (As I understand the
>> firmware's policy details have changed over time
>> but I do not know the details or when.)
>>
>> This makes use of powerd on the RPi*, with the firmware's
>> adjustments also enabled, involve 2 competing mechanisms,
>> if I understand right. I'm not aware of any horrible
>> consequences in actual ooperation but I found force_turbo
>> to lead to less time being taken in build activities back
>> when I last measured it.
>>
>> It is true that I've not looked into this area in a long
>> time.
>>
>> > Also, arm_boost=1 with force_turbo or not, is ignored.
>>
>>
>> https://github.com/raspberrypi/documentation/blob/8b096a52e394c10360549afd0a620755df467446/documentation/asciidoc/computers/config_txt/overclocking.adoc
>>
>> (from 2021-Nov-04) did not have arm_boost documented yet.
>>
>>
>> https://github.com/raspberrypi/documentation/blob/da45bd8c982e91e11c609991ba2fc8783872ef67/documentation/asciidoc/computers/config_txt/overclocking.adoc
>>
>> (from 2021-Nov-11) has arm_boost documented.
>>
>> These give a clue about the vintage of RPi* firmware needed
>> to have the arm_boost notation implemented.
>>
>> > sdram_freq and sdram_freq_min are set to 3200 by default, so I think I
>> will not need sdram_freq_min=3200 here.
>>
>>
>> https://github.com/raspberrypi/documentation/blob/2cbcd18fc155044f20ae6305fa0e62629b56893c/configuration/config-txt/overclocking.md
>>
>> (from 2021-Mar-31) shows the Pi4 sdram_freq_min as 400.
>> The defaults have changed with firmware updates.
>>
>> Note that the official RPi* port has 2021-Mar-03 firmware,
>> so before 2021-Mar-31.
>>
>>
>> https://github.com/raspberrypi/documentation/blob/75e6050edd9e1b0c47c58623133dc05a02c16351/documentation/asciidoc/computers/config_txt/overclocking.adoc
>>
>> (from 2021-Aug-09) shows the Pi4/CM4 sdram_freq_min as 3200.
>>
>> These give a clue about the vintage of RPi* firmware needed
>> to have the sdram_freq_min be 3200 by default.
>>
>> My settings are for a wide range of firmware vintages, not
>> just modern ones. Each item was shown (at the time added)
>> was shown to cut the times for the likes of buildworld,
>> buildkernel, or poudriere bulk activities that I did.
>>
>> Also, I tend to leave in place what has worked and still
>> does work, rather than to track the changes in defaults
>> over time in even more detail. I'd likely have different
>> settings listed if I'd started at a later point that had
>> newer defaults.
>>
>> > The only thing that I can't understand is how to calculate voltage:
>> >
>> > over_voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ???
>> > ( https://www.raspberrypi.com/documentation/computers/config_txt.html )
>> >
>> > Also, "7. Take it to the max" (
>> https://magpi.raspberrypi.com/articles/how-to-overclock-raspberry-pi-4 ):
>> >
>> > over_voltage=6 (?)
>> > arm_freq=2147
>> > gpu_freq=750
>>
>> I'll note that I never attempted to take each RPi4B to
>> its maximum for normal operation. I targeted having a
>> setting combination that was reliable (had some margin)
>> on all the example RPi4B's.
>>
>> I did have to explore were failures occured to do that.
>> I did have access to RPi4B's that were unreliable with
>> arm_freq=2100 for any over_voltage that I tried. Backing
>> off to 2000 gave me reliable results on all the RPi4B's.
>>
>> I never had trouble with sdram_freq_min=3200 but it did
>> help in contexts with the default being 400.
>>
>> > Thanks,
>> >
>> >
>> > Mark Millard <marklmi@yahoo.com> escreveu no dia quinta, 18/05/2023
>> à(s) 11:57:
>> > On May 18, 2023, at 01:29, Nuno Teixeira <eduardo@freebsd.org> wrote:
>> >
>> > > Confirmed that arm_boost is enable by default on rpi4 rev >= 1.4 as I
>> checked with htop.
>> > >
>> > > Also, tested arm_freq=1800 and it crashes FreeBSD around initializing
>> console/video and detecting mouse.
>> >
>> > Overclocking by setting the arm_freq directly involves also
>> > managing over_voltage explicitly, such as:
>> >
>> > over_voltage=6
>> >
>> > A sequence I use (and have used for a long time) is:
>> >
>> > [pi4]
>> > over_voltage=6
>> > arm_freq=2000
>> > sdram_freq_min=3200
>> > force_turbo=1
>> >
>> > But each RPi4B has heatsinks, a case with a fan,
>> > and a power supply rated for 5.1V 3.5A (so: has
>> > some extra margin).
>> >
>> > But the range of RPi4B's span Rev 1.1, Rev 1.4,
>> > and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte
>> > RAM models. All use those settings.
>> >
>> > As I understand, arm_boost implicitly does the
>> > extra things required for its implicit frequency,
>> > unlike assigning arm_freq or the like.
>> >
>> > If force_turbo is not used, it can be that:
>> >
>> > #
>> > # Local addition that avoids USB3 SSD boot failures that look like:
>> > #   uhub_reattach_port: port ? reset failed, error=USB_ERR_TIMEOUT
>> > #   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling
>> port ?
>> > initial_turbo=60
>> >
>> > is required for USB based booting. But this also
>> > gets into if the notation is supported or not for
>> > the firmware vintage used.
>> >
>> > The initial_turbo use happens to avoid frequency
>> > variability during boot and it appears that FreeBSD
>> > does not necessarily tolerate such variability in
>> > that time frame.
>> >
>> > Also: I happen to have USB3 boot media for which use
>> > of usb_pgood_delay=2000 is sufficient but without
>> > some such in/for U-Boot, U-Boot has problems
>> > recognizing the device (before FreeBSD is even
>> > involved). I build the U-Boot port with the
>> > assignment built in.
>> >
>> > > As linux config.txt says:
>> > > ---
>> > > [pi4]
>> > > # Run as fast as firmware / board allows
>> > > arm_boost=1
>> > > ---
>> > > firmware must be updated to support this feature for sure.
>> >
>> > I'm not aware of a dated list of when the various
>> > config.txt notations were first supported (firmware
>> > version). This makes it messier to use the web's
>> > published information, if one is using the firmware
>> > vintage that FreeBSD has in its port for the
>> > firmware.
>> >
>> > The notation that I use has been around for a long
>> > time.
>> >
>> > > Cheers,
>> > >
>> > > Nuno Teixeira <eduardo@freebsd.org> escreveu no dia quarta,
>> 17/05/2023 à(s) 14:08:
>> > > (...)
>> > >
>> > > I was meant using 13.2 not 12.3 :)
>> > >
>> > > Doug Rabson <dfr@rabson.org> escreveu no dia quarta, 17/05/2023 à(s)
>> 13:47:
>> > > I'm not sure about 12.3 either - you could try with 13.2 and see if
>> that makes a difference.
>> > >
>> > > On Wed, 17 May 2023 at 13:45, Nuno Teixeira <eduardo@freebsd.org>
>> wrote:
>> > > Hey,
>> > >
>> > > Ok. I'm new to rpi4 and arm in general but tomorrow I will force
>> 'arm_freq=1800' again just to see it it crashes again.
>> > > I will check too what values linux shows.
>> > >
>> > > I don't know if firmware/uboot version included in 12.3 supports this
>> feature.
>> > >
>> > > Cheers,
>> > >
>> > > Doug Rabson <dfr@rabson.org> escreveu no dia quarta, 17/05/2023 à(s)
>> 13:11:
>> > > Hi Nuno,
>> > >
>> > > I'm not sure where to start - I just happened to notice in the
>> documentation here:
>> https://www.raspberrypi.com/documentation/computers/config_txt.html that
>> the cpu frequency Pi4B R1.4 was listed as 1800 if arm_boot=1 so I tried it.
>> > >
>> > > Doug.
>> > >
>> > >
>> > >
>> > > On Wed, 17 May 2023 at 11:11, Nuno Teixeira <eduardo@freebsd.org>
>> wrote:
>> > > Hello Doug,
>> > >
>> > > I have too a 1.5 rpi but arm_boost=1 isn't doing anything, htop shows
>> 1500Mhz when doing something intensive.
>> > > I'm running 13.2 stable
>> > >
>> > > Do I missing something?
>> > >
>> > > Could you take a look at my setup?
>> > >
>> > > Thanks,
>> > >
>> > > Doug Rabson <dfr@rabson.org> escreveu no dia terça, 16/05/2023 à(s)
>> 17:19:
>> > >
>> > > On Sat, 13 May 2023 at 13:45, Doug Rabson <dfr@rabson.org> wrote:
>> > > I was able to build an updated rpi-firmware port based on 1.20210805
>> and this boots successfully on pi400 as well as rpi4. With this, I can load
>> the rpi-poe-plus overlay and I just need to try and reverse engineer the
>> undocumented mailbox API by reading the Linux code.
>> > >
>> > > I have a first approximation of a fan driver which works with the
>> 1.20210805 firmware (actually, I substituted rpi-poe-plus.dtbo from
>> 1.20210831 which just changes the fan levels for the POE+). I'm testing
>> with an rpi4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping the
>> cpu temperature below 65 degrees which is nice, especially since I set
>> arm_boost=1 in config.txt which boosts the cpu frequency up to 1800 for
>> this board.
>> > >
>> > > Does anyone have a pointer to the problem with firmware later than
>> 20210805? Would it make any kind of sense to try to get the fix into
>> releng/13.2 as an errata?
>> > >
>>
>>
>>
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>>
>>
>
> --
> Nuno Teixeira
> FreeBSD Committer (ports)
>


-- 
Nuno Teixeira
FreeBSD Committer (ports)