January 2016 - U-Boot

[U-Boot] [PATCH v2 00/15] Add Support for Secure Boot on LS208x
by Saksham Jain 28 Jan '16

28 Jan '16

Secure Boot ESBC has been enabled on FSL LS208x platforms. This patchset is dependent on http://patchwork.ozlabs.org/patch/571612/ Changes for v2: - changed function fsl_secboot_validate to return address of image - corrected Bootscript header for ls1043 and ls1021 Saksham Jain (15): armv8: ls2080: Add SFP Configs for LS2080/LS2085 armv8: ls2080: Add Secure Boot configs: SEC, Security Monitor, SRK and RCW SECURE BOOT: Add new ESBC header for ls-ch3 Secure Boot SECURE BOOT: Add Secure Boot support on ls2080aqds/rdb armv8: fsl-lsch3: Add bootscript header address for Secure Boot SECURE BOOT: Copy Bootscript and header from NOR to DDR for LS2080/5 SECURE BOOT: Change env variable "fdt_high" for LS2080a and LS2085a armv8 : ls2080: Add config for endianess of CCSR GUR armv8: fsl-lsch3: Disable SMMU during Secure Boot crypto/fsl: Correct 64bit Write when MMU disabled crypto/fsl: Make CAAM transactions cacheable SECURE_BOOT: Use default bootargs during Secure Boot SECURE BOOT: Halt execution when secure boot fail after reset request SECURE BOOT: Change fsl_secboot_validate function to output image addr SECURE_BOOT: Enable IE (Key extention) Feature in Ls2085a & LS2088a arch/arm/cpu/armv8/fsl-layerscape/soc.c | 18 ++- arch/arm/include/asm/arch-fsl-layerscape/config.h | 18 +++ .../include/asm/arch-fsl-layerscape/immap_lsch3.h | 28 ++++ arch/arm/include/asm/fsl_secure_boot.h | 50 ++++++- board/freescale/common/cmd_esbc_validate.c | 14 +- board/freescale/common/fsl_validate.c | 157 +++++++++++++++++---- board/freescale/ls2080aqds/ls2080aqds.c | 5 +- board/freescale/ls2080ardb/ls2080ardb.c | 5 +- configs/ls2080aqds_SECURE_BOOT_defconfig | 15 ++ configs/ls2080ardb_SECURE_BOOT_defconfig | 15 ++ configs/ls2085aqds_SECURE_BOOT_defconfig | 15 ++ configs/ls2085ardb_SECURE_BOOT_defconfig | 15 ++ drivers/crypto/fsl/desc_constr.h | 7 +- drivers/crypto/fsl/jr.c | 13 ++ drivers/crypto/fsl/jr.h | 3 + include/config_fsl_chain_trust.h | 25 ++-- include/configs/ls2080aqds.h | 2 + include/configs/ls2080ardb.h | 2 + include/fsl_secboot_err.h | 3 + include/fsl_sfp.h | 3 +- include/fsl_validate.h | 88 ++++++++++-- 21 files changed, 438 insertions(+), 63 deletions(-) create mode 100644 configs/ls2080aqds_SECURE_BOOT_defconfig create mode 100644 configs/ls2080ardb_SECURE_BOOT_defconfig create mode 100644 configs/ls2085aqds_SECURE_BOOT_defconfig create mode 100644 configs/ls2085ardb_SECURE_BOOT_defconfig -- 1.8.1.4

1 0

[U-Boot] [PATCH] pci: gate print info of reading vender id with CONFIG_DM_PCI
by Gong Qianyu 28 Jan '16

28 Jan '16

