From nobody Wed Jan 29 06:42:19 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YjXdl2Rfqz5mCnQ for ; Wed, 29 Jan 2025 06:42:35 +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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YjXdk33j6z3WY7; Wed, 29 Jan 2025 06:42:34 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none Received: from skull.home.blih.net (arennes-299-1-68-49.w92-159.abo.wanadoo.fr [92.159.163.49]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 8e28b1c9 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 29 Jan 2025 06:42:27 +0000 (UTC) Date: Wed, 29 Jan 2025 07:42:19 +0100 From: Emmanuel Vadot To: "Bjoern A. Zeeb" Cc: Mark Millard , FreeBSD Current , rea@freebsd.org Subject: Re: "don't know how to make /usr/main-src/sys/contrib/dev/iwm/iwm-3160-17.fw.uu. Stop" Message-Id: <20250129074219.c8c48eb025acc65e3dbbce72@bidouilliste.com> In-Reply-To: <597porsp-1p95-36on-04r1-95r8s6sq2nsn@yvfgf.mnoonqbm.arg> References: <978176f7-270c-4603-b80a-e29c3b1b4b73@FreeBSD.org> <4FC807EC-10DD-49FD-AACE-9026B4925923@yahoo.com> <1B14894C-78E3-4696-9E4F-FBA97A356BF1@yahoo.com> <597porsp-1p95-36on-04r1-95r8s6sq2nsn@yvfgf.mnoonqbm.arg> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4YjXdk33j6z3WY7 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] Hello, On Wed, 29 Jan 2025 03:33:17 +0000 (UTC) "Bjoern A. Zeeb" wrote: > On Mon, 27 Jan 2025, Mark Millard wrote: > > > On Jan 26, 2025, at 20:51, Adrian Chadd wrote: > > > > > >> Hi! > > > > Hello. > > > >> So, there's no longer a build target for the firmware uuencoded files -> kernel module. > > > > Yea. But there are the sys/conf/files dependency lines in > > main that still list .fw.uu files. That includes a reference > > related to the error I get in my context unless I avoid > > "device iwmfw" in the kernel configuration: > > > > /. . ./sys/conf/files: dependency "$S/contrib/dev/iwm/iwm-3160-17.fw.uu" \ > > > > It makes things look like the .fw.uu removal activity is still > > incomplete. > > Yes it is, This commit missed them. Manu, will you remove them? There is actually two problems with my commits, the first one is that you cannot compile a kernel with iwm firmware in it, rea@ sent me some patches a few weeks ago that solves that so this will be fixed soon-ish. The second is people loading from loader who updates their box from 13/14 to current, as make installkernel doesn't install the firmware anymore it will fail, removing iwm_load from loader.conf for the upgrade phase is the way to go I think as I don't see any other way. > commit af0a81b6470aba4af4a24ae9804053722846ded4 > Author: Emmanuel Vadot > AuthorDate: Thu Dec 12 17:13:58 2024 +0100 > Commit: Emmanuel Vadot > CommitDate: Mon Dec 16 10:44:47 2024 +0100 > > iwm: Stop shipping firmware as kernel module > > Since we can load raw firmware start shipping them as is. > This also remove the uuencode format that don't add any value and garbage > collect old firmwares version. > For pkgbase users they are now in the FreeBSD-firmware-iwm package. > > > > >> Being able to build iwm in the kernel rather than a module is broken. > >> > >> Now, the real issue(s) are that iwm needs firmware to initialise, and the firmware needs to exist, and thus it needs access to the rootfs for firmware_get() to find the now binary files in /boot/firmware instead of the kernel module old way, and that whole pipeline is broken if it's loaded at boot time or included in the kernel directly. There isn't a nice way to defer the firmware load attempt until /after/ rootfs is up. > > The answer is not to load it from loader anymore really but let devd do > it's job. Yes agreed and I've done that for quite some time but it seems that we advertize for a long time that loading wifi module from loader wasthe way to go so a lot of people were bitten by this. > That is monolithic kernels + firmware are still the problem but I am not > generally thinking this is the problem here. > > But yes, there would also be ways for firmware laod to be defered but > that's also a different story. Agreed. > > Yep. > > Firmware can still be loaded from loader. The following commit should have > made that more easily possible without changes. > > commit a0f06dfb0d188966bee7265ec7d9f20093186bb6 > Author: Emmanuel Vadot > AuthorDate: Mon Jan 6 08:34:02 2025 +0100 > Commit: Emmanuel Vadot > CommitDate: Mon Jan 6 08:34:02 2025 +0100 > > loader: Add a list of firmware name mapping > > Since we started to ship raw firmware for iwm(4), users who loads > the driver from loader are having problems as loader don't know that > the firmwares are now raw files and not kernel modules anymore. > Start a list of default entry for iwm(4) firmwares name mapping so it will > still works when loaded from loader. > > Differential Revision: https://reviews.freebsd.org/D48211 > Reviewed by: bz, imp, kevans > > > /bz > > -- > Bjoern A. Zeeb r15:7 -- Emmanuel Vadot