Re: iwm not in GENERIC kernel
> On Nov 2, 2017, at 09:53, Adrian Chadd wrote: > > ugh okay > > So it's a chicken/egg problem. > > You can't finish the device probe/attach until the firmware loads. > > For iwn, you can read the chipset abilities and mac address from > EPROM/flash on the chip without the firmware being loaded, so you can > complete probe/attach before the root filesystem is mounted. > > For iwm, you have to load the firmware before you can read the chipset > abilities and MAC address so you can't complete probe/attach until > AFTER the root filesystem is mounted. > > If someone wants to go add all of that support in to have probe/attach > deferred until after rootfs is available then please do so. Or, just > support the firmware being 100% compiled in- but when I tried this the > last time I ran out of some firmware arena size preventing other > firmware for other chipsets from being loaded. > > Otherwise this is the current hack. :) It’s ok (better than nothing)! Could you please write up bugs with your findings? Thanks so much! -Ngie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: iwm not in GENERIC kernel
ugh okay So it's a chicken/egg problem. You can't finish the device probe/attach until the firmware loads. For iwn, you can read the chipset abilities and mac address from EPROM/flash on the chip without the firmware being loaded, so you can complete probe/attach before the root filesystem is mounted. For iwm, you have to load the firmware before you can read the chipset abilities and MAC address so you can't complete probe/attach until AFTER the root filesystem is mounted. If someone wants to go add all of that support in to have probe/attach deferred until after rootfs is available then please do so. Or, just support the firmware being 100% compiled in- but when I tried this the last time I ran out of some firmware arena size preventing other firmware for other chipsets from being loaded. Otherwise this is the current hack. :) Sorry! -adrian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: iwm not in GENERIC kernel
> On Oct 29, 2017, at 11:01, Warner Losh wrote: ... > The blobs run on the actual card itself, not on the host. This is the > firmware for the wireless SoC that's on the card. We have allowed those in > the kernel since the very early days of the project when scsi controllers > like isp(4) downloaded firmware. > > This is somewhat different than the recently discussed HBAs that have binary > blobs that run on the host, which have no business in GENERIC… I’m just the messenger relaying what’s currently in place in the code based on what I remember from past discussions. If you disagree with what’s in place with MK_SOURCELESS_UCODE, please feel free to change it (how it works is already documented in multiple places, and this is what Linux does too with their firmware blobs). Also, it helps when the firmware driver is properly wired up to the kernel build system: r324470, r325122. The kernel module could compile on its own if someone cd’ed to the modules directory, but was broken otherwise, meaning that it wasn’t compiling as a module, or compiling into the kernel, prior to the before mentioned commits. Cheers, -Ngie signature.asc Description: Message signed with OpenPGP using GPGMail
Re: iwm not in GENERIC kernel
On Sun, Oct 29, 2017 at 11:29 AM, Ngie Cooper (yaneurabeya) < yaneurab...@gmail.com> wrote: > > > On Oct 29, 2017, at 10:26, Kevin Oberman wrote: > > … > > > But I thought that all modern wireless interfaces and many others load > blobs. Is the source for the firmware blob for iwn (which is in GENERIC) > available? > > There’s a piece that’s open sourced that a BSD developer has > written, but there’s also a binary payload that we have no insight into. > Cheers, > -Ngie > > $ file sys/contrib/dev/iwm/*.uu > sys/contrib/dev/iwm/iwm-3160-16.fw.uu: uuencoded or xxencoded, ASCII text > sys/contrib/dev/iwm/iwm-3160-17.fw.uu: uuencoded or xxencoded, ASCII text > sys/contrib/dev/iwm/iwm-3160-9.fw.uu: empty > sys/contrib/dev/iwm/iwm-7260-16.fw.uu: uuencoded or xxencoded, ASCII text > sys/contrib/dev/iwm/iwm-7260-17.fw.uu: uuencoded or xxencoded, ASCII text > sys/contrib/dev/iwm/iwm-7260-9.fw.uu: empty > sys/contrib/dev/iwm/iwm-7265-16.fw.uu: uuencoded or xxencoded, ASCII text > sys/contrib/dev/iwm/iwm-7265-17.fw.uu: uuencoded or xxencoded, ASCII text > sys/contrib/dev/iwm/iwm-7265-9.fw.uu: empty > sys/contrib/dev/iwm/iwm-7265D-17.fw.uu: uuencoded or xxencoded, ASCII text > sys/contrib/dev/iwm/iwm-7265D-22.fw.uu: uuencoded or xxencoded, ASCII text > sys/contrib/dev/iwm/iwm-8000C-16.fw.uu: uuencoded or xxencoded, ASCII text > sys/contrib/dev/iwm/iwm-8000C-17.fw.uu: uuencoded or xxencoded, ASCII text > sys/contrib/dev/iwm/iwm-8000C-22.fw.uu: uuencoded or xxencoded, ASCII text > sys/contrib/dev/iwm/iwm-8265-22.fw.uu: uuencoded or xxencoded, ASCII text > The blobs run on the actual card itself, not on the host. This is the firmware for the wireless SoC that's on the card. We have allowed those in the kernel since the very early days of the project when scsi controllers like isp(4) downloaded firmware. This is somewhat different than the recently discussed HBAs that have binary blobs that run on the host, which have no business in GENERIC... Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: iwm not in GENERIC kernel
> On Oct 29, 2017, at 10:26, Kevin Oberman wrote: … > But I thought that all modern wireless interfaces and many others load blobs. > Is the source for the firmware blob for iwn (which is in GENERIC) available? There’s a piece that’s open sourced that a BSD developer has written, but there’s also a binary payload that we have no insight into. Cheers, -Ngie $ file sys/contrib/dev/iwm/*.uu sys/contrib/dev/iwm/iwm-3160-16.fw.uu: uuencoded or xxencoded, ASCII text sys/contrib/dev/iwm/iwm-3160-17.fw.uu: uuencoded or xxencoded, ASCII text sys/contrib/dev/iwm/iwm-3160-9.fw.uu: empty sys/contrib/dev/iwm/iwm-7260-16.fw.uu: uuencoded or xxencoded, ASCII text sys/contrib/dev/iwm/iwm-7260-17.fw.uu: uuencoded or xxencoded, ASCII text sys/contrib/dev/iwm/iwm-7260-9.fw.uu: empty sys/contrib/dev/iwm/iwm-7265-16.fw.uu: uuencoded or xxencoded, ASCII text sys/contrib/dev/iwm/iwm-7265-17.fw.uu: uuencoded or xxencoded, ASCII text sys/contrib/dev/iwm/iwm-7265-9.fw.uu: empty sys/contrib/dev/iwm/iwm-7265D-17.fw.uu: uuencoded or xxencoded, ASCII text sys/contrib/dev/iwm/iwm-7265D-22.fw.uu: uuencoded or xxencoded, ASCII text sys/contrib/dev/iwm/iwm-8000C-16.fw.uu: uuencoded or xxencoded, ASCII text sys/contrib/dev/iwm/iwm-8000C-17.fw.uu: uuencoded or xxencoded, ASCII text sys/contrib/dev/iwm/iwm-8000C-22.fw.uu: uuencoded or xxencoded, ASCII text sys/contrib/dev/iwm/iwm-8265-22.fw.uu: uuencoded or xxencoded, ASCII text signature.asc Description: Message signed with OpenPGP using GPGMail
Re: iwm not in GENERIC kernel
On Sun, Oct 29, 2017 at 9:49 AM, Ngie Cooper (yaneurabeya) < yaneurab...@gmail.com> wrote: > > > On Oct 29, 2017, at 02:46, Thomas Mueller wrote: > > … > > > Is that binary blob the reason why rsu is not in GENERIC? > > > > I use rsu for Hiro H50191 USB wireless adapter. > > Yup. > But I thought that all modern wireless interfaces and many others load blobs. Is the source for the firmware blob for iwn (which is in GENERIC) available? -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: iwm not in GENERIC kernel
> On Oct 29, 2017, at 02:46, Thomas Mueller wrote: … > Is that binary blob the reason why rsu is not in GENERIC? > > I use rsu for Hiro H50191 USB wireless adapter. Yup. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: iwm not in GENERIC kernel
from Ngie Cooper: > > On Oct 28, 2017, at 18:09, Gordon Tetlow wrote: > > I have an Intel NUC that uses an Intel 8260 wireless driver. This works > > flawlessly if I load the module if_iwm via the loader or the rc.conf > > kld_list directive. > > Do we know if the iwm driver not being in GENERIC is an oversight or on > > purpose? I couldn't find anything in the list history. > Itâs on purpose since it has a binary blob firmware driver that it relies > on, IIRC. > -Ngie Is that binary blob the reason why rsu is not in GENERIC? I use rsu for Hiro H50191 USB wireless adapter. Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: iwm not in GENERIC kernel
> On Oct 28, 2017, at 18:09, Gordon Tetlow wrote: > > I have an Intel NUC that uses an Intel 8260 wireless driver. This works > flawlessly if I load the module if_iwm via the loader or the rc.conf > kld_list directive. > > Do we know if the iwm driver not being in GENERIC is an oversight or on > purpose? I couldn't find anything in the list history. It’s on purpose since it has a binary blob firmware driver that it relies on, IIRC. -Ngie signature.asc Description: Message signed with OpenPGP using GPGMail
iwm not in GENERIC kernel
I have an Intel NUC that uses an Intel 8260 wireless driver. This works flawlessly if I load the module if_iwm via the loader or the rc.conf kld_list directive. Do we know if the iwm driver not being in GENERIC is an oversight or on purpose? I couldn't find anything in the list history. Gordon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
