January 2017 - U-Boot

[U-Boot] [PATCH] tools: imximage: use 'new style' header length for imximage v1
by Martin Kaiser 27 Jan '17

27 Jan '17

From: Martin Kaiser <martin(a)kaiser.cx> We can use the same mechanism for the imximage v1 header length calculations that we're using for v2. Doing so, we can share more code between v1 and v2. Additionally, *header_size_ptr in imximage_set_header() will then have the correct value for both v1 and v2. Signed-off-by: Martin Kaiser <martin(a)kaiser.cx> --- I discovered the problem when I tried to use csf_ptr with imximage v1 (as part of a private modification). *csf_ptr = params->ep + *header_size_ptr - imximage_init_loadsize; = params->ep + sbuf->st_size + imximage_ivt_offset - imximage_init_loadsize; = params->ep + padded data file size + alloc_len - (imximage_init_loadsize - imximage_ivt_offset); This works only if alloc_len == imximage_init_loadsize - imximage_ivt_offset, not if alloc_len is always 4096. tools/imximage.c | 43 ++++++++++++++++++++----------------------- 1 file changed, 20 insertions(+), 23 deletions(-) diff --git a/tools/imximage.c b/tools/imximage.c index 092d550..e280da6 100644 --- a/tools/imximage.c +++ b/tools/imximage.c @@ -291,8 +291,7 @@ static void set_imx_hdr_v1(struct imx_header *imxhdr, uint32_t dcd_len, /* Set magic number */ fhdr_v1->app_code_barker = APP_CODE_BARKER; - /* TODO: check i.MX image V1 handling, for now use 'old' style */ - hdr_base = entry_point - 4096; + hdr_base = entry_point - imximage_init_loadsize + flash_offset; fhdr_v1->app_dest_ptr = hdr_base - flash_offset; fhdr_v1->app_code_jump_vector = entry_point; @@ -649,6 +648,7 @@ static void imximage_set_header(void *ptr, struct stat *sbuf, int ifd, { struct imx_header *imxhdr = (struct imx_header *)ptr; uint32_t dcd_len; + uint32_t imx_hdr_size; /* * In order to not change the old imx cfg file @@ -664,12 +664,13 @@ static void imximage_set_header(void *ptr, struct stat *sbuf, int ifd, /* Parse dcd configuration file */ dcd_len = parse_cfg_file(imxhdr, params->imagename); - if (imximage_version == IMXIMAGE_V2) { - if (imximage_init_loadsize < imximage_ivt_offset + - sizeof(imx_header_v2_t)) - imximage_init_loadsize = imximage_ivt_offset + - sizeof(imx_header_v2_t); - } + if (imximage_version == IMXIMAGE_V1) + imx_hdr_size = sizeof(imx_header_v1_t); + else + imx_hdr_size = sizeof(imx_header_v2_t); + + if (imximage_init_loadsize < imximage_ivt_offset + imx_hdr_size) + imximage_init_loadsize = imximage_ivt_offset + imx_hdr_size; /* Set the imx header */ (*set_imx_hdr)(imxhdr, dcd_len, params->ep, imximage_ivt_offset); @@ -722,6 +723,7 @@ static int imximage_generate(struct image_tool_params *params, struct stat sbuf; char *datafile = params->datafile; uint32_t pad_len; + uint32_t imx_hdr_size; memset(&imximage_header, 0, sizeof(imximage_header)); @@ -739,16 +741,15 @@ static int imximage_generate(struct image_tool_params *params, /* Parse dcd configuration file */ parse_cfg_file(&imximage_header, params->imagename); - /* TODO: check i.MX image V1 handling, for now use 'old' style */ - if (imximage_version == IMXIMAGE_V1) { - alloc_len = 4096; - } else { - if (imximage_init_loadsize < imximage_ivt_offset + - sizeof(imx_header_v2_t)) - imximage_init_loadsize = imximage_ivt_offset + - sizeof(imx_header_v2_t); - alloc_len = imximage_init_loadsize - imximage_ivt_offset; - } + if (imximage_version == IMXIMAGE_V1) + imx_hdr_size = sizeof(imx_header_v1_t); + else + imx_hdr_size = sizeof(imx_header_v2_t); + + if (imximage_init_loadsize < imximage_ivt_offset + imx_hdr_size) + imximage_init_loadsize = imximage_ivt_offset + imx_hdr_size; + + alloc_len = imximage_init_loadsize - imximage_ivt_offset; if (alloc_len < sizeof(struct imx_header)) { fprintf(stderr, "%s: header error\n", @@ -779,11 +780,7 @@ static int imximage_generate(struct image_tool_params *params, pad_len = ROUND(sbuf.st_size, 4096) - sbuf.st_size; - /* TODO: check i.MX image V1 handling, for now use 'old' style */ - if (imximage_version == IMXIMAGE_V1) - return 0; - else - return pad_len; + return pad_len; } -- 1.7.10.4

