[U-Boot-Users] "stacked" memory mapped flash assisted with GPIOs

[Mike Frysinger]

On Sunday 20 January 2008, Michael Schwingen wrote:
> Mike Frysinger wrote:
> > there are a few ways i can implement this in u-boot (and ive prototyped a
> > couple), but the question is which way to go.  i obviously dont want to
> > pick one which will be rejected for $whatever-reason.
> >
> > possibilities:
> > - add a command to manually toggle the GPIO lines
> >  * pros: simple to implement and requires no change to existing code
> >  * cons: requires user to manually toggle the address lines.  cannot
> > access multiple flashes in a single command.  not sure if this would work
> > with different types of flashes as the CFI code would only detect the
> > first.
>
> That does not seem very useful, unless you want to have two flashes that
> are switcheable, with a complete software version in each, so that the
> second flash is used for backup only. You can not have eg. a Linux image
> spanning across the boundary, and even a linux image in one flash and
> initrd in the other will probably also require extra work.

you could read it into external memory manually and bootm it there ... but 
that wouldnt be terribly efficient and may not be possible depending on the 
resources available ...

> > - have memory display / flash write commands toggle the GPIO lines
> >  * pros: user interface is transparent and not confusing by making it
> > seem like 1 flash exists (think software raid 0).  able to use 1 write
> > command and the lower layers will automatically split it across multiple
> > flashes.  should work with multiple types of flashes.
> >  * cons: requires modification to cmd_mem.c and cfi_flash.c.
>
> I think this is the way to go (do it somewhere in the lowlevel flash
> code)  - you have access to the whole flash, and higher-level commands
> can access the whole flash area. Not sure about bootm etc. - if commands
> directly reference flash locations, they will have to be changed to use
> some kind of flash_read accessor function that can do the GPIO toggling.

true ... there's more places than just the two i mentioned that would need 
modification ... anything that does direct memory addressing like bootm, 
crc32, cp, md, etc...

> You will need a range of "virtual" addresses that is big enough to map
> the whole flash - this is easy if the next 4MB after the physical flash
> location are unused, otherwise, you will have to fine a space in the
> memory map elsewhere.

yeah, i think you'd have to give it some "virtual" address space other than 
the real location.  for example, on the Blackfin processor, it has 4 banks 
(so it's 1 meg per bank) in a contiguous address space.  you could stack 
multiple flash on each bank.  so you cant really re-allocate the space after 
the first bank as virtual space for the stacked flashes on it as that'd 
clobber the space for the second bank ... i guess this is a pretty good 
argument for forcing the user to toggle the gpio's manually so that they know 
the exact state of the external memory banks wrt to flashes ...

> I have not yet looked at the details of working with NAND flash, but the
> requirements should be similar. Maybe the NAND subsystem can be coerced
> to do what you need ...

i dont think nand would be as much of a problem as it isnt directly 
addressable.  you have to go through the "nand" subsystem for reading/writing 
while with parallel nor flash, it's directly addressable.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080120/3b0f9138/attachment.pgp