January 2020 - U-Boot

[PATCH] configs: rpi: Set phy auto negotiation
by matthias.bgg＠kernel.org 30 Jan '20

30 Jan '20

From: Matthias Brugger <mbrugger(a)suse.com> Lower timeout for PHY auto negotiation as otherwise we have to wait for far too long. Signed-off-by: Matthias Brugger <mbrugger(a)suse.com> --- include/configs/rpi.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/include/configs/rpi.h b/include/configs/rpi.h index 83e258a6b9..18b817a001 100644 --- a/include/configs/rpi.h +++ b/include/configs/rpi.h @@ -74,6 +74,14 @@ #define CONFIG_TFTP_TSIZE #endif +/* + * RPi4 genet uses the generic phy support, set the + * timeout for auto-negotiation of the PHY in 50 ms units + */ +#ifdef PHYLIB +#define PHY_ANEG_TIMEOUT 20 +#endif + /* Console configuration */ #define CONFIG_SYS_CBSIZE 1024 -- 2.24.1

3 2

Re: [PATCH] riscv: Remove unnecessary instruction
by Rick Chen 30 Jan '20

30 Jan '20

> From: Sean Anderson [mailto:seanga2@gmail.com] > Sent: Tuesday, January 28, 2020 5:40 AM > To: U-Boot Mailing List > Cc: Bin Meng; Lukas Auer; Anup.Patel(a)wdc.com; Rick Jian-Zhi Chen(陳建志) > Subject: [PATCH] riscv: Remove unnecessary instruction > > The add instruction on risc-v can have any three sources and targets, so there is no need for an intermediate mov. > > Signed-off-by: Sean Anderson <seanga2(a)gmail.com> Reviewed-by: Rick Chen <rick(a)andestech.com> > --- > arch/riscv/cpu/start.S | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index 1a55b7d570..365163ad19 100644 > --- a/arch/riscv/cpu/start.S > +++ b/arch/riscv/cpu/start.S > @@ -359,9 +359,8 @@ relocate_secondary_harts: > call_board_init_r: > jal invalidate_icache_all > jal flush_dcache_all > - la t0, board_init_r > - mv t4, t0 /* offset of board_init_r() */ > - add t4, t4, t6 /* real address of board_init_r() */ > + la t0, board_init_r /* offset of board_init_r() */ > + add t4, t0, t6 /* real address of board_init_r() */ > /* > * setup parameters for board_init_r > */ > --

1 0

[PATCH 1/4] rockchip: rk3288: Enable pre console buffer
by Jagan Teki 30 Jan '20

30 Jan '20

Enable pre console buffer for rk3288 platform. This would help to capture the console messages prior to the console being initialised. Enabling this would help to capture all the console messages on video output source like HDMI. So we can find the full console messages of U-Boot proper on HDMI display when enabled it for RK3288 platform boards. Buffer address used for pre console is 0x0f000000 which is ram base plus 240MiB. right now the Allwinner SoC is using similar computation. Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- arch/arm/mach-rockchip/Kconfig | 1 + common/Kconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 2f260a5c5f..ed7514ab75 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -102,6 +102,7 @@ config ROCKCHIP_RK3288 select SUPPORT_SPL select SPL select SUPPORT_TPL + imply PRE_CONSOLE_BUFFER imply ROCKCHIP_COMMON_BOARD imply SPL_ROCKCHIP_COMMON_BOARD imply TPL_CLK diff --git a/common/Kconfig b/common/Kconfig index a7c5ba278a..21d0244050 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -567,6 +567,7 @@ config PRE_CON_BUF_ADDR depends on PRE_CONSOLE_BUFFER default 0x2f000000 if ARCH_SUNXI && MACH_SUN9I default 0x4f000000 if ARCH_SUNXI && !MACH_SUN9I + default 0x0f000000 if ROCKCHIP_RK3288 help This sets the start address of the pre-console buffer. This must be in available memory and is accessed before relocation and -- 2.18.0.321.gffc6fa0e3

2 7

[PATCH] rockchip: px30: sync the main px30 dtsi from mainline
by Heiko Stuebner 30 Jan '20

30 Jan '20

