[U-Boot-Users] [Patch 5/5] Add DataFlash support for AT91SAM9261EK board
nicolas.lacressonniere at rfo.atmel.com
Wed Jan 25 17:13:16 CET 2006
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.
From: u-boot-users-admin at lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Wolfgang
Sent: mercredi 25 janvier 2006 12:22
To: Lacressonniere Nicolas
Subject: Re: [U-Boot-Users] [Patch 5/5] Add DataFlash support for
<KAEELLICOFHDAEPIACDEKEPOCFAA.nicolas.lacressonniere at rfo.atmel.com> you
> 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
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.
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!
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
More information about the U-Boot