Date: Mon, 7 Sep 2020 15:14:28 +0200 (CEST) From: Ronald Klop <ronald-lists@klop.ws> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: Klaus Cucinauomo <maciphone2@googlemail.com>, freebsd-arm@freebsd.org Subject: MMCCAM - Re: onboard wireless on rpi4 Message-ID: <507782579.41.1599484468967@localhost> In-Reply-To: <09959D86-E3E3-43E9-8134-C2FC73343DBA@lists.zabbadoz.net> References: <20200904134619.GB80905@bastion.zyxst.net> <69934262-D9D3-4986-849D-9E8221D1E387@kronometrix.org> <1677459627.55.1599232125847@localhost> <75E08DC2-D229-45AA-85AE-CCF06FD0B490@kronometrix.org> <AAA3DC42-5C3E-4A1D-BE75-A20DE3BC300F@googlemail.com> <09959D86-E3E3-43E9-8134-C2FC73343DBA@lists.zabbadoz.net>
index | next in thread | previous in thread | raw e-mail
Van: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Datum: zaterdag, 5 september 2020 14:15 Aan: Klaus Cucinauomo <maciphone2@googlemail.com> CC: freebsd-arm@freebsd.org Onderwerp: Re: onboard wireless on rpi4 > > On 4 Sep 2020, at 17:35, Klaus Cucinauomo via freebsd-arm wrote: > > > Yep, my question if really no one else is working on it, was directed > to Björn ;-), > > because I don’t want to work on a completely different > implementation, > > if Björn is perhaps a few steps further. > > SDIO attach worked last year; WiFi (cfg80211) wasn’t finished. And I am not tired of hearing people ask for it. You have all the right to do so. > > I recently got a PCIe card (different bus attachment) but it should help to move forward on the WiFi parts as well. Yes, it is a free time project at the moment but it also benefits from other ongoing WiFi work. > > > Two things which may help for the RPi/SDIO parts are: > > - please try and use MMCCAM kernels and help, test, debug, report, .. all the things you find so (other people) can jump in as well so we can switch that on as default. Without that, no SDIO. > > - in case you are not only into RPi, the nanopi/rk33xx platforms with onboard SDIO WiFi need tiny little glue bits to turn the bits on; would be great if someone could just do that. > > > Bjoern > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > Hi, I've MMCCAM running since 12.1-BETA1 on rpi3B+. No problems so far. Apparently I'm to only one :-) https://dmesgd.nycbug.org/index.cgi?do=index&fts=mmccam Regards, Ronald. From owner-freebsd-arm@freebsd.org Mon Sep 7 14:42:47 2020 Return-Path: <owner-freebsd-arm@freebsd.org> Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5C72F3CB992 for <freebsd-arm@mailman.nyi.freebsd.org>; Mon, 7 Sep 2020 14:42:47 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BlWGZ3ncYz4CW6 for <freebsd-arm@freebsd.org>; Mon, 7 Sep 2020 14:42:46 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id E5F355E6 for <freebsd-arm@freebsd.org>; Mon, 7 Sep 2020 10:42:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 07 Sep 2020 10:42:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=IDPtdhMkuMrm6IoC2UaKh5B160r UiMIlthp2J2AkLsE=; b=gJA3+TrZOvSE/r3g740JtSiEe1as494jc3MfS7QJHJw OZPrzm9+dB6GkUysa+1q8OQeiIAmTTTDRiGIn+KF4Lj4QvH7e9A6v2o7b1KM3Msp fLg7PBxf7kAsJkapylMAq4jBg1LlsQ3BU/+DoHA+Q7FgFRoj+SvaWk48ErdM0KOQ MKcYiSM1yBaX/pKY+XMRMPc2ueUJ7f+k93sg3sM0bWgyw2Yv0a+Ie2zOav1Bfrnk FcV7JYuEmWehGhqECqsyKNcd2o9gSm9qsrB6CY0LvPJuim1xlarwdX30CpE5T4N9 NAm7s00JoogFldIyQRarh32BI/+Xelf5vEyaJQnXe0A=DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=IDPtdh MkuMrm6IoC2UaKh5B160rUiMIlthp2J2AkLsE=; b=bSXQw7UMgJ4U1Ed/7WCIbD QEllONK5DX6qaHFj9oib1uj/r1rp/B29rco3+arcd/zIY+LDwtgqIkEyupRf02MS n8m+VQXBeFrIF3FoWqxa/7zhL4BuJBoQVuE4CYoueYzPtGmL5fzmcGtVNmocFVln PzNYqler45l+knKAQh5HgXznRikQysEZ7cRIA3DKKb1VTiysfarKEAQPyaloZYXE HK7lxrHjnmFUypu8OyE89DiBTg+eOJsA9RYe9foBucgvMAzL5TyRDmcsjBvdony/ QfxzuRfWeYXZJ2936x0ylpxKxRom31pxgtRQW0hN+OGaelQdyqoa4EYAV80R7jrw =X-ME-Sender: <xms:4kZWX02VZW3AS8orBcD4C9_Yav_AzWbswiRb9SHiZGvptDPzfESh3w> <xme:4kZWX_HbVYlkOXXK5A4ENL2MtrBbJjVRGUkUC-5StxsEhTkDCBjnEshaBScbrs5FE CCurlhrnR601Yo4Jw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehtddgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeejgfegfeejgfeludfhveetiefhje euvedtjeeltdegffevveeuiedugeejkeevgfenucffohhmrghinhepiiihgihsthdrnhgv thdpfhhrvggvsghsugdrohhrghenucfkphepkedvrdejtddrledurdelleenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhishht shesiiihgihsthdrnhgvth X-ME-Proxy: <xmx:4kZWX86DtVR_yULxbt-_rQlG2RHf2GpTAH0EdJCimyMoCQ07aZIAIA> <xmx:4kZWX92ef5B2nSJpvvhN7RIm6MUGZBX5uvJxm4kjOVtuMIUKczM7ZQ> <xmx:4kZWX3H2EIW1bmSL93DftFWgZLQk1o9wi2jZnyBx-_7puQ_YN_sYSQ> <xmx:4kZWX7R8RCUkNECBjUP6lIDbqfh7uj7dKrwOwjhyztKfblNqlBVtHw> Received: from bastion.zyxst.net (bastion.zyxst.net [82.70.91.99]) by mail.messagingengine.com (Postfix) with ESMTPA id CDB5A306467D for <freebsd-arm@freebsd.org>; Mon, 7 Sep 2020 10:42:41 -0400 (EDT) Date: Mon, 7 Sep 2020 15:42:12 +0100 From: tech-lists <tech-lists@zyxst.net> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: rpi4 won't overclock Message-ID: <20200907144212.GB62420@bastion.zyxst.net> Mail-Followup-To: freebsd-arm <freebsd-arm@freebsd.org> References: <2F772350-6832-44CE-BCB4-F877173D320A.ref@yahoo.com> <2F772350-6832-44CE-BCB4-F877173D320A@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="61jdw2sOBCFtR2d/" Content-Disposition: inline In-Reply-To: <2F772350-6832-44CE-BCB4-F877173D320A@yahoo.com> X-Rspamd-Queue-Id: 4BlWGZ3ncYz4CW6 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm3 header.b=gJA3+TrZ; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=bSXQw7UM; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-5.05 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.147.123.25:from]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.41)[-0.413]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.970]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm3,messagingengine.com:s=fm3]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0:email]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.963]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[zyxst.net]; RCPT_COUNT_ONE(0.00)[1]; DBL_PROHIBIT(0.00)[0.0.0.0:email]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 07 Sep 2020 14:42:47 -0000 --61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Sep 06, 2020 at 05:31:15PM -0700, Mark Millard wrote: >tech-lists tech-lists at zyxst.net wrote on >Sun Sep 6 14:58:30 UTC 2020 : > >> I can't oc the pi in the usual way with -current on rpi4. Obviously I'm doing >> something wrong, but I don't know what. >> >> If I put parameters in config_rpi4.txt, they're seemingly ignored. > >Yep: config_rpi4.txt is just an example of what the config.txt file >contents should be like for a RPi4B. FreeBSD is not using the [...] >notation to be selective about what applies to what context and is >not using the include mechanism. > >So use of config.txt tailoring is involved. > >> If I take >> these out of there and put them instead at the bottom of config.txt, the pi >> will fail to boot (I think it's failing u-boot, it says, in VGA, it needs >> newer firmware). > >Have you tried making config.txt a strict copy of config_rip4.txt >with no other changes and it still fails to boot? Yes, just tried that. It will boot but it fails to boot if I set overclocking parameters in config.txt. I get to a screen that complains about newer firmware. It doesn't get as far as u-boot. I took the card out and amended it on another machine, then put it back in the rpi4. It boots, and config.txt looks like this: arm_control=0x200 arm_64bit=1 dtoverlay=disable-bt dtoverlay=mmc device_tree_address=0x4000 kernel=u-boot.bin armstub=armstub8-gic.bin #gpu_mem=16 #over_voltage=6 #arm_freq=2100 >Note: My context is based on head -r363590 . I'm now using r365391 on the pi4 > >> I've installed to rpi4 as per >> >> https://lists.freebsd.org/pipermail/freebsd-arm/2020-August/022162.html > >This is not what I've done since I experiment with uefi/ACPI >based booting and such. Even back when I tried u-boot I did >not do it the above way. (I've not tracked the u-boot based >contexts in some time.) This paragraph mostly is just noting >that I'm of limited/no help on those details. > >> The parameters I want to use are: >> >> arm_freq=2100 >> gpu_freq=750 >> over_voltage=6 > >Last I knew, u-boot style booting ignored/overrides what config.txt has >for the likes of arm_freq and probably more. It is set up for changing >settings from FreeBSD later --but FreeBSD may have no equivalent of >over_voltage=6 for all I know. (The FreeBSD u-boot based RPi3B that I >have access to behaves similarly for FreeBSD. boot -s always ends >up at a 600 MHz before something I put in /etc/sysctl.conf changes >the setting.) On my rpi3 12.1-STABLE r363237 GENERIC I have the following in /boot/msdos/config.txt: arm_control=0x200 dtparam=audio=on,i2c_arm=on,spi=on dtoverlay=mmc dtoverlay=pwm dtoverlay=disable-bt device_tree_address=0x4000 kernel=u-boot.bin #force_turbo=1 gpu_mem=16 arm_freq=1500 over_voltage=4 which normally gives 1.5GHz under load, nothing in /etc/sysctl.conf is setting this parameter. I have just enabled powerd and rebooted, but it hasn't come back so I suspect in my case it's applying config.txt but there's a powerd <-> config.txt interaction happening preventing it from booting. >The uefi/ACPI alternative for the RPi4B does use use the config.txt >settings, even as seen via boot -s. (This is the environment I >normally experiment with for the RPi4B.) > >I use over_voltage=6 and arm_freq=2000 on multiple RPi4B's. (I do not >adjust gpu_freq.) This makes the clock rate match a MACCHIATObin Double >Shot and has been reliable on the RPi4B's (4 GiB and 8 GiB). (Memory >subsystem properties make the MACCHIATObin faster at various >activities.) > >I did do some margin testing initially and figures around 2100 were >not reliable for keeping the RPi4B's operating. Of course, various >things can contribute to what setting work with some margin for >environment variability. I've got heatsinks, fans, and (apparently) >good power. I'm using dedicated power supplies made for rpi3 and rpi4. Am using heatsinks on the rpi3 in a clear plastic case on the rpi3 and a FLIRC aluminium heatsink case on the rpi4. >So far as I know, using the uefi/ACPI and the over_voltage=6 and >arm_freq=2000 leads to a context that runs at an essentially fixed >frequency, even when idle. > >> Even with make -j4 it sits stubbornly at 0.6GHz. > >It has been a long time since I've tried u-boot based for >the RPi4B. I have now got it to 1500 thanks to https://lists.freebsd.org/pipermail/freebsd-arm/2020-September/022279.html The very highest temperature it got to was 61 degC in 25 degC ambient with make -j4 buildworld >For the OPi+2E, Rock64, RPi3B I use in /etc/sysctl.conf : > >dev.cpu.0.freq=1008 # OPi+2E >dev.cpu.0.freq=1200 # Rock64 and RPi3B I'll try that on the rpi3. Do you use powerd? on either rpi3 or rpi4. >but for the RPi4B with the uefi/ACPI style boot process there >is no sysctl dev.cpu.0.freq to assign or inspect. Can you explain what you mean by uefi/ACPI style boot process? Or is there a link that explains it. I only know of one boot process with freebsd on rpi boards, and thats via u-boot. On my rpi4 I have that sysctl, and can modify it: freebsd@rpi4 ~ % sysctl dev.cpu.0.freq dev.cpu.0.freq: 600 freebsd@rpi4 ~ % sudo sysctl dev.cpu.0.freq=2000 dev.cpu.0.freq: 600 -> 1500 reebsd@rpi4 ~ % sysctl -a | grep dev.cpu.0. dev.cpu.0.temperature: 49.0C dev.cpu.0.freq_levels: 1500/-1 600/-1 dev.cpu.0.freq: 1500 dev.cpu.0.%parent: cpulist0 dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,cortex-a72 dev.cpu.0.%location: dev.cpu.0.%driver: cpu dev.cpu.0.%desc: Open Firmware CPU >So far as I know, the dev.cpu.0.freq assignments lead to >fix frequency operation: as I have not done anything >explicit to cause dynamic changes. Again: heatsinks, fans, >and good power. yeah it seems once set, it stays there. But because freq_levels has only two values, I can only set one or the other of these values. 2000 is not available. If I don't set it in the sysctl, speed becomes dynamic according to load. >I'll note that my experiments with timing rebuilds (from >scratch) ended up with times being shortest for -j3 for >the RPi4B. (Not surprising given the memory subsystem >properties from what I can tell.) Thanks, I'll try that next time I rebuild the kernel. >> The cpu is usually below 40 >> degC in a 20 degC environment. It'll go to 46 degC when make buildkernel runs. >> >> I've tried much lower parameters with the same result. What am I doing wrong? > >Overall, I do not know. But maybe some of the above will be >of use. It is useful, many thanks. How are you booting your rpi4s if not via u-boot? You're setting parameters in config.txt for the rpi4 ? -- J. --61jdw2sOBCFtR2d/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAl9WRtYACgkQs8o7QhFz NAUoMg//epaLY0tbxZsdzKmzAldaPbiX19gfD7JbhH83Ixyiug9xRjDIGTkpTTlz UbU1WUUJ9QQ+bHATC8jGwbxeDEs4qHL0BCqssVmiV6iBvisg62quixpkJ7+eS2FM KMLW3vbjjpf2JKGAypgbn4Y2H4m+Pta6RwVmUlXfXlwsdgrb/0qVqgkVOJmL8Znv 1IzT+21JBcArlUiqsDFe3ItyTHReo2yeKrhgAY4VCr+3oYAQ65YWcGcCzGVHlcnv jL9u5dwIfONXJ1Hd6w46avmyhwZlc7zEy9aiK6ozkAylukpLmsZwW020kuCrbooF BpM7UlpBObQrq4LU7lDIshvRD6pf6qMljkmlnm/cUZFJLZJIV9CgefyjYSrPHSi5 62XRJ1VYzLxKPRgu9EJAUCKFH2hiKDLqr2uORmRGuVPjbHy/ps8cAadvNqz+cKbE Qc0NAW6Z0jbFq3BxZ29GljnwpBgyxiwA/bkYsOWOn87TB8JZMlFV7NPOMjJn4YKB QfEzmD+VJtKG45Ei2PegCjcw7VgXACPo4s8tbUUW5e0cftUvuSqrDtGOdHdTemqj 1kTm4lcveOBHjbmaT46GoNvEjbQWvXeFLYAKu6eMq72AB6hjrN03JaRXi5+D6o5Z 3fw/V2Rva0CSpcYP1Xw9jNIy+hAztWLTBR6lGIT8ZOoDQTIkeLk=Evae -----END PGP SIGNATURE----- --61jdw2sOBCFtR2d/--home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?507782579.41.1599484468967>