[uClinux-dev] coldfire issue, _fault routine called setting VBR
angelo70 at gmail.com
Tue May 18 17:52:31 EDT 2010
thanks for the reply,
i am not using %a7, it is the uClinux kernel that use the stack pointer
as a temporary register. It is quite impossible that head.S of the
kernel have issues open.
#CONFIG_VECTORBASE is 0x00000000
Anyway, i replaced %a7 with %d0, just for test. Issue happen exactly
there, at the same line, setting VBR.
I have read that movec can trig an "illegal instruction" exception, and
i guess this is exactly what's happening here.
I had already the kernel running some months ago, one of the things i
changed is the toolchain, but also the version of the uClinux distribution.
I am starting to have some doubts on the toolchain.
On 18/05/2010 23:38, wittb at ecs.csus.edu wrote:
>> At reset, the "colilo" bootloader test the SDRAM memory, than start up
>> correctly giving the prompt.
>> Kernel 2.6 has been prepared with sdram start at 0x00000000, vector
>> start at 0x00000000, kernel code start at 0x400.
>> I load now through colilo "load" command the kernel (linux.bin) at 0x400
>> (SDRAM, flash is remapped at 0xffc00000 from colilo at reset).
>> Once i run the code from 0x400, after some instructions the $pc jump to
>> the "colilo" "_fault" routine.
>> I inserted a loop in
>> linux-2.6.x/arch/m68knommu/platform/coldfire/head.S, to find the exact
>> point where the jump happen, as below:
>> nop /* filler */
>> movew #0x2700, %sr /* no interrupts */
>> * Do any platform or board specific setup now. Most boards
>> * don't need anything. Those exceptions are define this in
>> * their board specific includes.
>> * Create basic memory configuration. Set VBR accordingly,
>> * and size memory.
>> movel #CONFIG_VECTORBASE,%a7
>> _loop: jmp _loop
>> movec %a7,%VBR /* set vectors addr */ *<<-- this line cause
>> the jump to _fault*
>> movel %a7,_ramvec
> Angelo --
> Here is my guess. I did MC68010 programming _many_ years ago.
> Why are you using A7 as your address reg? It is the stack pointer!
> If you have interrupts enabled ( which you don't ), that is a
> very good place to crash. What could happen instead, anytime
> you BSR ( call a subr ), pushing the return address will
> corrupt your memory. If CONFIG_VECTORBASE is a Flash address,
> then you will not get back the return address on RET .
> Could you use A0 instead of A7 (SP) ?
> anyway, I hope that helps,
>> Now i know the SDRAM is working correctly, but i am still stucked here.
>> Any help is really appreciated.
>> Many Thanks,
More information about the uClinux-dev