TDA4VM: The way to access DDR 32GB area

Hi Kevin

As far as I confirm by using Memory Window on CCS after executing GEL I mentioned my first thread,

Within that 2GB area you mentioned, some were accessible and some weren't.

Could you please share the information about the environment/procedure?

Thanks and Best regards,

HaTa

Hi HaTa,

>>Within that 2GB area you mentioned, some were accessible and some weren't.

Can you give more information on the above? Is this observation on EVM or custom board? Which address can you not read / write to? Which CPU is trying to access the memory region?

>>Could you please share the information about the environment/procedure?

I am using the J721E EVM with the on-board XDS110 emulator, and CCS version 10.1.0.00010.

I connect to the M3 core using the GELs included with the CCS installation. ccs\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E.gel

I run the GEL LPDDR4 init script (from CCS, select "Scripts" -> "J7ES DDR Memory config" -> "J7ES_LPDDR4_Config".

I connect to the A72_0_0 core. I view the memory from the Memory Browser window within CCS.

Thanks,
Kevin

Hi Kevin

Thanks for sharing the information which you can access to there.

I'll share it to customer.

I'm very sorry, but I'd like to know how to access there from C7x.

We have prepared an evidence for this case, please examine it.

We are in a situation where we are unable to access a possible area.

In the table below, we are trying to use the range 0x08 00000000 - 0x0F FFFFFFFFFFFF in the bottom two groups.

We'll call them 64-bit addresses.

UTLB is not initially mapped to a 64-bit address.

Therefore, the MMU needs to be configured, but even if it is configured, it will not work correctly.

Page Fault exception occurs when attempting to read.

Our prediction: DDR initialization in launch.js does not support 64bit addresses.

■Test case

c7x_mmu_0208.zip

The above environment is for the MMU sample program, with a section for 64-bit addresses added.

The TCR register have been changed to the latest recommended values.

The DSP execution freezes when the sample program is executed.

From the following register results, it can be confirmed that a Page Fault exception has occurred.

HaTa,

>>>In the table below, we are trying to use the range 0x08 00000000 - 0x0F FFFFFFFFFFFF in the bottom two groups.

As I previously stated, you should be able to access the upper 2GB memory at 0x880000000 - 0x8FFFFFFFF. I do not think the range you have mentioned above is valid.

pbyPtr = (uint8_t*)0x0800000000ULL;       <-- Not valid
assert(1 == *pbyPtr); // Page Fault

Hi Kevin

Thank you for your answer. I can now access it.

However, it is a very strange limitation that the access to DDR4 is fragmented.

The lack of continuous access is also an inconvenience in practical use.

Is it possible to change this in the settings?

Or is it just a convenience in the implementation of EVM, and does not cause any problems under normal circumstances?

Please let me know the reason for this strange address space, how you plan to fix it in the future, and how it will be handled in TDA4AL.

Hi Kevin

Thank you for your answer. I would like to formally adopt that approach.

Please let me know if there is anything I should be aware of in doing so.

Also, if you know how this specification will work in TDA4AL, please let me know.