> Do you really think this is needed? I think that the existing
> dataflash implementation (for the AT91RM9200) does not require any
> NOR flash either, and it does not need to do this.
Yes, I think it is necessary. I just had a look at AT91RM9200
implementation, and it includes all NOR flash stuff even if NOR flash is not
used... (cmd_flash.c requires a board/at91rm9200dk/flash.c and so on...)
As you told me before, we could use the same flash functions for NOR Flash
and DataFlash but it would break all existing code using
CONFIG_HAS_DATAFLASH flag. That's why I think the best thing is to use
CFG_NO_FLASH flag which will avoid embedding all NOR Flash stuff...
> If things are interdependent on such a level it's probably best to
> fix this first and then submit everything again, telling me to drop
> the previous set of patches.
OK, you can drop previous set of patches.
One more thing which is not clear to me. Concerning NAND development, you
told me to use testing-NAND git branch. But do I have to submit every
patches (board, lcd, usb...) against that branch or only the NAND part? If I
submit everything against testing-NAND branch, will it be included in a
future u-boot-1.1.5 release, for example?
From: wd@... [mailto:wd@...]
Sent: mercredi 25 janvier 2006 21:49
To: Lacressonniere Nicolas
Subject: Re: [U-Boot-Users] [Patch 5/5] Add DataFlash support for
> 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
> specific flash part. Does that way seem OK for you?
Do you really think this is needed? I think that the existing
dataflash implementation (for the AT91RM9200) does not require any
NOR flash either, and it does not need to do this.
> 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
> Add support for AT91SAM9261EK board) I submitted yesterday and which was
> 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
> new patch (previous one will be keeped)?
If things are interdependent on such a level it's probably best to
fix this first and then submit everything again, telling me to drop
the previous set of patches.
But then, your patches should not be dependent on each other in such
a way in the first place.
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@...
Put your Nose to the Grindstone!
-- Amalgamated Plastic Surgeons and Toolmakers, Ltd.