[U-Boot] BSS footprint of FAT very high - SPL issues

[U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

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
+

Best regards,
Aneesh

[U-Boot] BSS footprint of FAT very high - SPL issues

[Bedia, Vaibhav]

Hi Aneesh,

On Tuesday, February 01, 2011 10:54 AM, Aneesh V wrote:
> 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?
> 
[...]

I guess you will hit a similar issue with the networking related code is used (I am not sure if SPL uses it). That also requires a decent size of bss.

Is having a config option to specify the location of bss (like CONFIG_SYS_BSS_ADDR) better/acceptable?

Regards,
Vaibhav

[U-Boot] BSS footprint of FAT very high - SPL issues

[Wolfgang Denk]

Dear "Bedia, Vaibhav",

In message <FCCFB4CDC6E5564B9182F639FC356087035FB3155C@dbde02.ent.ti.com> you wrote:
> 
> Is having a config option to specify the location of bss (like CONFIG_SYS_BSS_ADDR) better/acceptable?

No such option is necessary because it is up to the SPL linker script
where it places the BSS.

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
Quote from the Boss... "I didn't say it was your fault.  I said I was
going to blame it on you."

[U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hi Vaibhav,

On Tuesday 01 February 2011 12:22 PM, Bedia, Vaibhav wrote:
> Hi Aneesh,
>
> On Tuesday, February 01, 2011 10:54 AM, Aneesh V wrote:
>> 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?
>>
> [...]
>
> I guess you will hit a similar issue with the networking related code is used (I am not sure if SPL uses it). That also requires a decent size of bss.

Luckily we don't need networking related code in SPL.

>
> Is having a config option to specify the location of bss (like CONFIG_SYS_BSS_ADDR) better/acceptable?

I would prefer to have rest of the BSS in internal RAM itself.

best regards,
Aneesh

[U-Boot] BSS footprint of FAT very high - SPL issues

[Bedia, Vaibhav]

On Tuesday, February 01, 2011 1:57 PM, V, Aneesh wrote:
> Hi Vaibhav,
> 
[...]
>> 
>> I guess you will hit a similar issue with the networking related
>> code is used (I am not sure if SPL uses it). That also requires a
>> decent size of bss.  
> 
> Luckily we don't need networking related code in SPL.

It might be required later on :)

> 
>> 
>> Is having a config option to specify the location of bss (like
>> CONFIG_SYS_BSS_ADDR) better/acceptable? 
> 
> I would prefer to have rest of the BSS in internal RAM itself.

Instead of adding workarounds for each driver I think putting BSS in SDRAM as pointed out by Wolfgang is better.

Regards,
Vaibhav

[U-Boot] BSS footprint of FAT very high - SPL issues

[Wolfgang Denk]

Dear "Bedia, Vaibhav",

In message <FCCFB4CDC6E5564B9182F639FC356087035FB315F8@dbde02.ent.ti.com> you wrote:
>
> > Luckily we don't need networking related code in SPL.
> 
> It might be required later on :)

It makes no sense. Load and start U-Boot if you need more fancy
features. If you need even more complex ones (say, TCP/IP and Java
support) then boot and OS.


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 witty saying proves nothing, but saying  something  pointless  gets
people's attention.

[U-Boot] BSS footprint of FAT very high - SPL issues

[Bedia, Vaibhav]

On Tuesday, February 01, 2011 3:35 PM, Wolfgang Denk wrote:
> Dear "Bedia, Vaibhav",
> 
> In message
> <FCCFB4CDC6E5564B9182F639FC356087035FB315F8@dbde02.ent.ti.com> you
> wrote:  
>> 
>>> Luckily we don't need networking related code in SPL.
>> 
>> It might be required later on :)
> 
> It makes no sense. Load and start U-Boot if you need more fancy
> features. If you need even more complex ones (say, TCP/IP and Java
> support) then boot and OS. 
> 

I was thinking of a scenario where we have SPL being loaded over ethernet and the SPL stage then trying to load the 2nd stage using TFTP.

Regards,
Vaibhav

[U-Boot] BSS footprint of FAT very high - SPL issues

[Albert ARIBAUD]

Le 01/02/2011 11:18, Bedia, Vaibhav a ?crit :
> On Tuesday, February 01, 2011 3:35 PM, Wolfgang Denk wrote:
>> Dear "Bedia, Vaibhav",
>>
>> In message
>> <FCCFB4CDC6E5564B9182F639FC356087035FB315F8@dbde02.ent.ti.com>  you
>> wrote:
>>>
>>>> Luckily we don't need networking related code in SPL.
>>>
>>> It might be required later on :)
>>
>> It makes no sense. Load and start U-Boot if you need more fancy
>> features. If you need even more complex ones (say, TCP/IP and Java
>> support) then boot and OS.
>>
>
> I was thinking of a scenario where we have SPL being loaded over
> ethernet and the SPL stage then trying to load the 2nd stage using
> TFTP.

That would be way outside of how U-Boot is supposed to work: the 
assumption is that the SPL and U-Boot itself are present on-board anyway 
-- the rationale being that the board should be able to get to the 
U-Boot prompt with only the console attached.

> Regards,
> Vaibhav

Amicalement,
-- 
Albert.

[U-Boot] BSS footprint of FAT very high - SPL issues

[Bedia, Vaibhav]

On Tuesday, February 01, 2011 4:19 PM, Albert ARIBAUD wrote:
[...]
> That would be way outside of how U-Boot is supposed to work: the
> assumption is that the SPL and U-Boot itself are present on-board
> anyway -- the rationale being that the board should be able to get
> to the U-Boot prompt with only the console attached.  

Ok. Thanks for the clarification.

