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

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

[Mike Frysinger]

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
-------------- 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/7f73af19/attachment.pgp 

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

[Michael Schwingen]

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

[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 

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

[Michael Schwingen]

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

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

[Mike Frysinger]

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
-------------- 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/20080121/4aa571b8/attachment.pgp 

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

[Haavard Skinnemoen]

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

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

[Mike Frysinger]

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
-------------- 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/20080121/9230661a/attachment.pgp 

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

[Haavard Skinnemoen]

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