1. 06 Sep, 2022 4 commits
  2. 05 Sep, 2022 1 commit
    • Jessica Clarke's avatar
      riscv: dts: Sync important Unmatched pmic and qspi0 changes from Linux · b236a66a
      Jessica Clarke authored
      This adds the onkey, RTC and watchdog children to the DA9063 PMIC node,
      fixes the compatible for qspi0's flash node to match the official DT
      schema (it being an is25wp256 is discoverable, hence jedec,spi-nor is
      the only compatible that should be present) and exposes the card detect
      Note that the device trees still diverge in some places (including
      important things like the PCIe controller's clock name) and should be
      cleaned up so that a common device tree is used in both projects rather
      than having different bindings. This patch does not attempt to do that,
      merely expose important functionality present in Linux's that is not in
      U-Boot's so that it can be used without the OS providing its own bundled
      Signed-off-by: Jessica Clarke's avatarJessica Clarke <jrtc27@jrtc27.com>
      Reviewed-by: default avatarLeo Yu-Chi Liang <ycliang@andestech.com>
  3. 03 Sep, 2022 18 commits
  4. 02 Sep, 2022 5 commits
    • Tom Rini's avatar
      Merge tag 'efi-2022-10-rc4' of https://source.denx.de/u-boot/custodians/u-boot-efi · 67fe8cc0
      Tom Rini authored
      Pull request for efi-2022-10-rc4
      * add a page on sending patches
      * bindings for FWU Metadata mtd storage
      * fpio status output fields description
      * ensure all block devices are probed
    • qianfan Zhao's avatar
      drivers: usb: fastboot: Fix full-speed usb descriptor · 2522bd3e
      qianfan Zhao authored and Marek Vasut's avatar Marek Vasut committed
      The host will report such error message if the fastboot device work in
      full-speed mode: "Duplicate descriptor for config 1 interface 0
      altsetting 0, skipping"
      Fastboot device ack both full and high speed interface descriptors when
      work in full-speed mode, that's will cause this issue.
      Fix it.
      Signed-off-by: default avatarqianfan Zhao <qianfanguijin@163.com>
      Reviewed-by: default avatarJohn Keeping <john@metanate.com>
    • Geert Uytterhoeven's avatar
      renesas: Fix RPC-IF compatible values · 68083b89
      Geert Uytterhoeven authored
      The compatible values used for device nodes representing Renesas Reduced
      Pin Count Interfaces were based on preliminary versions of the Device
      Tree Bindings.
      Correct them in both DTSi files and drivers, to match the final DT
      Note that there are no DT bindings for RPC-IF on RZ/A1 yet, hence the
      most logical SoC-specific value is used, without specifying a
      family-specific value.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
    • Geert Uytterhoeven's avatar
      ARM: renesas: Propagate RPC-IF enablement to subsequent software · 33aca1c8
      Geert Uytterhoeven authored
      As the Renesas Reduced Pin Count Interface may be locked by TF-A, it is
      disabled by default[1].  When unlocked, TF-A passes a DT fragment to
      enable it, which is applied to the U-Boot DT[2].
      Unlike the memory layout, the RPC-IF enablement is not propagated to
      subsequent software.  Hence e.g. Linux cannot know if the RPC-IF is
      locked or not, and will lock-up when trying to access the RPC-IF when
      Fix this by checking if the RPC-IF is enabled in the TF-A DT fragment, and
      setting the status of the RPC-IF device node in the target DT, if
      present, to "okay".  Do this only when a "flash" subnode is found, to
      avoid errors in subsequent software when the RPC-IF is not intended to
      be used.
      Note that this requires the status of the RPC-IF node to be set to
      "disabled" in the target DT, just like in the U-Boot DT.
      [1] commit 3d5f45c9 ("ARM: dts: rmobile: Disable RPC HF by
      [2] commit 361377db ("ARM: rmobile: Merge ...
    • Geert Uytterhoeven's avatar
      ARM: dts: rmobile: Fix RPC-IF device node names · e17205d0
      Geert Uytterhoeven authored
      According to the Generic Names Recommendation in the Devicetree
      Specification Release v0.3, and the DT Bindings for the Renesas Reduced
      Pin Count Interface, the node name for a Renesas RPC-IF device should be
      "spi".  Especially on R-Car Gen3 and RZ/G2, the node name matters, as
      the node is enabled by passing a DT fragment from TF-A to U-Boot, and
      from U-Boot to subsequent software.
      Fix this by renaming the device nodes from "rpc" to "spi".
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
  5. 01 Sep, 2022 6 commits
    • Sughosh Ganu's avatar
      dt/bindings: Add bindings for FWU Metadata mtd storage · 2ac4c98a
      Sughosh Ganu authored
      Add bindings needed for accessing the FWU metadata regions.
      These include the compatible string which point to the access
      method, the actual device which stores the FWU metadata and
      the offsets for both metadata regions.
      The current patch adds basic bindings needed for accessing the
      metadata structure on non-GPT mtd regions.
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu@linaro.org>
      Signed-off-by: default avatarJassi Brar <jaswinder.singh@linaro.org>
    • Tom Rini's avatar
      github: Update PR template for new "Patches" content · 0d8b7f9a
      Tom Rini authored
      The old "Patches" wiki page is not available anymore. Now that the
      content has been integrated with the submitting_patches document,
      reference that instead.
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
    • Tom Rini's avatar
      doc: process, sending_patches: Update and correct the old "Patches" content · 286ed78a
      Tom Rini authored
      - Use gender-neutral language to refer to the user, consistently.
      - Reference the checkpatch document.
      - Move the section on commit message tags to the process document and
        reference this in sending_patches.rst.
        - Reword the custodian workflow process section to refer to this new
          section, integrate some of the wording from there in this new section.
      - Update the comment about GPLv2 applying to August 2022, to be clear
        this still is correct.
      - Reword the section about MAKEALL to talk about local build testing and
        link to the CI document.
      - Reference the system_configuration document for the note about
        modifying existing code.
      - Reword the patchwork flow section.
      Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
    • Tom Rini's avatar
      doc: sending_patches.rst: Incorporate the old "Patches" wiki content · 6349b186
      Tom Rini authored
      Import as-is much of the old "Patches" wiki page to the current
      sending_patches.rst file. This means we need to move patman to being
      included in the higher level ToC and add a reference for "Custodians" in
      the process document. A very minimal amount of content changing and
      rewording is done here as part of the import, in order to make the
      conversion easier.
      Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
    • Patrice Chotard's avatar
      doc: Add gpio status output fields description · 00cc81f4
      Patrice Chotard authored
      Add gpio status output fields description and one output example.
      Signed-off-by: Patrice Chotard's avatarPatrice Chotard <patrice.chotard@foss.st.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Tweak the formatting.
      Signed-off-by: default avatarHeinrich Schuchardt <heinrich.schuchardt@canonical.com>
    • Heinrich Schuchardt's avatar
      efi_loader: ensure all block devices are probed · d5391bf0
      Heinrich Schuchardt authored
      Only probed block devices are available in the UEFI sub-system. Multiple
      block devices may be involved in the boot process. So we have to make sure
      that all block devices are probed. Another reason is that we store UEFI
      variables on the ESP which may be on any block device.
      On the sandbox before the patch:
      => efidebug devices
      No EFI system partition
      Device           Device Path
      ================ ====================
      000000001b027c70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
      000055d078bc1ae0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Uart(0,0,D,D)
      000000001b22e0b0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(020011223344,1)
      After the patch:
      => efidebug devices
      No EFI system partition
      Device           Device Path
      ================ ====================
      000000001b027c70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
      000055bdac8ddae0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Uart(0,0,D,D)
      000000001b230920 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(2)/SD(0)
      000000001b233ac0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(1)
      000000001b233b80 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(1)/HD(1,GPT,d0a914ee-a71c-fc1e-73f0-7e302b0e6c20,0x30,0x1)
      000000001b234110 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(1)/HD(2,GPT,9330a0ea-8aff-f67a-294c-fa05d60896c3,0x31,0x1)
      000000001b22f0e0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(2)
      000000001b238df0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/MAC(020011223344,1)
      Fixes: a9bf024b
       ("efi_loader: disk: a helper function to create efi_disk objects from udevice")
      Signed-off-by: default avatarHeinrich Schuchardt <heinrich.schuchardt@canonical.com>
  6. 31 Aug, 2022 6 commits