[U-Boot-Users] "stacked" memory mapped flash assisted with GPIOs
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.
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. - 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.
maybe someone else has other/better ideas for how to approach the issue. i didnt seem to find anything relevant from google / bundled docs / wiki. -mike
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
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
Mike Frysinger wrote:
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.
Well, your parallel flash is *not* directly addressable, so it might be worth to check if the NAND code can be used (by providing a NAND low-level driver which redirects to your banked flash).
cu Michael
On Sunday 20 January 2008, Michael Schwingen wrote:
Mike Frysinger wrote:
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.
Well, your parallel flash is *not* directly addressable
only some chunks are directly addressable at any one time. but you're right that if you look at the whole thing, it isnt.
another (probably saner) option is to implement a new subsystem, say "flash" or "gnor" (GPIO NOR). it'd have the same basic semantics/syntax as the nand or eeprom commands where you cannot access the flash directly, but instead read/write chunks to/from external memory. to keep code duplication down, it'd hook into the common cfi driver for the lower layer functions ... -mike
On Sun, 20 Jan 2008 05:56:08 -0500 Mike Frysinger vapier@gentoo.org wrote:
- 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.
Wouldn't it be enough to just modify the blackfin-specific implementation of map_physmem() and unmap_physmem()? Just use some of the physical address bits to toggle the necessary GPIO lines and return a suitable pointer into the 4MB memory window.
Haavard
On Monday 21 January 2008, Haavard Skinnemoen wrote:
Mike Frysinger vapier@gentoo.org wrote:
- 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.
Wouldn't it be enough to just modify the blackfin-specific implementation of map_physmem() and unmap_physmem()? Just use some of the physical address bits to toggle the necessary GPIO lines and return a suitable pointer into the 4MB memory window.
i'm working with u-boot-1.1.6 at the moment (will probably be syncing to mainline in the next month or two) so i didnt see these hooks added to the cfi_flash.c driver.
that would allow board porters to select an arbitrary address and say "if you wish to erase/write the flash in a contiguous manner, you need to use the base address 0x........ rather than the real base address 0x........". however, from what i can see, this would only account for erase/writes. reads are done directly by u-boot using physical addresses, so those have no provision for catching accesses. -mike
On Mon, 21 Jan 2008 08:01:48 -0500 Mike Frysinger vapier@gentoo.org wrote:
that would allow board porters to select an arbitrary address and say "if you wish to erase/write the flash in a contiguous manner, you need to use the base address 0x........ rather than the real base address 0x........".
Hmm...yeah. Fake physical addresses...perhaps not exactly pretty, but it will do the trick as long as nothing is actually accessible from the "fake" addresses.
On the other hand, the extra GPIO-controlled lines really _do_ form a part of the physical address, at least as far as the flash is concerned.
however, from what i can see, this would only account for erase/writes. reads are done directly by u-boot using physical addresses, so those have no provision for catching accesses.
True. Maybe the code reading the flash really _should_ use the map_physmem() interface, though...doing cached reads from the flash might very well cause trouble later, when writing commands to it...
Haavard
participants (3)
-
Haavard Skinnemoen -
Michael Schwingen -
Mike Frysinger