Debugging broken BSP suggestions?

Tue Mar 11 10:06:13 UTC 2014

Thanks Gedare!

I'll tidy up the code a bit and test it against the git HEAD. I've been
working against 4.10.2 up to now. Once I have something ready I'll submit a
patch.

Cheers,
James

On 11 March 2014 04:15, Gedare Bloom <gedare at rtems.org> wrote:

> James,
> Congratulations!
>
> Please feel free to submit a patch if you are able to do so to the
> rtems-devel mailing list. If you used the rtems-4.11 git master, some
> directions are available at
> http://wiki.rtems.org/wiki/index.php/Git_Users#Submitting_a_Patch. If
> you are working from an older version of rtems, the patch will still
> be useful for archival purposes if someone wants to get the BSP to
> work on newer versions of RTEMS.
>
> Gedare
>
> On Mon, Mar 10, 2014 at 5:44 AM, James Fitzsimons
> <james.fitzsimons at gmail.com> wrote:
> > Success!
> >
> > I have this bsp running again.
> >
> > The last step in the puzzle was that the mrm332.cfg (in the make/custom
> > directory in the bsp) had a value of RTEMS_CPU_MODEL=m68332. Changing
> that
> > to RTEMS_CPU_MODEL=mcpu32 and adding CPU_CFLAGS = -mcpu=cpu32 solved the
> > problem.
> >
> > I've actually ended up making a number of changes and fixes to get the
> bsp
> > running and it's now running out of ROM which was my goal.
> >
> > Thanks for all your help guys!
> >
> > Cheers,
> > James Fitzsimons
> >
> >
> > On 9 March 2014 23:13, James Fitzsimons <james.fitzsimons at gmail.com>
> wrote:
> >>
> >> Hi all,
> >>
> >> I've made a bit of progress tracking down the problem. I wrote an
> >> implementation for printk and managed to isolate the issue.
> >>
> >> It is dying in the following funciton in cpu.c:
> >>
> >> void _CPU_Install_interrupt_stack( void )
> >> {
> >> #if ( M68K_HAS_SEPARATE_STACKS == 1 )
> >>   void *isp = _CPU_Interrupt_stack_high;
> >>
> >>   asm volatile ( "movec %0,%%isp" : "=r" (isp) : "0" (isp) );
> >> #endif
> >> }
> >>
> >> Looking in m68k.h, M68K_HAS_SEPARATE_STACKS should be false for a mcpu32
> >> target. What am I missing?
> >>
> >> Is it something to do with RTEMS_CPU or RTEMS_CPU_FAMILY not being set
> >> correctly?
> >>
> >> My RTEMS version is 4.10.2 and I'm using eclipse with the RTEMS plugin.
> >>
> >> Feels like I'm close now, appreciate any pointers on these last details.
> >>
> >> Cheers,
> >> James
> >>
> >>
> >> On 7 March 2014 07:41, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
> >>>
> >>>
> >>> On 3/6/2014 11:19 AM, Gedare Bloom wrote:
> >>> > On Thu, Mar 6, 2014 at 5:37 AM, James Fitzsimons
> >>> > <james.fitzsimons at gmail.com> wrote:
> >>> >> Hi all,
> >>> >>
> >>> >> I'm trying to get an old bsp working - the mrm332 bsp for a 68332
> >>> >> target. I
> >>> >> know it's old technology but I have one of these boards and it will
> be
> >>> >> a
> >>> >> good fit for a project I want to do.
> >>> >>
> >>> >> Unfortunately I don't think the mrm332 bsp can every have been in a
> >>> >> working
> >>> >> state, or at least it isn't anymore.
> >>> >>
> >>> > What version of RTEMS is this BSP on?
> >>> >
> >>> >> I managed to get it kind of working by using the RAM linker script
> >>> >> which
> >>> >> just dumps everything into RAM, of course you can only run your
> >>> >> program once
> >>> >> and then you have to reload because the .data section gets hosed.
> >>> >>
> >>> >> I think I'm close to a linker script to run out of ROM, but it seems
> >>> >> to be
> >>> >> failing when it gets to bsp_get_work_area in bootcard.c. All I end
> up
> >>> >> with
> >>> >> is garbage at the console. I've verified it works up to here by
> >>> >> switching on
> >>> >> one of the onboard LED's just prior to the call to
> bsp_get_work_area.
> >>> >> I've
> >>> >> also examined the memory (flash and RAM) and it all looks pretty
> good.
> >>> >> Moving the LED code to just after the call to bsp_get_work_area
> >>> >> doesn't
> >>> >> work.
> >>> >>
> >>> > The most likely case is that the work area is overlapping with other
> >>> > memory sections in your linker script. The work area and program heap
> >>> > need to be well-defined regions that do not overlap with anything
> >>> > else, otherwise the initialization of those heaps will wipe out
> >>> > whatever memory they overlap.
> >>> >
> >>> >> I've gone over my linker script a dozen times. Anyone have any
> >>> >> suggestions
> >>> >> as to how to debug this problem?
> >>> >>
> >>> > Try to find the bounds on the program heap and the work space. See
> >>> > what the start/end addresses are and whether they are overlapping
> with
> >>> > anything else in memory.
> >>> If on the head, this is a likely candidate. AFAIK this BSP has not been
> >>> tested since
> >>> we moved to the common code for initializing memory. A simple bug in
> >>> memory
> >>> layout during the adjustment would do this.
> >>> > Good luck,
> >>> > Gedare
> >>> >
> >>> >> Many thanks!
> >>> >> James Fitzsimons
> >>> >>
> >>> >> _______________________________________________
> >>> >> rtems-users mailing list
> >>> >> rtems-users at rtems.org
> >>> >> http://www.rtems.org/mailman/listinfo/rtems-users
> >>> >>
> >>> > _______________________________________________
> >>> > rtems-users mailing list
> >>> > rtems-users at rtems.org
> >>> > http://www.rtems.org/mailman/listinfo/rtems-users
> >>>
> >>> --
> >>> Joel Sherrill, Ph.D.             Director of Research & Development
> >>> joel.sherrill at OARcorp.com        On-Line Applications Research
> >>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> >>> Support Available                (256) 722-9985
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20140311/3af6c51b/attachment.html>