This board got forgotten when we migrated the older APIC_TIMER users.
Now the platform is SMP by default and the older driver refuses to
build.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
ACRN build and configuration is non-trivially complicated, and so far
integration documentation has been mostly missing, and users have had
to get by via copying from existing integration efforts with minor
changes, leading to repeated mistakes and persistent confusion. This
is an attempt to document the process from first principles, with an
eye toward informing integrators (not me!) who might come by later to
better automate things. Some of the content is going to look remedial
to someone already familiar with e.g. ACRN configuration or EFI boot.
This simply replaces the pre-existing docs, which were for earlier
versions of ACRN where Zephyr was launched from the service OS instead
of the now-standard pre-launch VM mode.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
SMP is working now, make a 2-cpu configuration default for this
device.
Note that this requires changes to the default ACRN build
configuration! In hybrid.xml, you need to specify multiple physical
CPUs for the VM to uses, e.g.:
<vm id="0">
...
<cpu_affinity>
<pcpu_id>0</pcpu_id>
<pcpu_id>1</pcpu_id>
</cpu_affinity>
</vm>
Failing to build with this change will result in the system hanging at
boot trying to start up a CPU that won't run.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The ACRN hypervisor uses 0, 2, 4, 6 as its local APIC IDs for
virtualized CPUs and not the 0, 1, 2, 3 defaults we have.
(I hate this feature, having to manually (!) probe and code these
things in C isn't scaling. Zephyr needs to do the probing on its own
somehow, even if it's an offline tool in Linux or something.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Remove minnowboard configuration which is very basic and can be brought
back by just taking another X86 configuration. We have not tested this
board for a while and it is not being used actively, so remove it.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This board was added to test coverage feature when coverage was
introduced. This is now being testing with other boards and
configurations on a regular basis, so no need for this extra overhead in
CI.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The board moved to using APIC TSC Deadline Timer driver, which
removes the need for these configurations associated with
the older Apic timer driver (CONFIG_APIC_TIMER).
Signed-off-by: Jennifer Williams <jennifer.m.williams@intel.com>
This enables the kconfig options so that the board would be
using boot and pinned linker sections.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Cleanup along the same lines as the last change to APL/up_squared.
Make sure all hardware configuration is at the board level where it
belongs and not in the soc, don't play games with defaulting timer
drivers. Unify the configuration where possible and make it clearer
which setting goes with which driver.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The addition of a timer driver made a messy situation worse. Move
board-level configuration like clock rates and dividers into the board
and don't try to default it in the soc. Make it clear which kconfig
goes with which driver. Likewise don't try to do driver selection in
the soc, the board (or app) is in a better position to choose.
Also clean up and better unify the up_squared 32/64 bit settings.
Really only CONFIG_BOARD_NAME needs to care about the difference
between these devices.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Since CONFIG_KERNEL_VM_OFFSET no longer needs to be the same as
CONFIG_SRAM_OFFSET, set it to zero to reclaim the hole in
virtual address space.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The acrn_ehl_crb used the APIC timer but did not configure the TSC
M and N parameters, which are advised where available. This adds
the values consistent with native (ehl_crb) definition.
Signed-off-by: Jennifer Williams <jennifer.m.williams@intel.com>
The GSG link is no longer valid. This commit fixes the link to
use the site recommended by ACRN developers.
Fixes#34149
Signed-off-by: Jennifer Williams <jennifer.m.williams@intel.com>
The default APIC_TIMER_IRQ of 24 causes significant slowdown
in general tests and samples execution on this board. As the
value of ioapic RTEs increases, e.g. 48 in ACRN EHL CRB, the
APIC TIMER IRQ is stepped on. This commit tunes the config
for APIC_TIMER_IRQ to 48 for this board.
Fixes#33593
Signed-off-by: Jennifer Williams <jennifer.m.williams@intel.com>
Work around the fact that llvm objcopy does not support --gap-fill right
now. This should be done on the toolchain level at some point, it is
currently not possible however.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The linker script has been updated to have correct load address
in the ELF file, so there is no need for the horrible hack.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
There is no need to use this kconfig, as the phys-to-virt
offset is enough to figure out if the kernel is linked in
virtual address space in gen_mmu.py.
For code, use Z_VM_KERNEL instead.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This adds a new qemu_x86_virt board where code and data are
mapped in virtual address space and is actually executing within
virtual address space.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This changes x86 to use CONFIG_SRAM_OFFSET instead of
arch-specific CONFIG_X86_KERNEL_OFFSET. This allows the common
MMU macro Z_BOOT_VIRT_TO_PHYS() and Z_BOOT_PHYS_TO_VIRT() to
function properly if we ever need to map the kernel into
virtual address space that does not have the same starting
physical address.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This driver emulates a EEPROM device in flash.
Reworked implementation with modified flash layout.
The emulation represents the EEPROM in flash as a region that is a
direct map of the eeprom data followed by a region where changes to
the eeprom data is stored. Changes are written as address-data
combinations. The size of such a combination is determined by the
flash write block size and the size of the eeprom (required address
space), with a minimum of 4 byte.
The eeprom page needs to be a multiple of the flash page. Multiple
eeprom pages is also so supported and increases the number of writes
that can be performed.
The eeprom size, pagesize and the flash partition used for the eeprom
are defined in the dts. The flash partition should allow at least two
eeprom pages. For fast read access a rambuffer can be enabled for the
eeprom (by setting the option rambuf in the dts).
Signed-off-by: Laczen JMS <laczenjms@gmail.com>
All x86 QEMU boards have a hard-coded memory size of 9MB which
does not corresponding with what is defined in device tree.
So make use of CONFIG_SRAM_SIZE to provide correct memory size.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
QEMU provides multiboot information by default so we can
use the provided memory map to mark reserved physical
memory. Note that 64-bit requires Multiboot2 which
currently both Zephyr and QEMU do not support, hence
it's not enabled for qemu_x86_64.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The default KERNEL_VM_SIZE if ACPI=y is too large for QEMU targets
which results in page tables being too big to fit in available
memory. So limit the VM size to a more reasonable one.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
These were removed in commit 6b58e2c0a3
but mistakenly reintroduced in
commit 51c34bb609
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Add a new Kconfig CONFIG_BUILD_OUTPUT_EFI and select that for boards
that want to generate an EFI application.
Make qemu_x86_64 also generate an EFI file, however do not enable this
by default yet.
Goal is to boot qemu using EFI to be able to test this path in the
future.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
We've already enabled full RAM mapping if ACPI is enabled, also
set a large 3GB address space size, these systems are not RAM-
constrained (they are PC platforms) and they have large MMIO
config spaces for PCIe.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
With SDK 0.12.2 we have support to generation EFI binaries in binutils
which is needed by the zefi.py script. Now that is there we can utilize
the SDK objcopy instead of assuming the host objcopy can do this (which
would only be the case on x86 linux host systems).
Fixes#27047
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
These are all PC systems which have large amounts of memory
which needs to be mapped at runtime (most are 2GB).
Increase the address space size accordingly, adding an extra
8MB for mappings.
The ACRN target has 8MB, give it 16MB of VM.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We no longer use a page pool to draw memory pages when doing
memory map operations. We now preallocate the entire virtual
address space so no allocations are ever necessary when mapping
memory.
We still need memory to clone page tables, but this is now
expressed by a new Kconfig X86_MAX_ADDITIONAL_MEM_DOMAINS
which has much clearer semantics than specifying the number
of pages in the pool.
The default address space size is now 8MB, but this can be
tuned by the application.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Just tell the kernel that RAM starts 1MB in, period.
Better simulation of a low-memory microcontroller as
we're not managing a very large number of page frames
we'll never use.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
When zefi.py was changed to pass compiler and objcopy the flag to
objcopy for the EFI target was dropped. This is because the current
SDK (0.12.1) doesn't support that target type for objcopy. However,
target is necessary for the images to be created correctly and boot.
Switch back to use the host objcopy as a stop gap fix, until the SDK
can support target for EFI.
Fixes: #31517
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We no longer use a page pool to draw memory pages when doing
memory map operations. We now preallocate the entire virtual
address space so no allocations are ever necessary when mapping
memory.
We still need memory to clone page tables, but this is now
expressed by a new Kconfig X86_MAX_ADDITIONAL_MEM_DOMAINS
which has much clearer semantics than specifying the number
of pages in the pool.
The default address space size is now 8MB, but this can be
tuned by the application.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Just tell the kernel that RAM starts 1MB in, period.
Better simulation of a low-memory microcontroller as
we're not managing a very large number of page frames
we'll never use.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Johan Hedberg