From: Heiko Stuebner <heiko.stuebner(a)theobroma-systems.com> There have been multiple peripherals added to the main px30 dtsi in the Linux kernel since its addition to u-boot. So to make it easier to sync board devicetrees, update the core dtsi from Linux. Signed-off-by: Heiko Stuebner <heiko.stuebner(a)theobroma-systems.com> --- arch/arm/dts/px30.dtsi | 182 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 171 insertions(+), 11 deletions(-) diff --git a/arch/arm/dts/px30.dtsi b/arch/arm/dts/px30.dtsi index 0d2325a77f..b6c79e7ed3 100644 --- a/arch/arm/dts/px30.dtsi +++ b/arch/arm/dts/px30.dtsi @@ -10,6 +10,7 @@ #include <dt-bindings/pinctrl/rockchip.h> #include <dt-bindings/power/px30-power.h> #include <dt-bindings/soc/rockchip,boot-mode.h> +#include <dt-bindings/thermal/thermal.h> / { compatible = "rockchip,px30"; @@ -113,16 +114,11 @@ compatible = "operating-points-v2"; opp-shared; - opp-408000000 { - opp-hz = /bits/ 64 <408000000>; - opp-microvolt = <950000 950000 1350000>; - clock-latency-ns = <40000>; - opp-suspend; - }; opp-600000000 { opp-hz = /bits/ 64 <600000000>; opp-microvolt = <950000 950000 1350000>; clock-latency-ns = <40000>; + opp-suspend; }; opp-816000000 { opp-hz = /bits/ 64 <816000000>; @@ -186,6 +182,55 @@ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>; }; + thermal_zones: thermal-zones { + soc_thermal: soc-thermal { + polling-delay-passive = <20>; + polling-delay = <1000>; + sustainable-power = <750>; + thermal-sensors = <&tsadc 0>; + + trips { + threshold: trip-point-0 { + temperature = <70000>; + hysteresis = <2000>; + type = "passive"; + }; + + target: trip-point-1 { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + + soc_crit: soc-crit { + temperature = <115000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + + cooling-maps { + map0 { + trip = <&target>; + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + contribution = <4096>; + }; + + map1 { + trip = <&target>; + cooling-device = <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + contribution = <4096>; + }; + }; + }; + + gpu_thermal: gpu-thermal { + polling-delay-passive = <100>; /* milliseconds */ + polling-delay = <1000>; /* milliseconds */ + thermal-sensors = <&tsadc 1>; + }; + }; + xin24m: xin24m { compatible = "fixed-clock"; #clock-cells = <0>; @@ -370,6 +415,36 @@ compatible = "rockchip,px30-io-voltage-domain"; status = "disabled"; }; + + lvds: lvds { + compatible = "rockchip,px30-lvds"; + phys = <&dsi_dphy>; + phy-names = "dphy"; + rockchip,grf = <&grf>; + rockchip,output = "lvds"; + status = "disabled"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + lvds_vopb_in: endpoint@0 { + reg = <0>; + remote-endpoint = <&vopb_out_lvds>; + }; + + lvds_vopl_in: endpoint@1 { + reg = <1>; + remote-endpoint = <&vopl_out_lvds>; + }; + }; + }; + }; }; uart1: serial@ff158000 { @@ -650,6 +725,26 @@ }; }; + tsadc: tsadc@ff280000 { + compatible = "rockchip,px30-tsadc"; + reg = <0x0 0xff280000 0x0 0x100>; + interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>; + assigned-clocks = <&cru SCLK_TSADC>; + assigned-clock-rates = <50000>; + clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>; + clock-names = "tsadc", "apb_pclk"; + resets = <&cru SRST_TSADC>; + reset-names = "tsadc-apb"; + rockchip,grf = <&grf>; + rockchip,hw-tshut-temp = <120000>; + pinctrl-names = "init", "default", "sleep"; + pinctrl-0 = <&tsadc_otp_gpio>; + pinctrl-1 = <&tsadc_otp_out>; + pinctrl-2 = <&tsadc_otp_gpio>; + #thermal-sensor-cells = <1>; + status = "disabled"; + }; + saradc: saradc@ff288000 { compatible = "rockchip,px30-saradc", "rockchip,rk3399-saradc"; reg = <0x0 0xff288000 0x0 0x100>; @@ -706,12 +801,48 @@ #reset-cells = <1>; }; + usb2phy_grf: syscon@ff2c0000 { + compatible = "rockchip,px30-usb2phy-grf", "syscon", + "simple-mfd"; + reg = <0x0 0xff2c0000 0x0 0x10000>; + #address-cells = <1>; + #size-cells = <1>; + + u2phy: usb2-phy@100 { + compatible = "rockchip,px30-usb2phy"; + reg = <0x100 0x20>; + clocks = <&pmucru SCLK_USBPHY_REF>; + clock-names = "phyclk"; + #clock-cells = <0>; + assigned-clocks = <&cru USB480M>; + assigned-clock-parents = <&u2phy>; + clock-output-names = "usb480m_phy"; + status = "disabled"; + + u2phy_host: host-port { + #phy-cells = <0>; + interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "linestate"; + status = "disabled"; + }; + + u2phy_otg: otg-port { + #phy-cells = <0>; + interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "otg-bvalid", "otg-id", + "linestate"; + status = "disabled"; + }; + }; + }; + dsi_dphy: phy@ff2e0000 { compatible = "rockchip,px30-dsi-dphy"; reg = <0x0 0xff2e0000 0x0 0x10000>; clocks = <&pmucru SCLK_MIPIDSIPHY_REF>, <&cru PCLK_MIPIDSIPHY>; clock-names = "ref", "pclk"; - #clock-cells = <0>; resets = <&cru SRST_MIPIDSIPHY_P>; reset-names = "apb"; #phy-cells = <0>; @@ -731,6 +862,8 @@ g-rx-fifo-size = <280>; g-tx-fifo-size = <256 128 128 64 32 16>; g-use-dma; + phys = <&u2phy_otg>; + phy-names = "usb2-phy"; power-domains = <&power PX30_PD_USB>; status = "disabled"; }; @@ -741,6 +874,8 @@ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cru HCLK_HOST>; clock-names = "usbhost"; + phys = <&u2phy_host>; + phy-names = "usb"; power-domains = <&power PX30_PD_USB>; status = "disabled"; }; @@ -751,6 +886,8 @@ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cru HCLK_HOST>; clock-names = "usbhost"; + phys = <&u2phy_host>; + phy-names = "usb"; power-domains = <&power PX30_PD_USB>; status = "disabled"; }; @@ -823,17 +960,30 @@ status = "disabled"; }; + gpu: gpu@ff400000 { + compatible = "rockchip,px30-mali", "arm,mali-bifrost"; + reg = <0x0 0xff400000 0x0 0x4000>; + interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "job", "mmu", "gpu"; + clocks = <&cru SCLK_GPU>; + #cooling-cells = <2>; + power-domains = <&power PX30_PD_GPU>; + status = "disabled"; + }; + dsi: dsi@ff450000 { compatible = "rockchip,px30-mipi-dsi"; reg = <0x0 0xff450000 0x0 0x10000>; interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cru PCLK_MIPI_DSI>, <&dsi_dphy>; - clock-names = "pclk", "pll"; - resets = <&cru SRST_MIPIDSI_HOST_P>; - reset-names = "apb"; + clocks = <&cru PCLK_MIPI_DSI>; + clock-names = "pclk"; phys = <&dsi_dphy>; phy-names = "dphy"; power-domains = <&power PX30_PD_VO>; + resets = <&cru SRST_MIPIDSI_HOST_P>; + reset-names = "apb"; rockchip,grf = <&grf>; #address-cells = <1>; #size-cells = <0>; @@ -883,6 +1033,11 @@ reg = <0>; remote-endpoint = <&dsi_in_vopb>; }; + + vopb_out_lvds: endpoint@1 { + reg = <1>; + remote-endpoint = <&lvds_vopb_in>; + }; }; }; @@ -920,6 +1075,11 @@ reg = <0>; remote-endpoint = <&dsi_in_vopl>; }; + + vopl_out_lvds: endpoint@1 { + reg = <1>; + remote-endpoint = <&lvds_vopl_in>; + }; }; }; -- 2.24.1

