* add EARLY_PRINTF for debugging
* update module list to be much larger
* add random, otherwise well, stuff doesn't work.
* IPFIREWALL_DEFAULT_TO_ACCEPT
Tested:
* AP93 (AR7240 + AR9280)
TODO:
* rename to std.AR724X
* unify the built module list between all of the mips24k/mips74k atheros config files -
now that the HAL, hwpmc, USB, etc are per-chip/per-arch modules it is easy to just
compile them all and only include the ones you care about.
* Map change: create a combined kernel+rootfs image. The instructions I'll post
on the wiki (which will be for a very outdated dev board, but at least will
explain the what/why for posterity) will include how to reset the boot command.
Tested:
* AP93 dev board (AR7240 + AR9280)
- Fix typo of PLL Type 4
- Don't panic of frequency getters
Submitted by: Hiroki Mori <yamori813@yahoo.co.jp>
Differential Revision: https://reviews.freebsd.org/D10967
The (eventually) upcoming ath(4) changes will include being able to load
ath(4) devices on the AHB bus (ie the on-die wifi part of the SoC)
as modules.
In order for this to happen, a copy of the calibration data needs to be
copied away before the SPI driver runs or the memory map access hack
won't work.
Now, ideally (!) there'd be some driver that can come up after the MTD
pieces (eg, SPI, NAND, etc) and load into a firmware chunk the calibration
data.
(Or, really really nicely, would be an actual async firmware API that
would lead itself to having a driver schedule a file read - or a raw device
read - to get to the calibration data.)
Now, until all of the above is done - I'm going to perpetuate the layer
breaking atrocity here by simply doing the PCI bus fixup EEPROM/calibration
data hack here. This will work for any AR71xx (and later on, AR231x/AR531x)
device, as well as the handful of QCA MIPS + QCA9880v2 802.11ac boards with
NOR flash.
To use, this goes into the kernel config:
# Enable EEPROM hacks
options AR71XX_ATH_EEPROM
device ar71xx_caldata
device firmware
# This enables the ath_ahb driver (when I commit the change!) to
# pull data out of the firmware hack.
options ATH_EEPROM_FIRMWARE
In the hints file:
# ART calibration data mapping device
hint.ar71xx_caldata.0.at="nexus0"
hint.ar71xx_caldata.0.order=0
# Where the ART is - last 64k in the first 8MB of flash
hint.ar71xx_caldata.0.map.0.ath_fixup_addr=0x1fff0000
hint.ar71xx_caldata.0.map.0.ath_fixup_size=16384
# And now tell the ath(4) driver where to look!
hint.ath.0.eeprom_firmware="ar71xx_caldata.0.map.0.eeprom_firmware"
Tested:
* carambola2, AR933x SoC, using a set of ath and ath_hal modules to load
TODO:
* unify this bit of firmware loading code, as I will definitely need
to include both the PCI bus firmware version (for PCI ID fixups too!)
as well as AHB/on-chip calibration data.
* Commit the ath_ahb bus code
* Convert .. everything over. That'll take the majority of the time.
A long long time ago the register keyword told the compiler to store
the corresponding variable in a CPU register, but it is not relevant
for any compiler used in the FreeBSD world today.
ANSIfy related prototypes while here.
Reviewed by: cem, jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D10193
This patch improves the boundary checks in busdma to allow more cases
using the regular page based kernel memory allocator. Especially in
the case of having a non-zero boundary in the parent DMA tag. For
example AMD64 based platforms set the PCI DMA tag boundary to
PCI_DMA_BOUNDARY, 4GB, which before this patch caused contiguous
memory allocations to be preferred when allocating more than PAGE_SIZE
bytes. Even if the required alignment was less than PAGE_SIZE bytes.
This patch also fixes the nsegments check for using kmem_alloc_attr()
when the maximum segment size is less than PAGE_SIZE bytes.
Updated some comments describing the code in question.
Differential Revision: https://reviews.freebsd.org/D10645
Reviewed by: kib, jhb, gallatin, scottl
MFC after: 1 week
Sponsored by: Mellanox Technologies
- Save the current FIR in the global 'cpuinfo' structure in a new
'fpu_id' member.
- Decode flags in the FIR when displaying other CPU flags during boot.
- Use the existing "dummy" slot in the floating point register structure
to export the FIR in process core dumps and via ptrace(). Note that
while the FIR register is not volatile, this practice of storing the FIR
in the floating-point register set is used in other OS's.
Reviewed by: kan
MFC after: 1 month
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D10617
* Target module have ic plus etherswitch ip175c.
* Also add etherswitch support code on rt driver.
Reviewed by: mizhka
Differential Revision: https://reviews.freebsd.org/D10336
Tested:
* on IOData WN-G300R. may be same as Sitecom WLR-2100.
Submitted by: Hiroki Mori <yamori813@yahoo.co.jp>
Differential Revision: https://reviews.freebsd.org/D10621
* use ifqmaxlen
* handle (inefficiently for now) meeting padding and alignment requirements for
transmit mbufs.
* change how TX ring handling is done
Submitted by: Hiroki Mori <yamori813@yahoo.co.jp>
Differential Revision: https://reviews.freebsd.org/D10557
BHND_EROM_DUMP() method.
Dump the EROM tables to the coneole on mips/broadcom devices if bootverbose
is enabled; this functionality is primarily useful when debugging SoC EROM
parsing and device matching issues during early boot.
Reviewed by: mizhka
Approved by: adrian (mentor)
Sponsored by: Plausible Labs
Differential Revision: https://reviews.freebsd.org/D10122
in place. To do per-cpu stats, convert all fields that previously were
maintained in the vmmeters that sit in pcpus to counter(9).
- Since some vmmeter stats may be touched at very early stages of boot,
before we have set up UMA and we can do counter_u64_alloc(), provide an
early counter mechanism:
o Leave one spare uint64_t in struct pcpu, named pc_early_dummy_counter.
o Point counter(9) fields of vmmeter to pcpu[0].pc_early_dummy_counter,
so that at early stages of boot, before counters are allocated we already
point to a counter that can be safely written to.
o For sparc64 that required a whole dummy pcpu[MAXCPU] array.
Further related changes:
- Don't include vmmeter.h into pcpu.h.
- vm.stats.vm.v_swappgsout and vm.stats.vm.v_swappgsin changed to 64-bit,
to match kernel representation.
- struct vmmeter hidden under _KERNEL, and only vmstat(1) is an exclusion.
This is based on benno@'s 4-year old patch:
https://lists.freebsd.org/pipermail/freebsd-arch/2013-July/014471.html
Reviewed by: kib, gallatin, marius, lidl
Differential Revision: https://reviews.freebsd.org/D10156
The MFC will include a compat definition of smp_no_rendevous_barrier()
that calls smp_no_rendezvous_barrier().
Reviewed by: gnn, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D10313
I fixed this in 1997, but the fix was over-engineered and fragile and
was broken in 2003 if not before. i386 parameters were copied to 8
other arches verbatim, mostly after they stopped working on i386, and
mostly without the large comment saying how the values were chosen on
i386. powerpc has a non-verbatim copy which just changes the uncritical
parameter and seems to add a sign extension bug to it.
Just treat negative offsets as offsets if they are no more negative than
-db_offset_max (default -64K), and remove all the broken parameters.
-64K is not very negative, but it is enough for frame and stack pointer
offsets since kernel stacks are small.
The over-engineering was mainly to go more negative than -64K for the
negative offset format, without affecting printing for more than a
single address.
Addresses in the top 64K of a (full 32-bit or 64-bit) address space
are now printed less well, but there aren't many interesting ones.
For arches that have many interesting ones very near the top (e.g.,
68k has interrupt vectors there), there would be no good limit for
the negative offset format and -64K is a good as anything.
Add support for early boot access to NVRAM variables, using a new
bhnd_nvram_data_getvar_direct() API to support zero-allocation direct
reading of NVRAM variables from a bhnd_nvram_io instance backed by the
CFE NVRAM device.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D9913
This adds support for matching against a core lookup table when performing
early boot core lookup, and includes the BCM4706/Northstar-specific
ChipCommon core ID in the set of supported ChipCommon cores.
Approved by: adrian (mentor)
Differential Revision: https://reviews.freebsd.org/D10033
While there, parse u-boot provided command line arguments
for supported switches and update boothowto appropriately.
Also support setting kenv variables from the kernel comman
line.
PR: 216831 (modified)
as kernel drivers and their dependency onto mmc(4); this allows for
incrementing the mmc(4) module version but also for entire omission
of these bridge declarations for mmccam(4) in a single place, i. e.
in dev/mmc/bridge.h.
comments, marking unused parameters as such, style(9), whitespace,
etc.
o In the mmc(4) bridges and sdhci(4) (bus) front-ends:
- Remove redundant assignments of the default bus_generic_print_child
device method (I've whipped these out of the tree as part of r227843
once, but they keep coming back ...),
- use DEVMETHOD_END,
- use NULL instead of 0 for pointers.
o Trim/adjust includes.
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
Make the random number generator work so we can do WPA encryption on the AP's.
Submitted by: Michael Vale <m.vale@live.com.au>
Pull Request: https://github.com/freebsd/freebsd/pull/16
This is required for FDT's standard "reg-io-width" property
(similar to "reg-shift" property) found in many DTS files.
This fixes operation on Altera Arria 10 SOC Development Kit,
where standard ns8250 uart allows 4-byte access only.
Reviewed by: kan, marcel
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D9785
Convert PCIe hot plug support over to asking the firmware, if any, for
permission to use the HotPlug hardware. Implement pci_request_feature
for ACPI. All other host pci connections to allowing all valid feature
requests.
Sponsored by: Netflix
Stop building BERI_DE4_BASE and BERI_SIM_BASE, they aren't particularly
valid as they don't have a root dev. Do build BERI_DE4_SDROOT which
does so devices get coverage.
Remove ident from BERI_DE4_BASE for the reasons above which will cause
it to fail to build. BERI_SIM_BASE was already this way and broke
universe.[0]
Reported by: rpokala
Sponsored by: DARPA, AFRL
Implement get_pcpu() for amd64/sparc64/mips/powerpc, and use it to
replace pcpu_find(curcpu) in MI code.
Reviewed by: andreast, kan, lidl
Tested by: lidl(mips, sparc64), andreast(powerpc)
Differential Revision: https://reviews.freebsd.org/D9587
