February 2018 - U-Boot

[U-Boot] arm: mvebu: ClearFog: booting u-boot from ssd?
by Florian Klink 22 Feb '18

22 Feb '18

Hey, I tried getting ClearFog to load u-boot from a M.2 SSD (via SATA) So I built u-boot-spl.kwb > make clearfog_defconfig > make -j4 ARCH=arm CROSS_COMPILE=arm-none-eabi- dd'ed it on the SSD: > dd if=u-boot-spl.kwb of=/dev/sdX bs=512 seek=1 changed SW1 dip to 11100, and got this: > BootROM - 1.73 > Booting from AHCI > Probing HBA- 0 port 0 SATA device found > BootROM: Bad header at offset 00000001 > BootROM: Bad header at offset 00000022 > BootROM: Bad header at offset 00001000 > BootROM: Bad header at offset 00002000 > BootROM: Bad header at offset 00003000 > BootROM: Bad header at offset 00004000 > BootROM: Bad header at offset 00005000 > BootROM: Bad header at offset 00006000 > BootROM: Bad header at offset 00007000 > > Trying Uart According to the clearfog wiki and uboot-armada38x src tree, there are separate images for sd and sata, with the makefile there calling > $(obj)tools/marvell/doimage -T mmc -D 0x0 -E 0x0 -G $(obj)tools/marvell/bin_hdr/bin_hdr.bin u-boot.bin u-boot.mmc vs > $(obj)tools/marvell/doimage -T sata -D 0x0 -E 0x0 -G $(obj)tools/marvell/bin_hdr/bin_hdr.bin u-boot.bin u-boot.sata According to uboot-armada38x's tools/marvell/doimage_mv/doimage.c, this seems to result in different hdr->blockID = IBR_HDR_SATA_ID; //0x78 hdr->blockID = IBR_HDR_MMC_ID; //0xAE and maybe another hdr->sourceAddr baked into the image header [1] Mainline u-boot also knows about IBR_HDR_SATA_ID (tools/kwbimage.h), and has a mapping in tools/kwbimage.c (boot_modes[]), which seems to decide depending on the 'BOOT_FROM' setting in board/solidrun/clearfog/kwbimage.cfg This is currently hardcoded to 'sdio' (which will be translated to 0xAE == IBR_HDR_MMC_ID). Am I missing something completely obvious, or does this mean there need to be different image headers depending on boot medium type BootROM tries to load u-boot from (so it might be desirable to make this configurable)? Are there already any efforts being taken on that? Most likely we'd also need to enable SATA drivers, so u-boot is able to read the kernel, which might be on that disk. Regards, Florian [1]: https://github.com/coreboot/coreboot/blob/master/util/marvell/doimage_mv/do…

2 3

[U-Boot] [PATCH] board_f: Only reserve memory for U-Boot if we're going to relocate
by Alexey Brodkin 22 Feb '18

22 Feb '18

In case of no relocation we'll just waste some paceat the very end of usable memory area. If U-Boot is huge and we cannot use a lot of memory this loss will be pretty inconvenient. Signed-off-by: Alexey Brodkin <abrodkin(a)synopsys.com> Cc: Simon Glass <sjg(a)chromium.org> Cc: Bin Meng <bmeng.cn(a)gmail.com> Cc: Heiko Schocher <hs(a)denx.de> Cc: York Sun <york.sun(a)nxp.com> Cc: Stefan Roese <sr(a)denx.de> --- common/board_f.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/common/board_f.c b/common/board_f.c index 92743089087e..d1662199a570 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -396,19 +396,21 @@ static int reserve_trace(void) static int reserve_uboot(void) { - /* - * reserve memory for U-Boot code, data & bss - * round down to next 4 kB limit - */ - gd->relocaddr -= gd->mon_len; - gd->relocaddr &= ~(4096 - 1); -#if defined(CONFIG_E500) || defined(CONFIG_MIPS) - /* round down to next 64 kB limit so that IVPR stays aligned */ - gd->relocaddr &= ~(65536 - 1); -#endif - - debug("Reserving %ldk for U-Boot at: %08lx\n", gd->mon_len >> 10, - gd->relocaddr); + if (!(gd->flags & GD_FLG_SKIP_RELOC)) { + /* + * reserve memory for U-Boot code, data & bss + * round down to next 4 kB limit + */ + gd->relocaddr -= gd->mon_len; + gd->relocaddr &= ~(4096 - 1); + #if defined(CONFIG_E500) || defined(CONFIG_MIPS) + /* round down to next 64 kB limit so that IVPR stays aligned */ + gd->relocaddr &= ~(65536 - 1); + #endif + + debug("Reserving %ldk for U-Boot at: %08lx\n", + gd->mon_len >> 10, gd->relocaddr); + } gd->start_addr_sp = gd->relocaddr; -- 2.14.3

