On Wed, Aug 31, 2011 at 10:25 AM, Mike Frysinger <[email protected]> wrote:
> On Wednesday, August 31, 2011 09:57:33 Jie Zhang wrote:
>> From your explanation, the name HWAIT has nothing to do with flash. It
>> seems to me that it's just a coincidence BF527 SDP board uses PG0 as
>> flash_enable signal and PG0 happens to be a HWAIT signal for UART.
>
> the bootrom has one HWAIT signal and it gets used regardless of boot mode.  so
> you're right in that it isn't specific to any boot source.  however, it is not
> coincidental that the SDP guys picked PG0 to select the flash ... they did it
> explicitly because the default HWAIT signal is PG0.  thus their flash gets
> selected while the bootrom is booting the LDR, and then gets deselected after
> everything is done.  that way the async pins are free while it's running.
>
OK. Maybe it's not so coincidental. I still think renaming HWAIT to
FLASH_ENABLE will be better. What if later boot rom code chooses
another signal for the same purpose?

>> Here is the patch. It has a FIXME in it. It will not hurt now. It will
>> be fixed if we do it globally because then we can parse defaults
>> before user input. OK?
>
> looks good for a "right now" solution :)
>
Committed. Thank you!


Jie

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
UrJTAG-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/urjtag-development

Reply via email to