BSP for MIPS32 4KC

[Joel Sherrill]

Feel free to file a PR on this and it will get fixed.


--joel

mikeci at acm.org wrote:

>>You sent this to me and not to the list.  Did you mean for it to
>>go to everyone?
>>
>>mikeci at acm.org wrote:
>>
>>
>>>Hi!
>>>
>>>There is another thing here. Modules compiled with mips=3 and mips=1
>>>or mips=32 can't be linked together. This is main reason why I think
>>>we should stick with mips=32 instead of doing everything with mips=3.
>>>Does anyone have better solution?
>>
>>And no.  The problem Ralf mentioned on the p4xx BSPs is exactly this
>>type of thing.  The RTEMS traditional solution is to have LOTS of
>>multilibs where needed and then depend on the linker to do the right
>>thing.
>>
>>
>>>Regards
>>>
>>>Ivica
>>>
> 
> 
> Hi!
> 
> Yes, this was post for the list. Ok. I am satisfied with the BSP I
> currently have. There is still one more thing. I don't know if I should
> file this as a bug or not. This is the code defined in vectorisrs.c for
> r46xx or p4000:
> 
> void mips_vector_isr_handlers( CPU_Interrupt_frame *frame )
> {
>   unsigned int sr;
>   unsigned int cause;
>   unsigned int i;
>   unsigned int mask;
> 
>   mips_get_sr( sr );
>   mips_get_cause( cause );
> 
>   cause &= (sr & SR_IMASK);
>   cause >>= CAUSE_IPSHIFT;
> 
>   /* XXX check this and think about it. */
> 
>   for ( i=1, mask=0x80 ; i<=8 ; i++, mask >>= 1 ) {
>     if ( cause & mask )
>       CALL_ISR( MIPS_EXCEPTION_BASE + 8 - i, frame );
>   }
> }
> 
> The line      CALL_ISR( MIPS_EXCEPTION_BASE + 8 - i, frame );
> is in error. It should be:
> 
>        CALL_ISR( MIPS_INTERRUPT_BASE + 8 - i, frame );
> 
> 
> Regards
> 
> Ivica
> 
> 
> 
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985