[U-Boot-Users] Can I write to flash using mw command
bilahari akkiraju
-> On my target board I have a spansion GL064M flash
device.
-> The flash base address is 0xff000000.
-> I have read the data sheet for the device and
noted down the erase and write command sequences for
the device.
-> I cannot erase, write to flash by implementing the
appropriate command sequences with mw (memory write )
command provided by u-boot that came with my sdk
(u-boot 1.1.4).
For example
For erasing sector 0xff000000 I typed the following
sector erase command sequence (as per data sheet) at
u-boot prompt
mw.b 0xff000555 0xAA
mw.b 0xff0002AA 0x55
mw.b 0xff000555 0x80
mw.b 0xff000555 0xAA
mw.b 0xff0002AA 0x55
mw.b 0xff000000 0x30
For writing to address 0xff000000 I typed the
following write command sequence (as per data sheet)
at the u-boot prompt.
mw.b 0xff000555 0xAA
mw.b 0xff0002AA 0x55
mw.b 0xff000555 0xA0
mw.b 0xff000000 0x12 ; value 0x12
mw.b 0xff000001 0x34 ; value 0x34
mw.b 0xff000000 0xF0 ; reset (I do it as u-boot
driver cfi_flash.c does it )
-> After doing all this , when I do a memory dump
using md.b 0xff000000 , to my frustration I see that
nothing at all has happend to the flash.
I am sure I am missing something small or may be I am
doing a completely wrong thing. I am more of a
computer science guy and new to chip programming. Any
suggestions, ideas or comments would be very helpful.
Thanks you all
Bilahari
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
U-Boot-Users mailing list
U-Boot...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Ben Warren
> Hello,
>
> -> On my target board I have a spansion GL064M flash
> device.
We use this chip too and it works fine using U-boot's CFI. What is your
sector layout (uniform, bottom boot or top boot)? The additional
markings on the chip will tell you.
> -> I cannot erase, write to flash by implementing the
> appropriate command sequences with mw (memory write )
> command provided by u-boot that came with my sdk
> (u-boot 1.1.4).
>
Do the U-boot 'protect' and 'erase commands work? If so, why torture
yourself with low-level access? If not, you have a configuration or
hardware issue which we can explore.
regards,
Ben
Wolfgang Denk
>
> -> On my target board I have a spansion GL064M flash
> device.
How is it attached? As a 8 bit device?
> -> I cannot erase, write to flash by implementing the
> appropriate command sequences with mw (memory write )
Are you sure you use ther correct addresses and commands?
> For erasing sector 0xff000000 I typed the following
> sector erase command sequence (as per data sheet) at
> u-boot prompt
>
> mw.b 0xff000555 0xAA
> mw.b 0xff0002AA 0x55
> mw.b 0xff000555 0x80
> mw.b 0xff000555 0xAA
> mw.b 0xff0002AA 0x55
> mw.b 0xff000000 0x30
Are you really accessing an 8 bit device?
> I am sure I am missing something small or may be I am
> doing a completely wrong thing. I am more of a
Also check if your memory controller is set up correctly...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
All repairs tend to destroy the structure, to increase the entropy
and disorder of the system. Less and less effort is spent on fixing
original design flaws; more and more is spent on fixing flaws intro-
duced by earlier fixes. - Fred Brooks, "The Mythical Man Month"
Ben Warren
> Hi Ben,
>
> Stuff works fine using U-boot's cfi. I can protect
> and erase using appropriate commands (protect and
> erase ) provided by the u-boot. I do not know if
> there is a u-boot command to write to flash.
>
> My flinfo command shows this :
>
> bank # 1: CFI conformant FLASH (32 x 16) Size: 16 MB
> in 128 Sectors
> Erase timeout 16384 ms, write timeout 0 ms, buffer
> write timeout 4096 ms, buffe2
> Sector Start Addresses:
>
> FF000000 FF020000 FF040000 FF060000
> FF080000
> FF0A0000 FF0C0000 FF0E0000 FF100000
> FF120000
This is odd. The GL064 is either 32x8 or 16x16, and has either 128x64kB
or 127x64kB + 8x8kB sector layout. Yours appears to have 128 uniform
sectors of 128kB each. Either you're not using the part you think you
are or my documentation is out of date.
> I am trying low level access because I am writing my
> own flash utilities which are independent of U-boot
> and hence have to directly deal with right command
> sequences.
>
If your utilities are independent of U-boot then your request is
off-topic. Since the CFI driver is working, you're missing something in
the sequence of commands being written to flash. I've done it before
manually via BDI-2000, and although the Spansion documentation is
cryptic, it's technically correct. Sorry I can't help more right now
but work beckons...
Also, please copy the U-boot mailing list when corresponding.
regards,
Ben
Wolfgang Denk
> On Thu, 2006-10-05 at 14:03 -0700, bilahari akkiraju wrote:
> > Stuff works fine using U-boot's cfi. I can protect
> > and erase using appropriate commands (protect and
> > erase ) provided by the u-boot. I do not know if
> > there is a u-boot command to write to flash.
RTFM: http://www.denx.de/wiki/view/DULG/UBootCmdGroupFlash
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"I say we take off; nuke the site from orbit. It's the only way to be
sure." - Corporal Hicks, in "Aliens"
bilahari akkiraju
I did
protect off all
I have tried the following command sequences but didnt
succeed in my objective of writing to and erasing
first sector on flash.
WRITE COMMAND SEQUENCE:
mw ff000555 00AA00AA
mw ff0002AA 00550055
mw ff000555 00A000A0
mw ff000000 12345678
SECTOR ERASE COMMAND SEQUENCE:
mw ff000555 00AA00AA
mw ff0002AA 00550055
mw ff000555 00800080
mw ff000555 00AA00AA
mw ff0002AA 00550055
mw ff000000 00300030
Note: I tried mw.b, mw.w, mw.l with appropriate data
but didnt succeed.
In first place is it possible to write to AMD flash
manually like this or shud it be done only
programatically. Any one has tried writing to flash
this way before ( I could write to Intel strata flash
this way).
I walked through u-boot code for cfi_flash.c and
flash_write() function that is called when cp (copy)
command is invoked, the code does the same thing, the
only extra thing it does is it polls on data register
bits for a certain amount of time (flash erase, write
timeout intervals) and also does a reset to bring back
device to read array mode
mw.w ff000000 00F0 ; reset cmd
I have a ppc 8343 processor on board. I am wondering
if U-boot that came with my target board has
configuration that is preventing me to write to flash
(but cp commands works fine with flash). Any one who
has same spansion flash chip s29GL064M can try it, I
cannot figure out the missing link in the chain, any
advise, comments, suggestion will be of great help
Thanks,
Bilahari
--- Wolfgang Denk <w...@denx.de> wrote:
> In message
>
<2006100522282...@web33206.mail.mud.yahoo.com>
> you wrote:
> >
> > -> I read my board's spec and found out that I
> have
> > two spansion s29GL064M devices on my board whose
> data
> > bus is 16-bit wide and address bus is 32-bit wide.
> > They are attached as 16-bit devices.
>
> Then your command sequence was wrong.
>
> > -> I looked at the data sheet of the spansion
> > s29GL64M
> > and I am sure I am using the right command
> sequences
> > (x16 Mode commands) for erase and program.
>
> No. In 16 bit mode addresses get shifted by one bit,
> and your command
> word must address both chips, i. e. instead of
>
> mw.b 0xff000555 0xAA
>
> you need
>
> mw FF000AAA 00AA00AA
>
> > -> How can I check if my memory controller is
> > properly configured or not.
>
> By carefully studying the hardware documentation,
> processor User's
> manual, chip documentation, etc. Then perform a code
> review.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime
> Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80
> Email: w...@denx.de
> Do you suppose the reason the ends of the `Intel
> Inside' logo don't
> match up is that it was drawn on a Pentium?
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------------------------------------------------------------------
Wolfgang Denk
For this to work, you need working flash driver support in U-Boot.
And *if* you have working flash driver support, I wonder why you need
to do such things:
> WRITE COMMAND SEQUENCE:
>
> mw ff000555 00AA00AA
> mw ff0002AA 00550055
> mw ff000555 00A000A0
> mw ff000000 12345678
Please explain which flash driver you are using (cfi driver???), and
what the exact problem is you are trying to solve.
> timeout intervals) and also does a reset to bring back
> device to read array mode
>
> mw.w ff000000 00F0 ; reset cmd
In a configuration with 2 x 16 bit devices that should be 00F000F0.
> I have a ppc 8343 processor on board. I am wondering
> if U-boot that came with my target board has
> configuration that is preventing me to write to flash
> (but cp commands works fine with flash). Any one who
This statement makes no sense to me. If cp to flash works fine, then
obviously writing to flash is working fine, because this is what cp
does when the target address points to flash memory - programming
data to flash.
Explain what you want to do, and why, and what is not working - it
sounds as if you have a perfectly working CFI driver on your board,
so what is the problem?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Virtual" means never knowing where your next byte is coming from.
Jerry Van Baren
You can write to flash by hand, if you do it right. It is a good way to
learn how to do it programatically.
I believe the addresses you are using are wrong because your example
shows two 16 bit chips to make up your 32 bits of data. This means that
the LSB address line becomes a chip select between the two chips
(logically, if not physically) and is not seen by the chips themselves.
The result is the chips see the addresses shifted right 1 bit.
Equivalently, you have shift your addresses left by 1 bit to compensate.
Chip address: xxx555 => 0101 0101 0101
Your address: xxxAAA => 101 0101 0101x (x is the dropped bit)
Or, regrouped: 1010 1010 101o
(filling in 'o' for the "unused" LSB)
Chip address: xxx2AA => 0010 1010 1010
Your address: xxx554 => 0001 0101 010x
Or, regrouped: 0001 0101 010o
(filling in 'o' for the "unused" LSB)
Try the following, I suspect it will work.
WRITE COMMAND SEQUENCE:
mw ff000AAA 00AA00AA
mw ff000554 00550055
mw ff000AAA 00A000A0
mw ff000000 12345678
The standard flash driver figures this all out for you and thus works.
gvb
bilahari
Took your advice on flash addresses I should put
into my command sequences with my current flash
configuration (2 16-bit spansion s29GL064M chips
interleaved to form 32-bit flash system). You pointed me
to the right direction, thanks. Although I couldnt
succeed in manual manipulation of flash, I am able to
do it programatically (I downloaded a free low level driver
provided by spansion and used it with my code). And it
works fine, just like u-boot driver (cfi_flash.c). For anyone
interested here is the link
http://www.spansion.com/support/drivers_software/index.html
But one thing that doesnt work with my code and also
with u-boot is that if I want to write two different
values to the same flash locationconsecutively
( for example when I try to write 0x12 to flash address
0xff000000 and then write 0x34 to same flash address,
u-boot gives me a message "flash not erased".
My driver makes the program simply loop forever in a status
register polling loop, I guess).
Is it something natural with flash programming ?.
Should I always erase the whole sector before I re-program
a location ? (doesnt sound like a good approach to me),
is it not possible to write consecutively as with
the conventional memory?
Thanks for the help and the directions
Bilahari
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Ben Warren
On Wed, 2006-10-11 at 22:17 +0000, bilahari wrote:
> But one thing that doesnt work with my code and also
> with u-boot is that if I want to write two different
> values to the same flash locationconsecutively
> ( for example when I try to write 0x12 to flash address
> 0xff000000 and then write 0x34 to same flash address,
> u-boot gives me a message "flash not erased".
> My driver makes the program simply loop forever in a status
> register polling loop, I guess).
>
> Is it something natural with flash programming ?.
> Should I always erase the whole sector before I re-program
> a location ? (doesnt sound like a good approach to me),
> is it not possible to write consecutively as with
> the conventional memory?
Flash can't be accessed like the RAM you're thinking of. You can only
change a bit state from 1 to 0 (That's why after erasing a sector you'll
see that the contents are all 'ffffffff'). For all intents and
purposes, once you write to a location in flash, it's 'read-only' until
you erase the whole sector again. Also, keep in mind that flash devices
have a limited number of erase cycles before performance becomes
unreliable. A common value is 100000 cycles, although there are devices
with more and less than this number. In general, use Flash to store
information that will change infrequently.
regards,
Ben
Tolunay Orkun
> Hi, Jerry,
>
> Took your advice on flash addresses I should put
> into my command sequences with my current flash
> configuration (2 16-bit spansion s29GL064M chips
> interleaved to form 32-bit flash system). You pointed me
> to the right direction, thanks. Although I couldnt
I guess Jerry guessed right how your flash chips are interfaced to the
CPU bus since you did not disclose the complete information before.
Without this information you cannot program the flash correctly.
> But one thing that doesnt work with my code and also
> with u-boot is that if I want to write two different
> values to the same flash locationconsecutively
> ( for example when I try to write 0x12 to flash address
> 0xff000000 and then write 0x34 to same flash address,
> u-boot gives me a message "flash not erased".
> My driver makes the program simply loop forever in a status
> register polling loop, I guess).
>
> Is it something natural with flash programming ?.
Yes. With NOR flash devices erasing turns flash to all 1s. By write you
can turn 1s to 0s. But you cannot turn 0s to 1s without doing an erase
of the erase unit (block/sector).
> Should I always erase the whole sector before I re-program
> a location ? (doesnt sound like a good approach to me),
It does not sound that you have experience in embedded devices in
particular with flash parts. I suggest you do some reading to
familiarize yourself with the devices on your board. BTW, all this is
really not U-Boot related and off topic on the list.
> is it not possible to write consecutively as with
> the conventional memory?
It works as long as do not try to turn 1 bits to 0.
Best regards,
Tolunay
Tolunay Orkun
>> is it not possible to write consecutively as with
>> the conventional memory?
>
> It works as long as do not try to turn 1 bits to 0.
Correction: as long as you do not try to turn 0 bits to 1.
Jerry Van Baren
> Tolunay Orkun wrote:
>>> is it not possible to write consecutively as with
>>> the conventional memory?
>> It works as long as do not try to turn 1 bits to 0.
>
> Correction: as long as you do not try to turn 0 bits to 1.
>
> Tolunay
Back when I was a kid, all we had were ones. To make a zero we had to
subtract two ones. To change a zero to a one, we had to divide by zero
to get an infinite number and then divide it by itself again to get a
one... its no wonder flash wears out!
gvb ;-)
Wolfgang Denk
>
> Back when I was a kid, all we had were ones. To make a zero we had to
They changed it to zeros later, because a zero is much more powerful.
For example, leading zeros can be very powerful, expecially when you
employ them in the management of big companies. [BTW: that's the
difference between commercial and scientific notation: scientists
tend to suppress leading zeros.] And, to quote an ancient usenet
posting (sorry, the exact source is unknown to me):
Zero is an enigmatic value. It can mean success (fclose) or failure
(scanf). It can mean black or white. It can mean no permissions
(chmod) or all permissions (umask). It can mean now (setjmp) or later
(atexit). It can mean the beginning (lseek) or the end (read). It can
mean myself (getpgrp) or child (fork). It can mean all (kill's 1st
argument) or nothing (kill's 2nd argument). It can mean `default'
(SIG_IGN) or `I don't care' (waitpid) or `try to guess' (strtol).
Indeed 0 lets you talk to God (setuid).
Verily is 0 all things to all people.
SCNR :-)
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
As usual, this being a 1.3.x release, I haven't even compiled this
kernel yet. So if it works, you should be doubly impressed.
- Linus Torvalds in <1995061815...@keos.cs.Helsinki.FI>
Ben Warren
> In message <452E2DD0...@smiths-aerospace.com> you wrote:
> >
> > Back when I was a kid, all we had were ones. To make a zero we had to
>
> They changed it to zeros later, because a zero is much more powerful.
> For example, leading zeros can be very powerful, expecially when you
> employ them in the management of big companies. [BTW: that's the
> difference between commercial and scientific notation: scientists
> tend to suppress leading zeros.] And, to quote an ancient usenet
> posting (sorry, the exact source is unknown to me):
>
> Zero is an enigmatic value. It can mean success (fclose) or failure
> (scanf). It can mean black or white. It can mean no permissions
> (chmod) or all permissions (umask). It can mean now (setjmp) or later
> (atexit). It can mean the beginning (lseek) or the end (read). It can
> mean myself (getpgrp) or child (fork). It can mean all (kill's 1st
> argument) or nothing (kill's 2nd argument). It can mean `default'
> (SIG_IGN) or `I don't care' (waitpid) or `try to guess' (strtol).
> Indeed 0 lets you talk to God (setuid).
> Verily is 0 all things to all people.
Obligatory follow-on from a long-forgotten source:
"The decline of the Roman Empire can be traced to the fact that, lacking
zero, they were unable to return from their C programs"
bilahari
Ben Warren <bwarren <at> qstreams.com> writes:
>
> On Thu, 2006-10-12 at 15:11 +0200, Wolfgang Denk wrote:
Thank you all , learned the The Transcedental Truth about zero,
From spansion documentation :-
<<
When Flash memory is erased, all the bits in the
erased area are set to a logical “1” (high signal level).
Programming selectively changes bits to a logical
“0” (Low signal level). Flash memory is traditionally
programmed a single byte or word at a time and erased one
sector at a time. Only an erase operation can return a “0”
back to a “1”(erased) state.
For Floating-Gate technology,
it is possible to re-program (or write over) a byte
or word that has been previously programmed without
first erasing the byte or word (as long as no attempt is
made to program a “0” to a “1”). This re-programming of byte
or word locations can be used to incrementally program
individual bits to “0.” This incremental programming is
useful to track the progress in multi-step programming
schemes such as those used in a Flash File System.