Linker Set Based Initialization

Gedare Bloom gedare at rtems.org
Tue Dec 8 16:49:05 UTC 2015


We can also route student questions to here if we don't know the answers.

On Tue, Dec 8, 2015 at 11:07 AM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> On Tue, Dec 8, 2015 at 9:49 AM, Gedare Bloom <gedare at rtems.org> wrote:
>>
>> On Tue, Dec 8, 2015 at 10:45 AM, Joel Sherrill <joel at rtems.org> wrote:
>> >
>> >
>> > On Tue, Dec 8, 2015 at 9:09 AM, Sebastian Huber
>> > <sebastian.huber at embedded-brains.de> wrote:
>> >>
>> >> On 08/12/15 16:03, Joel Sherrill wrote:
>> >>>
>> >>> What BSPs/architectures have you tested?
>> >>
>> >>
>> >> I temporarily moved the splinkersets01 test to the samples/ticker and
>> >> tested that all BSPs build and link this test.
>> >>
>> >> I executed the splinkersets01 test on sis, psim and
>> >> arm_realview_pbx_a9_qemu.
>> >>
>> >>>
>> >>> Is this something that breaks on a per BSP basis? or per architecture
>> >>> basis?
>> >>> I am assuming that since it is linker based, each BSP could have
>> >>> broken
>> >>> linkcmds.
>> >>> Is that right?
>> >>
>> >>
>> >> It breaks on a per linker command file basis. Since all the maintained
>> >> BSPs use a linkercmds.base, which shouldn't be a big issue.
>> >>
>> >
>> > That means a LOT of the BSPs are broken. You have defined maintained in
>> > your
>> > own way.
>> > There are only a handful of architectures with linkcmds.base in them:
>> >
>> > ./or1k/shared/startup/linkcmds.base
>> > ./arm/shared/startup/linkcmds.base
>> > ./m68k/shared/startup/linkcmds.base
>> > ./powerpc/tqm8xx/startup/linkcmds.base
>> > ./powerpc/gen5200/startup/linkcmds.base
>> > ./powerpc/shared/startup/linkcmds.base
>> > ./sparc/shared/startup/linkcmds.base
>> >
>> > I am not sure how many BSPs within arm, m68k, or powerpc actually use
>> > the
>> > linkcmds.base.
>> >
>> > By my count, 13 of 94 BSP families have linkcmds.base.
>> >
>> >>
>> >> For requirements on the linker command file, see new chapter in user
>> >> manual. However BSPs should not deal with this in copy and paste linker
>> >> command files and instead use a linkercmds.base file.
>> >>
>> >
>> > So 85% of the BSP families don't use linkcmds.base and by the above
>> > statement,
>> > they must immediately be migrated to linkcmds.base.
>> >
>> > Unless you have a plan to address this problem, I am on the side of
>> > rejecting the
>> > part of this patch that changes the initialization.  And the issue must
>> > be
>> > addressed
>> > before this can be merged.
>> >
>> How hard to make updating 1 BSP as a GCI task? Sebastian to mentor... ;-)
>>
>
> Each architecture needs at least one linkcmds.base. I suspect Sebastian
> has to create that for each architecture since is harder.
>
> From there it should be possible for him to write instructions to convert
> a single BSP. Doing a single BSP family should make a nice sized GCI
> task.
>
> Worst case, if they all don't get done, we have a check list and
> instructions
> to work through after the holidays.
>
> Someone (hint Sebastian) must write the GCI instructions and do the
> base work. Then we need a list of BSP families that need to be converted.
> After that, Gedare or I should be able to generate the set of tasks to
> import into the GCI website.
>
> I would prefer that Sebastian co-mentor these so he can answer at least
> the questions on the initial tasks students do. The questions should be
> repetitive after a bit so improving instructions and other mentors knowing
> the information should allow others to help.
>
>>
>> >>
>> >>
>> >> --
>> >> Sebastian Huber, embedded brains GmbH
>> >>
>> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> >> Phone   : +49 89 189 47 41-16
>> >> Fax     : +49 89 189 47 41-09
>> >> E-Mail  : sebastian.huber at embedded-brains.de
>> >> PGP     : Public key available on request.
>> >>
>> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> >>
>> >
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>
>



More information about the devel mailing list