September 2019 - U-Boot

[U-Boot] [RFC PATCH 0/3] collect entropy, populate /chosen/rng-seed
by Rasmus Villemoes 19 Sep '19

19 Sep '19

[This is very much an early Request For Comments - it builds and shows a sketch of what I have in mind, but has not really been tested. The rest of the cover letter is copied from patch 3.] A recurring theme on LKML is the boot process deadlocking due to some process blocking waiting for random numbers, while the kernel's Cryptographic Random Number Generator (crng) is not initalized yet, but that very blocking means no activity happens that would generate the entropy necessary to finalize seeding the crng. This is not a problem on boards that have a good hwrng (when the kernel is configured to trust it), whether in the CPU or in a TPM or elsewhere. However, that's far from all boards out there. Moreover, when booting with an initrd, all the "disk activity" that would otherwise generate some timing variances has already been done by U-boot. Hence it makes sense to try to collect that entropy in U-boot and pass it on to the kernel. On the kernel side, support for that has just landed in master (commit 428826f5358c "fdt: add support for rng-seed"). By itself, this does not help with the initialization of the crng, since the kernel only considers the rng-seed "trustworthy" if CONFIG_RANDOM_TRUST_BOOTLOADER is set (it is always fed into the crng, but entropy is only accounted when that config option is set). This adds some basic infrastructure for collecting entropy in U-boot, and then it's up to the BSP developer to decide if CONFIG_RANDOM_TRUST_BOOTLOADER should be enabled in the kernel. If this is accepted, I think we should add entropy() calls before and after most disk and network activities. Moreover, at least some boards seem to have a rather reliable source of randomness in the contents of RAM after a cold boot [*], so I imagine exposing the entropy_mix() either via a command "entropy <addr> <len>" that can be run during a boot script, or perhaps to be done automatically (and as early as possible to reduce risk of "tainting") via some CONFIG_ENTROPY_RAM_{ADDR,LEN}. There's probably good sources of entropy to be had from the SPL phase, but I couldn't find a good way of passing that on other than by putting the sha256_context inside global_data, which would bloat that by over 100 bytes. [*] Looking at a slightly arbitrary place in the middle of physical memory I got these 40d07670: 34081000 400a8020 00002040 20024400 ...4 ..@@ ...D. 40d07670: 343c1000 640a9120 00036040 6006e400 ..<4 ..d@`.....` 40d07670: 353c1040 600a9120 00026041 6246e400 @.<5 ..`A`....Fb 40d07670: 34281000 600a9100 00026040 2046e400 ..(4...`@`....F So some bits are always the same, but there's quite a few that flip randomly between boots - so mixing in a MB or two seems that it should provide plenty of real entropy. Rasmus Villemoes (3): u-boot/sha256.h: add SHA256_INIT macro u-boot/sha256.h: include linux/types.h add infrastructure for collecting entropy common/fdt_support.c | 12 ++++++++ include/common.h | 3 ++ include/entropy.h | 42 +++++++++++++++++++++++++++ include/u-boot/sha256.h | 13 +++++++++ lib/Kconfig | 10 +++++++ lib/Makefile | 1 + lib/entropy.c | 63 +++++++++++++++++++++++++++++++++++++++++ 7 files changed, 144 insertions(+) create mode 100644 include/entropy.h create mode 100644 lib/entropy.c -- 2.20.1

1 3

[U-Boot] [PATCH v2 00/28] Add and update drivers for MediaTek MT76x8 SoCs
by Weijie Gao 18 Sep '19

18 Sep '19

