aboutsummaryrefslogtreecommitdiff
path: root/arch/arm/mach-mvebu
AgeCommit message (Collapse)AuthorFilesLines
2024-09-03arm: mvebu: turris_omnia: Use the i2c_eeprom misc driver for EEPROM reading ↵Marek Behún1-0/+1
in U-Boot proper Use the i2c_eeprom miscellaneous driver for reading Turris Omnia EEPROM in U-Boot proper. Keep using dm_i2c_read() in SPL build, since adding the i2c_eeprom driver to SPL build increases the image by 1.5 KiB. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2024-07-15arm: mach: marvell: Remove duplicate newlinesMarek Vasut3-8/+0
Drop all duplicate newlines. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
2024-07-08arm: mvebu: turris_omnia: Support old DDR3 trainingMarek Behún1-0/+1
Support old DDR3 training code on Turris Omnia, selectable via EEPROM field. Users experiencing DDR3 initialization failures or random crashes of the operating system due to incorrect DDR3 configuration can select the old DDR3 training implementation to fix those issues by setting the EEPROM field "Use old DDR training": eeprom update "Use old DDR training" 1 Signed-off-by: Marek Behún <kabel@kernel.org>
2024-07-08arm: mvebu: a38x: Add optional support for using old DDR3 training codeMarek Behún3-9/+33
Add optional support for using old DDR3 training code from 2017. The code lives in drivers/ddr/marvell/a38x/old/. To prevent symbol clashing with new DDR3 training code, a special header which renames all clashing symbols via macros is included and the symbols are prefixed with 'old_'. If old DDR3 training support is selected for a board, then the SPL initialization code calls a new function board_use_old_ddr3_training() to check whether it should use old DDR3 training code. The default weak implementation returns false, defaulting to new DDR3 training code. Boards that wish to support this need to select the ARMADA_38X_SUPPORT_OLD_DDR3_TRAINING config option and implement the old version of DDR topology provider, ddr3_get_topology_map(). Signed-off-by: Marek Behún <kabel@kernel.org>
2024-07-08ddr: marvell: a38x: debug: Allow compiling with immutable debug settings to ↵Marek Behún1-0/+10
reduce binary size Allow compiling with immutable debug settings: - DEBUG_LEVEL is always set to DEBUG_LEVEL_ERROR - register dumps are disabled This can save around 10 KiB of space in the resulting binary, which is a lot in U-Boot SPL. Signed-off-by: Marek Behún <kabel@kernel.org>
2024-07-08arm: mvebu: env_sf_get_env_addr() missing check for CONFIG_ENV_IS_IN_SPI_FLASHTony Dinh1-1/+1
The CONFIG_ENV_OFFSET is undefined if boot device is UART (CONFIG_MVEBU_SPL_BOOT_DEVICE_UART), or envs are not stored on flash (CONFIG_ENV_IS_NOWHERE). Check for CONFIG_ENV_IS_IN_SPI_FLASH as the first condition to determine whether env_sf_get_env_addr() should be provided. Signed-off-by: Tony Dinh <mibodhi@gmail.com>
2024-05-20Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"WIP/20May2024-nextTom Rini21-21/+10
As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-19Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""Tom Rini21-10/+21
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-06global: Make <asm/global_data.h> include <asm/u-boot.h>Tom Rini2-2/+0
This follows the example of RISC-V where <asm/global_data.h> includes <asm/u-boot.h> directly as "gd" includes a reference to bd_info already and so the first must include the second anyhow. We then remove <asm/u-boot.h> from all of the places which include references to "gd" an so have <asm/global_data.h> already. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-05-06arm: mvebu: Remove <common.h> and add needed includesTom Rini21-21/+12
Remove <common.h> from all mach-mvebu files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-04-04arm: mvebu: system-controller: Add support for SYSRESETMarek Behún4-7/+90
Add driver model support for sysreset via mvebu system controller. This is currently only available for U-Boot proper. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2024-04-04arm: mvebu: system-controller: Select mvebu-reset if DM_RESET && PCI_MVEBUMarek Behún1-1/+1
The mvebu-reset driver is only needed by the mvebu PCIe driver, but currently it is automatically selected if DM_RESET is enabled. Add the condition of PCI_MVEBU also being enabled for mvebu-reset to be selected. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2024-04-04arm: mvebu: system-controller: Rework to use UCLASS_SYSCONMarek Behún3-35/+54
The system-controller driver for 32-bit Armada is currently registered as UCLASS_RESET, since it only provides enabling/disabling PCIe ports. Rework it as UCLASS_SYSCON and bind mvebu-reset as a child device. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2024-04-04arm: mvebu: spl: Do not build mvebu-reset in SPLMarek Behún1-1/+2
Commit 35e29e89a386 ("arm: mvebu: Implement simple mvebu-reset driver for enabling/disabling PCIe ports") made it so that the mvebu reset driver for enabling/disabling PCIe ports is build if CONFIG_DM_RESET is enabled. This is because PCI_MVEBU depends on DM_RESET. But the driver should not be built for SPL. Indeed the PCI_MVEBU driver is not supported in SPL now, and so the mvebu-reset driver is not needed. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2024-01-11tools: kwbimage: Allow disabling build on non-mvebu platformsAlexander Dahl1-0/+1
Some users want to build with CONFIG_TOOLS_LIBCRYPTO disabled, which in general is possible for at least some boards. 32-bit mvebu however requires kwbimage for building SPL, and kwbimage has a hard dependency to host OpenSSL. The new symbol CONFIG_TOOLS_KWBIMAGE allows disabling kwbimage build on non-mvebu platforms, and thus building without host libcrypto from OpenSSL. Based on previous work and discussions, see links below. Link: https://lore.kernel.org/u-boot/20211021093304.25399-1-pali@kernel.org/ Link: https://lore.kernel.org/u-boot/20220111153120.1276641-1-marex@denx.de/ Link: https://lore.kernel.org/u-boot/20230121154743.667253-2-paulerwan.rio@gmail.com/ Cc: Marek Vasut <marex@denx.de> Cc: Paul-Erwan Rio <paulerwan.rio@gmail.com> Signed-off-by: Alexander Dahl <ada@thorsis.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2024-01-10arm: mvebu: AC5: Use finer grained memory mapChris Packham1-15/+51
The ATF implementation for AC5/AC5X ends up with bl31 living in some internal SRAM. This is in the middle of the large MMIO region that we were using. Adjust this to be finer grained blocks based on the address map from the AC5X Family Control and Management Subsystem Functional Datasheet. Signed-off-by: Chris Packham <judge.packham@gmail.com>
2023-11-07scsi: Forceably finish migration to DM_SCSIWIP/07Nov2023-nextTom Rini1-9/+0
The migration deadline for moving to DM_SCSI was v2023.04. A further reminder was sent out in August 2023 to the remaining platforms that had not migrated already, and that a few more over the line (or configs deleted). With this commit we: - Rename CONFIG_DM_SCSI to CONFIG_SCSI. - Remove all of the non-DM SCSI code. This includes removing other legacy symbols and code and removes some legacy non-DM AHCI code. - Some platforms that had previously been DM_SCSI=y && SCSI=n are now fully migrated to DM_SCSI as a few corner cases in the code assumed DM_SCSI=y meant SCSI=y. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-11-07arm: Drop <common.h> from remaining header filesTom Rini1-2/+0
None of these header files need to include <common.h> so we can just drop that entirely. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-10-26arm: mvebu: allow additional 4096 offset for bootable mmc imageJosua Mayer1-2/+3
Disarm the error message forcing u-boot/spl image to be located at sector 0 on eMMC data-partition and microSD. Offset 0 makes sense on eMMC boot partitions only, data partition must use 4096 to avoid conflicting with MBR. Valid offsets when booting from microSD, reported by boot-rom v1.73: BootROM: Bad header at offset 00000200 BootROM: Bad header at offset 00004400 BootROM: Bad header at offset 00200000 BootROM: Bad header at offset 00400000 BootROM: Bad header at offset 00600000 BootROM: Bad header at offset 00800000 BootROM: Bad header at offset 00A00000 BootROM: Bad header at offset 00C00000 BootROM: Bad header at offset 00E00000 BootROM: Bad header at offset 01000000 BootROM: Bad header at offset 01200000 BootROM: Bad header at offset 01400000 BootROM: Bad header at offset 01600000 BootROM: Bad header at offset 01800000 BootROM: Bad header at offset 01A00000 BootROM: Bad header at offset 01C00000 BootROM: Bad header at offset 01E00000 BootROM: Bad header at offset 02000000 BootROM: Bad header at offset 02200000 BootROM: Bad header at offset 02400000 BootROM: Bad header at offset 02600000 BootROM: Bad header at offset 02800000 BootROM: Bad header at offset 02A00000 BootROM: Bad header at offset 02C00000 BootROM: Bad header at offset 02E00000 Valid offsets when booting from eMMC: BootROM: Bad header at offset 00000000 BootROM: Bad header at offset 00200000 Switching BootPartitions. BootROM: Bad header at offset 00000000 BootROM: Bad header at offset 00200000 Fixes: 2226ca17348 ("arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header") Signed-off-by: Josua Mayer <josua@solid-run.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-10-26arm: mvebu: turris_mox: Extend to support RIPE Atlas ProbeMarek Behún1-1/+5
Extend Turris Mox board code to support CZ.NIC's RIPE Atlas Probe. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2023-10-17spl: mmc: Introduce proper layering for spl_mmc_get_uboot_raw_sector()Marek Vasut1-2/+2
Introduce two new weak functions, arch_spl_mmc_get_uboot_raw_sector() and board_spl_mmc_get_uboot_raw_sector(), each of which can be overridden at a matching level, that is arch/ and board/ , in addition to the existing weak function spl_mmc_get_uboot_raw_sector(). This way, architecture code can define a default architecture specific implementation of arch_spl_mmc_get_uboot_raw_sector(), while the board code can override that using board_spl_mmc_get_uboot_raw_sector() which takes precedence over the architecture code. In some sort of unlikely special case where code has to take precedence over board code too, the spl_mmc_get_uboot_raw_sector() is still left out to be a weak function, but it should be unlikely that this is ever needed to be overridden. Signed-off-by: Marek Vasut <marex@denx.de>
2023-08-15common: return type board_get_usable_ram_topHeinrich Schuchardt1-1/+1
board_get_usable_ram_top() returns a physical address that is stored in gd->ram_top. The return type of the function should be phys_addr_t like the current type of gd->ram_top. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2023-07-13arm: mvebu: Add Allied Telesis x240 boardChris Packham1-0/+7
The x240 and SE240 are a series of L2+ switches from Allied Telesis. There are a number of them in the range but as far as U-Boot is concerned all the CPU block components are the same so there's only one board defined. Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-07-13arm: mvebu: ac5: Define mvebu_get_nand_clock()Chris Packham1-0/+6
The NF_CLK for the AC5 SoC runs at 400MHz. There's no strapping or gating require so just add a mvebu_get_nand_clock() that returns this value. Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-05-06drivers: fix debug string with fdt_addr_t inputJohan Jonker1-1/+1
The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU can expect 64-bit data from the device tree parser, so fix some debug strings with fdt_addr_t to be able to handle both sizes. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-05-06drivers: use dev_read_addr_ptr when cast to pointerJohan Jonker1-2/+2
The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU can expect 64-bit data from the device tree parser, so use dev_read_addr_ptr instead of the dev_read_addr function in the various files in the drivers directory that cast to a pointer. As we are there also streamline the error response to -EINVAL on return. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-13arm: mvebu: spl: Allow to build SATA kwbimage for 4K Native disksPali Rohár3-0/+18
Add a new config option CONFIG_MVEBU_SPL_SATA_BLKSZ for specifying block size of SATA disk. This information is used during building of SATA kwbimage and must be correctly set, otherwise BootROM does not load SPL. For 4K Native disks CONFIG_MVEBU_SPL_SATA_BLKSZ must be set to 4096. Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Martin Rowe <martin.p.rowe@gmail.com>
2023-04-13arm: mvebu: spl: Do not hardcode SATA block size to 512Pali Rohár1-3/+8
Find SATA block device by blk_get_devnum_by_uclass_id() function and read from it the real block size of the SATA disk. Signed-off-by: Pali Rohár <pali@kernel.org>
2023-03-30arm: mvebu: Define all options for AXP BOOT_FROM_* macrosPali Rohár1-0/+4
Definitions are according to the MV78460 Hardware Specifications. Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Tested-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: Define all BOOTROM_ERR_MODE_* macrosPali Rohár1-0/+7
A385 BootROM fills into bits [31:28] of register 0x182d0 tracing value, which represents in which state BootROM currently is. BootROM fills one of the possible values: 0x2 (CPU initialization), 0x3 (UART detection), 0x6 (UART booting), 0x8 (PCI Express booting), 0x9 (parallel or SPI NOR booting), 0xA (parallel or SPI NAND booting), 0xB (SATA booting) and 0xE (SD / eMMC booting). Meaning of these values matches TRACE_* macros from Marvell soc_spec.h file: https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013.01-armada-18.06/tools/marvell/doimage_mv/soc_spec.h Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Tested-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: Define all options for A38x BOOT_FROM_* macrosPali Rohár1-4/+7
Disassembling A385 BootROM binary reveal how BootROM interprets strapping pins for Boot Device Mode. All possible options are: 0x00..0x07 -> Parallel NOR 0x08..0x15 -> Parallel NAND 0x16..0x17 -> Parallel NOR 0x18..0x25 -> Parallel NAND 0x26..0x27 -> SPI NAND 0x28..0x29 -> UART xmodem 0x2a..0x2b -> SATA 0x2c..0x2d -> PCI Express 0x2e..0x2f -> Parallel NOR 0x30..0x31 -> SD / eMMC 0x32..0x39 -> SPI NOR 0x3a..0x3c -> Parallel NOR 0x3d..0x3e -> UART debug console 0x3f -> Invalid Note that Boot Device Mode Options in A38x Hardware Specifications is incomplete. Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Tested-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: Convert BOOT_FROM_* constants to function macrosPali Rohár2-23/+22
This allows to merge BOOT_FROM_MMC and BOOT_FROM_MMC_ALT constants to one macro. And also allows to extend other BOOT_FROM_* macros for other variants. Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Tested-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constantPali Rohár2-3/+1
A385 BootROM treats strapping configuration 0x22 as SPI-NAND. So remove incorrect definition 0x22 as SATA. SATA on A385 has configuration 0x2A. Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Tested-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constantPali Rohár2-4/+0
A385 BootROM treats strapping configuration 0x3f as invalid. When booting fails (e.g. because of invalid configuration) then BootROM fallbacks to UART booting. Detecting BootROM fallback to UART booting is implemented in U-Boot since commit 2fd4284051e3 ("ARM: mach-mvebu: handle fall-back to UART boot"). So there is no need to define BOOT_FROM_UART_ALT constant and special handling for it anymore, remove it. This change effectively revers commit f3a88e2ca17a ("arm: mvebu: fix boot from UART on ClearFog Base"). Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Tested-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: Cleanup get_boot_device() codePali Rohár1-5/+10
Show correct information in debug() output and use correct names for variables. No functional change. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdtMartin Rowe1-0/+1
[upstream of vendor commit 19a96f7c40a8fc1d0a6546ac2418d966e5840a99] The Clearfog devices have only one SDHC device. This is either eMMC if it is populated on the SOM or SDHC if not. The Linux device tree assumes the SDHC case. Detect if the device is an eMMC and fixup the device-tree so it will be detected by Linux. Ported from vendor repo at https://github.com/SolidRun/u-boot Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-24arm: mvebu: Set common SPI flash default speed and modeTony Dinh1-0/+10
CONFIG_SF_DEFAULT_SPEED is used in SPL SPI to configure and probe the flash device during DM SPI uclass probing process, if the spi-max-frequency is not available in the DTB. Currently the max frequency is not available, because of the probing mechanism in SPI uclass has not been fully updated to DM. The CONFIG_SF_DEFAULT_SPEED is set to 1Mhz if a board defconfig does not specify it. This speed is too slow and result in a few seconds delay while the u-boot image is loaded from flash. Based on a survey of the device tree specifications for MVEBU boards, a sane default value should be 10Mhz. The default of 10Mhz enables an almost instantaneously loading of the u-boot image. Note that this patch depends on this patch series (has been merged to u-boot-marvell/next): https://lists.denx.de/pipermail/u-boot/2023-March/511038.html - RESEND: correct spelling of SF_DEFAULT_MODE Signed-off-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-02mvebu: Drop empty arch_misc_initTom Rini2-12/+0
If this hooks is needed later, it should be added and populated for real. Cc: Stefan Roese <sr@denx.de> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-02mvebe: Drop ARCH_MISC_INIT from alleycat 5Tom Rini1-9/+0
In this platform, arch_misc_init doesn't perform any real function. The call to get_soc_type_rev has no lasting side effects. Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
2023-03-01arm: mvebu: Define SPL memory mapsPali Rohár1-0/+16
In SPL are active memory maps set by the BootROM. Define them in cpu.h file to the correct values. Some peripherals are not mapped at all. Signed-off-by: Pali Rohár <pali@kernel.org>
2023-03-01arm: mvebu: Define env_sf_get_env_addr() also for Proper U-BootPali Rohár3-13/+14
Proper U-Boot moves SPI0 CS0 Flash mapping from 0xD4000000 to 0xF4000000 and change its size from 64 MB to 8 MB. Definitions are already in MBUS_SPI_BASE/MBUS_SPI_SIZE macros. So define these macros also for SPL build, use them in env_sf_get_env_addr() function and move this function from spl.c to cpu.c to be available in Proper U-Boot too. Signed-off-by: Pali Rohár <pali@kernel.org>
2023-03-01arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mappingPali Rohár1-1/+1
Signed-off-by: Pali Rohár <pali@kernel.org>
2023-03-01arm: mvebu: Remove A39x relictsPali Rohár4-44/+8
Signed-off-by: Pali Rohár <pali@kernel.org>
2023-03-01arm: mvebu: Fix description of MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) optionsPali Rohár1-2/+2
MVEBU_SPL_BOOT_DEVICE_SPI is for NOR flash. Either serial or parallel. Not for general serial/SPI devices. The correct name should be BOOT_DEVICE_NOR but name SPI is already used in mkimage config format which we do not want to change for compatibility reasons. MVEBU_SPL_BOOT_DEVICE_MMC is for MMC and SD compatible devices. Not for SDIO devices. In most cases used for eMMC or SD card. Signed-off-by: Pali Rohár <pali@kernel.org>
2023-03-01arm: mvebu: Add support for generating PEX kwbimagePali Rohár2-0/+7
Add a new Kconfig option CONFIG_MVEBU_SPL_BOOT_DEVICE_PEX which instruct make to generate kwbimage with PEX header. This image is used for booting from PCI Express device which is in the Root Complex mode. Support is very simple, SPL after finishes DDR training returns back to the BootROM (via CONFIG_SPL_BOOTROM_SUPPORT option) and BootROM then start executing U-Boot proper. Signed-off-by: Pali Rohár <pali@kernel.org>
2023-03-01arm: mvebu: Add support for generating NAND kwbimagePali Rohár3-0/+28
Add a new Kconfig option CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND which instruct make to generate kwbimage with NAND header. This image is used for booting from NAND flash (either SPI or parallel). Support is very simple, SPL after finishes DDR training returns back to the BootROM (via CONFIG_SPL_BOOTROM_SUPPORT option) and BootROM then loads and executes U-Boot proper. To generate correct kwbimage NAND header, it is required to set following Kconfig options: CONFIG_SYS_NAND_PAGE_SIZE CONFIG_SYS_NAND_BLOCK_SIZE CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION They are used only by make / mkimage when generating final kwbimage. CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION is a new mvebu specific Kconfig option which is set into kwbimage NAND_BADBLK_LOCATION header field. Signed-off-by: Pali Rohár <pali@kernel.org>
2023-03-01arm: mvebu: spl: Fix support for loading U-Boot proper from SD cardPali Rohár2-9/+32
Marvell BootROM loads MMC image from sector 0 (HW boot or data partition) and SD image from sector 1. So for SD card booting it is needed to not use constant CONFIG MMC options and instead of them it is needed to define functions spl_mmc_boot_mode() spl_mmc_get_uboot_raw_sector() which determinate offsets at SPL runtime based on MMC or SD card. Calculation of SD card sector expects following values: CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET=0 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0 Fixes: 2226ca173486 ("arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header") Signed-off-by: Pali Rohár <pali@kernel.org>
2023-03-01arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partitionPali Rohár2-1/+8
When eMMC boot is selected then BootROM loads kwbimage header (U-Boot SPL) from the selected eMMC boot partition. So for eMMC boot ensure that U-Boot SPL loads U-Boot proper (from kwbimage) also from the same selected eMMC boot partition. Fixes: 2226ca173486 ("arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header") Signed-off-by: Pali Rohár <pali@kernel.org>
2023-03-01arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and BOOT_DEVICE_MMC2_2Pali Rohár1-3/+1
BOOT_DEVICE_MMC2 and BOOT_DEVICE_MMC2_2 are representing mmc dev 1 but all Armada SoCs have only one mmc controller. So remove references to non-existent second mmc controller. Fixes: f830703f4284 ("arm: mvebu: Check that kwbimage blockid matches boot mode") Signed-off-by: Pali Rohár <pali@kernel.org>
2023-03-01arm: mvebu: spl: Fix parsing SATA kwbimagePali Rohár1-11/+2
Despite the official specification, Marvell BootROM does not interpret srcaddr from SATA image as number of sectors the beginning of the hard drive, but as number of sectors relative to the main header. To process SATA kwbimage and load U-Boot proper from it in the same way as Marvell BootROM, it is needed to interpret srcaddr as relative offset to the main header. This change fixes booting of U-Boot proper from SPL code in SATA image. Fixes: 2226ca173486 ("arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header") Signed-off-by: Pali Rohár <pali@kernel.org>
generated by cgit v1.1 at 2024-10-09 05:48:01 +0000