<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/arch/sandbox/dts/test.dts, branch main</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/test.dts?h=main</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/arch/sandbox/dts/test.dts?h=main'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2026-07-16T18:06:40Z</updated>
<entry>
<title>Merge patch series "vbe: bound FIT external-data reads against the firmware area"</title>
<updated>2026-07-16T18:06:40Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-07-16T18:06:40Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=91303d8a663248e15bd76801778ff709e490d88d'/>
<id>urn:sha1:91303d8a663248e15bd76801778ff709e490d88d</id>
<content type='text'>
Aristo Chen &lt;aristo.chen@canonical.com&gt; says:

vbe_read_fit() loads a firmware-phase FIT from a fixed firmware area on
a block device and then issues a follow-up blk_read() to pull in the
image, and optionally an FDT, referenced by the FIT's image node. The
source offset on the device and the read length both come from the FIT
itself, via data-position or data-offset and data-size. Those properties
live on mutable boot media and can be controlled by an attacker with
write access to the firmware area. On the TPL or VPL path, and on the
bootmeth bootflow path reached via abrec_read_bootflow_fw() and
vbe_simple_read_bootflow_fw(), the follow-up blk_read() runs before any
signature or hash check on the loaded phase.

Patch 1 is a sandbox test-tree preparation. The firmware1 node in
arch/sandbox/dts/test.dts declared area-size = 0xe00000 (14 MiB), but
the binman fw-update section in sandbox_vpl.dtsi is 32 MiB and the FIT
inside it carries ~16 MiB of external data, so the FIT already extended
past the declared area. The mismatch was tolerated because no caller
bounded the external-data load against area_size. Patch 1 raises
area-size to match the binman section size so test_vbe_vpl keeps passing
once the bound is enforced. The patches are ordered so the test is never
broken in the middle of the series.

Patch 2 adds the missing range check, confining the FIT-supplied
[load_addr, load_addr + len) window to [addr, addr + area_size] before
block numbers and lengths are computed, and applying the same constraint
to fdt_load_addr and fdt_size. The check is written in subtraction-only
form against the trusted area_size so the comparison cannot itself
overflow.

Patch 3 adds two sandbox unit tests under test/boot/ that construct
synthetic FITs with out-of-range data-position and oversized data-size,
write them to mmc1, and confirm vbe_read_fit() returns -E2BIG for each
before issuing the follow-up blk_read().

Deferring the external-data blk_read() until after the phase has been
signature-verified would be a stronger structural fix and was discussed
on the v1 thread. Simon confirmed the bounded read is the right first
step and that the verify-then-load change should be a separate series,
so this v3 stays scoped to the bound.

Link: https://lore.kernel.org/r/20260705034414.2247-1-aristo.chen@canonical.com
</content>
</entry>
<entry>
<title>sandbox: vbe: size firmware1 area to fit the binman fw-update section</title>
<updated>2026-07-16T18:06:14Z</updated>
<author>
<name>Aristo Chen</name>
<email>aristo.chen@canonical.com</email>
</author>
<published>2026-07-05T03:44:09Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a8fc408cdfcbc3d8a04b493510a54d852f60550d'/>
<id>urn:sha1:a8fc408cdfcbc3d8a04b493510a54d852f60550d</id>
<content type='text'>
The firmware1 node in test.dts declares area-size = 0xe00000 (14 MiB)
but the binman fw-update section in sandbox_vpl.dtsi is 0x2000000
(32 MiB) and the FIT inside it carries ~16 MiB of external data
(spl + u-boot subimages). The FIT therefore extends past the
declared firmware area, contradicting the documented contract of
vbe_read_fit() that the FIT must fit within @area_size.

The mismatch was tolerated because no caller actually bounded the
external-data load against area_size. Bring the devicetree in line
with the binman section size so the FIT extent stays within the
trusted firmware area, in preparation for vbe_read_fit() enforcing
that bound.

state-offset and version-offset are left as-is; they were already
inside the FIT data region and are not exercised by test_vbe_vpl.

Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Aristo Chen &lt;aristo.chen@canonical.com&gt;
</content>
</entry>
<entry>
<title>test: dm: pmbus: add a sandbox PMBus chip emulator</title>
<updated>2026-07-13T03:24:40Z</updated>
<author>
<name>Vincent Jardin</name>
<email>vjardin@free.fr</email>
</author>
<published>2026-07-12T18:20:48Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=995cc3383b7ee88bbe18e3ea8b2c13530b5af3b4'/>
<id>urn:sha1:995cc3383b7ee88bbe18e3ea8b2c13530b5af3b4</id>
<content type='text'>
Add a UCLASS_I2C_EMUL driver that emulates a PMBus 1.x compliant chip
behind the sandbox I2C bus, plus the test.dts wiring and sandbox
defconfig that bind it to the generic PMBus regulator
(compatible = "pmbus"). This design is a stub only: it lets the
follow-up dm unit test drive lib/pmbus.c, the generic regulator and
the pmbus CLI command with no real hardware.

The emulator models a flat per-command 16-bit register file and the
three identification block strings (MFR_ID / MFR_MODEL /
MFR_REVISION). READ_IIN and READ_POUT are deliberately left
unimplemented (the chip NAKs them) so the telemetry printer's
"(not supported)" path is exercised, mirroring a real buck that only
calibrates a subset of the sensor classes.

Signed-off-by: Vincent Jardin &lt;vjardin@free.fr&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&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>
</feed>