2 1

[PATCH] rockchip: boot_mode: find the saradc device name
by Hugh Cole-Baker 30 Jan '20

30 Jan '20

adc_channel_single_shot() requires the full device name e.g. "saradc@ff100000", which differs between Rockchip SoC's, but they all share the prefix "saradc"; find the ADC device with this name prefix and use its full name. Signed-off-by: Hugh Cole-Baker <sigmaris(a)gmail.com> --- I previously sent this on Jan. 11 as an RFC patch, since there were no comments on it previously I guess it can just be submitted as a patch as-is. arch/arm/mach-rockchip/boot_mode.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/boot_mode.c b/arch/arm/mach-rockchip/boot_mode.c index 08f80bd91a..7598fe4c43 100644 --- a/arch/arm/mach-rockchip/boot_mode.c +++ b/arch/arm/mach-rockchip/boot_mode.c @@ -7,6 +7,8 @@ #include <adc.h> #include <asm/io.h> #include <asm/arch-rockchip/boot_mode.h> +#include <dm/device.h> +#include <dm/uclass.h> #if (CONFIG_ROCKCHIP_BOOT_MODE_REG == 0) @@ -35,8 +37,26 @@ void set_back_to_bootrom_dnl_flag(void) __weak int rockchip_dnl_key_pressed(void) { unsigned int val; + struct udevice *dev; + struct uclass *uc; + int ret; - if (adc_channel_single_shot("saradc", 1, &val)) { + ret = uclass_get(UCLASS_ADC, &uc); + if (ret) + return false; + + ret = -ENODEV; + uclass_foreach_dev(dev, uc) { + if (!strncmp(dev->name, "saradc", 6)) { + ret = adc_channel_single_shot(dev->name, 1, &val); + break; + } + } + + if (ret == -ENODEV) { + pr_warn("%s: no saradc device found\n", __func__); + return false; + } else if (ret) { pr_err("%s: adc_channel_single_shot fail!\n", __func__); return false; } -- 2.17.2 (Apple Git-113)

