Tom Rini [Wed, 10 Apr 2024 23:06:27 +0000 (17:06 -0600)]
Merge patch series "pxe: Allow extlinux booting without CMDLINE enabled"
Simon Glass <sjg@chromium.org> says:
This series is the culmanation of the current line of refactoring
series. It adjusts pxe to call the booting functionality directly
rather than going through the command-line interface.
With this is is possible to boot using the extlinux bootmeth without
the command line enabled.
Simon Glass [Fri, 15 Dec 2023 04:19:06 +0000 (21:19 -0700)]
fastboot: Remove dependencies on CMDLINE
It is possible to boot a kernel without CMDLINE being enabled. Update
the implementation to handle this, and drop the condition from the
FASTBOOT config.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Simon Glass [Fri, 15 Dec 2023 04:19:01 +0000 (21:19 -0700)]
bootm: Make OS booting dependent on BOOTM
Booting an OS does not require the 'bootm' command, so change the
condition for these options.
Move them into boot/ so they don't depend on CMDLINE
Note that CMD_BOOTM_PRE_LOAD has been put directly into the bootm code
so will need some additional refactoring (and a test!) to allow it to
change over.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Fri, 15 Dec 2023 04:19:00 +0000 (21:19 -0700)]
bootm: Add a Kconfig option for bootm functionality
Create a separate Kconfig option which enables the bootm logic,
separate from the 'bootm' command. This will eventually allow booting
without CMDLINE enabled.
Update boards which disable CMD_BOOTM to disable BOOTM instead, since
CMD_BOOTM now depends on BOOTM
Simon Glass [Mon, 4 Dec 2023 00:29:31 +0000 (17:29 -0700)]
x86: zboot: Move environment setting into zboot_load()
The only difference between the command and the underlying logic is the
setting of envrionment variables. Move this out of the command
processing since it needs to be done in any case.
Simon Glass [Mon, 4 Dec 2023 00:29:28 +0000 (17:29 -0700)]
x86: zboot: Create a separate ZBOOT option for zboot logic
Most of the functionality of zboot is contained in the logic which
handles a zimage. Create a separate Kconfig for the logic so that it can
(later) be used without the command itself being enabled.
Enable ZBOOT by default on x86, with the command depending on that. The
existing 'imply' can therefore be removed.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Mon, 4 Dec 2023 00:29:27 +0000 (17:29 -0700)]
x86: zboot: Move command code into its own file
Much of the code in zimage.c deals with the zboot command. Move it into
a sepatate zboot.c file within the cmd/ directory. This will eventually
allow use of the zimage logic without the command being enabled.
Tom Rini [Wed, 10 Apr 2024 17:51:58 +0000 (11:51 -0600)]
Merge tag 'xilinx-for-v2024.07-rc1' of https://source.denx.de/u-boot/custodians/u-boot-microblaze
Xilinx changes for v2024.07-rc1
xilinx:
- Do not call env_get_location when !ENV_IS_NOWHERE
- Add FDT_FIXUP_PARTITIONS support
- Fix legacy format MAC decoding
zynqmp:
- Enable semihosting SPL support
- DT updates
- Kconfig resort/cleanup
- Don't describe second image/capsule if !SPL
- Add support for dfu/capsule description via MTD
- Support JTAG as alternative boot mode
- Add support for TEG soc variant
zynqmp-kria:
- Wire usb4 boot device
- Update SDIO tristate pin configuration
- Disable SPI_FLASH_BAR to avoid issue with SPI after update
mbv:
- Enable SPL and binman
- Small platform changes
zynqmp-nand:
- Error out in case of unsupported SW ECC
- Clean error path
versal-net:
- Support multiple locations for variables
Vincent Stehlé [Tue, 2 Apr 2024 11:29:16 +0000 (13:29 +0200)]
trace: use dynamic string buffer in make_flamegraph()
The str[] buffer declared in make_flamegraph() is used to hold strings
representing the full call-stacks recorded in traces. The size of this
buffer is currently 500 characters and this works well for the documented
examples.
However, it is possible to exhaust this buffer when processing traces
captured when running the UEFI shell on aarch64 sandbox for example.
Indeed, the maximum length needed for such traces can reach 780 characters.
As it is difficult to evaluate the maximum size that would ever be needed
for all the possible traces, let's use a dynamically allocated `abuf'
instead, which we reallocate when needed.
This fixes the following error:
String too short (500 chars)
While at it, fix a few typos in strings and comments.
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Cc: Michal Simek <michal.simek@amd.com>
U-Boot only knows absolute file paths. It is inconsistent to require that
saving to an ext4 file system should use a leading '/' while reading does
not. Remove the superfluous check.
The NFS protocol uses file handles to refer to file or directory.
In NFSv2 file handles have a fixed size of 32 bytes.
In NFSv3 file handles have a variable length up to 64 bytes. This is
also true for the MOUNT protocol. [1]
When the NFSv3 server replies with a file handle length > 32 bytes, U-Boot
only copies 32 bytes of that file handle and the next LOOKUP Call fails:
BIOS> nfs ${loadaddr} 192.168.1.51:/nfsroot/opos93dev-br/boot/Image
Using ethernet@428a0000 device
File transfer via NFS from server 192.168.1.51; our IP address is 192.168.1.133
Filename '/nfsroot/opos93dev-br/boot/Image'.
Load address: 0x80400000
Loading: *** ERROR: File lookup fail
done
BIOS>
Looking at this transfer in Wireshark, we can see that the server
replies with the following file handle:
Open for reading as O_RDONLY instead of O_RDWR:
the only usage of the fd is for the single read() below;
this prevented
mkimage -f auto -A arm64 \
-T kernel -C lz4 -d Image-6.6.15.lz4 \
-b mt8173-elm-hana-6.6.15.dtb outf
when the inputs were unwritable.
fs: ext4: make "File System is consistent\n" a debug message
When accessing an ext2 system the message "File System is consistent\n" is
shown after each write. This is superfluous noise. Only write a debug
message.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Greg Malysa [Wed, 20 Mar 2024 02:16:07 +0000 (22:16 -0400)]
build: Revive and update LDR format support
LDR format files are used primarily by Analog Devices processors but may
be of interest to other vendors. Previously support existed for this
format as part of the U-Boot build, but it has been unmaintained and
unused for a long time. In preparation for adding support for modern ADI
processors that use LDR, modernize the LDR support:
- Introduce CONFIG_LDR_CPU as the CPU string recognized by the LDR tool
may not be the same as CONFIG_CPU
- Add an SPL target that repackages u-boot-spl inside an LDR file
An almost identical target for packaging u-boot into an LDR file already
exists and did not need to be created.
Co-developed-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com> Signed-off-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com> Signed-off-by: Ian Roberts <ian.roberts@timesys.com> Signed-off-by: Greg Malysa <greg.malysa@timesys.com>
Tom Rini [Tue, 19 Mar 2024 16:51:31 +0000 (12:51 -0400)]
scripts/Makefile.spl: Use 'sort' in SHRUNK_ARCH_DTB rule
With configs such as "am64x_evm_a53" or "imx8mp_venice" which list
multiple device trees to build we get a warning such as:
scripts/Makefile.spl:578: target 'spl/dts/freescale/' given more than once in the same rule
If we sort this list first the warning goes away.
Tested-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Jixiong Hu [Tue, 19 Mar 2024 09:20:40 +0000 (17:20 +0800)]
fs: ext4: Change the Settings of file permissions
When a file is created in the linux and corresponding file permission
is set, if the file needs to be modified in uboot during the startup
process, the modified file permission will be reset to 755. Therefore,
when the ext4fs_write() function is called, if the file already exists,
the file permission of the new file is equal to the file permission of
the existing file.
Caleb Connolly [Mon, 18 Mar 2024 23:16:36 +0000 (23:16 +0000)]
cmd: sysboot: null check filename
Currently if ${bootfile} is unset and sysboot is invoked with no
filename specified then U-Boot will crash will a null-pointer
dereference. Add the missing check and a matching error print.
arm64: Fix map_range() not splitting mapped blocks
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.
Petr Zejdl [Thu, 4 Apr 2024 11:44:22 +0000 (13:44 +0200)]
xilinx: common: Fix MAC address read from EEPROM
The upper-to-lowercase character conversion now avoids altering the
MAC address field. In the previous version, this alteration corrupted
the MAC address.
The Kria board features a recovery application that activates
when the FW_EN button is pressed.
Upon power-up flash operates in 3B mode, However, the recovery
application changes it back to 4B mode.
Currently, after a reset, u-boot activates CONFIG_SPI_FLASH_BAR
and assumes the flash is in 3B mode. However, there's no code
or reset lines connected to the flash that could return it to
3B mode. To resolve this issue, changes were made to disable
CONFIG_SPI_FLASH_BAR, which activates 4-byte opcodes.
- RISC-V: Support backtrace and improve isa extension parsing
- cpu: Add cv1800b SoC support
- board: Add Milk-V Mars board support
- board: Add Milk-V Duo SD card support
The differences between the Milk-V Mars board and the VisionFive 2 board
are small enough that we can support both using the same U-Boot build.
* The model and compatible property are taken from proposed Linux patches.
* The EEPROM is atmel,24c02 according to the vendor U-Boot.
* The second Ethernet port is not available.
usb@10100000 does not exist in U-Boot yet. So we don't have to reflect
differences in usage here.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Currently in set_fdtfile() we set the value of environment variable fdtfile
unconditionally. The implies that a value in the environment will be
ignored.
With the patch environment variable fdtfile will only be set if it does not
yet exist. This requires that CONFIG_DEFAULT_FDT_FILE is not set.
Now the user can either set and save fdtfile interactively or in the U-Boot
configuration to overrule the device-tree name chosen based on the
hardware in set_fdtfile().
Reported-by: E Shattow <lucent@gmail.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Łukasz Stelmach [Thu, 28 Mar 2024 09:58:24 +0000 (10:58 +0100)]
riscv: Move virtio scan to board_late_init()
When virtio_init() gets called from board_init() PCI isn't ready. Thus,
virtio-over-PCI (e.g. network interfaces) devices can't be detected and
used without additional `virtio scan` scan in the shell or a script.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Conor Dooley [Mon, 18 Mar 2024 15:16:03 +0000 (15:16 +0000)]
riscv: support extension probing using riscv, isa-extensions
A new property has been added, with an extensive rationale at [1], that
can be used in place of "riscv,isa" to indicate what extensions are
supported by a given platform that is a list of strings rather than a
single string. There are some differences between the new property,
"riscv,isa-extensions" and the incumbent "riscv,isa" - chief among them
for the sake of parsing being the list of strings, as opposed to a
string. Another advantage is strictly defined meanings for each string
in a dt-binding, rather than deriving meaning from RVI standards. This
will likely to some divergence over time, but U-Boot's current use of
extension detection is very limited - there are just four callsites of
supports_extension() in mainline U-Boot.
These checks are limited to two checks for FPU support and two checks
for "s" and "u". "s" and "u" are not supported by the new property, but
they were also not permitted in "riscv,isa". These checks are only
meaningful (or run) in M-Mode, in which case supports_extension() does
not parse the devicetree anyway.
Add support for the new property in U-Boot, prioritising it, before
falling back to the, now deprecated, "riscv,isa" property if it is not
present.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Conor Dooley [Mon, 18 Mar 2024 15:16:02 +0000 (15:16 +0000)]
riscv: don't read riscv, isa in the riscv cpu's get_desc()
cpu_get_desc() for the RISC-V CPU currently reads "riscv,isa" to get
the description, but it is no longer a required property and cannot be
assummed to always be present, as the new "riscv,isa-extensions" and
"riscv,isa-base" properties may be present instead.
On RISC-V, cpu_get_desc() has two main uses - firstly providing an
informational name for the CPU for smbios or at boot with
DISPLAY_CPUINFO etc and secondly it forms the basis of ISA extension
detection in supports_extension() as it returns (a portion of) an ISA
string.
cpu_get_desc() returns a string, which aligned with "riscv,isa" but
the new property is a list of strings. Rather than add support for
the list of strings property, which would require creating an isa
string from "riscv,isa-extensions", modify the RISC-V CPU's
implementaion of cpu_get_desc() return the first compatible as the
cpu description instead. This may be fine for the informational cases,
but it would break extension dtection, given supports_extension()
expects cpu_get_desc() to return an ISA string.
Call dev_read_string() directly in supports_extension() to get the
contents of "riscv,isa" so that extension detection remains functional.
As a knock-on affect of this change, extension detection is no longer
broken for long ISA strings. Previously if the ISA string exceeded the
32 element array that supports_extension() passed to cpu_get_desc(),
it would return ENOSPC and no extensions would be detected.
This bug probably had no impact as U-Boot does not currently do anything
meaningful with the results of supports_extension() and most SoCs
supported by U-Boot don't have anywhere near that complex of an ISA
string. The QEMU virt machine's CPUs do however, so extension detection
doesn't work there.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Tom Rini [Mon, 8 Apr 2024 20:33:59 +0000 (14:33 -0600)]
Merge tag 'efi-2024-07-rc1' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2024-07-rc1
Documentation:
* improve description of FAT partition name generation
* add missing :: in doc/usage/cmd/itest.rst
UEFI:
* fix address mode for __efi_runtime_start/stop,
__efi_runtime_rel_start/stop
* fix size of variable attribute constants
* enable booting via EFI boot manager by default
* correct the sequence of the EFI boot methods
* correct finding the default EFI binary
* don't delete variable from memory if update failed
* fix append write behavior to non-existent variable
* Use binman for testing capsule updates on the sandbox
* Consider capsule test files in .gitignore and make clean
efi_loader: access __efi_runtime_rel_start/stop without &
A symbol defined in a linker script (e.g. __efi_runtime_rel_start = .;)
is only a symbol, not a variable and should not be dereferenced.
The common practice is either define it as
extern uint32_t __efi_runtime_rel_start or
extern char __efi_runtime_rel_start[] and access it as
&__efi_runtime_rel_start or __efi_runtime_rel_start respectively.
So let's access it properly since we define it as an array
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_loader: access __efi_runtime_start/stop without &
A symbol defined in a linker script (e.g. __efi_runtime_start = .;) is
only a symbol, not a variable and should not be dereferenced.
The common practice is either define it as
extern uint32_t __efi_runtime_start or
extern char __efi_runtime_start[] and access it as
&__efi_runtime_start or __efi_runtime_start respectively.
So let's access it properly since we define it as an array
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* The sandbox must not use an arbitrary file name bootsbox.efi but the
file name matching the host architecture to properly boot the respective
file. We already have an include which provides a macro with the name of
the EFI binary. Use it.
* The path to the EFI binary should be absolute.
* The path and the file name must be capitalized to conform to the UEFI
specification. This is important when reading from case sensitive
file systems.
efi_loader: move HOST_ARCH to version_autogenerated.h
efi_default_filename.h requires HOST_ARCH to be defined. Up to now we
defined it via a CFLAGS. This does not scale. Add the symbol to
version_autogenerated.h instead.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_loader: Don't delete variable from memory if adding a new one failed
Our efi_var_mem_xxx() functions don't have a replace variant. Instead we
add a new variable and delete the old instance when trying to replace a
variable. Currently we delete the old version without checking the new
one got added
Signed-off-by: Ilias Apalodimas <apalos@gmail.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Masahisa Kojima [Tue, 2 Apr 2024 09:09:50 +0000 (18:09 +0900)]
efi_loader: fix append write behavior to non-existent variable
Current "variables" efi_selftest result is inconsistent
between the U-Boot file storage and the tee-based StandaloneMM
RPMB secure storage.
U-Boot file storage implementation does not accept SetVariale
call to non-existent variable with EFI_VARIABLE_APPEND_WRITE,
it return EFI_NOT_FOUND.
However it is accepted and new variable is created in EDK II
StandaloneMM implementation if valid data and size are specified.
If data size is 0, EFI_SUCCESS is returned.
Since UEFI specification does not clearly describe the behavior
of the append write to non-existent variable, let's update
the U-Boot file storage implementation to get aligned with
the EDK II reference implementation.
Sughosh Ganu [Wed, 27 Mar 2024 10:49:02 +0000 (16:19 +0530)]
capsule: Makefile: add the generated files to CLEAN_FILES list
A certain set of capsule files are now generated as part of the
sandbox build. Add these files to the CLEAN_FILES list for deletion on
invoking any of the cleanup targets.
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canoncal.com> Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Sughosh Ganu [Wed, 27 Mar 2024 10:49:00 +0000 (16:19 +0530)]
sandbox: capsule: binman: generate some capsules as part of build
Currently, all the capsules for the sandbox platform are generated at
the time of running the capsule tests. To showcase generation of
capsules through binman, generate all raw(non FIT payload) capsules
needed for the sandbox platform as part of the build. This acts as an
illustrative example for generating capsules as part of a platform's
build.
Make corresponding change in the capsule test's configuration to get
these capsules from the build directory.
Sughosh Ganu [Wed, 27 Mar 2024 10:48:59 +0000 (16:18 +0530)]
sandbox: capsule: remove capsule related configs
The capsule update testing is carried out only on the sandbox and
sandbox_flattree variants. Remove the capsule update related configs
from the other sandbox variants. This ensures that the capsule files
are generated only on variants which are used for the feature's
testing.
- Convert imx8mp-beacon and verdin-imx8mm/verdin-imx8mp to OF_UPSTREAM.
- Enable PCIe NVMe support on imx8mp_beacon.
- Fix Ethernet and board detection on mx6cuboxi.
- Fix signature_block_hdr struct fields.
- Fix imx9_probe_mu prototype and make it to get called in
EVT_DM_POST_INIT_R.
- Test whether ethernet node is enabled before reading MAC EEPROM on
DHSOM SoMs.
Tom Rini [Fri, 5 Apr 2024 21:23:13 +0000 (17:23 -0400)]
Merge tag 'qcom-next-2024Apr04' of https://source.denx.de/u-boot/custodians/u-boot-snapdragon
- Ethernet, i2c, and USB support are now enabled by default
- The clock driver gets some bug fixes and cleanup
- Invalid FDTs are now properly detected in board_fdt_blob_setup().
- The pinctrl driver gains preparatory support for per-pin function
muxes.
- Support is added for two generations of Qualcomm HighSpeed USB PHY
- A power domain driver is added for the Globall Distributed Switch
Controllers on the GCC hardware block.
- SDM845 gains USB host mode support.
- OF_LIVE is enabled by default for Qualcomm platforms
- Some U-Boot devicetree compatibility fixups are added during init to
improve compatbility with upstream DT.
There is no runtime error in the current u-boot code. The only user of
struct signature_block_hdr is the "get_container_size" function in the
"arch/arm/mach-imx/image-container.c" file, and it's only using the very
first fields of the struct (which are in the correct position) and thus
there is no runtime failure.
On the other hand, extending the code to get the data encryption key
blob offset on the signature header gives a wrong value as the field is
in the wrong order.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
verdin-imx8mm/verdin-imx8mp: move imx verdins to OF_UPSTREAM
Move verdin-imx8mm and verdin-imx8mp to OF_UPSTREAM:
- handle the fact that dtbs now have a 'freescale/' prefix
- imply OF_UPSTREAM
- remove redundant files from arch/arm/dts leaving only the
*-u-boot.dtsi files
- update MAINTAINERS files
Josua Mayer [Sat, 30 Mar 2024 21:35:55 +0000 (18:35 -0300)]
mx6cuboxi: Fix Ethernet after DT sync with Linux
The i.MX6 Cubox-i and HummingBoards can have different PHYs at varying
addresses. U-Boot needs to auto-detect which phy is actually present,
and at which address it is responding.
Auto-detection from multiple phy nodes specified in device-tree does not
currently work correct. As a work-around merge all three possible phys
into one node with the special address 0xffffffff which indicates to the
generic phy driver to probe all addresses.
Signed-off-by: Josua Mayer <josua@solid-run.com>
[fabio: Added the changes to imx6qdl-sr-som-u-boot.dtsi.] Signed-off-by: Fabio Estevam <festevam@gmail.com> Tested-by: Christian Gmeiner <cgmeiner@igalia.com> Tested-by: Christian Gmeiner <cgmeiner@igalia.com>
Marek Vasut [Tue, 12 Mar 2024 21:15:58 +0000 (22:15 +0100)]
ARM: imx: stm32: Test whether ethernet node is enabled before reading MAC EEPROM on DHSOM
Check whether the ethernet interface is enabled at all before reading
MAC EEPROM. As a cost saving measure, it can happen that the MAC EEPROM
is not populated on SoMs which do not use ethernet.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Neil Armstrong [Fri, 29 Mar 2024 17:51:52 +0000 (18:51 +0100)]
dts: meson: Drop redundant G12A, G12B & SM1 devicetree files
Since meson G12A, G12B & SM1 based boards switched to using upstream DT,
so drop redundant files from arch/arm/dts directory. Only *-u-boot.dtsi files
kept in arch/arm/dts directory for these boards.
projects / u-boot.git / log