Debugging broken BSP suggestions?

Wed Mar 12 18:03:14 UTC 2014

Hi Joel,

On 13 March 2014 03:27, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:

>
> On 3/12/2014 9:09 AM, Gedare Bloom wrote:
> > 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.
>

This board has 512k of RAM and 512k of flash, some of which is already used
by CPU32Bug so it's definitely going to be smaller than what most modern
BSP's target.

I'll have a play with the compiler options as you suggest and see if I
can't get the code size down a bit.

Cheers,
James

>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20140313/6c980f4e/attachment-0001.html>