2 6

[U-Boot] twister fails to start u-boot from NAND
by Jeroen Hofstee 27 Jan '17

27 Jan '17

Hi, I am facing some issues when booting u-boot (755b06d1c0f) from _NAND_ on a twister board. It works fine when booting from mmc. u-boot v2016.09 works fine from NAND as well. The first issue is that it hangs after DRAM initialization / before NAND is found. Git bisect points to 085be482f6 (ARM: revive CONFIG_USE_ARCH_MEMCPY/MEMSET for UniPhier and Tegra) and while reverting that patch makes the issue go away, it doesn't seem to me like the root cause. With the patch reverted, the board hangs after getting the first ethernet address from the i2c EEPROM. Disabling reading from the EEPROM, it reaches the prompt but every issued command cause a data abort. So clearly something is wrong, but I have no clue what at the moment. I guess the most likely area which could cause such an issue would be the spl NAND driver corrupting memory or something, since it is the main difference between booting from mmc vs NAND. However almost nothing has changed in that area since v2016.09... Perhaps stack usage is significantly higher in the NAND boot..? If someone has idea what could be wrong here, let me know. With kind regards, Jeroen to reproduce: --------------------------------------------------------------------------- arm-linux-gnueabi-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 # from sd-card env default -f -a fatload mmc 0 ${loadaddr} u-boot.img && run update fatload mmc 0 ${loadaddr} mlo && run updatemlo # remove sd-card / reboot

2 1

[U-Boot] rockchip: rk3288: Possible regression in sdram setup
by Romain Perier 27 Jan '17

27 Jan '17

Hello, I have a strange behaviour with the SPL on rk3288. When I build u-boot-rockchip master for the rock2 (rock2_defconfig), I can easily start u-boot SPL and u-boot from an sdcard (the emmc boot partition is erased so my board starts in maskrom mode by default) without any issues. Now, I load uboot SPL and uboot over usb: - I power up the board - I generate an image for the bootrom: # tools/mkimage -n rk3288 -T rkimage -d spl/u-boot-spl-dtb.bin out - I uploaded this image via usb to the board # cat out | openssl rc4 -K 7c4e0304550509072d2c7b38170d1711 | ../tools/rkflashtool/rkflashtool l I get no output from the SPL. I have investigated and found that it is caused by sdram_rk3288.c: sdram_init(). More especially by the function phy_pctrl_reset(). I enabled EARLY_UART and added 2 printascii() in this function. This functions hangs in the second for loop. I hacked this function locally, I reduce the number of iterations from 4 to 3 then I added 2 uart outputs to this function and "OH!": it works, I get the following output: pctrl_reset:for pctrl_reset:end for pctrl_reset:for pctrl_reset:end for U-Boot SPL 2016.11-08675-ga4ae4ddda3-dirty (Jan 06 2017 - 10:35:41) Now, if I remove my printascii() functions completly, it's no longer working. Which suggests that it might have something to do with busy wait delays... (I could be wrong) From the sdram setup point of view, I don't see a real difference between an SPL loaded from sdcard and an SPL loaded via usb. Rockchip guys: Would you have an idea about the problem ? Thanks, Regards, Romain

3 6

[U-Boot] i2c_set_bus_num freeze
by Ran Shalit 27 Jan '17

27 Jan '17

Hello, I have some issue in u-boot trying to access bus #1. I can access bus #0, #2 with i2c dev 0/2 I can also access bus #0,1,2 from linux. But on trying to access i2c #1 in u-boot in hangs: The function i2c_set_bus_num get stuck . ret = i2c_set_bus_num(1); <<------- never gets here ......... if (ret) printf("Failure changing bus number (%d)\n", ret); It hangs in i2c_set_bus_num->i2c_init-> ...... printf("i2c_init 8\n"); bus_initialized[current_bus] = 1; if (readw (I2C_CON) & I2C_CON_EN) { writew (0, I2C_CON); udelay (50000); } writew(psc, I2C_PSC); writew(scll, I2C_SCLL); writew(sclh, I2C_SCLH); /* own address */ writew (slaveadd, I2C_OA); writew (I2C_CON_EN, I2C_CON); printf("i2c_init 9\n"); <<------ never get printed .................. I have seen a similar question, yet I am doing this access after u-boot complete, and command prompt. Is anyone familiar with this ? Regards, Ran

