<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/test/dm, branch v2025.01</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>dm: Add dm_remove_devices_active() for ordered device removal</title>
<updated>2024-11-24T21:41:28+00:00</updated>
<author>
<name>Janne Grunau</name>
<email>j@jannau.net</email>
</author>
<published>2024-11-23T21:44:05+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=dabaa4ae32062cb3f3d995e5c63e6cef54ad079b'/>
<id>dabaa4ae32062cb3f3d995e5c63e6cef54ad079b</id>
<content type='text'>
This replaces dm_remove_devices_flags() calls in all boot
implementations to ensure non vital devices are consistently removed
first. All boot implementation except arch/arm/lib/bootm.c currently
just call dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL). This can result
in crashes when dependencies between devices exists. The driver model's
design document describes DM_FLAG_VITAL as "indicates that the device is
'vital' to the operation of other devices". Device removal at boot
should follow this.

Instead of adding dm_remove_devices_flags() with (DM_REMOVE_ACTIVE_ALL |
DM_REMOVE_NON_VITAL) everywhere add dm_remove_devices_active() which
does this.

Fixes a NULL pointer deref in the apple dart IOMMU driver during EFI
boot. The xhci-pci (driver which depends on the IOMMU to work) removes
its mapping on removal. This explodes when the IOMMU device was removed
first.

dm_remove_devices_flags() is kept since it is used for testing of
device_remove() calls in dm.

Signed-off-by: Janne Grunau &lt;j@jannau.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This replaces dm_remove_devices_flags() calls in all boot
implementations to ensure non vital devices are consistently removed
first. All boot implementation except arch/arm/lib/bootm.c currently
just call dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL). This can result
in crashes when dependencies between devices exists. The driver model's
design document describes DM_FLAG_VITAL as "indicates that the device is
'vital' to the operation of other devices". Device removal at boot
should follow this.

Instead of adding dm_remove_devices_flags() with (DM_REMOVE_ACTIVE_ALL |
DM_REMOVE_NON_VITAL) everywhere add dm_remove_devices_active() which
does this.

Fixes a NULL pointer deref in the apple dart IOMMU driver during EFI
boot. The xhci-pci (driver which depends on the IOMMU to work) removes
its mapping on removal. This explodes when the IOMMU device was removed
first.

dm_remove_devices_flags() is kept since it is used for testing of
device_remove() calls in dm.

Signed-off-by: Janne Grunau &lt;j@jannau.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>dm: core: Add a function to see if a device exists</title>
<updated>2024-11-04T03:27:12+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2024-10-19T15:21:49+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=79b3e9d25b3f96fdf66f9d7dc6a14fdce9a15f93'/>
<id>79b3e9d25b3f96fdf66f9d7dc6a14fdce9a15f93</id>
<content type='text'>
All the uclass functions for finding a device end up creating a uclass
if it doesn't exist. Add a function which instead returns NULL in this
case.

This is useful when in the 'unbind' path, since we don't want to undo
any unbinding which has already happened.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
All the uclass functions for finding a device end up creating a uclass
if it doesn't exist. Add a function which instead returns NULL in this
case.

This is useful when in the 'unbind' path, since we don't want to undo
any unbinding which has already happened.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge patch series "Implement ACPI on aarch64"</title>
<updated>2024-10-28T00:44:13+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2024-10-27T23:14:22+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2800aecce08b47b169d8e9824dd23b1297b2cedc'/>
<id>2800aecce08b47b169d8e9824dd23b1297b2cedc</id>
<content type='text'>
Patrick Rudolph &lt;patrick.rudolph@9elements.com&gt; says:

Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.

The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.

The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.

The changes were tested on real hardware as well on QEMU v9.0:

qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
                    -pflash secure-world.rom \
                    -pflash unsecure-world.rom

qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic

Tested against FWTS V24.03.00.

Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
  USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
  cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
  Linux kernel module doesn't support ACPI yet.

Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Patrick Rudolph &lt;patrick.rudolph@9elements.com&gt; says:

Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.

The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.

The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.

The changes were tested on real hardware as well on QEMU v9.0:

qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
                    -pflash secure-world.rom \
                    -pflash unsecure-world.rom

qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic

Tested against FWTS V24.03.00.

Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
  USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
  cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
  Linux kernel module doesn't support ACPI yet.

Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers: misc: irq-uclass: Update irq_get_by_index</title>
<updated>2024-10-27T23:24:13+00:00</updated>
<author>
<name>Patrick Rudolph</name>
<email>patrick.rudolph@9elements.com</email>
</author>
<published>2024-10-23T13:20:05+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f116feadea7be9afe412c25779dfcf241c121715'/>
<id>f116feadea7be9afe412c25779dfcf241c121715</id>
<content type='text'>
Support reading the "interrupts" property from the devicetree in case
the "interrupts-extended" property isn't found. As the "interrupts"
property is commonly used, this allows to parse all existing FDT and
makes irq_get_by_index() more useful.