In that case how can network boot be supported in U-Boot? Is the expectation that the SPL image which gets downloaded to internal RAM inits SDRAM, relocates to it and then download any other image like a larger U-Boot or the OS image?

Regards,
Vaibhav

[U-Boot] BSS footprint of FAT very high - SPL issues

[Wolfgang Denk]

Dear "Bedia, Vaibhav",

In message <FCCFB4CDC6E5564B9182F639FC356087035FBED5FB@dbde02.ent.ti.com> you wrote:
>
> In that case how can network boot be supported in U-Boot? Is the expectation that the SPL image which gets downloaded to internal RAM inits SDRAM, relocates to it and then download any other image like a larger U-Boot or the OS image?

Can you please restrict your line length to some 70 or so characters?

At the moment, U-Boot it self assumes that it somehow got started as a
whole - either executing from reset (like when booting from NOR flash
or similar bootable memory regions), or by being loaded by some
secondary loader.  So far, we support NAND and OneNAND in such a mode.
Especially with NAND the restrictions may be severe - quite often the
SPL code has to fit in as little as 4 KiB, sometimes even in 2 KiB.

If you want SPL support for network booting, this needs to be added.
I am not sure if this really makes sense, though. Many devices today
have ROM code capable of reading boot images from USB or SDCard etc.,
so these are the "naturally supported" boot modes for such systems.
I haven't seen network boot in such a configuration yet.

If you add it, I guess the next steps will be support for WLAN booting
and IPv6.

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
Why can you only have two doors on a chicken coop? If it had four  it
would be a chicken sedan.

[U-Boot] BSS footprint of FAT very high - SPL issues

[Albert ARIBAUD]

Le 01/02/2011 09:26, Aneesh V a ?crit :

> I would prefer to have rest of the BSS in internal RAM itself.

In this case, you should define a dedicated output section in your 
linker file (say, ".ram"), which would locate in DRAM and collect input 
sections named similarly (".ram" as well would work) and then use 
attributes in the buffer declarations to put them in .ram sections.

That way, you'd clearly have .text, .data, .bss mapped to IRAM, and .ram 
  mapped to DRAM in a manner that readers of your code can understand.

Amicalement,
-- 
Albert.

[U-Boot] BSS footprint of FAT very high - SPL issues

[Ulf Samuelsson]

2011-02-01 09:26, Aneesh V skrev:
> Hi Vaibhav,
>
> On Tuesday 01 February 2011 12:22 PM, Bedia, Vaibhav wrote:
>> Hi Aneesh,
>>
>> On Tuesday, February 01, 2011 10:54 AM, Aneesh V wrote:
>>> 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?
>>>
>> [...]
>>
>> I guess you will hit a similar issue with the networking related code is used (I am not sure if SPL uses it). That also requires a decent size of bss.
> Luckily we don't need networking related code in SPL.
>
> I would prefer to have rest of the BSS in internal RAM itself.
>
> best regards,
> Aneesh
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
The way this problem is fixed on the AT91 is to run at91bootstrap first.
This program will initialize the SDRAM and copy u-boot to SDRAM.
at91bootstrap fits into 4 kB of code, and a small amount of RAM,
so it will run on real small CPUs.

You could try to do the same, instead of spending a lot of time,
trying to optimize.

-- 
Best Regards
Ulf Samuelsson

[U-Boot] BSS footprint of FAT very high - SPL issues

[Wolfgang Denk]

Dear Ulf Samuelsson,

In message <4D55A73C.6090404@atmel.com> you wrote:
>
> The way this problem is fixed on the AT91 is to run at91bootstrap first.
> This program will initialize the SDRAM and copy u-boot to SDRAM.
> at91bootstrap fits into 4 kB of code, and a small amount of RAM,
> so it will run on real small CPUs.

In mainline U-Boot we tend to use nand_spl instead.  There should be
no need for such externel, out-of-tree code.

Thanks.

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
"The value of marriage is not that adults produce children, but  that
children produce adults."                            - Peter De Vries

[U-Boot] BSS footprint of FAT very high - SPL issues

[Ulf Samuelsson]

Wolfgang Denk skrev 2011-02-11 23:15:
> Dear Ulf Samuelsson,
>
> In message<4D55A73C.6090404@atmel.com>  you wrote:
>> The way this problem is fixed on the AT91 is to run at91bootstrap first.
>> This program will initialize the SDRAM and copy u-boot to SDRAM.
>> at91bootstrap fits into 4 kB of code, and a small amount of RAM,
>> so it will run on real small CPUs.
> In mainline U-Boot we tend to use nand_spl instead.  There should be
> no need for such externel, out-of-tree code.

I am not aware of a single at91 user which uses nand_spl.  Are you?

Does nand_spl support at91?
Does it support loading from SPI Flash, Dataflash, EEPROM and SD-Card?
Does is support loading WinCE instead of U-Boot?
Does it support loading other stuff?

Is there anyone outside the u-boot core members that care what is used 
to load u-boot?

Anyway, your comment deviates from the real issue.
The environment is stored on an SPI device, and U-boot reads the environment
before it initializes the SPI. This is a bug, that needs fixing.

I see just a few choices.
1. Forbid anyone to store the environment in an SPI flash.
2. Initialize the SPI before reading the environment
3. Make the environment available without initializing the SPI first.
     This assumes that at91bootstrap , nand_spl or whatever makes
     a temporary environment available (as suggested).
     Any writes to the environment has to happen after the SPI has been 
initialized.

I think (1) can be ruled out, so we have (2) or (3) left, and someone 
needs to decide what to do.

I assume the same problem is with the I2C, SD-Card interface, which may 
need to be initialized
before the environment is read, if the environment happens to use such 
an interface.

> Thanks.
>
> Wolfgang Denk
>

