[U-Boot-Users] [PATCH] Update OMAP242x for git head (plus sign).

Tolunay Orkun listmember at orkun.us
Fri Sep 30 01:36:06 CEST 2005


Wolfgang Denk wrote:

>>Would you consider something like CFG_FLASH_PROTECT_LIST in board config 
>>file which defines an array of blocks that needs to be kept protected? 
>>This would be a list similar to CFG_FLASH_BANKS_LIST. This would take 
>>care of important sections of flash (beyond u-boot and environment) that 
>>needs to be protected for that particular board.
> 
> 
> Just to make sure I understand your intentions:  such  marked  blocks
> would  be handled in exactly the same way as the areas which are used
> to store U-Boot and the environment, i.  e.  they  are  protected  by
> default after each reset, but can be unprotected by the user?

Yes

> I see that such an extension would be useful  for  example  to  store
> FPGA images which might be vital to get the board running at all, and
> similar things.

Yes. Also useful to protect linux/initrd etc. images.

> Yes, I would  consider  such  an  extension,  but  then  it  must  be
> generally  available,  i.  e.  for all flash types. I understand that
> probably the cfi_flash driver would be  the  first  to  support  this
> feature, but maybe the code can be made generic enough that it can be
> called  by  custom flash drivers as well so all boards can use it (if
> they like), and we can use the same method for protecting U-Boot  and
> it's environment sectors?

I was initially thinking to add that functionality to flash_init() of 
cfi_flash.c. Other flash.c would need to implement the same way. 
However, there is a way to implement it in flash driver agnostic way.

I can create a generic flash_protect_init() function (pick a better name 
if you don't like it) which is called after flash_init() from 
lib_xxx/board.c files.

The implementation of flash_protect_init() would sit in a common file 
(perhaps in common/flash.c). flash_protect_init() would call 
flash_protect() for the list provided via CFG_FLASH_PROTECT_LIST (if 
defined) as well as for U-Boot code and environment areas.

This way the feature can be integrated consistently for all flash chip 
drivers and protection of U-Boot and environment would be standardized 
(and duplicate code could be removed from cfi_flash.c and other drivers)

Best regards,
Tolunay




More information about the U-Boot mailing list