AM2632: AM263x Bootflow possibilities

Hello Aakash,

thanks for your quick response, I think this may be a possible solution for me.

I'm now hesitating what is the better solution for me, because I think the change of the bootloader library functions is not easy.

We are developing a functional safety application that will run on the R5SS0 (in lockstep mode).
One of our requirements is a StuckAt-memory-test on all relevant memory areas of the R5SS0 (functional safety)

A one-time execution of this test during startup is sufficient for us.

In our opinion, a second core on which firmware should run is actually not necessary.
But now the pBIST library from the SDK comes into play.

As far as I understand the pBIST documentation, in order to test the memories of the R5SS0, pBIST must be run on the R5SS1.
The SDK already offers two precompiled pBIST configurations to run on R5SS0 or R5SS1. Each configuration tests memory of the other core and destroyes the memory content.

Yesterday I tried another solution for my pBIST problem. I changed the pBIST configuration of the R5SS0 (file sdl_pbist_soc.c).
I expanded SDL_PBIST_InstInfoArray for SUBSYS_R5SS0 by all entries, listed below SUBSYS_R5SS1, only the memory L2_0 I didn't take over, because here my SBL is running.
(L2_0 is also checked from pBIST in RBL)
Then I recompiled the pBIST library and executed it in my SBL (running on R5SS0 in L2_0), before loading my functional safey firmware on R5SS0.
Now my question.

Is it in the inventor's interest to modify the pBIST library, in particular the configuration, himself?
I would prefer to include the SDK functions without making any changes of my own.

Both solutions
- booting R5SS1/pBIST execution with additional booting of R5SS0 from R5SS1 and
- pBIST-Configuration change to be executed only from R5SS0)
need a change of SDK-code.

Is there an example how I have to run these two pBIST configurations back to back without having to change the precompiled SDK libraries (bootloader and pBIST)?
Perhaps you can you draw a picture, how the steps of pBIST in combination with the relevant cores are?

Thanks for your effort and your support
Josef

Hi Aakash,


I think, this does not solve my problem, because there are memory areas in the R5SS0, which are not tested by the pBIST executed in RBL/ROM.
(e.g VIM0 RAM and R5SS0 RAM, which I do not know what this really is, but I guess this may be the data and instruction cache of the R5SS0).
I don't want to do some tests twice, to achieve "more " safety, I want to do some additional memory tests, which are not done from RBL, I think.

I think, one important memory area, I should test for my R5SS0-controller during the run-up is the VIM0 RAM area and the R5SS0 RAM.

The SDK offers two precompiled configuration for pBIST with the recomendation, to do this pBIST test once during run up.

configuration to be executed on R5SS0 (tests mainly R5SS1 memories)

.memoryGroupsBitMap = 1u, /* Choose R5 STC*/
.memoryGroupsBitMap = 1u, /* Choose R51 STC*/
.memoryGroupsBitMap = 2u, /* Choose PBISTROM */
.memoryGroupsBitMap = 5u, /* Choose CPSW*/
.memoryGroupsBitMap = 6u, /* Choose ICSSM RAM */
.memoryGroupsBitMap = 7u, /* Choose MBOX */
.memoryGroupsBitMap = 8u, /* Choose MCAN */
.memoryGroupsBitMap = 9u, /* Choose TPCC */
.memoryGroupsBitMap = 11u, /* Choose MSS_L2_1 */
.memoryGroupsBitMap = 12u, /* Choose MSS_L2_2 */
.memoryGroupsBitMap = 13u, /* Choose MSS_L2_3 */
.memoryGroupsBitMap = 15u, /* Choose VIM1 RAM*/
.memoryGroupsBitMap = 28u, /* Choose R5SS1 RAM */
.memoryGroupsBitMap = 16u, /* Choose VIM0 R5SS1 RAM*/
.memoryGroupsBitMap = 17u, /* Choose VIM1 R5SS1 RAM*/
.memoryGroupsBitMap = 23u, /* Choose MSS CR5B ATCM0*/
.memoryGroupsBitMap = 24u, /* Choose MSS CR5B ATCM1*/
.memoryGroupsBitMap = 25u, /* Choose MSS CR5B BTCM0*/
.memoryGroupsBitMap = 26u, /* Choose MSS CR5B BTCM1*/

