AM5716: IPU issue in RTOS SBL

Kazu,

Kazu Kon said:

1. I think the starting address of IRAM_MEM is incorrect. It's not IRAM area of IPU.

    IRAM_MEM:     org = 0x00800000 len = 0x8000      /*   RAM 0x1FBFF*/

    C:\ti\pdk_am57xx_1_0_8\packages\ti\boot\sbl\example\ipu1MulticoreApp\lnk_cpu0.cmd

Yes, you are right. the IRAM for IPU at the time of reset starts at 0x00000000 and not 0x00800000. This appears to have been taken from the DSP memory map where that is the local address for L2 RAM. The right IRAM_MEM settings is pdk_am57xx_1_0_8\packages\ti\csl\example\lnk_m4.cmd.

I checked with the development team and they mentioned the SBL examples were validated only for ARM and DSP boot for M4 they recommned using CSL or PDK driver binaries with the SBL.

Kazu Kon said:

2. I think the following range (red) is 0x4000 instead of 0x10000.

                        if (((section.addr >= CSL_IPU_IPU1_BOOT_SPACE_REGS) &&
                             (section.addr <
                              (CSL_IPU_IPU1_BOOT_SPACE_REGS + 0x10000U))) ||
                            ((section.addr >= CSL_IPU_IPU1_RAM_REGS) &&
                             (section.addr < (CSL_IPU_IPU1_RAM_REGS + 0x10000))))

    C:\ti\pdk_am57xx_1_0_8\packages\ti\boot\sbl\src\rprc\sbl_rprc.c

I think the 0x10000  is the correct size of IPU L2 RAM. Please note that on power on reset the IPU MMU will set the IPU RAM to location 0x00 as the foot note says in TRM under the IPU Memory map table.

