#2204 closed defect (fixed)

mcf5235 has invalid code in start up

Reported by: Chris Johns Owned by: Chris Johns
Priority: highest Milestone: 4.11
Component: bsps Version: 4.11
Severity: blocker Keywords: bsp coldfire
Cc: Blocked By:
Blocking:

Description

The mcf5235 crashes on boot with:

dBUG> TRAP #7
PC: 000442F2 SR: 2704 [t.Sm.111...xnZvc]
An: 40000000 00006372 FBF7B9E5 F75F5FF7 00006286 F6F5FBFF 00006276 00006272
Dn: 001F1980 00000000 00000019 B75FFEFC FFFFFDCF FFB7AF5F DE5F5FC7 D9BBFDFE
000442F2: 0000 DC.W 0x0000

Inspection of the code with objdump shows Init5235 code is:

000442b8 <Init5235>:

442b8: 598f subql #4,%sp
442ba: 303c 3fff movew #16383,%d0
442be: 4297 clrl %sp@
442c0: 33c0 4010 0048 movew %d0,40100048 <IPSBAR+0x100048>
442c6: 70e1 moveq #-31,%d0
442c8: 13c0 4010 0040 moveb %d0,40100040 <
IPSBAR+0x100040>
442ce: 70e0 moveq #-32,%d0
442d0: 33c0 4000 0080 movew %d0,40000080 <IPSBAR+0x80>
442d6: 203c 001f 0001 movel #2031617,%d0
442dc: 23c0 4000 0084 movel %d0,40000084 <
IPSBAR+0x84>
442e2: 303c 1980 movew #6528,%d0
442e6: 33c0 4000 008a movew %d0,4000008a <IPSBAR+0x8a>
442ec: 42b8 0000 clrl 0 <HeapSize?>
442f0: 4e47 trap #7

...

which is wrong. It looks like something in the compiler has changes and it could the RTEMS 'm68k_set_vbr'. The .i file shows this as:

do { asm volatile ( "movec %0,%%vbr " : : "r" (0)); _VBR = (void *)0; } while(0);

and that is generating a .s of:

clr.l 0.w

trap #7

which is wrong. It is not clear what has change and what has broken with this BSP or it is the tools that are broken.

Attachments (2)

init5235.i (134.9 KB) - added by Chris Johns on Dec 1, 2014 at 2:52:53 AM.
Preprocessed source
init5235.s (61.7 KB) - added by Chris Johns on Dec 1, 2014 at 2:53:12 AM.
Invalid assembler output.

Download all attachments as: .zip

Change History (6)

Changed on Dec 1, 2014 at 2:52:53 AM by Chris Johns

Attachment: init5235.i added

Preprocessed source

Changed on Dec 1, 2014 at 2:53:12 AM by Chris Johns

Attachment: init5235.s added

Invalid assembler output.

comment:1 Changed on Dec 1, 2014 at 3:25:10 AM by Chris Johns

It looks to me like a gcc bug. Moving the copy out of init5235.c generates clean code and RTEMS boots.

comment:3 Changed on Dec 1, 2014 at 3:57:07 AM by Chris Johns <chrisj@…>

Owner: set to Chris Johns <chrisj@…>
Resolution: fixed
Status: newclosed

In dd309b10544bfceda968ac847ad34c3d90ca8281/rtems:

m68k/mcf5235: GCC 4.9.2 generates invalid code for Init5235.

Move the vector table copy out of the Init5235 source to avoid
stipping the GCC bug.

Fixes #2204.

comment:4 Changed on Dec 1, 2014 at 4:06:12 AM by Chris Johns

The very prompt response from the gcc community is this is expected behaviour when writing to 0 on the target. The -fno-delete-null-pointer-checks option disables the check.

I am happy to have our code built with this option because we should not be writing to 0 unless it is a special case such as setting up the vector table.

I am now wondering about the state of our other BSPs.

Last edited on Dec 1, 2014 at 4:06:57 AM by Chris Johns (previous) (diff)
Note: See TracTickets for help on using tickets.