[U-Boot-Users] FADS and ICU862 Environment problems
The current FADS code does not seem to restore the environment properly, and i can't figure out what it SHOULD do.
Right now, relocate_code only relocates up to the end of text (_init_end), and since CFG_MONITOR_BASE + CONFIG_MONITOR_LEN is after CFG_ENV_ADDR, ENV_IS_EMBEDDED is set.
Since ENV_IS_EMBEDDED is set, env_reloca_spec in flash.c does NOT memcpy(env_addr,CFG_ENV_ADDR,CFG_ENV_SIZE).
There are several refereces to environment[] in start.S that are ifdefed out if CONFIG_FADS or CONFIG_ICU862, which don't look right.
My fix is to remove those ifdefs, and make sure that ENV_IS_EMBEDDED is NOT set by reducing CFG_MONITOR_LEN to not include the environment.
What is the correct behavior?
TIA
In message 20030620014530.GA21955@zumanetworks.com you wrote:
The current FADS code does not seem to restore the environment properly, and i can't figure out what it SHOULD do.
It _should_ work, of course :-)
Right now, relocate_code only relocates up to the end of text (_init_end), and since CFG_MONITOR_BASE + CONFIG_MONITOR_LEN is after CFG_ENV_ADDR, ENV_IS_EMBEDDED is set.
This is probably a result of our attempt to get rid of CONFIG_MONITOR_LEN as far as possible. Now it is ONLY used to determine if the environment is embedded, or not.
Since ENV_IS_EMBEDDED is set, env_reloca_spec in flash.c does NOT memcpy(env_addr,CFG_ENV_ADDR,CFG_ENV_SIZE).
Correcnt.
There are several refereces to environment[] in start.S that are ifdefed out if CONFIG_FADS or CONFIG_ICU862, which don't look right.
Why not? I cannot speak for the FADS, of course. Won't touch no F*** ADS...
My fix is to remove those ifdefs, and make sure that ENV_IS_EMBEDDED is NOT set by reducing CFG_MONITOR_LEN to not include the environment.
What is the correct behavior?
Setting CFG_MONITOR_LEN correctly is correct. But why removing which #ifdefs ?
Best regards,
Wolfgang Denk
On Sat, Jun 21, 2003 at 02:21:36AM +0200, Wolfgang Denk wrote:
Setting CFG_MONITOR_LEN correctly is correct. But why removing which #ifdefs ?
if ENV_IS_EMBEDDED is set, nothing in environment.c gets compiled, and cpu/mpc8xx/start.S has a few
#if defined(CONFIG_FADS) || defined(CONFIG_ICU862)
directives which surround GOT_ENTRY(environment) and GOT(environment) references...
safe to remove these?
btw. wolfgang, this patch is growing larger and larger every week, I'm not sure how easy it is going to be for me to split it up into digestible chunks for you...
In message 20030621002854.GA27308@zumanetworks.com you wrote:
On Sat, Jun 21, 2003 at 02:21:36AM +0200, Wolfgang Denk wrote:
Setting CFG_MONITOR_LEN correctly is correct. But why removing which #ifdefs ?
if ENV_IS_EMBEDDED is set, nothing in environment.c gets compiled, and cpu/mpc8xx/start.S has a few
#if defined(CONFIG_FADS) || defined(CONFIG_ICU862)
directives which surround GOT_ENTRY(environment) and GOT(environment) references...
safe to remove these?
No.
If you look at the u-boot.map file when building for the ICU862 board you can see this:
... 0x40f22b3c __init_end = . 0x40f22b3c __bss_start = .
.bss 0x40f22c00 0x417c ... 0x40f26c30 flash_info 0x40f40000 . = ALIGN (0x40000)
.ppcenv 0x40f40000 0x4000 common/environment.o(.ppcenv) .ppcenv 0x40f40000 0x4000 common/environment.o 0x40f40000 environment 0x40f44000 _end = . 0x40f44000 PROVIDE (end, .)
The #ifdef in "cpu/mpc8xx/start.S" makes sure that clear_bss() does not attempt to clear any memory that belongs to the environment.
btw. wolfgang, this patch is growing larger and larger every week, I'm not sure how easy it is going to be for me to split it up into digestible chunks for you...
Split it now, and submit any stable parts of it.
Best regards,
Wolfgang Denk
On Sun, Jun 22, 2003 at 06:22:03PM +0200, Wolfgang Denk wrote:
In message 20030621002854.GA27308@zumanetworks.com you wrote:
On Sat, Jun 21, 2003 at 02:21:36AM +0200, Wolfgang Denk wrote:
Setting CFG_MONITOR_LEN correctly is correct. But why removing which #ifdefs ?
if ENV_IS_EMBEDDED is set, nothing in environment.c gets compiled, and cpu/mpc8xx/start.S has a few
#if defined(CONFIG_FADS) || defined(CONFIG_ICU862)
directives which surround GOT_ENTRY(environment) and GOT(environment) references...
safe to remove these?
No.
If you look at the u-boot.map file when building for the ICU862 board you can see this:
... 0x40f22b3c __init_end = . 0x40f22b3c __bss_start = .
.bss 0x40f22c00 0x417c ... 0x40f26c30 flash_info 0x40f40000 . = ALIGN (0x40000)
.ppcenv 0x40f40000 0x4000 common/environment.o(.ppcenv) .ppcenv 0x40f40000 0x4000 common/environment.o 0x40f40000 environment 0x40f44000 _end = . 0x40f44000 PROVIDE (end, .)
shouldn't the ifdef depend on ENV_IS_EMBEDDED? If that is set, even in the ICU862 case, nothing in environment.c gets compiled (ALL of the code is ifdef'ed out), and "environment" will be unresolved..
The #ifdef in "cpu/mpc8xx/start.S" makes sure that clear_bss() does not attempt to clear any memory that belongs to the environment.
but only if ENV_IS_EMBEDDED is NOT set... unless i'm missing something obvious?
btw. wolfgang, this patch is growing larger and larger every week, I'm not sure how easy it is going to be for me to split it up into digestible chunks for you...
Split it now, and submit any stable parts of it.
Too much is tangled together, i will try, but it doesn't look good.
TIA
In message 20030623212553.GA10209@zumanetworks.com you wrote:
shouldn't the ifdef depend on ENV_IS_EMBEDDED? If that is set, even in the ICU862 case, nothing in environment.c gets compiled (ALL of the code is ifdef'ed out), and "environment" will be unresolved..
ENV_IS_EMBEDDED? is not set on the ICU862 board, since the environment is located after the end of the U-Boot image, but not embedded within it.
The #ifdef in "cpu/mpc8xx/start.S" makes sure that clear_bss() does not attempt to clear any memory that belongs to the environment.
but only if ENV_IS_EMBEDDED is NOT set... unless i'm missing something obvious?
I see no discrepancy - ENV_IS_EMBEDDED is NOT set for ICU862
Split it now, and submit any stable parts of it.
Too much is tangled together, i will try, but it doesn't look good.
I know how that feels. Split splittable parts, then.
Best regards,
Wolfgang Denk
On Mon, Jun 23, 2003 at 11:35:48PM +0200, Wolfgang Denk wrote:
In message 20030623212553.GA10209@zumanetworks.com you wrote:
shouldn't the ifdef depend on ENV_IS_EMBEDDED? If that is set, even in the ICU862 case, nothing in environment.c gets compiled (ALL of the code is ifdef'ed out), and "environment" will be unresolved..
ENV_IS_EMBEDDED? is not set on the ICU862 board, since the environment is located after the end of the U-Boot image, but not embedded within it.
The #ifdef in "cpu/mpc8xx/start.S" makes sure that clear_bss() does not attempt to clear any memory that belongs to the environment.
but only if ENV_IS_EMBEDDED is NOT set... unless i'm missing something obvious?
I see no discrepancy - ENV_IS_EMBEDDED is NOT set for ICU862
I'm sorry, i must be dense, i'm still not getting this (i do not know anything about the ICU board) ...
So, leave in the ifdef ICU862 case, but what about FADS (and other boards) which may or may not have ENV_IS_EMBEDDED set?
shouldn't they also NOT initialize past the bss into environment.o if ENV_IS_EMBEDDED is not set, but not refer to the "environment" symbol if ENV_IS_EMBEDDED IS set?
i.e.
#if !defined(ENV_IS_EMBEDDED) || defined(CONFIG_ICU862)
Sorry that this is taking so long to explain, but now i'm hopelessly confused ;/
In message 20030623214211.GA10366@zumanetworks.com you wrote:
I see no discrepancy - ENV_IS_EMBEDDED is NOT set for ICU862
I'm sorry, i must be dense, i'm still not getting this (i do not know anything about the ICU board) ...
So, leave in the ifdef ICU862 case, but what about FADS (and other boards) which may or may not have ENV_IS_EMBEDDED set?
I don't know anything about the FADS board. I tried to use one once. Probably I will never touch one again.
shouldn't they also NOT initialize past the bss into environment.o if ENV_IS_EMBEDDED is not set, but not refer to the "environment" symbol if ENV_IS_EMBEDDED IS set?
It depends on the flash layout, i. e. where your environment is located.
#if !defined(ENV_IS_EMBEDDED) || defined(CONFIG_ICU862)
No. "!defined(ENV_IS_EMBEDDED)" might include situations where the environment is in EEPROM or so.
Sorry that this is taking so long to explain, but now i'm hopelessly confused ;/
Me too. What's wrong with the existing code? Where does it cause problems?
Best regards,
Wolfgang Denk
On Tue, Jun 24, 2003 at 08:24:30PM +0200, Wolfgang Denk wrote:
Me too. What's wrong with the existing code? Where does it cause problems?
in FADS, where ENV_IS_EMBEDDED may or may not be set, depending on how big MONITOR_LENGTH is... (i.e. past FLASH_ENV_BASE or not)
In message 20030624202853.GA15860@zumanetworks.com you wrote:
On Tue, Jun 24, 2003 at 08:24:30PM +0200, Wolfgang Denk wrote:
Me too. What's wrong with the existing code? Where does it cause problems?
in FADS, where ENV_IS_EMBEDDED may or may not be set, depending on how big MONITOR_LENGTH is... (i.e. past FLASH_ENV_BASE or not)
But this is exactly the point of defining MONITOR_LENGTH: _if_ the environment shall be embedded in the U-Boot image (ENV_IS_EMBEDDED will be set), then MONITOR_LENGTH must be big enough to include the environment; and if the environment shall be in a separate flash sector, then MONITOR_LENGTH must be small enough NOT to include the environment.
I don't know who designed it that way (because I don't care about the FADS board), but according to "board/fads/u-boot.lds" the environment on this board is aligned on a 256kB boundary _after_ the U-Boot image. So MONITOR_LENGTH must not include the environment, and ENV_IS_EMBEDDED shall not be set.
Best regards,
Wolfgang Denk
On Tue, Jun 24, 2003 at 10:38:22PM +0200, Wolfgang Denk wrote:
In message 20030624202853.GA15860@zumanetworks.com you wrote:
On Tue, Jun 24, 2003 at 08:24:30PM +0200, Wolfgang Denk wrote:
Me too. What's wrong with the existing code? Where does it cause problems?
in FADS, where ENV_IS_EMBEDDED may or may not be set, depending on how big MONITOR_LENGTH is... (i.e. past FLASH_ENV_BASE or not)
But this is exactly the point of defining MONITOR_LENGTH: _if_ the environment shall be embedded in the U-Boot image (ENV_IS_EMBEDDED will be set), then MONITOR_LENGTH must be big enough to include the environment; and if the environment shall be in a separate flash sector, then MONITOR_LENGTH must be small enough NOT to include the environment.
I don't know who designed it that way (because I don't care about the FADS board), but according to "board/fads/u-boot.lds" the environment on this board is aligned on a 256kB boundary _after_ the U-Boot image. So MONITOR_LENGTH must not include the environment, and ENV_IS_EMBEDDED shall not be set.
In which case NOTHING in environment.c is compiled, and "environment" goes unresolved....
should it JUST be #ifdef CONFIG_ICU862?
In message 20030624235953.GA16810@zumanetworks.com you wrote:
I don't know who designed it that way (because I don't care about the FADS board), but according to "board/fads/u-boot.lds" the environment on this board is aligned on a 256kB boundary _after_ the U-Boot image. So MONITOR_LENGTH must not include the environment, and ENV_IS_EMBEDDED shall not be set.
In which case NOTHING in environment.c is compiled, and "environment" goes unresolved....
But this is normal for a non-embedded environment. If you don;t embed it with the U-Boot image it will not be initialized after installing the image anyway (because it is not included), so there is little sense initializing it at compile time.
There are several other options: in cases where the environment is directly adjecent to the U-Boot image (it looks as if the FADS is such a configuration) you can "include" the environment, producing a bigger image which then contains an initialized environment.
It is up for the board maintainer to decide what he wants.
Best regards,
Wolfgang Denk
On Thu, Jun 26, 2003 at 08:50:27AM +0200, Wolfgang Denk wrote:
In message 20030624235953.GA16810@zumanetworks.com you wrote:
I don't know who designed it that way (because I don't care about the FADS board), but according to "board/fads/u-boot.lds" the environment on this board is aligned on a 256kB boundary _after_ the U-Boot image. So MONITOR_LENGTH must not include the environment, and ENV_IS_EMBEDDED shall not be set.
In which case NOTHING in environment.c is compiled, and "environment" goes unresolved....
unresolved, meaning:
ld -Bstatic -T /home/nyet/src/local/u-boot/board/fads/u-boot.lds -Ttext 0x02800000 -n cpu/mpc8xx/start.o \ --start-group board/fads/libfads.a cpu/mpc8xx/libmpc8xx.a lib_ppc/libppc.a fs/jffs2/libjffs2.a fs/fdos/libfdos.a net/libnet.a disk/libdisk.a rtc/librtc.a dtt/libdtt.a drivers/libdrivers.a post/libpost.a post/cpu/libcpu.a common/libcommon.a lib_generic/libgeneric.a --end-group \ -Map u-boot.map -o u-boot cpu/mpc8xx/start.o(.got2+0x24):/local/nyet-build/u-boot-mrv/cpu/mpc8xx/start.S:99: undefined reference to `environment' make: *** [u-boot] Error 1
But this is normal for a non-embedded environment. If you don;t embed it with the U-Boot image it will not be initialized after installing the image anyway (because it is not included), so there is little sense initializing it at compile time.
There are several other options: in cases where the environment is directly adjecent to the U-Boot image (it looks as if the FADS is such a configuration) you can "include" the environment, producing a bigger image which then contains an initialized environment.
It is up for the board maintainer to decide what he wants.
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de All I ask is a chance to prove that money can't make me happy.
In message 20030626214057.GA28486@zumanetworks.com you wrote:
unresolved, meaning:
ld -Bstatic -T /home/nyet/src/local/u-boot/board/fads/u-boot.lds -Ttext 0x02800000 -n cpu/mpc8xx/start.o \ --start-group board/fads/libfads.a cpu/mpc8xx/libmpc8xx.a lib_ppc/libppc.a fs/jffs2/libjffs2.a fs/fdos/libfdos.a net/libnet.a disk/libdisk.a rtc/librtc.a dtt/libdtt.a drivers/libdrivers.a post/libpost.a post/cpu/libcpu.a common/libcommon .a lib_generic/libgeneric.a --end-group \ -Map u-boot.map -o u-boot cpu/mpc8xx/start.o(.got2+0x24):/local/nyet-build/u-boot-mrv/cpu/mpc8xx/start.S:99: undefined reference to `environment' make: *** [u-boot] Error 1
Strange. I see no such problems:
-> MAKEALL FADS823 FADS850SAR FADS860T ICU862 rm -f include/config.h include/config.mk Configuring for FADS823 board... text data bss dec hex filename 95364 323632 16372 435368 6a4a8 u-boot rm -f include/config.h include/config.mk Configuring for FADS850SAR board... text data bss dec hex filename 87028 284488 16296 387812 5eae4 u-boot rm -f include/config.h include/config.mk Configuring for FADS860T board... text data bss dec hex filename 87352 38776 16336 142464 22c80 u-boot rm -f include/config.h include/config.mk Configuring for ICU862 board... text data bss dec hex filename 106712 47928 16764 171404 29d8c u-boot
No errors, no warnings.
I think I lost you. Please let's restart from zero.
What exactly is your problem with the current code?
Best regards,
Wolfgang Denk
On Fri, Jun 27, 2003 at 12:03:19AM +0200, Wolfgang Denk wrote:
In message 20030626214057.GA28486@zumanetworks.com you wrote:
unresolved, meaning:
ld -Bstatic -T /home/nyet/src/local/u-boot/board/fads/u-boot.lds -Ttext 0x02800000 -n cpu/mpc8xx/start.o \ --start-group board/fads/libfads.a cpu/mpc8xx/libmpc8xx.a lib_ppc/libppc.a fs/jffs2/libjffs2.a fs/fdos/libfdos.a net/libnet.a disk/libdisk.a rtc/librtc.a dtt/libdtt.a drivers/libdrivers.a post/libpost.a post/cpu/libcpu.a common/libcommon .a lib_generic/libgeneric.a --end-group \ -Map u-boot.map -o u-boot cpu/mpc8xx/start.o(.got2+0x24):/local/nyet-build/u-boot-mrv/cpu/mpc8xx/start.S:99: undefined reference to `environment' make: *** [u-boot] Error 1
Strange. I see no such problems:
-> MAKEALL FADS823 FADS850SAR FADS860T ICU862 rm -f include/config.h include/config.mk Configuring for FADS823 board... text data bss dec hex filename 95364 323632 16372 435368 6a4a8 u-boot rm -f include/config.h include/config.mk Configuring for FADS850SAR board... text data bss dec hex filename 87028 284488 16296 387812 5eae4 u-boot rm -f include/config.h include/config.mk Configuring for FADS860T board... text data bss dec hex filename 87352 38776 16336 142464 22c80 u-boot rm -f include/config.h include/config.mk Configuring for ICU862 board... text data bss dec hex filename 106712 47928 16764 171404 29d8c u-boot
No errors, no warnings.
I think I lost you. Please let's restart from zero.
What exactly is your problem with the current code?
Ok. To summarize:
If ENV_IS_EMBEDDED is set in FADS, it does not get copied during relocation due to common/env_flash.c
If ENV_IS_EMBEDDED is NOT set (by reducing MONITOR_LEN to not include ENV), i get this error.
In message 20030626221032.GA28649@zumanetworks.com you wrote:
Ok. To summarize:
If ENV_IS_EMBEDDED is set in FADS, it does not get copied during relocation due to common/env_flash.c
If ENV_IS_EMBEDDED is NOT set (by reducing MONITOR_LEN to not include ENV), i get this error.
Sorry, I don't know much about the FADS (and actually I really don;t want to care about broken hardware like this; but anyway).
Which specific board configuration are you using?
Checking "include/configs/FADS860T.h" I see:
#define CFG_MONITOR_LEN (272 << 10) /* Reserve 272 kB for Monitor */ ... #define CFG_ENV_IS_IN_FLASH 1 #define CFG_ENV_OFFSET 0x00040000 #define CFG_ENV_SIZE 0x4000 /* Total Size of Environment Sector */ #define CFG_ENV_SECT_SIZE 0x40000 /* see README - env sector total size */
After building the board "u-boot.map" says:
... .text 0x02800000 0x15538 cpu/mpc8xx/start.o(.text) .text 0x02800000 0x2468 cpu/mpc8xx/start.o 0x028001c8 _start_of_vectors ... 0x0281b77c __init_end = . 0x0281b77c __bss_start = . ... .ppcenv 0x02840000 0x4000 common/environment.o(.ppcenv) .ppcenv 0x02840000 0x4000 common/environment.o 0x02840000 environment 0x02844000 _end = . 0x02844000 PROVIDE (end, .) Address of section .text set to 0x2800000 ...
So the text segment starts at 0x02800000, and one sector (or 256 kB) later at 0x02840000 the environment follows. CFG_MONITOR_LEN is bigger than __bss_start, so ENV_IS_EMBEDDED should be set.
You are right, the environment will NOT be copied in function env_relocate_spec() in "common/env_flash.c", but it _will_ be copied in function env_relocate() in "common/env_common.c" (assuming gd->env_valid is zero).
I think this is correct. What am I missing?
Best regards,
Wolfgang Denk
On Fri, Jun 27, 2003 at 12:31:29AM +0200, Wolfgang Denk wrote:
In message 20030626221032.GA28649@zumanetworks.com you wrote:
Ok. To summarize:
If ENV_IS_EMBEDDED is set in FADS, it does not get copied during relocation due to common/env_flash.c
If ENV_IS_EMBEDDED is NOT set (by reducing MONITOR_LEN to not include ENV), i get this error.
.... snip
You are right, the environment will NOT be copied in function env_relocate_spec() in "common/env_flash.c", but it _will_ be copied in function env_relocate() in "common/env_common.c" (assuming gd->env_valid is zero).
I think this is correct. What am I missing?
but that is the default environment that is copied, not the saved copy stored via saveenv? When is the saved environment restored? relocate_code() never copies it since it is AFTER __init_end due to the way u-boot.lds locates environment.o after .bss
In message 20030626224147.GA28873@zumanetworks.com you wrote:
I think this is correct. What am I missing?
but that is the default environment that is copied, not the saved copy stored via saveenv? When is the saved environment restored? relocate_code() never copies it since it is AFTER __init_end due to the way u-boot.lds locates environment.o after .bss
Argh... now I see. Well, I think you are right.
Best regards,
Wolfgang Denk
On Fri, Jun 27, 2003 at 01:10:57AM +0200, Wolfgang Denk wrote:
In message 20030626224147.GA28873@zumanetworks.com you wrote:
I think this is correct. What am I missing?
but that is the default environment that is copied, not the saved copy stored via saveenv? When is the saved environment restored? relocate_code() never copies it since it is AFTER __init_end due to the way u-boot.lds locates environment.o after .bss
Argh... now I see. Well, I think you are right.
let me know when you come up with a recommended solution; for now I have removed those ifdef's in start.S and reduced MONITOR_LEN such that ENV_IS_EMBEDDED is not set.
Suggestions for the ENV_IS_EMBEDDED case?
In post/memory.c file
int memory_post_test (int flags) { int ret = 0; DECLARE_GLOBAL_DATA_PTR; bd_t *bd = gd->bd; unsigned long memsize = (bd->bi_memsize >= 256 << 20 ? 256 << 20 : bd->bi_memsize) - (1 << 20);
if (flags & POST_POWERFAIL) { ret = memory_post_tests (CFG_SDRAM_BASE, memsize); } else { /* POST_POWERNORMAL */
unsigned long i;
for (i = 0; i < (memsize >> 20) && ret == 0; i++) { if (ret == 0) ret = memory_post_tests (i << 20, 0x800); if (ret == 0) ret = memory_post_tests ((i << 20) + 0xff800, 0x800); } }
return ret; }
I think the line should be:
unsigned long memsize = (bd->bi_memsize >= 257 << 20 ? 256 << 20 : bd->bi_memsize) - (1 << 20);
Yabo Ding bobfree@bonbon.net
In message 3EFBBE6A.6000200@bonbon.net you wrote:
In post/memory.c file
...
unsigned long memsize = (bd->bi_memsize >= 256 << 20 ? 256 << 20 : bd->bi_memsize) - (1 << 20);
...
I think the line should be:
unsigned long memsize = (bd->bi_memsize >= 257 << 20 ? 256 << 20 : bd->bi_memsize) - (1 << 20);
Will you please explain what makes you think so?
Best regards,
Wolfgang Denk
Sorry, I have a mistake about the parenthesis' position.
Yabo Ding
Wolfgang Denk wrote:
In message 3EFBBE6A.6000200@bonbon.net you wrote:
In post/memory.c file
...
unsigned long memsize = (bd->bi_memsize >= 256 << 20 ? 256 << 20 : bd->bi_memsize) - (1 << 20);
...
I think the line should be:
unsigned long memsize = (bd->bi_memsize >= 257 << 20 ? 256 << 20 : bd->bi_memsize) - (1 << 20);
Will you please explain what makes you think so?
Best regards,
Wolfgang Denk
On Sun, Jun 22, 2003 at 06:22:03PM +0200, Wolfgang Denk wrote:
No.
If you look at the u-boot.map file when building for the ICU862 board you can see this:
... 0x40f22b3c __init_end = . 0x40f22b3c __bss_start = .
.bss 0x40f22c00 0x417c ... 0x40f26c30 flash_info 0x40f40000 . = ALIGN (0x40000)
.ppcenv 0x40f40000 0x4000 common/environment.o(.ppcenv) .ppcenv 0x40f40000 0x4000 common/environment.o 0x40f40000 environment 0x40f44000 _end = . 0x40f44000 PROVIDE (end, .)
The #ifdef in "cpu/mpc8xx/start.S" makes sure that clear_bss() does not attempt to clear any memory that belongs to the environment.
but later, you write:
I see no discrepancy - ENV_IS_EMBEDDED is NOT set for ICU862
how does environment.o have any data; it is totally ifdef'ed out if ENV_IS_EMBEDDED is not set...?
I am totally confused now ;/
In message 20030625002749.GA17011@zumanetworks.com you wrote:
I see no discrepancy - ENV_IS_EMBEDDED is NOT set for ICU862
how does environment.o have any data; it is totally ifdef'ed out if ENV_IS_EMBEDDED is not set...?
It does not. On the ICU862 the U-Boot image is at the lower end of the enfironment, while the environment is at the upper end (IIRC this board uses top boot sector flash memory). The environment does NOT get installed when installing the U-Boot image. So there is no need to put any initialized data in it.
It will be initialized as soon as the user types "saveenv" for the first time. Until then, the default environment is used.
I am totally confused now ;/
I'm sorry.
Best regards,
Wolfgang Denk
participants (3)
-
Nye Liu -
Wolfgang Denk -
Yabo Ding