From: Mingkai Hu <Mingkai.Hu(a)freescale.com> Referring to 'commit ff3e077bd23c ("dm: pci: Add a uclass for PCI")'. For legacy PCIe driver, it needs loop to read the vender_id from devie 0 to devie 255 to check if there is device available. Reading non-existen device will trigger the "Cannot read bus configuration: -1" information. Signed-off-by: Mingkai Hu <Mingkai.Hu(a)freescale.com> Signed-off-by: Gong Qianyu <Qianyu.Gong(a)nxp.com> --- common/cmd_pci.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/common/cmd_pci.c b/common/cmd_pci.c index 4e0951f..d94f90d 100644 --- a/common/cmd_pci.c +++ b/common/cmd_pci.c @@ -324,7 +324,9 @@ void pciinfo(int bus_num, int short_pci_listing) unsigned char header_type; unsigned short vendor_id; pci_dev_t dev; +#ifdef CONFIG_DM_PCI int ret; +#endif if (!hose) return; @@ -348,10 +350,14 @@ void pciinfo(int bus_num, int short_pci_listing) if (pci_skip_dev(hose, dev)) continue; +#ifdef CONFIG_DM_PCI ret = pci_read_config_word(dev, PCI_VENDOR_ID, &vendor_id); if (ret) goto error; +#else + pci_read_config_word(dev, PCI_VENDOR_ID, &vendor_id); +#endif if ((vendor_id == 0xFFFF) || (vendor_id == 0x0000)) continue; @@ -373,8 +379,10 @@ void pciinfo(int bus_num, int short_pci_listing) } return; +#ifdef CONFIG_DM_PCI error: printf("Cannot read bus configuration: %d\n", ret); +#endif } #endif -- 2.1.0.27.g96db324

3 4

[U-Boot] [PATCH V2 1/3] imx: mx7dsabresd: move mmc_get_env_devno to soc code
by Peng Fan 28 Jan '16

28 Jan '16

From: Peng Fan <peng.fan(a)nxp.com> Move mmc_get_env_devno to soc.c and rename to mmc_get_env_dev to match the one in common/env_mmc.c. Introduce a weak function board_mmc_get_env_dev. Different boards can implement this according to sdhc controller which is used by the board. Signed-off-by: Peng Fan <peng.fan(a)nxp.com> Cc: Stefano Babic <sbabic(a)denx.de> --- V2: Use CONFIG_ENV_IS_IN_MMC to wrap soc code. Since mmc_get_env_dev already upstreamed by this commit: " commit e92029c0f4e88ae3e738d83b25ef2d3c178ea082 Author: Clemens Gruber <clemens.gruber(a)pqgruber.com> Date: Wed Jan 20 15:43:37 2016 +0100 env_mmc: support overriding mmc dev from board code " I discard the V1 2/4 patch in my patch set. This patch set depends on https://patchwork.ozlabs.org/patch/573336/ arch/arm/cpu/armv7/mx7/soc.c | 21 +++++++++++++++++++++ board/freescale/mx7dsabresd/mx7dsabresd.c | 20 +++++--------------- 2 files changed, 26 insertions(+), 15 deletions(-) diff --git a/arch/arm/cpu/armv7/mx7/soc.c b/arch/arm/cpu/armv7/mx7/soc.c index ede7d53..ba6cfb9 100644 --- a/arch/arm/cpu/armv7/mx7/soc.c +++ b/arch/arm/cpu/armv7/mx7/soc.c @@ -388,6 +388,27 @@ enum boot_device get_boot_device(void) return boot_dev; } +#ifdef CONFIG_ENV_IS_IN_MMC +__weak int board_mmc_get_env_dev(int devno) +{ + return CONFIG_SYS_MMC_ENV_DEV; +} + +int mmc_get_env_dev(void) +{ + struct bootrom_sw_info **p = + (struct bootrom_sw_info **)ROM_SW_INFO_ADDR; + int devno = (*p)->boot_dev_instance; + u8 boot_type = (*p)->boot_dev_type; + + /* If not boot from sd/mmc, use default value */ + if ((boot_type != BOOT_TYPE_SD) && (boot_type != BOOT_TYPE_MMC)) + return CONFIG_SYS_MMC_ENV_DEV; + + return board_mmc_get_env_dev(devno); +} +#endif + void s_init(void) { #if !defined CONFIG_SPL_BUILD diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c b/board/freescale/mx7dsabresd/mx7dsabresd.c index bbcc5bb..20e56f2 100644 --- a/board/freescale/mx7dsabresd/mx7dsabresd.c +++ b/board/freescale/mx7dsabresd/mx7dsabresd.c @@ -328,22 +328,12 @@ static struct fsl_esdhc_cfg usdhc_cfg[3] = { {USDHC3_BASE_ADDR}, }; -static int mmc_get_env_devno(void) +int board_mmc_get_env_dev(int devno) { - struct bootrom_sw_info **p = - (struct bootrom_sw_info **)ROM_SW_INFO_ADDR; + if (devno == 2) + devno--; - u8 boot_type = (*p)->boot_dev_type; - u8 dev_no = (*p)->boot_dev_instance; - - /* If not boot from sd/mmc, use default value */ - if ((boot_type != BOOT_TYPE_SD) && (boot_type != BOOT_TYPE_MMC)) - return CONFIG_SYS_MMC_ENV_DEV; - - if (dev_no == 2) - dev_no--; - - return dev_no; + return devno; } static int mmc_map_to_kernel_blk(int dev_no) @@ -432,7 +422,7 @@ static void mmc_late_init(void) { char cmd[32]; char mmcblk[32]; - u32 dev_no = mmc_get_env_devno(); + u32 dev_no = mmc_get_env_dev(); if (!check_mmc_autodetect()) return; -- 2.6.2

1 2

[U-Boot] patman dies cryptially when a (valid) e-mail address contains parentheses (or is UTF-8)
by Albert ARIBAUD 28 Jan '16

28 Jan '16

Hello Simon, I just noticed this while adding a Series-cc to my work address which has parentheses: running patman (without -n) will result in sh: 1: Syntax error: "(" unexpected Which initially left me wondering what was happening until I realized one of the Series-cc addresses had parentheses, e.g. Series-cc: "Name NAME (NAME)" <address(a)domain.tld> Note that the parentheses were in the free-form part of the address, itself within double quotation marks, which appears valid wrt the RFC. I've tried using single quotes as a workaround: Series-cc: 'Name NAME (NAME)' <address(a)domain.tld> It kind-of-works in that patman does not die, but the resulting address in the mail has outer double quotes and inner single quotes, e.g. "'Name NAME (NAME)'" <address(a)domain.tld> Aditionally, addresses with names in UTF-8 also fail, though differently but still with a message somewhat unrelated to the actual cause (UTF-8-name is the placeholder for a name containing UTF-8 diacritics): fatal: ambiguous argument 'UTF-8-name <addres(a)domain.tld>': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' The same single-quote hack works it around, with the resulting mail Cc:ing the name surrounded by single quotes only: Cc: 'UTF-8-name' <addres(a)domain.tld> Cc:ing Marek who is a die-hard fan of UTF-8 names in e-mail addresses. :) Amicalement, -- Albert.

2 2

[U-Boot] [PATCH] x86: Correct spi node alias
by Bin Meng 28 Jan '16

28 Jan '16