4 7

[U-Boot] [PATCH v2 4/4] mmc: meson: add MMC support in Odroid C2 board init / config
by Heiner Kallweit 27 Jan '17

27 Jan '17

Add MMC support in Odroid C2 board init code and config. Signed-off-by: Heiner Kallweit <hkallweit1(a)gmail.com> --- v2: - move GXBB_PINMUX definition from patch 3 to this one --- arch/arm/include/asm/arch-meson/gxbb.h | 2 ++ board/amlogic/odroid-c2/odroid-c2.c | 27 +++++++++++++++++++++++++++ configs/odroid-c2_defconfig | 6 +++++- 3 files changed, 34 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/arch-meson/gxbb.h b/arch/arm/include/asm/arch-meson/gxbb.h index ce41349..af21222 100644 --- a/arch/arm/include/asm/arch-meson/gxbb.h +++ b/arch/arm/include/asm/arch-meson/gxbb.h @@ -20,6 +20,8 @@ #define GXBB_GPIO_IN(n) GXBB_PERIPHS_ADDR(_GXBB_GPIO_OFF(n) + 1) #define GXBB_GPIO_OUT(n) GXBB_PERIPHS_ADDR(_GXBB_GPIO_OFF(n) + 2) +#define GXBB_PINMUX(n) GXBB_PERIPHS_ADDR(0x2c + (n)) + #define GXBB_ETH_REG_0 GXBB_PERIPHS_ADDR(0x50) #define GXBB_ETH_REG_1 GXBB_PERIPHS_ADDR(0x51) diff --git a/board/amlogic/odroid-c2/odroid-c2.c b/board/amlogic/odroid-c2/odroid-c2.c index b61daaa..b559c71 100644 --- a/board/amlogic/odroid-c2/odroid-c2.c +++ b/board/amlogic/odroid-c2/odroid-c2.c @@ -8,6 +8,7 @@ #include <asm/io.h> #include <asm/arch/gxbb.h> #include <asm/arch/sm.h> +#include <asm/arch/sd_emmc.h> #include <dm/platdata.h> #include <phy.h> @@ -52,3 +53,29 @@ int misc_init_r(void) return 0; } + +static void meson_mmc_pinmux_setup(unsigned int port) +{ + switch (port) { + case SDIO_PORT_A: + setbits_le32(GXBB_PINMUX(8), 0x3f); + break; + case SDIO_PORT_B: + setbits_le32(GXBB_PINMUX(2), 0x3f << 10); + break; + case SDIO_PORT_C: + clrbits_le32(GXBB_PINMUX(2), 0x1f << 22); + setbits_le32(GXBB_PINMUX(4), (0x3 << 18) | (3 << 30)); + break; + default: + printf("meson: invalid MMC port %d for pinmux setup\n", port); + break; + } +} + +int board_mmc_init(bd_t *bis) +{ + meson_mmc_pinmux_setup(CONFIG_MMC_MESON_GX_SD_PORT); + + return 0; +} diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig index 7d0b2b1..b4e3277 100644 --- a/configs/odroid-c2_defconfig +++ b/configs/odroid-c2_defconfig @@ -3,7 +3,10 @@ CONFIG_ARCH_MESON=y CONFIG_MESON_GXBB=y CONFIG_TARGET_ODROID_C2=y CONFIG_IDENT_STRING=" odroid-c2" -# CONFIG_MMC is not set +CONFIG_MMC=y +CONFIG_DM_MMC=y +CONFIG_MMC_MESON_GX=y +CONFIG_MMC_MESON_GX_SD_PORT=1 CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2" # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set @@ -15,6 +18,7 @@ CONFIG_HUSH_PARSER=y # CONFIG_CMD_FPGA is not set # CONFIG_CMD_SOURCE is not set # CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_MMC=y CONFIG_OF_CONTROL=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM_ETH=y -- 2.11.0

2 2

[U-Boot] [PATCH v2 1/4] mmc: meson: add MMC nodes to Meson GXBB DT
by Heiner Kallweit 27 Jan '17

27 Jan '17

