Re: Raspberry Pi POE+ hat overlay

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)