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
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2014 Stefan Roese <sr@denx.de>
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: GPL-2.0+
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _CONFIG_SYNOLOGY_DS414_H
|
|
|
|
|
#define _CONFIG_SYNOLOGY_DS414_H
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* High Level Configuration Options (easy to change)
|
|
|
|
|
*/
|
|
|
|
|
#define CONFIG_DISPLAY_BOARDINFO_LATE
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* TEXT_BASE needs to be below 16MiB, since this area is scrubbed
|
|
|
|
|
* for DDR ECC byte filling in the SPL before loading the main
|
|
|
|
|
* U-Boot into it.
|
|
|
|
|
*/
|
|
|
|
|
#define CONFIG_SYS_TCLK 250000000 /* 250MHz */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Commands configuration
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* I2C */
|
|
|
|
|
#define CONFIG_SYS_I2C
|
|
|
|
|
#define CONFIG_SYS_I2C_MVTWSI
|
|
|
|
|
#define CONFIG_I2C_MVTWSI_BASE0 MVEBU_TWSI_BASE
|
|
|
|
|
#define CONFIG_SYS_I2C_SLAVE 0x0
|
|
|
|
|
#define CONFIG_SYS_I2C_SPEED 100000
|
|
|
|
|
|
|
|
|
|
/* SPI NOR flash default params, used by sf commands */
|
|
|
|
|
#define CONFIG_SF_DEFAULT_SPEED 1000000
|
|
|
|
|
#define CONFIG_SF_DEFAULT_MODE SPI_MODE_3
|
|
|
|
|
|
|
|
|
|
/* Environment in SPI NOR flash */
|
|
|
|
|
#define CONFIG_ENV_OFFSET 0x7E0000 /* RedBoot config partition in DTS */
|
|
|
|
|
#define CONFIG_ENV_SIZE (64 << 10) /* 64KiB */
|
|
|
|
|
#define CONFIG_ENV_SECT_SIZE (64 << 10) /* 64KiB sectors */
|
|
|
|
|
|
|
|
|
|
#define CONFIG_PHY_MARVELL /* there is a marvell phy */
|
|
|
|
|
#define CONFIG_PHY_ADDR { 0x1, 0x0 }
|
|
|
|
|
#define CONFIG_SYS_NETA_INTERFACE_TYPE PHY_INTERFACE_MODE_RGMII
|
|
|
|
|
|
|
|
|
|
#define CONFIG_SYS_ALT_MEMTEST
|
|
|
|
|
|
|
|
|
|
/* PCIe support */
|
|
|
|
|
#ifndef CONFIG_SPL_BUILD
|
|
|
|
|
#define CONFIG_PCI_MVEBU
|
|
|
|
|
#define CONFIG_PCI_SCAN_SHOW
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* USB/EHCI/XHCI configuration */
|
|
|
|
|
|
|
|
|
|
#define CONFIG_USB_MAX_CONTROLLER_COUNT 2
|
|
|
|
|
|
|
|
|
|
/* FIXME: broken XHCI support
|
|
|
|
|
* Below defines should enable support for the two rear USB3 ports. Sadly, this
|
|
|
|
|
* does not work because:
|
|
|
|
|
* - xhci-pci seems to not support DM_USB, so with that enabled it is not
|
|
|
|
|
* found.
|
|
|
|
|
* - USB init fails, controller does not respond in time */
|
|
|
|
|
|
2016-06-03 22:35:03 +00:00
|
|
|
#if !defined(CONFIG_USB_XHCI_HCD)
|
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
|
|
|
#define CONFIG_EHCI_IS_TDI
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/* why is this only defined in mv-common.h if CONFIG_DM is undefined? */
|
|
|
|
|
#define CONFIG_SYS_MVFS
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* mv-common.h should be defined after CMD configs since it used them
|
|
|
|
|
* to enable certain macros
|
|
|
|
|
*/
|
|
|
|
|
#include "mv-common.h"
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Memory layout while starting into the bin_hdr via the
|
|
|
|
|
* BootROM:
|
|
|
|
|
*
|
|
|
|
|
* 0x4000.4000 - 0x4003.4000 headers space (192KiB)
|
|
|
|
|
* 0x4000.4030 bin_hdr start address
|
|
|
|
|
* 0x4003.4000 - 0x4004.7c00 BootROM memory allocations (15KiB)
|
|
|
|
|
* 0x4007.fffc BootROM stack top
|
|
|
|
|
*
|
|
|
|
|
* The address space between 0x4007.fffc and 0x400f.fff is not locked in
|
|
|
|
|
* L2 cache thus cannot be used.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* SPL */
|
|
|
|
|
/* Defines for SPL */
|
|
|
|
|
#define CONFIG_SPL_TEXT_BASE 0x40004030
|
|
|
|
|
#define CONFIG_SPL_MAX_SIZE ((128 << 10) - 0x4030)
|
|
|
|
|
|
|
|
|
|
#define CONFIG_SPL_BSS_START_ADDR (0x40000000 + (128 << 10))
|
|
|
|
|
#define CONFIG_SPL_BSS_MAX_SIZE (16 << 10)
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_SPL_BUILD
|
|
|
|
|
#define CONFIG_SYS_MALLOC_SIMPLE
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#define CONFIG_SPL_STACK (0x40000000 + ((192 - 16) << 10))
|
|
|
|
|
#define CONFIG_SPL_BOOTROM_SAVE (CONFIG_SPL_STACK + 4)
|
|
|
|
|
|
|
|
|
|
/* SPL related SPI defines */
|
|
|
|
|
#define CONFIG_SPL_SPI_LOAD
|
|
|
|
|
#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x24000
|
|
|
|
|
|
|
|
|
|
/* DS414 bus width is 32bits */
|
|
|
|
|
#define CONFIG_DDR_32BIT
|
|
|
|
|
|
|
|
|
|
/* Default Environment */
|
|
|
|
|
#define CONFIG_BOOTCOMMAND "sf read ${loadaddr} 0xd0000 0x700000; bootm"
|
|
|
|
|
#define CONFIG_LOADADDR 0x80000
|
|
|
|
|
#undef CONFIG_PREBOOT /* override preboot for USB and SPI flash init */
|
|
|
|
|
#define CONFIG_PREBOOT "usb start; sf probe"
|
|
|
|
|
|
|
|
|
|
#endif /* _CONFIG_SYNOLOGY_DS414_H */
|
