Daniel Schultz [Fri, 19 Apr 2024 15:55:39 +0000 (08:55 -0700)]
board: phytec: common: Fix eepom is empty check
The ptr variable is currently defined as int and sizeof
returns the size of the eeprom data struct as Byte (32 in total).
In case the eeprom is empty, the check, if the eeprom is empty,
will most likely stop after 8 iterations because it will continue
with the stack which should contain some data. Therefore, the
init function will detect an empty EEPROM as API0 and return with
the valid flag set to True.
Fixes: dc22188cdc8 ("board: phytec: Add common PHYTEC SoM detection") Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Teresa Remmet <t.remmet@phytec.de>
For all of the functions that access the eeprom_data, make sure these
data are valid. Use the valid member of the phytec_eeprom_data struct.
This fixes a bug where only the API revision check guarded against
accessing rubbish. But if API revision was e.g. 6, eeprom setup failed
before, but phytec_get_imx8m_eth would still happily access the data.
Fixes: dc22188cdc8 ("board: phytec: Add common PHYTEC SoM detection") Signed-off-by: Yannic Moog <y.moog@phytec.de> Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Teresa Remmet <t.remmet@phytec.de>
board: phytec: introduce eeprom struct member 'valid'
Add a new nember to the eeprom_data that indicates whether the
associated data is valid or not. Make use of this new member in the
phytec_eeprom_data_init function by setting the valid value
appropriately.
Move the eeprom data to a new struct payload that holds
the payload of the eeprom.
This prints the MMC device being read similar to how we print the MMC
device we write to when e.g. calling saveenv.
One of the side effects is that the boot log now shows from which MMC
device the env was loaded:
Loading Environment from MMC... Reading from MMC(1)... OK
This is useful to identify which MMC device the environment was loaded
from for boards where there are more than one (e.g. eMMC and SD card)
without adding some debug messages manually.
Sadly, there's no way to know which of the default or redundant
environment is being read from env_mmc_load before env_import_redund is
called so it is printing a bit later (and possibly after error/warning
messages).
Michal Simek [Mon, 15 Apr 2024 08:20:05 +0000 (10:20 +0200)]
Kconfig: Remove all default n options
default n doesn't need to be specified. It is default option anyway.
Similar changes have been done by commit 18370f14975c ("Kconfig: Remove all
default n/no options").
Marek Vasut [Sun, 14 Apr 2024 18:37:20 +0000 (20:37 +0200)]
boot: fdt: Turn all addresses and sizes into u64
In case of systems where DRAM bank ends at the edge of 32bit boundary,
start + size calculations would overflow. This happens on STM32MP15xx
with 1 DRAM bank starting at 0xc0000000 and 1 GiB of DRAM. This is a
usual 32bit system DRAM size overflow, fix it by doing all DRAM size
and offset calculations using u64 types. This also covers a case where
a 32bit PAE system might be able to address up to 36bits of DRAM.
Fixes: a4df06e41fa2 ("boot: fdt: Change type of env_get_bootm_low() to phys_addr_t") Signed-off-by: Marek Vasut <marex@denx.de>
This patch adds DEFLATE compression algorithm support. It's a good choice
to trade off between compression ratios and performance compared to LZ4.
Alternatively, DEFLATE could be used for some specific files since EROFS
supports multiple compression algorithms in one image.
Charles Hardin [Fri, 12 Apr 2024 20:45:33 +0000 (13:45 -0700)]
net: add support to parse the NIS domain for the dhcp options
There is code in the bootp parsing for NIS domain and add the
same support for the dhcp options as well. This allows the same
usage of the data when the dhcp command is used in the boot
command.
Signed-off-by: Charles Hardin <ckhardin@gmail.com>
input: button_kbd: gracefully handle buttons that fail probe
If a button device fails to probe, it will still be added to the uclass
device list, and therefore will still be iterated over in
button_read_keys() resulting in a UAF on the buttons private data.
Resolve this by unbinding button devices that aren't active after
probing, and print a warning so it's clear that the button is broken.
Tom Rini [Thu, 18 Apr 2024 18:13:40 +0000 (12:13 -0600)]
Merge tag 'tpm-master-18042024' of https://source.denx.de/u-boot/custodians/u-boot-tpm
Igor says:
"The problem initially was in the TEE sandbox driver implementation
(drivers/tee/sandbox.c) and it's limitations, which doesn't
permit to have multiple simultaneous sessions with different TAs.
This is what actually happened in this CI run [1], firstly "optee_rpmb"
cmd was executed (and after execution we had one session open), and
then "scp03", which also makes calls to OP-TEE, however it fails
in sandbox_tee_open_session() because of this check:
if (state->ta) {
printf("A session is already open\n");
return -EBUSY;
}
I had two ways in mind to address that:
1. Close a session on each optee_rpmb cmd invocation.
I don't see any reason to keep this session open, as obviously
there is no other mechanism (tbh, I don't know if DM calls ".remove" for active
devices) to close it automatically before handing over control to
Linux kernel. As a result we might end up with some orphaned sessions
registered in OP-TEE OS core (obvious resource leak).
2. Extend TEE sandbox driver, add support for multiple
simultaneous sessions just to handle the case.
I've chosen the first approach, as IMO it was "kill two birds with one stone",
I could address resource leak in OP-TEE and bypass limitations of
TEE sandbox driver."
Tom Rini [Thu, 18 Apr 2024 14:29:35 +0000 (08:29 -0600)]
Revert "Merge patch series "pxe: Allow extlinux booting without CMDLINE 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.
Unlike CMPC885 and CMPCPRO boards, the FPGA of MCR3000 board doesn't
load code automatically but needs to be loaded by software through SPI.
Until now it was loaded later by Linux, but we'd like U-boot to have
access to some information that require the FPGA, like board address
in racks.
So, implemented the load of FPGA in U-boot.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
To avoid spamming your email boxes, the code isn't included in
the emailed patch but will be present in the PULL request
Instead of cross using cross-directory makefile directives,
add a Makefile in board/cssi/common/ directory in order to
benefit from HAVE_VENDOR_COMMON_LIB logic.
spi: mpc8xx: Use 16 bit mode for large transfers with even size
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.
board: cssi: Add support for SPI bus on MCR3000 board
MCR3000 board has some components tied to the SPI bus, like the Texas
Instruments LM74 temperature sensor.
Add support for SPI bus. The SPI chipselects are a bit special in the
way that they are driven by 3 bits in a register of the board's CPLD
where the value writen in those bits exclusively activates one of the
7 possible chipselects and value 0 sets all chipselets to inactive.
So add a special GPIO driver that simulates GPIOs for those chipselect.
Hugo Dubois [Tue, 5 Dec 2023 16:10:44 +0000 (17:10 +0100)]
board: cssi: Properly initialise MAC address for fibre on CMPC885 board
CMPC885 board can be pluged on a mother board with fibre interface, so
fibre interface MAC address must be initialised for that case.
Signed-off-by: Hugo Dubois <hugo.dubois.ext@csgroup.eu> Reviewed-by: CASAUBON Jean Michel <jean-michel.casaubon@csgroup.eu> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Hugo Dubois [Fri, 1 Dec 2023 14:56:12 +0000 (15:56 +0100)]
board: cssi: Initialise port F on MIAE
When equipped with the SRSA audio board, MIAE equipment
has an additional port called port F.
Initialise that port just like other ports of the board, so
that it is already configured when starting Linux kernel.
Signed-off-by: Hugo Dubois <hugo.dubois.ext@csgroup.eu> Reviewed-by: CASAUBON Jean Michel <jean-michel.casaubon@csgroup.eu> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Fix it by removing cell-index and cell-size which is unused and add
reg property. Also fix node name to be in line with reg value.
Also add missing compatible for eeprom node.
Igor Opaniuk [Thu, 4 Apr 2024 13:19:51 +0000 (15:19 +0200)]
tee: remove common.h inclusion
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 <ilias.apalodimas@linaro.org> Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Igor Opaniuk [Thu, 4 Apr 2024 13:19:48 +0000 (15:19 +0200)]
cmd: optee_rpmb: close tee session
Close tee session after each optee_rpmb invocation, as there is no
reason to keep it open, considering the absence of any available mechanism
to clean up all open sessions automatically before handing over control
to the Linux kernel. Without proper clean-up we might end up with orphaned
sessions registered in OP-TEE OS core (obvious resource leak).
Signed-off-by: Igor Opaniuk <igor.opaniuk@gmail.com> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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:
Marek Vasut [Mon, 25 Mar 2024 08:17:54 +0000 (09:17 +0100)]
ARM: dts: renesas: Switch to using upstream DT
Enable OF_UPSTREAM to use upstream DT and add renesas/ prefix to the
DEFAULT_DEVICE_TREE and OF_LIST. And thereby directly build DTB from
dts/upstream/src/ including *-u-boot.dtsi files from arch/$(ARCH)/dts/
directory.
The configuration update has been done using the following script:
```
sed -i '/^CONFIG_DEFAULT_DEVICE_TREE/ s@="@&renesas/@' `git grep -li renesas configs`
sed -i '/^CONFIG_OF_LIST/ s@r8a@renesas/&@g' `git grep -li renesas configs`
```
The RZN1 Snarc board does not seem to have a matching Linux kernel
DT counterpart, this is currently not switched to OF upstream.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Marek Vasut [Mon, 18 Mar 2024 14:59:38 +0000 (15:59 +0100)]
ARM: dts: renesas: Switch to using upstream DT on 64bit Renesas SoCs
Enable OF_UPSTREAM to use upstream DT and add renesas/ prefix to the
DEFAULT_DEVICE_TREE and OF_LIST. And thereby directly build DTB from
dts/upstream/src/ including *-u-boot.dtsi files from arch/$(ARCH)/dts/
directory.
The configuration update has been done using the following script:
```
sed -i '/^CONFIG_DEFAULT_DEVICE_TREE/ s@="@&renesas/@' `git grep -li renesas configs`
sed -i '/^CONFIG_OF_LIST/ s@r8a@renesas/&@g' `git grep -li renesas configs`
```
There are SoCs which are not included in this patch. The 32bit SoCs
require further infrastructure work. R8A779H0 is coming during the
next upstream DT synchronization cycle as it is not included in
current upstream DTs yet.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Adam Ford <aford173@gmail.com> # Beacon boards Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Marek Vasut [Mon, 18 Mar 2024 14:59:37 +0000 (15:59 +0100)]
ARM: dts: renesas: Replace R8A77950 with R8A77951
R-Car R8A77950 H3 ES1.* was only available to an internal development
group and needed a lot of quirks and workarounds. Public users only
have R-Car R8A77950 H3 ES2 and newer. Switch existing systems to use
R8A77951 device trees.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Sun, 17 Mar 2024 06:23:38 +0000 (07:23 +0100)]
ARM: dts: renesas: Stop using the -u-boot DTs for build
The U-Boot build system can automatically paste -u-boot.dtsi at the
end of matching .dts during build. Stop emulating this behavior and
rename the -u-boot.dts files to -u-boot.dtsi, drop "#include...dts"
from those new u-boot.dtsi files, and update board configuration
accordingly.
The rename, '#include...dts` scrubbing and configuration update has
been done using the following script:
```
$ find . -name r[78]\*-u-boot.dts | sort -u | while read line ; do \
git mv ${line%-u-boot.dts}-u-boot.dts ${line%-u-boot.dts}-u-boot.dtsi ; \
done
$ sed -i '/^#include.*dts"/ d' `find . -name r[78]\*-u-boot.dtsi`
$ sed -i 's@-u-boot@@g' `git grep -li renesas configs`
```
The Salvator-X and ULCB board files have been updated manually.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Acked-by: Adam Ford <aford173@gmail.com>
sandbox: don't call os_close with invalid file descriptor
If open() fails it returns -1. Calling close() with this value
makes no sense. Return -EIO instead.
Addresses-Coverity-ID: 185828 Improper use of negative value Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Fixes: 566bf3a8698 ("sandbox: Add a function to read a host file") Reviewed-by: Sean Anderson <seanga2@gmail.com>
Andrew Davis [Wed, 10 Apr 2024 18:38:34 +0000 (13:38 -0500)]
arm: mach-k3: security: Lower verbosity of cert message for GP
When we find a certificate on an image to be booted on a GP device we
print out a message explaining that the certificate is being skipped.
This message is rather long and is printed for every image. Shorten
the message and make the long version into a debug message.
Signed-off-by: Andrew Davis <afd@ti.com> Tested-by: Jonathan Humphreys <j-humphreys@ti.com>
configs: am64x_evm_*_defconfig: Increase offsets for eMMC raw boot
EMMC boot can fail due to the size of R5 SPL image growing beyond the
500KB of memory allocated in eMMC. Update offsets for eMMMC raw boot
to load each binary from the correct address in eMMC according to the
following eMMC layout:
This is a trivial but significant optimization:
mkimage took >200ms (and 49489 writes (of which 49456 512)),
now it takes 110ms (and 419 writes (of which 386 64k)).
sendfile is much more appropriate for this and is done in one syscall,
but doesn't bring any significant speedups over 64k r/w
at the 13M size ranges, so there's no need to introduce
#if __linux__
while((size = sendfile(fd_dst, fd_src, NULL, 128 * 1024 * 1024)) > 0)
;
if(size != -1) {
ret = 0;
goto out;
}
#endif
Makefile.lib: find capsule ESL dtsi file with CONFIG_OF_UPSTREAM
When CONFIG_OF_UPSTREAM is enabled, DTS files are in SOC subdirectories (vs the
top level dts directory), but when CONFIG_EFI_CAPSULE_AUTHENTICATE is enabled,
the dynamically created dtsi file containing the capsule ESL DT node is in the
parent directory. This results in a build failure because the #include inserted
in the DTS file is local to the current directory. Update Makefile to have the
DT preprocessing of #includes search in the parent (dts top level) directory
too.
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
This patch series is needed to get U-Boot to boot from a ZFS filesystem
on an aarch64 computer. Some of the patches are not architecture specific
and would be needed to boot ZFS on other platforms as well. The ZFS
support in U-Boot hasn't been substantively touched in several years and
to me it seems like it must have been broken for a long time on all
platforms, but I have only tested on aarch64.
Since there doesn't seem to be a mantainer for this area who I can cc,
I'm hoping these patches get seen and pulled in by a general U-Boot
maintainer.
[trini: Per Igor's comment and Phaedrus agreement, dropped his Tested-by
on the patches themselves]
Without this patch, the while loop being modified goes on infinitely,
but with the patch I am able to boot linux on zfs on a jetson tx2 nx.
It seems like this code was never tested because the logic is clearly
wrong. The function do_div(a,b) does a division that modifies the first
parameter to have a = a / b, and returns the remainder of the division.
So clearly in the usual case when file->offset = 0, the line
"blkid = do_div(blkid, blksz);" just results in blkid being set to zero
on every iteration of the loop, rather than being incremented as blocks
are read. Hence the zeroth block is read over and over and this becomes
an infinite loop.
So instead capture the remainder of the division in a "blkoff" variable,
and use that to properly calculate the memory address to move from in
memmove() below.
For example, if file->offset were 1337, on the first iteration of the
loop blkid would be 0 and blkoff would be 1337. If the blksz is 131072
(as it was for me), that amount of data would be copied into
data->file_buf. movesize would be 131072 - 1337 = 129735 so 129735 bytes
would be moved into buf. On the second iteration of the loop (assuming
there is one), red would be 129735, blkid would be 1, blkoff would be 0,
and 131072 bytes would be copied into buf. And so on...
As evidenced by how other filesystems handle it, a return value of 0
from fs_devread() means failure; nonzero means success. The opposite
assumption was being made in zfs.c for the use of zfs_devread() so fix
the confusion by making zfs_devread() return 0 on success.
It probably doesn't make sense to change the handling of zfs_devread()
in zfs.c instead, because as it is it matches the semantics of the other
functions there.
This happens when be64_to_cpu() is called on a value that exists at a
memory address that's 4 byte aligned but not 8 byte aligned (e.g. an
address ending in 04). The call stack where that happens is:
check_pool_label() ->
zfs_nvlist_lookup_uint64(vdevnvlist, ZPOOL_CONFIG_ASHIFT,...) ->
be64_to_cpu()
This code was hitting the error code path whenever malloc() succeeded
rather than when it failed, so presumably this part of the code hasn't
been tested. I had to apply this fix (and others) to get U-Boot to boot
from ZFS on an Nvidia Jetson TX2 NX SoM (an aarch64 computer).
net: wget: fix TCP sequence number wrap around issue
If tcp_seq_num is wrap around, tcp_seq_num >= initial_data_seq_num
isn't satisfied and store_block() isn't called.
The condition has a wrap around issue, so it is fixed in this patch.
Signed-off-by: Yasuharu Shibata <yasuharu.shibata@gmail.com> Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com> Suggested-by: Michael Trimarchi <michael@amarulasolutions.com> Reported-by: Tim Harvey <tharvey@gateworks.com> Tested-by: Fabio Estevam <festevam@denx.de>
net: wget: Support retransmission a dropped packet
The server sends multiple packets without waiting for an ACK
by window control and if some packets are dropped,
wget will return an ACK including the dropped packets.
First packet of TCP sequence number is 0x97bbdd4a.
Second packet of TCP sequence number should be 0x97bbe2ca,
however it is 0x97bbedca and returns its ACK, so the server
suppose that 0x97bbe2ca and 0x97bbedca are received appropriately.
In this case, 0x97bbe2ca was lost and the data of wget was broken.
In this patch, next_data_seq_num holds the next expected
TCP sequence number.
If the TCP sequence number different from next_data_seq_num,
trying to retransmit the packet.
- 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.
Tom Rini [Mon, 15 Apr 2024 13:38:18 +0000 (07:38 -0600)]
Merge tag 'u-boot-socfpga-next-20240415' of https://source.denx.de/u-boot/custodians/u-boot-socfpga
- Add option to reprogram FPGA every reboot, enable this as default in
chameleonv3 defconfig.
- Fixes: Rename CONFIG_SPL_SOCFPGA_SEC_REG to CONFIG_SPL_SOCFPGA_DT_REG,
so the driver can be built when CONFIG_SPL_SOCFPGA_DT_REG is set in
defconfig.
Yang Xiwen [Thu, 1 Feb 2024 14:05:43 +0000 (22:05 +0800)]
mmc: dw_mmc: Don't return error if data busy timeout
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.
Marek Vasut [Sun, 17 Mar 2024 03:01:22 +0000 (04:01 +0100)]
mmc: Unconditionally call mmc_deinit()
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.
Marek Vasut [Sat, 24 Feb 2024 22:32:11 +0000 (23:32 +0100)]
mmc: renesas-sdhi: Do not access SCC during tuning in send_cmd callback
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 <paul.barker.ct@bp.renesas.com> Tested-by: Paul Barker <paul.barker.ct@bp.renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Marek Vasut [Sat, 24 Feb 2024 22:32:10 +0000 (23:32 +0100)]
mmc: Add generic tuning flag
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 <marek.vasut+renesas@mailbox.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Marek Vasut [Sat, 24 Feb 2024 22:32:09 +0000 (23:32 +0100)]
mmc: Convert hs400_tuning flag from u8 to bool
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 <marek.vasut+renesas@mailbox.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Marek Vasut [Tue, 20 Feb 2024 08:38:45 +0000 (09:38 +0100)]
mmc: renesas-sdhi: Stop transmission in case tuning block transfer fails
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 <marek.vasut+renesas@mailbox.org> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com> Tested-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Marek Vasut [Tue, 20 Feb 2024 08:38:14 +0000 (09:38 +0100)]
mmc: tmio: Check INFO1 for completion during DMA transfer
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 <marek.vasut+renesas@mailbox.org> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com> Tested-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Linus Walleij [Thu, 8 Feb 2024 09:33:43 +0000 (10:33 +0100)]
mmc: arm_pl180_mmci: Rely on DM
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.
Jonas Karlman [Sat, 27 Jan 2024 17:12:35 +0000 (17:12 +0000)]
mmc: Add SPL_MMC_PWRSEQ to fix link issue when building SPL
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 <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Ferass El Hafidi <vitali64pmemail@protonmail.com>
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/20180826231332.2491-11-erosca@de.adit-jv.com/
reserved values have been observed resulting in a buffer overrun.
projects / u-boot.git / log