2 3

[U-Boot] [PATCH] arc: Introduce a possibility to not relocate U-boot
by Alexey Brodkin 22 Feb '18

22 Feb '18

From: Alexey Brodkin <Alexey.Brodkin(a)synopsys.com> Disabling relocation might be useful on ARC for 2 reasons: a) For advanced debugging with Synopsys proprietary MetaWare debugger which is capable of accessing much more specific hardware resources compared to gdb. For example it may show contents of L1 and L2 caches, internal states of some hardware blocks etc. But on the downside MetaWare debugger still cannot work with PIE. Even though that limitation could be work-arounded with change of ELF's header and stripping down all debug info but with it we won't have debug info for source-level debugging which is quite inconvenient. b) Some platforms which might benefit from usage of U-Boot basically don't have enough RAM to accommodate relocation of U-Boot so we keep code in flash and use as much of RAM as possible for more interesting things. Signed-off-by: Alexey Brodkin <abrodkin(a)synopsys.com> Cc: Simon Glass <sjg(a)chromium.org> Cc: Bin Meng <bmeng.cn(a)gmail.com> Cc: Heiko Schocher <hs(a)denx.de> Cc: York Sun <york.sun(a)nxp.com> Cc: Stefan Roese <sr(a)denx.de> --- arch/arc/lib/relocate.c | 6 ++++++ arch/arc/lib/start.S | 8 +++++++- common/board_f.c | 3 ++- 3 files changed, 15 insertions(+), 2 deletions(-) diff --git a/arch/arc/lib/relocate.c b/arch/arc/lib/relocate.c index 7802f4054594..96b4bd3d8fa6 100644 --- a/arch/arc/lib/relocate.c +++ b/arch/arc/lib/relocate.c @@ -17,6 +17,9 @@ int copy_uboot_to_ram(void) { size_t len = (size_t)&__image_copy_end - (size_t)&__image_copy_start; + if (gd->flags & GD_FLG_SKIP_RELOC) + return 0; + memcpy((void *)gd->relocaddr, (void *)&__image_copy_start, len); return 0; @@ -40,6 +43,9 @@ int do_elf_reloc_fixups(void) Elf32_Rela *re_src = (Elf32_Rela *)(&__rel_dyn_start); Elf32_Rela *re_end = (Elf32_Rela *)(&__rel_dyn_end); + if (gd->flags & GD_FLG_SKIP_RELOC) + return 0; + debug("Section .rela.dyn is located at %08x-%08x\n", (unsigned int)re_src, (unsigned int)re_end); diff --git a/arch/arc/lib/start.S b/arch/arc/lib/start.S index ac9944c4cf32..c78dd001d81d 100644 --- a/arch/arc/lib/start.S +++ b/arch/arc/lib/start.S @@ -78,7 +78,13 @@ ENTRY(_start) /* Zero the one and only argument of "board_init_f" */ mov_s %r0, 0 - j board_init_f + bl board_init_f + + /* We only get here if relocation is disabled by GD_FLG_SKIP_RELOC */ + /* Make sure we don't lose GD overwritten by zero new GD */ + mov %r0, %r25 + mov %r1, 0 + bl board_init_r ENDPROC(_start) /* diff --git a/common/board_f.c b/common/board_f.c index 7bfc73e8bca0..48c98d1a71af 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -904,7 +904,8 @@ void board_init_f(ulong boot_flags) hang(); #if !defined(CONFIG_ARM) && !defined(CONFIG_SANDBOX) && \ - !defined(CONFIG_EFI_APP) && !CONFIG_IS_ENABLED(X86_64) + !defined(CONFIG_EFI_APP) && !CONFIG_IS_ENABLED(X86_64) && \ + !defined(CONFIG_ARC) /* NOTREACHED - jump_to_copy() does not return */ hang(); #endif -- 2.14.3

2 3

