>From: Marek Vasut [mailto:ma...@denx.de] >Sent: Montag, 18. Dezember 2017 10:17 >On 12/18/2017 10:02 AM, linux-kernel-...@beckhoff.com wrote: >> From: Patrick Bruenn <p.bru...@beckhoff.com> >> >> Static variables are not available during board_init_f(). > >They are, since the board runs from RAM at that point already. > From reading the README and common/board_f.c I got the impression, that dram_init() is called before it's save to access mx53_dram_size. And as that change seemed to cure the strange behavior I described in [1] and [2], I prepared a patch for my board, which ended up to be requested for m53evk and mx53loco, too.
>> '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(). >> >> Reused dram initialization functions from arch/arm/mach- >imx/mx5/mx53_dram.c >> >> Signed-off-by: Patrick Bruenn <p.bru...@beckhoff.com> >> >> --- >> >> Changes in v2: None >> >> >> Only compile tested with make m53evk_defconfig > >Are you sure this patch retains the original functionality ? Note the >warning ... Effectively it changes: - return mx53_dram_size[0]; + return get_ram_size((void *)PHYS_SDRAM_1, 1 << 30); So, yes I am convinced that get_effective_memsize() still returns only the size of the first dram bank. However, I would be fine with just keeping the changes to my board (cx9020). And if anyone has a better idea of what might be the root cause of [1] and [2], I would absolute appreciate any input to that. Best regards and thanks in advance for any feedback, Patrick [1] https://lists.denx.de/pipermail/u-boot/2017-November/313214.html [2] https://lists.denx.de/pipermail/u-boot/2017-December/314480.html --- Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
