- Add 'rtems_shell_init_environment()' so a user can create the
shell environment without needing to run a shell.
- Move 'rtems_shell_lookup_topic', 'rtems_shell_can_see_cmd',
and 'rtems_shell_execute_cmd' from the internal interface to
the public interface.
Closes#3096.
There is no need to explicitly set the output format and architecture in
the linker script. This enables the usage of this linker script with
the ELFv2 ABI (64-bit).
Update #3082.
Do not flush/invalidate the caches. Instead enable the cache during the
low-level initialization and perform an explicit cache flush for the
read-only and fast-text sections.
Update #3082.
Update #3085.
The SPARC ABI is a bit special with respect to the floating point context.
The complete floating point context is volatile. Thus, from an ABI point
of view nothing needs to be saved and restored during a context switch.
Instead the floating point context must be saved and restored during
interrupt processing. Historically, the deferred floating point switch was
used for SPARC and the complete floating point context is saved and
restored during a context switch to the new floating point unit owner.
This is a bit dangerous since post-switch actions (e.g. signal handlers)
and context switch extensions may silently corrupt the floating point
context.
The floating point unit is disabled for interrupt handlers. Thus, in case
an interrupt handler uses the floating point unit then this will result in a
trap (INTERNAL_ERROR_ILLEGAL_USE_OF_FLOATING_POINT_UNIT).
In uniprocessor configurations, a lazy floating point context switch is
used. In case an active floating point thread is interrupted (PSR[EF] == 1)
and a thread dispatch is carried out, then this thread is registered as the
floating point owner. When a floating point owner is present during a
context switch, the floating point unit is disabled for the heir thread
(PSR[EF] == 0). The floating point disabled trap checks that the use of the
floating point unit is allowed and saves/restores the floating point context
on demand.
Update #3077.
The loop that checks if the current address is already mapped uses
the same local variable for the chanin node as the newly allocated
chain node so the allocated chain node gets over written.
Added a new local variable for the loop that checks the address
Updates #2859.
