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