Add DWMCI_QUIRK_DISABLE_FMP flag to Exynos850 driver data to make the
driver disable FMP in case of Exynos850 chip. That makes eMMC on
Exynos850 functional when U-Boot is executed during USB boot.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Up until now "samsung,exynos7-dw-mshc-smu" compatible was used for
Exynos850 SoC, as it's present in its device tree. But Exynos850 device
tree also supports "samsung,exynos850-dw-mshc-smu" compatible string.
Add it in compatible ID list in the driver so that it can be matched
against this string for Exynos850 device tree.
No functional change, as the driver data is just a copy of
"samsung,exynos7-dw-mshc-smu" data for now.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add DWMCI_QUIRK_DISABLE_FMP which disables Flash Memory Protector (FMP)
during driver's init. It's usually done by early bootloaders, but in
some cases (like USB boot) the FMP may be left unconfigured. The issue
was observed on Exynos850 SoC (the E850-96 board). Enabling this quirk
makes eMMC functional even in such cases.
No functional change, as this feature is only added here but not enabled
for any chips yet.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Exynos DW MMC glue layer driver have seen a lot of changes recently.
Stabilize the coding style.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Do not over-expose the private dw_mmc API. The glue layer drivers at
this point shouldn't be aware and shouldn't use the generic
dwmci_send_cmd() and dwmci_set_ios() functions. Making those functions
public causes a "leaky abstraction" issue. It clutters the public
interface of generic dw_mmc driver and possibly leads to improper usage
of those functions, so it's a bad design.
If struct dm_dwmci_ops has to be extended, do so by copying it first
(like it's done for example in snps_dw_mmc driver). That also makes sure
the future changes to struct dm_dwmci_ops in dw_mmc driver will be
automatically reflected in all extended copies, and avoid code
duplication.
This effectively reverts commit ef3b16bb8e73 ("mmc: dw_mmc: export
dwmci_send_cmd() and dwmci_set_ios()").
No functional change.
Fixes: ef3b16bb8e73 ("mmc: dw_mmc: export dwmci_send_cmd() and dwmci_set_ios()")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Instead of extending dm_dwmci_ops by copy-pasting the structure code
first, copy the actual structure data with memcpy() and then set the
.execute_tuning field. Now if struct dm_dwmci_ops gets modified in
future, these changes will be automatically reflected in struct
exynos_dwmmc_ops, which prevents possible issues in future. It also
avoids code duplication.
No functional change, but it can prevent possible isssues in future.
Fixes: eda4bd29929c ("mmc: exynos_dw_mmc: add support for MMC HS200 and HS400 modes")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The null check for loader in boot_from_devices was moved earlier in the
code path by the commit ae409a84e7 ("spl: NULL check variable before
dereference"), therefore the subsequent null checks for loader are not
necessary.
This patch removes those checks and refactors the prints to be more
useful in case of errors.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Anshul Dalal <anshuld@ti.com> says:
This patch set adds support for falcon boot on AM62a, 62p and 62x by bypassing
A53 SPL and U-boot.
Existing Boot flow:
R5 SPL -> ATF -> A53 SPL -> U-Boot -> Linux Kernel
Updated flow:
R5 SPL -> ATF -> Linux Kernel
U-Boot's falcon mode expects the jump from SPL to kernel to happen on the same
core which is not directly applicable for our heterogeneous platforms since
ATF, OPTEE and other non SPL binaries from tispl.bin should be loaded before the
kernel by the R5 SPL.
So we have to use a different flow to bypass A53 SPL and U-Boot, we first load
the newly added tispl_falcon.bin instead of tispl.bin which lacks u-boot-spl.bin
(A53's SPL) and the corresponding fdt. This sets up dm, tifs, optee and
atf. Once loaded, we load the kernel and the dtb (with fixups) at ATF's
PRELOADED_BL33_BASE and K3_HW_CONFIG_BASE.
NOTE:
Since we're now using the SPL to load the kernel and kernel expects a 2MiB
aligned load address, the existing PRELOADED_BL33_BASE has to be changed for ATF
to 0x82000000 with K3_HW_CONFIG_BASE set to 0x88000000 for the DTB.
Link: https://lore.kernel.org/r/20251031073800.344500-1-anshuld@ti.com
This patch adds user documentation for R5 falcon mode for AM62
platforms. The main section is added to am62x_sk.rst and other documents
just include the relevant sections. Steps to build falcon support, usage
and the modified R5 memory map have been documented.
Two svg images have also been added for reference, one for the modified
tifalcon.bin and other for the fitImage format specific to R5 falcon
mode.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
The bootargs are passed to the kernel in the chosen node, this patch
adds support for populating bootargs in the dtb if missing.
The values for kernel boot params is taken from the env, with 'boot' and
'bootpart' specifying the rootfs for the kernel similar to the
non-falcon boot flow.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This patch adds fdt fixups to the kernel device-tree in R5 falcon mode,
these fixups include fixing up the core-count, reserved-memory etc.
The users can opt out by disabling the respective CONFIG_OF_*_SETUP
config options.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
To simplify the boot process and prevent the R5 SPL size from growing,
this patch restricts the boot media to load the next stage payload
(tifalcon.bin and kernel FIT) to MMC only.
We select between eMMC/SD by checking "mmcdev" in env to conform with
how U-Boot proper handles loading binaries from MMC1 or MMC2.
Note that tiboot3.bin (the initial bootloader) can be loaded from any
boot mode supported by the ROM since the restriction only applies to
tifalcon.bin and fitImage.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
We use the spl_board_prepare_for_boot hook to call k3_r5_falcon_prep
which is ran after tispl is loaded but before jump_to_image.
In k3_r5_falcon_prep, we find the boot media and load the kernel FIT
just as standard secure falcon mode (since spl_start_uboot returns 0
now). Once the kernel and args are loaded.
Now when the flow goes to jump_to_image, we do the regular pre-jump
procedure and jump to TFA which jumps to the kernel directly since we
have already loaded the kernel and dtb at their respective addresses
(PRELOADED_BL33_BASE and K3_HW_CONFIG_BASE).
Overall execution for the R5 SPL after this patch:
board_init_r
|-> boot_from_devices
| +-> load_image (we load tifalcon.bin here since spl_start_uboot
| returns 1)
|
+-> spl_prepare_for_boot
| +-> k3_falcon_prep
| +-> load_image (we load fitImage here since spl_start_uboot
| returns 0 now)
|
+-> jump_to_image
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This fragment enables falcon mode for K3 platforms and modifies the
memory map.
To have enough stack and heap space for loading kernel image as
FIT the memory map was modified by expanding stack + heap size, the
PRELOADED_BL33_BASE in TFA has to also be updated to 0x82000000 since
the kernel needs to be loaded at 2MiB aligned address along with
updating K3_HW_CONFIG_BASE to 0x88000000 for the DT passed to kernel.
Modified memory map for R5 SPL (modified addresses marked with *):
0x80000000 +-------------------------------+ Start of DDR
512KiB | TFA reserved memory space | CONFIG_K3_ATF_LOAD_ADDR*
0x80080000 +-------------------------------+
31.5MiB | Unused |
0x82000000 +-------------------------------+ PRELOADED_BL33_BASE* in TFA
| | CONFIG_SYS_LOAD_ADDR*
57MiB | Kernel + initramfs Image | CONFIG_SPL_LOAD_FIT_ADDRESS*
| |
0x85900000 +-------------------------------+
| |
| R5 U-Boot SPL Stack + Heap |
39MiB | (size defined by |
|SPL_STACK_R_MALLOC_SIMPLE_LEN*)|
| |
0x88000000 +-------------------------------+ CONFIG_SPL_STACK_R_ADDR*
| | K3_HW_CONFIG_BASE* in TFA
16MiB | Kernel DTB | CONFIG_SPL_PAYLOAD_ARGS_ADDR*
| |
0x89000000 +-------------------------------+
331MiB | Device Manager (DM) Load Addr |
0x9db00000 +-------------------------------+
12MiB | DM Reserved |
0x9e700000 +-------------------------------+
1MiB | Unused |
0x9e800000 +-------------------------------+ BL32_BASE in TFA
24MiB | OPTEE |
0xa0000000 +-------------------------------+ End of DDR (512MiB)
Signed-off-by: Anshul Dalal <anshuld@ti.com>
This patch adds creation of tifalcon.bin for the AM62a, 62p and 62x.
The contents are the same as the existing tispl.bin but A53's SPL and
the FDT have been removed as they are not needed in R5 falcon mode.
This reduces boot time since the payload size is smaller compared to the
regular tispl.bin.
tispl.bin = TFA + TEE + TIFS-STUB + A53 SPL + FDT
tifalcon.bin = TFA + TEE + TIFS-STUB
Signed-off-by: Anshul Dalal <anshuld@ti.com>
I have a hunch VPL_DM_SERIAL should not be selectable if VPL isn't set
as implied by the prefix. Additionally, still based on the prefix, I'm
assuming VPL_DM should be a dependency. Since VPL_DM can only be
selectable when VPL is enabled, only depend on VPL_DM.
This mirrors SPL_DM_SERIAL and TPL_DM_SERIAL so seems right to me.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
SPL_FIT_FULL_CHECK currently shares its description and help text with
FIT_FULL_CHECK which is quite confusing, so let's specify this applies
to SPL.
Fixes: 6f3c2d8aa5 ("image: Add an option to do a full check of the FIT")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
This is mostly R-Car Gen5 drivers for GPIO, pin control, RSwitch3 and
matching PHYs. There is also a few trivial clean ups for arch headers
and configs. Board code, DT and clock are coming in follow up PR.
Now that we've had jobs running on both amd64 and arm64 hosts for a
while, we have enough data to look at usage and findings. For the world
build job, make use of the new DEFAULT_FAST_TAG and only build it once,
on either amd64 or arm64 as we don't run in to host specific results
there. For sandbox, continue to build on both arm64 and amd64 hosts as
we can find host specific breakage that way. Remove the mistaken
restriction on sandbox64_lwip.
Signed-off-by: Tom Rini <trini@konsulko.com>
Dmitrii Sharshakov <d3dx12.xx@gmail.com> says:
I faced some minor compatibility issues when choosing Clang as the
cross-compiler for my target.
Please review these two fixes, aiming at enabling Clang-based builds
(still using GNU binutils) for 32-bit ARM targets.
Tested to fix build with (also run-tested on qemu arm and arm64 with clang):
make ARCH=arm HOSTCC=clang CROSS_COMPILE=arm-none-eabi- CC=clang imx6ulz_smm_m2b_defconfig
make ARCH=arm HOSTCC=clang CROSS_COMPILE=arm-none-eabi- CC=clang -j20
Link: https://lore.kernel.org/r/20251101-clang-fixes-v1-0-a8398475226e@gmail.com
The current default boot command does not respect the Linux kernel 2 MiB
alignment requirement, present on aarch64 [1]:
"
The Image must be placed text_offset bytes from a 2MB aligned base
address anywhere in usable system RAM and called there.
"
Adjust the boot command such, that it always places both Image and DT at
the nearest highest 2 MiB aligned offset. The DT is placed at lower 2 MiB
aligned address, the aarch64 Image is placed at the next higher 2 MiB
aligned address. Is is unlikely that a DT would be larger than 2 MiB on
these systems.
Replace use of hard-coded load addresses with generic ${loadaddr} aligned
using setexpr. This way, if user picks valid ${loadaddr}, their kernel and
DT address will be correctly set as well.
Fix up boot commands to use && instead of ; to exit the boot command early
in case of failure.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arch/arm64/booting.rst#n138
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Use the BIT() macro consistently in R-Car Gen3 header.
Fix indent with spaces to tabs at the same time. No
functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Make CONFIG_SYS_LOAD_ADDR family-specific to prepare for R-Car Gen5
support. R-Car Gen5 uses different memory map compared to the current
R-Car Gen3 and Gen4 and also different CONFIG_SYS_LOAD_ADDR. This is
a preparatory change for R-Car Gen5. No functional change.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Upport
Checkpatch warns that it's generally not useful to have
the filename in the file. The warning is valid, drop the
encoded file name. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add initial pin control tables for the Renesas R-Car X5H R8A78000 SoC.
This SoC is the first one which includes custom DRV register handling,
different from previous generations due to change in DRV register bit
layout.
Signed-off-by: Huy Bui <huy.bui.wm@renesas.com>
Signed-off-by: Khanh Le <khanh.le.xr@renesas.com>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The upcoming Renesas R-Car Gen5 uses different mapping of bits in DRV
control register, which is incompatible with existing DRV register bit
mapping. Add .set_drive_strength callback into sh_pfc_soc_operations
and call it from sh_pfc_pinconf_set(), to allow each SoC specific PFC
driver to implement replacement .set_drive_strength. Make the current
sh_pfc_pinconf_set_drive_strength() non-static, rename it with rcar_
prefix, and pass it as .set_drive_strength for existing PFC drivers.
This is a preparatory patch for R-Car Gen5, no functional change.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: Consistently use .set_drive_strength() and pass exisiting
sh_pfc_pinconf_set_drive_strength() as its parameter for
all PFC drivers. Rewrite commit message.]
Show bit position in config write debug log, which is helpful for cases
where the p port setting is applied at the exact p bit position.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Unsplit the string
Fix Kconfig entry indent to be always consistently indented with
leading tabs, never with leading spaces. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add support for the GPIO controller block in the R-Car Gen5 SoC family.
The GPIO controller has a General Input Enable Register (INEN), whose
reset state is to have all input disabled. The GPIO controller also has
updated offsets for its control registers. U-Boot uses three registers,
INDT, POSNEG, INEN, which have updated offsets, those are handled by the
driver.
Signed-off-by: Huy Bui <huy.bui.wm@renesas.com>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: - Access Gen5 specific registers via driver data offsets,
- Update commit message]
The Renesas R-Car Gen5 GPIO controller has INDT, POSNEG, INEN registers
at different offsets compared to previous generations. Introduce three
new entries in struct rcar_gpio_data {} match data to describe these
register offsets for each GPIO controller. Update the driver to access
these three registers through the match data offsets. No functional
change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Wrap the RCAR_GPIO_HAS_INEN quirk in more flexible struct rcar_gpio_data {}
in preparation for addition of Renesas R-Car Gen5 GPIO controller support.
The Renesas R-Car Gen5 GPIO controller requires more than a single quirk
to properly describe it, therefore increase the flexibility and introduce
full match data structure, and use it throughout the driver. No functional
change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Remove register macros for registers which are not used by this driver.
This makes it easier to get an overview of which registers are really
used by the driver. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The PFC offset is no longer used directly in the driver since commit
fbf26bea39 ("gpio: renesas: Migrate to pinctrl GPIO accessors")
Drop the pfc_offset parsing.
Fixes: fbf26bea39 ("gpio: renesas: Migrate to pinctrl GPIO accessors")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add PHY driver for Multi-Protocol PHY present on Renesas R-Car X5H
R8A78000 SoC. Currently, the PHY driver only supports configuring
the MPPHY for ethernet operation.
Signed-off-by: Thanh Quan <thanh.quan.xn@renesas.com>
Signed-off-by: Phong Hoang <phong.hoang.wz@renesas.com>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com> #Fix License-Identifier
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: Clean up macros, indent, clock and reset handling in probe,
rename the driver and add r8a78000- into compatible string,
update commit message.]
Add support for the Ethernet Physical Coding Sublayer (PCS) controller
on R-Car Gen5 SoCs, specifically the Renesas R-Car X5H R8A78000.
The controller is based on the SERDES infrastructure used in previous
R-Car generations, with updates for Gen5 register layout and features.
Because majority of this driver is SoC-specific register programming,
the majority of this driver is different enough from R8A779F0 SerDes
driver to justify its own driver. Deduplication of the remaining bits
of code does not yield any improvement.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Phong Hoang <phong.hoang.wz@renesas.com>
Signed-off-by: Tam Nguyen <tam.nguyen.xa@renesas.com>
Signed-off-by: Thanh Quan <thanh.quan.xn@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[Marek: Add missing clk_bulk_disable() in fail path.
Drop always-true aneg_on setting.
Reduce poll delay from 100s to 100ms.
Use bulk reset operations to finalize reset handling.]
Add support for the Renesas Ethernet Switch3 (RSW3) controller,
present in R-Car Gen5 SoCs such as R-Car X5H (R8A78000). The
hardware offset differences are handled via driver match data.
The driver newly detects whether the switch prot is connected
to xPCS or not, and if so, turns on MIOC bit 3. This is new on
R-Car X5H. GWCKSC register is also programmed only on X5H. The
rest of the operation is identical to RSwitch2.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Tam Nguyen <tam.nguyen.xa@renesas.com>
Signed-off-by: Phong Hoang <phong.hoang.wz@renesas.com>
Signed-off-by: Thanh Quan <thanh.quan.xn@renesas.com>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
The MPIC_MDC_CLK clock setting value differs between R-Car S4
and R-Car X5H. Parametrize the value in preparation for R-Car
X5H addition into this driver. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The GWDCBAC0, GWDCBAC1, FWPBFCSDC, CABPIRM register offsets changed
between R-Car S4 and R-Car X5H. Parametrize their offsets in preparation
for R-Car X5H addition into this driver. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Inline FWRO, CARO, GWRO, TARO, RMRO macros directly into the
follow up register macros. FWRO, CARO, GWRO, TARO are already
zero, drop them. RMRO is 0x1000, increment all registers which
add RMRO by 0x1000 directly. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The forwarding engine CSD register offset changed between the
R-Car S4 and R-Car X5H. Parametrize this offset in preparation
for R-Car X5H addition into this driver. Clean up the macro
parameter names and make them more obvious. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The total port counts differ across variants of this IP in
R-Car S4 and R-Car X5H. Parametrize port count in preparation
for R-Car X5H addition into this driver. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The COMA, ETHA, GWCA offsets differ across variants of this IP in
R-Car S4 and R-Car X5H. Parametrize these offsets in preparation
for R-Car X5H addition into this driver. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This IP does support operating MII and SerDes via different ports.
Currently, the driver assumes that MII and SerDes are always bound
together on the same port, but this may not be the case. Implement
support for controlling MII and SerDes separately.
While the change is extensive, the gist of the change is to pass
pointer to the selected port registers to MII or SerDes functions,
depending on which port and operations should be done on that port.
Each combined ETHA instance contains both MII and SerDes register
pointers, which may not point to the same port, and passes those
registers to MII and SerDes functions respectively to control the
MII or SerDes of each port.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The new version of RSwitch3 in Renesas R-Car Gen5 uses multiple
clock to supply the IP. Convert the driver to bulk clock API to
cater for both single clock of R-Car S4 and multiple clock of
R-Car Gen5. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
