All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tolunay Orkun <listmember@orkun.us>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] Update OMAP242x for git head (plus sign).
Date: Thu, 29 Sep 2005 18:36:06 -0500	[thread overview]
Message-ID: <433C7A66.1000904@orkun.us> (raw)
In-Reply-To: <20050929222014.55EF0352597@atlas.denx.de>

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

  reply	other threads:[~2005-09-29 23:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-29  0:01 [U-Boot-Users] [PATCH] Update OMAP242x for git head (plus sign) Woodruff, Richard
2005-09-29 13:24 ` Wolfgang Denk
2005-09-29 20:28   ` Tolunay Orkun
2005-09-29 21:17     ` Wolfgang Denk
2005-09-29 22:07       ` Tolunay Orkun
2005-09-29 22:20         ` Wolfgang Denk
2005-09-29 23:36           ` Tolunay Orkun [this message]
2005-09-30  8:12             ` Wolfgang Denk
  -- strict thread matches above, loose matches on Subject: below --
2005-09-28 21:20 Woodruff, Richard
2005-09-28 23:46 ` 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=433C7A66.1000904@orkun.us \
    --to=listmember@orkun.us \
    --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.