Re: Raspberry Pi POE+ hat overlay

(...)

Tomorrow I will take it to the max:

over_voltage=6
arm_freq=2147
gpu_freq=750

:)

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

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


-- 
Nuno Teixeira
FreeBSD Committer (ports)