with no creative content. Include "lost" changes from git:
o Use /dev/efi instead of /dev/efidev
o Remove redundant NULL checks.
Submitted by: kib@, dim@, zbb@, emaste@
As of r302092, pipe is a wrapper around pipe2 and the pipe syscall is no
longer used. It is included only with the COMPAT_FREEBSD10 kernel option.
Add the compat option to support upgrades from systems with an earlier
userland.
MFC after: 1 week
Keep resource state consistent with INTRNG state - if intr_activate_irq
fails - deactivate resource and propagate error to calling function
Reviewed by: mmel
to add actions that run when a TCP frame is sent or received on a TCP
session in the ESTABLISHED state. In the base tree, this functionality is
only used for the h_ertt module, which is used by the cc_cdg, cc_chd, cc_hd,
and cc_vegas congestion control modules.
Presently, we incur overhead to check for hooks each time a TCP frame is
sent or received on an ESTABLISHED TCP session.
This change adds a new compile-time option (TCP_HHOOK) to determine whether
to include the hhook(9) framework for TCP. To retain backwards
compatibility, I added the TCP_HHOOK option to every configuration file that
already defined "options INET". (Therefore, this patch introduces no
functional change. In order to see a functional difference, you need to
compile a custom kernel without the TCP_HHOOK option.) This change will
allow users to easily exclude this functionality from their kernel, should
they wish to do so.
Note that any users who use a custom kernel configuration and use one of the
congestion control modules listed above will need to add the TCP_HHOOK
option to their kernel configuration.
Reviewed by: rrs, lstewart, hiren (previous version), sjg (makefiles only)
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D8185
These are older MIPS4kc parts from Atheros. They typically ran at
sub-200MHz and have 11bg, 11a, or 11abg wifi MAC/PHYs integrated.
This port is the initial non-wifi pieces required to bring up the
chip. I'll commit the redboot and other pieces later, and then
hopefully(!) wifi support will follow.
Submitted by: Mori Hiroki <yamori813@yahoo.co.jp>
Differential Revision: https://reviews.freebsd.org/D7237
drivers.
The BMIPS32/BMIPS3300 cores use a register layout distinct from the MIPS74K
core, and are only found on siba(4) devices.
Reviewed by: mizhka
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7791
Move to a per-proc TLS offset rather than incorrectly keying off the
presense of freebsd32 compability in the kernel.
Reviewed by: adrian, sbruno
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D7843
This will be required for SMP support on MIPS Malta platform.
Reviewed by: adrian
Sponsored by: DARPA, AFRL
Sponsored by: HEIF5
Differential Revision: https://reviews.freebsd.org/D7835
More changes to MIPS may be required, as commented in D7692, but this
revision aims to restore MIPS INTRNG functionality so we can move on
with working interrupts.
Reported by: yamori813@yahoo.co.jp
Tested by: mizhka (on BCM), sgalabov (on Mediatek)
Reviewed by: adrian, nwhitehorn (older version)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D7692
This patch adds driver implementation for BHND USB core. Driver has been
imported from ZRouter project with small adaptions for FreeBSD 11.
Also it's enabled for BroadCom MIPS74k boards by default. It's fully tested
on Asus boards (RT-N16: external USB, RT-N53: USB bus between SoC and WiFi
chips).
Reviewed by: adrian (mentor), ray
Approved by: adrian (mentor)
Obtained from: ZRouter
Differential Revision: https://reviews.freebsd.org/D7781
Adds support for probing and initializing bhndb(4) bridge state using
the bhnd_erom API, ensuring that full bridge configuration is available
*prior* to actually attaching and enumerating the bhnd(4) child device,
allowing us to safely allocate bus-level agent/device resources during
bhnd(4) bus enumeration.
- Add a bhnd_erom_probe() method usable by bhndb(4). This is an analogue
to the existing bhnd_erom_probe_static() method, and allows the bhndb
bridge to discover the best available erom parser class prior to newbus
probing of its children.
- Add support for supplying identification hints when probing erom
devices. This is required on early EXTIF-only chipsets, where chip
identification registers are not available.
- Migrate bhndb over to the new bhnd_erom API, using bhnd_core_info
records rather than bridged bhnd(4) device_t references to determine
the bridged chipsets' capability/bridge configuration.
- The bhndb parent (e.g. if_bwn) is now required to supply a hardware
priority table to the bridge. The default table is currently sufficient
for our supported devices.
- Drop the two-pass attach approach we used for compatibility with bhndb(4) in
the bhnd(4) bus drivers, and instead perform bus enumeration immediately,
and allocate bridged per-child bus-level resources during that enumeration.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7768
This defines a new bhnd_erom_if API, providing a common interface to device
enumeration on siba(4) and bcma(4) devices, for use both in the bhndb bridge
and SoC early boot contexts, and migrates mips/broadcom over to the new API.
This also replaces the previous adhoc device enumeration support implemented
for mips/broadcom.
Migration of bhndb to the new API will be implemented in a follow-up commit.
- Defined new bhnd_erom_if interface for bhnd(4) device enumeration, along
with bcma(4) and siba(4)-specific implementations.
- Fixed a minor bug in bhndb that logged an error when we attempted to map the
full siba(4) bus space (18000000-17FFFFFF) in the siba EROM parser.
- Reverted use of the resource's start address as the ChipCommon enum_addr in
bhnd_read_chipid(). When called from bhndb, this address is found within the
host address space, resulting in an invalid bridged enum_addr.
- Added support for falling back on standard bus_activate_resource() in
bhnd_bus_generic_activate_resource(), enabling allocation of the bhnd_erom's
bhnd_resource directly from a nexus-attached bhnd(4) device.
- Removed BHND_BUS_GET_CORE_TABLE(); it has been replaced by the erom API.
- Added support for statically initializing bhnd_erom instances, for use prior
to malloc availability. The statically allocated buffer size is verified both
at runtime, and via a compile-time assertion (see BHND_EROM_STATIC_BYTES).
- bhnd_erom classes are registered within a module via a linker set, allowing
mips/broadcom to probe available EROM parser instances without creating a
strong reference to bcma/siba-specific symbols.
- Migrated mips/broadcom to bhnd_erom_if, replacing the previous MIPS-specific
device enumeration implementation.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7748
Idle page zeroing has been disabled by default on all architectures since
r170816 and has some bugs that make it seemingly unusable. Specifically,
the idle-priority pagezero thread exacerbates contention for the free page
lock, and yields the CPU without releasing it in non-preemptive kernels. The
pagezero thread also does not behave correctly when superpage reservations
are enabled: its target is a function of v_free_count, which includes
reserved-but-free pages, but it is only able to zero pages belonging to the
physical memory allocator.
Reviewed by: alc, imp, kib
Differential Revision: https://reviews.freebsd.org/D7714
handling.
- Extended PWRCTL/PMU APIs to support querying clock frequency during very
early boot, prior to bus attach.
- Implement generic PMU-based calculation of UART rclk values.
- Replaced use of static frequency tables (bcm_socinfo) with
runtime-determined values.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7552
- Added bhnd_pmu driver implementations for PMU and PWRCTL chipsets,
derived from Broadcom's ISC-licensed HND code.
- Added bhnd bus-level support for routing per-core clock and resource
power requests to the PMU device.
- Lift ChipCommon support out into the bhnd module, dropping
bhnd_chipc.
Reviewed by: mizhka
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7492
This adds support for performing platform_reset() on all supported
devices, using early boot enumeration of chipc capabilities and
available cores.
- Added Broadcom-specific MIPS CP0 register definitions used by
BCM4785-specific reset handling.
- Added a bcm_platform structure for tracking chipc/pmu/cfe platform
data.
- Extended the BCMA EROM API to support early boot lookup of core info
(including port/region mappings).
- Extended platform_reset() to support PMU, PMU+AOB, and non-PMU
devices.
Reviewed by: mizhka
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7539
This was .. an interesting headache.
There are two halves:
* The earlier IRIX stuff (yes, early) occasionally would do dead
code removal and generate multiple consecutive LO16 entries.
If this is done for REL entries then it's fine - there's no
state kept between them. But gcc 5.x seems to do this for
RELA entries.
eg:
HI1 LO1 HI2 LO2 LO3 HI4 LO4
.. in this instance, LO2 should affect HI2, but LO3 doesn't at all
affect anything. The matching HI3 was in code that was deleted
as "dead code".
Then, the next one:
* A "GCC extension" allows for multiple HI entries before a LO entry;
and all of those HI entries use the first LO entry as their basis
for RELA offset calculations.
It does this so GCC can also do dead code deletion without necessarily
having to geneate fake relocation entries for balanced HI/LO RELA
entries.
eg:
HI1 LO1 HI2 HI3 HI4 LO4 LO5 HI6 LO6 LO7
in this instance, HI{2,3,4} are the same relocation as LO4 (eg .bss)
and need to be buffered until LO4 - then the RELA offset is applied
from LO4 to HI{2,3,4} calculations.
/And/, the AHL from HI4 is used during the LO4 relocation calculation,
just like in the normal (ie, before this commit) implementation.
Then, LO5 doesn't trigger anything - the HI "buffer" is empty,
so there are no HI relocations to flush out.
HI6/LO6 are normal, and LO7 doesn't trigger any HI updates.
Tested:
* AR9344 SoC, kernel modules, using gcc-5.3 (mips-gcc-5.3.0 package)
Notes:
* Yes, I do feel dirty having written this code.
Reviewed by: imp (after a handful of "this should be on fire" moments wrt gcc and this code)
- Read interrupt properties at bus enumeration time and store
it into global mapping table.
- At bus_activate_resource() time, given mapping entry is resolved and
connected to real interrupt source. A copy of mapping entry is attached
to given resource.
- At bus_setup_intr() time, mapping entry stored in resource is used
for delivery of requested interrupt configuration.
- For MSI/MSIX interrupts, mapping entry is created within
pci_alloc_msi()/pci_alloc_msix() call.
- For legacy PCI interrupts, mapping entry must be created within
pcib_route_interrupt() by pcib driver itself.
Reviewed by: nwhitehorn, andrew
Differential Revision: https://reviews.freebsd.org/D7493
This adds support for EARLY_PRINTF via the CFE console; the aim is to
provide a fix for the otherwise cyclic dependency between PMU discovery
and console printf/DELAY:
- We need to parse the bhnd(4) core table to determine the address (and
type) of the PMU/PLL registers and calculate the CPU clock frequency.
- The core table parsing code will emit a printf() if a parse error is
hit.
- Safely calling printf() without EARLY_PRINTF requires a working
DELAY+cninit, which means we need the PMU.
Errors in core table parsing shouldn't happen, but lack of EARLY_PRINTF
makes debugging more difficult.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7498
- Added a generic bhnd_nvram_parser API, with support for the TLV format
used on WGT634U devices, the standard BCM NVRAM format used on most
modern devices, and the "board text file" format used on some hardware
to supply external NVRAM data at runtime (e.g. via an EFI variable).
- Extended the bhnd_bus_if and bhnd_nvram_if interfaces to support both
string-based and primitive data type variable access, required for
common behavior across both SPROM and NVRAM data sources.
- Extended the existing SPROM implementation to support the new
string-based NVRAM APIs.
- Added an abstract bhnd_nvram driver, implementing the bhnd_nvram_if
atop the bhnd_nvram_parser API.
- Added a CFE-based bhnd_nvram driver to provide read-only access to
NVRAM data on MIPS SoCs, pending implementation of a flash-aware
bhnd_nvram driver.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7489
Several files use the internal name of `struct device` instead of
`device_t` which is part of the public API. This patch changes all
`struct device *` to `device_t`.
The remaining occurrences of `struct device` are those referring to the
Linux or OpenBSD version of the structure, or the code is not built on
FreeBSD and it's unclear what to do.
Submitted by: Matthew Macy <mmacy@nextbsd.org> (previous version)
Approved by: emaste, jhibbits, sbruno
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D7447
This work, originally from Stacey Son, uses the MIPS UserReg for
reading the TLS data, and will fall back to the normal syscall path
when it isn't supported.
This code dynamically patches cpu_switch() to bypass the UserReg
instruction so to avoid generating a machine exception.
Thanks to sson for the original work, and to Dan Nelson for
bringing it to date and testing it on MIPS32 with me.
Tested:
* mips64 (sson)
* mips74k (dnelson_1901@yahoo.com) - AR9344 SoC, UserReg support
* mips24k (adrian) - AR9331 SoC, no UserReg support
Obtained from: sson, dnelson_1901@yahoo.com
* add an ANY debug level which will always echo the message if debugging
is compiled in;
* log MDIO transaction timeouts if debugging is compiled in;
* the argemdio device is different to arge, so turning on MDIO debugging
flags in arge->sc_debug doesn't help. Add a debug sysctl to argemdio
as well so that MDIO transactions can be debugged.
Tested:
* AR9331
Relying on the boot loader console configuration allows us to use a
common set of device hints for all SENTRY5 devices.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D7376
For reasons I won't comment on, the AR934x and QCA953x GPIO_OE register
value is inverted - bit set == input, bit clear == output.
So, fix this in the output setting, in reading the initial state from
the boot loader, and also setting any gpiofunc pins that are necessary.
- Cast 32-bit register values to uintmax_t for use with %jx.
- Add special-case return address handling for MipsKernGenException to
avoid early termination of stack walking in the exception handler
stack frame.
Submitted by: Michael Zhilin <mizhka@gmail.com>
Reviewed by: ray
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6907
Recource management functions in GT PCI controller driver
treated memory/IO resources as KSEG1 addresses, later during
activation these values would be increased by KSEG1 base again
rendering the address invalid and causing "bus error" trap.
Actual logic was converted to use real physical addresses,
so mapping takes place only during activation.
Submitted by: Aleksandr Rybalko <ray@FreeBSD.org>
Approved by: re (gjb)
The delta between SENTRY5 and BCM was already small due to BCM being
derived from SENTRY5; re-integrating the two avoids the maintenance
overhead of keeping them both in sync with bhnd(4) changes.
- Re-integrate minor SENTRY5 deltas in bcm_machdep.c
- Modify uart_cpu_chipc to allow specifying UART debug/console flags via
kenv and device hints.
- Switch SENTRY5 to std.broadcom
- Enabled CFI flash support for SENTRY5
Reviewed by: Michael Zhilin <mizkha@gmail.com> (Broadcom MIPS support)
Approved by: re (gjb), adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6897
Replaces use of DEVICE_IDENTIFY with explicit enumeration of chipc
child devices using the chipc capability structure.
This is a precursor to PMU support, which requires more complex resource
assignment handling than achievable with the static device name-based
hints table.
Reviewed by: Michael Zhilin <mizkha@gmail.com> (Broadcom MIPS support)
Approved by: re (gjb), adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6896
threads, to make it less confusing and using modern kernel terms.
Rename the functions to reflect current use of the functions, instead
of the historic KSE conventions:
cpu_set_fork_handler -> cpu_fork_kthread_handler (for kthreads)
cpu_set_upcall -> cpu_copy_thread (for forks)
cpu_set_upcall_kse -> cpu_set_upcall (for new threads creation)
Reviewed by: jhb (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Approved by: re (hrs)
Differential revision: https://reviews.freebsd.org/D6731
Changes:
- Fixed incorrect MIPS74k vendor ID in the bhnd core descriptor tables
- Fixed MIPS core driver's matching against MIPS/MIPS33 cores.
- Improved MIPS3302 core description.
- Enabled BUS_PASS_BUS on the bhnd nexus drivers to allow early probing
of the MIPS core.
- Enabled BUS_PASS_CPU on the MIPS core driver to ensure correct attach
order.
- Disabled matching of the MIPS core driver on non-SoC devices.
Reviewed by: Michael Zhilin <mizhka@gmail.com>
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6735
p_sched is unused.
The struct td_sched is always co-allocated with the struct thread,
except for the thread0. Avoid useless indirection, instead calculate
td_sched location using simple pointer arithmetic in td_get_sched(9).
For thread0, which is statically allocated, create a structure to
emulate layout of the dynamic allocation.
Reviewed by: jhb (previous version)
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D6711
Now that bhnd(4) provides feature parity with the previous siba/mips
implementation, we can switch sentry5 over and begin lifting common
support code out for use across bhnd(4) embedded targets.
Changes:
- Fixed enumeration of siba(4) per-core address maps, required for
discovery of memory mapped chipc flash region on siba(4) devices.
- Simplified bhnd kernel configuration (dropped 'bhndbus' option).
- Replaced files.broadcom's direct file references with their
corresponding standard kernel options.
- Lifted out common bcma/siba nexus support, inheriting from the new
generic bhnd_nexus driver.
- Dropped now-unused sentry5 siba code.
- Re-integrated BCM into the universe build now that it actually compiles.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6712
This adds support for serial (via SPI) and parallel (via CFI) flash
as found on BCM47xx/BCM53xx SoCs.
Submitted by: Michael Zhilin <mizhka@gmail.com>
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D6250
Etherswitch support is built by default on all SoCs except RT3662/RT3883
as they have no built-in switch and their configurations with external
switches are not yet supported.
Sponsored by: Smartcom - Bulgaria AD
Add more 'compatible' strings found in various LEDE DTS files.
Reviewed by: adrian
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6432
needed in later changes where we may not be able to lock the pic list lock
to perform a lookup, e.g. from within interrupt context.
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
PCIe PHY needs different initialization on MT7628/MT7688 SoCs than it does
on MT7620.
However, LEDE (and OpenWRT) dts files have the PCIe node for MT7628/MT7688
as compatible with mt7620-pci.
We already can handle this properly in our driver, so we just need to add
compat strings to fbsd-mt7628an.dtsi and the PCIe driver.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6395
Relies on BHND(4) driver.
There files contains machine-dependent code for Broadcom MIPS processor and
provide UART driver.
This is a work in progress; it and the current bhnd code is enough to boot
on the ASUS RT-N16 and RT-N53 platforms.
Submitted by: Michael Zhilin <mizhka@gmail.com>
Differential Revision: https://reviews.freebsd.org/D6251
interface with 5 methods to mirror the 5 MSI/MSI-X methods in the pcib
interface. The pcib driver will need to perform a device specific lookup
to find the MSI controller and pass this to intrng as the xref. Intrng
will finally find the controller and have it handle the requested operation.
Obtained from: ABT Systems Ltd
MFH: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D5985
legacy siba sentry5 cpu glue.
The siba_cc code is the hard-coded chipcommon bits for the sentry s5,
which will eventually be replaced with the more flexible bhnd sipa/cc
code.
bwn, etc uses siba_bwn, which doesn't use siba or siba_cc to do anything.
Allow output pins to be read and input pins to be set.
Fix bugs where we were trying to access the gpio softc before doing
device_get_softc.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6222
struct associated with some type defined in enum intr_map_data_type
must have struct intr_map_data on the top of its own definition now.
When such structs are used, correct type and size must be filled in.
There are three such structs defined in sys/intr.h now. Their
definitions should be moved to corresponding headers by follow-up
commits.
While this change was propagated to all INTRNG like PICs,
pic_map_intr() method implementations were corrected on some places.
For this specific method, it's ensured by a caller that the 'data'
argument passed to this method is never NULL. Also, the return error
values were standardized there.
64-bit MIPS, use superpage rather than physical-segment constants, or
we may improperly fail to apply suitable alignment -- yet still allow
mmap() to appear to succeed.
Reviewed by: sson
MFC after: 1 week
Sponsored by: DARPA, AFRL
Rescanning a PCI bus uses the following steps:
- Fetch the current set of child devices and save it in the 'devlist'
array.
- Allocate a parallel array 'unchanged' initalized with NULL pointers.
- Scan the bus checking each slot (and each function on slots with a
multifunction device).
- If a valid function is found, look for a matching device in the 'devlist'
array. If a device is found, save the pointer in the 'unchanged' array.
If a device is not found, add a new device.
- After the scan has finished, walk the 'devlist' array deleting any
devices that do not have a matching pointer in the 'unchanged' array.
- Finally, fetch an updated set of child devices and explicitly attach any
devices that are not present in the 'unchanged' array.
This builds on the previous changes to move subclass data management into
pci_alloc_devinfo(), pci_child_added(), and bus_child_deleted().
Subclasses of the PCI bus use custom rescan logic explicitly override the
rescan method to disable rescans.
Differential Revision: https://reviews.freebsd.org/D6018
The purpose of this file was to simply detect the UART speed before
attaching the actual ns8250 driver so that we don't have to specify the
UART speed in DTS files.
However, OpenWRT DTS files specify ns16550a as a compatible string in
their DTS files and this makes the original ns8250 driver attach to
the device. So we would have to edit the DTS files anyway and since this
is only the case for MT7621 and MT7628/MT7688 for now, it's better to
just add the clock-frequency property to those (UART is always clocked
by the same clock in both these SoCs, so that's fine) instead of having
a separate driver and still having to change the DTS files.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6044
This allows us to come closer to OpenWRT vanilla DTS files.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6045
This allows us to get closer to OpenWRT DTS files and minimize the diffs
a little more.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6042
rounddown2 tends to produce longer lines than the original code
and when the code has a high indentation level it was not really
advantageous to do the replacement.
This tries to strike a balance between readability using the macros
and flexibility of having the expressions, so not everything is
converted.
Only compile what each SoC needs and get rid of MEDIATEK generic config.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5996
This revision makes the mtk_gpio_v1 driver read its register map property
from the OpenWRT dts files.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6029
The driver can read and parse the OpenWRT pinctrl dts entries.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5999
OpenWRT's dts files treat RT3050/RT3052/RT3350 within the same SoC dtsi
file, so we need to distinguish between the three dynamically, mainly
because the bit we use to determine the clock speed on RT3050/RT3052
can actually be floating on RT3350 and RT3350 is always at 320MHz.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5983
Add suppport for passing boot arguments via FDT for mediatek/ralink SoCs.
This was taken from kan's work on CI20.
Since most OpenWRT dts files have bootargs defined, we use bsdbootargs
to specify FreeBSD specific arguments.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5979
Revision 298068 changed MIPS_INTRNG and ARM_INTRNG to simply INTRNG.
MEDIATEK_BASE config was missed by this revision, so we change
MIPS_INTRNG to INTRNG here.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5978
This revision gets our Mediatek/Ralink drivers closer to OpenWRT's dts
definitions, so we can reuse them with less modifications later in order
to bring support for a lot of boards at once.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5961
This is actually initialized properly within xhci.c, so it's better to
not initialize it in mtk_xhci.c
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5935
the following:
1. Give the appropriate board dts file to be used by either:
1.1. edit the SoC kernel config required (e.g., MT7620A_FDT) and include
the required FDT_DTS_FILE makeoption; or
1.2. simply supply FDT_DTS_FILE="xx.dts" on the command line when building
the kernel
Of course, the user can also create a completely new kernel config to
match the desired board and include the SoC kernel config from within
it.
If required, edit the MEDIATEK config file, which includes optional
drivers and comment out the unneeded ones.
2.1. this would only make sense if kernel size is a concern. Even if we
build the kernel with all drivers, if we lzma it and package it as a uImage,
its size is still around 1.1MiB.
The user will have to choose a dts file (or create a new one) from
sys/gnu/dts/mips , where all Mediatek/Ralink dts files will be imported via
a later revision.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5966
The ACPI and OFW PCI bus drivers as well as CardBus override this to
allocate the larger ivars to hold additional info beyond the stock PCI ivars.
This removes the need to pass the size to functions like pci_add_iov_child()
and pci_read_device() simplifying IOV and bus rescanning implementations.
As a result of this and earlier changes, the ACPI PCI bus driver no longer
needs its own device_attach and pci_create_iov_child methods but can use
the methods in the stock PCI bus driver instead.
Differential Revision: https://reviews.freebsd.org/D5891
This revision introduces PCIe support for the relevant Mediatek/Ralink
SoCs.
Currently the PCIe support is not converted to INTRNG, this may be a
task for the future.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5886
Tested on a MT7621 board, similar to the WiTi board.
More testing will be required to confirm everything is fine, but things
look good so far.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5885
USB on both MT7621 and MT7688 seems to work much better without doing
slew rate calibration.
These are the only two SoCs, apart from MT7628, which actually make
use of the slew rate calibration routines implemented in the mtk_usb_phy
driver. Since MT7628 is actually a superset of MT7688 things should be
the same for it as well.
We do not remove the code, we simply define it out.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5884
In mtk_soc.c memory is mapped incorrectly for MT7621. This revision fixes
this.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5882
GPIO controller drivers import.
As with other Ralink/Mediatek work, there are 2 versions of the GPIO
controller driver, depending on the type of SoC.
This revision introduces initial support for these.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5877
SPI drivers for the various Ralink/Mediatek SoCs. There are 2 versions of
the SPI controller (so far) present in the supported SoCs, hence v1 and v2
drivers.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5842
USB support
This revision adds USB (EHCI/OHCI/OTG, depending on SoC type) support for
various Ralink/Mediatek SoCs.
Currently USB is not supported on MT7621, this will be a future addition.
A USB PHY driver is also included, so that we can properly initialize the
USB PHY (e.g., clocks, resets, registers where needed), before attempting
to initialize EHCI/OHCI/OTG functionality.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5841
UART drivers.
- uart_dev_mtk.[ch] are the old-style Mediatek/Ralink-specific UART driver
as also found in sys/mips/rt305x/uart_dev_rt305x.c, with minor improvements
and FDT attachment enabled for the appropriate SoCs.
- uart_dev_mtk_ns8250.c is the new-style ns16550a-compatible UART driver
found in newer Mediatek SoCs. It uses the uart_dev_ns8250.c driver
indirectly and is basically just a wrapper around it and only overrides its
probe method.
The reason I am not using the uart_dev_ns8250.c driver directly is because
I have some code that does UART clock detection before initializing the
UART, so that we don't need to hard-code the UART clock frequency in the
dts files for each board.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5840
Interrupt controllers found in various Mediatek/Ralink SoCs.
mtk_intr_v1 and mtk_intr_v2 are basically the same at the moment, with
just different register mappings.
However, v1 interrupt controller has a subset of the functionality of the
v2 interrupt controller, so in the future the v2 interrupt controller driver
may be enhanced, if needed, with things like level/edge interrupts and soft
interrupts. So, for the moment I suggest we keep them as 2 separate files.
mtk_intr_gic provides very basic (similar to v1 and v2) support for MIPS GIC
controllers, which currently maps all interrupts to a single core and sets
them to type level, active high. In the future this may be developed into a
generic GIC controller to support any new MIPS SoCs that include it. The GIC
is a standard MTI interrupt controller in their multi-core line-up (e.g.,
1004K, 1074K, etc.), rather than a SoC-specific controller.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5839
This revision adds the following to the Mediatek/Ralink support:
- initial support for "clocks" FDT property, currently based on fdt_clock
- initial support for "resets" FDT property, currently based on the
fdt_reset interface from D5826
- initial support for "pinctrl,bits" functionality via FDT. May be extended
in the future to cover a better and fuller pinctrl implementation
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5827
- machine dependent low level init code
- SoC clocks detection and some utility functions
- Common interface to read/write/modify SoC system control registers, used
by some of the other drivers and utility functions
- simple FDT resets support, based on the fdt_clock implementation already
in the tree. For the moment resets and clocks are managed using these
implementations. I am planning to port those to the new extres framework
in the future, but currently I simply don't have time to do this part too.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5826
On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but
type `long' is only 32-bit. This extends rman's resources to uintmax_t. With
this change, any resource can feasibly be placed anywhere in physical memory
(within the constraints of the driver).
Why uintmax_t and not something machine dependent, or uint64_t? Though it's
possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on
32-bit architectures. 64-bit architectures should have plenty of RAM to absorb
the increase on resource sizes if and when this occurs, and the number of
resources on memory-constrained systems should be sufficiently small as to not
pose a drastic overhead. That being said, uintmax_t was chosen for source
clarity. If it's specified as uint64_t, all printf()-like calls would either
need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t
aren't horrible, but it would also bake into the API for
resource_list_print_type() either a hidden assumption that entries get cast to
uintmax_t for printing, or these calls would need the PRI*64 macros. Since
source code is meant to be read more often than written, I chose the clearest
path of simply using uintmax_t.
Tested on a PowerPC p5020-based board, which places all device resources in
0xfxxxxxxxx, and has 8GB RAM.
Regression tested on qemu-system-i386
Regression tested on qemu-system-mips (malta profile)
Tested PAE and devinfo on virtualbox (live CD)
Special thanks to bz for his testing on ARM.
Reviewed By: bz, jhb (previous)
Relnotes: Yes
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D4544
is the physical memory size so may be larger than a u_long can hold, e.g.
on ARM with LPAE we could see an address space of up to 40 bits. On ARM
u_long is only 32 bits so the memory size will be truncated, possibly to
zero.
Reported by: bz
Sponsored by: ABT Systems Ltd
Summary:
As part of the migration of rman_res_t to be typed to uintmax_t, memory ranges
must be clamped appropriately for the bus, to prevent completely bogus addresses
from being used.
This is extracted from D4544.
Reviewed By: cem
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5134
Use u_long instead of uint32_t variables to avoid overflow
in case of PA space bigger than 32-bit.
Obtained from: Semihalf
Submitted by: Michal Stanek <mst@semihalf.com>
Sponsored by: Annapurna Labs
Approved by: cognet (mentor)
Reviewed by: andrew, br, wma
Differential revision: https://reviews.freebsd.org/D5393
This simplifies checking for default resource range for bus_alloc_resource(),
and improves readability.
This is part of, and related to, the migration of rman_res_t from u_long to
uintmax_t.
Discussed with: jhb
Suggested by: marcel
will allow for code that uses the old fdt_get_range and fdt_regsize
functions to find a range, map it, access, then unmap to replace this, up
to and including the map, with a call to OF_decode_addr.
As this function should only be used in the early boot code the unmap is
mostly do document we no longer need the mapping as it's a no-op, at least
on arm.
Reviewed by: jhibbits
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5258
ucontext_t available. Our code even has XXX comment about this.
Add a bit of compliance by moving struct __ucontext definition into
sys/_ucontext.h and including it into signal.h and sys/ucontext.h.
Several machine/ucontext.h headers were changed to use namespace-safe
types (like uint64_t->__uint64_t) to not depend on sys/types.h.
struct __stack_t from sys/signal.h is made always visible in private
namespace to satisfy sys/_ucontext.h requirements.
Apparently mips _types.h pollutes global namespace with f_register_t
type definition. This commit does not try to fix the issue.
PR: 207079
Reported and tested by: Ting-Wei Lan <lantw44@gmail.com>
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
pmap_unmapdev respectively) so that resources are properly managed.
This is work originally done by kan@. Stanislav picked it up as part
of his Mediatek SoC work.
Tested:
* Carambola2, AR933x SoC
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Reviewed by: kan
Differential Revision: https://reviews.freebsd.org/D5184
This was originall done by kan@.
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Reviewed by: kan
Differential Revision: https://reviews.freebsd.org/D5184
This is a prelude to intr-ng support for MIPS boards that need it -
notably the CI20 port from kan@ that's upcoming, but also work that
Stanislav is doing for the Mediatek platforms.
This is the initial platform dependent bits in include/intr.h, some
#defines for the nexus code for the intrng initialisation/runtime
bits, some changed naming (which I'll fix later to be the same, much
like what I did for ARM intr-ng) in exception.S, and the first cut
at a PIC.
Stanislav and I refactored out the common code for intrng support,
so the mips intrng definitions are quite small (sys/mips/include/intr.h.)
This is all work done by kan@, which stanislav has been cherry picking
into common code for his mediatek chipset work.
Tested:
* Carambola2 - no regressions (not intr-ng though!)
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Reviewed by: kan (original author)
Differential Revision: https://reviews.freebsd.org/D5182
clearing hazards.
This revision makes currently known MIPS32 Release 2 and Release 3 CPUs use
the EHB instruction when clearing hazards. So far the MIPS 74K and MIPS1004K
(somewhat) were already using the EHB. Now we add more r2 and r3 CPUs to
this list.
Also, for the cases of MIPS coherent processing systems (currently 1004K,
1074K, interAptiv and proAptiv) - define proper CCA attributes.
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D5078
This revision does the following renames:
CPU_MIPS24KC -> CPU_MIPS24K
CPU_MIPS74KC -> CPU_MIPS74K
CPU_MIPS1004KC -> CPU_MIPS1004K
It also adds the following new CPU_MIPSxxx options:
CPU_MIPS24KE, CPU_MIPS34K, CPU_MIPS1074K, CPU_INTERAPTIV, CPU_PROAPTIV
CPU_MIPSxxxxKC is limiting and possibly misleading as it implies the
MIPSxxxxK CPU has no FPU.
It would be better if the CPUs are named after their standard functionalities
only and the presence or absence of FPU can then be controlled via the
CPU_HAVEFPU option.
I will send out another dependent revision that moves MIPS 32 r2 and r3
CPUs to use the EHB instruction for clearing hazards instead of NOP/SSNOP.
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D5077
Use driver settable callbacks for handling of:
- core post reset
- reading actual port speed
Typically, OTG enabled EHCI cores wants setting of USBMODE register,
but this register is not defined in EHCI specification and different
cores can have it on different offset.
Also, for cores with TT extension, actual port speed must be determinable.
But again, EHCI specification not covers this so this patch provides
function for two most common variant of speed bits layout.
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D5088
POSIX requires these members to be of type void * rather than the
char * inherited from 4BSD. NetBSD and OpenBSD both changed their
fields to void * back in 1998. No new build failures were reported
via an exp-run.
PR: 206503 (exp-run)
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D5092
Summary:
Migrate to using the semi-opaque type rman_res_t to specify rman resources. For
now, this is still compatible with u_long.
This is step one in migrating rman to use uintmax_t for resources instead of
u_long.
Going forward, this could feasibly be used to specify architecture-specific
definitions of resource ranges, rather than baking a specific integer type into
the API.
This change has been broken out to facilitate MFC'ing drivers back to 10 without
breaking ABI.
Reviewed By: jhb
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5075
providing compiled-in static environment data that is used instead of any
data passed in from a boot loader.
Previously 'env' worked only on i386 and arm xscale systems, because it
required the MD startup code to examine the global envmode variable and
decide whether to use static_env or an environment obtained from the boot
loader, and set the global kern_envp accordingly. Most startup code wasn't
doing so. Making things even more complex, some mips startup code uses an
alternate scheme that involves calling init_static_kenv() to pass an empty
buffer and its size, then uses a series of kern_setenv() calls to populate
that buffer.
Now all MD startup code calls init_static_kenv(), and that routine provides
a single point where envmode is checked and the decision is made whether to
use the compiled-in static_kenv or the values provided by the MD code.
The routine also continues to serve its original purpose for mips; if a
non-zero buffer size is passed the routine installs the empty buffer ready
to accept kern_setenv() values. Now if the size is zero, the provided buffer
full of existing env data is installed. A NULL pointer can be passed if the
boot loader provides no env data; this allows the static env to be installed
if envmode is set to do so.
Most of the work here is a near-mechanical change to call the init function
instead of directly setting kern_envp. A notable exception is in xen/pv.c;
that code was originally installing a buffer full of preformatted env data
along with its non-zero size (like mips code does), which would have allowed
kern_setenv() calls to wipe out the preformatted data. Now it passes a zero
for the size so that the buffer of data it installs is treated as
non-writeable.
These are all works in progress. Notably - no wifi support just yet!
I've booted the MT7620 on a TP-Link Archer C2 via tftpboot.
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
* Add in chipset awareness to the obio bus layout (ie, which devices are
where);
* Add in some USB OTG changes to be aware of the newer stuff;
* Add in a configurable primary console - some chips use the normal UART,
some use UARTLITE.
Tested (by Stanislav);
* RT3050 (NFS)
* RT5350 (NFS, MFS)
* MT7620 (USB)
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
The Ingenic JZ7480 SoC that is on the Imagination Technologies CI20 board
has an L2 cache:
Cache info:
picache_stride = 4096
picache_loopcount = 8
pdcache_stride = 4096
pdcache_loopcount = 8
cpu0: Ingenic Xburst processor v79.2
MMU: Standard TLB, 32 entries
L1 i-cache: 8 ways of 128 sets, 32 bytes per line
L1 d-cache: 8 ways of 128 sets, 32 bytes per line
L2 cache: 8 ways of 256 sets, 128 bytes per line, 256 KiB total size
Config1=0xbe67338b<WatchRegs,EJTAG,FPU>
Config2=0x80000267
Config3=0x20
is what includes machine/ofw_machdep.h. Don't declare OF_decode_addr();
it isn't implemented yet on mips and the declaration for it is about to
be commonized into openfirm.h.
address and use this mechanism when:
1. kmem_alloc_{attr,contig}() can't find suitable free pages in the physical
memory allocator's free page lists. This replaces the long-standing
approach of scanning the inactive and inactive queues, converting clean
pages into PG_CACHED pages and laundering dirty pages. In contrast, the
new mechanism does not use PG_CACHED pages nor does it trigger a large
number of I/O operations.
2. on 32-bit MIPS processors, uma_small_alloc() and the pmap can't find
free pages in the physical memory allocator's free page lists that are
covered by the direct map. Tested by: adrian
3. ttm_bo_global_init() and ttm_vm_page_alloc_dma32() can't find suitable
free pages in the physical memory allocator's free page lists.
In the coming months, I expect that this new mechanism will be applied in
other places. For example, balloon drivers should use relocation to
minimize fragmentation of the guest physical address space.
Make vm_phys_alloc_contig() a little smarter (and more efficient in some
cases). Specifically, use vm_phys_segs[] earlier to avoid scanning free
page lists that can't possibly contain suitable pages.
Reviewed by: kib, markj
Glanced at: jhb
Discussed with: jeff
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D4444
This is a holdover from how reset is handled in the ARGE_MDIO world.
You need to define the mdio bus device if you want to use the ethernet
device or the arge setup path doesn't bring the MAC out of reset.
http://www.t-es-t.hu/download/mips/md00090c.pdf this is bit 3 of the
config0 word, not bit 2. This should fix virtually indexed caches
(relatively new in the MIPS world, so no current platforms used this
and current code just uses it as an optimization). It was causing
false positives on newer platforms that default to large values for
the kseg0 cache coherency attribute.
Submitted by: Stanislav Galabov
PR: 205249
These helper functions can be used to read in or write a buffer from or to
an arbitrary process' address space. Without them, this can only be done
using proc_rwmem(), which requires the caller to fill out a uio. This is
onerous and results in code duplication; the new functions provide a simpler
interface which is sufficient for most existing callers of proc_rwmem().
This change also adds a manual page for proc_rwmem() and the new functions.
Reviewed by: jhb, kib
Differential Revision: https://reviews.freebsd.org/D4245
sysent.
sv_prepsyscall is unused.
sv_sigsize and sv_sigtbl translate signal number from the FreeBSD
namespace into the ABI domain. It is only utilized on i386 for iBCS2
binaries. The issue with this approach is that signals for iBCS2 were
delivered with the FreeBSD signal frame layout, which does not follow
iBCS2. The same note is true for any other potential user if
sv_sigtbl. In other words, if ABI needs signal number translation, it
really needs custom sv_sendsig method instead.
Sponsored by: The FreeBSD Foundation
created for bus_dma_tag_t tag, bounce pages should be allocated
only if needed.
Before the fix, they were allocated always if BUS_DMA_COULD_BOUNCE flag
was set but BUS_DMA_MIN_ALLOC_COMP not. As bounce pages are never freed,
it could cause memory exhaustion when a lot of such tags together with
their maps were created.
Note that there could be more maps in one tag by current design.
However BUS_DMA_MIN_ALLOC_COMP flag is tag's flag. It's set after
bounce pages are allocated. Thus, they are allocated only for first
tag's map which needs them.
Approved by: kib (mentor)
Extended memory here is "physical memory above 256MB".
"memsize" in the environment only grows to 256MB; "ememsize" is the entire
memory range. Extended memory shows up at physical address 0x90000000.
This allows for malta64 VMs to be created with > 256MB RAM, all the way
up to 2GB RAM.
Tested:
* qemu-devel package; qemu-system-mips64 -m 2048 (and -m 256 to test the
no-ememsize case.)
TODO:
* testing mips32 with > 256MB RAM.
Reviewed by: imp
for the AP143.
Wifi doesn't work on the QCA9533 board, but basic ethernet/ethernet
and ethernet switch support does work.
The AP143 has 32MB RAM and 4MB flash, so this was tested with a USB
rootfs.
Tested:
* QCA9533v2, AP143 reference design board.
Small $25 IoT device, 400mhz Atheros cpu, Atheros WiFi and Ethernet
18 GPIOs, and support for Relay, Servo, and OLED expansion
https://onion.io/omega/
Reviewed by: adrian
Approved by: bapt (mentor)
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D4188
The QCA953x SoC is an integrated 2x2 2GHz 11n + MIPS24k core, with
a 5 port FE switch, gige WAN port, and all the same stuff you'd find on
its predecessor - the AR9331.
However, buried deep in here somewhere is also a PCIe EP/RC for various
applications and some other weird bits I don't yet know about.
This is enough to get the reference board up and booting. I haven't yet
had it pass lots of packets - I need to finalise the ethernet switch
bits and the GMAC configuration (ie, how the ethernet ports and switch
are wired up) and I'll bring that in when I commit the base configuration
files to use the thing.
The wifi stuff will come much later. I have to port that support from
Linux ath9k and extend our vendor HAL to support it.
The reference board (AP143) comes with 32MB RAM and 4MB flash, so in order
to use it I need to get USB working fully so I can run root from there.
Thankyou to Qualcomm Atheros for access to the reference design board.
Details:
* Add register definitions from openwrt;
* It looks like a QCA955x but shrunk down to a QCA933x footprint, so
use the QCA955x bits and fix up the clock detection code to do the
QCA953x bits (they're very subtly different);
* Teach GPIO about it;
* Teach EHCI about it;
* Teach if_arge about it;
* Teach the CPU detection code about it.
Tested:
* AP143, QCA9533v2 SoC
Obtained from: Linux, Linux OpenWRT
I discovered that we're logging each trap, which gets pretty spendy;
and there wasn't any further information on the pid/tid/progname involved.
I originally noticed this because I don't attach anything to /dev/log and so
the log() output stays going to the kernel. That's an oops on my part, but
I'm glad I did it.
This commit adds the following:
* a rate limiter, which could do with some eyeballs/ideas on how to
make it more predictable on SMP;
* log pid, tid, progname (comm) as part of the output.
I now get output like this:
Unaligned Load Word: pid=621 (pmcstat), tid=100060, pc=0xffffffff803ae898, badvaddr=0x40a10055
Unaligned Load Word: pid=621 (pmcstat), tid=100060, pc=0xffffffff803ae898, badvaddr=0x40a10051
Unaligned Load Word: pid=621 (pmcstat), tid=100060, pc=0xffffffff803ae898, badvaddr=0x40a1004d
Unaligned Load Word: pid=602 (login), tid=100042, pc=0xffffffff803ae898, badvaddr=0x401159
Unaligned Load Word: pid=602 (login), tid=100042, pc=0xffffffff803ae898, badvaddr=0x401155
Unaligned Load Word: pid=602 (login), tid=100042, pc=0xffffffff803ae898, badvaddr=0x401151
.. which makes it much easier to start figuring out what/where to fix.
The pc looks suss (it looks like it's in kernel space); I'll dig into that one next.
Tested:
* AR9331 SoC (Carambola2)
mips24k/mips74k document that we need an explicit SYNC so to order
things correctly, even with access to uncachable memory.
We were doing calls to SYNC in the cache ops (inv, wbinv) but we
weren't doing it for uncachable memory.
When I ported this code from netbsd I was .. slightly mips74k greener.
I used writethrough because (a) it's what netbsd did, and (b) if I used
writethrough then things "didn't work."
Fast-forward a couple years, more MIPS hacking and a whole lot more
understanding of the bus APIs (the last few commits notwithstanding;
it's been a long week, ok?) and I have this working for arge,
argemdio, spi and ath. Hans has it working for USB. The ath barrier
code will come in a later commit.
This gets the routing throughput up from 220mbit -> 337mbit.
I'm sure the bridging throughput will be similarly improved.
Tested:
* QCA955x SoC, routing workload.
* use barriers in a slightly better fashion. You can blame this
glass of whiskey on putting barriers in the wrong spot. Grr adrian.
* steal/rewrite the mdio busy check from ag7100 from openwrt and
refactor the existing code out. This is .. more correct.
This seems to fix the boot-to-boot variation that I've been seeing
and it quietens the switch port status flapping.
Tested:
* QCA9558 SoC (AP135.)
Obtained from: Linux OpenWRT
This driver and the linux ag71xx driver both treat the transmit ring
as a circular linked list of descriptors. There's no "end" pointer
that is ever NULL - instead, it expects the MAC to hit a finished
descriptor (ARGE_DESC_EMPTY) and stop.
Now, since it's a circular buffer, we may end up with the hardware
hitting the beginning of our multi-descriptor frame before we've finished
setting it up. It then DMA's it in, starts sending it, and we finish
writing out the new descriptor. The hardware may then write its
completion for the next descriptor out; then we do, and when we next
read it it'll show up as "not done" and transmit completion stops.
This unfortunately manifests itself as the transmit queue always
being active and a massive TX interrupt storm. We need to actively
ACK packets back from the transmit engine and if we don't (eg because
we think the transmit isn't finished but it is) then the unit will
just keep generating interrupts.
I hit this finally with the below testing setup. This fixed it for me.
Strictly speaking I should put in a sync in between writing out all of
the descriptors and writing out that final descriptor.
Tested:
* QCA9558 SoC (AP135 reference board) w/ arge1 + vlans acting as a
router, and iperf -d (tcp, bidirectional traffic.)
Obtained from: Linux OpenWRT (ag71xx_main.c.)
The MIPS busdma sync operations currently are a big no-op on coherent memory.
This isn't strictly correct behaviour as we need a SYNC in here to ensure that
the writes have finished and are visible in main memory before the MMIO accesses
occur. This will have to be addressed in a later commit.
But, before that happens, let's at least do a flush here to make things
more "correct".
This is required for even remotely sensible behaviour on mips74k with
write-through memory enabled.
The mips74k programmers guide notes that reads can be re-ordered, even
uncached ones, so we need an explicit SYNC between them.
Yes, this is a case of a driver author actively doing a bus barrier
operation.
This ends up being necessary when the mips74k core is run in write-back
mode rather than write-through mode. That's coming in an upcoming
commit.
Tested:
* mips74k, QCA9558 SoC (AP135 reference board), arge<->arge interface
routing traffic tests.
send frames.
This matches the other check for space.
"enough" is a misnomer, for "reasons". The biggest reason is that
the TX ring is actually a circular linked list, with no head/tail pointers.
This is just a bit more headroom between head/tail so we have time to
schedule frames before we hit where the hardware is at.
Ideally this would be tunable and a little larger.
This flushes out the write to the system before anything continues.
The mips74k guide, chapter 3.3.3 (write gathering) notes that writes
can be buffered in FIFOs - even uncached ones - so we can't guarantee
the device has felt its effects. Now, since we're all lazy driver
authors and don't pepper read/write barriers everywhere, fake it here.
tested:
* mips74k - QCA9558 SoC (AP135 reference board)
This should make it easier to track down interrupt storms from arge.
Tested:
* AP135 (QCA955x) SoC - defaults to ARGE_DEBUG enabled
* Carambola2 (AR9331 SoC) - defaults to ARGE_DEBUG disabled
I couldn't test arge0->arge1 bridging, only arge0 VLAN bridging.
The DIR-825C1 only hooks up arge0 to the switch GMAC0 and so
you need to abuse VLANs to test.
Tested:
* DIR-825C1 (AR9344)
This is an AR9331 part based on the AP121 reference design but with
32MB RAM. Yes, it has 4MB flash and it has no USB, so clever hacks
are required to get it up and working.
But boot/work it does.
This part seems to work bug-free with single byte TX/RX buffer alignment.
This drops the CPU requirement to bridge 100mbit iperf from 100% CPU
to ~ 50% CPU.
Tested:
* AP121 (AR9330) SoC, highly magic netbooted kernel + USB rootfs
due to 4mb flash, 16mb RAM; doing bridging between arge0 and arge1.
Notes:
* Yes, I likely can also turn this on for the AR934x SoC family now.
But since hardware design apparently follows similar branching
strategies to software design, I'll go and make sure all the AR934x's
that made it out into shipping products work before I flip it on.
offset within the buffer to align the L3 headers we know the buffer itself
was allocated and sized on cacheline boundaries and we don't need to
preserve partitial cachelines at the start and end of the buffer when
doing busdma sync operations.
to copying in some code from the armv4 busdma, and adapting a few variable
and flag names to match the surrounding mips code.
Instead of keeping a local cache of prealloced busdma_map structs on a
mutex-protected list, set up an uma zone to cache them.
Instead of all memory allocations using M_DEVBUF, use new categories
M_BUSDMA for allocations of metadata (tags, maps, segment tracking lists),
and M_BOUNCE for bounce pages.
When buffers are allocated out of the busdma_bufalloc zones the alignment
and size of the buffers is known, and the code can skip doing any "partial
cacheline flush" logic to preserve data that may be adjacent to the DMA
buffer but contain non-DMA data.
Reviewed by: adrian, imp
and implement support for VM_MEMATTR_UNCACHEABLE. This will be used in
upcoming changes to support BUS_DMA_COHERENT in bus_dmamem_alloc().
Reviewed by: adrian, imp
This was triggering when using it as an AP bridge rather than an ethernet
bridge.
The code is unclear but it works; I'll fix it to be clearer and test
performance at a later stage.
The existing code meets the "alignment" requirement for the l3 payload
by offsetting the mbuf by uint64_t and then calling an rx fixup routine
to copy the frame backwards by 2 bytes. This DWORD aligns the
L3 payload so tcp, etc doesn't panic on unaligned access.
This is .. slow.
For arge MACs that support 1 byte TX/RX address alignment, we can do
the "other" hack: offset the RX address of the mbuf so the L3 payload
again is hopefully DWORD aligned.
This is much cheaper - since TX/RX is both 1 byte align ready (thanks
to the previous commit) there's no bounce buffering going on and there
is no rx fixup copying.
This gets bridging performance up from 180mbit/sec -> 410mbit/sec.
There's around 10% of CPU cycles spent in _bus_dmamap_sync(); I'll
investigate that later.
Tested:
* QCA955x SoC (AP135 reference board), bridging arge0/arge1
by programming the switch to have two vlangroups in dot1q mode:
# ifconfig bridge0 inet 192.168.2.20/24
# etherswitchcfg config vlan_mode dot1q
# etherswitchcfg vlangroup0 members 0,1,2,3,4
# etherswitchcfg vlangroup1 vlan 2 members 5,6
# etherswitchcfg port5 pvid 2
# etherswitchcfg port6 pvid 2
# ifconfig arge1 up
# ifconfig bridge0 addm arge1
The early ethernet MACs (I think AR71xx and AR913x) require that both
TX and RX require 4-byte alignment for all packets.
The later MACs have started relaxing the requirements.
For now, the 1-byte TX and 1-byte RX alignment requirements are only for
the QCA955x SoCs. I'll add in the relaxed requirements as I review the
datasheets and do testing.
* Add a hardware flags field and 1-byte / 4-byte TX/RX alignment.
* .. defaulting to 4-byte TX and 4-byte RX alignment.
* Only enforce the TX alignment fixup if the hardware requires a 4-byte
TX alignment. This avoids a call to m_defrag().
* Add counters for various situations for further debugging.
* Set the 1-byte and 4-byte busdma alignment requirement when
the tag is created.
This improves the straight bridging performance from 130mbit/sec
to 180mbit/sec, purely by removing the need for TX path bounce buffers.
The main performance issue is the RX alignment requirement and any RX
bounce buffering that's occuring. (In a local test, removing the RX
fixup path and just aligning buffers raises the performance to above
400mbit/sec.
In theory it's a no-op for SoCs before the QCA955x.
Tested:
* QCA9558 SoC in AP135 board, using software bridging between arge0/arge1.
The ERL is a fairly cheap (~$100 USD) and readily available dual core
MIPS64 device so it makes a useful MIPS reference platform.
This is based in part on the kernel config generated by the mkerlimage
script from http://rtfm.net/FreeBSD/ERL/.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3884
* Shuffle the kernel to be at the beginning
* Give the kernel 2mb, the rootfs 6mb, and 'mib0' the rest
* put the cfg parition just before the ART calibration data for the
wifi part in the SoC
* .. and make sure ART points to the right 64k region.
I've updated the freebsd-wifi-build wiki the instructions on using this.
If someone has an AP135 with 8MB SPI flash then this won't work; everything
minus the big mib0 partition is just a bit over 8MB. Come see me if this
ever happens (you'll likely just have to shrink the rootfs and the kernel
a little in order to make it fit.)
Tested:
* AP135 reference board.
belong to a vm object, they can't be paged out. Since they can't be paged
out, they are never enqueued in a paging queue. Nonetheless, passing
PQ_INACTIVE to vm_page_unwire() creates the appearance that these pages
are being enqueued in the inactive queue. As of r288122, we can avoid
this false impression by passing PQ_NONE.
Submitted by: kmacy (an earlier version)
Differential Revision: https://reviews.freebsd.org/D1674
linkers no longer raise an error when undefined weak symbols are
found, but relocate as if the symbol value was 0. Note that we do not
repeat the mistake of userspace dynamic linker of making the symbol
lookup prefer non-weak symbol definition over the weak one, if both
are available. In fact, kernel linker uses the first definition
found, and ignores duplicates.
Signature of the elf_lookup() and elf_obj_lookup() functions changed
to split result/error code and the symbol address returned.
Otherwise, it is impossible to return zero address as the symbol
value, to MD relocation code. This explains the mechanical changes in
elf_machdep.c sources.
The powerpc64 R_PPC_JMP_SLOT handler did not checked error from the
lookup() call, the patch leaves the code as is (untested).
Reported by: glebius
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
When the system has more than a single PCI domain, the bus numbers
are not unique, thus they cannot be used for "pci" device numbering.
Change bus numbers to -1 (i.e. to-be-determined automatically)
wherever the code did not care about domains.
Reviewed by: jhb
Obtained from: Semihalf
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3406
running thread.
It is currently implemented only on amd64 and i386; on these
architectures, it is implemented by raising an NMI on the CPU on which
the target thread is currently running. Unlike stack_save_td(), it may
fail, for example if the thread is running in user mode.
This change also modifies the kern.proc.kstack sysctl to use this function,
so that stacks of running threads are shown in the output of "procstat -kk".
This is handy for debugging threads that are stuck in a busy loop.
Reviewed by: bdrewery, jhb, kib
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D3256
The only operation which is prevented by the hold is the kernel stack
swapout for the faulted thread, which should be fine to allow.
Remove useless checks for NULL curproc or curproc->p_vmspace from the
trap_pfault() wrappers on x86 and powerpc.
Reviewed by: alc (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
nlge(4) is supposed to deprecate rge(4) for Broadcom XLR when it was
introduced 5 years ago.
rge doesn't build on -CURRENT due to MII changes. All the XLR kernel confs
use nlge. Let's get rid of the old driver for FreeBSD 11. We can use
10-STABLE or SVN to go back and look at the old driver if needed.
Differential Revision: https://reviews.freebsd.org/D3339
Submitted by: kevin.bowling@kev009.com
Add a check to preload_search_info to make sure mod is set. Most of the
callers of preload_search_info don't check that the mod parameter is
set, which can cause page faults. While at it, remove some now unnecessary
checks before calling preload_search_info.
Sponsored by: Citrix Systems R&D
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D3440
vm_offset_t pmap_quick_enter_page(vm_page_t m)
void pmap_quick_remove_page(vm_offset_t kva)
These will create and destroy a temporary, CPU-local KVA mapping of a specified page.
Guarantees:
--Will not sleep and will not fail.
--Safe to call under a non-sleepable lock or from an ithread
Restrictions:
--Not guaranteed to be safe to call from an interrupt filter or under a spin mutex on all platforms
--Current implementation does not guarantee more than one page of mapping space across all platforms. MI code should not make nested calls to pmap_quick_enter_page.
--MI code should not perform locking while holding onto a mapping created by pmap_quick_enter_page
The idea is to use this in busdma, for bounce buffer copies as well as virtually-indexed cache maintenance on mips and arm.
NOTE: the non-i386, non-amd64 implementations of these functions still need review and testing.
Reviewed by: kib
Approved by: kib (mentor)
Differential Revision: http://reviews.freebsd.org/D3013
provide a semantic defined by the C11 fences with corresponding
memory_order.
atomic_thread_fence_acq() gives r | r, w, where r and w are read and
write accesses, and | denotes the fence itself.
atomic_thread_fence_rel() is r, w | w.
atomic_thread_fence_acq_rel() is the combination of the acquire and
release in single operation. Note that reads after the acq+rel fence
could be made visible before writes preceeding the fence.
atomic_thread_fence_seq_cst() orders all accesses before/after the
fence, and the fence itself is globally ordered against other
sequentially consistent atomic operations.
Reviewed by: alc
Discussed with: bde
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
and start teaching subsystems about it.
The Atheros MIPS platforms don't guarantee any kind of FIFO consistency
with interrupts in hardware. So software needs to do a flush when it
receives an interrupt and before it calls the interrupt handler.
There are new ones for the QCA934x and QCA955x, so do a few things:
* Get rid of the individual ones (for ethernet and IP2);
* Create a mux and enum listing all the variations on DDR flushes;
* replace the uses of IP2 with the relevant one (which will typically
be "PCI" here);
* call the USB DDR flush before calling the real USB interrupt handlers;
* call the ethernet one upon receiving an interrupt that's for us,
rather than never calling it during operation.
Tested:
* QCA9558 (TP-Link archer c7 v2)
* AR9331 (Carambola 2)
TODO:
* PCI, USB, ethernet, etc need to do a double-check to see if the
interrupt was truely for them before doing the DDR. For now I
prefer "correct" over "fast".
The SoC, the flash, the ethernet ports and ethernet switch all work.
The USB works.
The 11ac PCIe NIC internally is at least seen by the PCIE RC, but
I haven't tried using it yet. There's no driver and I haven't
yet swapped it out for a non-11ac chip.
The on-chip 2GHz wifi works, but there are some data errors that
get thrown up in STA mode when scanning. I have a feeling I have
to finish the DDR flush code out and have it run correctly on the
shared interrupts; that'll take a bit of time to get right.
But if you're after an updated piece of hardware, the Archer C7 v2
is certainly there, and you can replace the 11ac NIC with a 3x3
Atheros PCIe device (eg AR9380, AR9390, AR9580, etc) and it'll
"just work".
Tested:
* TP-Link archer c7v2.
The Tp-link Archer-C7v2 unit has a QCA9558 internally but hangs the
QCA988x 11ac PCIe NIC off of PCI RC #1, not #0.
So I actually finally /do/ have a board to verify whether PCIe is working.
Grr.
Tested:
* TP-Link Archer-C7v2.
* GENERAL
- Update copyright.
- Make kernel options for RANDOM_YARROW and RANDOM_DUMMY. Set
neither to ON, which means we want Fortuna
- If there is no 'device random' in the kernel, there will be NO
random(4) device in the kernel, and the KERN_ARND sysctl will
return nothing. With RANDOM_DUMMY there will be a random(4) that
always blocks.
- Repair kern.arandom (KERN_ARND sysctl). The old version went
through arc4random(9) and was a bit weird.
- Adjust arc4random stirring a bit - the existing code looks a little
suspect.
- Fix the nasty pre- and post-read overloading by providing explictit
functions to do these tasks.
- Redo read_random(9) so as to duplicate random(4)'s read internals.
This makes it a first-class citizen rather than a hack.
- Move stuff out of locked regions when it does not need to be
there.
- Trim RANDOM_DEBUG printfs. Some are excess to requirement, some
behind boot verbose.
- Use SYSINIT to sequence the startup.
- Fix init/deinit sysctl stuff.
- Make relevant sysctls also tunables.
- Add different harvesting "styles" to allow for different requirements
(direct, queue, fast).
- Add harvesting of FFS atime events. This needs to be checked for
weighing down the FS code.
- Add harvesting of slab allocator events. This needs to be checked for
weighing down the allocator code.
- Fix the random(9) manpage.
- Loadable modules are not present for now. These will be re-engineered
when the dust settles.
- Use macros for locks.
- Fix comments.
* src/share/man/...
- Update the man pages.
* src/etc/...
- The startup/shutdown work is done in D2924.
* src/UPDATING
- Add UPDATING announcement.
* src/sys/dev/random/build.sh
- Add copyright.
- Add libz for unit tests.
* src/sys/dev/random/dummy.c
- Remove; no longer needed. Functionality incorporated into randomdev.*.
* live_entropy_sources.c live_entropy_sources.h
- Remove; content moved.
- move content to randomdev.[ch] and optimise.
* src/sys/dev/random/random_adaptors.c src/sys/dev/random/random_adaptors.h
- Remove; plugability is no longer used. Compile-time algorithm
selection is the way to go.
* src/sys/dev/random/random_harvestq.c src/sys/dev/random/random_harvestq.h
- Add early (re)boot-time randomness caching.
* src/sys/dev/random/randomdev_soft.c src/sys/dev/random/randomdev_soft.h
- Remove; no longer needed.
* src/sys/dev/random/uint128.h
- Provide a fake uint128_t; if a real one ever arrived, we can use
that instead. All that is needed here is N=0, N++, N==0, and some
localised trickery is used to manufacture a 128-bit 0ULLL.
* src/sys/dev/random/unit_test.c src/sys/dev/random/unit_test.h
- Improve unit tests; previously the testing human needed clairvoyance;
now the test will do a basic check of compressibility. Clairvoyant
talent is still a good idea.
- This is still a long way off a proper unit test.
* src/sys/dev/random/fortuna.c src/sys/dev/random/fortuna.h
- Improve messy union to just uint128_t.
- Remove unneeded 'static struct fortuna_start_cache'.
- Tighten up up arithmetic.
- Provide a method to allow eternal junk to be introduced; harden
it against blatant by compress/hashing.
- Assert that locks are held correctly.
- Fix the nasty pre- and post-read overloading by providing explictit
functions to do these tasks.
- Turn into self-sufficient module (no longer requires randomdev_soft.[ch])
* src/sys/dev/random/yarrow.c src/sys/dev/random/yarrow.h
- Improve messy union to just uint128_t.
- Remove unneeded 'staic struct start_cache'.
- Tighten up up arithmetic.
- Provide a method to allow eternal junk to be introduced; harden
it against blatant by compress/hashing.
- Assert that locks are held correctly.
- Fix the nasty pre- and post-read overloading by providing explictit
functions to do these tasks.
- Turn into self-sufficient module (no longer requires randomdev_soft.[ch])
- Fix some magic numbers elsewhere used as FAST and SLOW.
Differential Revision: https://reviews.freebsd.org/D2025
Reviewed by: vsevolod,delphij,rwatson,trasz,jmg
Approved by: so (delphij)
This makes the TP-Link WDR3600 routers more useful
Differential Revision: https://reviews.freebsd.org/D2780
Approved by: adrian
Sponsored by: ScaleEngine Inc.
Native ABI do not need signal conversion, only emulators may want this. Usually
emulators implements its own sv_sendsig method. For now only ibcs2 emulator does
not have own sv_sendsig implementation and depends on native sendsig() method.
So, remove any extra attempts to convert signal numbers from native sendsig()
methods except from i386 where ibsc2 is living.
when allocation fails, it suffices to perform VM_WAIT. The direct map
covers the entirely of physical memory, so unlike 32-bit mips any
physical page can be used as a page table page.
years for head. However, it is continuously misused as the mpsafe argument
for callout_init(9). Deprecate the flag and clean up callout_init() calls
to make them more consistent.
Differential Revision: https://reviews.freebsd.org/D2613
Reviewed by: jhb
MFC after: 2 weeks
The replacement started at r283088 was necessarily incomplete without
replacing boolean_t with bool. This also involved cleaning some type
mismatches and ansifying old C function declarations.
Pointed out by: bde
Discussed with: bde, ian, jhb
* Change mips24k -> mips74k for hwpmc, but leave it disabled for now.
* don't build pci by default.
* build pci and qca955x_pci for AP135, as theres a PCIe NIC.
* don't build a hwpmc module, it doesn't really work out well
for the mips boards at the moment.
* add ipfw and DEFAULT_TO_ACCEPT.
The QCA955x looks a lot like the AR724x PCIe controller, except it
supports two root complexes. Unfortunately I only have one, so
although this code has started down the path of supporting more than
one, it's definitely not yet ready.
Tested:
* AP135 board (QCA9558 SoC), with the 11ac NIC swapped for an AR9380
PCIe NIC.
Notes:
* Yes, this driver isn't very pretty. I decided to commit what I have
versus holding onto something that isn't yet finished. It is enough
to bring up the above NIC and interrupt routing works, so it's a good
start.
* However, yes, the DDR flush routine hooks need to be fixed up.
I don't think I'm firing the right one at the moment.
pages which pass a NULL virtual address. If the BUS_DMA_KEEP_PG_OFFSET
flag is set, use the physical address to compute the page offset
instead. The physical address should always be valid when adding
bounce pages and should contain the same page offset like the virtual
address.
Submitted by: Svatopluk Kraus <onwahe@gmail.com>
MFC after: 1 week
Reviewed by: jhb@
The carambola2 exposes all the gpio pins, but some are reserved for
core functions (eg usb, ethernet, etc.) Others are configured by default
to be available as normal GPIO pins to do interesting things with.
GPIO 18->23 is the I2S, SLIC and SPDIF device pins, but none of those
are currently used. So, just allow those to show up.
Tested:
* AR9344, Carambola 2
* (.. bitbang SPI to an Adafruit LCD via libgpio, because FreeBSD could
do with more shiny output devices that aren't network interfaces.)
TODO:
There are some other pins aren't currently included here, but should be.
The LED pins are for the internal switch inside the AR9344.
* GPIO 0+1 are "LED0 + LED1", but they're tied to high for bootstrapping.
* GPIO 13-17 are "LED2..7", but they're tied (H, L, L, L, H) for bootstrapping.
* GPIO 11 and 12 are UART RTS/CTS or I2S; but GPIO 12 is tied L for bootstrap.
This is needed with the pl011 driver. Before this change it would default
to a shift of 0, however the hardware places the registers at 4-byte
addresses meaning the value should be 2.
This patch fixes this for the pl011 when configured using the fdt. The
other drivers have a default value of 0 to keep this a no-op.
MFC after: 1 week
and export them to userland.
- Define __HAVE_REG32 on platforms that define a reg32 structure and check
for this in <sys/procfs.h> to control when to export prstatus32, etc.
- Add prstatus32_t and prpsinfo32_t typedefs for the 32-bit structures.
libbfd looks for these types, and having them fixes 'gcore' in gdb of a
32-bit process on a 64-bit platform.
- Use the structure definitions from <sys/procfs.h> in gcore's elf32 core
dump code instead of duplicating the definitions.
Differential Revision: https://reviews.freebsd.org/D2142
Reviewed by: kib, nathanw (powerpc bits)
MFC after: 1 week
The MAC addresses were totally wrong. They're like the DIR-625C1 - at
0x1ffe0004 and 0x1ffe0018. They're however stored as text strings.
The ath0 MAC address is also not set, even though the calibration
partition is valid.
So, pick the board address / first MAC as the ath0 MAC, and derive
arge0/arge1 from that. That way they're hopefully unique enough
for people with multiple devices.
Tested:
* DIR-655A1
TODO:
* Do the same for the DIR-625A1 and DIR-625C1.
A couple of internal functions used by malloc(9) and uma truncated
a size_t down to an int. This could cause any number of issues
(e.g. indefinite sleeps, memory corruption) if any kernel
subsystem tried to allocate 2GB or more through malloc. zfs would
attempt such an allocation when run on a system with 2TB or more
of RAM.
Note to self: When this is MFCed, sparc64 needs the same fix.
Differential revision: https://reviews.freebsd.org/D2106
Reviewed by: kib
Reported by: Michael Fuckner <michael@fuckner.net>
Tested by: Michael Fuckner <michael@fuckner.net>
MFC after: 2 weeks
This allows the TL-WDR3600 to use the correct MAC address for ath0, ath1
and arge0. arge1 isn't used; until I disable it entirely it'll just
show up with a randomly generated MAC.
A lot of these dinky atheros based MIPS boards don't have a nice, well,
anything consistent defining their MAC addresses for things.
The Atheros reference design boards will happily put MAC addresses
into the wifi module calibration data like they should, and individual
ethernet MAC addresses into the calibration area in flash.
That makes my life easy - "hint.arge.X.eeprommac=<addr>" reads from
that flash address to extract a MAC, and everything works fine.
However, aside from some very well behaved vendors (eg the Carambola 2
board), everyone else does something odd.
eg:
* a MAC address in the environment (eg ubiquiti routerstation/RSPRO)
that you derive arge0/arge1 MAC addresses from.
* a MAC address in flash that you derive arge0/arge1 MAC addresses from.
* The wifi devices having their own MAC addresses in calibration data,
like normal.
* The wifi devices having a fixed, default or garbage value for a MAC
address in calibration data, and it has to be derived from the
system MAC.
So to support this complete nonsense of a situation, there needs to be
a few hacks:
* The "board" MAC address needs to be derived from somewhere and squirreled
away. For now it's either redboot or a MAC address stored in calibration
flash.
* Then, a "map" set of hints to populate kenv with some MAC addresses
that are derived/local, based on the board address. Each board has
a totally different idea of what you do to derive things, so each
map entry has an "offset" (+ve or -ve) that's added to the board
MAC address.
* Then if_arge (and later, if_ath) should check kenv for said hint and
if it's found, use that rather than the EEPROM MAC address - which may
be totally garbage and not actually work right.
In order to do this, I've undone some of the custom redboot expecting
hacks in if_arge and the stuff that magically adds one to the MAC
address supplied by the board - instead, as I continue to test this
out on more hardware, I'll update the hints file with a map explaining
(a) where the board MAC should come from, and (b) what offsets to use
for each device.
The aim is to have all of the tplink, dlink and other random hardware
we run on have valid MAC addresses at boot, so (a) people don't get
random B:S:D❌x:x ethernet MACs, and (b) the wifi MAC is valid
so it works rather than trying to use an invalid address that
actually upsets systems (think: multicast bit set in BSSID.)
Tested:
* TP-Link TL_WDR3600 - subsequent commits will add the hints map
and the if_ath support.
TODO:
* Since this is -HEAD, and I'm all for debugging, there's a lot of
printf()s in here. They'll eventually go under bootverbose.
* I'd like to turn the macaddr routines into something available
to all drivers - too many places hand-roll random MAC addresses
and parser stuff. I'd rather it just be shared code.
However, that'll require more formal review.
* More boards.
Without this the autotuning fails for small amounts of RAM (32mb),
which all the AR91xx shipping products seemed to have.
Thanks to gjb for reminding me to re-test this stuff.
Tested:
* AR91xx, TP-Link TL-WR1043nd v1
This is based on the AP135 design - QCA9558 SoC, 3x3 2GHz wifi, but no
5GHz (11n or 11ac) chip is available.
It however still has 128MiB of RAM, 16MiB of NOR flash and the AR8327N
gigabit switch - so it's quite a beefy router device.
Tested:
* Well, a unit, naturally
Obtained from: Completely messing up an amazon.com order and getting this instead, and asking "hey, wonder if I could.."
* add ipfw
* delete ath / ath_ahb for now, until I can have Warner beat me
with the clue stick about putting in conditional build things into
the ath Makefile so the module builds can just have the HAL bits
that are relevant for a particular target.
These are actually almost the same units; except one is 3x3 5GHz, and
one is 2x2 5GHz.
Tested:
* TP-Link TL-WDR3600
TODO:
* The ath0/ath1 MAC addresses are ye garbage (00:02:03:04:05:06); fixing
that will take a little more time. It works fine with the ath0/ath1
MAC addresses set manually.
* Go through and yank the AR9344 on-board switch config (arswitch1);
it's not required here for this AP.
The AR934x (and maybe others in this family) have a more complicated
GPIO mux. The AR71xx just has a single function register for a handful
of "GPIO or X" options, however the AR934x allows for one of roughly
100 behaviours for each GPIO pin.
So, this adds a quick hints based mechanism to configure the output
functions, which is required for some of the more interesting board
configurations. Specifically, some use external LNAs to improve
RX, and without the MUX/output configured right, the 2GHz RX side
will be plain terrible.
It doesn't yet configure the "input" side yet; I'll add that if
it's required.
Tested:
* TP-Link TL-WDR3600, testing 2GHz STA/AP modes, checking some
basic RX sensitivity things (ie, "can I see the AP on the other
side of the apartment that intentionally has poor signal reception
from where I am right now.")
Whilst here, fix a silly bug in the maxpin routine; I was missing
a break.
A lot of these embedded boards don't have a unique MAC address per
device stored somewhere unique - sometimes they'll have one MAC
for both arge NICs; someties they'll have one MAC for both arge NICs
/and/ the ath NICs. In these instances, we need to derive device
specific MAC addresses from the base MAC address.
These functions will be used by some follow-up code that'll slot
into if_arge and if_ath.
Otherwise, the initial media speed would change if a PHY is hooked up,
sending PHY speed notifications. For the AP135 at least, the RGMII
PHY has a static speed/duplex configured and if the PHY plumbing
attaches the PHY to the if_arge interface, the first link speed change
from 1000/full will set the MAC to something that isn't useful.
This shouldn't affect any other platforms - everything I looked at is
using hard-coded speed/duplex as static, as they're facing a switch
with no PHY attached.
* Force the arge0 interface to not use a PHY for speed negotiation
for now. It'd be nice to do it, but right now the RGMII interface
to the switch needs to stay at 1000/full in order to match what
the switch side of the port is programmed as.
So until that's all sorted out, disconnect arge0 from the PHY
and leave it at fixed at 1000/full.
I noticed this when I tried using a busted ethernet cable that
forced the PHY to negotiate 100/full. The switch was fine and
it negotiated to 100/full, but then arge0 saw the link update
and set the speed to 100/full when the switch side of that
hook up was set to 1000/full. Tsk.
* When using argemdio, the mdio device resets and initialises
the MAC, /not/ the arge_attach (or, as I discovered, arge_init.)
So arge1 wasn't being fully initialised and thus no traffic
would ever flow.
So until I tidy up that mess, just create an argemdio bus for
arge1. It's totally fine; it won't do anything or find anything
attached to it.
Tested:
* AP135 reference board - both arge0 and arge1 now work.
This is a QCA9558 SoC (2ghz 3x3) with an atheros 11ac PCIe 5GHz 3x3
NIC and an AR8327 gigabit ethernet switch.
TODO:
* The AR8327 gigabit switch support bugfixes are forthcoming.
* 11ac support and 11ac NIC support
This is enough to bring up the basic SoC support.
What works thus far:
* The mips74k core, pll setup, and UART (or else well, stuff would
be really difficult..)
* both USB 2.0 EHCI controllers
* on-board 2GHz 3x3 wifi (the other variant has 2GHz/5GHz wifi on-chip);
* arge0 - not yet sure why arge1 isn't firing off interrupts and thus
handling traffic, but I will soon figure it out and fix it here.
Tested:
* AP135 reference design, QCA9558 SoC, pretending to be an 11n
2GHz AP.
TODO:
* There's an interrupt mux hooking up devices to IP2 and IP3 - but it's
not a read-and-clear or write-to-clear register. So, trying to use it
naively like I have been ends up with massive interrupt storms.
For now the things that share those interrupts can just take them as
shared interrupts and try to play nice.
* There's two PCIe root complexes /and/ one of them can actually be
a PCIe device endpoint. Yes, you heard right. I have to teach the
AR724x PCIe bridge code to handle multiple instances with multiple
memory/irq regions, and then there'll be RC support, but EP support
isn't on my TODO list.
* I'm not sure why arge1 isn't up and running. I'll go figure that
out soon and fix it here.
Thankyou to Qualcomm Atheros for providing me with hardware and
an abundance of documentation about these things.
There's two EHCI controllers in the QCA955x SoCs - they have different
interrupts available via various demux registers, but they both tie to
IP3.
So for now, allow them to be sharable so they can hang off of IP3.
There's a lot more to come - the QCA955x has a bunch more GPIO MUX
configuration, reminiscent of what the ARM chips let you do - but
it'll have to come later.
This will override the resource allocation of simplebus, and also
merge the resource allocation code which was in xlp_pci.c.
With this change the SoC devices that does not have proper PCI
resources will be on the FDT simplebus. We can remove
sys/mips/nlm/dev/cfi_pci_xlp.c and sys/mips/nlm/dev/uart_pci_xlp.c
Handling some interrupts in XLP (like PCIe and SATA) involves writing to
vendor specific registers as part of interrupt acknowledgement.
This was earlier done with xlp_establish_intr(), but a better solution
is to provide a function xlp_set_bus_ack() that can be used with
cpu_establish_hardintr(). This will allow platform initialization code to
setup these ACKs without changing the standrard drivers.
Gather all the IRQ definitions to interrupt.h. Earlier these were in xlp.h
and pic.h. Update the definition of XLP_IRQ_IS_PICINTR to check for last
irq as well.
const. On x86, even after the machine context is supposedly read into
the struct ucontext, lazy FPU state save code might only mark the FPU
data as hardware-owned. Later, set_fpcontext() needs to fetch the
state from hardware, modifying the *mcp.
The set_mcontext(9) is called from sigreturn(2) and setcontext(2)
implementations and old create_thread(2) interface, which throw the
*mcp out after the set_mcontext() call.
Reported by: dim
Discussed with: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
for i386, and from the code inspection, nothing in the
arm/mips/sparc64 implementations depends on it.
Discussed with: imp, nwhitehorn
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
This avoids universe trying to build MALTA_COMMON and fail due to
the problem addressed in r276773.
Include std.MALTA from the MALTA mipsel and MALTA64 mips64el config files,
where the machine lines exist.
code in sys/kern/kern_dump.c. Most dumpsys() implementations are nearly
identical and simply redefine a number of constants and helper subroutines;
a generic implementation will make it easier to implement features around
kernel core dumps. This change does not alter any minidump code and should
have no functional impact.
PR: 193873
Differential Revision: https://reviews.freebsd.org/D904
Submitted by: Conrad Meyer <conrad.meyer@isilon.com>
Reviewed by: jhibbits (earlier version)
Sponsored by: EMC / Isilon Storage Division
socket-buffer implementations, introduce a return value for MCLGET()
(and m_cljget() that underlies it) to allow the caller to avoid testing
M_EXT itself. Update all callers to use the return value.
With this change, very few network device drivers remain aware of
M_EXT; the primary exceptions lie in mbuf-chain pretty printers for
debugging, and in a few cases, custom mbuf and cluster allocation
implementations.
NB: This is a difficult-to-test change as it touches many drivers for
which I don't have physical devices. Instead we've gone for intensive
review, but further post-commit review would definitely be appreciated
to spot errors where changes could not easily be made mechanically,
but were largely mechanical in nature.
Differential Revision: https://reviews.freebsd.org/D1440
Reviewed by: adrian, bz, gnn
Sponsored by: EMC / Isilon Storage Division
The QCA955x has more mux interrupts going on - and the AR934x actually does,
but I cheated and assigned wlan and pcie to the same interrupt line.
They are, there's just a status register mux that I should've been using.
Luckily this isn't too bad a change in itself - almost all of the
Atheros MIPS configurations use a _BASE file to inherit from.
Except PB92, which I should really fix up at some point.
The AR934x will use the legacy apb for now until I write its replacement.
The QCA955x SoC I'm doing bring-up on will have a separate qca955x_apb.c
implementation that includes hooking into IP2/IP3 and doing further
interrupt demuxing as appropriate.
APB mux.
It's larger than the AR71xx because it needs to replace the nexus
for some devices (notably wifi) and the wifi driver (if_ath_ahb.c)
reads the SPI data directly at early boot whilst it's memory mapped
in.
I'm eventually going to rip it out and replace it with a firmware
interface similar to what exists for the if_ath_pci.c path -
something early on (likely something new that I'll write) will
suck in the calibration data into a firmware API blob and that'll
be accessed from if_ath_ahb.c.
But, one thing at a time.
Tested:
* QCA955x SoC, AP135 development board
This adds the initial frequency poking and configures up enough
for it to boot and spit out data over the console.
There's still a whole bunch of work to do in the reset path
and devices to support this thing, but hey, it's alive!
ath> go 0x80050100
## Starting application at 0x80050100 ...
CPU platform: Atheros AR9558 rev 0
CPU Frequency=720 MHz
CPU DDR Frequency=600 MHz
CPU AHB Frequency=200 MHz
platform frequency: 720 MHz
CPU reference clock: 0 MHz
CPU MDIO clock: 40 MHz
Done at: hackathon
Obtained from: Linux OpenWRT, Qualcomm Atheros
There's likely a bunch of register offsets that I have to add the
register window base to before I use them.
Done at: Hackathon
Obtained from: Linux OpenWRT
The AR934x and later (which will turn up eventually) have a new GPIO
output configuration option - a real MUX rather than a "GPIO or this
function."
For now I'm squirreling it away in the CPU code just so it's done -
I may move this to the GPIO layer later.
Specifically, this is required for setting up some boards that have
external receive side LNA (low noise amplifier) that gets switched on/off
by the on-chip wireless MAC. If we don't add this support for those
boards then we'll end up with really poor performance.
(I don't yet have one of those APs, but it'll likely show up in a week.)
Obtained from: Linux OpenWRT
The elftoolchain project includes these additional defines for various
userland programs. Given that arch-specific defines are still interesting
in the context of userland programs reading or writing ELF metadata, they
should be included in top-level ELF headers.
Remove duplicate defines from ARM and MIPS elf headers.
Submitted by: will (initial version)
Reviewed by: imp, will
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D844
managing pages from different address ranges. Generally speaking, this
feature is used to increase the likelihood that physical pages are
available that can meet special DMA requirements or can be accessed through
a limited-coverage direct mapping (e.g., MIPS). However, prior to this
change, the configuration of the free lists was static, i.e., it was
determined at compile time. Consequentally, free lists could be created
for address ranges that held no actual pages, for example, on 32-bit MIPS-
based systems with 512 MB or less of physical memory. This change makes
the creation of the free lists dynamic, i.e., it is based on the available
physical memory at boot time.
On 64-bit x86-based systems with 64 GB or more of physical memory, create
free lists for managing pages with physical addresses below 4 GB. This
change is to address reported problems with initializing devices that
require the allocation of physical pages below 4 GB on some systems with
128 GB or more of physical memory.
PR: 185727
Differential Revision: https://reviews.freebsd.org/D1274
Reviewed by: jhb, kib
MFC after: 3 weeks
Sponsored by: EMC / Isilon Storage Division
It's redundant at the moment since it can be obtained from the trapframe
on the architectures where DTrace is supported, but this won't be the case
with ARM.
for counter mode), and AES-GCM. Both of these modes have been added to
the aesni module.
Included is a set of tests to validate that the software and aesni
module calculate the correct values. These use the NIST KAT test
vectors. To run the test, you will need to install a soon to be
committed port, nist-kat that will install the vectors. Using a port
is necessary as the test vectors are around 25MB.
All the man pages were updated. I have added a new man page, crypto.7,
which includes a description of how to use each mode. All the new modes
and some other AES modes are present. It would be good for someone
else to go through and document the other modes.
A new ioctl was added to support AEAD modes which AES-GCM is one of them.
Without this ioctl, it is not possible to test AEAD modes from userland.
Add a timing safe bcmp for use to compare MACs. Previously we were using
bcmp which could leak timing info and result in the ability to forge
messages.
Add a minor optimization to the aesni module so that single segment
mbufs don't get copied and instead are updated in place. The aesni
module needs to be updated to support blocked IO so segmented mbufs
don't have to be copied.
We require that the IV be specified for all calls for both GCM and ICM.
This is to ensure proper use of these functions.
Obtained from: p4: //depot/projects/opencrypto
Relnotes: yes
Sponsored by: FreeBSD Foundation
Sponsored by: NetGate
Special thanks to Nicholas Esborn for the loaner router to get this
target bootstrapped.
Review: D777
Reviewed by: adrian
Sponsored by: Nicholas Esborn <nick@desert.net>
commit 6d3c4c0922
Add terasic_mtl vt(4) framebuffer driver
terasic_mtl can be built with syscons(4) and vt(4) attachments, selected
at compile time.
commit 33240259b4
Clear terasic_mtl text buffer on attach
commit d188c2d241
Update terasic vt(4) driver for FreeBSD r269783
commit d1cc54eee8
Safety belt to ensure vt(4) fb parameters are correct
commit 76e6d468ef
Improve terasic_mtl_vt fdt parsing
- Use OF_getencprop to avoid need for explicit endian handling
(submitted by ray@freebsd.org)
- Check for expected length and correct pointer type
commit 3e2524b899
Correct device_printf usage
commit 9e53e3c8e0
Switch framebuffer to match host endianness
Xorg and xf86-video-scfb work much better with a native-endian
framebuffer.
commit 0f49259d59
Switch DE4 to vt(4) and enable kbdmux
commit 5bc96ebc89
Add missing \n in device_printf calls
Submitted by: emaste
Sponsored by: DARPA, AFRL
This change saves/restores the callee-saved MIPS floating point
registers as documented by the o32/n32/n64 spec ("MIPSpro N32
ABI Handbook", Table 2-1) for the _setjmp(3), _longjmp(3),
setjmp(3) and longjmp(3) C library functions. This is only
included when the C library is built with hardware floating point
support (or when "SOFTFLOAT" is not defined).
Submitted by: sson
MFC after: 1 month
Sponsored by: DARPA, AFRL
have chosen different (and more traditional) stateless/statuful
NAT64 as translation mechanism. Last non-trivial commits to both
faith(4) and faithd(8) happened more than 12 years ago, so I assume
it is time to drop RFC3142 in FreeBSD.
No objections from: net@
unit 0.
It seems that this 'simplification' was copied to all GPIO drivers in tree.
This fix a bug where a GPIO controller could fail to attach its children
(gpioc and gpiobus) if another GPIO driver attach first.
and casuword(9), but do not mix value read and indication of fault.
I know (or remember) enough assembly to handle x86 and powerpc. For
arm, mips and sparc64, implement fueword() and casueword() as wrappers
around fuword() and casuword(), which means that the functions cannot
distinguish between -1 and fault.
On architectures where fueword() and casueword() are native, implement
fuword() and casuword() using fueword() and casuword(), to reduce
assembly code duplication.
Sponsored by: The FreeBSD Foundation
Tested by: pho
MFC after: 2 weeks (ia64 needs treating)
- Wrong integer type was specified.
- Wrong or missing "access" specifier. The "access" specifier
sometimes included the SYSCTL type, which it should not, except for
procedural SYSCTL nodes.
- Logical OR where binary OR was expected.
- Properly assert the "access" argument passed to all SYSCTL macros,
using the CTASSERT macro. This applies to both static- and dynamically
created SYSCTLs.
- Properly assert the the data type for both static and dynamic
SYSCTLs. In the case of static SYSCTLs we only assert that the data
pointed to by the SYSCTL data pointer has the correct size, hence
there is no easy way to assert types in the C language outside a
C-function.
- Rewrote some code which doesn't pass a constant "access" specifier
when creating dynamic SYSCTL nodes, which is now a requirement.
- Updated "EXAMPLES" section in SYSCTL manual page.
MFC after: 3 days
Sponsored by: Mellanox Technologies
in userland rename in-kernel getenv()/setenv() to kern_setenv()/kern_getenv().
This fixes a namespace collision with libc symbols.
Submitted by: kmacy
Tested by: make universe
There's a bug in the AR7240 PCIe hardware where a correct BAR will end
up having the device disappear.
It turns out that for the device address it should be all 0's.
However, this meant that the PCI probe code would try writing 0xffffffff
in to see how big the window was, read back 0x0, and think the window
was 32 bits. It then ended up calculating a resource size of 0 bytes,
failed to find anything via an rman call, and this would fail to attach.
I have quite absolutely no idea how in the various planes of existence
this particular bit of code and how it worked with the PCI bus code
ever worked. But, well, it did.
Tested:
* Atheros AP93 - AR7240 + AR9280 reference board
It was doing incorrect things with masks. This was fixed in the
AR71xx codebase but it wasn't yet fixed in the AR724x code.
This ended up having config space reads return larger/incorrect values
in some situations.
Tested:
* AR7240
TODO:
* test ar7241, AR7242, and AR934x.
node's interrupts=<...> property creating resource list entries with a
single common implementation. This change makes ofw_bus_intr_to_rl() the
one true copy of that code and removes the copies of it from other places.
This also adds handling of the interrupts-extended property, which allows
specifying multiple interrupts for a node where each interrupt can have a
separate interrupt-parent. The bindings for this state that the property
cells contain an xref phandle to the interrupt parent followed by whatever
interrupt info that parent normally expects. This leads to having a
variable number of icells per interrupt in the property. For example you
could have <&intc1 1 &intc2 26 9 0 &intc3 9 4>.
Differential Revision: https://reviews.freebsd.org/D803
When the FreeBSD kernel is loaded from Xen the symtab and strtab are
not loaded the same way as the native boot loader. This patch adds
three new global variables to ddb that can be used to specify the
exact position and size of those tables, so they can be directly used
as parameters to db_add_symbol_table. A new helper is introduced, so callers
that used to set ksym_start and ksym_end can use this helper to set the new
variables.
It also adds support for loading them from the Xen PVH port, that was
previously missing those tables.
Sponsored by: Citrix Systems R&D
Reviewed by: kib
ddb/db_main.c:
- Add three new global variables: ksymtab, kstrtab, ksymtab_size that
can be used to specify the position and size of the symtab and
strtab.
- Use those new variables in db_init in order to call db_add_symbol_table.
- Move the logic in db_init to db_fetch_symtab in order to set ksymtab,
kstrtab, ksymtab_size from ksym_start and ksym_end.
ddb/ddb.h:
- Add prototype for db_fetch_ksymtab.
- Declate the extern variables ksymtab, kstrtab and ksymtab_size.
x86/xen/pv.c:
- Add support for finding the symtab and strtab when booted as a Xen
PVH guest. Since Xen loads the symtab and strtab as NetBSD expects
to find them we have to adapt and use the same method.
amd64/amd64/machdep.c:
arm/arm/machdep.c:
i386/i386/machdep.c:
mips/mips/machdep.c:
pc98/pc98/machdep.c:
powerpc/aim/machdep.c:
powerpc/booke/machdep.c:
sparc64/sparc64/machdep.c:
- Use the newly introduced db_fetch_ksymtab in order to set ksymtab,
kstrtab and ksymtab_size.
than u_char.
Migrate post_filter to use an int for a CPU rather than u_char.
Change intr_event_bind() to use an int for CPU rather than u_char.
It touches the ppc, sparc64, arm and mips machdep code but it should
(hah!) be a no-op.
Tested:
* i386, AMD64 laptops
Reviewed by: jhb
Prevent saturattion of the bus by constant polling which in
extreme cases can cause interface lockup. This makes FreeBSD
match similar case in the executive.
