<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/arch/sandbox/dts, branch master</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/u-boot.git/atom/arch/sandbox/dts?h=master</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/arch/sandbox/dts?h=master'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2026-06-11T13:56:52Z</updated>
<entry>
<title>Merge patch series "allow control DTB to double as "FIT image""</title>
<updated>2026-06-11T13:56:52Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-06-11T13:56:52Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=69491eb60a86e68fac304a7f1f9ff9fcd05f0d39'/>
<id>urn:sha1:69491eb60a86e68fac304a7f1f9ff9fcd05f0d39</id>
<content type='text'>
Rasmus Villemoes &lt;rv@rasmusvillemoes.dk&gt; says:

The commit message for patch 1 explains what it is I'd like to be able
to do, but here's some more background:

For a long time, we've embedded the boot script in the U-Boot binary
by building a bootscript.itb, and using a .dtsi like

  / {
          config {
                 bootscript = /incbin/("/path/to/bootscript.itb");
          };
  };

which in turn is mentioned in CONFIG_DEVICE_TREE_INCLUDES, that
bootscript.itb FIT image has been embedded in U-Boot's control
dtb. Running that was then a matter of doing

  fdt addr ${fdtcontroladdr} &amp;&amp; fdt get addr bsaddr /config bootscript &amp;&amp; source ${bsaddr}

