public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: David Hawkins <dwh@ovro.caltech.edu>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Altera Stratix II
Date: Sat, 01 Mar 2008 13:51:40 -0800	[thread overview]
Message-ID: <47C9CFEC.4050704@ovro.caltech.edu> (raw)
In-Reply-To: <ffc2b1d40803011332s33e18e29p961b750d4621e563@mail.gmail.com>

Hi Liberty,

> I believe I will prefare crippling the CFI over Crippling the flash
> eeprom as I believe it will be easier on our production team... But I
> will have to play with it some more...

If I understand your earlier posts, you are using a CFI
flash, and then 'hiding' half or more of that Flash
from the end user. You mention 'lifting pins', but I'm
not sure if you were actually doing that, or effectively
doing that using your FPGA on the Flash address lines.

A few questions

1. Does it really matter if the user can read the data?

    If not, just use the write-protect feature of the Flash
    to protect it from users. Eg. have the local bus FPGA
    decode the flash chip select, and address, and keep
    write-protect asserted for the regions you want to
    protect.

2. Is there any way to have your FPGA do this hiding for you?

    For example, if the FPGA decoded the Flash chip select,
    it could allow the Flash to respond to low-addresses,
    and could itself drive zeros on the bus for accesses
    to the hidden region.

3. Even if you lift the pins on the Flash, what is to stop
    the user doing a full chip erase, and deleting your
    unseen settings?


Cheers,
Dave

  reply	other threads:[~2008-03-01 21:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-26  7:19 [U-Boot-Users] Altera Stratix II Markus Brunner
2008-02-26  7:23 ` Jean-Christophe PLAGNIOL-VILLARD
2008-02-28 22:18   ` eran liberty
2008-02-29 17:45     ` Detlev Zundel
2008-02-29 19:56       ` eran liberty
2008-02-29 21:18         ` Wolfgang Denk
2008-02-29 21:36           ` eran liberty
2008-02-29 21:46             ` Brent Cook
2008-03-01 19:36               ` Michael Schwingen
2008-02-29 23:55             ` Wolfgang Denk
2008-03-01 21:32               ` eran liberty
2008-03-01 21:51                 ` David Hawkins [this message]
2008-03-02  0:29                   ` [U-Boot-Users] MPC8349EMDS.h Why do the BAT entries use Memory coherency? David Hawkins
2008-03-03 17:55                     ` David Hawkins
     [not found]                       ` <47CD7DCF.1070207@ovro.caltech.edu>
2008-03-04 20:48                         ` [U-Boot-Users] BDI .cfg for MPC8349E/EA-MDS-PB [1/2] David Hawkins
2008-03-04 20:49                         ` [U-Boot-Users] BDI .cfg for MPC8349E/EA-MDS-PB [2/2] David Hawkins
2008-03-02  9:21                   ` [U-Boot-Users] Altera Stratix II eran liberty
2008-03-02  0:35                 ` 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=47C9CFEC.4050704@ovro.caltech.edu \
    --to=dwh@ovro.caltech.edu \
    --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