Re: [U-Boot] [PATCH 4/5] rockchip: dts: rk3328: add rk3328-rock64.dts
Hi Matwey,
On 05/08/2019 02:34 PM, Matwey V. Kornilov wrote:
> rk3328-rock64.dts has been taken from Linux kernel with minor
> modifications.
Could you detail about which commit of kernel do you take
this dts from?
>
> Signed-off-by: Matwey V. Kornilov
> ---
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/rk3328-rock64-u-boot.dtsi | 30
> arch/arm/dts/rk3328-rock64.dts | 294
> +
> 3 files changed, 325 insertions(+)
> create mode 100644 arch/arm/dts/rk3328-rock64-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3328-rock64.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 8e082f2840..cacc580502 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -85,6 +85,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> rk3288-veyron-speedy.dtb \
> rk3288-vyasa.dtb \
> rk3328-evb.dtb \
> + rk3328-rock64.dtb \
> rk3399-ficus.dtb \
> rk3368-lion.dtb \
> rk3368-sheep.dtb \
> diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> new file mode 100644
> index 00..a0e04be758
> --- /dev/null
> +++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> @@ -0,0 +1,30 @@
> +/*
> + * (C) Copyright 2018 Rockchip Electronics Co., Ltd
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +/ {
> + aliases {
> + mmc0 = &emmc;
> + mmc1 = &sdmmc;
> + };
Maybe you would need a spl-boot-order here to make sure SPL can find
u-boot from
both emmc and sdmmc.
> +};
> +
> +&cru {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&uart2 {
> + u-boot,dm-pre-reloc;
> +};
And maybe you need add 'clock-frequency=2400' for uart2.
Thanks,
- Kever
> +
> +&emmc {
> + u-boot,dm-pre-reloc;
> + fifo-mode;
> +};
> +
> +&sdmmc {
> + u-boot,dm-pre-reloc;
> + fifo-mode;
> +};
> diff --git a/arch/arm/dts/rk3328-rock64.dts b/arch/arm/dts/rk3328-rock64.dts
> new file mode 100644
> index 00..7bcc53fcce
> --- /dev/null
> +++ b/arch/arm/dts/rk3328-rock64.dts
> @@ -0,0 +1,294 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2017 PINE64
> + */
> +
> +/dts-v1/;
> +#include "rk3328.dtsi"
> +
> +/ {
> + model = "Pine64 Rock64";
> + compatible = "pine64,rock64", "rockchip,rk3328";
> +
> + chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + gmac_clkin: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <12500>;
> + clock-output-names = "gmac_clkin";
> + #clock-cells = <0>;
> + };
> +
> + vcc_sd: sdmmc-regulator {
> + compatible = "regulator-fixed";
> + gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdmmc0m1_gpio>;
> + regulator-name = "vcc_sd";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + vin-supply = <&vcc_io>;
> + };
> +
> + vcc_host_5v: vcc-host-5v-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb30_host_drv>;
> + regulator-name = "vcc_host_5v";
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <&vcc_sys>;
> + };
> +
> + vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb20_host_drv>;
> + regulator-name = "vcc_host1_5v";
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <&vcc_sys>;
> + };
> +
> + vcc_sys: vcc-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +};
> +
> +&cpu0 {
> + cpu-supply = <&vdd_arm>;
> +};
> +
> +&cpu1 {
> + cpu-supply = <&vdd_arm>;
> +};
> +
> +&cpu2 {
> + cpu-supply = <&vdd_arm>;
> +};
> +
> +&cpu3 {
> + cpu-supply = <&vdd_arm>;
> +};
> +
> +&emmc {
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + mmc-hs200-1_8v;
> + non-removable;
> + pinctrl-names = "default";
> + pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_bus8>;
> + vmmc-supply = <&vcc_io>;
> + vqmmc-supply = <&vcc18_emmc>;
> + status = "okay";
> +};
> +
> +&gmac2io {
> + assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>;
> + assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>;
>
[U-Boot] [PATCH 3/3] arm: mediatek: remove arch_misc_init
The watchdog of mediatek chips is enabled by bootrom before u-boot is
running. Previously we choose to enable the wdt driver only to disable the
watchdog hardware.
Now wdt service is enabled by default. The function arch_misc_init which is
only used to disable wdt is no longer needed.
Reviewed-by: Ryder Lee
Signed-off-by: Weijie Gao
---
arch/arm/mach-mediatek/Kconfig | 3 ---
arch/arm/mach-mediatek/cpu.c | 12
2 files changed, 15 deletions(-)
diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig
index b5e91d4a7d..60aef15f15 100644
--- a/arch/arm/mach-mediatek/Kconfig
+++ b/arch/arm/mach-mediatek/Kconfig
@@ -12,7 +12,6 @@ choice
config TARGET_MT7623
bool "MediaTek MT7623 SoC"
select CPU_V7A
- select ARCH_MISC_INIT
help
The MediaTek MT7623 is a ARM-based SoC with a quad-core Cortex-A7
including NEON and GPU, Mali-450 graphics, several DDR3 options,
@@ -25,7 +24,6 @@ config TARGET_MT7629
bool "MediaTek MT7629 SoC"
select CPU_V7A
select SPL
- select ARCH_MISC_INIT
help
The MediaTek MT7629 is a ARM-based SoC with a dual-core Cortex-A7
including DDR3, crypto engine, 3x3 11n/ac Wi-Fi, Gigabit Ethernet,
@@ -34,7 +32,6 @@ config TARGET_MT7629
config TARGET_MT8516
bool "MediaTek MT8516 SoC"
select ARM64
- select ARCH_MISC_INIT
help
The MediaTek MT8516 is a ARM64-based SoC with a quad-core Cortex-A35.
including UART, SPI, USB2.0 and OTG, SD and MMC cards, NAND, PWM,
diff --git a/arch/arm/mach-mediatek/cpu.c b/arch/arm/mach-mediatek/cpu.c
index b37e299b74..1923c9e527 100644
--- a/arch/arm/mach-mediatek/cpu.c
+++ b/arch/arm/mach-mediatek/cpu.c
@@ -8,18 +8,6 @@
#include
#include
-int arch_misc_init(void)
-{
- struct udevice *wdt;
- int ret;
-
- ret = uclass_first_device_err(UCLASS_WDT, &wdt);
- if (!ret)
- wdt_stop(wdt);
-
- return 0;
-}
-
int arch_cpu_init(void)
{
icache_enable();
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] board_r: move initr_serial to be called before initr_watchdog
The initr_watchdog is currently placed before initr_serial. The
initr_watchdog calls printf and printf finally calls ops->putc of a serial
driver.
However, gd->cur_serial_dev points to a udevice allocated in board_f. The
gd->cur_serial_dev->driver->ops->putc points the the code region before
relocation.
Some serial drivers call WATCHDOG_RESET() in ops->putc. When DM is enabled
for watchdog, watchdog_reset() is called. watchdog_reset() calls get_timer
to get current timer.
On some platforms the timer driver is also a DM driver. initr_watchdog is
placed right after initr_dm, which means the timer driver hasn't been
initialized. So dm_timer_init() is called. To create a new udevice, calloc
is called.
However start from ops->putc, u-boot execution flow is redirected into the
memory region before relocation (board_f). In board_f, dlmalloc hasn't
been initialized. The call to calloc will fail, and this will cause DM to
print out an error message, and it will call printf again, causing
recursive error outputs.
This patch places initr_serial before initr_watchdog to solve this issue.
Cc: Stefan Roese
Reviewed-by: Ryder Lee
Signed-off-by: Weijie Gao
---
common/board_r.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_r.c b/common/board_r.c
index 150e8cd424..a298146c2b 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -678,6 +678,7 @@ static init_fnc_t init_sequence_r[] = {
#ifdef CONFIG_DM
initr_dm,
#endif
+ initr_serial,
#if defined(CONFIG_WDT)
initr_watchdog,
#endif
@@ -698,7 +699,6 @@ static init_fnc_t init_sequence_r[] = {
efi_memory_init,
#endif
stdio_init_tables,
- initr_serial,
initr_announce,
INIT_FUNC_WATCHDOG_RESET
#ifdef CONFIG_NEEDS_MANUAL_RELOC
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] watchdog: mtk_wdt: fix timeout calculation
U-Boot passes timeout in milliseconds for ops->start. However the driver treats this value as seconds. This will cause an overflow on writing wdt register. This patch divides the timeout by 1000 before writing to wdt register. Reviewed-by: Ryder Lee Signed-off-by: Weijie Gao --- drivers/watchdog/mtk_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c index 0b501733f2..19e3fde968 100644 --- a/drivers/watchdog/mtk_wdt.c +++ b/drivers/watchdog/mtk_wdt.c @@ -78,7 +78,7 @@ static void mtk_wdt_set_timeout(struct udevice *dev, unsigned int timeout) * One bit is the value of 512 ticks * The clock has 32 KHz */ - timeout = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY; + timeout = WDT_LENGTH_TIMEOUT((timeout << 6) / 1000) | WDT_LENGTH_KEY; writel(timeout, priv->base + MTK_WDT_LENGTH); mtk_wdt_reset(dev); -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [v2] board: ls1028a: Add an empty video hw init function
The video driver causes a link failure when config VIDEO built-in,
drivers/video/cfb_console.c:2022: undefined reference to `video_hw_init'
Adding an empty video hw init to slove the build issue, now the board
does not support display anything on U-boot.
Signed-off-by: Wen He
---
board/freescale/ls1028a/ls1028a.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/board/freescale/ls1028a/ls1028a.c
b/board/freescale/ls1028a/ls1028a.c
index e5de4eb70c..ece91660bf 100644
--- a/board/freescale/ls1028a/ls1028a.c
+++ b/board/freescale/ls1028a/ls1028a.c
@@ -20,6 +20,7 @@
#endif
#include
#include
+#include
#include
#include
@@ -229,3 +230,8 @@ int checkboard(void)
return 0;
}
#endif
+
+void *video_hw_init(void)
+{
+ return NULL;
+}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: merge adjacent sprintf()
In the implementation of the device path to text protocol join adjacent sprintf() statements. Signed-off-by: Heinrich Schuchardt --- lib/efi_loader/efi_device_path_to_text.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/lib/efi_loader/efi_device_path_to_text.c b/lib/efi_loader/efi_device_path_to_text.c index f3a9579076..96fd08971b 100644 --- a/lib/efi_loader/efi_device_path_to_text.c +++ b/lib/efi_loader/efi_device_path_to_text.c @@ -79,9 +79,8 @@ static char *dp_acpi(char *s, struct efi_device_path *dp) struct efi_device_path_acpi_path *adp = (struct efi_device_path_acpi_path *)dp; - s += sprintf(s, "Acpi(PNP%04X", EISA_PNP_NUM(adp->hid)); - s += sprintf(s, ",%d", adp->uid); - s += sprintf(s, ")"); + s += sprintf(s, "Acpi(PNP%04X,%d)", EISA_PNP_NUM(adp->hid), +adp->uid); break; } default: -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [v1] ls1028a: video: Add a empty video hw init for LS1028A
The video driver causes a link failure when config VIDEO built-in,
drivers/video/cfb_console.c:2022: undefined reference to `video_hw_init'
Adding a empty video hw init to slove the build issue, now the board
does not support display anything on U-boot.
Signed-off-by: Wen He
---
board/freescale/ls1028a/ls1028a.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/board/freescale/ls1028a/ls1028a.c
b/board/freescale/ls1028a/ls1028a.c
index e5de4eb70c..ece91660bf 100644
--- a/board/freescale/ls1028a/ls1028a.c
+++ b/board/freescale/ls1028a/ls1028a.c
@@ -20,6 +20,7 @@
#endif
#include
#include
+#include
#include
#include
@@ -229,3 +230,8 @@ int checkboard(void)
return 0;
}
#endif
+
+void *video_hw_init(void)
+{
+ return NULL;
+}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 12/15] i.MX7ULP: Workaround APLL PFD2 to 345.6Mhz
From: Ye Li The GPU uses APLL PFD2 as its clock parent (483.84Mhz) with divider set to 1. This frequecy is out of ULP A0 spec. The MAX rate for GPU is 350Mhz. So we simply configure the APLL PFD2 to 345.6Mhz (FRAC=28) to workaround the problem. The correct fix should let GPU handle the clock rate in kernel. Signed-off-by: Ye Li Signed-off-by: Peng Fan --- arch/arm/mach-imx/mx7ulp/clock.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-imx/mx7ulp/clock.c b/arch/arm/mach-imx/mx7ulp/clock.c index 0a0165cad2..6d6697ad99 100644 --- a/arch/arm/mach-imx/mx7ulp/clock.c +++ b/arch/arm/mach-imx/mx7ulp/clock.c @@ -300,9 +300,9 @@ void clock_init(void) scg_a7_soscdiv_init(); - /* APLL PFD1 = 270Mhz, PFD2=480Mhz, PFD3=800Mhz */ + /* APLL PFD1 = 270Mhz, PFD2=345.6Mhz, PFD3=800Mhz */ scg_enable_pll_pfd(SCG_APLL_PFD1_CLK, 35); - scg_enable_pll_pfd(SCG_APLL_PFD2_CLK, 20); + scg_enable_pll_pfd(SCG_APLL_PFD2_CLK, 28); scg_enable_pll_pfd(SCG_APLL_PFD3_CLK, 12); init_clk_lpuart(); -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 14/15] i.MX7ULP: Set A7 core frequency to 500Mhz for B0 chip
From: Ye Li
The normal target frequency for ULP A7 core is 500Mhz, but now ROM
set the core frequency to 413Mhz. So change it to 500Mhz in u-boot.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
arch/arm/include/asm/arch-mx7ulp/scg.h | 1 +
arch/arm/mach-imx/mx7ulp/clock.c | 2 ++
arch/arm/mach-imx/mx7ulp/scg.c | 41 ++
3 files changed, 44 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx7ulp/scg.h
b/arch/arm/include/asm/arch-mx7ulp/scg.h
index f1fae010da..531d8f3a95 100644
--- a/arch/arm/include/asm/arch-mx7ulp/scg.h
+++ b/arch/arm/include/asm/arch-mx7ulp/scg.h
@@ -337,5 +337,6 @@ void scg_a7_nicclk_init(void);
void scg_a7_sys_clk_sel(enum scg_sys_src clk);
void scg_a7_info(void);
void scg_a7_soscdiv_init(void);
+void scg_a7_init_core_clk(void);
#endif
diff --git a/arch/arm/mach-imx/mx7ulp/clock.c b/arch/arm/mach-imx/mx7ulp/clock.c
index 6d6697ad99..65d7fcfa39 100644
--- a/arch/arm/mach-imx/mx7ulp/clock.c
+++ b/arch/arm/mach-imx/mx7ulp/clock.c
@@ -300,6 +300,8 @@ void clock_init(void)
scg_a7_soscdiv_init();
+ scg_a7_init_core_clk();
+
/* APLL PFD1 = 270Mhz, PFD2=345.6Mhz, PFD3=800Mhz */
scg_enable_pll_pfd(SCG_APLL_PFD1_CLK, 35);
scg_enable_pll_pfd(SCG_APLL_PFD2_CLK, 28);
diff --git a/arch/arm/mach-imx/mx7ulp/scg.c b/arch/arm/mach-imx/mx7ulp/scg.c
index a28a2bc81b..0d31352c77 100644
--- a/arch/arm/mach-imx/mx7ulp/scg.c
+++ b/arch/arm/mach-imx/mx7ulp/scg.c
@@ -1091,3 +1091,44 @@ void scg_a7_info(void)
debug("SCG RCCR Value: 0x%x\n", readl(&scg1_regs->rccr));
debug("SCG Clock Status: 0x%x\n", readl(&scg1_regs->csr));
}
+
+void scg_a7_init_core_clk(void)
+{
+ u32 val = 0;
+
+ /*
+* The normal target frequency for ULP B0 is 500Mhz,
+* but ROM set it to 413Mhz, need to change SPLL PFD0 FRAC
+*/
+ if (soc_rev() >= CHIP_REV_2_0) {
+ /* Switch RCCR SCG to SOSC, firstly check the SOSC is valid */
+ if ((readl(&scg1_regs->sosccsr) & SCG_SOSC_CSR_SOSCVLD_MASK)) {
+ val = readl(&scg1_regs->rccr);
+ val &= (~SCG_CCR_SCS_MASK);
+ val |= ((SCG_SCS_SYS_OSC) << SCG_CCR_SCS_SHIFT);
+ writel(val, &scg1_regs->rccr);
+
+ /* Switch the PLLS to SPLL clk */
+ val = readl(&scg1_regs->spllcfg);
+ val &= ~SCG_PLL_CFG_PLLSEL_MASK;
+ writel(val, &scg1_regs->spllcfg);
+
+ /*
+* Re-configure PFD0 to 19,
+* A7 SPLL(528MHz) * 18 / 19 = 500MHz
+*/
+ scg_enable_pll_pfd(SCG_SPLL_PFD0_CLK, 19);
+
+ /* Switch the PLLS to SPLL PFD0 */
+ val = readl(&scg1_regs->spllcfg);
+ val |= SCG_PLL_CFG_PLLSEL_MASK;
+ writel(val, &scg1_regs->spllcfg);
+
+ /* Set RCCR SCG to SPLL clk out */
+ val = readl(&scg1_regs->rccr);
+ val &= (~SCG_CCR_SCS_MASK);
+ val |= ((SCG_SCS_SYS_PLL) << SCG_CCR_SCS_SHIFT);
+ writel(val, &scg1_regs->rccr);
+ }
+ }
+}
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 13/15] i.MX7ULP: Add CPU revision check for B0
Since there is no register for CPU revision, we use ROM version to
check the A0 or B0 chip.
Signed-off-by: Peng Fan
---
arch/arm/mach-imx/mx7ulp/soc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 7119ee4a07..6c53aa106e 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -18,10 +18,13 @@ struct imx_sec_config_fuse_t const imx_sec_config_fuse = {
};
#endif
+#define ROM_VERSION_ADDR 0x80
u32 get_cpu_rev(void)
{
- /* Temporally hard code the CPU rev to 0x73, rev 1.0. Fix it later */
- return (MXC_CPU_MX7ULP << 12) | (1 << 4);
+ /* Check the ROM version for cpu revision */
+ u32 rom_version = readl((void __iomem *)ROM_VERSION_ADDR);
+
+ return (MXC_CPU_MX7ULP << 12) | (rom_version & 0xFF);
}
#ifdef CONFIG_REVISION_TAG
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 15/15] i.MX7ULP: Change clock rate calculation for NIC1 BUS and EXT
From: Ye Li
On i.MX7ULP B0, there is change in NIC clock dividers architecture.
On A0, the NIC1 BUS and EXT dividers were in a chain with NIC1 DIV, but
on B0 they are parallel with NIC1 DIV. So now the dividers are independent.
This patch modifies the scg_nic_get_rate function according to this change.
Signed-off-by: Ye Li
Acked-by: Peng Fan
---
arch/arm/mach-imx/mx7ulp/scg.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/mx7ulp/scg.c b/arch/arm/mach-imx/mx7ulp/scg.c
index 0d31352c77..819c90af6c 100644
--- a/arch/arm/mach-imx/mx7ulp/scg.c
+++ b/arch/arm/mach-imx/mx7ulp/scg.c
@@ -352,7 +352,7 @@ static u32 scg_ddr_get_rate(void)
static u32 scg_nic_get_rate(enum scg_clk clk)
{
- u32 reg, val, rate;
+ u32 reg, val, rate, nic0_rate;
u32 shift, mask;
reg = readl(&scg1_regs->niccsr);
@@ -370,6 +370,7 @@ static u32 scg_nic_get_rate(enum scg_clk clk)
val = (reg & SCG_NICCSR_NIC0DIV_MASK) >> SCG_NICCSR_NIC0DIV_SHIFT;
rate = rate / (val + 1);
+ nic0_rate = rate;
clk_debug("scg_nic_get_rate NIC0 rate %u\n", rate);
@@ -411,6 +412,13 @@ static u32 scg_nic_get_rate(enum scg_clk clk)
return 0;
}
+ /*
+* On RevB, the nic_bus and nic_ext dividers are parallel
+* not chained with nic div
+*/
+ if (soc_rev() >= CHIP_REV_2_0)
+ rate = nic0_rate;
+
val = (reg & mask) >> shift;
rate = rate / (val + 1);
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 08/15] i.MX7ULP: Fix wrong i2c configuration name
From: Ye Li
Wrong I2c driver configuration name is used in codes, so I2c driver is
not built. Correct it.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
arch/arm/include/asm/arch-mx7ulp/clock.h | 2 +-
arch/arm/mach-imx/mx7ulp/clock.c | 2 +-
configs/mx7ulp_evk_defconfig | 1 +
configs/mx7ulp_evk_plugin_defconfig | 1 +
4 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx7ulp/clock.h
b/arch/arm/include/asm/arch-mx7ulp/clock.h
index bf69785831..eb02a20fdc 100644
--- a/arch/arm/include/asm/arch-mx7ulp/clock.h
+++ b/arch/arm/include/asm/arch-mx7ulp/clock.h
@@ -26,7 +26,7 @@ enum mxc_clock {
u32 mxc_get_clock(enum mxc_clock clk);
u32 get_lpuart_clk(void);
-#ifdef CONFIG_SYS_LPI2C_IMX
+#ifdef CONFIG_SYS_I2C_IMX_LPI2C
int enable_i2c_clk(unsigned char enable, unsigned i2c_num);
u32 imx_get_i2cclk(unsigned i2c_num);
#endif
diff --git a/arch/arm/mach-imx/mx7ulp/clock.c b/arch/arm/mach-imx/mx7ulp/clock.c
index fac9011388..0a0165cad2 100644
--- a/arch/arm/mach-imx/mx7ulp/clock.c
+++ b/arch/arm/mach-imx/mx7ulp/clock.c
@@ -72,7 +72,7 @@ u32 get_lpuart_clk(void)
return pcc_clock_get_rate(lpuart_pcc_clks[index - 4]);
}
-#ifdef CONFIG_SYS_LPI2C_IMX
+#ifdef CONFIG_SYS_I2C_IMX_LPI2C
int enable_i2c_clk(unsigned char enable, unsigned i2c_num)
{
/* Set parent to FIRC DIV2 clock */
diff --git a/configs/mx7ulp_evk_defconfig b/configs/mx7ulp_evk_defconfig
index c7af66b2e9..62a1ed6393 100644
--- a/configs/mx7ulp_evk_defconfig
+++ b/configs/mx7ulp_evk_defconfig
@@ -21,6 +21,7 @@ CONFIG_DM_GPIO=y
CONFIG_IMX_RGPIO2P=y
# CONFIG_MXC_GPIO is not set
CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_IMX_LPI2C=y
CONFIG_DM_MMC=y
CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_FSL_ESDHC=y
diff --git a/configs/mx7ulp_evk_plugin_defconfig
b/configs/mx7ulp_evk_plugin_defconfig
index fcead94f57..1c6f0e7590 100644
--- a/configs/mx7ulp_evk_plugin_defconfig
+++ b/configs/mx7ulp_evk_plugin_defconfig
@@ -20,6 +20,7 @@ CONFIG_IMX_RGPIO2P=y
# CONFIG_MXC_GPIO is not set
CONFIG_DM_I2C=y
CONFIG_DM_MMC=y
+CONFIG_SYS_I2C_IMX_LPI2C=y
CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_FSL_ESDHC=y
CONFIG_PINCTRL=y
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/15] misc: Kconfig: make i.MX7ULP could use MXC_OCOTP
Signed-off-by: Peng Fan --- drivers/misc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 0e645f58be..911777137d 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -128,7 +128,7 @@ config JZ4780_EFUSE config MXC_OCOTP bool "Enable MXC OCOTP Driver" - depends on ARCH_IMX8M || ARCH_MX6 || ARCH_MX7 || ARCH_VF610 + depends on ARCH_IMX8M || ARCH_MX6 || ARCH_MX7 || ARCH_MX7ULP || ARCH_VF610 default y help If you say Y here, you will get support for the One Time -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 05/15] i.MX7ULP: Correct the clock index
From: Bai Ping On i.MX7ULP, value zero is reserved in SCG1 RCCR register, so the val should be decreased by 1 to get the correct clock source index. Signed-off-by: Bai Ping Signed-off-by: Peng Fan --- arch/arm/mach-imx/mx7ulp/scg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/mx7ulp/scg.c b/arch/arm/mach-imx/mx7ulp/scg.c index b4f2ea875a..85d726fe30 100644 --- a/arch/arm/mach-imx/mx7ulp/scg.c +++ b/arch/arm/mach-imx/mx7ulp/scg.c @@ -440,7 +440,7 @@ static u32 scg_sys_get_rate(enum scg_clk clk) case SCG_SCS_SLOW_IRC: case SCG_SCS_FAST_IRC: case SCG_SCS_RTC_OSC: - rate = scg_src_get_rate(scg_scs_array[val]); + rate = scg_src_get_rate(scg_scs_array[val - 1]); break; case 5: rate = scg_apll_get_rate(); -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 10/15] i.MX7ULP: evk: Enable fuse comamnd
Enable fuse command Signed-off-by: Peng Fan --- configs/mx7ulp_evk_defconfig| 1 + configs/mx7ulp_evk_plugin_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/mx7ulp_evk_defconfig b/configs/mx7ulp_evk_defconfig index 62a1ed6393..520bdd4722 100644 --- a/configs/mx7ulp_evk_defconfig +++ b/configs/mx7ulp_evk_defconfig @@ -9,6 +9,7 @@ CONFIG_BOUNCE_BUFFER=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y CONFIG_CMD_MEMTEST=y +CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y diff --git a/configs/mx7ulp_evk_plugin_defconfig b/configs/mx7ulp_evk_plugin_defconfig index 1c6f0e7590..bb27909f5c 100644 --- a/configs/mx7ulp_evk_plugin_defconfig +++ b/configs/mx7ulp_evk_plugin_defconfig @@ -7,6 +7,7 @@ CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx7ulp_evk/imximage.cfg" CONFIG_BOUNCE_BUFFER=y CONFIG_HUSH_PARSER=y CONFIG_CMD_MEMTEST=y +CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/15] i.MX7ULP: Fix system reset after a7 rtc alarm expired.
From: Bai Ping
The board will reboot if A7 core enter mem mode by rtc, then M4 core
enter VLLS mode after the RTC alarm expired. Enable the dumb PMIC mode
to fix this issue.
Since i.MX7ULP B0 moves the SNVS LP into M4 domain, A core can't access
it. So check the CPU rev and not apply the settings for B0.
Signed-off-by: Bai Ping
Signed-off-by: Peng Fan
---
arch/arm/include/asm/arch-mx7ulp/imx-regs.h | 7 +++
arch/arm/mach-imx/mx7ulp/soc.c | 4
2 files changed, 11 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx7ulp/imx-regs.h
b/arch/arm/include/asm/arch-mx7ulp/imx-regs.h
index d58ed43199..3c82e9921e 100644
--- a/arch/arm/include/asm/arch-mx7ulp/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx7ulp/imx-regs.h
@@ -58,6 +58,7 @@
#define USDHC1_AIPS2_SLOT (56)
#define RGPIO2P0_AIPS0_SLOT(15)
#define RGPIO2P1_AIPS2_SLOT(15)
+#define SNVS_AIPS2_SLOT(35)
#define IOMUXC0_AIPS0_SLOT (61)
#define OCOTP_CTRL_AIPS1_SLOT (38)
#define OCOTP_CTRL_PCC1_SLOT (38)
@@ -177,6 +178,9 @@
#define USDHC0_RBASE ((AIPS2_BASE + (AIPS2_SLOT_SIZE * USDHC0_AIPS2_SLOT)))
#define USDHC1_RBASE ((AIPS2_BASE + (AIPS2_SLOT_SIZE * USDHC1_AIPS2_SLOT)))
+#define SNVS_BASE ((AIPS2_BASE + (AIPS2_SLOT_SIZE * SNVS_AIPS2_SLOT)))
+#define SNVS_LP_LPCR (SNVS_BASE + 0x38)
+
#define RGPIO2P0_RBASE ((AIPS0_BASE + (AIPS0_SLOT_SIZE * RGPIO2P0_AIPS0_SLOT)))
#define RGPIO2P1_RBASE ((AIPS2_BASE + (AIPS2_SLOT_SIZE * RGPIO2P1_AIPS2_SLOT)))
@@ -939,6 +943,9 @@
#define MMDC_MPWRDQBY3DL_WR_DQ25_DEL_MASK ((0x3f <<
MMDC_MPWRDQBY3DL_WR_DQ25_DEL))
#define MMDC_MPWRDQBY3DL_WR_DQ24_DEL_MASK ((0x3f <<
MMDC_MPWRDQBY3DL_WR_DQ24_DEL))
+#define SNVS_LPCR_DPEN (0x20)
+#define SNVS_LPCR_SRTC_ENV (0x1)
+
#if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__))
#include
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 6015c11869..7119ee4a07 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -106,6 +106,10 @@ void s_init(void)
/* clock configuration. */
clock_init();
+ if (soc_rev() < CHIP_REV_2_0) {
+ /* enable dumb pmic */
+ writel((readl(SNVS_LP_LPCR) | SNVS_LPCR_DPEN), SNVS_LP_LPCR);
+ }
return;
}
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 11/15] i.MX7ULP: Fix SPLL/APLL clock rate calculation issue
From: Ye Li The num/denom is a float value, but in the calculation it is convert to integer 0, and cause the result wrong. Signed-off-by: Ye Li Signed-off-by: Peng Fan --- arch/arm/mach-imx/mx7ulp/scg.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-imx/mx7ulp/scg.c b/arch/arm/mach-imx/mx7ulp/scg.c index 85d726fe30..a28a2bc81b 100644 --- a/arch/arm/mach-imx/mx7ulp/scg.c +++ b/arch/arm/mach-imx/mx7ulp/scg.c @@ -503,7 +503,10 @@ u32 decode_pll(enum pll_clocks pll) infreq = infreq / pre_div; - return infreq * mult + infreq * num / denom; + if (denom) + return infreq * mult + infreq * num / denom; + else + return infreq * mult; case PLL_A7_APLL: reg = readl(&scg1_regs->apllcsr); @@ -532,7 +535,10 @@ u32 decode_pll(enum pll_clocks pll) infreq = infreq / pre_div; - return infreq * mult + infreq * num / denom; + if (denom) + return infreq * mult + infreq * num / denom; + else + return infreq * mult; case PLL_USB: reg = readl(&scg1_regs->upllcsr); -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 07/15] i.MX7ULP: Add CONFIG_MX7ULP to kconfig
From: Ye Li Since many drivers need this CONFIG_MX7ULP to distiguish the settings for i.MX7ULP only. Add this entry to cpu's kconfig. Signed-off-by: Ye Li Signed-off-by: Peng Fan --- arch/arm/mach-imx/mx7ulp/Kconfig | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/mx7ulp/Kconfig b/arch/arm/mach-imx/mx7ulp/Kconfig index d4b0299dbd..ed5f0aeb2d 100644 --- a/arch/arm/mach-imx/mx7ulp/Kconfig +++ b/arch/arm/mach-imx/mx7ulp/Kconfig @@ -3,12 +3,16 @@ if ARCH_MX7ULP config SYS_SOC default "mx7ulp" +config MX7ULP + bool + choice prompt "MX7ULP board select" optional config TARGET_MX7ULP_EVK -bool "Support mx7ulp EVK board" + bool "Support mx7ulp EVK board" + select MX7ULP select SYS_ARCH_TIMER endchoice -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 06/15] i.MX7ULP: Fix PCC register bits mask and offset issue
From: Ye Li
The offset for FRAC and the mask for PCD are not correct.
If we set FRAC, we can't get the right frequency. Fix them
to correct value.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
arch/arm/include/asm/arch-mx7ulp/pcc.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx7ulp/pcc.h
b/arch/arm/include/asm/arch-mx7ulp/pcc.h
index 67a0936150..dee3cfcdc0 100644
--- a/arch/arm/include/asm/arch-mx7ulp/pcc.h
+++ b/arch/arm/include/asm/arch-mx7ulp/pcc.h
@@ -289,10 +289,10 @@ enum pcc3_entry {
#define PCC_INUSE_MASK (0x1 << PCC_INUSE_OFFSET)
#define PCC_PCS_OFFSET 24
#define PCC_PCS_MASK (0x7 << PCC_PCS_OFFSET)
-#define PCC_FRAC_OFFSET4
+#define PCC_FRAC_OFFSET3
#define PCC_FRAC_MASK (0x1 << PCC_FRAC_OFFSET)
#define PCC_PCD_OFFSET 0
-#define PCC_PCD_MASK (0xf << PCC_PCD_OFFSET)
+#define PCC_PCD_MASK (0x7 << PCC_PCD_OFFSET)
enum pcc_clksrc_type {
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 03/15] i.MX7ULP: evk: Modify FDT file to disable SD3.0 for usb boot
Since the SD3.0 kernel driver needs M4 image support, this causes
problem for usb boot booting into kernel. To decouple the relationship,
we modify the FDT file in u-boot to disable SD3.0.
So the kernel won't depend on M4 image.
Signed-off-by: Peng Fan
---
board/freescale/mx7ulp_evk/mx7ulp_evk.c | 47 +
configs/mx7ulp_evk_defconfig| 1 +
2 files changed, 48 insertions(+)
diff --git a/board/freescale/mx7ulp_evk/mx7ulp_evk.c
b/board/freescale/mx7ulp_evk/mx7ulp_evk.c
index 3a12fe1551..7527263577 100644
--- a/board/freescale/mx7ulp_evk/mx7ulp_evk.c
+++ b/board/freescale/mx7ulp_evk/mx7ulp_evk.c
@@ -4,10 +4,12 @@
*/
#include
+#include
#include
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -45,3 +47,48 @@ int board_init(void)
return 0;
}
+
+#if IS_ENABLED(CONFIG_OF_BOARD_SETUP)
+int ft_board_setup(void *blob, bd_t *bd)
+{
+ const char *path;
+ int rc, nodeoff;
+
+ if (get_boot_device() == USB_BOOT) {
+ path = fdt_get_alias(blob, "mmc0");
+ if (!path) {
+ puts("Not found mmc0\n");
+ return 0;
+ }
+
+ nodeoff = fdt_path_offset(blob, path);
+ if (nodeoff < 0)
+ return 0;
+
+ printf("Found usdhc0 node\n");
+ if (fdt_get_property(blob, nodeoff, "vqmmc-supply",
+ NULL) != NULL) {
+ rc = fdt_delprop(blob, nodeoff, "vqmmc-supply");
+ if (!rc) {
+ puts("Removed vqmmc-supply property\n");
+add:
+ rc = fdt_setprop(blob, nodeoff,
+"no-1-8-v", NULL, 0);
+ if (rc == -FDT_ERR_NOSPACE) {
+ rc = fdt_increase_size(blob, 32);
+ if (!rc)
+ goto add;
+ } else if (rc) {
+ printf("Failed to add no-1-8-v
property, %d\n", rc);
+ } else {
+ puts("Added no-1-8-v property\n");
+ }
+ } else {
+ printf("Failed to remove vqmmc-supply property,
%d\n", rc);
+ }
+ }
+ }
+
+ return 0;
+}
+#endif
diff --git a/configs/mx7ulp_evk_defconfig b/configs/mx7ulp_evk_defconfig
index d125ccc1af..c7af66b2e9 100644
--- a/configs/mx7ulp_evk_defconfig
+++ b/configs/mx7ulp_evk_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_MX7ULP=y
CONFIG_SYS_TEXT_BASE=0x6780
CONFIG_TARGET_MX7ULP_EVK=y
CONFIG_NR_DRAM_BANKS=1
+CONFIG_OF_BOARD_SETUP=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx7ulp_evk/imximage.cfg"
CONFIG_BOUNCE_BUFFER=y
CONFIG_HUSH_PARSER=y
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 02/15] imx: i.MX7ULP: add get_boot_device
Add get_boot_device for i.MX7ULP
Signed-off-by: Peng Fan
---
arch/arm/include/asm/arch-mx7ulp/imx-regs.h | 13 +
arch/arm/include/asm/arch-mx7ulp/sys_proto.h | 1 +
arch/arm/mach-imx/mx7ulp/soc.c | 27 +++
3 files changed, 41 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx7ulp/imx-regs.h
b/arch/arm/include/asm/arch-mx7ulp/imx-regs.h
index 63b02de087..d58ed43199 100644
--- a/arch/arm/include/asm/arch-mx7ulp/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx7ulp/imx-regs.h
@@ -10,6 +10,8 @@
#define ARCH_MXC
+#define ROM_SW_INFO_ADDR0x01E8
+
#define CAAM_SEC_SRAM_BASE (0x2600)
#define CAAM_SEC_SRAM_SIZE (SZ_32K)
#define CAAM_SEC_SRAM_END (CAAM_SEC_SRAM_BASE + CAAM_SEC_SRAM_SIZE - 1)
@@ -1112,6 +1114,17 @@ struct usbphy_regs {
u32 usb1_pfda_ctrl1_tog;/* 0x14c */
};
+struct bootrom_sw_info {
+ u8 reserved_1;
+ u8 boot_dev_instance;
+ u8 boot_dev_type;
+ u8 reserved_2;
+ u32 core_freq;
+ u32 axi_freq;
+ u32 ddr_freq;
+ u32 rom_tick_freq;
+ u32 reserved_3[3];
+};
#defineis_boot_from_usb(void) (!(readl(USB_PHY0_BASE_ADDR) &
(1<<20)))
#definedisconnect_from_pc(void)writel(0x0, USBOTG0_RBASE +
0x140)
diff --git a/arch/arm/include/asm/arch-mx7ulp/sys_proto.h
b/arch/arm/include/asm/arch-mx7ulp/sys_proto.h
index 6ecde7db93..0e4c8ad15d 100644
--- a/arch/arm/include/asm/arch-mx7ulp/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx7ulp/sys_proto.h
@@ -17,4 +17,5 @@ enum bt_mode {
SINGLE_BOOT /* LP_BT = 0, DUAL_BT = 0 */
};
+enum boot_device get_boot_device(void);
#endif
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index c72f0ed3fc..6015c11869 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
static char *get_reset_cause(char *);
@@ -244,3 +245,29 @@ int mmc_get_env_dev(void)
return board_mmc_get_env_dev(devno);
}
#endif
+
+enum boot_device get_boot_device(void)
+{
+ struct bootrom_sw_info **p =
+ (struct bootrom_sw_info **)ROM_SW_INFO_ADDR;
+
+ enum boot_device boot_dev = SD1_BOOT;
+ u8 boot_type = (*p)->boot_dev_type;
+ u8 boot_instance = (*p)->boot_dev_instance;
+
+ switch (boot_type) {
+ case BOOT_TYPE_SD:
+ boot_dev = boot_instance + SD1_BOOT;
+ break;
+ case BOOT_TYPE_MMC:
+ boot_dev = boot_instance + MMC1_BOOT;
+ break;
+ case BOOT_TYPE_USB:
+ boot_dev = USB_BOOT;
+ break;
+ default:
+ break;
+ }
+
+ return boot_dev;
+}
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 01/15] mx7ulp: Add common plugin codes for mx7ulp
From: Ye Li
Add common plugin codes to call ROM's hwcnfg_setup and generate IVT2
header.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
arch/arm/include/asm/arch-mx7ulp/mx7ulp_plugin.S | 93
arch/arm/mach-imx/Kconfig| 2 +-
2 files changed, 94 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/asm/arch-mx7ulp/mx7ulp_plugin.S
diff --git a/arch/arm/include/asm/arch-mx7ulp/mx7ulp_plugin.S
b/arch/arm/include/asm/arch-mx7ulp/mx7ulp_plugin.S
new file mode 100644
index 00..bcc804b58f
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx7ulp/mx7ulp_plugin.S
@@ -0,0 +1,93 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2019 NXP
+ */
+
+#include
+
+#define ROM_API_TABLE_BASE_ADDR_LEGACY 0x180
+#define ROM_VERSION_OFFSET 0x80
+#define ROM_API_HWCNFG_SETUP_OFFSET0x08
+
+plugin_start:
+
+ push{r0-r4, lr}
+
+ imx7ulp_ddr_setting
+ imx7ulp_clock_gating
+ imx7ulp_qos_setting
+
+normal_boot:
+
+/*
+ * The following is to fill in those arguments for this ROM function
+ * pu_irom_hwcnfg_setup(void **start, size_t *bytes, const void *boot_data)
+ * This function is used to copy data from the storage media into DDR.
+ * start - Initial (possibly partial) image load address on entry.
+ * Final image load address on exit.
+ * bytes - Initial (possibly partial) image size on entry.
+ * Final image size on exit.
+ * boot_data - Initial @ref ivt Boot Data load address.
+ */
+ adr r0, boot_data2
+ adr r1, image_len2
+ adr r2, boot_data2
+
+/*
+ * check the _pu_irom_api_table for the address
+ */
+before_calling_rom___pu_irom_hwcnfg_setup:
+ ldr r3, =ROM_VERSION_OFFSET
+ ldr r4, [r3]
+ ldr r3, =ROM_API_TABLE_BASE_ADDR_LEGACY
+ ldr r4, [r3, #ROM_API_HWCNFG_SETUP_OFFSET]
+ blx r4
+after_calling_rom___pu_irom_hwcnfg_setup:
+
+/*
+ * To return to ROM from plugin, we need to fill in these argument.
+ * Here is what need to do:
+ * Need to construct the parameters for this function before return to ROM:
+ * plugin_download(void **start, size_t *bytes, UINT32 *ivt_offset)
+ */
+ pop {r0-r4, lr}
+ push {r5}
+ ldr r5, boot_data2
+ str r5, [r0]
+ ldr r5, image_len2
+ str r5, [r1]
+ ldr r5, second_ivt_offset
+ str r5, [r2]
+ mov r0, #1
+ pop {r5}
+
+ /* return back to ROM code */
+ bx lr
+
+/* make the following data right in the end of the output*/
+.ltorg
+
+#define FLASH_OFFSET 0x400
+
+/*
+ * second_ivt_offset is the offset from the "second_ivt_header" to
+ * "image_copy_start", which involves FLASH_OFFSET, plus the first
+ * ivt_header, the plugin code size itself recorded by "ivt2_header"
+ */
+
+second_ivt_offset: .long (ivt2_header + 0x2C + FLASH_OFFSET)
+
+/*
+ * The following is the second IVT header plus the second boot data
+ */
+ivt2_header:.long 0x0
+app2_code_jump_v: .long 0x0
+reserv3:.long 0x0
+dcd2_ptr: .long 0x0
+boot_data2_ptr: .long 0x0
+self_ptr2: .long 0x0
+app_code_csf2: .long 0x0
+reserv4:.long 0x0
+boot_data2: .long 0x0
+image_len2: .long 0x0
+plugin2:.long 0x0
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index ec09ef240f..b6fd1595f0 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -29,7 +29,7 @@ config IMX_BOOTAUX
config USE_IMXIMG_PLUGIN
bool "Use imximage plugin code"
- depends on ARCH_MX7 || ARCH_MX6
+ depends on ARCH_MX7 || ARCH_MX6 || ARCH_MX7ULP
help
i.MX6/7 supports DCD and Plugin. Enable this configuration
to use Plugin, otherwise DCD will be used.
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] pci: layerscape: Add the workaround for errata A-009460
From: Xiaowei Bao
The VF_BARn_REG register's Prefetchable and Type bit fields
are overwritten by a write to VF's BAR Mask register.
workaround: Before writing to the VF_BARn_MASK_REG register,
write 0b to the PCIE_MISC_CONTROL_1_OFF register.
Signed-off-by: Xiaowei Bao
---
drivers/pci/pcie_layerscape.c |9 +
drivers/pci/pcie_layerscape.h |1 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 1b082da..7ba3c1d 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -450,6 +450,15 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie)
if (PCI_EXT_CAP_ID(sriov) == PCI_EXT_CAP_ID_SRIOV) {
pcie->sriov_flag = 1;
for (pf = 0; pf < PCIE_PF_NUM; pf++) {
+ /*
+* The VF_BARn_REG register's Prefetchable and Type bit
+* fields are overwritten by a write to VF's BAR Mask
+* register. Before writing to the VF_BARn_MASK_REG
+* register, write 0b to the PCIE_MISC_CONTROL_1_OFF
+* register.
+*/
+ writel(0, pcie->dbi + PCIE_MISC_CONTROL_1_OFF);
+
if (pcie->cfg2_flag) {
for (vf = 0; vf <= PCIE_VF_NUM; vf++) {
ctrl_writel(pcie,
diff --git a/drivers/pci/pcie_layerscape.h b/drivers/pci/pcie_layerscape.h
index 9038d32..067dd3c 100644
--- a/drivers/pci/pcie_layerscape.h
+++ b/drivers/pci/pcie_layerscape.h
@@ -94,6 +94,7 @@
#define PCIE_BAR4_SIZE SZ_1M /* 1M */
#define PCIE_SRIOV_VFBAR0 0x19C
+#define PCIE_MISC_CONTROL_1_OFF0x8BC
#define PCIE_CTRL1_FUNC_NUM0x0010
#define PCIE_MASK_OFFSET(flag, pf) ((flag) ? 0 : (0x1000 + 0x2 * (pf)))
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] PCI: layerscape: Add Support for ls2088 PCIe EP mode
From: Xiaowei Bao
Signed-off-by: hongbo.wang
Signed-off-by: Minghuan Lian
Signed-off-by: Xiaowei Bao
---
drivers/pci/pcie_layerscape.c | 117 +++-
drivers/pci/pcie_layerscape.h | 17 +--
2 files changed, 92 insertions(+), 42 deletions(-)
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index db1375a..1b082da 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -106,12 +106,17 @@ static void ls_pcie_atu_outbound_set(struct ls_pcie
*pcie, int idx, int type,
/* Use bar match mode and MEM type as default */
static void ls_pcie_atu_inbound_set(struct ls_pcie *pcie, int idx,
-int bar, u64 phys)
+ int bar, u64 phys, u32 pf)
{
+ u32 cr1 = 0;
+
+ if (pf)
+ cr1 |= PCIE_CTRL1_FUNC_NUM;
+
dbi_writel(pcie, PCIE_ATU_REGION_INBOUND | idx, PCIE_ATU_VIEWPORT);
dbi_writel(pcie, (u32)phys, PCIE_ATU_LOWER_TARGET);
dbi_writel(pcie, phys >> 32, PCIE_ATU_UPPER_TARGET);
- dbi_writel(pcie, PCIE_ATU_TYPE_MEM, PCIE_ATU_CR1);
+ dbi_writel(pcie, PCIE_ATU_TYPE_MEM | cr1, PCIE_ATU_CR1);
dbi_writel(pcie, PCIE_ATU_ENABLE | PCIE_ATU_BAR_MODE_ENABLE |
PCIE_ATU_BAR_NUM(bar), PCIE_ATU_CR2);
}
@@ -341,50 +346,61 @@ static void ls_pcie_setup_ctrl(struct ls_pcie *pcie)
ls_pcie_disable_bars(pcie);
}
-static void ls_pcie_ep_setup_atu(struct ls_pcie *pcie)
+static void ls_pcie_ep_setup_atu(struct ls_pcie *pcie, u32 pf)
{
- u64 phys = CONFIG_SYS_PCI_EP_MEMORY_BASE;
+ pci_size_t atu_size = CONFIG_SYS_PCI_MEMORY_SIZE;
+ u64 phys = 0;
+
+ phys = CONFIG_SYS_PCI_EP_MEMORY_BASE + pf * SZ_2M;
+ phys = ALIGN(phys, PCIE_BAR0_SIZE);
/* ATU 0 : INBOUND : map BAR0 */
- ls_pcie_atu_inbound_set(pcie, 0, 0, phys);
+ ls_pcie_atu_inbound_set(pcie, 0 + pf * BAR_NUM, 0, phys, pf);
/* ATU 1 : INBOUND : map BAR1 */
- phys += PCIE_BAR1_SIZE;
- ls_pcie_atu_inbound_set(pcie, 1, 1, phys);
+ phys = ALIGN(phys + PCIE_BAR0_SIZE, PCIE_BAR1_SIZE);
+ ls_pcie_atu_inbound_set(pcie, 1 + pf * BAR_NUM, 1, phys, pf);
/* ATU 2 : INBOUND : map BAR2 */
- phys += PCIE_BAR2_SIZE;
- ls_pcie_atu_inbound_set(pcie, 2, 2, phys);
- /* ATU 3 : INBOUND : map BAR4 */
- phys = CONFIG_SYS_PCI_EP_MEMORY_BASE + PCIE_BAR4_SIZE;
- ls_pcie_atu_inbound_set(pcie, 3, 4, phys);
+ phys = ALIGN(phys + PCIE_BAR1_SIZE, PCIE_BAR2_SIZE);
+ ls_pcie_atu_inbound_set(pcie, 2 + pf * BAR_NUM, 2, phys, pf);
+ /* ATU 3 : INBOUND : map BAR2 */
+ phys = ALIGN(phys + PCIE_BAR2_SIZE, PCIE_BAR2_SIZE);
+ ls_pcie_atu_inbound_set(pcie, 3 + pf * BAR_NUM, 4, phys, pf);
/* ATU 0 : OUTBOUND : map MEM */
- ls_pcie_atu_outbound_set(pcie, 0,
-PCIE_ATU_TYPE_MEM,
-pcie->cfg_res.start,
-0,
-CONFIG_SYS_PCI_MEMORY_SIZE);
+ ls_pcie_atu_outbound_set(pcie, PCIE_ATU_REGION_INDEX0,
+PCIE_ATU_TYPE_MEM, (u64)pcie->cfg_res.start,
+0, atu_size);
+
+ /* ATU 1 : OUTBOUND : map MEM */
+ ls_pcie_atu_outbound_set(pcie, PCIE_ATU_REGION_INDEX1,
+PCIE_ATU_TYPE_MEM, (u64)pcie->cfg_res.start
++ atu_size, atu_size, atu_size);
}
/* BAR0 and BAR1 are 32bit BAR2 and BAR4 are 64bit */
static void ls_pcie_ep_setup_bar(void *bar_base, int bar, u32 size)
{
+ u32 mask;
+
/* The least inbound window is 4KiB */
- if (size < 4 * 1024)
- return;
+ if (size < SZ_4K)
+ mask = 0;
+ else
+ mask = size - 1;
switch (bar) {
case 0:
- writel(size - 1, bar_base + PCI_BASE_ADDRESS_0);
+ writel(mask, bar_base + PCI_BASE_ADDRESS_0);
break;
case 1:
- writel(size - 1, bar_base + PCI_BASE_ADDRESS_1);
+ writel(mask, bar_base + PCI_BASE_ADDRESS_1);
break;
case 2:
- writel(size - 1, bar_base + PCI_BASE_ADDRESS_2);
+ writel(mask, bar_base + PCI_BASE_ADDRESS_2);
writel(0, bar_base + PCI_BASE_ADDRESS_3);
break;
case 4:
- writel(size - 1, bar_base + PCI_BASE_ADDRESS_4);
+ writel(mask, bar_base + PCI_BASE_ADDRESS_4);
writel(0, bar_base + PCI_BASE_ADDRESS_5);
break;
default:
@@ -394,13 +410,28 @@ static void ls_pcie_ep_setup_bar(void *bar_base, int bar,
u32 size)
static void ls_pcie_ep_setup_bars(void *bar_base)
{
- /* BAR0 - 32bit - 4K configuration */
+ /* BAR0 - 32bit - configuration */
+ ls_pcie_ep_setup_bar(bar_base, 0, PCIE_BAR
Re: [U-Boot] [linux-sunxi] [PATCH 2/6] sunxi: gpio: Enable support for H6 pin controller
于 2019年5月16日 GMT+08:00 上午9:26:29, Andre Przywara 写到:
>The Allwinner H6 pin controller is not really special, at least not
>when
>it comes to normal GPIO operation.
>
>Add the H6 compatible strings to the list of recognised strings, to
>make
>GPIOs work for H6 boards.
>
>Signed-off-by: Andre Przywara
>---
> drivers/gpio/sunxi_gpio.c | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
>index cbed8d42b7..780c39962a 100644
>--- a/drivers/gpio/sunxi_gpio.c
>+++ b/drivers/gpio/sunxi_gpio.c
>@@ -354,12 +354,14 @@ static const struct udevice_id sunxi_gpio_ids[] =
>{
> ID("allwinner,sun8i-v3s-pinctrl", a_all),
> ID("allwinner,sun9i-a80-pinctrl", a_all),
> ID("allwinner,sun50i-a64-pinctrl", a_all),
>+ ID("allwinner,sun50i-h6-pinctrl", a_all),
> ID("allwinner,sun6i-a31-r-pinctrl", l_2),
> ID("allwinner,sun8i-a23-r-pinctrl", l_1),
> ID("allwinner,sun8i-a83t-r-pinctrl",l_1),
> ID("allwinner,sun8i-h3-r-pinctrl", l_1),
> ID("allwinner,sun9i-a80-r-pinctrl", l_3),
> ID("allwinner,sun50i-a64-r-pinctrl",l_1),
>+ ID("allwinner,sun50i-h6-r-pinctrl", l_1),
Should be l_2 because H6 has PM bank.
> { }
> };
>
--
使用 K-9 Mail 发送自我的Android设备。
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/6] sunxi: H6: Enable USB for existing boards
So far USB was not enabled for the Allwinner H6 boards, as the PHY driver was not ready and the clock gates were missing. Since this is now fixed, let's add the PHY and the OHCI/EHCI drivers to the build, for all existing H6 boards. Signed-off-by: Andre Przywara --- arch/arm/mach-sunxi/Kconfig | 1 + configs/beelink_gs1_defconfig | 2 ++ configs/orangepi_lite2_defconfig| 2 ++ configs/orangepi_one_plus_defconfig | 2 ++ configs/pine_h64_defconfig | 3 +++ 5 files changed, 10 insertions(+) diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index 1669e62a6d..ad29139545 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -300,6 +300,7 @@ config MACH_SUN50I_H6 select ARM64 select SUPPORT_SPL select FIT + select PHY_SUN4I_USB select SPL_LOAD_FIT select DRAM_SUN50I_H6 diff --git a/configs/beelink_gs1_defconfig b/configs/beelink_gs1_defconfig index ef4dd29549..5c0f294688 100644 --- a/configs/beelink_gs1_defconfig +++ b/configs/beelink_gs1_defconfig @@ -13,3 +13,5 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_DEFAULT_DEVICE_TREE="sun50i-h6-beelink-gs1" CONFIG_LED=y CONFIG_LED_GPIO=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y diff --git a/configs/orangepi_lite2_defconfig b/configs/orangepi_lite2_defconfig index e5c2846eaa..227e1ac873 100644 --- a/configs/orangepi_lite2_defconfig +++ b/configs/orangepi_lite2_defconfig @@ -11,3 +11,5 @@ CONFIG_SPL_TEXT_BASE=0x20060 # CONFIG_SPL_DOS_PARTITION is not set # CONFIG_SPL_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="sun50i-h6-orangepi-lite2" +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y diff --git a/configs/orangepi_one_plus_defconfig b/configs/orangepi_one_plus_defconfig index 65537c422f..2e45909e3a 100644 --- a/configs/orangepi_one_plus_defconfig +++ b/configs/orangepi_one_plus_defconfig @@ -11,3 +11,5 @@ CONFIG_SPL_TEXT_BASE=0x20060 # CONFIG_SPL_DOS_PARTITION is not set # CONFIG_SPL_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="sun50i-h6-orangepi-one-plus" +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y diff --git a/configs/pine_h64_defconfig b/configs/pine_h64_defconfig index 5ac89b462c..0c5e47bbf7 100644 --- a/configs/pine_h64_defconfig +++ b/configs/pine_h64_defconfig @@ -12,3 +12,6 @@ CONFIG_SPL_TEXT_BASE=0x20060 # CONFIG_SPL_DOS_PARTITION is not set # CONFIG_SPL_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="sun50i-h6-pine-h64" +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB3_VBUS_PIN="PL5" -- 2.14.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/6] sunxi: Pine64: DTS: enable USB PHY 0 for HCI0
The first USB controller on the H6 SoC shares a PHY with the OTG
controller. Reportedly to avoid problems with the VBUS regulator under
Linux, we don't link OHCI0/EHCI0 to the USB PHY in the H6 .dtsi file.
However on boards which can't use peripheral mode (because they have an
always-on VBUS supply on an USB-A socket) we don't need this trick, and
can properly connect host controller 0 to the PHY 0.
Amend the Pine H64 .dts to reflect this. This enables the upper USB port
in U-Boot on this board.
Signed-off-by: Andre Przywara
---
arch/arm/dts/sun50i-h6-pine-h64.dts | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/sun50i-h6-pine-h64.dts
b/arch/arm/dts/sun50i-h6-pine-h64.dts
index 4802902e12..aad7646b18 100644
--- a/arch/arm/dts/sun50i-h6-pine-h64.dts
+++ b/arch/arm/dts/sun50i-h6-pine-h64.dts
@@ -96,6 +96,8 @@
};
&ehci0 {
+ phys = <&usb2phy 0>;
+ phy-names = "usb";
status = "okay";
};
@@ -120,6 +122,8 @@
};
&ohci0 {
+ phys = <&usb2phy 0>;
+ phy-names = "usb";
status = "okay";
};
@@ -255,7 +259,6 @@
&usb2otg {
dr_mode = "host";
- status = "okay";
};
&usb2phy {
--
2.14.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/6] sunxi: phy: Add USB PHY support for Allwinner H6
The USB PHY used in the Allwinner H6 SoC has some pecularities (as usual),
which require a small addition to the USB PHY driver:
In this case the second PHY is PHY3, not PHY1, so we need to skip number
1 and 2 in the code. Just use the respective code from Linux for that.
Signed-off-by: Andre Przywara
---
drivers/phy/allwinner/phy-sun4i-usb.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
b/drivers/phy/allwinner/phy-sun4i-usb.c
index f206fa3f5d..5e8f87717f 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -75,6 +75,7 @@ enum sun4i_usb_phy_type {
sun8i_h3_phy,
sun8i_v3s_phy,
sun50i_a64_phy,
+ sun50i_h6_phy,
};
struct sun4i_usb_phy_cfg {
@@ -85,6 +86,7 @@ struct sun4i_usb_phy_cfg {
bool dedicated_clocks;
bool enable_pmu_unk1;
bool phy0_dual_route;
+ int missing_phys;
};
struct sun4i_usb_phy_info {
@@ -349,6 +351,9 @@ static int sun4i_usb_phy_xlate(struct phy *phy,
if (args->args_count >= data->cfg->num_phys)
return -EINVAL;
+ if (data->cfg->missing_phys & BIT(args->args[0]))
+ return -ENODEV;
+
if (args->args_count)
phy->id = args->args[0];
else
@@ -429,6 +434,9 @@ static int sun4i_usb_phy_probe(struct udevice *dev)
struct sun4i_usb_phy_info *info = &phy_info[i];
char name[16];
+ if (data->cfg->missing_phys & BIT(i))
+ continue;
+
phy->gpio_vbus = sunxi_name_to_gpio(info->gpio_vbus);
if (phy->gpio_vbus >= 0) {
ret = gpio_request(phy->gpio_vbus, "usb_vbus");
@@ -583,6 +591,17 @@ static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
.phy0_dual_route = true,
};
+static const struct sun4i_usb_phy_cfg sun50i_h6_cfg = {
+ .num_phys = 4,
+ .type = sun50i_h6_phy,
+ .disc_thresh = 3,
+ .phyctl_offset = REG_PHYCTL_A33,
+ .dedicated_clocks = true,
+ .enable_pmu_unk1 = true,
+ .phy0_dual_route = true,
+ .missing_phys = BIT(1) | BIT(2),
+};
+
static const struct udevice_id sun4i_usb_phy_ids[] = {
{ .compatible = "allwinner,sun4i-a10-usb-phy", .data =
(ulong)&sun4i_a10_cfg },
{ .compatible = "allwinner,sun5i-a13-usb-phy", .data =
(ulong)&sun5i_a13_cfg },
@@ -594,6 +613,7 @@ static const struct udevice_id sun4i_usb_phy_ids[] = {
{ .compatible = "allwinner,sun8i-h3-usb-phy", .data =
(ulong)&sun8i_h3_cfg },
{ .compatible = "allwinner,sun8i-v3s-usb-phy", .data =
(ulong)&sun8i_v3s_cfg },
{ .compatible = "allwinner,sun50i-a64-usb-phy", .data =
(ulong)&sun50i_a64_cfg},
+ { .compatible = "allwinner,sun50i-h6-usb-phy", .data =
(ulong)&sun50i_h6_cfg},
{ }
};
--
2.14.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/6] sunxi: gpio: Enable support for H6 pin controller
The Allwinner H6 pin controller is not really special, at least not when
it comes to normal GPIO operation.
Add the H6 compatible strings to the list of recognised strings, to make
GPIOs work for H6 boards.
Signed-off-by: Andre Przywara
---
drivers/gpio/sunxi_gpio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index cbed8d42b7..780c39962a 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -354,12 +354,14 @@ static const struct udevice_id sunxi_gpio_ids[] = {
ID("allwinner,sun8i-v3s-pinctrl", a_all),
ID("allwinner,sun9i-a80-pinctrl", a_all),
ID("allwinner,sun50i-a64-pinctrl", a_all),
+ ID("allwinner,sun50i-h6-pinctrl", a_all),
ID("allwinner,sun6i-a31-r-pinctrl", l_2),
ID("allwinner,sun8i-a23-r-pinctrl", l_1),
ID("allwinner,sun8i-a83t-r-pinctrl",l_1),
ID("allwinner,sun8i-h3-r-pinctrl", l_1),
ID("allwinner,sun9i-a80-r-pinctrl", l_3),
ID("allwinner,sun50i-a64-r-pinctrl",l_1),
+ ID("allwinner,sun50i-h6-r-pinctrl", l_1),
{ }
};
--
2.14.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/6] sunxi: clocks: Add H6 USB clock gates and resets
To enable USB support in U-Boot, add the required clock and reset gates
to the H6 clock driver. Once enabled, the generic EHCI/OCHI drivers will
pick them up from there automatically.
Signed-off-by: Andre Przywara
---
drivers/clk/sunxi/clk_h6.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/clk/sunxi/clk_h6.c b/drivers/clk/sunxi/clk_h6.c
index 0bb00f449a..105c15d869 100644
--- a/drivers/clk/sunxi/clk_h6.c
+++ b/drivers/clk/sunxi/clk_h6.c
@@ -28,6 +28,22 @@ static struct ccu_clk_gate h6_gates[] = {
[CLK_BUS_SPI1] = GATE(0x96c, BIT(1)),
[CLK_BUS_EMAC] = GATE(0x97c, BIT(0)),
+
+ [CLK_USB_PHY0] = GATE(0xa70, BIT(29)),
+ [CLK_USB_OHCI0] = GATE(0xa70, BIT(31)),
+
+ [CLK_USB_PHY1] = GATE(0xa74, BIT(29)),
+
+ [CLK_USB_HSIC] = GATE(0xa7c, BIT(26)),
+ [CLK_USB_HSIC_12M] = GATE(0xa7c, BIT(27)),
+ [CLK_USB_PHY3] = GATE(0xa7c, BIT(29)),
+ [CLK_USB_OHCI3] = GATE(0xa7c, BIT(31)),
+
+ [CLK_BUS_OHCI0] = GATE(0xa8c, BIT(0)),
+ [CLK_BUS_OHCI3] = GATE(0xa8c, BIT(3)),
+ [CLK_BUS_EHCI0] = GATE(0xa8c, BIT(4)),
+ [CLK_BUS_EHCI3] = GATE(0xa8c, BIT(7)),
+ [CLK_BUS_OTG] = GATE(0xa8c, BIT(8)),
};
static struct ccu_reset h6_resets[] = {
@@ -43,6 +59,19 @@ static struct ccu_reset h6_resets[] = {
[RST_BUS_SPI1] = RESET(0x96c, BIT(17)),
[RST_BUS_EMAC] = RESET(0x97c, BIT(16)),
+
+ [RST_USB_PHY0] = RESET(0xa70, BIT(30)),
+
+ [RST_USB_PHY1] = RESET(0xa74, BIT(30)),
+
+ [RST_USB_HSIC] = RESET(0xa7c, BIT(28)),
+ [RST_USB_PHY3] = RESET(0xa7c, BIT(30)),
+
+ [RST_BUS_OHCI0] = RESET(0xa8c, BIT(16)),
+ [RST_BUS_OHCI3] = RESET(0xa8c, BIT(19)),
+ [RST_BUS_EHCI0] = RESET(0xa8c, BIT(20)),
+ [RST_BUS_EHCI3] = RESET(0xa8c, BIT(23)),
+ [RST_BUS_OTG] = RESET(0xa8c, BIT(24)),
};
static const struct ccu_desc h6_ccu_desc = {
--
2.14.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/6] sunxi: move SUNXI_GPIO to Kconfig
Probably for no particular reason SUNXI_GPIO was still defined the "old way", in header files only. Introduce SUNXI_GPIO to the Kconfig file in drivers/gpio to remove another line from our dreadful config_whitelist.txt. Signed-off-by: Andre Przywara --- arch/arm/Kconfig | 1 + drivers/gpio/Kconfig | 6 ++ include/configs/sunxi-common.h | 3 --- scripts/config_whitelist.txt | 1 - 4 files changed, 7 insertions(+), 4 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3c4af1f299..25af3c0553 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -900,6 +900,7 @@ config ARCH_SUNXI select SPL_STACK_R if SPL select SPL_SYS_MALLOC_SIMPLE if SPL select SPL_SYS_THUMB_BUILD if !ARM64 + select SUNXI_GPIO select SYS_NS16550 select SYS_THUMB_BUILD if !ARM64 select USB if DISTRO_DEFAULTS diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index e36a8abc42..5a4d7c553e 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -205,6 +205,12 @@ config SANDBOX_GPIO_COUNT of 'anonymous' GPIOs that do not belong to any device or bank. Select a suitable value depending on your needs. +config SUNXI_GPIO + bool "Allwinner GPIO driver" + depends on ARCH_SUNXI + help + Support the GPIO device in Allwinner SoCs. + config XILINX_GPIO bool "Xilinx GPIO driver" depends on DM_GPIO diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index fceb812448..7be94ee7d1 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -257,9 +257,6 @@ extern int soft_i2c_gpio_scl; #endif #endif /* ifdef CONFIG_REQUIRE_SERIAL_CONSOLE */ -/* GPIO */ -#define CONFIG_SUNXI_GPIO - #ifdef CONFIG_VIDEO_SUNXI /* * The amount of RAM to keep free at the top of RAM when relocating u-boot, diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index b16bc6ae34..219e2aae4d 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -1924,7 +1924,6 @@ CONFIG_STV0991 CONFIG_STV0991_HZ CONFIG_STV0991_HZ_CLOCK CONFIG_ST_SMI -CONFIG_SUNXI_GPIO CONFIG_SUNXI_MAX_FB_SIZE CONFIG_SUPERH_ON_CHIP_R8A66597 CONFIG_SUVD3 -- 2.14.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/6] sunxi: H6: Enable USB (2.0) support
Hi, this series enables USB support on the H6 boards. This is mostly just adding some missing pieces here and there, the actual controller and PHY are very similar to the previous ones, if not identical. This is for the 2.0 ports only at the moment, USB 3.0 will be done later (started porting Icenowy's Linux driver). The Pine H64 shares a similar problem as the Pine64+ boards regarding the upper USB port. To enable this port, we need the first patch from the series [1] fixing this issue on the A64 boards. Patch 1 is a drive-by patch to bring SUNXI_GPIO to Kconfig, as this was lingering in one of my branches for a while. Patch 2 enables GPIO support for the H6, as this is needed for the Pine H64 to enable the VBUS regulator. Patch 3 adds the clock and reset gates mappings for the USB controller and the PHY, the values are taken from the manual and verified against Linux. Patch 4 adds some code to the PHY driver to skip over not implemented PHYs, as the H6 uses a PHY0/PHY3 combination in the DT. Patch 5 then eventually enables USB in the existing defconfigs. Patch 6 adds the .dts fixes required to get the upper USB port to work on the Pine H64. Clément, can you please verify that this works for the Beelink box? I guess the USB 2.0 port is probably the OTG one, so this setup would look somewhat similar to the PineH64, which would allow you to copy the USB DT nodes from there. Cheers, Andre. [1] https://lists.denx.de/pipermail/u-boot/2019-May/369520.html Andre Przywara (6): sunxi: move SUNXI_GPIO to Kconfig sunxi: gpio: Enable support for H6 pin controller sunxi: clocks: Add H6 USB clock gates and resets sunxi: phy: Add USB PHY support for Allwinner H6 sunxi: H6: Enable USB for existing boards sunxi: Pine64: DTS: enable USB PHY 0 for HCI0 arch/arm/Kconfig | 1 + arch/arm/dts/sun50i-h6-pine-h64.dts | 5 - arch/arm/mach-sunxi/Kconfig | 1 + configs/beelink_gs1_defconfig | 2 ++ configs/orangepi_lite2_defconfig | 2 ++ configs/orangepi_one_plus_defconfig | 2 ++ configs/pine_h64_defconfig| 3 +++ drivers/clk/sunxi/clk_h6.c| 29 + drivers/gpio/Kconfig | 6 ++ drivers/gpio/sunxi_gpio.c | 2 ++ drivers/phy/allwinner/phy-sun4i-usb.c | 20 include/configs/sunxi-common.h| 3 --- scripts/config_whitelist.txt | 1 - 13 files changed, 72 insertions(+), 5 deletions(-) -- 2.14.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] sunxi: Pine64: DTS: enable USB PHY 0 for HCI0
The first USB controller on the A64 SoC shares a PHY with the OTG
controller. Reportedly to avoid problems with the VBUS regulator under
Linux, we don't link OHCI0/EHCI0 to the USB PHY in the A64 .dtsi file.
However on boards which can't use peripheral mode (because they have an
always-on VBUS supply on an USB-A socket) we don't need this trick, and
can properly connect host controller 0 to the PHY 0.
Amend the Pine64 and SoPine/LTS .dts to reflect this. This enables the
upper USB port in U-Boot on those boards.
Signed-off-by: Andre Przywara
---
arch/arm/dts/sun50i-a64-pine64.dts | 5 -
arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/sun50i-a64-pine64.dts
b/arch/arm/dts/sun50i-a64-pine64.dts
index c077b6c1f4..523a4d5bff 100644
--- a/arch/arm/dts/sun50i-a64-pine64.dts
+++ b/arch/arm/dts/sun50i-a64-pine64.dts
@@ -80,6 +80,8 @@
};
&ehci0 {
+ phys = <&usbphy 0>;
+ phy-names = "usb";
status = "okay";
};
@@ -136,6 +138,8 @@
};
&ohci0 {
+ phys = <&usbphy 0>;
+ phy-names = "usb";
status = "okay";
};
@@ -301,7 +305,6 @@
&usb_otg {
dr_mode = "host";
- status = "okay";
};
&usbphy {
diff --git a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts
b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts
index 53fcc9098d..1986897177 100644
--- a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts
+++ b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts
@@ -85,6 +85,8 @@
};
&ehci0 {
+ phys = <&usbphy 0>;
+ phy-names = "usb";
status = "okay";
};
@@ -131,6 +133,8 @@
};
&ohci0 {
+ phys = <&usbphy 0>;
+ phy-names = "usb";
status = "okay";
};
@@ -172,7 +176,6 @@
&usb_otg {
dr_mode = "host";
- status = "okay";
};
&usbphy {
--
2.14.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] sunxi: USB PHY: Support shared PHY 0
The Allwinner H3, H5, H6 and A64 SoCs share USB PHY 0 between the first
HCI controller (OHCI0/EHCI0) and the MUSB OTG controller. Bit 0 in
PHY register 0x20 selects with of the controllers is connected to the
PHY. So far we were hardwiring this bit to 0, so that the OTG controller
controls the pins.
As the A64 has only two sets of USB pins, some boards like the Pine64
connect two USB-A sockets to them, to give more host ports. In this case
we would like HCI0 to control the pins. For those boards we typically
don't even enable the MUSB OTG controller in the config.
Depending on whether the OTG controller is configured or not, switch
PHY0 to either EHCI0/OHCI0 or the OTG controller.
This enables the upper USB port on the Pine64 (and other) boards. This
proves to be very useful when people want to connect both an USB
keyboard and a flash drive, for instance to install a Linux
distribution.
Signed-off-by: Andre Przywara
---
drivers/phy/allwinner/phy-sun4i-usb.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
b/drivers/phy/allwinner/phy-sun4i-usb.c
index f206fa3f5d..de1065fce6 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -240,6 +240,11 @@ static int sun4i_usb_phy_power_off(struct phy *phy)
return 0;
}
+#ifdef CONFIG_USB_MUSB_SUNXI
+#define REROUTE_TARGET true
+#else
+#define REROUTE_TARGET false
+#endif
static void sun4i_usb_phy0_reroute(struct sun4i_usb_phy_data *data, bool
id_det)
{
u32 regval;
@@ -304,7 +309,8 @@ static int sun4i_usb_phy_init(struct phy *phy)
sun4i_usb_phy_passby(phy, true);
- sun4i_usb_phy0_reroute(data, true);
+ if (data->cfg->phy0_dual_route)
+ sun4i_usb_phy0_reroute(data, REROUTE_TARGET);
return 0;
}
--
2.14.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] sunxi: A64: enable first USB port on Pine64 boards
Since the beginning the upper USB port on Pine64 boards (Pine64+, SoPine baseboard, Pine64-LTS, Pinebook) was not working under U-Boot. This is due to the PHY for those pins being shared with the OTG controller, which we didn't even enable for those boards. Also the PHY code was always connecting the port pins to the OTG controller. These two patches fix this, so the upper USB port on said boards can be used within U-Boot. This allows to use an USB keyboard alongside an USB flash drive, for instance to install operating systems using UEFI. Cheers, Andre. Andre Przywara (2): sunxi: USB PHY: Support shared PHY 0 sunxi: Pine64: DTS: enable USB PHY 0 for HCI0 arch/arm/dts/sun50i-a64-pine64.dts | 5 - arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 5 - drivers/phy/allwinner/phy-sun4i-usb.c| 8 +++- 3 files changed, 15 insertions(+), 3 deletions(-) -- 2.14.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-socfpga/master
SoCFPGA DT and reset cleanup, AE MCVEVK board support. The following changes since commit 90176e3be63802bc8630bab651d169993f0f0763: Merge tag 'efi-2019-07-rc3' of git://git.denx.de/u-boot-efi (2019-05-13 07:13:28 -0400) are available in the Git repository at: git://git.denx.de/u-boot-socfpga.git master for you to fetch changes up to 9e6ed1a3466ea35d98e074187abcbcfee550b448: ARM: dts: socfpga: Keep FPGA bridge entries in SPL DT (2019-05-14 19:53:16 +0200) Marek Vasut (2): ARM: dts: socfpga: Factor out U-Boot specifics from A10 handoff files ARM: dts: socfpga: Keep FPGA bridge entries in SPL DT Simon Goldschmidt (2): arm: socfpga: remove re-added ad-hoc reset code arm: sofcpga: s10: remove unused ad-hoc reset code Wolfgang Grandegger (1): arm: socfpga: Re-add support for Aries MCV SoM and MCVEV[KP] board arch/arm/dts/Makefile | 1 + arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi| 91 ++ arch/arm/dts/socfpga_arria10_socdk.dtsi | 3 +- arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts| 2 + arch/arm/dts/socfpga_arria10_socdk_sdmmc_handoff.dtsi | 17 arch/arm/dts/socfpga_cyclone5_mcv.dtsi | 22 + arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi| 34 +++ arch/arm/dts/socfpga_cyclone5_mcvevk.dts| 81 arch/arm/mach-socfpga/Kconfig | 7 ++ arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h | 1 - arch/arm/mach-socfpga/include/mach/reset_manager_s10.h | 1 - arch/arm/mach-socfpga/reset_manager_gen5.c | 8 -- arch/arm/mach-socfpga/reset_manager_s10.c | 11 --- arch/arm/mach-socfpga/spl_gen5.c| 3 +- board/aries/mcvevk/MAINTAINERS | 9 ++ board/aries/mcvevk/Makefile | 7 ++ board/aries/mcvevk/qts/iocsr_config.h | 659 +++ board/aries/mcvevk/qts/pinmux_config.h | 218 board/aries/mcvevk/qts/pll_config.h | 84 + board/aries/mcvevk/qts/sdram_config.h | 343 board/aries/mcvevk/socfpga.c| 5 + configs/socfpga_mcvevk_defconfig| 59 include/configs/socfpga_mcvevk.h| 103 + 23 files changed, 1728 insertions(+), 41 deletions(-) create mode 100644 arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_cyclone5_mcv.dtsi create mode 100644 arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_cyclone5_mcvevk.dts create mode 100644 board/aries/mcvevk/MAINTAINERS create mode 100644 board/aries/mcvevk/Makefile create mode 100644 board/aries/mcvevk/qts/iocsr_config.h create mode 100644 board/aries/mcvevk/qts/pinmux_config.h create mode 100644 board/aries/mcvevk/qts/pll_config.h create mode 100644 board/aries/mcvevk/qts/sdram_config.h create mode 100644 board/aries/mcvevk/socfpga.c create mode 100644 configs/socfpga_mcvevk_defconfig create mode 100644 include/configs/socfpga_mcvevk.h ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-sh/master
Align env position on GR-Peach with downstream U-Boot. The following changes since commit 90176e3be63802bc8630bab651d169993f0f0763: Merge tag 'efi-2019-07-rc3' of git://git.denx.de/u-boot-efi (2019-05-13 07:13:28 -0400) are available in the Git repository at: git://git.denx.de/u-boot-sh.git master for you to fetch changes up to 851224460f9ae673a9a9a3a57a573ad636d1301b: ARM: renesas: grpeach: Align env position (2019-05-14 19:52:04 +0200) Marek Vasut (1): ARM: renesas: grpeach: Align env position include/configs/grpeach.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 2/2] fit: Support compat string property in configuration node
This patch adds support for an optional optimization to compatible
string matching where the compatible string property from the root node
of the kernel FDT can be copied into the configuration node of the FIT
image. This is most useful when using compressed FDTs or when using FDT
overlays, where the traditional extraction of the compatible string from
the kernel FDT itself is not easily possible.
Signed-off-by: Julius Werner
---
- No changes for v2
- No changes for v3
- Changes for v4:
- Added documentation for compatible string in config node.
- Added example .its file for compressed FDT with compat string in
config node.
common/image-fit.c| 67 -
doc/uImage.FIT/kernel_fdts_compressed.its | 73 +++
doc/uImage.FIT/source_file_format.txt | 7 +++
3 files changed, 119 insertions(+), 28 deletions(-)
create mode 100644 doc/uImage.FIT/kernel_fdts_compressed.its
diff --git a/common/image-fit.c b/common/image-fit.c
index 469c5c8f49..d32add6419 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1522,6 +1522,10 @@ int fit_check_format(const void *fit)
* compatible list, "foo,bar", matches a compatible string in the root of fdt1.
* "bim,bam" in fdt2 matches the second string which isn't as good as fdt1.
*
+ * As an optimization, the compatible property from the FDT's root node can be
+ * copied into the configuration node in the FIT image. This is required to
+ * match configurations with compressed FDTs.
+ *
* returns:
* offset to the configuration to use if one was found
* -1 otherwise
@@ -1554,55 +1558,62 @@ int fit_conf_find_compat(const void *fit, const void
*fdt)
for (noffset = fdt_next_node(fit, confs_noffset, &ndepth);
(noffset >= 0) && (ndepth > 0);
noffset = fdt_next_node(fit, noffset, &ndepth)) {
- const void *kfdt;
+ const void *fdt;
const char *kfdt_name;
- int kfdt_noffset;
+ int kfdt_noffset, compat_noffset;
const char *cur_fdt_compat;
int len;
- size_t size;
+ size_t sz;
int i;
if (ndepth > 1)
continue;
- kfdt_name = fdt_getprop(fit, noffset, "fdt", &len);
- if (!kfdt_name) {
- debug("No fdt property found.\n");
- continue;
- }
- kfdt_noffset = fdt_subnode_offset(fit, images_noffset,
- kfdt_name);
- if (kfdt_noffset < 0) {
- debug("No image node named \"%s\" found.\n",
- kfdt_name);
- continue;
- }
+ /* If there's a compat property in the config node, use that. */
+ if (fdt_getprop(fit, noffset, "compatible", NULL)) {
+ fdt = fit;/* search in FIT image */
+ compat_noffset = noffset; /* search under config node */
+ } else {/* Otherwise extract it from the kernel FDT. */
+ kfdt_name = fdt_getprop(fit, noffset, "fdt", &len);
+ if (!kfdt_name) {
+ debug("No fdt property found.\n");
+ continue;
+ }
+ kfdt_noffset = fdt_subnode_offset(fit, images_noffset,
+ kfdt_name);
+ if (kfdt_noffset < 0) {
+ debug("No image node named \"%s\" found.\n",
+ kfdt_name);
+ continue;
+ }
- if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) {
- debug("Can't extract compat from \"%s\" (compressed)\n",
- kfdt_name);
- continue;
- }
+ if (!fit_image_check_comp(fit, kfdt_noffset,
+ IH_COMP_NONE)) {
+ debug("Can't extract compat from \"%s\" "
+ "(compressed)\n", kfdt_name);
+ continue;
+ }
- /*
-* Get a pointer to this configuration's fdt.
-*/
- if (fit_image_get_data(fit, kfdt_noffset, &kfdt, &size)) {
- debug("Failed to get fdt \"%s\".\n", kfdt_name);
- continue;
+ /* search in this config's kernel FDT */
+ if (fit_image_get_data(fit, kfdt_noffset, &fdt, &sz)) {
+ debug("Failed to get fdt \"%s\".\n", kfdt_n
[U-Boot] [PATCH v4 0/2] fit: Image node compression
This patch series adds compression support for non-kernel FIT image nodes (e.g. FDTs). The first patch adds the compression support itself, the second adds a new feature to compatible string matching that allows it to be useful with compressed FDTs. Sandbox-tested with FIT images with and without compressed FDTs, with and without overlays, in both compatible string matching and direct config selection modes. Also expanded the test_fit pytest to include a case with compressed kernel, FDT and ramdisk. Julius Werner (2): fit: Support compression for non-kernel components (e.g. FDT) - Changes for v2: - Changed from only supporting compressed FDTs to supporting all non-kernel image node types. - Changes for v3: - Fixed up some debug output that was still written for v1. - Fixed a mistake with handling FIT_LOAD_OPTIONAL_NON_ZERO when 'load' was 0 (i.e. unset). - Added compression test case to the test_fit pytest. - No changes for v4 fit: Support compat string property in configuration node - No changes for v2 - No changes for v3 - Changes for v4: - Added documentation for compatible string in config node. - Added example .its file for compressed FDT with compat string in config node. common/image-fit.c | 140 +++-- 1 file changed, 83 insertions(+), 57 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/2] fit: Support compression for non-kernel components (e.g. FDT)
This patch adds support for compressing non-kernel image nodes in a FIT
image (kernel nodes could already be compressed previously). This can
reduce the size of FIT images and therefore improve boot times
(especially when an image bundles many different kernel FDTs). The
images will automatically be decompressed on load.
This patch does not support extracting compatible strings from
compressed FDTs, so it's not very helpful in conjunction with
CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
that select the configuration to load explicitly.
Signed-off-by: Julius Werner
---
- Changes for v2:
- Changed from only supporting compressed FDTs to supporting all
non-kernel image node types.
- Changes for v3:
- Fixed up some debug output that was still written for v1.
- Fixed a mistake with handling FIT_LOAD_OPTIONAL_NON_ZERO when
'load' was 0 (i.e. unset).
- Added compression test case to the test_fit pytest.
- No changes for v4
common/image-fit.c| 86 +++
test/py/tests/test_fit.py | 29 +++--
2 files changed, 77 insertions(+), 38 deletions(-)
diff --git a/common/image-fit.c b/common/image-fit.c
index ac901e131c..469c5c8f49 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -22,6 +22,7 @@
DECLARE_GLOBAL_DATA_PTR;
#endif /* !USE_HOSTCC*/
+#include
#include
#include
#include
@@ -1576,6 +1577,13 @@ int fit_conf_find_compat(const void *fit, const void
*fdt)
kfdt_name);
continue;
}
+
+ if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) {
+ debug("Can't extract compat from \"%s\" (compressed)\n",
+ kfdt_name);
+ continue;
+ }
+
/*
* Get a pointer to this configuration's fdt.
*/
@@ -1795,11 +1803,12 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
const char *fit_uname_config;
const char *fit_base_uname_config;
const void *fit;
- const void *buf;
+ void *buf;
+ void *loadbuf;
size_t size;
int type_ok, os_ok;
- ulong load, data, len;
- uint8_t os;
+ ulong load, load_end, data, len;
+ uint8_t os, comp;
#ifndef USE_HOSTCC
uint8_t os_arch;
#endif
@@ -1895,12 +1904,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
images->os.arch = os_arch;
#endif
- if (image_type == IH_TYPE_FLATDT &&
- !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) {
- puts("FDT image is compressed");
- return -EPROTONOSUPPORT;
- }
-
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL);
type_ok = fit_image_check_type(fit, noffset, image_type) ||
fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) ||
@@ -1931,7 +1934,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL_OK);
/* get image data address and length */
- if (fit_image_get_data_and_size(fit, noffset, &buf, &size)) {
+ if (fit_image_get_data_and_size(fit, noffset,
+ (const void **)&buf, &size)) {
printf("Could not find %s subimage data!\n", prop_name);
bootstage_error(bootstage_id + BOOTSTAGE_SUB_GET_DATA);
return -ENOENT;
@@ -1939,30 +1943,15 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
#if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS)
/* perform any post-processing on the image data */
- board_fit_image_post_process((void **)&buf, &size);
+ board_fit_image_post_process(&buf, &size);
#endif
len = (ulong)size;
- /* verify that image data is a proper FDT blob */
- if (image_type == IH_TYPE_FLATDT && fdt_check_header(buf)) {
- puts("Subimage data is not a FDT");
- return -ENOEXEC;
- }
-
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_GET_DATA_OK);
- /*
-* Work-around for eldk-4.2 which gives this warning if we try to
-* cast in the unmap_sysmem() call:
-* warning: initialization discards qualifiers from pointer target type
-*/
- {
- void *vbuf = (void *)buf;
-
- data = map_to_sysmem(vbuf);
- }
-
+ data = map_to_sysmem(buf);
+ load = data;
if (load_op == FIT_LOAD_IGNORED) {
/* Don't load */
} else if (fit_image_get_load(fit, noffset, &load)) {
@@ -1974,8 +1963,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
}
} else if (load_op != FIT_LOAD_OPTIONAL_NON_ZERO || load) {
ulong image_start, image_end;
- ulong load_end;
- void *dst;
/*
Re: [U-Boot] [PATCH v3 1/2] fit: Support compression for non-kernel components (e.g. FDT)
Like Simon (Goldschmidt) said, the current documentation for the "compression" property in image nodes already matches this, so I don't think I need to add anything there. I'll update the other patch to add documentation for compatible strings in config nodes, and then upload an .its example for compressed FDTs there (because the example makes more sense when using both features together). On Tue, May 14, 2019 at 8:11 PM Simon Glass wrote: > > Hi Simon, > > On Tue, 14 May 2019 at 05:16, Simon Goldschmidt > wrote: > > > > On Tue, May 14, 2019 at 12:55 PM Simon Glass wrote: > > > > > > Hi Julius, > > > > > > On Mon, 13 May 2019 at 19:13, Julius Werner wrote: > > > > > > > > > Is there a change log for this patch?I think we discussed having a > > > > > test. > > > > > > > > Sorry, forgot that. Is it okay if I just put it here or do you need me > > > > to resend a v4? > > > > > > I think it should be a v4 so it looks right in patchwork. > > > > > > Also for this patch, can you please add documentation - see > > > source_file_format.txt > > > > I had submitted a patch for that file already last year but then got > > stuck in implementing just this, see commit fd15a9e2565f here: > > https://github.com/u-boot/u-boot/commit/fd15a9e2565f831bf95c2152d1966d068a642175#diff-8c4b5e332d50ba25248fd06d6b4eb026 > > > > I don't know if this compression support needs anything more > > specific in that doc file. If anything, we could explicitly state that > > compression is now supported for all nodes, but then again, the > > file didn't tell that it was only supported for Kernels... > > Now that gmail is fixed I can reply more easily... > > Fair enough. > > Compression for a DT node is a pain, since it must be decompressed > before being accessed and even reading the compatible string is hard. > This is the purpose of one of Julius' patches. > > The DT format is fairly well documented and I would like to keep it > that way, as well as extend the tests as we add new functions. > > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework
On Wed, May 15, 2019 at 04:39:22PM -0500, Andreas Dannenberg wrote: > Hi Tom, > > On Wed, May 15, 2019 at 11:17:22AM -0400, Tom Rini wrote: > > On Tue, May 07, 2019 at 12:25:33PM -0500, Andreas Dannenberg wrote: > > > > > Introduce a framework that allows loading the System Firmware (SYSFW) > > > binary as well as the associated configuration data from an image tree > > > blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC > > > RAW mode partition or sector. > > > > > > To simplify the handling of and loading from the different boot media > > > we tap into the existing U-Boot SPL framework usually used for loading > > > U-Boot by building on an earlier commit that exposes some of that > > > functionality. > > > > > > Note that this initial implementation only supports FS and RAW-based > > > eMMC/SD card boot. > > [snip] > > > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig > > > index e677a2e01b..f1731dda58 100644 > > > --- a/arch/arm/mach-k3/Kconfig > > > +++ b/arch/arm/mach-k3/Kconfig > > > @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID > > > int > > > default 16 > > > > > > +config K3_LOAD_SYSFW > > > + bool > > > + depends on SPL > > > + default n > > > > 'n' is already default, you can drop this. > > Ok sure. > > > > > [snip] > > > +config K3_SYSFW_IMAGE_SIZE_MAX > > > + int "Amount of memory dynamically allocated for loading SYSFW blob" > > > + depends on K3_LOAD_SYSFW > > > + default 269000 > > > + help > > > + Amount of memory reserved through dynamic allocation at runtime for > > > + loading the combined System Firmware and configuration image tree > > > + blob. Keep it as tight as possible, as this directly affects the > > > + overall SPL memory footprint. > > > > This is missing a unit, and is 'int' really the best choice here (and > > really, I guess, 262.6KiB as a default) ? > > Will add a unit. > > As for the specific value, in our R5 SPL memory is very very tight. The > value used here is basically used for a malloc(), and any extra byte > allocated will be "wasted" and not available for stack etc. Also our > SYSFW image that is loaded is fixed size (except some +/-100 odd bytes > if the configuration data is changed that's part of the same SYSFW.ITB > blob), so a rather tailored size makes sense here. Right, that makes sense. But how did you get to that not-exactly-"round" number rather than say 0x41A00 or some other slightly smaller value in hex? If 0x41AC8 is right, then, OK, it's right. It just seems strange at first. > > > [snip] > > > diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile > > > index 0c3a4f7db1..6c895400c2 100644 > > > --- a/arch/arm/mach-k3/Makefile > > > +++ b/arch/arm/mach-k3/Makefile > > > @@ -7,4 +7,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o > > > obj-$(CONFIG_ARM64) += arm64-mmu.o > > > obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o > > > obj-$(CONFIG_TI_SECURE_DEVICE) += security.o > > > +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o > > > obj-y += common.o > > [snip] > > > diff --git a/arch/arm/mach-k3/sysfw-loader.c > > > b/arch/arm/mach-k3/sysfw-loader.c > > > new file mode 100644 > > > index 00..a66c27 > > > --- /dev/null > > > +++ b/arch/arm/mach-k3/sysfw-loader.c > > > @@ -0,0 +1,263 @@ > > [snip] > > > +#ifdef CONFIG_SPL_BUILD > > [snip of the whole body of the file] > > > +#endif > > > > We should be using something else in the Makefile, typically: > > obj-$(CONFIG_SPL_BUILD) += sysfw-loader.o > > should work. > > Well, it won't work like this. We need to make the building of the SYSFW > loader code depending on a CONFIG. This is because for K3 family devices > we build the U-Boot tree into three distinct images [1]: Then you do: ifeq ($(CONFIG_SPL_BUILD),y) obj-$(CONFIG_K3_LOAD_SYSFW) += sysfs-loader.o endif As seen in other places, as we do not whole-body ifdef code. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework
Hi Tom, On Wed, May 15, 2019 at 11:17:22AM -0400, Tom Rini wrote: > On Tue, May 07, 2019 at 12:25:33PM -0500, Andreas Dannenberg wrote: > > > Introduce a framework that allows loading the System Firmware (SYSFW) > > binary as well as the associated configuration data from an image tree > > blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC > > RAW mode partition or sector. > > > > To simplify the handling of and loading from the different boot media > > we tap into the existing U-Boot SPL framework usually used for loading > > U-Boot by building on an earlier commit that exposes some of that > > functionality. > > > > Note that this initial implementation only supports FS and RAW-based > > eMMC/SD card boot. > [snip] > > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig > > index e677a2e01b..f1731dda58 100644 > > --- a/arch/arm/mach-k3/Kconfig > > +++ b/arch/arm/mach-k3/Kconfig > > @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID > > int > > default 16 > > > > +config K3_LOAD_SYSFW > > + bool > > + depends on SPL > > + default n > > 'n' is already default, you can drop this. Ok sure. > > [snip] > > +config K3_SYSFW_IMAGE_SIZE_MAX > > + int "Amount of memory dynamically allocated for loading SYSFW blob" > > + depends on K3_LOAD_SYSFW > > + default 269000 > > + help > > + Amount of memory reserved through dynamic allocation at runtime for > > + loading the combined System Firmware and configuration image tree > > + blob. Keep it as tight as possible, as this directly affects the > > + overall SPL memory footprint. > > This is missing a unit, and is 'int' really the best choice here (and > really, I guess, 262.6KiB as a default) ? Will add a unit. As for the specific value, in our R5 SPL memory is very very tight. The value used here is basically used for a malloc(), and any extra byte allocated will be "wasted" and not available for stack etc. Also our SYSFW image that is loaded is fixed size (except some +/-100 odd bytes if the configuration data is changed that's part of the same SYSFW.ITB blob), so a rather tailored size makes sense here. > [snip] > > diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile > > index 0c3a4f7db1..6c895400c2 100644 > > --- a/arch/arm/mach-k3/Makefile > > +++ b/arch/arm/mach-k3/Makefile > > @@ -7,4 +7,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o > > obj-$(CONFIG_ARM64) += arm64-mmu.o > > obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o > > obj-$(CONFIG_TI_SECURE_DEVICE) += security.o > > +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o > > obj-y += common.o > [snip] > > diff --git a/arch/arm/mach-k3/sysfw-loader.c > > b/arch/arm/mach-k3/sysfw-loader.c > > new file mode 100644 > > index 00..a66c27 > > --- /dev/null > > +++ b/arch/arm/mach-k3/sysfw-loader.c > > @@ -0,0 +1,263 @@ > [snip] > > +#ifdef CONFIG_SPL_BUILD > [snip of the whole body of the file] > > +#endif > > We should be using something else in the Makefile, typically: > obj-$(CONFIG_SPL_BUILD) += sysfw-loader.o > should work. Well, it won't work like this. We need to make the building of the SYSFW loader code depending on a CONFIG. This is because for K3 family devices we build the U-Boot tree into three distinct images [1]: 1) SPL image for running on an R5 (our first stage) 2) SPL image for running on an A53 (our second stage) 3) U-Boot (proper) image for running on an A53 (third stage) With the change you proposed sysfw-loader.o will get build for A53 SPL where it is neither needed nor wanted, causing build failures. What we would need is something like (CONFIG_K3_LOAD_SYSFW && CONFIG_SPL_BUILD) to conditionally build that object if we want to get rid of the #ifdef/#endif in sysfw-loader.c I suppose. Thanks, Andreas [1] https://github.com/u-boot/u-boot/blob/master/board/ti/am65x/README ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: parameter checks simple network protocol
Check buffer pointers are not NULL as required by the UEFI 2.7 spec.
Return EFI_UNSUPPORTED instead of EFI_INVALID_PARAMETER when trying to
transmit with non-zero header_size.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_net.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
index e0e222a70b..d71c663068 100644
--- a/lib/efi_loader/efi_net.c
+++ b/lib/efi_loader/efi_net.c
@@ -392,7 +392,7 @@ static efi_status_t EFIAPI efi_net_transmit
efi_timer_check();
/* Check parameters */
- if (!this) {
+ if (!this || !buffer) {
ret = EFI_INVALID_PARAMETER;
goto out;
}
@@ -408,7 +408,7 @@ static efi_status_t EFIAPI efi_net_transmit
* TODO: We would need to create the header
* if header_size != 0
*/
- ret = EFI_INVALID_PARAMETER;
+ ret = EFI_UNSUPPORTED;
goto out;
}
@@ -466,7 +466,7 @@ static efi_status_t EFIAPI efi_net_receive
efi_timer_check();
/* Check parameters */
- if (!this) {
+ if (!this || !buffer || !buffer_size) {
ret = EFI_INVALID_PARAMETER;
goto out;
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
Hi TF,
On Mon, May 13, 2019 at 01:37:22PM +, Chee, Tien Fong wrote:
> On Wed, 2019-05-08 at 13:43 -0500, dannenb...@ti.com wrote:
> > Hi TF,
> > thanks for chiming in. Comments inlined...
> >
> > On Wed, May 08, 2019 at 04:31:35AM +, Chee, Tien Fong wrote:
> > >
> > > On Tue, 2019-05-07 at 22:00 +0200, Simon Goldschmidt wrote:
> > > >
> > > >
> > > > On 07.05.19 19:25, Andreas Dannenberg wrote:
> > > > >
> > > > >
> > > [...]
> > > >
> > > > >
> > > > >
> > > > > While I also have a working solution based on the existing FS
> > > > > loader
> > > > > framework this has its own challenges, namely by its very
> > > > > nature
> > > > > only
> > > > > addressing a subset of our use cases (no eMMC/SD RAW boot
> > > > > support
> > > > > for
> > > > > example),
> > > IMO, it's actually not that hard to enhance RAW support, i think
> > > minimal changes are required. I have attached the patches about an
> > > example of loading RAW from QSPI that i have done locally last few
> > > week
> > > ago.
> > As your patches show, no it's not hard, it's more or less taking
> > pieces
> > from the SPL loader framework and refactoring them into the FS
> > loader,
> > creating a good and universal solution usable across SPL and U-Boot
> > in
> > environments that are not tightly constrained in terms of memory.
> >
> > What I was going after is finding a way to load from different media
> > "pre-relocation" SPL (board_init_f), with almost no memory available,
> > where I have to agonize over every single KB available.
>
> This is just a simple "loader", provide user flexibility of loading
> stuff in anywhere, from SPL to U-Boot. As long as DM is supported by
> the time running at "pre-relocation" SPL, then FS loader should be able
> to work.
Understood. FS loader also relies on the peripheral being brought up.
For MMC, from my SPL board_init_f() user code I had to do a sequence of
mmc_initialize(), mmc_get_mmc_dev(), and mmc_init() before I could use
the FS loader functionality - just like the U-Boot SPL loader is already
doing this. Hence my concern with code duplication for certain use
cases. Anyways I'll post my use of the FS loader as an RFC here soon
so you can have a look at the whole thing if you like.
> > > > > being heavier on resource usage (needing to use ENV to pass
> > > > > parameters),
> > > ENV is optional, you can use DTS.
> > Is it? I had to update the FS loader framework when I experimented
> > with
> > it, please see attached patch. I had refactored it such that I can
> > pass
> > in all relevant data via platform data for the intial boot mode I was
> > going after, so that I can dynamically configure it on the fly from
> > early SPL board_init_f() based on boot media / boot mode, etc.
>
> Yes, you can tie up loader with target HW node for destination loading.
> For example, tie up with FPGA manager node, loading bistream file from
> MMC to FPGA manager.
>
> Here is an example, but i put the fs loader phandle under chosen node
> because most files and images are stored in the same storage.
> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=0a42a132a4b8
> 46031df2c4a7d04692240ed34843
Thanks for pointing to this example for DTS-based loading, I think I had
seen this earlier when I looked for implementations using the FS loader
framework.
> > >
> > > For example loading FPGA bitstream from QSPI RAW:
> > >
> > > /* DTS */
> > > / {
> > > + aliases {
> > > + spi0 = &qspi;
> > > + };
> > > +
> > > + fs_loader0: fs-loader {
> > > + u-boot,dm-pre-reloc;
> > > + compatible = "u-boot,fs-loader";
> > > + sfconfig = <0 0 1 3>;
> > > + };
> > > +};
> > > +
> > > +&fpga_mgr {
> > > + u-boot,dm-pre-reloc;
> > > + firmware-loader = <&fs_loader0>;
> > > + altr,bitstream = "30";
> > > +};
> > The above hard-codes and duplicates information that is already known
> > to
> > U-Boot (CONFIG_SF_DEFAULT_*), and will do more of the same as this is
> > being extended. How does one keep this consistent?
>
> Current fs loader not support RAW loading yet, i'm not sure whether it
> should support it by adding more specific storage API(much more messy),
> or just fully support filesystem only with one generic filesystem
> abstract interface.
>
> This example codes provide user opportunity to override the spi setting
> when running fs loader. CONFIG_SF_DEFAULT_* would be used by the
> drivers which are not running the fs loader.
>
> >
> > And how does this scale to support like 5 different boot modes using
> > a
> > single DTB? I guess one could populate 5 nodes, and then pick one
> > based
> > on boot mode during SPL execution, by extending the probe function
> > accordingly.
>
> This is just a very simple fs loader. This is totally up to user how
> they want to scale it up, may be adding the function to populate the fs
> loader nodes, or loading the images based on boot storages ordering in
> DTS?
This would require on-the-fly FDT manipulation. A
Re: [U-Boot] [PATCH] ARM: imx6logic: Stop overwriting fdt_file if manually set
On Wed, Mar 13, 2019 at 10:49 AM Adam Ford wrote:
> The board file uses the processor type to determine what dtb file
> is set. Unfortunately, if the user wants to manually set this,
> it get gets overwritten upon boot. This patch adds a check to
> see if the value is already set and only changes it if the value
> is empty.
>
> Signed-off-by: Adam Ford
>
>
Gentle nudge to try and get this into the next release.
thanks
adam
> diff --git a/board/logicpd/imx6/imx6logic.c
> b/board/logicpd/imx6/imx6logic.c
> index b17a3b1d39..53e609e15c 100644
> --- a/board/logicpd/imx6/imx6logic.c
> +++ b/board/logicpd/imx6/imx6logic.c
> @@ -152,7 +152,8 @@ int board_late_init(void)
>
> if (is_mx6dq()) {
> env_set("board_rev", "MX6DQ");
> - env_set("fdt_file", "imx6q-logicpd.dtb");
> + if (!env_get("fdt_file"))
> + env_set("fdt_file", "imx6q-logicpd.dtb");
> }
>
> return 0;
> --
> 2.17.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: da850evm: Enable block cache during SPL
There appears to be enough RAM to support cache in SPL. This pach enables block cache in SPL. Signed-off-by: Adam Ford diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig index 09c6147e2d..8c16d5c4f5 100644 --- a/configs/da850evm_defconfig +++ b/configs/da850evm_defconfig @@ -47,6 +47,7 @@ CONFIG_DM=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SPL_OF_TRANSLATE=y +CONFIG_SPL_BLOCK_CACHE=y CONFIG_DM_GPIO=y CONFIG_DA8XX_GPIO=y CONFIG_DM_I2C=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Kconfig: fix FIT offset prompt text
On 5/15/19 11:10 PM, Ibai Erkiaga wrote: > The current prompt text for FIT external offset is identical to > SYS_TEXT_BASE which might confuse the users. Provided more accurate > description for the prompt text. > > Signed-off-by: Ibai Erkiaga Reviewed-by: Marek Vasut -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Kconfig: fix FIT offset prompt text
On 5/15/19 11:15 PM, Marek Vasut wrote: > On 5/15/19 3:57 PM, Ibai Erkiaga wrote: >> The current prompt text for FIT external offset is identical to >> SYS_TEXT_BASE which might confuse the users. Provided more accurate >> description for the prompt text. >> >> Signed-off-by: Ibai Erkiaga >> --- >> >> Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/Kconfig b/Kconfig >> index 91c1082..f490ee4 100644 >> --- a/Kconfig >> +++ b/Kconfig >> @@ -278,7 +278,7 @@ config FIT >> if FIT >> >> config FIT_EXTERNAL_OFFSET >> -hex "Text Base" >> +hex "FIT External Offset" > > What changed ? There's no changelog and the patch looks the same too ;-) Argh, forget what I said, sorry. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Kconfig: fix FIT offset prompt text
On 5/15/19 3:57 PM, Ibai Erkiaga wrote: > The current prompt text for FIT external offset is identical to > SYS_TEXT_BASE which might confuse the users. Provided more accurate > description for the prompt text. > > Signed-off-by: Ibai Erkiaga > --- > > Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Kconfig b/Kconfig > index 91c1082..f490ee4 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -278,7 +278,7 @@ config FIT > if FIT > > config FIT_EXTERNAL_OFFSET > - hex "Text Base" > + hex "FIT External Offset" What changed ? There's no changelog and the patch looks the same too ;-) > default 0x0 > help > This specifies a data offset in fit image. > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Kconfig: fix FIT offset prompt text
> -Original Message- > From: Marek Vasut > Sent: 15 May 2019 15:09 > To: Ibai Erkiaga Elorza ; u-boot@lists.denx.de > Cc: Michal Simek ; Simon Glass ; > Masahiro Yamada ; Peng Fan > ; Chris Packham ; Jagan Teki > ; Stefan Roese > Subject: Re: [U-Boot][PATCH] Kconfig: fix FIT offset prompt text > > On 5/15/19 3:57 PM, Ibai Erkiaga wrote: > > The current prompt text for FIT external offset is identical to > > SYS_TEXT_BASE which might confuse the users. Provided more accurate > > description for the prompt text. > > > > Signed-off-by: Ibai Erkiaga > > --- > > > > Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Kconfig b/Kconfig > > index 91c1082..f490ee4 100644 > > --- a/Kconfig > > +++ b/Kconfig > > @@ -278,7 +278,7 @@ config FIT > > if FIT > > > > config FIT_EXTERNAL_OFFSET > > - hex "Text Base" > > + hex "FIT External Offset" > > "FIT external data offset" then ? > Fair enough, let me send an updated patch > > default 0x0 > > help > > This specifies a data offset in fit image. > > > > > -- > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] Kconfig: fix FIT offset prompt text
The current prompt text for FIT external offset is identical to SYS_TEXT_BASE which might confuse the users. Provided more accurate description for the prompt text. Signed-off-by: Ibai Erkiaga --- Changes in v2: -More detailed text Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index 91c1082..da208d6 100644 --- a/Kconfig +++ b/Kconfig @@ -278,7 +278,7 @@ config FIT if FIT config FIT_EXTERNAL_OFFSET - hex "Text Base" + hex "FIT external data offset" default 0x0 help This specifies a data offset in fit image. -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: GetVariable set attributes for EFI_BUFFER_TOO_SMALL
UEFI spec 2.7 erratum A leaves it undefined if Attributes should be set if
GetVariable() returns EFI_BUFFER_TOO_SMALL.
UEFI spec 2.8 defines that Attributes should be set if the return value is
either EFI_SUCCESS or EFI_BUFFER_TOO_SMALL.
Set Attributes if the return value is EFI_BUFFER_TOO_SMALL.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_variable.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 37728c3c16..28b1aa7505 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -202,8 +202,10 @@ efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
len /= 2;
*data_size = len;
- if (in_size < len)
- return EFI_EXIT(EFI_BUFFER_TOO_SMALL);
+ if (in_size < len) {
+ ret = EFI_BUFFER_TOO_SMALL;
+ goto out;
+ }
if (!data)
return EFI_EXIT(EFI_INVALID_PARAMETER);
@@ -217,8 +219,10 @@ efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
*data_size = len;
- if (in_size < len)
- return EFI_EXIT(EFI_BUFFER_TOO_SMALL);
+ if (in_size < len) {
+ ret = EFI_BUFFER_TOO_SMALL;
+ goto out;
+ }
if (!data)
return EFI_EXIT(EFI_INVALID_PARAMETER);
@@ -232,10 +236,11 @@ efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
return EFI_EXIT(EFI_DEVICE_ERROR);
}
+out:
if (attributes)
*attributes = attr & EFI_VARIABLE_MASK;
- return EFI_EXIT(EFI_SUCCESS);
+ return EFI_EXIT(ret);
}
static char *efi_variables_list;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
Hi Tom, On Wed, May 15, 2019 at 11:16:43AM -0400, Tom Rini wrote: > On Tue, May 07, 2019 at 12:25:29PM -0500, Andreas Dannenberg wrote: > > > TI K3 SoCs like the AM654x devices are fundamentally dependent on a > > firmware called SYSFW (System Firmware) being loaded into the dedicated > > DMSC (Device Management and Security Controller) processor to provide > > various services via TISCI (Texas Instruments System Control Interface) > > to manage device aspects such as core bringup, power, clocks, security, > > and so on across the entire SoC. > [snip] > > While I also have a working solution based on the existing FS loader > > framework this has its own challenges, namely by its very nature only > > addressing a subset of our use cases (no eMMC/SD RAW boot support for > > example), being heavier on resource usage (needing to use ENV to pass > > parameters), and not addressing the need to probe the boot peripheral. > > This particular framework works well for use cases requiring to load > > firmware from FS-based media once DDR is up and U-Boot is in a more > > "initialized" state but it is not a one-fits all solution for very > > early use in SPL board_init_f() accross different boot modes. > > I think one thing that might help here is to post this alternative > solution and provide the 'size' information for both series. In > addition, build something like am335x_evm and socfpga_stratix10 for both > series and include their before/after 'size' info too. Thanks! thanks for looking at this more closely. Sure, let me collect some data on this front and also post the alternative solution. It won't be a completely fair comparison however as the alternative solution only supports FS-based MMC boot, whereas the solution proposed here also supports eMMC/SD RAW boot, both partition and sector-based (and a combination thereof). -- Andreas Dannenberg Texas Instruments Inc ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Import include/android_bootloader_message.h from AOSP
Reviewed-by: Sam Protsenko
On Tue, May 14, 2019 at 10:46 PM Alex Deymo wrote:
>
> This takes the latest changes from AOSP from the file
> bootloader_message/include/bootloader_message/bootloader_message.h
> in the repository
> https://android.googlesource.com/platform/bootable/recovery
> and re-licensed them to BSD-3 for U-Boot.
>
> Minimum local changes have been applied (convert C++ to C comments and
> adding #ifndef __UBOOT__ block to skip all the function declarations).
>
> Signed-off-by: Alex Deymo
> ---
> include/android_bootloader_message.h | 246 +++
> 1 file changed, 246 insertions(+)
> create mode 100644 include/android_bootloader_message.h
>
> diff --git a/include/android_bootloader_message.h
> b/include/android_bootloader_message.h
> new file mode 100644
> index 00..b84789f022
> --- /dev/null
> +++ b/include/android_bootloader_message.h
> @@ -0,0 +1,246 @@
> +/*
> + * This is from the Android Project,
> + * Repository: https://android.googlesource.com/platform/bootable/recovery
> + * File: bootloader_message/include/bootloader_message/bootloader_message.h
> + * Commit: c784ce50e8c10eaf70e1f97e24e8324aef45faf5
> + *
> + * Copyright (C) 2008 The Android Open Source Project
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +#ifndef __ANDROID_BOOTLOADER_MESSAGE_H
> +#define __ANDROID_BOOTLOADER_MESSAGE_H
> +
> +/* compiler.h defines the types that otherwise are included from stdint.h and
> + * stddef.h
> + */
> +#include
> +
> +/* Spaces used by misc partition are as below:
> + * 0 - 2K For bootloader_message
> + * 2K - 16KUsed by Vendor's bootloader (the 2K - 4K range may be
> optionally used
> + * as bootloader_message_ab struct)
> + * 16K - 64KUsed by uncrypt and recovery to store wipe_package for A/B
> devices
> + * Note that these offsets are admitted by bootloader,recovery and uncrypt,
> so they
> + * are not configurable without changing all of them. */
> +static const size_t BOOTLOADER_MESSAGE_OFFSET_IN_MISC = 0;
> +static const size_t WIPE_PACKAGE_OFFSET_IN_MISC = 16 * 1024;
> +
> +/* Bootloader Message (2-KiB)
> + *
> + * This structure describes the content of a block in flash
> + * that is used for recovery and the bootloader to talk to
> + * each other.
> + *
> + * The command field is updated by linux when it wants to
> + * reboot into recovery or to update radio or bootloader firmware.
> + * It is also updated by the bootloader when firmware update
> + * is complete (to boot into recovery for any final cleanup)
> + *
> + * The status field was used by the bootloader after the completion
> + * of an "update-radio" or "update-hboot" command, which has been
> + * deprecated since Froyo.
> + *
> + * The recovery field is only written by linux and used
> + * for the system to send a message to recovery or the
> + * other way around.
> + *
> + * The stage field is written by packages which restart themselves
> + * multiple times, so that the UI can reflect which invocation of the
> + * package it is. If the value is of the format "#/#" (eg, "1/3"),
> + * the UI will add a simple indicator of that status.
> + *
> + * We used to have slot_suffix field for A/B boot control metadata in
> + * this struct, which gets unintentionally cleared by recovery or
> + * uncrypt. Move it into struct bootloader_message_ab to avoid the
> + * issue.
> + */
> +struct bootloader_message {
> +char command[32];
> +char status[32];
> +char recovery[768];
> +
> +/* The 'recovery' field used to be 1024 bytes. It has only ever
> + * been used to store the recovery command line, so 768 bytes
> + * should be plenty. We carve off the last 256 bytes to store the
> + * stage string (for multistage packages) and possible future
> + * expansion. */
> +char stage[32];
> +
> +/* The 'reserved' field used to be 224 bytes when it was initially
> + * carved off from the 1024-byte recovery field. Bump it up to
> + * 1184-byte so that the entire bootloader_message struct rounds up
> + * to 2048-byte. */
> +char reserved[1184];
> +};
> +
> +/**
> + * We must be cautious when changing the bootloader_message struct size,
> + * because A/B-specific fields may end up with different offsets.
> + */
> +#if (__STDC_VERSION__ >= 201112L) || defined(__cplusplus)
> +static_assert(sizeof(struct bootloader_message) == 2048,
> + "struct bootloader_message size changes, which may break A/B
> devices");
> +#endif
> +
> +/**
> + * The A/B-specific bootloader message structure (4-KiB).
> + *
> + * We separate A/B boot control metadata from the regular bootloader
> + * message struct and keep it here. Everything that's A/B-specific
> + * stays after struct bootloader_message, which should be managed by
> + * the A/B-bootloader or boot control HAL.
> + *
> + * The slot_suffix field is used for A/B implementations where the
> + * bootloader does not set the androidboot.ro.boot.slot_suffix kernel
Re: [U-Boot] [PATCH 13/18] arm: K3: am654: Map common EEPROM data into SRAM scratch space
Tom et al., On Thu, May 09, 2019 at 11:27:25AM -0500, Andreas Dannenberg wrote: > > > Won't HS devices fail while accessing this region? We should drop it > > > altogether. > > > > > > > HS devices cannot read this before SYSFW is loaded as by default it is > > left firewalled by ROM. This read happens after SYSFW loading so it does > > work currently, but no guarantee SYSFW will always remove this firewall > > by default, we may need a driver that does an explicit device get for > > this region to be sure it is powered and accessible (it is on a > > different reset domain, it may need special handling). > > Yes this is understood. For others reading this, this is how it is done > in our current production U-Boot tree (upstream U-Boot does not yet have > SYSFW loading capability). > > > I think we should avoid using this scratchpad for a couple other > > reasons. After R5 SPL has finished bootloading is handled by A53 cores, > > the R5 will be repurposed and other software will run on it, possibly > > wiping out the memory here. Anything we want to pass form R5 to A53 > > should use a non-R5-local memory, not this scratchpad. We need the same > > for passing the original boot media info also. > > > > A lot of pitfalls for just 512 bytes of RAM.. > > I don't disagree, this approach is limited, it's just the "easiest" we > started using when creating the initial solution. Let's find/align on a > different memory region. After additional alignment internally with Lokesh and Andrew we agreed on that for the time being we would like to move forward with the solution proposed here as it relates to the use of the scratchpad SRAM. It works for all current use cases including "high security" type devices as it stands. We may re-visit and evolve the solution should a need arise when adding support for a future device (so far there is no such need on our immediate radar screen). I also just rebased the solution on the latest upstream/master tree and confirmed that it still works as expected. -- Andreas Dannenberg Texas Instruments Inc > While at it, there is a need to pass additional data across our three > boot stages (R5 SPL -> A53 SPL -> A53 U-Boot); for example I'd at some > point like to carry forward peripheral initialization state (so we don't > have to re-probe stuff 3 times), amongst other things, for which I was > eyeing to use the new CONFIG_BLOBLIST* feature. So if we can identify a > new/dedicated memory region for such data it would be a good opportunity > to also start making use of the BLOBLIST feature at the same time, > creating a more scalable solution. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2019.07-rc2 released
Hey all, It's 2 days past release day, oops, and here is v2019.07-rc2. I think we're largely in good shape, but there's some big things to address still. Things that we need to address are what to do about the code that has gone past the DM migration. What I've said elsewhere is that I want to disable building of the code for a release, and remove it in a following release. How close are we to being able to do that? Well, Jagan started out a series for SPI that did most of what I wanted but didn't stop building the code. I've taken that and reworked it so we don't build the code in question, but do build the platforms. The only thing right now preventing me from posting it, aside from one last world build (which is in progress) is that it really will make a lot of PowerPC platforms build-but-useless. I don't think there's a good option to pick from here but I am hopeful we'll see at least a few platforms updated and converted after this happens. In terms of a changelog, git log --merges v2019.07-rc1..v2019.07-rc2 looks pretty good but the content there varies based on what was given to me in the PR. So please, the more details in the request the better! I'm planning on doing -rc3 on the 27th of May with -rc4 on June 10th and -rc5 on June 24th with the release scheduled on July 8th. Thanks all! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: kconfig: separate sysreset and firmware drivers from misc
Am 15.05.2019 um 18:19 schrieb Patrick DELAUNAY: Hi Simon This adds separate kconfig options for drivers/sysreset and drivers/firmware. Up to now, CONFIG_SPL_DRIVERS_MISC_SUPPORT added drivers/misc to SPL build but also added drivers/firmware and drivers/sysreset at the same time. Since that is confusing, this patch adds CONFIG_SPL_SYSRESET_SUPPORT for drivers/sysreset and CONFIG_SPL_DRIVERS_FIRMWARE_SUPPORT for drivers/firmware (and accordingly for the TPL options). To keep the binaries unchanged, this patch enables the 2 new options on all boards where DRIVERS_MISC_SUPPORT has been enabled before. Signed-off-by: Simon Goldschmidt I have one compilation failed for one board (on latest master branch) arm: + stm32f746-disco +drivers/built-in.o: In function `do_reset': +drivers/sysreset/sysreset-uclass.c:113: multiple definition of `do_reset' +arch/arm/lib/built-in.o:arch/arm/lib/reset.c:30: first defined here +drivers/built-in.o: In function `reset_cpu': +drivers/sysreset/sysreset-uclass.c:107: multiple definition of `reset_cpu' +arch/arm/cpu/armv7m/built-in.o:arch/arm/cpu/armv7m/cpu.c:53: first defined here +make[2]: *** [spl/u-boot-spl] Error 1 +make[1]: *** [spl/u-boot-spl] Error 2 +make: *** [sub-make] Error 2 But you have perhaps other patch in your branch... => for me select SPL_SYSRESET need to be removed for config STM32F7 to avoid driver/sysreset/uclass.c compilation Right, thanks for the hint. Seems like I need to not select CONFIG_SPL_SYSRESET if CONFIG_SYSRESET wasn't set. Also, I need to throw this at travis before sending v3... Regards, Simon For stm32mp and stm32: SPL_MISC needed for rcc SPL_SYSRESET are needed for only stm32mp1 cause compilation error for stm32 SPL_FIRMWARE is not needed but I will remove it when this patch will by merged. For the other part Reviewed-by: Patrick Delaunay Thanks, Patrick --- ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] warp7: include: configs: Differentiate bootscript address from loadaddr
Le 15/05/2019 à 10:23, Bryan O'Donoghue a écrit : On 14/05/2019 21:27, Pierre-Jean Texier wrote: should this apply in isolation ? Not necessarily, on my side everything working well on-top of master, for example: Hit any key to stop autoboot: 0 => run bootcmd_mmc0 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found U-Boot script /boot.scr So do you need a boot.scr for this patch to work, how will that affect current users who rely on the u-boot env only ? In fact, by using the Generic Distro Concept, we can also use the extlinux file, as explained in[1]. Example on WaRP7 : => run bootcmd_mmc0 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 132 bytes read in 1 ms (128.9 KiB/s) 1: linux Retrieving file: /zImage 8118520 bytes read in 116 ms (66.7 MiB/s) append: root=PARTUUID= rootwait rw console=ttymxc0,115200 Retrieving file: /imx7s-warp.dtb 26889 bytes read in 4 ms (6.4 MiB/s) Kernel image @ 0x8080 [ 0x00 - 0x7be0f8 ] ## Flattened Device Tree blob at 8300 Booting using the fdt blob at 0x8300 Using Device Tree in place at 8300, end 83009908 Regarding your question, it seems that is now the standard on many platforms [2]. In fact, instead of keeping a custom environment, it is better to use a more generic approach by switching to disto config (with boot.scr, extlinux, and so on). For sure, we can customized the CONFIG_BOOTCOMMAND variable in patch. [1] http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.distro [2] https://github.com/u-boot/u-boot/search?q=BOOT_TARGET_DEVICES%28func%29&unscoped_q=BOOT_TARGET_DEVICES%28func%29 Thanks Pierre-jean ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] AM3517 SPL fails with CONFIG_DM enabled
On Wed, May 15, 2019 at 7:43 PM Adam Ford wrote: > > On Wed, May 15, 2019 at 1:25 PM Simon Goldschmidt > wrote: > > > > Am 15.05.2019 um 20:12 schrieb Adam Ford: > > > I am trying to add DM support in SPL along with device tree support > > > similar to how it's being done for the omap3_logic boards. > > > Unfortunately, I think something is going wrong in the initialization > > > with CONFIG_DM enabled for SPL because I get no text data, and it > > > doesn't appear to boot. > > > > > > I tried enabling DM in SPL and using the older platdata method without > > > success. I have disabled DM_SERIAL in SPL and tried enabling the > > > serial debug stuff, and I get nothing. I don't have a debugger, so > > > it's a bit more difficult to troubleshoot. > > > > > > The main difference between the am35 and omap3 is the memory > > > controller, and I've tried to model the am35 after the omap3 boards I > > > also maintain. I was hoping someone might have any suggestions on how > > > to track down the issue. As of right now, I have OF_CONTROL working > > > in U-Boot and with DM disabled in SPL, everything is good. > > > > I don't know that mach, but reading the files, you're calling > > 'spl_early_init()' from your 'board_init_f()'. The problem I had there > > was that I did not have enough heap - and notice you need pre-reloc heap > > enabled. > > I have a device tree setup with a variety of pre-reloc entries. There > is an omap3-u-boot.dtsi file which sets this up. > dtc -I dtb -O dts spl/u-boot-spl.dtb lists a bunch of nodes for gpio, > mmc, serial, and some misc dependencies. > > Is there somewhere else I need to enable the pre-reloc stuff? > > > > > spl_early_init() parses the dts and binds the drivers, and even the > > default CONFIG_SPL_SYS_MALLOC_F_LEN of 1 KiB wasn't enough for me. Oh, > > and of course you need CONFIG_SYS_MALLOC_F enabled when calling > > spl_early_ini() from board_init_f in SPL. > > My updated defconfig file has: > > CONFIG_SYS_MALLOC_F_LEN=0x4000 > CONFIG_SYS_MALLOC_F=y > We had a similar problem, which we tracked down to calling DM functions before the DT was loaded (because we needed to probe GPIOs in order to know which DT we wanted), obviously that wasn't useful, but even with a heap of the size you've got here we were OOMing. To figure out exactly where we'd got we it wrong we ended up running with full malloc in SPL rather than simple malloc and chopping enough stuff out that it all fitted, at which point actually finding out our mistake got a lot easier (and then we could turn simple malloc back on). -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] AM3517 SPL fails with CONFIG_DM enabled
Am 15.05.2019 um 20:43 schrieb Adam Ford: On Wed, May 15, 2019 at 1:25 PM Simon Goldschmidt wrote: Am 15.05.2019 um 20:12 schrieb Adam Ford: I am trying to add DM support in SPL along with device tree support similar to how it's being done for the omap3_logic boards. Unfortunately, I think something is going wrong in the initialization with CONFIG_DM enabled for SPL because I get no text data, and it doesn't appear to boot. I tried enabling DM in SPL and using the older platdata method without success. I have disabled DM_SERIAL in SPL and tried enabling the serial debug stuff, and I get nothing. I don't have a debugger, so it's a bit more difficult to troubleshoot. The main difference between the am35 and omap3 is the memory controller, and I've tried to model the am35 after the omap3 boards I also maintain. I was hoping someone might have any suggestions on how to track down the issue. As of right now, I have OF_CONTROL working in U-Boot and with DM disabled in SPL, everything is good. I don't know that mach, but reading the files, you're calling 'spl_early_init()' from your 'board_init_f()'. The problem I had there was that I did not have enough heap - and notice you need pre-reloc heap enabled. I have a device tree setup with a variety of pre-reloc entries. There is an omap3-u-boot.dtsi file which sets this up. dtc -I dtb -O dts spl/u-boot-spl.dtb lists a bunch of nodes for gpio, mmc, serial, and some misc dependencies. Is there somewhere else I need to enable the pre-reloc stuff? None that I know of. But I haven't made the transition to DM SPL, I only suffered when adding more DM drivers... Are you sure that omap3-u-boot.dtsi gets auto-included? I don't know exactly how that automatism works... spl_early_init() parses the dts and binds the drivers, and even the default CONFIG_SPL_SYS_MALLOC_F_LEN of 1 KiB wasn't enough for me. Oh, and of course you need CONFIG_SYS_MALLOC_F enabled when calling spl_early_ini() from board_init_f in SPL. My updated defconfig file has: CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_SYS_MALLOC_F=y That should probably be enough :-) Anyway, before calling spl_early_init(), I thought there shouldn't be anything going wrong, so debug UART should work when initialized before spl_early_init() is called? Have you double-checked you're not hitting some size limit of your platform? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: variable: attributes may not be changed if a variable exists
On 5/15/19 8:09 AM, AKASHI Takahiro wrote:
> On Tue, May 14, 2019 at 08:08:49PM +0200, Heinrich Schuchardt wrote:
>> On 5/14/19 8:35 AM, Heinrich Schuchardt wrote:
>>> On 5/14/19 6:57 AM, AKASHI Takahiro wrote:
If a variable already exists, efi_set_variable() should not change
the variable's attributes. This patch enforces it.
>>>
>>> This behavior is mandated by UEFI spec 2.7.
>>>
>>> Reviewed-by: Heinrich Schuchardt
>>
>> This patch let's `bootefi selftest`fail:
>>
>> Executing 'variables'
>> lib/efi_selftest/efi_selftest_variables.c(60):
>> TODO: QueryVariableInfo failed
>> lib/efi_selftest/efi_selftest_variables.c(119):
>> ERROR: SetVariable failed
>> lib/efi_selftest/efi_selftest.c(110):
>> ERROR: Executing 'variables' failed
>>
>> The preferred solution would be to implement APPEND_WRITE.
>>
>> Otherwise at least adjust the unit test concerning APPEND_WRITE to use
>> efi_st_todo() and not to abort the test.
>
> Since the current code doesn't supoort APPEND_WRITE, my commit
> doesn't break anything. You should fix selftest first.
>
> I don't have an immediate plan to implement APPEND_WRITE for now.
>
> -Takahiro Akashi
>
>> I suggest that you always run `bootefi selftest` before submitting
>> changes to the UEFI sub-system.
>>
>> Best regards
>>
>> Heinrich
>>
>>>
Signed-off-by: AKASHI Takahiro
---
lib/efi_loader/efi_variable.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/lib/efi_loader/efi_variable.c
b/lib/efi_loader/efi_variable.c
index 37728c3c165d..c4f3a5d2743d 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -450,6 +450,15 @@ efi_status_t EFIAPI efi_set_variable(u16
*variable_name,
ret = EFI_WRITE_PROTECTED;
goto out;
}
+
+ /*
+ * attributes won't be changed
+ * TODO: take care of APPEND_WRITE once supported
+ */
+ if (attr != attributes) {
+ ret = EFI_INVALID_PARAMETER;
+ goto out;
You are freeing val. But this value was not allocated by you.
I saw this with `bootefi selftest` after applying
diff --git a/lib/efi_selftest/efi_selftest_variables.c
b/lib/efi_selftest/efi_selftest_variables.c
index b028c64bbc..e8346d0d4a 100644
--- a/lib/efi_selftest/efi_selftest_variables.c
+++ b/lib/efi_selftest/efi_selftest_variables.c
@@ -115,10 +115,8 @@ static int execute(void)
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_APPEND_WRITE,
7, v + 8);
- if (ret != EFI_SUCCESS) {
- efi_st_error("SetVariable failed\n");
- return EFI_ST_FAILURE;
- }
+ if (ret != EFI_SUCCESS)
+ efi_st_todo("SetVariable: append failed\n");
len = EFI_ST_MAX_DATA_SIZE;
ret = runtime->get_variable(L"efi_st_var1", &guid_vendor1,
&attr, &len, data);
Please, run (and if necessary adjust) unit tests before submitting patches.
Best regards
Heinrich
+ }
}
val = malloc(2 * data_size + strlen("{ro,run,boot}(blob)") + 1);
>>>
>>>
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] AM3517 SPL fails with CONFIG_DM enabled
On Wed, May 15, 2019 at 1:25 PM Simon Goldschmidt wrote: > > Am 15.05.2019 um 20:12 schrieb Adam Ford: > > I am trying to add DM support in SPL along with device tree support > > similar to how it's being done for the omap3_logic boards. > > Unfortunately, I think something is going wrong in the initialization > > with CONFIG_DM enabled for SPL because I get no text data, and it > > doesn't appear to boot. > > > > I tried enabling DM in SPL and using the older platdata method without > > success. I have disabled DM_SERIAL in SPL and tried enabling the > > serial debug stuff, and I get nothing. I don't have a debugger, so > > it's a bit more difficult to troubleshoot. > > > > The main difference between the am35 and omap3 is the memory > > controller, and I've tried to model the am35 after the omap3 boards I > > also maintain. I was hoping someone might have any suggestions on how > > to track down the issue. As of right now, I have OF_CONTROL working > > in U-Boot and with DM disabled in SPL, everything is good. > > I don't know that mach, but reading the files, you're calling > 'spl_early_init()' from your 'board_init_f()'. The problem I had there > was that I did not have enough heap - and notice you need pre-reloc heap > enabled. I have a device tree setup with a variety of pre-reloc entries. There is an omap3-u-boot.dtsi file which sets this up. dtc -I dtb -O dts spl/u-boot-spl.dtb lists a bunch of nodes for gpio, mmc, serial, and some misc dependencies. Is there somewhere else I need to enable the pre-reloc stuff? > > spl_early_init() parses the dts and binds the drivers, and even the > default CONFIG_SPL_SYS_MALLOC_F_LEN of 1 KiB wasn't enough for me. Oh, > and of course you need CONFIG_SYS_MALLOC_F enabled when calling > spl_early_ini() from board_init_f in SPL. My updated defconfig file has: CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_SYS_MALLOC_F=y > > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] net: eth-uclass: Support device tree MAC addresses
On Thu, Apr 25, 2019 at 10:50 AM Thierry Reding wrote: > > From: Thierry Reding > > Add the standard Ethernet device tree bindings (imported from v5.0 of > the Linux kernel) and implement support for reading the MAC address for > Ethernet devices in the Ethernet uclass. If the "mac-address" property > exists, the MAC address will be parsed from that. If that property does > not exist, the "local-mac-address" property will be tried as fallback. > > MAC addresses from device tree take precedence over the ones stored in > a network interface card's ROM. > > Acked-by: Joe Hershberger > Signed-off-by: Thierry Reding This seems to introduce a few build failures. https://travis-ci.org/jhershbe/u-boot/builds/532478716 Please have a look and submit a v4. Thanks, -Joe > --- > Changes in v3: > - add additional check to make sure the MAC address read from device > tree is a valid MAC address > > Changes in v2: > - use dev_read_u8_array_ptr() > > .../devicetree/bindings/net/ethernet.txt | 66 +++ > net/eth-uclass.c | 27 +++- > 2 files changed, 90 insertions(+), 3 deletions(-) > create mode 100644 Documentation/devicetree/bindings/net/ethernet.txt > > diff --git a/Documentation/devicetree/bindings/net/ethernet.txt > b/Documentation/devicetree/bindings/net/ethernet.txt > new file mode 100644 > index ..cfc376bc977a > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/ethernet.txt > @@ -0,0 +1,66 @@ > +The following properties are common to the Ethernet controllers: > + > +NOTE: All 'phy*' properties documented below are Ethernet specific. For the > +generic PHY 'phys' property, see > +Documentation/devicetree/bindings/phy/phy-bindings.txt. > + > +- local-mac-address: array of 6 bytes, specifies the MAC address that was > + assigned to the network device; > +- mac-address: array of 6 bytes, specifies the MAC address that was last > used by > + the boot program; should be used in cases where the MAC address assigned to > + the device by the boot program is different from the "local-mac-address" > + property; > +- nvmem-cells: phandle, reference to an nvmem node for the MAC address; > +- nvmem-cell-names: string, should be "mac-address" if nvmem is to be used; > +- max-speed: number, specifies maximum speed in Mbit/s supported by the > device; > +- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather > than > + the maximum frame size (there's contradiction in the Devicetree > + Specification). > +- phy-mode: string, operation mode of the PHY interface. This is now a > de-facto > + standard property; supported values are: > + * "internal" > + * "mii" > + * "gmii" > + * "sgmii" > + * "qsgmii" > + * "tbi" > + * "rev-mii" > + * "rmii" > + * "rgmii" (RX and TX delays are added by the MAC when required) > + * "rgmii-id" (RGMII with internal RX and TX delays provided by the PHY, the > + MAC should not add the RX or TX delays in this case) > + * "rgmii-rxid" (RGMII with internal RX delay provided by the PHY, the MAC > + should not add an RX delay in this case) > + * "rgmii-txid" (RGMII with internal TX delay provided by the PHY, the MAC > + should not add an TX delay in this case) > + * "rtbi" > + * "smii" > + * "xgmii" > + * "trgmii" > + * "2000base-x", > + * "2500base-x", > + * "rxaui" > + * "xaui" > + * "10gbase-kr" (10GBASE-KR, XFI, SFI) > +- phy-connection-type: the same as "phy-mode" property but described in the > + Devicetree Specification; > +- phy-handle: phandle, specifies a reference to a node representing a PHY > + device; this property is described in the Devicetree Specification and so > + preferred; > +- phy: the same as "phy-handle" property, not recommended for new bindings. > +- phy-device: the same as "phy-handle" property, not recommended for new > + bindings. > +- rx-fifo-depth: the size of the controller's receive fifo in bytes. This > + is used for components that can have configurable receive fifo sizes, > + and is useful for determining certain configuration settings such as > + flow control thresholds. > +- tx-fifo-depth: the size of the controller's transmit fifo in bytes. This > + is used for components that can have configurable fifo sizes. > +- managed: string, specifies the PHY management type. Supported values are: > + "auto", "in-band-status". "auto" is the default, it usess MDIO for > + management if fixed-link is not specified. > + > +Child nodes of the Ethernet controller are typically the individual PHY > devices > +connected via the MDIO bus (sometimes the MDIO bus controller is separate). > +They are described in the phy.txt file in this same directory. > +For non-MDIO PHY management see fixed-link.txt. > diff --git a/net/eth-uclass.c b/net/eth-uclass.c > index 4225aabf1fa1..28a82d7fc8d3 100644 > --- a/net/eth-uclass.c > +++ b/net/eth-uclass.c > @@ -455,6 +455,23 @@ static int eth_pre_unbind(struct udevice *dev) > return 0
Re: [U-Boot] AM3517 SPL fails with CONFIG_DM enabled
Am 15.05.2019 um 20:12 schrieb Adam Ford: I am trying to add DM support in SPL along with device tree support similar to how it's being done for the omap3_logic boards. Unfortunately, I think something is going wrong in the initialization with CONFIG_DM enabled for SPL because I get no text data, and it doesn't appear to boot. I tried enabling DM in SPL and using the older platdata method without success. I have disabled DM_SERIAL in SPL and tried enabling the serial debug stuff, and I get nothing. I don't have a debugger, so it's a bit more difficult to troubleshoot. The main difference between the am35 and omap3 is the memory controller, and I've tried to model the am35 after the omap3 boards I also maintain. I was hoping someone might have any suggestions on how to track down the issue. As of right now, I have OF_CONTROL working in U-Boot and with DM disabled in SPL, everything is good. I don't know that mach, but reading the files, you're calling 'spl_early_init()' from your 'board_init_f()'. The problem I had there was that I did not have enough heap - and notice you need pre-reloc heap enabled. spl_early_init() parses the dts and binds the drivers, and even the default CONFIG_SPL_SYS_MALLOC_F_LEN of 1 KiB wasn't enough for me. Oh, and of course you need CONFIG_SYS_MALLOC_F enabled when calling spl_early_ini() from board_init_f in SPL. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] AM3517 SPL fails with CONFIG_DM enabled
I am trying to add DM support in SPL along with device tree support similar to how it's being done for the omap3_logic boards. Unfortunately, I think something is going wrong in the initialization with CONFIG_DM enabled for SPL because I get no text data, and it doesn't appear to boot. I tried enabling DM in SPL and using the older platdata method without success. I have disabled DM_SERIAL in SPL and tried enabling the serial debug stuff, and I get nothing. I don't have a debugger, so it's a bit more difficult to troubleshoot. The main difference between the am35 and omap3 is the memory controller, and I've tried to model the am35 after the omap3 boards I also maintain. I was hoping someone might have any suggestions on how to track down the issue. As of right now, I have OF_CONTROL working in U-Boot and with DM disabled in SPL, everything is good. adam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On Tue, May 14, 2019 at 02:57:40PM -0500, Joe Hershberger wrote: > Hi Tom, > > Tested on Travis... https://travis-ci.org/jhershbe/u-boot/builds/531963238 > > The following changes since commit 90176e3be63802bc8630bab651d169993f0f0763: > > Merge tag 'efi-2019-07-rc3' of git://git.denx.de/u-boot-efi (2019-05-13 > 07:13:28 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-net.git master > > for you to fetch changes up to ebb97ea86878e56daadcc2d5d063ed59a10b5744: > > eth: mtk-eth: fix incorrect read of phy-handle (2019-05-14 14:43:33 -0500) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-stm32 for v2019.07 (round 3)
On Tue, May 14, 2019 at 02:59:07PM +, Patrice CHOTARD wrote: > Hi Tom > > Please find the pull request for STM32 round 3 > > The following changes since commit a69120a0d7c8d4044cdaceea9eb03913ba4e49c7: > > Prepare v2019.07-rc1 (2019-04-29 21:54:04 -0400) > > are available in the git repository at: > > https://github.com/pchotard/u-boot.git tags/u-boot-stm32-mcu-20190514 > > for you to fetch changes up to 1aaac8e60042b1e132f84184cfd9aa0f1a4afdde: > > configs: stm32f469-disco: Disable PINCTRL_FULL flag (2019-05-06 > 11:15:16 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: kconfig: separate sysreset and firmware drivers from misc
Hi Simon > > This adds separate kconfig options for drivers/sysreset and > drivers/firmware. > > Up to now, CONFIG_SPL_DRIVERS_MISC_SUPPORT added drivers/misc to SPL > build but also added drivers/firmware and drivers/sysreset at the same > time. > > Since that is confusing, this patch adds CONFIG_SPL_SYSRESET_SUPPORT > for > drivers/sysreset and CONFIG_SPL_DRIVERS_FIRMWARE_SUPPORT for > drivers/firmware (and accordingly for the TPL options). > > To keep the binaries unchanged, this patch enables the 2 new options > on all boards where DRIVERS_MISC_SUPPORT has been enabled before. > > Signed-off-by: Simon Goldschmidt I have one compilation failed for one board (on latest master branch) arm: + stm32f746-disco +drivers/built-in.o: In function `do_reset': +drivers/sysreset/sysreset-uclass.c:113: multiple definition of `do_reset' +arch/arm/lib/built-in.o:arch/arm/lib/reset.c:30: first defined here +drivers/built-in.o: In function `reset_cpu': +drivers/sysreset/sysreset-uclass.c:107: multiple definition of `reset_cpu' +arch/arm/cpu/armv7m/built-in.o:arch/arm/cpu/armv7m/cpu.c:53: first defined here +make[2]: *** [spl/u-boot-spl] Error 1 +make[1]: *** [spl/u-boot-spl] Error 2 +make: *** [sub-make] Error 2 But you have perhaps other patch in your branch... => for me select SPL_SYSRESET need to be removed for config STM32F7 to avoid driver/sysreset/uclass.c compilation For stm32mp and stm32: SPL_MISC needed for rcc SPL_SYSRESET are needed for only stm32mp1 cause compilation error for stm32 SPL_FIRMWARE is not needed but I will remove it when this patch will by merged. For the other part Reviewed-by: Patrick Delaunay Thanks, Patrick > --- > > arch/arm/mach-rockchip/Kconfig| 4 +++ > arch/arm/mach-rockchip/rk3288/Kconfig | 8 ++ > arch/arm/mach-stm32/Kconfig | 2 ++ > arch/arm/mach-stm32mp/Kconfig | 2 ++ > common/spl/Kconfig| 28 +++ > configs/B4420QDS_NAND_defconfig | 2 ++ > configs/B4860QDS_NAND_defconfig | 2 ++ > configs/C29XPCIE_NAND_defconfig | 2 ++ > configs/P1010RDB-PA_36BIT_NAND_defconfig | 4 +++ > configs/P1010RDB-PA_36BIT_SDCARD_defconfig| 2 ++ > configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 2 ++ > configs/P1010RDB-PA_NAND_defconfig| 4 +++ > configs/P1010RDB-PA_SDCARD_defconfig | 2 ++ > configs/P1010RDB-PA_SPIFLASH_defconfig| 2 ++ > configs/P1010RDB-PB_36BIT_NAND_defconfig | 4 +++ > configs/P1010RDB-PB_36BIT_SDCARD_defconfig| 2 ++ > configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 2 ++ > configs/P1010RDB-PB_NAND_defconfig| 4 +++ > configs/P1010RDB-PB_SDCARD_defconfig | 2 ++ > configs/P1010RDB-PB_SPIFLASH_defconfig| 2 ++ > configs/T1023RDB_NAND_defconfig | 2 ++ > configs/T1023RDB_SDCARD_defconfig | 2 ++ > configs/T1023RDB_SPIFLASH_defconfig | 2 ++ > configs/T1024QDS_NAND_defconfig | 2 ++ > configs/T1024QDS_SDCARD_defconfig | 2 ++ > configs/T1024QDS_SPIFLASH_defconfig | 2 ++ > configs/T1024RDB_NAND_defconfig | 2 ++ > configs/T1024RDB_SDCARD_defconfig | 2 ++ > configs/T1024RDB_SPIFLASH_defconfig | 2 ++ > configs/T1040D4RDB_NAND_defconfig | 2 ++ > configs/T1040D4RDB_SDCARD_defconfig | 2 ++ > configs/T1040D4RDB_SPIFLASH_defconfig | 2 ++ > configs/T1040RDB_NAND_defconfig | 2 ++ > configs/T1040RDB_SDCARD_defconfig | 2 ++ > configs/T1040RDB_SPIFLASH_defconfig | 2 ++ > configs/T1042D4RDB_NAND_defconfig | 2 ++ > configs/T1042D4RDB_SDCARD_defconfig | 2 ++ > configs/T1042D4RDB_SPIFLASH_defconfig | 2 ++ > .../T1042RDB_PI_NAND_SECURE_BOOT_defconfig| 2 ++ > configs/T1042RDB_PI_NAND_defconfig| 2 ++ > configs/T1042RDB_PI_SDCARD_defconfig | 2 ++ > configs/T1042RDB_PI_SPIFLASH_defconfig| 2 ++ > configs/T2080QDS_NAND_defconfig | 2 ++ > configs/T2080QDS_SDCARD_defconfig | 2 ++ > configs/T2080QDS_SPIFLASH_defconfig | 2 ++ > configs/T2080RDB_NAND_defconfig | 2 ++ > configs/T2080RDB_SDCARD_defconfig | 2 ++ > configs/T2080RDB_SPIFLASH_defconfig | 2 ++ > configs/T2081QDS_NAND_defconfig | 2 ++ > configs/T2081QDS_SDCARD_defconfig | 2 ++ > configs/T2081QDS_SPIFLASH_defconfig | 2 ++ > configs/T4160QDS_NAND_defconfig | 2 ++ > configs/T4160QDS_SDCARD_defconfig | 2 ++ > configs/T4240QDS_NAND_defconfig | 2 ++ > configs/T4240QDS_SDCARD_defconfig | 2 ++ > configs/T4240RDB_SDCARD_defconfig | 2 ++ > configs/am335x_guardian_defconfig | 2 ++ > configs/am43xx_evm_defconfig
[U-Boot] [PATCH] Kconfig: fix FIT offset prompt text
The current prompt text for FIT external offset is identical to SYS_TEXT_BASE which might confuse the users. Provided more accurate description for the prompt text. Signed-off-by: Ibai Erkiaga --- Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index 91c1082..f490ee4 100644 --- a/Kconfig +++ b/Kconfig @@ -278,7 +278,7 @@ config FIT if FIT config FIT_EXTERNAL_OFFSET - hex "Text Base" + hex "FIT External Offset" default 0x0 help This specifies a data offset in fit image. -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] arm: mach-stm32mp: Add newline to the MAC error message
Hi Manivannan,
>
> Without newline, the error message appears for non prgrammed OTP boards
> looks messsy. Hence add it to look more clean.
>
> Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Patrick Delaunay
Thanks
> ---
> arch/arm/mach-stm32mp/cpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c index
> 7b4431c9c75..e1a0a136809 100644
> --- a/arch/arm/mach-stm32mp/cpu.c
> +++ b/arch/arm/mach-stm32mp/cpu.c
> @@ -481,7 +481,7 @@ static int setup_mac_address(void)
> enetaddr[i] = ((uint8_t *)&otp)[i];
>
> if (!is_valid_ethaddr(enetaddr)) {
> - pr_err("invalid MAC address in OTP %pM", enetaddr);
> + pr_err("invalid MAC address in OTP %pM\n", enetaddr);
> return -EINVAL;
> }
> pr_debug("OTP MAC address = %pM\n", enetaddr);
> --
> 2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] board: stm32mp1: Add Avenger96 board support
Hi Manivannan,
>
> Add support for Avenger96 board from Arrow Electronics based on STM32MP157
> MPU. This board is one of the Consumer Edition (CE) boards of the 96Boards
> family and has the following features:
>
> SoC: STM32MP157AAC
> PMIC: STPMIC1A
> RAM: 1024 Mbyte @ 533MHz
> Storage: eMMC v4.51: 8 Gbyte
> microSD Socket: UHS-1 v3.01
> Ethernet Port: 10/100/1000 Mbit/s, IEEE 802.3 Compliant
> Wireless: WiFi 5 GHz & 2.4GHz IEEE 802.11a/b/g/n/ac
> Bluetooth®v4.2 (BR/EDR/BLE)
> USB: 2x Type A (USB 2.0) Host and 1x Micro B (USB 2.0) OTG
> Display: HDMI: WXGA (1366x768)@ 60 fps, HDMI 1.4
> LED: 4x User LED, 1x WiFi LED, 1x BT LED
>
> More information about this board can be found in 96Boards website:
> https://www.96boards.org/product/avenger96/
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> arch/arm/dts/Makefile | 1 +
> .../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 191 +
> arch/arm/dts/stm32mp157a-avenger96.dts| 362 ++
> board/st/stm32mp1/README | 23 ++
> 4 files changed, 577 insertions(+)
> create mode 100644 arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> create mode 100644 arch/arm/dts/stm32mp157a-avenger96.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> b4dc57edbd1..97a182f3abc 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -711,6 +711,7 @@ dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
>
> dtb-$(CONFIG_TARGET_STM32MP1) += \
> stm32mp157a-dk1.dtb \
> + stm32mp157a-avenger96.dtb \
> stm32mp157c-dk2.dtb \
> stm32mp157c-ed1.dtb \
> stm32mp157c-ev1.dtb
Minor, board added not in alphabetical oder
dtb-$(CONFIG_TARGET_STM32MP1) += \
stm32mp157a-avenger96.dtb \
stm32mp157a-dk1.dtb \
stm32mp157c-dk2.dtb \
stm32mp157c-ed1.dtb \
stm32mp157c-ev1.dtb
> diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> new file mode 100644
> index 000..1ff681afb87
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
> @@ -0,0 +1,191 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +/*
> + * Copyright : STMicroelectronics 2018
> + *
> + * Copyright (C) Linaro Ltd 2019 - All Rights Reserved
> + * Author: Manivannan Sadhasivam
> + */
> +
> +#include
> +#include "stm32mp157-u-boot.dtsi"
> +#include "stm32mp15-ddr3-2x4Gb-1066-binG.dtsi"
> +
> +/ {
> + aliases {
> + mmc0 = &sdmmc1;
> + mmc1 = &sdmmc2;
> + usb0 = &usbotg_hs;
> + };
> +
> + config {
> + u-boot,boot-led = "led1";
> + u-boot,error-led = "led4";
> + };
> +};
> +
> +&i2c4 {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&i2c4_pins_a {
> + u-boot,dm-pre-reloc;
> + pins {
> + u-boot,dm-pre-reloc;
> + };
> +};
> +
> +&pmic {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&rcc {
> + st,clksrc = <
> + CLK_MPU_PLL1P
> + CLK_AXI_PLL2P
> + CLK_MCU_PLL3P
> + CLK_PLL12_HSE
> + CLK_PLL3_HSE
> + CLK_PLL4_HSE
> + CLK_RTC_LSE
> + CLK_MCO1_DISABLED
> + CLK_MCO2_DISABLED
> + >;
> +
> + st,clkdiv = <
> + 1 /*MPU*/
> + 0 /*AXI*/
> + 0 /*MCU*/
> + 1 /*APB1*/
> + 1 /*APB2*/
> + 1 /*APB3*/
> + 1 /*APB4*/
> + 2 /*APB5*/
> + 23 /*RTC*/
> + 0 /*MCO1*/
> + 0 /*MCO2*/
> + >;
> +
> + st,pkcs = <
> + CLK_CKPER_HSE
> + CLK_FMC_ACLK
> + CLK_QSPI_ACLK
> + CLK_ETH_DISABLED
> + CLK_SDMMC12_PLL4P
> + CLK_DSI_DSIPLL
> + CLK_STGEN_HSE
> + CLK_USBPHY_HSE
> + CLK_SPI2S1_PLL3Q
> + CLK_SPI2S23_PLL3Q
> + CLK_SPI45_HSI
> + CLK_SPI6_HSI
> + CLK_I2C46_HSI
> + CLK_SDMMC3_PLL4P
> + CLK_USBO_USBPHY
> + CLK_ADC_CKPER
> + CLK_CEC_LSE
> + CLK_I2C12_HSI
> + CLK_I2C35_HSI
> + CLK_UART1_HSI
> + CLK_UART24_HSI
> + CLK_UART35_HSI
> + CLK_UART6_HSI
> + CLK_UART78_HSI
> + CLK_SPDIF_PLL4P
> + CLK_FDCAN_PLL4Q
> + CLK_SAI1_PLL3Q
> + CLK_SAI2_PLL3Q
> + CLK_SAI3_PLL3Q
> + CLK_SAI4_PLL3Q
> + CLK_RNG1_LSI
> + CLK_RNG2_LSI
> + CLK_LPTIM1_PCLK1
> + CLK_LPTIM23_PCLK3
> + CLK_LPTIM45_LSE
> + >;
> +
> + /* VCO = 1300.0 MHz => P = 650 (CPU) */
> + pll1: st,pll@0 {
> + cfg = < 2 80 0 0 0 PQR(1,0,0) >;
> + frac = < 0x800 >;
> + u-boot,dm-pre-reloc;
> + };
> +
> + /* VCO = 1066.0 MHz => P = 266 (A
Re: [U-Boot] [PATCH v2 1/3] arm: dts: stm32mp157: Add missing pinctrl definitions
Hi Manivannan,
>
> Add missing pinctrl definitions for STM32MP157.
>
> Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Patrick Delaunay
Thanks
> ---
> arch/arm/dts/stm32mp157-pinctrl.dtsi | 63
> 1 file changed, 63 insertions(+)
>
> diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi b/arch/arm/dts/stm32mp157-
> pinctrl.dtsi
> index 0aae69b0a04..200d2c00c5f 100644
> --- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
> @@ -220,6 +220,16 @@
> };
> };
>
> + i2c1_pins_b: i2c1-1 {
> + pins {
> + pinmux = AF5)>, /* I2C1_SCL */
> + ;
> /* I2C1_SDA */
> + bias-disable;
> + drive-open-drain;
> + slew-rate = <0>;
> + };
> + };
> +
> i2c2_pins_a: i2c2-0 {
> pins {
> pinmux = ,
> /* I2C2_SCL */ @@ -230,6 +240,16 @@
> };
> };
>
> + i2c2_pins_b: i2c2-1 {
> + pins {
> + pinmux = ,
> /* I2C2_SCL */
> + ;
> /* I2C2_SDA */
> + bias-disable;
> + drive-open-drain;
> + slew-rate = <0>;
> + };
> + };
> +
> i2c5_pins_a: i2c5-0 {
> pins {
> pinmux = AF4)>, /* I2C5_SCL */ @@ -375,6 +395,21 @@
> };
> };
>
> + spi2_pins_a: spi2-0 {
> + pins1 {
> + pinmux = AF5)>, /* SPI2_SCK */
> + , /*
> SPI2_NSS */
> + ; /*
> SPI2_MOSI */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <3>;
> + };
> + pins2 {
> + pinmux = ;
> /* SPI2_MISO */
> + bias-disable;
> + };
> + };
> +
> stusb1600_pins_a: stusb1600-0 {
> pins {
> pinmux = ANALOG)>; @@ -395,6 +430,34 @@
> };
> };
>
> + uart4_pins_b: uart4-1 {
> + pins1 {
> + pinmux = ;
> /* UART4_TX */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins2 {
> + pinmux = ;
> /* UART4_RX */
> + bias-disable;
> + };
> + };
> +
> + uart7_pins_a: uart7-0 {
> + pins1 {
> + pinmux = ;
> /* UART4_TX */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins2 {
> + pinmux = ,
> /* UART4_RX */
> + ,
> /* UART4_CTS */
> + ; /*
> UART4_RTS */
> + bias-disable;
> + };
> + };
> +
> usbotg_hs_pins_a: usbotg_hs-0 {
> pins {
> pinmux = ANALOG)>; /* OTG_ID */
> --
> 2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] riscv: Add Microchip MPFS Icicle board support
On Mon, May 13, 2019 at 6:52 PM Padmarao Begari wrote: > > This patch adds Microchip MPFS Icicle board support. > For now, NS16550 serial driver is only enabled. > The Microchip MPFS Icicle defconfig by default builds > U-Boot for M-Mode with SMP support. > > Signed-off-by: Padmarao Begari > --- > Changes in v3 > - Fix some typos > - Remove CONFIG_DM, CONFIG_DM_SERIAL, CONFIG_BAUDRATE, > CONFIG_SYS_NS16550, CONFIG_SYS_TEXT_BASE and CONFIG_NR_DRAM_BANKS > from microchip_mpfs_icicle_defconfig > - Add config SYS_TEXT_BASE in board kconfig > - Imply SYS_NS16550 in BOARD_SPECIFIC_OPTIONS > - select BOARD_EARLY_INIT_F in BOARD_SPECIFIC_OPTIONS > > Changes in v2 > - Fix some typos > - Rename target board to TARGET_MICROCHIP_ICICLE > - select CONFIG_BOARD_EARLY_INIT_F in BOARD_SPECIFIC_OPTIONS > - Remove #ifdef CONFIG_BOARD_EARLY_INIT_F > --- > arch/riscv/Kconfig| 4 ++ > board/microchip/mpfs_icicle/Kconfig | 26 + > board/microchip/mpfs_icicle/MAINTAINERS | 7 > board/microchip/mpfs_icicle/Makefile | 7 > board/microchip/mpfs_icicle/mpfs_icicle.c | 30 +++ > configs/microchip_mpfs_icicle_defconfig | 9 + > include/configs/microchip_mpfs_icicle.h | 63 > +++ > 7 files changed, 146 insertions(+) > create mode 100644 board/microchip/mpfs_icicle/Kconfig > create mode 100644 board/microchip/mpfs_icicle/MAINTAINERS > create mode 100644 board/microchip/mpfs_icicle/Makefile > create mode 100644 board/microchip/mpfs_icicle/mpfs_icicle.c > create mode 100644 configs/microchip_mpfs_icicle_defconfig > create mode 100644 include/configs/microchip_mpfs_icicle.h > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] x86: qemu-x86_64: Enable NVMe
NVMe was turned on in qemu-x86 but somehow we missed it for 64-bit. Signed-off-by: Bin Meng --- configs/qemu-x86_64_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig index 3ffcb4a..d8792d6 100644 --- a/configs/qemu-x86_64_defconfig +++ b/configs/qemu-x86_64_defconfig @@ -63,6 +63,7 @@ CONFIG_SPL_REGMAP=y CONFIG_SYSCON=y CONFIG_SPL_SYSCON=y CONFIG_CPU=y +CONFIG_NVME=y CONFIG_SPL_DM_RTC=y CONFIG_SPI=y CONFIG_SPL_TIMER=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] riscv: qemu: Enable PCI host ECAM generic driver
QEMU 4.0.0 'virt' target integrates a generic ECAM PCI host. Enable the driver for it. Signed-off-by: Bin Meng --- board/emulation/qemu-riscv/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig index 20ea6dc..2a03e43 100644 --- a/board/emulation/qemu-riscv/Kconfig +++ b/board/emulation/qemu-riscv/Kconfig @@ -36,5 +36,9 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply OF_BOARD_SETUP imply SIFIVE_SERIAL imply SMP + imply PCI + imply DM_PCI + imply PCIE_ECAM_GENERIC + imply CMD_PCI endif -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] riscv: qemu: Enable e1000 and nvme support
Since we have added the PCI support to the 'virt' target, enable e1000 and NVME as alternate network and storage devices for these virtio based devices. Signed-off-by: Bin Meng --- board/emulation/qemu-riscv/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig index 2a03e43..7f9a74d 100644 --- a/board/emulation/qemu-riscv/Kconfig +++ b/board/emulation/qemu-riscv/Kconfig @@ -40,5 +40,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply DM_PCI imply PCIE_ECAM_GENERIC imply CMD_PCI + imply E1000 + imply NVME endif -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] nvme: Fix warning of cast from pointer to integer of different size
When dma_addr_t is u32 in 64-bit, there are some warnings when building NVME driver. Fix it by doing an additional (long) cast. Signed-off-by: Bin Meng --- drivers/nvme/nvme.c | 4 ++-- drivers/nvme/nvme_show.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c index 1ee0a0a..d4965e2 100644 --- a/drivers/nvme/nvme.c +++ b/drivers/nvme/nvme.c @@ -577,7 +577,7 @@ static int nvme_get_info_from_identify(struct nvme_dev *dev) int ret; int shift = NVME_CAP_MPSMIN(dev->cap) + 12; - ret = nvme_identify(dev, 0, 1, (dma_addr_t)ctrl); + ret = nvme_identify(dev, 0, 1, (dma_addr_t)(long)ctrl); if (ret) return -EIO; @@ -646,7 +646,7 @@ static int nvme_blk_probe(struct udevice *udev) ns->dev = ndev; /* extract the namespace id from the block device name */ ns->ns_id = trailing_strtol(udev->name) + 1; - if (nvme_identify(ndev, ns->ns_id, 0, (dma_addr_t)id)) + if (nvme_identify(ndev, ns->ns_id, 0, (dma_addr_t)(long)id)) return -EIO; flbas = id->flbas & NVME_NS_FLBAS_LBA_MASK; diff --git a/drivers/nvme/nvme_show.c b/drivers/nvme/nvme_show.c index 395b061..15e459d 100644 --- a/drivers/nvme/nvme_show.c +++ b/drivers/nvme/nvme_show.c @@ -111,14 +111,14 @@ int nvme_print_info(struct udevice *udev) ALLOC_CACHE_ALIGN_BUFFER(char, buf_ctrl, sizeof(struct nvme_id_ctrl)); struct nvme_id_ctrl *ctrl = (struct nvme_id_ctrl *)buf_ctrl; - if (nvme_identify(dev, 0, 1, (dma_addr_t)ctrl)) + if (nvme_identify(dev, 0, 1, (dma_addr_t)(long)ctrl)) return -EIO; print_optional_admin_cmd(le16_to_cpu(ctrl->oacs), ns->devnum); print_optional_nvm_cmd(le16_to_cpu(ctrl->oncs), ns->devnum); print_format_nvme_attributes(ctrl->fna, ns->devnum); - if (nvme_identify(dev, ns->ns_id, 0, (dma_addr_t)id)) + if (nvme_identify(dev, ns->ns_id, 0, (dma_addr_t)(long)id)) return -EIO; print_formats(id, ns); -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework
On Tue, May 07, 2019 at 12:25:33PM -0500, Andreas Dannenberg wrote: > Introduce a framework that allows loading the System Firmware (SYSFW) > binary as well as the associated configuration data from an image tree > blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC > RAW mode partition or sector. > > To simplify the handling of and loading from the different boot media > we tap into the existing U-Boot SPL framework usually used for loading > U-Boot by building on an earlier commit that exposes some of that > functionality. > > Note that this initial implementation only supports FS and RAW-based > eMMC/SD card boot. [snip] > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig > index e677a2e01b..f1731dda58 100644 > --- a/arch/arm/mach-k3/Kconfig > +++ b/arch/arm/mach-k3/Kconfig > @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID > int > default 16 > > +config K3_LOAD_SYSFW > + bool > + depends on SPL > + default n 'n' is already default, you can drop this. [snip] > +config K3_SYSFW_IMAGE_SIZE_MAX > + int "Amount of memory dynamically allocated for loading SYSFW blob" > + depends on K3_LOAD_SYSFW > + default 269000 > + help > + Amount of memory reserved through dynamic allocation at runtime for > + loading the combined System Firmware and configuration image tree > + blob. Keep it as tight as possible, as this directly affects the > + overall SPL memory footprint. This is missing a unit, and is 'int' really the best choice here (and really, I guess, 262.6KiB as a default) ? [snip] > diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile > index 0c3a4f7db1..6c895400c2 100644 > --- a/arch/arm/mach-k3/Makefile > +++ b/arch/arm/mach-k3/Makefile > @@ -7,4 +7,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o > obj-$(CONFIG_ARM64) += arm64-mmu.o > obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o > obj-$(CONFIG_TI_SECURE_DEVICE) += security.o > +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o > obj-y += common.o [snip] > diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c > new file mode 100644 > index 00..a66c27 > --- /dev/null > +++ b/arch/arm/mach-k3/sysfw-loader.c > @@ -0,0 +1,263 @@ [snip] > +#ifdef CONFIG_SPL_BUILD [snip of the whole body of the file] > +#endif We should be using something else in the Makefile, typically: obj-$(CONFIG_SPL_BUILD) += sysfw-loader.o should work. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/13] spl: Allow skipping clearing BSS during relocation
On Tue, May 07, 2019 at 12:25:31PM -0500, Andreas Dannenberg wrote: > On some platform we have sufficient memory available early on to allow > setting up and using a basic BSS prior to relocation. In order to be > able to preserve data written to BSS during early startup add a Kconfig > option allowing to skip the clearing of the BSS section during setting > up of the final environment / relocation. > > Signed-off-by: Andreas Dannenberg Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/13] spl: Make image loader infrastructure more universal
On Tue, May 07, 2019 at 12:25:32PM -0500, Andreas Dannenberg wrote: > The current U-Boot SPL image loader infrastructure is very powerful, > able to initialize and load from a variety of boot media however it > is strongly geared towards loading specific types of images in a very > specific way. To address the need being able to use this infrastructure > to load arbitrary image files go ahead and refactor it as follows: > > - Refactor existing spl_mmc_load_image function into superset function, > accepting additional arguments such as filenames and media load offset > (same concept can also be applied toother spl_XXX_load_image functions) > - Extend the loader function to "remember" their peripheral initialization > status so that the init is only done once during the boot process, > - Extend the FIT image loading function to allow skipping the parsing/ > processing of the FIT contents (so that this can be done separately > in a more customized fashion) > - Populate the SPL_LOAD_IMAGE_METHOD() list with a trampoline function, > invoking the newly refactored superset functions in a way to maintain > compatibility with the existing behavior > > This refactoring initially covers MMC/SD card loading (RAW and FS-based). > > Signed-off-by: Andreas Dannenberg Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] System Firmware Loader for TI K3 family SoCs
On Tue, May 07, 2019 at 12:25:29PM -0500, Andreas Dannenberg wrote: > TI K3 SoCs like the AM654x devices are fundamentally dependent on a > firmware called SYSFW (System Firmware) being loaded into the dedicated > DMSC (Device Management and Security Controller) processor to provide > various services via TISCI (Texas Instruments System Control Interface) > to manage device aspects such as core bringup, power, clocks, security, > and so on across the entire SoC. [snip] > While I also have a working solution based on the existing FS loader > framework this has its own challenges, namely by its very nature only > addressing a subset of our use cases (no eMMC/SD RAW boot support for > example), being heavier on resource usage (needing to use ENV to pass > parameters), and not addressing the need to probe the boot peripheral. > This particular framework works well for use cases requiring to load > firmware from FS-based media once DDR is up and U-Boot is in a more > "initialized" state but it is not a one-fits all solution for very > early use in SPL board_init_f() accross different boot modes. I think one thing that might help here is to post this alternative solution and provide the 'size' information for both series. In addition, build something like am335x_evm and socfpga_stratix10 for both series and include their before/after 'size' info too. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/13] mmc: k3_arasan: Allow driver to probe without PDs specified
On Tue, May 07, 2019 at 12:25:30PM -0500, Andreas Dannenberg wrote: > We would like to use the driver even without power domains being > specified for cases such as during early boot when the required power > domains have already gotten enabled by the SoC's boot ROM and such > explicit initialization is not needed and possible. > > Signed-off-by: Andreas Dannenberg Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On Fri, May 10, 2019 at 09:50:45PM +, Joe Hershberger wrote: > Hi Vladimir and Tom, > > On Thu, May 9, 2019 at 7:51 AM Vladimir Oltean > wrote: > > > > On 09.05.2019 02:05, Vladimir Oltean wrote: > > > On 5/9/19 1:55 AM, Tom Rini wrote: > > >> On Wed, May 08, 2019 at 10:52:28PM +, Vladimir Oltean wrote: > > >>> On 5/9/19 1:48 AM, Tom Rini wrote: > > On Wed, May 08, 2019 at 10:45:50PM +, Vladimir Oltean wrote: > > > On 5/9/19 1:42 AM, Tom Rini wrote: > > >> On Wed, May 08, 2019 at 10:40:57PM +, Vladimir Oltean wrote: > > >>> On 5/9/19 1:24 AM, Joe Hershberger wrote: > > On Tue, May 7, 2019 at 5:15 PM Joe Hershberger > > wrote: > > > > > > Hi Tom, > > > > > > The following changes since commit > > > 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980: > > > > > > I rebased on your master and built for BB Black. DHCP seems to > > > work fine. > > > MLO also now fits again. > > > > > >Merge branch 'master' of git://git.denx.de/u-boot-sh > > > (2019-05-07 09:38:00 -0400) > > > > > > are available in the git repository at: > > > > > >git://git.denx.de/u-boot-net.git master > > > > > > for you to fetch changes up to > > > 8d0c6858455e89b089222a08d55ff711681ca011: > > > > > >net: phy: micrel: Find Micrel PHY node correctly > > > (2019-05-07 14:51:55 -0500) > > > > > > > > > Carlo Caione (4): > > >net: phy: Add generic helpers to access MMD PHY > > > registers > > >net: phy: ti: use generic helpers to access MMD > > > registers > > >cmd: mdio: Switch to generic helpers when accessing > > > the registers > > >net: phy: realtek: Introduce quirk to mark RXC not > > > stoppable > > > > > > James Byrne (2): > > >net: phy: micrel: Use correct skew values on KSZ9021 > > >net: phy: micrel: Find Micrel PHY node correctly > > > > > > Murali Karicheri (2): > > >ARM: k2g-gp-evm: update to rgmii pinmux configuration > > >ARM: k2g-ice: Add pinmux support for rgmii interface > > > > > > Pankaj Bansal (1): > > >drivers: net: ldpaa_eth: fix resource leak > > > > > > Siva Durga Prasad Paladugu (2): > > >net: phy: Reloc next and prev pointers inside > > > phy_drivers > > >net: phy: Fix return value check phy_probe > > > > > > Valentin-catalin Neacsu (1): > > >net: phy: aquantia: Set only autoneg on in register > > > 4.c441 > > > > > > Vladimir Oltean (6): > > >net: phy: ar803x: Address packet drops at low traffic > > > rate due to SmartEEE feature > > >net: phy: ar803x: Make RGMII Tx delays actually > > > configurable for AR8035 > > >net: phy: ar803x: Use common functions for RGMII > > > internal delays > > >net: phy: ar803x: Clarify the configuration of the > > > CLK_25M output pin > > >net: phy: ar803x: Explicitly disable RGMII delays > > > > Tom, this [1] is the patch that is breaking the evm. It doesn't > > affect > > BB Black because it uses an SMSC phy, where as this evm uses an > > AR8031/AR8033. > > > > Is it possible the device tree [2] is wrong for the board? It lists > > 'phy-mode = "rgmii-txid";', so that means that with this patch the > > RX > > delay is now being disabled. > > > > Any thoughts, Vladimir? > > > > Thanks, > > -Joe > > > > [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII > > delays" > > [2] arch/arm/dts/am335x-evm.dts > > > > >net: phy: ar803x: Clarify the intention of > > > ar8021_config > > > > > > arch/arm/dts/sama5d3xcm.dtsi| 32 +++--- > > > arch/arm/dts/sama5d3xcm_cmp.dtsi| 32 +++--- > > > arch/arm/dts/socfpga_arria5_socdk.dts | 4 +- > > > arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +- > > > arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +- > > > arch/arm/dts/socfpga_cyclone5_sockit.dts| 4 +- > > > arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +- > > > board/ti/ks2_evm/mux-k2g.h | 36 > > > +++ > >
Re: [U-Boot] [PATCH v6] ARM: am335x: Add phyCORE AM335x R2 support
On Wed, May 08, 2019 at 01:22:44PM +0200, Niel Fourie wrote:
> Support for Phytech phyCORE AM335x R2 SOM (PCL060) on the Phytec
> phyBOARD-Wega AM335x.
>
> CPU : AM335X-GP rev 2.1
> Model: Phytec AM335x phyBOARD-WEGA
> DRAM: 256 MiB
> NAND: 256 MiB
> MMC: OMAP SD/MMC: 0
> eth0: ethernet@4a10
>
> Working:
> - Eth0
> - i2C
> - MMC/SD
> - NAND
> - UART
> - USB (host)
>
> Device trees were taken from Linux mainline:
> commit 37624b58542f ("Linux 5.1-rc7")
>
> Signed-off-by: Niel Fourie
> Reviewed-by: Heiko Schocher
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/7] pcie: ti: add driver for AM65x PCIe RC
Add driver supporting PCIe root-complex available on TI's AM65x SoC. Signed-off-by: Sekhar Nori --- drivers/pci/Kconfig | 6 + drivers/pci/Makefile | 1 + drivers/pci/pcie_dw_ti.c | 725 +++ 3 files changed, 732 insertions(+) create mode 100644 drivers/pci/pcie_dw_ti.c diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 1521885bdeb2..dc6c6957239b 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -121,4 +121,10 @@ config PCI_MVEBU Say Y here if you want to enable PCIe controller support on Armada XP/38x SoCs. +config PCI_KEYSTONE + bool "TI Keystone PCIe controller" + depends on DM_PCI + help + Say Y here if you want to enable PCI controller support on AM654 SoC. + endif diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index 492364189594..d3a363533391 100644 --- a/drivers/pci/Makefile +++ b/drivers/pci/Makefile @@ -34,3 +34,4 @@ obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape.o obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape_fixup.o obj-$(CONFIG_PCI_XILINX) += pcie_xilinx.o obj-$(CONFIG_PCIE_INTEL_FPGA) += pcie_intel_fpga.o +obj-$(CONFIG_PCI_KEYSTONE) += pcie_dw_ti.o diff --git a/drivers/pci/pcie_dw_ti.c b/drivers/pci/pcie_dw_ti.c new file mode 100644 index ..b37fc2de7fb8 --- /dev/null +++ b/drivers/pci/pcie_dw_ti.c @@ -0,0 +1,725 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Texas Instruments, Inc + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +#define PCIE_VENDORID_MASK GENMASK(15, 0) +#define PCIE_DEVICEID_SHIFT16 + +/* PCI DBICS registers */ +#define PCIE_CONFIG_BAR0 0x10 +#define PCIE_LINK_STATUS_REG 0x80 +#define PCIE_LINK_STATUS_SPEED_OFF 16 +#define PCIE_LINK_STATUS_SPEED_MASK(0xf << PCIE_LINK_STATUS_SPEED_OFF) +#define PCIE_LINK_STATUS_WIDTH_OFF 20 +#define PCIE_LINK_STATUS_WIDTH_MASK(0xf << PCIE_LINK_STATUS_WIDTH_OFF) + +#define PCIE_LINK_CAPABILITY 0x7c +#define PCIE_LINK_CTL_20xa0 +#define TARGET_LINK_SPEED_MASK 0xf +#define LINK_SPEED_GEN_1 0x1 +#define LINK_SPEED_GEN_2 0x2 +#define LINK_SPEED_GEN_3 0x3 + +#define PCIE_MISC_CONTROL_1_OFF0x8bc +#define PCIE_DBI_RO_WR_EN BIT(0) + +#define PLR_OFFSET 0x700 +#define PCIE_PORT_DEBUG0 (PLR_OFFSET + 0x28) +#define PORT_LOGIC_LTSSM_STATE_MASK0x1f +#define PORT_LOGIC_LTSSM_STATE_L0 0x11 + +#define PCIE_LINK_WIDTH_SPEED_CONTROL 0x80c +#define PORT_LOGIC_SPEED_CHANGE(0x1 << 17) + +#define PCIE_LINK_UP_TIMEOUT_MS100 + +/* + * iATU Unroll-specific register definitions + * From 4.80 core version the address translation will be made by unroll. + * The registers are offset from atu_base + */ +#define PCIE_ATU_UNR_REGION_CTRL1 0x00 +#define PCIE_ATU_UNR_REGION_CTRL2 0x04 +#define PCIE_ATU_UNR_LOWER_BASE0x08 +#define PCIE_ATU_UNR_UPPER_BASE0x0c +#define PCIE_ATU_UNR_LIMIT 0x10 +#define PCIE_ATU_UNR_LOWER_TARGET 0x14 +#define PCIE_ATU_UNR_UPPER_TARGET 0x18 + +#define PCIE_ATU_REGION_INDEX1 (0x1 << 0) +#define PCIE_ATU_REGION_INDEX0 (0x0 << 0) +#define PCIE_ATU_TYPE_MEM (0x0 << 0) +#define PCIE_ATU_TYPE_IO (0x2 << 0) +#define PCIE_ATU_TYPE_CFG0 (0x4 << 0) +#define PCIE_ATU_TYPE_CFG1 (0x5 << 0) +#define PCIE_ATU_ENABLE(0x1 << 31) +#define PCIE_ATU_BAR_MODE_ENABLE (0x1 << 30) +#define PCIE_ATU_BUS(x)(((x) & 0xff) << 24) +#define PCIE_ATU_DEV(x)(((x) & 0x1f) << 19) +#define PCIE_ATU_FUNC(x) (((x) & 0x7) << 16) + +/* Register address builder */ +#define PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(region) ((region) << 9) + +/* Offsets from App base */ +#define PCIE_CMD_STATUS0x04 +#define LTSSM_EN_VAL BIT(0) + +/* Parameters for the waiting for iATU enabled routine */ +#define LINK_WAIT_MAX_IATU_RETRIES 5 +#define LINK_WAIT_IATU 1 + +#define AM654_PCIE_DEV_TYPE_MASK 0x3 +#define EP 0x0 +#define LEG_EP 0x1 +#define RC 0x2 + +/** + * struct pcie_dw_ti - TI DW PCIe controller state + * + * @app_base: The base address of application register space + * @dbics_base: The base address of dbics register space + * @cfg_base: The base address of configuration space + * @atu_base: The base address of ATU space + * @cfg_size: The size of the configuration space which is needed + *as it gets written into the PCIE_ATU_LIMIT register + * @first_busno: This driver supports multiple PCIe controllers. + *
[U-Boot] [PATCH 5/7] configs: am65x_evm_a53: enable PCIe support
Enable support for PCIe and related configurations on AM654 EVM platform. Signed-off-by: Sekhar Nori --- configs/am65x_evm_a53_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index 41cf0100fa3a..7745e2038790 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -31,6 +31,7 @@ CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_ASKENV=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_MMC=y +CONFIG_CMD_PCI=y CONFIG_CMD_REMOTEPROC=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIME=y @@ -58,6 +59,11 @@ CONFIG_K3_SEC_PROXY=y CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_K3_ARASAN=y +CONFIG_PHY=y +CONFIG_PCI=y +CONFIG_DM_PCI=y +CONFIG_PCI_KEYSTONE=y +CONFIG_AM654_PHY=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set CONFIG_SPL_PINCTRL=y -- 2.16.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 7/7] configs: am65x_evm_a53: enable support for PCIe ethernet cards
Enable support for Intel E1000 based PCIe ethernet cards that can be used to test PCIe RC functionality on AM65x EVM. Signed-off-by: Sekhar Nori --- configs/am65x_evm_a53_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index 7745e2038790..c1a04257769f 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -60,6 +60,9 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_K3_ARASAN=y CONFIG_PHY=y +CONFIG_DM_ETH=y +CONFIG_E1000=y +CONFIG_CMD_E1000=y CONFIG_PCI=y CONFIG_DM_PCI=y CONFIG_PCI_KEYSTONE=y -- 2.16.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/7] dm: core: add support for getting register address and size
Current dev_read_*() API lacks support to get address and size
of a "reg" property by name or index. Add support for the same.
Livetree support has been added but not tested.
Signed-off-by: Sekhar Nori
---
drivers/core/fdtaddr.c | 17 +
drivers/core/read.c| 20
include/dm/fdtaddr.h | 18 ++
include/dm/read.h | 41 +
4 files changed, 96 insertions(+)
diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
index c2873861dacd..6850003a287b 100644
--- a/drivers/core/fdtaddr.c
+++ b/drivers/core/fdtaddr.c
@@ -129,6 +129,23 @@ fdt_addr_t devfdt_get_addr_name(struct udevice *dev, const
char *name)
#endif
}
+fdt_addr_t devfdt_get_addr_size_name(struct udevice *dev, const char *name,
+fdt_size_t *size)
+{
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+ int index;
+
+ index = fdt_stringlist_search(gd->fdt_blob, dev_of_offset(dev),
+ "reg-names", name);
+ if (index < 0)
+ return index;
+
+ return devfdt_get_addr_size_index(dev, index, size);
+#else
+ return FDT_ADDR_T_NONE;
+#endif
+}
+
fdt_addr_t devfdt_get_addr(struct udevice *dev)
{
return devfdt_get_addr_index(dev, 0);
diff --git a/drivers/core/read.c b/drivers/core/read.c
index 6bda077a34b9..7c6944eeea84 100644
--- a/drivers/core/read.c
+++ b/drivers/core/read.c
@@ -82,6 +82,15 @@ fdt_addr_t dev_read_addr_index(struct udevice *dev, int
index)
return devfdt_get_addr_index(dev, index);
}
+fdt_addr_t dev_read_addr_size_index(struct udevice *dev, int index,
+ fdt_size_t *size)
+{
+ if (ofnode_is_np(dev_ofnode(dev)))
+ return ofnode_get_add_size_index(dev_ofnode(dev), index, size);
+ else
+ return devfdt_get_addr_size_index(dev, index, size);
+}
+
void *dev_remap_addr_index(struct udevice *dev, int index)
{
fdt_addr_t addr = dev_read_addr_index(dev, index);
@@ -102,6 +111,17 @@ fdt_addr_t dev_read_addr_name(struct udevice *dev, const
char *name)
return dev_read_addr_index(dev, index);
}
+fdt_addr_t dev_read_addr_size_name(struct udevice *dev, const char *name,
+ fdt_size_t *size)
+{
+ int index = dev_read_stringlist_search(dev, "reg-names", name);
+
+ if (index < 0)
+ return FDT_ADDR_T_NONE;
+ else
+ return dev_read_addr_size_index(dev, index, size);
+}
+
void *dev_remap_addr_name(struct udevice *dev, const char *name)
{
fdt_addr_t addr = dev_read_addr_name(dev, name);
diff --git a/include/dm/fdtaddr.h b/include/dm/fdtaddr.h
index 3bc2599b6cbd..57b326cb3362 100644
--- a/include/dm/fdtaddr.h
+++ b/include/dm/fdtaddr.h
@@ -120,4 +120,22 @@ fdt_addr_t devfdt_get_addr_size_index(struct udevice *dev,
int index,
*/
fdt_addr_t devfdt_get_addr_name(struct udevice *dev, const char *name);
+/**
+ * devfdt_get_addr_size_name() - Get the reg property and its size for a
device,
+ * indexed by name
+ *
+ * Returns the address and size specified in the 'reg' property of a device.
+ *
+ * @dev: Pointer to a device
+ * @name: the 'reg' property can hold a list of pairs, with the
+ * 'reg-names' property providing named-based identification. @index
+ * indicates the value to search for in 'reg-names'.
+ * @size: Pointer to size variable - this function returns the size
+ *specified in the 'reg' property here
+ *
+ * @return addr
+ */
+fdt_addr_t devfdt_get_addr_size_name(struct udevice *dev, const char *name,
+fdt_size_t *size);
+
#endif
diff --git a/include/dm/read.h b/include/dm/read.h
index 60b727cbd821..5c38fcc922ae 100644
--- a/include/dm/read.h
+++ b/include/dm/read.h
@@ -144,6 +144,19 @@ int dev_read_size(struct udevice *dev, const char
*propname);
*/
fdt_addr_t dev_read_addr_index(struct udevice *dev, int index);
+/**
+ * dev_read_addr_size_index() - Get the indexed reg property of a device
+ *
+ * @dev: Device to read from
+ * @index: the 'reg' property can hold a list of pairs
+ *and @index is used to select which one is required
+ * @size: place to put size value (on success)
+ *
+ * @return address or FDT_ADDR_T_NONE if not found
+ */
+fdt_addr_t dev_read_addr_size_index(struct udevice *dev, int index,
+ fdt_size_t *size);
+
/**
* dev_remap_addr_index() - Get the indexed reg property of a device
* as a memory-mapped I/O pointer
@@ -168,6 +181,20 @@ void *dev_remap_addr_index(struct udevice *dev, int index);
*/
fdt_addr_t dev_read_addr_name(struct udevice *dev, const char* name);
+/**
+ * dev_read_addr_size_name() - Get the reg property of a device, indexed by
name
+ *
+ * @dev: Device to read from
+ * @name: the 'reg' property can hold a list of pairs,
[U-Boot] [PATCH 6/7] arm: dts: k3-am65: add support for PCIe and SERDES
Add needed device-tree nodes to support PCIe 0
and SERDES on AM65x SoC. The nodes are kept
disabled by default.
Signed-off-by: Sekhar Nori
---
arch/arm/dts/k3-am65-main.dtsi | 108 +
arch/arm/dts/k3-am65.dtsi | 1 +
include/dt-bindings/phy/phy-am654-serdes.h | 13
3 files changed, 122 insertions(+)
create mode 100644 include/dt-bindings/phy/phy-am654-serdes.h
diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index adcd6341e40c..a564b277c357 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -5,6 +5,9 @@
* Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
*/
+#include
+#include
+
&cbass_main {
gic500: interrupt-controller@180 {
compatible = "arm,gic-v3";
@@ -69,4 +72,109 @@
clock-frequency = <4800>;
current-speed = <115200>;
};
+
+ scm_conf: scm_conf@10 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0 0x0010 0 0x1c000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x0010 0x1c000>;
+
+ serdes_mux: mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x4080 0x3>, /* SERDES0 lane select */
+ <0x4090 0x3>; /* SERDES1 lane select */
+ };
+
+ pcie0_mode: pcie-mode@4060 {
+ compatible = "syscon";
+ reg = <0x4060 0x4>;
+ };
+
+ pcie1_mode: pcie-mode@4070 {
+ compatible = "syscon";
+ reg = <0x4070 0x4>;
+ };
+
+ serdes0_clk: serdes_clk@4080 {
+ compatible = "syscon";
+ reg = <0x4080 0x4>;
+ };
+
+ serdes1_clk: serdes_clk@4090 {
+ compatible = "syscon";
+ reg = <0x4090 0x4>;
+ };
+
+ pcie_devid: pcie-devid@210 {
+ compatible = "syscon";
+ reg = <0x0210 0x4>;
+ };
+ };
+
+ serdes0: serdes@90 {
+ compatible = "ti,phy-am654-serdes";
+ reg = <0x0 0x90 0x0 0x2000>;
+ reg-names = "serdes";
+ #phy-cells = <2>;
+ power-domains = <&k3_pds 153>;
+ clocks = <&k3_clks 153 4>, <&k3_clks 153 1>, <&serdes1
AM654_SERDES_LO_REFCLK>;
+ clock-output-names = "serdes0_cmu_refclk", "serdes0_lo_refclk",
"serdes0_ro_refclk";
+ assigned-clocks = <&k3_clks 153 4>, <&serdes0
AM654_SERDES_CMU_REFCLK>;
+ assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>;
+ ti,serdes-clk = <&serdes0_clk>;
+ mux-controls = <&serdes_mux 0>;
+ #clock-cells = <1>;
+ };
+
+ serdes1: serdes@91 {
+ compatible = "ti,phy-am654-serdes";
+ reg = <0x0 0x91 0x0 0x2000>;
+ reg-names = "serdes";
+ #phy-cells = <2>;
+ power-domains = <&k3_pds 154>;
+ clocks = <&serdes0 AM654_SERDES_RO_REFCLK>, <&k3_clks 154 1>,
<&k3_clks 154 5>;
+ clock-output-names = "serdes1_cmu_refclk", "serdes1_lo_refclk",
"serdes1_ro_refclk";
+ assigned-clocks = <&k3_clks 154 5>, <&serdes1
AM654_SERDES_CMU_REFCLK>;
+ assigned-clock-parents = <&k3_clks 154 9>, <&k3_clks 154 5>;
+ ti,serdes-clk = <&serdes1_clk>;
+ mux-controls = <&serdes_mux 1>;
+ #clock-cells = <1>;
+ };
+
+ pcie0_rc: pcie@550 {
+ compatible = "ti,am654-pcie-rc";
+ reg = <0x0 0x550 0x0 0x1000>, <0x0 0x5501000 0x0 0x1000>,
<0x0 0x1000 0x0 0x2000>, <0x0 0x5506000 0x0 0x1000>;
+ reg-names = "app", "dbics", "config", "atu";
+ power-domains = <&k3_pds 120>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x8100 0 0 0x0 0x1002 0 0x0001
+ 0x8200 0 0x1003 0x0 0x1003 0
0x07FD>;
+ ti,syscon-pcie-id = <&pcie_devid>;
+ ti,syscon-pcie-mode = <&pcie0_mode>;
+ bus-range = <0x0 0xff>;
+ status = "disabled";
+ device_type = "pci";
+ num-lanes = <1>;
+ num-ob-windows = <16>;
+ num-viewport = <16>;
+ max-link-speed = <3>;
+ interrupts = ;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0
[U-Boot] [PATCH 4/7] phy: add support for AM654x SERDES
Add a new SERDES driver for TI's AM654x SoC which configures
the SERDES only for PCIe. Support fo USB3 can be added later.
SERDES in am654x has three input clocks (left input, external
reference clock and right input) and two output clocks (left
output and right output) in addition to a PLL mux clock which
the SERDES uses for Clock Multiplier Unit (CMU refclock).
The PLL mux clock can select from one of the three input
clocks. The right output can select between left input and
external reference clock while the left output can select
between the right input and external reference clock.
The driver has support to select PLL mux and left/right output
mux as specified in device tree.
Signed-off-by: Sekhar Nori
---
drivers/phy/Kconfig| 9 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-ti-am654.c | 411 +
3 files changed, 421 insertions(+)
create mode 100644 drivers/phy/phy-ti-am654.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 957efb3984bf..cce98448a4b5 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -102,6 +102,15 @@ config SPL_PIPE3_PHY
This PHY is found on omap devices supporting SATA such as dra7, am57x
and omap5
+config AM654_PHY
+ tristate "TI AM654 SERDES support"
+ depends on PHY && ARCH_K3
+ select REGMAP
+ select SYSCON
+ help
+ This option enables support for TI AM654 SerDes PHY used for
+ PCIe.
+
config STI_USB_PHY
bool "STMicroelectronics USB2 picoPHY driver for STiH407 family"
depends on PHY && ARCH_STI
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 90646ca55b9d..39da13c4c941 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_BCM6358_USBH_PHY) += bcm6358-usbh-phy.o
obj-$(CONFIG_BCM6368_USBH_PHY) += bcm6368-usbh-phy.o
obj-$(CONFIG_PHY_SANDBOX) += sandbox-phy.o
obj-$(CONFIG_$(SPL_)PIPE3_PHY) += ti-pipe3-phy.o
+obj-$(CONFIG_AM654_PHY) += phy-ti-am654.o
obj-$(CONFIG_STI_USB_PHY) += sti_usb_phy.o
obj-$(CONFIG_PHY_RCAR_GEN2) += phy-rcar-gen2.o
obj-$(CONFIG_PHY_RCAR_GEN3) += phy-rcar-gen3.o
diff --git a/drivers/phy/phy-ti-am654.c b/drivers/phy/phy-ti-am654.c
new file mode 100644
index ..39490124eabf
--- /dev/null
+++ b/drivers/phy/phy-ti-am654.c
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0+
+/**
+ * PCIe SERDES driver for AM654x SoC
+ *
+ * Copyright (C) 2018 Texas Instruments
+ * Author: Kishon Vijay Abraham I
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CMU_R07C 0x7c
+#define CMU_MASTER_CDN_O BIT(24)
+
+#define COMLANE_R138 0xb38
+#define CONFIG_VERSION_REG_MASKGENMASK(23, 16)
+#define CONFIG_VERSION_REG_SHIFT 16
+#define VERSION0x70
+
+#define COMLANE_R190 0xb90
+#define L1_MASTER_CDN_OBIT(9)
+
+#define COMLANE_R194 0xb94
+#define CMU_OK_I_0 BIT(19)
+
+#define SERDES_CTRL0x1fd0
+#define POR_EN BIT(29)
+
+#define WIZ_LANEXCTL_STS 0x1fe0
+#define TX0_ENABLE_OVL BIT(31)
+#define TX0_ENABLE_MASKGENMASK(30, 29)
+#define TX0_ENABLE_SHIFT 29
+#define TX0_DISABLE_STATE 0x0
+#define TX0_SLEEP_STATE0x1
+#define TX0_SNOOZE_STATE 0x2
+#define TX0_ENABLE_STATE 0x3
+#define RX0_ENABLE_OVL BIT(15)
+#define RX0_ENABLE_MASKGENMASK(14, 13)
+#define RX0_ENABLE_SHIFT 13
+#define RX0_DISABLE_STATE 0x0
+#define RX0_SLEEP_STATE0x1
+#define RX0_SNOOZE_STATE 0x2
+#define RX0_ENABLE_STATE 0x3
+
+#define WIZ_PLL_CTRL 0x1ff4
+#define PLL_ENABLE_OVL BIT(31)
+#define PLL_ENABLE_MASKGENMASK(30, 29)
+#define PLL_ENABLE_SHIFT 29
+#define PLL_DISABLE_STATE 0x0
+#define PLL_SLEEP_STATE0x1
+#define PLL_SNOOZE_STATE 0x2
+#define PLL_ENABLE_STATE 0x3
+#define PLL_OK BIT(28)
+
+#define PLL_LOCK_TIME 1000/* in milliseconds */
+#define SLEEP_TIME 100 /* in microseconds */
+
+#define LANE_USB3 0x0
+#define LANE_PCIE0_LANE0 0x1
+
+#define LANE_PCIE1_LANE0 0x0
+#define LANE_PCIE0_LANE1 0x1
+
+#define SERDES_NUM_CLOCKS 3
+
+/* SERDES control MMR bit offsets */
+#define SERDES_CTL_LANE_FUNC_SEL_SHIFT 0
+#define SERDES_CTL_LANE_FUNC_SEL_MASK GENMASK(1, 0)
+#define SERDES_CTL_CLK_SEL_SHIFT 4
+#define SERDES_CTL_CLK_SEL_MASKGENMASK(7, 4)
+
+/**
+ * struct serdes_am654_mux_clk_data - clock controller information structure
+ */
+struct serdes_am654_mux_clk_data {
+ struct regmap *regmap;
+ struct clk_bulk parents;
+};
+
+static int serdes_am654_mux_clk_probe(struct udevice *dev)
+{
+ struct serdes_am654_mux_clk_data *data = d
[U-Boot] [PATCH 1/7] clk: add support for clk_is_match()
Add support for clk_is_match() which is required to
know if two clock pointers point to the same exact
physical clock.
Signed-off-by: Sekhar Nori
---
drivers/clk/clk-uclass.c | 13 +
include/clk.h| 13 +
2 files changed, 26 insertions(+)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 79b3b0494c65..823be2bcb624 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -453,6 +453,19 @@ int clk_disable_bulk(struct clk_bulk *bulk)
return 0;
}
+bool clk_is_match(const struct clk *p, const struct clk *q)
+{
+ /* trivial case: identical struct clk's or both NULL */
+ if (p == q)
+ return true;
+
+ /* same device, id and data */
+ if (p->dev == q->dev && p->id == q->id && p->data == q->data)
+ return true;
+
+ return false;
+}
+
UCLASS_DRIVER(clk) = {
.id = UCLASS_CLK,
.name = "clk",
diff --git a/include/clk.h b/include/clk.h
index d24e99713a35..e657da038398 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -309,6 +309,18 @@ int clk_disable(struct clk *clk);
*/
int clk_disable_bulk(struct clk_bulk *bulk);
+/**
+ * clk_is_match - check if two clk's point to the same hardware clock
+ * @p: clk compared against q
+ * @q: clk compared against p
+ *
+ * Returns true if the two struct clk pointers both point to the same hardware
+ * clock node.
+ *
+ * Returns false otherwise. Note that two NULL clks are treated as matching.
+ */
+bool clk_is_match(const struct clk *p, const struct clk *q);
+
int soc_clk_dump(void);
/**
@@ -321,4 +333,5 @@ static inline bool clk_valid(struct clk *clk)
{
return !!clk->dev;
}
+
#endif
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/7] Add PCIe root complex support for AM654x SoC
Hi, This patch series adds PCIe root complex support for AM654x SoC. The device-tree files are based on bindings accepted in linux. See files Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt and Documentation/devicetree/bindings/pci/pci-keystone.txt in latest mainline master. I have not posted the actual board-specific device-tree bits yet. The reason is that PCIe slot is on a daughter card on the AM65x EVM. I want to see how we can support that as an overlay in U-Boot. That needs some more attention. Meanwhile I have tested this using a patch that simply enables PCIe in the baseboard device-tree file itself. Sekhar Nori (7): clk: add support for clk_is_match() dm: core: add support for getting register address and size pcie: ti: add driver for AM65x PCIe RC phy: add support for AM654x SERDES configs: am65x_evm_a53: enable PCIe support arm: dts: k3-am65: add support for PCIe and SERDES configs: am65x_evm_a53: enable support for PCIe ethernet cards arch/arm/dts/k3-am65-main.dtsi | 108 + arch/arm/dts/k3-am65.dtsi | 1 + configs/am65x_evm_a53_defconfig| 9 + drivers/clk/clk-uclass.c | 13 + drivers/core/fdtaddr.c | 17 + drivers/core/read.c| 20 + drivers/pci/Kconfig| 6 + drivers/pci/Makefile | 1 + drivers/pci/pcie_dw_ti.c | 725 + drivers/phy/Kconfig| 9 + drivers/phy/Makefile | 1 + drivers/phy/phy-ti-am654.c | 411 include/clk.h | 13 + include/dm/fdtaddr.h | 18 + include/dm/read.h | 41 ++ include/dt-bindings/phy/phy-am654-serdes.h | 13 + 16 files changed, 1406 insertions(+) create mode 100644 drivers/pci/pcie_dw_ti.c create mode 100644 drivers/phy/phy-ti-am654.c create mode 100644 include/dt-bindings/phy/phy-am654-serdes.h -- 2.16.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Kconfig: fix FIT offset prompt text
On 5/15/19 3:57 PM, Ibai Erkiaga wrote: > The current prompt text for FIT external offset is identical to > SYS_TEXT_BASE which might confuse the users. Provided more accurate > description for the prompt text. > > Signed-off-by: Ibai Erkiaga > --- > > Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Kconfig b/Kconfig > index 91c1082..f490ee4 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -278,7 +278,7 @@ config FIT > if FIT > > config FIT_EXTERNAL_OFFSET > - hex "Text Base" > + hex "FIT External Offset" "FIT external data offset" then ? > default 0x0 > help > This specifies a data offset in fit image. > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: omap3_logic/omap35_logic: Enable GPIO in SPL
The MMC controller enabled card detect, so this patch enables the GPIO driver in SPL to support it. Signed-off-by: Adam Ford diff --git a/configs/omap35_logic_defconfig b/configs/omap35_logic_defconfig index ea27731da3..3a529e8836 100644 --- a/configs/omap35_logic_defconfig +++ b/configs/omap35_logic_defconfig @@ -4,7 +4,6 @@ CONFIG_ARM=y CONFIG_ARCH_OMAP2PLUS=y CONFIG_SYS_TEXT_BASE=0x8010 CONFIG_TI_COMMON_CMD_OPTIONS=y -# CONFIG_SPL_GPIO_SUPPORT is not set CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_TARGET_OMAP3_LOGIC=y # CONFIG_SPL_OMAP3_ID_NAND is not set diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig index 446a6d41f2..0868e33131 100644 --- a/configs/omap3_logic_defconfig +++ b/configs/omap3_logic_defconfig @@ -4,7 +4,6 @@ CONFIG_ARM=y CONFIG_ARCH_OMAP2PLUS=y CONFIG_SYS_TEXT_BASE=0x8010 CONFIG_TI_COMMON_CMD_OPTIONS=y -# CONFIG_SPL_GPIO_SUPPORT is not set CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_TARGET_OMAP3_LOGIC=y # CONFIG_SPL_OMAP3_ID_NAND is not set -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 8/9] ubispl: add support for loading volumes by name
From: Hamish Guthrie
The motivation is to use the UBI atomic volume rename functionality to
allow double copy software updates on UBI. To that end the SPL is
configured to always load the same volume name (e.g. "u-boot"),
whereas a software updater always installs into the secondary volume
"u-boot_r". After successful installation, these two volume names are
switched.
This extension is protected by #ifdefs as it will somewhat slow down
loading of volumes by id. This is because the code needs to disable
the optimization of ignoring all volume ids which are not
to-be-loaded, since these can only be resolved after attaching.
This adds two vtbl related functions from Linux, which are taken from
the same kernel version as the current main U-Boot UBI code (Linux 4.2
64291f7db5bd8).
Signed-off-by: Hamish Guthrie
Signed-off-by: Markus Klotzbuecher
Reviewed-by: Heiko Schocher
Cc: Kyungmin Park
---
Changes for v2:
- indicate version of Kernel from which code was copied
common/spl/Kconfig | 13 +++
common/spl/spl_ubi.c| 7 ++
drivers/mtd/ubispl/ubispl.c | 215 +++-
drivers/mtd/ubispl/ubispl.h | 7 ++
include/ubispl.h| 6 +
5 files changed, 246 insertions(+), 2 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index fa63746909..624d084d03 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -563,6 +563,13 @@ config SPL_UBI
README.ubispl for more info.
if SPL_UBI
+config SPL_UBI_LOAD_BY_VOLNAME
+ bool "Support loading volumes by name"
+ help
+ This enables support for loading UBI volumes by name. When this
+ is set, CONFIG_SPL_UBI_LOAD_MONITOR_VOLNAME can be used to
+ configure the volume name from which to load U-Boot.
+
config SPL_UBI_MAX_VOL_LEBS
int "Maximum number of LEBs per volume"
depends on SPL_UBI
@@ -620,6 +627,12 @@ config SPL_UBI_LOAD_MONITOR_ID
help
The UBI volume id from which to load U-Boot
+config SPL_UBI_LOAD_MONITOR_VOLNAME
+ string "volume name of U-Boot volume"
+ depends on SPL_UBI_LOAD_BY_VOLNAME
+ help
+ The UBI volume name from which to load U-Boot
+
config SPL_UBI_LOAD_KERNEL_ID
int "id of kernel volume"
depends on SPL_OS_BOOT && SPL_UBI
diff --git a/common/spl/spl_ubi.c b/common/spl/spl_ubi.c
index 67e5fadd7c..0cb5080882 100644
--- a/common/spl/spl_ubi.c
+++ b/common/spl/spl_ubi.c
@@ -62,7 +62,14 @@ int spl_ubi_load_image(struct spl_image_info *spl_image,
}
#endif
header = spl_get_load_buffer(-sizeof(*header), sizeof(header));
+#ifdef CONFIG_SPL_UBI_LOAD_BY_VOLNAME
+ volumes[0].vol_id = -1;
+ strncpy(volumes[0].name,
+ CONFIG_SPL_UBI_LOAD_MONITOR_VOLNAME,
+ UBI_VOL_NAME_MAX + 1);
+#else
volumes[0].vol_id = CONFIG_SPL_UBI_LOAD_MONITOR_ID;
+#endif
volumes[0].load_addr = (void *)header;
ret = ubispl_load_volumes(&info, volumes, 1);
diff --git a/drivers/mtd/ubispl/ubispl.c b/drivers/mtd/ubispl/ubispl.c
index eeb1cbefb7..3f3b9b4367 100644
--- a/drivers/mtd/ubispl/ubispl.c
+++ b/drivers/mtd/ubispl/ubispl.c
@@ -45,6 +45,187 @@ static int ubi_io_is_bad(struct ubi_scan_info *ubi, int peb)
return peb >= ubi->peb_count || peb < 0;
}
+#ifdef CONFIG_SPL_UBI_LOAD_BY_VOLNAME
+
+/**
+ * ubi_dump_vtbl_record - dump a &struct ubi_vtbl_record object.
+ * @r: the object to dump
+ * @idx: volume table index
+ */
+void ubi_dump_vtbl_record(const struct ubi_vtbl_record *r, int idx)
+{
+ int name_len = be16_to_cpu(r->name_len);
+
+ ubi_dbg("Volume table record %d dump: size: %d",
+ idx, sizeof(struct ubi_vtbl_record));
+ ubi_dbg("\treserved_pebs %d", be32_to_cpu(r->reserved_pebs));
+ ubi_dbg("\talignment %d", be32_to_cpu(r->alignment));
+ ubi_dbg("\tdata_pad%d", be32_to_cpu(r->data_pad));
+ ubi_dbg("\tvol_type%d", (int)r->vol_type);
+ ubi_dbg("\tupd_marker %d", (int)r->upd_marker);
+ ubi_dbg("\tname_len%d", name_len);
+
+ if (r->name[0] == '\0') {
+ ubi_dbg("\tnameNULL");
+ return;
+ }
+
+ if (name_len <= UBI_VOL_NAME_MAX &&
+ strnlen(&r->name[0], name_len + 1) == name_len) {
+ ubi_dbg("\tname%s", &r->name[0]);
+ } else {
+ ubi_dbg("\t1st 5 characters of name: %c%c%c%c%c",
+ r->name[0], r->name[1], r->name[2], r->name[3],
+ r->name[4]);
+ }
+ ubi_dbg("\tcrc %#08x", be32_to_cpu(r->crc));
+}
+
+/* Empty volume table record */
+static struct ubi_vtbl_record empty_vtbl_record;
+
+/**
+ * vtbl_check - check if volume table is not corrupted and sensible.
+ * @ubi: UBI device description object
+ * @vtbl: volume table
+ *
+ * This function returns zero if @vtbl is all right, %1 if CRC is incorrect,
+ * and %-EINVAL if it contain
[U-Boot] [PATCH v2 9/9] ubispl: introduce separate CONFIG_UBI_SPL_SILENCE_MSG
From: Markus Klotzbuecher
This allows to silence ubi and ubispl individually.
Signed-off-by: Markus Klotzbuecher
Reviewed-by: Heiko Schocher
Cc: Kyungmin Park
---
Changes for v2: None
common/spl/Kconfig | 6 ++
drivers/mtd/ubispl/ubispl.h | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 624d084d03..ebe61969f9 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -645,6 +645,12 @@ config SPL_UBI_LOAD_ARGS_ID
help
The UBI volume id from which to load the device tree
+config UBI_SPL_SILENCE_MSG
+ bool "silence UBI SPL messages"
+ default n
+ help
+ Disable messages from UBI SPL. This leaves warnings
+ and errors enabled.
endif # if SPL_UBI
diff --git a/drivers/mtd/ubispl/ubispl.h b/drivers/mtd/ubispl/ubispl.h
index bcc376c6d7..b7cb7fc941 100644
--- a/drivers/mtd/ubispl/ubispl.h
+++ b/drivers/mtd/ubispl/ubispl.h
@@ -129,7 +129,7 @@ struct ubi_scan_info {
#define ubi_dbg(fmt, ...)
#endif
-#ifdef CONFIG_UBI_SILENCE_MSG
+#ifdef CONFIG_UBI_SPL_SILENCE_MSG
#define ubi_msg(fmt, ...)
#else
#define ubi_msg(fmt, ...) printf("UBI: " fmt "\n", ##__VA_ARGS__)
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 7/9] configs: migrate ubispl boards to KConfig
From: Markus Klotzbuecher Migrate the ubispl configuration for the omap3_igep00x0 and am335x_igep003x boards to KConfig. Both boards were built with SOURCE_DATE_EPOCH=0 and found to be equal before and after. Signed-off-by: Markus Klotzbuecher Cc: Heiko Schocher Cc: Kyungmin Park Cc: Javier Martínez Canillas Cc: Enric Balletbo i Serra --- Changes for v2: new patch configs/am335x_igep003x_defconfig | 12 configs/igep00x0_defconfig| 12 include/configs/am335x_igep003x.h | 16 include/configs/omap3_igep00x0.h | 14 -- 4 files changed, 24 insertions(+), 30 deletions(-) diff --git a/configs/am335x_igep003x_defconfig b/configs/am335x_igep003x_defconfig index f44fb09b31..5874831ba1 100644 --- a/configs/am335x_igep003x_defconfig +++ b/configs/am335x_igep003x_defconfig @@ -21,6 +21,18 @@ CONFIG_VERSION_VARIABLE=y CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MTD_SUPPORT=y +CONFIG_SPL_UBI=y +CONFIG_SPL_UBI_MAX_VOL_LEBS=256 +CONFIG_SPL_UBI_MAX_PEB_SIZE=262144 +CONFIG_SPL_UBI_MAX_PEBS=4096 +CONFIG_SPL_UBI_PEB_OFFSET=4 +CONFIG_SPL_UBI_VID_OFFSET=512 +CONFIG_SPL_UBI_LEB_START=2048 +CONFIG_SPL_UBI_INFO_ADDR=0x8808 +CONFIG_SPL_UBI_VOL_IDS=8 +CONFIG_SPL_UBI_LOAD_MONITOR_ID=0 +CONFIG_SPL_UBI_LOAD_KERNEL_ID=3 +CONFIG_SPL_UBI_LOAD_ARGS_ID=4 CONFIG_SPL_OS_BOOT=y CONFIG_SPL_POWER_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y diff --git a/configs/igep00x0_defconfig b/configs/igep00x0_defconfig index 927d7f0ecd..ab11935f48 100644 --- a/configs/igep00x0_defconfig +++ b/configs/igep00x0_defconfig @@ -17,6 +17,18 @@ CONFIG_SPL_TEXT_BASE=0x4020 CONFIG_SPL_SYS_MALLOC_SIMPLE=y # CONFIG_SPL_FS_EXT4 is not set CONFIG_SPL_MTD_SUPPORT=y +CONFIG_SPL_UBI=y +CONFIG_SPL_UBI_MAX_VOL_LEBS=256 +CONFIG_SPL_UBI_MAX_PEB_SIZE=262144 +CONFIG_SPL_UBI_MAX_PEBS=4096 +CONFIG_SPL_UBI_PEB_OFFSET=4 +CONFIG_SPL_UBI_VID_OFFSET=512 +CONFIG_SPL_UBI_LEB_START=2048 +CONFIG_SPL_UBI_INFO_ADDR=0x8808 +CONFIG_SPL_UBI_VOL_IDS=8 +CONFIG_SPL_UBI_LOAD_MONITOR_ID=0 +CONFIG_SPL_UBI_LOAD_KERNEL_ID=3 +CONFIG_SPL_UBI_LOAD_ARGS_ID=4 CONFIG_SPL_ONENAND_SUPPORT=y CONFIG_SPL_OS_BOOT=y CONFIG_CMD_SPL=y diff --git a/include/configs/am335x_igep003x.h b/include/configs/am335x_igep003x.h index 5131cd38e4..5b5e16026e 100644 --- a/include/configs/am335x_igep003x.h +++ b/include/configs/am335x_igep003x.h @@ -106,22 +106,6 @@ /* NAND support */ #define CONFIG_SYS_NAND_ONFI_DETECTION 1 -/* SPL */ - -/* UBI configuration */ -#define CONFIG_SPL_UBI 1 -#define CONFIG_SPL_UBI_MAX_VOL_LEBS256 -#define CONFIG_SPL_UBI_MAX_PEB_SIZE(256*1024) -#define CONFIG_SPL_UBI_MAX_PEBS4096 -#define CONFIG_SPL_UBI_VOL_IDS 8 -#define CONFIG_SPL_UBI_LOAD_MONITOR_ID 0 -#define CONFIG_SPL_UBI_LOAD_KERNEL_ID 3 -#define CONFIG_SPL_UBI_LOAD_ARGS_ID4 -#define CONFIG_SPL_UBI_PEB_OFFSET 4 -#define CONFIG_SPL_UBI_VID_OFFSET 512 -#define CONFIG_SPL_UBI_LEB_START 2048 -#define CONFIG_SPL_UBI_INFO_ADDR 0x8808 - /* NAND config */ #define CONFIG_SYS_NAND_5_ADDR_CYCLE #define CONFIG_SYS_NAND_PAGE_COUNT (CONFIG_SYS_NAND_BLOCK_SIZE / \ diff --git a/include/configs/omap3_igep00x0.h b/include/configs/omap3_igep00x0.h index a95a9cc664..4ad7dc18b1 100644 --- a/include/configs/omap3_igep00x0.h +++ b/include/configs/omap3_igep00x0.h @@ -96,18 +96,4 @@ #define CONFIG_SYS_NAND_ECCBYTES 14 #define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW_DETECTION_SW -/* UBI configuration */ -#define CONFIG_SPL_UBI 1 -#define CONFIG_SPL_UBI_MAX_VOL_LEBS256 -#define CONFIG_SPL_UBI_MAX_PEB_SIZE(256*1024) -#define CONFIG_SPL_UBI_MAX_PEBS4096 -#define CONFIG_SPL_UBI_VOL_IDS 8 -#define CONFIG_SPL_UBI_LOAD_MONITOR_ID 0 -#define CONFIG_SPL_UBI_LOAD_KERNEL_ID 3 -#define CONFIG_SPL_UBI_LOAD_ARGS_ID4 -#define CONFIG_SPL_UBI_PEB_OFFSET 4 -#define CONFIG_SPL_UBI_VID_OFFSET 512 -#define CONFIG_SPL_UBI_LEB_START 2048 -#define CONFIG_SPL_UBI_INFO_ADDR 0x8808 - #endif /* __IGEP00X0_H */ -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/9] env: ubi: support configurable VID offset
From: Hamish Guthrie
Introduce KConfig CONFIG_ENV_UBI_VID_OFFSET to allow providing custom
VID header offsets for the environment on UBI.
Signed-off-by: Hamish Guthrie
Signed-off-by: Markus Klotzbuecher
Reviewed-by: Heiko Schocher
Cc: Kyungmin Park
---
Changes for v2:
- default to no custom vid offset
env/Kconfig | 7 +++
env/ubi.c | 17 +
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/env/Kconfig b/env/Kconfig
index a57b1fc70b..c4c3309c09 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -522,6 +522,13 @@ config ENV_UBI_VOLUME_REDUND
help
Name of the redundant volume that you want to store the environment
in.
+config ENV_UBI_VID_OFFSET
+ int "ubi environment VID offset"
+ depends on ENV_IS_IN_UBI
+ default 0
+ help
+ UBI VID offset for environment. If 0, no custom VID offset is used.
+
endif
config USE_DEFAULT_ENV_FILE
diff --git a/env/ubi.c b/env/ubi.c
index 1dfdf0a8c8..e4b85167ec 100644
--- a/env/ubi.c
+++ b/env/ubi.c
@@ -15,6 +15,15 @@
#include
#undef crc32
+#define _QUOTE(x) #x
+#define QUOTE(x) _QUOTE(x)
+
+#if (CONFIG_ENV_UBI_VID_OFFSET == 0)
+ #define UBI_VID_OFFSET NULL
+#else
+ #define UBI_VID_OFFSET QUOTE(CONFIG_ENV_UBI_VID_OFFSET)
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_CMD_SAVEENV
@@ -28,7 +37,7 @@ static int env_ubi_save(void)
if (ret)
return ret;
- if (ubi_part(CONFIG_ENV_UBI_PART, NULL)) {
+ if (ubi_part(CONFIG_ENV_UBI_PART, UBI_VID_OFFSET)) {
printf("\n** Cannot find mtd partition \"%s\"\n",
CONFIG_ENV_UBI_PART);
return 1;
@@ -70,7 +79,7 @@ static int env_ubi_save(void)
if (ret)
return ret;
- if (ubi_part(CONFIG_ENV_UBI_PART, NULL)) {
+ if (ubi_part(CONFIG_ENV_UBI_PART, UBI_VID_OFFSET)) {
printf("\n** Cannot find mtd partition \"%s\"\n",
CONFIG_ENV_UBI_PART);
return 1;
@@ -111,7 +120,7 @@ static int env_ubi_load(void)
tmp_env1 = (env_t *)env1_buf;
tmp_env2 = (env_t *)env2_buf;
- if (ubi_part(CONFIG_ENV_UBI_PART, NULL)) {
+ if (ubi_part(CONFIG_ENV_UBI_PART, UBI_VID_OFFSET)) {
printf("\n** Cannot find mtd partition \"%s\"\n",
CONFIG_ENV_UBI_PART);
set_default_env(NULL, 0);
@@ -148,7 +157,7 @@ static int env_ubi_load(void)
*/
memset(buf, 0x0, CONFIG_ENV_SIZE);
- if (ubi_part(CONFIG_ENV_UBI_PART, NULL)) {
+ if (ubi_part(CONFIG_ENV_UBI_PART, UBI_VID_OFFSET)) {
printf("\n** Cannot find mtd partition \"%s\"\n",
CONFIG_ENV_UBI_PART);
set_default_env(NULL, 0);
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 6/9] ubispl: migrate configuration to Kconfig
From: Markus Klotzbuecher Move the ubispl configuration to KConfig and drop them from the whitelist. Signed-off-by: Markus Klotzbuecher Cc: Heiko Schocher Cc: Kyungmin Park Cc: Javier Martínez Canillas Cc: Enric Balletbo i Serra --- Changes for v2: None common/spl/Kconfig | 79 scripts/config_whitelist.txt | 12 -- 2 files changed, 79 insertions(+), 12 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index c7cd34449a..fa63746909 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -556,6 +556,85 @@ config SPL_NAND_SUPPORT This enables the drivers in drivers/mtd/nand/raw as part of an SPL build. +config SPL_UBI + bool "Support UBI" + help + Enable support for loading payloads from UBI. See + README.ubispl for more info. + +if SPL_UBI +config SPL_UBI_MAX_VOL_LEBS + int "Maximum number of LEBs per volume" + depends on SPL_UBI + help + The maximum number of logical eraseblocks which a static volume + to load can contain. Used for sizing the scan data structure. + +config SPL_UBI_MAX_PEB_SIZE + int "Maximum PEB size" + depends on SPL_UBI + help + The maximum physical erase block size. + +config SPL_UBI_MAX_PEBS + int "Maximum number of PEBs" + depends on SPL_UBI + help + The maximum physical erase block size. If not overridden by + board code, this value will be used as the actual number of PEBs. + +config SPL_UBI_PEB_OFFSET + int "Offset to first UBI PEB" + depends on SPL_UBI + help + The offset in number of PEBs from the start of flash to the first + PEB part of the UBI image. + +config SPL_UBI_VID_OFFSET + int "Offset to VID header" + depends on SPL_UBI + +config SPL_UBI_LEB_START + int "Offset to LEB in PEB" + depends on SPL_UBI + help + The offset in bytes to the LEB within a PEB. + +config SPL_UBI_INFO_ADDR + hex "Address to place UBI scan info" + depends on SPL_UBI + help + Address for ubispl to place the scan info. Read README.ubispl to + determine the required size + +config SPL_UBI_VOL_IDS + int "Maximum volume id" + depends on SPL_UBI + help + The maximum volume id which can be loaded. Used for sizing the + scan data structure. + +config SPL_UBI_LOAD_MONITOR_ID + int "id of U-Boot volume" + depends on SPL_UBI + help + The UBI volume id from which to load U-Boot + +config SPL_UBI_LOAD_KERNEL_ID + int "id of kernel volume" + depends on SPL_OS_BOOT && SPL_UBI + help + The UBI volume id from which to load the kernel + +config SPL_UBI_LOAD_ARGS_ID + int "id of kernel args volume" + depends on SPL_OS_BOOT && SPL_UBI + help + The UBI volume id from which to load the device tree + + +endif # if SPL_UBI + config SPL_NET_SUPPORT bool "Support networking" help diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index af7eb73e4a..eeddc6a974 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -1871,18 +1871,6 @@ CONFIG_SPL_STACK_ADDR CONFIG_SPL_STACK_SIZE CONFIG_SPL_START_S_PATH CONFIG_SPL_TARGET -CONFIG_SPL_UBI -CONFIG_SPL_UBI_INFO_ADDR -CONFIG_SPL_UBI_LEB_START -CONFIG_SPL_UBI_LOAD_ARGS_ID -CONFIG_SPL_UBI_LOAD_KERNEL_ID -CONFIG_SPL_UBI_LOAD_MONITOR_ID -CONFIG_SPL_UBI_MAX_PEBS -CONFIG_SPL_UBI_MAX_PEB_SIZE -CONFIG_SPL_UBI_MAX_VOL_LEBS -CONFIG_SPL_UBI_PEB_OFFSET -CONFIG_SPL_UBI_VID_OFFSET -CONFIG_SPL_UBI_VOL_IDS CONFIG_SPL_UBOOT_KEY_HASH CONFIG_SRAM_BASE CONFIG_SRAM_SIZE -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
