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
next prev parent 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.