[U-Boot] [PATCH v2 01/11] lib: add TPL_OF_LIBFDT option for TPL
TPL may need use libfdt for dt decode, add option for it. Signed-off-by: Kever Yang --- Changes in v2: None lib/Kconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/lib/Kconfig b/lib/Kconfig index f447c53..b43ef22 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -234,6 +234,16 @@ config SPL_OF_LIBFDT particular compatible nodes. The library operates on a flattened version of the device tree. +config TPL_OF_LIBFDT + bool "Enable the FDT library for TPL" + default y if TPL_OF_CONTROL + help + This enables the FDT library (libfdt). It provides functions for + accessing binary device tree images in memory, such as adding and + removing nodes and properties, scanning through the tree and finding + particular compatible nodes. The library operates on a flattened + version of the device tree. + config FDT_FIXUP_PARTITIONS bool "overwrite MTD partitions in DTS through defined in 'mtdparts'" depends on OF_LIBFDT -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 03/11] arm: add a separate stack for TPL
TPL stack may different from SPL and sys stack, add support for separate one when the board defines it. Signed-off-by: Kever Yang --- Changes in v2: None arch/arm/lib/crt0.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index fa81317..3c1c603 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -70,7 +70,9 @@ ENTRY(_main) * Set up initial C runtime environment and call board_init_f(0). */ -#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) +#if defined(CONFIG_TPL_BUILD) && defined(CONFIG_TPL_NEEDS_SEPARATE_STACK) + ldr r0, =(CONFIG_TPL_STACK) +#elif defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) ldr r0, =(CONFIG_SPL_STACK) #else ldr r0, =(CONFIG_SYS_INIT_SP_ADDR) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 02/11] arm: add option for TPL ARCH_MEM in arm 32bit
Some options like TPL_SYS_THUMB_BUILD, TPL_USE_ARCH_MEMCPY and TPL_USE_ARCH_MEMCPY are needed for TPL build in 32bit arm. Signed-off-by: Kever Yang --- Changes in v2: - update subject with ARCH_MEM info arch/arm/Kconfig | 29 + 1 file changed, 29 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 7390995..4069227 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -244,6 +244,17 @@ config SPL_SYS_THUMB_BUILD density. For ARM architectures that support Thumb2 this flag will result in Thumb2 code generated by GCC. +config TPL_SYS_THUMB_BUILD + bool "Build TPL using the Thumb instruction set" + default y if SYS_THUMB_BUILD + depends on TPL && !ARM64 + help + Use this flag to build SPL using the Thumb instruction set for + ARM architectures. Thumb instruction set provides better code + density. For ARM architectures that support Thumb2 this flag will + result in Thumb2 code generated by GCC. + + config SYS_L2CACHE_OFF bool "L2cache off" help @@ -280,6 +291,15 @@ config SPL_USE_ARCH_MEMCPY Such implementation may be faster under some conditions but may increase the binary size. +config TPL_USE_ARCH_MEMCPY + bool "Use an assembly optimized implementation of memcpy for TPL" + default y if USE_ARCH_MEMCPY + depends on !ARM64 + help + Enable the generation of an optimized version of memcpy. + Such implementation may be faster under some conditions + but may increase the binary size. + config USE_ARCH_MEMSET bool "Use an assembly optimized implementation of memset" default y @@ -298,6 +318,15 @@ config SPL_USE_ARCH_MEMSET Such implementation may be faster under some conditions but may increase the binary size. +config TPL_USE_ARCH_MEMSET + bool "Use an assembly optimized implementation of memset for TPL" + default y if USE_ARCH_MEMSET + depends on !ARM64 + help + Enable the generation of an optimized version of memset. + Such implementation may be faster under some conditions + but may increase the binary size. + config ARM64_SUPPORT_AARCH32 bool "ARM64 system support AArch32 execution state" default y if ARM64 && !TARGET_THUNDERX_88XX -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 05/11] sysreset: enable driver support in SPL/TPL
SPL/TPL also need use sysreset for some feature like panic callback. Signed-off-by: Kever Yang --- Changes in v2: None drivers/sysreset/Kconfig | 18 ++ drivers/sysreset/Makefile | 2 +- 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig index a6d48e8..a61a7d3 100644 --- a/drivers/sysreset/Kconfig +++ b/drivers/sysreset/Kconfig @@ -13,6 +13,24 @@ config SYSRESET to effect a reset. The uclass will try all available drivers when reset_walk() is called. +config SPL_SYSRESET + bool "Enable support for system reset drivers in SPL mode" + depends on SYSRESET && SPL_DM + help + Enable system reset drivers which can be used to reset the CPU or + board. Each driver can provide a reset method which will be called + to effect a reset. The uclass will try all available drivers when + reset_walk() is called. + +config TPL_SYSRESET + bool "Enable support for system reset drivers in TPL mode" + depends on SYSRESET && TPL_DM + help + Enable system reset drivers which can be used to reset the CPU or + board. Each driver can provide a reset method which will be called + to effect a reset. The uclass will try all available drivers when + reset_walk() is called. + if SYSRESET config SYSRESET_PSCI diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile index 2e9598e..00be747 100644 --- a/drivers/sysreset/Makefile +++ b/drivers/sysreset/Makefile @@ -4,7 +4,7 @@ # SPDX-License-Identifier: GPL-2.0+ # -obj-$(CONFIG_SYSRESET) += sysreset-uclass.o +obj-$(CONFIG_$(SPL_TPL_)SYSRESET) += sysreset-uclass.o obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 04/11] rockchip: rk322x: enable tpl support
Move original spl to tpl, and add spl to load next stage firmware, adapt all the address and option for them. Serial-changes: 2 - update upon latest source Signed-off-by: Kever Yang --- Changes in v2: None arch/arm/mach-rockchip/Kconfig | 9 +++ arch/arm/mach-rockchip/Makefile | 3 +- arch/arm/mach-rockchip/rk322x-board-spl.c| 61 +-- arch/arm/mach-rockchip/rk322x-board-tpl.c| 90 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds | 13 include/configs/rk322x_common.h | 9 ++- 6 files changed, 134 insertions(+), 51 deletions(-) create mode 100644 arch/arm/mach-rockchip/rk322x-board-tpl.c create mode 100644 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 967290f..dbc197c 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -46,9 +46,18 @@ config ROCKCHIP_RK322X bool "Support Rockchip RK3228/RK3229" select CPU_V7 select SUPPORT_SPL + select SUPPORT_TPL select SPL + select TPL + select TPL_NEEDS_SEPARATE_TEXT_BASE if SPL + select TPL_NEEDS_SEPARATE_STACK if TPL + select SPL_DRIVERS_MISC_SUPPORT + imply SPL_SERIAL_SUPPORT + imply TPL_SERIAL_SUPPORT select ROCKCHIP_BROM_HELPER select DEBUG_UART_BOARD_INIT + select TPL_LIBCOMMON_SUPPORT + select TPL_LIBGENERIC_SUPPORT help The Rockchip RK3229 is a ARM-based SoC with a dual-core Cortex-A7 including NEON and GPU, Mali-400 graphics, several DDR3 options diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile index e1b0519..3c14236 100644 --- a/arch/arm/mach-rockchip/Makefile +++ b/arch/arm/mach-rockchip/Makefile @@ -13,10 +13,11 @@ obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o obj-tpl-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-tpl.o obj-tpl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-tpl.o +obj-tpl-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board-tpl.o obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o obj-spl-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board-spl.o -obj-spl-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board-spl.o +obj-spl-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board-spl.o spl-boot-order.o obj-spl-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-spl.o obj-spl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-spl.o spl-boot-order.o obj-spl-$(CONFIG_ROCKCHIP_RK3399) += rk3399-board-spl.o spl-boot-order.o diff --git a/arch/arm/mach-rockchip/rk322x-board-spl.c b/arch/arm/mach-rockchip/rk322x-board-spl.c index 35f4f97..cab0262 100644 --- a/arch/arm/mach-rockchip/rk322x-board-spl.c +++ b/arch/arm/mach-rockchip/rk322x-board-spl.c @@ -5,77 +5,48 @@ */ #include -#include #include -#include #include -#include -#include -#include -#include -#include -#include -#include + +DECLARE_GLOBAL_DATA_PTR; u32 spl_boot_device(void) { return BOOT_DEVICE_MMC1; } -DECLARE_GLOBAL_DATA_PTR; -#define GRF_BASE 0x1100 -#define SGRF_BASE 0x1014 - -#define DEBUG_UART_BASE0x1103 +u32 spl_boot_mode(const u32 boot_device) +{ + return MMCSD_MODE_RAW; +} void board_debug_uart_init(void) { -static struct rk322x_grf * const grf = (void *)GRF_BASE; - /* Enable early UART2 channel 1 on the RK322x */ - rk_clrsetreg(&grf->gpio1b_iomux, -GPIO1B1_MASK | GPIO1B2_MASK, -GPIO1B2_UART21_SIN << GPIO1B2_SHIFT | -GPIO1B1_UART21_SOUT << GPIO1B1_SHIFT); - /* Set channel C as UART2 input */ - rk_clrsetreg(&grf->con_iomux, -CON_IOMUX_UART2SEL_MASK, -CON_IOMUX_UART2SEL_21 << CON_IOMUX_UART2SEL_SHIFT); } -#define SGRF_DDR_CON0 0x1015 void board_init_f(ulong dummy) { - struct udevice *dev; int ret; - /* -* Debug UART can be used from here if required: -* -* debug_uart_init(); -* printch('a'); -* printhex8(0x1234); -* printascii("string"); -*/ - debug_uart_init(); - printascii("SPL Init"); - ret = spl_early_init(); if (ret) { - debug("spl_early_init() failed: %d\n", ret); + printf("spl_early_init() failed: %d\n", ret); hang(); } + preloader_console_init(); +} - rockchip_timer_init(); - printf("timer init done\n"); - ret = uclass_get_device(UCLASS_RAM, 0, &dev); - if (ret) { - printf("DRAM init failed: %d\n", ret); - return; - } +#ifdef CONFIG_SPL_LOAD_FIT +int board_fit_config_name_match(const char *name) +{ + /* Just empty function now - can't decide what to choose */ + debug("%s: %s\n", __func__, name); /* Disable the ddr secure region setting to make it non-secure */ rk_clrreg(SGRF_DDR_CON0, 0x4000); #if define
[U-Boot] [PATCH v2 07/11] spl: add support to booting with OP-TEE
OP-TEE is an open source trusted OS, in armv7, its loading and running are like this: loading: - SPL load both OP-TEE and U-Boot running: - SPL run into OP-TEE in secure mode; - OP-TEE run into U-Boot in non-secure mode; More detail: https://github.com/OP-TEE/optee_os and search for 'boot arguments' for detail entry parameter in: core/arch/arm/kernel/generic_entry_a32.S Signed-off-by: Kever Yang --- Changes in v2: - Using new image type for op-tee common/spl/Kconfig | 7 +++ common/spl/Makefile| 1 + common/spl/spl.c | 8 common/spl/spl_optee.S | 13 + include/spl.h | 9 + 5 files changed, 38 insertions(+) create mode 100644 common/spl/spl_optee.S diff --git a/common/spl/Kconfig b/common/spl/Kconfig index aef0034..c9a1ebb 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -725,6 +725,13 @@ config SPL_ATF is loaded by SPL(which is considered as BL2 in ATF terminology). More detail at: https://github.com/ARM-software/arm-trusted-firmware +config SPL_OPTEE + bool "Support OP-TEE Trusted OS" + depends on ARM + help + OP-TEE is an open source Trusted OS which is loaded by SPL. + More detail at: https://github.com/OP-TEE/optee_os + config TPL bool depends on SUPPORT_TPL diff --git a/common/spl/Makefile b/common/spl/Makefile index 9bf8a2d..9918a2e 100644 --- a/common/spl/Makefile +++ b/common/spl/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_$(SPL_TPL_)UBI) += spl_ubi.o obj-$(CONFIG_$(SPL_TPL_)NET_SUPPORT) += spl_net.o obj-$(CONFIG_$(SPL_TPL_)MMC_SUPPORT) += spl_mmc.o obj-$(CONFIG_$(SPL_TPL_)ATF) += spl_atf.o +obj-$(CONFIG_$(SPL_TPL_)OPTEE) += spl_optee.o obj-$(CONFIG_$(SPL_TPL_)USB_SUPPORT) += spl_usb.o obj-$(CONFIG_$(SPL_TPL_)FAT_SUPPORT) += spl_fat.o obj-$(CONFIG_$(SPL_TPL_)EXT_SUPPORT) += spl_ext.o diff --git a/common/spl/spl.c b/common/spl/spl.c index 76c1963..2c8942b 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -436,6 +436,12 @@ void board_init_r(gd_t *dummy1, ulong dummy2) spl_invoke_atf(&spl_image); break; #endif +#if CONFIG_IS_ENABLED(OPTEE) + case IH_OS_OP_TEE: + debug("Jumping to U-Boot via OP-TEE\n"); + spl_optee_entry(0, 0, 0, (void *)spl_image.entry_point); + break; +#endif #ifdef CONFIG_SPL_OS_BOOT case IH_OS_LINUX: debug("Jumping to Linux\n"); @@ -450,6 +456,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2) debug("SPL malloc() used %#lx bytes (%ld KB)\n", gd->malloc_ptr, gd->malloc_ptr / 1024); #endif + + debug("loaded - jumping to U-Boot...\n"); #ifdef CONFIG_BOOTSTAGE_STASH int ret; diff --git a/common/spl/spl_optee.S b/common/spl/spl_optee.S new file mode 100644 index 000..4f7f8ba --- /dev/null +++ b/common/spl/spl_optee.S @@ -0,0 +1,13 @@ +/* + * Copyright (C) 2017 Rockchip Electronic Co.,Ltd + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include + +ENTRY(spl_optee_entry) + ldr lr, =CONFIG_SYS_TEXT_BASE + mov pc, r3 +ENDPROC(spl_optee_entry) diff --git a/include/spl.h b/include/spl.h index c14448b..551ce43 100644 --- a/include/spl.h +++ b/include/spl.h @@ -288,6 +288,15 @@ int spl_mmc_load_image(struct spl_image_info *spl_image, void spl_invoke_atf(struct spl_image_info *spl_image); /** + * spl_optee_entry - entry function for optee + * entry arg0, pagestore + * entry arg1, (ARMv7 standard bootarg #1) + * entry arg2, device tree address, (ARMv7 standard bootarg #2) + * entry arg3, non-secure entry address (ARMv7 bootarg #0) + */ +void spl_optee_entry(void *arg0, void *arg1, void *arg2, void *arg3); + +/** * board_return_to_bootrom - allow for boards to continue with the boot ROM * * If a board (e.g. the Rockchip RK3368 boards) provide some -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 09/11] rockchip: add fit source file for pack itb with op-tee
We package U-Boot and OP-TEE into one itb file for SPL, so that we can support OP-TEE in SPL. Signed-off-by: Kever Yang --- Changes in v2: - Make the its as common file used for all armv7 with op-tee arch/arm/mach-rockchip/fit_spl_optee.its | 50 1 file changed, 50 insertions(+) create mode 100644 arch/arm/mach-rockchip/fit_spl_optee.its diff --git a/arch/arm/mach-rockchip/fit_spl_optee.its b/arch/arm/mach-rockchip/fit_spl_optee.its new file mode 100644 index 000..3aeecb8 --- /dev/null +++ b/arch/arm/mach-rockchip/fit_spl_optee.its @@ -0,0 +1,50 @@ +/* + * Copyright (C) 2017 Rockchip Electronic Co.,Ltd + * + * Simple U-boot fit source file containing U-Boot, dtb and optee + */ + +/dts-v1/; + +/ { + description = "Simple image with OP-TEE support"; + #address-cells = <1>; + + images { + uboot@1 { + description = "U-Boot"; + data = /incbin/("../../../u-boot-nodtb.bin"); + type = "standalone"; + os = "U-Boot"; + arch = "arm"; + compression = "none"; + load = <0x6100>; + }; + optee@1 { + description = "OP-TEE"; + data = /incbin/("../../../tee.bin"); + type = "firmware"; + arch = "arm"; + os = "op-tee"; + compression = "none"; + load = <0x6840>; + entry = <0x6840>; + }; + fdt@1 { + description = "dtb"; + data = /incbin/("../../../u-boot.dtb"); + type = "flat_dt"; + compression = "none"; + }; + }; + + configurations { + default = "conf@1"; + conf@1 { + description = "Rockchip armv7 with OP-TEE"; + firmware = "optee@1"; + loadables = "uboot@1"; + fdt = "fdt@1"; + }; + }; +}; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 10/11] rockchip: evb-rk3229: add README file for OP-TEE support
Detail of step by step to bring up the board with OP-TEE support. Signed-off-by: Kever Yang --- Changes in v2: None board/rockchip/evb_rk3229/README | 72 1 file changed, 72 insertions(+) create mode 100644 board/rockchip/evb_rk3229/README diff --git a/board/rockchip/evb_rk3229/README b/board/rockchip/evb_rk3229/README new file mode 100644 index 000..46c54c2 --- /dev/null +++ b/board/rockchip/evb_rk3229/README @@ -0,0 +1,72 @@ +Get the Source and prebuild binary +== + + > mkdir ~/evb_rk3229 + > cd ~/evb_rk3229 + > git clone git://git.denx.de/u-boot.git + > git clone https://github.com/OP-TEE/optee_os.git + > git clone https://github.com/rockchip-linux/rkbin.git + > git clone https://github.com/rockchip-linux/rkdeveloptool.git + +Compile the OP-TEE +=== + + > cd optee_os + > make clean + > make CROSS_COMPILE_ta_arm32=arm-none-eabi- PLATFORM=rockchip-rk322x + Get tee.bin in this step, copy it to U-Boot root dir: + > cp out/arm-plat-rockchip/core/tee-pager.bin ../u-boot/tee.bin + +Compile the U-Boot +== + + > cd ../u-boot + > export CROSS_COMPILE=arm-linux-gnueabihf- + > export ARCH=arm + > make evb-rk3229_defconfig + > make + > make u-boot.itb + + Get tpl/u-boot-tpl.bin, spl/u-boot-spl.bin and u-boot.itb in this step. + +Compile the rkdeveloptool +=== + Follow instructions in latest README + > cd ../rkdeveloptool + > autoreconf -i + > ./configure + > make + > sudo make install + + Get rkdeveloptool in you Host in this step. + +Both origin binaries and Tool are ready now, choose either option 1 or +option 2 to deploy U-Boot. + +Package the image += + + > cd ../u-boot + > tools/mkimage -n rk322x -T rksd -d tpl/u-boot-spl.bin idbloader.img + > cat spl/u-boot-spl.bin >> idbloader.img + + Get idbloader.img in this step. + +Flash the image to eMMC +=== +Power on(or reset with RESET KEY) with MASKROM KEY preesed, and then: + > cd .. + > rkdeveloptool db rkbin/rk32/rk322x_loader_v1.04.232.bin + > rkdeveloptool wl 64 u-boot/idbloader.img + > rkdeveloptool wl 0x4000 u-boot/u-boot.itb + > rkdeveloptool rd + +Flash the image to SD card +== + > dd if=u-boot/idbloader.img of=/dev/sdb seek=64 + > dd if=u-boot/u-boot.itb of=/dev/sdb seek=16384 + +You should be able to get U-Boot log message with OP-TEE boot info. + +For more detail, please reference to: +http://opensource.rock-chips.com/wiki_Boot_option -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 11/11] rockchip: evb-rk322x: update defconfig with tpl and optee support
Enable all the options for TPL/SPL and OPTEE. Signed-off-by: Kever Yang --- Changes in v2: - update defconfig option configs/evb-rk3229_defconfig | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/configs/evb-rk3229_defconfig b/configs/evb-rk3229_defconfig index b226f66..025822d 100644 --- a/configs/evb-rk3229_defconfig +++ b/configs/evb-rk3229_defconfig @@ -4,14 +4,27 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x800 CONFIG_ROCKCHIP_RK322X=y -CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y +CONFIG_TPL_LDSCRIPT="arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds" +CONFIG_TPL_TEXT_BASE=0x10081000 +CONFIG_TPL_MAX_SIZE=28672 +CONFIG_TPL_STACK=0x10088000 +CONFIG_TPL_ROCKCHIP_BACK_TO_BROM=y +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x0 CONFIG_TARGET_EVB_RK3229=y -CONFIG_SPL_STACK_R_ADDR=0x8 +CONFIG_SPL_STACK_R_ADDR=0x6060 CONFIG_DEFAULT_DEVICE_TREE="rk3229-evb" CONFIG_DEBUG_UART=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_FIT_SOURCE="arch/arm/mach-rockchip/fit_spl_optee.its" # CONFIG_DISPLAY_CPUINFO is not set +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set +# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set CONFIG_SPL_STACK_R=y -CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200 +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000 +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x4000 +CONFIG_SPL_OPTEE=y CONFIG_FASTBOOT_FLASH=y CONFIG_FASTBOOT_FLASH_MMC_DEV=0 CONFIG_CMD_GPT=y @@ -19,14 +32,19 @@ CONFIG_CMD_MMC=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIME=y CONFIG_SPL_OF_CONTROL=y +CONFIG_TPL_OF_CONTROL=y CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" CONFIG_ENV_IS_IN_MMC=y +CONFIG_TPL_DM=y CONFIG_REGMAP=y CONFIG_SPL_REGMAP=y +CONFIG_TPL_REGMAP=y CONFIG_SYSCON=y CONFIG_SPL_SYSCON=y +CONFIG_TPL_SYSCON=y CONFIG_CLK=y CONFIG_SPL_CLK=y +CONFIG_TPL_CLK=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MMC_DW=y @@ -35,12 +53,14 @@ CONFIG_PINCTRL=y CONFIG_PINCTRL_ROCKCHIP_RK322X=y CONFIG_RAM=y CONFIG_SPL_RAM=y +CONFIG_TPL_RAM=y CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_BASE=0x1103 CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_SYS_NS16550=y CONFIG_SYSRESET=y +CONFIG_SPL_SYSRESET=y CONFIG_USB=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Rockchip" -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 06/11] image: add os type for OP-TEE
OP-TEE is an open source trust OS maintained here: https://github.com/OP-TEE/optee_os Signed-off-by: Kever Yang --- Changes in v2: - Add new image type like ATF common/image.c | 1 + include/image.h | 1 + 2 files changed, 2 insertions(+) diff --git a/common/image.c b/common/image.c index 4bcf6b3..597c025 100644 --- a/common/image.c +++ b/common/image.c @@ -91,6 +91,7 @@ static const table_entry_t uimage_arch[] = { static const table_entry_t uimage_os[] = { { IH_OS_INVALID, "invalid", "Invalid OS", }, + { IH_OS_OP_TEE, "op-tee", "OP-TEE" }, { IH_OS_ARM_TRUSTED_FIRMWARE, "arm-trusted-firmware", "ARM Trusted Firmware" }, { IH_OS_LINUX,"linux","Linux",}, #if defined(CONFIG_LYNXKDI) || defined(USE_HOSTCC) diff --git a/include/image.h b/include/image.h index a128a62..141ed00 100644 --- a/include/image.h +++ b/include/image.h @@ -153,6 +153,7 @@ enum { IH_OS_PLAN9,/* Plan 9 */ IH_OS_OPENRTOS, /* OpenRTOS */ IH_OS_ARM_TRUSTED_FIRMWARE, /* ARM Trusted Firmware */ + IH_OS_OP_TEE, /* OP-TEE */ IH_OS_COUNT, }; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 08/11] rockchip: rk322x: dts: enable uart2 for SPL/TPL
When we use DM_SERIAL for serial driver, we need enable the dts node for the debug console. Signed-off-by: Kever Yang --- Changes in v2: None arch/arm/dts/rk3229-evb.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/dts/rk3229-evb.dts b/arch/arm/dts/rk3229-evb.dts index ae0b0a4..fe4abe9 100644 --- a/arch/arm/dts/rk3229-evb.dts +++ b/arch/arm/dts/rk3229-evb.dts @@ -83,6 +83,7 @@ }; &uart2 { + u-boot,dm-pre-reloc; status = "okay"; }; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] [PATCH] arm64: mvebu: armada-8k: support SD card environment
Hi, Baruch, > -Original Message- > From: Baruch Siach [mailto:bar...@tkos.co.il] > Sent: Tuesday, December 19, 2017 08:43 > To: Kostya Porotchkin > Cc: Stefan Roese; u-boot@lists.denx.de; Sergey Matyukevich > Subject: Re: [EXT] [PATCH] arm64: mvebu: armada-8k: support SD card > environment > > Hi Kostya, > > Thanks for reviewing. > > On Thu, Dec 14, 2017 at 11:28:18AM +, Kostya Porotchkin wrote: > > > Allow storing the environment on the Macchiatobin SD card. This is > > > useful for distribution of SD card software images. Currently, the > > > environment is always loaded from the SPI flash whose content might > > > be incompatible with SD card kernel loading. > > > > > > Use the last 64KB of the 32MB boot partition as per the instructions > > > in the Macchiatobin wiki: > > > > > > http://wiki.macchiatobin.net/tiki- > > > index.php?page=Setup+alternative+boot+sources > > > > > > Cc: Konstantin Porotchkin > > > Signed-off-by: Baruch Siach > > > --- > > > include/configs/mvebu_armada-8k.h | 5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/include/configs/mvebu_armada-8k.h > > > b/include/configs/mvebu_armada-8k.h > > > index d85527434a0a..0457a72e353b 100644 > > > --- a/include/configs/mvebu_armada-8k.h > > > +++ b/include/configs/mvebu_armada-8k.h > > > @@ -73,7 +73,12 @@ > > > #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 > > > #define CONFIG_ENV_SPI_MODE CONFIG_SF_DEFAULT_MODE > > > > > > +#if defined(CONFIG_ENV_IS_IN_SPI_FLASH) > > > #define CONFIG_ENV_OFFSET0x18 /* as Marvell U-Boot > version */ > > > +#elif defined(CONFIG_ENV_IS_IN_MMC) > > > +#define CONFIG_SYS_MMC_ENV_DEV 1 > > > +#define CONFIG_ENV_OFFSET0x21f > > > +#endif > > > > I think this will break boot from the on-board eMMC device. > > Maybe the environment offset should be connected to the MMC device ID. > > So it will be different for SD and eMMC. > > The eMMC boot partition is not that big as the space on SD allocated > for the boot images. > > Additionally, the SD pre-allocated boot space is not really a constant > value. > > So what would you suggest? How can we detect the location of the SD/eMMC > stored environment? Would a per-board 'u-boot,mmc-env-offset' DT > property help? Maybe move to CONFIG_ENV_IS_IN_FAT? [Konstantin Porotchkin] What we know for sure is that partition 0 is always the data partition for both SD and eMMC. This is the only partition in case of SD and it less likely to be used with eMMC at all. So we can, for example, use your environment offset when the CONFIG_SYS_MMC_ENV_PART=0 As for the value of CONFIG_SYS_MMC_ENV_DEV, we cannot assume that it will have the same meaning for all Marvell A8K platforms. On some boards the device 1 may be the eMMC as well. Since this header is shared across all boards, I would not hard code the device 1 as SD. Using file for the environment storage when we boot from the data partition is also possible. In this case we do not have the dependency from the size of the empty space allocated before the first partition entry. Kosta > > baruch > > -- > http://baruch.siach.name/blog/ ~. .~ Tk Open > Systems > =}ooO--U--Ooo--- > -{= >- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il - ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 01/11] lib: add TPL_OF_LIBFDT option for TPL
TPL may need use libfdt for dt decode, add option for it. Signed-off-by: Kever Yang --- Changes in v3: None Changes in v2: None lib/Kconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/lib/Kconfig b/lib/Kconfig index f447c53..b43ef22 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -234,6 +234,16 @@ config SPL_OF_LIBFDT particular compatible nodes. The library operates on a flattened version of the device tree. +config TPL_OF_LIBFDT + bool "Enable the FDT library for TPL" + default y if TPL_OF_CONTROL + help + This enables the FDT library (libfdt). It provides functions for + accessing binary device tree images in memory, such as adding and + removing nodes and properties, scanning through the tree and finding + particular compatible nodes. The library operates on a flattened + version of the device tree. + config FDT_FIXUP_PARTITIONS bool "overwrite MTD partitions in DTS through defined in 'mtdparts'" depends on OF_LIBFDT -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 02/11] arm: add option for TPL ARCH_MEM in arm 32bit
Some options like TPL_SYS_THUMB_BUILD, TPL_USE_ARCH_MEMCPY and TPL_USE_ARCH_MEMCPY are needed for TPL build in 32bit arm. Signed-off-by: Kever Yang --- Changes in v3: None Changes in v2: - update subject with ARCH_MEM info arch/arm/Kconfig | 29 + 1 file changed, 29 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 7390995..4069227 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -244,6 +244,17 @@ config SPL_SYS_THUMB_BUILD density. For ARM architectures that support Thumb2 this flag will result in Thumb2 code generated by GCC. +config TPL_SYS_THUMB_BUILD + bool "Build TPL using the Thumb instruction set" + default y if SYS_THUMB_BUILD + depends on TPL && !ARM64 + help + Use this flag to build SPL using the Thumb instruction set for + ARM architectures. Thumb instruction set provides better code + density. For ARM architectures that support Thumb2 this flag will + result in Thumb2 code generated by GCC. + + config SYS_L2CACHE_OFF bool "L2cache off" help @@ -280,6 +291,15 @@ config SPL_USE_ARCH_MEMCPY Such implementation may be faster under some conditions but may increase the binary size. +config TPL_USE_ARCH_MEMCPY + bool "Use an assembly optimized implementation of memcpy for TPL" + default y if USE_ARCH_MEMCPY + depends on !ARM64 + help + Enable the generation of an optimized version of memcpy. + Such implementation may be faster under some conditions + but may increase the binary size. + config USE_ARCH_MEMSET bool "Use an assembly optimized implementation of memset" default y @@ -298,6 +318,15 @@ config SPL_USE_ARCH_MEMSET Such implementation may be faster under some conditions but may increase the binary size. +config TPL_USE_ARCH_MEMSET + bool "Use an assembly optimized implementation of memset for TPL" + default y if USE_ARCH_MEMSET + depends on !ARM64 + help + Enable the generation of an optimized version of memset. + Such implementation may be faster under some conditions + but may increase the binary size. + config ARM64_SUPPORT_AARCH32 bool "ARM64 system support AArch32 execution state" default y if ARM64 && !TARGET_THUNDERX_88XX -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 05/11] sysreset: enable driver support in SPL/TPL
SPL/TPL also need use sysreset for some feature like panic callback. Signed-off-by: Kever Yang --- Changes in v3: None Changes in v2: None drivers/sysreset/Kconfig | 18 ++ drivers/sysreset/Makefile | 2 +- 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig index a6d48e8..a61a7d3 100644 --- a/drivers/sysreset/Kconfig +++ b/drivers/sysreset/Kconfig @@ -13,6 +13,24 @@ config SYSRESET to effect a reset. The uclass will try all available drivers when reset_walk() is called. +config SPL_SYSRESET + bool "Enable support for system reset drivers in SPL mode" + depends on SYSRESET && SPL_DM + help + Enable system reset drivers which can be used to reset the CPU or + board. Each driver can provide a reset method which will be called + to effect a reset. The uclass will try all available drivers when + reset_walk() is called. + +config TPL_SYSRESET + bool "Enable support for system reset drivers in TPL mode" + depends on SYSRESET && TPL_DM + help + Enable system reset drivers which can be used to reset the CPU or + board. Each driver can provide a reset method which will be called + to effect a reset. The uclass will try all available drivers when + reset_walk() is called. + if SYSRESET config SYSRESET_PSCI diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile index 2e9598e..00be747 100644 --- a/drivers/sysreset/Makefile +++ b/drivers/sysreset/Makefile @@ -4,7 +4,7 @@ # SPDX-License-Identifier: GPL-2.0+ # -obj-$(CONFIG_SYSRESET) += sysreset-uclass.o +obj-$(CONFIG_$(SPL_TPL_)SYSRESET) += sysreset-uclass.o obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 03/11] arm: add a separate stack for TPL
TPL stack may different from SPL and sys stack, add support for separate one when the board defines it. Signed-off-by: Kever Yang --- Changes in v3: None Changes in v2: None arch/arm/lib/crt0.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index fa81317..3c1c603 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -70,7 +70,9 @@ ENTRY(_main) * Set up initial C runtime environment and call board_init_f(0). */ -#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) +#if defined(CONFIG_TPL_BUILD) && defined(CONFIG_TPL_NEEDS_SEPARATE_STACK) + ldr r0, =(CONFIG_TPL_STACK) +#elif defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) ldr r0, =(CONFIG_SPL_STACK) #else ldr r0, =(CONFIG_SYS_INIT_SP_ADDR) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 10/11] rockchip: evb-rk3229: add README file for OP-TEE support
Detail of step by step to bring up the board with OP-TEE support. Signed-off-by: Kever Yang --- Changes in v3: None Changes in v2: None board/rockchip/evb_rk3229/README | 72 1 file changed, 72 insertions(+) create mode 100644 board/rockchip/evb_rk3229/README diff --git a/board/rockchip/evb_rk3229/README b/board/rockchip/evb_rk3229/README new file mode 100644 index 000..46c54c2 --- /dev/null +++ b/board/rockchip/evb_rk3229/README @@ -0,0 +1,72 @@ +Get the Source and prebuild binary +== + + > mkdir ~/evb_rk3229 + > cd ~/evb_rk3229 + > git clone git://git.denx.de/u-boot.git + > git clone https://github.com/OP-TEE/optee_os.git + > git clone https://github.com/rockchip-linux/rkbin.git + > git clone https://github.com/rockchip-linux/rkdeveloptool.git + +Compile the OP-TEE +=== + + > cd optee_os + > make clean + > make CROSS_COMPILE_ta_arm32=arm-none-eabi- PLATFORM=rockchip-rk322x + Get tee.bin in this step, copy it to U-Boot root dir: + > cp out/arm-plat-rockchip/core/tee-pager.bin ../u-boot/tee.bin + +Compile the U-Boot +== + + > cd ../u-boot + > export CROSS_COMPILE=arm-linux-gnueabihf- + > export ARCH=arm + > make evb-rk3229_defconfig + > make + > make u-boot.itb + + Get tpl/u-boot-tpl.bin, spl/u-boot-spl.bin and u-boot.itb in this step. + +Compile the rkdeveloptool +=== + Follow instructions in latest README + > cd ../rkdeveloptool + > autoreconf -i + > ./configure + > make + > sudo make install + + Get rkdeveloptool in you Host in this step. + +Both origin binaries and Tool are ready now, choose either option 1 or +option 2 to deploy U-Boot. + +Package the image += + + > cd ../u-boot + > tools/mkimage -n rk322x -T rksd -d tpl/u-boot-spl.bin idbloader.img + > cat spl/u-boot-spl.bin >> idbloader.img + + Get idbloader.img in this step. + +Flash the image to eMMC +=== +Power on(or reset with RESET KEY) with MASKROM KEY preesed, and then: + > cd .. + > rkdeveloptool db rkbin/rk32/rk322x_loader_v1.04.232.bin + > rkdeveloptool wl 64 u-boot/idbloader.img + > rkdeveloptool wl 0x4000 u-boot/u-boot.itb + > rkdeveloptool rd + +Flash the image to SD card +== + > dd if=u-boot/idbloader.img of=/dev/sdb seek=64 + > dd if=u-boot/u-boot.itb of=/dev/sdb seek=16384 + +You should be able to get U-Boot log message with OP-TEE boot info. + +For more detail, please reference to: +http://opensource.rock-chips.com/wiki_Boot_option -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 07/11] spl: add support to booting with OP-TEE
OP-TEE is an open source trusted OS, in armv7, its loading and running are like this: loading: - SPL load both OP-TEE and U-Boot running: - SPL run into OP-TEE in secure mode; - OP-TEE run into U-Boot in non-secure mode; More detail: https://github.com/OP-TEE/optee_os and search for 'boot arguments' for detail entry parameter in: core/arch/arm/kernel/generic_entry_a32.S Signed-off-by: Kever Yang --- Changes in v3: None Changes in v2: - Using new image type for op-tee common/spl/Kconfig | 7 +++ common/spl/Makefile| 1 + common/spl/spl.c | 8 common/spl/spl_optee.S | 13 + include/spl.h | 9 + 5 files changed, 38 insertions(+) create mode 100644 common/spl/spl_optee.S diff --git a/common/spl/Kconfig b/common/spl/Kconfig index aef0034..c9a1ebb 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -725,6 +725,13 @@ config SPL_ATF is loaded by SPL(which is considered as BL2 in ATF terminology). More detail at: https://github.com/ARM-software/arm-trusted-firmware +config SPL_OPTEE + bool "Support OP-TEE Trusted OS" + depends on ARM + help + OP-TEE is an open source Trusted OS which is loaded by SPL. + More detail at: https://github.com/OP-TEE/optee_os + config TPL bool depends on SUPPORT_TPL diff --git a/common/spl/Makefile b/common/spl/Makefile index 9bf8a2d..9918a2e 100644 --- a/common/spl/Makefile +++ b/common/spl/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_$(SPL_TPL_)UBI) += spl_ubi.o obj-$(CONFIG_$(SPL_TPL_)NET_SUPPORT) += spl_net.o obj-$(CONFIG_$(SPL_TPL_)MMC_SUPPORT) += spl_mmc.o obj-$(CONFIG_$(SPL_TPL_)ATF) += spl_atf.o +obj-$(CONFIG_$(SPL_TPL_)OPTEE) += spl_optee.o obj-$(CONFIG_$(SPL_TPL_)USB_SUPPORT) += spl_usb.o obj-$(CONFIG_$(SPL_TPL_)FAT_SUPPORT) += spl_fat.o obj-$(CONFIG_$(SPL_TPL_)EXT_SUPPORT) += spl_ext.o diff --git a/common/spl/spl.c b/common/spl/spl.c index 76c1963..2c8942b 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -436,6 +436,12 @@ void board_init_r(gd_t *dummy1, ulong dummy2) spl_invoke_atf(&spl_image); break; #endif +#if CONFIG_IS_ENABLED(OPTEE) + case IH_OS_OP_TEE: + debug("Jumping to U-Boot via OP-TEE\n"); + spl_optee_entry(0, 0, 0, (void *)spl_image.entry_point); + break; +#endif #ifdef CONFIG_SPL_OS_BOOT case IH_OS_LINUX: debug("Jumping to Linux\n"); @@ -450,6 +456,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2) debug("SPL malloc() used %#lx bytes (%ld KB)\n", gd->malloc_ptr, gd->malloc_ptr / 1024); #endif + + debug("loaded - jumping to U-Boot...\n"); #ifdef CONFIG_BOOTSTAGE_STASH int ret; diff --git a/common/spl/spl_optee.S b/common/spl/spl_optee.S new file mode 100644 index 000..4f7f8ba --- /dev/null +++ b/common/spl/spl_optee.S @@ -0,0 +1,13 @@ +/* + * Copyright (C) 2017 Rockchip Electronic Co.,Ltd + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include + +ENTRY(spl_optee_entry) + ldr lr, =CONFIG_SYS_TEXT_BASE + mov pc, r3 +ENDPROC(spl_optee_entry) diff --git a/include/spl.h b/include/spl.h index c14448b..551ce43 100644 --- a/include/spl.h +++ b/include/spl.h @@ -288,6 +288,15 @@ int spl_mmc_load_image(struct spl_image_info *spl_image, void spl_invoke_atf(struct spl_image_info *spl_image); /** + * spl_optee_entry - entry function for optee + * entry arg0, pagestore + * entry arg1, (ARMv7 standard bootarg #1) + * entry arg2, device tree address, (ARMv7 standard bootarg #2) + * entry arg3, non-secure entry address (ARMv7 bootarg #0) + */ +void spl_optee_entry(void *arg0, void *arg1, void *arg2, void *arg3); + +/** * board_return_to_bootrom - allow for boards to continue with the boot ROM * * If a board (e.g. the Rockchip RK3368 boards) provide some -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 06/11] image: add os type for OP-TEE
OP-TEE is an open source trust OS maintained here: https://github.com/OP-TEE/optee_os Signed-off-by: Kever Yang --- Changes in v3: None Changes in v2: - Add new image type like ATF common/image.c | 1 + include/image.h | 1 + 2 files changed, 2 insertions(+) diff --git a/common/image.c b/common/image.c index 4bcf6b3..597c025 100644 --- a/common/image.c +++ b/common/image.c @@ -91,6 +91,7 @@ static const table_entry_t uimage_arch[] = { static const table_entry_t uimage_os[] = { { IH_OS_INVALID, "invalid", "Invalid OS", }, + { IH_OS_OP_TEE, "op-tee", "OP-TEE" }, { IH_OS_ARM_TRUSTED_FIRMWARE, "arm-trusted-firmware", "ARM Trusted Firmware" }, { IH_OS_LINUX,"linux","Linux",}, #if defined(CONFIG_LYNXKDI) || defined(USE_HOSTCC) diff --git a/include/image.h b/include/image.h index a128a62..141ed00 100644 --- a/include/image.h +++ b/include/image.h @@ -153,6 +153,7 @@ enum { IH_OS_PLAN9,/* Plan 9 */ IH_OS_OPENRTOS, /* OpenRTOS */ IH_OS_ARM_TRUSTED_FIRMWARE, /* ARM Trusted Firmware */ + IH_OS_OP_TEE, /* OP-TEE */ IH_OS_COUNT, }; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 09/11] rockchip: add fit source file for pack itb with op-tee
We package U-Boot and OP-TEE into one itb file for SPL, so that we can support OP-TEE in SPL. Signed-off-by: Kever Yang --- Changes in v3: None Changes in v2: - Make the its as common file used for all armv7 with op-tee arch/arm/mach-rockchip/fit_spl_optee.its | 50 1 file changed, 50 insertions(+) create mode 100644 arch/arm/mach-rockchip/fit_spl_optee.its diff --git a/arch/arm/mach-rockchip/fit_spl_optee.its b/arch/arm/mach-rockchip/fit_spl_optee.its new file mode 100644 index 000..3aeecb8 --- /dev/null +++ b/arch/arm/mach-rockchip/fit_spl_optee.its @@ -0,0 +1,50 @@ +/* + * Copyright (C) 2017 Rockchip Electronic Co.,Ltd + * + * Simple U-boot fit source file containing U-Boot, dtb and optee + */ + +/dts-v1/; + +/ { + description = "Simple image with OP-TEE support"; + #address-cells = <1>; + + images { + uboot@1 { + description = "U-Boot"; + data = /incbin/("../../../u-boot-nodtb.bin"); + type = "standalone"; + os = "U-Boot"; + arch = "arm"; + compression = "none"; + load = <0x6100>; + }; + optee@1 { + description = "OP-TEE"; + data = /incbin/("../../../tee.bin"); + type = "firmware"; + arch = "arm"; + os = "op-tee"; + compression = "none"; + load = <0x6840>; + entry = <0x6840>; + }; + fdt@1 { + description = "dtb"; + data = /incbin/("../../../u-boot.dtb"); + type = "flat_dt"; + compression = "none"; + }; + }; + + configurations { + default = "conf@1"; + conf@1 { + description = "Rockchip armv7 with OP-TEE"; + firmware = "optee@1"; + loadables = "uboot@1"; + fdt = "fdt@1"; + }; + }; +}; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 04/11] rockchip: rk322x: enable tpl support
Move original spl to tpl, and add spl to load next stage firmware, adapt all the address and option for them. Serial-changes: 2 - update upon latest source Signed-off-by: Kever Yang --- Changes in v3: - do not init ddr region in spl Changes in v2: None arch/arm/mach-rockchip/Kconfig | 9 +++ arch/arm/mach-rockchip/Makefile | 3 +- arch/arm/mach-rockchip/rk322x-board-spl.c| 63 +-- arch/arm/mach-rockchip/rk322x-board-tpl.c| 90 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds | 13 include/configs/rk322x_common.h | 9 ++- 6 files changed, 134 insertions(+), 53 deletions(-) create mode 100644 arch/arm/mach-rockchip/rk322x-board-tpl.c create mode 100644 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 967290f..dbc197c 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -46,9 +46,18 @@ config ROCKCHIP_RK322X bool "Support Rockchip RK3228/RK3229" select CPU_V7 select SUPPORT_SPL + select SUPPORT_TPL select SPL + select TPL + select TPL_NEEDS_SEPARATE_TEXT_BASE if SPL + select TPL_NEEDS_SEPARATE_STACK if TPL + select SPL_DRIVERS_MISC_SUPPORT + imply SPL_SERIAL_SUPPORT + imply TPL_SERIAL_SUPPORT select ROCKCHIP_BROM_HELPER select DEBUG_UART_BOARD_INIT + select TPL_LIBCOMMON_SUPPORT + select TPL_LIBGENERIC_SUPPORT help The Rockchip RK3229 is a ARM-based SoC with a dual-core Cortex-A7 including NEON and GPU, Mali-400 graphics, several DDR3 options diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile index e1b0519..3c14236 100644 --- a/arch/arm/mach-rockchip/Makefile +++ b/arch/arm/mach-rockchip/Makefile @@ -13,10 +13,11 @@ obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o obj-tpl-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-tpl.o obj-tpl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-tpl.o +obj-tpl-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board-tpl.o obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o obj-spl-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board-spl.o -obj-spl-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board-spl.o +obj-spl-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board-spl.o spl-boot-order.o obj-spl-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-spl.o obj-spl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-spl.o spl-boot-order.o obj-spl-$(CONFIG_ROCKCHIP_RK3399) += rk3399-board-spl.o spl-boot-order.o diff --git a/arch/arm/mach-rockchip/rk322x-board-spl.c b/arch/arm/mach-rockchip/rk322x-board-spl.c index 35f4f97..89af1d9 100644 --- a/arch/arm/mach-rockchip/rk322x-board-spl.c +++ b/arch/arm/mach-rockchip/rk322x-board-spl.c @@ -5,77 +5,46 @@ */ #include -#include #include -#include #include -#include -#include -#include -#include -#include -#include -#include + +DECLARE_GLOBAL_DATA_PTR; u32 spl_boot_device(void) { return BOOT_DEVICE_MMC1; } -DECLARE_GLOBAL_DATA_PTR; -#define GRF_BASE 0x1100 -#define SGRF_BASE 0x1014 - -#define DEBUG_UART_BASE0x1103 +u32 spl_boot_mode(const u32 boot_device) +{ + return MMCSD_MODE_RAW; +} void board_debug_uart_init(void) { -static struct rk322x_grf * const grf = (void *)GRF_BASE; - /* Enable early UART2 channel 1 on the RK322x */ - rk_clrsetreg(&grf->gpio1b_iomux, -GPIO1B1_MASK | GPIO1B2_MASK, -GPIO1B2_UART21_SIN << GPIO1B2_SHIFT | -GPIO1B1_UART21_SOUT << GPIO1B1_SHIFT); - /* Set channel C as UART2 input */ - rk_clrsetreg(&grf->con_iomux, -CON_IOMUX_UART2SEL_MASK, -CON_IOMUX_UART2SEL_21 << CON_IOMUX_UART2SEL_SHIFT); } -#define SGRF_DDR_CON0 0x1015 void board_init_f(ulong dummy) { - struct udevice *dev; int ret; - /* -* Debug UART can be used from here if required: -* -* debug_uart_init(); -* printch('a'); -* printhex8(0x1234); -* printascii("string"); -*/ - debug_uart_init(); - printascii("SPL Init"); - ret = spl_early_init(); if (ret) { - debug("spl_early_init() failed: %d\n", ret); + printf("spl_early_init() failed: %d\n", ret); hang(); } + preloader_console_init(); +} - rockchip_timer_init(); - printf("timer init done\n"); - ret = uclass_get_device(UCLASS_RAM, 0, &dev); - if (ret) { - printf("DRAM init failed: %d\n", ret); - return; - } +#ifdef CONFIG_SPL_LOAD_FIT +int board_fit_config_name_match(const char *name) +{ + /* Just empty function now - can't decide what to choose */ + debug("%s: %s\n", __func__, name); - /* Disable the ddr secure region setting to make it non-secure */ -
[U-Boot] [PATCH v3 08/11] rockchip: rk322x: dts: enable uart2 for SPL/TPL
When we use DM_SERIAL for serial driver, we need enable the dts node for the debug console. Signed-off-by: Kever Yang --- Changes in v3: None Changes in v2: None arch/arm/dts/rk3229-evb.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/dts/rk3229-evb.dts b/arch/arm/dts/rk3229-evb.dts index ae0b0a4..fe4abe9 100644 --- a/arch/arm/dts/rk3229-evb.dts +++ b/arch/arm/dts/rk3229-evb.dts @@ -83,6 +83,7 @@ }; &uart2 { + u-boot,dm-pre-reloc; status = "okay"; }; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] sunxi: arm64: correct usage of DT node address in FIT generation
Hi Simon, thanks for going through this! On 19/12/17 04:24, Simon Glass wrote: > Hi Andre, > > On 3 December 2017 at 19:05, Andre Przywara wrote: >> The DT spec demands a unit-address in a node name to match the "reg" >> property in that node. Newer dtc versions will throw warnings if this is >> not the case. >> Adjust the FIT build script for 64-bit Allwinner boards to remove the >> bogus addresses from the node names and avoid the warnings. >> This avoids a warning with recent versions of the dtc tool. >> >> Signed-off-by: Andre Przywara >> --- >> board/sunxi/mksunxi_fit_atf.sh | 16 >> 1 file changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh >> index b1d6e0e16a..36abe9efed 100755 >> --- a/board/sunxi/mksunxi_fit_atf.sh >> +++ b/board/sunxi/mksunxi_fit_atf.sh >> @@ -21,7 +21,7 @@ cat << __HEADER_EOF >> #address-cells = <1>; >> >> images { >> - uboot@1 { >> + uboot { >> description = "U-Boot (64-bit)"; >> data = /incbin/("u-boot-nodtb.bin"); >> type = "standalone"; >> @@ -29,7 +29,7 @@ cat << __HEADER_EOF >> compression = "none"; >> load = <0x4a00>; >> }; >> - atf@1 { >> + atf { >> description = "ARM Trusted Firmware"; >> data = /incbin/("$BL31"); >> type = "firmware"; >> @@ -44,7 +44,7 @@ cnt=1 >> for dtname in $* >> do >> cat << __FDT_IMAGE_EOF >> - fdt@$cnt { >> + fdt_$cnt { >> description = "$(basename $dtname .dtb)"; >> data = /incbin/("$dtname"); >> type = "flat_dt"; >> @@ -57,7 +57,7 @@ done >> cat << __CONF_HEADER_EOF >> }; >> configurations { >> - default = "config@1"; >> + default = "config_1"; > > Have you changed from hyphen to underscore here? Arrgh, indeed. I think that was the first version of the patch, before I changed to '-'. Sorry for that, will fix it. Cheers, Andre. > >> >> __CONF_HEADER_EOF >> >> @@ -65,11 +65,11 @@ cnt=1 >> for dtname in $* >> do >> cat << __CONF_SECTION_EOF >> - config@$cnt { >> + config_$cnt { >> description = "$(basename $dtname .dtb)"; >> - firmware = "uboot@1"; >> - loadables = "atf@1"; >> - fdt = "fdt@$cnt"; >> + firmware = "uboot"; >> + loadables = "atf"; >> + fdt = "fdt_$cnt"; >> }; >> __CONF_SECTION_EOF >> cnt=$((cnt+1)) >> -- >> 2.14.1 >> > > Regards, > Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] Rework : Please pull u-boot-imx
Hi Tom, Martyn, On 18/12/2017 18:22, Tom Rini wrote: > On Sun, Dec 17, 2017 at 10:50:49PM +0100, Stefano Babic wrote: > >> Hi Tom, >> >> please pull from u-boot-imx ("power: pmic/regulator allow dm be omitted >> by SPL" dropped), thanks ! >> >> The following changes since commit fcc8250c2f7c982f3593a8eecf737f8e2c95f222: >> >> Merge git://git.denx.de/u-boot-mips (2017-11-28 16:54:30 -0500) >> >> are available in the git repository at: >> >> git://www.denx.de/git/u-boot-imx.git master >> >> for you to fetch changes up to 7efc2dbfb2fa04bd4111615a8afb0822d6b88b09: >> >> arm: imx: add tzic interrupt controller for imx53 (2017-12-17 22:34:01 >> +0100) >> >> > [snip] >> Hannu Lounento (5): >> net: e1000: add support for writing to EEPROM >> net: e1000: split e1000_read_mac_addr >> net: e1000: implement eth_write_hwaddr >> board: ge: bx50v3: program MAC address to I210 > > This first patch adds a bunch of warnings about > e1000_update_eeprom_checksum_i210 being declared static and unused. > It's unused in the case of DM_ETH being set because we don't have > e1000_initialize and company compiled in, and thus no e1000_write_hwaddr > and thus no callers of e1000_update_eeprom_checksum_i210. Given that I > see on my calendar a reminder that in early 2018 I need to make a lack > of DM conversion of $X a lot louder of warning, are these 4 things > imporant fixes that must come in now, or something that can be baked a > bit longer? They are not fixes, but they add a feature (writing the EEPROM) that is used by GE in the mx53ppd board. If I drop those, I had to remove all patches because they depend on these four. I can do, but I forward the question to Martyn who is the originator of the series. > > To see the warnings, build for say qemu-x86_64. Thanks! > I see, right, thanks. Martyn, can you take a lookt at this ? If we are not hurry, I can put your series in the -next branch of u-boot-imx and let Tom to pull without them. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 11/11] rockchip: evb-rk322x: update defconfig with tpl and optee support
Enable all the options for TPL/SPL and OPTEE. Signed-off-by: Kever Yang --- Changes in v3: None Changes in v2: - update defconfig option configs/evb-rk3229_defconfig | 26 +++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/configs/evb-rk3229_defconfig b/configs/evb-rk3229_defconfig index b226f66..025822d 100644 --- a/configs/evb-rk3229_defconfig +++ b/configs/evb-rk3229_defconfig @@ -4,14 +4,27 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x800 CONFIG_ROCKCHIP_RK322X=y -CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y +CONFIG_TPL_LDSCRIPT="arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds" +CONFIG_TPL_TEXT_BASE=0x10081000 +CONFIG_TPL_MAX_SIZE=28672 +CONFIG_TPL_STACK=0x10088000 +CONFIG_TPL_ROCKCHIP_BACK_TO_BROM=y +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x0 CONFIG_TARGET_EVB_RK3229=y -CONFIG_SPL_STACK_R_ADDR=0x8 +CONFIG_SPL_STACK_R_ADDR=0x6060 CONFIG_DEFAULT_DEVICE_TREE="rk3229-evb" CONFIG_DEBUG_UART=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_FIT_SOURCE="arch/arm/mach-rockchip/fit_spl_optee.its" # CONFIG_DISPLAY_CPUINFO is not set +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set +# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set CONFIG_SPL_STACK_R=y -CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200 +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000 +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x4000 +CONFIG_SPL_OPTEE=y CONFIG_FASTBOOT_FLASH=y CONFIG_FASTBOOT_FLASH_MMC_DEV=0 CONFIG_CMD_GPT=y @@ -19,14 +32,19 @@ CONFIG_CMD_MMC=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIME=y CONFIG_SPL_OF_CONTROL=y +CONFIG_TPL_OF_CONTROL=y CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" CONFIG_ENV_IS_IN_MMC=y +CONFIG_TPL_DM=y CONFIG_REGMAP=y CONFIG_SPL_REGMAP=y +CONFIG_TPL_REGMAP=y CONFIG_SYSCON=y CONFIG_SPL_SYSCON=y +CONFIG_TPL_SYSCON=y CONFIG_CLK=y CONFIG_SPL_CLK=y +CONFIG_TPL_CLK=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MMC_DW=y @@ -35,12 +53,14 @@ CONFIG_PINCTRL=y CONFIG_PINCTRL_ROCKCHIP_RK322X=y CONFIG_RAM=y CONFIG_SPL_RAM=y +CONFIG_TPL_RAM=y CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_BASE=0x1103 CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_SYS_NS16550=y CONFIG_SYSRESET=y +CONFIG_SPL_SYSRESET=y CONFIG_USB=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Rockchip" -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] drivers/reset: support rockchip reset drivers
Kever, while this version has finally fixed the build errors for the rockchip-targets, it still causes major build failures for other target families: see https://travis-ci.org/ptomsich/u-boot-rockchip/builds/318128281 The new driver still appears to be built for the failing boards. Regards, Philipp. > On 18 Dec 2017, at 09:49, Kever Yang wrote: > > From: Elaine Zhang > > Create driver to support all Rockchip SoCs soft reset. > Example of usage: > i2c driver: > ret = reset_get_by_name(dev, "i2c", &reset_ctl); > if (ret) { > error("reset_get_by_name() failed: %d\n", ret); > } > > reset_assert(&reset_ctl); > udelay(50); > reset_deassert(&reset_ctl); > > i2c dts node: > resets = <&cru SRST_P_I2C1>, <&cru SRST_I2C1>; > reset-names = "p_i2c", "i2c"; > > Signed-off-by: Elaine Zhang > Signed-off-by: Kever Yang > --- > > Changes in v4: None > Changes in v3: None > Changes in v2: > - fix Kconfig more than 80 length > - use MACRO for reset bits in one reg > - use rkclr/set_reg for reg access > - add rockchip_reset_bind() > - use dev_read_addr_size() instead of fdtdec_ > > drivers/reset/Kconfig | 9 +++ > drivers/reset/Makefile | 1 + > drivers/reset/reset-rockchip.c | 133 + > 3 files changed, 143 insertions(+) > create mode 100644 drivers/reset/reset-rockchip.c > > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig > index ce46e27..97a78d7 100644 > --- a/drivers/reset/Kconfig > +++ b/drivers/reset/Kconfig > @@ -74,4 +74,13 @@ config AST2500_RESET > resets that are supported by watchdog. The main limitation though > is that some reset signals, like I2C or MISC reset multiple devices. > > +config RESET_ROCKCHIP > + bool "Reset controller driver for Rockchip SoCs" > + depends on DM_RESET && CLK > + default y > + help > + Support for reset controller on rockchip SoC. The main limitation > + though is that some reset signals, like I2C or MISC reset multiple > + devices. > + > endmenu > diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile > index 252cefe..7d7e080 100644 > --- a/drivers/reset/Makefile > +++ b/drivers/reset/Makefile > @@ -12,3 +12,4 @@ obj-$(CONFIG_TEGRA186_RESET) += tegra186-reset.o > obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o > obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o > obj-$(CONFIG_AST2500_RESET) += ast2500-reset.o > +obj-$(CONFIG_RESET_ROCKCHIP) += reset-rockchip.o > diff --git a/drivers/reset/reset-rockchip.c b/drivers/reset/reset-rockchip.c > new file mode 100644 > index 000..01047a2 > --- /dev/null > +++ b/drivers/reset/reset-rockchip.c > @@ -0,0 +1,133 @@ > +/* > + * (C) Copyright 2017 Rockchip Electronics Co., Ltd > + * > + * SPDX-License-Identifier: GPL-2.0 > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +/* > + * Each reg has 16 bits reset signal for devices > + * Note: Not including rk2818 and older SoCs > + */ > +#define ROCKCHIP_RESET_NUM_IN_REG16 > + > +struct rockchip_reset_priv { > + void __iomem *base; > + /* Rockchip reset reg locate at cru controller */ > + u32 reset_reg_offset; > + /* Rockchip reset reg number */ > + u32 reset_reg_num; > +}; > + > +static int rockchip_reset_request(struct reset_ctl *reset_ctl) > +{ > + struct rockchip_reset_priv *priv = dev_get_priv(reset_ctl->dev); > + > + debug("%s(reset_ctl=%p) (dev=%p, id=%lu) (reg_num=%d)\n", __func__, > + reset_ctl, reset_ctl->dev, reset_ctl->id, priv->reset_reg_num); > + > + if (reset_ctl->id / ROCKCHIP_RESET_NUM_IN_REG >= priv->reset_reg_num) > + return -EINVAL; > + > + return 0; > +} > + > +static int rockchip_reset_free(struct reset_ctl *reset_ctl) > +{ > + debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, reset_ctl, > + reset_ctl->dev, reset_ctl->id); > + > + return 0; > +} > + > +static int rockchip_reset_assert(struct reset_ctl *reset_ctl) > +{ > + struct rockchip_reset_priv *priv = dev_get_priv(reset_ctl->dev); > + int bank = reset_ctl->id / ROCKCHIP_RESET_NUM_IN_REG; > + int offset = reset_ctl->id % ROCKCHIP_RESET_NUM_IN_REG; > + > + debug("%s(reset_ctl=%p) (dev=%p, id=%lu) (reg_addr=%p)\n", __func__, > + reset_ctl, reset_ctl->dev, reset_ctl->id, > + priv->base + (bank * 4)); > + > + rk_setreg(priv->base + (bank * 4), BIT(offset)); > + > + return 0; > +} > + > +static int rockchip_reset_deassert(struct reset_ctl *reset_ctl) > +{ > + struct rockchip_reset_priv *priv = dev_get_priv(reset_ctl->dev); > + int bank = reset_ctl->id / ROCKCHIP_RESET_NUM_IN_REG; > + int offset = reset_ctl->id % ROCKCHIP_RESET_NUM_IN_REG; > + > + debug("%s(reset_ctl=%p) (dev=%p, id=%lu) (reg_addr=%p)\n", __func__, > + reset_ctl, reset_ctl->dev, reset_ctl->id, > + priv->base + (bank * 4)); > + > + rk_clrreg(priv->base + (ban
Re: [U-Boot] [PATCH 09/13] board: ti: am574x-idk: Add ddr data support
Hi Lokesh, > Hi Lukas, > > On Monday 18 December 2017 04:46 PM, Lukasz Majewski wrote: > > Hi Lokesh, > > > >> AM574x-idk has the following DDR parts attached: > >> EMIF1: MT41K256M16HA (1GB with ECC) > >> EMIF2: MT41K256M16HA (1GB without ECC) > >> > >> Enabling 2GB DDR without interleaving between EMIFs. And > >> enabling ECC on EMIF1. > >> > >> Signed-off-by: Lokesh Vutla > >> Signed-off-by: Krunal Bhargav > >> --- > >> board/ti/am57xx/board.c | 47 > >> --- 1 file changed, 44 > >> insertions(+), 3 deletions(-) > >> > >> diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c > >> index 2d14ae54fe..1377c7b1fe 100644 > >> --- a/board/ti/am57xx/board.c > >> +++ b/board/ti/am57xx/board.c > >> @@ -89,10 +89,18 @@ static const struct dmm_lisa_map_regs > >> am571x_idk_lisa_regs = { .is_ma_present = 0x1 > >> }; > >> > >> +static const struct dmm_lisa_map_regs am574x_idk_lisa_regs = { > >> + .dmm_lisa_map_2 = 0xc0600200, > >> + .dmm_lisa_map_3 = 0x80600100, > >> + .is_ma_present = 0x1 > >> +}; > >> + > >> void emif_get_dmm_regs(const struct dmm_lisa_map_regs > >> **dmm_lisa_regs) { > >>if (board_is_am571x_idk()) > >>*dmm_lisa_regs = &am571x_idk_lisa_regs; > >> + else if (board_is_am574x_idk()) > >> + *dmm_lisa_regs = &am574x_idk_lisa_regs; > >>else > >>*dmm_lisa_regs = &beagle_x15_lisa_regs; > >> } > >> @@ -231,8 +239,8 @@ static const struct emif_regs > >> am571x_emif1_ddr3_666mhz_emif_regs = > >> { .ref_ctrl= > >> 0x514d, .ref_ctrl_final= > >> 0x144a, .sdram_tim1= 0xd333887c, > >> - .sdram_tim2 = 0x40b37fe3, > >> - .sdram_tim3 = 0x409f8ada, > >> + .sdram_tim2 = 0x30b37fe3, > >> + .sdram_tim3 = 0x409f8ad8, > >>.read_idle_ctrl = 0x0005, > >>.zq_config = 0x5007190b, > >>.temp_alert_config = 0x, > >> @@ -249,17 +257,50 @@ static const struct emif_regs > >> am571x_emif1_ddr3_666mhz_emif_regs = > >> { .emif_rd_wr_exec_thresh = 0x0305 }; > >> > >> +static const struct emif_regs > >> am574x_emif1_ddr3_666mhz_emif_ecc_regs = { > >> + .sdram_config_init = 0x61863332, > >> + .sdram_config = 0x61863332, > >> + .sdram_config2 = 0x0800, > >> + .ref_ctrl = 0x514d, > >> + .ref_ctrl_final = 0x144a, > >> + .sdram_tim1 = 0xd333887c, > >> + .sdram_tim2 = 0x30b37fe3, > >> + .sdram_tim3 = 0x409f8ad8, > >> + .read_idle_ctrl = 0x0005, > >> + .zq_config = 0x5007190b, > >> + .temp_alert_config = 0x, > >> + .emif_ddr_phy_ctlr_1_init = 0x0024400f, > >> + .emif_ddr_phy_ctlr_1= 0x0e24400f, > >> + .emif_ddr_ext_phy_ctrl_1= 0x10040100, > >> + .emif_ddr_ext_phy_ctrl_2= 0x00910091, > >> + .emif_ddr_ext_phy_ctrl_3= 0x00950095, > >> + .emif_ddr_ext_phy_ctrl_4= 0x009b009b, > >> + .emif_ddr_ext_phy_ctrl_5= 0x009e009e, > >> + .emif_rd_wr_lvl_rmp_win = 0x, > >> + .emif_rd_wr_lvl_rmp_ctl = 0x8000, > >> + .emif_rd_wr_lvl_ctl = 0x, > >> + .emif_rd_wr_exec_thresh = 0x0305, > >> + .emif_ecc_ctrl_reg = 0xD001, > >> + .emif_ecc_address_range_1 = 0x3FFF, > >> + .emif_ecc_address_range_2 = 0x > >> +}; > > > > I'm wondering if it would be possible to: > > > > Embed this memory setup (even as binary blob) to SPL FIT -> Those > > values are generated from TI supplied excel sheet (when memory > > details are provided). > > > > > > Pros: > > > > > > - Since the same EMIF controller is used, one could only adjust the > > binary blob, when new memory (faster, slower, from other > > manufacturer) is used in the product. > > > > - There would be no need to add such code to the board file. > > yeah, ddr is not the only thing that comes in this bucket, PMIC data > as well can be also made in similar way. I mean all the board related > information can be moved out. I think that the EMIF controller configuration is a bit special. As you pointed out - for the whole AM57xx family one EMIF controller type is used. > But then the binary size will still > remain the same. The goal here would be to not make the binary smaller, but reducing the maintanence effort. Example use case - company X has a product. They are using single u-boot (with SPL and dts). The only thing, which they need to change is the data needed for setting up proper memory configuration (DDR2/DDR3, speed - 1500, 1333, ECC enabled/disabled, module size, etc). This all is done in EMIF. With separate EMIF blob configuration they don't n
Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size
Hi, On Mon, 18 Dec 2017 10:17:03 +0100 Marek Vasut wrote: > On 12/18/2017 10:02 AM, linux-kernel-...@beckhoff.com wrote: > > From: Patrick Bruenn > > > > Static variables are not available during board_init_f(). > > They are, since the board runs from RAM at that point already. > That's not the point. Zero-initialized variables (static or not) are located in the .bss section, which is overlayed by the .rel.dyn section. Thus writing to such a variable before relocation will trash the relocation data. Lothar Waßmann ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] doc: Document for generic firmware loader
On Isn, 2017-12-18 at 10:28 +0100, Lukasz Majewski wrote: > Hi Tien, > > > > > From: Tien Fong Chee > > > > This is initial draft document about generic firmware loader. > > The intention of this patch is open for discussion, and final > > version > > will be included together with next version release of generic > > firmware loader patchset. Current V3 generic firmware loader > > patchset > > can be reviewed from > > https://www.mail-archive.com/u-boot@lists.denx.de/msg272028.html > > > > Signed-off-by: Tien Fong Chee > > --- > >  doc/README.firmware_loader |   77 > > 1 files changed, 77 > > insertions(+), 0 deletions(-) create mode 100644 > > doc/README.firmware_loader > > > > diff --git a/doc/README.firmware_loader > > b/doc/README.firmware_loader > > new file mode 100644 > > index 000..d250723 > > --- /dev/null > > +++ b/doc/README.firmware_loader > > @@ -0,0 +1,77 @@ > > +/* > > + * Copyright (C) 2017 Intel Corporation > > + * > > + * SPDX-License-Identifier:GPL-2.0 > > + */ > > + > > +Introduction > > + > > +This is firmware loader for U-Boot framework, which has very close > > to some Linux +Firmware API. For the details of Linux Firmware API, > > you can refer to > > +https://01.org/linuxgraphics/gfx-docs/drm/driver-api/firmware/inde > > x.html. > > + +Firmware loader can be used to load whatever(firmware, image, > > and > > binary) from +the flash in file system format into target location >   ^^ I suppose that you mean - load binary image >   from file system put on flash? > Yes, you are right. > > > > such as memory, then +consumer driver such as FPGA driver can > > program > > FPGA image from the target +location into FPGA. > > + > > +Firmware Loader API core features > > +- > > +=> Firmware storage device partition search  > > +   > > +   => Default storage device partition search set for mmc, > > usb and sata > > + as shown in below: > > + static struct device_location default_locations[] = { > > + { > > + .name = "mmc", > > + .devpart = "0:1", > > + }, > > + { > > + .name = "usb", > > + .devpart = "0:1", > > + }, > > + { > > + .name = "sata", > > + .devpart = "0:1", > > + }, > > + }; > > + > > + However, the default storage device .devpart value can be > > overwritten > > + with value which is defined in the environment variable > > "FW_DEV_PART". > > + For example: env_set("FW_DEV_PART", "0:2"); >   ^^ - u-boot normally uses lower >   case for env variable naming. > okay, i will switch to lower case. > > > > + > > +Firmware Loader API > > +--- > > +=> int request_firmware_into_buf(struct firmware **firmware_p,  > > +   const char *name, > > +   struct device_location *location, > > +   void *buf, size_t size, u32 offset) > > +   -- > > +   => Load firmware into a previously allocated buffer > > + > > + Parameters: > > + struct firmware **firmware_p > > + pointer to firmware image > > + > > + const char *name > > + name of firmware file > > + > > + struct device_location *location > > + an array of supported firmware location > > + > > + void *buf > > + address of buffer to load firmware into > > + > > + size_t size > > + size of buffer > > + > > + u32 offset > > + offset of a file for start reading into buffer > > + > > + return: size of total read > > +    -ve when error > > + > > + Description: > > + The firmware is loaded directly into the buffer pointed to > > by buf and > > + the @firmware_p data member is pointed at buf. > > + > > > Best regards, > > Lukasz Majewski > > -- > > DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 1/2] drivers/reset: support rockchip reset drivers
From: Elaine Zhang Create driver to support all Rockchip SoCs soft reset. Example of usage: i2c driver: ret = reset_get_by_name(dev, "i2c", &reset_ctl); if (ret) { error("reset_get_by_name() failed: %d\n", ret); } reset_assert(&reset_ctl); udelay(50); reset_deassert(&reset_ctl); i2c dts node: resets = <&cru SRST_P_I2C1>, <&cru SRST_I2C1>; reset-names = "p_i2c", "i2c"; Signed-off-by: Elaine Zhang Signed-off-by: Kever Yang --- Changes in v5: - make rockchip reset driver depends on ARCH_ROCKCHIP Changes in v4: None Changes in v3: None Changes in v2: - fix Kconfig more than 80 length - use MACRO for reset bits in one reg - use rkclr/set_reg for reg access - add rockchip_reset_bind() - use dev_read_addr_size() instead of fdtdec_ drivers/reset/Kconfig | 9 +++ drivers/reset/Makefile | 1 + drivers/reset/reset-rockchip.c | 133 + 3 files changed, 143 insertions(+) create mode 100644 drivers/reset/reset-rockchip.c diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index ce46e27..3964b9e 100644 --- a/drivers/reset/Kconfig +++ b/drivers/reset/Kconfig @@ -74,4 +74,13 @@ config AST2500_RESET resets that are supported by watchdog. The main limitation though is that some reset signals, like I2C or MISC reset multiple devices. +config RESET_ROCKCHIP + bool "Reset controller driver for Rockchip SoCs" + depends on DM_RESET && ARCH_ROCKCHIP && CLK + default y + help + Support for reset controller on rockchip SoC. The main limitation + though is that some reset signals, like I2C or MISC reset multiple + devices. + endmenu diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index 252cefe..7d7e080 100644 --- a/drivers/reset/Makefile +++ b/drivers/reset/Makefile @@ -12,3 +12,4 @@ obj-$(CONFIG_TEGRA186_RESET) += tegra186-reset.o obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o obj-$(CONFIG_AST2500_RESET) += ast2500-reset.o +obj-$(CONFIG_RESET_ROCKCHIP) += reset-rockchip.o diff --git a/drivers/reset/reset-rockchip.c b/drivers/reset/reset-rockchip.c new file mode 100644 index 000..01047a2 --- /dev/null +++ b/drivers/reset/reset-rockchip.c @@ -0,0 +1,133 @@ +/* + * (C) Copyright 2017 Rockchip Electronics Co., Ltd + * + * SPDX-License-Identifier: GPL-2.0 + */ + +#include +#include +#include +#include +#include +#include +/* + * Each reg has 16 bits reset signal for devices + * Note: Not including rk2818 and older SoCs + */ +#define ROCKCHIP_RESET_NUM_IN_REG 16 + +struct rockchip_reset_priv { + void __iomem *base; + /* Rockchip reset reg locate at cru controller */ + u32 reset_reg_offset; + /* Rockchip reset reg number */ + u32 reset_reg_num; +}; + +static int rockchip_reset_request(struct reset_ctl *reset_ctl) +{ + struct rockchip_reset_priv *priv = dev_get_priv(reset_ctl->dev); + + debug("%s(reset_ctl=%p) (dev=%p, id=%lu) (reg_num=%d)\n", __func__, + reset_ctl, reset_ctl->dev, reset_ctl->id, priv->reset_reg_num); + + if (reset_ctl->id / ROCKCHIP_RESET_NUM_IN_REG >= priv->reset_reg_num) + return -EINVAL; + + return 0; +} + +static int rockchip_reset_free(struct reset_ctl *reset_ctl) +{ + debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, reset_ctl, + reset_ctl->dev, reset_ctl->id); + + return 0; +} + +static int rockchip_reset_assert(struct reset_ctl *reset_ctl) +{ + struct rockchip_reset_priv *priv = dev_get_priv(reset_ctl->dev); + int bank = reset_ctl->id / ROCKCHIP_RESET_NUM_IN_REG; + int offset = reset_ctl->id % ROCKCHIP_RESET_NUM_IN_REG; + + debug("%s(reset_ctl=%p) (dev=%p, id=%lu) (reg_addr=%p)\n", __func__, + reset_ctl, reset_ctl->dev, reset_ctl->id, + priv->base + (bank * 4)); + + rk_setreg(priv->base + (bank * 4), BIT(offset)); + + return 0; +} + +static int rockchip_reset_deassert(struct reset_ctl *reset_ctl) +{ + struct rockchip_reset_priv *priv = dev_get_priv(reset_ctl->dev); + int bank = reset_ctl->id / ROCKCHIP_RESET_NUM_IN_REG; + int offset = reset_ctl->id % ROCKCHIP_RESET_NUM_IN_REG; + + debug("%s(reset_ctl=%p) (dev=%p, id=%lu) (reg_addr=%p)\n", __func__, + reset_ctl, reset_ctl->dev, reset_ctl->id, + priv->base + (bank * 4)); + + rk_clrreg(priv->base + (bank * 4), BIT(offset)); + + return 0; +} + +struct reset_ops rockchip_reset_ops = { + .request = rockchip_reset_request, + .free = rockchip_reset_free, + .rst_assert = rockchip_reset_assert, + .rst_deassert = rockchip_reset_deassert, +}; + +static int rockchip_reset_probe(struct udevice *dev) +{ + struct rockchip_reset_priv *priv = dev_get_priv(dev); + fdt_addr_t addr; + fdt_size_t size; + + addr = dev_read
[U-Boot] [PATCH v5 2/2] rockchip: clk: bind reset driver
From: Elaine Zhang Bind rockchip reset to clock-controller with rockchip_reset_bind(). Signed-off-by: Elaine Zhang Signed-off-by: Kever Yang --- Changes in v5: None Changes in v4: - fix compile error if CONFIG_RESET_ROCKCHIP not defined Changes in v3: - add missing offset for rk3399 pmuclk bind Changes in v2: - use rockchip_reset_bind() to bind reset driver. arch/arm/include/asm/arch-rockchip/clock.h | 10 ++ drivers/clk/rockchip/clk_rk3036.c | 7 +++ drivers/clk/rockchip/clk_rk3188.c | 7 +++ drivers/clk/rockchip/clk_rk322x.c | 7 +++ drivers/clk/rockchip/clk_rk3288.c | 7 +++ drivers/clk/rockchip/clk_rk3328.c | 7 +++ drivers/clk/rockchip/clk_rk3368.c | 7 +++ drivers/clk/rockchip/clk_rk3399.c | 21 + drivers/clk/rockchip/clk_rv1108.c | 7 +++ 9 files changed, 80 insertions(+) diff --git a/arch/arm/include/asm/arch-rockchip/clock.h b/arch/arm/include/asm/arch-rockchip/clock.h index 736b260..5264111 100644 --- a/arch/arm/include/asm/arch-rockchip/clock.h +++ b/arch/arm/include/asm/arch-rockchip/clock.h @@ -85,4 +85,14 @@ void rk3288_clk_configure_cpu(struct rk3288_cru *cru, struct rk3288_grf *grf); int rockchip_get_clk(struct udevice **devp); +/* + * rockchip_reset_bind() - Bind soft reset device as child of clock device + * + * @pdev: clock udevice + * @reg_offset: the first offset in cru for softreset registers + * @reg_number: the reg numbers of softreset registers + * @return 0 success, or error value + */ +int rockchip_reset_bind(struct udevice *pdev, u32 reg_offset, u32 reg_number); + #endif diff --git a/drivers/clk/rockchip/clk_rk3036.c b/drivers/clk/rockchip/clk_rk3036.c index 280ebb9..510a00a 100644 --- a/drivers/clk/rockchip/clk_rk3036.c +++ b/drivers/clk/rockchip/clk_rk3036.c @@ -347,6 +347,13 @@ static int rk3036_clk_bind(struct udevice *dev) sys_child->priv = priv; } +#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP) + ret = offsetof(struct rk3036_cru, cru_softrst_con[0]); + ret = rockchip_reset_bind(dev, ret, 9); + if (ret) + debug("Warning: software reset driver bind faile\n"); +#endif + return 0; } diff --git a/drivers/clk/rockchip/clk_rk3188.c b/drivers/clk/rockchip/clk_rk3188.c index fca6899..6451c95 100644 --- a/drivers/clk/rockchip/clk_rk3188.c +++ b/drivers/clk/rockchip/clk_rk3188.c @@ -590,6 +590,13 @@ static int rk3188_clk_bind(struct udevice *dev) sys_child->priv = priv; } +#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP) + ret = offsetof(struct rk3188_cru, cru_softrst_con[0]); + ret = rockchip_reset_bind(dev, ret, 9); + if (ret) + debug("Warning: software reset driver bind faile\n"); +#endif + return 0; } diff --git a/drivers/clk/rockchip/clk_rk322x.c b/drivers/clk/rockchip/clk_rk322x.c index ff52b55..c8a2413 100644 --- a/drivers/clk/rockchip/clk_rk322x.c +++ b/drivers/clk/rockchip/clk_rk322x.c @@ -402,6 +402,13 @@ static int rk322x_clk_bind(struct udevice *dev) sys_child->priv = priv; } +#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP) + ret = offsetof(struct rk322x_cru, cru_softrst_con[0]); + ret = rockchip_reset_bind(dev, ret, 9); + if (ret) + debug("Warning: software reset driver bind faile\n"); +#endif + return 0; } diff --git a/drivers/clk/rockchip/clk_rk3288.c b/drivers/clk/rockchip/clk_rk3288.c index ac53239..b64c107 100644 --- a/drivers/clk/rockchip/clk_rk3288.c +++ b/drivers/clk/rockchip/clk_rk3288.c @@ -876,6 +876,13 @@ static int rk3288_clk_bind(struct udevice *dev) sys_child->priv = priv; } +#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP) + ret = offsetof(struct rk3288_cru, cru_softrst_con[0]); + ret = rockchip_reset_bind(dev, ret, 12); + if (ret) + debug("Warning: software reset driver bind faile\n"); +#endif + return 0; } diff --git a/drivers/clk/rockchip/clk_rk3328.c b/drivers/clk/rockchip/clk_rk3328.c index 4d522a7..fa0c777 100644 --- a/drivers/clk/rockchip/clk_rk3328.c +++ b/drivers/clk/rockchip/clk_rk3328.c @@ -614,6 +614,13 @@ static int rk3328_clk_bind(struct udevice *dev) sys_child->priv = priv; } +#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP) + ret = offsetof(struct rk3328_cru, softrst_con[0]); + ret = rockchip_reset_bind(dev, ret, 12); + if (ret) + debug("Warning: software reset driver bind faile\n"); +#endif + return ret; } diff --git a/drivers/clk/rockchip/clk_rk3368.c b/drivers/clk/rockchip/clk_rk3368.c index bfeef39..a831991 100644 --- a/drivers/clk/rockchip/clk_rk3368.c +++ b/drivers/clk/rockchip/clk_rk3368.c @@ -543,6 +543,13 @@ static int rk3368_clk_bind(struct udevice *dev) sys_child->priv = priv; } +#if CONFIG_IS_ENABLED(CONFIG_RESET_ROCKCHIP)
Re: [U-Boot] [PATCH v4 1/2] drivers/reset: support rockchip reset drivers
Philipp, On 12/19/2017 05:29 PM, Dr. Philipp Tomsich wrote: Kever, while this version has finally fixed the build errors for the rockchip-targets, it still causes major build failures for other target families: see https://travis-ci.org/ptomsich/u-boot-rockchip/builds/318128281 The new driver still appears to be built for the failing boards. I will make it depends on ARCH_ROCKCHIP. Thanks, - Kever Regards, Philipp. On 18 Dec 2017, at 09:49, Kever Yang wrote: From: Elaine Zhang Create driver to support all Rockchip SoCs soft reset. Example of usage: i2c driver: ret = reset_get_by_name(dev, "i2c", &reset_ctl); if (ret) { error("reset_get_by_name() failed: %d\n", ret); } reset_assert(&reset_ctl); udelay(50); reset_deassert(&reset_ctl); i2c dts node: resets = <&cru SRST_P_I2C1>, <&cru SRST_I2C1>; reset-names = "p_i2c", "i2c"; Signed-off-by: Elaine Zhang Signed-off-by: Kever Yang --- Changes in v4: None Changes in v3: None Changes in v2: - fix Kconfig more than 80 length - use MACRO for reset bits in one reg - use rkclr/set_reg for reg access - add rockchip_reset_bind() - use dev_read_addr_size() instead of fdtdec_ drivers/reset/Kconfig | 9 +++ drivers/reset/Makefile | 1 + drivers/reset/reset-rockchip.c | 133 + 3 files changed, 143 insertions(+) create mode 100644 drivers/reset/reset-rockchip.c diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index ce46e27..97a78d7 100644 --- a/drivers/reset/Kconfig +++ b/drivers/reset/Kconfig @@ -74,4 +74,13 @@ config AST2500_RESET resets that are supported by watchdog. The main limitation though is that some reset signals, like I2C or MISC reset multiple devices. +config RESET_ROCKCHIP + bool "Reset controller driver for Rockchip SoCs" + depends on DM_RESET && CLK + default y + help + Support for reset controller on rockchip SoC. The main limitation + though is that some reset signals, like I2C or MISC reset multiple + devices. + endmenu diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index 252cefe..7d7e080 100644 --- a/drivers/reset/Makefile +++ b/drivers/reset/Makefile @@ -12,3 +12,4 @@ obj-$(CONFIG_TEGRA186_RESET) += tegra186-reset.o obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o obj-$(CONFIG_AST2500_RESET) += ast2500-reset.o +obj-$(CONFIG_RESET_ROCKCHIP) += reset-rockchip.o diff --git a/drivers/reset/reset-rockchip.c b/drivers/reset/reset-rockchip.c new file mode 100644 index 000..01047a2 --- /dev/null +++ b/drivers/reset/reset-rockchip.c @@ -0,0 +1,133 @@ +/* + * (C) Copyright 2017 Rockchip Electronics Co., Ltd + * + * SPDX-License-Identifier: GPL-2.0 + */ + +#include +#include +#include +#include +#include +#include +/* + * Each reg has 16 bits reset signal for devices + * Note: Not including rk2818 and older SoCs + */ +#define ROCKCHIP_RESET_NUM_IN_REG 16 + +struct rockchip_reset_priv { + void __iomem *base; + /* Rockchip reset reg locate at cru controller */ + u32 reset_reg_offset; + /* Rockchip reset reg number */ + u32 reset_reg_num; +}; + +static int rockchip_reset_request(struct reset_ctl *reset_ctl) +{ + struct rockchip_reset_priv *priv = dev_get_priv(reset_ctl->dev); + + debug("%s(reset_ctl=%p) (dev=%p, id=%lu) (reg_num=%d)\n", __func__, + reset_ctl, reset_ctl->dev, reset_ctl->id, priv->reset_reg_num); + + if (reset_ctl->id / ROCKCHIP_RESET_NUM_IN_REG >= priv->reset_reg_num) + return -EINVAL; + + return 0; +} + +static int rockchip_reset_free(struct reset_ctl *reset_ctl) +{ + debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, reset_ctl, + reset_ctl->dev, reset_ctl->id); + + return 0; +} + +static int rockchip_reset_assert(struct reset_ctl *reset_ctl) +{ + struct rockchip_reset_priv *priv = dev_get_priv(reset_ctl->dev); + int bank = reset_ctl->id / ROCKCHIP_RESET_NUM_IN_REG; + int offset = reset_ctl->id % ROCKCHIP_RESET_NUM_IN_REG; + + debug("%s(reset_ctl=%p) (dev=%p, id=%lu) (reg_addr=%p)\n", __func__, + reset_ctl, reset_ctl->dev, reset_ctl->id, + priv->base + (bank * 4)); + + rk_setreg(priv->base + (bank * 4), BIT(offset)); + + return 0; +} + +static int rockchip_reset_deassert(struct reset_ctl *reset_ctl) +{ + struct rockchip_reset_priv *priv = dev_get_priv(reset_ctl->dev); + int bank = reset_ctl->id / ROCKCHIP_RESET_NUM_IN_REG; + int offset = reset_ctl->id % ROCKCHIP_RESET_NUM_IN_REG; + + debug("%s(reset_ctl=%p) (dev=%p, id=%lu) (reg_addr=%p)\n", __func__, + reset_ctl, reset_ctl->dev, reset_ctl->id, + priv->base + (bank * 4)); + + rk_clrreg(priv->base + (bank * 4), BIT(offset)); + + return 0; +} + +struct reset_ops rockchi
Re: [U-Boot] [PATCH v4 2/2] common: Generic firmware loader for file system
On Isn, 2017-12-18 at 08:39 +0100, Lothar Waßmann wrote: > Hi, > > On Mon, 18 Dec 2017 13:10:56 +0800 tien.fong.c...@intel.com wrote: > > > > From: Tien Fong Chee > > > > This is file system generic loader which can be used to load > > the file image from the storage into target such as memory. > > The consumer driver would then use this loader to program whatever, > > ie. the FPGA device. > > > > Signed-off-by: Tien Fong Chee > > --- > >  common/Makefile|   1 + > >  common/fs_loader.c | 311 > > + > >  doc/README.firmware_loader |  77 +++ > >  include/fs_loader.h|  28 > >  4 files changed, 417 insertions(+) > >  create mode 100644 common/fs_loader.c > >  create mode 100644 doc/README.firmware_loader > >  create mode 100644 include/fs_loader.h > > > [...] > > > > diff --git a/common/fs_loader.c b/common/fs_loader.c > > new file mode 100644 > > index 000..81cf5d6 > > --- /dev/null > > +++ b/common/fs_loader.c > [...] > > > > +/* > > + * Prepare firmware struct; > > + * return -ve if fail. > > + */ > > +static int _request_firmware_prepare(struct firmware **firmware_p, > > +  const char *name, void *dbuf, > > +  size_t size, u32 offset) > > +{ > > + struct firmware *firmware = NULL; > > + struct firmware_priv *fw_priv = NULL; > > + > > + *firmware_p = NULL; > > + > > + if (!name || name[0] == '\0') > > + return -EINVAL; > > + > > + *firmware_p = firmware = calloc(1, sizeof(*firmware)); > > + > > + if (!firmware) { > > + printf("%s: calloc(struct firmware) failed\n", > > __func__); > > + return -ENOMEM; > > + } > > + > > + fw_priv = calloc(1, sizeof(*fw_priv)); > > + > > + if (!fw_priv) { > > + printf("%s: calloc(struct fw_priv) failed\n", > > __func__); > > + return -ENOMEM; > What about freeing 'firmware' and NULLing *firmware_p here? There is no "freeing" support in U-Boot. I can assign NULL to *firmware_p. > Or better, do the assignment of *firmware_p at the end. Are you means switch the location between *firmware_p and fw_priv in calloc? > > > > > + } > > + > > + fw_priv->name = name; > > + fw_priv->offset = offset; > > + firmware->data = dbuf; > > + firmware->size = size; > > + firmware->priv = fw_priv; > > + > > + return 0; > > +} > > + > > +/* > > + * fw_get_filesystem_firmware - load firmware into an allocated > > buffer > > + * @location: An array of supported firmware location > > + * @firmware_p: pointer to firmware image > > + * > > + * @return: size of total read > > + * -ve when error > > + */ > > +static int fw_get_filesystem_firmware(struct device_location > > *location, > > +   struct firmware *firmware_p) > > +{ > > + struct firmware_priv *fw_priv = NULL; > > + loff_t actread; > > + char *dev_part; > > + int ret; > > + > > + dev_part = env_get("FW_DEV_PART"); > > + if (dev_part) > > + set_storage_devpart(location->name, dev_part); > > + > > + ret = init_storage_device(location); > > + if (ret) > > + goto out; > > + > > + select_fs_dev(location); > > + if (ret) > > + goto out; > > + > > + fw_priv = (struct firmware_priv *)firmware_p->priv; > > + > useless type cast. > I assume you are saying autocast, right? Let me check is there any warning from compiler after removing the cast. > > > > + ret = fs_read(fw_priv->name, (ulong)firmware_p->data, > > fw_priv->offset, > > +  firmware_p->size, &actread); > > + > > + if (ret || (actread != firmware_p->size)) { > > + printf("Error: %d Failed to read %s from flash > > %lld != %d.\n", > > +   ret, fw_priv->name, actread, firmware_p- > > >size); > > + return -EPERM; > Quoting myself from an earlier mail > (20171212091442.2f682...@karo-electronics.de): > > > > That's definitely not the right return code in this situation. > > If 'ret' is != 0 you should return 'ret', otherwise EIO is more > > appropriate here. > Sorry for mising out this part. I would change that. > > Lothar Waßmann ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] usb: ehci: fsl: Fix some compile warnings.
On 12/19/2017 08:33 AM, Ran Wang wrote: Commit message explaining what "some" means is missing. > Signed-off-by: Ran Wang > --- > drivers/usb/host/ehci-fsl.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c > index 62c431b..17d1fae 100644 > --- a/drivers/usb/host/ehci-fsl.c > +++ b/drivers/usb/host/ehci-fsl.c > @@ -106,14 +106,14 @@ static int ehci_fsl_probe(struct udevice *dev) > ehci = (struct usb_ehci *)priv->hcd_base; > hccr = (struct ehci_hccr *)(&ehci->caplength); > hcor = (struct ehci_hcor *) > - ((u32)hccr + HC_LENGTH(ehci_readl(&hccr->cr_capbase))); > + ((void *)hccr + HC_LENGTH(ehci_readl(&hccr->cr_capbase))); > > if (ehci_fsl_init(priv, ehci, hccr, hcor) < 0) > return -ENXIO; > > - debug("ehci-fsl: init hccr %x and hcor %x hc_length %d\n", > - (u32)hccr, (u32)hcor, > - (u32)HC_LENGTH(ehci_readl(&hccr->cr_capbase))); > + debug("ehci-fsl: init hccr %p and hcor %p hc_length %d\n", > + (void *)hccr, (void *)hcor, > + HC_LENGTH(ehci_readl(&hccr->cr_capbase))); > > return ehci_register(dev, hccr, hcor, &fsl_ehci_ops, 0, USB_INIT_HOST); > } > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] common: Generic firmware loader for file system
On 12/19/2017 11:31 AM, Chee, Tien Fong wrote: > On Isn, 2017-12-18 at 08:39 +0100, Lothar Waßmann wrote: >> Hi, >> >> On Mon, 18 Dec 2017 13:10:56 +0800 tien.fong.c...@intel.com wrote: >>> >>> From: Tien Fong Chee >>> >>> This is file system generic loader which can be used to load >>> the file image from the storage into target such as memory. >>> The consumer driver would then use this loader to program whatever, >>> ie. the FPGA device. >>> >>> Signed-off-by: Tien Fong Chee >>> --- >>>  common/Makefile|   1 + >>>  common/fs_loader.c | 311 >>> + >>>  doc/README.firmware_loader |  77 +++ >>>  include/fs_loader.h|  28 >>>  4 files changed, 417 insertions(+) >>>  create mode 100644 common/fs_loader.c >>>  create mode 100644 doc/README.firmware_loader >>>  create mode 100644 include/fs_loader.h >>> >> [...] >>> >>> diff --git a/common/fs_loader.c b/common/fs_loader.c >>> new file mode 100644 >>> index 000..81cf5d6 >>> --- /dev/null >>> +++ b/common/fs_loader.c >> [...] >>> >>> +/* >>> + * Prepare firmware struct; >>> + * return -ve if fail. >>> + */ >>> +static int _request_firmware_prepare(struct firmware **firmware_p, >>> +  const char *name, void *dbuf, >>> +  size_t size, u32 offset) >>> +{ >>> + struct firmware *firmware = NULL; >>> + struct firmware_priv *fw_priv = NULL; >>> + >>> + *firmware_p = NULL; >>> + >>> + if (!name || name[0] == '\0') >>> + return -EINVAL; >>> + >>> + *firmware_p = firmware = calloc(1, sizeof(*firmware)); >>> + >>> + if (!firmware) { >>> + printf("%s: calloc(struct firmware) failed\n", >>> __func__); >>> + return -ENOMEM; >>> + } >>> + >>> + fw_priv = calloc(1, sizeof(*fw_priv)); >>> + >>> + if (!fw_priv) { >>> + printf("%s: calloc(struct fw_priv) failed\n", >>> __func__); >>> + return -ENOMEM; >> What about freeing 'firmware' and NULLing *firmware_p here? > There is no "freeing" support in U-Boot. I can assign NULL > to *firmware_p. Try git grep free maybe ? >> Or better, do the assignment of *firmware_p at the end. > Are you means switch the location between *firmware_p and fw_priv in > calloc? [... -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size
On 12/19/2017 05:28 AM, Patrick Brünn wrote: >> From: Marek Vasut [mailto:ma...@denx.de] >> Sent: Montag, 18. Dezember 2017 13:30 >> On 12/18/2017 01:16 PM, Patrick Brünn wrote: From: Marek Vasut [mailto:ma...@denx.de] Sent: Montag, 18. Dezember 2017 12:52 On 12/18/2017 12:40 PM, Patrick Brünn wrote: > [...] btw do you use SPL ? If not, you should ... >>> I will read more about SPL. Until now, I thought I will only benefit, >>> if my initial boot media is limited in size. As we boot from sdcard, >>> that wasn't a problem to store 360k u-boot. >> >> The other is that you can ie. skip the whole u-boot altogether and boot >> linux directly. >> > Okay, I will try that. >> I wonder if it would be better to keep the static variable and avoid >> calling the get_ram_size() twice, it can save some CPU cycles. Besides >> that, thanks for the explanation/discussion !1 >> > The pleasure was all mine. I will test SPL on my board and in case that's > working I think it still makes sense to move our common code into one file. > Is arch/arm/mach-imx/mx53_dram.c the best location for it? > At first I tried board/freescale/common/ but in that case I needed to use > ugly relative pathes in the Makefiles "../../" I think arch/arm/mach-imx/ is good , yes . We already have some imx6 ddr there too, maybe you can follow that scheme. > Regards, Patrick > > --- > Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans > Beckhoff > Registered office: Verl, Germany | Register court: Guetersloh HRA 7075 > > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size
On 12/19/2017 08:48 AM, Patrick Brünn wrote: >> From: Patrick Brünn >> Sent: Dienstag, 19. Dezember 2017 05:29 >>> From: Marek Vasut [mailto:ma...@denx.de] >>> Sent: Montag, 18. Dezember 2017 13:30 >>> On 12/18/2017 01:16 PM, Patrick Brünn wrote: > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Montag, 18. Dezember 2017 12:52 > On 12/18/2017 12:40 PM, Patrick Brünn wrote: >> [...] > btw do you use SPL ? If not, you should ... I will read more about SPL. Until now, I thought I will only benefit, if my initial boot media is limited in size. As we boot from sdcard, that wasn't a problem to store 360k u-boot. >>> >>> The other is that you can ie. skip the whole u-boot altogether and boot >>> linux directly. >>> >> Okay, I will try that. >>> I wonder if it would be better to keep the static variable and avoid >>> calling the get_ram_size() twice, it can save some CPU cycles. Besides >>> that, thanks for the explanation/discussion !1 >>> >> The pleasure was all mine. I will test SPL on my board and in case that's >> working I think it still makes sense to move our common code into one file. >> Is >> arch/arm/mach-imx/mx53_dram.c the best location for it? >> At first I tried board/freescale/common/ but in that case I needed to use >> ugly >> relative pathes in the Makefiles "../../" > I spend a few hours this morning to experiment with SPL. From what I saw it > would require some additional patches to enable SPL_MMC for imx53 and > a few more changes to our sdcard layout (FAT vs. EXT4). Seeing all these > additional #ifdefs to consider I just don't have a good feeling to port that > adhoc > for our board. > Directly booting Linux still sounds tempting, but for the moment I cannot > spend > more effort into SPL for mx53cx9020. I will put that on my todo list. But for > now > I would like to concentrate to get mainline boot on mx53cx9020, again. > > I would suggest: > 1. I keep m53evk.c untouched for now. > 2a. Either patch both mx53cx9020 and mx53loco to avoid static mx53_dram_size, >and have the shared code in arch/arm/mach-imx/mx53_dram.c > 2b. Or patch only board/beckhoff/mx53cx9020/mx53cx9020.c > > Fabio, what do you prefer? Just patch the m53evk , use the static variable and all should be good IMO. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] common: Generic firmware loader for file system
Hi, On Tue, 19 Dec 2017 10:31:13 + Chee, Tien Fong wrote: > On Isn, 2017-12-18 at 08:39 +0100, Lothar Waßmann wrote: > > Hi, > > > > On Mon, 18 Dec 2017 13:10:56 +0800 tien.fong.c...@intel.com wrote: > > > > > > From: Tien Fong Chee > > > > > > This is file system generic loader which can be used to load > > > the file image from the storage into target such as memory. > > > The consumer driver would then use this loader to program whatever, > > > ie. the FPGA device. > > > > > > Signed-off-by: Tien Fong Chee > > > --- > > >  common/Makefile|   1 + > > >  common/fs_loader.c | 311 > > > + > > >  doc/README.firmware_loader |  77 +++ > > >  include/fs_loader.h|  28 > > >  4 files changed, 417 insertions(+) > > >  create mode 100644 common/fs_loader.c > > >  create mode 100644 doc/README.firmware_loader > > >  create mode 100644 include/fs_loader.h > > > > > [...] > > > > > > diff --git a/common/fs_loader.c b/common/fs_loader.c > > > new file mode 100644 > > > index 000..81cf5d6 > > > --- /dev/null > > > +++ b/common/fs_loader.c > > [...] > > > > > > +/* > > > + * Prepare firmware struct; > > > + * return -ve if fail. > > > + */ > > > +static int _request_firmware_prepare(struct firmware **firmware_p, > > > +  const char *name, void *dbuf, > > > +  size_t size, u32 offset) > > > +{ > > > + struct firmware *firmware = NULL; > > > + struct firmware_priv *fw_priv = NULL; > > > + > > > + *firmware_p = NULL; > > > + > > > + if (!name || name[0] == '\0') > > > + return -EINVAL; > > > + > > > + *firmware_p = firmware = calloc(1, sizeof(*firmware)); > > > + > > > + if (!firmware) { > > > + printf("%s: calloc(struct firmware) failed\n", > > > __func__); > > > + return -ENOMEM; > > > + } > > > + > > > + fw_priv = calloc(1, sizeof(*fw_priv)); > > > + > > > + if (!fw_priv) { > > > + printf("%s: calloc(struct fw_priv) failed\n", > > > __func__); > > > + return -ENOMEM; > > What about freeing 'firmware' and NULLing *firmware_p here? > There is no "freeing" support in U-Boot. I can assign NULL > How do you come to that conclusion? > to *firmware_p. > > Or better, do the assignment of *firmware_p at the end. > Are you means switch the location between *firmware_p and fw_priv in > calloc? > No. I would assign *firmware_p only when everything else was OK, so that there won't be a valid pointer in *firmware_p when the struct firmware it is pointing to has not been set up completely. I would do like this: static int _request_firmware_prepare(struct firmware **firmware_p,  const char *name, void *dbuf,  size_t size, u32 offset) { struct firmware *firmware; struct firmware_priv *fw_priv; *firmware_p = NULL; if (!name || name[0] == '\0') return -EINVAL; firmware = calloc(1, sizeof(*firmware)); if (!firmware) { printf("%s: calloc(struct firmware) failed\n", __func__); return -ENOMEM; } fw_priv = calloc(1, sizeof(*fw_priv)); if (!fw_priv) { printf("%s: calloc(struct fw_priv) failed\n", __func__); free(firmware); return -ENOMEM; } fw_priv->name = name; fw_priv->offset = offset; firmware->data = dbuf; firmware->size = size; firmware->priv = fw_priv; *firmware_p = firmware; return 0; } so that *firmware_p is only assigned to when everything was OK. (Note, that there is no need to initialize firmware and fw_priv to NULL) > > > + * fw_get_filesystem_firmware - load firmware into an allocated > > > buffer > > > + * @location: An array of supported firmware location > > > + * @firmware_p: pointer to firmware image > > > + * > > > + * @return: size of total read > > > + * -ve when error > > > + */ > > > +static int fw_get_filesystem_firmware(struct device_location > > > *location, > > > +   struct firmware *firmware_p) > > > +{ > > > + struct firmware_priv *fw_priv = NULL; > > > + loff_t actread; > > > + char *dev_part; > > > + int ret; > > > + > > > + dev_part = env_get("FW_DEV_PART"); > > > + if (dev_part) > > > + set_storage_devpart(location->name, dev_part); > > > + > > > + ret = init_storage_device(location); > > > + if (ret) > > > + goto out; > > > + > > > + select_fs_dev(location); > > > + if (ret) > > > + goto out; > > > + > > > + fw_priv = (struct firmware_priv *)firmware_p->priv; > > > + > > useless type cast. > > > I assume you are saying autocast, right? Let me check is there any > warning from compiler after removing the cast. > In C void pointers can be assigned to any type pointers without need for a cast. Lothar Waßmann _
Re: [U-Boot] [PATCH] sunxi: Add support for Libre Computer Board ALL-H3-CC H3 ver.
On Fri, Dec 8, 2017 at 8:31 AM, Jagan Teki wrote: > On Fri, Dec 8, 2017 at 7:59 AM, Chen-Yu Tsai wrote: >> On Fri, Dec 8, 2017 at 1:01 AM, Jagan Teki wrote: >>> On Thu, Dec 7, 2017 at 6:30 PM, Chen-Yu Tsai wrote: The Libre Computer Board ALL-H3-CC from Libre Technology is a Raspberry Pi B+ form factor single board computer based on the Allwinner H3 SoC. The board has 1GB DDR3 SDRAM, provided by 4 2Gb chips. The mounting holes and connectors are in the exact same position as on the Raspberry Pi B+. Raspberry Pi B+ like peripherals supported on this board include: - Power input through micro-USB connector (without USB OTG) - Native 100 Mbps ethernet using the internal PHY, as opposed to USB-based on the RPi - 4x USB 2.0 host ports, directly connected to the SoC, as opposed to being connected through a USB 2.0 hub on the RPi - TV and audio output on a 3.5mm TRRS jack - HDMI output - Micro-SD card slot - Standard RPi B+ GPIO header, with the standard peripherals routed to the same pins. * 5V, 3.3V power, and ground * I2C0 on the H3 is routed to I2C1 pins on the RPi header * I2C1 on the H3 is routed to I2C0 pins on the RPi header * UART1 on the H3 is routed to UART0 pins on the RPi header * SPI0 on the H3 is routed to SPI0 pins on the RPi header, with GPIO pin PA17 replacing the missing Chip Select 1 * I2S1 on the H3 is routed to PCM pins on the RPi header - Additional peripherals from the H3 are available on different pins. These include I2S0, JTAG, PWM1, SPDIF, SPI1, and UART3 In addition, there are a number of new features: - Console UART header - Consumer IR receiver - Camera interface (not compatible with RPi) - Onboard microphone - eMMC expansion module port - Heatsink mounting holes This patch adds defconfig and dts files for this board. The dts file is the same as the one submitted for inclusion in Linux, with some minor revisions to match the dtsi file and old EMAC bindings in U-boot. Since the OTG controller is wired to a USB host port, and the H3 has proper USB hosts to handle host mode, the MUSB driver is not enabled. Signed-off-by: Chen-Yu Tsai --- arch/arm/dts/Makefile | 1 + arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts | 180 ++ board/sunxi/MAINTAINERS | 5 + configs/libretech_all_h3_cc_h3_defconfig | 19 +++ 4 files changed, 205 insertions(+) create mode 100644 arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts create mode 100644 configs/libretech_all_h3_cc_h3_defconfig diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index f54adb21847a..0aba72d3a72f 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -320,6 +320,7 @@ dtb-$(CONFIG_MACH_SUN8I_A83T) += \ dtb-$(CONFIG_MACH_SUN8I_H3) += \ sun8i-h2-plus-orangepi-zero.dtb \ sun8i-h3-bananapi-m2-plus.dtb \ + sun8i-h3-libretech-all-h3-cc.dtb \ sun8i-h3-orangepi-2.dtb \ sun8i-h3-orangepi-lite.dtb \ sun8i-h3-orangepi-one.dtb \ diff --git a/arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts b/arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts new file mode 100644 index ..97b993f636f9 --- /dev/null +++ b/arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts @@ -0,0 +1,180 @@ +/* + * Copyright (C) 2017 Chen-Yu Tsai + * + * SPDX-License-Identifier: (GPL-2.0+ OR MIT) + */ >>> >>> Why can't we use Linux license? since we always sync dts files from Linux. >> >> This IS the same license we use for dts files in the Linux kernel. >> We want all projects to be able to use them. It wouldn't make sense >> to have BSD licensed projects to include GPL-only files, now would >> it? > > Reviewed-by: Jagan Teki Applied to u-boot-sunxi/next ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: imply CONFIG_OF_LIBFDT_OVERLAY
On Wed, Dec 13, 2017 at 2:16 PM, Andre Heider wrote: > fdt overlay support is useful for all sunxi boards, enable per default > and remove it from sunxi defconfigs. > > Signed-off-by: Andre Heider > --- > > Hi, > > there're way too many sunxi boards so I'm not 100% sure this is the best > approach... > > Are there boards where enabling this is definitely not desired? > > Thanks, > Andre > > arch/arm/Kconfig | 1 + > configs/CHIP_defconfig | 1 - > configs/CHIP_pro_defconfig | 1 - > 3 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 73909952d0..25847b3aa1 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -715,6 +715,7 @@ config ARCH_SUNXI > select USE_TINY_PRINTF > imply CMD_GPT > imply FAT_WRITE > + imply OF_LIBFDT_OVERLAY It's increasing u-boot.itb size to 512KB (which is 508K earlier) and in either case the size moves on env side where env start 0x88000 (504KB) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-sunxi/master
Hi Tom, Please pull this PR. thanks! Jagan. The following changes since commit b6251db8c3f0de605b4cd6f15a00fc7dd19cda63: Kconfig: Introduce USE_BOOTCOMMAND and migrate BOOTCOMMAND (2017-11-17 16:37:26 -0500) are available in the git repository at: git://git.denx.de/u-boot-sunxi.git master for you to fetch changes up to 23cd00ab2d8c39eaa15257efcba441939ea66fa8: arm64: dts: sun50i: h5: Order nodes in alphabetic for orangepi-prime (2017-12-19 16:26:21 +0530) Antony Antony (2): arm64: sun50i-h5.dtsi : update to kernel 4.14 sun50i: h5: Add NanoPi Neo Plus2 DT initial support Chen-Yu Tsai (1): sunxi: Fix UART console index for A33-OLinuXino Icenowy Zheng (2): video: sunxi: de2: add support for LCD SimpleFB sunxi: set the default CPUx frequency of H5 to 816MHz Jagan Teki (3): sunxi: arm64: Increase CONFIG_SYS_BOOTM_LEN to 32MB configs: sunxi: Drop FASTBOOT_FLASH arm64: dts: sun50i: h5: Order nodes in alphabetic for orangepi-prime Maxime Ripard (5): part: efi: Add a Kconfig option for the number of partition entries part: efi: Add default number of partition entries for sunxi sunxi: Add default partition scheme fastboot: Enable flashing by default on sunxi sunxi: Add the TBS A711 tablet Stefan Mavrodiev (1): sunxi: Fix A20-OLinuXino-MICRO LAN8710 support Vasily Khoruzhick (1): sunxi: video: HDMI: split VSYNC and HSYNC polarity settings arch/arm/dts/Makefile | 4 +- arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts| 106 + arch/arm/dts/sun50i-h5-orangepi-prime.dts | 16 ++-- arch/arm/dts/sun50i-h5.dtsi| 32 arch/arm/dts/sun8i-a83t-tbs-a711.dts | 76 ++ arch/arm/mach-sunxi/Kconfig| 2 +- board/sunxi/MAINTAINERS| 5 ++ board/sunxi/gmac.c | 4 + cmd/fastboot/Kconfig | 1 + configs/A13-OLinuXino_defconfig| 1 - configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 - configs/A20-OLinuXino-Lime2_defconfig | 1 - configs/A20-OLinuXino_MICRO-eMMC_defconfig | 1 + configs/A20-OLinuXino_MICRO_defconfig | 1 + configs/A33-OLinuXino_defconfig| 1 + configs/CHIP_defconfig | 1 - configs/CHIP_pro_defconfig | 1 - configs/Cubietruck_defconfig | 1 - configs/Nintendo_NES_Classic_Edition_defconfig | 1 - configs/Sinlinx_SinA33_defconfig | 1 - configs/nanopi_neo_plus2_defconfig | 18 + configs/parrot_r16_defconfig | 1 - configs/tbs_a711_defconfig | 23 ++ disk/Kconfig | 14 drivers/net/Kconfig| 8 ++ drivers/video/sunxi/sunxi_de2.c| 11 ++- drivers/video/sunxi/sunxi_dw_hdmi.c| 14 ++-- include/configs/sunxi-common.h | 18 + include/part_efi.h | 2 +- 29 files changed, 336 insertions(+), 30 deletions(-) create mode 100644 arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts create mode 100644 arch/arm/dts/sun8i-a83t-tbs-a711.dts create mode 100644 configs/nanopi_neo_plus2_defconfig create mode 100644 configs/tbs_a711_defconfig ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd/spi: fix block count for is25lq040b
On Fri, Dec 15, 2017 at 1:21 PM, Sean Nyekjaer wrote: > This spi-nor is 4Mbit/512KB > > Fixes: b4fbcbc5a5 ("mtd/spi: add support for is25lq040b") > Signed-off-by: Sean Nyekjaer > --- Applied to u-boot-spi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size
>From: Patrick Brünn >Sent: Dienstag, 19. Dezember 2017 05:29 >>From: Marek Vasut [mailto:ma...@denx.de] >>Sent: Montag, 18. Dezember 2017 13:30 >>On 12/18/2017 01:16 PM, Patrick Brünn wrote: From: Marek Vasut [mailto:ma...@denx.de] Sent: Montag, 18. Dezember 2017 12:52 On 12/18/2017 12:40 PM, Patrick Brünn wrote: >[...] btw do you use SPL ? If not, you should ... >>> I will read more about SPL. Until now, I thought I will only benefit, >>> if my initial boot media is limited in size. As we boot from sdcard, >>> that wasn't a problem to store 360k u-boot. >> >>The other is that you can ie. skip the whole u-boot altogether and boot >>linux directly. >> >Okay, I will try that. >>I wonder if it would be better to keep the static variable and avoid >>calling the get_ram_size() twice, it can save some CPU cycles. Besides >>that, thanks for the explanation/discussion !1 >> >The pleasure was all mine. I will test SPL on my board and in case that's >working I think it still makes sense to move our common code into one file. Is >arch/arm/mach-imx/mx53_dram.c the best location for it? >At first I tried board/freescale/common/ but in that case I needed to use ugly >relative pathes in the Makefiles "../../" I spend a few hours this morning to experiment with SPL. From what I saw it would require some additional patches to enable SPL_MMC for imx53 and a few more changes to our sdcard layout (FAT vs. EXT4). Seeing all these additional #ifdefs to consider I just don't have a good feeling to port that adhoc for our board. Directly booting Linux still sounds tempting, but for the moment I cannot spend more effort into SPL for mx53cx9020. I will put that on my todo list. But for now I would like to concentrate to get mainline boot on mx53cx9020, again. I would suggest: 1. I keep m53evk.c untouched for now. 2a. Either patch both mx53cx9020 and mx53loco to avoid static mx53_dram_size, and have the shared code in arch/arm/mach-imx/mx53_dram.c 2b. Or patch only board/beckhoff/mx53cx9020/mx53cx9020.c Fabio, what do you prefer? Regards, Patrick --- Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] arm: imx: m53evk: remove usage of mx53_dram_size
>From: Marek Vasut [mailto:ma...@denx.de] >Sent: Montag, 18. Dezember 2017 13:30 >On 12/18/2017 01:16 PM, Patrick Brünn wrote: >>> From: Marek Vasut [mailto:ma...@denx.de] >>> Sent: Montag, 18. Dezember 2017 12:52 >>> On 12/18/2017 12:40 PM, Patrick Brünn wrote: [...] >>> btw do you use SPL ? If not, you should ... >> I will read more about SPL. Until now, I thought I will only benefit, >> if my initial boot media is limited in size. As we boot from sdcard, >> that wasn't a problem to store 360k u-boot. > >The other is that you can ie. skip the whole u-boot altogether and boot >linux directly. > Okay, I will try that. >I wonder if it would be better to keep the static variable and avoid >calling the get_ram_size() twice, it can save some CPU cycles. Besides >that, thanks for the explanation/discussion !1 > The pleasure was all mine. I will test SPL on my board and in case that's working I think it still makes sense to move our common code into one file. Is arch/arm/mach-imx/mx53_dram.c the best location for it? At first I tried board/freescale/common/ but in that case I needed to use ugly relative pathes in the Makefiles "../../" Regards, Patrick --- Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 00/11] rockchip: add tpl and OPTEE support for rk3229
Add some generic options for TPL support for arm 32bit, and then and TPL support for rk3229(cortex-A7), and then add OPTEE support in SPL. Tested on latest u-boot-rockchip master. Changes in v3: - do not init ddr region in spl Changes in v2: - update subject with ARCH_MEM info - Add new image type like ATF - Using new image type for op-tee - Make the its as common file used for all armv7 with op-tee - update defconfig option Kever Yang (11): lib: add TPL_OF_LIBFDT option for TPL arm: add option for TPL ARCH_MEM in arm 32bit arm: add a separate stack for TPL rockchip: rk322x: enable tpl support sysreset: enable driver support in SPL/TPL image: add os type for OP-TEE spl: add support to booting with OP-TEE rockchip: rk322x: dts: enable uart2 for SPL/TPL rockchip: add fit source file for pack itb with op-tee rockchip: evb-rk3229: add README file for OP-TEE support rockchip: evb-rk322x: update defconfig with tpl and optee support arch/arm/Kconfig | 29 + arch/arm/dts/rk3229-evb.dts | 1 + arch/arm/lib/crt0.S | 4 +- arch/arm/mach-rockchip/Kconfig | 9 +++ arch/arm/mach-rockchip/Makefile | 3 +- arch/arm/mach-rockchip/fit_spl_optee.its | 50 arch/arm/mach-rockchip/rk322x-board-spl.c| 63 +-- arch/arm/mach-rockchip/rk322x-board-tpl.c| 90 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds | 13 board/rockchip/evb_rk3229/README | 72 ++ common/image.c | 1 + common/spl/Kconfig | 7 +++ common/spl/Makefile | 1 + common/spl/spl.c | 8 +++ common/spl/spl_optee.S | 13 configs/evb-rk3229_defconfig | 26 +++- drivers/sysreset/Kconfig | 18 ++ drivers/sysreset/Makefile| 2 +- include/configs/rk322x_common.h | 9 ++- include/image.h | 1 + include/spl.h| 9 +++ lib/Kconfig | 10 22 files changed, 381 insertions(+), 58 deletions(-) create mode 100644 arch/arm/mach-rockchip/fit_spl_optee.its create mode 100644 arch/arm/mach-rockchip/rk322x-board-tpl.c create mode 100644 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds create mode 100644 board/rockchip/evb_rk3229/README create mode 100644 common/spl/spl_optee.S -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 00/11] rockchip: add tpl and OPTEE support for rk3229
Add some generic options for TPL support for arm 32bit, and then and TPL support for rk3229(cortex-A7), and then add OPTEE support in SPL. Tested on latest u-boot-rockchip master. Changes in v2: - update subject with ARCH_MEM info - Add new image type like ATF - Using new image type for op-tee - Make the its as common file used for all armv7 with op-tee - update defconfig option Kever Yang (11): lib: add TPL_OF_LIBFDT option for TPL arm: add option for TPL ARCH_MEM in arm 32bit arm: add a separate stack for TPL rockchip: rk322x: enable tpl support sysreset: enable driver support in SPL/TPL image: add os type for OP-TEE spl: add support to booting with OP-TEE rockchip: rk322x: dts: enable uart2 for SPL/TPL rockchip: add fit source file for pack itb with op-tee rockchip: evb-rk3229: add README file for OP-TEE support rockchip: evb-rk322x: update defconfig with tpl and optee support arch/arm/Kconfig | 29 + arch/arm/dts/rk3229-evb.dts | 1 + arch/arm/lib/crt0.S | 4 +- arch/arm/mach-rockchip/Kconfig | 9 +++ arch/arm/mach-rockchip/Makefile | 3 +- arch/arm/mach-rockchip/fit_spl_optee.its | 50 arch/arm/mach-rockchip/rk322x-board-spl.c| 61 +-- arch/arm/mach-rockchip/rk322x-board-tpl.c| 90 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds | 13 board/rockchip/evb_rk3229/README | 72 ++ common/image.c | 1 + common/spl/Kconfig | 7 +++ common/spl/Makefile | 1 + common/spl/spl.c | 8 +++ common/spl/spl_optee.S | 13 configs/evb-rk3229_defconfig | 26 +++- drivers/sysreset/Kconfig | 18 ++ drivers/sysreset/Makefile| 2 +- include/configs/rk322x_common.h | 9 ++- include/image.h | 1 + include/spl.h| 9 +++ lib/Kconfig | 10 22 files changed, 381 insertions(+), 56 deletions(-) create mode 100644 arch/arm/mach-rockchip/fit_spl_optee.its create mode 100644 arch/arm/mach-rockchip/rk322x-board-tpl.c create mode 100644 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds create mode 100644 board/rockchip/evb_rk3229/README create mode 100644 common/spl/spl_optee.S -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/11] rockchip: add tpl and OPTEE support for rk3229
Hi Philipp, This patch 4/11 is not correct, it can not pass the buildman, I will send a new version, pls ignore this version. Thanks, - Kever On 12/19/2017 04:18 PM, Kever Yang wrote: Add some generic options for TPL support for arm 32bit, and then and TPL support for rk3229(cortex-A7), and then add OPTEE support in SPL. Tested on latest u-boot-rockchip master. Changes in v2: - update subject with ARCH_MEM info - Add new image type like ATF - Using new image type for op-tee - Make the its as common file used for all armv7 with op-tee - update defconfig option Kever Yang (11): lib: add TPL_OF_LIBFDT option for TPL arm: add option for TPL ARCH_MEM in arm 32bit arm: add a separate stack for TPL rockchip: rk322x: enable tpl support sysreset: enable driver support in SPL/TPL image: add os type for OP-TEE spl: add support to booting with OP-TEE rockchip: rk322x: dts: enable uart2 for SPL/TPL rockchip: add fit source file for pack itb with op-tee rockchip: evb-rk3229: add README file for OP-TEE support rockchip: evb-rk322x: update defconfig with tpl and optee support arch/arm/Kconfig | 29 + arch/arm/dts/rk3229-evb.dts | 1 + arch/arm/lib/crt0.S | 4 +- arch/arm/mach-rockchip/Kconfig | 9 +++ arch/arm/mach-rockchip/Makefile | 3 +- arch/arm/mach-rockchip/fit_spl_optee.its | 50 arch/arm/mach-rockchip/rk322x-board-spl.c| 61 +-- arch/arm/mach-rockchip/rk322x-board-tpl.c| 90 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds | 13 board/rockchip/evb_rk3229/README | 72 ++ common/image.c | 1 + common/spl/Kconfig | 7 +++ common/spl/Makefile | 1 + common/spl/spl.c | 8 +++ common/spl/spl_optee.S | 13 configs/evb-rk3229_defconfig | 26 +++- drivers/sysreset/Kconfig | 18 ++ drivers/sysreset/Makefile| 2 +- include/configs/rk322x_common.h | 9 ++- include/image.h | 1 + include/spl.h| 9 +++ lib/Kconfig | 10 22 files changed, 381 insertions(+), 56 deletions(-) create mode 100644 arch/arm/mach-rockchip/fit_spl_optee.its create mode 100644 arch/arm/mach-rockchip/rk322x-board-tpl.c create mode 100644 arch/arm/mach-rockchip/rk322x/u-boot-tpl.lds create mode 100644 board/rockchip/evb_rk3229/README create mode 100644 common/spl/spl_optee.S ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-spi/master
Hi Tom, Please pull this PR. thanks! Jagan. The following changes since commit 16fa2eb95172e63820ee5f3d4052f3362a6de84e: ARM: dra7: Kconfig: Add thermal configs for dra7xx and am57xx (2017-11-21 08:03:39 -0500) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to 065592b40b41b11ee66d8ff71a55156bf1b35088: mtd/spi: fix block count for is25lq040b (2017-12-19 17:33:48 +0530) Jagan Teki (1): spi: Zap unneeded option Sean Nyekjaer (2): mtd/spi: add support for is25lq040b mtd/spi: fix block count for is25lq040b drivers/mtd/spi/spi_flash_ids.c | 1 + include/spi.h | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/13] arm: keystone: Move cmd_ddr3 to a common place
On Tue, Dec 19, 2017 at 10:31:19AM +0530, Lokesh Vutla wrote: > > > On Tuesday 19 December 2017 01:33 AM, Tom Rini wrote: > > On Mon, Dec 18, 2017 at 03:04:16PM +0530, Lokesh Vutla wrote: > > > >> Move cmd_ddr3 to board/ti/common/ in order to make > >> it build for non-keystone TI platforms. > >> > >> Signed-off-by: Lokesh Vutla > > [snip] > >> diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile > >> index 7170eac81e..66025040bc 100644 > >> --- a/board/ti/common/Makefile > >> +++ b/board/ti/common/Makefile > >> @@ -4,3 +4,6 @@ > >> # > >> > >> obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o > >> +ifndef CONFIG_SPL_BUILD > >> +obj-${CONFIG_CMD_DDR3} += cmd_ddr3.o > >> +endif > > > > We shouldn't need games like that now to have all strings be discarded, > > now that we're mandating gcc-6 or later. Thanks! > > whithout guarding with !SPL_BUILD, following build erroris seen if > SPL_ENV is not enabled: > > # > env/built-in.o:(.data.env_htab+0xc): undefined reference to > `env_flags_validate' > lib/built-in.o: In function `hsearch_r': > /home/lokesh/working/mainline/u-boot/lib/hashtable.c:380: undefined > reference to `env_callback_init' > /home/lokesh/working/mainline/u-boot/lib/hashtable.c:382: undefined > reference to `env_flags_init' > scripts/Makefile.spl:343: recipe for target 'spl/u-boot-spl' failed > make[1]: *** [spl/u-boot-spl] Error 1 > Makefile:1400: recipe for target 'spl/u-boot-spl' failed > make: *** [spl/u-boot-spl] Error 2 > > > gcc-6 is being used. Am I missing something? Hmmm, I would have expected it to be gc'd away. But I guess we're forcing commands to be linked in for some reason, I'll dig more just so I know again but disregard my comment about removing the guard, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/13] arm: keystone: Move cmd_ddr3 to a common place
On Tue, Dec 19, 2017 at 10:31:19AM +0530, Lokesh Vutla wrote: > > > On Tuesday 19 December 2017 01:33 AM, Tom Rini wrote: > > On Mon, Dec 18, 2017 at 03:04:16PM +0530, Lokesh Vutla wrote: > > > >> Move cmd_ddr3 to board/ti/common/ in order to make > >> it build for non-keystone TI platforms. > >> > >> Signed-off-by: Lokesh Vutla > > [snip] > >> diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile > >> index 7170eac81e..66025040bc 100644 > >> --- a/board/ti/common/Makefile > >> +++ b/board/ti/common/Makefile > >> @@ -4,3 +4,6 @@ > >> # > >> > >> obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o > >> +ifndef CONFIG_SPL_BUILD > >> +obj-${CONFIG_CMD_DDR3} += cmd_ddr3.o > >> +endif While I'm looking at this again, we should probably mirror cmd/mvebu here and move this to cmd/ti/ instead of board/ti/common/, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: imply CONFIG_OF_LIBFDT_OVERLAY
On Tue, Dec 19, 2017 at 05:12:00PM +0530, Jagan Teki wrote: > On Wed, Dec 13, 2017 at 2:16 PM, Andre Heider wrote: > > fdt overlay support is useful for all sunxi boards, enable per default > > and remove it from sunxi defconfigs. > > > > Signed-off-by: Andre Heider > > --- > > > > Hi, > > > > there're way too many sunxi boards so I'm not 100% sure this is the best > > approach... > > > > Are there boards where enabling this is definitely not desired? > > > > Thanks, > > Andre > > > > arch/arm/Kconfig | 1 + > > configs/CHIP_defconfig | 1 - > > configs/CHIP_pro_defconfig | 1 - > > 3 files changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index 73909952d0..25847b3aa1 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -715,6 +715,7 @@ config ARCH_SUNXI > > select USE_TINY_PRINTF > > imply CMD_GPT > > imply FAT_WRITE > > + imply OF_LIBFDT_OVERLAY > > It's increasing u-boot.itb size to 512KB (which is 508K earlier) and > in either case the size moves on env side where env start 0x88000 > (504KB) Right, so maybe we can make that conditional to ARM? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] tools: fix incorrect usage of DT node unit address
On 3 December 2017 at 19:05, Andre Przywara wrote: > The DT spec demands a unit-address in a node name to match the "reg" > property in that node. Newer dtc versions will throw warnings if this is > not the case. > Correct the generated unit names when U-Boot's mkimage creates a FIT > image. > > Signed-off-by: Andre Przywara > --- > tools/fit_image.c | 24 > 1 file changed, 12 insertions(+), 12 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] armv8: secure firmware: fix incorrect unit address in node name
Hi Andre, On 3 December 2017 at 19:05, Andre Przywara wrote: > The DT spec demands a unit-address in a node name to match the "reg" > property in that node. Newer dtc versions will throw warnings if this is > not the case. > Remove the unit address from the config node name when U-Boot deals with > secure firmware FIT images. > > Signed-off-by: Andre Przywara > --- > arch/arm/cpu/armv8/sec_firmware.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass After this series, what remains to be converted? - Simon Applied to u-boot-dm thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] doc: fix incorrect usage of DT node unit address
On 3 December 2017 at 19:05, Andre Przywara wrote: > The DT spec demands a unit-address in a node name to match the "reg" > property in that node. Newer dtc versions will throw warnings if this is > not the case. > Fix all occurences in various documentation files where this was not > observed, to not give bad examples to the reader. > > Signed-off-by: Andre Przywara > --- > .../arm/cpu/armv8/fsl-layerscape/doc/README.falcon | 16 +- > doc/README.uniphier| 36 > +++--- > doc/chromium/chromebook_jerry.its | 16 +- > doc/chromium/nyan-big.its | 16 +- > 4 files changed, 42 insertions(+), 42 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] tools: fix incorrect usage of DT node unit address
On 3 December 2017 at 19:05, Andre Przywara wrote: > The DT spec demands a unit-address in a node name to match the "reg" > property in that node. Newer dtc versions will throw warnings if this is > not the case. > Correct the generated unit names when U-Boot's mkimage creates a FIT > image. > > Signed-off-by: Andre Przywara > --- > tools/fit_image.c | 24 > 1 file changed, 12 insertions(+), 12 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm thanks! Applied to u-boot-dm thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] sunxi: arm64: correct usage of DT node address in FIT generation
Hi Simon, thanks for going through this! On 19/12/17 04:24, Simon Glass wrote: > Hi Andre, > > On 3 December 2017 at 19:05, Andre Przywara wrote: >> The DT spec demands a unit-address in a node name to match the "reg" >> property in that node. Newer dtc versions will throw warnings if this is >> not the case. >> Adjust the FIT build script for 64-bit Allwinner boards to remove the >> bogus addresses from the node names and avoid the warnings. >> This avoids a warning with recent versions of the dtc tool. >> >> Signed-off-by: Andre Przywara >> --- >> board/sunxi/mksunxi_fit_atf.sh | 16 >> 1 file changed, 8 insertions(+), 8 deletions(-) >> Applied to u-boot-dm thanks! Applied to u-boot-dm thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] sunxi: arm64: correct usage of DT node address in FIT generation
Hi Simon, thanks for going through this! On 19/12/17 04:24, Simon Glass wrote: > Hi Andre, > > On 3 December 2017 at 19:05, Andre Przywara wrote: >> The DT spec demands a unit-address in a node name to match the "reg" >> property in that node. Newer dtc versions will throw warnings if this is >> not the case. >> Adjust the FIT build script for 64-bit Allwinner boards to remove the >> bogus addresses from the node names and avoid the warnings. >> This avoids a warning with recent versions of the dtc tool. >> >> Signed-off-by: Andre Przywara >> --- >> board/sunxi/mksunxi_fit_atf.sh | 16 >> 1 file changed, 8 insertions(+), 8 deletions(-) >> Applied to u-boot-dm thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] armv8: secure firmware: fix incorrect unit address in node name
Hi Andre, On 3 December 2017 at 19:05, Andre Przywara wrote: > The DT spec demands a unit-address in a node name to match the "reg" > property in that node. Newer dtc versions will throw warnings if this is > not the case. > Remove the unit address from the config node name when U-Boot deals with > secure firmware FIT images. > > Signed-off-by: Andre Przywara > --- > arch/arm/cpu/armv8/sec_firmware.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass After this series, what remains to be converted? - Simon Applied to u-boot-dm thanks! Applied to u-boot-dm thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] fix incorrect usage of DT node unit address in comments
On 3 December 2017 at 19:05, Andre Przywara wrote: > The DT spec demands a unit-address in a node name to match the "reg" > property in that node. Newer dtc versions will throw warnings if this is > not the case. > Fix all occurences in the tree where node names were mentioned in > comments, to not give bad examples to the reader. > > Signed-off-by: Andre Przywara > --- > common/image-fit.c | 16 > common/image-sig.c | 2 +- > include/image.h| 26 +- > tools/image-host.c | 10 +- > 4 files changed, 27 insertions(+), 27 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] binman: Run code coverage tests
Binman has 100% test coverage for the code as it is at present. To encourage it to stay that way, run the code-coverage test as part of the normal U-Boot tests. This is RFC because it requires the Python code coverage tools to be available. Signed-off-by: Simon Glass --- Changes in v2: - Drop patches already applied - Run tests with travis-ci also - Drop RFC tag from patch for binman code-coverage tests test/run | 7 +++ 1 file changed, 7 insertions(+) Applied to u-boot-dm thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/7] travis.yml: Run tests for tools
Run tests for the Python tools used by U-Boot. Signed-off-by: Simon Glass --- Changes in v2: None .travis.yml | 15 +++ 1 file changed, 15 insertions(+) Applied to u-boot-dm thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: > So even though the actual u-boot.bin for 64-bit boards is still somewhat > below the limit (~480KB), adding the ATF image (~32KB) pushes it over > the edge. So since v2017.11 u-boot.itb is already too big for the > traditional MMC env location. So I've had a quick look about what could go possibly go away in our current armv8 config (using the pine64+ defconfig). Let me know if some are actually vitals: - FIT_ENABLE_SHA256_SUPPORT - CONSOLE_MUX - CMD_CRC32 - CMD_LZMADEC - CMD_UNZIP - CMD_LOADB - CMD_LOADS - CMD_MISC (actually implementing the command sleep) - ISO_PARTITION (yes. For CDROMs.) - VIDEO_BPP8, VIDEO_BPP16 - VIDEO_ANSI - SHA256 - LZMA Removing those options make the u-boot.itb binary size going from 516kB to 478kB, making it functional again *and* allowing us to enable the DT overlays that seem way more important than any feature mentionned above (and bumps the size to 483kB). Let me know what you think, Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote: > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: > > So even though the actual u-boot.bin for 64-bit boards is still somewhat > > below the limit (~480KB), adding the ATF image (~32KB) pushes it over > > the edge. So since v2017.11 u-boot.itb is already too big for the > > traditional MMC env location. > > So I've had a quick look about what could go possibly go away in our > current armv8 config (using the pine64+ defconfig). Let me know if > some are actually vitals: > > - FIT_ENABLE_SHA256_SUPPORT > - CONSOLE_MUX > - CMD_CRC32 > - CMD_LZMADEC > - CMD_UNZIP > - CMD_LOADB > - CMD_LOADS > - CMD_MISC (actually implementing the command sleep) > - ISO_PARTITION (yes. For CDROMs.) > - VIDEO_BPP8, VIDEO_BPP16 > - VIDEO_ANSI > - SHA256 > - LZMA > > Removing those options make the u-boot.itb binary size going from > 516kB to 478kB, making it functional again *and* allowing us to enable > the DT overlays that seem way more important than any feature > mentionned above (and bumps the size to 483kB). You want to keep sha256 support in FIT images, we only have dropping that allowed for some very odd use-cases. And while I don't have a strong opinion about unzip, lzma is one of the valid/likelu compressions for an Image (and aside, I, or someone, needs to look into having 'booti' recognize various compression algorithms and automatically decompress them) so I don't think we should get rid of that. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] doc: FIT image: fix incorrect description of DT node unit address
On 18 December 2017 at 21:24, Simon Glass wrote: > On 3 December 2017 at 19:05, Andre Przywara wrote: >> The DT spec demands a unit-address in a node name to match the "reg" >> property in that node. Newer dtc versions will throw warnings if this is >> not the case. >> Fix all occurences in the FIT image documentation files where this was not >> observed, to not give bad examples to the reader. >> >> Signed-off-by: Andre Przywara >> --- >> doc/uImage.FIT/beaglebone_vboot.txt | 84 +++--- >> doc/uImage.FIT/command_syntax_extensions.txt | 42 +-- >> doc/uImage.FIT/howto.txt | 52 +++--- >> doc/uImage.FIT/overlay-fdt-boot.txt | 78 ++--- >> doc/uImage.FIT/signature.txt | 100 >> +-- >> doc/uImage.FIT/source_file_format.txt| 26 +++ >> doc/uImage.FIT/x86-fit-boot.txt | 10 +-- >> 7 files changed, 196 insertions(+), 196 deletions(-) >> > > Reviewed-by: Simon Glass > > I'm not hugely keen on the inconsistency of kernel vs. hash@1, but I > suppose it does not matter. Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] doc: FIT image: fix incorrect examples of DT node unit address
On 18 December 2017 at 21:24, Simon Glass wrote: > On 3 December 2017 at 19:05, Andre Przywara wrote: >> The DT spec demands a unit-address of a node name to match the "reg" >> property in that node. Newer dtc versions will throw warnings if this is >> not the case. >> Fix all occurences in the FIT image example files where this was not >> observed, to not give bad examples to the reader. >> >> Signed-off-by: Andre Przywara >> --- >> doc/uImage.FIT/kernel.its | 28 - >> doc/uImage.FIT/kernel_fdt.its | 20 ++-- >> doc/uImage.FIT/multi-with-fpga.its | 28 - >> doc/uImage.FIT/multi-with-loadables.its | 40 >> doc/uImage.FIT/multi.its| 54 >> - >> doc/uImage.FIT/multi_spl.its| 14 - >> doc/uImage.FIT/sign-configs.its | 18 +-- >> doc/uImage.FIT/sign-images.its | 16 +- >> doc/uImage.FIT/update3.its | 12 >> doc/uImage.FIT/update_uboot.its | 4 +-- >> 10 files changed, 117 insertions(+), 117 deletions(-) > > Reviewed-by: Simon Glass Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3][v3] common: Fix-up MAC addr in dts by fetching env variable serially
On 12 December 2017 at 10:56, York Sun wrote: > On 11/23/2017 03:22 AM, Prabhakar Kushwaha wrote: >> The MAC addresses get fixed in the device tree for "ethernet" nodes >> is by using trailing number behind "ethernet" found in "/aliases". >> It may not be necessary for the "ethernet" nodes to be sequential. >> There can be gaps in between or any node disabled >> >> So provide a support to fetch MAC addr sequentially from env >> and apply them to "ethernet" nodes in the order they appear in >> device tree only if "ethernet" is not "disabled" >> >> Signed-off-by: Prabhakar Kushwaha >> --- >> Changes for v2: Updated description and README >> Changes for v3: sending as it is >> > > Reviewed-by: York Sun Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] test: Run patman tests
On 26 November 2017 at 20:25, Simon Glass wrote: > Update the test script to run the patman tests also. > > Signed-off-by: Simon Glass > --- > > Changes in v2: None > > test/run | 1 + > 1 file changed, 1 insertion(+) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] test: Run buildman tests
On 26 November 2017 at 20:25, Simon Glass wrote: > Update the test script to run the buildman tests also. > > Signed-off-by: Simon Glass > --- > > Changes in v2: None > > test/run | 1 + > 1 file changed, 1 insertion(+) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/7] test: Run binman tests
On 26 November 2017 at 20:25, Simon Glass wrote: > Update the test script to run the binman tests also. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Adjust PYTHONPATH for new locations > > test/run | 3 +++ > 1 file changed, 3 insertions(+) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] [v3] boards: ls1046ardb: disable unavailable "ethernet" node in dts
On 12 December 2017 at 10:56, York Sun wrote: > On 11/23/2017 03:22 AM, Prabhakar Kushwaha wrote: >> Linux device tree contains "ethernet" node for all possible >> interface supported by SoC i.e. LS1046A. >> >> It is not necessary for a SerDes protocol to support all possible >> interface. So disable unavailable "ethernet" node in device tree. >> >> Also, enable FDT_SEQ_MACADDR_FROM_ENV to fetch MAC address >> sequentially from environment variables >> >> Signed-off-by: Prabhakar Kushwaha >> --- >> Changes for v2: Sending as it is >> Changes for v3: updated ethernet node for disable >> > > Reviewed-by: York Sun > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] test: Run dtoc tests
On 26 November 2017 at 20:25, Simon Glass wrote: > Update the test script to run the dtoc tests also. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Adjust PYTHONPATH for new locations > > test/run | 1 + > 1 file changed, 1 insertion(+) Applied to u-boot-dm ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3][v3] arm: Add support of updating dts before fix-up
On 12 December 2017 at 10:56, York Sun wrote: > On 11/23/2017 03:22 AM, Prabhakar Kushwaha wrote: >> "ethernet" node fix-up for device tree happens before Linux boot. >> >> There can be requirement of updating "ethernet" node even before >> fix-up. So, add support of updating "ethernet" node. >> >> Signed-off-by: Prabhakar Kushwaha >> --- >> Changes for v2: Sending as it is >> Changes for v2: Sending as it is >> > > Reviewed-by: York Sun Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
1;5002;0c On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote: > On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote: > > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: > > > So even though the actual u-boot.bin for 64-bit boards is still somewhat > > > below the limit (~480KB), adding the ATF image (~32KB) pushes it over > > > the edge. So since v2017.11 u-boot.itb is already too big for the > > > traditional MMC env location. > > > > So I've had a quick look about what could go possibly go away in our > > current armv8 config (using the pine64+ defconfig). Let me know if > > some are actually vitals: > > > > - FIT_ENABLE_SHA256_SUPPORT > > - CONSOLE_MUX > > - CMD_CRC32 > > - CMD_LZMADEC > > - CMD_UNZIP > > - CMD_LOADB > > - CMD_LOADS > > - CMD_MISC (actually implementing the command sleep) > > - ISO_PARTITION (yes. For CDROMs.) > > - VIDEO_BPP8, VIDEO_BPP16 > > - VIDEO_ANSI > > - SHA256 > > - LZMA > > > > Removing those options make the u-boot.itb binary size going from > > 516kB to 478kB, making it functional again *and* allowing us to enable > > the DT overlays that seem way more important than any feature > > mentionned above (and bumps the size to 483kB). > > You want to keep sha256 support in FIT images, we only have dropping > that allowed for some very odd use-cases. And while I don't have a > strong opinion about unzip, lzma is one of the valid/likelu compressions > for an Image (and aside, I, or someone, needs to look into having > 'booti' recognize various compression algorithms and automatically > decompress them) so I don't think we should get rid of that. So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at 499kB. Still tight, but it fits. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On 12/19/2017 02:12 PM, Maxime Ripard wrote: On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: So even though the actual u-boot.bin for 64-bit boards is still somewhat below the limit (~480KB), adding the ATF image (~32KB) pushes it over the edge. So since v2017.11 u-boot.itb is already too big for the traditional MMC env location. So I've had a quick look about what could go possibly go away in our current armv8 config (using the pine64+ defconfig). Let me know if some are actually vitals: - FIT_ENABLE_SHA256_SUPPORT - CONSOLE_MUX - CMD_CRC32 We use this in travis tests, but since no Allwinner systems are present there, I guess we don't care. - CMD_LZMADEC - CMD_UNZIP - CMD_LOADB - CMD_LOADS - CMD_MISC (actually implementing the command sleep) - ISO_PARTITION (yes. For CDROMs.) This one is needed to boot openSUSE or SLES images, since they come as .iso with el torito (which then gets booted using distro + bootefi). - VIDEO_BPP8, VIDEO_BPP16 - VIDEO_ANSI - SHA256 - LZMA Removing those options make the u-boot.itb binary size going from 516kB to 478kB, making it functional again *and* allowing us to enable the DT overlays that seem way more important than any feature mentionned above (and bumps the size to 483kB). Let me know what you think, Out of the ones above, only ISO_PARTITION is the one I would definitely care about; please don't remove that one ;) Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 19, 2017 at 02:26:40PM +0100, Maxime Ripard wrote: > 1;5002;0c > On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote: > > On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote: > > > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: > > > > So even though the actual u-boot.bin for 64-bit boards is still somewhat > > > > below the limit (~480KB), adding the ATF image (~32KB) pushes it over > > > > the edge. So since v2017.11 u-boot.itb is already too big for the > > > > traditional MMC env location. > > > > > > So I've had a quick look about what could go possibly go away in our > > > current armv8 config (using the pine64+ defconfig). Let me know if > > > some are actually vitals: > > > > > > - FIT_ENABLE_SHA256_SUPPORT > > > - CONSOLE_MUX > > > - CMD_CRC32 > > > - CMD_LZMADEC > > > - CMD_UNZIP > > > - CMD_LOADB > > > - CMD_LOADS > > > - CMD_MISC (actually implementing the command sleep) > > > - ISO_PARTITION (yes. For CDROMs.) > > > - VIDEO_BPP8, VIDEO_BPP16 > > > - VIDEO_ANSI > > > - SHA256 > > > - LZMA > > > > > > Removing those options make the u-boot.itb binary size going from > > > 516kB to 478kB, making it functional again *and* allowing us to enable > > > the DT overlays that seem way more important than any feature > > > mentionned above (and bumps the size to 483kB). > > > > You want to keep sha256 support in FIT images, we only have dropping > > that allowed for some very odd use-cases. And while I don't have a > > strong opinion about unzip, lzma is one of the valid/likelu compressions > > for an Image (and aside, I, or someone, needs to look into having > > 'booti' recognize various compression algorithms and automatically > > decompress them) so I don't think we should get rid of that. > > So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at > 499kB. Still tight, but it fits. Looking over myself, perhaps drop CMD_BOOTD and move LOGLEVEL to 3? -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-dm
Hi Tom, Here is the remainder of my queue for u-boot-dm, including the test patches that were dropped. If any of the test patches cause a problem with your workflow, please let me know. If you would rather hold these off until next release that's fine too. I have had to leave out the live-tree translation patch due to it breaking Jetson-TX1. It looks like you are tracking that: http://patchwork.ozlabs.org/patch/849881/ It would be good to get that in if we can once we have a respin. Travis build here (I'm running another now): https://travis-ci.org/sglass68/u-boot/builds/318440976 The following changes since commit 9da71fc83a38e9dbf71240b3e548f6b37417764a: Prepare v2018.01-rc2 (2017-12-18 20:55:17 -0500) are available in the Git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to a1626e99b5d00f7d99469dc30b6201ab69d4d5bd: armv8: secure firmware: fix incorrect unit address in node name (2017-12-18 21:25:57 -0700) Andre Przywara (7): doc: FIT image: fix incorrect description of DT node unit address doc: FIT image: fix incorrect examples of DT node unit address doc: fix incorrect usage of DT node unit address fix incorrect usage of DT node unit address in comments sunxi: arm64: correct usage of DT node address in FIT generation tools: fix incorrect usage of DT node unit address armv8: secure firmware: fix incorrect unit address in node name Prabhakar Kushwaha (3): common: Fix-up MAC addr in dts by fetching env variable serially arm: Add support of updating dts before fix-up boards: ls1046ardb: disable unavailable "ethernet" node in dts Simon Glass (6): test: Run binman tests test: Run patman tests test: Run buildman tests test: Run dtoc tests travis.yml: Run tests for tools binman: Run code coverage tests .travis.yml| 15 README | 9 ++ .../arm/cpu/armv8/fsl-layerscape/doc/README.falcon | 16 ++-- arch/arm/cpu/armv8/sec_firmware.c | 2 +- arch/arm/lib/bootm-fdt.c | 12 +++ board/freescale/ls1046ardb/eth.c | 51 +++ board/sunxi/mksunxi_fit_atf.sh | 16 ++-- common/fdt_support.c | 25 +- common/image-fit.c | 16 ++-- common/image-sig.c | 2 +- doc/README.uniphier| 36 doc/chromium/chromebook_jerry.its | 16 ++-- doc/chromium/nyan-big.its | 16 ++-- doc/uImage.FIT/beaglebone_vboot.txt| 84 - doc/uImage.FIT/command_syntax_extensions.txt | 42 - doc/uImage.FIT/howto.txt | 52 +-- doc/uImage.FIT/kernel.its | 28 +++--- doc/uImage.FIT/kernel_fdt.its | 20 ++--- doc/uImage.FIT/multi-with-fpga.its | 28 +++--- doc/uImage.FIT/multi-with-loadables.its| 40 - doc/uImage.FIT/multi.its | 54 +-- doc/uImage.FIT/multi_spl.its | 14 +-- doc/uImage.FIT/overlay-fdt-boot.txt| 78 doc/uImage.FIT/sign-configs.its| 18 ++-- doc/uImage.FIT/sign-images.its | 16 ++-- doc/uImage.FIT/signature.txt | 100 ++--- doc/uImage.FIT/source_file_format.txt | 26 +++--- doc/uImage.FIT/update3.its | 12 +-- doc/uImage.FIT/update_uboot.its| 4 +- doc/uImage.FIT/x86-fit-boot.txt| 10 +-- include/configs/ls1046ardb.h | 2 + include/fdt_support.h | 3 + include/image.h| 26 +++--- test/run | 13 +++ tools/fit_image.c | 24 ++--- tools/image-host.c | 10 +-- 36 files changed, 529 insertions(+), 407 deletions(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 19, 2017 at 02:28:03PM +0100, Alexander Graf wrote: > On 12/19/2017 02:12 PM, Maxime Ripard wrote: > >On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: > >>So even though the actual u-boot.bin for 64-bit boards is still somewhat > >>below the limit (~480KB), adding the ATF image (~32KB) pushes it over > >>the edge. So since v2017.11 u-boot.itb is already too big for the > >>traditional MMC env location. > >So I've had a quick look about what could go possibly go away in our > >current armv8 config (using the pine64+ defconfig). Let me know if > >some are actually vitals: > > > > - FIT_ENABLE_SHA256_SUPPORT > > - CONSOLE_MUX > > - CMD_CRC32 > > We use this in travis tests, but since no Allwinner systems are present > there, I guess we don't care. Note that tests that require CMD_CRC32 should be marked as such too. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
Hi Maxime, thanks for having a look! On 19/12/17 13:12, Maxime Ripard wrote: > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: >> So even though the actual u-boot.bin for 64-bit boards is still somewhat >> below the limit (~480KB), adding the ATF image (~32KB) pushes it over >> the edge. So since v2017.11 u-boot.itb is already too big for the >> traditional MMC env location. > > So I've had a quick look about what could go possibly go away in our > current armv8 config (using the pine64+ defconfig). Let me know if > some are actually vitals: > > - FIT_ENABLE_SHA256_SUPPORT > - CONSOLE_MUX > - CMD_CRC32 > - CMD_LZMADEC > - CMD_UNZIP > - CMD_LOADB > - CMD_LOADS > - CMD_MISC (actually implementing the command sleep) > - ISO_PARTITION (yes. For CDROMs.) As Alex mentioned, this is needed for some installer images, which come as ISOs. So if possible, we should keep this in. > - VIDEO_BPP8, VIDEO_BPP16 > - VIDEO_ANSI > - SHA256 > - LZMA From just looking at the names I am fine with the rest gone. But let me test tonight if there are any side effects. Some of them seem useful, but I would leave enabling them to the actual users. If someone needs it, they can enable them and loose the raw MMC environment. I think this is a fair trade-off. > Removing those options make the u-boot.itb binary size going from > 516kB to 478kB, making it functional again *and* allowing us to enable > the DT overlays that seem way more important than any feature > mentionned above (and bumps the size to 483kB). How important is the raw MMC environment for the ARM64 boards, actually? Most of the rationale for the 32-bit side seemed to apply to legacy use cases only. Do we have reports/complaints from 64-bit users? Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
> Date: Tue, 19 Dec 2017 14:12:02 +0100 > From: Maxime Ripard > > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: > > So even though the actual u-boot.bin for 64-bit boards is still somewhat > > below the limit (~480KB), adding the ATF image (~32KB) pushes it over > > the edge. So since v2017.11 u-boot.itb is already too big for the > > traditional MMC env location. > > So I've had a quick look about what could go possibly go away in our > current armv8 config (using the pine64+ defconfig). Let me know if > some are actually vitals: > > - FIT_ENABLE_SHA256_SUPPORT > - CONSOLE_MUX > - CMD_CRC32 > - CMD_LZMADEC > - CMD_UNZIP > - CMD_LOADB > - CMD_LOADS > - CMD_MISC (actually implementing the command sleep) > - ISO_PARTITION (yes. For CDROMs.) > - VIDEO_BPP8, VIDEO_BPP16 > - VIDEO_ANSI > - SHA256 > - LZMA > > Removing those options make the u-boot.itb binary size going from > 516kB to 478kB, making it functional again *and* allowing us to enable > the DT overlays that seem way more important than any feature > mentionned above (and bumps the size to 483kB). So without CONFIG_CONSOLE_MUX, what is the behaviour when both serial console and usb keyboard are present? Is the usb keyboard used when it is plugged in but serial otherwise? In any case, this would be just a stopgap measure for 2018.01 wouldn't it? We really have to move to the FAT-based environment or just bite the bullet and move the location of the environment. Personally I don't cutsomize my environment beyond setting boot_targets. So losing my old settings upon upgrade is not a big issue for me. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
> From: Andre Przywara > Date: Tue, 19 Dec 2017 13:38:59 + > > Hi Maxime, > > thanks for having a look! > > On 19/12/17 13:12, Maxime Ripard wrote: > > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: > >> So even though the actual u-boot.bin for 64-bit boards is still somewhat > >> below the limit (~480KB), adding the ATF image (~32KB) pushes it over > >> the edge. So since v2017.11 u-boot.itb is already too big for the > >> traditional MMC env location. > > > > So I've had a quick look about what could go possibly go away in our > > current armv8 config (using the pine64+ defconfig). Let me know if > > some are actually vitals: > > > > - FIT_ENABLE_SHA256_SUPPORT > > - CONSOLE_MUX > > - CMD_CRC32 > > - CMD_LZMADEC > > - CMD_UNZIP > > - CMD_LOADB > > - CMD_LOADS > > - CMD_MISC (actually implementing the command sleep) > > - ISO_PARTITION (yes. For CDROMs.) > > As Alex mentioned, this is needed for some installer images, which come > as ISOs. So if possible, we should keep this in. > > > - VIDEO_BPP8, VIDEO_BPP16 > > - VIDEO_ANSI > > - SHA256 > > - LZMA > > From just looking at the names I am fine with the rest gone. But let me > test tonight if there are any side effects. > > Some of them seem useful, but I would leave enabling them to the actual > users. If someone needs it, they can enable them and loose the raw MMC > environment. I think this is a fair trade-off. > > > Removing those options make the u-boot.itb binary size going from > > 516kB to 478kB, making it functional again *and* allowing us to enable > > the DT overlays that seem way more important than any feature > > mentionned above (and bumps the size to 483kB). > > How important is the raw MMC environment for the ARM64 boards, actually? > Most of the rationale for the 32-bit side seemed to apply to legacy use > cases only. Do we have reports/complaints from 64-bit users? For me/us (OpenBSD) the environment is still important. I have many setups where U-Boot lives on a uSD card but the installed OS lives on a USB device. In that scenario I set boot_targets to boot the EFI bootloader and OS off the USB disk. This is very helpfull for testing new versions of U-Boot as I can simply swap the uSD card. But for some setups this is essential as OpenBSD doesn't support the SD/MCC controller on all ARM hardware yet (but we do support it on Allwinner). Cheers, Mark ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 19, 2017 at 08:30:31AM -0500, Tom Rini wrote: > On Tue, Dec 19, 2017 at 02:26:40PM +0100, Maxime Ripard wrote: > > 1;5002;0c > > On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote: > > > On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote: > > > > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: > > > > > So even though the actual u-boot.bin for 64-bit boards is still > > > > > somewhat > > > > > below the limit (~480KB), adding the ATF image (~32KB) pushes it over > > > > > the edge. So since v2017.11 u-boot.itb is already too big for the > > > > > traditional MMC env location. > > > > > > > > So I've had a quick look about what could go possibly go away in our > > > > current armv8 config (using the pine64+ defconfig). Let me know if > > > > some are actually vitals: > > > > > > > > - FIT_ENABLE_SHA256_SUPPORT > > > > - CONSOLE_MUX > > > > - CMD_CRC32 > > > > - CMD_LZMADEC > > > > - CMD_UNZIP > > > > - CMD_LOADB > > > > - CMD_LOADS > > > > - CMD_MISC (actually implementing the command sleep) > > > > - ISO_PARTITION (yes. For CDROMs.) > > > > - VIDEO_BPP8, VIDEO_BPP16 > > > > - VIDEO_ANSI > > > > - SHA256 > > > > - LZMA > > > > > > > > Removing those options make the u-boot.itb binary size going from > > > > 516kB to 478kB, making it functional again *and* allowing us to enable > > > > the DT overlays that seem way more important than any feature > > > > mentionned above (and bumps the size to 483kB). > > > > > > You want to keep sha256 support in FIT images, we only have dropping > > > that allowed for some very odd use-cases. And while I don't have a > > > strong opinion about unzip, lzma is one of the valid/likelu compressions > > > for an Image (and aside, I, or someone, needs to look into having > > > 'booti' recognize various compression algorithms and automatically > > > decompress them) so I don't think we should get rid of that. > > > > So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at > > 499kB. Still tight, but it fits. > > Looking over myself, perhaps drop CMD_BOOTD and move LOGLEVEL to 3? And we're at 498kB now! :) Is CMD_ELF useful as well? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 19, 2017 at 02:28:03PM +0100, Alexander Graf wrote: > On 12/19/2017 02:12 PM, Maxime Ripard wrote: > > - VIDEO_BPP8, VIDEO_BPP16 > > - VIDEO_ANSI > > - SHA256 > > - LZMA > > > > Removing those options make the u-boot.itb binary size going from > > 516kB to 478kB, making it functional again *and* allowing us to enable > > the DT overlays that seem way more important than any feature > > mentionned above (and bumps the size to 483kB). > > > > Let me know what you think, > > Out of the ones above, only ISO_PARTITION is the one I would definitely care > about; please don't remove that one ;) Well, I guess you're never done with the 90s ;) And who knows, maybe it'll be hype again in a few years :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
Hi, On 19/12/17 13:51, Mark Kettenis wrote: >> From: Andre Przywara >> Date: Tue, 19 Dec 2017 13:38:59 + >> >> Hi Maxime, >> >> thanks for having a look! >> >> On 19/12/17 13:12, Maxime Ripard wrote: >>> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: So even though the actual u-boot.bin for 64-bit boards is still somewhat below the limit (~480KB), adding the ATF image (~32KB) pushes it over the edge. So since v2017.11 u-boot.itb is already too big for the traditional MMC env location. >>> >>> So I've had a quick look about what could go possibly go away in our >>> current armv8 config (using the pine64+ defconfig). Let me know if >>> some are actually vitals: >>> >>> - FIT_ENABLE_SHA256_SUPPORT >>> - CONSOLE_MUX >>> - CMD_CRC32 >>> - CMD_LZMADEC >>> - CMD_UNZIP >>> - CMD_LOADB >>> - CMD_LOADS >>> - CMD_MISC (actually implementing the command sleep) >>> - ISO_PARTITION (yes. For CDROMs.) >> >> As Alex mentioned, this is needed for some installer images, which come >> as ISOs. So if possible, we should keep this in. >> >>> - VIDEO_BPP8, VIDEO_BPP16 >>> - VIDEO_ANSI >>> - SHA256 >>> - LZMA >> >> From just looking at the names I am fine with the rest gone. But let me >> test tonight if there are any side effects. >> >> Some of them seem useful, but I would leave enabling them to the actual >> users. If someone needs it, they can enable them and loose the raw MMC >> environment. I think this is a fair trade-off. >> >>> Removing those options make the u-boot.itb binary size going from >>> 516kB to 478kB, making it functional again *and* allowing us to enable >>> the DT overlays that seem way more important than any feature >>> mentionned above (and bumps the size to 483kB). >> >> How important is the raw MMC environment for the ARM64 boards, actually? >> Most of the rationale for the 32-bit side seemed to apply to legacy use >> cases only. Do we have reports/complaints from 64-bit users? > > For me/us (OpenBSD) the environment is still important. I have many > setups where U-Boot lives on a uSD card but the installed OS lives on > a USB device. In that scenario I set boot_targets to boot the EFI > bootloader and OS off the USB disk. This is very helpfull for testing > new versions of U-Boot as I can simply swap the uSD card. But for > some setups this is essential as OpenBSD doesn't support the SD/MCC > controller on all ARM hardware yet (but we do support it on > Allwinner). I see, but I wasn't arguing for dropping the environment altogether, more for supporting FAT environments *only*. So how important is preserving existing environments over a firmware update in your scenario? I think this is the killer question here, isn't it? I'm inclined to just drop raw MMC environment support from sunxi64 boards and then enjoy the ~450KB more worth of code, until we hit the first MB boundary. I have builds with all (DDR3) A64 board DTs in the binary [1], which would be larger than 504K anyway. Cheers, Andre. [1] https://github.com/apritzel/pine64/commit/ee12bea43 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 19, 2017 at 01:38:59PM +, Andre Przywara wrote: > Hi Maxime, > > thanks for having a look! > > On 19/12/17 13:12, Maxime Ripard wrote: > > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: > >> So even though the actual u-boot.bin for 64-bit boards is still somewhat > >> below the limit (~480KB), adding the ATF image (~32KB) pushes it over > >> the edge. So since v2017.11 u-boot.itb is already too big for the > >> traditional MMC env location. > > > > So I've had a quick look about what could go possibly go away in our > > current armv8 config (using the pine64+ defconfig). Let me know if > > some are actually vitals: > > > > - FIT_ENABLE_SHA256_SUPPORT > > - CONSOLE_MUX > > - CMD_CRC32 > > - CMD_LZMADEC > > - CMD_UNZIP > > - CMD_LOADB > > - CMD_LOADS > > - CMD_MISC (actually implementing the command sleep) > > - ISO_PARTITION (yes. For CDROMs.) > > As Alex mentioned, this is needed for some installer images, which come > as ISOs. So if possible, we should keep this in. So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the overlay support, we're at 500kB. Again, tight, but under the limit. > > - VIDEO_BPP8, VIDEO_BPP16 > > - VIDEO_ANSI > > - SHA256 > > - LZMA > > From just looking at the names I am fine with the rest gone. But let me > test tonight if there are any side effects. > > Some of them seem useful, but I would leave enabling them to the actual > users. If someone needs it, they can enable them and loose the raw MMC > environment. I think this is a fair trade-off. Yes, that's my view too. > > Removing those options make the u-boot.itb binary size going from > > 516kB to 478kB, making it functional again *and* allowing us to enable > > the DT overlays that seem way more important than any feature > > mentionned above (and bumps the size to 483kB). > > How important is the raw MMC environment for the ARM64 boards, actually? > Most of the rationale for the 32-bit side seemed to apply to legacy use > cases only. Do we have reports/complaints from 64-bit users? Pretty much as important as it is on arm I guess. We just have less history, but the same use cases. I'd really like to give at least one release for transition, which would mean having a schedule like this: - in 2018.01, merge those config removals so that we have least have something that works quite fast - in 2018.03, merge the multiple environment patches. We seem to have reached a consensus here, so I'm not really concerned that we will have it merged. - in 2018.05, if needed, remove the raw MMC options and complete the transition to FAT. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 19, 2017 at 03:09:52PM +0100, Maxime Ripard wrote: > On Tue, Dec 19, 2017 at 08:30:31AM -0500, Tom Rini wrote: > > On Tue, Dec 19, 2017 at 02:26:40PM +0100, Maxime Ripard wrote: > > > 1;5002;0c > > > On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote: > > > > On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote: > > > > > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: > > > > > > So even though the actual u-boot.bin for 64-bit boards is still > > > > > > somewhat > > > > > > below the limit (~480KB), adding the ATF image (~32KB) pushes it > > > > > > over > > > > > > the edge. So since v2017.11 u-boot.itb is already too big for the > > > > > > traditional MMC env location. > > > > > > > > > > So I've had a quick look about what could go possibly go away in our > > > > > current armv8 config (using the pine64+ defconfig). Let me know if > > > > > some are actually vitals: > > > > > > > > > > - FIT_ENABLE_SHA256_SUPPORT > > > > > - CONSOLE_MUX > > > > > - CMD_CRC32 > > > > > - CMD_LZMADEC > > > > > - CMD_UNZIP > > > > > - CMD_LOADB > > > > > - CMD_LOADS > > > > > - CMD_MISC (actually implementing the command sleep) > > > > > - ISO_PARTITION (yes. For CDROMs.) > > > > > - VIDEO_BPP8, VIDEO_BPP16 > > > > > - VIDEO_ANSI > > > > > - SHA256 > > > > > - LZMA > > > > > > > > > > Removing those options make the u-boot.itb binary size going from > > > > > 516kB to 478kB, making it functional again *and* allowing us to enable > > > > > the DT overlays that seem way more important than any feature > > > > > mentionned above (and bumps the size to 483kB). > > > > > > > > You want to keep sha256 support in FIT images, we only have dropping > > > > that allowed for some very odd use-cases. And while I don't have a > > > > strong opinion about unzip, lzma is one of the valid/likelu compressions > > > > for an Image (and aside, I, or someone, needs to look into having > > > > 'booti' recognize various compression algorithms and automatically > > > > decompress them) so I don't think we should get rid of that. > > > > > > So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at > > > 499kB. Still tight, but it fits. > > > > Looking over myself, perhaps drop CMD_BOOTD and move LOGLEVEL to 3? > > And we're at 498kB now! :) > > Is CMD_ELF useful as well? That's a good question. In 32bit land, that's how you're going to launch FreeRTOS and proprietary apps and so forth. I don't know if for aarch64 people will still be doing ELF applications or UEFI applications for all of this. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
Hi, On 19/12/17 14:20, Tom Rini wrote: > On Tue, Dec 19, 2017 at 03:09:52PM +0100, Maxime Ripard wrote: >> On Tue, Dec 19, 2017 at 08:30:31AM -0500, Tom Rini wrote: >>> On Tue, Dec 19, 2017 at 02:26:40PM +0100, Maxime Ripard wrote: 1;5002;0c On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote: > On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote: >> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: >>> So even though the actual u-boot.bin for 64-bit boards is still somewhat >>> below the limit (~480KB), adding the ATF image (~32KB) pushes it over >>> the edge. So since v2017.11 u-boot.itb is already too big for the >>> traditional MMC env location. >> >> So I've had a quick look about what could go possibly go away in our >> current armv8 config (using the pine64+ defconfig). Let me know if >> some are actually vitals: >> >> - FIT_ENABLE_SHA256_SUPPORT >> - CONSOLE_MUX >> - CMD_CRC32 >> - CMD_LZMADEC >> - CMD_UNZIP >> - CMD_LOADB >> - CMD_LOADS >> - CMD_MISC (actually implementing the command sleep) >> - ISO_PARTITION (yes. For CDROMs.) >> - VIDEO_BPP8, VIDEO_BPP16 >> - VIDEO_ANSI >> - SHA256 >> - LZMA >> >> Removing those options make the u-boot.itb binary size going from >> 516kB to 478kB, making it functional again *and* allowing us to enable >> the DT overlays that seem way more important than any feature >> mentionned above (and bumps the size to 483kB). > > You want to keep sha256 support in FIT images, we only have dropping > that allowed for some very odd use-cases. And while I don't have a > strong opinion about unzip, lzma is one of the valid/likelu compressions > for an Image (and aside, I, or someone, needs to look into having > 'booti' recognize various compression algorithms and automatically > decompress them) so I don't think we should get rid of that. So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at 499kB. Still tight, but it fits. >>> >>> Looking over myself, perhaps drop CMD_BOOTD and move LOGLEVEL to 3? >> >> And we're at 498kB now! :) >> >> Is CMD_ELF useful as well? > > That's a good question. In 32bit land, that's how you're going to > launch FreeRTOS and proprietary apps and so forth. I don't know if for > aarch64 people will still be doing ELF applications or UEFI applications > for all of this. Eventually we will be, but for now (and the *defconfig*) I think it's fine to drop it. If we stick to Maxime's plan, we can get it back in 6 months or so. Cheers, Andre. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 19, 2017 at 02:22:59PM +, Andre Przywara wrote: > Hi, > > On 19/12/17 14:20, Tom Rini wrote: > > On Tue, Dec 19, 2017 at 03:09:52PM +0100, Maxime Ripard wrote: > >> On Tue, Dec 19, 2017 at 08:30:31AM -0500, Tom Rini wrote: > >>> On Tue, Dec 19, 2017 at 02:26:40PM +0100, Maxime Ripard wrote: > 1;5002;0c > On Tue, Dec 19, 2017 at 08:15:31AM -0500, Tom Rini wrote: > > On Tue, Dec 19, 2017 at 02:12:02PM +0100, Maxime Ripard wrote: > >> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: > >>> So even though the actual u-boot.bin for 64-bit boards is still > >>> somewhat > >>> below the limit (~480KB), adding the ATF image (~32KB) pushes it over > >>> the edge. So since v2017.11 u-boot.itb is already too big for the > >>> traditional MMC env location. > >> > >> So I've had a quick look about what could go possibly go away in our > >> current armv8 config (using the pine64+ defconfig). Let me know if > >> some are actually vitals: > >> > >> - FIT_ENABLE_SHA256_SUPPORT > >> - CONSOLE_MUX > >> - CMD_CRC32 > >> - CMD_LZMADEC > >> - CMD_UNZIP > >> - CMD_LOADB > >> - CMD_LOADS > >> - CMD_MISC (actually implementing the command sleep) > >> - ISO_PARTITION (yes. For CDROMs.) > >> - VIDEO_BPP8, VIDEO_BPP16 > >> - VIDEO_ANSI > >> - SHA256 > >> - LZMA > >> > >> Removing those options make the u-boot.itb binary size going from > >> 516kB to 478kB, making it functional again *and* allowing us to enable > >> the DT overlays that seem way more important than any feature > >> mentionned above (and bumps the size to 483kB). > > > > You want to keep sha256 support in FIT images, we only have dropping > > that allowed for some very odd use-cases. And while I don't have a > > strong opinion about unzip, lzma is one of the valid/likelu compressions > > for an Image (and aside, I, or someone, needs to look into having > > 'booti' recognize various compression algorithms and automatically > > decompress them) so I don't think we should get rid of that. > > So, adding back CMD_LZMADEC and FIT_ENABLE_SHA256_SUPPORT, we're at > 499kB. Still tight, but it fits. > >>> > >>> Looking over myself, perhaps drop CMD_BOOTD and move LOGLEVEL to 3? > >> > >> And we're at 498kB now! :) > >> > >> Is CMD_ELF useful as well? > > > > That's a good question. In 32bit land, that's how you're going to > > launch FreeRTOS and proprietary apps and so forth. I don't know if for > > aarch64 people will still be doing ELF applications or UEFI applications > > for all of this. > > Eventually we will be, but for now (and the *defconfig*) I think it's > fine to drop it. If we stick to Maxime's plan, we can get it back in 6 > months or so. If we have to, we have to. But I am weary of dropping and then re-adding functionality like that as you never know what version some company/vendor/etc is going to pick up and run with. If we can't keep the limit without dropping ELF, well, then we can't. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
Hi Maxime, On 19/12/17 14:20, Maxime Ripard wrote: > On Tue, Dec 19, 2017 at 01:38:59PM +, Andre Przywara wrote: >> Hi Maxime, >> >> thanks for having a look! >> >> On 19/12/17 13:12, Maxime Ripard wrote: >>> On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: So even though the actual u-boot.bin for 64-bit boards is still somewhat below the limit (~480KB), adding the ATF image (~32KB) pushes it over the edge. So since v2017.11 u-boot.itb is already too big for the traditional MMC env location. >>> >>> So I've had a quick look about what could go possibly go away in our >>> current armv8 config (using the pine64+ defconfig). Let me know if >>> some are actually vitals: >>> >>> - FIT_ENABLE_SHA256_SUPPORT >>> - CONSOLE_MUX >>> - CMD_CRC32 >>> - CMD_LZMADEC >>> - CMD_UNZIP >>> - CMD_LOADB >>> - CMD_LOADS >>> - CMD_MISC (actually implementing the command sleep) >>> - ISO_PARTITION (yes. For CDROMs.) >> >> As Alex mentioned, this is needed for some installer images, which come >> as ISOs. So if possible, we should keep this in. > > So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the > overlay support, we're at 500kB. > > Again, tight, but under the limit. Phew! ;-) > >>> - VIDEO_BPP8, VIDEO_BPP16 >>> - VIDEO_ANSI >>> - SHA256 >>> - LZMA >> >> From just looking at the names I am fine with the rest gone. But let me >> test tonight if there are any side effects. >> >> Some of them seem useful, but I would leave enabling them to the actual >> users. If someone needs it, they can enable them and loose the raw MMC >> environment. I think this is a fair trade-off. > > Yes, that's my view too. > >>> Removing those options make the u-boot.itb binary size going from >>> 516kB to 478kB, making it functional again *and* allowing us to enable >>> the DT overlays that seem way more important than any feature >>> mentionned above (and bumps the size to 483kB). >> >> How important is the raw MMC environment for the ARM64 boards, actually? >> Most of the rationale for the 32-bit side seemed to apply to legacy use >> cases only. Do we have reports/complaints from 64-bit users? > > Pretty much as important as it is on arm I guess. We just have less > history, but the same use cases. > > I'd really like to give at least one release for transition, which > would mean having a schedule like this: > > - in 2018.01, merge those config removals so that we have least have > something that works quite fast > > - in 2018.03, merge the multiple environment patches. We seem to > have reached a consensus here, so I'm not really concerned that we > will have it merged. > > - in 2018.05, if needed, remove the raw MMC options and complete the > transition to FAT. That sounds very reasonable to me, thanks for writing this down! This gives us an only intermediate shortage of features for defconfig. We should encourage everyone who builds (and ships) firmware right now to drop MMC env support already, if they tinker with the .config anyway. That is, if there is no legacy usage to be concerned about. Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 19, 2017 at 7:57 PM, Andre Przywara wrote: > Hi Maxime, > > On 19/12/17 14:20, Maxime Ripard wrote: >> On Tue, Dec 19, 2017 at 01:38:59PM +, Andre Przywara wrote: >>> Hi Maxime, >>> >>> thanks for having a look! >>> >>> On 19/12/17 13:12, Maxime Ripard wrote: On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: > So even though the actual u-boot.bin for 64-bit boards is still somewhat > below the limit (~480KB), adding the ATF image (~32KB) pushes it over > the edge. So since v2017.11 u-boot.itb is already too big for the > traditional MMC env location. So I've had a quick look about what could go possibly go away in our current armv8 config (using the pine64+ defconfig). Let me know if some are actually vitals: - FIT_ENABLE_SHA256_SUPPORT - CONSOLE_MUX - CMD_CRC32 - CMD_LZMADEC - CMD_UNZIP - CMD_LOADB - CMD_LOADS - CMD_MISC (actually implementing the command sleep) - ISO_PARTITION (yes. For CDROMs.) >>> >>> As Alex mentioned, this is needed for some installer images, which come >>> as ISOs. So if possible, we should keep this in. >> >> So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the >> overlay support, we're at 500kB. >> >> Again, tight, but under the limit. > > Phew! ;-) > >> - VIDEO_BPP8, VIDEO_BPP16 - VIDEO_ANSI - SHA256 - LZMA >>> >>> From just looking at the names I am fine with the rest gone. But let me >>> test tonight if there are any side effects. >>> >>> Some of them seem useful, but I would leave enabling them to the actual >>> users. If someone needs it, they can enable them and loose the raw MMC >>> environment. I think this is a fair trade-off. >> >> Yes, that's my view too. >> Removing those options make the u-boot.itb binary size going from 516kB to 478kB, making it functional again *and* allowing us to enable the DT overlays that seem way more important than any feature mentionned above (and bumps the size to 483kB). >>> >>> How important is the raw MMC environment for the ARM64 boards, actually? >>> Most of the rationale for the 32-bit side seemed to apply to legacy use >>> cases only. Do we have reports/complaints from 64-bit users? >> >> Pretty much as important as it is on arm I guess. We just have less >> history, but the same use cases. >> >> I'd really like to give at least one release for transition, which >> would mean having a schedule like this: >> >> - in 2018.01, merge those config removals so that we have least have >> something that works quite fast >> >> - in 2018.03, merge the multiple environment patches. We seem to >> have reached a consensus here, so I'm not really concerned that we >> will have it merged. >> >> - in 2018.05, if needed, remove the raw MMC options and complete the >> transition to FAT. > > That sounds very reasonable to me, thanks for writing this down! > > This gives us an only intermediate shortage of features for defconfig. > > We should encourage everyone who builds (and ships) firmware right now > to drop MMC env support already, if they tinker with the .config anyway. > That is, if there is no legacy usage to be concerned about. All these trimming(if it fits) seems to be nice for now, but what if once driver-model MMC, reset, pinctrl, clk, regulator are IN? of-course we can't do anything with SPL size because of SRAM constraints, but U-Boot proper size? why can't we increase the u-boot partition size? thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
Hi, On 19/12/17 14:38, Jagan Teki wrote: > On Tue, Dec 19, 2017 at 7:57 PM, Andre Przywara > wrote: >> Hi Maxime, >> >> On 19/12/17 14:20, Maxime Ripard wrote: >>> On Tue, Dec 19, 2017 at 01:38:59PM +, Andre Przywara wrote: Hi Maxime, thanks for having a look! On 19/12/17 13:12, Maxime Ripard wrote: > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: >> So even though the actual u-boot.bin for 64-bit boards is still somewhat >> below the limit (~480KB), adding the ATF image (~32KB) pushes it over >> the edge. So since v2017.11 u-boot.itb is already too big for the >> traditional MMC env location. > > So I've had a quick look about what could go possibly go away in our > current armv8 config (using the pine64+ defconfig). Let me know if > some are actually vitals: > > - FIT_ENABLE_SHA256_SUPPORT > - CONSOLE_MUX > - CMD_CRC32 > - CMD_LZMADEC > - CMD_UNZIP > - CMD_LOADB > - CMD_LOADS > - CMD_MISC (actually implementing the command sleep) > - ISO_PARTITION (yes. For CDROMs.) As Alex mentioned, this is needed for some installer images, which come as ISOs. So if possible, we should keep this in. >>> >>> So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the >>> overlay support, we're at 500kB. >>> >>> Again, tight, but under the limit. >> >> Phew! ;-) >> >>> > - VIDEO_BPP8, VIDEO_BPP16 > - VIDEO_ANSI > - SHA256 > - LZMA From just looking at the names I am fine with the rest gone. But let me test tonight if there are any side effects. Some of them seem useful, but I would leave enabling them to the actual users. If someone needs it, they can enable them and loose the raw MMC environment. I think this is a fair trade-off. >>> >>> Yes, that's my view too. >>> > Removing those options make the u-boot.itb binary size going from > 516kB to 478kB, making it functional again *and* allowing us to enable > the DT overlays that seem way more important than any feature > mentionned above (and bumps the size to 483kB). How important is the raw MMC environment for the ARM64 boards, actually? Most of the rationale for the 32-bit side seemed to apply to legacy use cases only. Do we have reports/complaints from 64-bit users? >>> >>> Pretty much as important as it is on arm I guess. We just have less >>> history, but the same use cases. >>> >>> I'd really like to give at least one release for transition, which >>> would mean having a schedule like this: >>> >>> - in 2018.01, merge those config removals so that we have least have >>> something that works quite fast >>> >>> - in 2018.03, merge the multiple environment patches. We seem to >>> have reached a consensus here, so I'm not really concerned that we >>> will have it merged. >>> >>> - in 2018.05, if needed, remove the raw MMC options and complete the >>> transition to FAT. >> >> That sounds very reasonable to me, thanks for writing this down! >> >> This gives us an only intermediate shortage of features for defconfig. >> >> We should encourage everyone who builds (and ships) firmware right now >> to drop MMC env support already, if they tinker with the .config anyway. >> That is, if there is no legacy usage to be concerned about. > > All these trimming(if it fits) seems to be nice for now, but what if > once driver-model MMC, reset, pinctrl, clk, regulator are IN? But that is what all of this is about? At the moment we can't go beyond 504K because the raw MMC U-Boot environment lives there on the SD card. But with Maxime's plan for 2018.05, this will be gone and we should have about 984KB (1MB - 40K). Cheers, Andre. > of-course we can't do anything with SPL size because of SRAM > constraints, but U-Boot proper size? why can't we increase the u-boot > partition size? > > thanks! > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 19, 2017 at 10:38 PM, Jagan Teki wrote: > On Tue, Dec 19, 2017 at 7:57 PM, Andre Przywara > wrote: >> Hi Maxime, >> >> On 19/12/17 14:20, Maxime Ripard wrote: >>> On Tue, Dec 19, 2017 at 01:38:59PM +, Andre Przywara wrote: Hi Maxime, thanks for having a look! On 19/12/17 13:12, Maxime Ripard wrote: > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: >> So even though the actual u-boot.bin for 64-bit boards is still somewhat >> below the limit (~480KB), adding the ATF image (~32KB) pushes it over >> the edge. So since v2017.11 u-boot.itb is already too big for the >> traditional MMC env location. > > So I've had a quick look about what could go possibly go away in our > current armv8 config (using the pine64+ defconfig). Let me know if > some are actually vitals: > > - FIT_ENABLE_SHA256_SUPPORT > - CONSOLE_MUX > - CMD_CRC32 > - CMD_LZMADEC > - CMD_UNZIP > - CMD_LOADB > - CMD_LOADS > - CMD_MISC (actually implementing the command sleep) > - ISO_PARTITION (yes. For CDROMs.) As Alex mentioned, this is needed for some installer images, which come as ISOs. So if possible, we should keep this in. >>> >>> So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the >>> overlay support, we're at 500kB. >>> >>> Again, tight, but under the limit. >> >> Phew! ;-) >> >>> > - VIDEO_BPP8, VIDEO_BPP16 > - VIDEO_ANSI > - SHA256 > - LZMA From just looking at the names I am fine with the rest gone. But let me test tonight if there are any side effects. Some of them seem useful, but I would leave enabling them to the actual users. If someone needs it, they can enable them and loose the raw MMC environment. I think this is a fair trade-off. >>> >>> Yes, that's my view too. >>> > Removing those options make the u-boot.itb binary size going from > 516kB to 478kB, making it functional again *and* allowing us to enable > the DT overlays that seem way more important than any feature > mentionned above (and bumps the size to 483kB). How important is the raw MMC environment for the ARM64 boards, actually? Most of the rationale for the 32-bit side seemed to apply to legacy use cases only. Do we have reports/complaints from 64-bit users? >>> >>> Pretty much as important as it is on arm I guess. We just have less >>> history, but the same use cases. >>> >>> I'd really like to give at least one release for transition, which >>> would mean having a schedule like this: >>> >>> - in 2018.01, merge those config removals so that we have least have >>> something that works quite fast >>> >>> - in 2018.03, merge the multiple environment patches. We seem to >>> have reached a consensus here, so I'm not really concerned that we >>> will have it merged. >>> >>> - in 2018.05, if needed, remove the raw MMC options and complete the >>> transition to FAT. >> >> That sounds very reasonable to me, thanks for writing this down! >> >> This gives us an only intermediate shortage of features for defconfig. >> >> We should encourage everyone who builds (and ships) firmware right now >> to drop MMC env support already, if they tinker with the .config anyway. >> That is, if there is no legacy usage to be concerned about. > > All these trimming(if it fits) seems to be nice for now, but what if > once driver-model MMC, reset, pinctrl, clk, regulator are IN? > of-course we can't do anything with SPL size because of SRAM > constraints, but U-Boot proper size? why can't we increase the u-boot > partition size? That is a really big if, given no one is actively working on it. I reckon we deal with it when someone starts having patches merged. :) ChenYu ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 19, 2017 at 10:41:23PM +0800, Chen-Yu Tsai wrote: > > All these trimming(if it fits) seems to be nice for now, but what if > > once driver-model MMC, reset, pinctrl, clk, regulator are IN? I guess a better question would be: what are we doing to fix an issue we had in a release already and will destroy the binary as soon as someone does a saveenv? > > of-course we can't do anything with SPL size because of SRAM > > constraints, but U-Boot proper size? why can't we increase the u-boot > > partition size? > > That is a really big if, given no one is actively working on it. > I reckon we deal with it when someone starts having patches merged. :) +1. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] am335x_hs_evm: Trim options in SPL to reduce binary size
On 12/16/2017 10:04 PM, Tom Rini wrote: > The am335x_hs_evm runs into size constraint problems at times with > various toolchains as changes come in due to the config have a large > number of options in SPL (to showcase what is possible) while also > having rather constrained binary limits. Gain some of this room back by > lowering the loglevel, disabling HW partition support and switching over > to the tiny FIT image support. > > Cc: Andrew F. Davis > Signed-off-by: Tom Rini > --- > I'd really appreciate a run-time test of this patch if at all possible > as I'm a little worried about TINY_FIT being incompatible with all of > the security options. Thanks! > --- > configs/am335x_hs_evm_defconfig | 4 > 1 file changed, 4 insertions(+) > > diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig > index 48b0e8583997..8eb304686dc7 100644 > --- a/configs/am335x_hs_evm_defconfig > +++ b/configs/am335x_hs_evm_defconfig > @@ -13,10 +13,12 @@ CONFIG_ANDROID_BOOT_IMAGE=y > CONFIG_FIT_IMAGE_POST_PROCESS=y > CONFIG_SPL_LOAD_FIT=y > CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y > +CONFIG_LOGLEVEL=3 > CONFIG_SYS_CONSOLE_INFO_QUIET=y > CONFIG_VERSION_VARIABLE=y > CONFIG_ARCH_MISC_INIT=y > CONFIG_SPL=y > +CONFIG_SPL_FIT_IMAGE_TINY=y > # CONFIG_SPL_ENV_SUPPORT is not set > # CONFIG_SPL_EXT_SUPPORT is not set > CONFIG_SPL_MTD_SUPPORT=y > @@ -37,6 +39,7 @@ CONFIG_DFU_RAM=y > CONFIG_DM_I2C=y > CONFIG_MISC=y > CONFIG_DM_MMC=y > +# CONFIG_MMC_HW_PARTITIONING is not set I haven't gotten around to testing the FIT_IMAGE_TINY stuff yet, but conceptually I have a much bigger problem with this part. Sacrificing functionality to allow continued SPL bloat is just wrong. Whatever caused SPL to grow should be re-worked or the author should have also made some optimization elsewhere to offset this. Now I'll have to go hunt for more optimizations somewhere so I can get all my features back here :( > CONFIG_MMC_OMAP_HS=y > CONFIG_NAND=y > CONFIG_NAND_OMAP_GPMC_PREFETCH=y > @@ -61,5 +64,6 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0451 > CONFIG_USB_GADGET_PRODUCT_NUM=0xd022 > CONFIG_USB_GADGET_DOWNLOAD=y > CONFIG_USB_ETHER=y > +CONFIG_SPL_TINY_MEMSET=y > CONFIG_RSA=y > CONFIG_LZO=y > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] am335x_hs_evm: Trim options in SPL to reduce binary size
On Tue, Dec 19, 2017 at 08:54:25AM -0600, Andrew F. Davis wrote: > On 12/16/2017 10:04 PM, Tom Rini wrote: > > The am335x_hs_evm runs into size constraint problems at times with > > various toolchains as changes come in due to the config have a large > > number of options in SPL (to showcase what is possible) while also > > having rather constrained binary limits. Gain some of this room back by > > lowering the loglevel, disabling HW partition support and switching over > > to the tiny FIT image support. > > > > Cc: Andrew F. Davis > > Signed-off-by: Tom Rini > > --- > > I'd really appreciate a run-time test of this patch if at all possible > > as I'm a little worried about TINY_FIT being incompatible with all of > > the security options. Thanks! > > --- > > configs/am335x_hs_evm_defconfig | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/configs/am335x_hs_evm_defconfig > > b/configs/am335x_hs_evm_defconfig > > index 48b0e8583997..8eb304686dc7 100644 > > --- a/configs/am335x_hs_evm_defconfig > > +++ b/configs/am335x_hs_evm_defconfig > > @@ -13,10 +13,12 @@ CONFIG_ANDROID_BOOT_IMAGE=y > > CONFIG_FIT_IMAGE_POST_PROCESS=y > > CONFIG_SPL_LOAD_FIT=y > > CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y > > +CONFIG_LOGLEVEL=3 > > CONFIG_SYS_CONSOLE_INFO_QUIET=y > > CONFIG_VERSION_VARIABLE=y > > CONFIG_ARCH_MISC_INIT=y > > CONFIG_SPL=y > > +CONFIG_SPL_FIT_IMAGE_TINY=y > > # CONFIG_SPL_ENV_SUPPORT is not set > > # CONFIG_SPL_EXT_SUPPORT is not set > > CONFIG_SPL_MTD_SUPPORT=y > > @@ -37,6 +39,7 @@ CONFIG_DFU_RAM=y > > CONFIG_DM_I2C=y > > CONFIG_MISC=y > > CONFIG_DM_MMC=y > > +# CONFIG_MMC_HW_PARTITIONING is not set > > I haven't gotten around to testing the FIT_IMAGE_TINY stuff yet, but > conceptually I have a much bigger problem with this part. > > Sacrificing functionality to allow continued SPL bloat is just wrong. > > Whatever caused SPL to grow should be re-worked or the author should > have also made some optimization elsewhere to offset this. Now I'll have > to go hunt for more optimizations somewhere so I can get all my features > back here :( FWIW, I don't think there was any functionality (aside from switching to FIT_IMAGE_TINY, but if that supports everything needed in this use-case...) that was removed exactly. But I see your point too. Jean-Jacques, was there anything else that could have been made configurable in your MMC work, that wasn't? Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 19, 2017 at 02:41:17PM +0100, Mark Kettenis wrote: > > Date: Tue, 19 Dec 2017 14:12:02 +0100 > > From: Maxime Ripard > > > > On Tue, Dec 05, 2017 at 10:28:20AM +, Andre Przywara wrote: > > > So even though the actual u-boot.bin for 64-bit boards is still somewhat > > > below the limit (~480KB), adding the ATF image (~32KB) pushes it over > > > the edge. So since v2017.11 u-boot.itb is already too big for the > > > traditional MMC env location. > > > > So I've had a quick look about what could go possibly go away in our > > current armv8 config (using the pine64+ defconfig). Let me know if > > some are actually vitals: > > > > - FIT_ENABLE_SHA256_SUPPORT > > - CONSOLE_MUX > > - CMD_CRC32 > > - CMD_LZMADEC > > - CMD_UNZIP > > - CMD_LOADB > > - CMD_LOADS > > - CMD_MISC (actually implementing the command sleep) > > - ISO_PARTITION (yes. For CDROMs.) > > - VIDEO_BPP8, VIDEO_BPP16 > > - VIDEO_ANSI > > - SHA256 > > - LZMA > > > > Removing those options make the u-boot.itb binary size going from > > 516kB to 478kB, making it functional again *and* allowing us to enable > > the DT overlays that seem way more important than any feature > > mentionned above (and bumps the size to 483kB). > > So without CONFIG_CONSOLE_MUX, what is the behaviour when both serial > console and usb keyboard are present? Is the usb keyboard used when > it is plugged in but serial otherwise? That's actually a very good question, and I don't know, I never used a USB keyboard with U-Boot. This is enabled on 7 Allwinner boards, and no one complained so far, so I would expect to work without that option activated. However, it doesn't take that much space either, so it's not like we really need to disable it either. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: imply CONFIG_OF_LIBFDT_OVERLAY
On 19/12/17 13:51, Maxime Ripard wrote: On Tue, Dec 19, 2017 at 05:12:00PM +0530, Jagan Teki wrote: On Wed, Dec 13, 2017 at 2:16 PM, Andre Heider wrote: fdt overlay support is useful for all sunxi boards, enable per default and remove it from sunxi defconfigs. Signed-off-by: Andre Heider --- Hi, there're way too many sunxi boards so I'm not 100% sure this is the best approach... Are there boards where enabling this is definitely not desired? Thanks, Andre arch/arm/Kconfig | 1 + configs/CHIP_defconfig | 1 - configs/CHIP_pro_defconfig | 1 - 3 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 73909952d0..25847b3aa1 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -715,6 +715,7 @@ config ARCH_SUNXI select USE_TINY_PRINTF imply CMD_GPT imply FAT_WRITE + imply OF_LIBFDT_OVERLAY It's increasing u-boot.itb size to 512KB (which is 508K earlier) and in either case the size moves on env side where env start 0x88000 (504KB) Right, so maybe we can make that conditional to ARM? Maxime From the 'we're out of space' thread: ... > So, with FIT_ENABLE_SHA256_SUPPORT, LZMADEC, ISO_PARTITION and the > overlay support, we're at 500kB. > > Again, tight, but under the limit. ... If I understood correctly the issue will be solved without any requiring changes to this patch. Let me know if that is not the case. Thanks, Andre ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM64 Allwinner Binary Size
On Tue, Dec 19, 2017 at 02:27:57PM +, Andre Przywara wrote: > >>> Removing those options make the u-boot.itb binary size going from > >>> 516kB to 478kB, making it functional again *and* allowing us to enable > >>> the DT overlays that seem way more important than any feature > >>> mentionned above (and bumps the size to 483kB). > >> > >> How important is the raw MMC environment for the ARM64 boards, actually? > >> Most of the rationale for the 32-bit side seemed to apply to legacy use > >> cases only. Do we have reports/complaints from 64-bit users? > > > > Pretty much as important as it is on arm I guess. We just have less > > history, but the same use cases. > > > > I'd really like to give at least one release for transition, which > > would mean having a schedule like this: > > > > - in 2018.01, merge those config removals so that we have least have > > something that works quite fast So, given the various feedback, the current diff for the pine64 is: http://code.bulix.org/t7icrw-243561 With that, We're at 500kB with the ATF. Does it work for everyone here? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 1/2] ARM: DTS: stm32: add MMC nodes for stm32f746-disco and stm32f769-disco
On 12 December 2017 at 02:14, wrote: > From: Patrice Chotard > > Add DT nodes to enable ARM_PL180_MMCI IP support for STM32F746 > and STM32F769 discovery boards > > There is a hardware issue on these boards, it misses a pullup on the GPIO line > used as card detect to allow correct SD card detection. > As workaround, cd-gpios property is not present in DT. > So SD card is always considered present in the slot. > > Signed-off-by: Christophe Priouzeau > Signed-off-by: Patrice Chotard > --- > arch/arm/dts/stm32f746-disco.dts| 12 > arch/arm/dts/stm32f746.dtsi | 85 > + > arch/arm/dts/stm32f769-disco.dts| 12 > include/dt-bindings/pinctrl/stm32f746-pinfunc.h | 19 +- > 4 files changed, 127 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Swig now required to build U-Boot?
Hi Tom, On 11 December 2017 at 18:51, Tom Rini wrote: > On Fri, Dec 08, 2017 at 04:16:41PM -0800, Sergey Kubushyn wrote: >> On Fri, 8 Dec 2017, Simon Glass wrote: >> >> >Hi Stephen, >> > >> >On 8 December 2017 at 16:28, Stephen Warren wrote: >> >>Simon, >> >> >> >>Is it expected that the latest u-boot-dm.git master branch now requires >> >>swig? All the non-sandbox builds on my test systems are failing: >> >> >> >> CHK include/config/uboot.release >> >> CHK include/generated/timestamp_autogenerated.h >> >> GEN ./Makefile >> >> UPD include/generated/timestamp_autogenerated.h >> >> CHK include/config.h >> >> CFG u-boot.cfg >> >> SHIPPED scripts/dtc/pylibfdt/libfdt.i >> >> PYMOD scripts/dtc/pylibfdt/_libfdt.so >> >>unable to execute 'swig': No such file or directory >> >>error: command 'swig' failed with exit status 1 >> >>make[4]: *** [scripts/dtc/pylibfdt/_libfdt.so] Error 1 >> >>make[3]: *** [scripts/dtc/pylibfdt] Error 2 >> >>make[2]: *** [scripts/dtc] Error 2 >> >>make[1]: *** [scripts] Error 2 >> >>make[1]: *** Waiting for unfinished jobs >> > >> >Yes, unless we have a very recent libfdt on the system (and even then >> >I'm not sure that it is picked up). We need swig to build pylibfdt >> >which is needed for binman. >> >> Err, would it be long before we need Java/Eclipse/Maven/younameit to just >> build U-Boot? > > There is a fine line to be walked here. On the flip side, do we want to > have to depend on N little external tools to put together a functional > image? We can use binman to avoid some subset of that. That said, > Simon, are we only building binman related stuff when we need binman in > the end? Thanks! Sorry I missed this question but answered it on another thread. Yes we are only building pylibfdt when it is needed. It is controlled by CONFIG_PYLIBFDT which is enabled when binman or dtoc are needed. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 2/2] configs: stm32f746-disco: enable MMC related flags
On 12 December 2017 at 02:15, wrote: > From: Patrice Chotard > > STM32F469-disco embeds an arm_pl180 mmc IP, so > enable CMD_MMC, DM_MMC and ARM_PL180_MMCI flags. > > Also enables all filesystem command related flags : > _ CMD_EXT2 > _ CMD_EXT4 > _ CMD_FAT > _ CMD_FS_GENERIC > _ CMD_GPT > _ CMD_BOOTZ > > Signed-off-by: Patrice Chotard > --- > configs/stm32f746-disco_defconfig | 15 ++- > 1 file changed, 14 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot