| Message ID | 4E8B1508.7020706@ti.com |
|---|---|
| State | Superseded |
| Headers | show |
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
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
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
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 >
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!
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
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