History log of /rk3399_rockchip-uboot/arch/arm/cpu/u-boot.lds (Results 1 – 25 of 59)
Revision Date Author Comments
# b0692428 24-Dec-2021 Joseph Chen <chenjh@rock-chips.com>

arm: v7: u-boot.lds: promise 8 byte align

When AArch64 bl31 uses u-boot.dtb passed from SPL, it requires
this fdt in a 8-byte aligned address, otherwise it causes a
unaligned access exception.

If t

arm: v7: u-boot.lds: promise 8 byte align

When AArch64 bl31 uses u-boot.dtb passed from SPL, it requires
this fdt in a 8-byte aligned address, otherwise it causes a
unaligned access exception.

If the u-boot is built with AArch32 mode, it's size maybe
not 8-byte aligned, so does the fdt address.

Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Change-Id: Icb6797336122f23ef5e82aec731faceb3f54242d

show more ...


# 3d8049ad 15-May-2020 Joseph Chen <chenjh@rock-chips.com>

common: add U_BOOT_CMD_ALWAYS() support

This function is used to support some special U-Boot commands with
U_BOOT_CMD_ALWAYS() declared even when CONFIG_CMDLINE is disabled.

It's used when develope

common: add U_BOOT_CMD_ALWAYS() support

This function is used to support some special U-Boot commands with
U_BOOT_CMD_ALWAYS() declared even when CONFIG_CMDLINE is disabled.

It's used when developers requires a critial u-boot.bin by disabling
the U_BOOT_CMD() and using a simple CLI instead.

Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Change-Id: I768637592a4d85c7fea00564e96fb80f21ab65fe

show more ...


# d0df954b 01-Feb-2019 Joseph Chen <chenjh@rock-chips.com>

arm: lib: add arm32/64 stacktrace support

This patch supports dump arm32/64 stacktrace as the format of raw
address info. The U-Boot symbol table is not available now, please
use ./scripts/stacktrac

arm: lib: add arm32/64 stacktrace support

This patch supports dump arm32/64 stacktrace as the format of raw
address info. The U-Boot symbol table is not available now, please
use ./scripts/stacktrace.sh script to parse stacktrace info with command:

./scripts/stacktrace.sh <file> // stacktrace info file

Example on RK3399:
Call trace:
PC: [< 00258a7c >] dwc3_gadget_uboot_handle_interrupt+0xa0/0x5bc
LR: [< 002052f8 >] usb_gadget_handle_interrupts+0x10/0x1c

Stack:
[< 00258a7c >] dwc3_gadget_uboot_handle_interrupt+0xa0/0x5bc
[< 0025bd6c >] sleep_thread.isra.20+0xb0/0x114
[< 0025cf58 >] fsg_main_thread+0x2c8/0x1814
[< 0020db58 >] do_rkusb+0x250/0x338
[< 00226a00 >] cmd_process+0xac/0xe0
[< 00212df4 >] run_list_real+0x6fc/0x72c
[< 00212f94 >] parse_stream_outer+0x170/0x67c
[< 002126e0 >] parse_string_outer+0xdc/0xf4
[< 00212bb0 >] run_list_real+0x4b8/0x72c
[< 00212f94 >] parse_stream_outer+0x170/0x67c
[< 00212698 >] parse_string_outer+0x94/0xf4
[< 00225f30 >] run_command_list+0x38/0x90
[< 00202d08 >] rockchip_dnl_mode_check+0x4c/0xd4
[< 00202db0 >] setup_boot_mode+0x20/0xf0
[< 00203010 >] board_late_init+0x10/0x40
[< 0027071c >] initcall_run_list+0x44/0x80
[< 00213d68 >] board_init_r+0x20/0x24

The "dump_stack()" is available to trigger stacktrace.

Change-Id: Ib1423269dd255fa4a34231489cd3b7e6ddd22540
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>

show more ...


# 83ebd4a6 14-Jun-2017 Tom Rini <trini@konsulko.com>

Revert "ARM: fixed relocation using proper alignment"

It turns out this change was not intended to be merged and as such,
revert it.

This reverts commit cdde7de0364ffa505d631b342f1a2fa729e8e67d.

R

Revert "ARM: fixed relocation using proper alignment"

It turns out this change was not intended to be merged and as such,
revert it.

This reverts commit cdde7de0364ffa505d631b342f1a2fa729e8e67d.

Reported-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

show more ...


# cdde7de0 10-May-2017 Manfred Schlaegl <manfred.schlaegl@ginzinger.com>

ARM: fixed relocation using proper alignment

Using u-boot-2017.05 on i.MX6UL we ran into following problem:
Initially U-Boot could be started normally.
If we added one random command in configuratio

ARM: fixed relocation using proper alignment

