[ECOS] Non-contiguous flash with flashv2

[ECOS] Non-contiguous flash with flashv2

[Daniel Helgason]

I'm having trouble seeing how flashv2 handles non-contiguous areas of
flash memory. I can see how it handles multiple flash drivers, each of
which can be managing flash in separate memory areas. But it looks like
the flash memory managed by a single flash driver must still be
contiguous.

Here is the problem. I have *two* flash areas that are controlled by
*one* flash-controller device. The flash areas are non-contiguous.

Take 1:

If I define just a single flash driver, then I can use three block_infos
to describe the areas:

  - block_info[0] - program flash
  - block_info[1] - empty space (1 big block covering the whole area)
  - block_info[2] - boot flash

If I do that, then I need to special-case read/erase/program functions
in the driver for the second block_info because that area will take a
bus-error exception if read/written. Also, I don't know the impact to
the other parts of eCos if I'm untruthful about the flash addresses. I
suspect that Redboot, at least, will think it's all valid flash.

Take 2:

If I define two flash drivers that share code, then each driver will
have a single block_info that covers just the valid area:

  Driver 1
  - block_info[0] - program flash
  Driver 2
  - block_info[0] - boot flash

If I do that, I'll run into problems related to the per-driver mutexes
because both drivers share the flash-controller. Also, the flash io code
"bulks up" quite a bit because it has to manage two drivers.

So, which is better, Take 1 or Take 2? Or is there another way?

How about a Take 3 that adds an offset/start field to the block_info
type? Then it would be easy to support non-contiguous flash within a
single driver. I suppose that would make mapping flash addresses to
devices and blocks complicated.

-- 
+---------------------------------------------
| Daniel Helgason <dhelgason@shaw.ca>


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Non-contiguous flash with flashv2

[Andrew Lunn]

> Take 2:
> 
> If I define two flash drivers that share code, then each driver will
> have a single block_info that covers just the valid area:
> 
>   Driver 1
>   - block_info[0] - program flash
>   Driver 2
>   - block_info[0] - boot flash

This is what was intended when i designed the API.

However, i did not think of your case, multiple FLASH devices hanging
off one controller. 

The mutex is there to stop multiple threads accessing the same flash
device. That is still valid for you.

However the fact that there is one controller is hidden from the flash
API layer. You register two different devices. So your controller
mutex should be lower down. The device specific driver needs to
implement the mutex. 

          Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Non-contiguous flash with flashv2

[Daniel Helgason]

On Thu, 2008-12-04 at 07:33 +0100, Andrew Lunn wrote:
> > Take 2:
> > 
> > If I define two flash drivers that share code, then each driver will
> > have a single block_info that covers just the valid area:
> > 
> >   Driver 1
> >   - block_info[0] - program flash
> >   Driver 2
> >   - block_info[0] - boot flash
> 
> This is what was intended when i designed the API.
> 
> However, i did not think of your case, multiple FLASH devices hanging
> off one controller. 
> 
> The mutex is there to stop multiple threads accessing the same flash
> device. That is still valid for you.
> 
> However the fact that there is one controller is hidden from the flash
> API layer. You register two different devices. So your controller
> mutex should be lower down. The device specific driver needs to
> implement the mutex. 
> ...

Thanks Andrew. That's what I implemented.

It seems a bit of a pity to have to take two mutexs to perform a flash
operation. Would it be worth considering making the locking strategy a
configurable option in io/flash? Perhaps the choices could be none,
common, or per-driver.

If 'none' is selected, then flash drivers can implement their own
locking if they want. This would have to assume that the flash drivers
are aware of each others resource requirements. In smaller MPUs with
built-in flash and no external bus this restriction shouldn't be a
problem.

If 'common' is selected, then the io/flash layer would supply a single
lock that covers all drivers. Only a single flash driver could ever be
actively working at a time. This would have to assume that flash
operations complete in a timely manner.

If 'per-driver' is selected, then io/flash would do what it does now -
manage a lock for each flash driver.

To implement this would require changes to io/flash, of course, but I
don't think any of the existing v2 flash drivers would have to be
changed.