[U-Boot] BSS footprint of FAT very high - SPL issues

[Wolfgang Denk]

Dear Ulf Samuelsson,

In message <4E6FCDB3.1080202@telia.com> you wrote:
>
> > In mainline U-Boot we tend to use nand_spl instead.  There should be
> > no need for such externel, out-of-tree code.

In the mean time, code has been reorganized, generalized and improved.

> I am not aware of a single at91 user which uses nand_spl.  Are you?

Well, AT91 support is pretty poor in general, compared to other SoC
families.  This is not exactly a problem of U-Boot.

> Does nand_spl support at91?

The design of the SPL code is not specific to any processor or
architecture.  Adding AT91 support is not more and not less difficult
than for any other SoC.

> Does it support loading from SPI Flash, Dataflash, EEPROM and SD-Card?

EEPROM?  I haven't seen a device booting U-Boot (or Linux) from an
EEPROM yet - but if you like, you can add such suppport, too.

Yes for the others, plus NAND and NOR.

> Does is support loading WinCE instead of U-Boot?

Yes, this can be supported.

> Does it support loading other stuff?

Yes, it does.  Tested for example with loading and starting a Linux
kernel.

> Is there anyone outside the u-boot core members that care what is used 
> to load u-boot?

Yes.  Customers and other end users for example, who don;t like having
to maintain unnecessary software packages and keeping tools and
scripts in place to build them; people who are interested in minimal
boot times, etc.

> Anyway, your comment deviates from the real issue.
> The environment is stored on an SPI device, and U-boot reads the environment
> before it initializes the SPI. This is a bug, that needs fixing.

The bug is in your configuration.  If you load U-Boot from a SPI
flash, you can simply load the environment with it, in a single
operation.

> I see just a few choices.

I can see a number more options.

> 1. Forbid anyone to store the environment in an SPI flash.
> 2. Initialize the SPI before reading the environment
> 3. Make the environment available without initializing the SPI first.

None of these are needed.

> I assume the same problem is with the I2C, SD-Card interface, which may 
> need to be initialized
> before the environment is read, if the environment happens to use such 
> an interface.

It's just a configuration.  It is not a problem.  At least not for us.

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
What we anticipate seldom occurs;  what  we  least  expect  generally
happens.                                          - Bengamin Disraeli