[U-Boot] [PATCH 1/2] arm: socfpga: cyclone5: Enable Macronix flash support
by chin.liang.see＠intel.com 22 Feb '18

22 Feb '18

From: Chin Liang See <chin.liang.see(a)intel.com> Enable Macronix flash support for Cyclone5 SoC Signed-off-by: Chin Liang See <chin.liang.see(a)intel.com> --- configs/socfpga_cyclone5_defconfig | 1 + configs/socfpga_is1_defconfig | 1 + configs/socfpga_sockit_defconfig | 1 + configs/socfpga_socrates_defconfig | 1 + configs/socfpga_sr1500_defconfig | 1 + configs/socfpga_vining_fpga_defconfig | 1 + 6 files changed, 6 insertions(+) diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig index 6ebd8a9..aa535c6 100644 --- a/configs/socfpga_cyclone5_defconfig +++ b/configs/socfpga_cyclone5_defconfig @@ -53,6 +53,7 @@ CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set diff --git a/configs/socfpga_is1_defconfig b/configs/socfpga_is1_defconfig index 08628ab..7be720a 100644 --- a/configs/socfpga_is1_defconfig +++ b/configs/socfpga_is1_defconfig @@ -48,6 +48,7 @@ CONFIG_SYS_I2C_DW=y # CONFIG_MMC is not set CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ90X1=y diff --git a/configs/socfpga_sockit_defconfig b/configs/socfpga_sockit_defconfig index 8ebe394..6edb47f 100644 --- a/configs/socfpga_sockit_defconfig +++ b/configs/socfpga_sockit_defconfig @@ -53,6 +53,7 @@ CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set diff --git a/configs/socfpga_socrates_defconfig b/configs/socfpga_socrates_defconfig index 9f42481..7c2428a 100644 --- a/configs/socfpga_socrates_defconfig +++ b/configs/socfpga_socrates_defconfig @@ -54,6 +54,7 @@ CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHY_MICREL=y diff --git a/configs/socfpga_sr1500_defconfig b/configs/socfpga_sr1500_defconfig index f9ed1a3..df1ee31 100644 --- a/configs/socfpga_sr1500_defconfig +++ b/configs/socfpga_sr1500_defconfig @@ -53,6 +53,7 @@ CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_DM_ETH=y diff --git a/configs/socfpga_vining_fpga_defconfig b/configs/socfpga_vining_fpga_defconfig index 6670b9f..512d701 100644 --- a/configs/socfpga_vining_fpga_defconfig +++ b/configs/socfpga_vining_fpga_defconfig @@ -69,6 +69,7 @@ CONFIG_LED_STATUS_CMD=y CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set -- 2.2.2

4 6

[U-Boot] [PATCH 1/2] doc: mxc_hab: Move HAB related info to the appropriate doc
by Breno Lima 22 Feb '18

22 Feb '18

