AM3874 custom board memory map

Hi Jorge,

Jorge Fernandez said:

1) From the link, it's not clear what the point 2) values are the correct ones. Maybe I have to define
this way??

#define CONFIG_NR_DRAM_BANKS        2        /* we have 2 banks of DRAM */
#define PHYS_DRAM_1            0x80000000    /* DRAM Bank #1 */
#define PHYS_DRAM_1_SIZE        0x20000000    /* 512 MB */
#define PHYS_DRAM_2            0xA0000000    /* DRAM Bank #2 */
#define PHYS_DRAM_2_SIZE        0x20000000    /* 512 MB */

From the link image it seems that the physical memory its mapped the same in the 0x80000000 and

in the 0xA0000000 range

Please note that the default /include/config/ti8148_evm.h file is wrong, as it reports 2GB in u-boot, while the actual DRAM size is 1GB. This is fixed with the below u-boot patch:

http://arago-project.org/git/projects/u-boot-omap3.git?p=projects/u-boot-omap3.git;a=commit;h=f9ee129775caeb7dc494c5bf0f4ba69ceab34950

 #define CONFIG_NR_DRAM_BANKS           2               /* we have 2 banks of DRAM */
 #define PHYS_DRAM_1                    0x80000000      /* DRAM Bank #1 */
-#define PHYS_DRAM_1_SIZE               0x40000000      /* 1 GB */
-#define PHYS_DRAM_2                    0xC0000000      /* DRAM Bank #2 */
-#define PHYS_DRAM_2_SIZE               0x40000000      /* 1 GB */
+#define PHYS_DRAM_1_SIZE               0x20000000      /* 512 MB */
+#define PHYS_DRAM_2                    0xA0000000      /* DRAM Bank #2 */
+#define PHYS_DRAM_2_SIZE               0x20000000      /* 512 MB */

Thus in your 512MB case, these should be the correct settings:

#define CONFIG_NR_DRAM_BANKS           2               /* we have 2 banks of DRAM */
#define PHYS_DRAM_1                       0x80000000      /* DRAM Bank #1 */
#define PHYS_DRAM_1_SIZE              0x10000000      /* 256 MB */
#define PHYS_DRAM_2                       0xA0000000      /* DRAM Bank #2 */
#define PHYS_DRAM_2_SIZE              0x10000000      /* 256 GB */

Jorge Fernandez said:

2) Any modification has to be done in the kernel sources?

No, I do not think you need to modify anything in the kernel sources (ti-ezsdk_dm814x-evm_5_04_00_11/board-support/linux-2.6.37-psp04.04.00.01)

Jorge Fernandez said:

3) What's the command line I have to set for this configuration? Is the next one correct?

setenv bootargs 'console=ttyO0,115200n8 rootwait root=/dev/mmcblk0p2 rw mem=256M ip=off noinitrd'

mem parameter should be 176M (not 256M). See http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map#Step_2.1:_Change_Linux_Memory_size_2 and http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map#Linux_Kernel_Memory

See also http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/186056.aspx

Make sure you are also executing the rest of the steps in the wiki:

http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map#Step_2.2:_Change_Location_of_Video_Frame_Buffers_2

http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map#Step_2.4:_Update_memory_map_for_Linux_side_app_2

Best regards,
Pavel

Hi Pavel,

Then, I understand from your answer that the point 1) is correct (as the link explains) ??

1) UBOOT: arch/arm/include/asm/arch-ti81xx/ddr_defs_ti814x.h

// Two 256MB sections with 128-byte interleaved (hole in b/w)
#define PG2_1_DMM_LISA_MAP__0        0x0
#define PG2_1_DMM_LISA_MAP__1        0x0
#define PG2_1_DMM_LISA_MAP__2        0x80540300
#define PG2_1_DMM_LISA_MAP__3        0xA0540300

Pavel Botev said:

Please note that the default /include/config/ti8148_evm.h file is wrong, as it reports 2GB in u-boot, while the actual DRAM size is 1GB. This is fixed with the below u-boot patch:

http://arago-project.org/git/projects/u-boot-omap3.git?p=projects/u-boot-omap3.git;a=commit;h=f9ee129775caeb7dc494c5bf0f4ba69ceab34950

 #define CONFIG_NR_DRAM_BANKS           2               /* we have 2 banks of DRAM */
 #define PHYS_DRAM_1                    0x80000000      /* DRAM Bank #1 */
