February 2018 - U-Boot

[U-Boot] armv5 and OMAP3 Question
by Adam Ford 04 Aug '18

04 Aug '18

The readme file for OMAP indicates that we compile using armv5 to "to allow more compilers to work" We have our arch/arm/mach-omap2/omap3/lowlevel_init.S file also noting some special assembly insturctions becuse we use armv5. The barriers defined also indicate we're using CP15 instead of the separate barrier instructions for armv7 because we're using armv5 instead. I just wonder in this day and age when we're noting a GCC version and generating warnings based on the GCC warning, do we still need to compile as armv5 any more? It seems like "to allow more compilers to work" would not really apply any more we're trying to push newer versions of GCC. (please don't flame me, I am honestly curious). adam

2 9

[U-Boot] [PATCH] xyz-modem: Change getc timeout loop waiting
by Tomas Melin 02 Aug '18

02 Aug '18

This fixes the loop delay when using a hw watchdog. In case a watchdog is used that accesses CPU registers, the defined delay of 20us in a tight loop will cause a huge delay in the actual timeout seen. This is caused by the fact that udelay will inheritantly call WATCHDOG_RESET. Together with the omap wdt implementation, the seen timeout increases up to around 30s. This makes the loop very slow and causes long delays when using the modem. Instead, implement the 2 sec loop by using the timer interface to know when to break out of the timeout loop. Watchdog kicking is taken care of by getc(). Signed-off-by: Tomas Melin <tomas.melin(a)vaisala.com> --- common/xyzModem.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/common/xyzModem.c b/common/xyzModem.c index 5656aac..e0d87db 100644 --- a/common/xyzModem.c +++ b/common/xyzModem.c @@ -71,12 +71,12 @@ typedef int cyg_int32; static int CYGACC_COMM_IF_GETC_TIMEOUT (char chan, char *c) { -#define DELAY 20 - unsigned long counter = 0; - while (!tstc () && (counter < xyzModem_CHAR_TIMEOUT * 1000 / DELAY)) + + ulong now = get_timer(0); + while (!tstc ()) { - udelay (DELAY); - counter++; + if (get_timer(now) > xyzModem_CHAR_TIMEOUT) + break; } if (tstc ()) { -- 2.1.4

3 6

[U-Boot] [PATCH v2 00/26] mmc: Add support for HS200 and UHS modes
by Jean-Jacques Hiblot 24 Jul '18

24 Jul '18

This series brings support for HS200 and UHS modes to the mmc core. It has been tested with the hsmmc driver on several platforms (DRA7, AM57x, AM437x, beaglebone black, Atmel SAMA5D3 xplained). Some modifications are required in the host driver to take advantage of this (voltage switching, tuning). The changes to the host driver will be posted a another series as this one is already long enough. The series starts with a small refactoring of th sd/mmc startup. The first 5 commits are mostly moving code around with little or no functionnal change. Then the notion of "mode" is introduced. Until now, this information wasn't kept in struct mmc. Only the clock and a flag for ddr was kept. Later the mode information will be used to select the clock frequency, the ddr flag and the tuning procedure. It will be also be check against the host capabilities. Then comes the big refactoring job in: "mmc: refactor MMC startup to make it easier to support new modes" and "mmc: refactor SD startup to make it easier to support new modes" Since the number of modes is increasing, it makes sense to try them in a more organized way. those commits use a list of supported modes and iterate through them to find the best working one. It also allows to switch more easilly from one mode to another (switching from HS200 to DDR52 to access boot partitions for example) Then there are a couple of new callback added to: - send the initialization stream (74 clock cycles) - wait while the card is busy (used during UHS voltage switching). checking is done on dat0. - select the IO voltage Then Power cycle is added. Without power cycle, if a UHS card fails to enumerate in UHS mode, it can't fall back to high speed mode and card enumeration will fail. Also in case of a reset (as opposed to a power on), it ensures that the SDCard is in clean state before re-doing the initialization. And finally the last commits add the support for HS200 and UHS. With this in place and the required changes in the HSMMC host driver (including DMA), we observe significant improvements in the performances on a DRA72 evm: eMMC HS200: 124 MB/s eMMC DDR52: 78 MB/s sd SDR104: 71 MB/s sd SDR50: 44 MB/s cheers, Jean-Jacques changes since v1: Changes take in account all the comment made during the first round of review. But it also include a rework of the handling of the voltage supplies and 2 new helper functions that can be used by the host driver during tuning and dts parsing. Here is a detailed list: * rebase on u-boot/master. * add the description for the new functions/members * fix the typos found in the reviews * limit the new features to DM_MMC only * fix the new checkpatch warnings/errors (is it now more strict ?) * get the voltage regulators from dts (main and IO-lines) * remove the set_vdd callback and do the job in the mmc core * add a send_init_stream callback to perform the 74 clock cycle sequence after power up * do a full power cycle (if possible) before the initialization. This ensures that the sd/MMC is in valid knwon state. Also it allows to check if the power cycling works as expected. * disable the UHS modes is power cycling is not available/working. This ensures that we won't be stuck if the UHS initialization fails. * select the appropriate signal voltage when selecting a mode (MMC only) * add a helper function to parse the generic dt bindings * add a helper function to send the tuning command Jean-Jacques Hiblot (17): mmc: dm: get the IO-line and main voltage regulators from the dts mmc: split mmc_startup() mmc: move the MMC startup for version above v4.0 in a separate function mmc: make ext_csd part of struct mmc mmc: add a function to read and test the ext csd (mmc >= 4) mmc: introduce mmc modes mmc: Add a function to dump the mmc capabilities mmc: use mmc modes to select the correct bus speed cmd: mmc: display the mode name and current bus speed in the mmc info mmc: refactor SD startup to make it easier to support new modes mmc: refactor MMC startup to make it easier to support new modes mmc: Add a new callback function to perform the 74 clocks cycle sequence mmc: Add support for UHS modes mmc: disable UHS modes if Vcc cannot be switched on and off mmc: Change mode when switching to a boot partition mmc: use the right voltage level for MMC DDR and HS200 modes mmc: add a library function to send tuning command Kishon Vijay Abraham I (9): mmc: make mmc_set_ios() return status mmc: Enable signal voltage to be selected from mmc core mmc: add power cyle support in mmc core mmc: add a new mmc parameter to disable mmc clock mmc: disable the mmc clock during power off mmc: Add a execute_tuning() callback to the mmc operations. mmc: add HS200 support in MMC core mmc: Retry some MMC cmds on failure dm: mmc: Add a library function to parse generic dt binding cmd/mmc.c | 3 +- drivers/mmc/Kconfig | 23 + drivers/mmc/fsl_esdhc.c | 2 +- drivers/mmc/mmc-uclass.c | 87 +++ drivers/mmc/mmc.c | 1511 ++++++++++++++++++++++++++++++++++------------ include/mmc.h | 176 +++++- 6 files changed, 1417 insertions(+), 385 deletions(-) -- 1.9.1

7 49

[U-Boot] Support of kernels > 16 MiB on Raspberry Pi
by Alexander Kurtz 21 Jul '18

21 Jul '18

Hi! I am using U-Boot to boot Debian Buster arm64 (standard kernel with a dracut-based initramfs) via an extlinux.conf on my Raspberry Pi 3. Recently, the Debian kernel grew beyond 16 MiB: 4.13: /boot/vmlinuz-4.13.0-1-arm64 == 16448000 bytes (< 16 MiB) [0] 4.14: /boot/vmlinuz-4.14.0-3-arm64 == 17539584 bytes (> 16 MiB) [1] 4.15: /boot/vmlinuz-4.15.0-1-arm64 == 17867264 bytes (> 16 MiB) [2] https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h#L129 says: #define ENV_MEM_LAYOUT_SETTINGS \ "fdt_high=ffffffff\0" \ "initrd_high=ffffffff\0" \ "fdt_addr_r=0x00000100\0" \ "pxefile_addr_r=0x00100000\0" \ "kernel_addr_r=0x01000000\0" \ "scriptaddr=0x02000000\0" \ "ramdisk_addr_r=0x02100000\0" \ Am I correct in assuming that this default configuration will break with kernels > 16 MiB? The Readme [3] seems to confirm this, but I wanted to ask for explicit confirmation here. The background is that ever since the upgrade to 4.14, the kernel has been failing to unpack the initramfs, complaining about "junk in [the] compressed archive" and I am currently trying to find where to best file a bug report about this! Best regards Alexander Kurtz [0] http://snapshot.debian.org/package/linux/4.13.13-1/#linux-image-4.13.0-1-ar… [1] http://snapshot.debian.org/package/linux/4.14.17-1/#linux-image-4.14.0-3-ar… [2] http://snapshot.debian.org/package/linux/4.15.4-1/#linux-image-4.15.0-1-arm… [3] https://github.com/u-boot/u-boot/blob/master/doc/README.distro#L250

5 7

[U-Boot] [RFC] Make U-Boot log great again
by Sam Protsenko 18 Jul '18

18 Jul '18

Hi guys, TL;DR This is a suggestion about fixing U-Boot log, which has got worse recently. Right now U-Boot and SPL logs are cluttered with bogus warnings like these (on X15 board, but I'm pretty sure it should appear on many others): Loading Environment from FAT... *** Warning - bad CRC, using default environment Failed (-5) Those are the consequences of next commit: fb69464eae1e ("env: Allow to build multiple environments in Kconfig") Because of this commit, I can see following changes in my .config file: +CONFIG_ENV_IS_IN_FAT=y +CONFIG_ENV_FAT_INTERFACE="mmc" +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" +CONFIG_ENV_FAT_FILE="uboot.env" which led U-Boot to try and load the environment from different sources. I agree that it's good thing to do and can be useful, but the problem is that the code for loading the environment wasn't changed to handle errors properly. How I suggest to handle that case: 1. If we have two sources for the environment (e.g. FAT partition on SD card and some raw partition on eMMC), we shouldn't print error messages if we were unable to load the environment from one source 2. We should probably print some human-readable information that we didn't find the environment there, let's skip and look for next source (but don't print those warnings/failed messages) 3. And only print the error message in case when U-Boot environment wasn't found at all (on all possible sources). I don't have enough time to fix this by my own right now. But let's discuss how to approach this issue in a best way possible. And if someone wants to step forward and do that -- would be really nice. If no -- I can look into that later. But let's collect some opinions here, first. Thanks.

8 22

[U-Boot] [PATCH v2] rockchip: i2c: enable new I2C controller for rk3066 and rk3188
by Alexander Kochetkov 13 Jul '18

13 Jul '18

rk3066 and rk3188 has two I2C controller implementations. Current I2C driver wan't work with legacy implementation. Switching between controllers is performed using a bit inside GFR_SOC_CON1 register. The bit setting is performed by pinctrl driver. The patch ask pinctrl to do settings. Signed-off-by: Alexander Kochetkov <al.kochet(a)gmail.com> --- drivers/i2c/rk_i2c.c | 90 +++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 85 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/rk_i2c.c b/drivers/i2c/rk_i2c.c index 332280c..ce6b441 100644 --- a/drivers/i2c/rk_i2c.c +++ b/drivers/i2c/rk_i2c.c @@ -34,6 +34,18 @@ struct rk_i2c { unsigned int speed; }; +enum { + RK_I2C_LEGACY, + RK_I2C_NEW, +}; + +/** + * @controller_type: i2c controller type + */ +struct rk_i2c_soc_data { + int controller_type; +}; + static inline void rk_i2c_get_div(int div, int *divh, int *divl) { *divl = div / 2; @@ -381,9 +393,38 @@ static int rockchip_i2c_ofdata_to_platdata(struct udevice *bus) static int rockchip_i2c_probe(struct udevice *bus) { struct rk_i2c *priv = dev_get_priv(bus); + struct rk_i2c_soc_data *soc_data; + struct udevice *pinctrl; + int bus_nr; + int ret; priv->regs = dev_read_addr_ptr(bus); + soc_data = (struct rk_i2c_soc_data*)dev_get_driver_data(bus); + + if (soc_data->controller_type == RK_I2C_LEGACY) { + ret = dev_read_alias_seq(bus, &bus_nr); + if (ret < 0) { + debug("%s: Could not get alias for %s: %d\n", + __func__, bus->name, ret); + return ret; + } + + ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl); + if (ret) { + debug("%s: Cannot find pinctrl device\n", __func__); + return ret; + } + + /* pinctrl will switch I2C to new type */ + ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_I2C0 + bus_nr); + if (ret) { + debug("%s: Failed to switch I2C to new type %s: %d\n", + __func__, bus->name, ret); + return ret; + } + } + return 0; } @@ -392,12 +433,51 @@ static const struct dm_i2c_ops rockchip_i2c_ops = { .set_bus_speed = rockchip_i2c_set_bus_speed, }; +static const struct rk_i2c_soc_data rk3066_soc_data = { + .controller_type = RK_I2C_LEGACY, +}; + +static const struct rk_i2c_soc_data rk3188_soc_data = { + .controller_type = RK_I2C_LEGACY, +}; + +static const struct rk_i2c_soc_data rk3228_soc_data = { + .controller_type = RK_I2C_NEW, +}; + +static const struct rk_i2c_soc_data rk3288_soc_data = { + .controller_type = RK_I2C_NEW, +}; + +static const struct rk_i2c_soc_data rk3328_soc_data = { + .controller_type = RK_I2C_NEW, +}; + +static const struct rk_i2c_soc_data rk3399_soc_data = { + .controller_type = RK_I2C_NEW, +}; + static const struct udevice_id rockchip_i2c_ids[] = { - { .compatible = "rockchip,rk3066-i2c" }, - { .compatible = "rockchip,rk3188-i2c" }, - { .compatible = "rockchip,rk3288-i2c" }, - { .compatible = "rockchip,rk3328-i2c" }, - { .compatible = "rockchip,rk3399-i2c" }, + { + .compatible = "rockchip,rk3066-i2c", + .data = (ulong)&rk3066_soc_data, + }, + { + .compatible = "rockchip,rk3188-i2c", + .data = (ulong)&rk3188_soc_data, + }, + { + .compatible = "rockchip,rk3288-i2c", + .data = (ulong)&rk3288_soc_data, + }, + { + .compatible = "rockchip,rk3328-i2c", + .data = (ulong)&rk3328_soc_data, + }, + { + .compatible = "rockchip,rk3399-i2c", + .data = (ulong)&rk3399_soc_data, + }, { } }; -- 1.7.9.5

3 4

[U-Boot] [PATCH] rockchip: rk3188: add rk_board_late_init() hook
by Alexander Kochetkov 13 Jul '18

13 Jul '18

All other rockchip boards have rk_board_late_init() hook, so add it to rk3188 boards also. Signed-off-by: Alexander Kochetkov <al.kochet(a)gmail.com> --- arch/arm/mach-rockchip/rk3188-board.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/rk3188-board.c b/arch/arm/mach-rockchip/rk3188-board.c index 916d18f..fc58aeb 100644 --- a/arch/arm/mach-rockchip/rk3188-board.c +++ b/arch/arm/mach-rockchip/rk3188-board.c @@ -20,6 +20,11 @@ DECLARE_GLOBAL_DATA_PTR; +__weak int rk_board_late_init(void) +{ + return 0; +} + int board_late_init(void) { struct rk3188_grf *grf; @@ -35,7 +40,7 @@ int board_late_init(void) NOC_REMAP_MASK << NOC_REMAP_SHIFT); } - return 0; + return rk_board_late_init(); } int board_init(void) -- 1.7.9.5

4 7

[U-Boot] [PATCH RESEND 0/4] Add CONFIG_SPL_NAND_IDENT
by Jörg Krause 27 Jun '18

27 Jun '18

RESEND because adding U-Boot NAND maintainer (Scott Wood) on Cc. When adding SPL support to a custom i.MX6ULL board with Toshiba TC58NVG0S3 NAND chip the MXS NAND SPL loader failed with "Failed to identify". This reason is that the SPL MXS NAND driver only supports ONFi-compliant NAND chips and the mentioned Toshiba NAND chip is non-ONFi. This patch set makes `nand_get_flash_type()` from `nand_base.c` public, so it can be used by any SPL NAND driver, introduced a new config option `CONFIG_SPL_NAND_IDENT` to enable the lookup for supported NAND chips in the chip ID list. Finally, the MXS NAND SPL driver is refactored so that the original ONFi-only identification routine is enabled by default. For non-ONFi NAND chips the newly introduced config option can be used. In my setup the binary size of `u-boot-spl.bin` is increased by about 13 kB when `CONFIG_SPL_NAND_IDENT` is enabled. As the i.MX6, as well as the i.MX28, both have an OCRAM of 128 kB the increase in the binary size is reasonable. Jörg Krause (4): mtd: nand: export nand_get_flash_type function spl, nand: add option CONFIG_SPL_NAND_IDENT to lookup for supported NAND chips mtd: nand: mxs_nand_spl: refactor mxs_flash_ident mtd: nand: mxs_nand_spl: add mxs_flash_full_ident README | 4 ++++ drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/mxs_nand_spl.c | 37 ++++++++++++++++++++++++++++++++++++- drivers/mtd/nand/nand_base.c | 3 ++- include/linux/mtd/rawnand.h | 10 +++++++--- scripts/config_whitelist.txt | 1 + 6 files changed, 51 insertions(+), 5 deletions(-) -- 2.15.1

2 8

[U-Boot] [RFC PATCH 0/2] ARM: v7: Enable basic framework for supporting bits for CVE-2017-5715
by Nishanth Menon 13 Jun '18

13 Jun '18

Hi Folks, This is a follow through on the discussion we have had in [1]. This itself is'nt a complete solution and is based on recommendation This from Arm[2] for variant 2 CVE-2017-5715 The Linux kernel discussions are spread out in [3], ATF and OPTEE status are available in [4]. This is just an RFC series (build tested at this point) to check if the direction is fine and should follow the final solution once kernel patches get to upstream, IMHO. NOTE: As per ARM recommendations[2], and discussions in list[1] ARM Cortex-A9/12/17 do not need additional steps in u-boot to enable the OS level workarounds. Nishanth Menon (2): ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for CVE-2017-5715 ARM: Introduce ability to enable invalidate of BTB on Cortex-A15 for CVE-2017-5715 arch/arm/Kconfig | 9 +++++++++ arch/arm/cpu/armv7/start.S | 15 +++++++++++++-- 2 files changed, 22 insertions(+), 2 deletions(-) [1] https://marc.info/?t=151639906500002&r=1&w=2 [2] https://developer.arm.com/support/security-update [3] https://marc.info/?t=151543790400007&r=1&w=2 and the latest in https://marc.info/?l=linux-arm-kernel&m=151689379521082&w=2 [4] https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmw… https://www.op-tee.org/security-advisories/ https://www.linaro.org/blog/meltdown-spectre/ -- 2.15.1

5 11

[U-Boot] Uboot as x86_64 EFI payload
by Juan Alfonso Reyes Ajenjo 10 Jun '18

10 Jun '18

Hi, I am Juan Alfonso Reyes, a firmware engineer in GMV. Currently we are developing new boards based in Apollo Lake CPU. We are trying to load uboot from UEFI. Using the default qemu-x86_efi_payload64_defconfig we are getting "U-Boot EFI Payload 2002 No memory map" error code. As I can see in the code 2002 means (efi_stub.c): ret = boot->get_memory_map(&size, NULL, &key, &desc_size, &version); if (ret != EFI_BUFFER_TOO_SMALL) { printhex2(BITS_PER_LONG); printhex2(ret); puts(" No memory map\n"); while(1); return ret; } 0x20 -> BITS_PER_LONG 32bits 0x02 -> EFI_INVALID_PARAMETER 32bits sounds weird for me, so I changed config to use CONFIG_X86_RUN_64BIT instead of CONFIG_X86_RUN_32BIT. I have changed it and I got a compilation error: In file included from include/common.h:53:0, from cmd/efi.c:8: cmd/efi.c: In function 'do_efi_mem': ./arch/x86/include/asm/global_data.h:117:12: error: 'global_data_ptr' undeclared (first use in this function) #define gd global_data_ptr I have surfed in the code and I have found this in ./arch/x86/include/asm/global_data.h # if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64) /* TODO(sjg(a)chromium.org<mailto:sjg@chromium.org>): Consider using a fixed register for gd on x86_64 */ #define gd global_data_ptr What do you mean with "Consider using a fixed register for gd" ?Can you help us to make this work? Are we in the correct direction? Thank you very much, Best regards, ________________________________ [cid:image001.gif@01D39918.97D8D0B0] Juan Alfonso Reyes Ajenjo Ingeniero en Informatica / Computer Systems Engineer Ingeniero en Automática y Electrónica Industrial / Automation and Industrial Electronics Engineer GMV Juan de Herrera nº17 Boecillo E-47151 Valladolid Tel. +34 983 54 65 54 Fax +34 983 54 65 53 www.gmv.com <http://www.gmv.com/> [cid:image002.png@01D39918.97D8D0B0]<http://www.facebook.com/infoGMV> [cid:image003.png@01D39918.97D8D0B0]<http://www.twitter.com/infoGMV_es> [cid:image004.png@01D39918.97D8D0B0]<https://plus.google.com/+Gmvcompany> [cid:image005.png@01D39918.97D8D0B0]<http://www.youtube.com/infoGMV> [cid:image006.png@01D39918.97D8D0B0]<https://www.linkedin.com/company/gmv> [cid:image007.png@01D39918.97D8D0B0]<http://www.gmv.com/en/RSS> [cid:image008.png@01D39918.97D8D0B0]<http://www.gmv.com/blog_gmv/language/en/> P Please consider the environment before printing this e-mail. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________

4 6