From: Breno Lima <breno.lima(a)nxp.com> Currently the High Assurance Boot procedure is documented in two places: - doc/README.imx6 - doc/README.mxc_hab It is better to consolidate all HAB related information into README.mxc_hab file, so move the content from README.imx6 to README.mxc_hab. Signed-off-by: Breno Lima <breno.lima(a)nxp.com> --- doc/README.imx6 | 48 --------------------------------------------- doc/README.mxc_hab | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 54 insertions(+), 51 deletions(-) diff --git a/doc/README.imx6 b/doc/README.imx6 index 2e8f1d8..b0644f8 100644 --- a/doc/README.imx6 +++ b/doc/README.imx6 @@ -113,51 +113,3 @@ issue the command: In order to load SPL and u-boot.img via imx_usb_loader tool, please refer to doc/README.sdp. -3. Using Secure Boot on i.MX6 machines with SPL support -------------------------------------------------------- - -This version of U-Boot is able to build a signable version of the SPL -as well as a signable version of the U-Boot image. The signature can -be verified through High Assurance Boot (HAB). - -CONFIG_SECURE_BOOT is needed to build those two binaries. -After building, you need to create a command sequence file and use -Freescales Code Signing Tool to sign both binaries. After creation, -the mkimage tool outputs the required information about the HAB Blocks -parameter for the CSF. During the build, the information is preserved -in log files named as the binaries. (SPL.log and u-boot-ivt.log). - -More information about the CSF and HAB can be found in the AN4581. -https://cache.freescale.com/files/32bit/doc/app_note/AN4581.pdf - -We don't want to explain how to create a PKI tree or SRK table as -this is well explained in the Application Note. - -Example Output of the SPL (imximage) creation: - Image Type: Freescale IMX Boot Image - Image Ver: 2 (i.MX53/6/7 compatible) - Mode: DCD - Data Size: 61440 Bytes = 60.00 kB = 0.06 MB - Load Address: 00907420 - Entry Point: 00908000 - HAB Blocks: 00907400 00000000 0000cc00 - -Example Output of the u-boot-ivt.img (firmware_ivt) creation: - Image Name: U-Boot 2016.11-rc1-31589-g2a4411 - Created: Sat Nov 5 21:53:28 2016 - Image Type: ARM U-Boot Firmware with HABv4 IVT (uncompressed) - Data Size: 352192 Bytes = 343.94 kB = 0.34 MB - Load Address: 17800000 - Entry Point: 00000000 - HAB Blocks: 0x177fffc0 0x0000 0x00054020 - -The CST (Code Signing Tool) can be downloaded from NXP. -# Compile CSF and create signature -./cst --o csf-u-boot.bin < command_sequence_uboot.csf -./cst --o csf-SPL.bin < command_sequence_spl.csf -# Append compiled CSF to Binary -cat SPL csf-SPL.bin > SPL-signed -cat u-boot-ivt.img csf-u-boot.bin > u-boot-signed.img - -These two signed binaries can be used on an i.MX6 in closed -configuration when the according SRK Table Hash has been flashed. diff --git a/doc/README.mxc_hab b/doc/README.mxc_hab index 4bd07d3..056ade7 100644 --- a/doc/README.mxc_hab +++ b/doc/README.mxc_hab @@ -1,4 +1,5 @@ -High Assurance Boot (HAB) for i.MX6 CPUs +1. High Assurance Boot (HAB) for i.MX CPUs +------------------------------------------ To enable the authenticated or encrypted boot mode of U-Boot, it is required to set the proper configuration for the target board. This @@ -52,8 +53,58 @@ cat u-boot.imx U-Boot_CSF_pad.bin > u-boot-signed.imx NOTE: U-Boot_CSF.bin needs to be padded to the value specified in the imximage.cfg file. -Setup U-Boot Image for Encrypted Boot -------------------------------------- + +2. Using Secure Boot on i.MX6 machines with SPL support +------------------------------------------------------- + +This version of U-Boot is able to build a signable version of the SPL +as well as a signable version of the U-Boot image. The signature can +be verified through High Assurance Boot (HAB). + +CONFIG_SECURE_BOOT is needed to build those two binaries. +After building, you need to create a command sequence file and use +Freescales Code Signing Tool to sign both binaries. After creation, +the mkimage tool outputs the required information about the HAB Blocks +parameter for the CSF. During the build, the information is preserved +in log files named as the binaries. (SPL.log and u-boot-ivt.log). + +More information about the CSF and HAB can be found in the AN4581. +https://cache.freescale.com/files/32bit/doc/app_note/AN4581.pdf + +We don't want to explain how to create a PKI tree or SRK table as +this is well explained in the Application Note. + +Example Output of the SPL (imximage) creation: + Image Type: Freescale IMX Boot Image + Image Ver: 2 (i.MX53/6/7 compatible) + Mode: DCD + Data Size: 61440 Bytes = 60.00 kB = 0.06 MB + Load Address: 00907420 + Entry Point: 00908000 + HAB Blocks: 00907400 00000000 0000cc00 + +Example Output of the u-boot-ivt.img (firmware_ivt) creation: + Image Name: U-Boot 2016.11-rc1-31589-g2a4411 + Created: Sat Nov 5 21:53:28 2016 + Image Type: ARM U-Boot Firmware with HABv4 IVT (uncompressed) + Data Size: 352192 Bytes = 343.94 kB = 0.34 MB + Load Address: 17800000 + Entry Point: 00000000 + HAB Blocks: 0x177fffc0 0x0000 0x00054020 + +The CST (Code Signing Tool) can be downloaded from NXP. +# Compile CSF and create signature +./cst --o csf-u-boot.bin < command_sequence_uboot.csf +./cst --o csf-SPL.bin < command_sequence_spl.csf +# Append compiled CSF to Binary +cat SPL csf-SPL.bin > SPL-signed +cat u-boot-ivt.img csf-u-boot.bin > u-boot-signed.img + +These two signed binaries can be used on an i.MX6 in closed +configuration when the according SRK Table Hash has been flashed. + +3. Setup U-Boot Image for Encrypted Boot +----------------------------------------- An authenticated U-Boot image is used as starting point for Encrypted Boot. The image is encrypted by Freescale's Code Signing Tool (CST). The CST replaces only the image data of -- 2.7.4

