[U-Boot-Users] u-boot locking ?

[alfred hitch]

Hi,

just to add to my last post, the u-boot seems to be hanging in the function:
flash_get_size

????
Code comments in header for function says:
*
 * The following code cannot be run from FLASH!
 *
 */

Any option I am missing which could be causing it to screw up ?

My compilation is simple:
make clean; make ixdp425_config; make

(Before doing this, u-boot was working just fine for us )

Anyone has already tried marking blocks as locked on J3 Flash ? and can help ?

Regards,
Alfred

On 1/9/06, alfred hitch <alfred.hitch at gmail.com> wrote:
> Hi Wolfgang,
>
> Thanks for your mails, u-boot in mycase also I observed wasnt being
> called with hardware protection on.
>
> I will appreciate if someone can help me with following questions:
> 1) I enabled these 3 defines in the include/configs/ixdp425.h
> #define CFG_FLASH_PROTECTION
> #define CFG_FLASH_CFI_DRIVER
> #define CFG_FLASH_CFI
>
> From what appeared logical (and compilation needs) to me.
> But, when I am booting the system now, its hanging after displaying
> the RAM configuration.
>
> I have just begun to trace down on what could be wrong,but it looks
> from initial traces to be in flash_init.
>
> Anything I am missing / doing wrong ??
>
> 2)  Read somewhere on net, that by deault all sectors are locked after
> reboo t ? true ? does J3 Intel strata flash does it also automatically
> ?
>
> 3) Remember to do so after relocation to RAM. :: Can you please help
> me to correct place, code path / function to do so ? I am very new to
> u-boot.
>
> Regards,
> Alfred
>
>
> On 1/8/06, Wolfgang Denk <wd at denx.de> wrote:
> > In message <29f916510601080721vd20b512u819ee9bce7ad1408 at mail.gmail.com> you wrote:
> > >
> > > 1) Does u-boot lock the block on which it resides by default ?
> >
> > Not by default, but you can inplement in your flah  driver  whichever
> > features you like.
> >
> > > I mean the sector /erase block on which u-boot is there, it will be
> > > locked using the block lock  bit by default ?
> >
> > Remember that only few flash chips provide such hardware locking, and
> > that some boards implement even other ways  of  write  protection  of
> > parts of or of the whole flash device.
> >
> > > 2) The flash content changing has to work in block sizes erase -
> > > modify - write cyecles only ??
> >
> > No. You can write single bytes (as long as you are only changing  '1'
> > bits to '0').
> >
> > > Reason for all this is that we have few boards on which u-boot is
> > > getting corrupted (on flash image corruption itself).
> > > And so am wondering even if its a noise issue, how can it first cause
> > > an unlock of sector before write.
> >
> > Normally the flash is  not  hardare  write  protected,  and  if  your
> > hardware designer used flash chips which can be corrupted for example
> > by  just writing arbitrary data to a sequential address range you may
> > easily see such corruption. There is a very good reason why AMD flash
> > chips require a specific programming sequence which must  be  written
> > in a certain sequence to certain non-consequitive addresses.
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> > --
> > Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> > PoB = "Prisoner of Bill" -- those held captive, unwillingly or other-
> > wise, by the contemptible Microsoft monopoly.
> >          -- Tom Christiansen in <6abo45$3lc$2 at csnews.cs.colorado.edu>
> >
>