<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/include/env_callback.h, 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>env: Fix network support when CONFIG_NET_LWIP is set</title>
<updated>2025-05-30T19:43:24+00:00</updated>
<author>
<name>Benjamin ROBIN</name>
<email>dev@benjarobin.fr</email>
</author>
<published>2025-05-17T20:09:30+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=6aa9c0f453cf920762e0b90d56d80f7cb36d5e6d'/>
<id>6aa9c0f453cf920762e0b90d56d80f7cb36d5e6d</id>
<content type='text'>
When lwIP (CONFIG_NET_LWIP) is used instead of legacy stack (CONFIG_NET),
environment flags support associated with network was not built: restore
support of "i" and "m" environment flags.

Signed-off-by: Benjamin ROBIN &lt;dev@benjarobin.fr&gt;
Acked-by: Jerome Forissier &lt;jerome.forissier@linaro.org&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When lwIP (CONFIG_NET_LWIP) is used instead of legacy stack (CONFIG_NET),
environment flags support associated with network was not built: restore
support of "i" and "m" environment flags.

Signed-off-by: Benjamin ROBIN &lt;dev@benjarobin.fr&gt;
Acked-by: Jerome Forissier &lt;jerome.forissier@linaro.org&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>env: Switch the callback static list to Kconfig</title>
<updated>2024-12-06T22:37:43+00:00</updated>
<author>
<name>Christoph Niedermaier</name>
<email>cniedermaier@dh-electronics.com</email>
</author>
<published>2024-11-20T16:01:35+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=dca82739b9d767d4074e990b060f0da93ba36550'/>
<id>dca82739b9d767d4074e990b060f0da93ba36550</id>
<content type='text'>
Switch the callback static list from the board configuration variable
CFG_ENV_CALLBACK_LIST_STATIC to Kconfig CONFIG_ENV_CALLBACK_LIST_STATIC.

Signed-off-by: Christoph Niedermaier &lt;cniedermaier@dh-electronics.com&gt;
Reviewed-by: Marek Vasut &lt;marex@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Switch the callback static list from the board configuration variable
CFG_ENV_CALLBACK_LIST_STATIC to Kconfig CONFIG_ENV_CALLBACK_LIST_STATIC.

Signed-off-by: Christoph Niedermaier &lt;cniedermaier@dh-electronics.com&gt;
Reviewed-by: Marek Vasut &lt;marex@denx.de&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>include: 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:49+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f38956a687c42db8d9736e09df2d68705369950e'/>
<id>f38956a687c42db8d9736e09df2d68705369950e</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>dfu: define a callback function for the dfu_alt_info environment variable</title>
<updated>2024-10-01T08:55:09+00:00</updated>
<author>
<name>Rasmus Villemoes</name>
<email>rasmus.villemoes@prevas.dk</email>
</author>
<published>2024-09-11T13:39:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4b17845529f5f0c94fe68c2daba1948d0ee41bb2'/>
<id>4b17845529f5f0c94fe68c2daba1948d0ee41bb2</id>
<content type='text'>
I'm trying to use dfu-util for bootstrapping an stm32mp board. It
mostly works fine, but something goes horribly wrong as soon as I make
use of the ability to run arbitrary u-boot shell commands. The shell
commands themselves work fine, but the heuristic "dfu_alt_info may
have changed, we have to reinit" seems to cause the board and/or my
host machine to go into some bad state, and further dfu-util commands
fail.

U-Boot already has a mechanism whereby C code can be told about
changes to specific environment variables. So instead of always doing
re-init, add a hook to the dfu_alt_info variable so that we only do
set dfu_reinit_needed if the commands actually did modify that
variable.