2 2

[U-Boot] [PATCH 1/3] imx6ul: engicam: Drop isiot-mmc defconfig
by Jagan Teki 22 Feb '18

22 Feb '18

Engicam Is.IoT has eMMC and NAND cpu modules where MMC is common for both, so remove explicit mmc defconfig. Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- arch/arm/dts/Makefile | 1 - arch/arm/dts/imx6ul-isiot-mmc.dts | 50 ------------------------------------- board/engicam/imx6ul/MAINTAINERS | 1 - configs/imx6ul_isiot_emmc_defconfig | 2 ++ configs/imx6ul_isiot_mmc_defconfig | 44 -------------------------------- 5 files changed, 2 insertions(+), 96 deletions(-) delete mode 100644 arch/arm/dts/imx6ul-isiot-mmc.dts delete mode 100644 configs/imx6ul_isiot_mmc_defconfig diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index c7695aa1f1..e9fe71431c 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -396,7 +396,6 @@ dtb-$(CONFIG_MX6) += imx6ull-14x14-evk.dtb \ imx6sx-sdb.dtb \ imx6ul-geam-kit.dtb \ imx6ul-isiot-emmc.dtb \ - imx6ul-isiot-mmc.dtb \ imx6ul-isiot-nand.dtb \ imx6ul-opos6uldev.dtb diff --git a/arch/arm/dts/imx6ul-isiot-mmc.dts b/arch/arm/dts/imx6ul-isiot-mmc.dts deleted file mode 100644 index bb5086a68a..0000000000 --- a/arch/arm/dts/imx6ul-isiot-mmc.dts +++ /dev/null @@ -1,50 +0,0 @@ -/* - * Copyright (C) 2016 Amarula Solutions B.V. - * Copyright (C) 2016 Engicam S.r.l. - * - * This file is dual-licensed: you can use it either under the terms - * of the GPL or the X11 license, at your option. Note that this dual - * licensing only applies to this file, and not this project as a - * whole. - * - * a) This file is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * version 2 as published by the Free Software Foundation. - * - * This file is distributed in the hope that it will be useful - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * Or, alternatively - * - * b) Permission is hereby granted, free of charge, to any person - * obtaining a copy of this software and associated documentation - * files (the "Software"), to deal in the Software without - * restriction, including without limitation the rights to use - * copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following - * conditions: - * - * The above copyright notice and this permission notice shall be - * included in all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND - * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES - * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND - * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT - * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY - * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR - * OTHER DEALINGS IN THE SOFTWARE. - */ - -/dts-v1/; - -#include "imx6ul-isiot.dtsi" - -/ { - model = "Engicam Is.IoT MX6UL MMC Starterkit"; - compatible = "engicam,imx6ul-isiot", "fsl,imx6ul"; -}; diff --git a/board/engicam/imx6ul/MAINTAINERS b/board/engicam/imx6ul/MAINTAINERS index 37f84f8cc0..73dbec88e2 100644 --- a/board/engicam/imx6ul/MAINTAINERS +++ b/board/engicam/imx6ul/MAINTAINERS @@ -10,6 +10,5 @@ F: configs/imx6ul_isiot_mmc_defconfig F: configs/imx6ul_isiot_nand_defconfig F: arch/arm/dts/imx6ul-geam-kit.dts F: arch/arm/dts/imx6ul-isiot.dtsi -F: arch/arm/dts/imx6ul-isiot-mmc.dts F: arch/arm/dts/imx6ul-isiot-emmc.dts F: arch/arm/dts/imx6ul-isiot-nand.dts diff --git a/configs/imx6ul_isiot_emmc_defconfig b/configs/imx6ul_isiot_emmc_defconfig index c334bebcce..d91b944d6e 100644 --- a/configs/imx6ul_isiot_emmc_defconfig +++ b/configs/imx6ul_isiot_emmc_defconfig @@ -23,6 +23,7 @@ CONFIG_SYS_PROMPT="isiotmx6ul> " CONFIG_CRC32_VERIFY=y CONFIG_CMD_MEMTEST=y CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_MII=y CONFIG_CMD_PING=y @@ -33,6 +34,7 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_ENV_IS_IN_MMC=y +CONFIG_SYS_I2C_MXC=y CONFIG_PHYLIB=y CONFIG_PHY_SMSC=y CONFIG_FEC_MXC=y diff --git a/configs/imx6ul_isiot_mmc_defconfig b/configs/imx6ul_isiot_mmc_defconfig deleted file mode 100644 index 3297a03678..0000000000 --- a/configs/imx6ul_isiot_mmc_defconfig +++ /dev/null @@ -1,44 +0,0 @@ -CONFIG_ARM=y -CONFIG_ARCH_MX6=y -CONFIG_SYS_TEXT_BASE=0x87800000 -CONFIG_SPL_GPIO_SUPPORT=y -CONFIG_SPL_LIBCOMMON_SUPPORT=y -CONFIG_SPL_LIBGENERIC_SUPPORT=y -CONFIG_SYS_MALLOC_F_LEN=0x2000 -CONFIG_TARGET_MX6UL_ENGICAM=y -CONFIG_SPL_SERIAL_SUPPORT=y -CONFIG_SPL_LIBDISK_SUPPORT=y -CONFIG_SPL_WATCHDOG_SUPPORT=y -# CONFIG_CMD_BMODE is not set -CONFIG_DEFAULT_DEVICE_TREE="imx6ul-isiot-mmc" -CONFIG_FIT=y -CONFIG_FIT_SIGNATURE=y -CONFIG_FIT_VERBOSE=y -CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" -CONFIG_BOOTDELAY=3 -CONFIG_SPL=y -CONFIG_SPL_EXT_SUPPORT=y -CONFIG_HUSH_PARSER=y -CONFIG_SYS_PROMPT="isiotmx6ul> " -CONFIG_CRC32_VERIFY=y -CONFIG_CMD_MEMTEST=y -CONFIG_CMD_GPIO=y -CONFIG_CMD_I2C=y -CONFIG_CMD_MMC=y -CONFIG_CMD_MII=y -CONFIG_CMD_PING=y -CONFIG_CMD_CACHE=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_EXT4=y -CONFIG_CMD_EXT4_WRITE=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y -CONFIG_ENV_IS_IN_MMC=y -CONFIG_SYS_I2C_MXC=y -CONFIG_PHYLIB=y -CONFIG_PHY_SMSC=y -CONFIG_FEC_MXC=y -CONFIG_PINCTRL=y -CONFIG_PINCTRL_IMX6=y -CONFIG_MXC_UART=y -CONFIG_IMX_THERMAL=y -- 2.14.2

