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
Bedia
Hi Aneesh,
Quoted 7 lines · 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.
Quoted 5 lines
BSS footprint of
fat.cis 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_BASEis 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
Le 01/02/2011 06:23, Aneesh V a ?crit :
Quoted 28 lines
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.cis 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_BASEis 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?
---
(quoted diff) +4
-0+#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.
.
.
Review
Quoted 8 lines
(quoted diff) +6
-0+#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?
Quoted 2 lines
Best regards,
Aneesh
Amicalement,
Signature · 1 line
Albert.
Le 01/02/2011 08:04, Albert ARIBAUD a ?crit :
Quoted 6 lines
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,
Signature · 1 line
Albert.
Dear Aneesh V,
Quoted 10 lines · In message <[email protected]> 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.cis 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_BASEis in SDRAM.Is this ok?
Why would that be necessary? Just put the BSS segment in SDRAM, and everything is fine, isn't it?
Quoted 3 lines
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
Signature · 4 lines
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.
Dear "Bedia, Vaibhav",
Quoted 2 lines · In message <[email protected]> you…
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
Signature · 5 lines
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."
Dear Albert ARIBAUD,
Quoted 11 lines · In message <[email protected]> you wrote:
Quoted 6 lines
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
Signature · 5 lines
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
Dear Wolfgang,
Quoted 9 lines · Wolfgang Denk
Dear Aneesh V,
Quoted 6 lines · In message<[email protected]> 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.
Quoted 7 lines
Quoted 4 lines
BSS footprint of
fat.cis 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_BASEis 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.
Quoted 6 lines
Quoted 4 lines
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
Hi Vaibhav,
Quoted 10 lines · Vaibhav
Hi Aneesh,
Quoted 7 lines · 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.
Quoted 8 lines
Quoted 5 lines
BSS footprint of
fat.cis 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_BASEis 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.
Quoted 2 lines
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
Hi Albert,
Quoted 9 lines · Albert ARIBAUD
Le 01/02/2011 08:04, Albert ARIBAUD a ?crit :
Quoted 6 lines
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?
Quoted 4 lines
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
Bedia
Quoted 2 lines · Aneesh
Hi Vaibhav,
[...]
Quoted 6 lines
Quoted 4 lines
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 :)
Quoted 6 lines
Quoted 4 lines
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
Bedia
Quoted 17 lines · Aneesh V
Dear Wolfgang,
Quoted 14 lines · Wolfgang Denk
Dear Aneesh V,
Quoted 10 lines · In message<[email protected]> 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.cis 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_BASEis in SDRAM.Is this ok?
Quoted 8 lines
Quoted 2 lines
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,
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines
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.
Quoted 2 lines
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
Signature · 4 lines
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
Dear "Bedia, Vaibhav",
Quoted 4 lines · In message <[email protected]> you…
Quoted 2 lines
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
Signature · 5 lines
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.
Bedia
Quoted 6 lines · Wolfgang Denk
Dear "Bedia, Vaibhav",
In message <[email protected]> you
Quoted 1 line · wrote:
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
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 :
Quoted 11 lines · Wolfgang Denk
Quoted 10 lines
Dear "Bedia, Vaibhav",
In message <[email protected]> you
Quoted 4 lines · wrote:
Quoted 2 lines
Luckily we don't need networking related code in SPL.
It might be required later on :)
Quoted 8 lines
Quoted 4 lines
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.
Quoted 2 lines
Regards,
Vaibhav
Amicalement,
Signature · 1 line
Albert.
Le 01/02/2011 09:26, Aneesh V a ?crit :
Quoted 1 line
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,
Signature · 1 line
Albert.
Bedia
On Tuesday, February 01, 2011 4:19 PM, Albert ARIBAUD wrote:
[...]
Quoted 4 lines
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",
Quoted 2 lines · In message <[email protected]> you…
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
Signature · 5 lines
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.
Hello Wolfgang, Albert,
Quoted 10 lines · Wolfgang Denk
Dear Aneesh V,
Quoted 6 lines · In message<[email protected]> you wrote:
Quoted 3 lines
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
Quoted 8 lines
Yes, this is normal.
Quoted 2 lines
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 :
Quoted 18 lines
Hello Wolfgang, Albert,
Quoted 15 lines · Wolfgang Denk
Dear Aneesh V,
Quoted 6 lines · In message<[email protected]> you wrote:
Quoted 3 lines
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.
Quoted 2 lines
rest of the bss in internal RAM so that it's available as soon as we enter C code.
Quoted 6 lines
Quoted 3 lines
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?
Quoted 7 lines
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. :)
Quoted 2 lines
Best regards,
Aneesh
Amicalement,
Signature · 1 line
Albert.
Hi Albert,
Quoted 25 lines · Albert ARIBAUD
Hi Aneesh,
Le 02/02/2011 14:17, Aneesh V a ?crit :
Quoted 22 lines
Hello Wolfgang, Albert,
Quoted 18 lines · Wolfgang Denk
Dear Aneesh V,
Quoted 6 lines · In message<[email protected]> you wrote:
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 9 lines
Quoted 8 lines
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.
Quoted 7 lines
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 :
Quoted 58 lines
Hi Albert,
Quoted 25 lines · Albert ARIBAUD
Hi Aneesh,
Le 02/02/2011 14:17, Aneesh V a ?crit :
Quoted 22 lines
Hello Wolfgang, Albert,
Quoted 18 lines · Wolfgang Denk
Dear Aneesh V,
Quoted 6 lines · In message<[email protected]> you wrote:
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 9 lines
Quoted 8 lines
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.Quoted 7 lines
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. :)
Quoted 5 lines
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.
Quoted 2 lines
Best regards,
Aneesh
Amicalement,
Signature · 1 line
Albert.
Quoted 31 lines · Aneesh V
Hi Albert,
Quoted 28 lines · Albert ARIBAUD
Hi Aneesh,
Le 02/02/2011 14:17, Aneesh V a ?crit :
Quoted 24 lines
Hello Wolfgang, Albert,
Quoted 10 lines · Wolfgang Denk
Dear Aneesh V,
Quoted 6 lines · In message<[email protected]> you wrote:
Quoted 3 lines
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
Quoted 8 lines
Yes, this is normal.
Quoted 2 lines
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.
Quoted 9 lines
Quoted 2 lines
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
hi Aneesh,
Quoted 6 lines · Aneesh V
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 Graeme,
On Thursday 03 February 2011 02:31 AM, Graeme Russ wrote:
[snip ..]
Quoted 11 lines
Quoted 6 lines
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.
Quoted 9 lines
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
Hello Sughosh,
Quoted 12 lines · sughosh ganu
hi Aneesh,
On Wed, Feb 2, 2011 at 7:31 PM, Aneesh V <[email protected] <mailto:[email protected]>> 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.
Quoted 4 lines
I had added serial console support in my
nand_splcode for the hawkboard port(referring existing FSL boards). I think the serial console can be initialised usingNS16550_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
Quoted 25 lines · Aneesh V
Hello Graeme,
On Thursday 03 February 2011 02:31 AM, Graeme Russ wrote:
[snip ..]Quoted 11 lines
Quoted 6 lines
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.
Quoted 9 lines
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.
Quoted 5 lines
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 :)
Quoted 6 lines
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
Hello Albert,
On Wednesday 02 February 2011 08:44 PM, Albert ARIBAUD wrote:
[snip ..]
Quoted 23 lines
Quoted 16 lines
Quoted 8 lines
Quoted 7 lines
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.Quoted 7 lines
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. :)
Quoted 6 lines
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.
Quoted 6 lines
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 :
Quoted 7 lines
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.Sby 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.
Quoted 2 lines
Best regards,
Aneesh
Amicalement,
Signature · 1 line
Albert.
Hello Wolfgang, Albert,
Quoted 8 lines · Albert ARIBAUD
Hi Aneesh,
Le 03/02/2011 11:38, Aneesh V a ?crit :
Quoted 4 lines
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.
Quoted 6 lines
Quoted 3 lines
If needed, I can fix up the
start.Sby 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.ldsin 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 :
Quoted 18 lines
Hello Wolfgang, Albert,
Quoted 8 lines · Albert ARIBAUD
Hi Aneesh,
Le 03/02/2011 11:38, Aneesh V a ?crit :
Quoted 4 lines
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.
Quoted 6 lines
Quoted 3 lines
If needed, I can fix up the
start.Sby 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.ldsin the ARM arch consistently.
Quoted 6 lines
I see
__u_boot_cmd_endas 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_startin 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.
Quoted 2 lines
Best regards,
Aneesh
Amicalement,
Signature · 1 line
Albert.
Hi Albert,
Quoted 28 lines · Albert ARIBAUD
Hi Aneesh,
Le 11/02/2011 07:28, Aneesh V a ?crit :
Quoted 18 lines
Hello Wolfgang, Albert,
Quoted 8 lines · Albert ARIBAUD
Hi Aneesh,
Le 03/02/2011 11:38, Aneesh V a ?crit :
Quoted 4 lines
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.
Quoted 6 lines
Quoted 3 lines
If needed, I can fix up the
start.Sby 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.ldsin the ARM arch consistently.Quoted 6 lines
I see
__u_boot_cmd_endas 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_startin future. I don't think that should be a big concern. Do you agree?
Quoted 6 lines
As you point out, using
__u_boot_cmdwould 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?
Quoted 5 lines
Quoted 3 lines
Best regards,
AneeshAmicalement,
Le 11/02/2011 07:57, Aneesh V a ?crit :
Quoted 7 lines
Quoted 6 lines
As you point out, using
__u_boot_cmdwould 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.
Quoted 6 lines
I thought it rather unlikely that the position of
__u_boot_cmdwill 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/omap4One patch will do, right?
Yes.
Quoted 2 lines
Also, any thoughts on the name for the new label.
_end_of_relocated_imageis 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".
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Best regards,
Aneesh
Amicalement,
Signature · 1 line
Albert.
On Friday 11 February 2011 01:45 PM, Albert ARIBAUD wrote:
[snip..]
Quoted 6 lines
Quoted 2 lines
Also, any thoughts on the name for the new label.
_end_of_relocated_imageis all I can think of?Current practice has "
_end" appended to whatever the labels delimit -- same as for "_start".
Quoted 6 lines
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
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Best regards,
AneeshAmicalement,
2011-02-01 09:26, Aneesh V skrev:
Quoted 23 lines
Hi Vaibhav,
Quoted 10 lines · Vaibhav
Hi Aneesh,
Quoted 7 lines · 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.
Quoted 8 lines
Quoted 5 lines
BSS footprint of
fat.cis 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_BASEis 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.
Quoted 8 lines
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.
Signature · 2 lines
Best Regards Ulf Samuelsson
Dear Ulf Samuelsson,
Quoted 5 lines · In message <[email protected]> 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
Signature · 5 lines
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
Hi Ulf,
Quoted 26 lines · Ulf Samuelsson
2011-02-01 09:26, Aneesh V skrev:
Quoted 25 lines
Hi Vaibhav,
Quoted 10 lines · Vaibhav
Hi Aneesh,
Quoted 7 lines · 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.
Quoted 8 lines
Quoted 5 lines
BSS footprint of
fat.cis 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_BASEis 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.
Quoted 8 lines
Quoted 6 lines
best regards,
Aneesh
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-bootThe 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
Quoted 8 lines · On Tuesday, February 01, 2011 00:23:46 Aneesh V wrote:
BSS footprint of
fat.cis 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_BASEis 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
Wolfgang Denk skrev 2011-02-11 23:15:
Quoted 9 lines
Dear Ulf Samuelsson,
Quoted 4 lines · In message<[email protected]> 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_splinstead. 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.
Quoted 4 lines
Thanks.
Wolfgang Denk
Dear Ulf Samuelsson,
Quoted 3 lines · In message <[email protected]> you wrote:
Quoted 3 lines
In mainline U-Boot we tend to use
nand_splinstead. There should be no need for such externel, out-of-tree code.
In the mean time, code has been reorganized, generalized and improved.
Quoted 1 line
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.
Quoted 1 line
Does
nand_splsupport 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.
Quoted 1 line
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.
Quoted 1 line
Does is support loading WinCE instead of U-Boot?
Yes, this can be supported.
Quoted 1 line
Does it support loading other stuff?
Yes, it does. Tested for example with loading and starting a Linux kernel.
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 1 line
I see just a few choices.
I can see a number more options.
Quoted 3 lines
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.
Quoted 4 lines
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
Signature · 5 lines
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