Date: Thu, 18 May 2023 14:21:29 +0100 From: Nuno Teixeira <eduardo@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: Doug Rabson <dfr@rabson.org>, freebsd-arm@freebsd.org Subject: Re: Raspberry Pi POE+ hat overlay Message-ID: <CAFDf7ULRen6JP3-4-Na43b%2BHqWU42Cd-rz-WJUKEMqgHrLf7OQ@mail.gmail.com> In-Reply-To: <CAFDf7ULcj%2Bt0ce5QdAKcePm3SdoZaFFCkkPUmqzPjyuOpM-GxA@mail.gmail.com> References: <CACA0VUh9-7o55pXcyn=Ep9mPexAkgjKLEKUh6HqMovTxe2_R0Q@mail.gmail.com> <E615D3BE-C12D-4960-BB01-AD2D40CA90A5@yahoo.com> <CACA0VUjCyhPCxBTn6h_HMOGjdFnivi5bnq4jgcg4i0bKY%2BF0PA@mail.gmail.com> <D6869D48-5661-4054-90D8-2B394CA5D25E@yahoo.com> <77CD0716-3BC8-47EB-8743-F2BD9CA43D31@yahoo.com> <432A1A16-9FE5-4339-AB38-8F3E03A5D4EF@yahoo.com> <CACA0VUhDwx%2BRmHU_OSFfGhjfbbbiy6HpurGL7WjM_i%2B0U7UpBQ@mail.gmail.com> <CACA0VUhdi2%2BGXpjmco0%2B5801t0Vso50Bat1UxJ2a4RJChxkU9w@mail.gmail.com> <CAFDf7UL9iSHcaaOYwU5A8RVYZpYDL65v-2FCprsyL2FLz8Cc8Q@mail.gmail.com> <CACA0VUhLi-HU5hJzV5xTSHVLBdoCCGKovY8fEgzbHXTfYD4JWQ@mail.gmail.com> <CAFDf7U%2BCmcB0sPT8WmssQ7bhv2DaDSS4MXNELDTxKHVuVhgkSw@mail.gmail.com> <CACA0VUhzf25MiOGZasfEueO=H1rmN1MnNW8gnryGk1w_he2aog@mail.gmail.com> <CAFDf7U%2Bh8NbLRC4v=6KNhPFLYr7LQ1rK4nDzxa=wQ3u%2BEhBZLA@mail.gmail.com> <CAFDf7UKv8RHH35tso3Zd9On81D=0O2Ocbz%2B5zgebwKSRqqy6Xg@mail.gmail.com> <ACDA9D81-C0C7-40E7-801A-FB41DAA687F5@yahoo.com> <CAFDf7ULDX6BSFSZghHUoznAAtbWetOQFQ5eT-Mdn-yuQXPUtsg@mail.gmail.com> <CAFDf7ULcj%2Bt0ce5QdAKcePm3SdoZaFFCkkPUmqzPjyuOpM-GxA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000005a6a4d05fbf7af32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (...) Tomorrow I will take it to the max: over_voltage=3D6 arm_freq=3D2147 gpu_freq=3D750 :) Nuno Teixeira <eduardo@freebsd.org> escreveu no dia quinta, 18/05/2023 =C3= =A0(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 > =C3=A0(s) 13:48: > >> Hello Mark! >> >> 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 adju= st >> voltage. >> It was nice that raspberry tell us what voltage exacly value they use fo= r >> 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 a= nd >> system do an auto 600 -> 2000 change when needed. Thats nice. >> Also, arm_boost=3D1 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=3D3200 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=3D6 (?) >> arm_freq=3D2147 >> gpu_freq=3D750 >> >> 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 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 <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: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=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 <dfr@rabson.org> 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 <eduardo@freebsd.org> >>> 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 <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.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 th= e >>> 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=3D1 in config.txt which boosts the cpu frequency up to 1800 f= or >>> 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 >>> >>> >> >> -- >> Nuno Teixeira >> FreeBSD Committer (ports) >> > > > -- > Nuno Teixeira > FreeBSD Committer (ports) > --=20 Nuno Teixeira FreeBSD Committer (ports) --0000000000005a6a4d05fbf7af32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>(...)</div><div><br></div><div>Tomorrow I will take i= t to the max:</div><div><br></div><div>over_voltage=3D6<br>arm_freq=3D2147<= br>gpu_freq=3D750</div><div><br></div><div>:)<br></div></div><br><div class= =3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Nuno Teixeira <<a= href=3D"mailto:eduardo@freebsd.org">eduardo@freebsd.org</a>> escreveu n= o dia quinta, 18/05/2023 =C3=A0(s) 14:11:<br></div><blockquote class=3D"gma= il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2= 04,204);padding-left:1ex"><div dir=3D"ltr"><div>(...)</div><div><br></div><= div>Found a nice table of overvoltage at <a href=3D"https://www.qengineerin= g.eu/overclocking-the-raspberry-pi-4.html" target=3D"_blank">https://www.qe= ngineering.eu/overclocking-the-raspberry-pi-4.html</a></div><div><br></div>= <div>(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 settin= g it).</div><div><br></div><div>I'm at poudriere building www/node18 wi= th with -J4 cores and freq from 1500->2000 temperature changes from ~46C= ->~57C</div><div>4 heatsinks and a case fan.</div><div><br></div><div>I&= #39;m so happy!</div><div><br></div><div>Thanks!<br> </div></div><br><div c= lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Nuno Teixeira &l= t;<a href=3D"mailto:eduardo@freebsd.org" target=3D"_blank">eduardo@freebsd.= org</a>> escreveu no dia quinta, 18/05/2023 =C3=A0(s) 13:48:<br></div><b= lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hello= Mark!</div><div><br></div><div>Indeed, voltage was the missing bit!</div><= div><br></div><div>I'm trying to setup 1800 as default now for revs >= ;=3D 1.4 following <a href=3D"https://www.raspberrypi.com/news/bullseye-bon= us-1-8ghz-raspberry-pi-4/" target=3D"_blank">https://www.raspberrypi.com/ne= ws/bullseye-bonus-1-8ghz-raspberry-pi-4/</a> that only talk about setting a= rm_freq=3D1800 but doesn't mention to adjust voltage.</div><div>It was = nice that raspberry tell us what voltage exacly value they use for new defa= ult 1800.<br></div><div><br></div><div>What I've got now is:</div><div>= <br></div><div>[pi4]<br> over_voltage=3D6<br> arm_freq=3D2000<br> sdram_freq_min=3D3200<br> ### force_turbo=3D1</div><div><br></div><div>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.<br></div><div>Also, arm_boost=3D1 wi= th force_turbo or not, is ignored.</div><div><br></div><div>sdram_freq and = sdram_freq_min are set to 3200 by default, so I think I will not need sdram= _freq_min=3D3200 here.</div><div><br></div><div>The only thing that I can&#= 39;t understand is how to calculate voltage:</div><div><br></div><div>over_= voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ???<br></div><div>( <a href=3D"h= ttps://www.raspberrypi.com/documentation/computers/config_txt.html" target= =3D"_blank">https://www.raspberrypi.com/documentation/computers/config_txt.= html</a> )</div><div><br></div><div>Also, "7. Take it to the max"= ( <a href=3D"https://magpi.raspberrypi.com/articles/how-to-overclock-raspb= erry-pi-4" target=3D"_blank">https://magpi.raspberrypi.com/articles/how-to-= overclock-raspberry-pi-4</a> ):</div><br>over_voltage=3D6 (?)<br>arm_freq= =3D2147<br>gpu_freq=3D750<div><br></div><div>Thanks,<br></div><div><br></di= v></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr= ">Mark Millard <<a href=3D"mailto:marklmi@yahoo.com" target=3D"_blank">m= arklmi@yahoo.com</a>> escreveu no dia quinta, 18/05/2023 =C3=A0(s) 11:57= :<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.= 8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On May 18, 202= 3, at 01:29, Nuno Teixeira <<a href=3D"mailto:eduardo@freebsd.org" targe= t=3D"_blank">eduardo@freebsd.org</a>> wrote:<br> <br> > Confirmed that arm_boost is enable by default on rpi4 rev >=3D 1.4 = as I checked with htop.<br> > <br> > Also, tested arm_freq=3D1800 and it crashes FreeBSD around initializin= g console/video and detecting mouse.<br> <br> Overclocking by setting the arm_freq directly involves also<br> managing over_voltage explicitly, such as:<br> <br> over_voltage=3D6<br> <br> A sequence I use (and have used for a long time) is:<br> <br> [pi4]<br> over_voltage=3D6<br> arm_freq=3D2000<br> sdram_freq_min=3D3200<br> force_turbo=3D1<br> <br> But each RPi4B has heatsinks, a case with a fan,<br> and a power supply rated for 5.1V 3.5A (so: has<br> some extra margin).<br> <br> But the range of RPi4B's span Rev 1.1, Rev 1.4,<br> and Rev 1.5, a mix of 4 GiByte RAM and 8 GiByte<br> RAM models. All use those settings.<br> <br> As I understand, arm_boost implicitly does the<br> extra things required for its implicit frequency,<br> unlike assigning arm_freq or the like.<br> <br> If force_turbo is not used, it can be that:<br> <br> #<br> # Local addition that avoids USB3 SSD boot failures that look like:<br> #=C2=A0 =C2=A0uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIME= OUT<br> #=C2=A0 =C2=A0uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabli= ng port ?<br> initial_turbo=3D60<br> <br> is required for USB based booting. But this also<br> gets into if the notation is supported or not for<br> the firmware vintage used.<br> <br> The initial_turbo use happens to avoid frequency<br> variability during boot and it appears that FreeBSD<br> does not necessarily tolerate such variability in<br> that time frame.<br> <br> Also: I happen to have USB3 boot media for which use<br> of usb_pgood_delay=3D2000 is sufficient but without<br> some such in/for U-Boot, U-Boot has problems<br> recognizing the device (before FreeBSD is even<br> involved). I build the U-Boot port with the<br> assignment built in.<br> <br> > As linux config.txt says:<br> > ---<br> > [pi4]<br> > # Run as fast as firmware / board allows<br> > arm_boost=3D1<br> > ---<br> > firmware must be updated to support this feature for sure.<br> <br> I'm not aware of a dated list of when the various<br> config.txt notations were first supported (firmware<br> version). This makes it messier to use the web's<br> published information, if one is using the firmware<br> vintage that FreeBSD has in its port for the<br> firmware.<br> <br> The notation that I use has been around for a long<br> time.<br> <br> > Cheers,<br> > <br> > Nuno Teixeira <<a href=3D"mailto:eduardo@freebsd.org" target=3D"_bl= ank">eduardo@freebsd.org</a>> escreveu no dia quarta, 17/05/2023 =C3=A0(= s) 14:08:<br> > (...)<br> > <br> > I was meant using 13.2 not 12.3 :)<br> > <br> > Doug Rabson <<a href=3D"mailto:dfr@rabson.org" target=3D"_blank">df= r@rabson.org</a>> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:47:<br= > > I'm not sure about 12.3 either - you could try with 13.2 and see i= f that makes a difference.<br> > <br> > On Wed, 17 May 2023 at 13:45, Nuno Teixeira <<a href=3D"mailto:edua= rdo@freebsd.org" target=3D"_blank">eduardo@freebsd.org</a>> wrote:<br> > Hey,<br> > <br> > Ok. I'm new to rpi4 and arm in general but tomorrow I will force &= #39;arm_freq=3D1800' again just to see it it crashes again.<br> > I will check too what values linux shows.<br> > <br> > I don't know if firmware/uboot version included in 12.3 supports t= his feature.<br> > <br> > Cheers,<br> > <br> > Doug Rabson <<a href=3D"mailto:dfr@rabson.org" target=3D"_blank">df= r@rabson.org</a>> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:11:<br= > > Hi Nuno,<br> > <br> > I'm not sure where to start - I just happened to notice in the doc= umentation here: <a href=3D"https://www.raspberrypi.com/documentation/compu= ters/config_txt.html" rel=3D"noreferrer" target=3D"_blank">https://www.rasp= berrypi.com/documentation/computers/config_txt.html</a> that the cpu freque= ncy Pi4B R1.4 was listed as 1800 if arm_boot=3D1 so I tried it.<br> > <br> > Doug.<br> > <br> > <br> > <br> > On Wed, 17 May 2023 at 11:11, Nuno Teixeira <<a href=3D"mailto:edua= rdo@freebsd.org" target=3D"_blank">eduardo@freebsd.org</a>> wrote:<br> > Hello Doug,<br> > <br> > I have too a 1.5 rpi but arm_boost=3D1 isn't doing anything, htop = shows 1500Mhz when doing something intensive.<br> > I'm running 13.2 stable<br> > <br> > Do I missing something?<br> > <br> > Could you take a look at my setup?<br> > <br> > Thanks,<br> > <br> > Doug Rabson <<a href=3D"mailto:dfr@rabson.org" target=3D"_blank">df= r@rabson.org</a>> escreveu no dia ter=C3=A7a, 16/05/2023 =C3=A0(s) 17:19= :<br> > <br> > On Sat, 13 May 2023 at 13:45, Doug Rabson <<a href=3D"mailto:dfr@ra= bson.org" target=3D"_blank">dfr@rabson.org</a>> wrote:<br> > I was able to build an updated rpi-firmware port based on 1.20210805 a= nd 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 un= documented mailbox API by reading the Linux code.<br> > <br> > I have a first approximation of a fan driver which works with the 1.20= 210805 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 rp= i4B rev 1.5 with 'make -j4 buildworld' and the fan is keeping the c= pu temperature below 65 degrees which is nice, especially since I set arm_b= oost=3D1 in config.txt which boosts the cpu frequency up to 1800 for this b= oard.<br> > <br> > Does anyone have a pointer to the problem with firmware later than 202= 10805? Would it make any kind of sense to try to get the fix into releng/13= .2 as an errata?<br> > <br> <br> <br> =3D=3D=3D<br> Mark Millard<br> marklmi at <a href=3D"http://yahoo.com" rel=3D"noreferrer" target=3D"_blank= ">yahoo.com</a><br> <br> </blockquote></div><br clear=3D"all"><br><span>-- </span><br><div dir=3D"lt= r"><div dir=3D"ltr"><span style=3D"color:rgb(102,102,102)">Nuno Teixeira<br= >FreeBSD Committer (ports)</span></div></div> </blockquote></div><br clear=3D"all"><br><span>-- </span><br><div dir=3D"lt= r"><div dir=3D"ltr"><span style=3D"color:rgb(102,102,102)">Nuno Teixeira<br= >FreeBSD Committer (ports)</span></div></div> </blockquote></div><br clear=3D"all"><br><span class=3D"gmail_signature_pre= fix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"l= tr"><span style=3D"color:rgb(102,102,102)">Nuno Teixeira<br>FreeBSD Committ= er (ports)</span></div></div> --0000000000005a6a4d05fbf7af32--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFDf7ULRen6JP3-4-Na43b%2BHqWU42Cd-rz-WJUKEMqgHrLf7OQ>