2 4

[U-Boot] [PATCH 1/5] imx: hab: Keep CAAM clock enabled after authenticating additional images
by Breno Lima 22 Feb '18

22 Feb '18

From: Breno Lima <breno.lima(a)nxp.com> Currently it is not possible to run CMD_DEK on i.MX SPL targets: => dek_blob 0x12000000 0x12001000 128 The system hangs after running dek_blob because the CAAM clock is being disabled by the HAB code. There is no need to disable CAAM clock after authenticating additional boot images, thus keep CAAM clock enabled to address this issue. Signed-off-by: Breno Lima <breno.lima(a)nxp.com> --- arch/arm/mach-imx/hab.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c index 5f19777..1e6b31d 100644 --- a/arch/arm/mach-imx/hab.c +++ b/arch/arm/mach-imx/hab.c @@ -507,13 +507,13 @@ int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t image_size, /* Verify IVT header bugging out on error */ if (verify_ivt_header(ivt_hdr)) - goto hab_caam_clock_disable; + goto hab_authentication_exit; /* Verify IVT body */ if (ivt->self != ivt_addr) { printf("ivt->self 0x%08x pointer is 0x%08x\n", ivt->self, ivt_addr); - goto hab_caam_clock_disable; + goto hab_authentication_exit; } start = ddr_start; @@ -591,8 +591,7 @@ hab_exit_failure_print_status: get_hab_status(); #endif -hab_caam_clock_disable: - hab_caam_clock_enable(0); +hab_authentication_exit: if (load_addr != 0) result = 0; -- 2.7.4

3 10

