From nobody Fri May 19 07:37:13 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QMzFf6tCFz4Bbw0 for ; Fri, 19 May 2023 07:37:26 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QMzFf60w0z44Nf for ; Fri, 19 May 2023 07:37:26 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684481846; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=s0b94eOvefp3+7WEvu2drvDFIJlEZ7IlaghX00vjBBw=; b=D+bPbitjQo46ixNGp2Tvk9MSnJ81j5e9XohVEL2eAUDFGj6GXBTM7vIwtWvFJiEaE++IJX 8Fu5YYhfl9Wvz+i4W/FuAq0nh1HxGxKgNhGR+JLw3ziAHQvMtnkX9IYungdkoZtvaOKe8l tdEivucRKcySYV9DcQwkJwPr4VPUFVcHavsXpIYy35zrX+Esqu6gyS3dirzc5Fs/3WfQo9 LgWlV4QmZop2oXkHJ0cXF49Zh4p7bwmbroU887QCmmO6hCvIBC5MYTaelQRWc3FrA7bEZh tg4mMNqWthTy9vPKYjbnLQocCK7MqjEE3XkloZhpeKwXY0a9kuas5S5f096MZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684481846; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=s0b94eOvefp3+7WEvu2drvDFIJlEZ7IlaghX00vjBBw=; b=cXwTYEl9bGnvYBBPNOr3w5wMzrbv2gTUSSVAc/m4964jt2B3LNIoV83xF5+ezFLKkuqiKW nywVvVeIf6fX7GnHRX/A5//5RCUyuhWs00c7woXXDbnMmVH4RZfL7TcAweYSRtKA12I2m6 9n/8+6ohuRRVz7QtRYgCI8ZNtYM5k10GfbiGuPJJ9v6VxF8UXlqMTlU0j7yhvuhd0/3/5f RwYDtNmL2iequydhCd2KRxVKxiYrJkEuZX8myypw0hvgZataEUvDf6CGyTsQc0FDg2sVcZ c4X5TCZePiMXrhpB0MYAlRmIZNUKeUeZTinJk/nRc1++griuTNCUVQgO/uWvig== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684481846; a=rsa-sha256; cv=none; b=uMmGTKH4DanezR1YgTtjDSj+GalAJeYWMtqHUAF5wnA0nYLcCJkmLyvSxoj6LLAQZtGECv g9ZaO+92iKzgxbdzhLn6eCXGaJhAB8in+qwDb+B9zDhnJa6io2+XFi6uU+lA+Ak/JrAQUw s+jUxyC+S30prUzvQ5zFbJJKR1LaP8n/m1rlNmhWmU3xo0Sm3f+A+x4FclJaPNw2LgdX7y GjZgejHL+ftXuwjZ++TBKhWuEQ14viKMIHOgDXBsGTo5JcRsy9mOOizAJjNhwHJscrS/Ln pXk4JczUYluYFeaSvtbFbUB0U658XRCU3ijfJi9YwxZ9pXTxGe/GBGq5m3PyUQ== Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QMzFf4XvLzl2c for ; Fri, 19 May 2023 07:37:26 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-pj1-f50.google.com with SMTP id 98e67ed59e1d1-253520adb30so1629729a91.1 for ; Fri, 19 May 2023 00:37:26 -0700 (PDT) X-Gm-Message-State: AC+VfDzqwOm3NpN/dlAj0og2OuGjBAcrztPfXaVU7XPHLZu6Bqz/U9mj 7jwxglEWnW/NBlWn3420heghOUptSCN3TOVkY4s= X-Google-Smtp-Source: ACHHUZ5a0xKUPLeqgDuV3bCduEAnp/HKw/ma6HYS42GY3Frd32fPKfyFFxgEOnr2MNVLOpA6xUfXgiLRK+b3rPtisXA= X-Received: by 2002:a17:90b:1109:b0:253:84dd:142c with SMTP id gi9-20020a17090b110900b0025384dd142cmr793267pjb.4.1684481845620; Fri, 19 May 2023 00:37:25 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> In-Reply-To: From: Nuno Teixeira Date: Fri, 19 May 2023 08:37:13 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Raspberry Pi POE+ hat overlay To: Mark Millard Cc: Doug Rabson , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="00000000000009f75005fc06fe05" X-ThisMailContainsUnwantedMimeParts: N --00000000000009f75005fc06fe05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 escreveu no dia quinta, 18/05/2023 =C3=A0(= s) 18:07: > On May 18, 2023, at 05:48, Nuno Teixeira wrote: > > > Indeed, voltage was the missing bit! > > > > I'm trying to setup 1800 as default now for revs >=3D 1.4 following > https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/ > that only talk about setting arm_freq=3D1800 but doesn't mention to adjus= t > 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=3D6 > > arm_freq=3D2000 > > sdram_freq_min=3D3200 > > ### force_turbo=3D1 > > > > My tests shows that we don't need force_turbo=3D1 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=3D1 with force_turbo or not, is ignored. > > > https://github.com/raspberrypi/documentation/blob/8b096a52e394c10360549af= d0a620755df467446/documentation/asciidoc/computers/config_txt/overclocking.= adoc > > (from 2021-Nov-04) did not have arm_boost documented yet. > > > https://github.com/raspberrypi/documentation/blob/da45bd8c982e91e11c60999= 1ba2fc8783872ef67/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=3D3200 here. > > > https://github.com/raspberrypi/documentation/blob/2cbcd18fc155044f20ae630= 5fa0e62629b56893c/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/75e6050edd9e1b0c47c5862= 3133dc05a02c16351/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=3D6 (?) > > arm_freq=3D2147 > > gpu_freq=3D750 > > 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=3D2100 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=3D3200 but it did > help in contexts with the default being 400. > > > Thanks, > > > > > > Mark Millard escreveu no dia quinta, 18/05/2023 > =C3=A0(s) 11:57: > > On May 18, 2023, at 01:29, Nuno Teixeira wrote: > > > > > Confirmed that arm_boost is enable by default on rpi4 rev >=3D 1.4 as= I > checked with htop. > > > > > > Also, tested arm_freq=3D1800 and it crashes FreeBSD around initializi= ng > console/video and detecting mouse. > > > > Overclocking by setting the arm_freq directly involves also > > managing over_voltage explicitly, such as: > > > > over_voltage=3D6 > > > > A sequence I use (and have used for a long time) is: > > > > [pi4] > > over_voltage=3D6 > > arm_freq=3D2000 > > sdram_freq_min=3D3200 > > force_turbo=3D1 > > > > 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=3DUSB_ERR_TIMEOUT > > # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling por= t > ? > > initial_turbo=3D60 > > > > 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=3D2000 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=3D1 > > > --- > > > 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 escreveu no dia quarta, > 17/05/2023 =C3=A0(s) 14:08: > > > (...) > > > > > > I was meant using 13.2 not 12.3 :) > > > > > > Doug Rabson escreveu no dia quarta, 17/05/2023 =C3= =A0(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 > wrote: > > > Hey, > > > > > > Ok. I'm new to rpi4 and arm in general but tomorrow I will force > 'arm_freq=3D1800' 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 escreveu no dia quarta, 17/05/2023 =C3= =A0(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=3D1 so I tried= it. > > > > > > Doug. > > > > > > > > > > > > On Wed, 17 May 2023 at 11:11, Nuno Teixeira > wrote: > > > Hello Doug, > > > > > > I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop sho= ws > 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 escreveu no dia ter=C3=A7a, 16/05/2023 = =C3=A0(s) > 17:19: > > > > > > On Sat, 13 May 2023 at 13:45, Doug Rabson 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 lo= ad > 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 t= he > cpu temperature below 65 degrees which is nice, especially since I set > arm_boost=3D1 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? > > > > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > --=20 Nuno Teixeira FreeBSD Committer (ports) --00000000000009f75005fc06fe05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for great explanation about overclocking and f= irmware.
I was lost between firmware versions used in raspberry l= inux 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 ve= rsion updates to check changes carefully.=C2=A0