2 1

Pull request: u-boot-rockchip-20200120
by Kever Yang 30 Jan '20

30 Jan '20

Hi Tom, Please pull the rockchip updates: - Support SPI boot and redundant boot for rk3399 - Support binman for rockchip platform - Update ram driver and add ddr4 support for rk3328 Travis: https://travis-ci.org/keveryang/u-boot/builds/639069624 Thanks, - Kever The following changes since commit d7bb6aceb2e99a832efbb96f9bf480bf95602192: Merge tag 'mmc-1-16-2020' of https://gitlab.denx.de/u-boot/custodians/u-boot-mmc (2020-01-16 13:20:51 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git tags/u-boot-rockchip-20200120 for you to fetch changes up to f9a0f5b83e9eabf4d064c7ec46fe2f9b9b694b4e: configs: firefly-rk3399: Enable CONFIG_MISC_INIT_R and ROCKCHIP_EFUSE (2020-01-19 15:19:03 +0800) ---------------------------------------------------------------- Jagan Teki (21): distro_bootcmd: Add SF support rockchip: Include SF on distrocmd devices rk3399: Add boot flash script offet, size rk3399: Check MMC env while defining it env: kconfig: Restrict rockchip env for MMC env: Enable SPI flash env for rockchip rockchip: dts: Sync ROC-RK3399-PC changes from Linux roc-pc-rk3399: Enable SPI Flash rockpro-rk3399: Enable SPI Flash rockchip: Add cpu-info rockchip: rk3399: Enable DISPLAY_CPUINFO arm: rockchip: Add common cru.h rockchip: Add common reset cause rockchip: rk3399: Add bootcount support Makefile: Add rockchip image type Makefile: rockchip: Suffix platform type with tpl name Makefile: rockchip: Support SPL-alone mkimage arm: dts: rk3036: Add rk3036-u-boot.dtsi arm: dts: rk3188: Add rk3188-u-boot.dtsi rockchip: Add Single boot image (with binman, pad_cat) doc: boards: Add rockchip documentation Kever Yang (3): ram: rk3328: only do data traning for cs0 rockchip: px30: remove CONFIG_OPTEE support rockchip: rk3308: add alias for emmc/sdmmc Mark Kettenis (1): configs: firefly-rk3399: Enable CONFIG_MISC_INIT_R and ROCKCHIP_EFUSE Thomas Hebb (1): ram: rk3399: don't assume phy_io_config() uses real regs YouMin Chen (2): ram: rk3328: add support ddr4 init ram: rk3328: update lpddr3 setting Makefile | 36 +- arch/arm/Kconfig | 1 + arch/arm/dts/rk3036-sdk-u-boot.dtsi | 2 + arch/arm/dts/rk3036-u-boot.dtsi | 6 + arch/arm/dts/rk3188-radxarock-u-boot.dtsi | 2 + arch/arm/dts/rk3188-u-boot.dtsi | 6 + arch/arm/dts/rk3288-u-boot.dtsi | 2 + arch/arm/dts/rk3308-u-boot.dtsi | 7 + arch/arm/dts/rk3328-sdram-ddr4-666.dtsi | 216 +++++++ arch/arm/dts/rk3328-sdram-lpddr3-666.dtsi | 8 +- arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 4 + arch/arm/dts/rk3399-roc-pc.dts | 673 +------------------- arch/arm/dts/rk3399-roc-pc.dtsi | 813 ++++++++++++++++++++++++ arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 + arch/arm/dts/rockchip-u-boot.dtsi | 21 + arch/arm/include/asm/arch-rockchip/clock.h | 4 +- arch/arm/include/asm/arch-rockchip/cru.h | 30 + arch/arm/include/asm/arch-rockchip/cru_rk3288.h | 20 +- arch/arm/include/asm/arch-rockchip/cru_rk3399.h | 11 +- arch/arm/mach-rockchip/Kconfig | 2 + arch/arm/mach-rockchip/Makefile | 1 + arch/arm/mach-rockchip/cpu-info.c | 65 ++ arch/arm/mach-rockchip/rk3288/clk_rk3288.c | 2 +- arch/arm/mach-rockchip/rk3288/rk3288.c | 41 +- arch/arm/mach-rockchip/rk3399/Kconfig | 10 + arch/arm/mach-rockchip/rk3399/clk_rk3399.c | 2 +- arch/arm/mach-rockchip/rk3399/rk3399.c | 2 +- configs/evb-px30_defconfig | 1 - configs/evb-rk3288_defconfig | 1 - configs/evb-rk3399_defconfig | 1 - configs/ficus-rk3399_defconfig | 1 - configs/firefly-px30_defconfig | 1 - configs/firefly-rk3288_defconfig | 1 - configs/firefly-rk3399_defconfig | 4 +- configs/khadas-edge-captain-rk3399_defconfig | 1 - configs/khadas-edge-rk3399_defconfig | 1 - configs/khadas-edge-v-rk3399_defconfig | 1 - configs/leez-rk3399_defconfig | 1 - configs/miqi-rk3288_defconfig | 1 - configs/nanopc-t4-rk3399_defconfig | 1 - configs/nanopi-m4-rk3399_defconfig | 1 - configs/nanopi-neo4-rk3399_defconfig | 1 - configs/orangepi-rk3399_defconfig | 1 - configs/phycore-rk3288_defconfig | 3 - configs/popmetal-rk3288_defconfig | 1 - configs/puma-rk3399_defconfig | 1 - configs/roc-pc-rk3399_defconfig | 3 +- configs/rock-pi-4-rk3399_defconfig | 1 - configs/rock960-rk3399_defconfig | 1 - configs/rockpro64-rk3399_defconfig | 3 +- configs/tinker-rk3288_defconfig | 1 - configs/tinker-s-rk3288_defconfig | 1 - configs/vyasa-rk3288_defconfig | 1 - doc/board/rockchip/index.rst | 10 + doc/board/rockchip/rockchip.rst | 130 ++++ drivers/clk/rockchip/clk_rk3288.c | 42 +- drivers/clk/rockchip/clk_rk3399.c | 36 +- drivers/ram/rockchip/sdram_rk3288.c | 10 +- drivers/ram/rockchip/sdram_rk3328.c | 10 +- drivers/ram/rockchip/sdram_rk3399.c | 16 +- drivers/video/rockchip/rk3288_mipi.c | 2 +- drivers/video/rockchip/rk3399_mipi.c | 2 +- drivers/video/rockchip/rk_mipi.c | 2 +- env/Kconfig | 8 +- include/config_distro_bootcmd.h | 35 + include/configs/evb_rk3399.h | 4 +- include/configs/rk3399_common.h | 7 +- include/configs/rockchip-common.h | 10 + 68 files changed, 1509 insertions(+), 841 deletions(-) create mode 100644 arch/arm/dts/rk3036-u-boot.dtsi create mode 100644 arch/arm/dts/rk3188-u-boot.dtsi create mode 100644 arch/arm/dts/rk3328-sdram-ddr4-666.dtsi create mode 100644 arch/arm/dts/rk3399-roc-pc.dtsi create mode 100644 arch/arm/dts/rockchip-u-boot.dtsi create mode 100644 arch/arm/include/asm/arch-rockchip/cru.h create mode 100644 arch/arm/mach-rockchip/cpu-info.c create mode 100644 doc/board/rockchip/index.rst create mode 100644 doc/board/rockchip/rockchip.rst

