It seems that for aarch64, unless we apply dynamic relocations to the
location being relocated, we fail to boot.
As Fangrui notes:
For dynamic relocations using the RELA format (readelf -Wr), GNU ld
sets the initial content to r_addend; ld.lld doesn't do that by
default (needs --apply-dynamic-relocs).
Otherwise .rodata appears to be full of NUL-bytes before relocation,
causing crashes when trying to invoke the function pointers in
init_sequence_f from initcall_run_list().
Link: https://reviews.llvm.org/D42797
Suggested-by: Fangrui Song <maskray@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Alistair Delva <adelva@google.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
When building the standalone example with llvm, the link step fails:
examples/standalone/libstubs.o: In function `dummy':
include/_exports.h:10: undefined reference to `jt'
include/_exports.h:11: undefined reference to `jt'
include/_exports.h:12: undefined reference to `jt'
include/_exports.h:13: undefined reference to `jt'
include/_exports.h:14: undefined reference to `jt'
examples/standalone/libstubs.o:include/_exports.h:15:
more undefined references to `jt' follow
Indeed, the standalone libstubs.o does use the jt symbol, but it was
marked 'static' in stubs.c. It's strange how gcc builds are working.
Signed-off-by: Alistair Delva <adelva@google.com>
Cc: Rick Chen <rick@andestech.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Pull request for efi-2023-01-rc1-2
Documentation:
* man-page for cls command
* update build requirements
UEFI
* Fix bugs in the Stop() function of the EFi Driver Binding protocol
for block devices
* Avoid EFI_CALL() when invoking CloseProtocol()
When host issues "fastboot reboot fastboot", it's expected that the
board drops the USB connection before resetting.
On some boards, such as Khadas VIM3L and SEI610, this is not the case.
We observe the following error:
$ fastboot reboot fastboot
Rebooting into fastboot OKAY [ 0.004s]
fastboot: error: Failed to boot into userspace fastboot; one or more components might be unbootable.
This does not happen when we use the RST button on the board.
It can be reproduced in linux with:
# echo b > /proc/sysrq-trigger
In this case, we hit a undefined hardware behavior, where D+ and D-
are in an unknown state. Therefore the host can't detect usb
disconnection.
Make sure we always call usb_gadget_release() when a "fastboot reboot"
command is issued.
Note: usb_gadget_release() should be called before g_dnl_unregister()
because g_dnl_unregister() triggers a complete() call on each
endpoint (thus calling do_reset()).
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Remove unused ehci_{setup,shutdown}_phy() helpers now replaced by
generic_{setup,shutdown}_phy().
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Replace ehci_setup_phy() and ehci_shutdown_phy () by respectively
generic_setup_phy() and generic_shutdown_phy().
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Replace ohci_setup_phy() and ohci_shutdown_phy () by respectively
generic_setup_phy() and generic_shutdown_phy().
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
In drivers usb/host/{ehci,ohci}-generic.c, {ehci,ohci}_setup_phy() and
{ehci,ohci}_shutdown_phy() shares 95% of common code.
Factorize this code in new generic_{setup,shudown}_phy() functions.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Take the USB_ETHER ifdef block apart and make use of obj-$(VAR) instead
to include the source files in build. The duplicate CI_UDC entry is now
removed, the USB_DEVICE ifdef is now reduced to core.o ep.o addition,
the ether.o can be conditionally compiled in using USB_ETHER.
No functional change.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
The env_get() might be undefined in case ENV_SUPPORT is disabled,
which may happen e.g. in SPL. Add missing ifdef guard around the
env_get() to prevent build failure.
Signed-off-by: Marek Vasut <marex@denx.de>
Tested-by: Fabio Estevam <festevam@denx.de>
Make it clearer why InstallMultipleProtocolInterfaces is invoked with two
NULLs:
* rename guid to esp_guid
* put protocol GUIDs and the related interfaces on same lines
* add comment
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The CloseProtocol() boot service requires a handle as first argument.
Passing the protocol interface is incorrect.
CloseProtocol() only has an effect if called with a non-zero value for
agent_handle. HandleProtocol() uses an opaque agent_handle when invoking
OpenProtocol() (currently NULL). Therefore HandleProtocol() should be
avoided.
* Replace the LocateHandle() call by efi_search_protocol().
* Remove the CloseProtocol() call.
Fixes: 8d99026f06 ("efi_loader: capsule: support firmware update")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The CloseProtocol() boot service requires a handle as first argument.
Passing the protocol interface is incorrect.
CloseProtocol() only has an effect if called with a non-zero value for
agent_handle. HandleProtocol() uses an opaque agent_handle when invoking
OpenProtocol() (currently NULL). Therefore HandleProtocol() should be
avoided.
* Replace the LocateHandle() call by efi_search_protocol().
* Remove the CloseProtocol() call.
* Remove a superfluous goto.
Fixes: ce3dbc5d08 ("efi_loader: add UEFI GPT measurement")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We want tests to avoid the usage of sudo. Describe that virt-make-fs can
generate disk images without being root.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Packages python3-filelock python3-pytest-xdist as required to run
'make tests'. Add them to the required packages list in the documentation.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The cls command works fine on the serial console. There is no reason to
let it depend on the availability of video.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
- mtd: Update the function name to 'rfree'
- Support NAND ONFI EDO mode for imx8mn architecture
- dm: clk: add missing stub when CONFIG_CLK is deactivated
This fixes the below build error if nand.c is included in
an SPL build.
/work/u-boot/drivers/mtd/nand/raw/nand.c: In function ‘nand_init_chip’:
/work/u-boot/drivers/mtd/nand/raw/nand.c:82:28: error: ‘nand_chip’ undeclared (first use in this function)
82 | struct nand_chip *nand = &nand_chip[i];
| ^~~~~~~~~
/work/u-boot/drivers/mtd/nand/raw/nand.c:82:28: note: each undeclared identifier is reported only once for each function it appears in
/work/u-boot/drivers/mtd/nand/raw/nand.c:84:20: error: ‘base_address’ undeclared (first use in this function); did you mean ‘base_addr’?
84 | ulong base_addr = base_address[i];
| ^~~~~~~~~~~~
| base_addr
Fixes: 068c41f1cc ("Finish conversion CONFIG_SYS_NAND_SELF_INIT to Kconfig")
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Pull request for efi-2023-01-rc1
UEFI:
* Provide driver binding protocol to registered events for block devices
* Code simplification and refactoring
* Fix pylint errors in test_efi_secboot
Other:
* Improve checks for register ranges
- Update RISC-V to use 32bit or 64bit toolchains, depending on if we're
building for 32bit or 64bit CPUs. This requires updating the Docker
container as well to have the 32bit toolchain.
- Assorted platform updates for developerbox, armv8 platforms in
general, TI K3 and AM65 platforms, nuvoton NPCM845 SoC and then clock
driver, ftgpio010 support, and common/board_f cleanups.
The following description is copied from the equivalent patch for the
Linux Kernel proposed by Aurelien Jarno:
>From version 2.38, binutils default to ISA spec version 20191213. This
means that the csr read/write (csrr*/csrw*) instructions and fence.i
instruction has separated from the `I` extension, become two standalone
extensions: Zicsr and Zifencei. As the kernel uses those instruction,
this causes the following build failure:
arch/riscv/cpu/mtrap.S: Assembler messages:
arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Christian Stewart <christian@paral.in>
Reviewed-by: Rick Chen <rick@andestech.com>
For building riscv32 targets we should use the riscv32 toolchain.
Add it to the Docker image.
Drop the riscv toolchain-alias as we do not need it in future.
While in here, update to the latest "jammy" tag.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Rick Chen <rick@andestech.com>
[trini: Update to latest jammy tag]
Signed-off-by: Tom Rini <trini@konsulko.com>
For the TI SoCs affected by errata i2329, enable MDIO manual
mode by default
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
In certain TI SoCs, on the CPSW and ICSS peripherals, there is
a possibility that the MDIO interface returns corrupt data on
MDIO reads or writes incorrect data on MDIO writes. There is also
a possibility for the MDIO interface to become unavailable until
the next peripheral reset.
The workaround is to configure the MDIO in manual mode and disable the
MDIO state machine and emulate the MDIO protocol by reading and writing
appropriate fields in MDIO_MANUAL_IF_REG register of the MDIO controller
to manipulate the MDIO clock and data pins.
More details about the errata i2329 and the workaround is available in:
https://www.ti.com/lit/er/sprz487a/sprz487a.pdf
Add implementation to disable MDIO state machine, configure MDIO in manual
mode and provide software MDIO read and writes via MDIO bitbanging. Allow
the MDIO to be initialized based on the need for manual mode.
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Include linux/sizes.h because it defines SZ_64K which is used in many
places inside k3-udma.c
This fixes the error: ‘SZ_64K’ undeclared which appears during build
time
Signed-off-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
When MMU is already enabled then dcache_enable() does not call mmu_setup()
and so setup_all_pgtables() is also never called.
In this situation when some driver calls mmu_set_region_dcache_behaviour()
function then U-Boot crashes with error message:
Emergency page table not setup.
Fix this issue by explicitly calling setup_all_pgtables() in dcache_enable()
function near condition for mmu_setup().
This change fixes chainloading U-Boot from U-Boot on Turris Mox board which
uses mvneta ethernet driver which calls mmu_set_region_dcache_behaviour().
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
In order to move ppc-specific code out of setup_dest_addr(), provide an
arch-specific variant arch_setup_dest_addr(), that can be used by
architecture code to fix up the initial reloc address.
It is called at the end of setup_dest_addr() initcall and the default
implementation is a nop stub.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
asm/mach_type.h header and CONFIG_MACH_TYPE macro are arm-specific, so move
related bdinfo logic to arch_setup_bdinfo() in arch/arm/lib/bdinfo.c.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
The XTRN_DECLARE_GLOBAL_DATA_PTR declarations in ppc code are permanently
commented out, so there are no users for this macro:
#if 1
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r2")
#else /* We could use plain global data, but the resulting code is bigger */
#define XTRN_DECLARE_GLOBAL_DATA_PTR extern
#define DECLARE_GLOBAL_DATA_PTR XTRN_DECLARE_GLOBAL_DATA_PTR \
gd_t *gd
#endif
Remove all references to this macro, but add a documentation note regarding
the possibility of using plain global data for the GD pointer.
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
