| Age | Commit message (Collapse) | Author |
|---|
|
Prasanth Babu Mantena <p-mantena@ti.com> says:
The channel allocation and deallocation for dma copy was happening on every
dma transfer. This is a overhead for transactions like NAND, which does
page reads recursively for complete data.
So, moving the dma allocation to probe and implement corresponding
remove function and cleanup dma device while exiting from spl.
Enable SPL_DM_DEVICE_REMOVE, for device removal capability in SPL.
Link: https://lore.kernel.org/r/20241009145703.1970034-1-p-mantena@ti.com
|
|
Currently, the allocation of DMA channel[0] for memcpy is happening
in udma_transfer() for every transfer, which leads to a huge overhead
for each transfer, especially in case of nand page reads. So, move this
allocation to udma_probe(), as a result, the allocation is done once
during probe.
Introduce udma_remove() for the cleanup of allocated channel during
probe.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
|
|
The udma_probe() function was placed above many important APIs
related to bcdma, pktdma, which restricts these APIs to be accessed
during probe. So, move udma_probe() below all of them.
Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
|
|
https://source.denx.de/u-boot/custodians/u-boot-dfu
u-boot-dfu-20241017
CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/22742
Usb Gadget:
- Fix cdns3 endpoint configuration by setting maxpacket
- Fix dwc3 cache handling when using DMA
Fastboot:
- Make AVB_VERIFY depends on FASTBOOT
|
|
|
|
Now that the TCPM framework exists we can introduce fusb302
driver using it. This chip is a very common USB-C controller
chip with PD support, which can be found in the Radxa Rock 5B
among many other boards. Apart from Power Delivery, it also
handles detection of the cable orientation. That can be used
to control a mux for connecting the right USB3 lane pair to
the USB3 controller.
The driver is originally from the Linux kernel, but has been
adapted to the requirements of U-Boot and its TCPM framework.
Co-developed-by: Wang Jie <dave.wang@rock-chips.com>
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
Tested-by: Soeren Moch <smoch@web.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
|
This adds TCPM framework in preparation for fusb302 support, which can
handle USB power delivery messages. This is needed to solve issues with
devices, that are running from a USB-C port supporting USB-PD, but not
having a battery.
Such a device currently boots to the kernel without interacting with
the power-supply at all. If there are no USB-PD message replies within
5 seconds, the power-supply assumes the peripheral is not capable of
USB-PD. It usually takes more than 5 seconds for the system to reach
the kernel and probe the I2C based fusb302 chip driver. Thus the
system always runs into this state. The power-supply's solution to
fix this error state is a hard reset, which involves removing the
power from VBUS. Boards without a battery (or huge capacitors) will
reset at this point resulting in a boot loop.
This imports the TCPM framework from the kernel. The porting has
originally been done by Rockchip using hardware timers and the Linux
kernel's TCPM code from some years ago.
I had a look at upgrading to the latest TCPM kernel code, but that
beast became a lot more complex due to adding more USB-C features.
I believe these features are not needed in U-Boot and with multiple
kthreads and hrtimers being involved it is non-trivial to port them.
Instead I worked on stripping down features from the Rockchip port
to an even more basic level. Also the TCPM code has been reworked
to avoid complete use of any timers (Rockchip used SoC specific
hardware timers + IRQ to implement delayed work mechanism). Instead
the delayed state changes are handled directly from the poll loop.
Note, that (in contrast to the original Rockchip port) the state
machine has the same hard reset quirk, that the kernel has - i.e.
it avoids disabling the CC pin resistors for devices that are not
self-powered. Without that quirk, the Radxa Rock 5B will not just
end up doing a machine reset when a hard reset is triggered, but will
not even recover, because the CPU will loose power and the FUSB302
will keep this state because of leak voltage arriving through the RX
serial pin (assuming a serial adapter is connected).
This also includes a 'tcpm' command, which can be used to get
information about the current state and the negotiated voltage
and current.
Co-developed-by: Wang Jie <dave.wang@rock-chips.com>
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
Tested-by: Soeren Moch <smoch@web.de>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
|
|
Rasmus Villemoes <ravi@prevas.dk> says:
Some small improvements to the serial rx buffer feature.
CI seems happy: https://github.com/u-boot/u-boot/pull/674
Link: https://lore.kernel.org/r/20241003141029.920035-1-ravi@prevas.dk
|
|
The initialization of upriv->buf doesn't check for a NULL return. But
there's actually no point in doing a separate, unconditional malloc()
in post_probe; we can just make serial_dev_priv contain the rx buffer
itself, and let the (larger) allocation be handled by the driver core
when it allocates the ->per_device_auto. The total run-time memory
used is mostly the same, we reduce the code size a little, and as a
bonus, struct serial_dev_priv does not contain the unused members when
!SERIAL_RX_BUFFER.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The help text says it must be a power of 2, and the implementation
does rely on that. Enforce it.
A violation gives a wall of text, but the last few lines should be
reasonably obvious:
drivers/serial/serial-uclass.c:334:9: note: in expansion of macro ‘BUILD_BUG_ON_NOT_POWER_OF_2’
334 | BUILD_BUG_ON_NOT_POWER_OF_2(CONFIG_SERIAL_RX_BUFFER_SIZE);
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Before the previous patch, pasting a string of length x >
CONFIG_SERIAL_RX_BUFFER_SIZE results in getting the
last (x%CONFIG_SERIAL_RX_BUFFER_SIZE) characters from that string.
With the previous patch, one instead gets the last
CONFIG_SERIAL_RX_BUFFER_SIZE characters repeatedly until the ->rd_ptr
catches up.
Both behaviours are counter-intuitive, and happen because the code
that checks for a character available from the hardware does not
account for whether there is actually room in the software buffer to
receive it. Fix that by adding such accounting. This also brings the
software buffering more in line with how most hardware FIFOs
behave (first received characters are kept, overflowing characters are
dropped).
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The current implementation of the circular rx buffer falls into a
common trap with circular buffers: It keeps the head/tail indices
reduced modulo the buffer size. The problem with that is that it makes
it impossible to distinguish "buffer full" from "buffer empty",
because in both situations one has head==tail.
This can easily be demonstrated: Build sandbox with RX_BUFFER enabled,
set the RX_BUFFER_SIZE to 32, and try pasting the string
01234567890123456789012345678901
Nothing seems to happen, but in reality, all characters have been read
and put into the buffer, but then tstc ends up believing nothing is in
the buffer anyway because upriv->rd_ptr == upriv->wr_ptr.
A better approach is to let the indices be free-running, and only
reduce them modulo the buffer size when accessing the array. Then
"empty" is head-tail==0 and "full" is head-tail==size. This does rely
on the buffer size being a power-of-two and the free-running
indices simply wrapping around to 0 when incremented beyond the
maximal positive value.
Incidentally, that change from signed to unsigned int also improves
code generation quite a bit: In C, (signed int)%(signed int) is
defined to have the sign of the dividend (so (-35) % 32 is -3, not
29), and hence despite the modulus being a power-of-two, x % 32 does
not actually compile to the same as a simple x & 31 - on x86 with -Os,
it seems that gcc ends up emitting an idiv instruction, which is quite
expensive.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Add what it takes to enable NETDEVICES with NET_LWIP and enable DHCP as
well as the dhcp command. CMD_TFTPBOOT is selected by BOOTMETH_EFI due
to this code having an implicit dependency on do_tftpb().
Note that PXE is likely non-fonctional with NET_LWIP (or at least not
100% functional) because DHCP option 209 is not supported by the lwIP
library. Therefore, BOOTP_PXE_DHCP_OPTION cannot be enabled.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by
adding a new net/lwip/ directory and the NET_LWIP symbol. Network
support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent
commits will introduce the lwIP code, re-work the NETDEVICE integration
and port some of the NET commands and features to lwIP.
SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols
that are part of NET (such as arp_init(), arp_timeout_check(),
arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be
added later.
Similarly, DFU_TFTP and FASTBOOT are not compatible with NET_LWIP
because of dependencies on net_loop(), tftp_timeout_ms,
tftp_timeout_count_max and other NET things. Let's add a dependency on
!NET_LWIP for now.
SANDBOX can select NET_LWIP but doing so will currently disable the eth
dm tests as well as the wget tests which have strong dependencies on the
NET code.
Other adjustments to Kconfig files are made to fix "unmet direct
dependencies detected" for USB_FUNCTION_SDP and CMD_FASTBOOT when
the default networking stack is set to NET_LWIP ("default NET_LWIP"
instead of "default NET" in Kconfig).
The networking stack is now a choice between NO_NET,
NET and NET_LWIP. Therefore '# CONFIG_NET is not set' should be
'CONFIG_NO_NET=y'. Adjust the defconfigs accordingly.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Introduce ETH_SANDBOX_LWIP which enables a mock driver similar to
ETH_SANDOX but without the dependencies on the legacy network stack
(NET) so that it may be enabled when the lwIP stack (NET_LWIP) is
introduced. The driver does nothing at this stage but its presence
will allow dm_test_iommu_noiommu [1] to pass.
[1] ./u-boot -T -c "ut dm dm_test_iommu_noiommu"
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
|
|
The commit 0252924ac6d4 ("mmc: dw_mmc: Extract FIFO data transfer into a
separate routine") unintentionally changed behavior of the FIFO data
transfer routine.
When data is read and size reaches 0 the original loop would wait on
DWMCI_INTMSK_DTO or timeout. The remaining size to read and buf position
is no longer tracked across dwmci_data_transfer_fifo() calls and because
of this an extra call to fifo() and dwmci_fifo_ready() may now trigger a
FIFO underflow timeout error and slows down FIFO reading.
Buswidth = 4, clock: 50000000
Sending CMD16
Sending CMD17
dwmci_fifo_ready: FIFO underflow timeout
Sending CMD16
Sending CMD18
dwmci_fifo_ready: FIFO underflow timeout
Sending CMD12
## Checking hash(es) for config config-1 ... OK
This reverts commit 0252924ac6d4af69061bb9589d16b30c5bdb7178 to restore
the old working behavior.
Fixes: 0252924ac6d4 ("mmc: dw_mmc: Extract FIFO data transfer into a separate routine")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # RK3588 Tiger
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The Infineon SEMPER NOR flash family uses 2-bit ECC by default with each
ECC block being 16 bytes. Under this scheme multi-pass programming to an
ECC block is not allowed. Set the writesize to make sure multi-pass
programming is not attempted on the flash.
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
|
|
This patch follows the upstream linux commit:
5273cc6df984("mtd: spi-nor: core: Call spi_nor_post_sfdp_fixups() only
when SFDP is defined")
spi_nor_post_sfdp_fixups() was called regardless of if
spi_nor_parse_sfdp() had been called or not. late_init() should be
instead used to initialize the parameters that are not defined in SFDP.
Ideally spi_nor_post_sfdp_fixups() is called only after successful parse
of SFDP. However, in case SFDP support is disabled by .config, that can
break current functionality. Therefore, we would call it after
spi_nor_parse_sfdp() regardless of its return value.
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
|
|
default_init() is wrong, it contributes to the maze of initializing
flash parameters. We'd like to get rid of it because the flash
parameters that it initializes are not really used at SFDP parsing time,
thus they can be initialized later.
Ideally we want SFDP to initialize all the flash parameters. If (when)
SFDP tables are wrong, we fix them with the post_sfdp/bfpt hooks, to
emphasize that SFDP is indeed wrong. When there are parameters that are
not covered by SFDP, we initialize them in late_init() - these
parameters have nothing to do with SFDP and they are not needed earlier.
With this we'll have a clearer view of who initializes what.
There are six default_init() hooks implemented just for initializing
octal_dtr_enable() and/or setup() hooks that called later on.
Just moving those to late_init() does not change functionality.
Suggested-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
|
|
The macronix_octal_fixups should be set only when mfr and flags match.
Fixes: df3d5f9e41 ("mtd: spi-nor: add support for Macronix Octal flash")
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Cc: JaimeLiao <jaimeliao.tw@gmail.com>
|
|
Some flashes like the Infineon SEMPER NOR flash family use ECC. Under
this ECC scheme, multi-pass writes to an ECC block is not allowed.
In other words, once data is programmed to an ECC block, it can't be
programmed again without erasing it first.
Upper layers like file systems need to be given this information so they
do not cause error conditions on the flash by attempting multi-pass
programming. This can be done by setting 'writesize' in 'struct
mtd_info'.
Set the default to 1 but allow flashes to modify it in fixup hooks. If
more flashes show up with this constraint in the future it might be
worth it to add it to 'struct flash_info', but for now increasing its
size is not worth it.
This patch replicates the following upstream linux commit:
afd473e85827 ("mtd: spi-nor: core: Allow flashes to specify MTD writesize")
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
|
|
For NOR flashes EC and VID are zeroed out before an erase is issued to
make sure UBI does not mistakenly treat the PEB as used and associate it
with an LEB.
But on some flashes, like the Infineon Semper NOR flash family,
multi-pass page programming is not allowed on the default ECC scheme.
This means zeroing out these magic numbers will result in the flash
throwing a page programming error.
Do not zero out EC and VID for such flashes. A writesize > 1 is an
indication of an ECC-ed flash.
This patch replicates the following upstream linux commit:
f669e74be820 ("ubi: Do not zero out EC and VID on ECC-ed NOR flashes")
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Acked-by: Pratyush Yadav <pratyush@kernel.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
|
|
On Qualcomm systems, the setup buffer and even buffers are in
a bad state at interrupt handling, so invalidate the dcache lines
for the setup_buf and event buffer to make sure we read correct
data written by the hardware.
This fixes the following error:
dwc3-generic-peripheral usb@a600000: UNKNOWN IRQ type -1
dwc3-generic-peripheral usb@a600000: UNKNOWN IRQ type 4673109
and invalid situation in dwc3_gadget_giveback() because setup_buf content
is read at 0s and leads to fatal crash fixed by [1].
[1] https://lore.kernel.org/all/20240528-topic-sm8x50-dwc3-gadget-crash-fix-v1-1-58434ab4b3d3@linaro.org/
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20241011-u-boot-dwc3-gadget-dcache-fixup-v4-3-5f3498d8035b@linaro.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
The current flush operation will omit doing a flush/invalidate on
the first and last bytes if the base address and size are not aligned
with CACHELINE_SIZE.
This causes operation failures Qualcomm platforms.
Take in account the alignment and size of the buffer and also
flush the previous and last cacheline.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20241011-u-boot-dwc3-gadget-dcache-fixup-v4-2-5f3498d8035b@linaro.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Since setup_buf is also consumed by hardware DMA, aligns it's
allocation like other hardware buffers by introduce setup_buf_addr
populated by dma_alloc_coherent(), and use it to pass the physical
address of the buffer to the hardware.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20241011-u-boot-dwc3-gadget-dcache-fixup-v4-1-5f3498d8035b@linaro.org
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
|
|
Raymond Mao <raymond.mao@linaro.org> says:
Integrate MbedTLS v3.6 LTS (currently v3.6.0) with U-Boot.
Motivations:
------------
1. MbedTLS is well maintained with LTS versions.
2. LWIP is integrated with MbedTLS and easily to enable HTTPS.
3. MbedTLS recently switched license back to GPLv2.
Prerequisite:
-------------
This patch series requires mbedtls git repo to be added as a
subtree to the main U-Boot repo via:
$ git subtree add --prefix lib/mbedtls/external/mbedtls \
https://github.com/Mbed-TLS/mbedtls.git \
v3.6.0 --squash
Moreover, due to the Windows-style files from mbedtls git repo,
we need to convert the CRLF endings to LF and do a commit manually:
$ git add --renormalize .
$ git commit
New Kconfig options:
--------------------
`MBEDTLS_LIB` is for MbedTLS general switch.
`MBEDTLS_LIB_CRYPTO` is for replacing original digest and crypto libs with
MbedTLS.
`MBEDTLS_LIB_CRYPTO_ALT` is for using original U-Boot crypto libs as
MbedTLS crypto alternatives.
`MBEDTLS_LIB_X509` is for replacing original X509, PKCS7, MSCode, ASN1,
and Pubkey parser with MbedTLS.
By default `MBEDTLS_LIB_CRYPTO_ALT` and `MBEDTLS_LIB_X509` are selected
when `MBEDTLS_LIB` is enabled.
`LEGACY_CRYPTO` is introduced as a main switch for legacy crypto library.
`LEGACY_CRYPTO_BASIC` is for the basic crypto functionalities and
`LEGACY_CRYPTO_CERT` is for the certificate related functionalities.
For each of the algorithm, a pair of `<alg>_LEGACY` and `<alg>_MBEDTLS`
Kconfig options are introduced. Meanwhile, `SPL_` Kconfig options are
introduced.
In this patch set, MBEDTLS_LIB, MBEDTLS_LIB_CRYPTO and MBEDTLS_LIB_X509
are by default enabled in qemu_arm64_defconfig and sandbox_defconfig
for testing purpose.
Patches for external MbedTLS project:
-------------------------------------
Since U-Boot uses Microsoft Authentication Code to verify PE/COFFs
executables which is not supported by MbedTLS at the moment,
addtional patches for MbedTLS are created to adapt with the EFI loader:
1. Decoding of Microsoft Authentication Code.
2. Decoding of PKCS#9 Authenticate Attributes.
3. Extending MbedTLS PKCS#7 lib to support multiple signer's certificates.
4. MbedTLS native test suites for PKCS#7 signer's info.
All above 4 patches (tagged with `mbedtls/external`) are submitted to
MbedTLS project and being reviewed, eventually they should be part of
MbedTLS LTS release.
But before that, please merge them into U-Boot, otherwise the building
will be broken when MBEDTLS_LIB_X509 is enabled.
See below PR link for the reference:
https://github.com/Mbed-TLS/mbedtls/pull/9001
Miscellaneous:
--------------
Optimized MbedTLS library size by tailoring the config file
and disabling all unnecessary features for EFI loader.
From v2, original libs (rsa, asn1_decoder, rsa_helper, md5, sha1, sha256,
sha512) are completely replaced when MbedTLS is enabled.
From v3, the size-growth is slightly reduced by refactoring Hash functions.
From v6, smaller implementations for SHA256 and SHA512 are enabled and
target size reduce significantly.
Target(QEMU arm64) size-growth when enabling MbedTLS:
v1: 6.03%
v2: 4.66%
v3 - v5: 4.55%
v6: 2.90%
Tests done:
-----------
EFI Secure Boot test (EFI variables loading and verifying, EFI signed image
verifying and booting) via U-Boot console.
EFI Secure Boot and Capsule sandbox test passed.
Known issues:
-------------
None.
Link: https://lore.kernel.org/u-boot/20241003215112.3103601-1-raymond.mao@linaro.org/
|
|
Adapt digest header files to support both original libs and MbedTLS
by switching on/off MBEDTLS_LIB_CRYPTO.
Introduce <alg>_LEGACY kconfig for legacy hash implementations.
sha256.o should depend on SHA256 kconfig only but not SUPPORT_EMMC_RPMB,
SHA256 should be selected when SUPPORT_EMMC_RPMB is enabled instead.
`IS_ENABLED` or `CONFIG_IS_ENABLED` is not applicable here, since
including <linux/kconfig.h> causes undefined reference on schedule()
with sandbox build, as <linux/kconfig.h> includes <generated/autoconf.h>
which enables `CONFIG_HW_WATCHDOG` and `CONFIG_WATCHDOG` but no schedule()
are defined in sandbox build,
Thus we use `#if defined(CONFIG_MBEDTLS_LIB_CRYPTO)` instead.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
On some platforms with low USB throughput, tranfers
of huge files take a long time and watchdog timer can
expire resulting in hardware reset. Avoid this by
petting the watchdog as long as we have pending transfers.
Signed-off-by: Godfrey Mwangi <godmwan@microsoft.com>
Reviewed-by: Marek Vasut <marex@denx.de>
|
|
https://source.denx.de/u-boot/custodians/u-boot-ufs
- Set of fixes/updated on UFS core
- Fix dcache/flush
- Update & Sync Quirks
- Backport fixes from Linux
- Add missing memory barriers
- Remove link_startup_again logic
- Add Neil to UFS maintainers
- Add UFS DesignWare Controller for AMD vers2 platforms
- Add UFS Qualcomm controller driver
|
|
https://source.denx.de/u-boot/custodians/u-boot-amlogic
- Add Libre Computer boards into proper libre-computer board directory
- Add new Boards:
- Libre Computer aml-s905d3-cc
- Libre Computer aml-a311d-cc
- Add capsule update to libretech-ac and the new boards since they have an onboard SPI nor flash
- Fix HDMI support after sync to v6.11 and regulator enable from Marek
- Fix khadas-vim3 android config for android-mainline kernel
- Disable meson64 boot targets when configs are not eavailable
|
|
https://source.denx.de/u-boot/custodians/u-boot-nand-flash
This merge request add support for BCMBCA raw nand driver for bcm96846
board that switch using OF_UPSTREAM and allow use onfi ecc params when
they are available in the atmel nand controller
The patches pass the pipeline CI:
https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/22638
|
|
The upstream Device Tree for GXBB/GXL/G12A was updated with VPU domain
shared between the VPU and HDMI node, causing a double enable.
Simply store the enable state and avoid enabling twice, fixing
HDMI output on all platforms.
Link: https://lore.kernel.org/r/20241009-u-boot-topic-fix-hdmi-v1-2-2479cd90c4ea@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Align with g12a driver to handle the CLKID_HDMI, CLKID_HDMI_SEL
and CLKID_HDMI_DIV clocks since they were added to the upstream
GXBB/GXL Devicetree on v6.11 with [1]
[1] https://lore.kernel.org/all/20240626152733.1350376-1-jbrunet@baylibre.com/
Link: https://lore.kernel.org/r/20241009-u-boot-topic-fix-hdmi-v1-1-2479cd90c4ea@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
If the regulator is already enabled, this happens if the regulator
is set in regulator-always-on, regulator_set_enable() return -EALREADY.
Ignore the -EALREADY return since it's not an error.
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20241009-u-boot-video-fix-hdmi-supply-already-on-v2-1-4478a28d1f49@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Add Support for the Host Controller driver for UFS HC
present on Qualcomm Snapdragon SoCs.
It has been successfully tested on SDM845, SM8250,
SM8550 ant SM8650 SoCs.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Tested-by: Julius Lehmann <lehmanju@devpi.de>
Tested-by: Caleb Connolly <caleb.connolly@linaro.org> #rb3gen2
Link: https://lore.kernel.org/r/20240910-topic-ufs-qcom-controller-v1-4-54c0d2231b10@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Add UFSHCI version 4.0 found on the recent Qualcomm UFS Controllers.
Tested-by: Julius Lehmann <lehmanju@devpi.de>
Tested-by: Caleb Connolly <caleb.connolly@linaro.org> #rb3gen2
Link: https://lore.kernel.org/r/20240910-topic-ufs-qcom-controller-v1-3-54c0d2231b10@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Add a new get_max_pwr_mode callback to permit the UFS controller
driver manipulate the max_pwr_mode struct right before setting
the new pwr_mode to the UFS device.
It can be used to limit the HS Gear with errata and hardware
limitations on some UFS controllers.
Tested-by: Julius Lehmann <lehmanju@devpi.de>
Tested-by: Caleb Connolly <caleb.connolly@linaro.org> #rb3gen2
Link: https://lore.kernel.org/r/20240910-topic-ufs-qcom-controller-v1-2-54c0d2231b10@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Add device_reset op to permit resetting the UFS device if
the UFS controller drivers supports the operation.
Tested-by: Julius Lehmann <lehmanju@devpi.de>
Tested-by: Caleb Connolly <caleb.connolly@linaro.org> #rb3gen2
Link: https://lore.kernel.org/r/20240910-topic-ufs-qcom-controller-v1-1-54c0d2231b10@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Add UFS AMD platform support on top of the UFS DWC
and UFS platform driver. UFS AMD platform requires
some platform specific configurations like M-PHY/RMMI/UniPro
and vendor specific registers programming before doing the LINKSTARTUP.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20240920041651.18173-3-venkatesh.abbarapu@amd.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
This patch has the goal to add support for DesignWare UFS Controller
specific operations.
This is based on linux kernel commit:
"drivers/scsi/ufs/ufshcd-dwc.c: ufs: add support for DesignWare
Controller" (sha1: 4b9ffb5a353bdee49f1f477ffe2b95ab3f9cbc0c)
It is ported from linux kernel 6.11-rc1.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20240920041651.18173-2-venkatesh.abbarapu@amd.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
The link_startup_again logic was added in Linux to handle device
that were set in LinkDown state, which should not be the case since U-boot
doesn't set LinkDown state are init, and Linux sets the device active
in ufshcd_init() for the first link startup.
ufshcd_set_ufs_dev_active(hba) is called at ufshcd_init() right before
scheduling an ufshcd_async_scan that will call ufshcd_device_init() then ufshcd_link_startup().
The comment in probe says:
/*
* We are assuming that device wasn't put in sleep/power-down
* state exclusively during the boot stage before kernel.
* This assumption helps avoid doing link startup twice during
* ufshcd_probe_hba().
*/
we can assume the same from U-Boot.
While it worked to far, it breaks link startup for Qualcomm Controllers v5,
let's just remove the logic.
Tested-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Tested-by: Julius Lehmann <lehmanju@devpi.de>
Link: https://lore.kernel.org/r/20240930-topic-ufs-enhancements-v3-12-58234f84ab89@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Minor typo fix and rewording of printf message
inside 'ufs_start' which announces the availability
of the UFS device.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Tested-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Tested-by: Julius Lehmann <lehmanju@devpi.de>
Link: https://lore.kernel.org/r/20240930-topic-ufs-enhancements-v3-11-58234f84ab89@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Add missing wmb() and mb() barriers in the u-boot UFS core
framework driver to allow registers updates to happen before
follow-up read operations.
This makes the barrier placement similar to the Linux UFS driver,
synced from the Linux v6.9 release.
Starting from the v6.10 release, the barriers were replaced with a register
read-back in [1], this will ported to u-boot in a second time.
[1] https://lore.kernel.org/all/20240329-ufs-reset-ensure-effect-before-delay-v5-0-181252004586@redhat.com/
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Tested-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Tested-by: Julius Lehmann <lehmanju@devpi.de>
Link: https://lore.kernel.org/r/20240930-topic-ufs-enhancements-v3-10-58234f84ab89@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Sync u-boot UFS driver to add all possible UFS Quirks
as supported by Linux UFS driver as well.
Synced with include/ufs/ufshcd.h from Linux v6.11 release
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Tested-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Tested-by: Julius Lehmann <lehmanju@devpi.de>
Link: https://lore.kernel.org/r/20240930-topic-ufs-enhancements-v3-9-58234f84ab89@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Clear UECPA once in u-boot UFS driver due to LINERESET has happened
during LINK_STARTUP. This makes the u-boot ufs driver behavior related
to UECPA similar to Linux UFS driver.
Ported from Linux kernel commit:
2355b66ed20c ("scsi: ufs: Handle LINERESET indication in err handler")
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Tested-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Tested-by: Julius Lehmann <lehmanju@devpi.de>
Link: https://lore.kernel.org/r/20240930-topic-ufs-enhancements-v3-8-58234f84ab89@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Add definition of 'ufshcd_rmwl()' helper function
which would be later used by Qualcomm UFS driver
to read-modify-write registers.
Ported from Linux kernel commits:
e785060ea3a1 ("ufs: definitions for phy interface")
cff91daf52d3 ("scsi: ufs: Fix kernel-doc syntax in ufshcd.h")
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Tested-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Tested-by: Julius Lehmann <lehmanju@devpi.de>
Link: https://lore.kernel.org/r/20240930-topic-ufs-enhancements-v3-7-58234f84ab89@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Add UFSHCD_QUIRK_HIBERN_FASTAUTO quirk for host controllers which supports
auto-hibernate the capability but only FASTAUTO mode.
Ported from Linux kernel commit
2f11bbc2c7f3 ("scsi: ufs: core: Add UFSHCD_QUIRK_HIBERN_FASTAUTO")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Tested-by: Julius Lehmann <lehmanju@devpi.de>
Link: https://lore.kernel.org/r/20240930-topic-ufs-enhancements-v3-6-58234f84ab89@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS for host controllers which do not
support 64-bit addressing.
Ported from Linux kernel commit
6554400d6f66 ("scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS")
with ufs_scsi_buffer_aligned() based on U-Boot generic bounce buffer.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Tested-by: Julius Lehmann <lehmanju@devpi.de>
Link: https://lore.kernel.org/r/20240930-topic-ufs-enhancements-v3-5-58234f84ab89@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
|
Now we have proper flush and invalidate helpers, we can use them
directly to operate on the scsi_cmd data.
Likewise, we do not need to flush then invalidate, just flush _or_
invalidate depending on the data direction.
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Tested-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Tested-by: Julius Lehmann <lehmanju@devpi.de>
Link: https://lore.kernel.org/r/20240930-topic-ufs-enhancements-v3-4-58234f84ab89@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
|
