[U-Boot] BSS footprint of FAT very high - SPL issues
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
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
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
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
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
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
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
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,
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
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
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,
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@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.
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
Wolfgang Denk skrev 2011-02-11 23:15:
Dear Ulf Samuelsson,
In message4D55A73C.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
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.
- Forbid anyone to store the environment in an SPI flash.
- Initialize the SPI before reading the environment
- 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
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@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
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,
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,
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
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
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
Dear Wolfgang,
On Tuesday 01 February 2011 01:25 PM, Wolfgang Denk wrote:
Dear Aneesh V,
In message4D4798E2.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
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 message4D4798E2.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
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
Hello Wolfgang, Albert,
On Tuesday 01 February 2011 03:33 PM, Wolfgang Denk wrote:
Dear Aneesh V,
In message4D47C1C9.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
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 message4D47C1C9.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,
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 message4D47C1C9.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
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 message4D47C1C9.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,
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
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,
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
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,
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,
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,
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,
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 message4D47C1C9.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
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
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
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
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
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
participants (9)
-
Albert ARIBAUD -
Aneesh V -
Bedia, Vaibhav -
Graeme Russ -
Mike Frysinger -
sughosh ganu -
Ulf Samuelsson -
Ulf Samuelsson -
Wolfgang Denk