-#define PHYS_DRAM_1_SIZE               0x40000000      /* 1 GB */
-#define PHYS_DRAM_2                    0xC0000000      /* DRAM Bank #2 */
-#define PHYS_DRAM_2_SIZE               0x40000000      /* 1 GB */
+#define PHYS_DRAM_1_SIZE               0x20000000      /* 512 MB */
+#define PHYS_DRAM_2                    0xA0000000      /* DRAM Bank #2 */
+#define PHYS_DRAM_2_SIZE               0x20000000      /* 512 MB */

Thus in your 512MB case, these should be the correct settings:

#define CONFIG_NR_DRAM_BANKS           2               /* we have 2 banks of DRAM */
#define PHYS_DRAM_1                       0x80000000      /* DRAM Bank #1 */
#define PHYS_DRAM_1_SIZE              0x10000000      /* 256 MB */
#define PHYS_DRAM_2                       0xA0000000      /* DRAM Bank #2 */
#define PHYS_DRAM_2_SIZE              0x10000000      /* 256 GB */

Thanks! I didn't know this patch! But, the hole from 0x90000000 to 0xA0000000, how

its managed? There are a 256MB memory area without memory. We don't have to specify

something in the boot line passed to kernel?

Pavel Botev said:

mem parameter should be 176M (not 256M). See http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map#Step_2.1:_Change_Linux_Memory_size_2 and http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map#Linux_Kernel_Memory

See also http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/186056.aspx

Make sure you are also executing the rest of the steps in the wiki:

http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map#Step_2.2:_Change_Location_of_Video_Frame_Buffers_2

http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map#Step_2.4:_Update_memory_map_for_Linux_side_app_2

This video frame buffer is related to the one used to display the logos? From uboot include/logo.h

you can see:

#define FRAME_BUFFER_ADDRESS        0x96D00000

When I enable using logos (#define CONFIG_TI81XX_VIDEO) then this address is used to map

the video framebuffer and the bmp is memcpy to this address blocking the uboot. Where this framebuffer

must be mapped? Another known memory area to be changed?

Thanks!

Jorge,

Jorge Fernandez said:

Then, I understand from your answer that the point 1) is correct (as the link explains) ??

1) UBOOT: arch/arm/include/asm/arch-ti81xx/ddr_defs_ti814x.h

// Two 256MB sections with 128-byte interleaved (hole in b/w)
#define PG2_1_DMM_LISA_MAP__0        0x0
#define PG2_1_DMM_LISA_MAP__1        0x0
#define PG2_1_DMM_LISA_MAP__2        0x80540300
#define PG2_1_DMM_LISA_MAP__3        0xA0540300

Yes, these settings are correct.

Jorge Fernandez said:

But, the hole from 0x90000000 to 0xA0000000, how

its managed? There are a 256MB memory area without memory. We don't have to specify

something in the boot line passed to kernel?

I do not think you should specify something about this. The whole address range for DDR DRAM is 2GB (0x80000000 to 0xFFFFFFFF). As you are using only 512MB of this 2GB range, the DMM (Dynamic Memory Manager) is configured to address only the 512MB space, not the whole 2GB. For more information, refer to the AM387x TRM, chapter 6 DMM/TILER, 6.2.1.6 Section Mapping and 6.3.4 Address Management Using LISA Sections

Other approach can be to configure the address space with no holes.This also should work.

#define PG2_1_DMM_LISA_MAP__0        0x0
#define PG2_1_DMM_LISA_MAP__1        0x0
#define PG2_1_DMM_LISA_MAP__2        0x0
#define PG2_1_DMM_LISA_MAP__3        0x80540300

#define CONFIG_NR_DRAM_BANKS           2               /* we have 2 banks of DRAM */
#define PHYS_DRAM_1                       0x80000000      /* DRAM Bank #1 */
#define PHYS_DRAM_1_SIZE              0x10000000      /* 256 MB */
#define PHYS_DRAM_2                       0x90000000      /* DRAM Bank #2 */
#define PHYS_DRAM_2_SIZE              0x10000000      /* 256 GB */

Jorge Fernandez said:

This video frame buffer is related to the one used to display the logos?

No, this is Shared Region (SR) between Host (Cortex-A8/DSP) and MC-HDVICP2 and MC-HDVPSS, used to allocate all video buffers. This is the location of the video frame buffers.

In a 512MB system, Linux memory manager is given only one memory segment of reduced size (mem=176M@0x80000000) and the Shared Region for video buffers is shifted to a different place to fit within 512MB, while in 1GB mem=364M@0x80000000 mem=320M@0x9FC00000.

Jorge Fernandez said:

Where this framebuffer

must be mapped? Another known memory area to be changed?

Change location of IPC_SR_FRAME_BUFFERS to 0xAB000000. This change needs to be done in the firmware loader input file. Update the system_addr and slave_virtual_addr values for IPC_SR_FRAME_BUFFERS from 0xB3D00000 to 0xAB000000 in the source memsegdef_default.c

ti-ezsdk_dm814x-evm_5_04_00_11/board-support/media-controller-utils_2_05_00_17/src/firmware_loader/memsegdef_default.c 

 /* Segment 3 */
  {
   1,                           /* valid */
   "IPC_SR_FRAME_BUFFERS",      /* name */
   0x0BC00000,                  /* size */
   LDR_SEGMENT_TYPE_DYNAMIC_SHARED_HEAP,        /* seg_type */
   0,                           /* flags */
   0xB3D00000,                  /* system_addr */              -----> 0xAB000000
   0xB3D00000,                  /* slave_virtual_addr */       -----> 0xAB000000
   1,                           /* master_core_id */
   (1 << LDR_CORE_ID_VM3) | (1 << LDR_CORE_ID_DM3) | (1 << LDR_CORE_ID_A8),
   /* core_id_mask */
   (1 << LDR_CORE_ID_VM3) | (1 << LDR_CORE_ID_DM3),     /* cache_enable_mask */
   (1 << LDR_CORE_ID_VM3) | (1 << LDR_CORE_ID_DM3),     /* cache_operation_mask
                                                         */
   2                            /* shared_region_id */
  },

Rebuild the firmware loader and copy the generated firmware loader in the target filesystem ($(EZSDK_ROOT)/filesys/usr/bin)

Regards,
Pavel

Hi! I'm beginning to understand it all a little more...

Pavel Botev said:

I do not think you should specify something about this. The whole address range for DDR DRAM is 2GB (0x80000000 to 0xFFFFFFFF). As you are using only 512MB of this 2GB range, the DMM (Dynamic Memory Manager) is configured to address only the 512MB space, not the whole 2GB. For more information, refer to the AM387x TRM, chapter 6 DMM/TILER, 6.2.1.6 Section Mapping and 6.3.4 Address Management Using LISA Sections

Other approach can be to configure the address space with no holes.This also should work.

#define PG2_1_DMM_LISA_MAP__0        0x0
#define PG2_1_DMM_LISA_MAP__1        0x0
#define PG2_1_DMM_LISA_MAP__2        0x0
#define PG2_1_DMM_LISA_MAP__3        0x80540300

#define CONFIG_NR_DRAM_BANKS           2               /* we have 2 banks of DRAM */
#define PHYS_DRAM_1                       0x80000000      /* DRAM Bank #1 */
#define PHYS_DRAM_1_SIZE              0x10000000      /* 256 MB */
#define PHYS_DRAM_2                       0x90000000      /* DRAM Bank #2 */
#define PHYS_DRAM_2_SIZE              0x10000000      /* 256 GB */

I'll go this way, i think is more clear. Any advantages from defining LISA_MAP_2 and LISA_MAP_3

or only definning LISA_MAP_3? Interleaving?

Pavel Botev said:

No, this is Shared Region (SR) between Host (Cortex-A8/DSP) and MC-HDVICP2 and MC-HDVPSS, used to allocate all video buffers. This is the location of the video frame buffers.

In a 512MB system, Linux memory manager is given only one memory segment of reduced size (mem=176M@0x80000000) and the Shared Region for video buffers is shifted to a different place to fit within 512MB, while in 1GB mem=364M@0x80000000 mem=320M@0x9FC00000.

Change location of IPC_SR_FRAME_BUFFERS to 0xAB000000. This change needs to be done in the firmware loader input file. Update the system_addr and slave_virtual_addr values for IPC_SR_FRAME_BUFFERS from 0xB3D00000 to 0xAB000000 in the source memsegdef_default.c

