<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/Makefile, branch master</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>spl: Make UFS available for SPL builds</title>
<updated>2026-03-12T08:30:44+00:00</updated>
<author>
<name>Alexey Charkov</name>
<email>alchark@gmail.com</email>
</author>
<published>2026-01-20T18:09:02+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c664b4d5f30a704003b97823a5ad6361cb16fbe8'/>
<id>c664b4d5f30a704003b97823a5ad6361cb16fbe8</id>
<content type='text'>
Add minimal infrastructure to build SPL images with support for UFS
storage devices. This also pulls in SCSI support and charset functions,
which are dependencies of the UFS code.

With this, only a fixed offset is supported for loading the next image,
which should be specified in CONFIG_SPL_UFS_RAW_U_BOOT_SECTOR as the
number of 4096-byte sectors into the UFS block device.

Reviewed-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Signed-off-by: Alexey Charkov &lt;alchark@gmail.com&gt;
Link: https://patch.msgid.link/20260120-rk3576-ufs-v5-1-0edb61b301b7@gmail.com
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add minimal infrastructure to build SPL images with support for UFS
storage devices. This also pulls in SCSI support and charset functions,
which are dependencies of the UFS code.

With this, only a fixed offset is supported for loading the next image,
which should be specified in CONFIG_SPL_UFS_RAW_U_BOOT_SECTOR as the
number of 4096-byte sectors into the UFS block device.

Reviewed-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Signed-off-by: Alexey Charkov &lt;alchark@gmail.com&gt;
Link: https://patch.msgid.link/20260120-rk3576-ufs-v5-1-0edb61b301b7@gmail.com
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Introduce the Generic System Interconnect Subsystem</title>
<updated>2025-11-20T08:17:58+00:00</updated>
<author>
<name>Neil Armstrong</name>
<email>neil.armstrong@linaro.org</email>
</author>
<published>2025-11-20T08:12:52+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=60a99d5ca374c83c0118f2634a7fcf4cc707b965'/>
<id>60a99d5ca374c83c0118f2634a7fcf4cc707b965</id>
<content type='text'>
Let's introduce the Generic System Interconnect subsystem based on
the counterpart Linux framework which is used to vote for bandwidth
across multiple SoC busses.

Documentation for the Linux Generic System Interconnect Subsystem can
be found at [1].

Each bus endpoints are materialised as "nodes" which are linked together,
and the DT will specify a pair of nodes to enable and set a bandwidth
on the route between those endpoints.

The hardware resources that provide those nodes and provides the way
to vote for the bandwidth are called "providers".

The Interconnect uclass code is heavily based on the Linux one, with
some small differences:
- nodes are allocated as udevices instead of Linux idr_alloc()
- tag management is minimal, only normal xlate is supported
- getting nodes states at probe is not implemented
- providers are probed on demand while the nodes links are traversed
- nodes are populated on bind
- id management is simplified, static IDs and dynamics IDs can be used
- identical consume API as Linux, only implementation differs

Fully tested with associated DM test suite.

[1] https://docs.kernel.org/driver-api/interconnect.html

Link: https://patch.msgid.link/20251120-topic-interconnect-next-v5-1-e8a82720da5d@linaro.org
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Let's introduce the Generic System Interconnect subsystem based on
the counterpart Linux framework which is used to vote for bandwidth
across multiple SoC busses.

Documentation for the Linux Generic System Interconnect Subsystem can
be found at [1].

Each bus endpoints are materialised as "nodes" which are linked together,
and the DT will specify a pair of nodes to enable and set a bandwidth
on the route between those endpoints.

The hardware resources that provide those nodes and provides the way
to vote for the bandwidth are called "providers".

The Interconnect uclass code is heavily based on the Linux one, with
some small differences:
- nodes are allocated as udevices instead of Linux idr_alloc()
- tag management is minimal, only normal xlate is supported
- getting nodes states at probe is not implemented
- providers are probed on demand while the nodes links are traversed
- nodes are populated on bind
- id management is simplified, static IDs and dynamics IDs can be used
- identical consume API as Linux, only implementation differs

Fully tested with associated DM test suite.

[1] https://docs.kernel.org/driver-api/interconnect.html

Link: https://patch.msgid.link/20251120-topic-interconnect-next-v5-1-e8a82720da5d@linaro.org
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spl: Add support for Device Firmware Upgrade (DFU) over PCIe</title>
<updated>2025-11-06T09:17:05+00:00</updated>
<author>
<name>Hrushikesh Salunke</name>
<email>h-salunke@ti.com</email>
</author>
<published>2025-10-23T08:09:22+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=cde77583cf0b54dd572a38acd159ded7dd5e3e86'/>
<id>cde77583cf0b54dd572a38acd159ded7dd5e3e86</id>
<content type='text'>
Introduces support for Device Firmware Upgrade (DFU) over PCIe in
U-Boot. Traditionally, the DFU protocol is used over USB, where a
device enters DFU mode and allows a host to upload firmware or binary
images directly via the USB interface. This is a widely adopted and
convenient method for updating firmware.

In the context of Texas Instruments (TI) SoCs, PCIe can be used as a
boot interface in a manner that differs from the conventional
"PCIe Boot" process, which typically refers to booting an OS or
firmware image from an NVMe SSD or other PCIe-attached storage devices.
Instead, TI SoCs can be configured as a PCIe Endpoint, allowing a
connected PCIe Root Complex (host) to transfer images directly into the
device’s memory over the PCIe bus for boot purposes. This mechanism is
analogous to DFU over USB, but leverages the high-speed PCIe link and
does not depend on traditional storage devices.

By extending the DFU framework in U-Boot to support PCIe, it will be
possible to flash images over PCIe. While this implementation is
motivated by TI SoC use cases, the framework is generic and can be
adopted by everyone for platforms that support PCIe Endpoint mode.
Platforms with hardware support for PCIe-based memory loading can use
this to implement PCIe as a boot mode, as well as to enable flashing
and recovery scenarios similar to DFU over USB.

In summary, enable support for:
- DFU-style flashing of firmware/images over PCIe, analogous to existing
USB DFU workflows
- PCIe as a boot mode where a host can load images directly into device
memory using DFU over PCIe

Signed-off-by: Hrushikesh Salunke &lt;h-salunke@ti.com&gt;
Reviewed-by: Mattijs Korpershoek &lt;mkorpershoek@kernel.org&gt;
Link: https://lore.kernel.org/r/20251023080922.3527052-1-h-salunke@ti.com
Signed-off-by: Mattijs Korpershoek &lt;mkorpershoek@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Introduces support for Device Firmware Upgrade (DFU) over PCIe in
U-Boot. Traditionally, the DFU protocol is used over USB, where a
device enters DFU mode and allows a host to upload firmware or binary
images directly via the USB interface. This is a widely adopted and
convenient method for updating firmware.

In the context of Texas Instruments (TI) SoCs, PCIe can be used as a
boot interface in a manner that differs from the conventional
"PCIe Boot" process, which typically refers to booting an OS or
firmware image from an NVMe SSD or other PCIe-attached storage devices.
Instead, TI SoCs can be configured as a PCIe Endpoint, allowing a
connected PCIe Root Complex (host) to transfer images directly into the
device’s memory over the PCIe bus for boot purposes. This mechanism is
analogous to DFU over USB, but leverages the high-speed PCIe link and
does not depend on traditional storage devices.

By extending the DFU framework in U-Boot to support PCIe, it will be
possible to flash images over PCIe. While this implementation is
motivated by TI SoC use cases, the framework is generic and can be
adopted by everyone for platforms that support PCIe Endpoint mode.
Platforms with hardware support for PCIe-based memory loading can use
this to implement PCIe as a boot mode, as well as to enable flashing
and recovery scenarios similar to DFU over USB.

In summary, enable support for:
- DFU-style flashing of firmware/images over PCIe, analogous to existing
USB DFU workflows
- PCIe as a boot mode where a host can load images directly into device
memory using DFU over PCIe

Signed-off-by: Hrushikesh Salunke &lt;h-salunke@ti.com&gt;
Reviewed-by: Mattijs Korpershoek &lt;mkorpershoek@kernel.org&gt;
Link: https://lore.kernel.org/r/20251023080922.3527052-1-h-salunke@ti.com
Signed-off-by: Mattijs Korpershoek &lt;mkorpershoek@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers: Enabled Kconfig and Makefile for i3c support</title>
<updated>2025-08-06T06:38:26+00:00</updated>
<author>
<name>Dinesh Maniyam</name>
<email>dinesh.maniyam@altera.com</email>
</author>
<published>2025-08-06T04:32:27+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a19a6e7124a4225220e1d53d021669332ef81628'/>
<id>a19a6e7124a4225220e1d53d021669332ef81628</id>
<content type='text'>
Add new i3c driver to U-Boot drivers.

