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