sizes are not supported.
o Map the PBVM page table.
o Map the PBVM using the largest possible power of 2 that is less than
the amount of PBVM used and round down to a valid page size. Note
that the current kernel is between 8MB and 16MB in size, which would
mean that 8MB would be the typical size of the mapping, if only 8MB
wasn't an invalid page size. In practice, we end up mapping the first
4MB of PBVM in most cases.
o The bootinfo structure is now a virtual pointer.
o Replace VM_MAX_ADDRESS with VM_MAXUSER_ADDRESS and redefine
VM_MAX_ADDRESS as the maximum address possible (~0UL).
o Since we're not using direct-mapped translations, switching
to physical addressing is less trivial. Reserve the boot stack
for running in physical mode and special-case the EFI call,
as we're still on the boot stack.
o Region 4 belongs to the kernel now, not process space.
also does this for sound drivers it's probably not necessary for all
combinations of controllers and drivers. However, given that our sound
drivers completely lack bus_dmamap_sync(9) calls this at least serves
as a workaround when enabling use of the IOMMU streaming buffers on
sparc64 and generally for arm and mips.
MFC after: 2 weeks
between kernel virtual address and physical address anymore. This so
that we can link the kernel at some virtual address without having
to worry whether the corresponding physical memory exists and is
available. The PBVM uses 64KB pages that are mapped to physical
addresses using a page table. The page table is at least 1 EFI page
in size, but can grow up to 1MB. This effectively gives us a memory
size between 32MB and 8GB -- i.e. enough to load a DVD image if one
wants to.
The loader assigns physical memory based on the EFI memory map and
makes sure that all physical memory is naturally aligned and a power
of 2. At this time there's no consideration for allocating physical
memory that is close to the BSP.
The kernel is informed about the physical address of the page table
and its size and can locate all PBVM pages through it.
The loader does not wire the PBVM page table yet. Instead it wires
all of the PBVM with a single translation. This is fine for now,
but a follow-up commit will fix it. We cannot handle more than 32MB
right now.
Note that the loader will map as much of the loaded kernel and
modules as possible, but it's up to the kernel to handle page faults
for references that aren't mapped. To make that easier, the page
table is mapped at a fixed virtual address.
o Move the backing store in the top half of region 0 now that
region 4 is re-assigned to be part of the kernel.
o De-emphasize VM_MAX_ADDRESS. It's really not used anywhere and probably
means something different than the limit for process address space (we
have VM_MAXUSER_ADDRESS for that).
o Exclude the gateway page from VM_MAXUSER_ADDRESS (i.e. make it the same
as VM_MAX_ADDRESS).
- Emitt an error when encountering an unsupported and in case of the
kernel also for unaligned relocations.
- Fix R_SPARC_LOX10 relocations. Apparently these are hardly ever used.
- Add the _RF_X committed in r212998 also to the tables in the sparc64
reloc.c in order reduce differences between the kernel and the userland
source. This results in no functional change though.
- Fix further inconsistencies in the abbreviations of the names of the
relocations.
- Further whitespace fixes.
Obtained from: NetBSD [1]
This is a minor cosmetic change - the users are more likely to want to
increase (rather than decrease) default kernel stack size,
which is already 4 pages on amd64.
MFC after: 4 days
Linux ath9k.
The ath9k ar9002_hw_init_cal() isn't entirely clear about what
is supposed to be called for what chipsets, so I'm ignoring the
rest of it and just porting the AR9285 init cal path as-is and
leaving the rest alone. Subsequent commits may also tidy up the
Merlin (AR9285) and other chipset support.
Obtained from: Linux ath9k
The ath9k driver has a unified boundary/pdadc function, whereas
ours is split into two (one for each EEPROM type.) This is why
the AR9280 check is done here where we could safely assume it'll
always be AR9280 or later.
this is incorrect for Kite (AR9285) and any future chipsets that
override the EEPROM related routines.
It meant that a direct call to set the TX power would call the v14 EEPROM
AR5416/AR9280 calibration routines, rather than the v4k EEPROM routines
for the AR9285. It thus read the incorrect values from the EEPROM and
programmed garbage PDADC and TX power values into the hardware.
adjust the IEEE80211_HTRATE_MAXSIZE constant, only MCS0 - 76 are valid
the other bits in the mcsset IE (77 - 127) are either reserved or used
for TX parameters.
o bunch of variables are turned into uint8_t
o initial setting of namep[] in lookup() is removed
as it's only overwritten a few lines down
o kname is explicitly initialized in main() as BSS
in boot2 is not zeroed
o the setting and reading of "fmt" in load() is removed
o buf in printf() is made static to save space
Reviewed by: jhb
Tested by: me and Fabian Keil <freebsd-listen fabiankeil de>
It looks like these apply in both open and closed loop TX power control,
but the only merlin boards i have either have OL -or- a non-default power
offset, not both.
to both make things clearer, and to make it easier to write userland
code which pulls in these definitions without needing to pull in the
rest of the HAL.
This stuff should be deprecated at some point in the future once
the net80211 regulatory domain support encapsulates all of the
defintions here.
This is something bus clock related from what I can gather. It is needed for
the AR9220 based Ubiquiti SR71-12 and SR71-15 Mini-PCI NICs.
(Note: those NICs don't work right now because of earlier changes to handle
power table offset correctly. That'll be resolved in a follow-up commit.)
