[U-Boot] [PATCH] arm: imx: cx9020: remove usage of mx53_dram_size

From: Patrick Bruenn p.bruenn@beckhoff.com
Global variables are not available during board_init_f(). 'static uint32_t mx53_dram_size[2];' was used in board specific dram_init(), dram_init_banksize() and get_effective_memsize() to avoid multiple calls to get_ram_size().
However multiple calls are better than undefined behavior... This fixes: https://lists.denx.de/pipermail/u-boot/2017-November/313214.html https://lists.denx.de/pipermail/u-boot/2017-December/314480.html
Signed-off-by: Patrick Bruenn p.bruenn@beckhoff.com
---
mx53cx9020 was based on mx53loco, which still uses this global variable. If you agree, this is a bug, I can prepare a similar fix for the QSB. Maybe it makes sense to move the dram_init functions for both boards into something like boards/freescale/common/mx53_dram.c But be aware I have no QSB at hand and could only compile test that patch for mx53loco.
--- board/beckhoff/mx53cx9020/mx53cx9020.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/board/beckhoff/mx53cx9020/mx53cx9020.c b/board/beckhoff/mx53cx9020/mx53cx9020.c index 021bd967c4..d8bdfc27bb 100644 --- a/board/beckhoff/mx53cx9020/mx53cx9020.c +++ b/board/beckhoff/mx53cx9020/mx53cx9020.c @@ -59,8 +59,6 @@ static const u32 CCAT_MODE_RUN = 0x0033DC8F;
DECLARE_GLOBAL_DATA_PTR;
-static uint32_t mx53_dram_size[2]; - phys_size_t get_effective_memsize(void) { /* @@ -74,15 +72,13 @@ phys_size_t get_effective_memsize(void) * U-Boot into invalid memory area close to the end of the first * DRAM bank. */ - return mx53_dram_size[0]; + return get_ram_size((void *)PHYS_SDRAM_1, 1 << 30); }
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 = mx53_dram_size[0] + mx53_dram_size[1]; + gd->ram_size = get_ram_size((void *)PHYS_SDRAM_1, 1 << 30); + gd->ram_size += get_ram_size((void *)PHYS_SDRAM_2, 1 << 30);
return 0; } @@ -90,10 +86,10 @@ int dram_init(void) int dram_init_banksize(void) { gd->bd->bi_dram[0].start = PHYS_SDRAM_1; - gd->bd->bi_dram[0].size = mx53_dram_size[0]; + gd->bd->bi_dram[0].size = get_ram_size((void *)PHYS_SDRAM_1, 1 << 30);
gd->bd->bi_dram[1].start = PHYS_SDRAM_2; - gd->bd->bi_dram[1].size = mx53_dram_size[1]; + gd->bd->bi_dram[1].size = get_ram_size((void *)PHYS_SDRAM_2, 1 << 30);
return 0; }

Hi,
On Fri, 15 Dec 2017 13:56:15 +0100 linux-kernel-dev@beckhoff.com wrote:
From: Patrick Bruenn p.bruenn@beckhoff.com
Global variables are not available during board_init_f().
s/Global/static/
Lothar Waßmann

Hi Lothar,
From: Lothar Waßmann [mailto:LW@KARO-electronics.de] Sent: Freitag, 15. Dezember 2017 15:02
Hi,
On Fri, 15 Dec 2017 13:56:15 +0100 linux-kernel-dev@beckhoff.com wrote:
From: Patrick Bruenn p.bruenn@beckhoff.com
Global variables are not available during board_init_f().
s/Global/static/
I fixed that for v2. Unfortunately everywhere but in the cover letter :-(.
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075

Hi Patrick,
On Fri, Dec 15, 2017 at 10:56 AM, linux-kernel-dev@beckhoff.com wrote:
From: Patrick Bruenn p.bruenn@beckhoff.com
Global variables are not available during board_init_f(). 'static uint32_t mx53_dram_size[2];' was used in board specific dram_init(), dram_init_banksize() and get_effective_memsize() to avoid multiple calls to get_ram_size().
However multiple calls are better than undefined behavior... This fixes: https://lists.denx.de/pipermail/u-boot/2017-November/313214.html https://lists.denx.de/pipermail/u-boot/2017-December/314480.html
Signed-off-by: Patrick Bruenn p.bruenn@beckhoff.com
mx53cx9020 was based on mx53loco, which still uses this global variable. If you agree, this is a bug, I can prepare a similar fix for the QSB. Maybe it makes sense to move the dram_init functions for both boards into something like boards/freescale/common/mx53_dram.c But be aware I have no QSB at hand and could only compile test that patch for mx53loco.
Yes, it makes sense to fix all boards. board/aries/m53evk/m53evk.c would also be affected.
Please prepare a patch that fixes all of them.
Thanks!
participants (4)
-
Fabio Estevam
-
linux-kernel-dev@beckhoff.com
-
Lothar Waßmann
-
Patrick Brünn