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
