April 2017 - U-Boot

[U-Boot] [PATCH v4 00/16] GPT over MTD
by Patrick Delaunay 11 Apr '17

11 Apr '17

I have a request to support GPT over MTD to have the MTD informations without U-Boot environment(CONFIG_ENV_IS_NOWHERE is a other requirement of my project to manage several board configuration with the same defconfig; boot from NAND or NOR or SDCARD). The current idea is to use the GPT header format to save the partitioning information directly in flash device (NOR or NAND), then the U-Boot MTD variables are rebuild from these GPT partitions and can be used by DISTRO command to search bootable binary. This information are directly used by BootRom to locate and load the first bootstage. The added code is under a new CONFIG : CONFIG_EFI_PARTITION_MTD and in the new file "disk/part_efi_mtd.c" For implementation details, see doc/README.gpt.mtd TODO: full support for modified command (if needed) today I limit the support for the command expected used by DISTRO macro: + gpt write + part list PLANNED: DISTRO macro update for automatic boot on GPT bootable partition found in MTD devices => as it is needed for my project, I will propose an other patch when this on will be accepted the current level is tested manually on sandbox with : > make O=sandbox sandbox_defconfig > make O=sandbox > dd if=/dev/zero of=spi.bin bs=1M count=4 > sandbox/u-boot -d sandbox/arch/sandbox/dts/test.dtb => sf probe SF: Detected M25P16 with page size 256 Bytes, erase size 64 KiB, total 2 MiB => setenv nor_part "name=part1,size=64KiB;name=part2,size=128KiB;\ name=boot,type=linux,bootable,size=512KiB" => gpt write nor 0 $nor_part Writing GPT: success! => part list nor 0 Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000080 0x000000ff "part1" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: d117f98e-6f2c-0040-00b2-331a19f91cb2 2 0x00000100 0x000001ff "part2" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 25718777-d0ad-0000-8060-02cb591c9737 3 0x00000200 0x000005ff "boot" attrs: 0x0000000000000004 type: 0fc63daf-8483-4772-8e79-3d69d8477de4 type: linux guid: 8a4bb8b4-e304-0040-0036-aff5c9c495b1 => setenv mtdids "nor0=nor0" => setenv mtdparts "mtdparts=" => mtdparts gpt nor0 => mtdparts device nor0 <nor0>, # parts = 3 #: name size offset mask_flags 0: part1 0x00010000 0x00010000 0 1: part2 0x00020000 0x00020000 0 2: boot 0x00080000 0x00040000 0 active partition: nor0,0 - (part1) 0x00010000 @ 0x00010000 defaults: mtdids : none mtdparts: none => part list nor 0 -bootable nor_boot_part => printenv nor_boot_part nor_boot_part=3 test filtering feature (can be used to mask some partitions to linux according the GUID) 1/ only add MTD for some guid = linux 2/ then add MTD for some guid = data => mtdparts delall => setenv mtdparts "mtdparts=" => setenv mtdids "nor0=nor0" => mtdparts gpt nor0 linux => mtdparts device nor0 <nor0>, # parts = 1 #: name size offset mask_flags 0: boot 0x00080000 0x00040000 0 active partition: nor0,0 - (boot) 0x00080000 @ 0x00040000 defaults: mtdids : none mtdparts: none => mtdparts gpt nor0 data => mtdparts device nor0 <nor0>, # parts = 3 #: name size offset mask_flags 0: part1 0x00010000 0x00010000 0 1: part2 0x00020000 0x00020000 0 2: boot 0x00080000 0x00040000 0 active partition: nor0,2 - (boot) 0x00080000 @ 0x00040000 defaults: mtdids : none mtdparts: none Changes in v4: - change RFC to PATCH - update cover letter - rebase on v2017.03 Changes in v3: - solve issue in compute partition_entry_lba update : missing / lba_size - rework and split patches for unrelated change after review from Cristophe Kerello and Simon Glass - rebase on v2017.03-rc1 Changes in v2: - split serie to reduce patches size (separate disk part and cmd impact and add precursor patch) - split large function Patrick Delaunay (16): uuid: add a function for GUID string parsing disk: part: refactor part_print_efi to prepare GPT over MTD disk: part: refactor part_get_info_efi to prepare GPT over MTD disk: part: prepare_backup_gpt_header rework disk: part: compute partition_entry_lba disk: part: efi: export internal function disk: part: add support of GPT partitioning over MTD cmd: gpt: remove blk_desc parameter in static function cmd: gpt: use error number in set_gpt_info cmd: gpt: add print_gpt_info_err cmd: gpt: update write command to support GPT over MTD cmd: part: update command to support GPT over MTD cmd: mtdparts: move PART_ADD_DESC_MAXLEN cmd: mtdparts: update command to support GPT over MTD uuid: remove dependency with io.h sandbox: GPT over MTD test cmd/gpt.c | 128 +++++++++---- cmd/mtdparts.c | 144 ++++++++++++++- cmd/part.c | 48 ++++- configs/sandbox_defconfig | 3 + disk/Kconfig | 17 ++ disk/Makefile | 1 + disk/part_efi.c | 140 +++++++------- disk/part_efi_int.h | 36 ++++ disk/part_efi_mtd.c | 457 ++++++++++++++++++++++++++++++++++++++++++++++ doc/README.gpt.mtd | 189 +++++++++++++++++++ include/configs/sandbox.h | 6 + include/part.h | 13 +- include/uuid.h | 1 + lib/uuid.c | 48 ++++- 14 files changed, 1108 insertions(+), 123 deletions(-) create mode 100644 disk/part_efi_int.h create mode 100644 disk/part_efi_mtd.c create mode 100644 doc/README.gpt.mtd -- 1.9.1

