Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option

[Tom Rini]

On Sat, Dec 04, 2021 at 03:09:59PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Sat, 4 Dec 2021 at 11:03, Tom Rini  wrote:
> >
> > On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sat, 4 Dec 2021 at 06:52, Tom Rini  wrote:
> > > >
> > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> > > >
> > > > [huge snip]
> > > > > > There's things that need to be cleaned up because we have some small
> > > > > > number of platforms that went off and did their own thing.  But 
> > > > > > largely
> > > > > > yes, things make sense to me.  We have:
> > > > > > - We embedded the device tree that will configure U-Boot, because 
> > > > > > there
> > > > > >   is no way for the hardware to have provided us one.
> > > > > > - We do not embed the device tree that will configure U-Boot, 
> > > > > > because
> > > > > >   there is already one present in memory for us to use.
> > > > > >
> > > > > > Then we have the developer option of:
> > > > > > - We embedded the device tree that will configure U-Boot, because 
> > > > > > we're
> > > > > >   developing something.
> > > > >
> > > > > Yes, agreed those are the cases. To me this needs to be a run-time 
> > > > > choice.
> > > >
> > > > But it's not possible.  That's the problem we keep going around and
> > > > around about.  People keep raising real life examples where you cannot
> > > > make a run time choice between "device tree we're passed at run time"
> > > > and "device tree we're compiled with".
> > >
> > > I haven't seen one. The most extreme case is QEMU and it works fine. I
> > > even added a test with it. What am I missing?
> >
> > QEMU and Xen should both never have an in-source-tree dts as they are
> > dynamic.  I think you missed the explanation about how U-Boot + Xen
> > works?  You're running the same U-Boot under Xen on any arbitrary ARMv8
> > (with required features...) system.  For QEMU virtual machines you're
> > not supposed to do what you're doing, for production.
> >
> > > > And it's not helpful.  It is ALWAYS the case that we know that we want
> > > > to override the run time device tree with our own, because it's a
> > > > developer developing things or it's a user / production case where we
> > > > must use the provided tree.  NOT doing that is what leads to madness
> > > > like we see for example on Pi where if we don't use the passed tree we
> > > > still need to copy X/Y/Z out of it.
> > >
> > > Aren't you talking about the distro DT there, rather than the the one
> > > on the boot disk? That is my reading of that patch. If we need to do
> > > that sort of thing, it doesn't matter where the the cointrol DT comes
> > > from. You are still going to have to do that sort of thing.
> > >
> > > It is not ALWAYS the case. I've shown you how easy it is to disable
> > > OF_BOARD and still boot / iterate.
> >
> > The DT we're passed in is the DT to pass to the OS.  That's the hook for
> > putting a DTB on the device as it ships, the OS will just work.  The
> > production case of needing to update that stored DTB is handled.  It's
> > always what should be used, again outside of developer doing
> > development.
> >
> > Maybe that's part of the confusion here too.  The DTB U-Boot is using is
> > the DTB the OS will consume too, in the passed at run time case.  Unless
> > we're instead going to save that DTB aside?  Which leaves me with a
> > different set of design questions...
> >
> > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we 
> > > > > > > should
> > > > > > > provide a way to do that? But what is driving that desire?
> > > > > >
> > > > > > I'm looking for ways to convince you that we do not need to include 
> > > > > > a
> > > > > > device tree in the binary.  There's a growing set of devices where 
> > > > > > the
> > > > > > device tree exists with the device.  If it's missing, that's a huge
> > > > > > fatal error we can't do all that much about.  If we need to do 
> > > > > > something
> > > > > > to that device tree for U-Boot, yes, fine, we should make it 
> > > > > > straight
> > > > > > forward for the developer to do that.  But that's not the common 
> > > > > > case!
> > > > >
> > > > > Well we could add another Kconfig which tells U-Boot not to include a
> > > > > devicetree in u-boot.bin, if that would resolve this?
> > > > >
> > > > > I just want to make sure that we always build the devicetrees and that
> > > > > it is easy for a knowledgeable dev to switch over to use them, without
> > > > > spelunking through dozens of other projects to discover the secret DT
> > > > > that no one will tell us about.
> > > >
> > > > Should we demand better documentation for boards?  Yes.  But it's still
> > > > a valid case to have zero device trees for a given platform in-tree.
> > > > Xen is an example of this.  QEMU is an example of this.  Platforms need
> > > > to work without adding special tweaks for us.  Maybe that means some
> > > > features can't be tested in QEM

Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option

[Tom Rini]

On Sat, Dec 04, 2021 at 07:52:46PM +0100, François Ozog wrote:
> Hi Simon
> 
> Le sam. 4 déc. 2021 à 18:35, Simon Glass  a écrit :
> 
> > Hi François,
> >
> > On Sat, 4 Dec 2021 at 09:55, François Ozog 
> > wrote:
> > >
> > > Hi Simon
> > >
> > > Le sam. 4 déc. 2021 à 16:21, Simon Glass  a écrit :
> > >>
> > >> Hi Tom,
> > >>
> > >> On Sat, 4 Dec 2021 at 06:52, Tom Rini  wrote:
> > >> >
> > >> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote:
> > >> >
> > >> > [huge snip]
> > >> > > > There's things that need to be cleaned up because we have some
> > small
> > >> > > > number of platforms that went off and did their own thing.  But
> > largely
> > >> > > > yes, things make sense to me.  We have:
> > >> > > > - We embedded the device tree that will configure U-Boot, because
> > there
> > >> > > >   is no way for the hardware to have provided us one.
> > >> > > > - We do not embed the device tree that will configure U-Boot,
> > because
> > >> > > >   there is already one present in memory for us to use.
> > >> > > >
> > >> > > > Then we have the developer option of:
> > >> > > > - We embedded the device tree that will configure U-Boot, because
> > we're
> > >> > > >   developing something.
> > >> > >
> > >> > > Yes, agreed those are the cases. To me this needs to be a run-time
> > choice.
> > >> >
> > >> > But it's not possible.  That's the problem we keep going around and
> > >> > around about.  People keep raising real life examples where you cannot
> > >> > make a run time choice between "device tree we're passed at run time"
> > >> > and "device tree we're compiled with".
> > >>
> > >> I haven't seen one. The most extreme case is QEMU and it works fine. I
> > >> even added a test with it. What am I missing?
> > >>
> > >> >
> > >> > And it's not helpful.  It is ALWAYS the case that we know that we want
> > >> > to override the run time device tree with our own, because it's a
> > >> > developer developing things or it's a user / production case where we
> > >> > must use the provided tree.  NOT doing that is what leads to madness
> > >> > like we see for example on Pi where if we don't use the passed tree we
> > >> > still need to copy X/Y/Z out of it.
> > >>
> > >> Aren't you talking about the distro DT there, rather than the the one
> > >> on the boot disk? That is my reading of that patch. If we need to do
> > >> that sort of thing, it doesn't matter where the the cointrol DT comes
> > >> from. You are still going to have to do that sort of thing.
> > >>
> > >> It is not ALWAYS the case. I've shown you how easy it is to disable
> > >> OF_BOARD and still boot / iterate.
> > >>
> > >> >
> > >> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we
> > should
> > >> > > > > provide a way to do that? But what is driving that desire?
> > >> > > >
> > >> > > > I'm looking for ways to convince you that we do not need to
> > include a
> > >> > > > device tree in the binary.  There's a growing set of devices
> > where the
> > >> > > > device tree exists with the device.  If it's missing, that's a
> > huge
> > >> > > > fatal error we can't do all that much about.  If we need to do
> > something
> > >> > > > to that device tree for U-Boot, yes, fine, we should make it
> > straight
> > >> > > > forward for the developer to do that.  But that's not the common
> > case!
> > >> > >
> > >> > > Well we could add another Kconfig which tells U-Boot not to include
> > a
> > >> > > devicetree in u-boot.bin, if that would resolve this?
> > >> > >
> > >> > > I just want to make sure that we always build the devicetrees and
> > that
> > >> > > it is easy for a knowledgeable dev to switch over to use them,
> > without
> > >> > > spelunking through dozens of other projects to discover the secret
> > DT
> > >> > > that no one will tell us about.
> > >> >
> > >> > Should we demand better documentation for boards?  Yes.  But it's
> > still
> > >> > a valid case to have zero device trees for a given platform in-tree.
> > >> > Xen is an example of this.  QEMU is an example of this.  Platforms
> > need
> > >> > to work without adding special tweaks for us.  Maybe that means some
> > >> > features can't be tested in QEMU-as-virtual-platform and only in
> > >> > QEMU-faithfully-emulating-specific-physical-platforms.
> > >>
> > >> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special
> > >> case, I think. How about we create a special Kconfig for that case? We
> > >> need to make some progress here.
> > >>
> > >> >
> > >> > > > I guess another part of the problem is that historically almost
> > all
> > >> > > > platforms were in the first case I list above, no run time
> > provided
> > >> > > > device tree, so we took the kernel one and added our bindings to
> > it.
> > >> > > > Now we're being bit by the growing number of platforms that are
> > the
> > >> > > > second case, and how do we get our properties in there, and which
> > ones
> > >> > > > even make sense to do that for.
> > >> > >
> 

Re: [PATCH v5 26/28] x86: efi: Don't use the 64-bit link script for the EFI app

[Christian Melki]

On 12/4/21 16:56, Simon Glass wrote:
> That script is not intended for use with EFI, so update the logic to avoid
> using it.
> 
> Signed-off-by: Simon Glass 
Signed-off-by: Christian Melki 
> ---
> 
> Changes in v5:
> - Add new patch to avoid using the 64-bit link script for the EFI app
> 
>  arch/x86/cpu/config.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/cpu/config.mk b/arch/x86/cpu/config.mk
> index d3033b41603..87e242a2065 100644
> --- a/arch/x86/cpu/config.mk
> +++ b/arch/x86/cpu/config.mk
> @@ -9,7 +9,7 @@ LDPPFLAGS += -DRESET_VEC_LOC=$(CONFIG_RESET_VEC_LOC)
>  LDPPFLAGS += -DSTART_16=$(CONFIG_SYS_X86_START16)
>  
>  ifdef CONFIG_X86_64
> -ifndef CONFIG_SPL_BUILD
> +ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_EFI_APP),)
>  LDSCRIPT = $(srctree)/arch/x86/cpu/u-boot-64.lds
>  endif
>  endif
> 

