Add a CPU counter interface to allow access to a free-running counter.
It is useful to measure short time intervals. This can be used for
example to enable profiling of critical low-level functions.
Add two busy wait functions rtems_counter_delay_ticks() and
rtems_counter_delay_nanoseconds() implemented via the CPU counter.
Rename rtems_internal_error_description() to
rtems_internal_error_text(). Rename rtems_fatal_source_description() to
rtems_fatal_source_text(). Rename rtems_status_code_description() to
rtems_status_text(). Remove previous implementation of
rtems_status_text().
The _CPU_Context_switch() is a normal function call. The following
registers are volatile (the caller must assume that the register
contents are destroyed by the callee) according to "SYSTEM V APPLICATION
BINARY INTERFACE - SPARC Processor Supplement", Third Edition: g1, o0,
o1, o2, o3, o4, o5. Drop these registers from the context.
Ensure that offset defines match the structure offsets.
Use the Global Timer for the Cortex-A9 MPCore clock driver instead of
the Private Timer. This enables a consistent nanoseconds since last
context switch value across all processors.
Install inter-processor interrupt (IPI) handler before secondary CPUs
are started. This ensures that secondary CPUs fetch the newly installed
handler.
Remove superfluous return statement.
Generate a linker command file from configure letting the user override the
defaults to suite their custom needs. Refer to configure.ac for the details.
Remove the SMP variants and let --enable-smp control if a BSP is built for
SMP.
Make USE_FAST_IDLE 1 only for the realview qemu BSP.
According with comment in
rtems_cache_invalidate_multiple_instruction_lines(), final_address
indicates the last address which needs to be invalidated. But if in
while loop we got final_address == i_addr condition then loop breaks and
final_address will not be invalidated.
Problem:
The console works fine when only transmitting data from the ERC32, but stops
working after a while when receiving data.
"Stops working" means, bytes are neither sent nor received from the UART, but
the rest of the system keeps functioning (task are executing, the operative
system is responsive, etc).
Context:
- When an RX error occurs, the ERC32 UARTS stop generating RX/TX interrupts
until the corresponding error flag in the UART_STATUS are cleared.
- The console.c code currently cleans the error flags from the console_isr_x
subroutines, but those are NOT called when an RX error occurs. Thus the error
flag is never cleaned and then the UARTs stop generating interrupts
indefinitely.
- The ERC32 UARTs generate a different interrupt when an RX error occurs.
Fixed by:
- Adding a third interrupt service routine console_isr_error to handle the
UART_ERROR trap. This isr cleans the error flags of the channels.
- Cleaning the error flags manually just after having initialized the interrupt
vectors. This is because if the error flag was already set by the time the
interrupt vectors are configured, the interrupts might never be called.
