bug in lm32 port

[Joel Sherrill]

Jukka Pietarinen wrote:
> Joel Sherrill wrote:
>   
>> I looked at the lm32 assembly ISR code to answer
>> an earlier question of Michael's.  It looked to me
>> that the port does not dispatch out of ISRs which
>> means that it can't preempt from an ISR.
>>
>> Where is the code for the port that would cause
>> a context switch from an ISR?
>> I could have just missed it.
>>     
>
> No, as is further interrupts are disabled during interrupt processing, 
> however, the debugger has higher priority and is using its own exception 
> table, if this was a question about the debugger. I thought interrupts 
> would not need to be preemptive as the handler code usually is very 
> short - maybe I'm missing something.
>   
I am not referring to the debugger stub.  I am concerned about
normal interrupt processing.  Look at the code in score/cpu/m68k
for a fairly easy to read example.  The user ISR can wake up
a task and after the ISR handler returns, you have to check
some variables to determine if you need to return to the interrupted
thread via normal "interrupt return" or whether you return to
a "dispatch from interrupt point". 

--joel
> Thanks,
> Jukka
>
>   
>> Jukka Pietarinen wrote:
>>     
>>> Hi Michael,
>>>
>>> Michael Walle wrote:
>>>  
>>>       
>>>> there is a bug in the lm32 port in the startup routines. There are
>>>> immediate branches to the isr handler and main function.
>>>>
>>>> On lm32 the opcode can encode 26bits adresses in an immediate branch,
>>>> which permits relative jumps of 64 MiB.
>>>>
>>>> The startup code is divided into a .boot and a .text section. The use of
>>>> immediate branches implies, that the 'distance' between these two 
>>>> sections
>>>> (and the section that holds the isr handler) must not be greater than
>>>> 64mb.
>>>>
>>>> So if, for example, one defines the .boot section in the embedded block
>>>> ram to be at 0x00000000 and the .text section in flash/sram 
>>>> (whatever) at
>>>> 0x40000000, he gets the following error:
>>>> (.boot+0xc0): relocation truncated to fit: R_LM32_CALL against symbol
>>>> `_ISR_Handler' defined in .text section ...
>>>>
>>>> Proposed fix:
>>>>  - move crt0 in libbsp/lm32/shared/start/start.S to .boot
>>>>  - use indirect branches
>>>>
>>>> But there is a problem with the ISR handler call: when the cpu jumps to
>>>> the interrupt vector, no registers have been saved yet. So we cannot use
>>>> indirect jumps. We can't even use register r0 (which is supposed to be
>>>> zero) because the "mvhi rX, imm16", which we need for indirect branches,
>>>> is just a pseudo operation for "orhi rX, r0, imm16".
>>>>
>>>> Some Thoughts:
>>>>  - we could change EBA (which is the exception base address) in the
>>>> bootcode and branch to it right after power up/reset. so our 'real'
>>>> exception vectors are no longer in the .boot section (well .. that
>>>> doesn't resolve the problem, but relocate it)
>>>>  - some support code in the .boot section that saves some registers onto
>>>> the stack
>>>>
>>>> Any other ideas?
>>>>     
>>>>         
>>> We could move both crt0 and _ISR_Handler to the .boot section. 
>>> Wouldn't that work?
>>>
>>> I just noticed crt0 does use immediate call to boot_card...
>>>
>>> Thanks,
>>> Jukka
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>   
>>>       
>
>   


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