[U-Boot] [PATCH for 2018.03] sunxi: README.sunxi64: Add hint about non-debug ATF
by Andre Przywara 22 Feb '18

22 Feb '18

As we are running into issues where the final U-Boot FIT image file is exceeding our size limit, add a hint to the README.sunxi64 file to point out the possibility of building non-debug versions of the ATF binary. This is about 12KB smaller than the standard debug build, and so again allows successful U-Boot builds for many boards with the Allwinner H5 SoC. Please note that under normal circumstances the debug build is still recommended, as it gives valuable clues in case something goes wrong in the ATF. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> --- Hi, as the level of desperation about Allwinner 64-bit FIT image sizes rises, we are getting more into the slightly cheaty section with our mitigations. However as my previous attempts in fixing this issue were not that warmly welcomed, I now suggest this rather pragmatic solution, which avoids hacking U-Boot badly. This fixes the various H5 builds for me. Cheers, Andre. board/sunxi/README.sunxi64 | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/board/sunxi/README.sunxi64 b/board/sunxi/README.sunxi64 index c492f749b8..eefa5001a2 100644 --- a/board/sunxi/README.sunxi64 +++ b/board/sunxi/README.sunxi64 @@ -38,6 +38,12 @@ the root of your U-Boot build directory (or create a symbolic link). $ export BL31=/src/arm-trusted-firmware/build/sun50iw1p1/debug/bl31.bin (adjust the actual path accordingly) +If you run into size issues with the resulting U-Boot image file, it might +help to use a release build, by using "DEBUG=0" when building bl31.bin. +As sometimes the ATF build process is a bit picky about the toolchain used, +or if you can't be bothered with building ATF, there are known working +binaries in the firmware repository[3], purely for convenience reasons. + SPL/U-Boot ------------ Both U-Boot proper and the SPL are using the 64-bit mode. As the boot ROM -- 2.14.1

3 3

[U-Boot] Can't boot with initramfs but It's ok without
by Clément Péron 22 Feb '18

22 Feb '18

Hi, I'm working on a dev board the SoC is Broadcom Cygnus with 256MiB of RAM Booting a Kernel and device tree works fine. But booting a Kernel with initramfs and a device tree make a strange behavior. Don't want to say stupid things but It seems that the Kernel didn't find the device tree and try to fall back using the ATAGS, but since I don't use them the machine ID is not set up. Do you have any idea of what I did wrong in my setup ? Thanks, Clement ---------------------------------------- U-Boot 2018.03-rc2-00036-g427c1c7280-dirty (Feb 21 2018 - 16:40:00 +0100) U-Boot code: 61000000 -> 6103F578 BSS: -> 6104CACC DRAM: Monitor len: 0004CACC Ram size: 0FA00000 Ram top: 6FA00000 TLB table from 6f9f0000 to 6f9f4000 Reserving 306k for U-Boot at: 6f9a3000 Reserving 4101k for malloc() at: 6f5a1c00 Reserving 80 Bytes for Board Info at: 6f5a1bb0 Reserving 184 Bytes for Global Data at: 6f5a1af8 RAM Configuration: Bank #0: 60000000 250 MiB DRAM: 250 MiB New Stack Pointer is: 6f5a1ad0 Relocation Offset is: 0e9a3000 Relocating to 6f9a3000, new gd at 6f5a1af8, sp at 6f5a1ad0 Now running in RAM - U-Boot at: 6f9a3000 MMC: iproc-sdhci: 0 Loading Environment from MMC... OK In: serial Out: serial Err: serial Net: Registering BCM sf2 eth Broadcom Starfighter2 Ethernet driver 0.1 Using GMAC0 gmac_mac_init: Chip ID: 0xd300 srab_interface_reset: timeout sw_init_done devid read succesfully via srab: 0xd300 devid32: 0xd300 Basic ethernet functionality initialized bcm_sf2_gmac-0 Hit any key to stop autoboot: 0 Booting debug bcm_sf2_gmac-0 Waiting for PHY auto negotiation to complete........ done Change GMAC speed to 1000MB BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 DHCP client bound to address 192.168.0.113 (4043 ms) Change GMAC speed to 1000MB 192.168.0.3 Change GMAC speed to 1000MB Using bcm_sf2_gmac-0 device TFTP from server 192.168.0.3; our IP address is 192.168.0.113 Filename 'boot/zImage'. Load address: 0x63000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################## 6.5 MiB/s done Bytes transferred = 73245400 (45da2d8 hex) Change GMAC speed to 1000MB Using bcm_sf2_gmac-0 device TFTP from server 192.168.0.3; our IP address is 192.168.0.113 Filename 'boot/myboard.dtb'. Load address: 0x62000000 Loading: # 6.2 MiB/s done Bytes transferred = 25911 (6537 hex) Kernel image @ 0x63000000 [ 0x000000 - 0x45da2d8 ] ## Flattened Device Tree blob at 62000000 Booting using the fdt blob at 0x62000000 Using Device Tree in place at 62000000, end 62009536 Starting kernel ... Uncompressing Linux... done, booting the kernel. Error: unrecognized/unsupported machine ID (r1 = 0x00000000). Available machine support: ID (hex) NAME ffffffff Generic DT based system ffffffff Broadcom Cygnus SoC ffffffff Freescale i.MX6 Quad/DualLite (Device Tree) ffffffff Altera SOCFPGA Please check your kernel config and/or bootloader.

