[U-Boot-Users] Suggestion on flash init

[U-Boot-Users] Suggestion on flash init

[Wang Jian]

Hi,

After reading many board/*/flash.c and writing customer board driver for
one of my customer, I think the current flash interface can be improved.

I suggest adding a subdir $(TOPDIR)/include/flash/ and putting flash
chip information here. When you use some kinds of flash chips, just
include relevant header files.

If we go further, many information in $(TOPDIR)/include/flash.h can be
put into these header files.

And, even flash operation (non-CFI) sample code can be put into
$(TOPDIR)/contrib/flash/.

The following is an example of AMD Spansion S29AL016M chip.

--snip--
#ifndef _FLASH_S29AL016M_H_ 
#define _FLASH_S29AL016M_H_ 
        
#define FLASH_S29AL016M_T_SECTORS       35
#define FLASH_S29AL016M_B_SECTORS       35
        
#define FLASH_S29AL016M_T_SIZE          0x00200000
#define FLASH_S29AL016M_B_SIZE          0x00200000


int FLASH_S29AL016M_T_BYTE_SA[] = {
        0x000000, 0x010000, 0x020000, 0x030000,
        0x040000, 0x050000, 0x060000, 0x070000,
        0x080000, 0x090000, 0x0A0000, 0x0B0000,
        0x0C0000, 0x0D0000, 0x0E0000, 0x0F0000,
        0x100000, 0x110000, 0x120000, 0x130000,
        0x140000, 0x150000, 0x160000, 0x170000,
        0x180000, 0x190000, 0x1A0000, 0x1B0000,
        0x1C0000, 0x1D0000, 0x1E0000, 0x1F0000,
        0x1F8000, 0x1FA000, 0x1C0000
};

int FLASH_S29AL016M_T_WORD_SA[] = {
        0x000000, 0x008000, 0x010000, 0x018000,
        0x020000, 0x028000, 0x030000, 0x038000,
        0x040000, 0x048000, 0x050000, 0x058000,
        0x060000, 0x068000, 0x070000, 0x078000,
        0x080000, 0x088000, 0x090000, 0x098000,
        0x0A0000, 0x0A8000, 0x0B0000, 0x0B8000,
        0x0C0000, 0x0C8000, 0x0D0000, 0x0D8000,
        0x0E0000, 0x0E8000, 0x0F0000, 0x0F8000,
        0x0FC000, 0x0FD000, 0x0FE000
};

int FLASH_S29AL016M_B_BYTE_SA[] = {
        0x000000, 0x004000, 0x006000, 0x008000,
        0x010000, 0x020000, 0x030000, 0x040000,
        0x050000, 0x060000, 0x070000, 0x080000,
        0x090000, 0x0A0000, 0x0B0000, 0x0C0000,
        0x0D0000, 0x0E0000, 0x0F0000, 0x100000,
        0x110000, 0x120000, 0x130000, 0x140000,
        0x150000, 0x160000, 0x170000, 0x180000,
        0x190000, 0x1A0000, 0x1B0000, 0x1C0000,
        0x1D0000, 0x1E0000, 0x1F0000
};

int FLASH_S29AL016M_B_WORD_SA[] = {
        0x000000, 0x002000, 0x003000, 0x004000,
        0x008000, 0x010000, 0x018000, 0x020000,
        0x028000, 0x030000, 0x038000, 0x040000,
        0x048000, 0x050000, 0x058000, 0x060000,
        0x068000, 0x070000, 0x078000, 0x080000,
        0x088000, 0x090000, 0x098000, 0x0A0000,
        0x0A8000, 0x0B0000, 0x0B8000, 0x0C0000,
        0x0C8000, 0x0D0000, 0x0D8000, 0x0E0000,
        0x0E8000, 0x0F0000, 0x0F8000
};

#endif
--snip--


In flash_get_size()
--snip--
        switch (device) {
        case BYTEME(AMD_ID_S29AL016M_T):
                info->flash_id += FLASH_S29AL016M_T;
                info->sector_count = FLASH_S29AL016M_T_SECTORS;
                info->size = FLASH_S29AL016M_T_SIZE;
                break;

        case BYTEME(AMD_ID_S29AL016M_B):
                info->flash_id += FLASH_S29AL016M_B;
                info->sector_count = FLASH_S29AL016M_B_SECTORS;
                info->size = FLASH_S29AL016M_B_SIZE;
                break;
--snip--


In flash_get_offset()
--snip--
        switch (info->flash_id & FLASH_TYPEMASK) {
        case FLASH_S29AL016M_T:
                for (i = 0; i < info->sector_count; i++) {
                        info->start[i] = base + FLASH_S29AL016M_T_BYTE_SA[i];
                }
                break;
        case FLASH_S29AL016M_B:
                for (i = 0; i < info->sector_count; i++) {
                        info->start[i] = base + FLASH_S29AL016M_B_BYTE_SA[i];
                }
                break;
--snip--

-- 
  lark

[U-Boot-Users] Suggestion on flash init

[Wolfgang Denk]

In message <20051225120433.F3F6.LARK@linux.net.cn> you wrote:
> 
> After reading many board/*/flash.c and writing customer board driver for
> one of my customer, I think the current flash interface can be improved.

