| Age | Commit message (Collapse) | Author |
|---|
|
During linux build process the header size is computed including the BSS
whereas it's removed when creating the uncompressed image. Therefore the
size of the uncompressed image on filesystem will be smaller than the
size specified in the header.
This causes issues when loading the kernel image from the SPL (as in
falcon boot) with spl_load since it compares the read file size from the
FS to the header size form the image. Which leads to the following check
in `include/spl_load.h` failing to -EIO when loading kernel image:
return read < spl_image->size ? -EIO : 0;
Therefore we should return the header size back to spl_load instead of
the file size in falcon boot when not loading a FIT image.
Bug report:
https://lore.kernel.org/u-boot/[email protected]/
Fixes: 775074165d97 ("spl: Add generic spl_load function")
Reported-by: Anshul Dalal <[email protected]>
Reviewed-by: Sean Anderson <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
|
|
CFG_SYS_SPI_* are used in falcon boot to specify the offsets and size of
the respective payloads. This patch moves them to Kconfig keeping the
values consistent for each of the affected boards.
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Fabio Estevam <[email protected]>
Signed-off-by: Anshul Dalal <[email protected]>
|
|
The first 4 block copy channels and rings on AM62P support
High Capacity Block Copy. These channels have approximately
3x improvement over the normal Block copy channels when doing
DDR-to-DDR copy.
Currently, during allocation these channels do not have a
separate interface and are allocated with normal BCDMA channels.
Latest TIFS and DM firmware adds support for differentiating these
High Capcity resources. This update is for allocating these new
resource type to different hosts with below mentioned scheme.
--------------------- --------------- ------------- ----------------
Resource A53_2 MCU_R5 WKUP_R5
--------------------- --------------- ------------- ----------------
BCDMA HC CHAN [4] => 2 (Primary) 1 (Primary) 1 (Primary)
BCDMA HC CHAN RING [4] => 2 (Primary) 1 (Primary) 1 (Primary)
BCDMA CHAN [4] => 18 (Primary) 2 (Primary) 6 (Primary)
BCDMA CHAN RING[4] => 18 (Primary) 2 (Primary) 6 (Primary)
Signed-off-by: Sparsh Kumar <[email protected]>
Signed-off-by: Sebin Francis <[email protected]>
Signed-off-by: Vishal Mahaveer <[email protected]>
|
|
Enable support for USB mass storage class (UMS) via USB0 instance of
USB on AM64x SoC. UMS allows USB host to access U-Boot block device
and enable file transfer.
Example usage of UMS command :
=> mmc list
mmc@fa10000: 0 (eMMC)
mmc@fa00000: 1
=> ums 0 mmc 1
UMS: LUN 0, dev mmc 1, hwpart 0, sector 0x0, count 0x3b72400
Signed-off-by: Hrushikesh Salunke <[email protected]>
|
|
There's no fan in MedisTek's reference design. Disable it for now.
Signed-off-by: Weijie Gao <[email protected]>
|
|
This patch adds pwm support for MediaTek MT7987 SoC.
Signed-off-by: Sam Shih <[email protected]>
Signed-off-by: Weijie Gao <[email protected]>
|
|
The reserved-memory node 'wmcpu-reserved@50000000' only applies to
linux kernel and is useless in u-boot.
Remove it in *-u-boot.dtsi to make this memory region usable.
Fixes: 2d6962e0618 (arm: mediatek: add support for MediaTek MT7987 SoC)
Signed-off-by: Weijie Gao <[email protected]>
|
|
While the dd command actually writes to the block device the truncate
command only updates the metadata (at least on ext4). This is faster and
reduces wear on the block device.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Caleb Connolly <[email protected]> says:
In Simon's series reworking autoprobe, a discussion came up about
DM_FLAG_PROBE_AFTER_BIND, specifically that it wasn't very clear where
this flag should be used.
This series implements my suggestions made there to clarify the use of
this flag, and fixup the two driver which erroneously apply it to their
driver struct (this does nothing).
Link: https://lore.kernel.org/u-boot/[email protected]/
Link: https://lore.kernel.org/r/[email protected]
|
|
Some drivers set DM_FLAG_PROBE_AFTER_BIND, this does nothing since it's
only every applied on a per-device basis.
Remove the flags.
Signed-off-by: Caleb Connolly <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Acked-by: Michal Simek <[email protected]>
|
|
The DM_FLAG_PROBE_AFTER_BIND flag only makes sense on a per-device
basis, however recently added documentation as well as some confused
drivers imply that it might be added to a driver definition, this does
nothing.
Clarify the new documentation and expand on the comment by the
definition to point people in the right direction.
Signed-off-by: Caleb Connolly <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Acked-by: Michal Simek <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-tegra into next
Ouya and Mocha were added around the same time SPL_HAVE_INIT_STACK was
introduced by Simon and therefore do not include this config option. It
is critical to add it before any defconfig resync, since the SPL_STACK
option will then be removed.
|
|
Mocha was added and tested right before this config option was added. Add
it to restore proper booting.
Fixes: d6a53f52 ("spl: Add an SPL_HAVE_INIT_STACK option")
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
Ouya was added and tested right before this config option was added. Add it
to restore proper booting.
Fixes: d6a53f52 ("spl: Add an SPL_HAVE_INIT_STACK option")
Signed-off-by: Svyatoslav Ryhel <[email protected]>
|
|
into next
More basic DBSC5 DRAM controller clean ups and improvements.
|
|
Pass DBSC5 udevice and MODEMR0 register values to board specific
function dbsc5_get_board_data(). The board specific implementation
of dbsc5_get_board_data() can return struct renesas_dbsc5_board_config
which matches the board based on the content of MODEMR0 or content
of DT accessible via the udevice.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Extract wait for completion code from dbsc5_send_dbcmd2() into
new separate function dbsc5_wait_dbwait(). This extracted code
can be used to implement MR register read in the future.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Update dbsc5_send_dbcmd2() such that it takes multiple parameters
instead of one magic register content value. These parameters are
used to form the same resulting register value internally in the
dbsc5_send_dbcmd2() function, but from well defined input constants.
The new input constants are the operation code, channel, rank, and
operation argument. The argument is operation code specific, therefore
it is still a 16-bit magic number, but the rest of the arguments are
now split up. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Remove leading space before dbsc5_ddr_setval_all_ch() , no functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Rename dbsc5_ddr_register_read() to dbsc5_ddr_register_mr27_mr57_read()
and dbsc5_ddr_register_set() to dbsc5_ddr_register_mr28_set() to make
it clear what those functions really do. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
|
into next
Assorted fixes, refactorings and additions that are ready, and shave
off some load from upcoming series'.
Improves MMC performance on D1/T113 (missed clock divider), enables
eMMC access on the H616 family (never worked, many thanks to Jernej for
the fix!), DRAM detection fixes for the H616 (now reportedly stable).
Some patches for the upcoming Allwinner A133 SoC support: a few
refactorings, plus the DM clock and pinctrl driver. The DRAM init
routines work, but need some more polishing, that also holds back the
actual enablement patch, which will hopefully follow for v2025.07 still.
Also some preparatory patches for the Allwinner A523 SoC support, for
now just to improve the FEL save/restore code. There will be more patches
coming up for this, ideally also in the coming cycle still.
Gitlab CI passed, and I booted that briefly on some boards.
|
|
Because the Allwinner BootROM always runs in AArch32, even on ARMv8 SoCs,
we need to switch to AArch64 first, but also need to save the CPU state,
when we later may need to return to the BootROM, for continuing with the
FEL USB protocol. This is done in 32-bit code, which we include into the
AArch64 boot assembly file as a series of .word directives, containing
the encoded AArch32 instructions. To be able to change and verify that
code, we also kept an assembly file with the respective 32-bit code, but
just for reference.
As this code is never compiled or assembled - it's just for
documentation - it became stale over time: we didn't really update this
along with the changes we made to the boot code. In particular the FEL
save code was completely missing.
Update that 32-bit assembly file, to match the current version used in
boot0.h, including the FEL save routine. Also update the build
instructions in the comments, to give people an actual chance to
assemble this code.
Signed-off-by: Andre Przywara <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
|
|
To be able to return to the BootROM when booting via the FEL USB
protocol, we need to save the CPU state very early, which we need to do
in the embedded AArch32 code. At the moment the pointer to the buffer for
that state is located *after* the code, which makes the PC relative
code fragile: adding or removing instructions will change the distance
to that pointer variable.
The "new" Allwinner A523 SoC requires more state to be saved (GICv3
system registers), but we must do that *only* on that SoC. Conditional
compilation sounds like the easiest solution, but would mean that the
distance to that pointer would change.
Solve this rather easily by moving the pointer to the *front* of the
code: we load that pointer in the first instructions, so the distance
would always stay the same. Later in the code we won't need PC relative
addressing anymore, so this code can grow or shrink easily, for instance
due to conditional compilation.
Signed-off-by: Andre Przywara <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
|
|
To return a 64-bit Allwinner chip back to the 32-bit BootROM code, we
have some embedded AArch32 code that restores the CPU state, before
branching back to the BootROM. At the moment the pointer to the buffer
with that state is located *after* the code, which makes the PC relative
code fragile: adding or removing instructions will change the distance
to that pointer variable.
The "new" Allwinner A523 SoC requires more state to be restored (GICv3
system registers), but we must do that *only* on that SoC. Conditional
compilation sounds like the easiest solution, but would mean that the
distance to that pointer would change.
Solve this rather easily by moving the pointer to the *front* of the
code: we load that pointer in the first instruction, so the distance
would always stay the same. Later in the code we won't need PC relative
addressing anymore, so this code can grow or shrink easily, for instance
due to conditional compilation.
Signed-off-by: Andre Przywara <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
|
|
Cards should always be reset and threshold set. This fixes eMMC on H616.
Signed-off-by: Jernej Skrabec <[email protected]>
[Andre: use macro-defined offsets to fix build on older SoCs]
Signed-off-by: Andre Przywara <[email protected]>
|
|
It turns out that checking just one write is not enough. Due to
unexplained reasons scan procedure detected double the size. By making
16 dword writes and comparisons that never happens.
New procedure is also inverted. Instead of writing two different values
to base address and some offset and then reading both and comparing
values, simplify this by writing pattern at the base address and then
search for this pattern at some offset.
Signed-off-by: Jernej Skrabec <[email protected]>
Tested-by: Ryan Walklin <[email protected]>
Reviewed-by: Andre Przywara <[email protected]>
|
|
Since there is quite a few possible DRAM configurations in terms of bus
width, rank and rows and columns count, size detection algorithm must be
very careful not to test combination which would be bigger than H616 is
actually capable of handling.
Ideally, we should always detect memory aliasing, even for 4 GB memory
size, which is the maximum amount of memory that H616 is capable of
handling. For this reason, we have to configure minimum amount of
supported rows when testing for columns and vice versa. This way test
code will never step out of 4 GB boundary.
While at it, check for 17 rows maximum. This aligns code with BSP DRAM
driver. There is probably no such configuration which would make sense
with 4 GB memory.
Signed-off-by: Jernej Skrabec <[email protected]>
Reviewed-by: Icenowy Zheng <[email protected]>
Reviewed-by: Andre Przywara <[email protected]>
|
|
The Allwinner A100 SoC has been around for a while, and has now seemingly
been replaced with its close sibling A133.
Add the required mapping between the pinmux group strings and their
respective mux value, as far as used by U-Boot proper. Linux has some
basic (clock and pinctrl) support for a while, so we can build on the
names already used there.
Signed-off-by: Andre Przywara <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
|
|
The Allwinner A100 SoC has been around for a while, and has now seemingly
been replaced with its close sibling A133.
Add support for the CCU, as far as used by U-Boot proper. Linux has some
basic (clock and pinctrl) support for a while, so we can already use the
existing binding headers.
Signed-off-by: Andre Przywara <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
|
|
Reorder the Kconfig defaults for the maximum SPL size, to make the
Allwinner specific values more readable and extensible: many older SoCs
need to be limited to 32KB, so make this the last ARCH_SUNXI entry, used
as a fallback unless explicitly overridden before.
Signed-off-by: Andre Przywara <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
|
|
Most Allwinner SoCs (used on 107 out of 172 boards) use a default CPU
frequency of 1008 MHz during the initial setup in the SPL.
Make this the fallback default, in case nothing else is selected, to
simplify the Kconfig stanza and make future additions easier.
Signed-off-by: Andre Przywara <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
|
|
Some of the X-Power AXP PMICs can be ordered with an alternative I2C
address, for instance an AXP717 could be shipped with address 0x34 or
with address 0x35. Similarly the AXP803 lists two possible addresses.
For DM (DT) based drivers this is no problem, but the Allwinner SPL
code relies on exactly one hardcoded address per PMIC so far.
Add a Kconfig variable that holds the I2C address used by the PMIC
accessed in the SPL, and provide the (mostly only one) supported address
as its default, for the PMICs we use. Boards using the other address
can easily set this in their defconfig.
This effectively moves the hardcoding from C code to Kconfig.
That enables to use the AXP717 on some boards with the new Allwinner
A523 chip, which use the other I2C address there.
Signed-off-by: Andre Przywara <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
The AXP803 has been around for about a decade now, but so far we didn't
need SPL support, since the DRAM rail was wired up correctly at reset.
Now some boards using the A133 SoC use the (compatible) AXP707 with DDR4
memory, which requires the SPL to set the required 1.1V voltage manually.
Add the descriptions for the DC/DC regulators of the AXP803, and enable
that when CONFIG_AXP803_POWER is enabled.
Signed-off-by: Andre Przywara <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
|
|
On the Allwinner D1/R528/T113-s3 SoCs (NCAT2) the factors encoded in
the PLL register describe the doubled clock rate, as in the other SoCs.
Correct for that by always dividing the calculated rate by 2, except on
the H6, where we need a divisor of 4 (no change here).
This corrects the PERIPH0 clock rate as read by the MMC driver, and
actually doubles the MMC performance on those NCAT2 chips.
Signed-off-by: Andre Przywara <[email protected]>
Reported-by: Kuba Szczodrzyński <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
On the Allwinner D1/R528/T113-s3 SoCs the MMC clock source selected by
mux value 1 is PLL_PERIPH0(1x), not (2x), as in the other SoCs.
But we have still the hidden divisor of 2 in the MMC mod clock, so
need to explicitly compensate for that on those SoCs.
This leads to the actually programmed clock rate to be double compared
to before, which increases the MMC performance on those SoCs.
Signed-off-by: Andre Przywara <[email protected]>
Reported-by: Kuba Szczodrzyński <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
The CHIP_DIP_SCAN configuration option
is relevant only to ARCH_SUNXI.
Make CHIP_DIP_SCAN dependent
on ARCH_SUNXI so that it does not show up on other goals.
Signed-off-by: Liya Huang <[email protected]>
Reviewed-by: Andre Przywara <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-tegra into next
- More Tegra video improvements
|
|
https://source.denx.de/u-boot/custodians/u-boot-tpm into next
When trying to boot an OS installer or a live image via EFI HTTP the
following happens
- U-Boot downloads the image and mounts it in memory
- The EFI subsystem is invoked and the image is started
- The OS calls ExitBootServices and the memory that holds the mounted
image might get overwritten
This results in installers complaining that they can't find installer
medium or live images complaining they can't find the root filesystem.
ACPI already deals with it by having NFIT and NVDIMM to provide ramdisks
that need to be preserved by the OS. Linux and device trees have support
for persistent memory devices (pmem).
We can use them and inject a pmem node in the DT to preserve memory across the
entire boot sequence. Linux will just create a block device over the reserved
memory and installers/images can re-discover it.
This is what it looks like from the OS perspective:
nd_pmem namespace0.0: unable to guarantee persistence of writes
pmem0: p1 p2 p3
EXT4-fs (pmem0p3): mounted filesystem f40f64a4-5b41-4828-856e-caaae2c1c2a0 r/w with ordered data mode. Quota mode: disabled.
EXT4-fs (pmem0p3): re-mounted f40f64a4-5b41-4828-856e-caaae2c1c2a0 r/w. Quota mode: disabled.
Adding 45052k swap on /dev/pmem0p2. Priority:-2 extents:1 across:45052k SS
root@genericarm64:~# mount | grep pmem
/dev/pmem0p3 on / type ext4 (rw,relatime)
/dev/pmem0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
It's worth noting that Linux behaves differently with reserved memory
(at least on arm64) and that depends on kernel config options.
CONFIG_ZONE_DEVICES and CONFIG_ARM64_PMEM are such options. It boils down to
how the kernel tries to map pages. If devm_memremap_pages() gets called instead
of devm_memremap() mapping the memory fails.
The only safe way is to remove the memory from the EFI memory map,
rather than defining it as /reserved no-map;/ in the DT.
|
|
Commit 56f186a68b3 ("lmb: check if a region can be reserved by
lmb_reserve()") fixed the lmb_reserve() and lmb_alloc_addr() API's for
some corner case scenarios, and also added corresonding test cases for
these corner cases. These tests were checking, among other things, the
lmb_alloc_addr() API. The above commit was applied to the next branch.
Subsequently, there was commit 67be24906fe
("lmb: change the return code on lmb_alloc_addr()") which was first
applied on the master branch, and subsequently got merged to next as
part of the rebase. The second commit changes the return value of the
lmb_alloc_addr() API, which now results in some of the tests added as
part of the first commit to fail. Fix those test cases.
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
The EFI HTTP boot puts the ISO installer image at some location in
memory. Information about this image has to be passed on to the OS
kernel, which is done by adding a persistent memory(pmem) node to the
devicetree(DT) that is passed to the OS. The OS kernel then gets
information about the presence of this ISO image and proceeds with the
installation.
In U-Boot, this ISO image gets mounted as a memory mapped blkmap
device slice, with the 'preserve' attribute. Add a helper function
which iterates through all such slices, and invokes a callback. The
callback adds the pmem node to the DT and removes the corresponding
memory region from the EFI memory map. Invoke this helper function as
part of the DT fixup which happens before booting the OS.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Tobias Waldekranz <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Some blkmap memory mapped devices might have to be relevant even
after U-Boot passes control to the next image as part of the platform
boot. An example of such a mapping would be an OS installer ISO image,
information for which has to be provided to the OS kernel. Use the
'preserve' attribute for such mappings. The code for adding a pmem
node to the device-tree then checks if this attribute is set, and adds
a node only for mappings which have this attribute.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Tobias Waldekranz <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Add information about the type of blkmap slices as an attribute in the
corresponding slice structure. Put information in the blkmap slice
structure to identify if it is associated with a memory or linear
mapped device. Which can then be used to take specific action based on
the type of the blkmap slice.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Tobias Waldekranz <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
ACPI has NFIT and NVDIMM support to provide ramdisks to the OS. Linux
and device trees have support for persistent memory(pmem) devices. The
firmware can then add a pmem node for the region of memory occupied by
the ramdisk when passing the device-tree to the OS.
It's worth noting that for linux to instantiate the /dev/pmemX device,
the memory described in the pmem node has to be omitted from the EFI
memory map we hand over to the OS if ZONE_DEVICES and SPARSEMEM is
enabled. With those enabled the pmem driver ends up calling
devm_memremap_pages() instead of devm_memremap(). The latter works
whether the memory is omitted or marked as reserved, but mapping pages
only works if the memory is omitted.
On top of that, depending on how the kernel is configured, that memory
area must be page aligned or 2MiB aligned. PowerPC is an exception here
and requires 16MiB alignment, but since we don't have EFI support for
it, limit the alignment to 2MiB.
Ensure that the ISO image is 2MiB aligned and remove the region
occupied by the image from the EFI memory map.
Signed-off-by: Sughosh Ganu <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
With upcoming changes supporting pmem nodes, we need to remove the
pmem area from the EFI memory map. Rename efi_add_memory_map_pg() to
efi_update_memory_map(), and allow removing memory from the EFI memory
map.
Signed-off-by: Sughosh Ganu <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
One of the problems an OS may face, when running in EFI, is that
a mounted ISO, after calling ExitBootServices goes away, if that ISO
is resident in RAM memory as a ramdisk.
ACPI has NFIT and NVDIMM support to provide ramdisks to the OS, but we
don't have anything in place for DTs. Linux and device trees have support
for persistent memory devices. So add a function that can inject a pmem
node in a DT, so we can pass information on the ramdisk the OS.
Signed-off-by: Masahisa Kojima <[email protected]>
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
The efi_install_fdt() function is called before booting an EFI binary,
either directly, or through a bootmanager. This function installs a
copy of the device-tree(DT) on the EFI configuration table, which is
passed on to the OS.
The current logic in this function does not install a DT if a
device-tree is already installed as an EFI configuration
table. However, this existing copy of the DT might not be up-to-date,
or it could be a wrong DT for the image that is being booted. Always
install a DT afresh to the configuration table before booting the EFI
binary.
Installing a new DT also involves some additional checks that are
needed to clean up memory associated with the existing DT copy. Check
for an existing copy, and free up that memory.
Signed-off-by: Sughosh Ganu <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
There is logic in the copy_fdt() function which is iterating over the
platform's DRAM banks and setting the fdt_ram_start variable. However,
this variable is not used subsequently in the function. Remove this
superfluous code.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
https://gitlab.denx.de/u-boot/custodians/u-boot-imx into next
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/25324
- Imply the i.MX thermal driver by default on imx8, imx9, imx8m.
- Add clk_resolve_parent_clk() and fix up iMX clock drivers.
|
|
into next
CI: https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/25323
- board: k1: Add reset driver
- board: starfive: Simplify binman config
- Some modifications on DTS and configs
|
|
The imx8_cpu driver is a CPU Driver that supports the i.MX9
family to display the CPU type, temperature grade and
current operating temperature. The older file,
arch/arm/mach-imx/cpu.c, does not support i.MX9, so this config
is enabled in various IMX9 boards. Instead of having this option
enabled in every IMX9, select this driver by default for the
platform.
Signed-off-by: Adam Ford <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