The "interrupts" property doesn't contain a phandle as "interrupts-extended"
does, so implement a new method to locate the interrupt-parent called
irq_get_interrupt_parent().

TEST: Read the interrupts from the GIC node for ACPI MADT generation.

Signed-off-by: Patrick Rudolph &lt;patrick.rudolph@9elements.com&gt;
Reviewed-by: Moritz Fischer &lt;moritzf@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Support reading the "interrupts" property from the devicetree in case
the "interrupts-extended" property isn't found. As the "interrupts"
property is commonly used, this allows to parse all existing FDT and
makes irq_get_by_index() more useful.

The "interrupts" property doesn't contain a phandle as "interrupts-extended"
does, so implement a new method to locate the interrupt-parent called
irq_get_interrupt_parent().

TEST: Read the interrupts from the GIC node for ACPI MADT generation.

Signed-off-by: Patrick Rudolph &lt;patrick.rudolph@9elements.com&gt;
Reviewed-by: Moritz Fischer &lt;moritzf@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>acpi: Add fill_madt to acpi_ops</title>
<updated>2024-10-27T23:24:13+00:00</updated>
<author>
<name>Patrick Rudolph</name>
<email>patrick.rudolph@9elements.com</email>
</author>
<published>2024-10-23T13:19:51+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=763bad3e1cf202147fbddb74c9876d7426ddb26b'/>
<id>763bad3e1cf202147fbddb74c9876d7426ddb26b</id>
<content type='text'>
Add a new method to acpi_ops to let drivers fill out ACPI MADT.
The code is unused for now until drivers implement the new ops.

TEST: Booted on QEMU sbsa using driver model generated MADT.

Signed-off-by: Patrick Rudolph &lt;patrick.rudolph@9elements.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Cc: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a new method to acpi_ops to let drivers fill out ACPI MADT.
The code is unused for now until drivers implement the new ops.

TEST: Booted on QEMU sbsa using driver model generated MADT.

Signed-off-by: Patrick Rudolph &lt;patrick.rudolph@9elements.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Cc: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>test: dm: wdt: replace cyclic_run() by schedule()</title>
<updated>2024-10-23T04:52:38+00:00</updated>
<author>
<name>Rasmus Villemoes</name>
<email>ravi@prevas.dk</email>
</author>
<published>2024-10-03T21:27:55+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=e3bc477e8038195b54bf50e7915b111e9c357cf0'/>
<id>e3bc477e8038195b54bf50e7915b111e9c357cf0</id>
<content type='text'>
This is the last place outside of cyclic.c that references
cyclic_run() directly. Replace by schedule(), so that cyclic_run() can
be made private. This also better matches what I believe commit
29caf9305b6f ("cyclic: Use schedule() instead of WATCHDOG_RESET()")
intended to do.

Signed-off-by: Rasmus Villemoes &lt;ravi@prevas.dk&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is the last place outside of cyclic.c that references
cyclic_run() directly. Replace by schedule(), so that cyclic_run() can
be made private. This also better matches what I believe commit
29caf9305b6f ("cyclic: Use schedule() instead of WATCHDOG_RESET()")
intended to do.

Signed-off-by: Rasmus Villemoes &lt;ravi@prevas.dk&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Stefan Roese &lt;sr@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>watchdog: gpio_wdt: add support for stoppable devices</title>
<updated>2024-10-23T04:52:38+00:00</updated>
<author>
<name>Rasmus Villemoes</name>
<email>ravi@prevas.dk</email>
</author>
<published>2024-10-02T19:23:23+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7f3d53c8bf3b851837dc2f5dd85e0c6a0d0116a1'/>
<id>7f3d53c8bf3b851837dc2f5dd85e0c6a0d0116a1</id>
<content type='text'>
Back when I added this driver in commit 2ac8490412c9, I wrote

    The corresponding linux driver apparently has support for some
    watchdog circuits which can be disabled by tri-stating the gpio, but I
    have never actually encountered such a chip in the wild;

That has changed now; I have a board with just such a watchdog on my
desk currently. Add support for that.

- For a hw_algo="toggle" device, the gpio is requested as output if the
  always-running flag is set, otherwise as input.

- The -&gt;start() method is updated to change the direction to output when
  required (i.e. it is not always-running).

- The -&gt;stop() method is implemented, but of course reports failure if
  always-running.

As I still haven't met any hw_algo="level" devices, I'm not entirely
sure how they fit in, but I'm borrowing logic from the corresponding
linux driver:

- In -&gt;probe(), such devices always request the gpio as GPIOD_IS_OUT.

- In -&gt;stop(), the linux driver has an "eternal ping" comment and sets
  the gpio to (logic) high.

Stefan:
Added necessary changes in test/dm/wdt.c to fix CI build breakage, as
suggested by Rasmus.

Signed-off-by: Rasmus Villemoes &lt;ravi@prevas.dk&gt;
Reviewed-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Back when I added this driver in commit 2ac8490412c9, I wrote

    The corresponding linux driver apparently has support for some
    watchdog circuits which can be disabled by tri-stating the gpio, but I
    have never actually encountered such a chip in the wild;