Using u-boot-2017.05 on i.MX6UL we ran into following problem:
Initially U-Boot could be started normally.
If we added one random command in configuration, the newly generated
image hung at startup (last output was DRAM: 256 MiB).

We tracked this down to a data abort within relocation (relocated_code).

relocated_code in arch/arm/lib/relocate.S copies 8 bytes per loop
iteration until the source pointer is equal to __image_copy_end.
In a good case __image_copy_end was aligned to 8 bytes, so the loop
stopped as suggested, but in an errornous case __image_copy_end was
not aligned to 8 bytes, so the loop ran out of bounds and caused a
data abort exception.

This patches solves the issue by aligning __image_copy_end to 8 byte
using the linker script related to arm.

I don't know if it's the correct way to solve this, so some review would
be very appreciated.

show more ...


# 2fe1281c 26-Sep-2016 Masahiro Yamada <yamada.masahiro@socionext.com>

ARM: create .secure_stack section only for PSCI

Jon Master reports that QEMU refuses to load a U-Boot image built
with CONFIG_ARMV7_NONSEC, but without CONFIG_ARMV7_PSCI since
commit 5a3aae68c74e ("

ARM: create .secure_stack section only for PSCI

Jon Master reports that QEMU refuses to load a U-Boot image built
with CONFIG_ARMV7_NONSEC, but without CONFIG_ARMV7_PSCI since
commit 5a3aae68c74e ("ARM: armv7: guard memory reserve for PSCI
with #ifdef CONFIG_ARMV7_PSCI").

It looks like only PSCI that needs the Secure stack, so move
the #ifdef to guard the whole of .secure_stack allocation in order
not to create the empty section.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: Jon Masters <jcm@redhat.com>
Link: http://patchwork.ozlabs.org/patch/664025/

show more ...


# 5a3aae68 30-Aug-2016 Masahiro Yamada <yamada.masahiro@socionext.com>

ARM: armv7: guard memory reserve for PSCI with #ifdef CONFIG_ARMV7_PSCI

If CONFIG_ARMV7_NONSEC is enabled, the linker script requires
CONFIG_ARMV7_PSCI_NR_CPUS regardless of CONFIG_ARMV7_PSCI.

Revi

ARM: armv7: guard memory reserve for PSCI with #ifdef CONFIG_ARMV7_PSCI

If CONFIG_ARMV7_NONSEC is enabled, the linker script requires
CONFIG_ARMV7_PSCI_NR_CPUS regardless of CONFIG_ARMV7_PSCI.

Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...


# 1f9ef0dc 15-Jul-2016 Tom Rini <trini@konsulko.com>

Merge branch 'master' of http://git.denx.de/u-boot-sunxi


# a5aa7ff3 05-Jul-2016 Chen-Yu Tsai <wens@csie.org>

ARM: Add secure section for initialized data

The secure monitor may need to store global or static values within the
secure section of memory, such as target PC or CPU power status.

Signed-off-by:

ARM: Add secure section for initialized data

The secure monitor may need to store global or static values within the
secure section of memory, such as target PC or CPU power status.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

show more ...


# 3eff6818 19-Jun-2016 Chen-Yu Tsai <wens@csie.org>

ARM: Add CONFIG_ARMV7_SECURE_MAX_SIZE and check size of secure section

As the PSCI implementation grows, we might exceed the size of the secure
memory that holds the firmware.

Add a configurable CO

ARM: Add CONFIG_ARMV7_SECURE_MAX_SIZE and check size of secure section

As the PSCI implementation grows, we might exceed the size of the secure
memory that holds the firmware.

Add a configurable CONFIG_ARMV7_SECURE_MAX_SIZE so platforms can define
how much secure memory is available. The linker then checks the size of
the whole secure section against this.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

show more ...


# 980d6a55 19-Jun-2016 Chen-Yu Tsai <wens@csie.org>

ARM: Add an empty secure stack section

Until now we've been using memory beyond psci_text_end as stack space
for the secure monitor or PSCI implementation, even if space was not
allocated for it.

T

ARM: Add an empty secure stack section

Until now we've been using memory beyond psci_text_end as stack space
for the secure monitor or PSCI implementation, even if space was not
allocated for it.

This was partially fixed in ("ARM: allocate extra space for PSCI stack
in secure section during link phase"). However, calculating stack space
from psci_text_end in one place, while allocating the space in another
is error prone.

This patch adds a separate empty secure stack section, with space for
CONFIG_ARMV7_PSCI_NR_CPUS stacks, each 1 KB. There's also
__secure_stack_start and __secure_stack_end symbols. The linker script
handles calculating the correct VMAs for the stack section. For
platforms that relocate/copy the secure monitor before using it, the
space is not allocated in the executable, saving space.

For platforms that do not define CONFIG_ARMV7_PSCI_NR_CPUS, a whole page
of stack space for 4 CPUs is allocated, matching the previous behavior.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

show more ...


# a1274cc9 19-Jun-2016 Chen-Yu Tsai <wens@csie.org>

ARM: Page align secure section only when it is executed in situ

Targets that define CONFIG_ARMV7_SECURE_BASE will copy the secure section
to another address before execution.

Since the secure secti

ARM: Page align secure section only when it is executed in situ

Targets that define CONFIG_ARMV7_SECURE_BASE will copy the secure section
to another address before execution.

Since the secure section in the u-boot image is only storage, there's
no reason to page align it and increase the binary image size.

Page align the secure section only when CONFIG_ARMV7_SECURE_BASE is not
defined. And instead of just aligning the __secure_start symbol, align
the whole .__secure_start section. This also makes the section empty,
so we need to add KEEP() to the input entry to prevent the section from
being garbage collected.

Also use ld constant "COMMONPAGESIZE" instead of hardcoded page size.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

show more ...


# b56e06d3 07-Jun-2016 Chen-Yu Tsai <wens@csie.org>

ARM: allocate extra space for PSCI stack in secure section during link phase

The PSCI implementation expects at most 2 pages worth of space reserved
at the end of the secure section for its stacks.

ARM: allocate extra space for PSCI stack in secure section during link phase

The PSCI implementation expects at most 2 pages worth of space reserved
at the end of the secure section for its stacks. If PSCI is relocated to
secure SRAM, then everything is fine. If no secure SRAM is available,
and PSCI remains in main memory, the reserved memory space doesn't cover
the space used by the stack.

If one accesses PSCI after Linux has fully booted, the memory that should
have been reserved for the PSCI stacks may have been used by the kernel
or userspace, and would be corrupted. Observed after effects include the
system hanging or telinit core dumping when trying to reboot. It seems
the init process gets hit the most on my test bed.

This fix allocates the space used by the PSCI stacks in the secure
section by skipping pages in the linker script, but only when there is
no secure SRAM, to avoid bloating the binary.

This fix is only a stop gap. It would be better to rework the stack
allocation mechanism, maybe with proper usage of CONFIG_ macros and an
explicit symbol.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

show more ...


# c1352119 14-Mar-2016 Simon Glass <sjg@chromium.org>

arm: x86: Drop command-line code when CONFIG_CMDLINE is disabled

Update the link script to drop this code when not needed. This is only done
for two architectures at present.

Signed-off-by: Simon G

arm: x86: Drop command-line code when CONFIG_CMDLINE is disabled

Update the link script to drop this code when not needed. This is only done
for two architectures at present.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

show more ...


# 50149ea3 04-Mar-2016 Alexander Graf <agraf@suse.de>

efi_loader: Add runtime services

After booting has finished, EFI allows firmware to still interact with the OS
using the "runtime services". These callbacks live in a separate address space,
since t

efi_loader: Add runtime services

After booting has finished, EFI allows firmware to still interact with the OS
using the "runtime services". These callbacks live in a separate address space,
since they are available long after U-Boot has been overwritten by the OS.

This patch adds enough framework for arbitrary code inside of U-Boot to become
a runtime service with the right section attributes set. For now, we don't make
use of it yet though.

We could maybe in the future map U-boot environment variables to EFI variables
here.

Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

show more ...


# c5e954ec 18-Jan-2016 Wang Dongsheng <dongsheng.wang@nxp.com>

ARM: Disable "DISCARD" for secure section if CONFIG_ARMV7_SECURE_BASE isn't defined

"DISCARD" will remove ._secure.text relocate, but PSCI framework
has already used some absolute address those need

ARM: Disable "DISCARD" for secure section if CONFIG_ARMV7_SECURE_BASE isn't defined

"DISCARD" will remove ._secure.text relocate, but PSCI framework
has already used some absolute address those need to relocate.

Use readelf -t -r u-boot show us:
.__secure_start addr: 601408e4
.__secure_end addr: 60141460

60141140 00000017 R_ARM_RELATIVE
46 _secure_monitor:
47 #ifdef CONFIG_ARMV7_PSCI
48 ldr r5, =_psci_vectors

60141194 00000017 R_ARM_RELATIVE
6014119c 00000017 R_ARM_RELATIVE
601411a4 00000017 R_ARM_RELATIVE
601411ac 00000017 R_ARM_RELATIVE
64 _psci_table:
66 .word psci_cpu_suspend
...
72 .word psci_migrate

60141344 00000017 R_ARM_RELATIVE
6014145c 00000017 R_ARM_RELATIVE
202 ldr r5, =psci_text_end

Solutions:
1. Change absolute address to RelAdr.
Based on LDR (immediate, ARM), we only have 4K offset to jump.
Now PSCI code size is close to 4K size that is LDR limit jump size,
so even if the LDR is based on the current instruction address,
there is also have a risk for RelAdr. If we use two jump steps I
think we can fix this issue, but looks too hack, so give up this way.

2. Enable "DISCARD" only for CONFIG_ARMV7_SECURE_BASE has defined.
If CONFIG_ARMV7_SECURE_BASE is defined in platform, all of secure
will in the BASE address that is absolute.

Signed-off-by: Wang Dongsheng <dongsheng.wang@nxp.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

show more ...


# 98e73c83 16-Nov-2015 Tom Rini <trini@konsulko.com>

Merge branch 'master' of git://www.denx.de/git/u-boot-imx


# d47cb0b6 23-Oct-2015 Peng Fan <Peng.Fan@freescale.com>

arm: discard relocation entries for secure text

The code such as PSCI in section named secure is bundled with
u-boot image, and when bootm, the code will be copied to their
runtime address same to c

arm: discard relocation entries for secure text

The code such as PSCI in section named secure is bundled with
u-boot image, and when bootm, the code will be copied to their
runtime address same to compliation/linking address -
CONFIG_ARMV7_SECURE_BASE.

When compile the PSCI code and link it into the u-boot image,
there will be relocation entries in .rel.dyn section for PSCI.
Actually, we do not needs these relocation entries.

If still keep the relocation entries in .rel.dyn section,
r0 at line 103 and 106 in arch/arm/lib/relocate.S may be an invalid
address which may not support read/write for one SoC.
102 /* relative fix: increase location by offset */
103 add r0, r0, r4
104 ldr r1, [r0]
105 add r1, r1, r4
106 str r1, [r0]

So discard them to avoid touching the relocation entry in
arch/arm/lib/relocate.S.

Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Cc: Tom Warren <twarren@nvidia.com>
Cc: York Sun <yorksun@freescale.com>
Cc: Hans De Goede <hdegoede@redhat.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Tom Rini <trini@konsulko.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Stefano Babic <sbabic@denx.de>
Acked-by: Albert ARIBAUD <albert.u.boot@aribaud.net>

show more ...


# 9597494e 14-May-2015 Tom Rini <trini@konsulko.com>

Merge branch 'master' of git://git.denx.de/u-boot-tegra


# 104d6fb6 21-Apr-2015 Jan Kiszka <jan.kiszka@siemens.com>

ARM: Clean up CONFIG_ARMV7_NONSEC/VIRT/PSCI conditions

CONFIG_ARMV7_VIRT depends on CONFIG_ARMV7_NONSEC, thus doesn't need to
be taken into account additionally. CONFIG_ARMV7_PSCI is only set on
boa

ARM: Clean up CONFIG_ARMV7_NONSEC/VIRT/PSCI conditions

CONFIG_ARMV7_VIRT depends on CONFIG_ARMV7_NONSEC, thus doesn't need to
be taken into account additionally. CONFIG_ARMV7_PSCI is only set on
boards that support CONFIG_ARMV7_NONSEC, and it only works on those.

CC: Tang Yuantian <Yuantian.Tang@freescale.com>
CC: York Sun <yorksun@freescale.com>
CC: Steve Rae <srae@broadcom.com>
CC: Andre Przywara <andre.przywara@linaro.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Tested-by: Alison Wang <alison.wang@freescale.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

show more ...


# c23154aa 08-Aug-2014 Stefano Babic <sbabic@denx.de>

Merge branch 'master' of git://git.denx.de/u-boot-arm


# 362f16b1 29-Jul-2014 Tom Rini <trini@ti.com>

Merge branch 'master' of git://git.denx.de/u-boot-arm


# bf433afd 12-Jul-2014 Marc Zyngier <marc.zyngier@arm.com>

ARM: HYP/non-sec: add separate section for secure code

In anticipation of refactoring the HYP/non-secure code to run
from secure RAM, add a new linker section that will contain that
code.

Nothing i

ARM: HYP/non-sec: add separate section for secure code

In anticipation of refactoring the HYP/non-secure code to run
from secure RAM, add a new linker section that will contain that
code.

Nothing is using it just yet.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>

show more ...


# f6ed9d50 22-May-2014 Tom Rini <trini@ti.com>

Merge branch 'master' of git://git.denx.de/u-boot-arm


# 41623c91 15-Apr-2014 Albert ARIBAUD <albert.u.boot@aribaud.net>

arm: move exception handling out of start.S files

Exception handling is basically identical for all ARM targets.
Factorize it out of the various start.S files and into a
single vectors.S file, and a

arm: move exception handling out of start.S files

Exception handling is basically identical for all ARM targets.
Factorize it out of the various start.S files and into a
single vectors.S file, and adjust linker scripts accordingly.

Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>

show more ...


123