This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Flash infrastructure rework


On Fri, Aug 20, 2004 at 03:44:36PM +0100, Bart Veer wrote:
> >>>>> "Andrew" == Andrew Lunn <andrew@lunn.ch> writes:
> 
>     >> Interrupts
>     >> ----------
>     >> 
>     >> I believe it is very important we sort out the interrupt issue.
> 
>     Andrew> You are braver than i am. I decided this was too thorny an
>     Andrew> issue to tackle and just documented the problem. It is
>     Andrew> only a problem when the application or RedBoot is running
>     Andrew> from ROM. Currently interrupt disabling is left to the
>     Andrew> application programmer do use if needed.
> 
> I believe it is a much bigger problem than that. Any scenario
> involving ROM RedBoot and a RAM application can be affected.

Yep, thats what i said: "application or redboot is running from ROM".
To be safe you need a RAMROM/RAM redboot and a ROMRAM/RAM application.

> Or concurrent read and write operations in a
> flash-based file system - although I am not sure how jffs2 handles
> that at the moment. 

Jffs2 plays nice and uses the flash API. So the mutex locking will
ensure that there are no similtanious operations with anything else.

> The application may also be manipulating the flash directly in
> various ways.

But thats the nornal case of all bets are off if you go direct to the
hardware and ignore the OS. Any application that does that is broken.

> I am not sure we can drop the existing AMD driver, there are an awful
> lot of board ports which use it. However any work done sorting out the
> interrupt/cache issues in one driver should carry across fairly easily
> to other drivers.

I would not drop the driver. Its too much work to change every
platform to use a generic CFI driver. I would more encourage people to
use the new drivers for new ports.

> Also, the AMD driver may have size advantages because you don't need
> the code that does the hardware querying. And it may be easier to
> specify which bootblocks should be used for fis and fconfig if you
> know exactly which chip(s) may be used, rather than figuring it out at
> run-time somehow.

Humm, maybe. I've not looked yet at how redboot would support boot
blocks. The CDL becomes interesting base the current block offsets
concept assumes all blocks are the same size. 

>     >> If we are going to move interrupt handling down into the
>     >> drivers then we'll also have to move any cache manipulation
>     >> there. The alternative would be e.g. a potential context switch
>     >> while the caches are disabled, and then the system is messed
>     >> up.
> 
>     Andrew> Why is it messed up? The current macros don't just disable
>     Andrew> it, they flush and invalidate it first. So a context
>     Andrew> switch is safe. The higher priority threads which gets to
>     Andrew> run will run slower since it does not have any caching,
>     Andrew> but thats how it currently works anyway. The only read
>     Andrew> danger is if something else unconditional re-enables the
>     Andrew> cache and then we are dead when the flash driver gets
>     Andrew> control again.
> 
> Running with caches disabled can easily cost you an order of magnitude
> in performance. Suppose your application has a highish priority
> thread, regularly woken up by an interrupt, which consumes about 50%
> of the available cpu time for its processing. In a lower-priority
> thread you do a write to a jffs2 logfile. The flash write starts, the
> cache is disabled, an interrupt happens and wakes up the higher
> priority thread, it tries to do its processing but will do so much
> more slowly than before and can no longer keep up with the incoming
> interrupts, and the lower-priority thread doing the flash write never
> wakes up again to re-enable the cache. The system is messed up.

OK. We have a different definition of messed up. Going by that
definition, all current eCos systems using flash are messed up. Thats
exactly what happens today! 

I was interpreting you to mean messed up as crashed. If the cache had
been disabled but not flush and invalidated, a context switch under
those conditions could lead to a crash when the thread access
inconsistent memory.

I supposed it should be safe to disable interrupts, disable the cache,
do what is needed and then reenable the cache and lastly
interrupts. There is no need to flush and invalidate the cache which
will save a lot of time.

But its not as simple as that. Its target dependent. eg on the ARM you
don't actually need to do anything with the cache. You setup the MMU
so the range of memory the flash occupies if none-cacheable, not
bufferable and then just access it as normal. Its not optimial since
you loose some performance on reads, but its much simpler.

>     >> cyg_flash_get_block_info() and cyg_flash_get_limits(): I think
>     >> we should just get rid of these completely. Full information on
>     >> the flash is available by other calls, and higher-level code
>     >> such as RedBoot should be made to use these.
> 
>     Andrew> I thought about that and changing redoot to use the other
>     Andrew> calls is something that is needed when making redboot use
>     Andrew> bootblocks. Removing these calls just makes it harder for
>     Andrew> people porting there own applications to the new api.
> 
> I don't think that is a big deal, the functions would remain in the
> legacy API. Since we are introducing a new API we should make it as
> clean as possible.

OK. I will take these out.

> 
>     >> cyg_flash_code_overlaps(): I am not sure this can be cleanly
>     >> defined. For example, consider a platform with one flash chip
>     >> that uses bottom boot blocks. If we want to make efficient use
>     >> of this chip then we want to place the fis and fconfig data in
>     >> these boot blocks. Hence the first boot block will contain some
>     >> startup code followed by a jump to later in the flash, then
>     >> we'll have the fis and fconfig blocks, and then the rest of the
>     >> code. How would cyg_flash_code_overlaps() work with that
>     >> scenario?
> 
>     Andrew> The HAL needs to be able to implement it. That is the only
>     Andrew> thing that knows what goes where. I didn't really like
>     Andrew> this function to start with, but redboot uses it quite a
>     Andrew> lot for user input sanity checking. We could remove it and
>     Andrew> hope the user knows what (s)he is doing.
> 
> HAL checks may not suffice if the application makes virtual vector
> calls. RedBoot could get much the same functionality by detecting
> CYG_HAL_STARTUP_ROM and looking for an overlap with its own fis entry,
> without needing a dubious flash_code_overlaps() function. That won't
> work 100% on all platforms, e.g. there may be startup types other than
> ROM which also have RedBoot resident in flash, but it will work on
> most.

OK. Like i said, i didn't like this function, so im happy to remove
it. Gary, what do you say?

        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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]