Showing changes from revision #7 to #8:
Added | Removed | Changed
Bit | Meaning when set |
---|---|
0 | You must tell the OS when a code area changes (OS_SynchroniseCodeAreas) |
1 | Enabling then disabling interrupts does not allow them a chance to occur (Use interrupt trigger routine returned in R1) |
2 | Hardware vectors are only readable in 32 bit mode |
3 | When storing PC, PC+8 is stored (not PC+12) |
4 | Data aborts occur with ‘full early’ timing (Base restored abort model) |
5 | CPU has split instruction & data caches |
6 | OS is 32-bit |
7 | CPU doesn’t support 26-bit modes |
8 | CPU has ‘M’ extensions (long multiply – UMULL, etc.) |
9 | CPU supports Thumb mode |
10 | CPU has ‘E’ DSP extensions (QADD, etc.) |
11 | |
0 → SWP/SWPB might be available (see notes) | |
12 | CPU supports LDR/STREX semaphores |
13 | CPU supports CLREX and LDR/STREX[B|H|D] semaphores |
14 | Reserved |
15 | CPU supports extended small page L2 descriptors |
16 | CPU doesn’t have a Drain Write Buffer instruction |
17 | Aborts don’t correctly follow the documented abort model (e.g. StrongARM pre rev-T; prevents lazy task swapping from being used) |
18 | CPU is an XScale |
19 | XScale JTAG is connected |
20 | High processor vectors are in use (vectors at &FFFF0000 instead of &0). See also OS_PlatformFeatures 32 |
21-31 | Reserved |
If Bit bit 11 is one, set it to indicates indicate thatSWP/SWPB definitely aren’t available available, (and in which caseLDREX/STREX will generally be available instead). instead. However if bit 11 is zero (or if OS_PlatformFeatures 0 isn’t implemented) there’s no guarantee thatSWP/SWPB are available. This is because bit 11 is a recent addition to the flags, which old implementations of OS_PlatformFeatures (such as those provided by the CallASWI module) are not aware of. So an ARM2 machine running CallASWI will generally return from OS_PlatformFeatures 0 with bit 11 clear, even though SWP/SWPB aren’t actually available.
If When your code isn’t concerned with ARM2 compatibility, it can simply take bit 11==0 11 as is an clear, indication and that providedCallASWI version 0.12 or later is in use, then SWP/SWPB definitely are available.
If Beware that if your code is concerned using with an ARM2 older compatibility, version it of will have to perform a manual check forCallASWI, or not calling OS_PlatformFeatures at all, on an ARM2 this could be inaccurate as SWP/SWPB availability were whenever not bit added 11 until is architecture zero. v2a. For example, you could temporarily install a an special error handler and then try to execute a dummySWP instruction, and check to see if the error handler is invoked. If your you code don’t is support also ARM2 32bit compatible then it any could version skip of this check if bit 6 is set (and assume thatSWPCallASWI / will return bit 11 clear anyway, which will be correct on ARM3 and later.SWPB are available) – any 32bit OS which doesn’t provide SWP/SWPB can be relied upon to correctly indicate this fact by setting bit 11 to 1.