3 18

[U-Boot] [PATCH 1/3] fsl: PPA: add support PPA image validation from NAND and SD
by Sumit Garg 11 Apr '17

11 Apr '17

Signed-off-by: Sumit Garg <sumit.garg(a)nxp.com> Signed-off-by: Udit Agarwal <udit.agarwal(a)nxp.com> Tested-by: Vinitha Pillai <vinitha.pillai(a)nxp.com> --- arch/arm/cpu/armv8/fsl-layerscape/ppa.c | 67 ++++++++++++++++++++++++++++++++- 1 file changed, 66 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c index 7f87bb8..d8f1d36 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/ppa.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/ppa.c @@ -39,6 +39,10 @@ int ppa_init(void) #ifdef CONFIG_CHAIN_OF_TRUST uintptr_t ppa_esbc_hdr = CONFIG_SYS_LS_PPA_ESBC_ADDR; uintptr_t ppa_img_addr = 0; +#if defined(CONFIG_SYS_LS_PPA_FW_IN_MMC) || \ + defined(CONFIG_SYS_LS_PPA_FW_IN_NAND) + void *ppa_hdr_ddr; +#endif #endif #ifdef CONFIG_SYS_LS_PPA_FW_IN_XIP @@ -53,7 +57,7 @@ int ppa_init(void) int dev = CONFIG_SYS_MMC_ENV_DEV; struct fdt_header *fitp; u32 cnt; - u32 blk = CONFIG_SYS_LS_PPA_FW_ADDR / 512; + u32 blk; debug("%s: PPA image load from eMMC/SD\n", __func__); @@ -81,6 +85,7 @@ int ppa_init(void) return -ENOMEM; } + blk = CONFIG_SYS_LS_PPA_FW_ADDR / 512; cnt = DIV_ROUND_UP(fdt_header_len, 512); debug("%s: MMC read PPA FIT header: dev # %u, block # %u, count %u\n", __func__, dev, blk, cnt); @@ -102,6 +107,29 @@ int ppa_init(void) return ret; } +#ifdef CONFIG_CHAIN_OF_TRUST + ppa_hdr_ddr = malloc(CONFIG_LS_PPA_ESBC_HDR_SIZE); + if (!ppa_hdr_ddr) { + printf("PPA: malloc failed for PPA header\n"); + return -ENOMEM; + } + + blk = CONFIG_SYS_LS_PPA_ESBC_ADDR >> 9; + cnt = DIV_ROUND_UP(CONFIG_LS_PPA_ESBC_HDR_SIZE, 512); + ret = mmc->block_dev.block_read(&mmc->block_dev, blk, cnt, ppa_hdr_ddr); + if (ret != cnt) { + free(ppa_hdr_ddr); + printf("MMC/SD read of PPA header failed\n"); + return -EIO; + } + debug("Read PPA header to 0x%p\n", ppa_hdr_ddr); + + /* flush cache after read */ + flush_cache((ulong)ppa_hdr_ddr, cnt * 512); + + ppa_esbc_hdr = (uintptr_t)ppa_hdr_ddr; +#endif + fw_length = fdt_totalsize(fitp); free(fitp); @@ -113,6 +141,7 @@ int ppa_init(void) return -ENOMEM; } + blk = CONFIG_SYS_LS_PPA_FW_ADDR / 512; cnt = DIV_ROUND_UP(fw_length, 512); debug("%s: MMC read PPA FIT image: dev # %u, block # %u, count %u\n", __func__, dev, blk, cnt); @@ -148,6 +177,31 @@ int ppa_init(void) return ret; } +#ifdef CONFIG_CHAIN_OF_TRUST + ppa_hdr_ddr = malloc(CONFIG_LS_PPA_ESBC_HDR_SIZE); + if (!ppa_hdr_ddr) { + printf("PPA: malloc failed for PPA header\n"); + return -ENOMEM; + } + + fw_length = CONFIG_LS_PPA_ESBC_HDR_SIZE; + + ret = nand_read(nand_info[0], (loff_t)CONFIG_SYS_LS_PPA_ESBC_ADDR, + &fw_length, (u_char *)ppa_hdr_ddr); + if (ret == -EUCLEAN) { + free(ppa_hdr_ddr); + printf("NAND read of PPA firmware at offset 0x%x failed\n", + CONFIG_SYS_LS_PPA_FW_ADDR); + return -EIO; + } + debug("Read PPA header to 0x%p\n", ppa_hdr_ddr); + + /* flush cache after read */ + flush_cache((ulong)ppa_hdr_ddr, fw_length); + + ppa_esbc_hdr = (uintptr_t)ppa_hdr_ddr; +#endif + fw_length = fdt_totalsize(&fit); ppa_fit_addr = malloc(fw_length); @@ -177,6 +231,13 @@ int ppa_init(void) #ifdef CONFIG_CHAIN_OF_TRUST ppa_img_addr = (uintptr_t)ppa_fit_addr; if (fsl_check_boot_mode_secure() != 0) { + /* + * In case of failure in validation, fsl_secboot_validate + * would not return back in case of Production environment + * with ITS=1. In Development environment (ITS=0 and + * SB_EN=1), the function may return back in case of + * non-fatal failures. + */ ret = fsl_secboot_validate(ppa_esbc_hdr, PPA_KEY_HASH, &ppa_img_addr); @@ -185,6 +246,10 @@ int ppa_init(void) else printf("PPA validation Successful\n"); } +#if defined(CONFIG_SYS_LS_PPA_FW_IN_MMC) || \ + defined(CONFIG_SYS_LS_PPA_FW_IN_NAND) + free(ppa_hdr_ddr); +#endif #endif #ifdef CONFIG_FSL_LSCH3 -- 1.9.1

2 10

[U-Boot] [PATCH] include: configs: Fix build warnings due to redefined
by suniel.spartan＠gmail.com 11 Apr '17

11 Apr '17

From: Suniel Mahesh <suniel.spartan(a)gmail.com> Driver model for OMAP24XX and later Multichannel SPI master controller, if used, OMAP3 SPI configuration is set. The same configuration is defined in ti_armv7_omap.h, because of redefinition, warnings are spilled during build. Fixed warnings for AM335x SOC by using #ifndef directive in ti_armv7_omap.h. Signed-off-by: Suniel Mahesh <suniel.spartan(a)gmail.com> --- Note: Tested on Beaglebone Black using latest u-boot mainline tree with device tree set --- include/configs/ti_armv7_omap.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/ti_armv7_omap.h b/include/configs/ti_armv7_omap.h index de14b85..3167b61 100644 --- a/include/configs/ti_armv7_omap.h +++ b/include/configs/ti_armv7_omap.h @@ -21,7 +21,9 @@ #define CONFIG_SYS_I2C_OMAP24XX /* SPI IP Block */ +#ifndef CONFIG_OMAP3_SPI #define CONFIG_OMAP3_SPI +#endif /* GPIO block */ #define CONFIG_OMAP_GPIO -- 1.9.1

3 2

[U-Boot] Please pull ARC changes
by Alexey Brodkin 11 Apr '17

11 Apr '17

