At HS400 mode the ITAPDLY value is that from High Speed mode
which is incorrect and may cause boot failures.
The ITAPDLY for HS400 speed mode should be the same as ITAPDLY
as HS200 timing after tuning is executed. Add the functionality
to save ITAPDLY from HS200 tuning and save as HS400 ITAPDLY.
Fixes: c964447ea3 ("mmc: am654_sdhci: Add support for input tap delay")
Signed-off-by: Judith Mendez <jm@ti.com>
According to the device datasheet [0], ENDLL=1 for
DDR52 mode, so call am654_sdhci_setup_dll() and write
itapdly after since we do not carry out tuning.
[0] https://www.ti.com/lit/ds/symlink/am62p.pdf
Fixes: c964447ea3 ("mmc: am654_sdhci: Add support for input tap delay")
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Set itap_del_ena if ITAPDLY is found in DT or if the tuning
algorithm was executed and found the optimal ITAPDLY. Add the
functionality to save ITAPDLYENA that can be referenced later
by storing the bit in array itap_del_ena[].
Signed-off-by: Judith Mendez <jm@ti.com>
U-Boot is failing to boot class U1 UHS SD cards due to incorrect
OTAP and ITAP delay select values. Update OTAP and ITAP delay select
values from DT.
Fixes: c7d106b4eb ("mmc: am654_sdhci: Update output tap delay writes")
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
Signed-off-by: Judith Mendez <jm@ti.com>
Currently the sdhci_am654 driver only supports one tuning
algorithm which should be used only when DLL is enabled. The
ITAPDLY is selected from the largest passing window and the
buffer is viewed as a circular buffer.
The new tuning algorithm should be used when the delay chain
is enabled; the ITAPDLY is selected from the largest passing
window and the buffer is not viewed as a circular buffer.
This implementation is based off of the following paper: [1].
Also add support for multiple failing windows.
[1] https://www.ti.com/lit/an/spract9/spract9.pdf
Fixes: a759abf569 ("mmc: am654_sdhci: Add support for software tuning")
Signed-off-by: Judith Mendez <jm@ti.com>
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>
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>
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>
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>
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: 566bf3a869 ("sandbox: Add a function to read a host file")
Reviewed-by: Sean Anderson <seanga2@gmail.com>
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>
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:
boot0/1 partition
0x0+----------------------------------+
| tiboot3.bin (1 MB) |
0x800+----------------------------------+
| tispl.bin (2 MB) |
0x1800+-----------------------------------+
| u-boot.img (4 MB) |
0x3800+-----------------------------------+
| environment (128 KB) |
0x3900+-----------------------------------+
Signed-off-by: Judith Mendez <jm@ti.com>
The FAT specification requires that the change date is set.
If a DM RTC device exists, set the creation and change date to the current
date when updating the directory entry. Otherwise use the date 2020-01-01.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The month is stored in 5 - 8. We need to shift it by 5 bits.
Cf. Microsoft FAT Specification, 2005-08-30
Fixes: 13c11c6653 ("fs: fat: add file attributes to struct fs_dirent")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Alexander Dahl <ada@thorsis.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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
Also extract the buffer size to a macro.
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
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>
Jonathan Humphreys <j-humphreys@ti.com> says:
Set basic settings needed for System Ready IR ACS testing, for several TI SoC
based platforms: AM64, AM62, AM62p, BeaglePlay, J7, and BeagleboneAI.
For AM64, AM62, and AM62p, also includes some config cleanup. Should be no
functional change.
mwleeds@mailtundra.com <mwleeds@mailtundra.com> says:
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...
Signed-off-by: Phaedrus Leeds <mwleeds@mailtundra.com>
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.
Signed-off-by: Phaedrus Leeds <mwleeds@mailtundra.com>
Without this patch, when trying to boot zfs using U-Boot on a Jetson TX2
NX (which is aarch64), I get a CPU reset error like so:
"Synchronous Abort" handler, esr 0x96000021
elr: 00000000800c9000 lr : 00000000800c8ffc (reloc)
elr: 00000000fff77000 lr : 00000000fff76ffc
x0 : 00000000ffb40f04 x1 : 0000000000000000
x2 : 000000000000000a x3 : 0000000003100000
x4 : 0000000003100000 x5 : 0000000000000034
x6 : 00000000fff9cc6e x7 : 000000000000000f
x8 : 00000000ff7f84a0 x9 : 0000000000000008
x10: 00000000ffb40f04 x11: 0000000000000006
x12: 000000000001869f x13: 0000000000000001
x14: 00000000ff7f84bc x15: 0000000000000010
x16: 0000000000002080 x17: 00000000001fffff
x18: 00000000ff7fbdd8 x19: 00000000ffb405f8
x20: 00000000ffb40dd0 x21: 00000000fffabe5e
x22: 000000ea77940000 x23: 00000000ffb42090
x24: 0000000000000000 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 0000000000bab10c x29: 00000000ff7f85f0
Code: d00001a0 9103a000 94006ac6 f9401ba0 (f9400000)
Resetting CPU ...
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()
Signed-off-by: Phaedrus Leeds <mwleeds@mailtundra.com>
Fixes: 4d3c95f5ea ("zfs: Add ZFS filesystem support")
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).
Signed-off-by: Phaedrus Leeds <mwleeds@mailtundra.com>
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.
Following log indicates this issue.
wget_handler() wget: Transferring, seq=97bbdd4a, ack=30,len=580
wget_handler() wget: Transferring, seq=97bbedca, ack=30,len=580
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.
Signed-off-by: Yasuharu Shibata <yasuharu.shibata@gmail.com>
Tested-by: Fabio Estevam <festevam@gmail.com>
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.
- 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.
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 <peng.fan@nxp.com>
Judith MendezandTom Rini
Nitin YadavandTom Rini
Marek Vasut
Heinrich SchuchardtandTom Rini
Andrew DavisandTom Rini
Jim LiuandTom Rini
Ahelenia ZiemiańskaandTom Rini
Jonathan HumphreysandTom Rini
mwleeds@mailtundra.comandTom Rini
Yasuharu ShibataandTom Rini
Peng FanandFabio Estevam