The R5 SPL SRAM size is limited and cannot accommodate both MMC boot and
Ethernet boot config options simultaneously. Add a dedicated defconfig
that enables the Ethernet boot on SK-AM62A-LP for R5 SPL stage.
Reviewed-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Anshul Dalal <anshuld@ti.com>
Signed-off-by: Chintan Vankar <c-vankar@ti.com>
We don't have too many people looking at those at the moment, so having
people getting into the project by adding tests or documentation is I
believe a good thing so let's encourage those specific contributions.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
We are "a bit" struggling with reviewing things and it's most of the
time maintainers or long time contributors reviewing patches on the
mailing list.
Hint that reviewing is also contributing to the project and that even if
you don't feel you're an expert, your review is still welcome and can
help us catch bugs before they are merged.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
This way we don't need to make sure this link still points to something
that exists, as Sphinx will enforce it at build time. It also has the
added benefit that if someone builds the docs they will point at their
docs (though that is debatable whether that's useful, but at least you
stay on the same website).
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
PK, KEK, db, dbx etc must always be measured in PCR7.
DeployedMode and AuditMode should be measured in PCR1 if DeployedMode
is set and PCR7 otherwise.
Fix the u16_strcmp to only change the PCR value for those two variables.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The function defined by the TCG spec looks like:
typedef
EFI_STATUS
(EFIAPI *EFI_TCG2_GET_EVENT_LOG) (
IN EFI_TCG2_PROTOCOL *This,
IN EFI_TCG2_EVENT_LOG_FORMAT EventLogFormat,
OUT EFI_PHYSICAL_ADDRESS *EventLogLocation,
OUT EFI_PHYSICAL_ADDRESS *EventLogLastEntry,
OUT BOOLEAN *EventLogTruncated
);
and the spec mandates that
"If no TPM is present, the function SHALL set the following values and return
EFI_SUCCESS:
EventLogLocation = NULL
EventLogLastEntry = NULL
EventLogTruncated = FALSE"
However, if we set it to NULL the local assignment is discarded when the
function returns. Set it to 0, although on some platforms that's a valid
address.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
When doing a sha256_update() for the measured DT, the size arguments for
fdt_size_dt_struct() and fdt_size_dt_strings() are inversed.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
In efi_sigstore_parse_siglist() sigdata is allocated. But instead of an
allocation matching the size of sigdata, tainted external data was used
to calculate the allocation size. This may lead to buffer overflows.
* Correct the allocation size.
* Follow the man-page. Use the structure size as second argument for
calloc.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Enhance the unit test to verify all Revision fields and all pointers of all
the EFI_BLOCK_IO_PROTOCOL structures.
As the unit test registers its own block io protocol for test purposes,
make sure to initialize its revision properly, as it will be verified as
well.
This can run on the sandbox with the following command:
./u-boot -T -c 'setenv efi_selftest block device; bootefi selftest'
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
In the block device selftest, make the handles pointer global and free it
also in teardown(), to simplify error handling.
We also need to nullify the pointer after freeing it on the normal path,
to avoid freeing it a second time during teardown().
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The list-table layout does not allow grouping columns together,
convert the table into grid-table layout instead and rework it
such that SoC families, generations, architectures and SoCs are
grouped together. Include SoC column to group SoCs together, and
Core column which is useful on SoC like the R-Car X5H where U-Boot
can run on multiple cores in the SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Update the Build section and note that it is only applicable
in case the table above does not contain any board specific
instructions. Include information that the Architecture column
now contains toolchain setup instruction links.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen5 X5H Ironhide board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Retronix R-Car Gen4 V4H Sparrow Hawk board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 D3 Draak board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 E3 Ebisu board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 M3Le Geist board.
Include Renesas R-Car Gen3 SPI NOR installation procedure document.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 H3/M3-W/M3-N ULCB board.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add document which clarifies how to build and install U-Boot on
Renesas R-Car Gen3 H3/M3-W/M3-N Salvator-X(S) board.
Include generic and HyperFlash Renesas R-Car Gen3 installation
procedure document.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add documents which briefly outline how to set up the SH4/Aarch32/Aarch64
toolchains, for future use in Renesas documentation. Reference all these
documents in the renesas list of boards "Arch" column.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
table_compute_checksum() returns the value that makes the byte sum of
the buffer zero. If the ext_checksum field already contains a non-zero
value (as QEMU's firmware-provided RSDP does), adding that existing
value into the sum produces an incorrect complement. Zero the field
before calling table_compute_checksum() so the calculation starts from
a clean state, matching the pattern used in acpi_write_rsdp().
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Bryan Brattlof <bb@ti.com> says:
Someone figured out that we do not wait long enough for the DDR chip to
be ready during initializing. During that debug it was also discovered
we don't handle warm resets correctly. These 2 patches should fix this.
I don't have a scope fast enough to prove these patches have fixed the
reported issues but I am boot testing (cold and warm resets) with a BBB
at my desk which seems to be OK with these applied.
With how old these platforms are I doubt we will see any issue on our
current devices and probably need a different DDR part to see any
stability improvements but these should help stabilize board wakeups
with different DDR parts.
Link: https://lore.kernel.org/r/20260624-335-ddr-cke-delay-v1-0-21d65d40a83f@ti.com
During a warm reset, the DDR controller will be put into a self refresh
state and will exit self refresh on reset release which will put the
controller in a ready state during bootup.
However we will reinitialize the controller regardless which will
temporarily (~6us) glitch the DDR_RESET line low
Fix this by checking if the VTP controller is already in a ready state
before we initialize the controller unnecessarily.
Fixes: 3ba65f97cb ("am33xx: refactor emif4/ddr to support multiple EMIF instances")
Signed-off-by: Bryan Brattlof <bb@ti.com>
With the Beaglebone Black the delay on DDR_RESET to DDR_CKE is currently
~135us and not the >500us required by JEDEC spec.
The issue here is the REF_CTRL register performs two purposes. It is the
counter for CKE to RESET delay before the DDR controller is initialized
and used to configure the refresh rate after initialization of the
controller.
So to avoid inadvertently configuring the CKE to DDR delay, ensure we
initialize the controller before we configure the refresh rate.
Fixes: 69b918b65d ("am33xx,ddr3: fix ddr3 sdram configuration")
Signed-off-by: Bryan Brattlof <bb@ti.com>
readl_relaxed_poll_timeout() relies on timers. On the beaglebone black,
the timer used by readl_relaxed_poll_timeout() depends on this clock
driver. So we have a sort of circular dependency [enable_clock ->
timer_init -> enable_clock -> timer_init]. It leads to a
division-per-zero during the second timer_init() and the beaglebone
fails to boot with following message:
| CPU : AM335X-GP rev 2.1
| Model: TI AM335x BeagleBone Black
| DRAM: 512 MiB
| ### ERROR ### Please RESET the board ###
Replace readl_relaxed_poll_timeout() with a simple loop that uses CPU
ticks to countdown the timeout. This loop and the value of LDELAY are
inspired from what's done in arch/arm/mach-omap2/am33xx/clock.c
Also, arch/arm/mach-omap2/am33xx/clock.c doesn't return an error on
timeout, it only logs it, so let's stick with it.
Fixes: de2e3f00f2 ("clk: ti: Remove AM33xx dependency")
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Reported-by: Tom Rini <trini@konsulko.com>
Tested-by: Tom Rini <trini@konsulko.com>
Julien Stephan <jstephan@baylibre.com> says:
When I first ran ./tools/qconfig.py, it immediately crashed with a
Python traceback because the configuration database had not yet been
generated.
This series adds a simple pre-check that detects this condition and
prints a clear error message instructing the user to generate the
database first using the -b option, instead of failing with an unhandled
exception.
While looking at the script, I also noticed that the help text still
references the obsolete moveconfig.rst document. This series updates
that reference as well.
Link: https://lore.kernel.org/r/20260702-qconfig-check-for-db-v1-0-f0b96bf8fa44@baylibre.com
This was missed during the renaming of the tool. Fix it.
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Fixes: ea4d6dead3 ("moveconfig: Rename the tool to qconfig")
Reviewed-by: Tom Rini <trini@konsulko.com>
When CONFIG_DATABASE does not exist, read_database() would fail with a
Python traceback. Add a pre-check to print a clear message asking the
user to generate the database first with the -b option.
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Billy Tsai <billy_tsai@aspeedtech.com> says:
The AST2700 is Aspeed's 7th-generation BMC SoC with a dual-die
architecture: SoC0 (CPU die) and SoC1 (I/O die) each have their own SCU
with independent multi-function pin controls. Initial AST2700 platform
support is already merged in next, including the ast2700.dtsi pinctrl0
and pinctrl1 nodes, but no pinctrl driver backs them yet.
This series adds one pinctrl driver per die, each followed by a patch
adding its pin configuration support. Both drivers use the generic
pinctrl framework and are compatible with the Linux kernel device tree
bindings, using the same group and function names as the Linux
aspeed,ast2700-soc0/soc1-pinctrl drivers so pin states can be shared
between the kernel and U-Boot device trees.
Patch 1 adds the SoC0 driver, which models each (function, group) pair
as a flat register mask/value table covering eMMC, VB, VGA DDC, JTAG
master port select, PCIe RC PERST and USB2/USB3 port routing. Patch 2
adds SoC0 pin configuration support: every GPIO18A/GPIO18B ball has
its own IO control register providing a 3 mA to 41 mA drive strength
selector and bias control.
Patch 3 adds the SoC1 driver, porting the per-pin 4-bit multi-function
selector scheme (220 pins, 238 groups, 217 functions) together with
the virtual pins for PCIe RC2 PERST, the USB2 port C/D mode and SGMII
controls. Patch 4 adds SoC1 pin configuration support: a per-pin bias
enable bit and sparse 2-bit drive strength fields (4 mA to 16 mA in
4 mA steps) mirroring the Linux driver layout.
The bias-disable, bias-pull-down, bias-pull-up and drive-strength
properties can be applied per pin or per group. Both drivers implement
gpio_request_enable so the GPIO driver can reclaim pins through the
gpio-ranges already present in ast2700.dtsi, and provide
get_pin_muxing so "pinmux status" reports the active signal of every
pin.
Link: https://lore.kernel.org/r/20260702-pinctrl-v1-0-4d2bd89fc213@aspeedtech.com
The SoC1 SCU provides a bias enable bit per pin in the registers at
0x480 (setting the bit disables the bias; the pull direction is fixed
in silicon) and 2-bit drive strength fields at 0x4C0 selecting 4 mA to
16 mA in 4 mA steps. The pin-to-field mapping of the drive strength
registers is sparse and non-linear, so it is kept in a lookup table
mirroring the Linux driver; pins without an entry reject
drive-strength with -ENOTSUPP.
Support the bias-disable, bias-pull-down, bias-pull-up and
drive-strength properties per pin and per group, and select PINCONF so
the generic pinctrl framework parses them.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Add the pinctrl driver for the AST2700 SoC1 (I/O) die.
Unlike previous Aspeed generations, the SoC1 SCU assigns every pin a
4-bit multi-function selector field in a contiguous register range
starting at SCU 0x400, eight pins per register. Only bits [2:0] of
each field select the function; bit 3 is reserved read-only and must
not be written. The driver therefore keeps per-pin group tables and
per-function mux values, mirroring the Linux
aspeed,ast2700-soc1-pinctrl driver, and shares the same device tree
bindings: 220 pins, 238 groups and 217 functions with identical names,
so pin states written for the Linux driver work unmodified.
A few controls live outside the pin-indexed range and are handled as
virtual pins: PCIERC2_PERST (SCU 0x908), the USB2 port C/D mode fields
(SCU 0x3B0) and SGMII0 (SCU 0x47C).
The gpio_request_enable hook restores a pin to GPIO by writing mux
value 0, except for the ADC-capable balls W17..AB19 where function 1
selects GPIO and 0 selects the ADC input.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Each GPIO18A/GPIO18B ball has its own IO control register starting at
SCU 0x480, providing a 4-bit drive strength selector (3 mA to 41 mA in
hardware-defined steps), a bias enable bit and a pull direction bit.
Extend the group table with the pin members of the ball-backed groups
so bias-disable, bias-pull-down, bias-pull-up and drive-strength
properties can be applied per group as well as per pin. The routing
groups (USB, JTAG, PCIe RC) have no package balls and reject pin
configuration with -ENOTSUPP.
Select PINCONF so the generic pinctrl framework parses the pin
configuration properties.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
The AST2700 is a dual-die BMC SoC: SoC0 (CPU die) and SoC1 (I/O die)
each have their own SCU with independent multi-function pin controls.
Add the pinctrl driver for the SoC0 die. The driver uses the generic
pinctrl framework and is compatible with the Linux kernel device tree
bindings, i.e. pin states are described with the same "function" and
"groups" properties and the same names as the Linux
aspeed,ast2700-soc0-pinctrl driver.
Unlike the older AST2500/AST2600 SCUs where each signal is enabled by
independent bits, the SoC0 mux selections mix single-bit enables
(eMMC, VGA DDC, VB strap), multi-bit selector fields (JTAG master port
select, USB2/USB3 port routing) and reset-control bits (PCIe RC
PERST). Model each (function, group) pair as one register
mask/value write so all of them fit a single flat table.
The gpio_request_enable hook releases the GPIO18A/GPIO18B pins to GPIO
mode by clearing every signal enable bit that claims the pin, matching
the Linux driver behaviour.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
CI: https://git.u-boot-project.org/u-boot/custodians/u-boot-mmc/-/pipelines/614
- Add PMBUS regulator, thermal and test
- Add regulator helper to set voltage within an acceptable range
- Update dw_mmc to use in-spec voltage range for vqmmc
- Fix regulator_enable/disable() macros
- Clear LPUART OR STAT in tstc to avoid hang
- Add MAINTAINERS entry for SDHCI
get_maintainer in U-Boot is configured to include contributors and patch
reviewers from the git history in the CC list, going back 1 year if they
have contributed more than 5% of the patches.
This is well suited to some core U-Boot code that has a long history and
doesn't get much love from any dedicated maintainer but for newer code
and board code in general as well as defconfigs it can be frustrating
for some contributors who do not wish to be CC'd on patches as well as a
general issue when dead emails are included.
While it would be desirable to just remove the --git flag and encourage
those interested to configure lei or just add themselves to MAINTAINERS
it perhaps makes more sense to phase it out gradually.
As a first step, reduce the time period that will be checked in the git
history from 1 year to 6 months, this still offers plenty of leeway for
contributions to the last 1/2 U-Boot releases. In addition, bump up the
required percentage of contributions from 5% to 15% and reduce the limit
on the number of "git maintainers" (i.e. unique S-o-b/A-b/R-b tags) from
5 to 2.
These changes should reduce the size of CC lists while still including
recent active contributors.
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Coverity reports an INTEGER_OVERFLOW issue because ut_asserteq() compares
an unsigned int (mmc_dev_num) with ret, which can hold a negative error
code.
Addresses-Coverity-ID: CID 646439: Integer handling issues (INTEGER_OVERFLOW)
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
The software revision field in the combined board config binary header
was hardcoded to 1, preventing independent control from SBL SWREV
configured via ti-secure-rom's sw-rev property.
Add support for the optional 'sw-rev' DTS property in ti_board_config
nodes, which sets the SWREV byte in the header. Defaults to 1 for
backward compatibility.
Signed-off-by: Shiva Tripathi <s-tripathi1@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The fdt checksign command accepts an optional address for an FDT
containing public keys. It currently installs that blob as gd->fdt_blob
before verifying the FIT configuration.
This breaks verification with DM-backed crypto drivers which have not
probed yet, since the later probe path expects gd->fdt_blob to remain
U-Boot's control FDT. For example, an ECDSA verifier can be bound from
the control FDT but fail to probe after fdt checksign points
gd->fdt_blob at the key-only DTB.
Add a FIT config verification helper that takes the key blob explicitly
and use it from fdt checksign. This keeps gd->fdt_blob unchanged while
still allowing the command to verify against an external key DTB.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Now that we have everything available on git.u-boot-project.org, switch
URLs to that location.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Add dm unit tests that drive every pmbus subcommand handler against
the sandbox PMBus chip emulator:
dev (select by bus:addr and by regulator-name), list, info,
telemetry, status, dump, read, write, clear, vout, scan and help.
Tested using:
./u-boot -T -c "ut dm pmbus*"
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
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 <vjardin@free.fr>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The driver is a thin UCLASS_THERMAL: its get_temp reads the
temperature of its parent regulator through the pmbus helper
(READ_TEMPERATURE_1), without any chip-specific code.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Wire board/nxp/common/vid.c into the <pmbus.h> framework so the legacy
NXP AVS path stops carrying its own duplicate copy of the PMBus
protocol and instead consumes the shared constants, decoders, and
transport helpers.
vid.c is the legacy NXP AVS/pre-kernel voltage-trim path for lx2160 CPUs.
It does PMBus to whichever core-rail voltage monitor the board carries:
LTC3882 or ISL68233 are selected with
CONFIG_VOL_MONITOR_LTC3882_*/CONFIG_VOL_MONITOR_ISL68233_*.
Before this change the file kept its own local PMBUS_CMD_* command-code
defines, its own inline LINEAR16 mantissa/exponent math, and called
into I2C through the I2C_READ/I2C_WRITE NXP wrappers in
board/nxp/common/i2c_common.{c,h} which is a parallel implementation of
exactly what <pmbus.h> + lib/pmbus.c provides.
The intent is to make vid.c an consumer of the new PMBus.
Compatibility with the former support:
- CLI unchanged: vdd_override and vdd_read keep their existing
semantics, return codes, and diagnostic output.
- I2C transport unchanged on the wire: the framework's pmbus_*
helpers call dm_i2c_read/dm_i2c_write: the same DM I2C
backing that vid.c's former I2C_READ/I2C_WRITE macros already
routed through on DM_I2C.
- Numeric decode is bit-equivalent: pmbus_reg2data_linear16() and
pmbus_data2reg_linear16() implement the PMBus 1.3 Part II
mantissa/exponent.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
