[U-Boot] [PATCH v3 0/3] Most rockchip platform based boards use a key to instruct
the board enter download firmware mode, some boards use a adc to detect the key status, and some use a gpio. This series try to implement all the download mode related functions on the base of Dr. Philipp's patch[0]. [0]https://lists.denx.de/pipermail/u-boot/2017-October/309060.html Changes in v3: - add support for rk3188 - rebase on Dr. Philipp's series Changes in v2: - correct the rk322x boot mode register address - make the help text more clear - implement the back to bootrom download mode check in c, thanks for Dr. Philipp Tomsich's suggestion. - more document - move adc key detect as the default Andy Yan (3): rockchip: make boot_mode related codes reused across all platforms rockchip: add support for enter to bootrom download mode rockchip: check download key before bootup arch/arm/include/asm/arch-rockchip/boot_mode.h | 6 ++ arch/arm/mach-rockchip/Kconfig | 16 ++ arch/arm/mach-rockchip/Makefile| 6 ++ arch/arm/mach-rockchip/boot_mode.c | 76 ++ arch/arm/mach-rockchip/bootrom.c | 47 +++- arch/arm/mach-rockchip/rk3036-board.c | 24 arch/arm/mach-rockchip/rk3188-board.c | 1 + arch/arm/mach-rockchip/rk322x-board.c | 24 arch/arm/mach-rockchip/rk3288-board.c | 25 - arch/arm/mach-rockchip/rk3399-board.c | 14 + 10 files changed, 164 insertions(+), 75 deletions(-) create mode 100644 arch/arm/mach-rockchip/boot_mode.c create mode 100644 arch/arm/mach-rockchip/rk3399-board.c -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] rockchip: make boot_mode related codes reused across all platforms
setup_boot_mode function use the same logic but different
mode register address across all the rockchip platforms,
so it's better to make this function reused across all the
platforms, and let the mode register address setting from
the config file.
Signed-off-by: Andy Yan
Reviewed-by: Simon Glass
---
Changes in v3:
- add support for rk3188
Changes in v2:
- correct the rk322x boot mode register address
- make the help text more clear
arch/arm/include/asm/arch-rockchip/boot_mode.h | 2 ++
arch/arm/mach-rockchip/Kconfig | 15
arch/arm/mach-rockchip/Makefile| 6 +
arch/arm/mach-rockchip/boot_mode.c | 33 ++
arch/arm/mach-rockchip/rk3036-board.c | 24 ---
arch/arm/mach-rockchip/rk3188-board.c | 1 +
arch/arm/mach-rockchip/rk322x-board.c | 24 ---
arch/arm/mach-rockchip/rk3288-board.c | 25 ---
arch/arm/mach-rockchip/rk3399-board.c | 14 +++
9 files changed, 71 insertions(+), 73 deletions(-)
create mode 100644 arch/arm/mach-rockchip/boot_mode.c
create mode 100644 arch/arm/mach-rockchip/rk3399-board.c
diff --git a/arch/arm/include/asm/arch-rockchip/boot_mode.h
b/arch/arm/include/asm/arch-rockchip/boot_mode.h
index bd65f60..163b2e7 100644
--- a/arch/arm/include/asm/arch-rockchip/boot_mode.h
+++ b/arch/arm/include/asm/arch-rockchip/boot_mode.h
@@ -16,4 +16,6 @@
/* enter usb mass storage mode */
#define BOOT_UMS (REBOOT_FLAG + 12)
+int setup_boot_mode(void);
+
#endif
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 36df484..6144057 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -117,6 +117,7 @@ config ROCKCHIP_RK3399
select SPL_SERIAL_SUPPORT
select SPL_DRIVERS_MISC_SUPPORT
select DEBUG_UART_BOARD_INIT
+ select BOARD_LATE_INIT
help
The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72
and quad-core Cortex-A53.
@@ -152,6 +153,20 @@ config TPL_ROCKCHIP_BACK_TO_BROM
SPL will return to the boot rom, which will then load the U-Boot
binary to keep going on.
+config ROCKCHIP_BOOT_MODE_REG
+ hex "Rockchip boot mode flag register address"
+ default 0x200081c8 if ROCKCHIP_RK3036
+ default 0x20004040 if ROCKCHIP_RK3188
+ default 0x110005c8 if ROCKCHIP_RK322X
+ default 0xff730094 if ROCKCHIP_RK3288
+ default 0xff738200 if ROCKCHIP_RK3368
+ default 0xff320300 if ROCKCHIP_RK3399
+ default 0x10300580 if ROCKCHIP_RV1108
+ default 0
+ help
+ The Soc will enter to different boot mode(defined in
asm/arch/boot_mode.h)
+ according to the value from this register.
+
config ROCKCHIP_SPL_RESERVE_IRAM
hex "Size of IRAM reserved in SPL"
default 0x4000
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index c15e9bf..2127f2b 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -22,10 +22,16 @@ obj-spl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-spl.o
spl-boot-order.o
obj-spl-$(CONFIG_ROCKCHIP_RK3399) += rk3399-board-spl.o spl-boot-order.o
ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
+
+ifneq ($(CONFIG_ROCKCHIP_BOOT_MODE_REG),0)
+obj-y += boot_mode.o
+endif
+
obj-$(CONFIG_ROCKCHIP_RK3188) += rk3188-board.o
obj-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board.o
obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board.o
obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board.o
+obj-$(CONFIG_ROCKCHIP_RK3399) += rk3399-board.o
endif
obj-$(CONFIG_$(SPL_TPL_)RAM) += sdram_common.o
diff --git a/arch/arm/mach-rockchip/boot_mode.c
b/arch/arm/mach-rockchip/boot_mode.c
new file mode 100644
index 000..4652490
--- /dev/null
+++ b/arch/arm/mach-rockchip/boot_mode.c
@@ -0,0 +1,33 @@
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include
+#include
+#include
+
+int setup_boot_mode(void)
+{
+ void *reg = (void *)CONFIG_ROCKCHIP_BOOT_MODE_REG;
+ int boot_mode = readl(reg);
+
+ debug("boot mode %x.\n", boot_mode);
+
+ /* Clear boot mode */
+ writel(BOOT_NORMAL, reg);
+
+ switch (boot_mode) {
+ case BOOT_FASTBOOT:
+ printf("enter fastboot!\n");
+ env_set("preboot", "setenv preboot; fastboot usb0");
+ break;
+ case BOOT_UMS:
+ printf("enter UMS!\n");
+ env_set("preboot", "setenv preboot; ums mmc 0");
+ break;
+ }
+
+ return 0;
+}
diff --git a/arch/arm/mach-rockchip/rk3036-board.c
b/arch/arm/mach-rockchip/rk3036-board.c
index a3457f3..a5d2571 100644
--- a/arch/arm/mach-rockchip/rk3036-board.c
+++ b/arch/arm/mach-rockchip/rk3036-board.c
@@ -19,30 +19,6 @@
DECLARE_GLOBAL_DATA_PTR;
-#define GRF_BASE 0x20008000
-
-static void set
[U-Boot] [PATCH v3 2/3] rockchip: add support for enter to bootrom download mode
Rockchip bootrom will enter download mode if it returns from
spl/tpl with a non-zero value and couldn't find a valid image
in the backup partition.
This patch provide a method to instruct the system to back to
bootrom download mode by checking the BROM_DOWNLOAD_FLAG register.
As the bootrom download function relys on some modules such as
interrupts, so we need to back to bootrom as early as possbile
before the tpl/spl code override the interrupt configurations.
Signed-off-by: Andy Yan
Reviewed-by: Kever Yang
---
Changes in v3:
- rebase on Dr. Philipp's series
Changes in v2:
- implement the back to bootrom download mode check in c,
thanks for Dr. Philipp Tomsich's suggestion.
arch/arm/include/asm/arch-rockchip/boot_mode.h | 4 +++
arch/arm/mach-rockchip/Kconfig | 1 +
arch/arm/mach-rockchip/bootrom.c | 47 --
3 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-rockchip/boot_mode.h
b/arch/arm/include/asm/arch-rockchip/boot_mode.h
index 163b2e7..6b2a610 100644
--- a/arch/arm/include/asm/arch-rockchip/boot_mode.h
+++ b/arch/arm/include/asm/arch-rockchip/boot_mode.h
@@ -15,7 +15,11 @@
#define BOOT_CHARGING (REBOOT_FLAG + 11)
/* enter usb mass storage mode */
#define BOOT_UMS (REBOOT_FLAG + 12)
+/* enter bootrom download mode */
+#define BOOT_BROM_DOWNLOAD 0xEF08A53C
+#ifndef __ASSEMBLY__
int setup_boot_mode(void);
+#endif
#endif
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 6144057..a26736a 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -118,6 +118,7 @@ config ROCKCHIP_RK3399
select SPL_DRIVERS_MISC_SUPPORT
select DEBUG_UART_BOARD_INIT
select BOARD_LATE_INIT
+ select ROCKCHIP_BROM_HELPER
help
The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72
and quad-core Cortex-A53.
diff --git a/arch/arm/mach-rockchip/bootrom.c b/arch/arm/mach-rockchip/bootrom.c
index e369fdc..bef2a90 100644
--- a/arch/arm/mach-rockchip/bootrom.c
+++ b/arch/arm/mach-rockchip/bootrom.c
@@ -6,6 +6,8 @@
#include
#include
+#include
+#include
#include
#include
@@ -15,12 +17,45 @@
*/
static jmp_buf brom_ctx __section(".data");
+static void _back_to_bootrom(enum rockchip_bootrom_cmd brom_cmd)
+{
+ longjmp(brom_ctx, brom_cmd);
+}
+
void back_to_bootrom(enum rockchip_bootrom_cmd brom_cmd)
{
#if CONFIG_IS_ENABLED(LIBCOMMON_SUPPORT)
puts("Returning to boot ROM...\n");
#endif
- longjmp(brom_ctx, brom_cmd);
+ _back_to_bootrom(brom_cmd);
+}
+
+/*
+ * we back to bootrom download mode if get a
+ * BOOT_BROM_DOWNLOAD flag in boot mode register
+ *
+ * note: the boot mode register is configured by
+ * application(next stage bootloader, kernel, etc),
+ * and the bootrom never check this register, so we need
+ * to check it and back to bootrom at very early bootstage(before
+ * some basic configurations(such as interrupts) been
+ * changed by TPL/SPL, as the bootrom download operation
+ * relys on many default settings(such as interrupts) by
+ * it's self.
+ */
+static bool check_back_to_brom_dnl_flag(void)
+{
+ u32 boot_mode;
+
+ if (CONFIG_ROCKCHIP_BOOT_MODE_REG) {
+ boot_mode = readl(CONFIG_ROCKCHIP_BOOT_MODE_REG);
+ if (boot_mode == BOOT_BROM_DOWNLOAD) {
+ writel(0, CONFIG_ROCKCHIP_BOOT_MODE_REG);
+ return true;
+ }
+ }
+
+ return false;
}
/*
@@ -34,6 +69,8 @@ int save_boot_params(void)
switch (ret) {
case 0:
+ if (check_back_to_brom_dnl_flag())
+ _back_to_bootrom(BROM_BOOT_ENTER_DNL);
/*
* This is the initial pass through this function
* (i.e. saving the context), setjmp just setup up the
@@ -54,7 +91,13 @@ int save_boot_params(void)
*/
ret = 0;
break;
-
+ case BROM_BOOT_ENTER_DNL:
+ /*
+* A non-zero return value will instruct the BROM enter
+* download mode.
+*/
+ ret = 1;
+ break;
default:
#if CONFIG_IS_ENABLED(LIBCOMMON_SUPPORT)
puts("FATAL: unexpected command to back_to_bootrom()\n");
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] rockchip: check download key before bootup
Enter download mode if the download key pressed.
Signed-off-by: Andy Yan
---
Changes in v3: None
Changes in v2:
- more document
- move adc key detect as the default
arch/arm/mach-rockchip/boot_mode.c | 43 ++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/mach-rockchip/boot_mode.c
b/arch/arm/mach-rockchip/boot_mode.c
index 4652490..bf0a410 100644
--- a/arch/arm/mach-rockchip/boot_mode.c
+++ b/arch/arm/mach-rockchip/boot_mode.c
@@ -5,14 +5,57 @@
*/
#include
+#include
#include
#include
+void set_back_to_bootrom_dnl_flag(void)
+{
+ writel(BOOT_BROM_DOWNLOAD, CONFIG_ROCKCHIP_BOOT_MODE_REG);
+}
+
+/*
+ * detect download key status by adc, most rockchip
+ * based boards use adc sample the download key status,
+ * but there are also some use gpio. So it's better to
+ * make this a weak function that can be override by
+ * some special boards.
+ */
+#define KEY_DOWN_MIN_VAL 0
+#define KEY_DOWN_MAX_VAL 30
+
+__weak int rockchip_dnl_key_pressed(void)
+{
+ unsigned int val;
+
+ if (adc_channel_single_shot("saradc", 1, &val)) {
+ printf("%s adc_channel_single_shot fail!\n", __func__);
+ return false;
+ }
+
+ if ((val >= KEY_DOWN_MIN_VAL) && (val <= KEY_DOWN_MAX_VAL))
+ return true;
+ else
+ return false;
+}
+
+void rockchip_dnl_mode_check(void)
+{
+ if (rockchip_dnl_key_pressed()) {
+ printf("download key pressed, entering download mode...");
+ set_back_to_bootrom_dnl_flag();
+ do_reset(NULL, 0, 0, NULL);
+ }
+}
+
int setup_boot_mode(void)
{
void *reg = (void *)CONFIG_ROCKCHIP_BOOT_MODE_REG;
int boot_mode = readl(reg);
+ rockchip_dnl_mode_check();
+
+ boot_mode = readl(reg);
debug("boot mode %x.\n", boot_mode);
/* Clear boot mode */
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/11] efi_loader: exclude openrd devices
(Adding Albert as maintainer again) On 11.10.2017 00:50, Rob Clark wrote: On Tue, Oct 10, 2017 at 6:28 PM, Heinrich Schuchardt wrote: On 10/10/2017 02:23 PM, Rob Clark wrote: These devices have small image size limits, so exclude EFI_LOADER to help avoid exceeding limits. Signed-off-by: Rob Clark --- lib/efi_loader/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index d2b6327119..6e22940da5 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,6 @@ config EFI_LOADER bool "Support running EFI Applications in U-Boot" - depends on (ARM || X86) && OF_LIBFDT + depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD default y help Select this option if you want to run EFI applications (like grub2) I understand that with the progress we make on EFI implementation and other parts of U-Boot the U-Boot image size is growing too big for direct loading by the primary boot loader. The OPENRD boards have abundant memory, e.g. openrd_ultimate_defconfig refers to a board with 512 MB RAM. So I think completely disabling EFI is not the solution. Instead building an SPL should be enabled for this architecture when the image is becoming too big for direct load. I am copying in the KIRKWOOD maintainers go get their view. I'm defn open to alternatives.. I don't know too much about what the limit was on these boards, other than we were close to it before, and the additional uefi proto's add <4k to the image size, which was enough to push it over the limit. Since this was effecting only a few boards, I went with this.. if it is only a temporary fix that can be removed soon, or if someone can do something better with a separate SPL build in the near term, that would be great. I personally have not used any Kirkwood based platforms in the last few years (and don't have access to one). And I don't see activities here from mother developers either. As adding SPL support is not trivial, frankly I don't see that this will be done anytime soon if at all. Perhaps the image size can be reduced by removing other features or interfaces from the OPENRD platform instead (CMD_MII, JFFS2, ...)? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/11] efi_loader: exclude openrd devices
On 11.10.17 09:07, Stefan Roese wrote: > (Adding Albert as maintainer again) > > On 11.10.2017 00:50, Rob Clark wrote: >> On Tue, Oct 10, 2017 at 6:28 PM, Heinrich Schuchardt >> wrote: >>> On 10/10/2017 02:23 PM, Rob Clark wrote: These devices have small image size limits, so exclude EFI_LOADER to help avoid exceeding limits. Signed-off-by: Rob Clark --- lib/efi_loader/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index d2b6327119..6e22940da5 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,6 @@ config EFI_LOADER bool "Support running EFI Applications in U-Boot" - depends on (ARM || X86) && OF_LIBFDT + depends on (ARM || X86) && OF_LIBFDT && !TARGET_OPENRD default y help Select this option if you want to run EFI applications (like grub2) >>> >>> I understand that with the progress we make on EFI implementation and >>> other >>> parts of U-Boot the U-Boot image size is growing too big for direct >>> loading >>> by the primary boot loader. >>> >>> The OPENRD boards have abundant memory, e.g. openrd_ultimate_defconfig >>> refers to a board with 512 MB RAM. >>> >>> So I think completely disabling EFI is not the solution. >>> Instead building an SPL should be enabled for this architecture when the >>> image is becoming too big for direct load. >>> >>> I am copying in the KIRKWOOD maintainers go get their view. >>> >> >> I'm defn open to alternatives.. I don't know too much about what the >> limit was on these boards, other than we were close to it before, and >> the additional uefi proto's add <4k to the image size, which was >> enough to push it over the limit. Since this was effecting only a few >> boards, I went with this.. if it is only a temporary fix that can be >> removed soon, or if someone can do something better with a separate >> SPL build in the near term, that would be great. > > I personally have not used any Kirkwood based platforms in the last few > years (and don't have access to one). And I don't see activities here > from mother developers either. As adding SPL support is not trivial, > frankly I don't see that this will be done anytime soon if at all. > > Perhaps the image size can be reduced by removing other features or > interfaces from the OPENRD platform instead (CMD_MII, JFFS2, ...)? If it's too much work to make EFI_LOADER work on these platforms, I guess it's ok to disable it just for them. Given how dated they are, chances are pretty slim that enabling EFI_LOADER by default will give us a U-Boot copy on the device that supports it straight from the factory ;). However, I would ideally prefer to see that happen in the respective defconfigs, not in Kconfig. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: pci: imx: fix imx_pcie_remove function
Hi Fabio Fabio Estevam wrote: > From: Sven-Ola Tuecke > > However, at least on some i.MX6 custom boards, when calling By "some", I assume that not all i.MX6 systems are showing this behaviour. Does anyone have an idea which systems are affected and which are not? > assert_core_reset() as part of the first-time PCIe init, read access > to PCIE_PL_PFLR simply hangs. Surround this readl() with > imx_pcie_fix_dabt_handler() does not help. For this reason, the forced > LTSSM detection is only used on the second assert_core_reset() that is > called shorly before starting the Linux kernel. > > Signed-off-by: Sven-Ola Tuecke > Signed-off-by: Fabio Estevam Seems to work on our board therefore Tested-by: David Müller ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dwc: ep0: Allocate and flush dwc->ep0_trb in a cache aligned manner
Hi, On Tuesday 10 October 2017 07:19 PM, Marek Vasut wrote: > On 10/10/2017 12:45 PM, Faiz Abbas wrote: >> Hi Marek, >> >> On Tuesday 10 October 2017 01:30 PM, Marek Vasut wrote: >>> On 10/10/2017 07:48 AM, Kishon Vijay Abraham I wrote: Hi, >>> >>> Hi, >>> >>> [...] >>> >> -dwc3_flush_cache((uintptr_t)trb, sizeof(*trb)); >> +dwc3_flush_cache((uintptr_t)dwc->ep0_trb_addr, >> sizeof(*trb) * 2); > > Why *2 ? Because its allocated as sizeof(*dwc->ep0_trb) * 2 below. This is not strictly required as dwc3_flush_cache() rounds up the size to CACHELINE_SIZE but from a caller POV, flush everything we allocated. >>> >>> Can the other TRB be in use ? Maybe aligning the TRBs to cacheline >>> size >>> would be better ? >>> >> A single trb is 16 bytes in size and two of them are allocated >> contiguously. > > Why are two allocated continuously ? (I am not dwc3 expert) The TRB's should be allocated contiguously for dwc3 and only the base of the entire TRB table is programmed in the HW. <-- TRB table base address | TRB0 | || | TRB1 | || | TRB2 | || | TRBn | || Neither am I. I did try to pad to the dwc_trb structure such that each trb is 64 bytes in size but this leads to failures when testing. I didn't get a chance to debug this though. I suspect its because the code expects the trbs to be contiguous and/or 16 bytes in size. It's not the code but it's the HW. >>> >>> That'd imply we need either some sort of flushing scheme or non-cachable >>> memory allocation. What does Linux do ? >>> The dma_alloc_coherent in linux kernel allocates non-cachable memory. >> >> Currently, the code is using local variable trb to flush the cache. When >> the first trb is used, dwc3_flush_cache flushes the complete >> CACHELINE_SIZE (including the 2nd trb). >> When the 2nd trb is used to flush cache, since it is an unaligned flush, >> it will issue a warning and will align it to the lower cache line >> boundary (flushing the 1st trb in the process). >> >> So with or without this patch, both trbs are getting flushed with every >> call. With the patch, we can just avoid misaligned messages by always >> flushing using an aligned address. > > What worries me is that you can flush something into the memory while > the controller is writing into it as well. Is that possible ? > No, control to the hardware is only given after all the trbs have been configured and flushed to memory. This is done by using the chain variable in the code. dwc3_flush_cache((uintptr_t)buf_dma, len); dwc3_flush_cache((uintptr_t)dwc->ep0_trb_addr, sizeof(*trb) * 2); if (chain) return 0; memset(¶ms, 0, sizeof(params)); params.param0 = upper_32_bits(dwc->ep0_trb_addr); params.param1 = lower_32_bits(dwc->ep0_trb_addr); ret = dwc3_send_gadget_ep_cmd(dwc, dep->number, DWC3_DEPCMD_STARTTRANSFER, ¶ms); Thanks, Faiz ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dwc: ep0: Allocate and flush dwc->ep0_trb in a cache aligned manner
Hi, On Wednesday 11 October 2017 01:53 PM, Faiz Abbas wrote: > Hi, > > On Tuesday 10 October 2017 07:19 PM, Marek Vasut wrote: >> On 10/10/2017 12:45 PM, Faiz Abbas wrote: >>> Hi Marek, >>> >>> On Tuesday 10 October 2017 01:30 PM, Marek Vasut wrote: On 10/10/2017 07:48 AM, Kishon Vijay Abraham I wrote: > Hi, Hi, [...] >>> - dwc3_flush_cache((uintptr_t)trb, sizeof(*trb)); >>> + dwc3_flush_cache((uintptr_t)dwc->ep0_trb_addr, >>> sizeof(*trb) * 2); >> >> Why *2 ? > > Because its allocated as sizeof(*dwc->ep0_trb) * 2 below. This is > not > strictly required as dwc3_flush_cache() rounds up the size to > CACHELINE_SIZE but from a caller POV, flush everything we > allocated. Can the other TRB be in use ? Maybe aligning the TRBs to cacheline size would be better ? >>> A single trb is 16 bytes in size and two of them are allocated >>> contiguously. >> >> Why are two allocated continuously ? (I am not dwc3 expert) > > The TRB's should be allocated contiguously for dwc3 and only the base of > the > entire TRB table is programmed in the HW. > <-- TRB table base address > | TRB0 | > || > | TRB1 | > || > | TRB2 | > || > | TRBn | > || > > > > Neither am I. I did try to pad to the dwc_trb structure such that each > trb is 64 bytes in size but this leads to failures when testing. I > didn't get a chance to debug this though. I suspect its because the > code > expects the trbs to be contiguous and/or 16 bytes in size. > > It's not the code but it's the HW. That'd imply we need either some sort of flushing scheme or non-cachable memory allocation. What does Linux do ? The dma_alloc_coherent in linux kernel allocates non-cachable memory. >>> >>> Currently, the code is using local variable trb to flush the cache. When >>> the first trb is used, dwc3_flush_cache flushes the complete >>> CACHELINE_SIZE (including the 2nd trb). >>> When the 2nd trb is used to flush cache, since it is an unaligned flush, >>> it will issue a warning and will align it to the lower cache line >>> boundary (flushing the 1st trb in the process). >>> >>> So with or without this patch, both trbs are getting flushed with every >>> call. With the patch, we can just avoid misaligned messages by always >>> flushing using an aligned address. >> >> What worries me is that you can flush something into the memory while >> the controller is writing into it as well. Is that possible ? >> > No, control to the hardware is only given after all the trbs have been > configured and flushed to memory. This is done by using the chain > variable in the code. > > dwc3_flush_cache((uintptr_t)buf_dma, len); > dwc3_flush_cache((uintptr_t)dwc->ep0_trb_addr, sizeof(*trb) * 2); this flush_cache can be moved after the chain so that flush is only invoked after all the TRB's has been configured. Thanks Kishon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull from u-boot-i2c
Hello Tom, please pull from u-boot-i2c master The following changes since commit 45c9d96ae40b0c4292eb67d687f0bf698a0ce72b: configs: Re-sync CONFIG_CMD_IMLS with moveconfig (2017-10-10 17:52:07 -0400) are available in the git repository at: git://git.denx.de/u-boot-i2c.git master for you to fetch changes up to 5bc90a8953a902152bd640322ffc8111dccbe3ab: i2c: muxes: pca954x: look up width from chip_desc (2017-10-11 06:17:22 +0200) Chris Packham (1): i2c: muxes: pca954x: look up width from chip_desc drivers/i2c/muxes/pca954x.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) travis test passes: https://travis-ci.org/hsdenx/u-boot-i2c/builds/286348223 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
Re: [U-Boot] [PATCH v2 09/14] arm: socfpga: Restructure the SPL file
On 10/05/2017 08:07 AM, chin.liang@intel.com wrote:
> From: Chin Liang See
>
> Restructure the SPL so each devices such as CV, A10 and S10
> will have their own dedicated SPL file. SPL file determine
> the HW initialization flow which is device specific
>
> Signed-off-by: Chin Liang See
> ---
> arch/arm/mach-socfpga/Makefile | 5 +-
> arch/arm/mach-socfpga/spl_a10.c | 105
>
> arch/arm/mach-socfpga/{spl.c => spl_gen5.c} | 46
> 3 files changed, 109 insertions(+), 47 deletions(-)
> create mode 100644 arch/arm/mach-socfpga/spl_a10.c
> rename arch/arm/mach-socfpga/{spl.c => spl_gen5.c} (83%)
>
Reviewed-by: Dinh Nguyen
Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/14] arm: socfpga: stratix10: Add SPL driver for Stratix10 SoC
On 10/05/2017 08:07 AM, chin.liang@intel.com wrote:
> From: Chin Liang See
>
> Add SPL driver support for Stratix SoC
>
> Signed-off-by: Chin Liang See
> ---
> arch/arm/mach-socfpga/Makefile| 4 +
> arch/arm/mach-socfpga/include/mach/firewall_s10.h | 84 +
> arch/arm/mach-socfpga/spl_s10.c | 138
> ++
> 3 files changed, 226 insertions(+)
> create mode 100644 arch/arm/mach-socfpga/include/mach/firewall_s10.h
> create mode 100644 arch/arm/mach-socfpga/spl_s10.c
>
> diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
> index b669d43..35b124a 100644
> --- a/arch/arm/mach-socfpga/Makefile
> +++ b/arch/arm/mach-socfpga/Makefile
> @@ -40,6 +40,7 @@ obj-y += system_manager_s10.o
> obj-y+= wrap_pinmux_config_s10.o
> obj-y+= wrap_pll_config_s10.o
> endif
> +
> ifdef CONFIG_SPL_BUILD
> ifdef CONFIG_TARGET_SOCFPGA_GEN5
> obj-y+= spl_gen5.o
> @@ -51,6 +52,9 @@ endif
> ifdef CONFIG_TARGET_SOCFPGA_ARRIA10
> obj-y+= spl_a10.o
> endif
> +ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
> +obj-y+= spl_s10.o
> +endif
> endif
>
> ifdef CONFIG_TARGET_SOCFPGA_GEN5
> diff --git a/arch/arm/mach-socfpga/include/mach/firewall_s10.h
> b/arch/arm/mach-socfpga/include/mach/firewall_s10.h
> new file mode 100644
> index 000..6894bb9
> --- /dev/null
> +++ b/arch/arm/mach-socfpga/include/mach/firewall_s10.h
> @@ -0,0 +1,84 @@
> +/*
> + * Copyright (C) 2017 Intel Corporation
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
> +#ifndef _FIREWALL_S10_
> +#define _FIREWALL_S10_
> +
> +struct socfpga_firwall_l4_per {
> + u32 nand; /* 0x00 */
> + u32 nand_data;
> + u32 _pad_0x8;
> + u32 usb0;
> + u32 usb1; /* 0x10 */
> + u32 _pad_0x14;
> + u32 _pad_0x18;
> + u32 spim0;
> + u32 spim1; /* 0x20 */
> + u32 spis0;
> + u32 spis1;
> + u32 emac0;
> + u32 emac1; /* 0x30 */
> + u32 emac2;
> + u32 _pad_0x38;
> + u32 _pad_0x3c;
> + u32 sdmmc; /* 0x40 */
> + u32 gpio0;
> + u32 gpio1;
> + u32 _pad_0x4c;
> + u32 i2c0; /* 0x50 */
> + u32 i2c1;
> + u32 i2c2;
> + u32 i2c3;
> + u32 i2c4; /* 0x60 */
> + u32 timer0;
> + u32 timer1;
> + u32 uart0;
> + u32 uart1; /* 0x70 */
> +};
> +
> +struct socfpga_firwall_l4_sys {
> + u32 _pad_0x00; /* 0x00 */
> + u32 _pad_0x04;
> + u32 dma_ecc;
> + u32 emac0rx_ecc;
> + u32 emac0tx_ecc;/* 0x10 */
> + u32 emac1rx_ecc;
> + u32 emac1tx_ecc;
> + u32 emac2rx_ecc;
> + u32 emac2tx_ecc;/* 0x20 */
> + u32 _pad_0x24;
> + u32 _pad_0x28;
> + u32 nand_ecc;
> + u32 nand_read_ecc; /* 0x30 */
> + u32 nand_write_ecc;
> + u32 ocram_ecc;
> + u32 _pad_0x3c;
> + u32 sdmmc_ecc; /* 0x40 */
> + u32 usb0_ecc;
> + u32 usb1_ecc;
> + u32 clock_manager;
> + u32 _pad_0x50; /* 0x50 */
> + u32 io_manager;
> + u32 reset_manager;
> + u32 system_manager;
> + u32 osc0_timer; /* 0x60 */
> + u32 osc1_timer;
> + u32 watchdog0;
> + u32 watchdog1;
> + u32 watchdog2; /* 0x70 */
> + u32 watchdog3;
> +};
> +
> +#define FIREWALL_L4_DISABLE_ALL (BIT(0) | BIT(24) | BIT(16))
> +#define FIREWALL_BRIDGE_DISABLE_ALL (~0)
> +
> +#define CCU_CPU0_MPRT_ADMASK_MEM_RAM0_ADDR 0xf7004688
> +#define CCU_IOM_MPRT_ADMASK_MEM_RAM0_ADDR0xf7018628
> +
> +#define CCU_ADMASK_P_MASK(BIT(0))
> +#define CCU_ADMASK_NS_MASK (BIT(1))
> +
> +#endif /* _FIREWALL_S10_ */
> diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-socfpga/spl_s10.c
> new file mode 100644
> index 000..12cafe6
> --- /dev/null
> +++ b/arch/arm/mach-socfpga/spl_s10.c
> @@ -0,0 +1,138 @@
> +/*
> + * Copyright (C) 2016-2017 Intel Corporation
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static const struct socfpga_firwall_l4_per *firwall_l4_per_base =
> + (struct socfpga_firwall_l4_per *)SOCFPGA_FIREWALL_L4_PER;
> +static const struct socfpga_firwall_l4_sys *firwall_l4_sys_base =
> + (struct socfpga_firwall_l4_sys *)SOCFPGA_FIREWALL_L4_SYS;
> +
> +u32 spl_boot_device(void)
> +{
> + /* TODO: Get from SDM or handoff */
> +/* #ifdef CONFIG_CADENCE_QSPI*/
> +#if 0
Remove the '#if 0'.
> + return BOOT_DEVICE_SPI;
> +#else
> + retu
Re: [U-Boot] [PATCH v2 11/14] arm: socfpga: stratix10: Add timer support for Stratix10 SoC
On 10/05/2017 08:07 AM, chin.liang@intel.com wrote: > From: Chin Liang See > > Add timer support for Stratix SoC > > Signed-off-by: Chin Liang See > --- > arch/arm/mach-socfpga/timer.c | 17 - > 1 file changed, 16 insertions(+), 1 deletion(-) > Reviewed-by: Dinh Nguyen Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/14] arm: socfpga: stratix10: Add mailbox support for Stratix10 SoC
On 10/05/2017 08:07 AM, chin.liang@intel.com wrote:
> From: Chin Liang See
>
> Add mailbox support for Stratix SoC
>
> Signed-off-by: Ley Foon Tan
> Signed-off-by: Chin Liang See
> ---
> arch/arm/mach-socfpga/Makefile | 1 +
> arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 108 ++
> arch/arm/mach-socfpga/mailbox_s10.c | 238
> +++
> 3 files changed, 347 insertions(+)
> create mode 100644 arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> create mode 100644 arch/arm/mach-socfpga/mailbox_s10.c
>
> diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
> index b253914..43e18d2 100644
> --- a/arch/arm/mach-socfpga/Makefile
> +++ b/arch/arm/mach-socfpga/Makefile
> @@ -32,6 +32,7 @@ endif
>
> ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
> obj-y+= clock_manager_s10.o
> +obj-y+= mailbox_s10.o
> obj-y+= misc_s10.o
> obj-y+= reset_manager_s10.o
> obj-y+= system_manager_s10.o
> diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> new file mode 100644
> index 000..b9bddf6
> --- /dev/null
> +++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> @@ -0,0 +1,108 @@
> +/*
> + * Copyright (C) 2017 Intel Corporation
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +#ifndef _MAILBOX_S10_H_
> +#define _MAILBOX_S10_H_
> +
> +/* user define Uboot ID */
> +#define MBOX_CLIENT_ID_UBOOT 0xB
> +#define MBOX_ID_UBOOT0x1
> +
> +#define MBOX_MAX_CMD_INDEX 2047
> +#define MBOX_CMD_BUFFER_SIZE 32
> +#define MBOX_RESP_BUFFER_SIZE16
> +
> +#define MBOX_HDR_CMD_LSB 0
> +#define MBOX_HDR_CMD_MSK (BIT(11) - 1)
> +#define MBOX_HDR_I_LSB 11
> +#define MBOX_HDR_I_MSK BIT(11)
> +#define MBOX_HDR_LEN_LSB 12
> +#define MBOX_HDR_LEN_MSK 0x007FF000
> +#define MBOX_HDR_ID_LSB 24
> +#define MBOX_HDR_ID_MSK 0x0F00
> +#define MBOX_HDR_CLIENT_LSB 28
> +#define MBOX_HDR_CLIENT_MSK 0xF000
> +
> +/* Interrupt flags */
> +#define MBOX_FLAGS_INT_COE BIT(0) /* COUT update interrupt enable */
> +#define MBOX_FLAGS_INT_RIE BIT(1) /* RIN update interrupt enable */
> +#define MBOX_FLAGS_INT_UAE BIT(8) /* Urgent ACK interrupt enable */
> +#define MBOX_ALL_INTRS (MBOX_FLAGS_INT_COE | \
> + MBOX_FLAGS_INT_RIE | \
> + MBOX_FLAGS_INT_UAE)
> +
> +/* Status */
> +#define MBOX_STATUS_UA_MSK BIT(8)
> +
> +#define MBOX_CMD_HEADER(client, id, len, cmd) \
> + (((cmd) << MBOX_HDR_CMD_LSB) & MBOX_HDR_CMD_MSK) | \
> + (((len) << MBOX_HDR_LEN_LSB) & MBOX_HDR_LEN_MSK) | \
> + (((id) << MBOX_HDR_ID_LSB) & MBOX_HDR_ID_MSK)| \
> + (((client) << MBOX_HDR_CLIENT_LSB) & MBOX_HDR_CLIENT_MSK)
> +
> +#define MBOX_RESP_ERR_GET(resp) \
> + (((resp) & MBOX_HDR_CMD_MSK) >> MBOX_HDR_CMD_LSB)
> +#define MBOX_RESP_LEN_GET(resp) \
> + (((resp) & MBOX_HDR_LEN_MSK) >> MBOX_HDR_LEN_LSB)
> +#define MBOX_RESP_ID_GET(resp) \
> + (((resp) & MBOX_HDR_ID_MSK) >> MBOX_HDR_ID_LSB)
> +#define MBOX_RESP_CLIENT_GET(resp) \
> + (((resp) & MBOX_HDR_CLIENT_MSK) >> MBOX_HDR_CLIENT_LSB)
> +
> +/* Response error list */
> +typedef enum {
> + /* CMD completed succesfully, but check resp ARGS for any errors */
> + MBOX_RESP_STATOK = 0,
> + /* CMD is incorrectly formatted in some way */
> + MBOX_RESP_INVALID_COMMAND = 1,
> + /* BootROM Command code not undesrtood */
> + MBOX_RESP_UNKNOWN_BR = 2,
> + /* CMD code not recognized by firmware */
> + MBOX_RESP_UNKNOWN = 3,
> + /* Indicates that the device is not configured */
> + MBOX_RESP_NOT_CONFIGURED = 256,
> + /* Indicates that the device is busy */
> + MBOX_RESP_DEVICE_BUSY = 0x1FF,
> + /* Indicates that there is no valid response available */
> + MBOX_RESP_NO_VALID_RESP_AVAILABLE = 0x2FF,
> + /* General Error */
> + MBOX_RESP_ERROR = 0x3FF,
> +} ALT_SDM_MBOX_RESP_CODE;
> +
> +/* Mailbox command list */
> +#define MBOX_RESTART 2
> +#define MBOX_QSPI_OPEN 50
> +#define MBOX_QSPI_CLOSE 51
> +#define MBOX_QSPI_DIRECT 59
> +
> +struct socfpga_mailbox {
> + u32 cin;/* command valid offset */
> + u32 rout; /* response output offset */
> + u32 urg;/* urgent command */
> + u32 flags; /* interrupt enables */
> + u32 pad_0x10_0x1f[4]; /* 0x10 - 0x1F reserved */
> + u32 cout; /* command free offset */
> + u32 rin;/* respond valid offset */
> + u32 pad_0x28; /* 0x28 reserved */
> + u32 status; /* mailbox status */
> + u32 pad_0x30_0x3f[4]; /* 0x30 - 0x3F reserved */
> + u32
Re: [U-Boot] [PATCH 2/4] spi: Drop CONFIG_ATMEL_DATAFLASH_SPI
Hi Tuomas,
On 2017/10/11 2:59, Tuomas Tynkkynen wrote:
Last user of this option went away in commit:
fdc7718999 ("board: usb_a9263: Update to support DT and DM")
It is okay for me.
Acked-by: Wenyou Yang
Signed-off-by: Tuomas Tynkkynen
---
drivers/spi/Makefile | 1 -
drivers/spi/atmel_dataflash_spi.c | 184 --
2 files changed, 185 deletions(-)
delete mode 100644 drivers/spi/atmel_dataflash_spi.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index cd7c7556a7..ad56203cd6 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -17,7 +17,6 @@ endif
obj-$(CONFIG_ALTERA_SPI) += altera_spi.o
obj-$(CONFIG_ATH79_SPI) += ath79_spi.o
-obj-$(CONFIG_ATMEL_DATAFLASH_SPI) += atmel_dataflash_spi.o
obj-$(CONFIG_ATMEL_SPI) += atmel_spi.o
obj-$(CONFIG_CADENCE_QSPI) += cadence_qspi.o cadence_qspi_apb.o
obj-$(CONFIG_CF_SPI) += cf_spi.o
diff --git a/drivers/spi/atmel_dataflash_spi.c
b/drivers/spi/atmel_dataflash_spi.c
deleted file mode 100644
index a2e9c00ea6..00
--- a/drivers/spi/atmel_dataflash_spi.c
+++ /dev/null
@@ -1,184 +0,0 @@
-/*
- * Driver for ATMEL DataFlash support
- * Author : Hamid Ikdoumi (Atmel)
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-/*
- * This driver desperately needs rework:
- *
- * - use structure SoC access
- * - get rid of including asm/arch/at91_spi.h
- * - remove asm/arch/at91_spi.h
- * - get rid of all CONFIG_ATMEL_LEGACY defines and uses
- *
- * 02-Aug-2010 Reinhard Meyer
- */
-
-#include
-#ifndef CONFIG_ATMEL_LEGACY
-# define CONFIG_ATMEL_LEGACY
-#endif
-#include
-#include
-
-#include
-
-#include
-#include
-
-#include "atmel_spi.h"
-
-#include
-#include
-#include
-
-#include
-
-#define AT91_SPI_PCS0_DATAFLASH_CARD 0xE /* Chip Select 0: NPCS0%1110 */
-#define AT91_SPI_PCS1_DATAFLASH_CARD 0xD /* Chip Select 1: NPCS1%1101 */
-#define AT91_SPI_PCS2_DATAFLASH_CARD 0xB /* Chip Select 2: NPCS2%1011 */
-#define AT91_SPI_PCS3_DATAFLASH_CARD 0x7 /* Chip Select 3: NPCS3%0111 */
-
-void AT91F_SpiInit(void)
-{
- /* Reset the SPI */
- writel(AT91_SPI_SWRST, ATMEL_BASE_SPI0 + AT91_SPI_CR);
-
- /* Configure SPI in Master Mode with No CS selected !!! */
- writel(AT91_SPI_MSTR | AT91_SPI_MODFDIS | AT91_SPI_PCS,
- ATMEL_BASE_SPI0 + AT91_SPI_MR);
-
- /* Configure CS0 */
- writel(AT91_SPI_NCPHA |
- (AT91_SPI_DLYBS & DATAFLASH_TCSS) |
- (AT91_SPI_DLYBCT & DATAFLASH_TCHS) |
- ((get_mck_clk_rate() / AT91_SPI_CLK) << 8),
- ATMEL_BASE_SPI0 + AT91_SPI_CSR(0));
-
-#ifdef CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS1
- /* Configure CS1 */
- writel(AT91_SPI_NCPHA |
- (AT91_SPI_DLYBS & DATAFLASH_TCSS) |
- (AT91_SPI_DLYBCT & DATAFLASH_TCHS) |
- ((get_mck_clk_rate() / AT91_SPI_CLK) << 8),
- ATMEL_BASE_SPI0 + AT91_SPI_CSR(1));
-#endif
-#ifdef CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS2
- /* Configure CS2 */
- writel(AT91_SPI_NCPHA |
- (AT91_SPI_DLYBS & DATAFLASH_TCSS) |
- (AT91_SPI_DLYBCT & DATAFLASH_TCHS) |
- ((get_mck_clk_rate() / AT91_SPI_CLK) << 8),
- ATMEL_BASE_SPI0 + AT91_SPI_CSR(2));
-#endif
-#ifdef CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS3
- /* Configure CS3 */
- writel(AT91_SPI_NCPHA |
- (AT91_SPI_DLYBS & DATAFLASH_TCSS) |
- (AT91_SPI_DLYBCT & DATAFLASH_TCHS) |
- ((get_mck_clk_rate() / AT91_SPI_CLK) << 8),
- ATMEL_BASE_SPI0 + AT91_SPI_CSR(3));
-#endif
-
- /* SPI_Enable */
- writel(AT91_SPI_SPIEN, ATMEL_BASE_SPI0 + AT91_SPI_CR);
-
- while (!(readl(ATMEL_BASE_SPI0 + AT91_SPI_SR) & AT91_SPI_SPIENS))
- ;
-
- /*
-* Add tempo to get SPI in a safe state.
-* Should not be needed for new silicon (Rev B)
-*/
- udelay(50);
- readl(ATMEL_BASE_SPI0 + AT91_SPI_SR);
- readl(ATMEL_BASE_SPI0 + AT91_SPI_RDR);
-
-}
-
-void AT91F_SpiEnable(int cs)
-{
- unsigned long mode;
-
- mode = readl(ATMEL_BASE_SPI0 + AT91_SPI_MR);
- mode &= ~AT91_SPI_PCS;
-
- switch (cs) {
- case 0:
- mode |= AT91_SPI_PCS0_DATAFLASH_CARD << 16;
- break;
- case 1:
- mode |= AT91_SPI_PCS1_DATAFLASH_CARD << 16;
- break;
- case 2:
- mode |= AT91_SPI_PCS2_DATAFLASH_CARD << 16;
- break;
- case 3:
- mode |= AT91_SPI_PCS3_DATAFLASH_CARD << 16;
- break;
- }
-
- writel(mode, ATMEL_BASE_SPI0 + AT91_SPI_MR);
-
- /* SPI_Enable */
- writel(AT91_SPI_SPIEN, ATMEL_BASE_SPI0 + AT91_SPI_CR);
-}
-
-unsigned int AT91F_SpiWrite1(AT91PS_DataflashDesc pDesc);
-
-unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc pDesc)
-{
- unsigned int timeout;
- unsigned int timebase;
-
- pDesc->state = BUSY;
-
-
Re: [U-Boot] fsl_esdhc driver is broken with DM
On Tue, Oct 10, 2017 at 5:18 PM, Fabio Estevam wrote: > Hi Jagan, > > On Mon, Oct 9, 2017 at 3:05 PM, Jagan Teki wrote: > >> I didn't dig much, but the i.MX6UL case has rebooting with DM_MMC for >> both SPL and U-Boot proper. > > Looks like the same issue I saw with mx6q, which has been fixed by this > commit: > http://git.denx.de/?p=u-boot.git;a=commitdiff;h=3ea0520512089cffbe02b7d6eb645cdfddb09c5c;hp=4f42a0d7210bd8d4d1f5e2fb73456679d74c44cd Still looping for i.MX6UL. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND] DW SPI: Get clock value from Device Tree
On Tue, Sep 26, 2017 at 6:40 PM, Eugeniy Paltsev
wrote:
> Add option to set spi controller clock frequency via device tree
> using standard clock bindings.
> Old way of setting spi controller clock frequency (via implementation
> of 'cm_get_spi_controller_clk_hz' function in platform specific code)
> remains supported.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> Resending due to previously sent one was discarded by mailing list.
>
> drivers/spi/designware_spi.c | 68
> +++-
> 1 file changed, 67 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
> index 5aa507b..c70697e 100644
> --- a/drivers/spi/designware_spi.c
> +++ b/drivers/spi/designware_spi.c
> @@ -11,6 +11,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -94,6 +95,7 @@ struct dw_spi_priv {
> void __iomem *regs;
> unsigned int freq; /* Default frequency */
> unsigned int mode;
> + unsigned long bus_clk_rate;
>
> int bits_per_word;
> u8 cs; /* chip select pin */
> @@ -176,14 +178,78 @@ static void spi_hw_init(struct dw_spi_priv *priv)
> debug("%s: fifo_len=%d\n", __func__, priv->fifo_len);
> }
>
> +/*
> + * cm_get_spi_controller_clk_hz function is old way to set spi controller
> + * frequency. If it isn't implemented and spi controller frequency isn't set
> via
> + * device tree we will get into next default function.
> + */
> +__weak unsigned int cm_get_spi_controller_clk_hz(void)
> +{
> + error("SPI clock is defined neither via device tree nor via
> cm_get_spi_controller_clk_hz!");
> +
> + return 0;
> +}
> +
> +static int dw_spi_of_get_clk(struct udevice *bus)
> +{
> +#if CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(CLK)
> + struct dw_spi_priv *priv = dev_get_priv(bus);
> + unsigned long clk_rate;
> + struct clk clk;
> + int ret;
> +
> + ret = clk_get_by_index(bus, 0, &clk);
> + if (ret)
> + return -EINVAL;
> +
> + ret = clk_enable(&clk);
> + if (ret && ret != -ENOSYS)
> + return ret;
> +
> + clk_rate = clk_get_rate(&clk);
> + if (!clk_rate)
> + return -EINVAL;
Use bus_clk_rate instead of local clk_rate and disable the clk if it
can't get the rate.
> +
> + priv->bus_clk_rate = clk_rate;
> +
> + clk_free(&clk);
> +
> + return 0;
> +#endif
> +
> + return -ENOSYS;
> +}
> +
> +static int dw_spi_get_clk(struct udevice *bus)
> +{
> + struct dw_spi_priv *priv = dev_get_priv(bus);
> +
> + /* Firstly try to get clock frequency from device tree */
> + if (!dw_spi_of_get_clk(bus))
> + return 0;
> +
> + /* In case of failure rollback to cm_get_spi_controller_clk_hz */
> + priv->bus_clk_rate = cm_get_spi_controller_clk_hz();
Why weak function, we can just return with error message since weak
does the same job
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-sh/rmobile branch
On Wed, Oct 11, 2017 at 08:53:25AM +0900, Nobuhiro Iwamatsu wrote: > Hi, Tom. > > The following changes since commit 37a7908137a8c904f43c83f3e6c269cd51bf6126: > > ARM: dts: rmobile: Update DTS to match Linux 4.13 (2017-09-12 23:01:51 > +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-sh.git rmobile > > for you to fetch changes up to 17cf99a5bb904a6e7c8797db2632bbe65ae1cfb5: > > ARM: rmobile: dts: Add SDR104/HS200 to Salvator-X (2017-10-10 08:22:54 > +0900) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND] DW SPI: Get clock value from Device Tree
Hi Jagan,
Thanks for respond, my comments are given inline.
On Wed, 2017-10-11 at 16:36 +0530, Jagan Teki wrote:
> On Tue, Sep 26, 2017 at 6:40 PM, Eugeniy Paltsev
> wrote:
> > Add option to set spi controller clock frequency via device tree
> > using standard clock bindings.
> > Old way of setting spi controller clock frequency (via implementation
> > of 'cm_get_spi_controller_clk_hz' function in platform specific code)
> > remains supported.
> >
> > Signed-off-by: Eugeniy Paltsev
> > ---
> > diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
> > index 5aa507b..c70697e 100644
> > --- a/drivers/spi/designware_spi.c
> > +++ b/drivers/spi/designware_spi.c
> > @@ -11,6 +11,7 @@
> > +/*
> > + * cm_get_spi_controller_clk_hz function is old way to set spi controller
> > + * frequency. If it isn't implemented and spi controller frequency isn't
> > set via
> > + * device tree we will get into next default function.
> > + */
> > +__weak unsigned int cm_get_spi_controller_clk_hz(void)
> > +{
> > + error("SPI clock is defined neither via device tree nor via
> > cm_get_spi_controller_clk_hz!");
> > +
> > + return 0;
> > +}
> > +
> > +static int dw_spi_get_clk(struct udevice *bus)
> > +{
> > + struct dw_spi_priv *priv = dev_get_priv(bus);
> > +
> > + /* Firstly try to get clock frequency from device tree */
> > + if (!dw_spi_of_get_clk(bus))
> > + return 0;
> > +
> > + /* In case of failure rollback to cm_get_spi_controller_clk_hz */
> > + priv->bus_clk_rate = cm_get_spi_controller_clk_hz();
>
> Why weak function, we can just return with error message since weak
> does the same job
I used weak function for backward compatibility with the previous driver
version:
The previous driver version used cm_get_spi_controller_clk_hz() function which
is set outside of designware_spi.c
You can look at
arch/arm/mach-socfpga/clock_manager_arria10.c
arch/arm/mach-socfpga/clock_manager_gen5.c
...
as examples.
So I define cm_get_spi_controller_clk_hz as weak in this driver to handle both
use cases:
1) We set frequency via device tree and cm_get_spi_controller_clk_hz is NOT
defined outside of designware_spi.c (new way)
2) We set frequency using cm_get_spi_controller_clk_hz, which is defined
outside of designware_spi.c (old way)
I guess it is OK?
--
Eugeniy Paltsev
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] armv8: ls1088: Move CONFIG_ENV_IS_IN_SPI_FLASH to defconfig
Signed-off-by: Ashish Kumar --- v2: Reword commit msg configs/ls1088aqds_qspi_defconfig | 1 + configs/ls1088ardb_qspi_defconfig | 1 + include/configs/ls1088aqds.h | 1 - include/configs/ls1088ardb.h | 1 - 4 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configs/ls1088aqds_qspi_defconfig b/configs/ls1088aqds_qspi_defconfig index 4b0d604..ce91a72 100644 --- a/configs/ls1088aqds_qspi_defconfig +++ b/configs/ls1088aqds_qspi_defconfig @@ -29,5 +29,6 @@ CONFIG_PCIE_LAYERSCAPE=y CONFIG_SYS_NS16550=y CONFIG_FSL_DSPI=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_ENV_IS_IN_SPI_FLASH=y # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_FSL_LS_PPA=y diff --git a/configs/ls1088ardb_qspi_defconfig b/configs/ls1088ardb_qspi_defconfig index 2d5a134..4501ba2 100644 --- a/configs/ls1088ardb_qspi_defconfig +++ b/configs/ls1088ardb_qspi_defconfig @@ -29,5 +29,6 @@ CONFIG_PCIE_LAYERSCAPE=y CONFIG_SYS_NS16550=y CONFIG_FSL_DSPI=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y +CONFIG_ENV_IS_IN_SPI_FLASH=y # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_FSL_LS_PPA=y diff --git a/include/configs/ls1088aqds.h b/include/configs/ls1088aqds.h index 3547b0b..4af64e2 100644 --- a/include/configs/ls1088aqds.h +++ b/include/configs/ls1088aqds.h @@ -20,7 +20,6 @@ unsigned long get_board_ddr_clk(void); #if defined(CONFIG_QSPI_BOOT) -#define CONFIG_ENV_IS_IN_SPI_FLASH #define CONFIG_ENV_SIZE0x2000 /* 8KB */ #define CONFIG_ENV_OFFSET 0x30/* 3MB */ #define CONFIG_ENV_SECT_SIZE 0x4 diff --git a/include/configs/ls1088ardb.h b/include/configs/ls1088ardb.h index 3223278..0c08158 100644 --- a/include/configs/ls1088ardb.h +++ b/include/configs/ls1088ardb.h @@ -12,7 +12,6 @@ #define CONFIG_DISPLAY_BOARDINFO_LATE #if defined(CONFIG_QSPI_BOOT) -#define CONFIG_ENV_IS_IN_SPI_FLASH #define CONFIG_ENV_SIZE0x2000 /* 8KB */ #define CONFIG_ENV_OFFSET 0x30/* 3MB */ #define CONFIG_ENV_SECT_SIZE 0x4 -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [XHCI] Maintainer split
On 10/11/2017 03:30 AM, Bin Meng wrote: > On Wed, Oct 11, 2017 at 5:04 AM, Tom Rini wrote: >> On Tue, Oct 10, 2017 at 11:27:39AM +0200, Marek Vasut wrote: >> >>> Hi, >>> >>> I am considering offloading xhci maintainership to Bin . >>> Thoughts ? >> >> If Bin wants it, I have no objections. >> > > Thanks for the offer. Glad I can help! So how do we go on from here ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [XHCI] Maintainer split
On Wed, Oct 11, 2017 at 03:17:24PM +0200, Marek Vasut wrote: > On 10/11/2017 03:30 AM, Bin Meng wrote: > > On Wed, Oct 11, 2017 at 5:04 AM, Tom Rini wrote: > >> On Tue, Oct 10, 2017 at 11:27:39AM +0200, Marek Vasut wrote: > >> > >>> Hi, > >>> > >>> I am considering offloading xhci maintainership to Bin . > >>> Thoughts ? > >> > >> If Bin wants it, I have no objections. > >> > > > > Thanks for the offer. Glad I can help! > > So how do we go on from here ? A patch to MAINTAINERS, and if you want Bin to send PRs from u-boot-usb, ask Wolfgang to put Bin's key on that repository too. And then you two coordinate off-list on everything else. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dwc: ep0: Allocate and flush dwc->ep0_trb in a cache aligned manner
On Wednesday 11 October 2017 02:28 PM, Kishon Vijay Abraham I wrote: > Hi, > > On Wednesday 11 October 2017 01:53 PM, Faiz Abbas wrote: >> Hi, >> >> On Tuesday 10 October 2017 07:19 PM, Marek Vasut wrote: >>> On 10/10/2017 12:45 PM, Faiz Abbas wrote: Hi Marek, On Tuesday 10 October 2017 01:30 PM, Marek Vasut wrote: > On 10/10/2017 07:48 AM, Kishon Vijay Abraham I wrote: >> Hi, > > Hi, > > [...] > - dwc3_flush_cache((uintptr_t)trb, sizeof(*trb)); + dwc3_flush_cache((uintptr_t)dwc->ep0_trb_addr, sizeof(*trb) * 2); >>> >>> Why *2 ? >> >> Because its allocated as sizeof(*dwc->ep0_trb) * 2 below. This >> is not >> strictly required as dwc3_flush_cache() rounds up the size to >> CACHELINE_SIZE but from a caller POV, flush everything we >> allocated. > > Can the other TRB be in use ? Maybe aligning the TRBs to > cacheline size > would be better ? > A single trb is 16 bytes in size and two of them are allocated contiguously. >>> >>> Why are two allocated continuously ? (I am not dwc3 expert) >> >> The TRB's should be allocated contiguously for dwc3 and only the base of >> the >> entire TRB table is programmed in the HW. >> <-- TRB table base address >> | TRB0 | >> || >> | TRB1 | >> || >> | TRB2 | >> || >> | TRBn | >> || >> >> >> >> Neither am I. I did try to pad to the dwc_trb structure such that >> each >> trb is 64 bytes in size but this leads to failures when testing. I >> didn't get a chance to debug this though. I suspect its because the >> code >> expects the trbs to be contiguous and/or 16 bytes in size. >> >> It's not the code but it's the HW. > > That'd imply we need either some sort of flushing scheme or non-cachable > memory allocation. What does Linux do ? > The dma_alloc_coherent in linux kernel allocates non-cachable memory. Currently, the code is using local variable trb to flush the cache. When the first trb is used, dwc3_flush_cache flushes the complete CACHELINE_SIZE (including the 2nd trb). When the 2nd trb is used to flush cache, since it is an unaligned flush, it will issue a warning and will align it to the lower cache line boundary (flushing the 1st trb in the process). So with or without this patch, both trbs are getting flushed with every call. With the patch, we can just avoid misaligned messages by always flushing using an aligned address. >>> >>> What worries me is that you can flush something into the memory while >>> the controller is writing into it as well. Is that possible ? >>> >> No, control to the hardware is only given after all the trbs have been >> configured and flushed to memory. This is done by using the chain >> variable in the code. >> >> dwc3_flush_cache((uintptr_t)buf_dma, len); >> dwc3_flush_cache((uintptr_t)dwc->ep0_trb_addr, sizeof(*trb) * 2); > > this flush_cache can be moved after the chain so that flush is only invoked > after all the TRB's has been configured. Sure, that can be done. Thanks, Faiz ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 031/080] serial: ns16550: Fix address translation
Hi,
On Mon, Oct 9, 2017 at 4:09 PM, Simon Glass wrote:
> Hi,
>
> On 9 October 2017 at 06:55, Dr. Philipp Tomsich
> wrote:
>>
>>> On 9 Oct 2017, at 14:45, Mario Six wrote:
>>>
>>> (adding Philipp since he converted lots of drivers to livetree recently)
>>>
>>> On Mon, Oct 9, 2017 at 6:48 AM, Simon Glass wrote:
Hi Mario,
On 29 September 2017 at 06:51, Mario Six wrote:
> The dev_read_addr function does not do any bus translations, and just
> returns the raw address read from the device tree, which makes the
> driver not work on systems that need bus translations to get the actual
> memory address of the device's register space.
Aside from any current functionality, what is the correct thing for
dev_read_addr() to do? I worry that the two parts (live/flat tree)
might do different things.
>>>
>>> I took a closer look, and indeed, the two parts of dev_read_addr behave
>>> differently: dev_read_addr calls dev_read_addr_index, which calls either
>>> ofnode_get_addr_index when live tree is active, or devfdt_get_addr_index
>>> when
>>> it's not. devfdt_get_addr_index applies bus translations, but
>>> ofnode_get_addr_index returns the untranslated address using of_read_number
>>> (the else part doesn't run, since we have an active live tree if
>>> ofnode_get_addr_index was called).
>>
>> Good point. I would expect the livetree case to use translated addresses
>> during runtime, as dev_read_addr_index calls either ofnode_get_addr_index
>> or devfdt_get_addr_index.
>>
>> In other words: are we missing an address translation from
>> ofnode_get_addr_index
>> or should the address retrieved via ofnode_get_addr_index have been
>> translated by earlier processing?
>
> Thank you both. Yes it seems like the right answer is to add the
> missing translation in. There is a CONFIG_OF_TRANSLATE which enables
> this. I think most boards don't use it, which is probably why there
> are no problems without it, but I think it is becoming more common as
> boards become more complex.
>
OK, I'll send a separate patch this week. Thanks for taking a look!
>>
>>>
>>> We could fix this by running of_translate_address on the value returned by
>>> of_read_number, so that dev_get_addr would then always return a translated
>>> address.
>>>
>>> But what I think is strange is that most live tree conversion patches (e.g.
>>> a9d3037 ("usb: dwc2: convert to livetree") or 4aac33f ("dm: mmc: fsl_esdhc:
>>> Update to support livetree")) simply replaced devfdt_get_addr (which does
>>> apply
>>> bus translations) with dev_read_addr (which does not apply bus translations
>>> in
>>> the live tree case). Shouldn't the converted driver have failed in the live
>>> tree case? Or were all drivers converted until now not depending on any bus
>>> translations?
>>>
In any case, we should not compound the problem if dev_read_addr() is
wrong.
>
> Since the dev_read_addr function is widely used, we refrain from
> modifying it, and instead read the raw address from the device tree, and
> apply the bus translations using the recently introduced
> dev_translate_address function.
>
> Signed-off-by: Mario Six
> ---
> drivers/serial/ns16550.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
REgards,
Simon
>>>
>>> Best regards,
>>>
>>> Mario
>>
>
> Regards,
> Simon
>
Best regards,
Mario
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] i2c: stm32f7_i2c: fix usage of useless local variable
From: Patrice Chotard
Remove useless local variable "s" and use directly
function's parameter "output"
Signed-off-by: Patrice Chotard
---
drivers/i2c/stm32f7_i2c.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index d519c17..610a9ef 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -640,7 +640,7 @@ static int stm32_i2c_compute_timing(struct stm32_i2c_priv
*i2c_priv,
struct stm32_i2c_setup *setup,
struct stm32_i2c_timings *output)
{
- struct stm32_i2c_timings *v, *_v, s;
+ struct stm32_i2c_timings *v, *_v;
struct list_head solutions;
int ret;
@@ -676,16 +676,10 @@ static int stm32_i2c_compute_timing(struct stm32_i2c_priv
*i2c_priv,
if (ret)
goto exit;
- ret = stm32_i2c_choose_solution(setup, &solutions, &s);
+ ret = stm32_i2c_choose_solution(setup, &solutions, output);
if (ret)
goto exit;
- output->presc = s.presc;
- output->scldel = s.scldel;
- output->sdadel = s.sdadel;
- output->scll = s.scll;
- output->sclh = s.sclh;
-
debug("%s: Presc: %i, scldel: %i, sdadel: %i, scll: %i, sclh: %i\n",
__func__, output->presc,
output->scldel, output->sdadel,
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] stm32f7_i2c fixes
From: Patrice Chotard This series : _ fixes data abort for stm32f7_i2c driver _ removes useless local variable Christophe Kerello (1): i2c: stm32f7_i2c: fix data abort Patrice Chotard (1): i2c: stm32f7_i2c: fix usage of useless local variable drivers/i2c/stm32f7_i2c.c | 17 ++--- 1 file changed, 6 insertions(+), 11 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] i2c: stm32f7_i2c: fix data abort
From: Christophe Kerello
As "v" is a local variable in stm32_i2c_choose_solution()
"v" has to be copied into "s" to avoid data abort in
stm32_i2c_compute_timing().
Signed-off-by: Christophe Kerello
Reviewed-by: Patrick DELAUNAY
Signed-off-by: Patrice Chotard
---
drivers/i2c/stm32f7_i2c.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/stm32f7_i2c.c b/drivers/i2c/stm32f7_i2c.c
index bf5fefa..d519c17 100644
--- a/drivers/i2c/stm32f7_i2c.c
+++ b/drivers/i2c/stm32f7_i2c.c
@@ -571,6 +571,7 @@ static int stm32_i2c_choose_solution(struct stm32_i2c_setup
*setup,
u32 dnf_delay;
u32 tsync;
u16 l, h;
+ bool sol_found = false;
int ret = 0;
af_delay_min = setup->analog_filter ?
@@ -619,14 +620,15 @@ static int stm32_i2c_choose_solution(struct
stm32_i2c_setup *setup,
clk_error_prev = clk_error;
v->scll = l;
v->sclh = h;
- s = v;
+ sol_found = true;
+ memcpy(s, v, sizeof(*s));
}
}
}
}
}
- if (!s) {
+ if (!sol_found) {
error("%s: no solution at all\n", __func__);
ret = -EPERM;
}
@@ -638,7 +640,7 @@ static int stm32_i2c_compute_timing(struct stm32_i2c_priv
*i2c_priv,
struct stm32_i2c_setup *setup,
struct stm32_i2c_timings *output)
{
- struct stm32_i2c_timings *v, *_v, *s;
+ struct stm32_i2c_timings *v, *_v, s;
struct list_head solutions;
int ret;
@@ -669,21 +671,20 @@ static int stm32_i2c_compute_timing(struct stm32_i2c_priv
*i2c_priv,
return -EINVAL;
}
- s = NULL;
INIT_LIST_HEAD(&solutions);
ret = stm32_i2c_compute_solutions(setup, &solutions);
if (ret)
goto exit;
- ret = stm32_i2c_choose_solution(setup, &solutions, s);
+ ret = stm32_i2c_choose_solution(setup, &solutions, &s);
if (ret)
goto exit;
- output->presc = s->presc;
- output->scldel = s->scldel;
- output->sdadel = s->sdadel;
- output->scll = s->scll;
- output->sclh = s->sclh;
+ output->presc = s.presc;
+ output->scldel = s.scldel;
+ output->sdadel = s.sdadel;
+ output->scll = s.scll;
+ output->sclh = s.sclh;
debug("%s: Presc: %i, scldel: %i, sdadel: %i, scll: %i, sclh: %i\n",
__func__, output->presc,
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/11] efi_loader: Initial EFI_DEVICE_PATH_UTILITIES_PROTOCOL
On 10.10.17 14:22, Rob Clark wrote:
> From: Leif Lindholm
>
> Not complete, but enough for Shell.efi and SCT.efi. We'll implement the
> rest as needed or once we have SCT running properly so there is a way to
> validate the interface against the conformance test suite.
>
> Initial skeleton written by Leif, and then implementation by myself.
>
> Cc: Leif Lindholm
> Signed-off-by: Rob Clark
> ---
> include/efi_api.h | 34 +++-
> include/efi_loader.h | 2 +
> lib/efi_loader/Makefile| 1 +
> lib/efi_loader/efi_boottime.c | 4 ++
> lib/efi_loader/efi_device_path_utilities.c | 88
> ++
> 5 files changed, 127 insertions(+), 2 deletions(-)
> create mode 100644 lib/efi_loader/efi_device_path_utilities.c
>
> diff --git a/include/efi_api.h b/include/efi_api.h
> index a9a6494afe..ffdba7fe1a 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -28,8 +28,9 @@ enum efi_timer_delay {
> EFI_TIMER_RELATIVE = 2
> };
>
> -#define UINTN size_t
> -typedef long INTN;
> +#define UINTN size_t /* TODO this should be removed in a future patch */
$ git grep UINTN | wc -l
13
Just send a preceding patch that introduces efi_uintn_t and replaces all
occurences of UINTN with it.
The uintn bits shouldn't be part of the
EFI_DEVICE_PATH_UTILITIES_PROTOCOL patch anyways :).
> +typedef size_t efi_uintn_t;
> +typedef ssize_t efi_intn_t;
> typedef uint16_t *efi_string_t;
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mx7dsabresd: Remove CONFIG_DM_MMC to avoid regression
Since U-Boot 2017.09 it is no longer possible to boot a kernel from SD
card:
U-Boot 2017.11-rc1-00149-g38c8107-dirty (Oct 11 2017 - 09:55:22 -0300)
CPU: Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz)
CPU: Commercial temperature grade (0C to 95C) at 35C
Reset cause: POR
Model: Freescale i.MX7 SabreSD Board
Board: i.MX7D SABRESD in non-secure mode
DRAM: 1 GiB
MMC: MMC/SD: Reset never completed.
MMC Device 0 not found
*** Warning - No MMC card found, using default environment
While a proper fix is not available, remove CONFIG_DM_MMC and register
the USDHC1 port in the old way, so that this board can boot a kernel
again.
Signed-off-by: Fabio Estevam
---
board/freescale/mx7dsabresd/mx7dsabresd.c | 42 +++
configs/mx7dsabresd_defconfig | 1 -
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c
b/board/freescale/mx7dsabresd/mx7dsabresd.c
index 5819b18..12f7c58 100644
--- a/board/freescale/mx7dsabresd/mx7dsabresd.c
+++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
@@ -29,6 +29,9 @@ DECLARE_GLOBAL_DATA_PTR;
#define UART_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | \
PAD_CTL_PUS_PU100KOHM | PAD_CTL_HYS)
+#define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
+ PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
+
#define ENET_PAD_CTRL (PAD_CTL_PUS_PU100KOHM | PAD_CTL_DSE_3P3V_49OHM)
#define ENET_PAD_CTRL_MII (PAD_CTL_DSE_3P3V_32OHM)
@@ -191,6 +194,18 @@ static iomux_v3_cfg_t const fec1_pads[] = {
MX7D_PAD_GPIO1_IO11__ENET1_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL_MII),
};
+static iomux_v3_cfg_t const usdhc1_pads[] = {
+ MX7D_PAD_SD1_CLK__SD1_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD1_CMD__SD1_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD1_DATA0__SD1_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD1_DATA1__SD1_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD1_DATA2__SD1_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD1_DATA3__SD1_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+
+ MX7D_PAD_SD1_CD_B__GPIO5_IO0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX7D_PAD_SD1_RESET_B__GPIO5_IO2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+};
+
static void setup_iomux_fec(void)
{
imx_iomux_v3_setup_multiple_pads(fec1_pads, ARRAY_SIZE(fec1_pads));
@@ -218,6 +233,33 @@ int mmc_map_to_kernel_blk(int dev_no)
return dev_no;
}
+#define USDHC1_CD_GPIO IMX_GPIO_NR(5, 0)
+#define USDHC1_PWR_GPIOIMX_GPIO_NR(5, 2)
+
+static struct fsl_esdhc_cfg usdhc_cfg[3] = {
+ {USDHC1_BASE_ADDR, 0, 4},
+};
+
+int board_mmc_getcd(struct mmc *mmc)
+{
+ return !gpio_get_value(USDHC1_CD_GPIO);
+}
+
+int board_mmc_init(bd_t *bis)
+{
+ imx_iomux_v3_setup_multiple_pads(usdhc1_pads, ARRAY_SIZE(usdhc1_pads));
+ gpio_request(USDHC1_CD_GPIO, "usdhc1_cd");
+ gpio_direction_input(USDHC1_CD_GPIO);
+ gpio_request(USDHC1_PWR_GPIO, "usdhc1_pwr");
+ gpio_direction_output(USDHC1_PWR_GPIO, 0);
+ udelay(500);
+ gpio_direction_output(USDHC1_PWR_GPIO, 1);
+ usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
+ return fsl_esdhc_initialize(bis, &usdhc_cfg[0]);
+
+ return 0;
+}
+
#ifdef CONFIG_FEC_MXC
int board_eth_init(bd_t *bis)
{
diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
index 26250fd..9e07a94 100644
--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -44,7 +44,6 @@ CONFIG_DFU_RAM=y
CONFIG_DM_GPIO=y
CONFIG_DM_74X164=y
CONFIG_DM_I2C=y
-CONFIG_DM_MMC=y
CONFIG_SPI_FLASH=y
CONFIG_SPI_FLASH_EON=y
CONFIG_PHYLIB=y
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mx7dsabresd: Remove CONFIG_DM_MMC to avoid regression
On Wed, Oct 11, 2017 at 11:23 AM, Fabio Estevam wrote: > Since U-Boot 2017.09 it is no longer possible to boot a kernel from SD > card: > > U-Boot 2017.11-rc1-00149-g38c8107-dirty (Oct 11 2017 - 09:55:22 -0300) > > CPU: Freescale i.MX7D rev1.2 1000 MHz (running at 792 MHz) > CPU: Commercial temperature grade (0C to 95C) at 35C > Reset cause: POR > Model: Freescale i.MX7 SabreSD Board > Board: i.MX7D SABRESD in non-secure mode > DRAM: 1 GiB > MMC: MMC/SD: Reset never completed. > > MMC Device 0 not found > *** Warning - No MMC card found, using default environment > > While a proper fix is not available, remove CONFIG_DM_MMC and register > the USDHC1 port in the old way, so that this board can boot a kernel > again. > > Signed-off-by: Fabio Estevam I understand your goal but I think we ought to focus on fixing the root cause of it instead of moving things back out of DM. I even think we could postpone a little the release until a fix is made but revert out from DM seems wrong. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/11] efi_loader: Initial HII protocols
On 10.10.17 14:22, Rob Clark wrote:
> From: Leif Lindholm
>
> Enough implementation of the following protocols to run Shell.efi and
> SCT.efi:
>
> EfiHiiConfigRoutingProtocolGuid
> EfiHiiDatabaseProtocol
> EfiHiiStringProtocol
>
> We'll fill in the rest once SCT is running properly so we can validate
> the implementation against the conformance test suite.
>
> Initial skeleton written by Leif, and then implementation by myself.
>
> Cc: Leif Lindholm
> Signed-off-by: Rob Clark
> ---
> include/efi_api.h | 261 ++
> include/efi_loader.h | 6 +
> lib/efi_loader/Makefile | 2 +-
> lib/efi_loader/efi_boottime.c | 9 +
> lib/efi_loader/efi_hii.c | 507
> ++
> 5 files changed, 784 insertions(+), 1 deletion(-)
> create mode 100644 lib/efi_loader/efi_hii.c
>
> diff --git a/include/efi_api.h b/include/efi_api.h
> index ffdba7fe1a..164147dc87 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -16,6 +16,7 @@
> #define _EFI_API_H
>
> #include
> +#include
>
> #ifdef CONFIG_EFI_LOADER
> #include
> @@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
> uint16_t node_length);
> };
>
> +#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
> + EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
> + 0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
> +
> +typedef uint16_t efi_string_id_t;
> +
> +struct efi_hii_config_routing_protocol {
> + efi_status_t(EFIAPI *extract_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t request,
> + efi_string_t *progress,
> + efi_string_t *results);
> + efi_status_t(EFIAPI *export_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + efi_string_t *results);
> + efi_status_t(EFIAPI *route_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t configuration,
> + efi_string_t *progress);
> + efi_status_t(EFIAPI *block_to_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t config_request,
> + const uint8_t *block,
> + const efi_uintn_t block_size,
> + efi_string_t *config,
> + efi_string_t *progress);
> + efi_status_t(EFIAPI *config_to_block)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t config_resp,
> + const uint8_t *block,
> + const efi_uintn_t *block_size,
> + efi_string_t *progress);
> + efi_status_t(EFIAPI *get_alt_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t config_resp,
> + const efi_guid_t *guid,
> + const efi_string_t name,
> + const struct efi_device_path *device_path,
> + const efi_string_t alt_cfg_id,
> + efi_string_t *alt_cfg_resp);
> +};
> +
> +#define EFI_HII_DATABASE_PROTOCOL_GUID\
> + EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
> + 0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
> +
> +typedef enum {
> + EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
> + EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, EFI_KEY_LEFT_ARROW,
> + EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
> + EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
> + EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, EFI_KEY_B6,
> + EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
> + EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
> + EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
> + EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
> + EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
> + EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
> + EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, EFI_KEY_D8,
> + EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11, EFI_KEY_D12, EFI_KEY_D13,
> + EFI_KEY_DEL, EFI_KEY_END, EFI_KEY_PG_DN, EFI_KEY_SEVEN, EFI_KEY_EIGHT,
> + EFI_KEY_NINE, EFI_KEY_E0, EFI_KEY_E1, EFI_KEY_E2, EFI_KEY_E3,
> + EFI_KEY_E4, EFI_KEY_E5, EFI_KEY_E6, EFI_KEY_E7, EFI_KEY_E8, EFI_KEY_E9,
> + EFI_KEY_E10, EFI_KEY_E11, EFI_KEY_E12, EFI_KEY_BACK_SPACE,
> + EFI_KEY_INS, EFI_KEY_HOME, EFI_KEY_PG_UP, EFI_KEY_NLCK, EFI_KEY_SLASH,
> + EFI_KEY_ASTERISK, EFI_KEY_MINUS, EFI_KEY_ESC, EFI_KEY_F1, EFI_KEY_F2,
> + EFI_KEY_F3, EFI_KEY_F4, EFI_KEY_F5, EFI_KEY_F6, EFI_KEY_F7, EFI_KEY_F8,
> + EFI_KEY_F9, EFI_KEY_F10, EFI_KEY_F11, EFI_KEY_F12, EFI_KEY_PRINT,
> + EFI_KEY_SLCK, EFI_KEY_PAUSE,
> +} efi_key;
> +
> +struct efi_key_descriptor {
> + efi_key key;
> + uint16_t unicode;
> + ui
Re: [U-Boot] [PATCH 03/11] efi_loader: Initial EFI_UNICODE_COLLATION_PROTOCOL
On 10.10.17 14:22, Rob Clark wrote:
> From: Leif Lindholm
>
> Not complete, but enough for Shell.efi and SCT.efi.
>
> Initial skeleton written by Leif, and then implementation by myself.
>
> Cc: Leif Lindholm
> Signed-off-by: Rob Clark
> ---
> include/efi_api.h | 41 ++
> include/efi_loader.h | 3 +
> lib/efi_loader/Makefile | 2 +-
> lib/efi_loader/efi_boottime.c | 6 ++
> lib/efi_loader/efi_unicode.c | 170
> ++
> 5 files changed, 221 insertions(+), 1 deletion(-)
> create mode 100644 lib/efi_loader/efi_unicode.c
>
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 164147dc87..38dd1240c1 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -797,6 +797,47 @@ struct efi_hii_string_protocol {
> efi_uintn_t *secondary_languages_size);
> };
>
> +/*
> + * Both UNICODE_COLLATION protocols seem to be the same thing, but
> + * advertised with two different GUID's because, why not?
> + */
> +
> +#define EFI_UNICODE_COLLATION_PROTOCOL_GUID \
> + EFI_GUID(0x1d85cd7f, 0xf43d, 0x11d2, \
> + 0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
> +
> +#define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \
> + EFI_GUID(0xa4c751fc, 0x23ae, 0x4c3e, \
> + 0x92, 0xe9, 0x49, 0x64, 0xcf, 0x63, 0xf3, 0x49)
> +
> +struct efi_unicode_collation_protocol {
> + efi_intn_t (EFIAPI *stri_coll)(
> + struct efi_unicode_collation_protocol *this,
> + efi_string_t s1,
> + efi_string_t s2);
> + bool (EFIAPI *metai_match)(
> + struct efi_unicode_collation_protocol *this,
> + efi_string_t string,
> + efi_string_t pattern);
> + void (EFIAPI *str_lwr)(
> + struct efi_unicode_collation_protocol *this,
> + efi_string_t string);
> + void (EFIAPI *str_upr)(
> + struct efi_unicode_collation_protocol *this,
> + efi_string_t string);
> + void (EFIAPI *fat_to_str)(
> + struct efi_unicode_collation_protocol *this,
> + efi_uintn_t fat_size,
> + uint8_t *fat,
> + efi_string_t string);
> + bool (EFIAPI *str_to_fat)(
> + struct efi_unicode_collation_protocol *this,
> + efi_string_t string,
> + efi_uintn_t fat_size,
> + uint8_t *fat);
> + uint8_t *supported_languages;
> +};
> +
> #define EFI_GOP_GUID \
> EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
>0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 591bf07e7a..af6812b2b4 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -83,6 +83,7 @@ extern const struct efi_device_path_utilities_protocol
> efi_device_path_utilities
> extern const struct efi_hii_config_routing_protocol efi_hii_config_routing;
> extern const struct efi_hii_database_protocol efi_hii_database;
> extern const struct efi_hii_string_protocol efi_hii_string;
> +extern const struct efi_unicode_collation_protocol efi_unicode_collation;
>
> uint16_t *efi_dp_str(struct efi_device_path *dp);
>
> @@ -97,6 +98,8 @@ extern const efi_guid_t
> efi_guid_device_path_utilities_protocol;
> extern const efi_guid_t efi_guid_hii_config_routing_protocol;
> extern const efi_guid_t efi_guid_hii_database_protocol;
> extern const efi_guid_t efi_guid_hii_string_protocol;
> +extern const efi_guid_t efi_guid_unicode_collation_protocol;
> +extern const efi_guid_t efi_guid_unicode_collation_protocol2;
>
> extern unsigned int __efi_runtime_start, __efi_runtime_stop;
> extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> index 725e0cba85..7ea96a4f1c 100644
> --- a/lib/efi_loader/Makefile
> +++ b/lib/efi_loader/Makefile
> @@ -17,7 +17,7 @@ endif
> obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
> obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
> obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
> -obj-y += efi_device_path_utilities.o efi_hii.o
> +obj-y += efi_device_path_utilities.o efi_hii.o efi_unicode.o
> obj-y += efi_file.o efi_variable.o efi_bootmgr.o
> obj-$(CONFIG_LCD) += efi_gop.o
> obj-$(CONFIG_DM_VIDEO) += efi_gop.o
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index c179afc25a..b568f3f162 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1166,6 +1166,12 @@ void efi_setup_loaded_image(struct efi_loaded_image
> *info, struct efi_object *ob
> obj->protocols[7].guid = &efi_guid_hii_config_routing_protocol;
> obj->protocols[7].protocol_interface = (void *)&efi_hii_config_routing;
>
> + obj->protocols[8].guid = &efi_guid_unicode_collation_protocol;
> + obj->protocols[8].protocol_interface = (void *)&efi_unicode_collation;
> +
> + obj->proto
Re: [U-Boot] [PATCH 04/11] efi_loader: SIMPLE_TEXT_INPUT_EX plus wire up objects properly
On 10.10.17 14:23, Rob Clark wrote: > We need the _EX version for SCT.. and we need to wire up the > corresponding objects in the systab properly, as well as dealing > with the console_in object advertising multiple protocols. > > Signed-off-by: Rob Clark Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/11] efi_loader: console support for color attributes
On 10.10.17 14:23, Rob Clark wrote: > Shell.efi uses this, and supporting color attributes makes things look > nicer. Map the EFI fg/bg color attributes to ANSI escape sequences. > Not all colors have a perfect match, but spec just says "Devices > supporting a different number of text colors are required to emulate the > above colors to the best of the device’s capabilities". > > Signed-off-by: Rob Clark Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout
On 10.10.17 14:23, Rob Clark wrote: > In some cases, it is quite useful to have (for example) EFI on screen > but u-boot on serial port. > > This adds two new optional environment variables, "efiin" and "efiout", > which can be used to set EFI console input/output independently of > u-boot's input/output. If unset, EFI console will default to stdin/ > stdout as before. > > Signed-off-by: Rob Clark With this patch, we lose the ability to have the efi in/out go to both graphical and serial console, right? This is critical functionality to have, since we don't necessarily know which output/input a user ends up using. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/11] efi_loader: fix events
On 10.10.17 14:23, Rob Clark wrote:
> An event can be created with type==0, Shell.efi does this for an event
> that is set when Ctrl-C is typed. So our current approach of having a
> fixed set of timer slots, and determining which slots are unused by
> type==0 doesn't work so well. But we don't have any particularly good
> reason to have a fixed table of events, so just dynamically allocate
> them and keep a list.
>
> Also fixes an incorrect implementation of CheckEvent() which was (a)
> incorrectly returning an error if type==0, and (b) didn't handle the
> case of an unsignaled event with a notify callback.
>
> With these fixes (plus implementation of SIMPLE_TEXT_INPUT_EX protocol),
> Ctrl-C works in Shell.efi.
>
> Signed-off-by: Rob Clark
> ---
> include/efi_loader.h | 1 +
> lib/efi_loader/efi_boottime.c | 217
> +-
> 2 files changed, 111 insertions(+), 107 deletions(-)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index e6e55d2cb4..2232caca44 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -154,6 +154,7 @@ struct efi_event {
> enum efi_timer_delay trigger_type;
> bool is_queued;
> bool is_signaled;
> + struct list_head link;
> };
>
>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 39dcc72648..19fafe546c 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -350,11 +350,26 @@ static efi_status_t efi_create_handle(void **handle)
> return r;
> }
>
> +static LIST_HEAD(efi_events);
> +
> /*
> - * Our event capabilities are very limited. Only a small limited
> - * number of events is allowed to coexist.
> + * Check if a pointer is a valid event.
> + *
> + * It might be nice at some point to extend this to a more general
> + * mechanism to check if pointers passed from the EFI world are
> + * valid objects of a particular type.
> */
> -static struct efi_event efi_events[16];
> +static bool efi_is_event(const void *obj)
> +{
> + struct efi_event *evt;
> +
> + list_for_each_entry(evt, &efi_events, link) {
> + if (evt == obj)
> + return true;
> + }
> +
> + return false;
> +}
>
> /*
> * Create an event.
> @@ -377,7 +392,7 @@ efi_status_t efi_create_event(uint32_t type, UINTN
> notify_tpl,
> void *context),
> void *notify_context, struct efi_event **event)
> {
> - int i;
> + struct efi_event *evt;
>
> if (event == NULL)
> return EFI_INVALID_PARAMETER;
> @@ -389,21 +404,24 @@ efi_status_t efi_create_event(uint32_t type, UINTN
> notify_tpl,
> notify_function == NULL)
> return EFI_INVALID_PARAMETER;
>
> - for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
> - if (efi_events[i].type)
> - continue;
> - efi_events[i].type = type;
> - efi_events[i].notify_tpl = notify_tpl;
> - efi_events[i].notify_function = notify_function;
> - efi_events[i].notify_context = notify_context;
> - /* Disable timers on bootup */
> - efi_events[i].trigger_next = -1ULL;
> - efi_events[i].is_queued = false;
> - efi_events[i].is_signaled = false;
> - *event = &efi_events[i];
> - return EFI_SUCCESS;
> - }
> - return EFI_OUT_OF_RESOURCES;
> + evt = calloc(1, sizeof(*evt));
> + if (!evt)
> + return EFI_OUT_OF_RESOURCES;
> +
> + evt->type = type;
> + evt->notify_tpl = notify_tpl;
> + evt->notify_function = notify_function;
> + evt->notify_context = notify_context;
> + /* Disable timers on bootup */
> + evt->trigger_next = -1ULL;
> + evt->is_queued = false;
> + evt->is_signaled = false;
> +
> + list_add_tail(&evt->link, &efi_events);
> +
> + *event = evt;
> +
> + return EFI_SUCCESS;
> }
>
> /*
> @@ -443,30 +461,31 @@ static efi_status_t EFIAPI efi_create_event_ext(
> */
> void efi_timer_check(void)
> {
> - int i;
> + struct efi_event *evt;
> u64 now = timer_get_us();
>
> - for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
> - if (!efi_events[i].type)
> - continue;
> - if (efi_events[i].is_queued)
> - efi_signal_event(&efi_events[i]);
> - if (!(efi_events[i].type & EVT_TIMER) ||
> - now < efi_events[i].trigger_next)
> + /*
> + * TODO perhaps optimize a bit and track the time of next
> + * timer to expire?
> + */
> + list_for_each_entry(evt, &efi_events, link) {
> + if (evt->is_queued)
> + efi_signal_event(evt);
> + if (!(evt->type & EVT_TIMER) ||
> + now < evt->trigger_next)
> continue;
> - switch (efi_events[i].trigger
Re: [U-Boot] [PATCH 08/11] efi_loader: implement SetWatchdogTimer
On 10.10.17 14:23, Rob Clark wrote: > From: Heinrich Schuchardt > > The watchdog is initialized with a 5 minute timeout period. > It can be reset by SetWatchdogTimer. > It is stopped by ExitBoottimeServices. > > Signed-off-by: Heinrich Schuchardt This is missing an SoB line from Rob. Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 09/11] efi_loader: Fix disk dp's for pre-DM/legacy devices
On 10.10.17 14:23, Rob Clark wrote: > This fixes an issue with OpenBSD's bootloader, and I think should also > fix a similar issue with grub2 on legacy devices. In the legacy case > we were creating disk objects for the partitions, but not also the > parent device. > > Reported-by: Jonathan Gray > Signed-off-by: Rob Clark This patch is already in efi-next? Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] kbuild: fix dependency of DT build
I saw a DT build issue report some time before [1]. I was able to
reproduce the bug, and figure out the root cause.
Since commit 6d427c6b1fa0 ("binman: Automatically include a U-Boot
.dtsi file"), invalid .*.cmd files are generated.
Since that commit, DTS files are put into sed and piped to CPP.
Because CPP reads the stream from stdin, -Wp,-MD,$(depfile).pre.tmp
option generates a depfile with the target name "-". This is not
the format expected by fixdep.
Use one more temporary file instead of using pipe. With this, deps_
in the .*.cmd will be fixed. Having a temp file name in source_ is
odd, but it is unsed in the build system. Not a big deal.
[1] https://lists.denx.de/pipermail/u-boot/2017-June/294451.html
Fiexes: 6d427c6b1fa0 ("binman: Automatically include a U-Boot .dtsi file")
Signed-off-by: Masahiro Yamada
---
Probably, I can fix this issue in an even cleaner way.
But, U-Boot build system is a mirror of Linux.
I generally improve Linux first, then import the outcome back to U-Boot.
I will give it a try when I find some time.
scripts/Makefile.lib | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 861a3dc..0d5c529 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -175,7 +175,7 @@ u_boot_dtsi_options = $(wildcard $(dir $<)$(basename
$(notdir $<))-u-boot.dtsi)
# $(warning u_boot_dtsi_options: $(u_boot_dtsi_options))
# We use the first match
-u_boot_dtsi = $(firstword $(u_boot_dtsi_options))
+u_boot_dtsi = $(notdir $(firstword $(u_boot_dtsi_options)))
# Modified for U-Boot
dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc\
@@ -308,9 +308,8 @@ quiet_cmd_dtc = DTC $@
# Modified for U-Boot
# Bring in any U-Boot-specific include at the end of the file
cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
- cat $< $(if $(u_boot_dtsi),\
- | sed "$$ a\#include \"$(u_boot_dtsi)\"") | \
- $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) - ;
\
+ (cat $<; $(if $(u_boot_dtsi),echo '\#include "$(u_boot_dtsi)"')) >
$(pre-tmp); \
+ $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp)
; \
$(DTC) -O dtb -o $@ -b 0 \
-i $(dir $<) $(DTC_FLAGS) \
-d $(depfile).dtc.tmp $(dtc-tmp) ; \
@@ -319,6 +318,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
$(obj)/%.dtb: $(src)/%.dts FORCE
$(call if_changed_dep,dtc)
+pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp)
dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
# DTCO
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 10/11] efi_loader: Add mem-mapped for fallback
On 10.10.17 14:23, Rob Clark wrote:
> When we don't have a real device/image path, such as 'bootefi hello',
> construct a mem-mapped device-path.
>
> This fixes 'bootefi hello' after devicepath refactoring.
>
> Fixes: 95c5553ea2 ("efi_loader: refactor boot device and loaded_image
> handling")
> Signed-off-by: Rob Clark
> ---
> cmd/bootefi.c| 23 +++
> include/efi_api.h| 8
> include/efi_loader.h | 3 +++
> lib/efi_loader/efi_device_path.c | 24
> lib/efi_loader/efi_device_path_to_text.c | 9 +
> 5 files changed, 67 insertions(+)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 24958ada46..18176a1266 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -128,6 +128,7 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt,
> {
> struct efi_loaded_image loaded_image_info = {};
> struct efi_object loaded_image_info_obj = {};
> + struct efi_device_path *memdp = NULL;
> ulong ret;
>
> ulong (*entry)(void *image_handle, struct efi_system_table *st)
> @@ -136,6 +137,20 @@ static unsigned long do_bootefi_exec(void *efi, void
> *fdt,
> const efi_guid_t fdt_guid = EFI_FDT_GUID;
> bootm_headers_t img = { 0 };
>
> + /*
> + * Special case for efi payload not loaded from disk, such as
> + * 'bootefi hello' or for example payload loaded directly into
> + * memory via jtag/etc:
> + */
> + if (!device_path && !image_path) {
> + printf("WARNING: using memory device/image path, this may
> confuse some payloads!\n");
> + /* actual addresses filled in after efi_load_pe() */
> + memdp = efi_dp_from_mem(0, 0, 0);
> + device_path = image_path = memdp;
> + } else {
> + assert(device_path && image_path);
> + }
> +
> /* Initialize and populate EFI object list */
> if (!efi_obj_list_initalized)
> efi_init_obj_list();
> @@ -182,6 +197,14 @@ static unsigned long do_bootefi_exec(void *efi, void
> *fdt,
> goto exit;
> }
>
> + if (memdp) {
> + struct efi_device_path_memory *mdp = (void *)memdp;
> + mdp->memory_type = loaded_image_info.image_code_type;
> + mdp->start_address = (uintptr_t)loaded_image_info.image_base;
> + mdp->end_address = mdp->start_address +
> + loaded_image_info.image_size;
> + }
> +
memdp gets leaked after bootefi is done. Putting it on the stack would
at least remove that problem ;). We currently expect to only return from
bootefi when a payload was successfully quit.
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mmc: sanitize includes for DM i2c
This patch fixes some warnings when building boards that do not define DM_I2C_COMPAT i.e. boards that entirely rely on the new i2c layer. Signed-off-by: Felix Brack --- drivers/mmc/omap_hsmmc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c index efa4389..30443d1 100644 --- a/drivers/mmc/omap_hsmmc.c +++ b/drivers/mmc/omap_hsmmc.c @@ -28,9 +28,9 @@ #include #include #include -#include -#include +#if defined(CONFIG_OMAP54XX) || defined(CONFIG_OMAP44XX) #include +#endif #include #include #if !defined(CONFIG_SOC_KEYSTONE) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/14] arm: socfpga: stratix10: Add mailbox support for Stratix10 SoC
On Wed, Oct 11, 2017 at 4:33 AM, Dinh Nguyen wrote:
>
>
> On 10/05/2017 08:07 AM, chin.liang@intel.com wrote:
>> From: Chin Liang See
>>
>> Add mailbox support for Stratix SoC
>>
>> Signed-off-by: Ley Foon Tan
>> Signed-off-by: Chin Liang See
>> ---
>> arch/arm/mach-socfpga/Makefile | 1 +
>> arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 108 ++
>> arch/arm/mach-socfpga/mailbox_s10.c | 238
>> +++
>> 3 files changed, 347 insertions(+)
>> create mode 100644 arch/arm/mach-socfpga/include/mach/mailbox_s10.h
>> create mode 100644 arch/arm/mach-socfpga/mailbox_s10.c
>>
>> diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
>> index b253914..43e18d2 100644
>> --- a/arch/arm/mach-socfpga/Makefile
>> +++ b/arch/arm/mach-socfpga/Makefile
>> @@ -32,6 +32,7 @@ endif
>>
>> ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
>> obj-y+= clock_manager_s10.o
>> +obj-y+= mailbox_s10.o
>> obj-y+= misc_s10.o
>> obj-y+= reset_manager_s10.o
>> obj-y+= system_manager_s10.o
>> diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
>> b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
>> new file mode 100644
>> index 000..b9bddf6
>> --- /dev/null
>> +++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
>> @@ -0,0 +1,108 @@
>> +/*
>> + * Copyright (C) 2017 Intel Corporation
>> + *
>> + * SPDX-License-Identifier: GPL-2.0
>> + */
>> +#ifndef _MAILBOX_S10_H_
>> +#define _MAILBOX_S10_H_
>> +
>> +/* user define Uboot ID */
>> +#define MBOX_CLIENT_ID_UBOOT 0xB
>> +#define MBOX_ID_UBOOT0x1
>> +
>> +#define MBOX_MAX_CMD_INDEX 2047
>> +#define MBOX_CMD_BUFFER_SIZE 32
>> +#define MBOX_RESP_BUFFER_SIZE16
>> +
>> +#define MBOX_HDR_CMD_LSB 0
>> +#define MBOX_HDR_CMD_MSK (BIT(11) - 1)
>> +#define MBOX_HDR_I_LSB 11
>> +#define MBOX_HDR_I_MSK BIT(11)
>> +#define MBOX_HDR_LEN_LSB 12
>> +#define MBOX_HDR_LEN_MSK 0x007FF000
>> +#define MBOX_HDR_ID_LSB 24
>> +#define MBOX_HDR_ID_MSK 0x0F00
>> +#define MBOX_HDR_CLIENT_LSB 28
>> +#define MBOX_HDR_CLIENT_MSK 0xF000
>> +
>> +/* Interrupt flags */
>> +#define MBOX_FLAGS_INT_COE BIT(0) /* COUT update interrupt enable */
>> +#define MBOX_FLAGS_INT_RIE BIT(1) /* RIN update interrupt enable */
>> +#define MBOX_FLAGS_INT_UAE BIT(8) /* Urgent ACK interrupt enable */
>> +#define MBOX_ALL_INTRS (MBOX_FLAGS_INT_COE | \
>> + MBOX_FLAGS_INT_RIE | \
>> + MBOX_FLAGS_INT_UAE)
>> +
>> +/* Status */
>> +#define MBOX_STATUS_UA_MSK BIT(8)
>> +
>> +#define MBOX_CMD_HEADER(client, id, len, cmd) \
>> + (((cmd) << MBOX_HDR_CMD_LSB) & MBOX_HDR_CMD_MSK) | \
>> + (((len) << MBOX_HDR_LEN_LSB) & MBOX_HDR_LEN_MSK) | \
>> + (((id) << MBOX_HDR_ID_LSB) & MBOX_HDR_ID_MSK)| \
>> + (((client) << MBOX_HDR_CLIENT_LSB) & MBOX_HDR_CLIENT_MSK)
>> +
>> +#define MBOX_RESP_ERR_GET(resp) \
>> + (((resp) & MBOX_HDR_CMD_MSK) >> MBOX_HDR_CMD_LSB)
>> +#define MBOX_RESP_LEN_GET(resp) \
>> + (((resp) & MBOX_HDR_LEN_MSK) >> MBOX_HDR_LEN_LSB)
>> +#define MBOX_RESP_ID_GET(resp) \
>> + (((resp) & MBOX_HDR_ID_MSK) >> MBOX_HDR_ID_LSB)
>> +#define MBOX_RESP_CLIENT_GET(resp) \
>> + (((resp) & MBOX_HDR_CLIENT_MSK) >> MBOX_HDR_CLIENT_LSB)
>> +
>> +/* Response error list */
>> +typedef enum {
>> + /* CMD completed succesfully, but check resp ARGS for any errors */
>> + MBOX_RESP_STATOK = 0,
>> + /* CMD is incorrectly formatted in some way */
>> + MBOX_RESP_INVALID_COMMAND = 1,
>> + /* BootROM Command code not undesrtood */
>> + MBOX_RESP_UNKNOWN_BR = 2,
>> + /* CMD code not recognized by firmware */
>> + MBOX_RESP_UNKNOWN = 3,
>> + /* Indicates that the device is not configured */
>> + MBOX_RESP_NOT_CONFIGURED = 256,
>> + /* Indicates that the device is busy */
>> + MBOX_RESP_DEVICE_BUSY = 0x1FF,
>> + /* Indicates that there is no valid response available */
>> + MBOX_RESP_NO_VALID_RESP_AVAILABLE = 0x2FF,
>> + /* General Error */
>> + MBOX_RESP_ERROR = 0x3FF,
>> +} ALT_SDM_MBOX_RESP_CODE;
>> +
>> +/* Mailbox command list */
>> +#define MBOX_RESTART 2
>> +#define MBOX_QSPI_OPEN 50
>> +#define MBOX_QSPI_CLOSE 51
>> +#define MBOX_QSPI_DIRECT 59
>> +
>> +struct socfpga_mailbox {
>> + u32 cin;/* command valid offset */
>> + u32 rout; /* response output offset */
>> + u32 urg;/* urgent command */
>> + u32 flags; /* interrupt enables */
>> + u32 pad_0x10_0x1f[4]; /* 0x10 - 0x1F reserved */
>> + u32 cout; /* command free offset */
>> + u32 rin;/* respond valid offset */
>>
Re: [U-Boot] [PATCH] mx7dsabresd: Remove CONFIG_DM_MMC to avoid regression
On Wed, Oct 11, 2017 at 11:27 AM, Otavio Salvador wrote: > I understand your goal but I think we ought to focus on fixing the > root cause of it instead of moving things back out of DM. I even think > we could postpone a little the release until a fix is made but revert > out from DM seems wrong. Sure, patches are welcome! However if the fix does not come in soon, I would really like to apply this one so that U-Boot mainline can be used again on this board. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] fsl_esdhc driver is broken with DM
Hi Jagan, On Wed, Oct 11, 2017 at 7:17 AM, Jagan Teki wrote: > Still looping for i.MX6UL. Can you test it again removing CONFIG_DM_MMC support? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] fsl_esdhc driver is broken with DM
Hi Fabio, On Wed, Oct 11, 2017 at 9:19 PM, Fabio Estevam wrote: > Hi Jagan, > > On Wed, Oct 11, 2017 at 7:17 AM, Jagan Teki wrote: > >> Still looping for i.MX6UL. > > Can you test it again removing CONFIG_DM_MMC support? I've observed here, u-boot is unable to relocate. So when I build U-Boot with removing u-boot,dm-spl from dts it works fine, but idea here I need to use SPL_OF_CONTROL and it is not related to DM_MMC I suppose. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] fsl_esdhc driver is broken with DM
On Wed, Oct 11, 2017 at 1:06 PM, Jagan Teki wrote: > I've observed here, u-boot is unable to relocate. So when I build > U-Boot with removing u-boot,dm-spl from dts it works fine, but idea > here I need to use SPL_OF_CONTROL and it is not related to DM_MMC I > suppose. Ok, a different bug then. I was wondering if we could have some automated boot tests in U-Boot mainline? Something like https://kernelci.org/ for U-Boot? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] fsl_esdhc driver is broken with DM
+ Stefano On Wed, Oct 11, 2017 at 9:39 PM, Fabio Estevam wrote: > On Wed, Oct 11, 2017 at 1:06 PM, Jagan Teki wrote: > >> I've observed here, u-boot is unable to relocate. So when I build >> U-Boot with removing u-boot,dm-spl from dts it works fine, but idea >> here I need to use SPL_OF_CONTROL and it is not related to DM_MMC I >> suppose. > > Ok, a different bug then. Yes, this is one of the reason I always insists new boards to use full proper U-Boot rather than just supporting their respective hardware on Mainline. > > I was wondering if we could have some automated boot tests in U-Boot mainline? > > Something like https://kernelci.org/ for U-Boot? Yes, it's time otherwise all goes odd. Better to start a new thread discuss how we can move this. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] am33xx: Add a function to query MPU voltage in uV
For the DM TPS65910 driver I'm working on, querying the MPU voltage
should return a value in uV. This value can then be used by the
regulator's standard function set_value to set the MPU voltage.
Signed-off-by: Felix Brack
---
arch/arm/include/asm/arch-am33xx/sys_proto.h | 1 +
arch/arm/mach-omap2/am33xx/sys_info.c| 16
2 files changed, 17 insertions(+)
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 4e78aaf..57fbfa4 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -40,6 +40,7 @@ void enable_norboot_pin_mux(void);
#endif
void am33xx_spl_board_init(void);
int am335x_get_efuse_mpu_max_freq(struct ctrl_dev *cdev);
+int am335x_get_mpu_vdd(int sil_rev, int frequency);
int am335x_get_tps65910_mpu_vdd(int sil_rev, int frequency);
#endif
diff --git a/arch/arm/mach-omap2/am33xx/sys_info.c
b/arch/arm/mach-omap2/am33xx/sys_info.c
index ea434aa..0181a8c 100644
--- a/arch/arm/mach-omap2/am33xx/sys_info.c
+++ b/arch/arm/mach-omap2/am33xx/sys_info.c
@@ -175,6 +175,22 @@ int am335x_get_efuse_mpu_max_freq(struct ctrl_dev *cdev)
return MPUPLL_M_720;
}
+int am335x_get_mpu_vdd(int sil_rev, int frequency)
+{
+ int sel_mask = am335x_get_tps65910_mpu_vdd(sil_rev, frequency);
+
+ switch (sel_mask) {
+ case TPS65910_OP_REG_SEL_1_3_2_5:
+ return 1325000;
+ case TPS65910_OP_REG_SEL_1_2_0:
+ return 120;
+ case TPS65910_OP_REG_SEL_1_1_0:
+ return 110;
+ default:
+ return 1262500;
+ }
+}
+
int am335x_get_tps65910_mpu_vdd(int sil_rev, int frequency)
{
/* For PG2.0 and later, we have one set of values. */
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] fsl_esdhc driver is broken with DM
On Wed, Oct 11, 2017 at 01:09:04PM -0300, Fabio Estevam wrote: > On Wed, Oct 11, 2017 at 1:06 PM, Jagan Teki wrote: > > > I've observed here, u-boot is unable to relocate. So when I build > > U-Boot with removing u-boot,dm-spl from dts it works fine, but idea > > here I need to use SPL_OF_CONTROL and it is not related to DM_MMC I > > suppose. > > Ok, a different bug then. > > I was wondering if we could have some automated boot tests in U-Boot mainline? > > Something like https://kernelci.org/ for U-Boot? The problem(s) there are related to lack of hardware support for testing firmware in a CI type environment. For example, I do test/py/test.py on real hardware before every push cycle. The problem for iMX in this case at least is that I haven't seen (nor had a chance to come up with) the scripting to update u-boot from within u-boot, to catch the kind of failures that we don't see when doing the USB recovery boot method. I can test sabrelite via u-boot.imx (and in theory I could test my hummingboard with SPL, but my quick pass at enabling USB gadget support there didn't seem to work). I would very much welcome more labs running tests however. There's already a few, but I guess the gap we see right here and now is that there's none for iMX. -- 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] cmd/pxe.c: Rework bootargs construction to clarify string checks
As the code currently stands, we first check that the length of the
given command line, along with ip_str/mac_str along with an additional 1
for the NULL termination will fit within the buffer we have, and if not,
we return an error. The way this code was originally written however
left Coverity "unhappy" due to using strcat rather than strncat.
Switching this to strncat however causes clang to be unhappy that we
aren't enforcing the "1" portion within strncat. Rather than further
re-work the code to include a "- 1" in this case as well, make the
strcat code only be done within the else side of the length test. This
keeps both clang and Coverity happy.
Fixes: 48ee0a87bc46 ("cmd/pxe.c: Rework initrd and bootargs handling slightly")
Signed-off-by: Tom Rini
---
cmd/pxe.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/cmd/pxe.c b/cmd/pxe.c
index a62cbe192a32..7043ad11fdd8 100644
--- a/cmd/pxe.c
+++ b/cmd/pxe.c
@@ -686,16 +686,17 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label
*label)
strlen(ip_str), strlen(mac_str),
sizeof(bootargs));
return 1;
+ } else {
+ if (label->append)
+ strncpy(bootargs, label->append,
+ sizeof(bootargs));
+ strcat(bootargs, ip_str);
+ strcat(bootargs, mac_str);
+
+ cli_simple_process_macros(bootargs, finalbootargs);
+ env_set("bootargs", finalbootargs);
+ printf("append: %s\n", finalbootargs);
}
-
- if (label->append)
- strncpy(bootargs, label->append, sizeof(bootargs));
- strncat(bootargs, ip_str, sizeof(bootargs) - strlen(bootargs));
- strncat(bootargs, mac_str, sizeof(bootargs) - strlen(bootargs));
-
- cli_simple_process_macros(bootargs, finalbootargs);
- env_set("bootargs", finalbootargs);
- printf("append: %s\n", finalbootargs);
}
bootm_argv[1] = env_get("kernel_addr_r");
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] efi_loader: Initial EFI_UNICODE_COLLATION_PROTOCOL
On Wed, Oct 11, 2017 at 10:36 AM, Alexander Graf wrote:
>
>
> On 10.10.17 14:22, Rob Clark wrote:
>> From: Leif Lindholm
>>
>> Not complete, but enough for Shell.efi and SCT.efi.
>>
>> Initial skeleton written by Leif, and then implementation by myself.
>>
>> Cc: Leif Lindholm
>> Signed-off-by: Rob Clark
>> ---
>> include/efi_api.h | 41 ++
>> include/efi_loader.h | 3 +
>> lib/efi_loader/Makefile | 2 +-
>> lib/efi_loader/efi_boottime.c | 6 ++
>> lib/efi_loader/efi_unicode.c | 170
>> ++
>> 5 files changed, 221 insertions(+), 1 deletion(-)
>> create mode 100644 lib/efi_loader/efi_unicode.c
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index 164147dc87..38dd1240c1 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -797,6 +797,47 @@ struct efi_hii_string_protocol {
>> efi_uintn_t *secondary_languages_size);
>> };
>>
>> +/*
>> + * Both UNICODE_COLLATION protocols seem to be the same thing, but
>> + * advertised with two different GUID's because, why not?
>> + */
>> +
>> +#define EFI_UNICODE_COLLATION_PROTOCOL_GUID \
>> + EFI_GUID(0x1d85cd7f, 0xf43d, 0x11d2, \
>> + 0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
>> +
>> +#define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \
>> + EFI_GUID(0xa4c751fc, 0x23ae, 0x4c3e, \
>> + 0x92, 0xe9, 0x49, 0x64, 0xcf, 0x63, 0xf3, 0x49)
>> +
>> +struct efi_unicode_collation_protocol {
>> + efi_intn_t (EFIAPI *stri_coll)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t s1,
>> + efi_string_t s2);
>> + bool (EFIAPI *metai_match)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string,
>> + efi_string_t pattern);
>> + void (EFIAPI *str_lwr)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string);
>> + void (EFIAPI *str_upr)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string);
>> + void (EFIAPI *fat_to_str)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_uintn_t fat_size,
>> + uint8_t *fat,
>> + efi_string_t string);
>> + bool (EFIAPI *str_to_fat)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string,
>> + efi_uintn_t fat_size,
>> + uint8_t *fat);
>> + uint8_t *supported_languages;
>> +};
>> +
>> #define EFI_GOP_GUID \
>> EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
>>0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index 591bf07e7a..af6812b2b4 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -83,6 +83,7 @@ extern const struct efi_device_path_utilities_protocol
>> efi_device_path_utilities
>> extern const struct efi_hii_config_routing_protocol efi_hii_config_routing;
>> extern const struct efi_hii_database_protocol efi_hii_database;
>> extern const struct efi_hii_string_protocol efi_hii_string;
>> +extern const struct efi_unicode_collation_protocol efi_unicode_collation;
>>
>> uint16_t *efi_dp_str(struct efi_device_path *dp);
>>
>> @@ -97,6 +98,8 @@ extern const efi_guid_t
>> efi_guid_device_path_utilities_protocol;
>> extern const efi_guid_t efi_guid_hii_config_routing_protocol;
>> extern const efi_guid_t efi_guid_hii_database_protocol;
>> extern const efi_guid_t efi_guid_hii_string_protocol;
>> +extern const efi_guid_t efi_guid_unicode_collation_protocol;
>> +extern const efi_guid_t efi_guid_unicode_collation_protocol2;
>>
>> extern unsigned int __efi_runtime_start, __efi_runtime_stop;
>> extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>> index 725e0cba85..7ea96a4f1c 100644
>> --- a/lib/efi_loader/Makefile
>> +++ b/lib/efi_loader/Makefile
>> @@ -17,7 +17,7 @@ endif
>> obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>> obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>> obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
>> -obj-y += efi_device_path_utilities.o efi_hii.o
>> +obj-y += efi_device_path_utilities.o efi_hii.o efi_unicode.o
>> obj-y += efi_file.o efi_variable.o efi_bootmgr.o
>> obj-$(CONFIG_LCD) += efi_gop.o
>> obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index c179afc25a..b568f3f162 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -1166,6 +1166,12 @@ void efi_setup_loaded_image(struct efi_loaded_image
>> *info, struct efi_object *ob
>> obj->protocols[7].guid = &efi_guid_hii_config_routing_protocol;
>> obj->protocols[7].protocol_interface = (void *)&efi_hii_config_routing;
>>
>> + o
[U-Boot] [PATCH] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model
Change-Id: I1bdfffe782a61a4c688f1bb56e85448024cd497b Signed-off-by: Eric Nelson --- configs/mx7dsabresd_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig index 795c4f2..144fb50 100644 --- a/configs/mx7dsabresd_defconfig +++ b/configs/mx7dsabresd_defconfig @@ -38,7 +38,6 @@ CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_OF_CONTROL=y -# CONFIG_BLK is not set CONFIG_DFU_MMC=y CONFIG_DFU_RAM=y CONFIG_DM_GPIO=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/11] efi_loader: Initial EFI_DEVICE_PATH_UTILITIES_PROTOCOL
On Wed, Oct 11, 2017 at 10:07 AM, Alexander Graf wrote:
>
>
> On 10.10.17 14:22, Rob Clark wrote:
>> From: Leif Lindholm
>>
>> Not complete, but enough for Shell.efi and SCT.efi. We'll implement the
>> rest as needed or once we have SCT running properly so there is a way to
>> validate the interface against the conformance test suite.
>>
>> Initial skeleton written by Leif, and then implementation by myself.
>>
>> Cc: Leif Lindholm
>> Signed-off-by: Rob Clark
>> ---
>> include/efi_api.h | 34 +++-
>> include/efi_loader.h | 2 +
>> lib/efi_loader/Makefile| 1 +
>> lib/efi_loader/efi_boottime.c | 4 ++
>> lib/efi_loader/efi_device_path_utilities.c | 88
>> ++
>> 5 files changed, 127 insertions(+), 2 deletions(-)
>> create mode 100644 lib/efi_loader/efi_device_path_utilities.c
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index a9a6494afe..ffdba7fe1a 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -28,8 +28,9 @@ enum efi_timer_delay {
>> EFI_TIMER_RELATIVE = 2
>> };
>>
>> -#define UINTN size_t
>> -typedef long INTN;
>> +#define UINTN size_t /* TODO this should be removed in a future patch */
>
> $ git grep UINTN | wc -l
> 13
>
> Just send a preceding patch that introduces efi_uintn_t and replaces all
> occurences of UINTN with it.
>
> The uintn bits shouldn't be part of the
> EFI_DEVICE_PATH_UTILITIES_PROTOCOL patch anyways :).
>
Heinrich mentioned he was doing that, so I didn't want to step on
feet. I figured this was the easiest approach regardless of the order
of merging patches (should be simple enough to drop the duplicate
efi_uintn_t)
BR,
-R
>> +typedef size_t efi_uintn_t;
>> +typedef ssize_t efi_intn_t;
>> typedef uint16_t *efi_string_t;
>
>
> Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model
On Thu, Oct 12, 2017 at 1:59 AM, Eric Nelson wrote: > Change-Id: I1bdfffe782a61a4c688f1bb56e85448024cd497b > Signed-off-by: Eric Nelson Reviewed-by: Jagan Teki -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/14] ddr: altera: stratix10: Add DDR support for Stratix10 SoC
On Thu, Oct 5, 2017 at 8:07 AM, wrote:
> From: Chin Liang See
>
> Add DDR support for Stratix SoC
>
> Signed-off-by: Chin Liang See
> ---
> arch/arm/mach-socfpga/include/mach/sdram_s10.h | 333 +
> drivers/ddr/altera/Makefile| 1 +
> drivers/ddr/altera/sdram_s10.c | 382
> +
> 3 files changed, 716 insertions(+)
> create mode 100644 arch/arm/mach-socfpga/include/mach/sdram_s10.h
> create mode 100644 drivers/ddr/altera/sdram_s10.c
>
> diff --git a/arch/arm/mach-socfpga/include/mach/sdram_s10.h
> b/arch/arm/mach-socfpga/include/mach/sdram_s10.h
> new file mode 100644
> index 000..d0fd958
[...]
> diff --git a/drivers/ddr/altera/Makefile b/drivers/ddr/altera/Makefile
> index bdd2872..943b6cd 100644
> --- a/drivers/ddr/altera/Makefile
> +++ b/drivers/ddr/altera/Makefile
> @@ -10,4 +10,5 @@
>
> ifdef CONFIG_ALTERA_SDRAM
> obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += sdram.o sequencer.o
> +obj-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += sdram_s10.o
> endif
> diff --git a/drivers/ddr/altera/sdram_s10.c b/drivers/ddr/altera/sdram_s10.c
> new file mode 100644
> index 000..c488caf
> --- /dev/null
> +++ b/drivers/ddr/altera/sdram_s10.c
> @@ -0,0 +1,382 @@
> +/*
> + * Copyright (C) 2016-2017 Intel Corporation
> + *
> + * SPDX-License-Identifier:GPL-2.0
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static const struct socfpga_ecc_hmc *socfpga_ecc_hmc_base =
> + (void *)SOCFPGA_SDR_ADDRESS;
> +static const struct socfpga_noc_ddr_scheduler
> *socfpga_noc_ddr_scheduler_base =
> + (void *)SOCFPGA_SDR_SCHEDULER_ADDRESS;
> +static const struct socfpga_io48_mmr *socfpga_io48_mmr_base =
> + (void *)SOCFPGA_HMC_MMR_IO48_ADDRESS;
> +static const struct socfpga_system_manager *sysmgr_regs =
> + (void *)SOCFPGA_SYSMGR_ADDRESS;
> +
> +#define DDR_CONFIG(A, B, C, R) ((A<<24)|(B<<16)|(C<<8)|R)
> +
> +/* The followring are the supported configurations */
> +u32 ddr_config[] = {
> + /* DDR_CONFIG(Address order,Bank,Column,Row) */
> + /* List for DDR3 or LPDDR3 (pinout order > chip, row, bank, column) */
> + DDR_CONFIG(0, 3, 10, 12),
> + DDR_CONFIG(0, 3, 9, 13),
> + DDR_CONFIG(0, 3, 10, 13),
> + DDR_CONFIG(0, 3, 9, 14),
> + DDR_CONFIG(0, 3, 10, 14),
> + DDR_CONFIG(0, 3, 10, 15),
> + DDR_CONFIG(0, 3, 11, 14),
> + DDR_CONFIG(0, 3, 11, 15),
> + DDR_CONFIG(0, 3, 10, 16),
> + DDR_CONFIG(0, 3, 11, 16),
> + DDR_CONFIG(0, 3, 12, 15), /* 0xa */
> + /* List for DDR4 only (pinout order > chip, bank, row, column) */
> + DDR_CONFIG(1, 3, 10, 14),
> + DDR_CONFIG(1, 4, 10, 14),
> + DDR_CONFIG(1, 3, 10, 15),
> + DDR_CONFIG(1, 4, 10, 15),
> + DDR_CONFIG(1, 3, 10, 16),
> + DDR_CONFIG(1, 4, 10, 16),
> + DDR_CONFIG(1, 3, 10, 17),
> + DDR_CONFIG(1, 4, 10, 17),
> +};
> +
> +#define DDR_CONFIG_ELEMENTS(sizeof(ddr_config)/sizeof(u32))
> +
> +int match_ddr_conf(u32 ddr_conf)
Should be static.
> +{
> + int i;
> + for (i = 0; i < DDR_CONFIG_ELEMENTS; i++) {
> + if (ddr_conf == ddr_config[i])
> + return i;
> + }
> + return 0;
> +}
> +
> +static int emif_clear(void)
> +{
> + u32 s2c, i;
> +
> + writel(0, &socfpga_ecc_hmc_base->rsthandshakectrl);
> + s2c = readl(&socfpga_ecc_hmc_base->rsthandshakestat) &
> + DDR_HMC_RSTHANDSHAKE_MASK;
> +
> + for (i = 1000; (i > 0) && s2c; i--) {
> + WATCHDOG_RESET();
> + mdelay(1);
> + s2c = readl(&socfpga_ecc_hmc_base->rsthandshakestat) &
> + DDR_HMC_RSTHANDSHAKE_MASK;
> + }
> + return !s2c;
> +}
> +
> +static int emif_reset(void)
What's the return used for? I don't see the callers of emif_reset checking
the return values at all.
> +{
> + u32 c2s, s2c, i;
> +
> + c2s = readl(&socfpga_ecc_hmc_base->rsthandshakectrl) &
> + DDR_HMC_RSTHANDSHAKE_MASK;
> + s2c = readl(&socfpga_ecc_hmc_base->rsthandshakestat) &
> + DDR_HMC_RSTHANDSHAKE_MASK;
> +
> + debug("DDR: c2s=%08x s2c=%08x nr0=%08x nr1=%08x nr2=%08x dst=%08x\n",
> + c2s, s2c, readl(&socfpga_io48_mmr_base->niosreserve0),
> + readl(&socfpga_io48_mmr_base->niosreserve1),
> + readl(&socfpga_io48_mmr_base->niosreserve2),
> + readl(&socfpga_io48_mmr_base->dramsts));
> +
> + if (s2c && emif_clear()) {
> + printf("DDR: emif_clear() failed\n");
> + return -1;
> + }
> +
> + puts("DDR: Triggerring emif_reset\n");
> + writel(DDR_HMC_CORE2SEQ_INT_REQ,
> + &socfpga_ecc_hmc_base->rsthandshakectrl);
> +
> + for (i = 1000; i > 0; i--) {
> + /* if seq2core
Re: [U-Boot] [PATCH 03/11] efi_loader: Initial EFI_UNICODE_COLLATION_PROTOCOL
On 11.10.17 22:30, Rob Clark wrote:
> On Wed, Oct 11, 2017 at 10:36 AM, Alexander Graf wrote:
>>
>>
>> On 10.10.17 14:22, Rob Clark wrote:
>>> From: Leif Lindholm
>>>
>>> Not complete, but enough for Shell.efi and SCT.efi.
>>>
>>> Initial skeleton written by Leif, and then implementation by myself.
>>>
>>> Cc: Leif Lindholm
>>> Signed-off-by: Rob Clark
>>> ---
>>> include/efi_api.h | 41 ++
>>> include/efi_loader.h | 3 +
>>> lib/efi_loader/Makefile | 2 +-
>>> lib/efi_loader/efi_boottime.c | 6 ++
>>> lib/efi_loader/efi_unicode.c | 170
>>> ++
>>> 5 files changed, 221 insertions(+), 1 deletion(-)
>>> create mode 100644 lib/efi_loader/efi_unicode.c
>>>
>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>> index 164147dc87..38dd1240c1 100644
>>> --- a/include/efi_api.h
>>> +++ b/include/efi_api.h
>>> @@ -797,6 +797,47 @@ struct efi_hii_string_protocol {
>>> efi_uintn_t *secondary_languages_size);
>>> };
>>>
>>> +/*
>>> + * Both UNICODE_COLLATION protocols seem to be the same thing, but
>>> + * advertised with two different GUID's because, why not?
>>> + */
>>> +
>>> +#define EFI_UNICODE_COLLATION_PROTOCOL_GUID \
>>> + EFI_GUID(0x1d85cd7f, 0xf43d, 0x11d2, \
>>> + 0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
>>> +
>>> +#define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \
>>> + EFI_GUID(0xa4c751fc, 0x23ae, 0x4c3e, \
>>> + 0x92, 0xe9, 0x49, 0x64, 0xcf, 0x63, 0xf3, 0x49)
>>> +
>>> +struct efi_unicode_collation_protocol {
>>> + efi_intn_t (EFIAPI *stri_coll)(
>>> + struct efi_unicode_collation_protocol *this,
>>> + efi_string_t s1,
>>> + efi_string_t s2);
>>> + bool (EFIAPI *metai_match)(
>>> + struct efi_unicode_collation_protocol *this,
>>> + efi_string_t string,
>>> + efi_string_t pattern);
>>> + void (EFIAPI *str_lwr)(
>>> + struct efi_unicode_collation_protocol *this,
>>> + efi_string_t string);
>>> + void (EFIAPI *str_upr)(
>>> + struct efi_unicode_collation_protocol *this,
>>> + efi_string_t string);
>>> + void (EFIAPI *fat_to_str)(
>>> + struct efi_unicode_collation_protocol *this,
>>> + efi_uintn_t fat_size,
>>> + uint8_t *fat,
>>> + efi_string_t string);
>>> + bool (EFIAPI *str_to_fat)(
>>> + struct efi_unicode_collation_protocol *this,
>>> + efi_string_t string,
>>> + efi_uintn_t fat_size,
>>> + uint8_t *fat);
>>> + uint8_t *supported_languages;
>>> +};
>>> +
>>> #define EFI_GOP_GUID \
>>> EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
>>>0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
>>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>>> index 591bf07e7a..af6812b2b4 100644
>>> --- a/include/efi_loader.h
>>> +++ b/include/efi_loader.h
>>> @@ -83,6 +83,7 @@ extern const struct efi_device_path_utilities_protocol
>>> efi_device_path_utilities
>>> extern const struct efi_hii_config_routing_protocol efi_hii_config_routing;
>>> extern const struct efi_hii_database_protocol efi_hii_database;
>>> extern const struct efi_hii_string_protocol efi_hii_string;
>>> +extern const struct efi_unicode_collation_protocol efi_unicode_collation;
>>>
>>> uint16_t *efi_dp_str(struct efi_device_path *dp);
>>>
>>> @@ -97,6 +98,8 @@ extern const efi_guid_t
>>> efi_guid_device_path_utilities_protocol;
>>> extern const efi_guid_t efi_guid_hii_config_routing_protocol;
>>> extern const efi_guid_t efi_guid_hii_database_protocol;
>>> extern const efi_guid_t efi_guid_hii_string_protocol;
>>> +extern const efi_guid_t efi_guid_unicode_collation_protocol;
>>> +extern const efi_guid_t efi_guid_unicode_collation_protocol2;
>>>
>>> extern unsigned int __efi_runtime_start, __efi_runtime_stop;
>>> extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
>>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>>> index 725e0cba85..7ea96a4f1c 100644
>>> --- a/lib/efi_loader/Makefile
>>> +++ b/lib/efi_loader/Makefile
>>> @@ -17,7 +17,7 @@ endif
>>> obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>>> obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>>> obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
>>> -obj-y += efi_device_path_utilities.o efi_hii.o
>>> +obj-y += efi_device_path_utilities.o efi_hii.o efi_unicode.o
>>> obj-y += efi_file.o efi_variable.o efi_bootmgr.o
>>> obj-$(CONFIG_LCD) += efi_gop.o
>>> obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>>> index c179afc25a..b568f3f162 100644
>>> --- a/lib/efi_loader/efi_boottime.c
>>> +++ b/lib/efi_loader/efi_boottime.c
>>> @@ -1166,6 +1166,12 @@ void efi_setup_loaded_image(struct efi_loaded_image
>>> *info, struct efi_object *ob
>>> ob
Re: [U-Boot] [PATCH] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model
Hi Eric, That was the fix I was waiting for, thanks! On Wed, Oct 11, 2017 at 5:29 PM, Eric Nelson wrote: Please add a commit log and explain that this fixes a regression. > Change-Id: I1bdfffe782a61a4c688f1bb56e85448024cd497b Please remove this line. Also, when you send a v2, please do the same change in mx7dsabresd_secure_defconfig. > Signed-off-by: Eric Nelson Now I can boot a kernel successfully, thanks: Tested-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model
On Wed, Oct 11, 2017 at 05:50:04PM -0300, Fabio Estevam wrote: > Hi Eric, > > That was the fix I was waiting for, thanks! > > On Wed, Oct 11, 2017 at 5:29 PM, Eric Nelson wrote: > > Please add a commit log and explain that this fixes a regression. > > > Change-Id: I1bdfffe782a61a4c688f1bb56e85448024cd497b > > Please remove this line. > > Also, when you send a v2, please do the same change in > mx7dsabresd_secure_defconfig. > > > Signed-off-by: Eric Nelson > > Now I can boot a kernel successfully, thanks: > > Tested-by: Fabio Estevam Is there perhaps a dependency here we need to enforce via Kconfig so this isn't a game of whack-a-mole? Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/14] board: altera: stratix10: Add socdk board support for Stratix10 SoC
On Thu, Oct 5, 2017 at 8:07 AM, wrote: > From: Chin Liang See > > Add socdk board support for Stratix SoC > > Signed-off-by: Chin Liang See > --- > board/altera/stratix10-socdk/MAINTAINERS | 7 +++ > board/altera/stratix10-socdk/Makefile| 7 +++ > board/altera/stratix10-socdk/socfpga.c | 7 +++ > 3 files changed, 21 insertions(+) > create mode 100644 board/altera/stratix10-socdk/MAINTAINERS > create mode 100644 board/altera/stratix10-socdk/Makefile > create mode 100644 board/altera/stratix10-socdk/socfpga.c > > diff --git a/board/altera/stratix10-socdk/MAINTAINERS > b/board/altera/stratix10-socdk/MAINTAINERS > new file mode 100644 > index 000..6192bc9 > --- /dev/null > +++ b/board/altera/stratix10-socdk/MAINTAINERS > @@ -0,0 +1,7 @@ > +SOCFPGA BOARD > +M: Chin-Liang See > +M: Dinh Nguyen Use dingu...@kernel.org please. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model
Hi Fabio, On 10/11/2017 01:50 PM, Fabio Estevam wrote: Hi Eric, That was the fix I was waiting for, thanks! Glad to hear it. On Wed, Oct 11, 2017 at 5:29 PM, Eric Nelson wrote: Please add a commit log and explain that this fixes a regression. Okay. If you insist ;) Change-Id: I1bdfffe782a61a4c688f1bb56e85448024cd497b Please remove this line. Oops. I think we need to refresh checkpatch. I think the version in the kernel tree checks for that. Also, when you send a v2, please do the same change in mx7dsabresd_secure_defconfig. Okay. Signed-off-by: Eric Nelson Now I can boot a kernel successfully, thanks: Tested-by: Fabio Estevam Great. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/14] arm: socfpga: stratix10: Enable Stratix10 SoC build
On Thu, Oct 5, 2017 at 8:07 AM, wrote: > From: Chin Liang See > > Add build support for Stratix SoC > > Signed-off-by: Chin Liang See > --- > arch/arm/Kconfig | 8 +- > arch/arm/mach-socfpga/Kconfig | 13 ++ > configs/socfpga_stratix10_defconfig | 39 ++ > include/configs/socfpga_stratix10_socdk.h | 216 > ++ > 4 files changed, 273 insertions(+), 3 deletions(-) > create mode 100644 configs/socfpga_stratix10_defconfig > create mode 100644 include/configs/socfpga_stratix10_socdk.h > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index d6d9558..4a6b9da 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -656,21 +656,23 @@ config ARCH_SNAPDRAGON > > config ARCH_SOCFPGA > bool "Altera SOCFPGA family" > - select CPU_V7 > + select CPU_V7 if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 > + select ARM64 if TARGET_SOCFPGA_STRATIX10 > select SUPPORT_SPL > select OF_CONTROL > select SPL_OF_CONTROL > select DM > select DM_SPI_FLASH > select DM_SPI > - select ENABLE_ARM_SOC_BOOT0_HOOK > + select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 || > TARGET_SOCFPGA_ARRIA10 > select ARCH_EARLY_INIT_R > select ARCH_MISC_INIT > select SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION > - select SYS_THUMB_BUILD > + select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || > TARGET_SOCFPGA_ARRIA10 > imply CMD_MTDPARTS > imply CRC32_VERIFY > imply FAT_WRITE > + select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10 > > config ARCH_SUNXI > bool "Support sunxi (Allwinner) SoCs" > diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig > index 45e5379..03ab956 100644 > --- a/arch/arm/mach-socfpga/Kconfig > +++ b/arch/arm/mach-socfpga/Kconfig > @@ -49,6 +49,12 @@ config TARGET_SOCFPGA_GEN5 > bool > select ALTERA_SDRAM > > +config TARGET_SOCFPGA_STRATIX10 > + bool > + select ARMV8_MULTIENTRY > + select ARMV8_SPIN_TABLE > + select ARMV8_SET_SMPEN > + > choice > prompt "Altera SOCFPGA board select" > optional > @@ -86,6 +92,10 @@ config TARGET_SOCFPGA_SR1500 > bool "SR1500 (Cyclone V)" > select TARGET_SOCFPGA_CYCLONE5 > > +config TARGET_SOCFPGA_STRATIX10_SOCDK > + bool "Intel SOCFPGA SoCDK (Stratix 10)" > + select TARGET_SOCFPGA_STRATIX10 > + > config TARGET_SOCFPGA_TERASIC_DE0_NANO > bool "Terasic DE0-Nano-Atlas (Cyclone V)" > select TARGET_SOCFPGA_CYCLONE5 > @@ -116,12 +126,14 @@ config SYS_BOARD > default "sockit" if TARGET_SOCFPGA_TERASIC_SOCKIT > default "socrates" if TARGET_SOCFPGA_EBV_SOCRATES > default "sr1500" if TARGET_SOCFPGA_SR1500 > + default "stratix10-socdk" if TARGET_SOCFPGA_STRATIX10_SOCDK > default "vining_fpga" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA > > config SYS_VENDOR > default "altera" if TARGET_SOCFPGA_ARRIA5_SOCDK > default "altera" if TARGET_SOCFPGA_ARRIA10_SOCDK > default "altera" if TARGET_SOCFPGA_CYCLONE5_SOCDK > + default "altera" if TARGET_SOCFPGA_STRATIX10_SOCDK > default "aries" if TARGET_SOCFPGA_ARIES_MCVEVK > default "ebv" if TARGET_SOCFPGA_EBV_SOCRATES > default "samtec" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA > @@ -145,6 +157,7 @@ config SYS_CONFIG_NAME > default "socfpga_sockit" if TARGET_SOCFPGA_TERASIC_SOCKIT > default "socfpga_socrates" if TARGET_SOCFPGA_EBV_SOCRATES > default "socfpga_sr1500" if TARGET_SOCFPGA_SR1500 > + default "socfpga_stratix10_socdk" if TARGET_SOCFPGA_STRATIX10_SOCDK > default "socfpga_vining_fpga" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA > > endif > diff --git a/configs/socfpga_stratix10_defconfig > b/configs/socfpga_stratix10_defconfig > new file mode 100644 > index 000..e5a7a69 > --- /dev/null > +++ b/configs/socfpga_stratix10_defconfig > @@ -0,0 +1,39 @@ > +CONFIG_ARM=y > +CONFIG_ARCH_SOCFPGA=y > +CONFIG_SYS_MALLOC_F_LEN=0x2000 > +CONFIG_SPL_FAT_SUPPORT=y > +CONFIG_TARGET_SOCFPGA_STRATIX10_SOCDK=y > +CONFIG_IDENT_STRING="socfpga_stratix10" > +CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk" > +CONFIG_BOOTDELAY=5 > +CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # " > +CONFIG_CMD_CACHE=y > +CONFIG_CMD_DHCP=y > +CONFIG_CMD_EXT4=y > +CONFIG_CMD_FAT=y > +# CONFIG_CMD_FLASH is not set > +CONFIG_CMD_FS_GENERIC=y > +# CONFIG_CMD_IMLS is not set > +CONFIG_CMD_MEMTEST=y > +CONFIG_CMD_MII=y > +CONFIG_CMD_MMC=y > +CONFIG_CMD_PING=y > +CONFIG_CMD_SF=y > +CONFIG_SPL=y > +CONFIG_SPL_DM=y > +CONFIG_SPL_DM_SEQ_ALIAS=y > +CONFIG_DM_MMC=y > +CONFIG_ENV_IS_IN_MMC=y > +CONFIG_DFU_MMC=y > +CONFIG_MMC_DW=y > +CONFIG_SPI_FLASH=y > +CONFIG_SPI_FLASH_BAR=y > +CONFIG_SPI_FLASH_SPANSION=y > +CONFIG_SPI_FLASH_STMICRO=y > +# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set > +CONFIG_CADENCE_QSPI=y > +CONFIG_DM_ETH=y > +CONF
Re: [U-Boot] [PATCH] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model
Hi Tom, On 10/11/2017 01:51 PM, Tom Rini wrote: On Wed, Oct 11, 2017 at 05:50:04PM -0300, Fabio Estevam wrote: Hi Eric, That was the fix I was waiting for, thanks! On Wed, Oct 11, 2017 at 5:29 PM, Eric Nelson wrote: Please add a commit log and explain that this fixes a regression. Change-Id: I1bdfffe782a61a4c688f1bb56e85448024cd497b Please remove this line. Also, when you send a v2, please do the same change in mx7dsabresd_secure_defconfig. Signed-off-by: Eric Nelson Now I can boot a kernel successfully, thanks: Tested-by: Fabio Estevam Is there perhaps a dependency here we need to enforce via Kconfig so this isn't a game of whack-a-mole? Thanks! We have a "default Y if DM" for it, which should be enough. http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/Kconfig;h=26760895f99dd53370f9077f5b7213a1a6f241fe;hb=HEAD#l3 Commit 6fbbcfd explicitly disabled it when converting to DM_MMC (secure_defconfig followed suit in commit 8ae5bb3), and that's where the trouble came in. Hmmm. A quick search shows that quite a few configurations have this choice (CONFIG_DM_MMC without CONFIG_BLK): ~u-boot/configs$ git grep -l CONFIG_DM_MMC=y | xargs grep BLK am335x_boneblack_vboot_defconfig:# CONFIG_BLK is not set am335x_evm_defconfig:# CONFIG_BLK is not set am335x_hs_evm_defconfig:# CONFIG_BLK is not set am43xx_evm_defconfig:# CONFIG_BLK is not set am43xx_evm_usbhost_boot_defconfig:# CONFIG_BLK is not set am43xx_hs_evm_defconfig:# CONFIG_BLK is not set am57xx_evm_defconfig:# CONFIG_BLK is not set am57xx_hs_evm_defconfig:# CONFIG_BLK is not set k2g_evm_defconfig:# CONFIG_BLK is not set k2g_hs_evm_defconfig:# CONFIG_BLK is not set ls1012aqds_qspi_defconfig:# CONFIG_BLK is not set ls1012ardb_qspi_defconfig:# CONFIG_BLK is not set mx6slevk_defconfig:# CONFIG_BLK is not set mx6slevk_spinor_defconfig:# CONFIG_BLK is not set mx6sllevk_defconfig:# CONFIG_BLK is not set mx6sllevk_plugin_defconfig:# CONFIG_BLK is not set mx6sxsabreauto_defconfig:# CONFIG_BLK is not set mx6ull_14x14_evk_defconfig:# CONFIG_BLK is not set mx6ull_14x14_evk_plugin_defconfig:# CONFIG_BLK is not set mx7ulp_evk_defconfig:# CONFIG_BLK is not set mx7ulp_evk_plugin_defconfig:# CONFIG_BLK is not set omap3_logic_defconfig:# CONFIG_BLK is not set pic32mzdask_defconfig:# CONFIG_BLK is not set Are all of these broken? I don't have any of the other boards, and am not in a position to say whether there's a legitimate use case for DM_MMC without BLK. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model
Commit 6fbbcfd introduced device-tree support for MMC devices on the mx7sabresd boards and didn't include BLK, which requires BLK. Commit 8ae5bb3 did the same for secure boot. Fix both by allowing blk-uclass (BLK) support. Tested-by: Fabio Estevam Signed-off-by: Eric Nelson --- V2 includes the updated to mx7dsabresd_secure_defconfig configs/mx7dsabresd_defconfig| 1 - configs/mx7dsabresd_secure_defconfig | 1 - 2 files changed, 2 deletions(-) diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig index 795c4f2..144fb50 100644 --- a/configs/mx7dsabresd_defconfig +++ b/configs/mx7dsabresd_defconfig @@ -38,7 +38,6 @@ CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_OF_CONTROL=y -# CONFIG_BLK is not set CONFIG_DFU_MMC=y CONFIG_DFU_RAM=y CONFIG_DM_GPIO=y diff --git a/configs/mx7dsabresd_secure_defconfig b/configs/mx7dsabresd_secure_defconfig index bd68831..d1af138 100644 --- a/configs/mx7dsabresd_secure_defconfig +++ b/configs/mx7dsabresd_secure_defconfig @@ -40,7 +40,6 @@ CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_OF_CONTROL=y -# CONFIG_BLK is not set CONFIG_DFU_MMC=y CONFIG_DFU_RAM=y CONFIG_DM_GPIO=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model
On Wed, Oct 11, 2017 at 02:45:25PM -0700, Eric Nelson wrote: > Commit 6fbbcfd introduced device-tree support for MMC devices on > the mx7sabresd boards and didn't include BLK, which requires BLK. > > Commit 8ae5bb3 did the same for secure boot. > > Fix both by allowing blk-uclass (BLK) support. > > Tested-by: Fabio Estevam > Signed-off-by: Eric Nelson > --- > V2 includes the updated to mx7dsabresd_secure_defconfig > configs/mx7dsabresd_defconfig| 1 - > configs/mx7dsabresd_secure_defconfig | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig > index 795c4f2..144fb50 100644 > --- a/configs/mx7dsabresd_defconfig > +++ b/configs/mx7dsabresd_defconfig > @@ -38,7 +38,6 @@ CONFIG_CMD_EXT4=y > CONFIG_CMD_EXT4_WRITE=y > CONFIG_CMD_FAT=y > CONFIG_OF_CONTROL=y > -# CONFIG_BLK is not set > CONFIG_DFU_MMC=y > CONFIG_DFU_RAM=y > CONFIG_DM_GPIO=y > diff --git a/configs/mx7dsabresd_secure_defconfig > b/configs/mx7dsabresd_secure_defconfig > index bd68831..d1af138 100644 > --- a/configs/mx7dsabresd_secure_defconfig > +++ b/configs/mx7dsabresd_secure_defconfig > @@ -40,7 +40,6 @@ CONFIG_CMD_EXT4=y > CONFIG_CMD_EXT4_WRITE=y > CONFIG_CMD_FAT=y > CONFIG_OF_CONTROL=y > -# CONFIG_BLK is not set > CONFIG_DFU_MMC=y > CONFIG_DFU_RAM=y > CONFIG_DM_GPIO=y It sounds like BLK shouldn't be default y if DM_MMC but rather selected by DM_MMC. Yes? -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model
On Wed, Oct 11, 2017 at 6:49 PM, Tom Rini wrote: > It sounds like BLK shouldn't be default y if DM_MMC but rather selected > by DM_MMC. Yes? What about this? --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -13,6 +13,7 @@ config MMC config DM_MMC bool "Enable MMC controllers using Driver Model" depends on DM + select BLK help This enables the MultiMediaCard (MMC) uclass which supports MMC and Secure Digital I/O (SDIO) cards. Both removable (SD, micro-SD, etc.) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model
On Wed, Oct 11, 2017 at 06:53:13PM -0300, Fabio Estevam wrote: > On Wed, Oct 11, 2017 at 6:49 PM, Tom Rini wrote: > > > It sounds like BLK shouldn't be default y if DM_MMC but rather selected > > by DM_MMC. Yes? > > What about this? > > --- a/drivers/mmc/Kconfig > +++ b/drivers/mmc/Kconfig > @@ -13,6 +13,7 @@ config MMC > config DM_MMC > bool "Enable MMC controllers using Driver Model" > depends on DM > + select BLK > help > This enables the MultiMediaCard (MMC) uclass which supports MMC and > Secure Digital I/O (SDIO) cards. Both removable (SD, micro-SD, etc.) Yes, I think that's it, along with removing the default y if DM_MMC from the BLK entry. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/11] efi_loader: Initial HII protocols
On Wed, Oct 11, 2017 at 10:30 AM, Alexander Graf wrote:
>
>
> On 10.10.17 14:22, Rob Clark wrote:
>> From: Leif Lindholm
>>
>> Enough implementation of the following protocols to run Shell.efi and
>> SCT.efi:
>>
>> EfiHiiConfigRoutingProtocolGuid
>> EfiHiiDatabaseProtocol
>> EfiHiiStringProtocol
>>
>> We'll fill in the rest once SCT is running properly so we can validate
>> the implementation against the conformance test suite.
>>
>> Initial skeleton written by Leif, and then implementation by myself.
>>
>> Cc: Leif Lindholm
>> Signed-off-by: Rob Clark
>> ---
>> include/efi_api.h | 261 ++
>> include/efi_loader.h | 6 +
>> lib/efi_loader/Makefile | 2 +-
>> lib/efi_loader/efi_boottime.c | 9 +
>> lib/efi_loader/efi_hii.c | 507
>> ++
>> 5 files changed, 784 insertions(+), 1 deletion(-)
>> create mode 100644 lib/efi_loader/efi_hii.c
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index ffdba7fe1a..164147dc87 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -16,6 +16,7 @@
>> #define _EFI_API_H
>>
>> #include
>> +#include
>>
>> #ifdef CONFIG_EFI_LOADER
>> #include
>> @@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
>> uint16_t node_length);
>> };
>>
>> +#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
>> + EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
>> + 0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
>> +
>> +typedef uint16_t efi_string_id_t;
>> +
>> +struct efi_hii_config_routing_protocol {
>> + efi_status_t(EFIAPI *extract_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t request,
>> + efi_string_t *progress,
>> + efi_string_t *results);
>> + efi_status_t(EFIAPI *export_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + efi_string_t *results);
>> + efi_status_t(EFIAPI *route_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t configuration,
>> + efi_string_t *progress);
>> + efi_status_t(EFIAPI *block_to_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t config_request,
>> + const uint8_t *block,
>> + const efi_uintn_t block_size,
>> + efi_string_t *config,
>> + efi_string_t *progress);
>> + efi_status_t(EFIAPI *config_to_block)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t config_resp,
>> + const uint8_t *block,
>> + const efi_uintn_t *block_size,
>> + efi_string_t *progress);
>> + efi_status_t(EFIAPI *get_alt_config)(
>> + const struct efi_hii_config_routing_protocol *this,
>> + const efi_string_t config_resp,
>> + const efi_guid_t *guid,
>> + const efi_string_t name,
>> + const struct efi_device_path *device_path,
>> + const efi_string_t alt_cfg_id,
>> + efi_string_t *alt_cfg_resp);
>> +};
>> +
>> +#define EFI_HII_DATABASE_PROTOCOL_GUID\
>> + EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
>> + 0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
>> +
>> +typedef enum {
>> + EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
>> + EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, EFI_KEY_LEFT_ARROW,
>> + EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
>> + EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
>> + EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, EFI_KEY_B6,
>> + EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
>> + EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
>> + EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
>> + EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
>> + EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
>> + EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
>> + EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, EFI_KEY_D8,
>> + EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11, EFI_KEY_D12, EFI_KEY_D13,
>> + EFI_KEY_DEL, EFI_KEY_END, EFI_KEY_PG_DN, EFI_KEY_SEVEN, EFI_KEY_EIGHT,
>> + EFI_KEY_NINE, EFI_KEY_E0, EFI_KEY_E1, EFI_KEY_E2, EFI_KEY_E3,
>> + EFI_KEY_E4, EFI_KEY_E5, EFI_KEY_E6, EFI_KEY_E7, EFI_KEY_E8, EFI_KEY_E9,
>> + EFI_KEY_E10, EFI_KEY_E11, EFI_KEY_E12, EFI_KEY_BACK_SPACE,
>> + EFI_KEY_INS, EFI_KEY_HOME, EFI_KEY_PG_UP, EFI_KEY_NLCK, EFI_KEY_SLASH,
>> + EFI_KEY_ASTERISK, EFI_KEY_MINUS, EFI_KEY_ESC, EFI_KEY_F1, EFI_KEY_F2,
>> + EFI_KEY_F3, EFI_KEY_F4, EFI_KEY_F5, EFI_KEY_F6, EFI_KEY_F7, EFI_KEY_F8,
>> + EFI_KEY_F9, EFI_KEY_F10, EFI_KEY_F11, EFI_KEY_F12,
Re: [U-Boot] [PATCH V2] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model
On Wed, Oct 11, 2017 at 6:55 PM, Tom Rini wrote: > Yes, I think that's it, along with removing the default y if DM_MMC from > the BLK entry. Thanks! Ok, if I do as suggested: --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -1,7 +1,6 @@ config BLK bool "Support block devices" depends on DM - default y if DM_MMC help Enable support for block devices, such as SCSI, MMC and USB flash sticks. These provide a block-level interface which permits diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index 94050836..f4c953c 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -13,6 +13,7 @@ config MMC config DM_MMC bool "Enable MMC controllers using Driver Model" depends on DM + select BLK help This enables the MultiMediaCard (MMC) uclass which supports MMC and Secure Digital I/O (SDIO) cards. Both removable (SD, micro-SD, etc.) Then mx7dsabresd_defconfig build and boots fine. However, mx6slevk_defconfig fails to build like this: CC common/usb_storage.o common/usb_storage.c: In function ‘usb_stor_probe_device’: common/usb_storage.c:208:30: error: ‘struct usb_device’ has no member named ‘dev’ data = dev_get_platdata(udev->dev); ^ common/usb_storage.c:218:32: error: ‘struct usb_device’ has no member named ‘dev’ ret = blk_create_devicef(udev->dev, "usb_storage_blk", str, ^ I can fix it by doing: --- a/configs/mx6slevk_defconfig +++ b/configs/mx6slevk_defconfig @@ -44,6 +44,7 @@ CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_THERMAL=y CONFIG_USB=y +CONFIG_DM_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y Is there a better fix for this breakage? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout
On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf wrote: > > > On 10.10.17 14:23, Rob Clark wrote: >> In some cases, it is quite useful to have (for example) EFI on screen >> but u-boot on serial port. >> >> This adds two new optional environment variables, "efiin" and "efiout", >> which can be used to set EFI console input/output independently of >> u-boot's input/output. If unset, EFI console will default to stdin/ >> stdout as before. >> >> Signed-off-by: Rob Clark > > With this patch, we lose the ability to have the efi in/out go to both > graphical and serial console, right? This is critical functionality to > have, since we don't necessarily know which output/input a user ends up > using. I'll think about how to support iomux.. but some things like console size are just not going to work properly there. And as long as we fix the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can simply not set efiout var and have things working as before, so you don't loose any existing functionality (although, like I said, if the two different consoles have different sizes things aren't going to work properly for anything other than simple cases). In most cases, the display driver should be able to detect whether a display is connected.. this is what I've done on dragonboard410c, so if no display plugged in, 'efiout=vidconsole' fails and you fall back to serial, else you get efi on screen like you would on a "real" computer. For boards that have a display driver that isn't able to do the basic check of whether a cable is plugged in, just don't set "efiout" (or fix the display driver) ;-) BR, -R > > Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/11] efi_loader: fix events
On Wed, Oct 11, 2017 at 10:49 AM, Alexander Graf wrote:
>
>
> On 10.10.17 14:23, Rob Clark wrote:
>> An event can be created with type==0, Shell.efi does this for an event
>> that is set when Ctrl-C is typed. So our current approach of having a
>> fixed set of timer slots, and determining which slots are unused by
>> type==0 doesn't work so well. But we don't have any particularly good
>> reason to have a fixed table of events, so just dynamically allocate
>> them and keep a list.
>>
>> Also fixes an incorrect implementation of CheckEvent() which was (a)
>> incorrectly returning an error if type==0, and (b) didn't handle the
>> case of an unsignaled event with a notify callback.
>>
>> With these fixes (plus implementation of SIMPLE_TEXT_INPUT_EX protocol),
>> Ctrl-C works in Shell.efi.
>>
>> Signed-off-by: Rob Clark
>> ---
>> include/efi_loader.h | 1 +
>> lib/efi_loader/efi_boottime.c | 217
>> +-
>> 2 files changed, 111 insertions(+), 107 deletions(-)
>>
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index e6e55d2cb4..2232caca44 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -154,6 +154,7 @@ struct efi_event {
>> enum efi_timer_delay trigger_type;
>> bool is_queued;
>> bool is_signaled;
>> + struct list_head link;
>> };
>>
>>
>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index 39dcc72648..19fafe546c 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -350,11 +350,26 @@ static efi_status_t efi_create_handle(void **handle)
>> return r;
>> }
>>
>> +static LIST_HEAD(efi_events);
>> +
>> /*
>> - * Our event capabilities are very limited. Only a small limited
>> - * number of events is allowed to coexist.
>> + * Check if a pointer is a valid event.
>> + *
>> + * It might be nice at some point to extend this to a more general
>> + * mechanism to check if pointers passed from the EFI world are
>> + * valid objects of a particular type.
>> */
>> -static struct efi_event efi_events[16];
>> +static bool efi_is_event(const void *obj)
>> +{
>> + struct efi_event *evt;
>> +
>> + list_for_each_entry(evt, &efi_events, link) {
>> + if (evt == obj)
>> + return true;
>> + }
>> +
>> + return false;
>> +}
>>
>> /*
>> * Create an event.
>> @@ -377,7 +392,7 @@ efi_status_t efi_create_event(uint32_t type, UINTN
>> notify_tpl,
>> void *context),
>> void *notify_context, struct efi_event **event)
>> {
>> - int i;
>> + struct efi_event *evt;
>>
>> if (event == NULL)
>> return EFI_INVALID_PARAMETER;
>> @@ -389,21 +404,24 @@ efi_status_t efi_create_event(uint32_t type, UINTN
>> notify_tpl,
>> notify_function == NULL)
>> return EFI_INVALID_PARAMETER;
>>
>> - for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
>> - if (efi_events[i].type)
>> - continue;
>> - efi_events[i].type = type;
>> - efi_events[i].notify_tpl = notify_tpl;
>> - efi_events[i].notify_function = notify_function;
>> - efi_events[i].notify_context = notify_context;
>> - /* Disable timers on bootup */
>> - efi_events[i].trigger_next = -1ULL;
>> - efi_events[i].is_queued = false;
>> - efi_events[i].is_signaled = false;
>> - *event = &efi_events[i];
>> - return EFI_SUCCESS;
>> - }
>> - return EFI_OUT_OF_RESOURCES;
>> + evt = calloc(1, sizeof(*evt));
>> + if (!evt)
>> + return EFI_OUT_OF_RESOURCES;
>> +
>> + evt->type = type;
>> + evt->notify_tpl = notify_tpl;
>> + evt->notify_function = notify_function;
>> + evt->notify_context = notify_context;
>> + /* Disable timers on bootup */
>> + evt->trigger_next = -1ULL;
>> + evt->is_queued = false;
>> + evt->is_signaled = false;
>> +
>> + list_add_tail(&evt->link, &efi_events);
>> +
>> + *event = evt;
>> +
>> + return EFI_SUCCESS;
>> }
>>
>> /*
>> @@ -443,30 +461,31 @@ static efi_status_t EFIAPI efi_create_event_ext(
>> */
>> void efi_timer_check(void)
>> {
>> - int i;
>> + struct efi_event *evt;
>> u64 now = timer_get_us();
>>
>> - for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
>> - if (!efi_events[i].type)
>> - continue;
>> - if (efi_events[i].is_queued)
>> - efi_signal_event(&efi_events[i]);
>> - if (!(efi_events[i].type & EVT_TIMER) ||
>> - now < efi_events[i].trigger_next)
>> + /*
>> + * TODO perhaps optimize a bit and track the time of next
>> + * timer to expire?
>> + */
>> + list_for_each_entry(evt, &efi_events, link) {
>> + if (evt->is_queued)
>> + efi_signal_eve
Re: [U-Boot] [PATCH 10/11] efi_loader: Add mem-mapped for fallback
On Wed, Oct 11, 2017 at 10:59 AM, Alexander Graf wrote:
>
>
> On 10.10.17 14:23, Rob Clark wrote:
>> When we don't have a real device/image path, such as 'bootefi hello',
>> construct a mem-mapped device-path.
>>
>> This fixes 'bootefi hello' after devicepath refactoring.
>>
>> Fixes: 95c5553ea2 ("efi_loader: refactor boot device and loaded_image
>> handling")
>> Signed-off-by: Rob Clark
>> ---
>> cmd/bootefi.c| 23 +++
>> include/efi_api.h| 8
>> include/efi_loader.h | 3 +++
>> lib/efi_loader/efi_device_path.c | 24
>> lib/efi_loader/efi_device_path_to_text.c | 9 +
>> 5 files changed, 67 insertions(+)
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index 24958ada46..18176a1266 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -128,6 +128,7 @@ static unsigned long do_bootefi_exec(void *efi, void
>> *fdt,
>> {
>> struct efi_loaded_image loaded_image_info = {};
>> struct efi_object loaded_image_info_obj = {};
>> + struct efi_device_path *memdp = NULL;
>> ulong ret;
>>
>> ulong (*entry)(void *image_handle, struct efi_system_table *st)
>> @@ -136,6 +137,20 @@ static unsigned long do_bootefi_exec(void *efi, void
>> *fdt,
>> const efi_guid_t fdt_guid = EFI_FDT_GUID;
>> bootm_headers_t img = { 0 };
>>
>> + /*
>> + * Special case for efi payload not loaded from disk, such as
>> + * 'bootefi hello' or for example payload loaded directly into
>> + * memory via jtag/etc:
>> + */
>> + if (!device_path && !image_path) {
>> + printf("WARNING: using memory device/image path, this may
>> confuse some payloads!\n");
>> + /* actual addresses filled in after efi_load_pe() */
>> + memdp = efi_dp_from_mem(0, 0, 0);
>> + device_path = image_path = memdp;
>> + } else {
>> + assert(device_path && image_path);
>> + }
>> +
>> /* Initialize and populate EFI object list */
>> if (!efi_obj_list_initalized)
>> efi_init_obj_list();
>> @@ -182,6 +197,14 @@ static unsigned long do_bootefi_exec(void *efi, void
>> *fdt,
>> goto exit;
>> }
>>
>> + if (memdp) {
>> + struct efi_device_path_memory *mdp = (void *)memdp;
>> + mdp->memory_type = loaded_image_info.image_code_type;
>> + mdp->start_address = (uintptr_t)loaded_image_info.image_base;
>> + mdp->end_address = mdp->start_address +
>> + loaded_image_info.image_size;
>> + }
>> +
>
> memdp gets leaked after bootefi is done. Putting it on the stack would
> at least remove that problem ;). We currently expect to only return from
> bootefi when a payload was successfully quit.
>
dp's that aren't allocated from pool are a bad idea, in some cases
they get free'd by the payload. (Well not really in this particular
case but it feels like a bad idea to mix/match how we allocate dp's..
also, it needs an /End node.) I guess it isn't such a critical leak,
but the right solution would be to efi_free_pool() it..
BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model
On Wed, Oct 11, 2017 at 07:07:04PM -0300, Fabio Estevam wrote: > On Wed, Oct 11, 2017 at 6:55 PM, Tom Rini wrote: > > > Yes, I think that's it, along with removing the default y if DM_MMC from > > the BLK entry. Thanks! > > Ok, if I do as suggested: > > --- a/drivers/block/Kconfig > +++ b/drivers/block/Kconfig > @@ -1,7 +1,6 @@ > config BLK > bool "Support block devices" > depends on DM > - default y if DM_MMC > help > Enable support for block devices, such as SCSI, MMC and USB > flash sticks. These provide a block-level interface which permits > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig > index 94050836..f4c953c 100644 > --- a/drivers/mmc/Kconfig > +++ b/drivers/mmc/Kconfig > @@ -13,6 +13,7 @@ config MMC > config DM_MMC > bool "Enable MMC controllers using Driver Model" > depends on DM > + select BLK > help > This enables the MultiMediaCard (MMC) uclass which supports MMC and > Secure Digital I/O (SDIO) cards. Both removable (SD, micro-SD, etc.) > > Then mx7dsabresd_defconfig build and boots fine. > > However, mx6slevk_defconfig fails to build like this: > > CC common/usb_storage.o > common/usb_storage.c: In function ‘usb_stor_probe_device’: > common/usb_storage.c:208:30: error: ‘struct usb_device’ has no member > named ‘dev’ > data = dev_get_platdata(udev->dev); > ^ > common/usb_storage.c:218:32: error: ‘struct usb_device’ has no member > named ‘dev’ >ret = blk_create_devicef(udev->dev, "usb_storage_blk", str, > ^ > I can fix it by doing: > > --- a/configs/mx6slevk_defconfig > +++ b/configs/mx6slevk_defconfig > @@ -44,6 +44,7 @@ CONFIG_DM_REGULATOR_FIXED=y > CONFIG_DM_REGULATOR_GPIO=y > CONFIG_DM_THERMAL=y > CONFIG_USB=y > +CONFIG_DM_USB=y > CONFIG_USB_STORAGE=y > CONFIG_USB_HOST_ETHER=y > CONFIG_USB_ETHER_ASIX=y > > Is there a better fix for this breakage? Hmmm. So, if you have DM and DM_MMC, you need BLK. If you have DM and BLK and USB, you also need DM_USB (and vice-versa, if you have DM and DM_USB and not DM_MMC, things will break too, on another platform I bet). So, DM_USB should also select BLK I think. The case like mx6slkevk where you have DM_USB supported by not enabled are a bug of sorts where it needs to also be enabling DM_USB. I think I'll need to do a world build to see what fails in this case, unless you want to do it? Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model
On Wed, Oct 11, 2017 at 7:17 PM, Tom Rini wrote: > Hmmm. So, if you have DM and DM_MMC, you need BLK. If you have DM and > BLK and USB, you also need DM_USB (and vice-versa, if you have DM and DM_USB > and > not DM_MMC, things will break too, on another platform I bet). So, > DM_USB should also select BLK I think. The case like mx6slkevk where > you have DM_USB supported by not enabled are a bug of sorts where it > needs to also be enabling DM_USB. I think I'll need to do a world build > to see what fails in this case, unless you want to do it? Thanks! Please go ahead with the build. I am about to leave for holidays. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] efi_loader query
On Wed, Oct 11, 2017 at 12:13 PM, Suneel Garapati wrote: > Hi Rob, > > I am enlisted on u-boot mailing list and currently trying to use efi > loader to launch ubuntu distro. > > Appreciate your great efforts on this, would definitely help a lot. > > I tried to boot grub from u-boot using efi_loader using, > bootefi note that the distro-bootcmd stuff should "just work" to avoid needing to do this step manually > however I see one error "Error to install/update FDT" while launch > ubuntu from grub menu. So, without editing grub.cfg to add 'devicetree' commands, it is expecting u-boot to load the correct fdt before 'bootefi'.. I have a patch[1] to do this as part of distro-bootcmd which we are using in fedora. [1] https://patchwork.ozlabs.org/patch/821470/ > I could also see > "Loading Linux.." > "Loading ramdisk..." > But jumps back to grub menu instead of booting into linux. > > I would like to know if CONFIG_EFI_LOADER will suffice or anything > else needs to be defined for distro support. I think also CONFIG_DISTRO_DEFAULTS.. assuming there are no special hacks in ubuntu's grub build for arm/arm64, at least. For fedora we are not using any special arm specific patches for grub (or shim/fallback) and (at least with the addition of the patch mentioned above to handled fdt loading in u-boot) it all just works automatically the same way it does on x86_64 (with all the other patches that landed for 2017.11 so far). BR, -R > Any suggestions/inputs would be of great help. > > Regards, > Suneel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] power: extend prefix match to regulator-name property
Hi Felix,
On 9 October 2017 at 03:04, Felix Brack wrote:
>
> This patch extends pmic_bind_children prefix matching. In addition to
> the node name the property regulator-name is used while trying to match
> prefixes. This allows assigning different drivers to regulator nodes
> named regulator@1 and regulator@10 for example.
> Signed-off-by: Felix Brack
> ---
>
> drivers/power/pmic/pmic-uclass.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
Can you please add a sandbox test and documentation for this?
See:
test/dm/pmic.c
doc/driver-model/pmic-framework.txt
>
> diff --git a/drivers/power/pmic/pmic-uclass.c
> b/drivers/power/pmic/pmic-uclass.c
> index 64964e4..5a034f0 100644
> --- a/drivers/power/pmic/pmic-uclass.c
> +++ b/drivers/power/pmic/pmic-uclass.c
> @@ -26,6 +26,7 @@ int pmic_bind_children(struct udevice *pmic, ofnode parent,
> struct driver *drv;
> struct udevice *child;
> const char *node_name;
> + const char *reg_name;
> int bind_count = 0;
> ofnode node;
> int prefix_len;
> @@ -44,8 +45,18 @@ int pmic_bind_children(struct udevice *pmic, ofnode parent,
> debug(" - compatible prefix: '%s'\n", info->prefix);
>
> prefix_len = strlen(info->prefix);
> - if (strncmp(info->prefix, node_name, prefix_len))
> - continue;
> + if (strncmp(info->prefix, node_name, prefix_len)) {
> + reg_name = ofnode_read_string(node,
> +
> "regulator-name");
> + if (reg_name) {
> + if (strncmp(info->prefix, reg_name,
> + prefix_len)) {
> + continue;
> + }
> + } else {
> + continue;
> + }
> + }
>
> drv = lists_driver_lookup_name(info->driver);
> if (!drv) {
> --
> 2.7.4
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] power: extend prefix match to regulator-name property
On Mon, Oct 9, 2017 at 6:04 PM, Felix Brack wrote: > This patch extends pmic_bind_children prefix matching. In addition to > the node name the property regulator-name is used while trying to match > prefixes. This allows assigning different drivers to regulator nodes > named regulator@1 and regulator@10 for example. No. See the regulator bindings: Optional properties: - regulator-name: A string used as a descriptive name for regulator outputs This can vary from board to board. The name should match the power rail name of the board (which may not be the same as the regulator chip's output name). If you have multiple regulator nodes which need to be differentiated, you need to use the deprecated "regulator-compatible" property, or just use the standard compatible property. ChenYu ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] tools: env: Add embedded.c to .gitignore
Signed-off-by: Bin Meng --- tools/env/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/env/.gitignore b/tools/env/.gitignore index 804abac..8d28b2b 100644 --- a/tools/env/.gitignore +++ b/tools/env/.gitignore @@ -1,2 +1,3 @@ +embedded.c fw_printenv fw_printenv_unstripped -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] board: ti: dra71x-evm: Hook LDO1 of LP8733 to EN_PIN
All regulators are hooked to EN_Pin at reset so that EN Pin controls their state. Hook the LDO1 regulator to EN pin which at reset is not hooked. This applies only to LP8733. Signed-off-by: Keerthy --- board/ti/dra7xx/evm.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c index 25ffdfb..441f14f 100644 --- a/board/ti/dra7xx/evm.c +++ b/board/ti/dra7xx/evm.c @@ -682,6 +682,13 @@ int board_late_init(void) omap_die_id_serial(); omap_set_fastboot_vars(); + + /* +* Hook the LDO1 regulator to EN pin. This applies only to LP8733 +* Rest all regulators are hooked to EN Pin at reset. +*/ + if (board_is_dra71x_evm()) + palmas_i2c_write_u8(LP873X_I2C_SLAVE_ADDR, 0x9, 0x7); #endif return 0; } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/5] arm64: layerscape: Move CONFIG_HAS_FSL_XHCI_USB to Kconfig
Hi Ran, On Wed, Oct 11, 2017 at 1:30 PM, Ran Wang wrote: > Use Kconfig to select QE-HDLC and USB pin-mux. > > Signed-off-by: Ran Wang > --- > Change in v3: > New patch file. > > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 7 +++ > include/configs/ls1012afrdm.h | 4 > include/configs/ls1012aqds.h | 4 > include/configs/ls1012ardb.h | 4 > include/configs/ls1021aiot.h | 4 > include/configs/ls1021aqds.h | 4 > include/configs/ls1021atwr.h | 4 > include/configs/ls1043aqds.h | 3 --- > include/configs/ls1043ardb.h | 3 --- > include/configs/ls1046aqds.h | 3 --- > include/configs/ls1046ardb.h | 3 --- > include/configs/ls2080aqds.h | 1 - > include/configs/ls2080ardb.h | 1 - > scripts/config_whitelist.txt | 1 - > 14 files changed, 7 insertions(+), 39 deletions(-) > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > index 3518d8601d..9fda8a1e83 100644 > --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig > @@ -489,3 +489,10 @@ config SYS_MC_RSV_MEM_ALIGN > > config SPL_LDSCRIPT > default "arch/arm/cpu/armv8/u-boot-spl.lds" if ARCH_LS1043A || > ARCH_LS1046A || ARCH_LS2080A > + > +config HAS_FSL_XHCI_USB > + bool > + default y if ARCH_LS1043A || ARCH_LS1046A How about LS2080? I see there is modification on 2080 related files in this patch. > + help > + For some SoC(such as LS1043A and LS1046A), USB and QE-HDLC multi-use nits: SoCs ( What is multi-use? I think you wanted to say: multiplex > + the pins, select it when pin assigned to USB. nits: when pin is assigned > diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h > index 6b1ba578e9..2e5af9cc4e 100644 > --- a/include/configs/ls1012afrdm.h > +++ b/include/configs/ls1012afrdm.h > @@ -34,12 +34,8 @@ > /* > * USB > */ > -#define CONFIG_HAS_FSL_XHCI_USB > - > -#ifdef CONFIG_HAS_FSL_XHCI_USB > #define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 > -#endif > > #define CONFIG_CMD_MEMINFO > #define CONFIG_CMD_MEMTEST > diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h > index b3121d2c21..e0949d0b53 100644 > --- a/include/configs/ls1012aqds.h > +++ b/include/configs/ls1012aqds.h > @@ -119,12 +119,8 @@ > #endif > > /*XHCI Support - enabled by default*/ > -#define CONFIG_HAS_FSL_XHCI_USB > - > -#ifdef CONFIG_HAS_FSL_XHCI_USB > #define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 > -#endif > > /* MMC */ > #ifdef CONFIG_MMC > diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h > index e9edcd2bc9..66ff004384 100644 > --- a/include/configs/ls1012ardb.h > +++ b/include/configs/ls1012ardb.h > @@ -22,12 +22,8 @@ > /* > * USB > */ > -#define CONFIG_HAS_FSL_XHCI_USB > - > -#ifdef CONFIG_HAS_FSL_XHCI_USB > #define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 > -#endif > > /* > * I2C IO expander > diff --git a/include/configs/ls1021aiot.h b/include/configs/ls1021aiot.h > index 3fe7b8f44c..2cbea87d95 100644 > --- a/include/configs/ls1021aiot.h > +++ b/include/configs/ls1021aiot.h > @@ -20,12 +20,8 @@ > #define CONFIG_SYS_INIT_RAM_SIZE OCRAM_SIZE > > /* XHCI Support - enabled by default */ > -#define CONFIG_HAS_FSL_XHCI_USB > - > -#ifdef CONFIG_HAS_FSL_XHCI_USB > #define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT1 > -#endif > > #define CONFIG_SYS_CLK_FREQ1 > #define CONFIG_DDR_CLK_FREQ1 > diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h > index f3d3aa2271..0046ded536 100644 > --- a/include/configs/ls1021aqds.h > +++ b/include/configs/ls1021aqds.h > @@ -405,12 +405,8 @@ unsigned long get_board_ddr_clk(void); > #endif > > /*XHCI Support - enabled by default*/ > -#define CONFIG_HAS_FSL_XHCI_USB > - > -#ifdef CONFIG_HAS_FSL_XHCI_USB > #define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT1 > -#endif > > /* > * Video > diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h > index 852ff57fb6..0172c9015d 100644 > --- a/include/configs/ls1021atwr.h > +++ b/include/configs/ls1021atwr.h > @@ -45,12 +45,8 @@ > #endif > > /* XHCI Support - enabled by default */ > -#define CONFIG_HAS_FSL_XHCI_USB > - > -#ifdef CONFIG_HAS_FSL_XHCI_USB > #define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT1 > -#endif > > #define CONFIG_SYS_CLK_FREQ1 > #define CONFIG_DDR_CLK_FREQ1 > diff --git a/include/configs/ls1043aqds.h b/include/configs/ls1043aqds.h > index 5aadd92efd..607c289d17 100644 > --- a/include/configs/ls1043aqds.h > +++ b/include/configs/ls
Re: [U-Boot] [PATCH v3 2/5] usb: host: Move CONFIG_XHCI_FSL to Kconfig
Hi Ran, On Wed, Oct 11, 2017 at 1:30 PM, Ran Wang wrote: > use Kconfig to select xhci accordingly. > > Signed-off-by: Ran Wang > --- > Change in v3: > New patch file. > > drivers/usb/host/Kconfig | 6 ++ > include/configs/ls1012afrdm.h | 1 - > include/configs/ls1012aqds.h | 1 - > include/configs/ls1012ardb.h | 1 - > include/configs/ls1021aiot.h | 1 - > include/configs/ls1021aqds.h | 1 - > include/configs/ls1021atwr.h | 1 - > include/configs/ls1043aqds.h | 1 - > include/configs/ls1043ardb.h | 1 - > include/configs/ls1046aqds.h | 1 - > include/configs/ls1046ardb.h | 1 - > include/configs/ls2080aqds.h | 1 - > include/configs/ls2080ardb.h | 1 - > scripts/config_whitelist.txt | 1 - > 14 files changed, 6 insertions(+), 13 deletions(-) > > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig > index f797a2568c..70e38a0425 100644 > --- a/drivers/usb/host/Kconfig > +++ b/drivers/usb/host/Kconfig > @@ -71,6 +71,12 @@ config USB_XHCI_DRA7XX_INDEX > Select the DRA7XX xHCI USB index. > Current supported values: 0, 1. > > +config USB_XHCI_FSL > + bool "Support for NXPLayerscape on-chip xHCI USB controller" nits: NXP Layerscape > + default y if ARCH_LS1021A || FSL_LSCH3 || FSL_LSCH2 > + depends on !SPL_NO_USB > + help > + Enables support for the on-chip xHCI controller on NXP Layerscape > SoCs. > endif # USB_XHCI_HCD > > config USB_EHCI_HCD > diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h > index 2e5af9cc4e..2e9c619bd5 100644 > --- a/include/configs/ls1012afrdm.h > +++ b/include/configs/ls1012afrdm.h > @@ -34,7 +34,6 @@ > /* > * USB > */ > -#define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 > > #define CONFIG_CMD_MEMINFO > diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h > index e0949d0b53..70bf72c431 100644 > --- a/include/configs/ls1012aqds.h > +++ b/include/configs/ls1012aqds.h > @@ -119,7 +119,6 @@ > #endif > > /*XHCI Support - enabled by default*/ > -#define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 > > /* MMC */ > diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h > index 66ff004384..110fcc6323 100644 > --- a/include/configs/ls1012ardb.h > +++ b/include/configs/ls1012ardb.h > @@ -22,7 +22,6 @@ > /* > * USB > */ > -#define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 > > /* > diff --git a/include/configs/ls1021aiot.h b/include/configs/ls1021aiot.h > index 2cbea87d95..dac4a81e2a 100644 > --- a/include/configs/ls1021aiot.h > +++ b/include/configs/ls1021aiot.h > @@ -20,7 +20,6 @@ > #define CONFIG_SYS_INIT_RAM_SIZE OCRAM_SIZE > > /* XHCI Support - enabled by default */ > -#define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT1 > > #define CONFIG_SYS_CLK_FREQ1 > diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h > index 0046ded536..8346e3658f 100644 > --- a/include/configs/ls1021aqds.h > +++ b/include/configs/ls1021aqds.h > @@ -405,7 +405,6 @@ unsigned long get_board_ddr_clk(void); > #endif > > /*XHCI Support - enabled by default*/ > -#define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT1 > > /* > diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h > index 0172c9015d..8ccc81642d 100644 > --- a/include/configs/ls1021atwr.h > +++ b/include/configs/ls1021atwr.h > @@ -45,7 +45,6 @@ > #endif > > /* XHCI Support - enabled by default */ > -#define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT1 > > #define CONFIG_SYS_CLK_FREQ1 > diff --git a/include/configs/ls1043aqds.h b/include/configs/ls1043aqds.h > index 607c289d17..641ffc1400 100644 > --- a/include/configs/ls1043aqds.h > +++ b/include/configs/ls1043aqds.h > @@ -371,7 +371,6 @@ unsigned long get_board_ddr_clk(void); > #endif > > /* USB */ > -#define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT3 > > /* > diff --git a/include/configs/ls1043ardb.h b/include/configs/ls1043ardb.h > index 866817d579..0e02be445a 100644 > --- a/include/configs/ls1043ardb.h > +++ b/include/configs/ls1043ardb.h > @@ -281,7 +281,6 @@ > > /* USB */ > #ifndef SPL_NO_USB > -#define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT3 > #endif > > diff --git a/include/configs/ls1046aqds.h b/include/configs/ls1046aqds.h > index d47616f2e7..2f2602f098 100644 > --- a/include/configs/ls1046aqds.h > +++ b/include/configs/ls1046aqds.h > @@ -137,7 +137,6 @@ unsigned long get_board_ddr_clk(void); > #endif > > /* USB */ > -#define CONFIG_USB_XHCI_FSL > #define CONFIG_USB_MAX_CONTROLLER_COUNT 3 > > /* SATA */ > diff --git a/include/configs/ls1046ardb.h b/include/configs/ls1046ardb.h > index 32b08d8229..40ce8ff462 100644 > --- a/include/configs/ls1046ardb.h > +++ b/incl
Re: [U-Boot] [PATCH v3 3/5] arm: layerscape: Remove CONFIG_USB_MAX_CONTROLLER_COUNT
Hi Ran, On Wed, Oct 11, 2017 at 1:30 PM, Ran Wang wrote: > Because COMFIG_DM_USB have been enabled and will not use it anymore. nits: has been enabled > > Signed-off-by: Ran Wang > --- > Change in v3: > New patch file. > > include/configs/ls1012afrdm.h | 5 - > include/configs/ls1012aqds.h | 3 --- > include/configs/ls1012ardb.h | 4 > include/configs/ls1021aiot.h | 3 --- > include/configs/ls1021aqds.h | 3 --- > include/configs/ls1021atwr.h | 3 --- > include/configs/ls1043aqds.h | 3 --- > include/configs/ls1043ardb.h | 5 - > include/configs/ls1046aqds.h | 3 --- > include/configs/ls1046ardb.h | 5 - > include/configs/ls2080aqds.h | 5 - > include/configs/ls2080ardb.h | 5 - > 12 files changed, 47 deletions(-) > Other than that, Reviewed-by: Bin Meng Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] ls1088aqds: Enable USB command on QDS for qspi-boot
On Wed, Oct 11, 2017 at 1:30 PM, Ran Wang wrote: > Signed-off-by: Amrita Kumari > Signed-off-by: Ashish Kumar > Signed-off-by: Ran Wang > --- > Change in v3: > - none > > Change in v2: > Remove macro CONFIG_HAS_FSL_XHCI_USB and CONFIG_USB_XHCI_FSL > and CONFIG_USB_MAX_CONTROLLER_COUNT from ls1088aqds.h since > Kconfig option has covered. > > Change in v1: > Rebased to > ba39608 ARM: DRA72x: Add support for detection of DRA71x SR 2.1 > > configs/ls1088aqds_qspi_defconfig | 8 > 1 file changed, 8 insertions(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/5] ls1088ardb: Enable USB command RDB qspi-boot
On Wed, Oct 11, 2017 at 1:30 PM, Ran Wang wrote: > Signed-off-by: Ashish Kumar > Signed-off-by: Amrita Kumari > Signed-off-by: Ran Wang > --- > Change in v3: > 1.Move HAS_FSL_XHCI_USB and USB_XHCI_FSL define to other patch file. > > Change in v2: > 1.Adjust USB nodes position in dts to keep them sorted in > unit-address. > 2.Move macro CONFIG_HAS_FSL_XHCI_USB and CONFIG_USB_XHCI_FSL > to Kconfig option. > 3.Remove CONFIG_USB_MAX_CONTROLLER_COUNT. > > Change in v1: > Rebased to > ba39608 ARM: DRA72x: Add support for detection of DRA71x SR 2.1 > > arch/arm/dts/fsl-ls1088a.dtsi | 14 ++ > configs/ls1088ardb_qspi_defconfig | 8 > include/linux/usb/xhci-fsl.h | 2 +- > 3 files changed, 23 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: minnowmax: Adjust VGA rom address
On Sat, Oct 7, 2017 at 5:44 PM, Stefan Roese wrote: > On 07.10.2017 11:43, Bin Meng wrote: >> >> Adjust VGA rom address to 0xfffb so that u-boot.rom image >> can be built again. >> >> Signed-off-by: Bin Meng > > > Reviewed-by: Stefan Roese applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] armv8: configs: ls1012a: correct the generic timer frequency issue
From: Yuantian Tang On ls1012a soc, core clock source frequency is 100Mhz. Generic timer frequency is derived from core clock source divided by 4, which is 25Mhz. So assign timer frequency to 25Mhz here. Signed-off-by: Tang Yuantian --- v2: - refine the commit message include/configs/ls1012a_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h index 096799eb64..a4e78f335f 100644 --- a/include/configs/ls1012a_common.h +++ b/include/configs/ls1012a_common.h @@ -32,7 +32,7 @@ #define CONFIG_SYS_DDR_BLOCK2_BASE 0x88000ULL /* Generic Timer Definitions */ -#define COUNTER_FREQUENCY CONFIG_SYS_CLK_FREQ/4 /* 25MHz */ +#define COUNTER_FREQUENCY 2500/* 25MHz */ /* CSU */ #define CONFIG_LAYERSCAPE_NS_ACCESS -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/11] efi_loader: Initial EFI_DEVICE_PATH_UTILITIES_PROTOCOL
On 10/11/2017 10:32 PM, Rob Clark wrote:
On Wed, Oct 11, 2017 at 10:07 AM, Alexander Graf wrote:
On 10.10.17 14:22, Rob Clark wrote:
From: Leif Lindholm
Not complete, but enough for Shell.efi and SCT.efi. We'll implement the
rest as needed or once we have SCT running properly so there is a way to
validate the interface against the conformance test suite.
Initial skeleton written by Leif, and then implementation by myself.
Cc: Leif Lindholm
Signed-off-by: Rob Clark
---
include/efi_api.h | 34 +++-
include/efi_loader.h | 2 +
lib/efi_loader/Makefile| 1 +
lib/efi_loader/efi_boottime.c | 4 ++
lib/efi_loader/efi_device_path_utilities.c | 88 ++
5 files changed, 127 insertions(+), 2 deletions(-)
create mode 100644 lib/efi_loader/efi_device_path_utilities.c
diff --git a/include/efi_api.h b/include/efi_api.h
index a9a6494afe..ffdba7fe1a 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -28,8 +28,9 @@ enum efi_timer_delay {
EFI_TIMER_RELATIVE = 2
};
-#define UINTN size_t
-typedef long INTN;
+#define UINTN size_t /* TODO this should be removed in a future patch */
$ git grep UINTN | wc -l
13
Just send a preceding patch that introduces efi_uintn_t and replaces all
occurences of UINTN with it.
The uintn bits shouldn't be part of the
EFI_DEVICE_PATH_UTILITIES_PROTOCOL patch anyways :).
Heinrich mentioned he was doing that, so I didn't want to step on
feet. I figured this was the easiest approach regardless of the order
of merging patches (should be simple enough to drop the duplicate
efi_uintn_t)
I do not mind if you put the change in one of your patches. Just do what
is needed to get your patch series merged.
Best regards
Heinrich
BR,
-R
+typedef size_t efi_uintn_t;
+typedef ssize_t efi_intn_t;
typedef uint16_t *efi_string_t;
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
