| Age | Commit message (Collapse) | Author |
|---|
|
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]>
|
|
Replace mac[5] += offset with a proper 48-bit MAC address add to avoid
overflow issues when mac[5] was close to 255.
Example:
i.MX95 MAC2: 00:11:22:33:44:FE + 6
Old: 00:11:22:33:44:04 (overflow, wraps to 0)
New: 00:11:22:33:45:04 (correct carry from mac[5] to mac[4])
Signed-off-by: Alice Guo <[email protected]>
Signed-off-by: Ye Li <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
|
|
The shutdown checking should use shutdown flags, not bootflags.
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
After supporting get DRAM size from SM, the trampoline buffer address
still depends on PHYS_SDRAM_SIZE. If the real DDR size is less than
PHYS_SDRAM_SIZE, the trampoline buffer address is invalid and SPL will
crash. So use board_phys_sdram_size to get real DDR size to calculate
correct address.
Fixes: e1cc7117b630 ("imx9: scmi: Get DDR size through SM SCMI API")
Signed-off-by: Ye Li <[email protected]>
Reviewed-by: Peng Fan <[email protected]>
Tested-by: Emanuele Ghidoli <[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]>
|
|
Use board_get_usable_ram_top() instead of get_effective_memsize() to
limit gd->ram_top.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit b9e6281632a8 ("arm: mediatek: mt8512:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation.
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. Overriding gd->bd->bi_dram[0].size was a bit
confusing since it isn't easily apparent which order the functions that
set it are called.
Fixes: b9e6281632a8 ("arm: mediatek: mt8512: drop dram_init_banksize()")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit d83bd9729d75 ("arm: mediatek: mt8195:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of get_effective_memsize() being overridden in commit
af4cba9a05aa ("arm: mediatek: mt8195: fix gd->ram_top limit")
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Fixes: d83bd9729d75 ("arm: mediatek: mt8195: drop dram_init_banksize()")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Fixes: a7c682565b4b ("arm: mediatek: add support of MT8189 SoC family")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit b3467e51e92b ("arm: mediatek: mt8188:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of get_effective_memsize() being overridden in commit
7518e10cd235 ("arm: mediatek: mt8188: fix gd->ram_top limit").
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Fixes: b3467e51e92b ("arm: mediatek: mt8188: drop dram_init_banksize()")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit bddd6bbef3dc ("arm: mediatek: mt7988:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of CFG_MAX_MEM_MAPPED.
Rather than continue to use an old-style CFG_ option and the potentially
confusing overriding of gd->bd->bi_dram[0].size (it is difficult to see
which order the functions that set it are called), we can just use
board_get_usable_ram_top() to set gd->ram_top to the correct value
instead. This is possible now, thanks to LMB_LIMIT_DMA_BELOW_RAM_TOP
being set by default for 64-bit Mediatek ARM SoCs.
The CFG_MAX_MEM_MAPPED option is removed since it is no longer needed.
The config header and Kconfig option are also removed since that was
the last CFG_ option.
Reported-by: Rudy Andram <[email protected]>
Closes: https://lore.kernel.org/u-boot/[email protected]/
Fixes: bddd6bbef3dc ("arm: mediatek: mt7988: drop dram_init_banksize()")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit 56183fb025c2 ("arm: mediatek: mt7987: drop
dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of CFG_MAX_MEM_MAPPED.
Rather than continue to use an old-style CFG_ option and the potentially
confusing overriding of gd->bd->bi_dram[0].size (it is difficult to see
which order the functions that set it are called), we can just use
board_get_usable_ram_top() to set gd->ram_top to the correct value
instead. This is possible now, thanks to LMB_LIMIT_DMA_BELOW_RAM_TOP
being set by default for 64-bit Mediatek ARM SoCs.
On mt7987, there is already an implementation of
board_get_usable_ram_top() for other reasons, so it is modified to
also limit ram_top to 4GiB (mt7987 is currently the only thing that
sets CONFIG_MTK_TZ_MOVABLE=y so it is safe to change this here without
unintentional side-effects).
The CFG_MAX_MEM_MAPPED option is removed since it is no longer needed.
The config header and Kconfig option are also removed since that was
the last CFG_ option.
Fixes: 56183fb025c2 ("arm: mediatek: mt7987: drop dram_init_banksize()")
Link: https://patch.msgid.link/[email protected]
Signed-off-by: David Lechner <[email protected]>
|
|
For AST2600 SPL with CONFIG_SPL_SEPARATE_BSS=y and
CONFIG_OF_SEPARATE=y, fdt_find_separate() expects the appended control
DTB at _image_binary_end.
The AST2600 SPL linker script aligned _image_binary_end via the
.binman_sym_table section. In builds where that section has no emitted
contents, objcopy -O binary does not include the alignment bytes in
spl/u-boot-spl-nodtb.bin. This causes the nodtb binary to end before
_image_binary_end, so the appended DTB is placed too early.
On evb-ast2600 this produced:
sizeof(spl/u-boot-spl-nodtb.bin) = 0xc92c
_image_binary_end = 0xc930
SPL then looked four bytes past the FDT header and failed with:
Missing DTB
No serial driver found
Move the 8-byte alignment into the preceding emitted __u_boot_list
section so the objcopy output and _image_binary_end agree.
Signed-off-by: Quentin Strydom <[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]>
|
|
Fix #else and #endif comments to match actual #if condition. Comments
incorrectly referenced CONFIG_USB_MUSB_* instead of CONFIG_AM335X_USB*
and CONFIG_XPL_BUILD.
Reviewed-by: Kory Maincent <[email protected]>
Signed-off-by: Markus Schneider-Pargmann (TI) <[email protected]>
|
|
This is required for am335x to boot correctly.
Signed-off-by: Markus Schneider-Pargmann (TI) <[email protected]>
|
|
Upstream devicetrees do not have a binding for the tick-timer. Add it
for all boards built with the am335x_evm_defconfig.
Reviewed-by: Kory Maincent <[email protected]>
Signed-off-by: Markus Schneider-Pargmann (TI) <[email protected]>
|
|
Currently if USB fails to probe, U-Boot does not reach the console.
This patch does not fail if USB fails to probe making it easier to debug
in case of issues.
Reviewed-by: Kory Maincent <[email protected]>
Signed-off-by: Markus Schneider-Pargmann (TI) <[email protected]>
|