configuration to be executed on R5SS1 (tests mainly R5SS0 memories, which are the mostly relevant memories for my functional safety application, because this sould run on R5SS0)

.memoryGroupsBitMap = 14u, /* Choose VIM0 RAM*/
.memoryGroupsBitMap = 10u, /* Choose MSS_L2_0 */
.memoryGroupsBitMap = 27u, /* Choose R5SS0 RAM */
.memoryGroupsBitMap = 3u, /* Choose CR5A_ROM0 */
.memoryGroupsBitMap = 4u, /* Choose CR5A_ROM1 */
.memoryGroupsBitMap = 18u, /* Choose TRACE */
.memoryGroupsBitMap = 29u, /* Choose MMCH0 */
.memoryGroupsBitMap = 19u, /* Choose MSS CR5A ATCM0*/
.memoryGroupsBitMap = 20u, /* Choose MSS CR5A ATCM1*/
.memoryGroupsBitMap = 21u, /* Choose MSS CR5A BTCM0*/
.memoryGroupsBitMap = 22u, /* Choose MSS CR5A BTCM1*/

My main problem ist, that I do not understand, when I should what test.
To my understanding, I need the second core R5SS1, to do the memory test for my R5SS0.
With the standard SBL this would not work, because loading and starting the firmware (with pBIST for R5SS0-areas) on R5SS1 will destroy the R5SS0 memory areas.

Due to that problem I had the idea, to start R5SS1 with pBIST and R5SS1 laods and starts firmware to R5SS0, after sucessfull pBIST, but this is not supported by the bootloader from SDK...

Can you ask your pBIST experts and/or safety experts, how the pBIST-tests can be done for all the R5SS0 areas (like an application note)

Regards
Josef

Hi Josef,

Apologies for the delay. We are reaching to subject matter expert to determine most optimum solution for you.

Best Regards,
Aakash

Hello Josef,

When you modified the file sdl_pbist_soc.c to include all the R5FSS0  memories, were you able to run the example successfully?

Thanks and Regards,
Vishwanath Reddy.

Hello Vishwanath,

I could not run all the tests from R5SS0, pBIST frooze during execution.
I had to disable the check of VIM0 ram(bitmap 14) and the check R5SS0 ram (bitmap 27).

I think, the reason for VIM0 is, that "pBIST done" is evaluated by interrupt. When I test the VIM0 area, the interrupt table is destroyed by the pBIST test...so the pBIST library can't never detect the end of this test.I think a test of VIM0 has to be done by R5SS1, mandatory, is this correct?

Can you give me hint, what R5SS0 ram is? Is this the instruction and data cache area of R5SS0? 

Thanks and regards
Josef

Hi Josef,

You can perform the PBIST for R5SS0 VIM0 and R5SS0 caches from R5SS0. When you run VIM0 PBITS test, the interrupt should be disabled, and check the status manually. 

Before starting the PBIST sequence, both the instruction cache and data cache must be disabled. So you can do R5SS0 caches PBIST from R5SS0.

Hi QJ Wang,

can you give me some more detailed information on the VIM0 test from R5SS0?

I think the SDL function SDL_PBIST_selfTest() does not offer the possibility of a manual check of the "test done"

Do I have to develop my own "pBIST functionality, based on the function SDL_PBIST_selfTest()m to do the check of VIM0 RAM from R5SS0?

Regards,

Josef

Hi Joef,

You need to disable all the enabled interrupts (UART0, RTI, PBIST) before performing PBIST test. After PBIST is triggered, check the VIM channel 71 (RAW), if it is set the PBIST is done.