Re: experience setting up a low memory machine
On 2020-03-13 18:31, Stuart Henderson wrote: On 2020-03-13, Jordan Geoghegan wrote: I wouldn't get too excited about running on low memory machines. The more RAM you can throw at something, the better, as this allows more cache room as well as improving function of ASLR and other memory randomizations. It does allow more cache, but what matters for ASLR is address space, not RAM. Ah okay, you're right. I was remembering reading something about low memory conditions weakening ASLR, but after doing a quick check, it seems it was an implementation specific issue with Windows and Linux.
Re: riscv
On 2020-03-13, Jordan Geoghegan wrote: > > > On 2020-03-13 09:50, Christian Weisgerber wrote: >> On 2020-03-13, "Peter J. Philipp" wrote: >> >>> Any developer working on a riscv port and willing to share their unofficial >>> work for possible future collaboration? >> I think I'd have heard by now if somebody was, so I'll go out on a >> limb and say no, nobody's working on a RISC-V port. >> > > I stumbled across this a while back, this guy at least claims to be > attempting a port to RISC-V... > > https://github.com/MengshiLi/openbsd-riscv-notes > > recent state: https://pastebin.com/QqLPs1GB
Re: experience setting up a low memory machine
On 2020-03-13, Jordan Geoghegan wrote: > I wouldn't get too excited about running on low memory machines. The > more RAM you can throw at something, the better, as this allows more > cache room as well as improving function of ASLR and other memory > randomizations. It does allow more cache, but what matters for ASLR is address space, not RAM.
Re: Confusing problem with CVS
Hi Chris, Chris Bennett wrote on Fri, Mar 13, 2020 at 08:23:22PM -0400: > Thanks, that was helpful. > I did not think of using info cvs. I do use info at times, > just not that often. That is quite understandable. With BSD systems in general, it is both the normal case and also our goal that the man(1) pages should contain the authoritative, complete, correct, concise documentation. But the further you move away from OpenBSD to other operating systems or into ports land, the more documentation gets scattered across various non-compatible file formats. But even in OpenBSD base, there are a few legacy components still in active use where we don't really continue development and where the authoritative documentation is not in manual page format, for example: - GNU as(1) - GNU cvs(1) - gdb(1) - GNU info(1) itself - and a few others With LLVM and related tools replacing GCC and GNU binutils on many platforms, the amount and the importance of info(1) documents is slowly continuing to decline. Yours, Ingo
Re: Confusing problem with CVS
Thanks, that was helpful. I did not think of using info cvs. I do use info at times, just not that often. I'm just using CVS for porting. Since -current offers a tar file and I've made a partition for /usr/ports and another for /usr/ports/mystuff, so I'm just using that file to replace ports without changing my WIP. I ran into a rather good C book that runs along with my way of thinking, so I wanted to follow -current src for learning. I'll just checkout src again unless I start working on a diff to submit in the future. For other things, I'm using backups plus git because I can pass along changes to other boxes so easily. I didn't think it was a bug, just something I wasn't understanding. I appreciate the help. Thanks, Chris Bennett
Re: Confusing problem with CVS
Hi Chris, Chris Bennett wrote on Fri, Mar 13, 2020 at 04:47:09PM -0400: > I am running -current. > > On one server, src was empty. So I did a cvs checkout. > On another server, src had older files. So I did a cvs up. > > Afterwards, inttypes.h had one size on the checkout, another size on the > updated src. > I rm'ed the updated src and did a checkout. Now both files are the same > size and date. > > What has happened here? I thought that cvs up was the correct procedure. > > cvs -qd$CVSROOT checkout -P src inside of /usr or > cvs -qd$CVSROOT up -Pd inside of /usr/src. > > Updating only changed some of the file dates That sounds as if you had sticky tags at least in parts of one of the trees, but you provide no details, so there is no way to be sure what exactly happened. > and did not work correctly. You provide no evidence whatsoever that there might be a bug, and my guess is that it is unlikely you encountered one. It is among the basic ideas of CVS that running "cvs up" across a whole tree doesn't necessarily update all the subdirectories from the same server, nor from the same repository, nor to the same branch. In addition, "cvs up" commands you ran in the past may have banned some files from being updated at all in the future. In case it isn't obvious, cvs(1) is very different from git(1) in these respects. With CVS, you can configure individual subdirectories and even individual files to behave in custom ways, which git(1) is incapable of. It all depends on what the files in the various directories with the name "CVS" contained, for example the various files called "Root", "Repository", "Entries", and "Tag". Because there are so many different scenarios in which what you describe is the expected behaviour, i can't provide better advice than this: use the command "info cvs" to learn how cvs(1) is supposed to work. In particular, make sure you become familiar with the -A, -C, and -r options of "cvs up", but i'm not saying that will be sufficient to avoid all possible surprises. Also use "/sticky" inside "info cvs" to look for information about sticky tags; it is mentioned at many different places. Yours, Ingo
Re: experience setting up a low memory machine
On 2020-03-11 19:20, Aaron Mason wrote: On Wed, Mar 11, 2020 at 6:47 PM Jordan Geoghegan wrote: On 2020-03-11 00:13, Stuart Longland wrote: On 15/2/20 6:43 pm, Dumitru Moldovan wrote: [SNIP] [SNIP] Sometimes it's better to realise when something has past its prime. A year or two ago I had OpenBSD working on my iBook with 64MB of RAM, even got FVWM working on it. For fun and testing purposes, I ran some small OpenBSD virtual machines with 64MB RAM as well. A few years back I got OpenBSD to boot with 32MB, but it wasn't particularly usable. I've found 128MB to be usable for basic terminal work, but you're definitely correct about 256MB being the bare minimum for anything fancy or GUI related. At work I run OpenBSD 6.1 in a VM for Request Tracker. It has 512MB RAM and it seems that may very well be overkill. At previous jobs I can ManageEngine ServiceDesk Plus and even in Linux you needed 2GB minimum just for it to get out of bed. I plan on rebuilding it with 6.6 (can't update RT because packages are too old in 6.1) and might run it on 256MB for shits and giggles. I wouldn't get too excited about running on low memory machines. The more RAM you can throw at something, the better, as this allows more cache room as well as improving function of ASLR and other memory randomizations.
Re: riscv
On 2020-03-13 09:50, Christian Weisgerber wrote: On 2020-03-13, "Peter J. Philipp" wrote: Any developer working on a riscv port and willing to share their unofficial work for possible future collaboration? I think I'd have heard by now if somebody was, so I'll go out on a limb and say no, nobody's working on a RISC-V port. I stumbled across this a while back, this guy at least claims to be attempting a port to RISC-V... https://github.com/MengshiLi/openbsd-riscv-notes
Confusing problem with CVS
I am running -current. On one server, src was empty. So I did a cvs checkout. On another server, src had older files. So I did a cvs up. Afterwards, inttypes.h had one size on the checkout, another size on the updated src. I rm'ed the updated src and did a checkout. Now both files are the same size and date. What has happened here? I thought that cvs up was the correct procedure. cvs -qd$CVSROOT checkout -P src inside of /usr or cvs -qd$CVSROOT up -Pd inside of /usr/src. Updating only changed some of the file dates and did not work correctly. Thanks, Chris Bennett
TUXEDO InfinityBook Pro 14 v5 -- touchpad not detected (synaptics)
Hi misc@, I have recently tested OpenBSD 6.6-current (11.03.2020) on the TUXEDO InfinityBook Pro 14 v5 laptop. While the synaptics touchpad is not detected on OpenBSD, it works fine on Linux -- please find below the corresponding dmesg lines: [ 14.485208] psmouse serio2: synaptics: queried max coordinates: x [..5718], y [..4908] [ 14.605439] psmouse serio2: synaptics: queried min coordinates: x [1238..], y [956..] [ 14.605446] psmouse serio2: synaptics: Your touchpad (PNP: SYN1221 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-in...@vger.kernel.org. [ 14.763961] psmouse serio2: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2b1, caps: 0xf00223/0x840300/0x26800/0x0, board id: 3175, fw id: 2330500 [ 14.806975] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio2/input/input24 I wonder whether anyone has succeeded in getting this device to work properly on OpenBSD? I would be happy to provide some test results if necessary. Please find the complete dmesg output attached at the end of this e-mail. Best wishes, Andrzej OpenBSD 6.6-current (GENERIC.MP) #48: Wed Mar 11 18:18:46 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34018422784 (32442MB) avail mem = 32974831616 (31447MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xe67a0 (43 entries) bios0: vendor INSYDE Corp. version "1.07.04RTR1" date 10/02/2019 bios0: TUXEDO TUXEDO acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT WSMT SSDT DBGP DBG2 SSDT NHLT HPET APIC MCFG SSDT SSDT DMAR FPDT acpi0: wakeup devices XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz, 1583.07 MHz, 06-8e-0c cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz, 1595.87 MHz, 06-8e-0c cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz, 1528.30 MHz, 06-8e-0c cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz, 1496.52 MHz, 06-8e-0c cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version
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: riscv
On 2020-03-13, "Peter J. Philipp" wrote: > Any developer working on a riscv port and willing to share their unofficial > work for possible future collaboration? I think I'd have heard by now if somebody was, so I'll go out on a limb and say no, nobody's working on a RISC-V port. -- Christian "naddy" Weisgerber na...@mips.inka.de
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
Re: trunk(4) driver with optional interface?
Le 13/03/2020 à 13:23, Raf Czlonka a écrit :> Hi David, hotplugd(8) might help here. Thanks, I've heard of it in the past. Can't understand how I did forget it. That will help me a lot! Regards, -- David
Re: trunk(4) driver with optional interface?
On Fri, Mar 13, 2020 at 12:13:45PM GMT, David Demelier wrote: > Hello, > > I'm using trunk(4) pseudo device to aggregate my wireless iwm(4) and my > dock ethernet interface ure(4) together. > > Since my laptop is not always connected to my dock, when booting I get a > trunk error if the interface is not available: > > ifconfig: SIOCTRUNKPORT: Invalid argument > > Hopefully, this is not a big deal as my iwm(4) is still available and > used nevertheless. > > Do you have any other recommandations or advises in my case? Because if > I plug my laptop into the dock after the creation of the trunk interface > I must use ifconfig by hand to attach it. If there is a way to detect > the attachment of a new interface, I could create an automatic script > too. Hi David, hotplugd(8) might help here. Regards, Raf > Content of my /etc/hostname.trunk0, /etc/hostname.iwm0 and > /etc/hostname.ure0: > > # /etc/hostname.trunk0 > trunkproto failover trunkport ure0 > trunkport iwm0 > dhcp > > # /etc/hostname.iwm0 > join myssid wpakey p > up > > # /etc/hostname.ure0 > up > > I'm using OpenBSD-current at the moment. > > Regards, > > -- > David >
trunk(4) driver with optional interface?
Hello, I'm using trunk(4) pseudo device to aggregate my wireless iwm(4) and my dock ethernet interface ure(4) together. Since my laptop is not always connected to my dock, when booting I get a trunk error if the interface is not available: ifconfig: SIOCTRUNKPORT: Invalid argument Hopefully, this is not a big deal as my iwm(4) is still available and used nevertheless. Do you have any other recommandations or advises in my case? Because if I plug my laptop into the dock after the creation of the trunk interface I must use ifconfig by hand to attach it. If there is a way to detect the attachment of a new interface, I could create an automatic script too. Content of my /etc/hostname.trunk0, /etc/hostname.iwm0 and /etc/hostname.ure0: # /etc/hostname.trunk0 trunkproto failover trunkport ure0 trunkport iwm0 dhcp # /etc/hostname.iwm0 join myssid wpakey p up # /etc/hostname.ure0 up I'm using OpenBSD-current at the moment. Regards, -- David
riscv
Any developer working on a riscv port and willing to share their unofficial work for possible future collaboration? Best Regards, -peter
Re: upgrade i386 kernel to amd64
Depends on your app, if your software is working fine on it since years then just leave it as is. You don't want multiarch systems it is even a mess in linux. A system like that should not be upgraded but migrated, you setup a clean install with the latest 64bit Obsd on another machine then move things over and adapt the configs. ‐‐‐ Original Message ‐‐‐ On Tuesday, March 3, 2020 12:14 AM, Justin Muir wrote: > Hello all, > > Running GENERIC i386 kernel on on a 64-bit amd machine. Just wondering > whether an upgrade amd64 is warranted. Any opinions? > > If so, just upgrade system? Re-compile kernel? Other options? > > tia! > > J
