Re: [U-Boot] [PATCH] board: move all the rockchip board in one folder
On 2016年07月08日 11:30, Kever Yang wrote: The 'evb_rk3036' and 'kylin' is not a vendor name, let's replace them to 'rockchip' which is a real _vendor_ name, and meet the architecure 'board///'. More boards from rockchip like evb_rk3288, evb_rk3399 will comes later. Signed-off-by: Kever Yang--- arch/arm/mach-rockchip/rk3036/Kconfig | 4 +- board/evb_rk3036/evb_rk3036/Kconfig| 15 -- board/evb_rk3036/evb_rk3036/MAINTAINERS| 0 board/evb_rk3036/evb_rk3036/Makefile | 7 --- board/evb_rk3036/evb_rk3036/evb_rk3036.c | 49 -- board/kylin/kylin_rk3036/Kconfig | 15 -- board/kylin/kylin_rk3036/MAINTAINERS | 0 board/kylin/kylin_rk3036/Makefile | 7 --- board/kylin/kylin_rk3036/kylin_rk3036.c| 81 -- board/rockchip/evb_rk3036/Kconfig | 15 ++ board/rockchip/evb_rk3036/MAINTAINERS | 0 board/rockchip/evb_rk3036/Makefile | 7 +++ board/rockchip/evb_rk3036/evb_rk3036.c | 49 ++ board/rockchip/kylin_rk3036/Kconfig| 15 ++ board/rockchip/kylin_rk3036/MAINTAINERS| 0 board/rockchip/kylin_rk3036/Makefile | 7 +++ board/rockchip/kylin_rk3036/kylin_rk3036.c | 81 ++ 17 files changed, 176 insertions(+), 176 deletions(-) delete mode 100644 board/evb_rk3036/evb_rk3036/Kconfig delete mode 100644 board/evb_rk3036/evb_rk3036/MAINTAINERS delete mode 100644 board/evb_rk3036/evb_rk3036/Makefile delete mode 100644 board/evb_rk3036/evb_rk3036/evb_rk3036.c delete mode 100644 board/kylin/kylin_rk3036/Kconfig delete mode 100644 board/kylin/kylin_rk3036/MAINTAINERS delete mode 100644 board/kylin/kylin_rk3036/Makefile delete mode 100644 board/kylin/kylin_rk3036/kylin_rk3036.c create mode 100644 board/rockchip/evb_rk3036/Kconfig create mode 100644 board/rockchip/evb_rk3036/MAINTAINERS create mode 100644 board/rockchip/evb_rk3036/Makefile create mode 100644 board/rockchip/evb_rk3036/evb_rk3036.c create mode 100644 board/rockchip/kylin_rk3036/Kconfig create mode 100644 board/rockchip/kylin_rk3036/MAINTAINERS create mode 100644 board/rockchip/kylin_rk3036/Makefile create mode 100644 board/rockchip/kylin_rk3036/kylin_rk3036.c diff --git a/arch/arm/mach-rockchip/rk3036/Kconfig b/arch/arm/mach-rockchip/rk3036/Kconfig index cc03808..f7562bd 100644 --- a/arch/arm/mach-rockchip/rk3036/Kconfig +++ b/arch/arm/mach-rockchip/rk3036/Kconfig @@ -15,7 +15,7 @@ config SYS_MALLOC_F_LEN config ROCKCHIP_COMMON bool "Support rk common fuction" -source "board/evb_rk3036/evb_rk3036/Kconfig" -source "board/kylin/kylin_rk3036/Kconfig" +source "board/rockchip/evb_rk3036/Kconfig" +source "board/rockchip/kylin_rk3036/Kconfig" endif diff --git a/board/evb_rk3036/evb_rk3036/Kconfig b/board/evb_rk3036/evb_rk3036/Kconfig deleted file mode 100644 index ae2a9eb..000 --- a/board/evb_rk3036/evb_rk3036/Kconfig +++ /dev/null @@ -1,15 +0,0 @@ -if TARGET_EVB_RK3036 - -config SYS_BOARD - default "evb_rk3036" - -config SYS_VENDOR - default "evb_rk3036" - -config SYS_CONFIG_NAME - default "evb_rk3036" - -config BOARD_SPECIFIC_OPTIONS # dummy - def_bool y - -endif diff --git a/board/evb_rk3036/evb_rk3036/MAINTAINERS b/board/evb_rk3036/evb_rk3036/MAINTAINERS deleted file mode 100644 index e69de29..000 diff --git a/board/evb_rk3036/evb_rk3036/Makefile b/board/evb_rk3036/evb_rk3036/Makefile deleted file mode 100644 index 0403836..000 --- a/board/evb_rk3036/evb_rk3036/Makefile +++ /dev/null @@ -1,7 +0,0 @@ -# -# (C) Copyright 2015 Google, Inc -# -# SPDX-License-Identifier: GPL-2.0+ -# - -obj-y += evb_rk3036.o diff --git a/board/evb_rk3036/evb_rk3036/evb_rk3036.c b/board/evb_rk3036/evb_rk3036/evb_rk3036.c deleted file mode 100644 index f5758b1..000 --- a/board/evb_rk3036/evb_rk3036/evb_rk3036.c +++ /dev/null @@ -1,49 +0,0 @@ -/* - * (C) Copyright 2015 Rockchip Electronics Co., Ltd - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -#include -#include -#include -#include -#include - -DECLARE_GLOBAL_DATA_PTR; - -void get_ddr_config(struct rk3036_ddr_config *config) -{ - /* K4B4G1646Q config */ - config->ddr_type = 3; - config->rank = 2; - config->cs0_row = 15; - config->cs1_row = 15; - - /* 8bank */ - config->bank = 3; - config->col = 10; - - /* 16bit bw */ - config->bw = 1; -} - -int board_init(void) -{ - return 0; -} - -int dram_init(void) -{ - gd->ram_size = sdram_size(); - - return 0; -} - -#ifndef CONFIG_SYS_DCACHE_OFF -void enable_caches(void) -{ - /* Enable D-cache. I-cache is already enabled in start.S */ - dcache_enable(); -} -#endif diff --git a/board/kylin/kylin_rk3036/Kconfig b/board/kylin/kylin_rk3036/Kconfig deleted file mode 100644 index 5d75c1f..000 --- a/board/kylin/kylin_rk3036/Kconfig +++ /dev/null @@ -1,15 +0,0
Re: [U-Boot] [PATCH] board: move all the rockchip board in one folder
2016-07-08 11:30 GMT+08:00 Kever Yang: > The 'evb_rk3036' and 'kylin' is not a vendor name, let's replace them > to 'rockchip' which is a real _vendor_ name, and meet the architecure > 'board///'. > > More boards from rockchip like evb_rk3288, evb_rk3399 will comes later. > > Signed-off-by: Kever Yang Reviewed-by: Eddie Cai > --- > arch/arm/mach-rockchip/rk3036/Kconfig | 4 +- > board/evb_rk3036/evb_rk3036/Kconfig| 15 -- > board/evb_rk3036/evb_rk3036/MAINTAINERS| 0 > board/evb_rk3036/evb_rk3036/Makefile | 7 --- > board/evb_rk3036/evb_rk3036/evb_rk3036.c | 49 -- > board/kylin/kylin_rk3036/Kconfig | 15 -- > board/kylin/kylin_rk3036/MAINTAINERS | 0 > board/kylin/kylin_rk3036/Makefile | 7 --- > board/kylin/kylin_rk3036/kylin_rk3036.c| 81 > -- > board/rockchip/evb_rk3036/Kconfig | 15 ++ > board/rockchip/evb_rk3036/MAINTAINERS | 0 > board/rockchip/evb_rk3036/Makefile | 7 +++ > board/rockchip/evb_rk3036/evb_rk3036.c | 49 ++ > board/rockchip/kylin_rk3036/Kconfig| 15 ++ > board/rockchip/kylin_rk3036/MAINTAINERS| 0 > board/rockchip/kylin_rk3036/Makefile | 7 +++ > board/rockchip/kylin_rk3036/kylin_rk3036.c | 81 > ++ > 17 files changed, 176 insertions(+), 176 deletions(-) > delete mode 100644 board/evb_rk3036/evb_rk3036/Kconfig > delete mode 100644 board/evb_rk3036/evb_rk3036/MAINTAINERS > delete mode 100644 board/evb_rk3036/evb_rk3036/Makefile > delete mode 100644 board/evb_rk3036/evb_rk3036/evb_rk3036.c > delete mode 100644 board/kylin/kylin_rk3036/Kconfig > delete mode 100644 board/kylin/kylin_rk3036/MAINTAINERS > delete mode 100644 board/kylin/kylin_rk3036/Makefile > delete mode 100644 board/kylin/kylin_rk3036/kylin_rk3036.c > create mode 100644 board/rockchip/evb_rk3036/Kconfig > create mode 100644 board/rockchip/evb_rk3036/MAINTAINERS > create mode 100644 board/rockchip/evb_rk3036/Makefile > create mode 100644 board/rockchip/evb_rk3036/evb_rk3036.c > create mode 100644 board/rockchip/kylin_rk3036/Kconfig > create mode 100644 board/rockchip/kylin_rk3036/MAINTAINERS > create mode 100644 board/rockchip/kylin_rk3036/Makefile > create mode 100644 board/rockchip/kylin_rk3036/kylin_rk3036.c > > diff --git a/arch/arm/mach-rockchip/rk3036/Kconfig > b/arch/arm/mach-rockchip/rk3036/Kconfig > index cc03808..f7562bd 100644 > --- a/arch/arm/mach-rockchip/rk3036/Kconfig > +++ b/arch/arm/mach-rockchip/rk3036/Kconfig > @@ -15,7 +15,7 @@ config SYS_MALLOC_F_LEN > config ROCKCHIP_COMMON > bool "Support rk common fuction" > > -source "board/evb_rk3036/evb_rk3036/Kconfig" > -source "board/kylin/kylin_rk3036/Kconfig" > +source "board/rockchip/evb_rk3036/Kconfig" > +source "board/rockchip/kylin_rk3036/Kconfig" > > endif > diff --git a/board/evb_rk3036/evb_rk3036/Kconfig > b/board/evb_rk3036/evb_rk3036/Kconfig > deleted file mode 100644 > index ae2a9eb..000 > --- a/board/evb_rk3036/evb_rk3036/Kconfig > +++ /dev/null > @@ -1,15 +0,0 @@ > -if TARGET_EVB_RK3036 > - > -config SYS_BOARD > - default "evb_rk3036" > - > -config SYS_VENDOR > - default "evb_rk3036" > - > -config SYS_CONFIG_NAME > - default "evb_rk3036" > - > -config BOARD_SPECIFIC_OPTIONS # dummy > - def_bool y > - > -endif > diff --git a/board/evb_rk3036/evb_rk3036/MAINTAINERS > b/board/evb_rk3036/evb_rk3036/MAINTAINERS > deleted file mode 100644 > index e69de29..000 > diff --git a/board/evb_rk3036/evb_rk3036/Makefile > b/board/evb_rk3036/evb_rk3036/Makefile > deleted file mode 100644 > index 0403836..000 > --- a/board/evb_rk3036/evb_rk3036/Makefile > +++ /dev/null > @@ -1,7 +0,0 @@ > -# > -# (C) Copyright 2015 Google, Inc > -# > -# SPDX-License-Identifier: GPL-2.0+ > -# > - > -obj-y += evb_rk3036.o > diff --git a/board/evb_rk3036/evb_rk3036/evb_rk3036.c > b/board/evb_rk3036/evb_rk3036/evb_rk3036.c > deleted file mode 100644 > index f5758b1..000 > --- a/board/evb_rk3036/evb_rk3036/evb_rk3036.c > +++ /dev/null > @@ -1,49 +0,0 @@ > -/* > - * (C) Copyright 2015 Rockchip Electronics Co., Ltd > - * > - * SPDX-License-Identifier: GPL-2.0+ > - */ > - > -#include > -#include > -#include > -#include > -#include > - > -DECLARE_GLOBAL_DATA_PTR; > - > -void get_ddr_config(struct rk3036_ddr_config *config) > -{ > - /* K4B4G1646Q config */ > - config->ddr_type = 3; > - config->rank = 2; > - config->cs0_row = 15; > - config->cs1_row = 15; > - > - /* 8bank */ > - config->bank = 3; > - config->col = 10; > - > - /* 16bit bw */ > - config->bw = 1; > -} > - > -int board_init(void) > -{ > - return 0; > -} > - > -int dram_init(void) > -{ > - gd->ram_size = sdram_size(); > - > - return 0; > -} > - > -#ifndef CONFIG_SYS_DCACHE_OFF
Re: [U-Boot] [PATCH] pwm: add MACRO to limit some code which only for rk3288
On 2016年07月08日 10:45, Kever Yang wrote: The grf setting for rkpwm is only need in rk3288, other SoCs like RK3399 which also use rkpwm do not need set the grf, let's add a MACRO to make the code only for RK3288. Change-Id: I167a4e8cf925e840d4bbbcfb1437aaed52b81477 Superfluous Change-Id. Signed-off-by: Kever Yang--- drivers/pwm/rk_pwm.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c index 2d289a4..e34adf0 100644 --- a/drivers/pwm/rk_pwm.c +++ b/drivers/pwm/rk_pwm.c @@ -13,8 +13,10 @@ #include #include #include +#ifdef CONFIG_ROCKCHIP_RK3288 #include #include +#endif #include #include @@ -22,7 +24,9 @@ DECLARE_GLOBAL_DATA_PTR; struct rk_pwm_priv { struct rk3288_pwm *regs; +#ifdef CONFIG_ROCKCHIP_RK3288 struct rk3288_grf *grf; +#endif }; static int rk_pwm_set_config(struct udevice *dev, uint channel, uint period_ns, @@ -65,19 +69,23 @@ static int rk_pwm_ofdata_to_platdata(struct udevice *dev) struct regmap *map; priv->regs = (struct rk3288_pwm *)dev_get_addr(dev); +#ifdef CONFIG_ROCKCHIP_RK3288 map = syscon_get_regmap_by_driver_data(ROCKCHIP_SYSCON_GRF); if (IS_ERR(map)) return PTR_ERR(map); priv->grf = regmap_get_range(map, 0); +#endif return 0; } static int rk_pwm_probe(struct udevice *dev) { +#ifdef CONFIG_ROCKCHIP_RK3288 struct rk_pwm_priv *priv = dev_get_priv(dev); rk_setreg(>grf->soc_con2, 1 << 0); +#endif return 0; } ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board: move all the rockchip board in one folder
The 'evb_rk3036' and 'kylin' is not a vendor name, let's replace them to 'rockchip' which is a real _vendor_ name, and meet the architecure 'board///'. More boards from rockchip like evb_rk3288, evb_rk3399 will comes later. Signed-off-by: Kever Yang--- arch/arm/mach-rockchip/rk3036/Kconfig | 4 +- board/evb_rk3036/evb_rk3036/Kconfig| 15 -- board/evb_rk3036/evb_rk3036/MAINTAINERS| 0 board/evb_rk3036/evb_rk3036/Makefile | 7 --- board/evb_rk3036/evb_rk3036/evb_rk3036.c | 49 -- board/kylin/kylin_rk3036/Kconfig | 15 -- board/kylin/kylin_rk3036/MAINTAINERS | 0 board/kylin/kylin_rk3036/Makefile | 7 --- board/kylin/kylin_rk3036/kylin_rk3036.c| 81 -- board/rockchip/evb_rk3036/Kconfig | 15 ++ board/rockchip/evb_rk3036/MAINTAINERS | 0 board/rockchip/evb_rk3036/Makefile | 7 +++ board/rockchip/evb_rk3036/evb_rk3036.c | 49 ++ board/rockchip/kylin_rk3036/Kconfig| 15 ++ board/rockchip/kylin_rk3036/MAINTAINERS| 0 board/rockchip/kylin_rk3036/Makefile | 7 +++ board/rockchip/kylin_rk3036/kylin_rk3036.c | 81 ++ 17 files changed, 176 insertions(+), 176 deletions(-) delete mode 100644 board/evb_rk3036/evb_rk3036/Kconfig delete mode 100644 board/evb_rk3036/evb_rk3036/MAINTAINERS delete mode 100644 board/evb_rk3036/evb_rk3036/Makefile delete mode 100644 board/evb_rk3036/evb_rk3036/evb_rk3036.c delete mode 100644 board/kylin/kylin_rk3036/Kconfig delete mode 100644 board/kylin/kylin_rk3036/MAINTAINERS delete mode 100644 board/kylin/kylin_rk3036/Makefile delete mode 100644 board/kylin/kylin_rk3036/kylin_rk3036.c create mode 100644 board/rockchip/evb_rk3036/Kconfig create mode 100644 board/rockchip/evb_rk3036/MAINTAINERS create mode 100644 board/rockchip/evb_rk3036/Makefile create mode 100644 board/rockchip/evb_rk3036/evb_rk3036.c create mode 100644 board/rockchip/kylin_rk3036/Kconfig create mode 100644 board/rockchip/kylin_rk3036/MAINTAINERS create mode 100644 board/rockchip/kylin_rk3036/Makefile create mode 100644 board/rockchip/kylin_rk3036/kylin_rk3036.c diff --git a/arch/arm/mach-rockchip/rk3036/Kconfig b/arch/arm/mach-rockchip/rk3036/Kconfig index cc03808..f7562bd 100644 --- a/arch/arm/mach-rockchip/rk3036/Kconfig +++ b/arch/arm/mach-rockchip/rk3036/Kconfig @@ -15,7 +15,7 @@ config SYS_MALLOC_F_LEN config ROCKCHIP_COMMON bool "Support rk common fuction" -source "board/evb_rk3036/evb_rk3036/Kconfig" -source "board/kylin/kylin_rk3036/Kconfig" +source "board/rockchip/evb_rk3036/Kconfig" +source "board/rockchip/kylin_rk3036/Kconfig" endif diff --git a/board/evb_rk3036/evb_rk3036/Kconfig b/board/evb_rk3036/evb_rk3036/Kconfig deleted file mode 100644 index ae2a9eb..000 --- a/board/evb_rk3036/evb_rk3036/Kconfig +++ /dev/null @@ -1,15 +0,0 @@ -if TARGET_EVB_RK3036 - -config SYS_BOARD - default "evb_rk3036" - -config SYS_VENDOR - default "evb_rk3036" - -config SYS_CONFIG_NAME - default "evb_rk3036" - -config BOARD_SPECIFIC_OPTIONS # dummy - def_bool y - -endif diff --git a/board/evb_rk3036/evb_rk3036/MAINTAINERS b/board/evb_rk3036/evb_rk3036/MAINTAINERS deleted file mode 100644 index e69de29..000 diff --git a/board/evb_rk3036/evb_rk3036/Makefile b/board/evb_rk3036/evb_rk3036/Makefile deleted file mode 100644 index 0403836..000 --- a/board/evb_rk3036/evb_rk3036/Makefile +++ /dev/null @@ -1,7 +0,0 @@ -# -# (C) Copyright 2015 Google, Inc -# -# SPDX-License-Identifier: GPL-2.0+ -# - -obj-y += evb_rk3036.o diff --git a/board/evb_rk3036/evb_rk3036/evb_rk3036.c b/board/evb_rk3036/evb_rk3036/evb_rk3036.c deleted file mode 100644 index f5758b1..000 --- a/board/evb_rk3036/evb_rk3036/evb_rk3036.c +++ /dev/null @@ -1,49 +0,0 @@ -/* - * (C) Copyright 2015 Rockchip Electronics Co., Ltd - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -#include -#include -#include -#include -#include - -DECLARE_GLOBAL_DATA_PTR; - -void get_ddr_config(struct rk3036_ddr_config *config) -{ - /* K4B4G1646Q config */ - config->ddr_type = 3; - config->rank = 2; - config->cs0_row = 15; - config->cs1_row = 15; - - /* 8bank */ - config->bank = 3; - config->col = 10; - - /* 16bit bw */ - config->bw = 1; -} - -int board_init(void) -{ - return 0; -} - -int dram_init(void) -{ - gd->ram_size = sdram_size(); - - return 0; -} - -#ifndef CONFIG_SYS_DCACHE_OFF -void enable_caches(void) -{ - /* Enable D-cache. I-cache is already enabled in start.S */ - dcache_enable(); -} -#endif diff --git a/board/kylin/kylin_rk3036/Kconfig b/board/kylin/kylin_rk3036/Kconfig deleted file mode 100644 index 5d75c1f..000 --- a/board/kylin/kylin_rk3036/Kconfig +++ /dev/null @@ -1,15 +0,0 @@ -if TARGET_KYLIN_RK3036 - -config SYS_BOARD - default "kylin_rk3036" -
Re: [U-Boot] [RESEND PATCH] rockchip: add basic support for evb-rk3288 board
Hi Simon, Pls hold this patch for a moment, I have a patch to clean the board files which vendor is rockchip, I will send it later today. Thanks, - Kever On 07/05/2016 06:06 PM, Ziyuan Xu wrote: evb-3288 board RK3288-based development board with 2 USB ports, HDMI, VGA, micro-SD card, audio, WiFi and Gigabit Ethernet. It also includes on-board 8G eMMC and 2GB of SDRAM. Expansion connector provide access to display pins, I2C, SPI, UART and GPIOs. This add some basic files required to allow the board to output serial messaged and can run command(mmc info etc). evb-rk3288 also supports booting from eMMC or SD card, the default is eMMC. Signed-off-by: Ziyuan Xu--- arch/arm/dts/Makefile | 1 + arch/arm/dts/rk3288-evb.dts | 59 + arch/arm/dts/rk3288-evb.dtsi | 379 ++ arch/arm/mach-rockchip/rk3288-board-spl.c | 4 +- arch/arm/mach-rockchip/rk3288/Kconfig | 10 + board/evb-rk3288/evb-rk3288/Kconfig | 15 ++ board/evb-rk3288/evb-rk3288/MAINTAINERS | 6 + board/evb-rk3288/evb-rk3288/Makefile | 7 + board/evb-rk3288/evb-rk3288/evb-rk3288.c | 15 ++ configs/evb-rk3288_defconfig | 67 ++ doc/README.rockchip | 3 +- include/configs/evb-rk3288.h | 26 ++ 12 files changed, 590 insertions(+), 2 deletions(-) create mode 100644 arch/arm/dts/rk3288-evb.dts create mode 100644 arch/arm/dts/rk3288-evb.dtsi create mode 100644 board/evb-rk3288/evb-rk3288/Kconfig create mode 100644 board/evb-rk3288/evb-rk3288/MAINTAINERS create mode 100644 board/evb-rk3288/evb-rk3288/Makefile create mode 100644 board/evb-rk3288/evb-rk3288/evb-rk3288.c create mode 100644 configs/evb-rk3288_defconfig create mode 100644 include/configs/evb-rk3288.h diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 5d463ce..493b9da 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -31,6 +31,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \ rk3288-firefly.dtb \ rk3288-jerry.dtb \ rk3288-rock2-square.dtb \ + rk3288-evb.dtb \ rk3036-sdk.dtb dtb-$(CONFIG_ARCH_MESON) += \ meson-gxbb-odroidc2.dtb diff --git a/arch/arm/dts/rk3288-evb.dts b/arch/arm/dts/rk3288-evb.dts new file mode 100644 index 000..caf24ee --- /dev/null +++ b/arch/arm/dts/rk3288-evb.dts @@ -0,0 +1,59 @@ +/* + * (C) Copyright 2016 Rockchip Electronics Co., Ltd + * + * SPDX-License-Identifier: GPL-2.0+ X11 + */ + +/dts-v1/; +#include "rk3288-evb.dtsi" + +/ { + model = "Evb-RK3288"; + compatible = "evb-rk3288,evb-rk3288", "rockchip,rk3288"; + + chosen { + stdout-path = + }; +}; + + { + rockchip,num-channels = <2>; + rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d + 0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6 + 0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0 + 0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4 + 0x8 0x1f4>; + rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076 + 0x0 0xc3 0x6 0x2>; + rockchip,sdram-channel = /bits/ 8 <0x2 0xa 0x3 0x2 0x2 0x0 0xe 0xe>; + rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>; +}; + + { + u-boot,dm-pre-reloc; +}; + + { + status = "okay"; +}; + + { + u-boot,dm-pre-reloc; + reg-shift = <2>; +}; + + { + u-boot,dm-pre-reloc; +}; + + { + u-boot,dm-pre-reloc; +}; + + { + u-boot,dm-pre-reloc; +}; + + { + u-boot,dm-pre-reloc; +}; diff --git a/arch/arm/dts/rk3288-evb.dtsi b/arch/arm/dts/rk3288-evb.dtsi new file mode 100644 index 000..cb7d03e --- /dev/null +++ b/arch/arm/dts/rk3288-evb.dtsi @@ -0,0 +1,379 @@ +/* + * (C) Copyright 2016 Rockchip Electronics Co., Ltd + * + * SPDX-License-Identifier: GPL-2.0+ X11 + */ + +#include "rk3288.dtsi" + +/ { + memory { + reg = <0 0x8000>; + }; + + keys: gpio-keys { + compatible = "gpio-keys"; + #address-cells = <1>; + #size-cells = <0>; + + button@0 { + gpio-key,wakeup = <1>; + gpios = < 5 GPIO_ACTIVE_LOW>; + label = "GPIO Power"; + linux,code = <116>; + pinctrl-names = "default"; + pinctrl-0 = <_key>; + }; + }; + + vcc_sys: vsys-regulator { + compatible = "regulator-fixed"; + regulator-name = "vcc_sys"; + regulator-min-microvolt = <500>; + regulator-max-microvolt = <500>; + regulator-always-on; + regulator-boot-on; + }; + + vcc_flash: flash-regulator { + compatible = "regulator-fixed"; + regulator-name = "vcc_flash"; + regulator-min-microvolt = <180>; +
[U-Boot] [PATCH] pwm: add MACRO to limit some code which only for rk3288
The grf setting for rkpwm is only need in rk3288, other SoCs like RK3399 which also use rkpwm do not need set the grf, let's add a MACRO to make the code only for RK3288. Change-Id: I167a4e8cf925e840d4bbbcfb1437aaed52b81477 Signed-off-by: Kever Yang--- drivers/pwm/rk_pwm.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c index 2d289a4..e34adf0 100644 --- a/drivers/pwm/rk_pwm.c +++ b/drivers/pwm/rk_pwm.c @@ -13,8 +13,10 @@ #include #include #include +#ifdef CONFIG_ROCKCHIP_RK3288 #include #include +#endif #include #include @@ -22,7 +24,9 @@ DECLARE_GLOBAL_DATA_PTR; struct rk_pwm_priv { struct rk3288_pwm *regs; +#ifdef CONFIG_ROCKCHIP_RK3288 struct rk3288_grf *grf; +#endif }; static int rk_pwm_set_config(struct udevice *dev, uint channel, uint period_ns, @@ -65,19 +69,23 @@ static int rk_pwm_ofdata_to_platdata(struct udevice *dev) struct regmap *map; priv->regs = (struct rk3288_pwm *)dev_get_addr(dev); +#ifdef CONFIG_ROCKCHIP_RK3288 map = syscon_get_regmap_by_driver_data(ROCKCHIP_SYSCON_GRF); if (IS_ERR(map)) return PTR_ERR(map); priv->grf = regmap_get_range(map, 0); +#endif return 0; } static int rk_pwm_probe(struct udevice *dev) { +#ifdef CONFIG_ROCKCHIP_RK3288 struct rk_pwm_priv *priv = dev_get_priv(dev); rk_setreg(>grf->soc_con2, 1 << 0); +#endif return 0; } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On Wed, Jul 06, 2016 at 10:46:51AM -0500, Joe Hershberger wrote: > Hi Tom, > > A few small last minute compile fixes and a phy support addition. > > The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0: > > Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400) > > are available in the git repository at: > > > git://git.denx.de/u-boot-net.git master > > for you to fetch changes up to 4c64c4db3b87818318ed8b4cd6907c508aaf04ce: > > net: rtl8169: Fix return value for rtl_send_common (2016-07-06 10:45:11 > -0500) > Reviewed-by: Tom Rini-- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Thu, Jul 07, 2016 at 03:55:43PM +0200, Marek Vasut wrote: > Hi Tom, > > I added one more patch by York to fix the powerpc mess. Updated PR > below, please pull for 2016.07 . > > Thanks! > > The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0: > >Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400) > > are available in the git repository at: > >git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to eb364c3dc28d59d33e823470d07746b22a8e6fee: > >powerpc: mpc85xx: kmp204x: Fix compiling error for usb errata > (2016-07-07 13:34:10 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request, u-boot-tegra/master
On Wed, Jul 06, 2016 at 10:32:53AM -0700, Tom Warren wrote: > Tom, > > Please pull u-boot-tegra/master into U-Boot/master. Thanks! > > All Tegra builds are OK, and Stephen's automated test system reports that > all tests pass. > > The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0: > > Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400) > > are available in the git repository at: > > > git://git.denx.de/u-boot-tegra.git master > > for you to fetch changes up to 703aaf76c2c06109fc36266767b2d1dcfce6f3ba: > > fdt: Drop some unused compatible strings (2016-07-05 13:23:04 -0700) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-rockchip
On Tue, Jul 05, 2016 at 11:05:36AM -0600, Simon Glass wrote: > Hi Tom, > > Just a little patch that got lost in time. > > The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0: > > Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-rockchip.git > > for you to fetch changes up to 70c440e5bdca097915b71170f9532ae4faad735a: > > rockchip: video: Lower hpd wait time (2016-07-05 10:38:56 -0600) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BayTrail PCIe x4 slot (Soft-Strap?)
Hi Stefan, On Thu, Jul 7, 2016 at 11:52 PM, Stefan Roesewrote: > Hi! > > I do have BayTrail / FSP related question. I'm currently trying > to use a DFI QSeven SoM which has one x4 PCIe slot instead > of the usual 4 x1 slots. So all 4 PCIe lanes are used by the > first PCIe controller. With the current U-Boot, all 4 PCIe > controllers are enabled by the FSP : > > 00:1c.0 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express > Root Port 1 (rev 11) > 00:1c.1 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express > Root Port 2 (rev 11) > 00:1c.2 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express > Root Port 3 (rev 11) > 00:1c.3 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express > Root Port 4 (rev 11) > > In this configuration, the x4 PCIe card that is installed in the > PCIe slot is not detected. The system always generated hotplug > events for all for ports, but the link is not established. > > The original DFI BIOS only enables the first PCIe controller. The > controllers 1...3 are not visible via lspci. Here the 4x link > is established and the 4x PCIe card is detected correctly. > > My question now is, how can I enable this 4x link on the first > PCIe controller via U-Boot / FSP? I have found no option on how > to configure the PCIe controllers in the FSP dts properties. > So that only the first controller is enabled and visible via > lspci etc. The BayTrail datasheet mentions this to configure the > PCIe setup in chapter "23.2.1 Root Port Configurations": > > " > Root port configurations are set by SoftStraps stored in SPI flash, > and the default option is “(4) x1”. Links for each root port will > train automatically to the maximum possible for each port. > " > Correct. It's determined by the soft strap value in the SPI flash, to be specific, in the descriptor.bin. > Where is this SoftStraps in the SPI flash located? I've found this > page mentioning that its a offset 0x100: > > https://embedded.communities.intel.com/thread/8539 > > But I fail to find any documentation for all those Soft-Strap > Registers / Values in the SPI flash. Does anyone have some further > infos / documentation on this? How to enable 4x PCIe lanes > for one PCIe controller on BayTrail / Atom? > Please try this: If you have the original DFI BIOS, extract the descriptor.bin using U-Boot's ifdtool (ifdtool -x dfi_bios), and use this descriptor.bin to generate u-boot.rom. Or if you don't have the original DFI BIOS, dump it using Dediprog SF100, and do the same. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] driver: fsl_qspi: disable AHB buffer prefetch
>On 07/07/2016 1:01 AM, york sun wrote: > On 07/03/2016 08:27 PM, Yunhui Cui wrote: > > From: Yunhui Cui> > > > A-009282: QuadSPI: QuadSPI data pre-fetch can result in incorrect data > > Affects: QuadSPI > > Description: With AHB buffer prefetch enabled, the QuadSPI may return > > incorrect data on the AHB interface. The buffer pre-fetch is enabled > > if the fetch size as configured either in the LUT or in the BUFxCR > > register is greater than 8 bytes. > > Impact: Only 64 bit read allowed. > > Workaround: Keep the read data size to 64 bits (8 Bytes), which > > disables the prefetch on the AHB buffer, and prevents this issue from > > occurring. > > > > Signed-off-by: Yunhui Cui > > --- > > drivers/spi/fsl_qspi.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index > > 75cbab2..e0a002d 100644 > > --- a/drivers/spi/fsl_qspi.c > > +++ b/drivers/spi/fsl_qspi.c > > @@ -444,7 +444,7 @@ static void qspi_init_ahb_read(struct fsl_qspi_priv > *priv) > > qspi_write32(priv->flags, >buf1cr, > QSPI_BUFXCR_INVALID_MSTRID); > > qspi_write32(priv->flags, >buf2cr, > QSPI_BUFXCR_INVALID_MSTRID); > > qspi_write32(priv->flags, >buf3cr, QSPI_BUF3CR_ALLMST_MASK | > > -(0x80 << QSPI_BUF3CR_ADATSZ_SHIFT)); > > +(0x1 << QSPI_BUF3CR_ADATSZ_SHIFT)); > > > > /* We only use the buffer3 */ > > qspi_write32(priv->flags, >buf0ind, 0); > > > > Yunhui, > > We handle erratum workaround using macros in case the workaround has > impact on other SoCs. [Yunhui] For now, all SoCs with Qspi module need this errata. > We also put the erratum information either in a > README file, or inline comment. It will be easier to read the code later. [Yunhui] ok, I will add inline comment in next version. > You don't have to put the whole erratum description in the commit message, > as long as it explains what this patch does and refer the erratum number > somewhere in the message so we can search the git log. > > York [Yunhui] ok, I will update the commit message in next version. Thanks Yunhui ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] usb: rockchip-phy: implement USB2.0 phy control for Synopsys
On 2016年07月08日 04:33, Heiko Stuebner wrote: Am Donnerstag, 7. Juli 2016, 09:58:38 schrieb Ziyuan Xu: On 2016年07月06日 21:42, Heiko Stuebner wrote: Am Mittwoch, 6. Juli 2016, 14:48:57 schrieb Heiko Stuebner: Am Mittwoch, 6. Juli 2016, 18:20:04 schrieb Ziyuan Xu: Hi heiko, On 2016年07月06日 17:34, Ziyuan Xu wrote: From: Xu ZiyuanSo far, Rockchip SoCs have two kinds of USB2.0 phy, like Synopsys and Innosilicon. This patch applys dwc2 usb driver framework to implement phy_init and phy_off for Synopsys phy on Rockchip platform. Signed-off-by: Ziyuan Xu --- Changes in v3: - Make UOC_CON registers to be unfixed which should be got from DT Changes in v2: - Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c - Rework the behaviour in otg_phy_init() and otg_phy_off() drivers/usb/phy/Makefile| 1 + drivers/usb/phy/rockchip_usb_syno_phy.c | 47 + 2 files changed, 48 insertions(+) create mode 100644 drivers/usb/phy/rockchip_usb_syno_phy.c diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index 93d147e..8002a18 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -7,3 +7,4 @@ obj-$(CONFIG_TWL4030_USB) += twl4030.o obj-$(CONFIG_OMAP_USB_PHY) += omap_usb_phy.o +obj-$(CONFIG_ROCKCHIP_USB_SYNO_PHY) += rockchip_usb_syno_phy.o diff --git a/drivers/usb/phy/rockchip_usb_syno_phy.c b/drivers/usb/phy/rockchip_usb_syno_phy.c new file mode 100644 index 000..ab049e1 --- /dev/null +++ b/drivers/usb/phy/rockchip_usb_syno_phy.c @@ -0,0 +1,47 @@ +/* + * Copyright 2016 Rockchip Electronics Co., Ltd + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include + +#include "../gadget/dwc2_udc_otg_priv.h" + +#define UOC_CON(x) ((x) * 0x4) As you know, dwc2 usb driver didn't apply devicetree model. It's hard to implement a compatible driver for Rockchip SoCs which use a same udc. Yeah, it is pretty strange that the dwc2 host part in uboot uses the devicetree while the gadget part does not - but I maybe someone else can answer this, as my contact with uboot was limited until now. The dwc2 host driver works just fine on my rk3036 kylin board. For example, SOFT_CTRL bit is UOC_CON2[2] on RK3288 I can't assure it's also UOC_CON[2] on other socs. Do you have any good ideas? Operating under the current constraints, I guess you could simply do something similar to what socfpga does in its board file. socfpga? Could you please indicate which project and file? I can't find out it. Aka get the usb controller node, read the phy phandle and get the phy compatible string from the dts. The usbphys each have per-soc compatible values "rockchip,rk3288-usbphy" etc, so you can determine the needed bits over that. In patchset [v3.3/4](http://patchwork.ozlabs.org/patch/645188/), I had get usb-phy offset from grf. If I understand it correctly, you mean that implement a struct in driver to match compatible and platdata. Then define any properties in platdata, contains of some bits which will be used. Something similar to https://patchwork.kernel.org/patch/9190287/? yep, you just need to find some mechanism to identify the soc you're running on so that the phy part can access the right registers on each one. Thanks for your opinion, I will do it. Heiko ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-dm
Hi Tom, A little fix. The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0: Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400) are available in the git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to 3cc5cda761c14628b25131bfc0db5dee433a52aa: mmc: msm_sdhci: Set mmc->dev pointer in msm_sdc_probe() (2016-07-07 10:10:29 -0600) Mateusz Kulikowski (1): mmc: msm_sdhci: Set mmc->dev pointer in msm_sdc_probe() drivers/mmc/msm_sdhci.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] usb: rockchip-phy: implement USB2.0 phy control for Synopsys
Am Donnerstag, 7. Juli 2016, 09:58:38 schrieb Ziyuan Xu: > On 2016年07月06日 21:42, Heiko Stuebner wrote: > > Am Mittwoch, 6. Juli 2016, 14:48:57 schrieb Heiko Stuebner: > >> Am Mittwoch, 6. Juli 2016, 18:20:04 schrieb Ziyuan Xu: > >>> Hi heiko, > >>> > >>> On 2016年07月06日 17:34, Ziyuan Xu wrote: > From: Xu Ziyuan> > So far, Rockchip SoCs have two kinds of USB2.0 phy, like Synopsys and > Innosilicon. This patch applys dwc2 usb driver framework to implement > phy_init and phy_off for Synopsys phy on Rockchip platform. > > Signed-off-by: Ziyuan Xu > > --- > > Changes in v3: > - Make UOC_CON registers to be unfixed which should be got from DT > > Changes in v2: > - Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c > - Rework the behaviour in otg_phy_init() and otg_phy_off() > > drivers/usb/phy/Makefile| 1 + > drivers/usb/phy/rockchip_usb_syno_phy.c | 47 > + 2 files changed, 48 > insertions(+) > create mode 100644 drivers/usb/phy/rockchip_usb_syno_phy.c > > diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile > index 93d147e..8002a18 100644 > --- a/drivers/usb/phy/Makefile > +++ b/drivers/usb/phy/Makefile > @@ -7,3 +7,4 @@ > > obj-$(CONFIG_TWL4030_USB) += twl4030.o > obj-$(CONFIG_OMAP_USB_PHY) += omap_usb_phy.o > > +obj-$(CONFIG_ROCKCHIP_USB_SYNO_PHY) += rockchip_usb_syno_phy.o > diff --git a/drivers/usb/phy/rockchip_usb_syno_phy.c > b/drivers/usb/phy/rockchip_usb_syno_phy.c new file mode 100644 > index 000..ab049e1 > --- /dev/null > +++ b/drivers/usb/phy/rockchip_usb_syno_phy.c > @@ -0,0 +1,47 @@ > +/* > + * Copyright 2016 Rockchip Electronics Co., Ltd > + * > + * SPDX-License-Identifier:GPL-2.0+ > + */ > + > +#include > +#include > + > +#include "../gadget/dwc2_udc_otg_priv.h" > + > +#define UOC_CON(x) ((x) * 0x4) > >>> > >>> As you know, dwc2 usb driver didn't apply devicetree model. It's hard > >>> to > >>> implement a compatible driver for Rockchip SoCs which use a same udc. > >> > >> Yeah, it is pretty strange that the dwc2 host part in uboot uses the > >> devicetree while the gadget part does not - but I maybe someone else > >> can > >> answer this, as my contact with uboot was limited until now. > >> The dwc2 host driver works just fine on my rk3036 kylin board. > >> > >>> For example, > >>> SOFT_CTRL bit is UOC_CON2[2] on RK3288 > >>> I can't assure it's also UOC_CON[2] on other socs. > >>> Do you have any good ideas? > >> > >> Operating under the current constraints, I guess you could simply do > >> something similar to what socfpga does in its board file. > > socfpga? Could you please indicate which project and file? I can't find > out it. > > >> Aka get the usb controller node, read the phy phandle and get the phy > >> compatible string from the dts. The usbphys each have per-soc > >> compatible > >> values "rockchip,rk3288-usbphy" etc, so you can determine the needed > >> bits > >> over that. > > In patchset [v3.3/4](http://patchwork.ozlabs.org/patch/645188/), I had > get usb-phy offset from grf. > If I understand it correctly, you mean that implement a struct in driver > to match compatible and platdata. Then define any properties in > platdata, contains of some bits which will be used. Something similar > to https://patchwork.kernel.org/patch/9190287/? yep, you just need to find some mechanism to identify the soc you're running on so that the phy part can access the right registers on each one. Heiko ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DMA driver for PL330
Hi Dinh, On 7 July 2016 at 10:30, Dinh Nguyenwrote: > > Hi Simon, > > I was wondering if you know of anyone working to add the PL330 driver > into U-Boot? If not, then perhaps I'll work on adding it to U-Boot. > > SoCFPGA has a specific need for it with regards to enabling the SDRAM ECC. No, not me. Please go ahead. > > Thanks, > Dinh Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/11] buildman: Make the tool friendlier for first-time users
On 07/03/2016 03:14 PM, Simon Glass wrote: This makes a few minor improvements to buildman to make it work more easiler for first-time users: - Improve progress and warning messages when fetching toolchains - Fix a bug where toolchain paths can be overwritten when fetching - Note at the top of the help how to get started Also this series removes MAKEALL. Since buildman has been around for 3 years it may be time to do this. If not, we can leave it for now. Sounds great:-) BTW, one problem I've come across with buildman recently is that it re-orders warnings/errors from the compiler. In particular, it seems to separate what it thinks are warning from errors (perhaps stdout/stderr split??) but I'm not sure it always gets it right, and I think elides duplicate lines when doing so. When running buildman repeatedly while doing development, and experiencing a compile error, this makes it extremely difficult to interpret some of the compiler's multi-line messages. Is it possible to have an option that turns off all the output processing, and just shows stderr/out mixed up as they would appear "interactively" when manually invoked from a shell, with no post-processing? Occasionally I have to fall back to a manual "make" invocation due to this. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/11] buildman: Add a quick-start note
On 07/03/2016 03:14 PM, Simon Glass wrote: For those who just want to build a board, it is useful to see a quick hint right at the start of the documentation. Add a few commands showing how to download toolchains and build a board. diff --git a/tools/buildman/README b/tools/buildman/README +If you just want to quickly set up buildman so you can build something (for +example Raspberry Pi 2), and don't mind downloading lots of stuff: + + cd /path/to/u-boot + PATH=$PATH:`pwd`/tools/buildman + buildman --fetch-arch all + buildman -k rpi_2 + ls ../current/rpi_2 + # u-boot.bin is the output image For just an rpi_2 build, perhaps "--fetch-arch arm" would be quicker, although I suppose then you'd have to make the text more complicated by pointing out that it only downloads an ARM toolchain and so the user would need to --fetch-arch again for anything else. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/11] buildman: Avoid overwriting existing toolchain entries
On 07/03/2016 03:14 PM, Simon Glass wrote: The current code for setting up the toolchain config always writes the new paths to an item called 'toolchain'. This means that it will overwrite any existing toolchain item with the same name. In practice, this means that: buildman --fetch-arch all will fetch all toolchains, but only the path of the final one will be added to the config. This normally works out OK, since most toolchains are the same version (e.g. gcc 4.9) and will be found on the same path. But it is not correct and toolchains for archs which don't use the same version will not function as expected. Adjust the code to use unique names for each toolchain path entry. diff --git a/tools/buildman/bsettings.py b/tools/buildman/bsettings.py +def GetItemsAsDict(section): +"""Get the items from a section of the config. + +Args: +section: name of section to retrieve + +Returns: +Dict: + key: name of item + value: value of item +""" +try: +items = {} +for item in settings.items(section): +items[item[0]] = item[1] Aren't those last 3 lines equivalent to: items = dict(settings.items(section)) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/11] buildman: Allow the toolchain error to be suppressed
On 07/03/2016 03:14 PM, Simon Glass wrote: When there are no toolchains a warning is printed. But in some cases this is confusing, such as when the user is fetching new toolchains. Adjust the function to supress the warning in this case. diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py -def GetPathList(self): +def GetPathList(self, show_warning=True): """Get a list of available toolchain paths +Args: +show_warning: True to show a warning if there are no tool chains. I don't see the new parameter being used anywhere? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/11] buildman: Automatically create a config file if needed
On 07/03/2016 03:14 PM, Simon Glass wrote: If there is no ~/.buildman file, buildman currently complains and exists. To make things a little more friendly, create an empty one automatically. This will not allow things to be built, but --fetch-arch can be used to handle that. Is it worth pointing out that caveat in the message that's printed? Is that caveat true e.g. in the case where the user already has a suitable compiler installed in (the default?) /usr/bin? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/14] test: Convert the vboot test to test/py
On 07/03/2016 03:38 PM, Teddy Reed wrote: Hi Simon, On Sun, Jul 3, 2016 at 8:40 AM, Simon Glasswrote: Now that we have a suitable test framework we should move all tests into it. The vboot test is a suitable candidate. Rewrite it in Python and move the data files into an appropriate directory. +datadir = 'test/py/tests/vboot/' +fit = '%stest.fit' % tmpdir +mkimage = cons.config.build_dir + '/tools/mkimage' +fit_check_sign = cons.config.build_dir + '/tools/fit_check_sign' +dtc_args = '-I dts -O dtb -i %s' % tmpdir +dtb = '%ssandbox-u-boot.dtb' % tmpdir +sig_node = '/configurations/conf@1/signature@1' If these variables are used throughout the tests like globals, should they be DATADIR, MKIMAGE, etc? I'd prefer not to use all-caps variable names. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/14] test: Convert the vboot test to test/py
On 07/03/2016 09:40 AM, Simon Glass wrote: Now that we have a suitable test framework we should move all tests into it. The vboot test is a suitable candidate. Rewrite it in Python and move the data files into an appropriate directory. diff --git a/test/py/tests/test_vboot.py b/test/py/tests/test_vboot.py +# Copyright (c) 2013, Google Inc. 2013-2016? +@pytest.mark.buildconfigspec('fit_signature') +def test_vboot(u_boot_console): +"""Test verified boot signing with mkimage and verification with 'bootm'. + +This works using sandbox only as it needs to update the device tree used +by U-Boot to hold public keys from the signing process. Since this works on sandbox, the function should be marked: @pytest.mark.boardspec('sandbox') +def dtc(dts): +util.cmd(cons, 'dtc %s %s%s -O dtb ' + '-o %s%s' % (dtc_args, datadir, dts, tmpdir, dtb)) For all the instances of util.cmd() in this file, it looks pretty easy to represent them as arrays rather than strings. Is implementing/using cmd() really necessary? +def run_bootm(test_type, expect_string): +cons.cleanup_spawn() +cons.ensure_spawned() That feels a bit too much like relying on internal details, especially as the docstring for cleanup_spawn() says "This is an internal function and should not be called directly." Can we introduce a new public function cons.restart_uboot() that's intended for public use? The implementation would just be the two lines above, but it would provide some encapsulation of the details. +cons.log.action('%s: Test Verified Boot Run: %s' % (algo, test_type)) > +output = cons.run_command_list( > +['sb load hostfs - 100 %stest.fit' % tmpdir, > + 'fdt addr 100', > + 'bootm 100']) > +assert(expect_string in output) Would it make sense to do this instead: with cons.log.section("Verified boot %s %s" % (algo, test_type)): output = ... assert ... ? That would nest each invocation of that command list into a separate collapsible section of the HTML log file. +def test_with_algo(sha): +"""Test verified boot with the given hash algorithm + +This is the main part of the test code. The same procedure is followed +for both hashing algorithms. + +Args: +sha: Either 'sha1' or 'sha256', to select the algorithm to use +""" +global algo + +algo = sha Why not just pass that parameter to the couple of functions that need it? Certainly, having the various utility functions rely on variables from outer scopes is consistent with some other existing tests, but if you're going to do that, I'd suggest having this function not take the sha parameter, but instead pick up "algo" from an outer scope too? +# Compile our device tree files for kernel and U-Boot +dtc('sandbox-kernel.dts') +dtc('sandbox-u-boot.dts') I think that happens twice, and ends up doing an identical operation. Should those commands (and perhaps some others below too?) be moved outside the function into top-level setup code? Also, is it necessary to repeat those commands if a previous test run already ran dtc? Here, dtc is an external utility so I don't think running it over and over is worthwhile. However, for some/all of the mkimage below, since mkimage presumably comes from the current U-Boot build, re-running it each time would actually test something about the current U-Boot source tree. +# Build the FIT, but don't sign anything yet +cons.log.action('%s: Test FIT with signed images' % algo) +make_fit('sign-images-%s.its' % algo) +run_bootm('unsigned images', 'dev-') Perhaps rather than run_bootm() creating its own log section, the section should be created here, and wrap all 3 of those lines above? +# Sign images with our dev keys +sign_fit() +run_bootm('signed images', 'dev+') + +# Create a fresh .dtb without the public keys +dtc('sandbox-u-boot.dts') Doesn't this generate the same DTB as above? I don't see any FIT/binary/... include statements etc. in that .dts file. +byte_list = ['%x' % (byte + 1)] + byte_list[1:] byte_list[0] = '%x' % (byte + 1) ? +cons = u_boot_console +tmpdir = cons.config.result_dir + '/' +tmp = tmpdir + 'vboot.tmp' +datadir = 'test/py/tests/vboot/' I suspect some of the files might usefully be placed into ubconfig.persistent_data_dir? +fit = '%stest.fit' % tmpdir +mkimage = cons.config.build_dir + '/tools/mkimage' +fit_check_sign = cons.config.build_dir + '/tools/fit_check_sign' +dtc_args = '-I dts -O dtb -i %s' % tmpdir +dtb = '%ssandbox-u-boot.dtb' % tmpdir I think all those filename concatenations would be clearer as '%s/%s' rather than placing the / into one of the strings. +# Create an RSA key pair +public_exponent = 65537 +
Re: [U-Boot] [PATCH] armv8: Remove the codes about switching to EL1 before jumping to kernel
Hi, 2016-07-07 13:44 GMT+02:00 Alexander Graf: > On 07/07/2016 08:25 AM, Alison Wang wrote: > >> As CONFIG_ARMV8_SWITCH_TO_EL1 is not used now, this patch is to remove >> CONFIG_ARMV8_SWITCH_TO_EL1 and the corresponding functions. >> >> Signed-off-by: Alison Wang >> > > I'll CC the maintainers for ZynqMP and Exynos as well, but from my side > this patch is a great step forward. > > Reviewed-by: Alexander Graf I am against this patch. The reason is simple. We are using this option for testing to make sure that hyperviser and OS behaves correctly when they start from different level. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] driver: fsl_qspi: disable AHB buffer prefetch
On 07/07/2016 12:52 AM, Yunhui Cui wrote: > >> On 07/07/2016 1:01 AM, york sun wrote: >> On 07/03/2016 08:27 PM, Yunhui Cui wrote: >>> From: Yunhui Cui>>> >>> A-009282: QuadSPI: QuadSPI data pre-fetch can result in incorrect data >>> Affects: QuadSPI >>> Description: With AHB buffer prefetch enabled, the QuadSPI may return >>> incorrect data on the AHB interface. The buffer pre-fetch is enabled >>> if the fetch size as configured either in the LUT or in the BUFxCR >>> register is greater than 8 bytes. >>> Impact: Only 64 bit read allowed. >>> Workaround: Keep the read data size to 64 bits (8 Bytes), which >>> disables the prefetch on the AHB buffer, and prevents this issue from >>> occurring. >>> >>> Signed-off-by: Yunhui Cui >>> --- >>>drivers/spi/fsl_qspi.c | 2 +- >>>1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index >>> 75cbab2..e0a002d 100644 >>> --- a/drivers/spi/fsl_qspi.c >>> +++ b/drivers/spi/fsl_qspi.c >>> @@ -444,7 +444,7 @@ static void qspi_init_ahb_read(struct fsl_qspi_priv >> *priv) >>> qspi_write32(priv->flags, >buf1cr, >> QSPI_BUFXCR_INVALID_MSTRID); >>> qspi_write32(priv->flags, >buf2cr, >> QSPI_BUFXCR_INVALID_MSTRID); >>> qspi_write32(priv->flags, >buf3cr, QSPI_BUF3CR_ALLMST_MASK | >>> -(0x80 << QSPI_BUF3CR_ADATSZ_SHIFT)); >>> +(0x1 << QSPI_BUF3CR_ADATSZ_SHIFT)); >>> >>> /* We only use the buffer3 */ >>> qspi_write32(priv->flags, >buf0ind, 0); >>> >> >> Yunhui, >> >> We handle erratum workaround using macros in case the workaround has >> impact on other SoCs. > > [Yunhui] For now, all SoCs with Qspi module need this errata. I still think it is better to gate the workaround with #ifdef in case we need to disable it for future SoCs. It will also be easier to locate the workaround code. > >> We also put the erratum information either in a >> README file, or inline comment. It will be easier to read the code later. > > [Yunhui] ok, I will add inline comment in next version. > >> You don't have to put the whole erratum description in the commit message, >> as long as it explains what this patch does and refer the erratum number >> somewhere in the message so we can search the git log. >> >> York > > [Yunhui] ok, I will update the commit message in next version. > Thanks. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/14] test/py: Fix up after the rename of CONFIG_SYS_HUSH_PARSER
On 07/03/2016 09:40 AM, Simon Glass wrote: At present all the hush tests are skipped on sandbox because the test thinks that this option is disabled. In fact it has just been renamed. It might be better to use the full CONFIG_xxx name in tests with @pytest.mark.buildconfigspec(), since at present it is not really clear that the options are related. Fixes: f1f9d4fa (hush: complete renaming CONFIG_SYS_HUSH_PARSER to CONFIG_HUSH_PARSER) Oh, I sent almost a duplicate of this later: https://patchwork.ozlabs.org/patch/645376/ That one also fixes a similar issue due to the reset -> sysreset rename. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/14] test/py: Add an option to execute a string containing a command
On 07/03/2016 09:40 AM, Simon Glass wrote: It is sometimes inconvenient to convert a string into a list for execution with run_and_log(). Provide a helper function to do this. diff --git a/test/py/u_boot_utils.py b/test/py/u_boot_utils.py +def cmd(u_boot_console, cmd_str): +"""Run a single command string and log its output. + +Args: +u_boot_console: A console connection to U-Boot. +cmd: The command to run, as a string. + +Returns: +The output as a string. +""" Thinking about this more: I believe the Pythonic way to do this would be to extend the existing run_and_log() to support the cmd parameter being either an array, or a string; I think something like just adding the following at the start of run_and_log(): if isinstance(cmd, str): cmd = str.split() This would also allow other higher-order functions like your later run_command_list() to take either a list of argv[] or a list of strings (or even a mixture), without having to code multiple versions of the higher level functions for the different cases. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/14] test/py: Provide a way to check that a command fails
On 07/03/2016 09:40 AM, Simon Glass wrote: Sometimes we want to run a command and check that it fails. Add a function to handle this. It can check the return code and also make sure that the output contains a given error message. diff --git a/test/py/u_boot_utils.py b/test/py/u_boot_utils.py +def run_and_log_expect_exception(u_boot_console, cmd, retcode, msg): +"""Run a command which is expected to fail. + +This runs a command and checks that it fails with the expected return code +and exception method. If not, an exception is raised. + +Args: +u_boot_console: A console connection to U-Boot. +cmd: The command to run, as an array of argv[]. +retcode: Expected non-zero return code from the command. +msg: String which should be contained within the command's output. +""" retcode isn't used anywhere. Do we care what the return code is, so long as it's something non-zero, and the desired exception message appears? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/14] test/py: Add an option to execute a string containing a command
On 07/03/2016 09:40 AM, Simon Glass wrote: It is sometimes inconvenient to convert a string into a list for execution with run_and_log(). Provide a helper function to do this. diff --git a/test/py/u_boot_utils.py b/test/py/u_boot_utils.py +def cmd(u_boot_console, cmd_str): "cmd" seems very generic and doesn't give any clue what it does. How about extending the existing function name to e.g. "run_and_log_str"? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] DMA driver for PL330
Hi Simon, I was wondering if you know of anyone working to add the PL330 driver into U-Boot? If not, then perhaps I'll work on adding it to U-Boot. SoCFPGA has a specific need for it with regards to enabling the SDRAM ECC. Thanks, Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] dm: mmc: dwmmc: use the callback functions as static
Hi Minkyu, On 6 July 2016 at 20:14, Minkyu Kangwrote: > Hi, > > On 01/07/16 04:53, Simon Glass wrote: >> Hi Jaehoon, >> >> On 28 June 2016 at 20:47, Jaehoon Chung wrote: >>> Hi Simon, >>> >>> On 06/29/2016 12:28 PM, Simon Glass wrote: Hi Jaehoon, On 27 June 2016 at 23:52, Jaehoon Chung wrote: > There are no places to call these functions. > It should be used the callback function. > Then it can be used as static functions. > > Signed-off-by: Jaehoon Chung > --- > drivers/mmc/dw_mmc.c | 4 ++-- > include/dwmmc.h | 3 --- > 2 files changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c > index 3411f95..f83a6bc 100644 > --- a/drivers/mmc/dw_mmc.c > +++ b/drivers/mmc/dw_mmc.c > @@ -182,7 +182,7 @@ static int dwmci_set_transfer_mode(struct dwmci_host > *host, > } > > #ifdef CONFIG_DM_MMC_OPS > -int dwmci_send_cmd(struct udevice *dev, struct mmc_cmd *cmd, >From what I can see this is already static. Which commit are you basing >off? >>> >>> I'm checking with your 'blk-working' branch. I'm not sure what's correct. >>> >>> commit dee390a1250c17a4e71e359d6e461319a7cdea54 >>> Author: Simon Glass >>> Date: Sat Jun 11 19:01:49 2016 -0600 >>> >>> dm: blk: Enable CONFIG_BLK if DM_MMC is enabled >>> >>> If i need to work with other branch, let me know,plz. >>> I have tested the DM with dw_mmc_exynos.c. (It's working fine.) >>> >>> I will send the patch-set for exynos dwmmc and sdhci controller. >>> So i need to know which repository and branch are correct. :) >>> >>> Then it's helpful to me for working dm. I think that i can help you for >>> checking on mmc side with DM. >> >> OK I see, thanks. >> >> Reviewed-by: Simon Glass >> > > This patch has been delegated to me, but cannot apply to u-boot-samsung. > should go to dm tree? Yes, it depends on dm/next. I'll assign those to patches to myself. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] BayTrail PCIe x4 slot (Soft-Strap?)
Hi! I do have BayTrail / FSP related question. I'm currently trying to use a DFI QSeven SoM which has one x4 PCIe slot instead of the usual 4 x1 slots. So all 4 PCIe lanes are used by the first PCIe controller. With the current U-Boot, all 4 PCIe controllers are enabled by the FSP : 00:1c.0 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 1 (rev 11) 00:1c.1 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 2 (rev 11) 00:1c.2 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 3 (rev 11) 00:1c.3 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 4 (rev 11) In this configuration, the x4 PCIe card that is installed in the PCIe slot is not detected. The system always generated hotplug events for all for ports, but the link is not established. The original DFI BIOS only enables the first PCIe controller. The controllers 1...3 are not visible via lspci. Here the 4x link is established and the 4x PCIe card is detected correctly. My question now is, how can I enable this 4x link on the first PCIe controller via U-Boot / FSP? I have found no option on how to configure the PCIe controllers in the FSP dts properties. So that only the first controller is enabled and visible via lspci etc. The BayTrail datasheet mentions this to configure the PCIe setup in chapter "23.2.1 Root Port Configurations": " Root port configurations are set by SoftStraps stored in SPI flash, and the default option is “(4) x1”. Links for each root port will train automatically to the maximum possible for each port. " Where is this SoftStraps in the SPI flash located? I've found this page mentioning that its a offset 0x100: https://embedded.communities.intel.com/thread/8539 But I fail to find any documentation for all those Soft-Strap Registers / Values in the SPI flash. Does anyone have some further infos / documentation on this? How to enable 4x PCIe lanes for one PCIe controller on BayTrail / Atom? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
Hi Tom, I added one more patch by York to fix the powerpc mess. Updated PR below, please pull for 2016.07 . Thanks! The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0: Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to eb364c3dc28d59d33e823470d07746b22a8e6fee: powerpc: mpc85xx: kmp204x: Fix compiling error for usb errata (2016-07-07 13:34:10 +0200) Hans de Goede (2): usb: dm: Add a usb_for_each_root_dev() helper function usb: dm: Make "usb info" use usb_for_each_root_dev() Marek Vasut (1): powerpc: mpc85xx: Do not build errata command in SPL York Sun (1): powerpc: mpc85xx: kmp204x: Fix compiling error for usb errata arch/powerpc/cpu/mpc85xx/Makefile | 2 ++ cmd/usb.c | 46 ++ include/configs/km/kmp204x-common.h | 1 + 3 files changed, 21 insertions(+), 28 deletions(-) -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: board: cm_fx6: fixup mtd partitions in the fdt
Hi Nikita, On 07/07/2016 10:53 AM, Nikita Kiryanov wrote: > On Wed, Jun 22, 2016 at 07:17:53PM +0300, Igor Grinberg wrote: >> On 06/19/2016 06:44 PM, Christopher Spinrath wrote: >>> The cm-fx6 module has an on-board st,m25p compatible spi flash chip >>> used for u-boot (binary & environment). Overwrite the partitions in >>> the device tree by the partition table provided in the mtdparts >>> environment variable, if it is set. >>> >>> This allows to specify a kernel independent partitioning in the >>> environment and provides a convient way for the user to adapt the >>> partition table. >>> >>> Signed-off-by: Christopher Spinrath>>> --- >>> board/compulab/cm_fx6/cm_fx6.c | 16 +++- >>> 1 file changed, 15 insertions(+), 1 deletion(-) >>> >>> diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c >>> index 712057a..81a7ae2 100644 >>> --- a/board/compulab/cm_fx6/cm_fx6.c >>> +++ b/board/compulab/cm_fx6/cm_fx6.c >> >> [...] >> >>> +#ifdef CONFIG_FDT_FIXUP_PARTITIONS >>> +struct node_info nodes[] = { >>> + { "st,m25p",MTD_DEV_TYPE_NOR, }, >> >> Nikita, is this enough for all flashes we assemble on cm-fx6? > > Yes, CM-FX6 is using M25PX16 and SST25VF016B, both of which are > supported by the m25p80.c driver. However, on the mainline branch > I don't see "m25p" in the list of device ids, and IIRC the request > is to favor "jedec,spi-nor" as compatible string over device specific > ones. Linux is going to use "st,m25p", "jedec,spi-nor" as compatible list (currently queued for inclusion in v4.8: https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/tree/arch/arm/boot/dts/imx6q-cm-fx6.dts?h=next/dt#n123 ). I have chosen "st,m25p" here to cover both the mainline and CompuLab's device trees (I have seen some where "jedec,spi-nor" is not in the list). However, if you prefer I will switch to "jedec,spi-nor" (excluding some device trees) in v2. Thanks, Christopher > >> >>> +}; >>> +#endif >>> + >> >> [...] >> >> -- >> Regards, >> Igor. >> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
On 07/07/2016 02:46 PM, Ryan Harkin wrote: On 7 July 2016 at 13:41, Alexander Grafwrote: On 07/07/2016 02:35 PM, Ryan Harkin wrote: On 7 July 2016 at 13:30, Alexander Graf wrote: On 07/07/2016 02:16 PM, Ryan Harkin wrote: On 7 July 2016 at 07:30, Alison Wang wrote: To support loading a 32-bit OS, the execution state will change from AArch64 to AArch32 when jumping to kernel. The architecture information will be got through checking FIT image, then U-Boot will load 32-bit OS or 64-bit OS automatically. Signed-off-by: Ebony Zhu Signed-off-by: Alison Wang Signed-off-by: Chenhui Zhao Unfortunately, this patch fails to boot for me. On FVP Foundation models, I see this error before the model hangs: [snip] Starting kernel ... resetting ... [snip] And I see the same output on AEMv8 Base models and Juno boards, only they reset continuously rather than hang. I think the problem is that I see this from ARM Trusted Firmware on boot: INFO:BL31: Preparing for EL3 exit to normal world Looking at the patch, it appears to be changing everything to boot in EL2. That was the case before the patch (with the removal of the EL1 boot thing) already. Linux can't run in EL3, that's why it has to boot in EL2 (or EL1, but that really should be limited to VMs). Pah! I misread the patch, specifically this hunk (and the one before it, I suppose): diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index e3c9832..59adab8 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -193,7 +193,6 @@ static void do_nonsec_virt_switch(void) { smp_kick_all_cpus(); dcache_disable();/* flush cache before swtiching to EL2 */ -armv8_switch_to_el2(); } #endif That's a "-", not a "+" on the call to armv8_switch_to_el2(). Either way, all my platforms are dead with this patch. Since you're running in software models, can you try to figure out where exactly it breaks? You assume that because I have a model that I have the ability to debug it ;-) ARM's FVP Foundation model is publicly available and free to use. So if you want to give it a spin, it's there for the taking. I thought the Foundation model doesn't support external debugging? I'd basically want to put a breakpoint at the point where the kernel exit print goes and then trace it from there :). But since Alison wrote the patches, I'm sure he can do that too :). Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
On 7 July 2016 at 13:41, Alexander Grafwrote: > On 07/07/2016 02:35 PM, Ryan Harkin wrote: >> >> On 7 July 2016 at 13:30, Alexander Graf wrote: >>> >>> On 07/07/2016 02:16 PM, Ryan Harkin wrote: On 7 July 2016 at 07:30, Alison Wang wrote: > > To support loading a 32-bit OS, the execution state will change from > AArch64 to AArch32 when jumping to kernel. > > The architecture information will be got through checking FIT image, > then U-Boot will load 32-bit OS or 64-bit OS automatically. > > Signed-off-by: Ebony Zhu > Signed-off-by: Alison Wang > Signed-off-by: Chenhui Zhao Unfortunately, this patch fails to boot for me. On FVP Foundation models, I see this error before the model hangs: [snip] Starting kernel ... resetting ... [snip] And I see the same output on AEMv8 Base models and Juno boards, only they reset continuously rather than hang. I think the problem is that I see this from ARM Trusted Firmware on boot: INFO:BL31: Preparing for EL3 exit to normal world Looking at the patch, it appears to be changing everything to boot in EL2. >>> >>> >>> That was the case before the patch (with the removal of the EL1 boot >>> thing) >>> already. Linux can't run in EL3, that's why it has to boot in EL2 (or >>> EL1, >>> but that really should be limited to VMs). >>> >> Pah! I misread the patch, specifically this hunk (and the one before >> it, I suppose): >> >> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c >> index e3c9832..59adab8 100644 >> --- a/arch/arm/lib/bootm.c >> +++ b/arch/arm/lib/bootm.c >> @@ -193,7 +193,6 @@ static void do_nonsec_virt_switch(void) >> { >> smp_kick_all_cpus(); >> dcache_disable();/* flush cache before swtiching to EL2 */ >> -armv8_switch_to_el2(); >> } >> #endif >> >> That's a "-", not a "+" on the call to armv8_switch_to_el2(). >> >> Either way, all my platforms are dead with this patch. > > > Since you're running in software models, can you try to figure out where > exactly it breaks? You assume that because I have a model that I have the ability to debug it ;-) ARM's FVP Foundation model is publicly available and free to use. So if you want to give it a spin, it's there for the taking. > I'm slightly confused that it's resetting. The switch to > EL2 shouldn't matter in your setup, because you're executing U-Boot in EL2 > already, since you're running ATF in EL3. > > > Alex > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
On 07/07/2016 02:35 PM, Ryan Harkin wrote: On 7 July 2016 at 13:30, Alexander Grafwrote: On 07/07/2016 02:16 PM, Ryan Harkin wrote: On 7 July 2016 at 07:30, Alison Wang wrote: To support loading a 32-bit OS, the execution state will change from AArch64 to AArch32 when jumping to kernel. The architecture information will be got through checking FIT image, then U-Boot will load 32-bit OS or 64-bit OS automatically. Signed-off-by: Ebony Zhu Signed-off-by: Alison Wang Signed-off-by: Chenhui Zhao Unfortunately, this patch fails to boot for me. On FVP Foundation models, I see this error before the model hangs: [snip] Starting kernel ... resetting ... [snip] And I see the same output on AEMv8 Base models and Juno boards, only they reset continuously rather than hang. I think the problem is that I see this from ARM Trusted Firmware on boot: INFO:BL31: Preparing for EL3 exit to normal world Looking at the patch, it appears to be changing everything to boot in EL2. That was the case before the patch (with the removal of the EL1 boot thing) already. Linux can't run in EL3, that's why it has to boot in EL2 (or EL1, but that really should be limited to VMs). Pah! I misread the patch, specifically this hunk (and the one before it, I suppose): diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index e3c9832..59adab8 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -193,7 +193,6 @@ static void do_nonsec_virt_switch(void) { smp_kick_all_cpus(); dcache_disable();/* flush cache before swtiching to EL2 */ -armv8_switch_to_el2(); } #endif That's a "-", not a "+" on the call to armv8_switch_to_el2(). Either way, all my platforms are dead with this patch. Since you're running in software models, can you try to figure out where exactly it breaks? I'm slightly confused that it's resetting. The switch to EL2 shouldn't matter in your setup, because you're executing U-Boot in EL2 already, since you're running ATF in EL3. Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
On 7 July 2016 at 13:30, Alexander Grafwrote: > On 07/07/2016 02:16 PM, Ryan Harkin wrote: >> >> On 7 July 2016 at 07:30, Alison Wang wrote: >>> >>> To support loading a 32-bit OS, the execution state will change from >>> AArch64 to AArch32 when jumping to kernel. >>> >>> The architecture information will be got through checking FIT image, >>> then U-Boot will load 32-bit OS or 64-bit OS automatically. >>> >>> Signed-off-by: Ebony Zhu >>> Signed-off-by: Alison Wang >>> Signed-off-by: Chenhui Zhao >> >> Unfortunately, this patch fails to boot for me. >> >> On FVP Foundation models, I see this error before the model hangs: >> >> [snip] >> Starting kernel ... >> >> resetting ... >> [snip] >> >> And I see the same output on AEMv8 Base models and Juno boards, only >> they reset continuously rather than hang. >> >> I think the problem is that I see this from ARM Trusted Firmware on boot: >> >> INFO:BL31: Preparing for EL3 exit to normal world >> >> Looking at the patch, it appears to be changing everything to boot in EL2. > > > That was the case before the patch (with the removal of the EL1 boot thing) > already. Linux can't run in EL3, that's why it has to boot in EL2 (or EL1, > but that really should be limited to VMs). > Pah! I misread the patch, specifically this hunk (and the one before it, I suppose): diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index e3c9832..59adab8 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -193,7 +193,6 @@ static void do_nonsec_virt_switch(void) { smp_kick_all_cpus(); dcache_disable();/* flush cache before swtiching to EL2 */ -armv8_switch_to_el2(); } #endif That's a "-", not a "+" on the call to armv8_switch_to_el2(). Either way, all my platforms are dead with this patch. > > Alex > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
On 07/07/2016 02:16 PM, Ryan Harkin wrote: On 7 July 2016 at 07:30, Alison Wangwrote: To support loading a 32-bit OS, the execution state will change from AArch64 to AArch32 when jumping to kernel. The architecture information will be got through checking FIT image, then U-Boot will load 32-bit OS or 64-bit OS automatically. Signed-off-by: Ebony Zhu Signed-off-by: Alison Wang Signed-off-by: Chenhui Zhao Unfortunately, this patch fails to boot for me. On FVP Foundation models, I see this error before the model hangs: [snip] Starting kernel ... resetting ... [snip] And I see the same output on AEMv8 Base models and Juno boards, only they reset continuously rather than hang. I think the problem is that I see this from ARM Trusted Firmware on boot: INFO:BL31: Preparing for EL3 exit to normal world Looking at the patch, it appears to be changing everything to boot in EL2. That was the case before the patch (with the removal of the EL1 boot thing) already. Linux can't run in EL3, that's why it has to boot in EL2 (or EL1, but that really should be limited to VMs). Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
On 7 July 2016 at 07:30, Alison Wangwrote: > To support loading a 32-bit OS, the execution state will change from > AArch64 to AArch32 when jumping to kernel. > > The architecture information will be got through checking FIT image, > then U-Boot will load 32-bit OS or 64-bit OS automatically. > > Signed-off-by: Ebony Zhu > Signed-off-by: Alison Wang > Signed-off-by: Chenhui Zhao Unfortunately, this patch fails to boot for me. On FVP Foundation models, I see this error before the model hangs: [snip] Starting kernel ... resetting ... [snip] And I see the same output on AEMv8 Base models and Juno boards, only they reset continuously rather than hang. I think the problem is that I see this from ARM Trusted Firmware on boot: INFO:BL31: Preparing for EL3 exit to normal world Looking at the patch, it appears to be changing everything to boot in EL2. The title of the patch is "armv8: Support loading 32-bit OS in AArch32 execution state", which implies it only makes changes to AArch32 code execution paths, however, it is clearly changing AArch64 boot too, so I'm not happy with the title or description of the patch either. > --- > Changes in v5: > - Modified armv8_switch_to_el2(). It will always jump to ep when switching to > AArch64 or AArch32 modes. > > Changes in v4: > - Correct config ARM64_SUPPORT_AARCH32. > - Omit arch and ftaddr arguments. > - Rename "xreg5" to "tmp". > - Use xxx_RES1 to combine all RES1 fields in xxx register. > - Use an immediate cmp directly. > - Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32. > > Changes in v3: > - Comments the functions and the arguments. > - Rename the real parameters. > - Use the macros instead of the magic values. > - Remove the redundant codes. > - Clean up all of the mess in boot_jump_linux(). > - Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system doesn't > support AArch32 state. > > Changes in v2: > - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used > to switch to AArch64 EL2 or AArch32 Hyp. > - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used > to switch to AArch64 EL1 or AArch32 SVC. > > arch/arm/Kconfig| 6 +++ > arch/arm/cpu/armv8/start.S | 2 + > arch/arm/cpu/armv8/transition.S | 4 +- > arch/arm/include/asm/macro.h| 80 --- > arch/arm/include/asm/system.h | 104 > +++- > arch/arm/lib/bootm.c| 13 - > common/image-fit.c | 19 +++- > 7 files changed, 206 insertions(+), 22 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 3237a74..1b30447 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -99,6 +99,12 @@ config ENABLE_ARM_SOC_BOOT0_HOOK > ARM_SOC_BOOT0_HOOK which contains the required assembler > preprocessor code. > > +config ARM64_SUPPORT_AARCH32 > + bool "ARM64 system support AArch32 execution state" > + default y if ARM64 && !TARGET_THUNDERX_88XX > + help > + This ARM64 system supports AArch32 execution state. > + > choice > prompt "Target select" > default TARGET_HIKEY > diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S > index ab434a6..a0c55d7 100644 > --- a/arch/arm/cpu/armv8/start.S > +++ b/arch/arm/cpu/armv8/start.S > @@ -244,6 +244,8 @@ WEAK(lowlevel_init) > /* > * All slaves will enter EL2. > */ > + mov x3, lr > + ldr x4, =ES_TO_AARCH64 > bl armv8_switch_to_el2 > > #endif /* CONFIG_ARMV8_MULTIENTRY */ > diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S > index 209d5c8..62d54b3 100644 > --- a/arch/arm/cpu/armv8/transition.S > +++ b/arch/arm/cpu/armv8/transition.S > @@ -11,7 +11,7 @@ > #include > > ENTRY(armv8_switch_to_el2) > - switch_el x0, 1f, 0f, 0f > + switch_el x5, 1f, 0f, 0f > 0: ret > -1: armv8_switch_to_el2_m x0 > +1: armv8_switch_to_el2_m x3, x4, x5 > ENDPROC(armv8_switch_to_el2) > diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h > index c1b3452..5108900 100644 > --- a/arch/arm/include/asm/macro.h > +++ b/arch/arm/include/asm/macro.h > @@ -8,6 +8,9 @@ > > #ifndef __ASM_ARM_MACRO_H__ > #define __ASM_ARM_MACRO_H__ > + > +#include > + > #ifdef __ASSEMBLY__ > > /* > @@ -135,13 +138,21 @@ lr.reqx30 > #endif > .endm > > -.macro armv8_switch_to_el2_m, xreg1 > - /* 64bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1 */ > - mov \xreg1, #0x5b1 > - msr scr_el3, \xreg1 > +/* > + * Switch from EL3 to EL2 for ARMv8 > + * @ep: kernel entry point > + * @flag: The execution state flag for lower exception > + * level, ES_TO_AARCH64 or ES_TO_AARCH32 > + * @tmp:temporary register > + * > + * For loading 32-bit OS, x1 is machine nr and x2 is
Re: [U-Boot] [PATCH] armv8: Remove the codes about switching to EL1 before jumping to kernel
On 07/07/2016 08:25 AM, Alison Wang wrote: As CONFIG_ARMV8_SWITCH_TO_EL1 is not used now, this patch is to remove CONFIG_ARMV8_SWITCH_TO_EL1 and the corresponding functions. Signed-off-by: Alison WangI'll CC the maintainers for ZynqMP and Exynos as well, but from my side this patch is a great step forward. Reviewed-by: Alexander Graf --- arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 13 arch/arm/cpu/armv8/start.S | 5 +-- arch/arm/cpu/armv8/transition.S | 6 arch/arm/include/asm/macro.h | 47 arch/arm/include/asm/system.h| 1 - arch/arm/lib/bootm.c | 3 -- arch/arm/mach-exynos/soc.c | 1 - include/configs/vexpress_aemv8a.h| 1 - include/configs/xilinx_zynqmp.h | 2 -- 9 files changed, 1 insertion(+), 78 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S index 5af6b73..d3a0117 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S @@ -325,19 +325,12 @@ ENTRY(secondary_boot_func) #endif bl secondary_switch_to_el2 -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 - bl secondary_switch_to_el1 -#endif slave_cpu: wfe ldr x0, [x11] cbz x0, slave_cpu -#ifndef CONFIG_ARMV8_SWITCH_TO_EL1 mrs x1, sctlr_el2 -#else - mrs x1, sctlr_el1 -#endif tbz x1, #25, cpu_is_le rev x0, x0 /* BE to LE conversion */ cpu_is_le: @@ -350,12 +343,6 @@ ENTRY(secondary_switch_to_el2) 1:armv8_switch_to_el2_m x0 ENDPROC(secondary_switch_to_el2) -ENTRY(secondary_switch_to_el1) - switch_el x0, 0f, 1f, 0f -0: ret -1: armv8_switch_to_el1_m x0, x1 -ENDPROC(secondary_switch_to_el1) - /* Ensure that the literals used by the secondary boot code are * assembled within it (this is required so that we can protect * this area with a single memreserve region diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 670e323..ab434a6 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -242,12 +242,9 @@ WEAK(lowlevel_init) #endif /* -* All slaves will enter EL2 and optionally EL1. +* All slaves will enter EL2. */ bl armv8_switch_to_el2 -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 - bl armv8_switch_to_el1 -#endif #endif /* CONFIG_ARMV8_MULTIENTRY */ diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S index 253a39b..209d5c8 100644 --- a/arch/arm/cpu/armv8/transition.S +++ b/arch/arm/cpu/armv8/transition.S @@ -15,9 +15,3 @@ ENTRY(armv8_switch_to_el2) 0:ret 1:armv8_switch_to_el2_m x0 ENDPROC(armv8_switch_to_el2) - -ENTRY(armv8_switch_to_el1) - switch_el x0, 0f, 1f, 0f -0: ret -1: armv8_switch_to_el1_m x0, x1 -ENDPROC(armv8_switch_to_el1) diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h index 9bb0efa..c1b3452 100644 --- a/arch/arm/include/asm/macro.h +++ b/arch/arm/include/asm/macro.h @@ -167,53 +167,6 @@ lr .reqx30 eret .endm -.macro armv8_switch_to_el1_m, xreg1, xreg2 - /* Initialize Generic Timers */ - mrs \xreg1, cnthctl_el2 - orr \xreg1, \xreg1, #0x3/* Enable EL1 access to timers */ - msr cnthctl_el2, \xreg1 - msr cntvoff_el2, xzr - - /* Initilize MPID/MPIDR registers */ - mrs \xreg1, midr_el1 - mrs \xreg2, mpidr_el1 - msr vpidr_el2, \xreg1 - msr vmpidr_el2, \xreg2 - - /* Disable coprocessor traps */ - mov \xreg1, #0x33ff - msr cptr_el2, \xreg1/* Disable coprocessor traps to EL2 */ - msr hstr_el2, xzr /* Disable coprocessor traps to EL2 */ - mov \xreg1, #3 << 20 - msr cpacr_el1, \xreg1 /* Enable FP/SIMD at EL1 */ - - /* Initialize HCR_EL2 */ - mov \xreg1, #(1 << 31)/* 64bit EL1 */ - orr \xreg1, \xreg1, #(1 << 29)/* Disable HVC */ - msr hcr_el2, \xreg1 - - /* SCTLR_EL1 initialization -* -* setting RES1 bits (29,28,23,22,20,11) to 1 -* and RES0 bits (31,30,27,21,17,13,10,6) + -* UCI,EE,EOE,WXN,nTWE,nTWI,UCT,DZE,I,UMA,SED,ITD, -* CP15BEN,SA0,SA,C,A,M to 0 -*/ - mov \xreg1, #0x0800 - movk\xreg1, #0x30d0, lsl #16 - msr sctlr_el1, \xreg1 - - /* Return to the EL1_SP1 mode from EL2 */ - mov \xreg1, sp - msr sp_el1, \xreg1 /* Migrate SP */ - mrs \xreg1, vbar_el2 - msr vbar_el1, \xreg1/* Migrate VBAR */ - mov \xreg1, #0x3c5 - msr spsr_el2, \xreg1/* EL1_SP1 | D |
Re: [U-Boot] [PATCH] armv8: Remove the codes about switching to EL1 before jumping to kernel
On 7 July 2016 at 07:25, Alison Wangwrote: > As CONFIG_ARMV8_SWITCH_TO_EL1 is not used now, this patch is to remove > CONFIG_ARMV8_SWITCH_TO_EL1 and the corresponding functions. > > Signed-off-by: Alison Wang I haven't reviewed the code changes, but I have tested it and everything still works for me with this change. I tested on FVP AEMv8 Base and FVP Foundation models and Juno R0, R1 and R2 development boards; booting BusyBox, OpenEmbedded (not on R0 or R2) and Android environments (not on R1). Tested-by: Ryan Harkin > --- > arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 13 > arch/arm/cpu/armv8/start.S | 5 +-- > arch/arm/cpu/armv8/transition.S | 6 > arch/arm/include/asm/macro.h | 47 > > arch/arm/include/asm/system.h| 1 - > arch/arm/lib/bootm.c | 3 -- > arch/arm/mach-exynos/soc.c | 1 - > include/configs/vexpress_aemv8a.h| 1 - > include/configs/xilinx_zynqmp.h | 2 -- > 9 files changed, 1 insertion(+), 78 deletions(-) > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S > b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S > index 5af6b73..d3a0117 100644 > --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S > +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S > @@ -325,19 +325,12 @@ ENTRY(secondary_boot_func) > #endif > > bl secondary_switch_to_el2 > -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 > - bl secondary_switch_to_el1 > -#endif > > slave_cpu: > wfe > ldr x0, [x11] > cbz x0, slave_cpu > -#ifndef CONFIG_ARMV8_SWITCH_TO_EL1 > mrs x1, sctlr_el2 > -#else > - mrs x1, sctlr_el1 > -#endif > tbz x1, #25, cpu_is_le > rev x0, x0 /* BE to LE conversion */ > cpu_is_le: > @@ -350,12 +343,6 @@ ENTRY(secondary_switch_to_el2) > 1: armv8_switch_to_el2_m x0 > ENDPROC(secondary_switch_to_el2) > > -ENTRY(secondary_switch_to_el1) > - switch_el x0, 0f, 1f, 0f > -0: ret > -1: armv8_switch_to_el1_m x0, x1 > -ENDPROC(secondary_switch_to_el1) > - > /* Ensure that the literals used by the secondary boot code are > * assembled within it (this is required so that we can protect > * this area with a single memreserve region > diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S > index 670e323..ab434a6 100644 > --- a/arch/arm/cpu/armv8/start.S > +++ b/arch/arm/cpu/armv8/start.S > @@ -242,12 +242,9 @@ WEAK(lowlevel_init) > #endif > > /* > -* All slaves will enter EL2 and optionally EL1. > +* All slaves will enter EL2. > */ > bl armv8_switch_to_el2 > -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 > - bl armv8_switch_to_el1 > -#endif > > #endif /* CONFIG_ARMV8_MULTIENTRY */ > > diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S > index 253a39b..209d5c8 100644 > --- a/arch/arm/cpu/armv8/transition.S > +++ b/arch/arm/cpu/armv8/transition.S > @@ -15,9 +15,3 @@ ENTRY(armv8_switch_to_el2) > 0: ret > 1: armv8_switch_to_el2_m x0 > ENDPROC(armv8_switch_to_el2) > - > -ENTRY(armv8_switch_to_el1) > - switch_el x0, 0f, 1f, 0f > -0: ret > -1: armv8_switch_to_el1_m x0, x1 > -ENDPROC(armv8_switch_to_el1) > diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h > index 9bb0efa..c1b3452 100644 > --- a/arch/arm/include/asm/macro.h > +++ b/arch/arm/include/asm/macro.h > @@ -167,53 +167,6 @@ lr .reqx30 > eret > .endm > > -.macro armv8_switch_to_el1_m, xreg1, xreg2 > - /* Initialize Generic Timers */ > - mrs \xreg1, cnthctl_el2 > - orr \xreg1, \xreg1, #0x3/* Enable EL1 access to timers */ > - msr cnthctl_el2, \xreg1 > - msr cntvoff_el2, xzr > - > - /* Initilize MPID/MPIDR registers */ > - mrs \xreg1, midr_el1 > - mrs \xreg2, mpidr_el1 > - msr vpidr_el2, \xreg1 > - msr vmpidr_el2, \xreg2 > - > - /* Disable coprocessor traps */ > - mov \xreg1, #0x33ff > - msr cptr_el2, \xreg1/* Disable coprocessor traps to EL2 */ > - msr hstr_el2, xzr /* Disable coprocessor traps to EL2 */ > - mov \xreg1, #3 << 20 > - msr cpacr_el1, \xreg1 /* Enable FP/SIMD at EL1 */ > - > - /* Initialize HCR_EL2 */ > - mov \xreg1, #(1 << 31) /* 64bit EL1 */ > - orr \xreg1, \xreg1, #(1 << 29) /* Disable HVC */ > - msr hcr_el2, \xreg1 > - > - /* SCTLR_EL1 initialization > -* > -* setting RES1 bits (29,28,23,22,20,11) to 1 > -* and RES0 bits (31,30,27,21,17,13,10,6) + > -* UCI,EE,EOE,WXN,nTWE,nTWI,UCT,DZE,I,UMA,SED,ITD, > -* CP15BEN,SA0,SA,C,A,M to 0 > -*/ >
Re: [U-Boot] [PATCH 2/3] ARM: board: cm_fx6: fixup mtd partitions in the fdt
On Wed, Jun 22, 2016 at 07:17:53PM +0300, Igor Grinberg wrote: > On 06/19/2016 06:44 PM, Christopher Spinrath wrote: > > The cm-fx6 module has an on-board st,m25p compatible spi flash chip > > used for u-boot (binary & environment). Overwrite the partitions in > > the device tree by the partition table provided in the mtdparts > > environment variable, if it is set. > > > > This allows to specify a kernel independent partitioning in the > > environment and provides a convient way for the user to adapt the > > partition table. > > > > Signed-off-by: Christopher Spinrath> > --- > > board/compulab/cm_fx6/cm_fx6.c | 16 +++- > > 1 file changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c > > index 712057a..81a7ae2 100644 > > --- a/board/compulab/cm_fx6/cm_fx6.c > > +++ b/board/compulab/cm_fx6/cm_fx6.c > > [...] > > > +#ifdef CONFIG_FDT_FIXUP_PARTITIONS > > +struct node_info nodes[] = { > > + { "st,m25p",MTD_DEV_TYPE_NOR, }, > > Nikita, is this enough for all flashes we assemble on cm-fx6? Yes, CM-FX6 is using M25PX16 and SST25VF016B, both of which are supported by the m25p80.c driver. However, on the mainline branch I don't see "m25p" in the list of device ids, and IIRC the request is to favor "jedec,spi-nor" as compatible string over device specific ones. > > > +}; > > +#endif > > + > > [...] > > -- > Regards, > Igor. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: configs: cm_fx6: improve default environment
On Sun, Jun 19, 2016 at 05:44:54PM +0200, Christopher Spinrath wrote: > Currently, entire script segments have to be changed in the default > environment to change the kernel image location or to append kernel > cmdline parameters. In the later case this has to be changed for > every possible boot device. > > Introduce new variables for kernel image locations and boot device > independent kernel parameters to make it easier to change these > settings. Reviewed-by: Nikita Kiryanov> > Signed-off-by: Christopher Spinrath > --- > include/configs/cm_fx6.h | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building efi_boottime.o fails for OpenRD (kirkwood) targets
On 06.07.16 23:16, Karsten Merker wrote: > Hello, > > current u-boot master shows problems when building efi_boottime.o > for the openrd_base, openrd_client and openrd_ultimate targets > (all based on Marvell "Kirkwood" SoCs). This was discovered > during builds of the (experimental) Debian u-boot 2016.07-rc3 > package, but exactly the same problem occurs with plain upstream. > Running "make openrd_base_defconfig; make" results in the > following error: > > CC lib/efi_loader/efi_image_loader.o > CC lib/efi_loader/efi_boottime.o > {standard input}: Assembler messages: > {standard input}:1672: Error: invalid immediate for address calculation > (value = 0x000A) > make[2]: *** [lib/efi_loader/efi_boottime.o] Error 1 > scripts/Makefile.build:280: recipe for target 'lib/efi_loader/efi_boottime.o' > failed > make[1]: *** [lib/efi_loader] Error 2 > scripts/Makefile.build:425: recipe for target 'lib/efi_loader' failed > make: *** [lib] Error 2 > Makefile:1210: recipe for target 'lib' failed > > The same happens when building the openrd_client and > openrd_ultimate targets. Thanks for the report. Tom pointed me to it yesterday as well and I submitted a fix: https://patchwork.ozlabs.org/patch/644968/ Please just apply it and things should work for you. Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] armv8: Remove the codes about switching to EL1 before jumping to kernel
As CONFIG_ARMV8_SWITCH_TO_EL1 is not used now, this patch is to remove CONFIG_ARMV8_SWITCH_TO_EL1 and the corresponding functions. Signed-off-by: Alison Wang--- arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 13 arch/arm/cpu/armv8/start.S | 5 +-- arch/arm/cpu/armv8/transition.S | 6 arch/arm/include/asm/macro.h | 47 arch/arm/include/asm/system.h| 1 - arch/arm/lib/bootm.c | 3 -- arch/arm/mach-exynos/soc.c | 1 - include/configs/vexpress_aemv8a.h| 1 - include/configs/xilinx_zynqmp.h | 2 -- 9 files changed, 1 insertion(+), 78 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S index 5af6b73..d3a0117 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S @@ -325,19 +325,12 @@ ENTRY(secondary_boot_func) #endif bl secondary_switch_to_el2 -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 - bl secondary_switch_to_el1 -#endif slave_cpu: wfe ldr x0, [x11] cbz x0, slave_cpu -#ifndef CONFIG_ARMV8_SWITCH_TO_EL1 mrs x1, sctlr_el2 -#else - mrs x1, sctlr_el1 -#endif tbz x1, #25, cpu_is_le rev x0, x0 /* BE to LE conversion */ cpu_is_le: @@ -350,12 +343,6 @@ ENTRY(secondary_switch_to_el2) 1: armv8_switch_to_el2_m x0 ENDPROC(secondary_switch_to_el2) -ENTRY(secondary_switch_to_el1) - switch_el x0, 0f, 1f, 0f -0: ret -1: armv8_switch_to_el1_m x0, x1 -ENDPROC(secondary_switch_to_el1) - /* Ensure that the literals used by the secondary boot code are * assembled within it (this is required so that we can protect * this area with a single memreserve region diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 670e323..ab434a6 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -242,12 +242,9 @@ WEAK(lowlevel_init) #endif /* -* All slaves will enter EL2 and optionally EL1. +* All slaves will enter EL2. */ bl armv8_switch_to_el2 -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1 - bl armv8_switch_to_el1 -#endif #endif /* CONFIG_ARMV8_MULTIENTRY */ diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S index 253a39b..209d5c8 100644 --- a/arch/arm/cpu/armv8/transition.S +++ b/arch/arm/cpu/armv8/transition.S @@ -15,9 +15,3 @@ ENTRY(armv8_switch_to_el2) 0: ret 1: armv8_switch_to_el2_m x0 ENDPROC(armv8_switch_to_el2) - -ENTRY(armv8_switch_to_el1) - switch_el x0, 0f, 1f, 0f -0: ret -1: armv8_switch_to_el1_m x0, x1 -ENDPROC(armv8_switch_to_el1) diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h index 9bb0efa..c1b3452 100644 --- a/arch/arm/include/asm/macro.h +++ b/arch/arm/include/asm/macro.h @@ -167,53 +167,6 @@ lr .reqx30 eret .endm -.macro armv8_switch_to_el1_m, xreg1, xreg2 - /* Initialize Generic Timers */ - mrs \xreg1, cnthctl_el2 - orr \xreg1, \xreg1, #0x3/* Enable EL1 access to timers */ - msr cnthctl_el2, \xreg1 - msr cntvoff_el2, xzr - - /* Initilize MPID/MPIDR registers */ - mrs \xreg1, midr_el1 - mrs \xreg2, mpidr_el1 - msr vpidr_el2, \xreg1 - msr vmpidr_el2, \xreg2 - - /* Disable coprocessor traps */ - mov \xreg1, #0x33ff - msr cptr_el2, \xreg1/* Disable coprocessor traps to EL2 */ - msr hstr_el2, xzr /* Disable coprocessor traps to EL2 */ - mov \xreg1, #3 << 20 - msr cpacr_el1, \xreg1 /* Enable FP/SIMD at EL1 */ - - /* Initialize HCR_EL2 */ - mov \xreg1, #(1 << 31) /* 64bit EL1 */ - orr \xreg1, \xreg1, #(1 << 29) /* Disable HVC */ - msr hcr_el2, \xreg1 - - /* SCTLR_EL1 initialization -* -* setting RES1 bits (29,28,23,22,20,11) to 1 -* and RES0 bits (31,30,27,21,17,13,10,6) + -* UCI,EE,EOE,WXN,nTWE,nTWI,UCT,DZE,I,UMA,SED,ITD, -* CP15BEN,SA0,SA,C,A,M to 0 -*/ - mov \xreg1, #0x0800 - movk\xreg1, #0x30d0, lsl #16 - msr sctlr_el1, \xreg1 - - /* Return to the EL1_SP1 mode from EL2 */ - mov \xreg1, sp - msr sp_el1, \xreg1 /* Migrate SP */ - mrs \xreg1, vbar_el2 - msr vbar_el1, \xreg1/* Migrate VBAR */ - mov \xreg1, #0x3c5 - msr spsr_el2, \xreg1/* EL1_SP1 | D | A | I | F */ - msr elr_el2, lr - eret -.endm - #if defined(CONFIG_GICV3) .macro gic_wait_for_interrupt_m xreg1 0 :wfi diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h index
[U-Boot] [PATCH v5 1/2] armv8: Support loading 32-bit OS in AArch32 execution state
To support loading a 32-bit OS, the execution state will change from AArch64 to AArch32 when jumping to kernel. The architecture information will be got through checking FIT image, then U-Boot will load 32-bit OS or 64-bit OS automatically. Signed-off-by: Ebony ZhuSigned-off-by: Alison Wang Signed-off-by: Chenhui Zhao --- Changes in v5: - Modified armv8_switch_to_el2(). It will always jump to ep when switching to AArch64 or AArch32 modes. Changes in v4: - Correct config ARM64_SUPPORT_AARCH32. - Omit arch and ftaddr arguments. - Rename "xreg5" to "tmp". - Use xxx_RES1 to combine all RES1 fields in xxx register. - Use an immediate cmp directly. - Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32. Changes in v3: - Comments the functions and the arguments. - Rename the real parameters. - Use the macros instead of the magic values. - Remove the redundant codes. - Clean up all of the mess in boot_jump_linux(). - Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system doesn't support AArch32 state. Changes in v2: - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used to switch to AArch64 EL2 or AArch32 Hyp. - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used to switch to AArch64 EL1 or AArch32 SVC. arch/arm/Kconfig| 6 +++ arch/arm/cpu/armv8/start.S | 2 + arch/arm/cpu/armv8/transition.S | 4 +- arch/arm/include/asm/macro.h| 80 --- arch/arm/include/asm/system.h | 104 +++- arch/arm/lib/bootm.c| 13 - common/image-fit.c | 19 +++- 7 files changed, 206 insertions(+), 22 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3237a74..1b30447 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -99,6 +99,12 @@ config ENABLE_ARM_SOC_BOOT0_HOOK ARM_SOC_BOOT0_HOOK which contains the required assembler preprocessor code. +config ARM64_SUPPORT_AARCH32 + bool "ARM64 system support AArch32 execution state" + default y if ARM64 && !TARGET_THUNDERX_88XX + help + This ARM64 system supports AArch32 execution state. + choice prompt "Target select" default TARGET_HIKEY diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index ab434a6..a0c55d7 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -244,6 +244,8 @@ WEAK(lowlevel_init) /* * All slaves will enter EL2. */ + mov x3, lr + ldr x4, =ES_TO_AARCH64 bl armv8_switch_to_el2 #endif /* CONFIG_ARMV8_MULTIENTRY */ diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S index 209d5c8..62d54b3 100644 --- a/arch/arm/cpu/armv8/transition.S +++ b/arch/arm/cpu/armv8/transition.S @@ -11,7 +11,7 @@ #include ENTRY(armv8_switch_to_el2) - switch_el x0, 1f, 0f, 0f + switch_el x5, 1f, 0f, 0f 0: ret -1: armv8_switch_to_el2_m x0 +1: armv8_switch_to_el2_m x3, x4, x5 ENDPROC(armv8_switch_to_el2) diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h index c1b3452..5108900 100644 --- a/arch/arm/include/asm/macro.h +++ b/arch/arm/include/asm/macro.h @@ -8,6 +8,9 @@ #ifndef __ASM_ARM_MACRO_H__ #define __ASM_ARM_MACRO_H__ + +#include + #ifdef __ASSEMBLY__ /* @@ -135,13 +138,21 @@ lr.reqx30 #endif .endm -.macro armv8_switch_to_el2_m, xreg1 - /* 64bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1 */ - mov \xreg1, #0x5b1 - msr scr_el3, \xreg1 +/* + * Switch from EL3 to EL2 for ARMv8 + * @ep: kernel entry point + * @flag: The execution state flag for lower exception + * level, ES_TO_AARCH64 or ES_TO_AARCH32 + * @tmp:temporary register + * + * For loading 32-bit OS, x1 is machine nr and x2 is ftaddr. + * For loading 64-bit OS, x0 is physical address to the FDT blob. + * They will be passed to the guest. + */ +.macro armv8_switch_to_el2_m, ep, flag, tmp msr cptr_el3, xzr /* Disable coprocessor traps to EL3 */ - mov \xreg1, #0x33ff - msr cptr_el2, \xreg1/* Disable coprocessor traps to EL2 */ + mov \tmp, #CPTR_EL2_RES1 + msr cptr_el2, \tmp /* Disable coprocessor traps to EL2 */ /* Initialize Generic Timers */ msr cntvoff_el2, xzr @@ -152,18 +163,55 @@ lr.reqx30 * and RES0 bits (31,30,27,26,24,21,20,17,15-13,10-6) + * EE,WXN,I,SA,C,A,M to 0 */ - mov \xreg1, #0x0830 - movk\xreg1, #0x30C5, lsl #16 - msr sctlr_el2, \xreg1 + ldr \tmp, =(SCTLR_EL2_RES1 | SCTLR_EL2_EE_LE |\ + SCTLR_EL2_WXN_DIS | SCTLR_EL2_ICACHE_DIS |\ + SCTLR_EL2_SA_DIS | SCTLR_EL2_DCACHE_DIS |\ + SCTLR_EL2_ALIGN_DIS |
[U-Boot] [PATCH v5 2/2] armv8: fsl-layerscape: SMP support for loading 32-bit OS
Spin-table method is used for secondary cores to load 32-bit OS. The architecture information will be got through checking FIT image and saved in the os_arch element of spin-table, then the secondary cores will check os_arch and jump to 32-bit OS or 64-bit OS automatically. Signed-off-by: Alison WangSigned-off-by: Chenhui Zhao --- Changes in v5: - Make secondary_switch_to_el2() always jump to ep when switching to AArch64 or AArch32 modes. Changes in v4: - Omit arch and ftaddr arguments. Changes in v3: - Adjust the arguments for armv8_switch_to_el2_m and armv8_switch_to_el1_m. Changes in v2: - Support to call armv8_switch_to_el2_m and armv8_switch_to_el1_m. arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 23 ++- arch/arm/cpu/armv8/fsl-layerscape/mp.c| 10 ++ arch/arm/include/asm/arch-fsl-layerscape/mp.h | 6 ++ arch/arm/lib/bootm.c | 6 ++ 4 files changed, 40 insertions(+), 5 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S index d3a0117..9535350 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S @@ -13,6 +13,8 @@ #ifdef CONFIG_MP #include #endif +#include +#include ENTRY(lowlevel_init) mov x29, lr /* Save LR */ @@ -324,8 +326,6 @@ ENTRY(secondary_boot_func) gic_wait_for_interrupt_m x0, w1 #endif - bl secondary_switch_to_el2 - slave_cpu: wfe ldr x0, [x11] @@ -334,13 +334,26 @@ slave_cpu: tbz x1, #25, cpu_is_le rev x0, x0 /* BE to LE conversion */ cpu_is_le: - br x0 /* branch to the given address */ + + ldr x5, [x11, #24] + ldr x6, =IH_ARCH_DEFAULT + cmp x6, x5 + b.eq1f + + ldr x3, [x11] + ldr x4, =ES_TO_AARCH32 + bl secondary_switch_to_el2 + +1: + ldr x3, [x11] + ldr x4, =ES_TO_AARCH64 + bl secondary_switch_to_el2 ENDPROC(secondary_boot_func) ENTRY(secondary_switch_to_el2) - switch_el x0, 1f, 0f, 0f + switch_el x5, 1f, 0f, 0f 0: ret -1: armv8_switch_to_el2_m x0 +1: armv8_switch_to_el2_m x3, x4, x5 ENDPROC(secondary_switch_to_el2) /* Ensure that the literals used by the secondary boot code are diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c b/arch/arm/cpu/armv8/fsl-layerscape/mp.c index df7ffb8..dd91550 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c @@ -22,6 +22,16 @@ phys_addr_t determine_mp_bootpg(void) return (phys_addr_t)_boot_code; } +void update_os_arch_secondary_cores(uint8_t os_arch) +{ + u64 *table = get_spin_tbl_addr(); + int i; + + for (i = 1; i < CONFIG_MAX_CPUS; i++) + table[i * WORDS_PER_SPIN_TABLE_ENTRY + + SPIN_TABLE_ELEM_OS_ARCH_IDX] = os_arch; +} + int fsl_layerscape_wake_seconday_cores(void) { struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR); diff --git a/arch/arm/include/asm/arch-fsl-layerscape/mp.h b/arch/arm/include/asm/arch-fsl-layerscape/mp.h index e46e076..55f0e0c 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/mp.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/mp.h @@ -13,6 +13,7 @@ * uint64_t entry_addr; * uint64_t status; * uint64_t lpid; +* uint64_t os_arch; * }; * we pad this struct to 64 bytes so each entry is in its own cacheline * the actual spin table is an array of these structures @@ -20,6 +21,7 @@ #define SPIN_TABLE_ELEM_ENTRY_ADDR_IDX 0 #define SPIN_TABLE_ELEM_STATUS_IDX 1 #define SPIN_TABLE_ELEM_LPID_IDX 2 +#define SPIN_TABLE_ELEM_OS_ARCH_IDX3 #define WORDS_PER_SPIN_TABLE_ENTRY 8 /* pad to 64 bytes */ #define SPIN_TABLE_ELEM_SIZE 64 @@ -35,4 +37,8 @@ phys_addr_t determine_mp_bootpg(void); void secondary_boot_func(void); int is_core_online(u64 cpu_id); #endif + +#define IH_ARCH_ARM2 /* ARM */ +#define IH_ARCH_ARM64 22 /* ARM64 */ + #endif /* _FSL_LAYERSCAPE_MP_H */ diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index 59adab8..56052c1 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -264,6 +264,10 @@ bool armv7_boot_nonsec(void) } #endif +__weak void update_os_arch_secondary_cores(uint8_t os_arch) +{ +} + /* Subcommand: GO */ static void boot_jump_linux(bootm_headers_t *images, int flag) { @@ -284,6 +288,8 @@ static void boot_jump_linux(bootm_headers_t *images, int flag) if (!fake) { do_nonsec_virt_switch(); + update_os_arch_secondary_cores(images->os.arch); + if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) && (images->os.arch == IH_ARCH_ARM))
[U-Boot] [PATCH v5 0/2] armv8: Support loading 32-bit OS in AArch32 execution state
This series is to support loading a 32-bit OS, the execution state will change from AArch64 to AArch32 when jumping to kernel. The architecture information will be got through checking FIT image, then U-Boot will load 32-bit OS or 64-bit OS automatically. Spin-table method is used for secondary cores to load 32-bit OS. The architecture information will be got through checking FIT image and saved in the os_arch element of spin-table, then the secondary cores will check os_arch and jump to 32-bit OS or 64-bit OS automatically. --- Changes in v5: - Modified armv8_switch_to_el2(). It will always jump to ep when switching to AArch64 or AArch32 modes. - Make secondary_switch_to_el2() always jump to ep when switching to AArch64 or AArch32 modes. Changes in v4: - Correct config ARM64_SUPPORT_AARCH32. - Omit arch and ftaddr arguments. - Rename "xreg5" to "tmp". - Use xxx_RES1 to combine all RES1 fields in xxx register. - Use an immediate cmp directly. - Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32. Changes in v3: - Comments the functions and the arguments. - Rename the real parameters. - Use the macros instead of the magic values. - Remove the redundant codes. - Clean up all of the mess in boot_jump_linux(). - Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system doesn't support AArch32 state. - Adjust the arguments for armv8_switch_to_el2_m and armv8_switch_to_el1_m. Changes in v2: - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used to switch to AArch64 EL2 or AArch32 Hyp. - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used to switch to AArch64 EL1 or AArch32 SVC. - Support to call armv8_switch_to_el2_m and armv8_switch_to_el1_m. Alison Wang (2): armv8: Support loading 32-bit OS in AArch32 execution state armv8: fsl-layerscape: SMP support for loading 32-bit OS arch/arm/Kconfig | 6 ++ arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 23 +++- arch/arm/cpu/armv8/fsl-layerscape/mp.c| 10 + arch/arm/cpu/armv8/start.S| 1 + arch/arm/cpu/armv8/transition.S | 4 ++-- arch/arm/include/asm/arch-fsl-layerscape/mp.h | 6 ++ arch/arm/include/asm/macro.h | 80 +-- arch/arm/include/asm/system.h | 104 +++- arch/arm/lib/bootm.c | 19 ++-- common/image-fit.c| 19 +++- 10 files changed, 245 insertions(+), 27 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot