When building imx8mp_evk_defconfig with LTO, the compiler complains
about type mismatch of function imx_eqos_txclk_set_rate() in file
drivers/net/dwc_eth_qos.c:845:12
which contains a weak definition of this function, vs file
arch/arm/mach-imx/imx8m/clock_imx8mm.c
which contains an implementation.
Change the type of this function in the implementation to fix this.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When building with LTO, the compiler complains about type mismatch of
function clk_bsc_enable() in file:
arch/arm/cpu/armv7/kona-common/clk-stubs.c
vs other files that define or use this function:
warning: type of ‘clk_bsc_enable’ does not match original declaration.
Change the type of this function to that of the other usages.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When building keystone with LTO the compiler complains:
Error: selected processor does not support `smc #0' in Thumb mode
Fix this by removing -flto for the file implementing these SMC calls.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
When apf27_defconfig is built with LTO, linking complains about
undefined reference to `nand_boot`. This is because it is referenced
from inline assembly. Make it visible.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
When imx28_xea_defconfig is built with LTO, the compiler complains about
the two different declarations of _start:
include/asm-generic/sections.h as extern void _start(void);
arch/arm/cpu/arm926ejs/mxs/mxs.c as extern uint32_t _start;
Fix this.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Fix LTO build for some thumb-interwork usecases (such as for
da850evm_defconfig), where inline assmebly such as
mrc p15,0,r2,c1,c0,0
causes the compiler to fail during LTO linking with
Error: selected processor does not support `mrc p15,0,r2,c1,c0,0'
in Thumb mode
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
On ARM, the gd pointer is stored in registers r9 / x18. For this the
-ffixed-r9 / -ffixed-x18 flag is used when compiling, but using global
register variables causes errors when building with LTO, and these
errors are very difficult to overcome.
Richard Biener says [1]:
Note that global register vars shouldn't be used with LTO and if they
are restricted to just a few compilation units the recommended fix is
to build those CUs without -flto.
We cannot do this for U-Boot since all CUs use -ffixed-reg flag.
It seems that with LTO we could in fact store the gd pointer differently
and gain performance or size benefit by allowing the compiler to use
r9 / x18. But this would need more work.
So for now, when building with LTO, go the clang way, and instead of
declaring gd a global register variable, we make it a function call via
macro.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68384
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
The Thumb instruction `ldr` is able to move high registers only from
armv7. For armv5 and armv6 we have to use `mov`.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
In style of linked lists, instead of declaring symbols for boundaries
of getopt options array in the linker script, declare corresponding
sections and retrieve the boundaries via static inline functions.
Without this clang's LTO produces binary without any getopt options,
because for some reason it thinks that array is empty (start and end
symbols are at the same address).
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
When building with LTO, the system libc's `errno` variable used in
arch/sandbox/cpu/os.c conflicts with U-Boot's `errno` (defined in
lib/errno.c) with the following error:
.../ld: errno@@GLIBC_PRIVATE: TLS definition in /lib64/libc.so.6
section .tbss mismatches non-TLS reference in
/tmp/u-boot.EQlEXz.ltrans0.ltrans.o
To avoid this conflict use different asm label for this variable when
CONFIG_SANDBOX is enabled.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Some toolchains are compiled so that they pass a --build-id=something
parameter to the linker implicitly.
This causes U-Boot LTO linking to fail with something like:
ld: section .note.gnu.build-id LMA ... overlaps section .text LMA ...
because U-Boot's link scripts do not currently handle .note.gnu.build-id
section.
Fix this by explicitly disabling build-id.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add plumbing for building U-Boot with Link Time Optimizations.
When building with LTO, $(PLATFORM_LIBS) has to be in --whole-archive /
--no-whole-archive group, otherwise some functions declared in assembly
may not be resolved and linking may fail.
Note: clang may throw away linker list symbols it thinks are unused when
compiling with LTO. To force these symbols to be included, we refer to
them via the __ADDRESSABLE macro in a C file generated from compiled
built-in.o files before linking.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently we use incremental linking (ld -r) to link several object
files from one directory into one built-in.o object file containing the
linked code from that directory (and its subdirectories).
Linux has, some time ago, moved to thin archives instead.
Thin archives are archives (.a) that do not really contain the object
files, only references to them.
Using thin archives instead of incremental linking
- saves disk space
- apparently works better with dead code elimination
- makes things easier for LTO
The third point is the important one for us. With incremental linking
there are several options how to do LTO, and that would unnecessarily
complicate things.
We have to use the --whole-archive/--no-whole-archive linking option
instead of --start-group/--end-group, otherwise linking may fail because
of unresolved symbols, or the resulting binary will be unusable.
We also need to use the P flag for ar, otherwise final linking may fail.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
Indent the linking commands so that they look cosmetically better.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When compiling with LTO, the compiler fails with an error saying that
`crc_table` causes a section type conflict with `efi_var_buf`.
This is because both are declared to be in the same section (via macro
`__efi_runtime_data`), but one is const while the other is not.
Put this variable into the section .rodata.efi_runtime, instead of
.data.efi_runtime, via macro __efi_runtime_rodata.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Heinrich Schuchardt <xypron.gpk@gmx.de>
Add $(CFLAGS_EFI) and remove $(CFLAGS_NON_EFI) for
efi_selftest_miniapp_exception.o.
The removal is needed when compiling with LTO - this object file needs
to be compiled without -flto.
The adding is for consistency with other miniapps.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add macro __efi_runtime_rodata, for const variables with similar purpose
as those using __efi_runtime_data.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Document the macros __efi_runtime and __efi_runtime_data in Sphinx
style.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When linking with LTO, the compiler complains about type mismatch of
variables `__efi_runtime_start`, `__efi_runtime_stop`,
`__efi_runtime_rel_start` and `__efi_runtime_rel_stop`:
include/efi_loader.h:218:21: warning: type of ‘__efi_runtime_start’
does not match original
declaration [-Wlto-type-mismatch]
218 | extern unsigned int __efi_runtime_start, __efi_runtime_stop;
| ^
arch/sandbox/lib/sections.c:7:6: note: ‘__efi_runtime_start’ was
previously declared here
7 | char __efi_runtime_start[0] __attribute__((section(".__efi_run
| ^
Change the type to char[] in include/efi_loader.h.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It seems that sometimes (happening on ARM64, for example with
turris_mox_defconfig) GCC, when linking with LTO, changes the symbol
names of some functions, for example lib/string.c's memcpy() function to
memcpy.isra.0.
This is a problem however when GCC for a code such as this:
struct some_struct *info = get_some_struct();
struct some struct tmpinfo;
tmpinfo = *info;
emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo.
This then results in the following linking error:
.../lz4.c:93: undefined reference to `memcpy'
.../uuid.c:206: more undefined references to `memcpy' follow
GCC's documentation says this about -nodefaultlibs option:
The compiler may generate calls to "memcmp", "memset", "memcpy" and
"memmove". These entries are usually resolved by entries in libc.
These entry points should be supplied through some other mechanism
when this option is specified.
Make these functions visible by using the __used macro to avoid this
error.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
Improve the regular expression that matches unittest symbols in
u-boot.sym.
Currently we do not enforce no prefix in symbol string, but with the
soon to come change in linker lists declaring lists and entries with the
__ADDRESSABLE macro (because of LTO), the symbol file will contain for
every symbol of the form
_u_boot_list_2_ut_X_2_Y
also symbol
__UNIQUE_ID___addressable__u_boot_list_2_ut_X_2_YN,
(where N at the end is some number).
In order to avoid matching these additional symbols, ensure that the
character before "_u_boot_list_2_ut" is not a symbol name character.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
This commit does the same thing as Linux commit 33def8498fdd.
Use a more generic form for __section that requires quotes to avoid
complications with clang and gcc differences.
Remove the quote operator # from compiler_attributes.h __section macro.
Convert all unquoted __section(foo) uses to quoted __section("foo").
Also convert __attribute__((section("foo"))) uses to __section("foo")
even if the __attribute__ has multiple list entry forms.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This is how Linux does this now, see Linux commit 339f29d91acf.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
There is a serious bug in regmap_read() and regmap_write() functions
where an uint pointer is cast to (void *) which is then cast to (u8 *),
(u16 *), (u32 *) or (u64 *), depending on register width of the map.
For example given a regmap with 16-bit register width the code
int val = 0x12340000;
regmap_read(map, 0, &val);
only changes the lower 16 bits of val on little-endian machines.
The upper 16 bits will remain 0x1234.
Nobody noticed this probably because this bug can be triggered with
regmap_write() only on big-endian architectures (which are not used by
many people anymore), and on little endian this bug has consequences
only if register width is 8 or 16 bits and also the memory place to
which regmap_read() should store it's result has non-zero upper bits,
which it seems doesn't happen anywhere in U-Boot normally. CI managed to
trigger this bug in unit test of dm_test_devm_regmap_field when compiled
for sandbox_defconfig using LTO.
Fix this by utilizing an union { u8; u16; u32; u64; } and reading data
into this union / writing data from this union.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Pratyush Yadav <p.yadav@ti.com>
There is no good reason to use a sequence from rand() here. We may as well
invent our own sequence.
This should molify Coverity which does not use rand() being used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 312949)
Clang has -Wself-assign enabled by default under -Wall and so when
building with -Werror we would get an error here. Inspired by Linux
kernel git commit a21151b9d81a ("tools/build: tweak unused value
workaround") make use of the fact that both Clang and GCC support
casting to `void` as the method to note that something is intentionally
unused.
Signed-off-by: Tom Rini <trini@konsulko.com>
The V3U SoC has several unlock registers, one per register group. They
reside at offset zero in each 0x200 bytes-sized block.
To avoid adding yet another table to the PFC implementation, this
patch adds the option to specify an address mask instead of the fixed
address in sh_pfc_soc_info::unlock_reg.
This is a direct port of Linux 5.12 commit e127ef2ed0a6
("pinctrl: renesas: Implement unlock register masks") by
Ulrich Hecht <uli+renesas@fpond.eu>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
The help text for Gen2 entries had a copy paste error, still containing
the Gen3 string, while the description was correctly listing Gen2. Fix
the help text.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
The help text in the Kconfig file was always a copy of the same thing.
Move single copy into the common PFC driver entry instead. Also fix a
copy-paste error in the PFC help text, which identified PFC as clock.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Pass struct udevice to rcar_gpio_set_direction() in preparation of
quirk handling in rcar_gpio_set_direction(). No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Most of the PLLx, MAIN, FIXED clock handlers are calling very similar
code, which determines parent rate and then applies multiplication and
division. The only difference is whether multiplication is fixed factor
or coming from CRx register. Deduplicate the code into a single function.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Base on Linux v5.10-rc2, commit 8b652aa8a1fb by Yoshihiro Shimoda
To support other register layouts in the future, add register pointers
of {control,status,reset,reset_clear}_regs into struct cpg_mssr_info
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
From Linux v5.10-rc2, commit ffbf9cf3f946 by Yoshihiro Shimoda
Introduce enum clk_reg_layout to support multiple register layout variants
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
CPG IP in some specific Renesas SoCs (i.e. new R8A779A0 V3U SoC)
requires a different setting procedure. Make struct cpg_mssr_info
accessible to handle the clock setting in that case.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
The MODEMR register offset changed on R8A779A0, make the MODEMR offset
configurable. Fill the offset in on all clock drivers. No functional
change.
Based off "clk: renesas: Make CPG Reset MODEMR offset accessible from
struct cpg_mssr_info" by Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
This supports RPCD2 clock handling. While at it, add the check point
for RPC-IF clock RPCD2 Frequency Division Ratio, since it must be odd
number
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
This patch fixes Realtime Module Stop Control Register (RMSTPCR) offsets
based on R-Car Gen3, H2/M2/M2N/E2/E2X hardware user's manual.
The r8a73a4 only has RMSTPCR0 - RMSTPCR5 so this calculation change
doesn't affect it.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Reinstate RPC clock on D3/E3 after Linux 5.12 synchronization.
The D3 and E3 clock drivers do not contain RPC clock entries
mainline Linux yet.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
With commit 8678776df6 (arm: mvebu: armada-3720-uDPU: fix PHY mode
definition to sgmii-2500) the PHY mode was switch to "sgmii-2500", even
when this is functionally incorrect since "2500base-x" was not supported
in U-Boot at that time. As this mode is now supported (at least present
in the headers), this patch moves back to the orinal version.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Jakov Petrina <jakov.petrina@sartura.hr>
Cc: Vladimir Vid <vladimir.vid@sartura.hr>
Cc: Luka Perkov <luka.perkov@sartura.hr>
Until now the mvpp2 driver used an extra 'phy-speed'
DT property in order to differentiate between the
SGMII and SGMII @2.5GHz. As there is a dedicated
PHY_INTERFACE_MODE_SGMII_2500 flag to mark the latter
start using it and drop the custom flag.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Stefan Chulski <stefanc@marvell.com>
Reviewed-by: Nadav Haklai <nadavh@marvell.com>
Tested-by: Nadav Haklai <nadavh@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
