Re: U-boot

[Thomas Perrot]

Hi Roman,

On Sat, 2021-07-31 at 03:34 +, Roman Kopytin wrote:
> Thanks, Michael.
> Can we sign in the separate state on special server for example?

Yes, it possible, there is a step to build and another one to sign,
that can be separated.

For example, the following command, that build and sign the itb:
# build and sign
mkimage -D "-I dts -O dtb -p 4096" -f ./foo.its -k ./keys -K ./u-
boot.dtb -r ./foo.itb

Can be spitted in two:
# build
uboot-mkimage \
-D "-I dts -O dtb -p 4096" \
-f ./foo.its \
./foo.itb

# sign
uboot-mkimage \
-D "-I dts -O dtb -p 4096" -F 
-k ./keys \
-K ./u-boot.dtb \
-r \
./foo.itb

Then the u-boot*.dtb should contains the pubkey node(s) in the
signature node and it can be shared and concatenated to the U-Boot
binary:

make EXT_DTB="./u-boot.dtb"

> Looks like we can work with public key only in this step.

The dtb containing the public key(s) is useful to verify the signature
at the target boot, or with the tool fit_check_sign to perform an
offload checking, for example:

fit_check_sign -f ./foo.itb -k ./u-boot.dtb

Best regards,
Thomas Perrot

> 
> From: Michael Nazzareno Trimarchi 
> Sent: Friday, July 30, 2021 8:50 PM
> To: Roman Kopytin 
> Cc: U-Boot-Denx ; Simon Glass 
> Subject: Re: U-boot
> 
> Caution: This is an external email. Be cautious while opening links or
> attachments.
> 
> 
> Hi Román
> 
> 
> On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin < 
> roman.kopy...@kaspersky.com> wrote:
> Hello, dear U-boot team
> 
> I have question about your old feature: U-boot patch for adding of the
> public key to dtb file.
>  
> https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/
> 
> I can’t understand, can we work only with public key? Why do we need to
> have private key for adding step?
> In documentation it is not very clear for me.
> 
> You need to sign with private key and keep it secret and local and
> verify it during booting with public key. Private key is not
> distributed with the image
> 
> Michael
> 
> 
> Thanks a lot.
> 

-- 
Thomas Perrot, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com



signature.asc
Description: This is a digitally signed message part

Re: [PATCH 2/2] x86: dts: Define a default TSC timer frequency

[Bin Meng]

On Thu, Jul 29, 2021 at 9:32 AM Simon Glass  wrote:
>
> On Tue, 27 Jul 2021 at 22:00, Bin Meng  wrote:
> >
> > If for some reason, TSC timer frequency cannot be determined from
> > hardware, nor is it specified in the device tree, U-Boot will panic
> > resulting in endless reset during boot.
> >
> > Let's define a default TSC timer frequency using the Kconfig value
> > CONFIG_X86_TSC_TIMER_FREQ (note: #include must be used instead of
> > /include/ otherwise the macro is not pre-processed).
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  arch/x86/dts/bayleybay.dts| 2 +-
> >  arch/x86/dts/baytrail_som-db5800-som-6867.dts | 2 +-
> >  arch/x86/dts/cherryhill.dts   | 2 +-
> >  arch/x86/dts/chromebook_coral.dts | 3 ++-
> >  arch/x86/dts/chromebook_link.dts  | 2 +-
> >  arch/x86/dts/chromebook_samus.dts | 2 +-
> >  arch/x86/dts/chromebox_panther.dts| 2 +-
> >  arch/x86/dts/conga-qeval20-qa3-e3845.dts  | 2 +-
> >  arch/x86/dts/coreboot.dts | 7 ++-
> >  arch/x86/dts/cougarcanyon2.dts| 2 +-
> >  arch/x86/dts/crownbay.dts | 2 +-
> >  arch/x86/dts/edison.dts   | 2 +-
> >  arch/x86/dts/efi-x86_app.dts  | 7 ++-
> >  arch/x86/dts/efi-x86_payload.dts  | 7 ++-
> >  arch/x86/dts/galileo.dts  | 7 ++-
> >  arch/x86/dts/minnowmax.dts| 2 +-
> >  arch/x86/dts/qemu-x86_i440fx.dts  | 6 +-
> >  arch/x86/dts/qemu-x86_q35.dts | 6 +-
> >  arch/x86/dts/slimbootloader.dts   | 2 +-
> >  arch/x86/dts/tsc_timer.dtsi   | 1 +
> >  20 files changed, 25 insertions(+), 43 deletions(-)
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!

Re: [PATCH 1/2] x86: tsc: Rename X86_TSC_TIMER_EARLY_FREQ to X86_TSC_TIMER_FREQ

[Bin Meng]

On Sat, Jul 31, 2021 at 9:35 AM Simon Glass  wrote:
>
> On Tue, 27 Jul 2021 at 22:00, Bin Meng  wrote:
> >
> > Currently there are two places to specify the x86 TSC timer frequency
> > with one in Kconfig used for early timer and the other one in device
> > tree used when the frequency cannot be determined from hardware.
> >
> > This may potentially create an inconsistent config where the 2 values
> > do not match. Let's use the one specified in Kconfig in the device
> > tree as well.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  arch/x86/cpu/quark/Kconfig | 4 ++--
> >  arch/x86/dts/galileo.dts   | 2 +-
> >  drivers/timer/Kconfig  | 8 
> >  drivers/timer/tsc_timer.c  | 5 +++--
> >  4 files changed, 10 insertions(+), 9 deletions(-)
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!

Re: [PATCH] x86: kconfig: Drop ROM_NEEDS_BLOBS and BUILD_ROM

[Bin Meng]

On Sat, Jul 31, 2021 at 9:35 AM Simon Glass  wrote:
>
> On Tue, 27 Jul 2021 at 09:15, Bin Meng  wrote:
> >
> > These 2 options are no longer needed as now binman is used to build
> > u-boot.rom.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  Kconfig| 21 -
> >  arch/x86/Kconfig   |  2 --
> >  arch/x86/cpu/quark/Kconfig |  1 -
> >  doc/arch/x86.rst   | 13 ++---
> >  4 files changed, 2 insertions(+), 35 deletions(-)
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!

Re: [PATCH] x86: crownbay: Adjust VGA rom address

[Bin Meng]

On Sat, Jul 31, 2021 at 9:35 AM Simon Glass  wrote:
>
> On Tue, 27 Jul 2021 at 07:30, Bin Meng  wrote:
> >
> > binman complains when binary blobs are present:
> >
> >   Node '/binman/rom/intel-vga': Offset 0xfff9 (4294508544) overlaps
> >   with previous entry '/binman/rom/u-boot-dtb-with-ucode' ending at
> >   0xfff9204c (4294516812)
> >
> > Adjust VGA rom address to 0xfffa so that u-boot.rom image can be
> > successfully built again.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  configs/crownbay_defconfig | 1 +
> >  1 file changed, 1 insertion(+)
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!

Re: [PATCH 1/2] x86: tsc: Rename X86_TSC_TIMER_EARLY_FREQ to X86_TSC_TIMER_FREQ

[Simon Glass]

On Tue, 27 Jul 2021 at 22:00, Bin Meng  wrote:
>
> Currently there are two places to specify the x86 TSC timer frequency
> with one in Kconfig used for early timer and the other one in device
> tree used when the frequency cannot be determined from hardware.
>
> This may potentially create an inconsistent config where the 2 values
> do not match. Let's use the one specified in Kconfig in the device
> tree as well.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/cpu/quark/Kconfig | 4 ++--
>  arch/x86/dts/galileo.dts   | 2 +-
>  drivers/timer/Kconfig  | 8 
>  drivers/timer/tsc_timer.c  | 5 +++--
>  4 files changed, 10 insertions(+), 9 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH] x86: kconfig: Drop ROM_NEEDS_BLOBS and BUILD_ROM

[Simon Glass]

On Tue, 27 Jul 2021 at 09:15, Bin Meng  wrote:
>
> These 2 options are no longer needed as now binman is used to build
> u-boot.rom.
>
> Signed-off-by: Bin Meng 
> ---
>
>  Kconfig| 21 -
>  arch/x86/Kconfig   |  2 --
>  arch/x86/cpu/quark/Kconfig |  1 -
>  doc/arch/x86.rst   | 13 ++---
>  4 files changed, 2 insertions(+), 35 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH] x86: crownbay: Adjust VGA rom address

[Simon Glass]

On Tue, 27 Jul 2021 at 07:30, Bin Meng  wrote:
>
> binman complains when binary blobs are present:
>
>   Node '/binman/rom/intel-vga': Offset 0xfff9 (4294508544) overlaps
>   with previous entry '/binman/rom/u-boot-dtb-with-ucode' ending at
>   0xfff9204c (4294516812)
>
> Adjust VGA rom address to 0xfffa so that u-boot.rom image can be
> successfully built again.
>
> Signed-off-by: Bin Meng 
> ---
>
>  configs/crownbay_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass 

Re: [PATCH 1/2] x86: tsc: Rename X86_TSC_TIMER_EARLY_FREQ to X86_TSC_TIMER_FREQ

[Bin Meng]

Hi Simon,

On Wed, Jul 28, 2021 at 12:00 PM Bin Meng  wrote:
>
> Currently there are two places to specify the x86 TSC timer frequency
> with one in Kconfig used for early timer and the other one in device
> tree used when the frequency cannot be determined from hardware.
>
> This may potentially create an inconsistent config where the 2 values
> do not match. Let's use the one specified in Kconfig in the device
> tree as well.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/cpu/quark/Kconfig | 4 ++--
>  arch/x86/dts/galileo.dts   | 2 +-
>  drivers/timer/Kconfig  | 8 
>  drivers/timer/tsc_timer.c  | 5 +++--
>  4 files changed, 10 insertions(+), 9 deletions(-)
>

Looks you reviewed the 2nd patch but not this one.

And there are other 2 patches related to x86 rom build. Could you
please take a look?

Regards,
Bin

Re: [PATCH v1 1/1] x86: tangier: Fix DMA controller IRQ polarity in CSRT

[Bin Meng]

Hi Simon,

On Sat, Jul 31, 2021 at 9:03 AM Simon Glass  wrote:
>
> On Fri, 30 Jul 2021 at 14:15, Andy Shevchenko
>  wrote:
> >
> > IRQ polarity in CSRT has the same definition as by ACPI specification
> > chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
> > ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
> > IRQ polarity is ActiveHigh.
> >
> > Note, in DSDT (see southcluster.asl) it's described correctly.
> >
> > Fixes: 5e99fde34a77 ("x86: tangier: Populate CSRT for shared DMA 
> > controller")
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  arch/x86/cpu/tangier/acpi.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Reviewed-by: Simon Glass 

Oops, this was applied 1 minute earlier :-)

I've added your RB tag manually.

Regards,
Bin

Re: [PATCH v1 1/1] x86: tangier: Fix DMA controller IRQ polarity in CSRT

[Simon Glass]

On Fri, 30 Jul 2021 at 14:15, Andy Shevchenko
 wrote:
>
> IRQ polarity in CSRT has the same definition as by ACPI specification
> chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
> ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
> IRQ polarity is ActiveHigh.
>
> Note, in DSDT (see southcluster.asl) it's described correctly.
>
> Fixes: 5e99fde34a77 ("x86: tangier: Populate CSRT for shared DMA controller")
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/cpu/tangier/acpi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH v1 1/1] x86: tangier: Fix DMA controller IRQ polarity in CSRT

[Bin Meng]

