* [U-Boot] Master branch broken for omap4_panda (SPL_BUILD) @ 2011-10-03 18:50 Aguirre, Sergio 2011-10-04 14:15 ` Aneesh V 2011-10-04 15:11 ` [U-Boot] [PATCH] omap: spl: fix build break due to changes in FAT Aneesh V 0 siblings, 2 replies; 12+ messages in thread From: Aguirre, Sergio @ 2011-10-03 18:50 UTC (permalink / raw) To: u-boot Hi all, I'm trying to build this commit: http://git.denx.de/?p=u-boot.git;a=commit;h=7b8ffea2ac44097ed1c99ba70b8c6a4cf12ba0b4 with: make omap4_panda_config make But it fails for spl build, while trying to link libfat.o with malloc()/free() functions. Git-bisect throws this commit to blame: http://git.denx.de/?p=u-boot.git;a=commit;h=ac4977719e157bcb3c45c70d9dd781164727530d Has anyone seen this? Regards, Sergio ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] Master branch broken for omap4_panda (SPL_BUILD) 2011-10-03 18:50 [U-Boot] Master branch broken for omap4_panda (SPL_BUILD) Aguirre, Sergio @ 2011-10-04 14:15 ` Aneesh V 2011-10-04 14:51 ` Wolfgang Denk 2011-10-04 15:11 ` [U-Boot] [PATCH] omap: spl: fix build break due to changes in FAT Aneesh V 1 sibling, 1 reply; 12+ messages in thread From: Aneesh V @ 2011-10-04 14:15 UTC (permalink / raw) To: u-boot Hi Sergio, On Tuesday 04 October 2011 12:20 AM, Aguirre, Sergio wrote: > Hi all, > > I'm trying to build this commit: > > http://git.denx.de/?p=u-boot.git;a=commit;h=7b8ffea2ac44097ed1c99ba70b8c6a4cf12ba0b4 > > with: > > make omap4_panda_config > make > > But it fails for spl build, while trying to link libfat.o with > malloc()/free() functions. > > Git-bisect throws this commit to blame: > > http://git.denx.de/?p=u-boot.git;a=commit;h=ac4977719e157bcb3c45c70d9dd781164727530d > > Has anyone seen this? Yes, I tried this just now and I am also facing this issue. I can fix the build issue using the following change. But that doesn't solve the problem. We do not have heap in SPL. So, this is a real serious problem for any SPL that has FAT support. I will try to setup a heap in SDRAM as soon as I get some time to work on this. --- 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 > > Regards, > Sergio > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [U-Boot] Master branch broken for omap4_panda (SPL_BUILD) 2011-10-04 14:15 ` Aneesh V @ 2011-10-04 14:51 ` Wolfgang Denk 2011-10-04 15:37 ` Aneesh V 2011-10-07 1:40 ` Tom Rini 0 siblings, 2 replies; 12+ messages in thread From: Wolfgang Denk @ 2011-10-04 14:51 UTC (permalink / raw) To: u-boot Dear Aneesh V, In message <4E8B1508.7020706@ti.com> you wrote: > > Yes, I tried this just now and I am also facing this issue. I can fix > the build issue using the following change. But that doesn't solve the > problem. We do not have heap in SPL. So, this is a real serious problem > for any SPL that has FAT support. I will try to setup a heap in SDRAM > as soon as I get some time to work on this. All file system code has been designed and implemented to run AFTER relocation. Access to a FAT file system is not supposed to happen from SPL code. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Landing: a controlled mid-air collision with a planet. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] Master branch broken for omap4_panda (SPL_BUILD) 2011-10-04 14:51 ` Wolfgang Denk @ 2011-10-04 15:37 ` Aneesh V 2011-10-04 18:05 ` Wolfgang Denk 2011-10-07 1:40 ` Tom Rini 1 sibling, 1 reply; 12+ messages in thread From: Aneesh V @ 2011-10-04 15:37 UTC (permalink / raw) To: u-boot Dear Wolfgang, On Tuesday 04 October 2011 08:21 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4E8B1508.7020706@ti.com> you wrote: >> >> Yes, I tried this just now and I am also facing this issue. I can fix >> the build issue using the following change. But that doesn't solve the >> problem. We do not have heap in SPL. So, this is a real serious problem >> for any SPL that has FAT support. I will try to setup a heap in SDRAM >> as soon as I get some time to work on this. > > All file system code has been designed and implemented to run AFTER > relocation. Access to a FAT file system is not supposed to happen > from SPL code. SPL does call relocate_code() but defeats it by passing the relocation target same as the SPL_TEXT_BASE. OMAP has traditionally supported booting from the FAT partition of an external SD card. The ROM code can pick up the SPL from the FAT partition and SPL should pick up u-boot from there too. Some of our boards like OMAP4 Panda have only an SD slot for non-volatile memory and no flash memory installed. Of course we could use the SD card in raw mode. But the FAT mode is much more convenient for many users. If FAT is not supported in SPL, it will be a major regression compared to x-loader and a show-stopper for us. I have submitted a patch to fix the problem reported in this thread and FAT boot is working fine again. However, I am worried about the increasing footprint of SPL. The main contributors are MMC and FAT. x-loader, with all it's short-comings, does the same job with a smaller footprint. NAND has a custom driver for SPL while MMC and FAT doesn't have. I don't think it's practical either. However, I wonder if these drivers could be scaled down in size for SPL with some '#ifdef CONFIG_SPL_BUILD's. I wish if somebody could look into this. best regards, Aneesh ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] Master branch broken for omap4_panda (SPL_BUILD) 2011-10-04 15:37 ` Aneesh V @ 2011-10-04 18:05 ` Wolfgang Denk 2011-10-05 9:42 ` Aneesh V 0 siblings, 1 reply; 12+ messages in thread From: Wolfgang Denk @ 2011-10-04 18:05 UTC (permalink / raw) To: u-boot Dear Aneesh V, In message <4E8B282A.8040301@ti.com> you wrote: > > > All file system code has been designed and implemented to run AFTER > > relocation. Access to a FAT file system is not supposed to happen > > from SPL code. ... > OMAP has traditionally supported booting from the FAT partition of an > external SD card. The ROM code can pick up the SPL from the FAT > partition and SPL should pick up u-boot from there too. Some of our > boards like OMAP4 Panda have only an SD slot for non-volatile memory > and no flash memory installed. Of course we could use the SD card in > raw mode. But the FAT mode is much more convenient for many users. If > FAT is not supported in SPL, it will be a major regression compared to > x-loader and a show-stopper for us. I understand this, and you may have noted that I did not NAK the patch. I just want to point out that what you are doing is pretty dangerous, and there are no seat-belts. > I have submitted a patch to fix the problem reported in this thread and > FAT boot is working fine again. For now. But please expect that the next breakage may happen any time, and there is no guarantee that it can be fixed as easily. > However, I am worried about the increasing footprint of SPL. The main > contributors are MMC and FAT. x-loader, with all it's short-comings, > does the same job with a smaller footprint. ... Why is this the case? I doubt they use other FAT code, or do they? What about MMC? > ... NAND has a custom driver > for SPL while MMC and FAT doesn't have. I don't think it's practical > either. However, I wonder if these drivers could be scaled down in size > for SPL with some '#ifdef CONFIG_SPL_BUILD's. I wish if somebody could > look into this. Do you have exact numbers of the sizes for the MMC, FAT and NAND code in x-loader compared to SPL U-Boot? And what are for example the restrictions of (V)FAT support in x-loader? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de You can fool some of the people all of the time, and You can fool all of the people some of the time, but You can't fool mom. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] Master branch broken for omap4_panda (SPL_BUILD) 2011-10-04 18:05 ` Wolfgang Denk @ 2011-10-05 9:42 ` Aneesh V 0 siblings, 0 replies; 12+ messages in thread From: Aneesh V @ 2011-10-05 9:42 UTC (permalink / raw) To: u-boot Dear Wolfgang, On Tuesday 04 October 2011 11:35 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4E8B282A.8040301@ti.com> you wrote: >> >>> All file system code has been designed and implemented to run AFTER >>> relocation. Access to a FAT file system is not supposed to happen >>> from SPL code. > ... >> OMAP has traditionally supported booting from the FAT partition of an >> external SD card. The ROM code can pick up the SPL from the FAT >> partition and SPL should pick up u-boot from there too. Some of our >> boards like OMAP4 Panda have only an SD slot for non-volatile memory >> and no flash memory installed. Of course we could use the SD card in >> raw mode. But the FAT mode is much more convenient for many users. If >> FAT is not supported in SPL, it will be a major regression compared to >> x-loader and a show-stopper for us. > > I understand this, and you may have noted that I did not NAK the > patch. I just want to point out that what you are doing is pretty > dangerous, and there are no seat-belts. > Thank you. I realize that maintaining our SPL will not be easy, particularly given the fact that most boards do not have SPL, much less FAT support in it. So, we are bound to see issues inadvertently introduced by others. But we have no other choice. >> I have submitted a patch to fix the problem reported in this thread and >> FAT boot is working fine again. > > For now. But please expect that the next breakage may happen any > time, and there is no guarantee that it can be fixed as easily. > >> However, I am worried about the increasing footprint of SPL. The main >> contributors are MMC and FAT. x-loader, with all it's short-comings, >> does the same job with a smaller footprint. ... > > Why is this the case? I doubt they use other FAT code, or do they? > What about MMC? > X-loader, as far as I know, is based on a very old fork of u-boot. MMC driver is a custom monolithic driver for OMAP4(not the generic MMC framework in the current mainline). We didn't take a closer look at the code differences yet. >> ... NAND has a custom driver >> for SPL while MMC and FAT doesn't have. I don't think it's practical >> either. However, I wonder if these drivers could be scaled down in size >> for SPL with some '#ifdef CONFIG_SPL_BUILD's. I wish if somebody could >> look into this. > > Do you have exact numbers of the sizes for the MMC, FAT and NAND code > in x-loader compared to SPL U-Boot? And what are for example the > restrictions of (V)FAT support in x-loader? Yes, we did a crude measurement by comparing the image size before and after commenting out the calls to the respective libraries(Pls note that we have -gc-sections enabled in both the cases). Here are the results. x-loader SPL MMC 3724 6900 FAT 2464 9340 Together the two makes a difference of 10052 Bytes, and far outweighs the gains made in sdram init and clock init. best regards, Aneesh > > Best regards, > > Wolfgang Denk > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] Master branch broken for omap4_panda (SPL_BUILD) 2011-10-04 14:51 ` Wolfgang Denk 2011-10-04 15:37 ` Aneesh V @ 2011-10-07 1:40 ` Tom Rini 2011-10-07 5:27 ` Wolfgang Denk 1 sibling, 1 reply; 12+ messages in thread From: Tom Rini @ 2011-10-07 1:40 UTC (permalink / raw) To: u-boot On Tue, Oct 4, 2011 at 7:51 AM, Wolfgang Denk <wd@denx.de> wrote: > Dear Aneesh V, > > In message <4E8B1508.7020706@ti.com> you wrote: >> >> Yes, I tried this just now and I am also facing this issue. I can fix >> the build issue using the following change. But that doesn't solve the >> problem. We do not have heap in SPL. So, this is a real serious problem >> for any SPL that has FAT support. I will try to setup a heap in SDRAM >> as soon as I get some time to work on this. > > All file system code has been designed and implemented to run AFTER > relocation. ?Access to a FAT file system is not supposed to happen > from SPL code. Since this wasn't a NAK just a warning about possible future problems, are you expecting this to come in via Sandeep's tree? Thanks! -- Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] Master branch broken for omap4_panda (SPL_BUILD) 2011-10-07 1:40 ` Tom Rini @ 2011-10-07 5:27 ` Wolfgang Denk 0 siblings, 0 replies; 12+ messages in thread From: Wolfgang Denk @ 2011-10-07 5:27 UTC (permalink / raw) To: u-boot Dear Tom Rini, In message <CA+M6bX=GQEJ0nccRYkgc-qz1u3cMYXEmmhKL0QvZkZiy2VWXag@mail.gmail.com> you wrote: > > > All file system code has been designed and implemented to run AFTER > > relocation. =A0Access to a FAT file system is not supposed to happen > > from SPL code. > > Since this wasn't a NAK just a warning about possible future problems, > are you expecting this to come in via Sandeep's tree? Thanks! Yes: I'm not happy about it, but I will not block it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de A committee is a life form with six or more legs and no brain. -- Lazarus Long, "Time Enough For Love" ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH] omap: spl: fix build break due to changes in FAT 2011-10-03 18:50 [U-Boot] Master branch broken for omap4_panda (SPL_BUILD) Aguirre, Sergio 2011-10-04 14:15 ` Aneesh V @ 2011-10-04 15:11 ` Aneesh V 2011-10-04 15:38 ` Wolfgang Denk 1 sibling, 1 reply; 12+ messages in thread From: Aneesh V @ 2011-10-04 15:11 UTC (permalink / raw) To: u-boot 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> --- --- arch/arm/cpu/armv7/omap-common/spl.c | 4 ++++ common/Makefile | 2 +- include/configs/omap4_common.h | 19 +++++++++++-------- 3 files changed, 16 insertions(+), 9 deletions(-) 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 */ -- 1.7.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH] omap: spl: fix build break due to changes in FAT 2011-10-04 15:11 ` [U-Boot] [PATCH] omap: spl: fix build break due to changes in FAT Aneesh V @ 2011-10-04 15:38 ` Wolfgang Denk 2011-10-04 16:00 ` Aneesh V 2011-10-04 16:17 ` Scott Wood 0 siblings, 2 replies; 12+ messages in thread From: Wolfgang Denk @ 2011-10-04 15:38 UTC (permalink / raw) To: u-boot 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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Lead me not into temptation... I can find it myself. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH] omap: spl: fix build break due to changes in FAT 2011-10-04 15:38 ` Wolfgang Denk @ 2011-10-04 16:00 ` Aneesh V 2011-10-04 16:17 ` Scott Wood 1 sibling, 0 replies; 12+ messages in thread From: Aneesh V @ 2011-10-04 16:00 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [U-Boot] [PATCH] omap: spl: fix build break due to changes in FAT 2011-10-04 15:38 ` Wolfgang Denk 2011-10-04 16:00 ` Aneesh V @ 2011-10-04 16:17 ` Scott Wood 1 sibling, 0 replies; 12+ messages in thread From: Scott Wood @ 2011-10-04 16:17 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-10-07 5:27 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-10-03 18:50 [U-Boot] Master branch broken for omap4_panda (SPL_BUILD) Aguirre, Sergio 2011-10-04 14:15 ` Aneesh V 2011-10-04 14:51 ` Wolfgang Denk 2011-10-04 15:37 ` Aneesh V 2011-10-04 18:05 ` Wolfgang Denk 2011-10-05 9:42 ` Aneesh V 2011-10-07 1:40 ` Tom Rini 2011-10-07 5:27 ` Wolfgang Denk 2011-10-04 15:11 ` [U-Boot] [PATCH] omap: spl: fix build break due to changes in FAT Aneesh V 2011-10-04 15:38 ` Wolfgang Denk 2011-10-04 16:00 ` Aneesh V 2011-10-04 16:17 ` Scott Wood
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.