There are a couple of advantage of having the bootscript (and other
script logic) embedded in the U-Boot binary. First, there's no need to
figure out some separate partition to store the script in, and making
sure that gets updated whenever the bootloader itself does. Second,
one doesn't need to worry about verifying the script; whatever steps
one needs to take to implement secure boot for U-Boot itself will by
necessity also cover the control dtb (if nothing else then because
that's where the public key for the kernel verification lives). And
third, the boot script is automatically updated together with U-Boot
itself; and if U-Boot is stored in an eMMC boot partition, that update
is guaranteed to be atomic.

Now with the stricter requirements of libfdt starting from v2026.04,
the above command no longer worked, or only half the time, because the
embedded FIT image may not land on an 8-byte aligned address. So that
line had to be changed a little (line breaks added)

  fdt addr ${fdtcontroladdr}
    &amp;&amp; fdt get addr bsaddr /config bootscript
    &amp;&amp; fdt get size bssize /config bootscript
    &amp;&amp; cp.b ${bsaddr} ${loadaddr} ${bssize}
    &amp;&amp; source ${loadaddr}

which is getting quite unwieldy.

Then it struck me that one could perhaps simplify all of this quite a
lot: Cut out the intermediate bootscript.itb, just create a .dtsi
which directly puts a /images node inside the control dtb

/ {
  	images {
		default = "bootscript";
		bootscript {
			description = "Boot script";
			data = /incbin/("/path/to/bootscript.sh");
			type = "script";
			compression = "none";
		};
	};
};

and treat the control dtb itself as a FIT image; so the command to put
in $bootcmd becomes simply

  source ${fdtcontroladdr}:bootscript

and embedding other pieces of callable scripts is quite trivial.

And that almost works out-of-the-box, except for the fit_check_format() sanity check.

Introduce a CONFIG_ knob that allows one to opt out of those sanity
checks, for the special case of the address being checked being
identical to gd-&gt;fdt_blob.

Link: https://lore.kernel.org/r/20260602213013.558064-1-rv@rasmusvillemoes.dk
</content>
</entry>
<entry>
<title>test: hook up test of allowing control DTB to act as FIT image</title>
<updated>2026-06-11T13:56:45Z</updated>
<author>
<name>Rasmus Villemoes</name>
<email>rv@rasmusvillemoes.dk</email>
</author>
<published>2026-06-02T21:30:13Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c8a636af67c640e1427e1085c8bada672e48f805'/>
<id>urn:sha1:c8a636af67c640e1427e1085c8bada672e48f805</id>
<content type='text'>
Add a test demonstrating how one can embed various scripts in the
control DTB.

Verify that the source command can be used with ${fdtcontroladdr} by
itself (invoking the default script), and with :&lt;node-name&gt;
suffix. Check that the scripts themselves can invoke "sibling"
scripts. Also verify that without CONTROL_DTB_AS_FIT set, the control
DTB is not accepted by the source command.

Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Rasmus Villemoes &lt;rv@rasmusvillemoes.dk&gt;
</content>
</entry>
<entry>
<title>reset: sandbox: Cover reset_reset() fallback with second sandbox provider</title>
<updated>2026-06-08T08:50:06Z</updated>
<author>
<name>Michal Simek</name>
<email>michal.simek@amd.com</email>
</author>
<published>2026-05-25T11:45:44Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4e3f64c7cc0c6a5defdceb485313b8a33f231f10'/>
<id>urn:sha1:4e3f64c7cc0c6a5defdceb485313b8a33f231f10</id>
<content type='text'>
Add a sandbox reset controller compatible string
"sandbox,reset-ctl-fallback-only" that reuses the existing sandbox assert,
deassert, request, and free helpers but omits rst_reset. That forces
reset_reset() through the core assert / udelay / deassert fallback.

Extend the reset-ctl-test DT node with a fifth reset line named "fallback"
that points at the new provider, and add dm_test_reset_reset_fallback_path
which verifies sandbox_reset_get_count() stays zero (rst_reset is never
invoked) while the line ends deasserted after reset_reset().

This complements the existing rst_reset coverage on sandbox,reset-ctl and
matches the approach of using a separate controller to exercise the
fallback path in unit tests.

Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Michal Simek &lt;michal.simek@amd.com&gt;
Link: https://lore.kernel.org/r/c1d40db6e2332a8b23ba842385b3f8c3d0290109.1779709539.git.michal.simek@amd.com
</content>
</entry>
<entry>
<title>test: dm: add PHY common props unit tests and sandbox DT nodes</title>
<updated>2026-05-06T09:07:22Z</updated>
<author>
<name>Lucien.Jheng</name>
<email>lucienzx159@gmail.com</email>
</author>
<published>2026-04-25T08:06:49Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=615c5367170272b5dda8b7ceae515f18dcfcafbf'/>
<id>urn:sha1:615c5367170272b5dda8b7ceae515f18dcfcafbf</id>
<content type='text'>
Add sandbox DM unit tests for the PHY common properties library and the
corresponding device tree test nodes to arch/sandbox/dts/test.dts.
Also enable CONFIG_PHY_COMMON_PROPS in configs/sandbox_defconfig so
the tests are built and run in the sandbox environment.

The test file covers rx/tx polarity lookups for all relevant cases:

  - missing property (defaults to PHY_POL_NORMAL)
  - single value without names array (applies to all modes)
  - count mismatch between values and names arrays (-EINVAL)
  - name found by exact match
  - name not found with no "default" fallback (-EINVAL)
  - name not found with a "default" entry (uses fallback value)
  - unsupported polarity value (-EOPNOTSUPP)

Ported from Linux KUnit test:
  linux/drivers/phy/phy-common-props-test.c

Signed-off-by: Lucien.Jheng &lt;lucienzx159@gmail.com&gt;
</content>
</entry>
<entry>
<title>test: boot: Add test for bootmeth_rauc</title>
<updated>2026-03-06T18:09:17Z</updated>
<author>
<name>Martin Schwan</name>
<email>m.schwan@phytec.de</email>
</author>
<published>2026-02-18T13:35:07Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=36add050eea439f0b2a15e4ea0d3a8e21216f159'/>
<id>urn:sha1:36add050eea439f0b2a15e4ea0d3a8e21216f159</id>
<content type='text'>
Add a simple unit test for testing the RAUC bootmethod. Provide only the
very basic tests for now, running a scan and list, to verify correct
detection of the RAUC bootmethod. More advanced boot tests of this
bootmethod can be added in a separate patch.

This requires another mmc image (mmc10) to contain the following
partitions:

1. boot A: contains a dummy boot.scr
2. root A: contains an empty root filesystem
3. boot B: contains a dummy boot.scr
4. root B: contains an empty root filesystem

The bootmeth_rauc scans all four partitions for existence and expects a
boot script in each boot partition.

Also add BOOTMETH_RAUC as a dependency on sandbox so that we can test
this with:

$ ./test/py/test.py -B sandbox --build -k test_ut # build the mmc10.img
$ ./test/py/test.py -B sandbox --build -k bootflow_rauc

Signed-off-by: Martin Schwan &lt;m.schwan@phytec.de&gt;
Reviewed-by: Simon Glass &lt;simon.glass@canonical.com&gt;
[trini: mmc9 is now in use, switch to mmc10]
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
</entry>
<entry>
<title>test: cmd: Add test for zip/unzip/gzwrite commands</title>
<updated>2026-02-18T21:02:58Z</updated>
<author>
<name>Marek Vasut</name>
<email>marek.vasut+renesas@mailbox.org</email>
</author>
<published>2026-02-05T01:40:45Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=6be3db6c1ab33c7ad90a8b25d7777e8425bf15cf'/>
<id>urn:sha1:6be3db6c1ab33c7ad90a8b25d7777e8425bf15cf</id>
<content type='text'>
Add simple test for zip/unzip/gzwrite commands. The test works as
follows. First, create three buffers with a bit of space between
each of them, fill them with random data, then compress data in
buffer 1 into buffer 2, decompress data in buffer 2 either directly
into buffer 3 or into MMC 1 and then read them back into buffer 3,
and finally compare buffer 1 and buffer 3, they have to be identical.

The buffers are filled with random data to detect out of bounds writes.
Test for various sizes, both small and large and unaligned.

The test uses ut_assert_skip_to_line() to skip over gzwrite progress
bar. Since the progress bar updates fill up the console record buffer,
increase the size of it to compensate.

Reviewed-by: Mattijs Korpershoek &lt;mkorpershoek@kernel.org&gt;
Tested-by: Mattijs Korpershoek &lt;mkorpershoek@kernel.org&gt;
Signed-off-by: Marek Vasut &lt;marek.vasut+renesas@mailbox.org&gt;
</content>
</entry>
<entry>
<title>test: dm: Add compatible multimatch test</title>
<updated>2026-01-28T15:20:59Z</updated>
<author>
<name>Markus Schneider-Pargmann (TI.com)</name>
<email>msp@baylibre.com</email>
</author>
<published>2026-01-27T11:03:39Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c7e0e3fd33ca9809605a6de0a58809daf1224bff'/>
<id>urn:sha1:c7e0e3fd33ca9809605a6de0a58809daf1224bff</id>
<content type='text'>
Add a test for binding of multiple drivers with the same compatible. If
one of the drivers returns -ENODEV the other one needs to be bound.

Reviewed-by: Simon Glass &lt;simon.glass@canonical.com&gt;
Reviewed-by: Mattijs Korpershoek &lt;mkorpershoek@kernel.org&gt;
Signed-off-by: Markus Schneider-Pargmann (TI.com) &lt;msp@baylibre.com&gt;
</content>
</entry>
<entry>
<title>sandbox: Fix DT compiler pin warnings in sandbox DTs</title>
<updated>2025-11-28T16:20:24Z</updated>
<author>
<name>Marek Vasut</name>
<email>marek.vasut+renesas@mailbox.org</email>
</author>
<published>2025-11-13T11:56:30Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=416ceee82f7abe4065446a0b97252c8c1573438c'/>
<id>urn:sha1:416ceee82f7abe4065446a0b97252c8c1573438c</id>
<content type='text'>
Trivially fix the following warnings in sandbox DTs, which show up with
DTC 1.7.2. Assign pin groups less confusing node names with pins- prefix
to avoid confusing DT compiler into thinking the node is really a bus node:

"
arch/sandbox/dts/.test.dtb.pre.tmp:1831.20-1841.5: Warning (i2c_bus_bridge): /pinctrl/i2c: incorrect #address-cells for I2C bus
arch/sandbox/dts/.test.dtb.pre.tmp:1831.20-1841.5: Warning (i2c_bus_bridge): /pinctrl/i2c: incorrect #size-cells for I2C bus
arch/sandbox/dts/test.dtb: Warning (i2c_bus_reg): Failed prerequisite 'i2c_bus_bridge'
arch/sandbox/dts/.test.dtb.pre.tmp:1848.20-1856.5: Warning (spi_bus_bridge): /pinctrl/spi: incorrect #address-cells for SPI bus
arch/sandbox/dts/.test.dtb.pre.tmp:1848.20-1856.5: Warning (spi_bus_bridge): /pinctrl/spi: incorrect #size-cells for SPI bus
arch/sandbox/dts/test.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge'
"

Signed-off-by: Marek Vasut &lt;marek.vasut+renesas@mailbox.org&gt;
Reviewed-by: Mattijs Korpershoek &lt;mkorpershoek@kernel.org&gt;
Reviewed-by: Heiko Schocher &lt;hs@nabladev.com&gt;
</content>
</entry>
<entry>
<title>sandbox: Fix DT compiler address warnings in sandbox DTs</title>
<updated>2025-11-28T16:20:24Z</updated>
<author>
<name>Marek Vasut</name>
<email>marek.vasut+renesas@mailbox.org</email>
</author>
<published>2025-11-13T11:56:29Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=9bde0c1da52e9421c84fa622849d85dbb77603e6'/>
<id>urn:sha1:9bde0c1da52e9421c84fa622849d85dbb77603e6</id>
<content type='text'>
Trivially fix the following warnings in sandbox DTs, which show up with
DTC 1.7.2. Fill in the missing address and adjust emulated I2C address
to fit the 7bit address limit:

"
arch/sandbox/dts/sandbox.dtsi:138.30-140.5: Warning (i2c_bus_reg): /i2c@0/sandbox_pmic: I2C bus unit address format error, expected "40"
arch/sandbox/dts/sandbox.dtsi:146.18-161.5: Warning (i2c_bus_reg): /i2c@0/emul: I2C bus unit address format error, expected "ff"
arch/sandbox/dts/sandbox.dtsi:148.4-17: Warning (i2c_bus_reg): /i2c@0/emul:reg: I2C address must be less than 7-bits, got "0xff". Set I2C_TEN_BIT_ADDRESS for 10 bit addresses or fix the property
"

"
arch/sandbox/dts/.test.dtb.pre.tmp:912.18-926.5: Warning (i2c_bus_reg): /i2c@0/emul: I2C bus unit address format error, expected "ff"
arch/sandbox/dts/.test.dtb.pre.tmp:913.4-17: Warning (i2c_bus_reg): /i2c@0/emul:reg: I2C address must be less than 7-bits, got "0xff". Set I2C_TEN_BIT_ADDRESS for 10 bit addresses or fix the property
arch/sandbox/dts/.test.dtb.pre.tmp:928.30-931.5: Warning (i2c_bus_reg): /i2c@0/sandbox_pmic: I2C bus unit address format error, expected "40"
"

Fix up pmic test to match.

Signed-off-by: Marek Vasut &lt;marek.vasut+renesas@mailbox.org&gt;
Reviewed-by: Heiko Schocher &lt;hs@nabladev.com&gt;
Reviewed-by: Mattijs Korpershoek &lt;mkorpershoek@kernel.org&gt;
</content>
</entry>
<entry>
<title>interconnect: add DM test suite</title>
<updated>2025-11-20T08:17:58Z</updated>
<author>
<name>Neil Armstrong</name>
<email>neil.armstrong@linaro.org</email>
</author>
<published>2025-11-20T08:12:53Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=9ab7163710d390672a7325cd0980ce32e2a8191a'/>
<id>urn:sha1:9ab7163710d390672a7325cd0980ce32e2a8191a</id>
<content type='text'>
Add a test suite exercising the whole lifetime and callbacks
of interconnect with a fake 5 providers with a split node graph.

The test suite checks the calculus are right and goes to the correct
nodes, and the lifetime of the node is correct.

Link: https://patch.msgid.link/20251120-topic-interconnect-next-v5-2-e8a82720da5d@linaro.org
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
</content>
</entry>
</feed>
