All of lore.kernel.org
 help / color / mirror / Atom feed
From: Reinhard Arlt <reinhard.arlt@t-online.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] cfi_flash init got real slow
Date: Mon, 20 Mar 2006 11:07:13 +0100	[thread overview]
Message-ID: <441E7ED1.9040401@t-online.de> (raw)
In-Reply-To: <20060319220540.2CD913535EA@atlas.denx.de>

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

  reply	other threads:[~2006-03-20 10:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-19 21:14 [U-Boot-Users] cfi_flash init got real slow Reinhard Arlt
2006-03-19 22:05 ` Wolfgang Denk
2006-03-20 10:07   ` Reinhard Arlt [this message]
2006-03-20 20:16     ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=441E7ED1.9040401@t-online.de \
    --to=reinhard.arlt@t-online.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.