[U-Boot-Users] Altera Stratix II

[U-Boot-Users] Altera Stratix II

[Markus Brunner]

Hi,

I've seen some patches for stratix II support on the Mailinglist, but none 
ended up in the git repository. 
e.g.:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/28559

Where are the problems and what has to be done to bring them into u-boot?

Regards

Markus

[U-Boot-Users] Altera Stratix II

[Jean-Christophe PLAGNIOL-VILLARD]

On 08:19 Tue 26 Feb     , Markus Brunner wrote:
> Hi,
> 
> I've seen some patches for stratix II support on the Mailinglist, but none 
> ended up in the git repository. 
> e.g.:
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/28559
> 
> Where are the problems and what has to be done to bring them into u-boot?

First, the patch is broken
Second, there some coding style
Third, the patch won't applied on the current tree

Feel free to send a rebase and fixed patch

Best Regards,
J.

[U-Boot-Users] Altera Stratix II

[eran liberty]

First of all,
I still have my patches and am working (for reasons which are
connected with the flat device tree & initrd) to make them patch
cleanly against latest RC. If any want wants them for him self or any
interested in making the effort to apply them... I will gladly send
him/her everything i have.

Second:
If you follow the mailing list you can see I have tried real hard to
follow the general conformance and be a nice contributing dude. At the
time my patches where applied cleanly against whatever git version i
was told to... at some point i had enough of those games.

