Debugging broken BSP suggestions?

Wed Mar 12 14:09:37 UTC 2014

James,

On Wed, Mar 12, 2014 at 6:08 AM, James Fitzsimons
<james.fitzsimons at gmail.com> wrote:
> 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'
>
You should use the rtems-4.11 tools for building the HEAD. Some things
may not work right otherwise.

For this particular issue, the problem is that some of the test cases
require a lot of RAM that probably exceeds the size of your board. The
solution is that your BSP should add:
#define BSP_SMALL_MEMORY 1
within the BSP's include/bsp.h file, e.g.
c/src/lib/libbsp/m68k/mrm332/include/bsp.h or similar.
You can grep for BSP_SMALL_MEMORY to see this.

> 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?
>
To submit a BSP, we mostly require that hello world and ticker run
correctly. These two samples exercise the console and clock drivers,
which is what a basic BSP should provide. Obviously, more working
tests is better, but right now we do not have an authoritative list of
which tests actually are expected to pass/fail. The testing situation
is work-in-progress.

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