Yo= urs,

Mark Millard <markl= mi@yahoo.com> escreveu no dia quinta, 18/05/2023 =C3=A0(s) 18:07:
On May 18, 2023, a= t 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 >=3D 1.4 follo= wing https://www.raspberrypi.c= om/news/bullseye-bonus-1-8ghz-raspberry-pi-4/ that only talk about sett= ing arm_freq=3D1800 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=3D6
> arm_freq=3D2000
> sdram_freq_min=3D3200
> ### force_turbo=3D1
>
> My tests shows that we don't need force_turbo=3D1 for a normal run= ning 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=3D1 with force_turbo or not, is ignored.

https://github.com/rasp= berrypi/documentation/blob/8b096a52e394c10360549afd0a620755df467446/documen= tation/asciidoc/computers/config_txt/overclocking.adoc

(from 2021-Nov-04) did not have arm_boost documented yet.

https://github.com/rasp= berrypi/documentation/blob/da45bd8c982e91e11c609991ba2fc8783872ef67/documen= tation/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=3D3200 here.

https://github.com/raspberrypi/documentation= /blob/2cbcd18fc155044f20ae6305fa0e62629b56893c/configuration/config-txt/ove= rclocking.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/rasp= berrypi/documentation/blob/75e6050edd9e1b0c47c58623133dc05a02c16351/documen= tation/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.co= m/documentation/computers/config_txt.html )
>
> Also, "7. Take it to the max" ( https://magpi.raspberrypi.com/articles/how-to-overclock-ra= spberry-pi-4 ):
>
> over_voltage=3D6 (?)
> arm_freq=3D2147
> gpu_freq=3D750

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=3D2100 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=3D3200 but it did
help in contexts with the default being 400.

> Thanks,
>
>
> Mark Millard <marklmi@yahoo.com> escreveu no dia quinta, 18/05/2023 =C3=A0(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 >=3D= 1.4 as I checked with htop.
> >
> > Also, tested arm_freq=3D1800 and it crashes FreeBSD around initia= lizing console/video and detecting mouse.
>
> Overclocking by setting the arm_freq directly involves also
> managing over_voltage explicitly, such as:
>
> over_voltage=3D6
>
> A sequence I use (and have used for a long time) is:
>
> [pi4]
> over_voltage=3D6
> arm_freq=3D2000
> sdram_freq_min=3D3200
> force_turbo=3D1
>
> 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: > #=C2=A0 =C2=A0uhub_reattach_port: port ? reset failed, error=3DUSB_ERR= _TIMEOUT
> #=C2=A0 =C2=A0uhub_reattach_port: device problem (USB_ERR_TIMEOUT), di= sabling port ?
> initial_turbo=3D60
>
> 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=3D2000 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=3D1
> > ---
> > 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 = =C3=A0(s) 14:08:
> > (...)
> >
> > I was meant using 13.2 not 12.3 :)
> >
> > Doug Rabson <dfr@rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:4= 7:
> > 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:<= br> > > Hey,
> >
> > Ok. I'm new to rpi4 and arm in general but tomorrow I will fo= rce 'arm_freq=3D1800' 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 suppo= rts this feature.
> >
> > Cheers,
> >
> > Doug Rabson <dfr@rabson.org> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:1= 1:
> > Hi Nuno,
> >
> > I'm not sure where to start - I just happened to notice in th= e documentation here: https://www= .raspberrypi.com/documentation/computers/config_txt.html that the cpu f= requency Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried it.
> >
> > Doug.
> >
> >
> >
> > On Wed, 17 May 2023 at 11:11, Nuno Teixeira <eduardo@freebsd.org> wrote:<= br> > > Hello Doug,
> >
> > I have too a 1.5 rpi but arm_boost=3D1 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=C3=A7a, 16/05/2023 =C3=A0(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.20210= 805 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 t= he 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.2021= 0831 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=3D1 in config.txt which boosts the cpu frequency up to 1800 for t= his board.
> >
> > Does anyone have a pointer to the problem with firmware later tha= n 20210805? Would it make any kind of sense to try to get the fix into rele= ng/13.2 as an errata?
> >



=3D=3D=3D
Mark Millard
marklmi at yahoo.com



--
Nuno Teixeira
FreeBSD Committ= er (ports)
--00000000000009f75005fc06fe05--