[ECOS] workspace_end_init, workspace_end and flash.c

Gary Thomas gary@mlbassoc.com
Tue Aug 28 11:02:00 GMT 2007

Gary Thomas wrote:
> Ben Wu wrote:
>> I've been working to integrate the RedBoot 2.04 Intel IXP42x NPE
>> ethernet driver to work with the most recent Ecos code and ran into a
>> problem where NPE "workspace" buffers were being overwritten causing the
>> boot process to hang.
>> I've tracked down the problem to the flash code where it allocates it's
>> own workspace buffers. Specifically :
>>>  workspace_end = (unsigned char )(workspace_end_init - fisdir_size);
>> In the 2.04 intel fork, the line reads
>>>  workspace_end = (unsigned char )(workspace_end - fisdir_size);
>> why the change? It seems that by doing so the flash init assumes it
>> always be called first and assumes any code that needs workspace will
>> use the workspace_end pointer rather than the workspace_end_init pointer.
>> It turns out that the NPE init code is being inserted before the flash
>> init code with the same RedBoot_INIT_FIRST priority level. Is there
>> anyway to fine tune insertion of initialization routines with a the same
>> priority order?
> You'd have to ask Intel why the change; they don't share their code
> with us, nor track our CVS (closely).

Actually, this is a case where it would have been nice for Intel *to* share!
They found something and we only learn about it the hard way...

> If the NPE code is indeed being executed before the FLASH code, then
> this change would be required.  The order of routines with the same
> priority is based on how the linker fills in the init table - not something
> that should ever be counted on :-(
> Looking at the code however, I think that the version which uses workspace_end
> is more correct and will work no matter what order init functions are called.

Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world

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