Commit graph

359 commits

Author SHA1 Message Date
Tony Dinh
b21f87a5a5 arm: mvebu: Add support for Synology DS116 (Armada 385)
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-13 10:14:50 +01:00
Tony Dinh
3fdd09f90f arm: mvebu: Add support for Thecus N2350 (Armada 385) board
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-13 10:14:50 +01:00
Simon Glass
611e9af07c Correct SPL uses of ARMADA_8K
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-09 16:32:25 -05:00
Simon Glass
c1c5538e7e Correct SPL uses of ARMADA_3700
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-09 16:32:25 -05:00
Simon Glass
51864cdcbc Correct SPL uses of ALLEYCAT_5
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-09 16:32:25 -05:00
Simon Glass
faed058f00 arm: mvebu: Drop reference to CONFIG_ARMADA_39X
This is not defined anywhere. Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>
2023-02-07 14:33:47 -05:00
Simon Glass
86dfdae2fa arm: mvebu: Remove reference to ARMADA_370
Drop this as it is not referenced anywhere else in the code.

Signed-off-by: Simon Glass <sjg@chromium.org>
2023-02-07 14:33:47 -05:00
Tom Rini
f5dd0c5e19 configs: Remove unused or redundant CONFIG symbols
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-23 10:15:13 -05:00
Tom Rini
9dbe356ef4 global: Migrate CONFIG_SAR_REG to CFG
Perform a simple rename of CONFIG_SAR_REG to CFG_SAR_REG

Signed-off-by: Tom Rini <trini@konsulko.com>
2022-12-23 10:15:11 -05:00
Tom Rini
f9932d38a3 global: Migrate CONFIG_SAR2_REG to CFG
Perform a simple rename of CONFIG_SAR2_REG to CFG_SAR2_REG

