Commit aa4c1c5c authored by Jeffrey Lee's avatar Jeffrey Lee
Browse files

Update docs to reflect current status

Version 0.02. Retagged as 'SMP-0_02'
parent 0f3d0d56
......@@ -60,8 +60,13 @@ is unsafe.
Other notes
===========
Because HAL interrupt numbers are core-specific, any device drivers implemented
in threads must use their affinity mask to lock them to a single core.
The IRQ manager will deadlock if an attempt is made to register or de-register
an IRQ handler for an IRQ that is currently active on the current core. E.g. a
handler attempting to deregister itself from within itself. This may happen in
some complex IRQ setups (e.g. multiple nested IRQs which can
register/deregister each other). It also happens when Ctrl-Break is pressed
(since the reset is triggered from within an IRQ context). Future changes may
improve this behaviour.
All cores share the same memory map as the primary core. This means it's unsafe
to allow them to access application space while in the Wimp. (Unpredictable
......@@ -77,18 +82,31 @@ then the error will not be recorded/reported, other than in *SMPMetrics. However
you may be able to manually recover the register dump from the top of the core's
ABT/UND stack.
If a non-X SWI returns an error, it will casue the calling thread to terminate
If a non-X SWI returns an error, it will cause the calling thread to terminate
with the given error.
Use of FIQs is not currently supported.
Some memory operations (making arbitrary pages cacheable/uncacheable via
OS_Memory 0, and page replacement when a DA claims specific pages) are not
currently dealt with in a multicore safe way. The device drivers used with the
Raspberry Pi generally don't make use of those operations, so the lack of
MP-safety is only likely to be an issue if third-party software you're using
attempts to use them (and if your multicore code interacts with the pages which
are being manipulated).
Service_PagesUnsafe / Service_PagesSafe (which are issued when e.g. a dynamic
area attempts to claim a page which is already in use by someone else) are
dealt with by putting the additional cores to sleep in a special "stasis" area.
This protects them from accessing the page(s) which are being moved, making the
operation safe. However because sleep entry/exit is triggered by receipt of the
service calls, any code which attempts to synchronise with a thread from within
a Service_PagesUnsafe / Service_PagesSafe handler may deadlock. Future changes
to the system should avoid this possibility (e.g. via tighter coupling with the
kernel).
Making arbitrary pages cacheable/uncacheable via OS_Memory 0 is not dealt with
in a multicore safe way. This may result instabilities or data corruption on
platforms which make heavy use of DMA from cacheable memory (iMX6, OMAP5,
Titanium).
Currently the idle thread uses WFI instead of WFE. This means that writing to a
pollword and then waking up a thread using SEV won't actually work; the core
will stay asleep until the next 100Hz thread scheduler interrupt. This is just
a temporary measure until a WFE-friendly sleep loop can be constructed (the
original implementation was flawed and prevented the cores from sleeping).
Commands
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment