2015-08-25 11:18:38 +00:00
|
|
|
if ARCH_MVEBU
|
|
|
|
|
|
2017-01-11 15:01:00 +00:00
|
|
|
config HAVE_MVEBU_EFUSE
|
|
|
|
|
bool
|
|
|
|
|
default n
|
|
|
|
|
|
2016-05-17 13:00:30 +00:00
|
|
|
config ARMADA_32BIT
|
|
|
|
|
bool
|
2018-07-23 13:55:15 +00:00
|
|
|
select ARCH_MISC_INIT
|
|
|
|
|
select BOARD_EARLY_INIT_F
|
2018-04-26 12:51:26 +00:00
|
|
|
select CPU_V7A
|
2019-04-11 06:58:32 +00:00
|
|
|
select SPL_DM if SPL
|
|
|
|
|
select SPL_DM_SEQ_ALIAS if SPL
|
|
|
|
|
select SPL_OF_CONTROL if SPL
|
|
|
|
|
select SPL_SIMPLE_BUS if SPL
|
2018-07-23 13:55:15 +00:00
|
|
|
select SUPPORT_SPL
|
2019-04-12 14:42:28 +00:00
|
|
|
select TRANSLATION_OFFSET
|
2016-05-17 13:00:30 +00:00
|
|
|
|
|
|
|
|
config ARMADA_64BIT
|
|
|
|
|
bool
|
|
|
|
|
select ARM64
|
|
|
|
|
|
|
|
|
|
# ARMv7 SoCs...
|
2016-01-29 08:14:54 +00:00
|
|
|
config ARMADA_375
|
|
|
|
|
bool
|
2016-05-17 13:00:30 +00:00
|
|
|
select ARMADA_32BIT
|
2016-01-29 08:14:54 +00:00
|
|
|
|
2015-12-21 12:56:33 +00:00
|
|
|
config ARMADA_38X
|
|
|
|
|
bool
|
2016-05-17 13:00:30 +00:00
|
|
|
select ARMADA_32BIT
|
2017-01-11 15:01:00 +00:00
|
|
|
select HAVE_MVEBU_EFUSE
|
2015-12-21 12:56:33 +00:00
|
|
|
|
2020-11-08 21:14:08 +00:00
|
|
|
config ARMADA_38X_HS_IMPEDANCE_THRESH
|
|
|
|
|
hex "Armada 38x USB 2.0 High-Speed Impedance Threshold (0x0 - 0x7)"
|
|
|
|
|
depends on ARMADA_38X
|
|
|
|
|
default 0x6
|
|
|
|
|
range 0x0 0x7
|
|
|
|
|
|
2015-12-21 12:56:33 +00:00
|
|
|
config ARMADA_XP
|
|
|
|
|
bool
|
2016-05-17 13:00:30 +00:00
|
|
|
select ARMADA_32BIT
|
|
|
|
|
|
|
|
|
|
# ARMv8 SoCs...
|
|
|
|
|
config ARMADA_3700
|
|
|
|
|
bool
|
|
|
|
|
select ARM64
|
2015-12-21 12:56:33 +00:00
|
|
|
|
arm64: mvebu: Add basic support for the Marvell Armada 7K/8K SoC
Compared to the Armada 3700, the Armada 7K and 8K are much more on the
high-end side: they use a dual Cortex-A72 or a quad Cortex-A72, as
opposed to the Cortex-A53 for the Armada 3700.
The Armada 7K and 8K also use a fairly unique architecture, internally
they are composed of several components:
- One AP (Application Processor), which contains the processor itself
and a few core hardware blocks. The AP used in the Armada 7K and 8K
is called AP806, and is available in two configurations:
dual Cortex-A72 and quad Cortex-A72.
- One or two CP (Communication Processor), which contain most of the I/O
interfaces (SATA, PCIe, Ethernet, etc.). The 7K family chips have one
CP, while the 8K family chips integrate two CPs, providing two times
the number of I/O interfaces available in the CP.
The CP used in the 7K and 8K is called CP110.
All in all, this gives the following combinations:
- Armada 7020, which is a dual Cortex-A72 with one CP
- Armada 7040, which is a quad Cortex-A72 with one CP
- Armada 8020, which is a dual Cortex-A72 with two CPs
- Armada 8040, which is a quad Cortex-A72 with two CPs
This patch adds basic support for this ARMv8 based SoC into U-Boot.
Future patches will integrate other device drivers and board support,
starting with the Marvell DB-88F7040 development board.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Nadav Haklai <nadavh@marvell.com>
Cc: Neta Zur Hershkovits <neta@marvell.com>
Cc: Kostya Porotchkin <kostap@marvell.com>
Cc: Omri Itach <omrii@marvell.com>
Cc: Igal Liberman <igall@marvell.com>
Cc: Haim Boot <hayim@marvell.com>
Cc: Hanna Hawa <hannah@marvell.com>
2016-05-25 06:13:45 +00:00
|
|
|
# Armada 7K and 8K are very similar - use only one Kconfig symbol for both
|
|
|
|
|
config ARMADA_8K
|
|
|
|
|
bool
|
|
|
|
|
select ARM64
|
|
|
|
|
|
2016-10-26 01:08:30 +00:00
|
|
|
# Armada PLL frequency (used for NAND clock generation)
|
|
|
|
|
config SYS_MVEBU_PLL_CLOCK
|
|
|
|
|
int
|
2019-04-11 10:22:50 +00:00
|
|
|
default "2000000000" if ARMADA_XP || ARMADA_3700 || ARMADA_8K || ARMADA_MSYS
|
2016-10-26 01:08:30 +00:00
|
|
|
default "1000000000" if ARMADA_38X || ARMADA_375
|
|
|
|
|
|
2016-05-17 13:00:30 +00:00
|
|
|
# Armada XP/38x SoC types...
|
2015-12-25 13:41:22 +00:00
|
|
|
config MV78230
|
|
|
|
|
bool
|
|
|
|
|
select ARMADA_XP
|
|
|
|
|
|
|
|
|
|
config MV78260
|
|
|
|
|
bool
|
|
|
|
|
select ARMADA_XP
|
2017-06-15 03:28:24 +00:00
|
|
|
imply CMD_SATA
|
2015-12-25 13:41:22 +00:00
|
|
|
|
|
|
|
|
config MV78460
|
|
|
|
|
bool
|
|
|
|
|
select ARMADA_XP
|
|
|
|
|
|
2019-04-11 10:22:50 +00:00
|
|
|
config ARMADA_MSYS
|
|
|
|
|
bool
|
|
|
|
|
select ARMADA_32BIT
|
|
|
|
|
|
|
|
|
|
config 98DX4251
|
|
|
|
|
bool
|
|
|
|
|
select ARMADA_MSYS
|
|
|
|
|
|
|
|
|
|
config 98DX3336
|
|
|
|
|
bool
|
|
|
|
|
select ARMADA_MSYS
|
|
|
|
|
|
|
|
|
|
config 98DX3236
|
|
|
|
|
bool
|
|
|
|
|
select ARMADA_MSYS
|
|
|
|
|
|
2016-09-22 00:56:13 +00:00
|
|
|
config 88F6820
|
2015-12-25 13:41:22 +00:00
|
|
|
bool
|
|
|
|
|
select ARMADA_38X
|
|
|
|
|
|
2015-08-25 11:18:38 +00:00
|
|
|
choice
|
arm64: mvebu: Add basic support for the Marvell Armada 7K/8K SoC
Compared to the Armada 3700, the Armada 7K and 8K are much more on the
high-end side: they use a dual Cortex-A72 or a quad Cortex-A72, as
opposed to the Cortex-A53 for the Armada 3700.
The Armada 7K and 8K also use a fairly unique architecture, internally
they are composed of several components:
- One AP (Application Processor), which contains the processor itself
and a few core hardware blocks. The AP used in the Armada 7K and 8K
is called AP806, and is available in two configurations:
dual Cortex-A72 and quad Cortex-A72.
- One or two CP (Communication Processor), which contain most of the I/O
interfaces (SATA, PCIe, Ethernet, etc.). The 7K family chips have one
CP, while the 8K family chips integrate two CPs, providing two times
the number of I/O interfaces available in the CP.
The CP used in the 7K and 8K is called CP110.
All in all, this gives the following combinations:
- Armada 7020, which is a dual Cortex-A72 with one CP
- Armada 7040, which is a quad Cortex-A72 with one CP
- Armada 8020, which is a dual Cortex-A72 with two CPs
- Armada 8040, which is a quad Cortex-A72 with two CPs
This patch adds basic support for this ARMv8 based SoC into U-Boot.
Future patches will integrate other device drivers and board support,
starting with the Marvell DB-88F7040 development board.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Nadav Haklai <nadavh@marvell.com>
Cc: Neta Zur Hershkovits <neta@marvell.com>
Cc: Kostya Porotchkin <kostap@marvell.com>
Cc: Omri Itach <omrii@marvell.com>
Cc: Igal Liberman <igall@marvell.com>
Cc: Haim Boot <hayim@marvell.com>
Cc: Hanna Hawa <hannah@marvell.com>
2016-05-25 06:13:45 +00:00
|
|
|
prompt "Armada XP/375/38x/3700/7K/8K board select"
|
2015-08-25 11:18:38 +00:00
|
|
|
optional
|
|
|
|
|
|
2015-10-20 13:14:47 +00:00
|
|
|
config TARGET_CLEARFOG
|
|
|
|
|
bool "Support ClearFog"
|
2016-09-22 00:56:13 +00:00
|
|
|
select 88F6820
|
2020-01-20 12:20:13 +00:00
|
|
|
select BOARD_LATE_INIT
|
2015-10-20 13:14:47 +00:00
|
|
|
|
2018-06-12 00:39:53 +00:00
|
|
|
config TARGET_HELIOS4
|
|
|
|
|
bool "Support Helios4"
|
|
|
|
|
select 88F6820
|
|
|
|
|
|
2017-02-16 11:52:22 +00:00
|
|
|
config TARGET_MVEBU_ARMADA_37XX
|
|
|
|
|
bool "Support Armada 37xx platforms"
|
2016-05-17 13:04:16 +00:00
|
|
|
select ARMADA_3700
|
2017-06-15 03:28:21 +00:00
|
|
|
imply SCSI
|
2016-05-17 13:04:16 +00:00
|
|
|
|
2016-01-29 08:14:54 +00:00
|
|
|
config TARGET_DB_88F6720
|
|
|
|
|
bool "Support DB-88F6720 Armada 375"
|
|
|
|
|
select ARMADA_375
|
|
|
|
|
|
2015-08-25 11:18:38 +00:00
|
|
|
config TARGET_DB_88F6820_GP
|
|
|
|
|
bool "Support DB-88F6820-GP"
|
2016-09-22 00:56:13 +00:00
|
|
|
select 88F6820
|
2015-08-25 11:18:38 +00:00
|
|
|
|
2016-09-22 00:56:14 +00:00
|
|
|
config TARGET_DB_88F6820_AMC
|
|
|
|
|
bool "Support DB-88F6820-AMC"
|
|
|
|
|
select 88F6820
|
|
|
|
|
|
2017-06-09 17:28:45 +00:00
|
|
|
config TARGET_TURRIS_OMNIA
|
|
|
|
|
bool "Support Turris Omnia"
|
|
|
|
|
select 88F6820
|
2019-05-02 14:53:37 +00:00
|
|
|
select BOARD_LATE_INIT
|
2019-05-02 14:53:28 +00:00
|
|
|
select DM_I2C
|
|
|
|
|
select I2C_MUX
|
|
|
|
|
select I2C_MUX_PCA954x
|
|
|
|
|
select SPL_I2C_MUX
|
|
|
|
|
select SYS_I2C_MVTWSI
|
2019-05-02 14:53:32 +00:00
|
|
|
select ATSHA204A
|
2017-06-09 17:28:45 +00:00
|
|
|
|
2018-04-24 15:21:31 +00:00
|
|
|
config TARGET_TURRIS_MOX
|
|
|
|
|
bool "Support Turris Mox"
|
|
|
|
|
select ARMADA_3700
|
|
|
|
|
|
2016-10-25 08:56:19 +00:00
|
|
|
config TARGET_MVEBU_ARMADA_8K
|
|
|
|
|
bool "Support Armada 7k/8k platforms"
|
2016-05-25 06:21:21 +00:00
|
|
|
select ARMADA_8K
|
2017-01-23 00:43:11 +00:00
|
|
|
select BOARD_LATE_INIT
|
2017-06-15 03:28:21 +00:00
|
|
|
imply SCSI
|
2016-05-25 06:21:21 +00:00
|
|
|
|
2021-03-16 16:20:57 +00:00
|
|
|
config TARGET_OCTEONTX2_CN913x
|
|
|
|
|
bool "Support CN913x platforms"
|
|
|
|
|
select ARMADA_8K
|
|
|
|
|
imply BOARD_EARLY_INIT_R
|
|
|
|
|
select BOARD_LATE_INIT
|
|
|
|
|
imply SCSI
|
|
|
|
|
|
2015-08-25 11:18:38 +00:00
|
|
|
config TARGET_DB_MV784MP_GP
|
|
|
|
|
bool "Support db-mv784mp-gp"
|
2015-12-25 13:41:22 +00:00
|
|
|
select MV78460
|
2015-08-25 11:18:38 +00:00
|
|
|
|
mvebu: Support Synology DS414
This adds support for the MV78230 based DS414 NAS by Synology. The
relevant bits have been extracted from the 'synogpl-5004-armadaxp'
package Synology kindly published, garnished with a fair amount of
trial-and-error.
Sadly, support is far from perfect. The major parts I have failed in
are SATA and XHCI support. Details about these and some other things
follow:
Device Tree
-----------
The device tree file armada-xp-synology-ds414.dts has been copied from
Linux and enhanced by recent U-Boot specific changes to
armada-xp-gp.dts.
SATA Support
------------
There is a Marvell 88SX7042 controller attached to PCIe which is
supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv.
I'm not sure if extending the latter to support PCI devices is worth the
effort at all. Porting sata_mv from Linux exceeded my brain's
capacities. :(
XHCI Support
------------
There is an EtronTech EJ168A XHCI controller attached to PCIe which
drives the two rear USB3 ports. After a bit of playing around I managed
to get it recognized by xhci-pci, but never was able to access any
devices attached to it. Enabling it in ds414 board config shows that it
does not respond to commands for whatever reason. The (somewhat) bright
side to it is that it is not even supported in Synology's customized
U-Boot, but that also means nowhere to steal the relevant bits from.
EHCI Support
------------
This seems functional after issuing 'usb start'. At least it detects USB
storage devices, and IIRC reading from them was OK. OTOH Linux fails to
register the controller if 'usb start' wasn't given before in U-Boot.
According to Synology sources, this board seems to support USB device
(gadget?) mode. Though I didn't play around with it.
PCIe Support
------------
This is fine, but trying to gate the clocks of unused lanes will hang
PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI.
DDR3 Training
-------------
Marvell/Synology uses eight PUPs instead of four. Does not look like
this is meant to be customized in mainline U-Boot at all. OTOH I have
no idea what a "PUP" actually is.
PEX Init
--------
Synology uses different values than mainline U-Boot with this patch:
pex_max_unit_get returns 2, pex_max_if_get returns 7 and
max_serdes_lines is set to 7. Not changing this seems to not have an
impact, although I'm not entirely sure it does not cause issues I am not
aware of.
Static Environment
------------------
This allows to boot stock Synology firmware at least. In order to be a
little more flexible when it comes to booting custom kernels, do not
only load zImage partition, but also rd.gz into memory. This way it is
possible to use about 7MB for kernel with piggyback initramfs.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
2015-12-25 13:41:25 +00:00
|
|
|
config TARGET_DS414
|
|
|
|
|
bool "Support Synology DS414"
|
|
|
|
|
select MV78230
|
|
|
|
|
|
2015-08-25 11:18:38 +00:00
|
|
|
config TARGET_MAXBCM
|
|
|
|
|
bool "Support maxbcm"
|
2015-12-25 13:41:22 +00:00
|
|
|
select MV78460
|
2015-08-25 11:18:38 +00:00
|
|
|
|
2016-01-20 07:13:29 +00:00
|
|
|
config TARGET_THEADORABLE
|
|
|
|
|
bool "Support theadorable Armada XP"
|
2017-01-23 00:43:11 +00:00
|
|
|
select BOARD_LATE_INIT if USB
|
2016-01-20 07:13:29 +00:00
|
|
|
select MV78260
|
2017-06-15 03:28:24 +00:00
|
|
|
imply CMD_SATA
|
2016-01-20 07:13:29 +00:00
|
|
|
|
2017-02-22 15:07:23 +00:00
|
|
|
config TARGET_CONTROLCENTERDC
|
|
|
|
|
bool "Support CONTROLCENTERDC"
|
|
|
|
|
select 88F6820
|
|
|
|
|
|
2019-01-10 08:01:00 +00:00
|
|
|
config TARGET_X530
|
|
|
|
|
bool "Support Allied Telesis x530"
|
|
|
|
|
select 88F6820
|
|
|
|
|
|
2019-04-11 10:22:53 +00:00
|
|
|
config TARGET_DB_XC3_24G4XG
|
|
|
|
|
bool "Support DB-XC3-24G4XG"
|
|
|
|
|
select 98DX3336
|
|
|
|
|
|
2020-05-26 18:17:50 +00:00
|
|
|
config TARGET_CRS3XX_98DX3236
|
|
|
|
|
bool "Support CRS3XX-98DX3236"
|
2019-05-07 17:35:55 +00:00
|
|
|
select 98DX3236
|
|
|
|
|
|
2015-08-25 11:18:38 +00:00
|
|
|
endchoice
|
|
|
|
|
|
2015-12-21 12:40:37 +00:00
|
|
|
config SYS_BOARD
|
|
|
|
|
default "clearfog" if TARGET_CLEARFOG
|
2018-06-12 00:39:53 +00:00
|
|
|
default "helios4" if TARGET_HELIOS4
|
2017-02-16 11:52:22 +00:00
|
|
|
default "mvebu_armada-37xx" if TARGET_MVEBU_ARMADA_37XX
|
2016-01-29 08:14:54 +00:00
|
|
|
default "db-88f6720" if TARGET_DB_88F6720
|
2015-12-21 12:40:37 +00:00
|
|
|
default "db-88f6820-gp" if TARGET_DB_88F6820_GP
|
2016-09-22 00:56:14 +00:00
|
|
|
default "db-88f6820-amc" if TARGET_DB_88F6820_AMC
|
2017-06-09 17:28:45 +00:00
|
|
|
default "turris_omnia" if TARGET_TURRIS_OMNIA
|
2018-04-24 15:21:31 +00:00
|
|
|
default "turris_mox" if TARGET_TURRIS_MOX
|
2016-10-25 08:56:19 +00:00
|
|
|
default "mvebu_armada-8k" if TARGET_MVEBU_ARMADA_8K
|
2021-03-16 16:20:57 +00:00
|
|
|
default "octeontx2_cn913x" if TARGET_OCTEONTX2_CN913x
|
2015-12-21 12:40:37 +00:00
|
|
|
default "db-mv784mp-gp" if TARGET_DB_MV784MP_GP
|
mvebu: Support Synology DS414
This adds support for the MV78230 based DS414 NAS by Synology. The
relevant bits have been extracted from the 'synogpl-5004-armadaxp'
package Synology kindly published, garnished with a fair amount of
trial-and-error.
Sadly, support is far from perfect. The major parts I have failed in
are SATA and XHCI support. Details about these and some other things
follow:
Device Tree
-----------
The device tree file armada-xp-synology-ds414.dts has been copied from
Linux and enhanced by recent U-Boot specific changes to
armada-xp-gp.dts.
SATA Support
------------
There is a Marvell 88SX7042 controller attached to PCIe which is
supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv.
I'm not sure if extending the latter to support PCI devices is worth the
effort at all. Porting sata_mv from Linux exceeded my brain's
capacities. :(
XHCI Support
------------
There is an EtronTech EJ168A XHCI controller attached to PCIe which
drives the two rear USB3 ports. After a bit of playing around I managed
to get it recognized by xhci-pci, but never was able to access any
devices attached to it. Enabling it in ds414 board config shows that it
does not respond to commands for whatever reason. The (somewhat) bright
side to it is that it is not even supported in Synology's customized
U-Boot, but that also means nowhere to steal the relevant bits from.
EHCI Support
------------
This seems functional after issuing 'usb start'. At least it detects USB
storage devices, and IIRC reading from them was OK. OTOH Linux fails to
register the controller if 'usb start' wasn't given before in U-Boot.
According to Synology sources, this board seems to support USB device
(gadget?) mode. Though I didn't play around with it.
PCIe Support
------------
This is fine, but trying to gate the clocks of unused lanes will hang
PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI.
DDR3 Training
-------------
Marvell/Synology uses eight PUPs instead of four. Does not look like
this is meant to be customized in mainline U-Boot at all. OTOH I have
no idea what a "PUP" actually is.
PEX Init
--------
Synology uses different values than mainline U-Boot with this patch:
pex_max_unit_get returns 2, pex_max_if_get returns 7 and
max_serdes_lines is set to 7. Not changing this seems to not have an
impact, although I'm not entirely sure it does not cause issues I am not
aware of.
Static Environment
------------------
This allows to boot stock Synology firmware at least. In order to be a
little more flexible when it comes to booting custom kernels, do not
only load zImage partition, but also rd.gz into memory. This way it is
possible to use about 7MB for kernel with piggyback initramfs.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
2015-12-25 13:41:25 +00:00
|
|
|
default "ds414" if TARGET_DS414
|
2015-12-21 12:40:37 +00:00
|
|
|
default "maxbcm" if TARGET_MAXBCM
|
2016-01-20 07:13:29 +00:00
|
|
|
default "theadorable" if TARGET_THEADORABLE
|
2018-06-18 18:56:23 +00:00
|
|
|
default "a38x" if TARGET_CONTROLCENTERDC
|
2019-01-10 08:01:00 +00:00
|
|
|
default "x530" if TARGET_X530
|
2019-04-11 10:22:53 +00:00
|
|
|
default "db-xc3-24g4xg" if TARGET_DB_XC3_24G4XG
|
2020-05-26 18:17:50 +00:00
|
|
|
default "crs3xx-98dx3236" if TARGET_CRS3XX_98DX3236
|
2015-12-21 12:40:37 +00:00
|
|
|
|
|
|
|
|
config SYS_CONFIG_NAME
|
|
|
|
|
default "clearfog" if TARGET_CLEARFOG
|
2018-06-12 00:39:53 +00:00
|
|
|
default "helios4" if TARGET_HELIOS4
|
2017-02-16 11:52:22 +00:00
|
|
|
default "mvebu_armada-37xx" if TARGET_MVEBU_ARMADA_37XX
|
2016-01-29 08:14:54 +00:00
|
|
|
default "db-88f6720" if TARGET_DB_88F6720
|
2015-12-21 12:40:37 +00:00
|
|
|
default "db-88f6820-gp" if TARGET_DB_88F6820_GP
|
2016-09-22 00:56:14 +00:00
|
|
|
default "db-88f6820-amc" if TARGET_DB_88F6820_AMC
|
2016-10-25 08:56:19 +00:00
|
|
|
default "mvebu_armada-8k" if TARGET_MVEBU_ARMADA_8K
|
2021-03-16 16:20:57 +00:00
|
|
|
default "mvebu_armada-8k" if TARGET_OCTEONTX2_CN913x
|
2015-12-21 12:40:37 +00:00
|
|
|
default "db-mv784mp-gp" if TARGET_DB_MV784MP_GP
|
mvebu: Support Synology DS414
This adds support for the MV78230 based DS414 NAS by Synology. The
relevant bits have been extracted from the 'synogpl-5004-armadaxp'
package Synology kindly published, garnished with a fair amount of
trial-and-error.
Sadly, support is far from perfect. The major parts I have failed in
are SATA and XHCI support. Details about these and some other things
follow:
Device Tree
-----------
The device tree file armada-xp-synology-ds414.dts has been copied from
Linux and enhanced by recent U-Boot specific changes to
armada-xp-gp.dts.
SATA Support
------------
There is a Marvell 88SX7042 controller attached to PCIe which is
supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv.
I'm not sure if extending the latter to support PCI devices is worth the
effort at all. Porting sata_mv from Linux exceeded my brain's
capacities. :(
XHCI Support
------------
There is an EtronTech EJ168A XHCI controller attached to PCIe which
drives the two rear USB3 ports. After a bit of playing around I managed
to get it recognized by xhci-pci, but never was able to access any
devices attached to it. Enabling it in ds414 board config shows that it
does not respond to commands for whatever reason. The (somewhat) bright
side to it is that it is not even supported in Synology's customized
U-Boot, but that also means nowhere to steal the relevant bits from.
EHCI Support
------------
This seems functional after issuing 'usb start'. At least it detects USB
storage devices, and IIRC reading from them was OK. OTOH Linux fails to
register the controller if 'usb start' wasn't given before in U-Boot.
According to Synology sources, this board seems to support USB device
(gadget?) mode. Though I didn't play around with it.
PCIe Support
------------
This is fine, but trying to gate the clocks of unused lanes will hang
PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI.
DDR3 Training
-------------
Marvell/Synology uses eight PUPs instead of four. Does not look like
this is meant to be customized in mainline U-Boot at all. OTOH I have
no idea what a "PUP" actually is.
PEX Init
--------
Synology uses different values than mainline U-Boot with this patch:
pex_max_unit_get returns 2, pex_max_if_get returns 7 and
max_serdes_lines is set to 7. Not changing this seems to not have an
impact, although I'm not entirely sure it does not cause issues I am not
aware of.
Static Environment
------------------
This allows to boot stock Synology firmware at least. In order to be a
little more flexible when it comes to booting custom kernels, do not
only load zImage partition, but also rd.gz into memory. This way it is
possible to use about 7MB for kernel with piggyback initramfs.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
2015-12-25 13:41:25 +00:00
|
|
|
default "ds414" if TARGET_DS414
|
2015-12-21 12:40:37 +00:00
|
|
|
default "maxbcm" if TARGET_MAXBCM
|
2016-01-20 07:13:29 +00:00
|
|
|
default "theadorable" if TARGET_THEADORABLE
|
2017-06-09 17:28:45 +00:00
|
|
|
default "turris_omnia" if TARGET_TURRIS_OMNIA
|
2018-04-24 15:21:31 +00:00
|
|
|
default "turris_mox" if TARGET_TURRIS_MOX
|
2018-06-18 18:56:23 +00:00
|
|
|
default "controlcenterdc" if TARGET_CONTROLCENTERDC
|
2019-01-10 08:01:00 +00:00
|
|
|
default "x530" if TARGET_X530
|
2019-04-11 10:22:53 +00:00
|
|
|
default "db-xc3-24g4xg" if TARGET_DB_XC3_24G4XG
|
2020-05-26 18:17:50 +00:00
|
|
|
default "crs3xx-98dx3236" if TARGET_CRS3XX_98DX3236
|
2015-12-21 12:40:37 +00:00
|
|
|
|
|
|
|
|
config SYS_VENDOR
|
|
|
|
|
default "Marvell" if TARGET_DB_MV784MP_GP
|
2017-02-16 11:52:22 +00:00
|
|
|
default "Marvell" if TARGET_MVEBU_ARMADA_37XX
|
2016-01-29 08:14:54 +00:00
|
|
|
default "Marvell" if TARGET_DB_88F6720
|
2015-12-21 12:40:37 +00:00
|
|
|
default "Marvell" if TARGET_DB_88F6820_GP
|
2016-09-22 00:56:14 +00:00
|
|
|
default "Marvell" if TARGET_DB_88F6820_AMC
|
2016-10-25 08:56:19 +00:00
|
|
|
default "Marvell" if TARGET_MVEBU_ARMADA_8K
|
2021-03-16 16:20:57 +00:00
|
|
|
default "Marvell" if TARGET_OCTEONTX2_CN913x
|
2019-04-11 10:22:53 +00:00
|
|
|
default "Marvell" if TARGET_DB_XC3_24G4XG
|
|
|
|
|
default "Marvell" if TARGET_MVEBU_DB_88F7040
|
2015-12-21 12:40:37 +00:00
|
|
|
default "solidrun" if TARGET_CLEARFOG
|
2018-06-12 00:39:53 +00:00
|
|
|
default "kobol" if TARGET_HELIOS4
|
mvebu: Support Synology DS414
This adds support for the MV78230 based DS414 NAS by Synology. The
relevant bits have been extracted from the 'synogpl-5004-armadaxp'
package Synology kindly published, garnished with a fair amount of
trial-and-error.
Sadly, support is far from perfect. The major parts I have failed in
are SATA and XHCI support. Details about these and some other things
follow:
Device Tree
-----------
The device tree file armada-xp-synology-ds414.dts has been copied from
Linux and enhanced by recent U-Boot specific changes to
armada-xp-gp.dts.
SATA Support
------------
There is a Marvell 88SX7042 controller attached to PCIe which is
supported by Linux's sata_mv driver but sadly not U-Boot's sata_mv.
I'm not sure if extending the latter to support PCI devices is worth the
effort at all. Porting sata_mv from Linux exceeded my brain's
capacities. :(
XHCI Support
------------
There is an EtronTech EJ168A XHCI controller attached to PCIe which
drives the two rear USB3 ports. After a bit of playing around I managed
to get it recognized by xhci-pci, but never was able to access any
devices attached to it. Enabling it in ds414 board config shows that it
does not respond to commands for whatever reason. The (somewhat) bright
side to it is that it is not even supported in Synology's customized
U-Boot, but that also means nowhere to steal the relevant bits from.
EHCI Support
------------
This seems functional after issuing 'usb start'. At least it detects USB
storage devices, and IIRC reading from them was OK. OTOH Linux fails to
register the controller if 'usb start' wasn't given before in U-Boot.
According to Synology sources, this board seems to support USB device
(gadget?) mode. Though I didn't play around with it.
PCIe Support
------------
This is fine, but trying to gate the clocks of unused lanes will hang
PCI enum. In addition to that, pci_mvebu seems not to support DM_PCI.
DDR3 Training
-------------
Marvell/Synology uses eight PUPs instead of four. Does not look like
this is meant to be customized in mainline U-Boot at all. OTOH I have
no idea what a "PUP" actually is.
PEX Init
--------
Synology uses different values than mainline U-Boot with this patch:
pex_max_unit_get returns 2, pex_max_if_get returns 7 and
max_serdes_lines is set to 7. Not changing this seems to not have an
impact, although I'm not entirely sure it does not cause issues I am not
aware of.
Static Environment
------------------
This allows to boot stock Synology firmware at least. In order to be a
little more flexible when it comes to booting custom kernels, do not
only load zImage partition, but also rd.gz into memory. This way it is
possible to use about 7MB for kernel with piggyback initramfs.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
2015-12-25 13:41:25 +00:00
|
|
|
default "Synology" if TARGET_DS414
|
2017-06-09 17:28:45 +00:00
|
|
|
default "CZ.NIC" if TARGET_TURRIS_OMNIA
|
2018-04-24 15:21:31 +00:00
|
|
|
default "CZ.NIC" if TARGET_TURRIS_MOX
|
2018-06-18 18:56:23 +00:00
|
|
|
default "gdsys" if TARGET_CONTROLCENTERDC
|
2019-01-10 08:01:00 +00:00
|
|
|
default "alliedtelesis" if TARGET_X530
|
2020-05-26 18:17:50 +00:00
|
|
|
default "mikrotik" if TARGET_CRS3XX_98DX3236
|
2015-12-21 12:40:37 +00:00
|
|
|
|
2015-08-25 11:18:38 +00:00
|
|
|
config SYS_SOC
|
|
|
|
|
default "mvebu"
|
|
|
|
|
|
2017-06-09 17:28:45 +00:00
|
|
|
choice
|
2018-06-18 18:56:24 +00:00
|
|
|
prompt "Boot method"
|
2020-04-17 07:19:05 +00:00
|
|
|
depends on SPL
|
2017-06-09 17:28:45 +00:00
|
|
|
|
2018-06-18 18:56:24 +00:00
|
|
|
config MVEBU_SPL_BOOT_DEVICE_SPI
|
2017-06-09 17:28:45 +00:00
|
|
|
bool "SPI NOR flash"
|
2020-04-17 07:19:05 +00:00
|
|
|
imply ENV_IS_IN_SPI_FLASH
|
arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header
Now that proper load and execution addresses are set in v1 kwbimage we
can use it for loading and booting U-Boot proper.
Use the new spl_parse_board_header() function to implement parsing the
kwbimage v1 header. Use information from this header to locate offset and
size of the U-Boot proper binary, instead of using the legacy U-Boot
header which is prepended to the U-Boot proper binary stored at fixed
offset. This has the advantage that we do not need to relay on legacy
U-Boot header anymore and therefore U-Boot proper binary can be stored at
any offset, as is the case when loading & booting U-Boot proper by
BootROM. The CONFIG_SYS_U_BOOT_OFFS option is therefore not used by SPL
code anymore.
Also allow to compile U-Boot SPL without CONFIG_SPL_SPI_FLASH_SUPPORT,
CONFIG_SPL_MMC_SUPPORT or CONFIG_SPL_SATA_SUPPORT set. In this case
BootROM is used for loading and executing U-Boot proper. This reduces the
size of U-Boot's SPL image. By default these config options are enabled
and so BootROM loading is not used. In some cases BootROM reads from SPI
NOR at lower speed than U-Boot SPL. So people can decide whether they
want to have smaller SPL binary at the cost of slower boot.
Therefore dependency on CONFIG_SPL_DM_SPI, CONFIG_SPL_SPI_FLASH_SUPPORT,
CONFIG_SPL_SPI_LOAD, CONFIG_SPL_SPI_SUPPORT, CONFIG_SPL_DM_GPIO,
CONFIG_SPL_DM_MMC, CONFIG_SPL_GPIO_SUPPORT, CONFIG_SPL_LIBDISK_SUPPORT,
CONFIG_SPL_MMC_SUPPORT, CONFIG_SPL_SATA_SUPPORT and
CONFIG_SPL_LIBDISK_SUPPORT is changed from strict to related "imply"
(which can be selectivelly turned off and causes booting via BootROM).
Options CONFIG_SYS_SPI_U_BOOT_OFFS,
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR and
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET have to to be set to
zero as they define the location where kwbimage header starts. It is the
location where BootROM expects start of the kwbimage from which it reads,
parses and executes SPL part. The same applies to option
CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR, which has to be set to one.
Update all config files to set correct values of these options and set
CONFIG_SYS_U_BOOT_OFFS to the correct value - the offset where U-Boot
proper starts.
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>
2021-07-23 09:14:29 +00:00
|
|
|
imply SPL_DM_SPI
|
|
|
|
|
imply SPL_SPI_FLASH_SUPPORT
|
|
|
|
|
imply SPL_SPI_LOAD
|
|
|
|
|
imply SPL_SPI_SUPPORT
|
2021-07-23 09:14:25 +00:00
|
|
|
select SPL_BOOTROM_SUPPORT
|
2017-06-09 17:28:45 +00:00
|
|
|
|
2018-06-18 18:56:24 +00:00
|
|
|
config MVEBU_SPL_BOOT_DEVICE_MMC
|
2017-06-09 17:28:45 +00:00
|
|
|
bool "SDIO/MMC card"
|
2020-04-17 07:19:05 +00:00
|
|
|
imply ENV_IS_IN_MMC
|
|
|
|
|
# GPIO needed for eMMC/SD card presence detection
|
arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header
Now that proper load and execution addresses are set in v1 kwbimage we
can use it for loading and booting U-Boot proper.
Use the new spl_parse_board_header() function to implement parsing the
kwbimage v1 header. Use information from this header to locate offset and
size of the U-Boot proper binary, instead of using the legacy U-Boot
header which is prepended to the U-Boot proper binary stored at fixed
offset. This has the advantage that we do not need to relay on legacy
U-Boot header anymore and therefore U-Boot proper binary can be stored at
any offset, as is the case when loading & booting U-Boot proper by
BootROM. The CONFIG_SYS_U_BOOT_OFFS option is therefore not used by SPL
code anymore.
Also allow to compile U-Boot SPL without CONFIG_SPL_SPI_FLASH_SUPPORT,
CONFIG_SPL_MMC_SUPPORT or CONFIG_SPL_SATA_SUPPORT set. In this case
BootROM is used for loading and executing U-Boot proper. This reduces the
size of U-Boot's SPL image. By default these config options are enabled
and so BootROM loading is not used. In some cases BootROM reads from SPI
NOR at lower speed than U-Boot SPL. So people can decide whether they
want to have smaller SPL binary at the cost of slower boot.
Therefore dependency on CONFIG_SPL_DM_SPI, CONFIG_SPL_SPI_FLASH_SUPPORT,
CONFIG_SPL_SPI_LOAD, CONFIG_SPL_SPI_SUPPORT, CONFIG_SPL_DM_GPIO,
CONFIG_SPL_DM_MMC, CONFIG_SPL_GPIO_SUPPORT, CONFIG_SPL_LIBDISK_SUPPORT,
CONFIG_SPL_MMC_SUPPORT, CONFIG_SPL_SATA_SUPPORT and
CONFIG_SPL_LIBDISK_SUPPORT is changed from strict to related "imply"
(which can be selectivelly turned off and causes booting via BootROM).
Options CONFIG_SYS_SPI_U_BOOT_OFFS,
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR and
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET have to to be set to
zero as they define the location where kwbimage header starts. It is the
location where BootROM expects start of the kwbimage from which it reads,
parses and executes SPL part. The same applies to option
CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR, which has to be set to one.
Update all config files to set correct values of these options and set
CONFIG_SYS_U_BOOT_OFFS to the correct value - the offset where U-Boot
proper starts.
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>
2021-07-23 09:14:29 +00:00
|
|
|
imply SPL_DM_GPIO
|
|
|
|
|
imply SPL_DM_MMC
|
|
|
|
|
imply SPL_GPIO
|
|
|
|
|
imply SPL_LIBDISK_SUPPORT
|
|
|
|
|
imply SPL_MMC_SUPPORT
|
2021-07-23 09:14:25 +00:00
|
|
|
select SPL_BOOTROM_SUPPORT
|
2017-06-09 17:28:45 +00:00
|
|
|
|
2019-05-16 10:03:58 +00:00
|
|
|
config MVEBU_SPL_BOOT_DEVICE_SATA
|
|
|
|
|
bool "SATA"
|
arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header
Now that proper load and execution addresses are set in v1 kwbimage we
can use it for loading and booting U-Boot proper.
Use the new spl_parse_board_header() function to implement parsing the
kwbimage v1 header. Use information from this header to locate offset and
size of the U-Boot proper binary, instead of using the legacy U-Boot
header which is prepended to the U-Boot proper binary stored at fixed
offset. This has the advantage that we do not need to relay on legacy
U-Boot header anymore and therefore U-Boot proper binary can be stored at
any offset, as is the case when loading & booting U-Boot proper by
BootROM. The CONFIG_SYS_U_BOOT_OFFS option is therefore not used by SPL
code anymore.
Also allow to compile U-Boot SPL without CONFIG_SPL_SPI_FLASH_SUPPORT,
CONFIG_SPL_MMC_SUPPORT or CONFIG_SPL_SATA_SUPPORT set. In this case
BootROM is used for loading and executing U-Boot proper. This reduces the
size of U-Boot's SPL image. By default these config options are enabled
and so BootROM loading is not used. In some cases BootROM reads from SPI
NOR at lower speed than U-Boot SPL. So people can decide whether they
want to have smaller SPL binary at the cost of slower boot.
Therefore dependency on CONFIG_SPL_DM_SPI, CONFIG_SPL_SPI_FLASH_SUPPORT,
CONFIG_SPL_SPI_LOAD, CONFIG_SPL_SPI_SUPPORT, CONFIG_SPL_DM_GPIO,
CONFIG_SPL_DM_MMC, CONFIG_SPL_GPIO_SUPPORT, CONFIG_SPL_LIBDISK_SUPPORT,
CONFIG_SPL_MMC_SUPPORT, CONFIG_SPL_SATA_SUPPORT and
CONFIG_SPL_LIBDISK_SUPPORT is changed from strict to related "imply"
(which can be selectivelly turned off and causes booting via BootROM).
Options CONFIG_SYS_SPI_U_BOOT_OFFS,
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR and
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET have to to be set to
zero as they define the location where kwbimage header starts. It is the
location where BootROM expects start of the kwbimage from which it reads,
parses and executes SPL part. The same applies to option
CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR, which has to be set to one.
Update all config files to set correct values of these options and set
CONFIG_SYS_U_BOOT_OFFS to the correct value - the offset where U-Boot
proper starts.
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>
2021-07-23 09:14:29 +00:00
|
|
|
imply SPL_SATA_SUPPORT
|
|
|
|
|
imply SPL_LIBDISK_SUPPORT
|
2021-07-23 09:14:25 +00:00
|
|
|
select SPL_BOOTROM_SUPPORT
|
2019-05-16 10:03:58 +00:00
|
|
|
|
2018-06-18 18:56:26 +00:00
|
|
|
config MVEBU_SPL_BOOT_DEVICE_UART
|
|
|
|
|
bool "UART"
|
2021-07-23 09:14:25 +00:00
|
|
|
select SPL_BOOTROM_SUPPORT
|
2018-06-18 18:56:26 +00:00
|
|
|
|
2017-06-09 17:28:45 +00:00
|
|
|
endchoice
|
|
|
|
|
|
2017-01-11 15:01:00 +00:00
|
|
|
config MVEBU_EFUSE
|
|
|
|
|
bool "Enable eFuse support"
|
|
|
|
|
default n
|
|
|
|
|
depends on HAVE_MVEBU_EFUSE
|
|
|
|
|
help
|
|
|
|
|
Enable support for reading and writing eFuses on mvebu SoCs.
|
|
|
|
|
|
|
|
|
|
config MVEBU_EFUSE_FAKE
|
|
|
|
|
bool "Fake eFuse access (dry run)"
|
|
|
|
|
default n
|
|
|
|
|
depends on MVEBU_EFUSE
|
|
|
|
|
help
|
|
|
|
|
This enables a "dry run" mode where eFuses are not really programmed.
|
|
|
|
|
Instead the eFuse accesses are emulated by writing to and reading
|
|
|
|
|
from a memory block.
|
|
|
|
|
This is can be used for testing prog scripts.
|
|
|
|
|
|
|
|
|
|
config SECURED_MODE_IMAGE
|
|
|
|
|
bool "Build image for trusted boot"
|
|
|
|
|
default false
|
|
|
|
|
depends on 88F6820
|
|
|
|
|
help
|
|
|
|
|
Build an image that employs the ARMADA SoC's trusted boot framework
|
|
|
|
|
for securely booting images.
|
|
|
|
|
|
|
|
|
|
config SECURED_MODE_CSK_INDEX
|
|
|
|
|
int "Index of active CSK"
|
|
|
|
|
default 0
|
|
|
|
|
depends on SECURED_MODE_IMAGE
|
|
|
|
|
|
2020-03-23 20:21:32 +00:00
|
|
|
source "board/solidrun/clearfog/Kconfig"
|
2020-12-09 03:07:36 +00:00
|
|
|
source "board/kobol/helios4/Kconfig"
|
2020-03-23 20:21:32 +00:00
|
|
|
|
2015-08-25 11:18:38 +00:00
|
|
|
endif
|
