arm: mx5: Fix memory slowness on MX53QSB
PATCH v2 1/4 arm: mx5: Fix memory slowness on MX53QSB
Fix memory access slowness on i.MX53 MX53QSB board. Let us inspect the
issue: First of all, the i.MX53 CPU has two memory banks mapped at 0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of DRAM memory. Notice that the memory area is not continuous. On MX53QSB, each of the banks contain 512MiB of DRAM, which makes a total of 1GiB of memory available to the system.
The problem is how the relocation of U-Boot is treated on i.MX53 . The U-Boot is placed at the ((start of first DRAM partition) + (gd->ram_size)) . This in turn poses a problem, since in our case, the gd->ram_size is 1GiB, the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory. Thus, with this algorithm, U-Boot is placed at offset:
0x7000_0000 + 1GiB - sizeof(u-boot and some small margin)
This is past the DRAM available in the first bank on MX53QSB, but is still within the address range of the first DRAM bank. Because of the memory wrap-around, the data can still be read and written to this area, but the access is much slower.
There were two ideas how to solve this problem, first was to map both of the available DRAM chunks next to one another by using MMU, second was to define CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED to size of the memory in the first DRAM bank. We choose the later because it turns out the former is not applicable afterall. The former cannot be used in case Linux kernel was loaded into the second DRAM bank area, which would be remapped and one would try booting the kernel, since at some point before the kernel is started, the MMU would be turned off, which would destroy the mapping and hang the system.
--- include/configs/mx53loco.h | 2 ++ 1 file changed, 2 insertions(+)
V2: Reword the commit message
include/configs/mx53loco.h +2 -0
@@ -199,6 +199,8 @@#define PHYS_SDRAM_2 CSD1_BASE_ADDR#define PHYS_SDRAM_2_SIZE (512 * 1024 * 1024)#define PHYS_SDRAM_SIZE (PHYS_SDRAM_1_SIZE + PHYS_SDRAM_2_SIZE) +#define CONFIG_VERY_BIG_RAM +#define CONFIG_MAX_MEM_MAPPED PHYS_SDRAM_1_SIZE#define CONFIG_SYS_SDRAM_BASE (PHYS_SDRAM_1)#define CONFIG_SYS_INIT_RAM_ADDR (IRAM_BASE_ADDR)
Signature · 1 line
1.9.0
PATCH v3 2/4 arm: mx5: Avoid hardcoding memory sizes on MX53QSB
The DRAM size can be easily detected at runtime on i.MX53. Implement such detection on MX53QSB and adjust the rest of the macros accordingly to use the detected values.
An important thing to note here is that we had to override the function for trimming the effective DRAM address, get_effective_memsize(). That is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of the available DRAM and we don't have gd->bd->bi_dram[0].size set up at the time the function is called, thus we cannot put this into the macro CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the size of the first DRAM block which we just detected.
--- board/freescale/mx53loco/mx53loco.c | 31 ++++++++++++++++++++++++------- include/configs/mx53loco.h | 12 +++++------- 2 files changed, 29 insertions(+), 14 deletions(-)
V2: Use linux/sizes.h instead of asm/sizes.h
V3: - Drop use of sizes.h completely
- Add beefy comment as to why we override get_effective_memsize()
- Drop CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED as we no longer need it if we override get_effective_memsize()
board/freescale/mx53loco/mx53loco.c +24 -7
@@ -30,24 +30,41 @@DECLARE_GLOBAL_DATA_PTR ; -int dram_init (void ) +static uint32_t mx53_dram_size[2 ]; + +phys_size_t get_effective_memsize (void ) { -u32 size1, size2; +/* +* WARNING: We must override get_effective_memsize() function here +* to report only the size of the first DRAM bank. This is to make +* U-Boot relocator place U-Boot into valid memory, that is, at the +* end of the first DRAM bank. If we did not override this function +* like so, U-Boot would be placed at the address of the first DRAM +* bank + total DRAM size - sizeof(uboot), which in the setup where +* each DRAM bank contains 512MiB of DRAM would result in placing +* U-Boot into invalid memory area close to the end of the first +* DRAM bank. +*/ +return mx53_dram_size[0 ]; +} - size1 =get_ram_size ((void *)PHYS_SDRAM_1 ,PHYS_SDRAM_1_SIZE ); - size2 =get_ram_size ((void *)PHYS_SDRAM_2 ,PHYS_SDRAM_2_SIZE ); +int dram_init (void ) +{ + mx53_dram_size[0 ] =get_ram_size ((void *)PHYS_SDRAM_1 ,1 <<30 ); + mx53_dram_size[1 ] =get_ram_size ((void *)PHYS_SDRAM_2 ,1 <<30 ); - gd->ram_size = size1 + size2; + gd->ram_size = mx53_dram_size[0 ] + mx53_dram_size[1 ];return 0 ; } +void dram_init_banksize (void ) { gd->bd->bi_dram[0 ].start =PHYS_SDRAM_1 ; - gd->bd->bi_dram[0 ].size =PHYS_SDRAM_1_SIZE ; + gd->bd->bi_dram[0 ].size = mx53_dram_size[0 ]; gd->bd->bi_dram[1 ].start =PHYS_SDRAM_2 ; - gd->bd->bi_dram[1 ].size =PHYS_SDRAM_2_SIZE ; + gd->bd->bi_dram[1 ].size = mx53_dram_size[1 ]; }u32 get_board_rev (void )
include/configs/mx53loco.h +5 -7
@@ -194,13 +194,11 @@/* Physical Memory Map */ #define CONFIG_NR_DRAM_BANKS 2 -#define PHYS_SDRAM_1 CSD0_BASE_ADDR -#define PHYS_SDRAM_1_SIZE (512 * 1024 * 1024) -#define PHYS_SDRAM_2 CSD1_BASE_ADDR -#define PHYS_SDRAM_2_SIZE (512 * 1024 * 1024) -#define PHYS_SDRAM_SIZE (PHYS_SDRAM_1_SIZE + PHYS_SDRAM_2_SIZE) -#define CONFIG_VERY_BIG_RAM -#define CONFIG_MAX_MEM_MAPPED PHYS_SDRAM_1_SIZE +#define PHYS_SDRAM_1 CSD0_BASE_ADDR +#define PHYS_SDRAM_1_SIZE (gd->bd->bi_dram[0].size) +#define PHYS_SDRAM_2 CSD1_BASE_ADDR +#define PHYS_SDRAM_2_SIZE (gd->bd->bi_dram[1].size) +#define PHYS_SDRAM_SIZE (gd->ram_size)#define CONFIG_SYS_SDRAM_BASE (PHYS_SDRAM_1)#define CONFIG_SYS_INIT_RAM_ADDR (IRAM_BASE_ADDR)
Signature · 1 line
1.9.0
PATCH v3 2/4 arm: mx5: Avoid hardcoding memory sizes on MX53QSB
Quoted 12 lines · Marek Vasut
The DRAM size can be easily detected at runtime on i.MX53. Implement such detection on MX53QSB and adjust the rest of the macros accordingly to use the detected values.
An important thing to note here is that we had to override the function for trimming the effective DRAM address,
get_effective_memsize(). That is because the function usesCONFIG_MAX_MEM_MAPPEDas the upper bound of the available DRAM and we don't have gd->bd->bi_dram[0].size set up at the time the function is called, thus we cannot put this into the macroCONFIG_MAX_MEM_MAPPED. Instead, we use custom override where we use the size of the first DRAM block which we just detected.
Quoted 5 lines
Signed-off-by Marek Vasut <[email protected]>Cc Fabio Estevam <[email protected]>Cc Stefano Babic <[email protected]>Cc Wolfgang Denk <[email protected]>---
Applied to u-boot-imx, thanks !
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v2 3/4 arm: mx5: Fix memory slowness on M53EVK
In reply to Marek VasutFix memory access slowness on i.MX53 M53EVK board. Let us inspect the
issue: First of all, the i.MX53 CPU has two memory banks mapped at 0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of DRAM memory. Notice that the memory area is not continuous. On M53EVK, each of the banks contain 512MiB of DRAM, which makes a total of 1GiB of memory available to the system.
The problem is how the relocation of U-Boot is treated on i.MX53 . The U-Boot is placed at the ((start of first DRAM partition) + (gd->ram_size)) . This in turn poses a problem, since in our case, the gd->ram_size is 1GiB, the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory. Thus, with this algorithm, U-Boot is placed at offset:
0x7000_0000 + 1GiB - sizeof(u-boot and some small margin)
This is past the DRAM available in the first bank on M53EVK, but is still within the address range of the first DRAM bank. Because of the memory wrap-around, the data can still be read and written to this area, but the access is much slower.
There were two ideas how to solve this problem, first was to map both of the available DRAM chunks next to one another by using MMU, second was to define CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED to size of the memory in the first DRAM bank. We choose the later because it turns out the former is not applicable afterall. The former cannot be used in case Linux kernel was loaded into the second DRAM bank area, which would be remapped and one would try booting the kernel, since at some point before the kernel is started, the MMU would be turned off, which would destroy the mapping and hang the system.
--- include/configs/m53evk.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
V2: Reword the commit message
include/configs/m53evk.h +3 -1
@@ -52,7 +52,9 @@#define PHYS_SDRAM_SIZE (PHYS_SDRAM_1_SIZE + PHYS_SDRAM_2_SIZE)#define CONFIG_SYS_MALLOC_LEN (10 * 1024 * 1024)#define CONFIG_SYS_MEMTEST_START 0x70000000 -#define CONFIG_SYS_MEMTEST_END 0xaff00000 +#define CONFIG_SYS_MEMTEST_END 0x8ff00000 +#define CONFIG_VERY_BIG_RAM +#define CONFIG_MAX_MEM_MAPPED PHYS_SDRAM_1_SIZE#define CONFIG_SYS_SDRAM_BASE (PHYS_SDRAM_1)#define CONFIG_SYS_INIT_RAM_ADDR (IRAM_BASE_ADDR)
Signature · 1 line
1.9.0
PATCH v2 3/4 arm: mx5: Fix memory slowness on M53EVK
Quoted 30 lines · Marek Vasut
Fix memory access slowness on i.MX53 M53EVK board. Let us inspect the
issue: First of all, the i.MX53 CPU has two memory banks mapped at 0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of DRAM memory. Notice that the memory area is not continuous. On M53EVK, each of the banks contain 512MiB of DRAM, which makes a total of 1GiB of memory available to the system.The problem is how the relocation of U-Boot is treated on i.MX53 . The U-Boot is placed at the ((start of first DRAM partition) + (
gd->ram_size)) . This in turn poses a problem, since in our case, thegd->ram_sizeis 1GiB, the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory. Thus, with this algorithm, U-Boot is placed at offset:0x7000_0000 + 1GiB - sizeof(u-boot and some small margin)This is past the DRAM available in the first bank on M53EVK, but is still within the address range of the first DRAM bank. Because of the memory wrap-around, the data can still be read and written to this area, but the access is much slower.
There were two ideas how to solve this problem, first was to map both of the available DRAM chunks next to one another by using MMU, second was to define
CONFIG_VERY_BIG_RAMandCONFIG_MAX_MEM_MAPPEDto size of the memory in the first DRAM bank. We choose the later because it turns out the former is not applicable afterall. The former cannot be used in case Linux kernel was loaded into the second DRAM bank area, which would be remapped and one would try booting the kernel, since at some point before the kernel is started, the MMU would be turned off, which would destroy the mapping and hang the system.
Quoted 5 lines
Signed-off-by Marek Vasut <[email protected]>Cc Fabio Estevam <[email protected]>Cc Stefano Babic <[email protected]>Cc Wolfgang Denk <[email protected]>---
Applied to u-boot-imx, thanks !
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v3 4/4 arm: mx5: Avoid hardcoding memory sizes on M53EVK
In reply to Marek VasutThe DRAM size can be easily detected at runtime on i.MX53. Implement such detection on M53EVK and adjust the rest of the macros accordingly to use the detected values.
An important thing to note here is that we had to override the function for trimming the effective DRAM address, get_effective_memsize(). That is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of the available DRAM and we don't have gd->bd->bi_dram[0].size set up at the time the function is called, thus we cannot put this into the macro CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the size of the first DRAM block which we just detected.
--- board/denx/m53evk/m53evk.c | 31 ++++++++++++++++++++++++------- include/configs/m53evk.h | 8 +++----- 2 files changed, 27 insertions(+), 12 deletions(-)
V2: Use linux/sizes.h instead of asm/sizes.h
V3: - Drop use of sizes.h completely
- Add beefy comment as to why we override get_effective_memsize()
- Drop CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED as we no longer need it if we override get_effective_memsize()
board/denx/m53evk/m53evk.c +24 -7
@@ -31,24 +31,41 @@DECLARE_GLOBAL_DATA_PTR ; -int dram_init (void ) +static uint32_t mx53_dram_size[2 ]; + +phys_size_t get_effective_memsize (void ) { -u32 size1, size2; +/* +* WARNING: We must override get_effective_memsize() function here +* to report only the size of the first DRAM bank. This is to make +* U-Boot relocator place U-Boot into valid memory, that is, at the +* end of the first DRAM bank. If we did not override this function +* like so, U-Boot would be placed at the address of the first DRAM +* bank + total DRAM size - sizeof(uboot), which in the setup where +* each DRAM bank contains 512MiB of DRAM would result in placing +* U-Boot into invalid memory area close to the end of the first +* DRAM bank. +*/ +return mx53_dram_size[0 ]; +} - size1 =get_ram_size ((void *)PHYS_SDRAM_1 ,PHYS_SDRAM_1_SIZE ); - size2 =get_ram_size ((void *)PHYS_SDRAM_2 ,PHYS_SDRAM_2_SIZE ); +int dram_init (void ) +{ + mx53_dram_size[0 ] =get_ram_size ((void *)PHYS_SDRAM_1 ,1 <<30 ); + mx53_dram_size[1 ] =get_ram_size ((void *)PHYS_SDRAM_2 ,1 <<30 ); - gd->ram_size = size1 + size2; + gd->ram_size = mx53_dram_size[0 ] + mx53_dram_size[1 ];return 0 ; } +void dram_init_banksize (void ) { gd->bd->bi_dram[0 ].start =PHYS_SDRAM_1 ; - gd->bd->bi_dram[0 ].size =PHYS_SDRAM_1_SIZE ; + gd->bd->bi_dram[0 ].size = mx53_dram_size[0 ]; gd->bd->bi_dram[1 ].start =PHYS_SDRAM_2 ; - gd->bd->bi_dram[1 ].size =PHYS_SDRAM_2_SIZE ; + gd->bd->bi_dram[1 ].size = mx53_dram_size[1 ]; }static void setup_iomux_uart (void )
include/configs/m53evk.h +3 -5
@@ -46,15 +46,13 @@*/ #define CONFIG_NR_DRAM_BANKS 2#define PHYS_SDRAM_1 CSD0_BASE_ADDR -#define PHYS_SDRAM_1_SIZE (512 * 1024 * 1024) +#define PHYS_SDRAM_1_SIZE (gd->bd->bi_dram[0].size)#define PHYS_SDRAM_2 CSD1_BASE_ADDR -#define PHYS_SDRAM_2_SIZE (512 * 1024 * 1024) -#define PHYS_SDRAM_SIZE (PHYS_SDRAM_1_SIZE + PHYS_SDRAM_2_SIZE) +#define PHYS_SDRAM_2_SIZE (gd->bd->bi_dram[1].size) +#define PHYS_SDRAM_SIZE (gd->ram_size)#define CONFIG_SYS_MALLOC_LEN (10 * 1024 * 1024)#define CONFIG_SYS_MEMTEST_START 0x70000000#define CONFIG_SYS_MEMTEST_END 0x8ff00000 -#define CONFIG_VERY_BIG_RAM -#define CONFIG_MAX_MEM_MAPPED PHYS_SDRAM_1_SIZE#define CONFIG_SYS_SDRAM_BASE (PHYS_SDRAM_1)#define CONFIG_SYS_INIT_RAM_ADDR (IRAM_BASE_ADDR)
Signature · 1 line
1.9.0
PATCH v3 4/4 arm: mx5: Avoid hardcoding memory sizes on M53EVK
Quoted 12 lines · Marek Vasut
The DRAM size can be easily detected at runtime on i.MX53. Implement such detection on M53EVK and adjust the rest of the macros accordingly to use the detected values.
An important thing to note here is that we had to override the function for trimming the effective DRAM address,
get_effective_memsize(). That is because the function usesCONFIG_MAX_MEM_MAPPEDas the upper bound of the available DRAM and we don't have gd->bd->bi_dram[0].size set up at the time the function is called, thus we cannot put this into the macroCONFIG_MAX_MEM_MAPPED. Instead, we use custom override where we use the size of the first DRAM block which we just detected.
Quoted 5 lines
Signed-off-by Marek Vasut <[email protected]>Cc Fabio Estevam <[email protected]>Cc Stefano Babic <[email protected]>Cc Wolfgang Denk <[email protected]>---
Applied to u-boot-imx, thanks !
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v2 1/4 arm: mx5: Fix memory slowness on MX53QSB
In reply to Marek VasutHi Marek,
Quoted 46 lines · Marek Vasut
Fix memory access slowness on i.MX53 MX53QSB board. Let us inspect the
issue: First of all, the i.MX53 CPU has two memory banks mapped at 0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of DRAM memory. Notice that the memory area is not continuous. On MX53QSB, each of the banks contain 512MiB of DRAM, which makes a total of 1GiB of memory available to the system.The problem is how the relocation of U-Boot is treated on i.MX53 . The U-Boot is placed at the ((start of first DRAM partition) + (
gd->ram_size)) . This in turn poses a problem, since in our case, thegd->ram_sizeis 1GiB, the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory. Thus, with this algorithm, U-Boot is placed at offset:0x7000_0000 + 1GiB - sizeof(u-boot and some small margin)This is past the DRAM available in the first bank on MX53QSB, but is still within the address range of the first DRAM bank. Because of the memory wrap-around, the data can still be read and written to this area, but the access is much slower.
There were two ideas how to solve this problem, first was to map both of the available DRAM chunks next to one another by using MMU, second was to define
CONFIG_VERY_BIG_RAMandCONFIG_MAX_MEM_MAPPEDto size of the memory in the first DRAM bank. We choose the later because it turns out the former is not applicable afterall. The former cannot be used in case Linux kernel was loaded into the second DRAM bank area, which would be remapped and one would try booting the kernel, since at some point before the kernel is started, the MMU would be turned off, which would destroy the mapping and hang the system.Signed-off-by Marek Vasut <[email protected]>Cc Fabio Estevam <[email protected]>Cc Stefano Babic <[email protected]>Cc Wolfgang Denk <[email protected]>--- include/configs/mx53loco.h | 2 ++ 1 file changed, 2 insertions(+)V2: Reword the commit message
include/configs/mx53loco.h +0
-0
include/configs/mx53loco.h line 206
Quoted 8 lines
include/configs/mx53loco.h +2
-0@@ -199,6 +199,8 @@#define PHYS_SDRAM_2 CSD1_BASE_ADDR#define PHYS_SDRAM_2_SIZE (512 * 1024 * 1024)#define PHYS_SDRAM_SIZE (PHYS_SDRAM_1_SIZE + PHYS_SDRAM_2_SIZE) +#define CONFIG_VERY_BIG_RAM +#define CONFIG_MAX_MEM_MAPPED PHYS_SDRAM_1_SIZE#define CONFIG_SYS_SDRAM_BASE (PHYS_SDRAM_1)#define CONFIG_SYS_INIT_RAM_ADDR (IRAM_BASE_ADDR)
Nice works, thanks ! I will push it soon.
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v2 1/4 arm: mx5: Fix memory slowness on MX53QSB
Quoted 55 lines · Stefano Babic
Hi Marek,
Quoted 52 lines · Marek Vasut
Fix memory access slowness on i.MX53 MX53QSB board. Let us inspect the
issue: First of all, the i.MX53 CPU has two memory banks mapped at 0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of DRAM memory. Notice that the memory area is not continuous. On MX53QSB, each of the banks contain 512MiB of DRAM, which makes a total of 1GiB of memory available to the system.The problem is how the relocation of U-Boot is treated on i.MX53 . The U-Boot is placed at the ((start of first DRAM partition) + (
gd->ram_size)) . This in turn poses a problem, since in our case, thegd->ram_sizeis 1GiB, the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory.Thus, with this algorithm, U-Boot is placed at offset:
0x7000_0000 + 1GiB - sizeof(u-boot and some small margin)This is past the DRAM available in the first bank on MX53QSB, but is still within the address range of the first DRAM bank. Because of the memory wrap-around, the data can still be read and written to this area, but the access is much slower.
There were two ideas how to solve this problem, first was to map both of the available DRAM chunks next to one another by using MMU, second was to define
CONFIG_VERY_BIG_RAMandCONFIG_MAX_MEM_MAPPEDto size of the memory in the first DRAM bank. We choose the later because it turns out the former is not applicable afterall. The former cannot be used in case Linux kernel was loaded into the second DRAM bank area, which would be remapped and one would try booting the kernel, since at some point before the kernel is started, the MMU would be turned off, which would destroy the mapping and hang the system.Signed-off-by Marek Vasut <[email protected]>Cc Fabio Estevam <[email protected]>Cc Stefano Babic <[email protected]>Cc Wolfgang Denk <[email protected]>---
include/configs/mx53loco.h | 2 ++ 1 file changed, 2 insertions(+)V2: Reword the commit message
include/configs/mx53loco.h +0
-0@@ -199,6 +199,8 @@#define PHYS_SDRAM_2 CSD1_BASE_ADDR#define PHYS_SDRAM_2_SIZE (512 * 1024 * 1024)#define PHYS_SDRAM_SIZE (PHYS_SDRAM_1_SIZE + PHYS_SDRAM_2_SIZE)
Quoted 7 lines
Quoted 5 lines
include/configs/mx53loco.h +2
-0+#define CONFIG_VERY_BIG_RAM +#define CONFIG_MAX_MEM_MAPPED PHYS_SDRAM_1_SIZE#define
CONFIG_SYS_SDRAM_BASE(PHYS_SDRAM_1)
#defineCONFIG_SYS_INIT_RAM_ADDR(IRAM_BASE_ADDR)Nice works, thanks ! I will push it soon.
Thanks :)
There are a few more patches in your PW queue from me, please check them and apply as seen fit. Thanks again!
Best regards,
Marek Vasut
PATCH v2 1/4 arm: mx5: Fix memory slowness on MX53QSB
Hi Marek,
Quoted 4 lines · Marek Vasut
Thanks :)
There are a few more patches in your PW queue from me, please check them and apply as seen fit. Thanks again!
All patches from you (or from others) that are ok for me and ready to be merged are marked by me in PW as "under reviewed" - there is not a "review passed " or "ready-to-be-merged" status. You can check yourself if some of your patches are missing.
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v2 1/4 arm: mx5: Fix memory slowness on MX53QSB
Quoted 5 lines · Stefano Babic
Hi Marek,
Quoted 2 lines · Marek Vasut
Thanks :)
Quoted 7 lines
Quoted 2 lines
There are a few more patches in your PW queue from me, please check them and apply as seen fit. Thanks again!
All patches from you (or from others) that are ok for me and ready to be merged are marked by me in PW as "under reviewed" - there is not a "review passed " or "ready-to-be-merged" status. You can check yourself if some of your patches are missing.
Will do, but I think you got them all. Thanks!
Best regards,
Marek Vasut
PATCH v2 1/4 arm: mx5: Fix memory slowness on MX53QSB
In reply to Marek VasutQuoted 30 lines · Marek Vasut
Fix memory access slowness on i.MX53 MX53QSB board. Let us inspect the
issue: First of all, the i.MX53 CPU has two memory banks mapped at 0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of DRAM memory. Notice that the memory area is not continuous. On MX53QSB, each of the banks contain 512MiB of DRAM, which makes a total of 1GiB of memory available to the system.The problem is how the relocation of U-Boot is treated on i.MX53 . The U-Boot is placed at the ((start of first DRAM partition) + (
gd->ram_size)) . This in turn poses a problem, since in our case, thegd->ram_sizeis 1GiB, the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory. Thus, with this algorithm, U-Boot is placed at offset:0x7000_0000 + 1GiB - sizeof(u-boot and some small margin)This is past the DRAM available in the first bank on MX53QSB, but is still within the address range of the first DRAM bank. Because of the memory wrap-around, the data can still be read and written to this area, but the access is much slower.
There were two ideas how to solve this problem, first was to map both of the available DRAM chunks next to one another by using MMU, second was to define
CONFIG_VERY_BIG_RAMandCONFIG_MAX_MEM_MAPPEDto size of the memory in the first DRAM bank. We choose the later because it turns out the former is not applicable afterall. The former cannot be used in case Linux kernel was loaded into the second DRAM bank area, which would be remapped and one would try booting the kernel, since at some point before the kernel is started, the MMU would be turned off, which would destroy the mapping and hang the system.
Quoted 5 lines
Signed-off-by Marek Vasut <[email protected]>Cc Fabio Estevam <[email protected]>Cc Stefano Babic <[email protected]>Cc Wolfgang Denk <[email protected]>---
Applied to u-boot-imx, thanks !
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================