Re: [U-Boot] [linux-sunxi] [PATCH 1/4] arm: dts: h6: move MMC pinctrl to soc
Hi, On Fri, 12 Apr 2019 at 15:36, Jagan Teki wrote: > > On Mon, Apr 8, 2019 at 10:11 PM Clément Péron wrote: > > > > There is only one muxing avalaible for each MMC controller. > > > > Move this pinmux to the SOC dtsi. > > Sync all dts(i) changes in one patch with head commit id details on > patch commit message instead of few minor updates. sync with some rc > tag would be beneficial if needed changes been part of that. eMMC pins move patch are planned for 5.2 no rc tag for now... I can postpone the sync dts(i) patch later If you prefer ? Clement ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] why does "board_init_r()" accept a second arg of "ulong dest_addr"?
On Fri, 12 Apr 2019, Robert P. J. Day wrote:
> On Fri, 12 Apr 2019, Simon Glass wrote:
>
> > Hi Robert,
> >
> > On Fri, 12 Apr 2019 at 06:31, Robert P. J. Day
> > wrote:
> > >
> > >
> > > was tracing the ARM-based boot sequence and ended up at the call to
> > > board_init_r():
> > >
> > > void board_init_r(gd_t *new_gd, ulong dest_addr)
> > > {
> > > /*
> > > * Set up the new global data pointer. So far only x86 does this
> > > * here.
> > > * TODO(s...@chromium.org): Consider doing this for all archs, or
> > > * dropping the new_gd parameter.
> > > */
> > > ... snip ...
> > >
> > > but as i read board_init_r(), it's not clear what that routine is
> > > doing with that second argument, "dest_addr".
>
> ... snip ...
>
> > I believe this is not used. The value is available in gd->dest_addr
> > and we now read it from there.
> >
> > So perhaps this argument could be dropped.
>
> massive sigh of relief here as i was totally prepared for a response
> like, "oh, come on, how can you not see how it's being used?" :-)
>
> anyway, i can take a shot at a patch unless someone else wants to do
> it. i'm just relieved that it wasn't that dumb a question after all.
i take it back ... there are, of course, calls to board_init_r()
from all over the place, across all architectures, so if someone
higher up the food chain wants to do something about that, that's fine
-- all i needed to confirm was that that second argument wasn't doing
anything. thanks. movin' on ...
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] at91: cleanup taurus port
Hello Eugen,
Am 12.04.2019 um 15:07 schrieb eugen.hris...@microchip.com:
On 12.04.2019 15:53, Heiko Schocher wrote:
External E-Mail
Hello eugen,
Am 12.04.2019 um 13:24 schrieb eugen.hris...@microchip.com:
On 11.04.2019 08:53, Heiko Schocher wrote:
- at91sam9g20-taurus.dts: use labels
- cleanup taurus port to compile clean with
current mainline again. SPL has no serial
output anymore, so it fits into SRAM.
Signed-off-by: Heiko Schocher
[snip]
Hello Heiko,
This patch has several issues:
taurus_defconfig
+spl/dts/dt-platdata.c:11:46: error: missing braces around initializer
[-Werror=missing-braces]
+ static const struct dtd_simple_bus dtv_ahb = {
+ ^
+spl/dts/dt-platdata.c:20:46: error: missing braces around initializer
[-Werror=missing-braces]
+ static const struct dtd_simple_bus dtv_apb = {
+cc1: all warnings being treated as errors
+make[2]: *** [spl/dts/dt-platdata.o] Error 1
+make[1]: *** [spl/u-boot-spl] Error 2
+make: *** [sub-make] Error 2
Ah, I had not warnings as errors active ... sorry for this!
Hmmm:
in generated ./include/generated/dt-structs-gen.h
struct dtd_simple_bus {
bool ranges;
};
True but at line #44 you have
#define dtd_simple_bus dtd_atmel_at91rm9200_pinctrl
Which redefines things...
indeed. As this is an autmatic generated file, I must look deeper
into it!
bye,
Heiko
and in spl/dts/dt-platdata.c:
#include
static const struct dtd_simple_bus dtv_ahb = {
.ranges = true,
};
Do not see what is really wrong ... may friday afternoon ...
and axm_defconfig :
+drivers/built-in.o: In function `get_current':
+drivers/serial/serial.c:318: undefined reference to
`default_serial_console'
+make[2]: *** [spl/u-boot-spl] Error 1
+make[1]: *** [spl/u-boot-spl] Error 2
+make: *** [sub-make] Error 2
Ups, sorry, just forgot to add this, update this in v2.
Thanks for the review!
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] Add Beelink GS1 Board
This serie introduce the Beelink GS1 board with a patch for the reset on Allwinner H6. Thanks to Jagan Teki most of the Beelink GS1 device-tree is taken from the Orange Pi boards. Changes with v1: - Add bus-width for mmc2 node - Add sha1 in the sync dts commit Clément Péron (3): arm: dts: h6: sync with dts with Linux sunxi arm: dts: h6: Add Beelink GS1 initial support arm: sunxi: h6: fix reset using r_wdog arch/arm/dts/Makefile | 1 + arch/arm/dts/sun50i-h6-beelink-gs1.dts| 184 ++ arch/arm/dts/sun50i-h6-orangepi.dtsi | 2 - arch/arm/dts/sun50i-h6-pine-h64.dts | 4 - arch/arm/dts/sun50i-h6.dtsi | 16 +- .../include/asm/arch-sunxi/cpu_sun50i_h6.h| 1 + arch/arm/mach-sunxi/board.c | 9 +- configs/beelink_gs1_defconfig | 15 ++ 8 files changed, 218 insertions(+), 14 deletions(-) create mode 100644 arch/arm/dts/sun50i-h6-beelink-gs1.dts create mode 100644 configs/beelink_gs1_defconfig -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] arm: dts: h6: sync with dts with Linux sunxi
There are some differences between U-Boot and Linux device tree files.
Sync only the minor changes.
6ba2e45d57af - arm64: dts: allwinner: h6: move MMC pinctrl to dtsi
54eac67bbe3a - arm64: dts: allwinner: Fix pinctrl node names
31af04cd60d3 - arm64: dts: Remove inconsistent use of 'arm,armv8' compatible
string
Signed-off-by: Clément Péron
---
arch/arm/dts/sun50i-h6-orangepi.dtsi | 2 --
arch/arm/dts/sun50i-h6-pine-h64.dts | 4
arch/arm/dts/sun50i-h6.dtsi | 16 ++--
3 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/arm/dts/sun50i-h6-orangepi.dtsi
b/arch/arm/dts/sun50i-h6-orangepi.dtsi
index 0612c19cd9..3748dcaa70 100644
--- a/arch/arm/dts/sun50i-h6-orangepi.dtsi
+++ b/arch/arm/dts/sun50i-h6-orangepi.dtsi
@@ -24,8 +24,6 @@
};
&mmc0 {
- pinctrl-names = "default";
- pinctrl-0 = <&mmc0_pins>;
vmmc-supply = <®_cldo1>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
bus-width = <4>;
diff --git a/arch/arm/dts/sun50i-h6-pine-h64.dts
b/arch/arm/dts/sun50i-h6-pine-h64.dts
index ceffc40810..a26314c084 100644
--- a/arch/arm/dts/sun50i-h6-pine-h64.dts
+++ b/arch/arm/dts/sun50i-h6-pine-h64.dts
@@ -42,16 +42,12 @@
};
&mmc0 {
- pinctrl-names = "default";
- pinctrl-0 = <&mmc0_pins>;
vmmc-supply = <®_cldo1>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
status = "okay";
};
&mmc2 {
- pinctrl-names = "default";
- pinctrl-0 = <&mmc2_pins>;
vmmc-supply = <®_cldo1>;
vqmmc-supply = <®_bldo2>;
non-removable;
diff --git a/arch/arm/dts/sun50i-h6.dtsi b/arch/arm/dts/sun50i-h6.dtsi
index cfa5fffcf6..5f01314703 100644
--- a/arch/arm/dts/sun50i-h6.dtsi
+++ b/arch/arm/dts/sun50i-h6.dtsi
@@ -19,28 +19,28 @@
#size-cells = <0>;
cpu0: cpu@0 {
- compatible = "arm,cortex-a53", "arm,armv8";
+ compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <0>;
enable-method = "psci";
};
cpu1: cpu@1 {
- compatible = "arm,cortex-a53", "arm,armv8";
+ compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <1>;
enable-method = "psci";
};
cpu2: cpu@2 {
- compatible = "arm,cortex-a53", "arm,armv8";
+ compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <2>;
enable-method = "psci";
};
cpu3: cpu@3 {
- compatible = "arm,cortex-a53", "arm,armv8";
+ compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <3>;
enable-method = "psci";
@@ -143,7 +143,7 @@
bias-pull-up;
};
- uart0_ph_pins: uart0-ph {
+ uart0_ph_pins: uart0-ph-pins {
pins = "PH0", "PH1";
function = "uart0";
};
@@ -158,6 +158,8 @@
resets = <&ccu RST_BUS_MMC0>;
reset-names = "ahb";
interrupts = ;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
@@ -186,6 +188,8 @@
resets = <&ccu RST_BUS_MMC2>;
reset-names = "ahb";
interrupts = ;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins>;
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
@@ -266,7 +270,7 @@
interrupt-controller;
#interrupt-cells = <3>;
- r_i2c_pins: r-i2c {
+ r_i2c_pins: r-i2c-pins {
pins = "PL0", "PL1";
function = "s_i2c";
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] arm: dts: h6: Add Beelink GS1 initial support
Beelink GS1 is an Allwinner H6 based TV box,
which support:
- Allwinner H6 Quad-core 64-bit ARM Cortex-A53
- GPU Mali-T720
- 2GB LPDDR3 RAM
- 16GB eMMC
- AXP805 PMIC
- 1Gbps GMAC via RTL8211E
- USB 2.0 and 3.0 Host
- HDMI port
- S/PDIF port
- 5V/2A DC power supply
- Wi-Fi/BT via Fn-Link 6222B-SRB (RTL8222BS)
Signed-off-by: Clément Péron
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/sun50i-h6-beelink-gs1.dts | 184 +
configs/beelink_gs1_defconfig | 15 ++
3 files changed, 200 insertions(+)
create mode 100644 arch/arm/dts/sun50i-h6-beelink-gs1.dts
create mode 100644 configs/beelink_gs1_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 86a01c2c70..61e7156284 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -467,6 +467,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
sun50i-h5-orangepi-prime.dtb \
sun50i-h5-orangepi-zero-plus2.dtb
dtb-$(CONFIG_MACH_SUN50I_H6) += \
+ sun50i-h6-beelink-gs1.dtb \
sun50i-h6-orangepi-lite2.dtb \
sun50i-h6-orangepi-one-plus.dtb \
sun50i-h6-pine-h64.dtb
diff --git a/arch/arm/dts/sun50i-h6-beelink-gs1.dts
b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
new file mode 100644
index 00..54b0882bed
--- /dev/null
+++ b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2019 Clément Péron
+ */
+
+/dts-v1/;
+
+#include "sun50i-h6.dtsi"
+
+#include
+
+/ {
+ model = "Beelink GS1";
+ compatible = "azw,beelink-gs1", "allwinner,sun50i-h6";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ power {
+ label = "beelink:white:power";
+ gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
+ default-state = "on";
+ };
+ };
+
+ reg_vcc5v: vcc5v {
+ /* board wide 5V supply directly from the DC jack */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-5v";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+};
+
+&mmc0 {
+ vmmc-supply = <®_cldo1>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ status = "okay";
+};
+
+&mmc2 {
+ vmmc-supply = <®_cldo1>;
+ vqmmc-supply = <®_bldo2>;
+ non-removable;
+ cap-mmc-hw-reset;
+ bus-width = <8>;
+ status = "okay";
+};
+
+&r_i2c {
+ status = "okay";
+
+ axp805: pmic@36 {
+ compatible = "x-powers,axp805", "x-powers,axp806";
+ reg = <0x36>;
+ interrupt-parent = <&r_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ x-powers,self-working-mode;
+ vina-supply = <®_vcc5v>;
+ vinb-supply = <®_vcc5v>;
+ vinc-supply = <®_vcc5v>;
+ vind-supply = <®_vcc5v>;
+ vine-supply = <®_vcc5v>;
+ aldoin-supply = <®_vcc5v>;
+ bldoin-supply = <®_vcc5v>;
+ cldoin-supply = <®_vcc5v>;
+
+ regulators {
+ reg_aldo1: aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-pl";
+ };
+
+ reg_aldo2: aldo2 {
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-ac200";
+ regulator-enable-ramp-delay = <10>;
+ };
+
+ reg_aldo3: aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc25-dram";
+ };
+
+ reg_bldo1: bldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-name = "vcc-bias-pll";
+ };
+
+ reg_bldo2: bldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <
[U-Boot] [PATCH v2 3/3] arm: sunxi: h6: fix reset using r_wdog
WDOG is broken for some H6 rev. The board is not reseted correctly. Use the R_WDOG instead. Signed-off-by: Clément Péron --- arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h | 1 + arch/arm/mach-sunxi/board.c | 9 +++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h index 41a9b0fc47..6392cb07b4 100644 --- a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h @@ -60,6 +60,7 @@ #define SUNXI_RTC_BASE 0x0700 #define SUNXI_R_CPUCFG_BASE0x07000400 #define SUNXI_PRCM_BASE0x0701 +#define SUNXI_R_WDOG_BASE 0x07020400 #define SUNXI_R_PIO_BASE 0x07022000 #define SUNXI_R_UART_BASE 0x0708 #define SUNXI_R_TWI_BASE 0x07081400 diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index b74eaf2a0e..1075b5ca54 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -287,9 +287,14 @@ void reset_cpu(ulong addr) writel(WDT_MODE_RESET_EN | WDT_MODE_EN, &wdog->mode); } #elif defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_MACH_SUN50I_H6) +#if defined(CONFIG_MACH_SUN50I_H6) + /* WDOG is broken for some H6 rev. use the R_WDOG instead */ static const struct sunxi_wdog *wdog = -((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)->wdog; - + (struct sunxi_wdog *)SUNXI_R_WDOG_BASE; +#else + static const struct sunxi_wdog *wdog = + ((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)->wdog; +#endif /* Set the watchdog for its shortest interval (.5s) and wait */ writel(WDT_CFG_RESET, &wdog->cfg); writel(WDT_MODE_EN, &wdog->mode); -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2 08/11] cmd: bootefi: carve out bootmgr code from do_bootefi()
On Fri, Apr 12, 2019 at 10:58:25AM +0200, Heinrich Schuchardt wrote:
>
>
> On 4/12/19 9:06 AM, AKASHI Takahiro wrote:
> > On Fri, Apr 12, 2019 at 07:55:16AM +0200, Heinrich Schuchardt wrote:
> >> On 3/27/19 5:40 AM, AKASHI Takahiro wrote:
> >>> This is a preparatory patch for reworking do_bootefi() in later patch.
> >>> do_bootmgr_exec() is renamed to do_efibootmgr() as we put all the
> >>> necessary
> >>> code into this function.
> >>>
> >>> Signed-off-by: AKASHI Takahiro
> >>> ---
> >>> cmd/bootefi.c | 42 ++
> >>> 1 file changed, 34 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> >>> index e9d4881997a1..94b5bdeed3f1 100644
> >>> --- a/cmd/bootefi.c
> >>> +++ b/cmd/bootefi.c
> >>> @@ -309,22 +309,47 @@ err_add_protocol:
> >>> return ret;
> >>> }
> >>>
> >>> -static int do_bootefi_bootmgr_exec(void)
> >>> +/**
> >>> + * do_efibootmgr() - execute EFI Boot Manager
> >>> + *
> >>> + * @fdt_opt: string of fdt start address
> >>> + * Return: status code
> >>> + *
> >>> + * Execute EFI Boot Manager
> >>> + */
> >>> +static int do_efibootmgr(const char *fdt_opt)
> >>> {
> >>> struct efi_device_path *device_path, *file_path;
> >>> void *addr;
> >>> - efi_status_t r;
> >>> + efi_status_t ret;
> >>> +
> >>> + /* Allow unaligned memory access */
> >>> + allow_unaligned();
> >>> +
> >>> + switch_to_non_secure_mode();
> >>> +
> >>
> >> Shouldn't we move these two call to efi_init_obj_list()?
> >
> > Given the fact that efi_init_obj_list() is called without invoking
> > any UEFI binary at some places, I'm not sure that it is the right
> > place where switch_to_non_secure_mode() be called.
If this is UEFI(and arm)-specific, it should be placed just
before setjmp() in efi_start_image().
But I'm not sure whether we should call switch_to_non_secure_mode()
even for a driver, which is logically part of U-Boot UEFI.
-Takahiro Akashi
> I think this could even be done in initr_reloc_global_data().
>
> @Alex
> What are your thoughts.
>
> Best regards
>
> Heinrich
>
> >
> > -Takahiro Akashi
> >
> >
> >> Best regards
> >>
> >> Heinrich
> >>
> >>> + /* Initialize EFI drivers */
> >>> + ret = efi_init_obj_list();
> >>> + if (ret != EFI_SUCCESS) {
> >>> + printf("Error: Cannot initialize UEFI sub-system, r = %lu\n",
> >>> +ret & ~EFI_ERROR_MASK);
> >>> + return CMD_RET_FAILURE;
> >>> + }
> >>> +
> >>> + ret = efi_install_fdt(fdt_opt);
> >>> + if (ret != EFI_SUCCESS)
> >>> + return CMD_RET_FAILURE;
> >>>
> >>> addr = efi_bootmgr_load(&device_path, &file_path);
> >>> if (!addr)
> >>> return 1;
> >>>
> >>> printf("## Starting EFI application at %p ...\n", addr);
> >>> - r = do_bootefi_exec(addr, device_path, file_path);
> >>> + ret = do_bootefi_exec(addr, device_path, file_path);
> >>> printf("## Application terminated, r = %lu\n",
> >>> -r & ~EFI_ERROR_MASK);
> >>> +ret & ~EFI_ERROR_MASK);
> >>>
> >>> - if (r != EFI_SUCCESS)
> >>> + if (ret != EFI_SUCCESS)
> >>> return 1;
> >>>
> >>> return 0;
> >>> @@ -463,6 +488,9 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
> >>> argc, char * const argv[])
> >>>
> >>> if (argc < 2)
> >>> return CMD_RET_USAGE;
> >>> +
> >>> + if (!strcmp(argv[1], "bootmgr"))
> >>> + return do_efibootmgr(argc > 2 ? argv[2] : NULL);
> >>> #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
> >>> else if (!strcmp(argv[1], "selftest"))
> >>> return do_efi_selftest(argc > 2 ? argv[2] : NULL);
> >>> @@ -497,9 +525,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
> >>> argc, char * const argv[])
> >>> memcpy(map_sysmem(addr, size), __efi_helloworld_begin, size);
> >>> } else
> >>> #endif
> >>> - if (!strcmp(argv[1], "bootmgr")) {
> >>> - return do_bootefi_bootmgr_exec();
> >>> - } else {
> >>> + {
> >>> saddr = argv[1];
> >>>
> >>> addr = simple_strtoul(saddr, NULL, 16);
> >>>
> >>
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] dm: core: Change platform specific translation-offset handling
Testing has shown that the current DM implementation of a platform /
board specific translation offset, as its needed for the SPL on MVEBU
platforms is buggy. The translation offset is confingured too late,
after the driver bind functions are run. This may result in incorrect
address translations. With the current implementation its not possible
to configure the offset earlier, as the DM code has not run at all.
This patch now removed the set_/get_translation_offset() calls and
moves the translation offset into the GD variable translation_offset.
This variable will get used when CONFIG_TRANSLATION_OFFSET is enabled.
This option is enabled only for MVEBU on ARM32 platforms, where its
currenty needed and configured in the SPL.
Signed-off-by: Stefan Roese
Cc: Pierre Bourdon
Cc: Baruch Siach
Cc: Simon Glass
Cc: Heiko Schocher
Cc: Tom Rini
---
arch/arm/mach-mvebu/Kconfig | 1 +
arch/arm/mach-mvebu/spl.c | 12 +---
drivers/core/Kconfig | 9 +
drivers/core/fdtaddr.c| 9 ++---
drivers/core/root.c | 21 -
include/asm-generic/global_data.h | 4
include/dm/fdtaddr.h | 21 -
7 files changed, 29 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 7dda04e0e3..6d3429b6b1 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -14,6 +14,7 @@ config ARMADA_32BIT
select SPL_OF_CONTROL
select SPL_SIMPLE_BUS
select SUPPORT_SPL
+ select TRANSLATION_OFFSET
config ARMADA_64BIT
bool
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 9dd7c84b68..530b98c1aa 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -93,15 +93,21 @@ void board_init_f(ulong dummy)
*/
#endif
+ /*
+* Use special translation offset for SPL. This needs to be
+* configured *before* spl_init() is called as this function
+* calls dm_init() which calls the bind functions of the
+* device drivers. Here the base address needs to be configured
+* (translated) correctly.
+*/
+ gd->translation_offset = 0xd000 - 0xf100;
+
ret = spl_init();
if (ret) {
debug("spl_init() failed: %d\n", ret);
hang();
}
- /* Use special translation offset for SPL */
- dm_set_translation_offset(0xd000 - 0xf100);
-
preloader_console_init();
timer_init();
diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index ddf2fb3fb8..2d195ae35e 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -225,6 +225,15 @@ config SPL_OF_TRANSLATE
used for the address translation. This function is faster and
smaller in size than fdt_translate_address().
+config TRANSLATION_OFFSET
+ bool "Platforms specific translation offset"
+ depends on DM && OF_CONTROL
+ help
+ Some platforms need a special address translation. Those
+ platforms (e.g. mvebu in SPL) can configure a translation
+ offset by enabling this option and setting the translation_offset
+ variable in the GD in their platform- / board-specific code.
+
config OF_ISA_BUS
bool
depends on OF_TRANSLATE
diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
index e113f1dd39..c2873861da 100644
--- a/drivers/core/fdtaddr.c
+++ b/drivers/core/fdtaddr.c
@@ -74,13 +74,16 @@ fdt_addr_t devfdt_get_addr_index(struct udevice *dev, int
index)
}
}
+#if defined(CONFIG_TRANSLATION_OFFSET)
/*
* Some platforms need a special address translation. Those
* platforms (e.g. mvebu in SPL) can configure a translation
-* offset in the DM by calling dm_set_translation_offset() that
-* will get added to all addresses returned by devfdt_get_addr().
+* offset by setting this value in the GD and enaling this
+* feature via CONFIG_TRANSLATION_OFFSET. This value will
+* get added to all addresses returned by devfdt_get_addr().
*/
- addr += dm_get_translation_offset();
+ addr += gd->translation_offset;
+#endif
return addr;
#else
diff --git a/drivers/core/root.c b/drivers/core/root.c
index e6ec7faf37..8fa096648e 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -25,10 +25,6 @@
DECLARE_GLOBAL_DATA_PTR;
-struct root_priv {
- fdt_addr_t translation_offset; /* optional translation offset */
-};
-
static const struct driver_info root_info = {
.name = "root_driver",
};
@@ -52,22 +48,6 @@ void dm_fixup_for_gd_move(struct global_data *new_gd)
}
}
-fdt_addr_t dm_get_translation_offset(void)
-{
- struct udevice *root = dm_root();
- struct root_priv *priv = dev_get_priv(root);
-
- return priv->translation_offset;
-}
-
-void dm_
[U-Boot] in drivers/mtd/nand/spi/core.c, what means "#ifdef CONFIG_OF"?
prettu sure there is no Kbuild "config OF" setting, should that be #ifdef CONFIG_OF_CONTROL or something related? i checked for the maintainer of that file, but it listed enough alleged maintainers that i thought i would just ask the list. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: imx6: DHCOM i.MX6 PDK: use Kconfig for inclusion of DDR calibration
The four x16 DDR3 are wired in T-topology. From NXP AN4467:
'Although not required, T-Topologies may also benefit from performing
Write Leveling as there are package delays on both the processor and DDR
devices that can be de-skewed by performing Write Leveling. Therefore,
Freescale recommends determining Write Leveling calibration parameters
for all boards, regardless of topology used.'
That is why write level calibration is also done.
Signed-off-by: Ludwig Zenz
---
board/dhelectronics/dh_imx6/dh_imx6_spl.c | 32 +--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
index 04e9eab272a..bbd2dc26828 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
@@ -482,6 +482,29 @@ static void setup_iomux_usb(void)
SETUP_IOMUX_PADS(usb_pads);
}
+/* Perform DDR DRAM calibration */
+static int spl_dram_perform_cal(struct mx6_ddr_sysinfo const *sysinfo)
+{
+ int ret = 0;
+
+#ifdef CONFIG_MX6_DDRCAL
+ udelay(100);
+ ret = mmdc_do_write_level_calibration(sysinfo);
+ if (ret) {
+ printf("DDR3: Write level calibration error [%d]\n", ret);
+ return ret;
+ }
+
+ ret = mmdc_do_dqs_calibration(sysinfo);
+ if (ret) {
+ printf("DDR3: DQS calibration error [%d]\n", ret);
+ return ret;
+ }
+#endif /* CONFIG_MX6_DDRCAL */
+
+ return ret;
+}
+
/* DRAM */
static void dhcom_spl_dram_init(void)
@@ -509,8 +532,7 @@ static void dhcom_spl_dram_init(void)
}
/* Perform DDR DRAM calibration */
- udelay(100);
- mmdc_do_dqs_calibration(&dhcom_ddr_64bit);
+ spl_dram_perform_cal(&dhcom_ddr_64bit);
} else if (is_cpu_type(MXC_CPU_MX6DL)) {
mx6sdl_dram_iocfg(64, &dhcom6sdl_ddr_ioregs,
@@ -528,8 +550,7 @@ static void dhcom_spl_dram_init(void)
}
/* Perform DDR DRAM calibration */
- udelay(100);
- mmdc_do_dqs_calibration(&dhcom_ddr_64bit);
+ spl_dram_perform_cal(&dhcom_ddr_64bit);
} else if (is_cpu_type(MXC_CPU_MX6SOLO)) {
mx6sdl_dram_iocfg(32, &dhcom6sdl_ddr_ioregs,
@@ -552,8 +573,7 @@ static void dhcom_spl_dram_init(void)
}
/* Perform DDR DRAM calibration */
- udelay(100);
- mmdc_do_dqs_calibration(&dhcom_ddr_32bit);
+ spl_dram_perform_cal(&dhcom_ddr_32bit);
}
}
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: imx6: update 1GB DDR3 calibration for DHCOM i.MX6qd PDK
Signed-off-by: Ludwig Zenz
---
board/dhelectronics/dh_imx6/dh_imx6_spl.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
index bbd2dc26828..2939389de39 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
@@ -161,18 +161,18 @@ static const struct mx6_mmdc_calibration
dhcom_mmdc_calib_2x4g_800 = {
};
static const struct mx6_mmdc_calibration dhcom_mmdc_calib_4x2g_1066 = {
- .p0_mpwldectrl0 = 0x0011000E,
- .p0_mpwldectrl1 = 0x000E001B,
- .p1_mpwldectrl0 = 0x00190015,
- .p1_mpwldectrl1 = 0x00070018,
- .p0_mpdgctrl0 = 0x42720306,
- .p0_mpdgctrl1 = 0x026F0266,
- .p1_mpdgctrl0 = 0x4273030A,
- .p1_mpdgctrl1 = 0x02740240,
- .p0_mprddlctl = 0x45393B3E,
- .p1_mprddlctl = 0x403A3747,
- .p0_mpwrdlctl = 0x40434541,
- .p1_mpwrdlctl = 0x473E4A3B,
+ .p0_mpwldectrl0 = 0x001a001a,
+ .p0_mpwldectrl1 = 0x00260015,
+ .p0_mpdgctrl0 = 0x030c0320,
+ .p0_mpdgctrl1 = 0x03100304,
+ .p0_mprddlctl = 0x432e3538,
+ .p0_mpwrdlctl = 0x363f423d,
+ .p1_mpwldectrl0 = 0x0006001e,
+ .p1_mpwldectrl1 = 0x00050015,
+ .p1_mpdgctrl0 = 0x031c0324,
+ .p1_mpdgctrl1 = 0x030c0258,
+ .p1_mprddlctl = 0x3834313f,
+ .p1_mpwrdlctl = 0x47374a42,
};
static const struct mx6_mmdc_calibration dhcom_mmdc_calib_4x2g_800 = {
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] U-Boot API example doesn't support 64-bit
Hello, I'd like to use the U-Boot external API with an ARM64 SoC. If I enable CONFIG_API I get the following build error for the API example: examples/api/crt0.S: Assembler messages: examples/api/crt0.S:33: Error: operand 1 should be an integer register -- `ldr ip,=search_hint' examples/api/crt0.S:34: Error: operand 1 should be an integer register -- `str sp,[ip]' examples/api/crt0.S:40: Error: operand 1 should be an integer register -- `ldr ip,=syscall_ptr' examples/api/crt0.S:41: Error: operand 1 should be an integer register -- `ldr pc,[ip]' scripts/Makefile.build:316: recipe for target 'examples/api/crt0.o' failed For me it seems that the example lacks support for 64-bit. Can anybody help me to get the example running on 64-bit? Apparently I have only very litte knowledge of assembler :-( Best regards Sebastian Priebe SII Technologies GmbH SII Technologies GmbH Geschäftsführer: Robert Bauer Sitz der Gesellschaft: 86167 Augsburg Registergericht: Amtsgericht Augsburg HRB 31802 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] regmap: fix regmap_read_poll_timeout warning about sandbox_timer_add_offset
Hi,
On 12/04/2019 15:09, Simon Glass wrote:
> Hi,
>
> On Thu, 11 Apr 2019 at 09:12, Neil Armstrong wrote:
>>
>> When fixing sandbox test for regmap_read_poll_timeout(), the
>> sandbox_timer_add_offset was introduced but only defined in sandbox code
>> thus generating warnings when used out of sandbox :
>>
>> include/regmap.h:289:2: note: in expansion of macro
>> 'regmap_read_poll_timeout_test'
>> regmap_read_poll_timeout_test(map, addr, val, cond, sleep_us, \
>> ^
>> drivers/spi/meson_spifc.c:169:8: note: in expansion of macro
>> 'regmap_read_poll_timeout'
>> ret = regmap_read_poll_timeout(spifc->regmap, REG_SLAVE, data,
>> ^~~~
>> drivers/spi/meson_spifc.c: In function 'meson_spifc_txrx':
>> include/regmap.h:277:4: warning: implicit declaration of function
>> 'sandbox_timer_add_offset' [-Wimplicit-function-declaration]
>>
>> This simply adds an empty static inline sandbox_timer_add_offset()
>> implementation that will be dropped by the compiler optimization routines.
>>
>> Cc: Simon Glass
>> Reported-by: Tom Rini
>> Fixes: df9cf1cc08 ("test: dm: regmap: Fix the long test delay")
>> Signed-off-by: Neil Armstrong
>> ---
>> include/regmap.h | 4
>> 1 file changed, 4 insertions(+)
>>
>
> This is OK with me, but I wonder if it would be better to change the code:
>
> if (IS_ENABLED(CONFIG_SANDBOX) && test_add_time) \
>sandbox_timer_add_offset(test_add_time); \
>
> to something like
>
>do_test_add_time(test_add_time);
>
> where do_test_add_time() is defined above as either a sandbox call, or empty?
>
> The reason I say this is it seems a bit weird to define a function
> called sandbox_... in non-sandbox code.
Yes, but it still seems weird to have empty test code defined in this header.
Can't we use sandbox_state->skip_delays here instead ?
Neil
>
>> diff --git a/include/regmap.h b/include/regmap.h
>> index 8359c511d2..144cffbcc0 100644
>> --- a/include/regmap.h
>> +++ b/include/regmap.h
>> @@ -239,6 +239,10 @@ int regmap_raw_read_range(struct regmap *map, uint
>> range_num, uint offset,
>> #define regmap_get(map, type, member, valp) \
>> regmap_range_get(map, 0, type, member, valp)
>>
>> +#ifndef CONFIG_SANDBOX
>> +static inline void sandbox_timer_add_offset(unsigned long offset) { }
>> +#endif
>> +
>> /**
>> * regmap_read_poll_timeout - Poll until a condition is met or a timeout
>> occurs
>> *
>> --
>> 2.21.0
>>
>
> Regards,
> Simon
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] net: Add MSCC Serval network driver.
Am 11.04.19 um 14:11 schrieb Horatiu Vultur: > Add network driver for Microsemi Ethernet switch. > It is present on Serval SoCs. > > Signed-off-by: Horatiu Vultur > --- > drivers/net/mscc_eswitch/Kconfig | 7 + > drivers/net/mscc_eswitch/Makefile| 1 + > drivers/net/mscc_eswitch/serval_switch.c | 703 > +++ > 3 files changed, 711 insertions(+) > create mode 100644 drivers/net/mscc_eswitch/serval_switch.c > Reviewed-by: Daniel Schwierzeck -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mips: mscc: serval: Fix reset
Am 11.04.19 um 13:51 schrieb Horatiu Vultur:
> In case the ddr training was failing, it couldn't reset, it was just
> hanging. Therefore reimplement it, so when ddr training is failing
> it would call _machine_restart, which power downs the DDR and does
> a force reset.
>
> Signed-off-by: Horatiu Vultur
> ---
> arch/mips/mach-mscc/include/mach/ddr.h | 14 ++
> arch/mips/mach-mscc/reset.c| 5 +
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/arch/mips/mach-mscc/include/mach/ddr.h
> b/arch/mips/mach-mscc/include/mach/ddr.h
> index 84ecfbd..97dac3e 100644
> --- a/arch/mips/mach-mscc/include/mach/ddr.h
> +++ b/arch/mips/mach-mscc/include/mach/ddr.h
> @@ -464,6 +464,19 @@ static inline void hal_vcoreiii_ddr_reset_assert(void)
> ICPU_RESET_MEM_RST_FORCE, BASE_CFG + ICPU_RESET);
> }
>
> +#if defined(CONFIG_SOC_SERVAL)
> +static inline void hal_vcoreiii_ddr_failed(void)
> +{
> + register u32 reset;
> +
> + pr_err("DDR training failed\n");
> +
> + /* Jump to reset - does not return */
> + reset = KSEG0ADDR(_machine_restart);
> + icache_lock((void *)reset, 128); // Reset while running from cache
> + asm volatile ("jr %0" : : "r" (reset));
> +}
there is no real difference to the current hal_vcoreiii_ddr_failed()
except the GPIO toggling. If that toggling is bad on Serval, couldn't
you simply wrap it with #if !defined(CONFIG_SOC_SERVAL)?
> +#else // JR2 || ServalT
> static inline void hal_vcoreiii_ddr_failed(void)
> {
> writel(0, BASE_CFG + ICPU_RESET);
> @@ -471,6 +484,7 @@ static inline void hal_vcoreiii_ddr_failed(void)
>
> panic("DDR init failed\n");
> }
> +#endif /* Serval */
> #endif /* JR2 || ServalT || Serval */
>
> /*
> diff --git a/arch/mips/mach-mscc/reset.c b/arch/mips/mach-mscc/reset.c
> index a555fc9..95fe0d8 100644
> --- a/arch/mips/mach-mscc/reset.c
> +++ b/arch/mips/mach-mscc/reset.c
> @@ -28,16 +28,13 @@ void _machine_restart(void)
> ICPU_RESET_CORE_RST_FORCE,
> BASE_CFG + ICPU_RESET);
> #elif defined(CONFIG_SOC_SERVAL)
> - register unsigned long i;
> -
> /* Prevent VCore-III from being reset with a global reset */
> writel(ICPU_RESET_CORE_RST_PROTECT, BASE_CFG + ICPU_RESET);
>
> /* Do global reset */
> writel(PERF_SOFT_RST_SOFT_CHIP_RST, BASE_DEVCPU_GCB + PERF_SOFT_RST);
>
> - for (i = 0; i < 1000; i++)
> - ;
> + mdelay(100);
I guess Gregory open-coded that because mdelay() can't run in the very
restricted environment without stack and BSS. If the delay is too short,
maybe you should rather increase the iteration count?
>
> /* Power down DDR for clean DDR re-training */
> writel(readl(BASE_CFG + ICPU_MEMCTRL_CTRL) |
>
--
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-stm32 for v2019.07-rc1
Hi Tom, please pull u-boot-smt32-20190412 including the following STM32 related patches for v2019.07-rc1 - add trusted boot with TF-A for stm32mp1 - stm32mp1 dts files sync'ed with Linux version - add STM32MP1 Discovery boards (DK1 and DK2) - add STMFX gpio expander driver - misc improvement for stm3mp1 supports - rename stpmu1 to stpmic1 (official name) - stm32_qspi: move to exec_op (spi nor driver for stm32 mpu and mcu) - add STM32 FMC2 NAND flash controller driver For trusted boot see bootchain description in WIKI = https://wiki.st.com/stm32mpu/wiki/ These patches are based on ST delivery available https://github.com/STMicroelectronics/u-boot This pull request include 8 series for the stm32mp157 support in U-Boot on the evaluation board (EV1) and on the discovery board support (DK2). - stm32mp1: add trusted boot with TF-A (v4 http://patchwork.ozlabs.org/project/uboot/list/?series=91422) - stm32mp1: update of stm32mp arch and stm32mp1 board (http://patchwork.ozlabs.org/project/uboot/list/?series=94502) - pmic: stpmic1: rename and update stpmic1 driver (http://patchwork.ozlabs.org/project/uboot/list/?series=89855) - Update stm32_sdmmc2 driver and DT bindings (http://patchwork.ozlabs.org/project/uboot/list/?series=91685) - Add STM32MP1 Discovery boards (http://patchwork.ozlabs.org/project/uboot/list/?series=91497) + correction for uart4_pins_a in stm32mp157a-dk1-u-boot.dtsi - Add STMFX gpio expander support for stm32mp157c-ev1 board (http://patchwork.ozlabs.org/project/uboot/list/?series=96427) + stmfx deactivated to avoid race condition corrected by "dm: pinctrl: Avoid race condition on probe for UCLASS_PINCTRL" http://patchwork.ozlabs.org/patch/1047723/ - spi: stm32_qspi: move to exec_op (http://patchwork.ozlabs.org/project/uboot/list/?series=101152) - mtd: rawnand: add STM32 FMC2 NAND flash controller driver (http://patchwork.ozlabs.org/project/uboot/list/?series=101151) Thanks, Patrick The following changes since commit 48ff1bc4f0a97c3291d0c87c2717fc1d79da5ef5: Merge branch '2019-04-09-master-imports-fs' (2019-04-10 08:18:18 -0400) are available in the git repository at: https://github.com/patrickdelaunay/u-boot.git tags/u-boot-stm32-20190412 for you to fetch changes up to 7bb75023a720432a32840c6df543aae92653b23d: mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver (2019-04-12 16:09:13 +0200) stm32 patches for v2019.07-rc1 - Add trusted boot with TF-A for stm32mp1 - stm32mp1 dts files sync'ed with Linux version - add STM32MP1 Discovery boards (DK1 and DK2) - add STMFX gpio expander driver - misc improvement for stm3mp1 supports - rename stpmu1 to stpmic1 (official name) - stm32_qspi: move to exec_op (spi nor driver for stm32 mpu and mcu) - add STM32 FMC2 NAND flash controller driver Christophe Kerello (3): spi: stm32_qspi: move to exec_op dt-bindings: mtd: stm32_fmc2: add STM32 FMC2 NAND controller documentation mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver Patrice Chotard (5): ARM: dts: stm32: Synchronize DT with kernel one board: stm32mp1: Update README file Board: stm32mp1: Add supply current boot information ARM: dts: stm32mp1: Add adc nodes board: stm32mp1: Force pinctrl driver probe in board_init() Patrick Delaunay (33): stm32mp1: add trusted boot with TF-A stm32mp1: bsec: access with SMC for trusted boot stm32mp1: display board information stm32mp1: add runtime information in environment stm32mp1: update boot mode management stm32mp1: update print_cpuinfo() stm32mp1: spl: add spl_display_print stm32mp1: cosmetic cleanup Kconfig stm32mp1: cosmetic: add comment on psci_migrate_info_type return value stm32mp1: spl: hang with trace when DDR init failed stm32mp1: update bootcmd stm32mp1: activate FASTBOOT on eMMC stm32mp1: support forced boot mode stm32mp1: update memory layout stm32mp1: activated some configuration stm32mp1: add some syscon drivers for syscfg and etpzc stm32mp1: add syscfg initialization stm32mp1: align serial number on bootrom stm32mp1: basic boot: SPL enable access to GPIOZ bank stm32mp1: bsec: use device tree new compatible stm32mp1: bsec: shadow all the upper OTP (no secure) during boot stm32mp1: Replace OTP read by SHADOW read regulator: stpmu1: update buck1 range power: stpmu1: rename files to stpmic1 power: rename stpmu1 to official name stpmic1 stpmic1: update register names pmic: stpmu1: add power switch off support stm32mp1: add command poweroff stm32mp1: dts: activate psci-1.0 stpmic1: add NVM update support in fuse command
Re: [U-Boot] [PATCH] regmap: fix regmap_read_poll_timeout warning about sandbox_timer_add_offset
On 12/04/2019 16:56, Neil Armstrong wrote:
> Hi,
>
>
> On 12/04/2019 15:09, Simon Glass wrote:
>> Hi,
>>
>> On Thu, 11 Apr 2019 at 09:12, Neil Armstrong wrote:
>>>
>>> When fixing sandbox test for regmap_read_poll_timeout(), the
>>> sandbox_timer_add_offset was introduced but only defined in sandbox code
>>> thus generating warnings when used out of sandbox :
>>>
>>> include/regmap.h:289:2: note: in expansion of macro
>>> 'regmap_read_poll_timeout_test'
>>> regmap_read_poll_timeout_test(map, addr, val, cond, sleep_us, \
>>> ^
>>> drivers/spi/meson_spifc.c:169:8: note: in expansion of macro
>>> 'regmap_read_poll_timeout'
>>> ret = regmap_read_poll_timeout(spifc->regmap, REG_SLAVE, data,
>>> ^~~~
>>> drivers/spi/meson_spifc.c: In function 'meson_spifc_txrx':
>>> include/regmap.h:277:4: warning: implicit declaration of function
>>> 'sandbox_timer_add_offset' [-Wimplicit-function-declaration]
>>>
>>> This simply adds an empty static inline sandbox_timer_add_offset()
>>> implementation that will be dropped by the compiler optimization routines.
>>>
>>> Cc: Simon Glass
>>> Reported-by: Tom Rini
>>> Fixes: df9cf1cc08 ("test: dm: regmap: Fix the long test delay")
>>> Signed-off-by: Neil Armstrong
>>> ---
>>> include/regmap.h | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>
>> This is OK with me, but I wonder if it would be better to change the code:
>>
>> if (IS_ENABLED(CONFIG_SANDBOX) && test_add_time) \
>>sandbox_timer_add_offset(test_add_time); \
>>
>> to something like
>>
>>do_test_add_time(test_add_time);
>>
>> where do_test_add_time() is defined above as either a sandbox call, or empty?
>>
>> The reason I say this is it seems a bit weird to define a function
>> called sandbox_... in non-sandbox code.
>
> Yes, but it still seems weird to have empty test code defined in this header.
>
> Can't we use sandbox_state->skip_delays here instead ?
What about the following ?
-><
diff --git a/arch/sandbox/include/asm/test.h b/arch/sandbox/include/asm/test.h
index fc52f47f82..e956a05262 100644
--- a/arch/sandbox/include/asm/test.h
+++ b/arch/sandbox/include/asm/test.h
@@ -59,14 +59,6 @@ void sandbox_i2c_eeprom_set_test_mode(struct udevice *dev,
void sandbox_i2c_eeprom_set_offset_len(struct udevice *dev, int offset_len);
-/*
- * sandbox_timer_add_offset()
- *
- * Allow tests to add to the time reported through lib/time.c functions
- * offset: number of milliseconds to advance the system time
- */
-void sandbox_timer_add_offset(unsigned long offset);
-
/**
* sandbox_i2c_rtc_set_offset() - set the time offset from system/base time
*
diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index 397e7561d4..9ca1eca027 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -31,7 +31,7 @@ void flush_cache(unsigned long start, unsigned long size)
/* system timer offset in ms */
static unsigned long sandbox_timer_offset;
-void sandbox_timer_add_offset(unsigned long offset)
+void timer_test_add_offset(unsigned long offset)
{
sandbox_timer_offset += offset;
}
diff --git a/drivers/net/sandbox.c b/drivers/net/sandbox.c
index decce2fa59..c136392350 100644
--- a/drivers/net/sandbox.c
+++ b/drivers/net/sandbox.c
@@ -350,7 +350,7 @@ static int sb_eth_recv(struct udevice *dev, int flags,
uchar **packetp)
struct eth_sandbox_priv *priv = dev_get_priv(dev);
if (skip_timeout) {
- sandbox_timer_add_offset(11000UL);
+ timer_test_add_offset(11000UL);
skip_timeout = false;
}
diff --git a/drivers/timer/sandbox_timer.c b/drivers/timer/sandbox_timer.c
index 6d2b045fe8..5228486082 100644
--- a/drivers/timer/sandbox_timer.c
+++ b/drivers/timer/sandbox_timer.c
@@ -14,7 +14,7 @@
/* system timer offset in ms */
static unsigned long sandbox_timer_offset;
-void sandbox_timer_add_offset(unsigned long offset)
+void timer_test_add_offset(unsigned long offset)
{
sandbox_timer_offset += offset;
}
diff --git a/include/regmap.h b/include/regmap.h
index 8359c511d2..3cd7a66cea 100644
--- a/include/regmap.h
+++ b/include/regmap.h
@@ -274,7 +274,7 @@ int regmap_raw_read_range(struct regmap *map, uint
range_num, uint offset,
if (cond) \
break; \
if (IS_ENABLED(CONFIG_SANDBOX) && test_add_time) \
- sandbox_timer_add_offset(test_add_time); \
+ timer_test_add_offset(test_add_time); \
if ((timeout_ms) && get_timer(__start) > (timeout_ms)) { \
__ret = regmap_read((map), (addr), &(val)); \
break; \
diff --git a/include/time.h b/include/time.h
index 825991e222..9fd0d73fb4 100644
--- a/include/time.h
+++ b/include/time.h
@@ -13,6 +13,14 @@ unsigned long get_timer(unsigned long base);
*/
unsigned long timer_get_us(void);
+/*
+ * timer_test_add_offset()
+ *
Re: [U-Boot] [U-Boot, v4, 3/7] soc: ti: k3: add CPPI5 description and helpers
On Tue, Feb 05, 2019 at 05:31:23PM +0530, Vignesh R wrote: > From: Grygorii Strashko > > Add TI Communications Port Programming Interface (CPPI) 5 > interface description and helpers > > Signed-off-by: Grygorii Strashko > Signed-off-by: Vignesh R > Reviewed-by: Tom Rini 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] [U-Boot, v4, 1/7] firmware: ti_sci: Add support for NAVSS resource management
On Tue, Feb 05, 2019 at 05:31:21PM +0530, Vignesh R wrote: > From: Grygorii Strashko > > Texas Instruments' System Control Interface (TI-SCI) Message Protocol > abstracts management of NAVSS resources, like PSI-L pairing and > unpairing, UDMAP tx/rx/flow configuration and Rings. > > This patch adds support for requesting and configuring such resources > from TI-SCI firmware. > > Signed-off-by: Peter Ujfalusi > Signed-off-by: Grygorii Strashko > Reviewed-by: Tom Rini > Signed-off-by: Vignesh R 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] [U-Boot,v2,0/7] AM65x HS device support
On Thu, Feb 21, 2019 at 04:35:05PM -0600, Andrew F. Davis wrote: > Hello all, > > This series brings up HS device support on the AM65x platform. Support > for HS on K3 family devices is a bit different than previous devices > but for the most part all that has been abstracted into the SECDEV > package, allowing for a rather straight forward implementation here. > > Thanks, > Andrew > > Changes from v1: > - Commented on use of .data section > - Use ti_sci_msg_hdr header directly when possible > - Rebase and add Reviewed-bys > - Will add makefile cleanup later as it also affects >files unrelated to this series > > Andrew F. Davis (7): > arm: K3: Avoid use of MCU_PSRAM0 before SYSFW is loaded > firmware: ti_sci: Add support for firewall management > firmware: ti_sci: Modify auth_boot TI-SCI API to match new version > arm: mach-k3: Add secure device support > arm: mach-k3: Add secure device build support > configs: Add a config for AM65x High Security EVM > doc: Update info on using K3 secure devices Can you please rebase this on master and repost? 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] [U-Boot, v4, 7/7] configs: am65x_evm_a53: Enable DMA related configs
On Tue, Feb 05, 2019 at 05:31:27PM +0530, Vignesh R wrote: > From: Grygorii Strashko > > Enable TI K3 AM65x PSI-L, Ring Accelerator and UDMA drivers > > Signed-off-by: Grygorii Strashko > Signed-off-by: Vignesh R > Reviewed-by: Tom Rini 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] [U-Boot, v4, 6/7] arm64: dts: ti: k3-am65: add mcu navss nodes
On Tue, Feb 05, 2019 at 05:31:26PM +0530, Vignesh R wrote: > From: Grygorii Strashko > > Add DT node for MCU NAVSS its components to get DMA working on AM654 > SoC. > > Signed-off-by: Grygorii Strashko > Signed-off-by: Vignesh R > Reviewed-by: Tom Rini 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] [U-Boot,v4,4/7] dma: ti: add driver to K3 UDMA
On Tue, Feb 05, 2019 at 05:31:24PM +0530, Vignesh R wrote: > The UDMA-P is intended to perform similar (but significantly upgraded) > functions > as the packet-oriented DMA used on previous SoC devices. The UDMA-P module > supports the transmission and reception of various packet types. > The UDMA-P also supports acting as both a UTC and UDMA-C for its internal > channels. Channels in the UDMA-P can be configured to be either Packet-Based > or > Third-Party channels on a channel by channel basis. > > The initial driver supports: > - MEM_TO_MEM (TR mode) > - DEV_TO_MEM (Packet mode) > - MEM_TO_DEV (Packet mode) > > Signed-off-by: Peter Ujfalusi > Signed-off-by: Grygorii Strashko > Signed-off-by: Vignesh R 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] [U-Boot,v4,2/7] soc: ti: k3: add navss ringacc driver
On Tue, Feb 05, 2019 at 05:31:22PM +0530, Vignesh R wrote: > From: Grygorii Strashko > > The Ring Accelerator (RINGACC or RA) provides hardware acceleration to > enable straightforward passing of work between a producer and a consumer. > There is one RINGACC module per NAVSS on TI AM65x SoCs. > > The RINGACC converts constant-address read and write accesses to equivalent > read or write accesses to a circular data structure in memory. The RINGACC > eliminates the need for each DMA controller which needs to access ring > elements from having to know the current state of the ring (base address, > current offset). The DMA controller performs a read or write access to a > specific address range (which maps to the source interface on the RINGACC) > and the RINGACC replaces the address for the transaction with a new address > which corresponds to the head or tail element of the ring (head for reads, > tail for writes). Since the RINGACC maintains the state, multiple DMA > controllers or channels are allowed to coherently share the same rings as > applicable. The RINGACC is able to place data which is destined towards > software into cached memory directly. > > Supported ring modes: > - Ring Mode > - Messaging Mode > - Credentials Mode > - Queue Manager Mode > > TI-SCI integration: > > Texas Instrument's System Control Interface (TI-SCI) Message Protocol now > has control over Ringacc module resources management (RM) and Rings > configuration. > > The Ringacc driver manages Rings allocation by itself now and requests > TI-SCI firmware to allocate and configure specific Rings only. It's done > this way because, Linux driver implements two stage Rings allocation and > configuration (allocate ring and configure ring) while TI-SCI Message > Protocol supports only one combined operation (allocate+configure). > > Signed-off-by: Grygorii Strashko > Signed-off-by: Vignesh R 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] [U-Boot, v4, 5/7] soc: keystone: Merge into ti specific directory
On Tue, Feb 05, 2019 at 05:31:25PM +0530, Vignesh R wrote: > Merge drivers/soc/keystone/ into drivers/soc/ti/ > and convert CONFIG_TI_KEYSTONE_SERDES into Kconfig. > > Signed-off-by: Vignesh R > Reviewed-by: Tom Rini 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] [U-Boot, v3, 3/3] am335x, guardian: Add support for the bosch guardian board
On Mon, Feb 25, 2019 at 03:33:00PM +, Martyn Welch wrote: > From: Sjoerd Simons > > Add support for the Bosch Guardian board. > > CPU : AM335X-GP rev 2.1 > Model: Bosch AM335x Guardian > I2C: ready > DRAM: 256 MiB > NAND: 512 MiB > MMC: OMAP SD/MMC: 0 > > Signed-off-by: Sjoerd Simons > Signed-off-by: Martyn Welch > Reviewed-by: Tom Rini > Reviewed-by: Felix Brack 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] [U-Boot, v3, 01/13] arm64: dts: k3: Sync sdhci0 node from kernel
On Tue, Feb 12, 2019 at 02:28:07PM +0530, Faiz Abbas wrote: > Sync the sdhci0 node from kernel. This changes the compatible that is > required to be there in the driver. Change the same for the SD card node > which is not yet supported in kernel. > > Also sync the main_pmx0 node as a side effect. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot,v3,02/13] mmc: am654_mmc: Change driver name
On Tue, Feb 12, 2019 at 02:28:08PM +0530, Faiz Abbas wrote: > This driver works with the sdhci controller present on TI's AM65x devices. > Change the name to make this clearer and match the compatible with > kernel. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, v3, 08/13] arm: dts: k3: Add phy specific properties to SD card node
On Tue, Feb 12, 2019 at 02:28:14PM +0530, Faiz Abbas wrote: > With changes in the driver requiring phy related properties, > add the same for the SD card node to prevent breaking boot with > the driver update. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, v3, 1/3] Add support for the MT41K128M16JT125K memory modules
On Mon, Feb 25, 2019 at 03:32:58PM +, Martyn Welch wrote: > From: Sjoerd Simons > > Add configuration for the MT41K128M16JT125K memory modules as used on the > Bosch Guardian device. > > Based on a patch by: > Govindaraji Sivanantham > > Signed-off-by: Sjoerd Simons > [checkpatch.pl cleanup by Martyn Welch] > Signed-off-by: Martyn Welch 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] [U-Boot,v3,03/13] mmc: am654_sdhci: Remove quirks
On Tue, Feb 12, 2019 at 02:28:09PM +0530, Faiz Abbas wrote: > The host controller works perfectly well without having to add any > quirks. Remove them. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, v3, 09/13] mmc: sdhci: Make set_ios_post() return int
On Tue, Feb 12, 2019 at 02:28:15PM +0530, Faiz Abbas wrote: > Make set_ios_post() return int to faciliate error handling in > platform drivers. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, v3, 06/13] mmc: sdhci: Add support for sdhci-caps-mask
On Tue, Feb 12, 2019 at 02:28:12PM +0530, Faiz Abbas wrote: > Add Support for masking some bits in the capabilities > register of a host controller. > > Also remove the redundant readl() into caps1. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, v3, 07/13] mmc: sdhci: Make sdhci_set_clock() non static
On Tue, Feb 12, 2019 at 02:28:13PM +0530, Faiz Abbas wrote: > The am654_sdhci driver needs to switch the clock off > before disabling its phy dll and needs to re-enable > the clock before enabling the phy again. > > Therefore, make the sdhci_set_clock() function accessible > in the am654_sdhci driver. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, v3, 7/7] ARM: dts: k2g-ice: add dt node for netcp
On Thu, Feb 21, 2019 at 12:02:07PM -0500, Murali Karicheri wrote: > This patch adds dt node for DP83867 phy used on K2G ICE board and > also enable netcp device nodes for the board. > > EVM hardware spec recommends to add 0.25 nsec delay in the tx > direction and 2.25 nsec delay in the rx direction for internal > delay in the clock path to be on the safer side. > > The board straps RX_DV/RX_CTRL pin of on board DP83867 phy in mode > 1. Unfortunately, the phy data manual disallows this. Add > ti,dp83867-rxctrl-strap-quirk in the phy node to allow software to > enable workaround suggested for this incorrect strap setting. This > ensures proper operation of this PHY. > > The dts bindings are kept in sync with that from 4.14.y linux > kernel. This required the pinmux device related bindings to be > commented out to allow for compilation. > > Signed-off-by: Murali Karicheri > Acked-by: Joe Hershberger 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] [U-Boot, v3, 13/13] mmc: am654_sdhci: Add a platform specific set_control_reg() callback
On Tue, Feb 12, 2019 at 02:28:19PM +0530, Faiz Abbas wrote: > From: Faiz Abbas > > Add a platform specific set_control_reg() callback to help switch to > UHS speed modes. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, v3, 06/13] mmc: sdhci: Add support for sdhci-caps-mask
On Tue, Feb 12, 2019 at 02:28:12PM +0530, Faiz Abbas wrote: > Add Support for masking some bits in the capabilities > register of a host controller. > > Also remove the redundant readl() into caps1. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, v3, 04/13] regmap: Add API regmap_init_mem_index()
On Tue, Feb 12, 2019 at 02:28:10PM +0530, Faiz Abbas wrote: > In device nodes with more than one entry in the reg property, > it is sometimes useful to regmap only of the entries. Add an > API regmap_init_mem_index() to facilitate this. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, v2, 2/3] ARM: dts: dra71-evm: Correct evm_sd regulator max voltage
On Fri, Apr 05, 2019 at 02:18:45PM +0530, Faiz Abbas wrote: > Correct vpo_sd_1v8_3v3 regulator max voltage to 3.3V > > Signed-off-by: Faiz Abbas > Reviewed-by: Keerthy 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] [U-Boot, v3, 2/7] ARM: k2g-gp-evm: update to rgmii pinmux configuration
On Thu, Feb 21, 2019 at 12:02:02PM -0500, Murali Karicheri wrote: > This patch updates pinmux configuration for K2G GP EVM based on > data generated by the pinmux tool at > https://dev.ti.com/pinmux/app.html#/default > > Signed-off-by: Murali Karicheri > Reviewed-by: Lokesh Vutla 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
[U-Boot] doing anything about "bad" Kbuild configuration options?
only a few months ago, i jumped into a discussion regarding Kbuild
config options that were defined in some Kconfig* file, but were
unused anywhere in the source tree:
http://u-boot.10912.n7.nabble.com/policy-regarding-unused-code-td351802.html#a351835
many years ago, i wrote a script to locate such entries in the linux
kernel source tree and, once u-boot adoopted the Kbuild build system,
i could obviously use the same script on the u-boot source -- so far,
so good. but i wrote some associated scripts to locate other oddities,
and one of them was to find what i called "badref" options.
now, "unused" options are typically not serious -- a Kbuild option
is defined that is simply not tested anywhere in the source. normally,
that's because someone removed some source and just forgot to remove
the associated Kconfig option.
"badref" options, on the other hand, are exactly the opposite --
options that *are* tested somewhere in the code, but are not defined
anywhere in a Kconfig file. in short, the code is testing some
CONFIG_* option that will never, ever succeed as it isn't defined,
which should typically be treated as a potentially more serious issue.
i wrote up an example of this here:
https://crashcourse.ca/dokuwiki/doku.php?id=u-boot_badref
where you can see the result of running the script and asking it to
scan the entire u-boot "drivers" directory once upon a time -- the
output consists of a string for which the corresponding
CONFIG_ is being tested somewhere in the argument directory,
but for which there is no apparent Kconfig definition; the output for
each string consists of a tree-wide search for that string.
as an example, note the very first example found:
> ACX517AKN
drivers/video/pxa_lcd.c:201:#ifdef CONFIG_ACX517AKN
drivers/video/pxa_lcd.c:231:#endif /* CONFIG_ACX517AKN */
drivers/video/pxa_lcd.c:297:#endif /* CONFIG_ACX517AKN */
scripts/config_whitelist.txt:15:CONFIG_ACX517AKN
so CONFIG_ACX517AKN is clearly being tested, while there is no
definition for that option *anywhere* in the tree. (the script might
not be perfect, there might be the occasional false negative or
positive, but one can always verify manually if there's any doubt.)
one of the worst culprits appears to be CONFIG_SPL_BUILD, which
appears all over the tree, but one can see a recent commit that takes
that into account:
commit 0ef692084363f2de8547db93397c6a69123d26ca
Author: Baruch Siach
Date: Thu Feb 7 13:21:16 2019 +0200
Kconfig: fix BUILD_TARGET for ARCH_MVEBU
Commit dc146ca11187 ("Kconfig: Migrate CONFIG_BUILD_TARGET") made the
mvebu default build target depend on CONFIG_SPL_BUILD. Unfortunately,
there is no such Kconfig symbol. Use the CONFIG_SPL symbol instead to
fix that.
Cc: Jagan Teki
Signed-off-by: Baruch Siach
Reviewed-by: Stefan Roese
Reviewed-by: Jagan Teki
Signed-off-by: Stefan Roese
the output for that example in my wiki page is a bit overwhelming,
which is why my badref script takes an optional directory to search,
so you can focus your attention as finely as you want. as an example,
check only drivers/mmc, which appears to find exactly four bad
references:
$ find_badref_configs.sh drivers/mmc
> HSMMC3_8BIT
drivers/mmc/omap_hsmmc.c:1577:#if defined(CONFIG_DRA7XX) &&
defined(CONFIG_HSMMC3_8BIT)
> MMC_RPMB_TRACE
drivers/mmc/rpmb.c:98:#ifdef CONFIG_MMC_RPMB_TRACE
drivers/mmc/rpmb.c:115:#ifdef CONFIG_MMC_RPMB_TRACE
drivers/mmc/rpmb.c:131:#ifdef CONFIG_MMC_RPMB_TRACE
drivers/mmc/rpmb.c:147:#ifdef CONFIG_MMC_RPMB_TRACE
drivers/mmc/rpmb.c:154:#ifdef CONFIG_MMC_RPMB_TRACE
scripts/config_whitelist.txt:1225:CONFIG_MMC_RPMB_TRACE
> MMC_SPI_CRC_ON
drivers/mmc/mmc_spi.c:94:#ifdef CONFIG_MMC_SPI_CRC_ON
drivers/mmc/mmc_spi.c:123:#ifdef CONFIG_MMC_SPI_CRC_ON
drivers/mmc/mmc.c:2259:#ifdef CONFIG_MMC_SPI_CRC_ON
scripts/config_whitelist.txt:1228:CONFIG_MMC_SPI_CRC_ON
arch/arm/include/asm/arch-pxa/regs-mmc.h:66:#define MMC_SPI_CRC_ON
(1 << 1)
> ZYNQ_HISPD_BROKEN
drivers/mmc/zynq_sdhci.c:263:#ifdef CONFIG_ZYNQ_HISPD_BROKEN
scripts/config_whitelist.txt:4637:CONFIG_ZYNQ_HISPD_BROKEN
$
in any event, i am not planning to do anything about this, i just
thought others might want to check whatever part of the code base for
which they are a maintainer, and see if any such things exist. and as
forrest gump once said, "that's all i have to say about that."
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 10/13] mmc: am654_sdhci: Add Support for PHY
On Tue, Feb 12, 2019 at 02:28:16PM +0530, Faiz Abbas wrote: > Add support in the driver for handling phy specific registers. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, V3, 2/2] ARM: davinci: da850evm: Enable SPL_OF_CONTROL without PLATDATA
On Mon, Feb 25, 2019 at 09:53:47PM -0600, Adam Ford wrote: > With the memory mapping giving us some more avialable RAM, this > updates the da850-evm-u-boot.dtsi to include the serial port, SPI > and Flash nodes along with some dependent nodes in the SPL dtb. > This also removes the platform data initialization code for the > serial port and SPI Flash. > > Signed-off-by: Adam Ford 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] [U-Boot, PATCHv2, 1/2] ti: keystone2: Move CONFIG_ISW_ENTRY_ADDR to a common place
On Tue, Mar 19, 2019 at 07:14:37AM -0400, Tom Rini wrote: > The ISW_ENTRY_ADDR Kconfig option under mach-omap2 isn't a SoC specific > notion but rather "where is our previous stage loaded in memory?" > option. Make use of this on ARCH_KEYSTONE rather than SPL_TEXT_BASE for > our HS builds that are not using SPL anyhow. > > Cc: Vitaly Andrianov > Cc: Andrew F. Davis > Cc: Lokesh Vutla > Signed-off-by: Tom Rini > Reviewed-by: Lokesh Vutla signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 11/13] configs: am65x_evm: Enable CONFIG_REGMAP
On Tue, Feb 12, 2019 at 02:28:17PM +0530, Faiz Abbas wrote: > Add Support for CONFIG_REGMAP. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, v2, 1/4] board: ti: dra71: Add pinmux settings for NAND on DRA71x EVM
On Wed, Feb 27, 2019 at 01:29:35PM +0530, Faiz Abbas wrote: > From: Franklin S Cooper Jr > > By default VOUT3 occupies the pins required for NAND. Therefore, create > a seperate entry that can be use to reconfigure these pins to work for > NAND. > > On the EVM SWITCH 8 pins 0 and 1 will be used to determine if NAND is > enabled or not. For NAND to be selected pin 0 should be on and pin 1 > should be off. Any other combination will assume NAND shouldn't be > enabled. > > Signed-off-by: Franklin S Cooper Jr > Signed-off-by: Faiz Abbas 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] [U-Boot, v3, 12/13] mmc: sdhci: Add support for HOST_CONTROL2 and setting UHS timings
On Tue, Feb 12, 2019 at 02:28:18PM +0530, Faiz Abbas wrote: > From: Faiz Abbas > > The HOST_CONTROL2 register is a part of SDHC v3.00 and not just specific > to arasan/zynq controllers. Add the same to sdhci.h. > > Also create a common API to set UHS timings in HOST_CONTROL2. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, 03/11] net: ti: cpsw: Convert cpsw_platform_data to a pointer in cpsw_priv
On Mon, Mar 18, 2019 at 01:54:33PM +0530, Faiz Abbas wrote: > Convert cpsw_platform_data to a pointer in cpsw_priv. Allocate it > dynamically and assign it as a part of eth_pdata. This helps in > isolating platform data handling and implementing platdata for SPL > in a board file. > > Signed-off-by: Faiz Abbas 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] [U-Boot, 1/5] firmware: Add support for querying msmc memory
On Fri, Mar 08, 2019 at 11:47:32AM +0530, Lokesh Vutla wrote: > DMSC can use certain amount of msmc memory available in the > system. Also certain part of msmc memory can be marked as L3 > cache using board config. But users might not know what size > is being used and the remaining available msmc memory. In order > to fix this TISCI protocol provides a messages that can query > the available msmc memory in the system. Add support for this > message. > > Signed-off-by: Lokesh Vutla 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] [U-Boot, v3, 05/13] regmap: Add support for polling on a register
On Tue, Feb 12, 2019 at 02:28:11PM +0530, Faiz Abbas wrote: > Add an API to continuously read a register until a condition is > satisfied or a timeout occurs. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, v3, 2/3] env: Don't check CONFIG_ENV_OFFSET_REDUND for SPL build
On Mon, Feb 25, 2019 at 03:32:59PM +, Martyn Welch wrote: > When booting using an SPL on am335x, if we want to support booting with > the boot ROM loader via USB (which uses RNDIS, making bootp and tftp > calls) we need to enable gadget eth in the SPL to load the main U-Boot > image. To enable CONFIG_SPL_ETH_SUPPORT, we must enable > CONFIG_SPL_ENV_SUPPORT as the environment is used by the eth support, but > we don't actually need to have environment variables saved in the SPL > environment. We do however have environment variables saved in the main > U-Boot image and enable CONFIG_ENV_OFFSET_REDUND (we are storing in raw > NAND). In such instances, even with the build config enabling both > CONFIG_CMD_SAVEENV and CONFIG_CMD_NAND, these options aren't set when > building the SPL, but CONFIG_ENV_OFFSET_REDUND still is. > > Don't check this configuration option for SPL builds to enable the above > configuration. > > Signed-off-by: Martyn Welch > Reviewed-by: Tom Rini 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] [U-Boot, v2, 3/4] configs: dra71x-evm: Add Support for NAND
On Wed, Feb 27, 2019 at 01:29:37PM +0530, Faiz Abbas wrote: > Add NAND support to dra71x-evm defconfig > > Signed-off-by: Faiz Abbas 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] [U-Boot, v3, 4/7] ARM: k2g: add a workaround to reset the phy
On Thu, Feb 21, 2019 at 12:02:04PM -0500, Murali Karicheri wrote: > This patch adds a workaround to reset the phy one time during boot > using GPIO0 pin 10 to make sure, the Phy latches the configuration > from the input pins correctly. > > Signed-off-by: Murali Karicheri > Acked-by: Joe Hershberger 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] am57xx_evm_defconfig: Enable configs to support QSPI boot
On Fri, Feb 22, 2019 at 11:01:52AM +0530, Vignesh R wrote: > AM57xx IDK EVMs can boot out of QSPI. Enable configs to support QSPI > boot. Also enable configs for updating QSPI boot images over DFU. > > Tested on AM572x IDK EVM. > > Signed-off-by: Vignesh R > Reviewed-by: Tom Rini 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] [U-Boot, v3, 3/7] net: netcp: add support for phy with rgmii ids
On Thu, Feb 21, 2019 at 12:02:03PM -0500, Murali Karicheri wrote: > Enhance the netcp driver to support phys that can be configured > for internal delay (rgmii-id, rgmii-rxid, rgmii-txid) > > Signed-off-by: Murali Karicheri > Acked-by: Joe Hershberger 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] [U-Boot, v2, 2/4] arm: dra7: Allow NAND to be enabled on DRA71x EVM.
On Wed, Feb 27, 2019 at 01:29:36PM +0530, Faiz Abbas wrote: > From: Franklin S Cooper Jr > > If SW 8 pins 0 and 1 indicate that NAND should be enabled then > the pins pinmux must be reconfigured for NAND mode. > > Therefore, enable NAND by reconfiguring the pinmux. > > Signed-off-by: Franklin S Cooper Jr > Signed-off-by: Faiz Abbas 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] [U-Boot, 07/11] board: ti: am335x: Add platdata for cpsw in SPL
On Mon, Mar 18, 2019 at 01:54:37PM +0530, Faiz Abbas wrote: > The SPL image overflows when cpsw dt nodes are added and SPL_OF_CONTROL > is enabled. Use static platdata instead to save space. > > Signed-off-by: Faiz Abbas 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] [U-Boot, 02/11] net: ti: cpsw: Move cpsw_phy_sel() to _probe()
On Mon, Mar 18, 2019 at 01:54:32PM +0530, Faiz Abbas wrote: > cpsw_phy_sel() is a configuration step that should not be in > ofdata_to_platdata(). Add phy_sel_compat to the cpsw_platform_data > structure so that it is accessible in _probe. Then move the call of > cpsw_phy_sel() to _probe. > > Signed-off-by: Faiz Abbas 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] [U-Boot,10/11] configs: am335x_evm: Update VCI String
On Mon, Mar 18, 2019 at 01:54:40PM +0530, Faiz Abbas wrote: > Update VCI string to keep it compatible with legacy test setups. > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] ARM: am3517_evm: Add spl_start_uboot for Falcon Mode
On Sun, Mar 31, 2019 at 09:18:29AM -0500, Adam Ford wrote:
> When booting the am3517-evm, the following message appears:
> SPL: Please implement spl_start_uboot() for your board
> SPL: Direct Linux boot not active!
>
> This patch implements spl_start_uboot to clear this message
> and allow device to know if it should boot U-Boot or kernel.
>
> Fixes: 1c6b6f383a41 ("ARM: am3517_evm: Enable Falcon Mode")
>
> Signed-off-by: Adam Ford
>
> diff --git a/board/logicpd/am3517evm/am3517evm.c
> b/board/logicpd/am3517evm/am3517evm.c
> index 6f728398c3..10031a4801 100644
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] [U-Boot, v2, 1/3] ARM: dts: dra7: Change pbias voltage to 3.3V
On Fri, Apr 05, 2019 at 02:18:44PM +0530, Faiz Abbas wrote: > As per recent TRM[1], PBIAS cell on dra7 devices supports > 3.3v and not 3.0v as documented earlier. > > Update PBIAS regulator max voltage and the voltage written > in the driver to reflect this. > > [1] http://www.ti.com/lit/pdf/sprui30 > > Signed-off-by: Faiz Abbas 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] [U-Boot, 5/5] configs: am65x_evm_a53: Enable CONFIG_OF_BOARD_SETUP
On Fri, Mar 08, 2019 at 11:47:36AM +0530, Lokesh Vutla wrote: > Enable CONFIG_OF_BOARD_SETUP so that msmc sram dt nodes > are updated correctly. > > Signed-off-by: Lokesh Vutla 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] [U-Boot, 09/11] configs: am335x_evm: Add Support for SPL_ETH
On Mon, Mar 18, 2019 at 01:54:39PM +0530, Faiz Abbas wrote: > Add Support for booting from Ethernet. > > Signed-off-by: Faiz Abbas 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] [U-Boot, 04/11] net: ti: cpsw-common: Isolate getting syscon address from assigning macid
On Mon, Mar 18, 2019 at 01:54:34PM +0530, Faiz Abbas wrote: > ti_cm_get_macid() is used to get a syscon node from the dt, read the > efuse address and then assign the macid read from the address. Divide > these two steps into separate functions one of which can be called from > ofdata_to_platdata() while the other can be called from _probe(). This > ensures that platdata can be assigned statically in a board file when > OF_CONTROL is not enabled. Also add a macid_sel_compat in private data > to get information about the macid byte placement. > > Signed-off-by: Faiz Abbas 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] [U-Boot, v3, 1/7] ARM: k2g-ice: Add pinmux support for rgmii interface
On Thu, Feb 21, 2019 at 12:02:01PM -0500, Murali Karicheri wrote: > This add pinmux configuration for rgmii interface so that network > driver can be supported on K2G ICE boards. The pinmux configurations > for this are generated using the pinmux tool at > https://dev.ti.com/pinmux/app.html#/default > > As this required some BUFFER_CLASS definitions, same is re-used > from the linux defnitions in include/dt-bindings/pinctrl/keystone.h > > Signed-off-by: Murali Karicheri > Reviewed-by: Lokesh Vutla > Acked-by: Joe Hershberger 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] [U-Boot,01/11] net: Add priv_pdata to eth_pdata
On Mon, Mar 18, 2019 at 01:54:31PM +0530, Faiz Abbas wrote: > Add a priv member for eth_pdata for platform specific platform data. > > Signed-off-by: Faiz Abbas 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] [U-Boot, v3, 5/7] ARM: dts: k2g-evm: remove unused phy-mode property from phy node
On Thu, Feb 21, 2019 at 12:02:05PM -0500, Murali Karicheri wrote: > This patch removes the unused phy-mode property from the phy dt node. On > K2G, currently link-interface determines if phy is used or not and is > already set to use rgmii. So this is not needed. Besides phy-mode should > be added to slave interface configuration of the cpsw driver, not in the > phy node. > > Signed-off-by: Murali Karicheri > Acked-by: Joe Hershberger 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] [U-Boot, 2/5] arm: k3: Add a wrapper to get tisci handle
On Fri, Mar 08, 2019 at 11:47:33AM +0530, Lokesh Vutla wrote: > Create a wrapper to get the ti sci handle. > > Signed-off-by: Lokesh Vutla 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] armv7R: K3: am654: Trigger panic on DDR init failures
On Mon, Mar 11, 2019 at 03:15:43PM -0500, Andreas Dannenberg wrote: > When initializing DDR from R5 SPL trigger U-Boot's panic facility > rather than simply returning from the board init function as there > is little point continuing code execution. Further, as panic implies > a board reset, so using it might potentially allow to recover from > this error in certain cases such as when the init failure was caused > by a temporary glitch of some sorts. > > Signed-off-by: Andreas Dannenberg > Reviewed-by: Lokesh Vutla 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] [U-Boot, v2, 3/3] mmc: omap_hsmmc: Set 3.3V for IO voltage
On Fri, Apr 05, 2019 at 02:18:46PM +0530, Faiz Abbas wrote: > Pbias voltage should match the IO voltage set for the SD card. With the > latest pbias change to 3.3V, update the capabilities and IO voltages > settings to 3.3V. > > Signed-off-by: Faiz Abbas 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] [U-Boot, V3, 1/2] davinci: da850evm/omapl138-lcdk: Move BSS to SDRAM because SRAM is full
On Mon, Feb 25, 2019 at 09:53:46PM -0600, Adam Ford wrote: > In order to fully support SPL_OF_CONTROL, we need BSS to be a bit > larger. This patch relocates BSS to SDRAM instead of SRAM which > is similar to how ARMv7 boards (like OMAP2+) do it. > > This means two new variables are required: > CONFIG_SPL_BSS_START_ADDR set to DAVINCI_DDR_EMIF_DATA_BASE > CONFIG_SPL_BSS_MAX_SIZE is set to 0x108 which is 1 byte > before the location where U-Boot will load. > > Signed-off-by: Adam Ford 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] [U-Boot, v2, 4/4] configs: ti_omap5_common: Add NAND environment settings
On Wed, Feb 27, 2019 at 01:29:38PM +0530, Faiz Abbas wrote: > Now that NAND is supported on DRA71x include various NAND environment > settings > > Signed-off-by: Faiz Abbas > Reviewed-by: Tom Rini 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] [U-Boot, 08/11] configs: am335x_evm: Reduce size of SPL
On Mon, Mar 18, 2019 at 01:54:38PM +0530, Faiz Abbas wrote: > Make some room in SPL by getting rid of unnecessary configs. > > Signed-off-by: Faiz Abbas 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] [U-Boot, v3, 6/7] k2g: config enable ti phy dp83867 for k2g
On Thu, Feb 21, 2019 at 12:02:06PM -0500, Murali Karicheri wrote: > Enable ti phy dp83867 for k2g > > Signed-off-by: Murali Karicheri > Reviewed-by: Tom Rini > Acked-by: Joe Hershberger 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] [U-Boot, 3/5] arm: k3: Add support for updating msmc dt node
On Fri, Mar 08, 2019 at 11:47:34AM +0530, Lokesh Vutla wrote: > Certain parts of msmc sram can be used by DMSC or can be > marked as L3 cache. Since the available size can vary, changing > DT every time the size varies might be painful. So, query this > information using TISCI cmd and fixup the DT for kernel. > Fixing up DT does the following: > - Create a sram node if not available > - update the reg property with available size > - update ranges property > - loop through available sub nodes and delete it if: > - mentioned size is out if available range > - subnode represents l3 cache or dmsc usage. > > Signed-off-by: Lokesh Vutla 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] [U-Boot, 06/11] net: ti: cpsw: Enable DM_FLAG_PRE_RELOC
On Mon, Mar 18, 2019 at 01:54:36PM +0530, Faiz Abbas wrote: > Add DM_FLAG_PRE_RELOC to make the driver probe in SPL. > > Signed-off-by: Faiz Abbas 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] [U-Boot, 11/11] board: ti: am335x: Remove non DM_ETH code
On Mon, Mar 18, 2019 at 01:54:41PM +0530, Faiz Abbas wrote: > With DM_ETH enabled in am335x devices, remove all the unused > non-DM code. > > Signed-off-by: Faiz Abbas 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] [U-Boot, 05/11] net: ti: cpsw: Block off ofdata_to_platdata with OF_CONTROL
On Mon, Mar 18, 2019 at 01:54:35PM +0530, Faiz Abbas wrote: > The ofdata_to_platdata function should not be called if OF_CONTROL is > not enabled because fdtdec_* calls will fail. Block the function with > OF_CONTROL > > Signed-off-by: Faiz Abbas 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] doing anything about "bad" Kbuild configuration options?
at risk of boring, i'll mention a couple more scripts i have for locating oddities or inconsistencies in the Kbuild structure, which people are welcome to play with. the first is called "find_badref_selects.sh", which specifically locates "select" directives in Kconfig files that are selecting non-existing Kbuild options, which makes them pointless. example (focusing attention on arch/arm directory): $ find_badref_selects.sh arch/arm > CPU_ARM926EJS1 arch/arm/mach-imx/mx2/Kconfig:20: select CPU_ARM926EJS1 > SPL_DISABLE_OF_CONTROL arch/arm/mach-exynos/Kconfig:119: select SPL_DISABLE_OF_CONTROL arch/arm/mach-exynos/Kconfig:153: select SPL_DISABLE_OF_CONTROL $ and a second script called "find_badref_make_configs.sh" specifically finds Kconfig references in Makefiles that point to non-existent Kconfig options. for example: $ find_badref_make_configs.sh drivers/gpio > ADI_GPIO2 ./drivers/gpio/Makefile:obj-$(CONFIG_ADI_GPIO2) += adi_gpio2.o > DB8500_GPIO ./drivers/gpio/Makefile:obj-$(CONFIG_DB8500_GPIO) += db8500_gpio.o > DM644X_GPIO ./drivers/gpio/Makefile:obj-$(CONFIG_DM644X_GPIO) += da8xx_gpio.o $ if anyone's interested, i can post those scripts on a couple more wiki pages this weekend, with an example or two. and on that note, i will shut up about this now. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 4/7] arm: mach-k3: Add secure device support
K3 devices have High Security (HS) variants along with the non-HS already
supported. Like the previous generation devices (OMAP/Keystone2) K3
supports boot chain-of-trust by authenticating and optionally decrypting
images as they are unpacked from FIT images. Add support for this here.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
Reviewed-by: Andreas Dannenberg
---
MAINTAINERS | 1 +
arch/arm/Kconfig| 2 +-
arch/arm/mach-k3/Makefile | 1 +
arch/arm/mach-k3/security.c | 63 +
4 files changed, 66 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-k3/security.c
diff --git a/MAINTAINERS b/MAINTAINERS
index f9ee4281d9..de1ea20930 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -721,6 +721,7 @@ S: Supported
F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
F: arch/arm/mach-omap2/sec-common.c
F: arch/arm/mach-omap2/config_secure.mk
+F: arch/arm/mach-k3/security.c
F: configs/am335x_hs_evm_defconfig
F: configs/am335x_hs_evm_uart_defconfig
F: configs/am43xx_hs_evm_defconfig
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 398dbef1cb..f89e590464 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1456,7 +1456,7 @@ endchoice
config TI_SECURE_DEVICE
bool "HS Device Type Support"
- depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS
+ depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
help
If a high secure (HS) device type is being used, this config
must be set. This option impacts various aspects of the
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index bd4ab361b2..0c3a4f7db1 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -6,4 +6,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-y += common.o
diff --git a/arch/arm/mach-k3/security.c b/arch/arm/mach-k3/security.c
new file mode 100644
index 00..52f49bf01f
--- /dev/null
+++ b/arch/arm/mach-k3/security.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * K3: Security functions
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+ struct udevice *dev;
+ struct ti_sci_handle *ti_sci;
+ struct ti_sci_proc_ops *proc_ops;
+ u64 image_addr;
+ u32 image_size;
+ int ret;
+
+ /* Get handle to Device Management and Security Controller (SYSFW) */
+ ret = uclass_get_device_by_name(UCLASS_FIRMWARE, "dmsc", &dev);
+ if (ret) {
+ printf("Failed to get handle to SYSFW (%d)\n", ret);
+ hang();
+ }
+ ti_sci = (struct ti_sci_handle *)(ti_sci_get_handle_from_sysfw(dev));
+ proc_ops = &ti_sci->ops.proc_ops;
+
+ image_addr = (uintptr_t)*p_image;
+
+ debug("Authenticating image at address 0x%016llx\n", image_addr);
+
+ /* Authenticate image */
+ ret = proc_ops->proc_auth_boot_image(ti_sci, &image_addr, &image_size);
+ if (ret) {
+ printf("Authentication failed!\n");
+ hang();
+ }
+
+ /*
+* The image_size returned may be 0 when the authentication process has
+* moved the image. When this happens no further processing on the
+* image is needed or often even possible as it may have also been
+* placed behind a firewall when moved.
+*/
+ *p_size = image_size;
+
+ /*
+* Output notification of successful authentication to re-assure the
+* user that the secure code is being processed as expected. However
+* suppress any such log output in case of building for SPL and booting
+* via YMODEM. This is done to avoid disturbing the YMODEM serial
+* protocol transactions.
+*/
+ if (!(IS_ENABLED(CONFIG_SPL_BUILD) &&
+ IS_ENABLED(CONFIG_SPL_YMODEM_SUPPORT) &&
+ spl_boot_device() == BOOT_DEVICE_UART))
+ printf("Authentication passed\n");
+}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 4/5] board: ti: am65x: Enable fixing up msmc sram node
On Fri, Mar 08, 2019 at 11:47:35AM +0530, Lokesh Vutla wrote: > Create a ft_board_setup() api that gets called as part of > DT fixup before jumping to kernel. In this ft_board_setup() > call fdt_fixup_msmc_ram that update msmc sram node. > > Signed-off-by: Lokesh Vutla 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
[U-Boot] [PATCH v3 5/7] arm: mach-k3: Add secure device build support
K3 HS devices require signed binaries for boot, use the SECDEV tools
to sign the boot artifacts during build.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
Reviewed-by: Andreas Dannenberg
---
MAINTAINERS | 1 +
arch/arm/mach-k3/config.mk| 25 ++
arch/arm/mach-k3/config_secure.mk | 44 +++
tools/k3_fit_atf.sh | 8 --
4 files changed, 76 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-k3/config_secure.mk
diff --git a/MAINTAINERS b/MAINTAINERS
index de1ea20930..69a6789c04 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -722,6 +722,7 @@ F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
F: arch/arm/mach-omap2/sec-common.c
F: arch/arm/mach-omap2/config_secure.mk
F: arch/arm/mach-k3/security.c
+F: arch/arm/mach-k3/config_secure.mk
F: configs/am335x_hs_evm_defconfig
F: configs/am335x_hs_evm_uart_defconfig
F: configs/am43xx_hs_evm_defconfig
diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
index be00d79fb0..2d8f61f9db 100644
--- a/arch/arm/mach-k3/config.mk
+++ b/arch/arm/mach-k3/config.mk
@@ -36,6 +36,14 @@ cmd_gencert = cat $(srctree)/tools/k3_x509template.txt | sed
$(SED_OPTS) > u-boo
# If external key is not provided, generate key using openssl.
ifeq ($(CONFIG_SYS_K3_KEY), "")
KEY=u-boot-spl-eckey.pem
+# On HS use real key or warn if not available
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/keys/custMpk.pem),)
+KEY=$(TI_SECURE_DEV_PKG)/keys/custMpk.pem
+else
+$(warning "WARNING: signing key not found. Random key will NOT work on HS
hardware!")
+endif
+endif
else
KEY=$(patsubst "%",$(srctree)/%,$(CONFIG_SYS_K3_KEY))
endif
@@ -65,6 +73,15 @@ ALL-y+= tiboot3.bin
endif
ifdef CONFIG_ARM64
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+SPL_ITS := u-boot-spl-k3_HS.its
+$(SPL_ITS): FORCE
+ IS_HS=1 \
+ $(srctree)/tools/k3_fit_atf.sh \
+ $(patsubst %,$(obj)/dts/%.dtb,$(subst ",,$(CONFIG_SPL_OF_LIST))) > $@
+
+ALL-y += tispl.bin_HS
+else
SPL_ITS := u-boot-spl-k3.its
$(SPL_ITS): FORCE
$(srctree)/tools/k3_fit_atf.sh \
@@ -72,7 +89,15 @@ $(SPL_ITS): FORCE
ALL-y += tispl.bin
endif
+endif
+
+else
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-y += u-boot.img_HS
else
ALL-y += u-boot.img
endif
+endif
+
+include $(srctree)/arch/arm/mach-k3/config_secure.mk
diff --git a/arch/arm/mach-k3/config_secure.mk
b/arch/arm/mach-k3/config_secure.mk
new file mode 100644
index 00..6d63c57665
--- /dev/null
+++ b/arch/arm/mach-k3/config_secure.mk
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (C) 2018 Texas Instruments, Incorporated - http://www.ti.com/
+# Andrew F. Davis
+
+quiet_cmd_k3secureimg = SECURE $@
+ifneq ($(TI_SECURE_DEV_PKG),)
+ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh),)
+cmd_k3secureimg = $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
+ $< $@ \
+ $(if $(KBUILD_VERBOSE:1=), >/dev/null)
+else
+cmd_k3secureimg = echo "WARNING:" \
+ "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \
+ "$@ was NOT secured!"; cp $< $@
+endif
+else
+cmd_k3secureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
+ "variable must be defined for TI secure devices." \
+ "$@ was NOT secured!"; cp $< $@
+endif
+
+%.dtb_HS: %.dtb FORCE
+ $(call if_changed,k3secureimg)
+
+$(obj)/u-boot-spl-nodtb.bin_HS: $(obj)/u-boot-spl-nodtb.bin FORCE
+ $(call if_changed,k3secureimg)
+
+tispl.bin_HS: $(obj)/u-boot-spl-nodtb.bin_HS $(patsubst
%,$(obj)/dts/%.dtb_HS,$(subst ",,$(CONFIG_SPL_OF_LIST))) $(SPL_ITS) FORCE
+ $(call if_changed,mkfitimage)
+
+MKIMAGEFLAGS_u-boot.img_HS = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
+ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
+ -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
+ $(patsubst %,-b arch/$(ARCH)/dts/%.dtb_HS,$(subst ",,$(CONFIG_OF_LIST)))
+
+OF_LIST_TARGETS = $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst
",,$(CONFIG_OF_LIST)))
+$(OF_LIST_TARGETS): dtbs
+
+u-boot-nodtb.bin_HS: u-boot-nodtb.bin FORCE
+ $(call if_changed,k3secureimg)
+
+u-boot.img_HS: u-boot-nodtb.bin_HS u-boot.img $(patsubst
%.dtb,%.dtb_HS,$(OF_LIST_TARGETS)) FORCE
+ $(call if_changed,mkimage)
diff --git a/tools/k3_fit_atf.sh b/tools/k3_fit_atf.sh
index 430b5ca616..4e9f69c087 100755
--- a/tools/k3_fit_atf.sh
+++ b/tools/k3_fit_atf.sh
@@ -21,6 +21,10 @@ if [ ! -f $TEE ]; then
TEE=/dev/null
fi
+if [ ! -z "$IS_HS" ]; then
+ HS_APPEND=_HS
+fi
+
cat << __HEADER_EOF
/dts-v1/;
@@ -51,7 +55,7 @@ cat << __HEADER_EOF
};
spl {
description = "SPL (64-bit)";
- data = /incbin/("spl/u-boot-spl-nodtb.bin");
+ data = /incbin/("spl/u-boot-spl-nodtb.bin$HS_APPEND");
type = "standalone";
[U-Boot] [PATCH v3 3/7] firmware: ti_sci: Modify auth_boot TI-SCI API to match new version
SYSFW version 2019.01 introduces a slightly modified version of this API,
add support for it here.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
Reviewed-by: Andreas Dannenberg
---
drivers/firmware/ti_sci.c | 25 -
drivers/firmware/ti_sci.h | 9 +++--
include/linux/soc/ti/ti_sci_protocol.h | 4 ++--
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 44bbeb66c2..1196ce0712 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1915,16 +1915,19 @@ static int ti_sci_cmd_set_proc_boot_ctrl(const struct
ti_sci_handle *handle,
* ti_sci_cmd_proc_auth_boot_image() - Command to authenticate and load the
* image and then set the processor configuration flags.
* @handle:Pointer to TI SCI handle
- * @proc_id: Processor ID this request is for
- * @cert_addr: Memory address at which payload image certificate is located.
+ * @image_addr:Memory address at which payload image and certificate is
+ * located in memory, this is updated if the image data is
+ * moved during authentication.
+ * @image_size: This is updated with the final size of the image after
+ * authentication.
*
* Return: 0 if all went well, else returns appropriate error value.
*/
static int ti_sci_cmd_proc_auth_boot_image(const struct ti_sci_handle *handle,
- u8 proc_id, u64 cert_addr)
+ u64 *image_addr, u32 *image_size)
{
struct ti_sci_msg_req_proc_auth_boot_image req;
- struct ti_sci_msg_hdr *resp;
+ struct ti_sci_msg_resp_proc_auth_boot_image *resp;
struct ti_sci_info *info;
struct ti_sci_xfer *xfer;
int ret = 0;
@@ -1944,9 +1947,8 @@ static int ti_sci_cmd_proc_auth_boot_image(const struct
ti_sci_handle *handle,
dev_err(info->dev, "Message alloc failed(%d)\n", ret);
return ret;
}
- req.processor_id = proc_id;
- req.cert_addr_low = cert_addr & TISCI_ADDR_LOW_MASK;
- req.cert_addr_high = (cert_addr & TISCI_ADDR_HIGH_MASK) >>
+ req.cert_addr_low = *image_addr & TISCI_ADDR_LOW_MASK;
+ req.cert_addr_high = (*image_addr & TISCI_ADDR_HIGH_MASK) >>
TISCI_ADDR_HIGH_SHIFT;
ret = ti_sci_do_xfer(info, xfer);
@@ -1955,10 +1957,15 @@ static int ti_sci_cmd_proc_auth_boot_image(const struct
ti_sci_handle *handle,
return ret;
}
- resp = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
+ resp = (struct ti_sci_msg_resp_proc_auth_boot_image
*)xfer->tx_message.buf;
if (!ti_sci_is_response_ack(resp))
- ret = -ENODEV;
+ return -ENODEV;
+
+ *image_addr = (resp->image_addr_low & TISCI_ADDR_LOW_MASK) |
+ (((u64)resp->image_addr_high <<
+ TISCI_ADDR_HIGH_SHIFT) & TISCI_ADDR_HIGH_MASK);
+ *image_size = resp->image_size;
return ret;
}
diff --git a/drivers/firmware/ti_sci.h b/drivers/firmware/ti_sci.h
index 1b601ff01b..a484b1fa40 100644
--- a/drivers/firmware/ti_sci.h
+++ b/drivers/firmware/ti_sci.h
@@ -708,7 +708,6 @@ struct ti_sci_msg_req_set_proc_boot_ctrl {
/**
* struct ti_sci_msg_req_proc_auth_start_image - Authenticate and start image
* @hdr: Generic Header
- * @processor_id: ID of processor
* @cert_addr_low: Lower 32bit (Little Endian) of certificate
* @cert_addr_high:Higher 32bit (Little Endian) of certificate
*
@@ -717,11 +716,17 @@ struct ti_sci_msg_req_set_proc_boot_ctrl {
*/
struct ti_sci_msg_req_proc_auth_boot_image {
struct ti_sci_msg_hdr hdr;
- u8 processor_id;
u32 cert_addr_low;
u32 cert_addr_high;
} __packed;
+struct ti_sci_msg_resp_proc_auth_boot_image {
+ struct ti_sci_msg_hdr hdr;
+ u32 image_addr_low;
+ u32 image_addr_high;
+ u32 image_size;
+} __packed;
+
/**
* struct ti_sci_msg_req_get_proc_boot_status - Get processor boot status
* @hdr: Generic Header
diff --git a/include/linux/soc/ti/ti_sci_protocol.h
b/include/linux/soc/ti/ti_sci_protocol.h
index 895cb1b911..c57802f293 100644
--- a/include/linux/soc/ti/ti_sci_protocol.h
+++ b/include/linux/soc/ti/ti_sci_protocol.h
@@ -279,8 +279,8 @@ struct ti_sci_proc_ops {
u64 bv, u32 cfg_set, u32 cfg_clr);
int (*set_proc_boot_ctrl)(const struct ti_sci_handle *handle, u8 pid,
u32 ctrl_set, u32 ctrl_clr);
- int (*proc_auth_boot_image)(const struct ti_sci_handle *handle, u8 pid,
- u64 caddr);
+ int (*proc_auth_boot_image)(const struct ti_sci_handle *handle,
+ u64 *image_addr, u32 *image_size);
int (*get_proc_boot_status)(const s
[U-Boot] [PATCH v3 1/7] arm: K3: Avoid use of MCU_PSRAM0 before SYSFW is loaded
On HS devices the 512b region of reset isolated memory called
MCU_PSRAM0 is firewalled by default. Until SYSFW is loaded we
cannot use this memory. It is only used to store a single value
left at the end of SRAM by ROM that will be needed later. Save
that value to a global variable stored in the .data section.
This section is used as .bss will be cleared between saving
this value and using it.
Signed-off-by: Andrew F. Davis
Reviewed-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
arch/arm/mach-k3/am6_init.c | 13 -
arch/arm/mach-k3/include/mach/am6_hardware.h | 3 ---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 77cd15f388..60a580305d 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -49,11 +49,16 @@ static void ctrl_mmr_unlock(void)
mmr_unlock(CTRL_MMR0_BASE, 7);
}
+/*
+ * This uninitialized global variable would normal end up in the .bss section,
+ * but the .bss is cleared between writing and reading this variable, so move
+ * it to the .data section.
+ */
+u32 bootindex __attribute__((section(".data")));
+
static void store_boot_index_from_rom(void)
{
- u32 *boot_index = (u32 *)K3_BOOT_PARAM_TABLE_INDEX_VAL;
-
- *boot_index = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
+ bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
}
void board_init_f(ulong dummy)
@@ -92,7 +97,6 @@ u32 spl_boot_mode(const u32 boot_device)
{
#if defined(CONFIG_SUPPORT_EMMC_BOOT)
u32 devstat = readl(CTRLMMR_MAIN_DEVSTAT);
- u32 bootindex = readl(K3_BOOT_PARAM_TABLE_INDEX_VAL);
u32 bootmode = (devstat & CTRLMMR_MAIN_DEVSTAT_BOOTMODE_MASK) >>
CTRLMMR_MAIN_DEVSTAT_BOOTMODE_SHIFT;
@@ -168,7 +172,6 @@ static u32 __get_primary_bootmedia(u32 devstat)
u32 spl_boot_device(void)
{
u32 devstat = readl(CTRLMMR_MAIN_DEVSTAT);
- u32 bootindex = readl(K3_BOOT_PARAM_TABLE_INDEX_VAL);
if (bootindex == K3_PRIMARY_BOOTMODE)
return __get_primary_bootmedia(devstat);
diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h
b/arch/arm/mach-k3/include/mach/am6_hardware.h
index b5244609af..3343233aa3 100644
--- a/arch/arm/mach-k3/include/mach/am6_hardware.h
+++ b/arch/arm/mach-k3/include/mach/am6_hardware.h
@@ -44,7 +44,4 @@
#define CTRLMMR_LOCK_KICK1 0x0100c
#define CTRLMMR_LOCK_KICK1_UNLOCK_VAL 0xd172bc5a
-/* MCU SCRATCHPAD usage */
-#define K3_BOOT_PARAM_TABLE_INDEX_VAL CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE
-
#endif /* __ASM_ARCH_AM6_HARDWARE_H */
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/7] firmware: ti_sci: Add support for firewall management
TI-SCI message protocol provides support for controlling the firewall
configurations available in SoC.
Introduce support for the set of TI-SCI message protocol APIs that
provide us with this capability of controlling firewalls.
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
Reviewed-by: Andreas Dannenberg
---
drivers/firmware/ti_sci.c | 177 +
drivers/firmware/ti_sci.h | 121 +
include/linux/soc/ti/ti_sci_protocol.h | 64 +
3 files changed, 362 insertions(+)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index d47d22fff3..44bbeb66c2 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -2428,6 +2428,178 @@ fail:
return ret;
}
+/**
+ * ti_sci_cmd_set_fwl_region() - Request for configuring a firewall region
+ * @handle:pointer to TI SCI handle
+ * @region:region configuration parameters
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_cmd_set_fwl_region(const struct ti_sci_handle *handle,
+const struct ti_sci_msg_fwl_region *region)
+{
+ struct ti_sci_msg_fwl_set_firewall_region_req req;
+ struct ti_sci_msg_hdr *resp;
+ struct ti_sci_info *info;
+ struct ti_sci_xfer *xfer;
+ int ret = 0;
+
+ if (IS_ERR(handle))
+ return PTR_ERR(handle);
+ if (!handle)
+ return -EINVAL;
+
+ info = handle_to_ti_sci_info(handle);
+
+ xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_FWL_SET,
+TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+(u32 *)&req, sizeof(req), sizeof(*resp));
+ if (IS_ERR(xfer)) {
+ ret = PTR_ERR(xfer);
+ dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+ return ret;
+ }
+
+ req.fwl_id = region->fwl_id;
+ req.region = region->region;
+ req.n_permission_regs = region->n_permission_regs;
+ req.control = region->control;
+ req.permissions[0] = region->permissions[0];
+ req.permissions[1] = region->permissions[1];
+ req.permissions[2] = region->permissions[2];
+ req.start_address = region->start_address;
+ req.end_address = region->end_address;
+
+ ret = ti_sci_do_xfer(info, xfer);
+ if (ret) {
+ dev_err(info->dev, "Mbox send fail %d\n", ret);
+ return ret;
+ }
+
+ resp = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
+
+ if (!ti_sci_is_response_ack(resp))
+ return -ENODEV;
+
+ return 0;
+}
+
+/**
+ * ti_sci_cmd_get_fwl_region() - Request for getting a firewall region
+ * @handle:pointer to TI SCI handle
+ * @region:region configuration parameters
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_cmd_get_fwl_region(const struct ti_sci_handle *handle,
+struct ti_sci_msg_fwl_region *region)
+{
+ struct ti_sci_msg_fwl_get_firewall_region_req req;
+ struct ti_sci_msg_fwl_get_firewall_region_resp *resp;
+ struct ti_sci_info *info;
+ struct ti_sci_xfer *xfer;
+ int ret = 0;
+
+ if (IS_ERR(handle))
+ return PTR_ERR(handle);
+ if (!handle)
+ return -EINVAL;
+
+ info = handle_to_ti_sci_info(handle);
+
+ xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_FWL_GET,
+TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+(u32 *)&req, sizeof(req), sizeof(*resp));
+ if (IS_ERR(xfer)) {
+ ret = PTR_ERR(xfer);
+ dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+ return ret;
+ }
+
+ req.fwl_id = region->fwl_id;
+ req.region = region->region;
+ req.n_permission_regs = region->n_permission_regs;
+
+ ret = ti_sci_do_xfer(info, xfer);
+ if (ret) {
+ dev_err(info->dev, "Mbox send fail %d\n", ret);
+ return ret;
+ }
+
+ resp = (struct ti_sci_msg_fwl_get_firewall_region_resp
*)xfer->tx_message.buf;
+
+ if (!ti_sci_is_response_ack(resp))
+ return -ENODEV;
+
+ region->fwl_id = resp->fwl_id;
+ region->region = resp->region;
+ region->n_permission_regs = resp->n_permission_regs;
+ region->control = resp->control;
+ region->permissions[0] = resp->permissions[0];
+ region->permissions[1] = resp->permissions[1];
+ region->permissions[2] = resp->permissions[2];
+ region->start_address = resp->start_address;
+ region->end_address = resp->end_address;
+
+ return 0;
+}
+
+/**
+ * ti_sci_cmd_change_fwl_owner() - Request for changing a firewall owner
+ * @handle:pointer to TI SCI handle
+ * @region:region configuration parameters
+ *
+ * Return: 0 if all went well, el
[U-Boot] [PATCH v3 0/7] AM65x HS device support
Hello all, This series brings up HS device support on the AM65x platform. Support for HS on K3 family devices is a bit different than previous devices but for the most part all that has been abstracted into the SECDEV package, allowing for a rather straight forward implementation here. Thanks, Andrew Changes from v2: - Rebased on latest master Changes from v1: - Commented on use of .data section - Use ti_sci_msg_hdr header directly when possible - Rebase and add Reviewed-bys - Will add makefile cleanup later as it also affects files unrelated to this series Andrew F. Davis (7): arm: K3: Avoid use of MCU_PSRAM0 before SYSFW is loaded firmware: ti_sci: Add support for firewall management firmware: ti_sci: Modify auth_boot TI-SCI API to match new version arm: mach-k3: Add secure device support arm: mach-k3: Add secure device build support configs: Add configs for AM65x High Security EVM doc: Update info on using K3 secure devices MAINTAINERS | 4 + arch/arm/Kconfig | 2 +- arch/arm/mach-k3/Makefile| 1 + arch/arm/mach-k3/am6_init.c | 13 +- arch/arm/mach-k3/config.mk | 25 +++ arch/arm/mach-k3/config_secure.mk| 44 arch/arm/mach-k3/include/mach/am6_hardware.h | 3 - arch/arm/mach-k3/security.c | 63 ++ configs/am65x_hs_evm_a53_defconfig | 77 +++ configs/am65x_hs_evm_r5_defconfig| 90 + doc/README.ti-secure | 20 +- drivers/firmware/ti_sci.c| 202 ++- drivers/firmware/ti_sci.h| 130 +++- include/linux/soc/ti/ti_sci_protocol.h | 68 ++- tools/k3_fit_atf.sh | 8 +- 15 files changed, 721 insertions(+), 29 deletions(-) create mode 100644 arch/arm/mach-k3/config_secure.mk create mode 100644 arch/arm/mach-k3/security.c create mode 100644 configs/am65x_hs_evm_a53_defconfig create mode 100644 configs/am65x_hs_evm_r5_defconfig -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 7/7] doc: Update info on using K3 secure devices
Signed-off-by: Andrew F. Davis Reviewed-by: Tom Rini Reviewed-by: Andreas Dannenberg --- doc/README.ti-secure | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/doc/README.ti-secure b/doc/README.ti-secure index 76950253ac..27c0eaa77f 100644 --- a/doc/README.ti-secure +++ b/doc/README.ti-secure @@ -138,7 +138,7 @@ Booting of U-Boot SPL Invoking the script for Keystone2 Secure Devices - = + create-boot-image.sh \ @@ -157,6 +157,18 @@ Booting of U-Boot SPL boot from all media. Secure boot from SPI NOR flash is not currently supported. + Invoking the script for K3 Secure Devices + = + + The signing steps required to produce a bootable SPL image on secure + K3 TI devices are the same as those performed on non-secure devices. + The only difference is the key is not checked on non-secure devices so + a dummy key is used when building U-Boot for those devices. For secure + K3 TI devices simply use the real hardware key for your device. This + real key can be set with the Kconfig option "K3_KEY". The environment + variable TI_SECURE_DEV_PKG is also searched for real keys when the + build targets secure devices. + Booting of Primary U-Boot (u-boot.img) == @@ -181,10 +193,8 @@ Booting of Primary U-Boot (u-boot.img) is enabled through the CONFIG_SPL_FIT_IMAGE_POST_PROCESS option which must be enabled for the secure boot scheme to work. In order to allow verifying proper operation of the secure boot chain in case of successful - authentication messages like "Authentication passed: CERT_U-BOOT-NOD" are - output by the SPL to the console for each blob that got extracted from the - FIT image. Note that the last part of this log message is the (truncated) - name of the signing certificate embedded into the blob that got processed. + authentication messages like "Authentication passed" are output by the + SPL to the console for each blob that got extracted from the FIT image. The exact details of the how the images are secured is handled by the SECDEV package. Within the SECDEV package exists a script to process -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 6/7] configs: Add configs for AM65x High Security EVM
Add new defconfig files for the AM65x High Security EVM.
This defconfigs are the same as for the non-secure part, except for:
CONFIG_TI_SECURE_DEVICE option set to 'y'
CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'
CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y'
Signed-off-by: Andrew F. Davis
Reviewed-by: Tom Rini
Reviewed-by: Andreas Dannenberg
---
MAINTAINERS| 2 +
configs/am65x_hs_evm_a53_defconfig | 77 +
configs/am65x_hs_evm_r5_defconfig | 90 ++
3 files changed, 169 insertions(+)
create mode 100644 configs/am65x_hs_evm_a53_defconfig
create mode 100644 configs/am65x_hs_evm_r5_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index 69a6789c04..aae2838f5c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -734,6 +734,8 @@ F: configs/k2hk_hs_evm_defconfig
F: configs/k2e_hs_evm_defconfig
F: configs/k2g_hs_evm_defconfig
F: configs/k2l_hs_evm_defconfig
+F: configs/am65x_hs_evm_r5_defconfig
+F: configs/am65x_hs_evm_a53_defconfig
TQ GROUP
#M:Martin Krause
diff --git a/configs/am65x_hs_evm_a53_defconfig
b/configs/am65x_hs_evm_a53_defconfig
new file mode 100644
index 00..dcafa458e0
--- /dev/null
+++ b/configs/am65x_hs_evm_a53_defconfig
@@ -0,0 +1,77 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SOC_K3_AM6=y
+CONFIG_TARGET_AM654_A53_EVM=y
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=2
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run run_kern"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_REMOTEPROC=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am654-base-board"
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_ENV_IS_IN_FAT=y
+CONFIG_ENV_FAT_INTERFACE="mmc"
+CONFIG_ENV_FAT_DEVICE_AND_PART="1:1"
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_TI_SCI=y
+CONFIG_DMA_CHANNELS=y
+CONFIG_TI_K3_NAVSS_UDMA=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_K3_ARASAN=y
+CONFIG_PINCTRL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_SPL_PINCTRL=y
+# CONFIG_SPL_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_K3=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SOC_TI=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_TI_SCI=y
diff --git a/configs/am65x_hs_evm_r5_defconfig
b/configs/am65x_hs_evm_r5_defconfig
new file mode 100644
index 00..1b9c138c03
--- /dev/null
+++ b/configs/am65x_hs_evm_r5_defconfig
@@ -0,0 +1,90 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SOC_K3_AM6=y
+CONFIG_TARGET_AM654_R5_EVM=y
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_USE_BOOTCOMMAND=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_SUPPORT=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_SPL_REMOTEPROC=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am654-r5-base-board"
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_ENV_IS_IN_FAT=y
+CONF
Re: [U-Boot] [U-Boot,v2,0/7] AM65x HS device support
On 4/12/19 12:27 PM, Tom Rini wrote: > On Thu, Feb 21, 2019 at 04:35:05PM -0600, Andrew F. Davis wrote: > >> Hello all, >> >> This series brings up HS device support on the AM65x platform. Support >> for HS on K3 family devices is a bit different than previous devices >> but for the most part all that has been abstracted into the SECDEV >> package, allowing for a rather straight forward implementation here. >> >> Thanks, >> Andrew >> >> Changes from v1: >> - Commented on use of .data section >> - Use ti_sci_msg_hdr header directly when possible >> - Rebase and add Reviewed-bys >> - Will add makefile cleanup later as it also affects >>files unrelated to this series >> >> Andrew F. Davis (7): >> arm: K3: Avoid use of MCU_PSRAM0 before SYSFW is loaded >> firmware: ti_sci: Add support for firewall management >> firmware: ti_sci: Modify auth_boot TI-SCI API to match new version >> arm: mach-k3: Add secure device support >> arm: mach-k3: Add secure device build support >> configs: Add a config for AM65x High Security EVM >> doc: Update info on using K3 secure devices > > Can you please rebase this on master and repost? Thanks! > Done and sent. Thanks, Andrew ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
On 4/11/19 10:50 PM, Ard Biesheuvel wrote: On Thu, 11 Apr 2019 at 12:59, Heinrich Schuchardt wrote: On 4/11/19 9:41 PM, Ilias Apalodimas wrote: Hi Heinrich, On 4/11/19 8:39 PM, Ilias Apalodimas wrote: Following Ard's suggestion: Runtime data sections are intended for data that is used by the runtime services implementations. Let's change they type to EFI_ACPI_RECLAIM_MEMORY Suggested-by: Ard Biesheuvel Signed-off-by: Ilias Apalodimas --- cmd/bootefi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 3619a20e6433..b54181909aff 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -111,13 +111,13 @@ static efi_status_t copy_fdt(void **fdtp) new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 + fdt_size, 0); ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, -EFI_RUNTIME_SERVICES_DATA, fdt_pages, +EFI_ACPI_RECLAIM_MEMORY, fdt_pages, GRUB uses EfiLoaderCode when installing its modified version of the FDT. The "Embedded Base Boot Requirements (EBBR) Specification, Release v1.0" does not require ACPI support. Can we expect EfiACPIReclaimMemory to be supported if we do not have any ACPI table? How about functions efi_smbios_register() and efi_acpi_register()? How about systab.tables assigned in efi_initialize_system_table()? Which of the addresses in systab.tables should be updated upon relocation. The EFI Spec is really hazy: "A pointer to the table associated with VendorGuid. Whether this pointer is a physical address or a virtual address during runtime is determined by the VendorGuid." The FDT_TABLE_GUID or DEVICE_TREE_GUID as Linux calls it is not defined in the UEFI spec. So we can marvel about expected behavior. Is there any other document specifying it? What about using EFI_BOOT_SERVICES_DATA instead of EFI_ACPI_RECLAIM_MEMORY? This still fixes the issue and doesn't cause any of the potential problems you mentioned Why services data and not loader data? Services data is used by the boot services and loader data by the loader. GRUB is a loader so it uses loader data, u-boot is both boot services and a loader so it could arguably use both, but boot services data is more idiomatic. From the pov of the OS, it makes no difference at all. As said above we should consider all three supported tables ACPI, SMBIOS, and FDT when thinking about a fix. The UEFI spec describes that the addresses inside ACPI and SMBIOS tables are not fixed up when entering runtime. This indicates that at least these tables have to be accessible at runtime. Accessible at runtime but *not* by the runtime services themselves. Why do you think that the FDT table should be treated> differently to the ACPI table? Same thing. Accessible at runtime but not by the firmware services themselves. Only data structures that the runtime services need to access in order to implement the functionality they expose to the OS should be in runtime services data memory. This applies to DT, ACPI and SMBIOS tables alike, but as I mentioned, for historical reasons, SMBIOS tables are usually exposed via runtime services data. Interestingly, the UEFI spec mentions that smbios tables should be located in runtime services data but no virtual mapping should be requested for them, and this is actually impossible in EDK2, so the current practice of using rtservicesdata for SMBIOS with the EFI_MEMORY_RUNTIME attribute set also violates the UEFI spec. Hello Ilias, hello Ard, please, have a look at this patch: efi_loader: update virtual address in efi_mem_carve_out https://lists.denx.de/pipermail/u-boot/2019-April/364937.html Possibly the bug reported here could have contributed the Linux crash you experienced. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
On Fri, 12 Apr 2019 at 10:16, Heinrich Schuchardt wrote: > > On 4/11/19 10:50 PM, Ard Biesheuvel wrote: > > On Thu, 11 Apr 2019 at 12:59, Heinrich Schuchardt > > wrote: > >> > >> On 4/11/19 9:41 PM, Ilias Apalodimas wrote: > >>> Hi Heinrich, > On 4/11/19 8:39 PM, Ilias Apalodimas wrote: > > Following Ard's suggestion: > > Runtime data sections are intended for data that is used by the runtime > > services implementations. > > Let's change they type to EFI_ACPI_RECLAIM_MEMORY > > > > Suggested-by: Ard Biesheuvel > > Signed-off-by: Ilias Apalodimas > > --- > >cmd/bootefi.c | 4 ++-- > >1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/cmd/bootefi.c b/cmd/bootefi.c > > index 3619a20e6433..b54181909aff 100644 > > --- a/cmd/bootefi.c > > +++ b/cmd/bootefi.c > > @@ -111,13 +111,13 @@ static efi_status_t copy_fdt(void **fdtp) > > new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 + > > fdt_size, 0); > > ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, > > -EFI_RUNTIME_SERVICES_DATA, fdt_pages, > > +EFI_ACPI_RECLAIM_MEMORY, fdt_pages, > > GRUB uses EfiLoaderCode when installing its modified version of the FDT. > > The "Embedded Base Boot Requirements (EBBR) Specification, Release v1.0" > does not require ACPI support. Can we expect EfiACPIReclaimMemory to be > supported if we do not have any ACPI table? > > How about functions efi_smbios_register() and efi_acpi_register()? > > How about systab.tables assigned in efi_initialize_system_table()? Which > of the addresses in systab.tables should be updated upon relocation. > > The EFI Spec is really hazy: "A pointer to the table associated with > VendorGuid. Whether this pointer is a physical address or a > virtual address during runtime is determined by the VendorGuid." > > The FDT_TABLE_GUID or DEVICE_TREE_GUID as Linux calls it is not defined > in the UEFI spec. So we can marvel about expected behavior. Is there any > other document specifying it? > >>> > >>> What about using EFI_BOOT_SERVICES_DATA instead of > >>> EFI_ACPI_RECLAIM_MEMORY? > >>> This still fixes the issue and doesn't cause any of the potential > >>> problems you > >>> mentioned > >> > >> Why services data and not loader data? > >> > > > > Services data is used by the boot services and loader data by the > > loader. GRUB is a loader so it uses loader data, u-boot is both boot > > services and a loader so it could arguably use both, but boot services > > data is more idiomatic. > > > >>From the pov of the OS, it makes no difference at all. > > > >> As said above we should consider all three supported tables ACPI, > >> SMBIOS, and FDT when thinking about a fix. The UEFI spec describes that > >> the addresses inside ACPI and SMBIOS tables are not fixed up when > >> entering runtime. > >> > >> This indicates that at least these tables have to be accessible at > >> runtime. > > > > Accessible at runtime but *not* by the runtime services themselves. > > > >> Why do you think that the FDT table should be treated> differently to the > >> ACPI table? > >> > > > > Same thing. Accessible at runtime but not by the firmware services > > themselves. > > > > Only data structures that the runtime services need to access in order > > to implement the functionality they expose to the OS should be in > > runtime services data memory. This applies to DT, ACPI and SMBIOS > > tables alike, but as I mentioned, for historical reasons, SMBIOS > > tables are usually exposed via runtime services data. Interestingly, > > the UEFI spec mentions that smbios tables should be located in runtime > > services data but no virtual mapping should be requested for them, and > > this is actually impossible in EDK2, so the current practice of using > > rtservicesdata for SMBIOS with the EFI_MEMORY_RUNTIME attribute set > > also violates the UEFI spec. > > > > Hello Ilias, hello Ard, > > please, have a look at this patch: > > efi_loader: update virtual address in efi_mem_carve_out > https://lists.denx.de/pipermail/u-boot/2019-April/364937.html > > Possibly the bug reported here could have contributed the Linux crash > you experienced. > Hello Heinrich, That patch looks completely unrelated, to be honest. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
On 4/12/19 7:24 PM, Ard Biesheuvel wrote: On Fri, 12 Apr 2019 at 10:16, Heinrich Schuchardt wrote: On 4/11/19 10:50 PM, Ard Biesheuvel wrote: On Thu, 11 Apr 2019 at 12:59, Heinrich Schuchardt wrote: On 4/11/19 9:41 PM, Ilias Apalodimas wrote: Hi Heinrich, On 4/11/19 8:39 PM, Ilias Apalodimas wrote: Following Ard's suggestion: Runtime data sections are intended for data that is used by the runtime services implementations. Let's change they type to EFI_ACPI_RECLAIM_MEMORY Suggested-by: Ard Biesheuvel Signed-off-by: Ilias Apalodimas --- cmd/bootefi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 3619a20e6433..b54181909aff 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -111,13 +111,13 @@ static efi_status_t copy_fdt(void **fdtp) new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 + fdt_size, 0); ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, -EFI_RUNTIME_SERVICES_DATA, fdt_pages, +EFI_ACPI_RECLAIM_MEMORY, fdt_pages, GRUB uses EfiLoaderCode when installing its modified version of the FDT. The "Embedded Base Boot Requirements (EBBR) Specification, Release v1.0" does not require ACPI support. Can we expect EfiACPIReclaimMemory to be supported if we do not have any ACPI table? How about functions efi_smbios_register() and efi_acpi_register()? How about systab.tables assigned in efi_initialize_system_table()? Which of the addresses in systab.tables should be updated upon relocation. The EFI Spec is really hazy: "A pointer to the table associated with VendorGuid. Whether this pointer is a physical address or a virtual address during runtime is determined by the VendorGuid." The FDT_TABLE_GUID or DEVICE_TREE_GUID as Linux calls it is not defined in the UEFI spec. So we can marvel about expected behavior. Is there any other document specifying it? What about using EFI_BOOT_SERVICES_DATA instead of EFI_ACPI_RECLAIM_MEMORY? This still fixes the issue and doesn't cause any of the potential problems you mentioned Why services data and not loader data? Services data is used by the boot services and loader data by the loader. GRUB is a loader so it uses loader data, u-boot is both boot services and a loader so it could arguably use both, but boot services data is more idiomatic. >From the pov of the OS, it makes no difference at all. As said above we should consider all three supported tables ACPI, SMBIOS, and FDT when thinking about a fix. The UEFI spec describes that the addresses inside ACPI and SMBIOS tables are not fixed up when entering runtime. This indicates that at least these tables have to be accessible at runtime. Accessible at runtime but *not* by the runtime services themselves. Why do you think that the FDT table should be treated> differently to the ACPI table? Same thing. Accessible at runtime but not by the firmware services themselves. Only data structures that the runtime services need to access in order to implement the functionality they expose to the OS should be in runtime services data memory. This applies to DT, ACPI and SMBIOS tables alike, but as I mentioned, for historical reasons, SMBIOS tables are usually exposed via runtime services data. Interestingly, the UEFI spec mentions that smbios tables should be located in runtime services data but no virtual mapping should be requested for them, and this is actually impossible in EDK2, so the current practice of using rtservicesdata for SMBIOS with the EFI_MEMORY_RUNTIME attribute set also violates the UEFI spec. Hello Ilias, hello Ard, please, have a look at this patch: efi_loader: update virtual address in efi_mem_carve_out https://lists.denx.de/pipermail/u-boot/2019-April/364937.html Possibly the bug reported here could have contributed the Linux crash you experienced. Hello Heinrich, That patch looks completely unrelated, to be honest. I wondered if virtual address != physical address could be the cause why the Linux memory management is incorrectly initialized. --- GRUB uses EfiLoaderCode when installing its modified version of the FDT. In EDK II EmbeddedPkg/Library/DxeDtPlatformDtbLoaderLibDefault/DxeDtPlatformDtbLoaderLibDefault.c function DtPlatformLoadDtb() calls function AllocateCopyPool(). In MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c function AllocateCopyPool() uses EfiBootServicesData for the device tree So I think using EfiBootServicesData in U-Boot should be safe. Please, update the patch accordingly. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
Hi Heinrich, > > Hello Ilias, hello Ard, > > please, have a look at this patch: > > efi_loader: update virtual address in efi_mem_carve_out > https://lists.denx.de/pipermail/u-boot/2019-April/364937.html > > Possibly the bug reported here could have contributed the Linux crash > you experienced. > Thanks for the heads up. Unfortunately i've already tried that. I was talking to Patrick before he posted the patch upstream. This seems unrelated anyway (all my tests were with the patch applied regardless) https://lore.kernel.org/linux-arm-kernel/20190411151320.GA23031@apalos/ This has an explanation on the problem. The tl;dr version (quoting Russell) "It is also designed to allow hardware-section sized mappings (making it possible to map sections on 1MB granularity) but as a single Linux page table always occupies 2MB, it is not permitted for the unused half of an aligned 2MB slot to be used for a page table mapping - hence this BUG_ON(). The ARM early mapping routines are intentionally designed such that areas of memory that they are asked to map are non-overlapping - it is the caller's responsibility to ensure this." In order to make sure this won't trigger we got to make sure that the fdt is placed on the first 1mb boundary of the memory (of any 2mb aligned area) thus forcing the kernel to init the pte's correctly, instead of trying to do section mappings for the memory in that area. The problem happens when you have a small no-map section within a 2MB region, and it does cross the even-odd 1MB boundary. So fdt at 0x7f0 (or any other are after that like 0xc7f01000) will crash the kernel with a BUG_ON(). Placing it in 0x7e01000-7eFF000 would be fine (on armv7's with LPAE off in the kernel) Thanks /Ilias ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
On Fri, 12 Apr 2019 at 10:44, Heinrich Schuchardt wrote: > > On 4/12/19 7:24 PM, Ard Biesheuvel wrote: > > On Fri, 12 Apr 2019 at 10:16, Heinrich Schuchardt > > wrote: > >> > >> On 4/11/19 10:50 PM, Ard Biesheuvel wrote: > >>> On Thu, 11 Apr 2019 at 12:59, Heinrich Schuchardt > >>> wrote: > > On 4/11/19 9:41 PM, Ilias Apalodimas wrote: > > Hi Heinrich, > >> On 4/11/19 8:39 PM, Ilias Apalodimas wrote: > >>> Following Ard's suggestion: > >>> Runtime data sections are intended for data that is used by the > >>> runtime > >>> services implementations. > >>> Let's change they type to EFI_ACPI_RECLAIM_MEMORY > >>> > >>> Suggested-by: Ard Biesheuvel > >>> Signed-off-by: Ilias Apalodimas > >>> --- > >>> cmd/bootefi.c | 4 ++-- > >>> 1 file changed, 2 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c > >>> index 3619a20e6433..b54181909aff 100644 > >>> --- a/cmd/bootefi.c > >>> +++ b/cmd/bootefi.c > >>> @@ -111,13 +111,13 @@ static efi_status_t copy_fdt(void **fdtp) > >>> new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 + > >>>fdt_size, 0); > >>> ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, > >>> -EFI_RUNTIME_SERVICES_DATA, fdt_pages, > >>> +EFI_ACPI_RECLAIM_MEMORY, fdt_pages, > >> > >> GRUB uses EfiLoaderCode when installing its modified version of the > >> FDT. > >> > >> The "Embedded Base Boot Requirements (EBBR) Specification, Release > >> v1.0" > >> does not require ACPI support. Can we expect EfiACPIReclaimMemory to be > >> supported if we do not have any ACPI table? > >> > >> How about functions efi_smbios_register() and efi_acpi_register()? > >> > >> How about systab.tables assigned in efi_initialize_system_table()? > >> Which > >> of the addresses in systab.tables should be updated upon relocation. > >> > >> The EFI Spec is really hazy: "A pointer to the table associated with > >> VendorGuid. Whether this pointer is a physical address or a > >> virtual address during runtime is determined by the VendorGuid." > >> > >> The FDT_TABLE_GUID or DEVICE_TREE_GUID as Linux calls it is not defined > >> in the UEFI spec. So we can marvel about expected behavior. Is there > >> any > >> other document specifying it? > > > > What about using EFI_BOOT_SERVICES_DATA instead of > > EFI_ACPI_RECLAIM_MEMORY? > > This still fixes the issue and doesn't cause any of the potential > > problems you > > mentioned > > Why services data and not loader data? > > >>> > >>> Services data is used by the boot services and loader data by the > >>> loader. GRUB is a loader so it uses loader data, u-boot is both boot > >>> services and a loader so it could arguably use both, but boot services > >>> data is more idiomatic. > >>> > >>> >From the pov of the OS, it makes no difference at all. > >>> > As said above we should consider all three supported tables ACPI, > SMBIOS, and FDT when thinking about a fix. The UEFI spec describes that > the addresses inside ACPI and SMBIOS tables are not fixed up when > entering runtime. > > This indicates that at least these tables have to be accessible at > runtime. > >>> > >>> Accessible at runtime but *not* by the runtime services themselves. > >>> > Why do you think that the FDT table should be treated> differently to > the ACPI table? > > >>> > >>> Same thing. Accessible at runtime but not by the firmware services > >>> themselves. > >>> > >>> Only data structures that the runtime services need to access in order > >>> to implement the functionality they expose to the OS should be in > >>> runtime services data memory. This applies to DT, ACPI and SMBIOS > >>> tables alike, but as I mentioned, for historical reasons, SMBIOS > >>> tables are usually exposed via runtime services data. Interestingly, > >>> the UEFI spec mentions that smbios tables should be located in runtime > >>> services data but no virtual mapping should be requested for them, and > >>> this is actually impossible in EDK2, so the current practice of using > >>> rtservicesdata for SMBIOS with the EFI_MEMORY_RUNTIME attribute set > >>> also violates the UEFI spec. > >>> > >> > >> Hello Ilias, hello Ard, > >> > >> please, have a look at this patch: > >> > >> efi_loader: update virtual address in efi_mem_carve_out > >> https://lists.denx.de/pipermail/u-boot/2019-April/364937.html > >> > >> Possibly the bug reported here could have contributed the Linux crash > >> you experienced. > >> > > > > Hello Heinrich, > > > > That patch looks completely unrelated, to be honest. > > > > I wondered if virtual address != physical address could be the cause why > the Linux memory mana
Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
On 4/12/19 7:36 PM, Ilias Apalodimas wrote: Hi Heinrich, Hello Ilias, hello Ard, please, have a look at this patch: efi_loader: update virtual address in efi_mem_carve_out https://lists.denx.de/pipermail/u-boot/2019-April/364937.html Possibly the bug reported here could have contributed the Linux crash you experienced. Thanks for the heads up. Unfortunately i've already tried that. I was talking to Patrick before he posted the patch upstream. This seems unrelated anyway (all my tests were with the patch applied regardless) https://lore.kernel.org/linux-arm-kernel/20190411151320.GA23031@apalos/ This has an explanation on the problem. The tl;dr version (quoting Russell) "It is also designed to allow hardware-section sized mappings (making it possible to map sections on 1MB granularity) but as a single Linux page table always occupies 2MB, it is not permitted for the unused half of an aligned 2MB slot to be used for a page table mapping - hence this BUG_ON(). The ARM early mapping routines are intentionally designed such that areas of memory that they are asked to map are non-overlapping - it is the caller's responsibility to ensure this." In order to make sure this won't trigger we got to make sure that the fdt is placed on the first 1mb boundary of the memory (of any 2mb aligned area) thus forcing the kernel to init the pte's correctly, instead of trying to do section mappings for the memory in that area. The problem happens when you have a small no-map section within a 2MB region, and it does cross the even-odd 1MB boundary. So fdt at 0x7f0 (or any other are after that like 0xc7f01000) will crash the kernel with a BUG_ON(). Placing it in 0x7e01000-7eFF000 would be fine (on armv7's with LPAE off in the kernel) I think Linux cannot make any assumptions about UEFI memory layout if it is not explicitly specified in the UEFI spec. Everything is simply a Linux bug. Concerning FDT I suggest to stick to what EDK II does: use EfiBootServicesData. Best regards Heinrich Thanks /Ilias ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] [U-boot]: Change FDT memory type from runtime data to boot services data
Following Ard's suggestion:
Runtime data sections are intended for data that is used by the runtime
services implementation.
Let's change the type to EFI_BOOT_SERVICES_DATA
This also fixes booting of armv7 using efi and fdtcontroladdr
Suggested-by: Ard Biesheuvel
Signed-off-by: Ilias Apalodimas
Acked-by: Ard Biesheuvel
---
cmd/bootefi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3619a20e6433..15ee4af45667 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -111,13 +111,13 @@ static efi_status_t copy_fdt(void **fdtp)
new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 +
fdt_size, 0);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_RUNTIME_SERVICES_DATA, fdt_pages,
+EFI_BOOT_SERVICES_DATA, fdt_pages,
&new_fdt_addr);
if (ret != EFI_SUCCESS) {
/* If we can't put it there, put it somewhere */
new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_RUNTIME_SERVICES_DATA, fdt_pages,
+EFI_BOOT_SERVICES_DATA, fdt_pages,
&new_fdt_addr);
if (ret != EFI_SUCCESS) {
printf("ERROR: Failed to reserve space for FDT\n");
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM tools-only CROSS_COMPILE issues within Cygwin
Just posting an update on the current Cygwin issues with U-Boot and the Android NDK. I do have NDK cross-compiles of tools-only working well from a Linux environment now but on Cygwin there continues to be some major compatibility issue with U-Boot's KBuild system and the Android NDK. Using the same command-line as my Linux NDK cross-compile on Cygwin results in the following odd build error: HOSTCC scripts/basic/fixdep CHK include/config/uboot.release CHK include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h HOSTCC tools/gen_eth_addr : No such file or directoryg file: make[1]: *** [scripts/Makefile.host:97: tools/gen_eth_addr] Error 2 make[1]: *** Deleting file 'tools/gen_eth_addr' make: *** [Makefile:1722: tools-only] Error 2 Then seeing if adding --sysroot helps gives the following also-bizarre error: HOSTCC scripts/basic/fixdep CHK include/config/uboot.release CHK include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h HOSTCC tools/gen_eth_addr In file included from ././include/compiler.h:19:0, from :0: g:\cygwin\home\chris\x-tools\arm-linux-androideabi-r15c-api21-unified\lib\gcc\arm-linux-androideabi\4.9.x\include\stdint.h:9:26: fatal error: stdint.h: No such file or directory # include_next ^ compilation terminated. make[1]: *** [scripts/Makefile.host:97: tools/gen_eth_addr] Error 1 make: *** [Makefile:1722: tools-only] Error 2 I'll be uploading a patch to fix issues with tools-only native Cygwin compiles and Android NDK cross-compiles on Linux shortly, but Android NDK cross-compiles on Cygwin could definitely still use some attention beyond my ability. Thanks for you for your time! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] include: compiler: fix tools-only compiles on Cygwin and with the Android NDK on Linux
Hi again, I am submitting this patch with some easy fixes for the ongoing broken compiling U-Boot tools-only on Cygwin and cross-compiling with the Android NDK on Linux. The added __kernel_* definitions in posix_types.h come from mainline so should be safe for inclusion: https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/posix_types.h I also feel it worth mentioning that my previous bug report for dumpimage failing on untrimmed dumps has not received any response yet, so I'll link it again for your attention as the issue remains in 2019.04: https://lists.denx.de/pipermail/u-boot/2019-January/355670.html Errors on Cygwin resolved by this patch: HOSTCC tools/aisimage.o In file included from tools/aisimage.c:9:0: include/image.h:321:2: error: unknown type name ‘__be32’ __be32 ih_magic; /* Image Header Magic Number */ ^~ (and 6 similar __be32 errors) make[1]: *** [scripts/Makefile.host:114: tools/aisimage.o] Error 1 make: *** [Makefile:1722: tools-only] Error 2 HOSTCC tools/imx8image.o In file included from include/linux/kernel.h:5:0, from include/imx8image.h:14, from tools/imx8image.c:8: include/linux/types.h:155:2: error: unknown type name ‘__kernel_daddr_t’ __kernel_daddr_t f_tfree; ^~~~ include/linux/types.h:156:2: error: unknown type name ‘__kernel_ino_t’ __kernel_ino_t f_tinode; ^~ make[1]: *** [scripts/Makefile.host:114: tools/imx8image.o] Error 1 make: *** [Makefile:1722: tools-only] Error 2 HOSTCC tools/mtk_image.o In file included from tools/mtk_image.c:12:0: tools/mtk_image.h:18:3: error: unknown type name ‘__le32’ __le32 version; ^~ (and 30 similar __le32 errors) tools/mtk_image.h:35:3: error: unknown type name ‘__le16’ __le16 ioif; ^~ (and 10 similar __le16 errors) make[1]: *** [scripts/Makefile.host:114: tools/mtk_image.o] Error 1 make: *** [Makefile:1722: tools-only] Error 2 HOSTCC tools/zynqmpbif.o tools/zynqmpbif.c: In function ‘bif_add_bit’: tools/zynqmpbif.c:520:15: warning: implicit declaration of function ‘__swab32’; did you mean ‘__bswap32’? [-Wimplicit-function-declaration] *bitbin32 = __swab32(*bitbin32); ^~~~ __bswap32 tools/zynqmpbif.o:zynqmpbif.c:(.text+0xdb7): undefined reference to `__swab32' collect2: error: ld returned 1 exit status make[1]: *** [scripts/Makefile.host:106: tools/dumpimage] Error 1 make: *** [Makefile:1722: tools-only] Error 2 Errors with the Android NDK on Linux resolved by this patch: HOSTCC tools/aisimage.o In file included from tools/aisimage.c:7:0: tools/imagetool.h:215:2: error: unknown type name 'ulong' ulong file_data, ^ In file included from tools/aisimage.c:9:0: include/image.h:335:2: error: unknown type name 'ulong' ulong start, end; /* start/end of blob */ ^ (and 42 similar ulong errors) make[1]: *** [tools/aisimage.o] Error 1 make: *** [tools-only] Error 2 HOSTCC tools/zynqmpbif.o tools/zynqmpbif.c: In function 'bif_add_bit': tools/zynqmpbif.c:520:3: warning: implicit declaration of function '__fswab32' [-Wimplicit-function-declaration] *bitbin32 = __swab32(*bitbin32); ^ tools/zynqmpbif.o:zynqmpbif.c:function bif_add_bit: error: undefined reference to '__fswab32' collect2: error: ld returned 1 exit status make[1]: *** [tools/mkimage] Error 1 make: *** [tools-only] Error 2 Thanks for your time and consideration! Chris 0001-include-compiler-fix-tools-only-compiles-on-Cygwin-a.patch Description: 0001-include-compiler-fix-tools-only-compiles-on-Cygwin-a.patch ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] i2c: mxc: Hide kconfig based control in DM_I2C mode
These options only apply when not using DM_I2C. When using device trees, the dt will enable and control the speeds of the I2C controller(s) and these configuration options have no effect. So disable them in DM_I2C mode. Otherwise they show up as decoys, and make it look like one is enabling I2C controllers and setting the speed when really it's doing nothing. Cc: Sriram Dash Cc: Priyanka Jain Cc: Heiko Schocher Signed-off-by: Trent Piepho --- drivers/i2c/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 1ef22e6bcd..df7fc7db0a 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -161,7 +161,7 @@ config SYS_I2C_MXC channels and operating on standard mode upto 100 kbits/s and fast mode upto 400 kbits/s. -if SYS_I2C_MXC +if SYS_I2C_MXC && !DM_I2C config SYS_I2C_MXC_I2C1 bool "NXP MXC I2C1" help -- 2.14.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
