Debugging broken BSP suggestions?

Wed Mar 12 10:08:17 UTC 2014

Hi guys,

I have a patch that applies against HEAD and works correctly with my sample
application on the target hardware.

I tried to build the test suite tonight with the intention of running the
tests to confirm everything worked correctly but it broke with the error:

m68k-rtems4.10/bin/ld: utf8proc01.exe section `.text' will not fit in
region `rom'

Where do you configure which tests get built for a bsp, and which ones do I
need to run and confirm working before I can submit the patch?

Cheers,
James

On 11 March 2014 23:06, James Fitzsimons <james.fitzsimons at gmail.com> wrote:

> 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/20140312/e72e325b/attachment-0001.html>