1 1

Re: [U-Boot] TCP & Overrrun
by Duncan Hare 22 Feb '18

22 Feb '18

On Sun, 11 Feb 2018 00:39:05 +0000 (UTC) Duncan Hare <dh(a)synoia.com> wrote: > Duncan Hare > > 714 931 7952 > > > ----- Forwarded Message ----- > From: Joe Hershberger <joe.hershberger(a)ni.com> > To: Duncan Hare <dh(a)synoia.com> > Cc: Joe Hershberger <joe.hershberger(a)ni.com>; u-boot > <u-boot(a)lists.denx.de> Sent: Friday, February 9, 2018 1:11 PM > Subject: Re: [U-Boot] TCP & Overrrun > > On Thu, Feb 8, 2018 at 8:41 PM, Duncan Hare <dh(a)synoia.com> wrote: > > On Thu, 8 Feb 2018 22:15:44 +0000 (UTC) > > Duncan Hare <dh(a)synoia.com> wrote: > > > >> Duncan Hare > >> > >> 714 931 7952 > >> > >> > >> ----- Forwarded Message ----- > >> From: Joe Hershberger <joe.hershberger(a)ni.com> > >> To: Duncan Hare <dh(a)synoia.com> > >> Cc: u-boot <u-boot(a)lists.denx.de>; Joe Hershberger > >> <joe.hershberger(a)ni.com> Sent: Thursday, February 8, 2018 11:40 AM > >> Subject: Re: [U-Boot] TCP & Overrrun > >> > >> Hi Duncan, > >> > >> On Wed, Feb 7, 2018 at 8:40 PM, Duncan Hare <dh(a)synoia.com> > >> wrote: > >> > I'm gettin overrun on the raspberry pi. > >> > > >> > Which ethernet drived does it use? > >> > >> You didn't specify which one you are talking about, but here's how > >> to find out... > >> > >> Assuming rpi3, find the config first... > >> > >> configs/rpi_3_defconfig says: > >> CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b" > >> arch/arm/dts/bcm2837-rpi-3-b.dts says: #include > >> "bcm283x-rpi-smsc9514.dtsi" arch/arm/dts/bcm283x-rpi-smsc9514.dtsi > >> says: ethernet: usbether@1 { > >> compatible = "usb424,ec00"; grep -rn ec00 drivers/ says: > >> drivers/usb/eth/smsc95xx.c > >> > >> Cheers, > >> -Joe > >> > >> > I need to determine if it > >> > uses CONFIG_SYS_RX_ETH_BUFFER" from net.h and the > >> > "net_rx_packets" buffer pool defined in net/net.c > >> > > >> > grep suggests it is not using net_rx_packets. > >> > > >> > Thanks > >> > > >> > Duncan Hare > >> > _______________________________________________ > >> > U-Boot mailing list > >> > U-Boot(a)lists.denx.de > >> > https://lists.denx.de/listinfo/u-boot > > ___________________________________________________ > > Joe > > > > Two solutions: > > > > Option 1. > > > > I think option 1 is the way to go. > > Thanks, > -Joe Joe The overruns were caused by printing error messages. The print process is (very) slow compared with packet and computer speeds, and causes overruns. I turned off all the error messages in tcp.c and the overruns also stopped. Makes debugging harder. Duncan

3 3