The Renesas RZ/G2L SMARC Evaluation Board Kit consists of the RZ/G2L
System-on-Module (SOM) based on the R9A07G044L2 SoC, and a common SMARC
carrier board.
The ARM TrustedFirmware code for the Renesas RZ/G2L SoC family passes a
devicetree blob to the bootloader as an argument in the same was
previous R-Car gen3/gen4 SoCs. This blob contains a compatible string
which can be used to identify the particular SoC we are running on and
this is used to select the appropriate device tree to load.
The configuration renesas_rzg2l_smarc_defconfig is added to support
building for this target. In the future this defconfig will be extended
to support other SoCs and evaluation boards from the RZ/G2L family.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The Renesas RZ/G2L SMARC Evaluation Board Kit consists of the RZ/G2L
System-on-Module (SOM) based on the R9A07G044L2 SoC, and a common SMARC
carrier board.
This patch is based on the corresponding Linux v6.5 device tree
(commit 52e12027d50affbf60c6c9c64db8017391b0c22e).
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The memory map for the RZ/G2L family differs from that of previous R-Car
Gen3/Gen4 SoCs.
A high level memory map can be seen in figure 5.2 (section 5.2.1) of the
RZ/G2L data sheet rev 1.30 published May 12, 2023. A summary is included
here (note that this is a 34-bit address space):
* 0x0_0000_0000 - 0x0_0002_FFFF SRAM area
* 0x0_0003_0000 - 0x0_0FFF_FFFF Reserved area
* 0x0_1000_0000 - 0x0_1FFF_FFFF I/O register area
* 0x0_2000_0000 - 0x0_2FFF_FFFF SPI Multi area
* 0x0_3000_0000 - 0x0_3FFF_FFFF Reserved area
* 0x0_4000_0000 - 0x1_3FFF_FFFF DDR area (4 GiB)
* 0x1_4000_0000 - 0x3_FFFF_FFFF Reserved area
Within the DDR area, the first 128 MiB are reserved by TrustedFirmware.
The region from 0x43F00000 to 0x47DFFFFF inclusive is protected for use
in TrustedFirmware/OP-TEE, but all other memory is included in the
memory map. This reservation is the same as used in R-Car
Gen3/Gen4 and RZ/G2{H,M,N,E} SoCs.
DRAM information is initialised based on the data in the fdt.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The ARM TrustedFirmware code for the Renesas RZ/G2L SoC family passes a
devicetree blob to the bootloader as an argument in the same was
previous R-Car Gen3/Gen4 SoCs. This blob contains a compatible string
which can be used to identify the particular SoC we are running on.
We do this as reading the DEVID & PRR registers from u-boot is not
sufficient to differentiate between the R9A07G044L (RZ/G2L) and
R9A07G044C (RZ/G2LC) SoCs. An additional read from offset 0x11861178 is
needed but this address is in the OTP region which can only be read from
the secure world (i.e. TrustedFirmware). So we have to rely on
TrustedFirmware to determine the SoC and pass this information to u-boot
via an fdt blob.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
We don't want to rely on source files including <asm/types.h> before
<asm/arch/rmobile.h>.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
On the Renesas RZ/G2L SoC family, we must ensure that the required clock
signals are enabled and the reset signal is de-asserted before we try to
communicate with the SDHI module.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Move the assignment of priv->quirks earlier in the function. This allows
us to drop the quirks local variable and makes it easier to maintain
clean error handling when we add RZ/G2L support in the next patch.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tidy up the existing include list before we add more includes in the
following patch.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This driver adds support for the gpio features of the GPIO/PFC module in
the Renesas RZ/G2L (R9A07G044) SoC.
The new `rzg2l-pfc-gpio` driver is bound to the same device tree node as
the `rzg2l-pfc-pinctrl` driver as the same hardware block provides both
GPIO and pin multiplexing features.
This patch is based on the corresponding Linux v6.5 driver
(commit 52e12027d50affbf60c6c9c64db8017391b0c22e).
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This driver adds support for the pinctrl features of the GPIO/PFC module
in the Renesas RZ/G2L (R9A07G044) SoC.
A multi-function `rzg2l-pfc` driver is defined for UCLASS_NOP, which
binds the `rzg2l-pfc-pinctrl` UCLASS_PINCTRL driver dynamically. We also
define common macros and functions for the PFC in <renesas/rzg2l-pfc.h>.
This makes it easy to add an additional UCLASS_GPIO driver for the GPIO
functionality of this module in a follow-up patch.
This patch is based on the corresponding Linux v6.5 driver
(commit 52e12027d50affbf60c6c9c64db8017391b0c22e).
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
On the Renesas RZ/G2L SoC family, valid GPIO numbers are not contiguous.
This is determined by the device tree, where a fixed number of bits are
used for the 'pin' number within a 'port', even though not all ports
have the same number of pins. The device tree can't be changed here
without breaking backwards compatibility in Linux, which we don't want
to do.
To avoid printing a status for each of these invalid GPIO numbers when
a user executes `gpio status -a`, we allow gpio_get_function() to return
-ENOENT when the given offset does not refer to a valid GPIO pin and we
skip printing anything if this occurs.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The RZ/G2L family uses CONFIG_RCAR_64 but does not share a common PFC
driver with the R-Car gen3 & gen4 boards.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This driver provides clock and reset control for the Renesas R9A07G044L
(RZ/G2L) and R9A07G044C (RZ/G2LC) SoC. It consists of two parts:
* driver code which is applicable to all SoCs in the RZ/G2L family.
* static data describing the clocks and resets which are specific to the
R9A07G044{L,C} SoCs. The identifier r9a07g044 (without a final letter)
is used to indicate that both SoCs are supported.
clk_set_rate() and clk_get_rate() are implemented only for the clocks
that are actually used in u-boot.
The CPG driver is marked with DM_FLAG_PRE_RELOC to ensure that its bind
function is called before the SCIF (serial port) driver is probed. This
is required so that we can de-assert the relevant reset signal during
the serial driver probe function.
This patch is based on the corresponding Linux v6.5 driver
(commit 52e12027d50affbf60c6c9c64db8017391b0c22e).
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add a config option for the R9A07G044L SoC used in the RZ/G2L so that we
can make use of this in the subsequent driver patches.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The Renesas RZ/G2L family includes the following ARM SoCs:
* RZ/G2L (r9a07g044l)
* RZ/G2LC (r9a07g044c)
* RZ/G2UL (r9a07g043u)
* RZ/V2L (r9a07g054l)
Support for individual SoCs and evaluation boards will be added in
separate patches.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Import bindings for the Interrupt Controller (IRQC) module in the
Renesas RZ/G2L SoC family.
This patch is based on the dt-bindings in Linux v6.5
(commit 52e12027d50affbf60c6c9c64db8017391b0c22e).
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Import bindings for the Port Function Control (PFC) module in the
Renesas RZ/G2L SoC family.
This patch is based on the dt-bindings in Linux v6.5
(commit 52e12027d50affbf60c6c9c64db8017391b0c22e).
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Import bindings for the Clock Pulse Generator (CPG) module in the
Renesas RZ/G2L SoC family.
This patch is based on the dt-bindings in Linux v6.5
(commit 52e12027d50affbf60c6c9c64db8017391b0c22e).
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
If we attempt to compile serial_sh.c for a system which lacks HSCIF
support (e.g. R8A7740), we see the following compilation error:
In file included from drivers/serial/serial_sh.c:20:
drivers/serial/serial_sh.c: In function ‘sh_serial_init_generic’:
drivers/serial/serial_sh.h:429:35: warning: implicit declaration of function ‘sci_HSSRR_out’; did you mean ‘sci_SCSCR_out’? [-Wimplicit-function-declaration]
429 | #define sci_out(port, reg, value) sci_##reg##_out(port, value)
| ^~~~
drivers/serial/serial_sh.c:62:17: note: in expansion of macro ‘sci_out’
62 | sci_out(port, HSSRR, HSSRR_SRE | HSSRR_SRCYC8);
| ^~~~~~~
To fix this, only try to support access to the HSSRR register for SoCs
where it actually exists.
Support for the RZ/G2L will be introduced in following patches, which
selects CONFIG_RCAR_64 but does not have HSCIF interfaces, so check for
CONFIG_RCAR_GEN2 || CONFIG_RCAR_GEN3 || CONFIG_RCAR_GEN4 to determine if
HSCIF is present.
Fixes: bbe36e29ca ('serial: sh: Add HSCIF support for R-Car SoC')
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Cc: Hai Pham <hai.pham.ud@renesas.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
scan all entries in multi-device boot_targets
EFI empty-capsule support
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmUpvTQRHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreabCwgAimB2fGpK3FjFMrH1Ko4Qh3j0D/0XomiQ
1KYVbn3YrswLmq1tav9HSKWR3Ep/Uet6jthpH2RPxhcGWNGqxkkk2k4LUudSlIYd
0KKoovMwBK9jZcojoBAjFGaoRIaEBlbFspW/RoXPJnr7ctxf6HSYkW2TPH09zqtD
FrL5Jjf6t0h6QShxhCYXbiHGCnp2zYZRzFnrYpaXy8IIavqWNJTAhkIGveMy+Qa8
TzhmuRamLgtZZwtFcHt8sZuV4+FtBrtHAyiEasnJFPJ5Kv6tFVBiHdYuygZMu/og
+F57ufgqgHTlDjzW72CJyhrHIcVn/mWjNYrulufqHAsSFD7cizISeA==
=qOUT
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-13oct23' of https://source.denx.de/u-boot/custodians/u-boot-dm
improvements with dev_read_addr_..._ptr()
scan all entries in multi-device boot_targets
EFI empty-capsule support
- Fix a memset call in the optee_agent code.
Then to quote the author for the rest of the changes:
This patch series allows users to access SCMI base protocol provided by
SCMI server (platform). See SCMI specification document v3.2 beta[1]
for more details about SCMI base protocol.
What is currently not implemented is
- SCMI_BASE_NOTIFY_ERRORS command and notification callback mechanism
This feature won't be very useful in the current U-Boot environment.
[1] https://developer.arm.com/documentation/den0056/e/?lang=en
The sess variable in open_channel was not entirely
cleared to zero at the start of this function.
This commit ensures that the entire struct is cleared.
Signed-off-by: Francois Berder <fberder@outlook.fr>
Now that we have Base protocol support, we will be able to check if a given
protocol is really supported by the SCMI server (firmware).
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Added is a new unit test for SCMI base protocol, which will exercise all
the commands provided by the protocol, except SCMI_BASE_NOTIFY_ERRORS.
$ ut dm scmi_base
It is assumed that test.dtb is used as sandbox's device tree.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
SCMI base protocol is mandatory and doesn't need to be listed in a device
tree.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
SCMI base protocol is mandatory, and once SCMI node is found in a device
tree, the protocol handle (udevice) is unconditionally installed to
the agent. Then basic information will be retrieved from SCMI server via
the protocol and saved into the agent instance's local storage.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
Adding SCMI base protocol makes it inconvenient to hold the agent instance
(udevice) locally since the agent device will be re-created per each test.
Just remove it and simplify the test flows.
The test scenario is not changed at all.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
This is a simple implementation of SCMI base protocol for sandbox.
The main use is in SCMI unit test.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
In SCMI base protocol version 2 (0x20000), new interfaces,
BASE_SET_DEVICE_PERMISSIONS/BASE_SET_PROTOCOL_PERMISSIONS/
BASE_RESET_AGENT_CONFIGURATION, were added. Moreover, the api of
BASE_DISCOVER_AGENT was changed to support self-agent discovery.
So the driver expects SCMI firmware support version 2 of base protocol.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
SCMI base protocol is mandatory according to the SCMI specification.
With this patch, SCMI base protocol can be accessed via SCMI transport
layers. All the commands, except SCMI_BASE_NOTIFY_ERRORS, are supported.
This is because U-Boot doesn't support interrupts and the current transport
layers are not able to handle asynchronous messages properly.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
Any SCMI protocol may have its own channel.
Test this feature on sandbox as the necessary framework was added
in a prior commit.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
This framework allows SCMI protocols to be installed and bound to the agent
so that the agent can manage and utilize them later.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
Move the location of scmi_bind_protocols() backward for changes
in later patches.
There is no change in functionality.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
In sandbox scmi agent, channels are not used at all. But in this patch,
dummy channels are supported in order to test protocol-specific channels.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
SCMI specification allows any protocol to have its own channel for
the transport. While the current SCMI driver may assign its channel
from a device tree, the core function, devm_scmi_process_msg(), doesn't
use a protocol's channel, but always use an agent's channel.
With this commit, devm_scmi_process_msg() tries to find and use
a protocol's channel. If it doesn't exist, use an agent's.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The commit 85dc582892 ("firmware: scmi: prepare uclass to pass channel
reference") added an explicit parameter, channel, but it seems to make
the code complex.
Hiding this parameter will allow for adding a generic (protocol-agnostic)
helper function, i.e. for PROTOCOL_VERSION, in a later patch.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
Add support in binman for generating EFI empty capsules. These
capsules are used in the FWU A/B update feature. Also add test cases
in binman for the corresponding code coverage.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a method to the mkeficapsule bintool to generate empty
capsules. These are capsules needed for the FWU A/B update feature.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The various fields of a generated capsule are currently verified
through hard-coded offsets. Use the dump-capsule feature for dumping
the capsule header contents and use those for capsule verification.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The #address-cells and #size-cells are not needed for running the
capsule generation binman tests. Remove the superfluous properties.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add documentation to explain the printing of the capsule headers
through the mkeficapsule tool.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add support to dump the contents of capsule headers. This is useful as
a debug feature for checking the contents of the capsule headers, and
can also be used in capsule verification.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
A follow-up to commit 842fb5de42
("drivers: use devfdt_get_addr_size_index_ptr when cast to pointer")
and commit 320a1938b6
("drivers: use devfdt_get_addr_index_ptr when cast to pointer").
In addition to using the *_ptr variants of these functions where the
address is cast to a pointer, this also changes devfdt_get_addr_*() to
dev_read_addr_*() in a few places. Some variable and field types are
changed from fdt_addr_t or phys_addr_t to void* where the cast was
happening later.
This patch fixes a number of compile warnings when building a 32bit
U-Boot with CONFIG_PHYS_64BIT=y. In some places, it also fixes error
handling where the return value of dev_read_addr() etc. was checked for
NULL instead of FDT_ADDR_T_NONE.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
pinctrl-single uses fdt_addr_t and phys_addr_t inconsistently, but both
are wrong to be passed to readb() etc., which expect a pointer or
pointer-sized integer. Change the driver to use
dev_read_addr_size_index_ptr(), so we consistently deal with void*
(except for the sandbox case and single_get_pin_muxing()).
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add missing mapmem.h header:
Signed-off-by: Simon Glass <sjg@chromium.org>
Same as dev_read_addr_name[_size](), but returns a pointer, cast
through map_sysmem().
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Checking for the error cast to fdt_addr_t is rather awkward - IS_ERR()
can be used, but it's not really made to be used on fdt_addr_t, which
may not even be the same size as a native pointer.
Most places in U-Boot only check for FDT_ADDR_T_NONE; let's adjust the
error return to match the expectation.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
- The dev_read_addr_name*() family of functions has no "index" argument,
doc comments should refer to "name"
- Specify the error return for several devfdt_get_addr*() functions
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The argument type of `build_from_git` was changed from string to list
in d71e711699.
This commit adapts the argument type of all bintools using this
function.
Signed-off-by: Lukas Funke <lukas.funke@weidmueller.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
sandbox_spl_defconfig with CONFIG_SPL_UNIT_TEST=n fails to build.
in function `spl_board_init':
arch/sandbox/cpu/spl.c:134:(.text.spl_board_init+0x4a):
undefined reference to `ut_run_list'
Add the missing configuration check.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
