So it turns out that sometime in the past I removed the GPIO bits here
and was going to move it into a module in order to save a little space.
However, it turns out that was a mistake on this particular AP - it
uses a pair of GPIO lines to control the two receive LNAs on the 2GHz
radio and without them enabled the radio is a LOT DEAF.
With this re-introduced (and some replacement userland tools to save
space, *cough* cpio/libarchive) I can actually use these chipsets
again as a 2G station. Without the LNA the AP was seeing a per-radio
RSSI upstairs here of around 3-5dB, with the LNA on it's around 15dB,
more than enough to actually use wifi upstairs and also in line with
the other Atheros / Intel devices I have up here.
Big oopsie to Adrian. Big, big oopsie.
- Use a default -march of mips64 on N64 and N32 kernels.
- Set the endianness (via MIPS_ENDIAN) and ABI (via MIPS_ABI) in
CFLAGS from MACHINE_ARCH. ARCH_FLAGS now only sets a different
-march value if needed.
- TRAMP_ARCH_FLAGS inherits MIPS_ENDIAN from MACHINE_ARCH but does
not set the ABI since XLPN32 needs an N64 ABI for the trampoline
loader. When TRAMP_ARCH_FLAGS is used it must set both -march
and -mabi.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D22030
The format to use depends on hardware configuration (synthesis-time),
so make it compile-time kernel option.
Extended format allows DMA engine to operate with 64-bit memory addresses.
Sponsored by: DARPA, AFRL
tun(4) and tap(4) share the same general management interface and have a lot
in common. Bugs exist in tap(4) that have been fixed in tun(4), and
vice-versa. Let's reduce the maintenance requirements by merging them
together and using flags to differentiate between the three interface types
(tun, tap, vmnet).
This fixes a couple of tap(4)/vmnet(4) issues right out of the gate:
- tap devices may no longer be destroyed while they're open [0]
- VIMAGE issues already addressed in tun by kp
[0] emaste had removed an easy-panic-button in r240938 due to devdrn
blocking. A naive glance over this leads me to believe that this isn't quite
complete -- destroy_devl will only block while executing d_* functions, but
doesn't block the device from being destroyed while a process has it open.
The latter is the intent of the condvar in tun, so this is "fixed" (for
certain definitions of the word -- it wasn't really broken in tap, it just
wasn't quite ideal).
ifconfig(8) also grew the ability to map an interface name to a kld, so
that `ifconfig {tun,tap}0` can continue to autoload the correct module, and
`ifconfig vmnet0 create` will now autoload the correct module. This is a
low overhead addition.
(MFC commentary)
This may get MFC'd if many bugs in tun(4)/tap(4) are discovered after this,
and how critical they are. Changes after this are likely easily MFC'd
without taking this merge, but the merge will be easier.
I have no plans to do this MFC as of now.
Reviewed by: bcr (manpages), tuexen (testing, syzkaller/packetdrill)
Input also from: melifaro
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D20044
Use it wherever COMPAT_FREEBSD11 is currently specified, like r309749.
Reviewed by: imp, jhb, markj
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D20120
As discussed in that commit message, it is a dangerous default. But the
safe default causes enough pain on a variety of platforms that for now,
restore the prior default.
Some of this is self-induced pain we should/could do better about; for
example, programmatic CI systems and VM managers should introduce entropy
from the host for individual VM instances. This is considered a future work
item.
On modern x86 and Power9 systems, this may be wholly unnecessary after
D19928 lands (even in the non-ideal case where early /boot/entropy is
unavailable), because they have fast hardware random sources available early
in boot. But D19928 is not yet landed and we have a host of architectures
which do not provide fast random sources.
This change adds several tunables and diagnostic sysctls, documented
thoroughly in UPDATING and sys/dev/random/random_infra.c.
PR: 230875 (reopens)
Reported by: adrian, jhb, imp, and probably others
Reviewed by: delphij, imp (earlier version), markm (earlier version)
Discussed with: adrian
Approved by: secteam(delphij)
Relnotes: yeah
Security: related
Differential Revision: https://reviews.freebsd.org/D19944
Embedded lzma decompression library becomes a module usable by other
consumers, in addition to geom_uzip.
Most important code changes are
- removal of XZ_DEC_SINGLE define, we need the code to work
with XZ_DEC_DYNALLOC;
- xz_crc32_init() call is removed from geom_uzip, xz module handles
initialization on its own.
xz is no longer embedded into geom_uzip, instead the depend line for
the module is provided, and corresponding kernel option is added to
each MIPS kernel config file using geom_uzip.
The commit also carries unrelated cleanup by removing excess "device geom_uzip"
in places which were missed in r344479.
Reviewed by: cem, hselasky, ray, slavash (previous versions)
Sponsored by: Mellanox Technologies
Differential revision: https://reviews.freebsd.org/D19266
MFC after: 3 weeks
iflib is already a module, but it is unconditionally compiled into the
kernel. There are drivers which do not need iflib(4), and there are
situations where somebody might not want iflib in kernel because of
using the corresponding driver as module.
Reviewed by: marius
Discussed with: erj
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D19041
This is an older broadcom part that implements the mips32 ISA. 32-bit
FreeBSD/mips now requires mips32r2, so retire this config. Most of the
broadcom port is shared with newer ports, so what little code may be
unique to this part has not been GC'd at this time.
Discussed on: freebsd-mips@
Differential Revision: https://reviews.freebsd.org/D18543
This was useful in bring up. However, it causes more issues than the
support is worth (64-bit atomics being chief among them).
Discussed on: freebsd-mips@
Differential Revision: https://reviews.freebsd.org/D18543
gxemul was a nice stop-gap while qemu support for mips was firmed
up. Now MALTA* + qemu is the platform of choice retire gxemul support.
It's unknown when this was last confirmed working.
Discussed on: freebsd-mips@
Differential Revision: https://reviews.freebsd.org/D18543
relevant and is unused. It's also getting in the way of progress in
some admittedly minor ways. Better to retire it to reduce the burden
on the project.
Discussed on: freebsd-mips@
Differential Revision: https://reviews.freebsd.org/D18543
Update the BOOTSTRAPPING check for libelf to require the fix for
mips64el object files committed in r338478 and re-enable kernel
modules in the MALTA64EL config file.
Reviewed by: emaste
Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D17054
It looks like the intent was to allow ZSTD support to be
compiled into the kernel with options ZSTDIO. But it doesn't look
like that was ever implemented or I'm missing how to do it.
I did a cursory audit of kernel config files and made a decision to
enable ZSTDIO in riscv GENERIC and mips MALTA configurations. All other
kernel configurations already had this option in their kernel configs
but they didn't do anything useful as the feature was declared as
"standard" prior to this.
Reviewed by: cem allanjude
Differential Revision: https://reviews.freebsd.org/D16007
xdma(4) interface.
This allows us to switch between Altera mSGDMA or SoftDMA engines used by
atse(4) device.
This also makes atse(4) driver become 25% smaller.
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D9618
The old way required the data to be present really early and copied it from
memory mapped NOR flash; this only worked during kernel boot but not for
ath/ath_hal modules.
Tested:
* AR9331, Carambola2, ath/hal modules.
is now unobtanium. It's only had API changes in the last 7 years, and
is responsible for a very large number of them. In addition, there's a
lot of code that reimplements base FreeBSD functionality, diminishing
the chances it still works. Without hardware to teset it on, or
prospects of obtaining such hardware and without vendor support, it's
time to move on.
Suggested by: kan@ in mips@ retirement discussion
it's at least 5 years out of production. I couldn't find a used one on
ebay and other secondary markets just now, nor when I tried 4 years
ago. It dates from the initial project/mips2 merge 8 years ago, and
hasn't been updated since.
Discussed on: mips@ (with some dissent)
It came into the tree with the project/mips merge 8 years ago. At the
time, it was hard to find a board with enough RAM to run. Now FreeBSD
requires at least 2x the RAM it did then. No changes have happened to
this port apart from API churn and license tagging since then. It ran
OK at the time it was committed, but no sightings in the wild have
happened since shortly after it was committed.
https://www.linux-mips.org/wiki/Adm5120_devices lists a bunch of
boards that were available 5 years ago (but are no longer
available). The beefiest one had only 64MB of RAM which is too
small. The Mirktik RB1xx never had more than 32MB.
Also remove confusing QEMU config file that never ever worked in QEMU
for mips. MALTA is used for that. Another of my past mistakes, false
starts that never amounted to anything.
Discussed on: mips@ (with some dissent)
never got better. It never worked on real hardware and is still mostly
stubs after 8 years when I added it. It has had no real update in that
time apart from API churn. It was added just so it didn't get lost in
the project/mips merge, but maybe it should have been lost as nothing
has come of it. It is time to give up the ghost on this one.
Approved by: me, shooting my own dog
Discussed on: mips@
This compilation issue has been found thanks to freebsd-wifi-build:
- gpioiic requires "gpio_if.h", so "device gpio" is mandatory
- rtl8366rb works over MDIO interface, so "device mdio" is mandatory
Compilation is checked on FreeBSD 12-CURRENT machine.
The driver is functional on both BHND Wi-Fi adapters and MIPS SoCs, but
does not currently include support for features not required by bwn(4),
including GPIO interrupt handling.
Approved by: adrian (mentor, implicit)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D12708
