[ECOS] Non-contiguous flash with flashv2

Daniel Helgason dhelgason@shaw.ca
Thu Dec 4 06:18:00 GMT 2008

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

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

More information about the Ecos-discuss mailing list