> -----Ursprüngliche Nachricht----- > Von: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] > Gesendet: Freitag, 17. Mai 2019 07:00 > An: Chris Johns; Sommer, Jan; j...@rtems.org > Cc: devel@rtems.org > Betreff: Re: AW: SMP for pc686 BSP > > On 17/05/2019 04:26, Chris Johns wrote: > >> Is it this ticket?:https://devel.rtems.org/ticket/2183 > >> I looked at the changes from Sebastian and updated the cpu_asm.S to be > more close to the one of the ARM architecture. > >> I haven't been able to test that in detail yet, because some troubles in > getting the APs to properly boot. > >> > >> For me the biggest open question atm is 3.) regarding what to do with > the GDTs. At the moment I lean towards option 3b and adding the > information to the per_CPU structure, because it seems pretty easy. > >> In common setups this would increase the structure by 48 bytes > additional space (8 bytes for NULL, text, data, gs and 2 user sections). > >> Would that be a problem? > > Does cpukit/include/rtems/score/percpudata.h help? > > > > I am not sure how this is put together but the comments at the top of the > file > > seem to indicate this exists for this type of purpose. It looks pretty neat. > > Optional components should use the <rtems/score/percpudata.h> API for > per-processor data. Per-processor data required by the CPU port should > use CPU_Per_CPU_control defined in <rtems/score/cpuimpl.h>. See arm, > riscv and sparc for examples. >
Thanks, that's what I found as well. Then I will go down that route. > -- > 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