This patch series have the following changes: - Add pinctrl(both pinmux and pinconf) driver, reset controller driver and clock driver for mt7628. - Add mt7628 platform to mtk-sd driver. - Modify mt7628's ethernet & usb phy driver to take advantages from the new drivers. - Update mt7621-spi driver with a new transfer method. - Enable fifo, disable flow control, and enable non-DM implementation for mtk hsuart driver. - Enanble the new drivers for currently existed mt7628 boards. Changes of v2: - Change clock gateing driver to a more 'generic' driver which supports output clock rates of CPU/SYS_BUS/peripherals. - mt7621-spi now uses accurate sys_freq from clock driver. - Make PHY link detection optional via DT. - Select essential drivers in Kconfig instead of setting in defconfig files. Weijie Gao (28): serial: serial_mtk: enable FIFO and disable flow control serial: serial_mtk: add non-DM version for SPL dts: mtmips: move uart property clock-frequency into mt7628an.dtsi dts: mtmips: enable high-speed UART support for mt7628 clk: add clock driver for MediaTek MT76x8 platform dts: mtmips: add clock node for mt7628 spi: mt7621-spi: use clock frequency from clk driver spi: mt7621-spi: remove data cache and rewrite its xfer function spi: mt7621-spi: restore default register value after each xfer pinctrl: add support for MediaTek MT7628 dts: mtmips: add pinctrl node for mt7628 dts: mtmips: add default pinctrl for uart nodes reset: add reset controller driver for MediaTek MIPS platform dts: mtmips: update reset controller node for mt7628 phy: mt76x8-usb-phy: add slew rate calibration and remove non-mt7628 part net: mt7628-eth: remove hardcoded gpio settings and regmap-based phy reset net: mt7628-eth: make phy link up detection optional via DT net: mt7628-eth: free rx descriptor on receiving failure net: mt7628-eth: add support to isolate LAN/WAN ports dts: mtmips: enable eth port0 led and link poll functions for all boards mmc: mtk-sd: add support for MediaTek MT7620/MT7628 SoCs mmc: mtk-sd: add a dts property cd-active-high for builtin-cd mode dts: mtmips: add mmc related nodes for mt7628an.dtsi dts: mtmips: add default pinctrl for gardena-smart-gateway-mt7688 dts: mtmips: add default pinctrl to eth nodes for all boards mips: mtmips: change baudrate table for all boards mips: mtmips: select essential drivers in Kconfig configs: mtmips: remove configs which are selected in Kconfig or useless arch/mips/Kconfig | 6 + .../mips/dts/gardena-smart-gateway-mt7688.dts | 19 +- arch/mips/dts/linkit-smart-7688.dts | 16 +- arch/mips/dts/mt7628a.dtsi | 246 +++++++- arch/mips/mach-mtmips/Kconfig | 2 + ...gardena-smart-gateway-mt7688-ram_defconfig | 7 - .../gardena-smart-gateway-mt7688_defconfig | 7 - configs/linkit-smart-7688-ram_defconfig | 7 - configs/linkit-smart-7688_defconfig | 7 - drivers/clk/Makefile | 1 + drivers/clk/mtmips/Makefile | 3 + drivers/clk/mtmips/clk-mt7628.c | 158 +++++ drivers/mmc/Kconfig | 2 +- drivers/mmc/mtk-sd.c | 32 +- drivers/net/Kconfig | 1 + drivers/net/mt7628-eth.c | 135 ++-- drivers/phy/Kconfig | 2 + drivers/phy/mt76x8-usb-phy.c | 225 +++++-- drivers/pinctrl/Kconfig | 1 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/mtmips/Kconfig | 13 + drivers/pinctrl/mtmips/Makefile | 7 + drivers/pinctrl/mtmips/pinctrl-mt7628.c | 585 ++++++++++++++++++ .../pinctrl/mtmips/pinctrl-mtmips-common.c | 87 +++ .../pinctrl/mtmips/pinctrl-mtmips-common.h | 53 ++ drivers/reset/Kconfig | 7 + drivers/reset/Makefile | 1 + drivers/reset/reset-mtmips.c | 82 +++ drivers/serial/serial.c | 2 + drivers/serial/serial_mtk.c | 223 ++++++- drivers/spi/mt7621_spi.c | 247 ++++---- .../configs/gardena-smart-gateway-mt7688.h | 2 +- include/configs/linkit-smart-7688.h | 2 +- include/dt-bindings/clock/mt7628-clk.h | 37 ++ include/dt-bindings/reset/mt7628-reset.h | 36 ++ 35 files changed, 1933 insertions(+), 329 deletions(-) create mode 100644 drivers/clk/mtmips/Makefile create mode 100644 drivers/clk/mtmips/clk-mt7628.c create mode 100644 drivers/pinctrl/mtmips/Kconfig create mode 100644 drivers/pinctrl/mtmips/Makefile create mode 100644 drivers/pinctrl/mtmips/pinctrl-mt7628.c create mode 100644 drivers/pinctrl/mtmips/pinctrl-mtmips-common.c create mode 100644 drivers/pinctrl/mtmips/pinctrl-mtmips-common.h create mode 100644 drivers/reset/reset-mtmips.c create mode 100644 include/dt-bindings/clock/mt7628-clk.h create mode 100644 include/dt-bindings/reset/mt7628-reset.h -- 2.17.1