Did you have a look at the cfi_flash  driver?  This  is  supposed  to
replace  the  custom  board/*/flash.c  in  most  cses (i. e. whenever
memory footprint requirements are not too limiting).

> I suggest adding a subdir $(TOPDIR)/include/flash/ and putting flash
> chip information here. When you use some kinds of flash chips, just
> include relevant header files.

I think we should use the cfi_driver instead.

And BTW - a comment on the suggested code:

> If we go further, many information in $(TOPDIR)/include/flash.h can be
> put into these header files.
...
> The following is an example of AMD Spansion S29AL016M chip.
...
> int FLASH_S29AL016M_T_BYTE_SA[] = {
>         0x000000, 0x010000, 0x020000, 0x030000,
>         0x040000, 0x050000, 0x060000, 0x070000,
...

All-capital-names should be reserved for preprocessor  variables.  It
is not acceptable to use these for other variables or function names.
It  is  also not a good idea to have such initializations in a header
file which might get included more than once.


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
Bradley's Bromide: If computers get too  powerful,  we  can  organize
them into a committee - that will do them in.

[U-Boot-Users] Suggestion on flash init

[Wang Jian]

Hi Wolfgang Denk,


On Sun, 25 Dec 2005 11:19:20 +0100, Wolfgang Denk <wd@denx.de> wrote:

> In message <20051225120433.F3F6.LARK@linux.net.cn> you wrote:
> > 
> > After reading many board/*/flash.c and writing customer board driver for
> > one of my customer, I think the current flash interface can be improved.
> 
> Did you have a look at the cfi_flash  driver?  This  is  supposed  to
> replace  the  custom  board/*/flash.c  in  most  cses (i. e. whenever
> memory footprint requirements are not too limiting).

I have tested cfi_flash.c for a while. Unfortuanately, it fails for
Spansion S29AL016M. The chip can be recognized, chip information is all
correct, but the erase and write routines fail.

The symptom is erase and write routine complete and seem to succeed, but
content remains unchanged.

The datasheet I download from Spansion (S29AL016M_00_A5_E.pdf) says:

? CFI (Common Flash Interface) compliant: allows host system to
   identify and accommodate multiple flash devices

Carefully read cfi_flash.c and datasheet, I think S29AL016M doesn't
support the cfi_flash.c's command sequence for erasing and writing.

> 
> > I suggest adding a subdir $(TOPDIR)/include/flash/ and putting flash
> > chip information here. When you use some kinds of flash chips, just
> > include relevant header files.
> 
> I think we should use the cfi_driver instead.
> 
> And BTW - a comment on the suggested code:
> 
> > If we go further, many information in $(TOPDIR)/include/flash.h can be
> > put into these header files.
> ...
> > The following is an example of AMD Spansion S29AL016M chip.
> ...
> > int FLASH_S29AL016M_T_BYTE_SA[] = {
> >         0x000000, 0x010000, 0x020000, 0x030000,
> >         0x040000, 0x050000, 0x060000, 0x070000,
> ...
> 
> All-capital-names should be reserved for preprocessor  variables.  It
> is not acceptable to use these for other variables or function names.
> It  is  also not a good idea to have such initializations in a header
> file which might get included more than once.
> 

The code I give are JUST example, so uppper or lower case is not a
problem in this sense.

I did worry about such initializations in header file, but given the
fact that only flash.c will include it, I think it is not a real problem.
And even it is included by multiple files, we can make these variables
static. Or we can use better solution, but the idea itself is still
reasonable.



-- 
  lark

[U-Boot-Users] Suggestion on flash init

[Wolfgang Denk]

In message <20051225190658.F3F9.LARK@linux.net.cn> you wrote:
> 
> I have tested cfi_flash.c for a while. Unfortuanately, it fails for
> Spansion S29AL016M. The chip can be recognized, chip information is all
> correct, but the erase and write routines fail.

Then please (lets) fix the problem instead of inventing the wheel again.

> And even it is included by multiple files, we can make these variables
> static. Or we can use better solution, but the idea itself is still

That's even worse as it would silently create multiple copies of  the
same data - which is just a waste of precious memory.

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
It is dangerous to be sincere unless you are also stupid.
                                                - George Bernard Shaw

[U-Boot-Users] Suggestion on flash init

[Wang Jian]

Hi Wolfgang Denk,


On Sun, 25 Dec 2005 17:34:49 +0100, Wolfgang Denk <wd@denx.de> wrote:

> In message <20051225190658.F3F9.LARK@linux.net.cn> you wrote:
> > 
> > I have tested cfi_flash.c for a while. Unfortuanately, it fails for
> > Spansion S29AL016M. The chip can be recognized, chip information is all
> > correct, but the erase and write routines fail.
> 
> Then please (lets) fix the problem instead of inventing the wheel again.

After a bad sleep, I read the manual again. This time, I find the cfi_flash.c
DOES do as what manual says. I will set some debug information and find
what happend. Stay tune.



-- 
  lark

[U-Boot-Users] Suggestion on flash init

[Wang Jian]

Hi Denk,

Me again.

In my situation, S29AL016M works in x8 mode, which has different command
sequence from in x16 mode.

The following are from datasheet.

Providing
vu_char *addr = (vu_char *) info->start[sect];

x16 mode sector erase
addr[0x555] = 0xAA;
addr[0x2AA] = 0x55;
addr[0x555] = 0x80;
addr[0x555] = 0xAA;
addr[0x2AA] = 0x55;
addr[0x000] = 0x30;
udelay(50); // at least 50 us before polling for status

x16 mode program
addr[0x555] = 0xAA;
addr[0x2AA] = 0x55;
addr[0x555] = 0xA0;
addr[offset] = data;

x8 mode sector erase
addr[0xAAA] = 0xAA;
addr[0x555] = 0x55;
addr[0xAAA] = 0x80;
addr[0xAAA] = 0xAA;
addr[0x555] = 0x55;
addr[0x000] = 0x30;
udelay(50); // at least 50 us before polling for status

x8 mode program
addr[0xAAA] = 0xAA;
addr[0x555] = 0x55;
addr[0xAAA] = 0xA0;
addr[offset] = data;

I have little knowledge about other flash chips, so it is not easy for
me to write clean patch for cfi_flash.c, although I want to.

Regards

On Mon, 26 Dec 2005 09:49:10 +0800, Wang Jian <lark@linux.net.cn> wrote:

> Hi Wolfgang Denk,
> 
> 
> On Sun, 25 Dec 2005 17:34:49 +0100, Wolfgang Denk <wd@denx.de> wrote:
> 
> > In message <20051225190658.F3F9.LARK@linux.net.cn> you wrote:
> > > 
> > > I have tested cfi_flash.c for a while. Unfortuanately, it fails for
> > > Spansion S29AL016M. The chip can be recognized, chip information is all
> > > correct, but the erase and write routines fail.
> > 
> > Then please (lets) fix the problem instead of inventing the wheel again.
> 
> After a bad sleep, I read the manual again. This time, I find the cfi_flash.c
> DOES do as what manual says. I will set some debug information and find
> what happend. Stay tune.
> 

-- 
  lark

[U-Boot-Users] Suggestion on flash init

[Wolfgang Denk]

In message <20060103205317.0711.LARK@linux.net.cn> you wrote:
> 
> In my situation, S29AL016M works in x8 mode, which has different command
> sequence from in x16 mode.

If you look closer it is not so different at all.

> x16 mode sector erase
> addr[0x555] = 0xAA;
> addr[0x2AA] = 0x55;
> addr[0x555] = 0x80;
> addr[0x555] = 0xAA;
> addr[0x2AA] = 0x55;
> addr[0x000] = 0x30;
...
> x8 mode sector erase
> addr[0xAAA] = 0xAA;
> addr[0x555] = 0x55;
> addr[0xAAA] = 0x80;
> addr[0xAAA] = 0xAA;
> addr[0x555] = 0x55;
> addr[0x000] = 0x30;

0x555 = 0xAAA >> 1
0x2AA = 0x555 >> 1

> I have little knowledge about other flash chips, so it is not easy for
> me to write clean patch for cfi_flash.c, although I want to.

The code is actually the very same,  just  taking  into  account  the
different addressing mode.

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
Another Armenia, Belgium ... the weak innocents who always seem to be
located on a natural invasion route.
	-- Kirk, "Errand of Mercy", stardate 3198.4

[U-Boot-Users] Suggestion on flash init

[Wang Jian]

Hi Wolfgang Denk,


On Tue, 03 Jan 2006 15:08:42 +0100, Wolfgang Denk <wd@denx.de> wrote:

> In message <20060103205317.0711.LARK@linux.net.cn> you wrote:
> > 
> > In my situation, S29AL016M works in x8 mode, which has different command
> > sequence from in x16 mode.
> 
> If you look closer it is not so different at all.
> 
> > x16 mode sector erase
> > addr[0x555] = 0xAA;
> > addr[0x2AA] = 0x55;
> > addr[0x555] = 0x80;
> > addr[0x555] = 0xAA;
> > addr[0x2AA] = 0x55;
> > addr[0x000] = 0x30;
> ...
> > x8 mode sector erase
> > addr[0xAAA] = 0xAA;
> > addr[0x555] = 0x55;
> > addr[0xAAA] = 0x80;
> > addr[0xAAA] = 0xAA;
> > addr[0x555] = 0x55;
> > addr[0x000] = 0x30;
> 
> 0x555 = 0xAAA >> 1
> 0x2AA = 0x555 >> 1
> 
> > I have little knowledge about other flash chips, so it is not easy for
> > me to write clean patch for cfi_flash.c, although I want to.
> 
> The code is actually the very same,  just  taking  into  account  the
> different addressing mode.
> 

I am not sure if other kind of AMD flash chips use such x8/x16 command
sequence. I am afraid that I will fix one thing and break other things.


-- 
  lark

[U-Boot-Users] Suggestion on flash init

[Wolfgang Denk]

In message <20060103232431.EB1F.LARK@linux.net.cn> you wrote:
> 
> I am not sure if other kind of AMD flash chips use such x8/x16 command
> sequence. I am afraid that I will fix one thing and break other things.

They all do. At least all I can remember.

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
Peace was the way.
	-- Kirk, "The City on the Edge of Forever", stardate unknown

[U-Boot-Users] Suggestion on flash init

[Tolunay Orkun]

Wang Jian wrote:
> Hi Wolfgang Denk,
> 
> 
> On Sun, 25 Dec 2005 17:34:49 +0100, Wolfgang Denk <wd@denx.de> wrote:
> 
> 
>>In message <20051225190658.F3F9.LARK@linux.net.cn> you wrote:
>>
>>>I have tested cfi_flash.c for a while. Unfortuanately, it fails for
>>>Spansion S29AL016M. The chip can be recognized, chip information is all
>>>correct, but the erase and write routines fail.
>>
>>Then please (lets) fix the problem instead of inventing the wheel again.
> 
> 
> After a bad sleep, I read the manual again. This time, I find the cfi_flash.c
> DOES do as what manual says. I will set some debug information and find
> what happend. Stay tune.
> 
> 
> 

You might want to check list archives regarding cfi_flash.c and the a 
number of patches that are created over the past year that is *still* 
pending to be incorporated to the mainline.

And if you check the mailing list archives you might find that Spansion 
chip (most probably) auto locks all sectors when powered up so you will 
need to issue unlock sequence before write/erase can succeed. There has 
been some spirited discussions on this and Wolfgang as a U-Boot project 
leader had explained the way he wants the issue addressed.

Wolfgang, when can we expect the pull-up of patches on the cfi_flash.c 
driver? I am personally holding up for existing patches to go through 
before I work on new patches.

Best regards,
Tolunay

[U-Boot-Users] Suggestion on flash init

[Wolfgang Denk]

Dear Tolunay,

in message <43BC4CD4.9020308@orkun.us> you wrote:
>
> Wolfgang, when can we expect the pull-up of patches on the cfi_flash.c 
> driver? I am personally holding up for existing patches to go through 

Well, in the last two months most of my time has been  sucked  up  by
the  (long  delayed)  release  of  ELDK  4.0  (and  by  a little Xmas
vacation :-).

Keep your finger's crossed, and tonight's ELDK build  might  be  what
we'll  release  as 4.0; the files in the CVS have already been tagged
as 4.0. If no new problems show up, this should enable  me  to  spend
some more time on U-Boot again.

> before I work on new patches.

Ummm... if you use git, you can and should make yourself  independent
of  my  patch  backlog. Actually if you spend the effort to go though
the list of cfi_flash driver related  patches  and  come  up  with  a
(somewhat  tested)  summary  patch  (or branch) that would be a great
help. We could do the same  like  with  the  NAND  code:  add  it  as
#testing-CFI branch, and if nobody complains I will merge it a little
later.

*All* feedback I receive for patches  (like  messages  saying  "added
patches X, Y, and Z, works for me, here ... is the URL of my git repo
where you can pull from) is welcome and helps to accelerate things.

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
The existence of god implies a violation of causality.

[U-Boot-Users] Suggestion on flash init

[Nuno João (Ext_NBS)]

	I am using the CFI driver (as it is in u-boot 1.1.3) with Spansion
	flash chips (S29GL512N11xxx: 2 x 16 bit chips, 32 bit port). I had
	no problems; I can do all the usual operations.

	My config is:

#define CFG_FLASH_BASE          CFG_FLASH_MEM_BASE

#define CFG_MAX_FLASH_BANKS     1       /* number of banks */
#define CFG_MAX_FLASH_SECT      512     /* sectors per device */
#undef  CFG_FLASH_CHECKSUM
#define CFG_FLASH_ERASE_TOUT    1024000 /* Flash Erase Timeout (ms) */
#define CFG_FLASH_WRITE_TOUT    500     /* Flash Write Timeout (ms) */

#define CFG_FLASH_CFI_DRIVER
#define CFG_FLASH_CFI
#define CFG_FLASH_EMPTY_INFO

	Cheers

-------------------------------------------------
=> flinfo

Bank # 1: CFI conformant FLASH (32 x 16)  Size: 128 MB in 512 Sectors
 Erase timeout 16384 ms, write timeout 1 ms, buffer write timeout 4096 ms, buffer size 32
  Sector Start Addresses:
 F8000000 E    F8040000 E    F8080000 E    F80C0000 E    F8100000 E
 F8140000 E    F8180000 E    F81C0000 E    F8200000 E    F8240000 E
 ...
 

-----Original Message-----
From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of Tolunay Orkun
Sent: quarta-feira, 4 de Janeiro de 2006 22:32
To: Wang Jian
Cc: Wolfgang Denk; u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] Suggestion on flash init

Wang Jian wrote:
>>In message <20051225190658.F3F9.LARK@linux.net.cn> you wrote:
>>
>>>I have tested cfi_flash.c for a while. Unfortuanately, it fails for
>>>Spansion S29AL016M. The chip can be recognized, chip information is all
>>>correct, but the erase and write routines fail.
(...)