Re: [PATCH v5 27/28] x86: efi: Set the correct link flags for the 64-bit EFI app

[Christian Melki]

On 12/4/21 16:56, Simon Glass wrote:
> At present some 32-bit settings are used with the 64-bit app. Fix this by
> separating out the two cases.
> 
> Be careful not to break the 64-bit payload, which needs to build a 64-bit
> EFI stub with a 32-bit U-Boot.
> 
> Signed-off-by: Simon Glass 
Signed-off-by: Christian Melki 
> ---
> 
> Changes in v5:
> - Add new patch to set the correct link flags for the 64-bit EFI app
> 
>  arch/x86/config.mk | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/config.mk b/arch/x86/config.mk
> index 589f2aed2bc..889497b6bd7 100644
> --- a/arch/x86/config.mk
> +++ b/arch/x86/config.mk
> @@ -20,6 +20,11 @@ IS_32BIT := y
>  endif
>  endif
>  
> +EFI_IS_32BIT := $(IS_32BIT)
> +ifdef CONFIG_EFI_STUB_64BIT
> +EFI_IS_32BIT :=
> +endif
> +
>  ifeq ($(IS_32BIT),y)
>  PLATFORM_CPPFLAGS += -march=i386 -m32
>  else
> @@ -44,8 +49,14 @@ CFLAGS_EFI := -fpic -fshort-wchar
>  # Compiler flags to be removed when building UEFI applications
>  CFLAGS_NON_EFI := -mregparm=3 -fstack-protector-strong
>  
> -ifeq ($(CONFIG_EFI_STUB_64BIT),)
> +ifeq ($(IS_32BIT),y)
> +EFIPAYLOAD_BFDARCH = i386
> +else
>  CFLAGS_EFI += $(call cc-option, -mno-red-zone)
> +EFIPAYLOAD_BFDARCH = x86_64
> +endif
> +
> +ifeq ($(EFI_IS_32BIT),y)
>  EFIARCH = ia32
>  EFIPAYLOAD_BFDTARGET = elf32-i386
>  else
> @@ -53,8 +64,6 @@ EFIARCH = x86_64
>  EFIPAYLOAD_BFDTARGET = elf64-x86-64
>  endif
>  
> -EFIPAYLOAD_BFDARCH = i386
> -
>  LDSCRIPT_EFI := $(srctree)/arch/x86/lib/elf_$(EFIARCH)_efi.lds
>  EFISTUB := crt0_$(EFIARCH)_efi.o reloc_$(EFIARCH)_efi.o
>  OBJCOPYFLAGS_EFI += --target=efi-app-$(EFIARCH)
> 

Re: [PATCH v2 11/11] timer: Add a migration message

[Simon Glass]

Some boards still use the old timer mechanism. Set a deadline for them to
update to driver model.

This needs a bit of a strange rule to avoid an error on some boards.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 Makefile   | 4 
 doc/develop/driver-model/migration.rst | 8 
 2 files changed, 12 insertions(+)

Applied to u-boot-dm/next, thanks!

Re: [PATCH v2 10/11] ide: Drop ATA_PORT_ADDR

[Simon Glass]

This is not needed anymore. Drop it to simplify the code.

Signed-off-by: Simon Glass 
Suggested-by: Heinrich Schuchardt 
---

Changes in v2:
- Add new patch to drop ATA_PORT_ADDR

 drivers/block/ide.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

Applied to u-boot-dm/next, thanks!

Re: [PATCH v2 06/11] Convert CONFIG_KEYBOARD to Kconfig

[Simon Glass]

This converts the following to Kconfig:
   CONFIG_KEYBOARD

Signed-off-by: Simon Glass 
---

(no changes since v1)

 README  | 8 
 arch/Kconfig| 1 +
 arch/arm/mach-exynos/Kconfig| 1 +
 configs/chromebit_mickey_defconfig  | 1 +
 configs/chromebook_jerry_defconfig  | 1 +
 configs/chromebook_minnie_defconfig | 1 +
 configs/chromebook_speedy_defconfig | 1 +
 configs/novena_defconfig| 1 +
 configs/smdk5250_defconfig  | 1 +
 configs/smdk5420_defconfig  | 1 +
 drivers/input/Kconfig   | 9 +
 include/configs/exynos5-dt-common.h | 3 ---
 include/configs/novena.h| 1 -
 include/configs/sandbox.h   | 5 -
 include/configs/smdk5250.h  | 1 -
 include/configs/smdk5420.h  | 2 --
 include/configs/veyron.h| 2 --
 scripts/config_whitelist.txt| 1 -
 18 files changed, 18 insertions(+), 23 deletions(-)

Applied to u-boot-dm/next, thanks!

Re: [PATCH v2 07/11] keyboard: Add a migration message

[Simon Glass]

A few boards still use the old keyboard mechanism. Set a deadline for them
to update to driver model.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 Makefile   | 1 +
 doc/develop/driver-model/migration.rst | 8 
 2 files changed, 9 insertions(+)

Applied to u-boot-dm/next, thanks!

Re: [PATCH v2 08/11] sandbox: Drop CONFIG_SYS_TIMER_RATE

[Simon Glass]

This is not used by sandbox since it uses driver model for the timer.

Drop it.

Also update the tools_only build to avoid build errors, since it does
actually build U-Boot too. Enable DM so we can use CONFIG_TIMER,
disable EFI_LOADER to avoid an error about board_quiesce_devices() and
disable NET to avoid having to define CONFIG_AVB_BUF_ADDR

Signed-off-by: Simon Glass 
---

(no changes since v1)

 configs/tools-only_defconfig | 7 +++
 include/configs/sandbox.h| 4 
 2 files changed, 3 insertions(+), 8 deletions(-)

Applied to u-boot-dm/next, thanks!

Re: [PATCH v2 02/11] sandbox: Drop CONFIG_HOST_MAX_DEVICES

[Simon Glass]

This can go in the related header file. Drop the CONFIG option.

Signed-off-by: Simon Glass 
Reviewed-by: Heinrich Schuchardt 
---

(no changes since v1)

 cmd/host.c   | 2 +-
 drivers/block/sandbox.c  | 6 +++---
 include/configs/sandbox.h| 2 --
 include/sandboxblockdev.h| 3 +++
 scripts/config_whitelist.txt | 1 -
 5 files changed, 7 insertions(+), 7 deletions(-)

Applied to u-boot-dm/next, thanks!

Re: [PATCH v2 03/11] Convert CONFIG_SYS_FDT_LOAD_ADDR to Kconfig

[Simon Glass]

This converts the following to Kconfig:
   CONFIG_SYS_FDT_LOAD_ADDR

Signed-off-by: Simon Glass 
---

(no changes since v1)

 arch/sandbox/Kconfig | 10 ++
 include/configs/sandbox.h|  6 --
 scripts/config_whitelist.txt |  1 -
 3 files changed, 10 insertions(+), 7 deletions(-)

Applied to u-boot-dm/next, thanks!

Re: [PATCH v2 01/11] trace: sandbox: Use only the Kconfig options

[Simon Glass]

At present there are Kconfig options for tracing, but sandbox uses
plain #defines to set them. Correct this and make the tracing command
default to enabled so that this is not needed.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Drop the unnecessary defconfig changes from the docs

 cmd/Kconfig   | 2 ++
 doc/develop/trace.rst | 9 ++---
 2 files changed, 4 insertions(+), 7 deletions(-)

Applied to u-boot-dm/next, thanks!

Re: [PATCH 4/7] dtoc: Add support for reading string-list properties

[Simon Glass]

Add a function to read a list of strings from the devicetree.

Signed-off-by: Simon Glass 
---

 tools/dtoc/fdt_util.py | 21 +
 tools/dtoc/test_fdt.py |  9 +
 2 files changed, 30 insertions(+)

Applied to u-boot-dm/next, thanks!

Re: [PATCH 5/7] binman: Support lists of external blobs

[Simon Glass]

Sometimes it is useful to have a list of related external blobs in a
single entry. An example is the DDR binaries used by meson. There are
9 files in total. Add support for this, so we don't have to have a
separate entry for each.

Signed-off-by: Simon Glass 
---

 scripts/pylint.base   |  1 +
 tools/binman/entries.rst  | 14 +
 tools/binman/etype/blob.py| 16 -
 tools/binman/etype/blob_ext_list.py   | 58 +++
 tools/binman/ftest.py | 20 +++
 tools/binman/test/215_blob_ext_list.dts   | 14 +
 .../binman/test/216_blob_ext_list_missing.dts | 14 +
 7 files changed, 134 insertions(+), 3 deletions(-)
 create mode 100644 tools/binman/etype/blob_ext_list.py
 create mode 100644 tools/binman/test/215_blob_ext_list.dts
 create mode 100644 tools/binman/test/216_blob_ext_list_missing.dts

Applied to u-boot-dm/next, thanks!

Re: [PATCH 1/7] binman: Allow providing tools and blob directories

[Simon Glass]

At present it is necessary to symlink files containing external blobs into
the U-Boot tree in order for binman to find them. This is not very
convenient.

Add two new environment/Makefile variables to help with this. Add
documentation as well, fixing a related nit.

Signed-off-by: Simon Glass 
---

 Makefile|  2 ++
 tools/binman/binman.rst | 31 ++-
 2 files changed, 32 insertions(+), 1 deletion(-)

Applied to u-boot-dm/next, thanks!

Re: [PATCH 3/7] binman: Allow extracting a file in an alternative format

[Simon Glass]

In some cases entries encapsulate other data and it is useful to access
the data within. An example is the fdtmap which consists of a 16-byte
header, followed by a devicetree.

Provide an option to specify an alternative format when extracting files.
In the case of fdtmap, this is 'fdt', which produces an FDT file which can
be viewed with fdtdump.

