At present cli_simple_process_macros() requires that the caller provide
an output buffer that is exactly CONFIG_SYS_CBSIZE bytes in length. This
makes sense since it is designed to be used from the command line. But we
also want to use it for bootargs substitution.
Update the function to allow the caller to specify the buffer size. Also
return an error if the buffer is exhausted. The caller can ignore that if
preferred.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present zimage does its own command-line processing and does not
support the 'silent console' feature. There doesn't seem to be any good
reason for this.
Add support for silent console to zimage.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we only support updating the 'bootargs' environment
variable. Add another function to update a buffer instead. This will
allow zimage to use this feature.
Also add a lot more tests to cover various cases.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present only one transformation is supported: making the Linux console
silent. To prepare for adding more, convert the boolean parameter into a
flag value.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present bootm_process_cmdline_env() reads the 'bootargs' variable and
then writes it back afterwards. This is painful for tests, which would
rather use a simple buffer.
It is also useful for zimage to use a buffer, since it does not actually
put the Linux command line in the bootargs variable.
Refactor the existing code into two pieces. One handles reading and
writing the environment variable, as well as allocating a buffer for use
by the rest of the code, which now operates on a buffer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the size (including terminator) for in this function, rather than
the length. This is arguably easier to follow, with the coming
refactor.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function will soon do more than just handle the 'silent linux'
feature. As a first step, update it to take a boolean parameter,
indicating whether or not the processing is required.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to add more processing to this function. Before doing so, rename
it to bootm_process_cmdline_env(), which is more generic.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this function fails silently on error. Update it to produce
an error code. Report this error to the user and abort the boot, since it
likely will prevent a successful start.
No tests are added at this stage, since additional refactoring is taking
place in subsequent patches.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function currently has no tests. Export it so that we can implement
a simple test on sandbox. Use IS_ENABLED() to remove the unused code,
instead #ifdef.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this function returns 1 on success and 0 on failure. But in
the latter case it provides no indication of what went wrong.
If an attempt is made to delete a non-existent variable, the caller may
want to ignore this error. This happens when setting a non-existent
variable to "", for example.
Update the function to return 0 on success and a useful error code on
failure. Add a function comment too.
Make sure that env_set() does not return an error if it is deleting a
variable that doesn't exist. We could update env_set() to return useful
error numbers also, but that is beyond the scope of this change.
Signed-off-by: Simon Glass <sjg@chromium.org>
wip
The BL31 expects the GIC to be uninitialized. Thus, if we are loading
the BL31 by the SPL we must not initialize it. If u-boot is loaded by
the SPL directly, it will initialize the GIC again (in the same
lowlevel_init()).
This was tested on a custom board with SPL loading the BL31 and jumping
to u-boot as BL33 as well as loading u-boot directly by the SPL. In case
the ATF BL1/BL2 is used, this patch won't change anything, because no
SPL is used at all.
Signed-off-by: Michael Walle <michael@walle.cc>
bl2_to_bl31_params_mem is just an implementation detail of the SPL ATF
support and is not needed anywhere else. Move it from the header to the
actual module.
Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Move the actual implementation of the bl2_plat_get_bl31_params() to its
own function. The weak function will just call the default
implementation. This has the advantage that board code can still call
the original implementation if it just want to modify minor things.
Signed-off-by: Michael Walle <michael@walle.cc>
There is no need to have the storage available globally. This is also a
preparation for LOAD_IMAGE_V2 support. That will introduce a similar
generator function which also has its own storage.
Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Michal Simek <michal.simek@xilinx.com>
There is SPL_ARMV8_SEC_FIRMWARE_SUPPORT and ARMV8_SEC_FIRMWARE_SUPPORT.
Thus use CONFIG_IS_ENABLED() instead of the simple #ifdef.
Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Activate ARCH_SUPPORT_PSCI as other TEGRA124 target and remove
CONFIG_ARMV7_PSCI and CONFIG_ARMV7_PSCI_NR_CPUS in configs file as they
are migrated in Kconfig.
Select CONFIG_ARMV7_PSCI_0_1 (the first PSCI version),
because CONFIG_ARMV7_PSCI_0_2 and CONFIG_ARMV7_PSCI_1_0
are not activated in this product.
Hi,
This patch depend on the previous serie [1].
I don't test this patch on real hardware but
after this patch the size of the binary don't change.
In .config we have:
CONFIG_ARCH_SUPPORT_PSCI=y
CONFIG_ARMV7_PSCI=y
# CONFIG_ARMV7_PSCI_1_0 is not set
# CONFIG_ARMV7_PSCI_0_2 is not set
CONFIG_ARMV7_PSCI_0_1=y
CONFIG_ARMV7_PSCI_NR_CPUS=4
In u-boot.cfg, this patch only add the 2 lines
#define CONFIG_ARCH_SUPPORT_PSCI 1
#define CONFIG_ARMV7_PSCI_0_1 1
[1] "Convert CONFIG_ARMV7_PSCI_1_0 and CONFIG_ARMV7_PSCI_0_2 to Kconfig"
http://patchwork.ozlabs.org/project/uboot/list/?series=184029
Regards
Patrick
END
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Peter Chubb <peter.chubb@data61.csiro.au>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Upstream linux DT naming doesn't align with the U-Boot DT, which may
not always be the case so this allows using BOOTENV_EFI_SET_FDTFILE_FALLBACK
where it might be appropriate for some boards.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
For booting via UEFI we need to define the fdtfile option so
bootefi has the option to load a fdtfile from disk. For arm64
the kernel dtb is located in a vendor directory so we define
that as nvidia for that architecture.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Use gpio_early_init_uart() function to disable RS232 serial transceiver
ForceOFF# pins on Iris.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Avoid UART input from floating RX pins on UARTB and UARTC (Colibri T30)
and UARTB, UARTC and UARTD (Apalis T30).
Note: Floating pins may cause spurious break conditions potentially
interrupting U-Boot's autoboot.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@toradex.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Fix SPI1 and UART2/3 resp. UARTB/C pinmuxing.
Note: The former was illegally muxing multiple SoC balls onto the same
internal SoC signal which caused rather strange behaviour regarding
the RS232 serial transceiver ForceOFF# pins as available on Iris.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@toradex.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add pinmuxing comment stating that TRISTATE means the output driver is
tri-stated and INPUT means the input driver is enabled vs. OUTPUT where
it is disabled.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@toradex.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This pull request adds:
* eventlog support for TCG2_PROTOCOL
* UEFI capusule updates
It replace printf by log in efi_uclass.c
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAl/JSfkACgkQxIHbvCwF
GsTKdQ//bCWxe24Qm8h1OeyfNYmHroPWtIHJuDqaPLzoWIF2JkhGE7U1o7IC9ISZ
m/UV/y4TpsGr47an5XSs3CaPaaRABsMcg3vF8wL8yjj8ll4Jj1ubm6wUzZjPncjJ
WnFvY4GXettStOiU2l9DZHheQnwbjEsfv9UcLCMHn2facNzkVpg2sQDq2yrXCacT
z6cG2MrYtUI09zuJzL+wAbn1SZ0OQ5pIWA/6vnxO66CTuaaC90pfZbYGE3NPAjSZ
Ck6naS8nuaGrIFzxexDZPaibuRE1mpMbg0qveH4NZJHPyVHssiv04T3p2oWizJpi
OWfrwFuTgA7d2AmV1Hr3f7e5vbdj8mB1mTk6Q+8NnOziSWIf1kj3grfkmV4Pvw55
jj/zg9gOsDWXqUZ4EOLSEpN7WOEqlZ/CVexxbEq+We+P3w6Wc19BSya8dtr04NRa
n+h27OW1msboiYSZvuwpYvLo2uQJV+60KMbMgxpHKS5/2PrbRihXhzHUD8Wl7Uyb
6lUN6L5wFNDExHGAqG0hGR0v/X6Gb60klLPFjcxbVH9ckJSU93FoHtYsvrdPhs19
/kpZ/TPap0A6VxXWnbmKFSPg/CtAGW96utK2bpmORaEcfrlLDMQuHNnajU41FFYQ
2AGKpmWm5fmyO1XmhoZl39XMgHEr9ZnY7iHdYrNEt8fvJ+6zGgg=
=1uwi
-----END PGP SIGNATURE-----
Merge tag 'efi-next' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi into next
Pull request for UEFI sub-system for next
This pull request adds:
* eventlog support for TCG2_PROTOCOL
* UEFI capusule updates
It replace printf by log in efi_uclass.c
The test can run on sandbox build and it attempts to execute a firmware
update via a capsule-on-disk, using a raw image capsule,
CONFIG_EFI_CAPSULE_RAW.
To run this test successfully, you need configure U-Boot specifically;
See test_capsule_firmware.py for requirements, and hence it won't run
on Travis CI, at least, for now.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
The test can run on sandbox build and it attempts to execute a firmware
update via a capsule-on-disk, using a FIT image capsule,
CONFIG_EFI_CAPSULE_FIT.
To run this test successfully, you need configure U-Boot specifically;
See test_capsule_firmware.py for requirements, and hence it won't run
on Travis CI, at least, for now.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
This is a utility mainly for test purpose.
mkeficapsule -f: create a test capsule file for FIT image firmware
Having said that, you will be able to customize the code to fit
your specific requirements for your platform.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
"efidebug capsule" is more or less a debugging utility.
efidebug capsule update: invoke UpdateCapsule against data on memory
efidebug capsule show: show a capsule header
efidebug capsule result: dump a capsule result variable
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
In this commit, a very simple firmware management protocol driver
is implemented. It will take a binary image in a capsule file and
apply the data using dfu backend storage drivers via dfu_write_by_alt()
interface.
So "dfu_alt_info" variable should be properly set to specify a device
and location to be updated. Please read README.dfu.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
In this commit, a very simple firmware management protocol driver
is implemented. It will take a common FIT image firmware in a capsule
file and apply the data using dfu backend storage drivers via
update_fit() interface.
So "dfu_alt_info" variable should be properly set to specify a device
and location to be updated. Please read README.dfu.
Fit image is a common file format for firmware update on U-Boot, and
this protocol works neatly just as a wrapper for one.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
A capsule tagged with the guid, EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID,
is handled as a firmware update object.
What efi_update_capsule() basically does is to load any firmware management
protocol (or fmp) drivers contained in a capsule, find out an appropriate
fmp driver and then invoke its set_image() interface against each binary
in a capsule.
In this commit, however, loading drivers is not supported.
The result of applying a capsule is set to be stored in "CapsuleXXXX"
variable, but its implementation is deferred to a fmp driver.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Memory range capsule gives us a way to notify that some memory regions
should be left untouched across the next reset.
See UEFI specification, section 8.5.3.
Since how we should handle this kind of capsule is totally up to
the system, no implementation will be added in this commit.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Capsule data can be loaded into the system either via UpdateCapsule
runtime service or files on a file system (of boot device).
The latter case is called "capsules on disk", and actual updates will
take place at the next boot time.
In this commit, we will support capsule on disk mechanism.
Please note that U-Boot itself has no notion of "boot device" and
all the capsule files to be executed will be detected only if they
are located in a specific directory, \EFI\UpdateCapsule, on a device
that is identified as a boot device by "BootXXXX" variables.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
In this commit, skeleton functions for capsule-related API's are
added under CONFIG_EFI_UPDATE_CAPSULE configuration.
Detailed implementation for a specific capsule type will be added
in the succeeding patches.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Since update_flash() is used only in update_tftp(), it should be
guarded with appropriate config options.
After the commit 3149e524fc, common/update.c will be built under
either CONFIG_UDATE_TFTP, CONFIG_DFU_TFTP or CONFIG_UPDATE_FIT.
Since CONFIG_UPDATE_FIT, hence fit_update(), doesn't rely on
update_flash(), the compiler may cause an "unused" warning if
CONFIG_UPDATE_FIT=y and CONFIG_UPDATE_TFTP=n and CONFIG_DFU_TFTP=n.
This is, for example, the case for sandbox defconfig where
EFI_CAPSULE_FIRMWARE_FIT is enabled for test purpose.
Fixes: 3149e524fc ("common: update: add a generic interface for FIT
image")
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
A previous commit is adding EFI_TCG2_PROTOCOL, which in it's eventlog
support registers an EFI configuration table.
Let's add the necessary GUID so 'efidebug table' command can display
table names properly.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
In the previous patches we only introduced a minimal subset of the
EFI_TCG2_PROTOCOL protocol implementing GetCapability().
So let's continue adding features to it, introducing the
GetEventLog() and HashLogExtendEvent() functions.
In order to do that we first need to construct the eventlog in memory,
specifically in EFI_BOOT_SERVICES_DATA memory and a configuration table
from EFI_ACPI_MEMORY_NVS.
U-Boot won't currently add any events to the log or measure any
components, but will expose the necessary EFI APIs for applications
to do so.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
A following patch introduces support for the EFI_TCG2_PROTOCOL
eventlog management.
Introduce the necessary tpm related headers
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The current tpm2_pcr_extend is hardcoded using SHA256.
Let's make the actual command to the TPM2 configurable so we can support
a wider range of algorithms and keep the current command line as-is i.e
limited to SHA256 only
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use logging functions instead of printf() and debug().
Change logging messages for uclass creation and destruction to log_debug().
Reported-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
This was used for a board which is not supproted anymore and can
therefore be dropped.
CC: Stefan Roese <sr@denx.de>
Signed-off-by: Holger Brunck <holger.brunck@hitachi-powergrids.com>
Reviewed-by: Stefan Roese <sr@denx.de>
This option is obsolete since 2009 and can be removed globally.
CC: Stefan Roese <sr@denx.de>
Signed-off-by: Holger Brunck <holger.brunck@hitachi-powergrids.com>
Reviewed-by: Stefan Roese <sr@denx.de>
The Kontron SMARC-sAL28 board uses that flash.
This is the same change as in the linux commit f3418718c0ec ("mtd:
spi-nor: Add support for w25q32jwm").
Signed-off-by: Michael Walle <michael@walle.cc>
Reported-by: Leo Krueger <leo.krueger@zal.aero>
