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 <j...@rtems.org> wrote: > > > On Tue, Dec 8, 2015 at 9:49 AM, Gedare Bloom <ged...@rtems.org> wrote: >> >> On Tue, Dec 8, 2015 at 10:45 AM, Joel Sherrill <j...@rtems.org> wrote: >> > >> > >> > On Tue, Dec 8, 2015 at 9:09 AM, Sebastian Huber >> > <sebastian.hu...@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.hu...@embedded-brains.de >> >> PGP : Public key available on request. >> >> >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> >> >> > >> > >> > _______________________________________________ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