ti-ezsdk_dm814x-evm_5_04_00_11/board-support/media-controller-utils_2_05_00_17/src/firmware_loader/memsegdef_default.c 

 /* Segment 3 */
  {
   1,                           /* valid */
   "IPC_SR_FRAME_BUFFERS",      /* name */
   0x0BC00000,                  /* size */
   LDR_SEGMENT_TYPE_DYNAMIC_SHARED_HEAP,        /* seg_type */
   0,                           /* flags */
   0xB3D00000,                  /* system_addr */              -----> 0xAB000000
   0xB3D00000,                  /* slave_virtual_addr */       -----> 0xAB000000
   1,                           /* master_core_id */
   (1 << LDR_CORE_ID_VM3) | (1 << LDR_CORE_ID_DM3) | (1 << LDR_CORE_ID_A8),
   /* core_id_mask */
   (1 << LDR_CORE_ID_VM3) | (1 << LDR_CORE_ID_DM3),     /* cache_enable_mask */
   (1 << LDR_CORE_ID_VM3) | (1 << LDR_CORE_ID_DM3),     /* cache_operation_mask
                                                         */
   2                            /* shared_region_id */
  },

Rebuild the firmware loader and copy the generated firmware loader in the target filesystem ($(EZSDK_ROOT)/filesys/usr/bin)

Very good explained! I have a little question. I see that from the 512MB only 122MB are free for

use once linux boot. There is some way to free memory? For instance, we are not going to use the

capture part of the video processors, only we are interested in the output framebuffer, could be any

memory be released to the system? Any link explaining this kind of topics?

Regards!!

Jorge,

Jorge Fernandez said:

I'll go this way, i think is more clear. Any advantages from defining LISA_MAP_2 and LISA_MAP_3

or only definning LISA_MAP_3? Interleaving?

Going this way, you also have the 128-byte interleaving, same as the other way:

#define PG2_1_DMM_LISA_MAP__2        0x0
#define PG2_1_DMM_LISA_MAP__3        0x80540300

#define PG2_1_DMM_LISA_MAP__2        0x80540300
#define PG2_1_DMM_LISA_MAP__3        0xA0540300

In both cases DMM_LISA_MAP_x[19:18] SDRC_INTL = 0x1 (128-byte interleaving mode)

All 4 DMM LISA sections are the same (0,1,2 and 3), only the priority is different. DMM_LISA_MAP__3 is with highest priority, while DMM_LISA_MAP__0 is with lowest priority. If two sections overlap, then the property of higher section number will be applied.

You can also use the below settings:

#define PG2_1_DMM_LISA_MAP__0        0x0
#define PG2_1_DMM_LISA_MAP__1        0x0
#define PG2_1_DMM_LISA_MAP__2        0x80540300
#define PG2_1_DMM_LISA_MAP__3        0x90540300

In theory all these 3 variants of the DMM LISA MAP registers settings should work for 512MB with the same advantages. I can not see one to have some advantages over the other 2. But the wiki page recommend this variant:

#define PG2_1_DMM_LISA_MAP__0        0x0
#define PG2_1_DMM_LISA_MAP__1        0x0
#define PG2_1_DMM_LISA_MAP__2        0x80540300
#define PG2_1_DMM_LISA_MAP__3        0xA0540300

And I assume only this variant is tested, so I recommend you to use this one, although I can not see any disadvantages in other two methods (in theory), but I have not personally test them, so keep in mind this.

In AM387x TRM, section 6.3.1 DMM Basic Register Setup, we have the below statement:

6. Program Section mapping, based on the SDRAM configuration of the system, which depends on the size of the SDRAM on one or both the banks.
• Example 1: Symmetrical DDRs on both EMIF banks. Each size = 512MB to add up to 1GB of total SDRAM memory. In all DMM_LISA_MAP__0..3 registers, program value 8064 0300h, which implies 1GB section starting from System address : 8000 0000h, mapped to 0000 0000h of both EMIF0 and EMIF1, with interleaving of 128 bytes enabled. Note that the above example uses only one DMM section and the three other are identical. There are other ways to define up-to 4 sections and configure each differently

Jorge Fernandez said:

I see that from the 512MB only 122MB are free for

use once linux boot. There is some way to free memory? For instance, we are not going to use the

capture part of the video processors, only we are interested in the output framebuffer, could be any

memory be released to the system? Any link explaining this kind of topics?

Have a look in the 512MB memory map:

http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map#Step_2.4:_Update_memory_map_for_Linux_side_app_2

The first partition (LINUX_MEM_1 = 176MB) is given to the Linux kernel memory manager. Do you need to increase this memory? Configure different memory split for kernel/user memory split, or use HIGHMEM support to allocate more memory to Linux.

Best regards,
Pavel

Jorge,

Please try also with adding the below two parameters in your boot arguments:

vmalloc=500M  notifyk.vpssm3_sva=0xBF90000

Regards,
Pavel