m68k and m68k-rtems-ld

[Joel Sherrill]

I just remembered that I hacked to comment something out of reset.S 
in order to get around what we believed to be a bug in m68k-rtems-ld.

The CVS history shows this.  There is a note in the ChangeLog that 
I did this.

2002-08-07      Joel Sherrill <joel at OARcorp.com>

        * start/Makefile.am: Pick up rest of Ralf'f changes and use
        cp not make-rel since there is no point in this case.
        * start/debugreset.S: Rights were not assigned.
        * start/reset.S: Add ifdef to avoid core dump until Chris can
        track it down.
        * start/cpuboot.c: Moved to startup.
        * startup/Makefile.am: Account for above.

See this for the diff.

http://www.rtems.org/cgi-bin/cvsweb.cgi/rtems/c/src/lib/libbsp/m68k/ods68302/start/reset.S.diff?r1=1.4&r2=1.5

--joel

Chris Johns wrote:
> 
> Joel Sherrill wrote:
> >
> > Nicolas PIGEON wrote:
> >
> >>Hi,
> >>
> >>This morning a problem occured when I tried to run an home made program with RTEMS on my 68302 board. Every program I compiled since this morning ran fine, even the bigest ones, this kind of issue was never seen before: On m68k processors, the address space on startup is only 8ko, so the whole boot code has to be there. But with my program, the linker places some big routines there, and one of the boot function (Boot_phase_1) is at 0x24ff and thus cannot be reached. I ran large programs before (such as httpd), and there were very few routines there, and the proc. was able to go to boot_phase_1 (which configures the chip selects).
> >>I know it's not really a RTEMS problem, but there's anybody to help me here...
> >>Is there a way to tell the linker to put these routine anywhere else, or to force him to put boot_phase_1 at the correct place? I guess It could be done easily, but I don't know how...
> >
> >
> > You will have to tinker with the loader script (linkcmds) or
> > gcc specifications (bsp_specs) to control which file is linked in
> > after start.S.  Assuming this file is in the BSP, it is probably
> > easiest to install this file as a separate .o like start.o and
> > treat it the same way.
> >
> 
> I agree. Looking at the BSP I think the link order (bsp specs file) is important.
> 
> As Joel suggests you could look at changing the linker command file to specify
> certain files first.
> 
> > Chris/Nicolas. Did you guys ever work out precisely what you wanted
> > patched in the BSP?  Chris made a comment about cutting the patch
> > down a bit.
> >
> 
> I am looking at this now. I will send an email to Nicolas about the bits I did
> not accept as is. The interrupt vector part will go in once my cvs update is
> finished.
> 
> --
>   Chris Johns, cjohns at cybertec.com.au

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985