M68K: drop the custom C arch_cpu_user_mem*() for the default impl

I didn't notice there was a C++ version that didn't require writing asm.

I'll have to write them anyway for speed someday.

M68K: add arch_cpu_idle and arch_cpu_pause inline stubs

Remove the stub from arch_cpu.cpp

We might want to implement a 040 CPU module providing idle using LPSTOP.

Add TODO note with respect to needed asm implementations.

* Renamed the ROUNDOWN macro to ROUNDDOWN. Also changed the implementation of
ROUNDUP to use '*' and '/' -- the compiler will optimize that for powers of
two anyway and this implementation works for other numbers as well.
* The thread::fault_handler use in C[++] code was broken with gcc 4. At least
when other functions were invoked. Trying to trick the compiler wasn't a
particularly good idea anyway, since the next compiler version could break
the trick again. So the general policy is to use the fault handlers only in
assembly code where we have full control. Changed that for x86 (save for the
vm86 mode, which has a similar mechanism), but not for the other
architectures.
* Introduced fault_handler, fault_handler_stack_pointer, and fault_jump_buffer
fields in the cpu_ent structure, which must be used instead of
thread::fault_handler in the kernel debugger. Consequently user_memcpy() must
not be used in the kernel debugger either. Introduced a debug_memcpy()
instead.
* Introduced debug_call_with_fault_handler() function which calls a function
in a setjmp() and fault handler context. The architecture specific backend
arch_debug_call_with_fault_handler() has only been implemented for x86 yet.
* Introduced debug_is_kernel_memory_accessible() for use in the kernel
debugger. It determines whether a range of memory can be accessed in the
way specified. The architecture specific back end
arch_vm_translation_map_is_kernel_page_accessible() has only been implemented
for x86 yet.
* Added arch_debug_unset_current_thread() (only implemented for x86) to unset
the current thread pointer in the kernel debugger. When entering the kernel
debugger we do some basic sanity checks of the currently set thread structure
and unset it, if they fail. This allows certain commands (most importantly
the stack trace command) to avoid accessing the thread structure.
* x86: When handling a double fault, we do now install a special handler for
page faults. This allows us to gracefully catch faulting commands, even if
e.g. the thread structure is toast.

We are now in much better shape to deal with double faults. Hopefully avoiding
the triple faults that some people have been experiencing on their hardware
and ideally even allowing to use the kernel debugger normally.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32073 a95241bf-73f2-0310-859d-f6bbb57e9c96

- Add m68k pendant of: r27529 & r27778 - handle skipIframes parameter
r27530 - allow faults with ints disabled if there is a handler
r27648 - call the end-of-interrupt thread callback
r27718 - add <asm_defs.h>, not used yet
r27722 - register the commpage as image and symbols (but we don't use it yet)
- remove dupped call to thread_get_current_thread()
- use 16MB iospace for now, 4MB seems too small.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27999 a95241bf-73f2-0310-859d-f6bbb57e9c96

cleanup


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26723 a95241bf-73f2-0310-859d-f6bbb57e9c96

- use a physical page for natfeat debug output for now
- add 040 cpu and mmu stuff
- use leftover from the page root table to put interrupt vector table to set VBR to


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26627 a95241bf-73f2-0310-859d-f6bbb57e9c96

- Cleanup
- rewrote early_query() to use the TT0 mapping to remove the page_hole stuff.
- fixed natfeat, using a page set up from the bootloader for now as it wants physical address. At least it's enough to see from the debugger:
load kernel...
kernel entry at 8003711a
Welcome to kernel debugger output!
Haiku revision: 26582
PANIC: unknown cpu_type 68040

Welcome to Kernel Debugging Land...
Running on CPU 0
kdebug>


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26599 a95241bf-73f2-0310-859d-f6bbb57e9c96

- missing ppc stub
- kernel_m68K almost links now, jsut bails out on the linker script...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26096 a95241bf-73f2-0310-859d-f6bbb57e9c96

- Add missing globals
- stubbed commpage stuff.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26094 a95241bf-73f2-0310-859d-f6bbb57e9c96

kernel compiles but doesn't link yet.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26092 a95241bf-73f2-0310-859d-f6bbb57e9c96

- some cpu and platform fixes.
- we'll just use decimal chip number (68030, ...) to identify cpu, fpu, and mmu for simplicity.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26041 a95241bf-73f2-0310-859d-f6bbb57e9c96

memory barrier functions available for drivers.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25183 a95241bf-73f2-0310-859d-f6bbb57e9c96

Ditto.
cleanup
Less ppc, more m68k :)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22822 a95241bf-73f2-0310-859d-f6bbb57e9c96

Note on 060 equivalent of HLT.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22750 a95241bf-73f2-0310-859d-f6bbb57e9c96

No need for ppc code there.
68030 invalidates only 1 long of a cache line each time.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22715 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fix flushing the ATC, add flushing icache.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22709 a95241bf-73f2-0310-859d-f6bbb57e9c96

