Add arch/arm/mach-keystone/ into K2 board directory MAINTAINERS file.
Convert current entries into regex match style.
Assign maintainership to myself.
Signed-off-by: Andrew Davis <afd@ti.com>
POSIX does not defined longopts for sort, use shortops
for even more compatibility.
Fixes: cc5a490cf4 ("Makefile: Sort u-boot-initial-env output")
Reported-by: Milan P. Stanić <mps@arvanta.net>
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Tested-by: Milan P. Stanić <mps@arvanta.net>
In a few cases we have MAINTAINERS entries that are missing obvious
paths or files. Typically this means a board directory that did not list
itself, but in a few cases we have a Kconfig file or similar.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The listed paths are allowed to contain wildcards. This includes the
'+' character which we have as a literal part of the path in a few
cases. Escape the '+' here so that files are matched.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We have a number of cases where the in-tree path of files and where
they presumably were when the first version of a patch were posted
differ slightly. Correct these to point at where the files are now.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
A number of platforms have "common" directories that are in turn not
listed by the board MAINTAINERS file. Add these directories in many
cases.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The platforms here have been removed, but the common code directory was
forgotten. Clean up.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
These platforms have been removed, but the MAINTAINERS file was missed,
clean up.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This file is in alphabetical order, move CAAM up to where it should be.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This defconfig was added without a MAINTAINERS entry, add one.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This defconfig was added without a MAINTAINERS entry, add one.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We have a few places where defconfigs were added (or renamed) and not
included in their previously listed MAINTAINERS entry, correct this.
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
There are a few entries where minor mistakes mean that we don't match up
with obviously expected files, correct those.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since commit 56670d6fb8 ("disk: part: use common api to lookup part
driver") part_get_info_by_name_type() ignores the part_type parameter
used to restrict the partition table type.
omap_mmc_get_part_size() and part_get_info_by_name() are the only
consumers.
omap_mmc_get_part_size() calls with part_type = PART_TYPE_EFI because at
the time of implementation a speed up could be gained by passing the
partition table type. After 5 years experience without this restriction
it looks safe to keep it that way.
part_get_info_by_name() uses PART_TYPE_ALL.
Move the logic of part_get_info_by_name_type() to part_get_info_by_name()
and replace the function in omap_mmc_get_part_size().
Fixes: 56670d6fb8 ("disk: part: use common api to lookup part driver")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
His entries had the correct email address listed last rather than first,
correct this.
Fixes: 4fa4227cdd (".mailmap: Record all address for main U-Boot contributor")
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Michal Simek <michal.simek@amd.com>
It is not visible anywhere in Trial State if this is the first, second, etc
attempt that's why show a message to be aware about status.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
Code rewrites the last char of size with adding &. It is visible from
dfu_alt_info print before this patch:
Make dfu_alt_info: 'mtd nor0=bank0 raw 2320000 80000;bank1 raw 27a0000
8000&mtd nor0=bank0 raw 23a0000 4000000;bank1 raw 2820000 4000000'
And after it:
Make dfu_alt_info: 'mtd nor0=bank0 raw 2320000 80000;bank1 raw 27a0000
80000&mtd nor0=bank0 raw 23a0000 4000000;bank1 raw 2820000 4000000'
Size for bank0 and bank1 must be the same because it is the same image.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
Current code after capsule update (mtd write) is not changing active_index
in mdata to previous_active_index.
On the reboot this is shown but showing message
"Boot idx 1 is not matching active idx 0, changing active_idx"
which is changing active_idx and writing mdata to flash.
But when this message is visible it is not checking which state that images
are. If they have acceptance bit setup to yes everything is fine and valid
images are booted (doesn't mean the latest one).
But if acceptance bit is no and images are in trial state in_trial variable
is never setup. Which means that from new flashed image stable image can be
rewritten because in_trial is not setup properly.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
In some designs the MAX313xx RTC may need calibration to cope with
oscillator inaccuracies. Provide read8/write8 ops so that the registers
can be accessed. Because the driver covers a range of MAX313xx variants
no attempt is made to ensure the register is valid.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Commit 62649165cb ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
fixed cache alignment for systems with a D-CACHE.
However it introduced some performance regressions [1] on system
flashing huge images, such as Android.
On AM62x SK EVM, we also observe such performance penalty:
Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.954s]
Writing 'super' OKAY [ 75.926s]
Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.641s]
Writing 'super' OKAY [ 62.849s]
Finished. Total time: 182.474s
The reason for this is that we use an arbitrary small buffer
(info->blksz * 100) for transferring.
Fix it by using a bigger buffer (info->blksz * FASTBOOT_MAX_BLK_WRITE)
as suggested in the original's patch review [2].
With this patch, performance impact is mitigated:
Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.912s]
Writing 'super' OKAY [ 15.780s]
Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.581s]
Writing 'super' OKAY [ 17.192s]
Finished. Total time: 76.569s
[1] https://lore.kernel.org/r/20221118121323.4009193-1-gary.bisson@boundarydevices.com
[2] https://lore.kernel.org/r/all/43e4c17c-4483-ec8e-f843-9b4c5569bd18@seco.com/
Fixes: 62649165cb ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
This driver considers that a node with an empty label is the top.
But the led class has changed, if a label is not provided for a led,
the label is filed with the node name. So we update this driver
to use a wrapper to manage the top led node.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Sec proxy data buffer is 60 bytes with the last of the registers
indicating transmission completion. This however poses a bit of a
challenge.
The backing memory for sec_proxy is regular memory, and all sec proxy
does is to trigger a burst of all 60 bytes of data over to the target
thread backing ring accelerator. It doesn't do a memory scrub when
it moves data out in the burst. When we transmit multiple messages,
remnants of previous message is also transmitted which results in
some random data being set in TISCI fields of messages that have been
expanded forward.
The entire concept of backward compatibility hinges on the fact that
the unused message fields remain 0x0 allowing for 0x0 value to be
specially considered when backward compatibility of message extension
is done.
So, instead of just writing the completion register, we continue
to fill the message buffer up with 0x0 (note: for partial message
involving completion, we already do this).
This allows us to scale and introduce ABI changes back also work with
other boot stages that may have left data in the internal memory.
While at this, drop the unused accessor function.
Fixes: f9aa41023b ("mailbox: Introduce K3 Secure Proxy Driver")
Signed-off-by: Nishanth Menon <nm@ti.com>
The default output directory is generally '../' in tests so we end up
trying to create '../.bm-work'. This does not work with azure, so update
these tests to use the temporary directory instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
This reverts commit d927d1a808, reversing
changes made to c07ad9520c.
These changes do not pass CI currently.
Signed-off-by: Tom Rini <trini@konsulko.com>
To quote the author:
Adding support for Arm FF-A v1.0 (Arm Firmware Framework for Armv8-A) [A].
FF-A specifies interfaces that enable a pair of software execution
environments aka partitions to communicate with each other. A partition
could be a VM in the Normal or Secure world, an application in S-EL0, or
a Trusted OS in S-EL1.
FF-A is a discoverable bus and similar to architecture features.
FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
by the PSCI driver.
=> dm tree
Class Index Probed Driver Name
-----------------------------------------------------------
...
firmware 0 [ + ] psci |-- psci
ffa 0 [ ] arm_ffa | `-- arm_ffa
...
Clients are able to probe then use the FF-A bus by calling the DM class
searching APIs (e.g: uclass_first_device).
This implementation of the specification provides support for Aarch64.
The FF-A driver uses the SMC ABIs defined by the FF-A specification to:
- Discover the presence of secure partitions (SPs) of interest
- Access an SP's service through communication protocols
(e.g: EFI MM communication protocol)
The FF-A support provides the following features:
- Being generic by design and can be used by any Arm 64-bit platform
- FF-A support can be compiled and used without EFI
- Support for SMCCCv1.2 x0-x17 registers
- Support for SMC32 calling convention
- Support for 32-bit and 64-bit FF-A direct messaging
- Support for FF-A MM communication (compatible with EFI boot time)
- Enabling FF-A and MM communication in Corstone1000 platform as a use case
- A Uclass driver providing generic FF-A methods.
- An Arm FF-A device driver providing Arm-specific methods and
reusing the Uclass methods.
- A sandbox emulator for Arm FF-A, emulates the FF-A side of the
Secure World and provides FF-A ABIs inspection methods.
- An FF-A sandbox device driver for FF-A communication with the
emulated Secure World. The driver leverages the FF-A Uclass to
establish FF-A communication.
- Sandbox FF-A test cases.
- A new command called armffa is provided as an example of how to
access the FF-A bus
For more details about the FF-A support please refer to [B] and refer to [C] for
how to use the armffa command.
Please find at [D] an example of the expected boot logs when enabling
FF-A support for a platform. In this example the platform is
Corstone1000. But it can be any Arm 64-bit platform.
[A]: https://developer.arm.com/documentation/den0077/latest/
[B]: doc/arch/arm64.ffa.rst
[C]: doc/usage/cmd/armffa.rst
[D]: example of boot logs when enabling FF-A
turn on EFI MM communication
On corstone1000 platform MM communication between u-boot
and the secure world (Optee) is done using the FF-A bus.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Add MM communication support using FF-A transport
This feature allows accessing MM partitions services through
EFI MM communication protocol. MM partitions such as StandAlonneMM
or smm-gateway secure partitions which reside in secure world.
An MM shared buffer and a door bell event are used to exchange
the data.
The data is used by EFI services such as GetVariable()/SetVariable()
and copied from the communication buffer to the MM shared buffer.
The secure partition is notified about availability of data in the
MM shared buffer by an FF-A message (door bell).
On such event, MM SP can read the data and updates the MM shared
buffer with the response data.
The response data is copied back to the communication buffer and
consumed by the EFI subsystem.
MM communication protocol supports FF-A 64-bit direct messaging.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Tested-by: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Add Sandbox test for the armffa command
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Add functional test cases for the FF-A support
These tests rely on the FF-A sandbox emulator and FF-A
sandbox driver which help in inspecting the FF-A communication.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support
Features of the sandbox FF-A support:
- Introduce an FF-A emulator
- Introduce an FF-A device driver for FF-A comms with emulated Secure World
- Provides test methods allowing to read the status of the inspected ABIs
The sandbox FF-A emulator supports only 64-bit direct messaging.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Provide armffa command showcasing the use of the U-Boot FF-A support
armffa is a command showcasing how to invoke FF-A operations.
This provides a guidance to the client developers on how to
call the FF-A bus interfaces. The command also allows to gather secure
partitions information and ping these partitions. The command is also
helpful in testing the communication with secure partitions.
For more details please refer to the command documentation [1].
[1]: doc/usage/cmd/armffa.rst
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0
The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
describes interfaces (ABIs) that standardize communication
between the Secure World and Normal World leveraging TrustZone
technology.
This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
querying the FF-A framework from the secure world.
The driver uses SMC32 calling convention which means using the first
32-bit data of the Xn registers.
All supported ABIs come with their 32-bit version except FFA_RXTX_MAP
which has 64-bit version supported.
Both 32-bit and 64-bit direct messaging are supported which allows both
32-bit and 64-bit clients to use the FF-A bus.
FF-A is a discoverable bus and similar to architecture features.
FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
by the PSCI driver.
Clients are able to probe then use the FF-A bus by calling the DM class
searching APIs (e.g: uclass_first_device).
The Secure World is considered as one entity to communicate with
using the FF-A bus. FF-A communication is handled by one device and
one instance (the bus). This FF-A driver takes care of all the
interactions between Normal world and Secure World.
The driver exports its operations to be used by upper layers.
Exported operations:
- ffa_partition_info_get
- ffa_sync_send_receive
- ffa_rxtx_unmap
Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c).
Arm specific methods are implemented in the Arm driver (arm-ffa.c).
For more details please refer to the driver documentation [2].
[1]: https://developer.arm.com/documentation/den0077/latest/
[2]: doc/arch/arm64.ffa.rst
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
provide a test case
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
convert UUID string to little endian binary data
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
add support for x0-x17 registers used by the SMC calls
In SMCCC v1.2 [1] arguments are passed in registers x1-x17.
Results are returned in x0-x17.
This work is inspired from the following kernel commit:
arm64: smccc: Add support for SMCCCv1.2 extended input/output registers
[1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6?token=
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
binman TI support
binman cipher support
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmS+wz8RHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreZJFgf5AQndwI5yzs/R0HqqPjeYwKclYmn/4aqc
AqWQU9fv3ZHcmFvdAp68PxMas5zYzJvc7az6sVOechmglFXmBj+cU9sM2LL6Ulre
WjOa3yypsOxLgIga5DYDa3t3wNnoy3Yqt1TZejpfHYPNraFWFJpHCF0uSSWIBlPr
8RpCuNtsFlRlTOcXWxew+ms4dtSJ7fIyX1PMIkhFXrYiJUtcdZ6YkG1BSnScqx80
ZG/JquGmeqnkejZ608QP0SBubct02oBfhkYEmfM87Eoz2GnfRpeARoiqohSYrBWM
9Ji9T6FQBO4iLHOnETO86YG/jlwb/CP+hUdswpcrcmlpwRxLGWIraA==
=IzFg
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-24jul23' of https://source.denx.de/u-boot/custodians/u-boot-dm
buildman refactoring and --maintainer-check
binman TI support
binman cipher support
- Actually merge the assorted K3 platform improvements that were
supposed to be in commit 247aa5a191 ("Merge branch
'2023-07-21-assorted-TI-platform-updates'")
In poking around it seems that many boards don't define a CONFIG_TARGET
Kconfig variable. This is not strictly necessary, but add an option to
buildman so these can be viewed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Change -D to mean --debug for consistency with other tools. This is not a
commonly used option, so the impact should be minimal.
Signed-off-by: Simon Glass <sjg@chromium.org>
