TDA4VM: How can I boot with a memory map that has a program in the range of 64bit addresses?

HaTa,

Yes the compiler will not allow addresses in linker.cmd spanning 32-bit addressable range. So the trick is to specify a continuous range in the linker.cmd but use the MMU to map the actual physical value.

For example,

Lower 2GB physical address 0x0000_8000_0000 to 0x0000_FFFF_FFFF

Upper 2GB physical address 0x0008_8000_0000 to 0x0008_FFFF_FFFF

So in the linker map specify the upper 2GB to be in the range contiguous of lower 2GB

Upper 2GB virtual address 0x0001_0000_0000 to 0x0001_7FFF_FFFF

Now in the MMU map the virtual 0x0001_0000_0000 to 0x0008_8000_0000

We have tested this and it works.

One catch here is that C7x MMU is for C7x DSP only. DRU does not use this MMU or have a separate MMU.

So if you are using DRU then you need to implement a callback function and provide during UDMA Init which does a manual virtual to physical address translation.

Regards,
Shyam

HaTa, 

Shyam has explained well. 

"strange memory fragmentation" is strange because the fragment covers both the boot mode and normal mode spaces. But during boot, ARM MMU is off, therefore there is no support of address translation. This means only 32-bit address space, that is, 2GB is "visible" to ARM as well as C7x. This is why the low MEM of 2GB is in the memory table you listed, it is for boot. 

Right after the boot is completed and normal mode starts, ARM would turn its MMU on, C7x would convert from SW mode to HW mode, first thing the CPU's would do is to walk the translation table so the virtual 64-bit addresses aiming for DDR would be mapped to 32GB space for DDR. Why 32GB? In normal mode, there are a lot of memory spaces become available, MSMC, IO's, DMA etc. They are placed in between the 2GB and 32GB region, pushing the DDR to the High MEM space, which is everything above 32GB. It is reasonable to give DDR "infinite" space from system perspective due to its size. 

So the problem here is not the fragments. Rather, because you want access the space in normal mode but the core is still in boot. What you can do is:

1. Put a small piece of code in the 2GB space for C7x to execute. This code will program its uTLB and overwrites the 16GB entry with 4 1GB pages (the next page size less than 16GB is 1GB). Then you can use the memory space you want to access.

2. Or, you can put a small piece of code still, in the 2GB space for C7x to execute and change MMU from SW managed mode to HW managed mode. I assume the page table is setup according to SDK. This way, CPU access right after turning MMU to HW mode will trigger MMU to do page table walk automatically and bring the page translation in for you. 

Having said that, you might realize that this is not C7x specific requirement. ARM cores have the same behavior, that is, during boot, put all executable code in the 2GB space because you can only play with the 32-bit addresses without MMU on. If you want to execute outside of that space during boot, you are out of luck for ARM. But for C7x, you can program the MMU like the boot code does. 

Hope this helps. 

Thanks,

Kai