public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] workspace_end_init, workspace_end and flash.c
Date: Tue, 28 Aug 2007 11:02:00 -0000	[thread overview]
Message-ID: <46D400BF.9070207@mlbassoc.com> (raw)
In-Reply-To: <46D3FF28.4070509@mlbassoc.com>

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

      reply	other threads:[~2007-08-28 11:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-27 23:54 Ben Wu
2007-08-28 10:55 ` Gary Thomas
2007-08-28 11:02   ` Gary Thomas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46D400BF.9070207@mlbassoc.com \
    --to=gary@mlbassoc.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).