With recent changes spi node was moved to a place as a subnode under pch, so update the alias to refer to its correct place as well. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- arch/x86/dts/bayleybay.dts | 4 ++-- arch/x86/dts/broadwell_som-6896.dts | 4 ++-- arch/x86/dts/chromebook_link.dts | 4 ++-- arch/x86/dts/chromebox_panther.dts | 4 ++-- arch/x86/dts/crownbay.dts | 4 ++-- arch/x86/dts/galileo.dts | 4 ++-- arch/x86/dts/minnowmax.dts | 4 ++-- 7 files changed, 14 insertions(+), 14 deletions(-) diff --git a/arch/x86/dts/bayleybay.dts b/arch/x86/dts/bayleybay.dts index 9bf707b..fbca467 100644 --- a/arch/x86/dts/bayleybay.dts +++ b/arch/x86/dts/bayleybay.dts @@ -21,7 +21,7 @@ aliases { serial0 = &serial; - spi0 = "/spi"; + spi0 = &spi; }; config { @@ -184,7 +184,7 @@ >; }; - spi { + spi: spi { #address-cells = <1>; #size-cells = <0>; compatible = "intel,ich-spi"; diff --git a/arch/x86/dts/broadwell_som-6896.dts b/arch/x86/dts/broadwell_som-6896.dts index 4e9e410..7b2c515 100644 --- a/arch/x86/dts/broadwell_som-6896.dts +++ b/arch/x86/dts/broadwell_som-6896.dts @@ -10,7 +10,7 @@ compatible = "advantech,som-6896", "intel,broadwell"; aliases { - spi0 = "/spi"; + spi0 = &spi; }; config { @@ -34,7 +34,7 @@ reg = <0x0000f800 0 0 0 0>; compatible = "intel,pch9"; - spi { + spi: spi { #address-cells = <1>; #size-cells = <0>; compatible = "intel,ich-spi"; diff --git a/arch/x86/dts/chromebook_link.dts b/arch/x86/dts/chromebook_link.dts index d148d6e..5807203 100644 --- a/arch/x86/dts/chromebook_link.dts +++ b/arch/x86/dts/chromebook_link.dts @@ -11,7 +11,7 @@ compatible = "google,link", "intel,celeron-ivybridge"; aliases { - spi0 = "/pci/pch/spi"; + spi0 = &spi; usb0 = &usb_0; usb1 = &usb_1; }; @@ -252,7 +252,7 @@ /* Enable EC SMI source */ intel,alt-gp-smi-enable = <0x0100>; - spi { + spi: spi { #address-cells = <1>; #size-cells = <0>; compatible = "intel,ich-spi"; diff --git a/arch/x86/dts/chromebox_panther.dts b/arch/x86/dts/chromebox_panther.dts index 2302701..48f0c77 100644 --- a/arch/x86/dts/chromebox_panther.dts +++ b/arch/x86/dts/chromebox_panther.dts @@ -10,7 +10,7 @@ compatible = "google,panther", "intel,haswell"; aliases { - spi0 = "/spi"; + spi0 = &spi; }; config { @@ -56,7 +56,7 @@ reg = <0x0000f800 0 0 0 0>; compatible = "intel,pch9"; - spi { + spi: spi { #address-cells = <1>; #size-cells = <0>; compatible = "intel,ich-spi"; diff --git a/arch/x86/dts/crownbay.dts b/arch/x86/dts/crownbay.dts index d6dd0b4..47fab0f 100644 --- a/arch/x86/dts/crownbay.dts +++ b/arch/x86/dts/crownbay.dts @@ -19,7 +19,7 @@ compatible = "intel,crownbay", "intel,queensbay"; aliases { - spi0 = "/spi"; + spi0 = &spi; }; config { @@ -227,7 +227,7 @@ >; }; - spi { + spi: spi { #address-cells = <1>; #size-cells = <0>; compatible = "intel,ich-spi"; diff --git a/arch/x86/dts/galileo.dts b/arch/x86/dts/galileo.dts index a2f5a1f..dd75fc4 100644 --- a/arch/x86/dts/galileo.dts +++ b/arch/x86/dts/galileo.dts @@ -18,7 +18,7 @@ compatible = "intel,galileo", "intel,quark"; aliases { - spi0 = "/spi"; + spi0 = &spi; }; config { @@ -115,7 +115,7 @@ >; }; - spi { + spi: spi { #address-cells = <1>; #size-cells = <0>; compatible = "intel,ich-spi"; diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts index e7ef7c9..7afdf6c 100644 --- a/arch/x86/dts/minnowmax.dts +++ b/arch/x86/dts/minnowmax.dts @@ -20,7 +20,7 @@ aliases { serial0 = &serial; - spi0 = "/spi"; + spi0 = &spi; }; config { @@ -218,7 +218,7 @@ >; }; - spi { + spi: spi { #address-cells = <1>; #size-cells = <0>; compatible = "intel,ich-spi"; -- 1.8.2.1

2 2

[U-Boot] [PATCH 1/2] net: phy: introduce a quirk PHY_BROKEN_RESET
by shh.xie＠gmail.com 28 Jan '16

28 Jan '16

From: Shaohui Xie <Shaohui.Xie(a)nxp.com> Current driver always performs a phy soft reset when connecting the phy device, but soft reset is not always supported by a phy device, so introduce a quirk PHY_BROKEN_RESET to let such a phy device to skip soft reset. This commit uses 'flags' of phy device structure to store the quirk. Signed-off-by: Shaohui Xie <Shaohui.Xie(a)nxp.com> --- drivers/net/phy/phy.c | 3 +++ include/phy.h | 1 + 2 files changed, 4 insertions(+) diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index 51b5746..2a36ae7 100644 --- a/drivers/net/phy/phy.c +++ b/drivers/net/phy/phy.c @@ -707,6 +707,9 @@ int phy_reset(struct phy_device *phydev) int timeout = 500; int devad = MDIO_DEVAD_NONE; + if (phydev->flags == PHY_BROKEN_RESET) + return 0; + #ifdef CONFIG_PHYLIB_10G /* If it's 10G, we need to issue reset through one of the MMDs */ if (is_10g_interface(phydev->interface)) { diff --git a/include/phy.h b/include/phy.h index 66cf61b..5f604a1 100644 --- a/include/phy.h +++ b/include/phy.h @@ -16,6 +16,7 @@ #include <linux/mdio.h> #define PHY_MAX_ADDR 32 +#define PHY_BROKEN_RESET (1 << 0) /* soft reset not supported */ #define PHY_BASIC_FEATURES (SUPPORTED_10baseT_Half | \ SUPPORTED_10baseT_Full | \ -- 2.1.0.27.g96db324

3 2

[U-Boot] SPL loading U-Boot from a FIT
by Simon Glass 27 Jan '16

27 Jan '16

Hi, (moving to a new thread) Tom mentioned: >We _really_ need some way to support more than one board per binary >before we can move everything to DM only. We discussed this on IRC but since that doesn't exist as far as the mailing list is concerned... The current plan is: - Adjust build system to optionally build a u-boot.img in FIT format that includes the U-Boot binary and >1 device tree files - Adjust SPL to load this - Add a way for SPL to determine which device tree to select (by calling a board-specific function) - Have SPL pass this selected device tree to U-Boot when it starts Thus we should be able to support more than one board with a single U-Boot image. Of course this is not a perfect solution (e.g. it is inefficient since the DTs are likely to be largely the same) but it should be a good first step. I'm going to try this out with sunxi initially and plan to get some patches out by the end of the week. If you are interested in taking a look before patches are ready, see u-boot-fdt/spl-working. Regards, Simon

1 0

[U-Boot] [PATCH] net : null check after pointer dereference
by Vishwas Srivastava 27 Jan '16

27 Jan '16

Author: Vishwas Srivastava <vishu.kernel(a)gmail.com> Date: Tue Jan 26 12:46:42 2016 +0530 null check after pointer dereference NULL check is made after the pointer dereference is davinci- emac driver. This patch fixes this issue. CC: Sergey Kubushyn <ksi(a)koi8.net>;Joe Hershberger < joe.hershberger(a)ni.com> Signed-off-by: Vishwas Srivastava <vishu.kernel(a)gmail.com> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c index 3f54a3f..1966eb9 100644 --- a/drivers/net/davinci_emac.c +++ b/drivers/net/davinci_emac.c @@ -692,8 +692,10 @@ static int davinci_eth_rcv_packet (struct eth_device *dev) davinci_invalidate_rx_descs(); rx_curr_desc = emac_rx_active_head; + if (!rx_curr_desc) + return 0; status = rx_curr_desc->pkt_flag_len; - if ((rx_curr_desc) && ((status & EMAC_CPPI_OWNERSHIP_BIT) == 0)) { + if ((status & EMAC_CPPI_OWNERSHIP_BIT) == 0) { if (status & EMAC_CPPI_RX_ERROR_FRAME) { /* Error in packet - discard it and requeue desc */ printf ("WARN: emac_rcv_pkt: Error in packet\n");

3 3

[U-Boot] [PATCH]: net: Wrong Initialization in davinci-emac driver
by Vishwas Srivastava 27 Jan '16

27 Jan '16

Author: Vishwas Srivastava <vishu.kernel(a)gmail.com> Date: Mon Jan 25 21:28:17 2016 +0530 Wrong Initialization in davinci emac driver emac module of the davinci platform supports only 8 tx and 8 rx channels (total 16). emac driver for davinci platform, however, while doing initialization of the dma descriptor head pointers,wrongly initializes the 16 head pointers (instead of 8) for tx dma and 16 head pointers for rx dma, which is wrong.The result is, that this register initilization spills over the other registers which was not intended and is undesirable.This patch fixes this problem. Signed-off-by: Vishwas Srivastava <vishu.kernel(a)gmail.com> CC: Sergey Kubushyn <ksi(a)koi8.net>;Joe Hershberger < joe.hershberger(a)ni.com> Signed-off-by: Vishwas Srivastava <vishu.kernel(a)gmail.com> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c index 92c3dca..3f54a3f 100644 --- a/drivers/net/davinci_emac.c +++ b/drivers/net/davinci_emac.c @@ -459,11 +459,11 @@ static int davinci_eth_open(struct eth_device *dev, bd_t *bis) /* Set DMA 8 TX / 8 RX Head pointers to 0 */ addr = &adap_emac->TX0HDP; - for(cnt = 0; cnt < 16; cnt++) + for(cnt = 0; cnt < 8; cnt++) writel(0, addr++); addr = &adap_emac->RX0HDP; - for(cnt = 0; cnt < 16; cnt++) + for(cnt = 0; cnt < 8; cnt++) writel(0, addr++); /* Clear Statistics (do this before setting MacControl register) */

2 2

[U-Boot] question about "drivers/usb/gadget/f_fastboot.c"
by Steve Rae 27 Jan '16

27 Jan '16

Please explain the following logic in "drivers/usb/gadget/f_fastboot.c": 422) static unsigned int rx_bytes_expected(unsigned int maxpacket) 423) { 424) int rx_remain = download_size - download_bytes; 425) int rem = 0; 426) if (rx_remain < 0) 427) return 0; 428) if (rx_remain > EP_BUFFER_SIZE) 429) return EP_BUFFER_SIZE; 430) if (rx_remain < maxpacket) { 431) rx_remain = maxpacket; 432) } else if (rx_remain % maxpacket != 0) { 433) rem = rx_remain % maxpacket; 434) rx_remain = rx_remain + (maxpacket - rem); 435) } 436) return rx_remain; 437) } In my case, - rx_remain is 616 - maxpacket is 512 therefore, it hits line 434, where rx_remain is adjusted to 1024 But then the fastboot download phase just sits and waits forever, because the host can only send 616 bytes, and we are waiting for 1024 bytes! I don't understand why we are expecting MORE bytes than the host can send during the download phase.... And I don't understand the need to align to a multiple of "maxpacket" during the download phase.... BTW, if I delete lines 430 through 435, then it works properly! Thanks, Steve

1 0