[U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hi Ulf,

On Saturday 12 February 2011 02:46 AM, Ulf Samuelsson wrote:
> 2011-02-01 09:26, Aneesh V skrev:
>> Hi Vaibhav,
>>
>> On Tuesday 01 February 2011 12:22 PM, Bedia, Vaibhav wrote:
>>> Hi Aneesh,
>>>
>>> On Tuesday, February 01, 2011 10:54 AM, Aneesh V wrote:
>>>> 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?
>>>>
>>> [...]
>>>
>>> I guess you will hit a similar issue with the networking related code is used (I am not sure if SPL uses it). That also requires a decent size of bss.
>> Luckily we don't need networking related code in SPL.
>>
>> I would prefer to have rest of the BSS in internal RAM itself.
>>
>> best regards,
>> Aneesh
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
> The way this problem is fixed on the AT91 is to run at91bootstrap first.
> This program will initialize the SDRAM and copy u-boot to SDRAM.

Thank you for the suggestion.

But please note that the SPL I am trying to create does exactly the
same. But the problem is that we allow users to keep the bootloaders
and kernel in the FAT partition of an MMC card(typically used for
development not on production systems). So, I have to support MMC and
FAT in SPL to load u-boot.

thanks,
Aneesh

[U-Boot] BSS footprint of FAT very high - SPL issues

[Albert ARIBAUD]

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.

[U-Boot] BSS footprint of FAT very high - SPL issues

[Albert ARIBAUD]

Le 01/02/2011 08:04, Albert ARIBAUD a ?crit :

> 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?

Answering myself: after reading Vaibhav's answer, I should amend my 
question aboce. Seems like the issue is the SPL has a BSS in IRAM, or in 
whatever memory it lands in. In that case, there's indeed no fix except 
putting the buffers in DRAM.

Amicalement,
-- 
Albert.

[U-Boot] BSS footprint of FAT very high - SPL issues

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4D47B20B.5040104@free.fr> you wrote:
> 
> > 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?
>
> Answering myself: after reading Vaibhav's answer, I should amend my
> question aboce. Seems like the issue is the SPL has a BSS in IRAM, or in
> whatever memory it lands in. In that case, there's indeed no fix except
> putting the buffers in DRAM.

well, there _is_ an obvious fix: put the BSS inS DRAM where we have
sufficient room for 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
The idea of male and female are universal constants.
	-- Kirk, "Metamorphosis", stardate 3219.8

[U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hi Albert,

On Tuesday 01 February 2011 12:41 PM, Albert ARIBAUD wrote:
> Le 01/02/2011 08:04, Albert ARIBAUD a ?crit :
>
>> 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?
>
> Answering myself: after reading Vaibhav's answer, I should amend my
> question aboce. Seems like the issue is the SPL has a BSS in IRAM, or in
> whatever memory it lands in. In that case, there's indeed no fix except
> putting the buffers in DRAM.

Yes, that's right. SPL has code, data and bss in internal RAM.

Best regards,
Aneesh

[U-Boot] BSS footprint of FAT very high - SPL issues

[Wolfgang Denk]

Dear Aneesh V,

In message <4D4798E2.3050500@ti.com> you wrote:
> 
> 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?

Why would that be necessary?  Just put the BSS segment in SDRAM, and
everything is fine, isn't it?

> 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?

I have no idea.   I am not familiar with that code either.

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 day without sunshine is like night.

[U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Dear Wolfgang,

On Tuesday 01 February 2011 01:25 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4D4798E2.3050500@ti.com>  you wrote:
>>
>> 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?
>
> Why would that be necessary?  Just put the BSS segment in SDRAM, and
> everything is fine, isn't it?

SDRAM is initialized by the SPL. So, bss can not be initialized and
used until SDRAM initialization is complete. I would prefer to have
rest of the bss in internal RAM so that it's available as soon as we
enter C code.

>
>> 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?
>
> I have no idea.   I am not familiar with that code either.

Probably I will give it a try once I solve some other issues I am
facing in getting FAT to work.

Best regards,
Aneesh

[U-Boot] BSS footprint of FAT very high - SPL issues

[Bedia, Vaibhav]

On Tuesday, February 01, 2011 1:48 PM, Aneesh V wrote:
> Dear Wolfgang,
> 
> On Tuesday 01 February 2011 01:25 PM, Wolfgang Denk wrote:
>> Dear Aneesh V,
>> 
>> In message<4D4798E2.3050500@ti.com>  you wrote:
>>> 
>>> 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?
>> 
>> Why would that be necessary?  Just put the BSS segment in SDRAM,
>> and everything is fine, isn't it?
> 
> SDRAM is initialized by the SPL. So, bss can not be initialized and
> used until SDRAM initialization is complete. I would prefer to have
> rest of the bss in internal RAM so that it's available as soon as
> we enter C code.   
> 

This approach looks very messy to me. I would rather revisit the init sequence to see if things can be fixed there.

Regards,
Vaibhav

[U-Boot] BSS footprint of FAT very high - SPL issues

[Wolfgang Denk]

Dear Aneesh V,

In message <4D47C1C9.1020002@ti.com> you wrote:
> 
> > Why would that be necessary?  Just put the BSS segment in SDRAM, and
> > everything is fine, isn't it?
> 
> SDRAM is initialized by the SPL. So, bss can not be initialized and
> used until SDRAM initialization is complete. I would prefer to have

Yes, this is normal.

> rest of the bss in internal RAM so that it's available as soon as we
> enter C code.

Well, you probably have to decide if you want an easy solution with
the restictions of the internal RAM size, or a somewhat more complex
solution with much more powerful resources.


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
"It's like deja vu all over again."                      - Yogi Berra

[U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hello Wolfgang, Albert,

On Tuesday 01 February 2011 03:33 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4D47C1C9.1020002@ti.com>  you wrote:
>>
>>> Why would that be necessary?  Just put the BSS segment in SDRAM, and
>>> everything is fine, isn't it?
>>
>> SDRAM is initialized by the SPL. So, bss can not be initialized and
>> used until SDRAM initialization is complete. I would prefer to have
>
> Yes, this is normal.
>
>> rest of the bss in internal RAM so that it's available as soon as we
>> enter C code.
>
> Well, you probably have to decide if you want an easy solution with
> the restictions of the internal RAM size, or a somewhat more complex
> solution with much more powerful resources.

I tried putting bss in SDRAM and it works for me. I just had to put a
couple of variables explicitly in .data section. However, there is one
minor issue that I would like to report.

Making .bss disjoint from the rest of the image may break the
relocation code in start.S. Currently the assumption is that
'__bss_start' indicates the end of .data and hence the image.
That will not be the case when .text and .data are in IRAM and .bss in
SDRAM. I am not affected because our SPL doesn't need relocation.

Best regards,
Aneesh

[U-Boot] BSS footprint of FAT very high - SPL issues

[Albert ARIBAUD]

Hi Aneesh,

Le 02/02/2011 14:17, Aneesh V a ?crit :
> Hello Wolfgang, Albert,
>
> On Tuesday 01 February 2011 03:33 PM, Wolfgang Denk wrote:
>> Dear Aneesh V,
>>
>> In message<4D47C1C9.1020002@ti.com> you wrote:
>>>
>>>> Why would that be necessary? Just put the BSS segment in SDRAM, and
>>>> everything is fine, isn't it?
>>>
>>> SDRAM is initialized by the SPL. So, bss can not be initialized and
>>> used until SDRAM initialization is complete. I would prefer to have
>>
>> Yes, this is normal.
>>
>>> rest of the bss in internal RAM so that it's available as soon as we
>>> enter C code.
>>
>> Well, you probably have to decide if you want an easy solution with
>> the restictions of the internal RAM size, or a somewhat more complex
>> solution with much more powerful resources.
>
> I tried putting bss in SDRAM and it works for me. I just had to put a
> couple of variables explicitly in .data section.

You mean data that would have ended in BSS but that you moved to .data? Why?

> However, there is one minor issue that I would like to report.
>
> Making .bss disjoint from the rest of the image may break the
> relocation code in start.S. Currently the assumption is that
> '__bss_start' indicates the end of .data and hence the image.
> That will not be the case when .text and .data are in IRAM and .bss in
> SDRAM. I am not affected because our SPL doesn't need relocation.

That's a good remark -- formally, the relocation code should go from 
start of text to end of data, not to start of BSS.

And that's one more reason for me to want bss stay with text and data 
(and your two variables above should stay uninitialized) and external 
RAM get its own memory declaration in the linker file. :)

> Best regards,
> Aneesh

Amicalement,
-- 
Albert.

[U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hi Albert,

On Wednesday 02 February 2011 07:07 PM, Albert ARIBAUD wrote:
> Hi Aneesh,
>
> Le 02/02/2011 14:17, Aneesh V a ?crit :
>> Hello Wolfgang, Albert,
>>
>> On Tuesday 01 February 2011 03:33 PM, Wolfgang Denk wrote:
>>> Dear Aneesh V,
>>>
>>> In message<4D47C1C9.1020002@ti.com> you wrote:
>>>>
>>>>> Why would that be necessary? Just put the BSS segment in SDRAM, and
>>>>> everything is fine, isn't it?
>>>>
>>>> SDRAM is initialized by the SPL. So, bss can not be initialized and
>>>> used until SDRAM initialization is complete. I would prefer to have
>>>
>>> Yes, this is normal.
>>>
>>>> rest of the bss in internal RAM so that it's available as soon as we
>>>> enter C code.
>>>
>>> Well, you probably have to decide if you want an easy solution with
>>> the restictions of the internal RAM size, or a somewhat more complex
>>> solution with much more powerful resources.
>>
>> I tried putting bss in SDRAM and it works for me. I just had to put a
>> couple of variables explicitly in .data section.
>
> You mean data that would have ended in BSS but that you moved to .data?
> Why?

Yes. These are variables that otherwise would go to BSS. I do this
because I need them before SDRAM initialization. One of this is the gd
structure. I allocate gd structure in .data that is in IRAM.
Why I need gd before SDRAM? Because I try to initialize serial console
as early as possible and this code has some reference to gd.


>
>> However, there is one minor issue that I would like to report.
>>
>> Making .bss disjoint from the rest of the image may break the
>> relocation code in start.S. Currently the assumption is that
>> '__bss_start' indicates the end of .data and hence the image.
>> That will not be the case when .text and .data are in IRAM and .bss in
>> SDRAM. I am not affected because our SPL doesn't need relocation.
>
> That's a good remark -- formally, the relocation code should go from
> start of text to end of data, not to start of BSS.
>
> And that's one more reason for me to want bss stay with text and data
> (and your two variables above should stay uninitialized) and external
> RAM get its own memory declaration in the linker file. :)
>

I can try that too. Just one small question.
You want to have the source file changes for putting the buffers in
.ram section only for SPL, right?
We could have done this globally(for both u-boot and SPL) and merge .ram 
with .bss for u-boot. But that would require changes to all linker scripts.

Best regards,
Aneesh

[U-Boot] BSS footprint of FAT very high - SPL issues

[Albert ARIBAUD]

Le 02/02/2011 15:01, Aneesh V a ?crit :
> Hi Albert,
>
> On Wednesday 02 February 2011 07:07 PM, Albert ARIBAUD wrote:
>> Hi Aneesh,
>>
>> Le 02/02/2011 14:17, Aneesh V a ?crit :
>>> Hello Wolfgang, Albert,
>>>
>>> On Tuesday 01 February 2011 03:33 PM, Wolfgang Denk wrote:
>>>> Dear Aneesh V,
>>>>
>>>> In message<4D47C1C9.1020002@ti.com> you wrote:
>>>>>
>>>>>> Why would that be necessary? Just put the BSS segment in SDRAM, and
>>>>>> everything is fine, isn't it?
>>>>>
>>>>> SDRAM is initialized by the SPL. So, bss can not be initialized and
>>>>> used until SDRAM initialization is complete. I would prefer to have
>>>>
>>>> Yes, this is normal.
>>>>
>>>>> rest of the bss in internal RAM so that it's available as soon as we
>>>>> enter C code.
>>>>
>>>> Well, you probably have to decide if you want an easy solution with
>>>> the restictions of the internal RAM size, or a somewhat more complex
>>>> solution with much more powerful resources.
>>>
>>> I tried putting bss in SDRAM and it works for me. I just had to put a
>>> couple of variables explicitly in .data section.
>>
>> You mean data that would have ended in BSS but that you moved to .data?
>> Why?
>
> Yes. These are variables that otherwise would go to BSS. I do this
> because I need them before SDRAM initialization. One of this is the gd
> structure. I allocate gd structure in .data that is in IRAM.
> Why I need gd before SDRAM? Because I try to initialize serial console
> as early as possible and this code has some reference to gd.
>
>
>>
>>> However, there is one minor issue that I would like to report.
>>>
>>> Making .bss disjoint from the rest of the image may break the
>>> relocation code in start.S. Currently the assumption is that
>>> '__bss_start' indicates the end of .data and hence the image.
>>> That will not be the case when .text and .data are in IRAM and .bss in
>>> SDRAM. I am not affected because our SPL doesn't need relocation.
>>
>> That's a good remark -- formally, the relocation code should go from
>> start of text to end of data, not to start of BSS.
>>
>> And that's one more reason for me to want bss stay with text and data
>> (and your two variables above should stay uninitialized) and external
>> RAM get its own memory declaration in the linker file. :)
>>
>
> I can try that too. Just one small question.
> You want to have the source file changes for putting the buffers in
> .ram section only for SPL, right?
> We could have done this globally(for both u-boot and SPL) and merge .ram
> with .bss for u-boot. But that would require changes to all linker scripts.

Correct: the BSS size issue only hits SPL, and only in your case -- 
U-Boot as such does not have strict BSS size issues. So yes, the change 
should affect only the board's SPL linker file if it exists, but if not, 
then the generic SPL linker file should be ok, because the change will 
only have an effect for boards where the code actually maps data to the 
DRAM section.

> Best regards,
> Aneesh

Amicalement,
-- 
Albert.

[U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hello Albert,

On Wednesday 02 February 2011 08:44 PM, Albert ARIBAUD wrote:
[snip ..]

>>>> However, there is one minor issue that I would like to report.
>>>>
>>>> Making .bss disjoint from the rest of the image may break the
>>>> relocation code in start.S. Currently the assumption is that
>>>> '__bss_start' indicates the end of .data and hence the image.
>>>> That will not be the case when .text and .data are in IRAM and .bss in
>>>> SDRAM. I am not affected because our SPL doesn't need relocation.
>>>
>>> That's a good remark -- formally, the relocation code should go from
>>> start of text to end of data, not to start of BSS.
>>>
>>> And that's one more reason for me to want bss stay with text and data
>>> (and your two variables above should stay uninitialized) and external
>>> RAM get its own memory declaration in the linker file. :)
>>>
>>
>> I can try that too. Just one small question.
>> You want to have the source file changes for putting the buffers in
>> .ram section only for SPL, right?
>> We could have done this globally(for both u-boot and SPL) and merge .ram
>> with .bss for u-boot. But that would require changes to all linker
>> scripts.
>
> Correct: the BSS size issue only hits SPL, and only in your case --
> U-Boot as such does not have strict BSS size issues. So yes, the change
> should affect only the board's SPL linker file if it exists, but if not,
> then the generic SPL linker file should be ok, because the change will
> only have an effect for boards where the code actually maps data to the
> DRAM section.

On second thoughts I would like to keep the entire bss in SDRAM. With
MMC and FAT support, the SPL is already nearing the IRAM budget in
OMAP3. It helps to save some space by moving out bss to SDRAM.

If needed, I can fix up the start.S by defining something like
_end_of_data. But is that really needed. I do not see any SPL that
needs relocation and SDRAM bss at the same time.

Best regards,
Aneesh

[U-Boot] BSS footprint of FAT very high - SPL issues

[Albert ARIBAUD]

Hi Aneesh,

Le 03/02/2011 11:38, Aneesh V a ?crit :

> On second thoughts I would like to keep the entire bss in SDRAM. With
> MMC and FAT support, the SPL is already nearing the IRAM budget in
> OMAP3. It helps to save some space by moving out bss to SDRAM.
>
> If needed, I can fix up the start.S by defining something like
> _end_of_data. But is that really needed. I do not see any SPL that
> needs relocation and SDRAM bss at the same time.

"Patches Welcome" :) -- with added thanks for patching all start.S / 
u-boot.lds in the ARM arch consistently.

> Best regards,
> Aneesh

Amicalement,
-- 
Albert.

[U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hello Wolfgang, Albert,

On Saturday 05 February 2011 12:28 PM, Albert ARIBAUD wrote:
> Hi Aneesh,
>
> Le 03/02/2011 11:38, Aneesh V a ?crit :
>
>> On second thoughts I would like to keep the entire bss in SDRAM. With
>> MMC and FAT support, the SPL is already nearing the IRAM budget in
>> OMAP3. It helps to save some space by moving out bss to SDRAM.
>>
>> If needed, I can fix up the start.S by defining something like
>> _end_of_data. But is that really needed. I do not see any SPL that
>> needs relocation and SDRAM bss at the same time.
>
> "Patches Welcome" :) -- with added thanks for patching all start.S /
> u-boot.lds in the ARM arch consistently.

I see __u_boot_cmd_end as the end of the image to be relocated in all
the scripts. Shall I use this label for this purpose. This will work
for now and save me from touching all those linker scripts. However,
there is a small possibility of this leading to the same problem as
with __bss_start in future. I don't think that should be a big concern.
Do you agree?

Best regards,
Aneesh

[U-Boot] BSS footprint of FAT very high - SPL issues

[Albert ARIBAUD]

Hi Aneesh,

Le 11/02/2011 07:28, Aneesh V a ?crit :
> Hello Wolfgang, Albert,
>
> On Saturday 05 February 2011 12:28 PM, Albert ARIBAUD wrote:
>> Hi Aneesh,
>>
>> Le 03/02/2011 11:38, Aneesh V a ?crit :
>>
>>> On second thoughts I would like to keep the entire bss in SDRAM. With
>>> MMC and FAT support, the SPL is already nearing the IRAM budget in
>>> OMAP3. It helps to save some space by moving out bss to SDRAM.
>>>
>>> If needed, I can fix up the start.S by defining something like
>>> _end_of_data. But is that really needed. I do not see any SPL that
>>> needs relocation and SDRAM bss at the same time.
>>
>> "Patches Welcome" :) -- with added thanks for patching all start.S /
>> u-boot.lds in the ARM arch consistently.
>
> I see __u_boot_cmd_end as the end of the image to be relocated in all
> the scripts. Shall I use this label for this purpose. This will work
> for now and save me from touching all those linker scripts. However,
> there is a small possibility of this leading to the same problem as
> with __bss_start in future. I don't think that should be a big concern.
> Do you agree?