4 6

DWC4 ethernet in U-Boot receiving it's own traffic
by Marek Vasut 30 Jan '20

30 Jan '20

Hi, are you aware of any issues with the DWC4 ethernet in U-Boot? I recently ran into oddity where the MAC receives it's own packets upon replying to ARP request. Test case is as follows: - Assume host PC with IP 192.168.1.1/24 , STM32MP1 board with IP 192.168.1.2/24 - Assume TFTP server has 64MiB file called 64m full of zeroes ($ dd if=/dev/zero of=/tftpboot/64m bs=64M count=1) - Run the following in U-Boot: $ setenv ipaddr 192.168.1.2 $ setenv netmask 255.255.255.0 $ setenv serverip 192.168.1.1 $ tftp 192.168.1.1:64m - In parallel, during the TFTP transfer, run the following on PC: $ arping -c 1 192.168.1.2 Observe 5-second delay while the MAC is trying to recover or complete failure of the transfer. What happens is that the U-Boot is in netloop, receives the ARP request and sends ARP reply. So far so good. However, the DWC4 receives that ARP reply too for reason that is not clear yet (the packet which arrives in eqos_recv() has source MAC equal to the board MAC address). Note that this is modeling a real world scenario where the host PC sends ARP request to the board during a TFTP transfer. The same problem does happen then. Can you try replicating this and see whether this is happening for you too? -- Best regards, Marek Vasut