When the IPU L2 is placed at 0x00 the entire 64 KB can be accesses using address from range 0x000000 to 0x10000 and that is what  referred to in that setting. It is a little confusing because the code uses CSL_IPU_IPU1_BOOT_SPACE_REGS but that address corresponds to IPU IRAM which is 64 KB so I don`t believe there is an issue here.

Please let us know if this is still not clear

At reset, the MMU is loaded with page 0, which forces the L2 RAM to be address 0x0. Post reset when you initialize the SOC using GEL files, you will notice that most of the MMU configuration provided by TI will put the entire L2RAM to be addressable  from 0x00000000 to 0x00020000.

For example if you look at the GEL file AM572x_multicore_reset.gel  you will see the small page configuration appears as follows:

/*Small Page*/
        regAddr = IPU_MMU_CFG;
        regAddr += 0x920;
        WR_MEM_32(regAddr,         0x00000000); regAddr += 0x4;
        WR_MEM_32(regAddr,         0x40000000); regAddr += 0x4;
        WR_MEM_32(regAddr,         0x00004000); regAddr += 0x4;
        WR_MEM_32(regAddr,         0x00008000); regAddr += 0x4;
        WR_MEM_32(regAddr,         0x20000000); regAddr += 0x4;

        regAddr = IPU_MMU_CFG;
        regAddr += 0x9A0;
        WR_MEM_32(regAddr,         0x55020000); regAddr += 0x4;
        WR_MEM_32(regAddr,         0x55080000); regAddr += 0x4;
        WR_MEM_32(regAddr,         0x55024000); regAddr += 0x4;
        WR_MEM_32(regAddr,         0x55028000); regAddr += 0x4;
        WR_MEM_32(regAddr,         0x55020000); regAddr += 0x4;

In RTOS SDK, you will see that the small pages are set as follows:

/* Small Page */
AMMU.smallPages[0].pageEnabled = AMMU.Enable_YES;
AMMU.smallPages[0].logicalAddress = 0x00000000;
AMMU.smallPages[0].translatedAddress = 0x55020000;
AMMU.smallPages[0].translationEnabled = AMMU.Enable_YES;
AMMU.smallPages[0].size = AMMU.Small_16K;
AMMU.smallPages[0].volatileQualifier = AMMU.Volatile_FOLLOW;
AMMU.smallPages[0].L1_cacheable = AMMU.CachePolicy_CACHEABLE;
AMMU.smallPages[0].L1_posted = AMMU.PostedPolicy_NON_POSTED;
AMMU.smallPages[0].L2_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
AMMU.smallPages[0].L2_posted = AMMU.PostedPolicy_NON_POSTED;

AMMU.smallPages[1].pageEnabled = AMMU.Enable_YES;
AMMU.smallPages[1].logicalAddress = 0x40000000;
AMMU.smallPages[1].translatedAddress = 0x55080000;
AMMU.smallPages[1].translationEnabled = AMMU.Enable_YES;
AMMU.smallPages[1].size = AMMU.Small_16K;
AMMU.smallPages[1].volatileQualifier = AMMU.Volatile_FOLLOW;
AMMU.smallPages[1].L1_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
AMMU.smallPages[1].L1_posted = AMMU.PostedPolicy_NON_POSTED;
AMMU.smallPages[1].L2_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
AMMU.smallPages[1].L2_posted = AMMU.PostedPolicy_NON_POSTED;

AMMU.smallPages[2].pageEnabled = AMMU.Enable_YES;
AMMU.smallPages[2].logicalAddress = 0x00004000;
AMMU.smallPages[2].translatedAddress = 0x55024000;
AMMU.smallPages[2].translationEnabled = AMMU.Enable_YES;
AMMU.smallPages[2].size = AMMU.Small_16K;
AMMU.smallPages[2].L1_cacheable = AMMU.CachePolicy_CACHEABLE;
AMMU.smallPages[2].L1_posted = AMMU.PostedPolicy_NON_POSTED;
AMMU.smallPages[2].L2_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
AMMU.smallPages[2].L2_posted = AMMU.PostedPolicy_NON_POSTED;

AMMU.smallPages[3].pageEnabled = AMMU.Enable_YES;
AMMU.smallPages[3].logicalAddress = 0x00008000;
AMMU.smallPages[3].translatedAddress = 0x55028000;
AMMU.smallPages[3].translationEnabled = AMMU.Enable_YES;
AMMU.smallPages[3].size = AMMU.Small_16K;
AMMU.smallPages[3].L1_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
AMMU.smallPages[3].L1_posted = AMMU.PostedPolicy_NON_POSTED;
AMMU.smallPages[3].L2_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
AMMU.smallPages[3].L2_posted = AMMU.PostedPolicy_NON_POSTED;

As long as you understand that MMU setting needs to align with the address that you use in the linker command file, you should be fine. To check the MMU settings, I like to use the Memory browser and CCS emulator will show the contents of the memory location as seen from the IPU core.

If you go to 0x00000000 when connected to IPU_C0, the contents will match with 0x55020000. Similarly 0x00004000 will match with 0x55024000 and so on.

Regards,

Rahul

Kazu Kon said:

I think that the length is 0x10000 (64KB) instead of 0x1000 (4KB). The comment of RAM 0x1FBFF is also strange. Right?

IRAM_MEM: org = 0x00000000 len = 0x1000 /* RAM 0x1FBFF*/

Agreed, if the L2RAM is moved to the logical address 0x00000000 then the length should 64KB (0x10000)  as memory after that would correspond to GPMC direct address space.

Kazu Kon said:

I can read and write to the all 64 KB area of ​​0x55020000 ~ 0x5502FFFF with CCS Memory Browser. And I can do to the 48 KB area of 0x00000000 ~ 0x0000BFFF, but it can not be done last 16 KB area of 0x0000C000 ~ 0x0000FFFF. I guess this area is not defined by AMMU Small Page (16 KB). Is it correct? 

That is correct, the top 16MB  doesn`t seem to be configured in the small AMMU table.

Kazu Kon said:

/*Medium Page*/
regAddr = IPU_MMU_CFG;
regAddr += 0x860;
WR_MEM_32(regAddr, 0x00300000); regAddr += 0x4;
WR_MEM_32(regAddr, 0x00400000); regAddr += 0x4;

regAddr = IPU_MMU_CFG;
regAddr += 0x8A0;
WR_MEM_32(regAddr, 0x40300000); regAddr += 0x4;
WR_MEM_32(regAddr, 0x40400000); regAddr += 0x4;

The setting maps 256KB of OCMC_0  (0x4030_0000) to logical address (0x0030_0000) and 256 KB of OCMC_1 (0x4040_0000) address to logical address (0x0040_0000). If you need the entire 512KB of OCMC,  then you will need to make another entry in the medium table to also remap the upper 256KB.

Kazu Kon said:

Rahul Prabhu

In RTOS SDK, you will see that the small pages are set as follows:

sorry for not providing the exact path to these settings. If you take any of the driver examples that are supported on the M4 core like UART, SPI, I2C, etc, there is a .cfg file in the examples for M4 that has this settings. Let me point you to the SPI driver M4 example configurations.

pdk_am57xx_1_0_x\packages\ti\drv\spi\test\am572x\m4\bios\spi_m4_idkAM572x.cfg

The AMMU settings are usually the same for all the PDK driver examples on M4.

Hope this helps.

Regards,

Rahul