As you point out, using __u_boot_cmd would cause as much of a concern as 
the current use of __bss_start, so I see no improvement there.

Please define a label in the linker file. If you haven't got time to 
port the change to other linkers, don't ; the BSS issue is, for now, 
specific to your case.

> Best regards,
> Aneesh

Amicalement,
-- 
Albert.

[U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hi Albert,

On Friday 11 February 2011 12:09 PM, Albert ARIBAUD wrote:
> Hi Aneesh,
>
> Le 11/02/2011 07:28, Aneesh V a ?crit :
>> Hello Wolfgang, Albert,
>>
>> On Saturday 05 February 2011 12:28 PM, Albert ARIBAUD wrote:
>>> Hi Aneesh,
>>>
>>> Le 03/02/2011 11:38, Aneesh V a ?crit :
>>>
>>>> On second thoughts I would like to keep the entire bss in SDRAM. With
>>>> MMC and FAT support, the SPL is already nearing the IRAM budget in
>>>> OMAP3. It helps to save some space by moving out bss to SDRAM.
>>>>
>>>> If needed, I can fix up the start.S by defining something like
>>>> _end_of_data. But is that really needed. I do not see any SPL that
>>>> needs relocation and SDRAM bss at the same time.
>>>
>>> "Patches Welcome" :) -- with added thanks for patching all start.S /
>>> u-boot.lds in the ARM arch consistently.
>>
>> I see __u_boot_cmd_end as the end of the image to be relocated in all
>> the scripts. Shall I use this label for this purpose. This will work
>> for now and save me from touching all those linker scripts. However,
>> there is a small possibility of this leading to the same problem as
>> with __bss_start in future. I don't think that should be a big concern.
>> Do you agree?
>
> As you point out, using __u_boot_cmd would cause as much of a concern as
> the current use of __bss_start, so I see no improvement there.
>
> Please define a label in the linker file. If you haven't got time to
> port the change to other linkers, don't ; the BSS issue is, for now,
> specific to your case.

