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.
--
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
