[ECOS] Linker sections & network buffers question.

[ECOS] Linker sections & network buffers question.

[Will Wagner]

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?

Thanks,

Will.
-- 
------------------------------------------------------------------------
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

Re: [ECOS] Linker sections & network buffers question.

[Gary Thomas]

[-- Attachment #1: Type: text/plain, Size: 1746 bytes --]

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.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1481 bytes --]

Index: hal/powerpc/arch/current/src/vectors.S
===================================================================
--- hal/powerpc/arch/current/src/vectors.S	(revision 3391)
+++ hal/powerpc/arch/current/src/vectors.S	(working copy)
@@ -368,11 +368,13 @@
         li      r0,0            # r0 = 0
         cmplw   r3,r4           # skip if no bss
         beq     2f
+        sub     r4,r4,r3        # compute number of words to clear
+        srwi    r4,r4,2
+        mtctr   r4
+        subi    r3,r3,4
         
-1:      stw     r0,0(r3)        # store zero
-        addi    r3,r3,4         # increment by 1 word
-        cmplw   r3,r4           # compare
-        blt     1b              # loop if not yet done
+1:      stwu    r0,4(r3)        # store zero & increment pointer
+        bdnz    1b
 2:
 
         # clear SBSS
@@ -380,11 +382,13 @@
         lwi     r4,__sbss_end   # r4 = end
         cmplw   r3,r4           # skip if no sbss
         beq     2f
+        sub     r4,r4,r3        # compute number of words to clear
+        srwi    r4,r4,2
+        mtctr   r4
+        subi    r3,r3,4
         
-1:      stw     r0,0(r3)        # store zero
-        addi    r3,r3,4         # increment by 1 word
-        cmplw   r3,r4           # compare
-        blt     1b              # loop if not yet done
+1:      stwu    r0,4(r3)        # store zero & increment pointer
+        bdnz    1b
 2:
 
         # It is now safe to call C functions which may rely on initialized


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS] Linker sections & network buffers question.

[Will Wagner]

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

Re: [ECOS] Linker sections & network buffers question.

[Gary Thomas]

Will Wagner wrote:
> 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?

Probably not, but it would take some effort to get them into a different
section.

> 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.
>>
>>
> 


-- 
------------------------------------------------------------
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