I thought it rather unlikely that the position of __u_boot_cmd will
change in future. But I agree with you. Better do it cleanly once and
for all. Changing the linker scripts for all cpus should not be a big
deal. But I will not be able to test any of them except armv7/omap4

One patch will do, right?

Also, any thoughts on the name for the new label.
_end_of_relocated_image is all I can think of?

>
>> Best regards,
>> Aneesh
>
> Amicalement,

[U-Boot] BSS footprint of FAT very high - SPL issues

[Albert ARIBAUD]

Le 11/02/2011 07:57, Aneesh V a ?crit :

>> As you point out, using __u_boot_cmd would cause as much of a concern as
>> the current use of __bss_start, so I see no improvement there.
>>
>> Please define a label in the linker file. If you haven't got time to
>> port the change to other linkers, don't ; the BSS issue is, for now,
>> specific to your case.
>
> I thought it rather unlikely that the position of __u_boot_cmd will
> change in future. But I agree with you. Better do it cleanly once and
> for all. Changing the linker scripts for all cpus should not be a big
> deal. But I will not be able to test any of them except armv7/omap4
>
> One patch will do, right?

Yes.

> Also, any thoughts on the name for the new label.
> _end_of_relocated_image is all I can think of?

Current practice has "_end" appended to whatever the labels delimit -- 
same as for "_start".

