New kernel events can be added at various location for sampling or counting.
This will for example allow easy system profiling whatever the processor is
with known tools like pmcstat(8).
Simultaneous usage of software PMC and hardware PMC is possible, for example
looking at the lock acquire failure, page fault while sampling on
instructions.
Sponsored by: NETASQ
MFC after: 1 month
The on-chip SD slots do not have PCI BARs corresponding to them, so
this has to be handled in the custom SoC memory allocation.
Provide memory resource for rids corresponding to BAR 0 and 1 in
the custom allocation code.
The XLP on-chip devices have PCI configuration headers, but some of the
devices need custom resource allocation code.
- devices with no MEM/IO BARs with registers in PCIe extended reg
space have to be handled in memory resource allocation
- devices without INTPIN/INTLINE in PCI header can be supported
by having these faked with a shadow register.
- Some devices does not allow 8/16 bit access to the register space,
he default bus space cannot be used for these.
Subclass pci and override attach and resource allocation methods to
take care of this.
Remove earlier code which did this partially.
Move XLP PCI UART device to sys/mips/nlm/dev/ directory. Other
drivers for the XLP SoC devices will be added here as well.
Update uart_cpu_xlp.c and uart_pci_xlp.c use macros for uart port,
speed and IO frequency.
Features:
- network driver for the four 10G interfaces and two management ports
on XLP 8xx.
- Support 4xx and 3xx variants of the processor.
- Source code and firmware building for the 16 mips32r2 micro-code engines
in the Network Accelerator.
- Basic initialization code for Packet ordering Engine.
Submitted by: Prabhath Raman (prabhath at netlogicmicro com)
[refactored and fixed up for style by jchandra]
On XLP evaluation platform, the board information is stored
in an I2C eeprom and the network block configuration is available
from a CPLD connected to the GBU (NOR flash bus). Add support
for both of these.
Support for the Security and RSA blocks on XLP SoC. Even though
the XLP supports many more algorithms, only the ones supported
in OCF have been added.
Submitted by: Venkatesh J. V. (venkatesh at netlogicmicro com)
- XLP supports hardware swap for PCIe IO/MEM accesses. Since we
are in big-endian mode, enable hardware swap and use the normal
bus space.
- move some printfs to bootverbose, and remove others.
- fix SoC device resource allocation code
- Do not use '|' while updating PCIE_BRIDGE_MSI_ADDRL
- some style fixes
In collaboration with: Venkatesh J. V. (venkatesh at netlogicmicro com)
- Replace MIPS24K-specific code with more generic framework that will
make adding new CPU support easier
- Add MIPS24K support for new framework
- Limit backtrace depth to 1 for stability reasons and add option
HWPMC_MIPS_BACKTRACE to override this limitation
As of FreeBSD 8, this driver should not be used. Applications that use
posix_openpt(2) and openpty(3) use the pts(4) that is built into the
kernel unconditionally. If it turns out high profile depend on the
pty(4) module anyway, I'd rather get those fixed. So please report any
issues to me.
The pty(4) module is still available as a kernel module of course, so a
simple `kldload pty' can be used to run old-style pseudo-terminals.
These are needed for some particular port configurations where the default
speed isn't suitable for all link speed types. (Ie, changing 10/100/1000MBit
PLL rate requires a similar MII clock rate, rather than a fixed MII rate.)
This is:
* only currently implemented for the ar71xx;
* isn't used anywhere (yet), as the final interface for this hasn't yet
been determined.
function.
From the submitter:
This patch fixes an issue I encountered using an NFS root with an
ar71xx-based MikroTik RouterBoard 450G on -current where the kernel fails
to contact a DHCP/BOOTP server via if_arge when it otherwise should be able
to. This may be the same issue that Monthadar Al Jaberi reported against
an RSPRO on 6 March, as the signature is the same:
%%%
DHCP/BOOTP timeout for server 255.255.255.255
DHCP/BOOTP timeout for server 255.255.255.255
DHCP/BOOTP timeout for server 255.255.255.255
.
.
.
DHCP/BOOTP timeout for server 255.255.255.255
DHCP/BOOTP timeout for server 255.255.255.255
arge0: initialization failed: no memory for rx buffers
DHCP/BOOTP timeout for server 255.255.255.255
arge0: initialization failed: no memory for rx buffers
%%%
The primary issue that I found is that the DHCP/BOOTP message that
bootpc_call() is sending never makes it onto the wire, which I believe is
due to the following:
- Last December, a change was made to the ifioctl that bootpc_call() uses
to adjust the netmask around the sosend().
- The new ioctl (SIOCAIFADDR) performs an if_init when invoked, whereas the
old one (SIOCSIFNETMASK) did not.
- if_arge maintains its own sense of link state in sc->arge_link_status.
- On a single-phy interface, sc->arge_link_status is initialized to 0 in
arge_init_locked().
- sc->arge_link_status remains 0 until a phy state change notification
causes arge_link_task to run, notice the link is up, and set it to 1.
- The inits caused by the ifioctls in bootpc_call are reinitializing the
interface, but not the phy, so sc->arge_link_status goes to 0 and remains
there.
- arge_start_locked() always sees sc->arge_link_status == 0 and returns
without queuing anything.
The attached patch changes arge_init_locked() such that in the single-phy
case, instead of initializing sc->arge_link_status to 0, it runs
arge_link_task() to set it according to the current phy state. This change
has allowed my setup to mount an NFS root successfully.
Submitted by: Patrick Kelsey <kelsey@ieee.org>
Reviewed by: juli
I had some interesting hangs until I realised I should try flushing the
DDR FIFO register and lo and behold, hangs stopped occuring.
I've put in a few DDR flushes here and there in case people decide to
reuse some of these functions. It's very very likely they're almost
all superflous.
To test:
* Connect to a network with a _lot_ of broadcast traffic
* Do this:
# while true; do ifconfig arge0 down; ifconfig arge0 up; done
This fixes the mbuf exhaustion that has been reported when the interface
state flaps up/down.
required for the ABI the kernel is being built for.
XXX This is implemented in a kind-of nasty way that involves including source
files, but it's still an improvement.
o) Retire ISA_* options since they're unused and were always wrong.
* enable ALQ and net80211/ath ALQ logging by default, to make it possible
to get debug register traces.
* Update some comments
* Enable HWPMC for testing.
implementations or no implementation on all platforms.
Some of these functions might be good ideas, but their semantics were unclear
given the lack of implementation, and an unlucky porter could be fooled into
trying to implement them or, worse, being baffled when something like
platform_trap_enter() failed to be called.
- Pass interrupt trapframe for handlers dow the chain
- Add PMC interrupt handler
PMC interrupt is a special case, so we want handle it as soon as possible
with minimum overhead. So we handle it apb filter routine.
bootable image.
The kernel has to fit inside an 896KiB area in a 4MB SPI flash.
So a bunch of stuff can't be included (and more is to come), including
(unfortunately) IPv6.
TODO:
* GPIO modules need to be created
* Shrink the image a bit more by removing some of the CAM layer debugging
strings.
make use of it where possible.
This primarily brings in support for newer hardware, and FreeBSD is not yet
able to support the abundance of IRQs on new hardware and many features in the
Ethernet driver.
Because of the changes to IRQs in the Simple Executive, we have to maintain our
own list of Octeon IRQs now, which probably can be pared-down and be specific
to the CIU interrupt unit soon, and when other interrupt mechanisms are added
they can maintain their own definitions.
Remove unmasking of interrupts from within the UART device now that the
function used is no longer present in the Simple Executive. The unmasking
seems to have been gratuitous as this is more properly handled by the buses
above the UART device, and seems to work on that basis.
o) The MAC set must occur before the multicast list is set up as the former
will enable the CAM unconditionally, while promiscuous mode disables it,
so if promiscuous mode is to be set this must occur after the MAC is
programmed.
o) The multicast list must be set up unconditionally as even if flags have
not changed, if the interface has gone through a reinitialization, the
state of the CAM as changed by the MAC initialization could be incorrect.
o) Call octm_init when flags change, even if the interface is already running.
