Hi Wolfgang,
Thanks for your mails, u-boot in mycase also I observed wasnt being called with hardware protection on.
I will appreciate if someone can help me with following questions: 1) I enabled these 3 defines in the include/configs/ixdp425.h #define CFG_FLASH_PROTECTION #define CFG_FLASH_CFI_DRIVER #define CFG_FLASH_CFI
From what appeared logical (and compilation needs) to me.
But, when I am booting the system now, its hanging after displaying the RAM configuration.
I have just begun to trace down on what could be wrong,but it looks from initial traces to be in flash_init.
Anything I am missing / doing wrong ??
2) Read somewhere on net, that by deault all sectors are locked after reboo t ? true ? does J3 Intel strata flash does it also automatically ?
3) Remember to do so after relocation to RAM. :: Can you please help me to correct place, code path / function to do so ? I am very new to u-boot.
Regards, Alfred
On 1/8/06, Wolfgang Denk wd@denx.de wrote:
In message 29f916510601080721vd20b512u819ee9bce7ad1408@mail.gmail.com you wrote:
- Does u-boot lock the block on which it resides by default ?
Not by default, but you can inplement in your flah driver whichever features you like.
I mean the sector /erase block on which u-boot is there, it will be locked using the block lock bit by default ?
Remember that only few flash chips provide such hardware locking, and that some boards implement even other ways of write protection of parts of or of the whole flash device.
- The flash content changing has to work in block sizes erase -
modify - write cyecles only ??
No. You can write single bytes (as long as you are only changing '1' bits to '0').
Reason for all this is that we have few boards on which u-boot is getting corrupted (on flash image corruption itself). And so am wondering even if its a noise issue, how can it first cause an unlock of sector before write.
Normally the flash is not hardare write protected, and if your hardware designer used flash chips which can be corrupted for example by just writing arbitrary data to a sequential address range you may easily see such corruption. There is a very good reason why AMD flash chips require a specific programming sequence which must be written in a certain sequence to certain non-consequitive addresses.
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de PoB = "Prisoner of Bill" -- those held captive, unwillingly or other- wise, by the contemptible Microsoft monopoly. -- Tom Christiansen in 6abo45$3lc$2@csnews.cs.colorado.edu