Third:
This is no Ego games/wars and i certainly don't need my name carved in
u-boot code for eternity (though i think it already is somewhere) . If
anyone wants to have my patches I will gladly give them (just don't
tell me you don't like the indention or whatever)
right now i have a patch that will burn Altera Statrix II in Fast
Passive Serial, Fast Passive Parallel and Fast Passive Parallel
encrypted.
Both parallel have been a bit neglected since in the end we chose to
go with the Passive serial (which can do encrypted no extra charge) .
But they are there.

Yours,
Liberty

On Tue, Feb 26, 2008 at 9:23 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
>
> On 08:19 Tue 26 Feb     , Markus Brunner wrote:
> > Hi,
> >
> > I've seen some patches for stratix II support on the Mailinglist, but none
> > ended up in the git repository.
> > e.g.:
> > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/28559
> >
> > Where are the problems and what has to be done to bring them into u-boot?
>
> First, the patch is broken
> Second, there some coding style
> Third, the patch won't applied on the current tree
>
> Feel free to send a rebase and fixed patch
>
> Best Regards,
> J.
>

[U-Boot-Users] Altera Stratix II

[Detlev Zundel]

Hi Eran and Markus,

> I still have my patches and am working (for reasons which are
> connected with the flat device tree & initrd) to make them patch
> cleanly against latest RC. If any want wants them for him self or any
> interested in making the effort to apply them... I will gladly send
> him/her everything i have.

Good, thanks.

> Second:
> If you follow the mailing list you can see I have tried real hard to
> follow the general conformance and be a nice contributing dude. At the
> time my patches where applied cleanly against whatever git version i
> was told to... at some point i had enough of those games.

Do you really think that rules that *everyone* contributing to a project
has to follow to achieve goals like maintainability, readability and
changeability is "playing games"?  

I admit that the rules are checked pretty strictly in U-Boot, but the
rules as such are in my opinion pretty comparable to other projects....

> Third:
> This is no Ego games/wars and i certainly don't need my name carved in
> u-boot code for eternity (though i think it already is somewhere) . If
> anyone wants to have my patches I will gladly give them (just don't
> tell me you don't like the indention or whatever)

I would really like to see Eran to get the patches into acceptable state
(should be not much work from what I can tell), but if this does not
happen, Markus can you pick up the patches and massage them into
acceptance?  In this way you'd get what you want and contribute to
U-Boot?  This would be very much appreciated...

Cheers
  Detlev

-- 
The  mathematician's patterns,  like the  painter's or  the poet's,  must be
beautiful;  the ideas, like the colours or the words, must fit together in a
harmonious way. Beauty is the first test: there is no permanent place in the
world for ugly mathematics.                       -- G. H. Hardy
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot-Users] Altera Stratix II

[eran liberty]

As part of my current ongoing effort to get up to date with rc2 I will
produce a patch that will apply cleanly against that in a few a days.
Hopefully it will be adopted in one go.
If not I will grant others the honor to make it there.

And on another topic (since I am already here):

Flash memory size.
On all the versions till now I have cheated U-boot to believe I have a
16M flash though the real flash was of sizes 32,64,128,256, and 512.
This suited my goals very nicely because i could have a generic binary
u-boot image for all my products. As cfi_flash.c grew up it started
reading the eeprom embedded in the FLASH and learn for itself the real
size of the FLASH, but till now I was able to restrict it to desired
size from the config file, or cheat it by returning a constant in
get_flash_size() function.
Currently I am adopting RC2 and is having trouble making u-boot do
What I want (and not the other way around).
Trying to give a lower then expected MAX_SECT in the config file will
both give an error (which is better then crash) and will config the
wrong side of the flash (the first sectors). Cheating it by hard coded
does not seem to work as well.

Any pointers on the subject will be appreciated.

And since this turned out to be a long one... I believe there is a bug
in the fdt manipulation function when regarding the initrd and
reserved maps.
I do not fully understand this code so I suggest someone who knows his
way around there will take a look. It seems that after manipulating
the FDT by enlarging it by 64bit*2 and pushing the desired initrd
content... the local ctx pointers are updated but no one update the
original pointer in the FDT itself. dumping the tree right after that
operation will reveal a broken tree. I have implemented an update fdt
which takes the local pointer and write them back into the FDT and it
seems to solve it, but my initrd is not working yet so i am not sure
this is the right thing to do.

That's all.

Have fun,
Liberty

On Fri, Feb 29, 2008 at 7:45 PM, Detlev Zundel <dzu@denx.de> wrote:
> Hi Eran and Markus,
>
> > I still have my patches and am working (for reasons which are
> > connected with the flat device tree & initrd) to make them patch
> > cleanly against latest RC. If any want wants them for him self or any
> > interested in making the effort to apply them... I will gladly send
> > him/her everything i have.
>
> Good, thanks.
>
> > Second:
> > If you follow the mailing list you can see I have tried real hard to
> > follow the general conformance and be a nice contributing dude. At the
> > time my patches where applied cleanly against whatever git version i
> > was told to... at some point i had enough of those games.
>
> Do you really think that rules that *everyone* contributing to a project
> has to follow to achieve goals like maintainability, readability and
> changeability is "playing games"?
>
> I admit that the rules are checked pretty strictly in U-Boot, but the
> rules as such are in my opinion pretty comparable to other projects....
>
> > Third:
> > This is no Ego games/wars and i certainly don't need my name carved in
> > u-boot code for eternity (though i think it already is somewhere) . If
> > anyone wants to have my patches I will gladly give them (just don't
> > tell me you don't like the indention or whatever)
>
> I would really like to see Eran to get the patches into acceptable state
> (should be not much work from what I can tell), but if this does not
> happen, Markus can you pick up the patches and massage them into
> acceptance?  In this way you'd get what you want and contribute to
> U-Boot?  This would be very much appreciated...
>
> Cheers
>  Detlev
>
> --
> The  mathematician's patterns,  like the  painter's or  the poet's,  must be
> beautiful;  the ideas, like the colours or the words, must fit together in a
> harmonious way. Beauty is the first test: there is no permanent place in the
> world for ugly mathematics.                       -- G. H. Hardy
> --
> DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
>

[U-Boot-Users] Altera Stratix II

[Wolfgang Denk]

In message <ffc2b1d40802291156o65bd167el8586288c5c07df3b@mail.gmail.com> you wrote:
> As part of my current ongoing effort to get up to date with rc2 I will
> produce a patch that will apply cleanly against that in a few a days.

In a few days we will have at least -rc3, if not 1.3.2.

> Flash memory size.
> On all the versions till now I have cheated U-boot to believe I have a
> 16M flash though the real flash was of sizes 32,64,128,256, and 512.
> This suited my goals very nicely because i could have a generic binary
> u-boot image for all my products. As cfi_flash.c grew up it started

I cannot understand why this should be necessary. we've  always  been
using the same U-Boot image no matter what the flash or RAM size was.
Actually  this  is  a  major  design  philosophy  of  U-Boot *not* to
hardcode memory sizes butto  automatically  deal  with  te  sizes  it
actually finds on the board.

> Currently I am adopting RC2 and is having trouble making u-boot do
> What I want (and not the other way around).

I think what you're trying to do is fundamentally broken.  Why  don't
you  use  the  real sizes present on the hardware? Why do you want to
lie to yourself and to your users?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
...though his invention worked superbly -- his theory was a crock  of
sewage from beginning to end.         - Vernor Vinge, "The Peace War"

[U-Boot-Users] Altera Stratix II

[eran liberty]

On Fri, Feb 29, 2008 at 11:18 PM, Wolfgang Denk <wd@denx.de> wrote:
> In message <ffc2b1d40802291156o65bd167el8586288c5c07df3b@mail.gmail.com> you wrote:
> > As part of my current ongoing effort to get up to date with rc2 I will
> > produce a patch that will apply cleanly against that in a few a days.
>
> In a few days we will have at least -rc3, if not 1.3.2.
>
> > Flash memory size.
> > On all the versions till now I have cheated U-boot to believe I have a
> > 16M flash though the real flash was of sizes 32,64,128,256, and 512.
> > This suited my goals very nicely because i could have a generic binary
> > u-boot image for all my products. As cfi_flash.c grew up it started
>
> I cannot understand why this should be necessary. we've  always  been
> using the same U-Boot image no matter what the flash or RAM size was.
> Actually  this  is  a  major  design  philosophy  of  U-Boot *not* to
> hardcode memory sizes butto  automatically  deal  with  te  sizes  it
> actually finds on the board.
>
> > Currently I am adopting RC2 and is having trouble making u-boot do
> > What I want (and not the other way around).
>
> I think what you're trying to do is fundamentally broken.  Why  don't
> you  use  the  real sizes present on the hardware? Why do you want to
> lie to yourself and to your users?
>

I have more then one way to answer this question some are more
philosophical then others, But I will choose the bare hardware
approach... we "hide" some backup information on the flash. We make
sure the user can not access this hiden info by physically lifting the
flash legs (there is a programmable part between the flash and the cpu
on the bus). So though there may be a 64Mb flash the user really have
a 32Mb. It is, in fact, the flash eeprom which lies to the u-boot /
linux.
Any attempt to access these non existing address will lead to bus
fault exactly as if the flash was a 32Mb (which in many sense it is).
So, again, it is important for me to tell u-boot "go ahaed and use
CFI, but dont listen to the eeporm cuz he doesn't know what he is
talking about".

Liberty
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> ...though his invention worked superbly -- his theory was a crock  of
> sewage from beginning to end.         - Vernor Vinge, "The Peace War"
>

[U-Boot-Users] Altera Stratix II

[Brent Cook]

On Friday 29 February 2008 15:36:59 eran liberty wrote:
> Any attempt to access these non existing address will lead to bus
> fault exactly as if the flash was a 32Mb (which in many sense it is).
> So, again, it is important for me to tell u-boot "go ahaed and use
> CFI, but dont listen to the eeporm cuz he doesn't know what he is
> talking about".
>

Have you tried reprogramming the flash eeprom to say something else? I know 
I've accidentally reprogrammed DRAM SPD eeproms with different/incorrect 
data.

[U-Boot-Users] Altera Stratix II

[Michael Schwingen]

Brent Cook wrote:
> On Friday 29 February 2008 15:36:59 eran liberty wrote:
>   
>> Any attempt to access these non existing address will lead to bus
>> fault exactly as if the flash was a 32Mb (which in many sense it is).
>> So, again, it is important for me to tell u-boot "go ahaed and use
>> CFI, but dont listen to the eeporm cuz he doesn't know what he is
>> talking about".
>>
>>     
>
> Have you tried reprogramming the flash eeprom to say something else? I know 
> I've accidentally reprogrammed DRAM SPD eeproms with different/incorrect 
> data.
>   
I am quite sure you can't write to the CFI data structures in flash.

cu
Michael

[U-Boot-Users] Altera Stratix II

[Wolfgang Denk]

In message <ffc2b1d40802291336s78a050b7i780fe48b9f2671ce@mail.gmail.com> you wrote:
>
> > I think what you're trying to do is fundamentally broken.  Why  don't
> > you  use  the  real sizes present on the hardware? Why do you want to
> > lie to yourself and to your users?
> 
> I have more then one way to answer this question some are more
> philosophical then others, But I will choose the bare hardware
> approach... we "hide" some backup information on the flash. We make
> sure the user can not access this hiden info by physically lifting the
> flash legs (there is a programmable part between the flash and the cpu
> on the bus). So though there may be a 64Mb flash the user really have
> a 32Mb. It is, in fact, the flash eeprom which lies to the u-boot /
> linux.

I see.

> Any attempt to access these non existing address will lead to bus
> fault exactly as if the flash was a 32Mb (which in many sense it is).
> So, again, it is important for me to tell u-boot "go ahaed and use
> CFI, but dont listen to the eeporm cuz he doesn't know what he is
> talking about".

I understand what you are trying to do, but I think  your  conclusion
is  wrong.  The  CFI  driver was implemented to read the geometry and
size information from the flash chips; if the  chips  cannot  provide
the  correct  information  (as in your case), they are simply not CFI
conformant, and you cannot use the CFI driver.

It may be possible to modify (or cripple) the CFI  driver  to  ignore
the information provided by the flash chips, or to overwrite parts of
this  information  (you  would  have  to  overwrite at least size and
number of sectors [and eventually the start address and first  sector
offset  if  you  map the flash at a fixed end address]) - but I don't
think that makes sense.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Writing a book is like washing an elephant: there's no good place  to
begin  or  end,  and  it's  hard to keep track of what you've already
covered.

[U-Boot-Users] Altera Stratix II

[eran liberty]

Both of you (Wolfgang and Brent) Provided me with some new angle to think of...

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...

In the past I had my own flag I called CONFIG_FORCE_FLASH SIZE.
Suppose I will come with a way to cripple the CFI to work as it should
in the latest version, would you like such a feature integrated in the
u-boot for all?

Liberty

On Sat, Mar 1, 2008 at 1:55 AM, Wolfgang Denk <wd@denx.de> wrote:
> In message <ffc2b1d40802291336s78a050b7i780fe48b9f2671ce@mail.gmail.com> you wrote:
> >
> > > I think what you're trying to do is fundamentally broken.  Why  don't
> > > you  use  the  real sizes present on the hardware? Why do you want to
> > > lie to yourself and to your users?
> >
> > I have more then one way to answer this question some are more
> > philosophical then others, But I will choose the bare hardware
> > approach... we "hide" some backup information on the flash. We make
> > sure the user can not access this hiden info by physically lifting the
> > flash legs (there is a programmable part between the flash and the cpu
> > on the bus). So though there may be a 64Mb flash the user really have
> > a 32Mb. It is, in fact, the flash eeprom which lies to the u-boot /
> > linux.
>
> I see.
>
> > Any attempt to access these non existing address will lead to bus
> > fault exactly as if the flash was a 32Mb (which in many sense it is).
> > So, again, it is important for me to tell u-boot "go ahaed and use
> > CFI, but dont listen to the eeporm cuz he doesn't know what he is
> > talking about".
>
> I understand what you are trying to do, but I think  your  conclusion
> is  wrong.  The  CFI  driver was implemented to read the geometry and
> size information from the flash chips; if the  chips  cannot  provide
> the  correct  information  (as in your case), they are simply not CFI
> conformant, and you cannot use the CFI driver.
>
> It may be possible to modify (or cripple) the CFI  driver  to  ignore
> the information provided by the flash chips, or to overwrite parts of
> this  information  (you  would  have  to  overwrite at least size and
> number of sectors [and eventually the start address and first  sector
> offset  if  you  map the flash at a fixed end address]) - but I don't
> think that makes sense.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Writing a book is like washing an elephant: there's no good place  to
> begin  or  end,  and  it's  hard to keep track of what you've already
> covered.
>

[U-Boot-Users] Altera Stratix II

[David Hawkins]

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

[U-Boot-Users] MPC8349EMDS.h Why do the BAT entries use Memory coherency?

[David Hawkins]

Hi all,

I'm just reading through the MPC8349EA-MDS-PB board
start-up code to understand it, eg. the initial SRAM
in data-cache trick.

In the BAT setups in include/configs/MPC8349EMDS.h,
some of the CFG_IBAT settings include the bit setting
BATL_MEMCOHERENCE, indicating that those BAT entries
are setting the M bit in the WIMG field, where
M = memory coherence.

I'm trying to understand why that bit is set.
Here's what the documents I've looked at say:

According to the Programming Environments Manual,
and Freescale AN1809 (minimal boot sequence app note),
if the M bit is set, accesses cause the processor to
'indicate' the access via a hardware signal. No doubt
this indication is so that another processor can
maintain coherence.

The e300 core reference manual indicates that in real
addressing mode, WIMG defaults to 0011b (p4-6), and
the on p4-7 it says

   'When the M attribute is set, and the access is
    performed, the global signal is asserted to
    indicate that the access is global.'

Then on p8-2 it shows that there is an e300 core
gbl# signal that reflects the state of the M bit.
Ok, so I can see what the hardware signal is that
asserts based on the M setting.

But in an MPC8349E/EA is there anything monitoring
the gbl# signal?

Chapter 7 of the MPC8349EA reference manual has an
overview of the core, but it doesn't comment on the
gbl# signal. There is a comment on p7-27 that

'the instruction cache is not snooped, and cache
  coherency must be maintained by software'

which I would interpret as meaning there ain't nobody
listening on gbl# for instruction accesses. Then for
the data caching, there is the comment on p7-29 that

'cache coherency is enforced by on-chip bus snooping logic'

But coherency with what? What other masters are there
that the core has to be coherent with?

I can see that the coherent system bus (CSB) is a
multi-master bus, and that the core is just another
master on that bus. But I don't think any of these devices
have a cache that they need to invalidate in response to the
processor asserting its gbl# signal (p6-11 just shows
request/grant, repeat, and priority signals to the arbiter).

So does anyone have an idea why the M bit would need to be
set for the MPC8349EA BAT entries?

FYI:
  - The M-bit is set for the BAT entries for:
     DDR, PCI memory, SDRAM, stack-in-dcache, and Flash)
  - The M-bit is not set for:
     PCI I/O, IMMRs, and BCSRs
    these are cache inhibited and guarded.

