Re: [U-Boot] [linux-sunxi] Re: [PATCH v2] sunxi: add NanoPi NEO Air defconfig
On Sat, Feb 25, 2017 at 4:26 PM, Jagan Teki wrote: > On Mon, Feb 13, 2017 at 1:22 PM, Maxime Ripard > wrote: >> On Sun, Feb 12, 2017 at 04:21:40PM +0100, Jelle van der Waa wrote: >>> Add support for the NanoPi NEO Air H3 board from friendlyarm.com . This >>> board contains WiFi, Bluetooth, 8GB eMMC storage and 512 MB DDR3 ram. >>> >>> Signed-off-by: Jelle van der Waa >> >> Acked-by: Maxime Ripard > > Fixed, error while 'git am' and > > Applied to u-boot-sunxi/master This is missing an entry to boards/sunxi/MAINTAINERS though. Jelle, can you send another patch adding yourself as a board maintainer? ChenYu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Mailing list moved
Hi, On Mon, Feb 27, 2017 at 9:33 PM, Wolfgang Denk wrote: > Hi all, > > hopefully unnoticed by anyone, we moved the mailing list to a new > (faster, bigger, better) server. As far as we can tell, operation > continues unchanged except for the fact that, when accessing the web > interface for administration tasks, the "mailman" part of the URL > was removed (but I think this affects only the moderators, and > nobody else). > > There is a slight chance that one or two messages did not make it > into the list archive. If you notice any such problem, please let > me know which message this was (ideally by telling me the respective > message-id), and we will take care of it. > > Also, if you notice any problems, please do not hesitate to contact > me. My browsers are now complaining about https://lists.denx.de/ using a self-signed certificate. And using HTTP gets automatically redirected to HTTPS. ChenYu > > Thanks! > > > Best regards, > > Wolfgang Denk > > -- > Meet DENX at the Embedded World Trade Show > 14 Mar - 16 Mar 2017, Nuremberg Trade Fair Centre, Hall 4, Booth 581 > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > A supercomputer is a machine that runs an endless loop in 2 seconds. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/12] sunxi: Enable SPL for R40
Now that we can do DRAM initialization for the R40, we can enable SPL support for it. Signed-off-by: Chen-Yu Tsai --- board/sunxi/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 9854ef0a599e..3df9f8197c57 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -136,6 +136,7 @@ config MACH_SUN8I_R40 bool "sun8i (Allwinner R40)" select CPU_V7 select SUNXI_GEN_SUN6I + select SUPPORT_SPL config MACH_SUN9I bool "sun9i (Allwinner A80)" -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 12/12] sunxi: Add support for Bananapi M2 Ultra
The Bananapi M2 Ultra is the first publicly available development board
featuring the R40 SoC.
This patch add barebone dtsi/dts files for the R40 and Bananapi M2 Ultra,
as well as a defconfig for it.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/dts/Makefile| 2 +
arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts | 69 ++
arch/arm/dts/sun8i-r40.dtsi | 183 +++
board/sunxi/MAINTAINERS | 6 +
configs/Bananapi_M2_Ultra_defconfig | 15 +++
5 files changed, 275 insertions(+)
create mode 100644 arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
create mode 100644 arch/arm/dts/sun8i-r40.dtsi
create mode 100644 configs/Bananapi_M2_Ultra_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eeaa9e028457..683cbdca6238 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -295,6 +295,8 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
sun8i-h3-orangepi-plus2e.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-nanopi-neo-air.dtb
+dtb-$(CONFIG_MACH_SUN8I_R40) += \
+ sun8i-r40-bananapi-m2-ultra.dtb
dtb-$(CONFIG_MACH_SUN50I_H5) += \
sun50i-h5-orangepi-pc2.dtb
dtb-$(CONFIG_MACH_SUN50I) += \
diff --git a/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
b/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
new file mode 100644
index ..ab471ab0bffb
--- /dev/null
+++ b/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2016 Chen-Yu Tsai
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-r40.dtsi"
+
+/ {
+ model = "Banana Pi BPI-M2-Ultra";
+ compatible = "sinovoip,bpi-m2-ultra", "allwinner,sun8i-r40";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pb_pins>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/sun8i-r40.dtsi b/arch/arm/dts/sun8i-r40.dtsi
new file mode 100644
index ..48ec2e855a2c
--- /dev/null
+++ b/arch/arm/dts/sun8i-r40.dtsi
@@ -0,0 +1,183 @@
+/*
+ * Copyright 2016 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU G
[U-Boot] [PATCH 10/12] sunxi: Fix CPUCFG address for R40
The R40 has the CPUCFG block at the same address as the A20. Fix it. Signed-off-by: Chen-Yu Tsai --- arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h index ea672fe8449a..88c3f138173f 100644 --- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h @@ -108,7 +108,7 @@ defined(CONFIG_MACH_SUN50I) #define SUNXI_TP_BASE 0x01c25000 #define SUNXI_PMU_BASE 0x01c25400 -#ifdef CONFIG_MACH_SUN7I +#if defined CONFIG_MACH_SUN7I || defined CONFIG_MACH_SUN8I_R40 #define SUNXI_CPUCFG_BASE 0x01c25c00 #endif @@ -167,7 +167,9 @@ defined(CONFIG_MACH_SUN50I) #define SUNXI_RTC_BASE 0x01f0 #define SUNXI_PRCM_BASE0x01f01400 -#if defined CONFIG_SUNXI_GEN_SUN6I && !defined CONFIG_MACH_SUN8I_A83T +#if defined CONFIG_SUNXI_GEN_SUN6I && \ +!defined CONFIG_MACH_SUN8I_A83T && \ +!defined CONFIG_MACH_SUN8I_R40 #define SUNXI_CPUCFG_BASE 0x01f01c00 #endif -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 00/12] sunxi: Add support for R40 SoC
Hi everyone,
This series adds support for the new R40 SoC. The R40 is marketed as the
successor to the A20. It is mostly pin compatible (in software) with the
A20. It has a somewhat similar memory layout, a hybrid of A20 and newer
sun6i gen.. Like the A20, it does not have a PRCM block.
This series makes checkpatch throw out a lot of errors, mostly "no spaces
at the start of a line" or "space prohibited after that open parenthesis
'('", but fixing them does not improve the readability of the code.
Patch 1 introduces the R40 to U-boot, by adding a Kconfig symbol, fixing
up any SoC depends on in Kconfig to disable unsupported features, and
reworking board level pinmuxes.
Patch 2 enables using the AXP221s PMIC in I2C mode. The R40 is paired
with this PMIC, but it does not have a P2WI controller.
Patch 3 fixes the watchdog reset function for R40. The R40's watchdog
register layout is like the A10/A20.
Patch 4 adds mmc pinmux settings for R40.
Patch 5 fixes the PLL lock settings for the R40. The R40's CCU has a
new mode for PLL lock, which can be configured and also switched back
to the old mode. Here we just use the old mode, which is the same as
the other sun6i gen. SoCs.
Patch 6 provides some default DRAM settings for the R40. These were
taken from the Bananapi M2 Ultra, the only R40 board available.
Patch 7 adds the compatible string for the R40 PIO. It is mostly
compatible with the A20, with a few functions gone, and a few new
ones.
Patch 8 adds DRAM initialization support for the R40. The DRAM
controller is very similar to the A64 and H5, however the A15 line
and CSC1 line are muxed on the same pin. Also the PIR_QSGATE bit
must not be set, or DRAM init fails.
Patch 9 enables SPL for R40.
Patch 10 fixes the address of the CPUCFG block on the R40. It is
the same as on the A20.
Patch 11 adds a PSCI implementation for the R40. As the register
layout is slightly erratic, we just use a macro for the ones that
can't fit into the cpucfg register definition structure.
Patch 12 adds a board dts and defconfig for the Bananapi M2 Ultra.
Please have a look.
Regards
ChenYu
Chen-Yu Tsai (12):
sunxi: Add initial support for R40
sunxi: Enable AXP221s in I2C mode with the R40 SoC
sunxi: Fix watchdog reset function for R40
sunxi: Add mmc[1-3] pinmux settings for R40
sunxi: Set PLL lock enable bits for R40
sunxi: Provide defaults for R40 DRAM settings
gpio: sunxi: Add compatible string for R40 PIO
sunxi: Use H3/A64 DRAM initialization code for R40
sunxi: Enable SPL for R40
sunxi: Fix CPUCFG address for R40
sunxi: Add PSCI support for R40
sunxi: Add support for Bananapi M2 Ultra
arch/arm/cpu/armv7/sunxi/psci.c | 35 -
arch/arm/dts/Makefile | 2 +
arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts| 69 +
arch/arm/dts/sun8i-r40.dtsi | 183
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 2 +
arch/arm/include/asm/arch-sunxi/cpu.h | 1 +
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 6 +-
arch/arm/include/asm/arch-sunxi/dram.h | 4 +-
arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h | 20 ++-
arch/arm/include/asm/arch-sunxi/timer.h | 5 +-
arch/arm/include/asm/arch-sunxi/watchdog.h | 5 +-
arch/arm/mach-sunxi/Makefile| 1 +
arch/arm/mach-sunxi/board.c | 15 +-
arch/arm/mach-sunxi/clock_sun6i.c | 9 +-
arch/arm/mach-sunxi/cpu_info.c | 2 +
arch/arm/mach-sunxi/dram_sun8i_h3.c | 121 ++--
arch/arm/mach-sunxi/pmic_bus.c | 7 +
board/sunxi/Kconfig | 18 ++-
board/sunxi/MAINTAINERS | 6 +
board/sunxi/board.c | 36 -
configs/Bananapi_M2_Ultra_defconfig | 15 ++
drivers/gpio/sunxi_gpio.c | 1 +
drivers/power/Kconfig | 16 ++-
23 files changed, 530 insertions(+), 49 deletions(-)
create mode 100644 arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
create mode 100644 arch/arm/dts/sun8i-r40.dtsi
create mode 100644 configs/Bananapi_M2_Ultra_defconfig
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 11/12] sunxi: Add PSCI support for R40
The R40's CPU controls are a combination of sun6i and sun7i.
All controls are in the CPUCFG block, and it seems the R40 does not
have a PRCM block. The core reset, power gating and clamp controls
are grouped like sun6i.
Last, the R40 does not have a secure SRAM block.
This patch adds a PSCI implementation for CPU bring-up and hotplug
for the R40.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/cpu/armv7/sunxi/psci.c | 35 ---
board/sunxi/Kconfig | 3 +++
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index 104dc909bc53..b3a34de1aafe 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -27,6 +27,17 @@
#defineGICD_BASE (SUNXI_GIC400_BASE + GIC_DIST_OFFSET)
#defineGICC_BASE (SUNXI_GIC400_BASE + GIC_CPU_OFFSET_A15)
+/*
+ * R40 is different from other single cluster SoCs.
+ *
+ * The power clamps are located in the unused space after the per-core
+ * reset controls for core 3. The secondary core entry address register
+ * is in the SRAM controller address range.
+ */
+#define SUN8I_R40_PWROFF (0x110)
+#define SUN8I_R40_PWR_CLAMP(cpu) (0x120 + (cpu) * 0x4)
+#define SUN8I_R40_SRAMC_SOFT_ENTRY_REG0(0xbc)
+
static void __secure cp15_write_cntp_tval(u32 tval)
{
asm volatile ("mcr p15, 0, %0, c14, c2, 0" : : "r" (tval));
@@ -68,7 +79,8 @@ static void __secure __mdelay(u32 ms)
static void __secure clamp_release(u32 __maybe_unused *clamp)
{
#if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN7I) || \
- defined(CONFIG_MACH_SUN8I_H3)
+ defined(CONFIG_MACH_SUN8I_H3) || \
+ defined(CONFIG_MACH_SUN8I_R40)
u32 tmp = 0x1ff;
do {
tmp >>= 1;
@@ -82,7 +94,8 @@ static void __secure clamp_release(u32 __maybe_unused *clamp)
static void __secure clamp_set(u32 __maybe_unused *clamp)
{
#if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN7I) || \
- defined(CONFIG_MACH_SUN8I_H3)
+ defined(CONFIG_MACH_SUN8I_H3) || \
+ defined(CONFIG_MACH_SUN8I_R40)
writel(0xff, clamp);
#endif
}
@@ -115,7 +128,17 @@ static void __secure sunxi_cpu_set_power(int
__always_unused cpu, bool on)
sunxi_power_switch(&cpucfg->cpu1_pwr_clamp, &cpucfg->cpu1_pwroff,
on, 0);
}
-#else /* ! CONFIG_MACH_SUN7I */
+#elif defined CONFIG_MACH_SUN8I_R40
+static void __secure sunxi_cpu_set_power(int cpu, bool on)
+{
+ struct sunxi_cpucfg_reg *cpucfg =
+ (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
+
+ sunxi_power_switch((void *)cpucfg + SUN8I_R40_PWR_CLAMP(cpu),
+ (void *)cpucfg + SUN8I_R40_PWROFF,
+ on, 0);
+}
+#else /* ! CONFIG_MACH_SUN7I && ! CONFIG_MACH_SUN8I_R40 */
static void __secure sunxi_cpu_set_power(int cpu, bool on)
{
struct sunxi_prcm_reg *prcm =
@@ -213,7 +236,13 @@ int __secure psci_cpu_on(u32 __always_unused unused, u32
mpidr, u32 pc)
psci_save_target_pc(cpu, pc);
/* Set secondary core power on PC */
+#ifdef CONFIG_MACH_SUN8I_R40
+ /* secondary core entry address is programmed differently */
+ writel((u32)&psci_cpu_entry,
+ SUNXI_SRAMC_BASE + SUN8I_R40_SRAMC_SOFT_ENTRY_REG0);
+#else
writel((u32)&psci_cpu_entry, &cpucfg->priv0);
+#endif
/* Assert reset on target CPU */
writel(0, &cpucfg->cpu[cpu].rst);
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 3df9f8197c57..1967625f7c4f 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -135,6 +135,9 @@ config MACH_SUN8I_H3
config MACH_SUN8I_R40
bool "sun8i (Allwinner R40)"
select CPU_V7
+ select CPU_V7_HAS_NONSEC
+ select CPU_V7_HAS_VIRT
+ select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 05/12] sunxi: Set PLL lock enable bits for R40
According to the BSP released by Banana Pi, the R40 (sun8iw11p1) has
an extra "PLL lock control" register in the CCU, which controls whether
the individual PLL lock status bits in each PLL's control register work
or not.
This patch enables it for all the PLLs.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 2 ++
arch/arm/mach-sunxi/clock_sun6i.c | 5 +
2 files changed, 7 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index 1bfb48bd52df..1aefd5a64c1f 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -142,6 +142,8 @@ struct sunxi_ccm_reg {
u32 apb2_reset_cfg; /* 0x2d8 APB2 Reset config */
u32 reserved25[5];
u32 ccu_sec_switch; /* 0x2f0 CCU Security Switch, H3 only */
+ u32 reserved26[11];
+ u32 pll_lock_ctrl; /* 0x320 PLL lock control, R40 only */
};
/* apb2 bit field */
diff --git a/arch/arm/mach-sunxi/clock_sun6i.c
b/arch/arm/mach-sunxi/clock_sun6i.c
index 4762fbf0c3f0..3c8c53fcf76b 100644
--- a/arch/arm/mach-sunxi/clock_sun6i.c
+++ b/arch/arm/mach-sunxi/clock_sun6i.c
@@ -35,6 +35,11 @@ void clock_init_safe(void)
clrbits_le32(&prcm->pll_ctrl1, PRCM_PLL_CTRL_LDO_KEY_MASK);
#endif
+#ifdef CONFIG_MACH_SUN8I_R40
+ /* Set PLL lock enable bits and switch to old lock mode */
+ writel(GENMASK(12, 0), &ccm->pll_lock_ctrl);
+#endif
+
clock_set_pll1(40800);
writel(PLL6_CFG_DEFAULT, &ccm->pll6_cfg);
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 06/12] sunxi: Provide defaults for R40 DRAM settings
These values were taken from the Banana Pi M2 Ultra fex file found in the released vendor BSP. This is the only publicly available R40 device at the time of this writing. Signed-off-by: Chen-Yu Tsai --- board/sunxi/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index e89ddf626289..9854ef0a599e 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -197,6 +197,7 @@ config DRAM_TYPE config DRAM_CLK int "sunxi dram clock speed" default 792 if MACH_SUN9I + default 648 if MACH_SUN8I_R40 default 312 if MACH_SUN6I || MACH_SUN8I default 360 if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I default 672 if MACH_SUN50I @@ -218,6 +219,7 @@ config DRAM_ZQ int "sunxi dram zq value" default 123 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN8I default 127 if MACH_SUN7I + default 3881979 if MACH_SUN8I_R40 default 4145117 if MACH_SUN9I default 3881915 if MACH_SUN50I ---help--- @@ -227,6 +229,7 @@ config DRAM_ODT_EN bool "sunxi dram odt enable" default n if !MACH_SUN8I_A23 default y if MACH_SUN8I_A23 + default y if MACH_SUN8I_R40 default y if MACH_SUN50I ---help--- Select this to enable dram odt (on die termination). -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 01/12] sunxi: Add initial support for R40
The R40 is the successor to the A20. It is a hybrid of the A20, A33
and the H3.
The R40's PIO controller is compatible with the A20,
Reuse the A20 UART and I2C muxing code by adding the R40's macro.
The display pipeline is the newer DE 2.0 variant.
Block enabling video on R40 for now.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/mach-sunxi/board.c| 10 +++---
arch/arm/mach-sunxi/cpu_info.c | 2 ++
board/sunxi/Kconfig| 9 +++--
board/sunxi/board.c| 19 ++-
4 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 5e03d039433a..5a74c9717d84 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -69,12 +69,14 @@ struct mm_region *mem_map = sunxi_mem_map;
static int gpio_init(void)
{
#if CONFIG_CONS_INDEX == 1 && defined(CONFIG_UART0_PORT_F)
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I)
+#if defined(CONFIG_MACH_SUN4I) || \
+defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40)
/* disable GPB22,23 as uart0 tx,rx to avoid conflict */
sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUNXI_GPIO_INPUT);
sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUNXI_GPIO_INPUT);
#endif
-#if defined(CONFIG_MACH_SUN8I)
+#if defined(CONFIG_MACH_SUN8I) && !defined(CONFIG_MACH_SUN8I_R40)
sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUN8I_GPF_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUN8I_GPF_UART0);
#else
@@ -82,7 +84,9 @@ static int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUNXI_GPF_UART0);
#endif
sunxi_gpio_set_pull(SUNXI_GPF(4), 1);
-#elif CONFIG_CONS_INDEX == 1 && (defined(CONFIG_MACH_SUN4I) ||
defined(CONFIG_MACH_SUN7I))
+#elif CONFIG_CONS_INDEX == 1 && (defined(CONFIG_MACH_SUN4I) || \
+defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40))
sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUN4I_GPB_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUN4I_GPB_UART0);
sunxi_gpio_set_pull(SUNXI_GPB(23), SUNXI_GPIO_PULL_UP);
diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
index 85633ccec216..7851de299ab5 100644
--- a/arch/arm/mach-sunxi/cpu_info.c
+++ b/arch/arm/mach-sunxi/cpu_info.c
@@ -87,6 +87,8 @@ int print_cpuinfo(void)
printf("CPU: Allwinner A83T (SUN8I %04x)\n", sunxi_get_sram_id());
#elif defined CONFIG_MACH_SUN8I_H3
printf("CPU: Allwinner H3 (SUN8I %04x)\n", sunxi_get_sram_id());
+#elif defined CONFIG_MACH_SUN8I_R40
+ printf("CPU: Allwinner R40 (SUN8I %04x)\n", sunxi_get_sram_id());
#elif defined CONFIG_MACH_SUN9I
puts("CPU: Allwinner A80 (SUN9I)\n");
#elif defined CONFIG_MACH_SUN50I
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 3e0e2624737e..8e8b9cd0d5fd 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -132,6 +132,11 @@ config MACH_SUN8I_H3
select MACH_SUNXI_H3_H5
select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT
+config MACH_SUN8I_R40
+ bool "sun8i (Allwinner R40)"
+ select CPU_V7
+ select SUNXI_GEN_SUN6I
+
config MACH_SUN9I
bool "sun9i (Allwinner A80)"
select CPU_V7
@@ -157,7 +162,7 @@ endchoice
# The sun8i SoCs share a lot, this helps to avoid a lot of "if A23 || A33"
config MACH_SUN8I
bool
- default y if MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUNXI_H3_H5 ||
MACH_SUN8I_A83T
+ default y if MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUNXI_H3_H5 ||
MACH_SUN8I_A83T || MACH_SUN8I_R40
config RESERVE_ALLWINNER_BOOT0_HEADER
bool "reserve space for Allwinner boot0 header"
@@ -510,7 +515,7 @@ config AXP_GPIO
config VIDEO
bool "Enable graphical uboot console on HDMI, LCD or VGA"
- depends on !MACH_SUN8I_A83T && !MACH_SUNXI_H3_H5 && !MACH_SUN9I &&
!MACH_SUN50I
+ depends on !MACH_SUN8I_A83T && !MACH_SUNXI_H3_H5 && !MACH_SUN8I_R40 &&
!MACH_SUN9I && !MACH_SUN50I
default y
---help---
Say Y here to add support for using a cfb console on the HDMI, LCD
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index b9660128e5e7..495cb591a9fb 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -394,7 +394,10 @@ int board_mmc_init(bd_t *bis)
void i2c_init_board(void)
{
#ifdef CONFIG_I2C0_ENABLE
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN5I) ||
defined(CONFIG_MACH_SUN7I)
+#if defined(CONFIG_MACH_SUN4I) || \
+defined(CONFIG_MACH_SUN5I) || \
+defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40)
sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUN4I_GPB_TWI0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUN4I_GPB_TWI0);
clock_twi_onoff(0, 1);
@@ -410,7 +413,9 @@ void i2c_init_board(void)
#endif
#ifdef CONFIG_I2C1_ENABLE
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I)
+#if defined(CONFIG_MACH_SUN4I) || \
+defined(CONFIG_MACH_SUN7
[U-Boot] [PATCH 08/12] sunxi: Use H3/A64 DRAM initialization code for R40
The R40 seems to have a variant of the memory controller found in
the H3 and A64 SoCs. Adapt the code for use on the R40. The changes
are based on released DRAM code and comparing register dumps from
boot0.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/include/asm/arch-sunxi/cpu.h | 1 +
arch/arm/include/asm/arch-sunxi/dram.h | 4 +-
arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h | 20 +++-
arch/arm/mach-sunxi/Makefile| 1 +
arch/arm/mach-sunxi/clock_sun6i.c | 4 +-
arch/arm/mach-sunxi/dram_sun8i_h3.c | 121 +---
6 files changed, 133 insertions(+), 18 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
b/arch/arm/include/asm/arch-sunxi/cpu.h
index e8e670e7e903..caec86526417 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu.h
@@ -16,5 +16,6 @@
#define SOCID_A64 0x1689
#define SOCID_H3 0x1680
#define SOCID_H5 0x1718
+#define SOCID_R40 0x1701
#endif /* _SUNXI_CPU_H */
diff --git a/arch/arm/include/asm/arch-sunxi/dram.h
b/arch/arm/include/asm/arch-sunxi/dram.h
index 1dc82205b7df..f452f889f928 100644
--- a/arch/arm/include/asm/arch-sunxi/dram.h
+++ b/arch/arm/include/asm/arch-sunxi/dram.h
@@ -24,7 +24,9 @@
#include
#elif defined(CONFIG_MACH_SUN8I_A83T)
#include
-#elif defined(CONFIG_MACH_SUNXI_H3_H5) || defined(CONFIG_MACH_SUN50I)
+#elif defined(CONFIG_MACH_SUNXI_H3_H5) || \
+ defined(CONFIG_MACH_SUN8I_R40) || \
+ defined(CONFIG_MACH_SUN50I)
#include
#elif defined(CONFIG_MACH_SUN9I)
#include
diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
index 25d07d9863c9..2770986b613f 100644
--- a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
+++ b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
@@ -15,7 +15,8 @@
struct sunxi_mctl_com_reg {
u32 cr; /* 0x00 control register */
- u8 res0[0x8]; /* 0x04 */
+ u32 cr_r1; /* 0x04 rank 1 control register (R40 only) */
+ u8 res0[0x4]; /* 0x08 */
u32 tmr;/* 0x0c (unused on H3) */
u32 mcr[16][2]; /* 0x10 */
u32 bwcr; /* 0x90 bandwidth control register */
@@ -63,6 +64,17 @@ struct sunxi_mctl_com_reg {
#define MCTL_CR_DUAL_RANK (0x1 << 0)
#define MCTL_CR_SINGLE_RANK(0x0 << 0)
+/*
+ * CR_R1 is a register found in the R40's DRAM controller. It sets various
+ * parameters for rank 1. Bits [11:0] have the same meaning as the bits in
+ * MCTL_CR, but they apply to rank 1 only. This implies we can have
+ * different chips for rank 1 than rank 0.
+ *
+ * As address line A15 and CS1 chip select for rank 1 are muxed on the same
+ * pin, if single rank is used, A15 must be muxed in.
+ */
+#define MCTL_CR_R1_MUX_A15 (0x1 << 21)
+
#define PROTECT_MAGIC (0x94be6fa3)
struct sunxi_mctl_ctl_reg {
@@ -72,7 +84,8 @@ struct sunxi_mctl_ctl_reg {
u32 clken; /* 0x0c */
u32 pgsr[2];/* 0x10 PHY general status registers */
u32 statr; /* 0x18 */
- u8 res1[0x14]; /* 0x1c */
+ u8 res1[0x10]; /* 0x1c */
+ u32 lp3mr11;/* 0x2c */
u32 mr[4]; /* 0x30 mode registers */
u32 pllgcr; /* 0x40 */
u32 ptr[5]; /* 0x44 PHY timing registers */
@@ -120,7 +133,8 @@ struct sunxi_mctl_ctl_reg {
struct {/* 0x300 DATX8 modules*/
u32 mdlr; /* 0x00 master delay line register */
u32 lcdlr[3]; /* 0x04 local calibrated delay line
registers */
- u32 bdlr[12]; /* 0x10 bit delay line registers */
+ u32 bdlr[11]; /* 0x10 bit delay line registers */
+ u32 sdlr; /* 0x3c output enable bit delay
registers */
u32 gtr;/* 0x40 general timing register */
u32 gcr;/* 0x44 general configuration register
*/
u32 gsr[3]; /* 0x48 general status registers */
diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index efab4811ee54..5510aa54353f 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_MACH_SUN8I_A23) += dram_sun8i_a23.o
obj-$(CONFIG_MACH_SUN8I_A33) += dram_sun8i_a33.o
obj-$(CONFIG_MACH_SUN8I_A83T) += dram_sun8i_a83t.o
obj-$(CONFIG_MACH_SUNXI_H3_H5) += dram_sun8i_h3.o
+obj-$(CONFIG_MACH_SUN8I_R40) += dram_sun8i_h3.o
obj-$(CONFIG_MACH_SUN9I) += dram_sun9i.o
obj-$(CONFIG_MACH_SUN50I) += dram_sun8i_h3.o
endif
diff --git a/arch/arm/mach-sunxi/clock_sun6i.c
b/arch/arm/mach-sunxi/clock_sun6i.c
index 3c8c53fcf76b..9068c88ab2f8 100644
--- a/arch/arm/mach-sunxi/clock_sun6i.c
+++ b/arch/arm/mach-sunxi/clock_sun6i.c
@@ -222,
[U-Boot] [PATCH 02/12] sunxi: Enable AXP221s in I2C mode with the R40 SoC
The R40 SoC uses the AXP221s in I2C mode to supply power. Some regulator's common usages have changed, and also the recommended voltage for existing usages have changed. Update the defaults to match. Signed-off-by: Chen-Yu Tsai --- arch/arm/mach-sunxi/pmic_bus.c | 7 +++ board/sunxi/Kconfig| 2 +- drivers/power/Kconfig | 16 ++-- 3 files changed, 18 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-sunxi/pmic_bus.c b/arch/arm/mach-sunxi/pmic_bus.c index 7c57f02792b9..f917c3e070a5 100644 --- a/arch/arm/mach-sunxi/pmic_bus.c +++ b/arch/arm/mach-sunxi/pmic_bus.c @@ -41,6 +41,9 @@ int pmic_bus_init(void) p2wi_init(); ret = p2wi_change_to_p2wi_mode(AXP221_CHIP_ADDR, AXP221_CTRL_ADDR, AXP221_INIT_DATA); +# elif defined CONFIG_MACH_SUN8I_R40 + /* Nothing. R40 uses the AXP221s in I2C mode */ + ret = 0; # else ret = rsb_init(); if (ret) @@ -65,6 +68,8 @@ int pmic_bus_read(u8 reg, u8 *data) #elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER # ifdef CONFIG_MACH_SUN6I return p2wi_read(reg, data); +# elif defined CONFIG_MACH_SUN8I_R40 + return i2c_read(AXP209_I2C_ADDR, reg, 1, data, 1); # else return rsb_read(AXP223_RUNTIME_ADDR, reg, data); # endif @@ -80,6 +85,8 @@ int pmic_bus_write(u8 reg, u8 data) #elif defined CONFIG_AXP221_POWER || defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER # ifdef CONFIG_MACH_SUN6I return p2wi_write(reg, data); +# elif defined CONFIG_MACH_SUN8I_R40 + return i2c_write(AXP209_I2C_ADDR, reg, 1, &data, 1); # else return rsb_write(AXP223_RUNTIME_ADDR, reg, data); # endif diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 8e8b9cd0d5fd..e89ddf626289 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -456,7 +456,7 @@ config USB3_VBUS_PIN config I2C0_ENABLE bool "Enable I2C/TWI controller 0" - default y if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I + default y if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I || MACH_SUN8I_R40 default n if MACH_SUN6I || MACH_SUN8I select CMD_I2C ---help--- diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 64e5bc2f74b4..911ecb1144a6 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -10,7 +10,7 @@ choice prompt "Select Sunxi PMIC Variant" depends on ARCH_SUNXI default AXP209_POWER if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I - default AXP221_POWER if MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33 + default AXP221_POWER if MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_R40 default AXP818_POWER if MACH_SUN8I_A83T default SUNXI_NO_PMIC if MACH_SUNXI_H3_H5 || MACH_SUN50I @@ -37,7 +37,7 @@ config AXP209_POWER config AXP221_POWER bool "axp221 / axp223 pmic support" - depends on MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33 + depends on MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33 || MACH_SUN8I_R40 select CMD_POWEROFF ---help--- Select this to enable support for the axp221/axp223 pmic found on most @@ -70,7 +70,7 @@ endchoice config AXP_DCDC1_VOLT int "axp pmic dcdc1 voltage" depends on AXP221_POWER || AXP809_POWER || AXP818_POWER - default 3300 if AXP818_POWER + default 3300 if AXP818_POWER || MACH_SUN8I_R40 default 3000 if MACH_SUN6I || MACH_SUN8I || MACH_SUN9I ---help--- Set the voltage (mV) to program the axp pmic dcdc1 at, set to 0 to @@ -97,6 +97,7 @@ config AXP_DCDC2_VOLT On A23/A33 boards dcdc2 is used for VDD-SYS and should be 1.1V. On A80 boards dcdc2 powers the GPU and can be left off. On A83T boards dcdc2 is used for VDD-CPUA(cluster 0) and should be 0.9V. + On R40 boards dcdc2 is VDD-CPU and should be 1.1V config AXP_DCDC3_VOLT int "axp pmic dcdc3 voltage" @@ -104,6 +105,7 @@ config AXP_DCDC3_VOLT default 900 if AXP809_POWER || AXP818_POWER default 1500 if AXP152_POWER default 1250 if AXP209_POWER + default 1100 if MACH_SUN8I_R40 default 1200 if MACH_SUN6I || MACH_SUN8I ---help--- Set the voltage (mV) to program the axp pmic dcdc3 at, set to 0 to @@ -114,6 +116,7 @@ config AXP_DCDC3_VOLT On A23 / A31 / A33 boards dcdc3 is VDD-CPU and should be 1.2V. On A80 boards dcdc3 is used for VDD-CPUA(cluster 0) and should be 0.9V. On A83T boards dcdc3 is used for VDD-CPUB(cluster 1) and should be 0.9V. + On R40 boards dcdc3 is VDD-SYS and VDD-GPU and should be 1.1V. config AXP_DCDC4_VOLT int "axp pmic dcdc4 voltage" @@ -138,13 +141,13 @@ config AXP_DCDC5_VOLT ---help--- Set the voltage (mV) to program the axp pmic dcdc5 at, set to 0 to disable dcdc5. - On A23 / A31 / A33 / A80 / A83T boards dcdc5 is VCC-DRAM and +
[U-Boot] [PATCH 07/12] gpio: sunxi: Add compatible string for R40 PIO
The PIO on the R40 SoC is mostly compatible with the A20.
Only a few pin functions for mmc2 were added to the PC
pingroup, to support 8 bit eMMCs.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpio/sunxi_gpio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index 8d2bb18504ae..3f40e8383001 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -352,6 +352,7 @@ static const struct udevice_id sunxi_gpio_ids[] = {
ID("allwinner,sun8i-a33-pinctrl", a_all),
ID("allwinner,sun8i-a83t-pinctrl", a_all),
ID("allwinner,sun8i-h3-pinctrl",a_all),
+ ID("allwinner,sun8i-r40-pinctrl", a_all),
ID("allwinner,sun9i-a80-pinctrl", a_all),
ID("allwinner,sun6i-a31-r-pinctrl", l_2),
ID("allwinner,sun8i-a23-r-pinctrl", l_1),
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 03/12] sunxi: Fix watchdog reset function for R40
The watchdog found on the R40 SoC is the older variant found on the A20.
Add the proper "#if defines" to make it work.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/include/asm/arch-sunxi/timer.h| 5 ++---
arch/arm/include/asm/arch-sunxi/watchdog.h | 5 -
arch/arm/mach-sunxi/board.c| 5 ++---
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/timer.h
b/arch/arm/include/asm/arch-sunxi/timer.h
index a665309803cb..ccdf942534a4 100644
--- a/arch/arm/include/asm/arch-sunxi/timer.h
+++ b/arch/arm/include/asm/arch-sunxi/timer.h
@@ -67,7 +67,7 @@ struct sunxi_timer_reg {
struct sunxi_timer timer[6];/* We have 6 timers */
u8 res2[16];
struct sunxi_avs avs;
-#ifdef CONFIG_SUNXI_GEN_SUN4I
+#if defined(CONFIG_SUNXI_GEN_SUN4I) || defined(CONFIG_MACH_SUN8I_R40)
struct sunxi_wdog wdog; /* 0x90 */
/* XXX the following is not accurate for sun5i/sun7i */
struct sunxi_64cnt cnt64; /* 0xa0 */
@@ -77,8 +77,7 @@ struct sunxi_timer_reg {
struct sunxi_tgp tgp[4];
u8 res5[8];
u32 cpu_cfg;
-#endif
-#ifdef CONFIG_SUNXI_GEN_SUN6I
+#elif defined(CONFIG_SUNXI_GEN_SUN6I)
u8 res3[16];
struct sunxi_wdog wdog[5]; /* We have 5 watchdogs */
#endif
diff --git a/arch/arm/include/asm/arch-sunxi/watchdog.h
b/arch/arm/include/asm/arch-sunxi/watchdog.h
index 8108be97bab0..ce6d66485609 100644
--- a/arch/arm/include/asm/arch-sunxi/watchdog.h
+++ b/arch/arm/include/asm/arch-sunxi/watchdog.h
@@ -13,7 +13,10 @@
#define WDT_CTRL_RESTART (0x1 << 0)
#define WDT_CTRL_KEY (0x0a57 << 1)
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN5I) ||
defined(CONFIG_MACH_SUN7I)
+#if defined(CONFIG_MACH_SUN4I) || \
+defined(CONFIG_MACH_SUN5I) || \
+defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40)
#define WDT_MODE_EN(0x1 << 0)
#define WDT_MODE_RESET_EN (0x1 << 1)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 5a74c9717d84..6ce07dfe0fd7 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -270,7 +270,7 @@ void board_init_f(ulong dummy)
void reset_cpu(ulong addr)
{
-#ifdef CONFIG_SUNXI_GEN_SUN4I
+#if defined(CONFIG_SUNXI_GEN_SUN4I) || defined(CONFIG_MACH_SUN8I_R40)
static const struct sunxi_wdog *wdog =
&((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)->wdog;
@@ -282,8 +282,7 @@ void reset_cpu(ulong addr)
/* sun5i sometimes gets stuck without this */
writel(WDT_MODE_RESET_EN | WDT_MODE_EN, &wdog->mode);
}
-#endif
-#ifdef CONFIG_SUNXI_GEN_SUN6I
+#elif defined(CONFIG_SUNXI_GEN_SUN6I)
static const struct sunxi_wdog *wdog =
((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)->wdog;
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/12] sunxi: Add mmc[1-3] pinmux settings for R40
The PIO is generally compatible with the A20, except that it routes the
full 8 bits and eMMC reset pins for mmc2.
Signed-off-by: Chen-Yu Tsai
---
board/sunxi/board.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 495cb591a9fb..21ce8348922c 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -199,7 +199,8 @@ static void mmc_pinmux_setup(int sdc)
case 1:
pins = sunxi_name_to_gpio_bank(CONFIG_MMC1_PINS);
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I)
+#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40)
if (pins == SUNXI_GPIO_H) {
/* SDC1: PH22-PH-27 */
for (pin = SUNXI_GPH(22); pin <= SUNXI_GPH(27); pin++) {
@@ -294,6 +295,17 @@ static void mmc_pinmux_setup(int sdc)
sunxi_gpio_set_pull(SUNXI_GPC(24), SUNXI_GPIO_PULL_UP);
sunxi_gpio_set_drv(SUNXI_GPC(24), 2);
}
+#elif defined(CONFIG_MACH_SUN8I_R40)
+ /* SDC2: PC6-PC15, PC24 */
+ for (pin = SUNXI_GPC(6); pin <= SUNXI_GPC(15); pin++) {
+ sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SDC2);
+ sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
+ sunxi_gpio_set_drv(pin, 2);
+ }
+
+ sunxi_gpio_set_cfgpin(SUNXI_GPC(24), SUNXI_GPC_SDC2);
+ sunxi_gpio_set_pull(SUNXI_GPC(24), SUNXI_GPIO_PULL_UP);
+ sunxi_gpio_set_drv(SUNXI_GPC(24), 2);
#elif defined(CONFIG_MACH_SUN8I) || defined(CONFIG_MACH_SUN50I)
/* SDC2: PC5-PC6, PC8-PC16 */
for (pin = SUNXI_GPC(5); pin <= SUNXI_GPC(6); pin++) {
@@ -320,7 +332,8 @@ static void mmc_pinmux_setup(int sdc)
case 3:
pins = sunxi_name_to_gpio_bank(CONFIG_MMC3_PINS);
-#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I)
+#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I) || \
+defined(CONFIG_MACH_SUN8I_R40)
/* SDC3: PI4-PI9 */
for (pin = SUNXI_GPI(4); pin <= SUNXI_GPI(9); pin++) {
sunxi_gpio_set_cfgpin(pin, SUNXI_GPI_SDC3);
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] sunxi: Add boards/sunxi and arch/arm/mach-sunxi to sunxi MAINTAINERS entry
Recently some sunxi related code was moved to arch/arm/mach-sunxi, but the MAINTAINERS entry was not updated to reflect this. Add this, and the board level boards/sunxi directory to our entry. While at it, also update its status, to reflect the current active maintainership. Signed-off-by: Chen-Yu Tsai --- MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index eaa2c3bbb860..4eee53f5a9f6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -168,9 +168,12 @@ F: arch/arm/include/asm/arch-stv0991/ ARM SUNXI M: Jagan Teki M: Maxime Ripard +S: Maintained T: git git://git.denx.de/u-boot-sunxi.git F: arch/arm/cpu/armv7/sunxi/ F: arch/arm/include/asm/arch-sunxi/ +F: arch/arm/mach-sunxi/ +F: board/sunxi/ ARM TEGRA M: Tom Warren -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Device cleanup before starting OS (Linux)
Hi Simon, On 01.03.2017 06:40, Simon Glass wrote: > On 28 February 2017 at 09:32, Stefan Roese wrote: >> >> Hi! >> >> I'm currently trying to add some code to stop (DMA) buffer usage >> in the Marvell mvpp2 ethernet driver, that should only be >> executed once, before the OS is started - stop() does not work >> easily for me here. I've found the weak function >> "board_quiesce_devices()", which is already used for >> such cases. But since you are not fond of weak functions >> (I totally agree here, this is far from perfect) and already >> suggested some kind of "finalize" DM API call, I'm wondering >> if I should introduce this new API call for such cases and use >> it in the ethernet driver. >> >> So what is your opinion about this? Should I add such a >> finalize DM function and call it from the arch/.../bootm >> code? Or do you have other suggestions on how to handle >> such driver specific last-stage (pre OS) calls? > > Is it possible to use the device's remove() method? I also thought about this of course. Using remove has the following disadvantages, that I currently can think of: - The remove functions of all devices are called, adding to the bootup time - Since all devices are removed, serial (and other) output is not available (for debug purposes) any more It should be possible to add a DM flag to enable this pre-OS device remove, which could be enabled on a per-device basis. This way we don't need another API function. But still I need to hook this pre-OS "remove" into arch/.../bootm. What do you think? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Device cleanup before starting OS (Linux)
Hi Stefan, On 28 February 2017 at 09:32, Stefan Roese wrote: > > Hi! > > I'm currently trying to add some code to stop (DMA) buffer usage > in the Marvell mvpp2 ethernet driver, that should only be > executed once, before the OS is started - stop() does not work > easily for me here. I've found the weak function > "board_quiesce_devices()", which is already used for > such cases. But since you are not fond of weak functions > (I totally agree here, this is far from perfect) and already > suggested some kind of "finalize" DM API call, I'm wondering > if I should introduce this new API call for such cases and use > it in the ethernet driver. > > So what is your opinion about this? Should I add such a > finalize DM function and call it from the arch/.../bootm > code? Or do you have other suggestions on how to handle > such driver specific last-stage (pre OS) calls? Is it possible to use the device's remove() method? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH 11/17] sunxi: SPL: add FIT config selector for Pine64 boards
01.03.2017, 10:26, "Andre Przywara" :
> For a board or platform to support FIT loading in the SPL, it has to
> provide a board_fit_config_name_match() routine, which helps to select
> one of possibly multiple DTBs contained in a FIT image.
> Provide a simple function which chooses the DT name U-Boot was
> configured with.
> If the DT name is one of the two Pine64 versions, determine the exact
> model by checking the DRAM size.
>
I think we shouldn't have is specially for Pine64 here, but make a framework
for other boards that can be easily checked.
Then make Pine64 series the first user of this framework.
> Signed-off-by: Andre Przywara
> ---
> board/sunxi/board.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index a510422..2ddff28 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -725,3 +725,26 @@ int ft_board_setup(void *blob, bd_t *bd)
> #endif
> return 0;
> }
> +
> +#ifdef CONFIG_SPL_LOAD_FIT
> +int board_fit_config_name_match(const char *name)
> +{
> + const char *cmp_str;
> +
> +#ifdef CONFIG_DEFAULT_DEVICE_TREE
> + cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
> +#else
> + return 0;
> +#endif
> +
> +/* Differentiate the two Pine64 board DTs by their DRAM size. */
> + if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
> + if ((gd->ram_size > 512 * 1024 * 1024))
> + return !strstr(name, "plus");
> + else
> + return !!strstr(name, "plus");
> + } else {
> + return strcmp(name, cmp_str);
> + }
> +}
> +#endif
> --
> 2.8.2
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 14/17] sunxi: Pine64: defconfig: enable SPL FIT support
The Pine64 (and all other 64-bit Allwinner boards) need to load an ARM Trusted Firmware image beside the actual U-Boot proper. This can now be easily achieved by using the just extended SPL FIT loading support, so enable it in the Pine64 defconfig. Also add the FIT image as a build target to 64-bit sunxi board to trigger the respective Makefile rules. Signed-off-by: Andre Przywara --- configs/pine64_plus_defconfig | 6 ++ include/configs/sunxi-common.h | 4 2 files changed, 10 insertions(+) diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig index 7c7d86f..2b47157 100644 --- a/configs/pine64_plus_defconfig +++ b/configs/pine64_plus_defconfig @@ -3,9 +3,14 @@ CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN50I=y CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus" +CONFIG_OF_LIST="sun50i-a64-pine64 sun50i-a64-pine64-plus" # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_CONSOLE_MUX=y CONFIG_SPL=y +CONFIG_FIT=y +CONFIG_SPL_FIT=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_OF_LIBFDT=y # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set # CONFIG_CMD_FPGA is not set @@ -14,3 +19,4 @@ CONFIG_SPL=y # CONFIG_SPL_EFI_PARTITION is not set CONFIG_SUN8I_EMAC=y CONFIG_USB_EHCI_HCD=y +CONFIG_SPL_FIT_GENERATOR="board/sunxi/mksunxi_fit_atf.sh" diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 37c4a4d..06d03d4 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -39,6 +39,10 @@ #define CONFIG_SYS_THUMB_BUILD /* Thumbs mode to save space in SPL */ #endif +#ifdef CONFIG_ARM64 +#define CONFIG_BUILD_TARGET "u-boot.itb" +#endif + /* Serial & console */ #define CONFIG_SYS_NS16550_SERIAL /* ns16550 reg in the low bits of cpu reg */ -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 11/17] sunxi: SPL: add FIT config selector for Pine64 boards
For a board or platform to support FIT loading in the SPL, it has to
provide a board_fit_config_name_match() routine, which helps to select
one of possibly multiple DTBs contained in a FIT image.
Provide a simple function which chooses the DT name U-Boot was
configured with.
If the DT name is one of the two Pine64 versions, determine the exact
model by checking the DRAM size.
Signed-off-by: Andre Przywara
---
board/sunxi/board.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index a510422..2ddff28 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -725,3 +725,26 @@ int ft_board_setup(void *blob, bd_t *bd)
#endif
return 0;
}
+
+#ifdef CONFIG_SPL_LOAD_FIT
+int board_fit_config_name_match(const char *name)
+{
+ const char *cmp_str;
+
+#ifdef CONFIG_DEFAULT_DEVICE_TREE
+ cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
+#else
+ return 0;
+#endif
+
+/* Differentiate the two Pine64 board DTs by their DRAM size. */
+ if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
+ if ((gd->ram_size > 512 * 1024 * 1024))
+ return !strstr(name, "plus");
+ else
+ return !!strstr(name, "plus");
+ } else {
+ return strcmp(name, cmp_str);
+ }
+}
+#endif
--
2.8.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 05/17] SPL: FIT: allow loading multiple images
So far we were not using the FIT image format to its full potential:
The SPL FIT loader was just loading the first image from the /images
node plus one of the listed DTBs.
Now with the refactored loader code it's easy to load an arbitrary
number of images in addition to the two mentioned above.
As described in the FIT image source file format description, iterate
over all images listed at the "loadables" property in the configuration
node and load every image at its desired location.
This allows to load any kind of images:
- firmware images to execute before U-Boot proper (for instance
ARM Trusted Firmware (ATF))
- firmware images for management processors (SCP, arisc, ...)
- firmware images for devices like WiFi controllers
- bit files for FPGAs
- additional configuration data
- kernels and/or ramdisks
The actual usage of this feature would be platform and/or board specific.
Signed-off-by: Andre Przywara
---
common/spl/spl_fit.c | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index ad5ba15..5583e09 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -178,10 +178,7 @@ static int spl_load_fit_image(struct spl_load_info *info,
ulong sector,
if (image_info) {
image_info->load_addr = load_addr;
image_info->size = length;
- if (entry == -1UL)
- image_info->entry_point = load_addr;
- else
- image_info->entry_point = entry;
+ image_info->entry_point = entry;
}
return 0;
@@ -196,6 +193,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
struct spl_image_info image_info;
int node, images;
int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
+ int index = 0;
/*
* Figure out where the external images start. This is the base for the
@@ -240,6 +238,11 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
if (node < 0) {
debug("could not find firmware image, trying loadables...\n");
node = spl_fit_get_image_node(fit, images, "loadables", 0);
+ /*
+* If we pick the U-Boot image from "loadables", start at
+* the second image when later loading additional images.
+*/
+ index = 1;
}
if (node < 0) {
debug("%s: Cannot find u-boot image node: %d\n",
@@ -265,5 +268,26 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
image_info.load_addr = spl_image->load_addr + spl_image->size;
spl_load_fit_image(info, sector, fit, base_offset, node, &image_info);
+ /* Now check if there are more images for us to load */
+ for (; ; index++) {
+ node = spl_fit_get_image_node(fit, images, "loadables", index);
+ if (node < 0)
+ break;
+
+ spl_load_fit_image(info, sector, fit, base_offset, node,
+ &image_info);
+
+ /*
+* If the "firmware" image did not provide an entry point,
+* use the first valid entry point from the loadables.
+*/
+ if (spl_image->entry_point == -1UL &&
+ image_info.entry_point != -1UL)
+ spl_image->entry_point = image_info.entry_point;
+ }
+
+ if (spl_image->entry_point == -1UL || spl_image->entry_point == 0)
+ spl_image->entry_point = spl_image->load_addr;
+
return 0;
}
--
2.8.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 06/17] tools: mksunxiboot: allow larger SPL binaries
mksunxiboot limits the size of the resulting SPL binaries to pretty conservative values to cover all SoCs and all boot media (NAND). It turns out that we have limit checks in place in the build process, so mksunxiboot can be relaxed and allow packaging binaries up to the actual 32KB the mask boot ROM actually imposes. This allows to have a bigger SPL, which is crucial for AArch64 builds. Signed-off-by: Andre Przywara --- tools/mksunxiboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c index 0f0b003..6bb649c 100644 --- a/tools/mksunxiboot.c +++ b/tools/mksunxiboot.c @@ -48,7 +48,7 @@ int gen_check_sum(struct boot_file_head *head_p) #define ALIGN(x, a) __ALIGN_MASK((x), (typeof(x))(a)-1) #define __ALIGN_MASK(x, mask) (((x)+(mask))&~(mask)) -#define SUN4I_SRAM_SIZE 0x7600 /* 0x7748+ is used by BROM */ +#define SUN4I_SRAM_SIZE 0x8000 /* SoC with smaller size are limited before */ #define SRAM_LOAD_MAX_SIZE (SUN4I_SRAM_SIZE - sizeof(struct boot_file_head)) /* -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 07/17] armv8: SPL: only compile GIC code if needed
Not every SoC needs to set up the GIC interrupt controller, so link think code only when the respective config option is set. This shaves off some bytes from the SPL code size. Signed-off-by: Andre Przywara --- arch/arm/lib/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index 166fa9e..71de1ca 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -44,7 +44,9 @@ ifdef CONFIG_CPU_V7M obj-y += interrupts_m.o else ifdef CONFIG_ARM64 obj-y += ccn504.o +ifneq ($(CONFIG_GICV2)$(CONFIG_GICV3),) obj-y += gic_64.o +endif obj-y += interrupts_64.o else obj-y += interrupts.o -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 03/17] SPL: FIT: rework U-Boot image loading
Currently the SPL FIT loader always looks only for the first image in
the /images node a FIT tree, which it loads and later executes.
Generalize this by looking for a "firmware" property in the matched
configuration subnode, or, if that does not exist, for the first string
in the "loadables" property. Then using the string in that property,
load the image of that name from the /images node.
This still loads only one image at the moment, but refactors the code to
allow extending this in a following patch.
To simplify later re-usage, we also generalize the spl_fit_select_index()
function to not return the image location, but just the node offset.
Signed-off-by: Andre Przywara
---
common/spl/spl_fit.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index ba45e65..572a5db 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -55,14 +55,13 @@ static int spl_fit_find_config_node(const void *fdt)
return -1;
}
-static int spl_fit_select_index(const void *fit, int images, int *offsetp,
- const char *type, int index)
+static int spl_fit_get_image_node(const void *fit, int images,
+ const char *type, int index)
{
const char *name, *str;
int node, conf_node;
int len, i;
- *offsetp = 0;
conf_node = spl_fit_find_config_node(fit);
if (conf_node < 0) {
#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
@@ -99,10 +98,7 @@ static int spl_fit_select_index(const void *fit, int images,
int *offsetp,
return -EINVAL;
}
- *offsetp = fdt_getprop_u32(fit, node, "data-offset");
- len = fdt_getprop_u32(fit, node, "data-size");
-
- return len;
+ return node;
}
static int get_aligned_image_offset(struct spl_load_info *info, int offset)
@@ -188,15 +184,22 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
if (count == 0)
return -EIO;
- /* find the firmware image to load */
+ /* find the node holding the images information */
images = fdt_path_offset(fit, FIT_IMAGES_PATH);
if (images < 0) {
debug("%s: Cannot find /images node: %d\n", __func__, images);
return -1;
}
- node = fdt_first_subnode(fit, images);
+
+ /* find the U-Boot image */
+ node = spl_fit_get_image_node(fit, images, "firmware", 0);
+ if (node < 0) {
+ debug("could not find firmware image, trying loadables...\n");
+ node = spl_fit_get_image_node(fit, images, "loadables", 0);
+ }
if (node < 0) {
- debug("%s: Cannot find first image node: %d\n", __func__, node);
+ debug("%s: Cannot find u-boot image node: %d\n",
+ __func__, node);
return -1;
}
@@ -238,10 +241,13 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
memcpy(dst, src, data_size);
/* Figure out which device tree the board wants to use */
- fdt_len = spl_fit_select_index(fit, images, &fdt_offset,
- FIT_FDT_PROP, 0);
- if (fdt_len < 0)
- return fdt_len;
+ node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, 0);
+ if (node < 0) {
+ debug("%s: cannot find FDT node\n", __func__);
+ return node;
+ }
+ fdt_offset = fdt_getprop_u32(fit, node, "data-offset");
+ fdt_len = fdt_getprop_u32(fit, node, "data-size");
/*
* Read the device tree and place it after the image. There may be
--
2.8.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 16/17] sunxi: Store the device tree name in the SPL header
From: Siarhei Siamashka
This patch updates the mksunxiboot tool to optionally add
the default device tree name string to the SPL header. This
information can be used by the firmware upgrade tools to
protect users from harming themselves by trying to upgrade
to an incompatible bootloader.
The primary use case here is a non-removable bootable media
(such as NAND, eMMC or SPI flash), which already may have
a properly working, but a little bit outdated bootloader
installed. For example, the user may download or build a
new U-Boot image for "Cubieboard", and then attemept to
install it on a "Cubieboard2" hardware by mistake as a
replacement for the already existing bootloader. If this
happens, the flash programming tool can identify this
problem and warn the user.
The size of the SPL header is also increased from 64 bytes
to 96 bytes to provide enough space for the device tree name
string.
[Andre: split patch to remove OF_LIST hash feature]
Signed-off-by: Siarhei Siamashka
Signed-off-by: Andre Przywara
---
arch/arm/include/asm/arch-sunxi/spl.h | 19 +++---
include/configs/sunxi-common.h| 8 +++---
scripts/Makefile.spl | 3 ++-
tools/mksunxiboot.c | 49 ---
4 files changed, 67 insertions(+), 12 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/spl.h
b/arch/arm/include/asm/arch-sunxi/spl.h
index 831d0c0..9358397 100644
--- a/arch/arm/include/asm/arch-sunxi/spl.h
+++ b/arch/arm/include/asm/arch-sunxi/spl.h
@@ -10,7 +10,7 @@
#define BOOT0_MAGIC"eGON.BT0"
#define SPL_SIGNATURE "SPL" /* marks "sunxi" SPL header */
-#define SPL_HEADER_VERSION 1
+#define SPL_HEADER_VERSION 2
#ifdef CONFIG_SUNXI_HIGH_SRAM
#define SPL_ADDR 0x1
@@ -58,11 +58,24 @@ struct boot_file_head {
* compatible format, ready to be imported via "env import -t".
*/
uint32_t fel_uEnv_length;
- uint32_t reserved1[2];
+ /*
+* Offset of an ASCIIZ string (relative to the SPL header), which
+* contains the default device tree name (CONFIG_DEFAULT_DEVICE_TREE).
+* This is optional and may be set to NULL. Is intended to be used
+* by flash programming tools for providing nice informative messages
+* to the users.
+*/
+ uint32_t dt_name_offset;
+ uint32_t reserved1;
uint32_t boot_media;/* written here by the boot ROM */
- uint32_t reserved2[5]; /* padding, align to 64 bytes */
+ /* A padding area (may be used for storing text strings) */
+ uint32_t string_pool[13];
+ /* The header must be a multiple of 32 bytes (for VBAR alignment) */
};
+/* Compile time check to assure proper alignment of structure */
+typedef char boot_file_head_not_multiple_of_32[1 - 2*(sizeof(struct
boot_file_head) % 32)];
+
#define is_boot0_magic(addr) (memcmp((void *)addr, BOOT0_MAGIC, 8) == 0)
#endif
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 06d03d4..e37bf6a 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -188,8 +188,8 @@
#endif
#ifdef CONFIG_SUNXI_HIGH_SRAM
-#define CONFIG_SPL_TEXT_BASE 0x10040 /* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x7fc0 /* 32 KiB */
+#define CONFIG_SPL_TEXT_BASE 0x10060 /* sram start+header */
+#define CONFIG_SPL_MAX_SIZE0x7fa0 /* 32 KiB */
#ifdef CONFIG_ARM64
/* end of SRAM A2 for now, as SRAM A1 is pretty tight for an ARM64 build */
#define LOW_LEVEL_SRAM_STACK 0x00054000
@@ -197,8 +197,8 @@
#define LOW_LEVEL_SRAM_STACK 0x00018000
#endif /* !CONFIG_ARM64 */
#else
-#define CONFIG_SPL_TEXT_BASE 0x40/* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x5fc0 /* 24KB on sun4i/sun7i
*/
+#define CONFIG_SPL_TEXT_BASE 0x60/* sram start+header */
+#define CONFIG_SPL_MAX_SIZE0x5fa0 /* 24KB on sun4i/sun7i
*/
#define LOW_LEVEL_SRAM_STACK 0x8000 /* End of sram */
#endif
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index b52f996..fe827ce 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -285,7 +285,8 @@ $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mkimage)
quiet_cmd_mksunxiboot = MKSUNXI $@
-cmd_mksunxiboot = $(objtree)/tools/mksunxiboot $< $@
+cmd_mksunxiboot = $(objtree)/tools/mksunxiboot \
+ --default-dt $(CONFIG_DEFAULT_DEVICE_TREE) $< $@
$(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mksunxiboot)
diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index 6bb649c..4ac2791 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -70,11 +70,40 @@ int main(int argc, char *argv[])
struct boot_img img;
unsigned file_size;
[U-Boot] [PATCH 10/17] sunxi: SPL: store RAM size in gd
The sunxi SPL was holding the detected RAM size in some local variable
only, so it wasn't accessible for other functions.
Store the value in gd->ram_size instead, so it can be used later on.
Signed-off-by: Andre Przywara
---
board/sunxi/board.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index b966012..a510422 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -480,7 +480,6 @@ void i2c_init_board(void)
void sunxi_board_init(void)
{
int power_failed = 0;
- unsigned long ramsize;
#ifdef CONFIG_SY8106A_POWER
power_failed = sy8106a_set_vout1(CONFIG_SY8106A_VOUT1_VOLT);
@@ -541,9 +540,9 @@ void sunxi_board_init(void)
#endif
#endif
printf("DRAM:");
- ramsize = sunxi_dram_init();
- printf(" %d MiB\n", (int)(ramsize >> 20));
- if (!ramsize)
+ gd->ram_size = sunxi_dram_init();
+ printf(" %d MiB\n", (int)(gd->ram_size >> 20));
+ if (!gd->ram_size)
hang();
/*
--
2.8.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 17/17] sunxi: use SPL header DT name for FIT board matching
Now that we can store a DT name in the SPL header, use this string (if
available) when finding the right DT blob to load for U-Boot proper.
This allows a generic U-Boot (proper) image to be combined with a bunch
of supported DTs, with just the SPL (possibly only that string) to be
different.
Eventually this string can be written after the build process by some
firmware update tool.
Signed-off-by: Andre Przywara
---
board/sunxi/board.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 2ddff28..714f8fd 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -729,13 +729,19 @@ int ft_board_setup(void *blob, bd_t *bd)
#ifdef CONFIG_SPL_LOAD_FIT
int board_fit_config_name_match(const char *name)
{
- const char *cmp_str;
+ struct boot_file_head *spl = (void *)(ulong)SPL_ADDR;
+ const char *cmp_str = (void *)(ulong)SPL_ADDR;
+ /* Check if there is a DT name stored in the SPL header and use that. */
+ if (spl->dt_name_offset) {
+ cmp_str += spl->dt_name_offset;
+ } else {
#ifdef CONFIG_DEFAULT_DEVICE_TREE
- cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
+ cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
#else
- return 0;
+ return 0;
#endif
+ };
/* Differentiate the two Pine64 board DTs by their DRAM size. */
if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
--
2.8.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 15/17] sunxi: OrangePi-PC2: defconfig: enable SPL FIT support
Enable the SPL FIT support and the FIT generator script for the OrangePi PC2 board, as it also need to load an ATF binary. Signed-off-by: Andre Przywara --- configs/orangepi_pc2_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/orangepi_pc2_defconfig b/configs/orangepi_pc2_defconfig index 19a5c2b..8a2d289 100644 --- a/configs/orangepi_pc2_defconfig +++ b/configs/orangepi_pc2_defconfig @@ -5,6 +5,12 @@ CONFIG_SPL=y CONFIG_DRAM_CLK=672 CONFIG_DRAM_ZQ=3881977 CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-orangepi-pc2" +CONFIG_OF_LIST="sun50i-h5-orangepi-pc2" +CONFIG_FIT=y +CONFIG_SPL_FIT=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_OF_LIBFDT=y +CONFIG_SPL_FIT_GENERATOR="board/sunxi/mksunxi_fit_atf.sh" # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_CONSOLE_MUX=y # CONFIG_CMD_IMLS is not set -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 13/17] sunxi: A64: Pine64: introduce FIT generator script
Now that the Makefile can call a generator script to build a more
advanced FIT image, let's use this feature to address the needs of
Allwinner A64 boards.
The (DTB stripped) U-Boot binary and the ATF are static, but we allow
an arbitrary number of supported device trees to be passed.
The script enters both a DT entry in the /images node and the respective
subnode in /configurations to support all listed DTBs.
This requires to copy the ARM Trusted Firmware build (bl31.bin) into
the U-Boot source directory (or to create a symlink to it).
Signed-off-by: Andre Przywara
---
board/sunxi/mksunxi_fit_atf.sh | 73 ++
1 file changed, 73 insertions(+)
create mode 100755 board/sunxi/mksunxi_fit_atf.sh
diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh
new file mode 100755
index 000..afa22e8
--- /dev/null
+++ b/board/sunxi/mksunxi_fit_atf.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+#
+# script to generate FIT image source for 64-bit sunxi boards with
+# ARM Trusted Firmware and multiple device trees (given on the command line)
+#
+# usage: $0 [ [;
+
+ images {
+ uboot@1 {
+ description = "U-Boot (64-bit)";
+ data = /incbin/("u-boot-nodtb.bin");
+ type = "standalone";
+ arch = "arm64";
+ compression = "none";
+ load = <0x4a00>;
+ };
+ atf@1 {
+ description = "ARM Trusted Firmware";
+ data = /incbin/("bl31.bin");
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ load = <0x44000>;
+ entry = <0x44000>;
+ };
+__HEADER_EOF
+
+cnt=1
+for dtname in $*
+do
+ cat << __FDT_IMAGE_EOF
+ fdt@$cnt {
+ description = "$(basename $dtname .dtb)";
+ data = /incbin/("$dtname");
+ type = "flat_dt";
+ compression = "none";
+ };
+__FDT_IMAGE_EOF
+ cnt=$((cnt+1))
+done
+
+cat << __CONF_HEADER_EOF
+ };
+ configurations {
+ default = "config@1";
+
+__CONF_HEADER_EOF
+
+cnt=1
+for dtname in $*
+do
+ cat << __CONF_SECTION_EOF
+ config@$cnt {
+ description = "$(basename $dtname .dtb)";
+ firmware = "uboot@1";
+ loadables = "atf@1";
+ fdt = "fdt@$cnt";
+ };
+__CONF_SECTION_EOF
+ cnt=$((cnt+1))
+done
+
+cat << __ITS_EOF
+ };
+};
+__ITS_EOF
--
2.8.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 08/17] armv8: fsl: move ccn504 code into FSL Makefile
The generic ARMv8 assembly code contains routines for setting up a CCN interconnect, though the Freescale SoCs are the only user. Link this code only for Freescale targets, this saves some precious bytes in the chronically tight SPL. Signed-off-by: Andre Przywara --- arch/arm/cpu/armv8/fsl-layerscape/Makefile | 1 + arch/arm/lib/Makefile | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile b/arch/arm/cpu/armv8/fsl-layerscape/Makefile index c9ab93e..ca09973 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile @@ -7,6 +7,7 @@ obj-y += cpu.o obj-y += lowlevel.o obj-y += soc.o +obj-y += ccn504.o obj-$(CONFIG_MP) += mp.o obj-$(CONFIG_OF_LIBFDT) += fdt.o obj-$(CONFIG_SPL) += spl.o diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index 71de1ca..60ffb4a 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -43,7 +43,6 @@ obj-y += stack.o ifdef CONFIG_CPU_V7M obj-y += interrupts_m.o else ifdef CONFIG_ARM64 -obj-y += ccn504.o ifneq ($(CONFIG_GICV2)$(CONFIG_GICV3),) obj-y += gic_64.o endif -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/17] SPL: FIT: factor out spl_load_fit_image()
At the moment we load two images from a FIT image: the actual U-Boot
image and the DTB. Both times we have very similar code to deal with
alignment requirement the media we load from imposes upon us.
Factor out this code into a new function, which we just call twice.
Signed-off-by: Andre Przywara
---
common/spl/spl_fit.c | 129 +++
1 file changed, 57 insertions(+), 72 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 572a5db..ad5ba15 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -18,7 +18,7 @@ static ulong fdt_getprop_u32(const void *fdt, int node, const
char *prop)
cell = fdt_getprop(fdt, node, prop, &len);
if (len != sizeof(*cell))
- return -1U;
+ return -1UL;
return fdt32_to_cpu(*cell);
}
@@ -139,19 +139,63 @@ static int get_aligned_image_size(struct spl_load_info
*info, int data_size,
return (data_size + info->bl_len - 1) / info->bl_len;
}
+static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
+ void *fit, ulong base_offset, int node,
+ struct spl_image_info *image_info)
+{
+ ulong offset;
+ size_t length;
+ ulong load_addr, load_ptr, entry;
+ void *src;
+ ulong overhead;
+ int nr_sectors;
+ int align_len = ARCH_DMA_MINALIGN - 1;
+
+ offset = fdt_getprop_u32(fit, node, "data-offset") + base_offset;
+ length = fdt_getprop_u32(fit, node, "data-size");
+ load_addr = fdt_getprop_u32(fit, node, "load");
+ if (load_addr == -1UL && image_info)
+ load_addr = image_info->load_addr;
+ load_ptr = (load_addr + align_len) & ~align_len;
+ entry = fdt_getprop_u32(fit, node, "entry");
+
+ overhead = get_aligned_image_overhead(info, offset);
+ nr_sectors = get_aligned_image_size(info, length, offset);
+
+ if (info->read(info, sector + get_aligned_image_offset(info, offset),
+ nr_sectors, (void*)load_ptr) != nr_sectors)
+ return -EIO;
+ debug("image: dst=%lx, offset=%lx, size=%lx\n", load_ptr, offset,
+ (unsigned long)length);
+
+ src = (void *)load_ptr + overhead;
+#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
+ board_fit_image_post_process(&src, &length);
+#endif
+
+ memcpy((void*)load_addr, src, length);
+
+ if (image_info) {
+ image_info->load_addr = load_addr;
+ image_info->size = length;
+ if (entry == -1UL)
+ image_info->entry_point = load_addr;
+ else
+ image_info->entry_point = entry;
+ }
+
+ return 0;
+}
+
int spl_load_simple_fit(struct spl_image_info *spl_image,
struct spl_load_info *info, ulong sector, void *fit)
{
int sectors;
- ulong size, load;
+ ulong size;
unsigned long count;
+ struct spl_image_info image_info;
int node, images;
- void *load_ptr;
- int fdt_offset, fdt_len;
- int data_offset, data_size;
int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
- int src_sector;
- void *dst, *src;
/*
* Figure out where the external images start. This is the base for the
@@ -203,82 +247,23 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
return -1;
}
- /* Get its information and set up the spl_image structure */
- data_offset = fdt_getprop_u32(fit, node, "data-offset");
- data_size = fdt_getprop_u32(fit, node, "data-size");
- load = fdt_getprop_u32(fit, node, "load");
- debug("data_offset=%x, data_size=%x\n", data_offset, data_size);
- spl_image->load_addr = load;
- spl_image->entry_point = load;
+ /* Load the image and set up the spl_image structure */
+ spl_load_fit_image(info, sector, fit, base_offset, node, spl_image);
spl_image->os = IH_OS_U_BOOT;
- /*
-* Work out where to place the image. We read it so that the first
-* byte will be at 'load'. This may mean we need to load it starting
-* before then, since we can only read whole blocks.
-*/
- data_offset += base_offset;
- sectors = get_aligned_image_size(info, data_size, data_offset);
- load_ptr = (void *)load;
- debug("U-Boot size %x, data %p\n", data_size, load_ptr);
- dst = load_ptr;
-
- /* Read the image */
- src_sector = sector + get_aligned_image_offset(info, data_offset);
- debug("Aligned image read: dst=%p, src_sector=%x, sectors=%x\n",
- dst, src_sector, sectors);
- count = info->read(info, src_sector, sectors, dst);
- if (count != sectors)
- return -EIO;
- debug("image: dst=%p, data_offset=%x, size=%x\n", dst, data_offset,
- data_size);
- src = dst + get
[U-Boot] [PATCH 12/17] Makefile: add rules to generate SPL FIT images
Some platforms require more complex U-Boot images than we can easily generate via the mkimage command line, for instance to load additional image files. Introduce a CONFIG_SPL_FIT_SOURCE and CONFIG_SPL_FIT_GENERATOR symbol, which can either hold an .its source file describing the image layout, or, in the second case, a generator tool (script) to create such a source file. This script gets passed the list of device tree files from the CONFIG_OF_LIST variable. A platform or board can define either of those in their defconfig file to allow an easy building of such an image. Signed-off-by: Andre Przywara --- Kconfig | 17 + Makefile | 20 2 files changed, 37 insertions(+) diff --git a/Kconfig b/Kconfig index 81b4226..f3e4243 100644 --- a/Kconfig +++ b/Kconfig @@ -238,6 +238,23 @@ config SPL_FIT_IMAGE_POST_PROCESS injected into the FIT creation (i.e. the blobs would have been pre- processed before being added to the FIT image). +config SPL_FIT_SOURCE + string ".its source file for U-Boot FIT image" + depends on SPL_FIT + help + Specifies a (platform specific) FIT source file to generate the + U-Boot FIT image. This could specify further image to load and/or + execute. + +config SPL_FIT_GENERATOR + string ".its file generator script for U-Boot FIT image" + depends on SPL_FIT + help + Specifies a (platform specific) script file to generate the FIT + source file used to build the U-Boot FIT image file. This gets + passed a list of supported device tree file stub names to + include in the generated image. + endif # FIT config OF_BOARD_SETUP diff --git a/Makefile b/Makefile index 38b42da..e09b0d9 100644 --- a/Makefile +++ b/Makefile @@ -826,6 +826,10 @@ quiet_cmd_mkimage = MKIMAGE $@ cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \ $(if $(KBUILD_VERBOSE:1=), >$(MKIMAGEOUTPUT)) +quiet_cmd_mkfitimage = MKIMAGE $@ +cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f $(U_BOOT_ITS) -E $@ \ + $(if $(KBUILD_VERBOSE:1=), >$(MKIMAGEOUTPUT)) + quiet_cmd_cat = CAT $@ cmd_cat = cat $(filter-out $(PHONY), $^) > $@ @@ -945,6 +949,19 @@ quiet_cmd_cpp_cfg = CFG $@ cmd_cpp_cfg = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) -ansi \ -DDO_DEPS_ONLY -D__ASSEMBLY__ -x assembler-with-cpp -P -dM -E -o $@ $< +# Boards with more complex image requirments can provide an .its source file +# or a generator script +ifneq ($(CONFIG_SPL_FIT_SOURCE),"") +U_BOOT_ITS = $(subst ",,$(CONFIG_SPL_FIT_SOURCE)) +else +ifneq ($(CONFIG_SPL_FIT_GENERATOR),"") +U_BOOT_ITS := u-boot.its +$(U_BOOT_ITS): FORCE + $(srctree)/$(CONFIG_SPL_FIT_GENERATOR) \ + $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > $@ +endif +endif + ifdef CONFIG_SPL_LOAD_FIT MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O u-boot \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ @@ -977,6 +994,9 @@ u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \ $(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin dts/dt.dtb,u-boot.bin) FORCE $(call if_changed,mkimage) +u-boot.itb: u-boot-nodtb.bin dts/dt.dtb $(U_BOOT_ITS) FORCE + $(call if_changed,mkfitimage) + u-boot-spl.kwb: u-boot.img spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/17] sunxi: A64: move SPL stack to end of SRAM A2
The SPL stack is usually located at the end of SRAM A1, where it grows towards the end of the SPL. For the really big AArch64 binaries the stack overwrites code pretty soon, so move the SPL stack to the end of SRAM A2, which is unused at this time. Signed-off-by: Andre Przywara --- include/configs/sunxi-common.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 5fe886b..37c4a4d 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -186,7 +186,12 @@ #ifdef CONFIG_SUNXI_HIGH_SRAM #define CONFIG_SPL_TEXT_BASE 0x10040 /* sram start+header */ #define CONFIG_SPL_MAX_SIZE0x7fc0 /* 32 KiB */ +#ifdef CONFIG_ARM64 +/* end of SRAM A2 for now, as SRAM A1 is pretty tight for an ARM64 build */ +#define LOW_LEVEL_SRAM_STACK 0x00054000 +#else #define LOW_LEVEL_SRAM_STACK 0x00018000 +#endif /* !CONFIG_ARM64 */ #else #define CONFIG_SPL_TEXT_BASE 0x40/* sram start+header */ #define CONFIG_SPL_MAX_SIZE0x5fc0 /* 24KB on sun4i/sun7i */ -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 01/17] armv8: spl: Call spl_relocate_stack_gd for ARMv8
From: Philipp Tomsich As part of the startup process for boards using the SPL, we need to call spl_relocate_stack_gd. This is needed to set up malloc with its DRAM buffer. [Andre: fix comment] Signed-off-by: Philipp Tomsich Reviewed-by: Andre Przywara Reviewed-by: Simon Glass Signed-off-by: Andre Przywara --- arch/arm/lib/crt0_64.S | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index 19c6a98..e59fd3e 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -109,8 +109,18 @@ relocation_return: */ bl c_runtime_cpu_setup /* still call old routine */ #endif /* !CONFIG_SPL_BUILD */ - -/* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */ +#if defined(CONFIG_SPL_BUILD) + bl spl_relocate_stack_gd /* may return NULL */ + /* +* Perform 'sp = (x0 != NULL) ? x0 : sp' while working +* around the constraint that most arm64 instructions cannot +* have 'sp' as an operand. +*/ + mov x1, sp + cmp x0, #0 + cselx0, x0, x1, ne + mov sp, x0 +#endif /* * Clear BSS section -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 02/17] SPL: FIT: refactor FDT loading
Currently the SPL FIT loader uses the spl_fit_select_fdt() function to
find the offset to the right DTB within the FIT image.
For this it iterates over all subnodes of the /configuration node in
the FIT tree and compares all "description" strings therein using a
board specific matching function.
If that finds a match, it uses the string in the "fdt" property of that
subnode to locate the matching subnode in the /images node, which points
to the DTB data.
Now this works very well, but is quite specific to cover this particular
use case. To open up the door for a more generic usage, let's split this
function into:
1) a function that just returns the node offset for the matching
configuration node (spl_fit_find_config_node())
2) a function that returns the image data any given property in a given
configuration node points to, additionally using a given index into
a possbile list of strings (spl_fit_select_index())
This allows us to replace the specific function above by asking for the
image the _first string of the "fdt" property_ in the matching
configuration subnode points to.
This patch introduces no functional changes, it just refactors the code
to allow reusing it later.
(diff is overly clever here and produces a hard-to-read patch, so I
recommend to throw a look at the result instead).
Signed-off-by: Andre Przywara
---
common/spl/spl_fit.c | 83
1 file changed, 52 insertions(+), 31 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index aae556f..ba45e65 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -22,13 +22,11 @@ static ulong fdt_getprop_u32(const void *fdt, int node,
const char *prop)
return fdt32_to_cpu(*cell);
}
-static int spl_fit_select_fdt(const void *fdt, int images, int *fdt_offsetp)
+static int spl_fit_find_config_node(const void *fdt)
{
- const char *name, *fdt_name;
- int conf, node, fdt_node;
- int len;
+ const char *name;
+ int conf, node, len;
- *fdt_offsetp = 0;
conf = fdt_path_offset(fdt, FIT_CONFS_PATH);
if (conf < 0) {
debug("%s: Cannot find /configurations node: %d\n", __func__,
@@ -50,39 +48,61 @@ static int spl_fit_select_fdt(const void *fdt, int images,
int *fdt_offsetp)
continue;
debug("Selecting config '%s'", name);
- fdt_name = fdt_getprop(fdt, node, FIT_FDT_PROP, &len);
- if (!fdt_name) {
- debug("%s: Cannot find fdt name property: %d\n",
- __func__, len);
- return -EINVAL;
- }
- debug(", fdt '%s'\n", fdt_name);
- fdt_node = fdt_subnode_offset(fdt, images, fdt_name);
- if (fdt_node < 0) {
- debug("%s: Cannot find fdt node '%s': %d\n",
- __func__, fdt_name, fdt_node);
- return -EINVAL;
+ return node;
+ }
+
+ return -1;
+}
+
+static int spl_fit_select_index(const void *fit, int images, int *offsetp,
+ const char *type, int index)
+{
+ const char *name, *str;
+ int node, conf_node;
+ int len, i;
+
+ *offsetp = 0;
+ conf_node = spl_fit_find_config_node(fit);
+ if (conf_node < 0) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+ printf("No matching DT out of these options:\n");
+ for (node = fdt_first_subnode(fit, conf_node);
+node >= 0;
+node = fdt_next_subnode(fit, node)) {
+ name = fdt_getprop(fit, node, "description", &len);
+ printf(" %s\n", name);
}
+#endif
+ return -ENOENT;
+ }
- *fdt_offsetp = fdt_getprop_u32(fdt, fdt_node, "data-offset");
- len = fdt_getprop_u32(fdt, fdt_node, "data-size");
- debug("FIT: Selected '%s'\n", name);
+ name = fdt_getprop(fit, conf_node, type, &len);
+ if (!name) {
+ debug("cannot find property '%s': %d\n", type, len);
+ return -EINVAL;
+ }
- return len;
+ str = name;
+ for (i = 0; i < index; i++) {
+ str = strchr(str, '\0') + 1;
+ if (!str || (str - name >= len)) {
+ debug("no string for index %d\n", index);
+ return -E2BIG;
+ }
}
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
- printf("No matching DT out of these options:\n");
- for (node = fdt_first_subnode(fdt, conf);
-node >= 0;
-node = fdt_next_subnode(fdt, node)) {
- name = fdt_getprop(fdt, node, "description", &len);
- printf(" %s\n", name);
+ debug("%s: '%s'\n", type, str);
+ node = fdt_subnode_offset(fit, images, str);
+
[U-Boot] [PATCH 00/17] SPL: extend FIT loading support
This is an updated and slightly extended version of the SPL FIT loading series I posted as an RFC some weeks ago. I tried to fix all bugs that have been pointed out by the diligent reviewers, also added patches to automatically build the FIT images. The first patch is a bug fix for a regression introduced with -rc1. I put this in there to allow people testing the series and to provide an actual patch for this fix, which should make it still into 2017.03. The next four patches introduce the core of the extened SPL FIT loading support, see below for a description. Patches 6-9 make some room in the sunxi 64-bit SPL to allow compiling in the FIT loading bits. Patch 10 and 11 let the SPL choose the proper DT from the FIT image. The next two patches add the infrastructure and an actual generator script, so the FIT image is automatically created at build time. Patches 14 and 15 enable the SPL FIT support in the Pine64 and the OrangePi PC 2 defconfigs. The last two patches are new and eventually store a DT file name in the SPL header, so U-Boot can easily pick the proper DT when scanning the FIT image. The idea is that this DT name should stay with the board, ideally on eMMC or SPI flash. So both U-Boot and a firmware update tool could identify a board, updating with compatible firmware while keeping the DT name in place. Ideally a board vendor would once seed this name onto on-board storage like SPI flash. Let me know what you think! Cheers, Andre. Based on top of sunxi/master (35affe7698e9). --- Currently the FIT format is not used to its full potential in the SPL: It only loads the first image from the /images node and appends the proper FDT. Some boards and platforms would benefit from loading more images before starting U-Boot proper, notably Allwinner A64 and ARMv8 Rockchip boards, which use an ARM Trusted Firmware (ATF) image to be executed before U-Boot. This series tries to solve this in a board agnostic and generic way: We extend the SPL FIT loading scheme to allow loading multiple images. So apart from loading the image which is referenced by the "firmware" property in the respective configuration node and placing the DTB right behind it, we iterate over all strings in the "loadable" property. Each image referenced there will be loaded to its specified load address. The entry point U-Boot eventually branches to will be taken from the first image to explicitly provide the "entry" property, or, if none of them does so, from the load address of the "firmware" image. This keeps the scheme compatible with the FIT images our Makefile creates automatically at the moment. Apart from the already mentioned ATF scenario this opens up more usage scenarios, of which the commit message of patch 04/11 lists some. The remaining patches prepare ane finally enable this scheme for the 64-bit Allwinner boards. Andre Przywara (15): SPL: FIT: refactor FDT loading SPL: FIT: rework U-Boot image loading SPL: FIT: factor out spl_load_fit_image() SPL: FIT: allow loading multiple images tools: mksunxiboot: allow larger SPL binaries armv8: SPL: only compile GIC code if needed armv8: fsl: move ccn504 code into FSL Makefile sunxi: A64: move SPL stack to end of SRAM A2 sunxi: SPL: store RAM size in gd sunxi: SPL: add FIT config selector for Pine64 boards Makefile: add rules to generate SPL FIT images sunxi: A64: Pine64: introduce FIT generator script sunxi: Pine64: defconfig: enable SPL FIT support sunxi: OrangePi-PC2: defconfig: enable SPL FIT support sunxi: use SPL header DT name for FIT board matching Philipp Tomsich (1): armv8: spl: Call spl_relocate_stack_gd for ARMv8 Siarhei Siamashka (1): sunxi: Store the device tree name in the SPL header Kconfig| 17 ++ Makefile | 20 +++ arch/arm/cpu/armv8/fsl-layerscape/Makefile | 1 + arch/arm/include/asm/arch-sunxi/spl.h | 19 ++- arch/arm/lib/Makefile | 3 +- arch/arm/lib/crt0_64.S | 14 +- board/sunxi/board.c| 36 - board/sunxi/mksunxi_fit_atf.sh | 73 + common/spl/spl_fit.c | 246 + configs/orangepi_pc2_defconfig | 6 + configs/pine64_plus_defconfig | 6 + include/configs/sunxi-common.h | 17 +- scripts/Makefile.spl | 3 +- tools/mksunxiboot.c| 51 +- 14 files changed, 387 insertions(+), 125 deletions(-) create mode 100755 board/sunxi/mksunxi_fit_atf.sh -- 2.8.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Complete verified uboot example
I've never seen the kernel load address (the start address for copying
the kernel image into RAM) being the same as the entrypoint address
(where U-Boot jumps to begin executing the kernel). I'd expect the
load address to be 0x2300.
It looks like you are converting the zImage into a U-Boot legacy image
and then storing the legacy image in the FIT. Don't do that. Store
the zImage in the FIT directly.
On Tue, Feb 28, 2017 at 11:09 AM, Ron Brash wrote:
> Hello,
>
> Still for some reason - there is an issue with booting from the FIT. With a
> version of Uboot without the FIT related CONFIGs enabled; everything works.
>
> Here is me taking my zImage and converting it to a u-image ( I am not sure
> on the addresses)
>
> mkimage -A arm -O linux -C none -T kernel -a 0x23008000 -e 0x23008000 -n
> linux-4.4.36b \
> -d $(KDIR)/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage-nDTB2
>
>
> My .its:
>
> /dts-v1/;
> /{
> description = "Configuration to load a Basic Kernel";
> #address-cells = <1>;
> images {
> linux_kernel@1 {
> description = "Linux zImage";
> data =
> /incbin/("../../../../bin/targets/myboard/legacy/myboard-legacy-zImage-nDTB2");
> type = "kernel";
> arch = "arm";
> os = "linux";
> compression = "none";
> load = <0x23008000>;
> entry = <0x23008000>;
> kernel-version = <1>;
> hash@1 {
> algo = "sha256";
> };
> };
> fdt@1 {
> description = "FDT blob";
> data = /incbin/("../../../../bin/targets/myboard/legacy/myboard.dtb");
> type = "flat_dt";
> arch = "arm";
> compression = "none";
> load = <0x2800>;
> fdt-version = <1>;
> hash@1{
> algo = "sha256";
> };
> };
> };
> configurations {
> default = "config@1";
> config@1{
> description = "Plain Linux";
> kernel = "linux_kernel@1";
> fdt = "fdt@1";
> signature@1{
> algo = "sha256,rsa2048";
> key-name-hint = "dev_key";
> sign-images = "fdt", "kernel";
> };
> };
> };
> };
>
>
> Then
>
>
> set -ex
> key_dir="/tmp/keys"
> key_name="dev_key"
>
> rm -rf ${FIT_IMG}
> rm -rf ${key_dir}
> mkdir ${key_dir}
> rootdir="/home/dev/usr"
>
> MKIMG="${rootdir}/lede/staging_dir/host/bin/mkimage"
> DTC="/usr/bin/dtc"
> CPP="/usr/bin/cpp"
> OPENSSL="/usr/bin/openssl"
>
> #Generate a private signing key (RSA2048):
> $OPENSSL genrsa -F4 -out \
> "${key_dir}"/"${key_name}".key 2048
>
> # Generate a public key:
> $OPENSSL req -batch -new -x509 \
> -key "${key_dir}"/"${key_name}".key \
> -out "${key_dir}"/"${key_name}".crt
>
> # Control FDT (u-boot.dts) - hits uboot to have keys etc...
> BD_NAME="at91sam9260-plx35"
> PATH_TO_BIN="${rootdir}/lede/bin/targets/myboard/legacy"
>
> #
> # This is the uboot-nodtb.bin (just renamed)
> #
> UBOOT_NAME="lede-myboard.bin"
> UBOOT_WITH_DTB="${PATH_TO_BIN}/${UBOOT_NAME}"
>
> PATH_TO_CTRL_FDT="${rootdir}/lede/build_dir/target-arm_arm926ej-s_musl-1.1.15_eabi/linux-myboard/myboard-uboot-2016.05/arch/arm/dts/"
>
> CTRL_FDT="${PATH_TO_CTRL_FDT}${BD_NAME}"
>
> FIT_ITS="at91sam9260"
> FIT_IMG="${rootdir}/lede/bin/targets/myboard/legacy/lede-at91-image.fit"
>
> DOPTS="-I dts -O dtb -p 2000"
>
> # Generate fitImage with space for signature:
> echo "create FIT with space - no signing"
> echo " "
> $MKIMG -D "${DOPTS}" \
> -f "${FIT_ITS}".its "${FIT_IMG}"
>
> echo ""
> echo ""
>
> # Now add them and sign them
> echo "Sign images with our keys"
> echo " "
> $MKIMG -D "${DOPTS}" -F \
> -k "${key_dir}" -K "${CTRL_FDT}".dtb -r "${FIT_IMG}"
>
> echo ""
> echo ""
>
> # Add FDT to image
> cp ${UBOOT_WITH_DTB} ${UBOOT_WITH_DTB}-wDTB
> cat ${PATH_TO_CTRL_FDT}/${BD_NAME}.dtb >> ${UBOOT_WITH_DTB}-wDTB
>
>
> Then I flash the uboot-WDTB to the board and also the FIT image. Following
> that, then I load the FIT into RAM and execute it with the command:
>
>
> cp.b 0xD0084000 0x2200 0x186A00;setenv my_bootcount 0; bootm 0x2200
>
> Initial value for argc=3
> Final value for argc=3
> ## Current stack ends at 0x23f119b8 * kernel: cmdline image address =
> 0x2200
> ## Loading kernel from FIT Image at 2200 ...
> No configuration specified, trying default...
> Found default configuration: 'config@1'
>Using 'config@1' configuration
>Trying 'linux_kernel@1' kernel subimage
> Description: Linux zImage
> Type: Kernel Image
> Compression: uncompressed
> Data Start: 0x22dc
> Data Size:1465544 Bytes = 1.4 MiB
> Architecture: ARM
> OS: Linux
> Load Address: 0x23008000
> Entry Point: 0x23008000
> Hash node:'hash@1'
> Hash algo:sha256
> Hash value:
> 52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe
> Hash len: 32
>Verifying Hash Integrity ... sha256+ OK
>kernel data at 0x22dc, len = 0x00165cc8 (1465544)
> * ramdisk: using config 'config@1' from image at 0x2200
> * ramdisk: no 'ramdisk' in config
> * fdt: using config 'config@1' from image at 0x2200
> ## Checking for 'FDT'/'FDT Image' at 2200
> ## Loading fdt from FIT Image at 2200 ...
>Usi
[U-Boot] [PATCH v1] tools: Remove CONFIG_SYS_TEXT_BASE in Makefile
This define is not used in tools sources and can be removed to avoid unnecessary link between tools and defconfig Signed-off-by: Patrick Delaunay --- tools/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/Makefile b/tools/Makefile index 5000f4d..1c840d7 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -246,7 +246,6 @@ HOST_EXTRACFLAGS += -include $(srctree)/include/libfdt_env.h \ $(patsubst -I%,-idirafter%, $(filter -I%, $(UBOOTINCLUDE))) \ -I$(srctree)/lib/libfdt \ -I$(srctree)/tools \ - -DCONFIG_SYS_TEXT_BASE=$(CONFIG_SYS_TEXT_BASE) \ -DUSE_HOSTCC \ -D__KERNEL_STRICT_NAMES \ -D_GNU_SOURCE -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 8/9] defconfig: k2e_hs_evm: Add k2e_hs_evm_defconfig
On Tue, Feb 28, 2017 at 11:47:01AM -0600, Andrew F. Davis wrote: > On 02/27/2017 09:19 AM, Tom Rini wrote: > > On Fri, Feb 24, 2017 at 06:59:45AM -0600, Andrew F. Davis wrote: > > > >> From: Vitaly Andrianov > >> > >> TI K2E secure devices have to be built with TI_SECURE_DEVICE, FIT, and > >> FIT_IMAGE_POST_PROCESS enabled. Add a dedicated defconfig for this. > >> > >> Signed-off-by: Vitaly Andrianov > >> Signed-off-by: Madan Srinivas > >> Signed-off-by: Andrew F. Davis > >> --- > >> configs/k2e_hs_evm_defconfig | 51 > >> > >> 1 file changed, 51 insertions(+) > >> create mode 100644 configs/k2e_hs_evm_defconfig > >> > >> diff --git a/configs/k2e_hs_evm_defconfig b/configs/k2e_hs_evm_defconfig > >> new file mode 100644 > >> index 00..d515cedaca > >> --- /dev/null > >> +++ b/configs/k2e_hs_evm_defconfig > >> @@ -0,0 +1,51 @@ > >> +CONFIG_ARM=y > >> +CONFIG_ARCH_KEYSTONE=y > >> +CONFIG_SYS_TEXT_BASE=0x0c60 > >> +CONFIG_TARGET_K2E_EVM=y > >> +CONFIG_TI_SECURE_DEVICE=y > >> +CONFIG_DEFAULT_DEVICE_TREE="keystone-k2e-evm" > >> +CONFIG_FIT=y > >> +CONFIG_FIT_IMAGE_POST_PROCESS=y > >> +CONFIG_OF_BOARD_SETUP=y > >> +CONFIG_SYS_CONSOLE_INFO_QUIET=y > >> +CONFIG_VERSION_VARIABLE=y > >> +CONFIG_HUSH_PARSER=y > >> +CONFIG_SYS_PROMPT="K2E HS EVM # " > >> +CONFIG_CMD_BOOTZ=y > >> +# CONFIG_CMD_IMLS is not set > >> +CONFIG_CMD_ASKENV=y > >> +# CONFIG_CMD_FLASH is not set > >> +CONFIG_CMD_NAND=y > >> +CONFIG_CMD_PART=y > >> +CONFIG_CMD_SF=y > >> +CONFIG_CMD_SPI=y > >> +CONFIG_CMD_I2C=y > >> +CONFIG_CMD_USB=y > >> +# CONFIG_CMD_SETEXPR is not set > >> +CONFIG_CMD_DHCP=y > >> +CONFIG_CMD_MII=y > >> +CONFIG_CMD_PING=y > >> +CONFIG_CMD_EXT2=y > >> +CONFIG_CMD_EXT4=y > >> +CONFIG_CMD_EXT4_WRITE=y > >> +CONFIG_CMD_FAT=y > >> +CONFIG_CMD_FS_GENERIC=y > >> +CONFIG_CMD_UBI=y > >> +CONFIG_ISO_PARTITION=y > >> +CONFIG_EFI_PARTITION=y > >> +CONFIG_OF_CONTROL=y > >> +CONFIG_NET_RANDOM_ETHADDR=y > >> +CONFIG_DM=y > >> +CONFIG_TI_AEMIF=y > >> +# CONFIG_MMC is not set > >> +CONFIG_DM_SPI_FLASH=y > >> +CONFIG_SPI_FLASH=y > >> +CONFIG_SPI_FLASH_STMICRO=y > >> +CONFIG_DM_ETH=y > >> +CONFIG_DM_SERIAL=y > >> +CONFIG_SYS_NS16550=y > >> +CONFIG_DM_SPI=y > >> +CONFIG_USB=y > >> +CONFIG_USB_XHCI_HCD=y > >> +CONFIG_USB_XHCI_DWC3=y > >> +CONFIG_USB_STORAGE=y > > > > This shows a number of the will-be-problems like the AM43/AM33 devices > > have. More things need to be select'd and imply'd so that the _hs_ > > variant defconfigs do not get out of sync easily and often. > > > > I do not think selecting all these options in Kconfig files is safe > right now, at least until moving some more symbols to Kconfig is > complete. After that we can add proper dependencies to all the symbols > and some things like _CMD_ symbols could be added automatically. > > Defconfigs are easier to cleanup than Kconfig definitions. I do not want > to maintain the per-platform Kconfig select'd list before we get symbol > dependencies worked out. Well, at the end of the day, the pain is on you on re-syncing the defconfig files, so if you want to wait on adding more logic, OK, I'll remove my objection. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 8/9] defconfig: k2e_hs_evm: Add k2e_hs_evm_defconfig
On 02/27/2017 09:19 AM, Tom Rini wrote: > On Fri, Feb 24, 2017 at 06:59:45AM -0600, Andrew F. Davis wrote: > >> From: Vitaly Andrianov >> >> TI K2E secure devices have to be built with TI_SECURE_DEVICE, FIT, and >> FIT_IMAGE_POST_PROCESS enabled. Add a dedicated defconfig for this. >> >> Signed-off-by: Vitaly Andrianov >> Signed-off-by: Madan Srinivas >> Signed-off-by: Andrew F. Davis >> --- >> configs/k2e_hs_evm_defconfig | 51 >> >> 1 file changed, 51 insertions(+) >> create mode 100644 configs/k2e_hs_evm_defconfig >> >> diff --git a/configs/k2e_hs_evm_defconfig b/configs/k2e_hs_evm_defconfig >> new file mode 100644 >> index 00..d515cedaca >> --- /dev/null >> +++ b/configs/k2e_hs_evm_defconfig >> @@ -0,0 +1,51 @@ >> +CONFIG_ARM=y >> +CONFIG_ARCH_KEYSTONE=y >> +CONFIG_SYS_TEXT_BASE=0x0c60 >> +CONFIG_TARGET_K2E_EVM=y >> +CONFIG_TI_SECURE_DEVICE=y >> +CONFIG_DEFAULT_DEVICE_TREE="keystone-k2e-evm" >> +CONFIG_FIT=y >> +CONFIG_FIT_IMAGE_POST_PROCESS=y >> +CONFIG_OF_BOARD_SETUP=y >> +CONFIG_SYS_CONSOLE_INFO_QUIET=y >> +CONFIG_VERSION_VARIABLE=y >> +CONFIG_HUSH_PARSER=y >> +CONFIG_SYS_PROMPT="K2E HS EVM # " >> +CONFIG_CMD_BOOTZ=y >> +# CONFIG_CMD_IMLS is not set >> +CONFIG_CMD_ASKENV=y >> +# CONFIG_CMD_FLASH is not set >> +CONFIG_CMD_NAND=y >> +CONFIG_CMD_PART=y >> +CONFIG_CMD_SF=y >> +CONFIG_CMD_SPI=y >> +CONFIG_CMD_I2C=y >> +CONFIG_CMD_USB=y >> +# CONFIG_CMD_SETEXPR is not set >> +CONFIG_CMD_DHCP=y >> +CONFIG_CMD_MII=y >> +CONFIG_CMD_PING=y >> +CONFIG_CMD_EXT2=y >> +CONFIG_CMD_EXT4=y >> +CONFIG_CMD_EXT4_WRITE=y >> +CONFIG_CMD_FAT=y >> +CONFIG_CMD_FS_GENERIC=y >> +CONFIG_CMD_UBI=y >> +CONFIG_ISO_PARTITION=y >> +CONFIG_EFI_PARTITION=y >> +CONFIG_OF_CONTROL=y >> +CONFIG_NET_RANDOM_ETHADDR=y >> +CONFIG_DM=y >> +CONFIG_TI_AEMIF=y >> +# CONFIG_MMC is not set >> +CONFIG_DM_SPI_FLASH=y >> +CONFIG_SPI_FLASH=y >> +CONFIG_SPI_FLASH_STMICRO=y >> +CONFIG_DM_ETH=y >> +CONFIG_DM_SERIAL=y >> +CONFIG_SYS_NS16550=y >> +CONFIG_DM_SPI=y >> +CONFIG_USB=y >> +CONFIG_USB_XHCI_HCD=y >> +CONFIG_USB_XHCI_DWC3=y >> +CONFIG_USB_STORAGE=y > > This shows a number of the will-be-problems like the AM43/AM33 devices > have. More things need to be select'd and imply'd so that the _hs_ > variant defconfigs do not get out of sync easily and often. > I do not think selecting all these options in Kconfig files is safe right now, at least until moving some more symbols to Kconfig is complete. After that we can add proper dependencies to all the symbols and some things like _CMD_ symbols could be added automatically. Defconfigs are easier to cleanup than Kconfig definitions. I do not want to maintain the per-platform Kconfig select'd list before we get symbol dependencies worked out. Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory
On Wed, Mar 01, 2017 at 02:03:58AM +0900, Masahiro Yamada wrote:
> Hi Tom,
>
> 2017-02-27 7:41 GMT+09:00 Tom Rini :
> > On Thu, Feb 23, 2017 at 10:31:17AM -0500, Tom Rini wrote:
> >> On Thu, Feb 23, 2017 at 06:17:38PM +0900, Masahiro Yamada wrote:
> >> > Hi Tom,
> >> >
> >> >
> >> > 2017-02-23 1:19 GMT+09:00 Tom Rini :
> >> > > On Wed, Feb 22, 2017 at 11:34:26AM +0900, Masahiro Yamada wrote:
> >> > >
> >> > >> At first, the ARM64 Linux booting requirement recommended that the
> >> > >> kernel image be placed text_offset bytes from 2MB aligned base near
> >> > >> the start of usable system RAM because memory below that base address
> >> > >> was unusable at that time.
> >> > >>
> >> > >> This requirement was relaxed by Linux commit a7f8de168ace ("arm64:
> >> > >> allow kernel Image to be loaded anywhere in physical memory").
> >> > >> Since then, the bit 3 of the flags field indicates the tolerance
> >> > >> of the kernel physical placement. If this bit is set, the 2MB
> >> > >> aligned base may be anywhere in physical memory. For details, see
> >> > >> Documentation/arm64/booting.txt of Linux.
> >> > >>
> >> > >> The booti command should be also relaxed to not expect the kernel
> >> > >> image at the start of the system RAM. Even when booting older
> >> > >> kernel versions, it still makes sense to have some space below the
> >> > >> kernel. For example, some firmware may sit at the start of the
> >> > >> system RAM.
> >> > >>
> >> > >> After all, the most flexible way for booting the kernel is to respect
> >> > >> the original images->ep instead of gd->bd->bi_dram[0].start. If
> >> > >> image->ep (which is the address given to the booti command) already
> >> > >> meets the address requirement, just use it. If not, relocate the
> >> > >> kernel to the next 2MB aligned address.
> >> > >>
> >> > >> Signed-off-by: Masahiro Yamada
> >> > >> ---
> >> > >>
> >> > >> cmd/booti.c | 6 +-
> >> > >> 1 file changed, 5 insertions(+), 1 deletion(-)
> >> > >>
> >> > >> diff --git a/cmd/booti.c b/cmd/booti.c
> >> > >> index f65f0e7..9408c34 100644
> >> > >> --- a/cmd/booti.c
> >> > >> +++ b/cmd/booti.c
> >> > >> @@ -11,6 +11,8 @@
> >> > >> #include
> >> > >> #include
> >> > >> #include
> >> > >> +#include
> >> > >> +#include
> >> > >>
> >> > >> DECLARE_GLOBAL_DATA_PTR;
> >> > >>
> >> > >> @@ -54,7 +56,9 @@ static int booti_setup(bootm_headers_t *images)
> >> > >>* If we are not at the correct run-time location, set the new
> >> > >>* correct location and then move the image there.
> >> > >>*/
> >> > >> - dst = gd->bd->bi_dram[0].start + le64_to_cpu(ih->text_offset);
> >> > >> + dst = images->ep - ih->text_offset;
> >> > >> + dst = ALIGN(dst, SZ_2M);
> >> > >> + dst += ih->text_offset;
> >> > >
> >> > > I think the code will be slightly more complex here but I would rather
> >> > > see us check for the presence of the flag which allows for us to
> >> > > relocate things rather than assume that we can always use the address
> >> > > provided, or round it up. The 'contract' wwith the kernel previously
> >> > > said it must be from start of memory and I'd rather not change that.
> >> >
> >> >
> >> > At first, I tried this approach.
> >> >
> >> > The problem (at least for me) is
> >> > commit a7f8de168ace is quite new; this is only included in Linux 4.5 and
> >> > later.
> >> > Linux 4.4 LTS will be used on Socionext's products for a while.
> >> > However, I need to avoid the relocation of the kernel image.
> >> >
> >> > The gd->bd->bi_dram[0].start points to the start of the DRAM.
> >> > Here, some firmware is sitting at the start of the DRAM.
> >> > To hide the head of the memory from Linux,
> >> > the memory node in the device tree is carved out.
> >> >
> >> > If CONFIG_ARCH_FIXUP_FDT_MEMORY is not set,
> >> > U-Boot passes the memory node as-is to Linux.
> >> > As a result, the Image is placed out of the available memory region
> >> > specified by DT,
> >> > then Linux fails to boot.
> >> >
> >> >
> >> > Somehow I want to achieve,
> >> > "Even when booting older kernel versions, it still makes sense to have
> >> > some space below the
> >> > kernel. For example, some firmware may sit at the start of the system
> >> > RAM."
> >> >
> >> >
> >> > Perhaps, can we introduce a CONFIG
> >> > to enable/disable the relocation?
> >> > Or, any other good idea?
> >>
> >> I guess the answer is that I need to find some time to re-read the
> >> history on Documentation/arm64/booting.txt to see when various
> >> restrictions changed / were introduced. I'm also willing to say that
> >> perhaps my initial implementation (or the follow up when text_offset was
> >> introduced) was incorrectly too strict.
> >
> > So, I re-read what the changes to the document were, before and after.
> > Prior to the change, the kernel will not be able to use any memory below
> > the 2MiB aligned address. After the change, the memory must be excluded
> > using normal mechanisms (and is outside
Re: [U-Boot] [PATCH] spi: cadence_qspi_apb: Add trigger-base DT bindings from Linux
R, Vignesh wrote: > On 2/28/2017 8:38 PM, Rush, Jason A. wrote: > [...] >> >> This also works. >> >> Marek - how do you feel about a patch series with the following: >> >> 1. revert commit 57897c13de03ac0136d64641a3eab526c6810387 >> spi: cadence_qspi_apb: Use 32 bit indirect write transaction when >> possible >> 2. revert commit b63b46313ed29e9b0c36b3d6b9407f6eade40c8f >> spi: cadence_qspi_apb: Use 32 bit indirect read transaction when >> possible >> 3. Apply my slightly modified version of >> https://patchwork.ozlabs.org/patch/693069/ >> (should I keep Vignesh as the signed-off?) > > Depends on how much you have changed the code. If the change is > significant then change the authorship to you and drop my signed-off. > Else, keep the authorship and signed-off. > If you are adding something new to the patch like adding code to make > sure that only 32bit data reads are issued, then I suggest you to submit > that change as separate patch. Very minimal. Another commit changed a #define from CQSPI_REG_INDIRECTWR_START_MASK to CQSPI_REG_INDIRECTWR_START, so I had to modify the patch to drop the _MASK so it would apply. Other than that, it's identical in content. > >> 4. Clean-up loading the reg variables to use fdtdec_get_addr_xxx(...) and >> mark >> them all as __iomem >> 5. Load the indirect-trigger property from the DT as a u32. I think this >> still >> needs to be a u32 because it's used in a writel(...) 32-bit write call >> in >> cadence_qspi_apb.c >> 6. Add indirect-trigger to dts files that use cadence driver >> >> I think that captures all the changes needed. >> >> Also, for the naming of the DT property, Linux has uses a 'cdns,' prefix >> (e.g. cdns,trigger-address) for a number of their properties (cdns,tshsl-ns, >> cdns,tsd2d-ns, etc.), but u-boot does not currently use the 'cdns,' prefix >> for >> the same properties. Do you want the 'cdns,' prefix on trigger-address? >> If so, do you want me to rename all the other properties to align them with >> the Linux DT as an additional patch? >> -- Regards, Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm64: booti: allow to place kernel image anywhere in physical memory
Hi Tom,
2017-02-27 7:41 GMT+09:00 Tom Rini :
> On Thu, Feb 23, 2017 at 10:31:17AM -0500, Tom Rini wrote:
>> On Thu, Feb 23, 2017 at 06:17:38PM +0900, Masahiro Yamada wrote:
>> > Hi Tom,
>> >
>> >
>> > 2017-02-23 1:19 GMT+09:00 Tom Rini :
>> > > On Wed, Feb 22, 2017 at 11:34:26AM +0900, Masahiro Yamada wrote:
>> > >
>> > >> At first, the ARM64 Linux booting requirement recommended that the
>> > >> kernel image be placed text_offset bytes from 2MB aligned base near
>> > >> the start of usable system RAM because memory below that base address
>> > >> was unusable at that time.
>> > >>
>> > >> This requirement was relaxed by Linux commit a7f8de168ace ("arm64:
>> > >> allow kernel Image to be loaded anywhere in physical memory").
>> > >> Since then, the bit 3 of the flags field indicates the tolerance
>> > >> of the kernel physical placement. If this bit is set, the 2MB
>> > >> aligned base may be anywhere in physical memory. For details, see
>> > >> Documentation/arm64/booting.txt of Linux.
>> > >>
>> > >> The booti command should be also relaxed to not expect the kernel
>> > >> image at the start of the system RAM. Even when booting older
>> > >> kernel versions, it still makes sense to have some space below the
>> > >> kernel. For example, some firmware may sit at the start of the
>> > >> system RAM.
>> > >>
>> > >> After all, the most flexible way for booting the kernel is to respect
>> > >> the original images->ep instead of gd->bd->bi_dram[0].start. If
>> > >> image->ep (which is the address given to the booti command) already
>> > >> meets the address requirement, just use it. If not, relocate the
>> > >> kernel to the next 2MB aligned address.
>> > >>
>> > >> Signed-off-by: Masahiro Yamada
>> > >> ---
>> > >>
>> > >> cmd/booti.c | 6 +-
>> > >> 1 file changed, 5 insertions(+), 1 deletion(-)
>> > >>
>> > >> diff --git a/cmd/booti.c b/cmd/booti.c
>> > >> index f65f0e7..9408c34 100644
>> > >> --- a/cmd/booti.c
>> > >> +++ b/cmd/booti.c
>> > >> @@ -11,6 +11,8 @@
>> > >> #include
>> > >> #include
>> > >> #include
>> > >> +#include
>> > >> +#include
>> > >>
>> > >> DECLARE_GLOBAL_DATA_PTR;
>> > >>
>> > >> @@ -54,7 +56,9 @@ static int booti_setup(bootm_headers_t *images)
>> > >>* If we are not at the correct run-time location, set the new
>> > >>* correct location and then move the image there.
>> > >>*/
>> > >> - dst = gd->bd->bi_dram[0].start + le64_to_cpu(ih->text_offset);
>> > >> + dst = images->ep - ih->text_offset;
>> > >> + dst = ALIGN(dst, SZ_2M);
>> > >> + dst += ih->text_offset;
>> > >
>> > > I think the code will be slightly more complex here but I would rather
>> > > see us check for the presence of the flag which allows for us to
>> > > relocate things rather than assume that we can always use the address
>> > > provided, or round it up. The 'contract' wwith the kernel previously
>> > > said it must be from start of memory and I'd rather not change that.
>> >
>> >
>> > At first, I tried this approach.
>> >
>> > The problem (at least for me) is
>> > commit a7f8de168ace is quite new; this is only included in Linux 4.5 and
>> > later.
>> > Linux 4.4 LTS will be used on Socionext's products for a while.
>> > However, I need to avoid the relocation of the kernel image.
>> >
>> > The gd->bd->bi_dram[0].start points to the start of the DRAM.
>> > Here, some firmware is sitting at the start of the DRAM.
>> > To hide the head of the memory from Linux,
>> > the memory node in the device tree is carved out.
>> >
>> > If CONFIG_ARCH_FIXUP_FDT_MEMORY is not set,
>> > U-Boot passes the memory node as-is to Linux.
>> > As a result, the Image is placed out of the available memory region
>> > specified by DT,
>> > then Linux fails to boot.
>> >
>> >
>> > Somehow I want to achieve,
>> > "Even when booting older kernel versions, it still makes sense to have
>> > some space below the
>> > kernel. For example, some firmware may sit at the start of the system
>> > RAM."
>> >
>> >
>> > Perhaps, can we introduce a CONFIG
>> > to enable/disable the relocation?
>> > Or, any other good idea?
>>
>> I guess the answer is that I need to find some time to re-read the
>> history on Documentation/arm64/booting.txt to see when various
>> restrictions changed / were introduced. I'm also willing to say that
>> perhaps my initial implementation (or the follow up when text_offset was
>> introduced) was incorrectly too strict.
>
> So, I re-read what the changes to the document were, before and after.
> Prior to the change, the kernel will not be able to use any memory below
> the 2MiB aligned address. After the change, the memory must be excluded
> using normal mechanisms (and is outside of this problem here). So,
> conceptually, I'm OK with changing our logic here a bit, what I did at
> first wrt text_offset was too literal. But:
> a) We need to re-work the comment in question now to explain a little
> better what is going on.
Yes.
> b) we should continue to use l
Re: [U-Boot] [PATCH] spi: cadence_qspi_apb: Add trigger-base DT bindings from Linux
On 2/28/2017 8:38 PM, Rush, Jason A. wrote: [...] > > This also works. > > Marek - how do you feel about a patch series with the following: > > 1. revert commit 57897c13de03ac0136d64641a3eab526c6810387 > spi: cadence_qspi_apb: Use 32 bit indirect write transaction when > possible > 2. revert commit b63b46313ed29e9b0c36b3d6b9407f6eade40c8f > spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible > 3. Apply my slightly modified version of > https://patchwork.ozlabs.org/patch/693069/ > (should I keep Vignesh as the signed-off?) Depends on how much you have changed the code. If the change is significant then change the authorship to you and drop my signed-off. Else, keep the authorship and signed-off. If you are adding something new to the patch like adding code to make sure that only 32bit data reads are issued, then I suggest you to submit that change as separate patch. > 4. Clean-up loading the reg variables to use fdtdec_get_addr_xxx(...) and mark > them all as __iomem > 5. Load the indirect-trigger property from the DT as a u32. I think this > still > needs to be a u32 because it's used in a writel(...) 32-bit write call in > cadence_qspi_apb.c > 6. Add indirect-trigger to dts files that use cadence driver > > I think that captures all the changes needed. > > Also, for the naming of the DT property, Linux has uses a 'cdns,' prefix > (e.g. cdns,trigger-address) for a number of their properties (cdns,tshsl-ns, > cdns,tsd2d-ns, etc.), but u-boot does not currently use the 'cdns,' prefix for > the same properties. Do you want the 'cdns,' prefix on trigger-address? > If so, do you want me to rename all the other properties to align them with > the Linux DT as an additional patch? > > -- > Regards, > Jason > -- Regards Vignesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] Device cleanup before starting OS (Linux)
Hi! I'm currently trying to add some code to stop (DMA) buffer usage in the Marvell mvpp2 ethernet driver, that should only be executed once, before the OS is started - stop() does not work easily for me here. I've found the weak function "board_quiesce_devices()", which is already used for such cases. But since you are not fond of weak functions (I totally agree here, this is far from perfect) and already suggested some kind of "finalize" DM API call, I'm wondering if I should introduce this new API call for such cases and use it in the ethernet driver. So what is your opinion about this? Should I add such a finalize DM function and call it from the arch/.../bootm code? Or do you have other suggestions on how to handle such driver specific last-stage (pre OS) calls? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/8] armv8: Add workaround for USB erratum A-009007
On 02/28/2017 02:52 AM, Suresh Gupta wrote: > > >> -Original Message- >> From: york sun >> Sent: Friday, February 24, 2017 10:31 PM >> To: Suresh Gupta >> Cc: u-boot@lists.denx.de; Scott Wood ; Leo Li >> ; Sriram Dash ; Rajesh Bhagat >> >> Subject: Re: [PATCH v3 4/8] armv8: Add workaround for USB erratum A-009007 >> >> On 02/23/2017 11:19 PM, Suresh Gupta wrote: >>> Hi York, >>> >>> It is not good idea to change the values of all macro at this time as the >>> code >> tested on different platforms. >> >> I am not talking about any value change. You are using writew. Why not using >> out_be16 as you thought? > > For now all values in macro (like USB_PHY_RX_EQ_VAL_2) are swapped and > if I want to use out_be16, then I need to change values of all macros, > which intern require testing on all platform. > That’s the reason, I don’t want to make such changes and break the working USB > Suresh, This erratum only applies to LS1043A, LS1046A, LS2080A. It wouldn't be too much trouble to verify all of them. I'd rather we do it right at the first place than coming back to fix it. Are you in a rush to get this patch out? Another thing, please drop defined(CONFIG_ARCH_LS2085A) for all the patches. We only use CONFIG_ARCH_LS2080A. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] Support additional Variant for TQMa6 SOM
On 28/02/2017 16:37, Markus Niebel wrote: > From: Markus Niebel > > Add support for the SOM variant featuring i.MX6DL. This needs a new > DCD config. The first patch is a small preparation. > > Changes for v2: > - Rebase on u-boot-imx master > - Fix minor issues in defconfig files > > Markus Niebel (2): > arm: imx6: tqma6: use CONFIG_TQM6x for SOM specific settings > arm: imx6: tqma6: add support for TQMa6DL variant > > board/tqc/tqma6/Kconfig| 7 +++ > board/tqc/tqma6/README | 3 + > board/tqc/tqma6/tqma6.c| 7 +++ > board/tqc/tqma6/tqma6_mba6.c | 14 +++-- > board/tqc/tqma6/tqma6dl.cfg| 125 > + > configs/tqma6dl_mba6_mmc_defconfig | 36 +++ > configs/tqma6dl_mba6_spi_defconfig | 37 +++ > include/configs/tqma6.h| 16 ++--- > include/configs/tqma6_mba6.h | 5 +- > 9 files changed, 235 insertions(+), 15 deletions(-) > create mode 100644 board/tqc/tqma6/tqma6dl.cfg > create mode 100644 configs/tqma6dl_mba6_mmc_defconfig > create mode 100644 configs/tqma6dl_mba6_spi_defconfig > Fine with me - I have dropped the old ones from -next, I wait a couple of days if someone has comments, then I merge them again in -next. Regards, Stefano -- Meet DENX at the Embedded World Trade Show 14 Mar - 16 Mar 2017, Nuremberg Trade Fair Centre, Hall 4, Booth 581 -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] arm: imx6: tqma6: use CONFIG_TQM6x for SOM specific settings
From: Markus Niebel
We have a Kconfig name for the module types. Let's Use it.
Some feature selections and configurations are based on the
module. Module selection selects the CPU type.
Signed-off-by: Markus Niebel
---
board/tqc/tqma6/tqma6_mba6.c | 13 +++--
include/configs/tqma6.h | 8
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/board/tqc/tqma6/tqma6_mba6.c b/board/tqc/tqma6/tqma6_mba6.c
index 4db1a0b..b51751d 100644
--- a/board/tqc/tqma6/tqma6_mba6.c
+++ b/board/tqc/tqma6/tqma6_mba6.c
@@ -54,19 +54,19 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
PAD_CTL_ODE | PAD_CTL_SRE_FAST)
-#if defined(CONFIG_MX6Q)
+#if defined(CONFIG_TQMA6Q)
#define IOMUX_SW_PAD_CTRL_GRP_DDR_TYPE_RGMII 0x02e0790
#define IOMUX_SW_PAD_CTRL_GRP_RGMII_TERM 0x02e07ac
-#elif defined(CONFIG_MX6S)
+#elif defined(CONFIG_TQMA6S)
#define IOMUX_SW_PAD_CTRL_GRP_DDR_TYPE_RGMII 0x02e0768
#define IOMUX_SW_PAD_CTRL_GRP_RGMII_TERM 0x02e0788
#else
-#error "need to define target CPU"
+#error "need to select module"
#endif
@@ -259,14 +259,15 @@ int board_phy_config(struct phy_device *phydev)
{
/*
* optimized pad skew values depends on CPU variant on the TQMa6x module:
- * i.MX6Q/D or i.MX6DL/S
+ * CONFIG_TQMA6Q: i.MX6Q/D
+ * CONFIG_TQMA6S: i.MX6S
*/
-#if defined(CONFIG_MX6Q) || defined(CONFIG_MX6Q)
+#if defined(CONFIG_TQMA6Q)
#define MBA6X_KSZ9031_CTRL_SKEW0x0032
#define MBA6X_KSZ9031_CLK_SKEW 0x03ff
#define MBA6X_KSZ9031_RX_SKEW 0x
#define MBA6X_KSZ9031_TX_SKEW 0x2036
-#elif defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
+#elif defined(CONFIG_TQMA6S)
#define MBA6X_KSZ9031_CTRL_SKEW0x0030
#define MBA6X_KSZ9031_CLK_SKEW 0x03ff
#define MBA6X_KSZ9031_RX_SKEW 0x
diff --git a/include/configs/tqma6.h b/include/configs/tqma6.h
index 1c0a762..2a63686 100644
--- a/include/configs/tqma6.h
+++ b/include/configs/tqma6.h
@@ -18,17 +18,17 @@
/* #endif */
/* place code in last 4 MiB of RAM */
-#if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
+#if defined(CONFIG_TQMA6S)
#define CONFIG_SYS_TEXT_BASE 0x2fc0
-#elif defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
+#elif defined(CONFIG_TQMA6Q)
#define CONFIG_SYS_TEXT_BASE 0x4fc0
#endif
#include "mx6_common.h"
-#if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
+#if defined(CONFIG_TQMA6S)
#define PHYS_SDRAM_SIZE(512u * SZ_1M)
-#elif defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
+#elif defined(CONFIG_TQMA6Q)
#define PHYS_SDRAM_SIZE(1024u * SZ_1M)
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] arm: imx6: tqma6: add support for TQMa6DL variant
From: Markus Niebel
This adds support for TQMa6DL using i.MX6DL and 1GiB DRAM
Since The module will use the same devicetree, we patch
the ram size in ft_board_setup.
Signed-off-by: Markus Niebel
---
board/tqc/tqma6/Kconfig| 7 +++
board/tqc/tqma6/README | 3 +
board/tqc/tqma6/tqma6.c| 7 +++
board/tqc/tqma6/tqma6_mba6.c | 5 +-
board/tqc/tqma6/tqma6dl.cfg| 125 +
configs/tqma6dl_mba6_mmc_defconfig | 34 ++
configs/tqma6dl_mba6_spi_defconfig | 35 +++
include/configs/tqma6.h| 10 +--
include/configs/tqma6_mba6.h | 5 +-
9 files changed, 223 insertions(+), 8 deletions(-)
create mode 100644 board/tqc/tqma6/tqma6dl.cfg
create mode 100644 configs/tqma6dl_mba6_mmc_defconfig
create mode 100644 configs/tqma6dl_mba6_spi_defconfig
diff --git a/board/tqc/tqma6/Kconfig b/board/tqc/tqma6/Kconfig
index 5dafa38..6df4134 100644
--- a/board/tqc/tqma6/Kconfig
+++ b/board/tqc/tqma6/Kconfig
@@ -22,6 +22,12 @@ config TQMA6Q
help
select TQMa6Q / TQMa6D with i.MX6Q/D and 1GiB DRAM
+config TQMA6DL
+ bool "TQMa6DL"
+ select MX6DL
+ help
+ select TQMa6DL with i.MX6DL and 1GiB DRAM
+
config TQMA6S
bool "TQMa6S"
select MX6S
@@ -70,6 +76,7 @@ endchoice
config IMX_CONFIG
default "board/tqc/tqma6/tqma6q.cfg" if TQMA6Q
+ default "board/tqc/tqma6/tqma6dl.cfg" if TQMA6DL
default "board/tqc/tqma6/tqma6s.cfg" if TQMA6S
endif
diff --git a/board/tqc/tqma6/README b/board/tqc/tqma6/README
index 2c012e7..c47cb21 100644
--- a/board/tqc/tqma6/README
+++ b/board/tqc/tqma6/README
@@ -21,6 +21,7 @@ To build U-Boot for the TQ Systems TQMa6 modules:
x is a placeholder for the CPU variant
q - means i.MX6Q/D: TQMa6Q (i.MX6Q) and TQMa6D (i.MX6D)
+dl - means i.MX6DL: TQMa6DL (i.MX6DL)
s - means i.MX6S: TQMa6S (i.MX6S)
baseboard is a placeholder for the boot device
@@ -31,5 +32,7 @@ This gives the following configurations:
tqma6q_mba6_mmc_config
tqma6q_mba6_spi_config
+tqma6dl_mba6_mmc_config
+tqma6dl_mba6_spi_config
tqma6s_mba6_mmc_config
tqma6s_mba6_spi_config
diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c
index c8fc95d..775ca21 100644
--- a/board/tqc/tqma6/tqma6.c
+++ b/board/tqc/tqma6/tqma6.c
@@ -267,8 +267,15 @@ int checkboard(void)
* Device Tree Support
*/
#if defined(CONFIG_OF_BOARD_SETUP) && defined(CONFIG_OF_LIBFDT)
+#define MODELSTRLEN 32u
int ft_board_setup(void *blob, bd_t *bd)
{
+ char modelstr[MODELSTRLEN];
+
+ snprintf(modelstr, MODELSTRLEN, "TQ %s on %s", tqma6_get_boardname(),
+tqma6_bb_get_boardname());
+ do_fixup_by_path_string(blob, "/", "model", modelstr);
+ fdt_fixup_memory(blob, (u64)PHYS_SDRAM, (u64)gd->ram_size);
/* bring in eMMC dsr settings */
do_fixup_by_path_u32(blob,
"/soc/aips-bus@0210/usdhc@02198000",
diff --git a/board/tqc/tqma6/tqma6_mba6.c b/board/tqc/tqma6/tqma6_mba6.c
index b51751d..65a8eab 100644
--- a/board/tqc/tqma6/tqma6_mba6.c
+++ b/board/tqc/tqma6/tqma6_mba6.c
@@ -59,7 +59,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define IOMUX_SW_PAD_CTRL_GRP_DDR_TYPE_RGMII 0x02e0790
#define IOMUX_SW_PAD_CTRL_GRP_RGMII_TERM 0x02e07ac
-#elif defined(CONFIG_TQMA6S)
+#elif defined(CONFIG_TQMA6S) || defined(CONFIG_TQMA6DL)
#define IOMUX_SW_PAD_CTRL_GRP_DDR_TYPE_RGMII 0x02e0768
#define IOMUX_SW_PAD_CTRL_GRP_RGMII_TERM 0x02e0788
@@ -261,13 +261,14 @@ int board_phy_config(struct phy_device *phydev)
* optimized pad skew values depends on CPU variant on the TQMa6x module:
* CONFIG_TQMA6Q: i.MX6Q/D
* CONFIG_TQMA6S: i.MX6S
+ * CONFIG_TQMA6DL: i.MX6DL
*/
#if defined(CONFIG_TQMA6Q)
#define MBA6X_KSZ9031_CTRL_SKEW0x0032
#define MBA6X_KSZ9031_CLK_SKEW 0x03ff
#define MBA6X_KSZ9031_RX_SKEW 0x
#define MBA6X_KSZ9031_TX_SKEW 0x2036
-#elif defined(CONFIG_TQMA6S)
+#elif defined(CONFIG_TQMA6S) || defined(CONFIG_TQMA6DL)
#define MBA6X_KSZ9031_CTRL_SKEW0x0030
#define MBA6X_KSZ9031_CLK_SKEW 0x03ff
#define MBA6X_KSZ9031_RX_SKEW 0x
diff --git a/board/tqc/tqma6/tqma6dl.cfg b/board/tqc/tqma6/tqma6dl.cfg
new file mode 100644
index 000..716033f
--- /dev/null
+++ b/board/tqc/tqma6/tqma6dl.cfg
@@ -0,0 +1,125 @@
+/*
+ * Copyright (C) 2014 - 2015 Markus Niebel
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Refer doc/README.imximage for more details about how-to configure
+ * and create imximage boot image
+ *
+ * The syntax is taken as close as possible with the kwbimage
+ */
+
+/* image version */
+IMAGE_VERSION 2
+
+#define __ASSEMBLY__
+#include
+
+/*
+ * Boot Device : one of
+ * spi, sd (the board has no nand neither onenand)
+ */
+#if defined(CONFIG_TQMA6X_MMC_BOOT)
+BOOT_FROM sd
+#elif defined(CONFIG_TQMA6X_SPI_BOOT)
+BOOT_FROM spi
+#endif
+
+#include "asm/arch/mx6-ddr.h"
+#include "asm/arch/iomux.h"
+#include "asm/arch/crm_regs.h
[U-Boot] [PATCH v2 0/2] Support additional Variant for TQMa6 SOM
From: Markus Niebel Add support for the SOM variant featuring i.MX6DL. This needs a new DCD config. The first patch is a small preparation. Changes for v2: - Rebase on u-boot-imx master - Fix minor issues in defconfig files Markus Niebel (2): arm: imx6: tqma6: use CONFIG_TQM6x for SOM specific settings arm: imx6: tqma6: add support for TQMa6DL variant board/tqc/tqma6/Kconfig| 7 +++ board/tqc/tqma6/README | 3 + board/tqc/tqma6/tqma6.c| 7 +++ board/tqc/tqma6/tqma6_mba6.c | 14 +++-- board/tqc/tqma6/tqma6dl.cfg| 125 + configs/tqma6dl_mba6_mmc_defconfig | 36 +++ configs/tqma6dl_mba6_spi_defconfig | 37 +++ include/configs/tqma6.h| 16 ++--- include/configs/tqma6_mba6.h | 5 +- 9 files changed, 235 insertions(+), 15 deletions(-) create mode 100644 board/tqc/tqma6/tqma6dl.cfg create mode 100644 configs/tqma6dl_mba6_mmc_defconfig create mode 100644 configs/tqma6dl_mba6_spi_defconfig -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: cadence_qspi_apb: Add trigger-base DT bindings from Linux
I don't know if this message successfully sent last weekend. My mail server was undergoing maintenance, and I didn't see my original message on the u-boot mailing list archive. So I'm resending, my apologies if this is a repost. R, Vignesh wrote: > On 2/25/2017 1:25 AM, Rush, Jason A. wrote: >> R, Vignesh wrote: >>> On 2/24/2017 12:55 AM, Marek Vasut wrote: On 02/23/2017 08:22 PM, Rush, Jason A. wrote: > Marek Vasut wrote: >> On 02/22/2017 06:37 PM, Rush, Jason A. wrote: >>> Marek Vasut wrote: On 02/21/2017 05:50 PM, Rush, Jason A. wrote: >>> [...] > >>> >>> You could try reverting my commits: >>> commit 57897c13de03ac0136d64641a3eab526c6810387 spi: cadence_qspi_apb: >>> Use 32 bit indirect write transaction when possible >>> commit b63b46313ed29e9b0c36b3d6b9407f6eade40c8f spi: cadence_qspi_apb: >>> Use 32 bit indirect read transaction when possible >>> >> >> When I reverted these two commits and added my patch for the indirect >> trigger_address, it works correctly. >> > > Oops, these patches are required as Cadence QSPI controller(I am not > sure if all versions of IP are newer versions only) has a limitation > that the external master is only permitted to issue 32-bit data > interface reads until the last word of an indirect transfer. > > >> Also, when I disabled the dcache (dcache off) as Marek suggested, it works >> correctly when running from the master branch (again with my indirect >> trigger_address patch). >> > > Just that I understand correctly, with latest master(with no patches > reverted) + your patch for indirect trigger_address + dcache off, you > don't see any problem? > Correct. >>> >>> But there were other patches by others in v2017.01-rc1, like >>> spi: cadence_qspi: Fix CS timings which may have impact. >>> >> >> I left all other commits in except the two Vignesh suggested to revert, so >> it seems to be related to those two commits and caching. As another data >> point, I can load and boot linux with caching on from another source (MMC). >> So I don't think it's a problem with memory/caching in general. >> >> Any suggestions on how to proceed from here? >> > > My patches use common bounce_buffer implementation which does dcache > flush/invalidate and if dcache has issues then I guess those operations > may be causing data corruption. Could you do a bit more research for me? > > 1. As a hack, could you just disable dcache operations in bounce_buffer > implementation? Here is the diff for the same: > This works. So it does seem to be an issue with the CQSPI and dcache on the Altera SoC. > > diff --git a/common/bouncebuf.c b/common/bouncebuf.c > index 054d9e0302cc..2878b9eed1ae 100644 > --- a/common/bouncebuf.c > +++ b/common/bouncebuf.c [...] > > 2. If that works, I guess there is some issue wrt CQSPI and dcache on your > platform, > I suggest you to revert my above two patches and try non bounce buffer > version of > my changes here: https://patchwork.ozlabs.org/patch/693069/. > This patch takes care of indirect write. I don't have similar patch for > indirect read but that wasn't required. > This also works. Marek - how do you feel about a patch series with the following: 1. revert commit 57897c13de03ac0136d64641a3eab526c6810387 spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible 2. revert commit b63b46313ed29e9b0c36b3d6b9407f6eade40c8f spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible 3. Apply my slightly modified version of https://patchwork.ozlabs.org/patch/693069/ (should I keep Vignesh as the signed-off?) 4. Clean-up loading the reg variables to use fdtdec_get_addr_xxx(...) and mark them all as __iomem 5. Load the indirect-trigger property from the DT as a u32. I think this still needs to be a u32 because it's used in a writel(...) 32-bit write call in cadence_qspi_apb.c 6. Add indirect-trigger to dts files that use cadence driver I think that captures all the changes needed. Also, for the naming of the DT property, Linux has uses a 'cdns,' prefix (e.g. cdns,trigger-address) for a number of their properties (cdns,tshsl-ns, cdns,tsd2d-ns, etc.), but u-boot does not currently use the 'cdns,' prefix for the same properties. Do you want the 'cdns,' prefix on trigger-address? If so, do you want me to rename all the other properties to align them with the Linux DT as an additional patch? -- Regards, Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] Please pull u-boot-imx
On Tue, Feb 28, 2017 at 09:39:01AM +0530, Jagan Teki wrote: > On Mon, Feb 27, 2017 at 2:42 PM, Stefano Babic wrote: > > Hi Tom, > > > > please pull from u-boot-imx, thanks ! > > > > The following changes since commit b24cf8540a85a9bf97975aadd6a7542f166c78a3: > > > > video: mxsfb: Fix reset hang when videomode variable is not present > > (2017-02-22 21:47:59 +0100) > > > > are available in the git repository at: > > > > git://www.denx.de/git/u-boot-imx.git master > > > > for you to fetch changes up to 60a38e423b21a897b8fa0d9376d9370ea915ddd8: > > > > i.MX6Q: isiot: Switch the mmc env based on devno (2017-02-26 13:00:22 > > +0100) > > > > > > Andrey Yurovsky (1): > > mtd: nand: build MXS driver for MX7 as well > > > > Jagan Teki (25): > > configs: imx6: Don't define USDHC2_BASE_ADDR > > arm: imx6ul: Add Engicam Is.IoT MX6UL Starter Kit initial support > > arm: dts: imx6ul-isiot: Add I2C nodes > > imx6: isiotmx6ul: Add I2C support > > arm: dts: imx6ul-isiot: Add FEC node > > imx6: isiotmx6ul: Add FEC support > > imx6: isiotmx6ul: Add NAND support > > imx6: isiotmx6ul: Add nandboot env support > > imx6ul: isiotmx6ul: Enable I2C support > > i.MX6: engicam: Include dts files under MAINTAINERS > > imx6: Add imx6_src_get_boot_mode > > imx: spl: Update NAND bootmode detection bit > > imx: Use IMX6_BMODE_* macros instead of numericals > > imx6: Add src_base structure define macro > > imx6: isiotmx6ul: Update SPL board boot order for eMMC > > i.MX6UL: isiot: Add eMMC boot support > > i.MX6UL: isiot: Add modeboot env via board_late_init > > i.MX6UL: isiot: Add mmc_late_init > > i.MX6UL: isiot: Switch the mmc env based on devno > > arm: dts: imx6qdl-icore-rqs: Add eMMC node > > imx6: icorem6_rqs: Update SPL board boot order for eMMC > > imx6: icorem6_rqs: Add eMMC boot support > > i.MX6Q: icorem6_rqs: Add modeboot env via board_late_init > > i.MX6Q: icorem6_rqs: Add mmc_late_init > > i.MX6Q: isiot: Switch the mmc env based on devno > > These patches were initiated during early on MW, any possibility to > merge these as well? As I was saying in my -rc3 release email, no. The next window is just around the corner. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: socfpga: fix issue with warm reset when CSEL is 0
On Mon, 2017-02-20 at 06:35 -0800, Dalon Westergreen wrote: > On Mon, 2017-02-20 at 15:24 +0100, Marek Vasut wrote: > > > > On 02/20/2017 03:21 PM, Dalon Westergreen wrote: > > > > > > > > > On Mon, 2017-02-20 at 15:14 +0100, Marek Vasut wrote: > > > > > > > > > > > > On 02/20/2017 03:10 PM, Dalon Westergreen wrote: > > > > > > > > > > > > > > > > > > > > On Mon, 2017-02-20 at 10:07 +0100, Marek Vasut wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 02/18/2017 02:34 AM, Dalon Westergreen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > When CSEL=0x0 the socfpga bootrom does not touch the clock > > > > > > > configuration for the device. This can lead to a boot failure > > > > > > > on warm resets. This patch disables warm resets when CSEL=0. > > > > > > > This results in the clock and pll configurations being reset > > > > > > > on any reset issued when CSEL=0. > > > > > > > > > > > > > > Signed-off-by: Dalon Westergreen > > > > > > > > > > > > What about my suggestion for V2 about just loading function pointer > > > > > > into > > > > > > the reset jump address register ? > > > > > > > > > > Frankly, i really dont like relying on the existence of a snippet of > > > > > code in > > > > > the > > > > > onchip ram being untouched to ensure a reboot/reset will occur for > > > > > this > > > > > csel=0 > > > > > case. i am certain this case is rarely used, and confident that it > > > > > isnt > > > > > being > > > > > used while trying to preserve sdram contents. > > > > > > > > Well, you already rely on such snippet, it's SPL. If you corrupt SPL and > > > > do warm reset, your system hangs, I had that multiple times :) > > > > > > True. I would argue to just use cold resets but i think arria 10 has more > > > use > > > for the warm reset case. > > > > OK > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the downside is that the scorecard is reset every boot. so the bootrom > > > > > will > > > > > retry all the spl images again resulting in possibly longer boot > > > > > times. > > > > > > > > Is that significant ? > > > > > > The watchdog timeout is on the order of 1.5 seconds. That would be for > > > each > > > failed spl. > > > > Hm, OK. But then your system is kinda broken, so you should expect this > > I guess. > > My thought exactly... I would like to see if Chin Liang or Dinh have any > comments? Chin Liang, Dinh, any comments? > > > > > > [...] > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] sunxi: add support for Lichee Pi Zero
On Sat, Feb 11, 2017 at 4:41 PM, Icenowy Zheng wrote: > Lichee Pi Zero is a development board with a V3s SoC. > > Add support for it. Add some details about board/features ? thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] ARM: dts: sunxi: Add device tree for Sunchip CX-A99
On Sat, Feb 25, 2017 at 5:55 PM, Rask Ingemann Lambertsen wrote: > The Sunchip CX-A99 is a board used in some media players. It features: > > An Allwinner A80 ARM SoC (4 * Cortex-A7 + 4 * Cortex-A15 cores) > 2 GiB or 4 GiB DDR3 DRAM > AXP808 PMIC > 16 GB or 32 GB eMMC > SDIO Wifi/Bluetooth/FM module > SD card slot > 1 USB 3.0 connector > 2 USB 2.0 connectors > SATA connector > UART connector (internally) for serial console > Ethernet connector (10/100/1000 Mbit/s) > HDMI connector > Composite video and analog audio connector > S/PDIF connector > IR remote control receiver > > This is a preliminary device tree for use until a device tree is accepted > upstream, after which it can be replaced by the upstream version. > > Signed-off-by: Rask Ingemann Lambertsen > --- > No changes from v1 to v2. > > arch/arm/dts/Makefile | 3 +- > arch/arm/dts/sun9i-a80-cx-a99.dts | 380 > ++ > 2 files changed, 382 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/dts/sun9i-a80-cx-a99.dts > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index 66ea0b3..fd86794 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -286,7 +286,8 @@ dtb-$(CONFIG_MACH_SUN50I) += \ > sun50i-a64-pine64.dtb > dtb-$(CONFIG_MACH_SUN9I) += \ > sun9i-a80-optimus.dtb \ > - sun9i-a80-cubieboard4.dtb > + sun9i-a80-cubieboard4.dtb \ > + sun9i-a80-cx-a99.dtb This along with 3/3 squashed and Applied to u-boot-sunxi/master thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] ARM: dts: sun9i: Add mmc1 pinmux setting
On Sat, Feb 25, 2017 at 5:54 PM, Rask Ingemann Lambertsen
wrote:
> From: Chen-Yu Tsai
>
> commit 56b0730157f70dc23d6caff9e7ceb8b377b96b9f upstream.
>
> On the A80, mmc1 is available on pingroup G. Designs mostly use this
> to connect to an SDIO WiFi chip.
>
> Signed-off-by: Chen-Yu Tsai
> Signed-off-by: Rask Ingemann Lambertsen
> ---
> Changes from v1 to v2:
> - Corrected mail sender and added my Signed-off-by: to commit message.
>
> arch/arm/dts/sun9i-a80.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/dts/sun9i-a80.dtsi b/arch/arm/dts/sun9i-a80.dtsi
> index f68b324..92412b2 100644
> --- a/arch/arm/dts/sun9i-a80.dtsi
> +++ b/arch/arm/dts/sun9i-a80.dtsi
> @@ -701,6 +701,14 @@
> allwinner,pull = ;
> };
>
> + mmc1_pins: mmc1 {
> + allwinner,pins = "PG0", "PG1" ,"PG2", "PG3",
> +"PG4", "PG5";
> + allwinner,function = "mmc1";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> mmc2_8bit_pins: mmc2_8bit {
> allwinner,pins = "PC6", "PC7", "PC8", "PC9",
> "PC10", "PC11", "PC12",
Reviewed-by: Jagan Teki
Applied to u-boot-sunxi/master
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/16] sunxi: Add support for the CHIP Pro
On Mon, Feb 27, 2017 at 10:51 PM, Maxime Ripard wrote: > The CHIP Pro is a SoM made by NextThing Co, and that embeds a GR8 SIP, an > AXP209 PMIC, a WiFi BT chip and a 512MB SLC NAND. > > Since the first Allwinner device coming whit an SLC NAND that doesn't have > the shortcomings (and breakages) the MLC NAND has, we can finally enable > the NAND support on a board by default. > > This is the occasion to introduce a bunch of additions needed imo to be > able to come up with a sane NAND support for our users. > > The biggest pain point is that the BROM uses a different ECC and randomizer > configuration than for the rest of the NAND. In order to lessen the number > of bitflips, you also need to pad with random data the SPL image. > > Since it's quite tedious to do right (and most users won't be able to > figure it out) and since if it is not done right, it will eventually turn > into an unusable system (which is bad UX), we think that the best solution > is to generate an SPL image that already embeds all this. We'll possible > have to do the same thing for the U-Boot image (at least for the random > padding) on MLC NANDs. > > The only drawback from that is that you need to flash it raw, instead of > using the usual nand write, but it's just a different command, nothing > major anyway. > > In order to flash it, from a device switched in FEL, on your host: > sunxi-fel spl spl/sunxi-spl.bin > sunxi-fel write 0x4a00 u-boot-dtb.bin > sunxi-fel write 0x4300 spl/sunxi-spl-with-ecc.bin > sunxi-fel exe 0x4a00 > > And on the board, once u-boot is running (assuming the NAND is already > erased): > > nand write.raw.noverify 0x4300 0 40 > nand write.raw.noverify 0x4300 0x40 40 > > nand write 0x4a00 0x80 0xc > > I also encountered some weird bug in the private libgcc that prevents > U-Boot from loading. Disabling CONFIG_USE_PRIVATE_LIBGCC fixes that. > > Let me know what you think, > Maxime > > Changes from v4: > - Rebased on top of last pull request > - Removed irrelevant config options > > Changes from v3: > - Bring new Kconfig patches from Boris > - Do not define Kconfig defaults in our board Kconfig but directly in the > option declaration > - Sync the DT with the kernel > - Fixed build breakages > > Changes from v2: > - Move CMD_NAND and CMD_UBI default to cmd/Kconfig > - Define the env Kconfig options only for ARCH_SUNXI to avoid build > breakages > - Define CMD_MTDPARTS only for ARCH_SUNXI > > Changes from v1: > - Allowed to build lib/bch.c for the host, and used that in the image > builder > - Fixed a bug in the NAND driver > - Wrote a documentation on how to flash a NAND image on an Allwinner > board > - Fixed a few compilation breakages and issues > - Moved U-boot offset out of the config header and into Kconfig > - Moved the environment into UBI > - Moved the environment selection to Kconfig > - Moved the CMD_MTDPARTS options to Kconfig > - Provide MTDIDS_DEFAULT and MTDPARTS_DEFAULT options through Kconfig > - Added the tags from everyone > > Boris Brezillon (3): > mtd: ubi: Select RBTREE option from MTD_UBI Kconfig entry > cmd: Expose a Kconfig option to enable UBIFS commands > cmd: nand: Expose optional suboptions in Kconfig > > Hans de Goede (1): > sunxi: Enable UBI and NAND support > > Maxime Ripard (12): > nand: sunxi: Fix modulo by zero error > bch: Allow to build for the host > tools: sunxi: Add spl image builder > common: Move environment choice to Kconfig > cmd: Add Kconfig option for CMD_MTDPARTS and related options > mtd: sunxi: Select the U-Boot location config option > mtd: sunxi: Change U-Boot offset > sunxi: Add the default mtdids and mtdparts to our env > nand: sunxi: Add options for the SPL NAND configuration > scripts: sunxi: Build an raw SPL image > sunxi: Sync GR8 DTS and AXP209 with the kernel > sunxi: Add support for the CHIP Pro Applied to u-boot-sunxi/master thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/7] usb: host: xhci-omap: fix double weak board_usb_init functions
On 28/02/17 10:00, Uri Mashiach wrote: > Hi, > > On 02/27/2017 06:22 PM, Roger Quadros wrote: >> Hi, >> >> On 23/02/17 15:39, Uri Mashiach wrote: >>> A weak version of the function board_usb_init is implemented in: >>> common/usb.c >>> drivers/usb/host/xhci-omap.c >>> >>> To fix the double implementations: >>> * Convert the board_usb_init function in drivers/usb/host/xhci-omap.c >>> normal (not weak). >>> * The function board_usb_init in drivers/usb/host/xhci-omap.c calls to >>> the weak function omap_xhci_board_usb_init. >>> * Rename board version of the function board_usb_init to >>> omap_xhci_board_usb_init. >>> Done only for boards that defines CONFIG_USB_XHCI_OMAP. >>> >>> To achieve the same flexibility with the function board_usb_cleanup: >>> * Add a normal (not weak) implementation of the function >>> board_usb_cleanup in drivers/usb/host/xhci-omap.c >>> * The function board_usb_cleanup in drivers/usb/host/xhci-omap.c calls >>> to the weak function omap_xhci_board_usb_cleanup. >>> * Rename board version of the function board_usb_cleanup to >>> omap_xhci_board_usb_cleanup. >>> Done only for boards that defines CONFIG_USB_XHCI_OMAP. >>> >>> Cc: Lokesh Vutla >>> Signed-off-by: Uri Mashiach >>> Acked-by: Marek Vasut >>> Reviewed-by: Tom Rini >>> --- >>> V1 -> V2: Use __weak instead of attribute block >>> V2 -> V4: none >>> >>> board/compulab/cl-som-am57x/cl-som-am57x.c | 2 +- >>> board/ti/am43xx/board.c| 4 ++-- >>> board/ti/am57xx/board.c| 4 ++-- >>> board/ti/dra7xx/evm.c | 4 ++-- >>> drivers/usb/host/xhci-omap.c | 17 +++-- >> >> What about board/ti/omap5_uevm/evm.c ? > > The symbol CONFIG_USB_XHCI_OMAP is not included in the file > include/configs/omap5_uevm.h, therefore: > The file drivers/usb/host/xhci-omap.c is not included in the compilation - no > double implementations to fix. > But if someone wants to use the XHCI host he will enable the CONFIG_USB_XHCI_OMAP for omap5_uevm right? We need to ensure it doesn't break then. -- cheers, -roger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] serial: Add serial driver for Intel MID
Add a specific serial driver for Intel MID platforms.
It has special fractional divider which can be programmed via UART_PS,
UART_MUL, and UART_DIV registers.
The UART clock is calculated as
UART clock = XTAL * UART_MUL / UART_DIV
The baudrate is calculated as
baud rate = UART clock / UART_PS / DLAB
Initialize fractional divider correctly for Intel Edison platform.
For backward compatibility we have to set initial DLAB value to 16
and speed to 115200 baud, where initial frequency is 29491200Hz, and
XTAL frequency is 38.4MHz.
Signed-off-by: Andy Shevchenko
---
drivers/serial/Kconfig| 9 +
drivers/serial/Makefile | 1 +
drivers/serial/serial_intel_mid.c | 69 +++
3 files changed, 79 insertions(+)
create mode 100644 drivers/serial/serial_intel_mid.c
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index b11f3ff89e..99dcdeb00d 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -347,6 +347,15 @@ config SYS_NS16550
be used. It can be a constant or a function to get clock, eg,
get_serial_clock().
+config INTEL_MID_SERIAL
+ bool "Intel MID platform UART support"
+ depends on DM_SERIAL && OF_CONTROL
+ depends on INTEL_MID
+ select SYS_NS16550
+ help
+ Select this to enable a UART for Intel MID platforms.
+ This uses the ns16550 driver as a library.
+
config ROCKCHIP_SERIAL
bool "Rockchip on-chip UART support"
depends on DM_SERIAL && SPL_OF_PLATDATA
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 8430668bf9..abd9dea4dc 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_S5P) += serial_s5p.o
obj-$(CONFIG_MXC_UART) += serial_mxc.o
obj-$(CONFIG_PXA_SERIAL) += serial_pxa.o
obj-$(CONFIG_MESON_SERIAL) += serial_meson.o
+obj-$(CONFIG_INTEL_MID_SERIAL) += serial_intel_mid.o
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_ROCKCHIP_SERIAL) += serial_rockchip.o
endif
diff --git a/drivers/serial/serial_intel_mid.c
b/drivers/serial/serial_intel_mid.c
new file mode 100644
index 00..777c09d6d2
--- /dev/null
+++ b/drivers/serial/serial_intel_mid.c
@@ -0,0 +1,69 @@
+/*
+ * Copyright (c) 2017 Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+
+/*
+ * The UART clock is calculated as
+ *
+ * UART clock = XTAL * UART_MUL / UART_DIV
+ *
+ * The baudrate is calculated as
+ *
+ * baud rate = UART clock / UART_PS / DLAB
+ */
+#define UART_PS0x30
+#define UART_MUL 0x34
+#define UART_DIV 0x38
+
+static void mid_writel(struct ns16550_platdata *plat, int offset, int value)
+{
+ unsigned char *addr;
+
+ offset *= 1 << plat->reg_shift;
+ addr = (unsigned char *)plat->base + offset;
+
+ writel(value, addr + plat->reg_offset);
+}
+
+static int mid_serial_probe(struct udevice *dev)
+{
+ struct ns16550_platdata *plat = dev_get_platdata(dev);
+
+ /*
+* Initialize fractional divider correctly for Intel Edison
+* platform.
+*
+* For backward compatibility we have to set initial DLAB value
+* to 16 and speed to 115200 baud, where initial frequency is
+* 29491200Hz, and XTAL frequency is 38.4MHz.
+*/
+ mid_writel(plat, UART_MUL, 96);
+ mid_writel(plat, UART_DIV, 125);
+ mid_writel(plat, UART_PS, 16);
+
+ return ns16550_serial_probe(dev);
+}
+
+static const struct udevice_id mid_serial_ids[] = {
+ { .compatible = "intel,mid-uart" },
+ {}
+};
+
+U_BOOT_DRIVER(serial_intel_mid) = {
+ .name = "serial_intel_mid",
+ .id = UCLASS_SERIAL,
+ .of_match = mid_serial_ids,
+ .ofdata_to_platdata = ns16550_serial_ofdata_to_platdata,
+ .platdata_auto_alloc_size = sizeof(struct ns16550_platdata),
+ .priv_auto_alloc_size = sizeof(struct NS16550),
+ .probe = mid_serial_probe,
+ .ops= &ns16550_serial_ops,
+ .flags = DM_FLAG_PRE_RELOC,
+};
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2017.03-rc3 released
Hello Tom, Am 28.02.2017 um 01:38 schrieb Tom Rini: Hey all, It's release day and v2017.03-rc3 is out. All in all, I'm OK with the contents here. It's the week after ELC, and you might have noticed I've been more picky today about PRs than I have in the past. During the "Linus and Dirk show" keynote, Linus brought up, as they'd just gone past some milestone year in the "new" release cycle model, it took them maybe 5 years to get to the point where everyone knows what is and isn't allowed at various points in the release cycle. So I'm going to try and be better, quicker. Once -rc2 is out, the window really has closed for "been around for a bit, stable now, missed the -rc1 cut off tho". There will always be another merge window, and on a rather predictable schedule too. Something else I want to point out now is that we have a few architectures that have not seen a lot of activity in the last few years, aren't functional to varying degrees and don't have a non-bouncing maintainer address. Between then and now, I'm going to try one last time to contact people associated with a few architectures and then I'm going to remove them after v2017.03 is out. As a final note, I expect us to release v2017.03 on schedule on the 13th of March. Thanks all! I miss patch: http://patchwork.ozlabs.org/patch/727734/ Without it, ethernet support for at91 boards like the siemens ones, does not work ... bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Support additional Variant for TQMa6 SOM
On 28/02/2017 11:50, Markus Niebel wrote: > Hello Stefano, > > Am Sonntag, den 26.02.2017, 12:57 +0100 schrieb Stefano Babic: >> On 03/02/2017 15:20, Markus Niebel wrote: >>> From: Markus Niebel >>> >>> Add support for the SOM variant featuring i.MX6DL. This needs a new >>> DCD config. The first patch is a small preparation. >>> >>> Markus Niebel (2): >>> arm: imx6: tqma6: use CONFIG_TQM6x for SOM specific settings >>> arm: imx6: tqma6: add support for TQMa6DL variant >>> >>> board/tqc/tqma6/Kconfig| 7 +++ >>> board/tqc/tqma6/README | 3 + >>> board/tqc/tqma6/tqma6.c| 7 +++ >>> board/tqc/tqma6/tqma6_mba6.c | 14 +++-- >>> board/tqc/tqma6/tqma6dl.cfg| 125 >>> + >>> configs/tqma6dl_mba6_mmc_defconfig | 36 +++ >>> configs/tqma6dl_mba6_spi_defconfig | 37 +++ >>> include/configs/tqma6.h| 16 ++--- >>> include/configs/tqma6_mba6.h | 5 +- >>> 9 files changed, 235 insertions(+), 15 deletions(-) >>> create mode 100644 board/tqc/tqma6/tqma6dl.cfg >>> create mode 100644 configs/tqma6dl_mba6_mmc_defconfig >>> create mode 100644 configs/tqma6dl_mba6_spi_defconfig >>> >> >> Applied to u-boot-imx, thanks ! >> > > I noticed, that I did a minor mistake (naming of default device tree) in > the two defconfig files. Since at the moment the series is in imx-next, > would you prefer a v2 or a patch that fixes this? > Please send a V2, I will replace the patches before sending to Tom - thanks ! Best regards, Stefano -- Meet DENX at the Embedded World Trade Show 14 Mar - 16 Mar 2017, Nuremberg Trade Fair Centre, Hall 4, Booth 581 -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] cmd: itest: correct calculus for long format
On Fri, Feb 17, 2017 at 3:00 PM, Stefan Roese wrote: > On 17.02.2017 13:57, Andy Shevchenko wrote: >> On Fri, Feb 10, 2017 at 8:38 PM, Simon Glass wrote: >>> On 10 February 2017 at 05:59, Andy Shevchenko >>> wrote: itest shell command doesn't work correctly in long format when doing comparaison due to wrong mask value calculus that overflow on 32 bits values. >>> Reviewed-by: Simon Glass >> Thanks! >> >> To whom should I send this to get it applied? Or just wait when >> maintainers pick this up? > As this patch doesn't fall into a special custodian responsibility, Tom > usually keeps track of it and will apply it - most likely after the > next release. But it's always a good idea to check from time to time, if > such patches have been applied and "ping" again if not. Tom, there is no such in -rc3, please apply if no objections. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Support additional Variant for TQMa6 SOM
Hello Stefano, Am Sonntag, den 26.02.2017, 12:57 +0100 schrieb Stefano Babic: > On 03/02/2017 15:20, Markus Niebel wrote: > > From: Markus Niebel > > > > Add support for the SOM variant featuring i.MX6DL. This needs a new > > DCD config. The first patch is a small preparation. > > > > Markus Niebel (2): > > arm: imx6: tqma6: use CONFIG_TQM6x for SOM specific settings > > arm: imx6: tqma6: add support for TQMa6DL variant > > > > board/tqc/tqma6/Kconfig| 7 +++ > > board/tqc/tqma6/README | 3 + > > board/tqc/tqma6/tqma6.c| 7 +++ > > board/tqc/tqma6/tqma6_mba6.c | 14 +++-- > > board/tqc/tqma6/tqma6dl.cfg| 125 > > + > > configs/tqma6dl_mba6_mmc_defconfig | 36 +++ > > configs/tqma6dl_mba6_spi_defconfig | 37 +++ > > include/configs/tqma6.h| 16 ++--- > > include/configs/tqma6_mba6.h | 5 +- > > 9 files changed, 235 insertions(+), 15 deletions(-) > > create mode 100644 board/tqc/tqma6/tqma6dl.cfg > > create mode 100644 configs/tqma6dl_mba6_mmc_defconfig > > create mode 100644 configs/tqma6dl_mba6_spi_defconfig > > > > Applied to u-boot-imx, thanks ! > I noticed, that I did a minor mistake (naming of default device tree) in the two defconfig files. Since at the moment the series is in imx-next, would you prefer a v2 or a patch that fixes this? > Best regards, > Stefano > Best regards, Markus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sunxi/master
Hi Tom, On 27/02/17 14:56, Tom Rini wrote: > On Mon, Feb 27, 2017 at 07:51:38PM +0530, Jagan Teki wrote: >> Hi Tom, >> >> Please pull this PR. >> >> thanks! >> Jagan >> >> The following changes since commit b24cf8540a85a9bf97975aadd6a7542f166c78a3: >> >> video: mxsfb: Fix reset hang when videomode variable is not present >> (2017-02-22 21:47:59 +0100) >> >> are available in the git repository at: >> >> git://git.denx.de/u-boot-sunxi.git master >> >> for you to fetch changes up to 35affe7698e95c058a1f6c7eb2e1bf35f82461c9: >> >> sunxi: add NanoPi NEO Air defconfig (2017-02-25 13:54:15 +0530) >> >> >> Andre Przywara (12): >> sunxi: fix ACTLR.SMP assembly routine >> ARM: rename CONFIG_TIMER_CLK_FREQ to COUNTER_FREQUENCY >> fsl: ls102x: remove redundant GENERIC_TIMER_CLK >> sunxi: simplify ACTLR.SMP bit set #ifdef >> sunxi: configs: merge sun9i and sun50i SPL memory definitions >> sunxi: Kconfig: introduce CONFIG_SUNXI_HIGH_SRAM >> sunxi: provide ARMv8 mem_map for every ARM64 board >> SPI: SPL: sunxi: fix 64-bit build >> sunxi: DRAM: add Allwinner H5 support >> sunxi: prepare for sharing MACH_SUN8I_H3 config symbol >> sunxi: introduce Allwinner H5 config option >> sunxi: Add OrangePi PC 2 initial support >> >> Jelle van der Waa (1): >> sunxi: add NanoPi NEO Air defconfig > > So today is -rc3 day. Which of the above are bug fixes, rather than new > functionality? Thanks! So technically only the first patch in my series is a bug fix, maybe the SPL SPI driver fix as well: - sunxi: fix ACTLR.SMP assembly routine - SPI: SPL: sunxi: fix 64-bit build I think this was sent under the assumption that we stick with the rather loose merge policy from the past (pulling new things in even after -rc1). The patches have been on the list for a while, v3 was sent just two days after the merge window closed, etc. But I take it that we are getting stricter with this, which is something I really welcome, because the loose policy led to scarily late merges and thus breakages in the past. So from my point of view I am fine with postponing this for the next merge window, which is basically just around the corner anyway. For Jelle's patch: I don't know if a new _defconfig (NanoPi NEO Air) really hurts or could be accepted at this point as well. Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] sunxi: add basic V3s support
On Mon, Feb 13, 2017 at 12:44 PM, Maxime Ripard wrote: > On Sat, Feb 11, 2017 at 07:11:00PM +0800, Icenowy Zheng wrote: >> Basic U-Boot support is now present for V3s. >> >> Some memory addresses are changed specially for V3s, as the original >> address map cannot fit into a so small DRAM. >> >> As the DRAM controller code needs a big refactor, the SPL support is >> disabled in this version. >> >> Signed-off-by: Icenowy Zheng > > Acked-by: Maxime Ripard Reviewed-by: Jagan Teki thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] serial: Add serial driver for Intel MID
On Tue, 2017-02-28 at 10:27 +0800, Kever Yang wrote: > Hi Andy, > > On 02/28/2017 12:22 AM, Andy Shevchenko wrote: > > Add a specific serial driver for Intel MID platforms. > > @@ -398,6 +398,15 @@ config MESON_SERIAL > > If you have an Amlogic Meson based board and want to use > > the on-chip > > serial ports, say Y to this option. If unsure, say N. > > > > +config MID_SERIAL > > + bool "Intel MID platform UART support" > > MID is not a Intel Chip series, right? Yes, it's wider than that: https://en.wikipedia.org/wiki/Mobile_Internet_device > So I think if you named MID_SERIAL or serial_mid.c would make people > confused, > could you add a INTEL- prefix for it or something relate to the SoC > chip > itself? "intel" prefix is okay. There are more than one SoC in the family. I would wait for others to comment for a while and then will submit v3. -- Andy Shevchenko Intel Finland Oy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] build mkimage warning
Hi Tom, On Wed, Feb 22, 2017 at 11:22 PM, Tom Rini wrote: > On Wed, Feb 22, 2017 at 07:21:12PM +0800, Bin Meng wrote: >> Hi Tom, Simon, >> >> With latest main branch, I see some warnings when building mkimage: >> >> HOSTLD tools/mkimage >> LDFLAGS="" python ./lib/libfdt/setup.py \ >> "-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer >> -include ./include/libfdt_env.h -idirafterinclude >> -idirafter./arch/x86/include -I./lib/libfdt -I./tools >> -DCONFIG_SYS_TEXT_BASE=0xfff0 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES >> -D_GNU_SOURCE " lib/libfdt/fdt.c lib/libfdt/fdt_ro.c >> lib/libfdt/fdt_rw.c lib/libfdt/fdt_strerror.c lib/libfdt/fdt_wip.c >> lib/libfdt/fdt_region.c lib/libfdt/fdt_sw.c tools/libfdt_wrap.c >> In file included from /usr/local/include/python2.7/Python.h:8, >> from tools/libfdt_wrap.c:125: >> /usr/local/include/python2.7/pyconfig.h:1193:1: warning: >> "_POSIX_C_SOURCE" redefined >> In file included from /usr/include/stdint.h:26, >> from ././include/compiler.h:19, >> from ././include/libfdt_env.h:12, >> from :0: >> /usr/include/features.h:162:1: warning: this is the location of the >> previous definition >> In file included from /usr/local/include/python2.7/Python.h:8, >> from tools/libfdt_wrap.c:125: >> /usr/local/include/python2.7/pyconfig.h:1215:1: warning: >> "_XOPEN_SOURCE" redefined >> In file included from /usr/include/stdint.h:26, >> from ././include/compiler.h:19, >> from ././include/libfdt_env.h:12, >> from :0: >> /usr/include/features.h:164:1: warning: this is the location of the >> previous definition >> mv _libfdt.so tools/_libfdt.so > > How did you configure your local python2.7 install? Thanks! $ ll /usr/bin/python* lrwxrwxrwx 1 root root 24 Oct 18 17:49 /usr/bin/python -> /usr/local/bin/python2.7* lrwxrwxrwx. 1 root root6 Jul 27 2016 /usr/bin/python2 -> python* -rwxr-xr-x 1 root root 8.9K Jul 24 2015 /usr/bin/python2.6* -rwxr-xr-x. 1 root root 1.4K Jul 24 2015 /usr/bin/python2.6-config* lrwxrwxrwx 1 root root 24 Aug 2 2016 /usr/bin/python2.7 -> /usr/local/bin/python2.7* lrwxrwxrwx. 1 root root 16 Jul 27 2016 /usr/bin/python-config -> python2.6-config* $ ll /usr/local/bin/python* lrwxrwxrwx 1 root root9 Aug 2 2016 /usr/local/bin/python -> python2.7* -rwxr-xr-x 1 root root 9.6K Aug 2 2016 /usr/local/bin/python2.7* -rwxr-xr-x 1 root root 1.7K Aug 2 2016 /usr/local/bin/python2.7-config* Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-boot FIT Signature
Hi Maria, On Tue, 2017-02-28 at 08:50 +0100, Maria Sepulveda wrote: > > On Mon, 2017-02-20 at 12:33 +0100, Maria Sepulveda wrote: > > > > > > The reason to store the public key on an external device is to verify > > > that it is our hardware. > > Do you want to verify it is your hardware or do you want to verify the > > Software > > is the one you designated to run on this hardware? > I want to avoid that someone could use my Software in a different hardware. > > > > > > > > This is my idea: > > > > > > In the host: > > > > > > 1. Sign my fit image with mkimage. > > > 2. Store the public key in some i2c device ( crypto-memory, read-only > > > device, TPM) > > > > > > In the target: > > > > > > 1. Start U-boot and load my standalone application. > > > Using i2c functions, I would like to check the i2c address of my > > > external device (i2c_probe function) and read the public key stored > > > inside. Then, I want to pass the public key to the U-boot to do the > > > verification. > > > I am not sure about if the public key has to be always stored in DBT to > > > do the verification (in both: DBT and external device) or it could just > > > be in the external device. > > > This is my configuration to enable verification: > > > > > > [...] > > > 2. U-boot load the fit image (bootm command) > > > > > > This is the general idea but first of all, I need to know if it is > > > possible to do that and how I could store the public key in somewhere > > > else, not only in dtb. > > As far as i know it is not designated to store the public key outside the > > DTB > > so it would need some coding on your side. > > > > As i said before you can do the verification with less effort, storing a > > checksum of your public key in a save place. It will take less space and > > you > > can make sure your public key, stored in the DTB, has not been modified by > > a > > third party. > > > > You just need to calculate a checksum over your public key at runtime and > > compare it to the securely stored one, if they match your public key is > > authenticated > > > > Maybe your processor has some builtin secure boot mechanism? > I am using an AM3352 processor and I think it doesn't have any secure > boot mechanism. That's why I would like to do the security part of my > project in U-Boot before load the kernel image. Ok, then you are on the right path :) > Maybe your idea could satisfy my needs. I will calculate a checksum over > the public key that will be stored in an external device. With a > standalone U-Boot Application, I will read the checksum from the > external device and check that the public key hasn't been tampered with. > If everything is right, U-Boot will load the FIT image. correct. > My question now is how to do that. I have read about 'crc' command but I > don't know if there is a better way to check at runtime the checksum of > the public key stored in dtb and compare it with the one stored in my > external device. In U-Boot there is a function called "calculate_hash" in "common/image-fit.c". For ease of use you can just verify the whole devicetree. You could use the function to calculate the hash over your devicetree in u-boot runtime. The hash to be stored in your external device you can calculate using openssl. I suggest you use sha256 as hash-function. On your host: openssl dgst -sha256 -binary -out checksum.bin u-boot.dtb in u-boot code: uint8_t value[SHA256_SUM_LEN]; int value_len; calculate_hash(start_address, size, "sha256", (unsigned char *)value, &value_len); And then memcmp "value" to the hash you took from the external device(checksum.bin). best regards Markus -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-60 Fax: (+49)-8142-66989-80 Email: m...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/20] arm: socfpga: add reset driver support for Arria 10
On 02/28/2017 09:27 AM, Ley Foon Tan wrote:
> On Mon, Feb 27, 2017 at 6:14 PM, Ley Foon Tan wrote:
>> On Sab, 2017-02-25 at 22:28 +0100, Marek Vasut wrote:
>>> On 02/22/2017 10:47 AM, Ley Foon Tan wrote:
Add reset driver support for Arria 10.
Signed-off-by: Tien Fong Chee
Signed-off-by: Ley Foon Tan
---
arch/arm/mach-socfpga/Makefile | 2 +
arch/arm/mach-socfpga/include/mach/reset_manager.h | 4 +-
.../include/mach/reset_manager_arria10.h | 144
arch/arm/mach-socfpga/reset_manager_arria10.c | 406
+
include/dt-bindings/reset/altr,rst-mgr-a10.h | 103 ++
5 files changed, 658 insertions(+), 1 deletion(-)
create mode 100755 arch/arm/mach-
socfpga/include/mach/reset_manager_arria10.h
create mode 100644 arch/arm/mach-socfpga/reset_manager_arria10.c
create mode 100644 include/dt-bindings/reset/altr,rst-mgr-a10.h
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-
socfpga/Makefile
index e83da2e..d81f003 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -10,6 +10,8 @@
obj-y += misc.o timer.o reset_manager.o clock_manager.o \
fpga_manager.o board.o
+obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += reset_manager_arria10.o
+
obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
# QTS-generated config file wrappers
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index 9e253bf..64526b6 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -43,7 +43,9 @@ void socfpga_per_reset_all(void);
/* Create a human-readable reference to SoCFPGA reset. */
#define SOCFPGA_RESET(_name) RSTMGR_##_name
-#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
+#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
+#include
+#elif defined(CONFIG_TARGET_SOCFPGA_GEN5)
>>> You can use #elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) instead to
>>> keep
>>> this list sorted.
>> You want sort with GEN5, ARRIA10 or sorted alphanumerically ARRIA10
>> then GEN5?
>>>
#include
#endif
diff --git a/arch/arm/mach-
socfpga/include/mach/reset_manager_arria10.h b/arch/arm/mach-
socfpga/include/mach/reset_manager_arria10.h
new file mode 100755
index 000..2668a86
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
@@ -0,0 +1,144 @@
+/*
+ * Copyright (C) 2012-2017 Altera Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef_RESET_MANAGER_ARRIA10_H_
+#define_RESET_MANAGER_ARRIA10_H_
>>> Use #ifdef[space]FOO and #define[space]FOO
>> Okay
>>>
+void watchdog_disable(void);
+void reset_deassert_noc_ddr_scheduler(void);
+int is_wdt_in_reset(void);
+void emac_manage_reset(ulong emacbase, uint state);
+int reset_deassert_bridges_handoff(void);
+void reset_assert_fpga_connected_peripherals(void);
+void reset_deassert_osc1wd0(void);
+void reset_assert_uart(void);
+void reset_deassert_uart(void);
>>> [...]
>>>
+#endif /* _RESET_MANAGER_ARRIA10_H_ */
diff --git a/arch/arm/mach-socfpga/reset_manager_arria10.c
b/arch/arm/mach-socfpga/reset_manager_arria10.c
new file mode 100644
index 000..01156de
--- /dev/null
+++ b/arch/arm/mach-socfpga/reset_manager_arria10.c
@@ -0,0 +1,406 @@
+/*
+ * Copyright (C) 2016-2017 Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct socfpga_reset_manager *reset_manager_base =
+ (void *)SOCFPGA_RSTMGR_ADDRESS;
+static const struct socfpga_system_manager *sysmgr_regs =
+ (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
>>> Use the tabs consistently, one or two, but pick one.
>> Okay.
>>>
+static int get_bridge_init_val(const void *blob, int compat_id);
+
+#define ECC_MASK (ALT_RSTMGR_PER0MODRST_EMACECC0_SET_MSK|\
+ ALT_RSTMGR_PER0MODRST_EMACECC1_SET_MSK|\
+ ALT_RSTMGR_PER0MODRST_EMACECC2_SET_MSK|\
+ ALT_RSTMGR_PER0MODRST_NANDECC_SET_MSK|\
+ ALT_RSTMGR_PER0MODRST_QSPIECC_SET_MSK|\
+ ALT_RSTMGR_PER0MODRST_SDMMCECC_SET_MSK)
>>> MSK | \
>>>
>>> Keep the spacing please.
>> Okay.
>>>
+void reset_assert_uart(void)
+{
+ u32 mask = 0;
+ unsigned int com_port;
+
+ com_port = uart_com_port(gd->fdt_blob);
>>> What's this function , is it defined later in the
Re: [U-Boot] [PATCH 06/20] arm: socfpga: add reset driver support for Arria 10
On Mon, Feb 27, 2017 at 6:14 PM, Ley Foon Tan wrote:
> On Sab, 2017-02-25 at 22:28 +0100, Marek Vasut wrote:
>> On 02/22/2017 10:47 AM, Ley Foon Tan wrote:
>> >
>> > Add reset driver support for Arria 10.
>> >
>> > Signed-off-by: Tien Fong Chee
>> > Signed-off-by: Ley Foon Tan
>> > ---
>> > arch/arm/mach-socfpga/Makefile | 2 +
>> > arch/arm/mach-socfpga/include/mach/reset_manager.h | 4 +-
>> > .../include/mach/reset_manager_arria10.h | 144
>> > arch/arm/mach-socfpga/reset_manager_arria10.c | 406
>> > +
>> > include/dt-bindings/reset/altr,rst-mgr-a10.h | 103 ++
>> > 5 files changed, 658 insertions(+), 1 deletion(-)
>> > create mode 100755 arch/arm/mach-
>> > socfpga/include/mach/reset_manager_arria10.h
>> > create mode 100644 arch/arm/mach-socfpga/reset_manager_arria10.c
>> > create mode 100644 include/dt-bindings/reset/altr,rst-mgr-a10.h
>> >
>> > diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-
>> > socfpga/Makefile
>> > index e83da2e..d81f003 100644
>> > --- a/arch/arm/mach-socfpga/Makefile
>> > +++ b/arch/arm/mach-socfpga/Makefile
>> > @@ -10,6 +10,8 @@
>> > obj-y += misc.o timer.o reset_manager.o clock_manager.o \
>> >fpga_manager.o board.o
>> >
>> > +obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += reset_manager_arria10.o
>> > +
>> > obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
>> >
>> > # QTS-generated config file wrappers
>> > diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
>> > b/arch/arm/mach-socfpga/include/mach/reset_manager.h
>> > index 9e253bf..64526b6 100644
>> > --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
>> > +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
>> > @@ -43,7 +43,9 @@ void socfpga_per_reset_all(void);
>> > /* Create a human-readable reference to SoCFPGA reset. */
>> > #define SOCFPGA_RESET(_name) RSTMGR_##_name
>> >
>> > -#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>> > +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
>> > +#include
>> > +#elif defined(CONFIG_TARGET_SOCFPGA_GEN5)
>> You can use #elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) instead to
>> keep
>> this list sorted.
> You want sort with GEN5, ARRIA10 or sorted alphanumerically ARRIA10
> then GEN5?
>>
>> >
>> > #include
>> > #endif
>> >
>> > diff --git a/arch/arm/mach-
>> > socfpga/include/mach/reset_manager_arria10.h b/arch/arm/mach-
>> > socfpga/include/mach/reset_manager_arria10.h
>> > new file mode 100755
>> > index 000..2668a86
>> > --- /dev/null
>> > +++ b/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
>> > @@ -0,0 +1,144 @@
>> > +/*
>> > + * Copyright (C) 2012-2017 Altera Corporation
>> > + *
>> > + * SPDX-License-Identifier:GPL-2.0+
>> > + */
>> > +
>> > +#ifndef_RESET_MANAGER_ARRIA10_H_
>> > +#define_RESET_MANAGER_ARRIA10_H_
>> Use #ifdef[space]FOO and #define[space]FOO
> Okay
>>
>> >
>> > +void watchdog_disable(void);
>> > +void reset_deassert_noc_ddr_scheduler(void);
>> > +int is_wdt_in_reset(void);
>> > +void emac_manage_reset(ulong emacbase, uint state);
>> > +int reset_deassert_bridges_handoff(void);
>> > +void reset_assert_fpga_connected_peripherals(void);
>> > +void reset_deassert_osc1wd0(void);
>> > +void reset_assert_uart(void);
>> > +void reset_deassert_uart(void);
>> [...]
>>
>> >
>> > +#endif /* _RESET_MANAGER_ARRIA10_H_ */
>> > diff --git a/arch/arm/mach-socfpga/reset_manager_arria10.c
>> > b/arch/arm/mach-socfpga/reset_manager_arria10.c
>> > new file mode 100644
>> > index 000..01156de
>> > --- /dev/null
>> > +++ b/arch/arm/mach-socfpga/reset_manager_arria10.c
>> > @@ -0,0 +1,406 @@
>> > +/*
>> > + * Copyright (C) 2016-2017 Intel Corporation
>> > + *
>> > + * SPDX-License-Identifier:GPL-2.0
>> > + */
>> > +
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +
>> > +DECLARE_GLOBAL_DATA_PTR;
>> > +
>> > +static const struct socfpga_reset_manager *reset_manager_base =
>> > + (void *)SOCFPGA_RSTMGR_ADDRESS;
>> > +static const struct socfpga_system_manager *sysmgr_regs =
>> > + (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
>> Use the tabs consistently, one or two, but pick one.
> Okay.
>>
>> >
>> > +static int get_bridge_init_val(const void *blob, int compat_id);
>> > +
>> > +#define ECC_MASK (ALT_RSTMGR_PER0MODRST_EMACECC0_SET_MSK|\
>> > + ALT_RSTMGR_PER0MODRST_EMACECC1_SET_MSK|\
>> > + ALT_RSTMGR_PER0MODRST_EMACECC2_SET_MSK|\
>> > + ALT_RSTMGR_PER0MODRST_NANDECC_SET_MSK|\
>> > + ALT_RSTMGR_PER0MODRST_QSPIECC_SET_MSK|\
>> > + ALT_RSTMGR_PER0MODRST_SDMMCECC_SET_MSK)
>> MSK | \
>>
>> Keep the spacing please.
> Okay.
>>
>> >
>> > +void reset_assert_uart(void)
>> > +{
>> > + u32 mask = 0;
>> > + unsigned int com_port;
>> > +
>> > + com_port = uart_com_port(gd->fdt_blob);
>> What's this function , is it defined later in the patchset ?
> Oh ya, it is in later patch [misc]. I will try to rear
Re: [U-Boot] am335x: musb: mass storage device issue
On Tue, Feb 14, 2017 at 11:46 AM, Yegor Yefremov wrote: > On Tue, Feb 14, 2017 at 7:57 AM, Stefan Roese wrote: >> Hi Yegor, >> >> >> On 13.02.2017 16:02, Yegor Yefremov wrote: >>> >>> On Mon, Feb 13, 2017 at 3:17 PM, Belisko Marek >>> wrote: Hi Yegor, On Mon, Feb 13, 2017 at 12:57 PM, Yegor Yefremov wrote: > > > My am335x based board doesn't detect USB sticks: > > U-Boot 2017.03-rc1 (Feb 13 2017 - 12:46:54 +0100) > > CPU : AM335X-GP rev 2.1 > I2C: ready > DRAM: 256 MiB > NAND: 256 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Using default environment > > Net:not set. Validating first E-fuse MAC > cpsw > Hit any key to stop autoboot: 0 > => usb reset > resetting USB... > USB0: scanning bus 0 for devices... 2 USB Device(s) found >scanning usb for storage devices... 0 Storage Device(s) found > > > => usb tree > USB device tree: > 1 Hub (480 Mb/s, 100mA) > | USB2.0 Hub > | > +-2 Vendor specific (480 Mb/s, 500mA) >Quectel, Incorporated UMTS/HSPA Module > > U-Boot finds a hub and a 3g modem attached to it, but the USB drive, > that is also attached to this hub won't be detected. maybe stupid reply but did you test on other board or with other usb device? I can check on BBB in the evening and post findings. >>> >>> >>> And please provide your u-boot version. >>> > So far I haven't tried to bisect the issue (have to find a working > commit including my board), but the same setup is working for 2014.07 > u-boot. Am I the only one or are other am335x based also affected? >>> >>> >>> Bisect result: >>> >>> 2ef117fe4fce4e1af282ac2bbb0be36c41d15e2b is the first bad commit >>> commit 2ef117fe4fce4e1af282ac2bbb0be36c41d15e2b >>> Author: Stefan Roese >>> Date: Tue Mar 15 13:59:13 2016 +0100 >>> >>> usb: Remove 200 ms delay in usb_hub_port_connect_change() >>> >>> This patch removes 2 mdelay(200) calls from >>> usb_hub_port_connect_change(). >>> These delays don't seem to be necessary. At least not in my tests. >>> Here >>> the number for a custom x86 Bay Trail board (not in mainline yet) with >>> a quite large and complex USB hub infrastructure. >>> >>> Without this patch: >>> starting USB... >>> USB0: USB EHCI 1.00 >>> scanning bus 0 for devices... 9 USB Device(s) found >>> >>> time: 28.415 seconds >>> >>> With this patch: >>> starting USB... >>> USB0: USB EHCI 1.00 >>> scanning bus 0 for devices... 9 USB Device(s) found >>> >>> time: 24.003 seconds >>> >>> So ~4.5 seconds of USB scanning time reduction. >>> >>> Signed-off-by: Stefan Roese >>> Cc: Simon Glass >>> Acked-by: Hans de Goede >>> Tested-by: Stephen Warren >>> Cc: Marek Vasut >> >> >> Might be that an initial delay is missing for your specific host >> controller. IIRC, we had a similar issue with the SoCPFGA also >> not detecting all USB sticks with my USB scanning patches applied. >> Please take a look at this patch: >> >> 2bf352f0 [usb: dwc2: Add delay to fix the USB detection problem >> on SoCFPGA] >> >> Perhaps you can do some tests with some initial delays as well? > > I have tried to increase delays in drivers/usb/musb-new/musb_uboot.c > and add delay in drivers/usb/musb-new/musb_dsps.c->dsps_musb_init(), > but no luck. > > @Felipe, @Mugunthan any idea? I made some more tests with various USB drives. All in all I have tried 4 devices: with delays: * Transcend 4GB: not detected * Transcend 16GB (USB 3.0): detected * Super Talent Express DUO USB 3.0: detected * DataTraveler 2GB: detected without delays: * Transcend 4GB: not detected * Transcend 16GB (USB 3.0): detected * Super Talent Express DUO USB 3.0: not detected * DataTraveler 2GB: detected So removing these delays reduces the number of working USB drives. Yegor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/7] usb: host: xhci-omap: fix double weak board_usb_init functions
Hi, On 02/27/2017 06:22 PM, Roger Quadros wrote: Hi, On 23/02/17 15:39, Uri Mashiach wrote: A weak version of the function board_usb_init is implemented in: common/usb.c drivers/usb/host/xhci-omap.c To fix the double implementations: * Convert the board_usb_init function in drivers/usb/host/xhci-omap.c normal (not weak). * The function board_usb_init in drivers/usb/host/xhci-omap.c calls to the weak function omap_xhci_board_usb_init. * Rename board version of the function board_usb_init to omap_xhci_board_usb_init. Done only for boards that defines CONFIG_USB_XHCI_OMAP. To achieve the same flexibility with the function board_usb_cleanup: * Add a normal (not weak) implementation of the function board_usb_cleanup in drivers/usb/host/xhci-omap.c * The function board_usb_cleanup in drivers/usb/host/xhci-omap.c calls to the weak function omap_xhci_board_usb_cleanup. * Rename board version of the function board_usb_cleanup to omap_xhci_board_usb_cleanup. Done only for boards that defines CONFIG_USB_XHCI_OMAP. Cc: Lokesh Vutla Signed-off-by: Uri Mashiach Acked-by: Marek Vasut Reviewed-by: Tom Rini --- V1 -> V2: Use __weak instead of attribute block V2 -> V4: none board/compulab/cl-som-am57x/cl-som-am57x.c | 2 +- board/ti/am43xx/board.c| 4 ++-- board/ti/am57xx/board.c| 4 ++-- board/ti/dra7xx/evm.c | 4 ++-- drivers/usb/host/xhci-omap.c | 17 +++-- What about board/ti/omap5_uevm/evm.c ? The symbol CONFIG_USB_XHCI_OMAP is not included in the file include/configs/omap5_uevm.h, therefore: The file drivers/usb/host/xhci-omap.c is not included in the compilation - no double implementations to fix. -- Thanks and regards, Uri ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
