public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wang Jian <lark@linux.net.cn>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Suggestion on flash init
Date: Sun, 25 Dec 2005 20:02:49 +0800	[thread overview]
Message-ID: <20051225190658.F3F9.LARK@linux.net.cn> (raw)
In-Reply-To: <20051225101920.51CAA353ACD@atlas.denx.de>

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

  reply	other threads:[~2005-12-25 12:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-25  4:33 [U-Boot-Users] Suggestion on flash init Wang Jian
2005-12-25 10:19 ` Wolfgang Denk
2005-12-25 12:02   ` Wang Jian [this message]
2005-12-25 16:34     ` Wolfgang Denk
2005-12-26  1:49       ` Wang Jian
2006-01-03 13:16         ` Wang Jian
2006-01-03 14:08           ` Wolfgang Denk
2006-01-03 15:34             ` Wang Jian
2006-01-03 15:44               ` Wolfgang Denk
2006-01-04 22:31         ` Tolunay Orkun
2006-01-04 23:51           ` Wolfgang Denk
  -- strict thread matches above, loose matches on Subject: below --
2006-01-05 16:20 Nuno João (Ext_NBS)

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=20051225190658.F3F9.LARK@linux.net.cn \
    --to=lark@linux.net.cn \
    --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