Date: Fri, 19 May 2023 08:38:56 +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: <CAFDf7U%2B8nmn%2BJGTZwmEmzbZZ2yXfRm9By%2B-vqjVGbbc9PB3biA@mail.gmail.com> In-Reply-To: <CAFDf7UL2GkSjGC51cchy2dO6-PxCdngJ-dBAhZ4L1nh9iHUYrg@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> <B727EB08-3E78-433E-9F45-37FB9EB621C4@yahoo.com> <CAFDf7UL2GkSjGC51cchy2dO6-PxCdngJ-dBAhZ4L1nh9iHUYrg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000029915105fc070489 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (...) Using: [pi4] over_voltage=3D6 arm_freq=3D2000 sdram_freq_min=3D3200 force_turbo=3D1 Start to like force_turbo on :) Cheers! Nuno Teixeira <eduardo@freebsd.org> escreveu no dia sexta, 19/05/2023 =C3= =A0(s) 08:37: > 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 <marklmi@yahoo.com> escreveu no dia quinta, 18/05/2023 =C3= =A0(s) > 18:07: > >> On May 18, 2023, at 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 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 >> 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/8b096a52e394c10360549a= fd0a620755df467446/documentation/asciidoc/computers/config_txt/overclocking= .adoc >> >> (from 2021-Nov-04) did not have arm_boost documented yet. >> >> >> https://github.com/raspberrypi/documentation/blob/da45bd8c982e91e11c6099= 91ba2fc8783872ef67/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/2cbcd18fc155044f20ae63= 05fa0e62629b56893c/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/75e6050edd9e1b0c47c586= 23133dc05a02c16351/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 <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 a= s I >> checked with htop. >> > > >> > > Also, tested arm_freq=3D1800 and it crashes FreeBSD around initializ= ing >> 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 >> 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 thi= s >> 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 trie= d 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 sh= ows >> 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 l= oad >> 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=3D1 in config.txt which boosts the cpu frequency up to 1800 fo= r >> 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) > --=20 Nuno Teixeira FreeBSD Committer (ports) --00000000000029915105fc070489 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>(...)</div><div><br></div><div>Using:</div><div><br><= /div><div><span class=3D"gmail-im">[pi4]<br> over_voltage=3D6<br> arm_freq=3D2000<br> sdram_freq_min=3D3200<br> force_turbo=3D1</span></div><div><span class=3D"gmail-im"><br></span></div>= <div><span class=3D"gmail-im">Start to like force_turbo on :)</span></div><= div><span class=3D"gmail-im"><br></span></div><div><span class=3D"gmail-im"= >Cheers!<br></span></div></div><br><div class=3D"gmail_quote"><div dir=3D"l= tr" class=3D"gmail_attr">Nuno Teixeira <<a href=3D"mailto:eduardo@freebs= d.org">eduardo@freebsd.org</a>> escreveu no dia sexta, 19/05/2023 =C3=A0= (s) 08:37:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div = dir=3D"ltr"><div>Thanks for great explanation about overclocking and firmwa= re.</div><div>I was lost between firmware versions used in raspberry linux = and freebsd port.</div><div><br></div><div>Now I have a better picture of w= hy this setup make sense for a specific firmware.</div><div><br></div><div>= I will stick with freq 2000 as my first goal was to set to 1800.<br></div><= div><br></div><div>And for now on, I will be watching firmware port version= updates to check changes carefully.=C2=A0</div><div><br></div><div>Yours,<= br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma= il_attr">Mark Millard <<a href=3D"mailto:marklmi@yahoo.com" target=3D"_b= lank">marklmi@yahoo.com</a>> escreveu no dia quinta, 18/05/2023 =C3=A0(s= ) 18:07:<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, 2023, at 05:48, Nuno Teixeira <<a href=3D"mailto:eduardo@freebsd.org= " target=3D"_blank">eduardo@freebsd.org</a>> wrote:<br> <br> > Indeed, voltage was the missing bit!<br> > <br> > I'm trying to setup 1800 as default now for revs >=3D 1.4 follo= wing <a href=3D"https://www.raspberrypi.com/news/bullseye-bonus-1-8ghz-rasp= berry-pi-4/" rel=3D"noreferrer" target=3D"_blank">https://www.raspberrypi.c= om/news/bullseye-bonus-1-8ghz-raspberry-pi-4/</a> that only talk about sett= ing arm_freq=3D1800 but doesn't mention to adjust voltage.<br> > It was nice that raspberry tell us what voltage exacly value they use = for new default 1800.<br> > <br> > What I've got now is:<br> > <br> > [pi4]<br> > over_voltage=3D6<br> > arm_freq=3D2000<br> > sdram_freq_min=3D3200<br> > ### force_turbo=3D1<br> > <br> > 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.<b= r> <br> I will note that the RPi* firmware itself varies the<br> frequency and voltages by default --but the way of<br> disabling that also disables powerd from being<br> effective as I understand. (As I understand the<br> firmware's policy details have changed over time<br> but I do not know the details or when.)<br> <br> This makes use of powerd on the RPi*, with the firmware's<br> adjustments also enabled, involve 2 competing mechanisms,<br> if I understand right. I'm not aware of any horrible<br> consequences in actual ooperation but I found force_turbo<br> to lead to less time being taken in build activities back<br> when I last measured it.<br> <br> It is true that I've not looked into this area in a long<br> time.<br> <br> > Also, arm_boost=3D1 with force_turbo or not, is ignored.<br> <br> <a href=3D"https://github.com/raspberrypi/documentation/blob/8b096a52e394c1= 0360549afd0a620755df467446/documentation/asciidoc/computers/config_txt/over= clocking.adoc" rel=3D"noreferrer" target=3D"_blank">https://github.com/rasp= berrypi/documentation/blob/8b096a52e394c10360549afd0a620755df467446/documen= tation/asciidoc/computers/config_txt/overclocking.adoc</a><br> <br> (from 2021-Nov-04) did not have arm_boost documented yet.<br> <br> <a href=3D"https://github.com/raspberrypi/documentation/blob/da45bd8c982e91= e11c609991ba2fc8783872ef67/documentation/asciidoc/computers/config_txt/over= clocking.adoc" rel=3D"noreferrer" target=3D"_blank">https://github.com/rasp= berrypi/documentation/blob/da45bd8c982e91e11c609991ba2fc8783872ef67/documen= tation/asciidoc/computers/config_txt/overclocking.adoc</a><br> <br> (from 2021-Nov-11) has arm_boost documented.<br> <br> These give a clue about the vintage of RPi* firmware needed<br> to have the arm_boost notation implemented.<br> <br> > sdram_freq and sdram_freq_min are set to 3200 by default, so I think I= will not need sdram_freq_min=3D3200 here.<br> <br> <a href=3D"https://github.com/raspberrypi/documentation/blob/2cbcd18fc15504= 4f20ae6305fa0e62629b56893c/configuration/config-txt/overclocking.md" rel=3D= "noreferrer" target=3D"_blank">https://github.com/raspberrypi/documentation= /blob/2cbcd18fc155044f20ae6305fa0e62629b56893c/configuration/config-txt/ove= rclocking.md</a><br> <br> (from 2021-Mar-31) shows the Pi4 sdram_freq_min as 400.<br> The defaults have changed with firmware updates.<br> <br> Note that the official RPi* port has 2021-Mar-03 firmware,<br> so before 2021-Mar-31.<br> <br> <a href=3D"https://github.com/raspberrypi/documentation/blob/75e6050edd9e1b= 0c47c58623133dc05a02c16351/documentation/asciidoc/computers/config_txt/over= clocking.adoc" rel=3D"noreferrer" target=3D"_blank">https://github.com/rasp= berrypi/documentation/blob/75e6050edd9e1b0c47c58623133dc05a02c16351/documen= tation/asciidoc/computers/config_txt/overclocking.adoc</a><br> <br> (from 2021-Aug-09) shows the Pi4/CM4 sdram_freq_min as 3200.<br> <br> These give a clue about the vintage of RPi* firmware needed<br> to have the sdram_freq_min be 3200 by default.<br> <br> My settings are for a wide range of firmware vintages, not<br> just modern ones. Each item was shown (at the time added)<br> was shown to cut the times for the likes of buildworld,<br> buildkernel, or poudriere bulk activities that I did.<br> <br> Also, I tend to leave in place what has worked and still<br> does work, rather than to track the changes in defaults<br> over time in even more detail. I'd likely have different<br> settings listed if I'd started at a later point that had<br> newer defaults.<br> <br> > The only thing that I can't understand is how to calculate voltage= :<br> > <br> > over_voltage: 0 (1.35V, 1.2V on Raspberry Pi 1) ???<br> > ( <a href=3D"https://www.raspberrypi.com/documentation/computers/confi= g_txt.html" rel=3D"noreferrer" target=3D"_blank">https://www.raspberrypi.co= m/documentation/computers/config_txt.html</a> )<br> > <br> > Also, "7. Take it to the max" ( <a href=3D"https://magpi.ras= pberrypi.com/articles/how-to-overclock-raspberry-pi-4" rel=3D"noreferrer" t= arget=3D"_blank">https://magpi.raspberrypi.com/articles/how-to-overclock-ra= spberry-pi-4</a> ):<br> > <br> > over_voltage=3D6 (?)<br> > arm_freq=3D2147<br> > gpu_freq=3D750<br> <br> I'll note that I never attempted to take each RPi4B to<br> its maximum for normal operation. I targeted having a<br> setting combination that was reliable (had some margin)<br> on all the example RPi4B's.<br> <br> I did have to explore were failures occured to do that.<br> I did have access to RPi4B's that were unreliable with<br> arm_freq=3D2100 for any over_voltage that I tried. Backing<br> off to 2000 gave me reliable results on all the RPi4B's.<br> <br> I never had trouble with sdram_freq_min=3D3200 but it did<br> help in contexts with the default being 400.<br> <br> > Thanks,<br> > <br> > <br> > Mark Millard <<a href=3D"mailto:marklmi@yahoo.com" target=3D"_blank= ">marklmi@yahoo.com</a>> escreveu no dia quinta, 18/05/2023 =C3=A0(s) 11= :57:<br> > 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 initia= lizing 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= _TIMEOUT<br> > #=C2=A0 =C2=A0uhub_reattach_port: device problem (USB_ERR_TIMEOUT), di= sabling 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"_blank">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"_blan= k">dfr@rabson.org</a>> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:4= 7:<br> > > I'm not sure about 12.3 either - you could try with 13.2 and = see if that makes a difference.<br> > > <br> > > On Wed, 17 May 2023 at 13:45, Nuno Teixeira <<a href=3D"mailto= :eduardo@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 fo= rce '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 suppo= rts this feature.<br> > > <br> > > Cheers,<br> > > <br> > > Doug Rabson <<a href=3D"mailto:dfr@rabson.org" target=3D"_blan= k">dfr@rabson.org</a>> escreveu no dia quarta, 17/05/2023 =C3=A0(s) 13:1= 1:<br> > > Hi Nuno,<br> > > <br> > > I'm not sure where to start - I just happened to notice in th= e documentation here: <a href=3D"https://www.raspberrypi.com/documentation/= computers/config_txt.html" rel=3D"noreferrer" target=3D"_blank">https://www= .raspberrypi.com/documentation/computers/config_txt.html</a> that the cpu f= requency 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= :eduardo@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"_blan= k">dfr@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:d= fr@rabson.org" target=3D"_blank">dfr@rabson.org</a>> wrote:<br> > > 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.<br> > > <br> > > 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.<br> > > <br> > > 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?<br> > > <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 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> --00000000000029915105fc070489--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFDf7U%2B8nmn%2BJGTZwmEmzbZZ2yXfRm9By%2B-vqjVGbbc9PB3biA>