[BUG] ARM_CM23_nonsecure does not support psplim

[Dasheverless]

Describe the bug Here is the link of Arm Cortex-M23 Devices Generic User Guide. As you can see, in the table 2.3, there is no psplim register in Non-secure state. Im not sure what will happen in a cm23 board, cause I only run the code on vm. If I delete the line that uses psplim, the code will work. Official code Several lines in portasm.s use psplim. msr psplim, r3 msr psplim, r1

[urutva]

Hi @Dasheverless,

Thanks for reporting this.

From the Armv8-M architecture manual, section D1.2.217 PSPLIM, Process Stack Pointer Limit Register is If the Main Extension is not implemented, the Non-secure PSPLIM is RES0.

[urutva]

@Dasheverless Apologies, I pressed the enter before completing the response.

Can you please provide more information on the example you are running and on which platform?

I'll look into this and create a PR soon.

[Dasheverless]

Hi @urutva , The architecture manual says when access psplim in non secure state with base extension, it will lead RAZ/WI. However, it reports a hard fault when reading psplim while nothing happened when writting psplim on our inhouse vm. Maybe it is a vm bug. If you are familiar with the behavior of msr or mrs a raz/wi register, please let me know. Thanks!

[urutva]

Hi @Dasheverless, apologies for late reply.

From the From the Armv8-M architecture manual, section D1.2.217 PSPLIM, Process Stack Pointer Limit Register and Configuration sub-section described that This register is always implemented.. However, If the Main Extension is not implemented, the Non-secure PSPLIM is RES0.

The description of RES0 from the manual is as follows:

A reserved bit or field with Should-Be-Zero-or-Preserved behavior, or equivalent read-only or write-only behavior.
Used for fields in register descriptions, and for fields in architecturally defined data structures that are held in
memory.
Within the architecture, there are some cases where a register bit or field:
• Is RES0 in some defined architectural context.
• Has different defined behavior in a different architectural context.
Note
RES0 is not used in descriptions of instruction encodings.
This means the definition of RES0 for fields in read/write registers is:
If a bit is RES0 in all contexts
For a bit in a read/write register, it is IMPLEMENTATION DEFINED whether:
1. The bit is hardwired to 0. In this case:
• Reads of the bit always return 0.
• Writes to the bit are ignored.
2. The bit can be written. In this case:
• An indirect write to the register sets the bit to 0.
• A read of the bit returns the last value that is successfully written, by either a direct or an indirect write, to
the bit.
If the bit has not been successfully written since reset, then the read of the bit returns the reset value if
there is one, or otherwise returns an UNKNOWN value.
• A direct write to the bit must update a storage location that is associated with the bit.
• The value of the bit must have no effect on the operation of the PE, other than determining the value read
back from the bit, unless this manual explicitly defines additional properties for the bit.
Whether RES0 bits or fields follow behavior 1 or behavior 2 is IMPLEMENTATION DEFINED on a bit-by-bit basis.

Therefore, it does looks like an issue with vm you are using.

Note: The section B3.3 Registers describes Two 32-bit stack pointer limit registers, MSPLIM and PSPLIM, if the Main Extension is not implemented the Non-secure versions of these registers are RAZ/WI.

The description of RAZ/WI from the manual:

Read-As-Zero, Writes Ignored.
Hardware must implement the field as Read-As-Zero, and must ignore writes to the field.
Software can rely on the field reading as all 0s, and on writes being ignored.
This description can apply to a single bit that reads as 0, or to a field that reads as all 0s.

Read-As-Zero (RAZ):

Hardware must implement the field as reading as all 0s.
Software:
• Can rely on the field reading as all 0s
• Must use a SBZP policy to write to the field.
This description can apply to a single bit that reads as 0, or to a field that reads as all 0s. It applies only to a bit or
field that is read-only.

Should-Be-Zero-or-Preserved (SBZP)

From the introduction of the Armv8 architecture, the description Should-Be-Zero -or-Preserved is superseded by
RES0.
Hardware must ignore writes to the field.
If software has read the field since the PE implementing the field was last reset and initialized, it must preserve the
value of the field by writing the value that it previously read from the field. Otherwise, it must write the field as all
0s.
If software writes a value to the field that is not a value that is previously read for the field and is not all 0s, it must
expect an UNPREDICTABLE or CONSTRAINED UNPREDICTABLE result.
This description can apply to a single bit that should be written as its preserved value or as 0, or to a field that
should be written as its preserved value or as all 0s.

[Dasheverless]

Hi @urutva , someone meet the same issue but in a board not in vm. So, I consult the processor team, they told me this. You can see the Operation for all encodings section in C2.4.125 MRS and C2.4.126 MSR of Armv8-M architecture manual. For example, when using cm23 witout security extension, it is always in non-secure state. The SYSm of PSPLIM_NS is 10001011.

case SYSm[7:3] of
...
    when '10001'
        if !HaveSecurityExt() then UNPREDICTABLE;

As you can see, when access PSPLIM in a baseline and wiout security extension, the behaviour is UNPREDICTABLE which may cause hardfualt.

[jefftenney]

@Dasheverless A minor correction -- but no change to the conclusion. FreeRTOS code never uses the 10001011 encoding, because FreeRTOS code never explicitly addresses PSPLIM_NS. Instead, the code uses PSPLIM (no suffix), which gets the 00001011 encoding. That's important because the operation for that encoding considers the main extension when the PE does not have the security extension. That way FreeRTOS can still use the PSPLIM register with the main extension and without the security extension.

[Dasheverless]

@Dasheverless A minor correction -- but no change to the conclusion. FreeRTOS code never uses the 10001011 encoding, because FreeRTOS code never explicitly addresses PSPLIM_NS. Instead, the code uses PSPLIM (no suffix), which gets the 00001011 encoding. That's important because the operation for that encoding considers the main extension when the PE does not have the security extension. That way FreeRTOS can still use the PSPLIM register with the main extension and without the security extension.

Thanks for correction!

[jefftenney]

@Dasheverless Oh I meant to ask, which board encountered this error? (Which MCU model, vendor, etc.)

[Dasheverless]

@Dasheverless Oh I meant to ask, which board encountered this error? (Which MCU model, vendor, etc.)

It is a inhouse board, similar to cm23.

[aggarg]

Closing this issue as the following PR https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/791 is merged.