Signed-off-by: Dinesh Maniyam &lt;dinesh.maniyam@altera.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add new i3c driver to U-Boot drivers.

Signed-off-by: Dinesh Maniyam &lt;dinesh.maniyam@altera.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Kbuild: Always use $(PHASE_)</title>
<updated>2025-04-11T18:16:44+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2025-04-01T22:55:23+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=302b41d5397e9f821d360a74335e8821d4513970'/>
<id>302b41d5397e9f821d360a74335e8821d4513970</id>
<content type='text'>
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mux: Makefile: Add config for mux drivers</title>
<updated>2024-12-14T15:34:16+00:00</updated>
<author>
<name>Anurag Dutta</name>
<email>a-dutta@ti.com</email>
</author>
<published>2024-11-29T11:31:29+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f0558f3a89fe0fa900b162ae2758772e37f72739'/>
<id>f0558f3a89fe0fa900b162ae2758772e37f72739</id>
<content type='text'>
Add config required to build mmio-mux driver and dependencies.

Signed-off-by: Anurag Dutta &lt;a-dutta@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add config required to build mmio-mux driver and dependencies.

Signed-off-by: Anurag Dutta &lt;a-dutta@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>global: Rename SPL_TPL_ to PHASE_</title>
<updated>2024-10-11T17:44:48+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2024-09-30T01:49:54+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=5c10c8badf8233cac1593cd2bef4d0379ac9e5bd'/>
<id>5c10c8badf8233cac1593cd2bef4d0379ac9e5bd</id>
<content type='text'>
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.

Update the comment in bootstage to refer to this symbol, instead of
SPL_

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.

Update the comment in bootstage to refer to this symbol, instead of
SPL_

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>global: Rename SPL_ to XPL_</title>
<updated>2024-10-11T17:44:48+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2024-09-30T01:49:53+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c46760d5967d12b6f7d37402878d1607a98b2b84'/>
<id>c46760d5967d12b6f7d37402878d1607a98b2b84</id>
<content type='text'>
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is
no-longer set.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is
no-longer set.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers: Use CONFIG_XPL_BUILD instead of CONFIG_SPL_BUILD</title>
<updated>2024-10-11T17:44:48+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2024-09-30T01:49:48+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=371dc068bbf50c6ed6146c04ec83b644bcc79249'/>
<id>371dc068bbf50c6ed6146c04ec83b644bcc79249</id>
<content type='text'>
Use the new symbol to refer to any 'SPL' build, including TPL and VPL

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use the new symbol to refer to any 'SPL' build, including TPL and VPL

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dm: adc: Add SPL_ADC Kconfig symbol for use of ADC in SPL</title>
<updated>2024-08-09T10:35:23+00:00</updated>
<author>
<name>Jonas Karlman</name>
<email>jonas@kwiboo.se</email>
</author>
<published>2024-08-02T22:12:22+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=232af1e58a977f3857074d3aba3709c860bd8058'/>
<id>232af1e58a977f3857074d3aba3709c860bd8058</id>
<content type='text'>
What model of Radxa ZERO 3W/3E board can be identified using ADC at
runtime, add a Kconfig symbol to allow use of ADC in SPL.

This will be used to identify board model in SPL to allow loading
correct FIT configuration and FDT for U-Boot proper at SPL phase.

Signed-off-by: Jonas Karlman &lt;jonas@kwiboo.se&gt;
Reviewed-by: Kever Yang &lt;kever.yang@rock-chips.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
What model of Radxa ZERO 3W/3E board can be identified using ADC at
runtime, add a Kconfig symbol to allow use of ADC in SPL.

This will be used to identify board model in SPL to allow loading
correct FIT configuration and FDT for U-Boot proper at SPL phase.

Signed-off-by: Jonas Karlman &lt;jonas@kwiboo.se&gt;
Reviewed-by: Kever Yang &lt;kever.yang@rock-chips.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
