[uClinux-dev] coldfire issue, _fault routine called setting VBR

angelo angelo70 at gmail.com
Thu May 20 08:42:29 EDT 2010

Dear all,

i have some additional info from the fault, setting VBR,
An exception for invalid instruction seems to be thrown, but in any 
case, the same instruction shouldn't cause any exception at all.
As you said, this could seems an SDRAM issue, but actually i solved the 
issues with it, memory test at startup pass always.

I checked,
1) the opcode, it is legal, correct, as per 5307 manual
movec %a7, %VBR correspond exactly to "4e7bf801" opcode in the manual.
This should exclude any toolchain or any -mCPU issue.
2) before jumping to 0x400 i am checking the SDRAM, reading the code 
just copied in memory. Here is what i am doing:

Sysam AMCORE boot...

colilo>l 400 0
load: Sysam AMCORE download to 400
Downloaded 1129472 bytes
colilo>m 0
00000000: 00000000 ffc00400 ffc0045e ffc0045e
00000010: ffc0045e ffc0045e ffc0045e ffc0045e
00000020: ffc0045e ffc0045e ffc0045e ffc0045e
00000030: ffc0045e ffc0045e ffc0045e ffc0045e
00000040: ffc0045e ffc0045e ffc0045e ffc0045e
00000050: ffc0045e ffc0045e ffc0045e ffc0045e
00000060: ffc0045e ffc0045e ffc0045e ffc0045e
00000070: ffc0045e ffc0045e ffc0045e ffc0045e
00000080: ffc0045e ffc0045e ffc0045e ffc0045e
00000090: ffc0045e ffc0045e ffc0045e ffc0045e
000000a0: ffc0045e ffc0045e ffc0045e ffc0045e
000000b0: ffc0045e ffc0045e ffc0045e ffc0045e
000000c0: ffc0045e ffc0045e ffc0045e ffc0045e
000000d0: ffc0045e ffc0045e ffc0045e ffc0045e
000000e0: ffc0045e ffc0045e ffc0045e ffc0045e
000000f0: ffc0045e ffc0045e ffc0045e ffc0045e
colilo>m 400
00000400: 4e7146fc 27002e7c 00000000 4e7bf801
00000410: 23cf000f ce3c2e7c 00000000 23cf000f
00000420: ce38203c 01000000 d08f23c0 000fce44
00000430: 203c0100 00004e7b 00024e71 203c0000
00000440: c0204e7b 00047000 4e7b0005 203ca000
00000450: 02004e7b 00024e71 43f90012 012023c9
00000460: 000fce40 41f90011 400043f9 00120120
00000470: 428020c0 b3c86600 fffa41f9 0010a000
00000480: 4fe81000 4eb90010 b4744efa fffe0000
00000490: 4e56ffa0 48d70c3c 266e0008 200f0280
000004a0: fffff000 20402a28 00104ab9 0011400c
000004b0: 660000fa 4e932800 4ab90011 400c667a
000004c0: 42001d40 ffc04a84 671072ed b284670a
000004d0: 4ab90011 400c6600 0136240f 0282ffff
000004e0: f0002442 baaa0010 671c4878 00404879
000004f0: 000eeb6c 486effc0 4eb90008 de482545
colilo>g 400

Vector table still contain offsets for the colilo "_fault" handler routine.
Anyway, even if everything is correct in memory, jumping to 0x400 i get 
the exception
setting VBR (@ offset 0x40C).

I am now suspecting of a kind of bad fetching instructions from the 
SDRAM, like if 16bit (2bytes)opcodes are read correctly, but not the 
longer opcodes.

I am really without any other ideas here.


On 18/05/2010 23:52, angelo wrote:
> brianW,
> 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.
> Regards,
> Angelo
> 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:
>>> _start:
>>>      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,
>> *brianW
>>> Now i know the SDRAM is working correctly, but i am still stucked here.
>>> Any help is really appreciated.
>>> Many Thanks,
>>> Angelo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20100520/1a790875/attachment.html>

More information about the uClinux-dev mailing list