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>
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>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
The macros are prefixed with DM_FLAG_, not DM_FLAGS_.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add dev_read_addr_size_index_ptr function with the same functionality as
dev_read_addr_size_index, but instead a return pointer is given.
Use map_sysmem() function as cast for the return.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This reverts commit d927d1a808, reversing
changes made to c07ad9520c.
These changes do not pass CI currently.
Signed-off-by: Tom Rini <trini@konsulko.com>
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>
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>
The behaviour of dev_read_addr_size() is surprising as it does not
handle #address-cells and #size-cells but instead hardcodes the values
based on sizeof(fdt_addr_t).
This is different from dev_read_addr_size_index() and
dev_read_addr_size_name() both of which do read the cell sizes from the
device tree.
Since dev_read_addr_size() is only used by a single driver and this
driver is broken when CONFIG_FDT_64BIT does not match the address size
in the device tree, fix the function to behave like all of the other
similarly named functions. Drop the property name argument as the only
caller passes "reg" and this is the expected property name matching the
other similarly named functions.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # chromebook_jerry
Tested-by: Simon Glass <sjg@chromium.org> # chromebook_bob
At present livetree can only be used for the control FDT. It is useful
to be able to use the ofnode API for other FDTs, e.g. those used by
the upcoming configuration editor.
We already have most of the support present, and tests can be marked with
the UT_TESTF_OTHER_FDT flag to use another FDT as a special case. But
with this change, the functionality becomes more generally available.
Plumb in the require support.
Signed-off-by: Simon Glass <sjg@chromium.org>
Ensure that the block of memory used by live tree is aligned according to
the default for structures. This ensures that the root node appears at
the start of the block, so it can be used with free(), rather than being
4 bytes later in some cases.
This corrects a rather obscure bug in unflatten_device_tree().
Fixes: 8b50d526ea ("dm: Add a function to create a 'live' device tree")
Signed-off-by: Simon Glass <sjg@chromium.org>
Remove the platform data header because its content is only used by the
driver.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Add devfdt_get_addr_size_index_ptr function with the same
functionality as devfdt_get_addr_size_index, but instead
a return pointer is given.
Suggested-by: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When fdt_addr_t and phys_addr_t are split it turns out that
the header don't match the functions, so fix the headers.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Correct the function documentation.
Fixes: ca031c0827 ("dm: core: introduce uclass_get_device_by_of_path()")
Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a new simple uclass for extcon. Currently all setup is done
in the probe. Uclass struct and ops are empty for now.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
There's quite a few instances of board-specific code doing
off = fdt_path_offset(gd->fdt_blob, ...);
...
ret = uclass_get_device_by_of_offset(..., off, &dev);
looking for an eeprom or a pmic via some alias. Such code can be
simplified a little if we have a helper for directly getting a device
via device tree path (including being given as an alias).
Implement it in terms of ofnode rather than raw offsets so that this
will work whether live tree is enabled or not.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
add block storage emulation for NVM XIP flash devices
Some paltforms such as Corstone-1000 need to see NVM XIP raw flash
as a block storage device with read only capability.
Here NVM flash devices are devices with addressable
memory (e.g: QSPI NOR flash).
The implementation is generic and can be used by different platforms.
Two drivers are provided as follows.
nvmxip-blk :
a generic block driver allowing to read from the XIP flash
nvmxip Uclass driver :
When a device is described in the DT and associated with
UCLASS_NVMXIP, the Uclass creates a block device and binds it with
the nvmxip-blk.
Platforms can use multiple NVM XIP devices at the same time by defining a
DT node for each one of them.
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Provide the basic HSCIF support for R-Car SoC.
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: Fill in HSSRR offset for Gen2 and SCBRR calculation for Gen2 and Gen3]
Reviewed-by: Simon Glass <sjg@chromium.org>
blkmaps are loosely modeled on Linux's device mapper subsystem. The
basic idea is that you can create virtual block devices whose blocks
can be backed by a plethora of sources that are user configurable.
This change just adds the basic infrastructure for creating and
removing blkmap devices. Subsequent changes will extend this to add
support for actual mappings.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
ofnode_decode_display_timing supports reading timing parameters from
subnode of display-timings node, for displays supporting multiple
resolution, in case if a display supports single resolution, it fails
reading directly from display-timings node, to support it
ofnode_decode_panel_timing is added.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order to support IOMMUs in non-bypass mode we need device ops
to map and unmap DMA memory. The map operation enters a mapping
for a region specified by CPU address and size into the translation
table of the IOMMU and returns a DMA address suitable for
programming the device to do DMA. The unmap operation removes
this mapping from the translation table of the IOMMU.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Sandbox supports block devices which can access files on the host machine.
At present there is no uclass for this. The devices are attached to the
root devic. The block-device type is therefore set to UCLASS_ROOT which
is confusing.
Block devices should be attached to a 'media' device instead, something
which handles access to the actual media and provides the block driver
for the block device.
Create a new uclass to handle this. It supports two operations, to attach
and detach a file on the host machine.
For now this is not fully plumbed in.
Signed-off-by: Simon Glass <sjg@chromium.org>
In the FWU Multi Bank Update feature, the information about the
updatable images is stored as part of the metadata, which is stored on
a dedicated partition. Add the metadata structure, and a driver model
uclass which provides functions to access the metadata. These are
generic API's, and implementations can be added based on parameters
like how the metadata partition is accessed and what type of storage
device houses the metadata.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
When probing a device fails NULL pointer is returned, and following
devices in uclass list cannot be iterated. Skip to next device on error
instead.
With that the only condition under which these simple iteration
functions return error is when the dm is not initialized at uclass_get
time. This is not all that interesting, change return type to void.
Fixes: 6494d708bf ("dm: Add base driver model support")
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
device_probe returns early when the device is already activated.
Add a note to the documentation that it can be used on already activated
devices.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Update this function's comment and also the livetree documentation, so it
is clear when to use the function.
Signed-off-by: Simon Glass <sjg@chromium.org>
The _err variant iterators use the simple iterators without suffix as
basis.
However, there is no user that uclass_next_device_err for iteration,
many users of uclass_first_device_err use it to get the first and
(assumed) only device of an uclass, and a couple that use
uclass_next_device_err to get the device following a known device in the
uclass list.
While there are some truly singleton device classes in which more than
one device cannot exist these are quite rare, and most classes can have
multiple devices even if it is not the case on the SoC's EVB.
In a later patch the simple iterators will be updated to not stop on
error and return next device instead. With this in many cases the code
that expects the first device or an error if it fails to probe may get
the next device instead. Use the _check iterators as the basis of _err
iterators to preserve the old behavior.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The return value is not used for anythig, and in a later patch the
behavior of the _err iterator will change in an incompatible way.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Update pvblock_probe() to avoid using internal var:
Signed-off-by: Simon Glass <sjg@chromium.org>
For future DM based FPGA drivers and for now to have a meaningful
logging class for old FPGA drivers.
Suggested-by: Michal Simek <michal.simek@amd.com>
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Dahl <post@lespocky.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20220930120430.42307-2-post@lespocky.de
Signed-off-by: Michal Simek <michal.simek@amd.com>
At present ofnode_write_prop() is inconsistent between livetree and
flattree, in that livetree requires the caller to ensure the property
value is stable (e.g. in rodata or allocated) but flattree does not, since
it makes a copy.
This makes the API call a bit painful to use, since the caller must do
different things depending on OF_LIVE.
Add a new 'copy' argument which tells the function to make a copy if
needed. Add some tests to cover this behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some ofnode functions can only operate on the default device tree, i.e.
U-Boot's control FDT. Add comments to that effect. Fix up the reference to
device tree bindings while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add the logic to redirect requests for the device tree through a function
which can look up the tree ID. This works by using the top bits of
ofnode.of_offset to encode a tree.
It is assumed that there will only be a few device trees used at runtime,
typically the control FDT (always tree ID 0) and possibly a separate FDT
to be passed the OS.
The maximum number of device trees supported at runtime is 8, with this
implementation. That would use bits 30:28 of the node-offset value,
meaning that the positive offset range is limited to bits 27:0, versus
30:1 with this feature disabled. That still allows a device tree of up
to 256MB, which should be enough for most FITs. Larger ones can be
supported by using external data with the FIT, or by enabling OF_LIVE.
Update the documentation a little and fix up the comment for
ofnode_valid().
Signed-off-by: Simon Glass <sjg@chromium.org>
At present, unless OF_LIVE is enabled, ofnode only supports access to one
device tree, the control FDT. This is because only the node offset is
encoded in ofnode, with the tree being implicit.
This makes ofnode (without OF_LIVE) unsuitable for device tree fixups, as
implemented by ft_board_setup() and other such functions.
To solve this, we can use the top bits of the node offset to hold a tree
ID.
Add the definitions for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function turns out to be a little confusing since it looks up a path
and also registers the tree. Split it into two, one that gets the root
node and one that looks up a path, so the purpose is clear.
Registering the tree will happen in a function to be added in a later
patch, called oftree_from_fdt().
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases we want to obtain an ofnode in the same tree as a different
ofnode, such as when looking up a subnode. At present this is trivial,
since there is only one tree. When there are multiple trees, this
implementation will change.
Also move the ofnode_to_offset() function up higher in the header file,
since we will need to provide a different implementation with multiple
trees.
Signed-off-by: Simon Glass <sjg@chromium.org>
When we have multiple trees, the ofnode logic needs to be told which one
to use. Create a new function which takes an oftree argument, along with
a helper to obtain the FDT pointer from an oftree.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present dm_test_ofnode_root() does this manually. Add some inline
functions to handle it, so this code can be centralised.
Add oftree functions to produce a null tree and to check whether a tree
is valid or not.
Signed-off-by: Simon Glass <sjg@chromium.org>
The flat device tree is assumed to be the control FDT but this is not
always the case. Update the ofnode implementation to obtain the node via
an function call so we can eventually add support for selecting different
trees.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present there is only one device tree used by the ofnode functions,
except for some esoteric use of live tree. In preparation for supporting
more than one, add a way to reset the list of device trees.
For now this does nothing.
Signed-off-by: Simon Glass <sjg@chromium.org>
