[U-Boot-Users] cfi_flash init got real slow

[U-Boot-Users] cfi_flash init got real slow

[Reinhard Arlt]

Hello,

i have changed the flash support in u-boot for the CPCI750 from a local 
flash.c to the usage of cfi_flash.c a month ago.

With the u-boot version from git from yesterday, flash init take about 
20 seconds (it tooks no noticeable time with the last version).

This is not acceptable.

It is also not acceptable to disable flash protection.

The problem is the code, that "invents" this "auto" flash unprotection 
in the flash_init routine. Please consider, that there are systems out 
with the env in eeprom, and, by the way, reading the "unlock" variable 
with the loop for each devive two times is not too good coding style.

Please be carefull with changes, that have an impact to other systems.

Kind regards

Reinhard

[U-Boot-Users] cfi_flash init got real slow

[Wolfgang Denk]

In message <441DC9C7.5070301@t-online.de> you wrote:
> 
> This is not acceptable.
> 
> It is also not acceptable to disable flash protection.

This has been discussed before. Please see the archives.

> The problem is the code, that "invents" this "auto" flash unprotection 
> in the flash_init routine. Please consider, that there are systems out 
> with the env in eeprom, and, by the way, reading the "unlock" variable 

It is your own problem if you store important data  like  the  U-Boot
environment  in  inherently unreliable memory like I2C EEPROM. I will
not discuss this here. Also, I don't see how this is related  to  the
CFI driver code.

> with the loop for each devive two times is not too good coding style.

Please feel free to submit a patch that improves the code.

> Please be carefull with changes, that have an impact to other systems.

All this has been discussed a long, long time ago. Also, if you  read
carefully,  you  wil  see that the behaviour is run-time configurable
using the "unlock" environment variable.


So what exactly are you complaining about? Maybe you can come up with
a constructive comment...

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
I am a computer. I am dumber than any human and smarter than any  ad-
ministrator.

[U-Boot-Users] cfi_flash init got real slow

[Reinhard Arlt]

Hello,

please don't cut the part of my mail, that describe the problem:

-->"With the u-boot version from git from yesterday, flash init take 
-->"about 20 seconds (it tooks no noticeable time with the last version)."


Wolfgang Denk wrote:
> In message <441DC9C7.5070301@t-online.de> you wrote:
> 
>>This is not acceptable.
>>
>>It is also not acceptable to disable flash protection.
>
> 
> This has been discussed before. Please see the archives.
>
The feature is good, but in a common piece of code, there should be a 
way to disable it.
> 
>>The problem is the code, that "invents" this "auto" flash unprotection 
>>in the flash_init routine. Please consider, that there are systems out 
>>with the env in eeprom, and, by the way, reading the "unlock" variable 
> 
> 
> It is your own problem if you store important data  like  the  U-Boot
> environment  in  inherently unreliable memory like I2C EEPROM. I will
> not discuss this here. Also, I don't see how this is related  to  the
> CFI driver code.
>
Without starting this thread again, this is true only for some type of 
hardware.
> 
>>with the loop for each devive two times is not too good coding style.
> 
> 
> Please feel free to submit a patch that improves the code.
>
> 
>>Please be carefull with changes, that have an impact to other systems.
> 
> 
> All this has been discussed a long, long time ago. Also, if you  read
> carefully,  you  wil  see that the behaviour is run-time configurable
> using the "unlock" environment variable.
> 
> 
> So what exactly are you complaining about? Maybe you can come up with
> a constructive comment...
1. The startup time of the flash module is now more then 20 seconds! 
This is more then the CPCI750 need's to the command prompt before the 
invention of this feature. This is due to the fact, that flash_init is 
called before env_relocate, and the bad implementation of the unprotect 
feature.
2. The code, that invent the flash unlock has the quality of a "quick 
hack": If you have four flash banks, the env will be read eight times, 
one time should be enough.
3. That i can not get rid of these unprotect feature with a build 
option: It is allways in the code, if CFG_FLASH_PROTECTION is enabled, a 
CFG_FLASH_NOAUTOPROTECT would help to get rid of this code, if i do not 
need it.
> 
> Best regards,
> 
> Wolfgang Denk
> 

Kind regards

Reinhard Arlt

[U-Boot-Users] cfi_flash init got real slow

[Wolfgang Denk]

In message <441E7ED1.9040401@t-online.de> you wrote:
> 
> > All this has been discussed a long, long time ago. Also, if you  read
> > carefully,  you  wil  see that the behaviour is run-time configurable
> > using the "unlock" environment variable.
...
> 1. The startup time of the flash module is now more then 20 seconds! 

Did you try unsing the "unlock" environment variable? Were there  any
problems with that?

> 2. The code, that invent the flash unlock has the quality of a "quick 
> hack": If you have four flash banks, the env will be read eight times, 
> one time should be enough.

Can you please submit a patch, then?

> 3. That i can not get rid of these unprotect feature with a build 
> option: It is allways in the code, if CFG_FLASH_PROTECTION is enabled, a 

Is there  anything  wrong  with  the  "unlock"  environment  variable
approach?

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
Human beings were created by water to transport it uphill.