The configuration is:
* RGMII, both ports
* arge0 - connected to PHY4 as a dedicated port (CPU port)
* arge1 - connected to the switch ports
I've verified this on my routerstation pro board.
* Add the i2c bitbang bus;
* Add the etherswitch/rtl8366rb drivers;
* "fix" the USB GPIO configuration so USB actually works.
Submitted by: Stefan Bethke <stb@lassitu.de>
The AP93 has:
* AR7240 - mips24k processor with integrated 10/100 switch and
various other peripherals;
* AR9283 - 2x2 2.4GHz 802.11n (with calibration data in flash);
* 64MB RAM;
* 16MB SPI flash.
The switch code detects as an AR8216 at the present moment, which isn't
_entirely_ strictly true. However, the MII/MDIO routing in AP93.hints
works - the arge0 MAC connects to PHY4 in the switch, but via the
switch internal MDIO bus. The switch connects to arge0's MDIO bus,
but only to export the switch registers.
Thanks to stb and ray for the switch work, and ray for helping determine
what the correct switch hints should be for this thing.
some of the IPI mechanisms used by the common MIPS SMP code so we could use
the multicast IPI facilities, on GXemul as well as on several real hardware
platforms, and the ability to have multiple hard IPI types.
This seems to break at least my test board here (AR71xx + AR8316 switch
PHY). Since I do have a whole sleuth of "normal" PHY boards (with
an AR71xx on a normal PHY port), I'll do some further testing with those
to determine whether this is a general issue, or whether it's limited
to the behaviour of the "fake" dedicated PHY port mode on these atheros
switches.
code and which had only stub implementations or no implementation on all
platforms. Makes gxemul compile.
Hinted by: rwatson
MFC after: 3 weeks
X-MFC by: rwatson:
1) Always implement missing bus space methods using a panic() stub rather
than a NULL pointer. This appeared not to trip up any existing device
drivers, but due to the nature of the devices I'm supporting locally,
I'm making use of some of the more obscure busspace methods, and
panic() is a preferred failure mode. For example, do this for the
setregion methods.
2) Hook up several existing busspace method implementations that were
provided in the file, but not actually present in the methods
structure. Especially, single-byte bus I/O routines. This should
allow bugs to be fixed in the Atheros 802.11 driver.
There are still some remaining unimplemented methods that would be
desirable to implement -- especially, 64-bit I/O calls that would
observably accelerate device performance on FPGA-based soft CPU cores
that are typically clocked an order of magnitude slower than
conventional hard core CPUs, but that remains for another day.
MFC after: 3 weeks
Discussed with: jmallett, scottl
Sponsored by: DARPA, AFRL
entirely of one machdep file lifted from the MALTA port, as well as
a low-level console and tty driver for the gxemul debugging console
device (the emulators stdio). As with many low-level embedded and
hypervisor console devices, it is polled only, so we drive TTY I/O
from a callout; we are perhaps a bit too aware of the MIPS physical
maps in order to attach the console before newbus comes to life.
The sample kernel configuration depends on an MD-based root file
system, which is not provided. However, any 64-bit, big-endian
userspace image (such as one generated for MALTA) should work.
This will hopefully be supplemented by additional device drivers for
gxemul-specific hardware simulations from Juli Mallett. We have
found oldtestmips quite useful for testing and improving aspects of
the MIPS port, so it's worth supporting better in FreeBSD.
Requested by: theraven, jmallett
Sponsored by: DARPA, AFRL
MFC after: 3 weeks
* Flesh out the PLL configuration fetch function, which will return the PLL
configuration based on the unit number and speed.
* Remove the PLL speed config logic from the AR71xx/AR91xx chip PLL config
function - pass in a 'pll' value instead.
* Modify arge_set_pll() to:
+ fetch the PLL configuration
+ write the PLL configuration
+ update the MII speed configuration.
This will allow if_arge to override the PLL configuration as required.
Obtained from: Linux/Atheros/OpenWRT
* Add a new method to set the MII mode - GMII, RGMII, RMII, MII.
+ arge0 supports all four (two for non-Gige interfaces.)
+ arge1 only supports two (one for non-gige interfaces.)
* Set the MII clock speed when changing the MAC PLL speed.
+ Needed for AR91xx and AR71xx; not needed for AR724x.
Tested:
* AR71xx only, I'll do AR913x testing tonight and fix whichever issues
creep up.
TODO:
* Implement the missing AR7242 arge0 PLL configuration, but don't
adjust the MII speed accordingly.
* .. the AR7240/AR7241 don't require this, so make sure it's not set
accidentally.
Bugs (not fixed here):
* Statically configured arge speeds are still broken - investigate why
that is on the AP96 board. Autonegotiate is working fine, but there
still seems to be an occasionally heavy packet loss issue.
Obtained from: Linux/Atheros/OpenWRT
arge1 still works (it's the standalone PHY) but arge0 and the other switch
ports don't work. They're enumerated though, demonstrating that the
mdiobus abstraction is correctly working.
This is only done if the ARGE_MDIO option is included.
* Shuffle the arge MDIO bus into a separate device, that needs to be
probed early (use hint.argemdio.X.order=0)
* hint.arge.X.mdio now specifies which miiproxy to rendezvous with.
* Call MAC/MDIO bus init during MDIO attach, not arge attach.
This is done regardless:
* Shift the arge MAC and MDIO bus reset code into separate functions
and call it early during MDIO bus attach. It's required for
correct MDIO bus IO to occur on AR71xx/AR91xx devices.
* Remove the AR71xx/AR91xx centric assumption that there's only one
MDIO bus. The initial code mapped miibus0(arge0) and miibus1(arge1)
MII register operations to the MII0 (arge0) register space. The
AR724x (and later, upcoming chipsets) have two MDIO busses and
the second is very much in use.
TODO:
* since the multiphy behaviour has changed (where now a phymask of >1
PHY will still be enumerated), multiphy setups may be quite wrong.
I'll go and fix these so they still have a chance of working, at least.
until the switch PHY support appears in -HEAD.
Submitted by: Stefan Bethke <stb@lassitu.de>
The default priority is now '1000' rather than '0'. This may cause some
unforseen regressions.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: imp
ar724x_pci.c.
* Move out the code which populates the firmware into ar71xx_fixup.c
* Shuffle around the ar724x fixup code to match what the ar71xx fixup
code does.
I've validated this on an AR7240 with AR9285 on-board NIC. It doesn't
yet load, as the AR9285 EEPROM code needs to be made "flash aware."
TODO:
* Validate that I haven't broken AR71xx
* Test AR9285/AR9287 onboard NICs, complete with EEPROM code changes
* Port over the needed BAR hacks for AR7240, AR7241 and AR7242 from
Linux OpenWRT. The current WAR has only been tested on the AR7240
and I'm not sure the way the BAR register is treated is "right".
The "fixup" method here is right when setting the BAR for local access -
ie, the BAR address is either 0xffff (AR7240) or 0x1000ffff (AR7241/AR7242),
but the ath9k-fixup.c code (Linux OpenWRT) does this when setting the
initial "fixup" BAR. It then restores the original BAR.
I'll have to read the ar724x PCI bus glue to see what other special cases
await.
* arge0 doesn't (yet) work via the switch PHY ports; I'm not sure why.
* arge1 maps to the WAN port. That works.
TODO:
* The PLL register needs a different (non-default) value for Gigabit
Ethernet. The board setup code needs to be extended a bit to allow
for non-default pll_1000 values - right now, those values come out
of hard-coded values in the per-chip set_pll_ge() routines.
Obtained from: Linux / OpenWRT
This uses the new firmware(9) method for squirreling away the EEPROM
contents from SPI flash so ath(4) can get to them later.
It won't work out of the box just yet - you have to add this to
if_ath_pci.c:
#define ATH_EEPROM_FIRMWARE
.. until I've added it as a configuration option and updated things.
future use by the ath(4) driver.
These embedded devices put the calibration/PCI bootstrap data on the
on board SPI flash rather than on an EEPROM connected to the NIC.
For some boards, there's two NICs and two sets of EEPROM data in the
main SPI flash.
The particulars:
* Introduce ath_fixup_size, which is the size of the EEPROM area in
bytes.
* Create a firmware image with a name based on the PCI device identifier
(bus/slot/device/function).
* Hide some verbose debugging behind 'bootverbose'.
ath(4) can then use this to load in the EEPROM data.
This requires AR71XX_ATH_EEPROM to be defined.
* the openwrt code doesn't treat 0/0/0 any differently
from other bus/slot/func combinations.
* A "local write" function writes to the LCONF area, and
so I've added it.
* The PCI workaround at attach time uses this LCONF code,
which it already did ..
* .. but it is a 4 byte write, not a 2 byte write.
Even though it's PCIR_COMMAND which is a two byte PCI register.
Tested on: AR7161
TODO: The other two AR71xx derivatives
TODO: More thoroughly stare at the datasheets I do have
and if it indeed is incorrect, push fixes to both
FreeBSD and Linux/OpenWRT.
Obtained from: Linux OpenWRT
This makes our naming scheme more closely match other systems and the
expectations of much third-party software. MIPS builds which are little-endian
should require and exhibit no changes. Big-endian TARGET_ARCHes must be
changed:
From: To:
mipseb mips
mipsn32eb mipsn32
mips64eb mips64
An entry has been added to UPDATING and some foot-shooting protection (complete
with warnings which should become errors in the near future) to the top-level
base system Makefile.
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.
XXX It would be good to use a better way to size intrcnt.
o) Fix literal 4s that are supposed to be sizeof (u_long).
XXX Why the * 2 here? Is this an artifact of a different system that this
code came from? We seem to allocate twice as much space for intrcnt
as we admit to in sintrcnt.
platforms.
This will make every attempt to mount a non-mpsafe filesystem to the
kernel forbidden, unless it is expressely compiled with
VFS_ALLOW_NONMPSAFE option.
This patch is part of the effort of killing non-MPSAFE filesystems
from the tree.
No MFC is expected for this patch.
o) Get rid of some unused macros related to features we don't intend to
provide.
o) Get rid of macro definitions for MIPS-I CPUs. We are not likely to
support anything that predartes MIPS-III.
o) Respell MIPS3_* macros as MIPS_*, which is how most of them were being
used already.
o) Eliminate a duplicate and mostly-unused set of exception vector macros.
There's still considerable duplication and lots more obsolete in our headers,
but this reduces one of the larger files to a size where one could reckon
about the correctness of its contents with a mere few hours of contemplation.
There is, of course, a question of whether we need definitions for fields,
registers and configurations that we are unlikely to ever use or implement,
even if they're not obsolete since 1991. FreeBSD is not a processor
reference manual, and things that aren't used may be wrong, or may be
duplicated because nobody could possibly actually know whether they're
already defined.
the native sigreturn doesn't use set_mcontext like the COMPAT_FREEBSD32 version
does, this wouldn't actually result in overwriting the TLS base. Probably it
makes sense to restructure the native sigreturn to use set_mcontext for
consistency, and to allow sigreturn to change the TLS base.
TLS:
o) The mc_tls field used to store the TLS base when doing context gets and
restores was left a pointer and not converted to a 32-bit integer. This
had the bug of not correctly capturing the TLS value desired by the user,
and the extra nastiness of making the structure the wrong size.
o) The mc_tls field was not being saved by sendsig. As a result, the TLS base
would always be set to NULL when restoring from a signal handler.
Thanks to gonzo for helping track down a bunch of other TLS bugs that came out
of tracking these down.
and offset it only if requested by RDHWR handler. Otherwise things
get overly complicated - we need to track whether address passsed in
request for setting td_md.md_tls is already offseted or not.
version was missing an else and would always use the n64 TP_OFFSET. Eliminate
some duplication of logic here.
It may be worth getting rid of some of the ifdefs and introducing gratuitous
SV_ILP32 runtime checks on n64 kernels without COMPAT_FREEBSD32 and on o32
kernels, similarly to how PowerPC works.
using the o32 ABI. This mostly follows nwhitehorn's lead in implementing
COMPAT_FREEBSD32 on powerpc64.
o) Add a new type to the freebsd32 compat layer, time32_t, which is time_t in the
32-bit ABI being used. Since the MIPS port is relatively-new, even the 32-bit
ABIs use a 64-bit time_t.
o) Because time{spec,val}32 has the same size and layout as time{spec,val} on MIPS
with 32-bit compatibility, then, disable some code which assumes otherwise
wrongly when built for MIPS. A more general macro to check in this case would
seem like a good idea eventually. If someone adds support for using n32
userland with n64 kernels on MIPS, then they will have to add a variety of
flags related to each piece of the ABI that can vary. That's probably the
right time to generalize further.
o) Add MIPS to the list of architectures which use PAD64_REQUIRED in the
freebsd32 compat code. Probably this should be generalized at some point.
Reviewed by: gonzo
handle address, where we're using handles as raw addresses.
This fixes devices with subregions on Octeon PCI specifically, and likely also on
MIPS more generally, where there isn't another bus_space in use that was doing the
math already.
long for specifying a boundary constraint.
- Change bus_dma tags to use bus_addr_t instead of bus_size_t for boundary
constraints.
These allow boundary constraints to be fully expressed for cases where
sizeof(bus_addr_t) != sizeof(bus_size_t). Specifically, it allows a
driver to properly specify a 4GB boundary in a PAE kernel.
Note that this cannot be safely MFC'd without a lot of compat shims due
to KBI changes, so I do not intend to merge it.
Reviewed by: scottl
- Reserver respective number of addresses for managment port
- octm uses base address directly
- other drivers get MACs on "first come first served" basis
Reviewed by: juli
- Centralize address assignment
- Make sure managment ports get first MAC address in pool
- Properly propagate fail if address allocation failed
Submitted by: Andrew Duane <aduane@juniper.net>
set all three of the kernel, supervisor, and user-mode 64-bit mode
flags. While FreeBSD does not currently use the supervisor ring (and
hence this is effectively a NOP on most systems), doing this avoids
triggering an exception on 64-bit MIPS CPUs that don't support 32-bit
compatibility mode, and therefore don't allow clearing the SX bit.
Reviewed by: gonzo
MFC after: 3 days
Sponsored by: DARPA, SRI International
Reading register $29 with RDHWR is becoming the de-facto standard to
implement TLS. According to linux-mips wiki, MIPS Technologies has
reserved hardware register $29 for ABI use. Furthermore current GCC
makes the following assumptions:
- RDHWR is natively available or otherwise emulated by the kernel
- Register $29 holds the TLS pointer
Submitted by: Robert Millan <rmh@debian.org>
of root HUB. Although it is initialized with port index of the
device's parent hub, which is worng. So track the USB tree up to
root HUB and initialize this filed ptroprly
Rename port_index to root_port_index in order to reflect its
real semantics.
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.
- Use Elf32_Addr as default, the only field that is
64 bitw wide is R_MIPS_64
- Add R_MIPS_HIGHER and R_MIPS_HGHEST handlers
- Handle R_MIPS_HI16 and R_MIPS_LO16 for both .rel and
.rela sections
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.
comparing to struct timeval. for clocktime they should be
1..7 and 1..12 respectively
- CAPK-0100ND uses RTC without centruy bit (DS1307) so set it 21st
This is an AR71xx based board with 8MB flash, 64MB RAM, a
Mini-PCI+ slot (see below) and a single 10/100/1000baseT
ethernet port. It also has two USB ports.
This is an easier board than most to add as it doesn't have a
switch PHY on-board. This made it (mostly) trivial to craft a
working configuration.
Things to note:
* This, like most other reference boards, use uboot rather then
redboot. It means that you typically have to manually flash
both the kernel and rootfs partitions.
* Since there's currently no (nice) way to extract out the
ethernet MAC and RAM from the uboot environment, the RAM
will default to 32mb and the MAC will be something very
incorrect. I'll try to fix this up in a subsequent commit
or two, even if it's just some hard-coded nonsense in
ar71xx_machdep.c for now.
* The board is designed for a specific model of mini-PCI+
NIC which never made it into production. Normal mini-PCI
NICs will work fine; if you happen to have the NIC in question
then it will work fine with this board.
bits.
The ROUERSTATION and RSPRO variants contain:
* the board specific bits (eg the RTC for RSPRO, later on it'll
include the GPIO/LED definitions);
* the boot specific bits (eg, on-board flash, usb flash, etc).
For now the AR71XX_BASE file contains the common board config,
drivers and net80211/ath wireless drivers.
I'll follow this up with config files for the other boards I
have (eg the Ubiquiti LSSR71, as well as some Mikrotik boards
that use the AR71XX and atheros reference boards) which will
be quite easy to do now.
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.
At the moment grab and ungrab methods of all console drivers are no-ops.
Current intended meaning of the calls is that the kernel takes control of
console input. In the future the semantics may be extended to mean that
the calling thread takes full ownership of the console (e.g. console
output from other threads could be suspended).
Inspired by: bde
MFC after: 2 months
* Add in a default GPIO section for AR91XX_BASE.hints, which doesn't
define the GPIO function masks or any GPIO pines.
* Add in the GPIO line definitions for LEDs and GPIO pins for the
TP-WR1043nd.
I've verified the LEDs work fine using gpioset.
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 second-last 64k seems to be the default firmware board configuration
area.
Since I have no idea whether uboot uses it or not - and it's prefixed
with an atheros eeprom signature (0xaa55), I figure the safest thing
to do is mark it as read-only.
I've modified my local tplink firmware building program to generate
a board configuration section - which is separate to this partition.
It's located in the 64k _before_ this particular 64k.
The firmware build program from OpenWRT never initialises those
values and the firmware images from tplink also leave it 0x0, so I
don't currently know what the exact, correct details should be.
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.
The default flash layout gives only 1 megabyte for the kernel, gzipped.
The uboot firmware running on this device only supports gzip, not lzma, so
we actually _do_ have to try and slim the kernel down a bit.
But, since I can't actually do that at the present, I'm opting to:
* extend the kernel from 1mb to 2mb;
* have rootfs fill the rest of that, save 64k;
* eventually I'll hide a 64k config partition at the end, between the
end of rootfs and the ART (radio configuration data.)
The uboot firmware doesn't care about the partition layout. It just
expects the kernel application image to sit at 0xbf020000 (right after
the 128k uboot image.) The uboot header isn't actually read either -
it's "faked" from a "tplink" flash image header. So as long as the
map configuration here matches what is being written out via the
tplink firmware generator, everything is a-ok.
A previous commit disabled compiling the AR9130 support in the default
HAL build in the kernel. Since the AR9130 support won't actually function
without AH_SUPPORT_AR9130 (and that abomination needs to be undone at some
point, in order to allow USB 11n NICs to also work), we now have to
explicitly compile it in.
But since the 11n RF backends don't (currently) join the RF linker set,
one has to compile in _an_ RF backend for the HAL to compile.
At some point it would be nice to correctly update the bus glue to make
this "correct", including having the DDR flush occur in the right spot
(ie, any AHB interrupt.)