3 4

[PATCH v3 16/20] tools: binman: add etype file for u-boot-lzma-img
by Weijie Gao 30 Jan '20

30 Jan '20

This patch adds etype u-boot-lzma-img for binman. README.entries is also updated. Signed-off-by: Weijie Gao <weijie.gao(a)mediatek.com> --- Changes since v2: none --- tools/binman/README.entries | 15 ++++++++++++++ tools/binman/etype/u_boot_lzma_img.py | 28 +++++++++++++++++++++++++++ 2 files changed, 43 insertions(+) create mode 100644 tools/binman/etype/u_boot_lzma_img.py diff --git a/tools/binman/README.entries b/tools/binman/README.entries index 6a816bba6b..0aea9b8f6d 100644 --- a/tools/binman/README.entries +++ b/tools/binman/README.entries @@ -747,6 +747,21 @@ applications. +Entry: u-boot-lzma-img: U-Boot legacy image with contents compressed by LZMA +---------------------------------------------------------------------------- + +Properties / Entry arguments: + - filename: Filename of u-boot-lzma.img (default 'u-boot-lzma.img') + +This is the U-Boot binary as a packaged image, in legacy format. It has a +header which allows it to be loaded at the correct address for execution. +Its contents are compressed by LZMA. + +You should use FIT (Flat Image Tree) instead of the legacy image for new +applications. + + + Entry: u-boot-nodtb: U-Boot flat binary without device tree appended -------------------------------------------------------------------- diff --git a/tools/binman/etype/u_boot_lzma_img.py b/tools/binman/etype/u_boot_lzma_img.py new file mode 100644 index 0000000000..966d6a46da --- /dev/null +++ b/tools/binman/etype/u_boot_lzma_img.py @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: GPL-2.0 +# Copyright (C) 2020 MediaTek Inc. All Rights Reserved. +# Author: Weijie Gao <weijie.gao(a)mediatek.com> +# +# Entry-type module for U-Boot legacy image with contents compressed by LZMA +# + +from entry import Entry +from blob import Entry_blob + +class Entry_u_boot_lzma_img(Entry_blob): + """U-Boot legacy image with contents compressed by LZMA + + Properties / Entry arguments: + - filename: Filename of u-boot-lzma.img (default 'u-boot-lzma.img') + + This is the U-Boot binary as a packaged image, in legacy format. It has a + header which allows it to be loaded at the correct address for execution. + Its contents are compressed by LZMA. + + You should use FIT (Flat Image Tree) instead of the legacy image for new + applications. + """ + def __init__(self, section, etype, node): + Entry_blob.__init__(self, section, etype, node) + + def GetDefaultFilename(self): + return 'u-boot-lzma.img' -- 2.17.1

