Re: "don't know how to make /usr/main-src/sys/contrib/dev/iwm/iwm-3160-17.fw.uu. Stop"

 Hello,

On Wed, 29 Jan 2025 03:33:17 +0000 (UTC)
"Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> wrote:

> On Mon, 27 Jan 2025, Mark Millard wrote:
> 
> > On Jan 26, 2025, at 20:51, Adrian Chadd <adrian@freebsd.org> 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 <manu@FreeBSD.org>
> AuthorDate: Thu Dec 12 17:13:58 2024 +0100
> Commit:     Emmanuel Vadot <manu@FreeBSD.org>
> 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 <manu@FreeBSD.org>
> AuthorDate: Mon Jan 6 08:34:02 2025 +0100
> Commit:     Emmanuel Vadot <manu@FreeBSD.org>
> 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 <manu@bidouilliste.com> <manu@freebsd.org>