Signed-off-by: Tom Rini <trini@konsulko.com>
2022-12-23 10:15:11 -05:00
Tom Rini
308520b8f2 global: Remove unused CONFIG symbols
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-22 10:31:48 -05:00
Tom Rini
65cc0e2a65 global: Move remaining CONFIG_SYS_* to CFG_SYS_*
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-05 16:06:08 -05:00
Tom Rini
aa6e94deab global: Move remaining CONFIG_SYS_SDRAM_* to CFG_SYS_SDRAM_*
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-12-05 16:06:07 -05:00
Chris Packham
6cc8b5db40 arm: mvebu: Add RD-AC5X board
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-07 07:46:28 +01:00
Chris Packham
7d7bb99e22 arm: mvebu: Support for 98DX25xx/98DX35xx SoC
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-11-07 07:46:28 +01:00
Pali Rohár
8092d1dd41 arm: mvebu: Add support for specifying VHV_Enable GPIO
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-06 10:15:35 +02:00
Pali Rohár
3b44b3fdf2 arm: mvebu: Add support for programming LD0 and LD1 eFuse
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-06 10:15:35 +02:00
Stefan Roese
2de00f342f arm: mvebu: Remove timer.c
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-10-06 10:15:35 +02:00
Pali Rohár
049704f808 board_f: Fix types for board_get_usable_ram_top()
Commit 37dc958947 ("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: 37dc958947 ("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-23 15:12:42 -04:00
Stefan Roese
7b530bb19e arm: mvebu: Use CONFIG_TIMER on all MVEBU & KIRKWOOD platforms
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-20 06:39:43 +02:00
Tom Rini
e9a1ff9724 Merge branch 'master' into next
Signed-off-by: Tom Rini <trini@konsulko.com>
2022-09-19 16:07:12 -04:00
Pali Rohár
5818198e6a arm: mvebu: Fix moving internal registers
Commit 5bb2c550b1 ("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 cefd764222 ("arm: mvebu: Fix internal
register config on A38x") probably unintentionally removed important
details about MMU from code comments around.

Commit 5bb2c550b1 ("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: 5bb2c550b1 ("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-13 09:04:22 +02:00
Pali Rohár
4f2333ba88 arm: mvebu: Enable L2 cache also on Armada 38x
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 3308933d2f ("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 3e5ce7ceeb ("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: 3308933d2f ("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-13 09:04:22 +02:00
Pali Rohár
a7199f4493 arm: mvebu: lowlevel.S: Use CR_M from asm/system.h
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-13 09:04:22 +02:00
Pali Rohár
2a0d9ae414 arm: mvebu: Guard non-AXP code by checking for AXP
Commit c86d53fd88 ("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: c86d53fd88 ("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-13 09:04:22 +02:00
Pali Rohár
117ef65502 arm: mvebu: Fix function enable_caches
Commit 3308933d2f ("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: 3308933d2f ("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-13 09:04:22 +02:00
Pali Rohár
b120519d76 arm: mvebu: Mark constant data with const keyword
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
2022-09-13 06:38:08 +02:00
Philip Oberfichtner
111688839a Convert CONFIG_SYS_L2_PL310 to Kconfig
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-09-01 17:18:42 -04:00
Michael Walle
78c9b85df8 arm: kirkwood: make it CONFIG_TIMER aware
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-23 12:38:54 +02:00
Pali Rohár
5692e5b244 arm: mvebu: mbus: Fix mbus driver to work also after U-Boot relocation
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-23 12:35:37 +02:00
Pali Rohár
397626ced6 arm: mvebu: Define env_sf_get_env_addr() for all Armada boards in SPL
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-23 10:48:59 +02:00
Pali Rohár
dfebc1b908 arm: mvebu: spl: Always fallback to BootROM boot method
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-08-09 08:57:23 +02:00
Pali Rohár
3308933d2f arm: mvebu: Avoid reading MVEBU_REG_PCIE_DEVID register too many times
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-21 10:14:04 +02:00
Marek Behún
61143f741e treewide: Fix Marek's name and change my e-mail address
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-21 10:14:04 +02:00
Chris Packham
8fd3cf2940 arm64: mvebu: handle non-zero base address for RAM
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-07-21 07:46:10 +02:00
Chris Packham
bfbd62f691 arm: mvebu: Use MVEBU_SPL_BOOT_DEVICE instead of SPL_BOOT_DEVICE
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-06 12:09:29 -04:00
Tom Rini
eaf6ea6a1d Migrate CUSTOM_SYS_INIT_SP_ADDR to Kconfig using system-constants.h
- 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-06 12:09:19 -04:00
Tom Rini
3b2979eefa mvebu: Use CONFIG_SPL_STACK + 4 directly for bootparam location
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-06-06 12:09:12 -04:00
Pali Rohár
5bb2c550b1 arm: mvebu: Move internal registers in arch_very_early_init() function
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-16 11:31:34 +02:00
Chris Packham
1001a0ab46 arm: mvebu: Remove unused ARMADA_64BIT
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-05-16 11:31:33 +02:00
Pali Rohár
1d71bbca45 arm: mvebu: a37xx: Add support for writing Security OTP values
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-21 12:31:36 +02:00
Pali Rohár
2975bba6df arm: mvebu: Enable CONFIG_SPL_SYS_NO_VECTOR_TABLE for 32-bit mvebu
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-21 12:31:36 +02:00
Pali Rohár
8b3d7ecdfe arm: mvebu: Add support for reading LD0 and LD1 eFuse
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-21 12:31:36 +02:00
Pali Rohár
c8b00da695 arm: mvebu: a37xx: Add support for reading Security OTP values
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-21 12:31:36 +02:00
Pali Rohár
85df8f9a21 arm: mvebu: a37xx: Extend mbox_do_cmd() code
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-21 12:31:36 +02:00
Pali Rohár
46ce9c78a9 arm: mvebu: a37xx: Move generic mbox code to arch/arm/mach-mvebu
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-21 12:31:36 +02:00
Pali Rohár
10154b81de arm: mvebu: a37xx: Add support for reading NB and SB fuse OTP value
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-21 12:31:36 +02:00
Tom Rini
53dbf1160d controlcenterdc: Migrate CUSTOMER_BOARD_SUPPORT to Kconfig
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-08 10:46:22 -04:00
Tom Rini
4e4fff7d93 mvebu: Move BOOTROM_ERR_REG out of CONFIG namespace
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-08 09:05:19 -04:00
Tom Rini
4de720e98d Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxi
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).
2022-04-05 08:33:32 -04:00