September 2018 - U-Boot

[U-Boot] [PATCH 0/9] Support 4GB of memory on 32bit systems
by Philipp Tomsich 19 Jan '19

19 Jan '19

Even on 32bit systems a full 4GB of DRAM may be installed and reported by the DRAM controller. Whether these 4GB are larger available depends on the size/configuration of address decoding windows and architectural features. This increases the fields holding the RAM size to have at least 33bits (i.e. we use a u64) and fixes the fallout from the change: some casts, the usage of min() and a few printf formats have to be adjusted. Philipp Tomsich (9): dm: allow 4GB of DRAM on 32bit systems rockchip: support 4GB DRAM on 32bit systems common: include <inttypes.h> always MIPS: use PRIx64 macros for printing ram size rockchip: rk3368: change type of ram-size field for a min()-calculation ram: stm32mp1: use PRIx64 macros for printing ram size board: keymile: add explicit cast to truncate the 64bit ram size field board: cm_fx6: use PRIx64 macros for printing ram size mpc85xx: add casts for ram size in min() calculation. arch/arm/include/asm/arch-rockchip/sdram_common.h | 2 +- arch/arm/mach-rockchip/sdram_common.c | 8 ++++---- arch/arm/mach-stm32mp/dram_init.c | 2 +- arch/mips/mach-bmips/dram.c | 2 +- arch/powerpc/cpu/mpc85xx/cpu.c | 6 ++++-- board/compulab/cm_fx6/cm_fx6.c | 3 ++- board/keymile/km_arm/km_arm.c | 6 ++++-- drivers/ram/rockchip/dmc-rk3368.c | 2 +- drivers/ram/stm32mp1/stm32mp1_ram.c | 2 +- include/asm-generic/global_data.h | 2 +- include/common.h | 1 + include/ram.h | 9 ++++++++- 12 files changed, 29 insertions(+), 16 deletions(-) -- 2.1.4

14 39

[U-Boot] [PATCH] [RFC] blk: Increase cache element size
by Marek Vasut 16 Jan '19

16 Jan '19

