longcall probelm (RE: was MVME2304 Exception 3 )

[Till Straumann]

Feng, Shuchen wrote:
> Hi all,
> 
> I could not use the -mlongcall  flag to compile my application.  
> I do not know if   I need to rebuild my toolchains with a specific option
> or the rs6000.c file needs to be patched.  I am heading both directions
> with no conclusion.  Hopefully, someone can shed some light for
> me. 
> 
> 
>  I believe the -mlongcall flag will solve the error message I ran to
> with the MVME2304-0141 board.  Probably Till does not need to rebuild the
> GeSys binary.  Without rebuilding the vxWorks image, we  used the -mlongcall
> option for the EPICS base and  application on the same board and it works.
> 
> 
> 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!)"
> 
> On August 18, Paul Jines wrote :
> 
> 
>>We are trying to run RTEMS on a MVME2304-0143 and are experiencing
> 
> Exception 3 errors.
> 
>>The exception 3's occur most of the time, but maybe 10% of the time do NOT
> 
> occur and run the
> 
>>GeSys application. It has never succeeded in running the epics
> 
> applications. 
> Te MVME2304-0141 board  is the same as Paul's  MVME2304-0143 with 128 MB.  
> Based on my experience with the MVME2306 board, the exception 3 could be
> caused by
> the improper setup of  the hardware or VME crate as well.  


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

Although this is easy to fix (I have patch for the 'bootloader'
ready), it is a bit tricky:

The proper place to shut down the interface would be from
a PPCBug "script" - unfortunately, there is no such feature.
This means that it has to be done manually during every boot
(involves the NBH command and some register twiddeling).
Alternatively, it can be done by the bootloader which must
resort to a PPCbug syscall. The ugly thing is that the
bootloader has no means to know that you actually did use
PPCbug to load the image - if you did use some other tool,
the PPCbug syscall will crash. The hack should hence
be made a 'configure/compile time' option...


-- Till
> 
> Regards,
> kate
>