Besides, the "relocated" part would be inexact; what matters here is the 
loading, or copying, of the image, not its relocation (and actually BSS 
is kind-of-relocated, as references to BSS from text or data may be the 
target of a relocation record).

So I would suggest "__image_load_end" or "__image_copy_end".

>>> Best regards,
>>> Aneesh

Amicalement,
-- 
Albert.

[U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

On Friday 11 February 2011 01:45 PM, Albert ARIBAUD wrote:
[snip..]
>> Also, any thoughts on the name for the new label.
>> _end_of_relocated_image is all I can think of?
>
> Current practice has "_end" appended to whatever the labels delimit --
> same as for "_start".
>
> Besides, the "relocated" part would be inexact; what matters here is the
> loading, or copying, of the image, not its relocation (and actually BSS
> is kind-of-relocated, as references to BSS from text or data may be the
> target of a relocation record).
>
> So I would suggest "__image_load_end" or "__image_copy_end".

Thanks. I will go with __image_copy_end

>
>>>> Best regards,
>>>> Aneesh
>
> Amicalement,

[U-Boot] BSS footprint of FAT very high - SPL issues

[Graeme Russ]

On Thu, Feb 3, 2011 at 1:01 AM, Aneesh V <aneesh@ti.com> wrote:
> Hi Albert,
>
> On Wednesday 02 February 2011 07:07 PM, Albert ARIBAUD wrote:
>> Hi Aneesh,
>>
>> Le 02/02/2011 14:17, Aneesh V a ?crit :
>>> Hello Wolfgang, Albert,
>>>
>>> On Tuesday 01 February 2011 03:33 PM, Wolfgang Denk wrote:
>>>> Dear Aneesh V,
>>>>
>>>> In message<4D47C1C9.1020002@ti.com> you wrote:
>>>>>
>>>>>> Why would that be necessary? Just put the BSS segment in SDRAM, and
>>>>>> everything is fine, isn't it?
>>>>>
>>>>> SDRAM is initialized by the SPL. So, bss can not be initialized and
>>>>> used until SDRAM initialization is complete. I would prefer to have
>>>>
>>>> Yes, this is normal.
>>>>
>>>>> rest of the bss in internal RAM so that it's available as soon as we
>>>>> enter C code.
>>>>
>>>> Well, you probably have to decide if you want an easy solution with
>>>> the restictions of the internal RAM size, or a somewhat more complex
>>>> solution with much more powerful resources.
>>>
>>> I tried putting bss in SDRAM and it works for me. I just had to put a
>>> couple of variables explicitly in .data section.
>>
>> You mean data that would have ended in BSS but that you moved to .data?
>> Why?
>
> Yes. These are variables that otherwise would go to BSS. I do this
> because I need them before SDRAM initialization. One of this is the gd
> structure. I allocate gd structure in .data that is in IRAM.
> Why I need gd before SDRAM? Because I try to initialize serial console
> as early as possible and this code has some reference to gd.
>

Which is a perfectly normal scenario and the way things have always been.
There should have been no need to shuffle gd around because of console
initialisation.

And as I understand it, gd itself does not get statically 'allocated' in
the u-boot image per-se (i.e. not in .data and not in .bss) - Only the
pointer to it is allocated. In most arches, this pointer is itself not
in .data or .bss but rather in a fixed reserved register. In the new x86
(final patches coming soon), the pointer is allocated in .data with a
preset initialised value pointing into  Cache-As-RAM (i.e. IRAM). Prior to
relocation, the gd pointer variable points to somewhere in IRAM / CAR and
after relocation, gd gets copied into the heap and the gd pointer adjusted
to point to the new permanent copy.

Regards,

Graeme

[U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hello Graeme,

On Thursday 03 February 2011 02:31 AM, Graeme Russ wrote:
[snip ..]
>> Yes. These are variables that otherwise would go to BSS. I do this
>> because I need them before SDRAM initialization. One of this is the gd
>> structure. I allocate gd structure in .data that is in IRAM.
>> Why I need gd before SDRAM? Because I try to initialize serial console
>> as early as possible and this code has some reference to gd.
>>
>
> Which is a perfectly normal scenario and the way things have always been.
> There should have been no need to shuffle gd around because of console
> initialisation.
>
> And as I understand it, gd itself does not get statically 'allocated' in
> the u-boot image per-se (i.e. not in .data and not in .bss) - Only the
> pointer to it is allocated. In most arches, this pointer is itself not
> in .data or .bss but rather in a fixed reserved register. In the new x86
> (final patches coming soon), the pointer is allocated in .data with a
> preset initialised value pointing into  Cache-As-RAM (i.e. IRAM). Prior to
> relocation, the gd pointer variable points to somewhere in IRAM / CAR and
> after relocation, gd gets copied into the heap and the gd pointer adjusted
> to point to the new permanent copy.

Please note that SPL starts executing from IRAM and not
FLASH (copied there by ROM code). So we have .data available
immediately. Actually we do not need gd except to reuse some code from
u-boot that uses it. Declaring gd as a static variable was just a
convenience decision.

If I were to allocate it separately I would have to allocate it in the
same IRAM and I may end up reserving more space than needed to allow
for future expansion. IRAM space is at a premium. So, declaring it as a
static variable helps in allocating only as much space as is needed.

Best regards,
Aneesh

[U-Boot] BSS footprint of FAT very high - SPL issues

[Graeme Russ]

On 03/02/11 18:01, Aneesh V wrote:
> Hello Graeme,
> 
> On Thursday 03 February 2011 02:31 AM, Graeme Russ wrote:
> [snip ..]
>>> Yes. These are variables that otherwise would go to BSS. I do this
>>> because I need them before SDRAM initialization. One of this is the gd
>>> structure. I allocate gd structure in .data that is in IRAM.
>>> Why I need gd before SDRAM? Because I try to initialize serial console
>>> as early as possible and this code has some reference to gd.
>>>
>>
>> Which is a perfectly normal scenario and the way things have always been.
>> There should have been no need to shuffle gd around because of console
>> initialisation.
>>
>> And as I understand it, gd itself does not get statically 'allocated' in
>> the u-boot image per-se (i.e. not in .data and not in .bss) - Only the
>> pointer to it is allocated. In most arches, this pointer is itself not
>> in .data or .bss but rather in a fixed reserved register. In the new x86
>> (final patches coming soon), the pointer is allocated in .data with a
>> preset initialised value pointing into  Cache-As-RAM (i.e. IRAM). Prior to
>> relocation, the gd pointer variable points to somewhere in IRAM / CAR and
>> after relocation, gd gets copied into the heap and the gd pointer adjusted
>> to point to the new permanent copy.
> 
> Please note that SPL starts executing from IRAM and not
> FLASH (copied there by ROM code). So we have .data available
> immediately. Actually we do not need gd except to reuse some code from
> u-boot that uses it. Declaring gd as a static variable was just a
> convenience decision.

Ah, silly me - I missed the fact this was SPL. Makes more sense now :)

> 
> If I were to allocate it separately I would have to allocate it in the
> same IRAM and I may end up reserving more space than needed to allow
> for future expansion. IRAM space is at a premium. So, declaring it as a
> static variable helps in allocating only as much space as is needed.
> 

Makes sense

Regards,

Graeme

[U-Boot] BSS footprint of FAT very high - SPL issues

[sughosh ganu]

hi Aneesh,

On Wed, Feb 2, 2011 at 7:31 PM, Aneesh V <aneesh@ti.com> wrote:

> Yes. These are variables that otherwise would go to BSS. I do this
> because I need them before SDRAM initialization. One of this is the gd
> structure. I allocate gd structure in .data that is in IRAM.
> Why I need gd before SDRAM? Because I try to initialize serial console
> as early as possible and this code has some reference to gd.
>

I had added serial console support in my nand_spl code for the hawkboard
port(referring existing FSL boards). I think the serial console can be
initialised using NS16550_init, which does not access any gd variable. This
is assuming that you can use the ns16550 serial driver :)

