Re: [PATCH 1/4] tools: mkeficapsule: Add support for parsing capsule params from config file
Hi Sughosh, On Fri, Dec 29, 2023 at 6:53 AM Sughosh Ganu wrote: > > hi Simon, > > On Wed, 27 Dec 2023 at 23:19, Simon Glass wrote: > > > > Hi Sughosh, > > > > On Mon, Dec 4, 2023 at 7:15 AM Sughosh Ganu wrote: > > > > > > hi Simon, > > > > > > On Sat, 2 Dec 2023 at 00:02, Simon Glass wrote: > > > > > > > > Hi Sughosh, > > > > > > > > On Thu, 30 Nov 2023 at 23:39, Sughosh Ganu > > > > wrote: > > > > > > > > > > hi Simon, > > > > > > > > > > On Thu, 30 Nov 2023 at 08:16, Simon Glass wrote: > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > On Wed, 22 Nov 2023 at 00:40, Sughosh Ganu > > > > > > wrote: > > > > > > > > > > > > > > hi Ilias, > > > > > > > > > > > > > > On Wed, 22 Nov 2023 at 13:06, Ilias Apalodimas > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > On Wed, 22 Nov 2023 at 07:23, Sughosh Ganu > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > > > > > > > On Wed, 22 Nov 2023 at 03:42, Simon Glass > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > > > > > > > On Tue, 21 Nov 2023 at 00:02, Sughosh Ganu > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Add support for specifying the parameters needed for > > > > > > > > > > > capsule > > > > > > > > > > > generation through a config file, instead of passing them > > > > > > > > > > > through > > > > > > > > > > > command-line. Parameters for more than a single capsule > > > > > > > > > > > file can be > > > > > > > > > > > specified, resulting in generation of multiple capsules > > > > > > > > > > > through a > > > > > > > > > > > single invocation of the command. > > > > > > > > > > > > > > > > > > > > > > The config file can then be passed to the mkeficapsule > > > > > > > > > > > tool in such > > > > > > > > > > > manner > > > > > > > > > > > > > > > > > > > > > > $ ./tools/mkeficapsule -f > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > > > > > --- > > > > > > > > > > > tools/Kconfig | 15 ++ > > > > > > > > > > > tools/Makefile | 1 + > > > > > > > > > > > tools/eficapsule.h | 114 > > > > > > > > > > > tools/mkeficapsule.c | 87 + > > > > > > > > > > > tools/mkeficapsule_parse.c | 352 > > > > > > > > > > > + > > > > > > > > > > > 5 files changed, 538 insertions(+), 31 deletions(-) > > > > > > > > > > > create mode 100644 tools/mkeficapsule_parse.c > > > > > > > > > > > > > > > > > > > > This patch keeps coming back :-) > > > > > > > > > > > > > > > > > > > > Can we not add multiple capsules in the binman description? > > > > > > > > > > Why do we > > > > > > > > > > need a new file format? How can binman decode images > > > > > > > > > > produced in this > > > > > > > > > > way? > > > > > > > > > > > > > > > > > > So as Tom mentions, this brings parity with respect to the > > > > > > > > > other > > > > > > > > > capsule generation tool in EDKII that generates capsules. > > > > > > > > > IIRC, this > > > > > > > > > is something which even Xilix was interested in, and Michal > > > > > > > > > had kind > > > > > > > > > of gone through these patches earlier. Lastly, it would be > > > > > > > > > good to > > > > > > > > > have support in U-Boot's mkeficapsule tool for generating a > > > > > > > > > single > > > > > > > > > capsule file with multiple payloads, and having support for > > > > > > > > > this > > > > > > > > > functionality helps in that goal. > > > > > > > > > > > > > > > > > > Also, you might have noticed that, since your objection to > > > > > > > > > the last > > > > > > > > > series, I have removed putting this in binman. So now, this > > > > > > > > > aspect of > > > > > > > > > the capsule generation would only be supported through the > > > > > > > > > command-line invocation of the tool. > > > > > > > > > > > > > > > > I think that overall the approach is sane. mkeficapsule is > > > > > > > > currently > > > > > > > > supported and compiled for distros, so the multiple payload > > > > > > > > support is > > > > > > > > useful. If we want to add support to binman, instead of > > > > > > > > rewriting this > > > > > > > > in python, we could just call that tool for parsing and creating > > > > > > > > capsules > > > > > > > > > > > > > > Given the amount of time these patches have been under review(also > > > > > > > number of iterations), I would request that this series be > > > > > > > reviewed > > > > > > > and merged first. I think there is general consensus that there is > > > > > > > value to have this functionality in the mkeficapsule tool. If it > > > > > > > is > > > > > > > deemed fit to support this through binman as well, that task can > > > > > > > be > > > > > > > taken up separately. Thanks. > > > > > > > > > > > > The point you are missing is that it is the entire
Re: [PATCH v4 2/9] acpi: carve out qfw_acpi.c
On Tue, Dec 19, 2023 at 04:04:01PM +0100, Heinrich Schuchardt wrote:
> Move the code related to copying tables from QEMU to a separate code
> module.
>
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Tom Rini
> Reviewed-by: Simon Glass
> ---
> v4:
> no change
> v3:
> no change
> v2:
> add missing blank line
> ---
> drivers/misc/Makefile | 1 +
> drivers/misc/qfw.c | 240 -
> drivers/misc/qfw_acpi.c | 256
> 3 files changed, 257 insertions(+), 240 deletions(-)
> create mode 100644 drivers/misc/qfw_acpi.c
Reviewed-by: Ilias Apalodimas
>
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index b67b82358a..cda701d38e 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_$(SPL_)PWRSEQ) += pwrseq-uclass.o
> obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
> ifdef CONFIG_QFW
> obj-y += qfw.o
> +obj-$(CONFIG_QFW_ACPI) += qfw_acpi.o
> obj-$(CONFIG_QFW_PIO) += qfw_pio.o
> obj-$(CONFIG_QFW_MMIO) += qfw_mmio.o
> obj-$(CONFIG_SANDBOX) += qfw_sandbox.o
> diff --git a/drivers/misc/qfw.c b/drivers/misc/qfw.c
> index 307334faf4..db98619fdf 100644
> --- a/drivers/misc/qfw.c
> +++ b/drivers/misc/qfw.c
> @@ -21,246 +21,6 @@
> #include
> #include
>
> -#ifdef QFW_ACPI
> -/*
> - * This function allocates memory for ACPI tables
> - *
> - * @entry : BIOS linker command entry which tells where to allocate memory
> - * (either high memory or low memory)
> - * @addr : The address that should be used for low memory allcation. If the
> - * memory allocation request is 'ZONE_HIGH' then this parameter will
> - * be ignored.
> - * @return: 0 on success, or negative value on failure
> - */
> -static int bios_linker_allocate(struct udevice *dev,
> - struct bios_linker_entry *entry, ulong *addr)
> -{
> - uint32_t size, align;
> - struct fw_file *file;
> - unsigned long aligned_addr;
> -
> - align = le32_to_cpu(entry->alloc.align);
> - /* align must be power of 2 */
> - if (align & (align - 1)) {
> - printf("error: wrong alignment %u\n", align);
> - return -EINVAL;
> - }
> -
> - file = qfw_find_file(dev, entry->alloc.file);
> - if (!file) {
> - printf("error: can't find file %s\n", entry->alloc.file);
> - return -ENOENT;
> - }
> -
> - size = be32_to_cpu(file->cfg.size);
> -
> - /*
> - * ZONE_HIGH means we need to allocate from high memory, since
> - * malloc space is already at the end of RAM, so we directly use it.
> - * If allocation zone is ZONE_FSEG, then we use the 'addr' passed
> - * in which is low memory
> - */
> - if (entry->alloc.zone == BIOS_LINKER_LOADER_ALLOC_ZONE_HIGH) {
> - aligned_addr = (unsigned long)memalign(align, size);
> - if (!aligned_addr) {
> - printf("error: allocating resource\n");
> - return -ENOMEM;
> - }
> - if (aligned_addr < gd->arch.table_start_high)
> - gd->arch.table_start_high = aligned_addr;
> - if (aligned_addr + size > gd->arch.table_end_high)
> - gd->arch.table_end_high = aligned_addr + size;
> -
> - } else if (entry->alloc.zone == BIOS_LINKER_LOADER_ALLOC_ZONE_FSEG) {
> - aligned_addr = ALIGN(*addr, align);
> - } else {
> - printf("error: invalid allocation zone\n");
> - return -EINVAL;
> - }
> -
> - debug("bios_linker_allocate: allocate file %s, size %u, zone %d, align
> %u, addr 0x%lx\n",
> - file->cfg.name, size, entry->alloc.zone, align, aligned_addr);
> -
> - qfw_read_entry(dev, be16_to_cpu(file->cfg.select), size,
> -(void *)aligned_addr);
> - file->addr = aligned_addr;
> -
> - /* adjust address for low memory allocation */
> - if (entry->alloc.zone == BIOS_LINKER_LOADER_ALLOC_ZONE_FSEG)
> - *addr = (aligned_addr + size);
> -
> - return 0;
> -}
> -
> -/*
> - * This function patches ACPI tables previously loaded
> - * by bios_linker_allocate()
> - *
> - * @entry : BIOS linker command entry which tells how to patch
> - * ACPI tables
> - * @return: 0 on success, or negative value on failure
> - */
> -static int bios_linker_add_pointer(struct udevice *dev,
> -struct bios_linker_entry *entry)
> -{
> - struct fw_file *dest, *src;
> - uint32_t offset = le32_to_cpu(entry->pointer.offset);
> - uint64_t pointer = 0;
> -
> - dest = qfw_find_file(dev, entry->pointer.dest_file);
> - if (!dest || !dest->addr)
> - return -ENOENT;
> - src = qfw_find_file(dev, entry->pointer.src_file);
> - if (!src || !src->addr)
> - return -ENOENT;
> -
> - debug("bios_linker_add_pointer: dest->addr 0x%lx, src->addr 0x%lx,
>
Re: [PATCH v4 5/9] acpi: enable writing ACPI tables on QEMU
On Tue, Dec 19, 2023 at 04:04:04PM +0100, Heinrich Schuchardt wrote:
> Invoke write_acpi_tables() via EVT_LAST_STAGE_INIT on QEMU except on X86.
> X86 calls write_acpi_tables() in write_tables().
>
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Simon Glass
> ---
> v4:
> no change
> v3:
> no change
> v2:
> new patch
> ---
> drivers/misc/qfw_acpi.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/misc/qfw_acpi.c b/drivers/misc/qfw_acpi.c
> index 6e14b2a504..7ffed1e8c0 100644
> --- a/drivers/misc/qfw_acpi.c
> +++ b/drivers/misc/qfw_acpi.c
> @@ -9,9 +9,11 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -254,3 +256,26 @@ ulong acpi_get_rsdp_addr(void)
> file = qfw_find_file(dev, "etc/acpi/rsdp");
> return file->addr;
> }
> +
> +#ifndef CONFIG_X86
> +static int evt_write_acpi_tables(void)
> +{
> + ulong addr, end;
> + void *ptr;
> +
> + /* Reserve 64K for ACPI tables, aligned to a 4K boundary */
> + ptr = memalign(SZ_4K, SZ_64K);
> + if (!ptr)
> + return -ENOMEM;
> + addr = map_to_sysmem(ptr);
> +
> + /* Generate ACPI tables */
> + end = write_acpi_tables(addr);
> + gd->arch.table_start = addr;
> + gd->arch.table_end = addr;
is this a typo and should be
gd->arch.table_end = end; ?
> +
> + return 0;
> +}
> +
> +EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, evt_write_acpi_tables);
> +#endif
> --
> 2.40.1
>
Thanks
/Ilias
Re: New TPM commands.
Hi Niek,
On Thu, Dec 21, 2023 at 02:12:49AM +, niek.nooij...@omron.com wrote:
> Hi Ilias
>
> I implemented the feedback and checked the htmldocs build target. no error
> there.
> I also applied the patch to the latest github version (was using an older
> one, but no compatibility issues) and used git format-patch instead of
> git-diff. The checkpatch script now shows no errors.
> There's no real reson to "want" this to be merged, but as our company
> benefits greatly from projects like u-boot, I figured that the least we could
> do was contribute back to the project. We use the TPM's non-volatile memory
> to lock away keys and other secrets and I don't think we're the only one
> needing this.
>
> anyhow here's the new revision. if I can help with more things I would gladly
> hear from you.
This doesn't apply cleanly on -master or -next trees.
Can you rebase it on top of either or them and resend it?
When you do, please send a new email with the topic set like this:
'tpm: NV memory accesses v2'
Thanks
/Ilias
>
> ===BEGIN PATCH=
> From afd377e2aba6df46bc991c0f250bf67d4ad036e0 Mon Sep 17 00:00:00 2001
> From: Niek Nooijens
> Date: Thu, 21 Dec 2023 10:56:14 +0900
> Subject: [PATCH] add tpm nv_commands
>
> Needed to read and write to the TPM's NV memory, in which you can store
> keys and other secret information, which can be locked behind PCR
> policies.
>
> Signed-off-by: Niek Nooijens
> ---
> cmd/tpm-v2.c | 152 +++
> include/tpm-v2.h | 15 +
> lib/tpm-v2.c | 67 -
> 3 files changed, 219 insertions(+), 15 deletions(-)
>
> diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
> index 7e479b9dfe..0d1e9e8e5c 100644
> --- a/cmd/tpm-v2.c
> +++ b/cmd/tpm-v2.c
> @@ -356,6 +356,136 @@ static int do_tpm_pcr_setauthvalue(struct cmd_tbl
> *cmdtp, int flag,
> key, key_sz));
> }
>
> +static int do_tpm_nv_define(struct cmd_tbl *cmdtp, int flag,
> + int argc, char *const argv[])
> +{
> + struct udevice *dev;
> + struct tpm_chip_priv *priv;
> + u32 nv_addr, nv_size, nv_attributes, rc;
> + void *policy_addr = NULL;
> + size_t policy_size = 0;
> + int ret;
> +
> + nv_attributes = 0;
> +
> + if ((argc < 3 && argc > 6) || argc == 4)
> + return CMD_RET_USAGE;
> +
> + ret = get_tpm();
> + if (ret)
> + return ret;
> +
> + priv = dev_get_uclass_priv(dev);
> + if (!priv)
> + return -EINVAL;
> +
> + nv_addr = simple_strtoul(argv[1], NULL, 0);
> +
> + nv_size = simple_strtoul(argv[2], NULL, 0);
> +
> + if (argc > 3)
> + nv_attributes = simple_strtoul(argv[3], NULL, 0);
> + else
> + nv_attributes = TPMA_NV_PLATFORMCREATE | TPMA_NV_OWNERWRITE |
> TPMA_NV_OWNERREAD | TPMA_NV_PPWRITE | TPMA_NV_PPREAD;
> +
> + if (argc > 4) {
> + policy_addr = map_sysmem(simple_strtoul(argv[4], NULL, 0), 0);
> + if ((nv_attributes & (TPMA_NV_POLICYREAD | TPMA_NV_POLICYWRITE))
> == 0) {
> + printf("ERROR: policy provided, but TPMA_NV_POLICYREAD or
> TPMA_NV_POLICYWRITE are NOT set!\n");
> + return CMD_RET_FAILURE;
> + }
> + policy_size = simple_strtoul(argv[5], NULL, 0);
> + }
> +
> + rc = tpm2_nv_define_space(dev, nv_addr, nv_size, nv_attributes,
> policy_addr, policy_size);
> +
> + if (rc)
> + printf("ERROR: nv_define #%u returns: 0x%x\n", nv_addr, rc);
> +
> + if (policy_addr)
> + unmap_sysmem(policy_addr);
> +
> + return report_return_code(rc);
> +}
> +
> +static int do_tpm_nv_undefine(struct cmd_tbl *cmdtp, int flag,
> + int argc, char *const argv[])
> +{
> + struct udevice *dev;
> + u32 nv_addr, ret, rc;
> +
> + ret = get_tpm();
> + if (ret)
> + return ret;
> +
> + if (argc != 2)
> + return CMD_RET_USAGE;
> +
> + nv_addr = simple_strtoul(argv[1], NULL, 0);
> + rc = tpm2_nv_undefine_space(dev, nv_addr);
> +
> + return report_return_code(rc);
> +}
> +
> +static int do_tpm_nv_read_value(struct cmd_tbl *cmdtp, int flag,
> + int argc, char *const argv[])
> +{
> + struct udevice *dev;
> + u32 nv_addr, nv_size, rc;
> + int ret;
> + void *out_data;
> +
> + ret = get_tpm();
> + if (ret)
> + return ret;
> +
> + if (argc != 4)
> + return CMD_RET_USAGE;
> +
> + nv_addr = simple_strtoul(argv[1], NULL, 0);
> +
> + nv_size = simple_strtoul(argv[2], NULL, 0);
> +
> + out_data = map_sysmem(simple_strtoul(argv[3], NULL, 0), 0);
> +
> + rc = tpm2_nv_read_value(dev, nv_addr, out_data, nv_size);
> +
> + if (rc)
> + printf("ERROR: nv_read #%u returns: #%u\n", nv_addr, rc);
> +
> + unmap_sysmem(out_data);
> + return report_return_code(rc);
> +}
> +
> +static int
Re: [PATCH 1/4] tools: mkeficapsule: Add support for parsing capsule params from config file
hi Simon, On Wed, 27 Dec 2023 at 23:19, Simon Glass wrote: > > Hi Sughosh, > > On Mon, Dec 4, 2023 at 7:15 AM Sughosh Ganu wrote: > > > > hi Simon, > > > > On Sat, 2 Dec 2023 at 00:02, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Thu, 30 Nov 2023 at 23:39, Sughosh Ganu > > > wrote: > > > > > > > > hi Simon, > > > > > > > > On Thu, 30 Nov 2023 at 08:16, Simon Glass wrote: > > > > > > > > > > Hi Sughosh, > > > > > > > > > > On Wed, 22 Nov 2023 at 00:40, Sughosh Ganu > > > > > wrote: > > > > > > > > > > > > hi Ilias, > > > > > > > > > > > > On Wed, 22 Nov 2023 at 13:06, Ilias Apalodimas > > > > > > wrote: > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > On Wed, 22 Nov 2023 at 07:23, Sughosh Ganu > > > > > > > wrote: > > > > > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > > > > > On Wed, 22 Nov 2023 at 03:42, Simon Glass > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > > > > > On Tue, 21 Nov 2023 at 00:02, Sughosh Ganu > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Add support for specifying the parameters needed for capsule > > > > > > > > > > generation through a config file, instead of passing them > > > > > > > > > > through > > > > > > > > > > command-line. Parameters for more than a single capsule > > > > > > > > > > file can be > > > > > > > > > > specified, resulting in generation of multiple capsules > > > > > > > > > > through a > > > > > > > > > > single invocation of the command. > > > > > > > > > > > > > > > > > > > > The config file can then be passed to the mkeficapsule tool > > > > > > > > > > in such > > > > > > > > > > manner > > > > > > > > > > > > > > > > > > > > $ ./tools/mkeficapsule -f > > > > > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > > > > --- > > > > > > > > > > tools/Kconfig | 15 ++ > > > > > > > > > > tools/Makefile | 1 + > > > > > > > > > > tools/eficapsule.h | 114 > > > > > > > > > > tools/mkeficapsule.c | 87 + > > > > > > > > > > tools/mkeficapsule_parse.c | 352 > > > > > > > > > > + > > > > > > > > > > 5 files changed, 538 insertions(+), 31 deletions(-) > > > > > > > > > > create mode 100644 tools/mkeficapsule_parse.c > > > > > > > > > > > > > > > > > > This patch keeps coming back :-) > > > > > > > > > > > > > > > > > > Can we not add multiple capsules in the binman description? > > > > > > > > > Why do we > > > > > > > > > need a new file format? How can binman decode images produced > > > > > > > > > in this > > > > > > > > > way? > > > > > > > > > > > > > > > > So as Tom mentions, this brings parity with respect to the other > > > > > > > > capsule generation tool in EDKII that generates capsules. IIRC, > > > > > > > > this > > > > > > > > is something which even Xilix was interested in, and Michal had > > > > > > > > kind > > > > > > > > of gone through these patches earlier. Lastly, it would be good > > > > > > > > to > > > > > > > > have support in U-Boot's mkeficapsule tool for generating a > > > > > > > > single > > > > > > > > capsule file with multiple payloads, and having support for this > > > > > > > > functionality helps in that goal. > > > > > > > > > > > > > > > > Also, you might have noticed that, since your objection to the > > > > > > > > last > > > > > > > > series, I have removed putting this in binman. So now, this > > > > > > > > aspect of > > > > > > > > the capsule generation would only be supported through the > > > > > > > > command-line invocation of the tool. > > > > > > > > > > > > > > I think that overall the approach is sane. mkeficapsule is > > > > > > > currently > > > > > > > supported and compiled for distros, so the multiple payload > > > > > > > support is > > > > > > > useful. If we want to add support to binman, instead of rewriting > > > > > > > this > > > > > > > in python, we could just call that tool for parsing and creating > > > > > > > capsules > > > > > > > > > > > > Given the amount of time these patches have been under review(also > > > > > > number of iterations), I would request that this series be reviewed > > > > > > and merged first. I think there is general consensus that there is > > > > > > value to have this functionality in the mkeficapsule tool. If it is > > > > > > deemed fit to support this through binman as well, that task can be > > > > > > taken up separately. Thanks. > > > > > > > > > > The point you are missing is that it is the entire goal of 'skirting > > > > > around' binman which is suspect. > > > > > > > > > > If there is a need to generate an output file from the build, we > > > > > should support it in binman. If people start creating configuration > > > > > files all over the place, then they are not using binman, right? > > > > > > > > > > I understand that there are pre-existing vendor-specific config files, > > > > > etc.
Re: [PATCH v6 5/8] binman: j721s2: Add firewall configurations
Hi Simon, On 09:50-20231226, Simon Glass wrote: > Hi Manorit, > > On Wed, Dec 6, 2023 at 9:51 AM Manorit Chawdhry wrote: > > > > The following commits adds the configuration of firewalls required to > > protect ATF and OP-TEE memory region from non-secure reads and > > writes using master and slave firewalls present in our K3 SOCs. > > > > Signed-off-by: Manorit Chawdhry > > --- > > arch/arm/dts/k3-j721s2-binman.dtsi | 217 > > + > > 1 file changed, 217 insertions(+) > > > > Just a minor point, but could you please reserve the 'binman' tag for > patches in tools/binman ? Sure, would do the needful! Thanks and regards, Manorit > > Thanks, > Simon
Re: Proposal: U-Boot memory management
Hi Simon, On Fri, 29 Dec 2023 at 07:36, Simon Glass wrote: > > Hi Ilias, > > On Fri, Dec 22, 2023 at 12:02 PM Ilias Apalodimas > wrote: > > > > Hi Simon > > > > I'll respond to the rest more thoroughly but I since I caught this early, > > > > [...] > > > > > > > > 5. Avoid calling efi_allocate_pages() and efi_allocate_pool() outside > > > boot-time services. This solves the problem 6. If memory is needed by > > > an app, allocate it with malloc() and see 3. There are only two > > > efi_allocate_pages() (smbios and efi_runtime). There are more calls of > > > efi_allocate_pool(), but most of these seem easy to fix up. For > > > example, efi_init_event_log() allocates a buffer, but this can be > > > allocated in normal malloc() space or in a bloblist. > > > > The TCG event log is only valid in the EFI world and is described by > > the EFI spec extensions [0]. I prefer it to remain as is > > How does that relate to [1] ? We use that today. The tl;dr is that TF-A measures the early stages, but doesn't have drivers to extend TPM PCRs. Instead, it creates an EventLog which hands over to U-Boot. The TPM subsystem searches for that and if it finds one && PCR0 == 0 replays the EventLog in hardware and copies it over to EFI memory. That being said, I'd much prefer using a bloblist for that EventLog (which also contains information on replaying), over a DT entry that's only described in TF-A docs. But that's a future improvement. > > > > > > > > > 6. Don't worry too much about whether EFI will be used for booting. > > > The cost is likely not that great: use bootstage to measure it as is > > > done for driver model. Try to minmise the cost of its tables, > > > particularly for execution time, but otherwise just rely on the > > > ability to disable EFI_LOADER. > > > > > > – > > > > > > Regards, > > > Simon > > > > [0] > > https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf > > Thanks > > /Ilias > > [1] > https://trustedfirmware-a.readthedocs.io/en/latest/components/measured_boot/event_log.html Cheers /Ilias
Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
Hi Masahiro, On Thu, Dec 14, 2023 at 7:34 AM Masahiro Yamada wrote: > > On Thu, Dec 14, 2023 at 3:12 PM Masahiro Yamada wrote: > > > > On Thu, Dec 14, 2023 at 1:03 PM Chen-Yu Tsai wrote: > > > > > > On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven > > > wrote: > > > > > > > > Hi Laurent, > > > > > > > > On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart > > > > wrote: > > > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote: > > > > > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart > > > > > > wrote: > > > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote: > > > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart > > > > > > > > wrote: > > > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote: > > > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a > > > > > > > > > > single file > > > > > > > > > > containing the built kernel and associated devicetree files. > > > > > > > > > > Compression defaults to gzip which gives a good balance of > > > > > > > > > > size and > > > > > > > > > > performance. > > > > > > > > > > > > > > > > > > > > The files compress from about 86MB to 24MB using this > > > > > > > > > > approach. > > > > > > > > > > > > > > > > > > > > The FIT can be used by bootloaders which support it, such > > > > > > > > > > as U-Boot > > > > > > > > > > and Linuxboot. It permits automatic selection of the correct > > > > > > > > > > devicetree, matching the compatible string of the running > > > > > > > > > > board with > > > > > > > > > > the closest compatible string in the FIT. There is no need > > > > > > > > > > for > > > > > > > > > > filenames or other workarounds. > > > > > > > > > > > > > > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use > > > > > > > > > > FIT_COMPRESSION to select a different algorithm. > > > > > > > > > > > > > > > > > > > > The FIT can be examined using 'dumpimage -l'. > > > > > > > > > > > > > > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). > > > > > > > > > > It also > > > > > > > > > > requires compression utilities for the algorithm being > > > > > > > > > > used. Supported > > > > > > > > > > compression options are the same as the Image.xxx files. > > > > > > > > > > For now there > > > > > > > > > > is no way to change the compression other than by editing > > > > > > > > > > the rule for > > > > > > > > > > $(obj)/image.fit > > > > > > > > > > > > > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made > > > > > > > > > > to support > > > > > > > > > > this here, since it must be built separately from the Linux > > > > > > > > > > build. > > > > > > > > > > > > > > > > > > FIT images are very useful, so I think this is a very welcome > > > > > > > > > addition > > > > > > > > > to the kernel build system. It can get tricky though: given > > > > > > > > > the > > > > > > > > > versatile nature of FIT images, there can't be any > > > > > > > > > one-size-fits-them-all solution to build them, and striking > > > > > > > > > the right > > > > > > > > > balance between what makes sense for the kernel and the > > > > > > > > > features that > > > > > > > > > users may request will probably lead to bikeshedding. As we > > > > > > > > > all love > > > > > > > > > bikeshedding, I thought I would start selfishly, with a > > > > > > > > > personal use > > > > > > > > > case :-) This isn't a yak-shaving request though, I don't see > > > > > > > > > any reason > > > > > > > > > to delay merging this series. > > > > > > > > > > > > > > > > > > Have you envisioned building FIT images with a subset of > > > > > > > > > DTBs, or adding > > > > > > > > > DTBOs ? Both would be fairly trivial extensions to this > > > > > > > > > script by > > > > > > > > > extending the supported command line arguments. It would > > > > > > > > > perhaps be more > > > > > > > > > difficult to integrate in the kernel build system though. > > > > > > > > > This leads me > > > > > > > > > to a second question: would you consider merging extensions > > > > > > > > > to this > > > > > > > > > script if they are not used by the kernel build system, but > > > > > > > > > meant for > > > > > > > > > users who manually invoke the script ? More generally, is the > > > > > > > > > script > > > > > > > > > > > > > > > > We'd also be interested in some customization, though in a > > > > > > > > different way. > > > > > > > > We imagine having a rule file that says X compatible string > > > > > > > > should map > > > > > > > > to A base DTB, plus B and C DTBO for the configuration section. > > > > > > > > The base > > > > > > > > DTB would carry all common elements of some device, while the > > > > > > > > DTBOs > > > > > > > > carry all the possible second source components, like different > > > > > > > > display > > > > > > > > panels or MIPI cameras for instance. This could drastically > > > > > > > > reduce
Re: [PATCH v4 08/12] bloblist: Handle alignment with a void entry
On Thu, 28 Dec 2023 at 18:04, Raymond Mao wrote:
>
> Hi Ilias,
>
> On Thu, 28 Dec 2023 at 06:32, Ilias Apalodimas
> wrote:
>>
>> Hi Raymond,
>>
>> On Wed, 27 Dec 2023 at 23:08, Raymond Mao wrote:
>> >
>> > From: Simon Glass
>> >
>> > Rather than setting the alignment using the header size, add an entirely
>> > new entry to cover the gap left by the alignment.
>> >
>> > Signed-off-by: Simon Glass
>> > Co-developed-by: Raymond Mao
>> > Signed-off-by: Raymond Mao
>> > Reviewed-by: Simon Glass
>> > ---
>> > common/bloblist.c | 23 +++
>> > 1 file changed, 19 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/common/bloblist.c b/common/bloblist.c
>> > index 705d9c6ae9..73dbbc01c0 100644
>> > --- a/common/bloblist.c
>> > +++ b/common/bloblist.c
>> > @@ -142,7 +142,7 @@ static int bloblist_addrec(uint tag, int size, int
>> > align_log2,
>> > {
>> > struct bloblist_hdr *hdr = gd->bloblist;
>> > struct bloblist_rec *rec;
>> > - int data_start, new_alloced;
>> > + int data_start, aligned_start, new_alloced;
>> >
>> > if (!align_log2)
>> > align_log2 = BLOBLIST_ALIGN_LOG2;
>> > @@ -151,10 +151,25 @@ static int bloblist_addrec(uint tag, int size, int
>> > align_log2,
>> > data_start = map_to_sysmem(hdr) + hdr->alloced + sizeof(*rec);
>> >
>> > /* Align the address and then calculate the offset from ->alloced
>> > */
>> > - data_start = ALIGN(data_start, 1U << align_log2) -
>> > map_to_sysmem(hdr);
>> > + aligned_start = ALIGN(data_start, 1U << align_log2) - data_start;
>> > +
>> > + /* If we need to create a dummy record, create it */
>> > + if (aligned_start) {
>> > + int void_size = aligned_start - sizeof(*rec);
>> > + struct bloblist_rec *vrec;
>> > + int ret;
>> > +
>> > + ret = bloblist_addrec(BLOBLISTT_VOID, void_size, 0, );
>>
>> I just noticed the 'BLOBLISTT'. Is that on purpose? or a typo?
>>
>> > + if (ret)
>> > + return log_msg_ret("void", ret);
>> > +
>> > + /* start the record after that */
>> > + data_start = map_to_sysmem(hdr) + hdr->alloced +
>> > sizeof(*vrec);
>> > + }
>> >
>> > /* Calculate the new allocated total */
>> > - new_alloced = data_start + ALIGN(size, 1U << align_log2);
>> > + new_alloced = data_start - map_to_sysmem(hdr) +
>> > + ALIGN(size, 1U << align_log2);
>>
Writing this as
new_alloced = hdr->alloced + sizeof(*rec) + ALIGN(size, 1U << align_log2);
is much more readable
>> So, wouldn't it make more sense to add the dummy record and align the
>> whole thing *after* we've added the entry?
>> Doing it like this might leave the last entry on an unaligned boundary, no?
>>
> The spec just cares about the TE *data* starts at an aligned address but not
> the TE header.
> Not sure if I fully understand your question but each TE *data* will start at
> an aligned address
> after calling `bloblist_addrec()`.
> And each TE is allowed to have its own alignment value, so we have to do the
> padding when
> a TE is being added but cannot predict the alignment value for the next TE -
> that means we
> cannot do the padding after each TE is added.
>
Ah thanks, this makes sense
> [...]
>
> Thanks and regards,
> Raymond
With the change above
Reviewed-by: Ilias Apalodimas
Re: [PATCH v4 7/7] smbios: Require the caller to align the SMBIOS table
On Thu, 28 Dec 2023 at 23:00, Heinrich Schuchardt wrote: > > > > Am 28. Dezember 2023 20:48:04 MEZ schrieb Simon Glass : > >Hi Heinrich, > > > >On Thu, Dec 28, 2023 at 5:36 PM Heinrich Schuchardt > >wrote: > >> > >> > >> > >> Am 28. Dezember 2023 14:37:19 MEZ schrieb Simon Glass : > >> >Hi Ilias, > >> > > >> >On Wed, Dec 27, 2023 at 11:12 AM Ilias Apalodimas > >> > wrote: > >> >> > >> >> Hi Simon, > >> >> > >> >> I commented on v3 as well, but in case you miss that > >> >> > >> >> On Wed, 27 Dec 2023 at 09:40, Simon Glass wrote: > >> >> > > >> >> > All callers handle this alignment, so drop the unnecessary code. This > >> >> > simplifies things a little. > >> >> > > >> >> > Signed-off-by: Simon Glass > >> >> > Reviewed-by: Heinrich Schuchardt > >> >> > --- > >> >> > > >> >> > (no changes since v1) > >> >> > > >> >> > include/smbios.h | 5 + > >> >> > lib/smbios.c | 2 -- > >> >> > 2 files changed, 1 insertion(+), 6 deletions(-) > >> >> > > >> >> > diff --git a/include/smbios.h b/include/smbios.h > >> >> > index 77be58887a2..879b8a814b8 100644 > >> >> > --- a/include/smbios.h > >> >> > +++ b/include/smbios.h > >> >> > @@ -258,12 +258,9 @@ static inline void fill_smbios_header(void > >> >> > *table, int type, > >> >> > * > >> >> > * This writes SMBIOS table at a given address. > >> >> > * > >> >> > - * @addr: start address to write SMBIOS table. If this is not > >> >> > - * 16-byte-aligned then it will be aligned before the > >> >> > table is > >> >> > - * written. > >> >> > + * @addr: start address to write SMBIOS table (must be > >> >> > 16-byte-aligned) > >> >> > * Return: end address of SMBIOS table (and start address for > >> >> > next entry) > >> >> > * or NULL in case of an error > >> >> > - * > >> >> > */ > >> >> > ulong write_smbios_table(ulong addr); > >> >> > > >> >> > diff --git a/lib/smbios.c b/lib/smbios.c > >> >> > index 7f79d969c92..cfd451e4088 100644 > >> >> > --- a/lib/smbios.c > >> >> > +++ b/lib/smbios.c > >> >> > @@ -563,8 +563,6 @@ ulong write_smbios_table(ulong addr) > >> >> > ctx.dev = NULL; > >> >> > } > >> >> > > >> >> > - /* 16 byte align the table address */ > >> >> > - addr = ALIGN(addr, 16); > >> >> > >> >> I think this is wrong. It will break SMBIOS on a user error. I am > >> >> fine replacing that with a check instead and error out if the address > >> >> is not 16b aligned > >> > > >> >Well this is why the comment says it must be aligned. This function is > >> >not called willy nilly,from code we control. Checking for alignment > >> >at runtime creates confusion and adds to code size. > >> > >> The SMBIOS tables themself have no alignment requirement. Only on non UEFI > >> x86 system presenting a UEFI entry point in the range 000Fh to > >> 000Fh this copy of the entry point has to be 16 byte aligned. > > Thanks Heinrich, this makes sense > >OK. So perhaps I should reword the comment to say that any > >arch-specific alignment must be respected by the caller? > > Just mentioning the requirement from the spec in the function description > should be good enough. > > Best regards > > Heinrich > > > > >Regards, > >Simon Reviewed-by: Ilias Apalodimas
Re: Proposal: U-Boot memory management
Hi, On Sat, Dec 16, 2023 at 6:01 PM Simon Glass wrote: > > Hi, > > This records my thoughts after a discussion with Ilias & Heinrich re > memory allocation in U-Boot. > > 1. malloc() > > malloc() is used for programmatic memory allocation. It allows memory > to be freed. It is not designed for very large allocations (e.g. a > 10MB kernel or 100MB ramdisk). > > 2. lmb > > lmb is used for large blocks of memory, such as those needed for a > kernel or ramdisk. Allocation is only transitory, for the purposes of > loading some images and booting. If the boot fails, then all lmb > allocations go away. > > lmb is set up by getting all available memory and then removing what > is used by U-Boot (code, data, malloc() space, etc.) > > lmb reservations have a few flags so that areas of memory can be > provided with attributes > > There are some corner cases...e.g. loading a file does an lmb > allocation but only for the purpose of avoiding a file being loaded > over U-Boot code/data. The allocation is dropped immediately after the > file is loaded. Within the bootm command, or when using standard boot, > this would be fairly easy to solve. > > Linux has renamed lmb to memblock. We should consider doing the same. > > 3. EFI > > EFI has its own memory-allocation tables. > > Like lmb, EFI is able to deal with large allocations. But via a 'pool' > function it can also do smaller allocations similar to malloc(), > although each one uses at least 4KB at present. > > EFI allocations do not go away when a boot fails. > > With EFI it is possible to add allocations post facto, in which case > they are added to the allocation table just as if the memory was > allocated with EFI to begin with. > > The EFI allocations and the lmb allocations use the same memory, so in > principle could conflict. > > EFI allocations are sometimes used to allocate internal U-Boot data as > well, if needed by the EFI app. For example, while efi_image_parse() > uses malloc(), efi_var_mem.c uses EFI allocations since the code runs > in the app context and may need to access the memory after U-Boot has > exited. Also efi_smbios.c uses allocate_pages() and then adds a new > mapping as well. > > EFI memory has attributes, including what the memory is used for (to > some degree of granularity). See enum efi_memory_type and struct > efi_mem_desc. In the latter there are also attribute flags - whether > memory is cacheable, etc. > > EFI also has the x86 idea of 'conventional' memory, meaning (I > believe) that below 4GB that isn't reserved for the hardware/system. > This is meaningless, or at least confusing, on ARM systems. > > 4. reservations > > It is perhaps worth mentioning a fourth method of memory management, > where U-Boot reserves chunks of memory before relocation (in > board_init_f.c), e.g. for the framebuffer, U-Boot code, the malloc() > region, etc. > > > Problems > —--- > > There are no urgent problems, but here are some things that could be improved: > > 1. EFI should attach most of its data structures to driver model. This > work has started, with the partition support, but more effort would > help. This would make it easier to see which memory is related to > devices and which is separate. > > 2. Some drivers do EFI reservations today, whether EFI is used for > booting or not (e.g. rockchip video rk_vop_probe()). > > 3. U-Boot doesn't really map arch-specific memory attributes (e.g. > armv8's struct mm_region) to EFI ones. > > 4. EFI duplicates some code from bootm, some of which relates to > memory allocation (e.g. FDT fixup). > > 5. EFI code is used even if EFI is never used to boot > > 6. EFI allocations can result in the same memory being used as has > already been allocated by lmb. Users may load files which overwrite > memory allocated by EFI. 7. We need to support doing an allocation when a file is loaded (to ensure files do not overlap), without making it too difficult to load multiple files to the same place, if desired. > > > Lifetime > > > We have three different memory allocators with different purposes. Can > we unify them a little? > > Within U-Boot: > - malloc() space lives forever > - lmb lives while setting out images for booting > - EFI (mostly) lives while booting an EFI app > > In practice, EFI is set up early in U-Boot. Some of this is necessary, > some not. EFI allocations stay around forever. This works OK since > large allocations are normally not done in EFI, so memory isn't really > consumed to any great degree by the boot process. > > What happens to EFI allocations if the app returns? They are still > present, in case another app is run. This seems fine. > > API > –-- > Can we unify some APIs? > > It should be possible to use lmb for large EFI memory allocations, so > long as they are only needed for booting. We effectively do this > today, since EFI does not manage the arrangement of loaded images in > memory. for the most part. > > It would not make sense to use EFI allocation to replace lmb
Re: Proposal: U-Boot memory management
Hi Ilias, On Fri, Dec 22, 2023 at 12:02 PM Ilias Apalodimas wrote: > > Hi Simon > > I'll respond to the rest more thoroughly but I since I caught this early, > > [...] > > > > > 5. Avoid calling efi_allocate_pages() and efi_allocate_pool() outside > > boot-time services. This solves the problem 6. If memory is needed by > > an app, allocate it with malloc() and see 3. There are only two > > efi_allocate_pages() (smbios and efi_runtime). There are more calls of > > efi_allocate_pool(), but most of these seem easy to fix up. For > > example, efi_init_event_log() allocates a buffer, but this can be > > allocated in normal malloc() space or in a bloblist. > > The TCG event log is only valid in the EFI world and is described by > the EFI spec extensions [0]. I prefer it to remain as is How does that relate to [1] ? > > > > > 6. Don't worry too much about whether EFI will be used for booting. > > The cost is likely not that great: use bootstage to measure it as is > > done for driver model. Try to minmise the cost of its tables, > > particularly for execution time, but otherwise just rely on the > > ability to disable EFI_LOADER. > > > > – > > > > Regards, > > Simon > > [0] > https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf > Thanks > /Ilias [1] https://trustedfirmware-a.readthedocs.io/en/latest/components/measured_boot/event_log.html
Re: [PATCH] include: env: ti: default_findfdt: Follow the bootstd/distro conventions
Nishanth Menon writes:
> Distroboot and bootstd both mandate a findfdt variable pointing to the
> correct device tree blob. Current mechanism calls a find_fdt function
> to set this variable. We do not need a find_fdt command to set the
> environment variable to a single dtb. Simplify the default_findfdt to
> remove variable expansion while at it.
>
> For legacy scripts depending on a TI convention of name_fdt, provide a
> find_fdt wrapper that behaves like before.
>
> NOTE: As part of this change, we also drop the cooked up
> default_device_tree_arch default_device_tree_subarch variables.
>
> Reported-by: Jonathan Humphreys
> Signed-off-by: Nishanth Menon
> ---
> include/env/ti/default_findfdt.env | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/include/env/ti/default_findfdt.env
> b/include/env/ti/default_findfdt.env
> index a2b51dd923bb..1a1ab8406c9e 100644
> --- a/include/env/ti/default_findfdt.env
> +++ b/include/env/ti/default_findfdt.env
> @@ -1,12 +1,7 @@
> -default_device_tree=CONFIG_DEFAULT_DEVICE_TREE
> -default_device_tree_arch=ti
> #ifdef CONFIG_ARM64
> -findfdt=
> - setenv name_fdt ${default_device_tree_arch}/${default_device_tree}.dtb;
> - setenv fdtfile ${name_fdt}
> +fdtfile=ti/CONFIG_DEFAULT_DEVICE_TREE.dtb;
> #else
> -default_device_tree_subarch=omap
> -findfdt=
> - setenv name_fdt
> ${default_device_tree_arch}/${default_device_tree_subarch}/${default_device_tree}.dtb;
> - setenv fdtfile ${name_fdt}
> +fdtfile=ti/omap/CONFIG_DEFAULT_DEVICE_TREE.dtb;
> #endif
> +
> +findfdt=setenv name_fdt ${fdt_file}
> --
> 2.43.0
Nishanth, only am62/beagleplay uses the default_findfdt.env definitions. Others
(eg, j721e) define their own and have a run-time component to them.
Jon
[PATCH] net: phy: ncsi: fixed not nullify the pointers after free
The issue occurs the UAF (use-after-free) to cause double free
when do the realloc function for the pointers during the
reinitialization NC-SI process, and it will cause the memory
management occurs error.
So, nullify these pointers after free.
Signed-off-by: Jacky Chou
---
drivers/net/phy/ncsi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/ncsi.c b/drivers/net/phy/ncsi.c
index eb3fd65bb4..9689385884 100644
--- a/drivers/net/phy/ncsi.c
+++ b/drivers/net/phy/ncsi.c
@@ -619,9 +619,12 @@ static void ncsi_handle_aen(struct ip_udp_hdr *ip,
unsigned int len)
/* Link or configuration lost - just redo the discovery process */
ncsi_priv->state = NCSI_PROBE_PACKAGE_SP;
- for (i = 0; i < ncsi_priv->n_packages; i++)
+ for (i = 0; i < ncsi_priv->n_packages; i++) {
free(ncsi_priv->packages[i].channels);
+ ncsi_priv->packages[i].channels = NULL;
+ }
free(ncsi_priv->packages);
+ ncsi_priv->packages = NULL;
ncsi_priv->n_packages = 0;
ncsi_priv->current_package = NCSI_PACKAGE_MAX;
--
2.34.1
Re: I'm looking for the source code of a specific u-boot version.
Is my version the correct one ?
root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders#
strings u-boot.bin | grep U-Boot
** Invalid partition type "%.32s" (expect "U-Boot")
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e
${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo
Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT
FAILED: continuing...; fi; done
U-Boot.armv7
MU-Boot EFI: Relocation at %p is out of range (%lx)
No valid device tree binary found - please append one to U-Boot
binary, use u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use
-d
U-Boot
U-Boot 2017.05 (Dec 28 2023 - 22:52:29 +0100) for snow
On Thu, Dec 28, 2023 at 11:44 PM Mario Marietto wrote:
>
> Maybe some parameter is wrong inside the snow_defconfig file ? Can you
> give a look ?
>
> CONFIG_ARM=y
> CONFIG_SKIP_LOWLEVEL_INIT=y
> CONFIG_SPL_SKIP_LOWLEVEL_INIT=y
> CONFIG_ARCH_CPU_INIT=y
> # CONFIG_SPL_USE_ARCH_MEMCPY is not set
> # CONFIG_SPL_USE_ARCH_MEMSET is not set
> CONFIG_ARCH_EXYNOS=y
> CONFIG_TEXT_BASE=0x43E0
> CONFIG_SYS_MALLOC_LEN=0x5004000
> CONFIG_SYS_MALLOC_F_LEN=0x400
> CONFIG_ARCH_EXYNOS5=y
> CONFIG_TARGET_SNOW=y
> CONFIG_NR_DRAM_BANKS=8
> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x205
> CONFIG_SF_DEFAULT_SPEED=5000
> CONFIG_ENV_SIZE=0x4000
> CONFIG_ENV_OFFSET=0x3FC000
> CONFIG_ENV_SECT_SIZE=0x4000
> CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow"
> CONFIG_SPL_TEXT_BASE=0x02023400
> CONFIG_SPL=y
> CONFIG_DEBUG_UART_BASE=0x12c3
> CONFIG_DEBUG_UART_CLOCK=1
> CONFIG_IDENT_STRING=" for snow"
> CONFIG_SYS_LOAD_ADDR=0x43e0
> CONFIG_DEBUG_UART=y
> CONFIG_FIT=y
> CONFIG_FIT_BEST_MATCH=y
> CONFIG_BOOTSTD_FULL=y
> CONFIG_BOOTMETH_CROS=y
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_SILENT_CONSOLE=y
> CONFIG_BLOBLIST=y
> # CONFIG_SPL_BLOBLIST is not set
> CONFIG_BLOBLIST_ADDR=0x43d0
> # CONFIG_SPL_FRAMEWORK is not set
> CONFIG_SPL_FOOTPRINT_LIMIT=y
> CONFIG_SPL_MAX_FOOTPRINT=0x3800
> CONFIG_SYS_PROMPT="snow # "
> CONFIG_SYS_PBSIZE=1024
> CONFIG_CMD_GPIO=y
> CONFIG_CMD_I2C=y
> CONFIG_CMD_MMC=y
> CONFIG_CMD_SPI=y
> CONFIG_CMD_USB=y
> # CONFIG_CMD_SETEXPR is not set
> CONFIG_CMD_CACHE=y
> CONFIG_CMD_TIME=y
> CONFIG_CMD_SOUND=y
> CONFIG_CMD_PMIC=y
> CONFIG_CMD_REGULATOR=y
> CONFIG_CMD_TPM=y
> CONFIG_CMD_TPM_TEST=y
> CONFIG_CMD_EXT4_WRITE=y
> CONFIG_ENV_OVERWRITE=y
> CONFIG_ENV_IS_IN_SPI_FLASH=y
> CONFIG_ENV_SPI_BUS=1
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> CONFIG_I2C_CROS_EC_LDO=y
> CONFIG_SYS_I2C_S3C24X0=y
> CONFIG_I2C_MUX=y
> CONFIG_I2C_ARB_GPIO_CHALLENGE=y
> CONFIG_CROS_EC_KEYB=y
> CONFIG_CROS_EC=y
> CONFIG_CROS_EC_I2C=y
> CONFIG_SUPPORT_EMMC_BOOT=y
> CONFIG_MMC_DW=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_S5P=y
> CONFIG_MTD=y
> CONFIG_SPI_FLASH_GIGADEVICE=y
> CONFIG_SPI_FLASH_WINBOND=y
> CONFIG_SMC911X=y
> CONFIG_DM_PMIC=y
> CONFIG_DM_PMIC_MAX77686=y
> CONFIG_PMIC_S5M8767=y
> CONFIG_PMIC_TPS65090=y
> CONFIG_DM_REGULATOR=y
> CONFIG_DM_REGULATOR_MAX77686=y
> CONFIG_REGULATOR_S5M8767=y
> CONFIG_REGULATOR_TPS65090=y
> CONFIG_DM_PWM=y
> CONFIG_PWM_EXYNOS=y
> CONFIG_SOUND=y
> CONFIG_I2S=y
> CONFIG_I2S_SAMSUNG=y
> CONFIG_SOUND_MAX98095=y
> CONFIG_SOUND_WM8994=y
> CONFIG_EXYNOS_SPI=y
> CONFIG_TPM_TIS_INFINEON=y
> CONFIG_USB=y
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_DWC3=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_HOST_ETHER=y
> CONFIG_USB_ETHER_ASIX88179=y
> CONFIG_VIDEO=y
> # CONFIG_VIDEO_BPP8 is not set
> CONFIG_VIDCONSOLE_AS_LCD=y
> CONFIG_DISPLAY=y
> CONFIG_VIDEO_EXYNOS=y
> CONFIG_EXYNOS_DP=y
> CONFIG_EXYNOS_FB=y
> CONFIG_VIDEO_BRIDGE=y
> CONFIG_VIDEO_BRIDGE_PARADE_PS862X=y
> CONFIG_VIDEO_BRIDGE_NXP_PTN3460=y
> CONFIG_TPM=y
> CONFIG_ERRNO_STR=y
> CONFIG_UNIT_TEST=y
> # CONFIG_UT_LIB_ASN1 is not set
>
> On Thu, Dec 28, 2023 at 11:26 PM Mario Marietto
> wrote:
> >
> > I've just built it with Ubuntu 18.04 / gcc 7.5.0 ; I have my
> > u-boot.bin and I tried to see if it worked,but unfortunately it
> > doesn't.
> >
> > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd#
> > ./start-freebsd
> >
> > Parsing config from freebsd.cfg
> > xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader
> > found: Invalid kernel
> > libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image failed
> > libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain
> > 1:cannot (re-)build domain: -3
> > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain
> > 1:Non-existent domain
> > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain
> > 1:Unable to destroy guest
> > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain
> > 1:Destruction of domain failed
> > freebsd is an invalid domain identifier (rc=-6)
> >
> > start-freebsd :
> >
> > xl create freebsd.cfg
> > xl console freebsd
> >
> > freebsd.cfg :
> >
> > name="freebsd"
> > kernel="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot.bin"
> > extra =
Re: I'm looking for the source code of a specific u-boot version.
Maybe some parameter is wrong inside the snow_defconfig file ? Can you give a look ? CONFIG_ARM=y CONFIG_SKIP_LOWLEVEL_INIT=y CONFIG_SPL_SKIP_LOWLEVEL_INIT=y CONFIG_ARCH_CPU_INIT=y # CONFIG_SPL_USE_ARCH_MEMCPY is not set # CONFIG_SPL_USE_ARCH_MEMSET is not set CONFIG_ARCH_EXYNOS=y CONFIG_TEXT_BASE=0x43E0 CONFIG_SYS_MALLOC_LEN=0x5004000 CONFIG_SYS_MALLOC_F_LEN=0x400 CONFIG_ARCH_EXYNOS5=y CONFIG_TARGET_SNOW=y CONFIG_NR_DRAM_BANKS=8 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x205 CONFIG_SF_DEFAULT_SPEED=5000 CONFIG_ENV_SIZE=0x4000 CONFIG_ENV_OFFSET=0x3FC000 CONFIG_ENV_SECT_SIZE=0x4000 CONFIG_DEFAULT_DEVICE_TREE="exynos5250-snow" CONFIG_SPL_TEXT_BASE=0x02023400 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0x12c3 CONFIG_DEBUG_UART_CLOCK=1 CONFIG_IDENT_STRING=" for snow" CONFIG_SYS_LOAD_ADDR=0x43e0 CONFIG_DEBUG_UART=y CONFIG_FIT=y CONFIG_FIT_BEST_MATCH=y CONFIG_BOOTSTD_FULL=y CONFIG_BOOTMETH_CROS=y CONFIG_DISTRO_DEFAULTS=y CONFIG_SILENT_CONSOLE=y CONFIG_BLOBLIST=y # CONFIG_SPL_BLOBLIST is not set CONFIG_BLOBLIST_ADDR=0x43d0 # CONFIG_SPL_FRAMEWORK is not set CONFIG_SPL_FOOTPRINT_LIMIT=y CONFIG_SPL_MAX_FOOTPRINT=0x3800 CONFIG_SYS_PROMPT="snow # " CONFIG_SYS_PBSIZE=1024 CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_SOUND=y CONFIG_CMD_PMIC=y CONFIG_CMD_REGULATOR=y CONFIG_CMD_TPM=y CONFIG_CMD_TPM_TEST=y CONFIG_CMD_EXT4_WRITE=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_ENV_SPI_BUS=1 CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_I2C_CROS_EC_LDO=y CONFIG_SYS_I2C_S3C24X0=y CONFIG_I2C_MUX=y CONFIG_I2C_ARB_GPIO_CHALLENGE=y CONFIG_CROS_EC_KEYB=y CONFIG_CROS_EC=y CONFIG_CROS_EC_I2C=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_DW=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_S5P=y CONFIG_MTD=y CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_SMC911X=y CONFIG_DM_PMIC=y CONFIG_DM_PMIC_MAX77686=y CONFIG_PMIC_S5M8767=y CONFIG_PMIC_TPS65090=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_MAX77686=y CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS65090=y CONFIG_DM_PWM=y CONFIG_PWM_EXYNOS=y CONFIG_SOUND=y CONFIG_I2S=y CONFIG_I2S_SAMSUNG=y CONFIG_SOUND_MAX98095=y CONFIG_SOUND_WM8994=y CONFIG_EXYNOS_SPI=y CONFIG_TPM_TIS_INFINEON=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX88179=y CONFIG_VIDEO=y # CONFIG_VIDEO_BPP8 is not set CONFIG_VIDCONSOLE_AS_LCD=y CONFIG_DISPLAY=y CONFIG_VIDEO_EXYNOS=y CONFIG_EXYNOS_DP=y CONFIG_EXYNOS_FB=y CONFIG_VIDEO_BRIDGE=y CONFIG_VIDEO_BRIDGE_PARADE_PS862X=y CONFIG_VIDEO_BRIDGE_NXP_PTN3460=y CONFIG_TPM=y CONFIG_ERRNO_STR=y CONFIG_UNIT_TEST=y # CONFIG_UT_LIB_ASN1 is not set On Thu, Dec 28, 2023 at 11:26 PM Mario Marietto wrote: > > I've just built it with Ubuntu 18.04 / gcc 7.5.0 ; I have my > u-boot.bin and I tried to see if it worked,but unfortunately it > doesn't. > > root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd# > ./start-freebsd > > Parsing config from freebsd.cfg > xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader > found: Invalid kernel > libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image failed > libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain > 1:cannot (re-)build domain: -3 > libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain > 1:Non-existent domain > libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain > 1:Unable to destroy guest > libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain > 1:Destruction of domain failed > freebsd is an invalid domain identifier (rc=-6) > > start-freebsd : > > xl create freebsd.cfg > xl console freebsd > > freebsd.cfg : > > name="freebsd" > kernel="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot.bin" > extra = "console=hvc0" > memory=512 > vcpus=1 > disk = [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] > > > On Thu, Dec 28, 2023 at 10:54 PM Tony Dinh wrote: > > > > On Thu, Dec 28, 2023 at 11:48 AM Simon Glass wrote: > > > > > > Hi Mario, > > > > > > On Thu, Dec 28, 2023 at 3:48 PM Mario Marietto > > > wrote: > > > > > > > > I tried to compile it,but If failed : > > > > > > > > /mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# > > > > ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make snow_defconfig > > > > > > > > HOSTCC scripts/basic/fixdep > > > > HOSTCC scripts/kconfig/conf.o > > > > HOSTCC scripts/kconfig/zconf.tab.o > > > > In file included from scripts/kconfig/zconf.tab.c:2470: > > > > In function ‘dep_stack_insert’, > > > > inlined from ‘sym_check_print_recursive’ at > > > > scripts/kconfig/symbol.c:1123:3, > > > > inlined from ‘sym_check_deps’ at scripts/kconfig/symbol.c:1300:3: > > > > scripts/kconfig/symbol.c:1099:19: warning: storing the address of > > > > local variable ‘cv_stack’ in ‘check_top’
Re: I'm looking for the source code of a specific u-boot version.
I've just built it with Ubuntu 18.04 / gcc 7.5.0 ; I have my u-boot.bin and I tried to see if it worked,but unfortunately it doesn't. root@devuan-bunsen:/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd# ./start-freebsd Parsing config from freebsd.cfg xc: error: panic: xg_dom_core.c:689: xc_dom_find_loader: no loader found: Invalid kernel libxl: error: libxl_dom.c:571:libxl__build_dom: xc_dom_parse_image failed libxl: error: libxl_create.c:1640:domcreate_rebuild_done: Domain 1:cannot (re-)build domain: -3 libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-existent domain libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Unable to destroy guest libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruction of domain failed freebsd is an invalid domain identifier (rc=-6) start-freebsd : xl create freebsd.cfg xl console freebsd freebsd.cfg : name="freebsd" kernel="/mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot.bin" extra = "console=hvc0" memory=512 vcpus=1 disk = [ 'FreeBSD-13.2-RELEASE-armv7.img,raw,xvda' ] On Thu, Dec 28, 2023 at 10:54 PM Tony Dinh wrote: > > On Thu, Dec 28, 2023 at 11:48 AM Simon Glass wrote: > > > > Hi Mario, > > > > On Thu, Dec 28, 2023 at 3:48 PM Mario Marietto > > wrote: > > > > > > I tried to compile it,but If failed : > > > > > > /mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# > > > ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make snow_defconfig > > > > > > HOSTCC scripts/basic/fixdep > > > HOSTCC scripts/kconfig/conf.o > > > HOSTCC scripts/kconfig/zconf.tab.o > > > In file included from scripts/kconfig/zconf.tab.c:2470: > > > In function ‘dep_stack_insert’, > > > inlined from ‘sym_check_print_recursive’ at > > > scripts/kconfig/symbol.c:1123:3, > > > inlined from ‘sym_check_deps’ at scripts/kconfig/symbol.c:1300:3: > > > scripts/kconfig/symbol.c:1099:19: warning: storing the address of > > > local variable ‘cv_stack’ in ‘check_top’ [-Wdangling-pointer=] > > > 1099 | check_top = stack; > > > | ~~^~~ > > > scripts/kconfig/symbol.c: In function ‘sym_check_deps’: > > > scripts/kconfig/symbol.c:1120:26: note: ‘cv_stack’ declared here > > > 1120 | struct dep_stack cv_stack; > > > | ^~~~ > > > scripts/kconfig/symbol.c:1090:4: note: ‘check_top’ declared here > > > 1090 | } *check_top; > > > |^ > > > HOSTLD scripts/kconfig/conf > > > # > > > # configuration written to .config > > > # > > > > > > /mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# > > > ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make > > > > > > scripts/kconfig/conf --silentoldconfig Kconfig > > > CHK include/config.h > > > CFG u-boot.cfg > > > GEN include/autoconf.mk > > > GEN include/autoconf.mk.dep > > > CFG spl/u-boot.cfg > > > GEN spl/include/autoconf.mk > > > CHK include/config/uboot.release > > > CHK include/generated/version_autogenerated.h > > > CHK include/generated/timestamp_autogenerated.h > > > UPD include/generated/timestamp_autogenerated.h > > > CC lib/asm-offsets.s > > > arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv5 > > > arm-linux-gnueabihf-gcc: note: valid arguments are: armv4 armv4t > > > armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk > > > armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m > > > armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a > > > armv8.6-a armv8-m.base armv8-m.main armv8-r armv8.1-m.main armv9-a > > > iwmmxt iwmmxt2; did you mean ‘armv4’? > > > arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’ > > > make[1]: *** [Kbuild:44: lib/asm-offsets.s] Error 1 > > > make: *** [Makefile:1287: prepare0] Error 2 > > > > You might need to compile with an old toolchain, e.g. gcc 4? > > I think Simon is right. I could not rebuild that 2017.05 u-boot with > gcc 12 now. So I looked at the old log, and it was built with gcc 6.3. > > gcc -Wp,-MD,disk/.part_efi.o.d -nostdinc -isystem > /usr/lib/gcc/arm-linux-gnueabi/6/include -Iinclude > -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__ > -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security > -fno-builtin -ffreestanding -Os -fno-stack-protector > -fno-delete-null-pointer-checks -g -fstack-usage > -Wno-format-nonliteral -Werror=date-time -D__ARM__ -marm > -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -fno-pic > -ffunction-sections -fdata-sections -fno-common -ffixed-r9 > -msoft-float -pipe -march=armv5te -D__LINUX_ARM_ARCH__=5 > -I./arch/arm/mach-kirkwood/include-D"KBUILD_STR(s)=#s" > -D"KBUILD_BASENAME=KBUILD_STR(part_efi)" > -D"KBUILD_MODNAME=KBUILD_STR(part_efi)" -c -o disk/part_efi.o > disk/part_efi.c > > # ll /usr/lib/gcc/arm-linux-gnueabi/6* -d > drwxr-xr-x 5 root root 4096 Apr
Re: I'm looking for the source code of a specific u-boot version.
On Thu, Dec 28, 2023 at 11:48 AM Simon Glass wrote: > > Hi Mario, > > On Thu, Dec 28, 2023 at 3:48 PM Mario Marietto wrote: > > > > I tried to compile it,but If failed : > > > > /mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# > > ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make snow_defconfig > > > > HOSTCC scripts/basic/fixdep > > HOSTCC scripts/kconfig/conf.o > > HOSTCC scripts/kconfig/zconf.tab.o > > In file included from scripts/kconfig/zconf.tab.c:2470: > > In function ‘dep_stack_insert’, > > inlined from ‘sym_check_print_recursive’ at > > scripts/kconfig/symbol.c:1123:3, > > inlined from ‘sym_check_deps’ at scripts/kconfig/symbol.c:1300:3: > > scripts/kconfig/symbol.c:1099:19: warning: storing the address of > > local variable ‘cv_stack’ in ‘check_top’ [-Wdangling-pointer=] > > 1099 | check_top = stack; > > | ~~^~~ > > scripts/kconfig/symbol.c: In function ‘sym_check_deps’: > > scripts/kconfig/symbol.c:1120:26: note: ‘cv_stack’ declared here > > 1120 | struct dep_stack cv_stack; > > | ^~~~ > > scripts/kconfig/symbol.c:1090:4: note: ‘check_top’ declared here > > 1090 | } *check_top; > > |^ > > HOSTLD scripts/kconfig/conf > > # > > # configuration written to .config > > # > > > > /mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# > > ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make > > > > scripts/kconfig/conf --silentoldconfig Kconfig > > CHK include/config.h > > CFG u-boot.cfg > > GEN include/autoconf.mk > > GEN include/autoconf.mk.dep > > CFG spl/u-boot.cfg > > GEN spl/include/autoconf.mk > > CHK include/config/uboot.release > > CHK include/generated/version_autogenerated.h > > CHK include/generated/timestamp_autogenerated.h > > UPD include/generated/timestamp_autogenerated.h > > CC lib/asm-offsets.s > > arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv5 > > arm-linux-gnueabihf-gcc: note: valid arguments are: armv4 armv4t > > armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk > > armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m > > armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a > > armv8.6-a armv8-m.base armv8-m.main armv8-r armv8.1-m.main armv9-a > > iwmmxt iwmmxt2; did you mean ‘armv4’? > > arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’ > > make[1]: *** [Kbuild:44: lib/asm-offsets.s] Error 1 > > make: *** [Makefile:1287: prepare0] Error 2 > > You might need to compile with an old toolchain, e.g. gcc 4? I think Simon is right. I could not rebuild that 2017.05 u-boot with gcc 12 now. So I looked at the old log, and it was built with gcc 6.3. gcc -Wp,-MD,disk/.part_efi.o.d -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/6/include -Iinclude -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -fno-delete-null-pointer-checks -g -fstack-usage -Wno-format-nonliteral -Werror=date-time -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -fno-pic -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -pipe -march=armv5te -D__LINUX_ARM_ARCH__=5 -I./arch/arm/mach-kirkwood/include-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(part_efi)" -D"KBUILD_MODNAME=KBUILD_STR(part_efi)" -c -o disk/part_efi.o disk/part_efi.c # ll /usr/lib/gcc/arm-linux-gnueabi/6* -d drwxr-xr-x 5 root root 4096 Apr 14 2019 /usr/lib/gcc/arm-linux-gnueabi/6 lrwxrwxrwx 1 root root1 May 16 2017 /usr/lib/gcc/arm-linux-gnueabi/6.3.0 -> 6 Hope this helps. All the best, Tony > > Regards, > Simon > > > > > > On Thu, Dec 28, 2023 at 3:47 PM Mario Marietto > > wrote: > > > > > > Hello. > > > > > > Can someone provide the right link to download u-boot-2017.0.5 , please ? > > > > > > I've found it here,but I'm not sure that it's the correct version : > > > > > > https://src.fedoraproject.org/repo/pkgs/uboot-tools/u-boot-2017.05.tar.bz2/sha512/be270f9242a72b05463092a022bbabd54996762de1ff23bf7575124ac02e62f49572a4e2f6f571a5019047d40027e56e35593b5cc373c4a5a39b100c3377ba93/ > > > > > > Can you confirm it ? thanks. > > > > > > On Thu, Dec 28, 2023 at 1:14 AM Tony Dinh wrote: > > > > > > > > Hi Mario and Heinrich, > > > > > > > > On Wed, Dec 27, 2023 at 12:23 PM Mario Marietto > > > > wrote: > > > > > > > > > > Hello. > > > > > > > > > > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook > > > > > SNOW with xen. Basically there are two ways to accomplish this task : > > > > > > > > > > > > > > > 1) to write a patch that allows the FreeBSD kernel to boot as a zImage > > > > > file. This could be accomplished applying this patch to a specific > > > > > file that's on the source code of FreeBSD : > > > > > > > >
Re: [PATCH v6] fdt: Allow the devicetree to come from a bloblist
On Thu, Dec 28, 2023 at 07:47:25PM +, Simon Glass wrote: > Standard passage provides for a bloblist to be passed from one firmware > phase to the next. That can be used to pass the devicetree along as well. > Add an option to support this. > > Tests for this will be added as part of the Universal Payload work. > > Signed-off-by: Simon Glass > --- [snip] > diff --git a/dts/Kconfig b/dts/Kconfig > index 00c0aeff893..ae451b9caf7 100644 > --- a/dts/Kconfig > +++ b/dts/Kconfig > @@ -105,6 +105,19 @@ config OF_EMBED > > endchoice > > +config OF_BLOBLIST > + bool "Provided by a bloblist at runtime" > + depends on BLOBLIST && OF_SEPARATE This is now even more confusing, frankly. The help for OF_SEPARATE says: If this option is enabled, the device tree will be built and placed as a separate u-boot.dtb file alongside the U-Boot image. So why would you enable that to then have a device tree passed via bloblist instead? We should probably start by fixing all of this confusing naming / logic and then correct things such that: - OF_EMBED wins if set. This is the override-has-been-set we-must-use-it switch. First choice, not last choice. If binman needs tweaks so that it will still generate images for platforms in this case, that needs to happen. - If we have a bloblist, we scan the bloblist for DT and if found, use it. - If it looks like we've been booted as a fake Linux kernel, and we can start with just aarch64 and let riscv come in as a follow up, so what's documented within https://www.kernel.org/doc/html/latest/arch/arm64/booting.html#call-the-kernel-image then we use that device tree. - This _may_ just end up having to be "Does x0 (or similar) point to a valid DT?" as I don't know how correct everything using this method today is too what the spec above lists. - If we have a dtb appended to use by what we call today OF_SEPARATE but should really stop calling it that we use that. At that point, we can probably have zero "totally board specific kludge for device tree location", and kill off OF_HAS_PRIOR_STAGE too (since that's really just bloblist or fake-linux-kernel). We'll also be able to support migration from fake-linux-kernel to bloblist -- Tom signature.asc Description: PGP signature
Re: [PATCH v13 00/24] Modernize U-Boot shell
On Fri, 22 Dec 2023 22:02:20 +0100, Francis Laniel wrote: > During 2021 summer, Sean Anderson wrote a contribution to add a new shell, > based > on LIL, to U-Boot [1, 2]. > While one of the goals of this contribution was to address the fact actual > U-Boot shell, which is based on Busybox hush, is old there was a discussion > about adding a new shell versus updating the actual one [3, 4]. > > So, in this series, with Harald Seiler, we updated the actual U-Boot shell to > reflect what is currently in Busybox source code. > Basically, this contribution is about taking a snapshot of Busybox > shell/hush.c > file (as it exists in commit 37460f5da) and adapt it to suit U-Boot needs. > > [...] Applied to u-boot/next, thanks! -- Tom
Re: [PATCH v4 7/7] smbios: Require the caller to align the SMBIOS table
Am 28. Dezember 2023 20:48:04 MEZ schrieb Simon Glass : >Hi Heinrich, > >On Thu, Dec 28, 2023 at 5:36 PM Heinrich Schuchardt wrote: >> >> >> >> Am 28. Dezember 2023 14:37:19 MEZ schrieb Simon Glass : >> >Hi Ilias, >> > >> >On Wed, Dec 27, 2023 at 11:12 AM Ilias Apalodimas >> > wrote: >> >> >> >> Hi Simon, >> >> >> >> I commented on v3 as well, but in case you miss that >> >> >> >> On Wed, 27 Dec 2023 at 09:40, Simon Glass wrote: >> >> > >> >> > All callers handle this alignment, so drop the unnecessary code. This >> >> > simplifies things a little. >> >> > >> >> > Signed-off-by: Simon Glass >> >> > Reviewed-by: Heinrich Schuchardt >> >> > --- >> >> > >> >> > (no changes since v1) >> >> > >> >> > include/smbios.h | 5 + >> >> > lib/smbios.c | 2 -- >> >> > 2 files changed, 1 insertion(+), 6 deletions(-) >> >> > >> >> > diff --git a/include/smbios.h b/include/smbios.h >> >> > index 77be58887a2..879b8a814b8 100644 >> >> > --- a/include/smbios.h >> >> > +++ b/include/smbios.h >> >> > @@ -258,12 +258,9 @@ static inline void fill_smbios_header(void *table, >> >> > int type, >> >> > * >> >> > * This writes SMBIOS table at a given address. >> >> > * >> >> > - * @addr: start address to write SMBIOS table. If this is not >> >> > - * 16-byte-aligned then it will be aligned before the >> >> > table is >> >> > - * written. >> >> > + * @addr: start address to write SMBIOS table (must be >> >> > 16-byte-aligned) >> >> > * Return: end address of SMBIOS table (and start address for next >> >> > entry) >> >> > * or NULL in case of an error >> >> > - * >> >> > */ >> >> > ulong write_smbios_table(ulong addr); >> >> > >> >> > diff --git a/lib/smbios.c b/lib/smbios.c >> >> > index 7f79d969c92..cfd451e4088 100644 >> >> > --- a/lib/smbios.c >> >> > +++ b/lib/smbios.c >> >> > @@ -563,8 +563,6 @@ ulong write_smbios_table(ulong addr) >> >> > ctx.dev = NULL; >> >> > } >> >> > >> >> > - /* 16 byte align the table address */ >> >> > - addr = ALIGN(addr, 16); >> >> >> >> I think this is wrong. It will break SMBIOS on a user error. I am >> >> fine replacing that with a check instead and error out if the address >> >> is not 16b aligned >> > >> >Well this is why the comment says it must be aligned. This function is >> >not called willy nilly,from code we control. Checking for alignment >> >at runtime creates confusion and adds to code size. >> >> The SMBIOS tables themself have no alignment requirement. Only on non UEFI >> x86 system presenting a UEFI entry point in the range 000Fh to 000Fh >> this copy of the entry point has to be 16 byte aligned. > >OK. So perhaps I should reword the comment to say that any >arch-specific alignment must be respected by the caller? Just mentioning the requirement from the spec in the function description should be good enough. Best regards Heinrich > >Regards, >Simon
Re: [PATCH 0/9] dts: Move to SoC-specific build rules
On Thu, Dec 28, 2023 at 07:48:08PM +, Simon Glass wrote: > Hi Tom, > > On Thu, Dec 28, 2023 at 3:40 PM Tom Rini wrote: > > > > On Thu, Dec 28, 2023 at 03:09:40PM +, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, Dec 28, 2023 at 2:23 PM Tom Rini wrote: > > > > > > > > On Thu, Dec 28, 2023 at 01:37:07PM +, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Wed, Dec 27, 2023 at 1:21 PM Tom Rini wrote: > > > > > > > > > > > > On Wed, Dec 27, 2023 at 08:23:56AM +, Simon Glass wrote: > > > > > > > > > > > > > U-Boot builds devicetree binaries from its source tree. As part > > > > > > > of the > > > > > > > Kconfig conversion, the Makefiles were updated to align with how > > > > > > > this > > > > > > > is done in Linux: a single target for each SoC is used to build > > > > > > > all the > > > > > > > .dtb files for that SoC. > > > > > > > > > > > > > > Since then, the Makefiles have devolved in some cases, resulting > > > > > > > in > > > > > > > lots of target-specific build rules. Also Linux has moved to using > > > > > > > subdirectories for each vendor. > > > > > > > > > > > > > > Recent work aims to allow U-Boot to directly use devicetree files > > > > > > > from > > > > > > > Linux. This would be easier if the directory structure were the > > > > > > > same. > > > > > > > Another recent discussion involved dropping the build rules > > > > > > > altogether. > > > > > > > > > > > > > > This series makes a start at cleaning up some of the build rules, > > > > > > > to > > > > > > > reduce the amount of code and make it easier to add new boards > > > > > > > for the > > > > > > > same SoC. > > > > > > > > > > > > > > One issue is that the ARCH_xxx Kconfig options between U-Boot and > > > > > > > Linux > > > > > > > are not always the same. Given the large number of SoCs and boards > > > > > > > supported by U-Boot, it would be useful to align these where > > > > > > > possible. > > > > > > > > > > > > I don't know why we should start with this now, and further not > > > > > > being on > > > > > > top of Sumit's series to remove our duplicate dts files. And that's > > > > > > where we can have the conversation about for which cases it even > > > > > > makes > > > > > > sense to build all of the dts files for a given SoC. > > > > > > > > > > This is a completely different series - there are no conflicts with > > > > > Sumit's series so it can be applied before or after it. > > > > > > > > > > My goal here is to clean up our build rules, rather than just throwing > > > > > them all away, for reasons we have discussed previously. I filed [1] > > > > > to track that. > > > > > > > > Yes, I'm saying we shouldn't be doing anything this series does until > > > > after Sumit's series has landed. Along with the fact that I don't like > > > > what's going on in this series. > > > > > > This seems to again be the disagreement over whether a single DT > > > should be build for each board, or all the DTs for an SoC? > > > > It's about the disagreement on what we should be building, and what that > > infrastructure looks like. I do not like adding extra rules for > > "clarity" because they don't make things clearer, they lead to the > > unclear mess we have today getting worse. Most instructions are _not_ > > "now take this dtb and this binary and .." but just "take this binary", > > because we already have the rules and logic to ensure we build the > > required dtbs. I also don't like the parts of this series that amount > > to deck shuffling when we should just be taking the chairs away. There's > > just not nor will there be a case for omap3/4/5 platforms of "change the > > dtb", so building more is pointless. For other SoCs, there may be some > > cases of "this could have been just a DT change", like > > rock5b-rk3588_defconfig / rock5a-rk3588s_defconfig could share a board > > dir, but the configs are different and the dts are different, so I don't > > know that you could really just swap the dtbs. > > It is true that we have a different defconfig for each board, but IMO > that is not good. It is an artifact of the way the build system works. > IMO Kconfig should be used to define sensible defaults so that the > defconfigs are nearly empty. Perhaps config fragments can be part of > the mix, if we can agree on [1]. > > But if we let this genie out of the bottle, it will be impossible to > put back in. The devicetree should control the hardware in U-Boot and > it should be possible to use the same U-Boot proper on all boards > which use the same SoC. We've never been past the point where a few examples of closely related boards can re-use the same U-Boot build and just change the device tree. It's going to be very SoC specific if we can ever do things like that, and it will also likely in turn become a question of where did the tricky bits that U-Boot used to do get shoved instead. You're not going to combine board/beagle/beagle/beagle.c and board/ti/omap3evm/evm.c (and
Re: [PATCH v3 7/8] dts: meson-gxbb: Switch to using upstream DT
On Thu, Dec 28, 2023 at 07:48:13PM +, Simon Glass wrote: > Hi Tom, > > On Thu, Dec 28, 2023 at 3:25 PM Tom Rini wrote: > > > > On Thu, Dec 28, 2023 at 03:09:41PM +, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, Dec 28, 2023 at 1:56 PM Tom Rini wrote: > > > > > > > > On Thu, Dec 28, 2023 at 01:37:11PM +, Simon Glass wrote: > > > > > Hi Sumit, > > > > > > > > > > On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg > > > > > wrote: > > > > > > > > > > > > Although there were still some variations in board DTS files based > > > > > > on > > > > > > meson-gxbb SoC but I think those were minor differences from > > > > > > upstream > > > > > > and shouldn't impact boot on these devices. > > > > > > > > > > > > So switch to upstream DT via mirroring amlogic/ directory from > > > > > > devicetree-rebasing/src/arm64/amlogic/ directory. And thereby > > > > > > directly > > > > > > building DTB from there including *-u-boot.dtsi files from > > > > > > arch/$(ARCH)/dts/ directory. > > > > > > > > > > > > Reviewed-by: Neil Armstrong > > > > > > Signed-off-by: Sumit Garg > > > > > > --- > > > > > > > > > > > > Changes in v3: > > > > > > -- > > > > > > - Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead. > > > > > > > > > > > > Changes in v2: > > > > > > -- > > > > > > - Picked up review tag > > > > > > > > > > > > arch/arm/mach-meson/Kconfig | 1 + > > > > > > configs/nanopi-k2_defconfig | 2 +- > > > > > > configs/odroid-c2_defconfig | 2 +- > > > > > > configs/p200_defconfig| 2 +- > > > > > > configs/p201_defconfig| 2 +- > > > > > > configs/videostrong-kii-pro_defconfig | 2 +- > > > > > > configs/wetek-hub_defconfig | 2 +- > > > > > > configs/wetek-play2_defconfig | 2 +- > > > > > > dts/arch/arm64/amlogic| 1 + > > > > > > 9 files changed, 9 insertions(+), 7 deletions(-) > > > > > > create mode 12 dts/arch/arm64/amlogic > > > > > > > > > > > > > > > > Reviewed-by: Simon Glass > > > > > > > > > > > diff --git a/arch/arm/mach-meson/Kconfig > > > > > > b/arch/arm/mach-meson/Kconfig > > > > > > index d6c89058061..8ddb59161a0 100644 > > > > > > --- a/arch/arm/mach-meson/Kconfig > > > > > > +++ b/arch/arm/mach-meson/Kconfig > > > > > > @@ -25,6 +25,7 @@ choice > > > > > > config MESON_GXBB > > > > > > bool "GXBB" > > > > > > select MESON_GX > > > > > > + imply OF_UPSTREAM > > > > > > help > > > > > > Select this if your SoC is an S905 > > > > > > > > > > > > diff --git a/configs/nanopi-k2_defconfig > > > > > > b/configs/nanopi-k2_defconfig > > > > > > index 41dbf7981f8..2e1c756bf7a 100644 > > > > > > --- a/configs/nanopi-k2_defconfig > > > > > > +++ b/configs/nanopi-k2_defconfig > > > > > > @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > > > > > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000 > > > > > > CONFIG_ENV_SIZE=0x2000 > > > > > > CONFIG_DM_GPIO=y > > > > > > -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" > > > > > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" > > > > > > CONFIG_OF_LIBFDT_OVERLAY=y > > > > > > CONFIG_DM_RESET=y > > > > > > CONFIG_DEBUG_UART_BASE=0xc81004c0 > > > > > > > > > > So now I am wondering if we can (later) have the SoC be implied when > > > > > using OF_UPSTREAM so we can do: > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" > > > > > > > > > > and it will add the 'amlogic/' automatically? > > > > > > > > > > Perhaps that might be a way to bridge the gap in terms of file layout? > > > > > > > > That's going to start to look real ugly real quick I suspect and I'm not > > > > sure what it really gets us? It seems to me that the convention of > > > > "vendor/board" has already been well enough adapted outside of the > > > > kernel, with the odd sticking point being getting everyone used to > > > > whatever will be happening for 32bit boards long term. So I think hiding > > > > the vendor part of the string here will be more, not less, confusing > > > > long term. > > > > > > Now that I dig in a bit, I see that the devicetree-rebasing tree does > > > not have any Makefiles in it. How does Linux build with it? Does > > > anyone have instructions? > > > > Linux doesn't build with it, it's the relevant parts of the kernel tree > > extracted for other projects to more easily use (more or less). > > Hmmm, in that case can we add Makefiles into the U-Boot version of the > tree, for U-Boot use? No? Why would we do that? I think you're missing how the amlogic conversion works. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds
On Thu, Dec 28, 2023 at 07:48:06PM +, Simon Glass wrote: > Hi Tom, > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini wrote: > > > > On Thu, Dec 28, 2023 at 03:09:12PM +, Simon Glass wrote: > > > Hi Tom, Sumit, > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini wrote: > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +, Simon Glass wrote: > > > > > Hi Sumit, > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg > > > > > wrote: > > > > > > > > > > > > Allow platform owners to mirror devicetree files from > > > > > > devitree-rebasing > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). > > > > > > Then > > > > > > build then along with any *-u-boot.dtsi file present in > > > > > > arch/$(ARCH)/dts > > > > > > directory. Also add a new Makefile for arm64. > > > > > > > > > > > > This will help easy migration for platforms which currently are > > > > > > compliant > > > > > > with upstream Linux kernel devicetree files. > > > > > > > > > > > > Signed-off-by: Sumit Garg > > > > > > --- > > > > > > > > > > > > Changes in v3: > > > > > > -- > > > > > > - Minor commit message update > > > > > > > > > > > > Changes in v2: > > > > > > -- > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > > > > > > > dts/Kconfig | 11 +++ > > > > > > dts/Makefile| 17 ++--- > > > > > > dts/arch/arm64/Makefile | 14 ++ > > > > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > > > > --- a/dts/Kconfig > > > > > > +++ b/dts/Kconfig > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > > > > enables a live tree which is available after relocation, > > > > > > and can be adjusted as needed. > > > > > > > > > > > > +config OF_UPSTREAM > > > > > > + bool "Enable use of devicetree imported from Linux kernel > > > > > > release" > > > > > > + help > > > > > > + Traditionally, U-Boot platforms used to have their custom > > > > > > devicetree > > > > > > + files or copy devicetree files from Linux kernel which > > > > > > are hard to > > > > > > + maintain and can usually get out-of-sync from Linux > > > > > > kernel. This > > > > > > + option enables platforms to migrate to > > > > > > devicetree-rebasing repo where > > > > > > + a regular sync will be maintained every major Linux > > > > > > kernel release > > > > > > + cycle. However, platforms can still have some custom > > > > > > u-boot specific > > > > > > + bits maintained as part of *-u-boot.dtsi files. > > > > > > > > > > My only other suggestion here is to mention that this should be set in > > > > > Kconfig, for the SoC as a whole. So I believe that means that it > > > > > should be hidden, with no string for the 'bool': > > > > > > > > > > bool # Enable use of devicetree imported from Linux kernel > > > > > release > > > > > > > > I think we can just keep prompting for it now, to make the transition > > > > easier, before this option just goes away in time, hopefully. > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these > > > > > files when building firefly-rk3399: > > > > > > > > > > rk3399-eaidk-610.dtbrk3399-khadas-edge-v.dtb > > > > > rk3399-orangepi.dtbrk3399-rock-pi-4a.dtb > > > > > rk3399-evb.dtb rk3399-leez-p710.dtb > > > > > rk3399-pinebook-pro.dtbrk3399-rock-pi-4c.dtb > > > > > rk3399-ficus.dtbrk3399-nanopc-t4.dtb > > > > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > > > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > > > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > > > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > > > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > > > > rk3399-gru-kevin.dtbrk3399-nanopi-m4.dtb > > > > > rk3399-rock-4c-plus.dtb > > > > > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb > > > > > rk3399-rock-4se.dtb > > > > > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb > > > > > rk3399-rock960.dtb > > > > > > > > > > Afterwards I get this: > > > > > > > > > > make[3]: *** No rule to make target > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > So I set this manually for that one board: > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > > > > > > > > > and get: > > > > > > > > > > make[3]: *** No rule to make target > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all > > > > > the DTs for rk3399, as it does today. > > > > > > > > Looking at the patch for
Re: [PATCH v6 4/6] common: console: record console from the beginning
чт, 28 груд. 2023 р. о 21:48 Simon Glass пише: > > On Thu, Dec 28, 2023 at 6:02 PM Svyatoslav Ryhel wrote: > > > > From: Ion Agorria > > > > Set flag to enable console record on console_record_init > > and not only on console_record_reset_enable. This fixes > > missing start of U-Boot log for fastboot oem console > > command. > > > > Signed-off-by: Ion Agorria > > Signed-off-by: Svyatoslav Ryhel > > Reviewed-by: Mattijs Korpershoek > > --- > > common/console.c | 3 +++ > > 1 file changed, 3 insertions(+) > > Reviewed-by: Simon Glass > > OK, I can see the use of this...but I wonder if we can now get rid of > the same line of code from console_record_reset_enable() ? > Interesting question but let's leave it to a dedicated patch :) Best Regards, Svyatoslav R. > > > > diff --git a/common/console.c b/common/console.c > > index 6f2089caa0..e6d7ebe935 100644 > > --- a/common/console.c > > +++ b/common/console.c > > @@ -821,6 +821,9 @@ int console_record_init(void) > > ret = membuff_new((struct membuff *)>console_in, > > CONFIG_CONSOLE_RECORD_IN_SIZE); > > > > + /* Start recording from the beginning */ > > + gd->flags |= GD_FLG_RECORD; > > + > > return ret; > > } > > > > -- > > 2.40.1 > > > > Regards, > Simon
Re: [PATCH v3 1/9] bloblist: add API to check the register conventions
Hi Raymond,
On Thu, Dec 28, 2023 at 3:13 PM Raymond Mao wrote:
>
> Hi Simon,
>
> On Thu, 28 Dec 2023 at 08:38, Simon Glass wrote:
>>
>> Hi Raymond,
>>
>> On Wed, Dec 27, 2023 at 4:06 PM Raymond Mao wrote:
>> >
>> > Hi Simon,
>> >
>> > On Tue, 26 Dec 2023 at 04:48, Simon Glass wrote:
>> >>
>> >> Hi Raymond,
>> >>
>> >> On Fri, Dec 22, 2023 at 9:31 PM Raymond Mao
>> >> wrote:
>> >> >
>> >> > Add bloblist_check_reg_conv() to check whether the bloblist is compliant
>> >> > to the register conventions defined in Firmware Handoff specification.
>> >> > This API can be used for all Arm platforms.
>> >> >
>> >> > Signed-off-by: Raymond Mao
>> >> > ---
>> >> > Changes in v2
>> >> > - Refactor of bloblist_check_reg_conv().
>> >> > Changes in v3
>> >> > - bloblist_check_reg_conv() returns -ENOENT if OF_BOARD is disabled.
>> >> >
>> >> > common/bloblist.c | 13 +
>> >> > include/bloblist.h | 12
>> >> > 2 files changed, 25 insertions(+)
>> >> >
>> >> > diff --git a/common/bloblist.c b/common/bloblist.c
>> >> > index 625e480f6b..ba17dd851a 100644
>> >> > --- a/common/bloblist.c
>> >> > +++ b/common/bloblist.c
>> >> > @@ -542,3 +542,16 @@ int bloblist_maybe_init(void)
>> >> >
>> >> > return 0;
>> >> > }
>> >> > +
>> >> > +int bloblist_check_reg_conv(ulong rfdt, ulong rzero)
>> >> > +{
>> >> > + if (!IS_ENABLED(CONFIG_OF_BOARD))
>> >> > + return -ENOENT;
>> >> > +
>> >> > + if (rzero || rfdt !=
>> >> > (ulong)bloblist_find(BLOBLISTT_CONTROL_FDT, 0)) {
>> >> > + gd->bloblist = NULL; /* Reset the gd bloblist pointer
>> >> > */
>> >> > + return -EIO;
>> >> > + }
>> >>
>> >> Where does the magic 4a0fb10b value get checked?
>> >>
>> > The magic and version of register conventions cannot be checked now since
>> > there is
>> > a bug in the spec. PSB:
>> > ```
>> > X1[23:0]: set to the TL signature (4a0f_b10b)
>>
>> That should say 0f_b10b
>>
> However, currently we have switched to `4a0f_b10b` in both TF-A and OP-TEE.
> I don't want to break the dataflow that is currently working.
> I prefer to make patches to TF-A, OP-TEE and U-Boot at the same time when
> spec v1.0 is ready.
Yes, sure, but we should fix them too!
>
> [...]
>
> Thanks and regards,
> Raymond
Regards,
Simon
Re: I'm looking for the source code of a specific u-boot version.
Hi Mario, On Thu, Dec 28, 2023 at 3:48 PM Mario Marietto wrote: > > I tried to compile it,but If failed : > > /mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# > ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make snow_defconfig > > HOSTCC scripts/basic/fixdep > HOSTCC scripts/kconfig/conf.o > HOSTCC scripts/kconfig/zconf.tab.o > In file included from scripts/kconfig/zconf.tab.c:2470: > In function ‘dep_stack_insert’, > inlined from ‘sym_check_print_recursive’ at > scripts/kconfig/symbol.c:1123:3, > inlined from ‘sym_check_deps’ at scripts/kconfig/symbol.c:1300:3: > scripts/kconfig/symbol.c:1099:19: warning: storing the address of > local variable ‘cv_stack’ in ‘check_top’ [-Wdangling-pointer=] > 1099 | check_top = stack; > | ~~^~~ > scripts/kconfig/symbol.c: In function ‘sym_check_deps’: > scripts/kconfig/symbol.c:1120:26: note: ‘cv_stack’ declared here > 1120 | struct dep_stack cv_stack; > | ^~~~ > scripts/kconfig/symbol.c:1090:4: note: ‘check_top’ declared here > 1090 | } *check_top; > |^ > HOSTLD scripts/kconfig/conf > # > # configuration written to .config > # > > /mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# > ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make > > scripts/kconfig/conf --silentoldconfig Kconfig > CHK include/config.h > CFG u-boot.cfg > GEN include/autoconf.mk > GEN include/autoconf.mk.dep > CFG spl/u-boot.cfg > GEN spl/include/autoconf.mk > CHK include/config/uboot.release > CHK include/generated/version_autogenerated.h > CHK include/generated/timestamp_autogenerated.h > UPD include/generated/timestamp_autogenerated.h > CC lib/asm-offsets.s > arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv5 > arm-linux-gnueabihf-gcc: note: valid arguments are: armv4 armv4t > armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk > armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m > armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a > armv8.6-a armv8-m.base armv8-m.main armv8-r armv8.1-m.main armv9-a > iwmmxt iwmmxt2; did you mean ‘armv4’? > arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’ > make[1]: *** [Kbuild:44: lib/asm-offsets.s] Error 1 > make: *** [Makefile:1287: prepare0] Error 2 You might need to compile with an old toolchain, e.g. gcc 4? Regards, Simon > > On Thu, Dec 28, 2023 at 3:47 PM Mario Marietto wrote: > > > > Hello. > > > > Can someone provide the right link to download u-boot-2017.0.5 , please ? > > > > I've found it here,but I'm not sure that it's the correct version : > > > > https://src.fedoraproject.org/repo/pkgs/uboot-tools/u-boot-2017.05.tar.bz2/sha512/be270f9242a72b05463092a022bbabd54996762de1ff23bf7575124ac02e62f49572a4e2f6f571a5019047d40027e56e35593b5cc373c4a5a39b100c3377ba93/ > > > > Can you confirm it ? thanks. > > > > On Thu, Dec 28, 2023 at 1:14 AM Tony Dinh wrote: > > > > > > Hi Mario and Heinrich, > > > > > > On Wed, Dec 27, 2023 at 12:23 PM Mario Marietto > > > wrote: > > > > > > > > Hello. > > > > > > > > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook > > > > SNOW with xen. Basically there are two ways to accomplish this task : > > > > > > > > > > > > 1) to write a patch that allows the FreeBSD kernel to boot as a zImage > > > > file. This could be accomplished applying this patch to a specific > > > > file that's on the source code of FreeBSD : > > > > > > > > > > > > https://xenbits.xen.org/gitweb/?p=p...8;hb=0782e25d98cc1391472717035f986c979edef0c9 > > > > > > > > > > > > > > > > This patch was written by Julien Grall a lot of time ago and now it > > > > does not work anymore. This is the reason explain by the xen > > > > developers : > > > > > > > > > > > > > > > > It appears FreeBSD-CURRENT removed the last step converting the kernel > > > > file to kernel.bin.The patch can be readily rebased, but without > > > > kernel.bin that doesn't do too much. > > > > > > > > > > > > > > > > So,without a rebase of that patch the first option is not applicable. > > > > And I'm not able to fix it. > > > > > > > > > > > > 2) booting FreeBSD using U-Boot,as explained to me by a xen developer : > > > > > > > > > > > > I was trying to explain why and how Julien's patch works so that you > > > > could be the one to re-do something similar or fix the patch on the > > > > FreeBSD kernel that you are working with. I am happy to help review > > > > and write patches but I don't work with the FreeBSD kernel so I > > > > wouldn't be able to help you quickly. However, I might have a > > > > suggestion. Do you know if FreeBSD can be booted by U-Boot ? > > > > Because > > > > U-Boot definitely boots as Xen on ARM guest firmware/bootloader. You > > > > should be able to build U-Boot and use the U-Boot binary as Xen guest > > > >
Re: [PATCH v3 7/8] dts: meson-gxbb: Switch to using upstream DT
Hi Tom, On Thu, Dec 28, 2023 at 3:25 PM Tom Rini wrote: > > On Thu, Dec 28, 2023 at 03:09:41PM +, Simon Glass wrote: > > Hi Tom, > > > > On Thu, Dec 28, 2023 at 1:56 PM Tom Rini wrote: > > > > > > On Thu, Dec 28, 2023 at 01:37:11PM +, Simon Glass wrote: > > > > Hi Sumit, > > > > > > > > On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg > > > > wrote: > > > > > > > > > > Although there were still some variations in board DTS files based on > > > > > meson-gxbb SoC but I think those were minor differences from upstream > > > > > and shouldn't impact boot on these devices. > > > > > > > > > > So switch to upstream DT via mirroring amlogic/ directory from > > > > > devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly > > > > > building DTB from there including *-u-boot.dtsi files from > > > > > arch/$(ARCH)/dts/ directory. > > > > > > > > > > Reviewed-by: Neil Armstrong > > > > > Signed-off-by: Sumit Garg > > > > > --- > > > > > > > > > > Changes in v3: > > > > > -- > > > > > - Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead. > > > > > > > > > > Changes in v2: > > > > > -- > > > > > - Picked up review tag > > > > > > > > > > arch/arm/mach-meson/Kconfig | 1 + > > > > > configs/nanopi-k2_defconfig | 2 +- > > > > > configs/odroid-c2_defconfig | 2 +- > > > > > configs/p200_defconfig| 2 +- > > > > > configs/p201_defconfig| 2 +- > > > > > configs/videostrong-kii-pro_defconfig | 2 +- > > > > > configs/wetek-hub_defconfig | 2 +- > > > > > configs/wetek-play2_defconfig | 2 +- > > > > > dts/arch/arm64/amlogic| 1 + > > > > > 9 files changed, 9 insertions(+), 7 deletions(-) > > > > > create mode 12 dts/arch/arm64/amlogic > > > > > > > > > > > > > Reviewed-by: Simon Glass > > > > > > > > > diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig > > > > > index d6c89058061..8ddb59161a0 100644 > > > > > --- a/arch/arm/mach-meson/Kconfig > > > > > +++ b/arch/arm/mach-meson/Kconfig > > > > > @@ -25,6 +25,7 @@ choice > > > > > config MESON_GXBB > > > > > bool "GXBB" > > > > > select MESON_GX > > > > > + imply OF_UPSTREAM > > > > > help > > > > > Select this if your SoC is an S905 > > > > > > > > > > diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig > > > > > index 41dbf7981f8..2e1c756bf7a 100644 > > > > > --- a/configs/nanopi-k2_defconfig > > > > > +++ b/configs/nanopi-k2_defconfig > > > > > @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > > > > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000 > > > > > CONFIG_ENV_SIZE=0x2000 > > > > > CONFIG_DM_GPIO=y > > > > > -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" > > > > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" > > > > > CONFIG_OF_LIBFDT_OVERLAY=y > > > > > CONFIG_DM_RESET=y > > > > > CONFIG_DEBUG_UART_BASE=0xc81004c0 > > > > > > > > So now I am wondering if we can (later) have the SoC be implied when > > > > using OF_UPSTREAM so we can do: > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" > > > > > > > > and it will add the 'amlogic/' automatically? > > > > > > > > Perhaps that might be a way to bridge the gap in terms of file layout? > > > > > > That's going to start to look real ugly real quick I suspect and I'm not > > > sure what it really gets us? It seems to me that the convention of > > > "vendor/board" has already been well enough adapted outside of the > > > kernel, with the odd sticking point being getting everyone used to > > > whatever will be happening for 32bit boards long term. So I think hiding > > > the vendor part of the string here will be more, not less, confusing > > > long term. > > > > Now that I dig in a bit, I see that the devicetree-rebasing tree does > > not have any Makefiles in it. How does Linux build with it? Does > > anyone have instructions? > > Linux doesn't build with it, it's the relevant parts of the kernel tree > extracted for other projects to more easily use (more or less). Hmmm, in that case can we add Makefiles into the U-Boot version of the tree, for U-Boot use? Regards, Simon
Re: [PATCH v6 4/6] common: console: record console from the beginning
On Thu, Dec 28, 2023 at 6:02 PM Svyatoslav Ryhel wrote: > > From: Ion Agorria > > Set flag to enable console record on console_record_init > and not only on console_record_reset_enable. This fixes > missing start of U-Boot log for fastboot oem console > command. > > Signed-off-by: Ion Agorria > Signed-off-by: Svyatoslav Ryhel > Reviewed-by: Mattijs Korpershoek > --- > common/console.c | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Simon Glass OK, I can see the use of this...but I wonder if we can now get rid of the same line of code from console_record_reset_enable() ? > > diff --git a/common/console.c b/common/console.c > index 6f2089caa0..e6d7ebe935 100644 > --- a/common/console.c > +++ b/common/console.c > @@ -821,6 +821,9 @@ int console_record_init(void) > ret = membuff_new((struct membuff *)>console_in, > CONFIG_CONSOLE_RECORD_IN_SIZE); > > + /* Start recording from the beginning */ > + gd->flags |= GD_FLG_RECORD; > + > return ret; > } > > -- > 2.40.1 > Regards, Simon
Re: [PATCH v6 3/6] common: console: introduce console_record_isempty helper
On Thu, Dec 28, 2023 at 6:02 PM Svyatoslav Ryhel wrote: > > From: Ion Agorria > > Add console_record_isempty to check if console record buffer > contains any data. > > Signed-off-by: Ion Agorria > Signed-off-by: Svyatoslav Ryhel > Reviewed-by: Mattijs Korpershoek > --- > common/console.c | 5 + > include/console.h | 13 + > 2 files changed, 18 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH 0/9] dts: Move to SoC-specific build rules
Hi Tom, On Thu, Dec 28, 2023 at 3:40 PM Tom Rini wrote: > > On Thu, Dec 28, 2023 at 03:09:40PM +, Simon Glass wrote: > > Hi Tom, > > > > On Thu, Dec 28, 2023 at 2:23 PM Tom Rini wrote: > > > > > > On Thu, Dec 28, 2023 at 01:37:07PM +, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Wed, Dec 27, 2023 at 1:21 PM Tom Rini wrote: > > > > > > > > > > On Wed, Dec 27, 2023 at 08:23:56AM +, Simon Glass wrote: > > > > > > > > > > > U-Boot builds devicetree binaries from its source tree. As part of > > > > > > the > > > > > > Kconfig conversion, the Makefiles were updated to align with how > > > > > > this > > > > > > is done in Linux: a single target for each SoC is used to build all > > > > > > the > > > > > > .dtb files for that SoC. > > > > > > > > > > > > Since then, the Makefiles have devolved in some cases, resulting in > > > > > > lots of target-specific build rules. Also Linux has moved to using > > > > > > subdirectories for each vendor. > > > > > > > > > > > > Recent work aims to allow U-Boot to directly use devicetree files > > > > > > from > > > > > > Linux. This would be easier if the directory structure were the > > > > > > same. > > > > > > Another recent discussion involved dropping the build rules > > > > > > altogether. > > > > > > > > > > > > This series makes a start at cleaning up some of the build rules, to > > > > > > reduce the amount of code and make it easier to add new boards for > > > > > > the > > > > > > same SoC. > > > > > > > > > > > > One issue is that the ARCH_xxx Kconfig options between U-Boot and > > > > > > Linux > > > > > > are not always the same. Given the large number of SoCs and boards > > > > > > supported by U-Boot, it would be useful to align these where > > > > > > possible. > > > > > > > > > > I don't know why we should start with this now, and further not being > > > > > on > > > > > top of Sumit's series to remove our duplicate dts files. And that's > > > > > where we can have the conversation about for which cases it even makes > > > > > sense to build all of the dts files for a given SoC. > > > > > > > > This is a completely different series - there are no conflicts with > > > > Sumit's series so it can be applied before or after it. > > > > > > > > My goal here is to clean up our build rules, rather than just throwing > > > > them all away, for reasons we have discussed previously. I filed [1] > > > > to track that. > > > > > > Yes, I'm saying we shouldn't be doing anything this series does until > > > after Sumit's series has landed. Along with the fact that I don't like > > > what's going on in this series. > > > > This seems to again be the disagreement over whether a single DT > > should be build for each board, or all the DTs for an SoC? > > It's about the disagreement on what we should be building, and what that > infrastructure looks like. I do not like adding extra rules for > "clarity" because they don't make things clearer, they lead to the > unclear mess we have today getting worse. Most instructions are _not_ > "now take this dtb and this binary and .." but just "take this binary", > because we already have the rules and logic to ensure we build the > required dtbs. I also don't like the parts of this series that amount > to deck shuffling when we should just be taking the chairs away. There's > just not nor will there be a case for omap3/4/5 platforms of "change the > dtb", so building more is pointless. For other SoCs, there may be some > cases of "this could have been just a DT change", like > rock5b-rk3588_defconfig / rock5a-rk3588s_defconfig could share a board > dir, but the configs are different and the dts are different, so I don't > know that you could really just swap the dtbs. It is true that we have a different defconfig for each board, but IMO that is not good. It is an artifact of the way the build system works. IMO Kconfig should be used to define sensible defaults so that the defconfigs are nearly empty. Perhaps config fragments can be part of the mix, if we can agree on [1]. But if we let this genie out of the bottle, it will be impossible to put back in. The devicetree should control the hardware in U-Boot and it should be possible to use the same U-Boot proper on all boards which use the same SoC. Regards, SImon [1] https://patchwork.ozlabs.org/user/todo/uboot/?series=380278
Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds
Hi Tom, On Thu, Dec 28, 2023 at 3:54 PM Tom Rini wrote: > > On Thu, Dec 28, 2023 at 03:09:12PM +, Simon Glass wrote: > > Hi Tom, Sumit, > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini wrote: > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +, Simon Glass wrote: > > > > Hi Sumit, > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg > > > > wrote: > > > > > > > > > > Allow platform owners to mirror devicetree files from > > > > > devitree-rebasing > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). > > > > > Then > > > > > build then along with any *-u-boot.dtsi file present in > > > > > arch/$(ARCH)/dts > > > > > directory. Also add a new Makefile for arm64. > > > > > > > > > > This will help easy migration for platforms which currently are > > > > > compliant > > > > > with upstream Linux kernel devicetree files. > > > > > > > > > > Signed-off-by: Sumit Garg > > > > > --- > > > > > > > > > > Changes in v3: > > > > > -- > > > > > - Minor commit message update > > > > > > > > > > Changes in v2: > > > > > -- > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > > > > > dts/Kconfig | 11 +++ > > > > > dts/Makefile| 17 ++--- > > > > > dts/arch/arm64/Makefile | 14 ++ > > > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > > > --- a/dts/Kconfig > > > > > +++ b/dts/Kconfig > > > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > > > enables a live tree which is available after relocation, > > > > > and can be adjusted as needed. > > > > > > > > > > +config OF_UPSTREAM > > > > > + bool "Enable use of devicetree imported from Linux kernel > > > > > release" > > > > > + help > > > > > + Traditionally, U-Boot platforms used to have their custom > > > > > devicetree > > > > > + files or copy devicetree files from Linux kernel which are > > > > > hard to > > > > > + maintain and can usually get out-of-sync from Linux kernel. > > > > > This > > > > > + option enables platforms to migrate to devicetree-rebasing > > > > > repo where > > > > > + a regular sync will be maintained every major Linux kernel > > > > > release > > > > > + cycle. However, platforms can still have some custom u-boot > > > > > specific > > > > > + bits maintained as part of *-u-boot.dtsi files. > > > > > > > > My only other suggestion here is to mention that this should be set in > > > > Kconfig, for the SoC as a whole. So I believe that means that it > > > > should be hidden, with no string for the 'bool': > > > > > > > > bool # Enable use of devicetree imported from Linux kernel > > > > release > > > > > > I think we can just keep prompting for it now, to make the transition > > > easier, before this option just goes away in time, hopefully. > > > > > > > Also, this doesn't seem to work for me. Before this series I get these > > > > files when building firefly-rk3399: > > > > > > > > rk3399-eaidk-610.dtbrk3399-khadas-edge-v.dtb > > > > rk3399-orangepi.dtbrk3399-rock-pi-4a.dtb > > > > rk3399-evb.dtb rk3399-leez-p710.dtb > > > > rk3399-pinebook-pro.dtbrk3399-rock-pi-4c.dtb > > > > rk3399-ficus.dtbrk3399-nanopc-t4.dtb > > > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > > > rk3399-gru-kevin.dtbrk3399-nanopi-m4.dtb > > > > rk3399-rock-4c-plus.dtb > > > > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb > > > > rk3399-rock-4se.dtb > > > > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb > > > > rk3399-rock960.dtb > > > > > > > > Afterwards I get this: > > > > > > > > make[3]: *** No rule to make target > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > So I set this manually for that one board: > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > > > > > > > and get: > > > > > > > > make[3]: *** No rule to make target > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > > > I am not sure how to fix this, nor how this can be made to build all > > > > the DTs for rk3399, as it does today. > > > > > > Looking at the patch for amlogic boards, you need to make the link to > > > devicetree-rebasing inside dts/... > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even > > with the link. > > > > Using odroid-c2 with -next I see: > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > > meson-a1-ad401.dtb
Re: [PATCH 5/5] test: unit test for smbios command
Hi Heinrich, On Thu, Dec 28, 2023 at 5:11 PM Heinrich Schuchardt wrote: > > > > Am 27. Dezember 2023 08:40:40 MEZ schrieb Simon Glass : > >Hi Heinrich, > > > >On Tue, Dec 26, 2023 at 10:11 AM Heinrich Schuchardt > >wrote: > >> > >> On 12/26/23 10:47, Simon Glass wrote: > >> > Hi Heinrich, > >> > > >> > On Sat, Dec 23, 2023 at 12:49 AM Heinrich Schuchardt > >> > wrote: > >> >> > >> >> Provide a unit test for the smbios command. > >> >> > >> >> Provide different test functions for QEMU, sandbox, and other systems. > >> >> > >> >> Signed-off-by: Heinrich Schuchardt > >> >> --- > >> >> test/py/tests/test_smbios.py | 47 > >> >> 1 file changed, 47 insertions(+) > >> >> create mode 100644 test/py/tests/test_smbios.py > >> > > >> > Can you please write this test in C? > >> > > >> > Regards, > >> > Simon > >> > >> According to our documentation we can use either Python or C tests. > >> We generally use Python tests for testing the CLI. > > > >Not really...there are lots of C tests for the CLI. It is actually > >easier to code, in most cases. > > > >> > >> I cannot see any benefit in trying to write this in C. > > > >I did go to some effort to document this: > > > >https://docs.u-boot.org/en/latest/develop/tests_writing.html#test-types > > As described in that document C is most adequate for testing on the sandbox. > I want to run this test on QEMU and real boards with release U-Boot firmware, > i.e. without deviating configuration. Are you checking that the compiler works? Most such tests are a waste of time, IMO. Anyway, any test is better than no test, as Tom says, so: Reviewed-by: Simon Glass Regards, SImon
Re: [PATCH v4 7/7] smbios: Require the caller to align the SMBIOS table
Hi Heinrich, On Thu, Dec 28, 2023 at 5:36 PM Heinrich Schuchardt wrote: > > > > Am 28. Dezember 2023 14:37:19 MEZ schrieb Simon Glass : > >Hi Ilias, > > > >On Wed, Dec 27, 2023 at 11:12 AM Ilias Apalodimas > > wrote: > >> > >> Hi Simon, > >> > >> I commented on v3 as well, but in case you miss that > >> > >> On Wed, 27 Dec 2023 at 09:40, Simon Glass wrote: > >> > > >> > All callers handle this alignment, so drop the unnecessary code. This > >> > simplifies things a little. > >> > > >> > Signed-off-by: Simon Glass > >> > Reviewed-by: Heinrich Schuchardt > >> > --- > >> > > >> > (no changes since v1) > >> > > >> > include/smbios.h | 5 + > >> > lib/smbios.c | 2 -- > >> > 2 files changed, 1 insertion(+), 6 deletions(-) > >> > > >> > diff --git a/include/smbios.h b/include/smbios.h > >> > index 77be58887a2..879b8a814b8 100644 > >> > --- a/include/smbios.h > >> > +++ b/include/smbios.h > >> > @@ -258,12 +258,9 @@ static inline void fill_smbios_header(void *table, > >> > int type, > >> > * > >> > * This writes SMBIOS table at a given address. > >> > * > >> > - * @addr: start address to write SMBIOS table. If this is not > >> > - * 16-byte-aligned then it will be aligned before the table > >> > is > >> > - * written. > >> > + * @addr: start address to write SMBIOS table (must be > >> > 16-byte-aligned) > >> > * Return: end address of SMBIOS table (and start address for next > >> > entry) > >> > * or NULL in case of an error > >> > - * > >> > */ > >> > ulong write_smbios_table(ulong addr); > >> > > >> > diff --git a/lib/smbios.c b/lib/smbios.c > >> > index 7f79d969c92..cfd451e4088 100644 > >> > --- a/lib/smbios.c > >> > +++ b/lib/smbios.c > >> > @@ -563,8 +563,6 @@ ulong write_smbios_table(ulong addr) > >> > ctx.dev = NULL; > >> > } > >> > > >> > - /* 16 byte align the table address */ > >> > - addr = ALIGN(addr, 16); > >> > >> I think this is wrong. It will break SMBIOS on a user error. I am > >> fine replacing that with a check instead and error out if the address > >> is not 16b aligned > > > >Well this is why the comment says it must be aligned. This function is > >not called willy nilly,from code we control. Checking for alignment > >at runtime creates confusion and adds to code size. > > The SMBIOS tables themself have no alignment requirement. Only on non UEFI > x86 system presenting a UEFI entry point in the range 000Fh to 000Fh > this copy of the entry point has to be 16 byte aligned. OK. So perhaps I should reword the comment to say that any arch-specific alignment must be respected by the caller? Regards, Simon
[PATCH v6] fdt: Allow the devicetree to come from a bloblist
Standard passage provides for a bloblist to be passed from one firmware
phase to the next. That can be used to pass the devicetree along as well.
Add an option to support this.
Tests for this will be added as part of the Universal Payload work.
Signed-off-by: Simon Glass
---
The discussion on this was not resolved and is now important due to the
bloblist series from Raymond. So I am sending it again since I believe
this is a better starting point than building on OF_BOARD
Changes in v6:
- Don't allow bloblist with OF_EMBED
Changes in v5:
- Make OF_BLOBLIST default y
- Make OF_BLOBLIST optional at runtime
Changes in v4:
- Rebase to -next
common/bloblist.c | 1 +
doc/develop/devicetree/control.rst | 3 ++
dts/Kconfig| 13 +
include/bloblist.h | 5
include/fdtdec.h | 6 ++--
lib/fdtdec.c | 44 +++---
6 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/common/bloblist.c b/common/bloblist.c
index a22f6c12b0c..b07ede11cfe 100644
--- a/common/bloblist.c
+++ b/common/bloblist.c
@@ -48,6 +48,7 @@ static struct tag_name {
{ BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
{ BLOBLISTT_SMBIOS_TABLES, "SMBIOS tables for x86" },
{ BLOBLISTT_VBOOT_CTX, "Chrome OS vboot context" },
+ { BLOBLISTT_CONTROL_FDT, "Control FDT" },
/* BLOBLISTT_PROJECT_AREA */
{ BLOBLISTT_U_BOOT_SPL_HANDOFF, "SPL hand-off" },
diff --git a/doc/develop/devicetree/control.rst
b/doc/develop/devicetree/control.rst
index cbb65c9b177..444c55de4e4 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -108,6 +108,9 @@ If CONFIG_OF_BOARD is defined, a board-specific routine
will provide the
devicetree at runtime, for example if an earlier bootloader stage creates
it and passes it to U-Boot.
+If CONFIG_OF_BLOBLIST is defined, the devicetree comes from a bloblist passed
+from a previous stage, if present.
+
If CONFIG_SANDBOX is defined, then it will be read from a file on
startup. Use the -d flag to U-Boot to specify the file to read, -D for the
default and -T for the test devicetree, used to run sandbox unit tests.
diff --git a/dts/Kconfig b/dts/Kconfig
index 00c0aeff893..ae451b9caf7 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -105,6 +105,19 @@ config OF_EMBED
endchoice
+config OF_BLOBLIST
+ bool "Provided by a bloblist at runtime"
+ depends on BLOBLIST && OF_SEPARATE
+ default y
+ help
+ Select this to read the devicetree from the bloblist. This allows
+ using a bloblist to transfer the devicetree between U-Boot phases.
+ The devicetree is stored in the bloblist by an early phase so that
+ U-Boot can read it.
+
+ If the bloblist does not contain a devicetree, then other methods will
+ be used.
+
config OF_BOARD
bool "Provided by the board (e.g a previous loader) at runtime"
default y if SANDBOX || OF_HAS_PRIOR_STAGE
diff --git a/include/bloblist.h b/include/bloblist.h
index 080cc46a126..e16d122f4fb 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -103,6 +103,11 @@ enum bloblist_tag_t {
BLOBLISTT_ACPI_TABLES = 0x104, /* ACPI tables for x86 */
BLOBLISTT_SMBIOS_TABLES = 0x105, /* SMBIOS tables for x86 */
BLOBLISTT_VBOOT_CTX = 0x106,/* Chromium OS verified boot context */
+ /*
+* Devicetree for use by firmware. On some platforms this is passed to
+* the OS also
+*/
+ BLOBLISTT_CONTROL_FDT = 0x107,
/*
* Project-specific tags are permitted here. Projects can be open source
diff --git a/include/fdtdec.h b/include/fdtdec.h
index bd1149f46d0..e80de24076c 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -72,7 +72,7 @@ struct bd_info;
* U-Boot is packaged as an ELF file, e.g. for debugging purposes
* @FDTSRC_ENV: Provided by the fdtcontroladdr environment variable. This
should
* be used for debugging/development only
- * @FDTSRC_NONE: No devicetree at all
+ * @FDTSRC_BLOBLIST: Provided by a bloblist from an earlier phase
*/
enum fdt_source_t {
FDTSRC_SEPARATE,
@@ -80,6 +80,7 @@ enum fdt_source_t {
FDTSRC_BOARD,
FDTSRC_EMBED,
FDTSRC_ENV,
+ FDTSRC_BLOBLIST,
};
/*
@@ -1190,7 +1191,8 @@ int fdtdec_resetup(int *rescan);
*
* The existing devicetree is available at gd->fdt_blob
*
- * @err internal error code if we fail to setup a DTB
+ * @err: 0 on success, -EEXIST if the devicetree is already correct, or other
+ * internal error code if we fail to setup a DTB
* @returns new devicetree blob pointer
*/
void *board_fdt_blob_setup(int *err);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 4016bf3c113..af3026dd42b 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -7,6 +7,10 @@
*/
#ifndef USE_HOSTCC
+
+#define LOG_CATEGORY LOGC_DT
+
+#include
#include
[PATCH v6 6/6] fastboot: add oem console command support
From: Ion Agorria
"oem console" serves to read console record buffer.
Signed-off-by: Ion Agorria
Signed-off-by: Svyatoslav Ryhel
Reviewed-by: Mattijs Korpershoek
---
doc/android/fastboot.rst | 1 +
drivers/fastboot/Kconfig | 7 +++
drivers/fastboot/fb_command.c | 39 +++
include/fastboot.h| 1 +
4 files changed, 48 insertions(+)
diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
index 1ad8a897c8..05d8f77759 100644
--- a/doc/android/fastboot.rst
+++ b/doc/android/fastboot.rst
@@ -29,6 +29,7 @@ The following OEM commands are supported (if enabled):
with = boot_ack boot_partition
- ``oem bootbus`` - this executes ``mmc bootbus %x %s`` to configure eMMC
- ``oem run`` - this executes an arbitrary U-Boot command
+- ``oem console`` - this dumps U-Boot console record buffer
Support for both eMMC and NAND devices is included.
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index 11fc0fe1c8..5e5855a76c 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -242,6 +242,13 @@ config FASTBOOT_OEM_RUN
this feature if you are using verified boot, as it will allow an
attacker to bypass any restrictions you have in place.
+config FASTBOOT_CMD_OEM_CONSOLE
+ bool "Enable the 'oem console' command"
+ depends on CONSOLE_RECORD
+ help
+ Add support for the "oem console" command to input and read console
+ record buffer.
+
endif # FASTBOOT
endmenu
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 6f621df074..f95f4e4ae1 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -41,6 +41,7 @@ static void reboot_recovery(char *, char *);
static void oem_format(char *, char *);
static void oem_partconf(char *, char *);
static void oem_bootbus(char *, char *);
+static void oem_console(char *, char *);
static void run_ucmd(char *, char *);
static void run_acmd(char *, char *);
@@ -108,6 +109,10 @@ static const struct {
.command = "oem run",
.dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_RUN, (run_ucmd),
(NULL))
},
+ [FASTBOOT_COMMAND_OEM_CONSOLE] = {
+ .command = "oem console",
+ .dispatch = CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_CONSOLE,
(oem_console), (NULL))
+ },
[FASTBOOT_COMMAND_UCMD] = {
.command = "UCmd",
.dispatch = CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT, (run_ucmd),
(NULL))
@@ -159,6 +164,23 @@ void fastboot_multiresponse(int cmd, char *response)
case FASTBOOT_COMMAND_GETVAR:
fastboot_getvar_all(response);
break;
+ case FASTBOOT_COMMAND_OEM_CONSOLE:
+ if (CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_CONSOLE)) {
+ char buf[FASTBOOT_RESPONSE_LEN] = { 0 };
+
+ if (console_record_isempty()) {
+ console_record_reset();
+ fastboot_okay(NULL, response);
+ } else {
+ int ret = console_record_readline(buf,
sizeof(buf) - 5);
+
+ if (ret < 0)
+ fastboot_fail("Error reading console",
response);
+ else
+ fastboot_response("INFO", response,
"%s", buf);
+ }
+ break;
+ }
default:
fastboot_fail("Unknown multiresponse command", response);
break;
@@ -503,3 +525,20 @@ static void __maybe_unused oem_bootbus(char
*cmd_parameter, char *response)
else
fastboot_okay(NULL, response);
}
+
+/**
+ * oem_console() - Execute the OEM console command
+ *
+ * @cmd_parameter: Pointer to command parameter
+ * @response: Pointer to fastboot response buffer
+ */
+static void __maybe_unused oem_console(char *cmd_parameter, char *response)
+{
+ if (cmd_parameter)
+ console_in_puts(cmd_parameter);
+
+ if (console_record_isempty())
+ fastboot_fail("Empty console", response);
+ else
+ fastboot_response(FASTBOOT_MULTIRESPONSE_START, response, NULL);
+}
diff --git a/include/fastboot.h b/include/fastboot.h
index 59cbea61ec..1e7920eb91 100644
--- a/include/fastboot.h
+++ b/include/fastboot.h
@@ -47,6 +47,7 @@ enum {
FASTBOOT_COMMAND_OEM_PARTCONF,
FASTBOOT_COMMAND_OEM_BOOTBUS,
FASTBOOT_COMMAND_OEM_RUN,
+ FASTBOOT_COMMAND_OEM_CONSOLE,
FASTBOOT_COMMAND_ACMD,
FASTBOOT_COMMAND_UCMD,
FASTBOOT_COMMAND_COUNT
--
2.40.1
[PATCH v6 5/6] lib: membuff: fix readline not returning line in case of overflow
From: Ion Agorria
If line overflows readline it will not be returned, fix this behavior,
make it optional and documented properly.
Signed-off-by: Ion Agorria
Signed-off-by: Svyatoslav Ryhel
Reviewed-by: Mattijs Korpershoek
Reviewed-by: Simon Glass
---
boot/bootmeth_extlinux.c | 2 +-
common/console.c | 2 +-
include/membuff.h| 5 +++--
lib/membuff.c| 4 ++--
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/boot/bootmeth_extlinux.c b/boot/bootmeth_extlinux.c
index aa2a4591eb..ae0ad1d53e 100644
--- a/boot/bootmeth_extlinux.c
+++ b/boot/bootmeth_extlinux.c
@@ -82,7 +82,7 @@ static int extlinux_fill_info(struct bootflow *bflow)
log_debug("parsing bflow file size %x\n", bflow->size);
membuff_init(, bflow->buf, bflow->size);
membuff_putraw(, bflow->size, true, );
- while (len = membuff_readline(, line, sizeof(line) - 1, ' '), len) {
+ while (len = membuff_readline(, line, sizeof(line) - 1, ' ', true),
len) {
char *tok, *p = line;
tok = strsep(, " ");
diff --git a/common/console.c b/common/console.c
index e6d7ebe935..cad65891fc 100644
--- a/common/console.c
+++ b/common/console.c
@@ -848,7 +848,7 @@ int console_record_readline(char *str, int maxlen)
return -ENOSPC;
return membuff_readline((struct membuff *)>console_out, str,
- maxlen, '\0');
+ maxlen, '\0', false);
}
int console_record_avail(void)
diff --git a/include/membuff.h b/include/membuff.h
index 21051b0c54..4eba626ce1 100644
--- a/include/membuff.h
+++ b/include/membuff.h
@@ -192,10 +192,11 @@ int membuff_free(struct membuff *mb);
* @mb: membuff to adjust
* @str: Place to put the line
* @maxlen: Maximum line length (excluding terminator)
+ * @must_fit: If true then str is empty if line doesn't fit
* Return: number of bytes read (including terminator) if a line has been
- *read, 0 if nothing was there
+ *read, 0 if nothing was there or line didn't fit when must_fit is set
*/
-int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch);
+int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch,
bool must_fit);
/**
* membuff_extend_by() - expand a membuff
diff --git a/lib/membuff.c b/lib/membuff.c
index 3c6c0ae125..b242a38ff1 100644
--- a/lib/membuff.c
+++ b/lib/membuff.c
@@ -287,7 +287,7 @@ int membuff_free(struct membuff *mb)
(mb->end - mb->start) - 1 - membuff_avail(mb);
}
-int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch)
+int membuff_readline(struct membuff *mb, char *str, int maxlen, int minch,
bool must_fit)
{
int len; /* number of bytes read (!= string length) */
char *s, *end;
@@ -309,7 +309,7 @@ int membuff_readline(struct membuff *mb, char *str, int
maxlen, int minch)
}
/* couldn't get the whole string */
- if (!ok) {
+ if (!ok && must_fit) {
if (maxlen)
*orig = '\0';
return 0;
--
2.40.1
[PATCH v6 4/6] common: console: record console from the beginning
From: Ion Agorria Set flag to enable console record on console_record_init and not only on console_record_reset_enable. This fixes missing start of U-Boot log for fastboot oem console command. Signed-off-by: Ion Agorria Signed-off-by: Svyatoslav Ryhel Reviewed-by: Mattijs Korpershoek --- common/console.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/console.c b/common/console.c index 6f2089caa0..e6d7ebe935 100644 --- a/common/console.c +++ b/common/console.c @@ -821,6 +821,9 @@ int console_record_init(void) ret = membuff_new((struct membuff *)>console_in, CONFIG_CONSOLE_RECORD_IN_SIZE); + /* Start recording from the beginning */ + gd->flags |= GD_FLG_RECORD; + return ret; } -- 2.40.1
[PATCH v6 3/6] common: console: introduce console_record_isempty helper
From: Ion Agorria
Add console_record_isempty to check if console record buffer
contains any data.
Signed-off-by: Ion Agorria
Signed-off-by: Svyatoslav Ryhel
Reviewed-by: Mattijs Korpershoek
---
common/console.c | 5 +
include/console.h | 13 +
2 files changed, 18 insertions(+)
diff --git a/common/console.c b/common/console.c
index 1ffda49c87..6f2089caa0 100644
--- a/common/console.c
+++ b/common/console.c
@@ -853,6 +853,11 @@ int console_record_avail(void)
return membuff_avail((struct membuff *)>console_out);
}
+bool console_record_isempty(void)
+{
+ return membuff_isempty((struct membuff *)>console_out);
+}
+
int console_in_puts(const char *str)
{
return membuff_put((struct membuff *)>console_in, str, strlen(str));
diff --git a/include/console.h b/include/console.h
index e29817e57b..2617e16007 100644
--- a/include/console.h
+++ b/include/console.h
@@ -84,6 +84,13 @@ int console_record_readline(char *str, int maxlen);
*/
int console_record_avail(void);
+/**
+ * console_record_isempty() - Returns if console output is empty
+ *
+ * Return: true if empty
+ */
+bool console_record_isempty(void);
+
/**
* console_in_puts() - Write a string to the console input buffer
*
@@ -131,6 +138,12 @@ static inline int console_in_puts(const char *str)
return 0;
}
+static inline bool console_record_isempty(void)
+{
+ /* Always empty */
+ return true;
+}
+
#endif /* !CONFIG_CONSOLE_RECORD */
/**
--
2.40.1
[PATCH v6 2/6] fastboot: implement "getvar all"
From: Ion Agorria
This commit implements "fastboot getvar all" listing
by iterating the existing dispatchers that don't require
parameters (as we pass NULL), uses fastboot multiresponse.
Signed-off-by: Ion Agorria
Signed-off-by: Svyatoslav Ryhel
Reviewed-by: Mattijs Korpershoek
---
doc/android/fastboot-protocol.rst | 3 ++
drivers/fastboot/fb_command.c | 3 ++
drivers/fastboot/fb_getvar.c | 77 +--
include/fastboot-internal.h | 7 +++
4 files changed, 77 insertions(+), 13 deletions(-)
diff --git a/doc/android/fastboot-protocol.rst
b/doc/android/fastboot-protocol.rst
index e8cbd7f24e..8bd6d7168f 100644
--- a/doc/android/fastboot-protocol.rst
+++ b/doc/android/fastboot-protocol.rst
@@ -173,6 +173,9 @@ The various currently defined names are::
bootloader requiring a signature before
it will install or boot images.
+ all Provides all info from commands above as
+ they were called one by one
+
Names starting with a lowercase character are reserved by this
specification. OEM-specific names should not start with lowercase
characters.
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index ab72d8c781..6f621df074 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -156,6 +156,9 @@ int fastboot_handle_command(char *cmd_string, char
*response)
void fastboot_multiresponse(int cmd, char *response)
{
switch (cmd) {
+ case FASTBOOT_COMMAND_GETVAR:
+ fastboot_getvar_all(response);
+ break;
default:
fastboot_fail("Unknown multiresponse command", response);
break;
diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
index 8cb8ffa2c6..f65519c57b 100644
--- a/drivers/fastboot/fb_getvar.c
+++ b/drivers/fastboot/fb_getvar.c
@@ -29,53 +29,67 @@ static void getvar_is_userspace(char *var_parameter, char
*response);
static const struct {
const char *variable;
+ bool list;
void (*dispatch)(char *var_parameter, char *response);
} getvar_dispatch[] = {
{
.variable = "version",
- .dispatch = getvar_version
+ .dispatch = getvar_version,
+ .list = true,
}, {
.variable = "version-bootloader",
- .dispatch = getvar_version_bootloader
+ .dispatch = getvar_version_bootloader,
+ .list = true
}, {
.variable = "downloadsize",
- .dispatch = getvar_downloadsize
+ .dispatch = getvar_downloadsize,
+ .list = true
}, {
.variable = "max-download-size",
- .dispatch = getvar_downloadsize
+ .dispatch = getvar_downloadsize,
+ .list = true
}, {
.variable = "serialno",
- .dispatch = getvar_serialno
+ .dispatch = getvar_serialno,
+ .list = true
}, {
.variable = "version-baseband",
- .dispatch = getvar_version_baseband
+ .dispatch = getvar_version_baseband,
+ .list = true
}, {
.variable = "product",
- .dispatch = getvar_product
+ .dispatch = getvar_product,
+ .list = true
}, {
.variable = "platform",
- .dispatch = getvar_platform
+ .dispatch = getvar_platform,
+ .list = true
}, {
.variable = "current-slot",
- .dispatch = getvar_current_slot
+ .dispatch = getvar_current_slot,
+ .list = true
#if IS_ENABLED(CONFIG_FASTBOOT_FLASH)
}, {
.variable = "has-slot",
- .dispatch = getvar_has_slot
+ .dispatch = getvar_has_slot,
+ .list = false
#endif
#if IS_ENABLED(CONFIG_FASTBOOT_FLASH_MMC)
}, {
.variable = "partition-type",
- .dispatch = getvar_partition_type
+ .dispatch = getvar_partition_type,
+ .list = false
#endif
#if IS_ENABLED(CONFIG_FASTBOOT_FLASH)
}, {
.variable = "partition-size",
- .dispatch = getvar_partition_size
+ .dispatch = getvar_partition_size,
+ .list = false
#endif
}, {
.variable = "is-userspace",
- .dispatch = getvar_is_userspace
+ .dispatch = getvar_is_userspace,
+ .list = true
}
};
@@ -237,6 +251,40 @@ static void getvar_is_userspace(char *var_parameter, char
*response)
fastboot_okay("no", response);
}
+static int current_all_dispatch;
+void fastboot_getvar_all(char *response)
+{
+ /*
+* Find a dispatch getvar that can be listed and send
+
[PATCH v6 1/6] fastboot: multiresponse support
From: Ion Agorria
Currently u-boot fastboot can only send one message back to host,
so if there is a need to print more than one line messages must be
kept sending until all the required data is obtained. This behavior
can be adjusted using multiresponce ability (getting multiple lines
of response) proposed in this patch.
Signed-off-by: Ion Agorria
Signed-off-by: Svyatoslav Ryhel
Reviewed-by: Mattijs Korpershoek
---
drivers/fastboot/fb_command.c | 10 ++
drivers/usb/gadget/f_fastboot.c | 29 +
include/fastboot.h | 18 ++
net/fastboot_udp.c | 29 +++--
4 files changed, 80 insertions(+), 6 deletions(-)
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 5fcadcdf50..ab72d8c781 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -152,6 +153,15 @@ int fastboot_handle_command(char *cmd_string, char
*response)
return -1;
}
+void fastboot_multiresponse(int cmd, char *response)
+{
+ switch (cmd) {
+ default:
+ fastboot_fail("Unknown multiresponse command", response);
+ break;
+ }
+}
+
/**
* okay() - Send bare OKAY response
*
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 9f322c9550..09e740cc96 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -497,6 +497,25 @@ static void do_bootm_on_complete(struct usb_ep *ep, struct
usb_request *req)
do_exit_on_complete(ep, req);
}
+static int multiresponse_cmd = -1;
+static void multiresponse_on_complete(struct usb_ep *ep, struct usb_request
*req)
+{
+ char response[FASTBOOT_RESPONSE_LEN] = {0};
+
+ if (multiresponse_cmd == -1)
+ return;
+
+ /* Call handler to obtain next response */
+ fastboot_multiresponse(multiresponse_cmd, response);
+ fastboot_tx_write_str(response);
+
+ /* If response is final OKAY/FAIL response disconnect this handler and
unset cmd */
+ if (!strncmp("OKAY", response, 4) || !strncmp("FAIL", response, 4)) {
+ multiresponse_cmd = -1;
+ fastboot_func->in_req->complete = fastboot_complete;
+ }
+}
+
static void do_acmd_complete(struct usb_ep *ep, struct usb_request *req)
{
/* When usb dequeue complete will be called
@@ -524,6 +543,16 @@ static void rx_handler_command(struct usb_ep *ep, struct
usb_request *req)
fastboot_fail("buffer overflow", response);
}
+ if (!strncmp(FASTBOOT_MULTIRESPONSE_START, response, 4)) {
+ multiresponse_cmd = cmd;
+ fastboot_multiresponse(multiresponse_cmd, response);
+
+ /* Only add complete callback if first is not a final OKAY/FAIL
response */
+ if (strncmp("OKAY", response, 4) && strncmp("FAIL", response,
4)) {
+ fastboot_func->in_req->complete =
multiresponse_on_complete;
+ }
+ }
+
if (!strncmp("DATA", response, 4)) {
req->complete = rx_handler_dl_image;
req->length = rx_bytes_expected(ep);
diff --git a/include/fastboot.h b/include/fastboot.h
index 296451f89d..59cbea61ec 100644
--- a/include/fastboot.h
+++ b/include/fastboot.h
@@ -14,6 +14,16 @@
#define FASTBOOT_VERSION "0.4"
+/*
+ * Signals u-boot fastboot code to send multiple responses by
+ * calling response generating function repeatedly until a OKAY/FAIL
+ * is generated as final response.
+ *
+ * This status code is only used internally to signal, must NOT
+ * be sent to host.
+ */
+#define FASTBOOT_MULTIRESPONSE_START ("MORE")
+
/* The 64 defined bytes plus \0 */
#define FASTBOOT_COMMAND_LEN (64 + 1)
#define FASTBOOT_RESPONSE_LEN (64 + 1)
@@ -172,5 +182,13 @@ void fastboot_data_download(const void *fastboot_data,
*/
void fastboot_data_complete(char *response);
+/**
+ * fastboot_handle_multiresponse() - Called for each response to send
+ *
+ * @cmd: Command id that requested multiresponse
+ * @response: Pointer to fastboot response buffer
+ */
+void fastboot_multiresponse(int cmd, char *response);
+
void fastboot_acmd_complete(void);
#endif /* _FASTBOOT_H_ */
diff --git a/net/fastboot_udp.c b/net/fastboot_udp.c
index d690787478..6fee441ab3 100644
--- a/net/fastboot_udp.c
+++ b/net/fastboot_udp.c
@@ -42,16 +42,15 @@ static int fastboot_remote_port;
static int fastboot_our_port;
/**
- * fastboot_udp_send_info() - Send an INFO packet during long commands.
+ * fastboot_udp_send_response() - Send an response into UDP
*
- * @msg: String describing the reason for waiting
+ * @response: Response to send
*/
-static void fastboot_udp_send_info(const char *msg)
+static void fastboot_udp_send_response(const char *response)
{
uchar *packet;
uchar *packet_base;
[PATCH v6 0/6] Implement fastboot multiresponce
Currently u-boot fastboot can only send one message back to host, so if there is a need to print more than one line messages must be kept sending until all the required data is obtained. This behavior can be adjusted using multiresponce ability (getting multiple lines of response) proposed in this patch set. Implementation of multiresponce leads to ability to dump content of console buffer which, with use of "oem run", allows to entirely avoid need in UART. --- Changes in v6: - remove prev console changes - add console_record_isempty helper - set record flag on init Changes in v5: - restored membuff_readline behavior changed in v4 Changes in v4: - adjust membuff_readline behavior with overflow Changes in v3: - fix missing function calls if CONFIG_CONSOLE_RECORD is not enabled Changes in v2: - changed variables to static - fixed multiresponce for udp - documented use of "MORE" - converted #if to if (...) --- Ion Agorria (6): fastboot: multiresponse support fastboot: implement "getvar all" common: console: introduce console_record_isempty helper common: console: record console from the beginning lib: membuff: fix readline not returning line in case of overflow fastboot: add oem console command support boot/bootmeth_extlinux.c | 2 +- common/console.c | 10 +++- doc/android/fastboot-protocol.rst | 3 ++ doc/android/fastboot.rst | 1 + drivers/fastboot/Kconfig | 7 +++ drivers/fastboot/fb_command.c | 52 + drivers/fastboot/fb_getvar.c | 77 +-- drivers/usb/gadget/f_fastboot.c | 29 include/console.h | 13 ++ include/fastboot-internal.h | 7 +++ include/fastboot.h| 19 include/membuff.h | 5 +- lib/membuff.c | 4 +- net/fastboot_udp.c| 29 +--- 14 files changed, 233 insertions(+), 25 deletions(-) -- 2.40.1
Re: [PATCH v4 4/7] smbios: Use SMBIOS 3.0 to support an address above 4GB
On Thu, Dec 28, 2023 at 03:46:09PM +0100, Mark Kettenis wrote: > > From: Simon Glass > > Date: Thu, 28 Dec 2023 13:37:03 + > > > > Hi Ilias, > > > > On Wed, Dec 27, 2023 at 11:05 AM Ilias Apalodimas > > wrote: > > > > > > Hi Simon, > > > > > > On Wed, 27 Dec 2023 at 09:40, Simon Glass wrote: > > > > > > > > When the SMBIOS table is written to an address above 4GB a 32-bit table > > > > address is not large enough. > > > > > > > > Use an SMBIOS3 table in that case. > > > > > > Maybe I missed this on the previous revisions, but is there a reason > > > we don't always use SMBIOS3 now? > > > > I am not sure...there was some comment about it not being supported in > > some cases, so I have tried to accommodate that. > > > > > And perhaps try to install SMBIOS2 if > > > 1. we fail > > > > due to? > > > > > 2. and the address is < 4GB > > > > We could, I suppose. Effectively we would drop generation of SMBIOS2. > > > > I really don't mind. This whole SMBIOS thing is a bit ridiculous, if > > you ask me. > > Linux added support for the SMBIOS 3.0 64-bit entry point in 2014. I > doubt anyone who cares about SMBIOS cares about kernels that old. > > So if it simplifies things, I'd drop support for the 32-bit SMBIOS > entry point. I agree, lets just provide SMBIOS3 tables. -- Tom signature.asc Description: PGP signature
Re: Regression: i.MX6ULL reset not working
On Thu, Dec 28, 2023 at 2:23 PM Francesco Dolcini wrote: > Are you sure? After the related kconfig changes you'll have CONFIG_WDT > enabled, and with that the watchdog is started and you need to > periodically refresh it. At the moment the watchdog is not enabled at > boot and it is used only for the reset. Ok, I understand now what you mean. > While the change might be fine, my concern is that this might affect some use > cases. Debugging? Kernel not having the watchdog driver enabled? Any > other fancy use-case? I am not aware of issues in this area. imx8m boards handle the watchdog via CONFIG_WDT and I haven't seen problems with that.
Re: [PATCH v4 7/7] smbios: Require the caller to align the SMBIOS table
Am 28. Dezember 2023 14:37:19 MEZ schrieb Simon Glass : >Hi Ilias, > >On Wed, Dec 27, 2023 at 11:12 AM Ilias Apalodimas > wrote: >> >> Hi Simon, >> >> I commented on v3 as well, but in case you miss that >> >> On Wed, 27 Dec 2023 at 09:40, Simon Glass wrote: >> > >> > All callers handle this alignment, so drop the unnecessary code. This >> > simplifies things a little. >> > >> > Signed-off-by: Simon Glass >> > Reviewed-by: Heinrich Schuchardt >> > --- >> > >> > (no changes since v1) >> > >> > include/smbios.h | 5 + >> > lib/smbios.c | 2 -- >> > 2 files changed, 1 insertion(+), 6 deletions(-) >> > >> > diff --git a/include/smbios.h b/include/smbios.h >> > index 77be58887a2..879b8a814b8 100644 >> > --- a/include/smbios.h >> > +++ b/include/smbios.h >> > @@ -258,12 +258,9 @@ static inline void fill_smbios_header(void *table, >> > int type, >> > * >> > * This writes SMBIOS table at a given address. >> > * >> > - * @addr: start address to write SMBIOS table. If this is not >> > - * 16-byte-aligned then it will be aligned before the table is >> > - * written. >> > + * @addr: start address to write SMBIOS table (must be >> > 16-byte-aligned) >> > * Return: end address of SMBIOS table (and start address for next >> > entry) >> > * or NULL in case of an error >> > - * >> > */ >> > ulong write_smbios_table(ulong addr); >> > >> > diff --git a/lib/smbios.c b/lib/smbios.c >> > index 7f79d969c92..cfd451e4088 100644 >> > --- a/lib/smbios.c >> > +++ b/lib/smbios.c >> > @@ -563,8 +563,6 @@ ulong write_smbios_table(ulong addr) >> > ctx.dev = NULL; >> > } >> > >> > - /* 16 byte align the table address */ >> > - addr = ALIGN(addr, 16); >> >> I think this is wrong. It will break SMBIOS on a user error. I am >> fine replacing that with a check instead and error out if the address >> is not 16b aligned > >Well this is why the comment says it must be aligned. This function is >not called willy nilly, from code we control. Checking for alignment >at runtime creates confusion and adds to code size. The SMBIOS tables themself have no alignment requirement. Only on non UEFI x86 system presenting a UEFI entry point in the range 000Fh to 000Fh this copy of the entry point has to be 16 byte aligned. Best regards Heinrich > >> >> Thanks >> /Ilias >> > start_addr = addr; >> > >> > /* >> > -- >> > 2.34.1 >> > > >Regards, >Simon
Re: [PATCH 26/26] arm: dts: k3-am654: convert bootph-pre-ram to bootph-all
On December 27, 2023 thus sayeth Nishanth Menon:
> On 11:44-20231221, Bryan Brattlof wrote:
> [..]
> > diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> > b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> > index a9b2d0d2a3036..770c7d129339f 100644
> > --- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> > +++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> [...]
> > _uart0 {
> > - bootph-pre-ram;
> > + bootph-all;
> > };
>
> Consider moving this to r5 dts - there is no use in having this in
> u-boot. should be pre-ram?
>
> >
> > _uart0 {
> > - bootph-pre-ram;
> > + bootph-all;
> > };
> Same here:
> Consider moving this to r5 dts - there is no use in having this in
> u-boot. should be pre-ram?
>
Oh good idea. I'll move these to the r5 dts
~Bryan
Re: Regression: i.MX6ULL reset not working
On Thu, Dec 28, 2023 at 02:08:33PM -0300, Fabio Estevam wrote: > On Thu, Dec 28, 2023 at 1:46 PM Francesco Dolcini > wrote: > > > With that we would have to enable the watchdog, something that is not > > done today. Any potential downside on doing it? > > I don't see any. > > The watchdog was being used originally too, but not via DM. Are you sure? After the related kconfig changes you'll have CONFIG_WDT enabled, and with that the watchdog is started and you need to periodically refresh it. At the moment the watchdog is not enabled at boot and it is used only for the reset. While the change might be fine, my concern is that this might affect some use cases. Debugging? Kernel not having the watchdog driver enabled? Any other fancy use-case? Assuming I am not getting this all wrong, and enabling CONFIG_WDT has no real effects, please correct me if I'm wrong. Francesco
Re: [PATCH 5/5] test: unit test for smbios command
On Thu, Dec 28, 2023 at 06:06:23PM +0100, Heinrich Schuchardt wrote: > > > Am 27. Dezember 2023 08:40:40 MEZ schrieb Simon Glass : > >Hi Heinrich, > > > >On Tue, Dec 26, 2023 at 10:11 AM Heinrich Schuchardt > >wrote: > >> > >> On 12/26/23 10:47, Simon Glass wrote: > >> > Hi Heinrich, > >> > > >> > On Sat, Dec 23, 2023 at 12:49 AM Heinrich Schuchardt > >> > wrote: > >> >> > >> >> Provide a unit test for the smbios command. > >> >> > >> >> Provide different test functions for QEMU, sandbox, and other systems. > >> >> > >> >> Signed-off-by: Heinrich Schuchardt > >> >> --- > >> >> test/py/tests/test_smbios.py | 47 > >> >> 1 file changed, 47 insertions(+) > >> >> create mode 100644 test/py/tests/test_smbios.py > >> > > >> > Can you please write this test in C? > >> > > >> > Regards, > >> > Simon > >> > >> According to our documentation we can use either Python or C tests. > >> We generally use Python tests for testing the CLI. > > > >Not really...there are lots of C tests for the CLI. It is actually > >easier to code, in most cases. > > > >> > >> I cannot see any benefit in trying to write this in C. > > > >I did go to some effort to document this: > > > >https://docs.u-boot.org/en/latest/develop/tests_writing.html#test-types > > As described in that document C is most adequate for testing on the sandbox. > I want to run this test on QEMU and real boards with release U-Boot firmware, > i.e. without deviating configuration. The important part is that we have a test. And I really don't want to re-read too much of that doc right now as I feel like it gets things a bit wrong. -- Tom signature.asc Description: PGP signature
Re: [PATCH 12/26] arm: dts: k3-am654: add needed regs to udmap nodes
On December 27, 2023 thus sayeth Nishanth Menon:
> On 11:43-20231221, Bryan Brattlof wrote:
> > Ethernet is one of a few IPs in U-Boot that depend on DMA to operate.
> > However there are a few missing registers ranges in the udmap nodes
> > need to properly setup DMA for the am65x.
> >
> > A fix has been added to the Linux kernel[0] to add these ranges however
> > they have not made it to a Linux tag. To keep DMA operational until the
> > next DT sync from Linux, add these ranges to the *-u-boot.dtsi with a
> > note for our future selves.
> >
> > [0] https://lore.kernel.org/r/20231213135138.929517-2-vigne...@ti.com
> > Signed-off-by: Bryan Brattlof
> > ---
> > arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 32
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> > b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> > index 9cd8c353c515b..645241da322a5 100644
> > --- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> > +++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> > @@ -260,3 +260,35 @@
> > _r5fss0 {
> > ti,cluster-mode = <0>;
> > };
> > +
> > +/* The DMA driver requires a few extra register ranges
> > + * which are missing for the am65x. A patch has been
> > + * sent and will be synced after the v6.8-rc1 linux
> > + * tag is published
> > + */
>
> Please fix multi-line comment style:
> /*
> * blah blah
> */
> instead of
> /* blah blah
> * more stuff
> */
Ah yeah I can get all of the comments fixed up.
~Bryan
> > +_udmap {
> > + reg = <0x0 0x3115 0x0 0x100>,
> > + <0x0 0x3400 0x0 0x10>,
> > + <0x0 0x3500 0x0 0x10>,
> > + <0x0 0x30b0 0x0 0x1>,
> > + <0x0 0x30c0 0x0 0x1>,
> > + <0x0 0x30d0 0x0 0x8000>;
> > + reg-names = "gcfg", "rchanrt", "tchanrt",
> > + "tchan", "rchan", "rflow";
> > +};
> > +
> > +/* The DMA driver requires a few extra register ranges
> > + * which are missing for the am65x. A patch has been
> > + * sent and will be synced after the v6.8-rc1 linux
> > + * tag is published
> > + */
>
> and here.
>
> > +_udmap {
> > + reg = <0x0 0x285c 0x0 0x100>,
> > + <0x0 0x2a80 0x0 0x4>,
> > + <0x0 0x2aa0 0x0 0x4>,
> > + <0x0 0x284a 0x0 0x4000>,
> > + <0x0 0x284c 0x0 0x4000>,
> > + <0x0 0x2840 0x0 0x2000>;
> > + reg-names = "gcfg", "rchanrt", "tchanrt",
> > + "tchan", "rchan", "rflow";
> > +};
> > --
> > 2.43.0
> >
>
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
> 849D 1736 249D
Re: Regression: i.MX6ULL reset not working
On Thu, Dec 28, 2023 at 1:46 PM Francesco Dolcini wrote: > With that we would have to enable the watchdog, something that is not > done today. Any potential downside on doing it? I don't see any. The watchdog was being used originally too, but not via DM.
Re: [PATCH 5/5] test: unit test for smbios command
Am 27. Dezember 2023 08:40:40 MEZ schrieb Simon Glass : >Hi Heinrich, > >On Tue, Dec 26, 2023 at 10:11 AM Heinrich Schuchardt >wrote: >> >> On 12/26/23 10:47, Simon Glass wrote: >> > Hi Heinrich, >> > >> > On Sat, Dec 23, 2023 at 12:49 AM Heinrich Schuchardt >> > wrote: >> >> >> >> Provide a unit test for the smbios command. >> >> >> >> Provide different test functions for QEMU, sandbox, and other systems. >> >> >> >> Signed-off-by: Heinrich Schuchardt >> >> --- >> >> test/py/tests/test_smbios.py | 47 >> >> 1 file changed, 47 insertions(+) >> >> create mode 100644 test/py/tests/test_smbios.py >> > >> > Can you please write this test in C? >> > >> > Regards, >> > Simon >> >> According to our documentation we can use either Python or C tests. >> We generally use Python tests for testing the CLI. > >Not really...there are lots of C tests for the CLI. It is actually >easier to code, in most cases. > >> >> I cannot see any benefit in trying to write this in C. > >I did go to some effort to document this: > >https://docs.u-boot.org/en/latest/develop/tests_writing.html#test-types As described in that document C is most adequate for testing on the sandbox. I want to run this test on QEMU and real boards with release U-Boot firmware, i.e. without deviating configuration. Best regards Heinrich > >Regards, >Simon
Re: [PATCH] cmd: net: nfs: Enable the NFS command by default
On Thu, Dec 28, 2023 at 12:04:12PM +0530, Tejas Bhumkar wrote: > Activated the default use of NFS command for booting > images via network using the NFS protocol. > > Signed-off-by: Tejas Bhumkar > --- > cmd/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index df6d71c103..a51b2d532f 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -1905,6 +1905,7 @@ config CMD_RARP > > config CMD_NFS > bool "nfs" > + default y > help > Boot image via network using NFS protocol. NAK, this is basically a revert of: commit 10de1257079905ac383e7abf346a04221cafa620 Author: Peter Robinson Date: Wed Jun 14 15:41:10 2023 +0100 disable NFS support by default While NFS is widely used in data centres, and private networks it's quite a nuanced usecase for device firmware. A lot of devices already disable it. Various network protocols should really be opt in, not opt out, because they add extra size and are potential attack vectors from a security PoV. In the NFS case it doesn't really make sense for a lot of devices like tables, SBCs etc. It's also something we don't really want for SystemReady-IR due to security concerns. Signed-off-by: Peter Robinson Reviewed-by: Tom Rini Reviewed-by: Ilias Apalodimas So please enable this in the configs that you need this enabled in by default, thanks. -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] u-boot-riscv/next
On Thu, Dec 28, 2023 at 01:38:11PM +0800, Leo Liang wrote: > Hi Tom, > > The following changes since commit 4b151562bb8e54160adedbc6a1c0c749c00a2f84: > > bootmeth: pass size to efi_binary_run() (2023-12-22 10:36:50 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-riscv.git next > > for you to fetch changes up to 9924d44dbcd47bd3664fa9f1f9f24044d83eaebf: > > andes: ae350: Enable MISC_INIT_R for ae350 platform (2023-12-27 17:29:11 > +0800) > > CI result shows no issue: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/19106 Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 09/12] cmd: allow to enable CMD_NAND for SPI NAND devices
On 12/28/23 10:39, Alexey Romanov wrote: > Boards with SPI NAND also can use this command. > > Signed-off-by: Alexey Romanov > --- > cmd/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index c47523a03b..c8484576e2 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -1367,7 +1367,7 @@ config CMD_MUX > config CMD_NAND > bool "nand" > default y if NAND_SUNXI > - depends on MTD_RAW_NAND > + depends on MTD_RAW_NAND || MTD_SPI_NAND > help > NAND support. > Reviewed-by: Sean Anderson
Re: [PATCH v1 11/12] fastboot: enable FASTBOOT_FLASH option for SPI NAND devices
On 12/28/23 10:39, Alexey Romanov wrote: > From now we can use FASTBOOT_FLASH_NAND option for SPI NAND. > > Signed-off-by: Alexey Romanov > --- > drivers/fastboot/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig > index a3df9aa3d0..3cfeea4837 100644 > --- a/drivers/fastboot/Kconfig > +++ b/drivers/fastboot/Kconfig > @@ -86,7 +86,7 @@ config FASTBOOT_USB_DEV > config FASTBOOT_FLASH > bool "Enable FASTBOOT FLASH command" > default y if ARCH_SUNXI || ARCH_ROCKCHIP > - depends on MMC || (MTD_RAW_NAND && CMD_MTDPARTS) > + depends on MMC || ((MTD_RAW_NAND || MTD_SPI_NAND) && CMD_MTDPARTS) > select IMAGE_SPARSE > help > The fastboot protocol includes a "flash" command for writing > @@ -112,7 +112,7 @@ config FASTBOOT_FLASH_MMC > > config FASTBOOT_FLASH_NAND > bool "FASTBOOT on NAND" > - depends on MTD_RAW_NAND && CMD_MTDPARTS > + depends on (MTD_RAW_NAND || MTD_SPI_NAND) && CMD_MTDPARTS > > endchoice > Reviewed-by: Sean Anderson
Re: [PATCH v1 10/12] fastboot: check device type for SPI NAND too
On 12/28/23 10:39, Alexey Romanov wrote:
> SPI NAND devices also supports 'fastboot erase / flash' commands.
>
> Signed-off-by: Alexey Romanov
> ---
> drivers/fastboot/fb_nand.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/fastboot/fb_nand.c b/drivers/fastboot/fb_nand.c
> index 6d3a900c77..39d888301f 100644
> --- a/drivers/fastboot/fb_nand.c
> +++ b/drivers/fastboot/fb_nand.c
> @@ -53,7 +53,7 @@ static int fb_nand_lookup(const char *partname,
> return ret;
> }
>
> - if (dev->id->type != MTD_DEV_TYPE_NAND) {
> + if (dev->id->type != MTD_DEV_TYPE_NAND && dev->id->type !=
> MTD_DEV_TYPE_SPINAND) {
> pr_err("partition '%s' is not stored on a NAND device",
> partname);
> fastboot_fail("not a NAND device", response);
Reviewed-by: Sean Anderson
Re: [PATCH v1 12/12] fastboot: fb_nand: add missing newlines in pr_err() macro
On 12/28/23 10:39, Alexey Romanov wrote:
> pr_err() doesn't add an newline symbol when printing.
>
> Signed-off-by: Alexey Romanov
> ---
> drivers/fastboot/fb_nand.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/fastboot/fb_nand.c b/drivers/fastboot/fb_nand.c
> index 39d888301f..9db1903e41 100644
> --- a/drivers/fastboot/fb_nand.c
> +++ b/drivers/fastboot/fb_nand.c
> @@ -48,13 +48,13 @@ static int fb_nand_lookup(const char *partname,
>
> ret = find_dev_and_part(partname, , , part);
> if (ret) {
> - pr_err("cannot find partition: '%s'", partname);
> + pr_err("cannot find partition: '%s'\n", partname);
> fastboot_fail("cannot find partition", response);
> return ret;
> }
>
> if (dev->id->type != MTD_DEV_TYPE_NAND && dev->id->type !=
> MTD_DEV_TYPE_SPINAND) {
> - pr_err("partition '%s' is not stored on a NAND device",
> + pr_err("partition '%s' is not stored on a NAND device\n",
> partname);
> fastboot_fail("not a NAND device", response);
> return -EINVAL;
> @@ -178,7 +178,7 @@ void fastboot_nand_flash_write(const char *cmd, void
> *download_buffer,
>
> ret = fb_nand_lookup(cmd, , , response);
> if (ret) {
> - pr_err("invalid NAND device");
> + pr_err("invalid NAND device\n");
> fastboot_fail("invalid NAND device", response);
> return;
> }
> @@ -242,7 +242,7 @@ void fastboot_nand_erase(const char *cmd, char *response)
>
> ret = fb_nand_lookup(cmd, , , response);
> if (ret) {
> - pr_err("invalid NAND device");
> + pr_err("invalid NAND device\n");
> fastboot_fail("invalid NAND device", response);
> return;
> }
> @@ -253,7 +253,7 @@ void fastboot_nand_erase(const char *cmd, char *response)
>
> ret = _fb_nand_erase(mtd, part);
> if (ret) {
> - pr_err("failed erasing from device %s", mtd->name);
> + pr_err("failed erasing from device %s\n", mtd->name);
> fastboot_fail("failed erasing from device", response);
> return;
> }
Reviewed-by: Sean Anderson
Re: [PATCH v1 01/12] nand: move NAND initialization API to nand/core.c
On 12/28/23 10:39, Alexey Romanov wrote:
> nand_register() and nand_init() is generic API for both
> RAW and SPI NAND's. We have to move this functions
> from drivers/mtd/nand/raw/nand.c to drivers/mtd/nand/core.c.
>
> Functions designed to work with RAW NAND should remain
> in drivers/mtd/nand/raw/nand.c.
>
> Signed-off-by: Alexey Romanov
> ---
> drivers/mtd/Kconfig | 2 +-
> drivers/mtd/nand/Kconfig | 10 +++
> drivers/mtd/nand/core.c | 136 +++
> drivers/mtd/nand/raw/Kconfig | 10 ---
> drivers/mtd/nand/raw/nand.c | 134 --
> include/nand.h | 2 +
> 6 files changed, 149 insertions(+), 145 deletions(-)
>
> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
> index c56840c849..1902351719 100644
> --- a/drivers/mtd/Kconfig
> +++ b/drivers/mtd/Kconfig
> @@ -260,7 +260,7 @@ config SYS_NAND_MAX_ECCPOS
>
> config SYS_NAND_MAX_CHIPS
> int "NAND max chips"
> - depends on MTD_RAW_NAND || CMD_ONENAND || TARGET_S5PC210_UNIVERSAL || \
> + depends on MTD_RAW_NAND || MTD_SPI_NAND || CMD_ONENAND ||
> TARGET_S5PC210_UNIVERSAL || \
> SPL_OMAP3_ID_NAND
> default 1
> help
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 78ae04bdcb..9a1d4ac0dc 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -1,6 +1,16 @@
> config MTD_NAND_CORE
> tristate
>
> +config SYS_MAX_NAND_DEVICE
> + int "Maximum number of NAND devices to support"
> + default 1
> +
> +config SYS_NAND_SELF_INIT
> + bool
> + help
> + This option, if enabled, provides more flexible and linux-like
> + NAND initialization process.
> +
> source "drivers/mtd/nand/raw/Kconfig"
>
> source "drivers/mtd/nand/spi/Kconfig"
> diff --git a/drivers/mtd/nand/core.c b/drivers/mtd/nand/core.c
> index 4b9dd6a926..ff298e3a0f 100644
> --- a/drivers/mtd/nand/core.c
> +++ b/drivers/mtd/nand/core.c
> @@ -10,6 +10,7 @@
> #define pr_fmt(fmt) "nand: " fmt
>
> #include
> +#include
> #include
> #ifndef __UBOOT__
> #include
> @@ -18,6 +19,12 @@
> #include
> #include
>
> +int nand_curr_device = -1;
> +
> +static struct mtd_info *nand_info[CONFIG_SYS_MAX_NAND_DEVICE];
> +static char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][8];
> +static unsigned long total_nand_size; /* in kiB */
> +
> /**
> * nanddev_isbad() - Check if a block is bad
> * @nand: NAND device
> @@ -250,6 +257,135 @@ void nanddev_cleanup(struct nand_device *nand)
> }
> EXPORT_SYMBOL_GPL(nanddev_cleanup);
>
> +struct mtd_info *get_nand_dev_by_index(int dev)
> +{
> + if (dev < 0 || dev >= CONFIG_SYS_MAX_NAND_DEVICE || !nand_info[dev] ||
> + !nand_info[dev]->name)
> + return NULL;
> +
> + return nand_info[dev];
> +}
> +EXPORT_SYMBOL_GPL(get_nand_dev_by_index);
> +
> +int nand_mtd_to_devnum(struct mtd_info *mtd)
> +{
> + int i;
> +
> + for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++) {
> + if (mtd && get_nand_dev_by_index(i) == mtd)
> + return i;
> + }
> +
> + return -ENODEV;
> +}
> +EXPORT_SYMBOL_GPL(nand_mtd_to_devnum);
> +
> +/* Register an initialized NAND mtd device with the U-Boot NAND command. */
> +int nand_register(int devnum, struct mtd_info *mtd)
> +{
> + if (devnum >= CONFIG_SYS_MAX_NAND_DEVICE)
> + return -EINVAL;
> +
> + nand_info[devnum] = mtd;
> +
> + sprintf(dev_name[devnum], "nand%d", devnum);
> + mtd->name = dev_name[devnum];
> +
> +#ifdef CONFIG_MTD
> + /*
> + * Add MTD device so that we can reference it later
> + * via the mtdcore infrastructure (e.g. ubi).
> + */
> + add_mtd_device(mtd);
> +#endif
> +
> + total_nand_size += mtd->size / 1024;
> +
> + if (nand_curr_device == -1)
> + nand_curr_device = devnum;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(nand_register);
> +
> +#ifdef CONFIG_MTD_CONCAT
> +static void create_mtd_concat(void)
> +{
> + struct mtd_info *nand_info_list[CONFIG_SYS_MAX_NAND_DEVICE];
> + int nand_devices_found = 0;
> + int i;
> +
> + for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++) {
> + struct mtd_info *mtd = get_nand_dev_by_index(i);
> + if (mtd != NULL) {
> + nand_info_list[nand_devices_found] = mtd;
> + nand_devices_found++;
> + }
> + }
> + if (nand_devices_found > 1) {
> + struct mtd_info *mtd;
> + char c_mtd_name[16];
> +
> + /*
> + * We detected multiple devices. Concatenate them together.
> + */
> + sprintf(c_mtd_name, "nand%d", nand_devices_found);
> + mtd = mtd_concat_create(nand_info_list, nand_devices_found,
> + c_mtd_name);
> +
> + if (mtd == NULL)
> + return;
> +
> + nand_register(nand_devices_found,
Re: [PATCH v4 10/12] bloblist: Adjust the bloblist header
On Thu, 28 Dec 2023 at 15:37, Simon Glass wrote:
>
> Hi Ilias,
>
> On Thu, Dec 28, 2023 at 7:37 AM Ilias Apalodimas
> wrote:
> >
> > Hi Raymond,
> >
> > [...]
> >
> > >
> > > void bloblist_show_list(void)
> > > @@ -463,7 +477,7 @@ void bloblist_reloc(void *to, uint to_size, void
> > > *from, uint from_size)
> > >
> > > memcpy(to, from, from_size);
> > > hdr = to;
> > > - hdr->size = to_size;
> > > + hdr->total_size = to_size;
> > > }
> > >
> > > int bloblist_init(void)
> > > @@ -493,7 +507,7 @@ int bloblist_init(void)
> > > addr, ret);
> > > } else {
> > > /* Get the real size, if it is not what we
> > > expected */
> > > - size = gd->bloblist->size;
> > > + size = gd->bloblist->total_size;
> > > }
> > > }
> > > if (ret) {
> > > diff --git a/include/bloblist.h b/include/bloblist.h
> > > index 7024d7bf9e..4ec4b3d449 100644
> > > --- a/include/bloblist.h
> > > +++ b/include/bloblist.h
> > > @@ -166,32 +166,33 @@ enum bloblist_tag_t {
> > > * from the last.
> > > *
> > > * @magic: BLOBLIST_MAGIC
> > > + * @chksum: checksum for the entire bloblist allocated area. Since any
> > > of the
> > > + * blobs can be altered after being created, this checksum is only
> > > valid
> > > + * when the bloblist is finalized before jumping to the next stage
> > > of boot.
> > > + * This is the value needed to make all checksummed bytes sum to 0
> > > * @version: BLOBLIST_VERSION
> > > * @hdr_size: Size of this header, normally sizeof(struct bloblist_hdr).
> > > The
> > > * first bloblist_rec starts at this offset from the start of the
> > > header
> > > - * @flags: Space for BLOBLISTF... flags (none yet)
> > > - * @size: Total size of the bloblist (non-zero if valid) including this
> > > header.
> > > - * The bloblist extends for this many bytes from the start of this
> > > header.
> > > - * When adding new records, the bloblist can grow up to this size.
> > > - * @alloced: Total size allocated so far for this bloblist. This starts
> > > out as
> > > + * @align_log2: Power of two of the maximum alignment required by this
> > > list
> > > + * @used_size: Size allocated so far for this bloblist. This starts out
> > > as
> > > * sizeof(bloblist_hdr) since we need at least that much space to
> > > store a
> > > * valid bloblist
> > > + * @total_size: The number of total bytes that the bloblist can occupy.
> > > + * Any blob producer must check if there is sufficient space before
> > > adding
> > > + * a record to the bloblist.
> > > + * @flags: Space for BLOBLISTF... flags (none yet)
> > > * @spare: Spare space (for future use)
> > > - * @chksum: checksum for the entire bloblist allocated area. Since any
> > > of the
> > > - * blobs can be altered after being created, this checksum is only
> > > valid
> > > - * when the bloblist is finalised before jumping to the next stage
> > > of boot.
> > > - * This is the value needed to make all checksummed bytes sum to 0
> > > */
> > > struct bloblist_hdr {
> > > u32 magic;
> > > - u32 version;
> > > - u32 hdr_size;
> > > + u8 chksum;
> > > + u8 version;
> > > + u8 hdr_size;
> > > + u8 align_log2;
> > > + u32 used_size;
> > > + u32 total_size;
> > > u32 flags;
> > > -
> > > - u32 size;
> > > - u32 alloced;
> > > u32 spare;
> > > - u32 chksum;
> > > };
> >
> > The patch generally looks ok, but while we are renaming things, can't
> > we just copy what the spec says instead of slightly changing the
> > names?
> >
> > With this applied we end up with
> > struct bloblist_hdr {
> > u32 magic;
> > u8 chksum;
> > u8 version;
> > u8 hdr_size;
> > u8 align_log2;
> > u32 used_size;
> > u32 total_size;
> > u32 flags;
> > u32 spare;
> > };
> >
> > Can you at least rename the ones you touch here properly?
> > - Drop the patch that renames spare to _spare
> > - used_size -> size
> > - total_size -> max_size (which btw mean different things)
> > - spare -> reserved
>
> Yes that would be good, but since the spec only recently changed the
> names, how about a 'rename' patch on top, if that is easier?
>
Sure I dont mind,
Reviewed-by: Ilias Apalodimas
> I was hoping that this series could be applied as is, or close to it.
> It looks like a good base to me.
>
> Regards,
> Simon
Re: Regression: i.MX6ULL reset not working
On Thu, Dec 28, 2023 at 01:35:31PM -0300, Fabio Estevam wrote:
> Hi Francesco,
>
> On Thu, Dec 28, 2023 at 12:49 PM Francesco Dolcini
> wrote:
> >
> > Hello Marek and all,
> > I just tried latest master on colibri-imx6ull-emmc and the reset command
> > is broken - it does nothing.
> >
> > From a bisect the issue was introduced with commit 68dcbdd594d4 ("ARM:
> > imx: Add weak default reset_cpu()"), U-Boot releases >= v2023.07 are
> > broken.
> >
> > Any hint? I did not try to debug it myself (yet?).
>
> I think we need something like this:
> https://gitlab.com/u-boot/u-boot/-/commit/9043adee3ea67f4a71498e8f06023e3f63d7668f
>
> but it needs to be more generic, at the SoC level, instead of per board.
With that we would have to enable the watchdog, something that is not
done today. Any potential downside on doing it?
Francesco
Re: [PATCH v1] fastboot: introduce 'oem board' subcommand
On 12/28/23 10:25, Alexey Romanov wrote:
> Currently, fastboot protocol in U-Boot has no opportunity
> to execute vendor custom code with verifed boot.
Well, I would say the most conventional way to do this would be something like
=> fastboot 0
=> source \# CONFIG_FASTBOOT_BUF_ADDR
and on your host machine,
$ fastboot stage my_script.itb
where my_script.its looks like
/dts-v1/;
/ {
description = "my script";
#address-cells = <1>;
images {
my-script {
data = /incbin/("my_script.scr");
type = "script";
arch = "arm64";
compression = "none";
hash-1 {
algo = "sha256";
};
};
};
configurations {
default = "conf";
conf {
description = "Load my script";
script = "my-script";
signature {
algo = "sha256,rsa2048";
key-name-hint = "vboot";
sign-images = "script";
};
};
};
};
This method is especially useful to pass complex parameters to your command.
This method of course requires commit bcc85b96b5f ("cmd: source: Support
specifying config name").
Would it be possible to use the above method for your use case?
--Sean
> This patch
> introduce new fastboot subcommand fastboot oem board:,
> which allow to run custom oem_board function.
> =
> Default implementation is __weak. Vendor must redefine it in
> board/ folder with his own logic.
>
> For example, some vendors have their custom nand/emmc partition
> flashing or erasing. Here some typical command for such use cases:
>
> - flashing:
>
> $ fastboot stage bootloader.img
> $ fastboot oem board:write_bootloader
>
> - erasing:
>
> $ fastboot oem board:erase_env
>
> Signed-off-by: Alexey Romanov
> ---
> drivers/fastboot/Kconfig | 7 +++
> drivers/fastboot/fb_command.c | 15 +++
> include/fastboot.h| 1 +
> 3 files changed, 23 insertions(+)
>
> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
> index 3cfeea4837..4c955cabab 100644
> --- a/drivers/fastboot/Kconfig
> +++ b/drivers/fastboot/Kconfig
> @@ -241,6 +241,13 @@ config FASTBOOT_OEM_RUN
> this feature if you are using verified boot, as it will allow an
> attacker to bypass any restrictions you have in place.
>
> +config FASTBOOT_OEM_BOARD
> + bool "Enable the 'oem board' command"
> + help
> + This extends the fastboot protocol with an "oem board" command. This
> + command allows running vendor custom code defined in board/ files.
> + Otherwise, it will do nothing and send fastboot fail.
> +
> endif # FASTBOOT
>
> endmenu
> diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
> index 71cfaec6e9..4d2b451f46 100644
> --- a/drivers/fastboot/fb_command.c
> +++ b/drivers/fastboot/fb_command.c
> @@ -39,6 +39,7 @@ static void reboot_recovery(char *, char *);
> static void oem_format(char *, char *);
> static void oem_partconf(char *, char *);
> static void oem_bootbus(char *, char *);
> +static void oem_board(char *, char *);
> static void run_ucmd(char *, char *);
> static void run_acmd(char *, char *);
>
> @@ -106,6 +107,10 @@ static const struct {
> .command = "oem run",
> .dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_RUN, (run_ucmd),
> (NULL))
> },
> + [FASTBOOT_COMMAND_OEM_BOARD] = {
> + .command = "oem board",
> + .dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_BOARD, (oem_board),
> (NULL))
> + },
> [FASTBOOT_COMMAND_UCMD] = {
> .command = "UCmd",
> .dispatch = CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT, (run_ucmd),
> (NULL))
> @@ -489,3 +494,13 @@ static void __maybe_unused oem_bootbus(char
> *cmd_parameter, char *response)
> else
> fastboot_okay(NULL, response);
> }
> +
> +void __weak fastboot_oem_board(char *cmd_parameter, void *data, u32 size,
> char *response)
> +{
> + fastboot_fail("oem board function not defined", response);
> +}
> +
> +static void __maybe_unused oem_board(char *cmd_parameter, char *response)
> +{
> + fastboot_oem_board(cmd_parameter, fastboot_buf_addr, image_size,
> response);
> +}
> diff --git a/include/fastboot.h b/include/fastboot.h
> index 296451f89d..06c1f26b6c 100644
> --- a/include/fastboot.h
> +++ b/include/fastboot.h
> @@ -37,6 +37,7 @@ enum {
> FASTBOOT_COMMAND_OEM_PARTCONF,
> FASTBOOT_COMMAND_OEM_BOOTBUS,
> FASTBOOT_COMMAND_OEM_RUN,
> + FASTBOOT_COMMAND_OEM_BOARD,
> FASTBOOT_COMMAND_ACMD,
> FASTBOOT_COMMAND_UCMD,
> FASTBOOT_COMMAND_COUNT
Re: Regression: i.MX6ULL reset not working
Hi Francesco,
On Thu, Dec 28, 2023 at 12:49 PM Francesco Dolcini wrote:
>
> Hello Marek and all,
> I just tried latest master on colibri-imx6ull-emmc and the reset command
> is broken - it does nothing.
>
> From a bisect the issue was introduced with commit 68dcbdd594d4 ("ARM:
> imx: Add weak default reset_cpu()"), U-Boot releases >= v2023.07 are
> broken.
>
> Any hint? I did not try to debug it myself (yet?).
I think we need something like this:
https://gitlab.com/u-boot/u-boot/-/commit/9043adee3ea67f4a71498e8f06023e3f63d7668f
but it needs to be more generic, at the SoC level, instead of per board.
Re: [PATCH v4 10/12] bloblist: Adjust the bloblist header
Hi Ilias,
On Thu, 28 Dec 2023 at 02:37, Ilias Apalodimas
wrote:
> Hi Raymond,
>
> [...]
>
> >
> > void bloblist_show_list(void)
> > @@ -463,7 +477,7 @@ void bloblist_reloc(void *to, uint to_size, void
> *from, uint from_size)
> >
> > memcpy(to, from, from_size);
> > hdr = to;
> > - hdr->size = to_size;
> > + hdr->total_size = to_size;
> > }
> >
> > int bloblist_init(void)
> > @@ -493,7 +507,7 @@ int bloblist_init(void)
> > addr, ret);
> > } else {
> > /* Get the real size, if it is not what we
> expected */
> > - size = gd->bloblist->size;
> > + size = gd->bloblist->total_size;
> > }
> > }
> > if (ret) {
> > diff --git a/include/bloblist.h b/include/bloblist.h
> > index 7024d7bf9e..4ec4b3d449 100644
> > --- a/include/bloblist.h
> > +++ b/include/bloblist.h
> > @@ -166,32 +166,33 @@ enum bloblist_tag_t {
> > * from the last.
> > *
> > * @magic: BLOBLIST_MAGIC
> > + * @chksum: checksum for the entire bloblist allocated area. Since any
> of the
> > + * blobs can be altered after being created, this checksum is only
> valid
> > + * when the bloblist is finalized before jumping to the next stage
> of boot.
> > + * This is the value needed to make all checksummed bytes sum to 0
> > * @version: BLOBLIST_VERSION
> > * @hdr_size: Size of this header, normally sizeof(struct
> bloblist_hdr). The
> > * first bloblist_rec starts at this offset from the start of the
> header
> > - * @flags: Space for BLOBLISTF... flags (none yet)
> > - * @size: Total size of the bloblist (non-zero if valid) including this
> header.
> > - * The bloblist extends for this many bytes from the start of this
> header.
> > - * When adding new records, the bloblist can grow up to this size.
> > - * @alloced: Total size allocated so far for this bloblist. This starts
> out as
> > + * @align_log2: Power of two of the maximum alignment required by this
> list
> > + * @used_size: Size allocated so far for this bloblist. This starts out
> as
> > * sizeof(bloblist_hdr) since we need at least that much space to
> store a
> > * valid bloblist
> > + * @total_size: The number of total bytes that the bloblist can occupy.
> > + * Any blob producer must check if there is sufficient space before
> adding
> > + * a record to the bloblist.
> > + * @flags: Space for BLOBLISTF... flags (none yet)
> > * @spare: Spare space (for future use)
> > - * @chksum: checksum for the entire bloblist allocated area. Since any
> of the
> > - * blobs can be altered after being created, this checksum is only
> valid
> > - * when the bloblist is finalised before jumping to the next stage
> of boot.
> > - * This is the value needed to make all checksummed bytes sum to 0
> > */
> > struct bloblist_hdr {
> > u32 magic;
> > - u32 version;
> > - u32 hdr_size;
> > + u8 chksum;
> > + u8 version;
> > + u8 hdr_size;
> > + u8 align_log2;
> > + u32 used_size;
> > + u32 total_size;
> > u32 flags;
> > -
> > - u32 size;
> > - u32 alloced;
> > u32 spare;
> > - u32 chksum;
> > };
>
> The patch generally looks ok, but while we are renaming things, can't
> we just copy what the spec says instead of slightly changing the
> names?
>
> With this applied we end up with
> struct bloblist_hdr {
> u32 magic;
> u8 chksum;
> u8 version;
> u8 hdr_size;
> u8 align_log2;
> u32 used_size;
> u32 total_size;
> u32 flags;
> u32 spare;
> };
>
> Can you at least rename the ones you touch here properly?
> - Drop the patch that renames spare to _spare
> - used_size -> size
> - total_size -> max_size (which btw mean different things)
> - spare -> reserved
>
> I was been told by Simon for the naming changes of `used_size` and
`total_size` at:
https://github.com/FirmwareHandoff/firmware_handoff/pull/25
I will prefer to keep this minor fix until spec v1.0 is released since the
spec
is still continuously being updated without upgrading the revision number.
When a v1.0 spec is released I will update the TF-A, OP-TEE and U-Boot
together.
[...]
Thanks and regards,
Raymond
Re: Regression: i.MX6ULL reset not working
On Thu, Dec 28, 2023 at 04:49:33PM +0100, Francesco Dolcini wrote:
> Hello Marek and all,
> I just tried latest master on colibri-imx6ull-emmc and the reset command
> is broken - it does nothing.
>
> >From a bisect the issue was introduced with commit 68dcbdd594d4 ("ARM:
> imx: Add weak default reset_cpu()"), U-Boot releases >= v2023.07 are
> broken.
>
> Any hint? I did not try to debug it myself (yet?).
Ok, the reason for the bug is simple.
Before that change we had drivers/watchdog/imx_watchdog.c:reset_cpu()
implementing the reset. However that function is also weak and now the
newly defined and empty weak is taking precedence.
I assume every i.MX that is not i.MX8M* or i.MX7ULP is now broken, not
just i.MX6ULL nor just the colibri.
Francesco
Re: [PATCH v4 08/12] bloblist: Handle alignment with a void entry
Hi Ilias,
On Thu, 28 Dec 2023 at 06:32, Ilias Apalodimas
wrote:
> Hi Raymond,
>
> On Wed, 27 Dec 2023 at 23:08, Raymond Mao wrote:
> >
> > From: Simon Glass
> >
> > Rather than setting the alignment using the header size, add an entirely
> > new entry to cover the gap left by the alignment.
> >
> > Signed-off-by: Simon Glass
> > Co-developed-by: Raymond Mao
> > Signed-off-by: Raymond Mao
> > Reviewed-by: Simon Glass
> > ---
> > common/bloblist.c | 23 +++
> > 1 file changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/common/bloblist.c b/common/bloblist.c
> > index 705d9c6ae9..73dbbc01c0 100644
> > --- a/common/bloblist.c
> > +++ b/common/bloblist.c
> > @@ -142,7 +142,7 @@ static int bloblist_addrec(uint tag, int size, int
> align_log2,
> > {
> > struct bloblist_hdr *hdr = gd->bloblist;
> > struct bloblist_rec *rec;
> > - int data_start, new_alloced;
> > + int data_start, aligned_start, new_alloced;
> >
> > if (!align_log2)
> > align_log2 = BLOBLIST_ALIGN_LOG2;
> > @@ -151,10 +151,25 @@ static int bloblist_addrec(uint tag, int size, int
> align_log2,
> > data_start = map_to_sysmem(hdr) + hdr->alloced + sizeof(*rec);
> >
> > /* Align the address and then calculate the offset from
> ->alloced */
> > - data_start = ALIGN(data_start, 1U << align_log2) -
> map_to_sysmem(hdr);
> > + aligned_start = ALIGN(data_start, 1U << align_log2) - data_start;
> > +
> > + /* If we need to create a dummy record, create it */
> > + if (aligned_start) {
> > + int void_size = aligned_start - sizeof(*rec);
> > + struct bloblist_rec *vrec;
> > + int ret;
> > +
> > + ret = bloblist_addrec(BLOBLISTT_VOID, void_size, 0,
> );
>
> I just noticed the 'BLOBLISTT'. Is that on purpose? or a typo?
>
> > + if (ret)
> > + return log_msg_ret("void", ret);
> > +
> > + /* start the record after that */
> > + data_start = map_to_sysmem(hdr) + hdr->alloced +
> sizeof(*vrec);
> > + }
> >
> > /* Calculate the new allocated total */
> > - new_alloced = data_start + ALIGN(size, 1U << align_log2);
> > + new_alloced = data_start - map_to_sysmem(hdr) +
> > + ALIGN(size, 1U << align_log2);
>
> So, wouldn't it make more sense to add the dummy record and align the
> whole thing *after* we've added the entry?
> Doing it like this might leave the last entry on an unaligned boundary, no?
>
> The spec just cares about the TE *data* starts at an aligned address but
not the TE header.
Not sure if I fully understand your question but each TE *data* will start
at an aligned address
after calling `bloblist_addrec()`.
And each TE is allowed to have its own alignment value, so we have to do
the padding when
a TE is being added but cannot predict the alignment value for the next TE
- that means we
cannot do the padding after each TE is added.
[...]
Thanks and regards,
Raymond
Re: [PATCH v5] fdt: Allow the devicetree to come from a bloblist
On Thu, Dec 28, 2023 at 01:36:54PM +, Simon Glass wrote:
> Standard passage provides for a bloblist to be passed from one firmware
> phase to the next. That can be used to pass the devicetree along as well.
> Add an option to support this.
>
> Tests for this will be added as part of the Universal Payload work.
>
> Signed-off-by: Simon Glass
> ---
> The discussion on this was not resolved and is now important due to the
> bloblist series from Raymond. So I am sending it again since I believe
> this is a better starting point than building on OF_BOARD
[snip]
> @@ -1662,23 +1667,42 @@ static void setup_multi_dtb_fit(void)
>
> int fdtdec_setup(void)
> {
> - int ret;
> + int ret = -ENOENT;
> +
> + /* If allowing a bloblist, check that first */
> + if (CONFIG_IS_ENABLED(OF_BLOBLIST)) {
> + ret = bloblist_maybe_init();
> + if (!ret) {
> + gd->fdt_blob = bloblist_find(BLOBLISTT_CONTROL_FDT, 0);
> + if (gd->fdt_blob) {
> + gd->fdt_src = FDTSRC_BLOBLIST;
> + log_debug("Devicetree is in bloblist at %p\n",
> + gd->fdt_blob);
> + } else {
> + log_debug("No FDT found in bloblist\n");
> + ret = -ENOENT;
> + }
> + }
> + }
>
> - /* The devicetree is typically appended to U-Boot */
> - if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
> - gd->fdt_blob = fdt_find_separate();
> - gd->fdt_src = FDTSRC_SEPARATE;
> - } else { /* embed dtb in ELF file for testing / development */
> - gd->fdt_blob = dtb_dt_embedded();
> - gd->fdt_src = FDTSRC_EMBED;
> + /* Otherwise, the devicetree is typically appended to U-Boot */
> + if (ret) {
> + if (IS_ENABLED(CONFIG_OF_SEPARATE)) {
> + gd->fdt_blob = fdt_find_separate();
> + gd->fdt_src = FDTSRC_SEPARATE;
> + } else { /* embed dtb in ELF file for testing / development */
> + gd->fdt_blob = dtb_dt_embedded();
> + gd->fdt_src = FDTSRC_EMBED;
> + }
> }
This whole if/else tree looks wrong today, and then wrong with this
patch. If we have an embedded device tree, which should only be used for
development (or special case needs, I _think_ some users today are using
this for security type needs), it must win and be used. The over-ride
switch was set, and should be used. Then, I don't know if we should be
saying "the user provided a tree via OF_SEPARATE, it should be used" or
"the device has passed us a tree via standard mechanism, it should be
used" is the higher priority. I really don't know which is more valid.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds
On Thu, Dec 28, 2023 at 03:09:12PM +, Simon Glass wrote: > Hi Tom, Sumit, > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini wrote: > > > > On Thu, Dec 28, 2023 at 01:37:26PM +, Simon Glass wrote: > > > Hi Sumit, > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg wrote: > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts > > > > directory. Also add a new Makefile for arm64. > > > > > > > > This will help easy migration for platforms which currently are > > > > compliant > > > > with upstream Linux kernel devicetree files. > > > > > > > > Signed-off-by: Sumit Garg > > > > --- > > > > > > > > Changes in v3: > > > > -- > > > > - Minor commit message update > > > > > > > > Changes in v2: > > > > -- > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > > > dts/Kconfig | 11 +++ > > > > dts/Makefile| 17 ++--- > > > > dts/arch/arm64/Makefile | 14 ++ > > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > > --- a/dts/Kconfig > > > > +++ b/dts/Kconfig > > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > > enables a live tree which is available after relocation, > > > > and can be adjusted as needed. > > > > > > > > +config OF_UPSTREAM > > > > + bool "Enable use of devicetree imported from Linux kernel > > > > release" > > > > + help > > > > + Traditionally, U-Boot platforms used to have their custom > > > > devicetree > > > > + files or copy devicetree files from Linux kernel which are > > > > hard to > > > > + maintain and can usually get out-of-sync from Linux kernel. > > > > This > > > > + option enables platforms to migrate to devicetree-rebasing > > > > repo where > > > > + a regular sync will be maintained every major Linux kernel > > > > release > > > > + cycle. However, platforms can still have some custom u-boot > > > > specific > > > > + bits maintained as part of *-u-boot.dtsi files. > > > > > > My only other suggestion here is to mention that this should be set in > > > Kconfig, for the SoC as a whole. So I believe that means that it > > > should be hidden, with no string for the 'bool': > > > > > > bool # Enable use of devicetree imported from Linux kernel release > > > > I think we can just keep prompting for it now, to make the transition > > easier, before this option just goes away in time, hopefully. > > > > > Also, this doesn't seem to work for me. Before this series I get these > > > files when building firefly-rk3399: > > > > > > rk3399-eaidk-610.dtbrk3399-khadas-edge-v.dtb > > > rk3399-orangepi.dtbrk3399-rock-pi-4a.dtb > > > rk3399-evb.dtb rk3399-leez-p710.dtb > > > rk3399-pinebook-pro.dtbrk3399-rock-pi-4c.dtb > > > rk3399-ficus.dtbrk3399-nanopc-t4.dtb > > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > > rk3399-gru-kevin.dtbrk3399-nanopi-m4.dtb > > > rk3399-rock-4c-plus.dtb > > > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb > > > rk3399-rock-4se.dtb > > > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb > > > rk3399-rock960.dtb > > > > > > Afterwards I get this: > > > > > > make[3]: *** No rule to make target > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > So I set this manually for that one board: > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > > > > > and get: > > > > > > make[3]: *** No rule to make target > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > > > I am not sure how to fix this, nor how this can be made to build all > > > the DTs for rk3399, as it does today. > > > > Looking at the patch for amlogic boards, you need to make the link to > > devicetree-rebasing inside dts/... > > OK, let me give up on rk3399 for now...that doesn't seem to work even > with the link. > > Using odroid-c2 with -next I see: > > $ ls /tmp/b/odroid-c2/arch/arm/dts/ > meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb > meson-gxl-s905x-libretech-cc.dtb > meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb > meson-gxl-s905x-libretech-cc-v2.dtb > meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb > meson-gxl-s905x-p212.dtb > meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb >
Regression: i.MX6ULL reset not working
Hello Marek and all,
I just tried latest master on colibri-imx6ull-emmc and the reset command
is broken - it does nothing.
>From a bisect the issue was introduced with commit 68dcbdd594d4 ("ARM:
imx: Add weak default reset_cpu()"), U-Boot releases >= v2023.07 are
broken.
Any hint? I did not try to debug it myself (yet?).
Francesco
Re: I'm looking for the source code of a specific u-boot version.
I tried to compile it,but If failed : /mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make snow_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/zconf.tab.o In file included from scripts/kconfig/zconf.tab.c:2470: In function ‘dep_stack_insert’, inlined from ‘sym_check_print_recursive’ at scripts/kconfig/symbol.c:1123:3, inlined from ‘sym_check_deps’ at scripts/kconfig/symbol.c:1300:3: scripts/kconfig/symbol.c:1099:19: warning: storing the address of local variable ‘cv_stack’ in ‘check_top’ [-Wdangling-pointer=] 1099 | check_top = stack; | ~~^~~ scripts/kconfig/symbol.c: In function ‘sym_check_deps’: scripts/kconfig/symbol.c:1120:26: note: ‘cv_stack’ declared here 1120 | struct dep_stack cv_stack; | ^~~~ scripts/kconfig/symbol.c:1090:4: note: ‘check_top’ declared here 1090 | } *check_top; |^ HOSTLD scripts/kconfig/conf # # configuration written to .config # /mnt/zroot2/zroot2/OS/Chromebook/freebsd-xen/domU-freebsd/bootloaders/u-boot-2017.05# ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config.h CFG u-boot.cfg GEN include/autoconf.mk GEN include/autoconf.mk.dep CFG spl/u-boot.cfg GEN spl/include/autoconf.mk CHK include/config/uboot.release CHK include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CC lib/asm-offsets.s arm-linux-gnueabihf-gcc: error: unrecognized -march target: armv5 arm-linux-gnueabihf-gcc: note: valid arguments are: armv4 armv4t armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8.6-a armv8-m.base armv8-m.main armv8-r armv8.1-m.main armv9-a iwmmxt iwmmxt2; did you mean ‘armv4’? arm-linux-gnueabihf-gcc: error: missing argument to ‘-march=’ make[1]: *** [Kbuild:44: lib/asm-offsets.s] Error 1 make: *** [Makefile:1287: prepare0] Error 2 On Thu, Dec 28, 2023 at 3:47 PM Mario Marietto wrote: > > Hello. > > Can someone provide the right link to download u-boot-2017.0.5 , please ? > > I've found it here,but I'm not sure that it's the correct version : > > https://src.fedoraproject.org/repo/pkgs/uboot-tools/u-boot-2017.05.tar.bz2/sha512/be270f9242a72b05463092a022bbabd54996762de1ff23bf7575124ac02e62f49572a4e2f6f571a5019047d40027e56e35593b5cc373c4a5a39b100c3377ba93/ > > Can you confirm it ? thanks. > > On Thu, Dec 28, 2023 at 1:14 AM Tony Dinh wrote: > > > > Hi Mario and Heinrich, > > > > On Wed, Dec 27, 2023 at 12:23 PM Mario Marietto > > wrote: > > > > > > Hello. > > > > > > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook > > > SNOW with xen. Basically there are two ways to accomplish this task : > > > > > > > > > 1) to write a patch that allows the FreeBSD kernel to boot as a zImage > > > file. This could be accomplished applying this patch to a specific > > > file that's on the source code of FreeBSD : > > > > > > > > > https://xenbits.xen.org/gitweb/?p=p...8;hb=0782e25d98cc1391472717035f986c979edef0c9 > > > > > > > > > > > > This patch was written by Julien Grall a lot of time ago and now it > > > does not work anymore. This is the reason explain by the xen > > > developers : > > > > > > > > > > > > It appears FreeBSD-CURRENT removed the last step converting the kernel > > > file to kernel.bin.The patch can be readily rebased, but without > > > kernel.bin that doesn't do too much. > > > > > > > > > > > > So,without a rebase of that patch the first option is not applicable. > > > And I'm not able to fix it. > > > > > > > > > 2) booting FreeBSD using U-Boot,as explained to me by a xen developer : > > > > > > > > > I was trying to explain why and how Julien's patch works so that you > > > could be the one to re-do something similar or fix the patch on the > > > FreeBSD kernel that you are working with. I am happy to help review > > > and write patches but I don't work with the FreeBSD kernel so I > > > wouldn't be able to help you quickly. However, I might have a > > > suggestion. Do you know if FreeBSD can be booted by U-Boot ? > > > Because > > > U-Boot definitely boots as Xen on ARM guest firmware/bootloader. You > > > should be able to build U-Boot and use the U-Boot binary as Xen guest > > > kernel, then U-Boot could load FreeBSD from disk or network and start > > > it. For instance as domU config file: > > > > > > kernel="/home/petalinux/u-boot.bin" > > > disk = [ '/home/petalinux/test.img,raw,xvda' ] > > > > > > > > > Actually I'm working on the idea n. 2. Basically I need to find the > > > proper u-boot file that's able to boot the image of FreeBSD that I > > > have
[PATCH v1 12/12] fastboot: fb_nand: add missing newlines in pr_err() macro
pr_err() doesn't add an newline symbol when printing.
Signed-off-by: Alexey Romanov
---
drivers/fastboot/fb_nand.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/fastboot/fb_nand.c b/drivers/fastboot/fb_nand.c
index 39d888301f..9db1903e41 100644
--- a/drivers/fastboot/fb_nand.c
+++ b/drivers/fastboot/fb_nand.c
@@ -48,13 +48,13 @@ static int fb_nand_lookup(const char *partname,
ret = find_dev_and_part(partname, , , part);
if (ret) {
- pr_err("cannot find partition: '%s'", partname);
+ pr_err("cannot find partition: '%s'\n", partname);
fastboot_fail("cannot find partition", response);
return ret;
}
if (dev->id->type != MTD_DEV_TYPE_NAND && dev->id->type !=
MTD_DEV_TYPE_SPINAND) {
- pr_err("partition '%s' is not stored on a NAND device",
+ pr_err("partition '%s' is not stored on a NAND device\n",
partname);
fastboot_fail("not a NAND device", response);
return -EINVAL;
@@ -178,7 +178,7 @@ void fastboot_nand_flash_write(const char *cmd, void
*download_buffer,
ret = fb_nand_lookup(cmd, , , response);
if (ret) {
- pr_err("invalid NAND device");
+ pr_err("invalid NAND device\n");
fastboot_fail("invalid NAND device", response);
return;
}
@@ -242,7 +242,7 @@ void fastboot_nand_erase(const char *cmd, char *response)
ret = fb_nand_lookup(cmd, , , response);
if (ret) {
- pr_err("invalid NAND device");
+ pr_err("invalid NAND device\n");
fastboot_fail("invalid NAND device", response);
return;
}
@@ -253,7 +253,7 @@ void fastboot_nand_erase(const char *cmd, char *response)
ret = _fb_nand_erase(mtd, part);
if (ret) {
- pr_err("failed erasing from device %s", mtd->name);
+ pr_err("failed erasing from device %s\n", mtd->name);
fastboot_fail("failed erasing from device", response);
return;
}
--
2.30.1
[PATCH v1 11/12] fastboot: enable FASTBOOT_FLASH option for SPI NAND devices
>From now we can use FASTBOOT_FLASH_NAND option for SPI NAND. Signed-off-by: Alexey Romanov --- drivers/fastboot/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig index a3df9aa3d0..3cfeea4837 100644 --- a/drivers/fastboot/Kconfig +++ b/drivers/fastboot/Kconfig @@ -86,7 +86,7 @@ config FASTBOOT_USB_DEV config FASTBOOT_FLASH bool "Enable FASTBOOT FLASH command" default y if ARCH_SUNXI || ARCH_ROCKCHIP - depends on MMC || (MTD_RAW_NAND && CMD_MTDPARTS) + depends on MMC || ((MTD_RAW_NAND || MTD_SPI_NAND) && CMD_MTDPARTS) select IMAGE_SPARSE help The fastboot protocol includes a "flash" command for writing @@ -112,7 +112,7 @@ config FASTBOOT_FLASH_MMC config FASTBOOT_FLASH_NAND bool "FASTBOOT on NAND" - depends on MTD_RAW_NAND && CMD_MTDPARTS + depends on (MTD_RAW_NAND || MTD_SPI_NAND) && CMD_MTDPARTS endchoice -- 2.30.1
[PATCH v1 10/12] fastboot: check device type for SPI NAND too
SPI NAND devices also supports 'fastboot erase / flash' commands.
Signed-off-by: Alexey Romanov
---
drivers/fastboot/fb_nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fastboot/fb_nand.c b/drivers/fastboot/fb_nand.c
index 6d3a900c77..39d888301f 100644
--- a/drivers/fastboot/fb_nand.c
+++ b/drivers/fastboot/fb_nand.c
@@ -53,7 +53,7 @@ static int fb_nand_lookup(const char *partname,
return ret;
}
- if (dev->id->type != MTD_DEV_TYPE_NAND) {
+ if (dev->id->type != MTD_DEV_TYPE_NAND && dev->id->type !=
MTD_DEV_TYPE_SPINAND) {
pr_err("partition '%s' is not stored on a NAND device",
partname);
fastboot_fail("not a NAND device", response);
--
2.30.1
[PATCH v1 09/12] cmd: allow to enable CMD_NAND for SPI NAND devices
Boards with SPI NAND also can use this command. Signed-off-by: Alexey Romanov --- cmd/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index c47523a03b..c8484576e2 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1367,7 +1367,7 @@ config CMD_MUX config CMD_NAND bool "nand" default y if NAND_SUNXI - depends on MTD_RAW_NAND + depends on MTD_RAW_NAND || MTD_SPI_NAND help NAND support. -- 2.30.1
[PATCH v1 07/12] mtdparts: use negative error codes
It is bad practice to use such error codes. Error codes
must be negative.
Also, fastboot code expects that if successful, mtdparts
functions will return a value greater than 0. You can see
fastboot_nand_get_part_info() functions calls inside
getvar_get_part_info().
And use 'return CMD_RET_FAILURE' define instead of 'return 1'.
Signed-off-by: Alexey Romanov
---
cmd/mtdparts.c | 154 -
1 file changed, 77 insertions(+), 77 deletions(-)
diff --git a/cmd/mtdparts.c b/cmd/mtdparts.c
index 0984158f41..08e5b794db 100644
--- a/cmd/mtdparts.c
+++ b/cmd/mtdparts.c
@@ -299,7 +299,7 @@ static void current_save(void)
* @param type mtd type
* @param num mtd number
* @param mtd a pointer to an mtd_info instance (output)
- * Return: 0 if device is valid, 1 otherwise
+ * Return: 0 if device is valid, -errno otherwise
*/
static int get_mtd_info(u8 type, u8 num, struct mtd_info **mtd)
{
@@ -309,7 +309,7 @@ static int get_mtd_info(u8 type, u8 num, struct mtd_info
**mtd)
*mtd = get_mtd_device_nm(mtd_dev);
if (IS_ERR(*mtd)) {
printf("Device %s not found!\n", mtd_dev);
- return 1;
+ return -ENODEV;
}
put_mtd_device(*mtd);
@@ -323,7 +323,7 @@ static int get_mtd_info(u8 type, u8 num, struct mtd_info
**mtd)
*
* @param id of the parent device
* @param part partition to validate
- * Return: 0 if partition is valid, 1 otherwise
+ * Return: 0 if partition is valid, -errno otherwise
*/
static int part_validate_eraseblock(struct mtdids *id, struct part_info *part)
{
@@ -333,7 +333,7 @@ static int part_validate_eraseblock(struct mtdids *id,
struct part_info *part)
u64 offset, size;
if (get_mtd_info(id->type, id->num, ))
- return 1;
+ return -EINVAL;
part->sector_size = mtd->erasesize;
@@ -347,14 +347,14 @@ static int part_validate_eraseblock(struct mtdids *id,
struct part_info *part)
printf("%s%d: partition (%s) start offset"
"alignment incorrect\n",
MTD_DEV_TYPE(id->type), id->num, part->name);
- return 1;
+ return -EINVAL;
}
size = part->size;
if (do_div(size, mtd->erasesize)) {
printf("%s%d: partition (%s) size alignment
incorrect\n",
MTD_DEV_TYPE(id->type), id->num, part->name);
- return 1;
+ return -EINVAL;
}
} else {
/*
@@ -374,7 +374,7 @@ static int part_validate_eraseblock(struct mtdids *id,
struct part_info *part)
printf("%s%d: partition (%s) start offset alignment
incorrect\n",
MTD_DEV_TYPE(id->type), id->num, part->name);
- return 1;
+ return -EINVAL;
start_ok:
@@ -393,7 +393,7 @@ static int part_validate_eraseblock(struct mtdids *id,
struct part_info *part)
printf("%s%d: partition (%s) size alignment incorrect\n",
MTD_DEV_TYPE(id->type), id->num, part->name);
- return 1;
+ return -EINVAL;
end_ok:
return 0;
@@ -410,7 +410,7 @@ static int part_validate_eraseblock(struct mtdids *id,
struct part_info *part)
*
* @param id of the parent device
* @param part partition to validate
- * Return: 0 if partition is valid, 1 otherwise
+ * Return: 0 if partition is valid, -errno otherwise
*/
static int part_validate(struct mtdids *id, struct part_info *part)
{
@@ -420,18 +420,18 @@ static int part_validate(struct mtdids *id, struct
part_info *part)
if (part->offset > id->size) {
printf("%s: offset %08llx beyond flash size %08llx\n",
id->mtd_id, part->offset, id->size);
- return 1;
+ return -EINVAL;
}
if ((part->offset + part->size) <= part->offset) {
printf("%s%d: partition (%s) size too big\n",
MTD_DEV_TYPE(id->type), id->num, part->name);
- return 1;
+ return -EINVAL;
}
if (part->offset + part->size > id->size) {
printf("%s: partitioning exceeds flash size\n", id->mtd_id);
- return 1;
+ return -EINVAL;
}
/*
@@ -446,7 +446,7 @@ static int part_validate(struct mtdids *id, struct
part_info *part)
*
* @param dev device to delete partition from
* @param part partition to delete
- * Return: 0 on success, 1 otherwise
+ * Return: 0 on success, -ernno otherwise
*/
static int part_del(struct mtd_device *dev, struct part_info *part)
{
@@ -544,7 +544,7 @@ static int part_sort_add(struct mtd_device *dev, struct
part_info *part)
/* be compliant with kernel
[PATCH v1 08/12] jffs2: use negative error codes
It is bad practice to use such error codes. Error codes
must be negative.
And use CMD_RET_FAILURE and CMD_RET_SUCCESS defines instead
of 1 and 0.
Signed-off-by: Alexey Romanov
---
cmd/jffs2.c | 45 +++--
1 file changed, 23 insertions(+), 22 deletions(-)
diff --git a/cmd/jffs2.c b/cmd/jffs2.c
index e00fcc2022..068eeedc58 100644
--- a/cmd/jffs2.c
+++ b/cmd/jffs2.c
@@ -151,7 +151,7 @@ extern int cramfs_info (struct part_info *info);
* Check device number to be within valid range for given device type.
*
* @param dev device to validate
- * Return: 0 if device is valid, 1 otherwise
+ * Return: 0 if device is valid, -errno otherwise
*/
static int mtd_device_validate(u8 type, u8 num, u32 *size)
{
@@ -191,7 +191,7 @@ static int mtd_device_validate(u8 type, u8 num, u32 *size)
} else
printf("Unknown defice type %d\n", type);
- return 1;
+ return -EINVAL;
}
/**
@@ -202,7 +202,7 @@ static int mtd_device_validate(u8 type, u8 num, u32 *size)
* @param ret_id output pointer to next char after parse completes (output)
* @param dev_type parsed device type (output)
* @param dev_num parsed device number (output)
- * Return: 0 on success, 1 otherwise
+ * Return: 0 on success, -errno otherwise
*/
static int mtd_id_parse(const char *id, const char **ret_id, u8 *dev_type, u8
*dev_num)
{
@@ -220,12 +220,12 @@ static int mtd_id_parse(const char *id, const char
**ret_id, u8 *dev_type, u8 *d
p += 7;
} else {
printf("incorrect device type in %s\n", id);
- return 1;
+ return -EINVAL;
}
if (!isdigit(*p)) {
printf("incorrect device number in %s\n", id);
- return 1;
+ return -EINVAL;
}
*dev_num = simple_strtoul(p, (char **), 0);
@@ -328,7 +328,7 @@ static inline u32 get_part_sector_size(struct mtdids *id,
struct part_info *part
* 'Static' version of command line mtdparts_init() routine. Single partition
on
* a single device configuration.
*
- * Return: 0 on success, 1 otherwise
+ * Return: 0 on success, -errno otherwise
*/
int mtdparts_init(void)
{
@@ -348,7 +348,7 @@ int mtdparts_init(void)
sizeof(struct mtdids));
if (!current_mtd_dev) {
printf("out of memory\n");
- return 1;
+ return -ENOMEM;
}
memset(current_mtd_dev, 0, sizeof(struct mtd_device) +
sizeof(struct part_info) + sizeof(struct mtdids));
@@ -365,7 +365,7 @@ int mtdparts_init(void)
(mtd_device_validate(id->type, id->num, )
!= 0)) {
printf("incorrect device: %s%d\n",
MTD_DEV_TYPE(id->type), id->num);
free(current_mtd_dev);
- return 1;
+ return -EINVAL;
}
id->size = size;
INIT_LIST_HEAD(>link);
@@ -485,7 +485,7 @@ int do_jffs2_fsload(struct cmd_tbl *cmdtp, int flag, int
argc,
/* make sure we are in sync with env variables */
if (mtdparts_init() !=0)
- return 1;
+ return CMD_RET_FAILURE;
if ((part = jffs2_part_info(current_mtd_dev, current_mtd_partnum))){
@@ -500,17 +500,18 @@ int do_jffs2_fsload(struct cmd_tbl *cmdtp, int flag, int
argc,
size = jffs2_1pass_load((char *)offset, part, filename);
}
- if (size > 0) {
- printf("### %s load complete: %d bytes loaded to
0x%lx\n",
- fsname, size, offset);
- env_set_hex("filesize", size);
- } else {
+ if (size <= 0) {
printf("### %s LOAD ERROR<%x> for %s!\n", fsname, size,
filename);
+ return CMD_RET_FAILURE;
}
- return !(size > 0);
+ printf("### %s load complete: %d bytes loaded to 0x%lx\n",
+ fsname, size, offset);
+ env_set_hex("filesize", size);
+
+ return 0;
}
- return 1;
+ return CMD_RET_FAILURE;
}
/**
@@ -534,7 +535,7 @@ int do_jffs2_ls(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
/* make sure we are in sync with env variables */
if (mtdparts_init() !=0)
- return 1;
+ return CMD_RET_FAILURE;
if ((part = jffs2_part_info(current_mtd_dev, current_mtd_partnum))){
@@ -546,9 +547,9 @@ int do_jffs2_ls(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
ret = jffs2_1pass_ls(part, filename);
}
- return ret ? 0 : 1;
+ return ret ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
}
- return 1;
+
[PATCH v1 06/12] spi: use nand_register() instead of add_mtd_device()
Most functions that work with NAND device (for example fastboot), use the get_nand_dev_by_index() function to work with NAND MTD. In order to use this feature, SPI NAND must be registered via nand_register(). Signed-off-by: Alexey Romanov --- drivers/mtd/nand/spi/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c index 27ad6fefdb..5210332712 100644 --- a/drivers/mtd/nand/spi/core.c +++ b/drivers/mtd/nand/spi/core.c @@ -23,6 +23,7 @@ #else #include #include +#include #include #include #include @@ -1222,7 +1223,7 @@ static int spinand_probe(struct udevice *dev) #ifndef __UBOOT__ ret = mtd_device_register(mtd, NULL, 0); #else - ret = add_mtd_device(mtd); + ret = nand_register(0, mtd); #endif if (ret) goto err_spinand_cleanup; -- 2.30.1
[PATCH v1 05/12] spi: add board_nand_init() function
By analogy with RAW NAND drivers, select SYS_NAND_SELF_INIT
option and implement board_nand_init() function. It will be
called from nand_init().
Signed-off-by: Alexey Romanov
---
drivers/mtd/nand/spi/Kconfig | 1 +
drivers/mtd/nand/spi/core.c | 14 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/mtd/nand/spi/Kconfig b/drivers/mtd/nand/spi/Kconfig
index 0777dfdf0a..c9ca76a1c9 100644
--- a/drivers/mtd/nand/spi/Kconfig
+++ b/drivers/mtd/nand/spi/Kconfig
@@ -2,6 +2,7 @@ menuconfig MTD_SPI_NAND
bool "SPI NAND device Support"
depends on DM_MTD && DM_SPI
select MTD_NAND_CORE
+ select SYS_NAND_SELF_INIT
select SPI_MEM
help
This is the framework for the SPI NAND device drivers.
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 202e3f11ec..27ad6fefdb 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1296,3 +1297,16 @@ U_BOOT_DRIVER(spinand) = {
.priv_auto = sizeof(struct spinand_device),
.probe = spinand_probe,
};
+
+void board_nand_init(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_SPI,
+ DM_DRIVER_GET(spinand),
+ );
+ if (ret && ret != -ENODEV)
+ log_err("Failed to initialize SPI NAND driver. (error %d)\n",
+ ret);
+}
--
2.30.1
[PATCH v1 04/12] nand: move nand_erase_opts() to core NAND folder
Currently nand_erase_opts() placed in the nand/raw/ folder,
because it uses the RAW NAND specific API (struct nand_chip).
This patch move it to core NAND folder and make function generic,
for both RAW/SPI NAND's usage.
Also, nand_erase_opts() used in fastboot/fb_nand.c, cmd/nand.c
and env/nand.c code. This is also the reason why we should move
it to core folder and make it more general.
Signed-off-by: Alexey Romanov
---
drivers/mtd/nand/raw/nand_util.c | 153
drivers/mtd/nand/util.c | 166 +++
2 files changed, 166 insertions(+), 153 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_util.c b/drivers/mtd/nand/raw/nand_util.c
index 9c18ce63b9..f7704d4697 100644
--- a/drivers/mtd/nand/raw/nand_util.c
+++ b/drivers/mtd/nand/raw/nand_util.c
@@ -32,159 +32,6 @@
#include
#include
#include
-#include
-
-typedef struct erase_info erase_info_t;
-
-/* support only for native endian JFFS2 */
-#define cpu_to_je16(x) (x)
-#define cpu_to_je32(x) (x)
-
-/**
- * nand_erase_opts: - erase NAND flash with support for various options
- * (jffs2 formatting)
- *
- * @param mtd nand mtd instance to erase
- * @param opts options, @see struct nand_erase_options
- * Return: 0 in case of success
- *
- * This code is ported from flash_eraseall.c from Linux mtd utils by
- * Arcom Control System Ltd.
- */
-int nand_erase_opts(struct mtd_info *mtd,
- const nand_erase_options_t *opts)
-{
- struct jffs2_unknown_node cleanmarker;
- erase_info_t erase;
- unsigned long erase_length, erased_length; /* in blocks */
- int result;
- int percent_complete = -1;
- const char *mtd_device = mtd->name;
- struct mtd_oob_ops oob_opts;
- struct nand_chip *chip = mtd_to_nand(mtd);
-
- if ((opts->offset & (mtd->erasesize - 1)) != 0) {
- printf("Attempt to erase non block-aligned data\n");
- return -1;
- }
-
- memset(, 0, sizeof(erase));
- memset(_opts, 0, sizeof(oob_opts));
-
- erase.mtd = mtd;
- erase.len = mtd->erasesize;
- erase.addr = opts->offset;
- erase_length = lldiv(opts->length + mtd->erasesize - 1,
-mtd->erasesize);
-
- cleanmarker.magic = cpu_to_je16(JFFS2_MAGIC_BITMASK);
- cleanmarker.nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER);
- cleanmarker.totlen = cpu_to_je32(8);
-
- /* scrub option allows to erase badblock. To prevent internal
-* check from erase() method, set block check method to dummy
-* and disable bad block table while erasing.
-*/
- if (opts->scrub) {
- erase.scrub = opts->scrub;
- /*
-* We don't need the bad block table anymore...
-* after scrub, there are no bad blocks left!
-*/
- if (chip->bbt) {
- kfree(chip->bbt);
- }
- chip->bbt = NULL;
- chip->options &= ~NAND_BBT_SCANNED;
- }
-
- for (erased_length = 0;
-erased_length < erase_length;
-erase.addr += mtd->erasesize) {
-
- schedule();
-
- if (opts->lim && (erase.addr >= (opts->offset + opts->lim))) {
- puts("Size of erase exceeds limit\n");
- return -EFBIG;
- }
- if (!opts->scrub) {
- int ret = mtd_block_isbad(mtd, erase.addr);
- if (ret > 0) {
- if (!opts->quiet)
- printf("\rSkipping %s at "
- "0x%08llx "
- " \n",
- ret == 1 ? "bad block" : "bbt
reserved",
- erase.addr);
-
- if (!opts->spread)
- erased_length++;
-
- continue;
-
- } else if (ret < 0) {
- printf("\n%s: MTD get bad block failed: %d\n",
- mtd_device,
- ret);
- return -1;
- }
- }
-
- erased_length++;
-
- result = mtd_erase(mtd, );
- if (result != 0) {
- printf("\n%s: MTD Erase failure: %d\n",
- mtd_device, result);
- continue;
- }
-
- /* format for JFFS2 ? */
- if (opts->jffs2 && chip->ecc.layout->oobavail >= 8) {
- struct mtd_oob_ops ops;
- ops.ooblen = 8;
-
[PATCH v1 03/12] nand: move nand_util.c to NAND core folder
This is right place for this API. Now, fastboot code uses this
API: these functions should be available regardless of the
selected NAND type (RAW / SPI).
Signed-off-by: Alexey Romanov
---
drivers/mtd/nand/Makefile| 2 +-
drivers/mtd/nand/raw/nand_util.c | 511 -
drivers/mtd/nand/util.c | 543 +++
3 files changed, 544 insertions(+), 512 deletions(-)
create mode 100644 drivers/mtd/nand/util.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 96e186600a..301b1bceff 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0+
ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
-nandcore-objs := core.o bbt.o
+nandcore-objs := core.o bbt.o util.o
obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
obj-$(CONFIG_MTD_RAW_NAND) += raw/
obj-$(CONFIG_MTD_SPI_NAND) += spi/
diff --git a/drivers/mtd/nand/raw/nand_util.c b/drivers/mtd/nand/raw/nand_util.c
index 72cc24f403..9c18ce63b9 100644
--- a/drivers/mtd/nand/raw/nand_util.c
+++ b/drivers/mtd/nand/raw/nand_util.c
@@ -35,7 +35,6 @@
#include
typedef struct erase_info erase_info_t;
-typedef struct mtd_infomtd_info_t;
/* support only for native endian JFFS2 */
#define cpu_to_je16(x) (x)
@@ -395,513 +394,3 @@ int nand_unlock(struct mtd_info *mtd, loff_t start,
size_t length,
return ret;
}
#endif
-
-/**
- * check_skip_len
- *
- * Check if there are any bad blocks, and whether length including bad
- * blocks fits into device
- *
- * @param mtd nand mtd instance
- * @param offset offset in flash
- * @param length image length
- * @param used length of flash needed for the requested length
- * Return: 0 if the image fits and there are no bad blocks
- * 1 if the image fits, but there are bad blocks
- *-1 if the image does not fit
- */
-static int check_skip_len(struct mtd_info *mtd, loff_t offset, size_t length,
- size_t *used)
-{
- size_t len_excl_bad = 0;
- int ret = 0;
-
- while (len_excl_bad < length) {
- size_t block_len, block_off;
- loff_t block_start;
-
- if (offset >= mtd->size)
- return -1;
-
- block_start = offset & ~(loff_t)(mtd->erasesize - 1);
- block_off = offset & (mtd->erasesize - 1);
- block_len = mtd->erasesize - block_off;
-
- if (!nand_block_isbad(mtd, block_start))
- len_excl_bad += block_len;
- else
- ret = 1;
-
- offset += block_len;
- *used += block_len;
- }
-
- /* If the length is not a multiple of block_len, adjust. */
- if (len_excl_bad > length)
- *used -= (len_excl_bad - length);
-
- return ret;
-}
-
-#ifdef CONFIG_CMD_NAND_TRIMFFS
-static size_t drop_ffs(const struct mtd_info *mtd, const u_char *buf,
- const size_t *len)
-{
- size_t l = *len;
- ssize_t i;
-
- for (i = l - 1; i >= 0; i--)
- if (buf[i] != 0xFF)
- break;
-
- /* The resulting length must be aligned to the minimum flash I/O size */
- l = i + 1;
- l = (l + mtd->writesize - 1) / mtd->writesize;
- l *= mtd->writesize;
-
- /*
-* since the input length may be unaligned, prevent access past the end
-* of the buffer
-*/
- return min(l, *len);
-}
-#endif
-
-/**
- * nand_verify_page_oob:
- *
- * Verify a page of NAND flash, including the OOB.
- * Reads page of NAND and verifies the contents and OOB against the
- * values in ops.
- *
- * @param mtd nand mtd instance
- * @param ops MTD operations, including data to verify
- * @param ofs offset in flash
- * Return: 0 in case of success
- */
-int nand_verify_page_oob(struct mtd_info *mtd, struct mtd_oob_ops *ops,
-loff_t ofs)
-{
- int rval;
- struct mtd_oob_ops vops;
- size_t verlen = mtd->writesize + mtd->oobsize;
-
- memcpy(, ops, sizeof(vops));
-
- vops.datbuf = memalign(ARCH_DMA_MINALIGN, verlen);
-
- if (!vops.datbuf)
- return -ENOMEM;
-
- vops.oobbuf = vops.datbuf + mtd->writesize;
-
- rval = mtd_read_oob(mtd, ofs, );
- if (!rval)
- rval = memcmp(ops->datbuf, vops.datbuf, vops.len);
- if (!rval)
- rval = memcmp(ops->oobbuf, vops.oobbuf, vops.ooblen);
-
- free(vops.datbuf);
-
- return rval ? -EIO : 0;
-}
-
-/**
- * nand_verify:
- *
- * Verify a region of NAND flash.
- * Reads NAND in page-sized chunks and verifies the contents against
- * the contents of a buffer. The offset into the NAND must be
- * page-aligned, and the function doesn't handle skipping bad blocks.
- *
- * @param mtd nand mtd instance
- * @param ofs offset
[PATCH v1 01/12] nand: move NAND initialization API to nand/core.c
nand_register() and nand_init() is generic API for both
RAW and SPI NAND's. We have to move this functions
from drivers/mtd/nand/raw/nand.c to drivers/mtd/nand/core.c.
Functions designed to work with RAW NAND should remain
in drivers/mtd/nand/raw/nand.c.
Signed-off-by: Alexey Romanov
---
drivers/mtd/Kconfig | 2 +-
drivers/mtd/nand/Kconfig | 10 +++
drivers/mtd/nand/core.c | 136 +++
drivers/mtd/nand/raw/Kconfig | 10 ---
drivers/mtd/nand/raw/nand.c | 134 --
include/nand.h | 2 +
6 files changed, 149 insertions(+), 145 deletions(-)
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index c56840c849..1902351719 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -260,7 +260,7 @@ config SYS_NAND_MAX_ECCPOS
config SYS_NAND_MAX_CHIPS
int "NAND max chips"
- depends on MTD_RAW_NAND || CMD_ONENAND || TARGET_S5PC210_UNIVERSAL || \
+ depends on MTD_RAW_NAND || MTD_SPI_NAND || CMD_ONENAND ||
TARGET_S5PC210_UNIVERSAL || \
SPL_OMAP3_ID_NAND
default 1
help
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 78ae04bdcb..9a1d4ac0dc 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -1,6 +1,16 @@
config MTD_NAND_CORE
tristate
+config SYS_MAX_NAND_DEVICE
+ int "Maximum number of NAND devices to support"
+ default 1
+
+config SYS_NAND_SELF_INIT
+ bool
+ help
+ This option, if enabled, provides more flexible and linux-like
+ NAND initialization process.
+
source "drivers/mtd/nand/raw/Kconfig"
source "drivers/mtd/nand/spi/Kconfig"
diff --git a/drivers/mtd/nand/core.c b/drivers/mtd/nand/core.c
index 4b9dd6a926..ff298e3a0f 100644
--- a/drivers/mtd/nand/core.c
+++ b/drivers/mtd/nand/core.c
@@ -10,6 +10,7 @@
#define pr_fmt(fmt)"nand: " fmt
#include
+#include
#include
#ifndef __UBOOT__
#include
@@ -18,6 +19,12 @@
#include
#include
+int nand_curr_device = -1;
+
+static struct mtd_info *nand_info[CONFIG_SYS_MAX_NAND_DEVICE];
+static char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][8];
+static unsigned long total_nand_size; /* in kiB */
+
/**
* nanddev_isbad() - Check if a block is bad
* @nand: NAND device
@@ -250,6 +257,135 @@ void nanddev_cleanup(struct nand_device *nand)
}
EXPORT_SYMBOL_GPL(nanddev_cleanup);
+struct mtd_info *get_nand_dev_by_index(int dev)
+{
+ if (dev < 0 || dev >= CONFIG_SYS_MAX_NAND_DEVICE || !nand_info[dev] ||
+ !nand_info[dev]->name)
+ return NULL;
+
+ return nand_info[dev];
+}
+EXPORT_SYMBOL_GPL(get_nand_dev_by_index);
+
+int nand_mtd_to_devnum(struct mtd_info *mtd)
+{
+ int i;
+
+ for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++) {
+ if (mtd && get_nand_dev_by_index(i) == mtd)
+ return i;
+ }
+
+ return -ENODEV;
+}
+EXPORT_SYMBOL_GPL(nand_mtd_to_devnum);
+
+/* Register an initialized NAND mtd device with the U-Boot NAND command. */
+int nand_register(int devnum, struct mtd_info *mtd)
+{
+ if (devnum >= CONFIG_SYS_MAX_NAND_DEVICE)
+ return -EINVAL;
+
+ nand_info[devnum] = mtd;
+
+ sprintf(dev_name[devnum], "nand%d", devnum);
+ mtd->name = dev_name[devnum];
+
+#ifdef CONFIG_MTD
+ /*
+* Add MTD device so that we can reference it later
+* via the mtdcore infrastructure (e.g. ubi).
+*/
+ add_mtd_device(mtd);
+#endif
+
+ total_nand_size += mtd->size / 1024;
+
+ if (nand_curr_device == -1)
+ nand_curr_device = devnum;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(nand_register);
+
+#ifdef CONFIG_MTD_CONCAT
+static void create_mtd_concat(void)
+{
+ struct mtd_info *nand_info_list[CONFIG_SYS_MAX_NAND_DEVICE];
+ int nand_devices_found = 0;
+ int i;
+
+ for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++) {
+ struct mtd_info *mtd = get_nand_dev_by_index(i);
+ if (mtd != NULL) {
+ nand_info_list[nand_devices_found] = mtd;
+ nand_devices_found++;
+ }
+ }
+ if (nand_devices_found > 1) {
+ struct mtd_info *mtd;
+ char c_mtd_name[16];
+
+ /*
+* We detected multiple devices. Concatenate them together.
+*/
+ sprintf(c_mtd_name, "nand%d", nand_devices_found);
+ mtd = mtd_concat_create(nand_info_list, nand_devices_found,
+ c_mtd_name);
+
+ if (mtd == NULL)
+ return;
+
+ nand_register(nand_devices_found, mtd);
+ }
+
+ return;
+}
+#else
+static void create_mtd_concat(void)
+{
+}
+#endif
+
+unsigned long nand_size(void)
+{
+ return total_nand_size;
+}
+EXPORT_SYMBOL_GPL(nand_size);
+
+void nand_init(void)
+{
+ static int
[PATCH v1 00/12] Support SPI NAND in fastboot protocol
Currently, fastboot in U-Boot doens't support SPI NAND devices. This patchset adds support for SPI NAND in fastboot nand subsystem. Alexey Romanov (12): nand: move NAND initialization API to nand/core.c nand: don't overwrite mtd name in nand_register() nand: move nand_util.c to NAND core folder nand: move nand_erase_opts() to core NAND folder spi: add board_nand_init() function spi: use nand_register() instead of add_mtd_device() mtdparts: use negative error codes jffs2: use negative error codes cmd: allow to enable CMD_NAND for SPI NAND devices fastboot: check device type for SPI NAND too fastboot: enable FASTBOOT_FLASH option for SPI NAND devices fastboot: fb_nand: add missing newlines in pr_err() macro cmd/Kconfig | 2 +- cmd/jffs2.c | 45 +- cmd/mtdparts.c | 154 +++ drivers/fastboot/Kconfig | 4 +- drivers/fastboot/fb_nand.c | 12 +- drivers/mtd/Kconfig | 2 +- drivers/mtd/nand/Kconfig | 10 + drivers/mtd/nand/Makefile| 2 +- drivers/mtd/nand/core.c | 140 ++ drivers/mtd/nand/raw/Kconfig | 10 - drivers/mtd/nand/raw/nand.c | 134 -- drivers/mtd/nand/raw/nand_util.c | 664 - drivers/mtd/nand/spi/Kconfig | 1 + drivers/mtd/nand/spi/core.c | 17 +- drivers/mtd/nand/util.c | 709 +++ include/nand.h | 2 + 16 files changed, 989 insertions(+), 919 deletions(-) create mode 100644 drivers/mtd/nand/util.c -- 2.30.1
[PATCH v1 02/12] nand: don't overwrite mtd name in nand_register()
We use this function in SPI NAND subsystem, which already
filled mtd->name field with "spi-nand0" string.
Signed-off-by: Alexey Romanov
---
drivers/mtd/nand/core.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/core.c b/drivers/mtd/nand/core.c
index ff298e3a0f..5a63e74ccb 100644
--- a/drivers/mtd/nand/core.c
+++ b/drivers/mtd/nand/core.c
@@ -22,7 +22,7 @@
int nand_curr_device = -1;
static struct mtd_info *nand_info[CONFIG_SYS_MAX_NAND_DEVICE];
-static char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][8];
+static char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][16];
static unsigned long total_nand_size; /* in kiB */
/**
@@ -288,8 +288,12 @@ int nand_register(int devnum, struct mtd_info *mtd)
nand_info[devnum] = mtd;
- sprintf(dev_name[devnum], "nand%d", devnum);
- mtd->name = dev_name[devnum];
+ if (!strlen(mtd->name)) {
+ snprintf(dev_name[devnum], ARRAY_SIZE(dev_name[devnum]),
"nand%d", devnum);
+ mtd->name = dev_name[devnum];
+ } else {
+ strlcpy(dev_name[devnum], mtd->name,
ARRAY_SIZE(dev_name[devnum]));
+ }
#ifdef CONFIG_MTD
/*
--
2.30.1
[PATCH v1] fastboot: introduce 'oem board' subcommand
Currently, fastboot protocol in U-Boot has no opportunity
to execute vendor custom code with verifed boot. This patch
introduce new fastboot subcommand fastboot oem board:,
which allow to run custom oem_board function.
Default implementation is __weak. Vendor must redefine it in
board/ folder with his own logic.
For example, some vendors have their custom nand/emmc partition
flashing or erasing. Here some typical command for such use cases:
- flashing:
$ fastboot stage bootloader.img
$ fastboot oem board:write_bootloader
- erasing:
$ fastboot oem board:erase_env
Signed-off-by: Alexey Romanov
---
drivers/fastboot/Kconfig | 7 +++
drivers/fastboot/fb_command.c | 15 +++
include/fastboot.h| 1 +
3 files changed, 23 insertions(+)
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index 3cfeea4837..4c955cabab 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -241,6 +241,13 @@ config FASTBOOT_OEM_RUN
this feature if you are using verified boot, as it will allow an
attacker to bypass any restrictions you have in place.
+config FASTBOOT_OEM_BOARD
+ bool "Enable the 'oem board' command"
+ help
+ This extends the fastboot protocol with an "oem board" command. This
+ command allows running vendor custom code defined in board/ files.
+ Otherwise, it will do nothing and send fastboot fail.
+
endif # FASTBOOT
endmenu
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 71cfaec6e9..4d2b451f46 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -39,6 +39,7 @@ static void reboot_recovery(char *, char *);
static void oem_format(char *, char *);
static void oem_partconf(char *, char *);
static void oem_bootbus(char *, char *);
+static void oem_board(char *, char *);
static void run_ucmd(char *, char *);
static void run_acmd(char *, char *);
@@ -106,6 +107,10 @@ static const struct {
.command = "oem run",
.dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_RUN, (run_ucmd),
(NULL))
},
+ [FASTBOOT_COMMAND_OEM_BOARD] = {
+ .command = "oem board",
+ .dispatch = CONFIG_IS_ENABLED(FASTBOOT_OEM_BOARD, (oem_board),
(NULL))
+ },
[FASTBOOT_COMMAND_UCMD] = {
.command = "UCmd",
.dispatch = CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT, (run_ucmd),
(NULL))
@@ -489,3 +494,13 @@ static void __maybe_unused oem_bootbus(char
*cmd_parameter, char *response)
else
fastboot_okay(NULL, response);
}
+
+void __weak fastboot_oem_board(char *cmd_parameter, void *data, u32 size, char
*response)
+{
+ fastboot_fail("oem board function not defined", response);
+}
+
+static void __maybe_unused oem_board(char *cmd_parameter, char *response)
+{
+ fastboot_oem_board(cmd_parameter, fastboot_buf_addr, image_size,
response);
+}
diff --git a/include/fastboot.h b/include/fastboot.h
index 296451f89d..06c1f26b6c 100644
--- a/include/fastboot.h
+++ b/include/fastboot.h
@@ -37,6 +37,7 @@ enum {
FASTBOOT_COMMAND_OEM_PARTCONF,
FASTBOOT_COMMAND_OEM_BOOTBUS,
FASTBOOT_COMMAND_OEM_RUN,
+ FASTBOOT_COMMAND_OEM_BOARD,
FASTBOOT_COMMAND_ACMD,
FASTBOOT_COMMAND_UCMD,
FASTBOOT_COMMAND_COUNT
--
2.30.1
[PATCH v1] arch: meson: add helper for boot partitition flashing
Amlogic uses its own scheme for flashing bootloader
partition. This patch adds helper function that can
be used by Amlogic BootROM and custom protocols.
Signed-off-by: Alexey Romanov
---
arch/arm/include/asm/arch-meson/nand.h | 88
arch/arm/mach-meson/Kconfig| 16 +++
arch/arm/mach-meson/Makefile | 2 +-
arch/arm/mach-meson/nand.c | 133 +
4 files changed, 238 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/asm/arch-meson/nand.h
create mode 100644 arch/arm/mach-meson/nand.c
diff --git a/arch/arm/include/asm/arch-meson/nand.h
b/arch/arm/include/asm/arch-meson/nand.h
new file mode 100644
index 00..5297d79dd6
--- /dev/null
+++ b/arch/arm/include/asm/arch-meson/nand.h
@@ -0,0 +1,88 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2023 SaluteDevices, Inc.
+ */
+
+#ifndef __MESON_NAND_H__
+#define __MESON_NAND_H__
+
+#include
+
+#define BOOT_LOADER "bootloader"
+#define BOOT_BL2"bl2"
+#define BOOT_SPL"spl"
+#define BOOT_TPL"tpl"
+#define BOOT_FIP"fip"
+
+#define BL2_COPY_NUM(CONFIG_MESON_BL2_COPY_NUM)
+#define TPL_COPY_NUM(CONFIG_MESON_TPL_COPY_NUM)
+#define BOOT_TOTAL_PAGES1024
+#define TPL_SIZE_PER_COPY 0x20
+#define BL2_SIZE(64 * 1024)
+
+struct meson_spi_nand_info_page {
+ char magic[8]; /* Magic header of info page. */
+ /* Info page version, +1 when you update this struct. */
+ u8 version; /* 1 for now. */
+ u8 mode;/* 1 discrete, 0 compact. */
+ u8 bl2_num; /* bl2 copy number. */
+ u8 fip_num; /* fip copy number. */
+ union {
+ struct {
+ u8 rd_max; /* spi nand max read io. */
+ u8 oob_offset; /* User bytes offset. */
+ u8 planes_per_lun;
+ u8 rsv;
+ u32 fip_start; /* Start pages. */
+ u32 fip_pages; /* Pages per fip. */
+ u32 page_size; /* spi nand page size (bytes). */
+ u32 page_per_blk; /* Page number per block. */
+ u32 oob_size; /* Valid oob size (bytes). */
+ u32 bbt_start; /* BBT start pages. */
+ u32 bbt_valid; /* BBT valid offset pages. */
+ u32 bbt_size; /* BBT occupied bytes. */
+ } __packed spinand; /* spi nand. */
+ struct {
+ u32 reserved;
+ } emmc;
+ } dev;
+} __packed;
+
+/**
+ * meson_bootloader_copy_num - get bootloader numbers of copies
+ *
+ * @part_name: partition name
+ * @return: number of copies of the specified bootloader partition
+ */
+int meson_bootloader_copy_num(const char *part_name);
+
+/**
+ * meson_bootloader_copy_size - get bootloader copy size in bytes
+ *
+ * @mtd: nand mtd instance
+ * @part_name: partition name
+ * @return: bootloader partition (fox example, BL2) copy size in bytes
+ */
+int meson_bootloader_copy_size(struct mtd_info *mtd, const char *part_name);
+
+/**
+ * meson_bootloader_write_info_pages - write bootloader metadata to nand
+ *
+ * @return: zero on success or error code on failure.
+ */
+int meson_bootloader_write_info_pages(void);
+
+/**
+ * meson_bootloader_write_bl2 - write bl2 to nand
+ *
+ * @mtd: nand mtd instance
+ * @buff: buffer to read from
+ * @offset: offset in flash
+ * @size: buffer length
+ * @flags: flags modifying the behaviour of the write to NAND
+ * @return: zero on success or error code on failure
+ */
+int meson_bootloader_write_bl2(struct mtd_info *mtd, void *buff, u32 offset,
+ size_t size, int flags);
+
+#endif
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index d6c8905806..7b75ed9a2b 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -96,4 +96,20 @@ config SYS_CONFIG_NAME
Based on this option include/configs/.h header
will be used for board configuration.
+config MESON_BL2_COPY_NUM
+ depends on ADNL || FASTBOOT_FLASH
+ int "Number of BL2 copies written to storage"
+ default 0
+ help
+ The ADNL / fastboot protocol writes several copies of BL2
bootloader
+ during firmware update process.
+
+config MESON_TPL_COPY_NUM
+ depends on ADNL || FASTBOOT_FLASH
+ int "Number of TPL copies written to storage"
+ default 0
+ help
+ The ADNL / fastboot protocol writes several copies of TPL
bootloader
+ during firmware update process.
+
endif
diff --git a/arch/arm/mach-meson/Makefile b/arch/arm/mach-meson/Makefile
index 535b0878b9..460626bca9 100644
--- a/arch/arm/mach-meson/Makefile
+++ b/arch/arm/mach-meson/Makefile
@@ -2,7 +2,7 @@
#
# Copyright (c)
Re: [PATCH 0/9] dts: Move to SoC-specific build rules
On Thu, Dec 28, 2023 at 03:09:40PM +, Simon Glass wrote: > Hi Tom, > > On Thu, Dec 28, 2023 at 2:23 PM Tom Rini wrote: > > > > On Thu, Dec 28, 2023 at 01:37:07PM +, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, Dec 27, 2023 at 1:21 PM Tom Rini wrote: > > > > > > > > On Wed, Dec 27, 2023 at 08:23:56AM +, Simon Glass wrote: > > > > > > > > > U-Boot builds devicetree binaries from its source tree. As part of the > > > > > Kconfig conversion, the Makefiles were updated to align with how this > > > > > is done in Linux: a single target for each SoC is used to build all > > > > > the > > > > > .dtb files for that SoC. > > > > > > > > > > Since then, the Makefiles have devolved in some cases, resulting in > > > > > lots of target-specific build rules. Also Linux has moved to using > > > > > subdirectories for each vendor. > > > > > > > > > > Recent work aims to allow U-Boot to directly use devicetree files from > > > > > Linux. This would be easier if the directory structure were the same. > > > > > Another recent discussion involved dropping the build rules > > > > > altogether. > > > > > > > > > > This series makes a start at cleaning up some of the build rules, to > > > > > reduce the amount of code and make it easier to add new boards for the > > > > > same SoC. > > > > > > > > > > One issue is that the ARCH_xxx Kconfig options between U-Boot and > > > > > Linux > > > > > are not always the same. Given the large number of SoCs and boards > > > > > supported by U-Boot, it would be useful to align these where possible. > > > > > > > > I don't know why we should start with this now, and further not being on > > > > top of Sumit's series to remove our duplicate dts files. And that's > > > > where we can have the conversation about for which cases it even makes > > > > sense to build all of the dts files for a given SoC. > > > > > > This is a completely different series - there are no conflicts with > > > Sumit's series so it can be applied before or after it. > > > > > > My goal here is to clean up our build rules, rather than just throwing > > > them all away, for reasons we have discussed previously. I filed [1] > > > to track that. > > > > Yes, I'm saying we shouldn't be doing anything this series does until > > after Sumit's series has landed. Along with the fact that I don't like > > what's going on in this series. > > This seems to again be the disagreement over whether a single DT > should be build for each board, or all the DTs for an SoC? It's about the disagreement on what we should be building, and what that infrastructure looks like. I do not like adding extra rules for "clarity" because they don't make things clearer, they lead to the unclear mess we have today getting worse. Most instructions are _not_ "now take this dtb and this binary and .." but just "take this binary", because we already have the rules and logic to ensure we build the required dtbs. I also don't like the parts of this series that amount to deck shuffling when we should just be taking the chairs away. There's just not nor will there be a case for omap3/4/5 platforms of "change the dtb", so building more is pointless. For other SoCs, there may be some cases of "this could have been just a DT change", like rock5b-rk3588_defconfig / rock5a-rk3588s_defconfig could share a board dir, but the configs are different and the dts are different, so I don't know that you could really just swap the dtbs. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4] fdt: Allow the devicetree to come from a bloblist
On Thu, Dec 28, 2023 at 03:09:45PM +, Simon Glass wrote: > Hi Tom, > > On Thu, Dec 28, 2023 at 1:48 PM Tom Rini wrote: > > > > On Thu, Dec 28, 2023 at 01:37:39PM +, Simon Glass wrote: > > > Hi Tom, > > > > > > > > > On Wed, Dec 27, 2023 at 8:06 PM Tom Rini wrote: > > > > > > > > On Wed, Dec 27, 2023 at 05:48:42PM +, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Tue, Dec 26, 2023 at 12:07 PM Tom Rini wrote: > > > > > > > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +, Simon Glass wrote: > > > > > > > > > > > > > Standard passage provides for a bloblist to be passed from one > > > > > > > firmware > > > > > > > phase to the next. That can be used to pass the devicetree along > > > > > > > as well. > > > > > > > Add an option to support this. > > > > > > > > > > > > > > Tests for this will be added as part of the Universal Payload > > > > > > > work. > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > --- > > > > > > > The discussion on this was not resolved and is now important due > > > > > > > to the > > > > > > > bloblist series from Raymond. So I am sending it again since I > > > > > > > believe > > > > > > > this is a better starting point than building on OF_BOARD > > > > > > > > > > > > I really don't like adding another option for "DT is given to us". > > > > > > Why > > > > > > isn't adding another enum to fdt_source_t sufficient > > > > > > > > > > That is added by this patch, but... > > > > > > > > > > >, and if we have > > > > > > bloblist enabled, that will look for and use if found? > > > > > > > > > > ...this is the question. I would like to be able to enable bloblist > > > > > without *requiring* the DT to come from there, hence the separate > > > > > Kconfig option. > > > > > > > > > > > Maybe some other > > > > > > code needs to be restructured and cleaned up too? > > > > > > > > > > Possibly, but I really am not keen on this board-specific solution. I > > > > > believe Ilias & I agreed that OF_BOARD should fade away, so I don't > > > > > like adding another thing onto it. > > > > > > > > I think you're missing something then. It should not be board specific > > > > to just find the dtb via bloblist, without a new CONFIG. > > > > > > Yes, that is what I am looking for. > > > > > > > Whatever is > > > > stopping that is what needs to be refactored and then you can just > > > > extend fdt_source_t without a new CONFIG option. > > > > > > OK, but I need a way to turn it off, at least for development. > > > > > > [merging in the other thread:] > > > > > > On Wed, Dec 27, 2023 at 8:11 PM Tom Rini wrote: > > > > > > > > On Wed, Dec 27, 2023 at 05:48:44PM +, Simon Glass wrote: > > > > > Hi Ilias, > > > > > > > > > > On Wed, Dec 27, 2023 at 6:44 AM Ilias Apalodimas > > > > > wrote: > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > On Tue, 26 Dec 2023 at 14:07, Tom Rini wrote: > > > > > > > > > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +, Simon Glass wrote: > > > > > > > > > > > > > > > Standard passage provides for a bloblist to be passed from one > > > > > > > > firmware > > > > > > > > phase to the next. That can be used to pass the devicetree > > > > > > > > along as well. > > > > > > > > Add an option to support this. > > > > > > > > > > > > > > > > Tests for this will be added as part of the Universal Payload > > > > > > > > work. > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > --- > > > > > > > > The discussion on this was not resolved and is now important > > > > > > > > due to the > > > > > > > > bloblist series from Raymond. So I am sending it again since I > > > > > > > > believe > > > > > > > > this is a better starting point than building on OF_BOARD > > > > > > > > > > > > > > I really don't like adding another option for "DT is given to > > > > > > > us". Why > > > > > > > isn't adding another enum to fdt_source_t sufficient, and if we > > > > > > > have > > > > > > > bloblist enabled, that will look for and use if found? Maybe some > > > > > > > other > > > > > > > code needs to be restructured and cleaned up too? > > > > > > > > > > > > Same here. On top of that the bloblist has a few items in there, > > > > > > e.g a > > > > > > TPM eventlog. What are we going to do? Add a Kconfig for each item? > > > > > > > > > > No, but that is just a straw man. The DT is special and U-Boot reports > > > > > where it comes from. > > > > > > > > > > > > > > > > > This has been going back and forth for a while. I've lost count of > > > > > > how > > > > > > many times I repeated the same proposal, but here it goes again. We > > > > > > have OF_BOARD and BLOBLIST options. The bloblist and its properties > > > > > > are scannable at runtime. Can't we use the combination of these 2 > > > > > > can > > > > > > be used to imply we expect things from a bloblist. If we want to be > > > > > > stricter in the future and explicitly expect the DT from a bloblist, > > > > > > we could add a
Re: [PATCH v3 7/8] dts: meson-gxbb: Switch to using upstream DT
On Thu, Dec 28, 2023 at 03:09:41PM +, Simon Glass wrote: > Hi Tom, > > On Thu, Dec 28, 2023 at 1:56 PM Tom Rini wrote: > > > > On Thu, Dec 28, 2023 at 01:37:11PM +, Simon Glass wrote: > > > Hi Sumit, > > > > > > On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg wrote: > > > > > > > > Although there were still some variations in board DTS files based on > > > > meson-gxbb SoC but I think those were minor differences from upstream > > > > and shouldn't impact boot on these devices. > > > > > > > > So switch to upstream DT via mirroring amlogic/ directory from > > > > devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly > > > > building DTB from there including *-u-boot.dtsi files from > > > > arch/$(ARCH)/dts/ directory. > > > > > > > > Reviewed-by: Neil Armstrong > > > > Signed-off-by: Sumit Garg > > > > --- > > > > > > > > Changes in v3: > > > > -- > > > > - Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead. > > > > > > > > Changes in v2: > > > > -- > > > > - Picked up review tag > > > > > > > > arch/arm/mach-meson/Kconfig | 1 + > > > > configs/nanopi-k2_defconfig | 2 +- > > > > configs/odroid-c2_defconfig | 2 +- > > > > configs/p200_defconfig| 2 +- > > > > configs/p201_defconfig| 2 +- > > > > configs/videostrong-kii-pro_defconfig | 2 +- > > > > configs/wetek-hub_defconfig | 2 +- > > > > configs/wetek-play2_defconfig | 2 +- > > > > dts/arch/arm64/amlogic| 1 + > > > > 9 files changed, 9 insertions(+), 7 deletions(-) > > > > create mode 12 dts/arch/arm64/amlogic > > > > > > > > > > Reviewed-by: Simon Glass > > > > > > > diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig > > > > index d6c89058061..8ddb59161a0 100644 > > > > --- a/arch/arm/mach-meson/Kconfig > > > > +++ b/arch/arm/mach-meson/Kconfig > > > > @@ -25,6 +25,7 @@ choice > > > > config MESON_GXBB > > > > bool "GXBB" > > > > select MESON_GX > > > > + imply OF_UPSTREAM > > > > help > > > > Select this if your SoC is an S905 > > > > > > > > diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig > > > > index 41dbf7981f8..2e1c756bf7a 100644 > > > > --- a/configs/nanopi-k2_defconfig > > > > +++ b/configs/nanopi-k2_defconfig > > > > @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > > > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000 > > > > CONFIG_ENV_SIZE=0x2000 > > > > CONFIG_DM_GPIO=y > > > > -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" > > > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" > > > > CONFIG_OF_LIBFDT_OVERLAY=y > > > > CONFIG_DM_RESET=y > > > > CONFIG_DEBUG_UART_BASE=0xc81004c0 > > > > > > So now I am wondering if we can (later) have the SoC be implied when > > > using OF_UPSTREAM so we can do: > > > > > > CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" > > > > > > and it will add the 'amlogic/' automatically? > > > > > > Perhaps that might be a way to bridge the gap in terms of file layout? > > > > That's going to start to look real ugly real quick I suspect and I'm not > > sure what it really gets us? It seems to me that the convention of > > "vendor/board" has already been well enough adapted outside of the > > kernel, with the odd sticking point being getting everyone used to > > whatever will be happening for 32bit boards long term. So I think hiding > > the vendor part of the string here will be more, not less, confusing > > long term. > > Now that I dig in a bit, I see that the devicetree-rebasing tree does > not have any Makefiles in it. How does Linux build with it? Does > anyone have instructions? Linux doesn't build with it, it's the relevant parts of the kernel tree extracted for other projects to more easily use (more or less). -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 4/9] arm: armv7: save boot arguments
Hi Simon,
On Thu, 28 Dec 2023 at 08:37, Simon Glass wrote:
> Hi Raymond,
>
> On Wed, Dec 27, 2023 at 3:52 PM Raymond Mao
> wrote:
> >
> > Hi Simon,
> >
> > On Tue, 26 Dec 2023 at 04:48, Simon Glass wrote:
> >>
> >> Hi Raymond,
> >>
> >> On Fri, Dec 22, 2023 at 9:31 PM Raymond Mao
> wrote:
> >> >
> >> > Save boot arguments r[0-3] into an array for handover of bloblist from
> >> > previous boot stage.
> >> >
> >> > Signed-off-by: Raymond Mao
> >> > ---
> >> > Changes in v2
> >> > - New patch file created for v2.
> >> > Changes in v3
> >> > - Swap value of r0 with r2.
> >> >
> >> > arch/arm/cpu/armv7/start.S | 13 +
> >> > 1 file changed, 13 insertions(+)
> >> >
> >> > diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> >> > index 69e281b086..2ca63ca32c 100644
> >> > --- a/arch/arm/cpu/armv7/start.S
> >> > +++ b/arch/arm/cpu/armv7/start.S
> >> > @@ -152,9 +152,22 @@ ENDPROC(c_runtime_cpu_setup)
> >> > *
> >> >
> */
> >> > WEAK(save_boot_params)
> >> > +#if (IS_ENABLED(CONFIG_OF_BOARD) && IS_ENABLED(CONFIG_BLOBLIST))
> >> > + ldr r12, =saved_args
> >> > + /* Intentionally swapping r0 with r2 */
> >> > + stm r12, {r2, r1, r0, r3}
> >>
> >> I thought the instruction was a bitmap, so what does the 'swapping'
> >> actually change?
> >>
> > The swapping is due to different register conventions between aarch32
> and aarch64.
> > Actually swapping here is to avoid the complexity of swapping this in C
> code.
> > I will update the comments here.
> >
> > [...]
>
> But how does this work? stm does not support changing the
> ordering...what am I missing?
>
Ah, my bad. You are right. I have to use `str` to store one by one in this
case.
[...]
Thanks and regards,
Raymond
Re: [PATCH] Add imx93-var-som support
[Adding Peng] On Thu, Dec 28, 2023 at 12:20 PM Fabio Estevam wrote: > > Hi Mathieu, > > On Thu, Dec 28, 2023 at 11:54 AM Mathieu Othacehe > wrote: > > > For now, I am testing the bootloaders I produce using those > > instructions: > > https://variwiki.com/index.php?title=Yocto_Build_U-Boot=mx93-yocto-mickledore-6.1.36_2.1.0-v1.1 > > > > I understand that it would be nice to have u-boot do the image > > construction with the firmware, ATF and so on, like implemented on > > imx8. > > Please give it a try to add binman support to build the U-Boot binary for > imx93. > > I am adding Peng Fan here in case he could help. > > Unfortunately, I don't have any imx93 board to help with this.
Re: [PATCH] Add imx93-var-som support
Hi Mathieu, On Thu, Dec 28, 2023 at 11:54 AM Mathieu Othacehe wrote: > For now, I am testing the bootloaders I produce using those > instructions: > https://variwiki.com/index.php?title=Yocto_Build_U-Boot=mx93-yocto-mickledore-6.1.36_2.1.0-v1.1 > > I understand that it would be nice to have u-boot do the image > construction with the firmware, ATF and so on, like implemented on > imx8. Please give it a try to add binman support to build the U-Boot binary for imx93. I am adding Peng Fan here in case he could help. Unfortunately, I don't have any imx93 board to help with this.
Re: [PATCH v3 1/9] bloblist: add API to check the register conventions
Hi Simon,
On Thu, 28 Dec 2023 at 08:38, Simon Glass wrote:
> Hi Raymond,
>
> On Wed, Dec 27, 2023 at 4:06 PM Raymond Mao
> wrote:
> >
> > Hi Simon,
> >
> > On Tue, 26 Dec 2023 at 04:48, Simon Glass wrote:
> >>
> >> Hi Raymond,
> >>
> >> On Fri, Dec 22, 2023 at 9:31 PM Raymond Mao
> wrote:
> >> >
> >> > Add bloblist_check_reg_conv() to check whether the bloblist is
> compliant
> >> > to the register conventions defined in Firmware Handoff specification.
> >> > This API can be used for all Arm platforms.
> >> >
> >> > Signed-off-by: Raymond Mao
> >> > ---
> >> > Changes in v2
> >> > - Refactor of bloblist_check_reg_conv().
> >> > Changes in v3
> >> > - bloblist_check_reg_conv() returns -ENOENT if OF_BOARD is disabled.
> >> >
> >> > common/bloblist.c | 13 +
> >> > include/bloblist.h | 12
> >> > 2 files changed, 25 insertions(+)
> >> >
> >> > diff --git a/common/bloblist.c b/common/bloblist.c
> >> > index 625e480f6b..ba17dd851a 100644
> >> > --- a/common/bloblist.c
> >> > +++ b/common/bloblist.c
> >> > @@ -542,3 +542,16 @@ int bloblist_maybe_init(void)
> >> >
> >> > return 0;
> >> > }
> >> > +
> >> > +int bloblist_check_reg_conv(ulong rfdt, ulong rzero)
> >> > +{
> >> > + if (!IS_ENABLED(CONFIG_OF_BOARD))
> >> > + return -ENOENT;
> >> > +
> >> > + if (rzero || rfdt !=
> (ulong)bloblist_find(BLOBLISTT_CONTROL_FDT, 0)) {
> >> > + gd->bloblist = NULL; /* Reset the gd bloblist
> pointer */
> >> > + return -EIO;
> >> > + }
> >>
> >> Where does the magic 4a0fb10b value get checked?
> >>
> > The magic and version of register conventions cannot be checked now
> since there is
> > a bug in the spec. PSB:
> > ```
> > X1[23:0]: set to the TL signature (4a0f_b10b)
>
> That should say 0f_b10b
>
> However, currently we have switched to `4a0f_b10b` in both TF-A and OP-TEE.
I don't want to break the dataflow that is currently working.
I prefer to make patches to TF-A, OP-TEE and U-Boot at the same time when
spec v1.0 is ready.
[...]
Thanks and regards,
Raymond
[PATCH v2] Add imx93-var-som support
From: Mathieu Othacehe
Add support for the Variscite VAR-SOM-IMX93 evaluation kit. The SoM
consists of an NXP iMX93 dual A55 CPU. The SoM is mounted on a Variscite
Symphony SBC.
Signed-off-by: Mathieu Othacehe
---
v1: https://lists.denx.de/pipermail/u-boot/2023-December/539825.html
Changes in v2:
- Use the device-trees that have been proposed here:
https://lore.kernel.org/linux-devicetree/20231227170919.8771-1-othac...@gnu.org/T/#t
- Add a MAINTAINERS file
- Remove the EXTCON_PTN5150 driver
- Use an env file
- Remove useless defines from imx93_var_som.h.
arch/arm/dts/Makefile |3 +-
.../dts/imx93-var-som-symphony-u-boot.dtsi| 251 +++
arch/arm/dts/imx93-var-som-symphony.dts | 305
arch/arm/dts/imx93-var-som.dtsi | 111 ++
arch/arm/include/asm/arch-imx9/clock.h|1 +
arch/arm/mach-imx/imx9/Kconfig|6 +
board/variscite/common/eth.c | 59 +
board/variscite/common/eth.h | 12 +
board/variscite/common/imx9_eeprom.c | 190 +++
board/variscite/common/imx9_eeprom.h | 83 +
board/variscite/common/mmc.c | 47 +
board/variscite/imx93_var_som/Kconfig | 12 +
board/variscite/imx93_var_som/MAINTAINERS |7 +
board/variscite/imx93_var_som/Makefile| 18 +
board/variscite/imx93_var_som/imx93_var_som.c | 126 ++
.../variscite/imx93_var_som/imx93_var_som.env | 104 ++
.../variscite/imx93_var_som/lpddr4x_timing.c | 1489 +
board/variscite/imx93_var_som/spl.c | 144 ++
configs/imx93_var_som_defconfig | 156 ++
include/configs/imx93_var_som.h | 48 +
20 files changed, 3171 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/imx93-var-som-symphony-u-boot.dtsi
create mode 100644 arch/arm/dts/imx93-var-som-symphony.dts
create mode 100644 arch/arm/dts/imx93-var-som.dtsi
create mode 100644 board/variscite/common/eth.c
create mode 100644 board/variscite/common/eth.h
create mode 100644 board/variscite/common/imx9_eeprom.c
create mode 100644 board/variscite/common/imx9_eeprom.h
create mode 100644 board/variscite/common/mmc.c
create mode 100644 board/variscite/imx93_var_som/Kconfig
create mode 100644 board/variscite/imx93_var_som/MAINTAINERS
create mode 100644 board/variscite/imx93_var_som/Makefile
create mode 100644 board/variscite/imx93_var_som/imx93_var_som.c
create mode 100644 board/variscite/imx93_var_som/imx93_var_som.env
create mode 100644 board/variscite/imx93_var_som/lpddr4x_timing.c
create mode 100644 board/variscite/imx93_var_som/spl.c
create mode 100644 configs/imx93_var_som_defconfig
create mode 100644 include/configs/imx93_var_som.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9d28a485bec..b32b949f80c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1124,7 +1124,8 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mq-librem5-r4.dtb
dtb-$(CONFIG_ARCH_IMX9) += \
- imx93-11x11-evk.dtb
+ imx93-11x11-evk.dtb \
+ imx93-var-som-symphony.dtb
dtb-$(CONFIG_ARCH_IMXRT) += imxrt1050-evk.dtb \
imxrt1020-evk.dtb \
diff --git a/arch/arm/dts/imx93-var-som-symphony-u-boot.dtsi
b/arch/arm/dts/imx93-var-som-symphony-u-boot.dtsi
new file mode 100644
index 000..4612a1bfd26
--- /dev/null
+++ b/arch/arm/dts/imx93-var-som-symphony-u-boot.dtsi
@@ -0,0 +1,251 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2022 NXP
+ * Copyright 2023 Variscite Ltd.
+ */
+
+/ {
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ bootph-pre-ram;
+ };
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+};
+
+&{/soc@0} {
+ bootph-all;
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+ bootph-all;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+_usdhc2_vmmc {
+ u-boot,off-on-delay-us = <2>;
+ bootph-pre-ram;
+};
+
+_reg_usdhc2_vmmc {
+ bootph-pre-ram;
+};
+
+_uart1 {
+ bootph-pre-ram;
+};
+
+_usdhc2 {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+};
+
+ {
+ bootph-pre-ram;
+ fsl,signal-voltage-switch-extra-delay-ms = <8>;
+};
+
+ {
+ compatible = "fsl,imx-eqos";
+};
+
+ {
+ reset-gpios = < 7 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <15000>;
+ reset-deassert-us = <10>;
+};
+
+ {
+ reset-gpios = < 5 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <15000>;
+ reset-deassert-us = <10>;
+};
+
+ {
+
Re: [PATCH] Add imx93-var-som support
Hello Fabio, Thanks for the review! > It would also be helpful to add doc/board/variscite/imx93_var_som.rst > that explains > how to build U-Boot for this board, how to get the firmware, ATF, > binaries, etc, and how to flash it to the boot medium. For now, I am testing the bootloaders I produce using those instructions: https://variwiki.com/index.php?title=Yocto_Build_U-Boot=mx93-yocto-mickledore-6.1.36_2.1.0-v1.1 I understand that it would be nice to have u-boot do the image construction with the firmware, ATF and so on, like implemented on imx8. Do you think that it could be done in a follow-up patch, once imx93-var-som support is merged? > Please also submit the imx93-var-som-symphony.dts support to Linux so that > it can get reviewed by the DT folks. Done here: https://lore.kernel.org/linux-devicetree/20231227170919.8771-1-othac...@gnu.org/T/#t > To not block the board support, I suggest sending a v2 without PTN5150 > support for now. OK. >> +/* Using ULP WDOG for reset */ >> +#define WDOG_BASE_ADDR WDG3_BASE_ADDR > > Is this needed now that we use DM? That specific define is needed as the ulp_wdog driver seems to require it. I removed all the other unneeded defines in v2. Thanks, Mathieu
Re: [PATCH v4] fdt: Allow the devicetree to come from a bloblist
Hi Tom, On Thu, Dec 28, 2023 at 1:48 PM Tom Rini wrote: > > On Thu, Dec 28, 2023 at 01:37:39PM +, Simon Glass wrote: > > Hi Tom, > > > > > > On Wed, Dec 27, 2023 at 8:06 PM Tom Rini wrote: > > > > > > On Wed, Dec 27, 2023 at 05:48:42PM +, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Tue, Dec 26, 2023 at 12:07 PM Tom Rini wrote: > > > > > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +, Simon Glass wrote: > > > > > > > > > > > Standard passage provides for a bloblist to be passed from one > > > > > > firmware > > > > > > phase to the next. That can be used to pass the devicetree along as > > > > > > well. > > > > > > Add an option to support this. > > > > > > > > > > > > Tests for this will be added as part of the Universal Payload work. > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > --- > > > > > > The discussion on this was not resolved and is now important due to > > > > > > the > > > > > > bloblist series from Raymond. So I am sending it again since I > > > > > > believe > > > > > > this is a better starting point than building on OF_BOARD > > > > > > > > > > I really don't like adding another option for "DT is given to us". Why > > > > > isn't adding another enum to fdt_source_t sufficient > > > > > > > > That is added by this patch, but... > > > > > > > > >, and if we have > > > > > bloblist enabled, that will look for and use if found? > > > > > > > > ...this is the question. I would like to be able to enable bloblist > > > > without *requiring* the DT to come from there, hence the separate > > > > Kconfig option. > > > > > > > > > Maybe some other > > > > > code needs to be restructured and cleaned up too? > > > > > > > > Possibly, but I really am not keen on this board-specific solution. I > > > > believe Ilias & I agreed that OF_BOARD should fade away, so I don't > > > > like adding another thing onto it. > > > > > > I think you're missing something then. It should not be board specific > > > to just find the dtb via bloblist, without a new CONFIG. > > > > Yes, that is what I am looking for. > > > > > Whatever is > > > stopping that is what needs to be refactored and then you can just > > > extend fdt_source_t without a new CONFIG option. > > > > OK, but I need a way to turn it off, at least for development. > > > > [merging in the other thread:] > > > > On Wed, Dec 27, 2023 at 8:11 PM Tom Rini wrote: > > > > > > On Wed, Dec 27, 2023 at 05:48:44PM +, Simon Glass wrote: > > > > Hi Ilias, > > > > > > > > On Wed, Dec 27, 2023 at 6:44 AM Ilias Apalodimas > > > > wrote: > > > > > > > > > > Hi Tom, > > > > > > > > > > On Tue, 26 Dec 2023 at 14:07, Tom Rini wrote: > > > > > > > > > > > > On Tue, Dec 26, 2023 at 09:46:25AM +, Simon Glass wrote: > > > > > > > > > > > > > Standard passage provides for a bloblist to be passed from one > > > > > > > firmware > > > > > > > phase to the next. That can be used to pass the devicetree along > > > > > > > as well. > > > > > > > Add an option to support this. > > > > > > > > > > > > > > Tests for this will be added as part of the Universal Payload > > > > > > > work. > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > --- > > > > > > > The discussion on this was not resolved and is now important due > > > > > > > to the > > > > > > > bloblist series from Raymond. So I am sending it again since I > > > > > > > believe > > > > > > > this is a better starting point than building on OF_BOARD > > > > > > > > > > > > I really don't like adding another option for "DT is given to us". > > > > > > Why > > > > > > isn't adding another enum to fdt_source_t sufficient, and if we have > > > > > > bloblist enabled, that will look for and use if found? Maybe some > > > > > > other > > > > > > code needs to be restructured and cleaned up too? > > > > > > > > > > Same here. On top of that the bloblist has a few items in there, e.g a > > > > > TPM eventlog. What are we going to do? Add a Kconfig for each item? > > > > > > > > No, but that is just a straw man. The DT is special and U-Boot reports > > > > where it comes from. > > > > > > > > > > > > > > This has been going back and forth for a while. I've lost count of how > > > > > many times I repeated the same proposal, but here it goes again. We > > > > > have OF_BOARD and BLOBLIST options. The bloblist and its properties > > > > > are scannable at runtime. Can't we use the combination of these 2 can > > > > > be used to imply we expect things from a bloblist. If we want to be > > > > > stricter in the future and explicitly expect the DT from a bloblist, > > > > > we could add a Kconfig option failing the boot if that's missing. > > > > > > > > I would like to have that Kconfig option now, not later. In my mind, > > > > the boot must be deterministic, so that if OF_BLOBLIST is enabled, the > > > > DT must come from there, or it is an error. > > > > > > Determinism doesn't require a CONFIG option, it just requires an if/else > > > tree where we say
Re: [PATCH v3 7/8] dts: meson-gxbb: Switch to using upstream DT
Hi Tom, On Thu, Dec 28, 2023 at 1:56 PM Tom Rini wrote: > > On Thu, Dec 28, 2023 at 01:37:11PM +, Simon Glass wrote: > > Hi Sumit, > > > > On Thu, Dec 28, 2023 at 11:59 AM Sumit Garg wrote: > > > > > > Although there were still some variations in board DTS files based on > > > meson-gxbb SoC but I think those were minor differences from upstream > > > and shouldn't impact boot on these devices. > > > > > > So switch to upstream DT via mirroring amlogic/ directory from > > > devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly > > > building DTB from there including *-u-boot.dtsi files from > > > arch/$(ARCH)/dts/ directory. > > > > > > Reviewed-by: Neil Armstrong > > > Signed-off-by: Sumit Garg > > > --- > > > > > > Changes in v3: > > > -- > > > - Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead. > > > > > > Changes in v2: > > > -- > > > - Picked up review tag > > > > > > arch/arm/mach-meson/Kconfig | 1 + > > > configs/nanopi-k2_defconfig | 2 +- > > > configs/odroid-c2_defconfig | 2 +- > > > configs/p200_defconfig| 2 +- > > > configs/p201_defconfig| 2 +- > > > configs/videostrong-kii-pro_defconfig | 2 +- > > > configs/wetek-hub_defconfig | 2 +- > > > configs/wetek-play2_defconfig | 2 +- > > > dts/arch/arm64/amlogic| 1 + > > > 9 files changed, 9 insertions(+), 7 deletions(-) > > > create mode 12 dts/arch/arm64/amlogic > > > > > > > Reviewed-by: Simon Glass > > > > > diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig > > > index d6c89058061..8ddb59161a0 100644 > > > --- a/arch/arm/mach-meson/Kconfig > > > +++ b/arch/arm/mach-meson/Kconfig > > > @@ -25,6 +25,7 @@ choice > > > config MESON_GXBB > > > bool "GXBB" > > > select MESON_GX > > > + imply OF_UPSTREAM > > > help > > > Select this if your SoC is an S905 > > > > > > diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig > > > index 41dbf7981f8..2e1c756bf7a 100644 > > > --- a/configs/nanopi-k2_defconfig > > > +++ b/configs/nanopi-k2_defconfig > > > @@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000 > > > CONFIG_ENV_SIZE=0x2000 > > > CONFIG_DM_GPIO=y > > > -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" > > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2" > > > CONFIG_OF_LIBFDT_OVERLAY=y > > > CONFIG_DM_RESET=y > > > CONFIG_DEBUG_UART_BASE=0xc81004c0 > > > > So now I am wondering if we can (later) have the SoC be implied when > > using OF_UPSTREAM so we can do: > > > > CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2" > > > > and it will add the 'amlogic/' automatically? > > > > Perhaps that might be a way to bridge the gap in terms of file layout? > > That's going to start to look real ugly real quick I suspect and I'm not > sure what it really gets us? It seems to me that the convention of > "vendor/board" has already been well enough adapted outside of the > kernel, with the odd sticking point being getting everyone used to > whatever will be happening for 32bit boards long term. So I think hiding > the vendor part of the string here will be more, not less, confusing > long term. Now that I dig in a bit, I see that the devicetree-rebasing tree does not have any Makefiles in it. How does Linux build with it? Does anyone have instructions? Regards, Simon
Re: [PATCH 0/9] dts: Move to SoC-specific build rules
Hi Tom, On Thu, Dec 28, 2023 at 2:23 PM Tom Rini wrote: > > On Thu, Dec 28, 2023 at 01:37:07PM +, Simon Glass wrote: > > Hi Tom, > > > > On Wed, Dec 27, 2023 at 1:21 PM Tom Rini wrote: > > > > > > On Wed, Dec 27, 2023 at 08:23:56AM +, Simon Glass wrote: > > > > > > > U-Boot builds devicetree binaries from its source tree. As part of the > > > > Kconfig conversion, the Makefiles were updated to align with how this > > > > is done in Linux: a single target for each SoC is used to build all the > > > > .dtb files for that SoC. > > > > > > > > Since then, the Makefiles have devolved in some cases, resulting in > > > > lots of target-specific build rules. Also Linux has moved to using > > > > subdirectories for each vendor. > > > > > > > > Recent work aims to allow U-Boot to directly use devicetree files from > > > > Linux. This would be easier if the directory structure were the same. > > > > Another recent discussion involved dropping the build rules altogether. > > > > > > > > This series makes a start at cleaning up some of the build rules, to > > > > reduce the amount of code and make it easier to add new boards for the > > > > same SoC. > > > > > > > > One issue is that the ARCH_xxx Kconfig options between U-Boot and Linux > > > > are not always the same. Given the large number of SoCs and boards > > > > supported by U-Boot, it would be useful to align these where possible. > > > > > > I don't know why we should start with this now, and further not being on > > > top of Sumit's series to remove our duplicate dts files. And that's > > > where we can have the conversation about for which cases it even makes > > > sense to build all of the dts files for a given SoC. > > > > This is a completely different series - there are no conflicts with > > Sumit's series so it can be applied before or after it. > > > > My goal here is to clean up our build rules, rather than just throwing > > them all away, for reasons we have discussed previously. I filed [1] > > to track that. > > Yes, I'm saying we shouldn't be doing anything this series does until > after Sumit's series has landed. Along with the fact that I don't like > what's going on in this series. This seems to again be the disagreement over whether a single DT should be build for each board, or all the DTs for an SoC? Regards, Simon
Re: [PATCH v4] fdt: Allow the devicetree to come from a bloblist
Hi Ilias, On Thu, Dec 28, 2023 at 1:58 PM Ilias Apalodimas wrote: > > [...] > > > > > > > > > > > Same here. On top of that the bloblist has a few items in there, e.g a > > > > > TPM eventlog. What are we going to do? Add a Kconfig for each item? > > > > > > > > No, but that is just a straw man. The DT is special and U-Boot reports > > > > where it comes from. > > > > > > The story is identical to the EventLog. It's 'special' as well and > > > U-Boot has to pick it up, otherwise the hardware and the EventLog will > > > end up with different values > > > > Why are you talking about event log? Let's stick to the topic at hand. > > We are. The reason I bring this up is pretty obvious. It has identical > properties to the DT, and I *dont* want a Kconfig option to enable or > disable it. It is completely different to the devicetree. I don't even know how to respond to this, or what properties might be common between a devicetree and a TPL log. > > > > > > > > > > > > > > > > > > > > This has been going back and forth for a while. I've lost count of how > > > > > many times I repeated the same proposal, but here it goes again. We > > > > > have OF_BOARD and BLOBLIST options. The bloblist and its properties > > > > > are scannable at runtime. Can't we use the combination of these 2 can > > > > > be used to imply we expect things from a bloblist. If we want to be > > > > > stricter in the future and explicitly expect the DT from a bloblist, > > > > > we could add a Kconfig option failing the boot if that's missing. > > > > > > > > I would like to have that Kconfig option now, not later. In my mind, > > > > the boot must be deterministic, so that if OF_BLOBLIST is enabled, the > > > > DT must come from there, or it is an error. > > > > > > And how is what I proposed not deterministic? What prevents us from > > > adding that Kconfig option now? > > > The only difference is that by default, U-Boot will try bloblist -> > > > board-specific method unless a Kconfig option prevents the fallback. > > > I've been working with vendors and helping them implement the firmware > > > handoff spec in their proprietary bootloaders and Raymond contributed > > > the implementation for TF-A. At the same time, I am pretty sure > > > vendors will need time to implement this properly. I don't see how > > > adding an implicit Kconfig option will help them push this forward. > > > > > > IOW I prefer U-Boot to *always* scan for a bloblist as the first > > > discovery DT method (unless the DT comes bundled with U-Boot), rather > > > than expecting users to turn a Kconfig knob. > > > > It is the 'unless the DT comes bundled with U-Boot' which I am talking > > about, but I now have a better understanding of the problem here. > > > > I don't want CONFIG_BLOBLIST to mean that the DT comes from a > > bloblist. > > But it doesn't mean that. It means 'try to scan the bloblist for a DT first'. I'm OK with that and it is how the v5 patch works. > > > Simply put, I want to be able to use the U-Boot DT during > > development, without needing to rebuild some prior stage or update > > some other project. So I would like the use of bloblist to be behind > > an OF_BLOBLIST option. > > That's easy instead of OF_BOARD use OF_EMBED or OF_SEPARATE? OF_EMBED doesn't help - things have moved on a lot from those days (e.g. Binman) OF_SEPARATE is already enabled > > > > > From Tom's email and your other reply, it seems that we could all live > > with an OF_BLOBLIST option to enable DT-in-bloblist, making it > > optional but default 'y'? > > > > > > > > > > > > > Also, repeating it doesn't make the proposal good. We agreed that > > > > OF_BOARD would eventually go away, so building on top of it is not > > > > setting us up for the future. > > > > > > No, we didn't [0]. In fact, I said I don't see OF_BOARD *ever* going > > > away. The only thing I suggested was to rename it > > > > Well I'm just not sure what is going on. Use of bloblist should not > > require board-specific code. It should be a generic mechanism, in > > fdtdec_setup() > > It doesn't, we never asked for that. There's even code in a previous > iteration from me showing exactly what I had in mind. We always said > scan for a bloblist if OF_BOARD is selected, in priority, and if you > don't find a DT try a board-specific method (and add a Kconfig option > to fail the boot if required). > > > > > There are too many cooks in this kitchen right now, I'll try another > > spin of my patch. > > I really don't like another OF_XXX for determining where the DT > comes from, but I've explained my opinion way too many times. I'll > let you and Tom decide on this I sent a v5 patch which I believe provides what we both want, so PTAL. [..] > > > [0] > > > https://lore.kernel.org/u-boot/cac_iwjkrktm4spyxpoddartj41a553vde+xm5gz3+jsntfq...@mail.gmail.com/ Regards, Simon
Re: [PATCH v3 4/8] dts: Add alternative location for upstream DTB builds
Hi Tom, Sumit, On Thu, Dec 28, 2023 at 2:03 PM Tom Rini wrote: > > On Thu, Dec 28, 2023 at 01:37:26PM +, Simon Glass wrote: > > Hi Sumit, > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg wrote: > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts > > > directory. Also add a new Makefile for arm64. > > > > > > This will help easy migration for platforms which currently are compliant > > > with upstream Linux kernel devicetree files. > > > > > > Signed-off-by: Sumit Garg > > > --- > > > > > > Changes in v3: > > > -- > > > - Minor commit message update > > > > > > Changes in v2: > > > -- > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/ > > > > > > dts/Kconfig | 11 +++ > > > dts/Makefile| 17 ++--- > > > dts/arch/arm64/Makefile | 14 ++ > > > 3 files changed, 39 insertions(+), 3 deletions(-) > > > create mode 100644 dts/arch/arm64/Makefile > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig > > > index 00c0aeff893..e58c1c6f2ab 100644 > > > --- a/dts/Kconfig > > > +++ b/dts/Kconfig > > > @@ -85,6 +85,17 @@ config OF_LIVE > > > enables a live tree which is available after relocation, > > > and can be adjusted as needed. > > > > > > +config OF_UPSTREAM > > > + bool "Enable use of devicetree imported from Linux kernel release" > > > + help > > > + Traditionally, U-Boot platforms used to have their custom > > > devicetree > > > + files or copy devicetree files from Linux kernel which are hard > > > to > > > + maintain and can usually get out-of-sync from Linux kernel. This > > > + option enables platforms to migrate to devicetree-rebasing repo > > > where > > > + a regular sync will be maintained every major Linux kernel > > > release > > > + cycle. However, platforms can still have some custom u-boot > > > specific > > > + bits maintained as part of *-u-boot.dtsi files. > > > > My only other suggestion here is to mention that this should be set in > > Kconfig, for the SoC as a whole. So I believe that means that it > > should be hidden, with no string for the 'bool': > > > > bool # Enable use of devicetree imported from Linux kernel release > > I think we can just keep prompting for it now, to make the transition > easier, before this option just goes away in time, hopefully. > > > Also, this doesn't seem to work for me. Before this series I get these > > files when building firefly-rk3399: > > > > rk3399-eaidk-610.dtbrk3399-khadas-edge-v.dtb > > rk3399-orangepi.dtbrk3399-rock-pi-4a.dtb > > rk3399-evb.dtb rk3399-leez-p710.dtb > > rk3399-pinebook-pro.dtbrk3399-rock-pi-4c.dtb > > rk3399-ficus.dtbrk3399-nanopc-t4.dtb > > rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb > > rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb > > rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb > > rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb > > rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb > > rk3399-gru-kevin.dtbrk3399-nanopi-m4.dtb > > rk3399-rock-4c-plus.dtb > > rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb > > rk3399-rock-4se.dtb > > rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb > > > > Afterwards I get this: > > > > make[3]: *** No rule to make target > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > So I set this manually for that one board: > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly" > > > > and get: > > > > make[3]: *** No rule to make target > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop. > > > > I am not sure how to fix this, nor how this can be made to build all > > the DTs for rk3399, as it does today. > > Looking at the patch for amlogic boards, you need to make the link to > devicetree-rebasing inside dts/... OK, let me give up on rk3399 for now...that doesn't seem to work even with the link. Using odroid-c2 with -next I see: $ ls /tmp/b/odroid-c2/arch/arm/dts/ meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb meson-gxl-s905x-libretech-cc.dtb meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb meson-gxl-s905x-libretech-cc-v2.dtb meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb meson-gxl-s905x-p212.dtb meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb meson-gxm-gt1-ultimate.dtb meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb meson-gxm-khadas-vim2.dtb meson-g12a-u200.dtbmeson-gxbb-odroidc2.dtb meson-gxm-s912-libretech-pc.dtb meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb meson-gxm-wetek-core2.dtb meson-g12b-a311d-khadas-vim3.dtb
Re: I'm looking for the source code of a specific u-boot version.
Hello. Can someone provide the right link to download u-boot-2017.0.5 , please ? I've found it here,but I'm not sure that it's the correct version : https://src.fedoraproject.org/repo/pkgs/uboot-tools/u-boot-2017.05.tar.bz2/sha512/be270f9242a72b05463092a022bbabd54996762de1ff23bf7575124ac02e62f49572a4e2f6f571a5019047d40027e56e35593b5cc373c4a5a39b100c3377ba93/ Can you confirm it ? thanks. On Thu, Dec 28, 2023 at 1:14 AM Tony Dinh wrote: > > Hi Mario and Heinrich, > > On Wed, Dec 27, 2023 at 12:23 PM Mario Marietto > wrote: > > > > Hello. > > > > I'm trying to boot FreeBSD for arm32 bit as DomU on my ARM Chromebook > > SNOW with xen. Basically there are two ways to accomplish this task : > > > > > > 1) to write a patch that allows the FreeBSD kernel to boot as a zImage > > file. This could be accomplished applying this patch to a specific > > file that's on the source code of FreeBSD : > > > > > > https://xenbits.xen.org/gitweb/?p=p...8;hb=0782e25d98cc1391472717035f986c979edef0c9 > > > > > > > > This patch was written by Julien Grall a lot of time ago and now it > > does not work anymore. This is the reason explain by the xen > > developers : > > > > > > > > It appears FreeBSD-CURRENT removed the last step converting the kernel > > file to kernel.bin.The patch can be readily rebased, but without > > kernel.bin that doesn't do too much. > > > > > > > > So,without a rebase of that patch the first option is not applicable. > > And I'm not able to fix it. > > > > > > 2) booting FreeBSD using U-Boot,as explained to me by a xen developer : > > > > > > I was trying to explain why and how Julien's patch works so that you > > could be the one to re-do something similar or fix the patch on the > > FreeBSD kernel that you are working with. I am happy to help review > > and write patches but I don't work with the FreeBSD kernel so I > > wouldn't be able to help you quickly. However, I might have a > > suggestion. Do you know if FreeBSD can be booted by U-Boot ? > > Because > > U-Boot definitely boots as Xen on ARM guest firmware/bootloader. You > > should be able to build U-Boot and use the U-Boot binary as Xen guest > > kernel, then U-Boot could load FreeBSD from disk or network and start > > it. For instance as domU config file: > > > > kernel="/home/petalinux/u-boot.bin" > > disk = [ '/home/petalinux/test.img,raw,xvda' ] > > > > > > Actually I'm working on the idea n. 2. Basically I need to find the > > proper u-boot file that's able to boot the image of FreeBSD that I > > have installed (13.2 for arm32 bit). Maybe I found it here : > > > > > > http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/nv_uboot-snow-simplefb.kpart.bz2 > > > > > > I found that link inside this tutorial : > > > > > > https://wiki.freebsd.org/arm/Chromebook > > > > > > the version of u-boot that has been embedded in that file is the following > > one : > > > > > > # strings nv_uboot-snow-simplefb.kpart | grep U-Boot > > U-Boot 2011.12-gc1f6280 (May 27 2013 - 15:06:59) for SMDK5250 > > > > > > So the question is easy : I need to find the source code of that old > > version of u-boot,because once compiled,it will give me the proper > > u-boot.bin kernel / bootloader file that maybe will be able to boot > > FreeBSD. > > Yes, it can boot a 32-bit ARM board. I'm not a FreeBSD person, but > I've helped a FreeBSD user booting a 32-bit ARM box with u-boot > (GoFlexHome Marvell Kirkwood 6281). The u-boot version was 2017.05. I > used an out-of-tree u-boot build. This u-boot executed the ubldr to > boot FreeBSD. > > Please see here: > https://forum.doozan.com/read.php?3,49039,82059#msg-82059 > > It's been so long, I don't remember the details. Just to confirm what > Heinrich said that u-boot can indeed boot 32-bit FreeBSD, since many > years ago. > > All the best, > Tony > > > > > > > -- > > Mario. -- Mario.
Re: [PATCH v4 4/7] smbios: Use SMBIOS 3.0 to support an address above 4GB
> From: Simon Glass > Date: Thu, 28 Dec 2023 13:37:03 + > > Hi Ilias, > > On Wed, Dec 27, 2023 at 11:05 AM Ilias Apalodimas > wrote: > > > > Hi Simon, > > > > On Wed, 27 Dec 2023 at 09:40, Simon Glass wrote: > > > > > > When the SMBIOS table is written to an address above 4GB a 32-bit table > > > address is not large enough. > > > > > > Use an SMBIOS3 table in that case. > > > > Maybe I missed this on the previous revisions, but is there a reason > > we don't always use SMBIOS3 now? > > I am not sure...there was some comment about it not being supported in > some cases, so I have tried to accommodate that. > > > And perhaps try to install SMBIOS2 if > > 1. we fail > > due to? > > > 2. and the address is < 4GB > > We could, I suppose. Effectively we would drop generation of SMBIOS2. > > I really don't mind. This whole SMBIOS thing is a bit ridiculous, if > you ask me. Linux added support for the SMBIOS 3.0 64-bit entry point in 2014. I doubt anyone who cares about SMBIOS cares about kernels that old. So if it simplifies things, I'd drop support for the 32-bit SMBIOS entry point.
