[U-Boot-Users] ENV_IS_EMBEDDED functionality

Hello Mr. Denk, I have a question regarding the functionality provided by ENV_IS_EMBEDDED. Currently, this value is computed only for the case CFG_ENV_IS_IN_FLASH defined in environment.h, and is based on the flash addresses of the environment being defined as inside the executing addresses of u-boot. This seems to be designed for the case where u-boot is executed out of flash and not copied into ram for execution. There is an old configuration variable, CFG_ENV_IS_EMBEDDED, that appears to be non-functional and deprecated. I am working with u-boot for the Analog Devices Blackfin chip, which has not yet been submitted to mainstream (AFAIK). The code directly defines ENV_IS_EMBEDDED to force that functionality even though it is copied to ram for execution (and thereby making the embedded determination in environment.h false). The linker script is fixed up to force the environment data onto a flash sector boundary, so everything works. It does however mean that u-boot cannot be updated without destroying the old environment data. This approach is also used for a serial flash on the spi bus using the env_eeprom module and CFG_ENV_IS_IN_EEPROM. Normally ENV_IS_EMBEDDED could not be defined in this case. My question is: What is your opinion of this approach? It seems to me that this makes ENV_IS_EMBEDDED a configuration parameter (again), which provides some (useful?) functionality but may not be what you envision. If ENV_IS_EMBEDDED is a configuration option, the name should be changed to include CFG, shouldn't it? The main advantages I see of allowing this are 1) CFG_ENV_OFFSET is fixed forever, u-boot growth will never collide with it. 2) Some flash space can be saved because the sector alignment of the environment data can be optimized as opposed to tacking it onto the end (which may waste almost an entire flash sector). Is this worth another configuration parameter? I do not want to go too far down this road if it will not be acceptable to you in any case. Thank you for your attention!
Best Regards, Bill Campbell

