1. 09 Oct, 2016 5 commits
  2. 16 Mar, 2016 1 commit
    • Tom Rini's avatar
      mvebu: ds414: Move cmd_syno into ds414 directory · d08fedf6
      Tom Rini authored
      When we switch to including all linker lists in SPL it is important to
      not include commands as that may lead to link errors due to other things
      we have already discarded.  In this case as we don't have other common
      code nor other Synology borads, move the cmd_syno.c file (which claims
      to be ds414 specific anyways!) into the ds414 directory and only build
      it for non-SPL builds.
      Signed-off-by: 's avatarTom Rini <trini@konsulko.com>
      d08fedf6
  3. 14 Jan, 2016 2 commits
    • Phil Sutter's avatar
      mvebu: ds414: Implement Synology specific command set · a12d3e4c
      Phil Sutter authored
      Synology keeps per item configuration in a dedicated 'partition' in SPI
      flash, namely the one named 'vendor' in DTS file. It contains the two
      NICs MAC addresses as well as the item's serial number. I didn't find a
      way to have this information extracted automatically, therefore
      implemented 'syno populate_env' command which extracts the three values
      and puts them into environment. To make things permanent though, one has
      to 'saveenv'.
      
      Another command is 'syno clk_gate', which allows to change the clock
      gating which is done in DS414 board file.
      Signed-off-by: 's avatarPhil Sutter <phil@nwl.cc>
      Acked-by: 's avatarStefan Roese <sr@denx.de>
      Reviewed-by: 's avatarTom Rini <trini@konsulko.com>
      a12d3e4c
    • Phil Sutter's avatar
      mvebu: Support Synology DS414 · aefb8f4c
      Phil Sutter authored
      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: 's avatarPhil Sutter <phil@nwl.cc>
      Acked-by: 's avatarStefan Roese <sr@denx.de>
      Reviewed-by: 's avatarTom Rini <trini@konsulko.com>
      aefb8f4c