April 2017 - U-Boot

[U-Boot] OMAP_HSMMC and MMC getcd discrepancy
by Adam Ford 09 Apr '17

09 Apr '17

I am trying to port my OMAP3630 board to use DM_MMC and OMAP_HSMMC_USE_GPIO without CONFIG_DM_MMC_OPS and with OF support by porting the OMAP3 device tree and I think there might be an issue with card detect. I am hoping someone might be able to clarify it for me. For what it's worth, the card detection in the device tree I have works fine under Linux, so I think the issue is more related to U-Boot than the device tree itself. My understanding of mmc_getwp and mmc_getcd from mmc.c is that both of them are going to be pointing to a functions that reads the status of the write protect and card detect pins. The omap_hsmmc driver maps these functions to omap_hsmmc_getcd and omap_hsmmc_getwp. There are two versions, one when DM_MMC is defined and one without it defined. Looking at the two getcd functions, it appears as if they boot look for the returned value of the gpio pin. Since CD pins are asserted low, I would expect that when the card is detected the CD pin would be 0 and 1 when absent. I would also expect the same for the WP pin. The non-DM_MMC version of the card detect function appears to address this in a comment "/* NOTE: assumes card detect signal is active-low */ and returns the opposite of the gpio value with !gpio_get_value(cd_gpio); However, the DM_MMC version has a check to see if the flag is inverted. Since these signals are passed to the higher level mmc driver, it seems like when the gpio is low, the return value should be high (card is detected when gpio = 0), yet it only inverts when the extra flag is set in the device tree and it seems like the logic is backwards. I am wondering if the omap_hsmmc_getcd using DM_MMC should instead read use: if (priv->cd_inverted) return value; return !value; If this makes sense, I can supply a patch, but I wanted to make sure I have the correct understanding first. Can someone please confirm if I am understanding this correctly? adam

1 0

[U-Boot] [PATCH v4 1/2] spl: Add spl_early_init()
by Simon Glass 09 Apr '17

09 Apr '17