Hi Tom, There's just a minor but quite important fix for ARC to be pulled from my tree. Anyways please pull it. The following changes since commit 9963890b8be1d208035945abc5ba9f77637b6542: libfdt: fix build with Python 3 (2017-04-10 13:25:19 -0600) are available in the git repository at: git://git.denx.de/u-boot-arc.git for you to fetch changes up to 40a808f173008729a0c631ab84693b6a2b0dcfc9: ARCv2: SLC: Make sure busy bit is set properly on SLC flushing (2017-04-11 17:54:31 +0300) ---------------------------------------------------------------- Alexey Brodkin (1): ARCv2: SLC: Make sure busy bit is set properly on SLC flushing arch/arc/lib/cache.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) Regards, Alexey

2 1

[U-Boot] [PATCH] arc: arcv1: Disable master/slave check
by Alexey Brodkin 11 Apr '17

11 Apr '17

ARCompact cores are not supposed to be used in SMP designs (this doesn't stop people from creation of heterogeneous chips, for an example keep reading) so there's no point in checking ARCNUM and halting somebody if we build for ARC700. Moreover on AXS101 board we have ARC770 in the ASIC together with other ARC cores and ARC770 happens to be the last node in JTAG chain with ARCNUM = 4. And existing check halts the one and only core we want keep running. Signed-off-by: Alexey Brodkin <abrodkin(a)synopsys.com> --- arch/arc/lib/start.S | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arc/lib/start.S b/arch/arc/lib/start.S index b2ba7683097f..95d64f9d4375 100644 --- a/arch/arc/lib/start.S +++ b/arch/arc/lib/start.S @@ -10,6 +10,9 @@ #include <asm/arcregs.h> ENTRY(_start) +; ARCompact devices are not supposed to be SMP so master/slave check +; makes no sense. +#ifdef CONFIG_ISA_ARCV2 ; Non-masters will be halted immediately, they might be kicked later ; by platform code right before passing control to the Linux kernel ; in bootm.c:boot_jump_linux(). @@ -25,6 +28,7 @@ ENTRY(_start) nop .Lmaster_proceed: +#endif /* Setup interrupt vector base that matches "__text_start" */ sr __ivt_start, [ARC_AUX_INTR_VEC_BASE] -- 2.7.4

1 0

[U-Boot] Please pull u-boot-fdt
by Simon Glass 11 Apr '17

11 Apr '17

Hi Tom, Just a few minor fixes. The following changes since commit 01cce5fdd098add2b8aa570468cb35fca5d778fe: Merge git://git.denx.de/u-boot-x86 (2017-04-10 08:07:29 -0400) are available in the git repository at: git://git.denx.de/u-boot-fdt.git for you to fetch changes up to 9963890b8be1d208035945abc5ba9f77637b6542: libfdt: fix build with Python 3 (2017-04-10 13:25:19 -0600) ---------------------------------------------------------------- Simon Glass (1): fdt: Bring in changes from v1.4.4 Stefan Agner (1): libfdt: fix build with Python 3 lib/libfdt/fdt_overlay.c | 23 ++++++++++++----------- lib/libfdt/fdt_rw.c | 3 ++- lib/libfdt/fdt_strerror.c | 3 +++ lib/libfdt/setup.py | 2 +- 4 files changed, 18 insertions(+), 13 deletions(-) Regards, Simon

2 1

[U-Boot] generating a script file in FIT_SIGNATURE context
by Nicolas LE BAYON 11 Apr '17

11 Apr '17

Hi all, In my setup, I have activated FIT (without signature in a first step), and I boot using standard script way (boot.scr), which I generate with the following command : mkimage -A arm -T script -C none -n "My boot script" -d boot.txt boot.scr It works fine, and I can "load" and "bootm" the FIT image. Now I would like to activate fit_signature. When I write manually all the boot.txt script commands in the console, it works fine. So it means that the FIT image is well generated, and the u-boot is well-configured. That's a good point. But I have some problems to run the generated boot.scr in that case. I think the script should also be generated with the signature. Do you confirm that? If this is the case, from your point of view, which fields should I add to my previous command? -F ? -k ? -K? others? Thanks in advance for your feedback Best Regards Nicolas

1 0

[U-Boot] MTD devices emulation driver (gluebi) support
by ManuelCurcio＠Eaton.com 11 Apr '17

11 Apr '17

Hi, I want to read a jffs2 file system over ubi from uboot. >From ubi.h, I found the CONFIG_MTD_UBI_GLUEBI define to allow this functionality (I think) : /* gluebi.c */ #ifdef CONFIG_MTD_UBI_GLUEBI .... However, when I set this define, after compilation, I have errors links about gluebi functions : uboot/common/cmd_ubi.c:293: undefined reference to `ubi_gluebi_updated' And in fact, after search, I didn't find gluebi.c file in uboot. I use the U-Boot 2015.01 version. When I look the last release, I didn't find gluebi.c too. Some one can tell me more about that ? How is it possible to read jffs2 (or squashfs) from uboot ? thanks ! Manuel ________________________________ Eaton Industries (France) S.A.S ~ Siège social: 110 Rue Blaise Pascal, Immeuble Le Viséo - Bâtiment A Innovallée, 38330, Montbonnot-St.-Martin, France ~ Lieu d'enregistrement au registre du commerce: Grenoble ~ Numéro d'enregistrement: 509 653 176 ~ Capital social souscrit et liberé:EUR 16215441 ~ Numéro de TVA: FR47509653176? ________________________________

2 4

[U-Boot] [PATCH] board: ls2080ardb: Add serdes1 protocol 0x4b support
by Santan Kumar 11 Apr '17

11 Apr '17

Signed-off-by: Santan Kumar <santan.kumar(a)nxp.com> Signed-off-by: Priyanka Jain <priyanka.jain(a)nxp.com> --- board/freescale/ls2080ardb/eth_ls2080rdb.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/board/freescale/ls2080ardb/eth_ls2080rdb.c b/board/freescale/ls2080ardb/eth_ls2080rdb.c index 799799c..ba584c8 100644 --- a/board/freescale/ls2080ardb/eth_ls2080rdb.c +++ b/board/freescale/ls2080ardb/eth_ls2080rdb.c @@ -62,6 +62,13 @@ int board_eth_init(bd_t *bis) wriop_set_phy_address(WRIOP1_DPMAC8, AQ_PHY_ADDR4); break; + case 0x4B: + wriop_set_phy_address(WRIOP1_DPMAC1, CORTINA_PHY_ADDR1); + wriop_set_phy_address(WRIOP1_DPMAC2, CORTINA_PHY_ADDR2); + wriop_set_phy_address(WRIOP1_DPMAC3, CORTINA_PHY_ADDR3); + wriop_set_phy_address(WRIOP1_DPMAC4, CORTINA_PHY_ADDR4); + + break; default: printf("SerDes1 protocol 0x%x is not supported on LS2080aRDB\n", srds_s1); -- 1.9.1

1 0

[U-Boot] [PATCH] sunxi: set up PLL1 on sun6i+ without use dividers
by Icenowy Zheng 11 Apr '17

11 Apr '17

According to the researching result of Ondrej Jirman, the factor M of PLL1 shouldn't be used and the factor P should be used only if the intended frequency is lower than 288MHz. This is proven by the clk-sun8iw7_tbl.c in the BSP source code -- in there the M value is always 0 and the maximum frequency that P is not 0 is 224MHz. As P is ignored on sun6i, it's not currently used. This patch removed the usage of M. This patch is an original work by Ondrej Jirman, however, he didn't add a Signed-off-by tag here to his commit. So I take this code and added my Signed-off-by. Signed-off-by: Icenowy Zheng <icenowy(a)aosc.io> --- This is a critical patch, and should be added to 2017.05. It has been verified by the Armbian. arch/arm/mach-sunxi/clock_sun6i.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-sunxi/clock_sun6i.c b/arch/arm/mach-sunxi/clock_sun6i.c index 4762fbf0c3..ce4291b30e 100644 --- a/arch/arm/mach-sunxi/clock_sun6i.c +++ b/arch/arm/mach-sunxi/clock_sun6i.c @@ -98,11 +98,10 @@ void clock_set_pll1(unsigned int clk) int k = 1; int m = 1; - if (clk > 1152000000) { - k = 2; - } else if (clk > 768000000) { + if (clk >= 1368000000) { k = 3; - m = 2; + } else if (clk >= 768000000) { + k = 2; } /* Switch to 24MHz clock while changing PLL1 */ -- 2.12.2

5 9