Re: [PATCH 061/149] board: freescale: Remove and add needed includes
> 在 2024年5月1日，10:44，Tom Rini 写道： > > Remove from this board vendor directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini > --- > Cc: Stefano Babic > Cc: Fabio Estevam > Cc: "NXP i.MX U-Boot Team" > Cc: Peng Fan > Cc: Giulio Benetti > Cc: Jesse Taube > Cc: Pramod Kumar > Cc: Alison Wang > Cc: Tang Yuantian > Cc: Mingkai Hu > Cc: Ashish Kumar > Cc: Priyanka Jain > Cc: Wasim Khan > Cc: Meenakshi Aggarwal > Cc: Angelo Dureghello > Cc: TsiChung Liew > Cc: Sinan Akman > Cc: Otavio Salvador > Cc: Jason Liu > Cc: Eric Nelson > Cc: Adrian Alonso > Cc: Qiang Zhao > Cc: Shengzhou Liu Acked-by: Jason Liu > --- > arch/arm/include/asm/arch-imx8m/ddr.h | 2 +- > arch/arm/include/asm/mach-imx/gpio.h | 2 ++ > board/freescale/common/cadmus.c | 3 ++- > board/freescale/common/cds_pci_ft.c | 1 - > board/freescale/common/cds_via.c | 1 - > board/freescale/common/cmd_esbc_validate.c| 2 +- > board/freescale/common/emc2305.c | 1 - > board/freescale/common/fman.c | 1 - > board/freescale/common/fsl_chain_of_trust.c | 2 +- > board/freescale/common/fsl_validate.c | 2 +- > board/freescale/common/i2c_common.c | 2 +- > board/freescale/common/i2c_mux.c | 3 ++- > board/freescale/common/ics307_clk.c | 2 +- > board/freescale/common/ls102xa_stream_id.c| 2 +- > board/freescale/common/mc34vr500.c| 1 - > board/freescale/common/mmc.c | 2 +- > board/freescale/common/ngpixis.c | 1 - > board/freescale/common/ns_access.c| 2 +- > board/freescale/common/p_corenet/law.c| 2 +- > board/freescale/common/p_corenet/tlb.c| 3 ++- > board/freescale/common/pfuze.c| 1 - > board/freescale/common/qixis.c| 2 +- > board/freescale/common/sdhc_boot.c| 1 - > board/freescale/common/sys_eeprom.c | 1 - > board/freescale/common/vid.c | 3 ++- > board/freescale/imx8mm_evk/imx8mm_evk.c | 1 - > board/freescale/imx8mm_evk/spl.c | 1 - > board/freescale/imx8mn_evk/imx8mn_evk.c | 1 - > board/freescale/imx8mn_evk/spl.c | 1 - > board/freescale/imx8mp_evk/spl.c | 1 - > board/freescale/imx8mq_evk/imx8mq_evk.c | 1 - > board/freescale/imx8mq_evk/lpddr4_timing.c| 1 - > board/freescale/imx8mq_evk/lpddr4_timing_b0.c | 1 - > board/freescale/imx8mq_evk/spl.c | 2 +- > board/freescale/imx8qm_mek/imx8qm_mek.c | 1 - > board/freescale/imx8qm_mek/spl.c | 1 - > board/freescale/imx8qxp_mek/imx8qxp_mek.c | 1 - > board/freescale/imx8qxp_mek/spl.c | 1 - > board/freescale/imx8ulp_evk/imx8ulp_evk.c | 1 - > board/freescale/imx8ulp_evk/spl.c | 1 - > board/freescale/imx93_evk/imx93_evk.c | 1 - > board/freescale/imx93_evk/spl.c | 1 - > board/freescale/imxrt1020-evk/imxrt1020-evk.c | 1 - > board/freescale/imxrt1050-evk/imxrt1050-evk.c | 1 - > board/freescale/imxrt1170-evk/imxrt1170-evk.c | 1 - > board/freescale/ls1012afrdm/eth.c | 1 - > board/freescale/ls1012afrdm/ls1012afrdm.c | 2 +- > board/freescale/ls1012aqds/eth.c | 2 +- > board/freescale/ls1012aqds/ls1012aqds.c | 2 +- > board/freescale/ls1012ardb/eth.c | 2 +- > board/freescale/ls1012ardb/ls1012ardb.c | 2 +- > board/freescale/ls1021aiot/ls1021aiot.c | 2 +- > board/freescale/ls1021aqds/ddr.c | 2 +- > board/freescale/ls1028a/ddr.c | 1 - > board/freescale/ls1028a/ls1028a.c | 2 +- > board/freescale/ls1043aqds/ddr.c | 1 - > board/freescale/ls1043aqds/eth.c | 2 +- > board/freescale/ls1043aqds/ls1043aqds.c | 2 +- > board/freescale/ls1043ardb/cpld.c | 2 +- > board/freescale/ls1043ardb/ddr.c | 1 - > board/freescale/ls1043ardb/eth.c | 2 +- > board/freescale/ls1046afrwy/ddr.c | 1 - > board/freescale/ls1046afrwy/eth.c | 2 +- > board/freescale/ls1046afrwy/ls1046afrwy.c | 2 +- > board/freescale/ls1046aqds/ddr.c | 1 - > board/freescale/ls1046aqds/eth.c | 2 +- > board/freescale/ls1046aqds/ls1046aqds.c | 2 +- > board/freescale/ls1046ardb/cpld.c | 2 +- > board/freescale
Re: [PATCH] imx53-qsb: Convert to watchdog driver model
From: Fabio Estevam
Sent: Thursday, February 22, 2024 1:39 AM
To: sba...@denx.de
Cc: Jason Liu ; u-boot@lists.denx.de
; Fabio Estevam
Subject: [PATCH] imx53-qsb: Convert to watchdog driver model
Commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()") caused
the 'reset' command in U-Boot to not cause a board reset.
Fix it by switching to the watchdog driver model via sysreset, which
is the preferred method for implementing the watchdog reset.
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx53-qsb-u-boot.dtsi | 14 ++
configs/mx53loco_defconfig | 3 +++
2 files changed, 17 insertions(+)
create mode 100644 arch/arm/dts/imx53-qsb-u-boot.dtsi
Thx for the fix.
Reviewed-by: Jason Liu
diff --git a/arch/arm/dts/imx53-qsb-u-boot.dtsi
b/arch/arm/dts/imx53-qsb-u-boot.dtsi
new file mode 100644
index ..593ab7caa635
--- /dev/null
+++ b/arch/arm/dts/imx53-qsb-u-boot.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/ {
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <&wdog1>;
+ bootph-pre-ram;
+ };
+};
+
+&wdog1 {
+ bootph-pre-ram;
+};
+
diff --git a/configs/mx53loco_defconfig b/configs/mx53loco_defconfig
index d4de8df7b49d..e2d3bc0b094e 100644
--- a/configs/mx53loco_defconfig
+++ b/configs/mx53loco_defconfig
@@ -60,6 +60,8 @@ CONFIG_POWER_FSL=y
CONFIG_POWER_I2C=y
CONFIG_DM_SERIAL=y
CONFIG_MXC_UART=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
CONFIG_USB=y
CONFIG_USB_EHCI_MX5=y
CONFIG_USB_STORAGE=y
@@ -67,3 +69,4 @@ CONFIG_USB_HOST_ETHER=y
CONFIG_USB_ETHER_ASIX=y
CONFIG_USB_ETHER_MCS7830=y
CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_IMX_WATCHDOG=y
--
2.34.1
Re: [PATCH] board: ti: am62x: Add variable device tree in env
On Mon, Jul 31, 2023 at 09:36:38AM -0500, Andrew Davis wrote:
> On 7/31/23 9:27 AM, Jason Kacines wrote:
> > Added variable default_device_tree that grabs from defconfig. Prevents
> > needing to change this variable in two locations if using a separate
> > device tree. In the future, it would be a good idea to remove this logic
> > completely, but this will help reduce complications.
> >
>
> If there are more than one possible DT for a given configuration, then
> we should have logic in `findfdt` to handle that. Not sure what having
> this set from kconfig will help in practice.
>
> Plus this kconfig is the DT bundled with SPL/U-Boot, but here you are using
> it to set the name of the DT to load for kernel (in theory these should have
> the same name but it still feels like a misuse).
This is a good point, not directly related to kconfig. Thank you. Ignore
this patch.
Jason
>
> How about we just skip to removing this logic as you suggest, set name_fdt
> directly and remove the `default_device_tree` env var.
>
> Andrew
>
> > Signed-off-by: Jason Kacines
> > ---
> > board/ti/am62x/am62x.env | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
> > index bb37d21de6..ee3d5a6b5f 100644
> > --- a/board/ti/am62x/am62x.env
> > +++ b/board/ti/am62x/am62x.env
> > @@ -1,7 +1,7 @@
> > #include
> > #include
> > -default_device_tree=ti/k3-am625-sk.dtb
> > +default_device_tree=CONFIG_DEFAULT_DEVICE_TREE.dtb
> > findfdt=
> > setenv name_fdt ${default_device_tree};
> > setenv fdtfile ${name_fdt}
[PATCH] board: ti: am62x: Add variable device tree in env
Added variable default_device_tree that grabs from defconfig. Prevents
needing to change this variable in two locations if using a separate
device tree. In the future, it would be a good idea to remove this logic
completely, but this will help reduce complications.
Signed-off-by: Jason Kacines
---
board/ti/am62x/am62x.env | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index bb37d21de6..ee3d5a6b5f 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -1,7 +1,7 @@
#include
#include
-default_device_tree=ti/k3-am625-sk.dtb
+default_device_tree=CONFIG_DEFAULT_DEVICE_TREE.dtb
findfdt=
setenv name_fdt ${default_device_tree};
setenv fdtfile ${name_fdt}
--
2.34.1
[PATCH] docs: boards: ti: add openocd spl debugging docs
Add documentation on how to use OpenOCD to debug U-Boot for TI K3
Generation boards.
Signed-off-by: Jason Kacines
---
doc/board/ti/am62x_openocd.rst | 248 +
doc/board/ti/k3.rst| 20 ++-
2 files changed, 265 insertions(+), 3 deletions(-)
create mode 100644 doc/board/ti/am62x_openocd.rst
diff --git a/doc/board/ti/am62x_openocd.rst b/doc/board/ti/am62x_openocd.rst
new file mode 100644
index 00..4e33bd6f58
--- /dev/null
+++ b/doc/board/ti/am62x_openocd.rst
@@ -0,0 +1,248 @@
+.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+.. sectionauthor:: Jason Kacines
+
+Debugging SPL in OpenOCD
+
+
+The following section demonstrates how to connect a board to OpenOCD and
+load the SPL symbols for debugging with a K3 generation device. For the
+guide below, users are expected to generate custom binaries, boot their
+board from an SD card and work with OpenOCD in a Linux environment. This
+guide uses the AM625-SK for device specific examples but can be extended
+to any K3 generation device.
+
+Step 1: Downloading OpenOCD
+---
+
+Download OpenOCD using the following command.
+
+.. code-block:: bash
+
+ sudo apt-get install openocd
+
+.. note::
+
+ OpenOCD version 0.12.0 is required to connect to the AM625-SK. Some
+ major GNU/Linux distros do not support version 0.12.0. Check the
+ version of OpenOCD with ``openocd -v``
+
+**For OpenOCD installations prior to version 0.12.0:**
+
+Clone the OpenOCD source code (https://openocd.org/).
+
+.. code-block:: bash
+
+ git clone https://git.code.sf.net/p/openocd/code openocd-code
+
+Move the required config files to the package installation of OpenOCD.
+
+.. code-block:: bash
+
+ cd {OpenOCD Source}
+ cp tcl/board/ti_am625evm.cfg /usr/local/share/openocd/scripts/board
+ cp tcl/target/ti_k3.cfg /usr/local/share/openocd/scripts/target
+
+Now you can move on to SK/EVM Setup to prepare your SK/EVM for debugging.
+
+Step 2: SK/EVM Setup
+
+
+Make the appropriate board cable connections.
+
+.. note::
+
+ Ensure that the BOOT MODE switches are set appropriately for an SD
+ Card boot (refer to the TRM for boot mode switch settings). For
+ AM62x devices, refer to :doc:`/board/ti/am62x_sk`.
+
+After connecting each of the cables from the figure above, run the
+following command to ensure that each connection is established.
+
+.. code-block:: bash
+
+ sudo dmesg | grep tty
+
+An output similar to the figure below should appear.
+
+::
+
+ [XX.XX] usb 1-5.3.2.2: FTDI USB Serial Device converter now
attached to ttyUSB0 <- Used for UART Flashing, UART boot, Linux Kernel,
U-Boot
+ [XX.XX] usb 1-5.3.2.2: FTDI USB Serial Device converter now
attached to ttyUSB1
+ [XX.XX] usb 1-5.3.2.2: FTDI USB Serial Device converter now
attached to ttyUSB2 <- Used for Console for DM R5F (WKUP R5F)
+ [XX.XX] usb 1-5.3.2.2: FTDI USB Serial Device converter now
attached to ttyUSB3 <- Used for Console on MCU M4F
+ [XX.XX] cdc_acm 1-5.3.1:1.0: ttyACM0: USB ACM device
+ [XX.XX] cdc_acm 1-5.3.1:1.3: ttyACM1: USB ACM device
+
+Open a serial connection with a baud rate of 115200 to view the kernel
+and U-Boot logs. Use the following command or a serial monitor of your
+choice.
+
+.. code-block:: bash
+
+ sudo picocom -b 115200 /dev/ttyUSB0
+
+Step 3: OpenOCD Debugging
+-
+
+Now that OpenOCD has been configured, launch an OpenOCD server with the
+following command.
+
+.. code-block:: bash
+
+ openocd -f board/ti_am625evm.cfg
+
+Below is an example of what the output of this command will print.
+
+::
+
+ Info : Listening on port for tcl connections
+ Info : Listening on port for telnet connections
+ Info : XDS110: connected
+ Info : XDS110: vid/pid = 0451/bef3
+ Info : XDS110: firmware version = 3.0.0.20
+ Info : XDS110: hardware version = 0x002f
+ Info : XDS110: connected to target via JTAG
+ Info : XDS110: TCK set to 2500 kHz
+ Info : clock speed 2500 kHz
+ Info : JTAG tap: am625.cpu tap/device found: 0x0bb7e02f (mfg: 0x017
(Texas Instruments), part: 0xbb7e, ver: 0x0)
+ Info : starting gdb server for am625.cpu.sysctrl on
+ Info : Listening on port for gdb connections
+ Info : starting gdb server for am625.cpu.a53.0 on 3334
+ Info : Listening on port 3334 for gdb connections
+ Info : starting gdb server for am625.cpu.a53.1 on 3335
+ Info : Listening on port 3335 for gdb connections
+ Info : starting gdb server for am625.cpu.a53.2 on 3336
+ Info : Listening on port 3336 for gdb connections
+ Info : starting gdb server for am625.cpu.a53.3 on 3337
+ Info : Listening on port 3337 for gdb co
[RFC PATCH 3/3] board: ti: am62x: Add am62x_evm defconfig fragments
Introduce am62x_evm defconfig fragments that will be used on top of the base wakeup defconfigs. The usage will be as follows: make <...> am62x_r5_defconfig am62x_evm_r5.config make <...> am62x_a53_defconfig am62x_evm_a53.config This will use the Makefile changes previously mentioned to access the .config fragments from /board/../ Also remove the original am62x_evm defconfigs now that fragments will be used to support to the board. Signed-off-by: Jason Kacines --- board/ti/am62x/am62x_evm_a53.config | 38 + board/ti/am62x/am62x_evm_r5.config | 51 +++ configs/am62x_evm_a53_defconfig | 104 --- configs/am62x_evm_r5_defconfig | 127 4 files changed, 89 insertions(+), 231 deletions(-) create mode 100644 board/ti/am62x/am62x_evm_a53.config create mode 100644 board/ti/am62x/am62x_evm_r5.config delete mode 100644 configs/am62x_evm_a53_defconfig delete mode 100644 configs/am62x_evm_r5_defconfig diff --git a/board/ti/am62x/am62x_evm_a53.config b/board/ti/am62x/am62x_evm_a53.config new file mode 100644 index 00..383bb4597a --- /dev/null +++ b/board/ti/am62x/am62x_evm_a53.config @@ -0,0 +1,38 @@ +# CONFIG_TI_SECURE_DEVICE is not set +CONFIG_SF_DEFAULT_SPEED=2500 +CONFIG_SPL_DM_SPI=y +CONFIG_DEFAULT_DEVICE_TREE="k3-am625-sk" +CONFIG_SPL_OF_LIST="k3-am625-sk" +CONFIG_OF_LIST="k3-am625-sk" +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI=y +CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y +CONFIG_SPL_DM_SPI_FLASH=y +# CONFIG_SPL_SPI_FLASH_TINY is not set +CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPL_SPI_LOAD=y +CONFIG_SYS_SPI_U_BOOT_OFFS=0x28 +CONFIG_SPL_YMODEM_SUPPORT=y +CONFIG_SYS_BOOTM_LEN=0x80 +CONFIG_CMD_PXE=y +CONFIG_CMD_DHCP=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_DMA_CHANNELS=y +CONFIG_TI_K3_NAVSS_UDMA=y +CONFIG_MMC_SDHCI_ADMA=y +CONFIG_SPL_MMC_SDHCI_ADMA=y +CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPI_FLASH_SOFT_RESET=y +CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_S28HX_T=y +CONFIG_NET=y +CONFIG_PHY_TI_DP83867=y +CONFIG_PHY_FIXED=y +CONFIG_TI_AM65_CPSW_NUSS=y +CONFIG_PHY=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_CADENCE_QSPI=y diff --git a/board/ti/am62x/am62x_evm_r5.config b/board/ti/am62x/am62x_evm_r5.config new file mode 100644 index 00..5dffab74f6 --- /dev/null +++ b/board/ti/am62x/am62x_evm_r5.config @@ -0,0 +1,51 @@ +# CONFIG_TI_SECURE_DEVICE is not set +CONFIG_SYS_MALLOC_LEN=0x0800 +CONFIG_SYS_MALLOC_F_LEN=0x9000 +CONFIG_NR_DRAM_BANKS=2 +CONFIG_SF_DEFAULT_SPEED=2500 +CONFIG_SF_DEFAULT_MODE=0 +CONFIG_ENV_SIZE=0x2 +CONFIG_GPIO=y +CONFIG_DM_GPIO=y +CONFIG_SPL_DM_SPI=y +CONFIG_DEFAULT_DEVICE_TREE="k3-am625-r5-sk" +CONFIG_SPL_DRIVERS_MISC=y +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI=y +CONFIG_I2C=y +CONFIG_INPUT=y +CONFIG_NET=y +CONFIG_BOOTDEV_ETH=y +CONFIG_SPL_DM_SPI_FLASH=y +CONFIG_SPL_RAM_SUPPORT=y +CONFIG_SPL_RAM_DEVICE=y +# CONFIG_SPL_SPI_FLASH_TINY is not set +CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPL_SPI_LOAD=y +CONFIG_SYS_SPI_U_BOOT_OFFS=0x8 +CONFIG_SPL_YMODEM_SUPPORT=y +CONFIG_CMD_ASKENV=y +CONFIG_CMD_DFU=y +CONFIG_SPL_MULTI_DTB_FIT=y +CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_DA8XX_GPIO=y +CONFIG_SPL_MISC=y +CONFIG_ESM_K3=y +CONFIG_MMC_SDHCI_ADMA=y +CONFIG_SPL_MMC_SDHCI_ADMA=y +CONFIG_DM_SPI=y +CONFIG_DM_SPI_FLASH=y +CONFIG_SPI=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPI_FLASH_SOFT_RESET=y +CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_S28HX_T=y +CONFIG_CADENCE_QSPI=y +CONFIG_PINCTRL=y +# CONFIG_PINCTRL_GENERIC is not set +CONFIG_SPL_PINCTRL=y +# CONFIG_SPL_PINCTRL_GENERIC is not set +CONFIG_PINCTRL_SINGLE=y diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig deleted file mode 100644 index 7c3bc184cf..00 --- a/configs/am62x_evm_a53_defconfig +++ /dev/null @@ -1,104 +0,0 @@ -CONFIG_ARM=y -CONFIG_ARCH_K3=y -CONFIG_TI_SECURE_DEVICE=y -CONFIG_SYS_MALLOC_F_LEN=0x8000 -CONFIG_SPL_LIBCOMMON_SUPPORT=y -CONFIG_SPL_LIBGENERIC_SUPPORT=y -CONFIG_NR_DRAM_BANKS=2 -CONFIG_SOC_K3_AM625=y -CONFIG_K3_ATF_LOAD_ADDR=0x9e78 -CONFIG_TARGET_AM625_A53_EVM=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b8 -CONFIG_SF_DEFAULT_SPEED=2500 -CONFIG_SPL_DM_SPI=y -CONFIG_DEFAULT_DEVICE_TREE="k3-am625-sk" -CONFIG_SPL_TEXT_BASE=0x8008 -CONFIG_OF_LIBFDT_OVERLAY=y -CONFIG_DM_RESET=y -CONFIG_SPL_MMC=y -CONFIG_SPL_SERIAL=y -CONFIG_SPL_STACK_R_ADDR=0x8200 -CONFIG_SPL_SIZE_LIMIT=0x4 -CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x800 -CONFIG_SPL_FS_FAT=y -CONFIG_SPL_LIBDISK_SUPPORT=y -CONFIG_SPL_SPI_FLASH_SUPPORT=y -CONFIG_SPL_SPI=y -# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set -CONFIG_SPL_LOAD_FIT=y -CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100 -CONFIG_DISTRO_DEFAULTS=y -CONFIG_BOOTCOMMA
[RFC PATCH 2/3] configs: Add am62x wakeup defconfigs
Introduce a minimal platform wakeup configuration for am62x devices.
These defconfigs are meant to serve as a foundation for custom boards to
build upon by only including necessary components to boot the device.
Defconfig fragments will be used to expand upon these base files.
Signed-off-by: Jason Kacines
---
configs/am62x_a53_defconfig | 78 ++
configs/am62x_r5_defconfig | 94 +
2 files changed, 172 insertions(+)
create mode 100644 configs/am62x_a53_defconfig
create mode 100644 configs/am62x_r5_defconfig
diff --git a/configs/am62x_a53_defconfig b/configs/am62x_a53_defconfig
new file mode 100644
index 00..baaa229b34
--- /dev/null
+++ b/configs/am62x_a53_defconfig
@@ -0,0 +1,78 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_SOC_K3_AM625=y
+CONFIG_K3_ATF_LOAD_ADDR=0x9e78
+CONFIG_TARGET_AM625_A53_EVM=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b8
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-sk"
+CONFIG_SPL_TEXT_BASE=0x8008
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_DM_RESET=y
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_SIZE_LIMIT=0x4
+CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x800
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+# CONFIG_CMD_PXE is not set
+# CONFIG_CMD_DHCP is not set
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern;
setenv fdtfile ti/${name_fdt}; run distro_bootcmd"
+CONFIG_SPL_MAX_SIZE=0x58000
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x80c8
+CONFIG_SPL_BSS_MAX_SIZE=0x8
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
+CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_CMD_MMC=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+# CONFIG_NET is not set
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_TI_SCI=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_AM654=y
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+# CONFIG_SPL_YMODEM_SUPPORT is not set
+CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_TI_K3_ARM64=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SOC_DEVICE=y
+CONFIG_SOC_DEVICE_TI_K3=y
+CONFIG_SOC_TI=y
+CONFIG_SYSRESET=y
+CONFIG_SPL_SYSRESET=y
+CONFIG_SYSRESET_TI_SCI=y
+CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
diff --git a/configs/am62x_r5_defconfig b/configs/am62x_r5_defconfig
new file mode 100644
index 00..64ae24bc90
--- /dev/null
+++ b/configs/am62x_r5_defconfig
@@ -0,0 +1,94 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SOC_K3_AM625=y
+CONFIG_TARGET_AM625_R5_EVM=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x43c3a7f0
+CONFIG_ENV_IS_NOWHERE=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-r5-sk"
+CONFIG_SPL_TEXT_BASE=0x43c0
+CONFIG_DM_RESET=y
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x7000
+CONFIG_SPL_SIZE_LIMIT=0x3A7F0
+CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x3500
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8008
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_LEGACY_IMAGE_FORMAT is not set
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
+CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
+CONFIG_SPL_MAX_SIZE=0x3B000
+CONFIG_SPL_PAD_TO=0x0
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x43c3b000
+CONFIG_SPL_BSS_MAX_SIZE=0x3000
+CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SYS_SPL_MALLOC=y
+CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y
+CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8400
+CONFIG_SYS_SPL_MALLOC_SIZE=0x100
+CONFIG_SPL_EARLY_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_REMOTEPROC=y
+# CONFIG_SPL_YMODEM_SUPPORT is not set
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_C
[RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../
Add support to config fragments (.config) located in the /board directory. This will allow only base defconfigs to live in /configs and all fragments to live in their respective device directory in /board/.. Signed-off-by: Jason Kacines --- scripts/kconfig/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile index 12e525ee31..2d97aab8d2 100644 --- a/scripts/kconfig/Makefile +++ b/scripts/kconfig/Makefile @@ -99,7 +99,9 @@ endif %_config: %_defconfig @: -configfiles=$(wildcard $(srctree)/kernel/configs/$@ $(srctree)/arch/$(SRCARCH)/configs/$@) +configfiles=$(wildcard $(srctree)/kernel/configs/$@ \ + $(srctree)/arch/$(SRCARCH)/configs/$@ \ + $(shell find $(srctree)/board -name "$@")) %.config: $(obj)/conf $(if $(call configfiles),, $(error No configuration exists for this target on this architecture)) -- 2.34.1
[RFC PATCH 0/3] Minimal platform configuration
When someone attempts to bring up a custom board using TI SoCs (am62x in
this case), it often takes several days for someone to reduce the
current configuration from the TI EVM/SK boards to a configuration that
works for their board.
The goal of these changes is to allow for a minimal boot configuration
to exist within UBoot that someone can access directly in order to
test their boards for a sign of life before beginning development. This
is all done with the hope to increase ease of use and reduce the
upbringing process from several days to a few hours.
With the use of fragments, the base defconfigs reside in configs/ and
the config fragments reside in board/../
There is still quite a lot of board specific code inside board_init_f()
that will need attention later, however this series begins the process
of splitting the am62x's configs into a separate generic defconfig
everyone can use for new board wakeups with individual board/ti/*.config
fragments for each board varient.
Jason Kacines (3):
scripts: kconfig: Add config fragment support in board/../
configs: Add am62x wakeup defconfigs
board: ti: am62x: Add am62x_evm defconfig fragments
board/ti/am62x/am62x_evm_a53.config | 38 +
board/ti/am62x/am62x_evm_r5.config| 51 ++
..._evm_a53_defconfig => am62x_a53_defconfig} | 34 ++--
...2x_evm_r5_defconfig => am62x_r5_defconfig} | 53 ---
scripts/kconfig/Makefile | 4 +-
5 files changed, 106 insertions(+), 74 deletions(-)
create mode 100644 board/ti/am62x/am62x_evm_a53.config
create mode 100644 board/ti/am62x/am62x_evm_r5.config
rename configs/{am62x_evm_a53_defconfig => am62x_a53_defconfig} (72%)
rename configs/{am62x_evm_r5_defconfig => am62x_r5_defconfig} (66%)
--
2.34.1
RE: [PATCH 00/13] x86: Various minor enhancements for coreboot
> -Original Message- > From: Simon Glass > Sent: 2023年2月21日 3:49 > To: U-Boot Mailing List > Cc: Bin Meng ; Simon Glass ; > AKASHI Takahiro ; Andrew Scull > ; Heinrich Schuchardt ; Ilias > Apalodimas ; Jason Liu ; > John Keeping ; Marek Vasut ; > Masahisa Kojima ; Michal Suchanek > ; Pali Rohár ; Pierre-Clément Tosi > ; Rasmus Villemoes ; > Stefan Roese > Subject: [PATCH 00/13] x86: Various minor enhancements for coreboot > > This series includes some patches generated while getting U-Boot to boot more > nicely on Brya, an Adler Lake Chromebook. > > This includes: > - show the ACPI tables with 'acpi list' > - get the UART to work even if coreboot doesn't enable it > - show unimplemented sysinfo tags > - fix for keyboard not working > - fix for trying to set up PCI regions when the info is not available > - fix for looking at inaccessible memory to find the sysinfo table > > > Simon Glass (13): > mtrr: Don't show an invalid CPU number > x86: Adjust search range for sysinfo table > input: Only reset the keyboard when running bare metal > x86: coreboot: Allow ACPI tables to be recorded > x86: coreboot: Collect the address of the ACPI tables > x86: Allow locating UARTs by device ID > pci: coreboot: Don't read regions when booting > usb: Quieten a debug message > x86: coreboot: Use a memory-mapped UART > x86: coreboot: Document how to enable the debug UART > x86: coreboot: Scan PCI after relocation > x86: coreboot: Log function names and line numbers > x86: coreboot: Show unimplemented sysinfo tags This patch-set looks fine to me, thus, Reviewed-by: Jason Liu > > arch/x86/cpu/cpu.c | 2 +- > arch/x86/dts/coreboot.dts | 4 ++ > arch/x86/include/asm/cb_sysinfo.h | 8 +++ > arch/x86/include/asm/coreboot_tables.h | 2 + > arch/x86/lib/coreboot/cb_sysinfo.c | 13 + > cmd/Kconfig| 3 +- > cmd/acpi.c | 4 ++ > cmd/x86/cbsysinfo.c| 9 > cmd/x86/mtrr.c | 3 +- > configs/coreboot_defconfig | 5 ++ > doc/board/coreboot/coreboot.rst| 29 +++ > drivers/input/i8042.c | 13 +++-- > drivers/pci/pci-uclass.c | 4 ++ > drivers/serial/serial_coreboot.c | 69 +++--- > drivers/usb/host/xhci.c| 4 +- > include/asm-generic/global_data.h | 4 +- > include/configs/coreboot.h | 2 + > include/pci_ids.h | 3 ++ > 18 files changed, 161 insertions(+), 20 deletions(-) > > -- > 2.39.2.637.g21b0678d19-goog smime.p7s Description: S/MIME cryptographic signature
RE: [PATCH v2 3/4] cmd: bdinfo: introduce bdinfo_print_size() helper
> -Original Message-
> From: Ovidiu Panait
> Sent: 2022年8月30日 1:02
> To: u-boot@lists.denx.de
> Cc: Ovidiu Panait ; Simon Glass ;
> Andy Shevchenko ; Dzmitry Sankouski
> ; Heinrich Schuchardt ; Jason
> Liu
> Subject: [PATCH v2 3/4] cmd: bdinfo: introduce bdinfo_print_size() helper
>
> Add bdinfo_print_size() helper to display size variables (such as cache
> sizes) in bdinfo format. The size is printed as "xxx Bytes", "xxx KiB",
"xxx MiB",
> "xxx GiB", etc as needed;
>
> Reviewed-by: Simon Glass
> Signed-off-by: Ovidiu Panait
> ---
>
> Changes in v2:
> Added "Reviewed-by" tag from Simon.
>
> cmd/bdinfo.c | 7 +++
> include/init.h | 13 +
> 2 files changed, 20 insertions(+)
>
The patch looks good to me.
Reviewed-by: Jason Liu
> diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c index 37cd8a57eb..9e23c4dd8f
> 100644
> --- a/cmd/bdinfo.c
> +++ b/cmd/bdinfo.c
> @@ -16,9 +16,16 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +void bdinfo_print_size(const char *name, uint64_t size) {
> + printf("%-12s= ", name);
> + print_size(size, "\n");
> +}
> +
> void bdinfo_print_num_l(const char *name, ulong value) {
> printf("%-12s= 0x%0*lx\n", name, 2 * (int)sizeof(value), value);
diff --git
> a/include/init.h b/include/init.h index 7b8f62c121..02bb4ce13e 100644
> --- a/include/init.h
> +++ b/include/init.h
> @@ -343,6 +343,19 @@ void bdinfo_print_num_ll(const char *name,
> unsigned long long value);
> /* Print a clock speed in MHz */
> void bdinfo_print_mhz(const char *name, unsigned long hz);
>
> +/**
> + * bdinfo_print_size - print size variables in bdinfo format
> + * @name:string to print before the size
> + * @size:size to print
> + *
> + * Helper function for displaying size variables as properly formatted
> +bdinfo
> + * entries. The size is printed as "xxx Bytes", "xxx KiB", "xxx MiB",
> + * "xxx GiB", etc. as needed;
> + *
> + * For use in arch_print_bdinfo().
> + */
> +void bdinfo_print_size(const char *name, uint64_t size);
> +
> /* Show arch-specific information for the 'bd' command */ void
> arch_print_bdinfo(void);
>
> --
> 2.25.1
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH 1/5] lib: crypto: add mscode_parser
On Tue, Jul 05, 2022 at 02:48:11PM +0900, AKASHI Takahiro wrote:
> + This option provides support for parsing MicroSoft's Authenticode
> + in pkcs7 message.
I chuckled when I saw "MicroSoft" in the cover letter, thinking it was a
wink, but here too... haha ummm. We could change it to "MikeRoweSoft"
instead in honor of the Belmont High School student. But... I think
"Microsoft" is what you're after here.
> + pr_devel("Data: %zu [%*ph]\n", data_len, (unsigned)(data_len),
> + content_data);
That's a weird cast around (data_len), but are you sure you want to keep
that print line in there?
Jason
RE: [PATCH 07/14] video: Drop references to CONFIG_VIDEO et al
> -Original Message-
> From: Simon Glass
> Sent: 2022年1月23日 22:04
> To: U-Boot Mailing List
> Cc: Anatolij Gustschin ; Jagan Teki
> ; Andre Przywara ;
> Simon Glass ; Andy Shevchenko
> ; Aswath Govindraju
> ; Aymen Sghaier ; Bin Meng
> ; Dario Binacchi ; Fabio Estevam
> ; Heiko Schocher ; Heinrich Schuchardt
> ; Jaehoon Chung ; Jason
> Liu ; Joel Peshkin ;
> Kory Maincent ; Marek Vasut
> ; Michal Simek ; dl-uboot-imx
> ; Ovidiu Panait ; Peng
> Fan ; Rasmus Villemoes ;
> samuel.e...@siemens.com; Stefan Bosch ; Stefan
> Roese ; Stefano Babic
> Subject: [PATCH 07/14] video: Drop references to CONFIG_VIDEO et al
>
> Drop the Kconfigs which are not used and all references to them. In
particular,
> this drops CONFIG_VIDEO to avoid confusion and allow us to eventually
> rename CONFIG_DM_VIDEO to CONFIG_VIDEO.
>
> Also drop the prototype for video_get_info_str() which is no-longer used.
>
> Signed-off-by: Simon Glass
> ---
>
> README| 3 -
> arch/arm/include/asm/mach-imx/mx5_video.h | 5 --
> .../mach-nexell/include/mach/display_dev.h| 2 +-
> board/freescale/mx51evk/Makefile | 1 -
> board/freescale/mx53loco/Makefile | 1 -
> board/kosagi/novena/novena_spl.c | 23
> cmd/Kconfig | 2 +-
> cmd/bdinfo.c | 2 +-
> cmd/bmp.c | 4 +-
> common/fdt_support.c | 2 +-
> common/stdio.c| 3 +-
> drivers/video/Kconfig | 56 +--
> drivers/video/nexell_display.c| 3 +-
> include/asm-generic/global_data.h | 2 +-
> include/configs/pxm2.h| 7 ---
> include/configs/rut.h | 9 ---
> lib/efi_loader/Kconfig| 1 -
> 17 files changed, 10 insertions(+), 116 deletions(-)
For the imx51/53 board.
Acked-by: Jason Liu
>
> diff --git a/README b/README
> index 816d9c4dfb2..40ef21df3b5 100644
> --- a/README
> +++ b/README
> @@ -1013,9 +1013,6 @@ The following options need to be configured:
> support, and should also define these other macros:
>
> CONFIG_SYS_DIU_ADDR
> - CONFIG_VIDEO
> - CONFIG_VIDEO_SW_CURSOR
> - CONFIG_VGA_AS_SINGLE_DEVICE
>
> The DIU driver will look for the 'video-mode' environment
> variable, and if defined, enable the DIU as a console during
diff --git
> a/arch/arm/include/asm/mach-imx/mx5_video.h
> b/arch/arm/include/asm/mach-imx/mx5_video.h
> index dc6aa00c894..b55c0fe8971 100644
> --- a/arch/arm/include/asm/mach-imx/mx5_video.h
> +++ b/arch/arm/include/asm/mach-imx/mx5_video.h
> @@ -6,12 +6,7 @@
> #ifndef __MX5_VIDEO_H
> #define __MX5_VIDEO_H
>
> -#ifdef CONFIG_VIDEO
> -void lcd_enable(void);
> -void setup_iomux_lcd(void);
> -#else
> static inline void lcd_enable(void) { } static inline void
setup_iomux_lcd(void)
> { } -#endif
>
> #endif
> diff --git a/arch/arm/mach-nexell/include/mach/display_dev.h
> b/arch/arm/mach-nexell/include/mach/display_dev.h
> index ffa45518d99..39b28ca1299 100644
> --- a/arch/arm/mach-nexell/include/mach/display_dev.h
> +++ b/arch/arm/mach-nexell/include/mach/display_dev.h
> @@ -8,7 +8,7 @@
> #ifndef _NX__DISPLAY_DEV_H_
> #define _NX__DISPLAY_DEV_H_
>
> -#if defined CONFIG_VIDEO || defined CONFIG_DM_VIDEO
> +#if defined CONFIG_DM_VIDEO
> #elif defined CONFIG_LCD
> #include
> #endif
> diff --git a/board/freescale/mx51evk/Makefile
> b/board/freescale/mx51evk/Makefile
> index 1a9581cabf9..808e35015e8 100644
> --- a/board/freescale/mx51evk/Makefile
> +++ b/board/freescale/mx51evk/Makefile
> @@ -5,4 +5,3 @@
> # (C) Copyright 2009 Freescale Semiconductor, Inc.
>
> obj-y+= mx51evk.o
> -obj-$(CONFIG_VIDEO) += mx51evk_video.o
> diff --git a/board/freescale/mx53loco/Makefile
> b/board/freescale/mx53loco/Makefile
> index d2ebd94dca1..9befe426957 100644
> --- a/board/freescale/mx53loco/Makefile
> +++ b/board/freescale/mx53loco/Makefile
> @@ -4,4 +4,3 @@
> # Jason Liu
>
> obj-y+= mx53loco.o
> -obj-$(CONFIG_VIDEO) += mx53loco_video.o
> diff --git a/board/kosagi/novena/novena_spl.c
> b/board/kosagi/novena/novena_spl.c
> index 3d22f2019e9..24c0fb22268 100644
> --- a/board/kosagi/novena/novena_spl.c
> +++ b/board/kosagi/novena/novena_spl.c
> @@ -379,30 +379,7 @@ static void novena_spl_setup_iomux_uart(void)
> imx_iom
RE: [RFC PATCH 04/10] FWU: Add metadata access functions for GPT partitioned block devices
> -Original Message-
> From: Sughosh Ganu
> Sent: 2021年11月25日 15:02
> To: u-boot@lists.denx.de
> Cc: Patrick Delaunay ; Patrice Chotard
> ; Heinrich Schuchardt ;
> Alexander Graf ; Simon Glass ; Bin
> Meng ; Peng Fan ; AKASHI
> Takahiro ; Ilias Apalodimas
> ; Jose Marinho ; Grant
> Likely ; Jason Liu ; Sughosh
> Ganu
> Subject: [RFC PATCH 04/10] FWU: Add metadata access functions for GPT
> partitioned block devices
>
> In the FWU Multi Bank Update feature, the information about the updatable
> images is stored as part of the metadata, on a separate partition. Add
> functions for reading from and writing to the metadata when the updatable
> images and the metadata are stored on a block device which is formated
with
> GPT based partition scheme.
>
> Signed-off-by: Sughosh Ganu
> ---
> lib/fwu_updates/fwu_metadata_gpt_blk.c | 716
> +
> 1 file changed, 716 insertions(+)
> create mode 100644 lib/fwu_updates/fwu_metadata_gpt_blk.c
>
> diff --git a/lib/fwu_updates/fwu_metadata_gpt_blk.c
> b/lib/fwu_updates/fwu_metadata_gpt_blk.c
> new file mode 100644
> index 00..98cc53f706
> --- /dev/null
> +++ b/lib/fwu_updates/fwu_metadata_gpt_blk.c
> @@ -0,0 +1,716 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2021, Linaro Limited
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#define PRIMARY_VALID0x1
> +#define SECONDARY_VALID 0x2
> +
> +#define MDATA_READ (u8)0x1
> +#define MDATA_WRITE (u8)0x2
> +
> +#define IMAGE_ACCEPT_SET (u8)0x1
> +#define IMAGE_ACCEPT_CLEAR (u8)0x2
Better to define as the followings:
#define MDATA_READ ((u8)0x1)
#define MDATA_WRITE ((u8)0x2)
#define IMAGE_ACCEPT_SET((u8)0x1)
#define IMAGE_ACCEPT_CLEAR ((u8)0x2)
> +
> +static int gpt_verify_metadata(struct fwu_metadata *metadata, bool
> +pri_part) {
> + u32 calc_crc32;
> + void *buf;
> +
> + buf = &metadata->version;
> + calc_crc32 = crc32(0, buf, sizeof(*metadata) - sizeof(u32));
> +
> + if (calc_crc32 != metadata->crc32) {
> + log_err("crc32 check failed for %s metadata partition\n",
> + pri_part ? "primary" : "secondary");
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +static int gpt_get_metadata_partitions(struct blk_desc *desc,
> +u32 *primary_mpart,
> +u32 *secondary_mpart)
> +{
> + int i, ret;
> + u32 nparts, mparts;
> + gpt_entry *gpt_pte = NULL;
> + const efi_guid_t fwu_metadata_guid = FWU_METADATA_GUID;
> +
> + ALLOC_CACHE_ALIGN_BUFFER_PAD(gpt_header, gpt_head, 1,
> + desc->blksz);
> +
> + ret = get_gpt_hdr_parts(desc, gpt_head, &gpt_pte);
> + if (ret < 0) {
> + log_err("Error getting GPT header and partitions\n");
> + ret = -EIO;
> + goto out;
> + }
> +
> + nparts = gpt_head->num_partition_entries;
> + for (i = 0, mparts = 0; i < nparts; i++) {
> + if (!guidcmp(&fwu_metadata_guid,
> + &gpt_pte[i].partition_type_guid)) {
> + ++mparts;
> + if (!*primary_mpart)
> + *primary_mpart = i + 1;
> + else
> + *secondary_mpart = i + 1;
> + }
> + }
> +
> + if (mparts != 2) {
> + log_err("Expect two copies of the metadata instead of %d\n",
> + mparts);
> + ret = -EINVAL;
> + } else {
> + ret = 0;
> + }
> +out:
> + free(gpt_pte);
> +
> + return ret;
> +}
> +
> +static int gpt_get_metadata_disk_part(struct blk_desc *desc,
> + struct disk_partition *info,
> + u32 part_num)
> +{
> + int ret;
> + char *metadata_guid_str = "8a7a84a0-8387-40f6-ab41-a8b9a5a60d23";
Is this hard-code guid_string intentioned?
> +
> + ret = part_get_info(desc, part_num, info);
Jason Liu
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] rockchip: rk3328: fix booting error for nanopi-r2s
Sorry to resend this, I forget to re-subscribe mail list.
The 'sdmmc0m1_gpio' is defined, more see last email.
Thanks,
- Jason
Jason Lee 于2021年8月12日周四 上午9:57写道：
>
> The 'sdmmc0m1_gpio' is defined in arch/arm/dts/rk3328.dtsi, which is
> included at the beginning of rk3328-nanopi-r2s.dts.
>
> The node is :
> sdmmc0-1 {
> sdmmc0m1_pwren: sdmmc0m1-pwren {
> rockchip,pins = <0 RK_PD6 3 &pcfg_pull_up_4ma>;
> };
>
> sdmmc0m1_gpio: sdmmc0m1-gpio {
> rockchip,pins = <0 RK_PD6 RK_FUNC_GPIO &pcfg_pull_up_4ma>;
> };
> };
>
>
> Thanks,
>
> -Jason
>
> Kever Yang 于2021年8月12日周四 上午8:56写道：
> >
> >
> > On 2021/8/11 下午6:05, Kever Yang wrote:
> > > Adam Lee 于2021年7月6日周二 下午10:42写道：
> > >> From 29cf326e24b657180e4cf90ded2366d49f33e88e Mon Sep 17 00:00:00 2001
> > >> From: jason416
> > >> Date: Mon, 5 Jul 2021 23:22:29 +0800
> > >> Subject: [PATCH] rockchip: rk3328: fix booting error for nanopi-r2s
> > >>
> > >> devices can not boot properly during SPL stage by
> > >> using microSD card which model is SDSQUNC-032G-ZN6MA.
> > >>
> > >> U-Boot SPL 2021.04 (Jul 02 2021 - 19:50:12 +)
> > >> Trying to boot from MMC1
> > >> mmc_load_image_raw_sector: mmc block read error
> > >> SPL: failed to boot from all boot devices
> > >>
> > >> change dts and config to support booting from ultra
> > >> high speed microSD card on nanopi-r2s.
> > >>
> > >> Signed-off-by: jason416
> > > Reviewed-by: Kever Yang
> > >
> > > Thanks,
> > > - Kever
> > >> ---
> > >> arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi | 4
> > >> arch/arm/dts/rk3328-nanopi-r2s.dts | 2 +-
> > >> configs/nanopi-r2s-rk3328_defconfig| 4
> > >> 3 files changed, 9 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi b/arch/arm/dts
> > >> /rk3328-nanopi-r2s-u-boot.dtsi
> > >> index 9e2ced1541..d5469748a2 100644
> > >> --- a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
> > >> +++ b/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
> > >> @@ -33,6 +33,10 @@
> > >>u-boot,dm-spl;
> > >> };
> > >>
> > >> +&vcc_io_sdio {
> > >> + u-boot,dm-spl;
> > >> +};
> > >> +
> > >> &gmac2io {
> > >>snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
> > >>snps,reset-active-low;
> > >> diff --git a/arch/arm/dts/rk3328-nanopi-r2s.dts
> > >> b/arch/arm/dts/rk3328-nanopi
> > >> -r2s.dts
> > >> index 5445c5cb3d..452e4764e6 100644
> > >> --- a/arch/arm/dts/rk3328-nanopi-r2s.dts
> > >> +++ b/arch/arm/dts/rk3328-nanopi-r2s.dts
> > >> @@ -323,7 +323,7 @@
> > >>bus-width = <4>;
> > >>cap-sd-highspeed;
> > >>disable-wp;
> > >> - pinctrl-0 = <&sdmmc0_clk>, <&sdmmc0_cmd>, <&sdmmc0_dectn>,
> > >> <&sdmmc0_bus4>;
> > >> + pinctrl-0 = <&sdmmc0_clk>, <&sdmmc0_cmd>, <&sdmmc0_dectn>,
> > >> <&sdmmc0_bus4>, <&sdmmc0m1_gpio>;
> >
> > The 'sdmmc0m1_gpio' is not defined.
> >
> >
> > Thanks,
> >
> > - Kever
> >
> > >>pinctrl-names = "default";
> > >>sd-uhs-sdr12;
> > >>sd-uhs-sdr25;
> > >> diff --git a/configs/nanopi-r2s-rk3328_defconfig b/configs/nanopi
> > >> -r2s-rk3328_defconfig
> > >> index 52996266a1..a7969bd7ab 100644
> > >> --- a/configs/nanopi-r2s-rk3328_defconfig
> > >> +++ b/configs/nanopi-r2s-rk3328_defconfig
> > >> @@ -56,6 +56,10 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
> > >> CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
> > >> CONFIG_ROCKCHIP_GPIO=y
> > >> CONFIG_SYS_I2C_ROCKCHIP=y
> > >> +CONFIG_MMC_IO_VOLTAGE=y
> > >> +CONFIG_SPL_MMC_IO_VOLTAGE=y
> > >> +CONFIG_MMC_UHS_SUPPORT=y
> > >> +CONFIG_SPL_MMC_UHS_SUPPORT=y
> > >> CONFIG_MMC_DW=y
> > >> CONFIG_MMC_DW_ROCKCHIP=y
> > >> CONFIG_SF_DEFAULT_SPEED=2000
> > >> --
> > >> 2.17.1
> > >
> >
> >
[PATCH v2 2/4] xhci.c: Add polling support for USB keyboards
The xhci driver was causing intermittent 5 second delays from the USB
keyboard polling hook. Executing something like a "sleep 1" for
example would sleep for 5 seconds, unless an event occurred on
the USB bus to shorten the delay.
Modeled after the code in the DWC2 driver, a nonblock state was added
to quickly return instead of blocking for up to 5 seconds waiting for
an event before timing out.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 26 +-
drivers/usb/host/xhci.c | 11 ++-
include/usb/xhci.h | 5 +++--
3 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 092ed6eaf1..607d4f715e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -432,9 +432,11 @@ static int event_ready(struct xhci_ctrl *ctrl)
*
* @param ctrl Host controller data structure
* @param expected TRB type expected from Event TRB
+ * @param nonblock when true do not block waiting for response
* @return pointer to event trb
*/
-union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected)
+union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected,
+ bool nonblock)
{
trb_type type;
unsigned long ts = get_timer(0);
@@ -442,8 +444,11 @@ union xhci_trb *xhci_wait_for_event(struct xhci_ctrl
*ctrl, trb_type expected)
do {
union xhci_trb *event = ctrl->event_ring->dequeue;
- if (!event_ready(ctrl))
+ if (!event_ready(ctrl)) {
+ if (nonblock)
+ return NULL;
continue;
+ }
type = TRB_FIELD_TO_TYPE(le32_to_cpu(event->event_cmd.flags));
if (type == expected)
@@ -493,7 +498,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
field = le32_to_cpu(event->trans_event.flags);
BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
@@ -501,7 +506,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
!= COMP_STOP)));
xhci_acknowledge_event(ctrl);
- event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
+ event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
!= udev->slot_id || GET_COMP_CODE(le32_to_cpu(
event->event_cmd.status)) != COMP_SUCCESS);
@@ -509,7 +514,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
xhci_queue_command(ctrl, (void *)((uintptr_t)ring->enqueue |
ring->cycle_state), udev->slot_id, ep_index, TRB_SET_DEQ);
- event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
+ event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
!= udev->slot_id || GET_COMP_CODE(le32_to_cpu(
event->event_cmd.status)) != COMP_SUCCESS);
@@ -552,10 +557,11 @@ static void record_transfer_result(struct usb_device
*udev,
* @param pipe contains the DIR_IN or OUT , devnum
* @param length length of the buffer
* @param buffer buffer to be read/written based on the request
+ * @param nonblock when true do not block waiting for response
* @return returns 0 if successful else -1 on failure
*/
int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
- int length, void *buffer)
+ int length, void *buffer, bool nonblock)
{
int num_trbs = 0;
struct xhci_generic_trb *start_trb;
@@ -714,8 +720,10 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, nonblock);
if (!event) {
+ if (nonblock)
+ return -EINVAL;
debug("XHCI bulk transfer timed out, aborting...\n");
abort_td(udev, ep_index);
udev->status = USB_ST_NAK_REC; /* closest thing to a timeout */
@@ -911,7 +919,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
if (!event)
goto abort;
field = le32_to_cpu(event->tra
[PATCH v2 3/4] xhci-ring.c: Add poll pending state to properly abort transactions
Both xhci_ctrl_tx() and xhci_bulk_tx() can be called synchronously by
other drivers such as the usb storage or network, while the keyboard
driver exclusively uses the polling mode.
The reason the abort needs to happen is for the case when a keyboard
poll was issue but there was no response packet. If another driver
such as the usb mass storage is called, it could receive the response
from the keyboard because only a single TRB queue is used.
Any pending polling transactions must be aborted before switching
modes to avoid corrupting the state of the controller and the driver
which expects a series of commands and responses from a specific
device.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 80
include/usb/xhci.h | 5 +++
2 files changed, 69 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 607d4f715e..00a0491771 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -549,19 +549,8 @@ static void record_transfer_result(struct usb_device *udev,
}
}
-/ Bulk and Control transfer methods /
-/**
- * Queues up the BULK Request
- *
- * @param udev pointer to the USB device structure
- * @param pipe contains the DIR_IN or OUT , devnum
- * @param length length of the buffer
- * @param buffer buffer to be read/written based on the request
- * @param nonblock when true do not block waiting for response
- * @return returns 0 if successful else -1 on failure
- */
-int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
- int length, void *buffer, bool nonblock)
+static int _xhci_bulk_tx_queue(struct usb_device *udev, unsigned long pipe,
+ int length, void *buffer)
{
int num_trbs = 0;
struct xhci_generic_trb *start_trb;
@@ -575,7 +564,6 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
struct xhci_virt_device *virt_dev;
struct xhci_ep_ctx *ep_ctx;
struct xhci_ring *ring; /* EP transfer ring */
- union xhci_trb *event;
int running_total, trb_buff_len;
unsigned int total_packet_count;
@@ -719,20 +707,73 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
} while (running_total < length);
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
+ return 0;
+}
+
+/ Bulk and Control transfer methods /
+/**
+ * Queues up the BULK Request
+ *
+ * @param udev pointer to the USB device structure
+ * @param pipe contains the DIR_IN or OUT , devnum
+ * @param length length of the buffer
+ * @param buffer buffer to be read/written based on the request
+ * @param nonblock when true do not block waiting for response
+ * @return returns 0 if successful else -1 on failure
+ */
+int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
+int length, void *buffer, bool nonblock)
+{
+ u32 field;
+ int ret;
+ union xhci_trb *event;
+ struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
+ int ep_index = usb_pipe_ep_index(pipe);
+ if (ctrl->poll_pend) {
+ /*
+* Abort a pending poll operation if it should have
+* timed out, or if this is a different buffer from a
+* separate request
+*/
+ if (get_timer(ctrl->bulk_tx_poll_ts) > XHCI_TIMEOUT ||
+ ctrl->last_bulk_tx_buf != buffer || ctrl->poll_last_udev !=
udev ||
+ ep_index != ctrl->poll_last_ep_index) {
+ abort_td(ctrl->poll_last_udev,
ctrl->poll_last_ep_index);
+ ctrl->poll_last_udev->status = USB_ST_NAK_REC; /*
closest thing to a timeout */
+ ctrl->poll_last_udev->act_len = 0;
+ ctrl->poll_pend = false;
+ }
+ } /* No else here because poll_pend might have changed above */
+ if (!ctrl->poll_pend) {
+ ctrl->last_bulk_tx_buf = buffer;
+ ret = _xhci_bulk_tx_queue(udev, pipe, length, buffer);
+ if (ret)
+ return ret;
+ }
event = xhci_wait_for_event(ctrl, TRB_TRANSFER, nonblock);
if (!event) {
- if (nonblock)
+ if (nonblock) {
+ if (!ctrl->poll_pend) {
+ /* Start the timer */
+ ctrl->bulk_tx_poll_ts = get_timer(0);
+ ctrl->poll_last_udev = udev;
+ ctrl->poll_last_ep_index = ep_index;
+ ctrl->poll_pend = true;
+ }
return -EINVAL;
+ }
debug("XHCI bulk transfer
[PATCH 0/4][v2] xhci fixes for rpi4
This is the second iteration of the xhci patch set for making USB keyboards usable on the rpi4 board. Patch 1 is new to deal with the USB device not responding immediately after a port reset. Patch 3 is refactored after the review from Bin Meng. Jason Wessel (4): xhci.c: Add retry in xhci_address_device() xhci.c: Add polling support for USB keyboards xhci-ring.c: Add poll pending state to properly abort transactions xhci-ring.c: Fix crash when issuing "usb reset" drivers/usb/host/xhci-ring.c | 115 +-- drivers/usb/host/xhci.c | 20 ++-- include/usb/xhci.h | 10 +++- 3 files changed, 111 insertions(+), 34 deletions(-)
[PATCH v2 1/4] xhci.c: Add retry in xhci_address_device()
After a port reset some usb keyboard devices do not respond
immediately, and instead the controller reports COMP_TX_ERR. Adding a
retry after the first TX error is returned resolves the issue.
Without the patch u-boot prints:
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... Device not responding to set address.
USB device not accepting new address (error=8000)
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 126dabc11b..9a31eba2bb 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -675,6 +675,7 @@ static int xhci_address_device(struct usb_device *udev, int
root_portnr)
struct xhci_virt_device *virt_dev;
int slot_id = udev->slot_id;
union xhci_trb *event;
+ int retry_cnt = 0;
virt_dev = ctrl->devs[slot_id];
@@ -685,6 +686,7 @@ static int xhci_address_device(struct usb_device *udev, int
root_portnr)
debug("Setting up addressable devices %p\n", ctrl->dcbaa);
xhci_setup_addressable_virt_dev(ctrl, udev, root_portnr);
+retry:
ctrl_ctx = xhci_get_input_control_ctx(virt_dev->in_ctx);
ctrl_ctx->add_flags = cpu_to_le32(SLOT_FLAG | EP0_FLAG);
ctrl_ctx->drop_flags = 0;
@@ -701,6 +703,13 @@ static int xhci_address_device(struct usb_device *udev,
int root_portnr)
ret = -EINVAL;
break;
case COMP_TX_ERR:
+ retry_cnt++;
+ if (retry_cnt < 2) {
+ /* Retry in case this was just after a port reset */
+ debug("COMP_TX_ERR retry\n");
+ xhci_acknowledge_event(ctrl);
+ goto retry;
+ }
puts("Device not responding to set address.\n");
ret = -EPROTO;
break;
--
2.17.1
[PATCH v2 4/4] xhci-ring.c: Fix crash when issuing "usb reset"
When TRB_TRANSFER is set for a call to xhci_wait_for_event, it can
return null, which causes u-boot to crash. This is an intermittent
problem found during "usb reset" testing.
If the null return occurs it means there was a timeout, and the
abort_td() should return immediately vs crashing u-boot from a null
dereference.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 00a0491771..bbb4410908 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -499,11 +499,16 @@ static void abort_td(struct usb_device *udev, int
ep_index)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
- field = le32_to_cpu(event->trans_event.flags);
- BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
- BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
- BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len
- != COMP_STOP)));
+ if (event) {
+ field = le32_to_cpu(event->trans_event.flags);
+ BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
+ BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
+ BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len
+!= COMP_STOP)));
+ } else {
+ debug("XHCI abort timeout\n");
+ return;
+ }
xhci_acknowledge_event(ctrl);
event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
--
2.17.1
Re: [PATCH 5/9] xhci-ring.c: Add the poll_pend state to properly abort transactions
On 8/20/20 3:26 AM, Bin Meng wrote:
> Hi Jason,
>
> On Sat, Jul 25, 2020 at 5:51 AM Jason Wessel
> wrote:
>>
>> xhci_trl_tx and xhchi_bulk_tx can be called synchronously by other
>> drivers such as the usb storage or network, while the keyboard driver
>> exclusively uses the polling mode.
>>
>
> Could you provide more details as to when this will fail?
An example is when the keyboard poll happens just before loading an
a kernel image from the USB device. The poll sets up the TRB to listen
but the packet may arrive when a keyboard event occurs, and the
existing drivers will crash when the keyboard event is received
instead of the request it has issued synchronously.
It didn't seem to happen too often, but extended testing discovered
the problem.
>
>> And pending polling transactions must be aborted before switching
>> modes to avoid corrupting the state of the controller.
>>
>> Signed-off-by: Jason Wessel
>> ---
>> drivers/usb/host/xhci-ring.c | 86 +---
>> 1 file changed, 70 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
>> index b7b2e16410..d6339f4f0a 100644
>> --- a/drivers/usb/host/xhci-ring.c
>> +++ b/drivers/usb/host/xhci-ring.c
>> @@ -24,6 +24,12 @@
>>
>> #include
>>
>> +static void *last_bulk_tx_buf;
>> +static struct usb_device *poll_last_udev;
>> +int poll_last_ep_index;
>> +static unsigned long bulk_tx_poll_ts;
>> +static bool poll_pend;
>
> Should these variables go into struct xhci_ctrl? What happens if 2
> controllers are sending data?
>
I would say you are correct. Because the board I was using only
had a single controller, the issue is only fixed for the single controller
case.
I can re-work the patches to account for the problem.
Jason.
>> +
>> /**
>> * Is this TRB a link TRB or was the last TRB the last TRB in this event
>> ring
>> * segment? I.e. would the updated event TRB pointer step off the end of
>> the
>> @@ -549,19 +555,8 @@ static void record_transfer_result(struct usb_device
>> *udev,
>> }
>> }
>>
>> -/ Bulk and Control transfer methods /
>> -/**
>> - * Queues up the BULK Request
>> - *
>> - * @param udev pointer to the USB device structure
>> - * @param pipe contains the DIR_IN or OUT , devnum
>> - * @param length length of the buffer
>> - * @param buffer buffer to be read/written based on the request
>> - * @param nonblock when true do not block waiting for response
>> - * @return returns 0 if successful else -1 on failure
>> - */
>> -int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
>> - int length, void *buffer, bool nonblock)
>> +static int _xhci_bulk_tx_queue(struct usb_device *udev, unsigned long pipe,
>> + int length, void *buffer)
>> {
>> int num_trbs = 0;
>> struct xhci_generic_trb *start_trb;
>> @@ -575,7 +570,6 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
>> pipe,
>> struct xhci_virt_device *virt_dev;
>> struct xhci_ep_ctx *ep_ctx;
>> struct xhci_ring *ring; /* EP transfer ring */
>> - union xhci_trb *event;
>>
>> int running_total, trb_buff_len;
>> unsigned int total_packet_count;
>> @@ -719,20 +713,73 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned
>> long pipe,
>> } while (running_total < length);
>>
>> giveback_first_trb(udev, ep_index, start_cycle, start_trb);
>> + return 0;
>> +}
>>
>> +/ Bulk and Control transfer methods /
>> +/**
>> + * Queues up the BULK Request
>> + *
>> + * @param udev pointer to the USB device structure
>> + * @param pipe contains the DIR_IN or OUT , devnum
>> + * @param length length of the buffer
>> + * @param buffer buffer to be read/written based on the request
>> + * @param nonblock when true do not block waiting for response
>> + * @return returns 0 if successful else -1 on failure
>> + */
>> +int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
>> +int length, void *buffer, bool nonblock)
>> +{
>> + u32 field;
>> + int ret;
>> + union xhci_trb *event;
>> + struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
>> + int ep_index = usb_pipe_ep_index(pipe);
>> +
>> + if (poll_pend) {
>>
[PATCH 0/2][v2] Raspberry pi improvements usb core
The original patches have been refactored. It turns out that one of the problems was a dwc2 specific with a stall after a port reset. This means the generic retry code was dropped. The xhci had a similar problem with a retry required for COMP_TX_ERR, and will be sent to the xhci maintainer. The new patches allow for a wider variety of usb keyboards to be used with u-boot. Jason Wessel (2): usb_kbd: Remove the initial interrupt request dwc2: Retry when a usb_stall occurs. common/usb_kbd.c| 10 +- drivers/usb/host/dwc2.c | 3 +++ 2 files changed, 8 insertions(+), 5 deletions(-)
Re: [RESEND][PATCH 1/3] usb_kbd: succeed even if no interrupt is pending
On 8/18/20 12:20 PM, Marek Vasut wrote: > On 8/18/20 6:54 PM, Jason Wessel wrote: >> >> >> On 8/18/20 10:05 AM, Marek Vasut wrote: >>> On 8/18/20 4:34 PM, Jason Wessel wrote: >>>> After the initial configuration some USB keyboard+mouse devices never >>>> return any kind of event on the interrupt line. In particular, the >>>> device identified by "Cypress Cypress USB Keyboard / PS2 Mouse as >>>> 3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:04B4:0101.0001/input/input0" >>>> never returns a data packet until the first external input event. >>>> >>>> I found this was also true with some newer model Dell keyboards. >>>> >>>> When the device is plugged into a xhci controller there is also no >>>> point in waiting 5 seconds for a device that is never going to present >>>> data, so the call to the interrupt service was changed to a >>>> nonblocking operation for the controllers that support this. >>>> >>>> With the patch applied, the rpi3 and rpi4 work well with the more >>>> complex keyboard devices. >>> >>> Please extend the comment in the code, it is not clear from it or from >>> the commit message what the problem really is that this patch tries to fix. >>> >>> Also, the printf() below the return 1 is never reached. >>> >> >> >> The printf() is only reached in the case of the #ifdef above it being true. > > That's pretty awful and confusing code then. The original code wasn't > stellar either, but can this be somehow improved now ? > >> The compiler in theory should optimize it away, but for clarity it can be >> moved >> with in the #ifdef but that also requires fixing it in two places because >> there are multiple levels to the #ifdef. > > I think it's better to make it more readable if possible. > >> Would the following be acceptable, which I can put in the next version. >> >> >> commit 319c75ee3d1fce8a3389d1de857751504b5110cb (HEAD -> master) >> Author: Jason Wessel >> Date: Thu Jun 25 05:31:25 2020 -0700 >> >> usb_kbd: succeed even if no interrupt is pending >> >> After the initial configuration some USB keyboard+mouse devices never >> return any kind of event on the interrupt line. In particular, the >> device identified by "Cypress Cypress USB Keyboard / PS2 Mouse as >> 3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:04B4:0101.0001/input/input0" >> never returns a data packet until the first external input event. >> >> I found this was also true with some newer model Dell keyboards. >> >> Without the patch u-boot prints the following on one of keyboards and >> leave it unable to accept input events. >> >> = >> scanning bus xhci_pci for devices... >> Failed to get keyboard state from device 14dd:1009 > > So I have to wonder, if the keyboard never returns a data packet until > you press a key (that makes sense), how does Linux deal with this ? > As far as I can tell the usb_kbd_probe() probe function in the Linux kernel sets up the configuration and exits right away. The keyboard drivers state was zeroed out in the probe function and the kernel later processes callbacks from the interrupt handler. Does that imply the other 2 code paths should also just return 1 and we get rid of the printf() entirely? I don't have any boards that wanted either of these two paths through code, so I wasn't inclined to change it. Jason.
Re: [RESEND][PATCH 2/3] common/usb.c: Work around keyboard reporting "USB device not accepting new address"
On 8/18/20 10:08 AM, Marek Vasut wrote:
> On 8/18/20 4:34 PM, Jason Wessel wrote:
>> When resetting the rpi3 board sometimes it will display:
>> USB device not accepting new address (error=0)
>>
>> After the message appears, the usb keyboard will not work. It seems
>> that the configuration actually did succeed however. Checking the
>> device status for a return code of zero and continuing allows the usb
>> keyboard and other usb devices to work function.
>>
>> Signed-off-by: Jason Wessel
>> ---
>> common/usb.c | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/common/usb.c b/common/usb.c
>> index aad13fd9c5..0eb5d40a2d 100644
>> --- a/common/usb.c
>> +++ b/common/usb.c
>> @@ -1054,11 +1054,12 @@ static int usb_prepare_device(struct usb_device
>> *dev, int addr, bool do_read,
>> dev->devnum = addr;
>>
>> err = usb_set_address(dev); /* set address */
>> -
>> -if (err < 0) {
>> +if (err < 0)
>> +debug("\n usb_set_address return < 0\n");
>
> Please print the return code here.
Good idea.
>
> Is dev->status always set by usb_set_address() when err < 0 ?
Yes. The status is filled in as far as I can tell. I had
received other values when exceeding timing thresholds with
too many printfs() to the serial port while debugging.
The usb hardware hardware devices seem to like their initialization
to be completed in a timely manner.
Jason.
>
>> +if (err < 0 && dev->status != 0) {
>> printf("\n USB device not accepting new address " \
>> "(error=%lX)\n", dev->status);
>> -return err;
>> +return err;
>> }
>>
>> mdelay(10); /* Let the SET_ADDRESS settle */
>>
Re: [RESEND][PATCH 3/3] usb.c: Add a retry in the usb_prepare_device()
>From the Raspberry Pi3 - With the patch removed: U-Boot> setenv usb_pgood_delay 2000 U-Boot> usb reset resetting USB... Bus usb@7e98: USB DWC2 scanning bus usb@7e98 for devices... unable to get device descriptor (error=-22) 6 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found The only way I found to make it work reliably was to have it retry in the usb_prepare_device(). Jason. On 8/18/20 10:08 AM, Marek Vasut wrote: > On 8/18/20 4:34 PM, Jason Wessel wrote: >> I have found through testing some USB 2 composite mouse/keyboard >> devices do not response to the usb_set_address call immediately >> following the port reset. It can take anywhere from 2ms to 20ms. > > Does it work if you do > > => setenv usb_pgood_delay 2000 > > before your test ? >
Re: [RESEND][PATCH 1/3] usb_kbd: succeed even if no interrupt is pending
On 8/18/20 10:05 AM, Marek Vasut wrote:
> On 8/18/20 4:34 PM, Jason Wessel wrote:
>> After the initial configuration some USB keyboard+mouse devices never
>> return any kind of event on the interrupt line. In particular, the
>> device identified by "Cypress Cypress USB Keyboard / PS2 Mouse as
>> 3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:04B4:0101.0001/input/input0"
>> never returns a data packet until the first external input event.
>>
>> I found this was also true with some newer model Dell keyboards.
>>
>> When the device is plugged into a xhci controller there is also no
>> point in waiting 5 seconds for a device that is never going to present
>> data, so the call to the interrupt service was changed to a
>> nonblocking operation for the controllers that support this.
>>
>> With the patch applied, the rpi3 and rpi4 work well with the more
>> complex keyboard devices.
>
> Please extend the comment in the code, it is not clear from it or from
> the commit message what the problem really is that this patch tries to fix.
>
> Also, the printf() below the return 1 is never reached.
>
The printf() is only reached in the case of the #ifdef above it being true.
The compiler in theory should optimize it away, but for clarity it can be moved
with in the #ifdef but that also requires fixing it in two places because
there are multiple levels to the #ifdef.
Would the following be acceptable, which I can put in the next version.
commit 319c75ee3d1fce8a3389d1de857751504b5110cb (HEAD -> master)
Author: Jason Wessel
Date: Thu Jun 25 05:31:25 2020 -0700
usb_kbd: succeed even if no interrupt is pending
After the initial configuration some USB keyboard+mouse devices never
return any kind of event on the interrupt line. In particular, the
device identified by "Cypress Cypress USB Keyboard / PS2 Mouse as
3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:04B4:0101.0001/input/input0"
never returns a data packet until the first external input event.
I found this was also true with some newer model Dell keyboards.
Without the patch u-boot prints the following on one of keyboards and
leave it unable to accept input events.
=
scanning bus xhci_pci for devices...
Failed to get keyboard state from device 14dd:1009
=
With the patch, all families of the Raspberry Pi boards can use this
keyboard device.
Signed-off-by: Jason Wessel
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index b316807844..9ff008d5dc 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -514,18 +514,28 @@ static int usb_kbd_probe_dev(struct usb_device *dev,
unsigned int ifnum)
USB_KBD_BOOT_REPORT_SIZE, data->new,
data->intinterval);
if (!data->intq) {
+ printf("Failed to get keyboard state from device %04x:%04x\n",
+ dev->descriptor.idVendor, dev->descriptor.idProduct);
+ /* Abort, we don't want to use that non-functional keyboard. */
+ return 0;
+ }
#elif defined(CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP)
if (usb_get_report(dev, iface->desc.bInterfaceNumber,
1, 0, data->new, USB_KBD_BOOT_REPORT_SIZE) < 0) {
-#else
- if (usb_int_msg(dev, data->intpipe, data->new, data->intpktsize,
- data->intinterval, false) < 0) {
-#endif
printf("Failed to get keyboard state from device %04x:%04x\n",
dev->descriptor.idVendor, dev->descriptor.idProduct);
/* Abort, we don't want to use that non-functional keyboard. */
return 0;
}
+#else
+ /*
+* Set poll to true for initial interrupt transfer
+* because some keyboard devices do not return an
+* event until the first keypress.
+*/
+ usb_int_msg(dev, data->intpipe, data->new, data->intpktsize,
+ data->intinterval, true);
+#endif
/* Success. */
return 1;
[RESEND][PATCH 2/3] common/usb.c: Work around keyboard reporting "USB device not accepting new address"
When resetting the rpi3 board sometimes it will display:
USB device not accepting new address (error=0)
After the message appears, the usb keyboard will not work. It seems
that the configuration actually did succeed however. Checking the
device status for a return code of zero and continuing allows the usb
keyboard and other usb devices to work function.
Signed-off-by: Jason Wessel
---
common/usb.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index aad13fd9c5..0eb5d40a2d 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1054,11 +1054,12 @@ static int usb_prepare_device(struct usb_device *dev,
int addr, bool do_read,
dev->devnum = addr;
err = usb_set_address(dev); /* set address */
-
- if (err < 0) {
+ if (err < 0)
+ debug("\n usb_set_address return < 0\n");
+ if (err < 0 && dev->status != 0) {
printf("\n USB device not accepting new address " \
"(error=%lX)\n", dev->status);
- return err;
+ return err;
}
mdelay(10); /* Let the SET_ADDRESS settle */
--
2.17.1
[RESEND][PATCH 3/3] usb.c: Add a retry in the usb_prepare_device()
I have found through testing some USB 2 composite mouse/keyboard
devices do not response to the usb_set_address call immediately
following the port reset. It can take anywhere from 2ms to 20ms.
This patch adds a retry and delay for usb_prepare_device() and allows
all the USB keyboards I tried to function properly.
Signed-off-by: Jason Wessel
---
common/usb.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/common/usb.c b/common/usb.c
index 0eb5d40a2d..39bae86a11 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1032,6 +1032,7 @@ static int usb_prepare_device(struct usb_device *dev, int
addr, bool do_read,
struct usb_device *parent)
{
int err;
+ int retry_msec = 0;
/*
* Allocate usb 3.0 device context.
@@ -1054,6 +1055,14 @@ static int usb_prepare_device(struct usb_device *dev,
int addr, bool do_read,
dev->devnum = addr;
err = usb_set_address(dev); /* set address */
+ /* Retry for old composite keyboard/mouse usb2 hardware */
+ while (err < 0 && retry_msec <= 40) {
+ retry_msec += 20;
+ mdelay(20);
+ err = usb_set_address(dev); /* set address */
+ }
+ if (retry_msec > 0)
+ debug("usb_set_address delay: %i\n", retry_msec);
if (err < 0)
debug("\n usb_set_address return < 0\n");
if (err < 0 && dev->status != 0) {
--
2.17.1
[RESEND][PATCH 0/3] Raspberry pi improvements usb core
These patches are now in use by other developers, and I would like to
get them into the upstream u-boot. This 3 patches were part of a 9
patch series posted in July prior to the merge window closure.
-- Travis CI checks https://github.com/u-boot/u-boot/pull/35 --
Pull Request #35 Rpi master
The commit 57805f2270c4 ("net: bcmgenet: Don't set ID_MODE_DIS when
not using RGMII") needed to be extended for the case of using the
rgmii-rxid. The latest version of the Rasbperry Pi4 dtb files for the
5.4 now specify the rgmii-rxid.
Signed-off-by: Jason Wessel
Commit 9a21770 #35: Rpi master Branch master
-- End Travis CI checks --
Jason Wessel (3):
usb_kbd: succeed even if no interrupt is pending
common/usb.c: Work around keyboard reporting "USB device not accepting
new address"
usb.c: Add a retry in the usb_prepare_device()
common/usb.c | 16 +---
common/usb_kbd.c | 4 +++-
2 files changed, 16 insertions(+), 4 deletions(-)
[RESEND][PATCH 1/3] usb_kbd: succeed even if no interrupt is pending
After the initial configuration some USB keyboard+mouse devices never
return any kind of event on the interrupt line. In particular, the
device identified by "Cypress Cypress USB Keyboard / PS2 Mouse as
3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:04B4:0101.0001/input/input0"
never returns a data packet until the first external input event.
I found this was also true with some newer model Dell keyboards.
When the device is plugged into a xhci controller there is also no
point in waiting 5 seconds for a device that is never going to present
data, so the call to the interrupt service was changed to a
nonblocking operation for the controllers that support this.
With the patch applied, the rpi3 and rpi4 work well with the more
complex keyboard devices.
Signed-off-by: Jason Wessel
---
common/usb_kbd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index b316807844..3c0056e1b9 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -519,7 +519,9 @@ static int usb_kbd_probe_dev(struct usb_device *dev,
unsigned int ifnum)
1, 0, data->new, USB_KBD_BOOT_REPORT_SIZE) < 0) {
#else
if (usb_int_msg(dev, data->intpipe, data->new, data->intpktsize,
- data->intinterval, false) < 0) {
+ data->intinterval, true) < 0) {
+ /* Read first packet if the device provides it, else pick it up
later */
+ return 1;
#endif
printf("Failed to get keyboard state from device %04x:%04x\n",
dev->descriptor.idVendor, dev->descriptor.idProduct);
--
2.17.1
[PATCH 8/9] bcmgenet: fix DMA buffer management
This commit fixes a serious issue occurring when several network
commands are run on a raspberry pi 4 board: for instance a "dhcp"
command and then one or several "tftp" commands. In this case,
packet recv callbacks were called several times on the same packets,
and send function was failing most of the time.
note: if the boot procedure is made of a single network
command, the issue is not visible.
The issue is related to management of the packet ring buffers
(producer / consumer) and DMA.
Each time a packet is received, the ethernet device stores it
in the buffer and increments an index called RDMA_PROD_INDEX.
Each time the driver outputs a received packet, it increments
another index called RDMA_CONS_INDEX.
Between each pair of network commands, as part of the driver
'start' function, previous code tried to reset both RDMA_CONS_INDEX
and RDMA_PROD_INDEX to 0. But RDMA_PROD_INDEX cannot be written from
driver side, thus its value was actually not updated, and only
RDMA_CONS_INDEX was reset to 0. This was resulting in a major
synchronization issue between the driver and the device. Most
visible behavior was that the driver seemed to receive again the
packets from the previous commands (e.g. DHCP response packets
"received" again when performing the first TFTP command).
This fix consists in setting RDMA_CONS_INDEX to the same
value as RDMA_PROD_INDEX, when resetting the driver.
The same kind of fix was needed on the TX side, and a few variables
had to be reset accordingly (c_index, tx_index, rx_index).
The rx_index and tx_index have only 256 entries so the bottom 8 bits
must be masked off.
Originated-by: Etienne Dublé
Signed-off-by: Jason Wessel
---
drivers/net/bcmgenet.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
index 11b6148ab6..1b7e7ba2bf 100644
--- a/drivers/net/bcmgenet.c
+++ b/drivers/net/bcmgenet.c
@@ -378,8 +378,6 @@ static void rx_descs_init(struct bcmgenet_eth_priv *priv)
u32 len_stat, i;
void *desc_base = priv->rx_desc_base;
- priv->c_index = 0;
-
len_stat = (RX_BUF_LENGTH << DMA_BUFLENGTH_SHIFT) | DMA_OWN;
for (i = 0; i < RX_DESCS; i++) {
@@ -403,8 +401,11 @@ static void rx_ring_init(struct bcmgenet_eth_priv *priv)
writel(RX_DESCS * DMA_DESC_SIZE / 4 - 1,
priv->mac_reg + RDMA_RING_REG_BASE + DMA_END_ADDR);
- writel(0x0, priv->mac_reg + RDMA_PROD_INDEX);
- writel(0x0, priv->mac_reg + RDMA_CONS_INDEX);
+ /* cannot init RDMA_PROD_INDEX to 0, so align RDMA_CONS_INDEX on it
instead */
+ priv->c_index = readl(priv->mac_reg + RDMA_PROD_INDEX);
+ writel(priv->c_index, priv->mac_reg + RDMA_CONS_INDEX);
+ priv->rx_index = priv->c_index;
+ priv->rx_index &= 0xFF;
writel((RX_DESCS << DMA_RING_SIZE_SHIFT) | RX_BUF_LENGTH,
priv->mac_reg + RDMA_RING_REG_BASE + DMA_RING_BUF_SIZE);
writel(DMA_FC_THRESH_VALUE, priv->mac_reg + RDMA_XON_XOFF_THRESH);
@@ -421,8 +422,10 @@ static void tx_ring_init(struct bcmgenet_eth_priv *priv)
writel(0x0, priv->mac_reg + TDMA_WRITE_PTR);
writel(TX_DESCS * DMA_DESC_SIZE / 4 - 1,
priv->mac_reg + TDMA_RING_REG_BASE + DMA_END_ADDR);
- writel(0x0, priv->mac_reg + TDMA_PROD_INDEX);
- writel(0x0, priv->mac_reg + TDMA_CONS_INDEX);
+ /* cannot init TDMA_CONS_INDEX to 0, so align TDMA_PROD_INDEX on it
instead */
+ priv->tx_index = readl(priv->mac_reg + TDMA_CONS_INDEX);
+ writel(priv->tx_index, priv->mac_reg + TDMA_PROD_INDEX);
+ priv->tx_index &= 0xFF;
writel(0x1, priv->mac_reg + TDMA_RING_REG_BASE + DMA_MBUF_DONE_THRESH);
writel(0x0, priv->mac_reg + TDMA_FLOW_PERIOD);
writel((TX_DESCS << DMA_RING_SIZE_SHIFT) | RX_BUF_LENGTH,
@@ -469,8 +472,6 @@ static int bcmgenet_gmac_eth_start(struct udevice *dev)
priv->tx_desc_base = priv->mac_reg + GENET_TX_OFF;
priv->rx_desc_base = priv->mac_reg + GENET_RX_OFF;
- priv->tx_index = 0x0;
- priv->rx_index = 0x0;
bcmgenet_umac_reset(priv);
--
2.17.1
[PATCH 1/9] fs/fat/fat.c: Do not perform zero block reads if there are no blocks left
While using u-boot with qemu's virtio driver I stumbled across a
problem reading files less than sector size. On the real hardware the
block reader seems ok with reading zero blocks, and while we could fix
the virtio host side of qemu to deal with a zero block read instead of
crashing, the u-boot fat driver should not be doing zero block reads
in the first place. If you ask hardware to read zero blocks you are
just going to get zero data. There may also be other hardware that
responds similarly to the virtio interface so this is worth fixing.
Without the patch I get the following and have to restart qemu because
it dies.
-
=> fatls virtio 0:1
30 cmdline.txt
=> fatload virtio 0:1 ${loadaddr} cmdline.txt
qemu-system-aarch64: virtio: zero sized buffers are not allowed
-
With the patch I get the expected results.
-
=> fatls virtio 0:1
30 cmdline.txt
=> fatload virtio 0:1 ${loadaddr} cmdline.txt
30 bytes read in 11 ms (2 KiB/s)
=> md.b ${loadaddr} 0x1E
4008: 64 77 63 5f 6f 74 67 2e 6c 70 6d 5f 65 6e 61 62dwc_otg.lpm_enab
40080010: 6c 65 3d 30 20 72 6f 6f 74 77 61 69 74 0a le=0 rootwait.
-----
Signed-off-by: Jason Wessel
Reviewed-by: Tom Rini
---
fs/fat/fat.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 9578b74bae..28aa5aaa9f 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -278,7 +278,10 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
unsigned long size)
}
} else {
idx = size / mydata->sect_size;
- ret = disk_read(startsect, idx, buffer);
+ if (idx == 0)
+ ret = 0;
+ else
+ ret = disk_read(startsect, idx, buffer);
if (ret != idx) {
debug("Error reading data (got %d)\n", ret);
return -1;
--
2.17.1
[PULL][PATCH 0/9] Raspberry pi improvements qemu/usb/ethernet
I would like to get these patches merged for the next release, but
there has been no movement on some of them in over a month. I would
fix any problems with the patches, but I am not aware of any. The
patch set has been tested on all the generations of the raspberry pi
hardware and qemu and passed the travis ci checks.
-- Travis CI checks --
Pull Request #35 Rpi master
The commit 57805f2270c4 ("net: bcmgenet: Don't set ID_MODE_DIS when
not using RGMII") needed to be extended for the case of using the
rgmii-rxid. The latest version of the Rasbperry Pi4 dtb files for the
5.4 now specify the rgmii-rxid.
Signed-off-by: Jason Wessel
Commit 9a21770 #35: Rpi master Branch master
-- End Travis CI checks --
Prior to this patch set, I had just a small number of USB keyboards
function properly with the Rasbpberry Pi boards. Nearly every
composite USB keyboard/mouse I had access to including the Raritan
IP/KVM devices would not initialize properly.
v1-consoldiated:
- Consolidated all the usb and ethernet patches into a single set
- No changes to any of the patches
v1:
- Testing completed against all generations of raspberry pi boards
- check patch warnings add errors have been fixed
rfc v3:
- Add in patch 6
- Finally got the GearHead keyboard + mouse composite USB device working
rfc v2:
- Minor cleanups to patches 1-3 based on prior review
- Patch 4 & 5 are new to fix various xhchi crashes
while having additional devices plugged in along with
booting off the usb port. The nonblocking mode turned
out to be somewhat complex.
rfc v1:
The original purpose of the patch set was to fix problems with the USB
keyboard support with the rpi4. The generic xhci code lacks a non
blocking call to read an event. This causes major problems for the
sleep function as well as for ethernet downloads where a keyboard poll
for interrupting the download blocks for 5 seconds.
The following changes since commit fee68b98fe3890631a9bdf8f8db328179011ee3f:
Merge tag 'efi-2020-10-rc1-4' of
https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-07-16 16:35:15 -0400)
are available in the Git repository at:
https://github.com/jwessel/u-boot
for you to fetch changes up to fb5b89c4f2aa2a95c4024b156099c838d1199bd0:
bcmgenet: Add support for rgmii-rxid (2020-07-17 06:35:11 -0700)
----
Jason Wessel (9):
fs/fat/fat.c: Do not perform zero block reads if there are no blocks left
xhci: Add polling support for USB keyboards
usb_kbd: succeed even if no interrupt is pending
common/usb.c: Work around keyboard reporting "USB device not accepting
new address"
xhci-ring.c: Add the poll_pend state to properly abort transactions
xhci-ring: Fix crash when issuing "usb reset"
usb.c: Add a retry in the usb_prepare_device()
bcmgenet: fix DMA buffer management
bcmgenet: Add support for rgmii-rxid
common/usb.c | 16 --
common/usb_kbd.c | 4 +-
drivers/net/bcmgenet.c | 20 +++
drivers/usb/host/xhci-ring.c | 123 +--
drivers/usb/host/xhci.c | 11 ++--
fs/fat/fat.c | 5 +-
include/usb/xhci.h | 5 +-
7 files changed, 136 insertions(+), 48 deletions(-)
[PATCH 7/9] usb.c: Add a retry in the usb_prepare_device()
I have found through testing some USB 2 composite mouse/keyboard
devices do not response to the usb_set_address call immediately
following the port reset. It can take anywhere from 2ms to 20ms.
This patch adds a retry and delay for usb_prepare_device() and allows
all the USB keyboards I tried to function properly.
Signed-off-by: Jason Wessel
---
common/usb.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/common/usb.c b/common/usb.c
index 0eb5d40a2d..39bae86a11 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1032,6 +1032,7 @@ static int usb_prepare_device(struct usb_device *dev, int
addr, bool do_read,
struct usb_device *parent)
{
int err;
+ int retry_msec = 0;
/*
* Allocate usb 3.0 device context.
@@ -1054,6 +1055,14 @@ static int usb_prepare_device(struct usb_device *dev,
int addr, bool do_read,
dev->devnum = addr;
err = usb_set_address(dev); /* set address */
+ /* Retry for old composite keyboard/mouse usb2 hardware */
+ while (err < 0 && retry_msec <= 40) {
+ retry_msec += 20;
+ mdelay(20);
+ err = usb_set_address(dev); /* set address */
+ }
+ if (retry_msec > 0)
+ debug("usb_set_address delay: %i\n", retry_msec);
if (err < 0)
debug("\n usb_set_address return < 0\n");
if (err < 0 && dev->status != 0) {
--
2.17.1
[PATCH 2/9] xhci: Add polling support for USB keyboards
The xhci driver was causing intermittent 5 second delays from the USB
keyboard polling hook. Executing something like a "sleep 1" for
example would sleep for 5 seconds, unless an event occurred on
the USB bus to shorten the delay.
Modeled after the code in the DWC2 driver, a nonblock state was added
to quickly return instead of blocking for up to 5 seconds waiting for
an event before timing out.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 26 +-
drivers/usb/host/xhci.c | 11 ++-
include/usb/xhci.h | 5 +++--
3 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 86aeaab412..b7b2e16410 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -432,9 +432,11 @@ static int event_ready(struct xhci_ctrl *ctrl)
*
* @param ctrl Host controller data structure
* @param expected TRB type expected from Event TRB
+ * @param nonblock when true do not block waiting for response
* @return pointer to event trb
*/
-union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected)
+union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected,
+ bool nonblock)
{
trb_type type;
unsigned long ts = get_timer(0);
@@ -442,8 +444,11 @@ union xhci_trb *xhci_wait_for_event(struct xhci_ctrl
*ctrl, trb_type expected)
do {
union xhci_trb *event = ctrl->event_ring->dequeue;
- if (!event_ready(ctrl))
+ if (!event_ready(ctrl)) {
+ if (nonblock)
+ return NULL;
continue;
+ }
type = TRB_FIELD_TO_TYPE(le32_to_cpu(event->event_cmd.flags));
if (type == expected)
@@ -493,7 +498,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
field = le32_to_cpu(event->trans_event.flags);
BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
@@ -501,7 +506,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
!= COMP_STOP)));
xhci_acknowledge_event(ctrl);
- event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
+ event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
!= udev->slot_id || GET_COMP_CODE(le32_to_cpu(
event->event_cmd.status)) != COMP_SUCCESS);
@@ -509,7 +514,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
xhci_queue_command(ctrl, (void *)((uintptr_t)ring->enqueue |
ring->cycle_state), udev->slot_id, ep_index, TRB_SET_DEQ);
- event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
+ event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
!= udev->slot_id || GET_COMP_CODE(le32_to_cpu(
event->event_cmd.status)) != COMP_SUCCESS);
@@ -552,10 +557,11 @@ static void record_transfer_result(struct usb_device
*udev,
* @param pipe contains the DIR_IN or OUT , devnum
* @param length length of the buffer
* @param buffer buffer to be read/written based on the request
+ * @param nonblock when true do not block waiting for response
* @return returns 0 if successful else -1 on failure
*/
int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
- int length, void *buffer)
+ int length, void *buffer, bool nonblock)
{
int num_trbs = 0;
struct xhci_generic_trb *start_trb;
@@ -714,8 +720,10 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, nonblock);
if (!event) {
+ if (nonblock)
+ return -EINVAL;
debug("XHCI bulk transfer timed out, aborting...\n");
abort_td(udev, ep_index);
udev->status = USB_ST_NAK_REC; /* closest thing to a timeout */
@@ -911,7 +919,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
if (!event)
goto abort;
field = le32_to_cpu(event->tra
[PATCH 5/9] xhci-ring.c: Add the poll_pend state to properly abort transactions
xhci_trl_tx and xhchi_bulk_tx can be called synchronously by other
drivers such as the usb storage or network, while the keyboard driver
exclusively uses the polling mode.
And pending polling transactions must be aborted before switching
modes to avoid corrupting the state of the controller.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 86 +---
1 file changed, 70 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index b7b2e16410..d6339f4f0a 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -24,6 +24,12 @@
#include
+static void *last_bulk_tx_buf;
+static struct usb_device *poll_last_udev;
+int poll_last_ep_index;
+static unsigned long bulk_tx_poll_ts;
+static bool poll_pend;
+
/**
* Is this TRB a link TRB or was the last TRB the last TRB in this event ring
* segment? I.e. would the updated event TRB pointer step off the end of the
@@ -549,19 +555,8 @@ static void record_transfer_result(struct usb_device *udev,
}
}
-/ Bulk and Control transfer methods /
-/**
- * Queues up the BULK Request
- *
- * @param udev pointer to the USB device structure
- * @param pipe contains the DIR_IN or OUT , devnum
- * @param length length of the buffer
- * @param buffer buffer to be read/written based on the request
- * @param nonblock when true do not block waiting for response
- * @return returns 0 if successful else -1 on failure
- */
-int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
- int length, void *buffer, bool nonblock)
+static int _xhci_bulk_tx_queue(struct usb_device *udev, unsigned long pipe,
+ int length, void *buffer)
{
int num_trbs = 0;
struct xhci_generic_trb *start_trb;
@@ -575,7 +570,6 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
struct xhci_virt_device *virt_dev;
struct xhci_ep_ctx *ep_ctx;
struct xhci_ring *ring; /* EP transfer ring */
- union xhci_trb *event;
int running_total, trb_buff_len;
unsigned int total_packet_count;
@@ -719,20 +713,73 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
} while (running_total < length);
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
+ return 0;
+}
+/ Bulk and Control transfer methods /
+/**
+ * Queues up the BULK Request
+ *
+ * @param udev pointer to the USB device structure
+ * @param pipe contains the DIR_IN or OUT , devnum
+ * @param length length of the buffer
+ * @param buffer buffer to be read/written based on the request
+ * @param nonblock when true do not block waiting for response
+ * @return returns 0 if successful else -1 on failure
+ */
+int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
+int length, void *buffer, bool nonblock)
+{
+ u32 field;
+ int ret;
+ union xhci_trb *event;
+ struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
+ int ep_index = usb_pipe_ep_index(pipe);
+
+ if (poll_pend) {
+ /*
+* Abort a pending poll operation if it should have
+* timed out, or if this is a different buffer from a
+* separate request
+*/
+ if (get_timer(bulk_tx_poll_ts) > XHCI_TIMEOUT ||
+ last_bulk_tx_buf != buffer || poll_last_udev != udev ||
+ ep_index != poll_last_ep_index) {
+ abort_td(poll_last_udev, poll_last_ep_index);
+ poll_last_udev->status = USB_ST_NAK_REC; /* closest
thing to a timeout */
+ poll_last_udev->act_len = 0;
+ poll_pend = false;
+ }
+ } /* No else here because poll_pend might have changed above */
+ if (!poll_pend) {
+ last_bulk_tx_buf = buffer;
+ ret = _xhci_bulk_tx_queue(udev, pipe, length, buffer);
+ if (ret)
+ return ret;
+ }
event = xhci_wait_for_event(ctrl, TRB_TRANSFER, nonblock);
if (!event) {
- if (nonblock)
+ if (nonblock) {
+ if (!poll_pend) {
+ /* Start the timer */
+ bulk_tx_poll_ts = get_timer(0);
+ poll_last_udev = udev;
+ poll_last_ep_index = ep_index;
+ poll_pend = true;
+ }
return -EINVAL;
+ }
debug("XHCI bulk transfer timed out, aborting...\n");
abort_td(udev, ep_index);
udev->status = USB_ST_NAK_REC; /* closest thing to a timeout */
udev->act_len =
[PATCH 6/9] xhci-ring: Fix crash when issuing "usb reset"
If a "usb reset" is issued when the poll_pend state is set the
abort_td() function will hit one of the BUG() statements in abort_td()
or the BUG() statement at the end of xhci_wait_for_event().
The controller has been reset, so the rest of the cleanup should be
skipped and poll_pend flag should be cleared.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d6339f4f0a..f2a07204cd 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -483,6 +483,8 @@ union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl,
trb_type expected,
if (expected == TRB_TRANSFER)
return NULL;
+ if (poll_pend)
+ return NULL;
printf("XHCI timeout on event type %d... cannot recover.\n", expected);
BUG();
}
@@ -505,11 +507,16 @@ static void abort_td(struct usb_device *udev, int
ep_index)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
- field = le32_to_cpu(event->trans_event.flags);
- BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
- BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
- BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len
- != COMP_STOP)));
+ if (event) {
+ field = le32_to_cpu(event->trans_event.flags);
+ BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
+ BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
+ BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len
+!= COMP_STOP)));
+ } else {
+ debug("XHCI abort timeout\n");
+ return;
+ }
xhci_acknowledge_event(ctrl);
event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
--
2.17.1
[PATCH 9/9] bcmgenet: Add support for rgmii-rxid
The commit 57805f2270c4 ("net: bcmgenet: Don't set ID_MODE_DIS when
not using RGMII") needed to be extended for the case of using the
rgmii-rxid. The latest version of the Rasbperry Pi4 dtb files for the
5.4 now specify the rgmii-rxid.
Signed-off-by: Jason Wessel
---
drivers/net/bcmgenet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
index 1b7e7ba2bf..ace1331362 100644
--- a/drivers/net/bcmgenet.c
+++ b/drivers/net/bcmgenet.c
@@ -457,7 +457,8 @@ static int bcmgenet_adjust_link(struct bcmgenet_eth_priv
*priv)
clrsetbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, OOB_DISABLE,
RGMII_LINK | RGMII_MODE_EN);
- if (phy_dev->interface == PHY_INTERFACE_MODE_RGMII)
+ if (phy_dev->interface == PHY_INTERFACE_MODE_RGMII ||
+ phy_dev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
setbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, ID_MODE_DIS);
writel(speed << CMD_SPEED_SHIFT, (priv->mac_reg + UMAC_CMD));
--
2.17.1
[PATCH 3/9] usb_kbd: succeed even if no interrupt is pending
After the initial configuration some USB keyboard+mouse devices never
return any kind of event on the interrupt line. In particular, the
device identified by "Cypress Cypress USB Keyboard / PS2 Mouse as
3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:04B4:0101.0001/input/input0"
never returns a data packet until the first external input event.
I found this was also true with some newer model Dell keyboards.
When the device is plugged into a xhci controller there is also no
point in waiting 5 seconds for a device that is never going to present
data, so the call to the interrupt service was changed to a
nonblocking operation for the controllers that support this.
With the patch applied, the rpi3 and rpi4 work well with the more
complex keyboard devices.
Signed-off-by: Jason Wessel
---
common/usb_kbd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index b316807844..3c0056e1b9 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -519,7 +519,9 @@ static int usb_kbd_probe_dev(struct usb_device *dev,
unsigned int ifnum)
1, 0, data->new, USB_KBD_BOOT_REPORT_SIZE) < 0) {
#else
if (usb_int_msg(dev, data->intpipe, data->new, data->intpktsize,
- data->intinterval, false) < 0) {
+ data->intinterval, true) < 0) {
+ /* Read first packet if the device provides it, else pick it up
later */
+ return 1;
#endif
printf("Failed to get keyboard state from device %04x:%04x\n",
dev->descriptor.idVendor, dev->descriptor.idProduct);
--
2.17.1
[PATCH 4/9] common/usb.c: Work around keyboard reporting "USB device not accepting new address"
When resetting the rpi3 board sometimes it will display:
USB device not accepting new address (error=0)
After the message appears, the usb keyboard will not work. It seems
that the configuration actually did succeed however. Checking the
device status for a return code of zero and continuing allows the usb
keyboard and other usb devices to work function.
Signed-off-by: Jason Wessel
---
common/usb.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index aad13fd9c5..0eb5d40a2d 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1054,11 +1054,12 @@ static int usb_prepare_device(struct usb_device *dev,
int addr, bool do_read,
dev->devnum = addr;
err = usb_set_address(dev); /* set address */
-
- if (err < 0) {
+ if (err < 0)
+ debug("\n usb_set_address return < 0\n");
+ if (err < 0 && dev->status != 0) {
printf("\n USB device not accepting new address " \
"(error=%lX)\n", dev->status);
- return err;
+ return err;
}
mdelay(10); /* Let the SET_ADDRESS settle */
--
2.17.1
[PATCH 1/2] bcmgenet: fix DMA buffer management
This commit fixes a serious issue occurring when several network
commands are run on a raspberry pi 4 board: for instance a "dhcp"
command and then one or several "tftp" commands. In this case,
packet recv callbacks were called several times on the same packets,
and send function was failing most of the time.
note: if the boot procedure is made of a single network
command, the issue is not visible.
The issue is related to management of the packet ring buffers
(producer / consumer) and DMA.
Each time a packet is received, the ethernet device stores it
in the buffer and increments an index called RDMA_PROD_INDEX.
Each time the driver outputs a received packet, it increments
another index called RDMA_CONS_INDEX.
Between each pair of network commands, as part of the driver
'start' function, previous code tried to reset both RDMA_CONS_INDEX
and RDMA_PROD_INDEX to 0. But RDMA_PROD_INDEX cannot be written from
driver side, thus its value was actually not updated, and only
RDMA_CONS_INDEX was reset to 0. This was resulting in a major
synchronization issue between the driver and the device. Most
visible behavior was that the driver seemed to receive again the
packets from the previous commands (e.g. DHCP response packets
"received" again when performing the first TFTP command).
This fix consists in setting RDMA_CONS_INDEX to the same
value as RDMA_PROD_INDEX, when resetting the driver.
The same kind of fix was needed on the TX side, and a few variables
had to be reset accordingly (c_index, tx_index, rx_index).
The rx_index and tx_index have only 256 entries so the bottom 8 bits
must be masked off.
Originated-by: Etienne Dublé
Signed-off-by: Jason Wessel
---
drivers/net/bcmgenet.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
index 11b6148ab6..1b7e7ba2bf 100644
--- a/drivers/net/bcmgenet.c
+++ b/drivers/net/bcmgenet.c
@@ -378,8 +378,6 @@ static void rx_descs_init(struct bcmgenet_eth_priv *priv)
u32 len_stat, i;
void *desc_base = priv->rx_desc_base;
- priv->c_index = 0;
-
len_stat = (RX_BUF_LENGTH << DMA_BUFLENGTH_SHIFT) | DMA_OWN;
for (i = 0; i < RX_DESCS; i++) {
@@ -403,8 +401,11 @@ static void rx_ring_init(struct bcmgenet_eth_priv *priv)
writel(RX_DESCS * DMA_DESC_SIZE / 4 - 1,
priv->mac_reg + RDMA_RING_REG_BASE + DMA_END_ADDR);
- writel(0x0, priv->mac_reg + RDMA_PROD_INDEX);
- writel(0x0, priv->mac_reg + RDMA_CONS_INDEX);
+ /* cannot init RDMA_PROD_INDEX to 0, so align RDMA_CONS_INDEX on it
instead */
+ priv->c_index = readl(priv->mac_reg + RDMA_PROD_INDEX);
+ writel(priv->c_index, priv->mac_reg + RDMA_CONS_INDEX);
+ priv->rx_index = priv->c_index;
+ priv->rx_index &= 0xFF;
writel((RX_DESCS << DMA_RING_SIZE_SHIFT) | RX_BUF_LENGTH,
priv->mac_reg + RDMA_RING_REG_BASE + DMA_RING_BUF_SIZE);
writel(DMA_FC_THRESH_VALUE, priv->mac_reg + RDMA_XON_XOFF_THRESH);
@@ -421,8 +422,10 @@ static void tx_ring_init(struct bcmgenet_eth_priv *priv)
writel(0x0, priv->mac_reg + TDMA_WRITE_PTR);
writel(TX_DESCS * DMA_DESC_SIZE / 4 - 1,
priv->mac_reg + TDMA_RING_REG_BASE + DMA_END_ADDR);
- writel(0x0, priv->mac_reg + TDMA_PROD_INDEX);
- writel(0x0, priv->mac_reg + TDMA_CONS_INDEX);
+ /* cannot init TDMA_CONS_INDEX to 0, so align TDMA_PROD_INDEX on it
instead */
+ priv->tx_index = readl(priv->mac_reg + TDMA_CONS_INDEX);
+ writel(priv->tx_index, priv->mac_reg + TDMA_PROD_INDEX);
+ priv->tx_index &= 0xFF;
writel(0x1, priv->mac_reg + TDMA_RING_REG_BASE + DMA_MBUF_DONE_THRESH);
writel(0x0, priv->mac_reg + TDMA_FLOW_PERIOD);
writel((TX_DESCS << DMA_RING_SIZE_SHIFT) | RX_BUF_LENGTH,
@@ -469,8 +472,6 @@ static int bcmgenet_gmac_eth_start(struct udevice *dev)
priv->tx_desc_base = priv->mac_reg + GENET_TX_OFF;
priv->rx_desc_base = priv->mac_reg + GENET_RX_OFF;
- priv->tx_index = 0x0;
- priv->rx_index = 0x0;
bcmgenet_umac_reset(priv);
--
2.17.1
[PATCH 2/2] bcmgenet: Add support for rgmii-rxid
The commit 57805f2270c4 ("net: bcmgenet: Don't set ID_MODE_DIS when
not using RGMII") needed to be extended for the case of using the
rgmii-rxid. The latest version of the Rasbperry Pi4 dtb files for the
5.4 now specify the rgmii-rxid.
Signed-off-by: Jason Wessel
---
drivers/net/bcmgenet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
index 1b7e7ba2bf..ace1331362 100644
--- a/drivers/net/bcmgenet.c
+++ b/drivers/net/bcmgenet.c
@@ -457,7 +457,8 @@ static int bcmgenet_adjust_link(struct bcmgenet_eth_priv
*priv)
clrsetbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, OOB_DISABLE,
RGMII_LINK | RGMII_MODE_EN);
- if (phy_dev->interface == PHY_INTERFACE_MODE_RGMII)
+ if (phy_dev->interface == PHY_INTERFACE_MODE_RGMII ||
+ phy_dev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
setbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, ID_MODE_DIS);
writel(speed << CMD_SPEED_SHIFT, (priv->mac_reg + UMAC_CMD));
--
2.17.1
Re: [PATCH] bcmgenet: fix DMA buffer management
On 7/16/20 11:02 AM, Jason Wessel wrote:
>
>
> On 7/16/20 7:02 AM, Jason Wessel wrote:
>> On 7/9/20 3:11 AM, etienne.du...@gmail.com wrote:
>>> From: Etienne Dublé
>>>
>>> This commit fixes a serious issue occuring when several network
>>> commands are run on a raspberry pi 4 board: for instance a "dhcp"
>>> command and then one or several "tftp" commands. In this case,
>>> packet recv callbacks were called several times on the same packets,
>>> and send function was failing most of the time.
>>>
>>> note: if the boot procedure is made of a single network
>>> command, the issue is not visible.
>>>
>>> The issue is related to management of the packet ring buffers
>>> (producer / consumer) and DMA.
>>> Each time a packet is received, the ethernet device stores it
>>> in the buffer and increments an index called RDMA_PROD_INDEX.
>>> Each time the driver outputs a received packet, it increments
>>> another index called RDMA_CONS_INDEX.
>>>
>>> Between each pair of network commands, as part of the driver
>>> 'start' function, previous code tried to reset both RDMA_CONS_INDEX
>>> and RDMA_PROD_INDEX to 0. But RDMA_PROD_INDEX cannot be written from
>>> driver side, thus its value was actually not updated, and only
>>> RDMA_CONS_INDEX was reset to 0. This was resulting in a major
>>> synchronization issue between the driver and the device. Most
>>> visible bahavior was that the driver seemed to receive again the
>>> packets from the previous commands (e.g. DHCP response packets
>>> "received" again when performing the first TFTP command).
>>>
>>> This fix consists in setting RDMA_CONS_INDEX to the same
>>> value as RDMA_PROD_INDEX, when resetting the driver.
>>>
>>> The same kind of fix was needed on the TX side, and a few variables
>>> had to be reset accordingly (c_index, tx_index, rx_index).
>>
>>
>> While there is some kind of problem with the driver, because I too
>> have observed a problem with multiple requests timing out or failing,
>> this patch makes the problem much worse. I was only able to complete
>> a single tftp request.
>>
>> In my case I am using a static IP address and serverip.
>>
>> Also your patch was missing the sign-off line. Please consider
>> running your patches through scripts/checkpatch.pl.
>>
>> Cheers,
>> Jason.
>>
>>> ---
>>> drivers/net/bcmgenet.c | 15 +++
>>> 1 file changed, 7 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
>>> index 11b6148ab6..a4facfd63f 100644
>>> --- a/drivers/net/bcmgenet.c
>>> +++ b/drivers/net/bcmgenet.c
>>> @@ -378,8 +378,6 @@ static void rx_descs_init(struct bcmgenet_eth_priv
>>> *priv)
>>> u32 len_stat, i;
>>> void *desc_base = priv->rx_desc_base;
>>>
>>> - priv->c_index = 0;
>>> -
>>> len_stat = (RX_BUF_LENGTH << DMA_BUFLENGTH_SHIFT) | DMA_OWN;
>>>
>>> for (i = 0; i < RX_DESCS; i++) {
>>> @@ -403,8 +401,10 @@ static void rx_ring_init(struct bcmgenet_eth_priv
>>> *priv)
>>> writel(RX_DESCS * DMA_DESC_SIZE / 4 - 1,
>>>priv->mac_reg + RDMA_RING_REG_BASE + DMA_END_ADDR);
>>>
>>> - writel(0x0, priv->mac_reg + RDMA_PROD_INDEX);
>>> - writel(0x0, priv->mac_reg + RDMA_CONS_INDEX);
>>> + /* cannot init RDMA_PROD_INDEX to 0, so align RDMA_CONS_INDEX on it
>>> instead */
>>> + priv->c_index = readl(priv->mac_reg + RDMA_PROD_INDEX);
>>> + writel(priv->c_index, priv->mac_reg + RDMA_CONS_INDEX);
>>> + priv->rx_index = priv->c_index;
>
>
> printf("before RX_IDX: 0x%x\n", priv->rx_index);
>
> I added a printf() like above for the RX and TX to see what is going on when
> I try and transfer a kernel Image file the second time.
>
>
> U-Boot> tftp ${loadaddr} bootfs/Image
> before RX_IDX: 0x0
> before TX_IDX: 0x0
> Using ethernet@7d58 device
> Filename 'bootfs/Image'.
> Load address: 0x8
> Loading: ## Warning: gatewayip needed but not set
> ## 16.8 MiB
> 6.1 MiB/s
> done
> Bytes transferred = 17615360 (10cca00 hex)
> U-Boot> tftp ${loadaddr} bootfs/Image
> before RX_IDX: 0xe4
> before TX_IDX: 0x2ee3
> Using ethernet@7d58
Re: [PATCH] bcmgenet: fix DMA buffer management
On 7/16/20 7:02 AM, Jason Wessel wrote:
> On 7/9/20 3:11 AM, etienne.du...@gmail.com wrote:
>> From: Etienne Dublé
>>
>> This commit fixes a serious issue occuring when several network
>> commands are run on a raspberry pi 4 board: for instance a "dhcp"
>> command and then one or several "tftp" commands. In this case,
>> packet recv callbacks were called several times on the same packets,
>> and send function was failing most of the time.
>>
>> note: if the boot procedure is made of a single network
>> command, the issue is not visible.
>>
>> The issue is related to management of the packet ring buffers
>> (producer / consumer) and DMA.
>> Each time a packet is received, the ethernet device stores it
>> in the buffer and increments an index called RDMA_PROD_INDEX.
>> Each time the driver outputs a received packet, it increments
>> another index called RDMA_CONS_INDEX.
>>
>> Between each pair of network commands, as part of the driver
>> 'start' function, previous code tried to reset both RDMA_CONS_INDEX
>> and RDMA_PROD_INDEX to 0. But RDMA_PROD_INDEX cannot be written from
>> driver side, thus its value was actually not updated, and only
>> RDMA_CONS_INDEX was reset to 0. This was resulting in a major
>> synchronization issue between the driver and the device. Most
>> visible bahavior was that the driver seemed to receive again the
>> packets from the previous commands (e.g. DHCP response packets
>> "received" again when performing the first TFTP command).
>>
>> This fix consists in setting RDMA_CONS_INDEX to the same
>> value as RDMA_PROD_INDEX, when resetting the driver.
>>
>> The same kind of fix was needed on the TX side, and a few variables
>> had to be reset accordingly (c_index, tx_index, rx_index).
>
>
> While there is some kind of problem with the driver, because I too
> have observed a problem with multiple requests timing out or failing,
> this patch makes the problem much worse. I was only able to complete
> a single tftp request.
>
> In my case I am using a static IP address and serverip.
>
> Also your patch was missing the sign-off line. Please consider
> running your patches through scripts/checkpatch.pl.
>
> Cheers,
> Jason.
>
>> ---
>> drivers/net/bcmgenet.c | 15 +++
>> 1 file changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
>> index 11b6148ab6..a4facfd63f 100644
>> --- a/drivers/net/bcmgenet.c
>> +++ b/drivers/net/bcmgenet.c
>> @@ -378,8 +378,6 @@ static void rx_descs_init(struct bcmgenet_eth_priv *priv)
>> u32 len_stat, i;
>> void *desc_base = priv->rx_desc_base;
>>
>> -priv->c_index = 0;
>> -
>> len_stat = (RX_BUF_LENGTH << DMA_BUFLENGTH_SHIFT) | DMA_OWN;
>>
>> for (i = 0; i < RX_DESCS; i++) {
>> @@ -403,8 +401,10 @@ static void rx_ring_init(struct bcmgenet_eth_priv *priv)
>> writel(RX_DESCS * DMA_DESC_SIZE / 4 - 1,
>> priv->mac_reg + RDMA_RING_REG_BASE + DMA_END_ADDR);
>>
>> -writel(0x0, priv->mac_reg + RDMA_PROD_INDEX);
>> -writel(0x0, priv->mac_reg + RDMA_CONS_INDEX);
>> +/* cannot init RDMA_PROD_INDEX to 0, so align RDMA_CONS_INDEX on it
>> instead */
>> +priv->c_index = readl(priv->mac_reg + RDMA_PROD_INDEX);
>> +writel(priv->c_index, priv->mac_reg + RDMA_CONS_INDEX);
>> +priv->rx_index = priv->c_index;
printf("before RX_IDX: 0x%x\n", priv->rx_index);
I added a printf() like above for the RX and TX to see what is going on when
I try and transfer a kernel Image file the second time.
U-Boot> tftp ${loadaddr} bootfs/Image
before RX_IDX: 0x0
before TX_IDX: 0x0
Using ethernet@7d58 device
Filename 'bootfs/Image'.
Load address: 0x8
Loading: ## Warning: gatewayip needed but not set
## 16.8 MiB
6.1 MiB/s
done
Bytes transferred = 17615360 (10cca00 hex)
U-Boot> tftp ${loadaddr} bootfs/Image
before RX_IDX: 0xe4
before TX_IDX: 0x2ee3
Using ethernet@7d58 device
Filename 'bootfs/Image'.
Load address: 0x8
Loading: ## Warning: gatewayip needed but not set
The TX_IDX is now 0x2ee3 which is definitely not going to work.
According to the driver file there are only 256 (0xFF) slots,
which is why it hangs, with your change.
Jason.
>> writel((RX_DESCS << DMA_RING_SIZE_SHIFT) | RX_BUF_LENGTH,
>> priv->mac_reg + RDMA_RING_REG_BASE + DMA_RING_BUF_SIZE);
>> writel(DMA_FC_T
Re: [PATCH] bcmgenet: fix DMA buffer management
On 7/9/20 3:11 AM, etienne.du...@gmail.com wrote:
> From: Etienne Dublé
>
> This commit fixes a serious issue occuring when several network
> commands are run on a raspberry pi 4 board: for instance a "dhcp"
> command and then one or several "tftp" commands. In this case,
> packet recv callbacks were called several times on the same packets,
> and send function was failing most of the time.
>
> note: if the boot procedure is made of a single network
> command, the issue is not visible.
>
> The issue is related to management of the packet ring buffers
> (producer / consumer) and DMA.
> Each time a packet is received, the ethernet device stores it
> in the buffer and increments an index called RDMA_PROD_INDEX.
> Each time the driver outputs a received packet, it increments
> another index called RDMA_CONS_INDEX.
>
> Between each pair of network commands, as part of the driver
> 'start' function, previous code tried to reset both RDMA_CONS_INDEX
> and RDMA_PROD_INDEX to 0. But RDMA_PROD_INDEX cannot be written from
> driver side, thus its value was actually not updated, and only
> RDMA_CONS_INDEX was reset to 0. This was resulting in a major
> synchronization issue between the driver and the device. Most
> visible bahavior was that the driver seemed to receive again the
> packets from the previous commands (e.g. DHCP response packets
> "received" again when performing the first TFTP command).
>
> This fix consists in setting RDMA_CONS_INDEX to the same
> value as RDMA_PROD_INDEX, when resetting the driver.
>
> The same kind of fix was needed on the TX side, and a few variables
> had to be reset accordingly (c_index, tx_index, rx_index).
While there is some kind of problem with the driver, because I too
have observed a problem with multiple requests timing out or failing,
this patch makes the problem much worse. I was only able to complete
a single tftp request.
In my case I am using a static IP address and serverip.
Also your patch was missing the sign-off line. Please consider
running your patches through scripts/checkpatch.pl.
Cheers,
Jason.
> ---
> drivers/net/bcmgenet.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
> index 11b6148ab6..a4facfd63f 100644
> --- a/drivers/net/bcmgenet.c
> +++ b/drivers/net/bcmgenet.c
> @@ -378,8 +378,6 @@ static void rx_descs_init(struct bcmgenet_eth_priv *priv)
> u32 len_stat, i;
> void *desc_base = priv->rx_desc_base;
>
> - priv->c_index = 0;
> -
> len_stat = (RX_BUF_LENGTH << DMA_BUFLENGTH_SHIFT) | DMA_OWN;
>
> for (i = 0; i < RX_DESCS; i++) {
> @@ -403,8 +401,10 @@ static void rx_ring_init(struct bcmgenet_eth_priv *priv)
> writel(RX_DESCS * DMA_DESC_SIZE / 4 - 1,
> priv->mac_reg + RDMA_RING_REG_BASE + DMA_END_ADDR);
>
> - writel(0x0, priv->mac_reg + RDMA_PROD_INDEX);
> - writel(0x0, priv->mac_reg + RDMA_CONS_INDEX);
> + /* cannot init RDMA_PROD_INDEX to 0, so align RDMA_CONS_INDEX on it
> instead */
> + priv->c_index = readl(priv->mac_reg + RDMA_PROD_INDEX);
> + writel(priv->c_index, priv->mac_reg + RDMA_CONS_INDEX);
> + priv->rx_index = priv->c_index;
> writel((RX_DESCS << DMA_RING_SIZE_SHIFT) | RX_BUF_LENGTH,
> priv->mac_reg + RDMA_RING_REG_BASE + DMA_RING_BUF_SIZE);
> writel(DMA_FC_THRESH_VALUE, priv->mac_reg + RDMA_XON_XOFF_THRESH);
> @@ -421,8 +421,9 @@ static void tx_ring_init(struct bcmgenet_eth_priv *priv)
> writel(0x0, priv->mac_reg + TDMA_WRITE_PTR);
> writel(TX_DESCS * DMA_DESC_SIZE / 4 - 1,
> priv->mac_reg + TDMA_RING_REG_BASE + DMA_END_ADDR);
> - writel(0x0, priv->mac_reg + TDMA_PROD_INDEX);
> - writel(0x0, priv->mac_reg + TDMA_CONS_INDEX);
> + /* cannot init TDMA_CONS_INDEX to 0, so align TDMA_PROD_INDEX on it
> instead */
> + priv->tx_index = readl(priv->mac_reg + TDMA_CONS_INDEX);
> + writel(priv->tx_index, priv->mac_reg + TDMA_PROD_INDEX);
> writel(0x1, priv->mac_reg + TDMA_RING_REG_BASE + DMA_MBUF_DONE_THRESH);
> writel(0x0, priv->mac_reg + TDMA_FLOW_PERIOD);
> writel((TX_DESCS << DMA_RING_SIZE_SHIFT) | RX_BUF_LENGTH,
> @@ -469,8 +470,6 @@ static int bcmgenet_gmac_eth_start(struct udevice *dev)
>
> priv->tx_desc_base = priv->mac_reg + GENET_TX_OFF;
> priv->rx_desc_base = priv->mac_reg + GENET_RX_OFF;
> - priv->tx_index = 0x0;
> - priv->rx_index = 0x0;
>
> bcmgenet_umac_reset(priv);
>
>
[PATCH 6/6] usb.c: Add a retry in the usb_prepare_device()
I have found through testing some USB 2 composite mouse/keyboard
devices do not response to the usb_set_address call immediately
following the port reset. It can take anywhere from 2ms to 20ms.
This patch adds a retry and delay for usb_prepare_device() and allows
all the USB keyboards I tried to function properly.
Signed-off-by: Jason Wessel
---
common/usb.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/common/usb.c b/common/usb.c
index 0eb5d40a2d..39bae86a11 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1032,6 +1032,7 @@ static int usb_prepare_device(struct usb_device *dev, int
addr, bool do_read,
struct usb_device *parent)
{
int err;
+ int retry_msec = 0;
/*
* Allocate usb 3.0 device context.
@@ -1054,6 +1055,14 @@ static int usb_prepare_device(struct usb_device *dev,
int addr, bool do_read,
dev->devnum = addr;
err = usb_set_address(dev); /* set address */
+ /* Retry for old composite keyboard/mouse usb2 hardware */
+ while (err < 0 && retry_msec <= 40) {
+ retry_msec += 20;
+ mdelay(20);
+ err = usb_set_address(dev); /* set address */
+ }
+ if (retry_msec > 0)
+ debug("usb_set_address delay: %i\n", retry_msec);
if (err < 0)
debug("\n usb_set_address return < 0\n");
if (err < 0 && dev->status != 0) {
--
2.17.1
[PATCH 5/6] xhci-ring: Fix crash when issuing "usb reset"
If a "usb reset" is issued when the poll_pend state is set the
abort_td() function will hit one of the BUG() statements in abort_td()
or the BUG() statement at the end of xhci_wait_for_event().
The controller has been reset, so the rest of the cleanup should be
skipped and poll_pend flag should be cleared.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d6339f4f0a..f2a07204cd 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -483,6 +483,8 @@ union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl,
trb_type expected,
if (expected == TRB_TRANSFER)
return NULL;
+ if (poll_pend)
+ return NULL;
printf("XHCI timeout on event type %d... cannot recover.\n", expected);
BUG();
}
@@ -505,11 +507,16 @@ static void abort_td(struct usb_device *udev, int
ep_index)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
- field = le32_to_cpu(event->trans_event.flags);
- BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
- BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
- BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len
- != COMP_STOP)));
+ if (event) {
+ field = le32_to_cpu(event->trans_event.flags);
+ BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
+ BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
+ BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len
+!= COMP_STOP)));
+ } else {
+ debug("XHCI abort timeout\n");
+ return;
+ }
xhci_acknowledge_event(ctrl);
event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
--
2.17.1
[PATCH 1/6] xhci: Add polling support for USB keyboards
The xhci driver was causing intermittent 5 second delays from the USB
keyboard polling hook. Executing something like a "sleep 1" for
example would sleep for 5 seconds, unless an event occurred on
the USB bus to shorten the delay.
Modeled after the code in the DWC2 driver, a nonblock state was added
to quickly return instead of blocking for up to 5 seconds waiting for
an event before timing out.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 26 +-
drivers/usb/host/xhci.c | 11 ++-
include/usb/xhci.h | 5 +++--
3 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 86aeaab412..b7b2e16410 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -432,9 +432,11 @@ static int event_ready(struct xhci_ctrl *ctrl)
*
* @param ctrl Host controller data structure
* @param expected TRB type expected from Event TRB
+ * @param nonblock when true do not block waiting for response
* @return pointer to event trb
*/
-union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected)
+union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected,
+ bool nonblock)
{
trb_type type;
unsigned long ts = get_timer(0);
@@ -442,8 +444,11 @@ union xhci_trb *xhci_wait_for_event(struct xhci_ctrl
*ctrl, trb_type expected)
do {
union xhci_trb *event = ctrl->event_ring->dequeue;
- if (!event_ready(ctrl))
+ if (!event_ready(ctrl)) {
+ if (nonblock)
+ return NULL;
continue;
+ }
type = TRB_FIELD_TO_TYPE(le32_to_cpu(event->event_cmd.flags));
if (type == expected)
@@ -493,7 +498,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
field = le32_to_cpu(event->trans_event.flags);
BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
@@ -501,7 +506,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
!= COMP_STOP)));
xhci_acknowledge_event(ctrl);
- event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
+ event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
!= udev->slot_id || GET_COMP_CODE(le32_to_cpu(
event->event_cmd.status)) != COMP_SUCCESS);
@@ -509,7 +514,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
xhci_queue_command(ctrl, (void *)((uintptr_t)ring->enqueue |
ring->cycle_state), udev->slot_id, ep_index, TRB_SET_DEQ);
- event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
+ event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
!= udev->slot_id || GET_COMP_CODE(le32_to_cpu(
event->event_cmd.status)) != COMP_SUCCESS);
@@ -552,10 +557,11 @@ static void record_transfer_result(struct usb_device
*udev,
* @param pipe contains the DIR_IN or OUT , devnum
* @param length length of the buffer
* @param buffer buffer to be read/written based on the request
+ * @param nonblock when true do not block waiting for response
* @return returns 0 if successful else -1 on failure
*/
int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
- int length, void *buffer)
+ int length, void *buffer, bool nonblock)
{
int num_trbs = 0;
struct xhci_generic_trb *start_trb;
@@ -714,8 +720,10 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, nonblock);
if (!event) {
+ if (nonblock)
+ return -EINVAL;
debug("XHCI bulk transfer timed out, aborting...\n");
abort_td(udev, ep_index);
udev->status = USB_ST_NAK_REC; /* closest thing to a timeout */
@@ -911,7 +919,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
if (!event)
goto abort;
field = le32_to_cpu(event->tra
[PATCH 3/6] common/usb.c: Work around keyboard reporting "USB device not accepting new address"
When resetting the rpi3 board sometimes it will display:
USB device not accepting new address (error=0)
After the message appears, the usb keyboard will not work. It seems
that the configuration actually did succeed however. Checking the
device status for a return code of zero and continuing allows the usb
keyboard and other usb devices to work function.
Signed-off-by: Jason Wessel
---
common/usb.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index aad13fd9c5..0eb5d40a2d 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1054,11 +1054,12 @@ static int usb_prepare_device(struct usb_device *dev,
int addr, bool do_read,
dev->devnum = addr;
err = usb_set_address(dev); /* set address */
-
- if (err < 0) {
+ if (err < 0)
+ debug("\n usb_set_address return < 0\n");
+ if (err < 0 && dev->status != 0) {
printf("\n USB device not accepting new address " \
"(error=%lX)\n", dev->status);
- return err;
+ return err;
}
mdelay(10); /* Let the SET_ADDRESS settle */
--
2.17.1
[PATCH 4/6] xhci-ring.c: Add the poll_pend state to properly abort transactions
xhci_trl_tx and xhchi_bulk_tx can be called synchronously by other
drivers such as the usb storage or network, while the keyboard driver
exclusively uses the polling mode.
And pending polling transactions must be aborted before switching
modes to avoid corrupting the state of the controller.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 86 +---
1 file changed, 70 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index b7b2e16410..d6339f4f0a 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -24,6 +24,12 @@
#include
+static void *last_bulk_tx_buf;
+static struct usb_device *poll_last_udev;
+int poll_last_ep_index;
+static unsigned long bulk_tx_poll_ts;
+static bool poll_pend;
+
/**
* Is this TRB a link TRB or was the last TRB the last TRB in this event ring
* segment? I.e. would the updated event TRB pointer step off the end of the
@@ -549,19 +555,8 @@ static void record_transfer_result(struct usb_device *udev,
}
}
-/ Bulk and Control transfer methods /
-/**
- * Queues up the BULK Request
- *
- * @param udev pointer to the USB device structure
- * @param pipe contains the DIR_IN or OUT , devnum
- * @param length length of the buffer
- * @param buffer buffer to be read/written based on the request
- * @param nonblock when true do not block waiting for response
- * @return returns 0 if successful else -1 on failure
- */
-int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
- int length, void *buffer, bool nonblock)
+static int _xhci_bulk_tx_queue(struct usb_device *udev, unsigned long pipe,
+ int length, void *buffer)
{
int num_trbs = 0;
struct xhci_generic_trb *start_trb;
@@ -575,7 +570,6 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
struct xhci_virt_device *virt_dev;
struct xhci_ep_ctx *ep_ctx;
struct xhci_ring *ring; /* EP transfer ring */
- union xhci_trb *event;
int running_total, trb_buff_len;
unsigned int total_packet_count;
@@ -719,20 +713,73 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
} while (running_total < length);
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
+ return 0;
+}
+/ Bulk and Control transfer methods /
+/**
+ * Queues up the BULK Request
+ *
+ * @param udev pointer to the USB device structure
+ * @param pipe contains the DIR_IN or OUT , devnum
+ * @param length length of the buffer
+ * @param buffer buffer to be read/written based on the request
+ * @param nonblock when true do not block waiting for response
+ * @return returns 0 if successful else -1 on failure
+ */
+int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
+int length, void *buffer, bool nonblock)
+{
+ u32 field;
+ int ret;
+ union xhci_trb *event;
+ struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
+ int ep_index = usb_pipe_ep_index(pipe);
+
+ if (poll_pend) {
+ /*
+* Abort a pending poll operation if it should have
+* timed out, or if this is a different buffer from a
+* separate request
+*/
+ if (get_timer(bulk_tx_poll_ts) > XHCI_TIMEOUT ||
+ last_bulk_tx_buf != buffer || poll_last_udev != udev ||
+ ep_index != poll_last_ep_index) {
+ abort_td(poll_last_udev, poll_last_ep_index);
+ poll_last_udev->status = USB_ST_NAK_REC; /* closest
thing to a timeout */
+ poll_last_udev->act_len = 0;
+ poll_pend = false;
+ }
+ } /* No else here because poll_pend might have changed above */
+ if (!poll_pend) {
+ last_bulk_tx_buf = buffer;
+ ret = _xhci_bulk_tx_queue(udev, pipe, length, buffer);
+ if (ret)
+ return ret;
+ }
event = xhci_wait_for_event(ctrl, TRB_TRANSFER, nonblock);
if (!event) {
- if (nonblock)
+ if (nonblock) {
+ if (!poll_pend) {
+ /* Start the timer */
+ bulk_tx_poll_ts = get_timer(0);
+ poll_last_udev = udev;
+ poll_last_ep_index = ep_index;
+ poll_pend = true;
+ }
return -EINVAL;
+ }
debug("XHCI bulk transfer timed out, aborting...\n");
abort_td(udev, ep_index);
udev->status = USB_ST_NAK_REC; /* closest thing to a timeout */
udev->act_len =
[PATCH 2/6] usb_kbd: succeed even if no interrupt is pending
After the initial configuration some USB keyboard+mouse devices never
return any kind of event on the interrupt line. In particular, the
device identified by "Cypress Cypress USB Keyboard / PS2 Mouse as
3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:04B4:0101.0001/input/input0"
never returns a data packet until the first external input event.
I found this was also true with some newer model Dell keyboards.
When the device is plugged into a xhci controller there is also no
point in waiting 5 seconds for a device that is never going to present
data, so the call to the interrupt service was changed to a
nonblocking operation for the controllers that support this.
With the patch applied, the rpi3 and rpi4 work well with the more
complex keyboard devices.
Signed-off-by: Jason Wessel
---
common/usb_kbd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index b316807844..3c0056e1b9 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -519,7 +519,9 @@ static int usb_kbd_probe_dev(struct usb_device *dev,
unsigned int ifnum)
1, 0, data->new, USB_KBD_BOOT_REPORT_SIZE) < 0) {
#else
if (usb_int_msg(dev, data->intpipe, data->new, data->intpktsize,
- data->intinterval, false) < 0) {
+ data->intinterval, true) < 0) {
+ /* Read first packet if the device provides it, else pick it up
later */
+ return 1;
#endif
printf("Failed to get keyboard state from device %04x:%04x\n",
dev->descriptor.idVendor, dev->descriptor.idProduct);
--
2.17.1
[PATCH 0/6] Improve USB Keyboard support for all rpi boards
Prior to this patch set, I had just a small number of USB keyboards function properly with the Rasbpberry Pi boards. Nearly every composite USB keyboard/mouse I had access to including the Raritan IP/KVM devices would not initialize properly. At this point I have tested all generations of the Raspberry Pi boards (0-4) and the USB keyboards I use day to day are working properly. For the RPi4, I tested against the rpi-master branch which now has the required USB patches, all the other boards were tested against the master branch. v1: - Testing completed against all generations of raspberry pi boards - check patch warnings add errors have been fixed rfc v3: - Add in patch 6 - Finally got the GearHead keyboard + mouse composite USB device working rfc v2: - Minor cleanups to patches 1-3 based on prior review - Patch 4 & 5 are new to fix various xhchi crashes while having additional devices plugged in along with booting off the usb port. The nonblocking mode turned out to be somewhat complex. rfc v1: The original purpose of the patch set was to fix problems with the USB keyboard support with the rpi4. The generic xhci code lacks a non blocking call to read an event. This causes major problems for the sleep function as well as for ethernet downloads where a keyboard poll for interrupting the download blocks for 5 seconds. ---- Jason Wessel (6): xhci: Add polling support for USB keyboards usb_kbd: succeed even if no interrupt is pending common/usb.c: Work around keyboard reporting "USB device not accepting new address" xhci-ring.c: Add the poll_pend state to properly abort transactions xhci-ring: Fix crash when issuing "usb reset" usb.c: Add a retry in the usb_prepare_device() common/usb.c | 16 +--- common/usb_kbd.c | 4 +++- drivers/usb/host/xhci-ring.c | 123 --- drivers/usb/host/xhci.c | 11 ++- include/usb/xhci.h | 5 +++-- 5 files changed, 121 insertions(+), 38 deletions(-)
[RFC PATCH v3 5/6] xhci-ring: Fix crash when issuing "usb reset"
If a "usb reset" is issued when the poll_pend state is set the
abort_td() function will hit one of the BUG() statements in abort_td()
or the BUG() statement at the end of xhci_wait_for_event().
The controller has been reset, so the rest of the cleanup should be
skipped and poll_pend flag should be cleared.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 1c00f2d496..ed0dea9fca 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -483,6 +483,8 @@ union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl,
trb_type expected,
if (expected == TRB_TRANSFER)
return NULL;
+ if (poll_pend)
+ return NULL;
printf("XHCI timeout on event type %d... cannot recover.\n", expected);
BUG();
}
@@ -505,11 +507,16 @@ static void abort_td(struct usb_device *udev, int
ep_index)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
- field = le32_to_cpu(event->trans_event.flags);
- BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
- BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
- BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len
- != COMP_STOP)));
+ if (event) {
+ field = le32_to_cpu(event->trans_event.flags);
+ BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
+ BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
+ BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len
+!= COMP_STOP)));
+ } else {
+ debug("XHCI abort timeout\n");
+ return;
+ }
xhci_acknowledge_event(ctrl);
event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
--
2.17.1
[RFC PATCH v3 0/6] Improve USB Keyboard support for rpi3/rpi4
At this point all the USB keyboards I had laying around now work and I can USB boot the rpi3 and rpi4, so perhaps this series can move beyond the RFC stage. More testing will occur over the next week or so. v3: - Add in patch 6 - Finally got the GearHead keyboard + mouse composite USB device working v2: - Minor cleanups to patches 1-3 based on prior review - Patch 4 & 5 are new to fix various xhchi crashes while having additional devices plugged in along with booting off the usb port. The nonblocking mode turned out to be somewhat complex. v1: For testing this patch series, I did apply the USB patches for the rpi4 board which had not been merged yet. Once the rpi4 USB changes are eventually merged the keyboard delay issues will show up and I imagine this issue is already a problem for other boards. This series does not depend on rpi4 patches as the changes are in the core USB functions. I performed tests with a number of usb modules attached including storage, ethernet, serial, wifi, keyboard, and mouse without any issues. ---- Jason Wessel (6): xhci: Add polling support for USB keyboards usb_kbd: Do not fail the keyboard if it does not have an interrupt pending common/usb.c: Work around keyboard reporting "USB device not accepting new address" xhci-ring.c: Add the poll_pend state to properly abort transactions xhci-ring: Fix crash when issuing "usb reset" usb.c: Add a retry in the usb_prepare_device() common/usb.c | 18 +--- common/usb_kbd.c | 4 ++- drivers/usb/host/xhci-ring.c | 123 ++-- drivers/usb/host/xhci.c | 11 include/usb/xhci.h | 5 ++-- 5 files changed, 122 insertions(+), 39 deletions(-)
[RFC PATCH v3 1/6] xhci: Add polling support for USB keyboards
The xhci driver was causing intermittent 5 second delays from the USB
keyboard polling hook. Executing something like a "sleep 1" for
example would sleep for 5 seconds, unless an event occurred on
the USB bus to shorten the delay.
Modeled after the code in the DWC2 driver, a nonblock state was added
to quickly return instead of blocking for up to 5 seconds waiting for
an event before timing out.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 26 +-
drivers/usb/host/xhci.c | 11 ++-
include/usb/xhci.h | 5 +++--
3 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 86aeaab412..b7b2e16410 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -432,9 +432,11 @@ static int event_ready(struct xhci_ctrl *ctrl)
*
* @param ctrl Host controller data structure
* @param expected TRB type expected from Event TRB
+ * @param nonblock when true do not block waiting for response
* @return pointer to event trb
*/
-union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected)
+union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected,
+ bool nonblock)
{
trb_type type;
unsigned long ts = get_timer(0);
@@ -442,8 +444,11 @@ union xhci_trb *xhci_wait_for_event(struct xhci_ctrl
*ctrl, trb_type expected)
do {
union xhci_trb *event = ctrl->event_ring->dequeue;
- if (!event_ready(ctrl))
+ if (!event_ready(ctrl)) {
+ if (nonblock)
+ return NULL;
continue;
+ }
type = TRB_FIELD_TO_TYPE(le32_to_cpu(event->event_cmd.flags));
if (type == expected)
@@ -493,7 +498,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
field = le32_to_cpu(event->trans_event.flags);
BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
@@ -501,7 +506,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
!= COMP_STOP)));
xhci_acknowledge_event(ctrl);
- event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
+ event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
!= udev->slot_id || GET_COMP_CODE(le32_to_cpu(
event->event_cmd.status)) != COMP_SUCCESS);
@@ -509,7 +514,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
xhci_queue_command(ctrl, (void *)((uintptr_t)ring->enqueue |
ring->cycle_state), udev->slot_id, ep_index, TRB_SET_DEQ);
- event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
+ event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
!= udev->slot_id || GET_COMP_CODE(le32_to_cpu(
event->event_cmd.status)) != COMP_SUCCESS);
@@ -552,10 +557,11 @@ static void record_transfer_result(struct usb_device
*udev,
* @param pipe contains the DIR_IN or OUT , devnum
* @param length length of the buffer
* @param buffer buffer to be read/written based on the request
+ * @param nonblock when true do not block waiting for response
* @return returns 0 if successful else -1 on failure
*/
int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
- int length, void *buffer)
+ int length, void *buffer, bool nonblock)
{
int num_trbs = 0;
struct xhci_generic_trb *start_trb;
@@ -714,8 +720,10 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, nonblock);
if (!event) {
+ if (nonblock)
+ return -EINVAL;
debug("XHCI bulk transfer timed out, aborting...\n");
abort_td(udev, ep_index);
udev->status = USB_ST_NAK_REC; /* closest thing to a timeout */
@@ -911,7 +919,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
if (!event)
goto abort;
field = le32_to_cpu(event->tra
[RFC PATCH v3 6/6] usb.c: Add a retry in the usb_prepare_device()
I have found through testing some USB 2 composite mouse/keyboard
devices do not response to the usb_set_address call immediately
following the port reset. It can take anywhere from 2ms to 20ms.
This patch adds a retry and delay for usb_prepare_device() and allows
all the USB keyboards I tried to function properly.
Signed-off-by: Jason Wessel
---
common/usb.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/common/usb.c b/common/usb.c
index ba83bb960b..fb091440cc 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1054,6 +1054,15 @@ static int usb_prepare_device(struct usb_device *dev,
int addr, bool do_read,
dev->devnum = addr;
err = usb_set_address(dev); /* set address */
+ /* Retry for old composite keyboard/mouse usb2 hardware */
+ int i = 0;
+ while (err < 0 && i <= 40) {
+ i += 20;
+ mdelay(20);
+ err = usb_set_address(dev); /* set address */
+ }
+ if (i > 0)
+ debug("usb_set_address delay: %i\n", i);
if (err < 0)
debug("\n usb_set_address return < 0\n");
if (err < 0 && dev->status != 0) {
--
2.17.1
[RFC PATCH v3 4/6] xhci-ring.c: Add the poll_pend state to properly abort transactions
xhci_trl_tx and xhchi_bulk_tx can be called synchronously by other
drivers such as the usb storage or network, while the keyboard driver
exclusively uses the polling mode.
And pending polling transactions must be aborted before switching
modes to avoid corrupting the state of the controller.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 86 +---
1 file changed, 70 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index b7b2e16410..1c00f2d496 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -24,6 +24,12 @@
#include
+static void *last_bulk_tx_buf = NULL;
+static struct usb_device *poll_last_udev;
+int poll_last_ep_index;
+static unsigned long bulk_tx_poll_ts = 0;
+static bool poll_pend = false;
+
/**
* Is this TRB a link TRB or was the last TRB the last TRB in this event ring
* segment? I.e. would the updated event TRB pointer step off the end of the
@@ -549,19 +555,8 @@ static void record_transfer_result(struct usb_device *udev,
}
}
-/ Bulk and Control transfer methods /
-/**
- * Queues up the BULK Request
- *
- * @param udev pointer to the USB device structure
- * @param pipe contains the DIR_IN or OUT , devnum
- * @param length length of the buffer
- * @param buffer buffer to be read/written based on the request
- * @param nonblock when true do not block waiting for response
- * @return returns 0 if successful else -1 on failure
- */
-int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
- int length, void *buffer, bool nonblock)
+static int _xhci_bulk_tx_queue(struct usb_device *udev, unsigned long pipe,
+ int length, void *buffer)
{
int num_trbs = 0;
struct xhci_generic_trb *start_trb;
@@ -575,7 +570,6 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
struct xhci_virt_device *virt_dev;
struct xhci_ep_ctx *ep_ctx;
struct xhci_ring *ring; /* EP transfer ring */
- union xhci_trb *event;
int running_total, trb_buff_len;
unsigned int total_packet_count;
@@ -719,20 +713,73 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
} while (running_total < length);
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
+ return 0;
+}
+/ Bulk and Control transfer methods /
+/**
+ * Queues up the BULK Request
+ *
+ * @param udev pointer to the USB device structure
+ * @param pipe contains the DIR_IN or OUT , devnum
+ * @param length length of the buffer
+ * @param buffer buffer to be read/written based on the request
+ * @param nonblock when true do not block waiting for response
+ * @return returns 0 if successful else -1 on failure
+ */
+int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
+ int length, void *buffer, bool nonblock)
+{
+ u32 field;
+ int ret;
+ union xhci_trb *event;
+ struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
+ int ep_index = usb_pipe_ep_index(pipe);
+
+ if (poll_pend) {
+ /*
+* Abort a pending poll operation if it should have
+* timed out, or if this is a different buffer from a
+* separate request
+*/
+ if (get_timer(bulk_tx_poll_ts) > XHCI_TIMEOUT ||
+ last_bulk_tx_buf != buffer || poll_last_udev != udev ||
+ ep_index != poll_last_ep_index) {
+ abort_td(poll_last_udev, poll_last_ep_index);
+ poll_last_udev->status = USB_ST_NAK_REC; /* closest
thing to a timeout */
+ poll_last_udev->act_len = 0;
+ poll_pend = false;
+ }
+ } /* No else here because poll_pend might have changed above */
+ if (!poll_pend) {
+ last_bulk_tx_buf = buffer;
+ ret = _xhci_bulk_tx_queue(udev, pipe, length, buffer);
+ if (ret)
+ return ret;
+ }
event = xhci_wait_for_event(ctrl, TRB_TRANSFER, nonblock);
if (!event) {
- if (nonblock)
+ if (nonblock) {
+ if (!poll_pend) {
+ /* Start the timer */
+ bulk_tx_poll_ts = get_timer(0);
+ poll_last_udev = udev;
+ poll_last_ep_index = ep_index;
+ poll_pend = true;
+ }
return -EINVAL;
+ }
debug("XHCI bulk transfer timed out, aborting...\n");
abort_td(udev, ep_index);
udev->status = USB_ST_NAK_REC; /* closest thing to a timeou
[RFC PATCH v3 3/6] common/usb.c: Work around keyboard reporting "USB device not accepting new address"
When resetting the rpi3 board sometimes it will display:
USB device not accepting new address (error=0)
After the message appears, the usb keyboard will not work. It seems
that the configuration actually did succeed however. Checking the
device status for a return code of zero and continuing allows the usb
keyboard and other usb devices to work function.
Signed-off-by: Jason Wessel
---
common/usb.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index aad13fd9c5..ba83bb960b 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1054,11 +1054,12 @@ static int usb_prepare_device(struct usb_device *dev,
int addr, bool do_read,
dev->devnum = addr;
err = usb_set_address(dev); /* set address */
-
- if (err < 0) {
- printf("\n USB device not accepting new address " \
+ if (err < 0)
+ debug("\n usb_set_address return < 0\n");
+ if (err < 0 && dev->status != 0) {
+ printf("\n USB device not accepting new address " \
"(error=%lX)\n", dev->status);
- return err;
+ return err;
}
mdelay(10); /* Let the SET_ADDRESS settle */
--
2.17.1
[RFC PATCH v3 2/6] usb_kbd: Do not fail the keyboard if it does not have an interrupt pending
After the initial configuration some USB keyboard+mouse devices never
return any kind of event on the interrupt line. In particular, the
device identified by "Cypress Cypress USB Keyboard / PS2 Mouse as
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:04B4:0101.0001/input/input0"
never returns a data packet until the first external input event.
I found this was also true with some newer model Dell keyboards.
When the device is plugged into a xhci controller there is also no
point in waiting 5 seconds for a device that is never going to present
data, so the call to the interrupt service was changed to a
nonblocking operation for the controllers that support this.
With the patch applied, the rpi3 and rpi4 work well with the more
complex keyboard devices.
Signed-off-by: Jason Wessel
---
common/usb_kbd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index b316807844..3c0056e1b9 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -519,7 +519,9 @@ static int usb_kbd_probe_dev(struct usb_device *dev,
unsigned int ifnum)
1, 0, data->new, USB_KBD_BOOT_REPORT_SIZE) < 0) {
#else
if (usb_int_msg(dev, data->intpipe, data->new, data->intpktsize,
- data->intinterval, false) < 0) {
+ data->intinterval, true) < 0) {
+ /* Read first packet if the device provides it, else pick it up
later */
+ return 1;
#endif
printf("Failed to get keyboard state from device %04x:%04x\n",
dev->descriptor.idVendor, dev->descriptor.idProduct);
--
2.17.1
[RFC PATCH v2 4/5] xhci-ring.c: Add the poll_pend state to properly abort transactions
xhci_trl_tx and xhchi_bulk_tx can be called synchronously by other
drivers such as the usb storage or network, while the keyboard driver
exclusively uses the polling mode.
And pending polling transactions must be aborted before switching
modes to avoid corrupting the state of the controller.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 86 +---
1 file changed, 70 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index b7b2e16410..1c00f2d496 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -24,6 +24,12 @@
#include
+static void *last_bulk_tx_buf = NULL;
+static struct usb_device *poll_last_udev;
+int poll_last_ep_index;
+static unsigned long bulk_tx_poll_ts = 0;
+static bool poll_pend = false;
+
/**
* Is this TRB a link TRB or was the last TRB the last TRB in this event ring
* segment? I.e. would the updated event TRB pointer step off the end of the
@@ -549,19 +555,8 @@ static void record_transfer_result(struct usb_device *udev,
}
}
-/ Bulk and Control transfer methods /
-/**
- * Queues up the BULK Request
- *
- * @param udev pointer to the USB device structure
- * @param pipe contains the DIR_IN or OUT , devnum
- * @param length length of the buffer
- * @param buffer buffer to be read/written based on the request
- * @param nonblock when true do not block waiting for response
- * @return returns 0 if successful else -1 on failure
- */
-int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
- int length, void *buffer, bool nonblock)
+static int _xhci_bulk_tx_queue(struct usb_device *udev, unsigned long pipe,
+ int length, void *buffer)
{
int num_trbs = 0;
struct xhci_generic_trb *start_trb;
@@ -575,7 +570,6 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
struct xhci_virt_device *virt_dev;
struct xhci_ep_ctx *ep_ctx;
struct xhci_ring *ring; /* EP transfer ring */
- union xhci_trb *event;
int running_total, trb_buff_len;
unsigned int total_packet_count;
@@ -719,20 +713,73 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
} while (running_total < length);
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
+ return 0;
+}
+/ Bulk and Control transfer methods /
+/**
+ * Queues up the BULK Request
+ *
+ * @param udev pointer to the USB device structure
+ * @param pipe contains the DIR_IN or OUT , devnum
+ * @param length length of the buffer
+ * @param buffer buffer to be read/written based on the request
+ * @param nonblock when true do not block waiting for response
+ * @return returns 0 if successful else -1 on failure
+ */
+int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
+ int length, void *buffer, bool nonblock)
+{
+ u32 field;
+ int ret;
+ union xhci_trb *event;
+ struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
+ int ep_index = usb_pipe_ep_index(pipe);
+
+ if (poll_pend) {
+ /*
+* Abort a pending poll operation if it should have
+* timed out, or if this is a different buffer from a
+* separate request
+*/
+ if (get_timer(bulk_tx_poll_ts) > XHCI_TIMEOUT ||
+ last_bulk_tx_buf != buffer || poll_last_udev != udev ||
+ ep_index != poll_last_ep_index) {
+ abort_td(poll_last_udev, poll_last_ep_index);
+ poll_last_udev->status = USB_ST_NAK_REC; /* closest
thing to a timeout */
+ poll_last_udev->act_len = 0;
+ poll_pend = false;
+ }
+ } /* No else here because poll_pend might have changed above */
+ if (!poll_pend) {
+ last_bulk_tx_buf = buffer;
+ ret = _xhci_bulk_tx_queue(udev, pipe, length, buffer);
+ if (ret)
+ return ret;
+ }
event = xhci_wait_for_event(ctrl, TRB_TRANSFER, nonblock);
if (!event) {
- if (nonblock)
+ if (nonblock) {
+ if (!poll_pend) {
+ /* Start the timer */
+ bulk_tx_poll_ts = get_timer(0);
+ poll_last_udev = udev;
+ poll_last_ep_index = ep_index;
+ poll_pend = true;
+ }
return -EINVAL;
+ }
debug("XHCI bulk transfer timed out, aborting...\n");
abort_td(udev, ep_index);
udev->status = USB_ST_NAK_REC; /* closest thing to a timeou
[RFC PATCH v2 5/5] xhci-ring: Fix crash when issuing "usb reset"
If a "usb reset" is issued when the poll_pend state is set the
abort_td() function will hit one of the BUG() statements in abort_td()
or the BUG() statement at the end of xhci_wait_for_event().
The controller has been reset, so the rest of the cleanup should be
skipped and poll_pend flag should be cleared.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 1c00f2d496..ed0dea9fca 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -483,6 +483,8 @@ union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl,
trb_type expected,
if (expected == TRB_TRANSFER)
return NULL;
+ if (poll_pend)
+ return NULL;
printf("XHCI timeout on event type %d... cannot recover.\n", expected);
BUG();
}
@@ -505,11 +507,16 @@ static void abort_td(struct usb_device *udev, int
ep_index)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
- field = le32_to_cpu(event->trans_event.flags);
- BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
- BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
- BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len
- != COMP_STOP)));
+ if (event) {
+ field = le32_to_cpu(event->trans_event.flags);
+ BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
+ BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
+ BUG_ON(GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len
+!= COMP_STOP)));
+ } else {
+ debug("XHCI abort timeout\n");
+ return;
+ }
xhci_acknowledge_event(ctrl);
event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
--
2.17.1
[RFC PATCH v2 3/5] common/usb.c: Work around keyboard reporting "USB device not accepting new address"
When resetting the rpi3 board sometimes it will display:
USB device not accepting new address (error=0)
After the message appears, the usb keyboard will not work. It seems
that the configuration actually did succeed however. Checking the
device status for a return code of zero and continuing allows the usb
keyboard and other usb devices to work function.
Signed-off-by: Jason Wessel
---
common/usb.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index aad13fd9c5..ba83bb960b 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1054,11 +1054,12 @@ static int usb_prepare_device(struct usb_device *dev,
int addr, bool do_read,
dev->devnum = addr;
err = usb_set_address(dev); /* set address */
-
- if (err < 0) {
- printf("\n USB device not accepting new address " \
+ if (err < 0)
+ debug("\n usb_set_address return < 0\n");
+ if (err < 0 && dev->status != 0) {
+ printf("\n USB device not accepting new address " \
"(error=%lX)\n", dev->status);
- return err;
+ return err;
}
mdelay(10); /* Let the SET_ADDRESS settle */
--
2.17.1
[RFC PATCH v2 0/5] Improve USB Keyboard support for rpi3/rpi4
v2: - Minor cleanups to patches 1-3 based on prior review - Patch 4 & 5 are new to fix various xhchi crashes while having additional devices plugged in along with booting off the usb port. The nonblocking mode turned out to be somewhat complex. v1: For testing this patch series, I did apply the USB patches for the rpi4 board which had not been merged yet. Once the rpi4 USB changes are eventually merged the keyboard delay issues will show up and I imagine this issue is already a problem for other boards. This series does not depend on rpi4 patches as the changes are in the core USB functions. I am not entirely certain about the change to the common/usb.c which is why this is an RFC. I am not sure if there would be other side effects to other USB drivers. I did test with a number of usb modules attached including storage, ethernet, serial, wifi, keyboard, and mouse without any issues. ---- Jason Wessel (5): xhci: Add polling support for USB keyboards usb_kbd: Do not fail the keyboard if it does not have an interrupt pending common/usb.c: Work around keyboard reporting "USB device not accepting new address" xhci-ring.c: Add the poll_pend state to properly abort transactions xhci-ring: Fix crash when issuing "usb reset" common/usb.c | 9 +++--- common/usb_kbd.c | 4 ++- drivers/usb/host/xhci-ring.c | 123 ++-- drivers/usb/host/xhci.c | 11 include/usb/xhci.h | 5 ++-- 5 files changed, 113 insertions(+), 39 deletions(-)
[RFC PATCH v2 2/5] usb_kbd: Do not fail the keyboard if it does not have an interrupt pending
After the initial configuration some USB keyboard+mouse devices never
return any kind of event on the interrupt line. In particular, the
device identified by "Cypress Cypress USB Keyboard / PS2 Mouse as
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:04B4:0101.0001/input/input0"
never returns a data packet until the first external input event.
I found this was also true with some newer model Dell keyboards.
When the device is plugged into a xhci controller there is also no
point in waiting 5 seconds for a device that is never going to present
data, so the call to the interrupt service was changed to a
nonblocking operation for the controllers that support this.
With the patch applied, the rpi3 and rpi4 work well with the more
complex keyboard devices.
Signed-off-by: Jason Wessel
---
common/usb_kbd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index b316807844..3c0056e1b9 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -519,7 +519,9 @@ static int usb_kbd_probe_dev(struct usb_device *dev,
unsigned int ifnum)
1, 0, data->new, USB_KBD_BOOT_REPORT_SIZE) < 0) {
#else
if (usb_int_msg(dev, data->intpipe, data->new, data->intpktsize,
- data->intinterval, false) < 0) {
+ data->intinterval, true) < 0) {
+ /* Read first packet if the device provides it, else pick it up
later */
+ return 1;
#endif
printf("Failed to get keyboard state from device %04x:%04x\n",
dev->descriptor.idVendor, dev->descriptor.idProduct);
--
2.17.1
[RFC PATCH v2 1/5] xhci: Add polling support for USB keyboards
The xhci driver was causing intermittent 5 second delays from the USB
keyboard polling hook. Executing something like a "sleep 1" for
example would sleep for 5 seconds, unless an event occurred on
the USB bus to shorten the delay.
Modeled after the code in the DWC2 driver, a nonblock state was added
to quickly return instead of blocking for up to 5 seconds waiting for
an event before timing out.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 26 +-
drivers/usb/host/xhci.c | 11 ++-
include/usb/xhci.h | 5 +++--
3 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 86aeaab412..b7b2e16410 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -432,9 +432,11 @@ static int event_ready(struct xhci_ctrl *ctrl)
*
* @param ctrl Host controller data structure
* @param expected TRB type expected from Event TRB
+ * @param nonblock when true do not block waiting for response
* @return pointer to event trb
*/
-union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected)
+union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected,
+ bool nonblock)
{
trb_type type;
unsigned long ts = get_timer(0);
@@ -442,8 +444,11 @@ union xhci_trb *xhci_wait_for_event(struct xhci_ctrl
*ctrl, trb_type expected)
do {
union xhci_trb *event = ctrl->event_ring->dequeue;
- if (!event_ready(ctrl))
+ if (!event_ready(ctrl)) {
+ if (nonblock)
+ return NULL;
continue;
+ }
type = TRB_FIELD_TO_TYPE(le32_to_cpu(event->event_cmd.flags));
if (type == expected)
@@ -493,7 +498,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
field = le32_to_cpu(event->trans_event.flags);
BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
@@ -501,7 +506,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
!= COMP_STOP)));
xhci_acknowledge_event(ctrl);
- event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
+ event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
!= udev->slot_id || GET_COMP_CODE(le32_to_cpu(
event->event_cmd.status)) != COMP_SUCCESS);
@@ -509,7 +514,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
xhci_queue_command(ctrl, (void *)((uintptr_t)ring->enqueue |
ring->cycle_state), udev->slot_id, ep_index, TRB_SET_DEQ);
- event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
+ event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
!= udev->slot_id || GET_COMP_CODE(le32_to_cpu(
event->event_cmd.status)) != COMP_SUCCESS);
@@ -552,10 +557,11 @@ static void record_transfer_result(struct usb_device
*udev,
* @param pipe contains the DIR_IN or OUT , devnum
* @param length length of the buffer
* @param buffer buffer to be read/written based on the request
+ * @param nonblock when true do not block waiting for response
* @return returns 0 if successful else -1 on failure
*/
int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
- int length, void *buffer)
+ int length, void *buffer, bool nonblock)
{
int num_trbs = 0;
struct xhci_generic_trb *start_trb;
@@ -714,8 +720,10 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, nonblock);
if (!event) {
+ if (nonblock)
+ return -EINVAL;
debug("XHCI bulk transfer timed out, aborting...\n");
abort_td(udev, ep_index);
udev->status = USB_ST_NAK_REC; /* closest thing to a timeout */
@@ -911,7 +919,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
if (!event)
goto abort;
field = le32_to_cpu(event->tra
[RFC PATCH 1/3] xhci: Add polling support for USB keyboards
The xhci driver was causing intermittent 5 second delays from the USB
keyboard polling hook. Executing something like a "sleep 1" for
example would sleep for 5 seconds, unless an event occurred on
the USB bus to shorten the delay.
Modeled after the code in the DWC2 driver, a nonblock state was added
to quickly return instead of blocking for up to 5 seconds waiting for
an event before timing out.
Signed-off-by: Jason Wessel
---
drivers/usb/host/xhci-ring.c | 24 +++-
drivers/usb/host/xhci.c | 10 +-
include/usb/xhci.h | 5 +++--
3 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 86aeaab412..1f7b3a8e0b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -434,7 +434,8 @@ static int event_ready(struct xhci_ctrl *ctrl)
* @param expected TRB type expected from Event TRB
* @return pointer to event trb
*/
-union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected)
+union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected,
+ bool nonblock)
{
trb_type type;
unsigned long ts = get_timer(0);
@@ -442,8 +443,11 @@ union xhci_trb *xhci_wait_for_event(struct xhci_ctrl
*ctrl, trb_type expected)
do {
union xhci_trb *event = ctrl->event_ring->dequeue;
- if (!event_ready(ctrl))
+ if (!event_ready(ctrl)) {
+ if (nonblock)
+ return NULL;
continue;
+ }
type = TRB_FIELD_TO_TYPE(le32_to_cpu(event->event_cmd.flags));
if (type == expected)
@@ -493,7 +497,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
field = le32_to_cpu(event->trans_event.flags);
BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
@@ -501,7 +505,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
!= COMP_STOP)));
xhci_acknowledge_event(ctrl);
- event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
+ event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
!= udev->slot_id || GET_COMP_CODE(le32_to_cpu(
event->event_cmd.status)) != COMP_SUCCESS);
@@ -509,7 +513,7 @@ static void abort_td(struct usb_device *udev, int ep_index)
xhci_queue_command(ctrl, (void *)((uintptr_t)ring->enqueue |
ring->cycle_state), udev->slot_id, ep_index, TRB_SET_DEQ);
- event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
+ event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
!= udev->slot_id || GET_COMP_CODE(le32_to_cpu(
event->event_cmd.status)) != COMP_SUCCESS);
@@ -555,7 +559,7 @@ static void record_transfer_result(struct usb_device *udev,
* @return returns 0 if successful else -1 on failure
*/
int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
- int length, void *buffer)
+ int length, void *buffer, bool nonblock)
{
int num_trbs = 0;
struct xhci_generic_trb *start_trb;
@@ -714,8 +718,10 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
pipe,
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, nonblock);
if (!event) {
+ if (nonblock)
+ return -EINVAL;
debug("XHCI bulk transfer timed out, aborting...\n");
abort_td(udev, ep_index);
udev->status = USB_ST_NAK_REC; /* closest thing to a timeout */
@@ -911,7 +917,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
giveback_first_trb(udev, ep_index, start_cycle, start_trb);
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+ event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
if (!event)
goto abort;
field = le32_to_cpu(event->trans_event.flags);
@@ -929,7 +935,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
if (GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len))
== COMP_SHORT_TX) {
/* Short data stage, clear up additional status stage event */
- event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
+
[RFC PATCH 2/3] usb_kbd: Do not fail the keyboard if it does not have an interrupt pending
After the initial configuration some USB keyboard+mouse devices never
return any kind of event on the interrupt line. In particular, the
device identified by "Cypress Cypress USB Keyboard / PS2 Mouse as
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:04B4:0101.0001/input/input0"
never returns a data packet until the first external input event.
I found this was also true with some newer model Dell keyboards.
When the device is plugged into a xhci controller there is also no
point in waiting 5 seconds for a device that is never going to present
data, so the call to the interrupt service was changed to a
nonblocking operation for the controllers that support this.
With the patch applied, the rpi3 and rpi4 work well with the more
complex keyboard devices.
Signed-off-by: Jason Wessel
---
common/usb_kbd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index b316807844..3c0056e1b9 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -519,7 +519,9 @@ static int usb_kbd_probe_dev(struct usb_device *dev,
unsigned int ifnum)
1, 0, data->new, USB_KBD_BOOT_REPORT_SIZE) < 0) {
#else
if (usb_int_msg(dev, data->intpipe, data->new, data->intpktsize,
- data->intinterval, false) < 0) {
+ data->intinterval, true) < 0) {
+ /* Read first packet if the device provides it, else pick it up
later */
+ return 1;
#endif
printf("Failed to get keyboard state from device %04x:%04x\n",
dev->descriptor.idVendor, dev->descriptor.idProduct);
--
2.17.1
[RFC PATCH 3/3] common/usb.c: Work around keyboard reporting "USB device not accepting new address"
When resetting the rpi3 board sometimes it will display:
USB device not accepting new address (error=0)
After the message appears, the usb keyboard will not work. It seems
that the configuration actually did succeed however. Checking the
device status for a return code of zero and continuing allows the usb
keyboard and other usb devices to work function.
Signed-off-by: Jason Wessel
---
common/usb.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index aad13fd9c5..2f7f205444 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1054,11 +1054,13 @@ static int usb_prepare_device(struct usb_device *dev,
int addr, bool do_read,
dev->devnum = addr;
err = usb_set_address(dev); /* set address */
-
- if (err < 0) {
- printf("\n USB device not accepting new address " \
+ if (err < 0)
+ debug("\n usb_set_address return < 0\n");
+ if (err < 0 && dev->status != 0) {
+ printf("\n USB device not accepting new address " \
"(error=%lX)\n", dev->status);
- return err;
+ if (dev->status != 0)
+ return err;
}
mdelay(10); /* Let the SET_ADDRESS settle */
--
2.17.1
[RFC PATCH 0/3] Improve USB Keyboard support for rpi3/rpi4
For testing this patch series, I did apply the USB patches for the rpi4 board which had not been merged yet. Once the rpi4 USB changes are eventually merged the keyboard delay issues will show up and I imagine this issue is already a problem for other boards. This series does not depend on rpi4 patches as the changes are in the core USB functions. I am not entirely certain about the change to the common/usb.c which is why this is an RFC. I am not sure if there would be other side effects to other USB drivers. I did test with a number of usb modules attached including storage, ethernet, serial, wifi, keyboard, and mouse without any issues. Jason Wessel (3): xhci: Add polling support for USB keyboards usb_kbd: Do not fail the keyboard if it does not have an interrupt pending common/usb.c: Work around keyboard reporting "USB device not accepting new address" common/usb.c | 10 ++ common/usb_kbd.c | 4 +++- drivers/usb/host/xhci-ring.c | 24 +++- drivers/usb/host/xhci.c | 10 +- include/usb/xhci.h | 5 +++-- 5 files changed, 32 insertions(+), 21 deletions(-)
[PATCH v3] fs/fat/fat.c: Do not perform zero block reads if there are no blocks left
While using u-boot with qemu's virtio driver I stumbled across a
problem reading files less than sector size. On the real hardware the
block reader seems ok with reading zero blocks, and while we could fix
the virtio host side of qemu to deal with a zero block read instead of
crashing, the u-boot fat driver should not be doing zero block reads
in the first place. If you ask hardware to read zero blocks you are
just going to get zero data. There may also be other hardware that
responds similarly to the virtio interface so this is worth fixing.
Without the patch I get the following and have to restart qemu because
it dies.
-
=> fatls virtio 0:1
30 cmdline.txt
=> fatload virtio 0:1 ${loadaddr} cmdline.txt
qemu-system-aarch64: virtio: zero sized buffers are not allowed
-
With the patch I get the expected results.
-
=> fatls virtio 0:1
30 cmdline.txt
=> fatload virtio 0:1 ${loadaddr} cmdline.txt
30 bytes read in 11 ms (2 KiB/s)
=> md.b ${loadaddr} 0x1E
4008: 64 77 63 5f 6f 74 67 2e 6c 70 6d 5f 65 6e 61 62dwc_otg.lpm_enab
40080010: 6c 65 3d 30 20 72 6f 6f 74 77 61 69 74 0a le=0 rootwait.
-----
Signed-off-by: Jason Wessel
Signed-off-by: Jason Wessel
---
fs/fat/fat.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 7fd29470c1..dfad1e910b 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -278,7 +278,10 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
unsigned long size)
}
} else {
idx = size / mydata->sect_size;
- ret = disk_read(startsect, idx, buffer);
+ if (idx == 0)
+ ret = 0;
+ else
+ ret = disk_read(startsect, idx, buffer);
if (ret != idx) {
debug("Error reading data (got %d)\n", ret);
return -1;
--
2.17.1
[PATCH] fs/fat/fat.c: Do not perform zero block reads if there are no blocks left
v2: Fix indentation and remove unneeded braces.
While using u-boot with qemu's virtio driver I stumbled across a
problem reading files less than sector size. On the real hardware the
block reader seems ok with reading zero blocks, and while we could fix
the virtio host side of qemu to deal with a zero block read instead of
crashing, the u-boot fat driver should not be doing zero block reads
in the first place. If you ask hardware to read zero blocks you are
just going to get zero data. There may also be other hardware that
responds similarly to the virtio interface so this is worth fixing.
Without the patch I get the following and have to restart qemu because
it dies.
-
=> fatls virtio 0:1
30 cmdline.txt
=> fatload virtio 0:1 ${loadaddr} cmdline.txt
qemu-system-aarch64: virtio: zero sized buffers are not allowed
-
With the patch I get the expected results.
-
=> fatls virtio 0:1
30 cmdline.txt
=> fatload virtio 0:1 ${loadaddr} cmdline.txt
30 bytes read in 11 ms (2 KiB/s)
=> md.b ${loadaddr} 0x1E
4008: 64 77 63 5f 6f 74 67 2e 6c 70 6d 5f 65 6e 61 62dwc_otg.lpm_enab
40080010: 6c 65 3d 30 20 72 6f 6f 74 77 61 69 74 0a le=0 rootwait.
-----
Signed-off-by: Jason Wessel
---
fs/fat/fat.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 7fd29470c1..8233a74620 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -278,7 +278,11 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
unsigned long size)
}
} else {
idx = size / mydata->sect_size;
- ret = disk_read(startsect, idx, buffer);
+ if (idx == 0) {
+ ret = 0;
+ } else {
+ ret = disk_read(startsect, idx, buffer);
+ }
if (ret != idx) {
debug("Error reading data (got %d)\n", ret);
return -1;
--
2.17.1
[PATCH] fs/fat.c: Do not perform zero block reads if there are no blocks left
While using u-boot with qemu's virtio driver I stumbled across a
problem reading files less than sector size. On the real hardware the
block reader seems ok with reading zero blocks, and while we could fix
the virtio host side of qemu to deal with a zero block read instead of
crashing, the u-boot fat driver should not be doing zero block reads
in the first place. If you ask hardware to read zero blocks you are
just going to get zero data. There may also be other hardware that
responds similarly to the virtio interface so this is worth fixing.
Without the patch I get the following and have to restart qemu because
it dies.
-
=> fatls virtio 0:1
30 cmdline.txt
=> fatload virtio 0:1 ${loadaddr} cmdline.txt
qemu-system-aarch64: virtio: zero sized buffers are not allowed
-
With the patch I get the expected results.
-
=> fatls virtio 0:1
30 cmdline.txt
=> fatload virtio 0:1 ${loadaddr} cmdline.txt
30 bytes read in 11 ms (2 KiB/s)
=> md.b ${loadaddr} 0x1E
4008: 64 77 63 5f 6f 74 67 2e 6c 70 6d 5f 65 6e 61 62dwc_otg.lpm_enab
40080010: 6c 65 3d 30 20 72 6f 6f 74 77 61 69 74 0a le=0 rootwait.
-----
Signed-off-by: Jason Wessel
---
fs/fat/fat.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 7fd29470c1..8233a74620 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -278,7 +278,11 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
unsigned long size)
}
} else {
idx = size / mydata->sect_size;
- ret = disk_read(startsect, idx, buffer);
+ if (idx == 0) {
+ ret = 0;
+ } else {
+ ret = disk_read(startsect, idx, buffer);
+ }
if (ret != idx) {
debug("Error reading data (got %d)\n", ret);
return -1;
--
2.17.1
[PATCH] fs/fat.c: Do not perform zero block reads if there are no blocks left
While using u-boot with qemu's virtio driver I stumbled across a
problem reading files less than sector size. On the real hardware the
block reader seems ok with reading zero blocks, and while we could fix
the virtio host side of qemu to deal with a zero block read instead of
crashing, the u-boot fat driver should not be doing zero block reads
in the first place. If you ask hardware to read zero blocks you are
just going to get zero data. There may also be other hardware that
responds similarly to the virtio interface so this is worth fixing.
Without the patch I get the following and have to restart qemu because
it dies.
-
=> fatls virtio 0:1
30 cmdline.txt
=> fatload virtio 0:1 ${loadaddr} cmdline.txt
qemu-system-aarch64: virtio: zero sized buffers are not allowed
-
With the patch I get the expected results.
-
=> fatls virtio 0:1
30 cmdline.txt
=> fatload virtio 0:1 ${loadaddr} cmdline.txt
30 bytes read in 11 ms (2 KiB/s)
=> md.b ${loadaddr} 0x1E
4008: 64 77 63 5f 6f 74 67 2e 6c 70 6d 5f 65 6e 61 62dwc_otg.lpm_enab
40080010: 6c 65 3d 30 20 72 6f 6f 74 77 61 69 74 0a le=0 rootwait.
-----
Signed-off-by: Jason Wessel
---
fs/fat/fat.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 7fd29470c1..8233a74620 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -278,7 +278,11 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
unsigned long size)
}
} else {
idx = size / mydata->sect_size;
- ret = disk_read(startsect, idx, buffer);
+ if (idx == 0) {
+ ret = 0;
+ } else {
+ ret = disk_read(startsect, idx, buffer);
+ }
if (ret != idx) {
debug("Error reading data (got %d)\n", ret);
return -1;
--
2.17.1
RE: [PATCH v3 1/2] mtd: rawnand: ca_nand: add Cortina Access Parallel NAND controller support
Hi Miquel/Tom, >> Hi Alex, >> >> Alex Nemirovsky wrote on Mon, 1 >> Jun 2020 14:26:49 -0700: >> >> > From: Jason Li >> > >> > Supports all CA SoCs which support a parallel nand controller. >> > It should be noted that some CA Soc also support an separate >> > SPI serial NAND controller. >> > >> > This driver only supports the parallel NAND controller. A different >> > driver supports the SPI NAND interface controller. >> > >> > Signed-off-by: Jason Li >> > Signed-off-by: Alex Nemirovsky >> > >> > CC: Miquel Raynal >> > CC: Simon Glass >> > CC: Tom Rini >> > --- >> > >> > Changes in v3: >> > - Include udelay.h to avoid implicit declaration of udelay() >> > >> > Changes in v2: >> > - Cleanup code style to pass checkpatch.pl >> > >> > MAINTAINERS|2 + >> > drivers/mtd/nand/raw/Kconfig | 31 + >> > drivers/mtd/nand/raw/Makefile |1 + >> > drivers/mtd/nand/raw/ca_nand.c | 4943 >> > >> > drivers/mtd/nand/raw/ca_nand.h | 3899 +++ >> >> This is insanely big ! >> >> > 5 files changed, 8876 insertions(+) >> > create mode 100644 drivers/mtd/nand/raw/ca_nand.c >> > create mode 100644 drivers/mtd/nand/raw/ca_nand.h >> > >> > diff --git a/MAINTAINERS b/MAINTAINERS >> > index 8add9d4..6da2ad8 100644 >> > --- a/MAINTAINERS >> > +++ b/MAINTAINERS >> > @@ -181,6 +181,8 @@ F: drivers/gpio/cortina_gpio.c >> > F:drivers/watchdog/cortina_wdt.c >> > F:drivers/serial/serial_cortina.c >> > F:drivers/mmc/ca_dw_mmc.c >> > +F:drivers/mtd/nand/raw/ca_nand.c >> > +F:drivers/mtd/nand/raw/ca_nand.h >> > >> > ARM/CZ.NIC TURRIS MOX SUPPORT >> > M:Marek Behun >> > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig >> > index c4d9d31..b3cbfcc 100644 >> > --- a/drivers/mtd/nand/raw/Kconfig >> > +++ b/drivers/mtd/nand/raw/Kconfig >> > @@ -102,6 +102,37 @@ config NAND_BRCMNAND_63158 >> > help >> > Enable support for broadcom nand driver on bcm63158. >> > >> > +config NAND_CORTINA >> > +tristate "Support Cortina-Access Parallel NAND cntlr." >> > + select SYS_NAND_SELF_INIT >> >> Alignment looks wrong >> >> > +help >> > + This enables the parallel RAW NAND driver for the >> > +Cortina-Access CA Family of SoCs. >> > + >> > +config NAND_CORTINA_ECC_LEVEL >> > +int "Cortina-Access Parallel Nand driver HW ECC algorithm" >> > +default 3 >> > +range 0 5 >> > +depends on NAND_CORTINA >> > +help >> > + NAND Flash ECC algorithm. Value range from 0 to 5. >> > + The default value is 3. >> > + >> > + 0: Hamming algorithm. Correct 3 bad bits in 256 btyes. >> > + 1: Hamming algorithm. Correct 3 bad bits in 512 btyes. >> > + 2: BCH algorithm. Correct 8 bad bits in 1K btyes. >> > + 3: BCH algorithm. Correct 16 bad bits in 1K btyes. >> > + 4: BCH algorithm. Correct 24 bad bits in 1K btyes. >> > + 5: BCH algorithm. Correct 40 bad bits in 1K btyes. >> >> Not sure how u-boot guys want to handle this but the current way to >> request for a specif correction is to pass nand-ecc-strength and >> nand-ecc-size DT properties. If the driver does not support the >> requested properties, there is a function (at least in Linux) which >> finds the closest correction called nand_ecc_choose_conf(), provided >> that you implemented a few specific hooks in your driver. > >We have drivers making use of those properties too, so this one should >as well. Thanks! > >-- >Tom Since DTB is separate image from u-boot. If we put these information in DTB. What ECC algorithm should be applied when read DTB from flash? Could you guide more detail. Thanks, Jason
RE: [PATCH 8/8] imx: convert mx53loco board to DM_VIDEO
> -Original Message- > From: Anatolij Gustschin > Sent: Tuesday, May 26, 2020 7:42 AM > To: u-boot@lists.denx.de > Cc: Jason Liu > Subject: [PATCH 8/8] imx: convert mx53loco board to DM_VIDEO > > Migration to DM_VIDEO driver is long overdue. Update defconfig to enable > usage of converted ipuv3 driver DM configuration. > > Signed-off-by: Anatolij Gustschin > Cc: Jason Liu > --- > configs/mx53loco_defconfig | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) Acked-by: Jason Liu > > diff --git a/configs/mx53loco_defconfig b/configs/mx53loco_defconfig index > e5d842a75d..40fab2016c 100644 > --- a/configs/mx53loco_defconfig > +++ b/configs/mx53loco_defconfig > @@ -37,7 +37,12 @@ CONFIG_USB_HOST_ETHER=y > CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_MCS7830=y > CONFIG_USB_ETHER_SMSC95XX=y > +CONFIG_DM_VIDEO=y > CONFIG_VIDEO_IPUV3=y > -CONFIG_VIDEO=y > -# CONFIG_VIDEO_SW_CURSOR is not set > +# CONFIG_BACKLIGHT is not set > +# CONFIG_VIDEO_BPP8 is not set > +# CONFIG_VIDEO_BPP32 is not set > +# CONFIG_VIDEO_ANSI is not set > +# CONFIG_PANEL is not set > +CONFIG_SYS_WHITE_ON_BLACK=y > CONFIG_OF_LIBFDT=y > -- > 2.17.1
Re: [U-Boot] [PATCH] spl_mmc: always use find_mmc_device() to get mmc handler
Hi,
We use the aliases to set the MMC device order. For example:
mmc0 = &emmc;
mmc1 = &sdmmc;
These define the MMC order in block layer.
But in the mmc layer, the MMC device order is defined in the dts MMC node.
It may make mistake to get MMC device order. So if we use the block layer
interface to
access mmc devices, use find_mmc_device to get current devnum but not
uclass_get_device.
Thanks and regards,
Jason
jason@rock-chips.com
From: Lokesh Vutla
Date: 2019-07-25 18:39
To: Kever Yang; u-boot@lists.denx.de
CC: jason@rock-chips.com; Marek Vasut; Tien Fong Chee; Peng Fan
Subject: Re: [U-Boot] [PATCH] spl_mmc: always use find_mmc_device() to get mmc
handler
+Peng
Hi Kever,
On 25/07/19 3:10 PM, Kever Yang wrote:
> Like cmd/mmc.c, the spl_mmc.c are using block driver interface
> like blk_dread() to access mmc devices, we need to get the mmc device
> handler by block driver interface so that we can always get correct
> device number, eg. the alias may change the device number which make
> the device number different in UCLASS_MMC list and UCLASS_BLK list.
>
> Signed-off-by: Kever Yang
> ---
>
> common/spl/spl_mmc.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index b3619889f7..3a93e20f04 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -113,9 +113,6 @@ static int spl_mmc_get_device_index(u32 boot_device)
>
> static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device)
> {
> -#if CONFIG_IS_ENABLED(DM_MMC)
> - struct udevice *dev;
> -#endif
> int err, mmc_dev;
>
> mmc_dev = spl_mmc_get_device_index(boot_device);
> @@ -130,14 +127,8 @@ static int spl_mmc_find_device(struct mmc **mmcp, u32
> boot_device)
> return err;
> }
>
> -#if CONFIG_IS_ENABLED(DM_MMC)
> - err = uclass_get_device(UCLASS_MMC, mmc_dev, &dev);
> - if (!err)
> - *mmcp = mmc_get_mmc_dev(dev);
> -#else
> *mmcp = find_mmc_device(mmc_dev);
> err = *mmcp ? 0 : -ENODEV;
> -#endif
I am not against the change but trying to understand what is the problem you
faced. mmc_initialize() would have initialized the devices based on the seq
number that is provided in DT. So in your case shouldn't uclass_get_device give
the right device or something else triggered this patch?
Also we are facing a different problem with mmc_initialize(). Very early in boot
there is no access to any peripheral other than boot peripheral(Need system co
processor to enable peripherals). There are 2 MMC controllers in our devices.
So, SD boot is failing while loading system firmware as mmc_initialize is trying
to probe both the controllers. In SPL, shouldn't we just probe the needed
controller instead of calling mmc_initialize?
Thanks and regards,
Lokesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [v3, 3/5] Convert to use fsl_esdhc_imx for i.MX platforms
> -Original Message- > From: Y.b. Lu > Sent: Tuesday, May 21, 2019 4:52 PM > To: u-boot@lists.denx.de > Cc: Stefano Babic ; Fabio Estevam ; > dl-uboot-imx ; Albert Aribaud > ; Eddy Petrișor ; > Akshay Bhat ; Ken Lin > ; Heiko Schocher ; Christian > Gmeiner ; Stefan Roese ; Patrick > Bruenn ; Troy Kisky > ; Uri Mashiach > ; Nikita Kiryanov ; > Otavio Salvador ; Andreas Geisreiter > ; Ludwig Zenz ; Eric > Bénard ; Peng Fan ; Jason Liu > ; Ye Li ; Adrian Alonso > ; Alison Wang ; > thar...@gateworks.com; Ian Ray ; Marcin Niestroj > ; Andrej Rosano ; > Marek Vasut ; Lukasz Majewski ; Adam > Ford ; Olaf Mandel ; > Martyn Welch ; Ingo Schroeck > ; Boris Brezillon > ; Soeren Moch ; > Richard Hu ; Vanessa Maegima > ; Max Krummenacher > ; Stefan Agner > ; Markus Niebel ; > Breno Matheus Lima ; Francesco Montefoschi > ; Parthiban Nallathambi > ; Albert ARIBAUD ; Jagan Teki > ; Raffaele RECALCATI > ; Simone CIANNI ; > Bhaskar Upadhaya ; Vinitha V Pillai > ; Prabhakar Kushwaha > ; Rajesh Bhagat ; > Antti Mäentausta ; Sébastien Szymanski > ; Lucile Quirion > ; Alexey Brodkin > ; Trevor Woerner ; Anatolij > Gustschin ; Denis Zalevskiy ; Fabien > Lahoudere ; Joe Hershberger > ; Simon Goldschmidt > ; James Byrne > ; Angelo Dureghello ; Y.b. > Lu > Subject: [v3, 3/5] Convert to use fsl_esdhc_imx for i.MX platforms > > Converted to use fsl_esdhc_imx for i.MX platforms. > > Signed-off-by: Yangbo Lu > --- > Changes for v2: > - Rebased. > Changes for v3: > - Rebased. > --- > arch/arm/cpu/arm1136/mx35/generic.c | 10 +- > arch/arm/cpu/arm926ejs/mx25/generic.c | 8 > arch/arm/cpu/armv7/vf610/generic.c| 10 +- > arch/arm/cpu/armv8/s32v234/generic.c | 2 +- > arch/arm/include/asm/global_data.h| 2 +- > arch/arm/mach-imx/cpu.c | 6 +++--- > arch/arm/mach-imx/mx6/litesom.c | 4 ++-- > arch/arm/mach-imx/mx7/clock.c | 4 ++-- > arch/arm/mach-imx/mx7ulp/clock.c | 2 +- > arch/arm/mach-imx/speed.c | 4 ++-- > board/advantech/dms-ba16/dms-ba16.c | 4 ++-- > board/aristainetos/aristainetos-v1.c | 2 +- > board/aristainetos/aristainetos-v2.c | 2 +- > board/aristainetos/aristainetos.c | 4 ++-- > board/bachmann/ot1200/ot1200.c| 2 +- > board/barco/platinum/platinum.c | 2 +- > board/barco/titanium/titanium.c | 4 ++-- > board/beckhoff/mx53cx9020/mx53cx9020.c| 4 ++-- > board/boundary/nitrogen6x/nitrogen6x.c| 4 ++-- > board/ccv/xpress/xpress.c | 2 +- > board/compulab/cl-som-imx7/cl-som-imx7.c | 6 +++--- > board/compulab/cl-som-imx7/common.c | 6 +++--- > board/compulab/cl-som-imx7/common.h | 8 > board/compulab/cl-som-imx7/mux.c | 8 > board/compulab/cl-som-imx7/spl.c | 6 +++--- > board/compulab/cm_fx6/cm_fx6.c| 4 ++-- > board/compulab/cm_fx6/common.c| 4 ++-- > board/compulab/cm_fx6/spl.c | 2 +- > board/congatec/cgtqmx6eval/cgtqmx6eval.c | 4 ++-- > board/dhelectronics/dh_imx6/dh_imx6.c | 4 ++-- > board/dhelectronics/dh_imx6/dh_imx6_spl.c | 2 +- > board/el/el6x/el6x.c | 4 ++-- > board/embest/mx6boards/mx6boards.c| 4 ++-- > board/freescale/imx8mq_evk/imx8mq_evk.c | 2 +- > board/freescale/imx8mq_evk/spl.c | 2 +- > board/freescale/imx8qxp_mek/imx8qxp_mek.c | 2 +- > board/freescale/mx25pdk/mx25pdk.c | 6 +++--- > board/freescale/mx35pdk/mx35pdk.c | 4 ++-- > board/freescale/mx51evk/mx51evk.c | 6 +++--- > board/freescale/mx53ard/mx53ard.c | 4 ++-- > board/freescale/mx53evk/mx53evk.c | 4 ++-- > board/freescale/mx53loco/mx53loco.c | 4 ++-- > board/freescale/mx53smd/mx53smd.c | 4 ++-- > board/freescale/mx6qarm2/mx6qarm2.c | 4 ++-- > board/freescale/mx6sabreauto/mx6sabreauto.c | 4 ++-- > board/freescale/mx6sabresd/mx6sabresd.c | 4 ++-- > board/freescale/mx6slevk/mx6slevk.c | 2 +- > board/freescale/mx6sxsabreauto/mx6sxsabreauto.c | 2 +- > board/freescale/mx6sxsabresd/mx6sxsabresd.c | 2 +- > board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c | 4 ++-- > board/freesc
Re: [U-Boot] [v3, 1/5] Move CONFIG_FSL_ESDHC to defconfig
> -Original Message- > From: Y.b. Lu > Sent: Tuesday, May 21, 2019 4:52 PM > To: u-boot@lists.denx.de > Cc: Stefano Babic ; Fabio Estevam ; > dl-uboot-imx ; Albert Aribaud > ; Eddy Petrișor ; > Akshay Bhat ; Ken Lin > ; Heiko Schocher ; Christian > Gmeiner ; Stefan Roese ; Patrick > Bruenn ; Troy Kisky > ; Uri Mashiach > ; Nikita Kiryanov ; > Otavio Salvador ; Andreas Geisreiter > ; Ludwig Zenz ; Eric > Bénard ; Peng Fan ; Jason Liu > ; Ye Li ; Adrian Alonso > ; Alison Wang ; > thar...@gateworks.com; Ian Ray ; Marcin Niestroj > ; Andrej Rosano ; > Marek Vasut ; Lukasz Majewski ; Adam > Ford ; Olaf Mandel ; > Martyn Welch ; Ingo Schroeck > ; Boris Brezillon > ; Soeren Moch ; > Richard Hu ; Vanessa Maegima > ; Max Krummenacher > ; Stefan Agner > ; Markus Niebel ; > Breno Matheus Lima ; Francesco Montefoschi > ; Parthiban Nallathambi > ; Albert ARIBAUD ; Jagan Teki > ; Raffaele RECALCATI > ; Simone CIANNI ; > Bhaskar Upadhaya ; Vinitha V Pillai > ; Prabhakar Kushwaha > ; Rajesh Bhagat ; > Antti Mäentausta ; Sébastien Szymanski > ; Lucile Quirion > ; Alexey Brodkin > ; Trevor Woerner ; Anatolij > Gustschin ; Denis Zalevskiy ; Fabien > Lahoudere ; Joe Hershberger > ; Simon Goldschmidt > ; James Byrne > ; Angelo Dureghello ; Y.b. > Lu > Subject: [v3, 1/5] Move CONFIG_FSL_ESDHC to defconfig > > Moved CONFIG_FSL_ESDHC from header files to defconfig files. > > Signed-off-by: Yangbo Lu > --- > Changes for v2: > - Rebased. > Changes for v3: > - Rebased. > --- > configs/imx8mq_evk_defconfig | 1 + > configs/imx8qm_mek_defconfig | 1 + > configs/imx8qxp_mek_defconfig | 1 + > configs/kp_imx6q_tpc_defconfig | 1 + > configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig | 1 + > configs/ls1012afrwy_qspi_defconfig | 1 + > configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig | 1 + > configs/ls1012afrwy_tfa_defconfig | 1 + > include/configs/imx8mq_evk.h | 1 - > include/configs/imx8qm_mek.h | 1 - > include/configs/imx8qxp_mek.h | 1 - > include/configs/kp_imx6q_tpc.h | 1 - > include/configs/ls1012afrwy.h | 1 - > 13 files changed, 8 insertions(+), 5 deletions(-) Acked-by: Jason Liu > > -- > 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 7/11/2018 1:54 PM, Marek Vasut wrote: > On 07/11/2018 07:30 PM, Trent Piepho wrote: >> On Wed, 2018-07-11 at 08:56 -0500, Jason Rush wrote: >>> On 7/11/2018 8:48 AM, Marek Vasut wrote: >>>> On 07/11/2018 03:49 PM, Jason Rush wrote: >>>>> My mistake. I did disable the dcache after scrubbing too. The >>>>> code is almost identical to the Arria10 code where after >>>>> scrubbing it flushes the dcache, then turns it off. >>>>> >>>>> The weird reset problems happens if I scrub the area where >>>>> u-boot relocates to with the dcache on, then turn dcache off. >>>>> >>>>> I tried to also tried turning the MMU off, but that didn't help. >>>> Maybe there are some data used by the SPL there ? I think the SPL has >>>> malloc area in RAM at some point. >>>> >>> I thought something similar, so I narrowed it down to clearing >>> just from where U-Boot relocates to the end of DRAM. If I'm >>> correct, that includes where U-Boot relocates and where the >>> MMU tables are normally stored. >> I wonder if the reset does not properly reset the CPU caches? The idea >> being that the CPU cache has stale data from before the reset, or maybe >> just stale tag bits, and the hang is due to using this bad data from >> the cache. > That's why we do dcache_off() icache_off() first, to make sure the > caches are in consistent state. But a good point nonetheless, this > should be checked. I call dcache_off() and icache_off() after scrubbing, and I verified the MMU control register indicated they were off. >> Or perhaps there is always something done incorrectly, but it is only >> the state of DRAM after a reset, vs a power cycle, that consistently >> triggers a hang? > The SoCFPGA has some weird warm/cold reset hooks even in the bootrom, > could be. But the DRAM should be torn down in either case. Maybe there is something wrong with the reset hooks? I could try and clear the on chip RAM after U-Boot relocates just to see what happens. Or there is probably an enable for the hooks I could try and disable. >> If possible, try to add code before the hang point to invalidate both >> the i-cache and d-cache for the problem region above. Perhaps the SPL >> is doing something wrong w.r.t. cache invalidation, e.g. moving code >> around and not updating the i-cache, because it assumes nothing has yet >> used the caches, which is now no longer the case since you turn them on >> for scrubbing. >> After scrubbing I first call flush_dcache_all(), then I added calls to invalidate_icache_all() and invalidate_dcache_all(), and finally I call dcache_off() and icache_off(). I wasn't sure about the order I should call them, but there was no change. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 7/11/2018 8:48 AM, Marek Vasut wrote: > On 07/11/2018 03:49 PM, Jason Rush wrote: >> On 7/11/2018 3:55 AM, Marek Vasut wrote: >>> On 07/11/2018 05:11 AM, Jason Rush wrote: >>> [...] >>> >>>>>>>> However, if I press the HPS_RST push button on the SoCKit (which is >>>>>>>> connected >>>>>>>> to power on reset), occasionally U-Boot will lock up while booting. >>>>>>>> It always >>>>>>>> boots and operates correctly from the initial power on, but it almost >>>>>>>> always >>>>>>>> fails to boot after pressing the HPS_RST button. >>>>>>>> >>>>>>>> Usually after pressing the HPS_RST button, U-Boot makes it past the >>>>>>>> SPL, and >>>>>>>> hangs somewhere after the call to setup_reloc() in ./common/board_f.c. >>>>>>>> Once >>>>>>>> it hangs there, pressing the HPS_RST button again usually causes the >>>>>>>> SPL to >>>>>>>> hang while setting up the MMU (before my call to memset). Eventually >>>>>>>> the >>>>>>>> WDT kicks in, and it just keeps hanging up in the same place. Once it >>>>>>>> gets in >>>>>>>> this mode, the only way to recover it is by toggling power on the >>>>>>>> board. >>>>>>>> >>>>>>>> I spent a bunch of time today trying to track down where it was >>>>>>>> hanging, but >>>>>>>> I couldn't pin point anything. The MMU tables looked correct. The MMU >>>>>>>> registers looked good. I'm not sure the best way to debug what's >>>>>>>> going on. >>>>>>> Try triggering warm reset and cold reset via the reset register: >>>>>>> >>>>>>> mw 0xffd05004 1 >>>>>>> mw 0xffd05004 2 >>>>>>> >>>>>>> Does it hang in one case and not in the other ? >>>>>>> >>>>>> It hangs in both cases. >>>>>> >>>>>> I did find that if I do not metset the last 1MiB of DRAM with the cache >>>>>> on, >>>>>> both warm and cold resets work. >>>>>> >>>>>> I changed the ecc scrubbing to zero out the first 0x8000 bytes and the >>>>>> last >>>>>> 0x1 bytes before the MMU is setup and I enable dcache. Then with >>>>>> the dcache enabled, I zero out the rest of memory. The resets work in >>>>>> this >>>>>> case as well. So there seems to be some side effect of clearing out the >>>>>> relocate address space with the cache on. >>>>> Can you investigate ? >>>>> >>>> I'd be happy to investigate more, but I'm not really sure what >>>> my next step should be. >>>> >>>> Something appears to be happening differently when U-Boot >>>> relocates if the dcache is on. But don't know how to track it >>>> down. >>> IIRC I disabled cache after scrubbing. >> My mistake. I did disable the dcache after scrubbing too. The >> code is almost identical to the Arria10 code where after >> scrubbing it flushes the dcache, then turns it off. >> >> The weird reset problems happens if I scrub the area where >> u-boot relocates to with the dcache on, then turn dcache off. >> >> I tried to also tried turning the MMU off, but that didn't help. > Maybe there are some data used by the SPL there ? I think the SPL has > malloc area in RAM at some point. > I thought something similar, so I narrowed it down to clearing just from where U-Boot relocates to the end of DRAM. If I'm correct, that includes where U-Boot relocates and where the MMU tables are normally stored. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 7/11/2018 3:55 AM, Marek Vasut wrote: > On 07/11/2018 05:11 AM, Jason Rush wrote: > [...] > >>>>>> However, if I press the HPS_RST push button on the SoCKit (which is >>>>>> connected >>>>>> to power on reset), occasionally U-Boot will lock up while booting. It >>>>>> always >>>>>> boots and operates correctly from the initial power on, but it almost >>>>>> always >>>>>> fails to boot after pressing the HPS_RST button. >>>>>> >>>>>> Usually after pressing the HPS_RST button, U-Boot makes it past the SPL, >>>>>> and >>>>>> hangs somewhere after the call to setup_reloc() in ./common/board_f.c. >>>>>> Once >>>>>> it hangs there, pressing the HPS_RST button again usually causes the SPL >>>>>> to >>>>>> hang while setting up the MMU (before my call to memset). Eventually the >>>>>> WDT kicks in, and it just keeps hanging up in the same place. Once it >>>>>> gets in >>>>>> this mode, the only way to recover it is by toggling power on the board. >>>>>> >>>>>> I spent a bunch of time today trying to track down where it was hanging, >>>>>> but >>>>>> I couldn't pin point anything. The MMU tables looked correct. The MMU >>>>>> registers looked good. I'm not sure the best way to debug what's going >>>>>> on. >>>>> Try triggering warm reset and cold reset via the reset register: >>>>> >>>>> mw 0xffd05004 1 >>>>> mw 0xffd05004 2 >>>>> >>>>> Does it hang in one case and not in the other ? >>>>> >>>> It hangs in both cases. >>>> >>>> I did find that if I do not metset the last 1MiB of DRAM with the cache on, >>>> both warm and cold resets work. >>>> >>>> I changed the ecc scrubbing to zero out the first 0x8000 bytes and the last >>>> 0x1 bytes before the MMU is setup and I enable dcache. Then with >>>> the dcache enabled, I zero out the rest of memory. The resets work in this >>>> case as well. So there seems to be some side effect of clearing out the >>>> relocate address space with the cache on. >>> Can you investigate ? >>> >> I'd be happy to investigate more, but I'm not really sure what >> my next step should be. >> >> Something appears to be happening differently when U-Boot >> relocates if the dcache is on. But don't know how to track it >> down. > IIRC I disabled cache after scrubbing. My mistake. I did disable the dcache after scrubbing too. The code is almost identical to the Arria10 code where after scrubbing it flushes the dcache, then turns it off. The weird reset problems happens if I scrub the area where u-boot relocates to with the dcache on, then turn dcache off. I tried to also tried turning the MMU off, but that didn't help. >> I was thinking I might dump the DRAM where U-Boot relocates >> to both with the dcache on and off, and see if there are any >> differences. I'm not really sure what that tells me though if I >> find a difference. >> >> Any suggestions? >> >> Regards, >> Jason >> > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 7/10/2018 11:11 AM, Marek Vasut wrote: > On 07/10/2018 02:10 PM, Jason Rush wrote: >> On 7/9/2018 3:08 AM, Marek Vasut wrote: >>> On 07/07/2018 12:56 AM, Jason Rush wrote: >>>> On 7/5/2018 6:10 PM, Marek Vasut wrote: >>>>> On 07/06/2018 01:11 AM, Jason Rush wrote: >>>>>> On 7/4/2018 2:23 AM, Marek Vasut wrote: >>>>>>> On 07/04/2018 01:45 AM, Jason Rush wrote: >>>>>>>> On 7/3/2018 9:08 AM, Marek Vasut wrote: >>>>>>>>> On 07/03/2018 03:58 PM, Jason Rush wrote: >>>>>>>>>> On 6/29/2018 10:17 AM, Marek Vasut wrote: >>>>>>>>>>> On 06/29/2018 05:06 PM, Jason Rush wrote: >>>>>>>>>>>> On 6/29/2018 9:52 AM, Marek Vasut wrote: >>>>>>>>>>>>> On 06/29/2018 04:44 PM, Jason Rush wrote: >>>>>>>>>>>>>> On 6/29/2018 9:34 AM, Marek Vasut wrote: >>>>>>>>>>>>>>> On 06/29/2018 04:31 PM, Jason Rush wrote: >>>>>>>>>>>>>>>> Dinh, >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A while ago, you posted the following patchset for SoCFPGA to >>>>>>>>>>>>>>>> add the PL330 >>>>>>>>>>>>>>>> DMA driver, and updated the SoCFPGA SDRAM init to write zeros >>>>>>>>>>>>>>>> to SDRAM to >>>>>>>>>>>>>>>> initialize the ECC bits if ECC was enabled: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://lists.denx.de/pipermail/u-boot/2016-October/269643.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I know it's been a long time, so I'll summarize some of the >>>>>>>>>>>>>>>> conversation... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> At the time, you had a problem with the patchset causing the >>>>>>>>>>>>>>>> SPL to fail to >>>>>>>>>>>>>>>> find the MMC. You had tracked it down to an issue with the >>>>>>>>>>>>>>>> following commit >>>>>>>>>>>>>>>> "a78cd8613204 ARM: Rework and correct barrier definitions". >>>>>>>>>>>>>>>> You and Marek >>>>>>>>>>>>>>>> discussed it a bit, but I don't think there was a real >>>>>>>>>>>>>>>> conclusion. You >>>>>>>>>>>>>>>> submitted a second version of the patchset asking for advice >>>>>>>>>>>>>>>> on debugging >>>>>>>>>>>>>>>> the issue: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://lists.denx.de/pipermail/u-boot/2016-December/275822.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> No real conversation came from the second patchset, and that >>>>>>>>>>>>>>>> was the end of >>>>>>>>>>>>>>>> the patch. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I was hoping we could revisit adding your patchset again. I am >>>>>>>>>>>>>>>> working on a >>>>>>>>>>>>>>>> custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased >>>>>>>>>>>>>>>> your patchset >>>>>>>>>>>>>>>> against v2018.05 and it is working on my custom board >>>>>>>>>>>>>>>> (although I don't have >>>>>>>>>>>>>>>> an MMC). I also tested it on a SoCKit booting from an MMC (I >>>>>>>>>>>>>>>> forced it to >>>>
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 7/9/2018 3:08 AM, Marek Vasut wrote: > On 07/07/2018 12:56 AM, Jason Rush wrote: >> On 7/5/2018 6:10 PM, Marek Vasut wrote: >>> On 07/06/2018 01:11 AM, Jason Rush wrote: >>>> On 7/4/2018 2:23 AM, Marek Vasut wrote: >>>>> On 07/04/2018 01:45 AM, Jason Rush wrote: >>>>>> On 7/3/2018 9:08 AM, Marek Vasut wrote: >>>>>>> On 07/03/2018 03:58 PM, Jason Rush wrote: >>>>>>>> On 6/29/2018 10:17 AM, Marek Vasut wrote: >>>>>>>>> On 06/29/2018 05:06 PM, Jason Rush wrote: >>>>>>>>>> On 6/29/2018 9:52 AM, Marek Vasut wrote: >>>>>>>>>>> On 06/29/2018 04:44 PM, Jason Rush wrote: >>>>>>>>>>>> On 6/29/2018 9:34 AM, Marek Vasut wrote: >>>>>>>>>>>>> On 06/29/2018 04:31 PM, Jason Rush wrote: >>>>>>>>>>>>>> Dinh, >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>>> A while ago, you posted the following patchset for SoCFPGA to >>>>>>>>>>>>>> add the PL330 >>>>>>>>>>>>>> DMA driver, and updated the SoCFPGA SDRAM init to write zeros to >>>>>>>>>>>>>> SDRAM to >>>>>>>>>>>>>> initialize the ECC bits if ECC was enabled: >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://lists.denx.de/pipermail/u-boot/2016-October/269643.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> I know it's been a long time, so I'll summarize some of the >>>>>>>>>>>>>> conversation... >>>>>>>>>>>>>> >>>>>>>>>>>>>> At the time, you had a problem with the patchset causing the SPL >>>>>>>>>>>>>> to fail to >>>>>>>>>>>>>> find the MMC. You had tracked it down to an issue with the >>>>>>>>>>>>>> following commit >>>>>>>>>>>>>> "a78cd8613204 ARM: Rework and correct barrier definitions". You >>>>>>>>>>>>>> and Marek >>>>>>>>>>>>>> discussed it a bit, but I don't think there was a real >>>>>>>>>>>>>> conclusion. You >>>>>>>>>>>>>> submitted a second version of the patchset asking for advice on >>>>>>>>>>>>>> debugging >>>>>>>>>>>>>> the issue: >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://lists.denx.de/pipermail/u-boot/2016-December/275822.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> No real conversation came from the second patchset, and that was >>>>>>>>>>>>>> the end of >>>>>>>>>>>>>> the patch. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I was hoping we could revisit adding your patchset again. I am >>>>>>>>>>>>>> working on a >>>>>>>>>>>>>> custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased >>>>>>>>>>>>>> your patchset >>>>>>>>>>>>>> against v2018.05 and it is working on my custom board (although >>>>>>>>>>>>>> I don't have >>>>>>>>>>>>>> an MMC). I also tested it on a SoCKit booting from an MMC (I >>>>>>>>>>>>>> forced it to >>>>>>>>>>>>>> scrub the SDRAM on the SoCKit, because it doesn't have ECC RAM), >>>>>>>>>>>>>> and the >>>>>>>>>>>>>> SoCKit finds the MMC and boots. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't have any suggestions on why it is working now on my >>>>>>>>>>>>>> board and not >>&g
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 7/5/2018 6:10 PM, Marek Vasut wrote: > On 07/06/2018 01:11 AM, Jason Rush wrote: >> On 7/4/2018 2:23 AM, Marek Vasut wrote: >>> On 07/04/2018 01:45 AM, Jason Rush wrote: >>>> On 7/3/2018 9:08 AM, Marek Vasut wrote: >>>>> On 07/03/2018 03:58 PM, Jason Rush wrote: >>>>>> On 6/29/2018 10:17 AM, Marek Vasut wrote: >>>>>>> On 06/29/2018 05:06 PM, Jason Rush wrote: >>>>>>>> On 6/29/2018 9:52 AM, Marek Vasut wrote: >>>>>>>>> On 06/29/2018 04:44 PM, Jason Rush wrote: >>>>>>>>>> On 6/29/2018 9:34 AM, Marek Vasut wrote: >>>>>>>>>>> On 06/29/2018 04:31 PM, Jason Rush wrote: >>>>>>>>>>>> Dinh, >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>>> A while ago, you posted the following patchset for SoCFPGA to add >>>>>>>>>>>> the PL330 >>>>>>>>>>>> DMA driver, and updated the SoCFPGA SDRAM init to write zeros to >>>>>>>>>>>> SDRAM to >>>>>>>>>>>> initialize the ECC bits if ECC was enabled: >>>>>>>>>>>> >>>>>>>>>>>> https://lists.denx.de/pipermail/u-boot/2016-October/269643.html >>>>>>>>>>>> >>>>>>>>>>>> I know it's been a long time, so I'll summarize some of the >>>>>>>>>>>> conversation... >>>>>>>>>>>> >>>>>>>>>>>> At the time, you had a problem with the patchset causing the SPL >>>>>>>>>>>> to fail to >>>>>>>>>>>> find the MMC. You had tracked it down to an issue with the >>>>>>>>>>>> following commit >>>>>>>>>>>> "a78cd8613204 ARM: Rework and correct barrier definitions". You >>>>>>>>>>>> and Marek >>>>>>>>>>>> discussed it a bit, but I don't think there was a real conclusion. >>>>>>>>>>>> You >>>>>>>>>>>> submitted a second version of the patchset asking for advice on >>>>>>>>>>>> debugging >>>>>>>>>>>> the issue: >>>>>>>>>>>> >>>>>>>>>>>> https://lists.denx.de/pipermail/u-boot/2016-December/275822.html >>>>>>>>>>>> >>>>>>>>>>>> No real conversation came from the second patchset, and that was >>>>>>>>>>>> the end of >>>>>>>>>>>> the patch. >>>>>>>>>>>> >>>>>>>>>>>> I was hoping we could revisit adding your patchset again. I am >>>>>>>>>>>> working on a >>>>>>>>>>>> custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased >>>>>>>>>>>> your patchset >>>>>>>>>>>> against v2018.05 and it is working on my custom board (although I >>>>>>>>>>>> don't have >>>>>>>>>>>> an MMC). I also tested it on a SoCKit booting from an MMC (I >>>>>>>>>>>> forced it to >>>>>>>>>>>> scrub the SDRAM on the SoCKit, because it doesn't have ECC RAM), >>>>>>>>>>>> and the >>>>>>>>>>>> SoCKit finds the MMC and boots. >>>>>>>>>>>> >>>>>>>>>>>> I don't have any suggestions on why it is working now on my board >>>>>>>>>>>> and not >>>>>>>>>>>> back when you first submitted the patchset. Maybe something else >>>>>>>>>>>> was fixed >>>>>>>>>>>> in the MMC? I was hoping you and Marek could test this patch again >>>>>>>>>>>> on some >>>>>>>>>>>> different SoCFPGA boards to see if you get the same results. >>>>>>>>>>> Look at this patch >>>>>>>>&g
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 7/5/2018 6:10 PM, Marek Vasut wrote: > On 07/06/2018 01:11 AM, Jason Rush wrote: >> On 7/4/2018 2:23 AM, Marek Vasut wrote: >>> On 07/04/2018 01:45 AM, Jason Rush wrote: >>>> On 7/3/2018 9:08 AM, Marek Vasut wrote: >>>>> On 07/03/2018 03:58 PM, Jason Rush wrote: >>>>>> On 6/29/2018 10:17 AM, Marek Vasut wrote: >>>>>>> On 06/29/2018 05:06 PM, Jason Rush wrote: >>>>>>>> On 6/29/2018 9:52 AM, Marek Vasut wrote: >>>>>>>>> On 06/29/2018 04:44 PM, Jason Rush wrote: >>>>>>>>>> On 6/29/2018 9:34 AM, Marek Vasut wrote: >>>>>>>>>>> On 06/29/2018 04:31 PM, Jason Rush wrote: >>>>>>>>>>>> Dinh, >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>>> A while ago, you posted the following patchset for SoCFPGA to add >>>>>>>>>>>> the PL330 >>>>>>>>>>>> DMA driver, and updated the SoCFPGA SDRAM init to write zeros to >>>>>>>>>>>> SDRAM to >>>>>>>>>>>> initialize the ECC bits if ECC was enabled: >>>>>>>>>>>> >>>>>>>>>>>> https://lists.denx.de/pipermail/u-boot/2016-October/269643.html >>>>>>>>>>>> >>>>>>>>>>>> I know it's been a long time, so I'll summarize some of the >>>>>>>>>>>> conversation... >>>>>>>>>>>> >>>>>>>>>>>> At the time, you had a problem with the patchset causing the SPL >>>>>>>>>>>> to fail to >>>>>>>>>>>> find the MMC. You had tracked it down to an issue with the >>>>>>>>>>>> following commit >>>>>>>>>>>> "a78cd8613204 ARM: Rework and correct barrier definitions". You >>>>>>>>>>>> and Marek >>>>>>>>>>>> discussed it a bit, but I don't think there was a real conclusion. >>>>>>>>>>>> You >>>>>>>>>>>> submitted a second version of the patchset asking for advice on >>>>>>>>>>>> debugging >>>>>>>>>>>> the issue: >>>>>>>>>>>> >>>>>>>>>>>> https://lists.denx.de/pipermail/u-boot/2016-December/275822.html >>>>>>>>>>>> >>>>>>>>>>>> No real conversation came from the second patchset, and that was >>>>>>>>>>>> the end of >>>>>>>>>>>> the patch. >>>>>>>>>>>> >>>>>>>>>>>> I was hoping we could revisit adding your patchset again. I am >>>>>>>>>>>> working on a >>>>>>>>>>>> custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased >>>>>>>>>>>> your patchset >>>>>>>>>>>> against v2018.05 and it is working on my custom board (although I >>>>>>>>>>>> don't have >>>>>>>>>>>> an MMC). I also tested it on a SoCKit booting from an MMC (I >>>>>>>>>>>> forced it to >>>>>>>>>>>> scrub the SDRAM on the SoCKit, because it doesn't have ECC RAM), >>>>>>>>>>>> and the >>>>>>>>>>>> SoCKit finds the MMC and boots. >>>>>>>>>>>> >>>>>>>>>>>> I don't have any suggestions on why it is working now on my board >>>>>>>>>>>> and not >>>>>>>>>>>> back when you first submitted the patchset. Maybe something else >>>>>>>>>>>> was fixed >>>>>>>>>>>> in the MMC? I was hoping you and Marek could test this patch again >>>>>>>>>>>> on some >>>>>>>>>>>> different SoCFPGA boards to see if you get the same results. >>>>>>>>>>> Look at this patch >>>>>>>>&g
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 7/4/2018 2:23 AM, Marek Vasut wrote: > On 07/04/2018 01:45 AM, Jason Rush wrote: >> On 7/3/2018 9:08 AM, Marek Vasut wrote: >>> On 07/03/2018 03:58 PM, Jason Rush wrote: >>>> On 6/29/2018 10:17 AM, Marek Vasut wrote: >>>>> On 06/29/2018 05:06 PM, Jason Rush wrote: >>>>>> On 6/29/2018 9:52 AM, Marek Vasut wrote: >>>>>>> On 06/29/2018 04:44 PM, Jason Rush wrote: >>>>>>>> On 6/29/2018 9:34 AM, Marek Vasut wrote: >>>>>>>>> On 06/29/2018 04:31 PM, Jason Rush wrote: >>>>>>>>>> Dinh, >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>>> A while ago, you posted the following patchset for SoCFPGA to add >>>>>>>>>> the PL330 >>>>>>>>>> DMA driver, and updated the SoCFPGA SDRAM init to write zeros to >>>>>>>>>> SDRAM to >>>>>>>>>> initialize the ECC bits if ECC was enabled: >>>>>>>>>> >>>>>>>>>> https://lists.denx.de/pipermail/u-boot/2016-October/269643.html >>>>>>>>>> >>>>>>>>>> I know it's been a long time, so I'll summarize some of the >>>>>>>>>> conversation... >>>>>>>>>> >>>>>>>>>> At the time, you had a problem with the patchset causing the SPL to >>>>>>>>>> fail to >>>>>>>>>> find the MMC. You had tracked it down to an issue with the >>>>>>>>>> following commit >>>>>>>>>> "a78cd8613204 ARM: Rework and correct barrier definitions". You and >>>>>>>>>> Marek >>>>>>>>>> discussed it a bit, but I don't think there was a real conclusion. >>>>>>>>>> You >>>>>>>>>> submitted a second version of the patchset asking for advice on >>>>>>>>>> debugging >>>>>>>>>> the issue: >>>>>>>>>> >>>>>>>>>> https://lists.denx.de/pipermail/u-boot/2016-December/275822.html >>>>>>>>>> >>>>>>>>>> No real conversation came from the second patchset, and that was the >>>>>>>>>> end of >>>>>>>>>> the patch. >>>>>>>>>> >>>>>>>>>> I was hoping we could revisit adding your patchset again. I am >>>>>>>>>> working on a >>>>>>>>>> custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased your >>>>>>>>>> patchset >>>>>>>>>> against v2018.05 and it is working on my custom board (although I >>>>>>>>>> don't have >>>>>>>>>> an MMC). I also tested it on a SoCKit booting from an MMC (I forced >>>>>>>>>> it to >>>>>>>>>> scrub the SDRAM on the SoCKit, because it doesn't have ECC RAM), and >>>>>>>>>> the >>>>>>>>>> SoCKit finds the MMC and boots. >>>>>>>>>> >>>>>>>>>> I don't have any suggestions on why it is working now on my board >>>>>>>>>> and not >>>>>>>>>> back when you first submitted the patchset. Maybe something else >>>>>>>>>> was fixed >>>>>>>>>> in the MMC? I was hoping you and Marek could test this patch again >>>>>>>>>> on some >>>>>>>>>> different SoCFPGA boards to see if you get the same results. >>>>>>>>> Look at this patch >>>>>>>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=9bb8a249b292d26f152c20e3641600b3d7b3924b >>>>>>>>> >>>>>>>>> You likely want similar approach, it's faster then the DMA and much >>>>>>>>> simpler. >>>>>>>>> >>>>>>>> Thanks Marek. I'll give it a try. Would you be interested in a >>>>>>>> similar patch for the Gen 5? >>>>>>> I don't have any Gen5 board which uses ECC, do yo
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 7/3/2018 9:08 AM, Marek Vasut wrote: > On 07/03/2018 03:58 PM, Jason Rush wrote: >> On 6/29/2018 10:17 AM, Marek Vasut wrote: >>> On 06/29/2018 05:06 PM, Jason Rush wrote: >>>> On 6/29/2018 9:52 AM, Marek Vasut wrote: >>>>> On 06/29/2018 04:44 PM, Jason Rush wrote: >>>>>> On 6/29/2018 9:34 AM, Marek Vasut wrote: >>>>>>> On 06/29/2018 04:31 PM, Jason Rush wrote: >>>>>>>> Dinh, >>>>>>> Hi, >>>>>>> >>>>>>>> A while ago, you posted the following patchset for SoCFPGA to add the >>>>>>>> PL330 >>>>>>>> DMA driver, and updated the SoCFPGA SDRAM init to write zeros to SDRAM >>>>>>>> to >>>>>>>> initialize the ECC bits if ECC was enabled: >>>>>>>> >>>>>>>> https://lists.denx.de/pipermail/u-boot/2016-October/269643.html >>>>>>>> >>>>>>>> I know it's been a long time, so I'll summarize some of the >>>>>>>> conversation... >>>>>>>> >>>>>>>> At the time, you had a problem with the patchset causing the SPL to >>>>>>>> fail to >>>>>>>> find the MMC. You had tracked it down to an issue with the following >>>>>>>> commit >>>>>>>> "a78cd8613204 ARM: Rework and correct barrier definitions". You and >>>>>>>> Marek >>>>>>>> discussed it a bit, but I don't think there was a real conclusion. You >>>>>>>> submitted a second version of the patchset asking for advice on >>>>>>>> debugging >>>>>>>> the issue: >>>>>>>> >>>>>>>> https://lists.denx.de/pipermail/u-boot/2016-December/275822.html >>>>>>>> >>>>>>>> No real conversation came from the second patchset, and that was the >>>>>>>> end of >>>>>>>> the patch. >>>>>>>> >>>>>>>> I was hoping we could revisit adding your patchset again. I am working >>>>>>>> on a >>>>>>>> custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased your >>>>>>>> patchset >>>>>>>> against v2018.05 and it is working on my custom board (although I >>>>>>>> don't have >>>>>>>> an MMC). I also tested it on a SoCKit booting from an MMC (I forced it >>>>>>>> to >>>>>>>> scrub the SDRAM on the SoCKit, because it doesn't have ECC RAM), and >>>>>>>> the >>>>>>>> SoCKit finds the MMC and boots. >>>>>>>> >>>>>>>> I don't have any suggestions on why it is working now on my board and >>>>>>>> not >>>>>>>> back when you first submitted the patchset. Maybe something else was >>>>>>>> fixed >>>>>>>> in the MMC? I was hoping you and Marek could test this patch again on >>>>>>>> some >>>>>>>> different SoCFPGA boards to see if you get the same results. >>>>>>> Look at this patch >>>>>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=9bb8a249b292d26f152c20e3641600b3d7b3924b >>>>>>> >>>>>>> You likely want similar approach, it's faster then the DMA and much >>>>>>> simpler. >>>>>>> >>>>>> Thanks Marek. I'll give it a try. Would you be interested in a similar >>>>>> patch for the Gen 5? >>>>> I don't have any Gen5 board which uses ECC, do you ? >>>>> If so, yes, prepare a patch, it should be very similar. >>>>> >>>>> Make sure to measure how long it takes to scrub the memory and how much >>>>> memory you have, I'd be interested in the numbers. >>>>> >>>> Looking at the master branch, it doesn't look like that code is ever being >>>> called? >>>> The sdram_init_ecc_bits() function is called from the >>>> ddr_calibration_sequence function(), >>>> but I can't find where ddr_calibration_sequence is called(). >>> git grep for it, it's call
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 6/29/2018 10:17 AM, Marek Vasut wrote: > On 06/29/2018 05:06 PM, Jason Rush wrote: >> On 6/29/2018 9:52 AM, Marek Vasut wrote: >>> On 06/29/2018 04:44 PM, Jason Rush wrote: >>>> On 6/29/2018 9:34 AM, Marek Vasut wrote: >>>>> On 06/29/2018 04:31 PM, Jason Rush wrote: >>>>>> Dinh, >>>>> Hi, >>>>> >>>>>> A while ago, you posted the following patchset for SoCFPGA to add the >>>>>> PL330 >>>>>> DMA driver, and updated the SoCFPGA SDRAM init to write zeros to SDRAM to >>>>>> initialize the ECC bits if ECC was enabled: >>>>>> >>>>>> https://lists.denx.de/pipermail/u-boot/2016-October/269643.html >>>>>> >>>>>> I know it's been a long time, so I'll summarize some of the >>>>>> conversation... >>>>>> >>>>>> At the time, you had a problem with the patchset causing the SPL to fail >>>>>> to >>>>>> find the MMC. You had tracked it down to an issue with the following >>>>>> commit >>>>>> "a78cd8613204 ARM: Rework and correct barrier definitions". You and >>>>>> Marek >>>>>> discussed it a bit, but I don't think there was a real conclusion. You >>>>>> submitted a second version of the patchset asking for advice on debugging >>>>>> the issue: >>>>>> >>>>>> https://lists.denx.de/pipermail/u-boot/2016-December/275822.html >>>>>> >>>>>> No real conversation came from the second patchset, and that was the end >>>>>> of >>>>>> the patch. >>>>>> >>>>>> I was hoping we could revisit adding your patchset again. I am working >>>>>> on a >>>>>> custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased your >>>>>> patchset >>>>>> against v2018.05 and it is working on my custom board (although I don't >>>>>> have >>>>>> an MMC). I also tested it on a SoCKit booting from an MMC (I forced it to >>>>>> scrub the SDRAM on the SoCKit, because it doesn't have ECC RAM), and the >>>>>> SoCKit finds the MMC and boots. >>>>>> >>>>>> I don't have any suggestions on why it is working now on my board and not >>>>>> back when you first submitted the patchset. Maybe something else was >>>>>> fixed >>>>>> in the MMC? I was hoping you and Marek could test this patch again on >>>>>> some >>>>>> different SoCFPGA boards to see if you get the same results. >>>>> Look at this patch >>>>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=9bb8a249b292d26f152c20e3641600b3d7b3924b >>>>> >>>>> You likely want similar approach, it's faster then the DMA and much >>>>> simpler. >>>>> >>>> Thanks Marek. I'll give it a try. Would you be interested in a similar >>>> patch for the Gen 5? >>> I don't have any Gen5 board which uses ECC, do you ? >>> If so, yes, prepare a patch, it should be very similar. >>> >>> Make sure to measure how long it takes to scrub the memory and how much >>> memory you have, I'd be interested in the numbers. >>> >> Looking at the master branch, it doesn't look like that code is ever being >> called? >> The sdram_init_ecc_bits() function is called from the >> ddr_calibration_sequence function(), >> but I can't find where ddr_calibration_sequence is called(). > git grep for it, it's called from somewhere in the arch/arm/mach-socfpga/ > >> Either way, I can test it. I have a custom Cyclone V board with ECC, and the >> Intel Arria V SoC >> Dev Kit I can test it on too which I think has ECC. > Please do. > I implemented a similar memset approach for the gen 5 socfpga. It's basically the same code as in that patch; however, when I performed a single memset the processor would reset for some reason. I changed it to loop over calling memset with a size of 32MB over the entire address the address, and that worked as opposed to doing a single memset on the RAM. I started on a SoCKit because it was handy, I know it doesn't have ECC, but I forced it to initialize the RAM as a quick test. It seems much slower than the DMA approach. It should be noted, I didn't implement any code to time the scrubbing, but rather just roughly monitored the time to get a rough idea of how long it took. On the SoCKit, which has 1GB of RAM, the memset takes around 8 seconds to complete, and the DMA takes under 2 seconds. Maybe I ported something wrong? I used very similar code as the sdram_init_ecc_bits() function, with the exception I looped over the second memset with a size of 32MB. I wasn't sure why the TLB address/size was being initialized, or if the values used on the Arria 10 are even correct for the Cyclone 5, but I used that part of the code as is from the Arria 10 patch as well as enabling the icache and dcache just like the Arria 10 code. Any suggestions on what to look at? Jason ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 6/29/2018 9:52 AM, Marek Vasut wrote: > On 06/29/2018 04:44 PM, Jason Rush wrote: >> On 6/29/2018 9:34 AM, Marek Vasut wrote: >>> On 06/29/2018 04:31 PM, Jason Rush wrote: >>>> Dinh, >>> Hi, >>> >>>> A while ago, you posted the following patchset for SoCFPGA to add the PL330 >>>> DMA driver, and updated the SoCFPGA SDRAM init to write zeros to SDRAM to >>>> initialize the ECC bits if ECC was enabled: >>>> >>>> https://lists.denx.de/pipermail/u-boot/2016-October/269643.html >>>> >>>> I know it's been a long time, so I'll summarize some of the conversation... >>>> >>>> At the time, you had a problem with the patchset causing the SPL to fail to >>>> find the MMC. You had tracked it down to an issue with the following >>>> commit >>>> "a78cd8613204 ARM: Rework and correct barrier definitions". You and Marek >>>> discussed it a bit, but I don't think there was a real conclusion. You >>>> submitted a second version of the patchset asking for advice on debugging >>>> the issue: >>>> >>>> https://lists.denx.de/pipermail/u-boot/2016-December/275822.html >>>> >>>> No real conversation came from the second patchset, and that was the end of >>>> the patch. >>>> >>>> I was hoping we could revisit adding your patchset again. I am working on a >>>> custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased your >>>> patchset >>>> against v2018.05 and it is working on my custom board (although I don't >>>> have >>>> an MMC). I also tested it on a SoCKit booting from an MMC (I forced it to >>>> scrub the SDRAM on the SoCKit, because it doesn't have ECC RAM), and the >>>> SoCKit finds the MMC and boots. >>>> >>>> I don't have any suggestions on why it is working now on my board and not >>>> back when you first submitted the patchset. Maybe something else was fixed >>>> in the MMC? I was hoping you and Marek could test this patch again on some >>>> different SoCFPGA boards to see if you get the same results. >>> Look at this patch >>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=9bb8a249b292d26f152c20e3641600b3d7b3924b >>> >>> You likely want similar approach, it's faster then the DMA and much simpler. >>> >> Thanks Marek. I'll give it a try. Would you be interested in a similar >> patch for the Gen 5? > I don't have any Gen5 board which uses ECC, do you ? > If so, yes, prepare a patch, it should be very similar. > > Make sure to measure how long it takes to scrub the memory and how much > memory you have, I'd be interested in the numbers. > Looking at the master branch, it doesn't look like that code is ever being called? The sdram_init_ecc_bits() function is called from the ddr_calibration_sequence function(), but I can't find where ddr_calibration_sequence is called(). Either way, I can test it. I have a custom Cyclone V board with ECC, and the Intel Arria V SoC Dev Kit I can test it on too which I think has ECC. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 6/29/2018 9:34 AM, Marek Vasut wrote: > On 06/29/2018 04:31 PM, Jason Rush wrote: >> Dinh, > Hi, > >> A while ago, you posted the following patchset for SoCFPGA to add the PL330 >> DMA driver, and updated the SoCFPGA SDRAM init to write zeros to SDRAM to >> initialize the ECC bits if ECC was enabled: >> >> https://lists.denx.de/pipermail/u-boot/2016-October/269643.html >> >> I know it's been a long time, so I'll summarize some of the conversation... >> >> At the time, you had a problem with the patchset causing the SPL to fail to >> find the MMC. You had tracked it down to an issue with the following commit >> "a78cd8613204 ARM: Rework and correct barrier definitions". You and Marek >> discussed it a bit, but I don't think there was a real conclusion. You >> submitted a second version of the patchset asking for advice on debugging >> the issue: >> >> https://lists.denx.de/pipermail/u-boot/2016-December/275822.html >> >> No real conversation came from the second patchset, and that was the end of >> the patch. >> >> I was hoping we could revisit adding your patchset again. I am working on a >> custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased your patchset >> against v2018.05 and it is working on my custom board (although I don't have >> an MMC). I also tested it on a SoCKit booting from an MMC (I forced it to >> scrub the SDRAM on the SoCKit, because it doesn't have ECC RAM), and the >> SoCKit finds the MMC and boots. >> >> I don't have any suggestions on why it is working now on my board and not >> back when you first submitted the patchset. Maybe something else was fixed >> in the MMC? I was hoping you and Marek could test this patch again on some >> different SoCFPGA boards to see if you get the same results. > Look at this patch > http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=9bb8a249b292d26f152c20e3641600b3d7b3924b > > You likely want similar approach, it's faster then the DMA and much simpler. > Thanks Marek. I'll give it a try. Would you be interested in a similar patch for the Gen 5? Jason ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
Dinh, A while ago, you posted the following patchset for SoCFPGA to add the PL330 DMA driver, and updated the SoCFPGA SDRAM init to write zeros to SDRAM to initialize the ECC bits if ECC was enabled: https://lists.denx.de/pipermail/u-boot/2016-October/269643.html I know it's been a long time, so I'll summarize some of the conversation... At the time, you had a problem with the patchset causing the SPL to fail to find the MMC. You had tracked it down to an issue with the following commit "a78cd8613204 ARM: Rework and correct barrier definitions". You and Marek discussed it a bit, but I don't think there was a real conclusion. You submitted a second version of the patchset asking for advice on debugging the issue: https://lists.denx.de/pipermail/u-boot/2016-December/275822.html No real conversation came from the second patchset, and that was the end of the patch. I was hoping we could revisit adding your patchset again. I am working on a custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased your patchset against v2018.05 and it is working on my custom board (although I don't have an MMC). I also tested it on a SoCKit booting from an MMC (I forced it to scrub the SDRAM on the SoCKit, because it doesn't have ECC RAM), and the SoCKit finds the MMC and boots. I don't have any suggestions on why it is working now on my board and not back when you first submitted the patchset. Maybe something else was fixed in the MMC? I was hoping you and Marek could test this patch again on some different SoCFPGA boards to see if you get the same results. Regards, Jason ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common: bootm: reserve memory bank
> Actually the DRAM is not only seperated in one
> bank. The DRAM bank information is stored in
> gd->bd->bi_dram, so reserve lmb according to
> gd->bd->bi_dram.
>
> Signed-off-by: Jason Zhu
> ---
> common/bootm.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/common/bootm.c b/common/bootm.c
> index e789f68..46689fa 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c
> @@ -53,16 +53,23 @@ __weak void board_quiesce_devices(void)
> #ifdef CONFIG_LMB
> static void boot_start_lmb(bootm_headers_t *images)
> {
> + lmb_init(&images->lmb);
> +#ifdef CONFIG_NR_DRAM_BANKS
> + int i;
> +
> + for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> + lmb_add(&images->lmb, gd->bd->bi_dram[i].start,
> + gd->bd->bi_dram[i].size);
> + }
> +#else
> ulong mem_start;
> phys_size_t mem_size;
>
> - lmb_init(&images->lmb);
> -
> mem_start = env_get_bootm_low();
> mem_size = env_get_bootm_size();
>
> lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
> -
> +#endif
> arch_lmb_reserve(&images->lmb);
> board_lmb_reserve(&images->lmb);
> }
Can you describe a bit how you ran into this problem? Thanks!
> Run the function dram_init_banksize, then the dram is seperated in several
> banks. Sometimes the bank0's size maybe zero. If we call boot_start_lmb
> to reserve lmb which just only reserve bank0, the lmb's memory size is zero.
> This can cause allocate memory error when we want to reserve lmb for fdt.
> So reserve lmb depend on CONFIG_NR_DRAM_BANKS(function dram_init_banksize
> seperates the dram by CONFIG_NR_DRAM_BANKS) but not just bank0.
> Thanks!
jason....@rock-chips.com
From: Tom Rini
Date: 2018-06-19 03:02
To: Jason Zhu
CC: Simon Glass; u-boot; Alexander Graf
Subject: Re: [U-Boot] [PATCH] common: bootm: reserve memory bank
On Thu, Jun 14, 2018 at 03:07:25PM +0800, Jason Zhu wrote:
> Actually the DRAM is not only seperated in one
> bank. The DRAM bank information is stored in
> gd->bd->bi_dram, so reserve lmb according to
> gd->bd->bi_dram.
>
> Signed-off-by: Jason Zhu
> ---
> common/bootm.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/common/bootm.c b/common/bootm.c
> index e789f68..46689fa 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c
> @@ -53,16 +53,23 @@ __weak void board_quiesce_devices(void)
> #ifdef CONFIG_LMB
> static void boot_start_lmb(bootm_headers_t *images)
> {
> + lmb_init(&images->lmb);
> +#ifdef CONFIG_NR_DRAM_BANKS
> + int i;
> +
> + for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> + lmb_add(&images->lmb, gd->bd->bi_dram[i].start,
> + gd->bd->bi_dram[i].size);
> + }
> +#else
> ulong mem_start;
> phys_size_t mem_size;
>
> - lmb_init(&images->lmb);
> -
> mem_start = env_get_bootm_low();
> mem_size = env_get_bootm_size();
>
> lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
> -
> +#endif
> arch_lmb_reserve(&images->lmb);
> board_lmb_reserve(&images->lmb);
> }
Can you describe a bit how you ran into this problem? Thanks!
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] common: bootm: reserve memory bank
Actually the DRAM is not only seperated in one
bank. The DRAM bank information is stored in
gd->bd->bi_dram, so reserve lmb according to
gd->bd->bi_dram.
Signed-off-by: Jason Zhu
---
common/bootm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index e789f68..46689fa 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -53,16 +53,23 @@ __weak void board_quiesce_devices(void)
#ifdef CONFIG_LMB
static void boot_start_lmb(bootm_headers_t *images)
{
+ lmb_init(&images->lmb);
+#ifdef CONFIG_NR_DRAM_BANKS
+ int i;
+
+ for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
+ lmb_add(&images->lmb, gd->bd->bi_dram[i].start,
+ gd->bd->bi_dram[i].size);
+ }
+#else
ulong mem_start;
phys_size_t mem_size;
- lmb_init(&images->lmb);
-
mem_start = env_get_bootm_low();
mem_size = env_get_bootm_size();
lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
-
+#endif
arch_lmb_reserve(&images->lmb);
board_lmb_reserve(&images->lmb);
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] common: bootm: reserve memory bank
Actually the DRAM is not only seperated in one
bank. The DRAM bank information is stored in
gd->bd->bi_dram, so reserve lmb according to
gd->bd->bi_dram.
Signed-off-by: Jason Zhu
---
common/bootm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index e789f68..46689fa 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -53,16 +53,23 @@ __weak void board_quiesce_devices(void)
#ifdef CONFIG_LMB
static void boot_start_lmb(bootm_headers_t *images)
{
+ lmb_init(&images->lmb);
+#ifdef CONFIG_NR_DRAM_BANKS
+ int i;
+
+ for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
+ lmb_add(&images->lmb, gd->bd->bi_dram[i].start,
+ gd->bd->bi_dram[i].size);
+ }
+#else
ulong mem_start;
phys_size_t mem_size;
- lmb_init(&images->lmb);
-
mem_start = env_get_bootm_low();
mem_size = env_get_bootm_size();
lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
-
+#endif
arch_lmb_reserve(&images->lmb);
board_lmb_reserve(&images->lmb);
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Re-introducing support for OLD hardware
Hi everyone. In regards to re-introduction and ongoing maintenance of support for old SoC, we have determined that this would be a futile effort. More so when you consider that the team here wanted to run Jquery and all of the newer frameworks on this old SoC. We have therefore chosen to support a "current" SoC in our design, using the AllWinner H3 series, and for this reason I will remain on the mailing list. Since this will be a deployment of U-boot in a secure environment with rather strict rules and regulations, we will probably have to maintain our own internal fork of U-Boot mainine. The reason for this is we wish to add our own proprietary functionality to lock out Linux kernels and images that we do not control. I haven't looked at this in great detail yet, so if I am trying to reinvent the wheel please let me know. The idea is simple- we want the board to refuse to boot any build of Linux we didn't compile ourselves. This is to comply with Payment Card Industry rules. This will mean I will have to pick up new releases and ensure interoperability with whatever is current. Many Thanks Jason Mitchell On 12 April 2018 at 16:01, Tom Rini wrote: > On Thu, Apr 12, 2018 at 09:04:20AM +0200, Jason Mitchell wrote: > > Good day all > > > > I am currently faced with a task of having to run new software on ageing > > hardware. We have currently about 1000 units in the field of a machine > that > > runs Windows CE using the Samsung S3C6410. > > > > Because these are considerable assets its not a simple case of replacing > > them with new, more modern hardware. > > > > The goal is to be able to get these existing boards to run Ubuntu so that > > we can run GoLang applications, so we need the GUI with just a relatively > > recent browser. > > > > The board in question is a near perfect clone of the SMDK6410, which was > > supported fully in U-boot in the past, indeed I can select SMDK6410 and > > compile a working U-boot using 1.3.4 sources > > > > After much effort I managed to get a tailored (tailored as in having > > changed the memory configuration to match the hardware) U-boot V1.3.4 > > compiled and running for this chip, the problem now, obviously we have a > > fairly recent Linux kernel compiled and it won't boot because the Device > > Tree Blob doesn't exist on such an old version of U-boot. > > > > So my questions are: > > > > - Has anyone perhaps created a branch or fork of the current or nearly > > current version of U-boot and patched in this support. I see a lot of > > Chinese websites where they seem to have done this but the language > barrier > > is a big problem. Also a lot of dead links are another problem. > > > > - If there isn't something out there, would it be possible to run through > > the steps with me to add support for this CPU again. I don't mind doing > the > > work, the main issue is I have no clue how U-boot actually works > internally. > > > > I have FULL JTAG access to this board, with a perfectly functional > OpenOCD > > setup. This is how we are able to program versions of U-boot into the > FLASH. > > There's two options: > 1) You can re-introduce support for the SMDK6410 into mainline U-Boot > and be an active maintainer of it. It was removed due to lack of active > maintainers. > > 2) You can, for Linux, use the "appended DTB" work-around to boot a > modern kernel from an old bootloader. > > -- > Tom > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Re-introducing support for OLD hardware
Hi there Thanks for the advice. The DTP append work-around sounds like a horrible hack that might come to bite me later, so I am going to rather go with re-introducing SMDK6410 back into the U-boot and maintain it. The benefits are then of course that we will be retrofitting something modern in the field, as opposed to a loader that is 7 years old. I will clone the current mainline and start investigating how to best approach this. Thanks and Regards, Jason Mitchell On 12 April 2018 at 16:01, Tom Rini wrote: > On Thu, Apr 12, 2018 at 09:04:20AM +0200, Jason Mitchell wrote: > > Good day all > > > > I am currently faced with a task of having to run new software on ageing > > hardware. We have currently about 1000 units in the field of a machine > that > > runs Windows CE using the Samsung S3C6410. > > > > Because these are considerable assets its not a simple case of replacing > > them with new, more modern hardware. > > > > The goal is to be able to get these existing boards to run Ubuntu so that > > we can run GoLang applications, so we need the GUI with just a relatively > > recent browser. > > > > The board in question is a near perfect clone of the SMDK6410, which was > > supported fully in U-boot in the past, indeed I can select SMDK6410 and > > compile a working U-boot using 1.3.4 sources > > > > After much effort I managed to get a tailored (tailored as in having > > changed the memory configuration to match the hardware) U-boot V1.3.4 > > compiled and running for this chip, the problem now, obviously we have a > > fairly recent Linux kernel compiled and it won't boot because the Device > > Tree Blob doesn't exist on such an old version of U-boot. > > > > So my questions are: > > > > - Has anyone perhaps created a branch or fork of the current or nearly > > current version of U-boot and patched in this support. I see a lot of > > Chinese websites where they seem to have done this but the language > barrier > > is a big problem. Also a lot of dead links are another problem. > > > > - If there isn't something out there, would it be possible to run through > > the steps with me to add support for this CPU again. I don't mind doing > the > > work, the main issue is I have no clue how U-boot actually works > internally. > > > > I have FULL JTAG access to this board, with a perfectly functional > OpenOCD > > setup. This is how we are able to program versions of U-boot into the > FLASH. > > There's two options: > 1) You can re-introduce support for the SMDK6410 into mainline U-Boot > and be an active maintainer of it. It was removed due to lack of active > maintainers. > > 2) You can, for Linux, use the "appended DTB" work-around to boot a > modern kernel from an old bootloader. > > -- > Tom > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Re-introducing support for OLD hardware
Good day all I am currently faced with a task of having to run new software on ageing hardware. We have currently about 1000 units in the field of a machine that runs Windows CE using the Samsung S3C6410. Because these are considerable assets its not a simple case of replacing them with new, more modern hardware. The goal is to be able to get these existing boards to run Ubuntu so that we can run GoLang applications, so we need the GUI with just a relatively recent browser. The board in question is a near perfect clone of the SMDK6410, which was supported fully in U-boot in the past, indeed I can select SMDK6410 and compile a working U-boot using 1.3.4 sources After much effort I managed to get a tailored (tailored as in having changed the memory configuration to match the hardware) U-boot V1.3.4 compiled and running for this chip, the problem now, obviously we have a fairly recent Linux kernel compiled and it won't boot because the Device Tree Blob doesn't exist on such an old version of U-boot. So my questions are: - Has anyone perhaps created a branch or fork of the current or nearly current version of U-boot and patched in this support. I see a lot of Chinese websites where they seem to have done this but the language barrier is a big problem. Also a lot of dead links are another problem. - If there isn't something out there, would it be possible to run through the steps with me to add support for this CPU again. I don't mind doing the work, the main issue is I have no clue how U-boot actually works internally. I have FULL JTAG access to this board, with a perfectly functional OpenOCD setup. This is how we are able to program versions of U-boot into the FLASH. Hoping someone can assist Kindest Regards, Jason Mitchell Software Developer Spark ATM Systems (PTY) LTD ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] am335x_evm: scan more partitions and use uname_r
On Wed, Mar 7, 2018 at 9:27 AM Tom Rini wrote:
> On Wed, Mar 07, 2018 at 05:40:42AM -0500, Jason Kridner wrote:
>
> > This enables mainline u-boot to boot the BeagleBoard.org Debian
> > distribution builds without extensive environment modifications.
> >
> > Some boot layouts only have a single partition on the
> > MMC/eMMC. This will scan those partitions after the second
> > partition that was already being scanned.
> >
> > Some layouts use uname_r to define the kernel being used for the boot to
> > support multiple kernels stored within the boot file system without
> > using symlinks.
> >
> > See http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 for
> > more details on the BeagleBoard.org Debian image layout.
> >
> > Signed-off-by: Jason Kridner
> > Cc: Robert Nelson
> > Cc: Tom Rini
> > ---
> > include/configs/am335x_evm.h | 5 -
> > include/environment/ti/mmc.h | 13 +
> > 2 files changed, 13 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
> > index 8d45b6fade..32fe0e0cd5 100644
> > --- a/include/configs/am335x_evm.h
> > +++ b/include/configs/am335x_evm.h
> > @@ -61,7 +61,10 @@
> > #define BOOTENV_DEV_LEGACY_MMC(devtypeu, devtypel, instance) \
> > "bootcmd_" #devtypel #instance "=" \
> > "setenv mmcdev " #instance"; "\
> > - "setenv bootpart " #instance":2 ; "\
> > + "setenv bootpart " #instance":2; "\
> > + "run mmcboot;"\
> > + "setenv mmcdev " #instance"; "\
> > + "setenv bootpart " #instance":1; "\
> > "run mmcboot\0"
> >
> > #define BOOTENV_DEV_NAME_LEGACY_MMC(devtypeu, devtypel, instance) \
> > diff --git a/include/environment/ti/mmc.h b/include/environment/ti/mmc.h
> > index 4305ebdaaf..b803ecccb7 100644
> > --- a/include/environment/ti/mmc.h
> > +++ b/include/environment/ti/mmc.h
> > @@ -23,9 +23,10 @@
> > "bootenvfile=uEnv.txt\0" \
> > "importbootenv=echo Importing environment from mmc${mmcdev} ...; "
> \
> > "env import -t ${loadaddr} ${filesize}\0" \
> > - "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}\0" \
> > - "loadimage=load ${devtype} ${bootpart} ${loadaddr}
> ${bootdir}/${bootfile}\0" \
> > - "loadfdt=load ${devtype} ${bootpart} ${fdtaddr}
> ${bootdir}/${fdtfile}\0" \
> > + "loadbootenv=if fatload mmc ${mmcdev} ${loadaddr}
> ${bootdir}/${bootenvfile}; then echo Found ${bootdir}/${bootenvfile} in FAT
> partition; else load mmc ${mmcdev} ${loadaddr} ${bootdir}/${bootenvfile};
> fi\0" \
> > + "loadimage=if test -n ${uname_r}; then load ${devtype} ${bootpart}
> ${loadaddr} ${bootdir}/vmlinuz-${uname_r}; run loadrd; else load ${devtype}
> ${bootpart} ${loadaddr} ${bootdir}/${bootfile}; fi\0" \
> > + "loadrd=load ${devtype} ${bootpart} ${rdaddr}
> ${bootdir}/initrd.img-${uname_r}; setenv rdsize ${filesize}\0" \
> > + "loadfdt=if test -n ${uname_r}; then load ${devtype} ${bootpart}
> ${fdtaddr} ${bootdir}/dtbs/${uname_r}/${fdtfile}; else load ${devtype}
> ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}; fi;\0" \
> > "envboot=mmc dev ${mmcdev}; " \
> > "if mmc rescan; then " \
> > "echo SD/MMC found on device ${mmcdev};" \
> > @@ -45,7 +46,11 @@
> > "mmcloados=run args_mmc; " \
> > "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then
> " \
> > "if run loadfdt; then " \
> > - "bootz ${loadaddr} - ${fdtaddr}; " \
> > + "if test -n ${uname_r}; then " \
> > + "bootz ${loadaddr}
> ${rdaddr}:${rdsize} ${fdtaddr}; " \
> > + "else " \
> > + "bootz ${loadaddr} - ${fdtaddr}; "
> \
> > + "fi; " \
> > "else " \
> > "if test ${boot_fdt} = try; then " \
> > "bootz; " \
>
> Why does this all differ from the usual Debian case? Thanks!
>
I believe the distros typically use /boot/extlinux/extlinux.conf. We need
some way to specify a number of other environment variables we use
elsewhere in our u-boot scripts for applying device-tree overlays and such.
This patch doesn't comprehend that. It does at least get our images to boot
without applying any overlays in u-boot.
I believe Robert is preparing a subsequent series to add the application of
overlays.
Do you have something else in mind with regards to envboot's future?
>
> --
> Tom
>
--
https://beagleboard.org/about
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] am335x: am335x_evm_usbspl_defconfig: NETCONSOLE
Enable NETCONSOLE by default. Still requires changes to the boot
environment to enable on the platform.
Signed-of-by: Jason Kridner
Cc: Tom Rini
---
configs/am335x_evm_usbspl_defconfig | 7 +++
1 file changed, 7 insertions(+)
diff --git a/configs/am335x_evm_usbspl_defconfig
b/configs/am335x_evm_usbspl_defconfig
index e4bf757923..19f7c49951 100644
--- a/configs/am335x_evm_usbspl_defconfig
+++ b/configs/am335x_evm_usbspl_defconfig
@@ -6,7 +6,13 @@ CONFIG_AM33XX=y
CONFIG_DISTRO_DEFAULTS=y
# CONFIG_ANDROID_BOOT_IMAGE is not set
CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run update_to_fit; fi; run
findfdt; run init_console; run envboot; run distro_bootcmd"
+CONFIG_CONSOLE_MUX=y
+CONFIG_SYS_CONSOLE_IS_IN_ENV=y
+# CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE is not set
+CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_SYS_STDIO_DEREGISTER is not set
+# CONFIG_FIT_EMBED is not set
CONFIG_VERSION_VARIABLE=y
CONFIG_ARCH_MISC_INIT=y
CONFIG_SPL=y
@@ -50,3 +56,4 @@ CONFIG_USB_ETHER=y
CONFIG_LZO=y
CONFIG_OF_LIBFDT=y
CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_NETCONSOLE=y
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] am335x_evm: scan more partitions and use uname_r
This enables mainline u-boot to boot the BeagleBoard.org Debian
distribution builds without extensive environment modifications.
Some boot layouts only have a single partition on the
MMC/eMMC. This will scan those partitions after the second
partition that was already being scanned.
Some layouts use uname_r to define the kernel being used for the boot to
support multiple kernels stored within the boot file system without
using symlinks.
See http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 for
more details on the BeagleBoard.org Debian image layout.
Signed-off-by: Jason Kridner
Cc: Robert Nelson
Cc: Tom Rini
---
include/configs/am335x_evm.h | 5 -
include/environment/ti/mmc.h | 13 +
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 8d45b6fade..32fe0e0cd5 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -61,7 +61,10 @@
#define BOOTENV_DEV_LEGACY_MMC(devtypeu, devtypel, instance) \
"bootcmd_" #devtypel #instance "=" \
"setenv mmcdev " #instance"; "\
- "setenv bootpart " #instance":2 ; "\
+ "setenv bootpart " #instance":2; "\
+ "run mmcboot;"\
+ "setenv mmcdev " #instance"; "\
+ "setenv bootpart " #instance":1; "\
"run mmcboot\0"
#define BOOTENV_DEV_NAME_LEGACY_MMC(devtypeu, devtypel, instance) \
diff --git a/include/environment/ti/mmc.h b/include/environment/ti/mmc.h
index 4305ebdaaf..b803ecccb7 100644
--- a/include/environment/ti/mmc.h
+++ b/include/environment/ti/mmc.h
@@ -23,9 +23,10 @@
"bootenvfile=uEnv.txt\0" \
"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
- "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}\0" \
- "loadimage=load ${devtype} ${bootpart} ${loadaddr}
${bootdir}/${bootfile}\0" \
- "loadfdt=load ${devtype} ${bootpart} ${fdtaddr}
${bootdir}/${fdtfile}\0" \
+ "loadbootenv=if fatload mmc ${mmcdev} ${loadaddr}
${bootdir}/${bootenvfile}; then echo Found ${bootdir}/${bootenvfile} in FAT
partition; else load mmc ${mmcdev} ${loadaddr} ${bootdir}/${bootenvfile}; fi\0"
\
+ "loadimage=if test -n ${uname_r}; then load ${devtype} ${bootpart}
${loadaddr} ${bootdir}/vmlinuz-${uname_r}; run loadrd; else load ${devtype}
${bootpart} ${loadaddr} ${bootdir}/${bootfile}; fi\0" \
+ "loadrd=load ${devtype} ${bootpart} ${rdaddr}
${bootdir}/initrd.img-${uname_r}; setenv rdsize ${filesize}\0" \
+ "loadfdt=if test -n ${uname_r}; then load ${devtype} ${bootpart}
${fdtaddr} ${bootdir}/dtbs/${uname_r}/${fdtfile}; else load ${devtype}
${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}; fi;\0" \
"envboot=mmc dev ${mmcdev}; " \
"if mmc rescan; then " \
"echo SD/MMC found on device ${mmcdev};" \
@@ -45,7 +46,11 @@
"mmcloados=run args_mmc; " \
"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
"if run loadfdt; then " \
- "bootz ${loadaddr} - ${fdtaddr}; " \
+ "if test -n ${uname_r}; then " \
+ "bootz ${loadaddr} ${rdaddr}:${rdsize}
${fdtaddr}; " \
+ "else " \
+ "bootz ${loadaddr} - ${fdtaddr}; " \
+ "fi; " \
"else " \
"if test ${boot_fdt} = try; then " \
"bootz; " \
--
2.15.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
