| Age | Commit message (Collapse) | Author |
|---|
|
enabled""
As reported by Jonas Karlman this series breaks booting on some AArch64
platforms with common use cases. For now the best path forward is to
revert the series.
This reverts commit 777c28460947371ada40868dc994dfe8537d7115, reversing
changes made to ab3453e7b12daef47b9e91da2a2a3d48615dc6fc.
Link: https://lore.kernel.org/u-boot/[email protected]/
Signed-off-by: Tom Rini <[email protected]>
|
|
Set the speed requested through mpc8xx_spi_set_speed() instead
of hardcoding a fixed speed.
Signed-off-by: Christophe Leroy <[email protected]>
|
|
On CPM, the RISC core is a lot more efficiant when doing transfers
in 16-bits chunks than in 8-bits chunks, but unfortunately the
words need to be byte swapped.
So, for large tranfers with an even size, allocate a temporary
buffer and byte-swap data before and after transfer.
This change allows setting higher speed for transfer. For instance
on an MPC 8xx (CPM1 comms RISC processor), the documentation tells
that transfer in byte mode at 1 kbit/s uses 0.200% of CPM load
at 25 MHz while a word transfer at the same speed uses 0.032%
of CPM load. This means the speed can be 6 times higher in
word mode for the same CPM load.
For small transfers, the load reduction is not worth the CPU load
required to allocate the temporary buffer, so do it only when data
size is over 64 bytes.
Signed-off-by: Christophe Leroy <[email protected]>
|
|
Perform multiple transfer of size MAX_BUFFER when the data to be
transferred is longer than MAX_BUFFER.
Signed-off-by: Christophe Leroy <[email protected]>
|
|
SDMA configuration register needs to be set up only once and doesn't
belong to drivers. Also, the value to be used is different on mpc885.
So do the init in cpu_init_f() with 0x40 for mpc885 and 0x1 for others.
Signed-off-by: Christophe Leroy <[email protected]>
|
|
LM74 is a SPI temperature sensor.
Implement a driver to read temperature from it.
Signed-off-by: Christophe Leroy <[email protected]>
|
|
xfer ops can be passed a NULL input or output buffer. At the
time being the driver ignores it and overwrites memory at 0.
Define a dummy buffer and use it when either input or output
buffer is NULL. Bail out when both are NULL as it shouldn't.
Also increase MAX_BUFFER len to 32k as the current is pretty
low.
Signed-off-by: Christophe Leroy <[email protected]>
|
|
Since commit 773ad4ebb1d6 ("spi, mpc8xx: Add support for chipselect via
GPIO and fixups"), DM_GPIO is required for 8xx SPI.
Add the missing dependency to avoid build failures.
Fixes: 773ad4ebb1d6 ("spi, mpc8xx: Add support for chipselect via GPIO and fixups")
Signed-off-by: Christophe Leroy <[email protected]>
|
|
The usage of the common.h include file is deprecated [1], and has already
been removed from several files.
Get rid of all inclusions in the "drivers/tee" directory, and replace it
with required include files directly where needed.
[1] doc/develop/codingstyle.rst
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Igor Opaniuk <[email protected]>
Reviewed-by: Sam Protsenko <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Fix OPTEE_TA_AVB symbol description in Kconfig:
s/"write"rb"/"write_rb"/g
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Igor Opaniuk <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Currently, fastboot protocol in U-Boot has no opportunity
to execute vendor custom code with verifed boot. This patch
introduce new fastboot subcommand fastboot oem board:<cmd>,
which allow to run custom oem_board function.
Default implementation is __weak. Vendor must redefine it in
board/ folder with his own logic.
For example, some vendors have their custom nand/emmc partition
flashing or erasing. Here some typical command for such use cases:
- flashing:
$ fastboot stage bootloader.img
$ fastboot oem board:write_bootloader
- erasing:
$ fastboot oem board:erase_env
Signed-off-by: Alexey Romanov <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
https://gitlab.denx.de/u-boot/custodians/u-boot-imx
CI:
https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20348
- Update the imx_rgpio2p to only access one address as per the
dt-schema.
- Remove unused imx9_cpu.c file.
- Only use the LPUART ipg clk for i.MX7ULP.
- Use the correct anatop base for accessing the PLL clocks on i.MX93.
|
|
|
|
The PLL clk needs use anatop base, otherwise wrong PLL address will
be used.
Fixes: 9c153e46661b ("clk: imx: add i.MX93 CCF driver")
Signed-off-by: Peng Fan <[email protected]>
|
|
This was wrongly committed, no user, remove it.
Signed-off-by: Peng Fan <[email protected]>
|
|
To i.MX7ULP compatible lpuart, there is only ipg clk, no per clk.
So add a devtype check for i.MX7ULP.
Signed-off-by: Peng Fan <[email protected]>
|
|
The i.MX8ULP/93 gpio dt-schema have been updated to only have one
address entry, update the driver to support it.
Signed-off-by: Peng Fan <[email protected]>
|
|
Remove the unused argument about cmd_error.
Fixes: a3b2786651c7 ("mmc: Drop unused mmc_send_tuning() cmd_error parameter")
Signed-off-by: Jaehoon Chung <[email protected]>
|
|
The value defaults to 0 and is ignored by dw_mmc code, so the other
users are not affected.
Setting this explicitly fixes some weird reading error found on Hi3798MV200.
Fixes: 8a5dc8140e62 ("mmc: hi6220_dw_mmc: add compatible for HC2910 support")
Signed-off-by: Yang Xiwen <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
As described in [1], some poor hardware or cards would fail to release
the bus and keep driving data lines low. Ignore it and send the next cmd
directly seems okay for most cases.
[1]: https://patchwork.kernel.org/project/linux-mmc/patch/[email protected]/
Signed-off-by: Yang Xiwen <[email protected]>
Tested-by: Jaehoon Chung <[email protected]>
|
|
CONFIG_DM_RESET enabled
This can avoid hardcoding a clock rate in driver. Also can enable the
clocks and deassert the resets if the pre-bootloader does not do this
for us.
Currently only enabled for Hi3798MV200.
Signed-off-by: Yang Xiwen <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
Place the SDR104/HS200/HS400 checks into the mmc_deinit() and always
call it. This simplifies the code and removes ifdeffery. No functional
change is expected.
Reviewed-by: Jaehoon Chung <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Dragan Simic <[email protected]>
|
|
Do not access SCC when sending commands during tuning operation as that
will disrupt the tuning operation. The tuning operation is adjusting the
SCC settings itself in execute_tuning callback.
When renesas_sdhi_execute_tuning() is called by the MMC core code, a loop
which consists of renesas_sdhi_prepare_tuning(), mmc_send_tuning() and
renesas_sdhi_compare_scc_data() iterates over each SCC tuning tap.
The renesas_sdhi_prepare_tuning() configures the SCC tuning tap number into
hardware, mmc_send_tuning() triggers transfer of tuning block which depends
on the bus mode for which the bus is currently being tuned, this information
is supplied by the MMC core code, and finally renesas_sdhi_compare_scc_data()
tests the received tuning block for validity.
Because renesas_sdhi_prepare_tuning() configures the SCC tuning tap into
the hardware to fit the tuning operation, mmc_send_tuning() which triggers
command transfer using renesas_sdhi_send_cmd() must not manipulate with
the SCC in any way. Currently renesas_sdhi_send_cmd() does unconditionally
call renesas_sdhi_check_scc_error(), which may adjust the SCC tuning tap
position by writing RENESAS_SDHI_SCC_TAPSET, which would overwrite the
required tuning configuration set by renesas_sdhi_prepare_tuning() and
disrupt the tuning operation.
Fix this by skipping the renesas_sdhi_check_scc_error() call in case the
MMC subsystem is in tuning state. This way, the SCC settings are left
unmodified by command transfer during tuning operation.
Reviewed-by: Paul Barker <[email protected]>
Tested-by: Paul Barker <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
Set generic mmc->tuning flag when performing tuning to indicate
this condition to drivers. Drivers may use this to bypass various
checks during tuning.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
This hs400_tuning is a flag, make it bool. No functional change.
This will be useful in the following patch, which adds another
more generic flag, where the compiler can better use the space
now reserved for the u8 to store more flags in it.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
The current code uses the state of tuning block received by SCC to
determine whether or not to send transmission stop command. This is
not correct. Use the state of tuning block transfer to determine
whether or not to send transmission stop command instead, because
the transmission stop command has to be sent in case the tuning
block transfer failed.
This requires two changes, separate variable to store and check the
state of tuning block received by SCC, and another separate variable
to store and check return value from transmission stop command.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Paul Barker <[email protected]>
Tested-by: Paul Barker <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
In case a CRC error occurs during DMA transfer, the transfer completion
flag is not set in TMIO_SD_DMA_INFO1 and the transfer would eventually
time out. The timeout could be very long in case the transfer consists
of a large amount of blocks, the base timeout is 10 seconds and every
block adds 100 us more.
In case a CRC error does occur, a completion flag is set in a different
register, TMIO_SD_INFO1. Use this other completion flag to detect DMA
transfer ended and stop waiting for TMIO_SD_DMA_INFO1 completion flag.
This reduces the lengthy timeout in case of an error. The unconditional
check of TMIO_SD_DMA_INFO2 register for DMA related errors must not be
skipped in any case to actually recognize the DMA error and report it.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Paul Barker <[email protected]>
Tested-by: Paul Barker <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
The cmd_error parameter is not used, remove it.
Signed-off-by: Marek Vasut <[email protected]>
|
|
The PL180/MMCI driver is implied to use CONFIG_DM and the ARM
defconfigs such as configs/vexpress_ca9x4_defconfig will get it
as well.
With a simple oneline to default to not being the v2 variant,
the original ARM MMCI variant works fine with the driver as well.
The IP version actually needs to be read out from a register on
the ARM versions, but we will simply assume we are running on the
original hardware if arm,primecell-periphid is not explicitly
specified in the device tree.
Drop the !CONFIG_DM code and depend on DM_MMC.
Tested on the Versatile Express CA9x4 board.
Signed-off-by: Linus Walleij <[email protected]>
|
|
With MMC_PWRSEQ enabled the following link issue may happen when
building SPL and SPL_PWRSEQ is not enabled.
aarch64-linux-gnu-ld.bfd: drivers/mmc/meson_gx_mmc.o: in function `meson_mmc_probe':
drivers/mmc/meson_gx_mmc.c:295: undefined reference to `pwrseq_set_power'
Fix this by adding a SPL_MMC_PWRSEQ Kconfig option used to enable mmc
pwrseq support in SPL.
Also add depends on DM_GPIO to fix following link issue:
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.o: in function `mmc_pwrseq_set_power':
drivers/mmc/mmc-pwrseq.c:26: undefined reference to `gpio_request_by_name'
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:29: undefined reference to `dm_gpio_set_value'
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:31: undefined reference to `dm_gpio_set_value'
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Acked-by: Ferass El Hafidi <[email protected]>
|
|
U-Boot does not support building kernel modules.
Fixes: 3c0dbed232bd ("mmc: arm_pl180_mmci: adapt driver to DM usage")
Fixes: 36645f45a048 ("drivers: mmc: Add sdhci driver for Broadcom iProc platform")
Fixes: dadd43c14368 ("mmc: synquacer: Add SynQuacer F_SDH30 SDHCI driver")
Fixes: b312c590bcd8 ("mmc: Add MMC support for stm32h7 Socs")
Fixes: d24b69395949 ("mmc: mtk-sd: add SD/MMC host controller driver for MT7623 SoC")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Patrice Chotard <[email protected]>
|
|
If the CSD register contains a reserved value (4 - 7) in bits 0:2 of the
TRAN_SPEED field, a buffer overrun occurs. Resize the mapping table.
According to the original report
https://lore.kernel.org/u-boot/[email protected]/
reserved values have been observed resulting in a buffer overrun.
Reported-by: Eugeniu Rosca <[email protected]>
Fixes: 272cc70b211e ("Add MMC Framework")
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
CONFIG_SPL_SOCFPGA_DT_REG
Commit 3f190c55a4211215914126b74357344342329943
("drivers: misc: Add socfpga_dtreg driver for Intel SoCFPGA")
This commit rename CONFIG_SPL_SOCFPGA_SEC_REG to CONFIG_SPL_SOCFPGA_DT_REG
in Makefile.
Signed-off-by: Wan Yee Lau <[email protected]>
|
|
|
|
https://source.denx.de/u-boot/custodians/u-boot-nand-flash
The first patch is by Weizhao Ouyang and avoids sf probe crashes.
The second patch is by Arseniy Krasnov and adds basic support for Amlogic
Meson NAND controller on AXG.
The following four patches are by Alexander Dahl and apply some fixes to
drivers/mtd/nand/raw/ and port some changes applied in Linux.
The following patch is by Bruce Suen and adds support for XTX SPINAND.
Finally, the last patch is again by Arseniy Krasnov and adds access to
OTP region, supporting info, dump, write and lock operations.
|
|
Add support for XTX XT26G0xA and XT26xxxD. The driver is ported from
linux-6.7.1. This driver is tested on Banana BPI-R3 with XT26G01A and
XT26G12D.
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Bruce Suen <[email protected]>
Reviewed-by: Frieder Schrempf <[email protected]>
Signed-off-by: Dario Binacchi <[email protected]>
|
|
Introduced with commit 6a8dfd57220d ("nand: atmel: Add DM based NAND
driver") when driver was initially ported from Linux. The context
around this and especially the code itself suggests 'read' is meant
instead of write.
The fix is the same as accepted in Linux already with mainline Linux
kernel commit 1c60e027ffde ("mtd: nand: raw: atmel: Fix comment in
timings preparation").
Link: https://lore.kernel.org/all/[email protected]
Link: https://lore.kernel.org/linux-mtd/[email protected]/T/#t
Signed-off-by: Alexander Dahl <[email protected]>
Reviewed-by: Michael Trimarchi <[email protected]>
Signed-off-by: Dario Binacchi <[email protected]>
|
|
One tab in general. One tab plus two spaces for help text.
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Alexander Dahl <[email protected]>
Reviewed-by: Michael Trimarchi <[email protected]>
Signed-off-by: Dario Binacchi <[email protected]>
|
|
Introduced in upstream Linux with commit 7a08dbaedd365 for release v5.0.
When the new atmel nand driver was backported to U-Boot with commit
6a8dfd57220d ("nand: atmel: Add DM based NAND driver") that definition
was added to the driver instead of the header file. Move it over to the
other definitions with the same help text it has in Linux.
Code actually using this has not been ported over to raw nand base yet.
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Alexander Dahl <[email protected]>
Reviewed-by: Michael Trimarchi <[email protected]>
Signed-off-by: Dario Binacchi <[email protected]>
|
|
In every other place in this file the macro is used, make it consistent.
Link: https://lore.kernel.org/all/[email protected]
Fixes: 9d1806fadc24 ("mtd: nand: Get rid of mtd variable in function calls")
Signed-off-by: Alexander Dahl <[email protected]>
Reviewed-by: Michael Trimarchi <[email protected]>
Signed-off-by: Dario Binacchi <[email protected]>
|
|
Basic support for Amlogic Meson NAND controller on AXG. This version
works at only first EDO mode.
Based on Linux version 6.7.0-rc4.
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Arseniy Krasnov <[email protected]>
Reviewed-by: Michael Trimarchi <[email protected]>
Signed-off-by: Dario Binacchi <[email protected]>
|
|
Allowing multicast packets is required for IPv6 neighbor discovery
protocol.
Signed-off-by: Parvathi Bhogaraju <[email protected]>
Signed-off-by: Jim Liu <[email protected]>
|
|
In IPv6 context, the ICMP and UDP checksum byte in the RX packet
is initially set to 0, recaclculated, and then re-inserted.
This process can result in a dirty cache line. To prevent issues,
it is essential to invalidate cache for the RX buffer before freeing
the descriptor for next DMA transfer.
This ensure that the dirty cache line doesn't inadvertently written back
due to cache eviction, there by corrupting the RX buffer
Signed-off-by: Parvathi Bhogaraju <[email protected]>
Signed-off-by: Jim Liu <[email protected]>
|
|
Fix compilation warning:
../arch/arm/include/asm/io.h: In function 'eqos_free_pkt':
../arch/arm/include/asm/io.h:103:32: warning: 'rx_desc' may be used uninitialized [-Wmaybe-uninitialized]
103 | #define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
| ^~~
../drivers/net/dwc_eth_qos.c:1220:27: note: 'rx_desc' was declared here
1220 | struct eqos_desc *rx_desc;
| ^~~~~~~
Signed-off-by: Patrice Chotard <[email protected]>
|
|
MD Danish Anwar <[email protected]> says:
Introduce ICSSG PRUETH support in uboot. The ICSSG driver is used in TI
AM654 SR2.0.
The ICSSG PRU Sub-system runs on EMAC firmware. This series Introduces
support for ICSSG driver in uboot.
This series has been tested on AM65x SR2.0, and the ICSSG interface is
able to ping / dhcp and boot kernel using tftp in uboot.
To use ICSSG2 ethernet, the ICSSG firmware needs to be loaded to PRU RPROC
cores and RPROC cores need to be booted with the firmware. This step is
done inside driver similar to kernel.
The remoteproc driver uses request_fw_into_buf() API from fs-loader driver
to load and start rproc with the required firmwares.
This series only introduces driver files. The device tree and config
changes to enable ICSSG driver will be introduced later.
|
|
ICSSG firmware supports FDB commands. Add support to send FDB commands
from driver. Once rx_flow_id is obtained from dma, let firmware know that
we are using this rx_flow_id by sending a FDB command.
Reviewed-by: Ravi Gunasekaran <[email protected]>
Signed-off-by: MD Danish Anwar <[email protected]>
|
|
This is the PRUSS Ethernet driver for TI AM654 SR2.0 and later SoCs with
the ICSSG PRU Sub-system running EMAC firmware. ICSSG Subsystem supports
two slices per instance. This driver caters to both slices / ports of
the icssg subsystem.
Since it is not possible for Ethernet driver to register more than one
port for a given instance, this patch introduces top level PRUETH as
UCLASS_MISC and binds UCLASS_ETH to individual ports in order to support
bringing up more than one Ethernet interface in U-Boot.
Since top level driver is UCLASS_MISC, board files would need to
instantiate the driver explicitly.
Signed-off-by: MD Danish Anwar <[email protected]>
Reviewed-by: Ravi Gunasekaran <[email protected]>
|
|
Add icssg_queue.c file. This file introduces macros and APIs related to
ICSSG queues. These will be used by ICSSG Ethernet driver.
Reviewed-by: Ravi Gunasekaran <[email protected]>
Signed-off-by: MD Danish Anwar <[email protected]>
|
|
Add icssg_config.h / .c and icssg_classifier.c files. These are firmware
configuration and classification related files. Add MII helper APIs and
MACROs. These APIs and MACROs will be later used by ICSSG Ethernet driver.
Also introduce icssg_prueth.h which has definition of prueth related
structures.
Signed-off-by: MD Danish Anwar <[email protected]>
Reviewed-by: Ravi Gunasekaran <[email protected]>
|
|
Add firmware interface related headers and macros for ICSSG Ethernet
driver. These macros will be later used by the ICSSG ethernet driver.
Reviewed-by: Ravi Gunasekaran <[email protected]>
Signed-off-by: MD Danish Anwar <[email protected]>
|
