Skip to content
Snippets Groups Projects
  1. Feb 07, 2023
  2. Jun 28, 2022
  3. May 02, 2022
  4. Feb 09, 2022
    • Rasmus Villemoes's avatar
      dts: automatically build necessary .dtb files · 3609e1dc
      Rasmus Villemoes authored and Simon Glass's avatar Simon Glass committed
      
      When building for a custom board, it is quite common to maintain a
      private branch which include some defconfig and .dts files. But to
      hook up those .dts files requires modifying a file "belonging" to
      upstream U-Boot, the arch/*/dts/Makefile. Forward-porting that branch
      to a newer upstream then often results in a conflict which, while it
      is trivial to resolve by hand, makes it harder to have a CI do "try to
      build our board against latest upstream".
      
      The .config usually includes information on precisely what .dtb(s) are
      needed, so to avoid having to modify the Makefile, simply add the
      files in (SPL_)OF_LIST to dtb-y.
      
      A technicality is that (SPL_)OF_LIST is not always defined, so rework
      the Kconfig symbols so that (SPL_)OF_LIST is always defined (when
      (SPL_)OF_CONTROL), but only prompted for in the cases which used to be
      their "depends on".
      
      nios2 and microblaze already have something like this in their
      dts/Makefile, and the rationale in commit 41f59f68 is similar to
      the above. So this simply generalizes existing practice. Followup
      patches could remove the logic in those two makefiles, just as there's
      potential for moving some common boilerplate from all the
      arch/*/dts/Makefile files to the new scripts/Makefile.dts.
      
      Signed-off-by: default avatarRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      3609e1dc
  5. Jan 25, 2022
    • Rasmus Villemoes's avatar
      introduce CONFIG_DEVICE_TREE_INCLUDES · a77f4680
      Rasmus Villemoes authored and Simon Glass's avatar Simon Glass committed
      
      The build system already automatically looks for and includes an
      in-tree *-u-boot.dtsi when building the control .dtb. However, there
      are some things that are awkward to maintain in such an in-tree file,
      most notably the metadata associated to public keys used for verified
      boot.
      
      The only "official" API to get that metadata into the .dtb is via
      mkimage, as a side effect of building an actual signed image. But
      there are multiple problems with that. First of all, the final U-Boot
      (be it U-Boot proper or an SPL) image is built based on a binary
      image, the .dtb, and possibly some other binary artifacts. So
      modifying the .dtb after the build requires the meta-buildsystem
      (Yocto, buildroot, whatnot) to know about and repeat some of the steps
      that are already known to and handled by U-Boot's build system,
      resulting in needless duplication of code. It's also somewhat annoying
      and inconsistent to have a .dtb file in the build folder which is not
      generated by the command listed in the corresponding .cmd file (that
      of course applies to any generated file).
      
      So the contents of the /signature node really needs to be baked into
      the .dtb file when it is first created, which means providing the
      relevant data in the form of a .dtsi file. One could in theory put
      that data into the *-u-boot.dtsi file, but it's more convenient to be
      able to provide it externally: For example, when developing for a
      customer, it's common to use a set of dummy keys for development,
      while the consultants do not (and should not) have access to the
      actual keys used in production. For such a setup, it's easier if the
      keys used are chosen via the meta-buildsystem and the path(s) patched
      in during the configure step. And of course, nothing prevents anybody
      from having DEVICE_TREE_INCLUDES point at files maintained in git, or
      for that matter from including the public key metadata in the
      *-u-boot.dtsi directly and ignore this feature.
      
      There are other uses for this, e.g. in combination with ENV_IMPORT_FDT
      it can be used for providing the contents of the /config/environment
      node, so I don't want to tie this exclusively to use for verified
      boot.
      
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Fix doc formatting error (make htmldocs)
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      a77f4680
  6. Dec 23, 2021
    • Simon Glass's avatar
      fdt: Avoid emitting an device tree when not needed · b7d8e85b
      Simon Glass authored and Tom Rini's avatar Tom Rini committed
      
      U-Boot always needs some sort of a device tree in the build. Some boards
      never actually use this, at least in production systems, since a prior
      firmware stage sets one up and passes it to U-Boot. At present the only
      mechanism to do that is with custom function (OF_BOARD), but future work
      will include a standard way of doing this ('standard passage').
      
      It can be confusing to see a device tree emitted from the U-Boot build in
      this situation. Add an option to drop it.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      b7d8e85b
    • Simon Glass's avatar
      fdt: Add a Kconfig for boards with a prior stage · 275b4832
      Simon Glass authored and Tom Rini's avatar Tom Rini committed
      
      When U-Boot is started from another firmware program, not just a prior
      phase of U-Boot, special behaviour is typically used. In particular, the
      device tree may come from that prior stage.
      
      At present this is sort-of indicated by OF_BOARD, although the
      correlation is not 1:1, since that option simply means that the board has
      a custom mechanism for obtaining the device tree. For example, sandbox
      defines OF_BOARD. Also the board_fdt_blob_setup() function can in fact
      make use of the devicetree in U-Boot if it wishes, as used by
      dragonboard410c until very recently.
      
      Add an explicit Kconfig for this situation. Update the OF_BOARD option to
      more-accurately reflect what it is doing, e.g. for sandbox.
      
      Drop the docs in the README as it is out of date.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      275b4832
    • Simon Glass's avatar
      fdt: Drop #ifdefs with MULTI_DTB_FIT · b4b6daf3
      Simon Glass authored and Tom Rini's avatar Tom Rini committed
      
      Refactor the code to drop the #ifdefs for this feature.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      b4b6daf3
    • Simon Glass's avatar
      fdt: Drop CONFIG_BINMAN_STANDALONE_FDT · 8e076812
      Simon Glass authored and Tom Rini's avatar Tom Rini committed
      
      This was added as a hack to work around not having an in-tree devicetree.
      Now that this is fixed it is not needed.
      
      Drop it.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      8e076812
    • Simon Glass's avatar
      fdt: Make OF_BOARD a bool option · 836eac7c
      Simon Glass authored and Tom Rini's avatar Tom Rini committed
      
      This should not be a separate option from OF_SEPARATE. It is a run-time
      option to override the devicetree, even if present.
      
      Move the option out of the choice.
      
      Disable BINMAN_FDT for a few boards which don't actually use it.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      836eac7c
  7. Oct 27, 2021
    • Ilias Apalodimas's avatar
      sandbox: Remove OF_HOSTFILE · e7fb7896
      Ilias Apalodimas authored and Tom Rini's avatar Tom Rini committed
      
      OF_HOSTFILE is used on sandbox configs only.  Although it's pretty
      unique and not causing any confusions,  we are better of having simpler
      config options for the DTB.
      
      So let's replace that with the existing OF_BOARD.  U-Boot would then
      have only three config options for the DTB origin.
      - OF_SEPARATE, build separately from U-Boot
      - OF_BOARD, board specific way of providing the DTB
      - OF_EMBED embedded in the u-boot binary(should not be used in production
      
      Signed-off-by: default avatarIlias Apalodimas <ilias.apalodimas@linaro.org>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      e7fb7896
  8. Oct 19, 2021
    • Simon Glass's avatar
      Makefile: Only build dtc if needed · 93b19653
      Simon Glass authored and Tom Rini's avatar Tom Rini committed
      
      At present U-Boot always builds dtc if CONFIG_OF_CONTROL is defined, even
      when DTC is provided. The built dtc is not actually used, so this is a
      waste of time.
      
      Update the Makefile logic to build dtc only if one is not provided to the
      build with the DTC variable. Add documentation to explain this.
      
      This saves about 3.5 seconds of elapsed time on a clean build of
      sandbox_spl for me.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      93b19653
  9. Oct 18, 2021
  10. Sep 25, 2021
    • Simon Glass's avatar
      treewide: Simply conditions with the new OF_REAL · 414cc151
      Simon Glass authored
      
      Use this new Kconfig to simplify the compilation conditions where
      appropriate.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      414cc151
    • Simon Glass's avatar
      fdt: Create a new OF_REAL Kconfig · eaad01a3
      Simon Glass authored
      
      The condition to indicate whether there is a runtime devicetree available
      is OF_CONTROL && !OF_PLATDATA. This is a bit unweidly and is repeated in
      a lot of places.
      
      Add a new OF_REAL Kconfig which provides this information directly.
      
      Note: This is similar in effect to LIBFDT. We might consider dropping
      LIBFDT and using this instead, but this is left for now as we also have
      OF_LIBFDT_OVERLAY which it would not make sense to change.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      eaad01a3
  11. May 19, 2021
  12. Mar 26, 2021
    • Simon Glass's avatar
      dm: core: Create a struct for device runtime info · ab933d80
      Simon Glass authored
      
      At present when driver model needs to change a device it simply updates
      the struct udevice structure. But with of-platdata-inst most of the fields
      are not modified at runtime. In fact, typically only the flags need to
      change.
      
      For systems running SPL from read-only memory it is convenient to separate
      out the runtime information, so that the devices don't need to be copied
      before being used.
      
      Create a new udevice_rt table, similar to the existing driver_rt. For now
      it just holds the flags, although they are not used in this patch.
      
      Add a new Kconfig for the driver_rt data, since this is not needed when
      of-platdata-inst is used.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      ab933d80
    • Simon Glass's avatar
      dm: core: Add an option to support SPL in read-only memory · 95a5825f
      Simon Glass authored
      
      Some systems (e.g. x86 APL) run SPL from read-only memory. The device
      instances created by dtoc are therefore not writeable. To make things work
      we would need to copy the devices to read/write memory.
      
      To avoid this, add an option to use a separate runtime struct for devices,
      just as is done for drivers. This can be used to hold information that
      changes at runtime, avoiding the need for a copy.
      
      Also add a Kconfig option for read-only SPL, which selects this feature.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      95a5825f
  13. Mar 22, 2021
  14. Mar 04, 2021
  15. Jan 16, 2021
    • Florian Klink's avatar
      dts: Log name of expected .dtb file · 1d55eb15
      Florian Klink authored and Tom Rini's avatar Tom Rini committed
      
      Make it more obvious what .dts file was expected by the build system.
      
      When adding support for a new board, I kept getting this error message,
      assuming I passed a wrong DEVICE_TREE parameter.
      
      However, what was really the mistake was that the entry in
      `arch/arm/dts/Makefile` was missing, and u-boot didn't like not being
      able to find the .dtb file that should have been produced.
      
      Simply logging the expected .dtb file name should make it easier to spot
      such mistakes.
      
      Signed-off-by: default avatarFlorian Klink <flokli@flokli.de>
      1d55eb15
  16. Jan 05, 2021
    • Simon Glass's avatar
      dm: Rename U_BOOT_DEVICE() to U_BOOT_DRVINFO() · 20e442ab
      Simon Glass authored
      
      The current macro is a misnomer since it does not declare a device
      directly. Instead, it declares driver_info record which U-Boot uses at
      runtime to create a device.
      
      The distinction seems somewhat minor most of the time, but is becomes
      quite confusing when we actually want to declare a device, with
      of-platdata. We are left trying to distinguish between a device which
      isn't actually device, and a device that is (perhaps an 'instance'?)
      
      It seems better to rename this macro to describe what it actually is. The
      macros is not widely used, since boards should use devicetree to declare
      devices.
      
      Rename it to U_BOOT_DRVINFO(), which indicates clearly that this is
      declaring a new driver_info record, not a device.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      20e442ab
    • Simon Glass's avatar
      Makefile: Tidy up SPL dtb production · c7674fcb
      Simon Glass authored
      
      Use the SPL_NAME variable to simplify the rules. Drop the SPL targets
      clean-files since the SPL and TPL dts/ directories are removed by
      existing rules. Move the SPL rules into a new spl_dtbs to avoid the
      complicated $(if) construct.
      
      Also drop unused pieces from the 'targets' variable.
      
      With this, SPL and TPL have separate dtbs which respect the various
      u-boot,dm-spl / u-boot,dm-tpl tags.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      c7674fcb
    • Simon Glass's avatar
      Makefile: Build SPL dtbs in the spl/ directory · de3e372a
      Simon Glass authored
      
      Rather than putting these in the top-level dts/ directory (which is
      intended for U-Boot proper), put them in the correct subdirectory for
      SPL (either spl/ or tpl/). This is where other SPL targets are kept,
      so this is more consistent.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      de3e372a
    • Simon Glass's avatar
      Makefile: Build a separate .dtb for TPL · 53db2eec
      Simon Glass authored
      
      At present both SPL and TPL use the same devicetree binary. While there
      is logic to run fdtgrep separately on each one, it does not actually
      happen.
      
      Add a new TPL rule and use that instead. Make this rule conditional on
      there actually being a TPL. Do the same for SPL for consistency.
      
      Note that the SPL and TPL dtbs are build by a Makefule rule used for
      U-Boot proper. This is the 'dtbs' target in dts/Makefile. So the check
      for CONFIG_TPL_BUILD in cmd_fdtgrep never actually works at present.
      
      We don't support CONFIG_OF_EMBED for TPL at present.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      53db2eec
  17. Oct 29, 2020
    • Simon Glass's avatar
      dm: Support parent devices with of-platdata · e41651ff
      Simon Glass authored
      
      At present of-platdata does not provide parent information. But this is
      useful for I2C devices, for example, since it allows them to determine
      which bus they are on.
      
      Add support for setting the parent correctly, by storing the parent
      driver_info index in dtoc and reading this in lists_bind_drivers(). This
      needs multiple passes since we must process children after their parents
      already have been bound.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      e41651ff
  18. Oct 09, 2020
    • Simon Glass's avatar
      Kconfig: Create a new tools menu · 1fa057be
      Simon Glass authored and Tom Rini's avatar Tom Rini committed
      
      At present MKIMAGE_DTC_PATH is in the devicetree menu but not within
      'devicetree control' since it does not relate to that. As a result it
      shows up in the top menu.
      
      It actually relates to the mkimage tool, so create a new tools menu for it
      and move it there.
      
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      1fa057be
  19. Jan 28, 2020
  20. Jan 16, 2020
  21. Jan 07, 2020
  22. Oct 31, 2019
  23. Oct 30, 2019
  24. Apr 12, 2019
  25. Apr 09, 2019
  26. Mar 22, 2019
    • Masahiro Yamada's avatar
      Revert "Ensure device tree DTS is compiled" · a3444bd0
      Masahiro Yamada authored and Tom Rini's avatar Tom Rini committed
      
      This reverts commit 27cb7300.
      
      I am not sure if I correctly understood the log of commit 27cb7300
      ("Ensure device tree DTS is compiled"), but the code-diff looks like
      it was trying to solve the missed re-compilation when .dts was modified.
      
      Recently, commit 2737dfe0 ("kbuild: make arch-dtbs target PHONY")
      fixed the issue in a more correct and more complete way.
      
      Anyway, since the former commit, we see a clumsy log like this:
      
        make[2]: 'arch/sandbox/dts/sandbox.dtb' is up to date
      
      Another problem is, it created multiple paths to descend into
      arch/*/dts/, causing a race in parallel building.
      
      So, let's revert it.
      
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      a3444bd0
  27. Feb 28, 2019
  28. Feb 09, 2019
  29. Jan 15, 2019
    • Masahiro Yamada's avatar
      kbuild: add .SECONDARY special target to scripts/Kbuild.include · c16b137e
      Masahiro Yamada authored and Tom Rini's avatar Tom Rini committed
      
      Based on the following Linux commits:
      
       - 54a702f70589 ("kbuild: mark $(targets) as .SECONDARY and remove
         .PRECIOUS markers")
      
       - 8e9b61b293d9 ("kbuild: move .SECONDARY special target to
         Kbuild.include")
      
      GNU Make automatically deletes intermediate files that are updated
      in a chain of pattern rules.
      
      Example 1) %.dtb.o <- %.dtb.S <- %.dtb <- %.dts
      Example 2) %.o <- %.c <- %.c_shipped
      
      A couple of makefiles mark such targets as .PRECIOUS to prevent Make
      from deleting them, but the correct way is to use .SECONDARY.
      
        .SECONDARY
          Prerequisites of this special target are treated as intermediate
          files but are never automatically deleted.
      
        .PRECIOUS
          When make is interrupted during execution, it may delete the target
          file it is updating if the file was modified since make started.
          If you mark the file as precious, make will never delete the file
          if interrupted.
      
      Both can avoid deletion of intermediate files, but the difference is
      the behavior when Make is interrupted; .SECONDARY deletes the target,
      but .PRECIOUS does not.
      
      The use of .PRECIOUS is relatively rare since we do not want to keep
      partially constructed (possibly corrupted) targets.
      
      .SECONDARY with no prerequisites causes all targets to be treated as
      secondary. This agrees the policy of Kbuild.
      
      scripts/Kbuild.include seems a suitable place to add it because it is
      included from almost all sub-makes.
      
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      c16b137e
Loading