3 2

[PATCH 0/4] Add Cortina Access basic DM drivers
by Alex Nemirovsky 30 Jan '20

30 Jan '20

This series contains a set of basic DM drivers compatible with Cortina Access ARM and MIPS series of SoCs. Jason Li (4): gpio: do not include <asm/arch/gpio.h> for Cortina CAxxxx SoCs gpio: cortina_gpio: add DM_GPIO driver for CAxxxx SoCs watchdog: cortina_wdt: add support for HW WDT on CAxxxx SoCs serial: serial_cortina: add UART DM driver for CAxxxx SoCs MAINTAINERS | 8 +++ arch/arm/include/asm/gpio.h | 2 +- drivers/gpio/Kconfig | 8 +++ drivers/gpio/Makefile | 1 + drivers/gpio/cortina_gpio.c | 113 +++++++++++++++++++++++++++++++ drivers/serial/Kconfig | 7 ++ drivers/serial/Makefile | 2 +- drivers/serial/serial_cortina.c | 129 +++++++++++++++++++++++++++++++++++ drivers/serial/serial_cortina.h | 83 +++++++++++++++++++++++ drivers/watchdog/Kconfig | 8 +++ drivers/watchdog/Makefile | 1 + drivers/watchdog/cortina_wdt.c | 144 ++++++++++++++++++++++++++++++++++++++++ 12 files changed, 504 insertions(+), 2 deletions(-) create mode 100644 drivers/gpio/cortina_gpio.c create mode 100644 drivers/serial/serial_cortina.c create mode 100644 drivers/serial/serial_cortina.h create mode 100644 drivers/watchdog/cortina_wdt.c -- 2.7.4

6 18

verified boot: semantics of multiple required keys
by Rasmus Villemoes 30 Jan '20

30 Jan '20

Hi I'm wondering a bit about the semantics of having multiple keys with the 'required = "conf"' property. Currently, the fit image (or rather the chosen configuration) must be signed by all such keys. I assume this is for the case where multiple parties (vendor, subvendor, customer?) all have to sign a given image (however they then manage to ensure that they know what they're signing). However, our use case is a little different. The board we want to do verified boot on doesn't have any hardware support for anchoring the root of trust (no TPM or similar), so we will be relying on creating an SPL that will live in read-only storage after production. We'd like to create 4 key pairs upfront, initially using key-0 for all signing, and keeping the private parts of key-{1,2,3} stored safely offline somewhere. The SPL will be equipped with the public part of all four keys in its control dtb. When key-0 inevitably leaks (or we suspect that it might have leaked), we will start using key-1. So we need the SPL to accept any image signed with at least one of those 'required = "conf"' keys. [Moreover, the board does have some OTP fuses, so we'd also like to implement logic to check those fuses before actually using key-$n - and if the SPL sees and verifies an image signed with key-N, it should burn the fuses corresponding to keys 0..N-1]. Implementation-wise, I'm thinking of something like signature { required-mode = "one"; // or "all", the default if not present key-0 { required = "conf"; key-index = <0>; .... } And then inside the loop, there would be something like if (board_key_revoked(key_index)) continue; and before returning, another board hook would be called board_keys_used_for_verification(int *index, int count) Does this make any sense? I'm not at all sure about the semantics of say 'require-mode = "all"' combined with all keys having been revoked - but I don't think a board that uses 'required-mode = "all"' would implement board_key_revoked() anyway. Rasmus

2 1