March 2016 - U-Boot

[U-Boot] [PATCH] fdt: fix setting MAC addresses for multiple interfaces
by Lev Iserovich 04 May '16

04 May '16

For multiple ethernet interfaces the FDT offset of '/aliases' will change as we are adding MAC addresses to the FDT. Therefore only the first interface ('ethernet0') will get properly updated in the FDT, with the rest getting FDT errors when we try to set their MAC address. Switch to using fdt_get_alias() which is the proper way to get the FDT path. Signed-off-by: Lev Iserovich <iserovil(a)deshawresearch.com> --- common/fdt_support.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/common/fdt_support.c b/common/fdt_support.c index 66464db..20e0e1c 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -481,16 +481,12 @@ int fdt_fixup_memory(void *blob, u64 start, u64 size) void fdt_fixup_ethernet(void *fdt) { - int node, i, j; + int i, j; char enet[16], *tmp, *end; char mac[16]; const char *path; unsigned char mac_addr[6]; - node = fdt_path_offset(fdt, "/aliases"); - if (node < 0) - return; - if (!getenv("ethaddr")) { if (getenv("usbethaddr")) { strcpy(mac, "usbethaddr"); @@ -505,7 +501,7 @@ void fdt_fixup_ethernet(void *fdt) i = 0; while ((tmp = getenv(mac)) != NULL) { sprintf(enet, "ethernet%d", i); - path = fdt_getprop(fdt, node, enet, NULL); + path = fdt_get_alias(fdt, enet); if (!path) { debug("No alias for %s\n", enet); sprintf(mac, "eth%daddr", ++i); -- 2.1.0

5 11

[U-Boot] [PATCH 0/2] net: phy: mv88e61xx: Revise as a PHY driver
by Kevin Smith 03 May '16

03 May '16

The previous version of this driver implemented a shell command to manually comfigure the switch. It did not integrate with the PHY infrastructure to allow a MAC to use it as its PHY. This is complete rewrite to allow this switch to function as a driver. Since none of the original driver remains, the old driver is first removed and the new PHY driver is added. This version configures the switch to have a CPU connected over an MII interface. It will enable PHY interfaces based on the MV88E61XX_PHY_PORTS macro. The switch is configured to allow PHY ports to only communicate to the CPU. This allows the switch to be used as a basic PHY on any/all ports. This was developed on a board with an mv88e6176 connected over SGMII. It is intended to work with other configurations, but these could not be tested. Any testing on other configurations or with other mv88e61xx chips is appreciated. Signed-off-by: Kevin Smith <kevin.smith(a)elecsyscorp.com> Acked-by: Prafulla Wadaskar <prafulla(a)marvell.com> Cc: Joe Hershberger <joe.hershberger(a)ni.com> Cc: Stefan Roese <sr(a)denx.de> Cc: Marek Vasut <marex(a)denx.de> Kevin Smith (2): net: Remove unused mv88e61xx switch driver net: phy: Add PHY driver for mv88e61xx switches drivers/net/phy/mv88e61xx.c | 959 +++++++++++++++++++++++++------------------- drivers/net/phy/mv88e61xx.h | 61 --- drivers/net/phy/phy.c | 3 + include/netdev.h | 58 --- include/phy.h | 1 + 5 files changed, 547 insertions(+), 535 deletions(-) delete mode 100644 drivers/net/phy/mv88e61xx.h -- 2.4.6

4 18

[U-Boot] [PATCH] drivers: net: ldpaa: Memset pools_params as "0" before use
by Prabhakar Kushwaha 03 May '16

03 May '16

Memset pools_params as "0" to avoid garbage value in dpni_set_pools. Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha(a)nxp.com> Reported-by: Jose Rivera <german.rivera(a)nxp.com> --- drivers/net/ldpaa_eth/ldpaa_eth.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c b/drivers/net/ldpaa_eth/ldpaa_eth.c index bc7f8bb..75b2b6b 100644 --- a/drivers/net/ldpaa_eth/ldpaa_eth.c +++ b/drivers/net/ldpaa_eth/ldpaa_eth.c @@ -920,6 +920,7 @@ static int ldpaa_dpni_bind(struct ldpaa_eth_priv *priv) struct dpni_tx_conf_cfg tx_conf_cfg; int err = 0; + memset(&pools_params, 0, sizeof(pools_params)); pools_params.num_dpbp = 1; pools_params.pools[0].dpbp_id = (uint16_t)dflt_dpbp->dpbp_attr.id; pools_params.pools[0].buffer_size = LDPAA_ETH_RX_BUFFER_SIZE; -- 1.9.1

3 2

[U-Boot] [PATCH 0/2] board: atmel: add SAMA5D2 PTC Engineering board
by Wenyou Yang 03 May '16

03 May '16

This board supports booting from NAND Flash and spi Flash. Wenyou Yang (2): ARM: at91: sama5d2: add macro & field definitions board: atmel: add SAMA5D2 PTC Engineering board arch/arm/mach-at91/Kconfig | 6 + arch/arm/mach-at91/include/mach/sama5_sfr.h | 24 +++ arch/arm/mach-at91/include/mach/sama5d2.h | 5 + board/atmel/sama5d2_ptc/Kconfig | 15 ++ board/atmel/sama5d2_ptc/MAINTAINERS | 7 + board/atmel/sama5d2_ptc/Makefile | 8 + board/atmel/sama5d2_ptc/sama5d2_ptc.c | 285 +++++++++++++++++++++++++++ configs/sama5d2_ptc_nandflash_defconfig | 12 ++ configs/sama5d2_ptc_spiflash_defconfig | 12 ++ include/configs/sama5d2_ptc.h | 155 +++++++++++++++ 10 files changed, 529 insertions(+) create mode 100644 board/atmel/sama5d2_ptc/Kconfig create mode 100644 board/atmel/sama5d2_ptc/MAINTAINERS create mode 100644 board/atmel/sama5d2_ptc/Makefile create mode 100644 board/atmel/sama5d2_ptc/sama5d2_ptc.c create mode 100644 configs/sama5d2_ptc_nandflash_defconfig create mode 100644 configs/sama5d2_ptc_spiflash_defconfig create mode 100644 include/configs/sama5d2_ptc.h -- 1.7.9.5

2 12

[U-Boot] [PATCH] spl_mmc: allow to load raw image
by Masahiro Yamada 02 May '16

02 May '16

The function spl_parse_image_header() falls back to a raw image if the U-Boot header is missing and CONFIG_SPL_PANIC_ON_RAW_IMAGE is undefined. While, the bad magic checking here makes the spl_parse_image_header() unreachable in case of the missing header. Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> --- common/spl/spl_mmc.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index c27a250..df406e3 100644 --- a/common/spl/spl_mmc.c +++ b/common/spl/spl_mmc.c @@ -33,11 +33,6 @@ static int mmc_load_image_raw_sector(struct mmc *mmc, unsigned long sector) if (count == 0) goto end; - if (image_get_magic(header) != IH_MAGIC) { - puts("bad magic\n"); - return -1; - } - spl_parse_image_header(header); /* convert size to sectors - round up */ -- 1.9.1

6 26

[U-Boot] [RFC] SPL -> U-Boot Chain of Trust
by Andreas Dannenberg 02 May '16

02 May '16

On Mon, Mar 28, 2016 at 03:32:40PM -0400, Tom Rini wrote: > I'm interested in getting secure device support going, but it seems > like we should need more than that, ie something to keep the chain of > trust going. Tom et al., I just saw your reply to Vitaly's email and I'm actually just looking into something along the lines you brought up but I didn't want to hijack that discussion so here's a new thread. As for the chain of trust for ARMv7, my understanding is that when using a combination of SPL and U-Boot there will always be a vendor- specific initial boot (ROM) code that authenticates SPL, and then there will need to be some code inserted into SPL that authenticates U-Boot after it's loaded (for example by using some secure ROM API call and such). So I was looking into if there is already some generic framework for this in U-Boot but didn't see anything obvious. One "easy" way would be to add a simple call to an authentication routine to board_init_r (u-boot/common/spl/spl.c) but let's say we add such a call for TI or other vendor's stuff I suppose this would not scale very well. But what about adding one generic call to a default authentication function declared as __weak for spl_image that doesn't do anything, but can be overwritten in vendor-specific files to provide means of authenticating spl_image. Would this be a good approach? Beyond that I was reviewing some of the awesome work from the Chromium team and I think on ARMv7 after we get MLO to authenticate U-Boot everything beyond that is already looking very solid and thorough (with FIT, DTB/Kernel and initramfs authentication). Thanks and Regards, -- Andreas Dannenberg Texas Instruments Inc

2 6

[U-Boot] [PATCH v2 00/27] spl: Support loading a FIT image containing U-Boot
by Simon Glass 02 May '16

02 May '16

4 60

[U-Boot] buildman: arm: undefined reference to `__aeabi_ldivmod'
by Jagan Teki 02 May '16

02 May '16

Hi, Did anyone encounter this issue? please let me know for any inputs. arm: + venice2 +drivers/mtd/spi-nor/built-in.o: In function `spi_nor_write': +build/../drivers/mtd/spi-nor/spi-nor.c:585: undefined reference to `__aeabi_ldivmod' +arm-unknown-linux-gnueabi-ld.bfd: BFD (GNU Binutils) 2.24 assertion fail /home/tony/buildall/src/binutils/bfd/elf32-arm.c:7696 +arm-unknown-linux-gnueabi-ld.bfd: error: required section '.rel.plt' not found in the linker script +arm-unknown-linux-gnueabi-ld.bfd: final link failed: Invalid operation +make[1]: *** [u-boot] Error 1 +make: *** [sub-make] Error 2 thanks! -- Jagan.

3 8

[U-Boot] [PATCH 0/8] net: Split out the Ethernet uclass into its own file
by Simon Glass 01 May '16

01 May '16

Every other uclass is in its own file. It makes sense to put the Ethernet uclass code into its own file too. The result is less code in each file, and it becomes easier to see which code is related to driver model. This series creates a new common file to hold the common code, moves the driver-model into its own file and tidies up. Some boards use PCI to obtain Ethernet. With driver model, unless this is mentioned in the device tree, the Ethernet device will not be present on initial startup. So we need to probe PCI just in case there is a device there. Simon Glass (8): tegra: Report errors from PCI init net: Don't call board/cpu_eth_init() with driver model net: Move common init into a new eth_common.c file net: Move environment functions to the common file net: Move remaining common functions to eth_common.c net: Move driver-model code into its own file net: Rename eth.c to eth_lecacy.c net: Probe PCI before looking for ethernet devices drivers/pci/pci_tegra.c | 6 +- net/Makefile | 7 +- net/{eth.c => eth-uclass.c} | 601 +------------------------------------------- net/eth_common.c | 166 ++++++++++++ net/eth_internal.h | 40 +++ net/eth_legacy.c | 439 ++++++++++++++++++++++++++++++++ 6 files changed, 664 insertions(+), 595 deletions(-) rename net/{eth.c => eth-uclass.c} (50%) create mode 100644 net/eth_common.c create mode 100644 net/eth_internal.h create mode 100644 net/eth_legacy.c -- 2.6.0.rc2.230.g3dd15c0

4 37

[U-Boot] A problem about 'sf probe' using DM_SPI
by Qianyu Gong 01 May '16

01 May '16

Hi Simon, I think I'm not very clear with this code in common/cmd_sf.c: " # ifdef CONFIG_DM_SPI_FLASH /* Remove the old device, otherwise probe will just be a nop */ ret = spi_find_bus_and_cs(bus, cs, &bus_dev, &new); if (!ret) { device_remove(new); device_unbind(new); } " I may understand the remove but why need to unbind the device? The unbind would cause a series of free operations on the device list, correct? Then if I probe a flash twice, at the second time the driver model will create a new flash named 'spi_flash@xx:xx' using default settings because it doesn't find such a device in the device list and never probes it from the board's fdt again. => dm tree Class Probed Name ---------------------------------------- root [ + ] root_driver simple_bus [ + ] `-- soc spi [ + ] |-- dspi@2100000 spi_flash [ ] | |-- n25q128a spi_flash [ + ] | |-- spi_flash@1:1 spi_flash [ + ] | `-- spi_flash@1:2 Fortunately the default SPI mode set by U-Boot is SPI_MODE_3 so it doesn't cause issues on our boards. But if an SPI flash which only supports SPI_MODE_0 is used, I think it wouldn't work properly from the second probe. Sorry if there is something wrong with my understandings. Just because I found my flash's name was changed to spi-flash@xx:xx in dm tree after several probes, I began to read something about driver model.:) Regards, Qianyu

2 5