S32G274 - Cannot access full 8MB of SRAM

[kf6uzf]

We are using the S32G-VNP-RDB2 development board with the S32G274 SoC. Our goal is to write our own first stage bootloader and run a proprietary OS. If we let U-Boot run and interrupt the Linux boot, we only see the first 2MB of SRAM. We have a working IVT, DCD and FSBL in place and still can't use memory above 2MB.We set the PRAMIAS to 0x0 and PRAMIAE to 0x1FFFF with no change in access. What is the process to enable the full 8MB of SRAM?

[Herbert_M_Triceratops]

solved

[kf6uzf]

We are still unable to access the full range of 8MB of SRAM. This exchange was completely useless.

[Daniel-Aguirre]

Hi,

Thanks for your feedback. We do apologize if this exchange is not proving to be useful under your needed scheme.

If you require better support, we recommend sending this inquiry to your local NXP FAE, for them to provide a better experience for your needs.

In the meantime, if you prefer to continue the exchange through this channel, are you using the image provided by NXP? What commands are you trying to input that lead to this non-accessible memory region behavior?

Please, let us know.

[Daniel-Aguirre]

Hi,

If you cannot access the full SRAM it can be related to the SRAM initialization. You say you have configured PRAMIAS and PRAMIAE, have you also set PRAMCR? This is shown on the S32G2 Reference Manual [Page 1346, S32G2 Reference Manual, Rev. 6, 11/2022]:

"1. Determine the bus address range to be initialized, and compute the equivalent range in the local memory address. This
must identify the lower and upper bound addresses in local memory to set up PRAMIAS and PRAMIAE.

2. Write the lower bound local memory address to PRAMIAS[IAS].
3. Write the upper bound local memory address to PRAMIAE[IAE].
4. Start initialization by writing 1 to PRAMCR[INITREQ]."

Also, is this done with the DCD? Is this done with the NXP provided Linux Image? For us to understand if we can replicate the behavior from our side.

Please, let us know.

[kf6uzf]

We set the registers in the IVT DCD block. Here is the DCD
D2 00 38 60 CC 00 34 04 40 19 C0 04 00 00 00 00 40 19 C0 08 00 03 FF FF 40 1A 00 04 00 00 00 00 40 1A 00 08 00 03 FF FF 40 19 C0 00 00 00 00 07 40 1A 00 00 00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The RM states the PRAMIAE[IAE] is a maximum value of 0x1FFFF but we believe it is an error because that would only allow 4MB access.
Thanks

[Daniel-Aguirre]

Hi,

We are looking into your DCD and see that PRAMIAE[IAE] has been set with a 0x3FFFF, which is not valid since IAE is only 17 bits wide.

S32G2 has 2 SRAM controllers, SRAMC and SRAMC_1 [Table 203, Page 1344, S32G2 Reference Manual, Rev. 6, 11/2022] and each one has access to 4MB, which in conjunction they will provide the full 8MB.

We are also seeing that you implemented everything in a single write with the DCD (or so it seems), the recommendation is to add each register in its own write command. Something like the example below:

We also saw that you added the initialization wait cycles, is this correct?

Lastly, we compare the output from the DCD tool with your DCD and see that the tool adds 1's instead of 0's at the end, did you generate this DCD with the NXP DCD tool inside Config Tools? Or did you generate it by yourself?

Please, let us know.

[kf6uzf]

The 0x3FFFF was an experiment. We have changed it back to 0x1FFFF. We will try to have an explicit write command after each register has been sent. Should we remove the wait cycles? We created the DCD by hand. Can you send me the output from the DCD tool you used. We are not using the S32DS. Thanks

[Daniel-Aguirre]

As for the wait cycles, we were just curious if they were needed on your application. We are not seeing any restriction over as if they are needed or not.

Below will be the output of the DCD Tool inside S32DS for the following sequence:

• SRAMC.PRAMIAS
• SRAMC.PRAMIAE
• SRAMC.PRAMCR
• SRAMC_1.PRAMIAS
• SRAMC_1.PRAMIAE
• SRAMC_1.PRAMCR

For each register, a write command was created:

d200 4c60 cc00 0c14 4019 c004 0000 0000
cc00 0c14 4019 c008 0001 ffff cc00 0c14
4019 c000 0000 0001 cc00 0c14 401a 0004
0000 0000 cc00 0c14 401a 0008 0001 ffff
cc00 0c14 401a 0000 0000 0001 ffff ffff
ffff ffff ffff ffff ffff ffff

Please, let us know.

[Herbert_M_Triceratops]

Hi Daniel, this is Rostami, you may remember me from a few previous private support cases. I work with user kf6uzf.

There is a real problem here, with SRAM. I appreciate the effort, but what you are suggesting is merely a collection of random guesses. I wish we could get lucky like that, I just want it to work, but we seem to be unlucky.

First, the presence of 16 bytes 0x00 at the end of the DCD is fine. This is the GMAC, which is irrelevant for non-secure boot. You yourself told me this, and I know factually that it's true. Further, NXP's own DCD, the one that is already on the board when you ship it, has all 0x00, like me, not all 0xFF, as you suggest and as the S32 Studio outputs. Not only is the value irrelevant, but NXP is not even using its own tool to generate the DCDs on the boards that it ships!

Second, DCD allows multiple writes to occur within one command. This is expressly allowed (cf. S32G2RM 30.4.2.1.1), and there is no reason to think that it is broken.

Third, NXP's own IVT with NXP's own DCD with NXP's own build of U-Boot, out of the box with no modifications, cannot read the full range of System SRAM! Even a relatively low address like 'md.l 0x34300000 1' fails (exception). I checked the MMU, and there is no protection, the whole 8MiB range 0x34000000-0x347FFFFF is mapped.

Nonetheless, I implemented all suggestions, iteratively, until I arrived at your exact DCD, output from the S32 Studio. The behavior of SRAM is identical, nothing improved.

All my stuff is fine, and tested, and verified. It's not usefule to speculate about how one thing or another "may" be wrong. It's not wrong. The problem is real and the problem is elsewhere. I already tested endless combinations of theories and values, nothing works.

Thanks for your attention to this. I'm sure you know that the processor is useless to us if we can't use SRAM confidently.

[Daniel-Aguirre]

Hi,

Thanks for your feedback. We were trying to understand if the DCD configuration was indeed or not the root-cause, since similar cases were related to not initializing correctly the SRAMC and SRAMC_1 modules. We apologize for this.

As for the uboot itself, are you using the image provided by NXP? What commands are you trying to input that lead to this non-accessible memory region behavior?

Please, let us know.