Copied from amlogic/meson-gx.dtsi on Linux with the interrupt definition removed. Signed-off-by: Heiner Kallweit <hkallweit1(a)gmail.com> --- v2: - no changes --- arch/arm/dts/meson-gxbb.dtsi | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/arch/arm/dts/meson-gxbb.dtsi b/arch/arm/dts/meson-gxbb.dtsi index e502c24..3f357b4 100644 --- a/arch/arm/dts/meson-gxbb.dtsi +++ b/arch/arm/dts/meson-gxbb.dtsi @@ -329,6 +329,24 @@ #address-cells = <2>; #size-cells = <2>; ranges = <0x0 0x0 0x0 0xd0000000 0x0 0x200000>; + + sd_emmc_a: mmc@70000 { + compatible = "amlogic,meson-gx-mmc", "amlogic,meson-gxbb-mmc"; + reg = <0x0 0x70000 0x0 0x2000>; + status = "disabled"; + }; + + sd_emmc_b: mmc@72000 { + compatible = "amlogic,meson-gx-mmc", "amlogic,meson-gxbb-mmc"; + reg = <0x0 0x72000 0x0 0x2000>; + status = "disabled"; + }; + + sd_emmc_c: mmc@74000 { + compatible = "amlogic,meson-gx-mmc", "amlogic,meson-gxbb-mmc"; + reg = <0x0 0x74000 0x0 0x2000>; + status = "disabled"; + }; }; ethmac: ethernet@c9410000 { -- 2.11.0

2 2

[U-Boot] [PATCH v7 0/7] arm: socfpga: update default u-boot environment
by Dalon Westergreen 27 Jan '17

27 Jan '17

From: Dalon Westergreen <dalon.westergreen(a)intel.com> These patches update the boot and os partition numbers in the default uboot environment for a number of socfpga boards. Per request, common environment configurations have been moved to a shared header. Changed in v7: Changed the bootloader partition to 3 to match the default layout for socfpga. commit 61520ac4d5545cc8d2e1792092e46ab8043d5f36 changed this to 1 which broke a number of socfpga kits. The default sdcard layour places partition 3 at the start of the fpga at +1MB. The partition is of type 0xA2. This is followed by partition 1 (FAT), and partition 2 (RootFS). Partition 1 should be the FAT partition or windows appears not to recognize the sdcard. Changed in v6: Changed CONFIG_SYS_MMCSD_FS_BOOT_PARTITION to be 1 for SPL_FAT and 2 for SPL_EXT support. I believe this is the original intent for whomever changed CONFIG_SYS_MMCSD_FS_BOOT_PARTITION to be 2. This allows us to keep the original sdcard layout and support FAT and EXT loading of the u-boot image Changes in v5: - Fixed sockit linux devicetree name - Changed default socfpga.dtb to match board name - sr1500 -> socfpga_cyclone5_sr1500.dtb - de1 -> socfpga_cyclone5_de1_soc.dtb Changes in v4: - Removed extraneous define in socfpga_common.h and only use CONFIG_EXTRA_ENV_SETTINGS for common uboot environment Changes in v3: - Corrected error in common default environment Dalon Westergreen (7): arm: socfpga: add env settings to common header arm: socfpga: update de0 nano default environment arm: socfpga: update cyclone5 socdk default environment arm: socfpga: update arria5 socdk default environment arm: socfpga: Update DE1 environment arm: socfpga: Update SoCKit environment arm: socfpga: Update sr1500 environment configs/socfpga_arria5_defconfig | 1 + configs/socfpga_cyclone5_defconfig | 1 + configs/socfpga_de0_nano_soc_defconfig | 3 +-- configs/socfpga_de1_soc_defconfig | 1 + configs/socfpga_sockit_defconfig | 1 + configs/socfpga_sr1500_defconfig | 1 + include/configs/socfpga_arria5_socdk.h | 25 ----------------------- include/configs/socfpga_common.h | 35 ++++++++++++++++++++++++++++++-- include/configs/socfpga_cyclone5_socdk.h | 25 ----------------------- include/configs/socfpga_de0_nano_soc.h | 19 +---------------- include/configs/socfpga_de1_soc.h | 19 +---------------- include/configs/socfpga_sockit.h | 27 +----------------------- include/configs/socfpga_sr1500.h | 25 ----------------------- 13 files changed, 42 insertions(+), 141 deletions(-) -- 2.7.4

2 14

[U-Boot] [PATCH] pci: don't skip vendor ID 0
by Gregory Fong 27 Jan '17

27 Jan '17

