From owner-freebsd-arm@freebsd.org Mon Jan 18 19:07:47 2021 Return-Path: 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 758CE4F3645 for ; Mon, 18 Jan 2021 19:07:47 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.160]) (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 (2048 bits) client-digest SHA256) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DKLry3N7lz4rQP for ; Mon, 18 Jan 2021 19:07:46 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1610996863; s=strato-dkim-0002; d=obsigna.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:From: Subject:Sender; bh=eTi8inKXweXL5wxMFcHzyfbKdOU7DAuKl/5iCE8ecxA=; b=jHtLydPQEBKukBuBykRZI7CLAxNMfqZHNbPuIhkM69bKA9qDK2ln6KR5eyjsat7Yxs rtGDm2X9Vezx5mQfO5DLiqkiLrqj3TNjsKPE0kYx9K14VHOsma/BpGF8esdnPdj5AUJi LztnGPQE/X4J54OoI9BGyN6gKuujTWexIaHi44Is+/0hhi4dKFP6mztrJLI1i7Y9Jzpb hAw1C864TgLz+gwA1/toS9PBdqhOHtL3PtNi6m1RtXsBrIU6MiL0xI0hzJGqTsRN8j/j 24wFfsjXepNpYuvxUUAIgkw3Qvte/eZr9y7fkVbgRWAFfIxbRyIl31bCINw07W2LgkG2 ZxOw== X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio0dVVInWnas+zpAhAiA/W" X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com by smtp.strato.de (RZmta 47.12.1 DYNA|AUTH) with ESMTPSA id d0872bx0IJ7gn6K (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 18 Jan 2021 20:07:42 +0100 (CET) Received: from rolf-aux.obsigna.com (rolf-aux.obsigna.com [192.168.222.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 0C5FD1350F946; Mon, 18 Jan 2021 16:07:38 -0300 (-03) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: GENERICSD snapshot on a BBB has issues with loading the if_rtwn_usb module From: "Dr. Rolf Jansen" In-Reply-To: <9F0684B2-02EA-4647-BA02-8C6F80C421F7@obsigna.com> Date: Mon, 18 Jan 2021 16:07:38 -0300 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9C2425C5-ABF2-4A3B-8C93-C20554A59000@obsigna.com> References: <47700631-2D94-4BA8-9707-9ADD70C99600@obsigna.com> <20210116184333.f91594f9c3505d2c588d9634@bidouilliste.com> <20210116184833.1a3182a20a2b6c727b64bb59@bidouilliste.com> <06F689CA-B781-4CEB-8F8A-B00FAC684DD3@obsigna.com> <20210117174539.43b55379e6a37881589616a8@bidouilliste.com> <20210117225539.c113796159735c5a3950c774@bidouilliste.com> <03F9A3D3-0A2B-4B09-9C8D-AAAF761C0F4C@obsigna.com> <20210118094510.48eee03d502ea25ab7d09938@bidouilliste.com> <9F0684B2-02EA-4647-BA02-8C6F80C421F7@obsigna.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.7) X-Rspamd-Queue-Id: 4DKLry3N7lz4rQP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=obsigna.com header.s=strato-dkim-0002 header.b=jHtLydPQ; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-rj@obsigna.com designates 81.169.146.160 as permitted sender) smtp.mailfrom=freebsd-rj@obsigna.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:81.169.146.128/25]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[obsigna.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[81.169.146.160:from]; ASN(0.00)[asn:6724, ipnet:81.169.144.0/22, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[obsigna.com:s=strato-dkim-0002]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[obsigna.com]; SPAMHAUS_ZRD(0.00)[81.169.146.160:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[81.169.146.160:from]; FROM_NAME_HAS_TITLE(1.00)[dr]; RWL_MAILSPIKE_POSSIBLE(0.00)[81.169.146.160:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 19:07:47 -0000 > Am 18.01.2021 um 09:02 schrieb Dr. Rolf Jansen = : >=20 >> Am 18.01.2021 um 05:45 schrieb Emmanuel Vadot = : >>=20 >> On Sun, 17 Jan 2021 19:01:24 -0300 >> "Dr. Rolf Jansen" wrote: >>=20 >>>> Am 17.01.2021 um 18:55 schrieb Emmanuel Vadot = : >>>>=20 >>>> On Sun, 17 Jan 2021 18:49:01 -0300 >>>> "Dr. Rolf Jansen" wrote: >>>>=20 >>>>>> Am 17.01.2021 um 13:45 schrieb Emmanuel Vadot = : >>>>>>=20 >>>>>> On Sat, 16 Jan 2021 15:11:28 -0300 >>>>>> "Dr. Rolf Jansen" > wrote: >>>>>>=20 >>>>>>>> Am 16.01.2021 um 14:48 schrieb Emmanuel Vadot = >: >>>>>>>>=20 >>>>>>>> On Sat, 16 Jan 2021 18:43:33 +0100 >>>>>>>> Emmanuel Vadot >> wrote: >>>>>>>>=20 >>>>>>>>> On Sat, 16 Jan 2021 14:08:58 -0300 >>>>>>>>> "Dr. Rolf Jansen" wrote: >>>>>>>>>=20 >>>>>>>>>> I updated one of my BBB from an older 13-CURRENT (July 2020) = to the latest 13-ALPHA1 snapshot from Jan, 14th ? = GENERICSD-20210114-7ae27c2d6c4-255938. >>>>>>>>>>=20 >>>>>>>>>> I had successfully employed an USB-WLAN dongle based on the = RTL8188eu chipset. I only added the following into /boot/loader.conf: >>>>>>>>>>=20 >>>>>>>>>> if_rtwn_usb_load=3D"YES" >>>>>>>>>>=20 >>>>>>>>>> By that all dependend modules were loaded automatically in a = snap. With ALPHA1 this doesn?t work anymore. After hours of = troubleshooting, I got it working by adding the following into = /etc/rc.conf: >>>>>>>>>>=20 >>>>>>>>>> kld_list=3D"if_rtwn_usb" >>>>>>>>>>=20 >>>>>>>>>> The "Loading kernel modules:" takes apprx. 4 seconds, = however, then the USB-WLAN device is enumerated correctly and it is = ready to use. This makes me think that this uncommon huge delay is the = culprit. I checked this with some snapshot thats I had installed = already. The issue seems to have been introduced together with the = switch to GENERICSD. A GENERICSD 13-CURRENT from end of December showed = this issue already, while a BBB-specific snapshot (from November 2020) = that I had installed on another BBB works as before by loading the = modules in /boot/loader.conf. >>>>>>>>>>=20 >>>>>>>>>> I don't mind to load the modules by the way of the kld_list = directive in /etc/rc.conf. However, the unusual long duration of loading = the module and its dependencies might be an indication for a more = fundamental issue. >>>>>>>>>>=20 >>>>>>>>>> Please feel free to ask me for doing more tests.=20 >>>>>>>>>>=20 >>>>>>>>>> Best regards >>>>>>>>>>=20 >>>>>>>>>> Rolf >>>>>>>>>=20 >>>>>>>>> I can reproduce that on my netbooted BBB. >>>>>>>>> The module is correctly loaded : >>>>>>>>>=20 >>>>>>>>> Loading >>>>>>>>> kernel... /boot/kernel/kernel text=3D0x1b4 text=3D0x68d638 = text=3D0x1c84f0 >>>>>>>>> data=3D0xb4070 data=3D0x0+0x258000 = syms=3D[0x4+0xa5ab0+0x4+0x119fd4] Loading >>>>>>>>> configured modules... /boot/kernel/if_rtwn_usb.ko text=3D0xb960 >>>>>>>>> text=3D0x62c0 data=3D0x2cc+0x3b syms=3D[0x4+0x3570+0x4+0x293f] = /boot/entropy >>>>>>>>> size=3D0x1000 /etc/hostid >>>>>>>>> size=3D0x25 Using DTB provided by EFI at >>>>>>>>> 0x87f00000. Kernel entry at >>>>>>>>> 0x96e00200... Kernel args: >>>>>>>>> (null) = =20 >>>>>>>>> ---<>--- = =20 >>>>>>>>>=20 >>>>>>>>> But it isn't loaded anymore after booting : >>>>>>>>> root@bbb:~ # kldstat=20 >>>>>>>>> Id Refs Address Size Name >>>>>>>>> 1 1 0xc0000000 d23a8c kernel >>>>>>>>>=20 >>>>>>>>> I don't think it has to do with the switch to GENERICSD, there = is (at >>>>>>>>> least shouldn't be) any difference between the old BBB image = and the >>>>>>>>> GENERICSD one. >>>>>>>=20 >>>>>>> Yes, this might well be a coincidence. I do neither have the = last BBB specific snapshot nor the first GENERICSD one for testing these = against each other. >>>>>>>=20 >>>>>>>> Just did a test on my OrangePi One (Allwinner H3 armv7 with = 512MB of >>>>>>>> RAM) and this is the same. >>>>>>>> The problem seems to be module dependancy, loader only loads >>>>>>>> if_rtnw_usb but doing a kldload also brings wlan.ko and rtwn.ko >>>>>>>=20 >>>>>>> I can confirm this. And in addition loading the if_rtwn_usb.ko = module and its dependcies manually also takes now significantly longer = compared to a manual load on the BBB specific 13-CURRENT from November. = Perhaps something has been changed in the dependency resolver. >>>>>>>=20 >>>>>>=20 >>>>>> Fixed in 0f2434ea000e >>>>>>=20 >>>>>> Thanks for reporting. >>>>>=20 >>>>> Unfortunately, this did not resolve the issue. I updated my = working copy with git pull and verified that your changes made it into = my source tree. Then I built a new kernel and replaced the original = ALPHA1 kernel from 2021-01-14 by this new one. The rtwn-modules are = still not loaded by the if_rtwn_usb_load=3D"YES" directive in = /boot/loader.conf. >>>>>=20 >>>>> Best regards >>>>>=20 >>>>> Rolf >>>>=20 >>>> You need to update loader.efi on the ESP partition. >>>=20 >>> Please excuse my ignorance. Do I need to build world for this? Then = where is the newly build loader.efi? >>>=20 >>> Best regards >>>=20 >>> Rolf >>=20 >> It's part of buildworld yes but you can rebuild it with : >> (cd stand/ && make buildenv TARGET_ARCH=3Darmv7 BUILDENV_SHELL=3D"make >> clean all -sj4") >>=20 >> Then locate loader_lua.efi in the obj directory and place it in the >> ESP (the fat16/fat32 partition) as efi/boot/bootarm.efi >=20 > This resolved the issue. >=20 > Thank you very much and best regards While loading of kernel modules do work with the newly build = loader_lua.efi, a regression emerged. In /boot/loader.conf I have for = some time now the directive loader_color=3D"NO" in order to prevent the = serial console changes from my default scheme black text on white = background to white on black. Since today, the serial console shows = again everything white on black. Is this directive not functional = anymore? How can I force the serial console keep on showing black text = on white background? Best regards Rolf