Re: Raspberry Pi POE+ hat overlay

Hello Mark!

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.
Also, arm_boost=1 with force_turbo or not, is ignored.

sdram_freq and sdram_freq_min are set to 3200 by default, so I think I will
not need sdram_freq_min=3200 here.

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

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)