Re: Raspberry Pi POE+ hat overlay

(...)

Found a nice table of overvoltage at
https://www.qengineering.eu/overclocking-the-raspberry-pi-4.html

(also, I found too some advices that over_voltage not needed to be set in
newer firmwares. Later I will test it on raspberry linux without setting
it).

I'm at poudriere building www/node18 with with -J4 cores and freq from
1500->2000 temperature changes from ~46C->~57C
4 heatsinks and a case fan.

I'm so happy!

Thanks!

Nuno Teixeira <eduardo@freebsd.org> escreveu no dia quinta, 18/05/2023 à(s)
13:48:

> 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)
>


-- 
Nuno Teixeira
FreeBSD Committer (ports)