Re: bwfm NVRAM file
On Fri, 13 Mar 2020 16:41:41 +0100
Patrick Wildt wrote:
> On Fri, Mar 13, 2020 at 12:12:18PM +0100, Rob Schmersel wrote:
> > Hello,
> >
> > In order to use a SDIO based bwfm device a "NVRAM" configuration
> > file will be needed besides the firmware file. This configuration
> > file is expected to be in the /etc/firmware directory, in the form
> > of brcmfmac{chip}-sdio.txt OR brcmfmac{chip}-sdio.nvram
> >
> > The need for this configuration file is not described in the man
> > page. However the device will not be usable without one and an
> > error message will be shown in the dmesg:
> > "failed loadfirmware of file: brcmfmac{chip}-sdio.txt"
> >
> > Can I suggest to below attached patch.
> >
> > I'm a bit unsure on how to indicate where the configuration file
> > comes from: Under Linux it is recommended that you read the NVRAM
> > contents from EFI, which I don't think is possible to do under
> > OpenBSD
> >
> > Hunting down the configuration file through your favorite search
> > engine can be a frustrating excercise, although you can find them
> > occasionally included in a windows driver or a linux distro.
> >
> > Question: Are there plans to include the NVRAM files in
> > bwfm_firmware package?
>
> It all depends! The NVRAM file is board-design-specific. So, let's
> assume OpenBSD and NetBSD would each build their own machine, using
> the same chip and firmware. The NVRAM file contains a configuration
> for the chip, so that it e.g. can limit TX/antenna gain or whatever.
> This is important for stuff like CE certification. There are quite a
> few settings, so it's very likely that the one board's chip needs a
> different configuration than the other one's chip.
>
> So where do we get this file? If it's an x86-based machine, it's
> likely they stored it as EFI variable. In OpenBSD, so far only the
> ARM ports support calling into the Runtime Services using efi(4).
> Since we don't have support for efi(4) on x86, OpenBSD cannot read
> the EFI variables. For that you'll have to boot Linux, or some
> other OS that has that feature. On some other x86 machines, the
> vendor might provide the file as part of a Windows firmware package.
>
> Is it different on ARMs? Well, yes, but not sure if worse or even
> better. The NVRAM file can usually be found on the vendor's Github.
>
> linux-firmware.git has started collecting and distributing some of
> the files. So that will be a helpful source for us. Otherwise we
> will have to collect them ourselves.
>
> For ARM there's still one commit left so that we can supply per-
> board NVRAM files more easily. In essence: We're working on it!
>
> Patrick
>
Aah I did not find linux-firmware.git during my search, most likely as
I was looking for bcm43341 nvram. That is not there :)
for reference attahced the file I got through the windows driver for
this specific mini pc from china
BR/Rob
#AP6234_NVRAM_V1.2_20140820_WIN8.1
manfid=0x2d0
prodid=0x0653
vendid=0x14e4
devid=0x4386
boardtype=0x0653
boardrev=0x1203
boardnum=22
macaddr=00:90:4c:c5:12:38
sromrev=3
#boardflags:
# bit 19 3tswitch: 2.4GHz FEM: SP3T switch share with BT
# bit 16 nopa: no external pa
#keep original 0x200
boardflags=0x0090201
xtalfreq=37400
nocrc=1
ag0=255
aa2g=1
ccode=CN
pa0itssit=0x20
#PA parameters for 2.4GHz
#pa0b0=6957 default
pa0b0=6727
pa0b1=-858
pa0b2=-178
tssifloor2g=69
# rssi params for 2.4GHz
rssismf2g=0xf
rssismc2g=0x8
rssisav2g=0x1
cckPwrOffset=3
# rssi params for 5GHz
rssismf5g=0xf
rssismc5g=0x7
#rssisav5g=0x1
rssisav5g=0x3
#PA parameters for lower a-band
#pa1lob0=5659 default
pa1lob0=5859
#pa1lob0=5659
pa1lob1=-693
pa1lob2=-178
tssifloor5gl=77
#PA parameters for midband
pa1b0=5372
#pa1b0=5172
pa1b1=-671
pa1b2=-212
tssifloor5gm=77
#PA paramasdeters for high band
#pa1hib0=5320 default
pa1hib0=5620
#pa1hib1=-963
pa1hib1=-663
pa1hib2=-179
tssifloor5gh=74
rxpo5g=0
maxp2ga0=72
# 19.5dBm max; 18dBm target
#Per rate power back-offs for g band, in .5 dB steps. Set it once you
have the right numbers. cck2gpo=0x
ofdm2gpo=0x
# R54 16dBm; R48 17dBm; others 18dBm
mcs2gpo0=0x
# M0~ M4 17dBm
mcs2gpo1=0x
# M5M6 15dBm; M7 14.5dBm
#max power for 5G
maxp5ga0=68
# 16dBm target; 17.5dBm Max
maxp5gla0=68
maxp5gha0=68
#Per rate power back-offs for a band, in .5 dB steps. Set it once you
have the right numbers. ofdm5gpo=0x
# R54 13.5dBm
ofdm5glpo=0x
ofdm5ghpo=0x
mcs5gpo0=0x
# M0~M4 16dBm (1dB higher than ofdm)
mcs5gpo1=0x
# M5M6 13.5dBm; M7 12dBm
mcs5glpo0=0x
mcs5glpo1=0x
mcs5ghpo0=0x
mcs5ghpo1=0x
# Parameters for DAC2x mode and ALPF bypass
# RF SW Truth Table: ctrl0 for BT_TX; ctrl1 or 5G Tx; ctrl2 for 5G Rx;
Ctrl3 for 2G Tx; Ctrl4 for 2G Rx
swctrlmap_2g=0x00080008,0x00100010,0x00080008,0x011010,0x11f
swctrlmap_5g=0x00040004,0x00020002,0x00040004,0x011010,0x2fe gain=32
triso2g=8
triso5g=8
#tx parameters
loflag=0
iqlocalidx5g=40
dlocalidx5g=70
iqcalidx5g=50
lpbckmode5g=1
Re: bwfm NVRAM file
On Fri, Mar 13, 2020 at 12:12:18PM +0100, Rob Schmersel wrote:
> Hello,
>
> In order to use a SDIO based bwfm device a "NVRAM" configuration file
> will be needed besides the firmware file. This configuration file is
> expected to be in the /etc/firmware directory, in the form of
> brcmfmac{chip}-sdio.txt OR brcmfmac{chip}-sdio.nvram
>
> The need for this configuration file is not described in the man page.
> However the device will not be usable without one and an error message
> will be shown in the dmesg:
> "failed loadfirmware of file: brcmfmac{chip}-sdio.txt"
>
> Can I suggest to below attached patch.
>
> I'm a bit unsure on how to indicate where the configuration file comes from:
> Under Linux it is recommended that you read the NVRAM contents from
> EFI, which I don't think is possible to do under OpenBSD
>
> Hunting down the configuration file through your favorite search engine
> can be a frustrating excercise, although you can find them
> occasionally included in a windows driver or a linux distro.
>
> Question: Are there plans to include the NVRAM files in bwfm_firmware
> package?
It all depends! The NVRAM file is board-design-specific. So, let's
assume OpenBSD and NetBSD would each build their own machine, using
the same chip and firmware. The NVRAM file contains a configuration
for the chip, so that it e.g. can limit TX/antenna gain or whatever.
This is important for stuff like CE certification. There are quite a
few settings, so it's very likely that the one board's chip needs a
different configuration than the other one's chip.
So where do we get this file? If it's an x86-based machine, it's
likely they stored it as EFI variable. In OpenBSD, so far only the
ARM ports support calling into the Runtime Services using efi(4).
Since we don't have support for efi(4) on x86, OpenBSD cannot read
the EFI variables. For that you'll have to boot Linux, or some
other OS that has that feature. On some other x86 machines, the
vendor might provide the file as part of a Windows firmware package.
Is it different on ARMs? Well, yes, but not sure if worse or even
better. The NVRAM file can usually be found on the vendor's Github.
linux-firmware.git has started collecting and distributing some of
the files. So that will be a helpful source for us. Otherwise we
will have to collect them ourselves.
For ARM there's still one commit left so that we can supply per-
board NVRAM files more easily. In essence: We're working on it!
Patrick
Re: bwfm NVRAM file
On Fri, 13 Mar 2020 13:41:48 +0100 Stefan Sperling wrote: > On Fri, Mar 13, 2020 at 12:12:18PM +0100, Rob Schmersel wrote: > > Question: Are there plans to include the NVRAM files in > > bwfm_firmware package? > > Yes, this is being worked on. See these recent commits by Patrick: > https://marc.info/?l=openbsd-cvs=158357502421524=2 > https://marc.info/?l=openbsd-cvs=158348413626641=2 > https://marc.info/?l=openbsd-cvs=158348535827039=2 > > I am not involved but it sounds like this issue could be resolved > in time for the next release. But please have patience. perfect :)
Re: bwfm NVRAM file
On Fri, Mar 13, 2020 at 12:12:18PM +0100, Rob Schmersel wrote: > Question: Are there plans to include the NVRAM files in bwfm_firmware > package? Yes, this is being worked on. See these recent commits by Patrick: https://marc.info/?l=openbsd-cvs=158357502421524=2 https://marc.info/?l=openbsd-cvs=158348413626641=2 https://marc.info/?l=openbsd-cvs=158348535827039=2 I am not involved but it sounds like this issue could be resolved in time for the next release. But please have patience.
bwfm NVRAM file
Hello,
In order to use a SDIO based bwfm device a "NVRAM" configuration file
will be needed besides the firmware file. This configuration file is
expected to be in the /etc/firmware directory, in the form of
brcmfmac{chip}-sdio.txt OR brcmfmac{chip}-sdio.nvram
The need for this configuration file is not described in the man page.
However the device will not be usable without one and an error message
will be shown in the dmesg:
"failed loadfirmware of file: brcmfmac{chip}-sdio.txt"
Can I suggest to below attached patch.
I'm a bit unsure on how to indicate where the configuration file comes from:
Under Linux it is recommended that you read the NVRAM contents from
EFI, which I don't think is possible to do under OpenBSD
Hunting down the configuration file through your favorite search engine
can be a frustrating excercise, although you can find them
occasionally included in a windows driver or a linux distro.
Question: Are there plans to include the NVRAM files in bwfm_firmware
package?
Index: share/man/man4/bwfm.4
===
RCS file: /cvs/src/share/man/man4/bwfm.4,v
retrieving revision 1.10
diff -u -p -u -r1.10 bwfm.4
--- share/man/man4/bwfm.4 10 Nov 2019 14:10:41 - 1.10
+++ share/man/man4/bwfm.4 11 Mar 2020 15:41:49 -
@@ -77,10 +77,18 @@ driver can be configured at runtime with
or on boot with
.Xr hostname.if 5 .
.Sh FILES
-The driver needs a firmware file which is loaded when the driver
-attaches.
+The
+.Nm
+driver needs a firmware file which is loaded when the
+.Nm
+driver attaches.
A prepackaged version of the firmware can be installed using
.Xr fw_update 1 .
+.Pp
+sdmmc connected devices need in addition a NVRAM configuration file,
+which is also loaded when the
+.Nm
+driver attaches.
.Sh EXAMPLES
The following example scans for available networks:
.Pp