This should handle TLB flushing on m68k (it's called ATC though).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22706 a95241bf-73f2-0310-859d-f6bbb57e9c96

Unfinished kernel support for m68k.
Based on ppc/x86 from r22648.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22650 a95241bf-73f2-0310-859d-f6bbb57e9c96

Add TODO note with respect to needed asm implementations.

* Renamed the ROUNDOWN macro to ROUNDDOWN. Also changed the implementation of
ROUNDUP to use '*' and '/' -- the compiler will optimize that for powers of
two anyway and this implementation works for other numbers as well.
* The thread::fault_handler use in C[++] code was broken with gcc 4. At least
when other functions were invoked. Trying to trick the compiler wasn't a
particularly good idea anyway, since the next compiler version could break
the trick again. So the general policy is to use the fault handlers only in
assembly code where we have full control. Changed that for x86 (save for the
vm86 mode, which has a similar mechanism), but not for the other
architectures.
* Introduced fault_handler, fault_handler_stack_pointer, and fault_jump_buffer
fields in the cpu_ent structure, which must be used instead of
thread::fault_handler in the kernel debugger. Consequently user_memcpy() must
not be used in the kernel debugger either. Introduced a debug_memcpy()
instead.
* Introduced debug_call_with_fault_handler() function which calls a function
in a setjmp() and fault handler context. The architecture specific backend
arch_debug_call_with_fault_handler() has only been implemented for x86 yet.
* Introduced debug_is_kernel_memory_accessible() for use in the kernel
debugger. It determines whether a range of memory can be accessed in the
way specified. The architecture specific back end
arch_vm_translation_map_is_kernel_page_accessible() has only been implemented
for x86 yet.
* Added arch_debug_unset_current_thread() (only implemented for x86) to unset
the current thread pointer in the kernel debugger. When entering the kernel
debugger we do some basic sanity checks of the currently set thread structure
and unset it, if they fail. This allows certain commands (most importantly
the stack trace command) to avoid accessing the thread structure.
* x86: When handling a double fault, we do now install a special handler for
page faults. This allows us to gracefully catch faulting commands, even if
e.g. the thread structure is toast.

We are now in much better shape to deal with double faults. Hopefully avoiding
the triple faults that some people have been experiencing on their hardware
and ideally even allowing to use the kernel debugger normally.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32073 a95241bf-73f2-0310-859d-f6bbb57e9c96

- Add m68k pendant of: r27529 & r27778 - handle skipIframes parameter
r27530 - allow faults with ints disabled if there is a handler
r27648 - call the end-of-interrupt thread callback
r27718 - add <asm_defs.h>, not used yet
r27722 - register the commpage as image and symbols (but we don't use it yet)
- remove dupped call to thread_get_current_thread()
- use 16MB iospace for now, 4MB seems too small.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27999 a95241bf-73f2-0310-859d-f6bbb57e9c96

cleanup


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26723 a95241bf-73f2-0310-859d-f6bbb57e9c96

- use a physical page for natfeat debug output for now
- add 040 cpu and mmu stuff
- use leftover from the page root table to put interrupt vector table to set VBR to


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26627 a95241bf-73f2-0310-859d-f6bbb57e9c96

- Cleanup
- rewrote early_query() to use the TT0 mapping to remove the page_hole stuff.
- fixed natfeat, using a page set up from the bootloader for now as it wants physical address. At least it's enough to see from the debugger:
load kernel...
kernel entry at 8003711a
Welcome to kernel debugger output!
Haiku revision: 26582
PANIC: unknown cpu_type 68040

Welcome to Kernel Debugging Land...
Running on CPU 0
kdebug>


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26599 a95241bf-73f2-0310-859d-f6bbb57e9c96

- missing ppc stub
- kernel_m68K almost links now, jsut bails out on the linker script...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26096 a95241bf-73f2-0310-859d-f6bbb57e9c96

- Add missing globals
- stubbed commpage stuff.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26094 a95241bf-73f2-0310-859d-f6bbb57e9c96

kernel compiles but doesn't link yet.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26092 a95241bf-73f2-0310-859d-f6bbb57e9c96

- some cpu and platform fixes.
- we'll just use decimal chip number (68030, ...) to identify cpu, fpu, and mmu for simplicity.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26041 a95241bf-73f2-0310-859d-f6bbb57e9c96

memory barrier functions available for drivers.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25183 a95241bf-73f2-0310-859d-f6bbb57e9c96

Ditto.
cleanup
Less ppc, more m68k :)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22822 a95241bf-73f2-0310-859d-f6bbb57e9c96

Note on 060 equivalent of HLT.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22750 a95241bf-73f2-0310-859d-f6bbb57e9c96

No need for ppc code there.
68030 invalidates only 1 long of a cache line each time.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22715 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fix flushing the ATC, add flushing icache.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22709 a95241bf-73f2-0310-859d-f6bbb57e9c96

This should handle TLB flushing on m68k (it's called ATC though).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22706 a95241bf-73f2-0310-859d-f6bbb57e9c96

Unfinished kernel support for m68k.
Based on ppc/x86 from r22648.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22650 a95241bf-73f2-0310-859d-f6bbb57e9c96