[U-Boot-Users] [Patch 5/5] Add DataFlash support for AT91SAM9261EK board

[Lacressonniere Nicolas]

OK Wolfgang,

We will use the same commands for flash and dataflash parts.
I found an existing flag CFG_NO_FLASH that can be used to prevent from
compiling some flash code so that we can use same commands without compiling
specific flash part. Does that way seem OK for you?

I also have a question concerning new patches I have to submit. These
CFG_NO_FLASH modifications have some impact on one of the patch ([Patch 1/5]
Add support for AT91SAM9261EK board) I submitted yesterday and which was not
rejected... Do I have to submit 2 new patches (previous one will be
cancelled) or do I have to make a diff on impacted files and submit only the
new patch (previous one will be keeped)?

Thanks in advance.
Best regards.

Nicolas.

-----Original Message-----
From: u-boot-users-admin at lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Wolfgang
Denk
Sent: mercredi 25 janvier 2006 12:22
To: Lacressonniere Nicolas
Cc: U-Boot-Users
Subject: Re: [U-Boot-Users] [Patch 5/5] Add DataFlash support for
AT91SAM9261EK board


Dear Nicolas,

in message
<KAEELLICOFHDAEPIACDEKEPOCFAA.nicolas.lacressonniere at rfo.atmel.com> you
wrote:
>
> Our board does not use any parallel flash part... So if I enable
> CFG_CMD_FLASH flag, I need to add an unnecessary flash.c file in
> board/at91sam9261ek directory in order to have access to low-level flash
> functions (flash_init...) So do I have to create such a file with empty
> functions? Or can we create another set of command? What do you think is
> best?

You don;t need a file flash.c in your board directory; there are many
boards without such a file - for example all  boards  using  the  CFI
flash driver. It does not matter where the function flash_init() gets
implemented - and you will need some function like that, too.

The question if we want to have special commands  for  dataflash  was
discussed a long time ago when the first board added support for such
devices.  By  then  it  was  decided that the standard flash commands
(protect, erase, cp, flinfo) shall be used  for  dataflash,  too,  so
that  the  behaviour  is completely transparent for the user. I still
think that was a good decision.

> > Also, I don't  see  any  need  for  a  "dflc  init"  command  -  such
> > initialization  should be done when needed and without needing manual
> > user interaction.
> OK, I will remove it.

Just rename this code into  flash_init()  and  one  of  the  problems
mentioned above just disappears...

> > And "dflc info" is  supposed  to  be  part of  the
> > "flinfo" output on your hardware.
> See first part...

See above. Please support the standard flinfo command.

> > * Add addr2ram verification in do_mem_cp function.
> > I also reject the patch because I think that such "verification" is a
> > bad thing.
> OK, I will remove it.

Thanks.

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 perversity of nature is nowhere better demonstrated by  the  fact
that,  when  exposed to the same atmosphere, bread becomes hard while
crackers become soft.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users