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

angelo angelo70 at gmail.com
Sun May 23 18:17:40 EDT 2010


Hi Greg and all,

infinite thanks for the support, trying to comment out the line that set 
VBR i understood that the $pc point was variable, and mostly was 
happening just after the jump in SDRAM.

So i thought that some months ago i had the kernel partially loaded, and 
the only difference was in SDRAM initialization code.
And that was ! I replaced days ago some part of the initialization with 
the one sent me from a guy, but that code was not exactly for my SDRAM / 
clock.
Dumping SDRAM with kernel loaded was looking ok, but for the MCF5307 
execution/instructions fetch someway it wasn't.

So i rolled back to my previous initialization code, and it works !
I am very very happy. Now i am trying to get a working image. Seems my 
flash SST 39BF3201B is not correctly detected.



Linux version 2.6.29-uc0001 (root at angel7) (gcc version 4.2.4) #61 Sun 
May 23 23:59:24 CEST 2010

uClinux/COLDFIRE(m5307)
COLDFIRE port done by Greg Ungerer, gerg at snapgear.com
Modified for M5307 by Dave Miller, dmiller at intellistor.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 4064
Kernel command line:
PID hash table entries: 64 (order: 6, 256 bytes)
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory available: 15072k/16384k RAM, (1010k kernel code, 140k data)
SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Calibrating delay loop... 52.83 BogoMIPS (lpj=264192)
Mount-cache hash table entries: 512
bio: create slab <bio-0> at 0
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
ColdFire internal UART serial driver
ttyS0 at MMIO 0x100001c0 (irq = 73) is a ColdFire UART
console [ttyS0] enabled
ttyS1 at MMIO 0x10000200 (irq = 74) is a ColdFire UART
mice: PS/2 mouse device common for all mice
List of all partitions:
No filesystem could mount root, tried:  jffs2
Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)

Regards,
Angelo




On 21/05/2010 07:41, Greg Ungerer wrote:
>
> 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
>
>

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


More information about the uClinux-dev mailing list