Cheers,
Dave

PS. This is the first time I've looked at the startup code
of a processor with an MMU, or BATs, so if I've missed the
obvious ... be kind :)

[U-Boot-Users] MPC8349EMDS.h Why do the BAT entries use Memory coherency?

[David Hawkins]

Hi all,

Once I'd written the email on this subject to the U-Boot
list, I figured it was starting to sound like a Freescale
support request, so I submitted one too. Here's their
response:

  "Actually, snooping occurs inside MPC8349 device.
   Besides e300 core, other possible masters are:
   PCI1, PCI2, DMA, TSEC1, TSEC2, USB, Ecnryption
   engine."

So, it does sound like there are devices internal to the
MPC8349EA that are monitoring the e300 core gbl# signal,
and hence the M-bit would need to be set in the BAT
entries.

> FYI:
>   - The M-bit is set for the BAT entries for:
>      DDR, PCI memory, SDRAM, stack-in-dcache, and Flash)
>   - The M-bit is not set for:
>      PCI I/O, IMMRs, and BCSRs
>     these are cache inhibited and guarded.

And this list pretty much makes sense. The exception
would be the stack-in-dcache, since there is no external
memory associated with the stack-in-dcache trick.

Trying to understand the stack-in-dcache trick was what
what started all this ... but, I guess in that case, having
the M-Bit set in the BAT entry doesn't really matter, since
nothing is (or should be) snooping that address anyway.

