Commit Graph

32 Commits

Author SHA1 Message Date
Landon J. Fuller
ff29b85a34 Replace mips/sentry5 with mips/broadcom
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
2016-06-25 04:34:54 +00:00
Adrian Chadd
85b543e06d Populate hw.model with the CPU model information.
Now you see something like:

# sysctl hw.model
hw.model: Atheros AR9330 rev 1

Tested:

* Carambola 2, AR9331 SoC
2015-07-14 05:14:10 +00:00
Adrian Chadd
b7d7ad0b90 Begin moving support for board MAC addresses over to being explicitly defined.
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:Dx: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.
2015-03-28 23:40:29 +00:00
Davide Italiano
2be111bf7d Follow up to r225617. In order to maximize the re-usability of kernel code
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
2014-10-16 18:04:43 +00:00
Luiz Otavio O Souza
b7c7433150 Add support for reading RouterBoard's memory which is passed by the loader
(RouterBOOT).

Tested on RouterBoards, various and on RSPRO, TP-Link MR3x20
(for regressions).
2014-05-09 14:02:18 +00:00
Adrian Chadd
8c56b727e4 Fix the Atheros MIPS startup path a little.
* Print out the platform frequency the same as the other frequencies.
* Print out the MDIO frequency.
* Optionally do GMAC and ethernet switch setup if required.

Tested:

* AR9344
2013-10-15 01:37:00 +00:00
Adrian Chadd
600f8cb57a Print out the platform reference frequency.
This is useful for AR933x platforms where that matters.
2013-03-29 06:31:31 +00:00
Juli Mallett
312af517e3 Remove platform APIs which are not used by any code and which had only stub
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.
2012-03-12 07:34:15 +00:00
Adrian Chadd
a2d4a78a47 Stop overloading opt_global.h. 2012-01-16 05:07:32 +00:00
Adrian Chadd
1c3ed0a410 Introduce a new (global, sorry!) option which controls whether
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.
2011-11-24 07:32:52 +00:00
Kevin Lo
281f0ca8e7 Remove duplicate header includes 2011-06-26 10:07:48 +00:00
Adrian Chadd
3c14a0e3fb The previous commit didn't completely rename this to what it should be. 2011-03-28 09:10:59 +00:00
Adrian Chadd
01754fac52 Refactor out the ar71xx mac address code into something that's
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.
2011-03-27 13:55:35 +00:00
Adrian Chadd
c720b9bd9e Add an option - AR71XX_REALMEM - which overrides the amount of
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.
2011-03-27 08:44:27 +00:00
Oleksandr Tymoshenko
99629fa36d - Populate dump_avail with proper values from phys_avail 2010-12-09 07:01:03 +00:00
Andrew Thompson
08e58cc093 Make a note of which platforms the mac strings come from.
Suggested by:	adrian
2010-09-17 01:13:48 +00:00
Andrew Thompson
3441a301f2 Use getenv to find the mac address since it could be in the bootloader
environment or command line and under different names.
2010-09-17 01:09:12 +00:00
Adrian Chadd
292899c376 Remove now unused 'reg'. 2010-08-19 02:15:39 +00:00
Adrian Chadd
6f96ebf309 Initialise the USB system using cpuops rather than the AR71XX specific method. 2010-08-19 02:14:53 +00:00
Adrian Chadd
1d11005672 Migrate the CPU reset path to use the new cpuops. 2010-08-19 02:12:04 +00:00
Adrian Chadd
70bd9230d1 Preparation work for supporting the AR91xx and AR724x.
* 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
2010-08-19 02:03:12 +00:00
Oleksandr Tymoshenko
d86043b594 - Call post-boot fixup function in order to get proper static
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
2010-01-25 00:44:05 +00:00
Warner Losh
657a57d730 Update from old DDB convetion to initialize debugger to new KDB way.
Always call kdb_init().  If we have KDB enabled, then provide a handy
place to break to the debugger.
2010-01-23 00:18:12 +00:00
Warner Losh
3ad9e328b8 Rename mips_pcpu_init to mips_pcpu0_init since it applies only to the
BSP.  Provide a missing prototype.
2010-01-09 03:08:22 +00:00
Warner Losh
a096e4b36b Centralize initialization of pcpu, and set curthread early... 2010-01-08 22:48:21 +00:00
Randall Stewart
8fae280afb With this commit our friend RMI will now compile. I have
not tested it and the chances of it running yet are about
ZERO.. but it will now compile. The hard part now begins,
 making it run ;-)
2009-10-30 08:53:11 +00:00
Andrew Thompson
3c2330f2e4 Parse and save the command line passed in from RedBoot (exec -c "xxx") and also
the board specific environment variables.

This is not ar71xx specific and should be shared better.
2009-10-28 21:27:56 +00:00
Oleksandr Tymoshenko
61bfa4ba5d - Move CPU/AHB frequency calculations to functions to
prevent code duplication
2009-07-09 20:11:26 +00:00
Oleksandr Tymoshenko
f92ba06830 - ar71xx increases Count value every two cycles 2009-05-19 02:51:30 +00:00
Oleksandr Tymoshenko
89616da3f5 - Get memory size and base MAC address from RedBoot (if available) 2009-05-16 02:43:24 +00:00
Oleksandr Tymoshenko
b31707c849 - Calculate CPU frequency using dividers from PLL registers 2009-05-15 01:53:09 +00:00
Oleksandr Tymoshenko
fd7391fc0c - Revert changes accidentally killed by merge operation 2009-04-14 22:53:22 +00:00