Commit Graph

2 Commits

Author SHA1 Message Date
Andy Ross 54ee5f7d89 arch/x86_64: Non-kconfig symbols shouldn't look like kconfig
The lowest level of the x86_64 bit port supports the full 64 bit ABI
just fine, but Zephyr does not (yet) and builds under the x32 ABI
instead.  The xuk layer can be built with or without the -mx32 switch,
and it had a configurable in a header to tell it what it was.  At some
point during development I swept through and turned all those tunables
into kconfigs, but this one wasn't used by zephyr and so it got the
CONFIG_* rename but never had an entry added to a Kconfig file to
match it, and eventually got picked up by Ulf's unused symbol
detector.

Rename back.  It will probably become a kconfig again someday when we
need it.  Fixes #14059.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2019-03-08 06:53:39 -05:00
Andy Ross b69d0da82d arch/x86_64: New architecture added
This patch adds a x86_64 architecture and qemu_x86_64 board to Zephyr.
Only the basic architecture support needed to run 64 bit code is
added; no drivers are added, though a low-level console exists and is
wired to printk().

The support is built on top of a "X86 underkernel" layer, which can be
built in isolation as a unit test on a Linux host.

Limitations:

+ Right now the SDK lacks an x86_64 toolchain.  The build will fall
  back to a host toolchain if it finds no cross compiler defined,
  which is tested to work on gcc 8.2.1 right now.

+ No x87/SSE/AVX usage is allowed.  This is a stronger limitation than
  other architectures where the instructions work from one thread even
  if the context switch code doesn't support it.  We are passing
  -no-sse to prevent gcc from automatically generating SSE
  instructions for non-floating-point purposes, which has the side
  effect of changing the ABI.  Future work to handle the FPU registers
  will need to be combined with an "application" ABI distinct from the
  kernel one (or just to require USERSPACE).

+ Paging is enabled (it has to be in long mode), but is a 1:1 mapping
  of all memory.  No MMU/USERSPACE support yet.

+ We are building with -mno-red-zone for stack size reasons, but this
  is a valuable optimization.  Enabling it requires automatic stack
  switching, which requires a TSS, which means it has to happen after
  MMU support.

+ The OS runs in 64 bit mode, but for compatibility reasons is
  compiled to the 32 bit "X32" ABI.  So while the full 64 bit
  registers and instruction set are available, C pointers are 32 bits
  long and Zephyr is constrained to run in the bottom 4G of memory.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2019-01-11 15:18:52 -05:00