Re: [PATCH v2 5/7] net: dwc_eth_qos_rockchip: Add support for RK3588
Hi Jonas,
On 2023-10-01 21:17, Jonas Karlman wrote:
> Add rk_gmac_ops and other special handling that is needed for GMAC to
> work on RK3588.
>
> rk_gmac_ops was ported from linux commits:
> 2f2b60a0ec28 ("net: ethernet: stmmac: dwmac-rk: Add gmac support for rk3588")
> 88619e77b33d ("net: stmmac: rk3588: Allow multiple gmac controller")
I've updated from U-Boot 2023.07.2 to 2024.01, and noticed Ethernet
issue on Linux. On a ODROID-M1 with 8GB of RAM I had a packet drop rate
of ~20%:
107 packets transmitted, 87 received, 18.6916% packet loss, time
107390ms
rtt min/avg/max/mdev = 0.337/0.405/0.889/0.076 ms
SSH connections feel very sluggy, presumably due to packet losses.
Strangely, the same build works just fine on another ODROID-M1 with 4GB
of RAM. I swapped Ethernet cable and switches to rule this out. It
really seems to bee that particular unit which is problematic.
Disabling this driver fixes the Etherent issue on Linux.
Do you have an idea what this could be? I am happy to run commands or
test patches to debug this.
--
Stefan
>
> Signed-off-by: Jonas Karlman
> Reviewed-by: Kever Yang
> ---
> Cc: David Wu
> Cc: Sebastian Reichel
> Cc: Benjamin Gaignard
> ---
> v2:
> - Collect r-b tag
>
> drivers/net/dwc_eth_qos.c | 4 +
> drivers/net/dwc_eth_qos_rockchip.c | 182 -
> 2 files changed, 182 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
> index 9fb98a2c3c74..dc04416865dd 100644
> --- a/drivers/net/dwc_eth_qos.c
> +++ b/drivers/net/dwc_eth_qos.c
> @@ -1712,6 +1712,10 @@ static const struct udevice_id eqos_ids[] = {
> .compatible = "rockchip,rk3568-gmac",
> .data = (ulong)_rockchip_config
> },
> + {
> + .compatible = "rockchip,rk3588-gmac",
> + .data = (ulong)_rockchip_config
> + },
> #endif
> #if IS_ENABLED(CONFIG_DWC_ETH_QOS_QCOM)
> {
> diff --git a/drivers/net/dwc_eth_qos_rockchip.c
> b/drivers/net/dwc_eth_qos_rockchip.c
> index 05edc098f50d..20fd3a25c3dd 100644
> --- a/drivers/net/dwc_eth_qos_rockchip.c
> +++ b/drivers/net/dwc_eth_qos_rockchip.c
> @@ -28,6 +28,7 @@ struct rk_gmac_ops {
> int tx_delay, int rx_delay);
> int (*set_to_rmii)(struct udevice *dev);
> int (*set_gmac_speed)(struct udevice *dev);
> + void (*set_clock_selection)(struct udevice *dev, bool enable);
> u32 regs[3];
> };
>
> @@ -35,7 +36,9 @@ struct rockchip_platform_data {
> struct reset_ctl_bulk resets;
> const struct rk_gmac_ops *ops;
> int id;
> + bool clock_input;
> struct regmap *grf;
> + struct regmap *php_grf;
> };
>
> #define HIWORD_UPDATE(val, mask, shift) \
> @@ -129,6 +132,137 @@ static int rk3568_set_gmac_speed(struct udevice *dev)
> return 0;
> }
>
> +/* sys_grf */
> +#define RK3588_GRF_GMAC_CON7 0x031c
> +#define RK3588_GRF_GMAC_CON8 0x0320
> +#define RK3588_GRF_GMAC_CON9 0x0324
> +
> +#define RK3588_GMAC_RXCLK_DLY_ENABLE(id) GRF_BIT(2 * (id) + 3)
> +#define RK3588_GMAC_RXCLK_DLY_DISABLE(id)GRF_CLR_BIT(2 * (id) + 3)
> +#define RK3588_GMAC_TXCLK_DLY_ENABLE(id) GRF_BIT(2 * (id) + 2)
> +#define RK3588_GMAC_TXCLK_DLY_DISABLE(id)GRF_CLR_BIT(2 * (id) + 2)
> +
> +#define RK3588_GMAC_CLK_RX_DL_CFG(val) HIWORD_UPDATE(val,
> 0xFF, 8)
> +#define RK3588_GMAC_CLK_TX_DL_CFG(val) HIWORD_UPDATE(val,
> 0xFF, 0)
> +
> +/* php_grf */
> +#define RK3588_GRF_GMAC_CON0 0x0008
> +#define RK3588_GRF_CLK_CON1 0x0070
> +
> +#define RK3588_GMAC_PHY_INTF_SEL_RGMII(id) \
> + (GRF_BIT(3 + (id) * 6) | GRF_CLR_BIT(4 + (id) * 6) | GRF_CLR_BIT(5 +
> (id) * 6))
> +#define RK3588_GMAC_PHY_INTF_SEL_RMII(id)\
> + (GRF_CLR_BIT(3 + (id) * 6) | GRF_CLR_BIT(4 + (id) * 6) | GRF_BIT(5 +
> (id) * 6))
> +
> +#define RK3588_GMAC_CLK_RMII_MODE(id)GRF_BIT(5 * (id))
> +#define RK3588_GMAC_CLK_RGMII_MODE(id) GRF_CLR_BIT(5 * (id))
> +
> +#define RK3588_GMAC_CLK_SELET_CRU(id)GRF_BIT(5 * (id) + 4)
> +#define RK3588_GMAC_CLK_SELET_IO(id) GRF_CLR_BIT(5 * (id) + 4)
> +
> +#define RK3588_GMAC_CLK_RMII_DIV2(id)GRF_BIT(5 * (id) + 2)
> +#define RK3588_GMAC_CLK_RMII_DIV20(id) GRF_CLR_BIT(5 * (id) +
> 2)
> +
> +#define RK3588_GMAC_CLK_RGMII_DIV1(id) \
> + (GRF_CLR_BIT(5 * (id) + 2) | GRF_CLR_BIT(5 * (id) + 3))
> +#define RK3588_GMAC_CLK_RGMII_DIV5(id) \
> + (GRF_BIT(5 * (id) + 2) | GRF_BIT(5 * (id) + 3))
> +#define RK3588_GMAC_CLK_RGMII_DIV50(id) \
> + (GRF_CLR_BIT(5 * (id) + 2) | GRF_BIT(5 * (id) + 3))
> +
> +#define RK3588_GMAC_CLK_RMII_GATE(id)GRF_BIT(5 * (id) + 1)
> +#define RK3588_GMAC_CLK_RMII_NOGATE(id) GRF_CLR_BIT(5 * (id) +
> 1)
> +
> +static int
Re: [PATCH v3 0/7] rpi5: initial support
Hi Ivan, On 2023-12-18 22:03, Ivan T. Ivanov wrote: > Hi, > > These patches are adding basic support for RPi5. > They are based on v2 series from Dmitry Malkin[1]. > > With them I am able to _start_ current openSUSE > Tumbleweed without modification. They are still > a lot of things to be added to the upstream Linux > before it runs flawlessly on this device, but at > least in U-Booot SD controller used for uSD card > and Frameboffer and HDMI0 devices are working fine > now. It seems that PCIe controller is working fine > too, but I have not tested it too much. Thank you very much for this work! > > Serial console and reset are also functional. I've applied the patchset to v2024.01-rc5 and built the rpi_arm64_defconfig target. I added enable_uart=1 and kernel=u-boot.bin to config.txt. While I see a brief U-Boot logo on HDMI, I haven't gotten anything on the serial console on pin 8/10 of the Raspberry Pi pin header. Is there anything specific needed to get the console going? -- Stefan > > Hopefully this will help others add missing pieces > more easily. > > Happy hacking! > > Regards, > Ivan > > [1] > https://lore.kernel.org/all/CAKRNjQ0dsWozGo4n8g58m4cCEk3n=qx1r+l24wbgpo-ip1y...@mail.gmail.com/ > > Dmitry Malkin (2): > rpi5: add initial memory map for bcm2712 > rpi5: Use devicetree as alternative way to read IO base addresses > > Ivan T. Ivanov (5): > rpi5: Use devicetree to retrieve board revision > bcm2835: brcm,bcm2708-fb device is using r5g6b5 format > mmc: bcmstb: Add support for bcm2712 SD controller > configs: rpi_arm64: enable SDHCI BCMSTB driver > pci: pcie-brcmstb: Add bcm2712 PCIe controller support > > arch/arm/mach-bcm283x/include/mach/base.h | 5 +- > arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +- > arch/arm/mach-bcm283x/include/mach/sdhci.h | 3 +- > arch/arm/mach-bcm283x/include/mach/timer.h | 3 +- > arch/arm/mach-bcm283x/include/mach/wdog.h | 3 +- > arch/arm/mach-bcm283x/init.c | 81 -- > board/raspberrypi/rpi/rpi.c| 22 ++- > configs/rpi_arm64_defconfig| 1 + > drivers/mmc/bcmstb_sdhci.c | 173 - > drivers/pci/pcie_brcmstb.c | 23 ++- > drivers/video/bcm2835.c| 10 +- > 11 files changed, 296 insertions(+), 31 deletions(-)
Re: [PATCH 2/2] board: rockchip: Add Hardkernel ODROID-M1
On 2023-07-06 07:08, Jonas Karlman wrote: > On 2023-07-06 01:27, Stefan Agner wrote: >> On 2023-07-02 22:47, Jonas Karlman wrote: >>> Hardkernel ODROID-M1 is a single board computer with a RK3568B2 SoC, >>> a slightly modified version of the RK3568 SoC. >>> >>> Features tested on a ODROID-M1 8GB v1.0 2022-06-13: >>> - SD-card boot >>> - eMMC boot >>> - SPI Flash boot >>> - PCIe/NVMe/AHCI >>> - SATA port >>> - USB host >>> >>> Device tree is imported from linux v6.4. >>> >>> Signed-off-by: Jonas Karlman >> >> Thanks for you patch! I've compared it to my version, and did not notice >> any downside/anything missing. If anything, your version is more feature >> complete. I've also tested it on an ODORID-M1 with 8GB of memory, it >> boots fine from SD card. >> >> Reviewed-by: Stefan Agner >> Tested-by: Stefan Agner > > Thanks for review and testing! > >> >> One thing I've noticed is that USB isn't working when I use the stock >> SPL (2017.09) running from the SPI RAM and upstream U-Boot (by writing >> u-boot.itb to a raw GPT partition named "uboot" to the SD-card). That is >> the same in my patchset. If the upstream SPL is used, things work. It >> seems that something is not (re)initialized in U-Boot. Not sure if we >> typically rely on the state the SPL leaves the HW at, but it would be >> nice if we are able to make that combination work. This allows to boot >> an upstream U-Boot from an SD-card without having to reflash the onboard >> SPI. > > Trying to use a combo of vendor u-boot SPL and mainline U-Boot proper is > not something I have tested or something I would recommend anyone to use. > To make use of all features one should press the "SPI recovery switch" > during boot or erase/replace U-Boot in SPI flash. Yeah I understand that this is the correct way of doing things. For Home Assistant OS we try to build an easy to use image which can be flashed to the SD card/eMMC and then booted directly. Unfortunately, the board doesn't allow to boot straight from eMMC/SD card. I'd prefer if we don't have to touch the SPI flash to avoid complexity and allow users to easily switch back to whatever the vendor offers. In a way, this is similar to how things work on x86-64, to leave the BIOS (in this case SPL on SPI flash) up to the hardware vendor. I understand that this gets into out-of-scope/unsupported territory. I posing the question opportunistically: Since you worked with the platform quite a bit maybe you have a good guess/idea what could be the culprit. > > Does this USB issue only affect U-Boot proper or also leave USB unusable > in linux? Booting OS from USB3 have been a little bit random when I have > tested, some of my USB3 devices work if plugged in from cold start > others needs to be removed and plugged in again for U-Boot to recognize > them. USB2 ports have been much more stable during my testing. USB is usable on Linux, so this is just U-Boot. I've tested with a USB 2.0 flash drive. > >> >> On a different note: Do you know if PCIe/NVMe support in SPL is >> something which is in the cards for this board? > > As mentioned in the cover-letter this series has some dependencies for > all features enabled in defconfig to work, most notably PCIe/NVMe. > > You can use my rk3568-2023.07-rc6 branch at [1] that have all > dependencies included or test with an artifact from my github actions > test build workflow at [2]. > > Or do you mean SPL to load FIT (U-Boot proper and TF-A) from NVMe? Yes, I meant using the SPL to load the U-Boot FIT image from NVMe. -- Stefan > > [1] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3568-2023.07-rc6 > [2] https://github.com/Kwiboo/u-boot-build/actions/runs/5448465108 > > Regards, > Jonas > >> >> -- >> Stefan >> >>> --- >>> arch/arm/dts/Makefile | 1 + >>> arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 46 ++ >>> arch/arm/dts/rk3568-odroid-m1.dts | 744 ++ >>> board/rockchip/evb_rk3568/MAINTAINERS | 7 + >>> configs/odroid-m1-rk3568_defconfig| 103 +++ >>> doc/board/rockchip/rockchip.rst | 1 + >>> 6 files changed, 902 insertions(+) >>> create mode 100644 arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi >>> create mode 100644 arch/arm/dts/rk3568-odroid-m1.dts >>> create mode 100644 configs/odroid-m1-rk3568_defconfig >>>[...]
Re: [PATCH 2/2] board: rockchip: Add Hardkernel ODROID-M1
On 2023-07-02 22:47, Jonas Karlman wrote:
> Hardkernel ODROID-M1 is a single board computer with a RK3568B2 SoC,
> a slightly modified version of the RK3568 SoC.
>
> Features tested on a ODROID-M1 8GB v1.0 2022-06-13:
> - SD-card boot
> - eMMC boot
> - SPI Flash boot
> - PCIe/NVMe/AHCI
> - SATA port
> - USB host
>
> Device tree is imported from linux v6.4.
>
> Signed-off-by: Jonas Karlman
Thanks for you patch! I've compared it to my version, and did not notice
any downside/anything missing. If anything, your version is more feature
complete. I've also tested it on an ODORID-M1 with 8GB of memory, it
boots fine from SD card.
Reviewed-by: Stefan Agner
Tested-by: Stefan Agner
One thing I've noticed is that USB isn't working when I use the stock
SPL (2017.09) running from the SPI RAM and upstream U-Boot (by writing
u-boot.itb to a raw GPT partition named "uboot" to the SD-card). That is
the same in my patchset. If the upstream SPL is used, things work. It
seems that something is not (re)initialized in U-Boot. Not sure if we
typically rely on the state the SPL leaves the HW at, but it would be
nice if we are able to make that combination work. This allows to boot
an upstream U-Boot from an SD-card without having to reflash the onboard
SPI.
On a different note: Do you know if PCIe/NVMe support in SPL is
something which is in the cards for this board?
--
Stefan
> ---
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 46 ++
> arch/arm/dts/rk3568-odroid-m1.dts | 744 ++
> board/rockchip/evb_rk3568/MAINTAINERS | 7 +
> configs/odroid-m1-rk3568_defconfig| 103 +++
> doc/board/rockchip/rockchip.rst | 1 +
> 6 files changed, 902 insertions(+)
> create mode 100644 arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3568-odroid-m1.dts
> create mode 100644 configs/odroid-m1-rk3568_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 480269fa6065..334c1bafda17 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -169,6 +169,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
> rk3566-anbernic-rgxx3.dtb \
> rk3566-radxa-cm3-io.dtb \
> rk3568-evb.dtb \
> + rk3568-odroid-m1.dtb \
> rk3568-rock-3a.dtb
>
> dtb-$(CONFIG_ROCKCHIP_RK3588) += \
> diff --git a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
> b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
> new file mode 100644
> index ..dc8ad98715ce
> --- /dev/null
> +++ b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include "rk356x-u-boot.dtsi"
> +
> +/ {
> + aliases {
> + spi0 =
> + };
> +
> + chosen {
> + stdout-path =
> + };
> +};
> +
> +_dual_io_pins {
> + bootph-all;
> +};
> +
> + {
> + cap-mmc-highspeed;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
> + mmc-hs400-enhanced-strobe;
> + pinctrl-0 = <_bus8 _clk _cmd _datastrobe>;
> +};
> +
> + {
> + bootph-pre-ram;
> + u-boot,spl-sfc-no-dma;
> +
> + flash@0 {
> + bootph-pre-ram;
> + };
> +};
> +
> + {
> + bootph-all;
> + clock-frequency = <2400>;
> + status = "okay";
> +};
> +
> +_usb_host {
> + /* Workaround until regulator implement basic reference counter */
> + regulator-always-on;
> +};
> diff --git a/arch/arm/dts/rk3568-odroid-m1.dts
> b/arch/arm/dts/rk3568-odroid-m1.dts
> new file mode 100644
> index ..59ecf868dbd0
> --- /dev/null
> +++ b/arch/arm/dts/rk3568-odroid-m1.dts
> @@ -0,0 +1,744 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2022 Hardkernel Co., Ltd.
> + *
> + */
> +
> +/dts-v1/;
> +#include
> +#include
> +#include
> +#include
> +#include "rk3568.dtsi"
> +
> +/ {
> + model = "Hardkernel ODROID-M1";
> + compatible = "rockchip,rk3568-odroid-m1", "rockchip,rk3568";
> +
> + aliases {
> + ethernet0 =
> + i2c0 =
> + i2c3 =
> + mmc0 =
> + mmc1 =
> + serial0 =
> + serial1 =
> + };
> +
> + chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + dc_12v: dc-12v-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "dc_12v";
> + regulator-always-on;
> + regulator-bo
Re: [PATCH] arm64: dts: rockchip: rk3568: Add ODROID-M1 board support
On 2023-07-05 18:24, Jonas Karlman wrote: > Hi Stefan, > On 2023-07-05 18:16, Stefan Agner wrote: >> Add ODROID-M1 board support. Board device tree rk3568-odroid-m1.dts >> from v6.4. > > I sent out a series that add support for ODROID-M1 a few days ago. > Please see https://patchwork.ozlabs.org/project/uboot/list/?series=362045 Cool, thanks for the hint! I've checked master branch but not the ML :) -- Stefan > > Regards, > Jonas > >> >> Signed-off-by: Stefan Agner >> --- >> arch/arm/dts/Makefile | 1 + >> arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 29 + >> arch/arm/dts/rk3568-odroid-m1.dts | 744 ++ >> configs/odroid-m1_defconfig | 84 +++ >> 4 files changed, 858 insertions(+) >> create mode 100644 arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi >> create mode 100644 arch/arm/dts/rk3568-odroid-m1.dts >> create mode 100644 configs/odroid-m1_defconfig >> > > [...]
[PATCH] arm64: dts: rockchip: rk3568: Add ODROID-M1 board support
Add ODROID-M1 board support. Board device tree rk3568-odroid-m1.dts
from v6.4.
Signed-off-by: Stefan Agner
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 29 +
arch/arm/dts/rk3568-odroid-m1.dts | 744 ++
configs/odroid-m1_defconfig | 84 +++
4 files changed, 858 insertions(+)
create mode 100644 arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3568-odroid-m1.dts
create mode 100644 configs/odroid-m1_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa60..11028c3a5e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -169,6 +169,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3566-anbernic-rgxx3.dtb \
rk3566-radxa-cm3-io.dtb \
rk3568-evb.dtb \
+ rk3568-odroid-m1.dts \
rk3568-rock-3a.dtb
dtb-$(CONFIG_ROCKCHIP_RK3588) += \
diff --git a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
new file mode 100644
index 00..3d75dd403b
--- /dev/null
+++ b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ * (C) Copyright 2023 Akash Gajjar
+ * (C) Copyright 2023 Stefan Agner
+ */
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path =
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ clock-frequency = <2400>;
+ bootph-all;
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3568-odroid-m1.dts
b/arch/arm/dts/rk3568-odroid-m1.dts
new file mode 100644
index 00..59ecf868db
--- /dev/null
+++ b/arch/arm/dts/rk3568-odroid-m1.dts
@@ -0,0 +1,744 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2022 Hardkernel Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include
+#include "rk3568.dtsi"
+
+/ {
+ model = "Hardkernel ODROID-M1";
+ compatible = "rockchip,rk3568-odroid-m1", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 =
+ i2c0 =
+ i2c3 =
+ mmc0 =
+ mmc1 =
+ serial0 =
+ serial1 =
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ dc_12v: dc-12v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_12v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+
+ hdmi-con {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <_out_con>;
+ };
+ };
+ };
+
+ ir-receiver {
+ compatible = "gpio-ir-receiver";
+ gpios = < RK_PC2 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_receiver_pin>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power: led-0 {
+ gpios = < RK_PC6 GPIO_ACTIVE_HIGH>;
+ function = LED_FUNCTION_POWER;
+ color = ;
+ default-state = "keep";
+ linux,default-trigger = "default-on";
+ pinctrl-names = "default";
+ pinctrl-0 = <_power_pin>;
+ };
+ led_work: led-1 {
+ gpios = < RK_PB7 GPIO_ACTIVE_HIGH>;
+ function = LED_FUNCTION_HEARTBEAT;
+ color = ;
+ linux,default-trigger = "heartbeat";
+ pinctrl-names = "default";
+ pinctrl-0 = <_work_pin>;
+ };
+ };
+
+ rk809-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <_det_pin>;
+ simple-audio-card,name = "Analog RK817";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,hp-det-gpio = < RK_PB0
GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,widgets =
+ "Headphone", "Headphones",
+
Re: [PATCH v2 10/18] pci: Check region ranges are addressable
Hi Andrew,
On 2022-03-29 18:58, Andrew Scull wrote:
> When parsing the `ranges` DT node, check that both extremes of the
> regions are addressable without overflow. This assumption can then be
> safely made when processing the regions.
I've bisected this patch to break USB support on 32-bit Raspberry Pi 4
builds.
We've been using U-Boot v2022.01 so far with USB boot support. With the
migration to U-Boot v2023.01, stopped booting with the following output:
U-Boot 2023.01+ (Apr 24 2023 - 15:11:45 +0200)
DRAM: 948 MiB (effective 7.9 GiB)
RPI 4 Model B (0xd03114)
Core: 207 devices, 15 uclasses, devicetree: board
MMC: mmcnr@7e30: 1, mmc@7e34: 0
Loading Environment from nowhere... OK
In:serial
Out: serial
Err: serial
Net: eth0: ethernet@7d58
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
PCI Autoconfig: Found P2P bridge, device 0
PCI Autoconfig: BAR 0, Prf64, size=0x1000, No resource
PCI: Failed autoconfig bar 10
starting USB...
Bus xhci_pci:
In this builds I've set #define DEBUG in
drivers/pci/pci_auto(_common).c.
Reverting this commit leads to:
U-Boot 2023.01+ (Apr 24 2023 - 15:47:58 +0200)
DRAM: 948 MiB (effective 7.9 GiB)
RPI 4 Model B (0xd03114)
Core: 207 devices, 15 uclasses, devicetree: board
MMC: mmcnr@7e30: 1, mmc@7e34: 0
Loading Environment from nowhere... OK
In:serial
Out: serial
Err: serial
Net: eth0: ethernet@7d58
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
PCI Autoconfig: Bus Memory region: [c000-],
Physical Memory [6-63fff]
PCI Autoconfig: Found P2P bridge, device 0
PCI Autoconfig: BAR 0, Mem64, size=0x1000, address=0xc000
bus_lower=0xc0001000
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 3 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
...
The system boot successfully a bootable system.
Note that this needs CONFIG_USB_XHCI_BRCM=y which is not set by default
in rpi_4_32b_defconfig.
I am guessing that the freeze is just a subsequent issue of not handling
PCI: Failed autoconfig bar 10 properly. But in any case, I'd prefer to
have a working PCIe in general.
Is maybe the Raspberry Pi device tree not suited for 32-bit operation?
Can't we use some sensible range in this case?
--
Stefan
>
> Signed-off-by: Andrew Scull
> Reviewed-by: Bin Meng
> ---
> drivers/pci/pci-uclass.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> index 719656eb3a..d84d97d676 100644
> --- a/drivers/pci/pci-uclass.c
> +++ b/drivers/pci/pci-uclass.c
> @@ -1017,7 +1017,22 @@ static void decode_regions(struct
> pci_controller *hose, ofnode parent_node,
>
> if (!IS_ENABLED(CONFIG_SYS_PCI_64BIT) &&
> type == PCI_REGION_MEM && upper_32_bits(pci_addr)) {
> - debug(" - beyond the 32-bit boundary, ignoring\n");
> + debug(" - pci_addr beyond the 32-bit boundary,
> ignoring\n");
> + continue;
> + }
> +
> + if (!IS_ENABLED(CONFIG_PHYS_64BIT) && upper_32_bits(addr)) {
> + debug(" - addr beyond the 32-bit boundary, ignoring\n");
> + continue;
> + }
> +
> + if (~((pci_addr_t)0) - pci_addr < size) {
> + debug(" - PCI range exceeds max address, ignoring\n");
> + continue;
> + }
> +
> + if (~((phys_addr_t)0) - addr < size) {
> + debug(" - phys range exceeds max address, ignoring\n");
> continue;
> }
[PATCH] samsung: common: ignore if CROS EC is not supported
If the CROS device class is not compiled in, uclass returns not
supported. Ignore this case as well.
This avoids boot failures on ODROID-XU4 without CONFIG_CROS_EC
ending with:
cros-ec communications failure -96
Please reset with Power+Refresh
Cannot init cros-ec device
Signed-off-by: Stefan Agner
---
board/samsung/common/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 16ce5cb892..663d7ca991 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -223,7 +223,7 @@ int board_late_init(void)
char mmcbootdev_str[16];
ret = uclass_first_device_err(UCLASS_CROS_EC, );
- if (ret && ret != -ENODEV) {
+ if (ret && ret != -ENODEV && ret != -EPFNOSUPPORT) {
/* Force console on */
gd->flags &= ~GD_FLG_SILENT;
--
2.39.1
Re: [PATCH] usb: xhci: reset endpoint on USB stall
Hi Bin, On 2022-01-05 02:21, Bin Meng wrote: > Hi Stefan, > > On Wed, Jan 5, 2022 at 3:48 AM Stefan Agner wrote: >> >> Bin Meng, >> >> On 2021-09-27 17:14, Marek Vasut wrote: >> > On 9/27/21 2:42 PM, Stefan Agner wrote: >> >> There are devices which cause a USB stall when trying to read strings. >> >> Specifically Arduino Mega R3 stalls when trying to read the product >> >> string. >> >> >> >> The stall currently remains unhandled, and subsequent retries submit new >> >> transfers on a stopped endpoint which ultimately cause a crash in >> >> abort_td(): >> >> WARN halted endpoint, queueing URB anyway. >> >> XHCI control transfer timed out, aborting... >> >> Unexpected XHCI event TRB, skipping... (3affe040 1300 >> >> 02008401) >> >> BUG at drivers/usb/host/xhci-ring.c:505/abort_td()! >> >> BUG! >> >> resetting ... >> >> >> >> Linux seems to be able to recover from the stall by issuing a >> >> TRB_RESET_EP command. >> >> >> >> Introduce reset_ep() which issues a TRB_RESET_EP followed by setting the >> >> transfer ring dequeue pointer via TRB_SET_DEQ. This allows to properly >> >> recover from a USB stall error and continue communicating with the USB >> >> device. >> >> >> >> Signed-off-by: Stefan Agner >> > >> > I hope to get AB/RB from Bin here, then it can go into this release I >> > think. >> >> Any chance you could have a look at this to get it into this release :) >> > > Sorry I missed this. I suspect it's too late for 2022.01 to include > such big changes :( I understand. Now that 2022.01 is out, could you have a look at this? -- Stefan
Re: [PATCH] usb: xhci: reset endpoint on USB stall
Bin Meng, On 2021-09-27 17:14, Marek Vasut wrote: > On 9/27/21 2:42 PM, Stefan Agner wrote: >> There are devices which cause a USB stall when trying to read strings. >> Specifically Arduino Mega R3 stalls when trying to read the product >> string. >> >> The stall currently remains unhandled, and subsequent retries submit new >> transfers on a stopped endpoint which ultimately cause a crash in >> abort_td(): >> WARN halted endpoint, queueing URB anyway. >> XHCI control transfer timed out, aborting... >> Unexpected XHCI event TRB, skipping... (3affe040 1300 02008401) >> BUG at drivers/usb/host/xhci-ring.c:505/abort_td()! >> BUG! >> resetting ... >> >> Linux seems to be able to recover from the stall by issuing a >> TRB_RESET_EP command. >> >> Introduce reset_ep() which issues a TRB_RESET_EP followed by setting the >> transfer ring dequeue pointer via TRB_SET_DEQ. This allows to properly >> recover from a USB stall error and continue communicating with the USB >> device. >> >> Signed-off-by: Stefan Agner > > I hope to get AB/RB from Bin here, then it can go into this release I think. Any chance you could have a look at this to get it into this release :) -- Stefan
[PATCH v2] usb: xhci-brcm: Include header file needed for dev_err
dev_err seems to be moved to different header file. Include
dm/device_compat.h file to compile properly.
Fixes: 69dae8902b16 ("linux/compat.h: Remove redefinition of dev_xxx macros")
Signed-off-by: Stefan Agner
---
Changes in v2:
- Correctly place include
drivers/usb/host/xhci-brcm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci-brcm.c b/drivers/usb/host/xhci-brcm.c
index 27c4bbfcba..fe17924028 100644
--- a/drivers/usb/host/xhci-brcm.c
+++ b/drivers/usb/host/xhci-brcm.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#define DRD2U3H_XHC_REGS_AXIWRA0xC08
--
2.33.0
[PATCH] usb: xhci-brcm: Include header file needed for dev_err
dev_err seems to be moved to different header file. Include
dm/device_compat.h file to compile properly.
Fixes: 69dae8902b16 ("linux/compat.h: Remove redefinition of dev_xxx macros")
Signed-off-by: Stefan Agner
---
drivers/usb/host/xhci-brcm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci-brcm.c b/drivers/usb/host/xhci-brcm.c
index 27c4bbfcba..ee3b55242e 100644
--- a/drivers/usb/host/xhci-brcm.c
+++ b/drivers/usb/host/xhci-brcm.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
--
2.33.0
[PATCH v2] nvme: invalidate correct memory range after read
The current code invalidates the range after the read buffer since the
buffer pointer gets incremented in the read loop. Use a temporary
pointer to make sure we have a pristine pointer to invalidate the
correct memory range after read.
Fixes: 704e040a51d2 ("nvme: Apply cache operations on the DMA buffers")
Reviewed-by: Andre Przywara
Signed-off-by: Stefan Agner
---
Changes in v2:
- Use uintptr_t to avoid casts
drivers/nvme/nvme.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index f6465ea7f4..3c529a2fce 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -743,6 +743,7 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t
blknr,
u64 prp2;
u64 total_len = blkcnt << desc->log2blksz;
u64 temp_len = total_len;
+ uintptr_t temp_buffer = (uintptr_t)buffer;
u64 slba = blknr;
u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift);
@@ -770,19 +771,19 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t
blknr,
}
if (nvme_setup_prps(dev, ,
- lbas << ns->lba_shift, (ulong)buffer))
+ lbas << ns->lba_shift, temp_buffer))
return -EIO;
c.rw.slba = cpu_to_le64(slba);
slba += lbas;
c.rw.length = cpu_to_le16(lbas - 1);
- c.rw.prp1 = cpu_to_le64((ulong)buffer);
+ c.rw.prp1 = cpu_to_le64(temp_buffer);
c.rw.prp2 = cpu_to_le64(prp2);
status = nvme_submit_sync_cmd(dev->queues[NVME_IO_Q],
, NULL, IO_TIMEOUT);
if (status)
break;
temp_len -= (u32)lbas << ns->lba_shift;
- buffer += lbas << ns->lba_shift;
+ temp_buffer += lbas << ns->lba_shift;
}
if (read)
--
2.33.0
Re: [PATCH] nvme: invalidate correct memory range after read
On 2021-09-30 18:09, Andre Przywara wrote:
> On Tue, 28 Sep 2021 10:01:40 +0200
> Stefan Agner wrote:
>
>> The current code invalidates the range after the read buffer since the
>> buffer pointer gets incremented in the read loop. Use a temporary
>> pointer to make sure we have a pristine pointer to invalidate the
>> correct memory range after read.
>
> Ah, good catch!
It did actually create issues in real world where sometimes it would
just not recognize a file system properly when using the ls command.
> This looks good, just one nit below:
>
>> Fixes: 704e040a51d2 ("nvme: Apply cache operations on the DMA buffers")
>> Signed-off-by: Stefan Agner
>> ---
>>
>> drivers/nvme/nvme.c | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
>> index f6465ea7f4..354513ad30 100644
>> --- a/drivers/nvme/nvme.c
>> +++ b/drivers/nvme/nvme.c
>> @@ -743,6 +743,7 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t
>> blknr,
>> u64 prp2;
>> u64 total_len = blkcnt << desc->log2blksz;
>> u64 temp_len = total_len;
>> +void *temp_buffer = buffer;
>
> You could make this an unsigned long (or better uintptr_t), then lose all
> the casts below and avoid the void ptr arithmetic.
Ok, I'll send an update shortly.
>
> But it works either way, so:
>
> Reviewed-by: Andre Przywara
Thanks for your review.
--
Stefan
>
> Cheers,
> Andre
>
>
>>
>> u64 slba = blknr;
>> u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift);
>> @@ -770,19 +771,19 @@ static ulong nvme_blk_rw(struct udevice *udev,
>> lbaint_t blknr,
>> }
>>
>> if (nvme_setup_prps(dev, ,
>> -lbas << ns->lba_shift, (ulong)buffer))
>> +lbas << ns->lba_shift, (ulong)temp_buffer))
>> return -EIO;
>> c.rw.slba = cpu_to_le64(slba);
>> slba += lbas;
>> c.rw.length = cpu_to_le16(lbas - 1);
>> -c.rw.prp1 = cpu_to_le64((ulong)buffer);
>> +c.rw.prp1 = cpu_to_le64((ulong)temp_buffer);
>> c.rw.prp2 = cpu_to_le64(prp2);
>> status = nvme_submit_sync_cmd(dev->queues[NVME_IO_Q],
>> , NULL, IO_TIMEOUT);
>> if (status)
>> break;
>> temp_len -= (u32)lbas << ns->lba_shift;
>> -buffer += lbas << ns->lba_shift;
>> +temp_buffer += lbas << ns->lba_shift;
>> }
>>
>> if (read)
[PATCH] nvme: invalidate correct memory range after read
The current code invalidates the range after the read buffer since the
buffer pointer gets incremented in the read loop. Use a temporary
pointer to make sure we have a pristine pointer to invalidate the
correct memory range after read.
Fixes: 704e040a51d2 ("nvme: Apply cache operations on the DMA buffers")
Signed-off-by: Stefan Agner
---
drivers/nvme/nvme.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index f6465ea7f4..354513ad30 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -743,6 +743,7 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t
blknr,
u64 prp2;
u64 total_len = blkcnt << desc->log2blksz;
u64 temp_len = total_len;
+ void *temp_buffer = buffer;
u64 slba = blknr;
u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift);
@@ -770,19 +771,19 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t
blknr,
}
if (nvme_setup_prps(dev, ,
- lbas << ns->lba_shift, (ulong)buffer))
+ lbas << ns->lba_shift, (ulong)temp_buffer))
return -EIO;
c.rw.slba = cpu_to_le64(slba);
slba += lbas;
c.rw.length = cpu_to_le16(lbas - 1);
- c.rw.prp1 = cpu_to_le64((ulong)buffer);
+ c.rw.prp1 = cpu_to_le64((ulong)temp_buffer);
c.rw.prp2 = cpu_to_le64(prp2);
status = nvme_submit_sync_cmd(dev->queues[NVME_IO_Q],
, NULL, IO_TIMEOUT);
if (status)
break;
temp_len -= (u32)lbas << ns->lba_shift;
- buffer += lbas << ns->lba_shift;
+ temp_buffer += lbas << ns->lba_shift;
}
if (read)
--
2.33.0
[PATCH] usb: xhci: reset endpoint on USB stall
There are devices which cause a USB stall when trying to read strings.
Specifically Arduino Mega R3 stalls when trying to read the product
string.
The stall currently remains unhandled, and subsequent retries submit new
transfers on a stopped endpoint which ultimately cause a crash in
abort_td():
WARN halted endpoint, queueing URB anyway.
XHCI control transfer timed out, aborting...
Unexpected XHCI event TRB, skipping... (3affe040 1300 02008401)
BUG at drivers/usb/host/xhci-ring.c:505/abort_td()!
BUG!
resetting ...
Linux seems to be able to recover from the stall by issuing a
TRB_RESET_EP command.
Introduce reset_ep() which issues a TRB_RESET_EP followed by setting the
transfer ring dequeue pointer via TRB_SET_DEQ. This allows to properly
recover from a USB stall error and continue communicating with the USB
device.
Signed-off-by: Stefan Agner
---
This has been reported on the ML by Mike Hoogstraten a while ago:
https://www.mail-archive.com/u-boot@lists.denx.de/msg390604.html
FWIW, for the Arduino Mega R3 I also opened an issue:
https://github.com/arduino/ArduinoCore-avr/issues/431
--
Stefan
drivers/usb/host/xhci-ring.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 35bd5cd29e..1a9dff3b6c 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -481,6 +481,33 @@ union xhci_trb *xhci_wait_for_event(struct xhci_ctrl
*ctrl, trb_type expected)
BUG();
}
+/*
+ * Send reset endpoint command for given endpoint. This recovers from a
+ * halted endpoint (e.g. due to a stall error).
+ */
+static void reset_ep(struct usb_device *udev, int ep_index)
+{
+ struct xhci_ctrl *ctrl = xhci_get_ctrl(udev);
+ struct xhci_ring *ring = ctrl->devs[udev->slot_id]->eps[ep_index].ring;
+ union xhci_trb *event;
+ u32 field;
+
+ printf("Resetting EP %d...\n", ep_index);
+ xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_RESET_EP);
+ event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
+ field = le32_to_cpu(event->trans_event.flags);
+ BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
+ xhci_acknowledge_event(ctrl);
+
+ 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);
+ 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);
+ xhci_acknowledge_event(ctrl);
+}
+
/*
* Stops transfer processing for an endpoint and throws away all unprocessed
* TRBs by setting the xHC's dequeue pointer to our enqueue pointer. The next
@@ -928,6 +955,10 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
pipe,
record_transfer_result(udev, event, length);
xhci_acknowledge_event(ctrl);
+ if (udev->status == USB_ST_STALLED) {
+ reset_ep(udev, ep_index);
+ return -EPIPE;
+ }
/* Invalidate buffer to make it available to usb-core */
if (length > 0)
--
2.33.0
Re: [PATCH] nvme: Enable FUA
On 2021-09-26 11:12, Jon Lin wrote:
> Most NVME devcies maintain data in internal cache for an uncertain
> times, and u-boot has no method to force NVME to flush cache.
> So this patch adds FUA to avoid data loss caused by power off after data
> programming.
Maybe worth mentioning that FUA stands for Force Unit Access and makes
sure that data has been written to non-volatile storage before command
completion.
It seems to me that volatile cache needs to be explicitly enabled by the
Volatile Write Cache feature. But I guess it could be already enabled by
earlier firmware/on reboot? Setting the FUA bit will make certain that
data land on non-volatile storage in any case. So:
Reviewed-by: Stefan Agner
Out of curiosity, has this been a problem in a real world situation?
--
Stefan
>
> Signed-off-by: Jon Lin
> ---
>
> drivers/nvme/nvme.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> index f6465ea7f4..5d05cb6e9e 100644
> --- a/drivers/nvme/nvme.c
> +++ b/drivers/nvme/nvme.c
> @@ -761,6 +761,9 @@ static ulong nvme_blk_rw(struct udevice *udev,
> lbaint_t blknr,
> c.rw.appmask = 0;
> c.rw.metadata = 0;
>
> + /* Always enable FUA for data integrity */
> + c.rw.control |= NVME_RW_FUA;
> +
> while (total_lbas) {
> if (total_lbas < lbas) {
> lbas = (u16)total_lbas;
Re: [RFC PATCH 4/4] nvme: translate virtual addresses into the bus's address space
On 2021-09-24 01:20, Stefan Agner wrote:
> So far we've been content with passing physical/CPU addresses when
> configuring memory addresses into NVMe controllers, but not all
> platforms have buses with transparent mappings. Specifically the
> Raspberry Pi 4 might introduce an offset to memory accesses incoming
> from its PCIe port.
>
> Introduce nvme_virt_to_bus() and nvme_bus_to_virt() to cater with these
> limitations, and make sure we don't break non DM users.
> For devices where PCIe's view of host memory doesn't match the memory
> as seen by the CPU.
>
> A similar change has been introduced for XHCI controller with
> commit 1a474559d90a ("xhci: translate virtual addresses into the bus's
> address space").
>
> Signed-off-by: Stefan Agner
> ---
>
> drivers/nvme/nvme.c | 32 ++--
> drivers/nvme/nvme.h | 15 +++
> 2 files changed, 33 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> index 4c4dc7cc4d..0b7082d71b 100644
> --- a/drivers/nvme/nvme.c
> +++ b/drivers/nvme/nvme.c
> @@ -95,7 +95,7 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 *prp2,
> buffer += (page_size - offset);
>
> if (length <= page_size) {
> - *prp2 = (u64)buffer;
> + *prp2 = nvme_virt_to_bus(dev, buffer);
> return 0;
> }
>
> @@ -120,16 +120,16 @@ static int nvme_setup_prps(struct nvme_dev *dev,
> u64 *prp2,
> i = 0;
> while (nprps) {
> if (i == prps_per_page) {
> - u64 next_prp_list = (u64)prp_pool + page_size;
> - *(prp_pool + i) = cpu_to_le64(next_prp_list);
> + u64 next = nvme_virt_to_bus(dev, prp_pool + page_size);
> + *(prp_pool + i) = cpu_to_le64(next);
> i = 0;
> prp_pool += page_size;
> }
> - *(prp_pool + i++) = cpu_to_le64((u64)buffer);
> + *(prp_pool + i++) = cpu_to_le64(nvme_virt_to_bus(dev, buffer));
> buffer += page_size;
> nprps--;
> }
> - *prp2 = (u64)dev->prp_pool;
> + *prp2 = nvme_virt_to_bus(dev, dev->prp_pool);
>
> flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool +
> dev->prp_entry_num * sizeof(u64));
> @@ -356,6 +356,7 @@ static int nvme_configure_admin_queue(struct nvme_dev
> *dev)
> int result;
> u32 aqa;
> u64 cap = dev->cap;
> + u64 dma_addr;
> struct nvme_queue *nvmeq;
> /* most architectures use 4KB as the page size */
> unsigned page_shift = 12;
> @@ -396,8 +397,10 @@ static int nvme_configure_admin_queue(struct nvme_dev
> *dev)
> dev->ctrl_config |= NVME_CC_IOSQES | NVME_CC_IOCQES;
>
> writel(aqa, >bar->aqa);
> - nvme_writeq((ulong)nvmeq->sq_cmds, >bar->asq);
> - nvme_writeq((ulong)nvmeq->cqes, >bar->acq);
> + dma_addr = nvme_virt_to_bus(dev, nvmeq->sq_cmds);
> + nvme_writeq(dma_addr, >bar->asq);
> + dma_addr = nvme_virt_to_bus(dev, nvmeq->cqes);
> + nvme_writeq(dma_addr, >bar->acq);
>
> result = nvme_enable_ctrl(dev);
> if (result)
> @@ -423,7 +426,7 @@ static int nvme_alloc_cq(struct nvme_dev *dev, u16 qid,
>
> memset(, 0, sizeof(c));
> c.create_cq.opcode = nvme_admin_create_cq;
> - c.create_cq.prp1 = cpu_to_le64((ulong)nvmeq->cqes);
> + c.create_cq.prp1 = cpu_to_le64(nvme_virt_to_bus(dev, nvmeq->cqes));
> c.create_cq.cqid = cpu_to_le16(qid);
> c.create_cq.qsize = cpu_to_le16(nvmeq->q_depth - 1);
> c.create_cq.cq_flags = cpu_to_le16(flags);
> @@ -440,7 +443,7 @@ static int nvme_alloc_sq(struct nvme_dev *dev, u16 qid,
>
> memset(, 0, sizeof(c));
> c.create_sq.opcode = nvme_admin_create_sq;
> - c.create_sq.prp1 = cpu_to_le64((ulong)nvmeq->sq_cmds);
> + c.create_sq.prp1 = cpu_to_le64(nvme_virt_to_bus(dev, nvmeq->sq_cmds));
> c.create_sq.sqid = cpu_to_le16(qid);
> c.create_sq.qsize = cpu_to_le16(nvmeq->q_depth - 1);
> c.create_sq.sq_flags = cpu_to_le16(flags);
> @@ -461,14 +464,14 @@ int nvme_identify(struct nvme_dev *dev, unsigned nsid,
> memset(, 0, sizeof(c));
> c.identify.opcode = nvme_admin_identify;
> c.identify.nsid = cpu_to_le32(nsid);
> - c.identify.prp1 = cpu_to_le64((u64)buffer);
> + c.identify.prp1 = cpu_to_le64(nvme_virt_to_bus(dev, buffer));
>
> length -= (page_size - offset);
> if (length <= 0) {
> c.identify.prp
[RFC PATCH 3/4] nvme: Use pointer for CPU addressed buffers
Pass buffers which use CPU addressing as void pointers. This aligns with
DMA APIs which use void pointers as argument. It will avoid unnecessary
type casts when adding support bus address translations.
Signed-off-by: Stefan Agner
---
drivers/nvme/nvme.c | 50
drivers/nvme/nvme_show.c | 4 ++--
include/nvme.h | 12 +-
3 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index 677e66b1bb..4c4dc7cc4d 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -74,11 +74,11 @@ static int nvme_wait_ready(struct nvme_dev *dev, bool
enabled)
}
static int nvme_setup_prps(struct nvme_dev *dev, u64 *prp2,
- int total_len, u64 dma_addr)
+ int total_len, void *buffer)
{
const u32 page_size = dev->page_size;
const u32 prps_per_page = (page_size >> 3) - 1;
- int offset = dma_addr & (page_size - 1);
+ int offset = (uintptr_t)buffer & (page_size - 1);
u64 *prp_pool;
int length = total_len;
int i, nprps;
@@ -92,10 +92,10 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 *prp2,
}
if (length)
- dma_addr += (page_size - offset);
+ buffer += (page_size - offset);
if (length <= page_size) {
- *prp2 = dma_addr;
+ *prp2 = (u64)buffer;
return 0;
}
@@ -125,11 +125,11 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64
*prp2,
i = 0;
prp_pool += page_size;
}
- *(prp_pool + i++) = cpu_to_le64(dma_addr);
- dma_addr += page_size;
+ *(prp_pool + i++) = cpu_to_le64((u64)buffer);
+ buffer += page_size;
nprps--;
}
- *prp2 = (ulong)dev->prp_pool;
+ *prp2 = (u64)dev->prp_pool;
flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool +
dev->prp_entry_num * sizeof(u64));
@@ -450,42 +450,42 @@ static int nvme_alloc_sq(struct nvme_dev *dev, u16 qid,
}
int nvme_identify(struct nvme_dev *dev, unsigned nsid,
- unsigned cns, dma_addr_t dma_addr)
+ unsigned int cns, void *buffer)
{
struct nvme_command c;
u32 page_size = dev->page_size;
- int offset = dma_addr & (page_size - 1);
+ int offset = (uintptr_t)buffer & (page_size - 1);
int length = sizeof(struct nvme_id_ctrl);
int ret;
memset(, 0, sizeof(c));
c.identify.opcode = nvme_admin_identify;
c.identify.nsid = cpu_to_le32(nsid);
- c.identify.prp1 = cpu_to_le64(dma_addr);
+ c.identify.prp1 = cpu_to_le64((u64)buffer);
length -= (page_size - offset);
if (length <= 0) {
c.identify.prp2 = 0;
} else {
- dma_addr += (page_size - offset);
- c.identify.prp2 = cpu_to_le64(dma_addr);
+ buffer += (page_size - offset);
+ c.identify.prp2 = cpu_to_le64((u64)buffer);
}
c.identify.cns = cpu_to_le32(cns);
- invalidate_dcache_range(dma_addr,
- dma_addr + sizeof(struct nvme_id_ctrl));
+ invalidate_dcache_range((uintptr_t)buffer,
+ (uintptr_t)buffer + sizeof(struct
nvme_id_ctrl));
ret = nvme_submit_admin_cmd(dev, , NULL);
if (!ret)
- invalidate_dcache_range(dma_addr,
- dma_addr + sizeof(struct nvme_id_ctrl));
+ invalidate_dcache_range((uintptr_t)buffer,
+ (uintptr_t)buffer + sizeof(struct
nvme_id_ctrl));
return ret;
}
int nvme_get_features(struct nvme_dev *dev, unsigned fid, unsigned nsid,
- dma_addr_t dma_addr, u32 *result)
+ void *buffer, u32 *result)
{
struct nvme_command c;
int ret;
@@ -493,7 +493,7 @@ int nvme_get_features(struct nvme_dev *dev, unsigned fid,
unsigned nsid,
memset(, 0, sizeof(c));
c.features.opcode = nvme_admin_get_features;
c.features.nsid = cpu_to_le32(nsid);
- c.features.prp1 = cpu_to_le64(dma_addr);
+ c.features.prp1 = cpu_to_le64((u64)buffer);
c.features.fid = cpu_to_le32(fid);
ret = nvme_submit_admin_cmd(dev, , result);
@@ -513,13 +513,13 @@ int nvme_get_features(struct nvme_dev *dev, unsigned fid,
unsigned nsid,
}
int nvme_set_features(struct nvme_dev *dev, unsigned fid, unsigned dword11,
- dma_addr_t dma_addr, u32 *result)
+ void *buffer, u32 *result)
{
struct nvme_command c;
memset(, 0, sizeof(c));
c.features.opcode = nvme_admin_set_features;
- c.features.prp1 = cpu_to_le64
[RFC PATCH 4/4] nvme: translate virtual addresses into the bus's address space
So far we've been content with passing physical/CPU addresses when
configuring memory addresses into NVMe controllers, but not all
platforms have buses with transparent mappings. Specifically the
Raspberry Pi 4 might introduce an offset to memory accesses incoming
from its PCIe port.
Introduce nvme_virt_to_bus() and nvme_bus_to_virt() to cater with these
limitations, and make sure we don't break non DM users.
For devices where PCIe's view of host memory doesn't match the memory
as seen by the CPU.
A similar change has been introduced for XHCI controller with
commit 1a474559d90a ("xhci: translate virtual addresses into the bus's
address space").
Signed-off-by: Stefan Agner
---
drivers/nvme/nvme.c | 32 ++--
drivers/nvme/nvme.h | 15 +++
2 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index 4c4dc7cc4d..0b7082d71b 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -95,7 +95,7 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 *prp2,
buffer += (page_size - offset);
if (length <= page_size) {
- *prp2 = (u64)buffer;
+ *prp2 = nvme_virt_to_bus(dev, buffer);
return 0;
}
@@ -120,16 +120,16 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64
*prp2,
i = 0;
while (nprps) {
if (i == prps_per_page) {
- u64 next_prp_list = (u64)prp_pool + page_size;
- *(prp_pool + i) = cpu_to_le64(next_prp_list);
+ u64 next = nvme_virt_to_bus(dev, prp_pool + page_size);
+ *(prp_pool + i) = cpu_to_le64(next);
i = 0;
prp_pool += page_size;
}
- *(prp_pool + i++) = cpu_to_le64((u64)buffer);
+ *(prp_pool + i++) = cpu_to_le64(nvme_virt_to_bus(dev, buffer));
buffer += page_size;
nprps--;
}
- *prp2 = (u64)dev->prp_pool;
+ *prp2 = nvme_virt_to_bus(dev, dev->prp_pool);
flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool +
dev->prp_entry_num * sizeof(u64));
@@ -356,6 +356,7 @@ static int nvme_configure_admin_queue(struct nvme_dev *dev)
int result;
u32 aqa;
u64 cap = dev->cap;
+ u64 dma_addr;
struct nvme_queue *nvmeq;
/* most architectures use 4KB as the page size */
unsigned page_shift = 12;
@@ -396,8 +397,10 @@ static int nvme_configure_admin_queue(struct nvme_dev *dev)
dev->ctrl_config |= NVME_CC_IOSQES | NVME_CC_IOCQES;
writel(aqa, >bar->aqa);
- nvme_writeq((ulong)nvmeq->sq_cmds, >bar->asq);
- nvme_writeq((ulong)nvmeq->cqes, >bar->acq);
+ dma_addr = nvme_virt_to_bus(dev, nvmeq->sq_cmds);
+ nvme_writeq(dma_addr, >bar->asq);
+ dma_addr = nvme_virt_to_bus(dev, nvmeq->cqes);
+ nvme_writeq(dma_addr, >bar->acq);
result = nvme_enable_ctrl(dev);
if (result)
@@ -423,7 +426,7 @@ static int nvme_alloc_cq(struct nvme_dev *dev, u16 qid,
memset(, 0, sizeof(c));
c.create_cq.opcode = nvme_admin_create_cq;
- c.create_cq.prp1 = cpu_to_le64((ulong)nvmeq->cqes);
+ c.create_cq.prp1 = cpu_to_le64(nvme_virt_to_bus(dev, nvmeq->cqes));
c.create_cq.cqid = cpu_to_le16(qid);
c.create_cq.qsize = cpu_to_le16(nvmeq->q_depth - 1);
c.create_cq.cq_flags = cpu_to_le16(flags);
@@ -440,7 +443,7 @@ static int nvme_alloc_sq(struct nvme_dev *dev, u16 qid,
memset(, 0, sizeof(c));
c.create_sq.opcode = nvme_admin_create_sq;
- c.create_sq.prp1 = cpu_to_le64((ulong)nvmeq->sq_cmds);
+ c.create_sq.prp1 = cpu_to_le64(nvme_virt_to_bus(dev, nvmeq->sq_cmds));
c.create_sq.sqid = cpu_to_le16(qid);
c.create_sq.qsize = cpu_to_le16(nvmeq->q_depth - 1);
c.create_sq.sq_flags = cpu_to_le16(flags);
@@ -461,14 +464,14 @@ int nvme_identify(struct nvme_dev *dev, unsigned nsid,
memset(, 0, sizeof(c));
c.identify.opcode = nvme_admin_identify;
c.identify.nsid = cpu_to_le32(nsid);
- c.identify.prp1 = cpu_to_le64((u64)buffer);
+ c.identify.prp1 = cpu_to_le64(nvme_virt_to_bus(dev, buffer));
length -= (page_size - offset);
if (length <= 0) {
c.identify.prp2 = 0;
} else {
buffer += (page_size - offset);
- c.identify.prp2 = cpu_to_le64((u64)buffer);
+ c.identify.prp2 = cpu_to_le64(nvme_virt_to_bus(dev, buffer));
}
c.identify.cns = cpu_to_le32(cns);
@@ -493,7 +496,7 @@ int nvme_get_features(struct nvme_dev *dev, unsigned fid,
unsigned nsid,
memset(, 0, sizeof(c));
c.features.opcode = nvme_admin_get_feature
[RFC PATCH 1/4] Revert "nvme: Correct the prps per page calculation method"
This reverts commit 859b33c948945f7904f60a2c12a3792d356d51ad. If there is more than one PRP List the last entry is a pointer to the next list. From the NVM Express specification: "The last entry within a memory page, as indicated by the memory page size in the CC.MPS field, shall be a PRP List pointer if there is more than a single memory page of data to be transferred." For the purpose of calculating the number of pages required for PRP lists we should always assume that the last entry is required for the next PRP list. Signed-off-by: Stefan Agner Cc: Wesley Sheng --- drivers/nvme/nvme.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c index f6465ea7f4..1ae3001a90 100644 --- a/drivers/nvme/nvme.c +++ b/drivers/nvme/nvme.c @@ -81,7 +81,7 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 *prp2, u64 *prp_pool; int length = total_len; int i, nprps; - u32 prps_per_page = page_size >> 3; + u32 prps_per_page = (page_size >> 3) - 1; u32 num_pages; length -= (page_size - offset); -- 2.33.0
[RFC PATCH 2/4] nvme: improve readability of nvme_setup_prps()
Improve readability by introducing consts, reuse consts where
appropriate and adding variables with discriptive name.
Signed-off-by: Stefan Agner
---
drivers/nvme/nvme.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index 1ae3001a90..677e66b1bb 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -76,12 +76,12 @@ static int nvme_wait_ready(struct nvme_dev *dev, bool
enabled)
static int nvme_setup_prps(struct nvme_dev *dev, u64 *prp2,
int total_len, u64 dma_addr)
{
- u32 page_size = dev->page_size;
+ const u32 page_size = dev->page_size;
+ const u32 prps_per_page = (page_size >> 3) - 1;
int offset = dma_addr & (page_size - 1);
u64 *prp_pool;
int length = total_len;
int i, nprps;
- u32 prps_per_page = (page_size >> 3) - 1;
u32 num_pages;
length -= (page_size - offset);
@@ -119,9 +119,9 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 *prp2,
prp_pool = dev->prp_pool;
i = 0;
while (nprps) {
- if (i == ((page_size >> 3) - 1)) {
- *(prp_pool + i) = cpu_to_le64((ulong)prp_pool +
- page_size);
+ if (i == prps_per_page) {
+ u64 next_prp_list = (u64)prp_pool + page_size;
+ *(prp_pool + i) = cpu_to_le64(next_prp_list);
i = 0;
prp_pool += page_size;
}
--
2.33.0
Re: [PATCH] ARM: bcm283x: change the virtual address of the XHCI PCI device base
On 2021-06-17 11:22, Marek Szyprowski wrote:
> Move the XHCI PCI device base up in the virtual address space. This fixes
> initialization failure observed with newer Raspberry Pi firmware, later
> than 63b1922311 ("firmware: arm_loader: Update armstubs with those from
> PR 117). It looks that chosing 0xff80 as the XHCI PCI device base
> conflicts with the updated ARM/VideoCore firmware.
>
> This also requires to reduce the size of the mapped PCI device region
> from 8MiB to 4MiB to fit into 32bit address space. This is still enough
> for the XHCI PCI device.
>
> Signed-off-by: Marek Szyprowski
> ---
> This fixes the issue observed on ARM 32bit after upgrading the RPi4
> firmware files, described some time ago here:
> https://lists.denx.de/pipermail/u-boot/2021-February/442317.html
This also fixes an issue we are seeing in Home Assistant:
https://github.com/home-assistant/operating-system/issues/1490
It does seem that it depends on the binary size (since USB enumeration
worked with 2021.04 at one point, but after enabling more configurations
it caused issues).
So:
Tested-by: Stefan Agner
I've seen that this did not make it into master yet, which tree is this
expected to get merged through?
--
Stefan
> ---
> arch/arm/mach-bcm283x/init.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
> index 49027ce0a2..9803499985 100644
> --- a/arch/arm/mach-bcm283x/init.c
> +++ b/arch/arm/mach-bcm283x/init.c
> @@ -14,7 +14,7 @@
> #include
>
> #define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS 0x6UL
> -#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE 0x80UL
> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE 0x40UL
>
> #ifdef CONFIG_ARM64
> #include
> @@ -148,7 +148,7 @@ int mach_cpu_init(void)
>
> #ifdef CONFIG_ARMV7_LPAE
> #ifdef CONFIG_TARGET_RPI_4_32B
> -#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT 0xff80UL
> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT 0xffc0UL
> #include
> #include
[PATCH v2] arm64: dts: meson: odroidc2: readd PHY reset properties
The sync of the device tree and dt-bindings from Linux v5.6-rc2
11a48a5a18c6 ("Linux 5.6-rc2") causes Ethernet to break on some
ODROID-C2. The PHY seems to need proper reset timing to be functional
in U-Boot and Linux afterwards. Readd the old PHY reset bindings for
dwmac until we support the new bindings in the PHY node.
Fixes: dd5f2351e99a ("arm64: dts: meson: sync dt and bindings from v5.6-rc2")
Signed-off-by: Stefan Agner
---
arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi
b/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi
index 90087b00db..5a2be8171e 100644
--- a/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi
+++ b/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi
@@ -29,6 +29,12 @@
};
};
+ {
+ snps,reset-gpio = < GPIOZ_14 0>;
+ snps,reset-delays-us = <0 1 100>;
+ snps,reset-active-low;
+};
+
{
status = "disabled";
};
--
2.31.1
[PATCH] arm64: dts: meson: odroidc2: readd PHY reset properties
The sync of the device tree and dt-bindings from Linux v5.6-rc2
11a48a5a18c6 ("Linux 5.6-rc2") causes Ethernet to break on some
ODROID-C2. The PHY seems to need proper reset timing to be functional
in U-Boot and Linux afterwards. Readd the old PHY reset bindings for
dwmac until we support the new bindings in the PHY node.
Fixes: dd5f2351e99a ("arm64: dts: meson: sync dt and bindings from v5.6-rc2")
Signed-off-by: Stefan Agner
---
arch/arm/dts/meson-gxbb-odroidc2.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/meson-gxbb-odroidc2.dts
b/arch/arm/dts/meson-gxbb-odroidc2.dts
index 70fcfb7b06..8b80bbc90b 100644
--- a/arch/arm/dts/meson-gxbb-odroidc2.dts
+++ b/arch/arm/dts/meson-gxbb-odroidc2.dts
@@ -188,6 +188,10 @@
phy-handle = <_phy0>;
phy-mode = "rgmii";
+ snps,reset-gpio = < GPIOZ_14 0>;
+ snps,reset-delays-us = <0 1 100>;
+ snps,reset-active-low;
+
amlogic,tx-delay-ns = <2>;
mdio {
--
2.31.1
Re: [PATCH] arm64: dts: meson: fix PHY deassert timing requirements
On 2021-04-07 16:29, Neil Armstrong wrote:
> On 07/04/2021 16:21, Stefan Agner wrote:
>> On 2021-04-07 15:31, Neil Armstrong wrote:
>>> Hi,
>>>
>>> On 06/04/2021 19:47, Stefan Agner wrote:
>>>> The sync of the device tree and dt-bindings from Linux v5.6-rc2
>>>> 11a48a5a18c6 ("Linux 5.6-rc2") causes Ethernet to break on some
>>>> ODROID-C2.
>>>>
>>>> Meanwhile a fix to increase the reset timing has been added to Linux.
>>>> Instead of reverting the offending commit, use the new reset timing
>>>> from upstream Linux commit c183c406c432 ("arm64: dts: meson: fix PHY
>>>> deassert timing requirements").
>>>>
>>>> Fixes: dd5f2351e99a ("arm64: dts: meson: sync dt and bindings from
>>>> v5.6-rc2")
>>>> Signed-off-by: Stefan Agner
>>>> ---
>>>> arch/arm/dts/meson-g12b-odroid-n2.dtsi | 2 +-
>>>> arch/arm/dts/meson-gxbb-nanopi-k2.dts | 2 +-
>>>> arch/arm/dts/meson-gxbb-odroidc2.dts | 2 +-
>>>> arch/arm/dts/meson-gxm-khadas-vim2.dts | 2 +-
>>>> 4 files changed, 4 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/arch/arm/dts/meson-g12b-odroid-n2.dtsi
>>>> b/arch/arm/dts/meson-g12b-odroid-n2.dtsi
>>>> index 6982632ae6..39a09661c5 100644
>>>> --- a/arch/arm/dts/meson-g12b-odroid-n2.dtsi
>>>> +++ b/arch/arm/dts/meson-g12b-odroid-n2.dtsi
>>>> @@ -413,7 +413,7 @@
>>>>max-speed = <1000>;
>>>>
>>>>reset-assert-us = <1>;
>>>> - reset-deassert-us = <3>;
>>>> + reset-deassert-us = <8>;
>>>
>>> In fact, these are not used by current U-boot, support for
>>> reset/deassert in PHY node
>>> is not yet supported in U-Boot. This first step was to switch to
>>> DM_MDIO and use the
>>> proper Designware glue, the second step is to find how to make use of
>>> these properties.
>>
>> Hm, that is strange, I have users reporting that this patch fixes the
>> issue on their devices. I guess it might be that the problem does not
>> always appear and it was just (bad) luck.
>>
>>>
>>> Concerning the patch, I'll prefer you sync the DT with v5.11 instead.
>>
>> We have multiple reports of non-working ODROID-C2 which worked in
>> previous U-Boot releases:
>> https://github.com/home-assistant/operating-system/issues/1202
>>
>> Similar reports exist in Armbian Forums as well.
>>
>> Until we have proper PHY reset/deassert support, I'd suggest to revert
>> dd5f2351e99a ("arm64: dts: meson: sync dt and bindings from v5.6-rc2")
>> partially then...
>
> Reverting this is clearly not a solution, the intermediate solution is to
> put back the previous reset properties like it was done for multiple boards
> like in arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi :
Yes, that is what I meant with revert ... partially. :)
I'll send a patch.
--
Stefan
>
> ==
> diff --git a/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi
> b/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi
> index 90087b00db..f1e6914351 100644
> --- a/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi
> +++ b/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi
> @@ -29,6 +29,12 @@
> };
> };
>
> + {
> +snps,reset-gpio = < GPIOZ_14 0>;
> +snps,reset-delays-us = <0 1 100>;
> +snps,reset-active-low;
> +};
> +
> {
> status = "disabled";
> };
> ==
>
> Neil
>>
>> --
>> Stefan
>>
>>
>>>
>>> Neil
>>>
>>>>reset-gpios = < GPIOZ_15 (GPIO_ACTIVE_LOW |
>>>> GPIO_OPEN_DRAIN)>;
>>>>
>>>>interrupt-parent = <_intc>;
>>>> diff --git a/arch/arm/dts/meson-gxbb-nanopi-k2.dts
>>>> b/arch/arm/dts/meson-gxbb-nanopi-k2.dts
>>>> index 7be3e35409..de27beafe9 100644
>>>> --- a/arch/arm/dts/meson-gxbb-nanopi-k2.dts
>>>> +++ b/arch/arm/dts/meson-gxbb-nanopi-k2.dts
>>>> @@ -165,7 +165,7 @@
>>>>reg = <0>;
>>>>
>>>>reset-assert-us = <1>;
>>>> - reset-deassert-us = <3>;
>>>> + r
Re: [PATCH] arm64: dts: meson: fix PHY deassert timing requirements
On 2021-04-07 15:31, Neil Armstrong wrote:
> Hi,
>
> On 06/04/2021 19:47, Stefan Agner wrote:
>> The sync of the device tree and dt-bindings from Linux v5.6-rc2
>> 11a48a5a18c6 ("Linux 5.6-rc2") causes Ethernet to break on some
>> ODROID-C2.
>>
>> Meanwhile a fix to increase the reset timing has been added to Linux.
>> Instead of reverting the offending commit, use the new reset timing
>> from upstream Linux commit c183c406c432 ("arm64: dts: meson: fix PHY
>> deassert timing requirements").
>>
>> Fixes: dd5f2351e99a ("arm64: dts: meson: sync dt and bindings from v5.6-rc2")
>> Signed-off-by: Stefan Agner
>> ---
>> arch/arm/dts/meson-g12b-odroid-n2.dtsi | 2 +-
>> arch/arm/dts/meson-gxbb-nanopi-k2.dts | 2 +-
>> arch/arm/dts/meson-gxbb-odroidc2.dts | 2 +-
>> arch/arm/dts/meson-gxm-khadas-vim2.dts | 2 +-
>> 4 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/dts/meson-g12b-odroid-n2.dtsi
>> b/arch/arm/dts/meson-g12b-odroid-n2.dtsi
>> index 6982632ae6..39a09661c5 100644
>> --- a/arch/arm/dts/meson-g12b-odroid-n2.dtsi
>> +++ b/arch/arm/dts/meson-g12b-odroid-n2.dtsi
>> @@ -413,7 +413,7 @@
>> max-speed = <1000>;
>>
>> reset-assert-us = <1>;
>> -reset-deassert-us = <3>;
>> +reset-deassert-us = <8>;
>
> In fact, these are not used by current U-boot, support for
> reset/deassert in PHY node
> is not yet supported in U-Boot. This first step was to switch to
> DM_MDIO and use the
> proper Designware glue, the second step is to find how to make use of
> these properties.
Hm, that is strange, I have users reporting that this patch fixes the
issue on their devices. I guess it might be that the problem does not
always appear and it was just (bad) luck.
>
> Concerning the patch, I'll prefer you sync the DT with v5.11 instead.
We have multiple reports of non-working ODROID-C2 which worked in
previous U-Boot releases:
https://github.com/home-assistant/operating-system/issues/1202
Similar reports exist in Armbian Forums as well.
Until we have proper PHY reset/deassert support, I'd suggest to revert
dd5f2351e99a ("arm64: dts: meson: sync dt and bindings from v5.6-rc2")
partially then...
--
Stefan
>
> Neil
>
>> reset-gpios = < GPIOZ_15 (GPIO_ACTIVE_LOW |
>> GPIO_OPEN_DRAIN)>;
>>
>> interrupt-parent = <_intc>;
>> diff --git a/arch/arm/dts/meson-gxbb-nanopi-k2.dts
>> b/arch/arm/dts/meson-gxbb-nanopi-k2.dts
>> index 7be3e35409..de27beafe9 100644
>> --- a/arch/arm/dts/meson-gxbb-nanopi-k2.dts
>> +++ b/arch/arm/dts/meson-gxbb-nanopi-k2.dts
>> @@ -165,7 +165,7 @@
>> reg = <0>;
>>
>> reset-assert-us = <1>;
>> -reset-deassert-us = <3>;
>> +reset-deassert-us = <8>;
>> reset-gpios = < GPIOZ_14 GPIO_ACTIVE_LOW>;
>>
>> interrupt-parent = <_intc>;
>> diff --git a/arch/arm/dts/meson-gxbb-odroidc2.dts
>> b/arch/arm/dts/meson-gxbb-odroidc2.dts
>> index 70fcfb7b06..50de1d01e5 100644
>> --- a/arch/arm/dts/meson-gxbb-odroidc2.dts
>> +++ b/arch/arm/dts/meson-gxbb-odroidc2.dts
>> @@ -200,7 +200,7 @@
>> reg = <0>;
>>
>> reset-assert-us = <1>;
>> -reset-deassert-us = <3>;
>> +reset-deassert-us = <8>;
>> reset-gpios = < GPIOZ_14 GPIO_ACTIVE_LOW>;
>>
>> interrupt-parent = <_intc>;
>> diff --git a/arch/arm/dts/meson-gxm-khadas-vim2.dts
>> b/arch/arm/dts/meson-gxm-khadas-vim2.dts
>> index bff8ec2c1c..e38d9e50ca 100644
>> --- a/arch/arm/dts/meson-gxm-khadas-vim2.dts
>> +++ b/arch/arm/dts/meson-gxm-khadas-vim2.dts
>> @@ -194,7 +194,7 @@
>> reg = <0>;
>>
>> reset-assert-us = <1>;
>> -reset-deassert-us = <3>;
>> +reset-deassert-us = <8>;
>> reset-gpios = < GPIOZ_14 GPIO_ACTIVE_LOW>;
>>
>> interrupt-parent = <_intc>;
>>
[PATCH] arm64: dts: meson: fix PHY deassert timing requirements
The sync of the device tree and dt-bindings from Linux v5.6-rc2
11a48a5a18c6 ("Linux 5.6-rc2") causes Ethernet to break on some
ODROID-C2.
Meanwhile a fix to increase the reset timing has been added to Linux.
Instead of reverting the offending commit, use the new reset timing
from upstream Linux commit c183c406c432 ("arm64: dts: meson: fix PHY
deassert timing requirements").
Fixes: dd5f2351e99a ("arm64: dts: meson: sync dt and bindings from v5.6-rc2")
Signed-off-by: Stefan Agner
---
arch/arm/dts/meson-g12b-odroid-n2.dtsi | 2 +-
arch/arm/dts/meson-gxbb-nanopi-k2.dts | 2 +-
arch/arm/dts/meson-gxbb-odroidc2.dts | 2 +-
arch/arm/dts/meson-gxm-khadas-vim2.dts | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/meson-g12b-odroid-n2.dtsi
b/arch/arm/dts/meson-g12b-odroid-n2.dtsi
index 6982632ae6..39a09661c5 100644
--- a/arch/arm/dts/meson-g12b-odroid-n2.dtsi
+++ b/arch/arm/dts/meson-g12b-odroid-n2.dtsi
@@ -413,7 +413,7 @@
max-speed = <1000>;
reset-assert-us = <1>;
- reset-deassert-us = <3>;
+ reset-deassert-us = <8>;
reset-gpios = < GPIOZ_15 (GPIO_ACTIVE_LOW |
GPIO_OPEN_DRAIN)>;
interrupt-parent = <_intc>;
diff --git a/arch/arm/dts/meson-gxbb-nanopi-k2.dts
b/arch/arm/dts/meson-gxbb-nanopi-k2.dts
index 7be3e35409..de27beafe9 100644
--- a/arch/arm/dts/meson-gxbb-nanopi-k2.dts
+++ b/arch/arm/dts/meson-gxbb-nanopi-k2.dts
@@ -165,7 +165,7 @@
reg = <0>;
reset-assert-us = <1>;
- reset-deassert-us = <3>;
+ reset-deassert-us = <8>;
reset-gpios = < GPIOZ_14 GPIO_ACTIVE_LOW>;
interrupt-parent = <_intc>;
diff --git a/arch/arm/dts/meson-gxbb-odroidc2.dts
b/arch/arm/dts/meson-gxbb-odroidc2.dts
index 70fcfb7b06..50de1d01e5 100644
--- a/arch/arm/dts/meson-gxbb-odroidc2.dts
+++ b/arch/arm/dts/meson-gxbb-odroidc2.dts
@@ -200,7 +200,7 @@
reg = <0>;
reset-assert-us = <1>;
- reset-deassert-us = <3>;
+ reset-deassert-us = <8>;
reset-gpios = < GPIOZ_14 GPIO_ACTIVE_LOW>;
interrupt-parent = <_intc>;
diff --git a/arch/arm/dts/meson-gxm-khadas-vim2.dts
b/arch/arm/dts/meson-gxm-khadas-vim2.dts
index bff8ec2c1c..e38d9e50ca 100644
--- a/arch/arm/dts/meson-gxm-khadas-vim2.dts
+++ b/arch/arm/dts/meson-gxm-khadas-vim2.dts
@@ -194,7 +194,7 @@
reg = <0>;
reset-assert-us = <1>;
- reset-deassert-us = <3>;
+ reset-deassert-us = <8>;
reset-gpios = < GPIOZ_14 GPIO_ACTIVE_LOW>;
interrupt-parent = <_intc>;
--
2.31.1
[PATCH v2] nvme: Use only 32-bit accesses in nvme_writeq/nvme_readq
There might be hardware configurations where 64-bit data accesses
to NVMe registers are not supported properly. This patch removes
the readq/writeq so always two 32-bit accesses are used to read/write
64-bit NVMe registers, similarly as it is done in Linux kernel.
This patch fixes operation of NVMe devices on RPi4 Broadcom BCM2711 SoC
based board, where the PCIe Root Complex, which is attached to the
system through the SCB bridge.
Even though the architecture is 64-bit the PCIe BAR is 32-bit and likely
the 64-bit wide register accesses initiated by the CPU are not properly
translated to a sequence of 32-bit PCIe accesses.
nvme_readq(), for example, always returns same value in upper and lower
32-bits, e.g. 0x3c033fff3c033fff which lead to NVMe devices to fail
probing.
This fix is analogous to commit 8e2ab05000ab ("usb: xhci: Use only
32-bit accesses in xhci_writeq/xhci_readq").
Cc: Sylwester Nawrocki
Cc: Nicolas Saenz Julienne
Cc: Matthias Brugger
Reviewed-by: Stefan Roese
Reviewed-by: Bin Meng
Signed-off-by: Stefan Agner
---
Changes in v2:
- Fix subject and message to reflect NVMe change
drivers/nvme/nvme.h | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/nvme/nvme.h b/drivers/nvme/nvme.h
index 0e8cb221a7..aa4b3bac67 100644
--- a/drivers/nvme/nvme.h
+++ b/drivers/nvme/nvme.h
@@ -535,28 +535,20 @@ struct nvme_completion {
*/
static inline u64 nvme_readq(__le64 volatile *regs)
{
-#if BITS_PER_LONG == 64
- return readq(regs);
-#else
__u32 *ptr = (__u32 *)regs;
u64 val_lo = readl(ptr);
u64 val_hi = readl(ptr + 1);
return val_lo + (val_hi << 32);
-#endif
}
static inline void nvme_writeq(const u64 val, __le64 volatile *regs)
{
-#if BITS_PER_LONG == 64
- writeq(val, regs);
-#else
__u32 *ptr = (__u32 *)regs;
u32 val_lo = lower_32_bits(val);
u32 val_hi = upper_32_bits(val);
writel(val_lo, ptr);
writel(val_hi, ptr + 1);
-#endif
}
struct nvme_bar {
--
2.29.2
Re: [PATCH] usb: xhci: Use only 32-bit accesses in nvme_writeq/nvme_readq
On 2020-12-30 02:36, Bin Meng wrote:
> Hi Stefan,
>
> On Wed, Dec 30, 2020 at 3:37 AM Stefan Agner wrote:
>
> The tag is wrong. Should be nvme:
Thanks for pointing out. Will send a v2.
FWIW, the send to amlogic ML was accidentially.
--
Stefan
>
>>
>> There might be hardware configurations where 64-bit data accesses
>> to NVMe registers are not supported properly. This patch removes
>> the readq/writeq so always two 32-bit accesses are used to read/write
>> 64-bit NVMe registers, similarly as it is done in Linux kernel.
>>
>> This patch fixes operation of NVMe devices on RPi4 Broadcom
>> BCM2711 SoC based board, where the VL805 USB XHCI controller is
>> connected to the PCIe Root Complex, which is attached to the system
>> through the SCB bridge.
>>
>> Even though the architecture is 64-bit the PCIe BAR is 32-bit and likely
>> the 64-bit wide register accesses initiated by the CPU are not properly
>> translated to a sequence of 32-bit PCIe accesses.
>> nvme_readq(), for example, always returns same value in upper and lower
>> 32-bits, e.g. 0x3c033fff3c033fff which lead to NVMe devices to fail
>> probing.
>>
>> This fix is analogous to commit 8e2ab05000ab ("usb: xhci: Use only
>> 32-bit accesses in xhci_writeq/xhci_readq").
>>
>> Cc: Sylwester Nawrocki
>> Cc: Zhikang Zhang
>> Cc: Nicolas Saenz Julienne
>> Cc: Matthias Brugger
>> Signed-off-by: Stefan Agner
>> ---
>>
>> drivers/nvme/nvme.h | 8
>> 1 file changed, 8 deletions(-)
>>
>
> Otherwise, LGTM:
>
> Reviewed-by: Bin Meng
[PATCH] usb: xhci: Use only 32-bit accesses in nvme_writeq/nvme_readq
There might be hardware configurations where 64-bit data accesses
to NVMe registers are not supported properly. This patch removes
the readq/writeq so always two 32-bit accesses are used to read/write
64-bit NVMe registers, similarly as it is done in Linux kernel.
This patch fixes operation of NVMe devices on RPi4 Broadcom
BCM2711 SoC based board, where the VL805 USB XHCI controller is
connected to the PCIe Root Complex, which is attached to the system
through the SCB bridge.
Even though the architecture is 64-bit the PCIe BAR is 32-bit and likely
the 64-bit wide register accesses initiated by the CPU are not properly
translated to a sequence of 32-bit PCIe accesses.
nvme_readq(), for example, always returns same value in upper and lower
32-bits, e.g. 0x3c033fff3c033fff which lead to NVMe devices to fail
probing.
This fix is analogous to commit 8e2ab05000ab ("usb: xhci: Use only
32-bit accesses in xhci_writeq/xhci_readq").
Cc: Sylwester Nawrocki
Cc: Zhikang Zhang
Cc: Nicolas Saenz Julienne
Cc: Matthias Brugger
Signed-off-by: Stefan Agner
---
drivers/nvme/nvme.h | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/nvme/nvme.h b/drivers/nvme/nvme.h
index 0e8cb221a7..aa4b3bac67 100644
--- a/drivers/nvme/nvme.h
+++ b/drivers/nvme/nvme.h
@@ -535,28 +535,20 @@ struct nvme_completion {
*/
static inline u64 nvme_readq(__le64 volatile *regs)
{
-#if BITS_PER_LONG == 64
- return readq(regs);
-#else
__u32 *ptr = (__u32 *)regs;
u64 val_lo = readl(ptr);
u64 val_hi = readl(ptr + 1);
return val_lo + (val_hi << 32);
-#endif
}
static inline void nvme_writeq(const u64 val, __le64 volatile *regs)
{
-#if BITS_PER_LONG == 64
- writeq(val, regs);
-#else
__u32 *ptr = (__u32 *)regs;
u32 val_lo = lower_32_bits(val);
u32 val_hi = upper_32_bits(val);
writel(val_lo, ptr);
writel(val_hi, ptr + 1);
-#endif
}
struct nvme_bar {
--
2.29.2
Re: [PATCH] mmc: meson-gx: change clock phase value on AGX SoCs
On 2020-12-15 06:19, Jaehoon Chung wrote:
> Hi,
>
> On 12/15/20 3:58 AM, Neil Armstrong wrote:
>> Hi,
>>
>> On 07/12/2020 18:15, Stefan Agner wrote:
>>> Amlogic AGX SoCs seem to have issue communicating with some eMMC
>>> devices (in particular with a Micron 128GB eMMC 5.1). The device
>>> is detected with 1-bit bus width, and at higher temperature loading
>>> pretty much anything from the storage fails: (e.g. fs_devread read error
>>> - block).
>>>
>>> When phase is set to 270° it is detected with 8-bit bus width and is
>>> working fine accross all temperatures.
>>
>> This is new to G12, I only had such issues and reports for SM1 only until
>> now.
>>
>>>
>>> Signed-off-by: Stefan Agner
>>> ---
>>> Hi Neil,
>>>
>>> I debugged this issue today on an ODROID N2+ not booting reliably. I am
>>> not sure if we can safely switch to 270° for all SoCs with
>>> amlogic,meson-axg-mmc, but I guess we have to try and see what happens?
>>> I will do a bit broader testing in the comming days here.
>>
>> amlogic,meson-axg-mmc covers too much SoCs, I'll prefer if you introduce
>> an u-boot only amlogic,meson-g12b-mmc compatible like I did for SM1.
>>
>>>
>>> Btw, I do see that 180° is also set in Linux. Do you have a patch to
>>> address this in Linux?
>>
>> I never had such reports on Linux, I think because eMMCs are directly used
>> in HS200 mode and 180° is the right configuration for HS200...
>
> I have checked mainline kernel with Odroid-C4.
> Linux Kernel is using PHASE_180 and enabled HS200 by default. That's
> why this issue doesn't report.
> It's working fine with PHASE_180. But if mode is downgrade as DDR50 or
> lower mode than HS200.
> It's also broken, like u-boot.
That make sense. It seems that HS200 is really required to have a stable
SD communication on this platform.
>
> When i have changed from PHASE_180 to PHASE_270, it's working fine
> about all modes.
>
> [2.689222] mmc1: new HS200 MMC card at address 0001
> [2.692070] xhci-hcd xhci-hcd.0.auto: irq 34, io mem 0xff50
> [2.697491] mmcblk1: mmc1:0001 BJTD4R 29.1 GiB
>
> Current meson_gx_mmc doesn't support HS200 on u-boot side. (It needs
> to implement more things.)
> So I think that it's right way to set to PHASE_270 on U-boot side.
> If it needs to fix this on kernel side, i will send the patch.
After more testing, we found that a 64GB eMMC stopped working when using
270°. We now switched back to 180° and lowered frequency to 24MHz. This
setting works on all eMMCs we had around to test, across temperature
ranges (booting when cold, as well as booting when heated up slightly).
Downstream U-Boot seems to use 40MHz clock, and switches phase depending
on frequency:
co-phase 0x3, tx-dly 0, clock 40
co-phase 0x1, tx-dly 0, clock 4000
I tried to implement this in a quick hack, but it did not work reliably.
However, as far as I can tell downstream U-Boot also does HS200 link
training etc... So it seems HS200 link training is required to make
things work properly.
--
Stefan
>
> Best Regards,
> Jaehoon Chung
>
>>
>> Neil
>>
>>>
>>> --
>>> Stefan
>>>
>>>
>>> arch/arm/include/asm/arch-meson/sd_emmc.h | 1 +
>>> drivers/mmc/meson_gx_mmc.c| 9 +
>>> 2 files changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h
>>> b/arch/arm/include/asm/arch-meson/sd_emmc.h
>>> index cb16f75fc6..db5e058098 100644
>>> --- a/arch/arm/include/asm/arch-meson/sd_emmc.h
>>> +++ b/arch/arm/include/asm/arch-meson/sd_emmc.h
>>> @@ -14,6 +14,7 @@
>>>
>>> enum meson_gx_mmc_compatible {
>>> MMC_COMPATIBLE_GX,
>>> + MMC_COMPATIBLE_AGX,
>>> MMC_COMPATIBLE_SM1,
>>> };
>>>
>>> diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
>>> index 5facbfdd9a..2c27113c10 100644
>>> --- a/drivers/mmc/meson_gx_mmc.c
>>> +++ b/drivers/mmc/meson_gx_mmc.c
>>> @@ -64,14 +64,15 @@ static void meson_mmc_config_clock(struct mmc *mmc)
>>>
>>> /*
>>> * SM1 SoCs doesn't work fine over 50MHz with CLK_CO_PHASE_180
>>> +* AGX SoCs don't work reliable with some eMMCs with CLK_CO_PHASE_180
>>> * If CLK_CO_PHASE_270 is used, it's more stable than other.
>>> * Other SoCs use CLK_CO_PHASE_180 by default.
>>> * It needs to find what is a proper value about each SoCs.
>>> */
[PATCH] mmc: meson-gx: change clock phase value on AGX SoCs
Amlogic AGX SoCs seem to have issue communicating with some eMMC
devices (in particular with a Micron 128GB eMMC 5.1). The device
is detected with 1-bit bus width, and at higher temperature loading
pretty much anything from the storage fails: (e.g. fs_devread read error
- block).
When phase is set to 270° it is detected with 8-bit bus width and is
working fine accross all temperatures.
Signed-off-by: Stefan Agner
---
Hi Neil,
I debugged this issue today on an ODROID N2+ not booting reliably. I am
not sure if we can safely switch to 270° for all SoCs with
amlogic,meson-axg-mmc, but I guess we have to try and see what happens?
I will do a bit broader testing in the comming days here.
Btw, I do see that 180° is also set in Linux. Do you have a patch to
address this in Linux?
--
Stefan
arch/arm/include/asm/arch-meson/sd_emmc.h | 1 +
drivers/mmc/meson_gx_mmc.c| 9 +
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h
b/arch/arm/include/asm/arch-meson/sd_emmc.h
index cb16f75fc6..db5e058098 100644
--- a/arch/arm/include/asm/arch-meson/sd_emmc.h
+++ b/arch/arm/include/asm/arch-meson/sd_emmc.h
@@ -14,6 +14,7 @@
enum meson_gx_mmc_compatible {
MMC_COMPATIBLE_GX,
+ MMC_COMPATIBLE_AGX,
MMC_COMPATIBLE_SM1,
};
diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
index 5facbfdd9a..2c27113c10 100644
--- a/drivers/mmc/meson_gx_mmc.c
+++ b/drivers/mmc/meson_gx_mmc.c
@@ -64,14 +64,15 @@ static void meson_mmc_config_clock(struct mmc *mmc)
/*
* SM1 SoCs doesn't work fine over 50MHz with CLK_CO_PHASE_180
+* AGX SoCs don't work reliable with some eMMCs with CLK_CO_PHASE_180
* If CLK_CO_PHASE_270 is used, it's more stable than other.
* Other SoCs use CLK_CO_PHASE_180 by default.
* It needs to find what is a proper value about each SoCs.
*/
- if (meson_gx_mmc_is_compatible(mmc->dev, MMC_COMPATIBLE_SM1))
- meson_mmc_clk |= CLK_CO_PHASE_270;
- else
+ if (meson_gx_mmc_is_compatible(mmc->dev, MMC_COMPATIBLE_GX))
meson_mmc_clk |= CLK_CO_PHASE_180;
+ else
+ meson_mmc_clk |= CLK_CO_PHASE_270;
/* 180 phase tx clock */
meson_mmc_clk |= CLK_TX_PHASE_000;
@@ -327,7 +328,7 @@ int meson_mmc_bind(struct udevice *dev)
static const struct udevice_id meson_mmc_match[] = {
{ .compatible = "amlogic,meson-gx-mmc", .data = MMC_COMPATIBLE_GX },
- { .compatible = "amlogic,meson-axg-mmc", .data = MMC_COMPATIBLE_GX },
+ { .compatible = "amlogic,meson-axg-mmc", .data = MMC_COMPATIBLE_AGX },
{ .compatible = "amlogic,meson-sm1-mmc", .data = MMC_COMPATIBLE_SM1 },
{ /* sentinel */ }
};
--
2.29.2
[PATCH 2/2] meson: Add soc_rev to environment
From: Pascal Vizeli
Add SoC revision to environment. This can be useful to select the
correct device tree at runtime (N2/N2+).
Signed-off-by: Pascal Vizeli
Signed-off-by: Stefan Agner
---
arch/arm/include/asm/arch-meson/boot.h | 4
arch/arm/mach-meson/board-info.c | 12
board/amlogic/odroid-n2/odroid-n2.c| 5 +
3 files changed, 21 insertions(+)
diff --git a/arch/arm/include/asm/arch-meson/boot.h
b/arch/arm/include/asm/arch-meson/boot.h
index a90fe55081..c67d12d06c 100644
--- a/arch/arm/include/asm/arch-meson/boot.h
+++ b/arch/arm/include/asm/arch-meson/boot.h
@@ -7,6 +7,8 @@
#ifndef __MESON_BOOT_H__
#define __MESON_BOOT_H__
+#include
+
/* Boot device */
#define BOOT_DEVICE_RESERVED0
#define BOOT_DEVICE_EMMC1
@@ -17,4 +19,6 @@
int meson_get_boot_device(void);
+int meson_get_soc_rev(char *buff, size_t buff_len);
+
#endif /* __MESON_BOOT_H__ */
diff --git a/arch/arm/mach-meson/board-info.c b/arch/arm/mach-meson/board-info.c
index a0bcf38f29..90e7dfaa3c 100644
--- a/arch/arm/mach-meson/board-info.c
+++ b/arch/arm/mach-meson/board-info.c
@@ -187,3 +187,15 @@ int show_board_info(void)
return 0;
}
+
+int meson_get_soc_rev(char *buff, size_t buff_len)
+{
+ unsigned int socinfo;
+
+ socinfo = get_socinfo();
+ if (!socinfo)
+ return -1;
+
+ /* Write SoC info */
+ return snprintf(buff, buff_len, "%x", socinfo_to_minor(socinfo));
+}
diff --git a/board/amlogic/odroid-n2/odroid-n2.c
b/board/amlogic/odroid-n2/odroid-n2.c
index caf7fd6810..dc0d933a39 100644
--- a/board/amlogic/odroid-n2/odroid-n2.c
+++ b/board/amlogic/odroid-n2/odroid-n2.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#define EFUSE_MAC_OFFSET 20
#define EFUSE_MAC_SIZE 12
@@ -23,6 +24,10 @@ int misc_init_r(void)
char efuse_mac_addr[EFUSE_MAC_SIZE], tmp[3];
ssize_t len;
+ if (IS_ENABLED(CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG) &&
+ meson_get_soc_rev(tmp, sizeof(tmp)) > 0)
+ env_set("soc_rev", tmp);
+
meson_eth_init(PHY_INTERFACE_MODE_RGMII, 0);
if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
--
2.29.2
[PATCH 1/2] ARM: meson: isolate loading of socinfo
Move loading of socinfo into a separate function so the value can be
reused later.
Signed-off-by: Stefan Agner
---
arch/arm/mach-meson/board-info.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-meson/board-info.c b/arch/arm/mach-meson/board-info.c
index e61d1adb10..a0bcf38f29 100644
--- a/arch/arm/mach-meson/board-info.c
+++ b/arch/arm/mach-meson/board-info.c
@@ -131,7 +131,7 @@ static void print_board_model(void)
printf("Model: %s\n", model ? model : "Unknown");
}
-int show_board_info(void)
+static unsigned int get_socinfo(void)
{
struct regmap *regmap;
int nodeoffset, ret;
@@ -163,8 +163,20 @@ int show_board_info(void)
return 0;
}
+ return socinfo;
+}
+
+int show_board_info(void)
+{
+ unsigned int socinfo;
+
/* print board information */
print_board_model();
+
+ socinfo = get_socinfo();
+ if (!socinfo)
+ return 0;
+
printf("SoC: Amlogic Meson %s (%s) Revision %x:%x (%x:%x)\n",
socinfo_to_soc_id(socinfo),
socinfo_to_package_id(socinfo),
--
2.29.2
RPi4 hang when booting from USB mass storage
Hi,
When trying to boot rpi_4_32b_defconfig of U-Boot 2020.10 (or master)
using a USB flash drive, U-Boot hangs early at:
U-Boot 2020.10 (Nov 20 2020 - 10:25:26 +0100)
DRAM: 3.9 GiB
The weird thing is that at this point U-Boot does not access USB/SD card
at all, still it matters if it got booted via USB or SD card.
What I noticed is that dram_init mem_size is different depending on
where I boot from, from USB:
U-Boot 2020.10-dirty (Nov 20 2020 - 11:35:45 +0100)
DRAM: dram_init...
dram_init 993001472
dram_init_banksize
3.9 GiB
And from SD-card:
U-Boot 2020.10-dirty (Nov 20 2020 - 11:37:06 +0100)
DRAM: dram_init...
dram_init 994050048
dram_init_banksize
3.9 GiB
I tried different firmware versions from stable branch (7caead9, ef72c17
used in current Raspberry Pi OS and latest 2ba11f2) and U-Boot versions
back to 2020.01 without success.
What does work is forcing the size in dram_init() to 512M:
@@ -267,6 +268,8 @@ int dram_init(void)
}
gd->ram_size = msg->get_arm_mem.body.resp.mem_size;
+ gd->ram_size = SZ_512M;
+ printf("forcing dram_init %lld\n", gd->ram_size);
return 0;
}
I did try RPi 4 Model B 2GB and 4GB. Any idea?
--
Stefan
Re: RPi3: serial console
On 2020-11-04 15:05, Stefan Agner wrote: > On 2020-10-16 03:28, Ricardo Salveti wrote: >> On Tue, Oct 13, 2020 at 11:04 AM Peter Robinson wrote: >>> >>> > >> Hello Matthias, >>> > >> >>> > >> I have upgraded the Raspberry 3 firmware from raspi3-firmware >>> > >> (1.20190215-1+deb10u4) to raspi-firmware (1.20200601-3) >>> > >> [https://packages.debian.org/bullseye/raspi-firmware]. >>> > >> >>> > >> After the upgrade the output of U-Boot on the serial console is >>> > >> complete >>> > >> gibberish as if the baudrate were incorrect. The output from the Linux >>> > >> kernel is fine at 115200 baud. >>> > > >>> > > I've seen similar on all firmware since around mid April up until >>> > > recently, it seems to be fixed with releases in Oct (I'm using one >>> > > from Oct 8th), I'm not sure if it can be fixed in U-Boot but it seems >>> > > to be due to a change in the firmware. >>> > >>> > Thanks for confirming the problem. >>> >>> For reference I have found a number of other problems with recent >>> firmwares and 2020.10 release: >>> * U-Boot crashes on a RPi4 8Gb model if you don't have a display connected >>> [1] >>> * It doesn't boot, not sure if it's a crash or something else, you >>> just get the rainbow screen, if you don't have the uart enabled in >>> config.txt (ie just using a display for output). >> >> Noticed the same as well here (boots fine only with enable_uart=1). >> While playing over with the files I noticed it works fine with the >> latest firmware when using an older bcm2710-rpi-3-b-plus.dtb >> (placed together with the firmware). If I use the latest >> bcm2710-rpi-3-b-plus.dtb from the 5.4 downstream kernel, it doesn't >> work (only tested on rpi3-b-plus). >> >> This is with CONFIG_OF_BOARD=y, if I use CONFIG_OF_EMBED instead it >> works just fine (which gives me the impression that u-boot might not >> be happy with the dtb generated by the firmware when enable_uart is >> not set). > > What we noticed is adding brcm,bcm2835-pl011 compatible to the UARTs > makes U-Boot 2020.10 boot even *without* enable_uart=1. dm shows that > with this change CONFIG_BCM283X_PL011_SERIAL is in use... > > From what I understand, this driver checks if the UART is muxed, and if > not bails out. So I guess without that compatible string, when the > regular PL011 driver is used, it seems that U-Boot tries to initialize > UART and fails? I looked a bit more into this and I think I made some progress. This is with downstream Linux 5.4, but I don't think it is relevant as downstream uses now the same UART bindings as upstream. It seems when U-Boot is falling back to the Bluetooth (mini) UART and crashes when using it as serial console. I noticed when setting "enable_uart=0" and "dtoverlay=disable-bt" U-Boot does show a serial console on the GPIO pins 14/15. The console is running on UART0, the first PL011 UART: serial0 [ + ] serial_pl01x | |-- serial@7e201000 Another method which works using "dtparam=uart0=off" and "enable_uart=0", which essentially disables UART0 and UART1 in device tree. U-Boot won't show a serial console, but the system boots... I think the reason why adding "brcm,bcm2835-pl011" to compatible works is because it makes probing of uart0 (the PL011 UART) in U-Boot fail, and hence U-Boot won't fallback to this UARTs. Note that "enable_uart=0" is equal to *not* setting enable_uart at all according to documentation and confirmed in the discussion at https://github.com/raspberrypi/firmware/issues/1483 (on RPi 3/4 anyways). What I also noticed that uart2 makes trouble (which is also PL011 in RPi4): "dtparam=uart0=off", "enable_uart=0" and "dtoverlay=uart2" make sure that only uart2 is available to U-Boot. It makes the system crash well... Disabling CONFIG_PL01X_SERIAL (which is only possible with a Kconfig change in arch/arm/Kconfig) makes the system boot in all cases... -- Stefan
Re: RPi3: serial console
On 2020-10-16 03:28, Ricardo Salveti wrote: > On Tue, Oct 13, 2020 at 11:04 AM Peter Robinson wrote: >> >> > >> Hello Matthias, >> > >> >> > >> I have upgraded the Raspberry 3 firmware from raspi3-firmware >> > >> (1.20190215-1+deb10u4) to raspi-firmware (1.20200601-3) >> > >> [https://packages.debian.org/bullseye/raspi-firmware]. >> > >> >> > >> After the upgrade the output of U-Boot on the serial console is complete >> > >> gibberish as if the baudrate were incorrect. The output from the Linux >> > >> kernel is fine at 115200 baud. >> > > >> > > I've seen similar on all firmware since around mid April up until >> > > recently, it seems to be fixed with releases in Oct (I'm using one >> > > from Oct 8th), I'm not sure if it can be fixed in U-Boot but it seems >> > > to be due to a change in the firmware. >> > >> > Thanks for confirming the problem. >> >> For reference I have found a number of other problems with recent >> firmwares and 2020.10 release: >> * U-Boot crashes on a RPi4 8Gb model if you don't have a display connected >> [1] >> * It doesn't boot, not sure if it's a crash or something else, you >> just get the rainbow screen, if you don't have the uart enabled in >> config.txt (ie just using a display for output). > > Noticed the same as well here (boots fine only with enable_uart=1). > While playing over with the files I noticed it works fine with the > latest firmware when using an older bcm2710-rpi-3-b-plus.dtb > (placed together with the firmware). If I use the latest > bcm2710-rpi-3-b-plus.dtb from the 5.4 downstream kernel, it doesn't > work (only tested on rpi3-b-plus). > > This is with CONFIG_OF_BOARD=y, if I use CONFIG_OF_EMBED instead it > works just fine (which gives me the impression that u-boot might not > be happy with the dtb generated by the firmware when enable_uart is > not set). What we noticed is adding brcm,bcm2835-pl011 compatible to the UARTs makes U-Boot 2020.10 boot even *without* enable_uart=1. dm shows that with this change CONFIG_BCM283X_PL011_SERIAL is in use... >From what I understand, this driver checks if the UART is muxed, and if not bails out. So I guess without that compatible string, when the regular PL011 driver is used, it seems that U-Boot tries to initialize UART and fails? -- Stefan
Re: [PATCH] usb: storage: increase retries to 20
On 2020-09-20 21:01, Stefan Agner wrote:
> A JMicron JMS583 based NVMe to USB 3.1 enclosure connected to a Raspberry
> Pi 4 fails to enumerate as a USB Mass Storage device on first try:
>
> ...
> startig USB...
> Bus xhci_pci: Register 5000420 NbrPorts 5
> Starting the controller
> USB XHCI 1.00
> scanning bus xhci_pci for devces... Device NOT ready
> Request Sense returned 02 04 01
> 4 USB Device(s) found
> scanning usb for storage devices... 0 Sorage Device(s) found
It turned out, the device was not sufficiently powered. Even after I was
able to use U-Boot to boot from it, Linux reported USB resets every ~30s
or so.
Supplying the device with enough power (e.g. by connecting via powered
USB 3.0 Hub) things started to work better: The device was always ready
below 1s (8 tries). So it seems that the default of 10 is actually good
enough also for this device.
--
Stefan
>
> However, it consistently works on the second try. It seems that the
> device takes longer than 1s to detect the media. With debug enabled
> it shows that the 11th retry count typically works.
>
> Increase retries to 20 for a startup time of up to 2s.
>
> Signed-off-by: Stefan Agner
> ---
> common/usb_storage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/usb_storage.c b/common/usb_storage.c
> index ff25441995..04910de21f 100644
> --- a/common/usb_storage.c
> +++ b/common/usb_storage.c
> @@ -1019,7 +1019,7 @@ static int usb_request_sense(struct scsi_cmd
> *srb, struct us_data *ss)
>
> static int usb_test_unit_ready(struct scsi_cmd *srb, struct us_data *ss)
> {
> - int retries = 10;
> + int retries = 20;
>
> do {
> memset(>cmd[0], 0, 12);
[PATCH] usb: storage: increase retries to 20
A JMicron JMS583 based NVMe to USB 3.1 enclosure connected to a Raspberry
Pi 4 fails to enumerate as a USB Mass Storage device on first try:
...
startig USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devces... Device NOT ready
Request Sense returned 02 04 01
4 USB Device(s) found
scanning usb for storage devices... 0 Sorage Device(s) found
However, it consistently works on the second try. It seems that the
device takes longer than 1s to detect the media. With debug enabled
it shows that the 11th retry count typically works.
Increase retries to 20 for a startup time of up to 2s.
Signed-off-by: Stefan Agner
---
common/usb_storage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/usb_storage.c b/common/usb_storage.c
index ff25441995..04910de21f 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -1019,7 +1019,7 @@ static int usb_request_sense(struct scsi_cmd *srb, struct
us_data *ss)
static int usb_test_unit_ready(struct scsi_cmd *srb, struct us_data *ss)
{
- int retries = 10;
+ int retries = 20;
do {
memset(>cmd[0], 0, 12);
--
2.28.0
Re: RPi4 U-Boot freeze
On 2020-09-19 23:20, Sean Anderson wrote:
> On 9/19/20 7:55 AM, Stefan Agner wrote:
>> On 2020-09-14 10:15, Matthias Brugger wrote:
>>> On 10/09/2020 23:12, Stefan Agner wrote:
>>>> On 2020-09-07 16:36, Peter Robinson wrote:
>>>>>> Any thoughts on this issue?
>>>>>
>>>>> Any reason why you're using 2020.01 and not at least 2020.07, or at
>>>>> least seeing if it's reproducible on 2020.10-rc3? The RPi4 support has
>>>>> changed quite a bit since then I suspect.
>>>>>
>>>>
>>>> Hi Peter,
>>>>
>>>> It's a stable release and we support a couple of devices with the same
>>>> U-Boot version. I'd rather prefer to stay with 2020.01 for RPi4 as well.
>>>>
>>>> We are on 2020.07 on development branch, and it does work fine there. So
>>>> I thought it can't be that hard, just bisect and backport whatever fixes
>>>> it... Unfortunately, it seems that there is no particular commit which
>>>> fixes it (the bisect ended up in a random unrelated commit, and it seems
>>>> that the issue appears/disappears depending on alignment/size...).
>>>>
>>>> I also did applied pretty much every RPi4 related commit made after
>>>> 2020.01 up until master back to 2020.01, no success either.
>>>>
>>>
>>> Which version of the Raspberry Pi firmware did you use?
>>> Unfortunately changes in the FW breaks stuff on U-Boot from time to time.
>>>
>>
>> Ok, I am now able to reproduce the issue on master as well as 2020.07
>> with standard rpi_4_32b_defconfig, but I still need to have parts of a
>> change which seems to trigger the issue in. From what I can tell, the
>> change *really* should not lead to a freeze. The change is just
>> accessing global variables from the data section... (see below).
>>
>> To me it still seems as if relocation somehow did not work correctly in
>> one way or another.
>>
>> Are there maybe restrictions in U-Boot when the data section can be
>> accessed? E.g. is it not legal to access the data section from the
>> serial driver?
>
> One thing bit me recently, and might be relevant here. Because
> putc_retry is initialized to zero, it is located in bss and not data.
> In U-Boot, bss is not accessable before relocation. The serial driver is
> one of the devices which U-Boot needs before relocating, so setting
> putc_retry may overwrite data in the device tree. To get around this,
> you could try adding __attribute__((section(".data"))) to that variable.
Thanks a lot for that hint, I did not know that bss is not accessible
before relocation.
That indeed seems to be the problem! Actually just removing the
initialization is fine here, as global variables are initialized to zero
anyways (from what it seems also in U-Boot's implementation).
I wonder if some compile time warning/check could be introduced, but I
guess there is not really a way to know what code is used before
relocation.
Anyways, thanks a lot, sorry for the noise. We can consider this solved.
--
Stefan
>
> --Sean
>
>>
>>
>> diff --git a/drivers/serial/serial_bcm283x_mu.c
>> b/drivers/serial/serial_bcm283x_mu.c
>> index 8a4af87eb6..74de6801ab 100644
>> --- a/drivers/serial/serial_bcm283x_mu.c
>> +++ b/drivers/serial/serial_bcm283x_mu.c
>> @@ -50,7 +50,8 @@ struct bcm283x_mu_regs {
>> struct bcm283x_mu_priv {
>> struct bcm283x_mu_regs *regs;
>> };
>> -
>> +static char *fs_argv[15];
>> +static uint32_t putc_retry = 0;
>> static int bcm283x_mu_serial_getc(struct udevice *dev);
>>
>> static int bcm283x_mu_serial_setbrg(struct udevice *dev, int baudrate)
>> @@ -95,6 +96,8 @@ static int bcm283x_mu_serial_putc(struct udevice *dev,
>> const char data)
>> struct bcm283x_mu_priv *priv = dev_get_priv(dev);
>> struct bcm283x_mu_regs *regs = priv->regs;
>>
>> + putc_retry++;
>> +
>> /* Wait until there is space in the FIFO */
>> if (!(readl(>lsr) & BCM283X_MU_LSR_TX_EMPTY))
>> return -EAGAIN;
>> @@ -162,6 +165,10 @@ static int bcm283x_mu_serial_probe(struct udevice
>> *dev)
>> struct bcm283x_mu_priv *priv = dev_get_priv(dev);
>> fdt_addr_t addr;
>>
>> + /* Make sure compiler does not optimize out this fs_argv
>> instance */
>> + if (fs_argv[0])
>> + fs_argv[0] = "test";
>> +
>> /* Don't spawn the device if it's not muxed */
>> if (!bcm283x
Re: RPi4 U-Boot freeze
On 2020-09-14 10:15, Matthias Brugger wrote:
> On 10/09/2020 23:12, Stefan Agner wrote:
>> On 2020-09-07 16:36, Peter Robinson wrote:
>>>> Any thoughts on this issue?
>>>
>>> Any reason why you're using 2020.01 and not at least 2020.07, or at
>>> least seeing if it's reproducible on 2020.10-rc3? The RPi4 support has
>>> changed quite a bit since then I suspect.
>>>
>>
>> Hi Peter,
>>
>> It's a stable release and we support a couple of devices with the same
>> U-Boot version. I'd rather prefer to stay with 2020.01 for RPi4 as well.
>>
>> We are on 2020.07 on development branch, and it does work fine there. So
>> I thought it can't be that hard, just bisect and backport whatever fixes
>> it... Unfortunately, it seems that there is no particular commit which
>> fixes it (the bisect ended up in a random unrelated commit, and it seems
>> that the issue appears/disappears depending on alignment/size...).
>>
>> I also did applied pretty much every RPi4 related commit made after
>> 2020.01 up until master back to 2020.01, no success either.
>>
>
> Which version of the Raspberry Pi firmware did you use?
> Unfortunately changes in the FW breaks stuff on U-Boot from time to time.
>
Ok, I am now able to reproduce the issue on master as well as 2020.07
with standard rpi_4_32b_defconfig, but I still need to have parts of a
change which seems to trigger the issue in. From what I can tell, the
change *really* should not lead to a freeze. The change is just
accessing global variables from the data section... (see below).
To me it still seems as if relocation somehow did not work correctly in
one way or another.
Are there maybe restrictions in U-Boot when the data section can be
accessed? E.g. is it not legal to access the data section from the
serial driver?
diff --git a/drivers/serial/serial_bcm283x_mu.c
b/drivers/serial/serial_bcm283x_mu.c
index 8a4af87eb6..74de6801ab 100644
--- a/drivers/serial/serial_bcm283x_mu.c
+++ b/drivers/serial/serial_bcm283x_mu.c
@@ -50,7 +50,8 @@ struct bcm283x_mu_regs {
struct bcm283x_mu_priv {
struct bcm283x_mu_regs *regs;
};
-
+static char *fs_argv[15];
+static uint32_t putc_retry = 0;
static int bcm283x_mu_serial_getc(struct udevice *dev);
static int bcm283x_mu_serial_setbrg(struct udevice *dev, int baudrate)
@@ -95,6 +96,8 @@ static int bcm283x_mu_serial_putc(struct udevice *dev,
const char data)
struct bcm283x_mu_priv *priv = dev_get_priv(dev);
struct bcm283x_mu_regs *regs = priv->regs;
+ putc_retry++;
+
/* Wait until there is space in the FIFO */
if (!(readl(>lsr) & BCM283X_MU_LSR_TX_EMPTY))
return -EAGAIN;
@@ -162,6 +165,10 @@ static int bcm283x_mu_serial_probe(struct udevice
*dev)
struct bcm283x_mu_priv *priv = dev_get_priv(dev);
fdt_addr_t addr;
+ /* Make sure compiler does not optimize out this fs_argv
instance */
+ if (fs_argv[0])
+ fs_argv[0] = "test";
+
/* Don't spawn the device if it's not muxed */
if (!bcm283x_is_serial_muxed())
return -ENODEV;
Most curious of all, it seems that the name (!!!) of the variable
fs_argv matters! I am not sure if that changes order of variables in
data section or something. I can also reproduce the issue with two
compilers (GCC 8.3 and GCC 9.2), so a compiler error seems somewhat
unlikely...
Any ideas? I am a bit out of idea how to debug this (I guess JTAG/gdb
might help, but I don't have such a setup).
FWIW, I plan to just drop the change which seems to at least partially
cause the isssue
(https://github.com/home-assistant/operating-system/blob/dev/buildroot-external/board/raspberrypi/patches/uboot/0002-avoid-block-uart-write.patch).
Still I think there is something wrong which will show itself someday in
a certain configuration.
--
Stefan
> Regards,
> Mathias
>
>> I fear that the problem in fact is still in master, but only appears if
>> certain things align a certain way... That is why I thought I bring it
>> up, to see if anybody else has noticed something along this lines. We do
>> have a rather trimmed down configuration, which might make the problem
>> appear more (fit in a D cache...).
>>
>> I probably will just disable cached around relocation for 2020.01 and
>> see if it resurfaces on development branch.
>>
>> --
>> Stefan
>>
>>
>>>> Just to be sure, I did some memory testing on the 2GB module, but no
>>>> issues found.
>>>>
>>>> I still somehow suspected that something else might be wrong with my
>>>> hardware, so I bought a new RPi4 (this time with 4GB of RAM) but the
>>>> very same with that:
>>>>
>>>> U-Boot 202
Re: RPi4 U-Boot freeze
On 2020-09-14 10:15, Matthias Brugger wrote: > On 10/09/2020 23:12, Stefan Agner wrote: >> On 2020-09-07 16:36, Peter Robinson wrote: >>>> Any thoughts on this issue? >>> >>> Any reason why you're using 2020.01 and not at least 2020.07, or at >>> least seeing if it's reproducible on 2020.10-rc3? The RPi4 support has >>> changed quite a bit since then I suspect. >>> >> >> Hi Peter, >> >> It's a stable release and we support a couple of devices with the same >> U-Boot version. I'd rather prefer to stay with 2020.01 for RPi4 as well. >> >> We are on 2020.07 on development branch, and it does work fine there. So >> I thought it can't be that hard, just bisect and backport whatever fixes >> it... Unfortunately, it seems that there is no particular commit which >> fixes it (the bisect ended up in a random unrelated commit, and it seems >> that the issue appears/disappears depending on alignment/size...). >> >> I also did applied pretty much every RPi4 related commit made after >> 2020.01 up until master back to 2020.01, no success either. >> > > Which version of the Raspberry Pi firmware did you use? > Unfortunately changes in the FW breaks stuff on U-Boot from time to time. The 4GB I left untouched so far, it came with the following setup: pi@raspberrypi:~$ sudo rpi-eeprom-update BCM2711 detected Dedicated VL805 EEPROM detected *** UPDATE AVAILABLE *** BOOTLOADER: update available CURRENT: Mon 15 Jul 12:59:55 UTC 2019 (1563195595) LATEST: Thu 16 Apr 17:11:26 UTC 2020 (1587057086) FW DIR: /lib/firmware/raspberrypi/bootloader/critical VL805: update available CURRENT: 00013701 LATEST: 000137ad The 2GB I did some firmware updates already, currently I ran it with the following settings: pi@raspberrypi:~$ sudo rpi-eeprom-update BCM2711 detected Dedicated VL805 EEPROM detected BOOTLOADER: up-to-date CURRENT: Thu 16 Apr 17:11:26 UTC 2020 (1587057086) LATEST: Thu 16 Apr 17:11:26 UTC 2020 (1587057086) FW DIR: /lib/firmware/raspberrypi/bootloader/critical VL805: up-to-date CURRENT: 000138a1 LATEST: 000137ad I was able to reproduce the issue with U-Boot 2020.07, but I still have two non-upstream patches ontop (I really can't see how they can affect relocation, but they seem to cause a state which makes the issue appear). I try to find a configuration which shows it without non-upstream code. -- Stefan > > Regards, > Mathias > >> I fear that the problem in fact is still in master, but only appears if >> certain things align a certain way... That is why I thought I bring it >> up, to see if anybody else has noticed something along this lines. We do >> have a rather trimmed down configuration, which might make the problem >> appear more (fit in a D cache...). >> >> I probably will just disable cached around relocation for 2020.01 and >> see if it resurfaces on development branch. >> >> -- >> Stefan >> >> >>>> Just to be sure, I did some memory testing on the 2GB module, but no >>>> issues found. >>>> >>>> I still somehow suspected that something else might be wrong with my >>>> hardware, so I bought a new RPi4 (this time with 4GB of RAM) but the >>>> very same with that: >>>> >>>> U-Boot 2020.01 (Aug 23 2020 - 22:02:31 +) >>>> >>>> DRAM: 3.9 GiB >>>> >>>> >>>> I still think there is something wrong with caching. From what I >>>> understand caches are enabled by the RPi (4) firmware. Is it safe to run >>>> 32-bit ARM U-Boot with enabled caches? >>>> >>>> -- >>>> Stefan >>>> >>>> On 2020-08-23 19:06, Stefan Agner wrote: >>>>> Hi, >>>>> >>>>> I noticed a quite common freeze when running 32-bit U-Boot 2020.01 >>>>> (rpi_4_32b_defconfig) on a 2GB RPi4 model: >>>>> >>>>> U-Boot 2020.01 (Aug 07 2020 - 13:00:23 +) >>>>> >>>>> DRAM: 1.9 GiB >>>>> >>>>> >>>>> This happens fairly often, I would say 4 out of 5 boot tries. However, >>>>> if it boots, everything seems to run fine. >>>>> >>>>> The issue seems to go away when using 2020.04 or any newer release, >>>>> however, when trying to find the actual patch fixing the issue using git >>>>> bisect I ended up with a MMC merge request which really seems unrelated >>>>> (36bdcf7f3b). It seems that the problem is quite evasive and disappears >>>>> if certain structure are aligned differently etc. >>&g
Re: RPi4 U-Boot freeze
On 2020-09-07 16:36, Peter Robinson wrote: >> Any thoughts on this issue? > > Any reason why you're using 2020.01 and not at least 2020.07, or at > least seeing if it's reproducible on 2020.10-rc3? The RPi4 support has > changed quite a bit since then I suspect. > Hi Peter, It's a stable release and we support a couple of devices with the same U-Boot version. I'd rather prefer to stay with 2020.01 for RPi4 as well. We are on 2020.07 on development branch, and it does work fine there. So I thought it can't be that hard, just bisect and backport whatever fixes it... Unfortunately, it seems that there is no particular commit which fixes it (the bisect ended up in a random unrelated commit, and it seems that the issue appears/disappears depending on alignment/size...). I also did applied pretty much every RPi4 related commit made after 2020.01 up until master back to 2020.01, no success either. I fear that the problem in fact is still in master, but only appears if certain things align a certain way... That is why I thought I bring it up, to see if anybody else has noticed something along this lines. We do have a rather trimmed down configuration, which might make the problem appear more (fit in a D cache...). I probably will just disable cached around relocation for 2020.01 and see if it resurfaces on development branch. -- Stefan >> Just to be sure, I did some memory testing on the 2GB module, but no >> issues found. >> >> I still somehow suspected that something else might be wrong with my >> hardware, so I bought a new RPi4 (this time with 4GB of RAM) but the >> very same with that: >> >> U-Boot 2020.01 (Aug 23 2020 - 22:02:31 +) >> >> DRAM: 3.9 GiB >> >> >> I still think there is something wrong with caching. From what I >> understand caches are enabled by the RPi (4) firmware. Is it safe to run >> 32-bit ARM U-Boot with enabled caches? >> >> -- >> Stefan >> >> On 2020-08-23 19:06, Stefan Agner wrote: >> > Hi, >> > >> > I noticed a quite common freeze when running 32-bit U-Boot 2020.01 >> > (rpi_4_32b_defconfig) on a 2GB RPi4 model: >> > >> > U-Boot 2020.01 (Aug 07 2020 - 13:00:23 +) >> > >> > DRAM: 1.9 GiB >> > >> > >> > This happens fairly often, I would say 4 out of 5 boot tries. However, >> > if it boots, everything seems to run fine. >> > >> > The issue seems to go away when using 2020.04 or any newer release, >> > however, when trying to find the actual patch fixing the issue using git >> > bisect I ended up with a MMC merge request which really seems unrelated >> > (36bdcf7f3b). It seems that the problem is quite evasive and disappears >> > if certain structure are aligned differently etc. >> > >> > Enabling initcall debugging showed that U-Boot crashes right after >> > relocation: >> > >> > ... >> > initcall: 00016f2c >> > >> > RAM Configuration: >> > Bank #0: 0 948 MiB >> > Bank #1: 4000 1 GiB >> > Bank #2: 0 0 Bytes >> > Bank #3: 0 0 Bytes >> > >> > DRAM: 1.9 GiB >> > initcall: 00016bb8 >> > New Stack Pointer is: 3af6d9e0 >> > initcall: 00016da4 >> > initcall: 00016ef0 >> > initcall: 00016ef8 >> > initcall: 00016d38 >> > Relocation Offset is: 3b375000 >> > Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0 >> > initcall: 00016ec8 [clear_bss] >> > initcall: 0004465c [display_options?? only appears sometimes] >> > >> > >> > I realized when using CONFIG_SYS_(I|D)CACHE_OFF=y the problem seems to >> > disappear. But to be 100% certain that it is cache related, I used my >> > original configuration (which is known to "reliably" freeze), and >> > replaced 00016ec8 with 8688 manually in the binary, essentially >> > swapping out function pointers in "init_sequence_f" [8688 is >> > cleanup_before_linux, which flushes and disables I-cache/D-cache]. And >> > indeed, that hacked up binary does boot reliably every time: >> > >> > ... >> > initcall: 00016f2c >> > >> > RAM Configuration: >> > Bank #0: 0 948 MiB >> > Bank #1: 4000 1 GiB >> > Bank #2: 0 0 Bytes >> > Bank #3: 0 0 Bytes >> > >> > DRAM: 1.9 GiB >> > initcall: 00016bb8 >> > New Stack Pointer is: 3af6d9e0 >> > initcall: 00016da4 >> > initcall: 00016ef0 >> > initcall: 00016ef8 >> > initcall: 00016d38 >> > Relocation Offset is: 3b375000 >> > Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0 >> > initcall: 8688 >> > initcall: 3b38c10c >> > initcall: 3b38c114 >> > initcall: 000172e0 (relocated to 3b38c2e0) >> > initcall: 0001712c (relocated to 3b38c12c) >> > ... >> > >> > From what I understand on RPi4 caches are enabled when entering U-Boot. >> > I was wondering if the relocation code really can handle that? >> > >> > -- >> > Stefan
[PATCH 1/2] rockchip: dts: tinker: move i2c node to shared device tree
The I2C EEPROM is present on Tinker Board S as well. Move the i2c node
to the shared, U-Boot specific rk3288-tinker-u-boot.dtsi device tree.
Cc: Jonas Karlman
Signed-off-by: Stefan Agner
---
arch/arm/dts/rk3288-tinker-u-boot.dtsi | 7 +++
arch/arm/dts/rk3288-tinker.dts | 7 ---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/rk3288-tinker-u-boot.dtsi
b/arch/arm/dts/rk3288-tinker-u-boot.dtsi
index 732aa4f91f..56d10c82ec 100644
--- a/arch/arm/dts/rk3288-tinker-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-tinker-u-boot.dtsi
@@ -17,6 +17,13 @@
rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
};
+ {
+ m24c08@50 {
+ compatible = "at,24c08", "i2c-eeprom";
+ reg = <0x50>;
+ };
+};
+
{
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/rk3288-tinker.dts b/arch/arm/dts/rk3288-tinker.dts
index 4b8405fd82..338670123b 100644
--- a/arch/arm/dts/rk3288-tinker.dts
+++ b/arch/arm/dts/rk3288-tinker.dts
@@ -35,10 +35,3 @@
vbus-supply = <_host>;
status = "okay";
};
-
- {
-m24c08@50 {
-compatible = "at,24c08", "i2c-eeprom";
-reg = <0x50>;
-};
-};
--
2.28.0
[PATCH 2/2] rockchip: dts: tinker: remove unnecessary node
The property reg-shift with the same value is present in the base
device tree already. Remove unnecessary node from rk3288-tinker.dts.
Signed-off-by: Stefan Agner
---
arch/arm/dts/rk3288-tinker.dts | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/dts/rk3288-tinker.dts b/arch/arm/dts/rk3288-tinker.dts
index 338670123b..8b1848c310 100644
--- a/arch/arm/dts/rk3288-tinker.dts
+++ b/arch/arm/dts/rk3288-tinker.dts
@@ -27,10 +27,6 @@
status = "okay";
};
- {
- reg-shift = <2>;
-};
-
_host1 {
vbus-supply = <_host>;
status = "okay";
--
2.28.0
Re: RPi4 U-Boot freeze
Any thoughts on this issue? Just to be sure, I did some memory testing on the 2GB module, but no issues found. I still somehow suspected that something else might be wrong with my hardware, so I bought a new RPi4 (this time with 4GB of RAM) but the very same with that: U-Boot 2020.01 (Aug 23 2020 - 22:02:31 +) DRAM: 3.9 GiB I still think there is something wrong with caching. From what I understand caches are enabled by the RPi (4) firmware. Is it safe to run 32-bit ARM U-Boot with enabled caches? -- Stefan On 2020-08-23 19:06, Stefan Agner wrote: > Hi, > > I noticed a quite common freeze when running 32-bit U-Boot 2020.01 > (rpi_4_32b_defconfig) on a 2GB RPi4 model: > > U-Boot 2020.01 (Aug 07 2020 - 13:00:23 +) > > DRAM: 1.9 GiB > > > This happens fairly often, I would say 4 out of 5 boot tries. However, > if it boots, everything seems to run fine. > > The issue seems to go away when using 2020.04 or any newer release, > however, when trying to find the actual patch fixing the issue using git > bisect I ended up with a MMC merge request which really seems unrelated > (36bdcf7f3b). It seems that the problem is quite evasive and disappears > if certain structure are aligned differently etc. > > Enabling initcall debugging showed that U-Boot crashes right after > relocation: > > ... > initcall: 00016f2c > > RAM Configuration: > Bank #0: 0 948 MiB > Bank #1: 4000 1 GiB > Bank #2: 0 0 Bytes > Bank #3: 0 0 Bytes > > DRAM: 1.9 GiB > initcall: 00016bb8 > New Stack Pointer is: 3af6d9e0 > initcall: 00016da4 > initcall: 00016ef0 > initcall: 00016ef8 > initcall: 00016d38 > Relocation Offset is: 3b375000 > Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0 > initcall: 00016ec8 [clear_bss] > initcall: 0004465c [display_options?? only appears sometimes] > > > I realized when using CONFIG_SYS_(I|D)CACHE_OFF=y the problem seems to > disappear. But to be 100% certain that it is cache related, I used my > original configuration (which is known to "reliably" freeze), and > replaced 00016ec8 with 8688 manually in the binary, essentially > swapping out function pointers in "init_sequence_f" [8688 is > cleanup_before_linux, which flushes and disables I-cache/D-cache]. And > indeed, that hacked up binary does boot reliably every time: > > ... > initcall: 00016f2c > > RAM Configuration: > Bank #0: 0 948 MiB > Bank #1: 4000 1 GiB > Bank #2: 0 0 Bytes > Bank #3: 0 0 Bytes > > DRAM: 1.9 GiB > initcall: 00016bb8 > New Stack Pointer is: 3af6d9e0 > initcall: 00016da4 > initcall: 00016ef0 > initcall: 00016ef8 > initcall: 00016d38 > Relocation Offset is: 3b375000 > Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0 > initcall: 8688 > initcall: 3b38c10c > initcall: 3b38c114 > initcall: 000172e0 (relocated to 3b38c2e0) > initcall: 0001712c (relocated to 3b38c12c) > ... > > From what I understand on RPi4 caches are enabled when entering U-Boot. > I was wondering if the relocation code really can handle that? > > -- > Stefan
RPi4 U-Boot freeze
Hi, I noticed a quite common freeze when running 32-bit U-Boot 2020.01 (rpi_4_32b_defconfig) on a 2GB RPi4 model: U-Boot 2020.01 (Aug 07 2020 - 13:00:23 +) DRAM: 1.9 GiB This happens fairly often, I would say 4 out of 5 boot tries. However, if it boots, everything seems to run fine. The issue seems to go away when using 2020.04 or any newer release, however, when trying to find the actual patch fixing the issue using git bisect I ended up with a MMC merge request which really seems unrelated (36bdcf7f3b). It seems that the problem is quite evasive and disappears if certain structure are aligned differently etc. Enabling initcall debugging showed that U-Boot crashes right after relocation: ... initcall: 00016f2c RAM Configuration: Bank #0: 0 948 MiB Bank #1: 4000 1 GiB Bank #2: 0 0 Bytes Bank #3: 0 0 Bytes DRAM: 1.9 GiB initcall: 00016bb8 New Stack Pointer is: 3af6d9e0 initcall: 00016da4 initcall: 00016ef0 initcall: 00016ef8 initcall: 00016d38 Relocation Offset is: 3b375000 Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0 initcall: 00016ec8 [clear_bss] initcall: 0004465c [display_options?? only appears sometimes] I realized when using CONFIG_SYS_(I|D)CACHE_OFF=y the problem seems to disappear. But to be 100% certain that it is cache related, I used my original configuration (which is known to "reliably" freeze), and replaced 00016ec8 with 8688 manually in the binary, essentially swapping out function pointers in "init_sequence_f" [8688 is cleanup_before_linux, which flushes and disables I-cache/D-cache]. And indeed, that hacked up binary does boot reliably every time: ... initcall: 00016f2c RAM Configuration: Bank #0: 0 948 MiB Bank #1: 4000 1 GiB Bank #2: 0 0 Bytes Bank #3: 0 0 Bytes DRAM: 1.9 GiB initcall: 00016bb8 New Stack Pointer is: 3af6d9e0 initcall: 00016da4 initcall: 00016ef0 initcall: 00016ef8 initcall: 00016d38 Relocation Offset is: 3b375000 Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0 initcall: 8688 initcall: 3b38c10c initcall: 3b38c114 initcall: 000172e0 (relocated to 3b38c2e0) initcall: 0001712c (relocated to 3b38c12c) ... >From what I understand on RPi4 caches are enabled when entering U-Boot. I was wondering if the relocation code really can handle that? -- Stefan
Re: [PATCH v6 0/4] usb: xhci: Load Raspberry Pi 4 VL805's firmware
Hi Nicolas, I do have USB MSD boot working with at least two USB flash drives successfully. I now tried using a USB NVMe enclosure (ICY BOX with a JMicron chip in it). It seems that U-Boot has troubles enumerating the device at first, but "usb reset" helps: U-Boo 2020.07 (Jul 25 2020 - 06:55:15 +) DRAM: 1.9 GiB RPI 4 Model B (0xb03112) MMC: mmcnr@7e30: 1, emmc2@7e34: 0 In:serial Out: serial Err: serial Net: eth0: genet@7d58 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) startig USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devces... Device NOT ready Request Sense returned 02 04 01 4 USB Device(s) found scanning usb for storage devices... 0 Sorage Device(s) found Card did not respond to voltage select! Card did not respond to voltage select! genet@7d58 Waiting for PHY auto negotiation to complete... done BOOTP broadcast 1 DHCP client bound to address 192.168.80.226 (3 ms > Ctrl+C HassOS> HassOS> usb tree USB device tree: 1 Hub (5 Gb/s, 0mA) | U-Boot XHCI Host Controller | +-2 MassStorage (5 Gb/s, 224mA) |JMicron USB 3.1 Storage Device DD56419884B3E | +-3 Hub (480 Mb/s, 100A) | USB2.0 Hub | +-4 Human Interface (12 Mb/s, 98mA) Logitech USB Receiver HassOS> ls usb 0:1 HassOS> usb reset resetting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_ci for devices... 4 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found HassOS>ls usb 0:1 41499 bcm2711-rpi-4-b.dtb 2382 boot.scr 57 cmdline.txt 1785 config.txt overlays/ 488304 u-boot.bin 2272992 start4.elf.orig 2277376 start4.elf 5405 fixup4.dat.orig 5407 fiup4.dat 9 file(s), 1 dir(s) HassOS> usb tree USB device tree: 1 Hub (5 Gb/s, 0mA) | U-Boot XHCI Host Controller | |+-2 Mass Storage (5 Gb/s, 224mA) |JMicron USB 3.1 Storage Device DD56419884B3E | +-3 Hub (480 b/s, 100mA) | USB2.0 Hub | +-4 Human Interface (12 Mb/s, 98mA) Logitech USB Receier The device then boots and works fine. Do you happen to know if there is some tunable in U-Boot which might help? https://github.com/home-assistant/operating-system/issues/796 -- Stefan On 2020-07-19 12:06, Nicolas Saenz Julienne wrote: > Hi Stefan, > > On Sun, 2020-07-19 at 02:37 +0200, Stefan Agner wrote: >> Hi Nicolas, >> >> On 2020-06-29 18:37, Nicolas Saenz Julienne wrote: >> > Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be >> > loaded explicitly. Earlier versions didn't need that as they where using >> > an EEPROM for that purpose. This series takes care of setting up the >> > relevant infrastructure and run the firmware loading routine at the >> > right moment. >> >> I tried using this patchset to boot from a USB mass storage device on >> RPi 4 with 8GB RAM. I updated the EEPROM firmware as well as deployed >> the latest GPU firmware (start4.elf/fixup4.dat) from the firmware master >> branch. I think with that I have new enough/correct versions. >> >> The RPi 4 successfully boots U-Boot from a mass storage device. However, >> U-Boot itself is then not able to access USB. The output always shows >> -110 (timeout). It seems that the VL805 controller is not detected on >> the PCIe bus. Do you happen to know what I might be missing? >> >> I tried current master (which has your patchset merged) as well as your >> vl805 branch on Github. > > > You're probably missing these two patches on your device-tree, they haven't > made it upstream yet, but most likely will soon: > > https://patchwork.ozlabs.org/project/linux-pci/patch/20200629161845.6021-4-nsaenzjulie...@suse.de/ > https://patchwork.ozlabs.org/project/linux-pci/patch/20200629161845.6021-5-nsaenzjulie...@suse.de/ > > Sorry for the hassle! > Nicolas > >> >> U-Boot 2020.07-rc4-00036-gdeb48986ee (Jul 19 2020 - 02:29:44 +0200) >> >> DRAM: 7.9 GiB >> RPI 4 Model B (0xd03114) >> MMC: mmcnr@7e30: 1, emmc2@7e34: 0 >> Loading Environment from FAT... Card did not respond to voltage select! >> In:serial >> Out: vidconsole >> Err: vidconsole >> Net: eth0: genet@7d58 >> PCIe BRCM: link up, 5.0 Gbps x1 (!SSC) >> Device 'pci_0:0.0': seq 0 is in use by 'pcie@7d50' >> starting USB... >> Bus xhci_pci: probe failed, error -110 >> No working controllers found >> Hit any key to stop autoboot: 0 >> U-Boot> pci enum >> U-Boot> pci >> Scanning PCI devices on bus 0 >> BusDevFun VendorId DeviceId Device Class Sub-Cla
Re: [PATCH v6 0/4] usb: xhci: Load Raspberry Pi 4 VL805's firmware
Figured that the device tree deployed on the boot partition indeed still
had the necessary nodes missing...
With that fixed, current master without any further patches detects the
USB controller just fine, and I was able to use at least two different
USB mass storage device just fine!
Sorry for the noise! And thanks for all your work!
--
Stefan
On 2020-07-19 02:37, Stefan Agner wrote:
> Hi Nicolas,
>
> On 2020-06-29 18:37, Nicolas Saenz Julienne wrote:
>> Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be
>> loaded explicitly. Earlier versions didn't need that as they where using
>> an EEPROM for that purpose. This series takes care of setting up the
>> relevant infrastructure and run the firmware loading routine at the
>> right moment.
>
> I tried using this patchset to boot from a USB mass storage device on
> RPi 4 with 8GB RAM. I updated the EEPROM firmware as well as deployed
> the latest GPU firmware (start4.elf/fixup4.dat) from the firmware master
> branch. I think with that I have new enough/correct versions.
>
> The RPi 4 successfully boots U-Boot from a mass storage device. However,
> U-Boot itself is then not able to access USB. The output always shows
> -110 (timeout). It seems that the VL805 controller is not detected on
> the PCIe bus. Do you happen to know what I might be missing?
>
> I tried current master (which has your patchset merged) as well as your
> vl805 branch on Github.
>
>
> U-Boot 2020.07-rc4-00036-gdeb48986ee (Jul 19 2020 - 02:29:44 +0200)
>
> DRAM: 7.9 GiB
> RPI 4 Model B (0xd03114)
> MMC: mmcnr@7e30: 1, emmc2@7e34: 0
> Loading Environment from FAT... Card did not respond to voltage select!
> In:serial
> Out: vidconsole
> Err: vidconsole
> Net: eth0: genet@7d58
> PCIe BRCM: link up, 5.0 Gbps x1 (!SSC)
> Device 'pci_0:0.0': seq 0 is in use by 'pcie@7d50'
> starting USB...
> Bus xhci_pci: probe failed, error -110
> No working controllers found
> Hit any key to stop autoboot: 0
> U-Boot> pci enum
> U-Boot> pci
> Scanning PCI devices on bus 0
> BusDevFun VendorId DeviceId Device Class Sub-Class
> _
> 00.00.00 0x14e4 0x2711 Bridge device 0x04
>
>
> --
> Stefan
>
>>
>> Note that this builds on top of Sylwester Nawrocki's "USB host support
>> for Raspberry Pi 4 board" series.
>>
>> This also depends on a DT/bindings patch available on the linux-mailing
>> lists:
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2205783.html
>>
>> Here is the relevant bit for reference/discussion:
>>
>> {
>>pci@1,0 {
>>#address-cells = <3>;
>>#size-cells = <2>;
>>ranges;
>>
>>reg = <0 0 0 0 0>;
>>
>>usb@1,0 {
>>reg = <0x1 0 0 0 0>;
>>resets = <
>> RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
>>};
>>};
>> };
>>
>> ---
>>
>> Changes since v5:
>> - Properly handle !CONFIG_IS_ENABLED(DM_RESET) in xchi code
>>
>> Changes since v4:
>> - Correct DT PCI topology, I separated the root bridge and controller
>>DT nodes
>> - Get rid of PCI core patch as not needed with correct DT PCI topology
>> - Move reset support to xchi core
>>
>> Changes since v3:
>> - Use reset controller
>>
>> Changes since v2:
>> - Correct comment on patch #1
>> - Address Matthias' comments
>>
>> Changes since v1:
>> - Rename function
>> - Use callback in xhci-pci.c
>>
>> Nicolas Saenz Julienne (4):
>> arm: rpi: Add function to trigger VL805's firmware load
>> reset: Add Raspberry Pi 4 firmware reset controller
>> configs: Enable support for reset controllers on RPi4
>> usb: xhci: Add reset controller support
>>
>> arch/arm/mach-bcm283x/include/mach/mbox.h | 13
>> arch/arm/mach-bcm283x/include/mach/msg.h | 7 +++
>> arch/arm/mach-bcm283x/msg.c | 46 ++
>> configs/rpi_4_32b_defconfig | 1 +
>> configs/rpi_4_defconfig | 1 +
>> configs/rpi_arm64_defconfig | 1 +
>> drivers/reset/Kconfig | 10
>> drivers/reset/Makefile| 1 +
>> drivers/reset/reset-raspberrypi.c | 60 +++
>> drivers/usb/host/xhci-mem.c | 2 +
>> drivers/usb/host/xhci.c | 33 ++
>> .../reset/raspberrypi,firmware-reset.h| 13
>> include/usb/xhci.h| 2 +
>> 13 files changed, 190 insertions(+)
>> create mode 100644 drivers/reset/reset-raspberrypi.c
>> create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h
Re: [PATCH v6 0/4] usb: xhci: Load Raspberry Pi 4 VL805's firmware
Hi Nicolas,
On 2020-06-29 18:37, Nicolas Saenz Julienne wrote:
> Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be
> loaded explicitly. Earlier versions didn't need that as they where using
> an EEPROM for that purpose. This series takes care of setting up the
> relevant infrastructure and run the firmware loading routine at the
> right moment.
I tried using this patchset to boot from a USB mass storage device on
RPi 4 with 8GB RAM. I updated the EEPROM firmware as well as deployed
the latest GPU firmware (start4.elf/fixup4.dat) from the firmware master
branch. I think with that I have new enough/correct versions.
The RPi 4 successfully boots U-Boot from a mass storage device. However,
U-Boot itself is then not able to access USB. The output always shows
-110 (timeout). It seems that the VL805 controller is not detected on
the PCIe bus. Do you happen to know what I might be missing?
I tried current master (which has your patchset merged) as well as your
vl805 branch on Github.
U-Boot 2020.07-rc4-00036-gdeb48986ee (Jul 19 2020 - 02:29:44 +0200)
DRAM: 7.9 GiB
RPI 4 Model B (0xd03114)
MMC: mmcnr@7e30: 1, emmc2@7e34: 0
Loading Environment from FAT... Card did not respond to voltage select!
In:serial
Out: vidconsole
Err: vidconsole
Net: eth0: genet@7d58
PCIe BRCM: link up, 5.0 Gbps x1 (!SSC)
Device 'pci_0:0.0': seq 0 is in use by 'pcie@7d50'
starting USB...
Bus xhci_pci: probe failed, error -110
No working controllers found
Hit any key to stop autoboot: 0
U-Boot> pci enum
U-Boot> pci
Scanning PCI devices on bus 0
BusDevFun VendorId DeviceId Device Class Sub-Class
_
00.00.00 0x14e4 0x2711 Bridge device 0x04
--
Stefan
>
> Note that this builds on top of Sylwester Nawrocki's "USB host support
> for Raspberry Pi 4 board" series.
>
> This also depends on a DT/bindings patch available on the linux-mailing lists:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2205783.html
>
> Here is the relevant bit for reference/discussion:
>
> {
>pci@1,0 {
>#address-cells = <3>;
>#size-cells = <2>;
>ranges;
>
>reg = <0 0 0 0 0>;
>
>usb@1,0 {
>reg = <0x1 0 0 0 0>;
>resets = <
> RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
>};
>};
> };
>
> ---
>
> Changes since v5:
> - Properly handle !CONFIG_IS_ENABLED(DM_RESET) in xchi code
>
> Changes since v4:
> - Correct DT PCI topology, I separated the root bridge and controller
>DT nodes
> - Get rid of PCI core patch as not needed with correct DT PCI topology
> - Move reset support to xchi core
>
> Changes since v3:
> - Use reset controller
>
> Changes since v2:
> - Correct comment on patch #1
> - Address Matthias' comments
>
> Changes since v1:
> - Rename function
> - Use callback in xhci-pci.c
>
> Nicolas Saenz Julienne (4):
> arm: rpi: Add function to trigger VL805's firmware load
> reset: Add Raspberry Pi 4 firmware reset controller
> configs: Enable support for reset controllers on RPi4
> usb: xhci: Add reset controller support
>
> arch/arm/mach-bcm283x/include/mach/mbox.h | 13
> arch/arm/mach-bcm283x/include/mach/msg.h | 7 +++
> arch/arm/mach-bcm283x/msg.c | 46 ++
> configs/rpi_4_32b_defconfig | 1 +
> configs/rpi_4_defconfig | 1 +
> configs/rpi_arm64_defconfig | 1 +
> drivers/reset/Kconfig | 10
> drivers/reset/Makefile| 1 +
> drivers/reset/reset-raspberrypi.c | 60 +++
> drivers/usb/host/xhci-mem.c | 2 +
> drivers/usb/host/xhci.c | 33 ++
> .../reset/raspberrypi,firmware-reset.h| 13
> include/usb/xhci.h| 2 +
> 13 files changed, 190 insertions(+)
> create mode 100644 drivers/reset/reset-raspberrypi.c
> create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h
Re: [U-Boot] [PATCH v1 2/2] MAINTAINERS: change colibri_imx6/imx6ull/t30/vf maintainers
On 2019-11-04 12:56, Igor Opaniuk wrote: > From: Igor Opaniuk > > Take over maintainership for colibri_imx6/imx6ull/t30/vf modules. > > Signed-off-by: Igor Opaniuk Acked-by: Stefan Agner Thanks for looking after those boards! -- Stefan > --- > > board/toradex/colibri-imx6ull/MAINTAINERS | 2 +- > board/toradex/colibri_imx7/MAINTAINERS| 2 +- > board/toradex/colibri_t30/MAINTAINERS | 2 +- > board/toradex/colibri_vf/MAINTAINERS | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/board/toradex/colibri-imx6ull/MAINTAINERS > b/board/toradex/colibri-imx6ull/MAINTAINERS > index c8199fa60a..4107d29876 100644 > --- a/board/toradex/colibri-imx6ull/MAINTAINERS > +++ b/board/toradex/colibri-imx6ull/MAINTAINERS > @@ -1,5 +1,5 @@ > Colibri iMX6ULL > -M: Stefan Agner > +M: Igor Opaniuk > W: http://developer.toradex.com/software/linux/linux-software > W: https://www.toradex.com/community > S: Maintained > diff --git a/board/toradex/colibri_imx7/MAINTAINERS > b/board/toradex/colibri_imx7/MAINTAINERS > index cd0f9c9b2d..178dece797 100644 > --- a/board/toradex/colibri_imx7/MAINTAINERS > +++ b/board/toradex/colibri_imx7/MAINTAINERS > @@ -1,5 +1,5 @@ > Colibri iMX7 > -M: Stefan Agner > +M: Igor Opaniuk > W: http://developer.toradex.com/software/linux/linux-software > W: https://www.toradex.com/community > S: Maintained > diff --git a/board/toradex/colibri_t30/MAINTAINERS > b/board/toradex/colibri_t30/MAINTAINERS > index 73b8e5d099..00c03c89b8 100644 > --- a/board/toradex/colibri_t30/MAINTAINERS > +++ b/board/toradex/colibri_t30/MAINTAINERS > @@ -1,5 +1,5 @@ > Colibri T30 > -M: Stefan Agner > +M: Igor Opaniuk > S: Maintained > F: board/toradex/colibri_t30/ > F: include/configs/colibri_t30.h > diff --git a/board/toradex/colibri_vf/MAINTAINERS > b/board/toradex/colibri_vf/MAINTAINERS > index 66b2150986..f94cc0fbe2 100644 > --- a/board/toradex/colibri_vf/MAINTAINERS > +++ b/board/toradex/colibri_vf/MAINTAINERS > @@ -1,5 +1,5 @@ > Colibri VFxx > -M: Stefan Agner > +M: Igor Opaniuk > W: http://developer.toradex.com/software/linux/linux-software > W: https://www.toradex.com/community > S: Maintained ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] colibri_imx7: boot kernel in secure mode
On 2019-07-03 15:50, Igor Opaniuk wrote:
> From: Igor Opaniuk
>
> NXP downstream kernel uses legacy method to enable other cores,
> which requires kernel to run in a security mode (althought upstream kernel
> uses PSCI for this).
>
> As we're using NXP kernel in our BSPs, lets enable this by default.
I think I mentioned it internally, but just to be clear: I do not agree
with this patch.
Upstream U-Boot should be able to boot upstream Linux. I'd rather prefer
to carry that patch in our downstream fork (or set the bootm_boot_mode
environment in our boot script).
--
Stefan
>
> Signed-off-by: Igor Opaniuk
> ---
>
> include/configs/colibri_imx7.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h
> index 40173b18fa..5408577661 100644
> --- a/include/configs/colibri_imx7.h
> +++ b/include/configs/colibri_imx7.h
> @@ -164,7 +164,8 @@
> "${board}/flash_blk.img && source ${loadaddr}\0" \
> "setup=setenv setupargs " \
> "console=tty1 console=${console}" \
> - ",${baudrate}n8 ${memargs} consoleblank=0\0" \
> + ",${baudrate}n8 ${memargs} consoleblank=0; " \
> + "setenv bootm_boot_mode sec\0" \
> "setupdate=run setsdupdate || run setusbupdate || run setethupdate\0" \
> "setusbupdate=usb start && setenv interface usb && " \
> "fatload ${interface} 0:1 ${loadaddr} " \
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] colibri_imx7: boot kernel in secure mode
On 2019-07-23 15:29, Tobias Junghans wrote: > Hi Igor, > > thanks for your comments! Is there any solution, patch or workaround I can > try > to power on the 2nd CPU core in secure mode with mainline kernel? I am afraid that is not possible since without PSCI mainline simply lacks the code how to enable the secondary CPU. You cannot use PSCI and stay in secure mode. Anyway, why would you want to boot in secure mode anyway? With non-secure mode your CPU has more features, e.g. you can actually use virtualization feature (HYP). You do not have that in secure mode. Booting in non-secure mode is the proper way(tm) to boot on this CPU. That CAAM issue is unfortunate. But I think it is possible to enable CAAM access in non-secure mode by making sure to write the proper registers while being still in secure mode. -- Stefan > > Thanks and best regards > > Tobias > >> I'm afraid you're right. >> Just after a bit of time researching and discussing with Stefan, seems >> that we need to introduce two different wrappers for booting the >> mainline kernel and downstream NXP kernel. >> >> * NXP kernel has legacy code to enable all cores, which works only when >> running in secure mode. >> * Mainline kernel, as you said before, does use PSCI for this, which >> is provided by U-boot (which adds proper psci nodes to the linux >> dtb on-fly before transferring control to the linux kernel entry point). >> When we try to load it in secure mode, it continues running on the same >> Secure PL1, and communication using SMC calling convention doesn't make >> sense at this case. > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] colibri_imx7_emmc: enable CONFIG_ARMV7_BOOT_SEC_DEFAULT
On 11.06.2019 14:29, Igor Opaniuk wrote: > From: Igor Opaniuk > > Enable CONFIG_ARMV7_BOOT_SEC_DEFAULT by default to avoid a kernel > crash when booting NXP linux kernels in non-secure world, > when job ring device allocation is done by CAAM hw accelerator driver: I rather prefer if mainline U-Boot prefers what makes sense for mainline kernel (and that is non-secure). Booting in secure mode can be also done using bootm_boot_mode environment variable. -- Stefan > > caam 3090.caam: job rings = 3, qi = 0 > caam_jr 30901000.jr0: failed to flush job ring 0 > caam_jr: probe of 30901000.jr0 failed with error -5 > caam_jr 30902000.jr1: failed to flush job ring 1 > caam_jr: probe of 30902000.jr1 failed with error -5 > caam_jr 30903000.jr2: failed to flush job ring 2 > caam_jr: probe of 30903000.jr2 failed with error -5 > caam algorithms registered in /proc/crypto > Job Ring Device allocation for transform failed > caam 3090.caam: caam pkc algorithms registered in /proc/crypto > Unable to handle kernel NULL pointer dereference at virtual address 0010 > pgd = c0004000 > [0010] *pgd= > Internal error: Oops: 5 [#1] PREEMPT SMP ARM > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Tainted: > Hardware name: Freescale i.MX7 Dual (Device Tree) > task: ec0d8000 task.stack: ec0ce000 > PC is at caam_sm_startup+0x3f8/0x4f4 > > Signed-off-by: Igor Opaniuk > --- > configs/colibri_imx7_emmc_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/colibri_imx7_emmc_defconfig > b/configs/colibri_imx7_emmc_defconfig > index 2fa9f1f532..0ce56a8df9 100644 > --- a/configs/colibri_imx7_emmc_defconfig > +++ b/configs/colibri_imx7_emmc_defconfig > @@ -76,3 +76,4 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y > CONFIG_USB_FUNCTION_FASTBOOT=y > CONFIG_FASTBOOT_BUF_ADDR=0x8200 > CONFIG_FASTBOOT_BUF_SIZE=0x1000 > +CONFIG_ARMV7_BOOT_SEC_DEFAULT=y ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cfb_console.c: DM_VIDEO conversion questions/suggestions
On 27.05.2019 07:21, Igor Opaniuk wrote: > Hi everyone, > > I've finally started looking into the cfb_console.c driver and it's > conversion to DM_VIDEO after our initial discussion [1]. > Unfortunately I've a bit underestimated the amount of effort that > should be done, as mxsfb.c in the Linux mainline obviously pulls the > whole core fb subsystem > (drivers/video/fbdev/core), which can take a while and frankly I doubt > that this is a proper way to do things here. Just wanted to mention that the Linux mxsfb fbdev driver is considered deprecated. See: https://lore.kernel.org/patchwork/patch/950619/#1135990 Also note that the new DRM driver does use OF graph style bindings, see: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mxsfb.txt > > Taking into account that the deadline for DM_VIDEO conversion is > 2019.07, it's unlikely that we will manage to do the full conversions > this cfb_console driver and all dependent hw specific drivers in a > proper way (where we can provide information about videomodes as > properties in a proper nodes in DT). IMHO, if the deadline hinders us to do it properly, we should extend the deadline. > > Currently the init chain for fb stuff in U-boot (on the other hand, in > the Linux, hw specific driver is probed initially, then they trigger > fb common routines that are needed from `video/fbdev/core`): > stdio_add_devices() -> ./common/stdio.c -> drv_video_init () > (drivers/cfb_console.c) - > video_hw_init (particular hw backend, > which was statically linked at compile time with a proper > video_hw_init() implementation, for example look into mxsfb.c) > > 2 ways of conversion that come to my mind: > 1. Start with simple DM wrappers in cfb_console.c, and introduce dumb > DT nodes so the device at least can be probed. All video configuration > will be stored the same way as before in the U-boot env (for example, > "videomode=video=ctfb:x:640,y:480,depth:18,pclk:39722,le:48,ri:16,up:33,lo:10,hs:96,vs:2,sync:0,vmode:0\0"). > Then, step by step, driver by driver, we can move some properties to > DT and try to sync Linux/U-boot video DT nodes (at least avoid > divergence of tree nodes, so Linux/U-boot video-related DT nodes > conform to each other). Yes, this is kind of dirty workaround, but at > least this something we can start with, and with minimal amount of > intrusive changes. > 2. Perform full conversion, where everything works the same way as in > Linux kernel. Initially I thought that it could be the proper way to > go, but taking into account all differences in the implementation of > fb in U-boot/Linux (even the way how the drivers are initialized), I > think we will just end up pulling the whole big piece from the Linux > kernel, that will definitely take a while (especially further support > of this code base, testing/fixing issues etc.). Is there maybe option 3, start a new DM_VIDEO capable driver mxsfb driver without converting the existing stuff. It is probably not much different from 2, but it allows you to start with a minimal feature set, and go from there incrementally. That is what Marek did when he implemented the Linux mxsfb DRM driver.. Haven't looked into the code much, so this might not really make sense... -- Stefan > > Just to be aware about the amount of effort that should be done: > > : u-boot.git$ grep -e CONFIG_CFB_CONSOLE -r ./configs/ > ./configs/T1042RDB_PI_SDCARD_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042D4RDB_SDCARD_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/nokia_rx51_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042D4RDB_NAND_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042RDB_PI_SPIFLASH_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042RDB_PI_NAND_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042D4RDB_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/T1042RDB_PI_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/eb_cpu5282_internal_defconfig:# CONFIG_CFB_CONSOLE is not set > ./configs/T1042D4RDB_SPIFLASH_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > ./configs/eb_cpu5282_defconfig:# CONFIG_CFB_CONSOLE is not set > ./configs/T1042D4RDB_SECURE_BOOT_defconfig:CONFIG_CFB_CONSOLE_ANSI=y > > Additional Kconfig symbols, that depend on CFB_CONSOLE: > * VGA_AS_SINGLE_DEVICE > * CONSOLE_EXTRA_INFO > * CONSOLE_SCROLL_LINES > * SYS_CONSOLE_BG_COL > * SYS_CONSOLE_FG_COL > > Drivers, that don't imply CFG_CONSOLE, but are used alongside with > cfb_console.c (kind of particular hw backend driver for fb console): > * mxsfb.c > * mb862xx.c > * sunxi_display.c > * ati_radeon_fb.c > * fsl_dcu_fb.c > * omap3_dss.c > * da8xx-fb.c > > Looking forward to your suggestions/recommendations here (and let me > know if I missed something), thanks! > > [1] https://lists.denx.de/pipermail/u-boot/2019-April/365506.html ___ U-Boot mailing list
Re: [U-Boot] [PATCH 1/1] imx8: cpu: fix warning for cpu_imx_get_temp
Hi Igor,
On 13.05.2019 12:46, Igor Opaniuk wrote:
> cpu_imx_get_temp() definition is wrapped with a ifdef macro,
> therefore all function references should be also wrapped the same way
> instead IS_ENABLED() usage.
>
> Fix warning:
> arch/arm/mach-imx/imx8/cpu.c: In function ‘cpu_imx_get_desc’:
> arch/arm/mach-imx/imx8/cpu.c:612:40: warning: implicit declaration of
> function ‘cpu_imx_get_temp’; did you mean ‘cpu_imx_get_desc’?
> [-Wimplicit-function-declaration]
>ret = snprintf(buf, size, " at %dC", cpu_imx_get_temp());
> ^~~~
> cpu_imx_get_desc
> cpu_imx_get_desc
>
Using IS_ENABLED is typically preferred over ifdef since it assures that
the code is compileable even if CONFIG_IMX_SCU_THERMAL is not enabled.
I'd rather prefer we drop the the ifdef around cpu_imx_get_temp(). The
linker will remove the function in case CONFIG_IMX_SCU_THERMAL is not
enabled.
--
Stefan
> Fixes: 82467cb217 ("imx8: cpu: get temperature when print cpu desc")
> Signed-off-by: Igor Opaniuk
> ---
> arch/arm/mach-imx/imx8/cpu.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
> index 12596c6387..616baed7cc 100644
> --- a/arch/arm/mach-imx/imx8/cpu.c
> +++ b/arch/arm/mach-imx/imx8/cpu.c
> @@ -606,11 +606,11 @@ int cpu_imx_get_desc(struct udevice *dev, char
> *buf, int size)
> ret = snprintf(buf, size, "NXP i.MX8%s Rev%s %s at %u MHz",
> plat->type, plat->rev, plat->name, plat->freq_mhz);
>
> - if (IS_ENABLED(CONFIG_IMX_SCU_THERMAL)) {
> - buf = buf + ret;
> - size = size - ret;
> - ret = snprintf(buf, size, " at %dC", cpu_imx_get_temp());
> - }
> +#if defined(CONFIG_IMX_SCU_THERMAL)
> + buf = buf + ret;
> + size = size - ret;
> + ret = snprintf(buf, size, " at %dC", cpu_imx_get_temp());
> +#endif
>
> snprintf(buf + ret, size - ret, "\n");
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH] board: toradex: drop support.arm maintainer email
On 26.04.19 20:53, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > Drop Toradex ARM Support from maintainer email > list as this just clogs our support ticketing system. Acked-by: Stefan Agner -- Stefan > > Signed-off-by: Marcel Ziswiler > > --- > > board/toradex/colibri-imx6ull/MAINTAINERS | 1 - > board/toradex/colibri_imx7/MAINTAINERS| 1 - > 2 files changed, 2 deletions(-) > > diff --git a/board/toradex/colibri-imx6ull/MAINTAINERS > b/board/toradex/colibri-imx6ull/MAINTAINERS > index 7cda555984..626c1f94f9 100644 > --- a/board/toradex/colibri-imx6ull/MAINTAINERS > +++ b/board/toradex/colibri-imx6ull/MAINTAINERS > @@ -1,6 +1,5 @@ > Colibri iMX6ULL > M: Stefan Agner > -M: Toradex ARM Support > W: http://developer.toradex.com/software/linux/linux-software > W: https://www.toradex.com/community > S: Maintained > diff --git a/board/toradex/colibri_imx7/MAINTAINERS > b/board/toradex/colibri_imx7/MAINTAINERS > index f55f8045f4..cd0f9c9b2d 100644 > --- a/board/toradex/colibri_imx7/MAINTAINERS > +++ b/board/toradex/colibri_imx7/MAINTAINERS > @@ -1,6 +1,5 @@ > Colibri iMX7 > M: Stefan Agner > -M: Toradex ARM Support > W: http://developer.toradex.com/software/linux/linux-software > W: https://www.toradex.com/community > S: Maintained > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/22] vybrid: clock: Provide enable_i2c_clk() function for Vybrid
On 03.02.2019 00:02, Lukasz Majewski wrote:
> Provide function to enable I2C clocks for vf610 - in the generic code.
> This function overrides the default weak function implementation (which
> only returns 1).
>
> Signed-off-by: Lukasz Majewski
Reviewed-by: Stefan Agner
--
Stefan
>
> ---
>
> Changes in v3:
> - Add code to enable I2C0 code as suggested by Stefan (so the code can be
> reused by other boards without regressions)
> - Exclude the pcm052.c related code to a separate patch
>
> Changes in v2: None
>
> arch/arm/cpu/armv7/vf610/generic.c | 22 ++
> arch/arm/include/asm/arch-vf610/clock.h | 3 +++
> 2 files changed, 25 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/vf610/generic.c
> b/arch/arm/cpu/armv7/vf610/generic.c
> index cbd3391918..e0c0b1bcb0 100644
> --- a/arch/arm/cpu/armv7/vf610/generic.c
> +++ b/arch/arm/cpu/armv7/vf610/generic.c
> @@ -375,3 +375,25 @@ void enable_caches(void)
> mmu_set_region_dcache_behaviour(IRAM_BASE_ADDR, IRAM_SIZE, option);
> }
> #endif
> +
> +#ifdef CONFIG_SYS_I2C_MXC
> +/* i2c_num can be from 0 - 3 */
> +int enable_i2c_clk(unsigned char enable, unsigned int i2c_num)
> +{
> + struct ccm_reg *ccm = (struct ccm_reg *)CCM_BASE_ADDR;
> +
> + switch (i2c_num) {
> + case 0:
> + clrsetbits_le32(>ccgr4, CCM_CCGR4_I2C0_CTRL_MASK,
> + CCM_CCGR4_I2C0_CTRL_MASK);
> + case 2:
> + clrsetbits_le32(>ccgr10, CCM_CCGR10_I2C2_CTRL_MASK,
> + CCM_CCGR10_I2C2_CTRL_MASK);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +#endif
> diff --git a/arch/arm/include/asm/arch-vf610/clock.h
> b/arch/arm/include/asm/arch-vf610/clock.h
> index 3bd73a01f3..72184fd608 100644
> --- a/arch/arm/include/asm/arch-vf610/clock.h
> +++ b/arch/arm/include/asm/arch-vf610/clock.h
> @@ -22,6 +22,9 @@ enum mxc_clock {
> void enable_ocotp_clk(unsigned char enable);
> unsigned int mxc_get_clock(enum mxc_clock clk);
> u32 get_lpuart_clk(void);
> +#ifdef CONFIG_SYS_I2C_MXC
> +int enable_i2c_clk(unsigned char enable, unsigned int i2c_num);
> +#endif
>
> #define imx_get_fecclk() mxc_get_clock(MXC_FEC_CLK)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] IMX6 NAND boot regression
Hi Tim, On 02.02.19 03:32, Tim Harvey wrote: > Stefan, > > I'm trying to track down an IMX6 SPL NAND boot regression that started > in v2018.07 with your patch series to mxs_nand. I am sorry about that. Unfortunately I did not had a design at hand where I was able to test the NAND driver in SPL... > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd: > nand: mxs_nand: use self init'. With this particular patch nand bbt > scanning would crash the board because of nand_chip.scan_btt not being > assigned. This was later fixed in > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: mxs_nand_spl: Fix > empty function pointer for BBT' but cherry-picking that on top of > 5346c31 fixes the immediate crash while scanning but then I find that > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img from > the NAND. This gets worse 2 patches later where in > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: use > structure for BCH geometry' I find that the first byte of every page > read is wrong because mxs_nand_swap_block_mark() is getting called on > the page which swaps the first bytes with oob. > > There are several IMX6 boards out there using both NAND and SPL I > believe that I would assume were broken by this series. Any ideas on > the proper resolution? Adam Ford sent another patch just recently with the title: "MTD: nand: mxs_nand: Allow driver to auto setup ECC in SPL". Maybe this helps? -- Stefan > > Regards, > > Tim > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/21] vybrid: clock: Provide enable_i2c_clk() function for Vybrid
On 01.02.2019 15:19, Lukasz Majewski wrote:
> Hi Stefan,
>
>> On 20.01.2019 14:34, Lukasz Majewski wrote:
>> > Provide function to enable I2C2 clock for vf610 (BK4) - in the
>> > generic code.
>>
>> Can you split this in two commits, one adding enable_i2c_clk and the
>> second removing board specific clock enable?
>
> This particular commit only adds new clock to generic driver.
No, this commit also touches board/phytec/pcm052/pcm052.c.
>
> There is a commit latter, which is removing the board file:
> [PATCH v2 15/21] pcm052: board: Remove in-board setup code (it is now
> replaced by DM setup)
>
> The approach as is is optimal - I do not see any build errors for
> separate patches.
>
>>
>> Also our module seems to use I2C0, could you add that instance to the
>> supported instances too? It should be rather trivial:
>>
>>
>> switch (i2c_num) {
>> case 0:
>> clrsetbits_le32(>ccgr4, CCM_CCGR4_I2C0_CTRL_MASK,
>> CCM_CCGR4_I2C0_CTRL_MASK);
>
> The problem is that this change is not related to BK4/PCM052 ... or
> "our module" is a PCM052?
>
> If this is some custom board / module (not pcm052) then I would prefer
> to have this change as a separate (not related to this patch set) patch.
You are touching common code. So far enable_i2c_clk was a weak function
which returned 1. If a board calls that function with i2c_num other than
2, the new platform specific enable_i2c_clk will return -EINVAL... Hence
this breaks boards which do not use instance 2...
I am not asking to update other board files. Simply making the common
code to work for all (known) cases.
--
Stefan
>
>> ...
>>
>>
>> --
>> Stefan
>>
>> >
>> > Signed-off-by: Lukasz Majewski
>> > ---
>> >
>> > Changes in v2: None
>> >
>> > arch/arm/cpu/armv7/vf610/generic.c | 19 +++
>> > arch/arm/include/asm/arch-vf610/clock.h | 3 +++
>> > board/phytec/pcm052/pcm052.c| 2 +-
>> > 3 files changed, 23 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/arch/arm/cpu/armv7/vf610/generic.c
>> > b/arch/arm/cpu/armv7/vf610/generic.c
>> > index cbd3391918..f1e6c7816e 100644
>> > --- a/arch/arm/cpu/armv7/vf610/generic.c
>> > +++ b/arch/arm/cpu/armv7/vf610/generic.c
>> > @@ -375,3 +375,22 @@ void enable_caches(void)
>> >mmu_set_region_dcache_behaviour(IRAM_BASE_ADDR, IRAM_SIZE,
>> > option); }
>> > #endif
>> > +
>> > +#ifdef CONFIG_SYS_I2C_MXC
>> > +/* i2c_num can be from 0 - 3 */
>> > +int enable_i2c_clk(unsigned char enable, unsigned int i2c_num)
>> > +{
>> > + struct ccm_reg *ccm = (struct ccm_reg *)CCM_BASE_ADDR;
>> > +
>> > + switch (i2c_num) {
>> > + case 2:
>> > + clrsetbits_le32(>ccgr10,
>> > CCM_CCGR10_I2C2_CTRL_MASK,
>> > + CCM_CCGR10_I2C2_CTRL_MASK);
>> > + break;
>> > + default:
>> > + return -EINVAL;
>> > + }
>> > +
>> > + return 0;
>> > +}
>> > +#endif
>> > diff --git a/arch/arm/include/asm/arch-vf610/clock.h
>> > b/arch/arm/include/asm/arch-vf610/clock.h
>> > index 3bd73a01f3..72184fd608 100644
>> > --- a/arch/arm/include/asm/arch-vf610/clock.h
>> > +++ b/arch/arm/include/asm/arch-vf610/clock.h
>> > @@ -22,6 +22,9 @@ enum mxc_clock {
>> > void enable_ocotp_clk(unsigned char enable);
>> > unsigned int mxc_get_clock(enum mxc_clock clk);
>> > u32 get_lpuart_clk(void);
>> > +#ifdef CONFIG_SYS_I2C_MXC
>> > +int enable_i2c_clk(unsigned char enable, unsigned int i2c_num);
>> > +#endif
>> >
>> > #define imx_get_fecclk() mxc_get_clock(MXC_FEC_CLK)
>> >
>> > diff --git a/board/phytec/pcm052/pcm052.c
>> > b/board/phytec/pcm052/pcm052.c index f988af2abc..cfc8009102 100644
>> > --- a/board/phytec/pcm052/pcm052.c
>> > +++ b/board/phytec/pcm052/pcm052.c
>> > @@ -485,7 +485,7 @@ static void clock_init(void)
>> >clrsetbits_le32(>ccgr9, CCM_REG_CTRL_MASK,
>> >CCM_CCGR9_FEC0_CTRL_MASK |
>> > CCM_CCGR9_FEC1_CTRL_MASK); clrsetbits_le32(>ccgr10,
>> > CCM_REG_CTRL_MASK,
>> > - CCM_CCGR10_NFC_CTRL_MASK |
>> > CCM_CCGR10_I2C2_CTRL_MASK);
>> > + CCM_CCGR10_NFC_CTRL_MASK);
>> >
>> >clrsetbits_le32(>pll2_ctrl,
>> > ANADIG_PLL2_CTRL_POWERDOWN, ANADIG_PLL2_CTRL_ENABLE |
>> > ANADIG_PLL2_CTRL_DIV_SELECT);
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/21] imx: vybrid: Update BK4 and PCM052 boards to only use DM/DTS
On 21.01.2019 15:22, Lukasz Majewski wrote: > On Mon, 21 Jan 2019 09:33:23 +0100 > Lukasz Majewski wrote: > >> Hi Stefan, >> >> > This patch series converts PCM052 and BK4 to use Driver Model and >> > Device Tree. >> > >> > Some notable changes: >> > - The way how MAC address is read from fuses can now be adjusted >> > - DTS improvement/sync with kernel (also extract u-boot specific >> > properties) >> > - Using generic code instead of one from board >> > >> > The output of u-boot boot: >> > U-Boot 2019.01-rc3-00076-gc149229be0 (Jan 14 2019 - 08:38:48 +0100) >> > >> > CPU: Freescale Vybrid VF610 at 396 MHz >> > Reset cause: POWER ON RESET >> > Model: Liebherr (LVF) BK4 Vybrid Board >> > Board: BK4r1 (L333) >> > DRAM: 512 MiB >> > NAND: 1024 MiB >> > MMC: FSL_SDHC: 0 >> > Loading Environment from NAND... OK >> > In:serial@40028000 >> > Out: serial@40028000 >> > Err: serial@40028000 >> > Net: eth0: fec@400d, eth1: fec@400d1000 >> > Enter passphrase to stop autoboot, booting in 3 seconds >> > >> > Buildman CI: >> > ./tools/buildman/buildman.py --branch=HEAD~4 vf610 mx6 vybrid >> > --detail --verbose --show_errors --force-build --count=21 >> > --output-dir=../BUILD/ >> > >> > Travis-CI: >> > https://travis-ci.org/lmajewski/u-boot-dfu/jobs/481963146 >> >> I've bisected this error, and it turned out that the following patch >> is the culprit (on top of which I've rebased my work): >> >> "fs: fat: dynamically allocate memory for temporary buffer" >> >> Without this patch applied: >> https://travis-ci.org/lmajewski/u-boot-dfu/builds/482301236 >> >> With: >> https://travis-ci.org/lmajewski/u-boot-dfu/builds/482297604 >> >> Test: test/py qemu_arm >> >> Error is in: "test_efi_selftest" >> >> Executing 'block device' >> /home/travis/build/lmajewski/u-boot-dfu/lib/efi_selftest/efi_selftest_block_device.c(386): >> TODO: Wrong volume label 'xxa1', expected 'U-BOOT TEST' >> /home/travis/build/lmajewski/u-boot-dfu/lib/efi_selftest/efi_selftest_block_device.c(413): >> ERROR: Unexpected file content >> /home/travis/build/lmajewski/u-boot-dfu/lib/efi_selftest/efi_selftest.c(110): >> ERROR: Executing 'block device' failed >> >> > > And the full travis-ci build without the above patch (all "green"): > > https://travis-ci.org/lmajewski/u-boot-dfu/builds/482308817 > I skimmed through the rest of the patchset but did not do a full review. But I am ok with the rest of the patches. I also tested the patchset on our Colibri VF50, and U-Boot seems to work fine! Thanks for your work! -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/21] vybrid: clock: Provide enable_i2c_clk() function for Vybrid
On 20.01.2019 14:34, Lukasz Majewski wrote:
> Provide function to enable I2C2 clock for vf610 (BK4) - in the
> generic code.
Can you split this in two commits, one adding enable_i2c_clk and the
second removing board specific clock enable?
Also our module seems to use I2C0, could you add that instance to the
supported instances too? It should be rather trivial:
switch (i2c_num) {
case 0:
clrsetbits_le32(>ccgr4, CCM_CCGR4_I2C0_CTRL_MASK,
CCM_CCGR4_I2C0_CTRL_MASK);
...
--
Stefan
>
> Signed-off-by: Lukasz Majewski
> ---
>
> Changes in v2: None
>
> arch/arm/cpu/armv7/vf610/generic.c | 19 +++
> arch/arm/include/asm/arch-vf610/clock.h | 3 +++
> board/phytec/pcm052/pcm052.c| 2 +-
> 3 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv7/vf610/generic.c
> b/arch/arm/cpu/armv7/vf610/generic.c
> index cbd3391918..f1e6c7816e 100644
> --- a/arch/arm/cpu/armv7/vf610/generic.c
> +++ b/arch/arm/cpu/armv7/vf610/generic.c
> @@ -375,3 +375,22 @@ void enable_caches(void)
> mmu_set_region_dcache_behaviour(IRAM_BASE_ADDR, IRAM_SIZE, option);
> }
> #endif
> +
> +#ifdef CONFIG_SYS_I2C_MXC
> +/* i2c_num can be from 0 - 3 */
> +int enable_i2c_clk(unsigned char enable, unsigned int i2c_num)
> +{
> + struct ccm_reg *ccm = (struct ccm_reg *)CCM_BASE_ADDR;
> +
> + switch (i2c_num) {
> + case 2:
> + clrsetbits_le32(>ccgr10, CCM_CCGR10_I2C2_CTRL_MASK,
> + CCM_CCGR10_I2C2_CTRL_MASK);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +#endif
> diff --git a/arch/arm/include/asm/arch-vf610/clock.h
> b/arch/arm/include/asm/arch-vf610/clock.h
> index 3bd73a01f3..72184fd608 100644
> --- a/arch/arm/include/asm/arch-vf610/clock.h
> +++ b/arch/arm/include/asm/arch-vf610/clock.h
> @@ -22,6 +22,9 @@ enum mxc_clock {
> void enable_ocotp_clk(unsigned char enable);
> unsigned int mxc_get_clock(enum mxc_clock clk);
> u32 get_lpuart_clk(void);
> +#ifdef CONFIG_SYS_I2C_MXC
> +int enable_i2c_clk(unsigned char enable, unsigned int i2c_num);
> +#endif
>
> #define imx_get_fecclk() mxc_get_clock(MXC_FEC_CLK)
>
> diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c
> index f988af2abc..cfc8009102 100644
> --- a/board/phytec/pcm052/pcm052.c
> +++ b/board/phytec/pcm052/pcm052.c
> @@ -485,7 +485,7 @@ static void clock_init(void)
> clrsetbits_le32(>ccgr9, CCM_REG_CTRL_MASK,
> CCM_CCGR9_FEC0_CTRL_MASK | CCM_CCGR9_FEC1_CTRL_MASK);
> clrsetbits_le32(>ccgr10, CCM_REG_CTRL_MASK,
> - CCM_CCGR10_NFC_CTRL_MASK | CCM_CCGR10_I2C2_CTRL_MASK);
> + CCM_CCGR10_NFC_CTRL_MASK);
>
> clrsetbits_le32(>pll2_ctrl, ANADIG_PLL2_CTRL_POWERDOWN,
> ANADIG_PLL2_CTRL_ENABLE | ANADIG_PLL2_CTRL_DIV_SELECT);
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/21] ARM: DTS: vybrid: Update vf.dtsi file to descibe more vf610 hardware
On 20.01.2019 14:34, Lukasz Majewski wrote:
> This patch allows moving vf610 based boards to a device tree and model.
> Ported from Linux kernel - v4.20 (tag)
>
> Signed-off-by: Lukasz Majewski
Reviewed-by: Stefan Agner
--
Stefan
> ---
>
> Changes in v2: None
>
> arch/arm/dts/vf.dtsi | 62
>
> 1 file changed, 62 insertions(+)
>
> diff --git a/arch/arm/dts/vf.dtsi b/arch/arm/dts/vf.dtsi
> index ad30059b9a..5e3b2c5b9d 100644
> --- a/arch/arm/dts/vf.dtsi
> +++ b/arch/arm/dts/vf.dtsi
> @@ -22,6 +22,10 @@
> spi1 =
> ehci0 =
> ehci1 =
> + i2c0 =
> + i2c1 =
> + i2c2 =
> + i2c3 =
> };
>
> soc {
> @@ -89,6 +93,22 @@
> status = "disabled";
> };
>
> + i2c0: i2c@40066000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-i2c";
> + reg = <0x40066000 0x1000>;
> + status = "disabled";
> + };
> +
> + i2c1: i2c@40067000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-i2c";
> + reg = <0x40067000 0x1000>;
> + status = "disabled";
> + };
> +
> iomuxc: iomuxc@40048000 {
> compatible = "fsl,vf610-iomuxc";
> reg = <0x40048000 0x1000>;
> @@ -156,6 +176,48 @@
> reg = <0x400b4000 0x800>;
> status = "disabled";
> };
> +
> + esdhc1: esdhc@400b2000 {
> + compatible = "fsl,esdhc";
> + reg = <0x400b2000 0x1000>;
> + status = "disabled";
> + };
> +
> + fec0: fec@400d {
> + compatible = "fsl,mvf600-fec";
> + reg = <0x400d 0x1000>;
> + status = "disabled";
> + };
> +
> + fec1: fec@400d1000 {
> + compatible = "fsl,mvf600-fec";
> + reg = <0x400d1000 0x1000>;
> + status = "disabled";
> + };
> +
> + nfc: nand@400e {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-nfc";
> + reg = <0x400e 0x4000>;
> + status = "disabled";
> + };
> +
> + i2c2: i2c@400e6000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-i2c";
> + reg = <0x400e6000 0x1000>;
> + status = "disabled";
> + };
> +
> + i2c3: i2c@400e7000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-i2c";
> + reg = <0x400e7000 0x1000>;
> + status = "disabled";
> + };
> };
> };
> };
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/21] vybrid: ddr: Extend vf610-pinfunc.h with DDR pads definitions
On 20.01.2019 14:34, Lukasz Majewski wrote: > This patch provides definitions necessary for VF610 DDR pad configurations. > > Signed-off-by: Lukasz Majewski Reviewed-by: Stefan Agner -- Stefan > --- > > Changes in v2: None > > arch/arm/dts/vf610-pinfunc.h | 50 > > 1 file changed, 50 insertions(+) > > diff --git a/arch/arm/dts/vf610-pinfunc.h b/arch/arm/dts/vf610-pinfunc.h > index fcad7132c8..24d7126756 100644 > --- a/arch/arm/dts/vf610-pinfunc.h > +++ b/arch/arm/dts/vf610-pinfunc.h > @@ -807,4 +807,54 @@ > #define VF610_PAD_PTA7__GPIO_134 0x218 0x000 ALT0 0x0 > #define VF610_PAD_PTA7__VIU_PIX_CLK 0x218 0x3AC ALT1 0x1 > > +#define VF610_PAD_DDR_RESETB 0x21c 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A15__DDR_A_15 0x220 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A14__DDR_A_14 0x224 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A13__DDR_A_13 0x228 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A12__DDR_A_12 0x22c 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A11__DDR_A_11 0x230 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A10__DDR_A_10 0x234 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A9__DDR_A_90x238 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A8__DDR_A_80x23c 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A7__DDR_A_70x240 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A6__DDR_A_60x244 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A5__DDR_A_50x248 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A4__DDR_A_40x24c 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A3__DDR_A_30x250 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A2__DDR_A_20x254 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A1__DDR_A_10x258 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_A0__DDR_A_00x25c 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_BA2__DDR_BA_2 0x260 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_BA1__DDR_BA_1 0x264 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_BA0__DDR_BA_0 0x268 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_CAS__DDR_CAS_B 0x26c 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_CKE__DDR_CKE_0 0x270 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_CLK__DDR_CLK_0 0x274 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_CS__DDR_CS_B_0 0x278 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D15__DDR_D_15 0x27c 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D14__DDR_D_14 0x280 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D13__DDR_D_13 0x284 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D12__DDR_D_12 0x288 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D11__DDR_D_11 0x28c 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D10__DDR_D_10 0x290 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D9__DDR_D_90x294 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D8__DDR_D_80x298 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D7__DDR_D_70x29c 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D6__DDR_D_60x2a0 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D5__DDR_D_50x2a4 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D4__DDR_D_40x2a8 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D3__DDR_D_30x2ac 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D2__DDR_D_20x2b0 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D1__DDR_D_10x2b4 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_D0__DDR_D_00x2b8 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_DQM1__DDR_DQM_10x2bc 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_DQM0__DDR_DQM_00x2c0 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_DQS1__DDR_DQS_10x2c4 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_DQS0__DDR_DQS_00x2c8 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_RAS__DDR_RAS_B 0x2cc 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_WE__DDR_WE_B 0x2d0 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_ODT1__DDR_ODT_00x2d4 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_ODT0__DDR_ODT_10x2d8 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_DDRBYTE1__DDR_DDRBYTE1 0x2dc 0x000 ALT0 0x0 > +#define VF610_PAD_DDR_DDRBYTE0__DDR_DDRBYTE0 0x2e0 0x000 ALT0 0x0 > #endif ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/21] net: Kconfig: FEC: Add dependency on VF610
On 20.01.2019 14:34, Lukasz Majewski wrote: > Signed-off-by: Lukasz Majewski Reviewed-by: Stefan Agner -- Stefan > --- > > Changes in v2: None > > drivers/net/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > index ff55e03d3f..f5e0fb8611 100644 > --- a/drivers/net/Kconfig > +++ b/drivers/net/Kconfig > @@ -187,7 +187,7 @@ config FEC_MXC_MDIO_BASE > > config FEC_MXC > bool "FEC Ethernet controller" > - depends on MX5 || MX6 || MX7 || IMX8 > + depends on MX5 || MX6 || MX7 || IMX8 || VF610 > help > This driver supports the 10/100 Fast Ethernet controller for > NXP i.MX processors. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/21] net: FEC: Add compatible for vybrid (vf610) to reuse fec_mxc.c driver
On 20.01.2019 14:34, Lukasz Majewski wrote:
> The NXP's FEC driver can be reused on vf610 device (with DM).
>
> Signed-off-by: Lukasz Majewski
Reviewed-by: Stefan Agner
--
Stefan
> ---
>
> Changes in v2: None
>
> drivers/net/fec_mxc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
> index 32fb34b793..be388ead30 100644
> --- a/drivers/net/fec_mxc.c
> +++ b/drivers/net/fec_mxc.c
> @@ -1465,6 +1465,7 @@ static const struct udevice_id fecmxc_ids[] = {
> { .compatible = "fsl,imx6ul-fec" },
> { .compatible = "fsl,imx53-fec" },
> { .compatible = "fsl,imx7d-fec" },
> + { .compatible = "fsl,mvf600-fec" },
> { }
> };
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 08/11] configs: colibri_imx7: enable CAAM driver
From: Stefan Agner Access to CAAM in non-secure mode must be enabled by the boot loader first. The U-Boot CAAM driver enables access to CAAM in non-secure mode by default. Hence enable the CAAM driver to allow Linux accessing CAAM directly. This prevents error messages like the following on Linux boot: caam 3090.caam: Entropy delay = 3200 caam 3090.caam: failed to acquire DECO 0 caam 3090.caam: failed to instantiate RNG Signed-off-by: Stefan Agner Acked-by: Marcel Ziswiler --- Changes in v2: None configs/colibri_imx7_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig index af976bab12..c6fd7f3f4e 100644 --- a/configs/colibri_imx7_defconfig +++ b/configs/colibri_imx7_defconfig @@ -2,9 +2,11 @@ CONFIG_ARM=y CONFIG_SYS_THUMB_BUILD=y CONFIG_ARCH_MX7=y CONFIG_SYS_TEXT_BASE=0x8780 +CONFIG_SECURE_BOOT=y CONFIG_TARGET_COLIBRI_IMX7=y CONFIG_IMX_RDC=y CONFIG_IMX_BOOTAUX=y +# CONFIG_CMD_DEKBLOB is not set CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_NR_DRAM_BANKS=1 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D" @@ -35,6 +37,7 @@ CONFIG_CMD_MII=y CONFIG_CMD_PING=y CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y +# CONFIG_CMD_HASH is not set CONFIG_CMD_EXT4=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y @@ -46,6 +49,7 @@ CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-rawnand" CONFIG_ENV_IS_IN_NAND=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y +CONFIG_FSL_CAAM=y CONFIG_DFU_MMC=y CONFIG_DM_GPIO=y CONFIG_DM_I2C=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 07/11] colibri_imx7: drop legacy usdhc support
From: Stefan Agner
Drop legacy pinmux/usdhc board configuration.
Signed-off-by: Stefan Agner
Acked-by: Marcel Ziswiler
---
Changes in v2: None
board/toradex/colibri_imx7/colibri_imx7.c | 97 ---
1 file changed, 97 deletions(-)
diff --git a/board/toradex/colibri_imx7/colibri_imx7.c
b/board/toradex/colibri_imx7/colibri_imx7.c
index a4c99626b4..392fda92da 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -33,9 +33,6 @@ DECLARE_GLOBAL_DATA_PTR;
#define UART_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | \
PAD_CTL_PUS_PU100KOHM | PAD_CTL_HYS)
-#define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
- PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
-
#define ENET_PAD_CTRL (PAD_CTL_PUS_PU100KOHM | PAD_CTL_DSE_3P3V_49OHM)
#define ENET_PAD_CTRL_MII (PAD_CTL_DSE_3P3V_32OHM)
@@ -64,17 +61,6 @@ static iomux_v3_cfg_t const uart1_pads[] = {
MX7D_PAD_SAI2_TX_SYNC__UART1_DTE_RTS | MUX_PAD_CTRL(UART_PAD_CTRL),
};
-static iomux_v3_cfg_t const usdhc1_pads[] = {
- MX7D_PAD_SD1_CLK__SD1_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD1_CMD__SD1_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD1_DATA0__SD1_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD1_DATA1__SD1_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD1_DATA2__SD1_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD1_DATA3__SD1_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-
- MX7D_PAD_GPIO1_IO00__GPIO1_IO0 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
#ifdef CONFIG_USB_EHCI_MX7
static iomux_v3_cfg_t const usb_cdet_pads[] = {
MX7D_PAD_ENET1_CRS__GPIO7_IO14 | MUX_PAD_CTRL(NO_PAD_CTRL),
@@ -109,24 +95,6 @@ static void setup_gpmi_nand(void)
}
#endif
-#ifdef CONFIG_TARGET_COLIBRI_IMX7_EMMC
-static iomux_v3_cfg_t const usdhc3_emmc_pads[] = {
- MX7D_PAD_SD3_CLK__SD3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_CMD__SD3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA4__SD3_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA5__SD3_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA6__SD3_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA7__SD3_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_STROBE__SD3_STROBE | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-
- MX7D_PAD_SD3_RESET_B__GPIO6_IO11 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-};
-#endif
-
#ifdef CONFIG_VIDEO_MXS
static iomux_v3_cfg_t const lcd_pads[] = {
MX7D_PAD_LCD_CLK__LCD_CLK | MUX_PAD_CTRL(LCD_PAD_CTRL),
@@ -211,71 +179,6 @@ static void setup_iomux_uart(void)
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
}
-#ifdef CONFIG_FSL_ESDHC
-
-#define USDHC1_CD_GPIO IMX_GPIO_NR(1, 0)
-
-static struct fsl_esdhc_cfg usdhc_cfg[] = {
-#ifdef CONFIG_TARGET_COLIBRI_IMX7_EMMC
- {USDHC3_BASE_ADDR},
-#endif
- {USDHC1_BASE_ADDR, 0, 4},
-};
-
-int board_mmc_getcd(struct mmc *mmc)
-{
- struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
- int ret = 0;
-
- switch (cfg->esdhc_base) {
- case USDHC1_BASE_ADDR:
- ret = !gpio_get_value(USDHC1_CD_GPIO);
- break;
-#ifdef CONFIG_TARGET_COLIBRI_IMX7_EMMC
- case USDHC3_BASE_ADDR:
- ret = 1;
- break;
-#endif
- }
-
- return ret;
-}
-
-int board_mmc_init(bd_t *bis)
-{
- int i, ret;
- /* USDHC1 is mmc0, USDHC3 is mmc1 */
- for (i = 0; i < CONFIG_SYS_FSL_USDHC_NUM; i++) {
- switch (i) {
- case 0:
- imx_iomux_v3_setup_multiple_pads(
- usdhc1_pads, ARRAY_SIZE(usdhc1_pads));
- gpio_request(USDHC1_CD_GPIO, "usdhc1_cd");
- gpio_direction_input(USDHC1_CD_GPIO);
- usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
- break;
-#ifdef CONFIG_TARGET_COLIBRI_IMX7_EMMC
- case 1:
- imx_iomux_v3_setup_multiple_pads(usdhc3_emmc_pads,
- ARRAY_SIZE(usdhc3_emmc_pads));
- usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
- break;
-#endif
- default:
- printf("Warning: you configured more USDHC controllers"
- "(%d) than supported by the board\n", i + 1);
- return -EINVAL;
- }
-
- ret = fsl_esdhc_initialize(bis, _cfg[i]);
- if (ret)
- return ret;
- }
-
- return
[U-Boot] [PATCH v2 06/11] configs: colibri_imx7: use DM_MMC
From: Stefan Agner Now that device tree is in place use DM_MMC for Colibri iMX7 devices. Signed-off-by: Stefan Agner Acked-by: Marcel Ziswiler --- Changes in v2: None configs/colibri_imx7_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig index 0c9467e136..af976bab12 100644 --- a/configs/colibri_imx7_defconfig +++ b/configs/colibri_imx7_defconfig @@ -49,6 +49,7 @@ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_DFU_MMC=y CONFIG_DM_GPIO=y CONFIG_DM_I2C=y +CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_NAND=y @@ -63,7 +64,6 @@ CONFIG_DM_PMIC=y CONFIG_PMIC_RN5T567=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y -CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Toradex" CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 11/11] configs: add default configuraiton for Colibri iMX7 with eMMC
From: Stefan Agner Add a default configuration for Colibri iMX7D 1GB (with eMMC NAND flash). Signed-off-by: Stefan Agner --- Changes in v2: - Add CONFIG_FIT/DFU/CRC32_VERIFY/CMD_GPT/DFU_MMC and FAT_WRITE configs/colibri_imx7_emmc_defconfig | 66 + 1 file changed, 66 insertions(+) create mode 100644 configs/colibri_imx7_emmc_defconfig diff --git a/configs/colibri_imx7_emmc_defconfig b/configs/colibri_imx7_emmc_defconfig new file mode 100644 index 00..5e2a204a88 --- /dev/null +++ b/configs/colibri_imx7_emmc_defconfig @@ -0,0 +1,66 @@ +CONFIG_ARM=y +CONFIG_SYS_THUMB_BUILD=y +CONFIG_ARCH_MX7=y +CONFIG_SYS_TEXT_BASE=0x8780 +CONFIG_SECURE_BOOT=y +CONFIG_TARGET_COLIBRI_IMX7=y +CONFIG_TARGET_COLIBRI_IMX7_EMMC=y +CONFIG_IMX_RDC=y +CONFIG_IMX_BOOTAUX=y +# CONFIG_CMD_DEKBLOB is not set +CONFIG_DISTRO_DEFAULTS=y +CONFIG_FIT=y +CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D" +CONFIG_BOOTDELAY=1 +# CONFIG_USE_BOOTCOMMAND is not set +# CONFIG_CONSOLE_MUX is not set +CONFIG_SYS_CONSOLE_IS_IN_ENV=y +# CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_SYS_PROMPT="Colibri iMX7 # " +# CONFIG_CMD_BOOTD is not set +# CONFIG_CMD_IMI is not set +# CONFIG_CMD_XIMG is not set +CONFIG_CMD_ASKENV=y +CONFIG_CRC32_VERIFY=y +CONFIG_CMD_MEMTEST=y +CONFIG_CMD_DFU=y +CONFIG_CMD_GPIO=y +CONFIG_CMD_GPT=y +# CONFIG_RANDOM_UUID is not set +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +CONFIG_CMD_USB_MASS_STORAGE=y +CONFIG_CMD_BMP=y +CONFIG_CMD_CACHE=y +# CONFIG_CMD_HASH is not set +# CONFIG_ISO_PARTITION is not set +CONFIG_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-emmc" +CONFIG_ENV_IS_IN_MMC=y +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y +CONFIG_FSL_CAAM=y +CONFIG_DFU_MMC=y +CONFIG_DM_GPIO=y +CONFIG_DM_I2C=y +CONFIG_DM_MMC=y +CONFIG_FSL_ESDHC=y +CONFIG_PHYLIB=y +CONFIG_PHY_MICREL=y +CONFIG_MII=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX7=y +CONFIG_DM_PMIC=y +CONFIG_PMIC_RN5T567=y +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="Toradex" +CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 +CONFIG_USB_GADGET_PRODUCT_NUM=0x4000 +CONFIG_CI_UDC=y +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_VIDEO=y +CONFIG_FAT_WRITE=y +CONFIG_OF_LIBFDT_OVERLAY=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 10/11] configs: colibri_imx7: use distro defaults
From: Stefan Agner The defconfig already use most features implied by distro defaults. Make sure we enable all features required by distro boot by making use of CONFIG_DISTRO_DEFAULTS. Signed-off-by: Stefan Agner --- Changes in v2: - New patch configs/colibri_imx7_defconfig | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig index 2e675a0c1d..91577ed36b 100644 --- a/configs/colibri_imx7_defconfig +++ b/configs/colibri_imx7_defconfig @@ -7,18 +7,17 @@ CONFIG_TARGET_COLIBRI_IMX7=y CONFIG_IMX_RDC=y CONFIG_IMX_BOOTAUX=y # CONFIG_CMD_DEKBLOB is not set -CONFIG_ENV_VARS_UBOOT_CONFIG=y +CONFIG_DISTRO_DEFAULTS=y CONFIG_NR_DRAM_BANKS=1 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D" CONFIG_BOOTDELAY=1 +# CONFIG_USE_BOOTCOMMAND is not set # CONFIG_CONSOLE_MUX is not set CONFIG_SYS_CONSOLE_IS_IN_ENV=y # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y -CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="Colibri iMX7 # " # CONFIG_CMD_BOOTD is not set -CONFIG_CMD_BOOTZ=y # CONFIG_CMD_IMI is not set # CONFIG_CMD_XIMG is not set CONFIG_CMD_ASKENV=y @@ -32,19 +31,15 @@ CONFIG_CMD_NAND_TRIMFFS=y CONFIG_CMD_NAND_TORTURE=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y -CONFIG_CMD_DHCP=y -CONFIG_CMD_MII=y -CONFIG_CMD_PING=y +# CONFIG_BOOTP_PXE is not set CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y # CONFIG_CMD_HASH is not set -CONFIG_CMD_EXT4=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand" CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:512k(mx7-bcb),1536k(u-boot1)ro,1536k(u-boot2)ro,512k(u-boot-env),-(ubi)" CONFIG_CMD_UBI=y +# CONFIG_ISO_PARTITION is not set CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-rawnand" CONFIG_ENV_IS_IN_NAND=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 09/11] configs: colibri_imx7: use DFU for NAND instead of MMC
From: Stefan Agner The colibri_imx7_defconfig is for Colibri iMX7 raw NAND devices. Hence DFU for NAND is more useful then for MMC devices. Signed-off-by: Stefan Agner --- Changes in v2: - New patch configs/colibri_imx7_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig index c6fd7f3f4e..2e675a0c1d 100644 --- a/configs/colibri_imx7_defconfig +++ b/configs/colibri_imx7_defconfig @@ -50,7 +50,7 @@ CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-rawnand" CONFIG_ENV_IS_IN_NAND=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_FSL_CAAM=y -CONFIG_DFU_MMC=y +CONFIG_DFU_NAND=y CONFIG_DM_GPIO=y CONFIG_DM_I2C=y CONFIG_DM_MMC=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 02/11] arm: dts: imx7: colibri: split dt for raw NAND and eMMC devices
From: Stefan Agner
In preparation of adding CONFIG_DM_MMC support use separate device
trees for raw NAND and eMMC devices.
Signed-off-by: Stefan Agner
Acked-by: Marcel Ziswiler
---
Changes in v2:
- Remove imx7-colibri.dtb from Makefile
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/imx7-colibri-emmc.dts| 16 +++
arch/arm/dts/imx7-colibri-rawnand.dts | 46 +++
.../{imx7-colibri.dts => imx7-colibri.dtsi} | 39 +---
board/toradex/colibri_imx7/MAINTAINERS| 3 ++
configs/colibri_imx7_defconfig| 2 +-
6 files changed, 68 insertions(+), 41 deletions(-)
create mode 100644 arch/arm/dts/imx7-colibri-emmc.dts
create mode 100644 arch/arm/dts/imx7-colibri-rawnand.dts
rename arch/arm/dts/{imx7-colibri.dts => imx7-colibri.dtsi} (65%)
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dda4e59491..768965a9fe 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -458,8 +458,7 @@ dtb-$(CONFIG_MX6UL) += \
dtb-$(CONFIG_MX6ULL) += imx6ull-14x14-evk.dtb
-dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
- imx7d-sdb.dtb \
+dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
imx7d-sdb-qspi.dtb
dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
diff --git a/arch/arm/dts/imx7-colibri-emmc.dts
b/arch/arm/dts/imx7-colibri-emmc.dts
new file mode 100644
index 00..295ca05916
--- /dev/null
+++ b/arch/arm/dts/imx7-colibri-emmc.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 Toradex AG
+ */
+
+/dts-v1/;
+#include "imx7-colibri.dtsi"
+
+/ {
+ model = "Toradex Colibri iMX7D 1GB (eMMC)";
+ compatible = "toradex,imx7d-colibri-emmc", "fsl,imx7d";
+
+ chosen {
+ stdout-path =
+ };
+};
diff --git a/arch/arm/dts/imx7-colibri-rawnand.dts
b/arch/arm/dts/imx7-colibri-rawnand.dts
new file mode 100644
index 00..4eb86fb011
--- /dev/null
+++ b/arch/arm/dts/imx7-colibri-rawnand.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 Toradex AG
+ */
+
+/dts-v1/;
+#include "imx7-colibri.dtsi"
+
+/ {
+ model = "Toradex Colibri iMX7S/D";
+ compatible = "toradex,imx7-colibri", "fsl,imx7";
+
+ chosen {
+ stdout-path =
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpmi_nand>;
+ fsl,use-minimum-ecc;
+ nand-on-flash-bbt;
+ nand-ecc-mode = "hw";
+ status = "okay";
+};
+
+ {
+ pinctrl_gpmi_nand: gpmi-nand-grp {
+ fsl,pins = <
+ MX7D_PAD_SD3_CLK__NAND_CLE 0x71
+ MX7D_PAD_SD3_CMD__NAND_ALE 0x71
+ MX7D_PAD_SAI1_TX_BCLK__NAND_CE0_B 0x71
+ MX7D_PAD_SAI1_TX_DATA__NAND_READY_B 0x74
+ MX7D_PAD_SD3_STROBE__NAND_RE_B 0x71
+ MX7D_PAD_SD3_RESET_B__NAND_WE_B 0x71
+ MX7D_PAD_SD3_DATA0__NAND_DATA00 0x71
+ MX7D_PAD_SD3_DATA1__NAND_DATA01 0x71
+ MX7D_PAD_SD3_DATA2__NAND_DATA02 0x71
+ MX7D_PAD_SD3_DATA3__NAND_DATA03 0x71
+ MX7D_PAD_SD3_DATA4__NAND_DATA04 0x71
+ MX7D_PAD_SD3_DATA5__NAND_DATA05 0x71
+ MX7D_PAD_SD3_DATA6__NAND_DATA06 0x71
+ MX7D_PAD_SD3_DATA7__NAND_DATA07 0x71
+ >;
+ };
+};
diff --git a/arch/arm/dts/imx7-colibri.dts b/arch/arm/dts/imx7-colibri.dtsi
similarity index 65%
rename from arch/arm/dts/imx7-colibri.dts
rename to arch/arm/dts/imx7-colibri.dtsi
index dca501be25..47295117aa 100644
--- a/arch/arm/dts/imx7-colibri.dts
+++ b/arch/arm/dts/imx7-colibri.dtsi
@@ -1,30 +1,12 @@
// SPDX-License-Identifier: GPL-2.0+ OR X11
/*
- * Copyright 2016 Toradex AG
+ * Copyright 2016-2019 Toradex AG
*/
/dts-v1/;
#include
#include "imx7d.dtsi"
-/ {
- model = "Toradex Colibri iMX7S/D";
- compatible = "toradex,imx7-colibri", "fsl,imx7";
-
- chosen {
- stdout-path =
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_gpmi_nand>;
- fsl,use-minimum-ecc;
- nand-on-flash-bbt;
- nand-ecc-mode = "hw";
- status = "okay";
-};
-
{
pinctrl-names = "default", "gpio";
pinctrl-0 = <_i2c1>;
@@ -57,25 +39,6 @@
};
{
- pinctrl_gpmi_nand: gpmi-nand-grp {
- fsl,pins = <
- MX7D_PAD_SD3_CLK__NAND_CLE 0x71
- MX7D_PAD_SD3_CMD__NAND_ALE 0x71
- MX7D_
[U-Boot] [PATCH v2 04/11] configs: colibri_imx7: use separate device tree
From: Stefan Agner Use OF_SEPARATE as suggested by the build system. Signed-off-by: Stefan Agner Acked-by: Marcel Ziswiler --- Changes in v2: None configs/colibri_imx7_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig index 3aaf1a417d..0c9467e136 100644 --- a/configs/colibri_imx7_defconfig +++ b/configs/colibri_imx7_defconfig @@ -43,7 +43,6 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand" CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:512k(mx7-bcb),1536k(u-boot1)ro,1536k(u-boot2)ro,512k(u-boot-env),-(ubi)" CONFIG_CMD_UBI=y CONFIG_OF_CONTROL=y -CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-rawnand" CONFIG_ENV_IS_IN_NAND=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 05/11] arm: dts: imx7: colibri: add usdhci peripherals to device tree
From: Stefan Agner
Add usdhci peripherals to device tree. This allows to use DM_MMC
for Colibri iMX7 devices.
Signed-off-by: Stefan Agner
---
Changes in v2:
- Remove unnecessary properties
arch/arm/dts/imx7-colibri-emmc.dts | 31 ++
arch/arm/dts/imx7-colibri.dtsi | 26 +
2 files changed, 57 insertions(+)
diff --git a/arch/arm/dts/imx7-colibri-emmc.dts
b/arch/arm/dts/imx7-colibri-emmc.dts
index 295ca05916..efd600091d 100644
--- a/arch/arm/dts/imx7-colibri-emmc.dts
+++ b/arch/arm/dts/imx7-colibri-emmc.dts
@@ -10,7 +10,38 @@
model = "Toradex Colibri iMX7D 1GB (eMMC)";
compatible = "toradex,imx7d-colibri-emmc", "fsl,imx7d";
+ aliases {
+ mmc0 =
+ mmc1 =
+ };
+
chosen {
stdout-path =
};
};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_usdhc3>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+ {
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX7D_PAD_SD3_CMD__SD3_CMD 0x59
+ MX7D_PAD_SD3_CLK__SD3_CLK 0x19
+ MX7D_PAD_SD3_DATA0__SD3_DATA0 0x59
+ MX7D_PAD_SD3_DATA1__SD3_DATA1 0x59
+ MX7D_PAD_SD3_DATA2__SD3_DATA2 0x59
+ MX7D_PAD_SD3_DATA3__SD3_DATA3 0x59
+ MX7D_PAD_SD3_DATA4__SD3_DATA4 0x59
+ MX7D_PAD_SD3_DATA5__SD3_DATA5 0x59
+ MX7D_PAD_SD3_DATA6__SD3_DATA6 0x59
+ MX7D_PAD_SD3_DATA7__SD3_DATA7 0x59
+ MX7D_PAD_SD3_STROBE__SD3_STROBE 0x19
+ >;
+ };
+};
diff --git a/arch/arm/dts/imx7-colibri.dtsi b/arch/arm/dts/imx7-colibri.dtsi
index 47295117aa..a85702f519 100644
--- a/arch/arm/dts/imx7-colibri.dtsi
+++ b/arch/arm/dts/imx7-colibri.dtsi
@@ -38,6 +38,15 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_usdhc1 _cd_usdhc1>;
+ no-1-8-v;
+ cd-gpios = < 0 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ status = "okay";
+};
+
{
pinctrl_i2c4: i2c4-grp {
fsl,pins = <
@@ -68,6 +77,17 @@
MX7D_PAD_SD2_DATA0__GPIO5_IO14 0x14 /* DTR */
>;
};
+
+ pinctrl_usdhc1: usdhc1-grp {
+ fsl,pins = <
+ MX7D_PAD_SD1_CMD__SD1_CMD 0x59
+ MX7D_PAD_SD1_CLK__SD1_CLK 0x19
+ MX7D_PAD_SD1_DATA0__SD1_DATA0 0x59
+ MX7D_PAD_SD1_DATA1__SD1_DATA1 0x59
+ MX7D_PAD_SD1_DATA2__SD1_DATA2 0x59
+ MX7D_PAD_SD1_DATA3__SD1_DATA3 0x59
+ >;
+ };
};
_lpsr {
@@ -84,4 +104,10 @@
MX7D_PAD_LPSR_GPIO1_IO04__GPIO1_IO4 0x407f
>;
};
+
+ pinctrl_cd_usdhc1: usdhc1-cd-grp {
+ fsl,pins = <
+ MX7D_PAD_LPSR_GPIO1_IO00__GPIO1_IO0 0x59 /* CD */
+ >;
+ };
};
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 03/11] configs: colibri_imx7: enable DM for raw NAND devices
From: Stefan Agner Use DM and device trees for raw NAND devices by default. This fixes -74 NAND read errors since it makes sure the ECC settings are the same as used in Linux and our downstream U-Boot. Signed-off-by: Stefan Agner --- Changes in v2: None configs/colibri_imx7_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig index 7441102ed4..3aaf1a417d 100644 --- a/configs/colibri_imx7_defconfig +++ b/configs/colibri_imx7_defconfig @@ -25,6 +25,7 @@ CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_MTD=y CONFIG_CMD_NAND_TRIMFFS=y CONFIG_CMD_NAND_TORTURE=y CONFIG_CMD_USB=y @@ -50,7 +51,9 @@ CONFIG_DFU_MMC=y CONFIG_DM_GPIO=y CONFIG_DM_I2C=y CONFIG_FSL_ESDHC=y +CONFIG_MTD=y CONFIG_NAND=y +CONFIG_NAND_MXS_DT=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_PHYLIB=y CONFIG_PHY_MICREL=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 01/11] colibri_imx7: fix boot commands
From: Stefan Agner
Fix mixed up boot commands between raw NAND and eMMC variant. Also
make sure that the boot_file is defined for the eMMC boot command.
Fixes: a62c60610f51 ("colibri_imx7_emmc: add Colibri iMX7D 1GB (eMMC) module
support")
Signed-off-by: Stefan Agner
Acked-by: Marcel Ziswiler
---
Changes in v2: None
include/configs/colibri_imx7.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h
index c31cf2888a..5a4b9801cb 100644
--- a/include/configs/colibri_imx7.h
+++ b/include/configs/colibri_imx7.h
@@ -110,13 +110,13 @@
"run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
#if defined(CONFIG_TARGET_COLIBRI_IMX7_NAND)
-#define CONFIG_BOOTCOMMAND "run emmcboot ; echo ; echo emmcboot failed ; " \
+#define CONFIG_BOOTCOMMAND "run ubiboot ; echo ; echo ubiboot failed ; " \
"setenv fdtfile ${soc}-colibri-${fdt_board}.dtb && run distro_bootcmd;"
#define MODULE_EXTRA_ENV_SETTINGS \
"mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
UBI_BOOTCMD
#elif defined(CONFIG_TARGET_COLIBRI_IMX7_EMMC)
-#define CONFIG_BOOTCOMMAND "run ubiboot ; echo ; echo ubiboot failed ; " \
+#define CONFIG_BOOTCOMMAND "run emmcboot ; echo ; echo emmcboot failed ; " \
"setenv fdtfile ${soc}-colibri-emmc-${fdt_board}.dtb && run
distro_bootcmd;"
#define MODULE_EXTRA_ENV_SETTINGS \
"variant=-emmc\0" \
@@ -143,6 +143,7 @@
NFS_BOOTCMD \
SD_BOOTCMD \
MODULE_EXTRA_ENV_SETTINGS \
+ "boot_file=zImage\0" \
"console=ttymxc0\0" \
"defargs=\0" \
"fdt_board=eval-v3\0" \
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 00/11] arm: Colibri iMX7 fixes and DM_MMC conversion
From: Stefan Agner
This patchset fixes some small issues with Colibri iMX7 and
converts the board to use DM_MMC. It also adds the so far
missing configuration for the eMMC variant.
This patchset gets rid of all but one deprecation warning.
The remaining warning is due to CONFIG_USB still being used.
Fixing this is not entirly trivial due to missing GPIO host/
peripheral switch capabilities and will be tackled later.
--
Stefan
Changes in v2:
- Remove imx7-colibri.dtb from Makefile
- Remove unnecessary properties
- New patch
- New patch
- Add CONFIG_FIT/DFU/CRC32_VERIFY/CMD_GPT/DFU_MMC and FAT_WRITE
Stefan Agner (11):
colibri_imx7: fix boot commands
arm: dts: imx7: colibri: split dt for raw NAND and eMMC devices
configs: colibri_imx7: enable DM for raw NAND devices
configs: colibri_imx7: use separate device tree
arm: dts: imx7: colibri: add usdhci peripherals to device tree
configs: colibri_imx7: use DM_MMC
colibri_imx7: drop legacy usdhc support
configs: colibri_imx7: enable CAAM driver
configs: colibri_imx7: use DFU for NAND instead of MMC
configs: colibri_imx7: use distro defaults
configs: add default configuraiton for Colibri iMX7 with eMMC
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/imx7-colibri-emmc.dts| 47 +
arch/arm/dts/imx7-colibri-rawnand.dts | 46 +
.../{imx7-colibri.dts => imx7-colibri.dtsi} | 65 ++---
board/toradex/colibri_imx7/MAINTAINERS| 3 +
board/toradex/colibri_imx7/colibri_imx7.c | 97 ---
configs/colibri_imx7_defconfig| 27 +++---
configs/colibri_imx7_emmc_defconfig | 66 +
include/configs/colibri_imx7.h| 5 +-
9 files changed, 207 insertions(+), 152 deletions(-)
create mode 100644 arch/arm/dts/imx7-colibri-emmc.dts
create mode 100644 arch/arm/dts/imx7-colibri-rawnand.dts
rename arch/arm/dts/{imx7-colibri.dts => imx7-colibri.dtsi} (68%)
create mode 100644 configs/colibri_imx7_emmc_defconfig
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 9/9] configs: add default configuraiton for Colibri iMX7 with eMMC
On 07.01.2019 00:49, Marcel Ziswiler wrote: > On Sun, 2019-01-06 at 22:00 +0100, Stefan Agner wrote: >> From: Stefan Agner >> >> Add a default configuration for Colibri iMX7D 1GB (with eMMC >> NAND flash). > > Finally (;-p). > >> Signed-off-by: Stefan Agner >> --- >> >> configs/colibri_imx7_emmc_defconfig | 65 >> + >> 1 file changed, 65 insertions(+) >> create mode 100644 configs/colibri_imx7_emmc_defconfig >> >> diff --git a/configs/colibri_imx7_emmc_defconfig >> b/configs/colibri_imx7_emmc_defconfig >> new file mode 100644 >> index 00..5bd8ac943c >> --- /dev/null >> +++ b/configs/colibri_imx7_emmc_defconfig >> @@ -0,0 +1,65 @@ >> +CONFIG_ARM=y >> +CONFIG_SYS_THUMB_BUILD=y >> +CONFIG_ARCH_MX7=y >> +CONFIG_SYS_TEXT_BASE=0x8780 >> +CONFIG_SECURE_BOOT=y >> +CONFIG_TARGET_COLIBRI_IMX7=y >> +CONFIG_TARGET_COLIBRI_IMX7_EMMC=y >> +CONFIG_IMX_RDC=y >> +CONFIG_IMX_BOOTAUX=y >> +# CONFIG_CMD_DEKBLOB is not set >> +CONFIG_ENV_VARS_UBOOT_CONFIG=y >> +CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imxi >> mage.cfg,MX7D" >> +CONFIG_BOOTDELAY=1 >> +# CONFIG_CONSOLE_MUX is not set >> +CONFIG_SYS_CONSOLE_IS_IN_ENV=y >> +# CONFIG_DISPLAY_BOARDINFO is not set >> +CONFIG_DISPLAY_BOARDINFO_LATE=y >> +CONFIG_HUSH_PARSER=y >> +CONFIG_SYS_PROMPT="Colibri iMX7 # " >> +# CONFIG_CMD_BOOTD is not set >> +CONFIG_CMD_BOOTZ=y >> +# CONFIG_CMD_IMI is not set >> +# CONFIG_CMD_XIMG is not set >> +CONFIG_CMD_ASKENV=y >> +CONFIG_CMD_MEMTEST=y >> +CONFIG_CMD_GPIO=y >> +CONFIG_CMD_I2C=y >> +CONFIG_CMD_MMC=y >> +CONFIG_CMD_USB=y >> +CONFIG_CMD_USB_MASS_STORAGE=y >> +CONFIG_CMD_DHCP=y >> +CONFIG_CMD_MII=y >> +CONFIG_CMD_PING=y >> +CONFIG_CMD_BMP=y >> +CONFIG_CMD_CACHE=y >> +# CONFIG_CMD_HASH is not set >> +CONFIG_CMD_EXT4=y >> +CONFIG_CMD_FAT=y >> +CONFIG_CMD_FS_GENERIC=y >> +CONFIG_OF_CONTROL=y >> +CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-emmc" >> +CONFIG_ENV_IS_IN_MMC=y >> +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y >> +CONFIG_FSL_CAAM=y >> +CONFIG_DM_GPIO=y >> +CONFIG_DM_I2C=y >> +CONFIG_DM_MMC=y >> +CONFIG_FSL_ESDHC=y >> +CONFIG_PHYLIB=y >> +CONFIG_PHY_MICREL=y >> +CONFIG_MII=y >> +CONFIG_PINCTRL=y >> +CONFIG_PINCTRL_IMX7=y >> +CONFIG_DM_PMIC=y >> +CONFIG_PMIC_RN5T567=y >> +CONFIG_USB=y >> +CONFIG_USB_EHCI_HCD=y >> +CONFIG_USB_GADGET=y >> +CONFIG_USB_GADGET_MANUFACTURER="Toradex" >> +CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 >> +CONFIG_USB_GADGET_PRODUCT_NUM=0x4000 >> +CONFIG_CI_UDC=y >> +CONFIG_USB_GADGET_DOWNLOAD=y >> +CONFIG_VIDEO=y >> +CONFIG_OF_LIBFDT_OVERLAY=y > > Again, I would use CONFIG_DISTRO_DEFAULTS as well. Plus maybe some > other goodies like CONFIG_FIT, CONFIG_CRC32_VERIFY, CONFIG_CMD_DFU, > CONFIG_CMD_GPT, CONFIG_DFU_MMC and the oldé CONFIG_FAT_WRITE. Okay, will add those. -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/9] configs: colibri_imx7: enable DM for raw NAND devices
On 07.01.2019 00:25, Marcel Ziswiler wrote: > On Sun, 2019-01-06 at 22:00 +0100, Stefan Agner wrote: >> From: Stefan Agner >> >> Use DM and device trees for raw NAND devices by default. This >> fixes -74 NAND read errors since it makes sure the ECC settings >> are the same as used in Linux and our downstream U-Boot. >> >> Signed-off-by: Stefan Agner >> --- >> >> configs/colibri_imx7_defconfig | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/configs/colibri_imx7_defconfig >> b/configs/colibri_imx7_defconfig >> index 7441102ed4..3aaf1a417d 100644 >> --- a/configs/colibri_imx7_defconfig >> +++ b/configs/colibri_imx7_defconfig >> @@ -25,6 +25,7 @@ CONFIG_CMD_DFU=y >> CONFIG_CMD_GPIO=y >> CONFIG_CMD_I2C=y >> CONFIG_CMD_MMC=y >> +CONFIG_CMD_MTD=y >> CONFIG_CMD_NAND_TRIMFFS=y >> CONFIG_CMD_NAND_TORTURE=y >> CONFIG_CMD_USB=y >> @@ -50,7 +51,9 @@ CONFIG_DFU_MMC=y >> CONFIG_DM_GPIO=y >> CONFIG_DM_I2C=y >> CONFIG_FSL_ESDHC=y >> +CONFIG_MTD=y >> CONFIG_NAND=y >> +CONFIG_NAND_MXS_DT=y >> CONFIG_MTD_UBI_FASTMAP=y >> CONFIG_PHYLIB=y >> CONFIG_PHY_MICREL=y > > We might want to add the following as well: > > CONFIG_DFU_NAND=y > > Plus I do not understand why we do not use CONFIG_DISTRO_DEFAULTS which would > include a lot of our now manually picked configuration items. Hm, good catch. There is CONFIG_DFU_MMC enabled for some reason, seemed to have slipped in in a Kconfig move. Will fix this. -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/9] arm: dts: imx7: colibri: split dt for raw NAND and eMMC devices
On 07.01.2019 00:18, Marcel Ziswiler wrote:
> On Sun, 2019-01-06 at 22:00 +0100, Stefan Agner wrote:
>> From: Stefan Agner
>>
>> In preparation of adding CONFIG_DM_MMC support use separate device
>> trees for raw NAND and eMMC devices.
>>
>> Signed-off-by: Stefan Agner
>> ---
>>
>> arch/arm/dts/imx7-colibri-emmc.dts| 16 +++
>> arch/arm/dts/imx7-colibri-rawnand.dts | 46
>> +++
>> .../{imx7-colibri.dts => imx7-colibri.dtsi} | 39 +---
>
> I believe renaming that one also needs changes in resp. Makefile
> otherwise leading to the following:
>
> make[3]: *** No rule to make target 'arch/arm/dts/imx7-colibri.dtb',
> needed by 'dtbs'. Stop.
Good catch, I definitely need to remove imx7-colibri.dtb there.
>
> Plus you may want to add the eMMC one as well e.g. as follows:
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index dda4e59491..9596b2a64f 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -458,7 +458,8 @@ dtb-$(CONFIG_MX6UL) += \
>
> dtb-$(CONFIG_MX6ULL) += imx6ull-14x14-evk.dtb
>
> -dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
> +dtb-$(CONFIG_MX7) += imx7-colibri-emmc.dtb \
> + imx7-colibri-rawnand.dtb \
> imx7d-sdb.dtb \
> imx7d-sdb-qspi.dtb
It seems that removing is actually sufficient. dtc/Makefile along with
CONFIG_OF_EMBED actually builds the device tree specified in the config
file automatically. Should we still add board device trees to
arch/arm/dts/Makefile?
@Stefano/ML any preference?
>
> BTW: Remember, I am not too big of a fan of renaming stuff and
> everywhere else we so far did not call anything -rawnand as of yet.
> However, in general I agree that this would be more clear and if you do
> clean-up the rest of the world(TM) in a similar fashion I am OK with
> it.
>
I don't _re_name, I just name :-) When we had to name the dt's in the
kernel, we did not knew that there will be an eMMC variant. It's a
different start condition here.
Also mind that device trees are named differently: Since we use the same
boot loader for i.MX 7S and 7D, I dropped a letter there too... IMHO,
renaming the dt in Linux now is too much churn. So I suggest either
leave as is in Kernel and deviate a bit in U-Boot or drop -rawnand in
U-Boot, what do you think?
--
Stefan
>> board/toradex/colibri_imx7/MAINTAINERS| 3 ++
>> configs/colibri_imx7_defconfig| 2 +-
>> 5 files changed, 67 insertions(+), 39 deletions(-)
>> create mode 100644 arch/arm/dts/imx7-colibri-emmc.dts
>> create mode 100644 arch/arm/dts/imx7-colibri-rawnand.dts
>> rename arch/arm/dts/{imx7-colibri.dts => imx7-colibri.dtsi} (65%)
>>
>> diff --git a/arch/arm/dts/imx7-colibri-emmc.dts b/arch/arm/dts/imx7-
>> colibri-emmc.dts
>> new file mode 100644
>> index 00..295ca05916
>> --- /dev/null
>> +++ b/arch/arm/dts/imx7-colibri-emmc.dts
>> @@ -0,0 +1,16 @@
>> +// SPDX-License-Identifier: GPL-2.0+ OR X11
>
> Don't we rather want GPL-2.0 OR MIT?
>
>> +/*
>> + * Copyright 2019 Toradex AG
>> + */
>> +
>> +/dts-v1/;
>> +#include "imx7-colibri.dtsi"
>> +
>> +/ {
>> +model = "Toradex Colibri iMX7D 1GB (eMMC)";
>> +compatible = "toradex,imx7d-colibri-emmc", "fsl,imx7d";
>> +
>> +chosen {
>> +stdout-path =
>> +};
>> +};
>
> I guess the meat-on-the-bone will follow (;-p).
>
>> diff --git a/arch/arm/dts/imx7-colibri-rawnand.dts
>> b/arch/arm/dts/imx7-colibri-rawnand.dts
>> new file mode 100644
>> index 00..4eb86fb011
>> --- /dev/null
>> +++ b/arch/arm/dts/imx7-colibri-rawnand.dts
>> @@ -0,0 +1,46 @@
>> +// SPDX-License-Identifier: GPL-2.0+ OR X11
>
> Dito.
>
>> +/*
>> + * Copyright 2019 Toradex AG
>> + */
>> +
>> +/dts-v1/;
>> +#include "imx7-colibri.dtsi"
>> +
>> +/ {
>> +model = "Toradex Colibri iMX7S/D";
>> +compatible = "toradex,imx7-colibri", "fsl,imx7";
>> +
>> +chosen {
>> +stdout-path =
>> +};
>> +};
>> +
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_gpmi_nand>;
>> +,use-minimum-ecc;
>> +nand-on-flash-bbt;
>> +-ecc-mode = "hw";
>> +status = "okay";
>> +};
>> +
>> + {
>> +pinctrl_gpmi_nand: gpmi-nand-grp {
>> +fsl,pins = <
>> +MX7D_PAD_SD3_CLK__
[U-Boot] [PATCH v1 8/9] configs: colibri_imx7: enable CAAM driver
From: Stefan Agner Access to CAAM in non-secure mode must be enabled by the boot loader first. The U-Boot CAAM driver enables access to CAAM in non-secure mode by default. Hence enable the CAAM driver to allow Linux accessing CAAM directly. This prevents error messages like the following on Linux boot: caam 3090.caam: Entropy delay = 3200 caam 3090.caam: failed to acquire DECO 0 caam 3090.caam: failed to instantiate RNG Signed-off-by: Stefan Agner --- configs/colibri_imx7_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig index af976bab12..c6fd7f3f4e 100644 --- a/configs/colibri_imx7_defconfig +++ b/configs/colibri_imx7_defconfig @@ -2,9 +2,11 @@ CONFIG_ARM=y CONFIG_SYS_THUMB_BUILD=y CONFIG_ARCH_MX7=y CONFIG_SYS_TEXT_BASE=0x8780 +CONFIG_SECURE_BOOT=y CONFIG_TARGET_COLIBRI_IMX7=y CONFIG_IMX_RDC=y CONFIG_IMX_BOOTAUX=y +# CONFIG_CMD_DEKBLOB is not set CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_NR_DRAM_BANKS=1 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D" @@ -35,6 +37,7 @@ CONFIG_CMD_MII=y CONFIG_CMD_PING=y CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y +# CONFIG_CMD_HASH is not set CONFIG_CMD_EXT4=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y @@ -46,6 +49,7 @@ CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-rawnand" CONFIG_ENV_IS_IN_NAND=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y +CONFIG_FSL_CAAM=y CONFIG_DFU_MMC=y CONFIG_DM_GPIO=y CONFIG_DM_I2C=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 5/9] arm: dts: imx7: colibri: add usdhci peripherals to device tree
From: Stefan Agner
Add usdhci peripherals to device tree. This allows to use DM_MMC
for Colibri iMX7 devices.
Signed-off-by: Stefan Agner
---
arch/arm/dts/imx7-colibri-emmc.dts| 69 +++
arch/arm/dts/imx7-colibri-rawnand.dts | 4 ++
arch/arm/dts/imx7-colibri.dtsi| 28 +++
3 files changed, 101 insertions(+)
diff --git a/arch/arm/dts/imx7-colibri-emmc.dts
b/arch/arm/dts/imx7-colibri-emmc.dts
index 295ca05916..8cf8befc7f 100644
--- a/arch/arm/dts/imx7-colibri-emmc.dts
+++ b/arch/arm/dts/imx7-colibri-emmc.dts
@@ -10,7 +10,76 @@
model = "Toradex Colibri iMX7D 1GB (eMMC)";
compatible = "toradex,imx7d-colibri-emmc", "fsl,imx7d";
+ aliases {
+ mmc0 =
+ mmc1 =
+ };
+
chosen {
stdout-path =
};
};
+
+ {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <_usdhc3>;
+ pinctrl-1 = <_usdhc3_100mhz>;
+ pinctrl-2 = <_usdhc3_200mhz>;
+ assigned-clocks = < IMX7D_USDHC3_ROOT_CLK>;
+ assigned-clock-rates = <4>;
+ bus-width = <8>;
+ fsl,tuning-step = <2>;
+ non-removable;
+ sdhci-caps-mask = <0x8000 0x0>;
+ status = "okay";
+};
+
+ {
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX7D_PAD_SD3_CMD__SD3_CMD 0x59
+ MX7D_PAD_SD3_CLK__SD3_CLK 0x19
+ MX7D_PAD_SD3_DATA0__SD3_DATA0 0x59
+ MX7D_PAD_SD3_DATA1__SD3_DATA1 0x59
+ MX7D_PAD_SD3_DATA2__SD3_DATA2 0x59
+ MX7D_PAD_SD3_DATA3__SD3_DATA3 0x59
+ MX7D_PAD_SD3_DATA4__SD3_DATA4 0x59
+ MX7D_PAD_SD3_DATA5__SD3_DATA5 0x59
+ MX7D_PAD_SD3_DATA6__SD3_DATA6 0x59
+ MX7D_PAD_SD3_DATA7__SD3_DATA7 0x59
+ MX7D_PAD_SD3_STROBE__SD3_STROBE 0x19
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3grp_100mhz {
+ fsl,pins = <
+ MX7D_PAD_SD3_CMD__SD3_CMD 0x5a
+ MX7D_PAD_SD3_CLK__SD3_CLK 0x1a
+ MX7D_PAD_SD3_DATA0__SD3_DATA0 0x5a
+ MX7D_PAD_SD3_DATA1__SD3_DATA1 0x5a
+ MX7D_PAD_SD3_DATA2__SD3_DATA2 0x5a
+ MX7D_PAD_SD3_DATA3__SD3_DATA3 0x5a
+ MX7D_PAD_SD3_DATA4__SD3_DATA4 0x5a
+ MX7D_PAD_SD3_DATA5__SD3_DATA5 0x5a
+ MX7D_PAD_SD3_DATA6__SD3_DATA6 0x5a
+ MX7D_PAD_SD3_DATA7__SD3_DATA7 0x5a
+ MX7D_PAD_SD3_STROBE__SD3_STROBE 0x1a
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3grp_200mhz {
+ fsl,pins = <
+ MX7D_PAD_SD3_CMD__SD3_CMD 0x5b
+ MX7D_PAD_SD3_CLK__SD3_CLK 0x1b
+ MX7D_PAD_SD3_DATA0__SD3_DATA0 0x5b
+ MX7D_PAD_SD3_DATA1__SD3_DATA1 0x5b
+ MX7D_PAD_SD3_DATA2__SD3_DATA2 0x5b
+ MX7D_PAD_SD3_DATA3__SD3_DATA3 0x5b
+ MX7D_PAD_SD3_DATA4__SD3_DATA4 0x5b
+ MX7D_PAD_SD3_DATA5__SD3_DATA5 0x5b
+ MX7D_PAD_SD3_DATA6__SD3_DATA6 0x5b
+ MX7D_PAD_SD3_DATA7__SD3_DATA7 0x5b
+ MX7D_PAD_SD3_STROBE__SD3_STROBE 0x1b
+ >;
+ };
+};
diff --git a/arch/arm/dts/imx7-colibri-rawnand.dts
b/arch/arm/dts/imx7-colibri-rawnand.dts
index 4eb86fb011..5d64e5ef41 100644
--- a/arch/arm/dts/imx7-colibri-rawnand.dts
+++ b/arch/arm/dts/imx7-colibri-rawnand.dts
@@ -10,6 +10,10 @@
model = "Toradex Colibri iMX7S/D";
compatible = "toradex,imx7-colibri", "fsl,imx7";
+ aliases {
+ mmc0 =
+ };
+
chosen {
stdout-path =
};
diff --git a/arch/arm/dts/imx7-colibri.dtsi b/arch/arm/dts/imx7-colibri.dtsi
index 47295117aa..3a627fc941 100644
--- a/arch/arm/dts/imx7-colibri.dtsi
+++ b/arch/arm/dts/imx7-colibri.dtsi
@@ -38,6 +38,17 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_usdhc1 _cd_usdhc1>;
+ no-1-8-v;
+ cd-gpios = < 0 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ fsl,tuning-start-tap = <20>;
+ fsl,tunin
[U-Boot] [PATCH v1 6/9] configs: colibri_imx7: use DM_MMC
From: Stefan Agner Now that device tree is in place use DM_MMC for Colibri iMX7 devices. Signed-off-by: Stefan Agner --- configs/colibri_imx7_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig index 0c9467e136..af976bab12 100644 --- a/configs/colibri_imx7_defconfig +++ b/configs/colibri_imx7_defconfig @@ -49,6 +49,7 @@ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_DFU_MMC=y CONFIG_DM_GPIO=y CONFIG_DM_I2C=y +CONFIG_DM_MMC=y CONFIG_FSL_ESDHC=y CONFIG_MTD=y CONFIG_NAND=y @@ -63,7 +64,6 @@ CONFIG_DM_PMIC=y CONFIG_PMIC_RN5T567=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y -CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Toradex" CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 4/9] configs: colibri_imx7: use separate device tree
From: Stefan Agner Use OF_SEPARATE as suggested by the build system. Signed-off-by: Stefan Agner --- configs/colibri_imx7_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig index 3aaf1a417d..0c9467e136 100644 --- a/configs/colibri_imx7_defconfig +++ b/configs/colibri_imx7_defconfig @@ -43,7 +43,6 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand" CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:512k(mx7-bcb),1536k(u-boot1)ro,1536k(u-boot2)ro,512k(u-boot-env),-(ubi)" CONFIG_CMD_UBI=y CONFIG_OF_CONTROL=y -CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-rawnand" CONFIG_ENV_IS_IN_NAND=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 7/9] colibri_imx7: drop legacy usdhc support
From: Stefan Agner
Drop legacy pinmux/usdhc board configuration.
Signed-off-by: Stefan Agner
---
board/toradex/colibri_imx7/colibri_imx7.c | 97 ---
1 file changed, 97 deletions(-)
diff --git a/board/toradex/colibri_imx7/colibri_imx7.c
b/board/toradex/colibri_imx7/colibri_imx7.c
index a4c99626b4..392fda92da 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -33,9 +33,6 @@ DECLARE_GLOBAL_DATA_PTR;
#define UART_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | \
PAD_CTL_PUS_PU100KOHM | PAD_CTL_HYS)
-#define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
- PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
-
#define ENET_PAD_CTRL (PAD_CTL_PUS_PU100KOHM | PAD_CTL_DSE_3P3V_49OHM)
#define ENET_PAD_CTRL_MII (PAD_CTL_DSE_3P3V_32OHM)
@@ -64,17 +61,6 @@ static iomux_v3_cfg_t const uart1_pads[] = {
MX7D_PAD_SAI2_TX_SYNC__UART1_DTE_RTS | MUX_PAD_CTRL(UART_PAD_CTRL),
};
-static iomux_v3_cfg_t const usdhc1_pads[] = {
- MX7D_PAD_SD1_CLK__SD1_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD1_CMD__SD1_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD1_DATA0__SD1_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD1_DATA1__SD1_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD1_DATA2__SD1_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD1_DATA3__SD1_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-
- MX7D_PAD_GPIO1_IO00__GPIO1_IO0 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
#ifdef CONFIG_USB_EHCI_MX7
static iomux_v3_cfg_t const usb_cdet_pads[] = {
MX7D_PAD_ENET1_CRS__GPIO7_IO14 | MUX_PAD_CTRL(NO_PAD_CTRL),
@@ -109,24 +95,6 @@ static void setup_gpmi_nand(void)
}
#endif
-#ifdef CONFIG_TARGET_COLIBRI_IMX7_EMMC
-static iomux_v3_cfg_t const usdhc3_emmc_pads[] = {
- MX7D_PAD_SD3_CLK__SD3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_CMD__SD3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA4__SD3_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA5__SD3_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA6__SD3_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_DATA7__SD3_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX7D_PAD_SD3_STROBE__SD3_STROBE | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-
- MX7D_PAD_SD3_RESET_B__GPIO6_IO11 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-};
-#endif
-
#ifdef CONFIG_VIDEO_MXS
static iomux_v3_cfg_t const lcd_pads[] = {
MX7D_PAD_LCD_CLK__LCD_CLK | MUX_PAD_CTRL(LCD_PAD_CTRL),
@@ -211,71 +179,6 @@ static void setup_iomux_uart(void)
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
}
-#ifdef CONFIG_FSL_ESDHC
-
-#define USDHC1_CD_GPIO IMX_GPIO_NR(1, 0)
-
-static struct fsl_esdhc_cfg usdhc_cfg[] = {
-#ifdef CONFIG_TARGET_COLIBRI_IMX7_EMMC
- {USDHC3_BASE_ADDR},
-#endif
- {USDHC1_BASE_ADDR, 0, 4},
-};
-
-int board_mmc_getcd(struct mmc *mmc)
-{
- struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
- int ret = 0;
-
- switch (cfg->esdhc_base) {
- case USDHC1_BASE_ADDR:
- ret = !gpio_get_value(USDHC1_CD_GPIO);
- break;
-#ifdef CONFIG_TARGET_COLIBRI_IMX7_EMMC
- case USDHC3_BASE_ADDR:
- ret = 1;
- break;
-#endif
- }
-
- return ret;
-}
-
-int board_mmc_init(bd_t *bis)
-{
- int i, ret;
- /* USDHC1 is mmc0, USDHC3 is mmc1 */
- for (i = 0; i < CONFIG_SYS_FSL_USDHC_NUM; i++) {
- switch (i) {
- case 0:
- imx_iomux_v3_setup_multiple_pads(
- usdhc1_pads, ARRAY_SIZE(usdhc1_pads));
- gpio_request(USDHC1_CD_GPIO, "usdhc1_cd");
- gpio_direction_input(USDHC1_CD_GPIO);
- usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
- break;
-#ifdef CONFIG_TARGET_COLIBRI_IMX7_EMMC
- case 1:
- imx_iomux_v3_setup_multiple_pads(usdhc3_emmc_pads,
- ARRAY_SIZE(usdhc3_emmc_pads));
- usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
- break;
-#endif
- default:
- printf("Warning: you configured more USDHC controllers"
- "(%d) than supported by the board\n", i + 1);
- return -EINVAL;
- }
-
- ret = fsl_esdhc_initialize(bis, _cfg[i]);
- if (ret)
- return ret;
- }
-
- return 0;
-}
-#endif
-
#ifdef CONFIG_FEC_MXC
int
[U-Boot] [PATCH v1 9/9] configs: add default configuraiton for Colibri iMX7 with eMMC
From: Stefan Agner Add a default configuration for Colibri iMX7D 1GB (with eMMC NAND flash). Signed-off-by: Stefan Agner --- configs/colibri_imx7_emmc_defconfig | 65 + 1 file changed, 65 insertions(+) create mode 100644 configs/colibri_imx7_emmc_defconfig diff --git a/configs/colibri_imx7_emmc_defconfig b/configs/colibri_imx7_emmc_defconfig new file mode 100644 index 00..5bd8ac943c --- /dev/null +++ b/configs/colibri_imx7_emmc_defconfig @@ -0,0 +1,65 @@ +CONFIG_ARM=y +CONFIG_SYS_THUMB_BUILD=y +CONFIG_ARCH_MX7=y +CONFIG_SYS_TEXT_BASE=0x8780 +CONFIG_SECURE_BOOT=y +CONFIG_TARGET_COLIBRI_IMX7=y +CONFIG_TARGET_COLIBRI_IMX7_EMMC=y +CONFIG_IMX_RDC=y +CONFIG_IMX_BOOTAUX=y +# CONFIG_CMD_DEKBLOB is not set +CONFIG_ENV_VARS_UBOOT_CONFIG=y +CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D" +CONFIG_BOOTDELAY=1 +# CONFIG_CONSOLE_MUX is not set +CONFIG_SYS_CONSOLE_IS_IN_ENV=y +# CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_HUSH_PARSER=y +CONFIG_SYS_PROMPT="Colibri iMX7 # " +# CONFIG_CMD_BOOTD is not set +CONFIG_CMD_BOOTZ=y +# CONFIG_CMD_IMI is not set +# CONFIG_CMD_XIMG is not set +CONFIG_CMD_ASKENV=y +CONFIG_CMD_MEMTEST=y +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +CONFIG_CMD_USB_MASS_STORAGE=y +CONFIG_CMD_DHCP=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_BMP=y +CONFIG_CMD_CACHE=y +# CONFIG_CMD_HASH is not set +CONFIG_CMD_EXT4=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-emmc" +CONFIG_ENV_IS_IN_MMC=y +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y +CONFIG_FSL_CAAM=y +CONFIG_DM_GPIO=y +CONFIG_DM_I2C=y +CONFIG_DM_MMC=y +CONFIG_FSL_ESDHC=y +CONFIG_PHYLIB=y +CONFIG_PHY_MICREL=y +CONFIG_MII=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX7=y +CONFIG_DM_PMIC=y +CONFIG_PMIC_RN5T567=y +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="Toradex" +CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 +CONFIG_USB_GADGET_PRODUCT_NUM=0x4000 +CONFIG_CI_UDC=y +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_VIDEO=y +CONFIG_OF_LIBFDT_OVERLAY=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 3/9] configs: colibri_imx7: enable DM for raw NAND devices
From: Stefan Agner Use DM and device trees for raw NAND devices by default. This fixes -74 NAND read errors since it makes sure the ECC settings are the same as used in Linux and our downstream U-Boot. Signed-off-by: Stefan Agner --- configs/colibri_imx7_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig index 7441102ed4..3aaf1a417d 100644 --- a/configs/colibri_imx7_defconfig +++ b/configs/colibri_imx7_defconfig @@ -25,6 +25,7 @@ CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_MTD=y CONFIG_CMD_NAND_TRIMFFS=y CONFIG_CMD_NAND_TORTURE=y CONFIG_CMD_USB=y @@ -50,7 +51,9 @@ CONFIG_DFU_MMC=y CONFIG_DM_GPIO=y CONFIG_DM_I2C=y CONFIG_FSL_ESDHC=y +CONFIG_MTD=y CONFIG_NAND=y +CONFIG_NAND_MXS_DT=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_PHYLIB=y CONFIG_PHY_MICREL=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 2/9] arm: dts: imx7: colibri: split dt for raw NAND and eMMC devices
From: Stefan Agner
In preparation of adding CONFIG_DM_MMC support use separate device
trees for raw NAND and eMMC devices.
Signed-off-by: Stefan Agner
---
arch/arm/dts/imx7-colibri-emmc.dts| 16 +++
arch/arm/dts/imx7-colibri-rawnand.dts | 46 +++
.../{imx7-colibri.dts => imx7-colibri.dtsi} | 39 +---
board/toradex/colibri_imx7/MAINTAINERS| 3 ++
configs/colibri_imx7_defconfig| 2 +-
5 files changed, 67 insertions(+), 39 deletions(-)
create mode 100644 arch/arm/dts/imx7-colibri-emmc.dts
create mode 100644 arch/arm/dts/imx7-colibri-rawnand.dts
rename arch/arm/dts/{imx7-colibri.dts => imx7-colibri.dtsi} (65%)
diff --git a/arch/arm/dts/imx7-colibri-emmc.dts
b/arch/arm/dts/imx7-colibri-emmc.dts
new file mode 100644
index 00..295ca05916
--- /dev/null
+++ b/arch/arm/dts/imx7-colibri-emmc.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 Toradex AG
+ */
+
+/dts-v1/;
+#include "imx7-colibri.dtsi"
+
+/ {
+ model = "Toradex Colibri iMX7D 1GB (eMMC)";
+ compatible = "toradex,imx7d-colibri-emmc", "fsl,imx7d";
+
+ chosen {
+ stdout-path =
+ };
+};
diff --git a/arch/arm/dts/imx7-colibri-rawnand.dts
b/arch/arm/dts/imx7-colibri-rawnand.dts
new file mode 100644
index 00..4eb86fb011
--- /dev/null
+++ b/arch/arm/dts/imx7-colibri-rawnand.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 Toradex AG
+ */
+
+/dts-v1/;
+#include "imx7-colibri.dtsi"
+
+/ {
+ model = "Toradex Colibri iMX7S/D";
+ compatible = "toradex,imx7-colibri", "fsl,imx7";
+
+ chosen {
+ stdout-path =
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpmi_nand>;
+ fsl,use-minimum-ecc;
+ nand-on-flash-bbt;
+ nand-ecc-mode = "hw";
+ status = "okay";
+};
+
+ {
+ pinctrl_gpmi_nand: gpmi-nand-grp {
+ fsl,pins = <
+ MX7D_PAD_SD3_CLK__NAND_CLE 0x71
+ MX7D_PAD_SD3_CMD__NAND_ALE 0x71
+ MX7D_PAD_SAI1_TX_BCLK__NAND_CE0_B 0x71
+ MX7D_PAD_SAI1_TX_DATA__NAND_READY_B 0x74
+ MX7D_PAD_SD3_STROBE__NAND_RE_B 0x71
+ MX7D_PAD_SD3_RESET_B__NAND_WE_B 0x71
+ MX7D_PAD_SD3_DATA0__NAND_DATA00 0x71
+ MX7D_PAD_SD3_DATA1__NAND_DATA01 0x71
+ MX7D_PAD_SD3_DATA2__NAND_DATA02 0x71
+ MX7D_PAD_SD3_DATA3__NAND_DATA03 0x71
+ MX7D_PAD_SD3_DATA4__NAND_DATA04 0x71
+ MX7D_PAD_SD3_DATA5__NAND_DATA05 0x71
+ MX7D_PAD_SD3_DATA6__NAND_DATA06 0x71
+ MX7D_PAD_SD3_DATA7__NAND_DATA07 0x71
+ >;
+ };
+};
diff --git a/arch/arm/dts/imx7-colibri.dts b/arch/arm/dts/imx7-colibri.dtsi
similarity index 65%
rename from arch/arm/dts/imx7-colibri.dts
rename to arch/arm/dts/imx7-colibri.dtsi
index dca501be25..47295117aa 100644
--- a/arch/arm/dts/imx7-colibri.dts
+++ b/arch/arm/dts/imx7-colibri.dtsi
@@ -1,30 +1,12 @@
// SPDX-License-Identifier: GPL-2.0+ OR X11
/*
- * Copyright 2016 Toradex AG
+ * Copyright 2016-2019 Toradex AG
*/
/dts-v1/;
#include
#include "imx7d.dtsi"
-/ {
- model = "Toradex Colibri iMX7S/D";
- compatible = "toradex,imx7-colibri", "fsl,imx7";
-
- chosen {
- stdout-path =
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_gpmi_nand>;
- fsl,use-minimum-ecc;
- nand-on-flash-bbt;
- nand-ecc-mode = "hw";
- status = "okay";
-};
-
{
pinctrl-names = "default", "gpio";
pinctrl-0 = <_i2c1>;
@@ -57,25 +39,6 @@
};
{
- pinctrl_gpmi_nand: gpmi-nand-grp {
- fsl,pins = <
- MX7D_PAD_SD3_CLK__NAND_CLE 0x71
- MX7D_PAD_SD3_CMD__NAND_ALE 0x71
- MX7D_PAD_SAI1_TX_BCLK__NAND_CE0_B 0x71
- MX7D_PAD_SAI1_TX_DATA__NAND_READY_B 0x74
- MX7D_PAD_SD3_STROBE__NAND_RE_B 0x71
- MX7D_PAD_SD3_RESET_B__NAND_WE_B 0x71
- MX7D_PAD_SD3_DATA0__NAND_DATA00 0x71
- MX7D_PAD_SD3_DATA1__NAND_DATA01 0x71
- MX7D_PAD_SD3_DATA2__NAND_DATA02 0x71
- MX7D_PAD_SD3_DATA3__NAND_DATA03 0x71
- MX7D_PAD_SD3_DATA4
[U-Boot] [PATCH v1 1/9] colibri_imx7: fix boot commands
From: Stefan Agner
Fix mixed up boot commands between raw NAND and eMMC variant. Also
make sure that the boot_file is defined for the eMMC boot command.
Fixes: a62c60610f51 ("colibri_imx7_emmc: add Colibri iMX7D 1GB (eMMC) module
support")
Signed-off-by: Stefan Agner
---
include/configs/colibri_imx7.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h
index c31cf2888a..5a4b9801cb 100644
--- a/include/configs/colibri_imx7.h
+++ b/include/configs/colibri_imx7.h
@@ -110,13 +110,13 @@
"run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
#if defined(CONFIG_TARGET_COLIBRI_IMX7_NAND)
-#define CONFIG_BOOTCOMMAND "run emmcboot ; echo ; echo emmcboot failed ; " \
+#define CONFIG_BOOTCOMMAND "run ubiboot ; echo ; echo ubiboot failed ; " \
"setenv fdtfile ${soc}-colibri-${fdt_board}.dtb && run distro_bootcmd;"
#define MODULE_EXTRA_ENV_SETTINGS \
"mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
UBI_BOOTCMD
#elif defined(CONFIG_TARGET_COLIBRI_IMX7_EMMC)
-#define CONFIG_BOOTCOMMAND "run ubiboot ; echo ; echo ubiboot failed ; " \
+#define CONFIG_BOOTCOMMAND "run emmcboot ; echo ; echo emmcboot failed ; " \
"setenv fdtfile ${soc}-colibri-emmc-${fdt_board}.dtb && run
distro_bootcmd;"
#define MODULE_EXTRA_ENV_SETTINGS \
"variant=-emmc\0" \
@@ -143,6 +143,7 @@
NFS_BOOTCMD \
SD_BOOTCMD \
MODULE_EXTRA_ENV_SETTINGS \
+ "boot_file=zImage\0" \
"console=ttymxc0\0" \
"defargs=\0" \
"fdt_board=eval-v3\0" \
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 0/9] arm: Colibri iMX7 fixes and DM_MMC conversion
From: Stefan Agner
This patchset fixes some small issues with Colibri iMX7 and
converts the board to use DM_MMC. It also adds the so far
missing configuration for the eMMC variant.
This patchset gets rid of all but one deprecation warning.
The remaining warning is due to CONFIG_USB still being used.
Fixing this is not entirly trivial due to missing GPIO host/
peripheral switch capabilities and will be tackled later.
--
Stefan
Stefan Agner (9):
colibri_imx7: fix boot commands
arm: dts: imx7: colibri: split dt for raw NAND and eMMC devices
configs: colibri_imx7: enable DM for raw NAND devices
configs: colibri_imx7: use separate device tree
arm: dts: imx7: colibri: add usdhci peripherals to device tree
configs: colibri_imx7: use DM_MMC
colibri_imx7: drop legacy usdhc support
configs: colibri_imx7: enable CAAM driver
configs: add default configuraiton for Colibri iMX7 with eMMC
arch/arm/dts/imx7-colibri-emmc.dts| 85
arch/arm/dts/imx7-colibri-rawnand.dts | 50 ++
.../{imx7-colibri.dts => imx7-colibri.dtsi} | 67 ++---
board/toradex/colibri_imx7/MAINTAINERS| 3 +
board/toradex/colibri_imx7/colibri_imx7.c | 97 ---
configs/colibri_imx7_defconfig| 12 ++-
configs/colibri_imx7_emmc_defconfig | 65 +
include/configs/colibri_imx7.h| 5 +-
8 files changed, 244 insertions(+), 140 deletions(-)
create mode 100644 arch/arm/dts/imx7-colibri-emmc.dts
create mode 100644 arch/arm/dts/imx7-colibri-rawnand.dts
rename arch/arm/dts/{imx7-colibri.dts => imx7-colibri.dtsi} (68%)
create mode 100644 configs/colibri_imx7_emmc_defconfig
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] tools: logos: crop Toradex logo slightly
Hi Stefano, On 14.12.2018 14:40, Stefano Babic wrote: > On 14/12/18 14:30, Tom Rini wrote: >> On Fri, Dec 14, 2018 at 02:26:22PM +0100, Stefan Agner wrote: >>> On 14.12.2018 14:20, Tom Rini wrote: >>>> On Fri, Dec 14, 2018 at 02:13:46PM +0100, Stefan Agner wrote: >>>>> Hi Tom, >>>>> >>>>> On 08.12.2018 17:48, Lukasz Majewski wrote: >>>>>> Hi Stefan, >>>>>> >>>>>>> From: Stefan Agner >>>>>>> >>>>>>> The current bitmap is a bit larger than necessary, it has a black >>>>>>> border around the Toradex logo. Crop the logo slightly which safes >>>>>>> some space, useful especially on Colibri VFxx. >>>>>> >>>>>> I can confirm that those changes, as well as >>>>>> >>>>>> [PATCH v1] board: toradex: colibri_vf: unset NFS and LOADS/B >>>>>> [PATCH v1] mtd: nand: raw: allow to disable unneeded ECC layouts >>>>>> [PATCH v1] fs: fat: dynamically allocate memory for temporary buffer >>>>> >>>>> I think all of those go directly into your tree? >>>> >>>> I had filed vybird stuff off to Stefano for some, hopefully correct >>>> reason. The FAT change and logo change are me, yes. >>> >>> I guess the mtd change is rather global... >> >> Ah right. Maybe I gave it to myself? I know I assigned it in >> patchwork. >> >>> Currently board/toradex is not specifically marked to be maintained by >>> Stefano (we also have Tegra boards). But yeah for Vybrid it probably >>> makes sense. >> > > Yes, I saw your patches, I will picked them up after current PR (sent > now) will be merged. This still did not make it. Can it still be considered for the next release? There is also: - board: toradex: colibri_vf: unset NFS and LOADS/B - ARM: vf610: ddrmc: program Dummy DDRBYTE1/2 - ddr: vybrid: various fixes (patchset) -- Stefan > >> Right, I try and assign boards based on the underlying SoC correctly but >> do also from time to time get them wrong (there's a handful of "wait >> that's not TI-based that's iMX-based, oops" I catch myself on). >> > > Regards, > Stefano ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: mxs_nand: Fix BCH read timeout error on boards requiring ECC
[this time using reply to all] On 03.01.19 03:36, Adam Ford wrote: > The LogicPD board uses a Micron Flash with ECC. To boot this from > SPL, the ECC needs to be correctly configured or the BCH engine > times out. > > Signed-off-by: Adam Ford Looks good to me, Acked-by: Stefan Agner > > diff --git a/drivers/mtd/nand/raw/mxs_nand.c b/drivers/mtd/nand/raw/mxs_nand.c > index e3341812a2..2d84bfffe2 100644 > --- a/drivers/mtd/nand/raw/mxs_nand.c > +++ b/drivers/mtd/nand/raw/mxs_nand.c > @@ -1163,6 +1163,12 @@ int mxs_nand_init_spl(struct nand_chip *nand) > > nand_info->gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE; > nand_info->bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE; > + > + if (is_mx6sx() || is_mx7()) > + nand_info->max_ecc_strength_supported = 62; > + else > + nand_info->max_ecc_strength_supported = 40; > + > err = mxs_nand_alloc_buffers(nand_info); > if (err) > return err; > diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c > b/drivers/mtd/nand/raw/mxs_nand_spl.c > index c628f3adec..ba85baac60 100644 > --- a/drivers/mtd/nand/raw/mxs_nand_spl.c > +++ b/drivers/mtd/nand/raw/mxs_nand_spl.c > @@ -201,6 +201,7 @@ static int mxs_nand_init(void) > /* setup flash layout (does not scan as we override that) */ > mtd->size = nand_chip.chipsize; > nand_chip.scan_bbt(mtd); > + mxs_nand_setup_ecc(mtd); > > return 0; > } > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: nand: mxs_nand_spl: Fix empty function pointer for BBT
On 30.12.18 17:11, Adam Ford wrote: > The initialization function calls a nand_chip.scan_bbt(mtd) but > scan_bbt is never initialized resulting in an undefined function > pointer. This will direct the function pointer to nand_default_bbt > defined in the same file. > > Signed-off-by: Adam Ford Seems sensible Acked-by: Stefan Agner > > diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c > b/drivers/mtd/nand/raw/mxs_nand_spl.c > index 2d7bbe83cc..c628f3adec 100644 > --- a/drivers/mtd/nand/raw/mxs_nand_spl.c > +++ b/drivers/mtd/nand/raw/mxs_nand_spl.c > @@ -185,6 +185,7 @@ static int mxs_nand_init(void) > mtd = nand_to_mtd(_chip); > /* set mtd functions */ > nand_chip.cmdfunc = mxs_nand_command; > + nand_chip.scan_bbt = nand_default_bbt; > nand_chip.numchips = 1; > > /* identify flash device */ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx6: apalis: Make the boot process more generic
Hi Petr,
[this time to the ML]
On 16.12.2018 12:06, Petr Štetiar wrote:
> I'm preparing support for Apalis imx6 boards in OpenWrt and I've ended
> up with quite huge patchset against upstream U-Boot 2018.03, so I'm
> trying to propose more generic way of boot process handling.
I agree a more flexible boot process would be better. There is distro
boot for that purpose, and I suggest using that by default. We did
enable distro boot in our downstream U-Boot [1] and also make use of it
in the Toradex Easy Installer [2] configuration (run distro_bootcmd).
Also check doc/README.distro. I think it should not need changes on
OpenWrt side since distro boot loads and executes boot.scr.
Additionally, it also guarantees that some variables are setup (e.g.
devtype, devnum and distro_bootpart) which allows to write generic boot
scripts.
[1]
http://git.toradex.com/cgit/u-boot-toradex.git/commit/include/configs/apalis_imx6.h?h=2016.11-toradex-next=a283b85daaefbe11a5a7b53ea06b5b76c54c155a
[2]
http://git.toradex.com/cgit/u-boot-toradex.git/commit/?h=2016.11-toradex-next=32c022da358ae016a84cf1dd9bd558a02f979b1a
--
Stefan
>
> In OpenWrt we usually have kernel, dtbs and U-Boot boot script in boot
> partition with ext4fs, so for some use cases it would be handy to be
> able to replace some of the files in the boot partion, that's why I've
> added write support to the ext4.
>
> I've added `set_blkcnt` environment variable which is needed for every
> `mmc write` command as we need to always specify size in block count.
> This is copy from official Toradex's flashing scripts, so all the
> credits for this work belongs to them.
>
> Currently the rootfs location is passed via mmcblk number and the
> problem with this approach is that the mmcblk number for the boot device
> changes depending on the kernel version and imx6 SoC type. In order to
> avoid such issues, use the UUID method to specify the rootfs location.
>
> I've added new boot sequence, where we first try to load and run boot
> script defined in the new `script` variable, so the boot process could
> be more generic and overridden by the distro. When the boot script isn't
> loaded, it will use the previous boot sequence.
>
> For the recovery purposes and better end user experience I've added boot
> from SDP as the last boot command if every other boot option fails. I
> plan to use SDP as official flashing/recovery procedure in OpenWrt for
> Apalis imx6 boards.
>
> I've copy almost everything from the `f086812a mx6sxsabresd: Use
> PARTUUID to specify the rootfs location` commit, so credits for the rest
> of this patch belongs to Fabio.
>
> Cc: Stefan Agner
> Cc: Max Krummenacher
> Signed-off-by: Petr Štetiar
> ---
> configs/apalis_imx6_defconfig | 2 ++
> include/configs/apalis_imx6.h | 26 +-
> 2 files changed, 23 insertions(+), 5 deletions(-)
>
> Changes since v1:
>
> * Made note about ext4 write support more clear
> * I've removed Kconfig variables and all variables which were
> coupled to the code
> * I've removed the note about backward compatibility from commit message,
> because I've realized, that this changes are not backward compatible,
> because this patch is switching to part UUID, so the distributions would
> need to provide filesystem with part UUID for rootfs.
>
> diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig
> index 133fc1a..279d39f 100644
> --- a/configs/apalis_imx6_defconfig
> +++ b/configs/apalis_imx6_defconfig
> @@ -39,6 +39,7 @@ CONFIG_CMD_DFU=y
> CONFIG_CMD_GPIO=y
> CONFIG_CMD_I2C=y
> CONFIG_CMD_MMC=y
> +CONFIG_CMD_PART=y
> CONFIG_CMD_USB=y
> CONFIG_CMD_USB_SDP=y
> CONFIG_CMD_USB_MASS_STORAGE=y
> @@ -48,6 +49,7 @@ CONFIG_CMD_PING=y
> CONFIG_CMD_BMP=y
> CONFIG_CMD_CACHE=y
> CONFIG_CMD_EXT4=y
> +CONFIG_CMD_EXT4_WRITE=y
> CONFIG_CMD_FAT=y
> CONFIG_CMD_FS_GENERIC=y
> CONFIG_ENV_IS_IN_MMC=y
> diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h
> index 135b3c9..3601891 100644
> --- a/include/configs/apalis_imx6.h
> +++ b/include/configs/apalis_imx6.h
> @@ -142,9 +142,9 @@
> "imx6q-colibri-cam-eval-v3.dtb fat 0 1"
>
> #define EMMC_BOOTCMD \
> - "emmcargs=ip=off root=/dev/mmcblk0p2 rw,noatime rootfstype=ext3 " \
> + "emmcargs=ip=off root=PARTUUID=${uuid} rw,noatime rootfstype=ext3 " \
> "rootwait\0" \
> - "emmcboot=run setup; " \
> + "emmcboot=run setup; run finduuid;" \
> "setenv bootargs ${defargs} ${emmcargs} ${setupargs} " \
> "${vidargs}; echo Booting from internal eMMC chip...; " \
> "run emmcdtbload; l
[U-Boot] [PATCH v1] ARM: vf610: ddrmc: program Dummy DDRBYTE1/2
From: Stefan Agner
The Vybrid reference manual VFXXXRM Rev. 0 10/2016 states in chapter
5.2.6.1 DUMMY PADS (DDR/QuadSPI) that those pads need to be programed
for correct operation of DDR. Assume the default DDR pin configuration
which seems to work well on a Colibri VF50.
Signed-off-by: Stefan Agner
---
arch/arm/include/asm/arch-vf610/iomux-vf610.h | 2 ++
arch/arm/mach-imx/ddrmc-vf610.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index c0eeaa7e7d..01bc2998b8 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -244,6 +244,8 @@ enum {
VF610_PAD_DDR_WE__DDR_WE_B = IOMUX_PAD(0x02d0, 0x02d0, 0,
__NA_, 0, VF610_DDR_PAD_CTRL),
VF610_PAD_DDR_ODT1__DDR_ODT_0 = IOMUX_PAD(0x02d4, 0x02d4, 0,
__NA_, 0, VF610_DDR_PAD_CTRL),
VF610_PAD_DDR_ODT0__DDR_ODT_1 = IOMUX_PAD(0x02d8, 0x02d8, 0,
__NA_, 0, VF610_DDR_PAD_CTRL),
+ VF610_PAD_DDR_DDRBYTE1__DDR_DDRBYTE1= IOMUX_PAD(0x02dc, 0x02dc, 0,
__NA_, 0, VF610_DDR_PAD_CTRL),
+ VF610_PAD_DDR_DDRBYTE2__DDR_DDRBYTE2= IOMUX_PAD(0x02e0, 0x02e0, 0,
__NA_, 0, VF610_DDR_PAD_CTRL),
};
#endif /* __IOMUX_VF610_H__ */
diff --git a/arch/arm/mach-imx/ddrmc-vf610.c b/arch/arm/mach-imx/ddrmc-vf610.c
index 3d7da1c25e..7cc8f5d2c0 100644
--- a/arch/arm/mach-imx/ddrmc-vf610.c
+++ b/arch/arm/mach-imx/ddrmc-vf610.c
@@ -61,6 +61,8 @@ void ddrmc_setup_iomux(const iomux_v3_cfg_t *pads, int
pads_count)
VF610_PAD_DDR_WE__DDR_WE_B,
VF610_PAD_DDR_ODT1__DDR_ODT_0,
VF610_PAD_DDR_ODT0__DDR_ODT_1,
+ VF610_PAD_DDR_DDRBYTE1__DDR_DDRBYTE1,
+ VF610_PAD_DDR_DDRBYTE2__DDR_DDRBYTE2,
VF610_PAD_DDR_RESETB,
};
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] tools: logos: crop Toradex logo slightly
On 14.12.2018 14:20, Tom Rini wrote: > On Fri, Dec 14, 2018 at 02:13:46PM +0100, Stefan Agner wrote: >> Hi Tom, >> >> On 08.12.2018 17:48, Lukasz Majewski wrote: >> > Hi Stefan, >> > >> >> From: Stefan Agner >> >> >> >> The current bitmap is a bit larger than necessary, it has a black >> >> border around the Toradex logo. Crop the logo slightly which safes >> >> some space, useful especially on Colibri VFxx. >> > >> > I can confirm that those changes, as well as >> > >> > [PATCH v1] board: toradex: colibri_vf: unset NFS and LOADS/B >> > [PATCH v1] mtd: nand: raw: allow to disable unneeded ECC layouts >> > [PATCH v1] fs: fat: dynamically allocate memory for temporary buffer >> >> I think all of those go directly into your tree? > > I had filed vybird stuff off to Stefano for some, hopefully correct > reason. The FAT change and logo change are me, yes. I guess the mtd change is rather global... Currently board/toradex is not specifically marked to be maintained by Stefano (we also have Tegra boards). But yeah for Vybrid it probably makes sense. -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/4] ARM: vf610: ddrmc: fix initialization completion detection
Lukasz, Stefano, On 04.12.2018 12:20, Stefan Agner wrote: > On 04.12.2018 11:59, Lukasz Majewski wrote: >> Hi Stefan, >> >>> From: Stefan Agner >>> >>> The CR80 register has multiple interrupt bits, the code is supposed >>> to check bit 8 but instead uses a logical and. In most cases this >>> probably did not affect real operations since at that stage typically >>> none of the other bits are set. >> >> It can exit the loop when any error bit is set (but anyway with broken >> DDR initialization we hang latter anyway). >> >>> >>> Signed-off-by: Stefan Agner >>> Acked-by: Marcel Ziswiler >>> --- >>> >>> arch/arm/include/asm/arch-vf610/imx-regs.h | 3 ++- >>> arch/arm/mach-imx/ddrmc-vf610.c| 3 ++- >>> 2 files changed, 4 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h >>> b/arch/arm/include/asm/arch-vf610/imx-regs.h index >>> b7374bfb8f..f71fbf4e73 100644 --- >>> a/arch/arm/include/asm/arch-vf610/imx-regs.h +++ >>> b/arch/arm/include/asm/arch-vf610/imx-regs.h @@ -200,7 +200,8 @@ >>> #define DDRMC_CR78_Q_FULLNESS(v) (((v) & 0x7) >>> << 24) #define DDRMC_CR78_BUR_ON_FLY_BIT(v) >>> ((v) & 0xf) #define DDRMC_CR79_CTLUPD_AREF(v) >>> (((v) & 0x1) << 24) -#define >>> DDRMC_CR82_INT_MASK 0x1000 >>> +#define DDRMC_CR80_MC_INIT_COMPLETE(1 << 8) >>> +#define DDRMC_CR82_INT_MASK(1 << 28) >> >> When I was working on my code - the checkpatch.pl was complaining about >> (1 << x) code. It was recommended to use BIT(x) instead. >> > > Yeah I noticed that too, but arch/arm/include/asm/arch-vf610/imx-regs.h > does use bit shifting so far. I rated consistency higher than the new > recommendation :-) Do you want me to change the whole file to BIT here? I'd rather prefer to keep it for now. But I think we otherwise are ok with this patch set right? I guess technically patch 4 would not be your realm Stefano, but maybe you can also take it through your tree? -- Stefan > > -- > Stefan > >>> #define DDRMC_CR87_ODT_WR_MAPCS0(v) ((v) << >>> 24) #define DDRMC_CR87_ODT_RD_MAPCS0(v) ((v) >>> << 16) #define DDRMC_CR88_TODTL_CMD(v) >>> (((v) & 0x1f) << 16) diff --git a/arch/arm/mach-imx/ddrmc-vf610.c >>> b/arch/arm/mach-imx/ddrmc-vf610.c index 3d7da1c25e..d121a53898 100644 >>> --- a/arch/arm/mach-imx/ddrmc-vf610.c +++ >>> b/arch/arm/mach-imx/ddrmc-vf610.c @@ -231,6 +231,7 @@ void >>> ddrmc_ctrl_init_ddr3(struct ddr3_jedec_timings const *timings, /* all >>> inits done, start the DDR controller */ >>> writel(DDRMC_CR00_DRAM_CLASS_DDR3 | DDRMC_CR00_START, >cr[0]); >>> - while (!(readl(>cr[80]) && 0x100)) >>> + while (!(readl(>cr[80]) & >>> DDRMC_CR80_MC_INIT_COMPLETE)) udelay(10); >>> + writel(DDRMC_CR80_MC_INIT_COMPLETE, >cr[81]); >>> } >> >> >> >> >> Best regards, >> >> Lukasz Majewski >> >> -- >> >> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk >> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany >> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] tools: logos: crop Toradex logo slightly
Hi Tom,
On 08.12.2018 17:48, Lukasz Majewski wrote:
> Hi Stefan,
>
>> From: Stefan Agner
>>
>> The current bitmap is a bit larger than necessary, it has a black
>> border around the Toradex logo. Crop the logo slightly which safes
>> some space, useful especially on Colibri VFxx.
>
> I can confirm that those changes, as well as
>
> [PATCH v1] board: toradex: colibri_vf: unset NFS and LOADS/B
> [PATCH v1] mtd: nand: raw: allow to disable unneeded ECC layouts
> [PATCH v1] fs: fat: dynamically allocate memory for temporary buffer
I think all of those go directly into your tree?
--
Stefan
>
> Reduce the u-boot.vyb binary for colibri_vf, so it is possible to put
> more device tree description data to vf.dtsi and hence convert some
> vf610 boards to DTS/DM.
>
> Tested-by: Lukasz Majewski
>
> Thanks Stefan :-)
>
>>
>> Signed-off-by: Stefan Agner
>> ---
>>
>> tools/logos/toradex.bmp | Bin 24982 -> 23298 bytes
>> 1 file changed, 0 insertions(+), 0 deletions(-)
>>
>> diff --git a/tools/logos/toradex.bmp b/tools/logos/toradex.bmp
>> index
>> 3e2dcf23358dd46fc7b1bb0dae70d3ba985606ee..8b5cb18e8475b3eda72c9f0e821b2aad17bc1bae
>> 100644 GIT binary patch delta 505
>> zcmYLEO-oxr6rCd>(HDKjZ>@>Jpis10rD|SMpO}a~;ztZ>#n#YvXDMP^LN{G@Ros~Y
>> z7ZzGv2rXT;2fM2V{0-tp-MG+&1*NzVD!qwH2j> zqA&|eIdVc37wR8om8$e!Zz<*l6?djGE9YG(S~;)!9==vfFLUm4-15@m|9r0G
>> zmizeCFm60Pec_#Ey3_){ltsV`(*{R;a?MtR!GlVHyVU}jnm+JXtq3Lc0*@L5*6#@X
>> zZWM?FBG5Uvi_1-;;7M@9V643tT)ro*yB*RRyf5r!m%wIs7(X6Z&}P4>2dpwK^!TCA
>> z#vApR)u#7*|L~|!Y@L=^>|}#ZB|Th=)POrtDVzOa=q<> zTCNWr4?o94(4CgaqoH;%G%TNcHS!SLa%5g3A@fQ%jYNRCF+X@VE-pJ+(CWB8
>> zDGB)@pZ0ionrZ=CrbK@;9R;^%B+8u4K>wYo&*H6Kdi+g)O1ODE*9`if$Qv)_#k`r8
>> Tu-(CC?xpL%4;b52`
>>
>> delta 656
>> zcmXw!ODIHP6vw|?uE!njFhgTzOi3nYyasb;yv8sxo^!iK9tlwv3RzGrG(|QZDZa9j
>> zB?~JZ+1My$i;az@WKD$CWZ~X(xb^k>++`QLBjQaHR3{E^tlYa7
>> z)+w+|)TbsGvzX}UqTV=PO%wUG_^qEgSQ8tBeJ!7_i5^I%n~giXW{@^6RYN>W!v46l
>> zZnTmTwxA%p5v^)Y2)QGZeq#<|oysNFT8OjO0P4s2> zf{70}efyfocU>k(xMn2%=P%%;Ou?--52dJHO4+QS`l^!nSw-~J;C6l%lwr~5F=qKz
>> zmy?(Jy*yd_Wjye{4y`=ZDsxrI1-IXU5n+X*mIJivEJ(i7hzuVMUi3JcX#IAJ8&;aF
>> zsBO3WN1EXwgprVHrN`B`5$D^R(R&|Pe+lV@v!3JlZpi4#JQJUH6Lh5}x
>> zJarfUd2L|nEy26~M84?DfS$fmoLlIpxszBE*3T+sI<+ON_XaQ> WVdOzbgrkvqwA_u-FJz9T1ojITOUl0h
>>
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
