longcall probelm (RE: was MVME2304 Exception 3 )

[Till Straumann]

Paul D Jines wrote:

>
>
>  
>
>>>>The error I got while loading the object code is :
>>>>
>>>> "Relocation of type 'R_PPC_REL24' failed: The relocation was
>>>>        
>>>>
>performed,
>  
>
>>>> but there was an overflow (check compiler flags!)"
>>>>
>>>>        
>>>>
This is CEXP who legitimately complains. The compiler generates code for
'short calls'
(R_PPC_REL24 relocation type) but CEXP loaded the module too far apart
to satisfy
the short reloc.

As I said, I recommend a simple workaround (I implemented this for the
SVGM BSP):
Let (in bspstart.c) the BSP limit the initial memory size to 32M and
provide __sbrk()
to add the rest of the memory when needed.
The idea is then to load all your modules prior to mallocating large
amounts of
memory (which will eventually trigger a call to __sbrk()).

>  
>
>>I  wonder  if Paul ever got this error message in loading >his object
>>    
>>
>code.
>
>I don't recall seeing that message.
>
>  
>
>>What is Paul's status now ?
>>Did Paul get the MVME2304-0143 working with the  version
>>Till build for  his  exception 3 diagnosis ?
>>    
>>
>
>By using the NBH/manually shutting down the network
>method that Till describes, everything works.  (Another
>thing that complicated our situation was a buggy terminal
>emulator.)
>
>  
>
>>>No - I suppose the exception 3 occurs (spuriously) because
>>>PPCbug's NBO command fails to shut down the ethernet interface.
>>>Therefore, the ethernet chip could still DMA when RTEMS is
>>>already executing (memory that were PPCbug's network buffers
>>>are now used by RTEMS).
>>>      
>>>
>
>  
>
>>I have not gotten exception 3 with  the MVME2306 (32Mb) >lately,
>>and not yet with the MVME2304-0141 (128MB) board.   I think
>>you might be right about the NBO command.  I rarely got the
>>exception 3 with the  MVME2306 in the past.  It seems that >it went
>>away lately.
>>    
>>
>
>One of the things that Till suggested that we try on our
>board during the diagnosis was to reset the memory size to
>32MB.  When we did that, things worked, even without
>resetting the network interface....
>  
>
I suggested this because I first suspected a bug in the page table code.
Later we found that PPCBug is to blame. Reducing the memory size
eliminated the problem because PPCBug (apparently) has its networking
buffers at the top of physical memory.
I don't understand why I (nor Kate) never ran into this because the MVME3206
with less memory essentally behaves the same way. I guess it is just luck -
PPCBug's networking buffers just don't collide with vital RTEMS data on that
board. Fixing it is nevertheless recommended.

T.

>
>Paul
>
>  
>