2 31

[U-Boot] [ANN] U-Boot v2019.10-rc3 released
by Tom Rini 18 Sep '19

18 Sep '19

Hey all, It's release day and here's v2019.10-rc3. We're well into what should be the stabilization period at this point. Going forward I am hoping for PRs that are bug fixes / regression fixes, Kconfig migrations or very self contained new boards and similar. If you have a series is "big" but doesn't quite fit into that list, please let me know with a patchwork link to the series in reply here. I'd like to get a handle on how much stuff like that it outstanding so that I can get an idea on what I should try and do about a "next" branch more often than I have and what rules might apply to it. In terms of a changelog, git log --merges v2019.10-rc2..v2019.10-rc3 continues to look pretty good but the content there varies based on what was given to me in the PR. So please, the more details in the request the better! I'm still planning on doing -rc4 on September 9th and -rc5 on September 23rd with the release scheduled on October 7th. Thanks all! -- Tom

3 5

[U-Boot] [PATCH V2] [RFC] usb: storage: Limit transfer size to 120 kiB
by Marek Vasut 18 Sep '19

18 Sep '19

Due to constant influx of more and more weird and broken USB sticks, do as Linux does in commit 779b457f66e10de3471479373463b27fd308dc85 usb: storage: scsiglue: further describe our 240 sector limit Just so we have some sort of documentation as to why we limit our Mass Storage transfers to 240 sectors, let's update the comment to make clearer that devices were found that would choke with larger transfers. While at that, also make sure to clarify that other operating systems have similar, albeit different, limits on mass storage transfers. And reduce the maximum transfer length of USB storage to 120 kiB. Signed-off-by: Marek Vasut <marek.vasut+renesas(a)gmail.com> Cc: Bin Meng <bmeng.cn(a)gmail.com> Cc: Simon Glass <sjg(a)chromium.org> --- V2: Reshuffle the code a bit, always clamp the transfer size to 240 blocks --- common/usb_storage.c | 43 ++++++++++++++++++++++--------------------- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/common/usb_storage.c b/common/usb_storage.c index 8c889bb1a6..e1b539a082 100644 --- a/common/usb_storage.c +++ b/common/usb_storage.c @@ -938,31 +938,32 @@ do_retry: static void usb_stor_set_max_xfer_blk(struct usb_device *udev, struct us_data *us) { - unsigned short blk; - size_t __maybe_unused size; - int __maybe_unused ret; - -#if !CONFIG_IS_ENABLED(DM_USB) -#ifdef CONFIG_USB_EHCI_HCD /* - * The U-Boot EHCI driver can handle any transfer length as long as - * there is enough free heap space left, but the SCSI READ(10) and - * WRITE(10) commands are limited to 65535 blocks. + * Limit the total size of a transfer to 120 KB. + * + * Some devices are known to choke with anything larger. It seems like + * the problem stems from the fact that original IDE controllers had + * only an 8-bit register to hold the number of sectors in one transfer + * and even those couldn't handle a full 256 sectors. + * + * Because we want to make sure we interoperate with as many devices as + * possible, we will maintain a 240 sector transfer size limit for USB + * Mass Storage devices. + * + * Tests show that other operating have similar limits with Microsoft + * Windows 7 limiting transfers to 128 sectors for both USB2 and USB3 + * and Apple Mac OS X 10.11 limiting transfers to 256 sectors for USB2 + * and 2048 for USB3 devices. */ - blk = USHRT_MAX; -#else - blk = 20; -#endif -#else + unsigned short blk = 240; + +#if CONFIG_IS_ENABLED(DM_USB) + size_t size; + int ret; + ret = usb_get_max_xfer_size(udev, (size_t *)&size); - if (ret < 0) { - /* unimplemented, let's use default 20 */ - blk = 20; - } else { - if (size > USHRT_MAX * 512) - size = USHRT_MAX * 512; + if ((ret >= 0) && (size < 240 * 512)) blk = size / 512; - } #endif us->max_xfer_blk = blk; -- 2.23.0.rc1