From: Eddie Cai <eddie.cai.linux(a)gmail.com> At present malloc_base/_limit/_ptr are not initialised in spl_init() when we call spl_init() in board_init_f(). This is due to a recent change aimed at avoiding overwriting the malloc area set up on some boards by spl_relocate_stack_gd(). However if CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN is not defined, we now skip setting up the memory area in spl_init() which is obviously wrong. To fix this, add a new function spl_early_init() which can be called in board_init_f(). Fixes: b3d2861e (spl: Remove overwrite of relocated malloc limit) Signed-off-by: Eddie Cai <eddie.cai.linux(a)gmail.com> Rewrote spl_{,early_}init() to avoid duplicate code: Rewrite/expand commit message: Signed-off-by: Simon Glass <sjg(a)chromium.org> --- Changes in v4: None Changes in v3: None Changes in v2: - Rewrote spl_{,early_}init() to avoid duplicate code - Rewrite commit message common/spl/spl.c | 46 +++++++++++++++++++++++++++++---------- include/asm-generic/global_data.h | 1 + include/spl.h | 24 +++++++++++++++++--- 3 files changed, 57 insertions(+), 14 deletions(-) diff --git a/common/spl/spl.c b/common/spl/spl.c index 766fb3d6f4..2bc8b42027 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -170,22 +170,20 @@ __weak void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image) image_entry(); } -int spl_init(void) +static int spl_common_init(bool setup_malloc) { int ret; - debug("spl_init()\n"); -/* - * with CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN we set malloc_base and - * malloc_limit in spl_relocate_stack_gd - */ -#if defined(CONFIG_SYS_MALLOC_F_LEN) && \ - !defined(CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN) + debug("spl_early_init()\n"); + +#if defined(CONFIG_SYS_MALLOC_F_LEN) + if (setup_malloc) { #ifdef CONFIG_MALLOC_F_ADDR - gd->malloc_base = CONFIG_MALLOC_F_ADDR; + gd->malloc_base = CONFIG_MALLOC_F_ADDR; #endif - gd->malloc_limit = CONFIG_SYS_MALLOC_F_LEN; - gd->malloc_ptr = 0; + gd->malloc_limit = CONFIG_SYS_MALLOC_F_LEN; + gd->malloc_ptr = 0; + } #endif if (CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)) { ret = fdtdec_setup(); @@ -202,6 +200,32 @@ int spl_init(void) return ret; } } + + return 0; +} + +int spl_early_init(void) +{ + int ret; + + ret = spl_common_init(true); + if (ret) + return ret; + gd->flags |= GD_FLG_SPL_EARLY_INIT; + + return 0; +} + +int spl_init(void) +{ + int ret; + + if (!(gd->flags & GD_FLG_SPL_EARLY_INIT)) { + ret = spl_common_init( + !IS_ENABLED(CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN)); + if (ret) + return ret; + } gd->flags |= GD_FLG_SPL_INIT; return 0; diff --git a/include/asm-generic/global_data.h b/include/asm-generic/global_data.h index e02863dc03..5b356dd231 100644 --- a/include/asm-generic/global_data.h +++ b/include/asm-generic/global_data.h @@ -127,5 +127,6 @@ typedef struct global_data { #define GD_FLG_SKIP_RELOC 0x00800 /* Don't relocate */ #define GD_FLG_RECORD 0x01000 /* Record console */ #define GD_FLG_ENV_DEFAULT 0x02000 /* Default variable flag */ +#define GD_FLG_SPL_EARLY_INIT 0x04000 /* Early SPL init is done */ #endif /* __ASM_GENERIC_GBL_DATA_H */ diff --git a/include/spl.h b/include/spl.h index bde44374ea..cdd196d187 100644 --- a/include/spl.h +++ b/include/spl.h @@ -213,11 +213,29 @@ int spl_load_image_ext_os(struct spl_image_info *spl_image, struct blk_desc *block_dev, int partition); /** - * spl_init() - Set up device tree and driver model in SPL if enabled + * spl_early_init() - Set up device tree and driver model in SPL if enabled * * Call this function in board_init_f() if you want to use device tree and - * driver model early, before board_init_r() is called. This function will - * be called from board_init_r() if not called earlier. + * driver model early, before board_init_r() is called. + * + * If this is not called, then driver model will be inactive in SPL's + * board_init_f(), and no device tree will be available. + */ +int spl_early_init(void); + +/** + * spl_init() - Set up device tree and driver model in SPL if enabled + * + * You can optionally call spl_early_init(), then optionally call spl_init(). + * This function will be called from board_init_r() if not called earlier. + * + * Both spl_early_init() and spl_init() perform a similar function except that + * the latter will not set up the malloc() area if + * CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN is enabled, since it is assumed to + * already be done by a calll to spl_relocate_stack_gd() before board_init_r() + * is reached. + * + * This function will be called from board_init_r() if not called earlier. * * If this is not called, then driver model will be inactive in SPL's * board_init_f(), and no device tree will be available. -- 2.12.0.367.g23dc2f6d3c-goog

5 11

Re: [U-Boot] Loading kernel from SD card slow on MinnowBoard Turbot since v2016.09
by Raschen Josef 09 Apr '17

09 Apr '17

Hi, > From my tests it should be somewhere between these two commits: > 1c62d999528da1f052cb4b07cbb540b148c52537 OK > ceec08f50b66df0c988033842ec057a32658cfe0 NOK I did some more tests and it looks like commit 14bed52d276afd36b9674ee7aa2c2ad9d2f4e59e introduced the issue. From the code I would guess that the max clock of the mmc controller is not set up correctly for the x86/BayTrail platform (minnowmax_defconfig in my case). Thanks, Josef

2 1

[U-Boot] [PATCH 0/7] *** SUBJECT HERE ***
by make＠marvell.com 09 Apr '17

09 Apr '17

From: Ken Ma <make(a)marvell.com> *** BLURB HERE *** 1. Move base, max_lun and max_id such scsi generic data from platdata to uclass plat data; 2. Make scsi compatible for legacy SCSI devices and new SAS controller - Introduce scsi bus DT node, scsi work as bus and scsi disks, scsi scanner and sata are its children scsi device; this is similar to the case that spi bus manages spi flashes; In such case, scsi bus probe should probe its children devices automatically; - SAS controller can also be a scsi node as current. 3. Example with mvebu armada 3700 scsi bus node Ken Ma (7): scsi: move base, max_lun and max_id to uclass plat data scsi: add children devices binding scsi: call children devices' probe functions automatically scsi: dt-bindings: add scsi device tree bindings scsi: mvebu: add scsi driver scsi: a3700: enable mvebu scsi driver scsi: dts: a3700: add scsi node arch/arm/dts/armada-3720-db.dts | 4 ++ arch/arm/dts/armada-37xx.dtsi | 16 +++++-- common/scsi.c | 2 +- configs/mvebu_db-88f3720_defconfig | 2 + .../scsi/marvell,mvebu-scsi.txt | 29 ++++++++++++ doc/device-tree-bindings/scsi/scsi-bus.txt | 22 +++++++++ drivers/block/Kconfig | 10 ++++ drivers/block/Makefile | 1 + drivers/block/ahci.c | 2 +- drivers/block/mvebu_scsi.c | 31 +++++++++++++ drivers/block/scsi-uclass.c | 54 +++++++++++++++++++++- 11 files changed, 165 insertions(+), 8 deletions(-) create mode 100644 doc/device-tree-bindings/scsi/marvell,mvebu-scsi.txt create mode 100644 doc/device-tree-bindings/scsi/scsi-bus.txt create mode 100644 drivers/block/mvebu_scsi.c -- 1.9.1

4 31

[U-Boot] [PATCH 0/5]
by Eric Gao 09 Apr '17

09 Apr '17

This serials patches add mipi dsi support for rk3399. Except the basic mipi driver, we need also enable pmic rk808 for lcd power and enable i2c for rk808 communication. what's more, the needed clk and pwm for backlight is init in spl stage, make sure spl work first. Eric Gao (3): rockchip: video: Add mipi dsi driver rockchip: Add dts config for mipi dsi rockchip: Enable mipi dsi configs eric.gao (2): rockchip: i2c: Enable i2c for rk3399 rockchip: pmic: Enable RK808 for rk3399 evb arch/arm/dts/rk3399-evb.dts | 123 ++++++ arch/arm/dts/rk3399.dtsi | 88 +++++ arch/arm/include/asm/arch-rockchip/cru_rk3399.h | 1 + arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 25 ++ arch/arm/include/asm/arch-rockchip/mipi_rk3399.h | 189 +++++++++ arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 1 + configs/evb-rk3399_defconfig | 12 + drivers/i2c/rk_i2c.c | 1 + drivers/video/Kconfig | 2 + drivers/video/rockchip/Kconfig | 47 +++ drivers/video/rockchip/Makefile | 6 +- drivers/video/rockchip/rk_mipi.c | 465 +++++++++++++++++++++++ drivers/video/rockchip/rk_vop.c | 39 +- 13 files changed, 992 insertions(+), 7 deletions(-) create mode 100644 arch/arm/include/asm/arch-rockchip/mipi_rk3399.h create mode 100644 drivers/video/rockchip/Kconfig create mode 100644 drivers/video/rockchip/rk_mipi.c -- 1.9.1

2 2

[U-Boot] [PATCH] rockchip: arm: halt when enable bucks of PMIC rk808
by Eric Gao 09 Apr '17

09 Apr '17

From: "Eric Gao" <eric.gao(a)rock-chips.com> when enable PMIC rk808,the system will halt at very early stage,log is shown as bellow. INFO: plat_rockchip_pmu_init(1211): pd status 3e INFO: BL31: Initializing runtime services INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 time 44561b, 0 (<<----Just stop here) It's caused by the absence of "{ }" in syscon_rk3399.c ,which will lead to memory overflow like below.According to Sysmap file ,we can find the function buck_get_value of rk808 is just follow the compatible struct,the pointer "of_match" point to "buck_get_value",but it is not a struct and don't have member of compatible, In this case, system crash. So,on the face, it looks like that rk808 is guilty.but he is really innocent. while (of_match->compatible) { <<---------- if (!strcmp(of_match->compatible, compat)) { *of_idp = of_match; return 0; } of_match++; } Signed-off-by: eric.gao <eric.gao(a)rock-chips.com> Signed-off-by: Eric Gao <eric.gao(a)rock-chips.com> --- arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c index d32985b..74d4552 100644 --- a/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/syscon_rk3399.c @@ -14,6 +14,7 @@ static const struct udevice_id rk3399_syscon_ids[] = { { .compatible = "rockchip,rk3399-pmugrf", .data = ROCKCHIP_SYSCON_PMUGRF }, { .compatible = "rockchip,rk3399-pmusgrf", .data = ROCKCHIP_SYSCON_PMUSGRF }, { .compatible = "rockchip,rk3399-cic", .data = ROCKCHIP_SYSCON_CIC }, + { } }; U_BOOT_DRIVER(syscon_rk3399) = { -- 1.9.1

2 1

[U-Boot] [PATCH v2 0/5] Patches to reduce TPL code size
by Simon Glass 09 Apr '17

09 Apr '17

With the rockchip 'rock' board some build and code size problems have come to light with TPL. This series provides a few ideas to improve things. Changes in v2: - Adjust the option to be SPL-only - Change the option to default to off (name it CONFIG_SPL_TINY_MEMSET) - Add a new patch to enable CONFIG_SPL_TINY_MEMSET - Add new patch to allow driver model to be disabled for TPL - Add new patch to allow driver-model serial to be disabled for TPL Simon Glass (5): string: Provide a slimmed-down memset() rockchip: rock: Enable CONFIG_SPL_TINY_MEMSET Makefile: Provide an option to select SPL or TPL dm: core: Allow driver model to be disabled for TPL dm: serial: Allow driver-model serial to be disabled for TPL configs/rock_defconfig | 1 + drivers/Makefile | 2 +- drivers/core/Kconfig | 14 ++++++++++++++ drivers/serial/Kconfig | 20 ++++++++++++++++++++ drivers/serial/Makefile | 2 +- lib/Kconfig | 8 ++++++++ lib/string.c | 6 ++++-- scripts/Kbuild.include | 6 ++++++ scripts/Makefile.spl | 6 ++++++ 9 files changed, 61 insertions(+), 4 deletions(-) -- 2.12.2.564.g063fe858b8-goog

4 13

[U-Boot] [RFC] tiny-printf: Add support for %p format
by Vignesh R 09 Apr '17

09 Apr '17

Add support for %p, %pa[p], %pM, %pm and %pI4 formats to tiny-printf. %pM and %pI4 are widely used by SPL networking stack and is required if networking support is desired in SPL. Before this patch: $ size spl/u-boot-spl text data bss dec hex filename 99325 4899 218584 322808 4ecf8 spl/u-boot-spl After this patch (with CONFIG_SPL_NET_SUPPORT): $ size spl/u-boot-spl text data bss dec hex filename 99714 4899 218584 323197 4ee7d spl/u-boot-spl So, this patch adds ~390 bytes to code size. If CONFIG_SPL_NET_SUPPORT is not enabled then only %p, %pa, %pap are supported, this adds ~90 bytes to code size. Compiler used is: arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016 Signed-off-by: Vignesh R <vigneshr(a)ti.com> --- lib/tiny-printf.c | 148 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 148 insertions(+) diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c index 6def8f98aa41..e524ffb657e6 100644 --- a/lib/tiny-printf.c +++ b/lib/tiny-printf.c @@ -12,6 +12,7 @@ #include <common.h> #include <stdarg.h> #include <serial.h> +#include <linux/ctype.h> struct printf_info { char *bf; /* Digit buffer */ @@ -52,6 +53,148 @@ static void div_out(struct printf_info *info, unsigned long *num, out_dgt(info, dgt); } +#ifdef CONFIG_SPL_NET_SUPPORT +static void string(struct printf_info *info, char *s) +{ + char ch; + + while ((ch = *s++)) + out(info, ch); +} + +static const char hex_asc[] = "0123456789abcdef"; +#define hex_asc_lo(x) hex_asc[((x) & 0x0f)] +#define hex_asc_hi(x) hex_asc[((x) & 0xf0) >> 4] + +static inline char *pack_hex_byte(char *buf, u8 byte) +{ + *buf++ = hex_asc_hi(byte); + *buf++ = hex_asc_lo(byte); + return buf; +} + +static void mac_address_string(struct printf_info *info, u8 *addr, + bool separator) +{ + /* (6 * 2 hex digits), 5 colons and trailing zero */ + char mac_addr[6 * 3]; + char *p = mac_addr; + int i; + + for (i = 0; i < 6; i++) { + p = pack_hex_byte(p, addr[i]); + if (separator && i != 5) + *p++ = ':'; + } + *p = '\0'; + + string(info, mac_addr); +} + +static char *put_dec_trunc(char *buf, unsigned int q) +{ + unsigned int d3, d2, d1, d0; + d1 = (q >> 4) & 0xf; + d2 = (q >> 8) & 0xf; + d3 = (q >> 12); + + d0 = 6 * (d3 + d2 + d1) + (q & 0xf); + q = (d0 * 0xcd) >> 11; + d0 = d0 - 10 * q; + *buf++ = d0 + '0'; /* least significant digit */ + d1 = q + 9 * d3 + 5 * d2 + d1; + if (d1 != 0) { + q = (d1 * 0xcd) >> 11; + d1 = d1 - 10 * q; + *buf++ = d1 + '0'; /* next digit */ + + d2 = q + 2 * d2; + if ((d2 != 0) || (d3 != 0)) { + q = (d2 * 0xd) >> 7; + d2 = d2 - 10 * q; + *buf++ = d2 + '0'; /* next digit */ + + d3 = q + 4 * d3; + if (d3 != 0) { + q = (d3 * 0xcd) >> 11; + d3 = d3 - 10 * q; + *buf++ = d3 + '0'; /* next digit */ + if (q != 0) + *buf++ = q + '0'; /* most sign. digit */ + } + } + } + return buf; +} + +static void ip4_addr_string(struct printf_info *info, u8 *addr) +{ + /* (4 * 3 decimal digits), 3 dots and trailing zero */ + char ip4_addr[4 * 4]; + char temp[3]; /* hold each IP quad in reverse order */ + char *p = ip4_addr; + int i, digits; + + for (i = 0; i < 4; i++) { + digits = put_dec_trunc(temp, addr[i]) - temp; + /* reverse the digits in the quad */ + while (digits--) + *p++ = temp[digits]; + if (i != 3) + *p++ = '.'; + } + *p = '\0'; + + string(info, ip4_addr); +} +#endif + +/* + * Show a '%p' thing. A kernel extension is that the '%p' is followed + * by an extra set of characters that are extended format + * specifiers. + * + * Right now we handle: + * + * - 'M' For a 6-byte MAC address, it prints the address in the + * usual colon-separated hex notation. + * - 'm' Same as above except there is no colon-separator. + * - 'I4'for IPv4 addresses printed in the usual way (dot-separated + * decimal). + */ + +static void pointer(struct printf_info *info, const char *fmt, void *ptr) +{ + unsigned long num = (uintptr_t)ptr; + unsigned long div; + + switch (*fmt) { + case 'a': + + switch (fmt[1]) { + case 'p': + default: + num = *(phys_addr_t *)ptr; + break; + } + break; +#ifdef CONFIG_SPL_NET_SUPPORT + case 'm': + return mac_address_string(info, ptr, false); + case 'M': + return mac_address_string(info, ptr, true); + case 'I': + if (fmt[1] == '4') + return ip4_addr_string(info, ptr); +#endif + default: + break; + } + div = 1UL << (sizeof(long) * 8 - 4); + for (; div; div /= 0x10) + div_out(info, &num, div); +} + static int _vprintf(struct printf_info *info, const char *fmt, va_list va) { char ch; @@ -144,6 +287,11 @@ static int _vprintf(struct printf_info *info, const char *fmt, va_list va) case 's': p = va_arg(va, char*); break; + case 'p': + pointer(info, fmt, va_arg(va, void *)); + while (isalnum(fmt[0])) + fmt++; + break; case '%': out(info, '%'); default: -- 2.11.0

3 4

[U-Boot] [v2017.03] firefly-rk3288 link failure
by Andreas Färber 09 Apr '17

09 Apr '17

Hello, In v2017.03 the firefly-rk3288 target fails to link with our gcc 6.3.1. I've tried gcc 7.0.1 (CC=gcc-7), but no change. [ 99s] LD u-boot [ 99s] ld.bfd: u-boot: Not enough room for program headers, try linking with -N [ 99s] ld.bfd: final link failed: Bad value [ 99s] make: *** [Makefile:1206: u-boot] Error 1 This is a regression from v2017.01. Is there a known fix or workaround? Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)

2 4

[U-Boot] [PATCH RFC] omap_hsmmc: update struct hsmmc to accommodate omap3 from DT
by Adam Ford 09 Apr '17

09 Apr '17

I am working on porting an OMAP3630 board to support device tree, and I attempted to change enable DM_MMC. Unfortunately, that broke MMC. I discovered that the base addresses were originally updated to reflect a change in the base address when using the device tree for some devices. This was done in 11e1582506c6 ("omap_hsmmc: update struct hsmmc to accomodate base address from DT") Unfortunately, this breaks the base address on an OMAP3630 (and I assume omap34xx) which currently doesn't have OF support yet. Without this patch, the when driver attemps to write to mmc_base->sysconfig at 4809c110 is used instead of mmc_base->sysconfig at 4809c010. This makes any attempt to use the mmc fail. With this patch, I am able to read/write to the MMC device with DM_MMC enabled with OF support. If there is a better solution, I am open to ideas. I verified this against the OMAP3530 TRM and OMAP3630 TRM. Since AM3359 TRM has the same value, it might be helpful for other boards, but I don't have them to test. If there is a better solution, I am perfectly open for suggestions. If this gets reviewed and approved, I can push the OMAP3630 (and OMAP3) device trees which might let more boards move to DM and OF support. Signed-off-by: Adam Ford <aford173(a)gmail.com> diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h index f2bf645..fd9b741 100644 --- a/arch/arm/include/asm/omap_mmc.h +++ b/arch/arm/include/asm/omap_mmc.h @@ -26,7 +26,7 @@ #define OMAP_MMC_H_ struct hsmmc { -#ifdef CONFIG_DM_MMC +#if defined(CONFIG_DM_MMC) && !defined(OMAP34XX) unsigned char res0[0x100]; #endif unsigned char res1[0x10]; -- 2.7.4

1 0