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 <[EMAIL PROTECTED]> -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