2 4

[U-Boot] Verified boot interrogation
by Roger Clark 18 Sep '19

18 Sep '19

Hello everyone, After studying the verified boot feature I have some interrogations. If my understanding is correct the procedure should be the following : 1) Generate private keys and certificate 2) Generate a uboot and a dts file to describe the key 3) Generate a kernel/dtb/ramdisk and an its file to describe the fit image (files + conf + signatures) 4) Signature of the fit image and creation of a u-boot dtb file containing the public key 5) Insertion of the uboot dtb file in the uboot binary A am I correct so far ? My question is why the step 4 is not divided in two steps ? I don't understand why the public key generation needs the fit image as input.This creates a link between uboot and the kernel and I don't see how I can flash a new kernel without re-flashing a linked uboot. The thing is I don't want to update uboot as often as the kernel. Sorry if this is a stupid question.. Thanks !

1 0

[U-Boot] [PATCH 01/14] dfu: cosmetic: cleanup sf to avoid checkpatch error
by Patrick Delaunay 18 Sep '19

18 Sep '19

Signed-off-by: Patrick Delaunay <patrick.delaunay(a)st.com> --- drivers/dfu/dfu.c | 7 ++++--- drivers/dfu/dfu_sf.c | 4 ++-- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c index d2b67b18cf..e9db7f8d66 100644 --- a/drivers/dfu/dfu.c +++ b/drivers/dfu/dfu.c @@ -478,14 +478,15 @@ int dfu_config_entities(char *env, char *interface, char *devstr) const char *dfu_get_dev_type(enum dfu_device_type t) { - const char *dev_t[] = {NULL, "eMMC", "OneNAND", "NAND", "RAM", "SF" }; + const char *const dev_t[] = {NULL, "eMMC", "OneNAND", "NAND", "RAM", + "SF"}; return dev_t[t]; } const char *dfu_get_layout(enum dfu_layout l) { - const char *dfu_layout[] = {NULL, "RAW_ADDR", "FAT", "EXT2", - "EXT3", "EXT4", "RAM_ADDR" }; + const char *const dfu_layout[] = {NULL, "RAW_ADDR", "FAT", "EXT2", + "EXT3", "EXT4", "RAM_ADDR" }; return dfu_layout[l]; } diff --git a/drivers/dfu/dfu_sf.c b/drivers/dfu/dfu_sf.c index 066e7670d1..b78fcfd3a1 100644 --- a/drivers/dfu/dfu_sf.c +++ b/drivers/dfu/dfu_sf.c @@ -19,7 +19,7 @@ static int dfu_get_medium_size_sf(struct dfu_entity *dfu, u64 *size) } static int dfu_read_medium_sf(struct dfu_entity *dfu, u64 offset, void *buf, - long *len) + long *len) { return spi_flash_read(dfu->data.sf.dev, dfu->data.sf.start + offset, *len, buf); @@ -32,7 +32,7 @@ static u64 find_sector(struct dfu_entity *dfu, u64 start, u64 offset) } static int dfu_write_medium_sf(struct dfu_entity *dfu, - u64 offset, void *buf, long *len) + u64 offset, void *buf, long *len) { int ret; -- 2.17.1

3 26

[U-Boot] fpga spi on uboot driver
by jérémy alcim 18 Sep '19

18 Sep '19

hi, I search how to make a multiplexing for my unstandar spi on my fpga. why ? because my spi register are 1 slot more. this slot is a sublayer for non standard connection data bus selector. I have 1 card connected at 4 card by my spi implementation. i want to use my spi chip on the fpga with the standard <sspi> command. Then for that i make a spi driver. on this driver i need to make 4 udevice (for only 1 spi chip on device-tree). why ? because i want set my registre slot for select the good data bus, then for select the good card connected on him. I have make a simple command who work, but its not approved by ma boss... He want use the standard interface with the unstandard spi hardware. I search find 2 week... but not find how to do. Are you an idea for make 4 spi on uboot with only 1 on device-tree ? Actually i write 4 time the same device on dts... Then i run 4 time the driver... its not good... Thanks for reading with my bad english ^^.

1 0

[U-Boot] [PATCH] armv8: ls1028a: add more personalities support
by Yuantian Tang 18 Sep '19

18 Sep '19

Add LS1027A, LS1018A and LS1017A personalities support to LS1028A processor soc family. LS1028A processor is the prime personality of LS1028A soc family. LS1027A processor is a lower funtionality version of QorIQ LS1028A which does not support the multimedia subsystems, such as LCD controller, GPU, and eDP PHY. The QorIQ LS1018A and LS1017A are low power versions of the QorIQ LS1028A and LS1027A processors, respectively which integrate single 64-bit Arm A72 core. Signed-off-by: Tang Yuantian <andy.tang(a)nxp.com> --- arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 3 +++ arch/arm/include/asm/arch-fsl-layerscape/soc.h | 3 +++ 2 files changed, 6 insertions(+) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c index 3e2a24fe80..dee96afe2d 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c @@ -58,6 +58,9 @@ static struct cpu_type cpu_type_list[] = { CPU_TYPE_ENTRY(LS1026A, LS1026A, 2), CPU_TYPE_ENTRY(LS2040A, LS2040A, 4), CPU_TYPE_ENTRY(LS1012A, LS1012A, 1), + CPU_TYPE_ENTRY(LS1017A, LS1017A, 1), + CPU_TYPE_ENTRY(LS1018A, LS1018A, 1), + CPU_TYPE_ENTRY(LS1027A, LS1027A, 2), CPU_TYPE_ENTRY(LS1028A, LS1028A, 2), CPU_TYPE_ENTRY(LS1088A, LS1088A, 8), CPU_TYPE_ENTRY(LS1084A, LS1084A, 8), diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h b/arch/arm/include/asm/arch-fsl-layerscape/soc.h --- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h @@ -83,6 +83,9 @@ enum boot_src get_boot_src(void); /* LS1043A/LS1023A 23x23 package silicon has different value of VAR_PER */ #define SVR_LS1043A_P23 0x879202 #define SVR_LS1023A_P23 0x87920A +#define SVR_LS1017A 0x870B24 +#define SVR_LS1018A 0x870B20 +#define SVR_LS1027A 0x870B04 #define SVR_LS1028A 0x870B00 #define SVR_LS1046A 0x870700 #define SVR_LS1026A 0x870708 -- 2.17.1

1 0

[U-Boot] Ethernet on i.MX8MM with mainline U-Boot
by Schrempf Frieder 18 Sep '19

18 Sep '19

Hi Peng, I tried to get Ethernet running on i.MX8MM with mainline U-Boot and your latest patches for SoC-support. I added the missing clocks, but something still seems to be wrong. It seems like the clock parents are not set correctly. If I run "dm tree", I see that the enet_axi is a child of clock-osc-24m, but I would expect it to be under sys_pll1_266m as specified in the devicetree. Do you have an idea what could be wrong or some working code to look at? Thanks for your help! Regards, Frieder

2 1

[U-Boot] [PATCH] configs: ls1012ardb: Add CONFIG_ENV_ADDR for LS1012ARDB
by Kuldeep Singh 18 Sep '19

18 Sep '19

The configuration helps in picking the environment from flash before DDR init. Signed-off-by: Ashish Kumar <Ashish.Kumar(a)nxp.com> Signed-off-by: Kuldeep Singh <kuldeep.singh(a)nxp.com> --- include/configs/ls1012ardb.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h index f6640fa499..a5e27404f8 100644 --- a/include/configs/ls1012ardb.h +++ b/include/configs/ls1012ardb.h @@ -17,6 +17,10 @@ #define CONFIG_SYS_MEMTEST_END 0x9fffffff +/* ENV */ +#define CONFIG_SYS_FSL_QSPI_BASE 0x40000000 +#define CONFIG_ENV_ADDR (CONFIG_SYS_FSL_QSPI_BASE + \ + CONFIG_ENV_OFFSET) /* * I2C IO expander */ -- 2.17.1

1 0