Re: [U-Boot] [PATCH 1/2] riscv: qemu: Enable PCI host ECAM generic driver
Hi Bin Bin Meng 於 2019年6月4日 週二 下午2:27寫道： > > Hi Rick, > > On Tue, Jun 4, 2019 at 1:35 PM Rick Chen wrote: > > > > > > > > Hi BIn > > > > > > > Hi Rick, > > > > > > > > On Mon, May 27, 2019 at 4:40 PM Auer, Lukas > > > > wrote: > > > > > > > > > > On Wed, 2019-05-15 at 08:42 -0700, Bin Meng wrote: > > > > > > QEMU 4.0.0 'virt' target integrates a generic ECAM PCI host. > > > > > > Enable the driver for it. > > > > > > > > > > > > Signed-off-by: Bin Meng > > > > > > --- > > > > > > > > > > > > board/emulation/qemu-riscv/Kconfig | 4 > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > > > > > Reviewed-by: Lukas Auer > > > > > Tested-by: Lukas Auer > > > > > > > > Could you please apply this series for v2019.07? > > > > > > > > Applied to u-boot-riscv/master, thanks! > > Thanks for applying. > > By searching riscv patches from patchwork, it seems there are some old > patches that are not cleaned up. I am not sure about their status. > Maybe they are already applied. I will rebase to u-boot/master before applying the patchs. If they are already applied, there will have conflictions, right ? > > http://patchwork.ozlabs.org/project/uboot/list/?seriesriscv== > > Could you please do some house keeping? I am not sure what do you mean about house keeping ? > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] RSA in U-Boot
Tom, Wolfgang, On Wed, May 22, 2019 at 02:48:42PM +0900, AKASHI Takahiro wrote: > Wolfgang, > > Thank you for your comments. > > On Fri, May 17, 2019 at 10:47:56AM +0200, Wolfgang Denk wrote: > > Dear Akashi Takahiro, > > > > In message <20190517001206.gx11...@linaro.org> you wrote: > > > > > > > Who: usually the responsible custodians > > > > > > "Custodians" don't always mean sub-system maintainers. Right? > > > > It's just a different name for the same thing. > > Okay. > > > > In fact, I have already imported relevant kernel code into U-Boot > > > and it now works perfectly with my experimental UEFI secure boot patch, > > > but see the total size (and numbers) of files imported is quite big. > > > I wonder who is willing to maintain them: > > ... > > > 37 files changed, 6409 insertions(+), 11 deletions(-) > > > > Well, if you compare for example against libressl-portable , then > > this git repository has 180 files with more than 20,000 lines. > > I think that there are two different approaches in using > external code (library). > 1.import necessary source files into U-Boot repository, customize them > and build them with the rest of U-Boot > 2.build it as a static library, either totally outside of U-Boot > or as a git submodule, and link it, i.e. only needed binary blobs, > to U-Boot. > (I don't know any existing libraries like this in U-Boot though.) > > We can adopt only (1) for kernel code, but *in general* (2) as well > for a library. That way, we may potentially save/minimize our own > maintenance cost, again *in general.* > > Those said, it seems to me that, gnutls, for instance, is not well > optimized for smaller (or purpose-specific) systems. For example, > _wrap_nettle_pk_verify(), public key verification function, supports > not only RSA, but also DSA, ECDSA and so on with no "opt-out" options > while UEFI secure boot only needs and supports RSA. > > > We are adding a lot of functionality, and anyone who wants to use > > this will have to pay the price. But this is what I mentioned > > before: I think the kernel code has already been tweaked with an > > eye on resource consumption, while standard public libraries have > > not. > > I'm not very sure about your last statement above, but as far as > the customisability is concerned some libraries may have an issue > in (2) as I mentioned above. > > In this sense, I still want to seek a possibility of using other > smaller libraries, like mbedTLS. > (mbedTLS has another issue, lacking pkcs7 parser.) > > > The kernel code may be big, but I would be surprised if there are > > smaller and leaner alternatives with similar quality? > > > > As for who is willing to maintain it: I have no idea. Usually it > > turns out to be the original implementoer / who pushed the code > > upstream into U-Boot. > > Okay, but for most of examples you mentioned as linux-origin code, > there are no explicit maintainers. Right? Do you have any further comments regarding maintainability? (The *quality*, or trustworthiness, of the original code is an orthogonal issue.) Thanks, -Takahiro Akashi > -Takahiro Akashi > > > > > Best regards, > > > > Wolfgang Denk > > > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > > miracle: an extremely outstanding or unusual event, thing, or > > accomplishment.- Webster's Dictionary ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 5/6] cmd: efidebug: add "boot exit" sub-command
With "boot exit" sub-command, we will let the system to exit
UEFI Boottime Services. This is mainly for testing.
Signed-off-by: AKASHI Takahiro
---
cmd/efidebug.c | 63 ++
1 file changed, 63 insertions(+)
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index e65722625455..d6abf08c93cc 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -977,6 +977,66 @@ out:
return ret;
}
+/**
+ * do_efi_boot_exit() - exit boottime services
+ *
+ * @cmdtp: Command table
+ * @flag: Command flag
+ * @argc: Number of arguments
+ * @argv: Argument array
+ * Return: CMD_RET_SUCCESS on success,
+ * CMD_RET_USAGE or CMD_RET_RET_FAILURE on failure
+ *
+ * Implement efidebug "boot exit" sub-command.
+ * - boot exit
+ */
+static int do_efi_boot_exit(cmd_tbl_t *cmdtp, int flag,
+ int argc, char * const argv[])
+{
+ struct efi_mem_desc *memmap;
+ efi_uintn_t map_size, map_key, desc_size;
+ u32 desc_version;
+ efi_status_t ret;
+
+ if (argc != 1)
+ return CMD_RET_USAGE;
+
+ memmap = NULL;
+ map_size = 0;
+ ret = EFI_CALL(BS->get_memory_map(_size, memmap, _key,
+ _size, _version));
+ if (ret == EFI_BUFFER_TOO_SMALL) {
+ map_size += sizeof(struct efi_mem_desc); /* for my own */
+ ret = EFI_CALL(BS->allocate_pool(EFI_LOADER_DATA,
+map_size, (void *)));
+ if (ret != EFI_SUCCESS) {
+ printf("Out of memory\n");
+ return CMD_RET_FAILURE;
+ }
+ ret = EFI_CALL(BS->get_memory_map(_size, memmap,
+ _key,
+ _size, _version));
+ }
+ if (ret != EFI_SUCCESS) {
+ printf("Getting UEFI memory map failed (%zu)\n",
+ ret & ~EFI_ERROR_MASK);
+ goto err;
+ }
+
+ ret = EFI_CALL(BS->exit_boot_services(efi_root, map_key));
+ if (ret == EFI_SUCCESS)
+ return CMD_RET_SUCCESS;
+
+ printf("exiting Boottime Services failed (%zu)\n",
+ ret & ~EFI_ERROR_MASK);
+
+err:
+ if (memmap)
+ EFI_CALL(BS->free_pool(memmap));
+
+ return CMD_RET_FAILURE;
+}
+
static cmd_tbl_t cmd_efidebug_boot_sub[] = {
U_BOOT_CMD_MKENT(add, CONFIG_SYS_MAXARGS, 1, do_efi_boot_add, "", ""),
U_BOOT_CMD_MKENT(rm, CONFIG_SYS_MAXARGS, 1, do_efi_boot_rm, "", ""),
@@ -984,6 +1044,7 @@ static cmd_tbl_t cmd_efidebug_boot_sub[] = {
U_BOOT_CMD_MKENT(next, CONFIG_SYS_MAXARGS, 1, do_efi_boot_next, "", ""),
U_BOOT_CMD_MKENT(order, CONFIG_SYS_MAXARGS, 1, do_efi_boot_order,
"", ""),
+ U_BOOT_CMD_MKENT(exit, CONFIG_SYS_MAXARGS, 1, do_efi_boot_exit, "", ""),
};
/**
@@ -1087,6 +1148,8 @@ static char efidebug_help_text[] =
" - set UEFI BootNext variable\n"
"efidebug boot order [ [ [ [...\n"
" - set/show UEFI boot order\n"
+ "efidebug boot exit\n"
+ " - exit UEFI Boottime Services\n"
"\n"
"efidebug devices\n"
" - show uefi devices\n"
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 6/6] efi_loader: variable: support runtime variable access via cache
With this patch, cache buffer for UEFI variables will be created
so that we will still be able to access, at least retrieve,
UEFI variables when we exit from boottime services,
This feature is a "should" behavior described in EBBR v1.0
section 2.5.3.
Signed-off-by: AKASHI Takahiro
---
include/efi_loader.h | 17 ++
lib/efi_loader/Kconfig| 9 +
lib/efi_loader/efi_boottime.c | 10 +-
lib/efi_loader/efi_runtime.c | 13 +
lib/efi_loader/efi_variable.c | 467 ++
5 files changed, 515 insertions(+), 1 deletion(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 93f7ece814a0..acab657b9d70 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -620,6 +620,23 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
const efi_guid_t *vendor, u32 attributes,
efi_uintn_t data_size, const void *data);
+#ifdef CONFIG_EFI_RUNTIME_GET_VARIABLE_CACHING
+efi_status_t efi_freeze_variable_table(void);
+
+/* runtime version of APIs */
+efi_status_t
+__efi_runtime EFIAPI efi_get_variable_runtime(u16 *variable_name,
+ const efi_guid_t *vendor,
+ u32 *attributes,
+ efi_uintn_t *data_size,
+ void *data);
+efi_status_t
+__efi_runtime EFIAPI efi_get_next_variable_name_runtime(
+ efi_uintn_t *variable_name_size,
+ u16 *variable_name,
+ const efi_guid_t *vendor);
+#endif /* CONFIG_EFI_RUNTIME_GET_VARIABLE_CACHING */
+
/*
* See section 3.1.3 in the v2.7 UEFI spec for more details on
* the layout of EFI_LOAD_OPTION. In short it is:
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index e2ef43157568..3f284795648f 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -59,6 +59,15 @@ config EFI_RUNTIME_CONVERT_POINTER
to be called by UEFI drivers in relocating themselves to virtual
address space.
+config EFI_RUNTIME_GET_VARIABLE_CACHING
+ bool "runtime_service: GetVariable: Enable runtime access via cache
(read-only)"
+ default y
+ help
+ Select this option if you want to access UEFI variables at
+ runtime even though you cannot update values on the fly.
+ With or without this option, you can access UEFI variables
+ at boottime.
+
config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index e4abaf3601d9..14e343abbd43 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1892,6 +1892,9 @@ static efi_status_t EFIAPI
efi_exit_boot_services(efi_handle_t image_handle,
efi_uintn_t map_key)
{
struct efi_event *evt;
+#ifdef CONFIG_EFI_RUNTIME_GET_VARIABLE_CACHING
+ efi_status_t ret;
+#endif
EFI_ENTRY("%p, %zx", image_handle, map_key);
@@ -1921,7 +1924,12 @@ static efi_status_t EFIAPI
efi_exit_boot_services(efi_handle_t image_handle,
}
}
- /* TODO: Should persist EFI variables here */
+#ifdef CONFIG_EFI_RUNTIME_GET_VARIABLE_CACHING
+ /* No more variable update */
+ ret = efi_freeze_variable_table();
+ if (ret != EFI_SUCCESS)
+ return EFI_EXIT(ret);
+#endif
board_quiesce_devices();
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index fc5bdee80e00..b60f70f04613 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -111,6 +111,11 @@ efi_status_t efi_init_runtime_supported(void)
efi_runtime_services_supported |=
EFI_RT_SUPPORTED_CONVERT_POINTER;
#endif
+#ifdef CONFIG_EFI_RUNTIME_GET_VARIABLE_CACHING
+ efi_runtime_services_supported |=
+ (EFI_RT_SUPPORTED_GET_VARIABLE |
+EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME);
+#endif
return EFI_CALL(efi_set_variable(L"RuntimeServicesSupported",
_global_variable_guid,
@@ -469,10 +474,18 @@ static struct efi_runtime_detach_list_struct
efi_runtime_detach_list[] = {
.patchto = NULL,
}, {
.ptr = _runtime_services.get_variable,
+#ifdef CONFIG_EFI_RUNTIME_GET_VARIABLE_CACHING
+ .patchto = _get_variable_runtime,
+#else
.patchto = _device_error,
+#endif
}, {
.ptr = _runtime_services.get_next_variable_name,
+#ifdef CONFIG_EFI_RUNTIME_GET_VARIABLE_CACHING
+ .patchto = _get_next_variable_name,
+#else
.patchto = _device_error,
+#endif
[U-Boot] [RFC 3/6] efi_loader: support convert_pointer at runtime
With this patch, ConvertPointer runtime service is enabled.
This function will be useful only after SetVirtualAddressMap is called
and before it exits according to UEFI specification.
Signed-off-by: AKASHI Takahiro
---
lib/efi_loader/Kconfig | 8
lib/efi_loader/efi_runtime.c | 81 ++--
2 files changed, 66 insertions(+), 23 deletions(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index bb9c7582b14d..e2ef43157568 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -51,6 +51,14 @@ config EFI_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
Enable SetVirtualAddressMap runtime service. This API will be
called by OS just before it enters into virtual address mode.
+config EFI_RUNTIME_CONVERT_POINTER
+ bool "runtime service: ConvertPointer"
+ default n
+ help
+ Enable ConvertPointer runtime service. This API will be expected
+ to be called by UEFI drivers in relocating themselves to virtual
+ address space.
+
config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index cf202bb9ec07..ff3684a4b692 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -27,7 +27,6 @@ LIST_HEAD(efi_runtime_mmio);
static efi_status_t __efi_runtime EFIAPI efi_unimplemented(void);
static efi_status_t __efi_runtime EFIAPI efi_device_error(void);
-static efi_status_t __efi_runtime EFIAPI efi_invalid_parameter(void);
/*
* TODO(s...@chromium.org): These defines and structures should come from the
ELF
@@ -108,6 +107,10 @@ efi_status_t efi_init_runtime_supported(void)
efi_runtime_services_supported |=
EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP;
#endif
+#ifdef CONFIG_EFI_RUNTIME_CONVERT_POINTER
+ efi_runtime_services_supported |=
+ EFI_RT_SUPPORTED_CONVERT_POINTER;
+#endif
return EFI_CALL(efi_set_variable(L"RuntimeServicesSupported",
_global_variable_guid,
@@ -392,6 +395,39 @@ efi_status_t __weak __efi_runtime EFIAPI
efi_set_time(struct efi_time *time)
return EFI_UNSUPPORTED;
}
+#ifdef CONFIG_EFI_RUNTIME_CONVERT_POINTER
+static struct efi_mem_desc *efi_virtmap __efi_runtime_data;
+static int efi_virtmap_num __efi_runtime_data;
+
+static efi_status_t __efi_runtime EFIAPI efi_convert_pointer(unsigned long dbg,
+void **address)
+{
+ struct efi_mem_desc *map;
+ efi_physical_addr_t addr;
+ int i;
+
+ if (!efi_virtmap)
+ return EFI_UNSUPPORTED;
+
+ if (!address)
+ return EFI_INVALID_PARAMETER;
+
+ for (i = 0, map = efi_virtmap; i < efi_virtmap_num; i++, map++) {
+ addr = (efi_physical_addr_t)*address;
+ if (addr >= map->physical_start &&
+ (addr < (map->physical_start
++ (map->num_pages << EFI_PAGE_SHIFT {
+ *address = (void *)map->virtual_start;
+ *address += addr - map->physical_start;
+
+ return EFI_SUCCESS;
+ }
+ }
+
+ return EFI_NOT_FOUND;
+}
+#endif
+
struct efi_runtime_detach_list_struct {
void *ptr;
void *patchto;
@@ -599,6 +635,10 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
return EFI_EXIT(EFI_INVALID_PARAMETER);
}
+ efi_virtmap = virtmap;
+ efi_virtmap_num = n;
+
+#if 0 /* FIXME: This code is fragile as calloc is used in add_runtime_mmio */
/* Rebind mmio pointers */
for (i = 0; i < n; i++) {
struct efi_mem_desc *map = (void*)virtmap +
@@ -622,14 +662,14 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
*lmmio->ptr = (void *)new_addr;
}
}
- if ((map_start <= (uintptr_t)systab.tables) &&
- (map_end >= (uintptr_t)systab.tables)) {
- char *ptr = (char *)systab.tables;
-
- ptr += off;
- systab.tables = (struct efi_configuration_table *)ptr;
- }
}
+#endif
+
+ /* FIXME */
+ efi_convert_pointer(0, (void **));
+
+ /* All fixes must be done before this line */
+ efi_virtmap = NULL;
/* Move the actual runtime code over */
for (i = 0; i < n; i++) {
@@ -644,6 +684,11 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
/* Once we're virtual, we can no longer handle
complex callbacks */
efi_runtime_detach(new_offset);
+
+ /*
+* FIXME:
+* We can no longer update
[U-Boot] [RFC 1/6] efi_loader: runtime: make SetVirtualAddressMap configurable
OS does not always need to call SetVirtualAddressMap.
(Ard confirmed this on arm64 linux.)
So let this API configurable. If disabled, it will return EFI_UNSUPPORTED
as UEFI specification requires.
Signed-off-by: AKASHI Takahiro
---
lib/efi_loader/Kconfig | 7 +++
lib/efi_loader/efi_runtime.c | 8
2 files changed, 15 insertions(+)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 8bf4b1754d06..bb9c7582b14d 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -44,6 +44,13 @@ config EFI_SET_TIME
Provide the SetTime() runtime service at boottime. This service
can be used by an EFI application to adjust the real time clock.
+config EFI_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
+ bool "runtime service: SetVirtualAddressMap"
+ default n
+ help
+ Enable SetVirtualAddressMap runtime service. This API will be
+ called by OS just before it enters into virtual address mode.
+
config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 9c50955c9bd0..60442cb21d37 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -374,10 +374,12 @@ static const struct efi_runtime_detach_list_struct
efi_runtime_detach_list[] = {
/* do_reset is gone */
.ptr = _runtime_services.reset_system,
.patchto = efi_reset_system,
+#ifdef CONFIG_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
}, {
/* invalidate_*cache_all are gone */
.ptr = _runtime_services.set_virtual_address_map,
.patchto = _unimplemented,
+#endif
}, {
/* RTC accessors are gone */
.ptr = _runtime_services.get_time,
@@ -512,6 +514,7 @@ void efi_runtime_relocate(ulong offset, struct efi_mem_desc
*map)
invalidate_icache_all();
}
+#ifdef CONFIG_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
/**
* efi_set_virtual_address_map() - change from physical to virtual mapping
*
@@ -619,6 +622,7 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
return EFI_EXIT(EFI_INVALID_PARAMETER);
}
+#endif /* CONFIG_RUNTIME_SET_VIRTUAL_ADDRESS_MAP */
/**
* efi_add_runtime_mmio() - add memory-mapped IO region
@@ -796,7 +800,11 @@ struct efi_runtime_services __efi_runtime_data
efi_runtime_services = {
.set_time = _set_time_boottime,
.get_wakeup_time = (void *)_unimplemented,
.set_wakeup_time = (void *)_unimplemented,
+#ifdef CONFIG_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
.set_virtual_address_map = _set_virtual_address_map,
+#else
+ .set_virtual_address_map = (void *)_unimplemented,
+#endif
.convert_pointer = (void *)_invalid_parameter,
.get_variable = efi_get_variable,
.get_next_variable_name = efi_get_next_variable_name,
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 2/6] efi: add RuntimeServicesSupported variable
This variable is defined in UEFI specification 2.8, section 8.1.
Its value should be updated whenever we add any usable runtime services
function.
Signed-off-by: AKASHI Takahiro
---
include/efi_api.h| 15 +++
include/efi_loader.h | 3 +++
lib/efi_loader/efi_runtime.c | 28
lib/efi_loader/efi_setup.c | 5 +
4 files changed, 51 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h
index 65584dd2d82a..d7d95edd4dfc 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -213,6 +213,21 @@ struct efi_capsule_header {
u32 capsule_image_size;
};
+#define EFI_RT_SUPPORTED_GET_TIME 0x0001
+#define EFI_RT_SUPPORTED_SET_TIME 0x0002
+#define EFI_RT_SUPPORTED_GET_WAKEUP_TIME 0x0004
+#define EFI_RT_SUPPORTED_SET_WAKEUP_TIME 0x0008
+#define EFI_RT_SUPPORTED_GET_VARIABLE 0x0010
+#define EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME0x0020
+#define EFI_RT_SUPPORTED_SET_VARIABLE 0x0040
+#define EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP 0x0080
+#define EFI_RT_SUPPORTED_CONVERT_POINTER 0x0100
+#define EFI_RT_SUPPORTED_GET_NEXT_HIGH_MONOTONIC_COUNT 0x0200
+#define EFI_RT_SUPPORTED_RESET_SYSTEM 0x0400
+#define EFI_RT_SUPPORTED_UPDATE_CAPSULE0x0800
+#define EFI_RT_SUPPORTED_QUERY_CAPSULE_CAPABILITIES0x1000
+#define EFI_RT_SUPPORTED_QUERY_VARIABLE_INFO 0x2000
+
struct efi_runtime_services {
struct efi_table_hdr hdr;
efi_status_t (EFIAPI *get_time)(struct efi_time *time,
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 23ce73226762..7bd8002e303e 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -573,6 +573,9 @@ static inline int guidcmp(const efi_guid_t *g1, const
efi_guid_t *g2)
#define __efi_runtime_data __attribute__ ((section (".data.efi_runtime")))
#define __efi_runtime __attribute__ ((section (".text.efi_runtime")))
+/* Indicate supported runtime services */
+efi_status_t efi_init_runtime_supported(void);
+
/* Update CRC32 in table header */
void __efi_runtime efi_update_table_header_crc32(struct efi_table_hdr *table);
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 60442cb21d37..cf202bb9ec07 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -89,6 +89,34 @@ struct elf_rela {
* handle a good number of runtime callbacks
*/
+efi_status_t efi_init_runtime_supported(void)
+{
+ u16 efi_runtime_services_supported;
+
+ /*
+* This value must be synced with efi_runtime_detach_list
+* as well as efi_runtime_services.
+*/
+ efi_runtime_services_supported = EFI_RT_SUPPORTED_RESET_SYSTEM;
+#ifdef CONFIG_EFI_GET_TIME
+ efi_runtime_services_supported |= EFI_RT_SUPPORTED_GET_TIME;
+#endif
+#ifdef CONFIG_EFI_SET_TIME
+ efi_runtime_services_supported |= EFI_RT_SUPPORTED_SET_TIME;
+#endif
+#ifdef CONFIG_EFI_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
+ efi_runtime_services_supported |=
+ EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP;
+#endif
+
+ return EFI_CALL(efi_set_variable(L"RuntimeServicesSupported",
+_global_variable_guid,
+EFI_VARIABLE_BOOTSERVICE_ACCESS |
+EFI_VARIABLE_RUNTIME_ACCESS,
+sizeof(efi_runtime_services_supported),
+_runtime_services_supported));
+}
+
/**
* efi_update_table_header_crc32() - Update crc32 in table header
*
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 45d6aca051f3..75fa344060d5 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -123,6 +123,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;
+ /* Indicate supported runtime services */
+ ret = efi_init_runtime_supported();
+ if (ret != EFI_SUCCESS)
+ goto out;
+
/* Initialize system table */
ret = efi_initialize_system_table();
if (ret != EFI_SUCCESS)
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 4/6] efi_loader: Patch non-runtime code out at ExitBootServices already
From: Alexander Graf
While discussing something completely different, Ard pointed out
that it might be legal to omit calling SetVirtualAddressMap altogether.
There is even a patch on the Linux Kernel Mailing List that implements
such behavior by now:
https://patchwork.kernel.org/patch/10782393/
While that sounds great, we currently rely on the SetVirtualAddressMap
call to remove all references to code that would not work outside of
boot services.
So let's patch out those bits already on the call to ExitBootServices,
so that we can successfully run even when an OS chooses to omit
any call to SetVirtualAddressMap.
Reported-by: Ard Biesheuvel
Signed-off-by: Alexander Graf
OpenBSD is not calling SetVirtualAddressMap on ARM 32 bit.
Adjust selftest: expect 'U-Boot' instead of 'resetting'.
Reviewed-by: Heinrich Schuchardt
---
include/efi_loader.h | 2 ++
lib/efi_loader/efi_boottime.c | 1 +
lib/efi_loader/efi_runtime.c | 25 -
test/py/tests/test_efi_selftest.py | 4 ++--
4 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 7bd8002e303e..93f7ece814a0 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -381,6 +381,8 @@ void efi_save_gd(void);
void efi_restore_gd(void);
/* Call this to relocate the runtime section to an address space */
void efi_runtime_relocate(ulong offset, struct efi_mem_desc *map);
+/* Call this when we start to live in a runtime only world */
+void efi_runtime_detach(ulong offset);
/* Call this to set the current device name */
void efi_set_bootdev(const char *dev, const char *devnr, const char *path);
/* Add a new object to the object list. */
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 7d1d6e92138e..e4abaf3601d9 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1932,6 +1932,7 @@ static efi_status_t EFIAPI
efi_exit_boot_services(efi_handle_t image_handle,
bootm_disable_interrupts();
/* Disable boot time services */
+ efi_runtime_detach((ulong)gd->relocaddr);
systab.con_in_handle = NULL;
systab.con_in = NULL;
systab.con_out_handle = NULL;
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index ff3684a4b692..fc5bdee80e00 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -433,7 +433,7 @@ struct efi_runtime_detach_list_struct {
void *patchto;
};
-static const struct efi_runtime_detach_list_struct efi_runtime_detach_list[] =
{
+static struct efi_runtime_detach_list_struct efi_runtime_detach_list[] = {
{
/* do_reset is gone */
.ptr = _runtime_services.reset_system,
@@ -490,7 +490,15 @@ static bool efi_runtime_tobedetached(void *p)
return false;
}
-static void efi_runtime_detach(ulong offset)
+/**
+ * efi_runtime_detach() - Remove any dependency on non-runtime sections
+ *
+ * This function patches all remaining code to be self-sufficient inside
+ * runtime sections. Any calls to non-runtime will be removed after this.
+ *
+ * @offset:relocaddr for pre-set_v_a_space, offset to VA after
+ */
+__efi_runtime void efi_runtime_detach(ulong offset)
{
int i;
ulong patchoff = offset - (ulong)gd->relocaddr;
@@ -506,6 +514,8 @@ static void efi_runtime_detach(ulong offset)
/* Update CRC32 */
efi_update_table_header_crc32(_runtime_services.hdr);
+
+ invalidate_icache_all();
}
/* Relocate EFI runtime to uboot_reloc_base = offset */
@@ -593,19 +603,25 @@ void efi_runtime_relocate(ulong offset, struct
efi_mem_desc *map)
* @virtmap: virtual address mapping information
* Return: status code
*/
-static efi_status_t EFIAPI efi_set_virtual_address_map(
+static __efi_runtime efi_status_t EFIAPI efi_set_virtual_address_map(
unsigned long memory_map_size,
unsigned long descriptor_size,
uint32_t descriptor_version,
struct efi_mem_desc *virtmap)
{
+ static __efi_runtime_data bool is_patched;
int n = memory_map_size / descriptor_size;
int i;
int rt_code_sections = 0;
+ if (is_patched)
+ return EFI_INVALID_PARAMETER;
+
EFI_ENTRY("%lx %lx %x %p", memory_map_size, descriptor_size,
descriptor_version, virtmap);
+ is_patched = true;
+
/*
* TODO:
* Further down we are cheating. While really we should implement
@@ -681,8 +697,7 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
map->physical_start + gd->relocaddr;
efi_runtime_relocate(new_offset, map);
- /* Once we're virtual, we can no longer handle
- complex callbacks */
+
[U-Boot] [RFC 0/6] efi_loader: support runtime variable access via cache
EBBR v1.0 section 2.5.3 says Even when SetVariable() is not supported during runtime services, firmware should cache variable names and values in EfiRuntimeServicesData memory so that GetVariable() and GetNextVeriableName() can behave as specified. This is an experimental patch set and the aim is to enable this feature. Cache buffer is in the same format as U-Boot environment hash table, but we cannot use functions in hashtable.c partly because most of U-Boot code are not available at UEFI runtime and partly because entries in a table are allocated by malloc(), which are again not available at UEFI runtime. It is quite painful to modify exiting U-Boot code so as to make it executable at UEFI runtime. So I implemented a limited version of hsearch_r(). This may be a discussion. Given that there are not so many UEFI variables, we may want to use a simpler table format for caching. Known issues: * Currently I test this feature with a test which is temporarily embedded in ExitBootServices. * After SetVirtualAddressMap, it won't work (TODO). ConvertPointer was implemented here just for this future work. * So how can we test the feature? We can't use "printenv" command as its relocation won't take place. * I see some Travis CI errors. This is probably due to no storage configured for UEFI variables. Patch#1 to #4 are preparatory patches. Patch#5 is mainly for testing. Patch#6 is core part of this patch set. AKASHI Takahiro (5): efi_loader: runtime: make SetVirtualAddressMap configurable efi: add RuntimeServicesSupported variable efi_loader: support convert_pointer at runtime cmd: efidebug: add "boot exit" sub-command efi_loader: variable: support runtime variable access via cache Alexander Graf (1): efi_loader: Patch non-runtime code out at ExitBootServices already cmd/efidebug.c | 63 include/efi_api.h | 15 + include/efi_loader.h | 22 ++ lib/efi_loader/Kconfig | 24 ++ lib/efi_loader/efi_boottime.c | 11 +- lib/efi_loader/efi_runtime.c | 155 -- lib/efi_loader/efi_setup.c | 5 + lib/efi_loader/efi_variable.c | 467 + test/py/tests/test_efi_selftest.py | 4 +- 9 files changed, 735 insertions(+), 31 deletions(-) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 00/15] Add Support for eMMC in Am65x-evm
On 04/06/19 11:57 PM, Andreas Dannenberg wrote:
> On Tue, Jun 04, 2019 at 09:32:21PM +0530, Lokesh Vutla wrote:
>>
>>
>> On 04/06/19 6:46 PM, Faiz Abbas wrote:
>>> Add Support for eMMC in TI's AM65x-evm. The series starts
>>> by syncing the sdhci0 node from the kernel. Then it adds APIs and
>>> changes to the driver required for handling the driver's integrated
>>> phy. The current maximum supported speed is DDR52. Higher speeds and
>>> tuning support will be added in a subsequent series.
>>>
>>> Changes in v6:
>>> 1. Squashed one more dependency for clk_200mhz from Andreas's patches[1]
>>>into patch 1. Patches now build without any help from the other series.
>>>
>>> 2. Improved line wrapping in patch 8.
>>
>> Thanks for the quick update. For the entire series:
>>
>> Tested-by: Lokesh Vutla
>
> Seems like the test coverage was limited.
>
> While eMMC (sdhci0) works when booting from SD card (sdhci1) the eMMC
> probe fails when booting from eMMC itself defeating the main purpose of
> a series adding eMMC support.
Series talks about the eMMC support and not the eMMC boot support. So I did
verify what is claimed. Anyways it is a valid bug you pointed out.
Faiz,
Can you please re post with the fix incorporated.
Thanks and regards,
Lokesh
>
> "sdhci@4f8 - probe failed: -22"
>
> I did some debugging and tracked this down to a missing drive strength
> setting on the R5 DTS file:
>
>
> $ git diff
> diff --git a/arch/arm/dts/k3-am654-r5-base-board.dts
> b/arch/arm/dts/k3-am654-r5-base-board.dts
> index 2f178c8b07..b10df50ef9 100644
> --- a/arch/arm/dts/k3-am654-r5-base-board.dts
> +++ b/arch/arm/dts/k3-am654-r5-base-board.dts
> @@ -186,6 +186,7 @@
> clock-names = "clk_xin";
> clocks = <_200mhz>;
> /delete-property/ power-domains;
> + ti,driver-strength-ohm = <50>;
> };
>
> {
>
>
> Can we please have this added.
>
>
> With this change added and SYSFW loader series applied I can boot all
> the way to U-Boot prompt on AM654x EVM from eMMC.
>
> Also SYSFW loader series no longer applies on top of this; will re-post
> a rebased/refactored version to be used on top of this series.
>
>
> --
> Andreas Dannenberg
> Texas Instruments Inc
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > container format file > > On 6/5/19 3:59 AM, Peng Fan wrote: > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading > >> i.MX container format file > >> > >> On 6/5/19 3:18 AM, Peng Fan wrote: > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > loading i.MX container format file > > On 6/4/19 5:27 AM, Peng Fan wrote: > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > >> loading i.MX container format file > >> > >> On 5/30/19 9:06 AM, Ye Li wrote: > >>> On 2019/5/27 19:31, Marek Vasut wrote: > Caution: EXT Email > > On 5/27/19 11:49 AM, Peng Fan wrote: > > Hi Marek, Lukasz, > > > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > >> loading i.MX container format file > >> > >> Hi Marek, > >> > >> On 2019/5/22 19:41, Marek Vasut wrote: > >>> Caution: EXT Email > >>> > >>> On 5/22/19 9:34 AM, Lukasz Majewski wrote: > >>> [...] > >> By using above approach we do have the NXP's > >> "container" > >> format only seen in the SPL (which is OK, as for > >> example Samsung does similar thing with FBL/BL1). > >> When > >> SPL is > >> "trused" > >> we may use available facilities. > > > > The issue to me is that sc_seco_authenticate could not > > take a FIT image as input. > > Is the sc_seco_authenticate an API accessible from SPL, > U-Boot proper or Linux crypro engine driver? > >>> > >>> Yes, it is an API accessible in SPL/U-Boot stage. I do > >>> not know about Linux crypto driver. > >> > >> Maybe it would be worth to check how Linux handle this? > >> Maybe it would shed some more light on it? > > > > I am not familiar with that, so might be stupid question > below. > > Does it really matter? > > I would check it just out of curiosity. > >>> > >>> Yes, it matters, because there should be such API. How would > >>> Linux authenticate e.g. userspace binaries if there wasn't > >>> one, surely not by wrapping every single object into the > >>> custom vendor-specific > >> container ? > >>> And if there is one, you can use it to authenticate raw > >>> binaries from U-Boot SPL too, e.g. fitImage blobs with an > >>> associated > signature. > >>> > >> > >> iMX8 AHAB uses RSA key pair for authentication, the on-chip > >> thing we called SRK is a array of public key hash which is > >> dedicated for AHAB. It is not a real key. The real public key > >> is in > >> container. > >> AHAB will check the public key with the on-chip SRK before > >> using it to authenticate the image. > >> Seco which contains the crypto engine on imx8 does not allow > >> to use the SRK by user. No such API exported. > >> And the fuse of SRK is locked, can't be read directly. > >> > >> Actually on imx6/imx7/imx8m, the SPL and u-boot are already > >> using ROM HAB to implement the trust chain, like SPL > >> authenticates u-boot, u-boot authenticatse kernel. We just > >> follow this same way on imx8, the difference is > >> imx8 needs container format for signed image. We prefer > >> directly loading container image than fit image. > >> If we pack fit image into container, obviously this will > >> cause one more > >> copy. > >> As a boot loader, isn't it better to have more image format > >> supported? > > If the functionality of the new image format is a subset of > already present image format, then no, that's called a duplication. > > >> We > >> don't force to use container, just set it as default. Users > >> still can choose fit or raw image. > > They can. however they cannot authenticate the fitImage because > the firmware doesn't provide the necessary API for that ? > > > > > Do you have more comment? > > How could Linux use this iMX8 chain of trust stuff to authenticate > e.g. > userspace binaries ? It's the same thing as authenticating blob > in a fitImage. > > >>> > >>> Userspace binaries don't use the same key pair. They are signed > >>> by software vendors' key. The private key for chip secure boot > >>> is only hold by > >> device manufacturer. > >>> For example, android needs to authenticate a signed APK. Its
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 6/5/19 3:59 AM, Peng Fan wrote: >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX >> container format file >> >> On 6/5/19 3:18 AM, Peng Fan wrote: Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file On 6/4/19 5:27 AM, Peng Fan wrote: >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support >> loading i.MX container format file >> >> On 5/30/19 9:06 AM, Ye Li wrote: >>> On 2019/5/27 19:31, Marek Vasut wrote: Caution: EXT Email On 5/27/19 11:49 AM, Peng Fan wrote: > Hi Marek, Lukasz, > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support >> loading i.MX container format file >> >> Hi Marek, >> >> On 2019/5/22 19:41, Marek Vasut wrote: >>> Caution: EXT Email >>> >>> On 5/22/19 9:34 AM, Lukasz Majewski wrote: >>> [...] >> By using above approach we do have the NXP's >> "container" >> format only seen in the SPL (which is OK, as for >> example Samsung does similar thing with FBL/BL1). >> When >> SPL is >> "trused" >> we may use available facilities. > > The issue to me is that sc_seco_authenticate could not > take a FIT image as input. Is the sc_seco_authenticate an API accessible from SPL, U-Boot proper or Linux crypro engine driver? >>> >>> Yes, it is an API accessible in SPL/U-Boot stage. I do not >>> know about Linux crypto driver. >> >> Maybe it would be worth to check how Linux handle this? >> Maybe it would shed some more light on it? > > I am not familiar with that, so might be stupid question below. > Does it really matter? I would check it just out of curiosity. >>> >>> Yes, it matters, because there should be such API. How would >>> Linux authenticate e.g. userspace binaries if there wasn't >>> one, surely not by wrapping every single object into the >>> custom vendor-specific >> container ? >>> And if there is one, you can use it to authenticate raw >>> binaries from U-Boot SPL too, e.g. fitImage blobs with an >>> associated signature. >>> >> >> iMX8 AHAB uses RSA key pair for authentication, the on-chip >> thing we called SRK is a array of public key hash which is >> dedicated for AHAB. It is not a real key. The real public key is in >> container. >> AHAB will check the public key with the on-chip SRK before >> using it to authenticate the image. >> Seco which contains the crypto engine on imx8 does not allow to >> use the SRK by user. No such API exported. >> And the fuse of SRK is locked, can't be read directly. >> >> Actually on imx6/imx7/imx8m, the SPL and u-boot are already >> using ROM HAB to implement the trust chain, like SPL >> authenticates u-boot, u-boot authenticatse kernel. We just >> follow this same way on imx8, the difference is >> imx8 needs container format for signed image. We prefer >> directly loading container image than fit image. >> If we pack fit image into container, obviously this will cause >> one more >> copy. >> As a boot loader, isn't it better to have more image format >> supported? If the functionality of the new image format is a subset of already present image format, then no, that's called a duplication. >> We >> don't force to use container, just set it as default. Users >> still can choose fit or raw image. They can. however they cannot authenticate the fitImage because the firmware doesn't provide the necessary API for that ? > > Do you have more comment? How could Linux use this iMX8 chain of trust stuff to authenticate e.g. userspace binaries ? It's the same thing as authenticating blob in a fitImage. >>> >>> Userspace binaries don't use the same key pair. They are signed by >>> software vendors' key. The private key for chip secure boot is >>> only hold by >> device manufacturer. >>> For example, android needs to authenticate a signed APK. Its >>> public key (Key >> A) is in system FS. >>> iMX trust chain only reaches to kernel + ramdisk. Then the chain >>> hands over >> to android. >>> In ramdisk, android puts another public Key (Key B) used by >>> dm-verify for system FS. So once system FS is verified ok, then >>> the public key A becomes trusted.
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > container format file > > On 6/5/19 3:18 AM, Peng Fan wrote: > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading > >> i.MX container format file > >> > >> On 6/4/19 5:27 AM, Peng Fan wrote: > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > loading i.MX container format file > > On 5/30/19 9:06 AM, Ye Li wrote: > > On 2019/5/27 19:31, Marek Vasut wrote: > >> Caution: EXT Email > >> > >> On 5/27/19 11:49 AM, Peng Fan wrote: > >>> Hi Marek, Lukasz, > >>> > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > loading i.MX container format file > > Hi Marek, > > On 2019/5/22 19:41, Marek Vasut wrote: > > Caution: EXT Email > > > > On 5/22/19 9:34 AM, Lukasz Majewski wrote: > > [...] > By using above approach we do have the NXP's > "container" > format only seen in the SPL (which is OK, as for > example Samsung does similar thing with FBL/BL1). > When > SPL is > "trused" > we may use available facilities. > >>> > >>> The issue to me is that sc_seco_authenticate could not > >>> take a FIT image as input. > >> > >> Is the sc_seco_authenticate an API accessible from SPL, > >> U-Boot proper or Linux crypro engine driver? > > > > Yes, it is an API accessible in SPL/U-Boot stage. I do not > > know about Linux crypto driver. > > Maybe it would be worth to check how Linux handle this? > Maybe it would shed some more light on it? > >>> > >>> I am not familiar with that, so might be stupid question below. > >>> Does it really matter? > >> > >> I would check it just out of curiosity. > > > > Yes, it matters, because there should be such API. How would > > Linux authenticate e.g. userspace binaries if there wasn't > > one, surely not by wrapping every single object into the > > custom vendor-specific > container ? > > And if there is one, you can use it to authenticate raw > > binaries from U-Boot SPL too, e.g. fitImage blobs with an > > associated > >> signature. > > > > iMX8 AHAB uses RSA key pair for authentication, the on-chip > thing we called SRK is a array of public key hash which is > dedicated for AHAB. It is not a real key. The real public key is in > container. > AHAB will check the public key with the on-chip SRK before > using it to authenticate the image. > Seco which contains the crypto engine on imx8 does not allow to > use the SRK by user. No such API exported. > And the fuse of SRK is locked, can't be read directly. > > Actually on imx6/imx7/imx8m, the SPL and u-boot are already > using ROM HAB to implement the trust chain, like SPL > authenticates u-boot, u-boot authenticatse kernel. We just > follow this same way on imx8, the difference is > imx8 needs container format for signed image. We prefer > directly loading container image than fit image. > If we pack fit image into container, obviously this will cause > one more > copy. > As a boot loader, isn't it better to have more image format > supported? > >> > >> If the functionality of the new image format is a subset of > >> already present image format, then no, that's called a duplication. > >> > We > don't force to use container, just set it as default. Users > still can choose fit or raw image. > >> > >> They can. however they cannot authenticate the fitImage because > >> the firmware doesn't provide the necessary API for that ? > >> > >>> > >>> Do you have more comment? > >> > >> How could Linux use this iMX8 chain of trust stuff to authenticate e.g. > >> userspace binaries ? It's the same thing as authenticating blob > >> in a fitImage. > >> > > > > Userspace binaries don't use the same key pair. They are signed by > > software vendors' key. The private key for chip secure boot is > > only hold by > device manufacturer. > > For example, android needs to authenticate a signed APK. Its > > public key (Key > A) is in system FS. > > iMX trust chain only reaches to kernel + ramdisk. Then the chain > > hands over > to android. > > In ramdisk, android puts another public Key (Key B) used by > > dm-verify for system FS. So once system FS is verified ok, then > > the public key A becomes trusted. Finally we can use public key A > >
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
On 6/5/19 3:18 AM, Peng Fan wrote: >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX >> container format file >> >> On 6/4/19 5:27 AM, Peng Fan wrote: Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file On 5/30/19 9:06 AM, Ye Li wrote: > On 2019/5/27 19:31, Marek Vasut wrote: >> Caution: EXT Email >> >> On 5/27/19 11:49 AM, Peng Fan wrote: >>> Hi Marek, Lukasz, >>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file Hi Marek, On 2019/5/22 19:41, Marek Vasut wrote: > Caution: EXT Email > > On 5/22/19 9:34 AM, Lukasz Majewski wrote: > [...] By using above approach we do have the NXP's "container" format only seen in the SPL (which is OK, as for example Samsung does similar thing with FBL/BL1). When SPL is "trused" we may use available facilities. >>> >>> The issue to me is that sc_seco_authenticate could not >>> take a FIT image as input. >> >> Is the sc_seco_authenticate an API accessible from SPL, >> U-Boot proper or Linux crypro engine driver? > > Yes, it is an API accessible in SPL/U-Boot stage. I do not > know about Linux crypto driver. Maybe it would be worth to check how Linux handle this? Maybe it would shed some more light on it? >>> >>> I am not familiar with that, so might be stupid question below. >>> Does it really matter? >> >> I would check it just out of curiosity. > > Yes, it matters, because there should be such API. How would > Linux authenticate e.g. userspace binaries if there wasn't one, > surely not by wrapping every single object into the custom > vendor-specific container ? > And if there is one, you can use it to authenticate raw binaries > from U-Boot SPL too, e.g. fitImage blobs with an associated >> signature. > iMX8 AHAB uses RSA key pair for authentication, the on-chip thing we called SRK is a array of public key hash which is dedicated for AHAB. It is not a real key. The real public key is in container. AHAB will check the public key with the on-chip SRK before using it to authenticate the image. Seco which contains the crypto engine on imx8 does not allow to use the SRK by user. No such API exported. And the fuse of SRK is locked, can't be read directly. Actually on imx6/imx7/imx8m, the SPL and u-boot are already using ROM HAB to implement the trust chain, like SPL authenticates u-boot, u-boot authenticatse kernel. We just follow this same way on imx8, the difference is imx8 needs container format for signed image. We prefer directly loading container image than fit image. If we pack fit image into container, obviously this will cause one more copy. As a boot loader, isn't it better to have more image format supported? >> >> If the functionality of the new image format is a subset of already >> present image format, then no, that's called a duplication. >> We don't force to use container, just set it as default. Users still can choose fit or raw image. >> >> They can. however they cannot authenticate the fitImage because the >> firmware doesn't provide the necessary API for that ? >> >>> >>> Do you have more comment? >> >> How could Linux use this iMX8 chain of trust stuff to authenticate e.g. >> userspace binaries ? It's the same thing as authenticating blob in >> a fitImage. >> > > Userspace binaries don't use the same key pair. They are signed by > software vendors' key. The private key for chip secure boot is only > hold by device manufacturer. > For example, android needs to authenticate a signed APK. Its public > key (Key A) is in system FS. > iMX trust chain only reaches to kernel + ramdisk. Then the chain > hands over to android. > In ramdisk, android puts another public Key (Key B) used by > dm-verify for system FS. So once system FS is verified ok, then the > public key A becomes trusted. Finally we can use public key A for APK >> authentication. So can we put a public key into the SPL and use it to verify a fitImage ? >>> >>> Technically doable. But compared with the current approach that reuse >>> ROM public API, Using crypto driver in SPL will be complicated and >>> code size larger without calling ROM API. >>> >>> I do not understand the problem the SPL loading NXP
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > container format file > > On 6/4/19 5:27 AM, Peng Fan wrote: > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading > >> i.MX container format file > >> > >> On 5/30/19 9:06 AM, Ye Li wrote: > >>> On 2019/5/27 19:31, Marek Vasut wrote: > Caution: EXT Email > > On 5/27/19 11:49 AM, Peng Fan wrote: > > Hi Marek, Lukasz, > > > >> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > >> loading i.MX container format file > >> > >> Hi Marek, > >> > >> On 2019/5/22 19:41, Marek Vasut wrote: > >>> Caution: EXT Email > >>> > >>> On 5/22/19 9:34 AM, Lukasz Majewski wrote: > >>> [...] > >> By using above approach we do have the NXP's "container" > >> format only seen in the SPL (which is OK, as for example > >> Samsung does similar thing with FBL/BL1). When SPL is > >> "trused" > >> we may use available facilities. > > > > The issue to me is that sc_seco_authenticate could not > > take a FIT image as input. > > Is the sc_seco_authenticate an API accessible from SPL, > U-Boot proper or Linux crypro engine driver? > >>> > >>> Yes, it is an API accessible in SPL/U-Boot stage. I do not > >>> know about Linux crypto driver. > >> > >> Maybe it would be worth to check how Linux handle this? Maybe > >> it would shed some more light on it? > > > > I am not familiar with that, so might be stupid question below. > > Does it really matter? > > I would check it just out of curiosity. > >>> > >>> Yes, it matters, because there should be such API. How would > >>> Linux authenticate e.g. userspace binaries if there wasn't one, > >>> surely not by wrapping every single object into the custom > >>> vendor-specific > >> container ? > >>> And if there is one, you can use it to authenticate raw binaries > >>> from U-Boot SPL too, e.g. fitImage blobs with an associated > signature. > >>> > >> > >> iMX8 AHAB uses RSA key pair for authentication, the on-chip thing > >> we called SRK is a array of public key hash which is dedicated > >> for AHAB. It is not a real key. The real public key is in container. > >> AHAB will check the public key with the on-chip SRK before using > >> it to authenticate the image. > >> Seco which contains the crypto engine on imx8 does not allow to > >> use the SRK by user. No such API exported. > >> And the fuse of SRK is locked, can't be read directly. > >> > >> Actually on imx6/imx7/imx8m, the SPL and u-boot are already using > >> ROM HAB to implement the trust chain, like SPL authenticates > >> u-boot, u-boot authenticatse kernel. We just follow this same way > >> on imx8, the difference is > >> imx8 needs container format for signed image. We prefer directly > >> loading container image than fit image. > >> If we pack fit image into container, obviously this will cause > >> one more > >> copy. > >> As a boot loader, isn't it better to have more image format supported? > > If the functionality of the new image format is a subset of already > present image format, then no, that's called a duplication. > > >> We > >> don't force to use container, just set it as default. Users still > >> can choose fit or raw image. > > They can. however they cannot authenticate the fitImage because the > firmware doesn't provide the necessary API for that ? > > > > > Do you have more comment? > > How could Linux use this iMX8 chain of trust stuff to authenticate e.g. > userspace binaries ? It's the same thing as authenticating blob in > a fitImage. > > >>> > >>> Userspace binaries don't use the same key pair. They are signed by > >>> software vendors' key. The private key for chip secure boot is only > >>> hold by > >> device manufacturer. > >>> For example, android needs to authenticate a signed APK. Its public > >>> key (Key > >> A) is in system FS. > >>> iMX trust chain only reaches to kernel + ramdisk. Then the chain > >>> hands over > >> to android. > >>> In ramdisk, android puts another public Key (Key B) used by > >>> dm-verify for system FS. So once system FS is verified ok, then the > >>> public key A becomes trusted. Finally we can use public key A for APK > authentication. > >> > >> So can we put a public key into the SPL and use it to verify a fitImage ? > > > > Technically doable. But compared with the current approach that reuse > > ROM public API, Using crypto driver in SPL will be complicated and > > code size larger without calling ROM API. > > > > I do not understand the problem the SPL loading NXP i.MX8 container > format. > > SPL should
Re: [U-Boot] [PATCH] arm: ls1028a: define the integrated PCI bus (ECAM)
Hi Alex,
On Tue, Jun 4, 2019 at 9:59 PM Alex Marginean wrote:
>
> Hi Bin,
>
> On 6/2/2019 5:22 PM, Bin Meng wrote:
> > Hi Alex,
> >
> > On Fri, May 31, 2019 at 12:27 AM Alex Marginean
> > wrote:
> >>
> >> LS1028A includes an integrated PCI bus with 8M of ECAM space plus register
> >> space for the integrated devices. This integrated PCI bus is driven using
> >> the generic ECAM driver.
> >>
> >> Signed-off-by: Alex Marginean
> >> ---
> >> arch/arm/dts/fsl-ls1028a.dtsi | 10 ++
> >> arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 2 ++
> >> arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h | 2 ++
> >> configs/ls1028aqds_tfa_defconfig | 1 +
> >> configs/ls1028ardb_tfa_defconfig | 1 +
> >> 5 files changed, 16 insertions(+)
> >>
> >> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
> >> index e6a443aa77..263c29af23 100644
> >> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> >> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> >> @@ -108,6 +108,16 @@
> >> 0x8200 0x0 0x4000 0x88 0x4000 0x0
> >> 0x4000>; /* non-prefetchable memory */
> >> };
> >>
> >> + pcie@1f000 {
> >> + compatible = "pci-host-ecam-generic";
> >> + reg = <0x01 0xf000 0x0 0x10>;
> >> + #address-cells = <3>;
> >> + #size-cells = <2>;
> >> + device_type = "pci";
> >> + bus-range = <0x0 0x0>;
> >
> > I think this should be <0x0 0x7> since you mentioned in the commit
> > message that only an 8M ECAM space is allocated.
>
> I think I was looking at the wrong spec, it seems the platform actually
> has 256MB of address space reserved for ECAM. It's not all implemented
> of course, in fact all the devices we care about in u-boot are on bus 0.
> Anyway, I can just remove bus-range, the default is 0-255 and that does
> match the HW.
>
> >
> >> + ranges= <0x8200 0x0 0x 0x1 0xf800 0x0
> >> 0x16>;
> >> + };
> >> +
> >> i2c0: i2c@200 {
> >> compatible = "fsl,vf610-i2c";
> >> #address-cells = <1>;
> >> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> >> b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> >> index bdeb62576c..7759acdb8f 100644
> >> --- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> >> +++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
> >> @@ -42,7 +42,9 @@
> >> #else
> >> #define CONFIG_SYS_PCIE1_PHYS_SIZE 0x8
> >> #define CONFIG_SYS_PCIE2_PHYS_SIZE 0x8
> >> +#ifndef CONFIG_SYS_PCIE3_PHYS_SIZE
> >> #define CONFIG_SYS_PCIE3_PHYS_SIZE 0x8
> >> +#endif
> >> #define CONFIG_SYS_PCIE4_PHYS_SIZE 0x8
> >> #define SYS_PCIE5_PHYS_SIZE0x8
> >> #define SYS_PCIE6_PHYS_SIZE0x8
> >> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> >> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> >> index 24c1b0e482..273157230f 100644
> >> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> >> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> >> @@ -186,6 +186,8 @@
> >> #elif CONFIG_ARCH_LS1028A
> >> #define CONFIG_SYS_PCIE1_PHYS_ADDR 0x80ULL
> >> #define CONFIG_SYS_PCIE2_PHYS_ADDR 0x88ULL
> >> +#define CONFIG_SYS_PCIE3_PHYS_ADDR 0x01f000ULL
> >> +#define CONFIG_SYS_PCIE3_PHYS_SIZE 0x001000ULL
> >
> > DT says the size is 0x10. This does not match.
>
> I'll extend reg to 256MB along with removing bus-range.
>
> > These macros really look to me this platform is still using lots of
> > non-DM approaches when it comes to driver support. These hard coded
> > values should really be dropped and retrieved from DT instead via
> > proper DM drivers.
>
> ECAM is driven by the ecam generic host driver and it doesn't care about
> these macros.
> These are used int arch/arm/cpu/armv8/fsl-layerscape/cpu.c to set up
> the MMU at boot though, accessing ECAM doesn't work without them.
Yes, but what I was trying to say that with driver model things like
register base and size should be retrieved from DT. Can we consider
doing an ARMv8 DM MMU driver that reads DT and set up the page table
for everything?
Simon/Tom, do you have any better ideas?
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/7] efi_loader: load saved non-volatile variables at init
On Tue, Jun 04, 2019 at 11:38:27PM +0200, Heinrich Schuchardt wrote: > On 6/4/19 8:52 AM, AKASHI Takahiro wrote: > >Data cache will be read in from persistent storage after (re)boot > >to restore UEFI non-volatile variables. > > > >Signed-off-by: AKASHI Takahiro > >--- > > lib/efi_loader/efi_setup.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > >diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c > >index 8691d686d29d..45d6aca051f3 100644 > >--- a/lib/efi_loader/efi_setup.c > >+++ b/lib/efi_loader/efi_setup.c > >@@ -8,6 +8,7 @@ > > #include > > #include > > #include > >+#include > > > > #define OBJ_LIST_NOT_INITIALIZED 1 > > > >@@ -102,6 +103,11 @@ efi_status_t efi_init_obj_list(void) > > /* On ARM switch from EL3 or secure mode to EL2 or non-secure mode */ > > switch_to_non_secure_mode(); > > > >+#ifdef CONFIG_EFI_VARIABLE_USE_ENV > > No clue what ENV refers to here as we are not talking about U-Boot > environment variables anymore. How about CONFIG_EFI_PERSISTENT_VARIABLES. It will be trivial once you take a look at "menuconfig." > > >+/* Load non-volatile variables */ > >+env_efi_load(); > > Can't we make env_efi_load() a __weak function which does nothing. If we > have a backend, that backend replaces the weak function. That way we > restrict the config variables to the Makefile. This is a discussion. There can be different approaches here, so I would like to deter to a developer who will implement a next backing storage (other than U-Boot env), which is likely to be Standalone MM services for secure boot. Unfortunately I'm not responsible for that(StMM). I hope that some Linaro engineers may have comments here. Thanks, -Takahiro Akashi > Regards > > Heinrich > > >+#endif > >+ > > /* Define supported languages */ > > ret = efi_init_platform_lang(); > > if (ret != EFI_SUCCESS) > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] efi_loader: variable: split UEFI variables from U-Boot environment
On Tue, Jun 04, 2019 at 11:31:24PM +0200, Heinrich Schuchardt wrote:
> On 6/4/19 8:52 AM, AKASHI Takahiro wrote:
> >UEFI volatile variables are managed in efi_var_htab while UEFI non-volatile
> >variables are in efi_nv_var_htab. At every SetVariable API, env_efi_save()
> >will also be called to save data cache (hash table) to persistent storage.
> >
> >Signed-off-by: AKASHI Takahiro
> >---
> > lib/efi_loader/Kconfig| 10 +
> > lib/efi_loader/efi_variable.c | 342 ++
> > 2 files changed, 275 insertions(+), 77 deletions(-)
> >
> >diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> >index cd5436c576b1..8bf4b1754d06 100644
> >--- a/lib/efi_loader/Kconfig
> >+++ b/lib/efi_loader/Kconfig
> >@@ -18,6 +18,16 @@ config EFI_LOADER
> >
> > if EFI_LOADER
> >
> >+choice
> >+prompt "Select variables storage"
> >+default EFI_VARIABLE_USE_ENV
> >+
> >+config EFI_VARIABLE_USE_ENV
> >+bool "Same device as U-Boot environment"
> >+select ENV_EFI
> >+
> >+endchoice
> >+
> > config EFI_GET_TIME
> > bool "GetTime() runtime service"
> > depends on DM_RTC
> >diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
> >index e56053194dae..d9887be938c2 100644
> >--- a/lib/efi_loader/efi_variable.c
> >+++ b/lib/efi_loader/efi_variable.c
> >@@ -48,6 +48,66 @@
> > * converted to utf16?
> > */
> >
> >+/*
> >+ * We will maintain two variable database: one for volatile variables,
> >+ * the other for non-volatile variables. The former exists only in memory
> >+ * and will go away at re-boot. The latter is currently backed up by the
> >same
> >+ * device as U-Boot environment and also works as variables cache.
> >+ *
> >+ * struct hsearch_data efi_var_htab
> >+ * struct hsearch_data efi_nv_var_htab
> >+ */
> >+
> >+static char *env_efi_get(const char *name, bool is_non_volatile)
> >+{
> >+struct hsearch_data *htab;
> >+ENTRY e, *ep;
> >+
> >+/* WATCHDOG_RESET(); */
> >+
> >+if (is_non_volatile)
> >+htab = _nv_var_htab;
> >+else
> >+htab = _var_htab;
> >+
> >+e.key = name;
> >+e.data = NULL;
> >+hsearch_r(e, FIND, , htab, 0);
> >+
> >+return ep ? ep->data : NULL;
> >+}
> >+
> >+static int env_efi_set(const char *name, const char *value,
> >+ bool is_non_volatile)
> >+{
> >+struct hsearch_data *htab;
> >+ENTRY e, *ep;
> >+int ret;
> >+
> >+if (is_non_volatile)
> >+htab = _nv_var_htab;
> >+else
> >+htab = _var_htab;
> >+
> >+/* delete */
> >+if (!value || *value == '\0') {
> >+ret = hdelete_r(name, htab, H_PROGRAMMATIC);
> >+return !ret;
> >+}
> >+
> >+/* set */
> >+e.key = name;
> >+e.data = (char *)value;
> >+hsearch_r(e, ENTER, , htab, H_PROGRAMMATIC);
> >+if (!ep) {
> >+printf("## Error inserting \"%s\" variable, errno=%d\n",
> >+ name, errno);
> >+return 1;
> >+}
> >+
> >+return 0;
> >+}
> >+
> > #define PREFIX_LEN (strlen("efi_----_"))
> >
> > /**
> >@@ -147,24 +207,12 @@ static const char *parse_attr(const char *str, u32
> >*attrp)
> > return str;
> > }
> >
> >-/**
> >- * efi_efi_get_variable() - retrieve value of a UEFI variable
> >- *
> >- * This function implements the GetVariable runtime service.
> >- *
> >- * See the Unified Extensible Firmware Interface (UEFI) specification for
> >- * details.
> >- *
> >- * @variable_name: name of the variable
> >- * @vendor: vendor GUID
> >- * @attributes: attributes of the variable
> >- * @data_size: size of the buffer to which the variable value
> >is copied
> >- * @data: buffer to which the variable value is copied
> >- * Return: status code
> >- */
> >-efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
> >- const efi_guid_t *vendor, u32 *attributes,
> >- efi_uintn_t *data_size, void *data)
> >+static
> >+efi_status_t EFIAPI efi_get_variable_common(u16 *variable_name,
> >+const efi_guid_t *vendor,
> >+u32 *attributes,
> >+efi_uintn_t *data_size, void *data,
> >+bool is_non_volatile)
> > {
> > char *native_name;
> > efi_status_t ret;
> >@@ -172,22 +220,19 @@ efi_status_t EFIAPI efi_get_variable(u16
> >*variable_name,
> > const char *val, *s;
> > u32 attr;
> >
> >-EFI_ENTRY("\"%ls\" %pUl %p %p %p", variable_name, vendor, attributes,
> >- data_size, data);
> >-
> > if (!variable_name || !vendor || !data_size)
> > return EFI_EXIT(EFI_INVALID_PARAMETER);
> >
> > ret = efi_to_native(_name, variable_name, vendor);
> > if (ret)
> >-return EFI_EXIT(ret);
> >+return ret;
Re: [U-Boot] [PATCH v3 1/7] env: save UEFI non-volatile variables in dedicated storage
On Tue, Jun 04, 2019 at 11:09:56PM +0200, Heinrich Schuchardt wrote: > On 6/4/19 8:52 AM, AKASHI Takahiro wrote: > >We need a variant of env_save()/env_load() to handle dedicated storage > >for UEFI variables. > >It is assumed that env_efi_load() will be called only ince at init > >and that env_efi_save() will be called at every SetVariable. > > > >In this patch, new parameters will be expected to be configured: > > CONFIG_ENV_EFI_FAT_DEVICE_AND_PART > > CONFIG_ENV_EFI_FAT_FILE > >in case of CONFIG_ENV_IS_IN_FAT. > > > >Signed-off-by: AKASHI Takahiro > >--- > > env/Kconfig | 39 > > env/env.c | 155 +- > > env/fat.c | 105 > > include/asm-generic/global_data.h | 3 + > > include/environment.h | 31 ++ > > 5 files changed, 332 insertions(+), 1 deletion(-) > > > >diff --git a/env/Kconfig b/env/Kconfig > >index 1e10c7a4c46b..a36b6ee48f10 100644 > >--- a/env/Kconfig > >+++ b/env/Kconfig > >@@ -399,6 +399,10 @@ config ENV_IS_IN_UBI > > the environment in. This will enable redundant environments in UBI. > > It is assumed that both volumes are in the same MTD partition. > > > > Our store will be completely unrelated to U-Boot environment variables. > So why should we put anything into this Kconfig? This is a discussion. Some of my code still mimics the logic of U-Boot environment, for instance, backing driver lookup. I think that U-Boot maintainers may want U-Boot and UEFI code to stay as close as possible. > >+config ENV_EFI > >+bool > >+default n > >+ > > config ENV_FAT_INTERFACE > > string "Name of the block device for the environment" > > depends on ENV_IS_IN_FAT > >@@ -438,6 +442,34 @@ config ENV_FAT_FILE > > It's a string of the FAT file name. This file use to store the > > environment. > > > >+config ENV_EFI_FAT_DEVICE_AND_PART > >+string "Device and partition for where to store the UEFI non-volatile > >variables in FAT" > >+depends on ENV_IS_IN_FAT > >+depends on ENV_EFI > >+help > >+ Define this to a string to specify the partition of the device. It can > >+ be as following: > > The following information is not specific to this variable. So we can > cut it short: > > "String defining the device number and the partition number in the > format :, e.g. 0:1." The text is just a copy of the one as for CONFIG_ENV_FAT_DEVICE_AND_PART. This is another reason that I put the code under "env." After your comment, the text can be modified as it refers to CONFIG_ENV_FAT_DEVICE_AND_PART for details. > > Where do you specify on which subsystem (mmc, scsi, sata, nvme) the file > is stored? Haven't you read the cover letter? Please read it first. I always try to put bunch of information regarding my patch there. > I would prefer nopt to have a restriction to FAT. If the EXT4 driver is > enabled writing and reading to an ext4 valume should work as well. When > calling fs_set_blk_dev() you will not specify any file system. I remember that I have answered this comment before: This is just an example for backing storage. It is a matter of time to support other devices as U-Boot environment does. This is another reason that I put the code under "env." > >+ > >+"D:P", "D:0", "D", "D:" or "D:auto" (D, P are integers. And P >= 1) > >+ - "D:P": device D partition P. Error occurs if device D has no > >+partition table. > >+ - "D:0": device D. > >+ - "D" or "D:": device D partition 1 if device D has partition > >+ table, or the whole device D if has no partition > >+ table. > >+ - "D:auto": first partition in device D with bootable flag set. > >+ If none, first valid partition in device D. If no > >+ partition table then means device D. > >+ > >+config ENV_EFI_FAT_FILE > >+string "Name of the FAT file to use for the UEFI non-volatile variables" > > %s/UEFI non-volatile variables/non-volatile UEFI variables/ > > No need for the file system being FAT. ditto. > >+depends on ENV_IS_IN_FAT > >+depends on ENV_EFI > >+default "uboot_efi.env" > >+help > >+ It's a string of the FAT file name. This file use to store the > > It is obvious that afile name is a string. But why restrict to a file > name? This could also be a path to a non-root file: Again, this is a copy from CONFIG_ENV_FAT_FILE. > "Path of the file used to store non-volatile UEFI variables." > > But can't we simply have a single variable, where we put all parts of > the definition, e.g. > > mmc 0:1 /EFI/nv-var.store Again, my code follows U-Boot's configuration style. > >+ UEFI non-volatile variables. > >+ > > config ENV_EXT4_INTERFACE > > string "Name of the block device for the environment" > > depends on ENV_IS_IN_EXT4 > >@@ -470,6
[U-Boot] [PATCH v3 15/18] ti: common: am6: Add support for setting MAC addresses
The AM654x EVM based on the TI K3 family of SoCs has an updated board
detection EEPROM structure that contains a TLV record of dedicated MAC
addresses rather than a range of MAC addresses as it was used on earlier
platforms such as DRA7. Add a basic function that allows us setting up
Ethernet MAC addresses into the U-Boot environment based on the MAC
address record contained in the common TI EEPROM structure.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
board/ti/common/board_detect.c | 32
board/ti/common/board_detect.h | 12
2 files changed, 44 insertions(+)
diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index fea39f21e8..32fa10599e 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -534,6 +534,25 @@ fail:
memset(mac_addr, 0, TI_EEPROM_HDR_ETH_ALEN);
}
+void __maybe_unused
+board_ti_am6_get_eth_mac_addr(int index,
+ u8 mac_addr[TI_EEPROM_HDR_ETH_ALEN])
+{
+ struct ti_am6_eeprom *ep = TI_AM6_EEPROM_DATA;
+
+ if (ep->header == TI_DEAD_EEPROM_MAGIC)
+ goto fail;
+
+ if (index < 0 || index >= ep->mac_addr_cnt)
+ goto fail;
+
+ memcpy(mac_addr, ep->mac_addr[index], TI_EEPROM_HDR_ETH_ALEN);
+ return;
+
+fail:
+ memset(mac_addr, 0, TI_EEPROM_HDR_ETH_ALEN);
+}
+
u64 __maybe_unused board_ti_get_emif1_size(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
@@ -667,6 +686,19 @@ void board_ti_set_ethaddr(int index)
}
}
+void board_ti_am6_set_ethaddr(int index, int count)
+{
+ u8 mac_addr[6];
+ int i;
+
+ for (i = 0; i < count; i++) {
+ board_ti_am6_get_eth_mac_addr(i, mac_addr);
+ if (is_valid_ethaddr(mac_addr))
+ eth_env_set_enetaddr_by_index("eth", i + index,
+ mac_addr);
+ }
+}
+
bool __maybe_unused board_ti_was_eeprom_read(void)
{
struct ti_common_eeprom *ep = TI_EEPROM_DATA;
diff --git a/board/ti/common/board_detect.h b/board/ti/common/board_detect.h
index bf563c84c8..a45d8961b9 100644
--- a/board/ti/common/board_detect.h
+++ b/board/ti/common/board_detect.h
@@ -398,6 +398,18 @@ void set_board_info_env_am6(char *name);
*/
void board_ti_set_ethaddr(int index);
+/**
+ * board_ti_am6_set_ethaddr- Sets the ethaddr environment from EEPROM
+ * @index: The first ethaddr environment variable to set
+ * @count: The number of MAC addresses to process
+ *
+ * EEPROM should be already read before calling this function. The EEPROM
+ * contains n dedicated MAC addresses. This function sets the ethaddr
+ * environment variable for all the available MAC addresses starting
+ * from ethaddr.
+ */
+void board_ti_am6_set_ethaddr(int index, int count);
+
/**
* board_ti_was_eeprom_read() - Check to see if the eeprom contents have been
read
*
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 18/18] configs: am65x_hs_evm: Add support for applying overlays
This will allow for downloading and applying overlays from an MMC/SD
boot media based on the overlay_files ENV variable containing a list
of overlay files.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
configs/am65x_hs_evm_a53_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configs/am65x_hs_evm_a53_defconfig
b/configs/am65x_hs_evm_a53_defconfig
index 7d7a673714..56052f73f3 100644
--- a/configs/am65x_hs_evm_a53_defconfig
+++ b/configs/am65x_hs_evm_a53_defconfig
@@ -19,7 +19,7 @@ CONFIG_FIT_IMAGE_POST_PROCESS=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL_TEXT_BASE=0x8008
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
@@ -85,3 +85,4 @@ CONFIG_SOC_TI=y
CONFIG_SYSRESET=y
CONFIG_SPL_SYSRESET=y
CONFIG_SYSRESET_TI_SCI=y
+CONFIG_OF_LIBFDT_OVERLAY=y
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 13/18] arm: K3: am654: Map common EEPROM data into SRAM scratch space
The board detection scheme employed on various TI EVMs makes use of SRAM scratch space to share data read from an on-board EEPROM between the different bootloading stages. Map the associated definition that's used to locate this data into the SRAM scratch space we use on AM654x. Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla --- arch/arm/mach-k3/include/mach/am6_hardware.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h b/arch/arm/mach-k3/include/mach/am6_hardware.h index 3343233aa3..6df7631545 100644 --- a/arch/arm/mach-k3/include/mach/am6_hardware.h +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h @@ -44,4 +44,7 @@ #define CTRLMMR_LOCK_KICK1 0x0100c #define CTRLMMR_LOCK_KICK1_UNLOCK_VAL 0xd172bc5a +/* MCU SCRATCHPAD usage */ +#define TI_SRAM_SCRATCH_BOARD_EEPROM_START CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE + #endif /* __ASM_ARCH_AM6_HARDWARE_H */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 09/18] configs: am65x_evm_a53: Enable PCA953X-type GPIO driver
Enable GPIO driver for PCA953X-compatible I2C-based I/O expander which includes support for the TCA9554/PCA9554-type expander found on the AM654 EVM base board. Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla --- configs/am65x_evm_a53_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index 1459512b15..5fa7a7e657 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -56,6 +56,8 @@ CONFIG_CLK_TI_SCI=y CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y +CONFIG_DM_GPIO=y +CONFIG_DM_PCA953X=y CONFIG_DM_I2C=y CONFIG_I2C_SET_DEFAULT_BUS_NUM=y CONFIG_SYS_I2C_OMAP24XX=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 06/18] configs: am65x_evm_defconfig: Enable I2C support
Enable I2C via driver model as well as the associated set of U-Boot commands to allow us interacting with various I2C slave devices. Signed-off-by: Andreas Dannenberg Signed-off-by: Vignesh R Reviewed-by: Lokesh Vutla --- configs/am65x_evm_a53_defconfig | 4 configs/am65x_evm_r5_defconfig | 4 2 files changed, 8 insertions(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index d5f8a01fae..1459512b15 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -33,6 +33,7 @@ CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_ASKENV=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPT=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_REMOTEPROC=y # CONFIG_CMD_SETEXPR is not set @@ -55,6 +56,9 @@ CONFIG_CLK_TI_SCI=y CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y +CONFIG_DM_I2C=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y +CONFIG_SYS_I2C_OMAP24XX=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y CONFIG_DM_MMC=y diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig index d81018b31d..7e81a98454 100644 --- a/configs/am65x_evm_r5_defconfig +++ b/configs/am65x_evm_r5_defconfig @@ -37,6 +37,7 @@ CONFIG_CMD_BOOTZ=y CONFIG_CMD_ASKENV=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPT=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_REMOTEPROC=y # CONFIG_CMD_SETEXPR is not set @@ -62,6 +63,9 @@ CONFIG_CLK_TI_SCI=y CONFIG_TI_SCI_PROTOCOL=y CONFIG_DM_GPIO=y CONFIG_DA8XX_GPIO=y +CONFIG_DM_I2C=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y +CONFIG_SYS_I2C_OMAP24XX=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y CONFIG_MISC=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 16/18] board: ti: am654: Use EEPROM-based board detection
The TI AM654x EVM base board and the associated daughtercards have on-
board I2C-based EEPROMs containing board configuration data. Use the
board detection infrastructure introduced earlier to do the following:
1) Parse the AM654x EVM base board EEPROM and populate items like board
name and MAC addresses into the TI common EEPROM data structure
residing in SRAM scratch space
2) Check for presence of daughter card(s) by probing the associated
presence signals via an I2C-based GPIO expander. Then, if such a
card is found, parse the data such as additional Ethernet MAC
addresses from its on-board EEPROM and populate into U-Boot
accordingly
3) Dynamically create an U-Boot ENV variable called overlay_files
containing a list of daugherboard-specific DTB overlays based on
daughercards found.
This patch adds support for the AM654x base board ("AM6-COMPROCEVM")
as well as for the IDK ("AM6-IDKAPPEVM"), OLDI LCD ("OLDI-LCD1EVM")
PCIe/USB3.0 ("SER-PCIEUSBEVM"), 2 Lane PCIe/USB2.0 ("SER-PCIE2LEVM"),
and general purpuse ("AM6-GPAPPEVM") daughtercards.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
arch/arm/mach-k3/am6_init.c | 4 +
arch/arm/mach-k3/include/mach/sys_proto.h | 2 +
board/ti/am65x/Kconfig| 7 +
board/ti/am65x/evm.c | 241 ++
include/configs/am65x_evm.h | 9 +-
5 files changed, 257 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index e326f575e5..cb96581bfb 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "common.h"
#include
#include
@@ -111,6 +112,9 @@ void board_init_f(ulong dummy)
preloader_console_init();
#endif
+ /* Perform EEPROM-based board detection */
+ do_board_detect();
+
#ifdef CONFIG_K3_AM654_DDRSS
ret = uclass_get_device(UCLASS_RAM, 0, );
if (ret)
diff --git a/arch/arm/mach-k3/include/mach/sys_proto.h
b/arch/arm/mach-k3/include/mach/sys_proto.h
index 018725b4d1..787a274492 100644
--- a/arch/arm/mach-k3/include/mach/sys_proto.h
+++ b/arch/arm/mach-k3/include/mach/sys_proto.h
@@ -12,4 +12,6 @@ u32 wait_on_value(u32 read_bit_mask, u32 match_value, void
*read_addr,
u32 bound);
struct ti_sci_handle *get_ti_sci_handle(void);
int fdt_fixup_msmc_ram(void *blob, char *parent_path, char *node_name);
+int do_board_detect(void);
+
#endif
diff --git a/board/ti/am65x/Kconfig b/board/ti/am65x/Kconfig
index 60bb834aca..47b41cd6af 100644
--- a/board/ti/am65x/Kconfig
+++ b/board/ti/am65x/Kconfig
@@ -12,6 +12,8 @@ config TARGET_AM654_A53_EVM
select ARM64
select SOC_K3_AM6
select SYS_DISABLE_DCACHE_OPS
+ select BOARD_LATE_INIT
+ imply TI_I2C_BOARD_DETECT
config TARGET_AM654_R5_EVM
bool "TI K3 based AM654 EVM running on R5"
@@ -21,6 +23,7 @@ config TARGET_AM654_R5_EVM
select K3_LOAD_SYSFW
select K3_AM654_DDRSS
imply SYS_K3_SPL_ATF
+ imply TI_I2C_BOARD_DETECT
endchoice
@@ -35,6 +38,8 @@ config SYS_VENDOR
config SYS_CONFIG_NAME
default "am65x_evm"
+source "board/ti/common/Kconfig"
+
endif
if TARGET_AM654_R5_EVM
@@ -51,4 +56,6 @@ config SYS_CONFIG_NAME
config SPL_LDSCRIPT
default "arch/arm/mach-omap2/u-boot-spl.lds"
+source "board/ti/common/Kconfig"
+
endif
diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index 52f5d6b11e..7bd8c4fa66 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -8,10 +8,31 @@
*/
#include
+#include
+#include
+#include
+#include
#include
+#include
#include
#include
+#include "../common/board_detect.h"
+
+#define board_is_am65x_base_board()board_ti_is("AM6-COMPROCEVM")
+
+/* Daughter card presence detection signals */
+enum {
+ AM65X_EVM_APP_BRD_DET,
+ AM65X_EVM_LCD_BRD_DET,
+ AM65X_EVM_SERDES_BRD_DET,
+ AM65X_EVM_HDMI_GPMC_BRD_DET,
+ AM65X_EVM_BRD_DET_COUNT,
+};
+
+/* Max number of MAC addresses that are parsed/processed per daughter card */
+#define DAUGHTER_CARD_NO_OF_MAC_ADDR 8
+
DECLARE_GLOBAL_DATA_PTR;
int board_init(void)
@@ -80,3 +101,223 @@ int ft_board_setup(void *blob, bd_t *bd)
return ret;
}
#endif
+
+int do_board_detect(void)
+{
+ int ret;
+
+ ret = ti_i2c_eeprom_am6_get_base(CONFIG_EEPROM_BUS_ADDRESS,
+CONFIG_EEPROM_CHIP_ADDRESS);
+ if (ret)
+ pr_err("Reading on-board EEPROM at 0x%02x failed %d\n",
+ CONFIG_EEPROM_CHIP_ADDRESS, ret);
+
+ return ret;
+}
+
+static void setup_board_eeprom_env(void)
+{
+ char *name = "am65x";
+
+ if (do_board_detect())
+ goto invalid_eeprom;
+
+ if (board_is_am65x_base_board())
+ name = "am65x";
+ else
+ printf("Unidentified board claims
[U-Boot] [PATCH v3 02/18] arm: omap_i2c: Remove unwanted header file inclusion
From: Vignesh R There is no need for to include this header here, so drop it. Signed-off-by: Vignesh R Reviewed-by: Heiko Schocher Reviewed-by: Lokesh Vutla --- arch/arm/include/asm/omap_i2c.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/include/asm/omap_i2c.h b/arch/arm/include/asm/omap_i2c.h index c1695cbbee..a6975401da 100644 --- a/arch/arm/include/asm/omap_i2c.h +++ b/arch/arm/include/asm/omap_i2c.h @@ -3,8 +3,6 @@ #ifndef _OMAP_I2C_H #define _OMAP_I2C_H -#include - #ifdef CONFIG_DM_I2C /* Information about a GPIO bank */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 12/18] configs: am65x_hs_evm_a53: Increase malloc pool before relocation
The malloc pool used before relocation is getting tight leading to out of memory errors doing certain DM-related calls. Since we are running the A53 SPL out of DDR let's just go ahead and bump its size as used in U-Boot proper as well as SPL (via Kconfig default value) from 8KB to 32KB. Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla Acked-by: Andrew F. Davis --- configs/am65x_hs_evm_a53_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/am65x_hs_evm_a53_defconfig b/configs/am65x_hs_evm_a53_defconfig index e619b794ea..7d7a673714 100644 --- a/configs/am65x_hs_evm_a53_defconfig +++ b/configs/am65x_hs_evm_a53_defconfig @@ -3,7 +3,7 @@ CONFIG_ARCH_K3=y CONFIG_TI_SECURE_DEVICE=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_SOC_K3_AM6=y CONFIG_TARGET_AM654_A53_EVM=y CONFIG_SPL_MMC_SUPPORT=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 17/18] configs: am65x_evm: Add support for applying overlays
This will allow for downloading and applying overlays from an MMC/SD
boot media based on the overlay_files ENV variable containing a list
of overlay files.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
configs/am65x_evm_a53_defconfig | 3 ++-
include/configs/am65x_evm.h | 9 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index 8d90014778..b0c080ebf1 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -16,7 +16,7 @@ CONFIG_DISTRO_DEFAULTS=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL_TEXT_BASE=0x8008
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
@@ -83,3 +83,4 @@ CONFIG_SYSRESET=y
CONFIG_SPL_SYSRESET=y
CONFIG_SYSRESET_TI_SCI=y
CONFIG_FAT_WRITE=y
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index 552ef780bd..1415bb1b15 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -70,6 +70,7 @@
"setenv overlay_files ${name_overlays}\0" \
"loadaddr=0x8008\0" \
"fdtaddr=0x8200\0" \
+ "overlayaddr=0x8300\0" \
"name_kern=Image\0" \
"console=ttyS2,115200n8\0" \
"args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280\0" \
@@ -84,6 +85,14 @@
"rd_spec=-\0" \
"init_mmc=run args_all args_mmc\0" \
"get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}\0" \
+ "get_overlay_mmc=" \
+ "fdt address ${fdtaddr};" \
+ "fdt resize 0x10;" \
+ "for overlay in $overlay_files;"\
+ "do;" \
+ "load mmc ${bootpart} ${overlayaddr} ${bootdir}/${overlay};"
\
+ "fdt apply ${overlayaddr};" \
+ "done;\0" \
"get_kern_mmc=load mmc ${bootpart} ${loadaddr} "\
"${bootdir}/${name_kern}\0" \
"partitions=" PARTS_DEFAULT
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 08/18] arm64: dts: k3-am654-base-board: Add I2C GPIO expander @ 0x38
The AM654 base board has a TCA9554/PCA9554-type GPIO expander on the
wkup_i2c0 bus at address 0x38 that is used to detect the presence of
daughter cards. Add a respective DTS description of this expander
to enable its use.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
arch/arm/dts/k3-am654-base-board.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/dts/k3-am654-base-board.dts
b/arch/arm/dts/k3-am654-base-board.dts
index 248d60e89b..e73b9aa6b1 100644
--- a/arch/arm/dts/k3-am654-base-board.dts
+++ b/arch/arm/dts/k3-am654-base-board.dts
@@ -76,4 +76,11 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c0_pins_default>;
clock-frequency = <40>;
+
+ tca9554: gpio@38 {
+ compatible = "nxp,pca9554";
+ reg = <0x38>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 14/18] ti: common: am6: Add support for board description EEPROM
The AM654x EVM based on the TI K3 family of SoCs have an updated board
detection EEPROM structure, now comprising variable-sized TLV-type
records, containing a superset of what is already being provided on
earlier platforms such as DRA7. Add basic support for parsing the new
data structures contained on the base board into the common TI EEPROM
structure while also providing infrastructure that can be used later on
to parse data from additional EEPROMs such as the ones that are used on
daughtercards for this platform.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
board/ti/common/board_detect.c | 214 +
board/ti/common/board_detect.h | 194 ++
2 files changed, 408 insertions(+)
diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index e258e22f37..fea39f21e8 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
#include
@@ -284,6 +285,191 @@ int __maybe_unused ti_i2c_eeprom_dra7_get(int bus_addr,
int dev_addr)
return 0;
}
+static int ti_i2c_eeprom_am6_parse_record(struct ti_am6_eeprom_record *record,
+ struct ti_am6_eeprom *ep,
+ char **mac_addr,
+ u8 mac_addr_max_cnt,
+ u8 *mac_addr_cnt)
+{
+ switch (record->header.id) {
+ case TI_AM6_EEPROM_RECORD_BOARD_INFO:
+ if (record->header.len != sizeof(record->data.board_info))
+ return -EINVAL;
+
+ if (!ep)
+ break;
+
+ /* Populate (and clean, if needed) the board name */
+ strlcpy(ep->name, record->data.board_info.name,
+ sizeof(ep->name));
+ ti_eeprom_string_cleanup(ep->name);
+
+ /* Populate selected other fields from the board info record */
+ strlcpy(ep->version, record->data.board_info.version,
+ sizeof(ep->version));
+ strlcpy(ep->software_revision,
+ record->data.board_info.software_revision,
+ sizeof(ep->software_revision));
+ strlcpy(ep->serial, record->data.board_info.serial,
+ sizeof(ep->serial));
+ break;
+ case TI_AM6_EEPROM_RECORD_MAC_INFO:
+ if (record->header.len != sizeof(record->data.mac_info))
+ return -EINVAL;
+
+ if (!mac_addr || !mac_addr_max_cnt)
+ break;
+
+ *mac_addr_cnt = ((record->data.mac_info.mac_control &
+TI_AM6_EEPROM_MAC_ADDR_COUNT_MASK) >>
+TI_AM6_EEPROM_MAC_ADDR_COUNT_SHIFT) + 1;
+
+ /*
+* The EEPROM can (but may not) hold a very large amount
+* of MAC addresses, by far exceeding what we want/can store
+* in the common memory array, so only grab what we can fit.
+* Note that a value of 0 means 1 MAC address, and so on.
+*/
+ *mac_addr_cnt = min(*mac_addr_cnt, mac_addr_max_cnt);
+
+ memcpy(mac_addr, record->data.mac_info.mac_addr,
+ *mac_addr_cnt * TI_EEPROM_HDR_ETH_ALEN);
+ break;
+ case 0x00:
+ /* Illegal value... Fall through... */
+ case 0xFF:
+ /* Illegal value... Something went horribly wrong... */
+ return -EINVAL;
+ default:
+ pr_warn("%s: Ignoring record id %u\n", __func__,
+ record->header.id);
+ }
+
+ return 0;
+}
+
+int __maybe_unused ti_i2c_eeprom_am6_get(int bus_addr, int dev_addr,
+struct ti_am6_eeprom *ep,
+char **mac_addr,
+u8 mac_addr_max_cnt,
+u8 *mac_addr_cnt)
+{
+ struct udevice *dev;
+ struct udevice *bus;
+ unsigned int eeprom_addr;
+ struct ti_am6_eeprom_record_board_id board_id;
+ struct ti_am6_eeprom_record record;
+ int rc;
+
+ /* Initialize with a known bad marker for i2c fails.. */
+ memset(ep, 0, sizeof(*ep));
+ ep->header = TI_DEAD_EEPROM_MAGIC;
+
+ /* Read the board ID record which is always the first EEPROM record */
+ rc = ti_i2c_eeprom_get(bus_addr, dev_addr, TI_EEPROM_HEADER_MAGIC,
+ sizeof(board_id), (uint8_t *)_id);
+ if (rc)
+ return rc;
+
+ if (board_id.header.id != TI_AM6_EEPROM_RECORD_BOARD_ID) {
+ pr_err("%s: Invalid board ID record!\n", __func__);
+ return -EINVAL;
+ }
+
+ /* Establish DM
[U-Boot] [PATCH v3 07/18] configs: am65x_hs_evm_defconfig: Enable I2C support
Enable I2C via driver model as well as the associated set of U-Boot commands to allow us interacting with various I2C slave devices. Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla Acked-by: Andrew F. Davis --- configs/am65x_hs_evm_a53_defconfig | 4 configs/am65x_hs_evm_r5_defconfig | 4 2 files changed, 8 insertions(+) diff --git a/configs/am65x_hs_evm_a53_defconfig b/configs/am65x_hs_evm_a53_defconfig index 62e9d720fe..7e36b2805b 100644 --- a/configs/am65x_hs_evm_a53_defconfig +++ b/configs/am65x_hs_evm_a53_defconfig @@ -35,6 +35,7 @@ CONFIG_SPL_REMOTEPROC=y CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_ASKENV=y # CONFIG_CMD_FLASH is not set +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_REMOTEPROC=y # CONFIG_CMD_SETEXPR is not set @@ -58,6 +59,9 @@ CONFIG_CLK_TI_SCI=y CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y +CONFIG_DM_I2C=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y +CONFIG_SYS_I2C_OMAP24XX=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y CONFIG_DM_MMC=y diff --git a/configs/am65x_hs_evm_r5_defconfig b/configs/am65x_hs_evm_r5_defconfig index 9e01899031..d378d1e9ee 100644 --- a/configs/am65x_hs_evm_r5_defconfig +++ b/configs/am65x_hs_evm_r5_defconfig @@ -39,6 +39,7 @@ CONFIG_CMD_BOOTZ=y CONFIG_CMD_ASKENV=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPT=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_REMOTEPROC=y # CONFIG_CMD_SETEXPR is not set @@ -62,6 +63,9 @@ CONFIG_CLK_TI_SCI=y CONFIG_TI_SCI_PROTOCOL=y CONFIG_DM_GPIO=y CONFIG_DA8XX_GPIO=y +CONFIG_DM_I2C=y +CONFIG_I2C_SET_DEFAULT_BUS_NUM=y +CONFIG_SYS_I2C_OMAP24XX=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y CONFIG_MISC=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 10/18] configs: am65x_hs_evm_a53: Enable PCA953X-type GPIO driver
Enable GPIO driver for PCA953X-compatible I2C-based I/O expander which includes support for the TCA9554/PCA9554-type expander found on the AM654 EVM base board. Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla Acked-by: Andrew F. Davis --- configs/am65x_hs_evm_a53_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/am65x_hs_evm_a53_defconfig b/configs/am65x_hs_evm_a53_defconfig index 7e36b2805b..e619b794ea 100644 --- a/configs/am65x_hs_evm_a53_defconfig +++ b/configs/am65x_hs_evm_a53_defconfig @@ -59,6 +59,8 @@ CONFIG_CLK_TI_SCI=y CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y +CONFIG_DM_GPIO=y +CONFIG_DM_PCA953X=y CONFIG_DM_I2C=y CONFIG_I2C_SET_DEFAULT_BUS_NUM=y CONFIG_SYS_I2C_OMAP24XX=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 11/18] configs: am65x_evm_a53: Increase malloc pool before relocation
The malloc pool used before relocation is getting tight leading to out of memory errors doing certain DM-related calls. Since we are running the A53 SPL out of DDR let's just go ahead and bump its size as used in U-Boot proper as well as SPL (via Kconfig default value) from 8KB to 32KB. Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla --- configs/am65x_evm_a53_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index 5fa7a7e657..8d90014778 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -2,7 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_K3=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_SOC_K3_AM6=y CONFIG_TARGET_AM654_A53_EVM=y CONFIG_SPL_MMC_SUPPORT=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 05/18] arm: dts: k3-am654-base-board: Enable wkup_i2c0 across all boot stages
To enable the use of an EEPROM-based board detection scheme we need to
be able to access the I2C bus associated with the EEPROMs across all
3 stages of U-Boot: R5 SPL, A53 SPL, and A53 U-Boot (proper). So go
ahead and add/update the wkup_i2c0 peripheral module DTS definitions
and its associated pinmux node accordingly.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Lokesh Vutla
---
arch/arm/dts/k3-am65.dtsi| 1 +
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 12
arch/arm/dts/k3-am654-base-board.dts | 15 +++
arch/arm/dts/k3-am654-r5-base-board.dts | 13 +
4 files changed, 41 insertions(+)
diff --git a/arch/arm/dts/k3-am65.dtsi b/arch/arm/dts/k3-am65.dtsi
index 5bcf6e0693..50f4be2047 100644
--- a/arch/arm/dts/k3-am65.dtsi
+++ b/arch/arm/dts/k3-am65.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
/ {
model = "Texas Instruments K3 AM654 SoC";
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index 67535f76a5..e21562252f 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -110,6 +110,14 @@
u-boot,dm-spl;
};
+_pmx0 {
+ u-boot,dm-spl;
+
+ wkup_i2c0_pins_default {
+ u-boot,dm-spl;
+ };
+};
+
_pmx0 {
u-boot,dm-spl;
main_uart0_pins_default: main_uart0_pins_default {
@@ -179,3 +187,7 @@
sdhci-caps-mask = <0x7 0x0>;
ti,driver-strength-ohm = <50>;
};
+
+_i2c0 {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/k3-am654-base-board.dts
b/arch/arm/dts/k3-am654-base-board.dts
index ab233916c6..248d60e89b 100644
--- a/arch/arm/dts/k3-am654-base-board.dts
+++ b/arch/arm/dts/k3-am654-base-board.dts
@@ -55,6 +55,15 @@
};
};
+_pmx0 {
+ wkup_i2c0_pins_default: wkup-i2c0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT, 0) /* (AC7)
WKUP_I2C0_SCL */
+ AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT, 0) /* (AD6)
WKUP_I2C0_SDA */
+ >;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_mmc0_pins_default>;
@@ -62,3 +71,9 @@
non-removable;
ti,driver-strength-ohm = <50>;
};
+
+_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0_pins_default>;
+ clock-frequency = <40>;
+};
diff --git a/arch/arm/dts/k3-am654-r5-base-board.dts
b/arch/arm/dts/k3-am654-r5-base-board.dts
index 8deda328d0..9d9b3d5852 100644
--- a/arch/arm/dts/k3-am654-r5-base-board.dts
+++ b/arch/arm/dts/k3-am654-r5-base-board.dts
@@ -136,6 +136,13 @@
>;
u-boot,dm-spl;
};
+
+ wkup_i2c0_pins_default: wkup-i2c0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT, 0) /* (AC7)
WKUP_I2C0_SCL */
+ AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT, 0) /* (AD6)
WKUP_I2C0_SDA */
+ >;
+ };
};
_pmx0 {
@@ -176,3 +183,9 @@
/delete-property/ power-domains;
ti,driver-strength-ohm = <50>;
};
+
+_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0_pins_default>;
+ clock-frequency = <40>;
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 04/18] arm: dts: k3-am65: Add I2C nodes
Add I2C DT nodes
Signed-off-by: Vignesh R
Reviewed-by: Lokesh Vutla
---
arch/arm/dts/k3-am65-main.dtsi | 44
arch/arm/dts/k3-am65-mcu.dtsi| 11
arch/arm/dts/k3-am65-wakeup.dtsi | 11
arch/arm/dts/k3-am65.dtsi| 6 +
4 files changed, 72 insertions(+)
diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index a97872f62e..39fec03b4a 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -99,4 +99,48 @@
ti,trm-icp = <0x8>;
dma-coherent;
};
+
+ main_i2c0: i2c@200 {
+ compatible = "ti,am654-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x200 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 110 1>;
+ power-domains = <_pds 110>;
+ };
+
+ main_i2c1: i2c@201 {
+ compatible = "ti,am654-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x201 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 111 1>;
+ power-domains = <_pds 111>;
+ };
+
+ main_i2c2: i2c@202 {
+ compatible = "ti,am654-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x202 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 112 1>;
+ power-domains = <_pds 112>;
+ };
+
+ main_i2c3: i2c@203 {
+ compatible = "ti,am654-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x203 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 113 1>;
+ power-domains = <_pds 113>;
+ };
};
diff --git a/arch/arm/dts/k3-am65-mcu.dtsi b/arch/arm/dts/k3-am65-mcu.dtsi
index 8c611d16df..1fd027748e 100644
--- a/arch/arm/dts/k3-am65-mcu.dtsi
+++ b/arch/arm/dts/k3-am65-mcu.dtsi
@@ -15,4 +15,15 @@
clock-frequency = <9600>;
current-speed = <115200>;
};
+
+ mcu_i2c0: i2c@40b0 {
+ compatible = "ti,am654-i2c", "ti,omap4-i2c";
+ reg = <0x0 0x40b0 0x0 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 114 1>;
+ power-domains = <_pds 114>;
+ };
};
diff --git a/arch/arm/dts/k3-am65-wakeup.dtsi b/arch/arm/dts/k3-am65-wakeup.dtsi
index 1b67747dfe..1f85006f55 100644
--- a/arch/arm/dts/k3-am65-wakeup.dtsi
+++ b/arch/arm/dts/k3-am65-wakeup.dtsi
@@ -51,4 +51,15 @@
clock-frequency = <4800>;
current-speed = <115200>;
};
+
+ wkup_i2c0: i2c@4212 {
+ compatible = "ti,am654-i2c", "ti,omap4-i2c";
+ reg = <0x4212 0x100>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-names = "fck";
+ clocks = <_clks 115 1>;
+ power-domains = <_pds 115>;
+ };
};
diff --git a/arch/arm/dts/k3-am65.dtsi b/arch/arm/dts/k3-am65.dtsi
index 3d4bf369d0..5bcf6e0693 100644
--- a/arch/arm/dts/k3-am65.dtsi
+++ b/arch/arm/dts/k3-am65.dtsi
@@ -22,6 +22,12 @@
serial2 = _uart0;
serial3 = _uart1;
serial4 = _uart2;
+ i2c0 = _i2c0;
+ i2c1 = _i2c0;
+ i2c2 = _i2c0;
+ i2c3 = _i2c1;
+ i2c4 = _i2c2;
+ i2c5 = _i2c3;
};
chosen { };
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 03/18] arm: dts: k3-am65: Move pinctrl nodes out of U-Boot specific dtsi
Only U-Boot specifc DT properties or overrides, must be in -u-boot.dtsi.
Pinctrl nodes does not belong here. Now that pinctrl nodes are in kernel
DT, there is no reason to be keep these in -u-boot.dtsi. Move them to
proper places so that it would ease copying DT entries from kernel DT.
Signed-off-by: Vignesh R
Reviewed-by: Lokesh Vutla
---
arch/arm/dts/k3-am65-main.dtsi | 8
arch/arm/dts/k3-am65-wakeup.dtsi | 8
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 15 ---
3 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index 84fed12fbd..a97872f62e 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -78,6 +78,14 @@
pinctrl-single,function-mask = <0x>;
};
+ main_pmx1: pinmux@11c2e8 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0x11c2e8 0x0 0x24>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x>;
+ };
+
sdhci0: sdhci@4f8 {
compatible = "ti,am654-sdhci-5.1";
reg = <0x0 0x4f8 0x0 0x260>, <0x0 0x4f9 0x0 0x134>;
diff --git a/arch/arm/dts/k3-am65-wakeup.dtsi b/arch/arm/dts/k3-am65-wakeup.dtsi
index 1f591ef8bb..1b67747dfe 100644
--- a/arch/arm/dts/k3-am65-wakeup.dtsi
+++ b/arch/arm/dts/k3-am65-wakeup.dtsi
@@ -34,6 +34,14 @@
};
};
+ wkup_pmx0: pinmux@4301c000 {
+ compatible = "pinctrl-single";
+ reg = <0x4301c000 0x118>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x>;
+ };
+
wkup_uart0: serial@4230 {
compatible = "ti,am654-uart";
reg = <0x4230 0x100>;
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index c43888f36d..67535f76a5 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -19,14 +19,6 @@
_main{
u-boot,dm-spl;
- main_pmx1: pinmux@11c2e8 {
- compatible = "pinctrl-single";
- reg = <0x0 0x11c2e8 0x0 0x24>;
- #pinctrl-cells = <1>;
- pinctrl-single,register-width = <32>;
- pinctrl-single,function-mask = <0x>;
- };
-
sdhci1: sdhci@04FA {
compatible = "ti,am654-sdhci-5.1";
reg = <0x0 0x4FA 0x0 0x1000>,
@@ -42,13 +34,6 @@
_mcu {
u-boot,dm-spl;
- wkup_pmx0: pinmux@4301c000 {
- compatible = "pinctrl-single";
- reg = <0x0 0x4301c000 0x0 0x118>;
- #pinctrl-cells = <1>;
- pinctrl-single,register-width = <32>;
- pinctrl-single,function-mask = <0x>;
- };
navss_mcu: navss-mcu {
compatible = "simple-bus";
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 00/18] Add EEPROM-based board detect support for TI K3 SoCs
This is an updated EEPROM-based board detection series that can applied if staged with other patches in the sequence proposed earlier [1]. For completeness here is the proposed sequence again, avoiding merge conflicts, but this time from the perspective of this patch series. Step 1) Faiz' "Add Support for eMMC in Am65x-evm" series [2]. It needs a small update to actuall allow for eMMC boot I posted earlier. Step 2) The updated (v2) SYSFW loader series just posted [3] Step 3) The updated AM654x EEPROM support proposed with this series Step 4) An updated version of Lokesh's "arm: k3: Allow for exclusive and shared device requests" series [4]. In addition to a rebase such an updated series should include updating power domain properties for devices that were added during the previous steps. Step 5) An updated version of Lokesh's "arm: k3: arm64: Initial support Texas Instrument's J721E Platform" series [5] also adding in the few lines of codes to leverage SYSFW. Step 6 & beyond) Various rproc patches, etc. Changes since v2: - Re-based for proposed staging K3 AM654x patch staging sequence Changes since initial submission: - Re-based onto latest 'master' branch - Collected all review tags - Re-tested [1] https://lists.denx.de/pipermail/u-boot/2019-June/371739.html [2] https://patchwork.ozlabs.org/project/uboot/list/?series=111723 [3] https://patchwork.ozlabs.org/project/uboot/list/?series=111844 [4] https://patchwork.ozlabs.org/project/uboot/list/?series=109163 [5] https://patchwork.ozlabs.org/project/uboot/list/?series=109296 -- Andreas Dannenberg Texas Instruments Inc Andreas Dannenberg (16): arm: dts: k3-am65: Move pinctrl nodes out of U-Boot specific dtsi arm: dts: k3-am65: Add I2C nodes arm: dts: k3-am654-base-board: Enable wkup_i2c0 across all boot stages configs: am65x_evm_defconfig: Enable I2C support configs: am65x_hs_evm_defconfig: Enable I2C support arm64: dts: k3-am654-base-board: Add I2C GPIO expander @ 0x38 configs: am65x_evm_a53: Enable PCA953X-type GPIO driver configs: am65x_hs_evm_a53: Enable PCA953X-type GPIO driver configs: am65x_evm_a53: Increase malloc pool before relocation configs: am65x_hs_evm_a53: Increase malloc pool before relocation arm: K3: am654: Map common EEPROM data into SRAM scratch space ti: common: am6: Add support for board description EEPROM ti: common: am6: Add support for setting MAC addresses board: ti: am654: Use EEPROM-based board detection configs: am65x_evm: Add support for applying overlays configs: am65x_hs_evm: Add support for applying overlays Vignesh R (2): i2c: omap24xx_i2c: Adapt driver to support K3 devices arm: omap_i2c: Remove unwanted header file inclusion arch/arm/dts/k3-am65-main.dtsi | 52 arch/arm/dts/k3-am65-mcu.dtsi| 11 + arch/arm/dts/k3-am65-wakeup.dtsi | 19 ++ arch/arm/dts/k3-am65.dtsi| 7 + arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 27 +- arch/arm/dts/k3-am654-base-board.dts | 22 ++ arch/arm/dts/k3-am654-r5-base-board.dts | 13 + arch/arm/include/asm/omap_i2c.h | 2 - arch/arm/mach-k3/am6_init.c | 4 + arch/arm/mach-k3/include/mach/am6_hardware.h | 3 + arch/arm/mach-k3/include/mach/sys_proto.h| 2 + board/ti/am65x/Kconfig | 7 + board/ti/am65x/evm.c | 241 ++ board/ti/common/board_detect.c | 246 +++ board/ti/common/board_detect.h | 206 configs/am65x_evm_a53_defconfig | 11 +- configs/am65x_evm_r5_defconfig | 4 + configs/am65x_hs_evm_a53_defconfig | 11 +- configs/am65x_hs_evm_r5_defconfig| 4 + drivers/i2c/Kconfig | 2 +- include/configs/am65x_evm.h | 18 +- 21 files changed, 884 insertions(+), 28 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 01/18] i2c: omap24xx_i2c: Adapt driver to support K3 devices
From: Vignesh R K3 devices have I2C IP that is same as OMAP2+ family. Allow driver to be compiled for ARCH_K3. Signed-off-by: Vignesh R Signed-off-by: Andreas Dannenberg Reviewed-by: Heiko Schocher Reviewed-by: Lokesh Vutla --- drivers/i2c/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 095a9bc6a4..4772db3837 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -330,7 +330,7 @@ endif config SYS_I2C_OMAP24XX bool "TI OMAP2+ I2C driver" - depends on ARCH_OMAP2PLUS + depends on ARCH_OMAP2PLUS || ARCH_K3 help Add support for the OMAP2+ I2C driver. -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 02/12] spl: Allow performing BSS init early before board_init_f()
On some platform we have sufficient memory available early on to allow setting up and using a basic BSS prior to entering board_init_f(). Doing so can for example be used to carry state over to board_init_r() without having to resort to extending U-Boot's global data structure. To support such scenarios add a Kconfig option called CONFIG_SPL_EARLY_BSS to allow moving the initialization of BSS prior to entering board_init_f(), if enabled. Note that using this option usually should go along with using CONFIG_SPL_SEPARATE_BSS and configuring BSS to be located in memory actually available prior to board_init_f(). Signed-off-by: Andreas Dannenberg --- arch/arm/lib/crt0.S | 53 ++--- common/spl/Kconfig | 10 + 2 files changed, 46 insertions(+), 17 deletions(-) diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index 30fba20e1b..c74641dcd9 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -57,6 +57,33 @@ * For more information see 'Board Initialisation Flow in README. */ +/* + * Macro for clearing BSS during SPL execution. Usually called during the + * relocation process for most boards before entering board_init_r(), but + * can also be done early before entering board_init_f() on plaforms that + * can afford it due to sufficient memory being available early. + */ + +.macro SPL_CLEAR_BSS + ldr r0, =__bss_start/* this is auto-relocated! */ + +#ifdef CONFIG_USE_ARCH_MEMSET + ldr r3, =__bss_end /* this is auto-relocated! */ + mov r1, #0x /* prepare zero to clear BSS */ + + subsr2, r3, r0 /* r2 = memset len */ + bl memset +#else + ldr r1, =__bss_end /* this is auto-relocated! */ + mov r2, #0x /* prepare zero to clear BSS */ + +clbss_l:cmpr0, r1 /* while not at end of BSS */ + strlo r2, [r0]/* clear 32-bit BSS word */ + addlo r0, r0, #4 /* move to next */ + blo clbss_l +#endif +.endm + /* * entry point of crt0 sequence */ @@ -82,6 +109,10 @@ ENTRY(_main) mov r9, r0 bl board_init_f_init_reserve +#if defined(CONFIG_SPL_EARLY_BSS) + SPL_CLEAR_BSS +#endif + mov r0, #0 bl board_init_f @@ -119,6 +150,11 @@ here: bl c_runtime_cpu_setup /* we still call old routine here */ #endif #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FRAMEWORK) + +#if !defined(CONFIG_SPL_EARLY_BSS) + SPL_CLEAR_BSS +#endif + # ifdef CONFIG_SPL_BUILD /* Use a DRAM stack for the rest of SPL, if requested */ bl spl_relocate_stack_gd @@ -126,23 +162,6 @@ here: movne sp, r0 movne r9, r0 # endif - ldr r0, =__bss_start/* this is auto-relocated! */ - -#ifdef CONFIG_USE_ARCH_MEMSET - ldr r3, =__bss_end /* this is auto-relocated! */ - mov r1, #0x /* prepare zero to clear BSS */ - - subsr2, r3, r0 /* r2 = memset len */ - bl memset -#else - ldr r1, =__bss_end /* this is auto-relocated! */ - mov r2, #0x /* prepare zero to clear BSS */ - -clbss_l:cmpr0, r1 /* while not at end of BSS */ - strlo r2, [r0]/* clear 32-bit BSS word */ - addlo r0, r0, #4 /* move to next */ - blo clbss_l -#endif #if ! defined(CONFIG_SPL_BUILD) bl coloured_LED_init diff --git a/common/spl/Kconfig b/common/spl/Kconfig index c7cd34449a..b0460e1d17 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -188,6 +188,16 @@ config TPL_BANNER_PRINT info. Disabling this option could be useful to reduce SPL boot time (e.g. approx. 6 ms faster, when output on i.MX6 with 115200 baud). +config SPL_EARLY_BSS + depends on ARM && !ARM64 + bool "Allows initializing BSS early before entering board_init_f" + help + On some platform we have sufficient memory available early on to + allow setting up and using a basic BSS prior to entering + board_init_f. Activating this option will also de-activate the + clearing of BSS during the SPL relocation process, thus allowing + to carry state from board_init_f to board_init_r by way of BSS. + config SPL_DISPLAY_PRINT bool "Display a board-specific message in SPL" help -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 08/12] configs: am65x_evm_r5: All sysfw to be loaded via MMC
Enable all the relevant configs that enables support for loading sysfw via MMC. Signed-off-by: Andreas Dannenberg --- configs/am65x_evm_r5_defconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig index 5abd686931..e3eb0d9cc5 100644 --- a/configs/am65x_evm_r5_defconfig +++ b/configs/am65x_evm_r5_defconfig @@ -3,7 +3,7 @@ CONFIG_ARCH_K3=y CONFIG_SPL_GPIO_SUPPORT=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x55000 CONFIG_SOC_K3_AM6=y CONFIG_TARGET_AM654_R5_EVM=y CONFIG_SPL_MMC_SUPPORT=y @@ -20,6 +20,7 @@ CONFIG_USE_BOOTCOMMAND=y CONFIG_SPL_TEXT_BASE=0x41c0 CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y +CONFIG_SPL_EARLY_BSS=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_DM_MAILBOX=y CONFIG_SPL_DM_RESET=y @@ -89,3 +90,4 @@ CONFIG_SYSRESET_TI_SCI=y CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_OMAP_TIMER=y +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 00/12] System Firmware Loader for TI K3 family SoCs
Updated version of the SYSFW loader series for K3 family AM654x devices. The fundamantal approach of tapping into the SPL loader framework has been kept for reasons discussed already. The series also still uses "early BSS" in SPL's board_init_f(). I'm well aware of the concerns previously brought up regarding this mainly by Simon Glass but I have not been able to find a better / more universal solution for this yet (one proposal was to move SYSFW loading into board_init_r() which is not easily solvable as SYSFW is needed to bring up DDR on K3 SoCs). Long story short I propose to consider the current proposed approach nevertheless (as it is also used by other platforms) at least as an initial step, and then migrate once a better solution is available. I have not yet included support for TI's newest K3 family J721E SoC which Lokesh posted an initial patch series [5] for due to the complex dependencies of all the different series we have currently posted/pending (if I were to add support for J721E which eventually will be required then the SYSFW loader series would have Lokesh's series as a pre-requisite as well). This being said I would like to propose the following staging sequence for the different TI K3 SoCs patches currently under review: Step 1) Faiz' "Add Support for eMMC in Am65x-evm" series [1]. It needs a small update to actuall allow for eMMC boot I posted earlier. Step 2) The SYSFW loader series proposed here Step 3) An updated version (v3) of the AM654x EEPROM support [3]. Will post this today. Step 4) An updated version of Lokesh's "arm: k3: Allow for exclusive and shared device requests" series. In addition to a rebase such an updated series should include updating power domain properties for devices that were added during the previous steps. Step 5) An updated version of Lokesh's "arm: k3: arm64: Initial support Texas Instrument's J721E Platform" series [5] also adding in the few lines of codes to leverage SYSFW. Step 6 & beyond) Various rproc patches, etc. The above is to allow for things to build in a logical order while avoiding merge conflicts. 1+2+3 added will provide a pretty good initial working U-Boot using eMMC and SD media for AM654x which is a device available today plus a foundation for everything else, hence it is at the top of the list. Changes since initial submission: - Dropped patch "armv7R: dts: k3: am654: Update mmc nodes for loading sysfw". This is taken care off by the "Add Support for eMMC in Am65x-evm" patch series [1] which this series was rebased on. - Replaced patch "spl: Allow skipping clearing BSS during relocation" with a functionally equivalent patch "spl: Allow performing BSS init early before board_init_f()" which is a bit more elegant solution which itself is a slight evolution what previously posted by Simon Goldschmidt [2] - Collected various review tags [1] https://patchwork.ozlabs.org/project/uboot/list/?series=111723 [2] https://patchwork.ozlabs.org/patch/1067363/ [3] https://patchwork.ozlabs.org/project/uboot/list/?series=109266 [4] https://patchwork.ozlabs.org/project/uboot/list/?series=109163 [5] https://patchwork.ozlabs.org/project/uboot/list/?series=109296 -- Andreas Dannenberg Texas Instruments Inc Andreas Dannenberg (10): mmc: am654_sdhci: Allow driver to probe without PDs specified spl: Allow performing BSS init early before board_init_f() spl: Make image loader infrastructure more universal arm: K3: Introduce System Firmware loader framework armV7R: K3: am654: Allow using SPL BSS pre-relocation armv7R: K3: am654: Use full malloc implementation in SPL armV7R: K3: am654: Load SYSFW binary and config from boot media configs: am65x_evm_r5: All sysfw to be loaded via MMC configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC configs: am65x_hs_evm: Add Support for eMMC boot Faiz Abbas (2): configs: am65x_evm: Add Support for eMMC boot am65x: README: Add eMMC layout and flash instructions arch/arm/lib/crt0.S | 53 ++-- arch/arm/mach-k3/Kconfig | 39 +++ arch/arm/mach-k3/Makefile| 3 + arch/arm/mach-k3/am6_init.c | 27 +- arch/arm/mach-k3/include/mach/sysfw-loader.h | 12 + arch/arm/mach-k3/sysfw-loader.c | 260 +++ board/ti/am65x/Kconfig | 1 + board/ti/am65x/README| 52 common/spl/Kconfig | 10 + common/spl/spl_fit.c | 14 + common/spl/spl_mmc.c | 76 -- configs/am65x_evm_a53_defconfig | 2 + configs/am65x_evm_r5_defconfig | 7 +- configs/am65x_hs_evm_a53_defconfig | 2 + configs/am65x_hs_evm_r5_defconfig| 7 +- drivers/mmc/am654_sdhci.c| 16 +- include/configs/am65x_evm.h | 30 ++-
[U-Boot] [PATCH v2 11/12] configs: am65x_hs_evm: Add Support for eMMC boot
Add configs to support RAW boot mode in eMMC. Signed-off-by: Andreas Dannenberg --- configs/am65x_hs_evm_a53_defconfig | 2 ++ configs/am65x_hs_evm_r5_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/am65x_hs_evm_a53_defconfig b/configs/am65x_hs_evm_a53_defconfig index 9c55cd37f6..62e9d720fe 100644 --- a/configs/am65x_hs_evm_a53_defconfig +++ b/configs/am65x_hs_evm_a53_defconfig @@ -25,6 +25,8 @@ CONFIG_SPL_TEXT_BASE=0x8008 CONFIG_SPL_SYS_MALLOC_SIMPLE=y CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400 CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_DM_MAILBOX=y CONFIG_SPL_DM_RESET=y diff --git a/configs/am65x_hs_evm_r5_defconfig b/configs/am65x_hs_evm_r5_defconfig index 642f005bd6..9e01899031 100644 --- a/configs/am65x_hs_evm_r5_defconfig +++ b/configs/am65x_hs_evm_r5_defconfig @@ -23,6 +23,8 @@ CONFIG_SPL_TEXT_BASE=0x41c0 CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_EARLY_BSS=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400 CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_DM_MAILBOX=y CONFIG_SPL_DM_RESET=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 09/12] configs: am65x_hs_evm_r5: All sysfw to be loaded via MMC
Enable all the relevant configs that enables support for loading sysfw via MMC. Signed-off-by: Andreas Dannenberg Reviewed-by: Simon Glass --- configs/am65x_hs_evm_r5_defconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/configs/am65x_hs_evm_r5_defconfig b/configs/am65x_hs_evm_r5_defconfig index 49eca7de64..642f005bd6 100644 --- a/configs/am65x_hs_evm_r5_defconfig +++ b/configs/am65x_hs_evm_r5_defconfig @@ -4,7 +4,7 @@ CONFIG_TI_SECURE_DEVICE=y CONFIG_SPL_GPIO_SUPPORT=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x55000 CONFIG_SOC_K3_AM6=y CONFIG_TARGET_AM654_R5_EVM=y CONFIG_SPL_MMC_SUPPORT=y @@ -22,6 +22,7 @@ CONFIG_USE_BOOTCOMMAND=y CONFIG_SPL_TEXT_BASE=0x41c0 CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y +CONFIG_SPL_EARLY_BSS=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_DM_MAILBOX=y CONFIG_SPL_DM_RESET=y @@ -89,3 +90,4 @@ CONFIG_SYSRESET_TI_SCI=y CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_OMAP_TIMER=y +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 03/12] spl: Make image loader infrastructure more universal
The current U-Boot SPL image loader infrastructure is very powerful,
able to initialize and load from a variety of boot media however it
is strongly geared towards loading specific types of images in a very
specific way. To address the need being able to use this infrastructure
to load arbitrary image files go ahead and refactor it as follows:
- Refactor existing spl_mmc_load_image function into superset function,
accepting additional arguments such as filenames and media load offset
(same concept can also be applied toother spl_XXX_load_image functions)
- Extend the loader function to "remember" their peripheral initialization
status so that the init is only done once during the boot process,
- Extend the FIT image loading function to allow skipping the parsing/
processing of the FIT contents (so that this can be done separately
in a more customized fashion)
- Populate the SPL_LOAD_IMAGE_METHOD() list with a trampoline function,
invoking the newly refactored superset functions in a way to maintain
compatibility with the existing behavior
This refactoring initially covers MMC/SD card loading (RAW and FS-based).
Signed-off-by: Andreas Dannenberg
Reviewed-by: Tom Rini
---
common/spl/spl_fit.c | 14
common/spl/spl_mmc.c | 76 +---
include/spl.h| 26 +++
3 files changed, 91 insertions(+), 25 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 87ecf0bb9e..969f7775c1 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -340,6 +340,16 @@ static int spl_fit_image_get_os(const void *fit, int
noffset, uint8_t *os)
#endif
}
+/*
+ * Weak default function to allow customizing SPL fit loading for load-only
+ * use cases by allowing to skip the parsing/processing of the FIT contents
+ * (so that this can be done separately in a more customized fashion)
+ */
+__weak bool spl_load_simple_fit_skip_processing(void)
+{
+ return false;
+}
+
int spl_load_simple_fit(struct spl_image_info *spl_image,
struct spl_load_info *info, ulong sector, void *fit)
{
@@ -389,6 +399,10 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
if (count == 0)
return -EIO;
+ /* skip further processing if requested to enable load-only use cases */
+ if (spl_load_simple_fit_skip_processing())
+ return 0;
+
/* find the node holding the images information */
images = fdt_path_offset(fit, FIT_IMAGES_PATH);
if (images < 0) {
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index 324d91c884..b3619889f7 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -151,7 +151,8 @@ static int spl_mmc_find_device(struct mmc **mmcp, u32
boot_device)
#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
static int mmc_load_image_raw_partition(struct spl_image_info *spl_image,
- struct mmc *mmc, int partition)
+ struct mmc *mmc, int partition,
+ unsigned long sector)
{
disk_partition_t info;
int err;
@@ -180,8 +181,7 @@ static int mmc_load_image_raw_partition(struct
spl_image_info *spl_image,
}
#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
- return mmc_load_image_raw_sector(spl_image, mmc,
- info.start + CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR);
+ return mmc_load_image_raw_sector(spl_image, mmc, info.start + sector);
#else
return mmc_load_image_raw_sector(spl_image, mmc, info.start);
#endif
@@ -234,7 +234,8 @@ static int mmc_load_image_raw_os(struct spl_image_info
*spl_image,
#endif
#ifdef CONFIG_SYS_MMCSD_FS_BOOT_PARTITION
-static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image, struct mmc
*mmc)
+static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image, struct mmc
*mmc,
+ const char *filename)
{
int err = -ENOSYS;
@@ -248,7 +249,7 @@ static int spl_mmc_do_fs_boot(struct spl_image_info
*spl_image, struct mmc *mmc)
#ifdef CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
err = spl_load_image_fat(spl_image, mmc_get_blk_desc(mmc),
CONFIG_SYS_MMCSD_FS_BOOT_PARTITION,
-CONFIG_SPL_FS_LOAD_PAYLOAD_NAME);
+filename);
if (!err)
return err;
#endif
@@ -263,7 +264,7 @@ static int spl_mmc_do_fs_boot(struct spl_image_info
*spl_image, struct mmc *mmc)
#ifdef CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
err = spl_load_image_ext(spl_image, mmc_get_blk_desc(mmc),
CONFIG_SYS_MMCSD_FS_BOOT_PARTITION,
-CONFIG_SPL_FS_LOAD_PAYLOAD_NAME);
+filename);
if (!err)
return err;
#endif
@@ -276,7 +277,8 @@ static int spl_mmc_do_fs_boot(struct spl_image_info
[U-Boot] [PATCH v2 07/12] armV7R: K3: am654: Load SYSFW binary and config from boot media
Use the System Firmware (SYSFW) loader framework to load and start
the SYSFW as part of the AM654 early initialization sequence. While
at it also initialize the WKUP_UART0 pinmux as it is used by SYSFW
to print diagnostic messages.
Signed-off-by: Andreas Dannenberg
---
arch/arm/mach-k3/am6_init.c | 27 ++-
board/ti/am65x/Kconfig | 1 +
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 60a580305d..e326f575e5 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -10,8 +10,11 @@
#include
#include
#include
+#include
#include "common.h"
#include
+#include
+#include
#ifdef CONFIG_SPL_BUILD
static void mmr_unlock(u32 base, u32 partition)
@@ -63,7 +66,7 @@ static void store_boot_index_from_rom(void)
void board_init_f(ulong dummy)
{
-#if defined(CONFIG_K3_AM654_DDRSS)
+#if defined(CONFIG_K3_LOAD_SYSFW) || defined(CONFIG_K3_AM654_DDRSS)
struct udevice *dev;
int ret;
#endif
@@ -83,8 +86,30 @@ void board_init_f(ulong dummy)
/* Init DM early in-order to invoke system controller */
spl_early_init();
+#ifdef CONFIG_K3_LOAD_SYSFW
+ /*
+* Process pinctrl for the serial0 a.k.a. WKUP_UART0 module and continue
+* regardless of the result of pinctrl. Do this without probing the
+* device, but instead by searching the device that would request the
+* given sequence number if probed. The UART will be used by the system
+* firmware (SYSFW) image for various purposes and SYSFW depends on us
+* to initialize its pin settings.
+*/
+ ret = uclass_find_device_by_seq(UCLASS_SERIAL, 0, true, );
+ if (!ret)
+ pinctrl_select_state(dev, "default");
+
+ /*
+* Load, start up, and configure system controller firmware. Provide
+* the U-Boot console init function to the SYSFW post-PM configuration
+* callback hook, effectively switching on (or over) the console
+* output.
+*/
+ k3_sysfw_loader(preloader_console_init);
+#else
/* Prepare console output */
preloader_console_init();
+#endif
#ifdef CONFIG_K3_AM654_DDRSS
ret = uclass_get_device(UCLASS_RAM, 0, );
diff --git a/board/ti/am65x/Kconfig b/board/ti/am65x/Kconfig
index 98172c28f5..60bb834aca 100644
--- a/board/ti/am65x/Kconfig
+++ b/board/ti/am65x/Kconfig
@@ -18,6 +18,7 @@ config TARGET_AM654_R5_EVM
select CPU_V7R
select SYS_THUMB_BUILD
select SOC_K3_AM6
+ select K3_LOAD_SYSFW
select K3_AM654_DDRSS
imply SYS_K3_SPL_ATF
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 10/12] configs: am65x_evm: Add Support for eMMC boot
From: Faiz Abbas Add configs to support RAW boot mode in eMMC. Signed-off-by: Faiz Abbas Signed-off-by: Andreas Dannenberg --- configs/am65x_evm_a53_defconfig | 2 ++ configs/am65x_evm_r5_defconfig | 2 ++ include/configs/am65x_evm.h | 2 ++ 3 files changed, 6 insertions(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index 43d2ccc5ed..d5f8a01fae 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -22,6 +22,8 @@ CONFIG_SPL_TEXT_BASE=0x8008 CONFIG_SPL_SYS_MALLOC_SIMPLE=y CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400 CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_DM_MAILBOX=y CONFIG_SPL_DM_RESET=y diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig index e3eb0d9cc5..d81018b31d 100644 --- a/configs/am65x_evm_r5_defconfig +++ b/configs/am65x_evm_r5_defconfig @@ -21,6 +21,8 @@ CONFIG_SPL_TEXT_BASE=0x41c0 CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_EARLY_BSS=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400 CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_DM_MAILBOX=y CONFIG_SPL_DM_RESET=y diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h index ea365b979b..1d291f5724 100644 --- a/include/configs/am65x_evm.h +++ b/include/configs/am65x_evm.h @@ -107,6 +107,8 @@ #define CONFIG_SYS_REDUNDAND_ENVIRONMENT #endif +#define CONFIG_SUPPORT_EMMC_BOOT + /* Now for the remaining common defines */ #include -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 06/12] armv7R: K3: am654: Use full malloc implementation in SPL
Switch to using the full malloc scheme in post-relocation SPL to allow better utilization of available memory for example by allowing memory to get freed. Initially allocate a 16MB-sized region in DDR starting at address 0x8400 for this purpose. Signed-off-by: Andreas Dannenberg --- configs/am65x_evm_r5_defconfig| 1 - configs/am65x_hs_evm_r5_defconfig | 1 - include/configs/am65x_evm.h | 3 +++ 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig index 6a261c20ac..5abd686931 100644 --- a/configs/am65x_evm_r5_defconfig +++ b/configs/am65x_evm_r5_defconfig @@ -18,7 +18,6 @@ CONFIG_SPL_LOAD_FIT=y CONFIG_USE_BOOTCOMMAND=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_SPL_TEXT_BASE=0x41c0 -CONFIG_SPL_SYS_MALLOC_SIMPLE=y CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_I2C_SUPPORT=y diff --git a/configs/am65x_hs_evm_r5_defconfig b/configs/am65x_hs_evm_r5_defconfig index 0b12f15782..49eca7de64 100644 --- a/configs/am65x_hs_evm_r5_defconfig +++ b/configs/am65x_hs_evm_r5_defconfig @@ -20,7 +20,6 @@ CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y CONFIG_USE_BOOTCOMMAND=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_SPL_TEXT_BASE=0x41c0 -CONFIG_SPL_SYS_MALLOC_SIMPLE=y CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_I2C_SUPPORT=y diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h index 1319745963..ea365b979b 100644 --- a/include/configs/am65x_evm.h +++ b/include/configs/am65x_evm.h @@ -41,6 +41,9 @@ CONFIG_SPL_BSS_MAX_SIZE) /* Set the stack right below the SPL BSS section */ #define CONFIG_SYS_INIT_SP_ADDR CONFIG_SPL_BSS_START_ADDR +/* Configure R5 SPL post-relocation malloc pool in DDR */ +#define CONFIG_SYS_SPL_MALLOC_START0x8400 +#define CONFIG_SYS_SPL_MALLOC_SIZE SZ_16M #endif #ifdef CONFIG_SYS_K3_SPL_ATF -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 01/12] mmc: am654_sdhci: Allow driver to probe without PDs specified
We would like to use the driver even without power domains being
specified for cases such as during early boot when the required power
domains have already gotten enabled by the SoC's boot ROM and such
explicit initialization is not needed and possible.
Signed-off-by: Andreas Dannenberg
Reviewed-by: Tom Rini
---
drivers/mmc/am654_sdhci.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
index fe633aa39a..fb0fb58070 100644
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -215,14 +215,14 @@ static int am654_sdhci_probe(struct udevice *dev)
int ret;
ret = power_domain_get_by_index(dev, _pwrdmn, 0);
- if (ret) {
- dev_err(dev, "failed to get power domain\n");
- return ret;
- }
-
- ret = power_domain_on(_pwrdmn);
- if (ret) {
- dev_err(dev, "Power domain on failed\n");
+ if (!ret) {
+ ret = power_domain_on(_pwrdmn);
+ if (ret) {
+ dev_err(dev, "Power domain on failed (%d)\n", ret);
+ return ret;
+ }
+ } else if (ret != -ENOENT && ret != -ENODEV && ret != -ENOSYS) {
+ dev_err(dev, "failed to get power domain (%d)\n", ret);
return ret;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 12/12] am65x: README: Add eMMC layout and flash instructions
From: Faiz Abbas
Add instructions for flashing boot images to the eMMC with a
layout of the address where each image needs to be flashed.
Also add instructions to flash filesystem partition in user
partition and boot kernel from the rootfs.
Signed-off-by: Faiz Abbas
---
board/ti/am65x/README | 52 +++
1 file changed, 52 insertions(+)
diff --git a/board/ti/am65x/README b/board/ti/am65x/README
index 0b82bd557b..16384e05ea 100644
--- a/board/ti/am65x/README
+++ b/board/ti/am65x/README
@@ -209,3 +209,55 @@ Image formats:
| |Secure config | |
| +---+ |
+---+
+
+eMMC:
+-
+ROM supports booting from eMMC from boot0 partition offset 0x0
+
+Flashing images to eMMC:
+
+The following commands can be used to download tiboot3.bin, tispl.bin,
+u-boot.img, and sysfw.itb from an SD card and write them to the eMMC boot0
+partition at respective addresses.
+
+=> mmc dev 0 1
+=> fatload mmc 1 ${loadaddr} tiboot3.bin
+=> mmc write ${loadaddr} 0x0 0x400
+=> fatload mmc 1 ${loadaddr} tispl.bin
+=> mmc write ${loadaddr} 0x400 0x1000
+=> fatload mmc 1 ${loadaddr} u-boot.img
+=> mmc write ${loadaddr} 0x1400 0x2000
+=> fatload mmc 1 ${loadaddr} sysfw.itb
+=> mmc write ${loadaddr} 0x3600 0x800
+
+To give the ROM access to the boot partition, the following commands must be
+used for the first time:
+=> mmc partconf 0 1 1 1
+=> mmc bootbus 0 1 0 0
+
+To create a software partition for the rootfs, the following command can be
+used:
+=> gpt write mmc 0 ${partitions}
+
+eMMC layout:
+
+ boot0 partition (8 MB)user partition
+ 0x0+--+ 0x0+-+
+ | tiboot3.bin (512 KB) | | |
+ 0x400+--+ | |
+ | tispl.bin (2 MB) | | |
+0x1400+--+ |rootfs |
+ | u-boot.img (4 MB) | | |
+0x3400+--+ | |
+ | environment (128 KB)| | |
+0x3500+--+ | |
+ | backup environment (128 KB)| | |
+0x3600+--+ | |
+ | sysfw (1 MB)| | |
+0x3E00+--+ +-+
+
+Kernel image and DT are expected to be present in the /boot folder of rootfs.
+To boot kernel from eMMC, use the following commands:
+=> setenv mmcdev 0
+=> setenv bootpart 0
+=> boot
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 05/12] armV7R: K3: am654: Allow using SPL BSS pre-relocation
In order to be able to use more advanced driver functionality which often relies on having BSS initialized during early boot prior to relocation several things need to be in place: 1) Memory needs to be available for BSS to use. For this, we locate BSS at the top of the MCU SRAM area, with the stack starting right below it, 2) We need to move the initialization of BSS prior to entering board_init_f(). We will do this with a separate commit by turning on the respective CONFIG option. In this commit we also clean up the assignment of the initial SP address as part of the refactoring, taking into account the pre-decrement post- increment nature in which the SP is used on ARM. Signed-off-by: Andreas Dannenberg --- include/configs/am65x_evm.h | 25 +++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h index 51abab3943..1319745963 100644 --- a/include/configs/am65x_evm.h +++ b/include/configs/am65x_evm.h @@ -19,6 +19,29 @@ #define CONFIG_SYS_SDRAM_BASE1 0x88000 /* SPL Loader Configuration */ +#ifdef CONFIG_TARGET_AM654_A53_EVM +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE +\ +CONFIG_SYS_K3_NON_SECURE_MSRAM_SIZE) +#else +/* + * Maximum size in memory allocated to the SPL BSS. Keep it as tight as + * possible (to allow the build to go through), as this directly affects + * our memory footprint. The less we use for BSS the more we have available + * for everything else. + */ +#define CONFIG_SPL_BSS_MAX_SIZE0x5000 +/* + * Link BSS to be within SPL in a dedicated region located near the top of + * the MCU SRAM, this way making it available also before relocation. Note + * that we are not using the actual top of the MCU SRAM as there is a memory + * location filled in by the boot ROM that we want to read out without any + * interference from the C context. + */ +#define CONFIG_SPL_BSS_START_ADDR (CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX -\ +CONFIG_SPL_BSS_MAX_SIZE) +/* Set the stack right below the SPL BSS section */ +#define CONFIG_SYS_INIT_SP_ADDR CONFIG_SPL_BSS_START_ADDR +#endif #ifdef CONFIG_SYS_K3_SPL_ATF #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"tispl.bin" @@ -29,8 +52,6 @@ #endif #define CONFIG_SPL_MAX_SIZECONFIG_SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE -#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE +\ - CONFIG_SYS_K3_NON_SECURE_MSRAM_SIZE - 4) #define CONFIG_SYS_BOOTM_LEN SZ_64M -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 04/12] arm: K3: Introduce System Firmware loader framework
Introduce a framework that allows loading the System Firmware (SYSFW) binary as well as the associated configuration data from an image tree blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC RAW mode partition or sector. To simplify the handling of and loading from the different boot media we tap into the existing U-Boot SPL framework usually used for loading U-Boot by building on an earlier commit that exposes some of that functionality. Note that this initial implementation only supports FS and RAW-based eMMC/SD card boot. Signed-off-by: Andreas Dannenberg Signed-off-by: Lokesh Vutla --- arch/arm/mach-k3/Kconfig | 39 +++ arch/arm/mach-k3/Makefile| 3 + arch/arm/mach-k3/include/mach/sysfw-loader.h | 12 + arch/arm/mach-k3/sysfw-loader.c | 260 +++ 4 files changed, 314 insertions(+) create mode 100644 arch/arm/mach-k3/include/mach/sysfw-loader.h create mode 100644 arch/arm/mach-k3/sysfw-loader.c diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index e677a2e01b..f25f822205 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -58,6 +58,45 @@ config SYS_K3_BOOT_CORE_ID int default 16 +config K3_LOAD_SYSFW + bool + depends on SPL + +config K3_SYSFW_IMAGE_NAME + string "File name of SYSFW firmware and configuration blob" + depends on K3_LOAD_SYSFW + default "sysfw.itb" + help + Filename of the combined System Firmware and configuration image tree + blob to be loaded when booting from a filesystem. + +config K3_SYSFW_IMAGE_MMCSD_RAW_MODE_SECT + hex "MMC sector to load SYSFW firmware and configuration blob from" + depends on K3_LOAD_SYSFW && SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR + default 0x3600 + help + Address on the MMC to load the combined System Firmware and + configuration image tree blob from, when the MMC is being used + in raw mode. Units: MMC sectors (1 sector = 512 bytes). + +config K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART + hex "MMC partition to load SYSFW firmware and configuration blob from" + depends on K3_LOAD_SYSFW && SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION + default 2 + help + Partition on the MMC to the combined System Firmware and configuration + image tree blob from, when the MMC is being used in raw mode. + +config K3_SYSFW_IMAGE_SIZE_MAX + int "Amount of memory dynamically allocated for loading SYSFW blob" + depends on K3_LOAD_SYSFW + default 269000 + help + Amount of memory (in bytes) reserved through dynamic allocation at + runtime for loading the combined System Firmware and configuration image + tree blob. Keep it as tight as possible, as this directly affects the + overall SPL memory footprint. + config SYS_K3_SPL_ATF bool "Start Cortex-A from SPL" depends on SPL && CPU_V7R diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile index 0c3a4f7db1..3af7f2ec96 100644 --- a/arch/arm/mach-k3/Makefile +++ b/arch/arm/mach-k3/Makefile @@ -7,4 +7,7 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o obj-$(CONFIG_ARM64) += arm64-mmu.o obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o obj-$(CONFIG_TI_SECURE_DEVICE) += security.o +ifeq ($(CONFIG_SPL_BUILD),y) +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o +endif obj-y += common.o diff --git a/arch/arm/mach-k3/include/mach/sysfw-loader.h b/arch/arm/mach-k3/include/mach/sysfw-loader.h new file mode 100644 index 00..36eb265348 --- /dev/null +++ b/arch/arm/mach-k3/include/mach/sysfw-loader.h @@ -0,0 +1,12 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ + * Andreas Dannenberg + */ + +#ifndef _SYSFW_LOADER_H_ +#define _SYSFW_LOADER_H_ + +void k3_sysfw_loader(void (*config_pm_done_callback)(void)); + +#endif diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c new file mode 100644 index 00..2ede82004a --- /dev/null +++ b/arch/arm/mach-k3/sysfw-loader.c @@ -0,0 +1,260 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * K3: System Firmware Loader + * + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ + * Andreas Dannenberg + */ + +#include +#include +#include +#include +#include +#include + +/* Name of the FIT image nodes for SYSFW and its config data */ +#define SYSFW_FIRMWARE "sysfw.bin" +#define SYSFW_CFG_BOARD"board-cfg.bin" +#define SYSFW_CFG_PM "pm-cfg.bin" +#define SYSFW_CFG_RM "rm-cfg.bin" +#define SYSFW_CFG_SEC "sec-cfg.bin" + +static bool sysfw_loaded; +static void *sysfw_load_address; + +/* + * Populate SPL hook to override the default load address used by the SPL + * loader function with a custom address for SYSFW loading. + */ +struct
Re: [U-Boot] [RFC 5/6] ARM: dts: colibri_imx7: Add lcdif node
Hi Igor,
On Mon, Jun 3, 2019 at 6:06 PM Igor Opaniuk wrote:
> + {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> +
> + display-timings {
> + native-mode = <_vga>;
> +
> + /* Standard VGA timing */
> + timing_vga: 640x480 {
> + u-boot,dm-pre-reloc;
> + clock-frequency = <25175000>;
> + hactive = <640>;
> + vactive = <480>;
> + hback-porch = <48>;
> + hfront-porch = <16>;
> + vback-porch = <33>;
> + vfront-porch = <10>;
> + hsync-len = <96>;
> + vsync-len = <2>;
> +
> + de-active = <1>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + pixelclk-active = <0>
This is the deprecated style mxsfb fbdev binding.
In the kernel we no longer use this style as documented in
Documentation/devicetree/bindings/display/mxsfb.txt
If we follow this route in U-Boot then we will diverge from the kernel
recommended bindings.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
On Tue, Jun 4, 2019 at 5:41 PM Sjoerd Simons wrote: > Small steps right; Ooi what imx_usb_loader configuration/commands are > you using to test this? (I find its config rather tricky to grasp). I simply run: sudo ./imx_usb SPL and then sudo ./imx_usb u-boot-dtb.img I suggest you to try U-Boot 2019.01 on a mx6sabreauto first. U-Boot 2019.01 is prior to the DM / fit conversion and loading SPL + u-boot.img with the method above works fine. > One of the next things I will need to look at is actually secure boot.. > That said why does imx_usb_loader if the board isn't locked? Not sure what you mean by locked. We have been using imx_usb_loader for a long time. After DM / fit comvesion the IVT piece is not added into the final .img. From the main Makefile: ifdef CONFIG_SPL_LOAD_FIT MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O u-boot \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \ $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) else MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" MKIMAGEFLAGS_u-boot-ivt.img = -A $(ARCH) -T firmware_ivt -C none -O u-boot \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" u-boot-ivt.img: MKIMAGEOUTPUT = u-boot-ivt.img.log CLEAN_FILES += u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log endif we can see that the ivt is not added for the CONFIG_SPL_LOAD_FIT case. I tried to change this logic, but so far was not able to make it work. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] cmd: env: add -nv option for UEFI non-volatile variable
On 6/4/19 8:52 AM, AKASHI Takahiro wrote: With this option, -nv, at "setenv -e" command, a variable will be defined as non-volatile. Signed-off-by: AKASHI Takahiro Reviewed-by: Heinrich Schuchardt ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/7] efi_loader: load saved non-volatile variables at init
On 6/4/19 8:52 AM, AKASHI Takahiro wrote: Data cache will be read in from persistent storage after (re)boot to restore UEFI non-volatile variables. Signed-off-by: AKASHI Takahiro --- lib/efi_loader/efi_setup.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c index 8691d686d29d..45d6aca051f3 100644 --- a/lib/efi_loader/efi_setup.c +++ b/lib/efi_loader/efi_setup.c @@ -8,6 +8,7 @@ #include #include #include +#include #define OBJ_LIST_NOT_INITIALIZED 1 @@ -102,6 +103,11 @@ efi_status_t efi_init_obj_list(void) /* On ARM switch from EL3 or secure mode to EL2 or non-secure mode */ switch_to_non_secure_mode(); +#ifdef CONFIG_EFI_VARIABLE_USE_ENV No clue what ENV refers to here as we are not talking about U-Boot environment variables anymore. How about CONFIG_EFI_PERSISTENT_VARIABLES. + /* Load non-volatile variables */ + env_efi_load(); Can't we make env_efi_load() a __weak function which does nothing. If we have a backend, that backend replaces the weak function. That way we restrict the config variables to the Makefile. Regards Heinrich +#endif + /* Define supported languages */ ret = efi_init_platform_lang(); if (ret != EFI_SUCCESS) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] efi_loader: bootmgr: make BootNext non-volatile
On 6/4/19 8:52 AM, AKASHI Takahiro wrote:
Signed-off-by: AKASHI Takahiro
Reviewed by: Heinrich Schuchardt
---
lib/efi_loader/efi_bootmgr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 43791422c819..b2102c5b5af2 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -210,7 +210,8 @@ efi_status_t efi_bootmgr_load(efi_handle_t *handle)
ret = EFI_CALL(efi_set_variable(
L"BootNext",
(efi_guid_t *)_global_variable_guid,
- 0, 0, ));
+ EFI_VARIABLE_NON_VOLATILE, 0,
+ ));
/* load BootNext */
if (ret == EFI_SUCCESS) {
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
Hi Fabio, > Hi Sjoerd, > > On Tue, Jun 4, 2019 at 4:58 PM Sjoerd Simons > wrote: > > > > From: Frieder Schrempf > > > > Add support for loading u-boot FIT images over the USB SDP protocol > > in the SPL > > > > Signed-off-by: Frieder Schrempf > > [Various build fixes] > > Signed-off-by: Sjoerd Simons > > Unfortunately, it still fails with imx_usb_loader due to the lack of > IVT. I do observe another issue - one of my "factory" board setup is not using (till now) OF_CONFIG. Without u-boot.img being a FitImage wrapped, the imx_usb_loader works correctly (with current mainline). After this change I do see the issue with imx_usb_loader. Unfortunately, applying this patch doesn't help. I will investigate this issue further tomorrow. > > Secure boot also needs IVT, so we need to find a way to insert IVT in > the FIT image. > > Tested with UUU and it worked, so this is progress :-) > > Tested-by: Fabio Estevam > > Thanks > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpGeiXMA96D7.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/7] cmd: efidebug: make some boot variables non-volatile
On 6/4/19 8:52 AM, AKASHI Takahiro wrote: Boot, BootOrder and BootNext should be non-volatile. Signed-off-by: AKASHI Takahiro Reviewed-by: Heinrich Schuchardt --- cmd/efidebug.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/cmd/efidebug.c b/cmd/efidebug.c index c4ac9dd634e2..e65722625455 100644 --- a/cmd/efidebug.c +++ b/cmd/efidebug.c @@ -558,6 +558,7 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag, } ret = EFI_CALL(RT->set_variable(var_name16, , + EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, size, data)); @@ -909,6 +910,7 @@ static int do_efi_boot_next(cmd_tbl_t *cmdtp, int flag, guid = efi_global_variable_guid; size = sizeof(u16); ret = EFI_CALL(RT->set_variable(L"BootNext", , + EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, size, )); @@ -964,6 +966,7 @@ static int do_efi_boot_order(cmd_tbl_t *cmdtp, int flag, guid = efi_global_variable_guid; ret = EFI_CALL(RT->set_variable(L"BootOrder", , + EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, size, bootorder)); ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 0/6] Convert mxsfb to DM_VIDEO
On Tue, 4 Jun 2019 00:05:55 +0300 Igor Opaniuk igor.opan...@gmail.com wrote: ... > Igor Opaniuk (6): > video: mxsfb: change mxs_lcd_init signature > video: mxsfb: reorder includes > video: mxsfb: refactor video_hw_init() > video: mxsfb: add DM_VIDEO support > ARM: dts: colibri_imx7: Add lcdif node > colibri_imx7_emmc: enable DM_VIDEO > > arch/arm/dts/imx7-colibri-emmc.dts | 2 + > arch/arm/dts/imx7-colibri.dtsi | 28 > arch/arm/mach-imx/cpu.c | 2 +- > arch/arm/mach-imx/mx7/soc.c | 2 +- > configs/colibri_imx7_emmc_defconfig | 2 +- > drivers/video/mxsfb.c | 219 +++- > include/configs/colibri_imx7.h | 2 +- > 7 files changed, 213 insertions(+), 44 deletions(-) Series applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] splash: display splash in DM_VIDEO configurations
On Wed, 29 May 2019 09:01:43 +
Igor Opaniuk igor.opan...@toradex.com wrote:
> Currently for CONFIG_DM_VIDEO=y setting splashimage env variable doesn't
> have any effect. Introduce a common function for both dm-video/lcd stacks,
> that checks env("splashimage") and invokes bmp_display() accordingly.
> For additional details please check discussion [1].
>
> [1] https://lists.denx.de/pipermail/u-boot/2019-May/371002.html
>
> Signed-off-by: Igor Opaniuk
> ---
> common/lcd.c | 10 +++---
> common/splash.c | 16 ++--
> common/stdio.c | 4
> include/splash.h | 6 +++---
> 4 files changed, 24 insertions(+), 12 deletions(-)
Applied to u-boot-video/master, thanks!
--
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] efi_loader: variable: split UEFI variables from U-Boot environment
On 6/4/19 8:52 AM, AKASHI Takahiro wrote:
UEFI volatile variables are managed in efi_var_htab while UEFI non-volatile
variables are in efi_nv_var_htab. At every SetVariable API, env_efi_save()
will also be called to save data cache (hash table) to persistent storage.
Signed-off-by: AKASHI Takahiro
---
lib/efi_loader/Kconfig| 10 +
lib/efi_loader/efi_variable.c | 342 ++
2 files changed, 275 insertions(+), 77 deletions(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index cd5436c576b1..8bf4b1754d06 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -18,6 +18,16 @@ config EFI_LOADER
if EFI_LOADER
+choice
+ prompt "Select variables storage"
+ default EFI_VARIABLE_USE_ENV
+
+config EFI_VARIABLE_USE_ENV
+ bool "Same device as U-Boot environment"
+ select ENV_EFI
+
+endchoice
+
config EFI_GET_TIME
bool "GetTime() runtime service"
depends on DM_RTC
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index e56053194dae..d9887be938c2 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -48,6 +48,66 @@
* converted to utf16?
*/
+/*
+ * We will maintain two variable database: one for volatile variables,
+ * the other for non-volatile variables. The former exists only in memory
+ * and will go away at re-boot. The latter is currently backed up by the same
+ * device as U-Boot environment and also works as variables cache.
+ *
+ * struct hsearch_data efi_var_htab
+ * struct hsearch_data efi_nv_var_htab
+ */
+
+static char *env_efi_get(const char *name, bool is_non_volatile)
+{
+ struct hsearch_data *htab;
+ ENTRY e, *ep;
+
+ /* WATCHDOG_RESET(); */
+
+ if (is_non_volatile)
+ htab = _nv_var_htab;
+ else
+ htab = _var_htab;
+
+ e.key = name;
+ e.data = NULL;
+ hsearch_r(e, FIND, , htab, 0);
+
+ return ep ? ep->data : NULL;
+}
+
+static int env_efi_set(const char *name, const char *value,
+ bool is_non_volatile)
+{
+ struct hsearch_data *htab;
+ ENTRY e, *ep;
+ int ret;
+
+ if (is_non_volatile)
+ htab = _nv_var_htab;
+ else
+ htab = _var_htab;
+
+ /* delete */
+ if (!value || *value == '\0') {
+ ret = hdelete_r(name, htab, H_PROGRAMMATIC);
+ return !ret;
+ }
+
+ /* set */
+ e.key = name;
+ e.data = (char *)value;
+ hsearch_r(e, ENTER, , htab, H_PROGRAMMATIC);
+ if (!ep) {
+ printf("## Error inserting \"%s\" variable, errno=%d\n",
+ name, errno);
+ return 1;
+ }
+
+ return 0;
+}
+
#define PREFIX_LEN (strlen("efi_----_"))
/**
@@ -147,24 +207,12 @@ static const char *parse_attr(const char *str, u32 *attrp)
return str;
}
-/**
- * efi_efi_get_variable() - retrieve value of a UEFI variable
- *
- * This function implements the GetVariable runtime service.
- *
- * See the Unified Extensible Firmware Interface (UEFI) specification for
- * details.
- *
- * @variable_name: name of the variable
- * @vendor:vendor GUID
- * @attributes:attributes of the variable
- * @data_size: size of the buffer to which the variable value is copied
- * @data: buffer to which the variable value is copied
- * Return: status code
- */
-efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
-const efi_guid_t *vendor, u32 *attributes,
-efi_uintn_t *data_size, void *data)
+static
+efi_status_t EFIAPI efi_get_variable_common(u16 *variable_name,
+ const efi_guid_t *vendor,
+ u32 *attributes,
+ efi_uintn_t *data_size, void *data,
+ bool is_non_volatile)
{
char *native_name;
efi_status_t ret;
@@ -172,22 +220,19 @@ efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
const char *val, *s;
u32 attr;
- EFI_ENTRY("\"%ls\" %pUl %p %p %p", variable_name, vendor, attributes,
- data_size, data);
-
if (!variable_name || !vendor || !data_size)
return EFI_EXIT(EFI_INVALID_PARAMETER);
ret = efi_to_native(_name, variable_name, vendor);
if (ret)
- return EFI_EXIT(ret);
+ return ret;
EFI_PRINT("get '%s'\n", native_name);
- val = env_get(native_name);
+ val = env_efi_get(native_name, is_non_volatile);
free(native_name);
if (!val)
- return EFI_EXIT(EFI_NOT_FOUND);
+ return EFI_NOT_FOUND;
val = parse_attr(val, );
@@ -198,7 +243,7 @@
Re: [U-Boot] [PATCH 1/2] watchdog: Split WDT from SPL_WDT
On Sun, 12 May 2019 23:34:52 +0200
Marek Vasut wrote:
> Use CONFIG_IS_ENABLED(WDT) to permit use of WDT in SPL without DM,
> while the full U-Boot can use rich DM/DT WDT driver.
>
> Signed-off-by: Marek Vasut
> Cc: Peng Fan
> Cc: Stefano Babic
> ---
> common/board_r.c | 2 +-
> common/spl/spl.c | 2 +-
> drivers/watchdog/Makefile | 2 +-
> include/asm-generic/global_data.h | 2 +-
> include/wdt.h | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/common/board_r.c b/common/board_r.c
> index 150e8cd424..988e40abb2 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -678,7 +678,7 @@ static init_fnc_t init_sequence_r[] = {
> #ifdef CONFIG_DM
> initr_dm,
> #endif
> -#if defined(CONFIG_WDT)
> +#if CONFIG_IS_ENABLED(WDT)
> initr_watchdog,
> #endif
> #if defined(CONFIG_ARM) || defined(CONFIG_NDS32) ||
> defined(CONFIG_RISCV) || \ diff --git a/common/spl/spl.c
> b/common/spl/spl.c index 0a6a47c202..f22f854718 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -601,7 +601,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> spl_board_init();
> #endif
>
> -#if defined(CONFIG_SPL_WATCHDOG_SUPPORT) && defined(CONFIG_WDT)
> +#if defined(CONFIG_SPL_WATCHDOG_SUPPORT) && CONFIG_IS_ENABLED(WDT)
> initr_watchdog();
> #endif
>
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 40b2f4bc66..4b94ae988c 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -16,7 +16,7 @@ obj-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
> obj-$(CONFIG_DESIGNWARE_WATCHDOG) += designware_wdt.o
> obj-$(CONFIG_TANGIER_WATCHDOG) += tangier_wdt.o
> obj-$(CONFIG_ULP_WATCHDOG) += ulp_wdog.o
> -obj-$(CONFIG_WDT) += wdt-uclass.o
> +obj-$(CONFIG_$(SPL_TPL_)WDT) += wdt-uclass.o
> obj-$(CONFIG_WDT_SANDBOX) += sandbox_wdt.o
> obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
> obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
> diff --git a/include/asm-generic/global_data.h
> b/include/asm-generic/global_data.h index 02a3ed6838..7c2220643b
> 100644 --- a/include/asm-generic/global_data.h
> +++ b/include/asm-generic/global_data.h
> @@ -137,7 +137,7 @@ typedef struct global_data {
> #if defined(CONFIG_TRANSLATION_OFFSET)
> fdt_addr_t translation_offset; /* optional
> translation offset */ #endif
> -#if defined(CONFIG_WDT)
> +#if CONFIG_IS_ENABLED(WDT)
> struct udevice *watchdog_dev;
> #endif
> } gd_t;
> diff --git a/include/wdt.h b/include/wdt.h
> index aa77d3e9b4..5bcff24ab3 100644
> --- a/include/wdt.h
> +++ b/include/wdt.h
> @@ -106,7 +106,7 @@ struct wdt_ops {
> int (*expire_now)(struct udevice *dev, ulong flags);
> };
>
> -#if defined(CONFIG_WDT)
> +#if CONFIG_IS_ENABLED(WDT)
> #ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS
> #define CONFIG_WATCHDOG_TIMEOUT_MSECS(60 * 1000)
> #endif
Tested-by: Lukasz Majewski
Test HW: display5 i.MX6Q device
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpHzqtFdpfwh.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] watchdog: imx: Add DM support
On Sun, 12 May 2019 23:34:53 +0200
Marek Vasut wrote:
> Add DM and DT probing support to iMX watchdog driver. This should
> allow boards to move over to this driver, enable SYSRESET_WATCHDOG
> to handle cpu_reset() if required.
>
> Signed-off-by: Marek Vasut
> Cc: Peng Fan
> Cc: Stefano Babic
> ---
> drivers/watchdog/Kconfig| 2 +-
> drivers/watchdog/imx_watchdog.c | 119
> +++- 2 files changed, 104 insertions(+),
> 17 deletions(-)
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index f909d40f45..b2ebe528ab 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -129,7 +129,7 @@ config XILINX_TB_WATCHDOG
>
> config IMX_WATCHDOG
> bool "Enable Watchdog Timer support for IMX and LSCH2 of NXP"
> - select HW_WATCHDOG
> + select HW_WATCHDOG if !WDT
> help
> Select this to enable the IMX and LSCH2 of Layerscape
> watchdog driver.
> diff --git a/drivers/watchdog/imx_watchdog.c
> b/drivers/watchdog/imx_watchdog.c index 14cc618074..53a3e9f5c7 100644
> --- a/drivers/watchdog/imx_watchdog.c
> +++ b/drivers/watchdog/imx_watchdog.c
> @@ -5,7 +5,9 @@
> */
>
> #include
> +#include
> #include
> +#include
> #include
> #include
> #ifdef CONFIG_FSL_LSCH2
> @@ -13,20 +15,40 @@
> #endif
> #include
>
> -#ifdef CONFIG_IMX_WATCHDOG
> -void hw_watchdog_reset(void)
> +static void imx_watchdog_expire_now(struct watchdog_regs *wdog)
> +{
> + clrsetbits_le16(>wcr, WCR_WT_MSK, WCR_WDE);
> +
> + writew(0x, >wsr);
> + writew(0x, >wsr); /* load minimum 1/2
> second timeout */
> + while (1) {
> + /*
> + * spin for .5 seconds before reset
> + */
> + }
> +}
> +
> +#if !defined(CONFIG_IMX_WATCHDOG) || \
> +(defined(CONFIG_IMX_WATCHDOG) && !CONFIG_IS_ENABLED(WDT))
> +void __attribute__((weak)) reset_cpu(ulong addr)
> {
> -#ifndef CONFIG_WATCHDOG_RESET_DISABLE
> struct watchdog_regs *wdog = (struct watchdog_regs
> *)WDOG1_BASE_ADDR;
> + imx_watchdog_expire_now(wdog);
> +}
> +#endif
> +
> +#if defined(CONFIG_IMX_WATCHDOG)
> +static void imx_watchdog_reset(struct watchdog_regs *wdog)
> +{
> +#ifndef CONFIG_WATCHDOG_RESET_DISABLE
> writew(0x, >wsr);
> writew(0x, >wsr);
> #endif /* CONFIG_WATCHDOG_RESET_DISABLE*/
> }
>
> -void hw_watchdog_init(void)
> +static void imx_watchdog_init(struct watchdog_regs *wdog)
> {
> - struct watchdog_regs *wdog = (struct watchdog_regs
> *)WDOG1_BASE_ADDR; u16 timeout;
>
> /*
> @@ -44,21 +66,86 @@ void hw_watchdog_init(void)
> writew(WCR_WDZST | WCR_WDBG | WCR_WDE | WCR_WDT | WCR_SRS |
> WCR_WDA | SET_WCR_WT(timeout), >wcr);
> #endif /* CONFIG_FSL_LSCH2*/
> - hw_watchdog_reset();
> + imx_watchdog_reset(wdog);
> }
> -#endif
>
> -void __attribute__((weak)) reset_cpu(ulong addr)
> +#if !CONFIG_IS_ENABLED(WDT)
> +void hw_watchdog_reset(void)
> {
> struct watchdog_regs *wdog = (struct watchdog_regs
> *)WDOG1_BASE_ADDR;
> - clrsetbits_le16(>wcr, WCR_WT_MSK, WCR_WDE);
> + imx_watchdog_reset(wdog);
> +}
>
> - writew(0x, >wsr);
> - writew(0x, >wsr); /* load minimum 1/2
> second timeout */
> - while (1) {
> - /*
> - * spin for .5 seconds before reset
> - */
> - }
> +void hw_watchdog_init(void)
> +{
> + struct watchdog_regs *wdog = (struct watchdog_regs
> *)WDOG1_BASE_ADDR; +
> + imx_watchdog_init(wdog);
> +}
> +#else
> +struct imx_wdt_priv {
> + void __iomem *base;
> +};
> +
> +static int imx_wdt_reset(struct udevice *dev)
> +{
> + struct imx_wdt_priv *priv = dev_get_priv(dev);
> +
> + imx_watchdog_reset(priv->base);
> +
> + return 0;
> +}
> +
> +static int imx_wdt_expire_now(struct udevice *dev, ulong flags)
> +{
> + struct imx_wdt_priv *priv = dev_get_priv(dev);
> +
> + imx_watchdog_expire_now(priv->base);
> + hang();
> +
> + return 0;
> +}
> +
> +static int imx_wdt_start(struct udevice *dev, u64 timeout, ulong
> flags) +{
> + struct imx_wdt_priv *priv = dev_get_priv(dev);
> +
> + imx_watchdog_init(priv->base);
> +
> + return 0;
> +}
> +
> +static int imx_wdt_probe(struct udevice *dev)
> +{
> + struct imx_wdt_priv *priv = dev_get_priv(dev);
> +
> + priv->base = dev_read_addr_ptr(dev);
> + if (!priv->base)
> + return -ENOENT;
> +
> + return 0;
> }
> +
> +static const struct wdt_ops imx_wdt_ops = {
> + .start = imx_wdt_start,
> + .reset = imx_wdt_reset,
> + .expire_now = imx_wdt_expire_now,
> +};
> +
> +static const struct udevice_id imx_wdt_ids[] = {
> + { .compatible = "fsl,imx21-wdt" },
> + {}
> +};
> +
> +U_BOOT_DRIVER(imx_wdt) = {
> + .name = "imx_wdt",
> + .id = UCLASS_WDT,
> + .of_match = imx_wdt_ids,
> + .probe = imx_wdt_probe,
> + .ops= _wdt_ops,
> +
Re: [U-Boot] [PATCH v3 2/7] efi_loader: variable: support non-volatile attribute
On 6/4/19 8:52 AM, AKASHI Takahiro wrote:
The attribute, EFI_VARIABLE_NON_VOLATILE, should be encoded as "nv" flag
in U-Boot variable if specified.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Heinrich Schuchardt
I will cherry-pick this patch. It is already showing relevant output:
Warning: e1000#0 using MAC address from ROM
OsIndicationsSupported: BS|RT, DataSize = 0x8
: 00 00 00 00 00 00 00 00
PlatformLang: NV|BS|RT, DataSize = 0x6
: 65 6e 2d 55 53 00en-US.
PlatformLangCodes: BS|RT, DataSize = 0x6
: 65 6e 2d 55 53 00en-US.
---
lib/efi_loader/efi_variable.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 50bc10537f40..e56053194dae 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -125,6 +125,8 @@ static const char *parse_attr(const char *str, u32 *attrp)
if ((s = prefix(str, "ro"))) {
attr |= READ_ONLY;
+ } else if ((s = prefix(str, "nv"))) {
+ attr |= EFI_VARIABLE_NON_VOLATILE;
} else if ((s = prefix(str, "boot"))) {
attr |= EFI_VARIABLE_BOOTSERVICE_ACCESS;
} else if ((s = prefix(str, "run"))) {
@@ -468,7 +470,7 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
}
}
- val = malloc(2 * data_size + strlen("{ro,run,boot}(blob)") + 1);
+ val = malloc(2 * data_size + strlen("{ro,run,boot,nv}(blob)") + 1);
if (!val) {
ret = EFI_OUT_OF_RESOURCES;
goto out;
@@ -480,12 +482,16 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
* store attributes
* TODO: several attributes are not supported
*/
- attributes &= (EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS);
+ attributes &= (EFI_VARIABLE_NON_VOLATILE |
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS);
s += sprintf(s, "{");
while (attributes) {
u32 attr = 1 << (ffs(attributes) - 1);
- if (attr == EFI_VARIABLE_BOOTSERVICE_ACCESS)
+ if (attr == EFI_VARIABLE_NON_VOLATILE)
+ s += sprintf(s, "nv");
+ else if (attr == EFI_VARIABLE_BOOTSERVICE_ACCESS)
s += sprintf(s, "boot");
else if (attr == EFI_VARIABLE_RUNTIME_ACCESS)
s += sprintf(s, "run");
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/7] env: save UEFI non-volatile variables in dedicated storage
On 6/4/19 8:52 AM, AKASHI Takahiro wrote: We need a variant of env_save()/env_load() to handle dedicated storage for UEFI variables. It is assumed that env_efi_load() will be called only ince at init and that env_efi_save() will be called at every SetVariable. In this patch, new parameters will be expected to be configured: CONFIG_ENV_EFI_FAT_DEVICE_AND_PART CONFIG_ENV_EFI_FAT_FILE in case of CONFIG_ENV_IS_IN_FAT. Signed-off-by: AKASHI Takahiro --- env/Kconfig | 39 env/env.c | 155 +- env/fat.c | 105 include/asm-generic/global_data.h | 3 + include/environment.h | 31 ++ 5 files changed, 332 insertions(+), 1 deletion(-) diff --git a/env/Kconfig b/env/Kconfig index 1e10c7a4c46b..a36b6ee48f10 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -399,6 +399,10 @@ config ENV_IS_IN_UBI the environment in. This will enable redundant environments in UBI. It is assumed that both volumes are in the same MTD partition. Our store will be completely unrelated to U-Boot environment variables. So why should we put anything into this Kconfig? +config ENV_EFI + bool + default n + config ENV_FAT_INTERFACE string "Name of the block device for the environment" depends on ENV_IS_IN_FAT @@ -438,6 +442,34 @@ config ENV_FAT_FILE It's a string of the FAT file name. This file use to store the environment. +config ENV_EFI_FAT_DEVICE_AND_PART + string "Device and partition for where to store the UEFI non-volatile variables in FAT" + depends on ENV_IS_IN_FAT + depends on ENV_EFI + help + Define this to a string to specify the partition of the device. It can + be as following: The following information is not specific to this variable. So we can cut it short: "String defining the device number and the partition number in the format :, e.g. 0:1." Where do you specify on which subsystem (mmc, scsi, sata, nvme) the file is stored? I would prefer nopt to have a restriction to FAT. If the EXT4 driver is enabled writing and reading to an ext4 valume should work as well. When calling fs_set_blk_dev() you will not specify any file system. + + "D:P", "D:0", "D", "D:" or "D:auto" (D, P are integers. And P >= 1) + - "D:P": device D partition P. Error occurs if device D has no + partition table. + - "D:0": device D. + - "D" or "D:": device D partition 1 if device D has partition + table, or the whole device D if has no partition + table. + - "D:auto": first partition in device D with bootable flag set. + If none, first valid partition in device D. If no + partition table then means device D. + +config ENV_EFI_FAT_FILE + string "Name of the FAT file to use for the UEFI non-volatile variables" %s/UEFI non-volatile variables/non-volatile UEFI variables/ No need for the file system being FAT. + depends on ENV_IS_IN_FAT + depends on ENV_EFI + default "uboot_efi.env" + help + It's a string of the FAT file name. This file use to store the It is obvious that afile name is a string. But why restrict to a file name? This could also be a path to a non-root file: "Path of the file used to store non-volatile UEFI variables." But can't we simply have a single variable, where we put all parts of the definition, e.g. mmc 0:1 /EFI/nv-var.store + UEFI non-volatile variables. + config ENV_EXT4_INTERFACE string "Name of the block device for the environment" depends on ENV_IS_IN_EXT4 @@ -470,6 +502,13 @@ config ENV_EXT4_FILE It's a string of the EXT4 file name. This file use to store the environment (explicit path to the file) +config ENV_EFI_SIZE + hex "UEFI Variables Environment Size" + depends on ENV_EFI + default 0x2 If we are writing to a file, the available space on the partition and in RAM is the limit. I see no need for this variable in this case. + help + Size of the UEFI variables storage area + if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL || ARC || ARCH_STM32MP config ENV_OFFSET diff --git a/env/env.c b/env/env.c index 4b417b90a291..202079f6d4c0 100644 --- a/env/env.c +++ b/env/env.c We are not creating a driver for U-Boot environment variables. So I would keep away from the code in this directory. You can put the load and save function into lib/efi_loader/ and use the normal file-system functions there to read and write the file. Essentially I expect we will end up with a class of drivers which we can use as backends for nv variables, e.g. * file storage * OP-TEE module * U-Boot variables * none Best regards
[U-Boot] [PATCH] ARM: socfpga: update CONFIG_SPL_FS_LOAD_PAYLOAD_NAME to u-boot.img
From: Dalon Westergreen Bring cyclone5 / arria5 / arria10 in line with convention and use u-boot.img as CONFIG_SPL_FS_LOAD_PAYLOAD_NAME. Signed-off-by: Dalon Westergreen --- include/configs/socfpga_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index d1034ac280..36b0ed5459 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -203,7 +203,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void); /* SPL SDMMC boot support */ #ifdef CONFIG_SPL_MMC_SUPPORT #if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4) -#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot-dtb.img" +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img" #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 #endif #else -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] ARM: socfpga: stratix10: Remove CONFIG_OF_EMBED
From: Dalon Westergreen CONFIG_OF_EMBED was primarily enabled to support the stratix10 spl hex file requirements. Since this option now produces a warning during build, and the spl hex can be created using alternate methods, CONFIG_OF_EMBED is no longer needed. Signed-off-by: Dalon Westergreen --- Changes in v3: -> Revert to u-boot.img for SPL payload name Changes in v2: -> Change CONFIG_SPL_TARGET back to u-boot-spl.hex --- configs/socfpga_stratix10_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/socfpga_stratix10_defconfig b/configs/socfpga_stratix10_defconfig index fbab388b43..f27180385d 100644 --- a/configs/socfpga_stratix10_defconfig +++ b/configs/socfpga_stratix10_defconfig @@ -26,7 +26,6 @@ CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y -CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk" CONFIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] Makefile: Add target to generate hex output for combined spl and dtb
From: Dalon Westergreen
Stratix10 requires a hex image of the spl plus spl devicetree offset to
the Stratix10 onchip memory located at SPL_TEXT_BASE. This patch adds
a target to generate a hex file from the u-boot-spl binary including the
dtb offset at SPL_TEST_BASE.
Objcopy is used to convert the $(SPL_BIN).bin, which includes the spl
dtb, to a hex file. the --change-address option is used to offset the
hex to SPL_TEXT_BASE as objcopy on the spl binary will not result in
a hex file appropriately offset at SPL_TEXT_BASE.
Signed-off-by: Dalon Westergreen
---
Changes in v3:
-> Cleanup commit message and better describe the problem being
resolved
-> Remove extraneous hunk
-> use SPL_BIN instead of u-boot-spl
Changes in v2:
-> Move spl hex file generation to SPL Makefile
-> Create hexfile from $(SPL_BIN).bin which will include the dtb
ifneq(build_dtb,)
---
Makefile | 9 -
scripts/Makefile.spl | 7 +++
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 07106138e9..12e36ebb72 100644
--- a/Makefile
+++ b/Makefile
@@ -1124,11 +1124,6 @@ OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
$(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec) \
$(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR),-R .bootpg -R
.resetvec)
-OBJCOPYFLAGS_u-boot-spl.hex = $(OBJCOPYFLAGS_u-boot.hex)
-
-spl/u-boot-spl.hex: spl/u-boot-spl FORCE
- $(call if_changed,objcopy)
-
binary_size_check: u-boot-nodtb.bin FORCE
@file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
map_size=$(shell cat u-boot.map | \
@@ -1707,6 +1702,10 @@ u-boot.lds: $(LDSCRIPT) prepare FORCE
spl/u-boot-spl.bin: spl/u-boot-spl
@:
+
+spl/u-boot-spl.hex: spl/u-boot-spl
+ @:
+
spl/u-boot-spl: tools prepare \
$(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATDATA),dts/dt.dtb) \
$(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATDATA),dts/dt.dtb)
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 7af6b120b6..551002194e 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -216,6 +216,8 @@ ifneq
($(CONFIG_TARGET_SOCFPGA_GEN5)$(CONFIG_TARGET_SOCFPGA_ARRIA10),)
ALL-y += $(obj)/$(SPL_BIN).sfp
endif
+ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/$(SPL_BIN).hex
+
ifdef CONFIG_ARCH_SUNXI
ALL-y += $(obj)/sunxi-spl.bin
@@ -363,6 +365,11 @@ endif
$(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mkimage)
+OBJCOPYFLAGS_$(SPL_BIN).hex := -I binary -O ihex
--change-address=$(CONFIG_SPL_TEXT_BASE)
+
+$(obj)/$(SPL_BIN).hex: $(obj)/$(SPL_BIN).bin FORCE
+ $(call if_changed,objcopy)
+
quiet_cmd_mksunxiboot = MKSUNXI $@
cmd_mksunxiboot = $(objtree)/tools/mksunxiboot \
--default-dt $(CONFIG_DEFAULT_DEVICE_TREE) $< $@
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
On Tue, 2019-06-04 at 17:19 -0300, Fabio Estevam wrote: > Hi Sjoerd, > > On Tue, Jun 4, 2019 at 4:58 PM Sjoerd Simons > wrote: > > From: Frieder Schrempf > > > > Add support for loading u-boot FIT images over the USB SDP protocol > > in > > the SPL > > > > Signed-off-by: Frieder Schrempf > > [Various build fixes] > > Signed-off-by: Sjoerd Simons > > Unfortunately, it still fails with imx_usb_loader due to the lack of > IVT. > > Secure boot also needs IVT, so we need to find a way to insert IVT in > the FIT image. > > Tested with UUU and it worked, so this is progress :-) Small steps right; Ooi what imx_usb_loader configuration/commands are you using to test this? (I find its config rather tricky to grasp). One of the next things I will need to look at is actually secure boot.. That said why does imx_usb_loader if the board isn't locked? > Tested-by: Fabio Estevam > > Thanks -- Sjoerd Simons Collabora Ltd. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] pinctrl: meson-gxbb: add hdmi related pins
The GXBB pinctrl is missing pins related to HDMI, namely hot plug
detection (hpd) and I2C (sda + scl).
This fixes HDMI support for GXBB in u-boot.
Reported-by: Mohammad Rasim
Signed-off-by: Maxime Jourdan
---
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
index 59b5be6211..9e2e151164 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxbb.c
@@ -61,6 +61,10 @@ static const unsigned int eth_txd1_pins[]= {
PIN(GPIOZ_11, EE_OFF) };
static const unsigned int eth_txd2_pins[] = { PIN(GPIOZ_12, EE_OFF) };
static const unsigned int eth_txd3_pins[] = { PIN(GPIOZ_13, EE_OFF) };
+static const unsigned int hdmi_hpd_pins[] = { PIN(GPIOH_0, EE_OFF) };
+static const unsigned int hdmi_sda_pins[] = { PIN(GPIOH_1, EE_OFF) };
+static const unsigned int hdmi_scl_pins[] = { PIN(GPIOH_2, EE_OFF) };
+
static const unsigned int uart_tx_ao_a_pins[] = { PIN(GPIOAO_0, 0) };
static const unsigned int uart_rx_ao_a_pins[] = { PIN(GPIOAO_1, 0) };
static const unsigned int uart_cts_ao_a_pins[] = { PIN(GPIOAO_2, 0) };
@@ -232,6 +236,11 @@ static struct meson_pmx_group meson_gxbb_periphs_groups[]
= {
GROUP(eth_txd2, 6, 3),
GROUP(eth_txd3, 6, 2),
+ /* Bank H */
+ GROUP(hdmi_hpd, 1, 26),
+ GROUP(hdmi_sda, 1, 25),
+ GROUP(hdmi_scl, 1, 24),
+
/* Bank DV */
GROUP(uart_tx_b,2, 29),
GROUP(uart_rx_b,2, 28),
@@ -351,6 +360,14 @@ static const char * const eth_groups[] = {
"eth_txd0", "eth_txd1", "eth_txd2", "eth_txd3",
};
+static const char * const hdmi_hpd_groups[] = {
+ "hdmi_hpd",
+};
+
+static const char * const hdmi_i2c_groups[] = {
+ "hdmi_sda", "hdmi_scl",
+};
+
static const char * const gpio_aobus_groups[] = {
"GPIOAO_0", "GPIOAO_1", "GPIOAO_2", "GPIOAO_3", "GPIOAO_4",
"GPIOAO_5", "GPIOAO_6", "GPIOAO_7", "GPIOAO_8", "GPIOAO_9",
@@ -383,6 +400,8 @@ static struct meson_pmx_func meson_gxbb_periphs_functions[]
= {
FUNCTION(uart_b),
FUNCTION(uart_c),
FUNCTION(eth),
+ FUNCTION(hdmi_hpd),
+ FUNCTION(hdmi_i2c),
};
static struct meson_pmx_func meson_gxbb_aobus_functions[] = {
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] video: meson: hdmi-supply regulator should be optional
Some boards don't have such a regulator, and don't need one to enable
HDMI display. Make it optional, fixing hdmi display for those boards.
Also surround the regulator code with a config check on DM_REGULATOR.
Reported-by: Mohammad Rasim
Signed-off-by: Maxime Jourdan
---
drivers/video/meson/meson_dw_hdmi.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/video/meson/meson_dw_hdmi.c
b/drivers/video/meson/meson_dw_hdmi.c
index 7a1c060856..483c93f6b6 100644
--- a/drivers/video/meson/meson_dw_hdmi.c
+++ b/drivers/video/meson/meson_dw_hdmi.c
@@ -361,13 +361,19 @@ static int meson_dw_hdmi_probe(struct udevice *dev)
priv->hdmi.i2c_clk_high = 0x67;
priv->hdmi.i2c_clk_low = 0x78;
+#if CONFIG_IS_ENABLED(DM_REGULATOR)
ret = device_get_supply_regulator(dev, "hdmi-supply", );
- if (ret)
+ if (ret && ret != -ENOENT) {
+ pr_err("Failed to get HDMI regulator\n");
return ret;
+ }
- ret = regulator_set_enable(supply, true);
- if (ret)
- return ret;
+ if (!ret) {
+ ret = regulator_set_enable(supply, true);
+ if (ret)
+ return ret;
+ }
+#endif
ret = reset_get_bulk(dev, );
if (ret)
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] mx6sabreauto: Enable SPL SDP support
On Tue, Jun 4, 2019 at 4:56 PM Sjoerd Simons wrote: > > To allow loading u-boot over USB enable SDP support in the SPL. > > Signed-off-by: Sjoerd Simons Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] mx6sabreauto: Remove CONFIG_SPL_DM to decrease the SPL size
On Tue, Jun 4, 2019 at 4:57 PM Sjoerd Simons wrote: > > The i.mx6 SPL binary cannot be bigger then 68K, while with the current > defconfig for sabreauto it's only about 56K as soon as USB support gets > added the size will overflows. > > Signed-off-by: Sjoerd Simons Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
Hi Sjoerd, On Tue, Jun 4, 2019 at 4:58 PM Sjoerd Simons wrote: > > From: Frieder Schrempf > > Add support for loading u-boot FIT images over the USB SDP protocol in > the SPL > > Signed-off-by: Frieder Schrempf > [Various build fixes] > Signed-off-by: Sjoerd Simons Unfortunately, it still fails with imx_usb_loader due to the lack of IVT. Secure boot also needs IVT, so we need to find a way to insert IVT in the FIT image. Tested with UUU and it worked, so this is progress :-) Tested-by: Fabio Estevam Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] efi_loader: close protocols in UnloadImage()
When UnloadImage() is called all protocols opened by the image have to be
closed.
Signed-off-by: Heinrich Schuchardt
---
v2
Closing a protocol may have side effects. So restart looping
after each closed protocol.
---
lib/efi_loader/efi_boottime.c | 38 +--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index b64ca54dbc..7d1d6e9213 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -2879,12 +2879,46 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t
image_handle,
* @image_obj: handle of the loaded image
* @loaded_image_protocol: loaded image protocol
*/
-static void efi_delete_image(struct efi_loaded_image_obj *image_obj,
-struct efi_loaded_image *loaded_image_protocol)
+static efi_status_t efi_delete_image
+ (struct efi_loaded_image_obj *image_obj,
+struct efi_loaded_image *loaded_image_protocol)
{
+ struct efi_object *efiobj;
+ efi_status_t r, ret = EFI_SUCCESS;
+
+close_next:
+ list_for_each_entry(efiobj, _obj_list, link) {
+ struct efi_handler *protocol;
+
+ list_for_each_entry(protocol, >protocols, link) {
+ struct efi_open_protocol_info_item *info;
+
+ list_for_each_entry(info, >open_infos, link) {
+ if (info->info.agent_handle !=
+ (efi_handle_t)image_obj)
+ continue;
+ r = EFI_CALL(efi_close_protocol
+ (efiobj, protocol->guid,
+info->info.agent_handle,
+info->info.controller_handle
+ ));
+ if (r != EFI_SUCCESS)
+ ret = r;
+ /*
+* Closing protocols may results in further
+* items being deleted. To play it safe loop
+* over all elements again.
+*/
+ goto close_next;
+ }
+ }
+ }
+
efi_free_pages((uintptr_t)loaded_image_protocol->image_base,
efi_size_in_pages(loaded_image_protocol->image_size));
efi_delete_handle(_obj->header);
+
+ return ret;
}
/**
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] mx6sabreauto: Select pinctrl driver
On Tue, 2019-06-04 at 11:15 -0300, Fabio Estevam wrote: > Hi Sjoerd, > > On Mon, Jun 3, 2019 at 4:01 PM Sjoerd Simons > wrote: > > With the conversion to DM we should select the pinctrl driver. > > > > Signed-off-by: Sjoerd Simons > > I did the same for mx6sabresd initially, but then later I realized > that it would be better to fix this globally like this: > https://lists.denx.de/pipermail/u-boot/2019-May/370740.html > > Hopefully Stefano can apply this version and then we can fix all i.MX > boards that were converted to DM automatically. Agreed that is a better solution -- Sjoerd Simons Collabora Ltd. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: Select the pinctrl drivers when DM is used
On Fri, 2019-05-24 at 09:50 -0300, Fabio Estevam wrote: > When using device model it is required to select the pinctrl > drivers so that the pins can be properly configured via > devicetree. > > mx6sabreauto board is an example of a target that uses DM and does > not select the pinctrl drivers. > > Instead of doing the pinctrl driver selection in each individual > defconfig file, select it at SoC level when DM is used. > > Signed-off-by: Fabio Estevam Reviewed-by: Sjoerd Simons > --- > arch/arm/Kconfig | 8 > 1 file changed, 8 insertions(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index efb9aab390..4c361c9a1d 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -787,6 +787,8 @@ config ARCH_MX31 > config ARCH_MX7ULP > bool "NXP MX7ULP" > select CPU_V7A > + select PINCTRL if DM > + select PINCTRL_IMX7ULP if DM > select ROM_UNIFIED_SECTIONS > imply MXC_GPIO > > @@ -795,6 +797,8 @@ config ARCH_MX7 > select ARCH_MISC_INIT > select BOARD_EARLY_INIT_F > select CPU_V7A > + select PINCTRL if DM > + select PINCTRL_IMX7 if DM > select SYS_FSL_HAS_SEC if SECURE_BOOT > select SYS_FSL_SEC_COMPAT_4 > select SYS_FSL_SEC_LE > @@ -803,6 +807,8 @@ config ARCH_MX7 > config ARCH_MX6 > bool "Freescale MX6" > select CPU_V7A > + select PINCTRL if DM > + select PINCTRL_IMX6 if DM > select SYS_FSL_HAS_SEC if SECURE_BOOT > select SYS_FSL_SEC_COMPAT_4 > select SYS_FSL_SEC_LE > @@ -818,6 +824,8 @@ config ARCH_MX5 > bool "Freescale MX5" > select BOARD_EARLY_INIT_F > select CPU_V7A > + select PINCTRL if DM > + select PINCTRL_IMX5 if DM > imply MXC_GPIO > > config ARCH_OWL -- Sjoerd Simons Collabora Ltd. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv3] ARM: zynq: Add configuration for Z-turn board
From: Anton Gerasimov
Basic (PS-only) configuration based on Vivado board files by
Sergiusz Bazanski
Signed-off-by: Anton Gerasimov
---
board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c | 281
1 file changed, 281 insertions(+)
create mode 100644 board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c
diff --git a/board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c
new file mode 100644
index 00..d4f0ee796f
--- /dev/null
+++ b/board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c
@@ -0,0 +1,281 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) Xilinx, Inc.
+ */
+
+#include
+
+static unsigned long ps7_pll_init_data[] = {
+ EMIT_WRITE(0xF808, 0xDF0DU),
+ EMIT_MASKWRITE(0xF8000110, 0x0030U, 0x000FA220U),
+ EMIT_MASKWRITE(0xF8000100, 0x0007F000U, 0x00028000U),
+ EMIT_MASKWRITE(0xF8000100, 0x0010U, 0x0010U),
+ EMIT_MASKWRITE(0xF8000100, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000100, 0x0001U, 0xU),
+ EMIT_MASKPOLL(0xF800010C, 0x0001U),
+ EMIT_MASKWRITE(0xF8000100, 0x0010U, 0xU),
+ EMIT_MASKWRITE(0xF8000120, 0x1F003F30U, 0x1F000200U),
+ EMIT_MASKWRITE(0xF8000114, 0x0030U, 0x0012C220U),
+ EMIT_MASKWRITE(0xF8000104, 0x0007F000U, 0x0002U),
+ EMIT_MASKWRITE(0xF8000104, 0x0010U, 0x0010U),
+ EMIT_MASKWRITE(0xF8000104, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000104, 0x0001U, 0xU),
+ EMIT_MASKPOLL(0xF800010C, 0x0002U),
+ EMIT_MASKWRITE(0xF8000104, 0x0010U, 0xU),
+ EMIT_MASKWRITE(0xF8000124, 0xFFF3U, 0x0C23U),
+ EMIT_MASKWRITE(0xF8000118, 0x0030U, 0x001452C0U),
+ EMIT_MASKWRITE(0xF8000108, 0x0007F000U, 0x0001E000U),
+ EMIT_MASKWRITE(0xF8000108, 0x0010U, 0x0010U),
+ EMIT_MASKWRITE(0xF8000108, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000108, 0x0001U, 0xU),
+ EMIT_MASKPOLL(0xF800010C, 0x0004U),
+ EMIT_MASKWRITE(0xF8000108, 0x0010U, 0xU),
+ EMIT_WRITE(0xF804, 0x767BU),
+ EMIT_EXIT(),
+};
+
+static unsigned long ps7_clock_init_data[] = {
+ EMIT_WRITE(0xF808, 0xDF0DU),
+ EMIT_MASKWRITE(0xF8000128, 0x03F03F01U, 0x00700F01U),
+ EMIT_MASKWRITE(0xF8000138, 0x0011U, 0x0001U),
+ EMIT_MASKWRITE(0xF8000140, 0x03F03F71U, 0x00100801U),
+ EMIT_MASKWRITE(0xF800014C, 0x3F31U, 0x0501U),
+ EMIT_MASKWRITE(0xF8000150, 0x3F33U, 0x1401U),
+ EMIT_MASKWRITE(0xF8000154, 0x3F33U, 0x0A03U),
+ EMIT_MASKWRITE(0xF800015C, 0x03F03F33U, 0x00200501U),
+ EMIT_MASKWRITE(0xF8000160, 0x007F007FU, 0xU),
+ EMIT_MASKWRITE(0xF8000168, 0x3F31U, 0x0501U),
+ EMIT_MASKWRITE(0xF8000170, 0x03F03F30U, 0x00200500U),
+ EMIT_MASKWRITE(0xF8000180, 0x03F03F30U, 0x00400500U),
+ EMIT_MASKWRITE(0xF80001C4, 0x0001U, 0x0001U),
+ EMIT_MASKWRITE(0xF800012C, 0x01FFCCCDU, 0x01FD044DU),
+ EMIT_WRITE(0xF804, 0x767BU),
+ EMIT_EXIT(),
+};
+
+static unsigned long ps7_ddr_init_data[] = {
+ EMIT_MASKWRITE(0xF8006000, 0x0001U, 0x0080U),
+ EMIT_MASKWRITE(0xF8006004, 0x0007U, 0x1082U),
+ EMIT_MASKWRITE(0xF8006008, 0x03FFU, 0x03C0780FU),
+ EMIT_MASKWRITE(0xF800600C, 0x03FFU, 0x02001001U),
+ EMIT_MASKWRITE(0xF8006010, 0x03FFU, 0x00014001U),
+ EMIT_MASKWRITE(0xF8006014, 0x001FU, 0x0004285BU),
+ EMIT_MASKWRITE(0xF8006018, 0xF7FFU, 0x44E458D3U),
+ EMIT_MASKWRITE(0xF800601C, 0xU, 0x7282BCE5U),
+ EMIT_MASKWRITE(0xF8006020, 0x7FDCU, 0x270872D0U),
+ EMIT_MASKWRITE(0xF8006024, 0x0FC3U, 0xU),
+ EMIT_MASKWRITE(0xF8006028, 0x3FFFU, 0x2007U),
+ EMIT_MASKWRITE(0xF800602C, 0xU, 0x0008U),
+ EMIT_MASKWRITE(0xF8006030, 0xU, 0x00040B30U),
+ EMIT_MASKWRITE(0xF8006034, 0x13FF3FFFU, 0x000116D4U),
+ EMIT_MASKWRITE(0xF8006038, 0x0003U, 0xU),
+ EMIT_MASKWRITE(0xF800603C, 0x000FU, 0x0777U),
+ EMIT_MASKWRITE(0xF8006040, 0xU, 0xFFF0U),
+ EMIT_MASKWRITE(0xF8006044, 0x0FFFU, 0x0F66U),
+ EMIT_MASKWRITE(0xF8006048, 0x0003F03FU, 0x0003C008U),
+ EMIT_MASKWRITE(0xF8006050, 0xFF0F8FFFU, 0x77010800U),
+ EMIT_MASKWRITE(0xF8006058, 0x0001U, 0xU),
+ EMIT_MASKWRITE(0xF800605C, 0xU, 0x5003U),
+ EMIT_MASKWRITE(0xF8006060, 0x17FFU, 0x003EU),
+ EMIT_MASKWRITE(0xF8006064, 0x00021FE0U, 0x0002U),
+ EMIT_MASKWRITE(0xF8006068, 0x03FFU, 0x00284141U),
+ EMIT_MASKWRITE(0xF800606C, 0xU, 0x1610U),
+ EMIT_MASKWRITE(0xF8006078, 0x03FFU, 0x00466111U),
+ EMIT_MASKWRITE(0xF800607C, 0x000FU, 0x0003U),
+ EMIT_MASKWRITE(0xF80060A4, 0xU,
[U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
From: Frieder Schrempf
Add support for loading u-boot FIT images over the USB SDP protocol in
the SPL
Signed-off-by: Frieder Schrempf
[Various build fixes]
Signed-off-by: Sjoerd Simons
---
Changes in v2:
- Fix build with CMD_USB_SDP
- Add SoB from Frieder Schrempf
common/spl/spl_sdp.c | 12 ++---
drivers/usb/gadget/f_sdp.c | 53 +-
include/sdp.h | 9 ++-
3 files changed, 63 insertions(+), 11 deletions(-)
diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
index 807256e908..51b245b886 100644
--- a/common/spl/spl_sdp.c
+++ b/common/spl/spl_sdp.c
@@ -25,10 +25,14 @@ static int spl_sdp_load_image(struct spl_image_info
*spl_image,
return -ENODEV;
}
- /* This command typically does not return but jumps to an image */
- sdp_handle(controller_index);
- pr_err("SDP ended\n");
+ /*
+* This command either loads a legacy image, jumps and never returns,
+* or it loads a FIT image and returns it to be handled by the SPL
+* code.
+*/
+ ret = spl_sdp_handle(controller_index, spl_image);
+ debug("SDP ended\n");
- return -EINVAL;
+ return ret;
}
SPL_LOAD_IMAGE_METHOD("USB SDP", 0, BOOT_DEVICE_BOARD, spl_sdp_load_image);
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index ae97ab2b49..fab7ce6f97 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -638,7 +638,20 @@ static u32 sdp_jump_imxheader(void *address)
return 0;
}
-static void sdp_handle_in_ep(void)
+#ifdef CONFIG_SPL_BUILD
+#ifdef CONFIG_SPL_LOAD_FIT
+static ulong sdp_fit_read(struct spl_load_info *load, ulong sector,
+ ulong count, void *buf)
+{
+ debug("%s: sector %lx, count %lx, buf %lx\n",
+ __func__, sector, count, (ulong)buf);
+ memcpy(buf, (void *)(load->dev + sector), count);
+ return count;
+}
+#endif
+#endif
+
+static void sdp_handle_in_ep(struct spl_image_info *spl_image)
{
u8 *data = sdp_func->in_req->buf;
u32 status;
@@ -690,10 +703,25 @@ static void sdp_handle_in_ep(void)
/* If imx header fails, try some U-Boot specific headers */
if (status) {
#ifdef CONFIG_SPL_BUILD
+ image_header_t *header =
+ sdp_ptr(sdp_func->jmp_address);
+#ifdef CONFIG_SPL_LOAD_FIT
+ if (image_get_magic(header) == FDT_MAGIC) {
+ struct spl_load_info load;
+
+ debug("Found FIT\n");
+ load.dev = header;
+ load.bl_len = 1;
+ load.read = sdp_fit_read;
+ spl_load_simple_fit(spl_image, , 0,
+ header);
+
+ return;
+ }
+#endif
/* In SPL, allow jumps to U-Boot images */
struct spl_image_info spl_image = {};
- spl_parse_image_header(_image,
- (struct image_header *)sdp_func->jmp_address);
+ spl_parse_image_header(_image, header);
jump_to_image_no_args(_image);
#else
/* In U-Boot, allow jumps to scripts */
@@ -715,19 +743,32 @@ static void sdp_handle_in_ep(void)
};
}
-void sdp_handle(int controller_index)
+#ifndef CONFIG_SPL_BUILD
+int sdp_handle(int controller_index)
+#else
+int spl_sdp_handle(int controller_index, struct spl_image_info *spl_image)
+#endif
{
printf("SDP: handle requests...\n");
while (1) {
if (ctrlc()) {
puts("\rCTRL+C - Operation aborted.\n");
- return;
+ return -EINVAL;
}
+#ifdef CONFIG_SPL_BUILD
+ if (spl_image->flags & SPL_FIT_FOUND)
+ return 0;
+#endif
+
WATCHDOG_RESET();
usb_gadget_handle_interrupts(controller_index);
- sdp_handle_in_ep();
+#ifdef CONFIG_SPL_BUILD
+ sdp_handle_in_ep(spl_image);
+#else
+ sdp_handle_in_ep(NULL);
+#endif
}
}
diff --git a/include/sdp.h b/include/sdp.h
index f6252d027f..6ac64fb1f3 100644
--- a/include/sdp.h
+++ b/include/sdp.h
@@ -10,6 +10,13 @@
#define __SDP_H_
int sdp_init(int controller_index);
-void sdp_handle(int controller_index);
+
+#ifdef CONFIG_SPL_BUILD
+#include
+
+int spl_sdp_handle(int controller_index, struct spl_image_info *spl_image);
+#else
+int sdp_handle(int controller_index);
+#endif
#endif /* __SDP_H_ */
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] mx6sabreauto: Remove CONFIG_SPL_DM to decrease the SPL size
The i.mx6 SPL binary cannot be bigger then 68K, while with the current defconfig for sabreauto it's only about 56K as soon as USB support gets added the size will overflows. Signed-off-by: Sjoerd Simons --- Changes in v2: None configs/mx6sabreauto_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig index dc758d7aaf..f9c70c5189 100644 --- a/configs/mx6sabreauto_defconfig +++ b/configs/mx6sabreauto_defconfig @@ -55,7 +55,6 @@ CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y -CONFIG_SPL_DM=y CONFIG_DFU_MMC=y CONFIG_DFU_SF=y CONFIG_DM_GPIO=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] Enable usage of SDP for i.MX6 Sabre Auto Boards
Being able to upload u-boot over USB is rather useful, so ideally this functionality should be enabled by the default config for these boards. Currently however no USB support is built into the SPL nor is SDP enabled for i.MX6 Sabre Auto boards. This round only has the patches needed for SDP support, the somewhat unrelated fixes have been been sent seperately (but without the u-boot image will fail to boot). And ofcourse fixes the build problem reported by Fabio. The first patch drops SPL DM support as there is no way to fit that *and* USB support in at the momenT. The seconds patch enabled USB & SPL SDP support for the board. Patch three adds support for loading FIT images over SDP as that is what is in use for the Sabre auto's main u-boot image. Patchset tested by using uuu with the following configuration: ``` uuu_version 1.2 SDP: boot -f SPL SDPU: write -f u-boot-dtb.img -addr 0x1000 SDPU: jump -addr 0x1000 SDPU: done ``` Changes in v2: - Fix build with CMD_USB_SDP - Add SoB from Frieder Schrempf Frieder Schrempf (1): usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP Sjoerd Simons (2): mx6sabreauto: Remove CONFIG_SPL_DM to decrease the SPL size mx6sabreauto: Enable SPL SDP support common/spl/spl_sdp.c | 12 +--- configs/mx6sabreauto_defconfig | 4 ++- drivers/usb/gadget/f_sdp.c | 53 ++ include/sdp.h | 9 +- 4 files changed, 66 insertions(+), 12 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] mx6sabreauto: Enable SPL SDP support
To allow loading u-boot over USB enable SDP support in the SPL. Signed-off-by: Sjoerd Simons --- Changes in v2: None configs/mx6sabreauto_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig index f9c70c5189..558b1cd996 100644 --- a/configs/mx6sabreauto_defconfig +++ b/configs/mx6sabreauto_defconfig @@ -26,6 +26,9 @@ CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_FIT_IMAGE_TINY=y CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y +CONFIG_SPL_USB_HOST_SUPPORT=y +CONFIG_SPL_USB_GADGET=y +CONFIG_SPL_USB_SDP_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v0 2/2] efi_loader: check timer events in Stall()
During a call to Stall() we should periodically check for timer events. This requires exporting function usec_to_tick() which further allows to remove redundant implementation of usec_to_tick() in rk_timer.c. v2 Remove redundant implementation of usec_to_tick() in rk_timer.c. Heinrich Schuchardt (2): lib: time: export usec_to_tick() efi_loader: check timer events in Stall() arch/arm/mach-rockchip/rk_timer.c | 7 --- include/time.h| 9 + lib/efi_loader/efi_boottime.c | 8 +++- lib/time.c| 2 +- 4 files changed, 17 insertions(+), 9 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] efi_loader: check timer events in Stall()
During a call to Stall() we should periodically check for timer events.
Signed-off-by: Heinrich Schuchardt
---
v2
Remove redundant implementation of usec_to_tick() in
arch/arm/mach-rockchip/rk_timer.c
---
lib/efi_loader/efi_boottime.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 5714deca70..b64ca54dbc 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1990,8 +1990,14 @@ out:
*/
static efi_status_t EFIAPI efi_stall(unsigned long microseconds)
{
+ u64 end_tick;
+
EFI_ENTRY("%ld", microseconds);
- udelay(microseconds);
+
+ end_tick = get_ticks() + usec_to_tick(microseconds);
+ while (get_ticks() < end_tick)
+ efi_timer_check();
+
return EFI_EXIT(EFI_SUCCESS);
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] lib: time: export usec_to_tick()
In the UEFI Stall() boottime service we need access to usec_to_tick().
Export the function.
Remove redundant implementation in arch/arm/mach-rockchip/rk_timer.c.
Signed-off-by: Heinrich Schuchardt
---
v2
no change
---
arch/arm/mach-rockchip/rk_timer.c | 7 ---
include/time.h| 9 +
lib/time.c| 2 +-
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk_timer.c
b/arch/arm/mach-rockchip/rk_timer.c
index f20e64f48e..29d379fa0a 100644
--- a/arch/arm/mach-rockchip/rk_timer.c
+++ b/arch/arm/mach-rockchip/rk_timer.c
@@ -20,13 +20,6 @@ static uint64_t rockchip_get_ticks(void)
return timebase_h << 32 | timebase_l;
}
-static uint64_t usec_to_tick(unsigned int usec)
-{
- uint64_t tick = usec;
- tick *= CONFIG_SYS_TIMER_RATE / (1000 * 1000);
- return tick;
-}
-
void rockchip_udelay(unsigned int usec)
{
uint64_t tmp;
diff --git a/include/time.h b/include/time.h
index 9fd0d73fb4..1e9b369be7 100644
--- a/include/time.h
+++ b/include/time.h
@@ -4,6 +4,7 @@
#define _TIME_H
#include
+#include
unsigned long get_timer(unsigned long base);
@@ -21,6 +22,14 @@ unsigned long timer_get_us(void);
*/
void timer_test_add_offset(unsigned long offset);
+/**
+ * usec_to_tick() - convert microseconds to clock ticks
+ *
+ * @usec: duration in microseconds
+ * Return: duration in clock ticks
+ */
+uint64_t usec_to_tick(unsigned long usec);
+
/*
* These inlines deal with timer wrapping correctly. You are
* strongly encouraged to use them
diff --git a/lib/time.c b/lib/time.c
index 9c55da6f1b..f5751ab162 100644
--- a/lib/time.c
+++ b/lib/time.c
@@ -139,7 +139,7 @@ unsigned long __weak notrace timer_get_us(void)
return tick_to_time(get_ticks() * 1000);
}
-static uint64_t usec_to_tick(unsigned long usec)
+uint64_t usec_to_tick(unsigned long usec)
{
uint64_t tick = usec;
tick *= get_tbclk();
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] usb: gadget: error out if g_dnl registration fails
If g_dnl_register fails return an error rather then stubornly
continuing onwards.
Signed-off-by: Sjoerd Simons
---
cmd/usb_gadget_sdp.c | 11 ---
common/spl/spl_sdp.c | 6 +-
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/cmd/usb_gadget_sdp.c b/cmd/usb_gadget_sdp.c
index 808ed974fa..2ead06be9f 100644
--- a/cmd/usb_gadget_sdp.c
+++ b/cmd/usb_gadget_sdp.c
@@ -13,7 +13,7 @@
static int do_sdp(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
- int ret = CMD_RET_FAILURE;
+ int ret;
if (argc < 2)
return CMD_RET_USAGE;
@@ -23,7 +23,11 @@ static int do_sdp(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
usb_gadget_initialize(controller_index);
g_dnl_clear_detach();
- g_dnl_register("usb_dnl_sdp");
+ ret = g_dnl_register("usb_dnl_sdp");
+ if (ret) {
+ pr_err("SDP dnl register failed: %d\n", ret);
+ goto exit_register;
+ }
ret = sdp_init(controller_index);
if (ret) {
@@ -37,9 +41,10 @@ static int do_sdp(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
exit:
g_dnl_unregister();
+exit_register:
usb_gadget_release(controller_index);
- return ret;
+ return CMD_RET_FAILURE;
}
U_BOOT_CMD(sdp, 2, 1, do_sdp,
diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
index 807256e908..7fc4404971 100644
--- a/common/spl/spl_sdp.c
+++ b/common/spl/spl_sdp.c
@@ -17,7 +17,11 @@ static int spl_sdp_load_image(struct spl_image_info
*spl_image,
const int controller_index = 0;
g_dnl_clear_detach();
- g_dnl_register("usb_dnl_sdp");
+ ret = g_dnl_register("usb_dnl_sdp");
+ if (ret) {
+ pr_err("SDP dnl register failed: %d\n", ret);
+ return ret;
+ }
ret = sdp_init(controller_index);
if (ret) {
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] ARM: socfpga: stratix10: Remove CONFIG_OF_EMBED
Am 04.06.2019 um 20:15 schrieb Tom Rini: On Tue, Jun 04, 2019 at 09:10:27AM -0700, Dalon L Westergreen wrote: On Tue, 2019-06-04 at 08:12 +0200, Simon Goldschmidt wrote: On Tue, Jun 4, 2019 at 7:58 AM See, Chin Liang wrote: On Tue, 2019-06-04 at 07:13 +0200, Simon Goldschmidt wrote: On Tue, Jun 4, 2019 at 1:57 AM Dalon Westergreen< dalon.westergr...@linux.intel.com> wrote: From: Dalon Westergreen CONFIG_OF_EMBED was primarily enabled to support the stratix10spl hex file requirements. Since this option now produces awarning during build, and the spl hex can be created usingalternate methods, CONFIG_OF_EMBED is no longer needed. Signed-off-by: Dalon Westergreen ---Changes in v2: -> Change CONFIG_SPL_TARGET back to u-boot-spl.hex--- configs/socfpga_stratix10_defconfig | 1 - include/configs/socfpga_stratix10_socdk.h | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/socfpga_stratix10_defconfigb/configs/socfpga_stratix10_defconf igindex fbab388b43..f27180385d 100644--- a/configs/socfpga_stratix10_defconfig+++ b/configs/socfpga_stratix10_defconfig@@ -26,7 +26,6 @@ CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y-CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk" CONFIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=ydiff --git a/include/configs/socfpga_stratix10_socdk.hb/include/configs/socfpga_str atix10_socdk.hindex 39d757d737..66855ff0d8 100644--- a/include/configs/socfpga_stratix10_socdk.h+++ b/include/configs/socfpga_stratix10_socdk.h@@ -210,6 +210,6 @@ unsigned int cm_get_l4_sys_free_clk_hz(void); /* SPL SDMMC boot support */ #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1-#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img"+#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot-dtb.img" Is that really necessary? I don't have the aarch64 compiler at hand,but when compiling a gen5 board, "u-boot.img" and "u-boot-dtb.img"are the same. Changing to "u-boot-dtb.img" here only complicatesthings for the user, I think. I would agree with Dalon since we want to make sure we use same name assocfpga_common.h, which is for CV, A10 SoCs. This would help tostandardize our internal test infra. But that 'dtb' thing is an implementation detail. Who of the testers careswhether the devicetree is embedded or not? "u-boot.img" exists withOF_EMBED and without it, or doesn't it? Regards,Simon Yes, it exists either way. I have no issue leaving it as u-boot.img but i do agree that it should bethe same across the socfpga family. As u-boot.img exists regardless of CONFIG_OF_EMBEDi would suggest just using u-boot.img, agreed? I will submit another patch to changesocfpga_common.h? Using "u-boot.img" is the right choice, it's what's used on all other platforms for "u-boot with dtb" and we have logic in the Makefile to do the right thing so that users can upgrade from a version of U-Boot where the dtb wasn't in use to one where it is without their scripts breaking. That's what I thought. Thanks for clarifying this, Tom. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 00/15] Add Support for eMMC in Am65x-evm
On Tue, Jun 04, 2019 at 09:32:21PM +0530, Lokesh Vutla wrote:
>
>
> On 04/06/19 6:46 PM, Faiz Abbas wrote:
> > Add Support for eMMC in TI's AM65x-evm. The series starts
> > by syncing the sdhci0 node from the kernel. Then it adds APIs and
> > changes to the driver required for handling the driver's integrated
> > phy. The current maximum supported speed is DDR52. Higher speeds and
> > tuning support will be added in a subsequent series.
> >
> > Changes in v6:
> > 1. Squashed one more dependency for clk_200mhz from Andreas's patches[1]
> >into patch 1. Patches now build without any help from the other series.
> >
> > 2. Improved line wrapping in patch 8.
>
> Thanks for the quick update. For the entire series:
>
> Tested-by: Lokesh Vutla
Seems like the test coverage was limited.
While eMMC (sdhci0) works when booting from SD card (sdhci1) the eMMC
probe fails when booting from eMMC itself defeating the main purpose of
a series adding eMMC support.
"sdhci@4f8 - probe failed: -22"
I did some debugging and tracked this down to a missing drive strength
setting on the R5 DTS file:
$ git diff
diff --git a/arch/arm/dts/k3-am654-r5-base-board.dts
b/arch/arm/dts/k3-am654-r5-base-board.dts
index 2f178c8b07..b10df50ef9 100644
--- a/arch/arm/dts/k3-am654-r5-base-board.dts
+++ b/arch/arm/dts/k3-am654-r5-base-board.dts
@@ -186,6 +186,7 @@
clock-names = "clk_xin";
clocks = <_200mhz>;
/delete-property/ power-domains;
+ ti,driver-strength-ohm = <50>;
};
{
Can we please have this added.
With this change added and SYSFW loader series applied I can boot all
the way to U-Boot prompt on AM654x EVM from eMMC.
Also SYSFW loader series no longer applies on top of this; will re-post
a rebased/refactored version to be used on top of this series.
--
Andreas Dannenberg
Texas Instruments Inc
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] ARM: socfpga: stratix10: Remove CONFIG_OF_EMBED
On Tue, Jun 04, 2019 at 09:10:27AM -0700, Dalon L Westergreen wrote: > On Tue, 2019-06-04 at 08:12 +0200, Simon Goldschmidt wrote: > > On Tue, Jun 4, 2019 at 7:58 AM See, Chin Liang > > wrote: > > > On Tue, 2019-06-04 at 07:13 +0200, Simon Goldschmidt wrote: > > > > On Tue, Jun 4, 2019 at 1:57 AM Dalon Westergreen< > > > > dalon.westergr...@linux.intel.com> wrote: > > > > > From: Dalon Westergreen > > > > > CONFIG_OF_EMBED was primarily enabled to support the stratix10spl hex > > > > > file requirements. Since this option now produces awarning during > > > > > build, and the spl hex can be created usingalternate methods, > > > > > CONFIG_OF_EMBED is no longer needed. > > > > > Signed-off-by: Dalon Westergreen > > > > > ---Changes in v2: -> Change CONFIG_SPL_TARGET back to > > > > > u-boot-spl.hex--- > > > > > configs/socfpga_stratix10_defconfig | 1 - > > > > > include/configs/socfpga_stratix10_socdk.h | 2 +- 2 files changed, 1 > > > > > insertion(+), 2 deletions(-) > > > > > diff --git > > > > > a/configs/socfpga_stratix10_defconfigb/configs/socfpga_stratix10_defconf > > > > > igindex fbab388b43..f27180385d 100644--- > > > > > a/configs/socfpga_stratix10_defconfig+++ > > > > > b/configs/socfpga_stratix10_defconfig@@ -26,7 +26,6 @@ > > > > > CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4=y CONFIG_CMD_FAT=y > > > > > CONFIG_CMD_FS_GENERIC=y-CONFIG_OF_EMBED=y > > > > > CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk" > > > > > CONFIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=ydiff --git > > > > > a/include/configs/socfpga_stratix10_socdk.hb/include/configs/socfpga_str > > > > > atix10_socdk.hindex 39d757d737..66855ff0d8 100644--- > > > > > a/include/configs/socfpga_stratix10_socdk.h+++ > > > > > b/include/configs/socfpga_stratix10_socdk.h@@ -210,6 +210,6 @@ > > > > > unsigned > > > > > int cm_get_l4_sys_free_clk_hz(void); > > > > > /* SPL SDMMC boot support */ #define > > > > > CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1-#define > > > > > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img"+#define > > > > > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot-dtb.img" > > > > Is that really necessary? I don't have the aarch64 compiler at hand,but > > > > when compiling a gen5 board, "u-boot.img" and "u-boot-dtb.img"are the > > > > same. Changing to "u-boot-dtb.img" here only complicatesthings for the > > > > user, I think. > > > > > > I would agree with Dalon since we want to make sure we use same name > > > assocfpga_common.h, which is for CV, A10 SoCs. This would help > > > tostandardize > > > our internal test infra. > > > > But that 'dtb' thing is an implementation detail. Who of the testers > > careswhether the devicetree is embedded or not? "u-boot.img" exists > > withOF_EMBED and without it, or doesn't it? > > Regards,Simon > > Yes, it exists either way. I have no issue leaving it as u-boot.img but i do > agree that it should bethe same across the socfpga family. As u-boot.img > exists > regardless of CONFIG_OF_EMBEDi would suggest just using u-boot.img, agreed? I > will submit another patch to changesocfpga_common.h? Using "u-boot.img" is the right choice, it's what's used on all other platforms for "u-boot with dtb" and we have logic in the Makefile to do the right thing so that users can upgrade from a version of U-Boot where the dtb wasn't in use to one where it is without their scripts breaking. -- 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 2/2] ARM: socfpga: stratix10: Remove CONFIG_OF_EMBED
On Tue, 2019-06-04 at 08:12 +0200, Simon Goldschmidt wrote: > On Tue, Jun 4, 2019 at 7:58 AM See, Chin Liang > wrote: > > On Tue, 2019-06-04 at 07:13 +0200, Simon Goldschmidt wrote: > > > On Tue, Jun 4, 2019 at 1:57 AM Dalon Westergreen< > > > dalon.westergr...@linux.intel.com> wrote: > > > > From: Dalon Westergreen > > > > CONFIG_OF_EMBED was primarily enabled to support the stratix10spl hex > > > > file requirements. Since this option now produces awarning during > > > > build, and the spl hex can be created usingalternate methods, > > > > CONFIG_OF_EMBED is no longer needed. > > > > Signed-off-by: Dalon Westergreen > > > > ---Changes in v2: -> Change CONFIG_SPL_TARGET back to u-boot-spl.hex--- > > > > configs/socfpga_stratix10_defconfig | 1 - > > > > include/configs/socfpga_stratix10_socdk.h | 2 +- 2 files changed, 1 > > > > insertion(+), 2 deletions(-) > > > > diff --git > > > > a/configs/socfpga_stratix10_defconfigb/configs/socfpga_stratix10_defconf > > > > igindex fbab388b43..f27180385d 100644--- > > > > a/configs/socfpga_stratix10_defconfig+++ > > > > b/configs/socfpga_stratix10_defconfig@@ -26,7 +26,6 @@ > > > > CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4=y CONFIG_CMD_FAT=y > > > > CONFIG_CMD_FS_GENERIC=y-CONFIG_OF_EMBED=y > > > > CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk" > > > > CONFIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=ydiff --git > > > > a/include/configs/socfpga_stratix10_socdk.hb/include/configs/socfpga_str > > > > atix10_socdk.hindex 39d757d737..66855ff0d8 100644--- > > > > a/include/configs/socfpga_stratix10_socdk.h+++ > > > > b/include/configs/socfpga_stratix10_socdk.h@@ -210,6 +210,6 @@ unsigned > > > > int cm_get_l4_sys_free_clk_hz(void); > > > > /* SPL SDMMC boot support */ #define > > > > CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1-#define > > > > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img"+#define > > > > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot-dtb.img" > > > Is that really necessary? I don't have the aarch64 compiler at hand,but > > > when compiling a gen5 board, "u-boot.img" and "u-boot-dtb.img"are the > > > same. Changing to "u-boot-dtb.img" here only complicatesthings for the > > > user, I think. > > > > I would agree with Dalon since we want to make sure we use same name > > assocfpga_common.h, which is for CV, A10 SoCs. This would help tostandardize > > our internal test infra. > > But that 'dtb' thing is an implementation detail. Who of the testers > careswhether the devicetree is embedded or not? "u-boot.img" exists > withOF_EMBED and without it, or doesn't it? > Regards,Simon Yes, it exists either way. I have no issue leaving it as u-boot.img but i do agree that it should bethe same across the socfpga family. As u-boot.img exists regardless of CONFIG_OF_EMBEDi would suggest just using u-boot.img, agreed? I will submit another patch to changesocfpga_common.h? --dalon > > ThanksChin Liang > > > Regards,Simon > > > > #endif /* __CONFIG_H */--2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] gpio: add gpio-hog support
Hello Patrick,
Am 04.06.2019 um 13:49 schrieb Patrick DELAUNAY:
Hi Heiko,
add gpio-hog support. GPIO hogging is a mechanism providing automatic GPIO
request and configuration as part of the gpio-controller's driver probe
function.
for more infos see:
doc/device-tree-bindings/gpio/gpio.txt
Signed-off-by: Heiko Schocher
It seens the hog function can be called several times, for gpio bank probed in
pre-reloc phasis:
- before recocation : gpio_post_probe() => gpio_hog() gpio_hogs_probed = 0
- after relocation :
gpio_post_probe() => gpio_hog()... gpio_hogs_probed = 0
gpio_hog_probe_all() => gpio_post_probe() => gpio_hog()...
gpio_hogs_probed = 1
I don't known if it is expected behavior:
hog configuration 2 times in Uboot = before and after relocation
No, not expected.
---
clean travis build, see result:
https://travis-ci.org/hsdenx/u-boot-test/builds/538734780
Changes in v3:
- probe now all gpio devices with gpio-hogs
from board_r before board_late_init() call
or if someone wants to access gpio-hog
based gpios with gpio_hog_lookup_name()
This is needed, because we cannot be sure,
if a gpio device which contains gpio-hogs
is probed.
- add line-name property as Michal recommended
- renamed gpio_priv_one into gpio_priv_one_hog
and protected through CONFIG_DM_GPIO_HOG
Changes in v2:
- move gpio_hog() call from post_probe() to post_bind()
call. Check if current gpio device has gpio-hog
definitions, if so, probe it.
common/board_r.c | 6 +
doc/device-tree-bindings/gpio/gpio.txt | 55 +++
drivers/gpio/Kconfig | 10 ++
drivers/gpio/gpio-uclass.c | 217 ++---
include/asm-generic/gpio.h | 32
5 files changed, 301 insertions(+), 19 deletions(-)
[...]
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c index
da5e9ba6e5..4ecff115f1 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -15,6 +16,18 @@
DECLARE_GLOBAL_DATA_PTR;
+#if defined(CONFIG_DM_GPIO_HOG)
+struct gpio_priv_one_hog {
+ struct list_head list;
+ char *name;
+ struct gpio_desc gpiod;
+};
+
+static struct list_head hogs;
+static int list_init;
+static int gpio_hogs_probed;
+#endif
+
/**
* gpio_to_device() - Convert global GPIO number to device, number
*
@@ -141,6 +154,147 @@ static int gpio_find_and_xlate(struct gpio_desc *desc,
return gpio_xlate_offs_flags(desc->dev, desc, args); }
+#if defined(CONFIG_DM_GPIO_HOG)
+int gpio_hog_probe_all(void)
+{
+ struct udevice *dev;
+ ofnode node;
+ int ret;
+
+ /*
+* We need to probe all gpio-hog devices
+* at some point, as we cannot be sure,
+* that all gpio devices, which contain a
+* gpio-hog definition are probed.
+*
+*/
+ if (gpio_hogs_probed)
+ return 0;
+
+ for (uclass_first_device(UCLASS_GPIO, );
+dev;
+uclass_next_device()) {
uclass_next_device automatically call probe for the class (in
uclass_get_device_tail)
in this context, I think that uclass_find_next_device is better
The idea was to only probe gpio devices with gpio-hog subnodes...
+ dev_for_each_subnode(node, dev) {
+ if (ofnode_read_bool(node, "gpio-hog")) {
+ ret = device_probe(dev);
+ if (ret)
+ return ret;
+ break;
+ }
+ }
+ }
+ gpio_hogs_probed = 1;
+
+ return 0;
+}
+
+struct gpio_desc *gpio_hog_lookup_name(const char *name) {
+ struct list_head *entry;
+ struct gpio_priv_one_hog *cur;
+
+ /* be sure, all gpio devices with gpio-hogs are probed */
+ gpio_hog_probe_all();
+ list_for_each(entry, ) {
+ cur = list_entry(entry, struct gpio_priv_one_hog, list);
+ if (strcmp(cur->name, name) == 0)
+ return >gpiod;
+ }
+
+ return NULL;
+}
+
+static int gpio_hog(struct udevice *dev) {
+ ofnode node;
+ int found = 0;
+ int ret;
+ struct gpio_dev_priv *uc_priv = NULL;
+
+ if (!list_init) {
+ INIT_LIST_HEAD();
+ list_init = 1;
+ }
+ dev_for_each_subnode(node, dev) {
+ if (ofnode_read_bool(node, "gpio-hog")) {
+ found = 1;
+ break;
+ }
+ }
This check is really needed, as it is already done in the main loop ?
I think you can remove this first 'found' loop.
Yes if we only setup the gpio-hogs from main loop.
+
+ if (!found)
+ return 0;
+
+ uc_priv = dev_get_uclass_priv(dev);
+
Re: [U-Boot] [PATCH v6 00/15] Add Support for eMMC in Am65x-evm
On 04/06/19 6:46 PM, Faiz Abbas wrote: > Add Support for eMMC in TI's AM65x-evm. The series starts > by syncing the sdhci0 node from the kernel. Then it adds APIs and > changes to the driver required for handling the driver's integrated > phy. The current maximum supported speed is DDR52. Higher speeds and > tuning support will be added in a subsequent series. > > Changes in v6: > 1. Squashed one more dependency for clk_200mhz from Andreas's patches[1] >into patch 1. Patches now build without any help from the other series. > > 2. Improved line wrapping in patch 8. Thanks for the quick update. For the entire series: Tested-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Add drive-strength-microamp in Meson pinctrl driver
Hi Guillaume, On 04/06/2019 13:53, Guillaume La Roque wrote: > The purpose of this patchset is to add drive-strength-microamp support in > meson pinconf > driver. This is a new feature that was added on the g12a. It is critical for > us > to support this since many functions are failing with default pad > drive-strength. > > The value achievable by the SoC are 500uA, 2500uA, 3000uA and 4000uA and the > DT property > 'drive-strength-microamp' is expressed in uA. > So this patch add another generic property "drive-strength-microamp". The > change to do so > would be minimal and could be benefit to other platforms later on. > > it's backport from linux : > https://lore.kernel.org/lkml/20190514082652.20686-1-glaro...@baylibre.com/ > > Cheers > Guillaume > > Guillaume La Roque (3): > dm: pinctrl: Add driver-strength-microamp property > pinctrl: meson: add support of drive-strength-microamp > pinctrl: meson: g12a: add DS bank value > > drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c | 1 + > drivers/pinctrl/meson/pinctrl-meson-g12a.c| 20 > drivers/pinctrl/meson/pinctrl-meson.c | 46 ++- > drivers/pinctrl/meson/pinctrl-meson.h | 43 +++-- > include/dm/pinctrl.h | 3 ++ > 5 files changed, 89 insertions(+), 24 deletions(-) > Thanks Tested on an Odroid-N2 ! Tested-by: Neil Armstrong Neil ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] mx6sabreauto: Select pinctrl driver
Hi Sjoerd, On Mon, Jun 3, 2019 at 4:01 PM Sjoerd Simons wrote: > > With the conversion to DM we should select the pinctrl driver. > > Signed-off-by: Sjoerd Simons I did the same for mx6sabresd initially, but then later I realized that it would be better to fix this globally like this: https://lists.denx.de/pipermail/u-boot/2019-May/370740.html Hopefully Stefano can apply this version and then we can fix all i.MX boards that were converted to DM automatically. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: ls1028a: define the integrated PCI bus (ECAM)
Hi Bin,
On 6/2/2019 5:22 PM, Bin Meng wrote:
Hi Alex,
On Fri, May 31, 2019 at 12:27 AM Alex Marginean wrote:
LS1028A includes an integrated PCI bus with 8M of ECAM space plus register
space for the integrated devices. This integrated PCI bus is driven using
the generic ECAM driver.
Signed-off-by: Alex Marginean
---
arch/arm/dts/fsl-ls1028a.dtsi | 10 ++
arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 2 ++
arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h | 2 ++
configs/ls1028aqds_tfa_defconfig | 1 +
configs/ls1028ardb_tfa_defconfig | 1 +
5 files changed, 16 insertions(+)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index e6a443aa77..263c29af23 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -108,6 +108,16 @@
0x8200 0x0 0x4000 0x88 0x4000 0x0
0x4000>; /* non-prefetchable memory */
};
+ pcie@1f000 {
+ compatible = "pci-host-ecam-generic";
+ reg = <0x01 0xf000 0x0 0x10>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ bus-range = <0x0 0x0>;
I think this should be <0x0 0x7> since you mentioned in the commit
message that only an 8M ECAM space is allocated.
I think I was looking at the wrong spec, it seems the platform actually
has 256MB of address space reserved for ECAM. It's not all implemented
of course, in fact all the devices we care about in u-boot are on bus 0.
Anyway, I can just remove bus-range, the default is 0-255 and that does
match the HW.
+ ranges= <0x8200 0x0 0x 0x1 0xf800 0x0 0x16>;
+ };
+
i2c0: i2c@200 {
compatible = "fsl,vf610-i2c";
#address-cells = <1>;
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
index bdeb62576c..7759acdb8f 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/cpu.h
@@ -42,7 +42,9 @@
#else
#define CONFIG_SYS_PCIE1_PHYS_SIZE 0x8
#define CONFIG_SYS_PCIE2_PHYS_SIZE 0x8
+#ifndef CONFIG_SYS_PCIE3_PHYS_SIZE
#define CONFIG_SYS_PCIE3_PHYS_SIZE 0x8
+#endif
#define CONFIG_SYS_PCIE4_PHYS_SIZE 0x8
#define SYS_PCIE5_PHYS_SIZE0x8
#define SYS_PCIE6_PHYS_SIZE0x8
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 24c1b0e482..273157230f 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -186,6 +186,8 @@
#elif CONFIG_ARCH_LS1028A
#define CONFIG_SYS_PCIE1_PHYS_ADDR 0x80ULL
#define CONFIG_SYS_PCIE2_PHYS_ADDR 0x88ULL
+#define CONFIG_SYS_PCIE3_PHYS_ADDR 0x01f000ULL
+#define CONFIG_SYS_PCIE3_PHYS_SIZE 0x001000ULL
DT says the size is 0x10. This does not match.
I'll extend reg to 256MB along with removing bus-range.
These macros really look to me this platform is still using lots of
non-DM approaches when it comes to driver support. These hard coded
values should really be dropped and retrieved from DT instead via
proper DM drivers.
ECAM is driven by the ecam generic host driver and it doesn't care about
these macros.
These are used int arch/arm/cpu/armv8/fsl-layerscape/cpu.c to set up
the MMU at boot though, accessing ECAM doesn't work without them.
#else
#define CONFIG_SYS_PCIE1_PHYS_ADDR 0x10ULL
#define CONFIG_SYS_PCIE2_PHYS_ADDR 0x12ULL
diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig
index 717b810523..7982ce4157 100644
--- a/configs/ls1028aqds_tfa_defconfig
+++ b/configs/ls1028aqds_tfa_defconfig
@@ -48,6 +48,7 @@ CONFIG_E1000=y
CONFIG_PCI=y
CONFIG_DM_PCI=y
CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_ECAM_GENERIC=y
CONFIG_PCIE_LAYERSCAPE=y
CONFIG_SCSI=y
CONFIG_DM_SCSI=y
diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig
index a8e4ddb7a8..c65e37df79 100644
--- a/configs/ls1028ardb_tfa_defconfig
+++ b/configs/ls1028ardb_tfa_defconfig
@@ -48,6 +48,7 @@ CONFIG_E1000=y
CONFIG_PCI=y
CONFIG_DM_PCI=y
CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_ECAM_GENERIC=y
CONFIG_PCIE_LAYERSCAPE=y
CONFIG_SCSI=y
CONFIG_DM_SCSI=y
--
Regards,
Bin
Thank you!
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
Hi Frieder, On Tue, Jun 4, 2019 at 4:09 AM Schrempf Frieder wrote: > Signed-off-by: Frieder Schrempf > > Thanks a lot for preparing the patch and sending it! As I reported yesterday to Sjoerd, this patch needs some adjustment as it breaks mx6sabresd_defconfig. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] mx6sabreauto: set SYS_MALLOC_F for video
Sabre Auto boards currently hang with: ``` U-Boot 2019.07-rc3-00057-gc41940c406 (Jun 03 2019 - 14:42:41 +0200) CPU: Freescale i.MX6QP rev1.0 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C)Reset cause: WDOG Model: Freescale i.MX6 Quad Plus SABRE Automotive Board Board: MX6Q-Sabreauto revA I2C: ready DRAM: 2 GiB Video device 'ipu@240' cannot allocate frame buffer memory -ensure the device is set up before relocation Error binding driver 'ipuv3_video': -28 Video device 'ipu@280' cannot allocate frame buffer memory -ensure the device is set up before relocation Error binding driver 'ipuv3_video': -28 Some drivers failed to bind Error binding driver 'generic_simple_bus': -28 Some drivers failed to bind initcall sequence 8ffe00b8 failed at call 1780e93b (err=-28) ``` Set SYS_MALLOC_F_LEN to reserve_video to work. This is similar to the change Peng Fan did for mx6sabresd (9002e735e717) Signed-off-by: Sjoerd Simons Reviewed-by: Peng Fan --- configs/mx6sabreauto_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig index ef965a30e6..dc758d7aaf 100644 --- a/configs/mx6sabreauto_defconfig +++ b/configs/mx6sabreauto_defconfig @@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x1780 CONFIG_SPL_GPIO_SUPPORT=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_TARGET_MX6SABREAUTO=y CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y @@ -11,7 +12,6 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y CONFIG_SPL_LIBDISK_SUPPORT=y CONFIG_NXP_BOARD_REVISION=y -# CONFIG_SYS_MALLOC_F is not set CONFIG_FIT=y CONFIG_SPL_FIT_PRINT=y CONFIG_SPL_LOAD_FIT=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] arm: dts: imx6qdl-u-boot: Alias usb0 to usbotg
All i.mx6 boards seems to have moved to DM_USB, however gadget support
for mx6 is still pre-DM as CI_UDC isn't converted yet. To make this work
the usb otg controller used for gadgets needs to be usb number 0.
Add an alias for this directly in the main u-boot mx6qdl dtsi so it
doesn't need to be done for each board separately.
This fixes regressions wrt. usb gadget functionality in several boards
that have gadget functions enabled in their config, but no usb0 alias in
their device-tree.
Signed-off-by: Sjoerd Simons
---
arch/arm/dts/imx6qdl-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/imx6qdl-u-boot.dtsi b/arch/arm/dts/imx6qdl-u-boot.dtsi
index 0aa29e38b8..e161ebb9af 100644
--- a/arch/arm/dts/imx6qdl-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-u-boot.dtsi
@@ -4,6 +4,10 @@
*/
/ {
+ aliases {
+ usb0 =
+ };
+
soc {
u-boot,dm-spl;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] mx6sabreauto: Select pinctrl driver
With the conversion to DM we should select the pinctrl driver. Signed-off-by: Sjoerd Simons Reviewed-by: Peng Fan --- configs/mx6sabreauto_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig index d0f302e9d0..ef965a30e6 100644 --- a/configs/mx6sabreauto_defconfig +++ b/configs/mx6sabreauto_defconfig @@ -70,6 +70,8 @@ CONFIG_SF_DEFAULT_SPEED=2000 CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y CONFIG_MII=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX6=y CONFIG_DM_REGULATOR=y CONFIG_SPI=y CONFIG_DM_SPI=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/3] i.mx6 (sabre auto) fixes for 2019.07
To make things easier i've split the `Enable usage of SDP for i.MX6 Sabre Auto Boards` patchset i sent yesterday up so it'll be hopefully easier to merge. The first two are the same as yesterday (Thanks Peng for the review). The last one is new and fixes regressions in usb gadget usage of various mx6 board that were converted to DM_USB. Sjoerd Simons (3): mx6sabreauto: Select pinctrl driver mx6sabreauto: set SYS_MALLOC_F for video arm: dts: imx6qdl-u-boot: Alias usb0 to usbotg arch/arm/dts/imx6qdl-u-boot.dtsi | 4 configs/mx6sabreauto_defconfig | 4 +++- 2 files changed, 7 insertions(+), 1 deletion(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