Cache up to 4 kiB entries. 4 kiB is the default block size on ext4, yet the underlying block layer devices usually report support for 512B . In most cases, the 512B support is emulated (ie. SD cards, SSDs, USB sticks etc.) and the real block size of those devices is much bigger. To avoid performance degradation with such devices and FS setup, bump the maximum cache entry size to 4 kiB. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Tom Rini <trini(a)konsulko.com> Cc: Simon Glass <sjg(a)chromium.org> --- drivers/block/blkcache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c index 294511fcdb..1fa64989d3 100644 --- a/drivers/block/blkcache.c +++ b/drivers/block/blkcache.c @@ -24,7 +24,7 @@ struct block_cache_node { static LIST_HEAD(block_cache); static struct block_cache_stats _stats = { - .max_blocks_per_entry = 2, + .max_blocks_per_entry = 8, .max_entries = 32 }; -- 2.16.2

2 9

[U-Boot] BPI-M2 Magic: DRAM:Timeout initialising DRAM
by Jagan Teki 10 Jan '19

10 Jan '19

Hi, Anyone find this dram timeout issue with BPI-M2 Magic Log: U-Boot SPL 2018.05-00294-g855ff8e6dd (May 21 2018 - 22:27:49 +0530) DRAM:Timeout initialising DRAM resetting ... Look like dram fex values seems ok, any inputs? [1] https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/sunxi-pack/allwinne… Jagan. -- Jagan Teki Senior Linux Kernel Engineer | Amarula Solutions U-Boot, Linux | Upstream Maintainer Hyderabad, India.

2 1

Re: [U-Boot] u-boot-rockchip: firefly-rk3288 hangs on: Loading Environment from MMC
by Vagrant Cascadian 27 Dec '18

27 Dec '18

On 2018-05-12, Vagrant Cascadian wrote: > On 2018-05-12, Vagrant Cascadian wrote: >> Booting firefly-rk3288 seems to hang looking for environment: >> >> U-Boot 2018.05+dfsg-1 (May 10 2018 - 20:24:57 +0000) >> >> Model: Firefly-RK3288 >> DRAM: 2 GiB >> MMC: dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0 >> Loading Environment from MMC... >> >> And just hangs there. I tried to bisect this, and got: commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355 Author: Jean-Jacques Hiblot <jjhiblot(a)ti.com> Date: Thu Sep 21 16:30:08 2017 +0200 mmc: disable UHS modes if Vcc cannot be switched on and off But it fails in a slightly different way: U-Boot 2018.01-00026-g04a2ea248f (May 21 2018 - 21:46:18 +0000) Model: Firefly-RK3288 DRAM: 2 GiB MMC: dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0 And just hangs without the "Loading Environment from MMC..." part... It is not a trivial revert on top of 2018.05, so I haven't been able to do that simple test. CONFIG_ENV_IS_IN_MMC has been enabled since at least: 5dc4dfd2a94 (Tom Rini 2017-08-28 07:16:32 -0400 36) CONFIG_ENV_IS_IN_MMC=y live well, vagrant

4 8

[U-Boot] [PATCH] fs: cbfs: remove wrong header validation
by Christian Gmeiner 23 Dec '18

23 Dec '18

Coreboot does not contain such a check: https://github.com/coreboot/coreboot/blob/eeb4e20b2f6d786c92fe3efb30817e903… Before this change cbfsinit failed with 'Bad CBFS file'. After this change all cbfs commands are working as expected. Signed-off-by: Christian Gmeiner <christian.gmeiner(a)gmail.com> --- fs/cbfs/cbfs.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/fs/cbfs/cbfs.c b/fs/cbfs/cbfs.c index 0dce639b49..2a581f0c18 100644 --- a/fs/cbfs/cbfs.c +++ b/fs/cbfs/cbfs.c @@ -96,11 +96,7 @@ static int file_cbfs_next_file(u8 *start, u32 size, u32 align, } swap_file_header(&header, fileHeader); - if (header.offset < sizeof(struct cbfs_fileheader) || - header.offset > header.len) { - file_cbfs_result = CBFS_BAD_FILE; - return -1; - } + newNode->next = NULL; newNode->type = header.type; newNode->data = start + header.offset; -- 2.17.1

3 7

[U-Boot] UBIFS Problems with U-boot 2018.1 & 4.14 Linux
by Otto Blom 20 Dec '18

20 Dec '18

Hi There ! I'm seeing a strange problem with u-boot 2018.1 and Linux 4.14 (Xilinx Petalinux 2018.1). If I write a ubifs image to flash using Linux 4.9 I can mount and read files from the image in both u-boot 2018.1 and Linux 4.14. However as soon as I write a new file to the file-system from Linux, U-boot can no longer read the file. The filesystem still mounts, but when I attempt to read the file I get the following error UBIFS error (ubi0:0 pid 0): read_block: bad data node (block 661, inode 5763) magic 0x6101831 crc 0x8e6aff1a node_type 1 (data node) group_type 0 (no node group) sqnum 63819 len 3075 key (5763, data, 661) size 4096 compr_typ 1 data size 3027 data: UBIFS error (ubi0:0 pid 0): do_readpage: cannot read page 661 of inode 5763, error -22 The file can still be read correctly from Linux, leading me to believe there is some form of incompatibility going on. I noticed that the ubifs version number was bumped from 4 to 5 in this commit http://git.infradead.org/linux-ubifs.git/commit/fc4b891bbefa73b496bb44b076b… Both Linux 4.9 and U-boot 18.1 still have version 4. Could that have something do to with it ? I'm running on a ZynqMP platform with Micron Flash (On-Die ECC) Thanks in advance, /Otto

4 11

[U-Boot] [PATCH][v2] armv8: lsch3: Add support of serdes3 module
by Priyanka Jain 10 Dec '18

10 Dec '18

Some lsch3 based SoCs like lx2160a contains three serdes modules. Add support for third serdes protocol in lsch3 Signed-off-by: Priyanka Jain <priyanka.jain(a)nxp.com> --- Changes for v2: Updated copyright Renamed CONFIG_SYS_FSL_SRDS_3 to CONFIG_SYS_NXP_SRDS_3 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 3 + .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c | 71 ++++++++++++++++++++++ .../include/asm/arch-fsl-layerscape/fsl_serdes.h | 2 + 3 files changed, 76 insertions(+) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig index f2111fa..fd31ae1 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig @@ -348,6 +348,9 @@ config SYS_FSL_SRDS_1 config SYS_FSL_SRDS_2 bool +config SYS_NXP_SRDS_3 + bool + config SYS_HAS_SERDES bool diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c index 2bef841..bfd2868 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c @@ -1,5 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /* + * Copyright 2016-2018 NXP * Copyright 2014-2015 Freescale Semiconductor, Inc. */ @@ -16,6 +17,9 @@ static u8 serdes1_prtcl_map[SERDES_PRCTL_COUNT]; #ifdef CONFIG_SYS_FSL_SRDS_2 static u8 serdes2_prtcl_map[SERDES_PRCTL_COUNT]; #endif +#ifdef CONFIG_SYS_NXP_SRDS_3 +static u8 serdes3_prtcl_map[SERDES_PRCTL_COUNT]; +#endif #if defined(CONFIG_FSL_MC_ENET) && !defined(CONFIG_SPL_BUILD) int xfi_dpmac[XFI8 + 1]; @@ -57,6 +61,12 @@ int is_serdes_configured(enum srds_prtcl device) ret |= serdes2_prtcl_map[device]; #endif +#ifdef CONFIG_SYS_NXP_SRDS_3 + if (!serdes3_prtcl_map[NONE]) + fsl_serdes_init(); + + ret |= serdes3_prtcl_map[device]; +#endif return !!ret; } @@ -82,6 +92,13 @@ int serdes_get_first_lane(u32 sd, enum srds_prtcl device) cfg >>= FSL_CHASSIS3_SRDS2_PRTCL_SHIFT; break; #endif +#ifdef CONFIG_SYS_NXP_SRDS_3 + case NXP_SRDS_3: + cfg = gur_in32(&gur->rcwsr[FSL_CHASSIS3_SRDS3_REGSR - 1]); + cfg &= FSL_CHASSIS3_SRDS3_PRTCL_MASK; + cfg >>= FSL_CHASSIS3_SRDS3_PRTCL_SHIFT; + break; +#endif default: printf("invalid SerDes%d\n", sd); break; @@ -201,6 +218,12 @@ struct serdes_prctl_info srds_prctl_info[] = { .shift = FSL_CHASSIS3_SRDS2_PRTCL_SHIFT }, #endif +#ifdef CONFIG_SYS_NXP_SRDS_3 + {.id = 3, + .mask = FSL_CHASSIS3_SRDS3_PRTCL_MASK, + .shift = FSL_CHASSIS3_SRDS3_PRTCL_SHIFT + }, +#endif {} /* NULL ENTRY */ }; @@ -341,6 +364,11 @@ int setup_serdes_volt(u32 svdd) (void *)(CONFIG_SYS_FSL_LSCH3_SERDES_ADDR + 0x10000); u32 cfg_rcwsrds2 = gur_in32(&gur->rcwsr[FSL_CHASSIS3_SRDS2_REGSR - 1]); #endif +#ifdef CONFIG_SYS_NXP_SRDS_3 + struct ccsr_serdes __iomem *serdes3_base = + (void *)(CONFIG_SYS_FSL_LSCH3_SERDES_ADDR + 0x20000); + u32 cfg_rcwsrds3 = gur_in32(&gur->rcwsr[FSL_CHASSIS3_SRDS3_REGSR - 1]); +#endif u32 cfg_tmp; int svdd_cur, svdd_tar; int ret = 1; @@ -370,6 +398,9 @@ int setup_serdes_volt(u32 svdd) #ifdef CONFIG_SYS_FSL_SRDS_2 do_enabled_lanes_reset(2, cfg_rcwsrds2, serdes2_base, false); #endif +#ifdef CONFIG_SYS_NXP_SRDS_3 + do_enabled_lanes_reset(3, cfg_rcwsrds3, serdes3_base, false); +#endif /* Put the all enabled PLL in reset */ #ifdef CONFIG_SYS_FSL_SRDS_1 @@ -383,6 +414,12 @@ int setup_serdes_volt(u32 svdd) do_pll_reset(cfg_tmp, serdes2_base); #endif +#ifdef CONFIG_SYS_NXP_SRDS_3 + cfg_tmp = cfg_rcwsrds3 & 0x30; + cfg_tmp >>= 4; + do_pll_reset(cfg_tmp, serdes3_base); +#endif + /* Put the Rx/Tx calibration into reset */ #ifdef CONFIG_SYS_FSL_SRDS_1 do_rx_tx_cal_reset(serdes1_base); @@ -392,6 +429,10 @@ int setup_serdes_volt(u32 svdd) do_rx_tx_cal_reset(serdes2_base); #endif +#ifdef CONFIG_SYS_NXP_SRDS_3 + do_rx_tx_cal_reset(serdes3_base); +#endif + ret = set_serdes_volt(svdd); if (ret < 0) { printf("could not change SVDD\n"); @@ -408,6 +449,11 @@ int setup_serdes_volt(u32 svdd) cfg_tmp >>= 2; do_serdes_enable(cfg_tmp, serdes2_base); #endif +#ifdef CONFIG_SYS_NXP_SRDS_3 + cfg_tmp = cfg_rcwsrds3 & 0x30; + cfg_tmp >>= 4; + do_serdes_enable(cfg_tmp, serdes3_base); +#endif /* Wait for at at least 625us, ensure the PLLs being reset are locked */ udelay(800); @@ -422,6 +468,13 @@ int setup_serdes_volt(u32 svdd) cfg_tmp >>= 2; do_pll_lock(cfg_tmp, serdes2_base); #endif + +#ifdef CONFIG_SYS_NXP_SRDS_3 + cfg_tmp = cfg_rcwsrds3 & 0x30; + cfg_tmp >>= 4; + do_pll_lock(cfg_tmp, serdes3_base); +#endif + /* Take the all enabled lanes out of reset */ #ifdef CONFIG_SYS_FSL_SRDS_1 do_enabled_lanes_reset(1, cfg_rcwsrds1, serdes1_base, true); @@ -430,6 +483,10 @@ int setup_serdes_volt(u32 svdd) do_enabled_lanes_reset(2, cfg_rcwsrds2, serdes2_base, true); #endif +#ifdef CONFIG_SYS_NXP_SRDS_3 + do_enabled_lanes_reset(3, cfg_rcwsrds3, serdes3_base, true); +#endif + /* For each PLL being reset, and achieved PLL lock set RST_DONE */ #ifdef CONFIG_SYS_FSL_SRDS_1 cfg_tmp = cfg_rcwsrds1 & 0x3; @@ -441,6 +498,12 @@ int setup_serdes_volt(u32 svdd) do_pll_reset_done(cfg_tmp, serdes2_base); #endif +#ifdef CONFIG_SYS_NXP_SRDS_3 + cfg_tmp = cfg_rcwsrds3 & 0x30; + cfg_tmp >>= 4; + do_pll_reset_done(cfg_tmp, serdes3_base); +#endif + return ret; } @@ -472,4 +535,12 @@ void fsl_serdes_init(void) FSL_CHASSIS3_SRDS2_PRTCL_SHIFT, serdes2_prtcl_map); #endif +#ifdef CONFIG_SYS_NXP_SRDS_3 + serdes_init(NXP_SRDS_3, + CONFIG_SYS_FSL_LSCH3_SERDES_ADDR + NXP_SRDS_3 * 0x10000, + FSL_CHASSIS3_SRDS3_REGSR, + FSL_CHASSIS3_SRDS3_PRTCL_MASK, + FSL_CHASSIS3_SRDS3_PRTCL_SHIFT, + serdes3_prtcl_map); +#endif } diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h index 6981076..bec35e8 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h @@ -1,5 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* + * Copyright 2018 NXP * Copyright 2015 Freescale Semiconductor, Inc. */ @@ -57,6 +58,7 @@ enum srds_prtcl { enum srds { FSL_SRDS_1 = 0, FSL_SRDS_2 = 1, + NXP_SRDS_3 = 2, }; #elif defined(CONFIG_FSL_LSCH2) enum srds_prtcl { -- 2.7.4

2 1

[U-Boot] [PATCH v2] efi_loader: Align runtime section to 64kb
by Alexander Graf 09 Dec '18

09 Dec '18

The UEFI spec mandates that runtime sections are 64kb aligned to enable support for 64kb page size OSs. This patch ensures that we extend the runtime section to 64kb to be spec compliant. Signed-off-by: Alexander Graf <agraf(a)suse.de> --- v1 -> v2: - rename kb to KiB in accordance to the spec - add reference to spec section for alignment requirement - only use 64KiB alignment on aarch64 --- lib/efi_loader/efi_memory.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c index 5bd4f4d7fc..b4cb543275 100644 --- a/lib/efi_loader/efi_memory.c +++ b/lib/efi_loader/efi_memory.c @@ -11,6 +11,7 @@ #include <mapmem.h> #include <watchdog.h> #include <linux/list_sort.h> +#include <linux/sizes.h> DECLARE_GLOBAL_DATA_PTR; @@ -563,6 +564,7 @@ __weak void efi_add_known_memory(void) static void add_u_boot_and_runtime(void) { unsigned long runtime_start, runtime_end, runtime_pages; + unsigned long runtime_mask = EFI_PAGE_MASK; unsigned long uboot_start, uboot_pages; unsigned long uboot_stack_size = 16 * 1024 * 1024; @@ -571,10 +573,22 @@ static void add_u_boot_and_runtime(void) uboot_pages = (gd->ram_top - uboot_start) >> EFI_PAGE_SHIFT; efi_add_memory_map(uboot_start, uboot_pages, EFI_LOADER_DATA, false); - /* Add Runtime Services */ - runtime_start = (ulong)&__efi_runtime_start & ~EFI_PAGE_MASK; +#if defined(__aarch64__) + /* + * Runtime Services must be 64KiB aligned according to the + * "AArch64 Platforms" section in the UEFI spec (2.7+). + */ + + runtime_mask = SZ_64K - 1; +#endif + + /* + * Add Runtime Services. We mark surrounding boottime code as runtime as + * well to fulfill the runtime alignment constraints but avoid padding. + */ + runtime_start = (ulong)&__efi_runtime_start & ~runtime_mask; runtime_end = (ulong)&__efi_runtime_stop; - runtime_end = (runtime_end + EFI_PAGE_MASK) & ~EFI_PAGE_MASK; + runtime_end = (runtime_end + runtime_mask) & ~runtime_mask; runtime_pages = (runtime_end - runtime_start) >> EFI_PAGE_SHIFT; efi_add_memory_map(runtime_start, runtime_pages, EFI_RUNTIME_SERVICES_CODE, false); -- 2.12.3

2 5

[U-Boot] [PATCH] warp7: configs: add CONFIG_FIT option
by Pierre-Jean Texier 08 Dec '18

08 Dec '18

This enable FIT image support. Signed-off-by: Pierre-Jean Texier <pjtexier(a)koncepto.io> --- configs/warp7_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index 15a6673..919d484 100644 --- a/configs/warp7_defconfig +++ b/configs/warp7_defconfig @@ -8,6 +8,8 @@ CONFIG_ARMV7_BOOT_SEC_DEFAULT=y CONFIG_IMX_RDC=y CONFIG_IMX_BOOTAUX=y CONFIG_NR_DRAM_BANKS=1 +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/warp7/imximage.cfg" CONFIG_HUSH_PARSER=y # CONFIG_CMD_BOOTD is not set -- 2.7.4

2 1

[U-Boot] [PATCH v3 0/4] Add Rock960 and Ficus 96Board support
by Manivannan Sadhasivam 06 Dec '18

06 Dec '18

This patchset adds support for Rock960 and Ficus 96Boards from Vamrs. Since both boards share most of the configurations, a common Rock960 family support is added with common support and the actual boards are based on this. The previous version of the patchseries were adding Rock960 [1] and Ficus [2] board support individually, but this series fuses them together based on the common board support as per Linux kernel. [1] https://patchwork.ozlabs.org/cover/963239/ [2] https://lists.denx.de/pipermail/u-boot/2018-August/339059.html This patchseries has been tested on Rock960 v1.2 board and expecting Ezequiel to do the testing for Ficus. PS: I have explicitly removed the previous Ack's for the Ficus board since there has been a heavy modification done on these patches. Thanks, Mani Manivannan Sadhasivam (4): arm: dts: rockchip: add some common pin-settings to rk3399 rockchip: rk3399: Add common Rock960 family from Vamrs rockchip: rk3399: Add Rock960 CE board support rockchip: rk3399: Add Ficus EE board support arch/arm/dts/Makefile | 2 + arch/arm/dts/rk3399-ficus.dts | 78 + arch/arm/dts/rk3399-rock960.dts | 45 + arch/arm/dts/rk3399-rock960.dtsi | 506 ++++++ .../arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi | 1536 +++++++++++++++++ arch/arm/dts/rk3399.dtsi | 55 +- arch/arm/mach-rockchip/rk3399/Kconfig | 26 + board/vamrs/rock960_rk3399/Kconfig | 15 + board/vamrs/rock960_rk3399/MAINTAINERS | 6 + board/vamrs/rock960_rk3399/Makefile | 6 + board/vamrs/rock960_rk3399/README | 152 ++ board/vamrs/rock960_rk3399/rock960-rk3399.c | 50 + configs/ficus-rk3399_defconfig | 71 + configs/rock960-rk3399_defconfig | 69 + include/configs/rock960_rk3399.h | 15 + 15 files changed, 2626 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/rk3399-ficus.dts create mode 100644 arch/arm/dts/rk3399-rock960.dts create mode 100644 arch/arm/dts/rk3399-rock960.dtsi create mode 100644 arch/arm/dts/rk3399-sdram-lpddr3-2GB-1600.dtsi create mode 100644 board/vamrs/rock960_rk3399/Kconfig create mode 100644 board/vamrs/rock960_rk3399/MAINTAINERS create mode 100644 board/vamrs/rock960_rk3399/Makefile create mode 100644 board/vamrs/rock960_rk3399/README create mode 100644 board/vamrs/rock960_rk3399/rock960-rk3399.c create mode 100644 configs/ficus-rk3399_defconfig create mode 100644 configs/rock960-rk3399_defconfig create mode 100644 include/configs/rock960_rk3399.h -- 2.17.1

8 36