Tom Rini <trini@konsulko.com> says:
This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.
Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <trini@konsulko.com>
Since commit 53d5a22163 ("emulation: Use bloblist to hold tables")
`make qemu-riscv64_smode_defconfig acpi.config && make` fails with
drivers/misc/qfw_smbios.c:93:(.text.qfw_evt_write_smbios_tables+0xe):
undefined reference to `bloblist_add'
Build with bloblist support.
Fixes: 53d5a22163 ("emulation: Use bloblist to hold tables")
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Note that this undoes the changes of commit cf6d4535cc ("x86:
emulation: Disable bloblist for now") as that was intended only for the
release due to time.
Harsha Vardhan V M <h-vm@ti.com> says:
This patch series introduces the fuse writebuff sub-system command and
makes improvements to the existing fuse implementation by removing the
custom string functions. The patches are required to be applied in
sequence.
The series consists of the following changes:
Patch 1 removes custom string functions and replaces them with standard
string functions.
Patch 2 introduces fuse.rst documentation for fuse commands.
Patch 3 introduces the fuse writebuff sub-system command, allowing to
write a structured buffer in memory to fuses, and implementing the
necessary function calls.
Patch 4 enables the fuse sub-system in the K3 platform.
Patch 5 updates the fuse.rst documentation to include details about the
new fuse writebuff command.
These changes aim to improve the fuse sub-system by the removal of
custom string functions and the addition of the fuse writebuff
command improves fuse programming workflows by allowing to write a
structured buffer in memory to efuses.
Link: https://lore.kernel.org/r/20250319084714.335777-1-h-vm@ti.com
Add K3_FUSE config option to add and enable fuse sub-system
implementation function calls.
Signed-off-by: Harsha Vardhan V M <h-vm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The existing QEMU implementation mostly ignored BLOBLIST_TABLES and
allocates the bulk of the tables with malloc(). Update it to place all
tables in the bloblist. Since QEMU declares a size of 128KB regardless
of the size of its tables, this requires a larger bloblist.
Fix up the e820 table to handle this, keeping the old code as an option
for now, to assist with any future bug-fixing.
Signed-off-by: Simon Glass <sjg@chromium.org>
The end of the ACPI table is set to 'addr' instead of 'end'. The ACPI
code for QEMU relies on those values to mark memory as 'ACPI Reclaim'
and as a result the ACPI RSDP ends up in Boot services Data.
Reported-by: Björn Töpel <bjorn@kernel.org>
Fixes: commit 638cc36348 ("acpi: enable writing ACPI tables on QEMU")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
QEMU can have its own internal ACPI and SMBIOS tables. At present U-Boot
copies out the SMBIOS tables but points directly to the ACPI ones.
The ACPI tables are not aligned on a 4KB boundary, which means that UPL
cannot use them directly, since it uses a reserved-memory node for the
tables and that it assumed (by EDK2) to be 4KB-aligned.
On x86, QEMU provides the tables in a mapped memory region and U-Boot
makes use of these directly, thus making it difficult to use any common
code.
Adjust the logic to fit within the existing table-generation code. Use a
bloblist always and ensure that the ACPI tables is placed in an aligned
region. Set a size of 8K for QEMU. This does not actually put all the
tables in one place, for QEMU, since it currently adds a pointer to the
tables in QFW.
On ARM, enable bloblist so that SMBIOS tables can be added to the
bloblist.
Signed-off-by: Simon Glass <sjg@chromium.org>
Raymond Mao <raymond.mao@linaro.org> says:
Motivations for changes:
Current SMBIOS library and command-line tool is not fully matching with
the requirements:
1. Missing support for other mandatory types (#7, #9, #16, #17, #19).
2. Only a few platforms support SMBIOS node from the device tree.
3. Values of some fields are hardcoded in the library other than fetching
from the device hardware.
4. Embedded data with dynamic length is not supported (E.g. Contained
Object Handles in Type #2 and Contained Elements in Type #3)
Changes:
1. Refactor the SMBIOS library and command-line tool to better align with
the SMBIOS spec.
2. Create an arch-specific driver for all aarch64-based platforms to fetch
SMBIOS private data from the device hardware (processor and cache).
3. Create a sysinfo driver to poppulate platform SMBIOS private data.
4. Add generic SMBIOS DTS file for arm64 platforms for those common strings
and values which cannot be retrieved from the system registers.
Vendors can create their own SMBIOS node using this as an example.
For those boards without SMBIOS nodes, this DTS file can be included to
have a generic SMBIOS information of the system.
5. Add support for Type #7 (Cache Information) and link its handles to
Type #4.
6. To minimize size-growth for those platforms which have not sufficient
ROM spaces or the platforms which don't need detailed SMBIOS
information, new added fields are only being built when kconfig
GENERATE_SMBIOS_TABLE_VERBOSE is selected.
Once this patch is acceptted, subsequent patch sets will add other missing
types (#9, #16, #17, #19).
Tests:
To test this with QEMU arm64, please follow the guide on dt_qemu.rst to
get a merged DT to run with.
```
qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \
| dtc - -o merged.dtb
qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \
-dtb merged.dtb
```
Link: https://lore.kernel.org/r/20241206225438.13866-1-raymond.mao@linaro.org
Enable sysinfo smbios by default for arm64.
When SYSINFO_SMBIOS is enabled, disable QFW_SMBIOS.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Aniket Limaye <a-limaye@ti.com> says:
This series adds OPP_LOW spec data in k3_avs driver and enables a config
option to select the OPP_LOW performance point.
J7200 SOC supports OPP_LOW and OPP_NOM as two Operating Performance
Points as per (7.5 Operating Performance Points) section in the
Datasheet [0].
- A72SS/MSMC at 2 GHz/1GHz operation must use OPP_NOM.
- A72SS/MSMC at 1 GHz/500 MHz operation can use OPP_NOM or OPP_LOW
voltage (though OPP_LOW voltage is recommended to reduce power
consumption).
The actual OPP voltage for the device is read from the efuse and
updated in k3_avs_probe().
The default j7200 devicetree and k3_avs driver set OPP_NOM spec
frequency and voltage.
In the board init file, if K3_OPP_LOW config is enabled, Check if
OPP_LOW AVS voltage read from efuse is valid and update frequency (A72
and MSMC) and voltage (VDD_CPU) as per the OPP_LOW spec.
[0]: https://www.ti.com/lit/gpn/dra821u (J7200 Datasheet)
Test logs:
https://gist.github.com/aniket-l/328ad93ed60c2419ed7be9f85e6b6075
- With series applied on master and CONFIG_K3_OPP_LOW enabled in
j7200_evm_r5_defconfig
- Logs shown with and without efuse register programmed for OPP_0
(Errors out if OPP_0 not found, programs OPP_LOW spec if found)
- Voltage update verified using 'i2c md 0x4c 0xe' in u-boot
- Frequency update verified using 'k3conf clock dump' in linux
Link: https://lore.kernel.org/r/20241119003617.1871183-1-a-limaye@ti.com
k3_avs driver checks opp_ids when probing and overwrites the voltage
values in vd_data for the respective board. The new k3_avs_check_opp()
can be called from board files to check the efuse data and returns 0 if
valid.
Also add the same check in k3_avs_program_voltage() to error out if
the efuse data was not valid.
Signed-off-by: Reid Tonking <reidt@ti.com>
Signed-off-by: Aniket Limaye <a-limaye@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
J7200 SOC supports OPP_LOW and OPP_NOM as two Operating Performance
Points as per (7.5 Operating Performance Points) section in the
Datasheet [0].
- A72SS/MSMC at 2 GHz/1GHz operation must use OPP_NOM.
- A72SS/MSMC at 1 GHz/500 MHz operation can use OPP_NOM or OPP_LOW
voltage (though OPP_LOW voltage is recommended to reduce power
consumption).
Add OPP_LOW frequency->voltage entry to vd_data.
The actual OPP voltage for the device is read from the efuse and
updated in k3_avs_probe().
OPP_NOM corresponds to OPP_1 and OPP_LOW to OPP_0 efuse register
fields, as described in the Datasheet [0]
The register offsets and fields are described in the TRM (5.2.6.1.5
WKUP_VTM_VD_OPPVID_j Register) [1].
[0]: https://www.ti.com/lit/gpn/dra821u (J7200 Datasheet)
[1]: https://www.ti.com/lit/pdf/spruiu1 (J7200 TRM)
Signed-off-by: Reid Tonking <reidt@ti.com>
Signed-off-by: Aniket Limaye <a-limaye@ti.com>
The ST M24256E behaves as a regular M24C256, except for the E variant
which uses up another I2C address for Additional Write lockable page.
This page is 64 Bytes long and can contain additional data. Add entry
for it, so users can describe that page in DT. Note that users still
have to describe the main M24C256 area separately as that is on separate
I2C address from this page.
Unlike M24C32-D and M24C64-D, this part is specifically ST and does not
have any comparable M24* counterparts from other vendors, hence the st,
vendor prefix. Furthermore, the part name is M24256E without C between
the 24 and 256, this is not a typo. Finally, there is M24C256-D part,
which does contain 32 Bytes long Additional Write lockable page, which
is a different part and not supported by this patch.
Datasheet: https://www.st.com/resource/en/datasheet/m24256e-f.pdf
From Linux kernel commit:
339cb28b9ee6 ("eeprom: at24: add ST M24256E Additional Write lockable page support")
Signed-off-by: Marek Vasut <marex@denx.de>
Driver for a PMIC watchdog timer controlled via Siemens SCU firmware
extensions. Only useful on some Siemens i.MX8-based platforms as
special SCFW is needed which provides the needed SCU API.
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Patrick Rudolph <patrick.rudolph@9elements.com> 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/20241023132116.970117-1-patrick.rudolph@9elements.com
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 <patrick.rudolph@9elements.com>
Reviewed-by: Moritz Fischer <moritzf@google.com>
Different devices have different MPU clk and dev ID. Currently it had
been hardcoded. Move it to DT based extraction.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Reviewed-by: Aniket Limaye <a-limaye@ti.com>
Check if AVS could not be programmed and print a warning.
Fixes: 9d233b4e3e ("misc: k3_avs: add driver for K3 Adaptive Voltage Scaling Class 0")
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Reviewed-by: Aniket Limaye <a-limaye@ti.com>
When OSCCA is enabled, FSB fuse shadow (offset 0x8000)
access is disabled for SOC. So update the driver to read fuse
from ELE API. The ELE has supported to read all shadow fuses like
FSB, reuse the table of FSB for the word index used by ELE API.
Add ELE shadow fuse read and write to current ELE fuse driver.
But when LC is OEM closed, the ELE read/write shadow fuse APIs are
forbidden. Reading from any fuse will return error. This causes
problem to u-boot which must read out some fuse no matter whatever LC.
So we have to change back to read from FSB and ELE common fuse read API.
For using ELE shadow read API for development purpose like checking
the ELE shadow fuse write result, user can set env variable
"enable_ele_shd" to y to switch it.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
There is a bug when checking fuse word with redundancy fuse in FSB
table. The redundancy fuses are combined into 4 words, so we can't
directly use word index to do the check, otherwise the high 4 words
will fail to match.
And When calling ELE API, res parameter will pass to ELE API to get ELE
response value for failure. So most of usage does not initialize
this variable and print it after calling ELE API.
However, when ELE API returns failure, we can't ensure this res is
always set because there may be other failure like MU failure.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add ELE APIs to support read and write shadow fuses
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
On iMX8ULP, the word index 1 is used to read OTP_UNIQ_ID with 4 words
data responsed. However this special index does not apply others.
So restrict the check to i.MX8ULP to avoid problem when reading from
fuse word 1 for others, such as i.MX93.
Also update header order
Signed-off-by: Peng Fan <peng.fan@nxp.com>
When OS is doing ELE API call, before OS get the response, OS is force
reseted, then it is possible that MU RR has data during initialization
in SPL stage. So clear the RR registers, otherwise SPL ELE API call will
work abnormal.
Cc: Alice Guo <alice.guo@nxp.com>
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The MU parameter register can provide the TR and RR number.
For i.MX95 which has 8 RR is different with i.MX93 and i.MX8ULP,
so update the driver to read the PAR for exact TR and RR number.
Also update compatible string for i.MX95 ELE MU.
Cc: Alice Guo <alice.guo@nxp.com>
Cc: Marek Vasut <marex@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Simon Glass <sjg@chromium.org> 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) && !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.
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.
Update the comment in bootstage to refer to this symbol, instead of
SPL_
Signed-off-by: Simon Glass <sjg@chromium.org>
The series "rockchip: Add efuse and otp support to more SoCs" [1],
merged in v2023.04, refactored and extended the Rockchip efuse and otp
driver to support reading eFUSE/OTP for all supported Rockchip SoCs.
Due to use of different licenses the drivers were never combined into a
single driver, however anything non SoC specific should be applied to
both drivers.
The commit fe38b88453 ("rockchip: Provided SPL control over efuse
presence") changed Makefile options for only one of the two drivers,
apply same change to keep these two drivers in sync.
[1] https://lore.kernel.org/r/20230222224436.1570224-1-jonas@kwiboo.se/
Fixes: fe38b88453 ("rockchip: Provided SPL control over efuse presence")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
This driver should not generally be present in SPL, even if misc devices
are enabled. Update the Makefile rule accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new ahab_derive command that derives the hardware unique key (HUK)
into a 16 or 32 bytes key and stores it at the given address.
Signed-off-by: Mathieu Othacehe <othacehe@gnu.org>
Reviewed-by: Ye Li <ye.li@nxp.com>
Port the RK3308 part of the Rockchip IO Domain driver from linux.
This differs from linux version in that vccio3 iodomain bit is enabled
in the write ops instead of in an init ops as in linux, this way we can
avoid keeping a full state of all supply that have been configured.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Port the PX30 part of the Rockchip IO Domain driver from Linux.
This differs from linux version in that the io iodomain bit is enabled
in the write ops instead of in an init ops as in linux, this way we can
avoid keeping a full state of all supplies that have been configured.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
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 <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
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 c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
The file include/eeprom.h is used only in some legacy non-DM I2C EEPROM
access cases. Remove most inclusions of this file as they are not
needed.
Signed-off-by: Tom Rini <trini@konsulko.com>
Port the RK3328 part of the Rockchip IO-domain driver from linux.
This differs from linux version in that pmu io iodomain bit is enabled
in the write ops instead of in an init ops as in linux, this way we can
avoid keeping a full state of all supply that have been configured.
Enable by default on all RK3328 boards, skip rk3328-evb because this
target is typically also used on miscellaneous boards and boxes not
fully supported by U-Boot.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Commit 3f190c55a4
("drivers: misc: Add socfpga_dtreg driver for Intel SoCFPGA")
This commit rename CONFIG_SPL_SOCFPGA_SEC_REG to CONFIG_SPL_SOCFPGA_DT_REG
in Makefile.
Signed-off-by: Wan Yee Lau <wan.yee.lau@intel.com>
Add support for true random number generator provided by the MCU on
Turris Omnia. The MCU firmware supports TRNG if the FEAT_TRNG bit is set
in features. In that case we bind the rng driver.
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Add support for system power off via UCLASS_SYSRESET. Newer versions of
Turris Omnia MCU firmware can power off the board (MCU will disable
almost all voltage regulators and go into low power mode).
Move the MCU driver into drivers/misc and register it under UCLASS_MISC.
The sysreset and gpio device are bound as child devices of the MCU device.
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
This message is used to commit into the fuses any new SRK revocation and
FW version information that have been found into the NXP (ELE FW) and
OEM containers.
Signed-off-by: Mathieu Othacehe <othacehe@gnu.org>
