- 25 1月, 2008 1 次提交
-
-
由 Haavard Skinnemoen 提交于
Add the following fields to /proc/cpuinfo: * chip type and revision (from the JTAG chip id) * cpu MHz (from clk_get_rate()) * features (from the CONFIG0 register) Also rename "cpu family" to "cpu arch" and "cpu type" to "cpu core" to remove some ambiguity. Show chip type and revision at bootup, and clarify that the other kinds of IDs that we're already printing are for the cpu core and architecture. Rename "AP7000" to "AP7" since that's the name of the core. Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
-
- 07 12月, 2007 1 次提交
-
-
由 Haavard Skinnemoen 提交于
The current debug trap handling code does a number of things that are illegal according to the AVR32 Architecture manual. Most importantly, it may try to schedule from Debug Mode, thus clearing the D bit, which can lead to "undefined behaviour". It seems like this works in most cases, but several people have observed somewhat unstable behaviour when debugging programs, including soft lockups. So there's definitely something which is not right with the existing code. The new code will never schedule from Debug mode, it will always exit Debug mode with a "retd" instruction, and if something not running in Debug mode needs to do something debug-related (like doing a single step), it will enter debug mode through a "breakpoint" instruction. The monitor code will then return directly to user space, bypassing its own saved registers if necessary (since we don't actually care about the trapped context, only the one that came before.) This adds three instructions to the common exception handling code, including one branch. It does not touch super-hot paths like the TLB miss handler. Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
-
- 27 4月, 2007 2 次提交
-
-
由 Haavard Skinnemoen 提交于
* Use generic BUG() handling * Remove some useless debug statements * Use a common function _exception() to send signals or oops when an exception can't be handled. This makes sure init doesn't enter an infinite exception loop as well. Borrowed from powerpc. * Add some basic exception tracing support to the page fault code. * Rework dump_stack(), show_regs() and friends and move everything into process.c * Print information about configuration options and chip type when oopsing Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
-
由 Haavard Skinnemoen 提交于
Clean up the cpu identification code, using definitions from <asm/sysreg.h> instead of hardcoded constants. Also, add a features bitmap to struct avr32_cpuinfo to allow other code to make decisions based upon what the running cpu is actually capable of. Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
-
- 26 9月, 2006 1 次提交
-
-
由 Haavard Skinnemoen 提交于
This adds support for the Atmel AVR32 architecture as well as the AT32AP7000 CPU and the AT32STK1000 development board. AVR32 is a new high-performance 32-bit RISC microprocessor core, designed for cost-sensitive embedded applications, with particular emphasis on low power consumption and high code density. The AVR32 architecture is not binary compatible with earlier 8-bit AVR architectures. The AVR32 architecture, including the instruction set, is described by the AVR32 Architecture Manual, available from http://www.atmel.com/dyn/resources/prod_documents/doc32000.pdf The Atmel AT32AP7000 is the first CPU implementing the AVR32 architecture. It features a 7-stage pipeline, 16KB instruction and data caches and a full Memory Management Unit. It also comes with a large set of integrated peripherals, many of which are shared with the AT91 ARM-based controllers from Atmel. Full data sheet is available from http://www.atmel.com/dyn/resources/prod_documents/doc32003.pdf while the CPU core implementation including caches and MMU is documented by the AVR32 AP Technical Reference, available from http://www.atmel.com/dyn/resources/prod_documents/doc32001.pdf Information about the AT32STK1000 development board can be found at http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3918 including a BSP CD image with an earlier version of this patch, development tools (binaries and source/patches) and a root filesystem image suitable for booting from SD card. Alternatively, there's a preliminary "getting started" guide available at http://avr32linux.org/twiki/bin/view/Main/GettingStarted which provides links to the sources and patches you will need in order to set up a cross-compiling environment for avr32-linux. This patch, as well as the other patches included with the BSP and the toolchain patches, is actively supported by Atmel Corporation. [dmccr@us.ibm.com: Fix more pxx_page macro locations] [bunk@stusta.de: fix `make defconfig'] Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com> Signed-off-by: NAdrian Bunk <bunk@stusta.de> Signed-off-by: NDave McCracken <dmccr@us.ibm.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-