Re: [U-Boot] [PATCH] spl: fat/fs: Add option to include/exclude FAT write build in SPL
On Thu, Jan 17, 2019 at 8:10 AM wrote:
>
> From: Tien Fong Chee
>
> Most of the time SPL only needs very simple FAT reading, so having
> CONFIG_SPL_FAT_WRITE to exclude or undefined would help to save 64KiB
> default max clustersize from memory.
>
> Signed-off-by: Tien Fong Chee
> ---
> common/spl/Kconfig |7 +++
> fs/fat/Makefile|7 ++-
> fs/fat/fat.c |4 +++-
> fs/fs.c|3 ++-
> 4 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 0ddbffc..dad4c11 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -403,6 +403,13 @@ config SPL_FAT_SUPPORT
> filesystem from within SPL. Support for the underlying block
> device (e.g. MMC or USB) must be enabled separately.
>
> +config SPL_FAT_WRITE
> + bool "Support write for FAT filesystems"
> + help
> + Enable write support for FAT and VFAT filesystems with SPL.
> + Support for the underlying block device (e.g. MMC or USB) must be
> + enabled separately.
> +
> config SPL_FPGA_SUPPORT
> bool "Support FPGAs"
> help
> diff --git a/fs/fat/Makefile b/fs/fat/Makefile
> index e64b61a..654b8c3 100644
> --- a/fs/fat/Makefile
> +++ b/fs/fat/Makefile
> @@ -1,5 +1,10 @@
> # SPDX-License-Identifier: GPL-2.0+
> #
>
> +ifdef CONFIG_SPL_BUILD
> obj-$(CONFIG_FS_FAT) := fat.o
> -obj-$(CONFIG_FAT_WRITE):= fat_write.o
> +obj-$(CONFIG_SPL_FAT_WRITE) = fat_write.o
> +else
> +obj-$(CONFIG_FS_FAT) := fat.o
> +obj-$(CONFIG_FAT_WRITE) = fat_write.o
> +endif
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index ac8913e..8803fb4 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -145,7 +145,9 @@ static void get_name(dir_entry *dirent, char *s_name)
> }
>
> static int flush_dirty_fat_buffer(fsdata *mydata);
> -#if !defined(CONFIG_FAT_WRITE)
> +
> +#if (!defined(CONFIG_SPL_BUILD) && !defined(CONFIG_FAT_WRITE)) || \
> + (defined(CONFIG_SPL_BUILD) && !defined(CONFIG_SPL_FAT_WRITE))
What about 'CONFIG_IS_ENABLED(FAT_WRITE)' ?
Regards,
Simon
> /* Stub for read only operation */
> int flush_dirty_fat_buffer(fsdata *mydata)
> {
> diff --git a/fs/fs.c b/fs/fs.c
> index cb26517..0b8088b 100644
> --- a/fs/fs.c
> +++ b/fs/fs.c
> @@ -168,7 +168,8 @@ static struct fstype_info fstypes[] = {
> .exists = fat_exists,
> .size = fat_size,
> .read = fat_read_file,
> -#ifdef CONFIG_FAT_WRITE
> +#if (!defined(CONFIG_SPL_BUILD) && defined(CONFIG_FAT_WRITE)) || \
> + (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_FAT_WRITE))
> .write = file_fat_write,
> .unlink = fat_unlink,
> .mkdir = fat_mkdir,
> --
> 1.7.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm64: zynqmp: Move SoC sources to mach-zynqmp
Similar changes was done for Zynq in past and this patch just follow
this pattern to separate cpu code from SoC code.
Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/*
And also fix references to these files.
Based on
"ARM: zynq: move SoC sources to mach-zynq"
(sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc)
Signed-off-by: Michal Simek
---
MAINTAINERS | 2 +-
arch/arm/Kconfig | 4 ++--
arch/arm/Makefile | 1 +
arch/arm/cpu/armv8/Makefile | 1 -
arch/arm/mach-k3/arm64-mmu.c | 2 +-
arch/arm/mach-tegra/arm64-mmu.c | 2 +-
arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/Kconfig| 0
arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/Makefile | 0
arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/clk.c | 0
arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/cpu.c | 0
arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/handoff.c | 0
arch/arm/{include/asm/arch-zynqmp => mach-zynqmp/include/mach}/clk.h | 0
arch/arm/{include/asm/arch-zynqmp => mach-zynqmp/include/mach}/gpio.h | 0
.../{include/asm/arch-zynqmp => mach-zynqmp/include/mach}/hardware.h | 0
.../asm/arch-zynqmp => mach-zynqmp/include/mach}/psu_init_gpl.h | 0
.../{include/asm/arch-zynqmp => mach-zynqmp/include/mach}/sys_proto.h | 0
arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/mp.c | 0
arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/psu_spl_init.c | 0
arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/spl.c | 0
19 files changed, 6 insertions(+), 6 deletions(-)
rename arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/Kconfig (100%)
rename arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/Makefile (100%)
rename arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/clk.c (100%)
rename arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/cpu.c (100%)
rename arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/handoff.c (100%)
rename arch/arm/{include/asm/arch-zynqmp => mach-zynqmp/include/mach}/clk.h
(100%)
rename arch/arm/{include/asm/arch-zynqmp => mach-zynqmp/include/mach}/gpio.h
(100%)
rename arch/arm/{include/asm/arch-zynqmp =>
mach-zynqmp/include/mach}/hardware.h (100%)
rename arch/arm/{include/asm/arch-zynqmp =>
mach-zynqmp/include/mach}/psu_init_gpl.h (100%)
rename arch/arm/{include/asm/arch-zynqmp =>
mach-zynqmp/include/mach}/sys_proto.h (100%)
rename arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/mp.c (100%)
rename arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/psu_spl_init.c (100%)
rename arch/arm/{cpu/armv8/zynqmp => mach-zynqmp}/spl.c (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index e192db075489..2386bebaea68 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -354,7 +354,7 @@ ARM ZYNQMP
M: Michal Simek
S: Maintained
T: git git://git.denx.de/u-boot-microblaze.git
-F: arch/arm/cpu/armv8/zynqmp/
+F: arch/arm/mach-zynqmp/
F: drivers/clk/clk_zynqmp.c
F: drivers/fpga/zynqpl.c
F: drivers/gpio/zynq_gpio.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a65e0c52116c..2298e6e7d750 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1503,14 +1503,14 @@ source "arch/arm/cpu/armv7/vf610/Kconfig"
source "arch/arm/mach-zynq/Kconfig"
+source "arch/arm/mach-zynqmp/Kconfig"
+
source "arch/arm/mach-versal/Kconfig"
source "arch/arm/mach-zynqmp-r5/Kconfig"
source "arch/arm/cpu/armv7/Kconfig"
-source "arch/arm/cpu/armv8/zynqmp/Kconfig"
-
source "arch/arm/cpu/armv8/Kconfig"
source "arch/arm/mach-imx/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 87d9d4b9f744..817302523aec 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -81,6 +81,7 @@ machine-$(CONFIG_ARCH_STM32MP)+= stm32mp
machine-$(CONFIG_TEGRA)+= tegra
machine-$(CONFIG_ARCH_UNIPHIER)+= uniphier
machine-$(CONFIG_ARCH_ZYNQ)+= zynq
+machine-$(CONFIG_ARCH_ZYNQMP) += zynqmp
machine-$(CONFIG_ARCH_VERSAL) += versal
machine-$(CONFIG_ARCH_ZYNQMP_R5) += zynqmp-r5
diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index 52c8daa04962..4c4b13c9e759 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -29,7 +29,6 @@ obj-$(CONFIG_$(SPL_)ARMV8_SEC_FIRMWARE_SUPPORT) +=
sec_firmware.o sec_firmware_a
obj-$(CONFIG_FSL_LAYERSCAPE) += fsl-layerscape/
obj-$(CONFIG_S32V234) += s32v234/
-obj-$(CONFIG_ARCH_ZYNQMP) += zynqmp/
obj-$(CONFIG_TARGET_HIKEY) += hisilicon/
obj-$(CONFIG_ARMV8_PSCI) += psci.o
obj-$(CONFIG_ARCH_SUNXI) += lowlevel_init.o
diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
index f8b93fe45849..a75ba1ffdba0 100644
--- a/arch/arm/mach-k3/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64-mmu.c
@@
Re: [U-Boot] [PATCH v4 8/9] cmd: efitool: export uefi variable helper functions
On Tue, Jan 15, 2019 at 06:28:38AM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:55 AM, AKASHI Takahiro wrote:
> > Those function will be used for integration with 'env' command
> > so as to handle uefi variables.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > cmd/efitool.c | 38 ++
> > include/command.h | 4
> > 2 files changed, 38 insertions(+), 4 deletions(-)
> >
> > diff --git a/cmd/efitool.c b/cmd/efitool.c
> > index f06718ea580d..b8fe28c53aaf 100644
> > --- a/cmd/efitool.c
> > +++ b/cmd/efitool.c
> > @@ -67,7 +67,7 @@ static void dump_var_data(char *data, unsigned long len)
> > *
> > * efi_$guid_$varname = {attributes}(type)value
> > */
> > -static int do_efi_dump_var(int argc, char * const argv[])
> > +static int _do_efi_dump_var(int argc, char * const argv[])
>
> Please, do not use two function names only distinguished by and
> underscore. A a reader I will always wonder which does what.
While I believe that "_" and "__" are a very common practice to
show an internal version of function,
> Please, use names that describe what the difference is.
I will revert _do_efi_dump_var() to do_efi_dump_var() and
change do_efi_dump_var() to do_efi_dump_var_ext().
> > {
> > char regex[256];
> > char * const regexlist[] = {regex};
> > @@ -130,6 +130,21 @@ static int do_efi_dump_var(int argc, char * const
> > argv[])
> > return CMD_RET_SUCCESS;
> > }
> >
> > +int do_efi_dump_var(int argc, char * const argv[])
> > +{
> > + efi_status_t r;
> > +
> > + /* Initialize EFI drivers */
> > + r = efi_init_obj_list();
> > + if (r != EFI_SUCCESS) {
> > + printf("Error: Cannot set up EFI drivers, r = %lu\n",
> > + r & ~EFI_ERROR_MASK);
>
> You duplicate this code below.
Do you want another function for just calling one function?
I don't think it's worth doing so.
> So, please, put this into a separate function.
>
> That could also help to avoid having separate do_efi_set_var and
> _do_efi_set_var.
I don't get your point.
Do you want to call efi_init_obj_list() at every do_efi_xxx()?
It just doesn't make sense.
> > + return CMD_RET_FAILURE;
> > + }
> > +
> > + return _do_efi_dump_var(argc, argv);
> > +}
> > +
> > static int append_value(char **bufp, unsigned long *sizep, char *data)
> > {
> > char *tmp_buf = NULL, *new_buf = NULL, *value;
> > @@ -227,7 +242,7 @@ out:
> > return 0;
> > }
> >
> > -static int do_efi_set_var(int argc, char * const argv[])
> > +static int _do_efi_set_var(int argc, char * const argv[])
> > {
> > char *var_name, *value = NULL;
> > efi_uintn_t size = 0;
> > @@ -270,6 +285,21 @@ out:
> > return ret;
> > }
> >
> > +int do_efi_set_var(int argc, char * const argv[])
> > +{
> > + efi_status_t r;
> > +
> > + /* Initialize EFI drivers */
> > + r = efi_init_obj_list();
> > + if (r != EFI_SUCCESS) {
> > + printf("Error: Cannot set up EFI drivers, r = %lu\n",
>
> It is more then drivers that we setup. So perhaps
>
> "Cannot initialize UEFI sub-system."
I don't mind, but that string directly comes from the original code
in bootefi.c.
> > + r & ~EFI_ERROR_MASK);
> > + return CMD_RET_FAILURE;
> > + }
> > +
> > + return _do_efi_set_var(argc, argv);
> > +}
> > +
> > static int efi_get_handles_by_proto(efi_guid_t *guid, efi_handle_t
> > **handlesp,
> > int *num)
> > {
> > @@ -1016,9 +1046,9 @@ static int do_efitool(cmd_tbl_t *cmdtp, int flag,
> > if (!strcmp(command, "boot"))
> > return do_efi_boot_opt(argc, argv);
> > else if (!strcmp(command, "dumpvar") || !strcmp(command, "dmpstore"))
> > - return do_efi_dump_var(argc, argv);
> > + return _do_efi_dump_var(argc, argv);
> > else if (!strcmp(command, "setvar"))
> > - return do_efi_set_var(argc, argv);
> > + return _do_efi_set_var(argc, argv);
> > else if (!strcmp(command, "devices"))
> > return do_efi_show_devices(argc, argv);
> > else if (!strcmp(command, "drivers"))
> > diff --git a/include/command.h b/include/command.h
> > index feddef300ccc..315e4b9aabfb 100644
> > --- a/include/command.h
> > +++ b/include/command.h
> > @@ -51,6 +51,10 @@ extern int do_run(cmd_tbl_t *cmdtp, int flag, int argc,
> > char * const argv[]);
> > #if defined(CONFIG_CMD_BOOTEFI)
> > extern int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char *
> > const argv[]);
> > #endif
> > +#if defined(CONFIG_CMD_EFITOOL)
>
> The definition has not dependencies. No need for an #if here.
Currently has, but as you and Alex suggested in a separate thread,
we may want to enable it (and do_efi_dump/set_var() as well)
whether or not CMD_BOOTEFI and CMD_EFIDEBUG, respectively, are defined.
Thanks,
-Takahiro Akashi
> > +int do_efi_dump_var(int argc, char * const argv[]);
> > +int do_efi_set_var(int argc, char * const argv[]);
> > +#endi
>
> Shouldn't
Re: [U-Boot] [PATCH 1/2] efi_loader: implement GetNextVariableName()
On 1/17/19 3:14 AM, AKASHI Takahiro wrote:
> Heinrich,
>
> Thank you for your quick review.
>
> On Wed, Jan 16, 2019 at 07:43:47PM +0100, Heinrich Schuchardt wrote:
>> On 12/14/18 10:47 AM, AKASHI Takahiro wrote:
>>> The current GetNextVariableName() is a placeholder.
>>> With this patch, it works well as expected.
>>>
>>> Signed-off-by: AKASHI Takahiro
>>> ---
>>> lib/efi_loader/efi_variable.c | 116 +-
>>> 1 file changed, 115 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
>>> index 19d9cb865f25..dac2f49aa1cc 100644
>>> --- a/lib/efi_loader/efi_variable.c
>>> +++ b/lib/efi_loader/efi_variable.c
>>> @@ -8,6 +8,9 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> +#include
>>> +#include
>>>
>>> #define READ_ONLY BIT(31)
>>>
>>> @@ -241,14 +244,125 @@ efi_status_t EFIAPI efi_get_variable(u16
>>> *variable_name, efi_guid_t *vendor,
>>> return EFI_EXIT(EFI_SUCCESS);
>>> }
>>>
>>> +static char *efi_variables_list;
>>> +static char *efi_cur_variable;
>>> +
>>
>> Please, provide a comment describing what this function is meant to do.
>
> I think that the function name describes itself clearly, but OK.
>
>> Describe every parameter
>>
>> Clearly state set variable_name_size is in bytes (cf.
>> EmuGetNextVariableName() in EDK2)
>
> Right.
>
>> This function duplicates some of the code in efi_get_variable. So,
>> please, use it in efi_get_variable too.
>
> Which part of code do you mean? I don't think so.
Checking buffer size.
Comparing vendor GUID.
Extracting an EFI variable from a U-Boot variable.
>
>>> +static efi_status_t parse_uboot_variable(char *variable,
>>> +efi_uintn_t *variable_name_size,
>>> +u16 *variable_name,
>>> +efi_guid_t *vendor,
>>> +u32 *attribute)
>>> +{
>>
>>
>>
>>> + char *guid, *name, *end, c;
>>> + unsigned long name_size;
>>> + u16 *p;
>>> +
>>> + guid = strchr(variable, '_');
>>> + if (!guid)
>>> + return EFI_NOT_FOUND;
>>> + guid++;
>>> + name = strchr(guid, '_');
>>> + if (!name)
>>> + return EFI_NOT_FOUND;
>>> + name++;
>>> + end = strchr(name, '=');
>>> + if (!end)
>>> + return EFI_NOT_FOUND;
>>> +
>>> + /* FIXME: size is in byte or u16? */
>>
>> It is in bytes. See comment above.
>
> OK
>
>>> + name_size = end - name;
>>> + if (*variable_name_size < (name_size + 1)) {
>>> + *variable_name_size = name_size + 1;
>>> + return EFI_BUFFER_TOO_SMALL;
>>> + }
>>> + end++; /* point to value */
>>> +
>>> + p = variable_name;
>>> + utf8_utf16_strncpy(, name, name_size);
>>> + variable_name[name_size] = 0;
>>> +
>>> + c = *(name - 1);
>>> + *(name - 1) = '\0'; /* guid need be null-terminated here */
>>> + uuid_str_to_bin(guid, (unsigned char *)vendor, UUID_STR_FORMAT_GUID);
>>> + *(name - 1) = c;
>>> +
>>> + parse_attr(end, attribute);
>>
>> You have to update variable_name_size.
>
> Right.
>
>>> +
>>> + return EFI_SUCCESS;
>>> +}
>>> +
>>> /*
>>> http://wiki.phoenix.com/wiki/index.php/EFI_RUNTIME_SERVICES#GetNextVariableName.28.29
>>> */
>>
>> Please add a description of the function here like we have it in
>> efi_bootefi.c
>
> OK, but not for efi_get/set_variable() as I didn't touch anything there.
For the other functions we should do it in a separate patch.
>
>>> efi_status_t EFIAPI efi_get_next_variable_name(efi_uintn_t
>>> *variable_name_size,
>>>u16 *variable_name,
>>>efi_guid_t *vendor)
>>> {
>>> + char *native_name, *variable;
>>> + ssize_t name_len, list_len;
>>> + char regex[256];
>>> + char * const regexlist[] = {regex};
>>> + u32 attribute;
>>> + int i;
>>> + efi_status_t ret;
>>> +
>>> EFI_ENTRY("%p \"%ls\" %pUl", variable_name_size, variable_name, vendor);
>>>
>>> - return EFI_EXIT(EFI_DEVICE_ERROR);
>>> + if (!variable_name_size || !variable_name || !vendor)
>>> + EFI_EXIT(EFI_INVALID_PARAMETER);
>>> +
>>> + if (variable_name[0]) {
>>
>> This code partially duplicates code in in efi_get_variable. Please,
>> carve out a common function.
>
> Which part of code do you mean? I don't see any duplication.
>
>>> + /* check null-terminated string */
>>> + for (i = 0; i < *variable_name_size; i++)
>>> + if (!variable_name[i])
>>> + break;
>>> + if (i >= *variable_name_size)
>>> + return EFI_EXIT(EFI_INVALID_PARAMETER);
>>> +
>>> + /* search for the last-returned variable */
>>> + ret = efi_to_native(_name, variable_name, vendor);
>>> + if (ret)
>>> + return EFI_EXIT(ret);
>>> +
>>> + name_len = strlen(native_name);
>>> +
[U-Boot] [PATCH] spl: fat/fs: Add option to include/exclude FAT write build in SPL
From: Tien Fong Chee
Most of the time SPL only needs very simple FAT reading, so having
CONFIG_SPL_FAT_WRITE to exclude or undefined would help to save 64KiB
default max clustersize from memory.
Signed-off-by: Tien Fong Chee
---
common/spl/Kconfig |7 +++
fs/fat/Makefile|7 ++-
fs/fat/fat.c |4 +++-
fs/fs.c|3 ++-
4 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 0ddbffc..dad4c11 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -403,6 +403,13 @@ config SPL_FAT_SUPPORT
filesystem from within SPL. Support for the underlying block
device (e.g. MMC or USB) must be enabled separately.
+config SPL_FAT_WRITE
+ bool "Support write for FAT filesystems"
+ help
+ Enable write support for FAT and VFAT filesystems with SPL.
+ Support for the underlying block device (e.g. MMC or USB) must be
+ enabled separately.
+
config SPL_FPGA_SUPPORT
bool "Support FPGAs"
help
diff --git a/fs/fat/Makefile b/fs/fat/Makefile
index e64b61a..654b8c3 100644
--- a/fs/fat/Makefile
+++ b/fs/fat/Makefile
@@ -1,5 +1,10 @@
# SPDX-License-Identifier: GPL-2.0+
#
+ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_FS_FAT) := fat.o
-obj-$(CONFIG_FAT_WRITE):= fat_write.o
+obj-$(CONFIG_SPL_FAT_WRITE) = fat_write.o
+else
+obj-$(CONFIG_FS_FAT) := fat.o
+obj-$(CONFIG_FAT_WRITE) = fat_write.o
+endif
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index ac8913e..8803fb4 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -145,7 +145,9 @@ static void get_name(dir_entry *dirent, char *s_name)
}
static int flush_dirty_fat_buffer(fsdata *mydata);
-#if !defined(CONFIG_FAT_WRITE)
+
+#if (!defined(CONFIG_SPL_BUILD) && !defined(CONFIG_FAT_WRITE)) || \
+ (defined(CONFIG_SPL_BUILD) && !defined(CONFIG_SPL_FAT_WRITE))
/* Stub for read only operation */
int flush_dirty_fat_buffer(fsdata *mydata)
{
diff --git a/fs/fs.c b/fs/fs.c
index cb26517..0b8088b 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -168,7 +168,8 @@ static struct fstype_info fstypes[] = {
.exists = fat_exists,
.size = fat_size,
.read = fat_read_file,
-#ifdef CONFIG_FAT_WRITE
+#if (!defined(CONFIG_SPL_BUILD) && defined(CONFIG_FAT_WRITE)) || \
+ (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_FAT_WRITE))
.write = file_fat_write,
.unlink = fat_unlink,
.mkdir = fat_mkdir,
--
1.7.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] travis: Wire Xilinx Versal Virt platform
Test Xilinx Versal Virt platform running on the v3.1.0 Qemu. Signed-off-by: Michal Simek --- Changes in v2: - Rebased on the top of https://lists.denx.de/pipermail/u-boot/2019-January/354857.html .travis.yml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/.travis.yml b/.travis.yml index 8991e12d6a1a..8daebdc8c157 100644 --- a/.travis.yml +++ b/.travis.yml @@ -448,6 +448,13 @@ matrix: QEMU_TARGET="arm-softmmu" TEST_PY_ID="--id qemu" BUILDMAN="^zynq_zc702$" +- name: "test/py xilinx_versal_virt" + env: +- TEST_PY_BD="xilinx_versal_virt" + TEST_PY_TEST_SPEC="not sleep" + QEMU_TARGET="aarch64-softmmu" + TEST_PY_ID="--id qemu" + BUILDMAN="^xilinx_versal_virt$" - name: "test/py xtfpga" env: - TEST_PY_BD="xtfpga" -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/9] cmd: efitool: add memmap command
On Tue, Jan 15, 2019 at 05:26:42AM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:55 AM, AKASHI Takahiro wrote:
> > "memmap" command prints uefi-specific memory map information.
> > => efi memmap
> > Type StartEnd Attributes
> > ==
> > CONVENTIONAL 4000-7de27000 WB
> > RUNTIME DATA 7de27000-7de28000 WB|RT
> > RESERVED 7de28000-7de2a000 WB
> > RUNTIME DATA 7de2a000-7de2b000 WB|RT
> > RESERVED 7de2b000-7de2c000 WB
> > RUNTIME DATA 7de2c000-7de2d000 WB|RT
> > LOADER DATA 7de2d000-7ff37000 WB
> > RUNTIME CODE 7ff37000-7ff38000 WB|RT
> > LOADER DATA 7ff38000-8000 WB
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > cmd/efitool.c | 78 ++-
> > 1 file changed, 77 insertions(+), 1 deletion(-)
> >
> > diff --git a/cmd/efitool.c b/cmd/efitool.c
> > index e77273fc6e1e..f06718ea580d 100644
> > --- a/cmd/efitool.c
> > +++ b/cmd/efitool.c
> > @@ -540,6 +540,78 @@ static int do_efi_show_images(int argc, char * const
> > argv[])
> > return CMD_RET_SUCCESS;
> > }
> >
> > +static const char * const efi_mem_type_string[] = {
> > + [EFI_RESERVED_MEMORY_TYPE] = "RESERVED",
> > + [EFI_LOADER_CODE] = "LOADER CODE",
> > + [EFI_LOADER_DATA] = "LOADER DATA",
> > + [EFI_BOOT_SERVICES_CODE] = "BOOT CODE",
> > + [EFI_BOOT_SERVICES_DATA] = "BOOT DATA",
> > + [EFI_RUNTIME_SERVICES_CODE] = "RUNTIME CODE",
> > + [EFI_RUNTIME_SERVICES_DATA] = "RUNTIME DATA",
> > + [EFI_CONVENTIONAL_MEMORY] = "CONVENTIONAL",
> > + [EFI_UNUSABLE_MEMORY] = "UNUSABLE MEM",
> > + [EFI_ACPI_RECLAIM_MEMORY] = "ACPI RECLAIM MEM",
> > + [EFI_ACPI_MEMORY_NVS] = "ACPI NVS",
> > + [EFI_MMAP_IO] = "IO",
> > + [EFI_MMAP_IO_PORT] = "IO PORT",
> > + [EFI_PAL_CODE] = "PAL",
> > +};
> > +
> > +#define EFI_MEM_ATTR(attribute, bit, string) \
> > + if ((attribute) & (bit)) { \
> > + if (sep)\
> > + putc('|'); \
> > + sep = 1;\
> > + printf(string); \
> > + }
> > +
> > +static int do_efi_show_memmap(int argc, char * const argv[])
> > +{
> > + struct efi_mem_desc *memmap = NULL, *map;
> > + efi_uintn_t map_size = 0;
> > + int i, sep;
> > + efi_status_t ret;
> > +
> > + ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);
>
> ret = EFI_SUCCCESS will only occur if the memory has not been setup yet.
I don't think so.
> So shouldn't we error out if ret != EFI_BUFFER_TOO_SMALL ?
>
> > + if (ret == EFI_BUFFER_TOO_SMALL) {
> > + memmap = malloc(map_size);
> > + if (!memmap)
> > + return CMD_RET_FAILURE;
> > + ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);
> > + }
> > + if (ret != EFI_SUCCESS) {
> > + free(memmap);
> > + return CMD_RET_FAILURE;
> > + }
> > +
> > + printf("Type StartEnd
> > Attributes\n");
> > + printf("
> > ==\n");
> > + for (i = 0, map = memmap; i < map_size / sizeof(*map); map++, i++) {
> > + sep = 0;
> > + printf("%-16s %016llx-%016llx ",
> > + efi_mem_type_string[map->type],
> > + map->physical_start,
> > + map->physical_start + map->num_pages * EFI_PAGE_SIZE);
> > + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_UC, "UC");
> > + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_WC, "WC");
> > + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_WT, "WT");
> > + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_WB, "WB");
> > + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_UCE, "UCE");
> > + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_WP, "WP");
> > + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_RP, "RP");
> > + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_XP, "WP");
> > + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_NV, "NV");
> > + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_MORE_RELIABLE, "REL");
> > + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_RO, "RO");
> > + EFI_MEM_ATTR(map->attribute, EFI_MEMORY_RUNTIME, "RT");
>
> Please, put that logic into a separate function which returns a const
> char *. Then we need only a single printf().
I don't think it's worth generating a one-time string only for this
specific use.
If 'printf' is a matter, I will simply replace it to puts() here.
> I suggest to use an array for the mapping:
>
> struct memory_attribute_name {
> u64 attribute;
> const char *short_name;
> };
>
> struct memory_attribute_name memory_attribute_names[] = {
> {EFI_MEMORY_UC, "UC"},
> ...
> };
>
> For looping you can use
[U-Boot] [PATCH] spl: fat/fs: Add control to build FS EXT4 in SPL
From: Tien Fong Chee
CONFIG_SPL_EXT_SUPPORT can be used to include/exclude the FS EXT4 from
SPL build. Excluding the FS EXT4 from SPL build can help to save 20KiB
memory.
Signed-off-by: Tien Fong Chee
---
fs/fs.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/fs/fs.c b/fs/fs.c
index 0b8088b..252e2f5 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -184,7 +184,9 @@ static struct fstype_info fstypes[] = {
.closedir = fat_closedir,
},
#endif
-#ifdef CONFIG_FS_EXT4
+/* #ifdef CONFIG_FS_EXT4 */
+#if (!defined(CONFIG_SPL_BUILD) && defined(CONFIG_FS_EXT4)) || \
+ (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_EXT_SUPPORT))
{
.fstype = FS_TYPE_EXT,
.name = "ext4",
--
1.7.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/9] efi_driver: add name to driver binding protocol
On 1/17/19 6:33 AM, AKASHI Takahiro wrote:
> You raised a couple of questions to me.
>
> On Tue, Jan 15, 2019 at 04:41:08AM +0100, Heinrich Schuchardt wrote:
>> On 1/15/19 3:55 AM, AKASHI Takahiro wrote:
>>> This new field will be shown as a driver's name in "efitool drivers"
>>> command.
>>
>> We can have drivers supplied by U-Boot
>
> I assume that what you mention here is a UCLASS_EFI driver.
>
> What's the problem is;
> efi_add_driver() adds EFI_DRIVER_BINDING_PROTOCOL with
> *efi_driver_binding_extended_protocol* interface, which is NOT compatible
> with EFI_DRIVER_BINDING_PROTOCOL.
> On the other hand, for example, in your efi_selftest_controller test
> a test driver is set up by installing EFI_DRIVER_BINDING_PROTOCOL
> with EFI_DRIVER_BINDING_PROTOCOL interface.
>
> So we have no way to distinguish the two cases(handles) and cannot
> deal with them properly.
Correct. It is allowable to add private fields to a protocol. EDK2 does
the same. But we cannot make any assumptions about the private fields here.
>
>> and drivers supplied by an EFI
>> binary that we recently installed via the bootefi command.
>>
>> A driver installed via the bootefi command will not have allocated
>> memory for the extra fields.
>
> There is no good example of driver of such kind.
> I don't know how we can retrieve a meaningful "driver name."
The UEFI spec does not foresee any name field.
The interesting information is: on which handle did the driver install
which protocol.
This information could be gathered by looping over all protocols on all
handles and looking for an OpenProtocolInformation where the driver is
the controller.
For me it would be fine if we leave that to a later patch.
Best regards
Heinrich
>
>> So you cannot use the name field in your "efitool drivers" command.
>
> Any suggestion?
>
> Thanks,
> -Takahiro Akashi
>
>>
>> Best regards
>>
>> Heinrich
>>
>>>
>>> Signed-off-by: AKASHI Takahiro
>>> ---
>>> include/efi_driver.h| 1 +
>>> lib/efi_driver/efi_uclass.c | 1 +
>>> 2 files changed, 2 insertions(+)
>>>
>>> diff --git a/include/efi_driver.h b/include/efi_driver.h
>>> index 840483a416a4..ee8867816094 100644
>>> --- a/include/efi_driver.h
>>> +++ b/include/efi_driver.h
>>> @@ -34,6 +34,7 @@ struct efi_driver_ops {
>>> * This structure adds internal fields to the driver binding protocol.
>>> */
>>> struct efi_driver_binding_extended_protocol {
>>> + const char *name;
>>> struct efi_driver_binding_protocol bp;
>>> const struct efi_driver_ops *ops;
>>> };
>>> diff --git a/lib/efi_driver/efi_uclass.c b/lib/efi_driver/efi_uclass.c
>>> index bb86ffd399c3..8bbaa02d490e 100644
>>> --- a/lib/efi_driver/efi_uclass.c
>>> +++ b/lib/efi_driver/efi_uclass.c
>>> @@ -271,6 +271,7 @@ static efi_status_t efi_add_driver(struct driver *drv)
>>> bp->bp.stop = efi_uc_stop;
>>> bp->bp.version = 0x;
>>> bp->ops = drv->ops;
>>> + bp->name = drv->name;
>>>
>>> ret = efi_create_handle(>bp.driver_binding_handle);
>>> if (ret != EFI_SUCCESS) {
>>>
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: socfpga: Increase Malloc pool size to support FAT filesystem in SPL
From: Tien Fong Chee This is minimum memory pool size required to get SPL booting to U-Boot, such as FPGA program and loading U-Boot image from FAT. Signed-off-by: Tien Fong Chee --- include/configs/socfpga_common.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index bd8f5c8..93273a8 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -258,7 +258,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) /* SPL memory allocation configuration, this is for FAT implementation */ #ifndef CONFIG_SYS_SPL_MALLOC_START -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001 +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x00012000 #define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SYS_INIT_RAM_SIZE - \ CONFIG_SYS_SPL_MALLOC_SIZE + \ CONFIG_SYS_INIT_RAM_ADDR) -- 1.7.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] fs: fat: Reduce default max clustersize 64KiB from malloc pool
From: Tien Fong Chee
Release cluster block immediately when no longer use would help to reduce
64KiB memory allocated to the memory pool.
Signed-off-by: Tien Fong Chee
---
fs/fat/fat.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index aa4636d..5574620 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -1153,12 +1153,19 @@ int file_fat_read_at(const char *filename, loff_t pos,
void *buffer,
goto out_free_both;
debug("reading %s at pos %llu\n", filename, pos);
- ret = get_contents(, itr->dent, pos, buffer, maxsize, actread);
+
+ /* For saving default max clustersize memory allocated to malloc pool */
+ dir_entry *dentptr = itr->dent;
+
+ free(itr);
+
+ ret = get_contents(, dentptr, pos, buffer, maxsize, actread);
out_free_both:
free(fsdata.fatbuf);
out_free_itr:
- free(itr);
+ if (!itr)
+ free(itr);
return ret;
}
--
1.7.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] fs: fat: dynamically allocate memory for temporary buffer
From: Stefan Agner
Drop the statically allocated get_contents_vfatname_block and
dynamically allocate a buffer only if required. This saves
64KiB of memory.
Signed-off-by: Stefan Agner
Signed-off-by: Tien Fong Chee
---
fs/fat/fat.c | 19 +--
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 8803fb4..aa4636d 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -307,9 +307,6 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
unsigned long size)
* into 'buffer'.
* Update the number of bytes read in *gotsize or return -1 on fatal errors.
*/
-__u8 get_contents_vfatname_block[MAX_CLUSTSIZE]
- __aligned(ARCH_DMA_MINALIGN);
-
static int get_contents(fsdata *mydata, dir_entry *dentptr, loff_t pos,
__u8 *buffer, loff_t maxsize, loff_t *gotsize)
{
@@ -320,7 +317,7 @@ static int get_contents(fsdata *mydata, dir_entry *dentptr,
loff_t pos,
loff_t actsize;
*gotsize = 0;
- debug("Filesize: %llu bytes\n", filesize);
+ debug("Filesize: %llu bytes, starting at pos %llu\n", filesize, pos);
if (pos >= filesize) {
debug("Read position past EOF: %llu\n", pos);
@@ -352,15 +349,25 @@ static int get_contents(fsdata *mydata, dir_entry
*dentptr, loff_t pos,
/* align to beginning of next cluster if any */
if (pos) {
+ __u8 *tmp_buffer;
+
+ tmp_buffer = malloc_cache_aligned(MAX_CLUSTSIZE);
+ if (!tmp_buffer) {
+ debug("Error: allocating buffer\n");
+ return -ENOMEM;
+ }
+
actsize = min(filesize, (loff_t)bytesperclust);
- if (get_cluster(mydata, curclust, get_contents_vfatname_block,
+ if (get_cluster(mydata, curclust, tmp_buffer,
(int)actsize) != 0) {
printf("Error reading cluster\n");
+ free(tmp_buffer);
return -1;
}
filesize -= actsize;
actsize -= pos;
- memcpy(buffer, get_contents_vfatname_block + pos, actsize);
+ memcpy(buffer, tmp_buffer + pos, actsize);
+ free(tmp_buffer);
*gotsize += actsize;
if (!filesize)
return 0;
--
1.7.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] arm64: zynqmp: Align u-boot-spl.bin for boot.bin creation
On 16. 01. 19 22:34, Simon Glass wrote: > On Wed, 16 Jan 2019 at 04:24, Michal Simek wrote: >> >> Bootrom is not capable to work with non align bootloader partition >> that's why it is necessary to align it before boot.bin creation. >> The patch is creating new spl/u-boot-spl-align.bin which is used only >> for boot.bin. >> >> Signed-off-by: Michal Simek >> --- >> >> Changes in v2: >> - New patch for solving issue with zynqmpimage.c >> >> scripts/Makefile.spl | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) > > Can we use binman for zynq? Also, why not always align? First of all this is for zynqmp/arm64 only. Zynq/arm32 doesn't have this issue based on my testing. I wanted to look at binman but didn't have a time. u-boot-spl.bin is align already but dtbs are not. That's why when DT is appended we get non aligned u-boot-spl.bin. I don't know if this is an issue for others but I would say that aligning of this new generated image make sense even for others. > > Reviewed-by: Simon Glass > Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/9] cmd: efitool: add images command
On Tue, Jan 15, 2019 at 05:58:57AM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:55 AM, AKASHI Takahiro wrote:
> > "images" command prints loaded images-related information.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > cmd/efitool.c | 13 -
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/cmd/efitool.c b/cmd/efitool.c
> > index 4bd6367b4bd9..e77273fc6e1e 100644
> > --- a/cmd/efitool.c
> > +++ b/cmd/efitool.c
> > @@ -533,6 +533,13 @@ static int do_efi_show_handles(int argc, char * const
> > argv[])
> > return CMD_RET_SUCCESS;
> > }
> >
> > +static int do_efi_show_images(int argc, char * const argv[])
> > +{
> > + efi_print_image_infos(NULL);
> > +
> > + return CMD_RET_SUCCESS;
> > +}
> > +
> > static int do_efi_boot_add(int argc, char * const argv[])
> > {
>
> Please, use the standard way of adding sub-commands. See
> doc/README.commands.
OK
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> > int id;
> > @@ -946,6 +953,8 @@ static int do_efitool(cmd_tbl_t *cmdtp, int flag,
> > return do_efi_show_drivers(argc, argv);
> > else if (!strcmp(command, "dh"))
> > return do_efi_show_handles(argc, argv);
> > + else if (!strcmp(command, "images"))
> > + return do_efi_show_images(argc, argv);
> > else
> > return CMD_RET_USAGE;
> > }
> > @@ -976,7 +985,9 @@ static char efitool_help_text[] =
> > "efitool drivers\n"
> > " - show uefi drivers\n"
> > "efitool dh\n"
> > - " - show uefi handles\n";
> > + " - show uefi handles\n"
> > + "efitool images\n"
> > + " - show loaded images\n";
> > #endif
> >
> > U_BOOT_CMD(
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/9] cmd: efitool: add dh command
On Tue, Jan 15, 2019 at 05:55:26AM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:55 AM, AKASHI Takahiro wrote:
> > "dh" command prints all the uefi handles used in the system.
> >
> > => efi dh
> > 7ef3bfa0: Device Path, Device Path To Text, Device Path Utilities,
> > Unicode Collation 2
> > 7ef31d30: Driver Binding
> > 7ef31da0: Simple Text Output
> > 7ef31e10: Simple Text Input, Simple Text Input Ex
> > 7ef3cca0: Block IO, Device Path
> > 7ef3d070: Block IO, Device Path
> > 7ef3d1b0: Block IO, Device Path, Simple File System
> > 7ef3d3e0: Block IO, Device Path, Simple File System
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > cmd/efitool.c | 103 +-
> > 1 file changed, 102 insertions(+), 1 deletion(-)
> >
> > diff --git a/cmd/efitool.c b/cmd/efitool.c
> > index 4d46721fbf91..4bd6367b4bd9 100644
> > --- a/cmd/efitool.c
> > +++ b/cmd/efitool.c
> > @@ -436,6 +436,103 @@ static int do_efi_show_drivers(int argc, char * const
> > argv[])
> > return CMD_RET_SUCCESS;
> > }
> >
> > +static struct {
> > + u16 *name;
>
> Please, reduce the memory size by using char *.
OK
> > + efi_guid_t guid;
> > +} guid_list[] = {
> > + {
> > + L"Device Path",
> > + DEVICE_PATH_GUID,
> > + },
> > + {
> > + L"Device Path To Text",
> > + EFI_DEVICE_PATH_TO_TEXT_PROTOCOL_GUID,
> > + },
> > + {
> > + L"Device Path Utilities",
> > + EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID,
> > + },
> > + {
> > + L"Unicode Collation 2",
> > + EFI_UNICODE_COLLATION_PROTOCOL2_GUID,
> > + },
> > + {
> > + L"Driver Binding",
> > + EFI_DRIVER_BINDING_PROTOCOL_GUID,
> > + },
> > + {
> > + L"Simple Text Input",
> > + EFI_SIMPLE_TEXT_INPUT_PROTOCOL_GUID,
> > + },
> > + {
> > + L"Simple Text Input Ex",
> > + EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL_GUID,
> > + },
> > + {
> > + L"Simple Text Output",
> > + EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL_GUID,
> > + },
> > + {
> > + L"Block IO",
> > + BLOCK_IO_GUID,
> > + },
> > + {
> > + L"Simple File System",
> > + EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID,
> > + },
>
> We implement a few more protocols, e.g.
>
> include/efi_api.h:467:#define BLOCK_IO_GUID \
> include/efi_api.h:977:#define EFI_DRIVER_BINDING_PROTOCOL_GUID \
> include/efi_api.h:999:#define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \
They are already in there.
> include/efi_api.h:283:#define LOADED_IMAGE_PROTOCOL_GUID \
> include/efi_api.h:700:#define EFI_GOP_GUID \
Added.
> > + {
> > + NULL,
> > + {{0,},},
> > + }
> You could use the ARRAY_SIZE() macro instead of the NULL entry.
OK
> > +};
> > +
> > +static int do_efi_show_handles(int argc, char * const argv[])
> > +{
> > + efi_handle_t *handles;
> > + efi_guid_t **guid;
> > + efi_uintn_t count;
> > + int num, i, j, k;
> > + efi_status_t ret;
> > +
> > + handles = NULL;
> > + num = 0;
> > + if (efi_get_handles_by_proto(NULL, , ))
> > + return CMD_RET_FAILURE;
> > +
> > + if (!num)
> > + return CMD_RET_SUCCESS;
> > +
> > + for (i = 0; i < num; i++) {
> > + printf("%16p:", handles[i]);
> > + ret = BS->protocols_per_handle(handles[i], , );
> > + if (ret || !count) {
> > + putc('\n');
> > + continue;
> > + }
> > +
> > + for (j = 0; j < count; j++) {
> > + for (k = 0; guid_list[k].name; k++)
> > + if (!guidcmp(_list[k].guid, guid[j]))
> > + break;
>
> Please, put this logic into a separate function returning const char *.
> Return NULL if not found.
OK
> > +
> > + if (j)
> > + printf(", ");
> > + else
> > + putc(' ');
> > +
> > + if (guid[j])
> > + printf("%ls", guid_list[k].name);
> > + else
> > + printf("%pUl", guid[j]);
> > + }
> > + putc('\n');
> > + }
> > +
> > + free(handles);
> > +
> > + return CMD_RET_SUCCESS;
> > +}
> > +
> > static int do_efi_boot_add(int argc, char * const argv[])
> > {
>
> Please, use the standard way of adding sub-commands. See
> doc/README.commands.
OK
Thanks,
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> > int id;
> > @@ -847,6 +944,8 @@ static int do_efitool(cmd_tbl_t *cmdtp, int flag,
> > return do_efi_show_devices(argc, argv);
> > else if (!strcmp(command, "drivers"))
> > return do_efi_show_drivers(argc, argv);
> > + else if (!strcmp(command, "dh"))
> > + return do_efi_show_handles(argc, argv);
> > else
> >
Re: [U-Boot] [PATCH v4 3/9] efi_driver: add name to driver binding protocol
You raised a couple of questions to me.
On Tue, Jan 15, 2019 at 04:41:08AM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:55 AM, AKASHI Takahiro wrote:
> > This new field will be shown as a driver's name in "efitool drivers"
> > command.
>
> We can have drivers supplied by U-Boot
I assume that what you mention here is a UCLASS_EFI driver.
What's the problem is;
efi_add_driver() adds EFI_DRIVER_BINDING_PROTOCOL with
*efi_driver_binding_extended_protocol* interface, which is NOT compatible
with EFI_DRIVER_BINDING_PROTOCOL.
On the other hand, for example, in your efi_selftest_controller test
a test driver is set up by installing EFI_DRIVER_BINDING_PROTOCOL
with EFI_DRIVER_BINDING_PROTOCOL interface.
So we have no way to distinguish the two cases(handles) and cannot
deal with them properly.
> and drivers supplied by an EFI
> binary that we recently installed via the bootefi command.
>
> A driver installed via the bootefi command will not have allocated
> memory for the extra fields.
There is no good example of driver of such kind.
I don't know how we can retrieve a meaningful "driver name."
> So you cannot use the name field in your "efitool drivers" command.
Any suggestion?
Thanks,
-Takahiro Akashi
>
> Best regards
>
> Heinrich
>
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > include/efi_driver.h| 1 +
> > lib/efi_driver/efi_uclass.c | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/include/efi_driver.h b/include/efi_driver.h
> > index 840483a416a4..ee8867816094 100644
> > --- a/include/efi_driver.h
> > +++ b/include/efi_driver.h
> > @@ -34,6 +34,7 @@ struct efi_driver_ops {
> > * This structure adds internal fields to the driver binding protocol.
> > */
> > struct efi_driver_binding_extended_protocol {
> > + const char *name;
> > struct efi_driver_binding_protocol bp;
> > const struct efi_driver_ops *ops;
> > };
> > diff --git a/lib/efi_driver/efi_uclass.c b/lib/efi_driver/efi_uclass.c
> > index bb86ffd399c3..8bbaa02d490e 100644
> > --- a/lib/efi_driver/efi_uclass.c
> > +++ b/lib/efi_driver/efi_uclass.c
> > @@ -271,6 +271,7 @@ static efi_status_t efi_add_driver(struct driver *drv)
> > bp->bp.stop = efi_uc_stop;
> > bp->bp.version = 0x;
> > bp->ops = drv->ops;
> > + bp->name = drv->name;
> >
> > ret = efi_create_handle(>bp.driver_binding_handle);
> > if (ret != EFI_SUCCESS) {
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/9] cmd: efitool: add devices command
On Tue, Jan 15, 2019 at 06:09:31AM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:55 AM, AKASHI Takahiro wrote:
> > "devices" command prints all the uefi variables on the system.
> >
> > => efi devices
> > Scanning disk ahci_scsi.id0lun0...
> > Scanning disk ahci_scsi.id1lun0...
> > Found 4 disks
> > D
> > e
> > vDevice Path
> >
> > 7ef3bfa0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> > 7ef3cca0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)
> > 7ef3d070 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)
> > 7ef3d1b0
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(1,MBR,0x086246ba,0x800,0x4)
> > 7ef3d3e0
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(1,0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > cmd/efitool.c | 98 ++-
> > 1 file changed, 97 insertions(+), 1 deletion(-)
> >
> > diff --git a/cmd/efitool.c b/cmd/efitool.c
> > index c7dc2c11f2e7..6b2df1beedb5 100644
> > --- a/cmd/efitool.c
> > +++ b/cmd/efitool.c
> > @@ -18,6 +18,8 @@
> > #include
> > #include
> >
> > +#define BS systab.boottime
> > +
> > static void dump_var_data(char *data, unsigned long len)
> > {
> > char *start, *end, *p;
> > @@ -266,6 +268,96 @@ out:
> > return ret;
> > }
> >
> > +static int efi_get_handles_by_proto(efi_guid_t *guid, efi_handle_t
> > **handlesp,
> > + int *num)
> > +{
> > + efi_handle_t *handles = NULL;
> > + efi_uintn_t size = 0;
> > + efi_status_t ret;
> > +
> > + if (guid) {
> > + ret = BS->locate_handle(BY_PROTOCOL, guid, NULL, ,
> > + handles);
> > + if (ret == EFI_BUFFER_TOO_SMALL) {
> > + handles = calloc(1, size);
> > + if (!handles)
> > + return -1;
> > +
> > + ret = BS->locate_handle(BY_PROTOCOL, guid, NULL, ,
> > + handles);
> > + }
> > + if (ret != EFI_SUCCESS) {
> > + free(handles);
> > + return -1;
> > + }
> > + } else {
> > + ret = BS->locate_handle(ALL_HANDLES, NULL, NULL, , NULL);
> > + if (ret == EFI_BUFFER_TOO_SMALL) {
> > + handles = calloc(1, size);
> > + if (!handles)
> > + return -1;
> > +
> > + ret = BS->locate_handle(ALL_HANDLES, NULL, NULL, ,
> > + handles);
> > + }
> > + if (ret != EFI_SUCCESS) {
> > + free(handles);
> > + return -1;
> > + }
> > + }
> > +
> > + *handlesp = handles;
> > + *num = size / sizeof(efi_handle_t);
> > +
> > + return 0;
> > +}
> > +
> > +static int efi_get_device_handle_info(efi_handle_t handle, u16 **name)
> > +{
> > + struct efi_device_path *dp;
> > + efi_status_t ret;
> > +
> > + ret = BS->open_protocol(handle, _guid_device_path,
> > + (void **), NULL /* FIXME */, NULL,
> > + EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> > + if (ret == EFI_SUCCESS) {
> > + *name = efi_dp_str(dp);
> > + return 0;
> > + } else {
> > + return -1;
> > + }
> > +}
> > +
> > +static int do_efi_show_devices(int argc, char * const argv[])
> > +{
> > + efi_handle_t *handles;
> > + u16 *devname;
>
> This is the device path. So why not call it dev_path?
dev_path is normally used for a device path object itself.
I prefer dp_text.
> > + int num, i;
> > +
> > + handles = NULL;
> > + num = 0;
> > + if (efi_get_handles_by_proto(NULL, , ))
> > + return CMD_RET_FAILURE;
> > +
> > + if (!num)
> > + return CMD_RET_SUCCESS;
> > +
> > + printf("D\n");
> > + printf("e\n");
> > + printf("vDevice Path\n");
> > + printf(" \n");
> > + for (i = 0; i < num; i++) {
> > + if (!efi_get_device_handle_info(handles[i], )) {
> > + printf("%16p %ls\n", handles[i], devname);
> > + efi_free_pool(devname);
> > + }
> > + }
> > +
> > + free(handles);
> > +
> > + return CMD_RET_SUCCESS;
> > +}
> > +
> > static int do_efi_boot_add(int argc, char * const argv[])
> > {
>
> Please, use the standard way of adding sub-commands, cf.
> doc/README.commands.
OK
Thanks,
-Takahiro Akashi
> Thanks a lot for your contribution.
>
> Regards
>
> Heinrich
>
> > int id;
> > @@ -673,6 +765,8 @@ static int do_efitool(cmd_tbl_t *cmdtp, int flag,
> > return do_efi_dump_var(argc, argv);
> > else if (!strcmp(command, "setvar"))
> > return do_efi_set_var(argc, argv);
> > + else if (!strcmp(command, "devices"))
> > +
Re: [U-Boot] [PATCH v4 1/9] cmd: add efitool command
On Tue, Jan 15, 2019 at 04:31:35AM +0100, Heinrich Schuchardt wrote: > On 1/15/19 3:55 AM, AKASHI Takahiro wrote: > > Currently, there is no easy way to add or modify UEFI variables. > > In particular, bootmgr supports BootOrder/Boot variables, it is > > quite hard to define them as u-boot variables because they are represented > > in a complicated and encoded format. > > > > The new command, efitool, helps address these issues and give us > > more friendly interfaces: > > * efitool boot add: add Boot variable > > * efitool boot rm: remove Boot variable > > * efitool boot dump: display all Boot variables > > * efitool boot order: set/display a boot order (BootOrder) > > * efitool setvar: set an UEFI variable (with limited functionality) > > * efitool dumpvar: display all UEFI variables > > > > As the name suggests, this command basically provides a subset fo UEFI > > shell commands with simplified functionality. > > > > Signed-off-by: AKASHI Takahiro > > Hello Takahiro, > > thanks a lot for your patch series. The additional command is really useful. > > Unfortunately the implementation of sub-commands does not follow the > coding style of other sub-commands. Could you please have a look at the > current doc/README.commands > > http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.commands OK. > I think it should be easy to convert your code to follow the > implementation style suggested there and used all over U-Boot. > > Sorry that I did not put this into an earlier comment. I only learnt > about this recently by a review from Simon and then updated the README. > > Please, add the new file in MAINTAINERS to the EFI PAYLOAD section. Sure Thanks, -Takahiro Akashi > Best regards > > Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] mmc: hi6220_dw_mmc: add compatible for Poplar support
It adds compatible "hisilicon,hi3798cv200-dw-mshc" for Poplar SoC
Hi3798CV200 to probe this mmc driver.
Signed-off-by: Shawn Guo
---
drivers/mmc/hi6220_dw_mmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/hi6220_dw_mmc.c b/drivers/mmc/hi6220_dw_mmc.c
index cc58aff38cc4..effd1e4c7c84 100644
--- a/drivers/mmc/hi6220_dw_mmc.c
+++ b/drivers/mmc/hi6220_dw_mmc.c
@@ -77,6 +77,7 @@ static int hi6220_dwmmc_bind(struct udevice *dev)
static const struct udevice_id hi6220_dwmmc_ids[] = {
{ .compatible = "hisilicon,hi6220-dw-mshc" },
+ { .compatible = "hisilicon,hi3798cv200-dw-mshc" },
{ }
};
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] poplar: clean up board level mmc initialization code
We have converted mmc to driver model on Poplar. So let's clean up
board level mmc initialization code.
Signed-off-by: Shawn Guo
---
arch/arm/include/asm/arch-hi3798cv200/dwmmc.h | 12
arch/arm/include/asm/arch-hi3798cv200/hi3798cv200.h | 1 -
board/hisilicon/poplar/poplar.c | 12
3 files changed, 25 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-hi3798cv200/dwmmc.h
diff --git a/arch/arm/include/asm/arch-hi3798cv200/dwmmc.h
b/arch/arm/include/asm/arch-hi3798cv200/dwmmc.h
deleted file mode 100644
index d08c20b36d31..
--- a/arch/arm/include/asm/arch-hi3798cv200/dwmmc.h
+++ /dev/null
@@ -1,12 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2017 Linaro
- * Jorge Ramirez-Ortiz
- */
-
-#ifndef _HI3798cv200_DWMMC_H_
-#define _HI3798cv200_DWMMC_H_
-
-int hi6220_dwmci_add_port(int index, u32 regbase, int bus_width);
-
-#endif /* _HI3798cv200_DWMMC_H_ */
diff --git a/arch/arm/include/asm/arch-hi3798cv200/hi3798cv200.h
b/arch/arm/include/asm/arch-hi3798cv200/hi3798cv200.h
index bb221e17e0ed..b98b45cc817b 100644
--- a/arch/arm/include/asm/arch-hi3798cv200/hi3798cv200.h
+++ b/arch/arm/include/asm/arch-hi3798cv200/hi3798cv200.h
@@ -11,7 +11,6 @@
#define REG_BASE_CRG 0xF8A22000
/* DEVICES */
-#define REG_BASE_MCI 0xF983
#define REG_BASE_UART0 0xF8B0
#define HIOTG_BASE_ADDR0xF98C
diff --git a/board/hisilicon/poplar/poplar.c b/board/hisilicon/poplar/poplar.c
index 155dfbb401f1..77948445e261 100644
--- a/board/hisilicon/poplar/poplar.c
+++ b/board/hisilicon/poplar/poplar.c
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include
DECLARE_GLOBAL_DATA_PTR;
@@ -155,17 +154,6 @@ static void usb2_phy_init(void)
udelay(200);
}
-int board_mmc_init(bd_t *bis)
-{
- int ret;
-
- ret = hi6220_dwmci_add_port(0, REG_BASE_MCI, 8);
- if (ret)
- printf("mmc init error (%d)\n", ret);
-
- return ret;
-}
-
#if defined(CONFIG_USB_GADGET) && defined(CONFIG_USB_GADGET_DWC2_OTG)
#include
#include
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] poplar: sync up device tree with kernel 4.20
It adds missing pinctrl headers, updates clock header and sync up Poplar
device tree with kernel 4.20 release.
Signed-off-by: Shawn Guo
---
arch/arm/dts/hi3798cv200-poplar.dts | 68 ++--
arch/arm/dts/hi3798cv200.dtsi | 221 +++-
arch/arm/dts/poplar-pinctrl.dtsi| 98 +++
include/dt-bindings/clock/histb-clock.h | 56 +++---
include/dt-bindings/pinctrl/hisi.h | 74
5 files changed, 482 insertions(+), 35 deletions(-)
create mode 100644 arch/arm/dts/poplar-pinctrl.dtsi
create mode 100644 include/dt-bindings/pinctrl/hisi.h
diff --git a/arch/arm/dts/hi3798cv200-poplar.dts
b/arch/arm/dts/hi3798cv200-poplar.dts
index 964326eae89b..d30f6eb8a5ee 100644
--- a/arch/arm/dts/hi3798cv200-poplar.dts
+++ b/arch/arm/dts/hi3798cv200-poplar.dts
@@ -1,14 +1,17 @@
-// SPDX-License-Identifier: GPL-2.0
/*
* DTS File for HiSilicon Poplar Development Board
*
* Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd.
+ *
+ * Released under the GPLv2 only.
+ * SPDX-License-Identifier: GPL-2.0
*/
/dts-v1/;
#include
#include "hi3798cv200.dtsi"
+#include "poplar-pinctrl.dtsi"
/ {
model = "HiSilicon Poplar Development Board";
@@ -59,6 +62,33 @@
default-state = "off";
};
};
+
+ reg_pcie: regulator-pcie {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3_PCIE0";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = < 7 0>;
+ enable-active-high;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_1 _pins_2
+_pins_3 _pins_4>;
+ fifo-depth = <256>;
+ clock-frequency = <2>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ non-removable;
+ bus-width = <8>;
+ status = "okay";
};
{
@@ -76,17 +106,17 @@
{
status = "okay";
- gpio-line-names = "LS-GPIO-E", "",
+ gpio-line-names = "GPIO-E", "",
"", "",
- "", "LS-GPIO-F",
- "", "LS-GPIO-J";
+ "", "GPIO-F",
+ "", "GPIO-J";
};
{
status = "okay";
- gpio-line-names = "LS-GPIO-H", "LS-GPIO-I",
- "LS-GPIO-L", "LS-GPIO-G",
- "LS-GPIO-K", "",
+ gpio-line-names = "GPIO-H", "GPIO-I",
+ "GPIO-L", "GPIO-G",
+ "GPIO-K", "",
"", "";
};
@@ -94,15 +124,15 @@
status = "okay";
gpio-line-names = "", "",
"", "",
- "LS-GPIO-C", "",
- "", "LS-GPIO-B";
+ "GPIO-C", "",
+ "", "GPIO-B";
};
{
status = "okay";
gpio-line-names = "", "",
"", "",
- "", "LS-GPIO-D",
+ "", "GPIO-D",
"", "";
};
@@ -110,7 +140,7 @@
status = "okay";
gpio-line-names = "", "USER-LED-1",
"USER-LED-2", "",
- "", "LS-GPIO-A",
+ "", "GPIO-A",
"", "";
};
@@ -144,6 +174,22 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ reset-gpios = < 4 GPIO_ACTIVE_HIGH>;
+ vpcie-supply = <_pcie>;
+ status = "okay";
+};
+
+ {
+ bus-width = <4>;
+ cap-sd-highspeed;
+ status = "okay";
+};
+
{
status = "okay";
label = "LS-SPI0";
diff --git a/arch/arm/dts/hi3798cv200.dtsi b/arch/arm/dts/hi3798cv200.dtsi
index 8b9c5ad05a19..7c0fddd7c8cf 100644
--- a/arch/arm/dts/hi3798cv200.dtsi
+++ b/arch/arm/dts/hi3798cv200.dtsi
@@ -1,12 +1,16 @@
-// SPDX-License-Identifier: GPL-2.0
/*
* DTS File for HiSilicon Hi3798cv200 SoC.
*
* Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd.
+ *
+ * Released under the GPLv2 only.
+ * SPDX-License-Identifier: GPL-2.0
*/
#include
+#include
#include
+#include
#include
/ {
@@ -104,6 +108,113 @@
#reset-cells = <2>;
};
+ perictrl: peripheral-controller@8a2 {
+ compatible = "hisilicon,hi3798cv200-perictrl", "syscon",
+"simple-mfd";
+ reg = <0x8a2 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x8a2 0x1000>;
+
+
[U-Boot] [PATCH 0/3] Enable mmc driver model for Poplar board
We take Linux Kernel as Poplar DTS upstream, and patch #1 sync up u-boot DTS with it, so that devices like MMC are available to use with u-boot driver model. Patch #2 adds Poplar mmc compatible to hi6220_dw_mmc driver, so that the driver can probe Poplar mmc device. And finally patch #3 cleans up the board level mmc initialization code, as they are not used any more. Shawn Guo (3): poplar: sync up device tree with kernel 4.20 mmc: hi6220_dw_mmc: add compatible for Poplar support poplar: clean up board level mmc initialization code arch/arm/dts/hi3798cv200-poplar.dts | 68 +- arch/arm/dts/hi3798cv200.dtsi | 221 +- arch/arm/dts/poplar-pinctrl.dtsi | 98 arch/arm/include/asm/arch-hi3798cv200/dwmmc.h | 12 - .../asm/arch-hi3798cv200/hi3798cv200.h| 1 - board/hisilicon/poplar/poplar.c | 12 - drivers/mmc/hi6220_dw_mmc.c | 1 + include/dt-bindings/clock/histb-clock.h | 56 +++-- include/dt-bindings/pinctrl/hisi.h| 74 ++ 9 files changed, 483 insertions(+), 60 deletions(-) create mode 100644 arch/arm/dts/poplar-pinctrl.dtsi delete mode 100644 arch/arm/include/asm/arch-hi3798cv200/dwmmc.h create mode 100644 include/dt-bindings/pinctrl/hisi.h -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] efi_loader: move efi_init_obj_list() to a new efi_setup.c
On Tue, Jan 15, 2019 at 04:16:52AM +0100, Heinrich Schuchardt wrote: > On 1/15/19 3:54 AM, AKASHI Takahiro wrote: > > # removed unnecessary "#if" statements from v1 > > > > The function, efi_init_obj_list(), can be shared in different pseudo efi > > applications, like bootefi/bootmgr as well as my efishell. Moreover, it > > will be utilized to extend efi initialization, for example, my "removable > > disk support" patch and "capsule-on-disk support" patch in the future. > > > > So with this patch, it will be moved to a new file, efi_setup.c, under > > lib/efi_loader and exported, making no changes in functionality. > > > > Signed-off-by: AKASHI Takahiro > > A corrected version 1 patch is already merged in efi-next: > > https://github.com/agraf/u-boot/commits/efi-next > > "efi_loader: move efi_init_obj_list() to a new efi_setup.c" > https://github.com/agraf/u-boot/commit/f30df235b5b5b3db65f89360ef114719d542ca0d Ah, I've checked but missed that. > So I think this v2 patch is obsolete. > > Should you find any mistake in the merged patch, please, provide a > follow up patch. Nothing so far. Thanks, -Takahiro Akashi > Best regards > > Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] efi_loader: implement GetNextVariableName()
Heinrich,
Thank you for your quick review.
On Wed, Jan 16, 2019 at 07:43:47PM +0100, Heinrich Schuchardt wrote:
> On 12/14/18 10:47 AM, AKASHI Takahiro wrote:
> > The current GetNextVariableName() is a placeholder.
> > With this patch, it works well as expected.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > lib/efi_loader/efi_variable.c | 116 +-
> > 1 file changed, 115 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
> > index 19d9cb865f25..dac2f49aa1cc 100644
> > --- a/lib/efi_loader/efi_variable.c
> > +++ b/lib/efi_loader/efi_variable.c
> > @@ -8,6 +8,9 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> >
> > #define READ_ONLY BIT(31)
> >
> > @@ -241,14 +244,125 @@ efi_status_t EFIAPI efi_get_variable(u16
> > *variable_name, efi_guid_t *vendor,
> > return EFI_EXIT(EFI_SUCCESS);
> > }
> >
> > +static char *efi_variables_list;
> > +static char *efi_cur_variable;
> > +
>
> Please, provide a comment describing what this function is meant to do.
I think that the function name describes itself clearly, but OK.
> Describe every parameter
>
> Clearly state set variable_name_size is in bytes (cf.
> EmuGetNextVariableName() in EDK2)
Right.
> This function duplicates some of the code in efi_get_variable. So,
> please, use it in efi_get_variable too.
Which part of code do you mean? I don't think so.
> > +static efi_status_t parse_uboot_variable(char *variable,
> > +efi_uintn_t *variable_name_size,
> > +u16 *variable_name,
> > +efi_guid_t *vendor,
> > +u32 *attribute)
> > +{
>
>
>
> > + char *guid, *name, *end, c;
> > + unsigned long name_size;
> > + u16 *p;
> > +
> > + guid = strchr(variable, '_');
> > + if (!guid)
> > + return EFI_NOT_FOUND;
> > + guid++;
> > + name = strchr(guid, '_');
> > + if (!name)
> > + return EFI_NOT_FOUND;
> > + name++;
> > + end = strchr(name, '=');
> > + if (!end)
> > + return EFI_NOT_FOUND;
> > +
> > + /* FIXME: size is in byte or u16? */
>
> It is in bytes. See comment above.
OK
> > + name_size = end - name;
> > + if (*variable_name_size < (name_size + 1)) {
> > + *variable_name_size = name_size + 1;
> > + return EFI_BUFFER_TOO_SMALL;
> > + }
> > + end++; /* point to value */
> > +
> > + p = variable_name;
> > + utf8_utf16_strncpy(, name, name_size);
> > + variable_name[name_size] = 0;
> > +
> > + c = *(name - 1);
> > + *(name - 1) = '\0'; /* guid need be null-terminated here */
> > + uuid_str_to_bin(guid, (unsigned char *)vendor, UUID_STR_FORMAT_GUID);
> > + *(name - 1) = c;
> > +
> > + parse_attr(end, attribute);
>
> You have to update variable_name_size.
Right.
> > +
> > + return EFI_SUCCESS;
> > +}
> > +
> > /*
> > http://wiki.phoenix.com/wiki/index.php/EFI_RUNTIME_SERVICES#GetNextVariableName.28.29
> > */
>
> Please add a description of the function here like we have it in
> efi_bootefi.c
OK, but not for efi_get/set_variable() as I didn't touch anything there.
> > efi_status_t EFIAPI efi_get_next_variable_name(efi_uintn_t
> > *variable_name_size,
> >u16 *variable_name,
> >efi_guid_t *vendor)
> > {
> > + char *native_name, *variable;
> > + ssize_t name_len, list_len;
> > + char regex[256];
> > + char * const regexlist[] = {regex};
> > + u32 attribute;
> > + int i;
> > + efi_status_t ret;
> > +
> > EFI_ENTRY("%p \"%ls\" %pUl", variable_name_size, variable_name, vendor);
> >
> > - return EFI_EXIT(EFI_DEVICE_ERROR);
> > + if (!variable_name_size || !variable_name || !vendor)
> > + EFI_EXIT(EFI_INVALID_PARAMETER);
> > +
> > + if (variable_name[0]) {
>
> This code partially duplicates code in in efi_get_variable. Please,
> carve out a common function.
Which part of code do you mean? I don't see any duplication.
> > + /* check null-terminated string */
> > + for (i = 0; i < *variable_name_size; i++)
> > + if (!variable_name[i])
> > + break;
> > + if (i >= *variable_name_size)
> > + return EFI_EXIT(EFI_INVALID_PARAMETER);
> > +
> > + /* search for the last-returned variable */
> > + ret = efi_to_native(_name, variable_name, vendor);
> > + if (ret)
> > + return EFI_EXIT(ret);
> > +
> > + name_len = strlen(native_name);
> > + for (variable = efi_variables_list; variable && *variable;) {
> > + if (!strncmp(variable, native_name, name_len) &&
> > + variable[name_len] == '=')
> > + break;
> > +
>
> You miss to compare
Re: [U-Boot] Problems to boot i.MX8QXP EVK board
> -Original Message-
> From: Breno Matheus Lima [mailto:brenomath...@gmail.com]
> Sent: 2019年1月17日 9:42
> To: Peng Fan
> Cc: Breno Matheus Lima ; Fabio Estevam
> ; Fabio Estevam ;
> U-Boot-Denx
> Subject: Re: Problems to boot i.MX8QXP EVK board
>
> Hi Peng,
>
> Em qua, 16 de jan de 2019 às 23:33, Peng Fan
> escreveu:
> >
> > Hi Breno,
> >
> > > -Original Message-
> > > From: Breno Matheus Lima [mailto:brenomath...@gmail.com]
> > > Sent: 2019年1月17日 9:04
> > > To: Peng Fan ; Breno Matheus Lima
> > >
> > > Cc: Fabio Estevam ; Fabio Estevam
> > > ; U-Boot-Denx
> > > Subject: Problems to boot i.MX8QXP EVK board
> > >
> > > Hi Peng,
> > >
> > > I'm not being able to boot U-Boot v2019.01 on my i.MX8QXP B0 MEK
> > > board by following README file
> (board/freescale/imx8qxp_mek/README).
> > >
> > > After reverting commit f7e475db4011("tools: imx8image: set dcd_skip
> > > to
> > > true") everything seems to be working fine.
> >
> > Are you using A0 or B0 chip? A0 chip is no being supported anymore.
> >
>
> I'm using i.MX8QXP B0:
Could you give a try using 4.14.78 GA release scfw/seco/atf + upstream uboot?
There might be some change in scfw.
Thanks,
Peng.
>
> U-Boot 2019.01-1-gc94b5e99a6 (Jan 16 2019 - 22:52:33 -0200)
>
> CPU: NXP i.MX8QXP RevB A35 at 147228 MHz
>
> Model: Freescale i.MX8QXP MEK
> Board: iMX8QXP MEK
> Build: SCFW 3301c1a9
> Boot: SD1
> DRAM: 3 GiB
> MMC: FSL_SDHC: 0, FSL_SDHC: 1
> Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
>
> In:serial@5a06
> Out: serial@5a06
> Err: serial@5a06
> Net: eth-1: ethernet@5b04
> Hit any key to stop autoboot: 0
> =>
>
> Thanks,
> Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Problems to boot i.MX8QXP EVK board
Hi Peng,
Em qua, 16 de jan de 2019 às 23:33, Peng Fan escreveu:
>
> Hi Breno,
>
> > -Original Message-
> > From: Breno Matheus Lima [mailto:brenomath...@gmail.com]
> > Sent: 2019年1月17日 9:04
> > To: Peng Fan ; Breno Matheus Lima
> >
> > Cc: Fabio Estevam ; Fabio Estevam
> > ; U-Boot-Denx
> > Subject: Problems to boot i.MX8QXP EVK board
> >
> > Hi Peng,
> >
> > I'm not being able to boot U-Boot v2019.01 on my i.MX8QXP B0 MEK board
> > by following README file (board/freescale/imx8qxp_mek/README).
> >
> > After reverting commit f7e475db4011("tools: imx8image: set dcd_skip to
> > true") everything seems to be working fine.
>
> Are you using A0 or B0 chip? A0 chip is no being supported anymore.
>
I'm using i.MX8QXP B0:
U-Boot 2019.01-1-gc94b5e99a6 (Jan 16 2019 - 22:52:33 -0200)
CPU: NXP i.MX8QXP RevB A35 at 147228 MHz
Model: Freescale i.MX8QXP MEK
Board: iMX8QXP MEK
Build: SCFW 3301c1a9
Boot: SD1
DRAM: 3 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment
In:serial@5a06
Out: serial@5a06
Err: serial@5a06
Net: eth-1: ethernet@5b04
Hit any key to stop autoboot: 0
=>
Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Problems to boot i.MX8QXP EVK board
Hi Breno,
> -Original Message-
> From: Breno Matheus Lima [mailto:brenomath...@gmail.com]
> Sent: 2019年1月17日 9:04
> To: Peng Fan ; Breno Matheus Lima
>
> Cc: Fabio Estevam ; Fabio Estevam
> ; U-Boot-Denx
> Subject: Problems to boot i.MX8QXP EVK board
>
> Hi Peng,
>
> I'm not being able to boot U-Boot v2019.01 on my i.MX8QXP B0 MEK board
> by following README file (board/freescale/imx8qxp_mek/README).
>
> After reverting commit f7e475db4011("tools: imx8image: set dcd_skip to
> true") everything seems to be working fine.
Are you using A0 or B0 chip? A0 chip is no being supported anymore.
Regards,
Peng.
>
> Do you happen to know if the procedure in README file should be enough for
> v2019.01?
>
> Thanks,
> Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/11] samsung: Tidy up sound, DM_MMC drop dead code
Hi, On 17/01/19 06:42, Simon Glass wrote: > Hi Minkyu, > > On Fri, 21 Dec 2018 at 10:35, Simon Glass wrote: >> >> Hi Minkyu, >> >> On Thu, 20 Dec 2018 at 17:40, Minkyu Kang wrote: >>> >>> Dear Simon Glass, >>> >>> On 17/12/18 11:36, Simon Glass wrote: This series was previously sent as a v1 without a cover letter. Since then I have added a few more patches: - Support for spring's audio codec - Dropping unused MMC and audio code - Removing unused fdt_compat_id values Changes in v2: - Add new patch to resync defconfigs for odroid - Remove stranded comments in the header files - Update to convert s5p_goni also - Add new patches as per the cover letter Simon Glass (11): odroid: Resync defconfigs Convert CONFIG_BOARD_TYPES to Kconfig exynos: Drop duplicate 'model' line exynos: Convert to use CONFIG_BLK sound: Add a driver for max98088 spring: Update sound to use max98088 codec spring: Update flashmap details samsung: Drop board_enable_audio_codec() samsung: mmc: Drop old MMC init code fdt: samsung: Drop unused fdt_compat_id values fdt: tegra: Drop COMPAT_AMS_AS3722 arch/arm/dts/exynos5250-spring.dts | 77 +++-- arch/arm/mach-exynos/Kconfig| 7 + arch/arm/mach-exynos/include/mach/mmc.h | 2 - arch/arm/mach-s5pc1xx/Kconfig | 2 + arch/arm/mach-s5pc1xx/Makefile | 1 + arch/arm/mach-s5pc1xx/pinmux.c | 20 ++ board/samsung/common/board.c| 52 +-- board/samsung/common/exynos5-dt.c | 29 -- common/Kconfig | 8 + configs/axs101_defconfig| 1 + configs/axs103_defconfig| 1 + configs/odroid-xu3_defconfig| 2 +- configs/odroid_defconfig| 2 +- configs/spring_defconfig| 1 + drivers/mmc/s5p_sdhci.c | 50 --- drivers/sound/Kconfig | 8 + drivers/sound/Makefile | 1 + drivers/sound/max98088.c| 431 drivers/sound/max98088.h| 192 +++ drivers/sound/samsung_sound.c | 2 +- include/configs/axs10x.h| 5 - include/configs/hsdk.h | 5 - include/configs/odroid.h| 1 - include/configs/odroid_xu3.h| 1 - include/fdtdec.h| 7 - include/samsung/misc.h | 2 - lib/fdtdec.c| 7 - scripts/config_whitelist.txt| 1 - 28 files changed, 739 insertions(+), 179 deletions(-) create mode 100644 arch/arm/mach-s5pc1xx/pinmux.c create mode 100644 drivers/sound/max98088.c create mode 100644 drivers/sound/max98088.h >>> >>> Do you want a pick patches up to your tree? >> >> I am happy to do that if you prefer, but please let me know. > > Shall I go ahead and do this? The merge window is open now. > Yes, please. I delegate this patchset to you. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/10] Convert CONFIG_BOARD_TYPES to Kconfig
On 12/01/19 10:37, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_BOARD_TYPES > > Signed-off-by: Simon Glass > Reviewed-by: Lukasz Majewski > --- > > Changes in v3: None > Changes in v2: > - Remove stranded comments in the header files > > common/Kconfig | 8 > configs/axs101_defconfig | 1 + > configs/axs103_defconfig | 1 + > configs/odroid-xu3_defconfig | 1 + > configs/odroid_defconfig | 1 + > include/configs/axs10x.h | 5 - > include/configs/hsdk.h | 5 - > include/configs/odroid.h | 1 - > include/configs/odroid_xu3.h | 1 - > scripts/config_whitelist.txt | 1 - > 10 files changed, 12 insertions(+), 13 deletions(-) > Reviewed-by: Minkyu Kang Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/10] exynos: Convert to use CONFIG_BLK
On 12/01/19 10:37, Simon Glass wrote: > Move all exynos boards over to use CONFIG_BLK. > > This converts s5p_goni also, but adding dummy functions for pinmux and > peripheral ID. This will not function correctly, but gives the maintainer > more time to convert the board if desired. > > Signed-off-by: Simon Glass > Reviewed-by: Lukasz Majewski > --- > > Changes in v3: > - Fix s3p_goni typo > > Changes in v2: > - Update to convert s5p_goni also > > arch/arm/mach-exynos/Kconfig | 7 +++ > arch/arm/mach-s5pc1xx/Kconfig | 2 ++ > arch/arm/mach-s5pc1xx/Makefile | 1 + > arch/arm/mach-s5pc1xx/pinmux.c | 20 > 4 files changed, 30 insertions(+) > create mode 100644 arch/arm/mach-s5pc1xx/pinmux.c > Reviewed-by: Minkyu Kang Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/10] samsung: Drop board_enable_audio_codec()
On 12/01/19 10:37, Simon Glass wrote:
> This function is not needed now since the audio codecs have been converted
> to proper drivers. The codec-enable GPIO is handled there.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Lukasz Majewski
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> board/samsung/common/exynos5-dt.c | 29 -
> 1 file changed, 29 deletions(-)
>
> diff --git a/board/samsung/common/exynos5-dt.c
> b/board/samsung/common/exynos5-dt.c
> index c183965b92..87eb381345 100644
> --- a/board/samsung/common/exynos5-dt.c
> +++ b/board/samsung/common/exynos5-dt.c
> @@ -34,37 +34,8 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -static void board_enable_audio_codec(void)
> -{
> - int node, ret;
> - struct gpio_desc en_gpio;
> -
> - node = fdtdec_next_compatible(gd->fdt_blob, 0,
> - COMPAT_SAMSUNG_EXYNOS5_SOUND);
> - if (node <= 0)
> - return;
> -
> - ret = gpio_request_by_name_nodev(offset_to_ofnode(node),
> - "codec-enable-gpio", 0, _gpio,
> - GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
> - if (ret == -FDT_ERR_NOTFOUND)
> - return;
> -
> - /* Turn on the GPIO which connects to the codec's "enable" line. */
> - gpio_set_pull(gpio_get_number(_gpio), S5P_GPIO_PULL_NONE);
> -
> -#ifdef CONFIG_SOUND_MAX98095
> - /* Enable MAX98095 Codec */
> - gpio_request(EXYNOS5_GPIO_X17, "max98095_enable");
> - gpio_direction_output(EXYNOS5_GPIO_X17, 1);
> - gpio_set_pull(EXYNOS5_GPIO_X17, S5P_GPIO_PULL_NONE);
> -#endif
> -}
> -
> int exynos_init(void)
> {
> - board_enable_audio_codec();
> -
> return 0;
> }
>
>
Reviewed-by: Minkyu Kang
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] exynos: Drop duplicate 'model' line
On 12/01/19 10:37, Simon Glass wrote:
> At present the model is shown twice, once in the generic code and once
> in the exynos code. Drop the latter.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Lukasz Majewski
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> board/samsung/common/board.c | 14 ++
> include/samsung/misc.h | 2 --
> 2 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> index 6fd26a3a91..3391228522 100644
> --- a/board/samsung/common/board.c
> +++ b/board/samsung/common/board.c
> @@ -290,15 +290,13 @@ int board_mmc_init(bd_t *bis)
> #ifdef CONFIG_DISPLAY_BOARDINFO
> int checkboard(void)
> {
> - const char *board_info;
> + if (IS_ENABLED(CONFIG_BOARD_TYPES)) {
> + const char *board_info = get_board_type();
> +
> + if (board_info)
> + printf("Type: %s\n", board_info);
> + }
>
> - board_info = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
> - printf("Board: %s\n", board_info ? board_info : "unknown");
> -#ifdef CONFIG_BOARD_TYPES
> - board_info = get_board_type();
> - if (board_info)
> - printf("Type: %s\n", board_info);
> -#endif
> return 0;
> }
> #endif
> diff --git a/include/samsung/misc.h b/include/samsung/misc.h
> index 0f957dc367..017560c256 100644
> --- a/include/samsung/misc.h
> +++ b/include/samsung/misc.h
> @@ -32,9 +32,7 @@ void draw_logo(void);
> char *get_dfu_alt_system(char *interface, char *devstr);
> char *get_dfu_alt_boot(char *interface, char *devstr);
> #endif
> -#ifdef CONFIG_BOARD_TYPES
> void set_board_type(void);
> const char *get_board_type(void);
> -#endif
>
> #endif /* __SAMSUNG_MISC_COMMON_H__ */
>
Reviewed-by: Minkyu Kang
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/10] samsung: mmc: Drop old MMC init code
On 12/01/19 10:37, Simon Glass wrote: > Now that these boards use driver model we can drop the old code. At > present s5p_mmc_init() is still used by goni and smdkv310 so cannot be > removed unless we remove those boards. > > Signed-off-by: Simon Glass > Reviewed-by: Lukasz Majewski > --- > > Changes in v3: None > Changes in v2: None > > arch/arm/mach-exynos/include/mach/mmc.h | 2 - > board/samsung/common/board.c| 38 --- > drivers/mmc/s5p_sdhci.c | 50 - > 3 files changed, 90 deletions(-) > Reviewed-by: Minkyu Kang Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Problems to boot i.MX8QXP EVK board
Hi Peng,
I'm not being able to boot U-Boot v2019.01 on my i.MX8QXP B0 MEK board
by following README file (board/freescale/imx8qxp_mek/README).
After reverting commit f7e475db4011("tools: imx8image: set dcd_skip to
true") everything seems to be working fine.
Do you happen to know if the procedure in README file should be enough
for v2019.01?
Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 07/17] dts: imx: Add imx6q-sabreauto dts and imx6qdl-sabreauto dtsi files
Hi Abel,
On Wed, Jan 16, 2019 at 12:09 PM Abel Vesa wrote:
> + mxcfb1: fb@0 {
> + compatible = "fsl,mxc_sdc_fb";
> + disp_dev = "ldb";
> + interface_pix_fmt = "RGB666";
> + default_bpp = <16>;
> + int_clk = <0>;
> + late_init = <0>;
> + status = "disabled";
This dts comes from the NXP kernel tree.
Please use the dts from mainline kernel instead.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 05/10] lib: lmb: extend lmb for checks at load time
On Wed, 16 Jan 2019 at 14:49, Tom Rini wrote:
>
> On Wed, Jan 16, 2019 at 10:44:16PM +0100, Simon Goldschmidt wrote:
> > Am Mi., 16. Jan. 2019, 22:34 hat Simon Glass
> > geschrieben:
> >
> > > Hi Simon,
> > >
> > > On Mon, 14 Jan 2019 at 14:38, Simon Goldschmidt
> > > wrote:
> > > >
> > > > This adds two new functions, lmb_alloc_addr and
> > > > lmb_get_unreserved_size.
> > > >
> > > > lmb_alloc_addr behaves like lmb_alloc, but it tries to allocate a
> > > > pre-specified address range. Unlike lmb_reserve, this address range
> > > > must be inside one of the memory ranges that has been set up with
> > > > lmb_add.
> > > >
> > > > lmb_get_unreserved_size returns the number of bytes that can be
> > > > used up to the next reserved region or the end of valid ram. This
> > > > can be 0 if the address passed is reserved.
> > > >
> > > > Added test for these new functions.
> > > >
> > > > Signed-off-by: Simon Goldschmidt
> > > > ---
> > > >
> > > > Changes in v10: None
> > > > Changes in v9: None
> > > > Changes in v8: None
> > > > Changes in v7: None
> > > > Changes in v6: None
> > > > Changes in v5:
> > > > - fixed lmb_alloc_addr when resulting reserved ranges get combined
> > > > - added test for these new functions
> > > >
> > > > Changes in v4: None
> > > > Changes in v2:
> > > > - added lmb_get_unreserved_size() for tftp
> > > >
> > > > include/lmb.h | 3 +
> > > > lib/lmb.c | 53 +
> > > > test/lib/lmb.c | 202 +
> > > > 3 files changed, 258 insertions(+)
> > >
> > > Reviewed-by: Simon Glass
> > >
> > > But please see suggestions/nits below.
> > >
> > > >
> > > > diff --git a/include/lmb.h b/include/lmb.h
> > > > index f04d058093..7d7e2a78dc 100644
> > > > --- a/include/lmb.h
> > > > +++ b/include/lmb.h
> > > > @@ -38,6 +38,9 @@ extern phys_addr_t lmb_alloc_base(struct lmb *lmb,
> > > phys_size_t size, ulong align
> > > > phys_addr_t max_addr);
> > > > extern phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t size,
> > > ulong align,
> > > > phys_addr_t max_addr);
> > > > +extern phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base,
> > > > + phys_size_t size);
> > >
> > > Can you please add full comments in the header for new functions.
> > >
> >
> > Sure I can but wouldn't it look odd to have one function documented in the
> > header but not the rest?
> >
> >
> > > > +extern phys_size_t lmb_get_unreserved_size(struct lmb *lmb, phys_addr_t
> > > addr);
> > > > extern int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr);
> > > > extern long lmb_free(struct lmb *lmb, phys_addr_t base, phys_size_t
> > > size);
> > > >
> > > > diff --git a/lib/lmb.c b/lib/lmb.c
> > > > index cd297f8202..e380a0a722 100644
> > > > --- a/lib/lmb.c
> > > > +++ b/lib/lmb.c
> > > > @@ -313,6 +313,59 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb,
> > > phys_size_t size, ulong align, phy
> > > > return 0;
> > > > }
> > > >
> > > > +/*
> > > > + * Try to allocate a specific address range: must be in defined memory
> > > but not
> > > > + * reserved
> > > > + */
> > > > +phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base,
> > > phys_size_t size)
> > > > +{
> > > > + long j;
> > >
> > > How about addr instead of j? I think single-char vars are OK for loop
> > > counters, etc. but this is not that.
> > >
> >
> > Sure.
> >
> >
> > > > +
> > > > + /* Check if the requested address is in one of the memory
> > > regions */
> > > > + j = lmb_overlaps_region(>memory, base, size);
> > > > + if (j >= 0) {
> > > > + /*
> > > > +* Check if the requested end address is in the same
> > > memory
> > > > +* region we found.
> > > > +*/
> > > > + if (lmb_addrs_overlap(lmb->memory.region[j].base,
> > > > + lmb->memory.region[j].size, base +
> > > size -
> > > > + 1, 1)) {
> > > > + /* ok, reserve the memory */
> > > > + if (lmb_reserve(lmb, base, size) >= 0)
> > > > + return base;
> > > > + }
> > > > + }
> > > > + return 0;
> > > > +}
> > > > +
> > > > +/* Return number of bytes from a given address that are free */
> > > > +phys_size_t lmb_get_unreserved_size(struct lmb *lmb, phys_addr_t addr)
> > >
> > > I support you use 'unreserved' instead of 'free' due to some subtle
> > > difference in meaning? Can you add a comment somewhere about this?
> > >
> >
> > Actually no, the name could be changed to 'lmb_get_free_size' if you like.
> >
> >
> > > > +{
> > > > + int i;
> > > > + long j;
> > >
> > > Here too - addr?
> > >
> >
> > Yes.
> >
> >
> > > > +
> > > > + /* check if the requested address is in the memory regions */
> > > > + j =
Re: [U-Boot] [PATCH v10 05/10] lib: lmb: extend lmb for checks at load time
On Wed, Jan 16, 2019 at 10:44:16PM +0100, Simon Goldschmidt wrote:
> Am Mi., 16. Jan. 2019, 22:34 hat Simon Glass geschrieben:
>
> > Hi Simon,
> >
> > On Mon, 14 Jan 2019 at 14:38, Simon Goldschmidt
> > wrote:
> > >
> > > This adds two new functions, lmb_alloc_addr and
> > > lmb_get_unreserved_size.
> > >
> > > lmb_alloc_addr behaves like lmb_alloc, but it tries to allocate a
> > > pre-specified address range. Unlike lmb_reserve, this address range
> > > must be inside one of the memory ranges that has been set up with
> > > lmb_add.
> > >
> > > lmb_get_unreserved_size returns the number of bytes that can be
> > > used up to the next reserved region or the end of valid ram. This
> > > can be 0 if the address passed is reserved.
> > >
> > > Added test for these new functions.
> > >
> > > Signed-off-by: Simon Goldschmidt
> > > ---
> > >
> > > Changes in v10: None
> > > Changes in v9: None
> > > Changes in v8: None
> > > Changes in v7: None
> > > Changes in v6: None
> > > Changes in v5:
> > > - fixed lmb_alloc_addr when resulting reserved ranges get combined
> > > - added test for these new functions
> > >
> > > Changes in v4: None
> > > Changes in v2:
> > > - added lmb_get_unreserved_size() for tftp
> > >
> > > include/lmb.h | 3 +
> > > lib/lmb.c | 53 +
> > > test/lib/lmb.c | 202 +
> > > 3 files changed, 258 insertions(+)
> >
> > Reviewed-by: Simon Glass
> >
> > But please see suggestions/nits below.
> >
> > >
> > > diff --git a/include/lmb.h b/include/lmb.h
> > > index f04d058093..7d7e2a78dc 100644
> > > --- a/include/lmb.h
> > > +++ b/include/lmb.h
> > > @@ -38,6 +38,9 @@ extern phys_addr_t lmb_alloc_base(struct lmb *lmb,
> > phys_size_t size, ulong align
> > > phys_addr_t max_addr);
> > > extern phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t size,
> > ulong align,
> > > phys_addr_t max_addr);
> > > +extern phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base,
> > > + phys_size_t size);
> >
> > Can you please add full comments in the header for new functions.
> >
>
> Sure I can but wouldn't it look odd to have one function documented in the
> header but not the rest?
>
>
> > > +extern phys_size_t lmb_get_unreserved_size(struct lmb *lmb, phys_addr_t
> > addr);
> > > extern int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr);
> > > extern long lmb_free(struct lmb *lmb, phys_addr_t base, phys_size_t
> > size);
> > >
> > > diff --git a/lib/lmb.c b/lib/lmb.c
> > > index cd297f8202..e380a0a722 100644
> > > --- a/lib/lmb.c
> > > +++ b/lib/lmb.c
> > > @@ -313,6 +313,59 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb,
> > phys_size_t size, ulong align, phy
> > > return 0;
> > > }
> > >
> > > +/*
> > > + * Try to allocate a specific address range: must be in defined memory
> > but not
> > > + * reserved
> > > + */
> > > +phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base,
> > phys_size_t size)
> > > +{
> > > + long j;
> >
> > How about addr instead of j? I think single-char vars are OK for loop
> > counters, etc. but this is not that.
> >
>
> Sure.
>
>
> > > +
> > > + /* Check if the requested address is in one of the memory
> > regions */
> > > + j = lmb_overlaps_region(>memory, base, size);
> > > + if (j >= 0) {
> > > + /*
> > > +* Check if the requested end address is in the same
> > memory
> > > +* region we found.
> > > +*/
> > > + if (lmb_addrs_overlap(lmb->memory.region[j].base,
> > > + lmb->memory.region[j].size, base +
> > size -
> > > + 1, 1)) {
> > > + /* ok, reserve the memory */
> > > + if (lmb_reserve(lmb, base, size) >= 0)
> > > + return base;
> > > + }
> > > + }
> > > + return 0;
> > > +}
> > > +
> > > +/* Return number of bytes from a given address that are free */
> > > +phys_size_t lmb_get_unreserved_size(struct lmb *lmb, phys_addr_t addr)
> >
> > I support you use 'unreserved' instead of 'free' due to some subtle
> > difference in meaning? Can you add a comment somewhere about this?
> >
>
> Actually no, the name could be changed to 'lmb_get_free_size' if you like.
>
>
> > > +{
> > > + int i;
> > > + long j;
> >
> > Here too - addr?
> >
>
> Yes.
>
>
> > > +
> > > + /* check if the requested address is in the memory regions */
> > > + j = lmb_overlaps_region(>memory, addr, 1);
> > > + if (j >= 0) {
> > > + for (i = 0; i < lmb->reserved.cnt; i++) {
> > > + if (addr < lmb->reserved.region[i].base) {
> > > + /* first reserved range > requested
> > address */
> > > + return
Re: [U-Boot] [PATCH v10 05/10] lib: lmb: extend lmb for checks at load time
Am Mi., 16. Jan. 2019, 22:34 hat Simon Glass geschrieben:
> Hi Simon,
>
> On Mon, 14 Jan 2019 at 14:38, Simon Goldschmidt
> wrote:
> >
> > This adds two new functions, lmb_alloc_addr and
> > lmb_get_unreserved_size.
> >
> > lmb_alloc_addr behaves like lmb_alloc, but it tries to allocate a
> > pre-specified address range. Unlike lmb_reserve, this address range
> > must be inside one of the memory ranges that has been set up with
> > lmb_add.
> >
> > lmb_get_unreserved_size returns the number of bytes that can be
> > used up to the next reserved region or the end of valid ram. This
> > can be 0 if the address passed is reserved.
> >
> > Added test for these new functions.
> >
> > Signed-off-by: Simon Goldschmidt
> > ---
> >
> > Changes in v10: None
> > Changes in v9: None
> > Changes in v8: None
> > Changes in v7: None
> > Changes in v6: None
> > Changes in v5:
> > - fixed lmb_alloc_addr when resulting reserved ranges get combined
> > - added test for these new functions
> >
> > Changes in v4: None
> > Changes in v2:
> > - added lmb_get_unreserved_size() for tftp
> >
> > include/lmb.h | 3 +
> > lib/lmb.c | 53 +
> > test/lib/lmb.c | 202 +
> > 3 files changed, 258 insertions(+)
>
> Reviewed-by: Simon Glass
>
> But please see suggestions/nits below.
>
> >
> > diff --git a/include/lmb.h b/include/lmb.h
> > index f04d058093..7d7e2a78dc 100644
> > --- a/include/lmb.h
> > +++ b/include/lmb.h
> > @@ -38,6 +38,9 @@ extern phys_addr_t lmb_alloc_base(struct lmb *lmb,
> phys_size_t size, ulong align
> > phys_addr_t max_addr);
> > extern phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t size,
> ulong align,
> > phys_addr_t max_addr);
> > +extern phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base,
> > + phys_size_t size);
>
> Can you please add full comments in the header for new functions.
>
Sure I can but wouldn't it look odd to have one function documented in the
header but not the rest?
> > +extern phys_size_t lmb_get_unreserved_size(struct lmb *lmb, phys_addr_t
> addr);
> > extern int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr);
> > extern long lmb_free(struct lmb *lmb, phys_addr_t base, phys_size_t
> size);
> >
> > diff --git a/lib/lmb.c b/lib/lmb.c
> > index cd297f8202..e380a0a722 100644
> > --- a/lib/lmb.c
> > +++ b/lib/lmb.c
> > @@ -313,6 +313,59 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb,
> phys_size_t size, ulong align, phy
> > return 0;
> > }
> >
> > +/*
> > + * Try to allocate a specific address range: must be in defined memory
> but not
> > + * reserved
> > + */
> > +phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base,
> phys_size_t size)
> > +{
> > + long j;
>
> How about addr instead of j? I think single-char vars are OK for loop
> counters, etc. but this is not that.
>
Sure.
> > +
> > + /* Check if the requested address is in one of the memory
> regions */
> > + j = lmb_overlaps_region(>memory, base, size);
> > + if (j >= 0) {
> > + /*
> > +* Check if the requested end address is in the same
> memory
> > +* region we found.
> > +*/
> > + if (lmb_addrs_overlap(lmb->memory.region[j].base,
> > + lmb->memory.region[j].size, base +
> size -
> > + 1, 1)) {
> > + /* ok, reserve the memory */
> > + if (lmb_reserve(lmb, base, size) >= 0)
> > + return base;
> > + }
> > + }
> > + return 0;
> > +}
> > +
> > +/* Return number of bytes from a given address that are free */
> > +phys_size_t lmb_get_unreserved_size(struct lmb *lmb, phys_addr_t addr)
>
> I support you use 'unreserved' instead of 'free' due to some subtle
> difference in meaning? Can you add a comment somewhere about this?
>
Actually no, the name could be changed to 'lmb_get_free_size' if you like.
> > +{
> > + int i;
> > + long j;
>
> Here too - addr?
>
Yes.
> > +
> > + /* check if the requested address is in the memory regions */
> > + j = lmb_overlaps_region(>memory, addr, 1);
> > + if (j >= 0) {
> > + for (i = 0; i < lmb->reserved.cnt; i++) {
> > + if (addr < lmb->reserved.region[i].base) {
> > + /* first reserved range > requested
> address */
> > + return lmb->reserved.region[i].base -
> addr;
> > + }
> > + if (lmb->reserved.region[i].base +
> > + lmb->reserved.region[i].size > addr) {
> > + /* requested addr is in this reserved
> range */
> > + return 0;
> > + }
> > +
Re: [U-Boot] [PATCH v2 00/11] samsung: Tidy up sound, DM_MMC drop dead code
Hi Minkyu, On Fri, 21 Dec 2018 at 10:35, Simon Glass wrote: > > Hi Minkyu, > > On Thu, 20 Dec 2018 at 17:40, Minkyu Kang wrote: > > > > Dear Simon Glass, > > > > On 17/12/18 11:36, Simon Glass wrote: > > > This series was previously sent as a v1 without a cover letter. Since then > > > I have added a few more patches: > > > > > > - Support for spring's audio codec > > > - Dropping unused MMC and audio code > > > - Removing unused fdt_compat_id values > > > > > > Changes in v2: > > > - Add new patch to resync defconfigs for odroid > > > - Remove stranded comments in the header files > > > - Update to convert s5p_goni also > > > - Add new patches as per the cover letter > > > > > > Simon Glass (11): > > > odroid: Resync defconfigs > > > Convert CONFIG_BOARD_TYPES to Kconfig > > > exynos: Drop duplicate 'model' line > > > exynos: Convert to use CONFIG_BLK > > > sound: Add a driver for max98088 > > > spring: Update sound to use max98088 codec > > > spring: Update flashmap details > > > samsung: Drop board_enable_audio_codec() > > > samsung: mmc: Drop old MMC init code > > > fdt: samsung: Drop unused fdt_compat_id values > > > fdt: tegra: Drop COMPAT_AMS_AS3722 > > > > > > arch/arm/dts/exynos5250-spring.dts | 77 +++-- > > > arch/arm/mach-exynos/Kconfig| 7 + > > > arch/arm/mach-exynos/include/mach/mmc.h | 2 - > > > arch/arm/mach-s5pc1xx/Kconfig | 2 + > > > arch/arm/mach-s5pc1xx/Makefile | 1 + > > > arch/arm/mach-s5pc1xx/pinmux.c | 20 ++ > > > board/samsung/common/board.c| 52 +-- > > > board/samsung/common/exynos5-dt.c | 29 -- > > > common/Kconfig | 8 + > > > configs/axs101_defconfig| 1 + > > > configs/axs103_defconfig| 1 + > > > configs/odroid-xu3_defconfig| 2 +- > > > configs/odroid_defconfig| 2 +- > > > configs/spring_defconfig| 1 + > > > drivers/mmc/s5p_sdhci.c | 50 --- > > > drivers/sound/Kconfig | 8 + > > > drivers/sound/Makefile | 1 + > > > drivers/sound/max98088.c| 431 > > > drivers/sound/max98088.h| 192 +++ > > > drivers/sound/samsung_sound.c | 2 +- > > > include/configs/axs10x.h| 5 - > > > include/configs/hsdk.h | 5 - > > > include/configs/odroid.h| 1 - > > > include/configs/odroid_xu3.h| 1 - > > > include/fdtdec.h| 7 - > > > include/samsung/misc.h | 2 - > > > lib/fdtdec.c| 7 - > > > scripts/config_whitelist.txt| 1 - > > > 28 files changed, 739 insertions(+), 179 deletions(-) > > > create mode 100644 arch/arm/mach-s5pc1xx/pinmux.c > > > create mode 100644 drivers/sound/max98088.c > > > create mode 100644 drivers/sound/max98088.h > > > > > > > Do you want a pick patches up to your tree? > > I am happy to do that if you prefer, but please let me know. Shall I go ahead and do this? The merge window is open now. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] lib: Kconfig: spelling fixes
On Sun, 13 Jan 2019 at 02:14, Chris Packham wrote: > > Signed-off-by: Chris Packham > --- > > lib/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] disk: efi: GUIDs should be const
On Sat, 12 Jan 2019 at 03:30, Heinrich Schuchardt wrote: > > Make system_guid const. > > Signed-off-by: Heinrich Schuchardt > --- > disk/part_efi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] common: spl: Kconfig: spelling fixes
On Sun, 13 Jan 2019 at 02:14, Chris Packham wrote: > > Signed-off-by: Chris Packham > --- > > common/spl/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/4] serial: add an of-platdata driver for "snps, dw-apb-uart"
Hi Simon, On Fri, 11 Jan 2019 at 03:02, Simon Goldschmidt wrote: > > On Fri, Jan 11, 2019 at 10:22 AM Andy Shevchenko > wrote: > > > > On Wed, Jan 9, 2019 at 10:36 AM Alexey Brodkin > > wrote: > > > > > > > Might be a bit naïve question but why depend on SPL_OF_PLATDATA only? > > > What about CONFIG_OF_EMBED? > > > > No driver should depend on OF_EMBED IIUC. New U-Boot spils a warning > > when production boards are using it. > > By now, actually I even dislike the idea of depending on OF_PLATDATA myself. > Maybe we should fix the OF_PLATDATA to driver matching code to better handle > drivers with multiple compatible strings instead of adding dedicated drivers. Sounds good. One option I rejected with the initial impl was to add tags to the DT to tell dtoc what to do. I still hope to avoid that, but it is an option, if helpful. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 08/10] pinctrl: Kconfig: spelling fixes
On Sun, 13 Jan 2019 at 02:14, Chris Packham wrote: > > Signed-off-by: Chris Packham > --- > > drivers/pinctrl/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] x86: Kconfig: spelling fixes
On Sun, 13 Jan 2019 at 02:14, Chris Packham wrote: > > Signed-off-by: Chris Packham > --- > > arch/x86/cpu/qemu/Kconfig | 2 +- > arch/x86/cpu/quark/Kconfig | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] power: regulator: Introduce regulator_set_enable_if_allowed api
On Fri, 11 Jan 2019 at 02:46, Lokesh Vutla wrote: > > regulator_set_enable() api throws an error in the following three cases: > - when requested to disable an always-on regulator > - when set_enable() ops not provided by regulator driver > - when enabling is actually failed.(Error returned by the regulator driver) > > Sometimes consumer drivers doesn't want to track the first two scenarios > and just need to worry about the case where enabling is actually failed. > But it is also a good practice to have an error value returned in the > first two cases. > > So introduce an api regulator_set_enable_if_allowed() which ignores the > first two error cases and returns an error as given by regulator driver. > Consumer drivers can use this api need not worry about the first two > error conditions. > > Signed-off-by: Lokesh Vutla > --- > drivers/power/regulator/regulator-uclass.c | 11 +++ > include/power/regulator.h | 11 +++ > test/dm/regulator.c| 21 + > 3 files changed, 43 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] Kconfig: fix spelling
On Sun, 13 Jan 2019 at 02:13, Chris Packham wrote: > > Signed-off-by: Chris Packham > --- > > Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time
Hi Alex, On Sat, 12 Jan 2019 at 15:00, Alexander Graf wrote: > > > > > Am 12.01.2019 um 22:32 schrieb Simon Glass : > > > > Hi Alex, > > > >> On Fri, 11 Jan 2019 at 00:57, Alexander Graf wrote: > >> > >> > >> > >>> On 11.01.19 05:29, AKASHI Takahiro wrote: > >>> Alex, Heinrich and Simon, > >>> > >>> Thank you for your comments, they are all valuable but also make me > >>> confused as different people have different requirements :) > >>> I'm not sure that all of us share the same *ultimate* goal here. > >> > >> The shared ultimate goal is to "merge" (as Simon put it) dm and efi > >> objects. > >> > >> But we have this annoying interim state where we would lose a few boards > >> because they haven't been converted to DM. That's what keeps us from it. > > > > I don't think that is true anymore. The deadline for patches is > > effectively 28th January. > > > >> > >> I think what this discussion boils down to is that someone needs to > >> start prototyping the DM/EFI integration. Start off with a simple > >> subsystem, like BLK. Then provide a DM path and have a non-DM fallback > >> still in its own source file that also provides EFI BLK devices. > >> Eventually we just remove the latter. > > > > No fallback, please. As above, it is time to remove code that does not > > use CONFIG_BLK. > > > >> > >> That way we can then work on getting hotplug working in the DM path, > >> which is the one we want anyway. For non-DM, you simply miss out on that > >> amazing new feature, but we don't regress users. > > > > Of which there will not be any as of 2019.04. I'm sorry to belabour > > this point, but I feel quite strongly that we should not be adding new > > code to old frameworks. We should instead be migrating away from them > > and deleting them. > > I was thinking of an isolated file that we could just remove eventually. > > But if we're getting to a dm only world with 2019.04 already, I'll be happy > to merge code that merges efi and dm objects for that release. > > The one thing I do not want here is any functional regression. If a board > worked with efi in 2019.01, it better works at least as well in 2019.04. So long as it supports BLK, yes. If it doesn't then I suppose it will be removed anyway. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 03/10] lib: lmb: reserving overlapping regions should fail
On Mon, 14 Jan 2019 at 14:38, Simon Goldschmidt wrote: > > lmb_add_region handles overlapping regions wrong: instead of merging > or rejecting to add a new reserved region that overlaps an existing > one, it just adds the new region. > > Since internally the same function is used for lmb_alloc, change > lmb_add_region to reject overlapping regions. > > Also, to keep reserved memory correct after 'free', reserved entries > created by allocating memory must not set their size to a multiple > of alignment but to the original size. This ensures the reserved > region is completely removed when the caller calls 'lmb_free', as > this one takes the same size as passed to 'lmb_alloc' etc. > > Add test to assert this. > > Signed-off-by: Simon Goldschmidt > --- > > Changes in v10: None > Changes in v9: None > Changes in v8: None > Changes in v7: > - add braces around if/else with macros accross more than one line > > Changes in v6: > - fix size of allocated regions that need alignment padding > > Changes in v5: > - added a test for this bug > > Changes in v4: None > Changes in v2: None > > lib/lmb.c | 11 +++--- > test/lib/lmb.c | 95 +- > 2 files changed, 91 insertions(+), 15 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: use u16* for file name
On Sat, 12 Jan 2019 at 04:02, Heinrich Schuchardt wrote:
>
> UTF-16 strings in our code should all be u16 *. Fix an inconsistency for
> file names which may lead to a warning for printf("%ls", ).
>
> Simon Glass
> Signed-off-by: Heinrich Schuchardt
> ---
> v2
> additionally correct efi_selftest_block_device.c
> ---
> include/efi_api.h| 2 +-
> lib/efi_loader/efi_file.c| 14 +++---
> lib/efi_selftest/efi_selftest_block_device.c | 6 +++---
> 3 files changed, 11 insertions(+), 11 deletions(-)
Reviewed-by: Simon Glass
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] dm: pinctrl: Prevent (re-)configuring pins when already done before relocation
Hi Lukasz, On Sat, 12 Jan 2019 at 14:46, Lukasz Majewski wrote: > > Hi Alex, > > > On Tue, Jan 8, 2019 at 11:24 PM Lukasz Majewski wrote: > > > > > > Hi Alex, > > > > > > > On Tue, Jan 8, 2019 at 10:52 PM Lukasz Majewski > > > > wrote: > > > > > > > > > > Hi Alex, > > > > > > > > > > > On Thu, Dec 27, 2018 at 3:49 PM Tom Rini > > > > > > wrote: > > > > > > > > > > > > > > On Tue, Dec 18, 2018 at 12:30:50PM +0100, Lukasz Majewski > > > > > > > wrote: > > > > > > > > This commit prevents from re-configuring pins if those > > > > > > > > were configured before relocation. > > > > > > > > > > > > > > > > Some pins - like UART or DDR must be setup before > > > > > > > > relocation (as they have 'u-boot,dm-pre-reloc' property > > > > > > > > set in DTS). Without this change, those pins are > > > > > > > > re-configured after relocation (pre_reloc_only = 0, so we > > > > > > > > do not "continue"). Such behavior may be a problem for > > > > > > > > DDR PAD configuration, as they might be already > > > > > > > > leveled/tuned with original setup). > > > > > > > > > > > > > > > > Signed-off-by: Lukasz Majewski > > > > > > > > > > > > > > Applied to u-boot/master, thanks! > > > > > > > > > > > > > > > > > > > I've bisected out to this commit and it's slightly broken > > > > > > things for me on an AM3352. It all works fine so long as I > > > > > > boot MLO from MMC (so the MMC is probed, pinctrl setup), but > > > > > > if I boot from UART then I get to full U-Boot, MMC hasn't > > > > > > been probed and the pinmuxing isn't set up for the MMC. > > > > > > > > > > I suppose that the pinmux node have set "u-boot,dm-pre-reloc" > > > > > property? > > > > > > > > > > > > > Yeah, well "u-boot,dm-spl", though now I re-read the docs I guess > > > > that's equivalent to "u-boot,dm-pre-reloc" as I've no TPL. > > > > > > I do need to check this -> as in my case I do have > > > "u-boot,dm-pre-reloc" property. And yes, in my case I do not have > > > TPL too (just SPL). > > > > > > > > > > > > The problem is not with lack of eMMC probing - it is with > > > > > pinctrl nodes having "u-boot,dm-pre-reloc" set in DTS and the > > > > > eMMC is probed after MLO/SPL. > > > > > It looks like your use case implicitly depends on pinmux being > > > > > reconfigured no matter if we are pre-relocated (MLO) or > > > > > afterwards. > > > > > > > > Yes, that's a much clearer description... > > > > > > Frankly, your mail opened my eyes to a use case which was handled (I > > > assume on purpose) with the old code - the "cross" boot with pinmux > > > and devices. > > > > > > For example boot from UART (MLO/SPL) and then continue with eMMC > > > (which require pinmux). > > > > > > > So I guess this needs something like a bloblist to communicate the > > initialisation state between MLO/SPL and u-boot, > > Yes. IMHO this is one way to do it. There is already a > DM_FLAG_ACTIVATED, which indicates if the device was probed. However, > it is not "dragged" from MLO / SPL to u-boot.img > > However, I think that we shall introduce a new flag - > DM_FLAG_CONFIGURE_ONCE [*], which would indicate that the device need > single configuration. > > This flag could be used with DM_PINMUX driver, to avoid > re-configuration. > > The idea would be to use bloblist (only when [*] is set) to pass tuples: > (driver_name, config_status) That seems reasonable, but I don't like the idea of using a name. Could we have some sort of numeric value instead? > > and in the core of DM just check if we shall re-configure the driver or > not. > > > which I've not the > > faintest idea where to start on. > > > > Horrible as they are, is a CONFIG symbol a possibility whilst we > > figure out how to solve this properly? > > The bloblist can be activated with CONFIG_BLOBLIST > > > > > I guess another option would be an additional two properties that give > > the two behaviours, but that feels like something we don't want long > > term. > > As we strive to use as little "u-boot,XX" extra properties to avoid > problems with Linux re-sync, I think that we shall use bloblist. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/10] drivers: Kconfig: spelling fixes
On Sun, 13 Jan 2019 at 02:14, Chris Packham wrote: > > Signed-off-by: Chris Packham > --- > > drivers/core/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] of-platdata: improve documentation
On Wed, 16 Jan 2019 at 12:40, Simon Goldschmidt wrote: > > Improve some things in the documentation of OF_PLATDATA that I found > while porting socfgpa_gen5 to it. > > Signed-off-by: Simon Goldschmidt > --- > > Changes in v2: > - further fixes noted by Simon Glass > - added info about missing node relations > - moved the passage about phandles into section 'caveats' > > doc/driver-model/of-plat.txt | 31 --- > dts/Kconfig | 6 ++ > 2 files changed, 22 insertions(+), 15 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 08/10] lmb: remove unused extern declaration
On Mon, 14 Jan 2019 at 14:38, Simon Goldschmidt wrote: > > lmb.h includes an extern declaration of "struct lmb lmb;" which > is not used anywhere, so remove it. > > Signed-off-by: Simon Goldschmidt > --- > > Changes in v10: None > Changes in v9: None > Changes in v8: None > Changes in v7: None > Changes in v6: None > Changes in v5: None > Changes in v4: None > Changes in v2: > - this patch is new in v2 > > include/lmb.h | 2 -- > 1 file changed, 2 deletions(-) Reviewed-by: Simon Glass Great! \ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 05/10] lib: lmb: extend lmb for checks at load time
Hi Simon,
On Mon, 14 Jan 2019 at 14:38, Simon Goldschmidt
wrote:
>
> This adds two new functions, lmb_alloc_addr and
> lmb_get_unreserved_size.
>
> lmb_alloc_addr behaves like lmb_alloc, but it tries to allocate a
> pre-specified address range. Unlike lmb_reserve, this address range
> must be inside one of the memory ranges that has been set up with
> lmb_add.
>
> lmb_get_unreserved_size returns the number of bytes that can be
> used up to the next reserved region or the end of valid ram. This
> can be 0 if the address passed is reserved.
>
> Added test for these new functions.
>
> Signed-off-by: Simon Goldschmidt
> ---
>
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5:
> - fixed lmb_alloc_addr when resulting reserved ranges get combined
> - added test for these new functions
>
> Changes in v4: None
> Changes in v2:
> - added lmb_get_unreserved_size() for tftp
>
> include/lmb.h | 3 +
> lib/lmb.c | 53 +
> test/lib/lmb.c | 202 +
> 3 files changed, 258 insertions(+)
Reviewed-by: Simon Glass
But please see suggestions/nits below.
>
> diff --git a/include/lmb.h b/include/lmb.h
> index f04d058093..7d7e2a78dc 100644
> --- a/include/lmb.h
> +++ b/include/lmb.h
> @@ -38,6 +38,9 @@ extern phys_addr_t lmb_alloc_base(struct lmb *lmb,
> phys_size_t size, ulong align
> phys_addr_t max_addr);
> extern phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t size, ulong
> align,
> phys_addr_t max_addr);
> +extern phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base,
> + phys_size_t size);
Can you please add full comments in the header for new functions.
> +extern phys_size_t lmb_get_unreserved_size(struct lmb *lmb, phys_addr_t
> addr);
> extern int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr);
> extern long lmb_free(struct lmb *lmb, phys_addr_t base, phys_size_t size);
>
> diff --git a/lib/lmb.c b/lib/lmb.c
> index cd297f8202..e380a0a722 100644
> --- a/lib/lmb.c
> +++ b/lib/lmb.c
> @@ -313,6 +313,59 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb,
> phys_size_t size, ulong align, phy
> return 0;
> }
>
> +/*
> + * Try to allocate a specific address range: must be in defined memory but
> not
> + * reserved
> + */
> +phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base, phys_size_t
> size)
> +{
> + long j;
How about addr instead of j? I think single-char vars are OK for loop
counters, etc. but this is not that.
> +
> + /* Check if the requested address is in one of the memory regions */
> + j = lmb_overlaps_region(>memory, base, size);
> + if (j >= 0) {
> + /*
> +* Check if the requested end address is in the same memory
> +* region we found.
> +*/
> + if (lmb_addrs_overlap(lmb->memory.region[j].base,
> + lmb->memory.region[j].size, base + size
> -
> + 1, 1)) {
> + /* ok, reserve the memory */
> + if (lmb_reserve(lmb, base, size) >= 0)
> + return base;
> + }
> + }
> + return 0;
> +}
> +
> +/* Return number of bytes from a given address that are free */
> +phys_size_t lmb_get_unreserved_size(struct lmb *lmb, phys_addr_t addr)
I support you use 'unreserved' instead of 'free' due to some subtle
difference in meaning? Can you add a comment somewhere about this?
> +{
> + int i;
> + long j;
Here too - addr?
> +
> + /* check if the requested address is in the memory regions */
> + j = lmb_overlaps_region(>memory, addr, 1);
> + if (j >= 0) {
> + for (i = 0; i < lmb->reserved.cnt; i++) {
> + if (addr < lmb->reserved.region[i].base) {
> + /* first reserved range > requested address */
> + return lmb->reserved.region[i].base - addr;
> + }
> + if (lmb->reserved.region[i].base +
> + lmb->reserved.region[i].size > addr) {
> + /* requested addr is in this reserved range */
> + return 0;
> + }
> + }
> + /* if we come here: no reserved ranges above requested addr */
> + return lmb->memory.region[lmb->memory.cnt - 1].base +
> + lmb->memory.region[lmb->memory.cnt - 1].size - addr;
> + }
> + return 0;
> +}
> +
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v10 02/10] lmb: fix allocation at end of address range
On Mon, 14 Jan 2019 at 14:38, Simon Goldschmidt wrote: > > The lmb code fails if base + size of RAM overflows to zero. > > Fix this by calculating end as 'base + size - 1' instead of 'base + size' > where appropriate. > > Added tests to assert this is fixed. > > Signed-off-by: Simon Goldschmidt > --- > > Changes in v10: None > Changes in v9: None > Changes in v8: None > Changes in v7: None > Changes in v6: None > Changes in v5: > - this patch is new in v5 > > Changes in v4: None > Changes in v2: None > > lib/lmb.c | 29 - > test/lib/lmb.c | 29 ++--- > 2 files changed, 38 insertions(+), 20 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] arm64: zynqmp: Align u-boot-spl.bin for boot.bin creation
On Wed, 16 Jan 2019 at 04:24, Michal Simek wrote: > > Bootrom is not capable to work with non align bootloader partition > that's why it is necessary to align it before boot.bin creation. > The patch is creating new spl/u-boot-spl-align.bin which is used only > for boot.bin. > > Signed-off-by: Michal Simek > --- > > Changes in v2: > - New patch for solving issue with zynqmpimage.c > > scripts/Makefile.spl | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Can we use binman for zynq? Also, why not always align? Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] nyan-big: add padding to its file
On Wed, 16 Jan 2019 at 11:50, Tristan Bastian wrote: > > Without this padding nyan-big ends at a blank screen on boot. > Details on how to get to this padding can be found in the README.chromium > under Notes. > > Signed-off-by: Tristan Bastian > --- > doc/chromium/nyan-big.its | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] nyan-big: change spi delay
On Wed, 16 Jan 2019 at 11:50, Tristan Bastian wrote: > > Internal keyboard of nyan-big is only working when cold booting by pressing > [reload/refresh]+[power] button. > With this patch keyboard is working by only pressing [power] button. > > Signed-off-by: Tristan Bastian > --- > arch/arm/dts/tegra124-nyan-big-u-boot.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 4/7] ARM: mach-omap2: Kconfig: Allow OMAP5 devices to set entry point
On Wed, Dec 05, 2018 at 11:51:33AM -0600, Andrew F. Davis wrote: > Like AM33xx and AM43xx, DRA7xx and AM57xx devices may need to > have an non-standard boot address in memory. This may be due > to the device being a high security variant, which place the > Initial SoftWare (ISW) after certificates and secure software. > > Allow these devices to set this from Kconfig. > > Signed-off-by: Andrew F. Davis > Reviewed-by: Tom Rini > --- > arch/arm/mach-omap2/Kconfig| 13 + > arch/arm/mach-omap2/am33xx/Kconfig | 15 --- > include/configs/ti_omap5_common.h | 2 +- > 3 files changed, 14 insertions(+), 16 deletions(-) Turns out this breaks OMAP3 among others as the question is asked there now and we have no default value (nor I suspect a reasonable one). Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] of-platdata: improve documentation
Improve some things in the documentation of OF_PLATDATA that I found while porting socfgpa_gen5 to it. Signed-off-by: Simon Goldschmidt --- Changes in v2: - further fixes noted by Simon Glass - added info about missing node relations - moved the passage about phandles into section 'caveats' doc/driver-model/of-plat.txt | 31 --- dts/Kconfig | 6 ++ 2 files changed, 22 insertions(+), 15 deletions(-) diff --git a/doc/driver-model/of-plat.txt b/doc/driver-model/of-plat.txt index 732bc34f06..0109ec56c3 100644 --- a/doc/driver-model/of-plat.txt +++ b/doc/driver-model/of-plat.txt @@ -64,17 +64,24 @@ strictly necessary. Notable problems include: normally also supports device tree it must use #ifdef to separate out this code, since the structures are only available in SPL. + - Correct relations between nodes are not implemented. This means that +parent/child relations (like bus device iteration) do not work yet. +Some phandles (those that are recognised as such) are converted into +a pointer to platform data. This pointer can potentially be used to +access the referenced device (by searching for the pointer value). +This feature is not yet implemented, however. + How it works -The feature is enabled by CONFIG SPL_OF_PLATDATA. This is only available -in SPL and should be tested with: +The feature is enabled by CONFIG OF_PLATDATA. This is only available in +SPL/TPL and should be tested with: -#if CONFIG_IS_ENABLED(SPL_OF_PLATDATA) +#if CONFIG_IS_ENABLED(OF_PLATDATA) A new tool called 'dtoc' converts a device tree file either into a set of -struct declarations, one for each compatible node, or a set of +struct declarations, one for each compatible node, and a set of U_BOOT_DEVICE() declarations along with the actual platform data for each device. As an example, consider this MMC node: @@ -156,6 +163,13 @@ This avoids the code overhead of converting the device tree data to platform data in the driver. The ofdata_to_platdata() method should therefore do nothing in such a driver. +Note that for the platform data to be matched with a driver, the 'name' +property of the U_BOOT_DEVICE() declaration has to match a driver declared +via U_BOOT_DRIVER(). This effectively means that a U_BOOT_DRIVER() with a +'name' corresponding to the devicetree 'compatible' string (after converting +it to a valid name for C) is needed, so a dedicated driver is required for +each 'compatible' string. + Where a node has multiple compatible strings, a #define is used to make them equivalent, e.g.: @@ -165,8 +179,8 @@ equivalent, e.g.: Converting of-platdata to a useful form --- -Of course it would be possible use the of-platdata directly in your driver -whenever configuration information is required. However this meands that the +Of course it would be possible to use the of-platdata directly in your driver +whenever configuration information is required. However this means that the driver will not be able to support device tree, since the of-platdata structure is not available when device tree is used. It would make no sense to use this structure if device tree were available, since the structure has @@ -282,11 +296,6 @@ prevents them being used inadvertently. All usage must be bracketed with The dt-platdata.c file contains the device declarations and is is built in spl/dt-platdata.c. -Some phandles (thsoe that are recognised as such) are converted into -points to platform data. This pointer can potentially be used to access the -referenced device (by searching for the pointer value). This feature is not -yet implemented, however. - The beginnings of a libfdt Python module are provided. So far this only implements a subset of the features. diff --git a/dts/Kconfig b/dts/Kconfig index 8917f42444..3e85914d11 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -265,8 +265,7 @@ config SPL_OF_PLATDATA This option works by generating C structure declarations for each compatible string, then adding platform data and U_BOOT_DEVICE - declarations for each node. See README.platdata for more - information. + declarations for each node. See of-plat.txt for more information. config TPL_OF_PLATDATA bool "Generate platform data for use in TPL" @@ -287,8 +286,7 @@ config TPL_OF_PLATDATA This option works by generating C structure declarations for each compatible string, then adding platform data and U_BOOT_DEVICE - declarations for each node. See README.platdata for more - information. + declarations for each node. See of-plat.txt for more information. endmenu -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] Make nyan-big working..
Another problem is, that the internal keyboard is not working on the current master. A change of the SPI deactive delay solves that. A workaround for the current master was to press [reload/refresh]+[power] button. With the second patch this is no longer needed. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] nyan-big: add padding to its file
Without this padding nyan-big ends at a blank screen on boot.
Details on how to get to this padding can be found in the README.chromium under
Notes.
Signed-off-by: Tristan Bastian
---
doc/chromium/nyan-big.its | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/chromium/nyan-big.its b/doc/chromium/nyan-big.its
index 37d4e10949..bd412915e9 100644
--- a/doc/chromium/nyan-big.its
+++ b/doc/chromium/nyan-big.its
@@ -6,7 +6,7 @@
images {
kernel {
- description = "U-Boot mainline";
+ description = "U-Boot mainline";
type = "kernel_noload";
arch = "arm";
os = "linux";
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] nyan-big: change spi delay
Internal keyboard of nyan-big is only working when cold booting by pressing
[reload/refresh]+[power] button.
With this patch keyboard is working by only pressing [power] button.
Signed-off-by: Tristan Bastian
---
arch/arm/dts/tegra124-nyan-big-u-boot.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/tegra124-nyan-big-u-boot.dtsi
b/arch/arm/dts/tegra124-nyan-big-u-boot.dtsi
index 3ff2f67c1a..ddfeba806c 100644
--- a/arch/arm/dts/tegra124-nyan-big-u-boot.dtsi
+++ b/arch/arm/dts/tegra124-nyan-big-u-boot.dtsi
@@ -15,7 +15,7 @@
};
spi@7000d400 {
- spi-deactivate-delay = <200>;
+ spi-deactivate-delay = <500>;
spi-max-frequency = <300>;
cros_ec: cros-ec@0 {
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] no DTB with nand SPL on sama5d3
Hello, Yes, I am trying to load the U-boot SPL What I posted previously was a custom board. I switched over to the sama5d3_xplained and all I get with sama5d3_xplained_nandflash_defconfig is ROMBOOT. AT91bootstrap works fine. I know there was the issue with the nand_header showing up for the SD card but that shouldn’t effect the nand. Some other patch I am missing to get a non-modified boot.bin nand working? The size of the 6th reset vector looks correct, with the assumption that it does not include the 208 bytes of nand_header? Dan > On Jan 16, 2019, at 6:02 AM, eugen.hris...@microchip.com wrote: > > > > > On 16.01.2019 03:13, Daniel Evans wrote: >> After flashing my boot.bin to nand I get the following output: >> >> RomBOOT >> Missing DTB >> ### ERROR ### Please RESET the board ### >> >> I found the error message in fdtdec.c, but not sure what I am missing. I >> have checked that my DTB is included in the boot.bin output. Any insight on >> what I am missing? > > Hello Daniel, > > Which defconfig are you using when building u-boot ? > > You are trying to load the U-boot SPL right ? > > It doesn't look like you even get to the point when you get to load the > u-boot proper, so maybe there are missing parts from your SPL, or the > size inside the 6th reset vector is not correctly calculated > > Did you try with our at91bootstrap proprietary second level bootloader > and get the same issue when booting the proper u-boot with it ? > > Hope this helps, > > Eugen > >> >> Dan >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> https://lists.denx.de/listinfo/u-boot >> ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] efi_loader: implement GetNextVariableName()
On 12/14/18 10:47 AM, AKASHI Takahiro wrote:
> The current GetNextVariableName() is a placeholder.
> With this patch, it works well as expected.
>
> Signed-off-by: AKASHI Takahiro
> ---
> lib/efi_loader/efi_variable.c | 116 +-
> 1 file changed, 115 insertions(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
> index 19d9cb865f25..dac2f49aa1cc 100644
> --- a/lib/efi_loader/efi_variable.c
> +++ b/lib/efi_loader/efi_variable.c
> @@ -8,6 +8,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> #define READ_ONLY BIT(31)
>
> @@ -241,14 +244,125 @@ efi_status_t EFIAPI efi_get_variable(u16
> *variable_name, efi_guid_t *vendor,
> return EFI_EXIT(EFI_SUCCESS);
> }
>
> +static char *efi_variables_list;
> +static char *efi_cur_variable;
> +
Please, provide a comment describing what this function is meant to do.
Describe every parameter
Clearly state set variable_name_size is in bytes (cf.
EmuGetNextVariableName() in EDK2)
This function duplicates some of the code in efi_get_variable. So,
please, use it in efi_get_variable too.
> +static efi_status_t parse_uboot_variable(char *variable,
> + efi_uintn_t *variable_name_size,
> + u16 *variable_name,
> + efi_guid_t *vendor,
> + u32 *attribute)
> +{
> + char *guid, *name, *end, c;
> + unsigned long name_size;
> + u16 *p;
> +
> + guid = strchr(variable, '_');
> + if (!guid)
> + return EFI_NOT_FOUND;
> + guid++;
> + name = strchr(guid, '_');
> + if (!name)
> + return EFI_NOT_FOUND;
> + name++;
> + end = strchr(name, '=');
> + if (!end)
> + return EFI_NOT_FOUND;
> +
> + /* FIXME: size is in byte or u16? */
It is in bytes. See comment above.
> + name_size = end - name;
> + if (*variable_name_size < (name_size + 1)) {
> + *variable_name_size = name_size + 1;
> + return EFI_BUFFER_TOO_SMALL;
> + }
> + end++; /* point to value */
> +
> + p = variable_name;
> + utf8_utf16_strncpy(, name, name_size);
> + variable_name[name_size] = 0;
> +
> + c = *(name - 1);
> + *(name - 1) = '\0'; /* guid need be null-terminated here */
> + uuid_str_to_bin(guid, (unsigned char *)vendor, UUID_STR_FORMAT_GUID);
> + *(name - 1) = c;
> +
> + parse_attr(end, attribute);
You have to update variable_name_size.
> +
> + return EFI_SUCCESS;
> +}
> +
> /*
> http://wiki.phoenix.com/wiki/index.php/EFI_RUNTIME_SERVICES#GetNextVariableName.28.29
> */
Please add a description of the function here like we have it in
efi_bootefi.c
> efi_status_t EFIAPI efi_get_next_variable_name(efi_uintn_t
> *variable_name_size,
> u16 *variable_name,
> efi_guid_t *vendor)
> {
> + char *native_name, *variable;
> + ssize_t name_len, list_len;
> + char regex[256];
> + char * const regexlist[] = {regex};
> + u32 attribute;
> + int i;
> + efi_status_t ret;
> +
> EFI_ENTRY("%p \"%ls\" %pUl", variable_name_size, variable_name, vendor);
>
> - return EFI_EXIT(EFI_DEVICE_ERROR);
> + if (!variable_name_size || !variable_name || !vendor)
> + EFI_EXIT(EFI_INVALID_PARAMETER);
> +
> + if (variable_name[0]) {
This code partially duplicates code in in efi_get_variable. Please,
carve out a common function.
> + /* check null-terminated string */
> + for (i = 0; i < *variable_name_size; i++)
> + if (!variable_name[i])
> + break;
> + if (i >= *variable_name_size)
> + return EFI_EXIT(EFI_INVALID_PARAMETER);
> +
> + /* search for the last-returned variable */
> + ret = efi_to_native(_name, variable_name, vendor);
> + if (ret)
> + return EFI_EXIT(ret);
> +
> + name_len = strlen(native_name);
> + for (variable = efi_variables_list; variable && *variable;) {
> + if (!strncmp(variable, native_name, name_len) &&
> + variable[name_len] == '=')
> + break;
> +
You miss to compare the GUID.
Consider the case that the GUID changes between two calls.
> + variable = strchr(variable, '\n');
> + if (variable)
> + variable++;
> + }
> +
> + free(native_name);
> + if (!(variable && *variable))
With less parentheses I can read the logic more easily:
if (!variable || !*variable)
But that is just a question of taste.
Please, consider the case that the variable is not on the list because
the variable has already
Re: [U-Boot] [RFC 01/17] common: Break USB_STORAGE dependency between SPL and u-boot proper
On Wed, Jan 16, 2019 at 02:03:20PM +, Abel Vesa wrote: > Some boards might need USB_STORAGE enabled in u-boot proper but not in > SPL. Make a separate config for SPL and keep the same depends on > conditions but for SPL. Also, all the boards that have DISTRO_DEFAULTS > use by default SPL_USB_STORAGE. > > Signed-off-by: Abel Vesa Please re-work this as I had described in the other thread, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-mips
Hi Tom, please pull updates for MIPS https://travis-ci.org/danielschwierzeck/u-boot/builds/480371326 The following changes since commit d3689267f92c5956e09cc7d1baa4700141662bff: Prepare v2019.01 (2019-01-14 17:02:36 -0500) are available in the Git repository at: git://git.denx.de/u-boot-mips.git tags/mips-pull-2019-11-16 for you to fetch changes up to 49f0b6bab919e6a9a509af841b43bbb49728dc45: mips: mt7688: gardena-smart-gateway: Enable green power LED on startup (2019-01-16 14:00:26 +0100) - MIPS: mscc: various enhancements for Luton and Ocelot platforms - MIPS: mscc: added support for Jaguar2 platform - MIPS: optimised SPL linker script - MIPS: bcm6368: fix restart flow issues - MIPS: fixed CONFIG_OF_EMBED warnings for all MIPS boards - MIPS: mt7688: small fixes and enhancements - mmc: compile-out write support if disabled Daniel Schwierzeck (7): MIPS: optimize and fix ELF sections MIPS: jz47xx: remove custom u-boot-spl.lds MIPS: boston: switch to CONFIG_OF_SEPARATE MIPS: malta: switch to CONFIG_OF_SEPARATE MIPS: pic32mzdask: switch to CONFIG_OF_SEPARATE MIPS: xilfpga: switch to CONFIG_OF_SEPARATE MIPS: bmips: switch to CONFIG_OF_SEPARATE Ezequiel Garcia (2): mmc: Use proper IS_ENABLED macro to check block support mmc: jz_mmc: Compile-out write support if disabled Horatiu Vultur (6): pinctrl: mscc: Add gpio and pinctrl for Jaguar2 SOC family MSCC: Add support for Jaguar2 SOC family MSCC: Add device tree for Jaguar2 board MSCC: Add device tree for Jaguar2-48 board MSCC: add device tree for Serval2 board MSCC: Add board support for Jaguar2 SOC family Lars Povlsen (13): mips: mscc: Add generic PHY MIIM utility functions mips: mscc: Add generic GPIO control utility function mips: luton: DT: Add pcb090 mips: mscc: luton+ocelot: Remove board config options, do probing mips: mscc_sgpio: Add the MSCC serial GPIO device (SIO) mips: mscc_sgpio: Add DT bindings documentation mips: luton: DT: Enable use of serial gpio mips: luton: Enable use of serial gpio for LED mips: ocelot: DT: Enable use of serial gpio mips: ocelot: Enable use of serial gpio for LED mips: spi: mscc: Add fast bitbang SPI driver mips: mscc: DT: Update luton device tree to use fast SPI driver mips: gpio: mscc: Obsoleted gpio-mscc-bitbang-spi.c Stefan Roese (2): mips: mt7688: gardena-smart-gateway: Update mtdparts/mtdids for Kernel 4.19 mips: mt7688: gardena-smart-gateway: Enable green power LED on startup Álvaro Fernández Rojas (1): net: bcm6368: fix restart flow issues MAINTAINERS| 5 + arch/mips/cpu/u-boot-spl.lds | 100 --- arch/mips/cpu/u-boot.lds | 104 --- arch/mips/dts/Makefile | 3 + arch/mips/dts/gardena-smart-gateway-mt7688.dts | 2 +- arch/mips/dts/jr2_pcb110.dts | 74 + arch/mips/dts/jr2_pcb111.dts | 74 + arch/mips/dts/luton_pcb090.dts | 57 arch/mips/dts/luton_pcb091.dts | 27 ++ arch/mips/dts/mscc,jr2.dtsi| 187 arch/mips/dts/mscc,luton.dtsi | 29 +- arch/mips/dts/mscc,ocelot.dtsi | 23 ++ arch/mips/dts/ocelot_pcb120.dts| 76 + arch/mips/dts/ocelot_pcb123.dts| 25 ++ arch/mips/dts/serval2_pcb112.dts | 60 arch/mips/mach-jz47xx/jz4780/u-boot-spl.lds| 50 arch/mips/mach-mscc/Kconfig| 45 ++- arch/mips/mach-mscc/Makefile | 5 +- arch/mips/mach-mscc/cpu.c | 7 + arch/mips/mach-mscc/dram.c | 2 +- arch/mips/mach-mscc/gpio.c | 33 +++ arch/mips/mach-mscc/include/mach/common.h | 65 + arch/mips/mach-mscc/include/mach/ddr.h | 38 ++- arch/mips/mach-mscc/include/mach/jr2/jr2.h | 24 ++ .../mach-mscc/include/mach/jr2/jr2_devcpu_gcb.h| 20 ++ .../include/mach/jr2/jr2_devcpu_gcb_miim_regs.h| 25 ++ .../mips/mach-mscc/include/mach/jr2/jr2_icpu_cfg.h | 321 .../include/mach/luton/luton_devcpu_gcb.h | 4 + .../mach/luton/luton_devcpu_gcb_miim_regs.h| 26 ++ .../include/mach/ocelot/ocelot_devcpu_gcb.h| 2 + .../mach/ocelot/ocelot_devcpu_gcb_miim_regs.h | 25 ++ arch/mips/mach-mscc/phy.c | 73 + arch/mips/mach-mscc/reset.c| 17 ++ board/mscc/common/Makefile | 4 + board/mscc/common/spi.c|
[U-Boot] [PATCH u-boot 2/2] cmd: mdio: Add new parameter to access MMD PHY registers
Two new parameters (rmmd and wmmd) are added to allow the `mdio` command
to access the content of the MMD PHY registers.
Signed-off-by: Carlo Caione
---
cmd/mdio.c | 33 +++--
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/cmd/mdio.c b/cmd/mdio.c
index 184868063a..010632b562 100644
--- a/cmd/mdio.c
+++ b/cmd/mdio.c
@@ -43,7 +43,7 @@ static int mdio_write_ranges(struct phy_device *phydev,
struct mii_dev *bus,
int addrlo,
int addrhi, int devadlo, int devadhi,
int reglo, int reghi, unsigned short data,
-int extended)
+int extended, int mmd)
{
int addr, devad, reg;
int err = 0;
@@ -51,7 +51,9 @@ static int mdio_write_ranges(struct phy_device *phydev,
struct mii_dev *bus,
for (addr = addrlo; addr <= addrhi; addr++) {
for (devad = devadlo; devad <= devadhi; devad++) {
for (reg = reglo; reg <= reghi; reg++) {
- if (!extended)
+ if (mmd)
+ err = phy_write_mmd(phydev, devad, reg,
data);
+ else if (!extended)
err = bus->write(bus, addr, devad,
reg, data);
else
@@ -71,7 +73,7 @@ err_out:
static int mdio_read_ranges(struct phy_device *phydev, struct mii_dev *bus,
int addrlo,
int addrhi, int devadlo, int devadhi,
- int reglo, int reghi, int extended)
+ int reglo, int reghi, int extended, int mmd)
{
int addr, devad, reg;
@@ -83,7 +85,9 @@ static int mdio_read_ranges(struct phy_device *phydev, struct
mii_dev *bus,
for (reg = reglo; reg <= reghi; reg++) {
int val;
- if (!extended)
+ if (mmd)
+ val = phy_read_mmd(phydev, devad, reg);
+ else if (!extended)
val = bus->read(bus, addr, devad, reg);
else
val = phydev->drv->readext(phydev, addr,
@@ -189,6 +193,7 @@ static int do_mdio(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
struct mii_dev *bus;
struct phy_device *phydev = NULL;
int extended = 0;
+ int mmd = 0;
if (argc < 2)
return CMD_RET_USAGE;
@@ -232,6 +237,18 @@ static int do_mdio(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return -1;
}
}
+ if (op[1] == 'm') {
+ phydev = mdio_phydev_for_ethname(argv[2]);
+
+ if (phydev) {
+ addrlo = phydev->addr;
+ addrhi = addrlo;
+ bus = phydev->bus;
+ mmd = 1;
+ } else {
+ return -1;
+ }
+ }
}
switch (op[0]) {
@@ -265,12 +282,12 @@ static int do_mdio(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
switch (op[0]) {
case 'w':
mdio_write_ranges(phydev, bus, addrlo, addrhi, devadlo, devadhi,
- reglo, reghi, data, extended);
+ reglo, reghi, data, extended, mmd);
break;
case 'r':
mdio_read_ranges(phydev, bus, addrlo, addrhi, devadlo, devadhi,
-reglo, reghi, extended);
+reglo, reghi, extended, mmd);
break;
}
@@ -303,6 +320,10 @@ U_BOOT_CMD(
"read PHY's extended register at .\n"
"mdio wx [.] - "
"write PHY's extended register at .\n"
+ "mdio rmmd [.] - "
+ "read PHY's extended register at .\n"
+ "mdio wmmd [.] - "
+ "write PHY's extended register at .\n"
" may be:\n"
" \n"
" \n"
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot 1/2] net: phy: Add support for accessing MMD PHY registers
Two new helper functions (phy_read_mmd() and phy_write_mmd()) are added
to allow access to the MMD PHY registers.
The MMD PHY registers can be accessed by two means:
1. Using two new MMD access function hooks in the PHY driver. These
functions can be implemented when the PHY driver does not support the
standard IEEE Compatible clause 45 access mechanism described in clause
22 or if the PHY uses its own non-standard access mechanism.
2. The standard clause 45 access extensions to the MMD registers through
the indirection registers (clause 22) in all the other cases.
Signed-off-by: Carlo Caione
---
drivers/net/phy/phy.c | 4 +++
include/phy.h | 62 +++
2 files changed, 66 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index cda4caa803..6769047407 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -549,6 +549,10 @@ int phy_register(struct phy_driver *drv)
drv->readext += gd->reloc_off;
if (drv->writeext)
drv->writeext += gd->reloc_off;
+ if (drv->read_mmd)
+ drv->read_mmd += gd->reloc_off;
+ if (drv->write_mmd)
+ drv->write_mmd += gd->reloc_off;
#endif
return 0;
}
diff --git a/include/phy.h b/include/phy.h
index b86fdfb2ce..0ce41661fa 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -101,6 +101,13 @@ struct phy_driver {
int (*readext)(struct phy_device *phydev, int addr, int devad, int reg);
int (*writeext)(struct phy_device *phydev, int addr, int devad, int reg,
u16 val);
+
+ /* Phy specific driver override for reading a MMD register */
+ int (*read_mmd)(struct phy_device *phydev, int devad, int reg);
+
+ /* Phy specific driver override for writing a MMD register */
+ int (*write_mmd)(struct phy_device *phydev, int devad, int reg, u16
val);
+
struct list_head list;
};
@@ -164,6 +171,61 @@ static inline int phy_write(struct phy_device *phydev, int
devad, int regnum,
return bus->write(bus, phydev->addr, devad, regnum, val);
}
+static inline void phy_mmd_indirect(struct phy_device *phydev, int devad,
+ int regnum)
+{
+ /* Write the desired MMD Devad */
+ phy_write(phydev, MDIO_DEVAD_NONE, MII_MMD_CTRL, devad);
+
+ /* Write the desired MMD register address */
+ phy_write(phydev, MDIO_DEVAD_NONE, MII_MMD_DATA, regnum);
+
+ /* Select the Function : DATA with no post increment */
+ phy_write(phydev, MDIO_DEVAD_NONE, MII_MMD_CTRL, (devad |
MII_MMD_CTRL_NOINCR));
+}
+
+static inline int phy_read_mmd(struct phy_device *phydev, int devad,
+ int regnum)
+{
+ int ret;
+
+ if (regnum > (u16)~0 || devad > 32)
+ return -EINVAL;
+
+ if (phydev->drv->read_mmd) {
+ ret = phydev->drv->read_mmd(phydev, devad, regnum);
+ } else {
+ phy_mmd_indirect(phydev, devad, regnum);
+
+ /* Read the content of the MMD's selected register */
+ ret = phy_read(phydev, MDIO_DEVAD_NONE, MII_MMD_DATA);
+ }
+
+ return ret;
+}
+
+static inline int phy_write_mmd(struct phy_device *phydev, int devad,
+ int regnum, u16 val)
+{
+ int ret;
+
+ if (regnum > (u16)~0 || devad > 32)
+ return -EINVAL;
+
+ if (phydev->drv->write_mmd) {
+ ret = phydev->drv->write_mmd(phydev, devad, regnum, val);
+ } else {
+ phy_mmd_indirect(phydev, devad, regnum);
+
+ /* Write the data into MMD's selected register */
+ phy_write(phydev, MDIO_DEVAD_NONE, MII_MMD_DATA, val);
+
+ ret = 0;
+ }
+
+ return ret;
+}
+
#ifdef CONFIG_PHYLIB_10G
extern struct phy_driver gen10g_driver;
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot 0/2] Add MMD PHY helpers
Introduce phy_(read|write)_mmd() generic 802.3 clause 45 register accessors for Clause 22 PHYs, using the indirect method. Allow this behaviour to be overriden by PHY drivers where necessary. Carlo Caione (2): net: phy: Add support for accessing MMD PHY registers cmd: mdio: Add new parameter to access MMD PHY registers cmd/mdio.c| 33 ++- drivers/net/phy/phy.c | 4 +++ include/phy.h | 62 +++ 3 files changed, 93 insertions(+), 6 deletions(-) -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] efi_selftest: fix variables test for GetNextVariableName()
On 12/14/18 10:47 AM, AKASHI Takahiro wrote: > There is a bug in efi variables test. > Fix it with some cosmetic improvements. > > Please note that efi variables test still fails at QueryVariableInfo() > and GetVariable(), but this is not due to a change in this patch. > ==8<== > Testing EFI API implementation > > Selected test: 'variables' > > Setting up 'variables' > Setting up 'variables' succeeded > > Executing 'variables' > .../u-boot/lib/efi_selftest/efi_selftest_variables.c(60): > TODO: QueryVariableInfo failed > .../u-boot/lib/efi_selftest/efi_selftest_variables.c(131): > TODO: GetVariable returned wrong length 7 > .../u-boot/lib/efi_selftest/efi_selftest_variables.c(133): > TODO: GetVariable returned wrong value > Executing 'variables' succeeded > > Boot services terminated > > Summary: 0 failures > ==>8== > > 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 v2 7/7] doc: ti-secure: Add ULO info for AM57xx/DRA7xx secure devices from TI
On 12/6/18 3:41 PM, Tom Rini wrote: > On Wed, Dec 05, 2018 at 11:51:36AM -0600, Andrew F. Davis wrote: > >> Booting from UART and USB on HS devices is now supported for this >> platform. Update documentation for the same. >> >> Signed-off-by: Andrew F. Davis > > Reviewed-by: Tom Rini > Ping? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] travis: Switch QEMU to 3.1.0 version
On Wed, Jan 16, 2019 at 03:18:44PM +0100, Michal Simek wrote: > Vexpress ca15_tc2 is failing with 3.1.0 because of QEMU issue. > When this patch is applied > https://patchwork.kernel.org/patch/10754401/ > Vexpress can be also turn to newer QEMU version. > > Signed-off-by: Michal Simek Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull from u-boot-i2c
On Tue, Jan 15, 2019 at 02:01:30PM +0100, Heiko Schocher wrote: > Hello Tom, > > please pull from u-boot-i2c.git master > > The following changes since commit d3689267f92c5956e09cc7d1baa4700141662bff: > > Prepare v2019.01 (2019-01-14 17:02:36 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-i2c.git master > > for you to fetch changes up to 1d7b6a5c4f879dd36ac07ad76ec31eb4fcd2b65b: > > i2c: Reflect correct dependency for !DM cadence driver (2019-01-15 09:06:46 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: Remove unused am335x_evm defconfigs
On Wed, Jan 16, 2019 at 02:38:04PM +0530, Vignesh R wrote: > These defconfigs don't seem be actively used any more, and have not been > moved to adapt DM or DT. Therefore delete them. > > Signed-off-by: Vignesh R Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-riscv/master
On Tue, Jan 15, 2019 at 03:16:39PM +0800, ub...@andestech.com wrote: > Hi Tom, > > Please pull some riscv updates: > 1. Improve cache implementation. > 2. Fix and improve standalone applications > > https://travis-ci.org/rickchen36/u-boot-riscv/builds/479684449 > > Thanks > > Rick > > > The following changes since commit d3689267f92c5956e09cc7d1baa4700141662bff: > > Prepare v2019.01 (2019-01-14 17:02:36 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-riscv.git > > for you to fetch changes up to 91882c472d8c0aef4db699d3f2de55bf43d4ae4b: > > riscv: qemu: define standalone load address (2019-01-15 09:36:31 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: Remove am43xx_evm_ethboot_defconfig
On Wed, Jan 16, 2019 at 02:54:36PM +0530, Vignesh R wrote: > am43xx_evm_ethboot_defconfig is not being actively used and has not been > moved to DM or DT. Also, ethboot cannot be tested on AM43xx EVM as such > due EVM limitations. Therefore delete it. > > Signed-off-by: Vignesh R Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] travis: Setup QEMU_VERSION as variable
On Wed, Jan 16, 2019 at 03:18:43PM +0100, Michal Simek wrote: > This change enables setting up specific Qemu version or sha1 for new > targets which are added after (current) v3.0.0 version. > This changes is preparation step for adding new Xilinx Versal Virt > platform which was merge after v3.0.0. > > Signed-off-by: Michal Simek > Reviewed-by: Bin Meng Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-dm
On Tue, Jan 15, 2019 at 08:57:23AM -0700, Simon Glass wrote: > Hi Tom, > > https://travis-ci.org/sglass68/u-boot/builds > > The following changes since commit d3689267f92c5956e09cc7d1baa4700141662bff: > > Prepare v2019.01 (2019-01-14 17:02:36 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git tags/dm-pull-15jan19 > > for you to fetch changes up to f51f6715a5013f37620c38f0430e21d4736e235a: > > lib: fdtdec: fdtdec_get_addr_size_fixed remove checks (2019-01-14 > 17:47:20 -0700) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] common: Kconfig: miscellaneous spelling fixes
On Fri, Jan 11, 2019 at 03:30:50PM +1300, Chris Packham wrote: > Signed-off-by: Chris Packham > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] kbuild: add .SECONDARY special target to scripts/Kbuild.include
On Fri, Jan 11, 2019 at 07:42:27PM +0900, Masahiro Yamada wrote:
> Based on the following Linux commits:
>
> - 54a702f70589 ("kbuild: mark $(targets) as .SECONDARY and remove
>.PRECIOUS markers")
>
> - 8e9b61b293d9 ("kbuild: move .SECONDARY special target to
>Kbuild.include")
>
> GNU Make automatically deletes intermediate files that are updated
> in a chain of pattern rules.
>
> Example 1) %.dtb.o <- %.dtb.S <- %.dtb <- %.dts
> Example 2) %.o <- %.c <- %.c_shipped
>
> A couple of makefiles mark such targets as .PRECIOUS to prevent Make
> from deleting them, but the correct way is to use .SECONDARY.
>
> .SECONDARY
> Prerequisites of this special target are treated as intermediate
> files but are never automatically deleted.
>
> .PRECIOUS
> When make is interrupted during execution, it may delete the target
> file it is updating if the file was modified since make started.
> If you mark the file as precious, make will never delete the file
> if interrupted.
>
> Both can avoid deletion of intermediate files, but the difference is
> the behavior when Make is interrupted; .SECONDARY deletes the target,
> but .PRECIOUS does not.
>
> The use of .PRECIOUS is relatively rare since we do not want to keep
> partially constructed (possibly corrupted) targets.
>
> .SECONDARY with no prerequisites causes all targets to be treated as
> secondary. This agrees the policy of Kbuild.
>
> scripts/Kbuild.include seems a suitable place to add it because it is
> included from almost all sub-makes.
>
> Signed-off-by: Masahiro Yamada
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Makefile: run CONFIG_BOARD_SIZE_LIMIT against .img
On Fri, Jan 11, 2019 at 08:56:02PM +0100, Simon Goldschmidt wrote: > With the current Makefile, CONFIG_BOARD_SIZE_LIMIT is used to check > the U-Boot binary without devicetree only. This produces wrong results > when OF_SEPARATE is used. > > To fix this, run the CONFIG_BOARD_SIZE_LIMIT check on all .img binaries > as well. > > Signed-off-by: Simon Goldschmidt > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] kbuild: add .DELETE_ON_ERROR special target
On Fri, Jan 11, 2019 at 07:42:26PM +0900, Masahiro Yamada wrote: > Linux commit 9c2af1c7377a8a6ef86e5cabf80978f3dbbb25c0 > > If Make gets a fatal signal while a shell is executing, it may delete > the target file that the recipe was supposed to update. This is needed > to make sure that it is remade from scratch when Make is next run; if > Make is interrupted after the recipe has begun to write the target file, > it results in an incomplete file whose time stamp is newer than that > of the prerequisites files. Make automatically deletes the incomplete > file on interrupt unless the target is marked .PRECIOUS. > > The situation is just the same as when the shell fails for some reasons. > Usually when a recipe line fails, if it has changed the target file at > all, the file is corrupted, or at least it is not completely updated. > Yet the file’s time stamp says that it is now up to date, so the next > time Make runs, it will not try to update that file. > > However, Make does not cater to delete the incomplete target file in > this case. We need to add .DELETE_ON_ERROR somewhere in the Makefile > to request it. > > scripts/Kbuild.include seems a suitable place to add it because it is > included from almost all sub-makes. > > Signed-off-by: Masahiro Yamada Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] serial: ns16550: fix debug uart putc called before init
On Wed, Jan 16, 2019 at 05:52:24PM +0100, Simon Goldschmidt wrote: > On Wed, Jan 16, 2019 at 3:44 AM Tom Rini wrote: > > > > On Wed, Jan 09, 2019 at 08:35:31PM +0100, Simon Goldschmidt wrote: > > > > > If _debug_uart_putc() is called before _debug_uart_init(), the > > > ns16550 debug uart driver hangs in a tight loop waiting for the > > > tx FIFO to get empty. > > > > > > As this can happen via a printf sneaking in before the port calls > > > debug_uart_init(), introduce a config option to ignore characters > > > before the debug uart is initialized. > > > > > > This is done by reading the baudrate divisor and aborting if is zero. > > > > > > The Kconfig option is required as reading the baudrate divisor does > > > not seem to work for all ns16500 compatibles (which is why the last > > > attempt on this has been reverted in 1a67969a99). > > > > > > Tested on socfpga_cyclone5_socrates. > > > > > > Signed-off-by: Simon Goldschmidt > > > Reviewed-by: Simon Glass > > > > Applied to u-boot/master, thanks! > > I don't see this or any of my other patches in u-boot/master (neither github > nor denx.de), is that expected? No, that was strange. While I swore I had pushed, apparently I had not. Fixed, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] serial: ns16550: fix debug uart putc called before init
On Wed, Jan 16, 2019 at 3:44 AM Tom Rini wrote: > > On Wed, Jan 09, 2019 at 08:35:31PM +0100, Simon Goldschmidt wrote: > > > If _debug_uart_putc() is called before _debug_uart_init(), the > > ns16550 debug uart driver hangs in a tight loop waiting for the > > tx FIFO to get empty. > > > > As this can happen via a printf sneaking in before the port calls > > debug_uart_init(), introduce a config option to ignore characters > > before the debug uart is initialized. > > > > This is done by reading the baudrate divisor and aborting if is zero. > > > > The Kconfig option is required as reading the baudrate divisor does > > not seem to work for all ns16500 compatibles (which is why the last > > attempt on this has been reverted in 1a67969a99). > > > > Tested on socfpga_cyclone5_socrates. > > > > Signed-off-by: Simon Goldschmidt > > Reviewed-by: Simon Glass > > Applied to u-boot/master, thanks! I don't see this or any of my other patches in u-boot/master (neither github nor denx.de), is that expected? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARC: Move ENV_SIZE and ENV_OFFSET to Kconfig
On Wed, Jan 16, 2019 at 07:38:04PM +0300, Alexey Brodkin wrote: > Join the party of some ARM boards and drop more > items from include/configs/xxx.h. > > Signed-off-by: Alexey Brodkin > Cc: Michal Simek > Cc: Simon Glass > Cc: Tom Rini Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] ARC: Move ENV_SIZE and ENV_OFFSET to Kconfig
Join the party of some ARM boards and drop more
items from include/configs/xxx.h.
Signed-off-by: Alexey Brodkin
Cc: Michal Simek
Cc: Simon Glass
Cc: Tom Rini
---
Changes in v2:
* Default ENV_OFFSET defined specially for ARC but not all
configs/emsdp_defconfig | 1 +
configs/iot_devkit_defconfig | 1 +
configs/tb100_defconfig | 1 +
env/Kconfig | 4 +++-
include/configs/axs10x.h | 1 -
include/configs/emsdp.h | 1 -
include/configs/hsdk.h | 2 --
include/configs/iot_devkit.h | 1 -
include/configs/nsim.h | 6 --
include/configs/tb100.h | 6 --
10 files changed, 6 insertions(+), 18 deletions(-)
diff --git a/configs/emsdp_defconfig b/configs/emsdp_defconfig
index 273334b05d..64281d0529 100644
--- a/configs/emsdp_defconfig
+++ b/configs/emsdp_defconfig
@@ -3,6 +3,7 @@ CONFIG_ISA_ARCV2=y
CONFIG_CPU_ARCEM6=y
CONFIG_TARGET_EMSDP=y
CONFIG_SYS_TEXT_BASE=0x
+CONFIG_ENV_SIZE=0x1000
CONFIG_SYS_CLK_FREQ=4000
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
CONFIG_VERSION_VARIABLE=y
diff --git a/configs/iot_devkit_defconfig b/configs/iot_devkit_defconfig
index 1b6dd9e55a..24bbe3fc5d 100644
--- a/configs/iot_devkit_defconfig
+++ b/configs/iot_devkit_defconfig
@@ -5,6 +5,7 @@ CONFIG_SYS_ICACHE_OFF=y
CONFIG_SYS_DCACHE_OFF=y
CONFIG_TARGET_IOT_DEVKIT=y
CONFIG_SYS_TEXT_BASE=0x
+CONFIG_ENV_SIZE=0x1000
CONFIG_SYS_CLK_FREQ=1600
CONFIG_LOCALVERSION="-iotdk-1.0"
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
diff --git a/configs/tb100_defconfig b/configs/tb100_defconfig
index f30053d4de..e3837d92e7 100644
--- a/configs/tb100_defconfig
+++ b/configs/tb100_defconfig
@@ -1,6 +1,7 @@
CONFIG_ARC=y
CONFIG_TARGET_TB100=y
CONFIG_SYS_TEXT_BASE=0x8400
+CONFIG_ENV_SIZE=0x800
CONFIG_SYS_CLK_FREQ=5
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTARGS=y
diff --git a/env/Kconfig b/env/Kconfig
index 9011109b47..c22cbbdadc 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -431,7 +431,7 @@ 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)
-if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL
+if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL ||
ARC
config ENV_OFFSET
hex "Environment Offset"
@@ -441,6 +441,7 @@ config ENV_OFFSET
default 0x88000 if ARCH_SUNXI
default 0xE if ARCH_ZYNQ
default 0x1E0 if ARCH_ZYNQMP
+ default 0 if ARC
help
Offset from the start of the device (or partition)
@@ -449,6 +450,7 @@ config ENV_SIZE
default 0x4 if ENV_IS_IN_SPI_FLASH && ARCH_ZYNQMP
default 0x2 if ARCH_SUNXI || ARCH_ZYNQ
default 0x8000 if ARCH_ROCKCHIP || ARCH_ZYNQMP || ARCH_VERSAL
+ default 0x4000 if ARC
help
Size of the environment storage area
diff --git a/include/configs/axs10x.h b/include/configs/axs10x.h
index 9452b06771..24afbc8fe5 100644
--- a/include/configs/axs10x.h
+++ b/include/configs/axs10x.h
@@ -62,7 +62,6 @@
/*
* Environment settings
*/
-#define CONFIG_ENV_SIZESZ_16K
#define CONFIG_EXTRA_ENV_SETTINGS \
"upgrade=if mmc rescan && " \
"fatload mmc 0:1 ${loadaddr} u-boot-update.img && " \
diff --git a/include/configs/emsdp.h b/include/configs/emsdp.h
index 9a205edc7c..44614138f8 100644
--- a/include/configs/emsdp.h
+++ b/include/configs/emsdp.h
@@ -24,7 +24,6 @@
/*
* Environment
*/
-#define CONFIG_ENV_SIZESZ_4K
#define CONFIG_BOOTFILE"app.bin"
#define CONFIG_LOADADDRCONFIG_SYS_LOAD_ADDR
diff --git a/include/configs/hsdk.h b/include/configs/hsdk.h
index 94c88b29f1..4755567a2d 100644
--- a/include/configs/hsdk.h
+++ b/include/configs/hsdk.h
@@ -57,8 +57,6 @@
/*
* Environment settings
*/
-#define CONFIG_ENV_SIZESZ_16K
-
#define CONFIG_EXTRA_ENV_SETTINGS \
"upgrade=if mmc rescan && " \
"fatload mmc 0:1 ${loadaddr} u-boot-update.scr && " \
diff --git a/include/configs/iot_devkit.h b/include/configs/iot_devkit.h
index 4ffe1141d9..4b110bb9d8 100644
--- a/include/configs/iot_devkit.h
+++ b/include/configs/iot_devkit.h
@@ -77,7 +77,6 @@
/*
* Environment
*/
-#define CONFIG_ENV_SIZESZ_4K
#define CONFIG_BOOTFILE"app.bin"
#define CONFIG_LOADADDRCONFIG_SYS_LOAD_ADDR
diff --git a/include/configs/nsim.h b/include/configs/nsim.h
index c3f34a91e4..61217bbe79 100644
--- a/include/configs/nsim.h
+++ b/include/configs/nsim.h
@@ -24,12 +24,6 @@
#define CONFIG_SYS_BOOTM_LEN SZ_32M
#define CONFIG_SYS_LOAD_ADDR 0x8200
-/*
- * Environment settings
- */
-#define CONFIG_ENV_SIZESZ_512
-#define CONFIG_ENV_OFFSET 0
-
/*
* Environment configuration
*/
diff --git a/include/configs/tb100.h
Re: [U-Boot] [PATCH] ARC: Move ENV_SIZE and ENV_OFFSET to Kconfig
Hi Tom, > -Original Message- > From: Tom Rini > Sent: Wednesday, January 16, 2019 7:25 PM > To: Alexey Brodkin > Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com; Michal Simek > ; Simon > Glass > Subject: Re: [PATCH] ARC: Move ENV_SIZE and ENV_OFFSET to Kconfig > > On Wed, Jan 16, 2019 at 04:22:22PM +, Alexey Brodkin wrote: > > Hi Tom, > > > > > -Original Message- > > > From: Tom Rini > > > Sent: Wednesday, January 16, 2019 7:19 PM > > > To: Alexey Brodkin > > > Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com; Michal Simek > > > ; > Simon > > > Glass > > > Subject: Re: [PATCH] ARC: Move ENV_SIZE and ENV_OFFSET to Kconfig > > > > > > On Wed, Jan 16, 2019 at 07:11:15PM +0300, Alexey Brodkin wrote: > > > > > > > Join the party of some ARM boards and drop more > > > > items from include/configs/xxx.h. > > > > > > > > Signed-off-by: Alexey Brodkin > > > > Cc: Michal Simek > > > > Cc: Simon Glass > > > > Cc: Tom Rini > > > > --- > > > > [snip] > > > > > > config ENV_OFFSET > > > > hex "Environment Offset" > > > > @@ -441,6 +441,7 @@ config ENV_OFFSET > > > > default 0x88000 if ARCH_SUNXI > > > > default 0xE if ARCH_ZYNQ > > > > default 0x1E0 if ARCH_ZYNQMP > > > > + default 0 > > > > > > Please make this "if ARC", thanks! > > > > Actually I don't like having here listed all the boards > > because with more boards/arches moving ENV settings to Kconfig > > we'll get here all of them listed at some point. > > Why default ENV_OFFSET [as well as] ENV_SIZE are not set in > > arch/soc/board top-level Kconfig? > > I believe the answer is that having config FOO prompt in one place and N > config FOO values results in lots of churn in the defconfig files when > they get re-synced. So yes, having N lines of default X if Y with the > prompt is what we want, at least until everything is converted and then > we can see if no, really, moving the defaults to some defined / > consistent locations doesn't result in so much churn. Ok that's fine by me. Sending a re-spin. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARC: Move ENV_SIZE and ENV_OFFSET to Kconfig
On Wed, Jan 16, 2019 at 04:22:22PM +, Alexey Brodkin wrote: > Hi Tom, > > > -Original Message- > > From: Tom Rini > > Sent: Wednesday, January 16, 2019 7:19 PM > > To: Alexey Brodkin > > Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com; Michal Simek > > ; Simon > > Glass > > Subject: Re: [PATCH] ARC: Move ENV_SIZE and ENV_OFFSET to Kconfig > > > > On Wed, Jan 16, 2019 at 07:11:15PM +0300, Alexey Brodkin wrote: > > > > > Join the party of some ARM boards and drop more > > > items from include/configs/xxx.h. > > > > > > Signed-off-by: Alexey Brodkin > > > Cc: Michal Simek > > > Cc: Simon Glass > > > Cc: Tom Rini > > > --- > > [snip] > > > > config ENV_OFFSET > > > hex "Environment Offset" > > > @@ -441,6 +441,7 @@ config ENV_OFFSET > > > default 0x88000 if ARCH_SUNXI > > > default 0xE if ARCH_ZYNQ > > > default 0x1E0 if ARCH_ZYNQMP > > > + default 0 > > > > Please make this "if ARC", thanks! > > Actually I don't like having here listed all the boards > because with more boards/arches moving ENV settings to Kconfig > we'll get here all of them listed at some point. > Why default ENV_OFFSET [as well as] ENV_SIZE are not set in > arch/soc/board top-level Kconfig? I believe the answer is that having config FOO prompt in one place and N config FOO values results in lots of churn in the defconfig files when they get re-synced. So yes, having N lines of default X if Y with the prompt is what we want, at least until everything is converted and then we can see if no, really, moving the defaults to some defined / consistent locations doesn't result in so much churn. -- 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] ARC: Move ENV_SIZE and ENV_OFFSET to Kconfig
Hi Tom, > -Original Message- > From: Tom Rini > Sent: Wednesday, January 16, 2019 7:19 PM > To: Alexey Brodkin > Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com; Michal Simek > ; Simon > Glass > Subject: Re: [PATCH] ARC: Move ENV_SIZE and ENV_OFFSET to Kconfig > > On Wed, Jan 16, 2019 at 07:11:15PM +0300, Alexey Brodkin wrote: > > > Join the party of some ARM boards and drop more > > items from include/configs/xxx.h. > > > > Signed-off-by: Alexey Brodkin > > Cc: Michal Simek > > Cc: Simon Glass > > Cc: Tom Rini > > --- [snip] > > config ENV_OFFSET > > hex "Environment Offset" > > @@ -441,6 +441,7 @@ config ENV_OFFSET > > default 0x88000 if ARCH_SUNXI > > default 0xE if ARCH_ZYNQ > > default 0x1E0 if ARCH_ZYNQMP > > + default 0 > > Please make this "if ARC", thanks! Actually I don't like having here listed all the boards because with more boards/arches moving ENV settings to Kconfig we'll get here all of them listed at some point. Why default ENV_OFFSET [as well as] ENV_SIZE are not set in arch/soc/board top-level Kconfig? -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARC: Move ENV_SIZE and ENV_OFFSET to Kconfig
On Wed, Jan 16, 2019 at 07:11:15PM +0300, Alexey Brodkin wrote: > Join the party of some ARM boards and drop more > items from include/configs/xxx.h. > > Signed-off-by: Alexey Brodkin > Cc: Michal Simek > Cc: Simon Glass > Cc: Tom Rini > --- > configs/emsdp_defconfig | 1 + > configs/iot_devkit_defconfig | 1 + > configs/tb100_defconfig | 1 + > env/Kconfig | 4 +++- > include/configs/axs10x.h | 1 - > include/configs/emsdp.h | 1 - > include/configs/hsdk.h | 2 -- > include/configs/iot_devkit.h | 1 - > include/configs/nsim.h | 6 -- > include/configs/tb100.h | 6 -- > 10 files changed, 6 insertions(+), 18 deletions(-) > > diff --git a/configs/emsdp_defconfig b/configs/emsdp_defconfig > index 273334b05d..64281d0529 100644 > --- a/configs/emsdp_defconfig > +++ b/configs/emsdp_defconfig > @@ -3,6 +3,7 @@ CONFIG_ISA_ARCV2=y > CONFIG_CPU_ARCEM6=y > CONFIG_TARGET_EMSDP=y > CONFIG_SYS_TEXT_BASE=0x > +CONFIG_ENV_SIZE=0x1000 > CONFIG_SYS_CLK_FREQ=4000 > # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set > CONFIG_VERSION_VARIABLE=y > diff --git a/configs/iot_devkit_defconfig b/configs/iot_devkit_defconfig > index 1b6dd9e55a..24bbe3fc5d 100644 > --- a/configs/iot_devkit_defconfig > +++ b/configs/iot_devkit_defconfig > @@ -5,6 +5,7 @@ CONFIG_SYS_ICACHE_OFF=y > CONFIG_SYS_DCACHE_OFF=y > CONFIG_TARGET_IOT_DEVKIT=y > CONFIG_SYS_TEXT_BASE=0x > +CONFIG_ENV_SIZE=0x1000 > CONFIG_SYS_CLK_FREQ=1600 > CONFIG_LOCALVERSION="-iotdk-1.0" > # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set > diff --git a/configs/tb100_defconfig b/configs/tb100_defconfig > index f30053d4de..e3837d92e7 100644 > --- a/configs/tb100_defconfig > +++ b/configs/tb100_defconfig > @@ -1,6 +1,7 @@ > CONFIG_ARC=y > CONFIG_TARGET_TB100=y > CONFIG_SYS_TEXT_BASE=0x8400 > +CONFIG_ENV_SIZE=0x800 > CONFIG_SYS_CLK_FREQ=5 > CONFIG_BOOTDELAY=3 > CONFIG_USE_BOOTARGS=y > diff --git a/env/Kconfig b/env/Kconfig > index 9011109b47..8beaa7249a 100644 > --- a/env/Kconfig > +++ b/env/Kconfig > @@ -431,7 +431,7 @@ 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) > > -if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL > +if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL || > ARC > > config ENV_OFFSET > hex "Environment Offset" > @@ -441,6 +441,7 @@ config ENV_OFFSET > default 0x88000 if ARCH_SUNXI > default 0xE if ARCH_ZYNQ > default 0x1E0 if ARCH_ZYNQMP > + default 0 Please make this "if ARC", thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARC: Move ENV_SIZE and ENV_OFFSET to Kconfig
Join the party of some ARM boards and drop more
items from include/configs/xxx.h.
Signed-off-by: Alexey Brodkin
Cc: Michal Simek
Cc: Simon Glass
Cc: Tom Rini
---
configs/emsdp_defconfig | 1 +
configs/iot_devkit_defconfig | 1 +
configs/tb100_defconfig | 1 +
env/Kconfig | 4 +++-
include/configs/axs10x.h | 1 -
include/configs/emsdp.h | 1 -
include/configs/hsdk.h | 2 --
include/configs/iot_devkit.h | 1 -
include/configs/nsim.h | 6 --
include/configs/tb100.h | 6 --
10 files changed, 6 insertions(+), 18 deletions(-)
diff --git a/configs/emsdp_defconfig b/configs/emsdp_defconfig
index 273334b05d..64281d0529 100644
--- a/configs/emsdp_defconfig
+++ b/configs/emsdp_defconfig
@@ -3,6 +3,7 @@ CONFIG_ISA_ARCV2=y
CONFIG_CPU_ARCEM6=y
CONFIG_TARGET_EMSDP=y
CONFIG_SYS_TEXT_BASE=0x
+CONFIG_ENV_SIZE=0x1000
CONFIG_SYS_CLK_FREQ=4000
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
CONFIG_VERSION_VARIABLE=y
diff --git a/configs/iot_devkit_defconfig b/configs/iot_devkit_defconfig
index 1b6dd9e55a..24bbe3fc5d 100644
--- a/configs/iot_devkit_defconfig
+++ b/configs/iot_devkit_defconfig
@@ -5,6 +5,7 @@ CONFIG_SYS_ICACHE_OFF=y
CONFIG_SYS_DCACHE_OFF=y
CONFIG_TARGET_IOT_DEVKIT=y
CONFIG_SYS_TEXT_BASE=0x
+CONFIG_ENV_SIZE=0x1000
CONFIG_SYS_CLK_FREQ=1600
CONFIG_LOCALVERSION="-iotdk-1.0"
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
diff --git a/configs/tb100_defconfig b/configs/tb100_defconfig
index f30053d4de..e3837d92e7 100644
--- a/configs/tb100_defconfig
+++ b/configs/tb100_defconfig
@@ -1,6 +1,7 @@
CONFIG_ARC=y
CONFIG_TARGET_TB100=y
CONFIG_SYS_TEXT_BASE=0x8400
+CONFIG_ENV_SIZE=0x800
CONFIG_SYS_CLK_FREQ=5
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTARGS=y
diff --git a/env/Kconfig b/env/Kconfig
index 9011109b47..8beaa7249a 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -431,7 +431,7 @@ 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)
-if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL
+if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL ||
ARC
config ENV_OFFSET
hex "Environment Offset"
@@ -441,6 +441,7 @@ config ENV_OFFSET
default 0x88000 if ARCH_SUNXI
default 0xE if ARCH_ZYNQ
default 0x1E0 if ARCH_ZYNQMP
+ default 0
help
Offset from the start of the device (or partition)
@@ -449,6 +450,7 @@ config ENV_SIZE
default 0x4 if ENV_IS_IN_SPI_FLASH && ARCH_ZYNQMP
default 0x2 if ARCH_SUNXI || ARCH_ZYNQ
default 0x8000 if ARCH_ROCKCHIP || ARCH_ZYNQMP || ARCH_VERSAL
+ default 0x4000 if ARC
help
Size of the environment storage area
diff --git a/include/configs/axs10x.h b/include/configs/axs10x.h
index 9452b06771..24afbc8fe5 100644
--- a/include/configs/axs10x.h
+++ b/include/configs/axs10x.h
@@ -62,7 +62,6 @@
/*
* Environment settings
*/
-#define CONFIG_ENV_SIZESZ_16K
#define CONFIG_EXTRA_ENV_SETTINGS \
"upgrade=if mmc rescan && " \
"fatload mmc 0:1 ${loadaddr} u-boot-update.img && " \
diff --git a/include/configs/emsdp.h b/include/configs/emsdp.h
index 9a205edc7c..44614138f8 100644
--- a/include/configs/emsdp.h
+++ b/include/configs/emsdp.h
@@ -24,7 +24,6 @@
/*
* Environment
*/
-#define CONFIG_ENV_SIZESZ_4K
#define CONFIG_BOOTFILE"app.bin"
#define CONFIG_LOADADDRCONFIG_SYS_LOAD_ADDR
diff --git a/include/configs/hsdk.h b/include/configs/hsdk.h
index 94c88b29f1..4755567a2d 100644
--- a/include/configs/hsdk.h
+++ b/include/configs/hsdk.h
@@ -57,8 +57,6 @@
/*
* Environment settings
*/
-#define CONFIG_ENV_SIZESZ_16K
-
#define CONFIG_EXTRA_ENV_SETTINGS \
"upgrade=if mmc rescan && " \
"fatload mmc 0:1 ${loadaddr} u-boot-update.scr && " \
diff --git a/include/configs/iot_devkit.h b/include/configs/iot_devkit.h
index 4ffe1141d9..4b110bb9d8 100644
--- a/include/configs/iot_devkit.h
+++ b/include/configs/iot_devkit.h
@@ -77,7 +77,6 @@
/*
* Environment
*/
-#define CONFIG_ENV_SIZESZ_4K
#define CONFIG_BOOTFILE"app.bin"
#define CONFIG_LOADADDRCONFIG_SYS_LOAD_ADDR
diff --git a/include/configs/nsim.h b/include/configs/nsim.h
index c3f34a91e4..61217bbe79 100644
--- a/include/configs/nsim.h
+++ b/include/configs/nsim.h
@@ -24,12 +24,6 @@
#define CONFIG_SYS_BOOTM_LEN SZ_32M
#define CONFIG_SYS_LOAD_ADDR 0x8200
-/*
- * Environment settings
- */
-#define CONFIG_ENV_SIZESZ_512
-#define CONFIG_ENV_OFFSET 0
-
/*
* Environment configuration
*/
diff --git a/include/configs/tb100.h b/include/configs/tb100.h
index 96e5b6315c..a761c37335 100644
---
[U-Boot] [PATCH 2/2] armv8: ls2088ardb: Update MAINTAINERS
From: York Sun Signed-off-by: York Sun CC: Rajesh Bhagat --- board/freescale/ls2080ardb/MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/board/freescale/ls2080ardb/MAINTAINERS b/board/freescale/ls2080ardb/MAINTAINERS index 1f6014deed..113b7ab3fd 100644 --- a/board/freescale/ls2080ardb/MAINTAINERS +++ b/board/freescale/ls2080ardb/MAINTAINERS @@ -13,6 +13,7 @@ M:Rajesh Bhagat S: Maintained F: configs/ls2088ardb_qspi_defconfig F: configs/ls2088ardb_tfa_defconfig +F: configs/ls2088ardb_tfa_SECURE_BOOT_defconfig LS2081ARDB BOARD M: Priyanka Jain -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] armv8: ls1088ardb: Update MAINTAINERS
From: York Sun Signed-off-by: York Sun CC: Rajesh Bhagat --- board/freescale/ls1088a/MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/board/freescale/ls1088a/MAINTAINERS b/board/freescale/ls1088a/MAINTAINERS index bca9969637..98ecb88e3b 100644 --- a/board/freescale/ls1088a/MAINTAINERS +++ b/board/freescale/ls1088a/MAINTAINERS @@ -8,6 +8,7 @@ F: include/configs/ls1088ardb.h F: configs/ls1088ardb_qspi_defconfig F: configs/ls1088ardb_sdcard_qspi_defconfig F: configs/ls1088ardb_tfa_defconfig +F: configs/ls1088ardb_tfa_SECURE_BOOT_defconfig LS1088AQDS BOARD M: Prabhakar Kushwaha -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] MIPS: mscc: ocelot: add switch reset support
Am 16.01.19 um 15:37 schrieb Gregory CLEMENT:
> Hi Daniel,
>
> On mer., janv. 16 2019, Daniel Schwierzeck
> wrote:
>
>> Am 16.01.19 um 14:07 schrieb Gregory CLEMENT:
>>> On some ocelots platform a workaround is needed in order to be able to
>>> reset the switch without resetting the DDR.
>>>
>>> Signed-off-by: Gregory CLEMENT
>>> ---
>>> board/mscc/ocelot/ocelot.c | 26 ++
>>> 1 file changed, 26 insertions(+)
>>>
>>> diff --git a/board/mscc/ocelot/ocelot.c b/board/mscc/ocelot/ocelot.c
>>> index 0f7a532158..77ebe8ae26 100644
>>> --- a/board/mscc/ocelot/ocelot.c
>>> +++ b/board/mscc/ocelot/ocelot.c
>>> @@ -10,6 +10,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> DECLARE_GLOBAL_DATA_PTR;
>>>
>>> @@ -18,6 +19,31 @@ enum {
>>> BOARD_TYPE_PCB123,
>>> };
>>>
>>> +void mscc_switch_reset(bool enter)
>>> +{
>>> + u32 reg, count = 0;
>>> +
>>> + /* Nasty workaround to avoid GPIO19 (DDR!) being reset */
>>> + mscc_gpio_set_alternate(19, 2);
>>> +
>>> + debug("applying SwC reset\n");
>>> +
>>> + writel(ICPU_RESET_CORE_RST_PROTECT, BASE_CFG + ICPU_RESET);
>>> + writel(PERF_SOFT_RST_SOFT_CHIP_RST, BASE_DEVCPU_GCB + PERF_SOFT_RST);
>>> +
>>> + if (wait_for_bit_le32(BASE_DEVCPU_GCB + PERF_SOFT_RST,
>>> + PERF_SOFT_RST_SOFT_CHIP_RST, false, 5000, false))
>>> + pr_err("Tiemout while waiting for switch reset\n");
>>> +
>>> + /*
>>> +* Reset GPIO19 mode back as regular GPIO, output, high (DDR
>>> +* not reset) (Order is important)
>>> +*/
>>> + setbits_le32(BASE_DEVCPU_GCB + PERF_GPIO_OE, BIT(19));
>>> + writel(BIT(19), BASE_DEVCPU_GCB + PERF_GPIO_OUT_SET);
>>> + mscc_gpio_set_alternate(19, 0);
>>
>> have you thought about or maybe planned a reset controller driver?
>
> Actually, here it is not a reset driver, it is just the workaround part
> of the stop() function in the network driver. It is not about resetting
> the whole platform, for this feature a driver already has been submited.
>
understood, there is nothing wrong with the patch. I only imagine that
such logic would better fit in a reset controller driver which only
exports reset domains (I didn't mean the sysreset driver). But I see
that the Linux driver also manually toggles the reset bits but at least
the register accesses are wrapped via syscon/regmap. Maybe it makes
sense to add a syscon driver for U-Boot too in the future?
--
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] MSCC: Remove reset.c
Hi Daniel,
The 01/16/2019 15:35, Daniel Schwierzeck wrote:
>
>
> Am 15.01.19 um 17:33 schrieb Horatiu Vultur:
> > Remove reset.c because it is not used anymore. It is superseed by
> > sysreset driver.
> >
> > Signed-off-by: Horatiu Vultur
> > ---
> > arch/mips/mach-mscc/Makefile | 2 +-
> > arch/mips/mach-mscc/include/mach/ddr.h | 18 -
> > arch/mips/mach-mscc/reset.c| 47
> > --
> > 3 files changed, 18 insertions(+), 49 deletions(-)
> > delete mode 100644 arch/mips/mach-mscc/reset.c
> >
> > diff --git a/arch/mips/mach-mscc/Makefile b/arch/mips/mach-mscc/Makefile
> > index f5b6968..349e889 100644
> > --- a/arch/mips/mach-mscc/Makefile
> > +++ b/arch/mips/mach-mscc/Makefile
> > @@ -2,6 +2,6 @@
> >
> > CFLAGS_cpu.o += -finline-limit=64000
> >
> > -obj-y += cpu.o dram.o reset.o phy.o lowlevel_init.o
> > +obj-y += cpu.o dram.o phy.o lowlevel_init.o
> > obj-$(CONFIG_SOC_LUTON) += lowlevel_init_luton.o gpio.o
> > obj-$(CONFIG_SOC_OCELOT) += gpio.o
> > diff --git a/arch/mips/mach-mscc/include/mach/ddr.h
> > b/arch/mips/mach-mscc/include/mach/ddr.h
> > index 7552acb..a2d20db 100644
> > --- a/arch/mips/mach-mscc/include/mach/ddr.h
> > +++ b/arch/mips/mach-mscc/include/mach/ddr.h
> > @@ -415,6 +415,22 @@ static inline void hal_vcoreiii_ddr_reset_release(void)
> > sleep_100ns(1);
> > }
> >
> > +static void ocelot_restart(void)
> > +{
> > + register u32 resetbits = PERF_SOFT_RST_SOFT_CHIP_RST;
> > + (void)readl(BASE_DEVCPU_GCB + PERF_SOFT_RST);
> > +
> > + /* Make sure VCore is NOT protected from reset */
> > + clrbits_le32(BASE_CFG + ICPU_RESET, ICPU_RESET_CORE_RST_PROTECT);
> > +
> > + /* Change to SPI bitbang for SPI reset workaround... */
> > + writel(ICPU_SW_MODE_SW_SPI_CS_OE(1) | ICPU_SW_MODE_SW_SPI_CS(1) |
> > + ICPU_SW_MODE_SW_PIN_CTRL_MODE, BASE_CFG + ICPU_SW_MODE);
> > +
> > + /* Do the global reset */
> > + writel(resetbits, BASE_DEVCPU_GCB + PERF_SOFT_RST);
> > +}
> > +
> > /*
> > * DDR memory sanity checking failed, tally and do hard reset
> > *
> > @@ -443,7 +459,7 @@ static inline void hal_vcoreiii_ddr_failed(void)
> > * MIPS CPU (and the cache), and the CPU will start executing
> > * from the reset vector.
> > */
> > - reset = KSEG0ADDR(_machine_restart);
> > + reset = KSEG0ADDR(ocelot_restart);
>
> ah I didn't thought about that when suggesting a sysreset driver.Then
> it's maybe not a good idea at all. Or you export a function declaration
> like mscc_cpu_reset(void) and implement it for each MSCC SoC. You could
> call this still in hal_vcoreiii_ddr_failed() context. The sysreset
> driver then simply wraps this function. But then it's not really worth
> the overhead. Sorry for the troubles ;)
No problem, thanks for all the feedback :)
One thingy is that after the patch[1] is accepted, I would like to send
a new patch series for a new SoC. And this new SoC has a different reset
mechanism which means that I need to put another #ifdef inside
_machine_restart.
For me it is perfectly fine not to accept this patch series and after I
send the new patch series for new SoC to have another look at the
function _machine_restart.
[1] https://lists.denx.de/pipermail/u-boot/2019-January/354812.html
>
> > icache_lock((void *)reset, 128);
> > asm volatile ("jr %0"::"r" (reset));
> >
> > diff --git a/arch/mips/mach-mscc/reset.c b/arch/mips/mach-mscc/reset.c
> > deleted file mode 100644
> > index e0e610a..000
> > --- a/arch/mips/mach-mscc/reset.c
> > +++ /dev/null
> > @@ -1,47 +0,0 @@
> > -// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > -/*
> > - * Copyright (c) 2018 Microsemi Corporation
> > - */
> > -
> > -#include
> > -
> > -#include
> > -#include
> > -
> > -#include
> > -
> > -void _machine_restart(void)
> > -{
> > -#if defined(CONFIG_SOC_JR2)
> > - register u32 reg = readl(BASE_CFG + ICPU_GENERAL_CTRL);
> > - /* Set owner */
> > - reg &= ~ICPU_GENERAL_CTRL_IF_SI_OWNER_M;
> > - reg |= ICPU_GENERAL_CTRL_IF_SI_OWNER(1);
> > - /* Set boot mode */
> > - reg |= ICPU_GENERAL_CTRL_BOOT_MODE_ENA;
> > - writel(reg, BASE_CFG + ICPU_GENERAL_CTRL);
> > - /* Read back in order to make BOOT mode setting active */
> > - reg = readl(BASE_CFG + ICPU_GENERAL_CTRL);
> > - /* Reset CPU only - still executing _here_. but from cache */
> > - writel(readl(BASE_CFG + ICPU_RESET) |
> > - ICPU_RESET_CORE_RST_CPU_ONLY |
> > - ICPU_RESET_CORE_RST_FORCE,
> > - BASE_CFG + ICPU_RESET);
> > -#else
> > - register u32 resetbits = PERF_SOFT_RST_SOFT_CHIP_RST;
> > - (void)readl(BASE_DEVCPU_GCB + PERF_SOFT_RST);
> > -
> > - /* Make sure VCore is NOT protected from reset */
> > - clrbits_le32(BASE_CFG + ICPU_RESET, ICPU_RESET_CORE_RST_PROTECT);
> > -
> > - /* Change to SPI bitbang for SPI reset workaround... */
> > - writel(ICPU_SW_MODE_SW_SPI_CS_OE(1) | ICPU_SW_MODE_SW_SPI_CS(1) |
> > -
Re: [U-Boot] [RFC 08/17] dts: imx: Add imx6q-sabresd dts and imx6qdl-sabresd dtsi files
On Wed, Jan 16, 2019 at 12:18 PM Abel Vesa wrote: > Oups, my bad. Actually the files should've been named imx6sabreauto.dtb (same > for sabresd). > Without the 'q'. I tested on 6d and booted fine, so what I'm saying here is: > this is meant for all the 6sabreauto. Do you mean mx6d (dual) or mx6dl (dual-lite)? I suppose you tested it on mx6d, which is the same SoC as imx6q, only difference being the number of cores. It is not possible to have a single dtb that covers all three variants (q/dl/qp). We still need imx6q-sabresd.dtb, imx6dl-sabresd.dtb and imx6qp-sabresd.dtb ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 08/17] dts: imx: Add imx6q-sabresd dts and imx6qdl-sabresd dtsi files
Hi Abel, On Wed, Jan 16, 2019 at 12:11 PM Abel Vesa wrote: > > Add necessary dts and dtsi files in order to enable DM in both > SPL and u-boot proper for mx6sabresd. > > Signed-off-by: Abel Vesa > --- > arch/arm/dts/Makefile |3 +- > arch/arm/dts/imx6q-sabresd.dts| 92 > arch/arm/dts/imx6qdl-sabresd.dtsi | 1065 > + > 3 files changed, 1159 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/dts/imx6q-sabresd.dts > create mode 100644 arch/arm/dts/imx6qdl-sabresd.dtsi > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index dad5436..1614a19 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -439,7 +439,8 @@ dtb-$(CONFIG_MX6QDL) += \ > imx6q-icore-mipi.dtb \ > imx6q-icore-rqs.dtb \ > imx6q-logicpd.dtb \ > - imx6q-sabreauto.dtb > + imx6q-sabreauto.dtb \ > + imx6q-sabresd.dtb Currently we support imx6q/imx6dl/imx6qp sabresd with the same U-Boot image. It seems that now you only support the imx6q variant, but we should keep supporting all the variants. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 08/17] dts: imx: Add imx6q-sabresd dts and imx6qdl-sabresd dtsi files
On 19-01-16 12:14:34, Fabio Estevam wrote: > Hi Abel, > > On Wed, Jan 16, 2019 at 12:11 PM Abel Vesa wrote: > > > > Add necessary dts and dtsi files in order to enable DM in both > > SPL and u-boot proper for mx6sabresd. > > > > Signed-off-by: Abel Vesa > > --- > > arch/arm/dts/Makefile |3 +- > > arch/arm/dts/imx6q-sabresd.dts| 92 > > arch/arm/dts/imx6qdl-sabresd.dtsi | 1065 > > + > > 3 files changed, 1159 insertions(+), 1 deletion(-) > > create mode 100644 arch/arm/dts/imx6q-sabresd.dts > > create mode 100644 arch/arm/dts/imx6qdl-sabresd.dtsi > > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > > index dad5436..1614a19 100644 > > --- a/arch/arm/dts/Makefile > > +++ b/arch/arm/dts/Makefile > > @@ -439,7 +439,8 @@ dtb-$(CONFIG_MX6QDL) += \ > > imx6q-icore-mipi.dtb \ > > imx6q-icore-rqs.dtb \ > > imx6q-logicpd.dtb \ > > - imx6q-sabreauto.dtb > > + imx6q-sabreauto.dtb \ > > + imx6q-sabresd.dtb > > Currently we support imx6q/imx6dl/imx6qp sabresd with the same U-Boot image. > > It seems that now you only support the imx6q variant, but we should > keep supporting all the variants. Oups, my bad. Actually the files should've been named imx6sabreauto.dtb (same for sabresd). Without the 'q'. I tested on 6d and booted fine, so what I'm saying here is: this is meant for all the 6sabreauto. Will fix the names in the next version. I'll just wait a little longer for more comments and resend. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
