[U-Boot-Users] ENV_IS_EMBEDDED functionality

[U-Boot-Users] ENV_IS_EMBEDDED functionality

[J. William Campbell]

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

[U-Boot-Users] Re: ENV_IS_EMBEDDED functionality

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Unix is simple, but it takes a genius to understand the simplicity."
					             - Dennis Ritchie

[U-Boot-Users] Re: ENV_IS_EMBEDDED functionality

[J. William Campbell]

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

[U-Boot-Users] Re: ENV_IS_EMBEDDED functionality

[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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There's an old story about the person who wished his computer were as
easy to use as his telephone. That wish has come  true,  since  I  no
longer know how to use my telephone.