Profiling the EHCI driver shows a significant performance problem in
ehci_submit_async(). Specifically, this function keeps enabling and
disabling async schedule back and forth for every single transaction.
However, enabling/disabling the async schedule does not take effect
immediatelly, but instead may take up to 1 mS (8 uFrames) to complete.
This impacts USB storage significantly, esp. since the recent reduction
of maximum transfer size to support more USB storage devices. This in
turn results in sharp increase in the number of ehci_submit_async()
calls. Since one USB storage BBB transfer does three such calls and
the maximum transfer size is 120 kiB, the overhead is 6 mS per 120 kiB,
which is unacceptable.
However, this overhead can be removed simply by keeping the async
schedule running. Specifically, the first transfer starts the async
schedule and then each and every subsequent transfer only adds a new
QH into that schedule, waits until the QH is completed and does NOT
disable the async schedule. The async schedule is stopped only by
shutting down the controller, which must happen before moving out
of U-Boot, otherwise the controller will corrupt memory.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Clear the USB_READY flag in the storage driver only in case there
is an error, otherwise usb_stor_BBB_transport() waits 5 mS before
doing anything every single time.
This is because the USB_READY flag is only ever set in
usb_test_unit_ready(), which is called only upon storage device
probe, not between each and every request. However, the device
cannot move out of USB_READY state once it was initialized.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Due to constant influx of more and more weird and broken USB sticks,
do as Linux does in commit 779b457f66e10de3471479373463b27fd308dc85
usb: storage: scsiglue: further describe our 240 sector limit
Just so we have some sort of documentation as to why
we limit our Mass Storage transfers to 240 sectors,
let's update the comment to make clearer that
devices were found that would choke with larger
transfers.
While at that, also make sure to clarify that other
operating systems have similar, albeit different,
limits on mass storage transfers.
And reduce the maximum transfer length of USB storage to 120 kiB.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Add weak callback to allow board specific behavior
- flush
- initiated
This patch prepare usage of DFU back end for communication with
STM32CubeProgrammer on stm32mp1 platform with stm32prog command.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add a virtual DFU backend to allow board specific read and write
(for OTP update for example).
Acked-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add the support of MTD partition for the MTD backend.
The expected dfu_alt_info for one alternate on the mtd device :
<name> part <part_id>
<name> partubi <part_id>
"partubi" also erase up to the end of the partition after write operation.
For example: dfu_alt_info = "spl part 1;u-boot part 2; UBI partubi 3"
U-Boot> dfu 0 mtd nand0
Acked-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add DFU backend for MTD device: allow to read
and write on all MTD device (NAND, SPI-NOR,
SPI-NAND,...)
For example :
> set dfu_alt_info "nand_raw raw 0x0 0x100000"
> dfu 0 mtd nand0
This MTD backend provides the same level than dfu nand
backend for NAND and dfu sf backend for SPI-NOR;
So it can replace booth of them but it also
add support of spi-nand.
> set dfu_alt_info "nand_raw raw 0x0 0x100000"
> dfu 0 mtd spi-nand0
The backend code is based on the "mtd" command
introduced by commit 5db66b3aee ("cmd: mtd:
add 'mtd' command")
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
This patch allows the DFU backend to indicate that that it can't
provide no more data to fill the DFU buffer, by setting b_left =0
without error, even if the size of received data is lower of the
expected total size indicated by get_medium_size.
For USB DFU stack point of view, it is acceptable:
the read length < requested size in DFU_UPLOAD and the
transaction is stopped.
That avoid infinite loop issue in dfu_read_buffer_fill because the
size for the DFU read is limited by get_medium_size = r_left
and the DFU stack expects that read is allowed up to this size.
This issue never occurs for current flash device (where chunk are
always completely read, and b_left will be never 0) but it is useful for
virtual partition when the backend only know the max size of this
alternate, the real size of the data are only known in the read
treatment.
PS: for file access on mmc, EOF is never reached as
dfu_get_medium_size_mmc returns the exact size of the file.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add support of DFU for several interface/device
with one command.
The format for "dfu_alt_info" in this case is :
- <interface> <dev>'='alternate list (';' separated)
- each interface is separated by '&'
The previous behavior is always supported.
One example for NOR (bootloaders) + NAND (rootfs in UBI):
U-Boot> env set dfu_alt_info \
"sf 0:0:10000000:0=spl part 0 1;u-boot part 0 2; \
u-boot-env part 0 3&nand 0=UBI partubi 0,3"
U-Boot> dfu 0 list
DFU alt settings list:
dev: SF alt: 0 name: spl layout: RAW_ADDR
dev: SF alt: 1 name: ssbl layout: RAW_ADDR
dev: SF alt: 2 name: u-boot-env layout: RAW_ADDR
dev: NAND alt: 3 name: UBI layout: RAW_ADDR
U-Boot> dfu 0
$> dfu-util -l
Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\
intf=0, alt=3, name="UBI", serial="002700333338511934383330"
Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\
intf=0, alt=2, name="u-boot-env", serial="002700333338511934383330"
Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\
intf=0, alt=1, name="u-boot", serial="002700333338511934383330"
Found DFU: [0483:5720] ver=9999, devnum=96, cfg=1,\
intf=0, alt=0, name="spl", serial="002700333338511934383330"
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Copy the partition support from NAND backend to SF,
support part and partubi option.
In case of ubi partition, erase the rest of the
partition as it is mandatory for UBI.
The added code is under compilation flag CONFIG_DFU_SF_PART
activated by default.
for example:
U-Boot> env set dfu_alt_info "spl part 0 1;\
u-boot part 0 2;u-boot-env part 0 3;UBI partubi 0 4"
U-Boot> dfu 0 sf 0:0:10000000:0
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Calling cache flush on invalid buffer, even with zero length might cause
an exception on certain platforms.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Add possibility to define a part of partition as a separate DFU entity.
This allows to have more than one items on the given partition.
The real use case for this option is TM2 board. It can use u-boot stored
as Linux kernel on the defined partition (as RAW data) and load the real
kernel from the same partition, but stored under the certain offset.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Lukasz Majewski <lukma@denx.de>
'THOR' download command requires DFU infrastructure to properly flash
board images. It can be used without enabling DFU command, so add such
dependency to Kconfig.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Lukasz Majewski <lukma@denx.de>
This is needed to make Windows THOR flash tool happy, because it
starts sending data only when interrupt packet is received on the 3rd
endpoint.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Lukasz Majewski <lukma@denx.de>
In combination with multiple partitions in NAND, this printf() ends up
being more noise than helpful. Change it to debug() instead.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Acked-by: Lukasz Majewski <lukma@denx.de>
Some boards don't populate clk/reset entries as these are are optional
as per binding documentation. Therefore, don't fail driver probe if
clk/reset entries are absent in DT.
This fixes fastboot failures seen due to enabling of CONFIG_CLK on AM57xx
Fixes: e8e683d33b ("board: ti: am57xx-idk: Configure the CDCE913 clock synthesizer")
Reported-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
- Add I2C clocks for i.MX6Q CCF driver
- Fix check in clk_set_default_parents()
- Managed API to get clock from device tree
- Fixes for core clock code (including sandbox regression tests)
This expands current Azure Pipelines Windows host tools build
testing to cover all the CI testing in gitlab and travis CI.
Note for some unknown reason, the 'container' cannot be used for
any jobs that have buildman, for buildman does not exit properly
and hangs the job forever. As a workaround, we manually call
docker to run the image to perform the CI tasks.
A complete run on Azure Pipelines takes about 2 hours and 10
minutes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
At present some boards generate kwbimage.cfg in the source tree
during the build. This breaks buildman testing on some systems
where the source tree is read-only. Update makefile rules to
generate it in the build tree instead.
Note some other boards have the kwbimage.cfg file written in
advance, hence we need check if the file exists in the build
tree first, otherwise we fall back to one in the source tree.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
In the 'Make' function, the codes tries to create a directory
if current stage is 'build'. But the directory isn't used at
all anywhere.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
buildman always generates boards.cfg in the U-Boot source tree.
When '-o' is given, we should generate boards.cfg to the given
output directory.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
On i.MX8, when booting from eMMC boot partition, the whole flash.bin
is stored in boot partition, however SPL switches to user partition
during the init of mmc driver:
spl_mmc_load() -> mmc_init()
Then it tries to load the container image in
spl_mmc_get_uboot_raw_sector(), but here it reads the data from user
partition and the header is not recognized as a valid header.
So we move spl_mmc_get_uboot_raw_sector after eMMC partition switch
to address this issue.
Anyway put spl_mmc_get_uboot_raw_sector before eMMC partition switch
is not correct, so let's move it after eMMC partition switch.
Reported-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
A previous patch below adding DDR mode support was actually for i.MX
platforms. Now i.MX eSDHC driver is fsl_esdhc_imx.c. For QorIQ eSDHC,
it uses different process for DDR mode, and hasn't been supported.
Let's drop DDR support code for i.MX in fsl_esdhc driver.
0e1bf61 mmc: fsl_esdhc: Add support for DDR mode
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
U-boot prefers DM_MMC + BLK for MMC. Now eSDHC driver has already
support it, so let's force to use it.
- Drop non-BLK support for DM_MMC introduced by below patch.
66fa035 mmc: fsl_esdhc: fix probe issue without CONFIG_BLK enabled
- Support only DM_MMC + BLK (assuming BLK is always enabled for DM_MMC).
- Use DM_MMC instead of BLK for conditional compile.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Microsoft Azure Pipelines [1] provides unlimited CI/CD minutes and
10 parallel jobs to every open source project for free.
This adds a configuration file for Azure Pipelines to utilize the
free Windows VM hosted by Microsoft to ensure no build broken in
building U-Boot host tools for Windows.
[1] https://azure.microsoft.com/en-us/blog/announcing-azure-pipelines-with-unlimited-ci-cd-minutes-for-open-source/
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
When building U-Boot host tools for Windows from Microsoft Azure
Pipelines, the following errors were seen:
HOSTCC tools/mkenvimage.o
In file included from tools/mkenvimage.c:25:
./tools/version.h:1:1: error: expected identifier or ‘(’ before ‘.’ token
1 | ../include/version.h
| ^
tools/mkenvimage.c: In function ‘main’:
tools/mkenvimage.c:117:4: warning: implicit declaration of function ‘usage’ [-Wimplicit-function-declaration]
117 | usage(prg);
| ^~~~~
tools/mkenvimage.c:120:35: error: ‘PLAIN_VERSION’ undeclared (first use in this function)
120 | printf("%s version %s\n", prg, PLAIN_VERSION);
| ^~~~~~~~~~~~~
tools/mkenvimage.c:120:35: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [scripts/Makefile.host:114: tools/mkenvimage.o] Error 1
It turns out tools/version.h is a symbolic link and with Windows
default settings it is unsupported hence the actual content of
tools/version.h is not what file include/version.h has, but the
the linked file path, which breaks the build.
To fix this, remove the symbolic links for tools/version.h. Instead
we perform a copy from include/version.h during the build.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
When building U-Boot host tools for Windows from Microsoft Azure
Pipelines, we see tons of weird warnings and errors emitted from
every Kconfig files:
Kconfig:6:warning: ignoring unsupported character ''
Kconfig:6:warning: ignoring unsupported character ''
Kconfig:8:warning: ignoring unsupported character ''
Kconfig:9:warning: ignoring unsupported character ''
Kconfig:10:warning: ignoring unsupported character ''
Kconfig:10:warning: ignoring unsupported character ''
Kconfig:13:warning: ignoring unsupported character ''
arch/Kconfig:1:warning: ignoring unsupported character ''
arch/Kconfig:2:warning: ignoring unsupported character ''
arch/Kconfig:2:warning: ignoring unsupported character ''
arch/Kconfig:4:warning: ignoring unsupported character ''
...
After several rounds of experiments, it turns out this is caused
by line endings. Historically, Linux and macOS used linefeed (LF)
characters while Windows used a carriage return plus a linefeed
(CRLF). When Azure Pipelines checks out the U-Boot repo, Git tries
to compensate for the difference by automatically making lines end
in CRLF in the working directory on Windows, which confuses the
Kconfig file parsing logic.
Fortunately Git provides a way for repos to tell Git not to do such
automatical line endings conversion via .gitattributes file below:
* text eol=lf
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
This adds a reST document for how to build U-Boot host tools,
including information for both Linux and Windows.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
'struct ustat' uses linux-specific typedefs to declare its memebers:
__kernel_daddr_t and __kernel_ino_t. It is currently not used by any
U-Boot codes, but when we build U-Boot tools for other platform like
Windows, this becomes a problem.
Let's surround it with __linux__.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
__swab32() is a Linux specific macro defined in linux/swab.h. Let's
use the compiler equivalent builtin function __builtin_bswap32() for
better portability.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
__leXX has Linux kernel specific __attribute__((bitwise)) which is
not portable. Use corresponding uintXX_t instead.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
- bmips: various small fixes
- mtmips: add new drivers for clock, reset-controller and pinctrl
- mtmips: add support for high speed UART
- mtmips: update/enhance drivers for SPI and ethernet
- mtmips: add support for MMC
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiQkHUH+J02LLC9InKPlOlyTyXBgFAl2zFisACgkQKPlOlyTy
XBgf9RAAkNwLjqUcBz3Ob1briRG5HF4D6bZCpjtkTIO8a2fanUHbSehh30TX8x2X
z0t/9Sd4OZwAeTxfQ/AlbbVdiB9IMgEb6lJ30Vr88MRNoPhABIQ8hw5xAzFi/6x9
88YolS/HQo6iR9rzSlaKjdIHhPTH5oQzRJ3JLqSwZzfUNy+zqINEhs3SYCnD2lyV
gTgiIT3Y5nKrhVHPUCy+jQG+wwWej2NFgwn71vR3/PSQJwxBuasg0qqOKD9hRtpC
XL6VErE7bf00elO8xjEObYrmB2FpffXJdkazS2HtRYNyKx0quaRNXJt7wqxEVP9L
M6SmL+S7zBFAetc/iyrlaakPvn7ImehSZkgLYaTPc3yzO+6bgq9tLfBERn/B/s5g
YyIzPGF66L96nuu0eVGCgSoUBjzBE8l2QTI8dho5xJxjWAUJOWSB0egqfFZzYVFu
4X37w6Z0j6uTK2oEl7KgJdc0JsZRsAJ8ZiqgOeNeMUTl2RnjGt0Oa7E24Va3n3hM
5vuEba9nPUFmdC5vlSd2RUK/dB587uKV93r5j54U62clpbiK+VMaRuRVX64ytZvB
B/0fKyCu+y7bxeZe4/X27jBUOk5yCuxbNI66m+cnnvfHqEmhz5PfDCEK1Dr29oqf
sCJLgTr7ahyuW4kEoL7KCOBEugPI85fp8/OlqC63M6/Kft0w5sA=
=6G/J
-----END PGP SIGNATURE-----
Merge tag 'mips-pull-2019-10-25' of git://git.denx.de/u-boot-mips
- bmips: add BCRM NAND support for BCM6368, BCM6328, BCM6362 and BCM63268 SoCs
- bmips: various small fixes
- mtmips: add new drivers for clock, reset-controller and pinctrl
- mtmips: add support for high speed UART
- mtmips: update/enhance drivers for SPI and ethernet
- mtmips: add support for MMC
Add the address spaces for the R5F cores in MCU domain to the ranges
property of the cbass_mcu interconnect node so that the addresses
within the R5F nodes can be translated properly by the relevant OF
address API.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
In SPL, DDR should be made available by the end of board_init_f()
so that apis in board_init_r() can use ddr. Adding support for
triggering DDR initialization from board_init_f().
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Use the 3733MTs DDR configuration that is auto generated from
DDR_Regconfig tool.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Kevin Scholz <k-scholz@ti.com>
The J721E DDR subsystem comprises DDR controller, DDR PHY and wrapper
logic to integrate these blocks in the device. The DDR subsystem is
used to provide an interface to external SDRAM devices which can be
utilized for storing program or data. Introduce support for the
DDR controller and DDR phy within the DDR subsystem.
Signed-off-by: Kevin Scholz <k-scholz@ti.com
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
