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