From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Tue, 01 Feb 2011 08:04:45 +0100 Subject: [U-Boot] BSS footprint of FAT very high - SPL issues In-Reply-To: <4D4798E2.3050500@ti.com> References: <4D4798E2.3050500@ti.com> Message-ID: <4D47B08D.8040905@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le 01/02/2011 06:23, Aneesh V a ?crit : > Dear Wolfgang, > > I had been working on creating an MMC SPL for OMAP4. OMAP boards > typically support booting from the FAT partition of a removable SD/MMC > card. So, we need to have FAT support in the SPL. But I am having some > difficulties in adding FAT support to SPL. > > BSS footprint of fat.c is very high. It has three buffers each of size > 64KB. To workaround this problem I have done something like below(The > way x-loader works around this problem today). > CONFIG_SYS_SPL_FAT_BUFFER_BASE is in SDRAM.Is this ok? > > Also, I was wondering why we need 3 such scratch buffers in this > implementation. I do not understand this code. But I was wondering if we > could work with just one 64K buffer? > > --- > +#ifdef CONFIG_PRELOADER > +__u8 *get_vfatname_block = (__u8 *)CONFIG_SYS_SPL_FAT_BUFFER_BASE; > +#else > __attribute__ ((__aligned__ (__alignof__ (dir_entry)))) > __u8 get_vfatname_block[MAX_CLUSTSIZE]; > +#endif > > . > . > . > > +#ifdef CONFIG_PRELOADER > +__u8 *get_dentfromdir_block = (__u8 *)CONFIG_SYS_SPL_FAT_BUFFER_BASE + > + MAX_CLUSTSIZE; > +#else > __attribute__ ((__aligned__ (__alignof__ (dir_entry)))) > __u8 get_dentfromdir_block[MAX_CLUSTSIZE]; > +#endif > + I'd like to make sure I understand the issue. Do these three BSS variables occupy space in the U-Boot binary? If they do, then *that* must be fixed rather than allocating a fixed address for them. In ARM achitectures, the linker file makes sure the BSS is at the end of the image and is not loadable, so the ELF to bin conversion just skips them. Maybe the linker file you're using here does not do this? > Best regards, > Aneesh Amicalement, -- Albert.