public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Will Wagner <will_wagner@carallon.com>
To: Gary Thomas <gary@mlbassoc.com>
Cc: eCos Discussion <ecos-discuss@ecos.sourceware.org>
Subject: Re: [ECOS] Linker sections & network buffers question.
Date: Fri, 12 Oct 2007 14:41:00 -0000	[thread overview]
Message-ID: <470F87F1.4000800@carallon.com> (raw)
In-Reply-To: <470F7ABE.6050400@mlbassoc.com>

Gary,

Yes that seems to work great.

Do you have any idea about whether the net memory pools need to be in 
the bss section in the first place?

Thanks,

Will.

Gary Thomas wrote:
> Will Wagner wrote:
>> Hi All,
>>
>> Have hit a problem where in debug builds the initialisation of the bss
>> section to zero takes so long that the chip watchdogs.
>>
>> I'm using an MPC866 chip and one of the problems with it is that the
>> slowest I can set the watchdog to is just over 0.5secs. The bss section
>> is just under 3MB and most of that (2MB) are the networking buffers.
>>
>> So I have a whole load of questions for you:
>>
>> Do the network buffers really have to reside in the bss section. The
>> buffers are just used to create Mempools and looking at the code I don't
>> think it relies on the memory being zero'd.
>>
>> If the buffers don't need to reside in the bss section, anyone know
>> which section is the one for variables that don't get set to zero?
>> Anyone remind me of the gcc syntax for specifying which section
>> something goes in?
>>
>> On powerpc in vectors.S the sbss & bss sections are zero'd before the
>> cache & mmu are enabled which means that the access to the SDRAM will
>> not burst (I think) and so be much slower. Any reason for not
>> rearranging the code so that cache & mmu are enabled before we try to
>> zero sbss & bss?
> 
> Sorry, this won't work as much of the code (including the part that
> sets up the MMU) is written in C and will expect the BSS to have already
> been cleared.
> 
> Try the attached patch which uses a different sequence to clear the BSS.
> It should run quite a bit faster (2 instructions / word instead of 4).
> 
> BTW, if this works for you, let me know and I'll check it in.
> 
> 

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner@carallon.com
Senior Project Engineer                  Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------



-- 
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-10-12 14:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-12 13:05 Will Wagner
2007-10-12 13:46 ` Gary Thomas
2007-10-12 14:41   ` Will Wagner [this message]
2007-10-12 15:09     ` Gary Thomas

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=470F87F1.4000800@carallon.com \
    --to=will_wagner@carallon.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=gary@mlbassoc.com \
    /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).