Date: Thu, 18 May 2023 13:48:18 +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: <CAFDf7ULDX6BSFSZghHUoznAAtbWetOQFQ5eT-Mdn-yuQXPUtsg@mail.gmail.com> In-Reply-To: <ACDA9D81-C0C7-40E7-801A-FB41DAA687F5@yahoo.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>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000ba09be05fbf7383e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 adjust volta= ge. 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. 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 initializing > 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 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:47: > > I'm not sure about 12.3 either - you could try with 13.2 and see if tha= t > 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 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.20210805 an= d > this boots successfully on pi400 as well as rpi4. With this, I can load t= he > 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) --000000000000ba09be05fbf7383e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <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.raspbe= rrypi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/">https://www.raspberry= pi.com/news/bullseye-bonus-1-8ghz-raspberry-pi-4/</a> that only talk about = setting arm_freq=3D1800 but doesn't mention to adjust voltage.</div><di= v>It was nice that raspberry tell us what voltage exacly value they use for= new default 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">https:/= /www.raspberrypi.com/documentation/computers/config_txt.html</a> )</div><di= v><br></div><div>Also, "7. Take it to the max" ( <a href=3D"https= ://magpi.raspberrypi.com/articles/how-to-overclock-raspberry-pi-4">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></div></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">Mark Millard <<a href=3D"mailto:ma= rklmi@yahoo.com">marklmi@yahoo.com</a>> escreveu no dia quinta, 18/05/20= 23 =C3=A0(s) 11:57:<br></div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1= ex">On May 18, 2023, at 01:29, Nuno Teixeira <<a href=3D"mailto:eduardo@= freebsd.org" target=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 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> --000000000000ba09be05fbf7383e--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFDf7ULDX6BSFSZghHUoznAAtbWetOQFQ5eT-Mdn-yuQXPUtsg>