June 2016 - U-Boot

[U-Boot] [PATCH 1/4] mx7dsabresd: Fix LCD_PWR_EN output setting
by Peng Fan 18 Jun '16

18 Jun '16

From: Ye Li <ye.li(a)nxp.com> LCD_PWR_EN controls the G pin of Q13 PMOS which needs low voltage to connect D to S for outputting LCD 3.3V. If LCD_PWR_EN is high, we measured the LCD 3v3 is actually 1.2V. Signed-off-by: Ye Li <ye.li(a)nxp.com> Signed-off-by: Peng Fan <peng.fan(a)nxp.com> Cc: Stefano Babic <sbabic(a)denx.de> Cc: Fabio Estevam <fabio.estevam(a)nxp.com> --- board/freescale/mx7dsabresd/mx7dsabresd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c b/board/freescale/mx7dsabresd/mx7dsabresd.c index c3062f1..1f4fc03 100644 --- a/board/freescale/mx7dsabresd/mx7dsabresd.c +++ b/board/freescale/mx7dsabresd/mx7dsabresd.c @@ -171,7 +171,7 @@ static enum qn_level seq[3][2] = { static enum qn_func qn_output[8] = { qn_disable, qn_reset, qn_reset, qn_reset, qn_reset, qn_reset, qn_enable, - qn_enable + qn_disable }; static void iox74lv_init(void) -- 2.6.2

3 8

[U-Boot] [PATCH] mx6sabresd: Allow LVDS backlight to be functional after a kernel reboot
by Marco Franchi 18 Jun '16

18 Jun '16

Currently the LVDS backlight does not work in U-Boot after a “reboot” comand in the kernel. This problem occurs because the kernel uses this pin in PWM mode and U-Boot does not configure the backlight pin as GPIO functionality. So fix the problem by explicitly configuring the backlight pin as GPIO in U-Boot. Signed-off-by: Marco Franchi <marco.franchi(a)nxp.com> --- board/freescale/mx6sabresd/mx6sabresd.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/board/freescale/mx6sabresd/mx6sabresd.c b/board/freescale/mx6sabresd/mx6sabresd.c index 54ba36b..28c969d 100644 --- a/board/freescale/mx6sabresd/mx6sabresd.c +++ b/board/freescale/mx6sabresd/mx6sabresd.c @@ -177,13 +177,27 @@ static iomux_v3_cfg_t const rgb_pads[] = { MX6_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 | MUX_PAD_CTRL(NO_PAD_CTRL), MX6_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 | MUX_PAD_CTRL(NO_PAD_CTRL), MX6_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 | MUX_PAD_CTRL(NO_PAD_CTRL), +}; + +static iomux_v3_cfg_t const bl_pads[] = { MX6_PAD_SD1_DAT3__GPIO1_IO21 | MUX_PAD_CTRL(NO_PAD_CTRL), }; +static void enable_backlight(void) +{ + imx_iomux_v3_setup_multiple_pads(bl_pads, ARRAY_SIZE(bl_pads)); + gpio_direction_output(DISP0_PWR_EN, 1); +} + static void enable_rgb(struct display_info_t const *dev) { imx_iomux_v3_setup_multiple_pads(rgb_pads, ARRAY_SIZE(rgb_pads)); - gpio_direction_output(DISP0_PWR_EN, 1); + enable_backlight(); +} + +static void enable_lvds(struct display_info_t const *dev) +{ + enable_backlight(); } static struct i2c_pads_info i2c_pad_info1 = { @@ -370,7 +384,7 @@ struct display_info_t const displays[] = {{ .addr = 0, .pixfmt = IPU_PIX_FMT_RGB666, .detect = NULL, - .enable = NULL, + .enable = enable_lvds, .mode = { .name = "Hannstar-XGA", .refresh = 60, -- 2.7.4

3 3

[U-Boot] [PATCH] cmd: usb: check if_type before using this device
by Peng Fan 18 Jun '16

18 Jun '16

For legacy usb storage driver, USB_MAX_STOR_DEV is defined as 7. If we only have one usb disk on board, `usb dev 0` is ok. But if `usb dev 1`, still ok, then `usb read xxx` will trigger system fault and reboot. So check if_type before using this device. Signed-off-by: Peng Fan <peng.fan(a)nxp.com> Cc: Simon Glass <sjg(a)chromium.org> Cc: Hans de Goede <hdegoede(a)redhat.com> Cc: Bin Meng <bmeng.cn(a)gmail.com> Cc: Marek Vasut <marex(a)denx.de> Cc: Stefan Roese <sr(a)denx.de> Cc: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> Cc: Peng Fan <peng.fan(a)nxp.com> Cc: Stephen Warren <swarren(a)nvidia.com> --- cmd/usb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/cmd/usb.c b/cmd/usb.c index b83d323..58d9db2 100644 --- a/cmd/usb.c +++ b/cmd/usb.c @@ -800,7 +800,8 @@ static int do_usb(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) int dev = (int)simple_strtoul(argv[2], NULL, 10); printf("\nUSB device %d: ", dev); stor_dev = blk_get_devnum_by_type(IF_TYPE_USB, dev); - if (stor_dev == NULL) { + if ((stor_dev == NULL) || + (stor_dev->if_type == IF_TYPE_UNKNOWN)) { printf("unknown device\n"); return 1; } -- 2.6.2

3 2

[U-Boot] [PATCH] usb: ehci: only shutdown opened controller
by Peng Fan 18 Jun '16

18 Jun '16

If the usb controller is not running, no need to shutdown it, otherwise `usb stop` complains about: "EHCI failed to shut down host controller". To i.MX7D SDB, there are two usb ports, one Host, one OTG. If we only plug one udisk to the Host port and then `usb start`, the OTG controller for OTG port does not run actually. Then, if `usb stop`, the OTG controller for OTG port will also be shutdown, but it is not running. This patch adds a check to only shutdown the running controller. Signed-off-by: Peng Fan <peng.fan(a)nxp.com> Cc: Marek Vasut <marex(a)denx.de> Cc: Simon Glass <sjg(a)chromium.org> Cc: Mateusz Kulikowski <mateusz.kulikowski(a)gmail.com> Cc: Hans de Goede <hdegoede(a)redhat.com> Cc: "Stefan Brüns" <stefan.bruens(a)rwth-aachen.de> Cc: Stephen Warren <swarren(a)nvidia.com> --- drivers/usb/host/ehci-hcd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index fa5d584..13aa70d 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -210,6 +210,9 @@ static int ehci_shutdown(struct ehci_ctrl *ctrl) return -EINVAL; cmd = ehci_readl(&ctrl->hcor->or_usbcmd); + /* If not run, directly return */ + if (!(cmd & CMD_RUN)) + return 0; cmd &= ~(CMD_PSE | CMD_ASE); ehci_writel(&ctrl->hcor->or_usbcmd, cmd); ret = handshake(&ctrl->hcor->or_usbsts, STS_ASS | STS_PSS, 0, -- 2.6.2

2 2

[U-Boot] [PATCH] drivers: usb: fsl: Fix NULL terminating issue for usb controller name string
by Rajesh Bhagat 17 Jun '16

17 Jun '16

Fixes NULL terminating issue for usb controller name string and performs code cleanup for intializing variables current_usb_controller and usb_phy. Signed-off-by: Rajesh Bhagat <rajesh.bhagat(a)nxp.com> --- drivers/usb/host/ehci-fsl.c | 10 ++++------ 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c index a43d37d..a806993 100644 --- a/drivers/usb/host/ehci-fsl.c +++ b/drivers/usb/host/ehci-fsl.c @@ -49,11 +49,9 @@ int ehci_hcd_init(int index, enum usb_init_type init, struct usb_ehci *ehci = NULL; const char *phy_type = NULL; size_t len; - char current_usb_controller[5]; + char current_usb_controller[5] = {0}; #ifdef CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY - char usb_phy[5]; - - usb_phy[0] = '\0'; + char usb_phy[5] = {0}; #endif if (has_erratum_a007075()) { /* @@ -64,8 +62,8 @@ int ehci_hcd_init(int index, enum usb_init_type init, */ mdelay(5); } - memset(current_usb_controller, '\0', 5); - snprintf(current_usb_controller, 4, "usb%d", index+1); + snprintf(current_usb_controller, sizeof(current_usb_controller), + "usb%d", index+1); switch (index) { case 0: -- 1.7.7.4

2 7

[U-Boot] [PATCH] SPL ext: cosmetic: correct error message in spl_load_image_ext()
by Petr Kulhavy 17 Jun '16

17 Jun '16

Correct the error message in spl_load_image_ext() when image parsing fails. Instead of "ext4fs_read failed" print "failed to parse image header". Signed-off-by: Petr Kulhavy <brain(a)jikos.cz> CC: Guillaume GARDET <guillaume.gardet(a)free.fr> --- common/spl/spl_ext.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/spl/spl_ext.c b/common/spl/spl_ext.c index ade5496..074b31e 100644 --- a/common/spl/spl_ext.c +++ b/common/spl/spl_ext.c @@ -50,7 +50,7 @@ int spl_load_image_ext(struct blk_desc *block_dev, err = spl_parse_image_header(header); if (err < 0) { - puts("spl: ext4fs_read failed\n"); + puts("spl: failed to parse image header\n"); goto end; } -- 2.5.0

3 2

[U-Boot] [RFC] x86: baytrail: azalia DT configuration mock-up
by George McCollister 17 Jun '16

17 Jun '16

I'm looking for feedback on this mock-up of fsp,azalia-config DT before I proceed to writing code. I included everything in fsp for context. fsp { compatible = "intel,baytrail-fsp"; fsp,mrc-init-tseg-size = <0>; fsp,mrc-init-mmio-size = <0x800>; fsp,mrc-init-spd-addr1 = <0xa0>; fsp,mrc-init-spd-addr2 = <0xa2>; fsp,emmc-boot-mode = <2>; fsp,enable-sdio; fsp,enable-sdcard; fsp,enable-hsuart1; fsp,enable-spi; fsp,enable-sata; fsp,sata-mode = <1>; fsp,enable-azalia; fsp,azalia-config { compatible = "intel,baytrail-fsp-azalia-config"; fsp,pme-enable = <1>; fsp,docking-supported = <1>; fsp,docking-attached = <0>; fsp,hdmi-codec-enable = <1>; fsp,azalia-v-ci-enable = <1>; fsp,rsvdbits = <0>; fsp,reset-wait-timer-us = <300>; alc262 { compatible = "fsp,azalia-verb-table"; fsp,vendor-device-id = <0x10ec0262>; fsp,sub-system-id = <0>; fsp,revision-id = <0xff>; fsp,front-panel-support = <1>; fsp,number-of-rear-jacks = <11>; fsp,number-of-front-jacks = <2>; fsp,verb-table-data = < /* Pin Complex (NID 0x11) */ 0x01171cf0 0x01171d11 0x01171e11 0x01171f41 /* Pin Complex (NID 0x12) */ 0x01271cf0 0x01271d11 0x01271e11 0x01271f41 /* Pin Complex (NID 0x14) */ 0x01471c10 0x01471d40 0x01471e01 0x01471f01 /* Pin Complex (NID 0x15) */ 0x01571cf0 0x01571d11 0x01571e11 0x01571f41 /* Pin Complex (NID 0x16) */ 0x01671cf0 0x01671d11 0x01671e11 0x01671f41 /* Pin Complex (NID 0x18) */ 0x01871c20 0x01871d98 0x01871ea1 0x01871f01 /* Pin Complex (NID 0x19) */ 0x01971c21 0x01971d98 0x01971ea1 0x01971f02 /* Pin Complex (NID 0x1A) */ 0x01a71c2f 0x01a71d30 0x01a71e81 0x01a71f01 /* Pin Complex */ 0x01b71c1f 0x01b71d40 0x01b71e21 0x01b71f02 /* Pin Complex */ 0x01c71cf0 0x01c71d11 0x01c71e11 0x01c71f41 /* Pin Complex */ 0x01d71c01 0x01d71dc6 0x01d71e14 0x01d71f40 /* Pin Complex */ 0x01e71cf0 0x01e71d11 0x01e71e11 0x01e71f41 /* Pin Complex */ 0x01f71cf0 0x01f71d11 0x01f71e11 0x01f71f41 >; }; }; fsp,lpss-sio-enable-pci-mode; fsp,enable-dma0; fsp,enable-dma1; fsp,enable-i2c0; fsp,enable-i2c1; fsp,enable-i2c2; fsp,enable-i2c3; fsp,enable-i2c4; fsp,enable-i2c5; fsp,enable-i2c6; fsp,enable-pwm0; fsp,enable-pwm1; fsp,igd-dvmt50-pre-alloc = <2>; fsp,aperture-size = <2>; fsp,gtt-size = <2>; fsp,serial-debug-port-address = <0x3f8>; fsp,serial-debug-port-type = <1>; fsp,scc-enable-pci-mode; fsp,os-selection = <4>; fsp,emmc45-ddr50-enabled; fsp,emmc45-retune-timer-value = <8>; fsp,enable-igd; fsp,enable-memory-down; fsp,memory-down-params { compatible = "intel,baytrail-fsp-mdp"; fsp,dram-speed = <1>; fsp,dram-type = <1>; fsp,dimm-0-enable; fsp,dimm-width = <1>; fsp,dimm-density = <2>; fsp,dimm-bus-width = <3>; fsp,dimm-sides = <0>; fsp,dimm-tcl = <0xb>; fsp,dimm-trpt-rcd = <0xb>; fsp,dimm-twr = <0xc>; fsp,dimm-twtr = <6>; fsp,dimm-trrd = <6>; fsp,dimm-trtp = <6>; fsp,dimm-tfaw = <0x14>; }; }; Thanks, George McCollister

2 6

[U-Boot] MPC8347 Initial Boot problems
by Gardner, Austin (GE Transportation) 17 Jun '16

17 Jun '16

Hello, I am currently trying to get my MPC8347EA board up and running by porting the MPC8349EMDS configuration that is currently available. This is my first time working with uboot, so naturally I am having some issues. My issue is that I can't get any response from the board after we flash it with the binary image. I don't know if I am flashing it in the wrong location, or if it is because the configurations in the header files that I changed are wrong. I have tried flashing it in various locations such as start of memory, CONFIG_SYS_TEXT_BASE location (changed to our needs of 0xFF8000000), etc. I also have changed a lot of the memory configurations from the MPC8349EMDS such as the timing configs, ddrlawbar and ddrlawar, sdram configs and modes, etc. After getting the uboot to actually launch to a command line, the next step will be to have it launch to our QNX os. Any help with this would be greatly appreciated. I apologize if I use the wrong terminology at any point, I am still very new to this. Thanks, Austin

1 0

[U-Boot] RFC, dm: devices and device_info platdata manual relocation
by Angelo Dureghello 17 Jun '16

17 Jun '16

Hi all, i have seen, updating u-boot in NOR parallel flash, that the U_BOOT_DEVICE structure "platdata" ptr is still pointing to flash, so the update (rewriting flash) die silently and fails. I have found a workaround using misc_init_r that works in my board.c, as below, but i don't like too much the solution: ... #include <dm/platform_data/serial_coldfire.h> ... DECLARE_GLOBAL_DATA_PTR; .... int misc_init_r(void) { /* * FIXME: relocation seems not working properly on m68k, * so relocating manually */ struct udevice *dev; int retval; printf("misc_init_r(): entering\n"); retval = uclass_find_device(UCLASS_SERIAL, 0, &dev); if (!retval) { printf("misc_init_r(): relocating serial device\n"); dev->platdata += gd->reloc_off; } return 0; } static struct coldfire_serial_platdata mcf5307_serial_plat = { .base = CONFIG_SYS_UART_BASE, .port = 0, .baudrate = CONFIG_BAUDRATE, }; U_BOOT_DEVICE(coldfire_serial) = { .name = "serial_coldfire", .platdata = &mcf5307_serial_plat, }; So, i can keep this changes in my board, but, i am wondering if manual-reloc of devices structures is maybe responsibility of drivers/core/root.c, something like int dm_init(void) { ..... #if defined(CONFIG_NEEDS_MANUAL_RELOC) fix_drivers(); fix_uclass(); fix_devices(); <------------- #endif ..... Every comment is welcome. Regards, Angelo Dureghello

2 2

[U-Boot] U-boot Minnowmax Turbot SPI flash time
by vinoth eswaran 17 Jun '16

17 Jun '16

Hello Mr.Bin, In the file minnowmax_defconfig for SPI flash I am seeing many configurations getting enabled, CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y Do we need all the configurations and also I have seen a patch regarding this but not included in the mainline, http://lists.denx.de/pipermail/u-boot/2015-November/235822.html For Minnowmax Turbot , can I use only the following configuration? CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y Mit Freundlichen Grüßen VinothKumar +49 1798909072

2 3