Notice: We have migrated to GitLab launching 2024-05-01 see here:

#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:


The mcf5235 crashes on boot with:

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 <
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 <
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 12/01/14 at 02:52:53.
Preprocessed source
init5235.s (61.7 KB) - added by Chris Johns on 12/01/14 at 02:53:12.
Invalid assembler output.

Download all attachments as: .zip

Change History (6)

Changed on 12/01/14 at 02:52:53 by Chris Johns

Attachment: init5235.i added

Preprocessed source

Changed on 12/01/14 at 02:53:12 by Chris Johns

Attachment: init5235.s added

Invalid assembler output.

comment:1 Changed on 12/01/14 at 03:25:10 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 12/01/14 at 03:57:07 by Chris Johns <chrisj@…>

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

In [changeset:"dd309b10544bfceda968ac847ad34c3d90ca8281/rtems"]:

Error: Processor CommitTicketReference failed
/data/trac/repo/rtems.git does not appear to be a Git repository.

comment:4 Changed on 12/01/14 at 04:06:12 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 12/01/14 at 04:06:57 by Chris Johns (previous) (diff)
Note: See TracTickets for help on using tickets.