| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
to the actual handler routine. All the pointers are static-intialized to
the only handlers available, and yet various platform-specific inits still
set those pointers (to the values they're already initialized to). Begin
to drain the swamp by removing all the redundant external declarations and
runtime setting of the pointers that's scattered around various places.
|
| |
|
|
|
|
|
| |
routine compiled in, print a friendly error message about it rather than
mysteriously hanging while trying to init 4GB of nonexistant ram.
|
|
|
|
| |
in common code now.
|
|
|
|
|
|
|
|
|
|
|
| |
communicate the kernel's physical load address from where it's known in
initarm() into cpu_mp_start() which is called from non-arm code and
takes no parameters.
This adds the global variable and ensures that all the various copies
of initarm() set it. It uses the variable in cpu_mp_start(), eliminating
the last uses of KERNPHYSADDR outside of locore.S (where we can now
calculate it instead of relying on the constant).
|
|
|
|
|
| |
at runtime) where it's trivial to do so. Another breadcrumb on the trail
to a kernel that can be loaded at any 1MB boundary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a new physmem.c file. The new code provides helper routines that can be
used by legacy SoCs and newer FDT-based systems. There are routines to
add one or more regions of physically contiguous ram, and exclude one or
more physically contiguous regions of ram. Ram can be excluded from crash
dumps, from being given over to the vm system for allocation management,
or both. After all the included and excluded regions have been added,
arm_physmem_init_kernel_globals() processes the regions into the global
dump_avail and phys_avail arrays and realmem and physmem variables that
communicate memory configuration to the rest of the kernel.
Convert all existing SoCs to use the new helper code.
|
|
|
|
| |
remove the need to load the kernel at a fixed address.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
devices. This is a nop, except for what's reported by atmelbus for the
resources.
It would be nice if we could dymanically allocated these things, but
the pmap_mapdev panics if we don't keep the static mappings, so we
still need to play the carefully allocate VA space between all
supported SoC game.
User's with their own devices may need to make adjustments.
|
|
|
|
|
|
|
|
|
|
| |
vm_max_virtual_address to be KERNVIRTADDR + 256MB. This allows some
future shock protection since the KVA requirements have gone up since
the unmapped changes have gone in, as well as preventing us from
overlapping with the hardware devices, which we map at 0xd0000000,
which we'd hit with anything more than 85MB...
MFC after: 3 days
|
|
|
|
|
|
|
| |
the common FDT-aware initarm() in arm/machdep.c.
Pointed out by: cognet
Pointy hat to: ian
|
|
|
|
|
|
|
| |
new devmap.[ch] files. Emphasize the MD nature of these things by using
the prefix arm_devmap_ on the function and type names (already a few of
these things found their way into MI code, hopefully it will be harder to
do by accident in the future).
|
|
|
|
|
| |
that the latter correctly fills in the clock data structures based on
proper hardware-specific shift and mask values from the soc_data structure.
|
|
|
|
| |
through vm/pmap.h.
|
|
|
|
|
|
|
|
| |
Remove unused inclusion of vm/vm_pager.h and vm/vnode_pager.h.
Sponsored by: EMC / Isilon storage division
Tested by: pho
Reviewed by: alc
|
|
|
|
|
|
|
|
| |
been included in r246926.)
The second parameter to pmap_bootstrap() is redundant. Eliminate it.
Reviewed by: andrew
|
| |
|
|
|
|
| |
initarm for FDT closer together. More to follow.
|
|
|
|
|
|
|
| |
On single core devices set_stackptrs is only ever called with cpu = 0 in
initarm and will be identical to the existing function. On SMP this needs
to be implemented for sys/arm/mp_machdep.c, but the implementations are
identical for each SoC.
|
|
|
|
|
|
|
|
|
| |
Cummulative patch of changes that are not vendor-specific:
- ARMv6 and ARMv7 architecture support
- ARM SMP support
- VFP/Neon support
- ARM Generic Interrupt Controller driver
- Simplification of startup code for all platforms
|
|
|
|
| |
Reviewed by: imp
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
having the CPU device that's a child of atmelarm that does stuff.
o Create a linker_set for the support fucntions for the SoCs.
o Rename soc_data to soc_info.
o Move the delay and reset function pointers to new soc_data struct
o Create elements for all known SoCs
o Add lookup of the SoC we found, and print a warning if it isn't one
we know about.
|
|
|
|
|
| |
have left enabled after we detect the CPU, and remove the multiplely
copied code from the SoC modules.
|
| |
|
|
|
|
|
|
| |
arm platform. Add all the atmel boards to the ATMEL kernel for
testing purposes. Until boot loader arg parsing of baord type
is done, this won't actually be able to do the runtime selection.
|
|
|
|
| |
first place).
|
| |
|
|
|
|
|
|
|
| |
aren't very pretty yet, but this takes DELAY and cpu_reset and makes
them pointers.
# I worry that these are set too late in the boot, especially cpu_reset.
|
|
|
|
|
| |
rearranging where we initialize the time counter and putting the
common stubs into a central place.
|
|
|
|
|
|
| |
this array either from Linux boot data, when enabled, or in the
typical way that most ports do it. arm_pyhs_avail_init is coming
soon since it must be a separate function.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the boot parameters from initarm first thing. parse_boot_param parses
the boot arguments and converts them to the /boot/loader metadata the
rest of the kernel uses. parse_boot_param is a weak alias to
fake_preload_metadata, which all the platforms use now, but may become
more extensive in the future.
Since it is a weak symbol, specific boards may define their own
parse_boot_param to interface to custom boot loaders.
Reviewed by: cognet@, Ian Lapore
|
|
|
|
|
| |
is not used in this part of the function and correctly initialised later
when it is used.
|
|
|
|
|
|
| |
common function.
Reviewed by: imp
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SoC variants. Fold the AT91SAM9XE chips into the AT91SAM9260
handling, where appropriate. The following SoCs/SoC families are recognized:
at91cap9, at91rm9200, at91sam9260, at91sam9261, at91sam9263,
at91sam9g10, at91sam9g20, at91sam9g45, at91sam9n12, at91sam9rl,
at91sam9x5
and the following variations are also recognized:
at91rm9200_bga, at91rm9200_pqfp, at91sam9xe, at91sam9g45, at91sam9m10,
at91sam9g46, at91sam9m11, at91sam9g15, at91sam9g25, at91sam9g35,
at91sam9x25, at91sam9x35
This is only the identification routine: no additional Atmel devices
are supported at this time.
# With these changes, I'm able to boot to the point of identification
# on a few different Atmel SoCs that we don't yet support using the
# KB920X config file -- someday tht will be an ATMEL config file...
|
|
|
|
|
|
| |
structure with the first 4 registers to allow a wider range of boot
loaders to work. Future commits will make use of this to centralize
support for the different loaders.
|
|
|
|
|
|
|
| |
console so initialized will work upon return from cninit. While this
is the very next line, other platforms setup all this stuff before
calling cninit. Also, initialize the SDRAM base register in the inner
block in at91_ramsize().
|
|
|
|
|
|
|
|
|
|
|
| |
compiled into the kernel. This allows us to boot the same kernel on
machines with different master clock frequencies, so long as we can
determine the main clock frequency accurately. Cleanup the pmc clock
init function so it can be called in early boot so we can use the
serial port just after we call cninit.
# We have two calls to at91_pmc_clock_init for reasons unknown, that will
# be fixed later -- it is harmless for now.
|
| |
|
|
|
|
|
|
|
| |
at91_machdep.c, and do it for the files I forgot the first time
Reported by: andrew
Submitted by: pluknet
|
| |
|
|
|
|
| |
to map and use the msgbuf.
|
|
|
|
|
|
|
| |
Submitted by: perryh pluto.rain.com (previous version)
Reviewed by: jhb
Approved by: kib (mentor)
Tested by: universe
|
|
|
|
| |
Submitted by: Greg Ansley
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Support for sam9 "EMAC" controller.
* Support for rmii interface to phy.
at91.c & at91sam9.c:
* Eliminate separate at91sam9.c file.
* Add new devices to at91sam9_devs table.
at91_machdep.c & at at91sam9_machdep.c:
* Automatic chip type determination.
* Remove compile time chip dependencies.
* Eliminate separate at91sam9_machdep.c file.
at91_pmc.c:
* Corrected support for all of the sam926? and sam9g20 chips.
* Remove compile time chip dependencies.
My apologies to Greg for taking so long to take care of it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
DPCPU area was not properly mapped into kernel VA space, which caused page
fault on the first DPCPU access. This patch fixes the problem by mapping DPCPU
area into kernel VA space.
Submitted by: Michal Hajduk, Piotr Ziecik
Reviewed by: cognet, stas
Approved by: re (kib)
Obtained from: Semihalf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Modules and kernel code alike may use DPCPU_DEFINE(),
DPCPU_GET(), DPCPU_SET(), etc. akin to the statically defined
PCPU_*. Requires only one extra instruction more than PCPU_* and is
virtually the same as __thread for builtin and much faster for shared
objects. DPCPU variables can be initialized when defined.
- Modules are supported by relocating the module's per-cpu linker set
over space reserved in the kernel. Modules may fail to load if there
is insufficient space available.
- Track space available for modules with a one-off extent allocator.
Free may block for memory to allocate space for an extent.
Reviewed by: jhb, rwatson, kan, sam, grehan, marius, marcel, stas
|