AW: AW: SMP for pc686 BSP

[Jan.Sommer at dlr.de]

> -----Ursprüngliche Nachricht-----
> Von: Sebastian Huber [mailto:sebastian.huber at embedded-brains.de]
> Gesendet: Freitag, 17. Mai 2019 07:00
> An: Chris Johns; Sommer, Jan; joel at rtems.org
> Cc: devel at 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.huber at embedded-brains.de
> PGP     : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.