[ECOS] [RFC] CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM

[ECOS] [RFC] CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM

[Jani Monoses]

Hi
there are a few flash drivers which still implement the
CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM interface while the
way to handle the problem of executing from/modifying the flash 
in the same time is solved in newer drivers by putting the
sensitive functions to sections which at load time are put in RAM
by appending section attributes to their prototypes.
Still there might be cases when the functions can stay in flash -
one that I can think of is when the flash has separately erasable/programmable
regions and you're sure you'll only touch one while the code is in the other.
At least one comment in the strataflash .cdl says that:

        Rarely, it is useful to disable the request that flash driver code
        be copied to separate RAM for execution.  This option lets you do that.

So according to this a replacement of the interface with the new way using attributes
could have this small regression.

What do the maintainers think?

1)"I wish people stopped nitpicking the sources and do some real work instead of cleanups"
2)"All drivers should use the section attribute"
3)"We could have a macro which expands to the current attribute or to nothing if a driver
independent cdl option is set and all drivers turned to using this macro"
4)...


Thanks
Jani.


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

Re: [ECOS] [RFC] CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM

[Jonathan Larmour]

Jani Monoses wrote:
> Hi
> there are a few flash drivers which still implement the
> CYGHWR_IO_FLASH_DEVICE_NOT_IN_RAM interface while the
> way to handle the problem of executing from/modifying the flash 
> in the same time is solved in newer drivers by putting the
> sensitive functions to sections which at load time are put in RAM
> by appending section attributes to their prototypes.
> Still there might be cases when the functions can stay in flash -
> one that I can think of is when the flash has separately erasable/programmable
> regions and you're sure you'll only touch one while the code is in the other.
> At least one comment in the strataflash .cdl says that:
> 
>         Rarely, it is useful to disable the request that flash driver code
>         be copied to separate RAM for execution.  This option lets you do that.
> 
> So according to this a replacement of the interface with the new way using attributes
> could have this small regression.
> 
> What do the maintainers think?
> 
> 1)"I wish people stopped nitpicking the sources and do some real work instead of cleanups"
> 2)"All drivers should use the section attribute"
> 3)"We could have a macro which expands to the current attribute or to nothing if a driver
> independent cdl option is set and all drivers turned to using this macro"
> 4)...

1 and 4 for sure :). To me 3 seems best, but then I haven't the time to 
write a patch for all that, so it's easy for me to say ;).

Note: be careful to avoid breaking things for 3rd party drivers with an 
interface change. Not every flash driver that exists is checked into the 
master repo.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


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