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>
- A new driver in the misc to register setting from device tree. This
also provides user a clean interface and all register settings are
centralized in one place, device tree.
- Enable Agilex5 platform for Intel product. Changes, modification and
new files are created for board, dts, configs and makefile to create
the base for Agilex5.
Build-tested on SoC64 boards, boot tested on some of them.
Add socfpga_dtreg driver enablement for Intel SoCFPGA.
Signed-off-by: Wan Yee Lau <wan.yee.lau@intel.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@intel.com>
Port the RK3399 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.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The ATSHA204A chip requires SDA line to go low for at least 60us to
wake up the chip. Previous implementation did not meet this requirement
due to the NAK received on bus and not sending the zeroes.
The function to ignore the NAK and send bytes regardless is not
supported in the u-boot making it impossible to wake up the chip
this way.
Instead, the bus speed, if needed, is set to lowest value and the
message is sent to the address 0x0. This way, the address of zero
makes the SDA line go low for about 80us, meeting the required time
to wake up the chip. The zero length packet is not sent by the i2c,
so the one byte is sent to the transfer function, but only the address
is sent anyway.
After sending the zero address, the bus speed is restored to the
previous value if it was slowed down to wake up the chip.
Signed-off-by: Michał Barnaś <barnas@google.com>
Some previous commit changed the continue statement to return,
making the for loop used to retry waking up the chip to always
return after one iteration. This commit removes the loop, cleaning
the code a little.
Signed-off-by: Michał Barnaś <barnas@google.com>
In the SMBIOS 3 entry point the Structure Table Maximum Size field was
incorrectly named max_struct_size. A Maximum Structure Size field only
exists in the SMBIOS 2.1 entry point and has a different meaning.
Call the Structure Table Length field table_maximum_size.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The current code convert the SMBIOS 2.1 entry point structure to
SMBIOS 3.0 entry point structure. The max_struct_size member in
SMBIOS 2.1 entry point structure indicates
"Size of the largest SMBIOS structure, in bytes".
We need to use struct_table_length instead.
Fixes: 1c5aab803c ("smbios: copy QEMU tables")
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
QEMU provides SMBIOS tables with detailed information. We should not try to
replicate them in U-Boot.
If we want to inform about U-Boot, we can add a Firmware Inventory
Information (type 45) table in future.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
commit 1b15483deb ("misc: add Qualcomm GENI SE QUP device driver")
introduced support for platform-specific oversampling values, necessary
to configure the UART clocks on all platforms at runtime. However it
relies in probing a parent device. Despite the DM_FLAG_PRE_RELOC flag,
this is not done consistently during boot.
Instead, take another approach by relying on ofnode_ helpers to read the
serial engine base address and do the read directly. This fixes early
UART on boards with a non-default oversampling rate.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Invoke write_acpi_tables() via EVT_LAST_STAGE_INIT on QEMU except on X86.
X86 calls write_acpi_tables() in write_tables().
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move the code related to copying tables from QEMU to a separate code
module.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
