aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-04-19ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-scmi-u-bootPatrice Chotard
Add 2 gpio-keys : _ button-user-1 for stm32prog mode activation. _ button-user-2 for fastboot mode activation. Remove proprietary st,fastboot-gpios and st,stm32prog-gpios. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-u-bootPatrice Chotard
The blue led is used to indicate U-Boot entering / exit indication then Linux heartbeat. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Update red led node for stm32mp157c-ed1-u-bootPatrice Chotard
As indicated in kernel led dt-bindings, label is a deprecated property, so remove it and use led node's name instead for u-boot,error-led property. Rename red led node's name to led-red. Remove status property which is useless. Add compatible = "gpio-leds" which is not present in kernel DT. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-u-bootPatrice Chotard
red led and button dedicated to fastboot share the same gpio GPIOA13. Led driver is probed early so the corresponding gpio is taken and configured in output which forbid fastboot and stm32prog button usage. To avoid this, remove the "default-state" property from red led node. This will avoid to trigger the led driver probe() to configure the led default state during startup. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-u-bootPatrice Chotard
Add 2 gpio-keys : _ button-user-1 for stm32prog mode activation. _ button-user-2 for fastboot mode activation. Remove proprietary st,fastboot-gpios and st,stm32prog-gpios. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Update u-boot, boot-led for stm32mp157a-dk1-u-bootPatrice Chotard
As indicated in kernel led dt-bindings, label is a deprecated property, so remove it and use blue led node's name instead for u-boot,boot-led property. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Update red led node for stm32mp157a-dk1-u-bootPatrice Chotard
As indicated in kernel led dt-bindings, label is a deprecated property, so remove it and use red led node's name instead for u-boot,error-led property. Rename red led node's name to led-red. Remove status property which is useless. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-u-bootPatrice Chotard
red led and button dedicated to fastboot share the same gpio GPIOA13. Led driver is probed early so the corresponding gpio is taken and configured in output which forbid fastboot and stm32prog button usage. To avoid this, remove the "default-state" property from red led node. This will avoid to trigger the led driver probe() to configure the led default state during startup. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-u-bootPatrice Chotard
Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare 2 gpio-keys. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Add led-blue for stm32mp157a-dk1-scmi-u-bootPatrice Chotard
As indicated in kernel led dt-bindings, label is a deprecated property, so remove it and use blue led node's name instead for u-boot,boot-led property. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Update red led node for stm32mp157a-dk1-scmi-u-bootPatrice Chotard
As indicated in kernel led dt-bindings, label is a deprecated property, so remove it and use red led node's name instead for u-boot,error-led property. Rename "red" led node's name to "led-red". Remove status property which is useless. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-scmi-u-bootPatrice Chotard
red led and button dedicated to fastboot share the same gpio GPIOA13. Led driver is probed early so the corresponding gpio is taken and configured in output which forbid fastboot and stm32prog button usage. To avoid this, remove the "default-state" property from red led node. This will avoid to trigger the led driver probe() to configure the led default state during startup. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-scmi-u-bootPatrice Chotard
Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare 2 gpio-keys. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Clean led-red node for stm32mp135f-dk-u-bootPatrice Chotard
Remove "color" property from led-red node which is not supported by U-Boot. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Don't probe led-red/led-blue at boot for stm32mp135f-dk-u-bootPatrice Chotard
led-red and button dedicated to fastboot share the same gpio GPIOA13. led-blue and button dedicated to stm32prog share the same gpio GPIOA14. Led driver is probed early so the corresponding gpio is taken and configured in output which forbid fastboot and stm32prog button usage. To avoid this, remove the "default-state" property from led-red and led-blue led's node. This will avoid to trigger the led driver probe() to configure the led default state during startup. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Add gpio-keys for stm32mp135f-dk-u-bootPatrice Chotard
Add 2 gpio-keys : _ button-user-1 for stm32prog mode activation. _ update button-user's label (defined in kernel DT) to match label requested in board_key_check() for fastboot mode activation. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19board: st: stmp32mp1: Use BUTTON UCLASS in board_key_check()Patrice Chotard
Instead of using gpio directly to detect key pressed on button dedicated for fastboot and stm32mprog, make usage of BUTTON UCLASS. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp13_defconfigPatrice Chotard
Enable BUTTON_GPIO flag for STM32MP15. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
2024-04-19configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_trusted_defconfigPatrice Chotard
Enable BUTTON_GPIO flag for STM32MP15. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_basic_defconfigPatrice Chotard
Enable BUTTON_GPIO flag for STM32MP15. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_defconfigPatrice Chotard
Enable BUTTON_GPIO flag for STM32MP15. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19configs: stm32mp13: Enable FASTBOOTPatrice Chotard
Enable FASTBOOT relative flags for stm32mp13_defconfig. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
2024-04-19mmc: stm32_sdmmc2: Fix AARCH64 compilation warningsPatrice Chotard
When building with AARCH64 defconfig, we got warnings, fix them. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2024-04-19mmc: stm32_sdmmc2: Add "st,stm32mp25-sdmmc2" compatiblePatrick Delaunay
Add compatible used for STM32MP25 family. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
2024-04-19ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcom-u-bootPatrice Chotard
Fix flash@0 partition node name with correct offset. Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand node for stm32mp15xx-dhcom/dhcor") Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcor-u-bootPatrice Chotard
Fix flash@0 partition node name with correct offset. Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand node for stm32mp15xx-dhcom/dhcor") Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: dts: stm32: Fix partition node name for stm32mp157c-ev1-u-bootPatrice Chotard
Fix flash@0 and nand@0 partition node name with correct offset. Fixes: e91d3c61767b ("arm: dts: stm32: Add partitions in flash0 and nand node for stm32mp15xx-ev1") Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
2024-04-19ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xxMarek Vasut
In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be released from endless loop in BootROM only by populating TAMP BKPxR 4 and 5 with magic and branch address and sending SGI0 interrupt from core 0 to core 1 twice. TAMP_SMCR BKP..PROT fields must be initialized as well to release the core 1 from endless loop during the second SGI0 handling on core 1. Initialize TAMP_SMCR to protect the first 32 backup registers, the ones which contain the core 1 magic, branch address and boot information. This requirement seems to be undocumented, therefore it was necessary to trace and analyze the STM32MP15xx BootROM using OpenOCD and objdump. Ultimately, it turns out that a certain BootROM function reads out the TAMP_SMCR register and tests whether the BKP..PROT fields are non-zero. If they are zero, the BootROM code again waits for SGI0 using WFI, else the execution moves forward until it reaches handoff to the TAMP BKPxR 5 branch address. This fixes CPU core 1 release using U-Boot PSCI implementation on an OTP-CLOSED system, i.e. system with fuse 0 bit 6 set. Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2024-04-19ARM: stm32: Report OTP-CLOSED instead of rev.? on closed STM32MP15xxMarek Vasut
SoC revision is only accessible via DBUMCU IDC register, which requires BSEC.DENABLE DBGSWENABLE bit to be set to make the register accessible, otherwise an access to the register triggers bus fault. As BSEC.DBGSWENABLE is zero in case of an OTP-CLOSED system, do NOT set DBGSWENABLE bit as this might open a brief window for timing attacks. Instead, report that this system is OTP-CLOSED and do not report any SoC revision to avoid confusing users. Use an SEC/C abbreviation to avoid growing SOC_NAME_SIZE . Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2024-04-19ARM: stm32: Drop superfluous Makefile entry for ecdsa_romapi.oMarek Vasut
The source file is in arch/arm/mach-stm32mp/ecdsa_romapi.c and not in arch/arm/mach-stm32mp/stm32mp1/ecdsa_romapi.c . There are two Makefile entries in each subdirectory. Drop the bogus one and keep only the correct one, the one in arch/arm/mach-stm32mp/Makefile . Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2024-04-19ARM: stm32: Jump to ep on successful resume in PSCI suspend codeMarek Vasut
In case the system has resumed successfully, the PSCI suspend resume code has to jump to the 'ep' successful resume entry point code path, otherwise the code has to jump to content of the LR register, which points to failed resume code path. To implement this distinction, rewrite LR register stored on stack with 'ep' value in case of a successful resume, which is really in every case unless some catastrophic failure occurred during suspend. Without this change, Linux counts every resume as failed in /sys/power/suspend_stats/fail Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2024-04-19net: dwc_eth_qos: Add support for st, ext-phyclk propertyMarek Vasut
The "st,ext-phyclk" property is a unification of "st,eth-clk-sel" and "st,eth-ref-clk-sel" properties. All three properties define ETH CK clock direction, however: - "st,eth-clk-sel" selects clock direction for GMII/RGMII mode - "st,eth-ref-clk-sel" selects clock direction for RMII mode - "st,ext-phyclk" selects clock direction for all RMII/GMII/RGMII modes The "st,ext-phyclk" is the preferrable property to use. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Christophe ROULLIER <christophe.roullier@foss.st.com>
2024-04-19net: dwc_eth_qos: Add support of STM32MP13xx platformChristophe Roullier
Add compatible "st,stm32mp13-dwmac" to manage STM32MP13 boards. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Christophe Roullier <christophe.roullier@st.com> Signed-off-by: Marek Vasut <marex@denx.de> # Rebase, reshuffle, squash code Reviewed-by: Christophe ROULLIER <christophe.roullier@foss.st.com>
2024-04-19net: dwc_eth_qos: Add DT parsing for STM32MP13xx platformChristophe Roullier
Manage 2 ethernet instances, select which instance to configure with mask If mask is not present in DT, it is stm32mp15 platform. Signed-off-by: Christophe Roullier <christophe.roullier@st.com> Signed-off-by: Marek Vasut <marex@denx.de> # Rework the code Reviewed-by: Christophe ROULLIER <christophe.roullier@foss.st.com>
2024-04-19net: dwc_eth_qos: Constify st, eth-* values parsed out of DTMarek Vasut
Use const bool for the values parsed out of DT. Drop the duplicate assignment of false into those bool variables, assign them directly with the content parsed out of DT. Abbreviate the variable name too. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Marek Vasut <marex@denx.de>
2024-04-19net: dwc_eth_qos: Use consistent logging printsMarek Vasut
Use dev_*() only to print all the logs from this glue code, instead of mixing dev_*(), log_*(), pr_*() all in one code. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Marek Vasut <marex@denx.de>
2024-04-19net: dwc_eth_qos: Move log_debug statements on top of case blockMarek Vasut
Move the log_debug() calls on top of the bit manipulation code. No functional change. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Marek Vasut <marex@denx.de>
2024-04-19net: dwc_eth_qos: Use FIELD_PREP for ETH_SEL bitfieldMarek Vasut
Use FIELD_PREP to configure content of ETH_SEL bitfield in SYSCFG_PMCSETR register. No functional change. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Marek Vasut <marex@denx.de>
2024-04-19net: dwc_eth_qos: Scrub ifdefferyMarek Vasut
Replace ifdef CONFIG_CLK with if (CONFIG_IS_ENABLED(CLK)) to improve code build coverage. Some of the functions printed debug("%s: OK\n", __func__); on exit with and without CLK enabled, some did not, make it consistent and print nothing if CLK is disabled. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Christophe ROULLIER <christophe.roullier@foss.st.com>
2024-04-19net: dwc_eth_qos: Fold board_interface_eth_init into STM32 glue codeMarek Vasut
Move board_interface_eth_init() into eqos_probe_syscfg_stm32() in STM32 driver glue code. The eqos_probe_syscfg_stm32() parses STM32 specific DT properties of this MAC and configures SYSCFG registers accordingly, there is nothing board specific happening in this function, move it into generic driver code instead. Drop the now unused duplicates from board files. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Marek Vasut <marex@denx.de>
2024-04-19net: dwc_eth_qos: Rename eqos_stm32_config to eqos_stm32mp15_configMarek Vasut
The current glue code is specific to STM32MP15xx, the upcoming STM32MP13xx will introduce another entry specific to the STM32MP13xx. Rename the current entry to eqos_stm32mp15_config in preparation for STM32MP13xx addition. No functional change. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Christophe ROULLIER <christophe.roullier@foss.st.com>
2024-04-19net: dwc_eth_qos: Split STM32 glue into separate fileMarek Vasut
Move STM32 glue code into separate file to contain the STM32 specific code outside of the DWMAC core code. No functional change. Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Christophe ROULLIER<christophe.roullier@foss.st.com>
2024-04-19mtd: rawnand: stm32_fmc2: add MP25 supportChristophe Kerello
FMC2 IP supports up to 4 chip select. On MP1 SoC, only 2 of them are available when on MP25 SoC, the 4 chip select are available. Let's use a platform data structure for parameters that will differ. Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2024-04-19memory: stm32-fmc2-ebi: add MP25 RIF supportChristophe Kerello
The FMC2 revision 2 supports security and isolation compliant with the Resource Isolation Framework (RIF). From RIF point of view, the FMC2 is composed of several independent resources, listed below, which can be assigned to different security and compartment domains: - 0: Common FMC_CFGR register. - 1: EBI controller for Chip Select 1. - 2: EBI controller for Chip Select 2. - 3: EBI controller for Chip Select 3. - 4: EBI controller for Chip Select 4. - 5: NAND controller. Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2024-04-19memory: stm32-fmc2-ebi: add MP25 supportChristophe Kerello
Add the support of the revision 2 of FMC2 IP. - PCSCNTR register has been removed, - CFGR register has been added, - the bit used to enable the IP has moved from BCR1 to CFGR, - the timeout for CEx deassertion has moved from PCSCNTR to BCRx, - the continuous clock enable has moved from BCR1 to CFGR, - the clk divide ratio has moved from BCR1 to CFGR. The MP1 SoCs have only one signal to manage all the controllers (NWAIT). The MP25 SOC has one RNB signal for the NAND controller and one NWAIT signal for the memory controller. Let's use a platform data structure for parameters that will differ between MP1 and MP25. Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2024-04-19arm: stm32: Enable OHCI HCD support on STM32MP15xx DHSOMMarek Vasut
The OHCI HCD is mandatory for USB 1.1 FS/LS device support, enable it. This used to be enabled implicitly before, now that implicit dependency disappeared and this got disabled. Enable it manually. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2024-04-19stm32mp: cmd_stm32prog: add dependencies with USB_GADGET_DOWNLOADPatrick Delaunay
This patch avoids compilation issue when CONFIG_USB_GADGET is deactivated in defconfig, with undefined reference to run_usb_dnl_gadget and to g_dnl_set_product. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Igor Opaniuk <igor.opaniuk@foundries.io> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
2024-04-18env: mmc: print MMC device being readQuentin Schulz
This prints the MMC device being read similar to how we print the MMC device we write to when e.g. calling saveenv. One of the side effects is that the boot log now shows from which MMC device the env was loaded: Loading Environment from MMC... Reading from MMC(1)... OK This is useful to identify which MMC device the environment was loaded from for boards where there are more than one (e.g. eMMC and SD card) without adding some debug messages manually. Sadly, there's no way to know which of the default or redundant environment is being read from env_mmc_load before env_import_redund is called so it is printing a bit later (and possibly after error/warning messages). Cc: Quentin Schulz <foss+uboot@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org>
2024-04-18Kconfig: Remove all default n optionsMichal Simek
default n doesn't need to be specified. It is default option anyway. Similar changes have been done by commit 18370f14975c ("Kconfig: Remove all default n/no options"). Signed-off-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-04-18boot: fdt: Turn all addresses and sizes into u64Marek Vasut
In case of systems where DRAM bank ends at the edge of 32bit boundary, start + size calculations would overflow. This happens on STM32MP15xx with 1 DRAM bank starting at 0xc0000000 and 1 GiB of DRAM. This is a usual 32bit system DRAM size overflow, fix it by doing all DRAM size and offset calculations using u64 types. This also covers a case where a 32bit PAE system might be able to address up to 36bits of DRAM. Fixes: a4df06e41fa2 ("boot: fdt: Change type of env_get_bootm_low() to phys_addr_t") Signed-off-by: Marek Vasut <marex@denx.de>