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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox