Opened on 03/09/23 at 12:42:53
Last modified on 06/22/23 at 21:03:07
#4875 assigned enhancement
LEON3FT - Power-down workaround
Reported by: | Daniel Páscoa | Owned by: | Sebastian Huber |
---|---|---|---|
Priority: | normal | Milestone: | 6.1 |
Component: | arch/sparc | Version: | 6 |
Severity: | normal | Keywords: | qualification |
Cc: | Blocked By: | ||
Blocking: |
Description
Within bsps\sparc\leon3\start\bspidle.S there is the attached code snapshot, on which line 26 seems to contradict GR712RC board User Manual section 1.7.8 (Errata # 8 - LEON3FT Cache Controller: Incorrect Bus Access After Power-Down):
“1.7.8 LEON3FT Cache Controller: Incorrect Bus Access After Power-Down
A LEON with support for clock gating has one clock that is kept running and one clock that is gated off in power-down mode. Due to a design error, the gated clock was used for logic that keeps track of the state of the AMBA bus. Due to this error, the first instruction or data (whichever is first) access to the bus after leaving power-down might be performed incorrectly.
…
Note that the stack pointer or other cachable memory should never be used as the source operand, even if using ASI 1, since this may lead to faulty data being loaded into the data cache.“
One has asked Gaisler’s opinion and this has been the response:
“The errata is perhaps a bit too strongly worded. There is a risk that the load instruction used in the workaround will lead to fetching in incorrect data that gets cached if the address is in a cacheable area but that in itself is not a problem. In order for that to propagate into a real problem there has to be a subsequent load from that address that hits in the Dcache and uses the invalid data before that cache line is either flushed or the data is overwritten by stores. If you know that the address (and the same cache line) will not be loaded from this does not happen. In this case it is reading from the stack of the idle task which is never read from once the idle task is running. So I do not see that this can create a real issue.”
Either way, we wanted the RTEMS community to double-check that indeed there is not a real problem and eventually place additional comments on the code to better contextualize it w.r.t. the GR712RC User Manual errata # 8.
(Image attached)
Additional Notes:
This ticket was raised as an outcome of the Independent SW Verification and Validation (ISVV) for ESA-promoted RTEMS SMP Qualification Data Packs (https://rtems-qual.io.esa.int). The original ISVV reference for this issue is RTEMS-SMP-CODE-VER-073.
Attachments (1)
Change History (4)
Changed on 03/09/23 at 12:43:34 by Daniel Páscoa
Attachment: | Screenshot 2023-03-09 125938.jpg added |
---|
comment:1 Changed on 03/09/23 at 13:01:31 by Sebastian Huber
Component: | admin → arch/sparc |
---|---|
Milestone: | → 6.1 |
Type: | defect → enhancement |
Version: | → 6 |
comment:2 Changed on 03/15/23 at 06:22:08 by Sebastian Huber
Keywords: | qualification added |
---|
comment:3 Changed on 06/22/23 at 21:03:07 by Joel Sherrill
Owner: | set to Sebastian Huber |
---|---|
Status: | new → assigned |
Summary: | Power-down workaround → LEON3FT - Power-down workaround |
Code