In message 43C7FF53.7020809@comcast.net you wrote:
I have a question regarding the functionality provided by
ENV_IS_EMBEDDED. Currently, this value is computed only for the case CFG_ENV_IS_IN_FLASH defined in environment.h, and is based on the flash
Yes, because it can only be located in the middle of the U-Boot image in flash if the environment is stored itself in flash - you cannot have this if the environment is, for example, sotred in a EEPROM.
addresses of the environment being defined as inside the executing addresses of u-boot. This seems to be designed for the case where u-boot is executed out of flash and not copied into ram for execution. There is
Wrong. This has nothing to do with execution, just with storage.
an old configuration variable, CFG_ENV_IS_EMBEDDED, that appears to be non-functional and deprecated. I am working with u-boot for the Analog Devices Blackfin chip, which has not yet been submitted to mainstream
I think I remember to have seen patches here on the list - search the archives, please.
(AFAIK). The code directly defines ENV_IS_EMBEDDED to force that functionality even though it is copied to ram for execution (and thereby
This has nothing to do with execution.
My question is: What is your opinion of this approach? It seems
You misunderstand the function.
Best regards,
Wolfgang Denk

Thanks for the quick response. There are some Blackfin related questions on the old list, but the attempt made a couple of years ago to submit the patches was rejected for a lot of reasons. I was not involved at that time. I am attempting to determine if this ENV_IS_EMBEDDED approach is also going to be rejected so I can find another way. It is not clear to me that it is really necessary, but I want to understand further the functionality to determine if it is in any way useful. This reflects the current state of the Blackfin code, so I am trying to clean it up somewhat. I have a further question below.
Wolfgang Denk wrote:
In message 43C7FF53.7020809@comcast.net you wrote:
I have a question regarding the functionality provided by
ENV_IS_EMBEDDED. Currently, this value is computed only for the case CFG_ENV_IS_IN_FLASH defined in environment.h, and is based on the flash
Yes, because it can only be located in the middle of the U-Boot image in flash if the environment is stored itself in flash - you cannot have this if the environment is, for example, sotred in a EEPROM.
addresses of the environment being defined as inside the executing addresses of u-boot. This seems to be designed for the case where u-boot is executed out of flash and not copied into ram for execution. There is
Wrong. This has nothing to do with execution, just with storage.
The source of my confusion is that ENV_IS_EMBEDDED is defined as follows in environment.h #if (CFG_ENV_ADDR >= CFG_MONITOR_BASE) && \ (CFG_ENV_ADDR+CFG_ENV_SIZE) <= (CFG_MONITOR_BASE+CFG_MONITOR_LEN) #define ENV_IS_EMBEDDED 1 #endif Isn't CFG_MONITOR_BASE the address where u-boot resides for execution? It is defined that way on the Blackfin code because CFG_MONITOR_BASE is defined as TEXT_BASE and TEXT_BASE is defined as 0x07FC0000. The flash memory is located at CFG_FLASH_BASE (defined as 0x20000000) and CFG_ENV_ADDR is 0x20004000. U-boot is loaded into flash at 0x20000000, so the environment data does reside in flash even though the ENV_IS_EMBEDDED test fails. The code gets around this by just defining it directly. So is CFG_MONITOR_BASE incorrectly defined and it should be a flash address?? BTW the u-boot code is not compiled PIC, so the execution address must matc the link address.
an old configuration variable, CFG_ENV_IS_EMBEDDED, that appears to be non-functional and deprecated. I am working with u-boot for the Analog Devices Blackfin chip, which has not yet been submitted to mainstream
I think I remember to have seen patches here on the list - search the archives, please.
(AFAIK). The code directly defines ENV_IS_EMBEDDED to force that functionality even though it is copied to ram for execution (and thereby
This has nothing to do with execution.
My question is: What is your opinion of this approach? It seems
You misunderstand the function.
Best regards,
Wolfgang Denk

In message 43C82439.6030102@comcast.net you wrote:
Thanks for the quick response. There are some Blackfin related questions on the old list, but the attempt made a couple of years ago to submit the patches was rejected for a lot of reasons. I was not involved at that time. I am attempting to determine if this ENV_IS_EMBEDDED approach is also going to be rejected so I can find another way. It is
Yes. Please don't invent new stuff without need. The existing code is ugly (being a mess of #ifdef's), but serves a purpose (minimal code footprint because all these things get computed at compile time) and covers all existing configurations so far.
The source of my confusion is that ENV_IS_EMBEDDED is defined as follows in environment.h #if (CFG_ENV_ADDR >= CFG_MONITOR_BASE) && \ (CFG_ENV_ADDR+CFG_ENV_SIZE) <= (CFG_MONITOR_BASE+CFG_MONITOR_LEN) #define ENV_IS_EMBEDDED 1 #endif Isn't CFG_MONITOR_BASE the address where u-boot resides for execution?
No. It's the start address of the image in flash. As mentioned before, this has *nothing* to do with execution.
It is defined that way on the Blackfin code because CFG_MONITOR_BASE is defined as TEXT_BASE and TEXT_BASE is defined as 0x07FC0000. The flash memory is located at CFG_FLASH_BASE (defined as 0x20000000) and CFG_ENV_ADDR is 0x20004000. U-boot is loaded into flash at 0x20000000,
Ummm... then 0x07FC0000 must be a RAM address, right? Then your definition of CFG_MONITOR_BASE is broken. You should have CFG_MONITOR_BASE = 0x20000000.
so the environment data does reside in flash even though the ENV_IS_EMBEDDED test fails. The code gets around this by just defining
Misconfiguration.
it directly. So is CFG_MONITOR_BASE incorrectly defined and it should be a flash address?? BTW the u-boot code is not compiled PIC, so the
Yes.
execution address must matc the link address.
...or you must relocate it.
Best regards,
Wolfgang Denk
participants (2)
-
J. William Campbell
-
Wolfgang Denk