| Age | Commit message (Collapse) | Author |
|---|
|
Simon Glass <[email protected]> says:
The current UPL spec[1] has been tidied up and improved over the last
year, since U-Boot's original UPL support was written.
This series includes some prerequisite patches needed for the real UPL
patches. It is split from [2]
[1] https://github.com/UniversalPayload/spec/tree/3f1450d
[2] https://patchwork.ozlabs.org/project/uboot/list/?series=438574&state=*
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
|
|
Raymond Mao <[email protected]> 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/[email protected]
|
|
Enable sysinfo smbios by default for arm64.
When SYSINFO_SMBIOS is enabled, disable QFW_SMBIOS.
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add support for Gateworks System Controller pre-scaled ADC input.
Signed-off-by: Tim Harvey <[email protected]>
|
|
Add support for Gateworks System Controller fan tach input.
Signed-off-by: Tim Harvey <[email protected]>
|
|
Aniket Limaye <[email protected]> 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/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Aniket Limaye <[email protected]>
Reviewed-by: Manorit Chawdhry <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Aniket Limaye <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Heiko Schocher <[email protected]>
Reviewed-by: Alexander Sverdlin <[email protected]>
Reviewed-by: Stefan Roese <[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]>
|
|
Manorit Chawdhry <[email protected]> says:
This series adds support for Adaptive voltage scaling on J721S2 device [0].
[0]: https://www.ti.com/lit/pdf/spruj28 (Section 5.2.4.1 AVS Support)
AVS Test for J721S2: https://gist.github.com/manorit2001/b2fd9f6764a863294d4aa0755c83c84f
Boot Test results: https://gist.github.com/manorit2001/d44e035552cb19aadeb0d928d5cb5f26
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Reviewed-by: Aniket Limaye <[email protected]>
|
|
Check if AVS could not be programmed and print a warning.
Fixes: 9d233b4e3ed6 ("misc: k3_avs: add driver for K3 Adaptive Voltage Scaling Class 0")
Reviewed-by: Udit Kumar <[email protected]>
Signed-off-by: Manorit Chawdhry <[email protected]>
Reviewed-by: Aniket Limaye <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add ELE APIs to support read and write shadow fuses
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Cc: Marek Vasut <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
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 <[email protected]>
Cc: Marek Vasut <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Ye Li <[email protected]>
|
|
Simon Glass <[email protected]> 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 <[email protected]>
|
|
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is
no-longer set.
Signed-off-by: Simon Glass <[email protected]>
|
|
Use the new symbol to refer to any 'SPL' build, including TPL and VPL
Signed-off-by: Simon Glass <[email protected]>
|
|
Rename this function to indicate that it refers to any xPL phase.
Signed-off-by: Simon Glass <[email protected]>
|
|
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 fe38b88453d2 ("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/[email protected]/
Fixes: fe38b88453d2 ("rockchip: Provided SPL control over efuse presence")
Signed-off-by: Jonas Karlman <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Ye Li <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
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 c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.
Reported-by: Jonas Karlman <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Remove <common.h> from this driver directory and when needed
add missing include files directly.
Signed-off-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
CONFIG_SPL_SOCFPGA_DT_REG
Commit 3f190c55a4211215914126b74357344342329943
("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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
|
|
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 <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-socfpga into next
- 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 <[email protected]>
Reviewed-by: Tien Fong Chee <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
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ś <[email protected]>
|
|
Fix the sleep function to issue the sleep command instead of idle one.
Signed-off-by: Michał Barnaś <[email protected]>
|
|
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ś <[email protected]>
|
|
Add implementation of sc_pm_reset_reason() call for obtaining
reset reason.
Signed-off-by: Igor Opaniuk <[email protected]>
|
|
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 <[email protected]>
|
