[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug in lm32 port
- Date: Fri, 27 Mar 2009 13:46:12 +0200
- From: jukka.pietarinen at mrf.fi (Jukka Pietarinen)
- Subject: bug in lm32 port
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.
> 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
>>> (and the section that holds the isr handler) must not be greater than
>>> 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...
>> rtems-users mailing list
>> rtems-users at rtems.com