Convert UTF-8 chars to ASCII in cases where make sense. No Copyright or
names are converted.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Marek Behún <kabel@kernel.org>
The implementation of map_range() creates the requested mapping by
walking the page tables, iterating over multiple PTEs and/or descending
into existing table mappings as needed. When doing so, it assumes any
pre-existing valid PTE to be a table mapping. This assumption is wrong
if the platform code attempts to successively map two overlapping ranges
where the latter intersects a block mapping created for the former.
As a result, map_range() treats the existing block mapping as a table
mapping and descends into it i.e. starts interpreting the
previously-mapped range as an array of PTEs, writing to them and
potentially even descending further (extra fun with MMIO ranges!).
Instead, pass any valid non-table mapping to split_block(), which
ensures that it actually was a block mapping (calls panic() otherwise)
before splitting it.
Fixes: 41e2787f5e ("arm64: Reduce add_map() complexity")
Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
Tested-by: Fabio Estevam <festevam@gmail.com>
Tested-by: Hiago De Franco <hiago.franco@toradex.com> # Toradex Verdin AM62
Reviewed-by: Marc Zyngier <maz@kernel.org>
Ilias Apalodimas <ilias.apalodimas@linaro.org> says:
The arm linker scripts had a mix of symbols and C defined variables in an
effort to emit relative references instead of absolute ones e.g [0]. A
linker bug prevented us from doing so [1] -- fixed since 2016.
This has led to confusion over the years, ending up with mixed section
definitions. Some sections are defined with overlays and different
definitions between v7 and v8 architectures.
For example __efi_runtime_rel_start/end is defined as a linker symbol for
armv8 and a C variable in armv7.
Linker scripts nowadays can emit relative references, as long as the symbol
definition is contained within the section definition. So let's switch most
of the C defined variables and clean up the arm sections.c file.
There's still a few symbols remaining -- __secure_start/end,
__secure_stack_start/end and __end which can be cleaned up
in a followup series.
For both QEMU v7/v8 bloat-o-meter shows now size difference
$~ ./scripts/bloat-o-meter u-boot u-boot.new
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Function old new delta
Total: Before=798861, After=798861, chg +0.00%
The symbols seem largely unchanged apart from a difference in .bss
as well as the emited sections and object types of the affected variables.
On the output below the first value is from -next and the second comes from
-next + this patchset. The .bss_start/end sections have disappeared from
the newer binaries.
# For example on QEMU v8:
efi_runtime_start
7945: 0000000000000178 0 OBJECT GLOBAL DEFAULT 2 __efi_runtime_start
7942: 0000000000000178 0 NOTYPE GLOBAL DEFAULT 2 __efi_runtime_start
efi_runtime_stop
9050: 0000000000000d38 0 OBJECT GLOBAL DEFAULT 2 __efi_runtime_stop
9047: 0000000000000d38 0 NOTYPE GLOBAL DEFAULT 2 __efi_runtime_stop
__efi_runtime_rel_start
7172: 00000000000dc2f0 0 OBJECT GLOBAL DEFAULT 10 __efi_runtime_rel_start
7169: 00000000000dc2f0 0 NOTYPE GLOBAL DEFAULT 10 __efi_runtime_rel_start
__efi_runtime_rel_stop
7954: 00000000000dc4a0 0 OBJECT GLOBAL DEFAULT 10 __efi_runtime_rel_stop
7951: 00000000000dc4a0 0 NOTYPE GLOBAL DEFAULT 10 __efi_runtime_rel_stop
__rel_dyn_start
7030: 00000000000dc4a0 0 OBJECT GLOBAL DEFAULT 11 __rel_dyn_start
7027: 00000000000dc4a0 0 NOTYPE GLOBAL DEFAULT 11 __rel_dyn_start
__rel_dyn_end
8959: 0000000000102b10 0 OBJECT GLOBAL DEFAULT 12 __rel_dyn_end
8956: 0000000000102b10 0 NOTYPE GLOBAL DEFAULT 11 __rel_dyn_end
image_copy_start
9051: 0000000000000000 0 OBJECT GLOBAL DEFAULT 1 __image_copy_start
9048: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 1 __image_copy_start
image_copy_end
7467: 00000000000dc4a0 0 OBJECT GLOBAL DEFAULT 11 __image_copy_end
7464: 00000000000dc4a0 0 NOTYPE GLOBAL DEFAULT 11 __image_copy_end
bss_start
12: 0000000000102b10 0 SECTION LOCAL DEFAULT 12 .bss_start
8087: 0000000000000018 0 NOTYPE GLOBAL DEFAULT 1 _bss_start_ofs
8375: 0000000000102b10 0 OBJECT GLOBAL DEFAULT 12 __bss_start
8084: 0000000000000018 0 NOTYPE GLOBAL DEFAULT 1 _bss_start_ofs
8372: 0000000000102b10 0 NOTYPE GLOBAL DEFAULT 12 __bss_start
bss_end
14: 000000000010bc30 0 SECTION LOCAL DEFAULT 14 .bss_end
7683: 000000000010bc30 0 OBJECT GLOBAL DEFAULT 14 __bss_end
8479: 0000000000000020 0 NOTYPE GLOBAL DEFAULT 1 _bss_end_ofs
7680: 000000000010bbb0 0 NOTYPE GLOBAL DEFAULT 12 __bss_end
8476: 0000000000000020 0 NOTYPE GLOBAL DEFAULT 1 _bss_end_ofs
# For QEMU v7:
efi_runtime_start
10703: 000003bc 0 OBJECT GLOBAL DEFAULT 2 __efi_runtime_start
10699: 000003c0 0 NOTYPE GLOBAL DEFAULT 2 __efi_runtime_start
efi_runtime_stop
11796: 000012ec 0 OBJECT GLOBAL DEFAULT 2 __efi_runtime_stop
11792: 000012ec 0 NOTYPE GLOBAL DEFAULT 2 __efi_runtime_stop
__efi_runtime_rel_start
9937: 000c40dc 0 OBJECT GLOBAL DEFAULT 8 __efi_runtime_rel_start
9935: 000c40dc 0 NOTYPE GLOBAL DEFAULT 9 __efi_runtime_rel_start
__efi_runtime_rel_stop
10712: 000c41dc 0 OBJECT GLOBAL DEFAULT 10 __efi_runtime_rel_stop
10708: 000c41dc 0 NOTYPE GLOBAL DEFAULT 9 __efi_runtime_rel_stop
__rel_dyn_start
9791: 000c41dc 0 OBJECT GLOBAL DEFAULT 10 __rel_dyn_start
9789: 000c41dc 0 NOTYPE GLOBAL DEFAULT 10 __rel_dyn_start
__rel_dyn_end
11708: 000da5f4 0 OBJECT GLOBAL DEFAULT 10 __rel_dyn_end
11704: 000da5f4 0 NOTYPE GLOBAL DEFAULT 10 __rel_dyn_end
image_copy_start
448: 0000177c 0 NOTYPE LOCAL DEFAULT 3 _image_copy_start_ofs
11797: 00000000 0 OBJECT GLOBAL DEFAULT 1 __image_copy_start
445: 0000177c 0 NOTYPE LOCAL DEFAULT 3 _image_copy_start_ofs
11793: 00000000 0 NOTYPE GLOBAL DEFAULT 1 __image_copy_start
image_copy_end
450: 00001780 0 NOTYPE LOCAL DEFAULT 3 _image_copy_end_ofs
10225: 000c41dc 0 OBJECT GLOBAL DEFAULT 10 __image_copy_end
447: 00001780 0 NOTYPE LOCAL DEFAULT 3 _image_copy_end_ofs
10222: 000c41dc 0 NOTYPE GLOBAL DEFAULT 10 __image_copy_end
bss_start
11: 000c41dc 0 SECTION LOCAL DEFAULT 11 .bss_start
11124: 000c41dc 0 OBJECT GLOBAL DEFAULT 11 __bss_start
11120: 000c41dc 0 NOTYPE GLOBAL DEFAULT 11 __bss_start
bss_end
13: 000cbbf8 0 SECTION LOCAL DEFAULT 13 .bss_end
10442: 000cbbf8 0 OBJECT GLOBAL DEFAULT 13 __bss_end
10439: 000cbbf8 0 NOTYPE GLOBAL DEFAULT 11 __bss_end
It's worth noting that since the efi regions are affected by the change, booting
with EFI is preferable while testing. Booting the kernel only should be enough
since the efi stub and the kernel proper do request boottime and runtime
services respectively.
Something along the lines of
> virtio scan && load virtio 0 $kernel_addr_r Image && bootefi $kernel_addr_r
will work for QEMU aarch64.
Tested platforms:
- QEMU aarch64
- Xilinx kv260 kria starter kit & zynq
- QEMU armv7
- STM32MP157C-DK2
[0] commit 3ebd1cbc49 ("arm: make __bss_start and __bss_end__ compiler-generated")
[1] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
Previous patches cleaning up linker symbols, also merged any explicit
. = ALIGN(x); into section definitions -- e.g
.bss ALIGN(x) : instead of
. = ALIGN(x);
. bss : {...}
However, if the output address is not specified then one will be chosen
for the section. This address will be adjusted to fit the alignment
requirement of the output section following the strictest alignment of
any input section contained within the output section. So let's get rid
of the redundant ALIGN directives when they are not needed.
While at add comments for the alignment of __bss_start/end since our
C runtime setup assembly assumes that __bss_start - __bss_end will be
a multiple of 4/8 for armv7 and armv8 respectively.
It's worth noting that the alignment is preserved on .rel.dyn for
mach-zynq which was explicitly aligning that section on an 8b
boundary instead of 4b one.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
image_copy_start/end are defined as c variables in order to force the compiler
emit relative references. However, defining those within a section definition
will do the same thing since [0].
So let's remove the special sections from the linker scripts, the
variable definitions from sections.c and define them as a symbols within
a section.
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
Suggested-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Sam Edwards <CFSworks@gmail.com> # Binary output identical
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
__efi_runtime_start/end are defined as c variables for arm7 only in
order to force the compiler emit relative references. However, defining
those within a section definition will do the same thing since [0].
On top of that the v8 linker scripts define it as a symbol.
So let's remove the special sections from the linker scripts, the
variable definitions from sections.c and define them as a symbols within
the correct section.
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
Suggested-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Sam Edwards <CFSworks@gmail.com> # Binary output identical
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
commit 47bd65ef05 ("arm: make __rel_dyn_{start, end} compiler-generated")
were moving the __rel_dyn_start/end on c generated variables that were
injected in their own sections. The reason was that we needed relative
relocations for position independent code and linker bugs back then
prevented us from doing so [0].
However, the linker documentation pages states that symbols that are
defined within a section definition will create a relocatable
type with the value being a fixed offset from the base of a section [1].
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
[1] https://sourceware.org/binutils/docs/ld/Expression-Section.html
Suggested-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Sam Edwards <CFSworks@gmail.com> # Binary output identical
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
__efi_runtime_rel_start/end are defined as c variables for arm7 only in
order to force the compiler emit relative references. However, defining
those within a section definition will do the same thing since [0].
On top of that the v8 linker scripts define it as a symbol.
So let's remove the special sections from the linker scripts, the
variable definitions from sections.c and define them as a symbols within
the correct section.
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
Suggested-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>
Tested-by: Sam Edwards <CFSworks@gmail.com> # Binary output identical
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
commit 3ebd1cbc49 ("arm: make __bss_start and __bss_end__ compiler-generated")
and
commit f84a7b8f54 ("ARM: Fix __bss_start and __bss_end in linker scripts")
were moving the bss_start/end on c generated variables that were
injected in their own sections. The reason was that we needed relative
relocations for position independent code and linker bugs back then
prevented us from doing so [0].
However, the linker documentation pages states that symbols that are
defined within a section definition will create a relocatable type with
the value being a fixed offset from the base of a section [1].
So let's start cleaning this up starting with the bss_start and bss_end
variables. Convert them into symbols within the .bss section definition.
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
[1] https://sourceware.org/binutils/docs/ld/Expression-Section.html
Tested-by: Caleb Connolly <caleb.connolly@linaro.org> # Qualcomm sdm845
Tested-by: Sam Edwards <CFSworks@gmail.com> # Binary output identical
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Current Cache Size ID Register (ccsidr_el1) has two "flavors"
depending on whether FEAT_CCIDX is implemented or not.
When FEAT_CCIDX is implemented Associativity parameter
is coded on bits [23:3] and NumSets parameter on bits [55:32].
When FEAT_CCIDX is not implemented then Associativity parameter
is coded on bits [12:3] and NumSets parameter on bits [27:13].
Current U-Boot code does not check whether FEAT_CCIDX is implemented
and always parses ccsidr_el1 as if FEAT_CCIDX was not implemented.
This is of course wrong on systems where FEAT_CCIDX is implemented.
This patch fixes that problems and tests whether FEAT_CCIDX
is implemented or not and accordingly parses the ccsidr_el1 register.
Signed-off-by: Lukasz Wiecaszek <lukasz.wiecaszek@gmail.com>
This architecture and related board are unmaintained currently and have
been for a long time. Remove them.
Signed-off-by: Tom Rini <trini@konsulko.com>
The header (NSIH) used for the s5p4418-SoC is not loaded into RAM by the
2nd-bootloader, see boot0.h. Therefore, use an adapted version of
relocate_vectors which relocates the vectors after the header (at _start)
instead of the 'dummy'-vectors at the start of the header (at
__image_copy_start).
Signed-off-by: Stefan Bosch <stefan_b@posteo.net>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
Raymond Mao <raymond.mao@linaro.org> says:
This patch set adds/adapts a few bloblist APIs and implements Arm arch
custom function to retrieve the bloblist (aka. Transfer List) from
previous loader via boot arguments when BLOBLIST option is enabled and
all boot arguments are compliant to the register conventions defined
in the Firmware Handoff spec v0.9.
If an arch wishes to have different behaviors for loading bloblist
from the previous boot stage, it is required to implement the custom
function xferlist_from_boot_arg().
Save boot arguments x[0-3] into an array for handover of bloblist from
previous boot stage.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Save boot arguments r[0-3] into an array for handover of bloblist from
previous boot stage.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
When an XXX_BOOTCOMMAND isn't defined, the result is that bootcmd is set
to some random memory content. Fix it so that the function does nothing
in that case and leaves the bootcmd environment unmodified.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Incorrect registers HW_POWER_VDDIOCTRL, HW_POWER_VDDACTRL
and HW_POWER_VDDDCTRL are used in the current code to disable/enable
brownout interrupts in 'mxs_power_set_vddx()'.
Change register to HW_POWER_CTRL which contains brownout interrupt
enable bits ENIRQ_VDDIO_BO, ENIRQ_VDDA_BO and ENIRQ_VDDD_BO.
Signed-off-by: Cody Green <cody@londelec.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Lukasz Majewski <lukma@denx.de>
- Add TPM support for venice boards
- Add networking support for imx93-evk
- Enable TCP, IPv6, wget for DHCOM and Data Modul boards
- Enable fastboot support for Toradex boards
- Allow pico-imx7d to boot from SD
- Enable fastboot for beacon imx8m beacon boards, disabled
SYS_CONSOLE_IS_IN_ENV
- Fix mxsboot to prevent NAND blocks being reported as bad
- Add imx8mm PWM clock support
- Several devicetree syncs with the kernel
- Add support for i.MX8MP Polyhex Debix Model A SBC
- Reworked ddr_load_train_firmware() to get a 50ms boot time improvement
The MXS starts with CPSR V bit set, which makes the CPU jump to high vectors
in case of an exception. Those high vectors are located at 0xffff0000, which
is where the BootROM exception table is located as well. U-Boot should handle
exceptions on its own using its own exception handling code, which is located
at 0x0, i.e. at low vectors. Clear the CPSR V bit, so that the CPU would jump
to low vectors on exception instead, and therefore run the U-Boot exception
handling code.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
To quote the author:
It would be useful to be able to boot an OS when CONFIG_CMDLINE is
disabled. This could allow reduced code size.
Standard boot provides a way to handle programmatic boot, without
scripts, so such a feature is possible. The main impediment is the
inability to use the booting features of U-Boot without a command line.
So the solution is to avoid passing command arguments and the like to
code in boot/
A similar process has taken place with filesystems, for example, where
we have (somewhat) separate Kconfig options for the filesystem commands
and the filesystems themselves.
This series starts the process of refactoring the bootm logic so that
it can be called from standard boot without using the command line.
Mostly it removes the use of argc, argv and cmdtbl from the internal
logic.
Some limited tidy-up is included, but this is kept to smaller patches,
rather than trying to remove all #ifdefs etc. Some function comments
are added, however.
A simple programmatic boot is provided as a starting point.
This work will likely take many series, so this is just the start.
Size growth with this series for firefly-rk3288 (Thumb2) is:
arm: (for 1/1 boards) all +23.0 rodata -49.0 text +72.0
This should be removed by:
https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/11
but it is not included in this series as it is already large enough.
No functional change is intended in this series.
Changes in v3:
- Add a panic if programmatic boot fails
- Drop RFC tag
Changes in v2:
- Add new patch to adjust position of unmap_sysmem() in boot_get_kernel()
- Add new patch to obtain command arguments
- Fix 'boot_find_os' typo
- Pass in the command name
- Use the command table to provide the command name, instead of "bootm"
Since we can now cleanly disable CMDLINE when needed, drop the rules
which discard the command code. It will not be built in the first
place.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This reverts commit 6cdf6b7a34. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This reverts commit 836b8d4b20. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This reverts commit c1da6fdb5c. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
This patch adds the necessary code to make nonsec booting and PSCI
secondary core management functional on the R528/T113.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Tested-by: Maksim Kiselev <bigunclemax@gmail.com>
Tested-by: Kevin Amadiva <kevin.amadiva@mec.at>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Since the sunxi support nowadays generally prefers #defined register
offsets instead of modeling register layouts using C structs, now is a
good time to do this for PSCI as well. This patch moves away from using
the structs `sunxi_cpucfg_reg` and `sunxi_prcm_reg` in psci.c.
The former struct and its associated header file existed only to support
PSCI code, so also delete them altogether.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
This is to prepare for R528, which does not have the typical
"CPUCFG" block; it has a "CPUX" block which provides these
same functions but is organized differently.
Moving the hardware-access bits to their own functions separates the
logic from the hardware so we can reuse the same logic.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
This patch restructures psci.c to get away from the "many different
function definitions switched by #ifdef" paradigm to the preferred style
of having a single function definition with `if (IS_ENABLED(...))` to
make the optimizer include only the appropriate function bodies instead.
There are no functional changes here.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
At the moment we have each SoC's memory map defined in its own cpu.h,
which is included in include/configs/sunxi_common.h. This will be a
problem with the introduction of Allwinner RISC-V support.
Remove the inclusion of that header file from the common config header,
instead move the required serial base addresses (for the SPL) into a
separate header file. Then include the original cpu.h file only where
we really need it, which is only under arch/arm now.
This disentangles the architecture specific header files from the
generic code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
As the code to switch an ARM core from secure to the non-secure state
needs to know the base address of the Generic Interrupt Controller
(GIC), we read an Arm Cortex defined system register that is supposed to
hold that base address. However there are SoCs out there that get this
wrong, and this CBAR register either reads as 0 or points to the wrong
address. To accommodate those systems, so far we use a macro defined in
some platform specific header files, for affected boards.
To simplify future extensions, replace that macro with a Kconfig variable
that holds this override address, and define a default value for SoCs
that need it.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>
Some functions are not used outside this file, so make them static.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
PPA was a secure firmware developed in-house which is no longer
supported and replaced by TF-A quite some years ago. Drop support
for it.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Rename this so that SPL is first, as per U-Boot convention. Also add
PAYLOAD_ since this is where in memory the parameters for the payload
have been stored.
Signed-off-by: Simon Glass <sjg@chromium.org>
We like to put the SPL first so it is clear that it relates to SPL. Rename
various malloc-related options which have crept in, to stick to this
convention.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Martyn Welch <martyn.welch@collabora.com>
Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com>
Use the misc_init_f event instead, which is designed for this purpose.
All boards with CONFIG_VID already enable CONFIG_EVENT.
Signed-off-by: Simon Glass <sjg@chromium.org>
When PIE is enabled in start.S, u-boot/-spl use __rel_dyn_start
and _rel_dyn_end symbol to be loaded to and executed at a
different address than it was linked at.
u-boot-spl.lds is used in SPL build, but relocation information
section(.rela*) were discarded.
In line number 80 in arch/arm/cpu/armv8/u-boot-spl.lds
/DISCARD/ : { *(.rela*) }
If PIE enabled in SPL, __rel_dyn_start which is defined as
.rel_dyn_start in sections.c will be apended to the end of
.bss section.
In our ASPEED case, size of .bss section would let .rel_dyn_start
without 8-byte alignment, leading to alignment fault when
executing ldp instuction in pie_fix_loop.
Signed-off-by: Kevin Chen <kevin_chen@aspeedtech.com>
Now all linker symbols are declared as type char[]. Though we can
reference the address via both the array name 'var' and its address
'&var'. It's better to unify them to avoid confusing developers.
This patch converts all '&var' linker symbol refrences to the most
commonly used format 'var'.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
It is not a parse error to have a default value of "0" for a "hex" type
entry, instead of "0x0". However, "0" and "0x0" are not treated the
same even by the tools themselves. Correct this by changing the default
value from "0" to "0x0" for all hex type questions that had the
incorrect default. Fix one instance (in two configs) of a default of "0"
being used on a hex question to be "0x0". Remove the cases where a
defconfig had set a value of "0x0" to be used as the default had been
"0".
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Function board_switch_core_volt has not been used since it was
defined
Signed-off-by: Shenlin Liang <liangshenlin@eswincomputing.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
add support for x0-x17 registers used by the SMC calls
In SMCCC v1.2 [1] arguments are passed in registers x1-x17.
Results are returned in x0-x17.
This work is inspired from the following kernel commit:
arm64: smccc: Add support for SMCCCv1.2 extended input/output registers
[1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6?token=
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Allow individual Layerscape boards to opt-out of fsl_setenv_bootcmd
by declaring the original function as weak.
fsl_setenv_bootcmd is used to change the bootcmd based on the
TF-A boot source (e.g QSPI vs SD/MMC) for reasons including
secure boot / integrity measurements and DPAA2 configuration loading.
See previous discussion at [1].
On the Ten64 board, our bootcmd is the same across
all TF-A boot sources so we don't want this behaviour.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
[1] https://patchwork.ozlabs.org/project/uboot/patch/20211110044639.7070-3-matt@traverse.com.au/#2790037
Reviewed-by: Peng Fan <peng.fan@nxp.com>
This reverts commit d927d1a808, reversing
changes made to c07ad9520c.
These changes do not pass CI currently.
Signed-off-by: Tom Rini <trini@konsulko.com>
add support for x0-x17 registers used by the SMC calls
In SMCCC v1.2 [1] arguments are passed in registers x1-x17.
Results are returned in x0-x17.
This work is inspired from the following kernel commit:
arm64: smccc: Add support for SMCCCv1.2 extended input/output registers
[1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6?token=
Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
When DM_SERIAL is enabled on mxs (i.e. imx28) platform, the console
early initialization must be postponed until the driver model is
correctly setup.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
The IMX28 PMU (Power Management Unit) has a dedicated Linear Regulator
to produce (by default) 4.2V output - available outside the chip as
VDD_4P2.
When system is supposed to not use VDD5V as a main power source - instead
the DCDC_BATT is used; it is safe to disable this regulator.
As the in-PMU DCDC switching regulator (from which DCDC_VDDA, DCDC_VDDIO
and DCDC_VDDD are generated) can be driven from DCDC_BATT or output
of this 4P2 regulator - by disabling the latter the use of the DCDC_BATT
is forced.
To be more specific - according to NXP's AN4199 the DCDC_BATT source is
preferred (over VDD5V), as more efficient and stable source for
industrial applications.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
This new Kconfig option allows disabling the in-PMU battery charging
block. This may be required when DCDC_BAT source is powered not from
battery, but from already regulated, good quality source.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
This option sets the current limit for 5V source to zero, so all
the PMU outputs are primarily powered from battery source (DCDC_BAT).
This option may be set on systems, where the 5V is NOT supposed to be
in any scenario powering the system - for example on systems where
DCDC_BAT is connected to fixed and regulated 4.2V source (so the
"battery" is not present).
Signed-off-by: Lukasz Majewski <lukma@denx.de>
