| Age | Commit message (Collapse) | Author |
|---|
|
area"
Aristo Chen <[email protected]> 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/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Aristo Chen <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add a sandbox LDO3 with a configurable 1.8V to 3.3V range and use it
to test regulator_set_value_clamp().
Test in-range requests, clamping against the regulator limits, invalid
ranges outside the regulator limits and a min value higher than max.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Rasmus Villemoes <[email protected]> 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} && fdt get addr bsaddr /config bootscript && 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}
&& fdt get addr bsaddr /config bootscript
&& fdt get size bssize /config bootscript
&& cp.b ${bsaddr} ${loadaddr} ${bssize}
&& 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->fdt_blob.
Link: https://lore.kernel.org/r/[email protected]
|
|
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 :<node-name>
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 <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/c1d40db6e2332a8b23ba842385b3f8c3d0290109.1779709539.git.michal.simek@amd.com
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
[trini: mmc9 is now in use, switch to mmc10]
Signed-off-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Tested-by: Mattijs Korpershoek <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Signed-off-by: Markus Schneider-Pargmann (TI.com) <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
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/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
Add s simple test for the I3C uclass in sandbox.
Signed-off-by: Dinesh Maniyam <[email protected]>
|
|
Create a basic test suit for AES DM uclass that covers all available
operations.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
This will allow arch(s) that use device tree blobs to pad the end of the
device tree so they can be modified by board files at run time. This will
help prevent errors such as FDT_ERR_NOSPACE from occurring.
Signed-off-by: Eric Schikschneit <[email protected]>
[trini: Change default order so that X86 && EFI_APP works correctly]
|
|
Use white on black for the expo menu as it is easier on the eyes.
Signed-off-by: Simon Glass <[email protected]>
|
|
Add tests for video bridge ops.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Test suit for of_graph parsing helpers.
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
in linux we have the option to create the name of a led
optionally through the following properties:
- function
- color
- function-enumerator
This patch adds support for parsing this properties if there
is no label property.
The led name is created in led_post_bind() and we need some
storage place for it. Currently this patch prevents to use
malloc() instead it stores the name in new member :
char name[LED_MAX_NAME_SIZE];
of struct led_uc_plat. While at it append led tests for the
new feature.
Signed-off-by: Heiko Schocher <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
implementation"
Christian Marangi <[email protected]> says:
This series is split in 2 part.
While adapting the LED boot and activity code to the new property
accepted by Rob in dt-schema repository, a big BUG was discovered.
The reason wasn't clear at start and took me some days to figure it
out.
This was triggered by adding a new phandle in the test.dts to
introduce test for the new OPs.
This single addition caused the sandbox CI test to fail in the
dm_test_ofnode_phandle_ot test.
This doesn't make sense as reverting the change made the CI test
to correctly finish. Also moving the uboot node down
after the first phandle (in test.dts the gpio one) also made
the CI test to correctly finish.
A little bit of searching and debugging made me realize the
parse phandle OPs didn't support other.dts at all and they
were still referencing phandle index from test.dts.
(more info in the related commit)
In short the test was broken all along and was working by
pure luck. The first 4 patch address and fix the problem for good.
The other 4 patch expand and address the property change for
LED boot/activity.
Posting in a single series as changes are trivial and just
to speedup review process. (and also because the second
part depends on the first)
All CI tested with azure pipeline.
Link: https://lore.kernel.org/r/[email protected]
|
|
Update test for LED activity and boot to follow new implementation with
property set to the LED node phandle.
Also update a copy-paste error in the function name for the activity
tests and actually enable the test with the DM_TEST macro.
Signed-off-by: Christian Marangi <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add test for ofnode options phandle helper and add new property in the
sandbox test dts.
Signed-off-by: Christian Marangi <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Expand dm_test_ofnode_phandle(_ot) with new ofnode/tree_parse_phandle() op.
Signed-off-by: Christian Marangi <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Fix broken dm_test_ofnode_phandle_ot test. They never actually worked
and were passing test by pure luck by having the same phandle index of
test.dts that coincicentally had #gpio-cells in the same index node.
It was sufficient to add a phandle to test.dts to make the test fail.
To correctly test these feature, make use oif the new OPs oftree to
parse phandle.
For consistency with the dm_test_ofnode_phandle, rework the test and
other.dts to use the same property with the other- prefix to every
node.
Also fix dm_test_ofnode_get_by_phandle_ot by making it more robust and
renaming the phandle property to other-phandle.
Signed-off-by: Christian Marangi <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Rename actual android bootmethod test to specify it's for boot image
version 4.
Add a unit test for testing the Android bootmethod with boot image
version 2.
This requires another mmc image (mmc8) to contain the following
partitions:
- misc: contains the Bootloader Control Block (BCB)
- boot_a: contains a fake generic kernel image
we can test this with:
$ ./test/py/test.py --bd sandbox --build -k test_ut # build the mmc8.img
$ ./test/py/test.py --bd sandbox --build -k bootflow_android
Reviewed-by: Mattijs Korpershoek <[email protected]>
Signed-off-by: Guillaume La Roque <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Create a new disk for use with tests, which contains the new 'testapp'
EFI app specifically intended for testing the EFI loader.
Attach it to the USB device, since most testing is currently done with
mmc.
Initially this image will be used to test the EFI bootmeth.
Fix a stale comment in prep_mmc_bootdev() while we are here.
For now this uses sudo and a compressed fallback file, like all the
other bootstd tests. Once this series is in, the patch which moves
this to use user-space tools will be cleaned up and re-submitted.
Signed-off-by: Simon Glass <[email protected]>
|
|
Patrick Rudolph <[email protected]> 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/[email protected]
|
|
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 <[email protected]>
Reviewed-by: Moritz Fischer <[email protected]>
|
|
At present menu items are stored according to their sequence number in
the menu. In some cases we may want to have holes in that sequence, or
not use a sequence at all.
Add a new 'value' property for menu items. This will be used for
reading and writing, if present. If there is no 'value' property, then
the normal sequence number will be used instead.
Signed-off-by: Simon Glass <[email protected]>
|
|
This phandle was missing in the sandbox DT, add it, otherwise sandbox-i2c
driver cannot look up the emulator via i2c_emul_find(). This fixes the
following i2c_emul_find() error:
"
$ ./u-boot -Dc ""
...
i2c_emul_find() No emulators for device 'sandbox_pmic'
sandbox_pmic_write() write error to device: 0000000018c568d0 register: 0x0!
out_set_value() PMIC write failed: -5
i2c_emul_find() No emulators for device 'sandbox_pmic'
sandbox_pmic_write() write error to device: 0000000018c568d0 register: 0x0!
out_set_value() PMIC write failed: -5
...
"
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The dtbs: target is almost identical in all architecture Makefiles.
All architecture Makefiles include scripts/Makefile.dts . Deduplicate
the dtbs: target into scripts/Makefile.dts . No functional change.
Reviewed-by: Sumit Garg <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Tested-by: Caleb Connolly <[email protected]> #qcom, OF_UPSTREAM
|
|
Expand ofnode options test with new generic helper for bool, int and
string.
Signed-off-by: Christian Marangi <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add tests for LED boot and activity feature and add required property in
sandbox test DTS.
Signed-off-by: Christian Marangi <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Sughosh Ganu <[email protected]> says:
This is a follow-up from an earlier RFC series [1] for making the LMB
and EFI memory allocations work together. This is a non-rfc version
with only the LMB part of the patches, for making the LMB memory map
global and persistent.
This is part one of a set of patches which aim to have the LMB and EFI
memory allocations work together. This requires making the LMB memory
map global and persistent, instead of having local, caller specific
maps. This is being done keeping in mind the usage of LMB memory by
platforms where the same memory region can be used to load multiple
different images. What is not allowed is to overwrite memory that has
been allocated by the other module, currently the EFI memory
module. This is being achieved by introducing a new flag,
LMB_NOOVERWRITE, which represents memory which cannot be re-requested
once allocated.
The data structures (alloced lists) required for maintaining the LMB
map are initialised during board init. The LMB module is enabled by
default for the main U-Boot image, while it needs to be enabled for
SPL. This version also uses a stack implementation, as suggested by
Simon Glass to temporarily store the lmb structure instance which is
used during normal operation when running lmb tests. This does away
with the need to run the lmb tests separately.
The tests have been tweaked where needed because of these changes.
The second part of the patches, to be sent subsequently, would work on
having the EFI allocations work with the LMB API's.
[1] - https://lore.kernel.org/u-boot/[email protected]/T/#t
Notes:
1) These patches are on next, as the alist patches have been
applied to that branch.
2) I have tested the boot on the ST DK2 board, but it would be good to
get a T-b/R-b from the ST maintainers.
3) It will be good to test these changes on a PowerPC platform
(ideally an 85xx, as I do not have one).
|
|
The TCG event log buffer is being set at the end of ram memory. This
region of memory is to be reserved as LMB_NOMAP memory in the LMB
memory map. The current location of this buffer overlaps with the
memory region reserved for the U-Boot image, which is at the top of
the usable memory. This worked earlier as the LMB memory map was not
global but caller specific, but fails now because of the overlap.
Move the TCG event log buffer to the start of the ram memory region
instead. Move the location of the early trace buffer and the load
buffer for U-Boot(spl boot) accordingly.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The sandbox pinmux driver is used in the non-test devicetree as well as
the test one. I didn't realize this when I modified the driver for
tests, and so broke the regular use case (which only resulted in
warnings). First, making the pinmux and the UART group available
pre-relocation to avoid ENODEV errors. Then, convert the pin groups and
functions to the new style, adding onewire group as well.
Fixes: 7f0f1806e3a ("test: pinmux: Add test for pin muxing")
Closes: https://source.denx.de/u-boot/u-boot/-/issues/2
Signed-off-by: Sean Anderson <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add a unit test for testing the Android bootmethod.
This requires another mmc image (mmc7) to contain the following partitions:
- misc: contains the Bootloader Control Block (BCB)
- boot_a: contains a fake generic kernel image
- vendor_boot_a: contains a fake vendor_boot image
Also add BOOTMETH_ANDROID as a dependency on sandbox so that we can test
this with:
$ ./test/py/test.py --bd sandbox --build -k test_ut # build the mmc7.img
$ ./test/py/test.py --bd sandbox --build -k bootflow_android
Signed-off-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Julien Masson <[email protected]>
Reviewed-by: Guillaume La Roque <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Currently, all the capsules for the sandbox platform are generated at
the time of running the capsule tests. To showcase generation of
capsules through binman, generate all raw(non FIT payload) capsules
needed for the sandbox platform as part of the build. This acts as an
illustrative example for generating capsules as part of a platform's
build.
Make corresponding change in the capsule test's configuration to get
these capsules from the build directory.
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
Adjust the DT to match upstream bindings.
Reviewed-by: Neil Armstrong <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
With the recent changes to the Qualcomm PMIC GPIO driver the sandbox
tests for it no longer pass, update the DTS and tests to work with the
changes.
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Prepare v2024.01-rc5
|
|
Assign ccf_clk_ops to .ops of clk_ccf driver so that it can act as an
clk provider. Also add "#clock-cells=<1>" to its device tree node.
Add "i2c_root" to clk_test in the device tree and driver for testing.
Get "i2c_root" clock in CCF unit tests and add tests for it.
Signed-off-by: Yang Xiwen <[email protected]>
Reviewed-by: Sean Anderson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Prepare v2024.01-rc3
|
|
Add a sandbox NAND flash driver to facilitate testing. This driver supports
any number of devices, each using a single chip-select. The OOB data is
stored in-band, with the separation enforced through the API.
For now, create two devices to test with. The first is a very small device
with basic ECC. The second is an 8G device (chosen to be larger than 32
bits). It uses ONFI, with the values copied from the datasheet. It also
doesn't need too strong ECC, which speeds things up.
Although the nand subsystem determines the parameters of a chip based on
the ID, the driver itself requires devicetree properties for each
parameter. We do not derive parameters from the ID because parsing the ID
is non-trivial. We do not just use the parameters that the nand subsystem
has calculated since that is something we should be testing. An exception
is made for the ECC layout, since that is difficult to encode in the device
tree and is not a property of the device itself.
Despite using file I/O to access the backing data, we do not support using
external files. In my experience, these are unnecessary for testing since
tests can generally be written to write their expected data beforehand.
Additionally, we would need to store the "programmed" information somewhere
(complicating the format and the programming process) or try to detect
whether block are erased at runtime (degrading probe speeds).
Information about whether each page has been programmed is stored in an
in-memory buffer. To simplify the implementation, we only support a single
program per erase. While this is accurate for many larger flashes, some
smaller flashes (512 byte) support multiple programs and/or subpage
programs. Support for this could be added later as I believe some
filesystems expect this.
To test ECC, we support error-injection. Surprisingly, only ECC bytes in
the OOB area are protected, even though all bytes are equally susceptible
to error. Because of this, we take care to only corrupt ECC bytes.
Similarly, because ECC covers "steps" and not the whole page, we must take
care to corrupt data in the same way.
Signed-off-by: Sean Anderson <[email protected]>
|
|
The baudrate configured in .config is taken by default by serial. If
change of baudrate is required then the .config needs to changed and
u-boot recompilation is required or the u-boot environment needs to be
updated.
To avoid this, support is added to fetch the baudrate directly from the
device tree file and update.
The serial, prints the log with the configured baudrate in the dtb.
The commit c4df0f6f315c ("arm: mvebu: Espressobin: Set default value for
$fdtfile env variable") is taken as reference for changing the default
environment variable.
The default environment stores the default baudrate value, When default
baudrate and dtb baudrate are not same glitches are seen on the serial.
So, the environment also needs to be updated with the dtb baudrate to
avoid the glitches on the serial.
Also add test to cover this new function.
Signed-off-by: Algapally Santosh Sagar <[email protected]>
Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Michal Simek <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-tpm
bootX measurements and measurement API moved to u-boot core:
Up to now, U-Boot could perform measurements and EventLog creation as
described by the TCG spec when booting via EFI.
The EFI code was residing in lib/efi_loader/efi_tcg2.c and contained
both EFI specific code + the API needed to access the TPM, extend PCRs
and create an EventLog. The non-EFI part proved modular enough and
moving it around to the TPM subsystem was straightforward.
With that in place we can have a common API for measuring binaries
regardless of the boot command, EFI or boot(m|i|z), and contructing an
EventLog.
I've tested all of the EFI cases -- booting with an empty EventLog and
booting with a previous stage loader providing one and found no
regressions. Eddie tested the bootX part.
Eddie also fixed the sandbox TPM which couldn't be used for the EFI code
and it now supports all the required capabilities. This had a slight
sideeffect in our testing since the EFI subsystem initializes the TPM
early and 'tpm2 init' failed during some python tests. That code only
opens the device though, so we can replace it with 'tpm2 autostart'
which doesn't error out and still allows you to perfom the rest of the
tests but doesn't report an error if the device is already opened.
There's a few minor issues with this PR as well but since testing and
verifying the changes takes a considerable amount of time, I prefer
merging it now.
Heinrich has already sent a PR for -master containing "efi_loader: fix
EFI_ENTRY point on get_active_pcr_banks" and I am not sure if that will
cause any conflicts, but in any case they should be trivial to resolve.
Both the EFI and non-EFI code have a Kconfig for measuring the loaded
Device Tree. The reason this is optional is that we can't reason
when/if devices add random info like kaslr-seed, mac addresses etc in
the DT. In that case measurements are random, board specific and
eventually useless. The reason it was difficult to fix it prior to this
patchset is because the EFI subsystem and thus measurements was brought
up late and DT fixups might have already been applied. With this
patchset we can measure the DT really early in the future.
Heinrich also pointed out that the two Kconfigs for the DTB measurements
can be squashed in a single one and that the documentation only explains
the non-EFI case. I agree on both but as I said this is a sane working
version, so let's pull this first it's aleady big enough and painful to
test.
|
|
Use the sandbox TPM driver to measure some boot images in a unit
test case.
Signed-off-by: Eddie James <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
