1. 19 Sep, 2021 3 commits
    • Simon Glass's avatar
      doc: Add documentation about devicetree usage · d9a29c9b
      Simon Glass authored
      At present some of the ideas and techniques behind devicetree in U-Boot
      are assumed, implied or unsaid. Add some documentation to cover how
      devicetree is build, how it can be modified and the rules about using
      the various CONFIG_OF_... options.
      
      Commit-notes:
      This patch attracted quite a bit of discussion here:
      
      https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-sjg@chromium.org/
      
      
      
      I have not included the text suggested by François. While I agree that
      it would be useful to have an introduction in this space, I do not agree
      that we should have two devicetrees or that U-Boot should not have its own
      things in the devicetree, so it is not clear to me what we should actually
      write.
      
      The 'Devicetree Control in U-Boot' docs were recently merged and these
      provide some base info, for now.
      END
      
      Series-to: u-boot
      Series-version: 4
      Series-links: 261659
      Series-cc: Mark Kettenis <mark.kettenis@xs4all.nl>
      Series-cc: trini, heinrich
      Series-cc: Sean Anderson <seanga2@gmail.com>
      Series-cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
      Series-changes: 2
      - Fix typos per Sean (thank you!) and a few others
      - Add a 'Use of U-Boot /config node' section
      - Drop mention of dm-verity since that actually uses the kernel cmdline
      - Explain that OF_BOARD will still work after these changes (in
        'Once this bug is fixed...' paragraph)
      - Expand a bit on the reason why the 'Current situation' is bad
      - Clarify in a second place that Linux and U-Boot use the same devicetree
        in 'To be clear, while U-Boot...'
      - Expand on why we should have rules for other projects in
        'Devicetree in another project'
      - Add a comment as to why devicetree in U-Boot is not 'bad design'
      - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
      - Rewrite 'Devicetree generated on-the-fly in another project' to cover
        points raised on v1
      - Add 'Why does U-Boot have its nodes and properties?'
      - Add 'Why not have two devicetrees?'
      
      Series-changes: 3
      - Clarify the 'bug' refered to at the top
      - Reword 'This means that there' paragraph to explain U-Boot-specific things
      - Move to doc/develop/devicetree now that OF_CONTROL is in the docs
      
      Cover-letter:
      doc: Clarify how U-Boot makes use of devicetree
      This series includes a documentation update to clarify how U-Boot makes
      use of devicetree and its requirements when working with other firmware
      projects.
      
      Once agreed it should provide more clarity in this area, which seems to
      have devolved into a confusing mire recently.
      
      My goal here is to sort out this area one and for all, clearly documenting
      the use cases and implications of them. I hope that the end result of this
      (substantial) effort will be a shared understanding of how to move
      forward in U-Boot and hopefully some ideas for firmware in general.
      
      It also cleans up the config binding since this has got a bit out-of-date.
      END
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarMarcel Ziswiler <marcel.ziswiler@toradex.com>
      d9a29c9b
    • Simon Glass's avatar
      doc: Add mention of the /config binding · 803725ac
      Simon Glass authored
      
      
      The devicetree binding files are in their own directory and use a simple
      text format. Add a link for the binding for the /config node, since it
      is otherwise hard to find.
      
      Series-changes: 4
      - Add a patch to refer to the /config binding from docs
      Suggested-by: Heinrich Schuchardt's avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      803725ac
    • Tom Rini's avatar
      Merge tag 'dm-pull-18sep21' of https://source.denx.de/u-boot/custodians/u-boot-dm · 3f571228
      Tom Rini authored
      Revert the public-key-embedded-in-executable patches so this does not form
      part of an official release before it is agreed.
      3f571228
  2. 18 Sep, 2021 3 commits
  3. 17 Sep, 2021 11 commits
    • Tom Rini's avatar
      Merge branch '2021-09-17-TI-platform-updates' · d0b8c9a2
      Tom Rini authored
      - Assorted bugfixes for TI platforms
      d0b8c9a2
    • Nishanth Menon's avatar
      arm: mach-k3: common: Make sure firmware sections are loaded prior to armv8 startup · ee91d465
      Nishanth Menon authored and Tom Rini's avatar Tom Rini committed
      With Device Manager firmware in an elf file form, we cannot load the FIT
      image to the exact same address as any of the executable sections of the
      elf file itself is located.
      
      However, the device tree descriptions for the ARMV8 bootloader/OS
      includes DDR regions only the final sections in DDR where the Device
      Manager firmware is actually executing out of.
      
      As the R5 uC is usually operating at a slower rate than an ARMv8 MPU,
      by starting the Armv8 ahead of parsing the elf and copying the correct
      sections to the required memories creates a race condition where the
      ARMv8 could overwrite the elf image loaded from the FIT image prior to
      the R5 completing parsing and putting the correct sections of elf in
      the required memory locations. OR create rather obscure debug conditions
      where data in the section is being modified by ARMV8 OS while the elf
      copy is in progress.
      
      To prevent all these conditions, lets make sure that the elf pa...
      ee91d465
    • Roger Quadros's avatar
      arm: mach-k3: am6_init: Prioritize MSMC traffic over DDR in NAVSS Northbridge · 6887f8e0
      Roger Quadros authored and Tom Rini's avatar Tom Rini committed
      
      
      NB0 is bridge to SRAM and NB1 is bridge to DDR.
      
      To ensure that SRAM transfers are not stalled due to delays during DDR
      refreshes, SRAM traffic should be higher priority (threadmap=2) than
      DDR traffic (threadmap=0).
      
      This fixup is critical to provide deterministic access latency to
      MSMC from ICSSG, it applies to all AM65 silicon revisions and is due
      to incorrect reset values (has no erratum id) and statically setting
      things up should be done independent of usecases and board.
      
      This specific style of Northbridge configuration is specific only to
      AM65x devices, follow-on K3 devices have different data prioritization
      schemes (ASEL and the like) and hence the fixup applies purely to
      AM65x.
      
      Without this fix, ICSSG TX lock-ups due to delays in MSMC transfers in
      case of SR1 devices, on SR2 devices, lockups were not observed so far
      but high retry rates of ICSSG Ethernet (icssg-eth) and, thus, lower
      throughput.
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Acked-by: default avatarAndrew F. Davis <afd@ti.com>
      Acked-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarBenoit Parrot <bparrot@ti.com>
      [Jan: rebased, dropped used define, extended commit log]
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      [Nishanth: Provide relevant context in the commit message]
      Signed-off-by: Nishanth Menon<nm@ti.com>
      6887f8e0
    • Suman Anna's avatar
      clk: ti: k3: Update driver to account for divider flags · cfd50dfb
      Suman Anna authored and Tom Rini's avatar Tom Rini committed
      
      
      The K3 SoCs have some PLL output clocks (POSTDIV clocks) which in
      turn serve as inputs to other HSDIV output clocks. These clocks use
      the actual value to compute the divider clock rate, and need to be
      registered with the CLK_DIVIDER_ONE_BASED flags. The current k3-clk
      driver and data lacks the infrastructure to pass in divider flags.
      Update the driver and data to account for these divider flags.
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
      cfd50dfb
    • Dave Gerlach's avatar
      clk: ti: k3-pll: Change DIV_CTRL programming to read-modify-write · d3c56e2a
      Dave Gerlach authored and Tom Rini's avatar Tom Rini committed
      There are three different divider values in the DIV_CTRL register
      controlled by the k3-pll driver. Currently the ti_pll_clk_set_rate
      function writes the entire register when programming plld, even though
      plld only resides in the lower 6 bits.
      
      Change the plld programming to read-modify-write to only affect the
      relevant bits for plld and to preserve the other two divider values
      present in the upper 16 bits, otherwise they will always get set to zero
      when programming plld.
      
      Fixes: 0aa2930c
      
       ("clk: add support for TI K3 SoC PLL")
      Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
      d3c56e2a
    • Dave Gerlach's avatar
      arm: mach-k3: Add note to auto-generated files · ae8d3d23
      Dave Gerlach authored and Tom Rini's avatar Tom Rini committed
      
      
      Add a note to the automatically generated clk-data and dev-data files
      for j721e and j7200 to indicate that they are in fact auto-generated and
      should not be hand edited.
      
      Also adjust TI URL to use https instead of http and also add an empty
      line before first header inclusion.
      Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
      ae8d3d23
    • Suman Anna's avatar
      arm: mach-k3: j7200: Fix clk-data parenting for postdiv PLL clocks · 326c03b5
      Suman Anna authored and Tom Rini's avatar Tom Rini committed
      The TI K3 Fractional PLLs use two programmable POSTDIV1 and POSTDIV2
      divisors to generate the final FOUTPOSTDIV clock. These are in sequence
      with POSTDIV2 following the POSTDIV1 clock. The current J7200 clock data
      has the POSTDIV2 clock as the parent for the POSTDIV1 clock, which is
      opposite of the actual implementation. Fix the data by simply adjusting
      the register bit-shifts.
      
      The Main PLL1 POSTDIV clocks were also defined incorrectly using Main PLL0
      register values, fix these as well.
      
      Fixes: 277729ea
      
       ("arm: mach-k3: Add platform data for j721e and j7200")
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
      326c03b5
    • Suman Anna's avatar
      arm: mach-k3: j721e: Fix clk-data parenting for postdiv PLL clocks · f1a815d0
      Suman Anna authored and Tom Rini's avatar Tom Rini committed
      The TI K3 Fractional PLLs use two programmable POSTDIV1 and POSTDIV2
      divisors to generate the final FOUTPOSTDIV clock. These are in sequence
      with POSTDIV2 following the POSTDIV1 clock. The current J721E clock data
      has the POSTDIV2 clock as the parent for the POSTDIV1 clock, which is
      opposite of the actual implementation. Fix the data by simply adjusting
      the register bit-shifts.
      
      The Main PLL1 POSTDIV clocks were also defined incorrectly using Main PLL0
      register values, fix these as well.
      
      Fixes: 277729ea
      
       ("arm: mach-k3: Add platform data for j721e and j7200")
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
      f1a815d0
    • Suman Anna's avatar
      arm: mach-k3: common: Add a release_resources_for_core_shutdown() stub · d86a089d
      Suman Anna authored and Tom Rini's avatar Tom Rini committed
      
      
      Add a weak release_resources_for_core_shutdown() stub implementation
      that can be overridden by actual implementation if a SoC supports that
      function.
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Reviewed-by: default avatarNishanth Menon <nm@ti.com>
      d86a089d
    • Suman Anna's avatar
      firmware: ti_sci: Include linux/err.h in ti_sci_protocol.h · 04662755
      Suman Anna authored and Tom Rini's avatar Tom Rini committed
      
      
      The common TI SCI header file uses some macros from err.h and these
      get exercised when CONFIG_TI_SCI_PROTOCOL is not defined. Include
      the linux/err.h header file in this header file directly rather
      than relying on source files to include it to eliminate any
      potential build errors.
      
      While at this, reorder the existing header file include to the
      beginning of the file.
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Reviewed-by: default avatarNishanth Menon <nm@ti.com>
      04662755
    • Christophe Leroy's avatar
      MAINTAINERS: POWERPC MPC8XX: Update email address · 12ff1a8d
      Christophe Leroy authored and Tom Rini's avatar Tom Rini committed
      
      
      Our email addresses have changed from @c-s.fr to @csgroup.eu
      
      Update entry in MAINTAINERS
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@csgroup.eu>
      12ff1a8d
  4. 15 Sep, 2021 5 commits
  5. 14 Sep, 2021 9 commits
  6. 13 Sep, 2021 9 commits