18 Jan, 2020

1 commit


12 Aug, 2019

1 commit


12 Apr, 2019

1 commit

  • This patch enables the PCIe port specific link capabilities configuration
    for Armada XP. The weak function board_sat_r_get() was used to return
    a common flag for PCIe Gen1 vs Gen2 capability for all PCIe ports. This
    is now changed with this patch to return a bit per PCIe port (4 bits
    in this case, bit 0 for PCIe port 0, etc).

    The theadorable board uses this new feature to configure PCIe port 0
    as Gen1 and all other PCIe ports as Gen2 capable. All other AXP boards
    using this function are not changed in the configuration and still
    configure all ports as PCIe Gen2.

    This patch also removes the parameter "pex_mode" from
    board_serdes_cfg_get() as this parameter was not used in any of the
    implementations.

    Signed-off-by: Stefan Roese
    Cc: Phil Sutter

    Stefan Roese
     

11 Oct, 2018

1 commit


06 Aug, 2018

1 commit

  • Move the gdsys Controlcenter DC specific build time kwbimage.cfg
    generation code into the mach-mvebu/ directory to be shared by all 32bit
    mvebu platforms.

    Remove board specific kwbimage.cfg files, and use the generated one
    instead. These files are all identical, with two exceptions. Clearfog
    and Helios4 use the sdio boot device, whereas all others use spi. Update
    the defconfigs for the exceptional boards to generate the same
    kwbimage.cfg as before.

    Signed-off-by: Baruch Siach
    Signed-off-by: Stefan Roese

    Baruch Siach
     

07 May, 2018

1 commit

  • When U-Boot started using SPDX tags we were among the early adopters and
    there weren't a lot of other examples to borrow from. So we picked the
    area of the file that usually had a full license text and replaced it
    with an appropriate SPDX-License-Identifier: entry. Since then, the
    Linux Kernel has adopted SPDX tags and they place it as the very first
    line in a file (except where shebangs are used, then it's second line)
    and with slightly different comment styles than us.

    In part due to community overlap, in part due to better tag visibility
    and in part for other minor reasons, switch over to that style.

    This commit changes all instances where we have a single declared
    license in the tag as both the before and after are identical in tag
    contents. There's also a few places where I found we did not have a tag
    and have introduced one.

    Signed-off-by: Tom Rini

    Tom Rini
     

06 Nov, 2017

1 commit

  • As part of my usual round of build testing, output about missing
    MAINTAINERS information was not logged, and thus often overlooked.
    Correct that mistake by ensuring that I log the output of
    genboardscfg.py every time. As part of that, address a number of
    missing MAINTAINERS entires. In the case of a missing file, I have put
    the original submitter down. In the rest of the cases I have added the
    config (and sometimes relevant header file) to the existing set of file
    globs.

    Signed-off-by: Tom Rini

    Tom Rini
     

16 Aug, 2017

1 commit


05 Jun, 2017

1 commit


09 Oct, 2016

5 commits


17 Mar, 2016

1 commit

  • 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: Tom Rini

    Tom Rini
     

14 Jan, 2016

2 commits

  • 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: Phil Sutter
    Acked-by: Stefan Roese
    Reviewed-by: Tom Rini

    Phil Sutter
     
  • 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
    Acked-by: Stefan Roese
    Reviewed-by: Tom Rini

    Phil Sutter