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

[Michael Schwingen <rincewind@discworld.dascon.de>]

Mike Frysinger wrote:
> some Blackfin processors have an optional async memory controller which allows 
> for up to 4 megs of memory to be mapped.  sometimes these 4 megs are not 
> enough, so people extend this by hooking up the higher address pins to GPIOs.  
> so if you want to map 8 megs of memory, the highest address pin would be tied 
> to a GPIO line while the remaining address pins would be hooked up like 
> normal directly to the processor.
>   
Hm - I have seen this on an ARM11 CPU recently (don't ask - fortunately, 
I did not have to work on that target for long, and the u-boot they 
provided was a good example how not to do patches).
It seems strange why chip manufacturers implement such a limited 
expansion bus address space on CPUs which have enough CPU address 
capability, expecially on devices that support linux.

> 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.

> - 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.

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.

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 ...

cu
Michael