Robert Nelson [Sat, 4 Nov 2023 08:11:00 +0000 (03:11 -0500)]
arm: dts: Add k3-j721e-beagleboneai64
BeagleBoard.org BeagleBone AI-64 is an open source hardware single
board computer based on the Texas Instruments TDA4VM SoC featuring
dual-core 2.0GHz Arm Cortex-A72 processor, C7x+MMA and 2 C66x
floating-point VLIW DSPs, 3x dual ARM Cortex-R5 co-processors,
2x 6-core Programmable Real-Time Unit and Industrial Communication
SubSystem, PowerVR Rogue 8XE GE8430 3D GPU. The board features 4GB
DDR4, USB3.0 Type-C, 2x USB SS Type-A, miniDisplayPort, 2x 4-lane
CSI, DSI, 16GB eMMC flash, 1G Ethernet, M.2 E-key for WiFi/BT, and
BeagleBone expansion headers.
This board family can be indentified by the BBONEAI-64-B0 in the
at24 eeprom:
Nishanth Menon [Sat, 4 Nov 2023 08:01:35 +0000 (03:01 -0500)]
board: Move beagleplay under beagle vendor folder
Move beagleplay support away from ti/am62x to it's own beagle vendor
folder.
This forms the starting point for new beagle platforms added under it's
own board vendor folder.
As part of this create all the associated files with a bare minimum
beagleplay.c file.
Suggested-by: Andrew Davis <afd@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Bryan Brattlof <bb@ti.com>
[trini: Update k3-binman.dtsi to use full path to scheme.yaml now] Signed-off-by: Tom Rini <trini@konsulko.com>
Nishanth Menon [Sat, 4 Nov 2023 08:01:33 +0000 (03:01 -0500)]
arm: dts: k3-am625-beagleplay-u-boot/r5: Just depend on k3-binman.dtsi
With the upcoming folder separation, there is no further need to depend
on am625-binman.dtsi. Duplicate the existing definitions to u-boot.dtsi
and r5.dts as appropriate.
Nishanth Menon [Sat, 4 Nov 2023 07:21:50 +0000 (02:21 -0500)]
doc: board: ti: j721e_evm: Use board relative path for include directives
When using include directives within a section that is included by non
TI board rst file, k3.rst and other include paths need to be relative to
doc/board/ base.
Nishanth Menon [Sat, 4 Nov 2023 07:21:49 +0000 (02:21 -0500)]
configs: j7200_evm_a72_defconfig: Switch to bootstd
Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.
Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Nishanth Menon [Sat, 4 Nov 2023 07:21:48 +0000 (02:21 -0500)]
configs: j7200: Remove HBMC_AM654 config
Kernel commit 1b77265626a4 ("arm64: dts: ti: k3-j7200-mcu-wakeup: Add
HyperBus node") was merged to kernel without its dependent patch [1].
Similar fix is needed in U-Boot, and hbmc currently breaks boot. Till
this gets fixed in U-Boot, disable the config by default so that the
hbmc probe that happens in board/ti/j721e/evm.c will not take place
and lead to boot failure.
This is similar to the approach in commit 5b2671594b80 ("configs:
j721e: Remove HBMC_AM654 config"), introduced to j7200 evm platform.
Nishanth Menon [Sat, 4 Nov 2023 07:21:47 +0000 (02:21 -0500)]
arm: mach-k3: j721e: Improve support for UDA FS
Commit 5019170970ad ("arch: arm: mach-k3: j721e: add support for UDA
FS") introduced basic UDA FS support, however, we can Take approach
similar to commit 0f1c1e8b368b ("arm: mach-k3: am625: Add support for
UDA FS"). While boot partition support with EMMC boot is useful, it is
constrained by the size of boot hardware partition itself.
In the case of K3 devices, tispl images can contain OP-TEE images that
can substantially vary in size and the u-boot image itself can vary over
time as we enable various features.
So use the CSD information in the case of EMMC_BOOT configuration being
enabled to pick boot partition or UDA FS mode operation to pick.
If EMMC_BOOT is disabled, then depend on filesystem configuration to
pick data from UDA.
Nishanth Menon [Sat, 4 Nov 2023 07:21:44 +0000 (02:21 -0500)]
arm: mach-k3: Kconfig: Introduce a symbol to indicate J7200
J7200 shares quite a few characteristics with J721E. However a few sets
are different. Introduce a Kconfig to differentiate the two to allow for
new boards to be introduced in a seamless manner.
Nishanth Menon [Sat, 4 Nov 2023 07:21:43 +0000 (02:21 -0500)]
configs: j721e_evm_a72_defconfig: Switch to bootstd
Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.
Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Nishanth Menon [Sat, 4 Nov 2023 02:45:11 +0000 (21:45 -0500)]
arm: mach-k3: Move TI dummy keys out of board folder
This file is used to emulate customer keys on TI development board
ecosystems, move it out of board/ directory and into mach-k3. And
change the relative paths to absolute paths in the binman paths.
While at it, drop the reference in verdin-binman file which is
redundant.
Nishanth Menon [Sat, 4 Nov 2023 02:45:10 +0000 (21:45 -0500)]
arm: mach-k3: Move K3 degenerate keys out of board folder
This file is common for all of K3, move it out of board/ directory and
into mach-k3. And change the relative paths to absolute paths in the
binman paths.
While at it, drop the reference in verdin-binman file which is
redundant.
Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Andrew Davis <afd@ti.com>
Andrew Davis [Tue, 14 Nov 2023 15:59:49 +0000 (09:59 -0600)]
arm: mach-k3: Remove incorrect checks for SPL build
The kconfig option SPL means this build supports SPL but not that
this build is SPL, nor that this build is the SPL running on R5.
For options that are for R5 SPL use CPU_V7R.
Andrew Davis [Wed, 1 Nov 2023 20:35:30 +0000 (15:35 -0500)]
arm: mach-k3: j721s2: Move board selection to mach-k3
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Andrew Davis [Wed, 1 Nov 2023 20:35:29 +0000 (15:35 -0500)]
arm: mach-k3: am62ax: Move board selection to mach-k3
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Andrew Davis [Wed, 1 Nov 2023 20:35:28 +0000 (15:35 -0500)]
arm: mach-k3: am62x: Move board selection to mach-k3
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Andrew Davis [Wed, 1 Nov 2023 20:35:27 +0000 (15:35 -0500)]
arm: mach-k3: am64x: Move board selection to mach-k3
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Andrew Davis [Wed, 1 Nov 2023 20:35:26 +0000 (15:35 -0500)]
arm: mach-k3: am65x: Move board selection to mach-k3
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Andrew Davis [Wed, 1 Nov 2023 20:35:25 +0000 (15:35 -0500)]
arm: mach-k3: j721e: Move board selection to mach-k3
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor, being selectable at the same time.
For instance you can select both TARGET_AM654_A53_EVM and
TARGET_IOT2050_A53 in the same build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Andrew Davis [Wed, 1 Nov 2023 20:35:24 +0000 (15:35 -0500)]
board: ti: Add dependency from TARGET selection to SOC
Currently the K3 selection for TARGET boards does not depend on the SoC
for which it is based. This leds to the odd ability to select for instance
both SOC_K3_AM625 and TARGET_J721E_A72_EVM.
To fix this the target choice should depend on the matching SOC config.
Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Miquel Raynal [Tue, 10 Oct 2023 09:03:04 +0000 (11:03 +0200)]
usb: udc: Try to clarify an error message
At some point when trying to use USB gadgets, two situations may arise
and lead to a failure. Either the UDC (USB Device Controller) is not
available at all (not described or not probed) or the UDC is already in
use. For instance, as the USB Ethernet gadget remains bound to the UDC,
the use of any other USB gadget (fastboot, dfu, etc) *after* will always
fail with the "couldn't find an available UDC" error.
Let's give a more helpful message by making a difference between the two
cases. Let's also hint people who would get this error and grep it into
the sources a better explanation of what's wrong with their workflow.
Miquel Raynal [Tue, 10 Oct 2023 09:03:03 +0000 (11:03 +0200)]
cmd: bind: Try to improve the (un)bind help
While it may sound totally obvious for the regular U-Boot developer to
get the parameters of the bind/unbind commands from the output of 'dm
tree', it did not felt straightforward to me until I was explicitly
told to look there. And even when I knew the command, I did not make a
direct link between the arguments of this command and the columns
returned by 'dm tree'.
Several of us lost a lot of time because of that, I would like to kindly
help other users by slightly improving this textual line. Unfortunately,
because of how this string is used (like within the 'help' command) I
cannot detail much more, but at least the pointer is there.
While we add this message, we can also imply CMD_DM when we enable
CMD_BIND so the debug message does not lead to an unknown command. This
way the 'dm' command will likely be there unless explicitly disabled.
Miquel Raynal [Tue, 10 Oct 2023 09:03:02 +0000 (11:03 +0200)]
cmd: Change the dependencies between CMD_BIND and USB_GADGET
Today CMD_BIND defaults to 'y' when USB_ETHER is enabled. In practice,
CMD_BIND should default to 'y' when any USB gadget is enabled not only
USB_ETHER. Let's invert the logic of the dependency and use the weak
'imply' keyword to enforce this.
Marek Vasut [Tue, 7 Nov 2023 00:09:59 +0000 (01:09 +0100)]
usb: gadget: f_mass_storage: Stop ums on START-STOP UNIT SCSI command
Exit the UMS handler loop in case START-STOP UNIT SCSI command is
received. This is sent e.g. by the util-linux eject(1) command and
indicates to the device that it is supposed to spin down the media
and enter low power state.
This effectively adds support for exitting the 'ums' command from
host using 'eject /dev/sdN' that is on par with 'dfu-util -e' .
Jaehoon Chung [Mon, 20 Jun 2022 11:13:54 +0000 (20:13 +0900)]
dfu: add CONFIG_DFU_NAME_MAX_SIZE configuration
Add CONFIG_DFU_NAME_MAX_SIZE to change the proper size.
If name is longer than default size, it can do wrong behavior during updating
image. So it need to change the proper maximum size.
This patch is proviced the solution to change value with configuration.
Simon Holesch [Mon, 20 Nov 2023 00:08:34 +0000 (01:08 +0100)]
usb: ci: Fix gadget reinit
The ChipIdea device controller wasn't properly cleaned up when disabled.
So enabling it again left it in a broken state. The problem occurred for
example when the host unbinds the driver and binds it again.
During the first setup, when the out request is queued, the endpoint is
primed (`epprime`). If the endpoint is then disabled, it stayed primed
with the initial buffer. So after the endpoint is re-enabled, the device
controller and device driver were out of sync: the new out request was
in the driver queue head, yet not submitted, but the "complete" function
was still called, since the endpoint was primed with the old buffer.
With the fastboot function this error led to the (rather confusing)
error message "buffer overflow".
Fixed by clearing the primed buffers with the `epflush` (`ENDPTFLUSH`)
register.
Signed-off-by: Simon Holesch <simon@holesch.de> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Link: https://lore.kernel.org/r/20231120002024.32865-1-simon@holesch.de Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
efi_loader: Increase default variable store size to 128K
In commit 9fd3f881c6ed ("efi_loader: Increase default variable store size to 64KiB")
Alper has a detailed explanation of why the size needs to be bumped to at
least 64K. However enabling Secure boot, writing db, KEK, PK etc keys
will further increase the size so bump it to 128K.
It's worth noting that when U-Boot stores the EFI variables in an RPMB the
available storage is defined statically in StandAloneMM at build time.
The U-Boot code is detecting the available true size on the fly during
writes. When StandAloneMM is present this size defines the reserved
memory U-Boot can use to copy any runtime variables, before booting an
OS.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Jonathan Corbet [Wed, 4 Jan 2023 17:47:39 +0000 (10:47 -0700)]
docs: Fix the docs build with Sphinx 6.0
Sphinx 6.0 removed the execfile_() function, which we use as part of the
configuration process. They *did* warn us... Just open-code the
functionality as is done in Sphinx itself.
Tested (using SPHINX_CONF, since this code is only executed with an
alternative config file) on various Sphinx versions from 2.5 through 6.0.
Reported-by: Martin Liลกka <mliska@suse.cz> Cc: stable@vger.kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Rebased for U-Boot Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
When running 'mkimage -l' is called for a valid StarFive file an error
message "Error: invalid marker bytes" is written by the Renesas SPKG
driver.
mkimage -l may be invoked without specifying an image type. In this case
mkimage iterates over all image type drivers to find the one that matches.
None of the non-matching drivers should write an error message.
Fix the Renesas SPKG driver.
Fixes: afdfcb11f97c ("tools: spkgimage: add Renesas SPKG format") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
scsi: set dma direction to NONE for TEST UNIT READY
SCSI device scan code was executing TEST UNIT READY command without
explicitly setting dma direction in struct scsi_cmd to NONE, so command
was passed to driver with dma direction set to DMA_FROM_DEVICE,
inherited from older usage.
With WDC SDINDDH6-64G ufs device, that caused TEST UNIT READY to
return error.
Fix that, by explicitly setting dma direction to NONE for
TEST UNIT READY, and restoring it back DMA_FROM_DEVICE for the
following READ CAPACITY.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Reviewed-by: Marek Vasut <marex@denx.de>
Tom Rini [Sat, 18 Nov 2023 20:52:53 +0000 (15:52 -0500)]
Merge tag 'efi-next-18112023' of https://source.denx.de/u-boot/custodians/u-boot-tpm into next
EFI HTTP Boot is currently supported by using a combination of
wget, blkmap and bootefi commands. The user has to download the
image, mount it using blkmap and then execute the efi installer
using bootefi.
This series simplifies the user experience. Instead of doing all the
steps manually, users can now enable a new Kconfig (EFI_HTTP_BOOT)
which will select wget, blkmap and dns options. They can then use
efidebug command to add a boot option for the EFI Bootmanager using
=> efidebug boot add -u 3 netinst http://<path>
=> efidebug boot order 3
=> bootefi bootmgr
The boot manager will automatically download and mount the image.
Once it's mounted it will locate and launch the installer.
It's worth noting that this rarely fails, but the reason is irrelevant
to the current patchset. More information can be found here
https://lore.kernel.org/u-boot/CAOMZO5CoduEgwgdQiybmoKh6qQZOezUtRRQO4ecaGdZBBz5dDw@mail.gmail.c
om/
The tl;dr is that wget sometimes fails to download the file correctly
or set the size env variables. We expect all these to be solved once
LWIP is stable and pulled
Masahisa Kojima [Fri, 10 Nov 2023 04:25:41 +0000 (13:25 +0900)]
cmd: efidebug: add uri device path
This adds the URI device path option for 'boot add' subcommand.
User can add the URI load option for downloading ISO image file
or EFI application through network. Currently HTTP is only supported.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Masahisa Kojima [Fri, 10 Nov 2023 04:25:40 +0000 (13:25 +0900)]
efi_loader: support boot from URI device path
This supports to boot from the URI device path.
When user selects the URI device path, bootmgr downloads
the file using wget into the address specified by loadaddr
env variable.
If the file is .iso or .img file, mount the image with blkmap
then try to boot with the default file(e.g. EFI/BOOT/BOOTAA64.EFI).
Since boot option indicating the default file is automatically
created when new disk is detected, system can boot by selecting
the automatically created blkmap boot option.
If the file is PE-COFF file, load and start the downloaded file.
The buffer used to download the ISO image file must be
reserved to avoid the unintended access to the image and
expose the ramdisk to the OS.
For PE-COFF file case, this memory reservation is done
in LoadImage Boot Service.
[Ilias fix a few memory leaks by replacing returns with gotos]
Lore: https://lore.kernel.org/u-boot/20231110042542.3797301-1-masahisa.kojima@linaro.org/T/#mbac31da301ff465b60894b38f3a587b2868cf817 Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Masahisa Kojima [Fri, 10 Nov 2023 04:25:39 +0000 (13:25 +0900)]
efi_loader: add return to efibootmgr event group
When the image loaded by efibootmgr returns, efibootmgr
needs to clean the resources. Adding the event of returning
to efibootmgr is useful to simplify the implementation.
Masahisa Kojima [Fri, 10 Nov 2023 04:25:38 +0000 (13:25 +0900)]
efi_loader: add missing const classifier for event service
const classifier is missing in EventGroup parameter of
CreateEventEx(). Fix it to remove the compiler warning.
NotifyContext parameter of CreateEventEx() is also defined
with const in UEFI specification, but NotifyContext parameter
of CreateEvent() is defined without const.
Since current implementation calls the common efi_create_event()
function from both CreateEventEx() and CreateEvent() services,
NotifyContext parameter leaves as is.
Raymond Mao [Fri, 10 Nov 2023 04:25:37 +0000 (13:25 +0900)]
efi_loader: Boot var automatic management
Changes for complying to EFI spec ยง3.5.1.1
'Removable Media Boot Behavior'.
Boot variables can be automatically generated during a removable
media is probed. At the same time, unused boot variables will be
detected and removed.
Please note that currently the function 'efi_disk_remove' has no
ability to distinguish below two scenarios
a) Unplugging of a removable media under U-Boot
b) U-Boot exiting and booting an OS
Thus currently the boot variables management is not added into
'efi_disk_remove' to avoid boot options being added/erased
repeatedly under scenario b) during power cycles
See TODO comments under function 'efi_disk_remove' for more details
The original efi_secboot tests expect that BootOrder EFI variable
is not defined. With this commit, the BootOrder EFI variable is
automatically added when the disk is detected. The original
efi_secboot tests end up with unexpected failure.
The efi_secboot tests need to be modified to explicitly set
the BootOrder EFI variable.
squashfs and erofs ls tests are also affected by this modification,
need to clear the previous state before squashfs ls test starts.
Co-developed-by: Masahisa Kojima <masahisa.kojima@linaro.org> Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Signed-off-by: Raymond Mao <raymond.mao@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Joao Marcos Costa <jmcosta944@gmail.com> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Masahisa Kojima [Fri, 10 Nov 2023 04:25:35 +0000 (13:25 +0900)]
net: wget: add wget with dns utility function
Current wget takes the target uri in this format:
"<http server ip>:<file path>" e.g.) 192.168.1.1:/bar
The http server ip address must be resolved before
calling wget.
This commit adds the utility function runs wget with dhs.
User can call wget with the uri like "http://foo/bar".
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Ramon Fried <rfried.dev@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Simon Glass [Thu, 16 Nov 2023 01:35:23 +0000 (18:35 -0700)]
bootstd: Avoid freeing a non-allocated buffer
EFI applications can be very large and thus used to cause boot failures
when malloc() space was exhausted.
A recent changed fixed this by using the kernel_addr_r environment var
as the address of the buffer. However, it still frees the buffer when
the bootflow is discarded.
Fix this by introducing a flag to indicate whether the buffer was
allocated, or not.
Note that kernel_addr_r is not the last word here. It might be better
to use lmb to place images. But there is a lot of refactoring to do
before we can remove the environment variables. The distro scripts rely
on them so it is safe for bootstd to do so too.
Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file Signed-off-by: Simon Glass <sjg@chromium.org>
Reported by: Simon Glass <sjg@chromium.org>
Reported by: Shantur Rathore <i@shantur.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Shantur Rathore <i@shantur.com>
Chris Packham [Fri, 27 Oct 2023 00:23:54 +0000 (13:23 +1300)]
Revert "arm64: Use FEAT_HAFDBS to track dirty pages when available"
This reverts commit 6cdf6b7a340db4ddd008516181de7e08e3f8c213. 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>
Chris Packham [Fri, 27 Oct 2023 00:23:53 +0000 (13:23 +1300)]
Revert "arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present"
This reverts commit 836b8d4b205d2175b57cb9ef271e638b0c116e89. 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>
Chris Packham [Fri, 27 Oct 2023 00:23:52 +0000 (13:23 +1300)]
Revert "armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present"
This reverts commit c1da6fdb5c239b432440721772d993e63cfdeb20. 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>
Marcel Ziswiler [Thu, 26 Oct 2023 07:32:20 +0000 (09:32 +0200)]
imx: spl_imx_romapi: fix emmc fast boot mode case
This fixes a regression in the eMMC fast boot mode case where the buffer
was missing 464 bytes.
The code figures out how many bytes must at least be fetched to honor
the current read, rounds that up to the ss->pagesize [which is a no-op
in the USB download case because that has ->pagesize==1], fetches that
many bytes, but then recorded the original upper bound as the new end of
the valid data. However, this did not take into account the rounding up
to the ss->pagesize. Fix this by recording the actual bytes downloaded.
Fixes: 4b4472438f5a ("imx: spl_imx_romapi: avoid tricky use of spl_load_simple_fit() to get full FIT size") Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Acked-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Fabio Estevam <festevam@gmail.com>
John Keeping [Tue, 14 Nov 2023 11:30:17 +0000 (11:30 +0000)]
spl: fix TPL_SYS_MALLOC_F description
This config option enables the malloc() pool in TPL not the SPL. Fix
the description to accurately reflect this.
Fixes: fd8497dae54 (spl: Create proper symbols for enabling the malloc() pool) Signed-off-by: John Keeping <jkeeping@inmusicbrands.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Andre Przywara [Tue, 7 Nov 2023 16:09:00 +0000 (16:09 +0000)]
virtio: rng: gracefully handle 0 byte returns
According to the virtio v1.x "entropy device" specification, a virtio-rng
device is supposed to always return at least one byte of entropy.
However the virtio v0.9 spec does not mention such a requirement.
The Arm Fixed Virtual Platform (FVP) implementation of virtio-rng always
returns 8 bytes less of entropy than requested. If 8 bytes or less are
requested, it will return 0 bytes.
This behaviour makes U-Boot's virtio_rng_read() implementation go into an
endless loop, hanging the system.
Work around this problem by always requesting 8 bytes more than needed,
but only if a previous call to virtqueue_get_buf() returned 0 bytes.
This should never trigger on a v1.x spec compliant implementation, but
fixes the hang on the Arm FVP.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reported-by: Peter Hoyes <peter.hoyes@arm.com>
Tom Rini [Fri, 17 Nov 2023 13:38:05 +0000 (08:38 -0500)]
Merge branch '2023-11-16-assorted-updates' into next
- squashfs improvements, remove common.h in some places, assorted code
fixes, fix a few CONFIG symbol names in Kconfig files, bring in
linux's <linux/time.h> conversion functions, poplar updates, bcb
improvements.
Sam Edwards [Sat, 11 Nov 2023 15:19:04 +0000 (08:19 -0700)]
fs: btrfs: fix reading when length specified
The btrfs read function limits the read length to ensure that it
and the read offset do not together exceed the size of the file.
However, this size was only being queried if the read length was
passed a value of zero (meaning "whole file"), and the size is
defaulted to 0 otherwise. This means the clamp will just zero out
the length if one is specified, preventing reading of the file.
Fix this by checking the file size unconditionally, and unifying
the default length and clamping logic as a single range check instead.
This bug was discovered when trying to boot Linux with initrd= via
'bootefi' from a btrfs partition. The EFI stub entered an infinite
loop of zero-length reads while trying to read the initrd, and the
boot process stalled indefinitely.
Signed-off-by: Sam Edwards <CFSworks@gmail.com> Reviewed-by: Qu Wenruo <wqu@suse.com>
Dmitrii Merkurev [Fri, 10 Nov 2023 05:59:55 +0000 (05:59 +0000)]
cmd: bcb: extend BCB C API to allow read/write the fields
Currently BCB C API only allows to modify 'command' BCB field.
Extend it so that we can also read and modify all the available
BCB fields (command, status, recovery, stage).
Co-developed-by: Cody Schuffelen <schuffelen@google.com> Signed-off-by: Cody Schuffelen <schuffelen@google.com> Signed-off-by: Dmitrii Merkurev <dimorinny@google.com> Cc: Eugeniu Rosca <erosca@de.adit-jv.com> Cc: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org> Cc: Simon Glass <sjg@chromium.org> Cc: Mattijs Korpershoek <mkorpershoek@baylibre.com> Cc: Sean Anderson <sean.anderson@seco.com> Cc: Cody Schuffelen <schuffelen@google.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # on vim3 Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Igor Opaniuk [Thu, 9 Nov 2023 22:34:34 +0000 (23:34 +0100)]
poplar: use random mac address
Set CONFIG_NET_RANDOM_ETHADDR=y, which sets random eth address in
case there is no configuration provided neither in CONFIG_ETHADDR
nor in "ethaddr" env variable.
This fixes the problem:
poplar# dhcp
Error: ethernet@9841000 address not set.
Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Igor Prusov [Thu, 9 Nov 2023 17:10:02 +0000 (20:10 +0300)]
linux/time.h: Add Linux time conversion defines
Currently there are no defines for time conversion in time.h, which
leads to drivers declaring those locally or not using defines at all, so
add them from Linux.
Signed-off-by: Igor Prusov <ivprusov@salutedevices.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Paul Barker [Wed, 8 Nov 2023 08:51:10 +0000 (08:51 +0000)]
sysreset: Fix unsupported request return values
The description of the sysreset request method in <sysreset.h> says that
the return value should be -EPROTONOSUPPORT if the requested reset type
is not supported by this device.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Simon Glass <sjg@chromium.org>
projects / thirdparty / u-boot.git / log