Signed-off-by: Simon Glass 
---

 tools/binman/binman.rst | 29 
 tools/binman/cmdline.py |  2 ++
 tools/binman/control.py | 28 +---
 tools/binman/entries.rst| 11 +-
 tools/binman/entry.py   | 37 +
 tools/binman/etype/atf_fip.py   | 16 -
 tools/binman/etype/cbfs.py  |  8 ++---
 tools/binman/etype/fdtmap.py| 12 +++
 tools/binman/etype/section.py   | 23 ++---
 tools/binman/ftest.py   | 34 +++
 tools/binman/image.py   |  2 +-
 tools/binman/test/213_fdtmap_alt_format.dts | 15 +
 tools/binman/test/214_no_alt_format.dts | 13 
 13 files changed, 208 insertions(+), 22 deletions(-)
 create mode 100644 tools/binman/test/213_fdtmap_alt_format.dts
 create mode 100644 tools/binman/test/214_no_alt_format.dts

Applied to u-boot-dm/next, thanks!

Re: [PATCH 2/7] binman: Allow listing an image created by a newer version

[Simon Glass]

If an older version of binman is used to list images created by a newer
one, it is possible that it will contain entry types that are not
supported. At present this produces an error.

Adjust binman to use a plain 'blob' entry type to cope with this, so the
image can at least be listed.

Signed-off-by: Simon Glass 
---

 tools/binman/binman.rst   |  5 +++
 tools/binman/entry.py | 65 +++
 tools/binman/entry_test.py|  9 +
 tools/binman/etype/section.py |  3 +-
 tools/binman/image.py | 10 --
 5 files changed, 74 insertions(+), 18 deletions(-)

Applied to u-boot-dm/next, thanks!

Re: [PATCH v4 18/34] bloblist: Support allocating the bloblist

[Simon Glass]

Typically the bloblist is positioned at a fixed address in memory until
relocation. This is convenient when it is set up in SPL or before
relocation.

But for EFI we want to set it up only when U-Boot proper is running. Add
a way to allocate it using malloc() and update the documentation to cover
this aspect of bloblist.

Note there are no tests of this feature at present, nor any direct testing
of bloblist_init().

This can be added, e.g. by making this option controllable at runtime.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 common/Kconfig   | 15 +--
 common/bloblist.c| 16 ++--
 common/board_f.c |  8 +++-
 doc/develop/bloblist.rst | 16 
 4 files changed, 50 insertions(+), 5 deletions(-)

Applied to u-boot-dm/next, thanks!

Re: [PATCH 6/7] binman: Rename _ReadSubnodes() to ReadEntries()

[Simon Glass]

This method name is more commonly used for this function. Use it
consistently.

Signed-off-by: Simon Glass 
---

 tools/binman/etype/fit.py| 4 ++--
 tools/binman/etype/intel_ifwi.py | 4 ++--
 tools/binman/etype/mkimage.py| 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

Applied to u-boot-dm/next, thanks!

Please pull u-boot-dm/next

[Simon Glass]

Hi Tom,

https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/10137


The following changes since commit f89615088fba1b1f33713ad26dbe3a3c82b692ec:

  Merge branch 'next' of
