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