On Sat, Jul 31, 2021 at 7:44 AM Bin Meng  wrote:
>
> On Sat, Jul 31, 2021 at 4:15 AM Andy Shevchenko
>  wrote:
> >
> > IRQ polarity in CSRT has the same definition as by ACPI specification
> > chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
> > ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
> > IRQ polarity is ActiveHigh.
> >
> > Note, in DSDT (see southcluster.asl) it's described correctly.
> >
> > Fixes: 5e99fde34a77 ("x86: tangier: Populate CSRT for shared DMA 
> > controller")
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  arch/x86/cpu/tangier/acpi.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!

Re: [PATCH] x86: dts: Add "m25p,fast-read" to SPI flash node

[Bin Meng]

On Sat, Jul 31, 2021 at 3:02 AM Simon Glass  wrote:
>
> On Thu, 29 Jul 2021 at 06:18, Bin Meng  wrote:
> >
> > Except ICH7 SPI, all SPI flashes connected to ICH9 / Fast SPI should
> > have "m25p,fast-read" property present in their DT nodes.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  arch/x86/dts/bayleybay.dts| 1 +
> >  arch/x86/dts/baytrail_som-db5800-som-6867.dts | 1 +
> >  arch/x86/dts/cherryhill.dts   | 1 +
> >  arch/x86/dts/chromebook_coral.dts | 1 +
> >  arch/x86/dts/chromebook_link.dts  | 1 +
> >  arch/x86/dts/chromebook_samus.dts | 1 +
> >  arch/x86/dts/chromebox_panther.dts| 1 +
> >  arch/x86/dts/conga-qeval20-qa3-e3845.dts  | 1 +
> >  arch/x86/dts/cougarcanyon2.dts| 1 +
> >  arch/x86/dts/dfi-bt700.dtsi   | 1 +
> >  arch/x86/dts/minnowmax.dts| 1 +
> >  11 files changed, 11 insertions(+)
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!

Re: [PATCH v1 1/1] x86: tangier: Fix DMA controller IRQ polarity in CSRT

[Bin Meng]

On Sat, Jul 31, 2021 at 4:15 AM Andy Shevchenko
 wrote:
>
> IRQ polarity in CSRT has the same definition as by ACPI specification
> chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
> ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
> IRQ polarity is ActiveHigh.
>
> Note, in DSDT (see southcluster.asl) it's described correctly.
>
> Fixes: 5e99fde34a77 ("x86: tangier: Populate CSRT for shared DMA controller")
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/cpu/tangier/acpi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 

Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL

[Tom Rini]

On Fri, Jul 30, 2021 at 03:48:15PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 30 Jul 2021 at 15:33, Tom Rini  wrote:
> >
> > On Fri, Jul 30, 2021 at 01:02:18PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 29 Jul 2021 at 07:52, Tom Rini  wrote:
> > > >
> > > > On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote:
> > > > > Hi,
> > > > >
> > > > > On Wed, 28 Jul 2021 at 17:55, Tom Rini  wrote:
> > > > > >
> > > > > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 7/27/21 12:07 AM, Tom Rini wrote:
> > > > > > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote:
> > > > > > > >
> > > > > > > > > This feature should never have been made available when 
> > > > > > > > > driver model
> > > > > > > > > or devicetree are disabled. Add these as conditions, so that 
> > > > > > > > > we don't
> > > > > > > > > create even more barriers to migration.
> > > > > > > > >
> > > > > > > > > Add a note about the substantial size increment associated 
> > > > > > > > > with this
> > > > > > > > > option.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Simon Glass 
> > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > Changes in v2:
> > > > > > > > > - Split out new patch to make EFI_LOADER depend on DM and 
> > > > > > > > > OF_CONTROL
> > > > > > > > > - Note the approximate size of this feature in the help
> > > > > > > > >
> > > > > > > > >   lib/efi_loader/Kconfig | 4 +++-
> > > > > > > > >   1 file changed, 3 insertions(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > > > > > > index 6242caceb7f..466abfed300 100644
> > > > > > > > > --- a/lib/efi_loader/Kconfig
> > > > > > > > > +++ b/lib/efi_loader/Kconfig
> > > > > > > > > @@ -1,6 +1,6 @@
> > > > > > > > >   config EFI_LOADER
> > > > > > > > >   bool "Support running UEFI applications"
> > > > > > > > > - depends on OF_LIBFDT && ( \
> > > > > > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \
> > > > > > >
> > > > > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we 
> > > > > > > get rid
> > > > > > > of this symbol?
> > > > > >
> > > > > > No, but I did send out a message about that today as we're very 
> > > > > > close.
> > > > > > Much closer than I had expected us to be.
> > > > >
> > > > > Note we will still have SPL_DM, I think.
> > > >
> > > > Right.
> > > >
> > > > > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL and 
> > > > > > > not DM?
> > > > > >
> > > > > > Yes, a few.  It's vexpress_aemv8a_semi, warp (fixed by
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/
> > > > > > so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g 
> > > > > > and sniper.
> > > > > >
> > > > > > > Why are these separate symbols? Isn't this symbol to be 
> > > > > > > eliminated, too?
> > > > > >
> > > > > > Simon?
> > > > >
> > > > > If we do eliminate DM it will be in a separate series. Like Tom I am
> > > > > pleasantly surprised at how close we are.
> > > > >
> > > > > But please let's consider patches on their merits. It is fine to reply
> > > > > with a wishlist but even better to reply with a follow-up patch.
> > > >
> > > > OK.  So, build-wise, EFI_LOADER does not require OF_CONTROL.
> > >
> > > I strongly believe it should (and it should have 5 years ago too). New
> > > features should not be built on pre-migration stuff.
> >
> > Well, what legacy interfaces is it using?  That's something to figure
> > out and address as needed.
> 
> It was built on non-DM and I believe it still has code for non-DM
> (e.g. look for DM_MMC). Without DM, OF_CONTROL has no purpose IMO.
> 
> Perhaps Heinrich has cleaned a lot of that old cruft out now?

Now that DM_MMC and DM_VIDEO are mandatory, there is some cruft that can
be removed, both there and probably tree-wide.  But that's not the same
as OF_CONTROL.  Not all DM_xxx requires OF_CONTROL support.

> > > > > Somewhat related, I think we need to create a separate symbol which
> > > > > means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing.
> > > > >
> > > > > Also I think we should push of-platdata, since otherwise we're going
> > > > > to hit the same problem of migrating SPL boards to DM one day.
> > > >
> > > > Note that we don't have CONFIG_OF_PLATDATA just
> > > > CONFIG_(SPL|TPL)_OF_PLATDATA.
> > >
> > > Indeed. But we haven't defined it because we don't want to permit it.
> > > It is just for constrained environments and we assume that U-Boot
> > > proper has enough space (how else could it load Linux?)
> >
> > If OF_PLATDATA for U-Boot itself makes sense or not is a separate
> > discussion to have.
> 
> OK, I'd love to hear the reasoning on that one day.

This might come up again real soon now in the context of nokia_rx51 and
migrating away from the very old MUSB gadget driver and to modern
DM_USB_GADGET.  The p

Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL

[Simon Glass]

Hi Tom,

On Fri, 30 Jul 2021 at 15:33, Tom Rini  wrote:
>
> On Fri, Jul 30, 2021 at 01:02:18PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 29 Jul 2021 at 07:52, Tom Rini  wrote:
> > >
> > > On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote:
> > > > Hi,
> > > >
> > > > On Wed, 28 Jul 2021 at 17:55, Tom Rini  wrote:
> > > > >
> > > > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote:
> > > > > >
> > > > > >
> > > > > > On 7/27/21 12:07 AM, Tom Rini wrote:
> > > > > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote:
> > > > > > >
> > > > > > > > This feature should never have been made available when driver 
> > > > > > > > model
> > > > > > > > or devicetree are disabled. Add these as conditions, so that we 
> > > > > > > > don't
> > > > > > > > create even more barriers to migration.
> > > > > > > >
> > > > > > > > Add a note about the substantial size increment associated with 
> > > > > > > > this
> > > > > > > > option.
> > > > > > > >
> > > > > > > > Signed-off-by: Simon Glass 
> > > > > > > > ---
> > > > > > > >
> > > > > > > > Changes in v2:
> > > > > > > > - Split out new patch to make EFI_LOADER depend on DM and 
> > > > > > > > OF_CONTROL
> > > > > > > > - Note the approximate size of this feature in the help
> > > > > > > >
> > > > > > > >   lib/efi_loader/Kconfig | 4 +++-
> > > > > > > >   1 file changed, 3 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > > > > > index 6242caceb7f..466abfed300 100644
> > > > > > > > --- a/lib/efi_loader/Kconfig
> > > > > > > > +++ b/lib/efi_loader/Kconfig
> > > > > > > > @@ -1,6 +1,6 @@
> > > > > > > >   config EFI_LOADER
> > > > > > > >   bool "Support running UEFI applications"
> > > > > > > > - depends on OF_LIBFDT && ( \
> > > > > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \
> > > > > >
> > > > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get 
> > > > > > rid
> > > > > > of this symbol?
> > > > >
> > > > > No, but I did send out a message about that today as we're very close.
> > > > > Much closer than I had expected us to be.
> > > >
> > > > Note we will still have SPL_DM, I think.
> > >
> > > Right.
> > >
> > > > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL and not 
> > > > > > DM?
> > > > >
> > > > > Yes, a few.  It's vexpress_aemv8a_semi, warp (fixed by
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/
> > > > > so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g and 
> > > > > sniper.
> > > > >
> > > > > > Why are these separate symbols? Isn't this symbol to be eliminated, 
> > > > > > too?
> > > > >
> > > > > Simon?
> > > >
> > > > If we do eliminate DM it will be in a separate series. Like Tom I am
> > > > pleasantly surprised at how close we are.
> > > >
> > > > But please let's consider patches on their merits. It is fine to reply
> > > > with a wishlist but even better to reply with a follow-up patch.
> > >
> > > OK.  So, build-wise, EFI_LOADER does not require OF_CONTROL.
> >
> > I strongly believe it should (and it should have 5 years ago too). New
> > features should not be built on pre-migration stuff.
>
> Well, what legacy interfaces is it using?  That's something to figure
> out and address as needed.

It was built on non-DM and I believe it still has code for non-DM
(e.g. look for DM_MMC). Without DM, OF_CONTROL has no purpose IMO.

Perhaps Heinrich has cleaned a lot of that old cruft out now?

>
> > > > Somewhat related, I think we need to create a separate symbol which
> > > > means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing.
> > > >
> > > > Also I think we should push of-platdata, since otherwise we're going
> > > > to hit the same problem of migrating SPL boards to DM one day.
> > >
> > > Note that we don't have CONFIG_OF_PLATDATA just
> > > CONFIG_(SPL|TPL)_OF_PLATDATA.
> >
> > Indeed. But we haven't defined it because we don't want to permit it.
> > It is just for constrained environments and we assume that U-Boot
> > proper has enough space (how else could it load Linux?)
>
> If OF_PLATDATA for U-Boot itself makes sense or not is a separate
> discussion to have.

OK, I'd love to hear the reasoning on that one day.

>
> > > > > > lib/efi_loader/efi_disk.c is the only place where we maintain 
> > > > > > duplicate
> > > > > > code for DM and non-DM. A dependency on CONFIG_BLK (which itself 
> > > > > > depends
> > > > > > on CONFIG_DM) would make more sense to me. But only in a patch
> > > > > > eliminating the non-BLK code.
> > > > >
> > > > > I just know that off-hand, partition + disk + block has some corner
> > > > > case, but maybe that corner case is unintentional in terms of usage
> > > > > today.
> > > > >
> > > > > > > >   ARM && (SYS_CPU = arm1136 || \
> > > > > > > >   SYS_CPU = arm1176 || \
> > > > > > > > 

Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL

[Tom Rini]

On Fri, Jul 30, 2021 at 01:02:18PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 29 Jul 2021 at 07:52, Tom Rini  wrote:
> >
> > On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote:
> > > Hi,
> > >
> > > On Wed, 28 Jul 2021 at 17:55, Tom Rini  wrote:
> > > >
> > > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote:
> > > > >
> > > > >
> > > > > On 7/27/21 12:07 AM, Tom Rini wrote:
> > > > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote:
> > > > > >
> > > > > > > This feature should never have been made available when driver 
> > > > > > > model
> > > > > > > or devicetree are disabled. Add these as conditions, so that we 
> > > > > > > don't
> > > > > > > create even more barriers to migration.
> > > > > > >
> > > > > > > Add a note about the substantial size increment associated with 
> > > > > > > this
> > > > > > > option.
> > > > > > >
> > > > > > > Signed-off-by: Simon Glass 
> > > > > > > ---
> > > > > > >
> > > > > > > Changes in v2:
> > > > > > > - Split out new patch to make EFI_LOADER depend on DM and 
> > > > > > > OF_CONTROL
> > > > > > > - Note the approximate size of this feature in the help
> > > > > > >
> > > > > > >   lib/efi_loader/Kconfig | 4 +++-
> > > > > > >   1 file changed, 3 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > > > > index 6242caceb7f..466abfed300 100644
> > > > > > > --- a/lib/efi_loader/Kconfig
> > > > > > > +++ b/lib/efi_loader/Kconfig
> > > > > > > @@ -1,6 +1,6 @@
> > > > > > >   config EFI_LOADER
> > > > > > >   bool "Support running UEFI applications"
> > > > > > > - depends on OF_LIBFDT && ( \
> > > > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \
> > > > >
> > > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get 
> > > > > rid
> > > > > of this symbol?
> > > >
> > > > No, but I did send out a message about that today as we're very close.
> > > > Much closer than I had expected us to be.
> > >
> > > Note we will still have SPL_DM, I think.
> >
> > Right.
> >
> > > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL and not DM?
> > > >
> > > > Yes, a few.  It's vexpress_aemv8a_semi, warp (fixed by
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/
> > > > so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g and 
> > > > sniper.
> > > >
> > > > > Why are these separate symbols? Isn't this symbol to be eliminated, 
> > > > > too?
> > > >
> > > > Simon?
> > >
> > > If we do eliminate DM it will be in a separate series. Like Tom I am
> > > pleasantly surprised at how close we are.
> > >
> > > But please let's consider patches on their merits. It is fine to reply
> > > with a wishlist but even better to reply with a follow-up patch.
> >
> > OK.  So, build-wise, EFI_LOADER does not require OF_CONTROL.
> 
> I strongly believe it should (and it should have 5 years ago too). New
> features should not be built on pre-migration stuff.

Well, what legacy interfaces is it using?  That's something to figure
out and address as needed. 

> > > Somewhat related, I think we need to create a separate symbol which
> > > means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing.
> > >
> > > Also I think we should push of-platdata, since otherwise we're going
> > > to hit the same problem of migrating SPL boards to DM one day.
> >
> > Note that we don't have CONFIG_OF_PLATDATA just
> > CONFIG_(SPL|TPL)_OF_PLATDATA.
> 
> Indeed. But we haven't defined it because we don't want to permit it.
> It is just for constrained environments and we assume that U-Boot
> proper has enough space (how else could it load Linux?)

If OF_PLATDATA for U-Boot itself makes sense or not is a separate
discussion to have.

> > > > > lib/efi_loader/efi_disk.c is the only place where we maintain 
> > > > > duplicate
> > > > > code for DM and non-DM. A dependency on CONFIG_BLK (which itself 
> > > > > depends
> > > > > on CONFIG_DM) would make more sense to me. But only in a patch
> > > > > eliminating the non-BLK code.
> > > >
> > > > I just know that off-hand, partition + disk + block has some corner
> > > > case, but maybe that corner case is unintentional in terms of usage
> > > > today.
> > > >
> > > > > > >   ARM && (SYS_CPU = arm1136 || \
> > > > > > >   SYS_CPU = arm1176 || \
> > > > > > >   SYS_CPU = armv7   || \
> > > > > > > @@ -25,6 +25,8 @@ config EFI_LOADER
> > > > > > > will expose the UEFI API to a loaded application, 
> > > > > > > enabling it to
> > > > > > > reuse U-Boot's device drivers.
> > > > > > >
> > > > > > > +   For ARM 32-bit, this adds about 90KB to the size of U-Boot.
> > > > > > > +
> > > > >
> > > > > There is no unit ISO prefix K. Do you mean KiB?
> > > > >
> > > > > 90 KiB may be the value today. Will you update it regularly? Otherwise
> > > > > don't pu

[PATCH v1 1/1] x86: tangier: Fix DMA controller IRQ polarity in CSRT

[Andy Shevchenko]

IRQ polarity in CSRT has the same definition as by ACPI specification
chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
IRQ polarity is ActiveHigh.

Note, in DSDT (see southcluster.asl) it's described correctly.

Fixes: 5e99fde34a77 ("x86: tangier: Populate CSRT for shared DMA controller")
Signed-off-by: Andy Shevchenko 
---
 arch/x86/cpu/tangier/acpi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/cpu/tangier/acpi.c b/arch/x86/cpu/tangier/acpi.c
index 41bd177e095f..82f4ce5a34a4 100644
--- a/arch/x86/cpu/tangier/acpi.c
+++ b/arch/x86/cpu/tangier/acpi.c
@@ -89,8 +89,8 @@ static u32 acpi_fill_csrt_dma(struct acpi_csrt_group *grp)
si->mmio_base_low = 0xff192000;
si->mmio_base_high = 0;
si->gsi_interrupt = 32;
-   si->interrupt_polarity = 1;
-   si->interrupt_mode = 0;
+   si->interrupt_polarity = 0; /* Active High */
+   si->interrupt_mode = 0; /* Level triggered */
si->num_channels = 8;
si->dma_address_width = 32;
si->base_request_line = 0;
-- 
2.30.2

Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL

[Simon Glass]

Hi Tom,

On Thu, 29 Jul 2021 at 07:52, Tom Rini  wrote:
>
> On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote:
> > Hi,
> >
> > On Wed, 28 Jul 2021 at 17:55, Tom Rini  wrote:
> > >
> > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote:
> > > >
> > > >
> > > > On 7/27/21 12:07 AM, Tom Rini wrote:
> > > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote:
> > > > >
> > > > > > This feature should never have been made available when driver model
> > > > > > or devicetree are disabled. Add these as conditions, so that we 
> > > > > > don't
> > > > > > create even more barriers to migration.
> > > > > >
> > > > > > Add a note about the substantial size increment associated with this
> > > > > > option.
> > > > > >
> > > > > > Signed-off-by: Simon Glass 
> > > > > > ---
> > > > > >
> > > > > > Changes in v2:
> > > > > > - Split out new patch to make EFI_LOADER depend on DM and OF_CONTROL
> > > > > > - Note the approximate size of this feature in the help
> > > > > >
> > > > > >   lib/efi_loader/Kconfig | 4 +++-
> > > > > >   1 file changed, 3 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > > > index 6242caceb7f..466abfed300 100644
> > > > > > --- a/lib/efi_loader/Kconfig
> > > > > > +++ b/lib/efi_loader/Kconfig
> > > > > > @@ -1,6 +1,6 @@
> > > > > >   config EFI_LOADER
> > > > > >   bool "Support running UEFI applications"
> > > > > > - depends on OF_LIBFDT && ( \
> > > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \
> > > >
> > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get rid
> > > > of this symbol?
> > >
> > > No, but I did send out a message about that today as we're very close.
> > > Much closer than I had expected us to be.
> >
> > Note we will still have SPL_DM, I think.
>
> Right.
>
> > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL and not DM?
> > >
> > > Yes, a few.  It's vexpress_aemv8a_semi, warp (fixed by
> > > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/
> > > so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g and 
> > > sniper.
> > >
> > > > Why are these separate symbols? Isn't this symbol to be eliminated, too?
> > >
> > > Simon?
> >
> > If we do eliminate DM it will be in a separate series. Like Tom I am
> > pleasantly surprised at how close we are.
> >
> > But please let's consider patches on their merits. It is fine to reply
> > with a wishlist but even better to reply with a follow-up patch.
>
> OK.  So, build-wise, EFI_LOADER does not require OF_CONTROL.

I strongly believe it should (and it should have 5 years ago too). New
features should not be built on pre-migration stuff.

>
> > Somewhat related, I think we need to create a separate symbol which
> > means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing.
> >
> > Also I think we should push of-platdata, since otherwise we're going
> > to hit the same problem of migrating SPL boards to DM one day.
>
> Note that we don't have CONFIG_OF_PLATDATA just
> CONFIG_(SPL|TPL)_OF_PLATDATA.

Indeed. But we haven't defined it because we don't want to permit it.
It is just for constrained environments and we assume that U-Boot
proper has enough space (how else could it load Linux?)

>
> > > > lib/efi_loader/efi_disk.c is the only place where we maintain duplicate
> > > > code for DM and non-DM. A dependency on CONFIG_BLK (which itself depends
> > > > on CONFIG_DM) would make more sense to me. But only in a patch
> > > > eliminating the non-BLK code.
> > >
> > > I just know that off-hand, partition + disk + block has some corner
> > > case, but maybe that corner case is unintentional in terms of usage
> > > today.
> > >
> > > > > >   ARM && (SYS_CPU = arm1136 || \
> > > > > >   SYS_CPU = arm1176 || \
> > > > > >   SYS_CPU = armv7   || \
> > > > > > @@ -25,6 +25,8 @@ config EFI_LOADER
> > > > > > will expose the UEFI API to a loaded application, 
> > > > > > enabling it to
> > > > > > reuse U-Boot's device drivers.
> > > > > >
> > > > > > +   For ARM 32-bit, this adds about 90KB to the size of U-Boot.
> > > > > > +
> > > >
> > > > There is no unit ISO prefix K. Do you mean KiB?
> > > >
> > > > 90 KiB may be the value today. Will you update it regularly? Otherwise
> > > > don't put a number here.
> > > >
> > > > I can't see that the effect on size is truly architecture specific. Why
> > > > do you refer to 32bit ARM?
> > > >
> > > > Such a comment would better fit into a documentation chapter on
> > > > downsizing U-Boot.
> > >
> > > Yes, we should probably drop that specific note.
> >
> > From my POV I really like these notes in Kconfig. They appear in a few
> > places and provide people with rough guidance. I'd like to see more of
> > them. I don't know how we can keep them up-to-date, although I'd argue
> > that they s

Re: [PATCH] x86: dts: Add "m25p,fast-read" to SPI flash node

[Simon Glass]

On Thu, 29 Jul 2021 at 06:18, Bin Meng  wrote:
>
> Except ICH7 SPI, all SPI flashes connected to ICH9 / Fast SPI should
> have "m25p,fast-read" property present in their DT nodes.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/dts/bayleybay.dts| 1 +
>  arch/x86/dts/baytrail_som-db5800-som-6867.dts | 1 +
>  arch/x86/dts/cherryhill.dts   | 1 +
>  arch/x86/dts/chromebook_coral.dts | 1 +
>  arch/x86/dts/chromebook_link.dts  | 1 +
>  arch/x86/dts/chromebook_samus.dts | 1 +
>  arch/x86/dts/chromebox_panther.dts| 1 +
>  arch/x86/dts/conga-qeval20-qa3-e3845.dts  | 1 +
>  arch/x86/dts/cougarcanyon2.dts| 1 +
>  arch/x86/dts/dfi-bt700.dtsi   | 1 +
>  arch/x86/dts/minnowmax.dts| 1 +
>  11 files changed, 11 insertions(+)

Reviewed-by: Simon Glass 

Re: Debugging dtoc?

[Simon Glass]

Hi Tom,

On Fri, 30 Jul 2021 at 11:26, Tom Rini  wrote:
>
> On Fri, Jul 30, 2021 at 10:59:22AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 30 Jul 2021 at 09:10, Tom Rini  wrote:
> > >
> > > On Fri, Jul 30, 2021 at 08:44:29AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 29 Jul 2021 at 07:22, Tom Rini  wrote:
> > > > >
> > > > > On Wed, Jul 28, 2021 at 07:27:08PM -0600, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Wed, 28 Jul 2021 at 17:28, Simon Glass  wrote:
> > > > > > >
> > > > > > > Hi again,
> > > > > > >
> > > > > > > On Mon, 26 Jul 2021 at 08:06, Simon Glass  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Sun, 25 Jul 2021 at 15:10, Tom Rini  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > So, I'm trying to fix the problem on am335x_evm (and some 
> > > > > > > > > family
> > > > > > > > > configs) with needing SPL_OF_CONTROL enabled.  This is mostly 
> > > > > > > > > fine just
> > > > > > > > > enabling the option, except on am335x_evm itself, which is the
> > > > > > > > > kitchen-sink config and overflows memory.  I've gone with 
> > > > > > > > > switching to
> > > > > > > > > SPL_OF_PLATDATA there as am335x in general has all of the 
> > > > > > > > > U_BOOT_DRVINFO
> > > > > > > > > entries it needs I believe.  But, with the following patch:
> > > > > > > > >
> > > > > > > > > diff --git a/arch/arm/dts/am335x-evm-u-boot.dtsi 
> > > > > > > > > b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > > > > > index 4cf5f9928d58..514f682cac99 100644
> > > > > > > > > --- a/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > > > > > +++ b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > > > > > @@ -8,6 +8,7 @@
> > > > > > > > >  &l4_per {
> > > > > > > > >
> > > > > > > > > segment@30 {
> > > > > > > > > +   u-boot,dm-pre-reloc;
> > > > > > > > >
> > > > > > > > > target-module@e000 {
> > > > > > > > > u-boot,dm-pre-reloc;
> > > > > > > > > diff --git a/configs/am335x_boneblack_vboot_defconfig 
> > > > > > > > > b/configs/am335x_boneblack_vboot_defconfig
> > > > > > > > > index a0baeec79edd..ffeefd1a0087 100644
> > > > > > > > > --- a/configs/am335x_boneblack_vboot_defconfig
> > > > > > > > > +++ b/configs/am335x_boneblack_vboot_defconfig
> > > > > > > > > @@ -31,6 +31,7 @@ CONFIG_CMD_SPL=y
> > > > > > > > >  # CONFIG_CMD_SETEXPR is not set
> > > > > > > > >  CONFIG_BOOTP_DNS2=y
> > > > > > > > >  CONFIG_OF_CONTROL=y
> > > > > > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > > > > > >  CONFIG_ENV_OVERWRITE=y
> > > > > > > > >  CONFIG_ENV_IS_IN_MMC=y
> > > > > > > > >  CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> > > > > > > > > diff --git a/configs/am335x_evm_defconfig 
> > > > > > > > > b/configs/am335x_evm_defconfig
> > > > > > > > > index a33efff42a74..f35b2a02f56b 100644
> > > > > > > > > --- a/configs/am335x_evm_defconfig
> > > > > > > > > +++ b/configs/am335x_evm_defconfig
> > > > > > > > > @@ -37,13 +37,16 @@ CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
> > > > > > > > >  
> > > > > > > > > CONFIG_MTDPARTS_DEFAULT="mtdparts=nand.0:128k(NAND.SPL),128k(NAND.SPL.backup1),128k(NAND.SPL.backup2),128k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),1m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)"
> > > > > > > > >  # CONFIG_SPL_EFI_PARTITION is not set
> > > > > > > > >  CONFIG_OF_CONTROL=y
> > > > > > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > > > > > >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack 
> > > > > > > > > am335x-evmsk am335x-bonegreen am335x-icev2 
> > > > > > > > > am335x-pocketbeagle"
> > > > > > > > > +CONFIG_SPL_OF_PLATDATA=y
> > > > > > > > >  CONFIG_ENV_OVERWRITE=y
> > > > > > > > >  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > > > > > > > >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> > > > > > > > >  CONFIG_SPL_ENV_IS_NOWHERE=y
> > > > > > > > >  CONFIG_VERSION_VARIABLE=y
> > > > > > > > >  CONFIG_BOOTP_SEND_HOSTNAME=y
> > > > > > > > > +# CONFIG_SPL_SIMPLE_BUS is not set
> > > > > > > > >  CONFIG_BOOTCOUNT_LIMIT=y
> > > > > > > > >  CONFIG_CLK=y
> > > > > > > > >  CONFIG_CLK_CDCE9XX=y
> > > > > > > > > diff --git a/configs/am335x_evm_spiboot_defconfig 
> > > > > > > > > b/configs/am335x_evm_spiboot_defconfig
> > > > > > > > > index 8f0c330674a9..4a2a56a9af9e 100644
> > > > > > > > > --- a/configs/am335x_evm_spiboot_defconfig
> > > > > > > > > +++ b/configs/am335x_evm_spiboot_defconfig
> > > > > > > > > @@ -32,6 +32,7 @@ CONFIG_BOOTP_DNS2=y
> > > > > > > > >  CONFIG_CMD_MTDPARTS=y
> > > > > > > > >  # CONFIG_SPL_EFI_PARTITION is not set
> > > > > > > > >  CONFIG_OF_CONTROL=y
> > > > > > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > > > > > >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack 
> > > > > > > > > am335x-evmsk am335x-bonegreen am335x-icev2 
> > > > > > > > > am335x-pocketbeagle"
> > > > > > > > >  CONFIG_ENV_OVERWRITE=y
> > > > > > > > >  # CONFIG_ENV_IS_IN_FAT is not set
> > > > > > > >

[PATCH v4 1/5] arm: dts: Add IOT2050 device tree files

[Jan Kiszka]

From: Jan Kiszka 

Prepares for the addition of the IOT2050 board which is based on the TI
AM65x. The board comes in two variants, Basic and Advanced, so there are
separate dts files. Furthermore, the SPL has its own device tree.

Based on original board support by Le Jin, Gao Nian and Chao Zeng.

Signed-off-by: Jan Kiszka 
---
 arch/arm/dts/Makefile |   7 +-
 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi  | 105 +++
 .../dts/k3-am65-iot2050-common-u-boot.dtsi| 103 +++
 arch/arm/dts/k3-am65-iot2050-common.dtsi  | 655 ++
 arch/arm/dts/k3-am65-iot2050-spl.dts  |  16 +
 arch/arm/dts/k3-am6528-iot2050-basic.dts  |  67 ++
 arch/arm/dts/k3-am6548-iot2050-advanced.dts   |  66 ++
 7 files changed, 1018 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
 create mode 100644 arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-am65-iot2050-common.dtsi
 create mode 100644 arch/arm/dts/k3-am65-iot2050-spl.dts
 create mode 100644 arch/arm/dts/k3-am6528-iot2050-basic.dts
 create mode 100644 arch/arm/dts/k3-am6548-iot2050-advanced.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 537c96bf5b..08aa3c09f8 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1084,7 +1084,12 @@ dtb-$(CONFIG_STM32MP15x) += \
stm32mp15xx-dhcom-picoitx.dtb \
stm32mp15xx-dhcor-avenger96.dtb
 
-dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb k3-am654-r5-base-board.dtb
+dtb-$(CONFIG_SOC_K3_AM6) += \
+   k3-am654-base-board.dtb \
+   k3-am654-r5-base-board.dtb \
+   k3-am65-iot2050-spl.dtb \
+   k3-am6528-iot2050-basic.dtb \
+   k3-am6548-iot2050-advanced.dtb
 dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \
  k3-j721e-r5-common-proc-board.dtb \
  k3-j7200-common-proc-board.dtb \
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi 
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
new file mode 100644
index 00..61745c6c23
--- /dev/null
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2020-2021
+ *
+ * Authors:
+ *   Jan Kiszka 
+ */
+
+#include 
+
+/ {
+   binman {
+   filename = "flash.bin";
+   pad-byte = <0xff>;
+   size = <0x80>;
+
+   blob-ext@0x00 {
+   offset = <0x00>;
+   filename = "tiboot3.bin";
+   };
+
+   blob@0x08 {
+   offset = <0x08>;
+   filename = "tispl.bin";
+   };
+
+   fit@0x28 {
+   description = "U-Boot for IOT2050";
+   offset = <0x28>;
+   images {
+   u-boot {
+   description = "U-Boot";
+   type = "standalone";
+   arch = "arm64";
+   os = "u-boot";
+   compression = "none";
+   load = <0x8080>;
+   entry = <0x8080>;
+   u-boot-nodtb {
+   };
+   };
+
+   fdt-iot2050-basic {
+   description = 
"k3-am6528-iot2050-basic.dtb";
+   type = "flat_dt";
+   arch = "arm64";
+   compression = "none";
+   blob {
+   filename = 
"arch/arm/dts/k3-am6528-iot2050-basic.dtb";
+   };
+   };
+
+   fdt-iot2050-advanced {
+   description = 
"k3-am6548-iot2050-advanced.dtb";
+   type = "flat_dt";
+   arch = "arm64";
+   compression = "none";
+   blob {
+   filename = 
"arch/arm/dts/k3-am6548-iot2050-advanced.dtb";
+   };
+   };
+   };
+
+   configurations {
+   default = "conf-iot2050-basic";
+
+   conf-iot2050-basic {
+   description = "iot2050-basic";
+   firmware = "u-boot";
+   fdt = "fdt-iot2050-basic";
+

[PATCH v4 4/5] watchdog: rti_wdt: Add support for loading firmware

[Jan Kiszka]

From: Jan Kiszka 

To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware, add the required rproc init and loading logic for the
first R5F core to the watchdog start handler. In case the R5F cluster is
in lock-step mode, also initialize the second core. The firmware itself
is embedded into U-Boot binary to ease access to it and ensure it is
properly hashed in case of secure boot.

One possible firmware source is https://github.com/siemens/k3-rti-wdt.

The board is responsible for providing the firmware as additional
loadable via the U-Boot fit image. The driver will pick up its location
from /fit-images/k3-rti-wdt-firmware then.

Signed-off-by: Jan Kiszka 
---
 drivers/watchdog/Kconfig   | 20 +
 drivers/watchdog/rti_wdt.c | 88 ++
 2 files changed, 108 insertions(+)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index f0ff2612a6..1a1fddfe9f 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -209,6 +209,26 @@ config WDT_K3_RTI
  Say Y here if you want to include support for the K3 watchdog
  timer (RTI module) available in the K3 generation of processors.
 
+if WDT_K3_RTI
+
+config WDT_K3_RTI_LOAD_FW
+   bool "Load watchdog firmware"
+   depends on REMOTEPROC
+   help
+ Automatically load the specified firmware image into the MCU R5F
+ core 0. On the AM65x, this firmware is supposed to handle the expiry
+ of the watchdog timer, typically by resetting the system.
+
+config WDT_K3_RTI_FW_FILE
+   string "Watchdog firmware image file"
+   default "k3-rti-wdt.fw"
+   depends on WDT_K3_RTI_LOAD_FW
+   help
+ Firmware image to be embedded into U-Boot and loaded on watchdog
+ start.
+
+endif
+
 config WDT_SANDBOX
bool "Enable Watchdog Timer support for Sandbox"
depends on SANDBOX && WDT
diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c
index 8335b20ae8..253286d349 100644
--- a/drivers/watchdog/rti_wdt.c
+++ b/drivers/watchdog/rti_wdt.c
@@ -11,9 +11,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 /* Timer register set definition */
 #define RTIDWDCTRL 0x90
@@ -42,6 +44,88 @@ struct rti_wdt_priv {
unsigned int clk_khz;
 };
 
+#ifdef CONFIG_WDT_K3_RTI_LOAD_FW
+#define RTI_WDT_FIT_PATH   "/fit-images/k3-rti-wdt-firmware"
+
+static int rti_wdt_load_fw(struct udevice *dev)
+{
+   struct udevice *rproc_dev;
+   int primary_core, ret;
+   u32 cluster_mode;
+   ofnode node;
+   u64 rti_wdt_fw;
+   u32 rti_wdt_fw_size;
+
+   node = ofnode_path(RTI_WDT_FIT_PATH);
+   if (!ofnode_valid(node))
+   goto fit_error;
+
+   ret = ofnode_read_u64(node, "load", &rti_wdt_fw);
+   if (ret)
+   goto fit_error;
+   ret = ofnode_read_u32(node, "size", &rti_wdt_fw_size);
+   if (ret)
+   goto fit_error;
+
+   node = ofnode_by_compatible(ofnode_null(), "ti,am654-r5fss");
+   if (!ofnode_valid(node))
+   goto dt_error;
+
+   ret = ofnode_read_u32(node, "ti,cluster-mode", &cluster_mode);
+   if (ret)
+   cluster_mode = 1;
+
+   node = ofnode_by_compatible(node, "ti,am654-r5f");
+   if (!ofnode_valid(node))
+   goto dt_error;
+
+   ret = uclass_get_device_by_ofnode(UCLASS_REMOTEPROC, node, &rproc_dev);
+   if (ret)
+   return ret;
+
+   primary_core = dev_seq(rproc_dev);
+
+   ret = rproc_dev_init(primary_core);
+   if (ret)
+   goto fw_error;
+
+   if (cluster_mode == 1) {
+   ret = rproc_dev_init(primary_core + 1);
+   if (ret)
+   goto fw_error;
+   }
+
+   ret = rproc_load(primary_core, (ulong)rti_wdt_fw,
+rti_wdt_fw_size);
+   if (ret)
+   goto fw_error;
+
+   ret = rproc_start(primary_core);
+   if (ret)
+   goto fw_error;
+
+   return 0;
+
+fit_error:
+   dev_err(dev, "No loadable firmware found under %s\n", RTI_WDT_FIT_PATH);
+   return -ENOENT;
+
+dt_error:
+   dev_err(dev, "No compatible firmware target processor found\n");
+   return -ENODEV;
+
+fw_error:
+   dev_err(dev, "Failed to load watchdog firmware into remote processor 
%d\n",
+   primary_core);
+   return ret;
+}
+#else
+static inline int rti_wdt_load_fw(struct udevice *dev)
+{
+   return 0;
+}
+#endif
+
 static int rti_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
 {
struct rti_wdt_priv *priv = dev_get_priv(dev);
@@ -51,6 +135,10 @@ static int rti_wdt_start(struct udevice *dev, u64 
timeout_ms, ulong flags)
if (readl(priv->regs + RTIDWDCTRL) == WDENABLE_KEY)
return -EBUSY;
 
+   ret = rti_wdt_load_fw(dev);
+   if (ret < 0)
+   return ret;
+
timer_margin = timeou

[PATCH v4 3/5] arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entry

[Jan Kiszka]

From: Jan Kiszka 

Add the DT entry for a watchdog based on RTI1. It requires additional
firmware on the MCU R5F cores to handle the expiry, e.g.
https://github.com/siemens/k3-rti-wdt. As this firmware will also lock
the power domain to protect it against premature shutdown, mark it
shared.

Aligns us to the kernel's DT in this regard.

Signed-off-by: Jan Kiszka 
---
 arch/arm/dts/k3-am65-mcu.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/dts/k3-am65-mcu.dtsi b/arch/arm/dts/k3-am65-mcu.dtsi
index 7454c8cec0..903796bf7d 100644
--- a/arch/arm/dts/k3-am65-mcu.dtsi
+++ b/arch/arm/dts/k3-am65-mcu.dtsi
@@ -308,4 +308,13 @@
ti,loczrama = <1>;
};
};
+
+   mcu_rti1: rti@4061 {
+   compatible = "ti,j7-rti-wdt";
+   reg = <0x0 0x4061 0x0 0x100>;
+   clocks = <&k3_clks 135 0>;
+   power-domains = <&k3_pds 135 TI_SCI_PD_SHARED>;
+   assigned-clocks = <&k3_clks 135 0>;
+   assigned-clock-parents = <&k3_clks 135 4>;
+   };
 };
-- 
2.31.1

[PATCH v4 5/5] iot2050: Enable watchdog support, but do not auto-start it

[Jan Kiszka]

From: Jan Kiszka 

This allows to use the watchdog in custom scripts but does not enforce
that the OS has to support it as well.

Signed-off-by: Jan Kiszka 
---
 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 16 
 configs/iot2050_defconfig|  6 ++
 2 files changed, 22 insertions(+)

diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi 
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 61745c6c23..8e3f1709e9 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -59,6 +59,16 @@
filename = 
"arch/arm/dts/k3-am6548-iot2050-advanced.dtb";
};
};
+
+#ifdef CONFIG_WDT_K3_RTI_FW_FILE
+   k3-rti-wdt-firmware {
+   type = "blob";
+   load = <0x8200>;
+   blob {
+   filename = 
CONFIG_WDT_K3_RTI_FW_FILE;
+   };
+   };
+#endif
};
 
configurations {
@@ -68,12 +78,18 @@
description = "iot2050-basic";
firmware = "u-boot";
fdt = "fdt-iot2050-basic";
+#ifdef CONFIG_WDT_K3_RTI_FW_FILE
+   loadables = "k3-rti-wdt-firmware";
+#endif
};
 
conf-iot2050-advanced {
description = "iot2050-advanced";
firmware = "u-boot";
fdt = "fdt-iot2050-advanced";
+#ifdef CONFIG_WDT_K3_RTI_FW_FILE
+   loadables = "k3-rti-wdt-firmware";
+#endif
};
};
};
diff --git a/configs/iot2050_defconfig b/configs/iot2050_defconfig
index 6af8971aa5..b30483f73b 100644
--- a/configs/iot2050_defconfig
+++ b/configs/iot2050_defconfig
@@ -51,6 +51,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_WDT=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_TIME=y
 # CONFIG_ISO_PARTITION is not set
@@ -129,4 +130,9 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GENERIC=y
 CONFIG_USB_KEYBOARD=y
+# CONFIG_WATCHDOG is not set
+# CONFIG_WATCHDOG_AUTOSTART is not set
+CONFIG_WDT=y
+CONFIG_WDT_K3_RTI=y
+CONFIG_WDT_K3_RTI_LOAD_FW=y
 CONFIG_OF_LIBFDT_OVERLAY=y
-- 
2.31.1

[PATCH v4 2/5] board: siemens: Add support for SIMATIC IOT2050 devices

[Jan Kiszka]

From: Jan Kiszka 

This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.

Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot
SPL, ATF and TEE have to reside in SPI flash.

Full integration into a bootable image can be found on
https://github.com/siemens/meta-iot2050

Based on original board support by Le Jin, Gao Nian and Chao Zeng.

Signed-off-by: Jan Kiszka 
---
 arch/arm/mach-k3/Kconfig  |   1 +
 board/siemens/iot2050/Kconfig |  32 
 board/siemens/iot2050/MAINTAINERS |   8 +
 board/siemens/iot2050/Makefile|  10 ++
 board/siemens/iot2050/README  |  65 +++
 board/siemens/iot2050/board.c | 284 ++
 board/siemens/iot2050/config.mk   |   8 +
 configs/iot2050_defconfig | 132 ++
 include/configs/iot2050.h |  67 +++
 9 files changed, 607 insertions(+)
 create mode 100644 board/siemens/iot2050/Kconfig
 create mode 100644 board/siemens/iot2050/MAINTAINERS
 create mode 100644 board/siemens/iot2050/Makefile
 create mode 100644 board/siemens/iot2050/README
 create mode 100644 board/siemens/iot2050/board.c
 create mode 100644 board/siemens/iot2050/config.mk
 create mode 100644 configs/iot2050_defconfig
 create mode 100644 include/configs/iot2050.h

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index fa8d134b42..526f5f8b76 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -168,4 +168,5 @@ config K3_DM_FW
 source "board/ti/am65x/Kconfig"
 source "board/ti/am64x/Kconfig"
 source "board/ti/j721e/Kconfig"
+source "board/siemens/iot2050/Kconfig"
 endif
diff --git a/board/siemens/iot2050/Kconfig b/board/siemens/iot2050/Kconfig
new file mode 100644
index 00..8f634c172c
--- /dev/null
+++ b/board/siemens/iot2050/Kconfig
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) Siemens AG, 2018-2021
+#
+# Authors:
+#   Le Jin 
+#   Jan Kiszka 
+
+config TARGET_IOT2050_A53
+   bool "IOT2050 running on A53"
+   select ARM64
+   select SOC_K3_AM6
+   select BOARD_LATE_INIT
+   select SYS_DISABLE_DCACHE_OPS
+   select BINMAN
+
+if TARGET_IOT2050_A53
+
+config SYS_BOARD
+   default "iot2050"
+
+config SYS_VENDOR
+   default "siemens"
+
+config SYS_CONFIG_NAME
+   default "iot2050"
+
+config IOT2050_BOOT_SWITCH
+   bool "Disable eMMC boot via USER button (Advanced version only)"
+   default y
+
+endif
diff --git a/board/siemens/iot2050/MAINTAINERS 
b/board/siemens/iot2050/MAINTAINERS
new file mode 100644
index 00..028fd22960
--- /dev/null
+++ b/board/siemens/iot2050/MAINTAINERS
@@ -0,0 +1,8 @@
+IOT2050 BOARD
+M: Le Jin 
+M: Jan Kiszka 
+S: Maintained
+F: board/siemens/iot2050/
+F: include/configs/iot2050.h
+F: configs/iot2050_defconfig
+F: arch/arm/dts/iot2050-*
diff --git a/board/siemens/iot2050/Makefile b/board/siemens/iot2050/Makefile
new file mode 100644
index 00..619594ab8e
--- /dev/null
+++ b/board/siemens/iot2050/Makefile
@@ -0,0 +1,10 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Makefile for Siemens IOT2050 board
+# Copyright (c) Siemens AG, 2018-2021
+#
+# Authors:
+#   Le Jin 
+#
+
+obj-y += board.o
diff --git a/board/siemens/iot2050/README b/board/siemens/iot2050/README
new file mode 100644
index 00..b63f05b5cf
--- /dev/null
+++ b/board/siemens/iot2050/README
@@ -0,0 +1,65 @@
+SIMATIC IOT2050 BASIC and ADVANCED
+==
+
+The SIMATIC IOT2050 is an open industrial IoT gateway that is using the TI
+AM6528 GP (Basic variant) or the AM6548 HS (Advanced variant). The Advanced
+variant is prepared for secure boot.
+
+The IOT2050 starts only from OSPI. It loads a Siemens-provided bootloader
+called SE-Boot for the MCU domain (R5F cores), then hands over to ATF and
+OP-TEE, before booting U-Boot on the A53 cores. This describes how to build all
+open artifacts into a flashable image for the OSPI flash. The flash image will
+work on both variants.
+
+
+Dependencies
+
+
+ATF:Upstream release 2.4 or newer
+OP-TEE: Upstream release 3.10.0 or newer
+
+Binary dependencies can be found in
+https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild.
+The following binaries from that source need to be present in the build folder:
+
+ - tiboot3.bin
+ - sysfw.itb
+ - sysfw.itb_HS
+
+
+Building
+
+
+Make sure that CROSS_COMPILE is set appropriately:
+
+export CROSS_COMPILE=aarch64-linux-gnu-
+
+ATF:
+
+make PLAT=k3 SPD=opteed K3_USART=1
+
+OP-TEE:
+
+make PLATFORM=k3-am65x CFG_ARM64_core=y \
+ CFG_TEE_CORE_LOG_LEVEL=2 CFG_CONSOLE_UART=1
+
+U-Boot:
+
+export ATF=/path/to/bl31.bin
+export TEE=/path/to/tee-pager_v2.bin
+make iot2050_defconfig
+make
+
+
+Flashing
+
+
+Via U-Boot:

[PATCH v4 0/5] Add SIMATIC IOT2050 board support

[Jan Kiszka]

This is the baseline support for the SIMATIC IOT2050 devices.

Changes in v4:
 - rebased
 - make rtd-wdt firmware a "loadable" inside U-Boot proper fit image,
   avoiding controversial embedding as object
 - improved mmc1 removal from boot_targets
 - fixed various build issues

Changes in v3:
 - rebased
 - addressed several checkpatch warnings
- a few #ifdef -> IS_ENABLED conversions
- comment marker for SPDK identifier in .S file
- trailing whitespaces
 - factored out rti_wdt_load_fw (less #ifdef)

Changes in v2:
 - rebased
 - sync with upstream-accepted DT
 - add boot switch
 - include watchdog support

Allows to boot mainline 5.10 kernels, but not the original BSP-derived
kernel we currently ship as reference. This is due to the TI sysfw ABI
breakages between 2.x and 3.x. We will soon provide a transitional
kernel that allows booting both firmware ABIs - as long as full upstream
kernel support is work in progress.

Note that this baseline support lacks Ethernet drivers. We are working
closely with TI to ensure that the to-be-upstreamed icssg-prueth driver
will work both with new SR2.0 AM65x silicon as well as with SR1.0 which
is used in the currently shipped IOT2050 devices.

A staging tree for complete IOT2050 support can be found at [1]. Full
image integration is available via [2].

Jan

[1] https://github.com/siemens/u-boot/commits/jan/iot2050
[2] https://github.com/siemens/meta-iot2050

Jan Kiszka (5):
  arm: dts: Add IOT2050 device tree files
  board: siemens: Add support for SIMATIC IOT2050 devices
  arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entry
  watchdog: rti_wdt: Add support for loading firmware
  iot2050: Enable watchdog support, but do not auto-start it

 arch/arm/dts/Makefile |   7 +-
 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi  | 121 
 .../dts/k3-am65-iot2050-common-u-boot.dtsi| 103 +++
 arch/arm/dts/k3-am65-iot2050-common.dtsi  | 655 ++
 arch/arm/dts/k3-am65-iot2050-spl.dts  |  16 +
 arch/arm/dts/k3-am65-mcu.dtsi |   9 +
 arch/arm/dts/k3-am6528-iot2050-basic.dts  |  67 ++
 arch/arm/dts/k3-am6548-iot2050-advanced.dts   |  66 ++
 arch/arm/mach-k3/Kconfig  |   1 +
 board/siemens/iot2050/Kconfig |  32 +
 board/siemens/iot2050/MAINTAINERS |   8 +
 board/siemens/iot2050/Makefile|  10 +
 board/siemens/iot2050/README  |  65 ++
 board/siemens/iot2050/board.c | 284 
 board/siemens/iot2050/config.mk   |   8 +
 configs/iot2050_defconfig | 138 
 drivers/watchdog/Kconfig  |  20 +
 drivers/watchdog/rti_wdt.c|  88 +++
 include/configs/iot2050.h |  67 ++
 19 files changed, 1764 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
 create mode 100644 arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-am65-iot2050-common.dtsi
 create mode 100644 arch/arm/dts/k3-am65-iot2050-spl.dts
 create mode 100644 arch/arm/dts/k3-am6528-iot2050-basic.dts
 create mode 100644 arch/arm/dts/k3-am6548-iot2050-advanced.dts
 create mode 100644 board/siemens/iot2050/Kconfig
 create mode 100644 board/siemens/iot2050/MAINTAINERS
 create mode 100644 board/siemens/iot2050/Makefile
 create mode 100644 board/siemens/iot2050/README
 create mode 100644 board/siemens/iot2050/board.c
 create mode 100644 board/siemens/iot2050/config.mk
 create mode 100644 configs/iot2050_defconfig
 create mode 100644 include/configs/iot2050.h

-- 
2.31.1

Re: U-boot

[Michael Nazzareno Trimarchi]

Hi Román


On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin 
wrote:

> Hello, dear U-boot team
>
> I have question about your old feature: U-boot patch for adding of the
> public key to dtb file.
>
> https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/
>
> I can’t understand, can we work only with public key? Why do we need to
> have private key for adding step?
> In documentation it is not very clear for me.
>

You need to sign with private key and keep it secret and local and verify
it during booting with public key. Private key is not distributed with the
image

Michael


> Thanks a lot.
>
>
>

U-boot

[Roman Kopytin]

Hello, dear U-boot team

I have question about your old feature: U-boot patch for adding of the public 
key to dtb file.
https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/

I can’t understand, can we work only with public key? Why do we need to have 
private key for adding step?
In documentation it is not very clear for me.

Thanks a lot.

Re: Debugging dtoc?

[Tom Rini]

On Fri, Jul 30, 2021 at 10:59:22AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 30 Jul 2021 at 09:10, Tom Rini  wrote:
> >
> > On Fri, Jul 30, 2021 at 08:44:29AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 29 Jul 2021 at 07:22, Tom Rini  wrote:
> > > >
> > > > On Wed, Jul 28, 2021 at 07:27:08PM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Wed, 28 Jul 2021 at 17:28, Simon Glass  wrote:
> > > > > >
> > > > > > Hi again,
> > > > > >
> > > > > > On Mon, 26 Jul 2021 at 08:06, Simon Glass  wrote:
> > > > > > >
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Sun, 25 Jul 2021 at 15:10, Tom Rini  wrote:
> > > > > > > >
> > > > > > > > So, I'm trying to fix the problem on am335x_evm (and some family
> > > > > > > > configs) with needing SPL_OF_CONTROL enabled.  This is mostly 
> > > > > > > > fine just
> > > > > > > > enabling the option, except on am335x_evm itself, which is the
> > > > > > > > kitchen-sink config and overflows memory.  I've gone with 
> > > > > > > > switching to
> > > > > > > > SPL_OF_PLATDATA there as am335x in general has all of the 
> > > > > > > > U_BOOT_DRVINFO
> > > > > > > > entries it needs I believe.  But, with the following patch:
> > > > > > > >
> > > > > > > > diff --git a/arch/arm/dts/am335x-evm-u-boot.dtsi 
> > > > > > > > b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > > > > index 4cf5f9928d58..514f682cac99 100644
> > > > > > > > --- a/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > > > > +++ b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > > > > @@ -8,6 +8,7 @@
> > > > > > > >  &l4_per {
> > > > > > > >
> > > > > > > > segment@30 {
> > > > > > > > +   u-boot,dm-pre-reloc;
> > > > > > > >
> > > > > > > > target-module@e000 {
> > > > > > > > u-boot,dm-pre-reloc;
> > > > > > > > diff --git a/configs/am335x_boneblack_vboot_defconfig 
> > > > > > > > b/configs/am335x_boneblack_vboot_defconfig
> > > > > > > > index a0baeec79edd..ffeefd1a0087 100644
> > > > > > > > --- a/configs/am335x_boneblack_vboot_defconfig
> > > > > > > > +++ b/configs/am335x_boneblack_vboot_defconfig
> > > > > > > > @@ -31,6 +31,7 @@ CONFIG_CMD_SPL=y
> > > > > > > >  # CONFIG_CMD_SETEXPR is not set
> > > > > > > >  CONFIG_BOOTP_DNS2=y
> > > > > > > >  CONFIG_OF_CONTROL=y
> > > > > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > > > > >  CONFIG_ENV_OVERWRITE=y
> > > > > > > >  CONFIG_ENV_IS_IN_MMC=y
> > > > > > > >  CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> > > > > > > > diff --git a/configs/am335x_evm_defconfig 
> > > > > > > > b/configs/am335x_evm_defconfig
> > > > > > > > index a33efff42a74..f35b2a02f56b 100644
> > > > > > > > --- a/configs/am335x_evm_defconfig
> > > > > > > > +++ b/configs/am335x_evm_defconfig
> > > > > > > > @@ -37,13 +37,16 @@ CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
> > > > > > > >  
> > > > > > > > CONFIG_MTDPARTS_DEFAULT="mtdparts=nand.0:128k(NAND.SPL),128k(NAND.SPL.backup1),128k(NAND.SPL.backup2),128k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),1m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)"
> > > > > > > >  # CONFIG_SPL_EFI_PARTITION is not set
> > > > > > > >  CONFIG_OF_CONTROL=y
> > > > > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > > > > >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack 
> > > > > > > > am335x-evmsk am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> > > > > > > > +CONFIG_SPL_OF_PLATDATA=y
> > > > > > > >  CONFIG_ENV_OVERWRITE=y
> > > > > > > >  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > > > > > > >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> > > > > > > >  CONFIG_SPL_ENV_IS_NOWHERE=y
> > > > > > > >  CONFIG_VERSION_VARIABLE=y
> > > > > > > >  CONFIG_BOOTP_SEND_HOSTNAME=y
> > > > > > > > +# CONFIG_SPL_SIMPLE_BUS is not set
> > > > > > > >  CONFIG_BOOTCOUNT_LIMIT=y
> > > > > > > >  CONFIG_CLK=y
> > > > > > > >  CONFIG_CLK_CDCE9XX=y
> > > > > > > > diff --git a/configs/am335x_evm_spiboot_defconfig 
> > > > > > > > b/configs/am335x_evm_spiboot_defconfig
> > > > > > > > index 8f0c330674a9..4a2a56a9af9e 100644
> > > > > > > > --- a/configs/am335x_evm_spiboot_defconfig
> > > > > > > > +++ b/configs/am335x_evm_spiboot_defconfig
> > > > > > > > @@ -32,6 +32,7 @@ CONFIG_BOOTP_DNS2=y
> > > > > > > >  CONFIG_CMD_MTDPARTS=y
> > > > > > > >  # CONFIG_SPL_EFI_PARTITION is not set
> > > > > > > >  CONFIG_OF_CONTROL=y
> > > > > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > > > > >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack 
> > > > > > > > am335x-evmsk am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> > > > > > > >  CONFIG_ENV_OVERWRITE=y
> > > > > > > >  # CONFIG_ENV_IS_IN_FAT is not set
> > > > > > > >
> > > > > > > > I get the following failure and I don't see how to debug this:
> > > > > > > >   DTOCspl/dts/dt-plat.c
> > > > > > > > Traceback (most recent call last):
> > > > > > > >   File "./tools/dtoc/dtoc", line 115, in 
> > > > > > > > args.phase, instantiate=args.instantiate)
> > > > > > > >   File 
> > > > > > > > "/hom

Re: Debugging dtoc?

[Simon Glass]

Hi Tom,

On Fri, 30 Jul 2021 at 09:10, Tom Rini  wrote:
>
> On Fri, Jul 30, 2021 at 08:44:29AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 29 Jul 2021 at 07:22, Tom Rini  wrote:
> > >
> > > On Wed, Jul 28, 2021 at 07:27:08PM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, 28 Jul 2021 at 17:28, Simon Glass  wrote:
> > > > >
> > > > > Hi again,
> > > > >
> > > > > On Mon, 26 Jul 2021 at 08:06, Simon Glass  wrote:
> > > > > >
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Sun, 25 Jul 2021 at 15:10, Tom Rini  wrote:
> > > > > > >
> > > > > > > So, I'm trying to fix the problem on am335x_evm (and some family
> > > > > > > configs) with needing SPL_OF_CONTROL enabled.  This is mostly 
> > > > > > > fine just
> > > > > > > enabling the option, except on am335x_evm itself, which is the
> > > > > > > kitchen-sink config and overflows memory.  I've gone with 
> > > > > > > switching to
> > > > > > > SPL_OF_PLATDATA there as am335x in general has all of the 
> > > > > > > U_BOOT_DRVINFO
> > > > > > > entries it needs I believe.  But, with the following patch:
> > > > > > >
> > > > > > > diff --git a/arch/arm/dts/am335x-evm-u-boot.dtsi 
> > > > > > > b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > > > index 4cf5f9928d58..514f682cac99 100644
> > > > > > > --- a/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > > > +++ b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > > > @@ -8,6 +8,7 @@
> > > > > > >  &l4_per {
> > > > > > >
> > > > > > > segment@30 {
> > > > > > > +   u-boot,dm-pre-reloc;
> > > > > > >
> > > > > > > target-module@e000 {
> > > > > > > u-boot,dm-pre-reloc;
> > > > > > > diff --git a/configs/am335x_boneblack_vboot_defconfig 
> > > > > > > b/configs/am335x_boneblack_vboot_defconfig
> > > > > > > index a0baeec79edd..ffeefd1a0087 100644
> > > > > > > --- a/configs/am335x_boneblack_vboot_defconfig
> > > > > > > +++ b/configs/am335x_boneblack_vboot_defconfig
> > > > > > > @@ -31,6 +31,7 @@ CONFIG_CMD_SPL=y
> > > > > > >  # CONFIG_CMD_SETEXPR is not set
> > > > > > >  CONFIG_BOOTP_DNS2=y
> > > > > > >  CONFIG_OF_CONTROL=y
> > > > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > > > >  CONFIG_ENV_OVERWRITE=y
> > > > > > >  CONFIG_ENV_IS_IN_MMC=y
> > > > > > >  CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> > > > > > > diff --git a/configs/am335x_evm_defconfig 
> > > > > > > b/configs/am335x_evm_defconfig
> > > > > > > index a33efff42a74..f35b2a02f56b 100644
> > > > > > > --- a/configs/am335x_evm_defconfig
> > > > > > > +++ b/configs/am335x_evm_defconfig
> > > > > > > @@ -37,13 +37,16 @@ CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
> > > > > > >  
> > > > > > > CONFIG_MTDPARTS_DEFAULT="mtdparts=nand.0:128k(NAND.SPL),128k(NAND.SPL.backup1),128k(NAND.SPL.backup2),128k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),1m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)"
> > > > > > >  # CONFIG_SPL_EFI_PARTITION is not set
> > > > > > >  CONFIG_OF_CONTROL=y
> > > > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > > > >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack 
> > > > > > > am335x-evmsk am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> > > > > > > +CONFIG_SPL_OF_PLATDATA=y
> > > > > > >  CONFIG_ENV_OVERWRITE=y
> > > > > > >  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > > > > > >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> > > > > > >  CONFIG_SPL_ENV_IS_NOWHERE=y
> > > > > > >  CONFIG_VERSION_VARIABLE=y
> > > > > > >  CONFIG_BOOTP_SEND_HOSTNAME=y
> > > > > > > +# CONFIG_SPL_SIMPLE_BUS is not set
> > > > > > >  CONFIG_BOOTCOUNT_LIMIT=y
> > > > > > >  CONFIG_CLK=y
> > > > > > >  CONFIG_CLK_CDCE9XX=y
> > > > > > > diff --git a/configs/am335x_evm_spiboot_defconfig 
> > > > > > > b/configs/am335x_evm_spiboot_defconfig
> > > > > > > index 8f0c330674a9..4a2a56a9af9e 100644
> > > > > > > --- a/configs/am335x_evm_spiboot_defconfig
> > > > > > > +++ b/configs/am335x_evm_spiboot_defconfig
> > > > > > > @@ -32,6 +32,7 @@ CONFIG_BOOTP_DNS2=y
> > > > > > >  CONFIG_CMD_MTDPARTS=y
> > > > > > >  # CONFIG_SPL_EFI_PARTITION is not set
> > > > > > >  CONFIG_OF_CONTROL=y
> > > > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > > > >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack 
> > > > > > > am335x-evmsk am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> > > > > > >  CONFIG_ENV_OVERWRITE=y
> > > > > > >  # CONFIG_ENV_IS_IN_FAT is not set
> > > > > > >
> > > > > > > I get the following failure and I don't see how to debug this:
> > > > > > >   DTOCspl/dts/dt-plat.c
> > > > > > > Traceback (most recent call last):
> > > > > > >   File "./tools/dtoc/dtoc", line 115, in 
> > > > > > > args.phase, instantiate=args.instantiate)
> > > > > > >   File 
> > > > > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py",
> > > > > > >  line 1223, in run_steps
> > > > > > > outfile.method(plat)
> > > > > > >   File 
> > > > > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py",
> > > > > > >  line 10

[PATCH] lib: -Wformat-truncation in rsa_engine_get_priv_key

[Heinrich Schuchardt]

With glibc 2.33 (Ubuntu package glibc6 2.33-0ubuntu9) building
sifive_unmatched_defconfig results in:

In file included from /usr/include/stdio.h:866,
 from ././include/compiler.h:26,
 from :
In function ‘snprintf’,
inlined from ‘rsa_engine_get_priv_key’ at ./tools/../^:273:4:
/usr/include/riscv64-linux-gnu/bits/stdio2.h:71:10: warning:
‘%s’ directive argument is null [-Wformat-truncation=]
   71 |   return __builtin___snprintf_chk (__s, __n, 
__USE_FORTIFY_LEVEL - 1,
  | 
^~~~

   72 |__glibc_objsize (__s), __fmt,
  |~
   73 |__va_arg_pack ());
  |~

Avoid passing a NULL string.

Signed-off-by: Heinrich Schuchardt 
---
 lib/rsa/rsa-sign.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index 085dc89bf7..c7ae7a0dbc 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -271,8 +271,7 @@ static int rsa_engine_get_priv_key(const char 
*keydir, const char *name,

 keydir, name);
else if (keydir)
snprintf(key_id, sizeof(key_id),
-"%s",
-name);
+"%s", name ? name : "");
else if (keyfile)
snprintf(key_id, sizeof(key_id), "%s", keyfile);
else
--
2.31.1

Re: Debugging dtoc?

[Tom Rini]

On Fri, Jul 30, 2021 at 08:44:29AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 29 Jul 2021 at 07:22, Tom Rini  wrote:
> >
> > On Wed, Jul 28, 2021 at 07:27:08PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 28 Jul 2021 at 17:28, Simon Glass  wrote:
> > > >
> > > > Hi again,
> > > >
> > > > On Mon, 26 Jul 2021 at 08:06, Simon Glass  wrote:
> > > > >
> > > > > Hi Tom,
> > > > >
> > > > > On Sun, 25 Jul 2021 at 15:10, Tom Rini  wrote:
> > > > > >
> > > > > > So, I'm trying to fix the problem on am335x_evm (and some family
> > > > > > configs) with needing SPL_OF_CONTROL enabled.  This is mostly fine 
> > > > > > just
> > > > > > enabling the option, except on am335x_evm itself, which is the
> > > > > > kitchen-sink config and overflows memory.  I've gone with switching 
> > > > > > to
> > > > > > SPL_OF_PLATDATA there as am335x in general has all of the 
> > > > > > U_BOOT_DRVINFO
> > > > > > entries it needs I believe.  But, with the following patch:
> > > > > >
> > > > > > diff --git a/arch/arm/dts/am335x-evm-u-boot.dtsi 
> > > > > > b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > > index 4cf5f9928d58..514f682cac99 100644
> > > > > > --- a/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > > +++ b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > > @@ -8,6 +8,7 @@
> > > > > >  &l4_per {
> > > > > >
> > > > > > segment@30 {
> > > > > > +   u-boot,dm-pre-reloc;
> > > > > >
> > > > > > target-module@e000 {
> > > > > > u-boot,dm-pre-reloc;
> > > > > > diff --git a/configs/am335x_boneblack_vboot_defconfig 
> > > > > > b/configs/am335x_boneblack_vboot_defconfig
> > > > > > index a0baeec79edd..ffeefd1a0087 100644
> > > > > > --- a/configs/am335x_boneblack_vboot_defconfig
> > > > > > +++ b/configs/am335x_boneblack_vboot_defconfig
> > > > > > @@ -31,6 +31,7 @@ CONFIG_CMD_SPL=y
> > > > > >  # CONFIG_CMD_SETEXPR is not set
> > > > > >  CONFIG_BOOTP_DNS2=y
> > > > > >  CONFIG_OF_CONTROL=y
> > > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > > >  CONFIG_ENV_OVERWRITE=y
> > > > > >  CONFIG_ENV_IS_IN_MMC=y
> > > > > >  CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> > > > > > diff --git a/configs/am335x_evm_defconfig 
> > > > > > b/configs/am335x_evm_defconfig
> > > > > > index a33efff42a74..f35b2a02f56b 100644
> > > > > > --- a/configs/am335x_evm_defconfig
> > > > > > +++ b/configs/am335x_evm_defconfig
> > > > > > @@ -37,13 +37,16 @@ CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
> > > > > >  
> > > > > > CONFIG_MTDPARTS_DEFAULT="mtdparts=nand.0:128k(NAND.SPL),128k(NAND.SPL.backup1),128k(NAND.SPL.backup2),128k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),1m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)"
> > > > > >  # CONFIG_SPL_EFI_PARTITION is not set
> > > > > >  CONFIG_OF_CONTROL=y
> > > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > > >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack 
> > > > > > am335x-evmsk am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> > > > > > +CONFIG_SPL_OF_PLATDATA=y
> > > > > >  CONFIG_ENV_OVERWRITE=y
> > > > > >  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > > > > >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> > > > > >  CONFIG_SPL_ENV_IS_NOWHERE=y
> > > > > >  CONFIG_VERSION_VARIABLE=y
> > > > > >  CONFIG_BOOTP_SEND_HOSTNAME=y
> > > > > > +# CONFIG_SPL_SIMPLE_BUS is not set
> > > > > >  CONFIG_BOOTCOUNT_LIMIT=y
> > > > > >  CONFIG_CLK=y
> > > > > >  CONFIG_CLK_CDCE9XX=y
> > > > > > diff --git a/configs/am335x_evm_spiboot_defconfig 
> > > > > > b/configs/am335x_evm_spiboot_defconfig
> > > > > > index 8f0c330674a9..4a2a56a9af9e 100644
> > > > > > --- a/configs/am335x_evm_spiboot_defconfig
> > > > > > +++ b/configs/am335x_evm_spiboot_defconfig
> > > > > > @@ -32,6 +32,7 @@ CONFIG_BOOTP_DNS2=y
> > > > > >  CONFIG_CMD_MTDPARTS=y
> > > > > >  # CONFIG_SPL_EFI_PARTITION is not set
> > > > > >  CONFIG_OF_CONTROL=y
> > > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > > >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack 
> > > > > > am335x-evmsk am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> > > > > >  CONFIG_ENV_OVERWRITE=y
> > > > > >  # CONFIG_ENV_IS_IN_FAT is not set
> > > > > >
> > > > > > I get the following failure and I don't see how to debug this:
> > > > > >   DTOCspl/dts/dt-plat.c
> > > > > > Traceback (most recent call last):
> > > > > >   File "./tools/dtoc/dtoc", line 115, in 
> > > > > > args.phase, instantiate=args.instantiate)
> > > > > >   File 
> > > > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py",
> > > > > >  line 1223, in run_steps
> > > > > > outfile.method(plat)
> > > > > >   File 
> > > > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py",
> > > > > >  line 1081, in generate_plat
> > > > > > self.output_node_plat(node)
> > > > > >   File 
> > > > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py",
> > > > > >  line 1023, in output_node_plat
> > > > > > self._output_values(node)
> > > > > >   F

Re: Debugging dtoc?

[Simon Glass]

Hi Tom,

On Thu, 29 Jul 2021 at 07:22, Tom Rini  wrote:
>
> On Wed, Jul 28, 2021 at 07:27:08PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 28 Jul 2021 at 17:28, Simon Glass  wrote:
> > >
> > > Hi again,
> > >
> > > On Mon, 26 Jul 2021 at 08:06, Simon Glass  wrote:
> > > >
> > > > Hi Tom,
> > > >
> > > > On Sun, 25 Jul 2021 at 15:10, Tom Rini  wrote:
> > > > >
> > > > > So, I'm trying to fix the problem on am335x_evm (and some family
> > > > > configs) with needing SPL_OF_CONTROL enabled.  This is mostly fine 
> > > > > just
> > > > > enabling the option, except on am335x_evm itself, which is the
> > > > > kitchen-sink config and overflows memory.  I've gone with switching to
> > > > > SPL_OF_PLATDATA there as am335x in general has all of the 
> > > > > U_BOOT_DRVINFO
> > > > > entries it needs I believe.  But, with the following patch:
> > > > >
> > > > > diff --git a/arch/arm/dts/am335x-evm-u-boot.dtsi 
> > > > > b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > index 4cf5f9928d58..514f682cac99 100644
> > > > > --- a/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > +++ b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > > @@ -8,6 +8,7 @@
> > > > >  &l4_per {
> > > > >
> > > > > segment@30 {
> > > > > +   u-boot,dm-pre-reloc;
> > > > >
> > > > > target-module@e000 {
> > > > > u-boot,dm-pre-reloc;
> > > > > diff --git a/configs/am335x_boneblack_vboot_defconfig 
> > > > > b/configs/am335x_boneblack_vboot_defconfig
> > > > > index a0baeec79edd..ffeefd1a0087 100644
> > > > > --- a/configs/am335x_boneblack_vboot_defconfig
> > > > > +++ b/configs/am335x_boneblack_vboot_defconfig
> > > > > @@ -31,6 +31,7 @@ CONFIG_CMD_SPL=y
> > > > >  # CONFIG_CMD_SETEXPR is not set
> > > > >  CONFIG_BOOTP_DNS2=y
> > > > >  CONFIG_OF_CONTROL=y
> > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > >  CONFIG_ENV_OVERWRITE=y
> > > > >  CONFIG_ENV_IS_IN_MMC=y
> > > > >  CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> > > > > diff --git a/configs/am335x_evm_defconfig 
> > > > > b/configs/am335x_evm_defconfig
> > > > > index a33efff42a74..f35b2a02f56b 100644
> > > > > --- a/configs/am335x_evm_defconfig
> > > > > +++ b/configs/am335x_evm_defconfig
> > > > > @@ -37,13 +37,16 @@ CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
> > > > >  
> > > > > CONFIG_MTDPARTS_DEFAULT="mtdparts=nand.0:128k(NAND.SPL),128k(NAND.SPL.backup1),128k(NAND.SPL.backup2),128k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),1m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)"
> > > > >  # CONFIG_SPL_EFI_PARTITION is not set
> > > > >  CONFIG_OF_CONTROL=y
> > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
> > > > > am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> > > > > +CONFIG_SPL_OF_PLATDATA=y
> > > > >  CONFIG_ENV_OVERWRITE=y
> > > > >  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > > > >  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> > > > >  CONFIG_SPL_ENV_IS_NOWHERE=y
> > > > >  CONFIG_VERSION_VARIABLE=y
> > > > >  CONFIG_BOOTP_SEND_HOSTNAME=y
> > > > > +# CONFIG_SPL_SIMPLE_BUS is not set
> > > > >  CONFIG_BOOTCOUNT_LIMIT=y
> > > > >  CONFIG_CLK=y
> > > > >  CONFIG_CLK_CDCE9XX=y
> > > > > diff --git a/configs/am335x_evm_spiboot_defconfig 
> > > > > b/configs/am335x_evm_spiboot_defconfig
> > > > > index 8f0c330674a9..4a2a56a9af9e 100644
> > > > > --- a/configs/am335x_evm_spiboot_defconfig
> > > > > +++ b/configs/am335x_evm_spiboot_defconfig
> > > > > @@ -32,6 +32,7 @@ CONFIG_BOOTP_DNS2=y
> > > > >  CONFIG_CMD_MTDPARTS=y
> > > > >  # CONFIG_SPL_EFI_PARTITION is not set
> > > > >  CONFIG_OF_CONTROL=y
> > > > > +CONFIG_SPL_OF_CONTROL=y
> > > > >  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
> > > > > am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> > > > >  CONFIG_ENV_OVERWRITE=y
> > > > >  # CONFIG_ENV_IS_IN_FAT is not set
> > > > >
> > > > > I get the following failure and I don't see how to debug this:
> > > > >   DTOCspl/dts/dt-plat.c
> > > > > Traceback (most recent call last):
> > > > >   File "./tools/dtoc/dtoc", line 115, in 
> > > > > args.phase, instantiate=args.instantiate)
> > > > >   File 
> > > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", 
> > > > > line 1223, in run_steps
> > > > > outfile.method(plat)
> > > > >   File 
> > > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", 
> > > > > line 1081, in generate_plat
> > > > > self.output_node_plat(node)
> > > > >   File 
> > > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", 
> > > > > line 1023, in output_node_plat
> > > > > self._output_values(node)
> > > > >   File 
> > > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", 
> > > > > line 812, in _output_values
> > > > > self._output_prop(node, node.props[pname])
> > > > >   File 
> > > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py", 
> > > > > line

Re: [PATCH] fastboot: fix partition name truncation in environment lookup

[Sean Anderson]

On 7/30/21 8:23 AM, Matthias Schiffer wrote:

strlcat() need to be passed the full buffer length. The incorrect call
caused truncation of partition names for fastboot_raw_partition_... and
fastboot_partition_alias_... env lookup to much less than PART_NAME_LEN.

Fixes: 69a752983171 ("fastboot: Fix possible buffer overrun")
Signed-off-by: Matthias Schiffer 
---
  drivers/fastboot/fb_mmc.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index 2f3837e559..33fd6c21af 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -40,7 +40,7 @@ static int raw_part_get_info_by_name(struct blk_desc 
*dev_desc,
  
  	/* check for raw partition descriptor */

strcpy(env_desc_name, "fastboot_raw_partition_");
-   strlcat(env_desc_name, name, PART_NAME_LEN);
+   strlcat(env_desc_name, name, sizeof(env_desc_name));
raw_part_desc = strdup(env_get(env_desc_name));
if (raw_part_desc == NULL)
return -ENODEV;
@@ -114,7 +114,7 @@ static int part_get_info_by_name_or_alias(struct blk_desc 
**dev_desc,
  
  		/* check for alias */

strcpy(env_alias_name, "fastboot_partition_alias_");
-   strlcat(env_alias_name, name, PART_NAME_LEN);
+   strlcat(env_alias_name, name, sizeof(env_alias_name));
aliased_part_name = env_get(env_alias_name);
if (aliased_part_name != NULL)
ret = do_get_part_info(dev_desc, aliased_part_name,



Reviewed-by: Sean Anderson 

Re: [PATCH v2 0/5] meson64_android: use BCB for reboot reason

[Neil Armstrong]

On 30/07/2021 14:28, Mattijs Korpershoek wrote:
> The SEI-610 and SEI-510 boards are well supported in the
> Android Open Source project via the yukawa [1] platform.
> 
> Their U-Boot version, despite being public [2] is not in mainline.
> 
> Android has multiple OSes it can boot into:
> * Main android
> * Recovery OS
> * Fastbootd (recovery OS with fastboot mode)
> * Bootloader (U-Boot) with fastboot mode
> 
> The decision of which OS to boot into is taken by the bootloader based on
> the "reboot reason".
> 
> For amlogic boards, we pass the reboot reason via a custom smc call.
> This support is limited: we don't r
> 
> These series reworks the reboot reason handling to use the BCB, which
> is the standard Android way.
> 
> [1] https://android.googlesource.com/device/amlogic/yukawa
> [2] 
> https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ
> 
> Changes in v2:
> * re-ordered commits
> * added Neil's Acked-by
> 
> Mattijs Korpershoek (5):
>   configs: meson64_android: use BCB for reboot to bootloader
>   configs: meson64_android: implement recovery boot via BCB
>   configs: meson64_android: reboot to fastbootd from bootloader
>   configs: sei610/sei510: set CONFIG_CMD_BCB=y
>   Revert "ARM: meson: Add support for fastboot_set_reboot_flag()"
> 
>  arch/arm/mach-meson/board-common.c | 34 -
>  configs/sei510_defconfig   |  1 +
>  configs/sei610_defconfig   |  1 +
>  include/configs/meson64_android.h  | 60 --
>  4 files changed, 42 insertions(+), 54 deletions(-)
> 

Applied to u-boot-amlogic

Thanks,
Neil

Re: [PATCH 0/5] meson64_android: use BCB for reboot reason

[Mattijs Korpershoek]

Hi Neil,

Neil Armstrong  writes:

> On 30/07/2021 10:55, Mattijs Korpershoek wrote:
>> The SEI-610 and SEI-510 boards are well supported in the
>> Android Open Source project via the yukawa [1] platform.
>> 
>> Their U-Boot version, despite being public [2] is not in mainline.
>> 
>> Android has multiple OSes it can boot into:
>> * Main android
>> * Recovery OS
>> * Fastbootd (recovery OS with fastboot mode)
>> * Bootloader (U-Boot) with fastboot mode
>> 
>> The decision of which OS to boot into is taken by the bootloader based on
>> the "reboot reason".
>> 
>> For amlogic boards, we pass the reboot reason via a custom smc call.
>> This support is limited: we don't r
>> 
>> These series reworks the reboot reason handling to use the BCB, which
>> is the standard Android way.
>> 
>> [1] https://android.googlesource.com/device/amlogic/yukawa
>> [2] 
>> https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ
>> 
>> Mattijs Korpershoek (5):
>>   Revert "ARM: meson: Add support for fastboot_set_reboot_flag()"
>>   configs: meson64_android: use BCB for reboot to bootloader
>>   configs: meson64_android: implement recovery boot via BCB
>>   configs: meson64_android: reboot to fastbootd from bootloader
>>   configs: sei610/sei510: set CONFIG_CMD_BCB=y
>> 
>>  arch/arm/mach-meson/board-common.c | 34 -
>>  configs/sei510_defconfig   |  1 +
>>  configs/sei610_defconfig   |  1 +
>>  include/configs/meson64_android.h  | 60 --
>>  4 files changed, 42 insertions(+), 54 deletions(-)
>> 
>
> Looks fine, but I'll move the patch 1 as last.
Thanks for your review.
>
> Can you re-post ?
>
> Please add:
> Acked-by: Neil Armstrong 
>
> to all patches if you repost.
I've reposted a v2 with your ack.

Mattijs
>
> Neil

[PATCH v3 7/7] mmc: zynq_sdhci: Use set_control_reg from sdhci.c

[Ashok Reddy Soma]

Since set_control_reg is available in sdhci.c, use it and remove
arasan_sdhci_set_control_reg().

Signed-off-by: Ashok Reddy Soma 
Reviewed-by: Jaehoon Chung 
---

(no changes since v1)

 drivers/mmc/zynq_sdhci.c | 21 +
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 89776f48eb..73bb3abbc2 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -690,29 +690,10 @@ static void arasan_dt_parse_clk_phases(struct udevice 
*dev)
 "clk-phase-mmc-hs400");
 }
 
-static void arasan_sdhci_set_control_reg(struct sdhci_host *host)
-{
-   struct mmc *mmc = (struct mmc *)host->mmc;
-   u32 reg;
-
-   if (!IS_SD(mmc))
-   return;
-
-   if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180) {
-   reg = sdhci_readw(host, SDHCI_HOST_CONTROL2);
-   reg |= SDHCI_CTRL_VDD_180;
-   sdhci_writew(host, reg, SDHCI_HOST_CONTROL2);
-   }
-
-   if (mmc->selected_mode > SD_HS &&
-   mmc->selected_mode <= MMC_HS_200)
-   sdhci_set_uhs_timing(host);
-}
-
 static const struct sdhci_ops arasan_ops = {
.platform_execute_tuning= &arasan_sdhci_execute_tuning,
.set_delay = &arasan_sdhci_set_tapdelay,
-   .set_control_reg = &arasan_sdhci_set_control_reg,
+   .set_control_reg = &sdhci_set_control_reg,
 };
 #endif
 
-- 
2.17.1

[PATCH v3 6/7] mmc: zynq_sdhci: Wait till sd card detect state is stable

[Ashok Reddy Soma]

From: T Karthik Reddy 

As per SD spec when SD host controller is reset, it takes 1000msec
to detect the card state. In case, if we enable the sd bus voltage &
card detect state is not stable, then host controller will disable
the sd bus voltage.

In case of warm/subsystem reboot, due to unstable card detect state
host controller is disabling the sd bus voltage to sd card causing
sd card timeout error. So we wait for a maximum of 1000msec to get
the card detect state stable before we enable the sd bus voltage.

This current fix is workaround for now, this needs to be analysed
further. Zynqmp platform should behave the same as Versal, but we
did not encounter this issue as of now. So we are fixing it for
Versal only.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Ashok Reddy Soma 
---

(no changes since v2)

Changes in v2:
 - Changed return error from -EIO to -ETIMEDOUT in arasan_sdhci_probe()
   in card detect state stable workaround

 drivers/mmc/zynq_sdhci.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 9a1693940a..89776f48eb 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -776,6 +776,23 @@ static int arasan_sdhci_probe(struct udevice *dev)
return ret;
upriv->mmc = host->mmc;
 
+   /*
+* Wait for 1000msec till the card detect state gets stable
+* else host controller will set sd power bus voltage to 0.
+*/
+   if (IS_ENABLED(CONFIG_ARCH_VERSAL)) {
+   u32 timeout = 1000;
+
+   while (((sdhci_readl(host, SDHCI_PRESENT_STATE) &
+SDHCI_CARD_STATE_STABLE) == 0) && timeout--) {
+   mdelay(1);
+   }
+   if (!timeout) {
+   dev_err(dev, "Sdhci card detect state not stable\n");
+   return -ETIMEDOUT;
+   }
+   }
+
return sdhci_probe(dev);
 }
 
-- 
2.17.1

[PATCH v3 5/7] mmc: zynq_sdhci: Move setting tapdelay code to driver

[Ashok Reddy Soma]

Move tapdelay function calls to zynq_sdhci.c and make them static
inline. zynqmp_tap_delay.h has function prototypes for the functions
defined in tap_delays.c, which will not be needed anymore.

Remove tap_delays.c and zynqmp_tap_delay.h files.

Signed-off-by: Ashok Reddy Soma 
---

Changes in v3:
 - Make the changes on top of patch 4/7 to move the code to zynq_sdhci.c

 board/xilinx/zynqmp/Makefile |   2 -
 board/xilinx/zynqmp/tap_delays.c | 115 ---
 drivers/mmc/zynq_sdhci.c | 108 -
 include/zynqmp_tap_delay.h   |  34 -
 4 files changed, 107 insertions(+), 152 deletions(-)
 delete mode 100644 board/xilinx/zynqmp/tap_delays.c
 delete mode 100644 include/zynqmp_tap_delay.h

diff --git a/board/xilinx/zynqmp/Makefile b/board/xilinx/zynqmp/Makefile
index 7d8277ca40..a914028753 100644
--- a/board/xilinx/zynqmp/Makefile
+++ b/board/xilinx/zynqmp/Makefile
@@ -44,8 +44,6 @@ $(obj)/pm_cfg_obj.o: $(shell cd $(srctree); readlink -f 
$(CONFIG_ZYNQMP_SPL_PM_C
 endif
 endif
 
-obj-$(CONFIG_MMC_SDHCI_ZYNQ) += tap_delays.o
-
 ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_CMD_ZYNQMP) += cmds.o
 endif
diff --git a/board/xilinx/zynqmp/tap_delays.c b/board/xilinx/zynqmp/tap_delays.c
deleted file mode 100644
index 514f86a29a..00
--- a/board/xilinx/zynqmp/tap_delays.c
+++ /dev/null
@@ -1,115 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Xilinx ZynqMP SoC Tap Delay Programming
- *
- * Copyright (C) 2018 Xilinx, Inc.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define SD_DLL_CTRL0xFF180358
-#define SD_ITAP_DLY0xFF180314
-#define SD_OTAP_DLY0xFF180318
-#define SD0_DLL_RSTBIT(2)
-#define SD1_DLL_RSTBIT(18)
-#define SD0_ITAPCHGWIN BIT(9)
-#define SD1_ITAPCHGWIN BIT(25)
-#define SD0_ITAPDLYENA BIT(8)
-#define SD1_ITAPDLYENA BIT(24)
-#define SD0_ITAPDLYSEL_MASKGENMASK(7, 0)
-#define SD1_ITAPDLYSEL_MASKGENMASK(23, 16)
-#define SD0_OTAPDLYSEL_MASKGENMASK(5, 0)
-#define SD1_OTAPDLYSEL_MASKGENMASK(21, 16)
-
-int zynqmp_dll_reset(u8 node_id, u32 type)
-{
-   if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
-   if (node_id == NODE_SD_0)
-   return zynqmp_mmio_write(SD_DLL_CTRL, SD0_DLL_RST,
-type == PM_DLL_RESET_ASSERT ?
-SD0_DLL_RST : 0);
-
-   return zynqmp_mmio_write(SD_DLL_CTRL, SD1_DLL_RST,
-type == PM_DLL_RESET_ASSERT ?
-SD1_DLL_RST : 0);
-   } else {
-   return xilinx_pm_request(PM_IOCTL, (u32)node_id,
-IOCTL_SD_DLL_RESET, type, 0, NULL);
-   }
-}
-
-int arasan_zynqmp_set_in_tapdelay(u8 node_id, u32 itap_delay)
-{
-   int ret;
-
-   if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
-   if (node_id == NODE_SD_0) {
-   ret = zynqmp_mmio_write(SD_ITAP_DLY, SD0_ITAPCHGWIN,
-   SD0_ITAPCHGWIN);
-   if (ret)
-   return ret;
-
-   ret = zynqmp_mmio_write(SD_ITAP_DLY, SD0_ITAPDLYENA,
-   SD0_ITAPDLYENA);
-   if (ret)
-   return ret;
-
-   ret = zynqmp_mmio_write(SD_ITAP_DLY,
-   SD0_ITAPDLYSEL_MASK,
-   itap_delay);
-   if (ret)
-   return ret;
-
-   ret = zynqmp_mmio_write(SD_ITAP_DLY, SD0_ITAPCHGWIN, 0);
-   if (ret)
-   return ret;
-   }
-   ret = zynqmp_mmio_write(SD_ITAP_DLY, SD1_ITAPCHGWIN,
-   SD1_ITAPCHGWIN);
-   if (ret)
-   return ret;
-
-   ret = zynqmp_mmio_write(SD_ITAP_DLY, SD1_ITAPDLYENA,
-   SD1_ITAPDLYENA);
-   if (ret)
-   return ret;
-
-   ret = zynqmp_mmio_write(SD_ITAP_DLY, SD1_ITAPDLYSEL_MASK,
-   (itap_delay << 16));
-   if (ret)
-   return ret;
-
-   ret = zynqmp_mmio_write(SD_ITAP_DLY, SD1_ITAPCHGWIN, 0);
-   if (ret)
-   return ret;
-   } else {
-   return xilinx_pm_request(PM_IOCTL, (u32)node_id,
-IOCTL_SET_SD_TAPDELAY,
-PM_TAPDELAY_INPUT, ita

[PATCH v3 4/7] mmc: zynq_sdhci: Add xilinx_pm_request() method to set tapdelays

[Ashok Reddy Soma]

Currently xilinx sdhci driver is using zynqmp_mmio_write() to set
tapdelay values and DLL resets. Continue to use this for SPL and mini
U-Boot where U-Boot will be executed at EL3 level.

Use firmware call xilinx_pm_request() using appropriate arguments to
set input/output tapdelays and also for DLL resets in regular flow(EL2).

Host driver should explicitly request DLL reset before ITAP (assert DLL)
and after OTAP (release DLL) to avoid issues in some cases. Also handle
error return where possible.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Ashok Reddy Soma 
---

Changes in v3:
 - As we are seeing issues with SPL flow, keep zynqmp_mmio_write method
   to set tapdelay's and DLL resets. Add xilinx_pm_request on top of it
   for regular flow.
 - Changed the patch title to reflect these changes

Changes in v2:
 - Added comment for why 1ms delay is needed between DLL assert and
 release
 - Remove mmc->dev->seq_ and use priv->deviceid instead

 board/xilinx/zynqmp/tap_delays.c | 148 +--
 drivers/mmc/zynq_sdhci.c |  73 ---
 include/zynqmp_tap_delay.h   |  25 --
 3 files changed, 159 insertions(+), 87 deletions(-)

diff --git a/board/xilinx/zynqmp/tap_delays.c b/board/xilinx/zynqmp/tap_delays.c
index d16bbb8eff..514f86a29a 100644
--- a/board/xilinx/zynqmp/tap_delays.c
+++ b/board/xilinx/zynqmp/tap_delays.c
@@ -8,94 +8,108 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 #define SD_DLL_CTRL0xFF180358
 #define SD_ITAP_DLY0xFF180314
 #define SD_OTAP_DLY0xFF180318
-#define SD0_DLL_RST_MASK   0x0004
-#define SD0_DLL_RST0x0004
-#define SD1_DLL_RST_MASK   0x0004
-#define SD1_DLL_RST0x0004
-#define SD0_ITAPCHGWIN_MASK0x0200
-#define SD0_ITAPCHGWIN 0x0200
-#define SD1_ITAPCHGWIN_MASK0x0200
-#define SD1_ITAPCHGWIN 0x0200
-#define SD0_ITAPDLYENA_MASK0x0100
-#define SD0_ITAPDLYENA 0x0100
-#define SD1_ITAPDLYENA_MASK0x0100
-#define SD1_ITAPDLYENA 0x0100
-#define SD0_ITAPDLYSEL_MASK0x00FF
-#define SD1_ITAPDLYSEL_MASK0x00FF
-#define SD0_OTAPDLYSEL_MASK0x003F
-#define SD1_OTAPDLYSEL_MASK0x003F
+#define SD0_DLL_RSTBIT(2)
+#define SD1_DLL_RSTBIT(18)
+#define SD0_ITAPCHGWIN BIT(9)
+#define SD1_ITAPCHGWIN BIT(25)
+#define SD0_ITAPDLYENA BIT(8)
+#define SD1_ITAPDLYENA BIT(24)
+#define SD0_ITAPDLYSEL_MASKGENMASK(7, 0)
+#define SD1_ITAPDLYSEL_MASKGENMASK(23, 16)
+#define SD0_OTAPDLYSEL_MASKGENMASK(5, 0)
+#define SD1_OTAPDLYSEL_MASKGENMASK(21, 16)
 
-void zynqmp_dll_reset(u8 deviceid)
+int zynqmp_dll_reset(u8 node_id, u32 type)
 {
-   /* Issue DLL Reset */
-   if (deviceid == 0)
-   zynqmp_mmio_write(SD_DLL_CTRL, SD0_DLL_RST_MASK,
- SD0_DLL_RST);
-   else
-   zynqmp_mmio_write(SD_DLL_CTRL, SD1_DLL_RST_MASK,
- SD1_DLL_RST);
+   if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
+   if (node_id == NODE_SD_0)
+   return zynqmp_mmio_write(SD_DLL_CTRL, SD0_DLL_RST,
+type == PM_DLL_RESET_ASSERT ?
+SD0_DLL_RST : 0);
 
-   mdelay(1);
-
-   /* Release DLL Reset */
-   if (deviceid == 0)
-   zynqmp_mmio_write(SD_DLL_CTRL, SD0_DLL_RST_MASK, 0x0);
-   else
-   zynqmp_mmio_write(SD_DLL_CTRL, SD1_DLL_RST_MASK, 0x0);
+   return zynqmp_mmio_write(SD_DLL_CTRL, SD1_DLL_RST,
+type == PM_DLL_RESET_ASSERT ?
+SD1_DLL_RST : 0);
+   } else {
+   return xilinx_pm_request(PM_IOCTL, (u32)node_id,
+IOCTL_SD_DLL_RESET, type, 0, NULL);
+   }
 }
 
-void arasan_zynqmp_set_in_tapdelay(u8 deviceid, u32 itap_delay)
+int arasan_zynqmp_set_in_tapdelay(u8 node_id, u32 itap_delay)
 {
-   if (deviceid == 0) {
-   zynqmp_mmio_write(SD_DLL_CTRL, SD0_DLL_RST_MASK, SD0_DLL_RST);
+   int ret;
 
-   /* Program ITAP delay */
-   zynqmp_mmio_write(SD_ITAP_DLY, SD0_ITAPCHGWIN_MASK,
- SD0_ITAPCHGWIN);
-   zynqmp_mmio_write(SD_ITAP_DLY, SD0_ITAPDLYENA_MASK,
- SD0_ITAPDLYENA);
-   zynqmp_mmio_write(SD_ITAP_DLY, SD0_ITAPDLYSEL_MASK, itap_delay);
-   zynqmp_mmio_write(SD_ITAP_DLY, SD0_ITAPCHGWIN_MASK, 0x0);
+   if (IS_ENABLED(CONFIG_SPL_BU

[PATCH v3 1/7] mmc: zynq_sdhci: Return errors from arasan_sdhci_set_tapdelay

[Ashok Reddy Soma]

Change return type of arasan_sdhci_set_tapdelay() to int, to facilitate
returning errors. Get return values from input and output set clock phase
functions inside arasan_sdhci_set_tapdelay() and return those errors.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Ashok Reddy Soma 
---

Changes in v3:
 - Added new line after return at two places

Changes in v2:
 - Split patch 1/7 to two patches, one for zynq_sdhci and other one
   for sdhci

 drivers/mmc/zynq_sdhci.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index ba87ee8dd5..1ecc2ec669 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -422,7 +422,7 @@ static int sdhci_versal_sampleclk_set_phase(struct 
sdhci_host *host,
return 0;
 }
 
-static void arasan_sdhci_set_tapdelay(struct sdhci_host *host)
+static int arasan_sdhci_set_tapdelay(struct sdhci_host *host)
 {
struct arasan_sdhci_priv *priv = dev_get_priv(host->mmc->dev);
struct arasan_sdhci_clk_data *clk_data = &priv->clk_data;
@@ -431,18 +431,31 @@ static void arasan_sdhci_set_tapdelay(struct sdhci_host 
*host)
u8 timing = mode2timing[mmc->selected_mode];
u32 iclk_phase = clk_data->clk_phase_in[timing];
u32 oclk_phase = clk_data->clk_phase_out[timing];
+   int ret;
 
dev_dbg(dev, "%s, host:%s, mode:%d\n", __func__, host->name, timing);
 
if (IS_ENABLED(CONFIG_ARCH_ZYNQMP) &&
device_is_compatible(dev, "xlnx,zynqmp-8.9a")) {
-   sdhci_zynqmp_sampleclk_set_phase(host, iclk_phase);
-   sdhci_zynqmp_sdcardclk_set_phase(host, oclk_phase);
+   ret = sdhci_zynqmp_sampleclk_set_phase(host, iclk_phase);
+   if (ret)
+   return ret;
+
+   ret = sdhci_zynqmp_sdcardclk_set_phase(host, oclk_phase);
+   if (ret)
+   return ret;
} else if (IS_ENABLED(CONFIG_ARCH_VERSAL) &&
   device_is_compatible(dev, "xlnx,versal-8.9a")) {
-   sdhci_versal_sampleclk_set_phase(host, iclk_phase);
-   sdhci_versal_sdcardclk_set_phase(host, oclk_phase);
+   ret = sdhci_versal_sampleclk_set_phase(host, iclk_phase);
+   if (ret)
+   return ret;
+
+   ret = sdhci_versal_sdcardclk_set_phase(host, oclk_phase);
+   if (ret)
+   return ret;
}
+
+   return 0;
 }
 
 static void arasan_dt_read_clk_phase(struct udevice *dev, unsigned char timing,
-- 
2.17.1

[PATCH v3 2/7] mmc: sdhci: Change prototype of set_delay to return errors

[Ashok Reddy Soma]

set_delay() has return type as void. If there are any errors while
setting tapdelay's it won't be able to return them.

Change the prototype of set_delay() in sdhci_ops structure and return
the errors from wherever it is called.

Signed-off-by: Ashok Reddy Soma 
---

(no changes since v2)

Changes in v2:
 - This is the second patch that has been split from 1/7
 - This covers changes for sdhci driver separately
 - Added a debug print in case of error from set_delay()

 drivers/mmc/sdhci.c | 10 --
 include/sdhci.h |  2 +-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index d9ab6a0a83..a99014236a 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -366,6 +366,7 @@ int sdhci_set_clock(struct mmc *mmc, unsigned int clock)
 {
struct sdhci_host *host = mmc->priv;
unsigned int div, clk = 0, timeout;
+   int ret;
 
/* Wait max 20 ms */
timeout = 200;
@@ -386,8 +387,13 @@ int sdhci_set_clock(struct mmc *mmc, unsigned int clock)
if (clock == 0)
return 0;
 
-   if (host->ops && host->ops->set_delay)
-   host->ops->set_delay(host);
+   if (host->ops && host->ops->set_delay) {
+   ret = host->ops->set_delay(host);
+   if (ret) {
+   printf("%s: Error while setting tap delay\n", __func__);
+   return ret;
+   }
+   }
 
if (SDHCI_GET_VERSION(host) >= SDHCI_SPEC_300) {
/*
diff --git a/include/sdhci.h b/include/sdhci.h
index 0ae9471ad7..44a0d84e5a 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -268,7 +268,7 @@ struct sdhci_ops {
int (*set_ios_post)(struct sdhci_host *host);
void(*set_clock)(struct sdhci_host *host, u32 div);
int (*platform_execute_tuning)(struct mmc *host, u8 opcode);
-   void (*set_delay)(struct sdhci_host *host);
+   int (*set_delay)(struct sdhci_host *host);
int (*deferred_probe)(struct sdhci_host *host);
 };
 
-- 
2.17.1

[PATCH v3 3/7] zynqmp_firmware: Add zynqmp firmware related enums

[Ashok Reddy Soma]

From: T Karthik Reddy 

Add enums for pm node id's, pm ioctl id's, tapdelay types, dll reset types

Signed-off-by: T Karthik Reddy 
Signed-off-by: Ashok Reddy Soma 
---

(no changes since v1)

 include/zynqmp_firmware.h | 127 ++
 1 file changed, 127 insertions(+)

diff --git a/include/zynqmp_firmware.h b/include/zynqmp_firmware.h
index f6f82bf882..c559ee7d3c 100644
--- a/include/zynqmp_firmware.h
+++ b/include/zynqmp_firmware.h
@@ -62,6 +62,99 @@ enum pm_api_id {
PM_API_MAX,
 };
 
+enum pm_node_id {
+   NODE_UNKNOWN = 0,
+   NODE_APU = 1,
+   NODE_APU_0 = 2,
+   NODE_APU_1 = 3,
+   NODE_APU_2 = 4,
+   NODE_APU_3 = 5,
+   NODE_RPU = 6,
+   NODE_RPU_0 = 7,
+   NODE_RPU_1 = 8,
+   NODE_PLD = 9,
+   NODE_FPD = 10,
+   NODE_OCM_BANK_0 = 11,
+   NODE_OCM_BANK_1 = 12,
+   NODE_OCM_BANK_2 = 13,
+   NODE_OCM_BANK_3 = 14,
+   NODE_TCM_0_A = 15,
+   NODE_TCM_0_B = 16,
+   NODE_TCM_1_A = 17,
+   NODE_TCM_1_B = 18,
+   NODE_L2 = 19,
+   NODE_GPU_PP_0 = 20,
+   NODE_GPU_PP_1 = 21,
+   NODE_USB_0 = 22,
+   NODE_USB_1 = 23,
+   NODE_TTC_0 = 24,
+   NODE_TTC_1 = 25,
+   NODE_TTC_2 = 26,
+   NODE_TTC_3 = 27,
+   NODE_SATA = 28,
+   NODE_ETH_0 = 29,
+   NODE_ETH_1 = 30,
+   NODE_ETH_2 = 31,
+   NODE_ETH_3 = 32,
+   NODE_UART_0 = 33,
+   NODE_UART_1 = 34,
+   NODE_SPI_0 = 35,
+   NODE_SPI_1 = 36,
+   NODE_I2C_0 = 37,
+   NODE_I2C_1 = 38,
+   NODE_SD_0 = 39,
+   NODE_SD_1 = 40,
+   NODE_DP = 41,
+   NODE_GDMA = 42,
+   NODE_ADMA = 43,
+   NODE_NAND = 44,
+   NODE_QSPI = 45,
+   NODE_GPIO = 46,
+   NODE_CAN_0 = 47,
+   NODE_CAN_1 = 48,
+   NODE_EXTERN = 49,
+   NODE_APLL = 50,
+   NODE_VPLL = 51,
+   NODE_DPLL = 52,
+   NODE_RPLL = 53,
+   NODE_IOPLL = 54,
+   NODE_DDR = 55,
+   NODE_IPI_APU = 56,
+   NODE_IPI_RPU_0 = 57,
+   NODE_GPU = 58,
+   NODE_PCIE = 59,
+   NODE_PCAP = 60,
+   NODE_RTC = 61,
+   NODE_LPD = 62,
+   NODE_VCU = 63,
+   NODE_IPI_RPU_1 = 64,
+   NODE_IPI_PL_0 = 65,
+   NODE_IPI_PL_1 = 66,
+   NODE_IPI_PL_2 = 67,
+   NODE_IPI_PL_3 = 68,
+   NODE_PL = 69,
+   NODE_GEM_TSU = 70,
+   NODE_SWDT_0 = 71,
+   NODE_SWDT_1 = 72,
+   NODE_CSU = 73,
+   NODE_PJTAG = 74,
+   NODE_TRACE = 75,
+   NODE_TESTSCAN = 76,
+   NODE_PMU = 77,
+   NODE_MAX = 78,
+};
+
+enum tap_delay_type {
+   PM_TAPDELAY_INPUT = 0,
+   PM_TAPDELAY_OUTPUT = 1,
+};
+
+enum dll_reset_type {
+   PM_DLL_RESET_ASSERT = 0,
+   PM_DLL_RESET_RELEASE = 1,
+   PM_DLL_RESET_PULSE = 2,
+};
+
 enum pm_query_id {
PM_QID_INVALID = 0,
PM_QID_CLOCK_GET_NAME = 1,
@@ -79,6 +172,40 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR = 13,
 };
 
+enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE,
+   IOCTL_SET_RPU_OPER_MODE,
+   IOCTL_RPU_BOOT_ADDR_CONFIG,
+   IOCTL_TCM_COMB_CONFIG,
+   IOCTL_SET_TAPDELAY_BYPASS,
+   IOCTL_SET_SGMII_MODE,
+   IOCTL_SD_DLL_RESET,
+   IOCTL_SET_SD_TAPDELAY,
+   IOCTL_SET_PLL_FRAC_MODE,
+   IOCTL_GET_PLL_FRAC_MODE,
+   IOCTL_SET_PLL_FRAC_DATA,
+   IOCTL_GET_PLL_FRAC_DATA,
+   IOCTL_WRITE_GGS,
+   IOCTL_READ_GGS,
+   IOCTL_WRITE_PGGS,
+   IOCTL_READ_PGGS,
+   /* IOCTL for ULPI reset */
+   IOCTL_ULPI_RESET,
+   /* Set healthy bit value*/
+   IOCTL_SET_BOOT_HEALTH_STATUS,
+   IOCTL_AFI,
+   /* Probe counter read/write */
+   IOCTL_PROBE_COUNTER_READ,
+   IOCTL_PROBE_COUNTER_WRITE,
+   IOCTL_OSPI_MUX_SELECT,
+   /* IOCTL for USB power request */
+   IOCTL_USB_SET_STATE,
+   /* IOCTL to get last reset reason */
+   IOCTL_GET_LAST_RESET_REASON,
+   /* AIE ISR Clear */
+   IOCTL_AIE_ISR_CLEAR,
+};
+
 #define PM_SIP_SVC  0xc200
 
 #define ZYNQMP_PM_VERSION_MAJOR 1
-- 
2.17.1

[PATCH v3 0/7] Arasan sdhci driver updates

[Ashok Reddy Soma]

This patch series updates/fixes below things:
 - Handle errors from tapdelay functions and return to set_delay()
 - Add ZynqMP firmware related enums which are used in sdhci driver
 - Replace mmio_write() with firmware call xilinx_pm_request()
 - Move tapdelay setting code from tap_delays.c to driver and remove
   tap_dealy.c and zynqmp_tap_delay.h
 - Change variable name from deviceid to node_id in couple of functions
   for consistancy
 - Add a workaround for sd card detect stable issue for Versal platforms
 - Use set_control_reg from sdhci.c

These patches are based on below microblaze U-Boot 'next' branch.
https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/commits/next

Changes in v3:
 - Added new line after return at two places
 - As we are seeing issues with SPL flow, keep zynqmp_mmio_write method
   to set tapdelay's and DLL resets. Add xilinx_pm_request on top of it
   for regular flow.
 - Changed the patch title to reflect these changes
 - Make the changes on top of patch 4/7 to move the code to zynq_sdhci.c

Changes in v2:
 - Split patch 1/7 to two patches, one for zynq_sdhci and other one
   for sdhci
 - This is the second patch that has been split from 1/7
 - This covers changes for sdhci driver separately
 - Added a debug print in case of error from set_delay()
 - Added comment for why 1ms delay is needed between DLL assert and
 release
 - Remove mmc->dev->seq_ and use priv->deviceid instead
 - Changed return error from -EIO to -ETIMEDOUT in arasan_sdhci_probe()
   in card detect state stable workaround

Ashok Reddy Soma (5):
  mmc: zynq_sdhci: Return errors from arasan_sdhci_set_tapdelay
  mmc: sdhci: Change prototype of set_delay to return errors
  mmc: zynq_sdhci: Add xilinx_pm_request() method to set tapdelays
  mmc: zynq_sdhci: Move setting tapdelay code to driver
  mmc: zynq_sdhci: Use set_control_reg from sdhci.c

T Karthik Reddy (2):
  zynqmp_firmware: Add zynqmp firmware related enums
  mmc: zynq_sdhci: Wait till sd card detect state is stable

 board/xilinx/zynqmp/Makefile |   2 -
 board/xilinx/zynqmp/tap_delays.c | 101 -
 drivers/mmc/sdhci.c  |  10 +-
 drivers/mmc/zynq_sdhci.c | 242 ++-
 include/sdhci.h  |   2 +-
 include/zynqmp_firmware.h| 127 
 include/zynqmp_tap_delay.h   |  21 ---
 7 files changed, 338 insertions(+), 167 deletions(-)
 delete mode 100644 board/xilinx/zynqmp/tap_delays.c
 delete mode 100644 include/zynqmp_tap_delay.h

-- 
2.17.1

[PATCH v2 2/5] configs: meson64_android: implement recovery boot via BCB

[Mattijs Korpershoek]

Right now meson64_android does not know how to boot into Android
Recovery: it simply falls back to "fastboot" mode in the bootloader.

Implement the boot to recovery.
While at it, use the standard BCB way instead of a sm for consistency.

Signed-off-by: Mattijs Korpershoek 
Acked-by: Neil Armstrong 
---
 include/configs/meson64_android.h | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/include/configs/meson64_android.h 
b/include/configs/meson64_android.h
index d732032d1f..ce08346b70 100644
--- a/include/configs/meson64_android.h
+++ b/include/configs/meson64_android.h
@@ -21,6 +21,10 @@
 #define CONTROL_PARTITION "misc"
 #endif
 
+#ifndef RECOVERY_PARTITION
+#define RECOVERY_PARTITION "recovery"
+#endif
+
 #define BOOTENV_DEV_FASTBOOT(devtypeu, devtypel, instance) \
"bootcmd_fastboot=" \
"setenv run_fastboot 0;" \
@@ -51,20 +55,23 @@
 #define BOOTENV_DEV_NAME_FASTBOOT(devtypeu, devtypel, instance)\
"fastboot "
 
-/* TOFIX: Run actual recovery instead of fastboot */
 #define BOOTENV_DEV_RECOVERY(devtypeu, devtypel, instance) \
"bootcmd_recovery=" \
"pinmux dev pinctrl@14;" \
"pinmux dev pinctrl@40;" \
-   "sm reboot_reason reason;" \
"setenv run_recovery 0;" \
"if run check_button; then " \
"echo Recovery button is pressed;" \
"setenv run_recovery 1;" \
-   "elif test \"${reason}\" = \"recovery\" -o " \
- "\"${reason}\" = \"update\"; then " \
-   "echo Recovery asked by reboot reason;" \
-   "setenv run_recovery 1;" \
+   "fi; " \
+   "if bcb load " __stringify(CONFIG_FASTBOOT_FLASH_MMC_DEV) " " \
+   CONTROL_PARTITION "; then " \
+   "if bcb test command = boot-recovery; then " \
+   "echo BCB: Recovery boot...; " \
+   "setenv run_recovery 1;" \
+   "fi;" \
+   "else " \
+   "echo Warning: BCB is corrupted or does not exist; " \
"fi;" \
"if test \"${skip_recovery}\" -eq 1; then " \
"echo Recovery skipped by environment;" \
@@ -76,7 +83,16 @@
"fi;" \
"if test \"${run_recovery}\" -eq 1; then " \
"echo Running Recovery...;" \
-   "fastboot " __stringify(CONFIG_FASTBOOT_USB_DEV) "; " \
+   "mmc dev ${mmcdev};" \
+   "setenv bootargs \"${bootargs} 
androidboot.serialno=${serial#}\";" \
+   "part start mmc ${mmcdev} " RECOVERY_PARTITION " 
boot_start;" \
+   "part size mmc ${mmcdev} " RECOVERY_PARTITION " 
boot_size;" \
+   "if mmc read ${loadaddr} ${boot_start} ${boot_size}; 
then " \
+   "echo Running Android Recovery...;" \
+   "bootm ${loadaddr};" \
+   "fi;" \
+   "echo Failed to boot Android...;" \
+   "reset;" \
"fi\0"
 
 #define BOOTENV_DEV_NAME_RECOVERY(devtypeu, devtypel, instance)\
-- 
2.30.2

[PATCH v2 4/5] configs: sei610/sei510: set CONFIG_CMD_BCB=y

[Mattijs Korpershoek]

SEI-610 and SEI-510 are both for Android boards based on Yukawa[1]

Enable the BCB command to enable the standard Android boot flow.

[1] https://android.googlesource.com/device/amlogic/yukawa/
Signed-off-by: Mattijs Korpershoek 
Acked-by: Neil Armstrong 
---
 configs/sei510_defconfig | 1 +
 configs/sei610_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/sei510_defconfig b/configs/sei510_defconfig
index 63b3043a15..74328f2fd4 100644
--- a/configs/sei510_defconfig
+++ b/configs/sei510_defconfig
@@ -22,6 +22,7 @@ CONFIG_PREBOOT="run load_logo"
 CONFIG_MISC_INIT_R=y
 # CONFIG_CMD_BDI is not set
 # CONFIG_CMD_IMI is not set
+CONFIG_CMD_BCB=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 # CONFIG_CMD_LOADS is not set
diff --git a/configs/sei610_defconfig b/configs/sei610_defconfig
index 56f136ed96..2a6d0e5995 100644
--- a/configs/sei610_defconfig
+++ b/configs/sei610_defconfig
@@ -22,6 +22,7 @@ CONFIG_PREBOOT="run load_logo"
 CONFIG_MISC_INIT_R=y
 # CONFIG_CMD_BDI is not set
 # CONFIG_CMD_IMI is not set
+CONFIG_CMD_BCB=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 # CONFIG_CMD_LOADS is not set
-- 
2.30.2

[PATCH v2 5/5] Revert "ARM: meson: Add support for fastboot_set_reboot_flag()"

[Mattijs Korpershoek]

With the introduction of a generic reboot flag implemented in commit
a362ce214f ("fastboot: Implement generic fastboot_set_reboot_flag"), we
no longer need the custom PSCI implementation to handle the reboot reason.

This reverts commit 9a34dedfae0ebb031a45324c2fed8c39b2c6fcf2.

Signed-off-by: Mattijs Korpershoek 
Acked-by: Neil Armstrong 
---
 arch/arm/mach-meson/board-common.c | 34 --
 1 file changed, 34 deletions(-)

diff --git a/arch/arm/mach-meson/board-common.c 
b/arch/arm/mach-meson/board-common.c
index 1690b6b1e6..7ceba7cede 100644
--- a/arch/arm/mach-meson/board-common.c
+++ b/arch/arm/mach-meson/board-common.c
@@ -22,10 +22,7 @@
 #include 
 #include 
 
-#if CONFIG_IS_ENABLED(FASTBOOT)
 #include 
-#include 
-#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -152,38 +149,7 @@ int board_late_init(void)
return meson_board_late_init();
 }
 
-#if CONFIG_IS_ENABLED(FASTBOOT)
-static unsigned int reboot_reason = REBOOT_REASON_NORMAL;
-
-int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
-{
-   if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
-   return -ENOTSUPP;
-
-   reboot_reason = REBOOT_REASON_BOOTLOADER;
-
-   printf("Using reboot reason: 0x%x\n", reboot_reason);
-
-   return 0;
-}
-
-void reset_cpu(void)
-{
-   struct pt_regs regs;
-
-   regs.regs[0] = ARM_PSCI_0_2_FN_SYSTEM_RESET;
-   regs.regs[1] = reboot_reason;
-
-   printf("Rebooting with reason: 0x%lx\n", regs.regs[1]);
-
-   smc_call(®s);
-
-   while (1)
-   ;
-}
-#else
 void reset_cpu(void)
 {
psci_system_reset();
 }
-#endif
-- 
2.30.2

[PATCH v2 3/5] configs: meson64_android: reboot to fastbootd from bootloader

[Mattijs Korpershoek]

Whenever we test for boot-fastboot in the BCB, it means that Android
wants us to boot into recovery with a special mode (fastbootd).

Force reboot into recovery in that case.

Note: we don't erase the bcb on purpose here: recoveryOS needs to read
the BCB as well to know if it boots into regular recovery mode or
fastbootd mode.

Signed-off-by: Mattijs Korpershoek 
Acked-by: Neil Armstrong 
---
 include/configs/meson64_android.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/configs/meson64_android.h 
b/include/configs/meson64_android.h
index ce08346b70..f9f2b26416 100644
--- a/include/configs/meson64_android.h
+++ b/include/configs/meson64_android.h
@@ -44,6 +44,10 @@
"bcb clear command; bcb store; " \
"setenv run_fastboot 1;" \
"fi; " \
+   "if bcb test command = boot-fastboot; then " \
+   "echo BCB: fastboot userspace boot...; " \
+   "setenv force_recovery 1;" \
+   "fi; " \
"else " \
"echo Warning: BCB is corrupted or does not exist; " \
"fi;" \
-- 
2.30.2

[PATCH v2 0/5] meson64_android: use BCB for reboot reason

[Mattijs Korpershoek]

The SEI-610 and SEI-510 boards are well supported in the
Android Open Source project via the yukawa [1] platform.

Their U-Boot version, despite being public [2] is not in mainline.

Android has multiple OSes it can boot into:
* Main android
* Recovery OS
* Fastbootd (recovery OS with fastboot mode)
* Bootloader (U-Boot) with fastboot mode

The decision of which OS to boot into is taken by the bootloader based on
the "reboot reason".

For amlogic boards, we pass the reboot reason via a custom smc call.
This support is limited: we don't r

These series reworks the reboot reason handling to use the BCB, which
is the standard Android way.

[1] https://android.googlesource.com/device/amlogic/yukawa
[2] https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ

Changes in v2:
* re-ordered commits
* added Neil's Acked-by

Mattijs Korpershoek (5):
  configs: meson64_android: use BCB for reboot to bootloader
  configs: meson64_android: implement recovery boot via BCB
  configs: meson64_android: reboot to fastbootd from bootloader
  configs: sei610/sei510: set CONFIG_CMD_BCB=y
  Revert "ARM: meson: Add support for fastboot_set_reboot_flag()"

 arch/arm/mach-meson/board-common.c | 34 -
 configs/sei510_defconfig   |  1 +
 configs/sei610_defconfig   |  1 +
 include/configs/meson64_android.h  | 60 --
 4 files changed, 42 insertions(+), 54 deletions(-)

-- 
2.30.2

[PATCH v2 1/5] configs: meson64_android: use BCB for reboot to bootloader

[Mattijs Korpershoek]

As of today, we use a "vendor specific" secure monitor call for the
reboot reason (sm).

We should not need this. Android uses the BCB (Bootloader Control Block)
to communicate with the bootloader.

Implement "reboot into bootloader" using the standard BCB way instead of
using sm calls.

Signed-off-by: Mattijs Korpershoek 
Acked-by: Neil Armstrong 
---
 include/configs/meson64_android.h | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/include/configs/meson64_android.h 
b/include/configs/meson64_android.h
index 3b61d5f703..d732032d1f 100644
--- a/include/configs/meson64_android.h
+++ b/include/configs/meson64_android.h
@@ -17,9 +17,12 @@
 #define LOGO_PARTITION "logo"
 #endif
 
+#ifndef CONTROL_PARTITION
+#define CONTROL_PARTITION "misc"
+#endif
+
 #define BOOTENV_DEV_FASTBOOT(devtypeu, devtypel, instance) \
"bootcmd_fastboot=" \
-   "sm reboot_reason reason;" \
"setenv run_fastboot 0;" \
"if test \"${boot_source}\" = \"usb\"; then " \
"echo Fastboot forced by usb rom boot;" \
@@ -30,18 +33,15 @@
"echo Broken MMC partition scheme;" \
"setenv run_fastboot 1;" \
"fi;" \
-   "if test \"${reason}\" = \"bootloader\" -o " \
-   "\"${reason}\" = \"fastboot\"; then " \
-   "echo Fastboot asked by reboot reason;" \
-   "setenv run_fastboot 1;" \
-   "fi;" \
-   "if test \"${skip_fastboot}\" -eq 1; then " \
-   "echo Fastboot skipped by environment;" \
-   "setenv run_fastboot 0;" \
-   "fi;" \
-   "if test \"${force_fastboot}\" -eq 1; then " \
-   "echo Fastboot forced by environment;" \
-   "setenv run_fastboot 1;" \
+   "if bcb load " __stringify(CONFIG_FASTBOOT_FLASH_MMC_DEV) " " \
+   CONTROL_PARTITION "; then " \
+   "if bcb test command = bootonce-bootloader; then " \
+   "echo BCB: Bootloader boot...; " \
+   "bcb clear command; bcb store; " \
+   "setenv run_fastboot 1;" \
+   "fi; " \
+   "else " \
+   "echo Warning: BCB is corrupted or does not exist; " \
"fi;" \
"if test \"${run_fastboot}\" -eq 1; then " \
"echo Running Fastboot...;" \
-- 
2.30.2

[PATCH v2] mmc: Add support for enumerating MMC card in a given mode using mmc command

[Aswath Govindraju]

Add support for enumerating MMC card in a given mode using mmc rescan and
mmc dev commands. The speed mode is provided as the last argument in these
commands and is indicated using the index from enum bus_mode in
include/mmc.h. A speed mode can be set only if it has already been enabled
in the device tree.

Signed-off-by: Aswath Govindraju 
---

Changes since v1:
- Removed #ifdef around the definition of user_speed_mode field
- Replaced #if with if (IS_ENABLED())
- Removed repeated MMC_CAP(MMC_LEGACY)
- initialized user_speed_mode to MMC_MODES_SPEED in mmc_init_device
  and mmc_dp_preinit
- corrected curr_device to dev and included part check, the case when
  mode is provided in the argument

 cmd/Kconfig  | 10 ++
 cmd/mmc.c| 75 +---
 doc/usage/mmc.rst| 49 --
 drivers/mmc/mmc-uclass.c |  5 ++-
 drivers/mmc/mmc.c| 22 +++-
 include/mmc.h|  2 ++
 6 files changed, 138 insertions(+), 25 deletions(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index ffef3cc76ca4..3a857b3f6e2e 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2389,4 +2389,14 @@ config CMD_UBIFS
help
  UBIFS is a file system for flash devices which works on top of UBI.
 
+config MMC_SPEED_MODE_SET
+   bool "set speed mode using mmc command"
+   depends on CMD_MMC
+   default n
+   help
+ Enable setting speed mode using mmc rescan and mmc dev commands.
+ The speed mode is provided as the last argument in these commands
+ and is indicated using the index from enum bus_mode in
+ include/mmc.h. A speed mode can be set only if it has already
+ been enabled in the device tree.
 endmenu
diff --git a/cmd/mmc.c b/cmd/mmc.c
index b942576b58ac..e256210a3705 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
}
}
 }
-static struct mmc *init_mmc_device(int dev, bool force_init)
+
+static struct mmc *init_mmc_device(int dev, bool force_init,
+  enum bus_mode speed_mode)
 {
struct mmc *mmc;
mmc = find_mmc_device(dev);
@@ -134,6 +136,10 @@ static struct mmc *init_mmc_device(int dev, bool 
force_init)
 
if (force_init)
mmc->has_init = 0;
+
+   if (IS_ENABLED(CONFIG_MMC_SPEED_MODE_SET))
+   mmc->user_speed_mode = speed_mode;
+
if (mmc_init(mmc))
return NULL;
 
@@ -159,7 +165,7 @@ static int do_mmcinfo(struct cmd_tbl *cmdtp, int flag, int 
argc,
}
}
 
-   mmc = init_mmc_device(curr_device, false);
+   mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
 
@@ -293,7 +299,7 @@ static int do_mmcrpmb(struct cmd_tbl *cmdtp, int flag,
if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
return CMD_RET_SUCCESS;
 
-   mmc = init_mmc_device(curr_device, false);
+   mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
 
@@ -338,7 +344,7 @@ static int do_mmc_read(struct cmd_tbl *cmdtp, int flag,
blk = simple_strtoul(argv[2], NULL, 16);
cnt = simple_strtoul(argv[3], NULL, 16);
 
-   mmc = init_mmc_device(curr_device, false);
+   mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
 
@@ -387,7 +393,7 @@ static int do_mmc_sparse_write(struct cmd_tbl *cmdtp, int 
flag,
return CMD_RET_FAILURE;
}
 
-   mmc = init_mmc_device(curr_device, false);
+   mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
 
@@ -431,7 +437,7 @@ static int do_mmc_write(struct cmd_tbl *cmdtp, int flag,
blk = simple_strtoul(argv[2], NULL, 16);
cnt = simple_strtoul(argv[3], NULL, 16);
 
-   mmc = init_mmc_device(curr_device, false);
+   mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
 
@@ -460,7 +466,7 @@ static int do_mmc_erase(struct cmd_tbl *cmdtp, int flag,
blk = simple_strtoul(argv[1], NULL, 16);
cnt = simple_strtoul(argv[2], NULL, 16);
 
-   mmc = init_mmc_device(curr_device, false);
+   mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
 
@@ -482,8 +488,19 @@ static int do_mmc_rescan(struct cmd_tbl *cmdtp, int flag,
 int argc, char *const argv[])
 {
struct mmc *mmc;
+   enum bus_mode speed_mode = MMC_MODES_END;
+
+   if (argc == 1) {
+   mmc = init_mmc_device(curr_device, true, MMC_MODES_END);
+   } else if (argc == 2) {
+   /* parse the mode */
+   speed_mode = simple_strtoul(argv[1], NULL, 10);
+  

[PATCH] fastboot: fix partition name truncation in environment lookup

[Matthias Schiffer]

strlcat() need to be passed the full buffer length. The incorrect call
caused truncation of partition names for fastboot_raw_partition_... and
fastboot_partition_alias_... env lookup to much less than PART_NAME_LEN.

Fixes: 69a752983171 ("fastboot: Fix possible buffer overrun")
Signed-off-by: Matthias Schiffer 
---
 drivers/fastboot/fb_mmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index 2f3837e559..33fd6c21af 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -40,7 +40,7 @@ static int raw_part_get_info_by_name(struct blk_desc 
*dev_desc,
 
/* check for raw partition descriptor */
strcpy(env_desc_name, "fastboot_raw_partition_");
-   strlcat(env_desc_name, name, PART_NAME_LEN);
+   strlcat(env_desc_name, name, sizeof(env_desc_name));
raw_part_desc = strdup(env_get(env_desc_name));
if (raw_part_desc == NULL)
return -ENODEV;
@@ -114,7 +114,7 @@ static int part_get_info_by_name_or_alias(struct blk_desc 
**dev_desc,
 
/* check for alias */
strcpy(env_alias_name, "fastboot_partition_alias_");
-   strlcat(env_alias_name, name, PART_NAME_LEN);
+   strlcat(env_alias_name, name, sizeof(env_alias_name));
aliased_part_name = env_get(env_alias_name);
if (aliased_part_name != NULL)
ret = do_get_part_info(dev_desc, aliased_part_name,
-- 
2.17.1

Re: [PATCH 0/5] meson64_android: use BCB for reboot reason

[Neil Armstrong]

On 30/07/2021 10:55, Mattijs Korpershoek wrote:
> The SEI-610 and SEI-510 boards are well supported in the
> Android Open Source project via the yukawa [1] platform.
> 
> Their U-Boot version, despite being public [2] is not in mainline.
> 
> Android has multiple OSes it can boot into:
> * Main android
> * Recovery OS
> * Fastbootd (recovery OS with fastboot mode)
> * Bootloader (U-Boot) with fastboot mode
> 
> The decision of which OS to boot into is taken by the bootloader based on
> the "reboot reason".
> 
> For amlogic boards, we pass the reboot reason via a custom smc call.
> This support is limited: we don't r
> 
> These series reworks the reboot reason handling to use the BCB, which
> is the standard Android way.
> 
> [1] https://android.googlesource.com/device/amlogic/yukawa
> [2] 
> https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ
> 
> Mattijs Korpershoek (5):
>   Revert "ARM: meson: Add support for fastboot_set_reboot_flag()"
>   configs: meson64_android: use BCB for reboot to bootloader
>   configs: meson64_android: implement recovery boot via BCB
>   configs: meson64_android: reboot to fastbootd from bootloader
>   configs: sei610/sei510: set CONFIG_CMD_BCB=y
> 
>  arch/arm/mach-meson/board-common.c | 34 -
>  configs/sei510_defconfig   |  1 +
>  configs/sei610_defconfig   |  1 +
>  include/configs/meson64_android.h  | 60 --
>  4 files changed, 42 insertions(+), 54 deletions(-)
> 

Looks fine, but I'll move the patch 1 as last.

Can you re-post ?

Please add:
Acked-by: Neil Armstrong 

to all patches if you repost.

Neil

[PATCH] dm: migrate the dm_warn to use the log macro

[Patrick Delaunay]

Migrate the dm_warn function to log macro with
LOGC_DM category and LOGL_WARNING level.

This macro allows filtering with log command and allows
output on all log backend.

Signed-off-by: Patrick Delaunay 
---

 drivers/core/util.c | 11 ---
 include/dm/util.h   |  2 +-
 2 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/core/util.c b/drivers/core/util.c
index 91e93b0cf1..5be4ee79de 100644
--- a/drivers/core/util.c
+++ b/drivers/core/util.c
@@ -11,17 +11,6 @@
 #include 
 #include 
 
-#if CONFIG_IS_ENABLED(DM_WARN)
-void dm_warn(const char *fmt, ...)
-{
-   va_list args;
-
-   va_start(args, fmt);
-   vprintf(fmt, args);
-   va_end(args);
-}
-#endif
-
 int list_count_items(struct list_head *head)
 {
struct list_head *node;
diff --git a/include/dm/util.h b/include/dm/util.h
index 138893c935..c634e470e7 100644
--- a/include/dm/util.h
+++ b/include/dm/util.h
@@ -7,7 +7,7 @@
 #define __DM_UTIL_H
 
 #if CONFIG_IS_ENABLED(DM_WARN)
-void dm_warn(const char *fmt, ...);
+#define dm_warn(fmt...) log(LOGC_DM, LOGL_WARNING, ##fmt)
 #else
 static inline void dm_warn(const char *fmt, ...)
 {
-- 
2.25.1

[PATCH 2/2] dm: add debug message when failed to select the default pinctrl

[Patrick Delaunay]

Add a message on probe in driver model core when the default
pinctrl selection failed.

This message is displayed only when the pinctrl API is
implemented, i.e. when result is not ENOSYS.

Signed-off-by: Patrick Delaunay 
---

 drivers/core/device.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 29668f6fb3..6710c847e1 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -532,8 +532,12 @@ int device_probe(struct udevice *dev)
 * is set just above. However, the PCI bus' probe() method and
 * associated uclass methods have not yet been called.
 */
-   if (dev->parent && device_get_uclass_id(dev) != UCLASS_PINCTRL)
-   pinctrl_select_state(dev, "default");
+   if (dev->parent && device_get_uclass_id(dev) != UCLASS_PINCTRL) {
+   ret = pinctrl_select_state(dev, "default");
+   if (ret && ret != -ENOSYS)
+   log_debug("Device '%s' failed to configure default 
pinctrl: %d (%s)\n",
+ dev->name, ret, errno_str(ret));
+   }
 
if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
(device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
@@ -578,8 +582,12 @@ int device_probe(struct udevice *dev)
if (ret)
goto fail_uclass;
 
-   if (dev->parent && device_get_uclass_id(dev) == UCLASS_PINCTRL)
-   pinctrl_select_state(dev, "default");
+   if (dev->parent && device_get_uclass_id(dev) == UCLASS_PINCTRL) {
+   ret = pinctrl_select_state(dev, "default");
+   if (ret && ret != -ENOSYS)
+   log_debug("Device '%s' failed to configure default 
pinctrl: %d (%s)\n",
+ dev->name, ret, errno_str(ret));
+   }
 
return 0;
 fail_uclass:
-- 
2.25.1

[PATCH 1/2] pinctrl: change result for unsupported API

[Patrick Delaunay]

Use the return value ENOSYS for unsupported API
- pinctrl_generic_set_state
- pinctrl_select_state

Signed-off-by: Patrick Delaunay 
---

 include/dm/pinctrl.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/dm/pinctrl.h b/include/dm/pinctrl.h
index 695e78ad0d..8b869c4fbf 100644
--- a/include/dm/pinctrl.h
+++ b/include/dm/pinctrl.h
@@ -495,7 +495,7 @@ int pinctrl_generic_set_state(struct udevice *pctldev, 
struct udevice *config);
 static inline int pinctrl_generic_set_state(struct udevice *pctldev,
struct udevice *config)
 {
-   return -EINVAL;
+   return -ENOSYS;
 }
 #endif
 
@@ -512,7 +512,7 @@ int pinctrl_select_state(struct udevice *dev, const char 
*statename);
 static inline int pinctrl_select_state(struct udevice *dev,
   const char *statename)
 {
-   return -EINVAL;
+   return -ENOSYS;
 }
 #endif
 
-- 
2.25.1

Re: [PATCH] mmc: Add support for enumerating MMC card in a given mode using mmc command

[Aswath Govindraju]

Hi Jaehoon,

On 30/07/21 3:02 pm, Jaehoon Chung wrote:
> On 7/30/21 6:20 PM, Aswath Govindraju wrote:
>> Hi Jaehoon,
>>
>> On 30/07/21 2:44 pm, Jaehoon Chung wrote:
>>> Hi Aswath,
>>>
>>> On 7/30/21 2:12 PM, Aswath Govindraju wrote:
 Hi Jaehoon,

 On 30/07/21 4:00 am, Jaehoon Chung wrote:
> Hi Aswath,
>
> On 7/29/21 11:55 PM, Aswath Govindraju wrote:
>> Add support for enumerating MMC card in a given mode using mmc rescan and
>> mmc dev commands. The speed mode is provided as the last argument in 
>> these
>> commands and is indicated using the index from enum bus_mode in
>> include/mmc.h. A speed mode can be set only if it has already been 
>> enabled
>> in the device tree.
>
> Thanks for this patch. It seems that it's useful to develope and debug.
> I will test with this patch.
>
> Could you also update doc/usage/mmc.rst file?
>

 Sure, I'll update it in the respin.
>>>
>>> When I have simply tested with this patch, it's not working correct.
>>> I will test more and share them. Did you test about SD-card?
>>>

Actually I just found one error but I am not sure if it is the same
error you are seeing.

In my case even if mode is supported it shows that if is not supported
and this is because of [1], it should have been dev there. On correcting
it I don't see this error anymore.


>>
>> Yes, I tested with both SD-Card and eMMC.
>>
>> Also, please note that MMC_SPEED_MODE_SET has to be enabled in the
>> defconfig files.
> 
> I did. :)  (enabled MMC_SPEED_MODE_SET). 
> If it's not supported mode, it seems that always set to LEGACY mode. Is it 
> intention behavior?
> 

No, it is not expected to always set to MMC_LEGACY mode if an
unsupported mode is input.

> I will test on eMMC and SD. Well it will take a little time. Maybe Next week?
> 

Sure, I will post a respin before this weekend. Please do test and share
your results.

Thanks,
Aswath


> Best Regards,
> Jaehoon Chung
> 
>>
>> Thanks,
>> Aswath
>>
>>> Best Regards,
>>> Jaehoon Chung
>>>

 Thanks,
 Aswath

> Best Regards,
> Jaehoo Chung
>
>>
>> Signed-off-by: Aswath Govindraju 
>> ---
>>  cmd/Kconfig  | 10 ++
>>  cmd/mmc.c| 71 
>>  drivers/mmc/mmc-uclass.c |  3 ++
>>  drivers/mmc/mmc.c| 18 ++
>>  include/mmc.h|  4 +++
>>  5 files changed, 85 insertions(+), 21 deletions(-)
>>
>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>> index ffef3cc76ca4..3a857b3f6e2e 100644
>> --- a/cmd/Kconfig
>> +++ b/cmd/Kconfig
>> @@ -2389,4 +2389,14 @@ config CMD_UBIFS
>>  help
>>UBIFS is a file system for flash devices which works on top 
>> of UBI.
>>  
>> +config MMC_SPEED_MODE_SET
>> +bool "set speed mode using mmc command"
>> +depends on CMD_MMC
>> +default n
>> +help
>> +  Enable setting speed mode using mmc rescan and mmc dev 
>> commands.
>> +  The speed mode is provided as the last argument in these 
>> commands
>> +  and is indicated using the index from enum bus_mode in
>> +  include/mmc.h. A speed mode can be set only if it has already
>> +  been enabled in the device tree.
>>  endmenu
>> diff --git a/cmd/mmc.c b/cmd/mmc.c
>> index b942576b58ac..073e87d69634 100644
>> --- a/cmd/mmc.c
>> +++ b/cmd/mmc.c
>> @@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
>>  }
>>  }
>>  }
>> -static struct mmc *init_mmc_device(int dev, bool force_init)
>> +
>> +static struct mmc *init_mmc_device(int dev, bool force_init,
>> +   enum bus_mode speed_mode)
>>  {
>>  struct mmc *mmc;
>>  mmc = find_mmc_device(dev);
>> @@ -134,6 +136,11 @@ static struct mmc *init_mmc_device(int dev, bool 
>> force_init)
>>  
>>  if (force_init)
>>  mmc->has_init = 0;
>> +
>> +#if CONFIG_IS_ENABLED(MMC_SPEED_MODE_SET)
>> +mmc->user_speed_mode = speed_mode;
>> +#endif
>> +
>>  if (mmc_init(mmc))
>>  return NULL;
>>  
>> @@ -159,7 +166,7 @@ static int do_mmcinfo(struct cmd_tbl *cmdtp, int 
>> flag, int argc,
>>  }
>>  }
>>  
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>>  if (!mmc)
>>  return CMD_RET_FAILURE;
>>  
>> @@ -293,7 +300,7 @@ static int do_mmcrpmb(struct cmd_tbl *cmdtp, int 
>> flag,
>>  if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
>>  return CMD_RET_SUCCESS;
>>  
>> -mmc = init_mmc_device(curr_devi

Re: [PATCH 5/5] test: dm: Add test for ECDSA UCLASS support

[Patrick DELAUNAY]

Hi,

On 7/29/21 6:47 PM, Alexandru Gagniuc wrote:

This test verifies that ECDSA_UCLASS is implemented, and that
ecdsa_verify() works as expected. The definition of "expected" is
"does not find a device, and returns -ENODEV".

The lack of a hardware-independent ECDSA implementation prevents us
from having one in the sandbox, for now.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Simon Glass 
---
  configs/sandbox_defconfig |  2 ++
  test/dm/Makefile  |  1 +
  test/dm/ecdsa.c   | 38 ++
  3 files changed, 41 insertions(+)
  create mode 100644 test/dm/ecdsa.c



Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [PATCH 4/5] Kconfig: FIT_SIGNATURE should not select RSA_VERIFY

[Patrick DELAUNAY]

Hi,

On 7/29/21 6:47 PM, Alexandru Gagniuc wrote:

FIT signatures can now be implemented with ECDSA. The assumption that
all FIT images are signed with RSA is no longer valid. Thus, instead
of 'select'ing RSA, only 'imply' it. This doesn't change the defaults,
but allows one to explicitly disable RSA support.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Simon Glass 
Reviewed-by: Igor Opaniuk 
---
  common/Kconfig.boot | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)



Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [PATCH 3/5] arm: stm32mp1: Implement ECDSA signature verification

[Patrick DELAUNAY]

Hi,

On 7/29/21 6:47 PM, Alexandru Gagniuc wrote:

The STM32MP ROM provides several service. One of them is the ability
to verify ecdsa256 signatures. Hook the ROM API into the ECDSA uclass.

Signed-off-by: Alexandru Gagniuc 
---
  arch/arm/mach-stm32mp/Kconfig|   9 +++
  arch/arm/mach-stm32mp/Makefile   |   1 +
  arch/arm/mach-stm32mp/ecdsa_romapi.c | 102 +++
  3 files changed, 112 insertions(+)
  create mode 100644 arch/arm/mach-stm32mp/ecdsa_romapi.c



Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [PATCH 2/5] lib: ecdsa: Implement UCLASS_ECDSA verification on target

[Patrick DELAUNAY]

Hi,

On 7/29/21 6:47 PM, Alexandru Gagniuc wrote:

Implement the crypto_algo .verify() function for ecdsa256. Because
it backends on UCLASS_ECDSA, this change is focused on parsing the
keys from devicetree and passing this information to the specific
UCLASS driver.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Simon Glass 
---
  lib/Kconfig  |   1 +
  lib/Makefile |   1 +
  lib/ecdsa/Kconfig|  23 +++
  lib/ecdsa/Makefile   |   1 +
  lib/ecdsa/ecdsa-verify.c | 134 +++
  5 files changed, 160 insertions(+)
  create mode 100644 lib/ecdsa/Kconfig
  create mode 100644 lib/ecdsa/Makefile
  create mode 100644 lib/ecdsa/ecdsa-verify.c



Reviewed-by: Patrick Delaunay 

Thanks
Patrick

Re: [PATCH 1/5] dm: crypto: Define UCLASS API for ECDSA signature verification

[Patrick DELAUNAY]

Hi Alexandru,

On 7/29/21 6:47 PM, Alexandru Gagniuc wrote:

Define a UCLASS API for verifying ECDSA signatures. Unlike
UCLASS_MOD_EXP, which focuses strictly on modular exponentiation,
the ECDSA class focuses on verification. This is done so that it
better aligns with mach-specific implementations, such as stm32mp.

Signed-off-by: Alexandru Gagniuc 
---
  include/crypto/ecdsa-uclass.h | 39 +++
  include/dm/uclass-id.h|  1 +
  2 files changed, 40 insertions(+)
  create mode 100644 include/crypto/ecdsa-uclass.h



Reviewed-by: Patrick Delaunay 

Thanks
Patrick

[PATCH] xilinx: zynqmp: Reset usb and scsi via preboot

[Michal Simek]

Based on thread
https://lists.denx.de/pipermail/u-boot/2021-June/451828.html
especially
"Overall we have a deficiency in the UEFI implementation in that we
cannot deal with block devices added or removed after initialization."
there is a need to deal with removable media as usb/scsi/sata.

That's why bridge this gap in EFI implementation by resetting usb and
scsi resets to get all disks before efi_init_obj_list() is called.

In our standard boot flow, where we use distro boot, order is fixed as
"jtag mmc0 mmc1 qspi0 nand0 usb0 usb1 scsi0 pxe dhcp" with prioritizing
boot device added by commit 2882b39d564b ("arm64: zynqmp: Setup the first
boot_target at run time").
When device has ESP partition all devices should be detected because then
efi_disk_register() in efi_init_obj_list() is called only once.

The first such a device is sd/emmc(mmc0/mmc1) and then disks on usb/sata
are not handled at all.

The commit 6bb577dbb30f ("arm64: zynqmp: Disable
EFI_CAPSULE_ON_DISK_EARLY") also pointed out on this issue but detection of
removable media wasn't solved that's why do it now via preboot command.

I have tested cases without usb and scsi and there is no problem with
calling resets without devices itself.

Signed-off-by: Michal Simek 
---

 configs/xilinx_zynqmp_virt_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/xilinx_zynqmp_virt_defconfig 
b/configs/xilinx_zynqmp_virt_defconfig
index 43ab4e7bd990..748e6d668654 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -22,6 +22,7 @@ CONFIG_FIT_VERBOSE=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x1000
 CONFIG_USE_PREBOOT=y
+CONFIG_PREBOOT="scsi reset;usb reset"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_BOARD_EARLY_INIT_R=y
-- 
2.32.0

[PATCH] reset: zynqmp: Add reset controller for ZynqMP SoC

[Michal Simek]

Add firmware based reset controller for Xilinx ZynqMP SoC to let other
drivers to call reset functions. Driver is only tested on Xilinx ZynqMP but
support for Xilinx Versal can be simply added. That's why reset_id and
nr_reset are assigned in probe folder.
Driver is inpired by driver from Linux kernel.

Signed-off-by: Michal Simek 
---

 MAINTAINERS  |   1 +
 drivers/reset/Kconfig|   9 +++
 drivers/reset/Makefile   |   1 +
 drivers/reset/reset-zynqmp.c | 100 ++
 include/zynqmp_firmware.h| 131 +++
 5 files changed, 242 insertions(+)
 create mode 100644 drivers/reset/reset-zynqmp.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 483a45840803..868d4e145ca2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -600,6 +600,7 @@ F:  drivers/mtd/nand/raw/zynq_nand.c
 F: drivers/net/phy/xilinx_phy.c
 F: drivers/net/zynq_gem.c
 F: drivers/serial/serial_zynq.c
+F: drivers/reset/reset-zynqmp.c
 F: drivers/rtc/zynqmp_rtc.c
 F: drivers/spi/zynq_qspi.c
 F: drivers/spi/zynq_spi.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index a42b3f0077c9..d73daf5e3189 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -197,4 +197,13 @@ config RESET_SCMI
  Enable this option if you want to support reset controller
  devices exposed by a SCMI agent based on SCMI reset domain
  protocol communication with a SCMI server.
+
+config RESET_ZYNQMP
+   bool "Reset Driver for Xilinx ZynqMP SoC's"
+   depends on DM_RESET && ZYNQMP_FIRMWARE
+   help
+ Support for reset controller on Xilinx ZynqMP SoC. Driver is only
+ passing request via Xilinx firmware interface to TF-A and PMU
+ firmware.
+
 endmenu
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 8a0f5280761a..d69486bdeb9e 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_RESET_SIFIVE) += reset-sifive.o
 obj-$(CONFIG_RESET_SYSCON) += reset-syscon.o
 obj-$(CONFIG_RESET_RASPBERRYPI) += reset-raspberrypi.o
 obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
+obj-$(CONFIG_RESET_ZYNQMP) += reset-zynqmp.o
diff --git a/drivers/reset/reset-zynqmp.c b/drivers/reset/reset-zynqmp.c
new file mode 100644
index ..57652346738d
--- /dev/null
+++ b/drivers/reset/reset-zynqmp.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Xilinx, Inc. - Michal Simek
+ */
+
+#define LOG_CATEGORY UCLASS_RESET
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ZYNQMP_NR_RESETS   (ZYNQMP_PM_RESET_END - ZYNQMP_PM_RESET_START)
+#define ZYNQMP_RESET_IDZYNQMP_PM_RESET_START
+
+struct zynqmp_reset_priv {
+   u32 reset_id;
+   u32 nr_reset;
+};
+
+static int zynqmp_pm_reset_assert(const u32 reset,
+ const enum zynqmp_pm_reset_action assert_flag)
+{
+   return xilinx_pm_request(PM_RESET_ASSERT, reset, assert_flag, 0, 0,
+NULL);
+}
+
+static int zynqmp_reset_assert(struct reset_ctl *rst)
+{
+   struct zynqmp_reset_priv *priv = dev_get_priv(rst->dev);
+
+   dev_dbg(rst->dev, "%s(rst=%p) (id=%lu)\n", __func__, rst, rst->id);
+
+   return zynqmp_pm_reset_assert(priv->reset_id + rst->id,
+ PM_RESET_ACTION_ASSERT);
+}
+
+static int zynqmp_reset_deassert(struct reset_ctl *rst)
+{
+   struct zynqmp_reset_priv *priv = dev_get_priv(rst->dev);
+
+   dev_dbg(rst->dev, "%s(rst=%p) (id=%lu)\n", __func__, rst, rst->id);
+
+   return zynqmp_pm_reset_assert(priv->reset_id + rst->id,
+ PM_RESET_ACTION_RELEASE);
+}
+
+static int zynqmp_reset_request(struct reset_ctl *rst)
+{
+   struct zynqmp_reset_priv *priv = dev_get_priv(rst->dev);
+
+   dev_dbg(rst->dev, "%s(rst=%p) (id=%lu) (nr_reset=%d)\n", __func__,
+   rst, rst->id, priv->nr_reset);
+
+   if (rst->id > priv->nr_reset)
+   return -EINVAL;
+
+   return 0;
+}
+
+static int zynqmp_reset_free(struct reset_ctl *rst)
+{
+   struct zynqmp_reset_priv *priv = dev_get_priv(rst->dev);
+
+   dev_dbg(rst->dev, "%s(rst=%p) (id=%lu) (nr_reset=%d)\n", __func__,
+   rst, rst->id, priv->nr_reset);
+
+   return 0;
+}
+
+static int zynqmp_reset_probe(struct udevice *dev)
+{
+   struct zynqmp_reset_priv *priv = dev_get_priv(dev);
+
+   priv->reset_id = ZYNQMP_RESET_ID;
+   priv->nr_reset = ZYNQMP_NR_RESETS;
+   return 0;
+}
+
+const struct reset_ops zynqmp_reset_ops = {
+   .request = zynqmp_reset_request,
+   .rfree = zynqmp_reset_free,
+   .rst_assert = zynqmp_reset_assert,
+   .rst_deassert = zynqmp_reset_deassert,
+};
+
+static const struct udevice_id zynqmp_reset_ids[] = {
+   { .compatible = "xlnx,zynqmp-reset" },
+   { }
+};
+
+U_BOOT_DRIVER(zynqmp_reset) = {
+   .name   = "zynqmp_reset",
+   .id 

[PATCH] firmware: xilinx: Use explicit values for all enum values

[Michal Simek]

Based on discussion at
https://lore.kernel.org/r/20200318125003.ga2727...@kroah.com we got
recommendation to use explicit values for all enum values.
The patch is following this recommendation.

Signed-off-by: Michal Simek 
Link: 
https://lore.kernel.org/r/daeb67ded45d8a8f6a96717d1fb9c84439dd2ae8.1612361627.git.michal.si...@xilinx.com
---

 include/zynqmp_firmware.h | 93 +--
 1 file changed, 49 insertions(+), 44 deletions(-)

diff --git a/include/zynqmp_firmware.h b/include/zynqmp_firmware.h
index f6f82bf8828e..669af6765ce9 100644
--- a/include/zynqmp_firmware.h
+++ b/include/zynqmp_firmware.h
@@ -10,54 +10,59 @@
 
 enum pm_api_id {
PM_GET_API_VERSION = 1,
-   PM_SET_CONFIGURATION,
-   PM_GET_NODE_STATUS,
-   PM_GET_OPERATING_CHARACTERISTIC,
-   PM_REGISTER_NOTIFIER,
-   PM_REQUEST_SUSPEND,
-   PM_SELF_SUSPEND,
-   PM_FORCE_POWERDOWN,
-   PM_ABORT_SUSPEND,
-   PM_REQUEST_WAKEUP,
-   PM_SET_WAKEUP_SOURCE,
-   PM_SYSTEM_SHUTDOWN,
-   PM_REQUEST_NODE,
-   PM_RELEASE_NODE,
-   PM_SET_REQUIREMENT,
-   PM_SET_MAX_LATENCY,
-   PM_RESET_ASSERT,
-   PM_RESET_GET_STATUS,
-   PM_MMIO_WRITE,
-   PM_MMIO_READ,
-   PM_PM_INIT_FINALIZE,
-   PM_FPGA_LOAD,
-   PM_FPGA_GET_STATUS,
-   PM_GET_CHIPID,
+   PM_SET_CONFIGURATION = 2,
+   PM_GET_NODE_STATUS = 3,
+   PM_GET_OPERATING_CHARACTERISTIC = 4,
+   PM_REGISTER_NOTIFIER = 5,
+   /* API for suspending */
+   PM_REQUEST_SUSPEND = 6,
+   PM_SELF_SUSPEND = 7,
+   PM_FORCE_POWERDOWN = 8,
+   PM_ABORT_SUSPEND = 9,
+   PM_REQUEST_WAKEUP = 10,
+   PM_SET_WAKEUP_SOURCE = 11,
+   PM_SYSTEM_SHUTDOWN = 12,
+   PM_REQUEST_NODE = 13,
+   PM_RELEASE_NODE = 14,
+   PM_SET_REQUIREMENT = 15,
+   PM_SET_MAX_LATENCY = 16,
+   /* Direct control API functions: */
+   PM_RESET_ASSERT = 17,
+   PM_RESET_GET_STATUS = 18,
+   PM_MMIO_WRITE = 19,
+   PM_MMIO_READ = 20,
+   PM_PM_INIT_FINALIZE = 21,
+   PM_FPGA_LOAD = 22,
+   PM_FPGA_GET_STATUS = 23,
+   PM_GET_CHIPID = 24,
+   /* ID 25 is been used by U-boot to process secure boot images */
+   /* Secure library generic API functions */
PM_SECURE_SHA = 26,
-   PM_SECURE_RSA,
-   PM_PINCTRL_REQUEST,
-   PM_PINCTRL_RELEASE,
-   PM_PINCTRL_GET_FUNCTION,
-   PM_PINCTRL_SET_FUNCTION,
-   PM_PINCTRL_CONFIG_PARAM_GET,
-   PM_PINCTRL_CONFIG_PARAM_SET,
-   PM_IOCTL,
-   PM_QUERY_DATA,
-   PM_CLOCK_ENABLE,
-   PM_CLOCK_DISABLE,
-   PM_CLOCK_GETSTATE,
-   PM_CLOCK_SETDIVIDER,
-   PM_CLOCK_GETDIVIDER,
-   PM_CLOCK_SETRATE,
-   PM_CLOCK_GETRATE,
-   PM_CLOCK_SETPARENT,
-   PM_CLOCK_GETPARENT,
-   PM_SECURE_IMAGE,
+   PM_SECURE_RSA = 27,
+   PM_PINCTRL_REQUEST = 28,
+   PM_PINCTRL_RELEASE = 29,
+   PM_PINCTRL_GET_FUNCTION = 30,
+   PM_PINCTRL_SET_FUNCTION = 31,
+   PM_PINCTRL_CONFIG_PARAM_GET = 32,
+   PM_PINCTRL_CONFIG_PARAM_SET = 33,
+   PM_IOCTL = 34,
+   PM_QUERY_DATA = 35,
+   PM_CLOCK_ENABLE = 36,
+   PM_CLOCK_DISABLE = 37,
+   PM_CLOCK_GETSTATE = 38,
+   PM_CLOCK_SETDIVIDER = 39,
+   PM_CLOCK_GETDIVIDER = 40,
+   PM_CLOCK_SETRATE = 41,
+   PM_CLOCK_GETRATE = 42,
+   PM_CLOCK_SETPARENT = 43,
+   PM_CLOCK_GETPARENT = 44,
+   PM_SECURE_IMAGE = 45,
PM_FPGA_READ = 46,
-   PM_SECURE_AES,
+   PM_SECURE_AES = 47,
PM_CLOCK_PLL_GETPARAM = 49,
+   /* PM_REGISTER_ACCESS API */
PM_REGISTER_ACCESS = 52,
-   PM_EFUSE_ACCESS,
+   PM_EFUSE_ACCESS = 53,
PM_FEATURE_CHECK = 63,
PM_API_MAX,
 };
-- 
2.32.0

Re: [PATCH] mmc: Add support for enumerating MMC card in a given mode using mmc command

[Jaehoon Chung]

On 7/30/21 6:20 PM, Aswath Govindraju wrote:
> Hi Jaehoon,
> 
> On 30/07/21 2:44 pm, Jaehoon Chung wrote:
>> Hi Aswath,
>>
>> On 7/30/21 2:12 PM, Aswath Govindraju wrote:
>>> Hi Jaehoon,
>>>
>>> On 30/07/21 4:00 am, Jaehoon Chung wrote:
 Hi Aswath,

 On 7/29/21 11:55 PM, Aswath Govindraju wrote:
> Add support for enumerating MMC card in a given mode using mmc rescan and
> mmc dev commands. The speed mode is provided as the last argument in these
> commands and is indicated using the index from enum bus_mode in
> include/mmc.h. A speed mode can be set only if it has already been enabled
> in the device tree.

 Thanks for this patch. It seems that it's useful to develope and debug.
 I will test with this patch.

 Could you also update doc/usage/mmc.rst file?

>>>
>>> Sure, I'll update it in the respin.
>>
>> When I have simply tested with this patch, it's not working correct.
>> I will test more and share them. Did you test about SD-card?
>>
> 
> Yes, I tested with both SD-Card and eMMC.
> 
> Also, please note that MMC_SPEED_MODE_SET has to be enabled in the
> defconfig files.

I did. :)  (enabled MMC_SPEED_MODE_SET). 
If it's not supported mode, it seems that always set to LEGACY mode. Is it 
intention behavior?

I will test on eMMC and SD. Well it will take a little time. Maybe Next week?

Best Regards,
Jaehoon Chung

> 
> Thanks,
> Aswath
> 
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> Thanks,
>>> Aswath
>>>
 Best Regards,
 Jaehoo Chung

>
> Signed-off-by: Aswath Govindraju 
> ---
>  cmd/Kconfig  | 10 ++
>  cmd/mmc.c| 71 
>  drivers/mmc/mmc-uclass.c |  3 ++
>  drivers/mmc/mmc.c| 18 ++
>  include/mmc.h|  4 +++
>  5 files changed, 85 insertions(+), 21 deletions(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index ffef3cc76ca4..3a857b3f6e2e 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -2389,4 +2389,14 @@ config CMD_UBIFS
>   help
> UBIFS is a file system for flash devices which works on top of UBI.
>  
> +config MMC_SPEED_MODE_SET
> + bool "set speed mode using mmc command"
> + depends on CMD_MMC
> + default n
> + help
> +   Enable setting speed mode using mmc rescan and mmc dev commands.
> +   The speed mode is provided as the last argument in these commands
> +   and is indicated using the index from enum bus_mode in
> +   include/mmc.h. A speed mode can be set only if it has already
> +   been enabled in the device tree.
>  endmenu
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index b942576b58ac..073e87d69634 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
>   }
>   }
>  }
> -static struct mmc *init_mmc_device(int dev, bool force_init)
> +
> +static struct mmc *init_mmc_device(int dev, bool force_init,
> +enum bus_mode speed_mode)
>  {
>   struct mmc *mmc;
>   mmc = find_mmc_device(dev);
> @@ -134,6 +136,11 @@ static struct mmc *init_mmc_device(int dev, bool 
> force_init)
>  
>   if (force_init)
>   mmc->has_init = 0;
> +
> +#if CONFIG_IS_ENABLED(MMC_SPEED_MODE_SET)
> + mmc->user_speed_mode = speed_mode;
> +#endif
> +
>   if (mmc_init(mmc))
>   return NULL;
>  
> @@ -159,7 +166,7 @@ static int do_mmcinfo(struct cmd_tbl *cmdtp, int 
> flag, int argc,
>   }
>   }
>  
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>   if (!mmc)
>   return CMD_RET_FAILURE;
>  
> @@ -293,7 +300,7 @@ static int do_mmcrpmb(struct cmd_tbl *cmdtp, int flag,
>   if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
>   return CMD_RET_SUCCESS;
>  
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>   if (!mmc)
>   return CMD_RET_FAILURE;
>  
> @@ -338,7 +345,7 @@ static int do_mmc_read(struct cmd_tbl *cmdtp, int 
> flag,
>   blk = simple_strtoul(argv[2], NULL, 16);
>   cnt = simple_strtoul(argv[3], NULL, 16);
>  
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>   if (!mmc)
>   return CMD_RET_FAILURE;
>  
> @@ -387,7 +394,7 @@ static int do_mmc_sparse_write(struct cmd_tbl *cmdtp, 
> int flag,
>   return CMD_RET_FAILURE;
>   }
>  
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>   if (!mmc)
>   return CMD_RET_FAILURE;
>  
> @@ -431,7 +438,7 @@ static int do_mmc_write(struct cmd

Re: [PATCH] mmc: Add support for enumerating MMC card in a given mode using mmc command

[Aswath Govindraju]

Hi Jaehoon,

On 30/07/21 2:44 pm, Jaehoon Chung wrote:
> Hi Aswath,
> 
> On 7/30/21 2:12 PM, Aswath Govindraju wrote:
>> Hi Jaehoon,
>>
>> On 30/07/21 4:00 am, Jaehoon Chung wrote:
>>> Hi Aswath,
>>>
>>> On 7/29/21 11:55 PM, Aswath Govindraju wrote:
 Add support for enumerating MMC card in a given mode using mmc rescan and
 mmc dev commands. The speed mode is provided as the last argument in these
 commands and is indicated using the index from enum bus_mode in
 include/mmc.h. A speed mode can be set only if it has already been enabled
 in the device tree.
>>>
>>> Thanks for this patch. It seems that it's useful to develope and debug.
>>> I will test with this patch.
>>>
>>> Could you also update doc/usage/mmc.rst file?
>>>
>>
>> Sure, I'll update it in the respin.
> 
> When I have simply tested with this patch, it's not working correct.
> I will test more and share them. Did you test about SD-card?
> 

Yes, I tested with both SD-Card and eMMC.

Also, please note that MMC_SPEED_MODE_SET has to be enabled in the
defconfig files.

Thanks,
Aswath

> Best Regards,
> Jaehoon Chung
> 
>>
>> Thanks,
>> Aswath
>>
>>> Best Regards,
>>> Jaehoo Chung
>>>

 Signed-off-by: Aswath Govindraju 
 ---
  cmd/Kconfig  | 10 ++
  cmd/mmc.c| 71 
  drivers/mmc/mmc-uclass.c |  3 ++
  drivers/mmc/mmc.c| 18 ++
  include/mmc.h|  4 +++
  5 files changed, 85 insertions(+), 21 deletions(-)

 diff --git a/cmd/Kconfig b/cmd/Kconfig
 index ffef3cc76ca4..3a857b3f6e2e 100644
 --- a/cmd/Kconfig
 +++ b/cmd/Kconfig
 @@ -2389,4 +2389,14 @@ config CMD_UBIFS
help
  UBIFS is a file system for flash devices which works on top of UBI.
  
 +config MMC_SPEED_MODE_SET
 +  bool "set speed mode using mmc command"
 +  depends on CMD_MMC
 +  default n
 +  help
 +Enable setting speed mode using mmc rescan and mmc dev commands.
 +The speed mode is provided as the last argument in these commands
 +and is indicated using the index from enum bus_mode in
 +include/mmc.h. A speed mode can be set only if it has already
 +been enabled in the device tree.
  endmenu
 diff --git a/cmd/mmc.c b/cmd/mmc.c
 index b942576b58ac..073e87d69634 100644
 --- a/cmd/mmc.c
 +++ b/cmd/mmc.c
 @@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
}
}
  }
 -static struct mmc *init_mmc_device(int dev, bool force_init)
 +
 +static struct mmc *init_mmc_device(int dev, bool force_init,
 + enum bus_mode speed_mode)
  {
struct mmc *mmc;
mmc = find_mmc_device(dev);
 @@ -134,6 +136,11 @@ static struct mmc *init_mmc_device(int dev, bool 
 force_init)
  
if (force_init)
mmc->has_init = 0;
 +
 +#if CONFIG_IS_ENABLED(MMC_SPEED_MODE_SET)
 +  mmc->user_speed_mode = speed_mode;
 +#endif
 +
if (mmc_init(mmc))
return NULL;
  
 @@ -159,7 +166,7 @@ static int do_mmcinfo(struct cmd_tbl *cmdtp, int flag, 
 int argc,
}
}
  
 -  mmc = init_mmc_device(curr_device, false);
 +  mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
  
 @@ -293,7 +300,7 @@ static int do_mmcrpmb(struct cmd_tbl *cmdtp, int flag,
if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
return CMD_RET_SUCCESS;
  
 -  mmc = init_mmc_device(curr_device, false);
 +  mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
  
 @@ -338,7 +345,7 @@ static int do_mmc_read(struct cmd_tbl *cmdtp, int flag,
blk = simple_strtoul(argv[2], NULL, 16);
cnt = simple_strtoul(argv[3], NULL, 16);
  
 -  mmc = init_mmc_device(curr_device, false);
 +  mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
  
 @@ -387,7 +394,7 @@ static int do_mmc_sparse_write(struct cmd_tbl *cmdtp, 
 int flag,
return CMD_RET_FAILURE;
}
  
 -  mmc = init_mmc_device(curr_device, false);
 +  mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
  
 @@ -431,7 +438,7 @@ static int do_mmc_write(struct cmd_tbl *cmdtp, int 
 flag,
blk = simple_strtoul(argv[2], NULL, 16);
cnt = simple_strtoul(argv[3], NULL, 16);
  
 -  mmc = init_mmc_device(curr_device, false);
 +  mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
  
 @@ -460,7 +467,7 @@ static int do_mmc_erase(struct cmd_tbl *cmdtp, int 
 flag,
>>>

Re: [PATCH 2/2] board: sifive: use ccache driver instead of helper function

[Zong Li]

On Thu, Jul 29, 2021 at 8:26 PM Zong Li  wrote:
>
> On Wed, Jul 28, 2021 at 11:18 PM Sean Anderson  wrote:
> >
> > On 7/28/21 3:25 AM, Zong Li wrote:
> > > On Wed, Jul 28, 2021 at 12:29 PM Sean Anderson  wrote:
> > >>
> > >> On 7/27/21 4:54 AM, Zong Li wrote:
> > >>> Invokes the generic cache_enable interface to execute the relative
> > >>> implementation in SiFive ccache driver.
> > >>>
> > >>> Signed-off-by: Zong Li 
> > >>> ---
> > >>>arch/riscv/cpu/fu540/Kconfig  |  1 +
> > >>>arch/riscv/cpu/fu540/cache.c  | 62 
> > >>> ---
> > >>>arch/riscv/cpu/fu740/Kconfig  |  1 +
> > >>>arch/riscv/cpu/fu740/cache.c  | 60 +++---
> > >>>arch/riscv/include/asm/arch-fu540/cache.h |  2 +-
> > >>>arch/riscv/include/asm/arch-fu740/cache.h |  2 +-
> > >>>board/sifive/unleashed/unleashed.c| 10 +---
> > >>>board/sifive/unmatched/unmatched.c|  9 +---
> > >>>8 files changed, 45 insertions(+), 102 deletions(-)
> > >>>
> > >>> diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig
> > >>> index 05463b2625..1f50b823ed 100644
> > >>> --- a/arch/riscv/cpu/fu540/Kconfig
> > >>> +++ b/arch/riscv/cpu/fu540/Kconfig
> > >>> @@ -19,6 +19,7 @@ config SIFIVE_FU540
> > >>>imply SMP
> > >>>imply CLK_SIFIVE
> > >>>imply CLK_SIFIVE_PRCI
> > >>> + imply SIFIVE_CACHE_CCACHE
> > >>>imply SIFIVE_SERIAL
> > >>>imply MACB
> > >>>imply MII
> > >>> diff --git a/arch/riscv/cpu/fu540/cache.c b/arch/riscv/cpu/fu540/cache.c
> > >>> index 0fc4ef6c00..3c754c4614 100644
> > >>> --- a/arch/riscv/cpu/fu540/cache.c
> > >>> +++ b/arch/riscv/cpu/fu540/cache.c
> > >>> @@ -1,55 +1,33 @@
> > >>>// SPDX-License-Identifier: GPL-2.0+
> > >>>/*
> > >>> - * Copyright (C) 2020 SiFive, Inc
> > >>> + * Copyright (C) 2020 - 2021 SiFive, Inc
> > >>> *
> > >>> * Authors:
> > >>> *   Pragnesh Patel 
> > >>> */
> > >>>
> > >>>#include 
> > >>> -#include 
> > >>> -#include 
> > >>> -#include 
> > >>> +#include 
> > >>> +#include 
> > >>>
> > >>> -/* Register offsets */
> > >>> -#define L2_CACHE_CONFIG  0x000
> > >>> -#define L2_CACHE_ENABLE  0x008
> > >>> -
> > >>> -#define MASK_NUM_WAYSGENMASK(15, 8)
> > >>> -#define NUM_WAYS_SHIFT   8
> > >>> -
> > >>> -DECLARE_GLOBAL_DATA_PTR;
> > >>> -
> > >>> -int cache_enable_ways(void)
> > >>> +int sifive_ccache_enable_ways(void)
> > >>>{
> > >>
> > >> Is there any reason this function is duplicated? See below for further 
> > >> comments.
> > >
> > > Sorry, I don't completely understand about duplication here. Do you
> > > mean why we need this function? or why is it present in both unleashed
> > > and unmatched?
> >
> > Why it is present in both. Shouldn't it be present in some shared file?
> >
>
> I considered that before, the places to put this ccache function might
> be either 'arch/riscv/lib/' or 'arch/riscv/cpu/generic', these two
> folders put some common stuff for all riscv platforms, but this ccache
> function is actually used in sifive platform only, I'm not sure if it
> is suitable to put the function into them, so I just followed the
> original tree. OTOH, the compiler will drop the unused code, so it
> might be OK to put it into the folders above, and not influence other
> platforms. Do you have any preference or any recommendation?
>

I'm going to add a cache_init() or a weak enable_caches() which is
declared in cpu_func.h into 'arch/riscv/lib/cache.c' for the next
version.

> > >
> > >>
> > >>> - const void *blob = gd->fdt_blob;
> > >>> - int node;
> > >>> - fdt_addr_t base;
> > >>> - u32 config;
> > >>> - u32 ways;
> > >>> -
> > >>> - volatile u32 *enable;
> > >>> -
> > >>> - node = fdt_node_offset_by_compatible(blob, -1,
> > >>> -  "sifive,fu540-c000-ccache");
> > >>> -
> > >>> - if (node < 0)
> > >>> - return node;
> > >>> -
> > >>> - base = fdtdec_get_addr_size_auto_parent(blob, 0, node, "reg", 0,
> > >>> - NULL, false);
> > >>> - if (base == FDT_ADDR_T_NONE)
> > >>> - return FDT_ADDR_T_NONE;
> > >>> -
> > >>> - config = readl((volatile u32 *)base + L2_CACHE_CONFIG);
> > >>> - ways = (config & MASK_NUM_WAYS) >> NUM_WAYS_SHIFT;
> > >>> -
> > >>> - enable = (volatile u32 *)(base + L2_CACHE_ENABLE);
> > >>> + struct udevice *dev;
> > >>> + int ret;
> > >>> +
> > >>> + ret = uclass_get_device_by_driver(UCLASS_CACHE,
> > >>> +   DM_DRIVER_GET(sifive_ccache),
> > >>> +   &dev);
> > >>> + if (ret) {
> > >>> + pr_debug("%s: could not enable cache ways\n", __func__);
> > >>> + return ret;
> > >>> + }
> > >>> +
> > >>> + ret = cache_enable(dev);
> > >>> + if (ret) {
> > >>> + pr_debug("

Re: [PATCH] mmc: Add support for enumerating MMC card in a given mode using mmc command

[Jaehoon Chung]

Hi Aswath,

On 7/30/21 2:12 PM, Aswath Govindraju wrote:
> Hi Jaehoon,
> 
> On 30/07/21 4:00 am, Jaehoon Chung wrote:
>> Hi Aswath,
>>
>> On 7/29/21 11:55 PM, Aswath Govindraju wrote:
>>> Add support for enumerating MMC card in a given mode using mmc rescan and
>>> mmc dev commands. The speed mode is provided as the last argument in these
>>> commands and is indicated using the index from enum bus_mode in
>>> include/mmc.h. A speed mode can be set only if it has already been enabled
>>> in the device tree.
>>
>> Thanks for this patch. It seems that it's useful to develope and debug.
>> I will test with this patch.
>>
>> Could you also update doc/usage/mmc.rst file?
>>
> 
> Sure, I'll update it in the respin.

When I have simply tested with this patch, it's not working correct.
I will test more and share them. Did you test about SD-card?

Best Regards,
Jaehoon Chung

> 
> Thanks,
> Aswath
> 
>> Best Regards,
>> Jaehoo Chung
>>
>>>
>>> Signed-off-by: Aswath Govindraju 
>>> ---
>>>  cmd/Kconfig  | 10 ++
>>>  cmd/mmc.c| 71 
>>>  drivers/mmc/mmc-uclass.c |  3 ++
>>>  drivers/mmc/mmc.c| 18 ++
>>>  include/mmc.h|  4 +++
>>>  5 files changed, 85 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>>> index ffef3cc76ca4..3a857b3f6e2e 100644
>>> --- a/cmd/Kconfig
>>> +++ b/cmd/Kconfig
>>> @@ -2389,4 +2389,14 @@ config CMD_UBIFS
>>> help
>>>   UBIFS is a file system for flash devices which works on top of UBI.
>>>  
>>> +config MMC_SPEED_MODE_SET
>>> +   bool "set speed mode using mmc command"
>>> +   depends on CMD_MMC
>>> +   default n
>>> +   help
>>> + Enable setting speed mode using mmc rescan and mmc dev commands.
>>> + The speed mode is provided as the last argument in these commands
>>> + and is indicated using the index from enum bus_mode in
>>> + include/mmc.h. A speed mode can be set only if it has already
>>> + been enabled in the device tree.
>>>  endmenu
>>> diff --git a/cmd/mmc.c b/cmd/mmc.c
>>> index b942576b58ac..073e87d69634 100644
>>> --- a/cmd/mmc.c
>>> +++ b/cmd/mmc.c
>>> @@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
>>> }
>>> }
>>>  }
>>> -static struct mmc *init_mmc_device(int dev, bool force_init)
>>> +
>>> +static struct mmc *init_mmc_device(int dev, bool force_init,
>>> +  enum bus_mode speed_mode)
>>>  {
>>> struct mmc *mmc;
>>> mmc = find_mmc_device(dev);
>>> @@ -134,6 +136,11 @@ static struct mmc *init_mmc_device(int dev, bool 
>>> force_init)
>>>  
>>> if (force_init)
>>> mmc->has_init = 0;
>>> +
>>> +#if CONFIG_IS_ENABLED(MMC_SPEED_MODE_SET)
>>> +   mmc->user_speed_mode = speed_mode;
>>> +#endif
>>> +
>>> if (mmc_init(mmc))
>>> return NULL;
>>>  
>>> @@ -159,7 +166,7 @@ static int do_mmcinfo(struct cmd_tbl *cmdtp, int flag, 
>>> int argc,
>>> }
>>> }
>>>  
>>> -   mmc = init_mmc_device(curr_device, false);
>>> +   mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>>> if (!mmc)
>>> return CMD_RET_FAILURE;
>>>  
>>> @@ -293,7 +300,7 @@ static int do_mmcrpmb(struct cmd_tbl *cmdtp, int flag,
>>> if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
>>> return CMD_RET_SUCCESS;
>>>  
>>> -   mmc = init_mmc_device(curr_device, false);
>>> +   mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>>> if (!mmc)
>>> return CMD_RET_FAILURE;
>>>  
>>> @@ -338,7 +345,7 @@ static int do_mmc_read(struct cmd_tbl *cmdtp, int flag,
>>> blk = simple_strtoul(argv[2], NULL, 16);
>>> cnt = simple_strtoul(argv[3], NULL, 16);
>>>  
>>> -   mmc = init_mmc_device(curr_device, false);
>>> +   mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>>> if (!mmc)
>>> return CMD_RET_FAILURE;
>>>  
>>> @@ -387,7 +394,7 @@ static int do_mmc_sparse_write(struct cmd_tbl *cmdtp, 
>>> int flag,
>>> return CMD_RET_FAILURE;
>>> }
>>>  
>>> -   mmc = init_mmc_device(curr_device, false);
>>> +   mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>>> if (!mmc)
>>> return CMD_RET_FAILURE;
>>>  
>>> @@ -431,7 +438,7 @@ static int do_mmc_write(struct cmd_tbl *cmdtp, int flag,
>>> blk = simple_strtoul(argv[2], NULL, 16);
>>> cnt = simple_strtoul(argv[3], NULL, 16);
>>>  
>>> -   mmc = init_mmc_device(curr_device, false);
>>> +   mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>>> if (!mmc)
>>> return CMD_RET_FAILURE;
>>>  
>>> @@ -460,7 +467,7 @@ static int do_mmc_erase(struct cmd_tbl *cmdtp, int flag,
>>> blk = simple_strtoul(argv[1], NULL, 16);
>>> cnt = simple_strtoul(argv[2], NULL, 16);
>>>  
>>> -   mmc = init_mmc_device(curr_device, false);
>>> +   mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>>> if (!mmc)
>>> return CMD_RET_FAILURE;
>>>  
>>> @@ -482,8 +489,19 @@ s

[PATCH 3/5] configs: meson64_android: implement recovery boot via BCB

[Mattijs Korpershoek]

Right now meson64_android does not know how to boot into Android
Recovery: it simply falls back to "fastboot" mode in the bootloader.

Implement the boot to recovery.
While at it, use the standard BCB way instead of a sm for consistency.

Signed-off-by: Mattijs Korpershoek 
---
 include/configs/meson64_android.h | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/include/configs/meson64_android.h 
b/include/configs/meson64_android.h
index d732032d1f..ce08346b70 100644
--- a/include/configs/meson64_android.h
+++ b/include/configs/meson64_android.h
@@ -21,6 +21,10 @@
 #define CONTROL_PARTITION "misc"
 #endif
 
+#ifndef RECOVERY_PARTITION
+#define RECOVERY_PARTITION "recovery"
+#endif
+
 #define BOOTENV_DEV_FASTBOOT(devtypeu, devtypel, instance) \
"bootcmd_fastboot=" \
"setenv run_fastboot 0;" \
@@ -51,20 +55,23 @@
 #define BOOTENV_DEV_NAME_FASTBOOT(devtypeu, devtypel, instance)\
"fastboot "
 
-/* TOFIX: Run actual recovery instead of fastboot */
 #define BOOTENV_DEV_RECOVERY(devtypeu, devtypel, instance) \
"bootcmd_recovery=" \
"pinmux dev pinctrl@14;" \
"pinmux dev pinctrl@40;" \
-   "sm reboot_reason reason;" \
"setenv run_recovery 0;" \
"if run check_button; then " \
"echo Recovery button is pressed;" \
"setenv run_recovery 1;" \
-   "elif test \"${reason}\" = \"recovery\" -o " \
- "\"${reason}\" = \"update\"; then " \
-   "echo Recovery asked by reboot reason;" \
-   "setenv run_recovery 1;" \
+   "fi; " \
+   "if bcb load " __stringify(CONFIG_FASTBOOT_FLASH_MMC_DEV) " " \
+   CONTROL_PARTITION "; then " \
+   "if bcb test command = boot-recovery; then " \
+   "echo BCB: Recovery boot...; " \
+   "setenv run_recovery 1;" \
+   "fi;" \
+   "else " \
+   "echo Warning: BCB is corrupted or does not exist; " \
"fi;" \
"if test \"${skip_recovery}\" -eq 1; then " \
"echo Recovery skipped by environment;" \
@@ -76,7 +83,16 @@
"fi;" \
"if test \"${run_recovery}\" -eq 1; then " \
"echo Running Recovery...;" \
-   "fastboot " __stringify(CONFIG_FASTBOOT_USB_DEV) "; " \
+   "mmc dev ${mmcdev};" \
+   "setenv bootargs \"${bootargs} 
androidboot.serialno=${serial#}\";" \
+   "part start mmc ${mmcdev} " RECOVERY_PARTITION " 
boot_start;" \
+   "part size mmc ${mmcdev} " RECOVERY_PARTITION " 
boot_size;" \
+   "if mmc read ${loadaddr} ${boot_start} ${boot_size}; 
then " \
+   "echo Running Android Recovery...;" \
+   "bootm ${loadaddr};" \
+   "fi;" \
+   "echo Failed to boot Android...;" \
+   "reset;" \
"fi\0"
 
 #define BOOTENV_DEV_NAME_RECOVERY(devtypeu, devtypel, instance)\
-- 
2.30.2

[PATCH 5/5] configs: sei610/sei510: set CONFIG_CMD_BCB=y

[Mattijs Korpershoek]

SEI-610 and SEI-510 are both for Android boards based on Yukawa[1]

Enable the BCB command to enable the standard Android boot flow.

[1] https://android.googlesource.com/device/amlogic/yukawa/
Signed-off-by: Mattijs Korpershoek 
---
 configs/sei510_defconfig | 1 +
 configs/sei610_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/sei510_defconfig b/configs/sei510_defconfig
index 63b3043a15..74328f2fd4 100644
--- a/configs/sei510_defconfig
+++ b/configs/sei510_defconfig
@@ -22,6 +22,7 @@ CONFIG_PREBOOT="run load_logo"
 CONFIG_MISC_INIT_R=y
 # CONFIG_CMD_BDI is not set
 # CONFIG_CMD_IMI is not set
+CONFIG_CMD_BCB=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 # CONFIG_CMD_LOADS is not set
diff --git a/configs/sei610_defconfig b/configs/sei610_defconfig
index 56f136ed96..2a6d0e5995 100644
--- a/configs/sei610_defconfig
+++ b/configs/sei610_defconfig
@@ -22,6 +22,7 @@ CONFIG_PREBOOT="run load_logo"
 CONFIG_MISC_INIT_R=y
 # CONFIG_CMD_BDI is not set
 # CONFIG_CMD_IMI is not set
+CONFIG_CMD_BCB=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 # CONFIG_CMD_LOADS is not set
-- 
2.30.2

[PATCH 2/5] configs: meson64_android: use BCB for reboot to bootloader

[Mattijs Korpershoek]

As of today, we use a "vendor specific" secure monitor call for the
reboot reason (sm).

We should not need this. Android uses the BCB (Bootloader Control Block)
to communicate with the bootloader.

Implement "reboot into bootloader" using the standard BCB way instead of
using sm calls.

Signed-off-by: Mattijs Korpershoek 
---
 include/configs/meson64_android.h | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/include/configs/meson64_android.h 
b/include/configs/meson64_android.h
index 3b61d5f703..d732032d1f 100644
--- a/include/configs/meson64_android.h
+++ b/include/configs/meson64_android.h
@@ -17,9 +17,12 @@
 #define LOGO_PARTITION "logo"
 #endif
 
+#ifndef CONTROL_PARTITION
+#define CONTROL_PARTITION "misc"
+#endif
+
 #define BOOTENV_DEV_FASTBOOT(devtypeu, devtypel, instance) \
"bootcmd_fastboot=" \
-   "sm reboot_reason reason;" \
"setenv run_fastboot 0;" \
"if test \"${boot_source}\" = \"usb\"; then " \
"echo Fastboot forced by usb rom boot;" \
@@ -30,18 +33,15 @@
"echo Broken MMC partition scheme;" \
"setenv run_fastboot 1;" \
"fi;" \
-   "if test \"${reason}\" = \"bootloader\" -o " \
-   "\"${reason}\" = \"fastboot\"; then " \
-   "echo Fastboot asked by reboot reason;" \
-   "setenv run_fastboot 1;" \
-   "fi;" \
-   "if test \"${skip_fastboot}\" -eq 1; then " \
-   "echo Fastboot skipped by environment;" \
-   "setenv run_fastboot 0;" \
-   "fi;" \
-   "if test \"${force_fastboot}\" -eq 1; then " \
-   "echo Fastboot forced by environment;" \
-   "setenv run_fastboot 1;" \
+   "if bcb load " __stringify(CONFIG_FASTBOOT_FLASH_MMC_DEV) " " \
+   CONTROL_PARTITION "; then " \
+   "if bcb test command = bootonce-bootloader; then " \
+   "echo BCB: Bootloader boot...; " \
+   "bcb clear command; bcb store; " \
+   "setenv run_fastboot 1;" \
+   "fi; " \
+   "else " \
+   "echo Warning: BCB is corrupted or does not exist; " \
"fi;" \
"if test \"${run_fastboot}\" -eq 1; then " \
"echo Running Fastboot...;" \
-- 
2.30.2

[PATCH 4/5] configs: meson64_android: reboot to fastbootd from bootloader

[Mattijs Korpershoek]

Whenever we test for boot-fastboot in the BCB, it means that Android
wants us to boot into recovery with a special mode (fastbootd).

Force reboot into recovery in that case.

Note: we don't erase the bcb on purpose here: recoveryOS needs to read
the BCB as well to know if it boots into regular recovery mode or
fastbootd mode.

Signed-off-by: Mattijs Korpershoek 
---
 include/configs/meson64_android.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/configs/meson64_android.h 
b/include/configs/meson64_android.h
index ce08346b70..f9f2b26416 100644
--- a/include/configs/meson64_android.h
+++ b/include/configs/meson64_android.h
@@ -44,6 +44,10 @@
"bcb clear command; bcb store; " \
"setenv run_fastboot 1;" \
"fi; " \
+   "if bcb test command = boot-fastboot; then " \
+   "echo BCB: fastboot userspace boot...; " \
+   "setenv force_recovery 1;" \
+   "fi; " \
"else " \
"echo Warning: BCB is corrupted or does not exist; " \
"fi;" \
-- 
2.30.2

[PATCH 1/5] Revert "ARM: meson: Add support for fastboot_set_reboot_flag()"

[Mattijs Korpershoek]

With the introduction of a generic reboot flag implemented in commit
a362ce214f ("fastboot: Implement generic fastboot_set_reboot_flag"), we
no longer need the custom PSCI implementation to handle the reboot reason.

This reverts commit 9a34dedfae0ebb031a45324c2fed8c39b2c6fcf2.

Signed-off-by: Mattijs Korpershoek 
---
 arch/arm/mach-meson/board-common.c | 34 --
 1 file changed, 34 deletions(-)

diff --git a/arch/arm/mach-meson/board-common.c 
b/arch/arm/mach-meson/board-common.c
index 1690b6b1e6..7ceba7cede 100644
--- a/arch/arm/mach-meson/board-common.c
+++ b/arch/arm/mach-meson/board-common.c
@@ -22,10 +22,7 @@
 #include 
 #include 
 
-#if CONFIG_IS_ENABLED(FASTBOOT)
 #include 
-#include 
-#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -152,38 +149,7 @@ int board_late_init(void)
return meson_board_late_init();
 }
 
-#if CONFIG_IS_ENABLED(FASTBOOT)
-static unsigned int reboot_reason = REBOOT_REASON_NORMAL;
-
-int fastboot_set_reboot_flag(enum fastboot_reboot_reason reason)
-{
-   if (reason != FASTBOOT_REBOOT_REASON_BOOTLOADER)
-   return -ENOTSUPP;
-
-   reboot_reason = REBOOT_REASON_BOOTLOADER;
-
-   printf("Using reboot reason: 0x%x\n", reboot_reason);
-
-   return 0;
-}
-
-void reset_cpu(void)
-{
-   struct pt_regs regs;
-
-   regs.regs[0] = ARM_PSCI_0_2_FN_SYSTEM_RESET;
-   regs.regs[1] = reboot_reason;
-
-   printf("Rebooting with reason: 0x%lx\n", regs.regs[1]);
-
-   smc_call(®s);
-
-   while (1)
-   ;
-}
-#else
 void reset_cpu(void)
 {
psci_system_reset();
 }
-#endif
-- 
2.30.2

[PATCH 0/5] meson64_android: use BCB for reboot reason

[Mattijs Korpershoek]

The SEI-610 and SEI-510 boards are well supported in the
Android Open Source project via the yukawa [1] platform.

Their U-Boot version, despite being public [2] is not in mainline.

Android has multiple OSes it can boot into:
* Main android
* Recovery OS
* Fastbootd (recovery OS with fastboot mode)
* Bootloader (U-Boot) with fastboot mode

The decision of which OS to boot into is taken by the bootloader based on
the "reboot reason".

For amlogic boards, we pass the reboot reason via a custom smc call.
This support is limited: we don't r

These series reworks the reboot reason handling to use the BCB, which
is the standard Android way.

[1] https://android.googlesource.com/device/amlogic/yukawa
[2] https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ

Mattijs Korpershoek (5):
  Revert "ARM: meson: Add support for fastboot_set_reboot_flag()"
  configs: meson64_android: use BCB for reboot to bootloader
  configs: meson64_android: implement recovery boot via BCB
  configs: meson64_android: reboot to fastbootd from bootloader
  configs: sei610/sei510: set CONFIG_CMD_BCB=y

 arch/arm/mach-meson/board-common.c | 34 -
 configs/sei510_defconfig   |  1 +
 configs/sei610_defconfig   |  1 +
 include/configs/meson64_android.h  | 60 --
 4 files changed, 42 insertions(+), 54 deletions(-)

-- 
2.30.2

Re: [PATCH v2 2/2] mtd: spi-nor: Mask out fast read if not requested in DT

[Bin Meng]

Hi Pratyush,

On Fri, Jul 30, 2021 at 3:31 PM Pratyush Yadav  wrote:
>
> On 30/07/21 03:20PM, Bin Meng wrote:
> > The DT bindings of "jedec,spi-nor" [1] defines "m25p,fast-read" property
> > to indicate that "fast read" opcode can be used to read data from the
> > chip instead of the usual "read" opcode.
> >
> > If this property is not present in DT, mask out fast read in
> > spi_nor_init_params(). This change mirrors the same logic in
> > spi_nor_info_init_params() in drivers/mtd/spi-nor/core.c in
> > the Linux kernel v5.14-rc3.
> >
> > [1] Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml in the kernel 
> > tree
> >
> > Signed-off-by: Bin Meng 
> >
> > ---
> >
> > Changes in v2:
> > - Guard changes with CONFIG_IS_ENABLED(DM_SPI)
>
> Hehe, I just commented about this on your v1, and I see the v2 in my
> inbox already ;-)
>
> So this will make sure that dev_ofnode() will be valid, right?

This is to avoid build error for non-DM_SPI platforms.

For dev_ofnode() I think it's always valid, as spi_nor_init_params()
is called by spi_nor_scan() in sf_probe.c which does not support
OF_PLATDATA.

>
> >
> >  drivers/mtd/spi/spi-nor-core.c | 16 +---
> >  1 file changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> > index c8c3bdd890..d5d905fa5a 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -2604,18 +2604,28 @@ static int spi_nor_init_params(struct spi_nor *nor,
> >   params->size = info->sector_size * info->n_sectors;
> >   params->page_size = info->page_size;
> >
> > + if (!(info->flags & SPI_NOR_NO_FR)) {
> > + /* Default to Fast Read for DT and non-DT platform devices. */
> > + params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
> > +
> > + /* Mask out Fast Read if not requested at DT instantiation. */
> > +#if CONFIG_IS_ENABLED(DM_SPI)
> > + if (!ofnode_read_bool(dev_ofnode(nor->spi->dev),
>
> Let's avoid the #if here and do
>
>   if (CONFIG_IS_ENABLED(DM_SPI) && !ofnode_read_bool())

This does not work because nor->spi->dev has to be inside
CONFIG_IS_ENABLED(DM_SPI) as well.

>
> > +   "m25p,fast-read"))
> > + params->hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
> > +#endif
> > + }
> > +
> >   /* (Fast) Read settings. */
> >   params->hwcaps.mask |= SNOR_HWCAPS_READ;
> >   spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ],
> > 0, 0, SPINOR_OP_READ,
> > SNOR_PROTO_1_1_1);
> >
> > - if (!(info->flags & SPI_NOR_NO_FR)) {
> > - params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
> > + if (params->hwcaps.mask & SNOR_HWCAPS_READ_FAST)
> >   spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_FAST],
> > 0, 8, SPINOR_OP_READ_FAST,
> > SNOR_PROTO_1_1_1);
> > - }
> >
> >   if (info->flags & SPI_NOR_DUAL_READ) {
> >   params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_2;
>

Regards,
Bin

Re: [PATCH v2 2/2] mtd: spi-nor: Mask out fast read if not requested in DT

[Pratyush Yadav]

On 30/07/21 03:20PM, Bin Meng wrote:
> The DT bindings of "jedec,spi-nor" [1] defines "m25p,fast-read" property
> to indicate that "fast read" opcode can be used to read data from the
> chip instead of the usual "read" opcode.
> 
> If this property is not present in DT, mask out fast read in
> spi_nor_init_params(). This change mirrors the same logic in
> spi_nor_info_init_params() in drivers/mtd/spi-nor/core.c in
> the Linux kernel v5.14-rc3.
> 
> [1] Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml in the kernel 
> tree
> 
> Signed-off-by: Bin Meng 
> 
> ---
> 
> Changes in v2:
> - Guard changes with CONFIG_IS_ENABLED(DM_SPI)

Hehe, I just commented about this on your v1, and I see the v2 in my 
inbox already ;-)

So this will make sure that dev_ofnode() will be valid, right?

> 
>  drivers/mtd/spi/spi-nor-core.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index c8c3bdd890..d5d905fa5a 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -2604,18 +2604,28 @@ static int spi_nor_init_params(struct spi_nor *nor,
>   params->size = info->sector_size * info->n_sectors;
>   params->page_size = info->page_size;
>  
> + if (!(info->flags & SPI_NOR_NO_FR)) {
> + /* Default to Fast Read for DT and non-DT platform devices. */
> + params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
> +
> + /* Mask out Fast Read if not requested at DT instantiation. */
> +#if CONFIG_IS_ENABLED(DM_SPI)
> + if (!ofnode_read_bool(dev_ofnode(nor->spi->dev),

Let's avoid the #if here and do

  if (CONFIG_IS_ENABLED(DM_SPI) && !ofnode_read_bool())

> +   "m25p,fast-read"))
> + params->hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
> +#endif
> + }
> +
>   /* (Fast) Read settings. */
>   params->hwcaps.mask |= SNOR_HWCAPS_READ;
>   spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ],
> 0, 0, SPINOR_OP_READ,
> SNOR_PROTO_1_1_1);
>  
> - if (!(info->flags & SPI_NOR_NO_FR)) {
> - params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
> + if (params->hwcaps.mask & SNOR_HWCAPS_READ_FAST)
>   spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_FAST],
> 0, 8, SPINOR_OP_READ_FAST,
> SNOR_PROTO_1_1_1);
> - }
>  
>   if (info->flags & SPI_NOR_DUAL_READ) {
>   params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_2;

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH 2/2] mtd: spi-nor: Mask out fast read if not requested in DT

[Pratyush Yadav]

Hi Bin,

On 29/07/21 07:58PM, Bin Meng wrote:
> The DT bindings of "jedec,spi-nor" [1] defines "m25p,fast-read" property
> to indicate that "fast read" opcode can be used to read data from the
> chip instead of the usual "read" opcode.
> 
> If this property is not present in DT, mask out fast read in
> spi_nor_init_params(). This change mirrors the same logic in
> spi_nor_info_init_params() in drivers/mtd/spi-nor/core.c in
> the Linux kernel v5.14-rc3.
> 
> [1] Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml in the kernel 
> tree
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  drivers/mtd/spi/spi-nor-core.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 2883d092fc..d6a0ed39c5 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -2597,6 +2597,8 @@ static int spi_nor_init_params(struct spi_nor *nor,
>  const struct flash_info *info,
>  struct spi_nor_flash_parameter *params)
>  {
> + struct spi_slave *spi = nor->spi;
> +
>   /* Set legacy flash parameters as default. */
>   memset(params, 0, sizeof(*params));
>  
> @@ -2604,18 +2606,25 @@ static int spi_nor_init_params(struct spi_nor *nor,
>   params->size = info->sector_size * info->n_sectors;
>   params->page_size = info->page_size;
>  
> + if (!(info->flags & SPI_NOR_NO_FR)) {
> + /* Default to Fast Read for DT and non-DT platform devices. */
> + params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
> +
> + /* Mask out Fast Read if not requested at DT instantiation. */
> + if (!ofnode_read_bool(dev_ofnode(spi->dev), "m25p,fast-read"))

Do you need to check if dev_ofnode() is valid? Can spi-nor be 
instantiated from a non-DT platform (like platdata maybe)? I am not very 
familiar with DT/platdata stuff, other than the basics.

> + params->hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
> + }
> +
>   /* (Fast) Read settings. */
>   params->hwcaps.mask |= SNOR_HWCAPS_READ;
>   spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ],
> 0, 0, SPINOR_OP_READ,
> SNOR_PROTO_1_1_1);
>  
> - if (!(info->flags & SPI_NOR_NO_FR)) {
> - params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
> + if (params->hwcaps.mask & SNOR_HWCAPS_READ_FAST)
>   spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_FAST],
> 0, 8, SPINOR_OP_READ_FAST,
> SNOR_PROTO_1_1_1);
> - }

The patch looks good to me other than the point above.

>  
>   if (info->flags & SPI_NOR_DUAL_READ) {
>   params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_2;
> -- 
> 2.25.1
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

[PATCH v2 2/2] mtd: spi-nor: Mask out fast read if not requested in DT

[Bin Meng]

The DT bindings of "jedec,spi-nor" [1] defines "m25p,fast-read" property
to indicate that "fast read" opcode can be used to read data from the
chip instead of the usual "read" opcode.

If this property is not present in DT, mask out fast read in
spi_nor_init_params(). This change mirrors the same logic in
spi_nor_info_init_params() in drivers/mtd/spi-nor/core.c in
the Linux kernel v5.14-rc3.

[1] Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml in the kernel tree

Signed-off-by: Bin Meng 

---

Changes in v2:
- Guard changes with CONFIG_IS_ENABLED(DM_SPI)

 drivers/mtd/spi/spi-nor-core.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index c8c3bdd890..d5d905fa5a 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -2604,18 +2604,28 @@ static int spi_nor_init_params(struct spi_nor *nor,
params->size = info->sector_size * info->n_sectors;
params->page_size = info->page_size;
 
+   if (!(info->flags & SPI_NOR_NO_FR)) {
+   /* Default to Fast Read for DT and non-DT platform devices. */
+   params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
+
+   /* Mask out Fast Read if not requested at DT instantiation. */
+#if CONFIG_IS_ENABLED(DM_SPI)
+   if (!ofnode_read_bool(dev_ofnode(nor->spi->dev),
+ "m25p,fast-read"))
+   params->hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
+#endif
+   }
+
/* (Fast) Read settings. */
params->hwcaps.mask |= SNOR_HWCAPS_READ;
spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ],
  0, 0, SPINOR_OP_READ,
  SNOR_PROTO_1_1_1);
 
-   if (!(info->flags & SPI_NOR_NO_FR)) {
-   params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
+   if (params->hwcaps.mask & SNOR_HWCAPS_READ_FAST)
spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_FAST],
  0, 8, SPINOR_OP_READ_FAST,
  SNOR_PROTO_1_1_1);
-   }
 
if (info->flags & SPI_NOR_DUAL_READ) {
params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_2;
-- 
2.25.1

[PATCH v2 1/2] mtd: spi-nor: Respect flash's hwcaps in spi_nor_adjust_hwcaps()

[Bin Meng]

The smart spi_nor_adjust_hwcaps() does not respect the SPI flash's
hwcaps, and only looks to the controller on what can be supported.

The flash's hwcaps needs to be AND'ed before checking.

Fixes: 71025f013ccb ("mtd: spi-nor-core: Rework hwcaps selection")
Signed-off-by: Bin Meng 
Reviewed-by: Pratyush Yadav 

---

Changes in v2:
- Update comments per Pratyush's review

 drivers/mtd/spi/spi-nor-core.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 99e2f16349..c8c3bdd890 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -2858,10 +2858,11 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor,
unsigned int cap;
 
/*
-* Enable all caps by default. We will mask them after checking what's
-* really supported using spi_mem_supports_op().
+* Start by assuming the controller supports every capability.
+* We will mask them after checking what's really supported
+* using spi_mem_supports_op().
 */
-   *hwcaps = SNOR_HWCAPS_ALL;
+   *hwcaps = SNOR_HWCAPS_ALL & params->hwcaps.mask;
 
/* X-X-X modes are not supported yet, mask them all. */
*hwcaps &= ~SNOR_HWCAPS_X_X_X;
-- 
2.25.1