https://source.denx.de/u-boot/custodians/u-boot-net into next
(2021-12-02 07:16:04 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-dm.git tags/dm-pull-5nov21

for you to fetch changes up to 0dbe5a1bde643b69375b11247f751d5acedb711c:

  timer: Add a migration message (2021-12-05 09:26:26 -0700)


binman refactoring to imrpove section handling
bloblist - allow it to be allocated
sandbox config-header cleanup


Alexander Preißner (1):
  drivers: core: lists: fix for loop index type

Heinrich Schuchardt (1):
  sandbox: replace putchar(ch) by fputc(ch, stdout)

Simon Glass (33):
  dtoc: Bring in the libfdt module automatically
  dtoc: Add support for reading 64-bit ints
  dtoc: Add support for reading fixed-length bytes properties
  binman: Tidy up style in cmdline
  binman: Add a way to obtain the version
  binman: Correct init of entry in Entry class
  binman: Correct comments for ReadChildData()
  binman: Drop the underscore in _ReadEntries()
  binman: Drop the filename property in entry_Section
  binman: Allow overriding BuildSectionData()
  binman: Allow control of which entries to read
  binman: Update the section documentation
  binman: Move cbfs.ObtainContents() down a bit
  binman: Use normal entries in cbfs
  binman: cbfs: Refactor the init process
  binman: cfbs: Refactor ObtainContents() for consistency
  binman: Rename testCbfsNoCOntents()
  bloblist: Support allocating the bloblist
  binman: Allow providing tools and blob directories
  binman: Allow listing an image created by a newer version
  binman: Allow extracting a file in an alternative format
  dtoc: Add support for reading string-list properties
  binman: Support lists of external blobs
  binman: Rename _ReadSubnodes() to ReadEntries()
  trace: sandbox: Use only the Kconfig options
  sandbox: Drop CONFIG_HOST_MAX_DEVICES
  Convert CONFIG_SYS_FDT_LOAD_ADDR to Kconfig
  Convert CONFIG_KEYBOARD to Kconfig
  keyboard: Add a migration message
  sandbox: Drop CONFIG_SYS_TIMER_RATE
  ide: Drop unused CONFIG options
  ide: Drop ATA_PORT_ADDR
  timer: Add a migration message

 Makefile|   7 ++
 README  |  11 ---
 arch/Kconfig|   1 +
 arch/arm/mach-exynos/Kconfig|   1 +
 arch/arm/mach-kirkwood/include/mach/config.h|   2 -
 arch/powerpc/include/asm/config.h   |   3 -
 arch/sandbox/Kconfig|  10 +++
 arch/sandbox/cpu/os.c   |   2 +-
 cmd/Kconfig |   2 +
 cmd/host.c  |   2 +-
 common/Kconfig  |  15 +++-
 common/bloblist.c   |  16 +++-
 common/board_f.c|   8 +-
 configs/chromebit_mickey_defconfig  |   1 +
 configs/chromebook_jerry_defconfig  |   1 +
 configs/chromebook_minnie_defconfig |   1 +
 configs/chromebook_speedy_defconfig |   1 +
 configs/novena_defconfig|   1 +
 configs/smdk5250_defconfig  |   1 +
 configs/smdk5420_defconfig  |   1 +
 configs/tools-only_defconfig|   7 +-
 doc/develop/bloblist.rst|  16 
 doc/develop/driver-model/migration.rst  |  16 
 doc/develop/trace.rst   |   9 +-
 drivers/block/ide.c |  14 +--
 drivers/block/sandbox.c |   6 +-
 drivers/core/lists.c|   2 +-
 drivers/input/Kconfig   |   9 ++
 include/configs/edminiv2.h  |   2 -
 include/configs/exynos5-dt-common.h |   3 -
 include/configs/novena.h|   1 -
 include/configs/r2dplus.h   |   1 -
 include/configs/sandbox.h   |  20 -
 include/configs/smdk5250.h  |   1 -
 include/configs/smdk5420.h  |   2 -
 include/configs/veyron.h|   2 -
 include/sandboxblockdev.h   |   3 +
 scripts/config_whitelist.txt|   5 --
 tools/binman/binman.rst |  65 +-
 tools/binman/cmdline.py |  76 
 tools/binman/control.py |  28 +-
 tools/binman/entries.rst   

Re: [PATCH 0/2] binman: Add support for ATF Firmware Image Package (FIP)

[Simon Glass]

Hi François,

On Sat, 4 Dec 2021 at 05:35, François Ozog  wrote:
>
> Hi Simon and Sandrine
>
> Le jeu. 2 déc. 2021 à 08:10, Sandrine Bailleux  a 
> écrit :
>>
>> Hi Simon,
>>
>> On 12/1/21 5:51 PM, Simon Glass wrote:
>> > Hi Sandrine,
>> >
>> > On Wed, 1 Dec 2021 at 03:32, Sandrine Bailleux
>> >  wrote:
>> >>
>> >> Hi everyone,
>> >>
>> >> I am Sandrine Bailleux, from the Trusted Firmware-A project. Ilias
>> >> Apalodimas CC'ed me on this thread.
>> >>
>> >> First of all, thanks for involving the TF-A developers in this thread
>> >> and my apologies for the delay in responding.
>> >
>> > Thank you for your response.
>> >
>> >>
>> >> On 11/25/21 6:01 PM, François Ozog wrote:
>> >>> Hi Simon,
>> >>>
>> >>> On Thu, 25 Nov 2021 at 17:49, Simon Glass > >>> > wrote:
>> >>>
>> >>> Hi François,
>> >>>
>> >>> On Thu, 25 Nov 2021 at 08:11, François Ozog
>> >>> mailto:francois.o...@linaro.org>> wrote:
>> >>> >
>> >>> > Hi Simon,
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas
>> >>> mailto:ilias.apalodi...@linaro.org>>
>> >>> wrote:
>> >>> >>
>> >>> >> +cc Sandrine
>> >>> >>
>> >>> >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas
>> >>> >> > >>> > wrote:
>> >>> >> >
>> >>> >> > Hi Simon,
>> >>> >> >
>> >>> >> >
>> >>> >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass > >>> > wrote:
>> >>> >> > >
>> >>> >> > >
>> >>> >> > > This series adds support for the FIP format as used by ARM
>> >>> Trusted
>> >>> >> > > Firmware (in particular TF-A).
>> >>> >> > >
>> >>> >
>> >>> > I will use a question you use often "what problem are you trying
>> >>> to solve?". If FIP format is used it means that TF-A/BL2 is going to
>> >>> parse it and verify the hashes/signatures according to TF-A scheme.
>> >>> >
>> >>> > The packager will embed in a FIP components like Secure Monitor,
>> >>> Secure hypervisor, Secure partitions code and manifests.
>> >>> >
>> >>> > All in all, U-Boot will be representing a small percentage of the
>> >>> functionality offered by secure firmware  as a whole and it feels
>> >>> odd to make another implementation that is more "accessory" rather
>> >>> than critical for the U-Boot community. It may be a good idea but I
>> >>> wish you could explain it.
>> >>>
>> >>> Here is a talk about Binman, its goals and how it works.
>> >>>
>> >>> https://www.youtube.com/watch?v=L84ujgUXBOQ
>> >>>
>> >>> Think of Binman as a separate tool that brings everything together. 
>> >>> It
>> >>> has grown out of U-Boot, largely because U-Boot is the main firmware
>> >>> in most cases. Getting U-Boot to start up and boot successfully is 
>> >>> the
>> >>> goal of this packaging process. There are lots of instructions in the
>> >>> tree and elsewhere about how to build an image comprising U-Boot and
>> >>> various binary blobs. Binman aims to provide documentation for that
>> >>> process and an image description that can be used to build an image
>> >>> reliably.
>> >>>
>> >>> We are slowly converting these text instructions into an in-tree 
>> >>> image
>> >>> description.
>> >>>
>> >>> I believe that Binman can help bring order to the chaos that is
>> >>> otherwise only going to grow, with lots of shell scripts, manual
>> >>> instructions, obscure binary tools, etc. Binman brings everything
>> >>> together and makes it clear what is needing/missing to build an 
>> >>> image.
>> >>>
>> >>> >
>> >>> >> > > This allows images to be created containing a FIP, which
>> >>> itself contains
>> >>> >> > > various binaries. With this, image creation can be handled
>> >>> from an in-tree
>> >>> >> > > image description instead of needing to perform a lot of
>> >>> manual steps or
>> >>> >> > > custom scripts to build the FIP.
>> >>> >> > >
>> >>> >
>> >>> > That's not my experience of building a fip.  Packaging even Linux
>> >>> as a BL33 (instead of U-Boot) is very simple.
>> >>>
>> >>> But not automatic. With Binman you don't need to worry about the
>> >>> packaging. It is done for you. You just need to find all the binary
>> >>> blobs that are needed.  This ability is quite important as firmware 
>> >>> is
>> >>> fragmenting and getting very complicated these days.
>> >>>
>> >>> Binman runs twice...once in the U-Boot tree to do a build and again
>> >>> later to repackage, put in a final fdtmap, add signatures and any
>> >>> final pieces needed.
>> >>>
>> >>> See this patch for an example of complicated build instructions with
>> >>> Odroid-C2 (>10 binary blobs!) and how Binman can help (see the 
>> >>> changes
>> >>> in the .rst file):
>> >>>
>> >>> 
>> >>> https://patchwork.ozlabs.org/

Re: Please pull u-boot-dm/next

[Tom Rini]

On Sun, Dec 05, 2021 at 12:53:43PM -0700, Simon Glass wrote:

> Hi Tom,
> 
> https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/10137
> 
> 
> The following changes since commit f89615088fba1b1f33713ad26dbe3a3c82b692ec:
> 
>   Merge branch 'next' of
> https://source.denx.de/u-boot/custodians/u-boot-net into next
> (2021-12-02 07:16:04 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-dm.git tags/dm-pull-5nov21
> 
> for you to fetch changes up to 0dbe5a1bde643b69375b11247f751d5acedb711c:
> 
>   timer: Add a migration message (2021-12-05 09:26:26 -0700)
> 

So I see we now get:
+(cortina_presidio-asic-emmc) = WARNING 
==
+(cortina_presidio-asic-emmc) This board does not use CONFIG_TIMER (Driver Model
+(cortina_presidio-asic-emmc) for Timer drivers). Please update the board to use
+(cortina_presidio-asic-emmc) CONFIG_TIMER before the v2022.10 release. Failure 
to
+(cortina_presidio-asic-emmc) update by the deadline may result in board 
removal.
+(cortina_presidio-asic-emmc) See doc/driver-model/migration.rst for more info.
+(cortina_presidio-asic-emmc) 


For a bunch of boards.  And that's not a full year from introduction of
warning to removal threat.  And I haven't seen any migration email to
all of the relevant maintainers yet either.  What's a good example of a
conversion to point maintainers at, as well?  Thanks.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] sunxi: dts: Fix typoed eMMC check

[Andre Przywara]

Commit 03510bf62149 ("sunxi: only include alias for eMMC when mmc2
used") protected the eMMC alias in U-Boot's DT stub the with the
associated Kconfig symbol, but was actually using the wrong name.

Fix the name of the symbol to match what's defined in Kconfig and what
the defconfig files actually use.

Fixes: 03510bf62149 ("sunxi: only include alias for eMMC when mmc2 used")
Signed-off-by: Andre Przywara 
Reported-by: 5...@5kft.org
---
 arch/arm/dts/sunxi-u-boot.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
index b7244c1112a..f2d7361b84f 100644
--- a/arch/arm/dts/sunxi-u-boot.dtsi
+++ b/arch/arm/dts/sunxi-u-boot.dtsi
@@ -13,7 +13,7 @@
 / {
aliases {
mmc0 = &mmc0;
-#if CONFIG_MMC_SUNXI_EXTRA_SLOT == 2
+#if CONFIG_MMC_SUNXI_SLOT_EXTRA == 2
mmc1 = &mmc2;
 #endif
};
-- 
2.17.6

Please pull u-boot-dm (take 2)

[Simon Glass]

Hi Tom,

I left out another pending patch but completely forgot to drop the
timer patch last time. Here it is again.

(next branch)


The following changes since commit f89615088fba1b1f33713ad26dbe3a3c82b692ec:

  Merge branch 'next' of
https://source.denx.de/u-boot/custodians/u-boot-net into next
(2021-12-02 07:16:04 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-dm.git tags/dm-pull-5dec21a

for you to fetch changes up to c229cd2b6e443a1365ff5089c4c4a6440f218dce:

  ide: Drop ATA_PORT_ADDR (2021-12-05 09:26:26 -0700)


binman refactoring to improve section handling
bloblist - allow it to be allocated
sandbox config-header cleanup


Alexander Preißner (1):
  drivers: core: lists: fix for loop index type

Heinrich Schuchardt (1):
  sandbox: replace putchar(ch) by fputc(ch, stdout)

Simon Glass (32):
  dtoc: Bring in the libfdt module automatically
  dtoc: Add support for reading 64-bit ints
  dtoc: Add support for reading fixed-length bytes properties
  binman: Tidy up style in cmdline
  binman: Add a way to obtain the version
  binman: Correct init of entry in Entry class
  binman: Correct comments for ReadChildData()
  binman: Drop the underscore in _ReadEntries()
  binman: Drop the filename property in entry_Section
  binman: Allow overriding BuildSectionData()
  binman: Allow control of which entries to read
  binman: Update the section documentation
  binman: Move cbfs.ObtainContents() down a bit
  binman: Use normal entries in cbfs
  binman: cbfs: Refactor the init process
  binman: cfbs: Refactor ObtainContents() for consistency
  binman: Rename testCbfsNoCOntents()
  bloblist: Support allocating the bloblist
  binman: Allow providing tools and blob directories
  binman: Allow listing an image created by a newer version
  binman: Allow extracting a file in an alternative format
  dtoc: Add support for reading string-list properties
  binman: Support lists of external blobs
  binman: Rename _ReadSubnodes() to ReadEntries()
  trace: sandbox: Use only the Kconfig options
  sandbox: Drop CONFIG_HOST_MAX_DEVICES
  Convert CONFIG_SYS_FDT_LOAD_ADDR to Kconfig
  Convert CONFIG_KEYBOARD to Kconfig
  keyboard: Add a migration message
  sandbox: Drop CONFIG_SYS_TIMER_RATE
  ide: Drop unused CONFIG options
  ide: Drop ATA_PORT_ADDR

 Makefile|   3 +
 README  |  11 ---
 arch/Kconfig|   1 +
 arch/arm/mach-exynos/Kconfig|   1 +
 arch/arm/mach-kirkwood/include/mach/config.h|   2 -
 arch/powerpc/include/asm/config.h   |   3 -
 arch/sandbox/Kconfig|  10 +++
 arch/sandbox/cpu/os.c   |   2 +-
 cmd/Kconfig |   2 +
 cmd/host.c  |   2 +-
 common/Kconfig  |  15 +++-
 common/bloblist.c   |  16 +++-
 common/board_f.c|   8 +-
 configs/chromebit_mickey_defconfig  |   1 +
 configs/chromebook_jerry_defconfig  |   1 +
 configs/chromebook_minnie_defconfig |   1 +
 configs/chromebook_speedy_defconfig |   1 +
 configs/novena_defconfig|   1 +
 configs/smdk5250_defconfig  |   1 +
 configs/smdk5420_defconfig  |   1 +
 configs/tools-only_defconfig|   7 +-
 doc/develop/bloblist.rst|  16 
 doc/develop/driver-model/migration.rst  |   8 ++
 doc/develop/trace.rst   |   9 +-
 drivers/block/ide.c |  14 +--
 drivers/block/sandbox.c |   6 +-
 drivers/core/lists.c|   2 +-
 drivers/input/Kconfig   |   9 ++
 include/configs/edminiv2.h  |   2 -
 include/configs/exynos5-dt-common.h |   3 -
 include/configs/novena.h|   1 -
 include/configs/r2dplus.h   |   1 -
 include/configs/sandbox.h   |  20 -
 include/configs/smdk5250.h  |   1 -
 include/configs/smdk5420.h  |   2 -
 include/configs/veyron.h|   2 -
 include/sandboxblockdev.h   |   3 +
 scripts/config_whitelist.txt|   5 --
 tools/binman/binman.rst |  65 +-
 tools/binman/cmdline.py |  76 
 tools/binman/control.py |  28 +-
 tools/binman/entries.rst   

Re: [BUG] efi_loader: incorrect creation of device paths

[AKASHI Takahiro]

On Fri, Dec 03, 2021 at 05:32:49PM +0100, Heinrich Schuchardt wrote:
> On 11/25/21 06:44, AKASHI Takahiro wrote:
> > Heinrich,
> > 
> > On Wed, Nov 24, 2021 at 12:10:32PM +0900, AKASHI Takahiro wrote:
> > > On Sat, Nov 20, 2021 at 01:54:30PM +0100, Heinrich Schuchardt wrote:
> > > > Hello Takahiro,
> > > > 
> > > > in a prior mail we have discussed the creation of device paths for USB
> > > > mass storage devices.
> > > > 
> > > > On the sand boxyou get the following devices after 'usb start':
> > > > 
> > > >   Class Index  Probed  DriverName
> > > > ---
> > > >   usb   0  [ + ]   usb_sandbox   |-- usb@1
> > > >   usb_hub   0  [ + ]   usb_hub   |   `-- hub
> > > >   usb_mass_s0  [ + ]   usb_mass_storage  |   |--
> > > > usb_mass_storage
> > > >   blk   3  [   ]   usb_storage_blk   |   |   `--
> > > > usb_mass_storage.lun0
> > > >   usb_mass_s1  [ + ]   usb_mass_storage  |   |--
> > > > usb_mass_storage
> > > >   blk   4  [   ]   usb_storage_blk   |   |   `--
> > > > usb_mass_storage.lun0
> > > >   usb_mass_s2  [ + ]   usb_mass_storage  |   `--
> > > > usb_mass_storage
> > > >   blk   5  [   ]   usb_storage_blk   |   `--
> > > > usb_mass_storage.lun0
> > > > 
> > > > For of these storage devices we try to create the same device path which
> > > > is not allowable:
> > > > 
> > > > => usb start
> > > > starting USB...
> > > > Bus usb@1: scanning bus usb@1 for devices... 5 USB Device(s) found
> > > > scanning usb for storage devices... 3 Storage Device(s) found
> > > > =>
> > > > => efidebug dh
> > > > Scanning disk mmc2.blk...
> > > > handle 15e34f00,
> > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(2)/SD(0)
> > > > Scanning disk mmc1.blk...
> > > > handle 15e36b30,
> > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(1)
> > > > Scanning disk mmc0.blk...
> > > > handle 15e35b00,
> > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(2)
> > > > Scanning disk usb_mass_storage.lun0...
> > > > handle 15e35c10,
> > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x1234,0x5678,0x9,0x0,0x0)/UsbClass(0x1234,0x5678,0x0,0x0,0x0)
> > > > fs_devread read outside partition 2
> > > > Failed to mount ext2 filesystem...
> > > > BTRFS: superblock end 69632 is larger than device size 512
> > > > Scanning disk usb_mass_storage.lun0...
> > > > handle 15e361f0,
> > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x1234,0x5678,0x9,0x0,0x0)/UsbClass(0x1234,0x5678,0x0,0x0,0x0)
> > > > ERROR: failure to add disk device usb_mass_storage.lun0, r = 20
> > > > Error: Cannot initialize UEFI sub-system, r = 20
> > > > 
> > > > I will provide a patch that will allow the first USB device to be used
> > > > and avoids stopping the boot process. But we really have to walk the dm
> > > > tree to create a device patch for USB devices based on port IDs.
> > > > 
> > > > We should add a new field to struct uclass_driver:
> > > > 
> > > > struct efi_device_path *get_node(udevice *dev);
> > > > 
> > > > This function shall return a pointer to an freshly allocated buffer with
> > > > the device node for the device. To build the devicepath we can then walk
> > > > the dm tree.
> > > 
> > > I'm not sure this is an acceptable solution.
> > > 
> > > Let me make sure:
> > > The goal would be to create a device path like
> > > .../USB(0x1,0x0)/HD(1,...)
> > > instead of
> > > 
> > > .../UsbHub(0x0,0x0,0x0,0x3)/UsbMassStorage(0x46f4,0x1,0x0,0x0)/HD(1,...)
> > > as we already see this format for SCSI:
> > > .../Scsi(0,0)/HD(1,..)
> > > 
> > > Right?
> > 
> > Please try the tweak attached below.
> > (I think what I did here is trivial.)
> > 
> > If you like, I will post it as a patch.
> > (See "10.3.4.5.1 USB Device Path Example".)
> > 
> > -Takahiro Akashi
> > 
> > > > >  From cda91e9d8144f89f0d73738b338289a7940bbe0e Mon Sep 17 00:00:00 
> > > > > 2001
> > > > > From: AKASHI Takahiro 
> > > > > Date: Thu, 25 Nov 2021 14:20:08 +0900
> > > > > Subject: [PATCH] efi_loader: disk: usb mass-storage
> > 
> > - use path_usb instead of path_usb_class for existing USB dp nodes
> > - add a dp node for UCLASS_USB
> > 
> > => usb start
> > starting USB...
> > Bus xhci_pci: Register 8001040 NbrPorts 8
> > Starting the controller
> > USB XHCI 1.00
> > scanning bus xhci_pci for devices... 4 USB Device(s) found
> > scanning usb for storage devices... 2 Storage Device(s) found
> > => dm tree
> >   Class Index  Probed  DriverName
> > ---
> >   root  0  [ + ]   root_driver   root_driver
> >   ...
> >   pci   0  [ + ]   pci_generic_ecam  |-- pcie@1000
> >   pci_generi0  [   ]   pci_generic_drv   |   |-- pci_0:0.0
> >   virtio   32  [ + ]   virtio-pci.l  

Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION

[AKASHI Takahiro]

On Fri, Dec 03, 2021 at 05:06:56PM +0100, Heinrich Schuchardt wrote:
> On 12/3/21 08:16, AKASHI Takahiro wrote:
> > Heinrich,
> > 
> > On Tue, Nov 16, 2021 at 12:01:27PM +0900, AKASHI Takahiro wrote:
> > > On Tue, Nov 16, 2021 at 01:02:55AM +0100, Heinrich Schuchardt wrote:
> > > > On 11/16/21 00:51, AKASHI Takahiro wrote:
> > > > > > > Is the patch good enough to include in the series?
> > > > > > > 
> > > > > > > If not, you could reply to it with what needs doing.
> > > > > ? I have already replied to your patch:)
> > > > > Basically, it seems to be fine to me.
> > > > > 
> > > > > > > Regards,
> > > > > > > Simon
> > > > > > > 
> > > > > > The patch is not usable as is. It assumes only GPT partioning is 
> > > > > > used.
> > > > > @Heinrich
> > > > > I don't get your point. Either my patch or Simon's is not specific
> > > > > to GPT at all.
> > > > > 
> > > > > So I'm going to start respinning my patch for a next round of 
> > > > > discussion.
> > > > 
> > > > A field name gpt_part_info obviously relates to GPT?
> > > 
> > > No.
> > > 
> > > IICU, the structure, disk_partition, is not particularly GPT-specific
> > > as such type of data are used over various partition drivers.
> > > In my patch series, I simply reuse "struct disk_part" as a structure
> > > holding a partition number and partition information (= disk_partition).
> > 
> > So do you agree that we won't have "partition-table" devices for now?
> > 
> > -Takahiro Akashi
> 
> We don't need the partition-table to be a udevice now. We still can
> later convert the partition drivers to a uclass if we deem it helpful.

OK. I'm going to prepare for next RFC.

-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> > 
> > 
> > > -Takahiro Akashi
> > > 
> > > > Up to now this string exists only in cmd/gpt.c.
> > > > 
> > > > Best regards
> > > > 
> > > > Heinrich
> > > > 
> > > > > 
> > > > > -Takahiro Akashi
> > > > > 
> > > > > > Instead all partition table drivers need to be converted to drivers 
> > > > > > for
> > > > > > the new uclass.
> > > > > > 
> > > > > > Best regards
> > > > > > 
> > > > > > Heinrich
> > > > 
> 

RE: [EXT] Re: [PATCH v4 01/16] crypto/fsl: Add support for CAAM Job ring driver model

[Gaurav Jain]

Hello

> -Original Message-
> From: Simon Glass 
> Sent: Wednesday, December 1, 2021 11:32 PM
> To: Gaurav Jain 
> Cc: U-Boot Mailing List ; Stefano Babic
> ; Fabio Estevam ; Peng Fan
> ; Priyanka Jain ; Ye Li
> ; Horia Geanta ; Ji Luo
> ; Franck Lenormand ; Silvano Di
> Ninno ; Sahil Malhotra ;
> Pankaj Gupta ; Varun Sethi ; dl-
> uboot-imx ; Shengzhou Liu ;
> Mingkai Hu ; Rajesh Bhagat ;
> Meenakshi Aggarwal ; Wasim Khan
> ; Alison Wang ; Pramod
> Kumar ; Andy Tang ;
> Adrian Alonso ; Vladimir Oltean 
> Subject: Re: [EXT] Re: [PATCH v4 01/16] crypto/fsl: Add support for CAAM Job
> ring driver model
> 
> Caution: EXT Email
> 
> On Wed, 1 Dec 2021 at 05:14, Gaurav Jain  wrote:
> >
> > Hello Simon
> >
> > > -Original Message-
> > > From: Simon Glass 
> > > Sent: Wednesday, December 1, 2021 11:57 AM
> > > To: Gaurav Jain 
> > > Cc: U-Boot Mailing List ; Stefano Babic
> > > ; Fabio Estevam ; Peng Fan
> > > ; Priyanka Jain ; Ye Li
> > > ; Horia Geanta ; Ji Luo
> > > ; Franck Lenormand ;
> > > Silvano Di Ninno ; Sahil Malhotra
> > > ; Pankaj Gupta ; Varun
> > > Sethi ; dl- uboot-imx ;
> > > Shengzhou Liu ; Mingkai Hu
> > > ; Rajesh Bhagat ;
> > > Meenakshi Aggarwal ; Wasim Khan
> > > ; Alison Wang ; Pramod
> > > Kumar ; Andy Tang ;
> > > Adrian Alonso ; Vladimir Oltean
> > > 
> > > Subject: Re: [EXT] Re: [PATCH v4 01/16] crypto/fsl: Add support for
> > > CAAM Job ring driver model
> > >
> > > Caution: EXT Email
> > >
> > > Hi Gaurav,
> > >
> > > On Mon, 29 Nov 2021 at 00:25, Gaurav Jain  wrote:
> > > >
> > > > Hello Simon
> > > >
> > > > > -Original Message-
> > > > > From: Simon Glass 
> > > > > Sent: Thursday, November 25, 2021 5:42 AM
> > > > > To: Gaurav Jain 
> > > > > Cc: U-Boot Mailing List ; Stefano Babic
> > > > > ; Fabio Estevam ; Peng Fan
> > > > > ; Priyanka Jain ; Ye Li
> > > > > ; Horia Geanta ; Ji Luo
> > > > > ; Franck Lenormand ;
> > > > > Silvano Di Ninno ; Sahil Malhotra
> > > > > ; Pankaj Gupta ;
> > > > > Varun Sethi ; dl- uboot-imx
> > > > > ; Shengzhou Liu ;
> > > > > Mingkai Hu ; Rajesh Bhagat
> > > > > ; Meenakshi Aggarwal
> > > > > ; Wasim Khan ;
> > > > > Alison Wang ; Pramod Kumar
> > > > > ; Andy Tang ;
> Adrian
> > > > > Alonso ; Vladimir Oltean
> > > > > 
> > > > > Subject: Re: [EXT] Re: [PATCH v4 01/16] crypto/fsl: Add support
> > > > > for CAAM Job ring driver model
> > > > >
> > > > > Caution: EXT Email
> > > > >
> > > > > Hi Gaurav,
> > > > >
> > > > > On Mon, 8 Nov 2021 at 02:30, Gaurav Jain 
> wrote:
> > > > > >
> > > > > > Hello Simon
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Simon Glass 
> > > > > > > Sent: Tuesday, November 2, 2021 8:26 PM
> > > > > > > To: Gaurav Jain 
> > > > > > > Cc: U-Boot Mailing List ; Stefano
> > > > > > > Babic ; Fabio Estevam ;
> > > > > > > Peng Fan ; Priyanka Jain
> > > > > > > ; Ye Li ; Horia Geanta
> > > > > > > ; Ji Luo ; Franck
> > > > > > > Lenormand ; Silvano Di Ninno
> > > > > > > ; Sahil Malhotra
> > > > > > > ; Pankaj Gupta
> > > > > > > ; Varun Sethi ; dl-
> > > > > > > uboot-imx ; Shengzhou Liu
> > > > > > > ; Mingkai Hu ;
> > > > > > > Rajesh Bhagat ; Meenakshi Aggarwal
> > > > > > > ; Wasim Khan
> > > > > > > ; Alison Wang ;
> > > > > > > Pramod Kumar ; Andy Tang
> > > > > > > ;
> > > Adrian
> > > > > > > Alonso ; Vladimir Oltean
> > > > > > > 
> > > > > > > Subject: [EXT] Re: [PATCH v4 01/16] crypto/fsl: Add support
> > > > > > > for CAAM Job ring driver model
> > > > > > >
> > > > > > > Caution: EXT Email
> > > > > > >
> > > > > > > Hi Gaurav,
> > > > > > >
> > > > > > > On Tue, 26 Oct 2021 at 00:56, Gaurav Jain 
> wrote:
> > > > > > > >
> > > > > > > > added device tree support for job ring driver.
> > > > > > > > sec is initialized based on job ring information processed
> > > > > > > > from device tree.
> > > > > > > >
> > > > > > > > Signed-off-by: Gaurav Jain 
> > > > > > > > Reviewed-by: Ye Li 
> > > > > > > > ---
> > > > > > > >  cmd/Kconfig |   1 +
> > > > > > > >  drivers/crypto/fsl/Kconfig  |   7 +
> > > > > > > >  drivers/crypto/fsl/Makefile |   4 +-
> > > > > > > >  drivers/crypto/fsl/jr.c | 318 
> > > > > > > > -
> ---
> > > > > > > >  drivers/crypto/fsl/jr.h |  14 ++
> > > > > > > >  5 files changed, 234 insertions(+), 110 deletions(-)
> > > > > > >
> > > > > > > You should not have CONFIG_ARCH_IMX8 in a driver. Things
> > > > > > > like that should be handled by using a different compatible 
> > > > > > > string.
> > > > > > > Also please use the
> > > > > livetree API.
> > > > > > >
> > > > > > > I asked about the use of MISC as a uclass earlier. It seems
> > > > > > > that this device provides random numbers and perhaps
> > > > > > > hashing? It is hard to know since I am not sure where the
> > > > > > > documentation is in this series. It seems odd to be modelled
> > > > > > > as a MISC device. My understanding is that there are
> > > > > > > problems with the size in SPL if a different
> > > > > UCLAS

RE: [EXT] Re: [PATCH v6 01/15] crypto/fsl: Add support for CAAM Job ring driver model

[Gaurav Jain]

Hello Simon

> -Original Message-
> From: Simon Glass 
> Sent: Wednesday, December 1, 2021 11:32 PM
> To: Gaurav Jain 
> Cc: u-boot@lists.denx.de; Stefano Babic ; Fabio Estevam
> ; Peng Fan ; Priyanka Jain
> ; Ye Li ; Horia Geanta
> ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ;
> Sahil Malhotra ; Pankaj Gupta
> ; Varun Sethi ; dl-uboot-imx
> ; Shengzhou Liu ; Mingkai Hu
> ; Rajesh Bhagat ; Meenakshi
> Aggarwal ; Wasim Khan
> ; Alison Wang ; Pramod
> Kumar ; Andy Tang ;
> Adrian Alonso ; Vladimir Oltean 
> Subject: Re: [EXT] Re: [PATCH v6 01/15] crypto/fsl: Add support for CAAM Job
> ring driver model
> 
> Caution: EXT Email
> 
> Hi Gaurav,
> 
> On Wed, 1 Dec 2021 at 04:54, Gaurav Jain  wrote:
> >
> > Hello Simon,
> >
> > > -Original Message-
> > > From: Simon Glass 
> > > Sent: Wednesday, December 1, 2021 11:57 AM
> > > To: Gaurav Jain 
> > > Cc: u-boot@lists.denx.de; Stefano Babic ; Fabio
> > > Estevam ; Peng Fan ; Priyanka
> > > Jain ; Ye Li ; Horia Geanta
> > > ; Ji Luo ; Franck Lenormand
> > > ; Silvano Di Ninno
> > > ; Sahil Malhotra ;
> > > Pankaj Gupta ; Varun Sethi ;
> > > dl-uboot-imx ; Shengzhou Liu
> > > ; Mingkai Hu ; Rajesh
> > > Bhagat ; Meenakshi Aggarwal
> > > ; Wasim Khan ;
> > > Alison Wang ; Pramod Kumar
> > > ; Andy Tang ; Adrian
> > > Alonso ; Vladimir Oltean 
> > > Subject: [EXT] Re: [PATCH v6 01/15] crypto/fsl: Add support for CAAM
> > > Job ring driver model
> > >
> > > Caution: EXT Email
> > >
> > > Hi Gaurav,
> > >
> > > On Tue, 30 Nov 2021 at 03:41, Gaurav Jain  wrote:
> > > >
> > > > added device tree support for job ring driver.
> > > > sec is initialized based on job ring information processed from
> > > > device tree.
> > > >
> > > > Signed-off-by: Gaurav Jain 
> > > > Reviewed-by: Ye Li 
> > > > ---
> > > >  drivers/crypto/fsl/Kconfig   |   7 +
> > > >  drivers/crypto/fsl/Makefile  |   2 +
> > > >  drivers/crypto/fsl/jobdesc.c |   4 +-
> > > >  drivers/crypto/fsl/jr.c  | 316 +++
> > > >  drivers/crypto/fsl/jr.h  |  14 ++
> > > >  5 files changed, 232 insertions(+), 111 deletions(-)
> > >
> > > Can you create a new uclass for this instead of using misc? What
> > > operations does this device support?
> > I am thinking of creating UCLASS_CAAM which will not be generic and
> dedicated to job ring driver.
> > Let me know if you are fine with this new uclass.
> > This will support only single operation which is run(run_descriptor_jr) 
> > used to
> enqueue the descriptor to JR.
> > Let me know if you have any more comments, as I am planning to do validate
> all the suggested changes on all imx, layerscape, powerpc platforms.
> 
> 
> Well, have a look if remoteproc would suit you as it has
> start()/stop() etc. But if not, yes creating your own uclass is fine.
> You never know, others may use it. Remember to add a sandbox driver and test
> (both are likely pretty trivial though).

On the second thought, JR driver operation run_descriptor_jr() can be 
implemented using the MISC class ioctl.
will be floating the changes for review in next version soon.

Regards
Gaurav Jain
> 
> Regards,
> Simon

[PATCH 0/5] Series short description

[Masami Hiramatsu]

Hi,

This series is improving DFU subsystem. This improves dfu_alt_info
parser and fixing documents etc.

When I was debuging my patch for updating dfu_alt_info on the
DeveloperBox platform, I found that dfu_alt_info parser doesn't
accept redundant spaces and tabs. Also the dfu.rst description
seems wrong. Moreover, there is no way to check whether the
parser parses the dfu_alt_info correctly.

These patches fixes such issues. [1/5] is just for avoiding
buffer overrun, [2/5] and [3/5] improves dfu_alt_info parser
to accept redundant spaces and tabs, and check the number of
arguments strictly so that the parser (and user) can notice
any unexpected parameters. [4/5] fixes the documents (there
seems some wrong description maybe coming from copy&paste).
[5/5] allows user to run 'dfu list' even if the platform
doesn't support DFU_OVER_USB.

Thank you,

---

Masami Hiramatsu (5):
  DFU: Do not copy the entity name over the buffer size
  DFU: Accept redundant spaces and tabs in dfu_alt_info
  DFU: Check the number of arguments and argument string strictly
  doc: usage: DFU: Fix dfu_alt_info document
  cmd/dfu: Enable 'dfu list' command without DFU_OVER_USB


 cmd/dfu.c  |6 +++--
 doc/usage/dfu.rst  |   57 ++--
 drivers/dfu/dfu.c  |   37 ---
 drivers/dfu/dfu_mmc.c  |   55 +++---
 drivers/dfu/dfu_mtd.c  |   34 +++--
 drivers/dfu/dfu_nand.c |   34 ++---
 drivers/dfu/dfu_ram.c  |   24 ++--
 drivers/dfu/dfu_sf.c   |   34 ++---
 drivers/dfu/dfu_virt.c |5 +++-
 include/dfu.h  |   33 ++--
 10 files changed, 205 insertions(+), 114 deletions(-)

--
Masami Hiramatsu 

[PATCH 0/5] DFU: Update dfu_alt_info parser etc.

[Masami Hiramatsu]

Hi,

This series is improving DFU subsystem. This improves dfu_alt_info
parser and fixing documents etc.

When I was debuging my patch for updating dfu_alt_info on the
DeveloperBox platform, I found that dfu_alt_info parser doesn't
accept redundant spaces and tabs. Also the dfu.rst description
seems wrong. Moreover, there is no way to check whether the
parser parses the dfu_alt_info correctly.

These patches fixes such issues. [1/5] is just for avoiding
buffer overrun, [2/5] and [3/5] improves dfu_alt_info parser
to accept redundant spaces and tabs, and check the number of
arguments strictly so that the parser (and user) can notice
any unexpected parameters. [4/5] fixes the documents (there
seems some wrong description maybe coming from copy&paste).
[5/5] allows user to run 'dfu list' even if the platform
doesn't support DFU_OVER_USB.

Thank you,

---

Masami Hiramatsu (5):
  DFU: Do not copy the entity name over the buffer size
  DFU: Accept redundant spaces and tabs in dfu_alt_info
  DFU: Check the number of arguments and argument string strictly
  doc: usage: DFU: Fix dfu_alt_info document
  cmd/dfu: Enable 'dfu list' command without DFU_OVER_USB


 cmd/dfu.c  |6 +++--
 doc/usage/dfu.rst  |   57 ++--
 drivers/dfu/dfu.c  |   37 ---
 drivers/dfu/dfu_mmc.c  |   55 +++---
 drivers/dfu/dfu_mtd.c  |   34 +++--
 drivers/dfu/dfu_nand.c |   34 ++---
 drivers/dfu/dfu_ram.c  |   24 ++--
 drivers/dfu/dfu_sf.c   |   34 ++---
 drivers/dfu/dfu_virt.c |5 +++-
 include/dfu.h  |   33 ++--
 10 files changed, 205 insertions(+), 114 deletions(-)

--
Masami Hiramatsu 

[PATCH 1/5] DFU: Do not copy the entity name over the buffer size

[Masami Hiramatsu]

Use strlcpy() instead of strcpy() to prevent copying the
entity name over the name buffer size.

Signed-off-by: Masami Hiramatsu 
---
 drivers/dfu/dfu.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index af3975925a..66c41b5e76 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -503,7 +503,7 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s, 
int alt,
 
debug("%s: %s interface: %s dev: %s\n", __func__, s, interface, devstr);
st = strsep(&s, " ");
-   strcpy(dfu->name, st);
+   strlcpy(dfu->name, st, DFU_NAME_SIZE);
 
dfu->alt = alt;
dfu->max_buf_size = 0;

[PATCH 2/5] DFU: Accept redundant spaces and tabs in dfu_alt_info

[Masami Hiramatsu]

If dfu_alt_info has repeated spaces or tab (for indentation or
readability), the dfu fails to parse it. For example, if
dfu_alt_info="mtd nor1=image raw  10 20" (double spaces
after "raw"), the image entity start address is '0' and the size
'0x10'. This is because the repeated space is not skipped.

Use space and tab as a separater and apply skip_spaces() to
skip redundant spaces and tabs.

Signed-off-by: Masami Hiramatsu 
---
 drivers/dfu/dfu.c  |6 --
 drivers/dfu/dfu_mmc.c  |   11 ---
 drivers/dfu/dfu_mtd.c  |8 ++--
 drivers/dfu/dfu_nand.c |   11 ---
 drivers/dfu/dfu_ram.c  |3 ++-
 drivers/dfu/dfu_sf.c   |   12 +---
 6 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 66c41b5e76..18154774f9 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -123,9 +123,10 @@ int dfu_config_interfaces(char *env)
s = env;
while (s) {
ret = -EINVAL;
-   i = strsep(&s, " ");
+   i = strsep(&s, " \t");
if (!i)
break;
+   s = skip_spaces(s);
d = strsep(&s, "=");
if (!d)
break;
@@ -502,8 +503,9 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s, 
int alt,
char *st;
 
debug("%s: %s interface: %s dev: %s\n", __func__, s, interface, devstr);
-   st = strsep(&s, " ");
+   st = strsep(&s, " \t");
strlcpy(dfu->name, st, DFU_NAME_SIZE);
+   s = skip_spaces(s);
 
dfu->alt = alt;
dfu->max_buf_size = 0;
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 3dab5a5f63..d747ede66c 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -351,11 +351,12 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char 
*devstr, char *s)
dfu->data.mmc.dev_num = dectoul(devstr, NULL);
 
for (; parg < argv + sizeof(argv) / sizeof(*argv); ++parg) {
-   *parg = strsep(&s, " ");
+   *parg = strsep(&s, " \t");
if (*parg == NULL) {
pr_err("Invalid number of arguments.\n");
return -ENODEV;
}
+   s = skip_spaces(s);
}
 
entity_type = argv[0];
@@ -390,9 +391,11 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char 
*devstr, char *s)
 * specifying the mmc HW defined partition number
 */
if (s)
-   if (!strcmp(strsep(&s, " "), "mmcpart"))
+   if (!strcmp(strsep(&s, " \t"), "mmcpart")) {
+   s = skip_spaces(s);
dfu->data.mmc.hw_partition =
simple_strtoul(s, NULL, 0);
+   }
 
} else if (!strcmp(entity_type, "part")) {
struct disk_partition partinfo;
@@ -412,8 +415,10 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char 
*devstr, char *s)
 * specifying the mmc HW defined partition number
 */
if (s)
-   if (!strcmp(strsep(&s, " "), "offset"))
+   if (!strcmp(strsep(&s, " \t"), "offset")) {
+   s = skip_spaces(s);
offset = simple_strtoul(s, NULL, 0);
+   }
 
dfu->layout = DFU_RAW_ADDR;
dfu->data.mmc.lba_start = partinfo.start + offset;
diff --git a/drivers/dfu/dfu_mtd.c b/drivers/dfu/dfu_mtd.c
index 0b7f17761f..ee534a9d10 100644
--- a/drivers/dfu/dfu_mtd.c
+++ b/drivers/dfu/dfu_mtd.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static bool mtd_is_aligned_with_block_size(struct mtd_info *mtd, u64 size)
 {
@@ -265,11 +266,14 @@ int dfu_fill_entity_mtd(struct dfu_entity *dfu, char 
*devstr, char *s)
dfu->data.mtd.info = mtd;
dfu->max_buf_size = mtd->erasesize;
 
-   st = strsep(&s, " ");
+   st = strsep(&s, " \t");
+   s = skip_spaces(s);
if (!strcmp(st, "raw")) {
dfu->layout = DFU_RAW_ADDR;
dfu->data.mtd.start = hextoul(s, &s);
-   s++;
+   if (!isspace(*s))
+   return -1;
+   s = skip_spaces(s);
dfu->data.mtd.size = hextoul(s, &s);
} else if ((!strcmp(st, "part")) || (!strcmp(st, "partubi"))) {
char mtd_id[32];
diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
index e53b35e42b..76761939ab 100644
--- a/drivers/dfu/dfu_nand.c
+++ b/drivers/dfu/dfu_nand.c
@@ -201,11 +201,14 @@ int dfu_fill_entity_nand(struct dfu_entity *dfu, char 
*devstr, char *s)
 
dfu->data.nand.ubi = 0;
dfu->dev_type = DFU_DEV_NAND;
-   st = strsep(&s, " ");
+   st = strsep(&s, " \t");
+   s = skip_spaces(s);

[PATCH 3/5] DFU: Check the number of arguments and argument string strictly

[Masami Hiramatsu]

When parsing the dfu_alt_info, check the number of arguments
and argument string strictly. If there is any garbage data
(which is not able to be parsed correctly) in dfu_alt_info,
that means something wrong and user may make a typo or mis-
understanding about the syntax. Since the dfu_alt_info is
used for updating the firmware, this mistake may lead to
brick the hardware.
Thus it should be checked strictly for making sure there
is no mistake.

Signed-off-by: Masami Hiramatsu 
---
 drivers/dfu/dfu.c  |   31 +--
 drivers/dfu/dfu_mmc.c  |   56 ++--
 drivers/dfu/dfu_mtd.c  |   36 +++
 drivers/dfu/dfu_nand.c |   39 ++---
 drivers/dfu/dfu_ram.c  |   25 ++---
 drivers/dfu/dfu_sf.c   |   38 +
 drivers/dfu/dfu_virt.c |5 +++-
 include/dfu.h  |   33 ++--
 8 files changed, 154 insertions(+), 109 deletions(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 18154774f9..516dda6179 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -500,12 +500,29 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size, 
int blk_seq_num)
 static int dfu_fill_entity(struct dfu_entity *dfu, char *s, int alt,
   char *interface, char *devstr)
 {
+   char *argv[DFU_MAX_ENTITY_ARGS];
+   int argc;
char *st;
 
debug("%s: %s interface: %s dev: %s\n", __func__, s, interface, devstr);
st = strsep(&s, " \t");
strlcpy(dfu->name, st, DFU_NAME_SIZE);
-   s = skip_spaces(s);
+
+   /* Parse arguments */
+   for (argc = 0; s && argc < DFU_MAX_ENTITY_ARGS; argc++) {
+   s = skip_spaces(s);
+   if (!*s)
+   break;
+   argv[argc] = strsep(&s, " \t");
+   }
+
+   if (argc == DFU_MAX_ENTITY_ARGS && s) {
+   s = skip_spaces(s);
+   if (*s) {
+   log_err("Too many arguments for %s\n", dfu->name);
+   return -EINVAL;
+   }
+   }
 
dfu->alt = alt;
dfu->max_buf_size = 0;
@@ -513,22 +530,22 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char 
*s, int alt,
 
/* Specific for mmc device */
if (strcmp(interface, "mmc") == 0) {
-   if (dfu_fill_entity_mmc(dfu, devstr, s))
+   if (dfu_fill_entity_mmc(dfu, devstr, argv, argc))
return -1;
} else if (strcmp(interface, "mtd") == 0) {
-   if (dfu_fill_entity_mtd(dfu, devstr, s))
+   if (dfu_fill_entity_mtd(dfu, devstr, argv, argc))
return -1;
} else if (strcmp(interface, "nand") == 0) {
-   if (dfu_fill_entity_nand(dfu, devstr, s))
+   if (dfu_fill_entity_nand(dfu, devstr, argv, argc))
return -1;
} else if (strcmp(interface, "ram") == 0) {
-   if (dfu_fill_entity_ram(dfu, devstr, s))
+   if (dfu_fill_entity_ram(dfu, devstr, argv, argc))
return -1;
} else if (strcmp(interface, "sf") == 0) {
-   if (dfu_fill_entity_sf(dfu, devstr, s))
+   if (dfu_fill_entity_sf(dfu, devstr, argv, argc))
return -1;
} else if (strcmp(interface, "virt") == 0) {
-   if (dfu_fill_entity_virt(dfu, devstr, s))
+   if (dfu_fill_entity_virt(dfu, devstr, argv, argc))
return -1;
} else {
printf("%s: Device %s not (yet) supported!\n",
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index d747ede66c..a91da972d4 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -337,35 +337,34 @@ void dfu_free_entity_mmc(struct dfu_entity *dfu)
  * 4th (optional):
  * mmcpart  (access to HW eMMC partitions)
  */
-int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *devstr, char *s)
+int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *devstr, char **argv, int 
argc)
 {
const char *entity_type;
ssize_t second_arg;
size_t third_arg;
-
struct mmc *mmc;
+   char *s;
 
-   const char *argv[3];
-   const char **parg = argv;
-
-   dfu->data.mmc.dev_num = dectoul(devstr, NULL);
-
-   for (; parg < argv + sizeof(argv) / sizeof(*argv); ++parg) {
-   *parg = strsep(&s, " \t");
-   if (*parg == NULL) {
-   pr_err("Invalid number of arguments.\n");
-   return -ENODEV;
-   }
-   s = skip_spaces(s);
+   if (argc < 3) {
+   pr_err("The number of parameters are not enough.\n");
+   return -EINVAL;
}
 
+   dfu->data.mmc.dev_num = dectoul(devstr, &s);
+   if (*s)
+   return -EINVAL;
+
entity_type = argv[0];
/*
   

[PATCH 4/5] doc: usage: DFU: Fix dfu_alt_info document

[Masami Hiramatsu]

Fix some typo and wrong information about dfu_alt_info.
- Add the parameter format, decimal only or hexadecimal.
- Use same parameter name for the same kind of parameters.
  (e.g. dev -> dev_id)

Signed-off-by: Masami Hiramatsu 
---
 doc/usage/dfu.rst |   57 +
 1 file changed, 40 insertions(+), 17 deletions(-)

diff --git a/doc/usage/dfu.rst b/doc/usage/dfu.rst
index 11c88072b8..ed47ff561e 100644
--- a/doc/usage/dfu.rst
+++ b/doc/usage/dfu.rst
@@ -113,9 +113,9 @@ mmc
 each element in *dfu_alt_info* being
 
 *  raw   [mmcpart ]   raw access to mmc device
-*  part   [mmcpart ]  raw access to partition
-*  fat   [mmcpart ]   file in FAT partition
-*  ext4   [mmcpart ]  file in EXT4 partition
+*  part   [offset ]  raw access to partition
+*  fat file in FAT partition
+*  ext4file in EXT4 partition
 *  skip 0 0  ignore flashed data
 *  script 0 0execute commands in shell
 
@@ -169,14 +169,20 @@ nand
 
 each element in *dfu_alt_info* being either of
 
-*  raw raw access to mmc device
-*  partraw acces to partition
-*  partubiraw acces to ubi partition
+*  raw  raw access to nand device
+*  part   raw access to partition
+*  partubiraw access to ubi partition
 
 with
 
-partid
-is the MTD partition index
+offset
+is the offset in the nand device (hexadecimal without "0x")
+size
+is the size of the access area (hexadecimal without "0x")
+dev_id
+is the NAND device index (decimal only)
+part_id
+is the NAND partition index (decimal only)
 
 ram
 raw access to ram::
@@ -190,6 +196,13 @@ ram
 
ramraw access to ram
 
+with
+
+offset
+is the offset in the ram device (hexadecimal without "0x")
+size
+is the size of the access area (hexadecimal without "0x")
+
 sf
 serial flash : NOR::
 
@@ -198,13 +211,19 @@ sf
 each element in *dfu_alt_info* being either of:
 
 *  rawraw access to sf device
-*  partraw acces to partition
-*  partubiraw acces to ubi partition
+*  partraw acces to partition
+*  partubiraw acces to ubi partition
 
 with
 
-partid
-is the MTD partition index
+offset
+is the offset in the sf device (hexadecimal without "0x")
+size
+is the size of the access area (hexadecimal without "0x")
+dev_id
+is the sf device index (the device is "nor") (deximal only)
+part_id
+is the MTD partition index (decimal only)
 
 mtd
 all MTD device: NAND, SPI-NOR, SPI-NAND,...::
@@ -219,14 +238,18 @@ mtd
 
 each element in *dfu_alt_info* being either of:
 
-*  raw   forraw access to mtd device
-*  part   for raw acces to partition
-*  partubi   for raw acces to ubi partition
+*  rawfor raw access to mtd device
+*  partfor raw access to partition
+*  partubi for raw access to ubi partition
 
 with
 
-partid
-is the MTD partition index
+offset
+is the offset in the mtd device (hexadecimal without "0x")
+size
+is the size of the access area (hexadecimal without "0x")
+part_id
+is the MTD partition index (decimal only)
 
 virt
 virtual flash back end for DFU

[PATCH 5/5] cmd/dfu: Enable 'dfu list' command without DFU_OVER_USB

[Masami Hiramatsu]

Since dfu is not only used for USB, and some platform only
supports DFU_OVER_TFTP or EFI capsule update, dfu_alt_info
is defined on such platforms too.

For such platform, 'dfu list' command is useful to check
how the current dfu_alt_info setting is parsed.

Signed-off-by: Masami Hiramatsu 
---
 cmd/dfu.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cmd/dfu.c b/cmd/dfu.c
index 4a288f74c2..208555c888 100644
--- a/cmd/dfu.c
+++ b/cmd/dfu.c
@@ -50,7 +50,6 @@ static int do_dfu(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
if (!strcmp(argv[1], "tftp"))
return update_tftp(value, interface, devstring);
 #endif
-#ifdef CONFIG_DFU_OVER_USB
ret = dfu_init_env_entities(interface, devstring);
if (ret)
goto done;
@@ -65,6 +64,7 @@ static int do_dfu(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
goto done;
}
 
+#ifdef CONFIG_DFU_OVER_USB
int controller_index = simple_strtoul(usb_controller, NULL, 0);
bool retry = false;
do {
@@ -79,9 +79,9 @@ static int do_dfu(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
}
} while (retry);
 
+#endif
 done:
dfu_free_entities();
-#endif
return ret;
 }
 
@@ -100,8 +100,8 @@ U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu,
 #ifdef CONFIG_DFU_TIMEOUT
"[] - specify inactivity timeout in seconds\n"
 #endif
-   "[list] - list available alt settings\n"
 #endif
+   "[list] - list available alt settings\n"
 #ifdef CONFIG_DFU_OVER_TFTP
 #ifdef CONFIG_DFU_OVER_USB
"dfu "

Re: [PATCH] MAINTAINERS: Remove Anastasiia Lukianenko from Xen entry

[Oleksandr Andrushchenko]

Hi, all!

Anastasiia has left EPAM, so now her e-mail bounces.
I can updated the e-mail if Anastasiia is still up to maintaining Xen part in 
U-boot.

Thank you,
Oleksandr

On 06.12.21 09:09, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
>
> Anastasiia Lukianenko's e-mail is now bouncing, so remove it from
> the maintainers list.
>
> Signed-off-by: Oleksandr Andrushchenko 
>
> ---
> Cc: Anastasiia Lukianenko 
> ---
> Anastasiia if instead of just removing your e-mail you still want to
> maintain Xen support in U-boot please please provide a new e-mail, so I
> can update.
> ---
>   MAINTAINERS | 1 -
>   1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9045e509d737..4d80a6c282c5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1288,7 +1288,6 @@ F:  arch/x86/
>   F:  cmd/x86/
>   
>   XEN
> -M:   Anastasiia Lukianenko 
>   M:  Oleksandr Andrushchenko 
>   S:  Maintained
>   F:  arch/arm/cpu/armv8/xen/

Re: [PATCH 0/5] Series short description

[Masami Hiramatsu]

Sorry, please ignore this mail, i missed to update the subject.
Thanks,

2021年12月6日(月) 14:43 Masami Hiramatsu :
>
> Hi,
>
> This series is improving DFU subsystem. This improves dfu_alt_info
> parser and fixing documents etc.
>
> When I was debuging my patch for updating dfu_alt_info on the
> DeveloperBox platform, I found that dfu_alt_info parser doesn't
> accept redundant spaces and tabs. Also the dfu.rst description
> seems wrong. Moreover, there is no way to check whether the
> parser parses the dfu_alt_info correctly.
>
> These patches fixes such issues. [1/5] is just for avoiding
> buffer overrun, [2/5] and [3/5] improves dfu_alt_info parser
> to accept redundant spaces and tabs, and check the number of
> arguments strictly so that the parser (and user) can notice
> any unexpected parameters. [4/5] fixes the documents (there
> seems some wrong description maybe coming from copy&paste).
> [5/5] allows user to run 'dfu list' even if the platform
> doesn't support DFU_OVER_USB.
>
> Thank you,
>
> ---
>
> Masami Hiramatsu (5):
>   DFU: Do not copy the entity name over the buffer size
>   DFU: Accept redundant spaces and tabs in dfu_alt_info
>   DFU: Check the number of arguments and argument string strictly
>   doc: usage: DFU: Fix dfu_alt_info document
>   cmd/dfu: Enable 'dfu list' command without DFU_OVER_USB
>
>
>  cmd/dfu.c  |6 +++--
>  doc/usage/dfu.rst  |   57 
> ++--
>  drivers/dfu/dfu.c  |   37 ---
>  drivers/dfu/dfu_mmc.c  |   55 +++---
>  drivers/dfu/dfu_mtd.c  |   34 +++--
>  drivers/dfu/dfu_nand.c |   34 ++---
>  drivers/dfu/dfu_ram.c  |   24 ++--
>  drivers/dfu/dfu_sf.c   |   34 ++---
>  drivers/dfu/dfu_virt.c |5 +++-
>  include/dfu.h  |   33 ++--
>  10 files changed, 205 insertions(+), 114 deletions(-)
>
> --
> Masami Hiramatsu 



-- 
Masami Hiramatsu