Signed-off-by: Rasmus Villemoes &lt;rasmus.villemoes@prevas.dk&gt;
Reviewed-by: Mattijs Korpershoek &lt;mkorpershoek@baylibre.com&gt;
Link: https://lore.kernel.org/r/20240911133900.1444083-1-rasmus.villemoes@prevas.dk
Signed-off-by: Mattijs Korpershoek &lt;mkorpershoek@baylibre.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I'm trying to use dfu-util for bootstrapping an stm32mp board. It
mostly works fine, but something goes horribly wrong as soon as I make
use of the ability to run arbitrary u-boot shell commands. The shell
commands themselves work fine, but the heuristic "dfu_alt_info may
have changed, we have to reinit" seems to cause the board and/or my
host machine to go into some bad state, and further dfu-util commands
fail.

U-Boot already has a mechanism whereby C code can be told about
changes to specific environment variables. So instead of always doing
re-init, add a hook to the dfu_alt_info variable so that we only do
set dfu_reinit_needed if the commands actually did modify that
variable.

Signed-off-by: Rasmus Villemoes &lt;rasmus.villemoes@prevas.dk&gt;
Reviewed-by: Mattijs Korpershoek &lt;mkorpershoek@baylibre.com&gt;
Link: https://lore.kernel.org/r/20240911133900.1444083-1-rasmus.villemoes@prevas.dk
Signed-off-by: Mattijs Korpershoek &lt;mkorpershoek@baylibre.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"</title>
<updated>2024-05-20T19:35:03+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2024-05-20T19:35:03+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=03de305ec48b0bb28554372abb40ccd46dbe0bf9'/>
<id>03de305ec48b0bb28554372abb40ccd46dbe0bf9</id>
<content type='text'>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman &lt;jonas@kwiboo.se&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman &lt;jonas@kwiboo.se&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""</title>
<updated>2024-05-19T14:16:36+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2024-05-19T02:20:43+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d678a59d2d719da9e807495b4b021501f2836ca5'/>
<id>d678a59d2d719da9e807495b4b021501f2836ca5</id>
<content type='text'>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman &lt;jonas@kwiboo.se&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman &lt;jonas@kwiboo.se&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>env: Remove &lt;common.h&gt; and add needed includes</title>
<updated>2024-05-06T21:05:04+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2024-04-27T14:11:03+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0f92fa4560335f04858bfc9881e0bc6bbb756b3f'/>
<id>0f92fa4560335f04858bfc9881e0bc6bbb756b3f</id>
<content type='text'>
Remove &lt;common.h&gt; from all "env/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove &lt;common.h&gt; from all "env/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bootstd: Use the bootargs env var for changing the cmdline</title>
<updated>2023-07-16T15:13:17+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2023-07-12T15:04:35+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d42243fe21c8847cd5c6db4e11b2aee660448451'/>
<id>d42243fe21c8847cd5c6db4e11b2aee660448451</id>
<content type='text'>
The "bootargs" environment variable is used to set the command-line
arguments to pass to the OS. Use this same mechanism with bootstd as well.
When the variable is updated, it is written to the current bootflow. When
the current bootflow is updated, the environment variable is updated too.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The "bootargs" environment variable is used to set the command-line
arguments to pass to the OS. Use this same mechanism with bootstd as well.
When the variable is updated, it is written to the current bootflow. When
the current bootflow is updated, the environment variable is updated too.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>global: Finish CONFIG -&gt; CFG migration</title>
<updated>2023-01-20T17:27:24+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2023-01-10T16:19:45+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=6e7df1d151a7a127caf3b62ff6dfc003fc2aefcd'/>
<id>6e7df1d151a7a127caf3b62ff6dfc003fc2aefcd</id>
<content type='text'>
At this point, the remaining places where we have a symbol that is
defined as CONFIG_... are in fairly odd locations. While as much dead
code has been removed as possible, some of these locations are simply
less obvious at first. In other cases, this code is used, but was
defined in such a way as to have been missed by earlier checks.  Perform
a rename of all such remaining symbols to be CFG_... rather than
CONFIG_...

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
At this point, the remaining places where we have a symbol that is
defined as CONFIG_... are in fairly odd locations. While as much dead
code has been removed as possible, some of these locations are simply
less obvious at first. In other cases, this code is used, but was
defined in such a way as to have been missed by earlier checks.  Perform
a rename of all such remaining symbols to be CFG_... rather than
CONFIG_...

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