That has changed now; I have a board with just such a watchdog on my
desk currently. Add support for that.

- For a hw_algo="toggle" device, the gpio is requested as output if the
  always-running flag is set, otherwise as input.

- The -&gt;start() method is updated to change the direction to output when
  required (i.e. it is not always-running).

- The -&gt;stop() method is implemented, but of course reports failure if
  always-running.

As I still haven't met any hw_algo="level" devices, I'm not entirely
sure how they fit in, but I'm borrowing logic from the corresponding
linux driver:

- In -&gt;probe(), such devices always request the gpio as GPIOD_IS_OUT.

- In -&gt;stop(), the linux driver has an "eternal ping" comment and sets
  the gpio to (logic) high.

Stefan:
Added necessary changes in test/dm/wdt.c to fix CI build breakage, as
suggested by Rasmus.

Signed-off-by: Rasmus Villemoes &lt;ravi@prevas.dk&gt;
Reviewed-by: Stefan Roese &lt;sr@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: introduce alternative implementation as net/lwip/</title>
<updated>2024-10-16T17:11:56+00:00</updated>
<author>
<name>Jerome Forissier</name>
<email>jerome.forissier@linaro.org</email>
</author>
<published>2024-10-16T10:03:59+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8cb330355bd52852f209cf08c1e79babfbdf1253'/>
<id>8cb330355bd52852f209cf08c1e79babfbdf1253</id>
<content type='text'>
Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by
adding a new net/lwip/ directory and the NET_LWIP symbol. Network
support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent
commits will introduce the lwIP code, re-work the NETDEVICE integration
and port some of the NET commands and features to lwIP.

SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols
that are part of NET (such as arp_init(), arp_timeout_check(),
arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be
added later.

Similarly, DFU_TFTP and FASTBOOT are not compatible with NET_LWIP
because of dependencies on net_loop(), tftp_timeout_ms,
tftp_timeout_count_max and other NET things. Let's add a dependency on
!NET_LWIP for now.

SANDBOX can select NET_LWIP but doing so will currently disable the eth
dm tests as well as the wget tests which have strong dependencies on the
NET code.

Other adjustments to Kconfig files are made to fix "unmet direct
dependencies detected" for USB_FUNCTION_SDP and CMD_FASTBOOT when
the default networking stack is set to NET_LWIP ("default NET_LWIP"
instead of "default NET" in Kconfig).

The networking stack is now a choice between NO_NET,
NET and NET_LWIP. Therefore '# CONFIG_NET is not set' should be
'CONFIG_NO_NET=y'. Adjust the defconfigs accordingly.

Signed-off-by: Jerome Forissier &lt;jerome.forissier@linaro.org&gt;
Acked-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by
adding a new net/lwip/ directory and the NET_LWIP symbol. Network
support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent
commits will introduce the lwIP code, re-work the NETDEVICE integration
and port some of the NET commands and features to lwIP.

SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols
that are part of NET (such as arp_init(), arp_timeout_check(),
arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be
added later.

Similarly, DFU_TFTP and FASTBOOT are not compatible with NET_LWIP
because of dependencies on net_loop(), tftp_timeout_ms,
tftp_timeout_count_max and other NET things. Let's add a dependency on
!NET_LWIP for now.

SANDBOX can select NET_LWIP but doing so will currently disable the eth
dm tests as well as the wget tests which have strong dependencies on the
NET code.

Other adjustments to Kconfig files are made to fix "unmet direct
dependencies detected" for USB_FUNCTION_SDP and CMD_FASTBOOT when
the default networking stack is set to NET_LWIP ("default NET_LWIP"
instead of "default NET" in Kconfig).

The networking stack is now a choice between NO_NET,
NET and NET_LWIP. Therefore '# CONFIG_NET is not set' should be
'CONFIG_NO_NET=y'. Adjust the defconfigs accordingly.

Signed-off-by: Jerome Forissier &lt;jerome.forissier@linaro.org&gt;
Acked-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"</title>
<updated>2024-10-11T18:23:25+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2024-10-11T18:23:25+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=47e544f576699ca4630e20448db6a05178960697'/>
<id>47e544f576699ca4630e20448db6a05178960697</id>
<content type='text'>
Simon Glass &lt;sjg@chromium.org&gt; says:

When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL

Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.

For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:

   #if defined(CONFIG_SPL_BUILD) &amp;&amp; !defined(CONFIG_TPL_BUILD)

In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.

This series starts a change in terminology and usage to resolve the
above issues:

- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
  'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
  defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_

It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.

This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.

The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Simon Glass &lt;sjg@chromium.org&gt; says:

When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL

Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.

For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:

   #if defined(CONFIG_SPL_BUILD) &amp;&amp; !defined(CONFIG_TPL_BUILD)

In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.

This series starts a change in terminology and usage to resolve the
above issues:

- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
  'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
  defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_

It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.

This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.

The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
</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>
</feed>
