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.
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.
on-board, glued to the AR71xx CPU. These may forgo separate WMAC EEPROMs
(which store configuration and calibration data) and instead store
it in the main board SPI flash.
Normally the NIC reads the EEPROM attached to it to setup various PCI
configuration registers. If this isn't done, the device will probe as
something different (eg 0x168c:abcd, or 0x168c:ff??.) Other setup registers
are also written to which may control important functions.
This introduces a new compile option, AR71XX_ATH_EEPROM, which enables the
use of this particular code. The ART offset in the SPI flash can be
specified as a hint against the relevant slot/device number, for example:
hint.pcib.0.bus.0.17.0.ath_fixup_addr=0x1fff1000
hint.pcib.0.bus.0.18.0.ath_fixup_addr=0x1fff5000
TODO:
* Think of a better name;
* Make the PCIe version of this fixup code also use this option;
* Maybe also check slot 19;
* This has to happen _before_ the SPI flash is set from memory-mapped
to SPI-IO - so document that somewhere.
This was preventing the ath driver from being loaded at runtime.
It worked fine when compiled statically into the kernel but not when
kldload'ed after the system booted.
The root cause was that PCIR_INTLINE (register 60) was being
overwritten by zeros when register 62 was being written to.
A subsequent read of this register would return 0, and thus
the rest of the PCI glue assumed an IRQ resource had already
been allocated. This caused the device to fail to attach at
runtime as the device itself didn't contain any IRQ resources.
TODO: go back over the ar71xx and ar724x PCI config read/write
code and ensure it's correct.
performance issues.
* Access to the GPIO bus is already locked by requesting
and releasing the bus - thus the lock isn't really needed
for each GPIO pin change.
* Don't lock and unlock the GPIO bus for -each- i2c access -
the i2c bus code is already doing this by calling the upper
layer callback to request/release the bus. This thus locks
the bus for the entirety of the transaction.
TODO:
* Further verify that everything is correctly requesting/
releasing the GPIO bus.
* Look at how to lock the GPIO pin configuration stuff,
potentially by locking/unlocking the bus at the gpiobus
layer.
config and function mask setup.
* "gpiomask" now specifies which GPIO pins to enable, for devices to bind to.
* "function_set" allows bits in the function register to be set at GPIO setup.
* "function_clear" allows bits in the function register to be cleared at
GPIO setup.
The function_set/function_clear bits allow for individual GPIO pins to either
drive a GPIO line or an alternate function - eg USB, JTAG, etc. This allows
for things like CS1/CS2 be enabled for those boards w/ >1 SPI device connected,
or disabling JTAG for the AR7240 (which is apparently needed ..)
I've verified this on the AR71xx.
This patch should remove the need for kldunload of USB
controller drivers at suspend and kldload of USB controller
drivers at resume.
This patch also fixes some build issues in avr32dci.c
MFC after: 2 weeks
the ar71xx platform code should assume a uboot or redboot environment.
The current code gets very confused (and just crashes) on a uboot
environment, where each attribute=value pair is in a single entry.
Redboot on the other hand stores it as "attribute", "value", "attribute",
"value", ...
This allows the kernel to boot on a TP-LINK TL-WR1043ND from flash,
where the uboot environment gets setup. This didn't show up during a netboot
as "tftpboot" and "go" don't setup the uboot environment variables.
one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.
Because driver is accessing a common MII structure in
mii_pollstat(), updating user supplied structure should be done
before dropping a driver lock.
Reported by: Karim (fodillemlinkarimi <> gmail dot com)
(reporting IFM_LOOP based on BMCR_LOOP is left in place though as
it might provide useful for debugging). For most mii(4) drivers it
was unclear whether the PHYs driven by them actually support
loopback or not. Moreover, typically loopback mode also needs to
be activated on the MAC, which none of the Ethernet drivers using
mii(4) implements. Given that loopback media has no real use (and
obviously hardly had a chance to actually work) besides for driver
development (which just loopback mode should be sufficient for
though, i.e one doesn't necessary need support for loopback media)
support for it is just dropped as both NetBSD and OpenBSD already
did quite some time ago.
- Let mii_phy_add_media() also announce the support of IFM_NONE.
- Restructure the PHY entry points to use a structure of entry points
instead of discrete function pointers, and extend this to include
a "reset" entry point. Make sure any PHY-specific reset routine is
always used, and provide one for lxtphy(4) which disables MII
interrupts (as is done for a few other PHYs we have drivers for).
This includes changing NIC drivers which previously just called the
generic mii_phy_reset() to now actually call the PHY-specific reset
routine, which might be crucial in some cases. While at it, the
redundant checks in these NIC drivers for mii->mii_instance not being
zero before calling the reset routines were removed because as soon
as one PHY driver attaches mii->mii_instance is incremented and we
hardly can end up in their media change callbacks etc if no PHY driver
has attached as mii_attach() would have failed in that case and not
attach a miibus(4) instance.
Consequently, NIC drivers now no longer should call mii_phy_reset()
directly, so it was removed from EXPORT_SYMS.
- Add a mii_phy_dev_attach() as a companion helper to mii_phy_dev_probe().
The purpose of that function is to perform the common steps to attach
a PHY driver instance and to hook it up to the miibus(4) instance and to
optionally also handle the probing, addition and initialization of the
supported media. So all a PHY driver without any special requirements
has to do in its bus attach method is to call mii_phy_dev_attach()
along with PHY-specific MIIF_* flags, a pointer to its PHY functions
and the add_media set to one. All PHY drivers were updated to take
advantage of mii_phy_dev_attach() as appropriate. Along with these
changes the capability mask was added to the mii_softc structure so
PHY drivers taking advantage of mii_phy_dev_attach() but still
handling media on their own do not need to fiddle with the MII attach
arguments anyway.
- Keep track of the PHY offset in the mii_softc structure. This is done
for compatibility with NetBSD/OpenBSD.
- Keep track of the PHY's OUI, model and revision in the mii_softc
structure. Several PHY drivers require this information also after
attaching and previously had to wrap their own softc around mii_softc.
NetBSD/OpenBSD also keep track of the model and revision on their
mii_softc structure. All PHY drivers were updated to take advantage
as appropriate.
- Convert the mebers of the MII data structure to unsigned where
appropriate. This is partly inspired by NetBSD/OpenBSD.
- According to IEEE 802.3-2002 the bits actually have to be reversed
when mapping an OUI to the MII ID registers. All PHY drivers and
miidevs where changed as necessary. Actually this now again allows to
largely share miidevs with NetBSD, which fixed this problem already
9 years ago. Consequently miidevs was synced as far as possible.
- Add MIIF_NOMANPAUSE and mii_phy_flowstatus() calls to drivers that
weren't explicitly converted to support flow control before. It's
unclear whether flow control actually works with these but typically
it should and their net behavior should be more correct with these
changes in place than without if the MAC driver sets MIIF_DOPAUSE.
Obtained from: NetBSD (partially)
Reviewed by: yongari (earlier version), silence on arch@ and net@
of endian-ness issues with the AR724x.
From Luiz:
* Fix the bus space tag used so endian-ness is correctly handled;
* Only do the workaround for the AR7240; AR7241/AR7242 (PB92)
don't require this
From me:
* Add a read flush from openwrt
Submitted by: Luiz Otavio O Souza
This is reported to work on the AR7240 based Ubiquiti Rocket M5
but I haven't tested it on that hardware. I also don't yet have
it fully working on the AR7242 based development board here;
probe/attach functions but the register space resource looks like
the endian-ness is wrong (0x10000000 instead of 0x00001000).o
Further digging will be required.
Submitted by: Luiz Otavio O Souza
bus driver at detach, hence ehci_detach() does exactly this since r199718.
Submitted by: Luiz Otavio O Souza
MFC after: 7 days
Approved by: thompsa (mentor)
levels. TX would hang, RX wouldn't. A bit of digging showed the interface
send queue was full, but IFF_DRV_OACTIVE was clear and the hardware TX
queue was empty.
It turns out that there wasn't a check to drain the interface send
queue once hardware TX had completed, so if the interface send queue
had filled up in the meantime, subsequent packets would be dropped
by the higher layers and if_start (and thus arge_start()) would never
be called.
The fix is simple - call arge_start_locked() in the software interrupt
handler after the hardware TX queue has been handled or a TX underrun
occured. This way the interface send queue gets drained.
offset in the flash.
Some devices (eg the TPLink WR-1043ND) don't have a flash environment
partition which can be queried for the current board settings.
This particular workaround allows for image creators to use a hint
to set the base MAC address. For example:
hint.arge.0.eeprommac=0x1f01fc00
just for Redboot.
At some point we're going to need to build options for different
boot environments - for example, the UBoot setups I've seen simply
have the MAC address hard-coded at a fixed location in flash.
The OpenWRT support simply yanks the if_arge MAC directly from that
in code, rather than trying to find a uboot environment to pull it
from.
memory detected from Redboot, or overrides the "otherwise" case
if no Redboot information was found.
Some AR71XX platforms don't use Redboot (eg TP-LINK devices using
UBoot; some later Ubiquiti devices which apparently also use
UBoot) and at least one plain out lies - the Ubiquiti LS-SR71A
Redboot says there's 16mb of RAM when in fact there's 32mb.
A more "clean" solution will be needed at a later date.
The AR913x/AR724x USB lives at a different offset to the AR71xx
USB, so this needs to be either adjusted for in a subsequent
commit, or updated in hints for kernels compiled for those
platforms.
Submitted by: Luiz Otavio O Souzau <loos.br@gmail.com>
mipsel' or 'machine mips mipseb' into the config file (with a few 64's
tossed in for good measure). This will let us build the proper
kernels with different worlds as part of make universe.
This reflects actual type used to store and compare child device orders.
Change is mostly done via a Coccinelle (soon to be devel/coccinelle)
semantic patch.
Verified by LINT+modules kernel builds.
Followup to: r212213
MFC after: 10 days
* Add a function to write to the relevant PLL register
* Break out the PLL configuration for the AR71XX into the CPU ops,
lifted from if_arge.c.
* Add the AR91XX PLL configuration ops, using the AR91XX register
definitions.
This is untested but should at least allow an AR724X to boot.
The current code is lacking the detail needed to expose the PCIe bus.
It is also lacking any NIC, PLL or flush/WB code.
This works well enough to bring a system up to single-user mode
using an MDROOT.
Known Issues:
* The EHCI USB doesn't currently work and will panic the kernel during
attach.
* The onboard ethernet won't work until the PLL routines have been
fleshed out and shoe-horned into if_arge.
* The WMAC device glue (and quite likely the if_ath support)
hasn't yet been implemented.
* Implement a SoC probe function, from Linux, which determines the
SoC family, type and revision. This only probes the AR71xx series
SoC and (currently) panics on others.
* Migrate some of the AR71XX specific hardware init (USB device, determining
system frequencies) into using the cpuops introduced in an earlier commit.
Other SoC specific hardware stuff (per-device flush/WB, GPIO pin wiring,
Ethernet PLL setup, other things I've likely missed) will be introduced in
subsequent commits.
Reviewed by: imp@
Obtained from: (partially) Linux
Each of these SoCs have different devices, different hardware initialisation
methods and, quite likely, different quirks. These functions will abstract
out the SoC differences and keep these differences out of the drivers (eg
USB init, if_arge, etc.)
The existing code only checked the alignment of the first mbuf and
didn't enforce the size constraints.
This commit introduces a simple function to check the alignment and
size of all mbufs in the list. This fixes the initial issue in the
PR.
PR: kern/148307
Reviewed by: gonzo@
* Add some per-device sysctl entries which record the watchdog state -
whether it is armed; whether the last reboot was due to the watchdog.
* Add a per-device sysctl debug flag to enable logging watchdog arming/
disarming.
Reviewed by: gonzo@
queue length. The default value for this parameter is 50, which is
quite low for many of today's uses and the only way to modify this
parameter right now is to edit if_var.h file. Also add read-only
sysctl with the same name, so that it's possible to retrieve the
current value.
MFC after: 1 month
The RX overflow is reported in bit 2 on real hardware and Linux driver
for the same device already has this defined correctly.
This fixes frequent interrupt storms seen on RouterStation Pro boards.
Discussed with: gonzo
symbols resolving in DDB
- When zeroing .bss/.sbss do not round end address to page boundary,
it's not neccessary and might destroy data pased by trampoline or
boot loader
and deactivate_device
- Save state before attaching driver and restore it when
detaching
- Clear CLK bit after last bit of byte has been sent over
the bus providing falling edge for last byte in transfer
- Fix several places where CS0 was always assumed
- Add $FreeBSD$ to ar71xxreg.h
fixed-state media with parameters set via hints
and configure MAC accordingly to these parameters.
All the underlying PHY magic is done by boot manager
on startup. At the moment there is no proper way
to make active and control all PHYs simultaneously
from one MII bus and there is no way to associate
incoming/outgoing packet with specific PHY.
