| Age | Commit message (Collapse) | Author |
|---|
|
Vishal Mahaveer <[email protected]> says:
Collecting SYSFW traces from DMSC firmware is broken on the current
codebase. These changes enables MAIN_UART1 for collecting SYSFW traces
when the trace option is enabled in the boardcfg.
Link: https://lore.kernel.org/r/[email protected]
|
|
Enable MAIN UART1 in the R5 SPL device tree to collect system SYSFW
debug traces during early boot.
Signed-off-by: Vishal Mahaveer <[email protected]>
Reviewed-by: Bryan Brattlof <[email protected]>
|
|
The upstream device tree changed the serial alias for MAIN UART1 from
serial3 to serial1. Update the board initialization code to match this
change by modifying the UCLASS_SERIAL sequence number lookup.
This ensures proper pin control configuration for the UART used by
system firmware (SYSFW).
Signed-off-by: Vishal Mahaveer <[email protected]>
Fixes: d2edabfa8de5 ("arm: mach-k3: am642: Load SYSFW binary and config from boot media")
Reviewed-by: Bryan Brattlof <[email protected]>
|
|
The commit 55a342176984 ("common: Add an option to relocate on ram top")
changed so that dram_init_banksize() is called before gd->ram_top has
been initialized. This change broke Rockchip DRAM banks configuration
due to gd->ram_top now being 0 when dram_init_banksize() is called.
This makes first DRAM bank size calculation overflow and end up with
DRAM bank = 0x0000000000000000
-> start = 0x0000000000200000
-> size = 0xffffffffffe00000
instead of the expected (for 2 GiB)
DRAM bank = 0x0000000000000000
-> start = 0x0000000000200000
-> size = 0x000000007fe00000
or (for 4 GiB)
DRAM bank = 0x0000000000000000
-> start = 0x0000000000200000
-> size = 0x00000000f7e00000
on e.g. RK3399 boards.
Change to not depend on gd->ram_top having to be pre-calculated before
dram_init_banksize() is called, also move the related method
board_get_usable_ram_top() closer to more easily get an overview of
their interdependence, to restore working DRAM bank initialization.
Fixes: 55a342176984 ("common: Add an option to relocate on ram top")
Signed-off-by: Jonas Karlman <[email protected]>
Reported-by: Ilias Apalodimas <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]> # on Radxa ROCK
|
|
Ryan Chen <[email protected]> says:
AST2700 is the 8th generation of Integrated Remote Management
Processor introduced by ASPEED Technology Inc. It is a Board
Management Controller (BMC) SoC family with a dual-die architecture:
SoC0 ("CPU" die with four ARM Cortex-A35 application cores) and
SoC1 ("IO" die with peripherals) each SoC have its own SCU PLLs,
clock dividers and reset domains.
Link: https://lore.kernel.org/r/[email protected]
|
|
Set the acpi_ops structure as static const where applicable. The
The structure is not accessible from outside of drivers and is not
going to be modified at runtime. The structure may be unused in a
couple of drivers depending on their configuration, mark those
sites with __maybe_unused .
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add a SDRAM controller driver for the AST2700, derived from the
existing AST2700 controller code used by the Ibex SPL but adapted
to run from ARM U-Boot proper on the Cortex-A35 cores.
The DDR4/DDR5 controller and its DesignWare PHY are programmed by
the Ibex SPL before ARM U-Boot proper takes over. This driver
reads back the configuration left by the SPL, probes the
controller, and exposes ram_info (base and size, with the VGA
carve-out subtracted) via UCLASS_RAM so that dram_init() can
populate gd->ram_size.
The PHY firmware-load entry points (dwc_ddrphy_phyinit_userCustom_*)
are kept compiled but call a __weak fmc_hdr_get_prebuilt() stub
when ARM U-Boot proper is the caller; the real implementation is
provided by the Ibex SPL via the same fmc_hdr.h descriptor format
(here added for the ARM build).
Adds the supporting register-layout headers under
arch/arm/include/asm/arch-aspeed/:
- sdram.h: SDRAM controller and DWC PHY register definitions
- scu.h: SCU bits referenced by the SDRAM driver
- fmc_hdr.h: prebuilt-blob descriptor (binary-compatible with
arch/riscv/include/asm/arch-ast2700/fmc_hdr.h used
by the Ibex SPL)
Signed-off-by: Ryan Chen <[email protected]>
|
|
Add initial device tree support for the ASPEED AST27xx family, the
8th-generation Baseboard Management Controller (BMC) SoCs.
AST27xx SOC Family
- https://www.aspeedtech.com/server_ast2700/
- https://www.aspeedtech.com/server_ast2720/
- https://www.aspeedtech.com/server_ast2750/
The AST27xx features a dual-SoC architecture consisting of two ties,
referred to as SoC0 and SoC1 - interconnected through an internal
property bus. Both SoCs share the same address decoding scheme,
while each maintains independent clock and reset domains.
- SoC0 (CPU die): contains a dual-core Cortex-A35 cluster and two
Cortex-M4 cores, along with high-speed peripherals.
- SoC1 (I/O die): includes the BootMCU (responsible for system
boot) and its own clock/reset domains low-speed peripherals.
The device tree describes the SoC0 and SoC1 domains and their peripheral
layouts.
Signed-off-by: Ryan Chen <[email protected]>
|
|
Add initial support for the ASPEED AST2700, an arm64 (Cortex-A35)
Baseboard Management Controller (BMC) SoC. AST2700 is Aspeed's 8th
generation BMC and uses a dual-die architecture: SoC0 (the "CPU"
die) hosts the four Cortex-A35 cores and its own SCU at 0x12c02000,
while SoC1 (the "IO" die) hosts the peripherals and its own SCU at
0x14c02000.
This commit adds:
- ASPEED_AST2700 Kconfig option and the ast2700 mach subdir
(mach Makefile, ast2700/Kconfig, board/aspeed/evb_ast2700/*)
- arm64 MMU map covering the SoC device window and the DRAM
region at 0x4_0000_0000 (up to 8 GiB)
- lowlevel_init.S for early CPU bring-up
- cpu-info: print SoC ID (AST2700/2720/2750 A0/A1/A2 variants)
and reset cause (cold reset, EXT reset, WDT reset)
- board_common: dram_init via UCLASS_RAM, AHBC timeout init
- platform: env_get_location() that selects SPI/eMMC based on
the IO-die HW strap; arch_misc_init() that exposes
${boot_device} and ${verify} to the boot script
- SCU0/SCU1 register layout header (scu_ast2700.h)
- configs/evb-ast2700_defconfig and include/configs/evb_ast2700.h
for the AST2700 EVB board
The defconfig depends on ast2700-evb.dts, which is introduced in
a subsequent patch; this commit must be applied with the
remaining series for evb-ast2700_defconfig to build.
Signed-off-by: Ryan Chen <[email protected]>
|
|
Add v2x_status and ele_info commands to print useful information
for development and debug purpose.
Signed-off-by: Ye Li <[email protected]>
|
|
Add V2X Get State API to return V2X states for debug purpose
Signed-off-by: Ye Li <[email protected]>
|
|
The LDB clock sources don't have to be the same, so allow DI1 clock to
be configured separately.
Unlikely to be significant, but the reason will become apparent in the
following commit.
Signed-off-by: Brian Ruley <[email protected]>
|
|
During development or various dangerous experiments, it may
be necessary to override the trip points. Allow users to do
that. However, do keep in mind that this may damage the SoC.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Add initial U-Boot support for Aquila iMX95 SoM.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Signed-off-by: Franz Schnyder <[email protected]>
Reviewed-by: Francesco Dolcini <[email protected]>
|
|
OPTEE-OS starts correctly when "opteed" is enabled for Secure Payload
Dispatcher in TF-A (tested on OP-TEE version: 4.9.0), however imx93
devices require a patch for OPTEE targets because binman does not see
the tee.bin file when it is available.
Enable conditional OPTEE support for imx93 devices.
Signed-off-by: Krzysztof Drobiński <[email protected]>
Signed-off-by: Mathieu Dubois-Briand <[email protected]>
|
|
Enable the live DT to reduce the DT parsing time.
Test data on i.MX95-EVK:
Before:
Accumulated time:
26,205 dm_spl
483,991 dm_f
22,977 dm_r
After:
Accumulated time:
26,229 dm_spl
484,772 dm_f
2,667 of_live
1,003 dm_r
Signed-off-by: Peng Fan <[email protected]>
|
|
Use livetree API, otherwise it will fail to read properties from the device
tree when OF_LIVE is enabled.
Signed-off-by: Peng Fan <[email protected]>
|
|
Update to latest ddr firmware name, otherwise user may use legacy ddr
firmware from linux-firmware-imx release.
Signed-off-by: Peng Fan <[email protected]>
|
|
When CONFIG_CPU is enabled, print_cpuinfo is defined in common/board_f.c
with static property. However in imx cpu.c, print_cpuinfo is not a local
function, so guard it with !CONFIG_IS_ENABLED(CPU).
And all i.MX8M boards has CONFIG_CPU and CONFIG_CPU_IMX set, so remove the
dead code.
However legacy print_cpuinfo also print reset reason, to keep reset
reason printed as before, export get_reset_reason() and invoke it
at arch_misc_init().
Signed-off-by: Peng Fan <[email protected]>
|
|
There is only one SoC and no external user of get_imx_type for i.MX7ULP,
so directly embed the string in print_cpuinfo and drop get_imx_type().
Signed-off-by: Peng Fan <[email protected]>
|
|
There is only one SoC and no external user of get_imx_type for i.MX8ULP,
so directly embed the string in print_cpuinfo and drop get_imx_type().
Signed-off-by: Peng Fan <[email protected]>
|
|
Same to 85319b2e672 ("board: toradex: smarc-imx95: remove gpio1 reg"),
there is no need to use dual base for i.MX952 gpio, so drop the U-Boot
specific reg changes.
Signed-off-by: Peng Fan <[email protected]>
|
|
CONFIG_IMX_TMU depends on CONFIG_DM_THERMAL, so when selecting IMX_TMU,
DM_THERMAL should also be selected.
Update i.MX8M based defconfigs.
Signed-off-by: Peng Fan <[email protected]>
Acked-by: Francesco Dolcini <[email protected]>
|
|
Restyle all Kconfigs other then "arm":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Restyle all Kconfigs for "arm":
Menu entries : no space left
Menu attributes: 1 TAB
Help text : 1 TAB + 2 spaces
Replace '---help---' by 'help'
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
While restyling Kconfig the script checkpatch.pl gives
this info:
WARNING: 'Enble' may be misspelled - perhaps 'Enable'?
Fix by changing 'Enble' to 'Enable'.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
While restyling Kconfig the script checkpatch.pl gives
this info:
WARNING: 'suppport' may be misspelled - perhaps 'support'?
Fix by changing 'suppport' to 'support'.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Currently, the bi_dram[] information is stored in the board info
structure (bd). Because bd is only valid after reserve_board(),
dram_init_banksize() must be called late in the initialization process.
This limitation is problematic, as it forces us to rely on a variety of
bespoke functions to determine board RAM, bank memory sizes, and other
early setup requirements.
By moving bi_dram[] into the global data (gd), we can run it earlier.
This is particularly convenient since boards define their own
dram_init_banksize() routines, which do not always rely on parsing
Device Tree (DT) memory nodes.
Additionally, U-Boot defaults to relocating to the top of the first memory
bank. While boards currently use custom functions to override this
behavior, having the DRAM bank information available earlier in gd makes
relocating to a different bank trivial and standardizes the process.
Reviewed-by: Anshul Dalal <[email protected]>
Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385
Tested-by: Anshul Dalal <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
|
|
Prepare v2026.07-rc5
|
|
Francesco Valla <[email protected]> says:
This patch set contains a collection of small fixes and cleanups for the
"full" FIT loader that can be used for the SPL. The main beneficiary is
the falcon boot flow, but the same loader can be used also for U-Boot
proper.
Patch 1 was part of another set, but I decided to put it here for a
better separation between plumbing (here) and new features (there). I
kept the Reviewed-by tag collected from Simon in that occasion.
Patch 6 introduces a new unit test covering most of the code that is
being cleaned up.
The set was tested on a i.MX93 FRDM, both with and without signature and
to boot both U-Boot proper and the Linux kernel directly (i.e., falcon
boot).
Link: https://lore.kernel.org/r/[email protected]
|
|
Following what is already done for the "simple" FIT loader, add a unit
test for the "full" loader.
Signed-off-by: Francesco Valla <[email protected]>
|
|
set_one_region()"
Casey Connolly <[email protected]> says:
Currently trying to unmap a region results in slow and largely broken
behaviour as we unnecessarily split blocks and manually set thousands of
individual 4k pages instead of higher level blocks.
This series fixes the behaviour of set_one_region() so that it works
properly when called to unmap regions. See patch 4 for details.
Patches 1 & 2 improve the existing debug functionality, the pagetable
dumper will now print most explicitly unmapped regions (since they still
have their PA intact), as well as adding a new function which does a
very basic software TLB lookup to help with debugging.
Patch 3 de-duplicates some code by moving the loop that always surrounds
set_one_region() calls into its own function, this also helps with
readability in the calling functions.
Link: https://lore.kernel.org/r/[email protected]
|
|
As more platforms start ensuring they explicitly unmap reserved-memory
regions a few issues have appeared with how the existing dynamic mapping
code works. Fix these and get a small optimisation as well.
1. Teach pte_type() to actually respect the PTE_TYPE_VALID bit
2. Don't walk the TLB a second time if we call mmu_change_region_attr()
with PTE_TYPE_FAULT (since it would just be a slow nop)
3. Fix how set_one_region() decides to split blocks.
Today set_one_region() will always split blocks until it reaches the
smallest granule size (4k) and then update all of these pages. This
appears to be due to a big in how is_aligned() is implemented, since
it only evaluates to true if addr and size are both multiples of the
current granule size, so a mapping aligned to 2M which is 4M in size
will cleanly result in 2 blocks being set, but a mapping aligned to
2M which is 4M + 8k in size will result in blocks being split and 1026
individual pages being set.
While for the address it is correct to enforce that it is aligned to
the current granule size, we only need to check if the region size is
greater than the current granule size. This allows us to simplify our
second example above to only 4 entries being updated (assuming no blocks
have to be split) since we only need to update 2 blocks to map the first
4M, drastically improving the best-case performance.
In the case where the address is 4k aligned rather than 2M aligned we
will still be restricted to mapping 4k pages until we reach 2M alignment
where we could then map a larger 2M granule which previously would never
happen.
Signed-off-by: Casey Connolly <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
This loop is duplicated 3 times, put it into its own function and call
it instead. This simplifies the logic in a few functions.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Casey Connolly <[email protected]>
|
|
When a region is explicitly unmapped (like with
mmu_change_region_attr(.... PTE_TYPE_FAULT)) the address translation
still remains but won't be used since the region is marked invalid.
Print these regions when we dump the pagetable to help with debugging.
Signed-off-by: Casey Connolly <[email protected]>
|
|
Implement a super basic software TLB walk which can look up a single
address in the TLB and print each stage of the translation. This is
helpful for debugging TLB issues and will be compiled out if unused.
Example output on QEMU aarch64:
Performing software TLB lookup of address 0x50100000 va_bits: 40
PTE: 0x47fe0000. addr[47:39]: 0x000 (offset 0x00000)
L0: 0x47fe0000 -> TABLE (0x47fe1000)
PTE: 0x47fe1000. addr[38:30]: 0x001 (offset 0x00008)
L1: 0x47fe1008 -> BLOCK (0x40000000)
[0x40000000 - 0x80000000]
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Casey Connolly <[email protected]>
|
|
Bastien Curutchet <[email protected]> says:
This series aims to add back the omap4 support. This support was removed
by commit b0ee3fe642c ("arm: ti: Remove omap4 platform support") because
at that moment, none of the OMAP4-based boards had done the migration to
DM_I2C.
My use case is an old product based on the Variscite's omap4 system on
module. I needed to upgrade U-Boot on it for security reasons. I think
that this work could benefit to other people who may have same kind of
product to maintain.
Patch 1 to 3 remove the omap's clock driver dependency to the AM33xx
as it is also present in omap4 platforms. I tested these changes on the
beaglebone black to ensure I didn't break the AM33xx case.
Patch 4 & 5 revert the deletion of the omap4 support. The revert makes
checkpatch.pl angry. I fixed quite a lots of warnings already but it
remains two kinds of warnings:
- CamelCase on timings structure, I left the CamelCase because IMHO it's
more readable this way.
- #ifdef CONFIG_XYZ shouldn't be used anymore. I left one of this because
I didn't find a clean way to get rid of it.
Patch 6 adds support for the Variscite's system on module. This system on
module is supported by the Linux project through
ti/omap/omap4-var-som-om44.dtsi
Link: https://lore.kernel.org/r/[email protected]
|
|
OMAP4 support is present but there isn't any board using it.
Add minimal support for the Variscite OMAP4-SoM (debug console + boot
from SD card).
Use the ti/omap/omap4-var-stk-om44 device-tree from the Linux kernel. The
real representation of the SoM's hardware is located in
ti/omap/omap4-var-som-om44.dtsi included in it.
Set myself as maintainer for it.
Signed-off-by: Bastien Curutchet <[email protected]>
|
|
omap4 support was dropped by b0ee3fe642c ("arm: ti: Remove omap4 platform
support") because the supported boards hadn't done the conversion to
CONFIG_DM_I2C in time. It still exists some omap4-based products and
they could benefit from the latest U-Boot support for obvious security
reasons.
Revert part of b0ee3fe642c to introduce back a minimal support for the
omap4 platform.
Fix the checkpatch's warning/errors induced by this revert. Following
warnings are still present:
| arch/arm/include/asm/arch-omap4/clock.h:445: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
| arch/arm/mach-omap2/omap4/hwinit.c:24: WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible
| arch/arm/mach-omap2/omap4/sdram_elpida.c:142: CHECK: Avoid CamelCase: <tRPab>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:143: CHECK: Avoid CamelCase: <tRCD>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:144: CHECK: Avoid CamelCase: <tWR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:145: CHECK: Avoid CamelCase: <tRASmin>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:146: CHECK: Avoid CamelCase: <tRRD>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:147: CHECK: Avoid CamelCase: <tWTRx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:148: CHECK: Avoid CamelCase: <tXSR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:149: CHECK: Avoid CamelCase: <tXPx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:150: CHECK: Avoid CamelCase: <tRFCab>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:151: CHECK: Avoid CamelCase: <tRTPx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:152: CHECK: Avoid CamelCase: <tCKE>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:153: CHECK: Avoid CamelCase: <tCKESR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:154: CHECK: Avoid CamelCase: <tZQCS>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:155: CHECK: Avoid CamelCase: <tZQCL>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:156: CHECK: Avoid CamelCase: <tZQINIT>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:157: CHECK: Avoid CamelCase: <tDQSCKMAXx2>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:158: CHECK: Avoid CamelCase: <tRASmax>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:159: CHECK: Avoid CamelCase: <tFAW>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:209: CHECK: Avoid CamelCase: <tRL>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:210: CHECK: Avoid CamelCase: <tRP_AB>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:213: CHECK: Avoid CamelCase: <tRAS_MIN>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:215: CHECK: Avoid CamelCase: <tWTR>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:216: CHECK: Avoid CamelCase: <tXP>
| arch/arm/mach-omap2/omap4/sdram_elpida.c:217: CHECK: Avoid CamelCase: <tRTP>
I didn't find an clean way to fix the "don't use #ifdef" warning as we
need to define the gpio_bank for the SPL build only.
For the CamelCase warnings, the incriminated attributes represent
timings, so IMHO, it is more readable with CamelCase.
Set myself as OMAP4 maintainer.
Signed-off-by: Bastien Curutchet <[email protected]>
|
|
Lots of clock definitions are common to OMAP3, OMAP4 and OMAP5. So the
same macros are defined both in arch-am33xx/clock.h and in
arch-omap5/clock.h. Upcoming support for OMAP4 will again need the same
macros.
Group these common macro definitions into a common omap_clock header
shared across the OMAP2+ families.
Signed-off-by: Bastien Curutchet <[email protected]>
|
|
PRM_VC_I2C_CHANNEL_FREQ_KHZ is defined in omap5/clock.h but isn't really
related to clocks.
Since it's only used by mach-omap2/vc.c, move its definition there.
Signed-off-by: Bastien Curutchet <[email protected]>
|
|
Bind the DBSC5 DRAM controller driver on boot in board_early_init_r(),
which brings up the DBSC5 DRAM controller and its PHY and which enables
access to DRAM present on this system.
Add default boot command which loads additional bootloader components
from HF and UFS storage into SRAM and DRAM, and starts those components
on SCP and AP core 0. The system is then capable of reaching U-Boot on
the AP core 0. Specifically, the following components are loaded:
- SCP firmware, 384 kiB from HF offset 0x4c0000 to SCP STCM
- TFA BL31, 256 kiB from UFS0 offset 0x5000 * 4 kiB sectors to DRAM 0x8c200000
- TEE, 2 MiB from UFS0 offset 0x5200 * 4 kiB sectors to DRAM 0x8c400000
- U-Boot, 1 MiB from UFS0 offset 0x7200 * 4 kiB sectors to DRAM 0x8c300000
- IPL parameters table is generated at DRAM address 0x8c100000
Enable pstore command support to allow dumping kernel console from
pstore/ramoops, which is convenient for debugging. Use as follows:
=> pstore set 0x80000000 0x10000 0x400 0x8000 0 0 0
=> pstore display console
Signed-off-by: Marek Vasut <[email protected]>
|
|
Simon Glass <[email protected]> says:
Commit bd3f9ee679b4 added FORCE to several if_changed rules whose
recipes expand $^, so FORCE leaks in as a stray argument and the
command fails. Use $< to restore the Edison and i.MX23/28 images.
Link: https://lore.kernel.org/r/[email protected]
|
|
Commit bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") adds FORCE
as a prerequisite to the if_changed rules here, but the commands use $^
so FORCE leaks in as a stray operand. The dd in cmd_mkalign_mxs fails
(silently, since its stderr is discarded) and the binary is never
aligned, stat in cmd_mkivt_mxs emits an error and cst receives a bogus
argument.
Use $< and $(real-prereqs) instead, which exclude FORCE.
Fixes: bd3f9ee679b4 ("kbuild: Bump the build system to 6.1")
Signed-off-by: Simon Glass <[email protected]>
|
|
ARM GIC-600 IP complies with ARM GICv3 architecture, but among others,
implements a power control register in the Redistributor frame. This
register must be programmed to mark the frame as powered on, before
accessing other registers in the frame.
Before the switch to generic lowlevel_init function, this did not pose
a problem as the previous custom lowlevel_init did not access the GICR
registers. The generic function does and that does lead to a hang early
in SPL. Enable the GIC600 initialization variant to mitigate the hang.
Fixes: 37997a214ed1 ("arm: renesas: Use stock lowlevel_init function and remove s_init")
Signed-off-by: Marek Vasut <[email protected]>
|
|
The SDK 4.32 flash_writer tool, built from the SDK IPL source, requires
SREC S7 "Start address (termination)" record [1] at the end of the SREC
file that is sent to it during installation of content into storage,
otherwise the tool waits for the S7 record indefinitelly and the payload
does not get installed into storage.
Specifically, the tool considers SREC S3 and S7 records as mandatory,
S0, S5, S6 as ignored, and any other records as unsupported.
Configure srec_cat such that it explicitly generates the trailing S7
record, and also that it never generates the ignored S5 Count record.
This fixes installation of u-boot-elf.shdr using the flash_writer tool,
which can not finish successfully without the trailing S7 record.
[1] https://en.wikipedia.org/wiki/Motorola_S-record#Record_types
Fixes: 3b2ce3743c1a ("arm: renesas: Generate u-boot-elf.shdr for R-Car Gen5 RSIP")
Signed-off-by: Marek Vasut <[email protected]>
|
|
These boards are not yet in the CONFIG_OF_LIST of the defconfigs, add
them and remove the local devicetrees.
Signed-off-by: Markus Schneider-Pargmann (TI) <[email protected]>
|
|
Use dt_dir for the substitution of the DT paths to get the correct paths
even when switching to OF_UPSTREAM.
Signed-off-by: Markus Schneider-Pargmann (TI) <[email protected]>
|
|
These devicetrees are not used anymore because the boards are using
upstream devicetrees now.
Acked-by: Andrew Davis <[email protected]>
Signed-off-by: Markus Schneider-Pargmann (TI) <[email protected]>
|
|
Support musb being probed by ti,musb-am33xx. The non-upstream DT probing
used a wrapper driver that probed ti-musb-peripheral and ti-musb-host.
This wrapper registered as UCLASS_MISC, which is why it is requested in
this board.c file.
With the new devicetree the wrapper that registers as UCLASS_MISC is
gone, instead the UCLASS_USB and UCLASS_USB_GADGET_GENERIC have to be
requested.
Signed-off-by: Markus Schneider-Pargmann (TI) <[email protected]>
|
