summaryrefslogtreecommitdiff
path: root/arch/arm/mach-mvebu
AgeCommit message (Collapse)Author
2023-02-13arm: mvebu: Add support for Synology DS116 (Armada 385)Tony Dinh
Synology DS116 is a NAS based on Marvell Armada 385 SoC. Board Specification: - Marvel MV88F6820 Dual Core at 1.8GHz - 1 GiB DDR3 RAM - 8MB Macronix mx25l6405d SPI flash - I2C - 2x USB 3.0 - 1x GBE LAN port (PHY: Marvell 88E1510) - 1x SATA (6 Gbps) - 3x LED - PIC16F1829 (connected to uart1) - GPIO fan - serial console Note that this patch depends on the add-support for Thecus N2350 patch: https://patchwork.ozlabs.org/project/uboot/patch/20230201231306.7010-1-mibodhi@gmail.com/ Signed-off-by: Tony Dinh <mibodhi@gmail.com>
2023-02-13arm: mvebu: Add support for Thecus N2350 (Armada 385) boardTony Dinh
Thecus N2350 is a NAS based on Marvell Armada 385 SoC. Specification: - Processor: Marvel MV88F6820 Dual Core at 1GHz - 1 GiB DDR4 RAM - 4MB Macronix mx25l3205d SPI flash - 512MB Hynix H27U4G8F2DTR-BC NAND flash - I2C - 2x USB 3.0 - 1x GBE LAN port (PHY: Marvell 88E1510) - 2x SATA (hot swap slots) - 3x buttons - 10x LEDS - serial console Signed-off-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-02-09Correct SPL uses of ARMADA_8KSimon Glass
This converts 2 usages of this option to the non-SPL form, since there is no SPL_ARMADA_8K defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org>
2023-02-09Correct SPL uses of ARMADA_3700Simon Glass
This converts 2 usages of this option to the non-SPL form, since there is no SPL_ARMADA_3700 defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org>
2023-02-09Correct SPL uses of ALLEYCAT_5Simon Glass
This converts 2 usages of this option to the non-SPL form, since there is no SPL_ALLEYCAT_5 defined in Kconfig Signed-off-by: Simon Glass <sjg@chromium.org>
2023-02-07arm: mvebu: Drop reference to CONFIG_ARMADA_39XSimon Glass
This is not defined anywhere. Drop it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de>
2023-02-07arm: mvebu: Remove reference to ARMADA_370Simon Glass
Drop this as it is not referenced anywhere else in the code. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-12-23configs: Remove unused or redundant CONFIG symbolsTom Rini
A number of CONFIG symbols have crept in that are never referenced in code, so drop them here. Further, we have two symbols being enabled in headers while already enabled correctly in Kconfig, so these lines can also be removed. Signed-off-by: Tom Rini <trini@konsulko.com>
2022-12-23global: Migrate CONFIG_SAR_REG to CFGTom Rini
Perform a simple rename of CONFIG_SAR_REG to CFG_SAR_REG Signed-off-by: Tom Rini <trini@konsulko.com>
2022-12-23global: Migrate CONFIG_SAR2_REG to CFGTom Rini
Perform a simple rename of CONFIG_SAR2_REG to CFG_SAR2_REG Signed-off-by: Tom Rini <trini@konsulko.com>
2022-12-22global: Remove unused CONFIG symbolsTom Rini
This removes the following unreferenced CONFIG symbols: CONFIG_FDTADDR CONFIG_FDTFILE CONFIG_FLASH_SECTOR_SIZE CONFIG_FSL_CPLD CONFIG_HDMI_ENCODER_I2C_ADDR CONFIG_I2C_MVTWSI CONFIG_I2C_RTC_ADDR CONFIG_IRAM_END CONFIG_IRAM_SIZE CONFIG_KSNET_MDIO_PHY_CONFIG_ENABLE CONFIG_L1_INIT_RAM CONFIG_MACB_SEARCH_PHY CONFIG_MIU_2BIT_21_7_INTERLEAVED CONFIG_MTD_NAND_VERIFY_WRITE CONFIG_MVGBE_PORTS CONFIG_NETDEV CONFIG_NUM_DSP_CPUS CONFIG_PHY_BASE_ADR CONFIG_PHY_INTERFACE_MODE CONFIG_PSRAM_SCFG CONFIG_RAMBOOT_SPIFLASH CONFIG_RAMBOOT_TEXT_BASE CONFIG_RD_LVL CONFIG_ROCKCHIP_SDHCI_MAX_FREQ CONFIG_SETUP_INITRD_TAG CONFIG_SH_QSPI_BASE CONFIG_SMDK5420 CONFIG_SOCRATES CONFIG_SPI_ADDR CONFIG_SPI_FLASH_QUAD CONFIG_SPI_FLASH_SIZE CONFIG_SPI_HALF_DUPLEX CONFIG_SPI_N25Q256A_RESET CONFIG_TEGRA_SLINK_CTRLS CONFIG_TPM_TIS_BASE_ADDRESS CONFIG_UBOOT_SECTOR_COUNT CONFIG_UBOOT_SECTOR_START CONFIG_VAR_SIZE_SPL CONFIG_VERY_BIG_RAM And also: BL1_SIZE PHY_NO RESERVE_BLOCK_SIZE Signed-off-by: Tom Rini <trini@konsulko.com>
2022-12-05global: Move remaining CONFIG_SYS_* to CFG_SYS_*Tom Rini
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS namespace do not easily transition to Kconfig. In many cases they likely should come from the device tree instead. Move these out of CONFIG namespace and in to CFG namespace. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-12-05global: Move remaining CONFIG_SYS_SDRAM_* to CFG_SYS_SDRAM_*Tom Rini
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM namespace do not easily transition to Kconfig. In many cases they likely should come from the device tree instead. Move these out of CONFIG namespace and in to CFG namespace. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-11-07arm: mvebu: Add RD-AC5X boardChris Packham
The RD-AC5X-32G16HVG6HLG-A0 development board main components and features include: * Main 12V/54V power supply * 270 Gbps throughput packet processor on the main board * DDR4: * SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs) * SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs) * PCB co-layout with 4GB device to support 8GB (Dual CS) requirement * 16GB eMMC (Samsung KLMAG1JETD-B041006) * 16MB SPI NOR(GD25Q127C) * 32 x 1000 Base-T interfaces * 16 x 2500 Base-T interfaces * SR1: 88E2540*4 * SR2: 88E2580*1+88E2540*2 * Six (6) x 25G Base-R SFP28 interfaces * One (1) x RJ-45 console connector, interfacing to the on board UART * One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0) * One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1) * One (1) x RJ-45 1G Base-T Management port, interfacing to the host port (shared with PCIe) Connected to 88E1512 Gigabit Ethernet Phy * One (1) x Oculink port, interfacing to the PCIe port for external CPU connection * POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~ Port 48 (Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881 solution) * POE total power budget 780W * LED interfaces per network port/POE * LED interfaces (common) showing system status * PTP TC mode Supported (Reserved M.2 connector to support BC mode) Signed-off-by: Chris Packham <judge.packham@gmail.com>
2022-11-07arm: mvebu: Support for 98DX25xx/98DX35xx SoCChris Packham
Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with an integrated CPU (referred to as the CnM block in Marvell's documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support has been ported from Marvell's SDK which is based on a much older version of U-Boot. Signed-off-by: Chris Packham <judge.packham@gmail.com>
2022-10-06arm: mvebu: Add support for specifying VHV_Enable GPIOPali Rohár
VHV_Enable GPIO is required to enable during eFuse programming on Armada SoCs not from 3700 family. Add support for enabling and disabling VHV pin via GPIO during eFuse programming, when specified. All details are in Marvell AN-389: ARMADA VHV Power document (Doc. No. MV-S302545-00 Rev. C, August 2, 2016). Note that due to HW Errata 3.6 eFuse erroneous burning (Ref #: HWE-3718342) VHV power must be disabled while core voltage is off to prevent erroneous eFuse programming. This is specified in Marvell ARMADA 380/385/388 Functional Errata, Guidelines, and Restrictions document (Doc. No. MV-S501377-00 Rev. D, December 1, 2016). Signed-off-by: Pali Rohár <pali@kernel.org>
2022-10-06arm: mvebu: Add support for programming LD0 and LD1 eFusePali Rohár
This patch implements LD eFuse programming support. Armada 385 contains two LD eFuse lines, each is 256 bit long with one additional lock bit. LD 0 line is mapped to U-Boot fuse bank 64 and LD 1 line to fuse bank 65. U-Boot 32-bit fuse words 0-8 are mapped to LD eFuse line bits 0-255. U-Boot fuse word 9 is mapped to LD eFuse line lock bit. So to program LD 1 General Purpose Data line, use U-Boot fuse command: => fuse prog -y 65 0 0x76543210 => fuse prog -y 65 1 0xfedcba98 => fuse prog -y 65 2 0x76543210 => fuse prog -y 65 3 0xfedcba98 => fuse prog -y 65 4 0x76543210 => fuse prog -y 65 5 0xfedcba98 => fuse prog -y 65 6 0x76543210 => fuse prog -y 65 7 0xfedcba98 => fuse prog -y 65 8 0x1 Signed-off-by: Pali Rohár <pali@kernel.org>
2022-10-06arm: mvebu: Remove timer.cStefan Roese
Since the move to CONFIG_TIMER with support for CONFIG_TIMER_EARLY, this platform specific init_timer() function is not needed any more. Let's remove it completely. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Michael Walle <michael@walle.cc> Cc: Pali Rohár <pali@kernel.org>
2022-09-23board_f: Fix types for board_get_usable_ram_top()Pali Rohár
Commit 37dc958947ed ("global_data.h: Change ram_top type to phys_addr_t") changed type of ram_top member from ulong to phys_addr_t but did not changed types in board_get_usable_ram_top() function which returns value for ram_top. So change ulong to phys_addr_t type also in board_get_usable_ram_top() signature and implementations. Fixes: 37dc958947ed ("global_data.h: Change ram_top type to phys_addr_t") Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-09-20arm: mvebu: Use CONFIG_TIMER on all MVEBU & KIRKWOOD platformsStefan Roese
Now that the new timer support is available for these platforms, let's select this IF for all these platforms. This way it's not necessary that each board changes it's config header. Signed-off-by: Stefan Roese <sr@denx.de> Tested-by: Tony Dinh <mibodhi@gmail.com>
2022-09-19Merge branch 'master' into nextTom Rini
Signed-off-by: Tom Rini <trini@konsulko.com>
2022-09-13arm: mvebu: Fix moving internal registersPali Rohár
Commit 5bb2c550b11e ("arm: mvebu: Move internal registers in arch_very_early_init() function") moved code from file cpu.c to lowlevel.c, which moves Marvell internal registers from address INTREG_BASE_ADDR_REG to SOC_REGS_PHY_BASE. But the steps describing how to do it correctly were documented only in older U-Boot versions and commit cefd764222ee ("arm: mvebu: Fix internal register config on A38x") probably unintentionally removed important details about MMU from code comments around. Commit 5bb2c550b11e ("arm: mvebu: Move internal registers in arch_very_early_init() function") implemented code movement according to (now incomplete) comments which resulted in semi-broken code. The result is that I-cache is currently disabled for all Armada 38x boards and maybe there are some other (unreported / undetected) issues. Reimplement it correctly. First flush all caches, then disable MMU and L2 cache and then move Marvell internal registers. There is no need to explicitly disable I-cache. After this change lzmadec command with lzma image of 0x7000000 bytes is doing decompression just 5 seconds. Before this change it was 30 seconds. To make lowlevel.S code more readable, extend asm/pl310.h header file to be compatible with assembler and use macros from this file. Fixes: 5bb2c550b11e ("arm: mvebu: Move internal registers in arch_very_early_init() function") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-09-13arm: mvebu: Enable L2 cache also on Armada 38xPali Rohár
For some unknown reason when L2 cache is disabled on Armada 385 then loadb, loadx and loady commands do not work with higher baudrates than 115200 (they just abort transfer) and lzmadec command with lzma image of size 0x7000000 (maybe even smaller, we tested this one) is doing decompression for more than 2 minutes. After enabling L2 cache decompression takes only 30s and loadb, loadx and loady are stable and working fine. git bisect identified problematic commit 3308933d2fe9 ("arm: mvebu: Avoid reading MVEBU_REG_PCIE_DEVID register too many times"). Before this commit above issues were not present. But investigation showed that above issue was possible to reproduce also by reverting that commit and forcing compiler to do inline optimization of mvebu_soc_family() function. Which seems that the root of this issue is in caches and position of instruction of segments. So currently it is unknown what is or was broken, but code movement, code inlining or other compiler optimization triggered it. Commit 3e5ce7ceeb94 ("arm: mvebu: Enable L2 cache on Armada XP") mentioned that enabling L2 cache on Armada XP improved performance and that Armada 38x has L2 disabled (which is default state) and if needed it has to be enabled in separate patch. As enabling L2 cache also improve performance on Armada 38x, enable it. Note that Aurora cache in no outer mode is available only on Armada XP, hence it is not touched for Armada 38x code. Fixes: 3308933d2fe9 ("arm: mvebu: Avoid reading MVEBU_REG_PCIE_DEVID register too many times") Reported-by: Marek Behún <kabel@kernel.org> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-09-13arm: mvebu: lowlevel.S: Use CR_M from asm/system.hPali Rohár
Replace magic constant 1 when disabling MMU by macro CR_M from include header file asm/system.h. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-09-13arm: mvebu: Guard non-AXP code by checking for AXPPali Rohár
Commit c86d53fd88df ("arm: mvebu: Don't disable cache at startup on Armada XP at all") introduced branch for non-AXP code which was guarded by A38X condition. Fix this issue by checking for AXP platform, not by A38X. Fixes: c86d53fd88df ("arm: mvebu: Don't disable cache at startup on Armada XP at all") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-09-13arm: mvebu: Fix function enable_cachesPali Rohár
Commit 3308933d2fe9 ("arm: mvebu: Avoid reading MVEBU_REG_PCIE_DEVID register too many times") broke support for caches on all Armada SoCs. Before that commit there was code: if (mvebu_soc_family() != MVEBU_SOC_A375) { dcache_enable(); } And after that commit there is code: if (IS_ENABLED(CONFIG_ARMADA_375)) { dcache_enable(); } Comment above this code says that d-cache should be disabled on Armada 375. But new code inverted logic and broke Armada 375 and slowed down all other Armada SoCs (including A38x). Fix this issue by changing logic to: if (!IS_ENABLED(CONFIG_ARMADA_375)) { dcache_enable(); } Which matches behavior prior that commit. Fixes: 3308933d2fe9 ("arm: mvebu: Avoid reading MVEBU_REG_PCIE_DEVID register too many times") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-09-13arm: mvebu: Mark constant data with const keywordPali Rohár
Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-09-01Convert CONFIG_SYS_L2_PL310 to KconfigPhilip Oberfichtner
This converts CONFIG_SYS_L2_PL310 to Kconfig. For omap2 and mvebu the 'select SYS_L2_PL310' locations were determined using ./tools/moveconfig -i CONFIG_SYS_L2_PL310. For mx6 I manually chose ARCH_MX6 as 'select' location. The correctness has been verified using $ ./tools/moveconfig.py -f ARCH_MX6 ~SYS_L2_PL310 ~SYS_L2CACHE_OFF 0 matches That means whenever an ARCH_MX6 board had SYS_L2_PL310 disabled, this was correctly reflected in SYS_L2CACHE_OFF. Thus it's safe to insert the 'select' statement under ARCH_MX6. Signed-off-by: Philip Oberfichtner <pro@denx.de>
2022-08-23arm: kirkwood: make it CONFIG_TIMER awareMichael Walle
If we switch to CONFIG_TIMER, we don't need the legacy timer macros and functions anymore. Add the proper guards to exclude them from compiling. Cc: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-08-23arm: mvebu: mbus: Fix mbus driver to work also after U-Boot relocationPali Rohár
mbus driver is initialized from arch_cpu_init() callback which is called before relocation. This driver stores lot of functions and structure pointers into global variables, so it is data position dependent. Therefore after relocations all pointers are invalid and driver does not work anymore as all pointers referes to the old memory, which overlaps with CONFIG_SYS_LOAD_ADDR and ${loadaddr}. For example U-Boot fuse command crashes if loadaddr memory is cleared or rewritten by some image loaded by U-Boot load command. mw.w ${loadaddr} 0x0 10000 fuse read 0 1 2 Fix this issue by removing of all mbus global variables in which are stored pointers to structures or functions which changes during relocation. And replace it by direct function calls (not via pointers). With this change fuse command finally works. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Stefan Roese <sr@denx.de>
2022-08-23arm: mvebu: Define env_sf_get_env_addr() for all Armada boards in SPLPali Rohár
SPI0 CS0 Flash is mapped to address range 0xD4000000 - 0xD7FFFFFF by BootROM. Proper U-Boot removes this direct mapping. So it is available only in SPL. This applies for all 32-bit Armada BootROMs. SPL mvebu code is used only on 32-bit Armada SoCs. So move env_sf_get_env_addr() function from Turris Omnia board to common SPL mvebu code and add proper checks for SPI0 CS0. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-08-09arm: mvebu: spl: Always fallback to BootROM boot methodPali Rohár
BootROM boot method should always work so always add it as fallback method to spl_boot_list. In case U-Boot SPI driver fails it is better to try using BootROM than hanging as by default only one boot method is specified. Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2022-07-21arm: mvebu: Avoid reading MVEBU_REG_PCIE_DEVID register too many timesPali Rohár
Change detection of platform/cpu from runtime to compile time via config define. This completely eliminates compiling code which is not going to run on selected platform. Code which parses and prints device / revision id still reads device id from MVEBU_REG_PCIE_DEVID register, but only once. Signed-off-by: Pali Rohár <pali@kernel.org> Acked-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-07-21treewide: Fix Marek's name and change my e-mail addressMarek Behún
Fix diacritics in some instances of my name and change my e-mail address to kabel@kernel.org. Add corresponding .mailmap entries. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-07-21arm64: mvebu: handle non-zero base address for RAMChris Packham
board_get_usable_ram_top() conflated the RAM size with the top address of RAM. On systems where RAM starts at address 0 these numbers are the same so it went unnoticed. Update board_get_usable_ram_top() to take CONFIG_SYS_SDRAM_BASE into account when determining the top address. Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2022-06-06arm: mvebu: Use MVEBU_SPL_BOOT_DEVICE instead of SPL_BOOT_DEVICEChris Packham
Update the way KWB_CFG_SEC_BOOT_DEV is determined to use CONFIG_MVEBU_SPL_BOOT_DEVICE_{SPI,MMC} instead of CONFIG_SPL_BOOT_DEVICE. Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2022-06-06Migrate CUSTOM_SYS_INIT_SP_ADDR to Kconfig using system-constants.hTom Rini
- Make all users of CUSTOM_SYS_INIT_SP_ADDR reference SYS_INIT_SP_ADDR - Introduce HAS_CUSTOM_SYS_INIT_SP_ADDR to allow for setting the stack pointer directly, otherwise we use the common calculation. - On some platforms that were using the standard calculation but did not set CONFIG_SYS_INIT_RAM_SIZE / CONFIG_SYS_INIT_RAM_ADDR, set them. - On a small number of platforms that were not subtracting GENERATED_GBL_DATA_SIZE do so now via the standard calculation. - CONFIG_SYS_INIT_SP_OFFSET is now widely unused, so remove it from most board config header files. Signed-off-by: Tom Rini <trini@konsulko.com>
2022-06-06mvebu: Use CONFIG_SPL_STACK + 4 directly for bootparam locationTom Rini
The definition of CONFIG_SPL_BOOTROM_SAVE is always a fixed CONFIG_SPL_STACK + 4, while CONFIG_SPL_STACK is not constant. This change will make it clear where the location is still, once CONFIG_SPL_STACK moves to Kconfig. Cc: Stefan Roese <sr@denx.de> Signed-off-by: Tom Rini <trini@konsulko.com>
2022-05-16arm: mvebu: Move internal registers in arch_very_early_init() functionPali Rohár
Moving of internal registers from INTREG_BASE_ADDR_REG to SOC_REGS_PHY_BASE needs to be done very early, prior calling any function which may touch internal registers, like debug_uart_init(). So do it earlier in arch_very_early_init() instead of arch_cpu_init(). Movement is done in proper U-Boot, not in SPL. SPL may return to bootrom and bootrom requires internal registers at (old) expected location. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2022-05-16arm: mvebu: Remove unused ARMADA_64BITChris Packham
Nothing selects ARMADA_64BIT. Instead the 64-bit SoCs just select ARM64 directly. Remove the unused config item. Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2022-04-21arm: mvebu: a37xx: Add support for writing Security OTP valuesPali Rohár
Implement write support for Security OTP values via mailbox API commands MBOX_CMD_OTP_WRITE_32B and MBOX_CMD_OTP_WRITE. Write support for North and South Bridge OTPs are not implemented as these OTPs are already burned in factory with some data. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz>
2022-04-21arm: mvebu: Enable CONFIG_SPL_SYS_NO_VECTOR_TABLE for 32-bit mvebuPali Rohár
U-Boot SPL is on 32-bit mvebu executed by the BootROM. And BootROM expects that U-Boot SPL returns execution back to the BootROM. Vectors during execution of U-Boot SPL should not be changed as BootROM does not expect it and uses its own vectors. So do not overwrite vectors in SPL build. Signed-off-by: Pali Rohár <pali@kernel.org>
2022-04-21arm: mvebu: Add support for reading LD0 and LD1 eFusePali Rohár
Armada 385 contains 64 lines of HD eFuse and 2 lines of LD eFuse. HD eFuse is used for secure boot and each line is 64 bits long + 1 lock bit. LD eFuse lines are 256 bits long + 1 lock bit. LD 0 line is reserved for Marvell Internal Use and LD 1 line is for General Purpose Data. U-Boot already contains HD eFuse reading and programming support. This patch implements LD eFuse reading support. LD 0 line is mapped to U-Boot fuse bank 64 and LD 1 line to fuse bank 65. LD 0 Marvell Internal Use line seems that was burned in factory with some data and can be read by U-Boot fuse command: => fuse read 64 0 9 LD 1 General Purpose Data line is by default empty and can be read by U-Boot fuse command: => fuse read 65 0 9 Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz>
2022-04-21arm: mvebu: a37xx: Add support for reading Security OTP valuesPali Rohár
It is not possible for the A53 core (on which U-Boot is running) to read it directly. For this purpose Marvell defined mbox API for sending OTP commands between CM3 and A53 cores. Implement these Marvell fuse reading mbox commands via U-Boot fuse API. Banks 0-43 are used for accessing Security OTP (44 rows with 67 bits via 44 banks and words 0-2). Note that of the 67 bits, the 3 upper bits are: 1 lock bit and 2 auxiliary bits (meant for testing during the manufacture of the SOC, as I understand it). Also note that the lock bit and the auxiliary bits are not readable via Marvell commands. With CZ.NIC's commands the lock bit is readable. Write support is not implemented yet. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2022-04-21arm: mvebu: a37xx: Extend mbox_do_cmd() codePali Rohár
Allow to specify input parameters, define all available mbox commands supported by CZ.NIC's secure firmware and also Marvell's fuse.bin firmware and fix parsing response from Marvell OTP commands. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2022-04-21arm: mvebu: a37xx: Move generic mbox code to arch/arm/mach-mvebuPali Rohár
Generic A3720 mbox code is currently in Turris Mox specific board file board/CZ.NIC/turris_mox/mox_sp.c. Move it to board independent arch file arch/arm/mach-mvebu/armada3700/mbox.c. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2022-04-21arm: mvebu: a37xx: Add support for reading NB and SB fuse OTP valuePali Rohár
Implement reading NB and SB fuses of Armada 37xx SOC via U-Boot fuse API. Banks 0-43 are reserved for accessing Security OTP (not implemented yet). Bank 44 is used for accessing North Bridge OTP (69 bits via words 0-2). Bank 45 is used for accessing South Bridge OTP (97 bits via words 0-3). Write support is not implemented yet because it looks like that both North and South Bridge OTPs are already burned in factory with some data. The meaning of some bits of North Bridge is documented in WTMI source code. The meaning of bits in South Bridge is unknown. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2022-04-08controlcenterdc: Migrate CUSTOMER_BOARD_SUPPORT to KconfigTom Rini
This symbol is only possibly useful on some mvebu platforms, so move the symbol there and select it for the only current user. Cc: Mario Six <mario.six@gdsys.cc> Cc: Stefan Roese <sr@denx.de> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Stefan Roese <sr@denx.de>
2022-04-08mvebu: Move BOOTROM_ERR_REG out of CONFIG namespaceTom Rini
This register is referenced in one location and does not seem configurable, so remove it from CONFIG namespace. Cc: Stefan Roese <sr@denx.de> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Stefan Roese <sr@denx.de>
2022-04-05Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxiTom Rini
A big part is the DM pinctrl driver, which allows us to get rid of quite some custom pinmux code and make the whole port much more robust. Many thanks to Samuel for that nice contribution! There are some more or less cosmetic warnings about missing clocks right now, I will send the trivial fixes for that later. Another big chunk is the mkimage upgrade, which adds RISC-V and TOC0 (secure images) support. Both features are unused at the moment, but I have an always-secure board that will use that once the DT lands in the kernel. On top of those big things we have some smaller fixes, improving the I2C DM support, fixing some H6/H616 early clock setup and improving the eMMC boot partition support. The gitlab CI completed successfully, including the build test for all 161 sunxi boards. I also boot tested on a A64, A20, H3, H6, and F1C100 board. USB, SD card, eMMC, and Ethernet all work there (where applicable).
generated by cgit v1.2.3 (git 2.0.4) at 2024-06-28 21:50:52 +0000