From: Dave Klotz <DaveWK225@protonmail.com>
To: u-boot@lists.u-boot-project.org
Cc: Huan Zhou <pericycle.cc@gmail.com>,
Eric Chung <eric.chung@riscstar.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Yixun Lan <dlan@kernel.org>, Tom Rini <trini@konsulko.com>,
u-boot-spacemit@groups.io
Subject: [PATCH 0/9] pci: spacemit: fixes for the K1 PCIe host driver
Date: Fri, 02 Oct 2026 21:30:32 +0000 [thread overview]
Message-ID: <cover.1790975598.git.DaveWK225@protonmail.com> (raw)
Fixes for "pci: spacemit: add DesignWare PCIe host controller driver",
following the Linux driver and the bring-up order that works on the
boards I have:
- power the slot from the root port's vpcie3v3-supply (the vendor
k1x,pwr_on property is not in any upstream device tree);
- keep the PHY interface in reset until LTSSM enable, and soft-reset
the controller before bring-up so a warm reset starts clean;
- check clock, reset and iATU setup errors;
- report link up from the SMLH/RDLH bits in the link window;
- leave the link speed alone unless max-link-speed is set, instead of
writing Gen1 into LNKCAP and LNKCTL2, so the OS can still train the
link at its full speed;
- drop ASPM L1 from LNKCAP as Linux does for NVMe drives;
- set the link width from num-lanes;
- keep the probe successful when the link is down (an empty slot), and
answer config cycles behind a down link with all ones.
Tested on an OrangePi RV2: an NVMe drive on port B is found and
FreeBSD boots from it by EFI; FreeBSD then retrains the link to x2 at
5 GT/s (with the Gen1 cap in place it could not). Port C, empty, reports
"Link down" and nothing hangs. Under U-Boot this drive still trains x1
at 2.5 GT/s.
Two observations about the RV2 device tree, not addressed here:
pcie1_3_cfg and pcie2_4_cfg mux CLKREQ#, and with CLKREQ# muxed the
controller gates its DBI clock whenever the endpoint leaves CLKREQ# high,
so the next DBI access hangs; I run the board with PERST# only in those
groups. And port B needs num-lanes = <2>, which the tree does not set.
Dave Klotz (9):
pci: spacemit: power the slot from vpcie3v3-supply
pci: spacemit: hold the PHY interface in reset until link start
pci: spacemit: soft reset the controller before bring-up
pci: spacemit: check clock, reset and iATU setup results
pci: spacemit: report link up from the link status register
pci: spacemit: do not force the link to 2.5 GT/s
pci: spacemit: do not advertise ASPM L1
pci: spacemit: set the link width from num-lanes
pci: spacemit: do not fail the probe when the link is down
drivers/pci/pcie_dw_spacemit.c | 231 +++++++++++++++++++++++----------
drivers/pci/pcie_dw_spacemit.h | 12 --
2 files changed, 162 insertions(+), 81 deletions(-)
base-commit: a000f2af240eaa996cec92f8d44bad96fdf3f898
--
2.55.0
WARNING: multiple messages have this Message-ID (diff)
From: Dave Klotz <DaveWK225@protonmail.com>
To: u-boot@lists.u-boot-project.org
Cc: Huan Zhou <pericycle.cc@gmail.com>,
Eric Chung <eric.chung@riscstar.com>, Yixun Lan <dlan@kernel.org>,
Tom Rini <trini@konsulko.com>, Guodong Xu <guodong@riscstar.com>,
Raymond Mao <raymond.mao@riscstar.com>,
u-boot-spacemit@groups.io
Subject: [PATCH 0/2] spacemit: k1: SPL robustness for boards without a PMIC or SPI NOR
Date: Fri, 02 Oct 2026 21:31:33 +0000 [thread overview]
Message-ID: <cover.1790975598.git.DaveWK225@protonmail.com> (raw)
Message-ID: <20261002213133.GTPAJWy-qdnCacf-4wbD3uPXAWd8ZgASBkeU7uocbsw@z> (raw)
Two small SPL changes for K1 boards that do not look like the BPI-F3
and MusePi Pro:
1. pmic_init() and nor_early_init() panic when the device tree gives
the SPL no PMIC or no SPI controller. A board that boots from eMMC or
microSD with its rails already up (the OrangePi R2S and RV2) stops
there. Log it and carry on.
2. Provide board_boot_order(): the device the BootROM booted from, as
detected now, then the other MMC controller and SPI NOR, so an
unexpected BootROM path still finds U-Boot.
Tested on an OrangePi RV2 booting from microSD (no SPI controller in
the SPL): "No SPI controller", then the SPL loads U-Boot from the card
through the detected MMC2. The fallback order was not exercised, since
the detection was right.
Dave Klotz (2):
spacemit: k1: do not require a PMIC or an SPI controller in SPL
spacemit: k1: fall back to the other boot devices in SPL
board/spacemit/k1/spl.c | 48 +++++++++++++++++++++++++++++++++++++----
1 file changed, 44 insertions(+), 4 deletions(-)
base-commit: a000f2af240eaa996cec92f8d44bad96fdf3f898
--
2.55.0
next reply other threads:[~2026-10-02 21:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 21:30 Dave Klotz [this message]
2026-10-02 21:31 ` [PATCH 0/2] spacemit: k1: SPL robustness for boards without a PMIC or SPI NOR Dave Klotz
2026-10-02 21:30 ` [PATCH 1/9] pci: spacemit: power the slot from vpcie3v3-supply Dave Klotz
2026-10-02 21:30 ` [PATCH 2/9] pci: spacemit: hold the PHY interface in reset until link start Dave Klotz
2026-10-02 21:30 ` [PATCH 3/9] pci: spacemit: soft reset the controller before bring-up Dave Klotz
2026-10-02 21:30 ` [PATCH 4/9] pci: spacemit: check clock, reset and iATU setup results Dave Klotz
2026-10-02 21:31 ` [PATCH 5/9] pci: spacemit: report link up from the link status register Dave Klotz
2026-10-02 21:31 ` [PATCH 6/9] pci: spacemit: do not force the link to 2.5 GT/s Dave Klotz
2026-10-02 21:31 ` [PATCH 7/9] pci: spacemit: do not advertise ASPM L1 Dave Klotz
2026-10-02 21:31 ` [PATCH 8/9] pci: spacemit: set the link width from num-lanes Dave Klotz
2026-10-02 21:31 ` [PATCH 9/9] pci: spacemit: do not fail the probe when the link is down Dave Klotz
2026-10-02 21:31 ` [PATCH 1/2] spacemit: k1: do not require a PMIC or an SPI controller in SPL Dave Klotz
2026-10-02 21:31 ` [PATCH 2/2] spacemit: k1: fall back to the other boot devices " Dave Klotz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1790975598.git.DaveWK225@protonmail.com \
--to=davewk225@protonmail.com \
--cc=dlan@kernel.org \
--cc=eric.chung@riscstar.com \
--cc=neil.armstrong@linaro.org \
--cc=pericycle.cc@gmail.com \
--cc=trini@konsulko.com \
--cc=u-boot-spacemit@groups.io \
--cc=u-boot@lists.u-boot-project.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.