It comes to my mind as I write this email that maybe this idea would
impact flash drivers controlling NAND or serially accessed memory
devices. In fact the more I think about it, the less onerous having to
take two mutexes appears. Wishy-washy, eh?!

-- 
+---------------------------------------------
| Daniel Helgason <dhelgason@shaw.ca>


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Non-contiguous flash with flashv2

[Jonathan Larmour]

Daniel Helgason wrote:
> 
> It seems a bit of a pity to have to take two mutexs to perform a flash
> operation. Would it be worth considering making the locking strategy a
> configurable option in io/flash? Perhaps the choices could be none,
> common, or per-driver.

There's probably a better way to abstract this than making it an option -
it's an intrinsic property of the driver and should be set automatically.
After all, we want to support multiple different drivers in a system, with
completely different properties.

It imagine it could be expressed some way via some variant of the
CYG_FLASH_DRIVER macro. An initial thought is CYG_FLASH_DRIVER_NO_LOCK for
the case with no locks so the driver is responsible for locking if any is
required. Then you can also have CYG_FLASH_DRIVER_SHARED_LOCK  (better name
suggestions welcomed) to which you pass, along with the usual stuff,
another CYG_FLASH_DRIVER instance with which you share the same mutex lock.

The ability to selectively push locking into the driver would be worthwhile
- it would make it feasible to support operations like erasing of entire
planes. The above would make it possible I believe.

But in the most common case, we don't want to increase the porting effort
of individual drivers by requiring them to always do locking themselves,
IMHO. So anything which requires changing existing drivers should be
considered a no-no, especially since it should be after eCos 3.0.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Non-contiguous flash with flashv2

[Bart Veer]

>>>>> "Daniel" == Daniel Helgason <dhelgason@shaw.ca> writes:

    Daniel> On Thu, 2008-12-04 at 07:33 +0100, Andrew Lunn wrote:
    >> > Take 2:
    >> > 
    >> > If I define two flash drivers that share code, then each driver will
    >> > have a single block_info that covers just the valid area:
    >> > 
    >> >   Driver 1
    >> >   - block_info[0] - program flash
    >> >   Driver 2
    >> >   - block_info[0] - boot flash
    >> 
    >> This is what was intended when i designed the API.
    >> 
    >> However, i did not think of your case, multiple FLASH devices hanging
    >> off one controller. 
    >> 
    >> The mutex is there to stop multiple threads accessing the same flash
    >> device. That is still valid for you.
    >> 
    >> However the fact that there is one controller is hidden from the flash
    >> API layer. You register two different devices. So your controller
    >> mutex should be lower down. The device specific driver needs to
    >> implement the mutex. 
    >> ...

    Daniel> Thanks Andrew. That's what I implemented.

    Daniel> It seems a bit of a pity to have to take two mutexs to
    Daniel> perform a flash operation. Would it be worth considering
    Daniel> making the locking strategy a configurable option in
    Daniel> io/flash? Perhaps the choices could be none, common, or
    Daniel> per-driver.

Theoretically possible but I think it adds unnecessary complexity.
Your current behaviour is very similar to what already happens for
e.g. dataflashes on an SPI bus: there is a mutex at the flash driver
level, and a lower-down mutex at the SPI bus level. A mutex is a
fairly small object, so memory consumption is not a big issue. Locking
and unlocking an uncontested mutex are cheap operations, completely
negligible compared with actually performing a flash write or erase.

However, if you make the locking behaviour configurable then soner or
later somebody is going to get it wrong. A user may misunderstand the
option and set it inappropriately, or a new driver may do the wrong
thing. Then you end up with a system where flash mostly works, but
very occasionally you could have two threads accessing a flash device
at the same time with no mutex to protect against that, and you would
have bad things happening. That kind of bug is very hard to track
down.

Plus, you are adding complexity to the generic flash package and that
new code would need testing somehow, and long-term maintenance,

So let's keep things simple. The current approach works fine for most
current hardware. On some hardware it may involve an extra mutex and a
bit of extra locking, but the overheads are small.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss