| Message ID | 1317741066-31121-1-git-send-email-aneesh@ti.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | Tom Rini |
| Headers | show |
Dear Aneesh V, In message <1317741066-31121-1-git-send-email-aneesh@ti.com> you wrote: > From: a0393566local (none) <a0393566local@ula0393566> > > FAT library now uses malloc() and free(). But SPL doesn't > have heap until now. Setup a heap in SDRAM to fix this issue. > > However this increases SPL footprint beyond the available SRAM > budget. So, compile out some fancy features in the SDARM init > bring back footprint under control > > CC: Sandeep Paulraj <s-paulraj@ti.com> > CC: Wolfgang Denk <wd@denx.de> > Signed-off-by: Aneesh V <aneesh@ti.com> I think it is a bad idea to go this way. We should face the fact that SPL code is running before proper relocation to RAM, and thus there are certain limitations. Certain parts of the code, including file system code, has not been written with such limitations in mind. It makes use of functions that are not available in SPL code, or of features that are not available in SPL code (like a heap, or a virtually unlimited stack). You may be lucky here, and your test cases with the FFAT code may actually work. But I would not bet on it. U-Boot has not been designed to run complex code like file systemes before relocation, and SPL code _is_ before relocation. Best regards, Wolfgang Denk
Dear Wolfgang, On Tuesday 04 October 2011 09:08 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<1317741066-31121-1-git-send-email-aneesh@ti.com> you wrote: >> From: a0393566local (none)<a0393566local@ula0393566> >> >> FAT library now uses malloc() and free(). But SPL doesn't >> have heap until now. Setup a heap in SDRAM to fix this issue. >> >> However this increases SPL footprint beyond the available SRAM >> budget. So, compile out some fancy features in the SDARM init >> bring back footprint under control >> >> CC: Sandeep Paulraj<s-paulraj@ti.com> >> CC: Wolfgang Denk<wd@denx.de> >> Signed-off-by: Aneesh V<aneesh@ti.com> > > I think it is a bad idea to go this way. > > We should face the fact that SPL code is running before proper > relocation to RAM, and thus there are certain limitations. > > Certain parts of the code, including file system code, has not been > written with such limitations in mind. It makes use of functions that > are not available in SPL code, or of features that are not available > in SPL code (like a heap, or a virtually unlimited stack). > > You may be lucky here, and your test cases with the FFAT code may > actually work. But I would not bet on it. > I have mentioned why FAT is inevitable for us in a separate mail in this thread. > > U-Boot has not been designed to run complex code like file systemes > before relocation, and SPL code _is_ before relocation. Please note that SPL is not as restricted as it seems(at least the way it is now). For instance, OMAP SPL has 1. gd in SRAM 2. .bss in SDRAM and 3. heap in SDRAM(with this patch) So, we have everything that takes for any driver to function as long as the .text fits in the SRAM. I think the same principles apply to all platforms not just OMAP. These complex drivers are likely to be used only after SDRAM is initialized. After SDRAM is initialized you have plenty of space for .bss and heap. So the only limitation for an SPL should be .text and .data size. best regards, Aneesh
On 10/04/2011 10:38 AM, Wolfgang Denk wrote: > I think it is a bad idea to go this way. > > We should face the fact that SPL code is running before proper > relocation to RAM, and thus there are certain limitations. > > Certain parts of the code, including file system code, has not been > written with such limitations in mind. It makes use of functions that > are not available in SPL code, or of features that are not available > in SPL code (like a heap, or a virtually unlimited stack). > > You may be lucky here, and your test cases with the FFAT code may > actually work. But I would not bet on it. > > > U-Boot has not been designed to run complex code like file systemes > before relocation, and SPL code _is_ before relocation. SPL has its own relocation. If it were under the same restrictions as normal pre-relocation U-Boot, where would it load an image to? All SPL really is, is some makefile infrastructure to produce a second, special-purpose U-Boot image. The degree to which it is stripped down depends on the requirements of the particular target. -Scott
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c b/arch/arm/cpu/armv7/omap-common/spl.c index c76fea6..46a1413 100644 --- a/arch/arm/cpu/armv7/omap-common/spl.c +++ b/arch/arm/cpu/armv7/omap-common/spl.c @@ -35,6 +35,7 @@ #include <asm/arch/mmc_host_def.h> #include <i2c.h> #include <image.h> +#include <malloc.h> DECLARE_GLOBAL_DATA_PTR; @@ -106,6 +107,9 @@ void board_init_r(gd_t *id, ulong dummy) u32 boot_device; debug(">>spl:board_init_r()\n"); + mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START, + CONFIG_SYS_SPL_MALLOC_SIZE); + timer_init(); i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE); diff --git a/common/Makefile b/common/Makefile index 2edbd71..b424beb 100644 --- a/common/Makefile +++ b/common/Makefile @@ -29,7 +29,6 @@ LIB = $(obj)libcommon.o ifndef CONFIG_SPL_BUILD COBJS-y += main.o COBJS-y += command.o -COBJS-y += dlmalloc.o COBJS-y += exports.o COBJS-$(CONFIG_SYS_HUSH_PARSER) += hush.o COBJS-y += image.o @@ -176,6 +175,7 @@ COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o endif COBJS-y += console.o +COBJS-y += dlmalloc.o COBJS-y += memsize.o COBJS-y += stdio.o diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index 228eac5..f438fc2 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -238,6 +238,7 @@ #endif /* Defines for SDRAM init */ +#define CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS #ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS #define CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION #define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS @@ -251,6 +252,16 @@ #define CONFIG_SPL_BSS_START_ADDR 0x80000000 #define CONFIG_SPL_BSS_MAX_SIZE 0x80000 /* 512 KB */ +/* + * 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM + * 64 bytes before this address should be set aside for u-boot.img's + * header. That is 0x800FFFC0--0x80100000 should not be used for any + * other needs. + */ +#define CONFIG_SYS_TEXT_BASE 0x80100000 +#define CONFIG_SYS_SPL_MALLOC_START 0x80200000 +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x100000 /* 1 MB */ + #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x300 /* address 0x60000 */ #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x200 /* 256 KB */ @@ -266,12 +277,4 @@ #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_LDSCRIPT "arch/arm/cpu/armv7/omap-common/u-boot-spl.lds" -/* - * 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM - * 64 bytes before this address should be set aside for u-boot.img's - * header. That is 0x800FFFC0--0x80100000 should not be used for any - * other needs. - */ -#define CONFIG_SYS_TEXT_BASE 0x80100000 - #endif /* __CONFIG_OMAP4_COMMON_H */