Debugging broken BSP suggestions?

Wed Mar 12 14:27:05 UTC 2014

On 3/12/2014 9:09 AM, Gedare Bloom wrote:
> 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.
Also if the BSP is low on memory -- especially code space -- it may make
sense to
use -Os instead of -O2.

And (on the head), we have seen on the sparc BSPs, that per function
sections
can have a significant impact on executable size. The tests dropped ~45% on
average in code size.  This requires tinkering with the compiler arguments,
linker arguments, and linkcmds to add KEEP.

But if you have hello and ticker working, it is just a matter of keeping
them working. 
These are mechanical changes that can break things but if you start from
a known
good, it isn't hard.
>> 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
>>>>>>>
>>>

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