Sorry for the 'noise' :)

Cheers,
Dave

[U-Boot-Users] BDI .cfg for MPC8349E/EA-MDS-PB [1/2]

[David Hawkins]

Hi all,

I've written a couple of BDI2000 .cfg files, with
register settings consistent with the latest
U-Boot source. I've tested it on both the
Freescale boards:

MPC8349E-MDS-PB:
   - MPC8349E processor (v1.x silicon)
   - DDR1 SDRAM
   - Micron Q-Flash

MPC8349EA-MDS-PB:
   - MPC8349EA processor (v3.x silicon)
   - DDR2 SDRAM
   - Spansion Flash

Wolfgang/Stefan could you place these in the
ftp://www.denx.de/pub/BDI2000, as they may be
useful to others.

I'll send the two files separately to avoid
the newsgroup file size limits.

[1/2] BDI .cfg for MPC8349E-MDS-PB

Thanks!
Dave
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mpc8349e_mds_pb.cfg
Url: http://lists.denx.de/pipermail/u-boot/attachments/20080304/09934af0/attachment.txt 

[U-Boot-Users] BDI .cfg for MPC8349E/EA-MDS-PB [2/2]

[David Hawkins]

Second .cfg file

[2/2] BDI .cfg for MPC8349EA-MDS-PB

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mpc8349ea_mds_pb.cfg
Url: http://lists.denx.de/pipermail/u-boot/attachments/20080304/637a2b8d/attachment.txt 