-sughosh

[U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hello Sughosh,

On Thursday 03 February 2011 12:19 PM, sughosh ganu wrote:
> hi Aneesh,
>
> On Wed, Feb 2, 2011 at 7:31 PM, Aneesh V <aneesh@ti.com
> <mailto:aneesh@ti.com>> wrote:
>
>     Yes. These are variables that otherwise would go to BSS. I do this
>     because I need them before SDRAM initialization. One of this is the gd
>     structure. I allocate gd structure in .data that is in IRAM.
>     Why I need gd before SDRAM? Because I try to initialize serial console
>     as early as possible and this code has some reference to gd.
>
>
> I had added serial console support in my nand_spl code for the hawkboard
> port(referring existing FSL boards). I think the serial console can be
> initialised using NS16550_init, which does not access any gd variable.
> This is assuming that you can use the ns16550 serial driver :)

Thanks for the input. Yes, we are using ns16550 driver.

However, I would still need gd because it is getting used
in other places like the mmc driver that I have to use in the SPL.

Best regards,
Aneesh

[U-Boot] BSS footprint of FAT very high - SPL issues

[Mike Frysinger]

On Tuesday, February 01, 2011 00:23:46 Aneesh V wrote:
> 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?

i'd be pretty surprised if these couldnt be cleaned up in some way.  sucking 
up 64KiB * 3 just for vfat is pretty f-in crazy.  no other FS code needs this.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110215/47b48daf/attachment.pgp