bug in lm32 port

[Joel Sherrill]

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.

--joel

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
>