Searched hist:"9 ac4fc82071ce346e3885118242ff45d22f69b82" (Results 1 – 3 of 3) sorted by relevance
| /openbmc/u-boot/common/init/ |
| H A D | board_init.c | 9ac4fc82071ce346e3885118242ff45d22f69b82 Thu Nov 12 08:30:19 CST 2015 Fabio Estevam <fabio.estevam@freescale.com> board_init: Change the logic to setup malloc_base
Prior to commit 5ba534d247d418 ("arm: Switch 32-bit ARM to using generic
global_data setup") we used to have assembly code that configured the
malloc_base address.
Since this commit we use the board_init_f_mem() function in C to setup
malloc_base address.
In board_init_f_mem() there was a deliberate choice to support only
early malloc() or full malloc() in SPL, but not both.
Adapt this logic to allow both to be used, one after the other, in SPL.
This issue has been observed in a Congatec board, where we need to
retrieve the manufacturing information from the SPI NOR (the SPI API
calls malloc) prior to configuring the DRAM. In this case as malloc_base
was not configured we always see malloc to fail.
With this change we are able to use malloc in SPL prior to DRAM gets
initialized.
Also update the CONFIG_SYS_SPL_MALLOC_START entry in the README file.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
| /openbmc/u-boot/include/configs/ |
| H A D | zynq-common.h | 83b6464daa017eb142370f537e58f19e8d9f6e53 Mon Nov 23 09:27:38 CST 2015 Michal Simek <michal.simek@xilinx.com> ARM: zynq: Fix location of stack and malloc areas
The patch
"board_init: Change the logic to setup malloc_base"
(sha1: 9ac4fc82071ce346e3885118242ff45d22f69b82)
breaks SPL for Zynq because it puts early alloc area on the stack which
caused that stack was decreased by CONFIG_SYS_MALLOC_F_LEN (0x400)
and there was not enough space for regular stack.
This patch changes memory layout to better utilize the last 64k OCM
block.
0xffff0000 - 0xfff1000 - Full malloc space
0xffff1000 - 0xffff300 - Stack location
0xfffff300 - CONFIG_SYS_MALLOC_F_LEN - Early malloc space
0xfffffd00 - sizeof(GD) - GD
0xfffffe00 - 0xffffffff - SoC specific boot code
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Tested-by: Moritz Fischer <moritz.fischer@ettus.com>
|
| /openbmc/u-boot/ |
| H A D | README | 9ac4fc82071ce346e3885118242ff45d22f69b82 Thu Nov 12 08:30:19 CST 2015 Fabio Estevam <fabio.estevam@freescale.com> board_init: Change the logic to setup malloc_base
Prior to commit 5ba534d247d418 ("arm: Switch 32-bit ARM to using generic
global_data setup") we used to have assembly code that configured the
malloc_base address.
Since this commit we use the board_init_f_mem() function in C to setup
malloc_base address.
In board_init_f_mem() there was a deliberate choice to support only
early malloc() or full malloc() in SPL, but not both.
Adapt this logic to allow both to be used, one after the other, in SPL.
This issue has been observed in a Congatec board, where we need to
retrieve the manufacturing information from the SPI NOR (the SPI API
calls malloc) prior to configuring the DRAM. In this case as malloc_base
was not configured we always see malloc to fail.
With this change we are able to use malloc in SPL prior to DRAM gets
initialized.
Also update the CONFIG_SYS_SPL_MALLOC_START entry in the README file.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|