On Sunday 29 November 2009, Michael Schwingen wrote:
> David Brownell wrote:
> > With NAND it's easy to see why they won't use CPU addresses. :)
> >
> > In general, using { bank, sector } addressing gives finer control
> > over the actual chip resources, and is less error prone, even for
> > NOR flash. You kind of want to avoid accidentally erasing (or
> > even protecting) the wrong data.
>
> However, it is not very useful if I need to write an image that spans
> multiple banks - I have boards where the addressable flash is made up
> out of multiple physical flash chips, each on its own chipselect, at
> adjacent addresses - and these may be different flashes, eg. one CFI and
> one non-CFI one, so that makes multiple banks in the OpenOCD configuration.
And different versions of a board may populate different NOR chips.
For example, is that 18 MByte image going into two different 16 MB
chips? Or is this board populated with two 32 MB chips? Sometimes
it won't matter...
> However, neither my bootloader not my kernel really care - they only see
> one big flash area, and when writing an image using OpenOCD, I need to
> do the same.
Well, "want" to not care. Likewise some folk "want" to use commands
which emphasize those specifics. I was just answering the question of
why folk like the { bank, sector } style addressing ... not saying that
the { address, offset } is bad. (Although it *is* only relevant for
NOR flash, not NAND; while the NAND market is growing faster...)
> Furthermore, I want to write *one* config file for such a type of board.
> I don't really care about what sector numbers in the flash are used -
> the addresses are constant, the sector numbers change depending on the
> particular flash that is stuffed on a board.
Sure. I have no problem with that model. I was just explaining why
that model doesn't suit everyone ... including the basic fact of not
even being relevant for NAND.
(Don't know about OneNAND ... it's a bit more NOR-ish than normal NAND.)
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
