| Age | Commit message (Collapse) | Author |
|---|
|
As exposed by "make randconfig", CPU_MICROBLAZE uses select to
force-enable XILINX_MICROBLAZE0_PVR, but that symbol depends on
TARGET_MICROBLAZE_GENERIC. The select bypasses this dependency chain,
triggering a Kconfig warning:
WARNING: unmet direct dependencies detected for XILINX_MICROBLAZE0_PVR
Depends on [n]: MICROBLAZE [=y] && TARGET_MICROBLAZE_GENERIC [=n]
Selected by [y]:
- CPU_MICROBLAZE [=y] && CPU [=y] && MICROBLAZE [=y]
Change XILINX_MICROBLAZE0_PVR from select to depends on, so that the
CPU driver is only available when PVR support has been explicitly
enabled.
Fixes: 816226d27efa ("cpu: add CPU driver for microblaze")
Reported-by: Tom Rini <[email protected]>
Signed-off-by: Michal Simek <[email protected]>
Link: https://lore.kernel.org/r/61ddd555f58ef5169c48b190423640d949e4aad1.1773764781.git.michal.simek@amd.com
|
|
This patch is used to add the imx type string of i.MX952 so that the
i.MX952 CPU info can be printed.
Signed-off-by: Alice Guo <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
Prepare v2026.04-rc4
|
|
Replace then -> they so that the sentence makes sense.
Signed-off-by: Hugo Villeneuve <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.
Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.
Reviewed-by: Patrice Chotard <[email protected]> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <[email protected]> #TI boards
Acked-by: Yao Zi <[email protected]> #TH1520
Signed-off-by: Peng Fan <[email protected]>
|
|
Linux kernel .get_temp() callback reports values in millicelsius,
U-Boot currently reports them in celsius. Align the two and report
in millicelsius. Update drivers accordingly. Update callsites that
use thermal_get_temp() as well.
The 'temperature' command now reports temperature in millicelsius
as well, with additional accuracy. This changes command line ABI
slightly.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: David Zang <[email protected]>
[trini: Update test/cmd/temperature.c]
Signed-off-by: Tom Rini <[email protected]>
|
|
Add a case for i.MX94 to return the correct string identifier in the
get_imx_type_str() function. This ensures proper CPU type reporting for
i.MX94 platforms.
Signed-off-by: Alice Guo <[email protected]>
|
|
Add setting default temperatures to the weak version of
get_cpu_temp_grade so these values will not be used uninitialised.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <[email protected]>
|
|
This patch is used to add the imx type string of i.MX95 ao that the
i.MX95 CPU info can be printed.
Signed-off-by: Alice Guo <[email protected]>
|
|
Much of the data that is display by imx8_cpu.c is also displayed from
arch/arm/mach-imx/cpu.c, except the temperature grade and active
temperature are only displayed when SoC is an i.MX9. Since IMX9 now
implies IMX_TMU, change this to check for IMX_TMU in the same way
it's done in mach-imx/cpu.c to enable displaying this information
for any SoC with either of this config enabled.
Since additional text may appear due to this commit, remove
the extra space in the message displaying the temperature
grade.
Before:
CPU: NXP i.MX8MP Rev1.1 A53 at 1200 MHz
Model: Beacon EmbeddedWorks i.MX8MPlus Development kit
After:
CPU: NXP i.MX8MP Rev1.1 A53 at 1200 MHz
CPU: Industrial temperature grade (-40C to 105C) at 28C
Model: Beacon EmbeddedWorks i.MX8MPlus Development kit
Signed-off-by: Adam Ford <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
The imx8_cpu is capable of running on IMX8, IMX8M, and IMX9
families, but the CPU list is limited on the 8M variants. Expand
this list to show more variants and their respective names.
Signed-off-by: Adam Ford <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
iMX91 is reduced part from iMX93 with part number: i.MX9131/11/01
It removed A55_1, M33, MIPI DSI, LVDS, etc.
i.MX9131:
- Support 2.4GT/s DDR and HWFFC at 1.2GT/s
i.MX9121:
- A55 at 800Mhz and DDR at 1600MTS, with low drive mode.
i.MX9111:
- Support 1.6GT/s DDR and HWFFC at 800MT/s
i.MX9101:
- Support 800Mhz ARM clock
- Support 1.6GT/s DDR and HWFFC at 800MT/s
- No parallel display, eQOS, flexcan
Updated Clock/Container/CPU and etc for i.MX91
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[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]
|
|
When ACPI is enabled over FDT the APs cannot be brought out of reset
by the OS using the "FDT spin-table" mechanism, as no FDT is provided
to the OS. The APs must be released out of reset in u-boot and then
brought up in an ACPI compliant fashion.
When ARMV8_MULTIENTRY is specified, the APs are released from reset
and will enter U-Boot after it has been relocated as well.
By default ARMV8_MULTIENTRY is not selected, keeping existing behaviour.
TEST: All APs enter U-Boot when run on qemu-system-aarch64 and on
real hardware.
Signed-off-by: Patrick Rudolph <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Cc: Matthias Brugger <[email protected]>
Cc: Peter Robinson <[email protected]>
Cc: Tom Rini <[email protected]>
|
|
Fill the MADT table in the GIC driver and armv8 CPU driver to
drop SoC specific code. While the GIC only needs devicetree
data, the CPU driver needs additional information stored in
the cpu_plat struct.
While on it update the only board making use of the existing
drivers and writing ACPI MADT in mainboard code.
TEST: Booted on QEMU sbsa-ref using GICV3 driver model generated MADT.
Booted on QEMU raspb4 using GICV2 driver model generated MADT.
Signed-off-by: Patrick Rudolph <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Cc: Simon Glass <[email protected]>
|
|
Add a generic driver that binds to armv8 CPU nodes. The generic driver allows
- to enumerate CPUs present in a system, even when no other driver binds it
- generates ACPI SSDT code for each CPU
- Fill the ACPI MADT table (implemented in a follow up patch)
The newly introduced code could also be reused on other CPU drivers that are
compatible with armv8.
TEST: Booted on QEMU sbsa and verify the driver binds to CPU nodes.
Confirmed with FWTS that all ACPI processor devices are present.
Signed-off-by: Patrick Rudolph <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Simon Glass <[email protected]>
|
|
U-Boot device tree is padded just after U-Boot proper.
After the whole stuff loaded to DRAM space, the device tree
area is conflict with BSS region before U-Boot relocation.
So any write to BSS area before reloc_fdt will corrupt the
device tree. Without the fix, there is issue that “binman_init
failed:-2” on i.MX8MP-EVK board.
Drop 'revision' and use malloc area in cpu_imx_plat->rev.
Signed-off-by: Peng Fan <[email protected]>
|
|
Add support for iMX93 low performance parts 9302 and 9301 which
restrict to low drive voltage only.
The parts run A55 max speed at 900Mhz and M33 at 133Mhz, have NPU
and A55 core1 (9301) disabled.
Reviewed-by: Peng Fan <[email protected]>
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Release the secondary cores through the PSCI request.
Signed-off-by: Hou Zhiqiang <[email protected]>
|
|
Add i.MX 8M Mini, Nano and Plus SoCs support.
Signed-off-by: Hou Zhiqiang <[email protected]>
|
|
Return CPU description string without newline character in the end.
Signed-off-by: Hou Zhiqiang <[email protected]>
|
|
Increase one more bit to cover all CPU types. Otherwise it shows
wrong CPU info on some platforms, such as i.MX8M Plus:
U-Boot 2024.04+g674440bc73e+p0 (Jun 06 2024 - 10:05:34 +0000)
CPU: NXP i.MX8MM Rev1.1 A53 at 4154504685 MHz at 30C
Model: NXP i.MX8MPlus LPDDR4 EVK board
Signed-off-by: Hou Zhiqiang <[email protected]>
|
|
The cpu_freq stores the current CPU frequency in Hz.
Signed-off-by: Hou Zhiqiang <[email protected]>
Reviewed-by: Michael Trimarchi <[email protected]>
|
|
Add empty release CPU core function for testing.
Signed-off-by: Hou Zhiqiang <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add a new callback release_core to the cpu_ops, which is used to
release a CPU core to run baremetal or RTOS application on a SoC
with multiple CPU cores.
Signed-off-by: Hou Zhiqiang <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Jiaxun Yang <[email protected]> says:
Hi all,
This series enabled qemu-xtensa board.
For dc232b CPU it needs to be built with toolchain[1].
This is a side product of me investigating architectures
physical address != virtual address in U-Boot. Now we can
get it covered under CI and regular tests.
VirtIO devices are not working as expected, due to U-Boot's
assumption on VA == PA everywhere, I'm going to get this fixed
later.
My Xtensa knowledge is pretty limited, Xtensa people please
feel free to point out if I got anything wrong.
Thanks
[1]: https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-dc232b-elf.tar.gz
|
|
Implement various CPU related functions.
I'm actually just using it to get cpu clock frequency.
Tested-by: Max Filippov <[email protected]>
Signed-off-by: Jiaxun Yang <[email protected]>
|
|
Raymond Mao <[email protected]> says:
This patch set is picked from the previously posted serie:
"[RFC] Integrate MbedTLS v3.6 LTS with U-Boot"
They are not directly related to MbedTLS integration, but the
prerequisite for a few clean-up, refactoring and minor fixes.
For V2, the linker script patch is dropped and added one patch
to move the snprintf to stdio.h
|
|
Move snprintf to stdio.h since it is needed by exteranl libraries.
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Ilias Apalodimas <[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]>
|
|
Without the NULL check, if the devicetree that u-boot loads does not have a
compatible property then a store access fault will be raised and force the
machine to reset, due to the NULL pointer we passed to strlen. This commit
adds this check and will return -ENOSPC to indicate the get_desc failed.
Signed-off-by: Hanyuan Zhao <[email protected]>
Reviewed-by: Leo Yu-Chi Liang <[email protected]>
|
|
Remove <common.h> from this driver directory and when needed
add missing include files directly.
Signed-off-by: Tom Rini <[email protected]>
|
|
This was wrongly committed, no user, remove it.
Signed-off-by: Peng Fan <[email protected]>
|
|
cpu_get_desc() for the RISC-V CPU currently reads "riscv,isa" to get
the description, but it is no longer a required property and cannot be
assummed to always be present, as the new "riscv,isa-extensions" and
"riscv,isa-base" properties may be present instead.
On RISC-V, cpu_get_desc() has two main uses - firstly providing an
informational name for the CPU for smbios or at boot with
DISPLAY_CPUINFO etc and secondly it forms the basis of ISA extension
detection in supports_extension() as it returns (a portion of) an ISA
string.
cpu_get_desc() returns a string, which aligned with "riscv,isa" but
the new property is a list of strings. Rather than add support for
the list of strings property, which would require creating an isa
string from "riscv,isa-extensions", modify the RISC-V CPU's
implementaion of cpu_get_desc() return the first compatible as the
cpu description instead. This may be fine for the informational cases,
but it would break extension dtection, given supports_extension()
expects cpu_get_desc() to return an ISA string.
Call dev_read_string() directly in supports_extension() to get the
contents of "riscv,isa" so that extension detection remains functional.
As a knock-on affect of this change, extension detection is no longer
broken for long ISA strings. Previously if the ISA string exceeded the
32 element array that supports_extension() passed to cpu_get_desc(),
it would return ENOSPC and no extensions would be detected.
This bug probably had no impact as U-Boot does not currently do anything
meaningful with the results of supports_extension() and most SoCs
supported by U-Boot don't have anywhere near that complex of an ISA
string. The QEMU virt machine's CPUs do however, so extension detection
doesn't work there.
Signed-off-by: Conor Dooley <[email protected]>
reviewed-by: Leo Yu-Chi Liang <[email protected]>
|
|
For RISC-V CPUs the SMBIOS Processor ID field contains
the Machine Vendor ID from CSR mvendorid.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
This function is a no-op. Remove it.
Signed-off-by: Sean Anderson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The SMBIOS specification requires to set the processor family in the type 4
(Processor Information) table to specific values depending only on the
bitness of the system (0x200 for RV32 and 0x201 for RV64).
With this patch dmidecode shows
Handle 0x0004, DMI type 4, 48 bytes
Processor Information
Socket Designation: Not Specified
Type: Central Processor
Family: RV64
for qemu-riscv64_smode_defconfig.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The last user of the NEEDS_MANUAL_RELOC has been removed in commit
26af162ac8f8 ("arch: m68k: Implement relocation")
Remove now unused NEEDS_MANUAL_RELOC code.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Very few of the existing event-spy records use the arguments they are
passed. Update them to use a simple spy instead, to simplify the code.
Where an adaptor function is currently used, remove it where possible.
Signed-off-by: Simon Glass <[email protected]>
|
|
According to datasheet, iMX93 has fused parts with CORE1 or NPU or
both disabled. So update code to support it, the kernel device tree
runtime update will be added in future patches.
Signed-off-by: Peng Fan <[email protected]>
|
|
Support print out cpu grade temperature
Signed-off-by: Peng Fan <[email protected]>
|
|
Use CONFIG_DM_THERMAL to make the temperature function could be reused
by i.MX8 and i.MX9
Signed-off-by: Peng Fan <[email protected]>
|
|
Add CPU_IMX Kconfig
Support imx8_cpu driver for i.MX9
Signed-off-by: Peng Fan <[email protected]>
|
|
For local functions, use static for function.
Signed-off-by: Peng Fan <[email protected]>
|
|
Move imx8 sci header file to include/firmware/imx, then we could
use build macro to reuse some i.MX8 drivers for i.MX9, such as
drivers/cpu/imx8_cpu.c.
Signed-off-by: Peng Fan <[email protected]>
Signed-off-by: Stefano Babic <[email protected]>
|
|
The original function was only called once, before relocation. The new
one is called again after relocation. This was not the intent of the
original call. Fix this by renaming and updating the calling logic.
With this, chromebook_link64 makes it through SPL.
Fixes: 7fe32b3442f0 ("event: Convert arch_cpu_init_dm() to use events")
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
The event framework is just that, a framework. Enabling it by itself
does nothing, so we shouldn't ask the user about it. Reword (and correct
typos) around this the option and help text. This also applies to
DM_EVENT and EVENT_DYNAMIC. Only EVENT_DEBUG and CMD_EVENT should be
visible to the user to select, when EVENT is selected.
With this, it's time to address the larger problems. When functionality
uses events, typically via EVENT_SPY, the appropriate framework then
must be select'd and NOT imply'd. As the functionality will cease to
work (and so, platforms will fail to boot) this is non-optional and
where select is appropriate. Audit the current users of EVENT_SPY to
have a more fine-grained approach to select'ing the framework where
used. Also ensure the current users of event_register and also select
EVENT_DYNAMIC.
Cc: AKASHI Takahiro <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Reported-by: Oliver Graute <[email protected]>
Reported-by: Francesco Dolcini <[email protected]>
Fixes: 7fe32b3442f0 ("event: Convert arch_cpu_init_dm() to use events")
Fixes: 42fdcebf859f ("event: Convert misc_init_f() to use events")
Fixes: c5ef2025579e ("dm: fix DM_EVENT dependencies")
Signed-off-by: Tom Rini <[email protected]>
Tested-by: Simon Glass <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Fabio Estevam <[email protected]>
|
|
We already have a function for probing all devices of a specific class,
use it.
Signed-off-by: Michal Suchanek <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
This function is also available as ofnode_is_enabled(), so use that
instead.
Signed-off-by: Simon Glass <[email protected]>
|
