[U-Boot-Users] u-boot locking ?
Hi,
I have some (basic) question .. 1) Does u-boot lock the block on which it resides by default ? I mean the sector /erase block on which u-boot is there, it will be locked using the block lock bit by default ?
Plafform in question being IXDP 425 with Intel J3 NOR Flash.
2) The flash content changing has to work in block sizes erase - modify - write cyecles only ??
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.
Any help in understanding of above issues will be really appreciated, Regards, Alfred
On Sunday 08 January 2006 17:21, alfred hitch wrote:
Hi,
I have some (basic) question ..
- Does u-boot lock the block on which it resides by default ?
I mean the sector /erase block on which u-boot is there, it will be locked using the block lock bit by default ?
Plafform in question being IXDP 425 with Intel J3 NOR Flash.
- The flash content changing has to work in block sizes erase -
modify - write cyecles only ??
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.
Any help in understanding of above issues will be really appreciated, Regards, Alfred
AFAIK u-boot normally only software protects sectors (mark them internally as read-only). You can lock the sector(s) in your board startup routine. Remember to do so after relocation to RAM.
Regards
Pantelis
Hi Pantelis / All,
I have been trying to get the protection working for ixdp425 + J3 flash. But, no luck so far.
When I turn on the CFI_FLASH_PROTECTION option in include/configs/ixdp425.h I get flash_real_protect undeclared.
A grep reveals that it is defined in file drivers/cfi_flash.c and is #ifdef'ed with CFG_FLASH_CFI_DRIVER ( Above needs CFG_FLASH_CFI)
Doing these, I notice that the flash_init function is being called now from the drivers/cfi_flash.c instead of earlier include/board/ixdp425.c
At this point code hangs. I guess the reason for this will be relocation for RAM is essential and isnt happening for this cfi_flash.c ?
How to do this, I am sure I am missing something very trivial here
I see lots of discussions on locking etc, but none which is similar to my problem.
Regards, Alfred
On 1/8/06, Pantelis Antoniou pantelis.antoniou@gmail.com wrote:
On Sunday 08 January 2006 17:21, alfred hitch wrote:
Hi,
I have some (basic) question ..
- Does u-boot lock the block on which it resides by default ?
I mean the sector /erase block on which u-boot is there, it will be locked using the block lock bit by default ?
Plafform in question being IXDP 425 with Intel J3 NOR Flash.
- The flash content changing has to work in block sizes erase -
modify - write cyecles only ??
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.
Any help in understanding of above issues will be really appreciated, Regards, Alfred
AFAIK u-boot normally only software protects sectors (mark them internally as read-only). You can lock the sector(s) in your board startup routine. Remember to do so after relocation to RAM.
Regards
Pantelis
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
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
Hi,
just to add to my last post, the u-boot seems to be hanging in the function: flash_get_size
???? Code comments in header for function says: * * The following code cannot be run from FLASH! * */
Any option I am missing which could be causing it to screw up ?
My compilation is simple: make clean; make ixdp425_config; make
(Before doing this, u-boot was working just fine for us )
Anyone has already tried marking blocks as locked on J3 Flash ? and can help ?
Regards, Alfred
On 1/9/06, alfred hitch alfred.hitch@gmail.com wrote:
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:
- 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 ??
- Read somewhere on net, that by deault all sectors are locked after
reboo t ? true ? does J3 Intel strata flash does it also automatically ?
- 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
In message 29f916510601090155q21ac4a8dy8ad8a9012b3b3603@mail.gmail.com you wrote:
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:
...
You may want to search the archive and read the previous postings to this topic first. There has been a long discussion about locking and what could or should be done about it.
Best regards,
Wolfgang Denk
participants (3)
-
alfred hitch -
Pantelis Antoniou -
Wolfgang Denk