[ECOS] Copying flash code to RAM problem

[Larice Robert]

this is an ecos bug, use can use something like

static char flashiodev_workspaces[1][FLASH_MIN_WORKSPACE] __attribute__ ((aligned))

or 

static char flashiodev_workspaces[1][FLASH_MIN_WORKSPACE] __attribute__ ((aligned(4)))

(a gcc C extension, info in gcc.info)


the problem is the two diminsional char array. most gcc use an implicit
__attribute__ ((aligned(1))) 
for such an array. this is clearly unsufficient for stack space.

the problem is widespread across lots of ecos files.
i've sent a patch to ecos-patches quite some time ago, but still un-answered.
(search the archive for "((aligned))", to find the patch)

the propability to experience the problem is small. (because most static
objects are 32 bit aligned and n*32 in size, linker will almost certainly
choose a 32 mit aligned addr for your particular char array)

Robert Larice

> Hi
> 
> Copying the flash code to RAM doesn't always work for me.
> 
> The RAM block to copy the code to is allocated in:
> 
> flashiodev.c:66
> static char flashiodev_workspaces[1][FLASH_MIN_WORKSPACE];
> 
> This might be located on an odd address, in which case the code fails to
> execute. I wonder why no one else has seen that problem. Is the alignment
> different with gcc-3? (I use gcc version 3.0.2 20010924 (prerelease)
> -mcpu=arm7tdmi)
> 
> Changing the line to
> static long
> flashiodev_workspaces[1][(FLASH_MIN_WORKSPACE+sizeof(long)-1)/sizeof(long)];
> fixes the problem.
> 
> Is that the best way to ensure alignment? I couldn't find any macros that
> handle alignment.
> 
> PS: Other than that I can report success with runnning the jffs2 test on an
> ARM7 platform.
> 
> Venlig Hilsen / Regards 
> Morten
> 
> -- 
> Morten Laursen, M.Sc.S.E.
> RTX Telecom A/S - http://www.rtx.dk/
> Direct phone: (+45) 96 32 24 03

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