[U-Boot-Users] Altera Stratix II

[eran liberty]

This is starting to be me talking about my implementation, and though
I love being in the spotlight, I think its best for the rest of u-boot
mailing list that I will answer more question off line.

After I have solved it one way or the other I will simply present my
solution and will let you decide if you wish to adopt it or not.

On Sat, Mar 1, 2008 at 11:51 PM, David Hawkins <dwh@ovro.caltech.edu> wrote:
>  1. Does it really matter if the user can read the data?
>

Yes! this is our last line of defence, Super idiot proof, reserved
only for our technician coming to the site to save the day. If the
user can write to it, its no longer Super idiot proof

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

This is a valid solution, but for this FPGA needs bus logic, timing,
address parsing, etc. Till today we preferred a simple bus shortcut.

>  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?
>

FPGA logic is encrypted! if user can read / create or write the FPGA.
Then flash is the least of my problems. (while IP will certainly be
higher and my job position even more :) )

Liberty.

[U-Boot-Users] Altera Stratix II

[Wolfgang Denk]

In message <ffc2b1d40803011332s33e18e29p961b750d4621e563@mail.gmail.com> you wrote:
> 
> In the past I had my own flag I called CONFIG_FORCE_FLASH SIZE.
> Suppose I will come with a way to cripple the CFI to work as it should
> in the latest version, would you like such a feature integrated in the
> u-boot for all?

To be honest - my immediate reaction is a clear "no".

But then, if it's implemented cleanly,  doesn't  hurt others  and  is
useful to some (like you) - why not?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When a program is being  tested,  it  is  too  late  to  make  design
changes.                  -- Geoffrey James, "The Tao of Programming"