• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 831 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5728: IPC DSP1 Memory Carveout Change

Brad Griffis
Guru*** 125430 points

Part Number: AM5728

AM5728 EVM
Proc SDK Linux 3.01

I'm running the ex02_messageq example from IPC.  If I leave all the memory mapping alone and run it, things are fine.  However, I'm trying to make memory map adjustments, and even the smallest adjustment seems to break things.  Initially I was trying to move the entire DSP1 carveout, but that actually broke the entire boot!  So then I tried for a smaller change.  I shrunk the DSP1 carveout and shifted it like so:

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 574021a..16828e5 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -44,7 +44,7 @@

dsp1_cma_pool: dsp1_cma@99000000 {
compatible = "shared-dma-pool";
- reg = <0x0 0x99000000 0x0 0x4000000>;
+ reg = <0x0 0x9b000000 0x0 0x2000000>;
reusable;
status = "okay";
};

So I'm still sitting within the same footprint as the initial code, but instead of using 64MB I'm using the 32MB half in higher memory.  Trivial change right?  I can't get the program to function any more.

I compared the IOMMU mappings between the working and non-working cases using this command:

cat /sys/kernel/debug/omap_iommu/40d01000.mmu/pagetable

Working:

1: 0x95000000 0x9b100002
1: 0x95100000 0x9b200002
1: 0x95200000 0x9b300002
1: 0x95300000 0x9b400002
1: 0x95400000 0x9b500002
1: 0x9f000000 0x9b600002

Failing:

1: 0x95000000 0x99100002
1: 0x95100000 0x99200002
1: 0x95200000 0x99300002
1: 0x95300000 0x99400002
1: 0x95400000 0x99500002
1: 0x9f000000 0x99600002

I can see based on these mappings that in the good case, the virtual addresses at 0x9F000000 (which correspond to DSP memory areas TRACE_BUF, EXC_DATA, and PM_DATA) are being mapped to 0x9B600000, which is within the DSP1 CMA carveout.  

In the failing case, those memories are being mapped to physical address 0x99600000 which is NOT in my carveout.  I suspect this is the root of my issues.

  • 0
    TI__Guru*** 127335 points

    Hi Brad,

    You cannot unilaterally change the reserved memory entries on the kernel-side without making the corresponding IPC-side changes. There is currently a relation between the kernel-side reserved memory start and the vring addresses on the BIOS-side. The addresses for these have to match. Please update the PHYS_MEM_IPC_VRING to match the starting address of the reserved memory node. In the above example, you should update the macro in the corresponding resource table to use 0x9B000000. 

    Also, all the reserved memory nodes are laid out together, so changing one will also have a cascading affect on other remote processors if there are memory overlaps. Also, we use the same memory addresses across the DRA7 and AM57xx families.

    Also, it is worthwhile to go through the following AppNote, which discusses about memory map changes for IPU2:

    http://www.ti.com/lit/pdf/sprac08

  • 0 in reply to Suman Anna
    TI__Guru*** 125430 points

    Suman Anna said:
    There is currently a relation between the kernel-side reserved memory start and the vring addresses on the BIOS-side.

    Since the DSP is seeing only virtual addresses, it seems like we should be able to easily map some fixed virtual address from the DSP to the proper physical vring address.

    Is there any possible way to remove this dependency?  Updating the memory map would be extremely straight-forward without this requirement.  This one thing means we need to update 2 places in unison, build two different files, make sure we properly update 2 different files.  In the last several hours I've already had multiple times where I missed one of these several things which caused things to fail.

    Suman Anna said:
    The addresses for these have to match. Please update the PHYS_MEM_IPC_VRING to match the starting address of the reserved memory node. In the above example, you should update the macro in the corresponding resource table to use 0x9B000000. 

    This did indeed fix the issue (once I got everything properly rebuilt).  I would love to see some further improvement to remove the dependency.