Select CONFIG_SUPPORT_ACPI to allow usage of ACPI tables with RISC-V.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Enable the QEMU firmware interface if ACPI tables are to be supported on
the QEMU platform.
Enable the QFW MMIO interface if the QEMU firmware interface is enabled.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Invoke write_acpi_tables() via EVT_LAST_STAGE_INIT on QEMU except on X86.
X86 calls write_acpi_tables() in write_tables().
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add fields for the location of ACPI tables to the global data.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add fields for the location of ACPI tables to the global data.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move the code related to copying tables from QEMU to a separate code
module.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We have two implementations of write_acpi_tables(). One for writing ACPI
tables based on ACPI_WRITER() entries another based on copying tables from
QEMU.
Create a symbol CONFIG_QFW_ACPI that signifies copying ACPI tables from
QEMU and use it consistently.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use X_DSDT and X_FIRMWARE_CTRL if available.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rebased on -next to use nomap:
Signed-off-by: Simon Glass <sjg@chromium.org>
On non x86 platforms the hardware reduce flag must be set in the FADT
table. Write an error message if the flag is missing.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rebased on -next to use nomap, add hyphens:
Signed-off-by: Simon Glass <sjg@chromium.org>
If field X_FIRMWARE_CTRL is filled, field FIRMWARE must be ignored. If
field X_DSDT is filled, field DSDT must be ignored.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rebased on -next to use nomap:
Signed-off-by: Simon Glass <sjg@chromium.org>
Fields X_FIRMWAE_CTRL and X_DSDT must be 64bit wide. Convert pointers to
to uintptr_t to fill these.
If field X_FIRMWARE_CTRL is filled, field FIRMWARE must be ignored. If
field X_DSDT is filled, field DSDT must be ignored. We should not fill
unused fields.
See the field definitions in chapter "5.2.9 Fixed ACPI Description Table
(FADT)" of the ACPI Specification 6.5.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Standard passage provides for a bloblist to be passed from one firmware
phase to the next. That can be used to pass the devicetree along as well.
Add an option to support this.
Tests for this will be added as part of the Universal Payload work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
At present this code allocates memory when writing the tables and
then unnecessarily adds another memory map when installing it.
Adjust the code to allocate the tables using the normal U-Boot
mechanism. This avoids doing an EFI memory allocation early in
U-Boot, which may use memory that would be overwritten by a
'load' command, for example.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sandbox uses an API to map between addresses and pointers. This allows
it to have (emulated) memory at zero and avoid arch-specific addressing
details. It also allows memory-mapped peripherals to work.
As an example, on many machines sandbox maps address 100 to pointer
value 10000000.
However this is not correct for ACPI, if sandbox starts another program
(e.g EFI app) and passes it the tables. That app has no knowledge of
sandbox's address mapping. So to make this work we want to store
10000000 as the value in the table.
Add two new 'nomap' functions which clearly make this exeption to how
sandbox works.
This should allow EFI apps to access ACPI tables with sandbox, e.g. for
testing purposes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Use the word 'acpi' in this test so that it runs along with all the
other ACPI tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Only the v3 table is supported now, so always use this when installing
the EFI table.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
These tables are a pain since there is no way to handle memory above
4GB. Use SMBIOS3 always.
This should hopefully not create problems on x86 devices, since SMBIOS3
was released seven years ago (2015).
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
All callers handle this alignment, so drop the unnecessary code. This
simplifies things a little.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
EFI does not use the 'anchor string' to determine the SMBIOS table
version, instead preferring to have two separate GUIDs. Use the correct
one, depending on the table version.
Call unmap_system() to balance to the use of map_sysmem()
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This should access arch-specific properties. Fix it and update the
existing usage.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
When the SMBIOS table is written to an address above 4GB a 32-bit table
address is not large enough.
Use an SMBIOS3 table in that case.
Note that we cannot use efi_allocate_pages() since this function has
nothing to do with EFI. There is no equivalent function to allocate
memory below 4GB in U-Boot. One solution would be to create a separate
malloc() pool, or just always put the malloc() pool below 4GB.
- Use log_debug() for warning
- Rebase on Heinrich's smbios.h patch
- Set the checksum for SMBIOS3
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add definition of the SMBIOS 3.0 (64-bit) Entry Point structure.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Move all of this logic into the else clause, since it will not be used
for SMBIOS3
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
In preparation for adding support for SMBIOS3 move this code into an
else statement. There is no functional change.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Documentation updates for endeavoru, lg_x3, grouper and transformers,
addition of MIPI calibration clock name for T114 (inline with T124+),
conversion of TEGRA_SUPPORT_NON_SECURE into Kconfig and endeavoru
stability improvements.
As already done for NOR chips, if device ESIZE and ENVSECTORS static
configurations are both zero, then autodetect them at runtime.
Cc: Joe Hershberger <joe.hershberger@ni.com>
cc: Stefan Agner <stefan@agner.ch>
cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Anthony Loiseau <anthony.loiseau@allcircuits.com>
It's totally valid for read() to provide less bytes than requested
maximum. It may happen if there is no more data available yet or source
pushes data in small chunks.
This actually happens when trying to read env data from NVMEM device.
Kernel may provide NVMEM content in page size parts (like 4096 B).
This fixes warnings like:
Warning on /sys/bus/nvmem/devices/u-boot-env0/nvmem: Attempted to read 16384 bytes but got 4096
Warning on /sys/bus/nvmem/devices/u-boot-env0/nvmem: Attempted to read 12288 bytes but got 4096
Warning on /sys/bus/nvmem/devices/u-boot-env0/nvmem: Attempted to read 8192 bytes but got 4096
Since the main loop in flash_read_buf() is used to read blocks this
patch adds a new nested one.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Rename "addr0" and "addr1" to "buf0" and "buf1" accordingly. Name "addr"
suggests that variable contains a numeric value being some kind of
address. Name "buf" is de facto a standard name for pointer to allocated
memory for reading data to.
While at it drop redundant checks for NULL before calling free().
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Call to fread() was changed to check for return value. The problem is it
can't be checked for returning 1 (as it is) to determine success.
We call fread() with buffer size as "size" argument. Reading any
"compatible" value shorter than buffer size will result in returning 0
even on success.
Modify code to use fstat() to determine expected read length.
This fixes regression that broke using fw_env with NVMEM devices.
Fixes: c059a22b77 ("tools: env: fw_env: Fix unused-result warning")
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Unlike all other supported Tegra devices and most known Tegra devices, the
HTC One X has no hardware way to enter APX/RCM mode, which may lead to a
dangerous situation when, if BCT is set correctly and the bootloader is
faulty, the device will hang in a permanent brick state. Exiting from this
state can be done only by disassembling the device and shortening the
testpad to the ground.
To prevent this or to minimize the probability of such an accident, it was
proposed to add the RCM rebooting hook as early into SPL as possible since
SPL is much more robust and has minimal changes that can break bootflow.
gpio_early_init_uart() function was chosen as it is the earliest function
exposed for setup by the device. Hook performs a check for volume up button
state and triggers RCM if it is pressed.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Manorit Chawdhry <m-chawdhry@ti.com> says:
K3 devices have firewalls that are used to prevent illegal accesses to
memory regions that are deemed secure. The series prevents the illegal
accesses to ATF and OP-TEE regions that are present in different K3
devices.
AM62X, AM62AX and AM64X are currently in hold due to some firewall
configurations that our System Controller (TIFS) needs to handle.
The devices that are not configured with the firewalling nodes will not
be affected and can continue to work fine until the firewall nodes are
added so will be a non-blocking merge.
Test Logs: https://gist.github.com/manorit2001/4cead2fb3a19eb5d19005b3f54682627
CICD Run: https://github.com/u-boot/u-boot/pull/442
This commit adds a general flow to explain the usage of firewalls and
the chain of trust in K3 devices.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
The following commits adds the configuration of firewalls required to
protect ATF and OP-TEE memory region from non-secure reads and
writes using master and slave firewalls present in our K3 SOCs.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Tested-by: Thomas Richard <thomas.richard@bootlin.com>
The following commits adds the configuration of firewalls required to
protect ATF and OP-TEE memory region from non-secure reads and
writes using master and slave firewalls present in our K3 SOCs.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
The following commits adds the configuration of firewalls required to
protect ATF and OP-TEE memory region from non-secure reads and
writes using master and slave firewalls present in our K3 SOCs.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
For readability during configuring firewalls, adding k3-security.h file
and including it in k3-binman.dtsi to be accessible across K3 SoCs
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
We can now firewall entities while loading them through our secure
entity TIFS, the required information should be present in the
certificate that is being parsed by TIFS.
The following commit adds the support to enable the certificates to be
generated if the firewall configurations are present in the binman dtsi
nodes.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Fix the error message to not use dst and use self as it is copying the
properties to self.
While using templating if there are no subnodes defined, we end up in
this situation where "dst" isn't defined and it tries to print the error
message and fails.
'UnboundLocalError: local variable 'dst' referenced before assignment'
Fixes: 55e1278d5e ("dtoc: Allow inserting a list of nodes into another")
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Principle is exactly the same as on T124, testing of register
which behaves differently in secure and non-secure states.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
main_timer0 is used by u-boot as the tick-timer. Add it to the soc
devices list so it an be enabled via the k3 power controller.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
