From owner-freebsd-arm@freebsd.org Mon Jan 18 21:20:57 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 187C44F6093 for ; Mon, 18 Jan 2021 21:20:57 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DKPpb3qgSz3GPr for ; Mon, 18 Jan 2021 21:20:55 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1611004853; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KScA9iv2/Bw4UgvGLN32OWMH/knggjBGgmzI5ZuCE4c=; b=QY3XME6shCa+77d3hmOeJUY3fQ/JoPUokOkUCsskUKqYopNxOXkB17Sq3EPYodXvfe7A4Q fJ6iPdqxUxpj2jVHI+Yn9sHOSRhJcb0eVz0DrOPHh4+2bO9pRftoubl49jBIOwgYLwwFs+ T0Iqc219RS+0C0J4i/ZJUmIZyMjWabc= Received: from amy.home (lfbn-idf2-1-745-114.w86-247.abo.wanadoo.fr [86.247.192.114]) by mx.blih.net (OpenSMTPD) with ESMTPSA id d1817f52 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 18 Jan 2021 21:20:53 +0000 (UTC) Date: Mon, 18 Jan 2021 22:20:52 +0100 From: Emmanuel Vadot To: "Dr. Rolf Jansen" Cc: freebsd-arm@freebsd.org Subject: Re: GENERICSD snapshot on a BBB has issues with loading the if_rtwn_usb module Message-Id: <20210118222052.2e0d6c824f0685be8199ad03@bidouilliste.com> In-Reply-To: <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> <9C2425C5-ABF2-4A3B-8C93-C20554A59000@obsigna.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DKPpb3qgSz3GPr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=QY3XME6s; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+mx]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[212.83.155.74:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.83.155.74:from]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; 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 21:20:57 -0000 On Mon, 18 Jan 2021 16:07:38 -0300 "Dr. Rolf Jansen" wrote: > > Am 18.01.2021 um 09:02 schrieb Dr. Rolf Jansen : > > > >> Am 18.01.2021 um 05:45 schrieb Emmanuel Vadot : > >> > >> On Sun, 17 Jan 2021 19:01:24 -0300 > >> "Dr. Rolf Jansen" wrote: > >> > >>>> Am 17.01.2021 um 18:55 schrieb Emmanuel Vadot : > >>>> > >>>> On Sun, 17 Jan 2021 18:49:01 -0300 > >>>> "Dr. Rolf Jansen" wrote: > >>>> > >>>>>> Am 17.01.2021 um 13:45 schrieb Emmanuel Vadot : > >>>>>> > >>>>>> On Sat, 16 Jan 2021 15:11:28 -0300 > >>>>>> "Dr. Rolf Jansen" > wrote: > >>>>>> > >>>>>>>> Am 16.01.2021 um 14:48 schrieb Emmanuel Vadot >: > >>>>>>>> > >>>>>>>> On Sat, 16 Jan 2021 18:43:33 +0100 > >>>>>>>> Emmanuel Vadot >> wrote: > >>>>>>>> > >>>>>>>>> On Sat, 16 Jan 2021 14:08:58 -0300 > >>>>>>>>> "Dr. Rolf Jansen" wrote: > >>>>>>>>> > >>>>>>>>>> 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. > >>>>>>>>>> > >>>>>>>>>> I had successfully employed an USB-WLAN dongle based on the RTL8188eu chipset. I only added the following into /boot/loader.conf: > >>>>>>>>>> > >>>>>>>>>> if_rtwn_usb_load="YES" > >>>>>>>>>> > >>>>>>>>>> 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: > >>>>>>>>>> > >>>>>>>>>> kld_list="if_rtwn_usb" > >>>>>>>>>> > >>>>>>>>>> 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. > >>>>>>>>>> > >>>>>>>>>> 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. > >>>>>>>>>> > >>>>>>>>>> Please feel free to ask me for doing more tests. > >>>>>>>>>> > >>>>>>>>>> Best regards > >>>>>>>>>> > >>>>>>>>>> Rolf > >>>>>>>>> > >>>>>>>>> I can reproduce that on my netbooted BBB. > >>>>>>>>> The module is correctly loaded : > >>>>>>>>> > >>>>>>>>> Loading > >>>>>>>>> kernel... /boot/kernel/kernel text=0x1b4 text=0x68d638 text=0x1c84f0 > >>>>>>>>> data=0xb4070 data=0x0+0x258000 syms=[0x4+0xa5ab0+0x4+0x119fd4] Loading > >>>>>>>>> configured modules... /boot/kernel/if_rtwn_usb.ko text=0xb960 > >>>>>>>>> text=0x62c0 data=0x2cc+0x3b syms=[0x4+0x3570+0x4+0x293f] /boot/entropy > >>>>>>>>> size=0x1000 /etc/hostid > >>>>>>>>> size=0x25 Using DTB provided by EFI at > >>>>>>>>> 0x87f00000. Kernel entry at > >>>>>>>>> 0x96e00200... Kernel args: > >>>>>>>>> (null) > >>>>>>>>> ---<>--- > >>>>>>>>> > >>>>>>>>> But it isn't loaded anymore after booting : > >>>>>>>>> root@bbb:~ # kldstat > >>>>>>>>> Id Refs Address Size Name > >>>>>>>>> 1 1 0xc0000000 d23a8c kernel > >>>>>>>>> > >>>>>>>>> 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. > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>>> 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 > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>> > >>>>>> Fixed in 0f2434ea000e > >>>>>> > >>>>>> Thanks for reporting. > >>>>> > >>>>> 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="YES" directive in /boot/loader.conf. > >>>>> > >>>>> Best regards > >>>>> > >>>>> Rolf > >>>> > >>>> You need to update loader.efi on the ESP partition. > >>> > >>> Please excuse my ignorance. Do I need to build world for this? Then where is the newly build loader.efi? > >>> > >>> Best regards > >>> > >>> Rolf > >> > >> It's part of buildworld yes but you can rebuild it with : > >> (cd stand/ && make buildenv TARGET_ARCH=armv7 BUILDENV_SHELL="make > >> clean all -sj4") > >> > >> Then locate loader_lua.efi in the obj directory and place it in the > >> ESP (the fat16/fat32 partition) as efi/boot/bootarm.efi > > > > This resolved the issue. > > > > 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="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 Yes we compile with TERM_EMU now so you might need to adjust teken.bg_color and teken.bg_color in loader.conf I think -- Emmanuel Vadot