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

Greg Ungerer gerg at snapgear.com
Fri May 21 01:41:08 EDT 2010


Hi Angelo,

angelo wrote:
> 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.

What sort of memory tests do you run?
How well do they check the RAM?
Do you run the memory tests with cache on as well as of?


> 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.

How far does execution get if you comment out that movec line?


> 2) before jumping to 0x400 i am checking the SDRAM, reading the code 
> just copied in memory. Here is what i am doing:

I don't really know Colilo well, but the processor is still
in supervisor mode when it passes control to the newly loaded
kernel isn't it?

Regards
Greg



> 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.
> 
> Thanks,
> Angelo
> 
> 
> 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.
>>>>       */
>>>>      PLATFORM_SETUP
>>>>
>>>>      /*
>>>>       * 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
>>>>
>>>>
>>>>      
>>>
>>>    
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev


-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg at snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com



More information about the uClinux-dev mailing list