Skip to content
Snippets Groups Projects
  1. Jan 14, 2022
    • This contributor prefers not to receive mails's avatar
      tools: kwbimage: Show binary image offset in mkimage -l, in addition to size · c934c9a6
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      For debugging purposes it is good to know where the binary image would be
      loaded and also it is needed to know if printed size is image size or the
      size of header together with image.
      
      Make it unambiguous by showing that printed size is not the size of the
      whole header, but only the size of executable code, and print also the
      executable offset of this binary image. Load/execute address is the offset
      relative to the base address (either 0x40004000 or 0x40000000).
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      c934c9a6
    • This contributor prefers not to receive mails's avatar
      tools: kwbimage: Add missing check for maximal value for DATA_DELAY · fdcae261
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      Data delay is stored as 8-bit number in kwbimage structure. Ensure the
      given value is at most 255.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      fdcae261
    • This contributor prefers not to receive mails's avatar
      arm: mvebu: Enable BootROM output on A38x · 18d85d6e
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      BootROMs on pre-A38x SoCs enabled its output on UART by default, but A38x'
      BootROM has its output on UART disabled by default.
      
      To enable BootROM output on A38x SoC, it is required to set DEBUG flag
      (which only enables BootROM output and nothing more) in kwbimage. For UART
      images this DEBUG flag is ignored by BootROM.
      
      Enable kwbimage DEBUG flag for all A38x boards.
      
      With this change BootROM prints the following (success) information on UART
      before booting U-Boot kwbimage:
      
        BootROM - 1.73
        Booting from SPI flash
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      18d85d6e
    • This contributor prefers not to receive mails's avatar
      tools: kwbimage: Enforce 128-bit boundary alignment only for Sheeva CPU · bdf8c9f2
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      This alignment is required only for platforms based on Sheeva CPU core
      which are A370 and AXP. Now when U-Boot build system correctly propagates
      LOAD_ADDRESS there is no need to have enabled 128-bit boundary alignment on
      platforms which do not need it. Previously it was required because load
      address was implicitly rounded to 128-bit boundary and U-Boot build system
      expected it and misused it. Now with explicit setting of LOAD_ADDRESS there
      is no guessing for load address anymore.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      bdf8c9f2
    • This contributor prefers not to receive mails's avatar
      arm: mvebu: Correctly set LOAD_ADDRESS for U-Boot SPL binary in kwbimage · a2b1db41
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      U-Boot SPL for mvebu platform is not compiled as position independent.
      Therefore it is required to instruct BootROM to load U-Boot SPL at the
      correct address. Loading of kwbimage binary code at specific address can be
      now achieved by the new LOAD_ADDRESS token as part of BINARY command in
      kwbimage config file.
      
      Update mvebu Makefile to put value of $(CONFIG_SPL_TEXT_BASE) into
      LOAD_ADDRESS token when generating kwbimage.cfg from kwbimage.cfg.in.
      
      It is required to update regex for sed to find replacement tokens at any
      position on a line in kwbimage config file and not only at the beginning of
      the line. This is because LOAD_ADDRESS is specified at the end of line
      containing the BINARY command.
      
      It looks like all Armada boards set CONFIG_SPL_TEXT_BASE to value
      0x40004030 or 0x40000030. Why this value? It is because main kwbimage
      header is at address 0x40004030 or 0x40000000 and it is 32 bytes long.
      After the main header there is the binary header, which consist of 1 byte
      for type, 3 bytes for size, 1 byte for number of arguments, 3 reserved
      bytes and then 4 bytes for each argument. After these arguments comes the
      executable code.
      
      So arguments start at address 0x40004028 or 0x40000028. Before commit
      e6571f38 ("arm: mvebu: Remove dummy BIN header arguments for SPL
      binary") there were two (dummy) arguments, which resulted in load address
      of 0x40004030 or 0x40000030, always. After that commit (which removed dummy
      arguments), load address stayed same due to the 128-bit alignment done by
      mkimage.
      
      This patch now reflects the dependency between $(CONFIG_SPL_TEXT_BASE),
      load address and dummy kwbimage arguments, and allows the user to adjust
      $(CONFIG_SPL_TEXT_BASE) config option to some other value.
      
      For unsupported values, when mkimage/kwbimage cannot set chosen load address
      as specified by $(CONFIG_SPL_TEXT_BASE), the build process now fails,
      instead of silently generating non-working kwbimage.
      
      Removal of this alignment between $(CONFIG_SPL_TEXT_BASE) and LOAD_ADDRESS
      can only be done by compiling U-Boot SPL as position independent. But this
      currently is not possible for 32-bit ARM version of U-Boot SPL.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      a2b1db41
    • This contributor prefers not to receive mails's avatar
      arm: mvebu: Set CPU for U-Boot SPL binary in kwbimage · 29c6a9c7
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      kwbimage needs to know CPU type, so set it in kwbimage config file.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      29c6a9c7
    • This contributor prefers not to receive mails's avatar
      tools: kwbimage: Check for maximal kwbimage header size · 78d997f9
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      BootROM loads kwbimage header to L2-SRAM and BootROM reserve only 192 kB for it.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      78d997f9
    • This contributor prefers not to receive mails's avatar
      tools: kwbimage: Check the return value of image_headersz_v1() · 252e7c3a
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      Function image_headersz_v1() may return zero on fatal errors.
      In this case the function already printed an error message.
      
      Check the return value of image_headersz_v1() in kwbimage_generate(),
      and exit on zero value with EXIT_FAILURE.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      252e7c3a
    • This contributor prefers not to receive mails's avatar
      tools: kwbimage: Add support for specifying LOAD_ADDRESS for BINARY command · 0aca27ea
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      ARM executable code included in kwbimage binary header, which is not
      position independent, needs to be loaded and executed by BootROM at the
      correct fixed address.
      
      Armada BootROMs load kwbimage header (in which the executable code is also
      stored) at fixed address 0x40004000 or 0x40000000 which is mapped to
      L2-SRAM (L2 Cache as SRAM). Address 0x40004000 is used on Armada platforms
      with Sheeva CPU core (A370 and AXP) where BootROM uses MMU with 0x4000
      bytes for MMU translation table. Address 0x40000000 is used on all other
      platforms.
      
      Thus the only way to specify load and execute address of this executable
      code in binary kwbimage header is by filling dummy arguments into the
      binary header, using the same mechanism we already have for achieving
      128-bit boundary alignment on A370 and AXP SoCs.
      
      Extend kwbimage config file parser to allow to specify load address as
      part of BINARY command with syntax:
      
          BINARY path_to_binary arg1 arg2 ... argN LOAD_ADDRESS address
      
      If the specified load address is invalid or cannot be used, mkimage will
      throw fatal error and exit. This will prevent generating kwbimage with
      invalid load address for non-position independent binary code.
      
      If no load address is specified, kwbimage will not fill any the dummy
      arguments, thus it will behave the same as before this change.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      0aca27ea
    • This contributor prefers not to receive mails's avatar
      tools: kwbimage: Add support for specifying CPU core · af49605b
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      For other changes it is required to know if CPU core is Sheeva or not.
      Therefore add a new command CPU for specifying CPU.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      af49605b
    • This contributor prefers not to receive mails's avatar
      arm: mvebu: Generate kwbimage.cfg with $(call cmd, ...) · 6329d440
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      Usage of $(call cmd,...) is standard way to call other commands which
      generate things.
      
      It also has the advantage of printing build information in the form
        KWBCFG  arch/arm/mach-mvebu/kwbimage.cfg
      if verbosity is disabled, and printing the build command otherwise.
      
      Note that the '#' character needs to be escaped in Makefile when used as
      value for make variable assignment.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      6329d440
    • This contributor prefers not to receive mails's avatar
      tools: kwbimage: Preserve order of BINARY, DATA and DATA_DELAY commands · 3db9c417
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      Preserve the order of BINARY, DATA and DATA_DELAY commands as they appear
      in the input file. They may depend on each other.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      3db9c417
    • This contributor prefers not to receive mails's avatar
      tools: kwbimage: Fix generating image with multiple DATA_DELAY commands · d737d5d2
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      Register set header consists of sequence of DATA commands followed by
      exactly one DATA_DELAY command. Thus if we are generating image with
      multiple DATA_DELAY commands, we need to create more register set headers.
      
      Fix calculation of image size with multiple DATA_DELAY commands and
      correctly set pointer to struct register_set_hdr_v1 when initializing new
      register set header.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      d737d5d2
    • This contributor prefers not to receive mails's avatar
      tools: kwbimage: Deduplicate v1 regtype header finishing · 9ac1def0
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      Deduplicate code that finishes OPT_HDR_V1_REGISTER_TYPE header by
      extracing it into separate function.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      9ac1def0
    • This contributor prefers not to receive mails's avatar
      tools: kwbimage: Mark all local functions as static · 6eb20bbf
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      Mark all local functions as static.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      6eb20bbf
    • Marek Behún's avatar
      ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision · 3fc92a21
      Marek Behún authored and Stefan Roese's avatar Stefan Roese committed
      
      This is a cleaned up and fixed version of a patch
        mv_ddr: a380: fix SPLIT_OUT_MIX state decision
      
        in each pattern cycle the bus state can be changed
        in order to avoide it, need to back to the same bus state on each
        pattern cycle
      by
        Moti Boskula <motib@marvell.com>
      
      The original patch is not in Marvell's mv-ddr-marvell repository. It was
      gives to us by Marvell to fix an issues with DDR training on some
      boards, but it cannot be applied as is to mv-ddr-marvell, because it is
      a very dirty draft patch that would certainly break other things, mainly
      DDR4 training code in mv-ddr-marvell, since it changes common functions.
      
      I have cleaned up the patch and removed stuff that seemed unnecessary
      (when removed, it still fixed things). Note that I don't understand
      completely what the code does exactly, since I haven't studied the DDR
      training code extensively (and I suspect that no one besides some few
      people in Marvell understand the code completely).
      
      Anyway after the cleanup the patch still fixes isssues with DDR training
      on the failing boards.
      
      There was also a problem with the original patch on some of the Allied
      Telesis' x530 boards, reported by Chris Packham. I have asked Chris to
      send me some logs, and managed to fix it:
      - if you look at the change, you'll notice that it introduces
        subtraction of cur_start_win[] and cur_end_win[] members, depending on
        a bit set in the current_byte_status variable
      - the original patch subtracted cur_start_win[] if either
        BYTE_SPLIT_OUT_MIX or BYTE_HOMOGENEOUS_SPLIT_OUT bits were set, but
        subtracted cur_end_win[] only if the first one (BYTE_SPLIT_OUT_MIX)
        was set
      - from Chris Packham logs I discovered that the x530 board where the
        original patch introduced DDR training failure, only the
        BYTE_HOMOGENEOUS_SPLIT_OUT bit was set, and on our boards where the
        patch is needed only the BYTE_SPLIT_OUT_MIX is set in the
        current_byte_status variable
      - this led me to the hypothesis that both cur_start_win[] and
        cur_end_win[] should be subtracted only if BYTE_SPLIT_OUT_MIX bit is
        set, the BYTE_HOMOGENEOUS_SPLIT_OUT bit shouldn't be considered at all
      - this hypothesis also gains credibility when considering the commit
        title ("fix SPLIT_OUT_MIX state decision")
      
      Hopefully this will fix things without breaking anything else.
      
      Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      Tested-by: default avatarChris Packham <judge.packham@gmail.com>
      3fc92a21
    • Marek Behún's avatar
      board: gdsys: Drop Dirk Eibach from MAINTAINERS · 28c19226
      Marek Behún authored and Stefan Roese's avatar Stefan Roese committed
      
      I got an
      
      <dirk.eibach@gdsys.cc>: host mxlb.ispgateway.de[80.67.18.126] said:
        554 Sorry, no mailbox here by that name. (in reply to RCPT TO command)
      
      when sending e-mail to dirk.eibach@gdsys.cc.
      
      Drop Dirk Eibach from MAINTAINERS of board/gdsys/a38x and
      board/gdsys/mpc8308. The latter would be left maintainerless, add
      Mario Six <mario.six@gdsys.cc> (he is also maintainer of the former
      board).
      
      Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      28c19226
    • Marek Behún's avatar
      ddr: marvell: a38x: Fix Synchronous vs Asynchronous mode determination · eadc4f51
      Marek Behún authored and Stefan Roese's avatar Stefan Roese committed
      
      Before commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
      mode"), Asynchornous Mode was only used when the CPU Subsystem Clock
      Options[4:0] field in the SAR1 register was set to value 0x13: CPU at
      2 GHz and DDR at 933 MHz.
      
      Then commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
      mode") added support for Asynchornous Modes with frequencies other than
      933 MHz (but at least 467 MHz), but the code it added to check for
      whether Asynchornous Mode should be used is wrong: it checks whether the
      frequency setting in board DDR topology map is set to value other than
      MV_DDR_FREQ_SAR.
      
      Thus boards which define a specific value, greater than 400 MHz, for DDR
      frequency in their board topology (e.g. Turris Omnia defines
      MV_DDR_FREQ_800), are incorrectly put into Asynchornous Mode after that
      commit.
      
      The A38x Functional Specification, section 10.12 DRAM Clocking, says:
        In Synchornous mode, the DRAM and CPU clocks are edge aligned and run
        in 1:2 or 1:3 CPU to DRAM frequency ratios.
      
      Change the check for whether Asynchornous Mode should be used according
      to this explanation in Functional Specification.
      
      Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
      Tested-by: default avatarChris Packham <judge.packham@gmail.com>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      eadc4f51
    • Tony Dinh's avatar
      arm: kirkwood: iConnect : Update board maintainer · 1b24de6e
      Tony Dinh authored and Stefan Roese's avatar Stefan Roese committed
      
      Add myself as maintainer.
      
      Signed-off-by: default avatarTony Dinh <mibodhi@gmail.com>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      1b24de6e
    • Tony Dinh's avatar
      arm: kirkwood: iConnect : Add PCIe late init · bbebd5b0
      Tony Dinh authored and Stefan Roese's avatar Stefan Roese committed
      
      - Add board_late_init function to enable pci_init
      
      Signed-off-by: default avatarTony Dinh <mibodhi@gmail.com>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      bbebd5b0
    • Tony Dinh's avatar
      arm: kirkwood: iConnect : Add PCIe related configs · 531d4bb0
      Tony Dinh authored and Stefan Roese's avatar Stefan Roese committed
      
      - Add MVEBU PCIe configs
      - Also add SYS_THUMB_BUILD to keep u-boot image size within 512K
      
      Signed-off-by: default avatarTony Dinh <mibodhi@gmail.com>
      Reviewed-by: default avatarStefan Roese <sr@denx.de>
      531d4bb0
    • Pierre Bourdon's avatar
      mtd: nand: pxa3xx: use marvell, prefix for custom DT properties · c03f4da1
      Pierre Bourdon authored and Stefan Roese's avatar Stefan Roese committed
      
      The DT properties for the "enable-arbiter" and "keep-config" config
      knobs were previously named inconsistently:
      
      - The u-boot driver used "nand-enable-arbiter" and "nand-keep-config"
        names, without Marvell prefixes.
      
      - The Linux driver uses "marvell,nand-keep-config" ("enable-arbiter"
        does not exist anymore in recent kernels, but it also used to be
        "marvell,nand-enable-arbiter").
      
      - The device trees almost all use "marvell," prefixed names, except for
        one single instance of "nand-enable-arbiter" without vendor prefix.
      
      This commit standardizes on the vendor prefixed version, making the
      u-boot driver read from DT props "marvell,nand-enable-arbiter" and
      "marvell,nand-keep-config". The one device tree using the unprefixed
      version is also changed to use the new naming.
      
      This has the side effect of making the previously no-op "marvell,"
      config knobs already present in some DTs actually do something. This was
      likely the original intention of the DT authors, but note that this
      commit was not tested on every single impacted board.
      
      Signed-off-by: default avatarPierre Bourdon <delroth@gmail.com>
      c03f4da1
    • This contributor prefers not to receive mails's avatar
      arm: mvebu: a38x: serdes: Move non-serdes PCIe code to pci_mvebu.c · 94c30f9c
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      As explained in commit 3bedbcc3 ("arm: mvebu: a38x: serdes: Don't
      overwrite read-only SAR PCIe registers") it is required to set Maximum Link
      Width bits of PCIe Root Port Link Capabilities Register depending of number
      of used serdes lanes. As this register is part of PCIe address space and
      not serdes address space, move it into pci_mvebu.c driver.
      
      Read number of PCIe lanes from DT property "num-lanes" which is used also
      by other PCIe controller drivers in Linux kernel. If this property is
      absent then it defaults to 1. This property needs to be set to 4 for every
      mvebu board which use PEX_ROOT_COMPLEX_X4 or PEX_BUS_MODE_X4.
      
      Enabling of PCIe port needs to be done afer all registers in PCIe address
      space are properly configure. For this purpose use new mvebu-reset driver
      (part of system-controller) and remove this code from serdes code.
      
      Because some PCIe ports cannot be enabled individually, it is required to
      first setup all PCIe ports and then enable them.
      
      This change contains also all required "num-lanes" and "resets" DTS
      properties, to make pci_mvebu.c driver work correctly.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      94c30f9c
    • This contributor prefers not to receive mails's avatar
      arm: mvebu: Implement simple mvebu-reset driver for enabling/disabling PCIe ports · 35e29e89
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      Enabling and disabling PCIe ports is done via address space of system
      controller. All 32-bit Armada SoCs use low 4 bits in SoC Control 1 Register
      for enabling and disabling some or more PCIe ports. Correct mapping needs
      to be set in particular DTS files.
      
      DT API for mvebu-reset is prepared for implementing resets also for other
      HW blocks, but currently only PCIe is implemented via index 0.
      
      Currently this driver is not used as PCIe ports are automatically enabled
      by SerDes code executed by U-Boot SPL. But this will change in followup
      patches.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      35e29e89
    • This contributor prefers not to receive mails's avatar
      pci: pci_mvebu: Wait 100ms for Link Up in mvebu_pcie_probe() · e7ff4271
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      After function mvebu_pcie_probe() returns U-Boot DM expects that PCIe link
      is already up. In followup patches link initialization will be moved from
      SPL to proper and therefore explicitly link up delay is required.
      
      Delay mvebu_pcie_probe() for 100ms to ensure that PCIe link is up after
      function finish. In the case when no card is connected to the PCIe slot,
      this will delay probe time by 100ms, which should not be problematic.
      
      This change fixes detection and initialization of some QCA98xx cards on
      the first serdes when configured in x1 mode. Default configuration of
      the first serdes on A385 is x4 mode, so it looks as if some delay is
      required when x4 is changed to x1 and card correctly links with A385.
      Other PCIe serdes ports on A385 are x1-only, and so they don't have this
      problem.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      e7ff4271
    • This contributor prefers not to receive mails's avatar
      pci: pci_mvebu: Split initialization of PCIe ports into 3 phases · afef9f42
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      In first phase just parse DT properties and fill struct mvebu_pcie. In
      second phase setup all PCIe links (without enabling them). And in the last
      third phase enable all PCIe links and create UCLASS_PCI device for each
      one.
      
      Because parsing of DT is done before UCLASS_PCI is created, we cannot use
      DM for this action anymore. So remove .of_to_plat callback and replace it
      by ad-hoc function for parsing DT properties and filling struct mvebu_pcie.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      afef9f42
    • This contributor prefers not to receive mails's avatar
      pci: pci_mvebu: Remove dependency on SOC_REGS_PHY_BASE macro · 137db2af
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      SoC specific macro SOC_REGS_PHY_BASE is used for two things:
      
      * calculation of base PCIe port address
      * filling PCIe register with address of internal registers
      
      For calculating base PCIe port address use function
      ofnode_translate_address() which translates DT "assigned-addresses" to
      final PCIe port address.
      
      And for calculating address of internal registers use untranslated and
      translated DT "assigned-addresses".
      
      Basically this change reads SOC_REGS_PHY_BASE address indirectly from DT.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      137db2af
    • This contributor prefers not to receive mails's avatar
      pci: pci_mvebu: Inline mvebu_pcie_port_parse_dt() function · 6f4988f9
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      Function mvebu_pcie_port_parse_dt() is called only from
      mvebu_pcie_of_to_plat() function. Both these function parse DT properties
      required to setup mvebu pcie. So inline mvebu_pcie_port_parse_dt() function
      into mvebu_pcie_of_to_plat() to have all code related to parsing DT
      properties at one place.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      6f4988f9
    • This contributor prefers not to receive mails's avatar
      pci: pci_mvebu: Fix PCIe MEM and IO resources assignment and mbus mapping · 537b0142
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      Do not call pci_set_region() for resources which were not properly mapped.
      This prevents U-Boot to access unmapped memory space.
      
      Update MBUS_PCI_MEM_SIZE and MBUS_PCI_IO_SIZE macros to cover all PCIe MEM
      and IO ranges. Previously these macros covered only address ranges for the
      first PCIe port. Between MBUS_PCI_IO_BASE and MBUS_PCI_MEM_BASE there is
      space for six 128 MB long address ranges. So set MBUS_PCI_MEM_SIZE to value
      of 6*128 MB. Similarly set MBUS_PCI_IO_SIZE to 6*64 KB.
      
      Function resource_size() returns zero when start address is 0 and end
      address is -1. So set invalid resources to these values to indicate that
      resource has no mapping.
      
      Split global PCIe MEM and IO resources (defined by MBUS_PCI_*_* macros)
      into PCIe ports in mvebu_pcie_bind() function which allocates per-port
      based struct mvebu_pcie, instead of using global state variables
      mvebu_pcie_membase and mvebu_pcie_iobase. This makes pci_mvebu.c driver
      independent of global static variables (which store the state of
      allocation) and allows to bind and unbind the driver more times.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
      537b0142
    • This contributor prefers not to receive mails's avatar
      board: gdsys: a38x: Enable PCIe link 2 in spl_board_init() · 2ac06f3e
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      A385 controlcenterdc board does not use PCI DM properly and touches some
      PCIe devices directly in its board code.
      
      This controlcenterdc spl_board_init() function expects that PCIe link is
      already initialized. Link itself is initialized in a38x serdes code but
      this will change in future and link initialization will be postponed from
      U-Boot SPL to proper U-Boot.
      
      So explicitly enable PCIe link 2 in spl_board_init() function via
      SoC Control Register 1 to not break this code by future changes. This board
      has PCIe link 2 just x1, so no additional initialization (except enabling
      PCIe port) is needed.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      2ac06f3e
    • This contributor prefers not to receive mails's avatar
      arm: mvebu: Convert board_pex_config() to CONFIG_SPL_BOARD_INIT · 8f9e0f4d
      This contributor prefers not to receive mails authored and Stefan Roese's avatar Stefan Roese committed
      
      The only user of board_pex_config() weak function is A385 controlcenterdc
      board. It looks like that code in its board_pex_config() function needs to
      be executed after PCIe link is up. Therefore put this code into
      spl_board_init() function which is called after a38x serdes initialization,
      and therefore it is after the serdes hws_pex_config() function finishes
      (which is the state before this change).
      
      With this change completely remove board_pex_config() function as it is not
      used anymore.
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      8f9e0f4d
  2. Jan 13, 2022
Loading