Debugging broken BSP suggestions?

[Gedare Bloom]

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