Unlike 0xffff, 0 is not an invalid vendor ID. Signed-off-by: Gregory Fong <gregory.fong(a)virgingalactic.com> --- Based on question initially asked here: http://lists.denx.de/pipermail/u-boot/2016-December/276172.html I've been looking through the book I have on PCI and through various online resources, and haven't been able to find evidence that a vendor ID of 0 is invalid, even if it's unusual. There are still issues in how this will be handled in e.g. drivers/pci/pci_common.c because pci_hose_find_devices() still assumes that a vendor and device ID of 0 mean that the last pci_device_id is reached, but this change at least allows the device's PCI BARs to get programmed if the vendor ID is 0. drivers/pci/pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 6b36c18..3ee7180 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -366,7 +366,7 @@ int pci_hose_scan_bus(struct pci_controller *hose, int bus) pci_hose_read_config_word(hose, dev, PCI_VENDOR_ID, &vendor); - if (vendor == 0xffff || vendor == 0x0000) + if (vendor == 0xffff) continue; if (!PCI_FUNC(dev)) -- 1.9.1

4 7

[U-Boot] Pull request: u-boot-ubi/master
by Heiko Schocher 27 Jan '17

27 Jan '17

Hello Tom, please pull from u-boot-ubi.git master The following changes since commit 79a34b71c943a80af5c6d9a2af736fbb37dcc14c: Merge git://git.denx.de/u-boot-mpc85xx (2017-01-25 17:38:45 -0500) are available in the git repository at: git://git.denx.de/u-boot-ubi.git master for you to fetch changes up to f59f07ece5ec78a8fc2f0e06a80ff66029002629: cmd: ubi: allow '-' to specify maximum volume size (2017-01-26 07:00:25 +0100) ---------------------------------------------------------------- Ladislav Michl (1): cmd: ubi: allow '-' to specify maximum volume size cmd/ubi.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

2 1

[U-Boot] Please pull u-boot-marvell/master
by Stefan Roese 27 Jan '17

27 Jan '17

Hi Tom, please pull the following MVEBU related patches, mostly dealing with adding support for the Xenon SDHCI driver available on the A7k/8k SoCs. I've collected the Reviewed-by from Jaehoon for these mmc patches. Thanks, Stefan The following changes since commit f2b0c007f84e582b7a101bd49db60cc8d75f5de4: travis-ci: Add swig and libpython-dev to the package list (2017-01-24 10:35:57 -0500) are available in the git repository at: git://www.denx.de/git/u-boot-marvell.git for you to fetch changes up to e559ef1ae80c1bde942ad9c62932de20e2b68cef: arm64: mvebu: Update bubt command MMC block device access (2017-01-25 07:04:22 +0100) ---------------------------------------------------------------- Konstantin Porotchkin (1): arm64: mvebu: Update bubt command MMC block device access Stefan Roese (9): mmc: sdhci: Clear SDHCI_CLOCK_CONTROL before configuring the new value mmc: sdhci: Add support for optional controller specific set_ios_post() mmc: Add Marvell Xenon SDHCI controller driver arm64: mvebu: Armada 3700: Add SDHCI device tree nodes arm64: mvebu: Armada 3720-db: Add SDHCI device tree nodes arm64: mvebu: Enable SDHCI/MMC support for the db-88f3720 arm64: mvebu: Armada 7k/8k: Add SDHCI device tree nodes arm64: mvebu: Armada 7040-db: Add SDHCI device tree nodes arm64: mvebu: Enable SDHCI/MMC support for the db-88f7040/8040 arch/arm/dts/armada-3720-db.dts | 21 ++ arch/arm/dts/armada-37xx.dtsi | 16 ++ arch/arm/dts/armada-7040-db.dts | 14 + arch/arm/dts/armada-ap806.dtsi | 8 + arch/arm/dts/armada-cp110-master.dtsi | 8 + cmd/mvebu/bubt.c | 25 +- configs/mvebu_db-88f3720_defconfig | 6 +- configs/mvebu_db-88f7040_defconfig | 5 +- configs/mvebu_db-88f8040_defconfig | 5 +- drivers/mmc/Kconfig | 11 + drivers/mmc/Makefile | 1 + drivers/mmc/sdhci.c | 10 +- drivers/mmc/xenon_sdhci.c | 497 ++++++++++++++++++++++++++++++++++ include/configs/mvebu_armada-8k.h | 3 + include/configs/mvebu_db-88f3720.h | 3 + include/sdhci.h | 1 + 16 files changed, 624 insertions(+), 10 deletions(-) create mode 100644 drivers/mmc/xenon_sdhci.c

2 1