Re: [PATCH v2 1/9] mmc: sandbox: Add support for writing

[Lukasz Majewski]

Hi Sean,

> This adds support writing to the sandbox mmc backed by an in-memory
> buffer. The unit test has been updated to test reading, writing, and
> erasing. I'm not sure what MMCs erase to; I picked 0, but if it's 0xFF
> then that can be easily changed.

Could you rebase this patch series on top of:
https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/commits/master

I've encountered some conflicts with previous patches.

(And of course sorry for trouble - this patch series is the last one
with the pile I've got for USB/DFU).

Thanks in advance.

> 
> Signed-off-by: Sean Anderson 
> Reviewed-by: Simon Glass 
> ---
> 
> (no changes since v1)
> 
>  drivers/mmc/sandbox_mmc.c | 41
> ++- test/dm/mmc.c |
> 19 +- 2 files changed, 50 insertions(+), 10
> deletions(-)
> 
> diff --git a/drivers/mmc/sandbox_mmc.c b/drivers/mmc/sandbox_mmc.c
> index e86ea8fe09..3daf708451 100644
> --- a/drivers/mmc/sandbox_mmc.c
> +++ b/drivers/mmc/sandbox_mmc.c
> @@ -17,6 +17,17 @@ struct sandbox_mmc_plat {
>   struct mmc mmc;
>  };
>  
> +#define MMC_CSIZE 0
> +#define MMC_CMULT 8 /* 8 because the card is high-capacity */
> +#define MMC_BL_LEN_SHIFT 10
> +#define MMC_BL_LEN BIT(MMC_BL_LEN_SHIFT)
> +#define MMC_CAPACITY (((MMC_CSIZE + 1) << (MMC_CMULT + 2)) \
> +   * MMC_BL_LEN) /* 1 MiB */
> +
> +struct sandbox_mmc_priv {
> + u8 buf[MMC_CAPACITY];
> +};
> +
>  /**
>   * sandbox_mmc_send_cmd() - Emulate SD commands
>   *
> @@ -26,6 +37,10 @@ struct sandbox_mmc_plat {
>  static int sandbox_mmc_send_cmd(struct udevice *dev, struct mmc_cmd
> *cmd, struct mmc_data *data)
>  {
> + struct sandbox_mmc_priv *priv = dev_get_priv(dev);
> + struct mmc *mmc = mmc_get_mmc_dev(dev);
> + static ulong erase_start, erase_end;
> +
>   switch (cmd->cmdidx) {
>   case MMC_CMD_ALL_SEND_CID:
>   memset(cmd->response, '\0', sizeof(cmd->response));
> @@ -44,8 +59,9 @@ static int sandbox_mmc_send_cmd(struct udevice
> *dev, struct mmc_cmd *cmd, break;
>   case MMC_CMD_SEND_CSD:
>   cmd->response[0] = 0;
> - cmd->response[1] = 10 << 16;/* 1 <<
> block_len */
> - cmd->response[2] = 0;
> + cmd->response[1] = (MMC_BL_LEN_SHIFT << 16) |
> +((MMC_CSIZE >> 16) & 0x3f);
> + cmd->response[2] = (MMC_CSIZE & 0x) << 16;
>   cmd->response[3] = 0;
>   break;
>   case SD_CMD_SWITCH_FUNC: {
> @@ -59,13 +75,27 @@ static int sandbox_mmc_send_cmd(struct udevice
> *dev, struct mmc_cmd *cmd, break;
>   }
>   case MMC_CMD_READ_SINGLE_BLOCK:
> - memset(data->dest, '\0', data->blocksize);
> - break;
>   case MMC_CMD_READ_MULTIPLE_BLOCK:
> - strcpy(data->dest, "this is a test");
> + memcpy(data->dest, >buf[cmd->cmdarg *
> data->blocksize],
> +data->blocks * data->blocksize);
> + break;
> + case MMC_CMD_WRITE_SINGLE_BLOCK:
> + case MMC_CMD_WRITE_MULTIPLE_BLOCK:
> + memcpy(>buf[cmd->cmdarg * data->blocksize],
> data->src,
> +data->blocks * data->blocksize);
>   break;
>   case MMC_CMD_STOP_TRANSMISSION:
>   break;
> + case SD_CMD_ERASE_WR_BLK_START:
> + erase_start = cmd->cmdarg;
> + break;
> + case SD_CMD_ERASE_WR_BLK_END:
> + erase_end = cmd->cmdarg;
> + break;
> + case MMC_CMD_ERASE:
> + memset(>buf[erase_start * mmc->write_bl_len],
> '\0',
> +(erase_end - erase_start + 1) *
> mmc->write_bl_len);
> + break;
>   case SD_CMD_APP_SEND_OP_COND:
>   cmd->response[0] = OCR_BUSY | OCR_HCS;
>   cmd->response[1] = 0;
> @@ -148,5 +178,6 @@ U_BOOT_DRIVER(mmc_sandbox) = {
>   .bind   = sandbox_mmc_bind,
>   .unbind = sandbox_mmc_unbind,
>   .probe  = sandbox_mmc_probe,
> + .priv_auto_alloc_size = sizeof(struct sandbox_mmc_priv),
>   .platdata_auto_alloc_size = sizeof(struct sandbox_mmc_plat),
>  };
> diff --git a/test/dm/mmc.c b/test/dm/mmc.c
> index 4e5136c850..f744452ff2 100644
> --- a/test/dm/mmc.c
> +++ b/test/dm/mmc.c
> @@ -29,16 +29,25 @@ static int dm_test_mmc_blk(struct unit_test_state
> *uts) {
>   struct udevice *dev;
>   struct blk_desc *dev_desc;
> - char cmp[1024];
> + int i;
> + char write[1024], read[1024];
>  
>   ut_assertok(uclass_get_device(UCLASS_MMC, 0, ));
>   ut_assertok(blk_get_device_by_str("mmc", "0", _desc));
>  
> - /* Read a few blocks and look for the string we expect */
> + /* Write a few blocks and verify that we get the same data
> back */ ut_asserteq(512, dev_desc->blksz);
> - memset(cmp, '\0', sizeof(cmp));
> - ut_asserteq(2, blk_dread(dev_desc, 0, 2, cmp));
> - ut_assertok(strcmp(cmp, "this is a test"));
> + for (i = 0; i < 

Re: [PATCH] fastboot: add UUU command UCmd and ACmd support

[Lukasz Majewski]

Hi Heiko,

> Hello Roman,
> 
> Am 27.01.21 um 10:34 schrieb Roman Stratiienko:
> > Hello Heiko,
> > 
> > Looks like these commands will provide full access to any u-boot
> > commands, including working with memory.
> > It can be used to read/set any registers/data which is not in the
> > trust zone, thus opening a huge backdoor.
> > 
> > This command could be useful for debug/CI purposes, but do you
> > really want this in release builds?  
> 
> Hmm.. indeed.
> 
> I set the default to no not to yes, so you need
> to enable it, and add a comment in Kconfig.

Do you plan to send another version of this patch? Or is it ready for
being pull?

> 
> Thanks!
> 
> bye,
> Heiko
> > 
> > Best regards,
> > Roman
> > 
> > пн, 11 янв. 2021 г. в 12:19, Heiko Schocher :  
> >>
> >> add support for the UUU commands ACmd and UCmd.
> >>
> >> Enable them through the Kconfig option
> >> CONFIG_FASTBOOT_UUU_SUPPORT
> >>
> >> base was commit in NXP kernel
> >> 9b149c2a2882: ("MLK-18591-3 android: Add FSL android fastboot
> >> support")
> >>
> >> and ported it to current mainline. Tested this patch
> >> on imx6ul based board.
> >>
> >> Signed-off-by: Heiko Schocher 
> >> ---
> >> azure build:
> >> https://dev.azure.com/hs0298/hs/_build/results?buildId=57=results
> >>
> >> version uuu tool used for tests:
> >> commit 3870fb781b35: ("fastboot: default to logical-block-size
> >> 4096")
> >>
> >>  doc/android/fastboot-protocol.rst |  5 +++
> >>  doc/android/fastboot.rst  |  2 +
> >>  drivers/fastboot/Kconfig  |  7 
> >>  drivers/fastboot/fb_command.c | 62
> >> +++ drivers/usb/gadget/f_fastboot.c
> >> | 17 + include/fastboot.h|  7 
> >>  6 files changed, 100 insertions(+)
> >>
> >> diff --git a/doc/android/fastboot-protocol.rst
> >> b/doc/android/fastboot-protocol.rst index e723659e49c..e8cbd7f24ea
> >> 100644 --- a/doc/android/fastboot-protocol.rst
> >> +++ b/doc/android/fastboot-protocol.rst
> >> @@ -144,6 +144,11 @@ Command Reference
> >>
> >>"powerdown"  Power off the device.
> >>
> >> +  "ucmd"   execute any bootloader command and wait
> >> until it
> >> +   finishs.
> >> +
> >> +  "acmd"   execute any bootloader command, do not
> >> wait. +
> >>  Client Variables
> >>  
> >>
> >> diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
> >> index 2877c3cbaaa..b58d1b5b31a 100644
> >> --- a/doc/android/fastboot.rst
> >> +++ b/doc/android/fastboot.rst
> >> @@ -19,6 +19,8 @@ The current implementation supports the
> >> following standard commands:
> >>  - ``reboot``
> >>  - ``reboot-bootloader``
> >>  - ``set_active`` (only a stub implementation which always
> >> succeeds) +- ``ucmd`` (if enabled)
> >> +- ``acmd`` (if enabled)
> >>
> >>  The following OEM commands are supported (if enabled):
> >>
> >> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
> >> index 4352ba67a71..b1f8cd74a15 100644
> >> --- a/drivers/fastboot/Kconfig
> >> +++ b/drivers/fastboot/Kconfig
> >> @@ -72,6 +72,13 @@ config FASTBOOT_FLASH
> >>   the downloaded image to a non-volatile storage device.
> >> Define this to enable the "fastboot flash" command.
> >>
> >> +config FASTBOOT_UUU_SUPPORT
> >> +   bool "Enable FASTBOOT i.MX UUU special command"
> >> +   default y if ARCH_MX7 || ARCH_MX6 || ARCH_IMX8 ||
> >> ARCH_IMX8M || ARCH_MX7ULP
> >> +   select FSL_FASTBOOT
> >> +   help
> >> + The fastboot protocol includes "UCmd" command and "ACmd"
> >> command +
> >>  choice
> >> prompt "Flash provider for FASTBOOT"
> >> depends on FASTBOOT_FLASH
> >> diff --git a/drivers/fastboot/fb_command.c
> >> b/drivers/fastboot/fb_command.c index d3c578672dc..31a47e46386
> >> 100644 --- a/drivers/fastboot/fb_command.c
> >> +++ b/drivers/fastboot/fb_command.c
> >> @@ -43,6 +43,11 @@ static void reboot_recovery(char *, char *);
> >>  static void oem_format(char *, char *);
> >>  #endif
> >>
> >> +#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
> >> +static void run_ucmd(char *, char *);
> >> +static void run_acmd(char *, char *);
> >> +#endif
> >> +
> >>  static const struct {
> >> const char *command;
> >> void (*dispatch)(char *cmd_parameter, char *response);
> >> @@ -99,6 +104,16 @@ static const struct {
> >> .dispatch = oem_format,
> >> },
> >>  #endif
> >> +#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
> >> +   [FASTBOOT_COMMAND_UCMD] = {
> >> +   .command = "UCmd",
> >> +   .dispatch = run_ucmd,
> >> +   },
> >> +   [FASTBOOT_COMMAND_ACMD] = {
> >> +   .command = "ACmd",
> >> +   .dispatch = run_acmd,
> >> +   },
> >> +#endif
> >>  };
> >>
> >>  /**
> >> @@ -309,6 +324,53 @@ static void erase(char *cmd_parameter, char
> >> *response) }
> >>  #endif
> >>
> >> +#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
> >> +/**
> >> + * run_ucmd() - Execute the UCmd command

Re: Xilinx ZynqMP SPL boot: psu_init_gpl.c code corrupts U-Boot memory

[Michal Simek]

Hi,

On 1/30/21 5:52 AM, Sean Anderson wrote:
> On 1/21/21 3:41 AM, Michal Simek wrote:
>> Hi,
>>
>> On 1/20/21 9:25 PM, Robert Hancock wrote:
>>> I've been trying to get the U-Boot SPL to work on a Xilinx ZCU102
>>> development board. I have been testing with U-Boot 2021.01, and using
>>> the generated psu_init_gpl HW initialization code generated by Vivado
>>> 2020.2, rather than the versions in the U-Boot tree, as we are
>>> expecting to make changes to the configuration as we move to our own
>>> board design.
>>>
>>> The issue I was seeing is that the SPL seemingly locking up or crashing
>>> early in the boot process, just after the SPL banner was printed. I've
>>> CCed "Major A" as he reported something similar on the mailing list in
>>> March ('ZynqMP boot: no messages from SPL other than "Debug uart
>>> enabled"') but I didn't see a resoution posted.
>>>
>>> After groveling around with the Xilinx JTAG debugger for a day or so, I
>>> figured out that the problem was that the SPL ended up reading from an
>>> invalid pointer address somewhere during the driver model
>>> initialization process, and crashing. After using memory watchpoints to
>>> identify where the bogus value was being written to the pointer storage
>>> location, the memory write was actually coming from the Vivado 2020.2-
>>> generated psu_init_gpl code. The offending code is in a function called
>>> serdes_illcalib_pcie_gen1 and looks like this:
>>>
>>>    if (gen2_calib != 1)
>>>    {
>>>  ill1_val[loop] = ((0x04 + meancount[loop]*8) % 0x100);
>>>  ill12_val[loop] = ((0x04 + meancount[loop]*8) >= 0x100) ?
>>> 0x10 : 0x00;
>>>  Xil_Out32(0xFFFE+loop*4,iterresult[loop]);
>>>  Xil_Out32(0xFFFE0010+loop*4,iterresult[loop+4]);
>>>  Xil_Out32(0xFFFE0020+loop*4,bistpasscount[loop]);
>>>  Xil_Out32(0xFFFE0030+loop*4,meancount[loop]);
>>>    }
>>>    if (gen2_calib == 1)
>>>    {
>>>  ill1_val[loop] = ((0x104 + meancount[loop]*8) % 0x100);
>>>  ill12_val[loop] = ((0x104 + meancount[loop]*8) >= 0x200) ?
>>> 0x02 : 0x01;
>>>  Xil_Out32(0xFFFE0040+loop*4,iterresult[loop]);
>>>  Xil_Out32(0xFFFE0050+loop*4,iterresult[loop+4]);
>>>  Xil_Out32(0xFFFE0060+loop*4,bistpasscount[loop]);
>>>  Xil_Out32(0xFFFE0070+loop*4,meancount[loop]);
>>>    }
>>>
>>> Those writes to 0xFFFE are to on-chip memory addresses, not any
>>> hardware register, so I have no idea what this is trying to achieve.
>>> Possibly this is some debug code to store some calibration results that
>>> was left in by mistake? Those addresses may not be used in the Xilinx
>>> FSBL, but overwriting them in the U-Boot SPL wreaks havoc.
>>>
>>> For now, I've worked around it by hacking the Xil_Out32 implementation
>>> provided by U-Boot in board/xilinx/zynqmp/xil_io.h to trap and ignore
>>> writes to memory addresses in the OCRAM range (0xFFFC to
>>> 0x). With that in place, things seem to be working. Probably
>>> this should be addressed in the Vivado psu_init code generator, but we
>>> may need some workaround like this to avoid those using the affected
>>> Xilinx tool versions from hitting this issue?
>>>
>>
>> I can't see any code like this in u-boot code. I can't see context of
>> this code that's why simply don't know what it does and why.
> 
> I believe it's to fix [1]. See [2] for other people with this problem.
> I'm not sure what Xilinx's stance on this behavior is.
> 
> --Sean
> 
> [1] https://www.xilinx.com/support/answers/72992.html
> [2]
> https://forums.xilinx.com/t5/Embedded-Development-Tools/Custom-zcu102-2020-1-SATA-link-down-SStatus-1-SControl-330/td-p/1143816
> 

I have let support team know about this but this is topic out of u-boot
mailing list because we simply don't have any code like this in the repo.
And it is just showing good decision to store psu_inits in u-boot repo
not to relay on specific design tool version.

Thanks,
Michal

Re: [PATCH] x86: Reduce size of samus image

[Bin Meng]

On Mon, Feb 1, 2021 at 2:18 PM Bin Meng  wrote:
>
> On Mon, Feb 1, 2021 at 12:17 AM Simon Glass  wrote:
> >
> > With the recent addition of ACPI generation, the image size has got beyond
> > its current limit.
> >
> > Samus does not actually use this, nor x86 emulation for PCI ROMs, so
> > disable both features.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  configs/chromebook_samus_defconfig | 1 +
> >  include/configs/chromebook_samus.h | 3 +++
> >  2 files changed, 4 insertions(+)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!

Re: [PATCH v3 11/12] x86: coral: Add sysinfo ops

[Bin Meng]

On Mon, Jan 25, 2021 at 1:51 AM Simon Glass  wrote:
>
> These ops are missing at present which is not permitted. Add an empty
> operation struct.
>
> Note: If the uclass requires operations then the drivers should provide
> them. Otherwise, checking for missing operations must be done in every
> uclass operation, so it adds to code size.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Expand commit to explain why operations are required
>
> Changes in v2:
> - Add new patch to fix crash on coral
>
>  board/google/chromebook_coral/coral.c | 5 +
>  1 file changed, 5 insertions(+)
>

Reviewed-by: Bin Meng 

Re: [PATCH v3 09/12] smbios: Add more options for the BIOS version string

[Bin Meng]

On Mon, Jan 25, 2021 at 1:51 AM Simon Glass  wrote:
>
> At present the version string is obtained from PLAIN_VERSION. Some boards
> may want to configure this using the device tree, since the build system
> can more easily insert things there after U-Boot itself is built. Add this
> option to the code.
>
> Also in some cases the version needs to be generated programmatically,
> such as when it is stored elsewhere in the ROM and must be read first.
> To handle this, keep a pointer around so that it can be updated later.
> This works by storing the last string in the context, since it is easier
> than passing out a little-used extra parameter.
>
> Provide a function to update the version string.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3:
> - Add missing DECLARE_GLOBAL_DATA_PTR
>
> Changes in v2:
> - Correct documentation format
>
>  include/asm-generic/global_data.h |  6 
>  include/smbios.h  | 12 +++
>  lib/smbios.c  | 58 +--
>  3 files changed, 73 insertions(+), 3 deletions(-)
>

Reviewed-by: Bin Meng 

Re: [PATCH v3 07/12] smbios: Drop the eos parameter

[Bin Meng]

On Mon, Jan 25, 2021 at 1:51 AM Simon Glass  wrote:
>
> We can store this in the context and avoid passing it to each function.
> This makes it easier to follow and will also allow keeping track of the
> end of the string table (in future patches).
>
> Add an 'eos' field to the context and create a function to set it up.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Fix comment for smbios_add_prop()
> - Rename set_eos() to smbios_set_eos()
>
>  lib/smbios.c | 60 +++-
>  1 file changed, 36 insertions(+), 24 deletions(-)
>

Reviewed-by: Bin Meng 

Re: [PATCH v3 12/12] smbios: Allow a few values to come from sysinfo

[Bin Meng]

Hi Simon,

On Mon, Jan 25, 2021 at 1:51 AM Simon Glass  wrote:
>
> While static configuration is useful it cannot cover every case. Sometimes
> board revisions are encoded in resistor straps and must be read at
> runtime.
>
> The easiest way to provide this information is via sysinfo, since the
> board can then provide a driver to read whatever is needed.
>
> Add some standard sysinfo options for this, and use them to obtain the
> required information.
>
> Signed-off-by: Simon Glass 
>

I guess you used patman to automatically collect the Reviewed-by tag?

Is this blank line inserted by patman? If yes, we should fix patman to
avoid this.

> Reviewed-by: Bin Meng 
> ---
>
> Changes in v3:
> - Use SMBIOS_STR_MAX for the max sysinfo string length
>
>  include/sysinfo.h | 11 +++
>  lib/smbios.c  | 32 +---
>  2 files changed, 40 insertions(+), 3 deletions(-)
>

Regards,
Bin

Re: [PATCH v3 01/12] README: Add doumentation for version information

[Bin Meng]

Hi Simon,

On Mon, Jan 25, 2021 at 1:50 AM Simon Glass  wrote:
>
> There are quite a few available version options in U-Boot. Add a list of
> the available Makefile variables and #defines, along with examples.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v3:
> - Move to doc/ and .rst format
> - Add examples for converting epoch values
>
>  doc/Makefile|  1 -
>  doc/develop/index.rst   |  1 +
>  doc/develop/version.rst | 93 +
>  3 files changed, 94 insertions(+), 1 deletion(-)
>  create mode 100644 doc/develop/version.rst
>
> diff --git a/doc/Makefile b/doc/Makefile
> index a686d4728ec..683e4b56099 100644
> --- a/doc/Makefile
> +++ b/doc/Makefile
> @@ -56,7 +56,6 @@ quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath 
> $(BUILDDIR)/$3/$4)
> PYTHONDONTWRITEBYTECODE=1 \
> BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
> $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
> $(SPHINXBUILD) \
> -   -W \

Why is this change?

> -b $2 \
> -c $(abspath $(srctree)/$(src)) \
> -d $(abspath $(BUILDDIR)/.doctrees/$3) \
> diff --git a/doc/develop/index.rst b/doc/develop/index.rst
> index beaa64d8d90..ac57fdb8f30 100644
> --- a/doc/develop/index.rst
> +++ b/doc/develop/index.rst
> @@ -13,6 +13,7 @@ Implementation
> global_data
> logging
> menus
> +   version
>
>  Debugging
>  -
> diff --git a/doc/develop/version.rst b/doc/develop/version.rst
> new file mode 100644
> index 000..6da31a4a1e7
> --- /dev/null
> +++ b/doc/develop/version.rst
> @@ -0,0 +1,93 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +.. Copyright (c) 2013 The Chromium OS Authors.
> +
> +Version information
> +===
> +
> +U-Boot releases are named by year and patch level, for example 2020.10 means 
> the
> +release that came out in October 2020. Release candidates are tagged every 
> few
> +weeks as the project heads to the next release. So 2020.10-rc1 was the first
> +release candidate (RC), tagged soon after 2020.07 was released.
> +
> +See https://www.denx.de/wiki/view/U-Boot/ReleaseCycle for full details.
> +
> +Within the build system, various Makefile variables are created, making use 
> of
> +VERSION, PATCHLEVEL and EXTRAVERSION defined at the top of 'Makefile'. There 
> is
> +also SUBLEVEL available for downstream use. See also CONFIG_IDENT_STRING.
> +
> +Some variables end up in a generated header file at
> +include/generated/version_autogenerated.h and can be accessed from C source 
> by
> +including 
> +
> +The following are available:
> +
> +   UBOOTRELEASE (Makefile)
> +  Full release version as a string. If this is not a tagged release, it 
> also
> +  includes the number of commits since the last tag as well as the the 
> git
> +  hash.  If there are uncommitted changes a '-dirty' suffix is added too.
> +
> +  This is written by scripts/setlocalversion (maintained by Linux) to
> +  include/config/uboot.release and ends up in the UBOOTRELEASE Makefile
> +  variable.
> +
> +  Examples::
> +
> + 2020.10-rc3
> + 2021.01-rc5-00248-g60dd854f3ba-dirty
> +
> +   PLAIN_VERSION (string #define)
> +  This is UBOOTRELEASE but available in C source.
> +
> +  Examples::
> +
> + 2020.10
> + 2021.01-rc5-00248-g60dd854f3ba-dirty
> +
> +   UBOOTVERSION (Makefile)
> +  This holds just the first three components of UBOOTRELEASE (i.e. not 
> the
> +  git hash, etc.)
> +
> +  Examples::
> +
> + 2020.10
> + 2021.01-rc5
> +
> +   U_BOOT_VERSION (string #define)
> +  "U-Boot " followed by UBOOTRELEASE, for example::
> +
> + U-Boot 2020.10
> + U-Boot 2021.01-rc5
> +
> +  This is used as part of the banner string when U-Boot starts.
> +
> +   U_BOOT_VERSION_STRING (string #define)
> +  U_BOOT_VERSION followed by build-time information
> +  and CONFIG_IDENT_STRING.
> +
> +  Examples::
> +
> + U-Boot 2020.10 (Jan 06 2021 - 08:50:36 -0700)
> + U-Boot 2021.01-rc5-00248-g60dd854f3ba-dirty (Jan 06 2021 - 08:50:36 
> -0700) for spring
> +
> +Build date/time is also included. See the generated file
> +include/generated/timestamp_autogenerated.h for the available
> +fields. For example::
> +
> +   #define U_BOOT_DATE "Jan 06 2021" (US format only)
> +   #define U_BOOT_TIME "08:50:36"(24-hour clock)
> +   #define U_BOOT_TZ "-0700" (Time zone in hours)
> +   #define U_BOOT_DMI_DATE "01/06/2021"  (US format only)
> +   #define U_BOOT_BUILD_DATE 0x20210106  (hex mmdd format)
> +   #define U_BOOT_EPOCH 1609948236
> +
> +The Epoch is the number of seconds since midnight on 1/1/70. You can convert
> +this to a time with::
> +
> +   $ date -u -d @1609948236
> +   Wed 06 Jan 2021 03:50:36 PM UTC
> +   $ date -d 'Wed 06 Jan 2021 03:50:36 PM UTC' +%s
> +   1609948236
> +
> +Every time you build U-Boot this will update based on the time
> +on your build machine. See 

Re: [PATCH v2] sysboot: add zboot support to boot x86 Linux kernel image

[Bin Meng]

Hi Kory,

On Thu, Jan 21, 2021 at 11:01 AM Bin Meng  wrote:
>
> On Sat, Dec 26, 2020 at 5:25 AM Kory Maincent  
> wrote:
> >
> > Add "zboot" command to the list of supported boot in the label_boot 
> > function.
> >
> > Signed-off-by: Kory Maincent 
> > ---
> >
> > Change since v1:
> >  - Modify comment
> >
> >  cmd/pxe_utils.c   | 4 
> >  include/command.h | 2 ++
> >  2 files changed, 6 insertions(+)
> >
>
> applied to u-boot-x86, thanks!

This patch unfortunately does not compile, due to the following commit
made by Simon:

commit 5588e776b02d65afeae612d3dde92e7add2e03cc
Author: Simon Glass 
Date:   Sat Sep 5 14:50:43 2020 -0600

x86: zboot: Set up a sub-command structure

Add subcommands to zboot. At present there is only one called 'start'
which does the whole boot. It is the default command so is optional.

Change the 's' string variable to const while we are here.

Could you please rework? Thanks!

Regards,
Bin

Re: [PATCH v2 00/12] x86: Minor improvements mostly for image loading

[Bin Meng]

Hi Simon,

On Mon, Jan 25, 2021 at 1:06 AM Simon Glass  wrote:
>
> This series provides a few improvements for loading of images. It also
> provides a way to show more detailed model information as well as an
> of-platdata fix noticed recently.
>
> Changes in v2:
> - Add comment to .lds file
> - Add more notes to the commit
> - Fix two missing asterisks in comments
>
> Simon Glass (12):
>   x86: acpi_gpe: Update driver name to match devicetree
>   x86: spl: Add a function to find the text base
>   x86: apl: Enhance debugging in the SPL loader
>   x86: Make sure the SPL image ends on a suitable boundary
>   x86: spl: Make moving BSS conditional
>   x86: Update Chromium OS GNVS names
>   x86: zimage: Allow dumping the image from outside the module
>   x86: zimage: Improve command-line debug handling
>   x86: spl: Clear BSS unconditionally
>   x86: tpl: Show next stage being booted
>   sysinfo: Allow showing model info from sysinfo
>   x86: coral: Show memory config and SKU ID on startup

Patch 1-10 was applied to u-boot-x86. Patch 11-12 do not apply. Please
rebase. Thanks!

Regards,
Bin

Re: [PATCH v2 04/12] x86: Make sure the SPL image ends on a suitable boundary

[Bin Meng]

On Mon, Jan 25, 2021 at 1:06 AM Simon Glass  wrote:
>
> The part of U-Boot that actually ends up in u-boot-nodtb.bin is not built
> with any particular alignment. It ends at the start of the BSS section.
> The BSS section selects its own alignment, which may larger.

may be

> This means that there can be a gap of a few bytes between the image
> ending and BSS starting.
>
> Since u-boot.bin is build by joining u-boot-nodtb.bin and u-boot.dtb (with
> perhaps some padding for BSS), the expected result is not obtained. U-Boot
> uses the end of BSS to find the devicetree, so this means that it cannot
> be found.
>
> Add 32-byte alignment of BSS so that the image size is correct and
> appending the devicetree will place it at the end of BSS.
>
> Signed-off-by: Simon Glass 
> ---
>
> Example SPL output without this patch:
>
> Sections:
> Idx Name  Size  VMA   LMA   File off  Algn
>   0 .text 000142a1  fef4  fef4  1000  2**4
>   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>   1 .u_boot_list  14a4  fef542a8  fef542a8  000152a8  2**3
>   CONTENTS, ALLOC, LOAD, RELOC, DATA
>   2 .rodata   599c  fef55760  fef55760  00016760  2**5
>   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
>   3 .data 0970  fef5b100  fef5b100  0001c100  2**5
>   CONTENTS, ALLOC, LOAD, RELOC, DATA
>   4 .binman_sym_table 0020  fef5ba70  fef5ba70  0001ca70  2**2
>   CONTENTS, ALLOC, LOAD, DATA
>   5 .bss  0060  fef5baa0  fef5baa0    2**5
>   ALLOC
>
> You can see that .bss is aligned to 2**5 (32 bytes). This is because of
> the mallinfo struct in dlmalloc.c:
>
>  17 .bss.current_mallinfo 0028      04c0  2**5
>   ALLOC
>
> In this case the size of u-boot-spl-nodtb.bin is 0x1ba90. This matches up
> with the _image_binary_end symbol:
>
> fef5ba90 g   .binman_sym_table   _image_binary_end
>
> But BSS starts 16 bytes later, at 0xfef5baa0, due to the 32-byte
> alignment. So we must align _image_binary_end to a 32-byte boundary. This
> forces the binary size to be 0x1baa0, i.e. ending at the start of bss, as
> expected.
>
> Note that gcc reports __BIGGEST_ALIGNMENT__ of 16 on this build, even
> though it generates an object file with a member that requests 32-byte
> alignment.
>
> The current_mallinfo struct is 40 bytes in size. Increasing the struct to
> 68 bytes (i.e. just above a 64-byte boundary) does not cause the alignment
> to go above 32 bytes. So it seems that 32 bytes is the maximum alignment
> at present.
>

The above information is very useful for people to understand such
tricky changes.

I can put such in the commit message when applying.

> Changes in v2:
> - Add comment to .lds file
> - Add more notes to the commit
>
>  arch/x86/cpu/u-boot-spl.lds | 10 ++
>  1 file changed, 10 insertions(+)
>

Reviewed-by: Bin Meng 

Re: [PATCH] acpi: Tidy up documentation for struct acpi_gpio

[Bin Meng]

On Mon, Feb 1, 2021 at 2:22 PM Bin Meng  wrote:
>
> On Sun, Jan 24, 2021 at 2:08 AM Simon Glass  wrote:
> >
> > Some comments were provided after this patch was applied. Address them.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  include/acpi/acpi_device.h | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!

Re: [PATCH] acpi: Tidy up documentation for struct acpi_gpio

[Bin Meng]

On Sun, Jan 24, 2021 at 2:08 AM Simon Glass  wrote:
>
> Some comments were provided after this patch was applied. Address them.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/acpi/acpi_device.h | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>

Reviewed-by: Bin Meng 

Re: [PATCH] x86: Reduce size of samus image

[Bin Meng]

On Mon, Feb 1, 2021 at 12:17 AM Simon Glass  wrote:
>
> With the recent addition of ACPI generation, the image size has got beyond
> its current limit.
>
> Samus does not actually use this, nor x86 emulation for PCI ROMs, so
> disable both features.
>
> Signed-off-by: Simon Glass 
> ---
>
>  configs/chromebook_samus_defconfig | 1 +
>  include/configs/chromebook_samus.h | 3 +++
>  2 files changed, 4 insertions(+)
>

Reviewed-by: Bin Meng 

Re: [PATCH 05/17] x86: tsc_timer: Correct overflow in __udelay()

[Bin Meng]

On Mon, Feb 1, 2021 at 2:10 PM Bin Meng  wrote:
>
> On Thu, Jan 14, 2021 at 11:30 AM Simon Glass  wrote:
> >
> > At present long delays such as msleep(2000) can cause an overflow in this
> > function. There is no need for this, since it already uses a 64-bit int.
> >
> > Add a cast to correct this.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  drivers/timer/tsc_timer.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!

Re: [PATCH 13/17] x86: coral: Add a devicetree node for eMMC

[Bin Meng]

On Mon, Feb 1, 2021 at 2:11 PM Bin Meng  wrote:
>
> On Thu, Jan 14, 2021 at 11:30 AM Simon Glass  wrote:
> >
> > Add a node for this so we can indicate that it is does not require any
> > ACPI code.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/x86/dts/chromebook_coral.dts | 6 ++
> >  1 file changed, 6 insertions(+)
> >
>
> Reviewed-by: Bin Meng 

applied to u-boot-x86, thanks!

Re: [PATCH 13/17] x86: coral: Add a devicetree node for eMMC

[Bin Meng]

On Thu, Jan 14, 2021 at 11:30 AM Simon Glass  wrote:
>
> Add a node for this so we can indicate that it is does not require any
> ACPI code.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/dts/chromebook_coral.dts | 6 ++
>  1 file changed, 6 insertions(+)
>

Reviewed-by: Bin Meng 

Re: [PATCH 05/17] x86: tsc_timer: Correct overflow in __udelay()

[Bin Meng]

On Thu, Jan 14, 2021 at 11:30 AM Simon Glass  wrote:
>
> At present long delays such as msleep(2000) can cause an overflow in this
> function. There is no need for this, since it already uses a 64-bit int.
>
> Add a cast to correct this.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/timer/tsc_timer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 

[PATCH 2/3] arm: dts: k3-j721e: Sync Linux v5.11-rc6 dts into U-Boot

[Lokesh Vutla]

Sync all J721e related v5.11-rc6 Linux kernel dts into U-Boot.
HBMC nodes are not yet added in Linux kernel yet but were added
in U-Boot. In order to avoid any regressions, hbmc nodes are kept
intact. These will be added in kernel in future.

Signed-off-by: Lokesh Vutla 
---
 .../k3-j721e-common-proc-board-u-boot.dtsi|   70 +-
 arch/arm/dts/k3-j721e-common-proc-board.dts   |  661 +++-
 arch/arm/dts/k3-j721e-main.dtsi   | 1476 +++--
 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi |  234 ++-
 .../k3-j721e-r5-common-proc-board-u-boot.dtsi |9 +
 .../arm/dts/k3-j721e-r5-common-proc-board.dts |2 -
 arch/arm/dts/k3-j721e-som-p0.dtsi |  272 ++-
 arch/arm/dts/k3-j721e.dtsi|   29 +-
 include/dt-bindings/mux/ti-serdes.h   |   93 ++
 9 files changed, 2440 insertions(+), 406 deletions(-)
 create mode 100644 include/dt-bindings/mux/ti-serdes.h

diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index cfb39325e9..3384ed9f3a 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -13,11 +13,30 @@
 
aliases {
ethernet0 = _port1;
+   spi0 = 
+   spi1 = 
+   remoteproc0 = _r5fss0_core0;
+   remoteproc1 = _r5fss0_core1;
+   remoteproc2 = _r5fss0_core0;
+   remoteproc3 = _r5fss0_core1;
+   remoteproc4 = _r5fss1_core0;
+   remoteproc5 = _r5fss1_core1;
+   remoteproc6 = _0;
+   remoteproc7 = _1;
+   remoteproc8 = _0;
+   i2c0 = _i2c0;
+   i2c1 = _i2c0;
+   i2c2 = _i2c1;
+   i2c3 = _i2c0;
};
 };
 
 _main{
u-boot,dm-spl;
+
+   main-navss {
+   u-boot,dm-spl;
+   };
 };
 
 _mcu_wakeup {
@@ -31,7 +50,7 @@
u-boot,dm-spl;
};
 
-   mcu_navss {
+   mcu-navss {
u-boot,dm-spl;
 
ringacc@2b80 {
@@ -42,6 +61,10 @@
u-boot,dm-spl;
};
};
+
+   chipid@4314 {
+   u-boot,dm-spl;
+   };
 };
 
 _proxy_main {
@@ -70,29 +93,6 @@
 
 _pmx0 {
u-boot,dm-spl;
-   mcu_cpsw_pins_default: mcu_cpsw_pins_default {
-   pinctrl-single,pins = <
-   J721E_WKUP_IOPAD(0x0058, PIN_OUTPUT, 0) /* (N4) 
MCU_RGMII1_TX_CTL */
-   J721E_WKUP_IOPAD(0x005c, PIN_INPUT, 0) /* (N5) 
MCU_RGMII1_RX_CTL */
-   J721E_WKUP_IOPAD(0x0060, PIN_OUTPUT, 0) /* (M2) 
MCU_RGMII1_TD3 */
-   J721E_WKUP_IOPAD(0x0064, PIN_OUTPUT, 0) /* (M3) 
MCU_RGMII1_TD2 */
-   J721E_WKUP_IOPAD(0x0068, PIN_OUTPUT, 0) /* (M4) 
MCU_RGMII1_TD1 */
-   J721E_WKUP_IOPAD(0x006c, PIN_OUTPUT, 0) /* (M5) 
MCU_RGMII1_TD0 */
-   J721E_WKUP_IOPAD(0x0078, PIN_INPUT, 0) /* (L2) 
MCU_RGMII1_RD3 */
-   J721E_WKUP_IOPAD(0x007c, PIN_INPUT, 0) /* (L5) 
MCU_RGMII1_RD2 */
-   J721E_WKUP_IOPAD(0x0080, PIN_INPUT, 0) /* (M6) 
MCU_RGMII1_RD1 */
-   J721E_WKUP_IOPAD(0x0084, PIN_INPUT, 0) /* (L6) 
MCU_RGMII1_RD0 */
-   J721E_WKUP_IOPAD(0x0070, PIN_INPUT, 0) /* (N1) 
MCU_RGMII1_TXC */
-   J721E_WKUP_IOPAD(0x0074, PIN_INPUT, 0) /* (M1) 
MCU_RGMII1_RXC */
-   >;
-   };
-
-   mcu_mdio_pins_default: mcu_mdio1_pins_default {
-   pinctrl-single,pins = <
-   J721E_WKUP_IOPAD(0x008c, PIN_OUTPUT, 0) /* (L1) 
MCU_MDIO0_MDC */
-   J721E_WKUP_IOPAD(0x0088, PIN_INPUT, 0) /* (L4) 
MCU_MDIO0_MDIO */
-   >;
-   };
 };
 
 _pmx0 {
@@ -129,24 +129,6 @@
u-boot,dm-spl;
 };
 
-_cpsw {
-   pinctrl-names = "default";
-   pinctrl-0 = <_cpsw_pins_default _mdio_pins_default>;
-};
-
-_mdio {
-   phy0: ethernet-phy@0 {
-   reg = <0>;
-   ti,rx-internal-delay = ;
-   ti,fifo-depth = ;
-   };
-};
-
-_port1 {
-   phy-mode = "rgmii-rxid";
-   phy-handle = <>;
-};
-
 _cpsw {
reg = <0x0 0x4600 0x0 0x20>,
  <0x0 0x40f00200 0x0 0x2>;
@@ -211,7 +193,3 @@
 _fss0_ospi1_pins_default {
u-boot,dm-spl;
 };
-
- {
-   u-boot,dm-spl;
-};
diff --git a/arch/arm/dts/k3-j721e-common-proc-board.dts 
b/arch/arm/dts/k3-j721e-common-proc-board.dts
index fcfc665f09..60764366e2 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-common-proc-board.dts
@@ -1,12 +1,14 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2019 Texas Instruments Incorporated - https://www.ti.com/
  */
 
 /dts-v1/;
 
 #include "k3-j721e-som-p0.dtsi"
 #include 

[PATCH 3/3] arm: dts: k3-j7200: Sync Linux v5.11-rc6 dts into U-Boot

[Lokesh Vutla]

Sync all J7200 related v5.11-rc6 Linux kernel dts into U-Boot.
MCU R5F nodes are not yet added in Linux kernel yet but were added
in U-Boot. In order to avoid regressions, r5f nodes are kept intact.
These will be added in kernel in future.

Signed-off-by: Lokesh Vutla 
---
 .../k3-j7200-common-proc-board-u-boot.dtsi|  16 +-
 arch/arm/dts/k3-j7200-common-proc-board.dts   | 122 +---
 arch/arm/dts/k3-j7200-main.dtsi   | 296 +++---
 arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 230 +++---
 arch/arm/dts/k3-j7200-som-p0.dtsi | 107 ++-
 arch/arm/dts/k3-j7200.dtsi|  27 +-
 6 files changed, 583 insertions(+), 215 deletions(-)

diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
index 0a5faa2134..e52f7e1e86 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
@@ -11,13 +11,13 @@
 
aliases {
ethernet0 = _port1;
+   i2c0 = _i2c0;
+   i2c1 = _i2c0;
+   i2c2 = _i2c1;
+   i2c3 = _i2c0;
};
 };
 
- {
-   u-boot,dm-spl;
-};
-
 _main {
u-boot,dm-spl;
 };
@@ -36,6 +36,10 @@
clock-frequency = <2500>;
u-boot,dm-spl;
};
+
+   chipid@4314 {
+   u-boot,dm-spl;
+   };
 };
 
 _proxy_main {
@@ -136,10 +140,6 @@
u-boot,dm-spl;
 };
 
-_gpio0 {
-   u-boot,dm-spl;
-};
-
 _fss0_hpb0_pins_default {
u-boot,dm-spl;
 };
diff --git a/arch/arm/dts/k3-j7200-common-proc-board.dts 
b/arch/arm/dts/k3-j7200-common-proc-board.dts
index 85cb159838..5120711d4f 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board.dts
+++ b/arch/arm/dts/k3-j7200-common-proc-board.dts
@@ -5,9 +5,10 @@
 
 /dts-v1/;
 
-#include 
 #include "k3-j7200-som-p0.dtsi"
 #include 
+#include 
+#include 
 
 / {
chosen {
@@ -60,7 +61,7 @@
>;
};
 
-   mcu_cpsw_pins_default: mcu_cpsw_pins_default {
+   mcu_cpsw_pins_default: mcu-cpsw-pins-default {
pinctrl-single,pins = <
J721E_WKUP_IOPAD(0x0068, PIN_OUTPUT, 0) /* 
MCU_RGMII1_TX_CTL */
J721E_WKUP_IOPAD(0x006c, PIN_INPUT, 0) /* 
MCU_RGMII1_RX_CTL */
@@ -77,7 +78,7 @@
>;
};
 
-   mcu_mdio_pins_default: mcu_mdio1_pins_default {
+   mcu_mdio_pins_default: mcu-mdio1-pins-default {
pinctrl-single,pins = <
J721E_WKUP_IOPAD(0x009c, PIN_OUTPUT, 0) /* (L1) 
MCU_MDIO0_MDC */
J721E_WKUP_IOPAD(0x0098, PIN_INPUT, 0) /* (L4) 
MCU_MDIO0_MDIO */
@@ -93,7 +94,14 @@
>;
};
 
-   main_mmc1_pins_default: main_mmc1_pins_default {
+   main_i2c1_pins_default: main-i2c1-pins-default {
+   pinctrl-single,pins = <
+   J721E_IOPAD(0xdc, PIN_INPUT_PULLUP, 3) /* (U3) 
ECAP0_IN_APWM_OUT.I2C1_SCL */
+   J721E_IOPAD(0xe0, PIN_INPUT_PULLUP, 3) /* (T3) 
EXT_REFCLK1.I2C1_SDA */
+   >;
+   };
+
+   main_mmc1_pins_default: main-mmc1-pins-default {
pinctrl-single,pins = <
J721E_IOPAD(0x104, PIN_INPUT, 0) /* (M20) MMC1_CMD */
J721E_IOPAD(0x100, PIN_INPUT, 0) /* (P21) MMC1_CLK */
@@ -112,7 +120,7 @@
>;
};
 
-   main_usbss0_pins_default: main_usbss0_pins_default {
+   main_usbss0_pins_default: main-usbss0-pins-default {
pinctrl-single,pins = <
J721E_IOPAD(0x120, PIN_OUTPUT, 0) /* (T4) USB0_DRVVBUS 
*/
>;
@@ -121,16 +129,17 @@
 
 _uart0 {
/* Wakeup UART is used by System firmware */
-   status = "disabled";
+   status = "reserved";
 };
 
 _uart0 {
+   /* Shared with ATF on this platform */
power-domains = <_pds 146 TI_SCI_PD_SHARED>;
 };
 
 _uart2 {
/* MAIN UART 2 is used by R5F firmware */
-   status = "disabled";
+   status = "reserved";
 };
 
 _uart3 {
@@ -168,27 +177,22 @@
status = "disabled";
 };
 
-_i2c0 {
+_cpsw {
pinctrl-names = "default";
-   pinctrl-0 = <_i2c0_pins_default>;
-   clock-frequency = <40>;
+   pinctrl-0 = <_cpsw_pins_default _mdio_pins_default>;
 };
 
-_sdhci0 {
-   /* eMMC */
-   non-removable;
-   ti,driver-strength-ohm = <50>;
-   disable-wp;
+_mdio {
+   phy0: ethernet-phy@0 {
+   reg = <0>;
+   ti,rx-internal-delay = ;
+   ti,fifo-depth = ;
+   };
 };
 
-_sdhci1 {
-   /* SD card */
-   pinctrl-0 = <_mmc1_pins_default>;
-   pinctrl-names = "default";
-   vmmc-supply = <_mmc1>;
-   vqmmc-supply = <_sd_dv>;
-   ti,driver-strength-ohm = <50>;
-   disable-wp;
+_port1 {
+   phy-mode = "rgmii-rxid";
+   phy-handle = <>;
 };
 
 _i2c0 {
@@ -211,37 +215,69 

[PATCH 1/3] arm: dts: k3-am65: Sync Linux v5.11-rc6 dts into U-Boot

[Lokesh Vutla]

Sync all AM65 related v5.11-rc6 Linux kernel dts into U-Boot.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/k3-am65-main.dtsi| 832 +++---
 arch/arm/dts/k3-am65-mcu.dtsi | 221 +++--
 arch/arm/dts/k3-am65-wakeup.dtsi  |  48 +-
 arch/arm/dts/k3-am65.dtsi |  10 +-
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi  |  63 +-
 arch/arm/dts/k3-am654-base-board.dts  | 465 --
 arch/arm/dts/k3-am654-industrial-thermal.dtsi |  45 +
 arch/arm/dts/k3-am654-r5-base-board.dts   |  38 +-
 arch/arm/dts/k3-am654.dtsi|  10 +-
 9 files changed, 1360 insertions(+), 372 deletions(-)
 create mode 100644 arch/arm/dts/k3-am654-industrial-thermal.dtsi

diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index a7b03dc669..cabdba85e0 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -2,13 +2,31 @@
 /*
  * Device Tree Source for AM6 SoC Family Main Domain peripherals
  *
- * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - https://www.ti.com/
  */
-
 #include 
-#include 
 
 _main {
+   msmc_ram: sram@7000 {
+   compatible = "mmio-sram";
+   reg = <0x0 0x7000 0x0 0x20>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x7000 0x20>;
+
+   atf-sram@0 {
+   reg = <0x0 0x2>;
+   };
+
+   sysfw-sram@f {
+   reg = <0xf 0x1>;
+   };
+
+   l3cache-sram@10 {
+   reg = <0x10 0x10>;
+   };
+   };
+
gic500: interrupt-controller@180 {
compatible = "arm,gic-v3";
#address-cells = <2>;
@@ -24,23 +42,43 @@
 */
interrupts = ;
 
-   gic_its: gic-its@1820 {
+   gic_its: msi-controller@182 {
compatible = "arm,gic-v3-its";
reg = <0x00 0x0182 0x00 0x1>;
+   socionext,synquacer-pre-its = <0x100 0x40>;
msi-controller;
#msi-cells = <1>;
};
};
 
-   secure_proxy_main: mailbox@32c0 {
-   compatible = "ti,am654-secure-proxy";
-   #mbox-cells = <1>;
-   reg-names = "target_data", "rt", "scfg";
-   reg = <0x00 0x32c0 0x00 0x10>,
- <0x00 0x3240 0x00 0x10>,
- <0x00 0x3280 0x00 0x10>;
-   interrupt-names = "rx_011";
-   interrupts = ;
+   serdes0: serdes@90 {
+   compatible = "ti,phy-am654-serdes";
+   reg = <0x0 0x90 0x0 0x2000>;
+   reg-names = "serdes";
+   #phy-cells = <2>;
+   power-domains = <_pds 153 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <_clks 153 4>, <_clks 153 1>, < 
AM654_SERDES_LO_REFCLK>;
+   clock-output-names = "serdes0_cmu_refclk", "serdes0_lo_refclk", 
"serdes0_ro_refclk";
+   assigned-clocks = <_clks 153 4>, < 
AM654_SERDES_CMU_REFCLK>;
+   assigned-clock-parents = <_clks 153 8>, <_clks 153 4>;
+   ti,serdes-clk = <_clk>;
+   #clock-cells = <1>;
+   mux-controls = <_mux 0>;
+   };
+
+   serdes1: serdes@91 {
+   compatible = "ti,phy-am654-serdes";
+   reg = <0x0 0x91 0x0 0x2000>;
+   reg-names = "serdes";
+   #phy-cells = <2>;
+   power-domains = <_pds 154 TI_SCI_PD_EXCLUSIVE>;
+   clocks = < AM654_SERDES_RO_REFCLK>, <_clks 154 1>, 
<_clks 154 5>;
+   clock-output-names = "serdes1_cmu_refclk", "serdes1_lo_refclk", 
"serdes1_ro_refclk";
+   assigned-clocks = <_clks 154 5>, < 
AM654_SERDES_CMU_REFCLK>;
+   assigned-clock-parents = <_clks 154 9>, <_clks 154 5>;
+   ti,serdes-clk = <_clk>;
+   #clock-cells = <1>;
+   mux-controls = <_mux 1>;
};
 
main_uart0: serial@280 {
@@ -51,6 +89,7 @@
interrupts = ;
clock-frequency = <4800>;
current-speed = <115200>;
+   power-domains = <_pds 146 TI_SCI_PD_EXCLUSIVE>;
};
 
main_uart1: serial@281 {
@@ -60,7 +99,7 @@
reg-io-width = <4>;
interrupts = ;
clock-frequency = <4800>;
-   current-speed = <115200>;
+   power-domains = <_pds 147 TI_SCI_PD_EXCLUSIVE>;
};
 
main_uart2: serial@282 {
@@ -70,10 +109,31 @@
reg-io-width = <4>;
interrupts = ;

[PATCH 0/3] arm: dts: k3: Sync TI's K3 related dts nodes

[Lokesh Vutla]

Sync are TI's K3 related v5.11-rc6 Linux kernel dts into U-Boot.
This series depends on the following two patch series:
https://patchwork.ozlabs.org/project/uboot/list/?series=226539
https://patchwork.ozlabs.org/project/uboot/list/?series=227056


Lokesh Vutla (3):
  arm: dts: k3-am65: Sync Linux v5.11-rc6 dts into U-Boot
  arm: dts: k3-j721e: Sync Linux v5.11-rc6 dts into U-Boot
  arm: dts: k3-j7200: Sync Linux v5.11-rc6 dts into U-Boot

 arch/arm/dts/k3-am65-main.dtsi|  832 --
 arch/arm/dts/k3-am65-mcu.dtsi |  221 ++-
 arch/arm/dts/k3-am65-wakeup.dtsi  |   48 +-
 arch/arm/dts/k3-am65.dtsi |   10 +-
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi  |   63 +-
 arch/arm/dts/k3-am654-base-board.dts  |  465 +-
 arch/arm/dts/k3-am654-industrial-thermal.dtsi |   45 +
 arch/arm/dts/k3-am654-r5-base-board.dts   |   38 +-
 arch/arm/dts/k3-am654.dtsi|   10 +-
 .../k3-j7200-common-proc-board-u-boot.dtsi|   16 +-
 arch/arm/dts/k3-j7200-common-proc-board.dts   |  122 +-
 arch/arm/dts/k3-j7200-main.dtsi   |  296 +++-
 arch/arm/dts/k3-j7200-mcu-wakeup.dtsi |  230 +--
 arch/arm/dts/k3-j7200-som-p0.dtsi |  107 +-
 arch/arm/dts/k3-j7200.dtsi|   27 +-
 .../k3-j721e-common-proc-board-u-boot.dtsi|   70 +-
 arch/arm/dts/k3-j721e-common-proc-board.dts   |  661 +++-
 arch/arm/dts/k3-j721e-main.dtsi   | 1476 +++--
 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi |  234 ++-
 .../k3-j721e-r5-common-proc-board-u-boot.dtsi |9 +
 .../arm/dts/k3-j721e-r5-common-proc-board.dts |2 -
 arch/arm/dts/k3-j721e-som-p0.dtsi |  272 ++-
 arch/arm/dts/k3-j721e.dtsi|   29 +-
 include/dt-bindings/mux/ti-serdes.h   |   93 ++
 24 files changed, 4383 insertions(+), 993 deletions(-)
 create mode 100644 arch/arm/dts/k3-am654-industrial-thermal.dtsi
 create mode 100644 include/dt-bindings/mux/ti-serdes.h

-- 
2.30.0

Re: [PATCH] sunxi: spl: Fix H616 clock initialization

[Jernej Škrabec]

Dne ponedeljek, 01. februar 2021 ob 01:46:22 CET je Andre Przywara napisal(a):
> On Sun, 31 Jan 2021 21:25:39 +0100
> Jernej Skrabec  wrote:
> 
> Hi Jernej,
> 
> > It turns out that there is a magic bit in PRCM region which seemingly
> > makes PLLs work if it's enabled. Sadly, there is no documentation what
> > it does exactly, so we'll just mimick BSP boot0 behaviour and enable it
> > before any clock is set up.
> 
> Good job of figuring this out!
> 
> > Fixes: b18bd53d6cde ("sunxi: introduce support for H616 clocks")
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >  arch/arm/mach-sunxi/clock_sun50i_h6.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > b/arch/arm/mach-sunxi/clock_sun50i_h6.c index 06d84eb158d7..68c8e7f2afbe
> > 100644
> > --- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > +++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > @@ -9,6 +9,12 @@ void clock_init_safe(void)
> > 
> >  {
> >  
> > struct sunxi_ccm_reg *const ccm =
> > 
> > (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> > 
> > +
> > +#ifdef CONFIG_MACH_SUN50I_H616
> 
> Can you change this to: if (IS_ENABLED())?

ok.

> 
> > +   /* this seems to enable PLLs */
> 
> Out of curiosity, what makes you think it's PLL related? At least the
> PERIPH0 and CPU PLLs seem to work without it?

Because I was able to configure TCON TOP -> TCON TV0 -> HDMI chain just fine, 
but nothing would be shown on screen, not even test patterns from TCON. HDMI 
itself worked ok (EDID could be read). I noticed that vblank interrupts were 
not genereted. This and no image is consisted with disabling bus clock to TCON 
and HDMI. I checked several times that clock configuration matches to that in 
BSP... I also moved both to another PLL without success. Also, this bit was 
discovered in function, which does clock initialization.

PLL cpu is always special case, otherwise nothing would work at boot. I have 
no real explanation for PLL periph...

Best regards,
Jernej

> 
> Cheers,
> Andre
> 
> > +   setbits_le32(SUNXI_PRCM_BASE + 0x250, 0x10);
> > +#endif
> > +
> > 
> > clock_set_pll1(40800);
> > 
> > writel(CCM_PLL6_DEFAULT, >pll6_cfg);

Re: [PATCH] mtd: spi-nor.h: Change spaces to tabs

[Bin Meng]

On Wed, Jan 6, 2021 at 8:59 PM Bin Meng  wrote:
>
> U-Boot coding convention prefers tabs over spaces.
>
> Signed-off-by: Bin Meng 
> ---
>
>  include/linux/mtd/spi-nor.h | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
>

Ping?

Re: [PATCH] remoteproc: k3_r5: Sync to upstreamed kernel DT property names

[Lokesh Vutla]

On 27/01/21 5:50 am, Suman Anna wrote:
> The K3 R5F remoteproc driver in U-Boot was upstreamed prior to the
> equivalent remoteproc driver in the Linux kernel. Some of the DT
> properties used in U-Boot got upstreamed using different names
> in Linux kernel.
> 
> The modified property names include the R5F cluster mode configuration
> property "lockstep-mode"; and three different individual R5F core config
> properties - "atcm-enable", "btcm-enable" and "loczrama". The property
> names were updated as follows:
>   lockstep-mode => ti,cluster-mode
>   atcm-enable   => ti,atcm-enable
>   btcm-enable   => ti,btcm-enable
>   loczrama  => ti,loczrama
> 
> Update the K3 R5F remoteproc driver, the corresponding binding, and
> all the existing usage in AM65x, J721E and J7200 dts files all at
> once to use the new properties and to not break any bisectability.
> 
> Signed-off-by: Suman Anna 
> ---
> Hi Lokesh,
> 
> As agreed offline, this patch syncs the U-Boot K3 R5F driver and all
> the related pieces in a single patch to the equivalent property names
> in the latest upstream Linux kernel. Note that the kernel bindings in
> general define a few more properties which have no presence so far in
> U-Boot. So, only the common properties are synched. No changes are
> required to the K3 DSP remoteproc driver.
> 
> Tested on AM65x, J721E and J7200 using appropriate SYSFW. Patch is on
> top of latest U-Boot master commit e262b2973e22.

Applied to u-boot-ti/for-rc branch.

Thanks and regards,
Lokesh

Re: [PATCH] configs: am335x_evm: enable CONFIG_SPL_ALLOC_BD

[Lokesh Vutla]

On 19/01/21 2:58 am, Dario Binacchi wrote:
> With commit 38d6b7ebdaee ("spl: Drop bd_info in the data section") you
> need to enable this option to boot from mmc.
> 
> Signed-off-by: Dario Binacchi 

Applied to u-boot-ti/for-rc

Thanks and regards,
Lokesh

> ---
> 
>  configs/am335x_evm_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
> index eb5a299bbc..c4d3bd0c44 100644
> --- a/configs/am335x_evm_defconfig
> +++ b/configs/am335x_evm_defconfig
> @@ -13,6 +13,7 @@ CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run 
> update_to_fit; fi; run f
>  CONFIG_LOGLEVEL=3
>  CONFIG_SYS_CONSOLE_INFO_QUIET=y
>  CONFIG_ARCH_MISC_INIT=y
> +CONFIG_SPL_ALLOC_BD=y
>  CONFIG_SPL_FIT_IMAGE_TINY=y
>  CONFIG_SPL_ETH_SUPPORT=y
>  # CONFIG_SPL_FS_EXT4 is not set
> 

Re: [PATCH 14/14] riscv: k210: Enable QSPI for spi3

[Bin Meng]

On Mon, Feb 1, 2021 at 8:34 AM Sean Anderson  wrote:
>
> This device has four IOs connected to the SPI flash. Add the appropriate
> bindings.
>
> Signed-off-by: Sean Anderson 
> ---
>
>  arch/riscv/dts/k210-maix-bit.dts | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Bin Meng 

Re: [PATCH 05/14] spi: spi-mem: Add debug message for spi-mem ops

[Bin Meng]

On Mon, Feb 1, 2021 at 8:36 AM Sean Anderson  wrote:
>
> This prints some basic metadata about the SPI memory op. This information
> may be used to debug SPI drivers (e.g. determining the expected SPI mode).
> It is also helpful for verifying that the data on the wire matches the data
> intended to be transmitted (e.g. with a logic analyzer). The opcode is
> printed with a format of %02Xh to match the notation commonly used in flash
> datasheets.
>
> Signed-off-by: Sean Anderson 
> ---
>
>  drivers/spi/spi-mem.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> index c095ae9505..eb83c11910 100644
> --- a/drivers/spi/spi-mem.c
> +++ b/drivers/spi/spi-mem.c
> @@ -220,6 +220,12 @@ int spi_mem_exec_op(struct spi_slave *slave, const 
> struct spi_mem_op *op)
> int ret;
> int i;
>
> +   dev_dbg(slave->dev, "exec %02Xh %u-%u-%u addr=%llx wait=%u len=%u\n",

dummy cycles=%u, data len=%u to be clearer?

> +   op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
> +   op->data.buswidth, op->addr.val,
> +   op->dummy.buswidth ? op->dummy.nbytes * 8 / 
> op->dummy.buswidth : 0,
> +   op->data.nbytes);
> +
> if (!spi_mem_supports_op(slave, op))
> return -ENOTSUPP;
>
> --

Otherwise LGTM
Reviewed-by: Bin Meng 

Re: [PATCH 03/14] mtd: spi-nor-core: Fix typo in documentation

[Bin Meng]

On Mon, Feb 1, 2021 at 8:35 AM Sean Anderson  wrote:
>
> This line should come before the docs for the next function.
>
> Fixes: 7aeedac0153 ("mtd: spi: Port SPI NOR framework from Linux")
>
> Signed-off-by: Sean Anderson 
> ---
>
>  include/linux/mtd/spi-nor.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 

Re: [PATCH 04/14] mtd: spi-mem: Export spi_mem_default_supports_op

[Bin Meng]

On Mon, Feb 1, 2021 at 8:35 AM Sean Anderson  wrote:
>
> This is useful for extending the default functionality.
>
> Signed-off-by: Sean Anderson 
> ---
>
>  include/spi-mem.h | 3 +++
>  1 file changed, 3 insertions(+)
>

Reviewed-by: Bin Meng 

Re: [PATCH 02/14] cmd: sf: Print error on test failure

[Bin Meng]

On Mon, Feb 1, 2021 at 8:35 AM Sean Anderson  wrote:
>
> The sf test command is used to test spi flashes (and spi masters). Printing
> the exact error code is very helpful to those debugging the spi stack.
>
> Signed-off-by: Sean Anderson 
> ---
>
>  cmd/sf.c | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
>

Reviewed-by: Bin Meng 

Re: [PATCH 01/14] cmd: sf: Display errno on erase failure

[Bin Meng]

On Mon, Feb 1, 2021 at 8:35 AM Sean Anderson  wrote:
>
> If there is an error while erasing SPI flash, no errno is displayed. This
> makes it difficult to determine the cause of the error. This change mirrors
> the logic for write errors above.
>
> Signed-off-by: Sean Anderson 
> ---
>
>  cmd/sf.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 

Re: [PATCH v2] mmc: mmc_spi: Print verbose debug output when crc16 check fails

[Sean Anderson]

On 1/17/21 7:27 AM, Bin Meng wrote:

Add some verbose debug output when crc16 check fails.

Signed-off-by: Bin Meng 
Reviewed-by: Jaehoon Chung 

---

Changes in v2:
- do the crc_ok assignment at the the same line where it's defined

  drivers/mmc/mmc_spi.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index 46800bbed2..b1edb6ad7c 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -181,8 +181,10 @@ static int mmc_spi_readdata(struct udevice *dev,
if (ret)
return ret;
  #ifdef CONFIG_MMC_SPI_CRC_ON
-   if (be16_to_cpu(crc16_ccitt(0, buf, bsize)) != crc) {
-   debug("%s: data crc error\n", __func__);
+   u16 crc_ok = be16_to_cpu(crc16_ccitt(0, buf, bsize));
+   if (crc_ok != crc) {
+   debug("%s: data crc error, expect %04x get 
%04x\n",


Nit: Perhaps use expected/got?

Otherwise looks good to me; I ended up creating a similar patch
previously, but never got around to upstreaming it.

--Sean


+ __func__, crc_ok, crc);
r1 = R1_SPI_COM_CRC;
break;
}

Re: [PATCH 2/3] mmc: mmc_spi: Fix potential spec violation in receiving card response

[Jaehoon Chung]

Hi Bin,

On 2/1/21 1:20 PM, Bin Meng wrote:
> From: Bin Meng 
> 
> After command is sent and before card response shows up on the line,
> there is a variable number of clock cycles in between called Ncr.
> The spec [1] says the minimum is 1 byte and the maximum is 8 bytes.
> 
> Current logic in mmc_spi_sendcmd() has a flaw that it could only work
> with certain SD cards with their Ncr being just 1 byte.
> 
> When resp_match is false, the codes try to receive only 1 byte from
> the SD card. On the other hand when resp_match is true, the logic
> happens to be no problem as it loops until timeout to receive as many
> bytes as possible to see a match of the expected resp_match_value.
> However not every call to mmc_spi_sendcmd() is made with resp_match
> being true hence this exposes a potential issue with SD cards that
> have a larger Ncr value.
> 
> Given no issue was reported as of today, we can reasonably conclude
> that all cards being used on the supported boards happen to have a 1
> byte Ncr timing requirement. But a broken case can be triggered by
> utilizing QEMU to emulate a larger value of Ncr (by default 1 byte
> Ncr is used on QEMU). This commit fixes such potential spec violation
> to improve the card compatibility.
> 
> [1] "Physical Layer Specification Version 8.00"
>  chapter 7.5.1: Command / Response
>  chapter 7.5.4: Timing Values

After checking spec, i will reply for this patch. :)

Best Regards,
Jaehoon Chung

> 
> Signed-off-by: Bin Meng 
> ---
> 
>  drivers/mmc/mmc_spi.c | 32 +---
>  1 file changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
> index 85a2818..5ec6b0f 100644
> --- a/drivers/mmc/mmc_spi.c
> +++ b/drivers/mmc/mmc_spi.c
> @@ -103,29 +103,31 @@ static int mmc_spi_sendcmd(struct udevice *dev,
>  
>   debug("%s: cmd%d", __func__, cmdidx);
>  
> - if (resp_match) {
> + if (resp_match)
>   r = ~resp_match_value;
> - i = CMD_TIMEOUT;
> - while (i) {
> - ret = dm_spi_xfer(dev, 1 * 8, NULL, , 0);
> - if (ret)
> - return ret;
> - debug(" resp%d=0x%x", rpos, r);
> - rpos++;
> - i--;
> + i = CMD_TIMEOUT;
> + while (i) {
> + ret = dm_spi_xfer(dev, 1 * 8, NULL, , 0);
> + if (ret)
> + return ret;
> + debug(" resp%d=0x%x", rpos, r);
> + rpos++;
> + i--;
>  
> + if (resp_match) {
>   if (r == resp_match_value)
>   break;
> + } else {
> + if (!(r & 0x80))
> + break;
>   }
> - if (!i && (r != resp_match_value))
> +
> + if (!i)
>   return -ETIMEDOUT;
>   }
>  
> - for (i = 0; i < resp_size; i++) {
> - if (i == 0 && resp_match) {
> - resp[i] = resp_match_value;
> - continue;
> - }
> + resp[0] = r;
> + for (i = 1; i < resp_size; i++) {
>   ret = dm_spi_xfer(dev, 1 * 8, NULL, , 0);
>   if (ret)
>   return ret;
> 

Re: [PATCH 3/3] mmc: mmc_spi: Document the 3 local functions

[Jaehoon Chung]

On 2/1/21 1:20 PM, Bin Meng wrote:
> From: Bin Meng 
> 
> mmc_spi_sendcmd(), mmc_spi_readdata() and mmc_spi_writedata() are
> currently undocumented. Add comment blocks to explain the arguments
> and the return value.
> 
> Signed-off-by: Bin Meng 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
> 
>  drivers/mmc/mmc_spi.c | 36 +++-
>  1 file changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
> index 5ec6b0f..6d4f205 100644
> --- a/drivers/mmc/mmc_spi.c
> +++ b/drivers/mmc/mmc_spi.c
> @@ -37,7 +37,8 @@
>  #define SPI_RESPONSE_CRC_ERR ((5 << 1)|1)
>  #define SPI_RESPONSE_WRITE_ERR   ((6 << 1)|1)
>  
> -/* Read and write blocks start with these tokens and end with crc;
> +/*
> + * Read and write blocks start with these tokens and end with crc;
>   * on error, read tokens act like a subset of R2_SPI_* values.
>   */
>  /* single block write multiblock read */
> @@ -70,6 +71,20 @@ struct mmc_spi_priv {
>   struct spi_slave *spi;
>  };
>  
> +/**
> + * mmc_spi_sendcmd() - send a command to the SD card
> + *
> + * @dev: mmc_spi device
> + * @cmdidx:  command index
> + * @cmdarg:  command argument
> + * @resp_type:   card response type
> + * @resp:buffer to store the card response
> + * @resp_size:   size of the card response
> + * @resp_match:  if true, compare each of received bytes with 
> @resp_match_value
> + * @resp_match_value:a value to be compared with each of received 
> bytes
> + * @r1b: if true, receive additional bytes for busy signal token
> + * @return 0 if OK, -ETIMEDOUT if no card response is received, -ve on error
> + */
>  static int mmc_spi_sendcmd(struct udevice *dev,
>  ushort cmdidx, u32 cmdarg, u32 resp_type,
>  u8 *resp, u32 resp_size,
> @@ -159,6 +174,15 @@ static int mmc_spi_sendcmd(struct udevice *dev,
>   return 0;
>  }
>  
> +/**
> + * mmc_spi_readdata() - read data block(s) from the SD card
> + *
> + * @dev: mmc_spi device
> + * @xbuf:buffer of the actual data (excluding token and crc) to read
> + * @bcnt:number of data blocks to transfer
> + * @bsize:   size of the actual data (excluding token and crc) in bytes
> + * @return 0 if OK, -ECOMM if crc error, -ETIMEDOUT on other errors
> + */
>  static int mmc_spi_readdata(struct udevice *dev,
>   void *xbuf, u32 bcnt, u32 bsize)
>  {
> @@ -207,6 +231,16 @@ static int mmc_spi_readdata(struct udevice *dev,
>   return ret;
>  }
>  
> +/**
> + * mmc_spi_writedata() - write data block(s) to the SD card
> + *
> + * @dev: mmc_spi device
> + * @xbuf:buffer of the actual data (excluding token and crc) to write
> + * @bcnt:number of data blocks to transfer
> + * @bsize:   size of actual data (excluding token and crc) in bytes
> + * @multi:   indicate a transfer by multiple block write command (CMD25)
> + * @return 0 if OK, -ECOMM if crc error, -ETIMEDOUT on other errors
> + */
>  static int mmc_spi_writedata(struct udevice *dev, const void *xbuf,
>u32 bcnt, u32 bsize, int multi)
>  {
> 

Re: [PATCH 1/3] mmc: mmc_spi: Move argument check to the beginning of mmc_spi_sendcmd()

[Jaehoon Chung]

On 2/1/21 1:20 PM, Bin Meng wrote:
> From: Bin Meng 
> 
> The argument check should happen before any transfer on the SPI lines.
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  drivers/mmc/mmc_spi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
> index b1edb6a..85a2818 100644
> --- a/drivers/mmc/mmc_spi.c
> +++ b/drivers/mmc/mmc_spi.c
> @@ -83,6 +83,9 @@ static int mmc_spi_sendcmd(struct udevice *dev,
> __func__, cmdidx, cmdarg, resp_type,
> resp_size, resp_match, resp_match_value);
>  
> + if (!resp || !resp_size)
> + return 0;

I'm not sure..does it needs to locate more above? resp_size is referred in 
debug message.
Other thing looks good to me. 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> +
>   cmdo[0] = 0xff;
>   cmdo[1] = MMC_SPI_CMD(cmdidx);
>   cmdo[2] = cmdarg >> 24;
> @@ -98,9 +101,6 @@ static int mmc_spi_sendcmd(struct udevice *dev,
>   if (ret)
>   return ret;
>  
> - if (!resp || !resp_size)
> - return 0;
> -
>   debug("%s: cmd%d", __func__, cmdidx);
>  
>   if (resp_match) {
> 

[PATCH 3/3] mmc: mmc_spi: Document the 3 local functions

[Bin Meng]

From: Bin Meng 

mmc_spi_sendcmd(), mmc_spi_readdata() and mmc_spi_writedata() are
currently undocumented. Add comment blocks to explain the arguments
and the return value.

Signed-off-by: Bin Meng 
---

 drivers/mmc/mmc_spi.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index 5ec6b0f..6d4f205 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -37,7 +37,8 @@
 #define SPI_RESPONSE_CRC_ERR   ((5 << 1)|1)
 #define SPI_RESPONSE_WRITE_ERR ((6 << 1)|1)
 
-/* Read and write blocks start with these tokens and end with crc;
+/*
+ * Read and write blocks start with these tokens and end with crc;
  * on error, read tokens act like a subset of R2_SPI_* values.
  */
 /* single block write multiblock read */
@@ -70,6 +71,20 @@ struct mmc_spi_priv {
struct spi_slave *spi;
 };
 
+/**
+ * mmc_spi_sendcmd() - send a command to the SD card
+ *
+ * @dev:   mmc_spi device
+ * @cmdidx:command index
+ * @cmdarg:command argument
+ * @resp_type: card response type
+ * @resp:  buffer to store the card response
+ * @resp_size: size of the card response
+ * @resp_match:if true, compare each of received bytes with 
@resp_match_value
+ * @resp_match_value:  a value to be compared with each of received bytes
+ * @r1b:   if true, receive additional bytes for busy signal token
+ * @return 0 if OK, -ETIMEDOUT if no card response is received, -ve on error
+ */
 static int mmc_spi_sendcmd(struct udevice *dev,
   ushort cmdidx, u32 cmdarg, u32 resp_type,
   u8 *resp, u32 resp_size,
@@ -159,6 +174,15 @@ static int mmc_spi_sendcmd(struct udevice *dev,
return 0;
 }
 
+/**
+ * mmc_spi_readdata() - read data block(s) from the SD card
+ *
+ * @dev:   mmc_spi device
+ * @xbuf:  buffer of the actual data (excluding token and crc) to read
+ * @bcnt:  number of data blocks to transfer
+ * @bsize: size of the actual data (excluding token and crc) in bytes
+ * @return 0 if OK, -ECOMM if crc error, -ETIMEDOUT on other errors
+ */
 static int mmc_spi_readdata(struct udevice *dev,
void *xbuf, u32 bcnt, u32 bsize)
 {
@@ -207,6 +231,16 @@ static int mmc_spi_readdata(struct udevice *dev,
return ret;
 }
 
+/**
+ * mmc_spi_writedata() - write data block(s) to the SD card
+ *
+ * @dev:   mmc_spi device
+ * @xbuf:  buffer of the actual data (excluding token and crc) to write
+ * @bcnt:  number of data blocks to transfer
+ * @bsize: size of actual data (excluding token and crc) in bytes
+ * @multi: indicate a transfer by multiple block write command (CMD25)
+ * @return 0 if OK, -ECOMM if crc error, -ETIMEDOUT on other errors
+ */
 static int mmc_spi_writedata(struct udevice *dev, const void *xbuf,
 u32 bcnt, u32 bsize, int multi)
 {
-- 
2.7.4

[PATCH 2/3] mmc: mmc_spi: Fix potential spec violation in receiving card response

[Bin Meng]

From: Bin Meng 

After command is sent and before card response shows up on the line,
there is a variable number of clock cycles in between called Ncr.
The spec [1] says the minimum is 1 byte and the maximum is 8 bytes.

Current logic in mmc_spi_sendcmd() has a flaw that it could only work
with certain SD cards with their Ncr being just 1 byte.

When resp_match is false, the codes try to receive only 1 byte from
the SD card. On the other hand when resp_match is true, the logic
happens to be no problem as it loops until timeout to receive as many
bytes as possible to see a match of the expected resp_match_value.
However not every call to mmc_spi_sendcmd() is made with resp_match
being true hence this exposes a potential issue with SD cards that
have a larger Ncr value.

Given no issue was reported as of today, we can reasonably conclude
that all cards being used on the supported boards happen to have a 1
byte Ncr timing requirement. But a broken case can be triggered by
utilizing QEMU to emulate a larger value of Ncr (by default 1 byte
Ncr is used on QEMU). This commit fixes such potential spec violation
to improve the card compatibility.

[1] "Physical Layer Specification Version 8.00"
 chapter 7.5.1: Command / Response
 chapter 7.5.4: Timing Values

Signed-off-by: Bin Meng 
---

 drivers/mmc/mmc_spi.c | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index 85a2818..5ec6b0f 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -103,29 +103,31 @@ static int mmc_spi_sendcmd(struct udevice *dev,
 
debug("%s: cmd%d", __func__, cmdidx);
 
-   if (resp_match) {
+   if (resp_match)
r = ~resp_match_value;
-   i = CMD_TIMEOUT;
-   while (i) {
-   ret = dm_spi_xfer(dev, 1 * 8, NULL, , 0);
-   if (ret)
-   return ret;
-   debug(" resp%d=0x%x", rpos, r);
-   rpos++;
-   i--;
+   i = CMD_TIMEOUT;
+   while (i) {
+   ret = dm_spi_xfer(dev, 1 * 8, NULL, , 0);
+   if (ret)
+   return ret;
+   debug(" resp%d=0x%x", rpos, r);
+   rpos++;
+   i--;
 
+   if (resp_match) {
if (r == resp_match_value)
break;
+   } else {
+   if (!(r & 0x80))
+   break;
}
-   if (!i && (r != resp_match_value))
+
+   if (!i)
return -ETIMEDOUT;
}
 
-   for (i = 0; i < resp_size; i++) {
-   if (i == 0 && resp_match) {
-   resp[i] = resp_match_value;
-   continue;
-   }
+   resp[0] = r;
+   for (i = 1; i < resp_size; i++) {
ret = dm_spi_xfer(dev, 1 * 8, NULL, , 0);
if (ret)
return ret;
-- 
2.7.4

[PATCH 1/3] mmc: mmc_spi: Move argument check to the beginning of mmc_spi_sendcmd()

[Bin Meng]

From: Bin Meng 

The argument check should happen before any transfer on the SPI lines.

Signed-off-by: Bin Meng 
---

 drivers/mmc/mmc_spi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index b1edb6a..85a2818 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -83,6 +83,9 @@ static int mmc_spi_sendcmd(struct udevice *dev,
  __func__, cmdidx, cmdarg, resp_type,
  resp_size, resp_match, resp_match_value);
 
+   if (!resp || !resp_size)
+   return 0;
+
cmdo[0] = 0xff;
cmdo[1] = MMC_SPI_CMD(cmdidx);
cmdo[2] = cmdarg >> 24;
@@ -98,9 +101,6 @@ static int mmc_spi_sendcmd(struct udevice *dev,
if (ret)
return ret;
 
-   if (!resp || !resp_size)
-   return 0;
-
debug("%s: cmd%d", __func__, cmdidx);
 
if (resp_match) {
-- 
2.7.4

[PATCH 0/3] mmc: mmc_spi: Fix potential spec violation in receiving card response

[Bin Meng]

After command is sent and before card response shows up on the line,
there is a variable number of clock cycles in between called Ncr.
The spec [1] says the minimum is 1 byte and the maximum is 8 bytes.

Current logic in mmc_spi_sendcmd() has a flaw that it could only work
with certain SD cards with their Ncr being just 1 byte.

When resp_match is false, the codes try to receive only 1 byte from
the SD card. On the other hand when resp_match is true, the logic
happens to be no problem as it loops until timeout to receive as many
bytes as possible to see a match of the expected resp_match_value.
However not every call to mmc_spi_sendcmd() is made with resp_match
being true hence this exposes a potential issue with SD cards that
have a larger Ncr value.

Given no issue was reported as of today, we can reasonably conclude
that all cards being used on the supported boards happen to have a 1
byte Ncr timing requirement. But a broken case can be triggered by
utilizing QEMU to emulate a larger value of Ncr (by default 1 byte
Ncr is used on QEMU). This series fixes such potential spec violation
to improve the card compatibility.

[1] "Physical Layer Specification Version 8.00"
 chapter 7.5.1: Command / Response
 chapter 7.5.4: Timing Values


Bin Meng (3):
  mmc: mmc_spi: Move argument check to the beginning of
mmc_spi_sendcmd()
  mmc: mmc_spi: Fix potential spec violation in receiving card response
  mmc: mmc_spi: Document the 3 local functions

 drivers/mmc/mmc_spi.c | 74 ++-
 1 file changed, 55 insertions(+), 19 deletions(-)

-- 
2.7.4

Re: [PATCH 1/2] gitlab: Move the n900 test into its own section

[Tom Rini]

On Mon, Feb 01, 2021 at 03:54:39AM +0100, Heinrich Schuchardt wrote:
> On 1/31/21 2:49 PM, Tom Rini wrote:
> > On Sun, Jan 31, 2021 at 01:15:20PM +0100, Pali Rohár wrote:
> > > On Saturday 30 January 2021 22:17:45 Simon Glass wrote:
> > > > This test is not reliable. Quite often (20%?) it makes the build fail 
> > > > and
> > > > a retry succeeds.
> > > 
> > > This test should work. Are there any logs with issues?
> > 
> > I don't see it failing any more often than other tests do, due to
> > network connectivity issues.  That may be helped by, now that we've
> > dropped Travis, having the container be pre-populated with more of the
> > downloaded files and pre-building the special QEMU.
> > 
> 
> Hello Tom,
> 
> That is what my patch
> 
> Dockerfile: compile QEMU for Nokia N900 emulation
> https://patchwork.ozlabs.org/project/uboot/patch/20200713171046.230013-1-xypron.g...@gmx.de/
> 
> is about.
> 
> You marked it as "changes requested" but it is unclear to me which
> changes you request.

As I said in the most recent reply there, we need to update the test
script to use it, and that in turn may also mean changing what the
Dockerfile change is doing.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2] mmc: mmc_spi: Print verbose debug output when crc16 check fails

[Bin Meng]

On Thu, Jan 28, 2021 at 11:14 PM Bin Meng  wrote:
>
> On Sun, Jan 17, 2021 at 8:27 PM Bin Meng  wrote:
> >
> > Add some verbose debug output when crc16 check fails.
> >
> > Signed-off-by: Bin Meng 
> > Reviewed-by: Jaehoon Chung 
> >
> > ---
> >
> > Changes in v2:
> > - do the crc_ok assignment at the the same line where it's defined
> >
> >  drivers/mmc/mmc_spi.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
>
> Ping?

Peng, will you take this, or if this should go via another tree?

Regards,
Bin

Re: [PATCH 1/2] gitlab: Move the n900 test into its own section

[Heinrich Schuchardt]

On 1/31/21 2:49 PM, Tom Rini wrote:

On Sun, Jan 31, 2021 at 01:15:20PM +0100, Pali Rohár wrote:

On Saturday 30 January 2021 22:17:45 Simon Glass wrote:

This test is not reliable. Quite often (20%?) it makes the build fail and
a retry succeeds.


This test should work. Are there any logs with issues?


I don't see it failing any more often than other tests do, due to
network connectivity issues.  That may be helped by, now that we've
dropped Travis, having the container be pre-populated with more of the
downloaded files and pre-building the special QEMU.



Hello Tom,

That is what my patch

Dockerfile: compile QEMU for Nokia N900 emulation
https://patchwork.ozlabs.org/project/uboot/patch/20200713171046.230013-1-xypron.g...@gmx.de/

is about.

You marked it as "changes requested" but it is unclear to me which
changes you request.

Best regards

Heinrich

Re: arm64: rk3399: Add support NanoPi R4s

[Chen-Yu Tsai]

Hi,

On Mon, Feb 1, 2021 at 9:58 AM Kever Yang  wrote:
>
> Hi Xiaobo,
>
>
>  Thanks for your update, see comments in line.
>
> On 2021/1/29 下午10:34, alex tian wrote:
> > From c9563fe439e07e760d29a42e737b8265d5772150 Mon Sep 17 00:00:00 2001
> > From: Xiaobo Tian mailto:peterwil...@gmail.com>>
> > Date: Fri, 29 Jan 2021 22:30:22 +0800
> > Subject: [PATCH] arm64: rk3399: Add support NanoPi R4s
>
> You need to update the patch version, this is at lease version 4, and
> please add change log
>
> for what have been update in new version, these can be found in the link
> I share with you in previous review.
>
> >
> > NanoPi R4s [1] is SBC base on Rockchip RK3399 hexa-core processor with
> > dual-Core Cortex-A72 and Mali-T864 GPU with 4GiB(LPDDR4) of RAM, SD
> > card support,
> > including 2 gigabit ethernet(RTL8211E 1Gbps - RTL8111H 1Gbps) and 2
> > USB 3.0 port.
> > port.It also has two GPIO headers which allows further peripherals to
> > be used.
> >
> > The devicetree file is taken of the rk3399 nanopi4 Linux kernel [2].
> we need a commit number in mainline kernel instead of file link.
> >
> > [1] https://wiki.friendlyarm.com/wiki/index.php/NanoPi_R4S
> This product is no need in the commit message.
> > [2]
> > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
> >
> > Cc: Tom Rini mailto:tr...@konsulko.com>>
> > Cc: Kever Yang  > >
> > Reviewed-by: Kever Yang  > >
>
>
> Please don't add my review tag before I reply it to the list with
> "Reviewed-by..." message.
>
> One more thing is that please make sure this patch can pass the
> checkpatch script, 10 warnings for this patch now,
>
> and you will need to add MAINTAINERS info for this board at
> board/rockchip/evb_rk3399/MAINTAINERS if you
>
> want to follow evb with everything other than dts, or else you will need
> to add a board at board/friendlyarm/.
>
>
> Thanks,
>
> - Kever
>
> > Signed-off-by: Xiaobo Tian  > >
> > ---
> >  arch/arm/dts/Makefile  |   1 +
> >  arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi |   7 ++
> >  arch/arm/dts/rk3399-nanopi-r4s.dts | 129 +
> >  configs/nanopi-r4s-rk3399_defconfig|  62 ++
> >  4 files changed, 199 insertions(+)
> >  create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/rk3399-nanopi-r4s.dts
> >  create mode 100644 configs/nanopi-r4s-rk3399_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 858b79ac97..528dfe069e 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -92,6 +92,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
> >   rk3288-evb.dtb \
> >   rk3288-firefly.dtb \
> >   rk3288-miqi.dtb \
> > + rk3399-nanopi-r4s.dtb \
> >   rk3288-phycore-rdk.dtb \
> >   rk3288-popmetal.dtb \
> >   rk3288-rock2-square.dtb \
> > diff --git a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> > b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> > new file mode 100644
> > index 00..df193f0e64
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> > @@ -0,0 +1,7 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2020 Xiaobo  > >
> > + */
> > +
> > +#include "rk3399-nanopi4-u-boot.dtsi"
> > +#include "rk3399-sdram-lpddr4-100.dtsi"

Because of this ...

> > diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts
> > b/arch/arm/dts/rk3399-nanopi-r4s.dts
> > new file mode 100644
> > index 00..36d55fed39
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
> > @@ -0,0 +1,129 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright (c) 2020 FriendlyElec Computer Tech. Co., Ltd.
> > + * (http://www.friendlyarm.com)
> > + *
> > + * Copyright (C) 2020 Xiaobo  > >
> > + */
> > +
> > +/dts-v1/;
> > +#include "rk3399-nanopi4.dtsi"
> > +
> > +/ {
> > + model = "FriendlyElec NanoPi R4S";
> > + compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
> > +
> > +  cpuinfo {
> > +  compatible = "rockchip,cpuinfo";
> > +  nvmem-cells = <_id>;
> > +  nvmem-cell-names = "id";
> > +  };
> > +
> > +  aliases {
> > +  ethernet1 = 
> > +  };
> > +
> > + vdd_5v: vdd-5v {
> > + compatible = "regulator-fixed";
> > + regulator-name = "vdd_5v";
> > + regulator-always-on;
> > + regulator-boot-on;
> > + };
> > +
> > + fan: pwm-fan {
> > + compatible = "pwm-fan";
> > + cooling-levels = <0 12 18 255>;
> > + #cooling-cells = <2>;
> > + fan-supply = <_5v>;
> > + pwms = < 0 5 0>;
> > + };
> > +};
> > +
> > +_thermal {
> > + trips {
> > + cpu_warm: cpu_warm {
> > + temperature = <55000>;
> > + hysteresis = <2000>;
> > + type = "active";
> > + };
> > +
> > + cpu_hot: cpu_hot {
> > + temperature = <65000>;
> > + hysteresis = <2000>;
> > + type = "active";
> > + };
> > + };
> > +
> > + cooling-maps {
> > + map2 {
> > + 

[PATCH 1/1] fs/squashfs: NULL dereference in sqfs_closedir()

[Heinrich Schuchardt]

sqfs_opendir() called in sqfs_size(), sqfs_read(), sqfs_exists() may fail
leading to sqfs_closedir(NULL) being called. Do not dereference NULL.

Signed-off-by: Heinrich Schuchardt 
---
 fs/squashfs/sqfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index dca13bd1f1..29805c3c6f 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -1716,6 +1716,9 @@ void sqfs_closedir(struct fs_dir_stream *dirs)
 {
struct squashfs_dir_stream *sqfs_dirs;

+   if (!dirs)
+   return;
+
sqfs_dirs = (struct squashfs_dir_stream *)dirs;
free(sqfs_dirs->inode_table);
free(sqfs_dirs->dir_table);
--
2.29.2

[PATCH 1/1] firmware: smci: possible NULL dereference

[Heinrich Schuchardt]

sandbox_scmi_devices_ctx() may return NULL. We should not dereference this
value in sandbox_scmi_devices_remove().

The problem was indicated by 'gcc-11 -fanalyzer'.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/firmware/scmi/sandbox-scmi_devices.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/firmware/scmi/sandbox-scmi_devices.c 
b/drivers/firmware/scmi/sandbox-scmi_devices.c
index 414da6f4df..1a6fafbf53 100644
--- a/drivers/firmware/scmi/sandbox-scmi_devices.c
+++ b/drivers/firmware/scmi/sandbox-scmi_devices.c
@@ -50,6 +50,9 @@ static int sandbox_scmi_devices_remove(struct udevice *dev)
int ret = 0;
size_t n;

+   if (!devices)
+   return 0;
+
for (n = 0; n < SCMI_TEST_DEVICES_RD_COUNT; n++) {
int ret2 = reset_free(devices->reset + n);

--
2.29.2

Re: arm64: rk3399: Add support NanoPi R4s

[Kever Yang]

Hi Xiaobo,


    Thanks for your update, see comments in line.

On 2021/1/29 下午10:34, alex tian wrote:

From c9563fe439e07e760d29a42e737b8265d5772150 Mon Sep 17 00:00:00 2001
From: Xiaobo Tian mailto:peterwil...@gmail.com>>
Date: Fri, 29 Jan 2021 22:30:22 +0800
Subject: [PATCH] arm64: rk3399: Add support NanoPi R4s


You need to update the patch version, this is at lease version 4, and 
please add change log


for what have been update in new version, these can be found in the link 
I share with you in previous review.




NanoPi R4s [1] is SBC base on Rockchip RK3399 hexa-core processor with
dual-Core Cortex-A72 and Mali-T864 GPU with 4GiB(LPDDR4) of RAM, SD 
card support,
including 2 gigabit ethernet(RTL8211E 1Gbps - RTL8111H 1Gbps) and 2 
USB 3.0 port.
port.It also has two GPIO headers which allows further peripherals to 
be used.


The devicetree file is taken of the rk3399 nanopi4 Linux kernel [2].

we need a commit number in mainline kernel instead of file link.


[1] https://wiki.friendlyarm.com/wiki/index.php/NanoPi_R4S

This product is no need in the commit message.
[2] 
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi


Cc: Tom Rini mailto:tr...@konsulko.com>>
Cc: Kever Yang >
Reviewed-by: Kever Yang >



Please don't add my review tag before I reply it to the list with 
"Reviewed-by..." message.


One more thing is that please make sure this patch can pass the 
checkpatch script, 10 warnings for this patch now,


and you will need to add MAINTAINERS info for this board at 
board/rockchip/evb_rk3399/MAINTAINERS if you


want to follow evb with everything other than dts, or else you will need 
to add a board at board/friendlyarm/.



Thanks,

- Kever

Signed-off-by: Xiaobo Tian >

---
 arch/arm/dts/Makefile                      |   1 +
 arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi |   7 ++
 arch/arm/dts/rk3399-nanopi-r4s.dts         | 129 +
 configs/nanopi-r4s-rk3399_defconfig        |  62 ++
 4 files changed, 199 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-nanopi-r4s.dts
 create mode 100644 configs/nanopi-r4s-rk3399_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 858b79ac97..528dfe069e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -92,6 +92,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
  rk3288-evb.dtb \
  rk3288-firefly.dtb \
  rk3288-miqi.dtb \
+ rk3399-nanopi-r4s.dtb \
  rk3288-phycore-rdk.dtb \
  rk3288-popmetal.dtb \
  rk3288-rock2-square.dtb \
diff --git a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi 
b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi

new file mode 100644
index 00..df193f0e64
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Xiaobo >

+ */
+
+#include "rk3399-nanopi4-u-boot.dtsi"
+#include "rk3399-sdram-lpddr4-100.dtsi"
diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts 
b/arch/arm/dts/rk3399-nanopi-r4s.dts

new file mode 100644
index 00..36d55fed39
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (C) 2020 Xiaobo >

+ */
+
+/dts-v1/;
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+ model = "FriendlyElec NanoPi R4S";
+ compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
+
+  cpuinfo {
+      compatible = "rockchip,cpuinfo";
+      nvmem-cells = <_id>;
+      nvmem-cell-names = "id";
+  };
+
+  aliases {
+      ethernet1 = 
+  };
+
+ vdd_5v: vdd-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_5v";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ cooling-levels = <0 12 18 255>;
+ #cooling-cells = <2>;
+ fan-supply = <_5v>;
+ pwms = < 0 5 0>;
+ };
+};
+
+_thermal {
+ trips {
+ cpu_warm: cpu_warm {
+ temperature = <55000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_hot: cpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map2 {
+ trip = <_warm>;
+ cooling-device = < THERMAL_NO_LIMIT 1>;
+ };
+
+ map3 {
+ trip = <_hot>;
+ cooling-device = < 2 THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+_phy {
+ status = "disabled";
+};
+
+ {
+ status = "disabled";
+};
+
+ {
+ lan_led: led-1 {
+ gpios = < RK_PA1 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:lan";
+ };
+
+ wan_led: led-2 {
+ gpios = < RK_PA0 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:wan";
+ };
+};
+
+_gpio {
+ rockchip,pins =
+ <0 RK_PB5 RK_FUNC_GPIO _pull_none>,
+ <1 RK_PA0 RK_FUNC_GPIO _pull_none>,
+ <1 RK_PA1 RK_FUNC_GPIO _pull_none>;
+};
+
+ {
+ max-link-speed = <1>;
+ num-lanes 

Re: [PATCH] sunxi: spl: Fix H616 clock initialization

[Andre Przywara]

On Sun, 31 Jan 2021 21:25:39 +0100
Jernej Skrabec  wrote:

Hi Jernej,

> It turns out that there is a magic bit in PRCM region which seemingly
> makes PLLs work if it's enabled. Sadly, there is no documentation what
> it does exactly, so we'll just mimick BSP boot0 behaviour and enable it
> before any clock is set up.

Good job of figuring this out!

> Fixes: b18bd53d6cde ("sunxi: introduce support for H616 clocks")
> Signed-off-by: Jernej Skrabec 
> ---
>  arch/arm/mach-sunxi/clock_sun50i_h6.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c 
> b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> index 06d84eb158d7..68c8e7f2afbe 100644
> --- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> +++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> @@ -9,6 +9,12 @@ void clock_init_safe(void)
>  {
>   struct sunxi_ccm_reg *const ccm =
>   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> +
> +#ifdef CONFIG_MACH_SUN50I_H616

Can you change this to: if (IS_ENABLED())?

> + /* this seems to enable PLLs */

Out of curiosity, what makes you think it's PLL related? At least the
PERIPH0 and CPU PLLs seem to work without it?

Cheers,
Andre

> + setbits_le32(SUNXI_PRCM_BASE + 0x250, 0x10);
> +#endif
> +
>   clock_set_pll1(40800);
>  
>   writel(CCM_PLL6_DEFAULT, >pll6_cfg);

Re: [PULL] u-boot-usb/master

[Tom Rini]

On Sun, Jan 31, 2021 at 03:58:01PM +0100, Marek Vasut wrote:

> The following changes since commit 472a716b8fdfd88a27cb675e4ea8e12cb4f79fc3:
> 
>   configs: Resync with savedefconfig (2021-01-29 13:56:04 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 723fd5668ff2c8dd19e808778b5670d0fa6bdc4b:
> 
>   usb: gaget: ci: set ep's desc when enable ep (2021-01-31 14:08:56 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PULL] u-boot-sh/master

[Tom Rini]

On Sun, Jan 31, 2021 at 03:57:24PM +0100, Marek Vasut wrote:

> The following changes since commit 472a716b8fdfd88a27cb675e4ea8e12cb4f79fc3:
> 
>   configs: Resync with savedefconfig (2021-01-29 13:56:04 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sh.git master
> 
> for you to fetch changes up to 8a73bef338d48095dfb8e805b643d7dd1f6b6d9b:
> 
>   mmc: tmio: sdhi: Configure internal DMA bus width (2021-01-31 14:08:45
> +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: Please pull u-boot-dm

[Tom Rini]

On Sat, Jan 30, 2021 at 08:28:26PM -0700, Simon Glass wrote:

> Hi Tom,
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/6139
> 
> 
> The following changes since commit 472a716b8fdfd88a27cb675e4ea8e12cb4f79fc3:
> 
>   configs: Resync with savedefconfig (2021-01-29 13:56:04 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-dm.git tags/dm-pull-30jan21
> 
> for you to fetch changes up to f84eda89e5970ef513fe64ba8e8d977788c44dca:
> 
>   disk: part: sandbox support in dev_print() (2021-01-30 14:25:42 -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 12/14] spi: dw: Support DUAL/QUAD/OCTAL

[Sean Anderson]

This adds support for DUAL/QUAD/OCTAL transfers. This adds
dw_spi_supports_op to do some sanity checks which would otherwise live in
exec_op. We only support byte transfers, but as far as I could tell only
bytes are supported by mem_ops (e.g. every part of the opcode has nbytes).

Signed-off-by: Sean Anderson 
---

 drivers/spi/designware_spi.c | 147 +++
 1 file changed, 130 insertions(+), 17 deletions(-)

diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index 169888a06d..4796d55b20 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -215,7 +215,8 @@ static u32 dw_spi_update_cr0(struct dw_spi_priv *priv)
 priv->bits_per_word - 1)
| FIELD_PREP(DWC_SSI_CTRLR0_FRF_MASK, priv->type)
| FIELD_PREP(DWC_SSI_CTRLR0_MODE_MASK, priv->mode)
-   | FIELD_PREP(DWC_SSI_CTRLR0_TMOD_MASK, priv->tmode);
+   | FIELD_PREP(DWC_SSI_CTRLR0_TMOD_MASK, priv->tmode)
+   | FIELD_PREP(DWC_SSI_CTRLR0_SPI_FRF_MASK, priv->spi_frf);
} else {
if (priv->caps & DW_SPI_CAP_DFS32)
cr0 = FIELD_PREP(CTRLR0_DFS_32_MASK,
@@ -226,12 +227,36 @@ static u32 dw_spi_update_cr0(struct dw_spi_priv *priv)
 
cr0 |= FIELD_PREP(CTRLR0_FRF_MASK, priv->type)
|  FIELD_PREP(CTRLR0_MODE_MASK, priv->mode)
-   |  FIELD_PREP(CTRLR0_TMOD_MASK, priv->tmode);
+   |  FIELD_PREP(CTRLR0_TMOD_MASK, priv->tmode)
+   |  FIELD_PREP(CTRLR0_SPI_FRF_MASK, priv->spi_frf);
}
 
return cr0;
 }
 
+static u32 dw_spi_update_spi_cr0(const struct spi_mem_op *op)
+{
+   uint trans_type, wait_cycles;
+
+   /* This assumes support_op has filtered invalid types */
+   if (op->addr.buswidth == 1)
+   trans_type = SPI_CTRLR0_TRANS_TYPE_1_1_X;
+   else if (op->cmd.buswidth == 1)
+   trans_type = SPI_CTRLR0_TRANS_TYPE_1_X_X;
+   else
+   trans_type = SPI_CTRLR0_TRANS_TYPE_X_X_X;
+
+   if (op->dummy.buswidth)
+   wait_cycles = op->dummy.nbytes * 8 / op->dummy.buswidth;
+   else
+   wait_cycles = 0;
+
+   return FIELD_PREP(SPI_CTRLR0_TRANS_TYPE, trans_type)
+  | FIELD_PREP(SPI_CTRLR0_ADDR_L_MASK, op->addr.nbytes * 2)
+  | FIELD_PREP(SPI_CTRLR0_INST_L_MASK, 2)
+  | FIELD_PREP(SPI_CTRLR0_WAIT_CYCLES_MASK, wait_cycles);
+}
+
 static int request_gpio_cs(struct udevice *bus)
 {
 #if CONFIG_IS_ENABLED(DM_GPIO) && !defined(CONFIG_SPL_BUILD)
@@ -302,6 +327,17 @@ static void spi_hw_init(struct udevice *bus, struct 
dw_spi_priv *priv)
if (priv->caps & DW_SPI_CAP_DWC_SSI || !FIELD_GET(CTRLR0_DFS_MASK, cr0))
priv->caps |= DW_SPI_CAP_DFS32;
 
+   /*
+* If SPI_FRF exists that means we have DUAL, QUAD, or OCTAL. Since we
+* can't differentiate, just set DUAL
+*/
+   if (priv->caps & DW_SPI_CAP_DWC_SSI) {
+   if (FIELD_GET(DWC_SSI_CTRLR0_SPI_FRF_MASK, cr0))
+   priv->caps |= DW_SPI_CAP_DUAL;
+   } else if (FIELD_GET(CTRLR0_SPI_FRF_MASK, cr0)) {
+   priv->caps |= DW_SPI_CAP_DUAL;
+   }
+
dw_write(priv, DW_SPI_SSIENR, 1);
 
/*
@@ -604,6 +640,13 @@ static int dw_spi_xfer(struct udevice *dev, unsigned int 
bitlen,
u32 val, cs;
uint frames;
 
+   /* DUAL/QUAD/OCTAL only supported by exec_op for now */
+   if (priv->mode & (SPI_TX_DUAL | SPI_TX_QUAD | SPI_TX_OCTAL |
+ SPI_RX_DUAL | SPI_RX_QUAD | SPI_RX_OCTAL))
+   return -1;
+
+   priv->spi_frf = CTRLR0_SPI_FRF_BYTE;
+
/* spi core configured to do 8 bit transfers */
if (bitlen % priv->bits_per_word) {
dev_err(dev, "Non byte aligned SPI transfer.\n");
@@ -682,6 +725,9 @@ static int dw_spi_xfer(struct udevice *dev, unsigned int 
bitlen,
 /*
  * This function is necessary for reading SPI flash with the native CS
  * c.f. https://lkml.org/lkml/2015/12/23/132
+ *
+ * It also lets us handle DUAL/QUAD/OCTAL transfers in a much more idiomatic
+ * way.
  */
 static int dw_spi_exec_op(struct spi_slave *slave, const struct spi_mem_op *op)
 {
@@ -692,37 +738,72 @@ static int dw_spi_exec_op(struct spi_slave *slave, const 
struct spi_mem_op *op)
struct spi_mem_op *mut_op = (struct spi_mem_op *)op;
u8 op_len = sizeof(op->cmd.opcode) + op->addr.nbytes + op->dummy.nbytes;
u8 op_buf[op_len];
-   u32 cr0, val;
+   u32 cr0, spi_cr0, val;
+
+   /* Only bytes are supported for spi-mem transfers */
+   if (priv->bits_per_word != 8)
+   return -EINVAL;
+
+   switch (op->data.buswidth) {
+   case 0:
+   case 1:
+   priv->spi_frf = CTRLR0_SPI_FRF_BYTE;
+   break;
+   case 2:
+   priv->spi_frf = 

[PATCH 14/14] riscv: k210: Enable QSPI for spi3

[Sean Anderson]

This device has four IOs connected to the SPI flash. Add the appropriate
bindings.

Signed-off-by: Sean Anderson 
---

 arch/riscv/dts/k210-maix-bit.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/dts/k210-maix-bit.dts b/arch/riscv/dts/k210-maix-bit.dts
index e4dea205b2..902dcfd08a 100644
--- a/arch/riscv/dts/k210-maix-bit.dts
+++ b/arch/riscv/dts/k210-maix-bit.dts
@@ -200,6 +200,8 @@
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <5000>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
m25p,fast-read;
broken-flash-reset;
};
-- 
2.29.2

[PATCH 13/14] spi: dw: Support clock stretching

[Sean Anderson]

We don't always read/write to the FIFO fast enough. Enable clock stretching
for enhanced SPI transfers. This is only possible with DWC SSI devices more
recent than 1.01a. We also need to set the RXFTLR register to tell the
device when to start reciving again. In particular, the default of 0 will
result in the device never restarting reception if there is an overflow. On
the transmit side, we need to set CTRL1 so that the device knows when to
keep stretching the clock if the FIFO is empty.

Signed-off-by: Sean Anderson 
---

 drivers/spi/designware_spi.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index 4796d55b20..78da490c3e 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -254,7 +254,8 @@ static u32 dw_spi_update_spi_cr0(const struct spi_mem_op 
*op)
return FIELD_PREP(SPI_CTRLR0_TRANS_TYPE, trans_type)
   | FIELD_PREP(SPI_CTRLR0_ADDR_L_MASK, op->addr.nbytes * 2)
   | FIELD_PREP(SPI_CTRLR0_INST_L_MASK, 2)
-  | FIELD_PREP(SPI_CTRLR0_WAIT_CYCLES_MASK, wait_cycles);
+  | FIELD_PREP(SPI_CTRLR0_WAIT_CYCLES_MASK, wait_cycles)
+  | SPI_CTRLR0_CLK_STRETCH_EN;
 }
 
 static int request_gpio_cs(struct udevice *bus)
@@ -356,6 +357,9 @@ static void spi_hw_init(struct udevice *bus, struct 
dw_spi_priv *priv)
priv->fifo_len = (fifo == 1) ? 0 : fifo;
dw_write(priv, DW_SPI_TXFTLR, 0);
}
+
+   /* Set receive fifo interrupt level register for clock stretching */
+   dw_write(priv, DW_SPI_RXFTLR, priv->fifo_len - 1);
 }
 
 /*
@@ -778,8 +782,7 @@ static int dw_spi_exec_op(struct spi_slave *slave, const 
struct spi_mem_op *op)
 
dw_write(priv, DW_SPI_SSIENR, 0);
dw_write(priv, DW_SPI_CTRLR0, cr0);
-   if (read)
-   dw_write(priv, DW_SPI_CTRLR1, op->data.nbytes - 1);
+   dw_write(priv, DW_SPI_CTRLR1, op->data.nbytes - 1);
if (priv->spi_frf != CTRLR0_SPI_FRF_BYTE)
dw_write(priv, DW_SPI_SPI_CTRL0, spi_cr0);
dw_write(priv, DW_SPI_SSIENR, 1);
-- 
2.29.2

[PATCH 09/14] spi: dw: Rewrite poll_transfer logic

[Sean Anderson]

This rewrites poll_transfer, dw_writer, and dw_reader.

* We now use RO transfers (instead of always using TR). This eliminates the
  need to send out dummy words, and simplifies the transmit logic.
* All parameters (except regs and bits_per_word) are passed explicitly.
* Most parameters have been made explicit (instead of being recalculated on
  every loop).
* Transfers are measured in units of frames instead of bytes. This matches
  the measurements used by the device and eliminates several divisions by
  bits_per_word.
* We now check if we have over-/under-flowed the FIFO. This should help
  prevent hangs when the device stops the transfer and U-Boot doesn't
  realize it (and then waits for the remaining data forever). TXUI is not
  present in DW_APB_SSI, but in the worst case we just don't write data.

  Unfortunately, this doesn't seem to solve all problems, and there are
  some remaining bugs (such as some transfers containing all 1s or all 0s)
  when we have many fifo overflows. This is solved for DWC devices by
  enabling clock stretching.
* poll_transfer is now used by dw_spi_exec_op as well as xfer.
* There are separate inner loops for 8-, 16-, and 32-bit frame sizes. This
  should hopefully reduce the amount of over-/under-flows. However, I
  haven't done exhaustive testing to ensure this is really necessary. In
  particular, I was never able to prevent read overflows at 50MHz clock
  speed.

These changes should probably have been split up into several commits, but
several depend on each other, and it would be difficult to break this up
while preserving bisectability.

Signed-off-by: Sean Anderson 
---

 drivers/spi/designware_spi.c | 284 +--
 1 file changed, 171 insertions(+), 113 deletions(-)

diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index 9a30a677c8..683394a5a4 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -134,14 +134,10 @@ struct dw_spi_priv {
unsigned int freq;  /* Default frequency */
unsigned int mode;
 
-   const void *tx;
-   const void *tx_end;
-   void *rx;
-   void *rx_end;
u32 fifo_len;   /* depth of the FIFO buffer */
 
int bits_per_word;
-   int len;
+   int frames; /* Number of frames in the transfer */
u8 cs;  /* chip select pin */
u8 tmode;   /* TR/TO/RO/EEPROM */
u8 type;/* SPI/SSP/MicroWire */
@@ -374,14 +370,24 @@ static int dw_spi_probe(struct udevice *bus)
return 0;
 }
 
-/* Return the max entries we can fill into tx fifo */
-static inline u32 tx_max(struct dw_spi_priv *priv)
+/**
+ * dw_writer() - Write data frames to the tx fifo
+ * @priv: Driver private info
+ * @tx: The tx buffer
+ * @idx: The number of data frames already transmitted
+ * @tx_frames: The number of data frames left to transmit
+ * @rx_frames: The number of data frames left to receive (0 if only
+ * transmitting)
+ * @frame_bytes: The number of bytes taken up by one data frame
+ *
+ * This function writes up to @tx_frames data frames using data from @tx[@idx].
+ *
+ * Return: The number of frames read
+ */
+static uint dw_writer(struct dw_spi_priv *priv, const void *tx, uint idx,
+ uint tx_frames, uint rx_frames, uint frame_bytes)
 {
-   u32 tx_left, tx_room, rxtx_gap;
-
-   tx_left = (priv->tx_end - priv->tx) / (priv->bits_per_word >> 3);
-   tx_room = priv->fifo_len - dw_read(priv, DW_SPI_TXFLR);
-
+   u32 tx_room = priv->fifo_len - dw_read(priv, DW_SPI_TXFLR);
/*
 * Another concern is about the tx/rx mismatch, we
 * thought about using (priv->fifo_len - rxflr - txflr) as
@@ -390,67 +396,131 @@ static inline u32 tx_max(struct dw_spi_priv *priv)
 * shift registers. So a control from sw point of
 * view is taken.
 */
-   rxtx_gap = ((priv->rx_end - priv->rx) - (priv->tx_end - priv->tx)) /
-   (priv->bits_per_word >> 3);
+   u32 rxtx_gap = rx_frames - tx_frames;
+   u32 count = min3(tx_frames, tx_room, (u32)(priv->fifo_len - rxtx_gap));
+   u32 *dr = priv->regs + DW_SPI_DR;
 
-   return min3(tx_left, tx_room, (u32)(priv->fifo_len - rxtx_gap));
-}
+   if (!count)
+   return 0;
 
-/* Return the max entries we should read out of rx fifo */
-static inline u32 rx_max(struct dw_spi_priv *priv)
-{
-   u32 rx_left = (priv->rx_end - priv->rx) / (priv->bits_per_word >> 3);
-
-   return min_t(u32, rx_left, dw_read(priv, DW_SPI_RXFLR));
-}
-
-static void dw_writer(struct dw_spi_priv *priv)
-{
-   u32 max = tx_max(priv);
-   u32 txw = 0x;
-
-   while (max--) {
-   /* Set the tx word if the transfer's original "tx" is not null 
*/
-   if (priv->tx_end - priv->len) {
-   if (priv->bits_per_word == 8)
-

[PATCH 10/14] spi: dw: Add DUAL/QUAD/OCTAL caps

[Sean Anderson]

These capabilities correspond to SSIC_SPI_MODE of 1, 2, or 3, respectively.
This doesn't do much yet, but it does add support for detection and for
disallowing unsupported modes.  Unfortunately, we cannot discriminate
between these modes (only that SSIC_SPI_MODE != 0), so we only assume DUAL
if something sticks to SPI_FRF.

Signed-off-by: Sean Anderson 
---

 drivers/spi/designware_spi.c | 41 +---
 1 file changed, 29 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index 683394a5a4..1dd83e6ca6 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -129,6 +129,9 @@ struct dw_spi_priv {
 #define DW_SPI_CAP_KEEMBAY_MST BIT(1) /* Unimplemented */
 #define DW_SPI_CAP_DWC_SSI BIT(2)
 #define DW_SPI_CAP_DFS32   BIT(3)
+#define DW_SPI_CAP_DUALBIT(4)
+#define DW_SPI_CAP_QUADBIT(5)
+#define DW_SPI_CAP_OCTAL   BIT(5)
unsigned long caps;
unsigned long bus_clk_rate;
unsigned int freq;  /* Default frequency */
@@ -141,6 +144,7 @@ struct dw_spi_priv {
u8 cs;  /* chip select pin */
u8 tmode;   /* TR/TO/RO/EEPROM */
u8 type;/* SPI/SSP/MicroWire */
+   u8 spi_frf; /* BYTE/DUAL/QUAD/OCTAL */
 };
 
 static inline u32 dw_read(struct dw_spi_priv *priv, u32 offset)
@@ -267,7 +271,6 @@ static void spi_hw_init(struct udevice *bus, struct 
dw_spi_priv *priv)
priv->fifo_len = (fifo == 1) ? 0 : fifo;
dw_write(priv, DW_SPI_TXFTLR, 0);
}
-   dev_dbg(bus, "fifo_len=%d\n", priv->fifo_len);
 }
 
 /*
@@ -351,22 +354,21 @@ static int dw_spi_probe(struct udevice *bus)
if (ret)
return ret;
 
-   priv->caps = dev_get_driver_data(bus);
-   dw_spi_detect_caps(bus, priv);
-
-   version = dw_read(priv, DW_SPI_VERSION);
-   dev_dbg(bus, "ssi_version_id=%c.%c%c%c ssi_max_xfer_size=%u\n",
-   version >> 24, version >> 16, version >> 8, version,
-   priv->caps & DW_SPI_CAP_DFS32 ? 32 : 16);
-
/* Currently only bits_per_word == 8 supported */
priv->bits_per_word = 8;
 
priv->tmode = 0; /* Tx & Rx */
 
/* Basic HW init */
+   priv->caps = dev_get_driver_data(bus);
spi_hw_init(bus, priv);
 
+   version = dw_read(priv, DW_SPI_VERSION);
+   dev_dbg(bus,
+   "ssi_version_id=%c.%c%c%c ssi_rx_fifo_depth=%u 
ssi_max_xfer_size=%u\n",
+   version >> 24, version >> 16, version >> 8, version,
+   priv->fifo_len, priv->caps & DW_SPI_CAP_DFS32 ? 32 : 16);
+
return 0;
 }
 
@@ -748,13 +750,25 @@ static int dw_spi_set_mode(struct udevice *bus, uint mode)
 {
struct dw_spi_priv *priv = dev_get_priv(bus);
 
+   if (!(priv->caps & DW_SPI_CAP_DUAL) &&
+   (mode & (SPI_RX_DUAL | SPI_TX_DUAL)))
+   return -EINVAL;
+
+   if (!(priv->caps & DW_SPI_CAP_QUAD) &&
+   (mode & (SPI_RX_QUAD | SPI_TX_QUAD)))
+   return -EINVAL;
+
+   if (!(priv->caps & DW_SPI_CAP_OCTAL) &&
+   (mode & (SPI_RX_OCTAL | SPI_TX_OCTAL)))
+   return -EINVAL;
+
/*
 * Can't set mode yet. Since this depends on if rx, tx, or
 * rx & tx is requested. So we have to defer this to the
 * real transfer function.
 */
priv->mode = mode;
-   dev_dbg(bus, "mode=%d\n", priv->mode);
+   dev_dbg(bus, "mode=%x\n", mode);
 
return 0;
 }
@@ -813,10 +827,13 @@ static const struct udevice_id dw_spi_ids[] = {
 */
{ .compatible = "altr,socfpga-spi" },
{ .compatible = "altr,socfpga-arria10-spi" },
-   { .compatible = "canaan,kendryte-k210-spi" },
+   {
+   .compatible = "canaan,kendryte-k210-spi",
+   .data = DW_SPI_CAP_QUAD | DW_SPI_CAP_OCTAL,
+   },
{
.compatible = "canaan,kendryte-k210-ssi",
-   .data = DW_SPI_CAP_DWC_SSI,
+   .data = DW_SPI_CAP_DWC_SSI | DW_SPI_CAP_QUAD,
},
{ .compatible = "intel,stratix10-spi" },
{ .compatible = "intel,agilex-spi" },
-- 
2.29.2

[PATCH 11/14] spi: dw: Add registers necessary for DUAL/QUAD/OCTAL

[Sean Anderson]

This adds some registers needed for DUAL/QUAD/OCTAL modes. It also adds the
fields in (R)ISR so we can check for over-/under-flow.

Signed-off-by: Sean Anderson 
---

 drivers/spi/designware_spi.c | 55 ++--
 1 file changed, 52 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index 1dd83e6ca6..169888a06d 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -56,6 +56,8 @@
 #define DW_SPI_IDR 0x58
 #define DW_SPI_VERSION 0x5c
 #define DW_SPI_DR  0x60
+#define DW_SPI_RX_SAMPLE_DLY   0xf0
+#define DW_SPI_SPI_CTRL0   0xf4
 
 /* Bit fields in CTRLR0 */
 /*
@@ -80,8 +82,8 @@
 #define CTRLR0_TMOD_RO 0x2 /* recv only */
 #define CTRLR0_TMOD_EPROMREAD  0x3 /* eeprom read mode */
 
-#define CTRLR0_SLVOE_OFFSET10
-#define CTRLR0_SRL_OFFSET  11
+#define CTRLR0_SLVOE_OFFSETBIT(10)
+#define CTRLR0_SRL BIT(11)
 #define CTRLR0_CFS_MASKGENMASK(15, 12)
 
 /* Only present when SSI_MAX_XFER_SIZE=32 */
@@ -92,13 +94,15 @@
 #define CTRLR0_SPI_FRF_BYTE0x0
 #defineCTRLR0_SPI_FRF_DUAL 0x1
 #defineCTRLR0_SPI_FRF_QUAD 0x2
+#defineCTRLR0_SPI_FRF_OCTAL0x3
 
 /* Bit fields in CTRLR0 based on DWC_ssi_databook.pdf v1.01a */
 #define DWC_SSI_CTRLR0_DFS_MASKGENMASK(4, 0)
 #define DWC_SSI_CTRLR0_FRF_MASKGENMASK(7, 6)
 #define DWC_SSI_CTRLR0_MODE_MASK   GENMASK(9, 8)
 #define DWC_SSI_CTRLR0_TMOD_MASK   GENMASK(11, 10)
-#define DWC_SSI_CTRLR0_SRL_OFFSET  13
+#define DWC_SSI_CTRLR0_SRL BIT(13)
+#define DWC_SSI_CTRLR0_SSTEBIT(14)
 #define DWC_SSI_CTRLR0_SPI_FRF_MASKGENMASK(23, 22)
 
 /* Bit fields in SR, 7 bits */
@@ -111,6 +115,51 @@
 #define SR_TX_ERR  BIT(5)
 #define SR_DCOLBIT(6)
 
+/* Bit fields in (R)ISR */
+
+/* TX FIFO Empty */
+#define ISR_TXEI   BIT(0)
+/* TX FIFO Overflow */
+#define ISR_TXOI   BIT(1)
+/* RX FIFO Underflow */
+#define ISR_RXUI   BIT(2)
+/* RX FIFO Overflow */
+#define ISR_RXOI   BIT(3)
+/* RX FIFO Full */
+#define ISR_RXFI   BIT(4)
+/* Multi-master contention */
+#define ISR_MSTI   BIT(5)
+/* XIP Receive FIFO Overflow */
+#define ISR_XRXOI  BIT(6)
+/* TX FIFO Underflow */
+#define ISR_TXUI   BIT(7)
+/* AXI Error */
+#define ISR_AXIE   BIT(8)
+/* SPI TX Error */
+#define ISR_SPITE  BIT(10)
+/* SSI Done */
+#define ISR_DONE   BIT(11)
+
+/* Bit fields in SPI_CTRLR0 */
+
+/*
+ * Whether the instruction or address use the value of SPI_FRF or use
+ * FRF_BYTE
+ */
+#define SPI_CTRLR0_TRANS_TYPE  GENMASK(1, 0)
+#define SPI_CTRLR0_TRANS_TYPE_1_1_X0x0
+#define SPI_CTRLR0_TRANS_TYPE_1_X_X0x1
+#define SPI_CTRLR0_TRANS_TYPE_X_X_X0x2
+/* Address width in 4-bit units */
+#define SPI_CTRLR0_ADDR_L_MASK GENMASK(5, 2)
+/* Enable mode bits after address in XIP mode */
+#define SPI_CTRLR0_XIP_MD_BIT_EN   BIT(7)
+/* Instruction width in 4-bit units */
+#define SPI_CTRLR0_INST_L_MASK GENMASK(9, 8)
+/* Number of "dummy" cycles */
+#define SPI_CTRLR0_WAIT_CYCLES_MASKGENMASK(15, 11)
+#define SPI_CTRLR0_CLK_STRETCH_EN  BIT(30)
+
 #define RX_TIMEOUT 1000/* timeout in ms */
 
 struct dw_spi_plat {
-- 
2.29.2

[PATCH 08/14] spi: dw: Switch to capabilities

[Sean Anderson]

Since Linux commit cc760f3143f5 ("spi: dw: Convert CS-override to DW SPI
capabilities"), the Linux driver has used capability flags instead of
using ad-hoc flags and functions. This is a great idea, and we should use
it as well.

The .data field in the compatible array has switched from being an
initialization function to being a set of default capabilities. This is
necessary since some capabilities cannot be determined at runtime.

Signed-off-by: Sean Anderson 
---

 drivers/spi/designware_spi.c | 141 +--
 1 file changed, 69 insertions(+), 72 deletions(-)

diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index 29ec1503fd..9a30a677c8 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -123,9 +123,13 @@ struct dw_spi_priv {
struct reset_ctl_bulk resets;
struct gpio_desc cs_gpio;   /* External chip-select gpio */
 
-   u32 (*update_cr0)(struct dw_spi_priv *priv);
-
void __iomem *regs;
+/* DW SPI capabilities */
+#define DW_SPI_CAP_CS_OVERRIDE BIT(0) /* Unimplemented */
+#define DW_SPI_CAP_KEEMBAY_MST BIT(1) /* Unimplemented */
+#define DW_SPI_CAP_DWC_SSI BIT(2)
+#define DW_SPI_CAP_DFS32   BIT(3)
+   unsigned long caps;
unsigned long bus_clk_rate;
unsigned int freq;  /* Default frequency */
unsigned int mode;
@@ -135,7 +139,6 @@ struct dw_spi_priv {
void *rx;
void *rx_end;
u32 fifo_len;   /* depth of the FIFO buffer */
-   u32 max_xfer;   /* Maximum transfer size (in bits) */
 
int bits_per_word;
int len;
@@ -154,51 +157,30 @@ static inline void dw_write(struct dw_spi_priv *priv, u32 
offset, u32 val)
__raw_writel(val, priv->regs + offset);
 }
 
-static u32 dw_spi_dw16_update_cr0(struct dw_spi_priv *priv)
+static u32 dw_spi_update_cr0(struct dw_spi_priv *priv)
 {
-   return FIELD_PREP(CTRLR0_DFS_MASK, priv->bits_per_word - 1)
-| FIELD_PREP(CTRLR0_FRF_MASK, priv->type)
-| FIELD_PREP(CTRLR0_MODE_MASK, priv->mode)
-| FIELD_PREP(CTRLR0_TMOD_MASK, priv->tmode);
-}
+   u32 cr0;
 
-static u32 dw_spi_dw32_update_cr0(struct dw_spi_priv *priv)
-{
-   return FIELD_PREP(CTRLR0_DFS_32_MASK, priv->bits_per_word - 1)
-| FIELD_PREP(CTRLR0_FRF_MASK, priv->type)
-| FIELD_PREP(CTRLR0_MODE_MASK, priv->mode)
-| FIELD_PREP(CTRLR0_TMOD_MASK, priv->tmode);
-}
-
-static u32 dw_spi_dwc_update_cr0(struct dw_spi_priv *priv)
-{
-   return FIELD_PREP(DWC_SSI_CTRLR0_DFS_MASK, priv->bits_per_word - 1)
-| FIELD_PREP(DWC_SSI_CTRLR0_FRF_MASK, priv->type)
-| FIELD_PREP(DWC_SSI_CTRLR0_MODE_MASK, priv->mode)
-| FIELD_PREP(DWC_SSI_CTRLR0_TMOD_MASK, priv->tmode);
-}
-
-static int dw_spi_apb_init(struct udevice *bus, struct dw_spi_priv *priv)
-{
-   /* If we read zeros from DFS, then we need to use DFS_32 instead */
-   dw_write(priv, DW_SPI_SSIENR, 0);
-   dw_write(priv, DW_SPI_CTRLR0, 0x);
-   if (FIELD_GET(CTRLR0_DFS_MASK, dw_read(priv, DW_SPI_CTRLR0))) {
-   priv->max_xfer = 16;
-   priv->update_cr0 = dw_spi_dw16_update_cr0;
+   if (priv->caps & DW_SPI_CAP_DWC_SSI) {
+   cr0 = FIELD_PREP(DWC_SSI_CTRLR0_DFS_MASK,
+priv->bits_per_word - 1)
+   | FIELD_PREP(DWC_SSI_CTRLR0_FRF_MASK, priv->type)
+   | FIELD_PREP(DWC_SSI_CTRLR0_MODE_MASK, priv->mode)
+   | FIELD_PREP(DWC_SSI_CTRLR0_TMOD_MASK, priv->tmode);
} else {
-   priv->max_xfer = 32;
-   priv->update_cr0 = dw_spi_dw32_update_cr0;
+   if (priv->caps & DW_SPI_CAP_DFS32)
+   cr0 = FIELD_PREP(CTRLR0_DFS_32_MASK,
+priv->bits_per_word - 1);
+   else
+   cr0 = FIELD_PREP(CTRLR0_DFS_MASK,
+priv->bits_per_word - 1);
+
+   cr0 |= FIELD_PREP(CTRLR0_FRF_MASK, priv->type)
+   |  FIELD_PREP(CTRLR0_MODE_MASK, priv->mode)
+   |  FIELD_PREP(CTRLR0_TMOD_MASK, priv->tmode);
}
 
-   return 0;
-}
-
-static int dw_spi_dwc_init(struct udevice *bus, struct dw_spi_priv *priv)
-{
-   priv->max_xfer = 32;
-   priv->update_cr0 = dw_spi_dwc_update_cr0;
-   return 0;
+   return cr0;
 }
 
 static int request_gpio_cs(struct udevice *bus)
@@ -251,8 +233,26 @@ static int dw_spi_of_to_plat(struct udevice *bus)
 /* Restart the controller, disable all interrupts, clean rx fifo */
 static void spi_hw_init(struct udevice *bus, struct dw_spi_priv *priv)
 {
+   u32 cr0;
+
dw_write(priv, DW_SPI_SSIENR, 0);
dw_write(priv, DW_SPI_IMR, 0x);
+
+   /*
+* Detect features by writing CTRLR0 and seeing which fields remain
+  

[PATCH 07/14] spi: dw: Mask all possible interrupts

[Sean Anderson]

DWC_SPI has more than 8 interrupts. Write to the whole IMR to mask
everything.

Signed-off-by: Sean Anderson 
---

 drivers/spi/designware_spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index 519d6e32bd..29ec1503fd 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -252,7 +252,7 @@ static int dw_spi_of_to_plat(struct udevice *bus)
 static void spi_hw_init(struct udevice *bus, struct dw_spi_priv *priv)
 {
dw_write(priv, DW_SPI_SSIENR, 0);
-   dw_write(priv, DW_SPI_IMR, 0xff);
+   dw_write(priv, DW_SPI_IMR, 0x);
dw_write(priv, DW_SPI_SSIENR, 1);
 
/*
-- 
2.29.2

[PATCH 05/14] spi: spi-mem: Add debug message for spi-mem ops

[Sean Anderson]

This prints some basic metadata about the SPI memory op. This information
may be used to debug SPI drivers (e.g. determining the expected SPI mode).
It is also helpful for verifying that the data on the wire matches the data
intended to be transmitted (e.g. with a logic analyzer). The opcode is
printed with a format of %02Xh to match the notation commonly used in flash
datasheets.

Signed-off-by: Sean Anderson 
---

 drivers/spi/spi-mem.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index c095ae9505..eb83c11910 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -220,6 +220,12 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct 
spi_mem_op *op)
int ret;
int i;
 
+   dev_dbg(slave->dev, "exec %02Xh %u-%u-%u addr=%llx wait=%u len=%u\n",
+   op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
+   op->data.buswidth, op->addr.val,
+   op->dummy.buswidth ? op->dummy.nbytes * 8 / op->dummy.buswidth 
: 0,
+   op->data.nbytes);
+
if (!spi_mem_supports_op(slave, op))
return -ENOTSUPP;
 
-- 
2.29.2

[PATCH 06/14] spi: dw: Log status register on timeout

[Sean Anderson]

This logs the status register on timeout, so it is easier to determine the
cause of the failure.

Signed-off-by: Sean Anderson 
---

 drivers/spi/designware_spi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index 742121140d..519d6e32bd 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -552,6 +552,7 @@ static int dw_spi_xfer(struct udevice *dev, unsigned int 
bitlen,
if (readl_poll_timeout(priv->regs + DW_SPI_SR, val,
   (val & SR_TF_EMPT) && !(val & SR_BUSY),
   RX_TIMEOUT * 1000)) {
+   dev_dbg(bus, "timed out; sr=%x\n", dw_read(priv, DW_SPI_SR));
ret = -ETIMEDOUT;
}
 
@@ -639,6 +640,8 @@ static int dw_spi_exec_op(struct spi_slave *slave, const 
struct spi_mem_op *op)
if (readl_poll_timeout(priv->regs + DW_SPI_SR, val,
   (val & SR_TF_EMPT) && !(val & SR_BUSY),
   RX_TIMEOUT * 1000)) {
+   dev_dbg(bus, "timed out; sr=%x\n",
+   dw_read(priv, DW_SPI_SR));
ret = -ETIMEDOUT;
}
}
-- 
2.29.2

[PATCH 03/14] mtd: spi-nor-core: Fix typo in documentation

[Sean Anderson]

This line should come before the docs for the next function.

Fixes: 7aeedac0153 ("mtd: spi: Port SPI NOR framework from Linux")

Signed-off-by: Sean Anderson 
---

 include/linux/mtd/spi-nor.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 4a8e19ee4f..39ef872ebf 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -302,8 +302,8 @@ struct spi_flash {
  * @flash_lock:[FLASH-SPECIFIC] lock a region of the SPI NOR
  * @flash_unlock:  [FLASH-SPECIFIC] unlock a region of the SPI NOR
  * @flash_is_locked:   [FLASH-SPECIFIC] check if a region of the SPI NOR is
- * @quad_enable:   [FLASH-SPECIFIC] enables SPI NOR quad mode
  * completely locked
+ * @quad_enable:   [FLASH-SPECIFIC] enables SPI NOR quad mode
  * @priv:  the private data
  */
 struct spi_nor {
-- 
2.29.2

[PATCH 02/14] cmd: sf: Print error on test failure

[Sean Anderson]

The sf test command is used to test spi flashes (and spi masters). Printing
the exact error code is very helpful to those debugging the spi stack.

Signed-off-by: Sean Anderson 
---

 cmd/sf.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/cmd/sf.c b/cmd/sf.c
index de80fcd38b..46346fb9d4 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -445,20 +445,22 @@ static int spi_flash_test(struct spi_flash *flash, 
uint8_t *buf, ulong len,
   ulong offset, uint8_t *vbuf)
 {
struct test_info test;
-   int i;
+   int err, i;
 
printf("SPI flash test:\n");
memset(, '\0', sizeof(test));
test.base_ms = get_timer(0);
test.bytes = len;
-   if (spi_flash_erase(flash, offset, len)) {
-   printf("Erase failed\n");
+   err = spi_flash_erase(flash, offset, len);
+   if (err) {
+   printf("Erase failed (err = %d)\n", err);
return -1;
}
spi_test_next_stage();
 
-   if (spi_flash_read(flash, offset, len, vbuf)) {
-   printf("Check read failed\n");
+   err = spi_flash_read(flash, offset, len, vbuf);
+   if (err) {
+   printf("Check read failed (err = %d)\n", err);
return -1;
}
for (i = 0; i < len; i++) {
@@ -471,15 +473,17 @@ static int spi_flash_test(struct spi_flash *flash, 
uint8_t *buf, ulong len,
}
spi_test_next_stage();
 
-   if (spi_flash_write(flash, offset, len, buf)) {
-   printf("Write failed\n");
+   err = spi_flash_write(flash, offset, len, buf);
+   if (err) {
+   printf("Write failed (err = %d)\n", err);
return -1;
}
memset(vbuf, '\0', len);
spi_test_next_stage();
 
-   if (spi_flash_read(flash, offset, len, vbuf)) {
-   printf("Read failed\n");
+   err = spi_flash_read(flash, offset, len, vbuf);
+   if (err) {
+   printf("Read failed (ret = %d)\n", err);
return -1;
}
spi_test_next_stage();
-- 
2.29.2

[PATCH 04/14] mtd: spi-mem: Export spi_mem_default_supports_op

[Sean Anderson]

This is useful for extending the default functionality.

Signed-off-by: Sean Anderson 
---

 include/spi-mem.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/spi-mem.h b/include/spi-mem.h
index ca0f55c8fd..1dd556b6cf 100644
--- a/include/spi-mem.h
+++ b/include/spi-mem.h
@@ -236,6 +236,9 @@ spi_controller_dma_unmap_mem_op_data(struct spi_controller 
*ctlr,
 
 int spi_mem_adjust_op_size(struct spi_slave *slave, struct spi_mem_op *op);
 
+bool spi_mem_default_supports_op(struct spi_slave *slave,
+const struct spi_mem_op *op);
+
 bool spi_mem_supports_op(struct spi_slave *slave, const struct spi_mem_op *op);
 
 int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op);
-- 
2.29.2

[PATCH 01/14] cmd: sf: Display errno on erase failure

[Sean Anderson]

If there is an error while erasing SPI flash, no errno is displayed. This
makes it difficult to determine the cause of the error. This change mirrors
the logic for write errors above.

Signed-off-by: Sean Anderson 
---

 cmd/sf.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/cmd/sf.c b/cmd/sf.c
index c0d6a8f8a0..de80fcd38b 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -344,8 +344,11 @@ static int do_spi_flash_erase(int argc, char *const argv[])
}
 
ret = spi_flash_erase(flash, offset, size);
-   printf("SF: %zu bytes @ %#x Erased: %s\n", (size_t)size, (u32)offset,
-  ret ? "ERROR" : "OK");
+   printf("SF: %zu bytes @ %#x Erased: ", (size_t)size, (u32)offset);
+   if (ret)
+   printf("ERROR %d\n", ret);
+   else
+   printf("OK\n");
 
return ret == 0 ? 0 : 1;
 }
-- 
2.29.2

[PATCH 00/14] spi: dw: Add support for DUAL/QUAD/OCTAL modes

[Sean Anderson]

This series adds support for enhanced SPI modes. It was tested on a K210 (DWC
SSI with QSPI flash).

If anyone has a designware device with QSPI flash attached (especially a DW SSI
APB device), I'd greatly appreciate them testing out this patch series.

Many of the earlier patches in this series are general fixups and can be split
off/merged separately if desired.


Sean Anderson (14):
  cmd: sf: Display errno on erase failure
  cmd: sf: Print error on test failure
  mtd: spi-nor-core: Fix typo in documentation
  mtd: spi-mem: Export spi_mem_default_supports_op
  spi: spi-mem: Add debug message for spi-mem ops
  spi: dw: Log status register on timeout
  spi: dw: Mask all possible interrupts
  spi: dw: Switch to capabilities
  spi: dw: Rewrite poll_transfer logic
  spi: dw: Add DUAL/QUAD/OCTAL caps
  spi: dw: Add registers necessary for DUAL/QUAD/OCTAL
  spi: dw: Support DUAL/QUAD/OCTAL
  spi: dw: Support clock stretching
  riscv: k210: Enable QSPI for spi3

 arch/riscv/dts/k210-maix-bit.dts |   2 +
 cmd/sf.c |  29 +-
 drivers/spi/designware_spi.c | 652 +--
 drivers/spi/spi-mem.c|   6 +
 include/linux/mtd/spi-nor.h  |   2 +-
 include/spi-mem.h|   3 +
 6 files changed, 476 insertions(+), 218 deletions(-)

-- 
2.29.2

Pull request: u-boot-sunxi/master for v2021.04 (part 3)

[Andre Przywara]

Hi Tom,

please pull the master branch from u-boot-sunxi, containing some late
sunxi patches for the 2021.04 merge window:
-
- Allwinner H616 Ethernet support
- sunxi ata debug fix
-

The H616 Ethernet support was used for a long time, but was reworked
later in the development phase, and now rebased on top of the already
committed H616 support. And having Ethernet is so convenient, especially
for the ongoing kernel development.

Thanks,
Andre

=
The following changes since commit 76404f86a24aa28efc26a296bf6ab9d697c60b9f:

  Merge tag 'efi-2021-04-rc1-4' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2021-01-30 14:49:17 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi.git master

for you to fetch changes up to a38bb0d0377dd47dfc9270fb46112bca263e8885:

  ata: sunxi: fix debug messages (2021-01-31 23:55:56 +)


Andre Przywara (3):
  net: sun8i-emac: Always clear syscon EPHY register
  net: sun8i-emac: Determine pinmux based on SoC, not EMAC type
  sunxi: OrangePi Zero 2: Enable Ethernet

Dario Binacchi (1):
  ata: sunxi: fix debug messages

 configs/orangepi_zero2_defconfig |  2 ++
 drivers/ata/ahci_sunxi.c |  8 +++---
 drivers/net/sun8i_emac.c | 59 ++--
 3 files changed, 39 insertions(+), 30 deletions(-)

[PATCH v2 1/1] sandbox: mark os_abort() as noreturn

[Heinrich Schuchardt]

gcc -fanalyzer needs the information that a function does not return to
provide accurate information.

os_abort() does not return. Mark it accordingly.

Signed-off-by: Heinrich Schuchardt 
---
v2:
use __attribute__((noreturn)) instead of __return
---
 include/os.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/os.h b/include/os.h
index e192e32d59..65bcb232ca 100644
--- a/include/os.h
+++ b/include/os.h
@@ -341,7 +341,7 @@ void os_localtime(struct rtc_time *rt);
 /**
  * os_abort() - raise SIGABRT to exit sandbox (e.g. to debugger)
  */
-void os_abort(void);
+void os_abort(void) __attribute__((noreturn));

 /**
  * os_mprotect_allow() - Remove write-protection on a region of memory
--
2.29.2

[PATCH 1/1] sandbox: mark os_abort() as __noreturn

[Heinrich Schuchardt]

gcc -fanalyzer needs the information that a function does not return to
provide accurate information.

os_abort() does not return. Mark it accordingly.

Signed-off-by: Heinrich Schuchardt 
---
 include/os.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/os.h b/include/os.h
index e192e32d59..8de802cab0 100644
--- a/include/os.h
+++ b/include/os.h
@@ -341,7 +341,7 @@ void os_localtime(struct rtc_time *rt);
 /**
  * os_abort() - raise SIGABRT to exit sandbox (e.g. to debugger)
  */
-void os_abort(void);
+void __noreturn os_abort(void);

 /**
  * os_mprotect_allow() - Remove write-protection on a region of memory
--
2.29.2

Re: [PATCH] video: Drop unprintable characters from video_font_data.h

[Simon Glass]

+Anatolij Gustschin  which did not happen automatically, sorry


On Wed, 16 Dec 2020 at 20:52, Simon Glass  wrote:
>
> This file contains characters which are not valid in utf-8. This confuses
> dtoc which wants to parse it. They don't really serve any purpose anyway,
> so drop them.
>
> To: U-Boot Mailing List 
> Cc: Tom Rini 
>
> Signed-off-by: Simon Glass 
> ---
>  include/video_font_data.h | 258 +++---
>  1 file changed, 129 insertions(+), 129 deletions(-)
>
> diff --git a/include/video_font_data.h b/include/video_font_data.h
> index ed5fd640a80..6e64198d1a4 100644
> --- a/include/video_font_data.h
> +++ b/include/video_font_data.h
> @@ -2302,7 +2302,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 127 0x7f ' ' */
> +   /* 127 0x7f */
> 0x00, /*  */
> 0x00, /*  */
> 0x00, /*  */
> @@ -2320,7 +2320,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 128 0x80 '€' */
> +   /* 128 0x80 */
> 0x00, /*  */
> 0x00, /*  */
> 0x3c, /* 0000 */
> @@ -2338,7 +2338,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 129 0x81 ' ' */
> +   /* 129 0x81 */
> 0x00, /*  */
> 0x00, /*  */
> 0xcc, /* 11001100 */
> @@ -2356,7 +2356,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 130 0x82 '‚' */
> +   /* 130 0x82 */
> 0x00, /*  */
> 0x0c, /* 1100 */
> 0x18, /* 00011000 */
> @@ -2374,7 +2374,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 131 0x83 'ƒ' */
> +   /* 131 0x83 */
> 0x00, /*  */
> 0x10, /* 0001 */
> 0x38, /* 00111000 */
> @@ -2392,7 +2392,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 132 0x84 '„' */
> +   /* 132 0x84 */
> 0x00, /*  */
> 0x00, /*  */
> 0xcc, /* 11001100 */
> @@ -2410,7 +2410,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 133 0x85 '…' */
> +   /* 133 0x85 */
> 0x00, /*  */
> 0x60, /* 0110 */
> 0x30, /* 0011 */
> @@ -2428,7 +2428,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 134 0x86 '†' */
> +   /* 134 0x86 */
> 0x00, /*  */
> 0x38, /* 00111000 */
> 0x6c, /* 01101100 */
> @@ -2446,7 +2446,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 135 0x87 '‡' */
> +   /* 135 0x87 */
> 0x00, /*  */
> 0x00, /*  */
> 0x00, /*  */
> @@ -2464,7 +2464,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 136 0x88 'ˆ' */
> +   /* 136 0x88 */
> 0x00, /*  */
> 0x10, /* 0001 */
> 0x38, /* 00111000 */
> @@ -2482,7 +2482,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 137 0x89 '‰' */
> +   /* 137 0x89 */
> 0x00, /*  */
> 0x00, /*  */
> 0xc6, /* 11000110 */
> @@ -2500,7 +2500,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 138 0x8a 'Š' */
> +   /* 138 0x8a */
> 0x00, /*  */
> 0x60, /* 0110 */
> 0x30, /* 0011 */
> @@ -2518,7 +2518,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 139 0x8b '‹' */
> +   /* 139 0x8b */
> 0x00, /*  */
> 0x00, /*  */
> 0x66, /* 01100110 */
> @@ -2536,7 +2536,7 @@ static unsigned char __maybe_unused 
> video_fontdata[VIDEO_FONT_SIZE] = {
> 0x00, /*  */
> 0x00, /*  */
>
> -   /* 140 0x8c 'Œ' */
> +   /* 140 0x8c */
> 0x00, /*  */
> 0x18, /* 00011000 */
> 

[PATCH] sunxi: spl: Fix H616 clock initialization

[Jernej Skrabec]

It turns out that there is a magic bit in PRCM region which seemingly
makes PLLs work if it's enabled. Sadly, there is no documentation what
it does exactly, so we'll just mimick BSP boot0 behaviour and enable it
before any clock is set up.

Fixes: b18bd53d6cde ("sunxi: introduce support for H616 clocks")
Signed-off-by: Jernej Skrabec 
---
 arch/arm/mach-sunxi/clock_sun50i_h6.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c 
b/arch/arm/mach-sunxi/clock_sun50i_h6.c
index 06d84eb158d7..68c8e7f2afbe 100644
--- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
@@ -9,6 +9,12 @@ void clock_init_safe(void)
 {
struct sunxi_ccm_reg *const ccm =
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+#ifdef CONFIG_MACH_SUN50I_H616
+   /* this seems to enable PLLs */
+   setbits_le32(SUNXI_PRCM_BASE + 0x250, 0x10);
+#endif
+
clock_set_pll1(40800);
 
writel(CCM_PLL6_DEFAULT, >pll6_cfg);
-- 
2.30.0

Re: [PATCH 1/2] gitlab: Move the n900 test into its own section

[Pali Rohár]

On Sunday 31 January 2021 10:10:56 Simon Glass wrote:
> Hi Pali,
> 
> On Sun, 31 Jan 2021 at 10:05, Pali Rohár  wrote:
> >
> > On Sunday 31 January 2021 09:51:44 Simon Glass wrote:
> > > Hi Pali,
> > >
> > > On Sun, 31 Jan 2021 at 08:52, Pali Rohár  wrote:
> > > >
> > > > On Sunday 31 January 2021 08:43:19 Simon Glass wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Sun, 31 Jan 2021 at 08:04, Pali Rohár  wrote:
> > > > > >
> > > > > > On Sunday 31 January 2021 08:49:20 Tom Rini wrote:
> > > > > > > On Sun, Jan 31, 2021 at 01:15:20PM +0100, Pali Rohár wrote:
> > > > > > > > On Saturday 30 January 2021 22:17:45 Simon Glass wrote:
> > > > > > > > > This test is not reliable. Quite often (20%?) it makes the 
> > > > > > > > > build fail and
> > > > > > > > > a retry succeeds.
> > > > > > > >
> > > > > > > > This test should work. Are there any logs with issues?
> > > > > > >
> > > > > > > I don't see it failing any more often than other tests do, due to
> > > > > > > network connectivity issues.  That may be helped by, now that 
> > > > > > > we've
> > > > > > > dropped Travis, having the container be pre-populated with more 
> > > > > > > of the
> > > > > > > downloaded files and pre-building the special QEMU.
> > > > > >
> > > > > > If there are just network issue problems then pre-downloading 
> > > > > > required
> > > > > > files into cache / container should resolve them.
> > > > >
> > > > > The flake issues I see are like this:
> > > > >
> > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/202441
> > > > >
> > > > > I am not sure of the cause, but it would be good to fix it!
> > > >
> > > > Hello Simon! This is not a network issue problem but rather some U-Boot
> > > > regression in mmc code. Second test failed with error:
> > > >
> > > > "Failed to boot kernel from eMMC"
> > > >
> > > > Other tests succeed:
> > > >
> > > > "Kernel was successfully booted from RAM"
> > > > "Kernel was successfully booted from OneNAND"
> > > >
> > > > So problem is really with second boot attempt from eMMC. U-Boot log is
> > > > also available in output (as second run):
> > > >
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=
> > > > ...
> > > > Timed out in wait_for_event: status=
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=
> > > > Check if pads/pull-ups of bus are properly configured
> > > > Timed out in wait_for_event: status=
> > > > Check if pads/pull-ups of bus are properly configured
> > > > test/nokia_rx51_test.sh: line 233:  5946 Killed  
> > > > ./qemu-system-arm -M n900 -mtdblock mtd_emmc.img -sd emmc_emmc.img 
> > > > -serial /dev/stdout -display none > qemu_emmc.log
> > > >
> > > > After 300s was qemu killed and test marked as failure.
> > > >
> > > > So this is valid failure and regression in u-boot emmc code. So it would
> > > > be needed to identify which commit caused it and revert it...
> > >
> > > The problem is that it is intermittent. Can you repeat it?
> >
> > So when you run this test more times from same sources / git commit,
> > this error appears only sometimes?
> 
> Perhaps 1 time in 5 or 10? Every time I click 'retry' in gitlab it
> tries again and passes.

It would be interested to know if problem is with compiled binary (and
rebuilding fixes it) or problem is in qemu runtime part (same compiled
binary sometimes passes and sometimes fails).

But as I have not see this issue, I do not know what is happening here.

> >
> > This particular issue I have not seen in qemu yet when I run tests on my
> > local machine. So I cannot reproduce it.
> >
> > I saw similar errors, but only on real device (not in qemu) and they
> > were visible always (not sometimes). And for all my known problems I
> > have sent patches to mailing list. including i2c, mmc and usb. Some of
> > them are still waiting for review & merge...
> 
> So perhaps it has been fixed, but not yet merged?

Yea, this is possible.

> >
> > ===
> >
> > I know only one error which is not fixed yet and happens "only
> > sometimes" which I was not able to debug yet. Probably if u-boot binary
> > has particular size then it completely crashes (and with same binary it
> > can be reproduced for every run). But recompiling u-boot binary resolves
> > this issue and sometimes even without modifying source code. So I
> > suspect that time string (which changes for every recompilation)
> > must have some effect (maybe some +-1 padding?). Adding new random 100
> > characters into env variables seems to fix it.
> 
> That's not good.
> 
> Re the analsys, that seems a bit of a stretch. While the time/date
> changes, its length doesn't normally change.
> 
> Uninited values can have any behaviour. I assumes this is in U-Boot
> proper, not SPL? You could check that BSS variables are not used
> before relocation, perhaps?

This is U-Boot 

Re: [PATCH 1/2] gitlab: Move the n900 test into its own section

[Simon Glass]

Hi Pali,

On Sun, 31 Jan 2021 at 10:05, Pali Rohár  wrote:
>
> On Sunday 31 January 2021 09:51:44 Simon Glass wrote:
> > Hi Pali,
> >
> > On Sun, 31 Jan 2021 at 08:52, Pali Rohár  wrote:
> > >
> > > On Sunday 31 January 2021 08:43:19 Simon Glass wrote:
> > > > Hi Pali,
> > > >
> > > > On Sun, 31 Jan 2021 at 08:04, Pali Rohár  wrote:
> > > > >
> > > > > On Sunday 31 January 2021 08:49:20 Tom Rini wrote:
> > > > > > On Sun, Jan 31, 2021 at 01:15:20PM +0100, Pali Rohár wrote:
> > > > > > > On Saturday 30 January 2021 22:17:45 Simon Glass wrote:
> > > > > > > > This test is not reliable. Quite often (20%?) it makes the 
> > > > > > > > build fail and
> > > > > > > > a retry succeeds.
> > > > > > >
> > > > > > > This test should work. Are there any logs with issues?
> > > > > >
> > > > > > I don't see it failing any more often than other tests do, due to
> > > > > > network connectivity issues.  That may be helped by, now that we've
> > > > > > dropped Travis, having the container be pre-populated with more of 
> > > > > > the
> > > > > > downloaded files and pre-building the special QEMU.
> > > > >
> > > > > If there are just network issue problems then pre-downloading required
> > > > > files into cache / container should resolve them.
> > > >
> > > > The flake issues I see are like this:
> > > >
> > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/202441
> > > >
> > > > I am not sure of the cause, but it would be good to fix it!
> > >
> > > Hello Simon! This is not a network issue problem but rather some U-Boot
> > > regression in mmc code. Second test failed with error:
> > >
> > > "Failed to boot kernel from eMMC"
> > >
> > > Other tests succeed:
> > >
> > > "Kernel was successfully booted from RAM"
> > > "Kernel was successfully booted from OneNAND"
> > >
> > > So problem is really with second boot attempt from eMMC. U-Boot log is
> > > also available in output (as second run):
> > >
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=
> > > ...
> > > Timed out in wait_for_event: status=
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=
> > > Check if pads/pull-ups of bus are properly configured
> > > Timed out in wait_for_event: status=
> > > Check if pads/pull-ups of bus are properly configured
> > > test/nokia_rx51_test.sh: line 233:  5946 Killed  
> > > ./qemu-system-arm -M n900 -mtdblock mtd_emmc.img -sd emmc_emmc.img 
> > > -serial /dev/stdout -display none > qemu_emmc.log
> > >
> > > After 300s was qemu killed and test marked as failure.
> > >
> > > So this is valid failure and regression in u-boot emmc code. So it would
> > > be needed to identify which commit caused it and revert it...
> >
> > The problem is that it is intermittent. Can you repeat it?
>
> So when you run this test more times from same sources / git commit,
> this error appears only sometimes?

Perhaps 1 time in 5 or 10? Every time I click 'retry' in gitlab it
tries again and passes.

>
> This particular issue I have not seen in qemu yet when I run tests on my
> local machine. So I cannot reproduce it.
>
> I saw similar errors, but only on real device (not in qemu) and they
> were visible always (not sometimes). And for all my known problems I
> have sent patches to mailing list. including i2c, mmc and usb. Some of
> them are still waiting for review & merge...

So perhaps it has been fixed, but not yet merged?

>
> ===
>
> I know only one error which is not fixed yet and happens "only
> sometimes" which I was not able to debug yet. Probably if u-boot binary
> has particular size then it completely crashes (and with same binary it
> can be reproduced for every run). But recompiling u-boot binary resolves
> this issue and sometimes even without modifying source code. So I
> suspect that time string (which changes for every recompilation)
> must have some effect (maybe some +-1 padding?). Adding new random 100
> characters into env variables seems to fix it.

That's not good.

Re the analsys, that seems a bit of a stretch. While the time/date
changes, its length doesn't normally change.

Uninited values can have any behaviour. I assumes this is in U-Boot
proper, not SPL? You could check that BSS variables are not used
before relocation, perhaps?

>
> > >
> > > > Re the network issues, I have a persistent DNS problem with my
> > > > network. I am really not sure of the root cause but sometimes it will
> > > > fail to find a host, then succeed 5 seconds later. I spent some time
> > > > on it a few weeks ago but will try again.
Regards,
Simon

Re: [PATCH v2] armv8: Handle EL2 Host mode

[Mark Kettenis]

> Date: Sun, 31 Jan 2021 16:29:21 +
> From: Andre Przywara 
> 
> On Sat, 30 Jan 2021 22:31:06 +0100
> Mark Kettenis  wrote:
> 
> Hi,
> 
> > On implementations that support VHE, the layout of the CPTR_EL2
> > register depends on whether HCR_EL2.E2H is set.  Check this bit
> > and and set the aprropriate bits to enable access to the FP/SIMD
> > registers.  This allows U-Boot to run on systems that pass
> > control to U-Boot in EL2 with EL2 Host mode enabled such as
> > machine with Apple's M1 SoC.
> > 
> > Signed-off-by: Mark Kettenis 
> 
> Reviewed-by: Andre Przywara 
> 
> So architecturally this is correct, but I was wondering why you would
> actually need this? I gave this a quick spin in QEMU (-cpu max),
> hacking E2H to 1 very early in start.S. However loading and executing
> the Linux kernel was fine even without this patch, so did you observe
> an actual problem? Any kernel entered in EL2 would probably take care of
> the E2H bit and CPTR itself (Linux sets E2H, FreeBSD clears it), so
> is (your?) U-Boot actually using SIMD or VFP instructions itself?

Not explicitly.  The problem I ran into was that snprintf() was trying
to save q0-q7 to the stack.  Compiling with -mgeneral-regs-only fixed
that issue, but since armv8/start.S explicitly enables the FPU I
concluded that someone deliberately chose to allow for SIMD and VFP in
U-Boot.

If we were to revisit that decision, we could save a few bytes I guess...

Cheers,

Mark

> > ---
> > 
> > v2: rename label
> > 
> >  arch/arm/cpu/armv8/start.S | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> > index 662449156b..979dcfef35 100644
> > --- a/arch/arm/cpu/armv8/start.S
> > +++ b/arch/arm/cpu/armv8/start.S
> > @@ -133,9 +133,15 @@ pie_fixup_done:
> >  #endif
> > b   0f
> >  2: set_vbarvbar_el2, x0
> > +   mrs x0, hcr_el2
> > +   tbnzx0, #34, el2_vhe/* HCR_EL2.E2H */
> > mov x0, #0x33ff
> > msr cptr_el2, x0/* Enable FP/SIMD */
> > b   0f
> > +el2_vhe:
> > +   mov x0, #3 << 20
> > +   msr cptr_el2, x0/* Enable FP/SIMD */
> > +   b   0f
> >  1: set_vbarvbar_el1, x0
> > mov x0, #3 << 20
> > msr cpacr_el1, x0   /* Enable FP/SIMD */
> 
> 

Re: [PATCH 1/2] gitlab: Move the n900 test into its own section

[Pali Rohár]

On Sunday 31 January 2021 09:51:44 Simon Glass wrote:
> Hi Pali,
> 
> On Sun, 31 Jan 2021 at 08:52, Pali Rohár  wrote:
> >
> > On Sunday 31 January 2021 08:43:19 Simon Glass wrote:
> > > Hi Pali,
> > >
> > > On Sun, 31 Jan 2021 at 08:04, Pali Rohár  wrote:
> > > >
> > > > On Sunday 31 January 2021 08:49:20 Tom Rini wrote:
> > > > > On Sun, Jan 31, 2021 at 01:15:20PM +0100, Pali Rohár wrote:
> > > > > > On Saturday 30 January 2021 22:17:45 Simon Glass wrote:
> > > > > > > This test is not reliable. Quite often (20%?) it makes the build 
> > > > > > > fail and
> > > > > > > a retry succeeds.
> > > > > >
> > > > > > This test should work. Are there any logs with issues?
> > > > >
> > > > > I don't see it failing any more often than other tests do, due to
> > > > > network connectivity issues.  That may be helped by, now that we've
> > > > > dropped Travis, having the container be pre-populated with more of the
> > > > > downloaded files and pre-building the special QEMU.
> > > >
> > > > If there are just network issue problems then pre-downloading required
> > > > files into cache / container should resolve them.
> > >
> > > The flake issues I see are like this:
> > >
> > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/202441
> > >
> > > I am not sure of the cause, but it would be good to fix it!
> >
> > Hello Simon! This is not a network issue problem but rather some U-Boot
> > regression in mmc code. Second test failed with error:
> >
> > "Failed to boot kernel from eMMC"
> >
> > Other tests succeed:
> >
> > "Kernel was successfully booted from RAM"
> > "Kernel was successfully booted from OneNAND"
> >
> > So problem is really with second boot attempt from eMMC. U-Boot log is
> > also available in output (as second run):
> >
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=
> > ...
> > Timed out in wait_for_event: status=
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=
> > Check if pads/pull-ups of bus are properly configured
> > Timed out in wait_for_event: status=
> > Check if pads/pull-ups of bus are properly configured
> > test/nokia_rx51_test.sh: line 233:  5946 Killed  
> > ./qemu-system-arm -M n900 -mtdblock mtd_emmc.img -sd emmc_emmc.img -serial 
> > /dev/stdout -display none > qemu_emmc.log
> >
> > After 300s was qemu killed and test marked as failure.
> >
> > So this is valid failure and regression in u-boot emmc code. So it would
> > be needed to identify which commit caused it and revert it...
> 
> The problem is that it is intermittent. Can you repeat it?

So when you run this test more times from same sources / git commit,
this error appears only sometimes?

This particular issue I have not seen in qemu yet when I run tests on my
local machine. So I cannot reproduce it.

I saw similar errors, but only on real device (not in qemu) and they
were visible always (not sometimes). And for all my known problems I
have sent patches to mailing list. including i2c, mmc and usb. Some of
them are still waiting for review & merge...

===

I know only one error which is not fixed yet and happens "only
sometimes" which I was not able to debug yet. Probably if u-boot binary
has particular size then it completely crashes (and with same binary it
can be reproduced for every run). But recompiling u-boot binary resolves
this issue and sometimes even without modifying source code. So I
suspect that time string (which changes for every recompilation)
must have some effect (maybe some +-1 padding?). Adding new random 100
characters into env variables seems to fix it.

> >
> > > Re the network issues, I have a persistent DNS problem with my
> > > network. I am really not sure of the root cause but sometimes it will
> > > fail to find a host, then succeed 5 seconds later. I spent some time
> > > on it a few weeks ago but will try again.
> 
> Regards,
> Simon

Re: [PATCH 1/2] gitlab: Move the n900 test into its own section

[Simon Glass]

Hi Pali,

On Sun, 31 Jan 2021 at 08:52, Pali Rohár  wrote:
>
> On Sunday 31 January 2021 08:43:19 Simon Glass wrote:
> > Hi Pali,
> >
> > On Sun, 31 Jan 2021 at 08:04, Pali Rohár  wrote:
> > >
> > > On Sunday 31 January 2021 08:49:20 Tom Rini wrote:
> > > > On Sun, Jan 31, 2021 at 01:15:20PM +0100, Pali Rohár wrote:
> > > > > On Saturday 30 January 2021 22:17:45 Simon Glass wrote:
> > > > > > This test is not reliable. Quite often (20%?) it makes the build 
> > > > > > fail and
> > > > > > a retry succeeds.
> > > > >
> > > > > This test should work. Are there any logs with issues?
> > > >
> > > > I don't see it failing any more often than other tests do, due to
> > > > network connectivity issues.  That may be helped by, now that we've
> > > > dropped Travis, having the container be pre-populated with more of the
> > > > downloaded files and pre-building the special QEMU.
> > >
> > > If there are just network issue problems then pre-downloading required
> > > files into cache / container should resolve them.
> >
> > The flake issues I see are like this:
> >
> > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/202441
> >
> > I am not sure of the cause, but it would be good to fix it!
>
> Hello Simon! This is not a network issue problem but rather some U-Boot
> regression in mmc code. Second test failed with error:
>
> "Failed to boot kernel from eMMC"
>
> Other tests succeed:
>
> "Kernel was successfully booted from RAM"
> "Kernel was successfully booted from OneNAND"
>
> So problem is really with second boot attempt from eMMC. U-Boot log is
> also available in output (as second run):
>
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> ...
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> test/nokia_rx51_test.sh: line 233:  5946 Killed  
> ./qemu-system-arm -M n900 -mtdblock mtd_emmc.img -sd emmc_emmc.img -serial 
> /dev/stdout -display none > qemu_emmc.log
>
> After 300s was qemu killed and test marked as failure.
>
> So this is valid failure and regression in u-boot emmc code. So it would
> be needed to identify which commit caused it and revert it...

The problem is that it is intermittent. Can you repeat it?

>
> > Re the network issues, I have a persistent DNS problem with my
> > network. I am really not sure of the root cause but sometimes it will
> > fail to find a host, then succeed 5 seconds later. I spent some time
> > on it a few weeks ago but will try again.

Regards,
Simon

Re: [PATCH v2] armv8: Handle EL2 Host mode

[Andre Przywara]

On Sat, 30 Jan 2021 22:31:06 +0100
Mark Kettenis  wrote:

Hi,

> On implementations that support VHE, the layout of the CPTR_EL2
> register depends on whether HCR_EL2.E2H is set.  Check this bit
> and and set the aprropriate bits to enable access to the FP/SIMD
> registers.  This allows U-Boot to run on systems that pass
> control to U-Boot in EL2 with EL2 Host mode enabled such as
> machine with Apple's M1 SoC.
> 
> Signed-off-by: Mark Kettenis 

Reviewed-by: Andre Przywara 

So architecturally this is correct, but I was wondering why you would
actually need this? I gave this a quick spin in QEMU (-cpu max),
hacking E2H to 1 very early in start.S. However loading and executing
the Linux kernel was fine even without this patch, so did you observe
an actual problem? Any kernel entered in EL2 would probably take care of
the E2H bit and CPTR itself (Linux sets E2H, FreeBSD clears it), so
is (your?) U-Boot actually using SIMD or VFP instructions itself?

Cheers,
Andre.

> ---
> 
> v2: rename label
> 
>  arch/arm/cpu/armv8/start.S | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index 662449156b..979dcfef35 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -133,9 +133,15 @@ pie_fixup_done:
>  #endif
>   b   0f
>  2:   set_vbarvbar_el2, x0
> + mrs x0, hcr_el2
> + tbnzx0, #34, el2_vhe/* HCR_EL2.E2H */
>   mov x0, #0x33ff
>   msr cptr_el2, x0/* Enable FP/SIMD */
>   b   0f
> +el2_vhe:
> + mov x0, #3 << 20
> + msr cptr_el2, x0/* Enable FP/SIMD */
> + b   0f
>  1:   set_vbarvbar_el1, x0
>   mov x0, #3 << 20
>   msr cpacr_el1, x0   /* Enable FP/SIMD */

[PATCH] x86: Reduce size of samus image

[Simon Glass]

With the recent addition of ACPI generation, the image size has got beyond
its current limit.

Samus does not actually use this, nor x86 emulation for PCI ROMs, so
disable both features.

Signed-off-by: Simon Glass 
---

 configs/chromebook_samus_defconfig | 1 +
 include/configs/chromebook_samus.h | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/configs/chromebook_samus_defconfig 
b/configs/chromebook_samus_defconfig
index c0d2b04ccdf..71b5f8bdfea 100644
--- a/configs/chromebook_samus_defconfig
+++ b/configs/chromebook_samus_defconfig
@@ -54,6 +54,7 @@ CONFIG_ENV_OVERWRITE=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
+# CONFIG_ACPIGEN is not set
 CONFIG_CPU=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_DW=y
diff --git a/include/configs/chromebook_samus.h 
b/include/configs/chromebook_samus.h
index dfeede7e91a..2fe3e721993 100644
--- a/include/configs/chromebook_samus.h
+++ b/include/configs/chromebook_samus.h
@@ -15,6 +15,9 @@
 #include 
 #include 
 
+/* We can rely on running natively, and this saves code size */
+#undef CONFIG_BIOSEMU
+
 #undef CONFIG_STD_DEVICES_SETTINGS
 #define CONFIG_STD_DEVICES_SETTINGS "stdin=usbkbd,i8042-kbd,serial\0" \
"stdout=vidconsole,serial\0" \
-- 
2.30.0.365.g02bc693789-goog

Re: [PATCH 1/2] gitlab: Move the n900 test into its own section

[Pali Rohár]

On Sunday 31 January 2021 08:43:19 Simon Glass wrote:
> Hi Pali,
> 
> On Sun, 31 Jan 2021 at 08:04, Pali Rohár  wrote:
> >
> > On Sunday 31 January 2021 08:49:20 Tom Rini wrote:
> > > On Sun, Jan 31, 2021 at 01:15:20PM +0100, Pali Rohár wrote:
> > > > On Saturday 30 January 2021 22:17:45 Simon Glass wrote:
> > > > > This test is not reliable. Quite often (20%?) it makes the build fail 
> > > > > and
> > > > > a retry succeeds.
> > > >
> > > > This test should work. Are there any logs with issues?
> > >
> > > I don't see it failing any more often than other tests do, due to
> > > network connectivity issues.  That may be helped by, now that we've
> > > dropped Travis, having the container be pre-populated with more of the
> > > downloaded files and pre-building the special QEMU.
> >
> > If there are just network issue problems then pre-downloading required
> > files into cache / container should resolve them.
> 
> The flake issues I see are like this:
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/202441
> 
> I am not sure of the cause, but it would be good to fix it!

Hello Simon! This is not a network issue problem but rather some U-Boot
regression in mmc code. Second test failed with error:

"Failed to boot kernel from eMMC"

Other tests succeed:

"Kernel was successfully booted from RAM"
"Kernel was successfully booted from OneNAND"

So problem is really with second boot attempt from eMMC. U-Boot log is
also available in output (as second run):

Check if pads/pull-ups of bus are properly configured
Timed out in wait_for_event: status=
...
Timed out in wait_for_event: status=
Check if pads/pull-ups of bus are properly configured
Timed out in wait_for_event: status=
Check if pads/pull-ups of bus are properly configured
Timed out in wait_for_event: status=
Check if pads/pull-ups of bus are properly configured
test/nokia_rx51_test.sh: line 233:  5946 Killed  
./qemu-system-arm -M n900 -mtdblock mtd_emmc.img -sd emmc_emmc.img -serial 
/dev/stdout -display none > qemu_emmc.log

After 300s was qemu killed and test marked as failure.

So this is valid failure and regression in u-boot emmc code. So it would
be needed to identify which commit caused it and revert it...

> Re the network issues, I have a persistent DNS problem with my
> network. I am really not sure of the root cause but sometimes it will
> fail to find a host, then succeed 5 seconds later. I spent some time
> on it a few weeks ago but will try again.
> 
> Regards,
> Simon

Re: [PATCH 1/2] gitlab: Move the n900 test into its own section

[Simon Glass]

Hi Pali,

On Sun, 31 Jan 2021 at 08:04, Pali Rohár  wrote:
>
> On Sunday 31 January 2021 08:49:20 Tom Rini wrote:
> > On Sun, Jan 31, 2021 at 01:15:20PM +0100, Pali Rohár wrote:
> > > On Saturday 30 January 2021 22:17:45 Simon Glass wrote:
> > > > This test is not reliable. Quite often (20%?) it makes the build fail 
> > > > and
> > > > a retry succeeds.
> > >
> > > This test should work. Are there any logs with issues?
> >
> > I don't see it failing any more often than other tests do, due to
> > network connectivity issues.  That may be helped by, now that we've
> > dropped Travis, having the container be pre-populated with more of the
> > downloaded files and pre-building the special QEMU.
>
> If there are just network issue problems then pre-downloading required
> files into cache / container should resolve them.

The flake issues I see are like this:

https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/202441

I am not sure of the cause, but it would be good to fix it!

Re the network issues, I have a persistent DNS problem with my
network. I am really not sure of the root cause but sometimes it will
fail to find a host, then succeed 5 seconds later. I spent some time
on it a few weeks ago but will try again.

Regards,
Simon

Re: [PATCH 04/11] dm: Remove uses of device_bind_offset()

[Simon Glass]

Hi Eugen,

On Sun, 31 Jan 2021 at 02:18,  wrote:
>
> On 10.12.2020 02:26, Simon Glass wrote:
> > This function is not needed since the standard device_bind() can be used
> > instead.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >   arch/x86/cpu/apollolake/spl.c   |  2 +-
> >   drivers/clk/at91/compat.c   | 20 
> >   drivers/clk/clk.c   |  2 +-
> >   drivers/gpio/mt7621_gpio.c  |  4 ++--
> >   drivers/gpio/s5p_gpio.c |  4 ++--
> >   drivers/gpio/sunxi_gpio.c   |  4 ++--
> >   drivers/gpio/tegra186_gpio.c|  4 ++--
> >   drivers/gpio/tegra_gpio.c   |  6 +++---
> >   drivers/net/mvpp2.c |  4 ++--
> >   drivers/pinctrl/broadcom/pinctrl-bcm283x.c  |  5 ++---
> >   drivers/pinctrl/meson/pinctrl-meson.c   |  4 +++-
> >   drivers/pinctrl/mscc/pinctrl-jr2.c  |  4 ++--
> >   drivers/pinctrl/mscc/pinctrl-luton.c|  4 ++--
> >   drivers/pinctrl/mscc/pinctrl-ocelot.c   |  4 ++--
> >   drivers/pinctrl/mscc/pinctrl-serval.c   |  4 ++--
> >   drivers/pinctrl/mscc/pinctrl-servalt.c  |  4 ++--
> >   drivers/pinctrl/mvebu/pinctrl-armada-37xx.c |  8 
> >   drivers/power/regulator/Kconfig |  2 +-
> >   include/dm/device-internal.h|  4 ++--
> >   include/power/regulator.h   |  2 +-
> >   20 files changed, 46 insertions(+), 49 deletions(-)
> >
> > Applied to u-boot-dm, thanks!
> >
>
>
> Hi Simon,
>
> I bisected the tree and this commit looks to break
> sama5d4_xplained_mmc_defconfig :
>
> 
> No serial driver found
> Could not initialize timer (err -19)
>
> Could not initialize timer (err -19)
>
> Could not initialize timer (err -19)
>
> Could not initialize timer (err -19)
>
> Could not initialize timer (err -19)
>
> Could not initialize timer (err -19)
>
> Could not initialize timer (err -19)
>
> Could not initialize timer (err -19)
>
> Could not initialize timer (err -19)
>
> Could not initialize timer (err -19)
>
> Booting u-boot fails when adding this commit.
>
> Could you please help or let me know how I can fix it ?

I suspect the problem could be in the changes to
drivers/clk/at91/compat.c although I cannot see why

You could try reverting that change, and just using offset_to_ofnode()
in the device_bind_driver_to_node() call. I actually intended to do
that at the time due to the risk, but somehow I missed this one.

OTOH it would be good to move the code to livetree and stop using fdt offsets.

Regards,
Simon

Re: [PATCH 1/2] gitlab: Move the n900 test into its own section

[Pali Rohár]

On Sunday 31 January 2021 08:49:20 Tom Rini wrote:
> On Sun, Jan 31, 2021 at 01:15:20PM +0100, Pali Rohár wrote:
> > On Saturday 30 January 2021 22:17:45 Simon Glass wrote:
> > > This test is not reliable. Quite often (20%?) it makes the build fail and
> > > a retry succeeds.
> > 
> > This test should work. Are there any logs with issues?
> 
> I don't see it failing any more often than other tests do, due to
> network connectivity issues.  That may be helped by, now that we've
> dropped Travis, having the container be pre-populated with more of the
> downloaded files and pre-building the special QEMU.

If there are just network issue problems then pre-downloading required
files into cache / container should resolve them.

[PULL] u-boot-usb/master

[Marek Vasut]

The following changes since commit 472a716b8fdfd88a27cb675e4ea8e12cb4f79fc3:

  configs: Resync with savedefconfig (2021-01-29 13:56:04 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-usb.git master

for you to fetch changes up to 723fd5668ff2c8dd19e808778b5670d0fa6bdc4b:

  usb: gaget: ci: set ep's desc when enable ep (2021-01-31 14:08:56 +0100)


Andy Shevchenko (3):
  f_rockusb: Use NULL instead of 0 for pointers
  f_rockusb: Avoid use-after-free in the global pointer variable
  f_fastboot: Avoid use-after-free in the global pointer variable

Eugeniu Rosca (5):
  cmd: bcb: Extract '__bcb_load' from 'do_bcb_load' for internal needs
  cmd: bcb: Extract '__bcb_set' from 'do_bcb_set' for internal needs
  cmd: bcb: Extract '__bcb_store' from 'do_bcb_store' for internal 
needs

  cmd: bcb: Expose 'bcb_write_reboot_reason' to external callers
  cmd: bcb: Add support for processing const string literals in 
bcb_set()


Guillermo Rodriguez (1):
  dfu: Fix handling of UBI partitions in MTD backend

Jaehoon Chung (1):
  dfu: add 'SKIP' entity

Jun Li (2):
  usb: gadget: set correct usb_configuration for os_desc_config
  usb: gadget: update os_desc_config when add config

Li Jun (13):
  usb: gadget: don't change ep name for dwc3 while ep autoconfig
  usb: gadget: OS String support
  usb: gadget: move utf8_to_utf16le to header file
  usb: gadget: OS Feature Descriptors support
  usb: gadget: add WCID support for mfgtool
  usb: gadget: fastboot: add ext properties for WCID
  usb: gadget: add super speed support
  usb: fastboot: add super speed support
  usb: gadget: dnl: set dnl to be super speed
  usb: composite: force gadget to be USB2 for HS only function
  usb: udc: ci: update speed handling
  usb: gadget: fastboot: use correct max packet size
  usb: gaget: ci: set ep's desc when enable ep

Marek Szyprowski (5):
  cmd: usb_mass_storage: show device interface name
  dfu: mmc: use the default MMC device if entity specifies it as -1
  dfu: add 'SCRIPT' entity
  dfu: add support for the dfu_alt_info reintialization from the 
flashed script
  thor: add support for the dfu_alt_info reintialization from the 
flashed script


Pali Rohár (1):
  usb: gadget: Do not export usbd_device_* arrays

Peng Fan (1):
  usb: gadget: add Kconfig for OS descriptors

Seung-Woo Kim (1):
  gadget: f_thor: fix wrong file size cast

Ye Li (1):
  usb: gadget: Add ep_config call back to usb_gadget_ops

 cmd/bcb.c   |  88 ++-
 cmd/dfu.c   |  13 +++-
 cmd/thordown.c  |  19 +++--
 cmd/usb_mass_storage.c  |   4 +-
 common/dfu.c|   3 +
 doc/README.dfu  |  30 +++-
 drivers/dfu/dfu.c   |   7 +-
 drivers/dfu/dfu_mmc.c   |  39 --
 drivers/dfu/dfu_mtd.c   |   4 +-
 drivers/usb/gadget/Kconfig  |   9 +++
 drivers/usb/gadget/ci_udc.c |   5 +-
 drivers/usb/gadget/composite.c  | 392 
++---

 drivers/usb/gadget/core.c   |  45 ++--
 drivers/usb/gadget/ep0.c|  46 
 drivers/usb/gadget/epautoconf.c |   6 ++
 drivers/usb/gadget/f_fastboot.c |  85 --
 drivers/usb/gadget/f_rockusb.c  |   7 +-
 drivers/usb/gadget/f_thor.c |  11 +--
 drivers/usb/gadget/g_dnl.c  |   1 +
 drivers/usb/gadget/u_os_desc.h  | 123 
 drivers/usb/gadget/usbstring.c  |  74 +--
 include/bcb.h   |  21 ++
 include/dfu.h   |   4 ++
 include/linux/usb/composite.h   |  71 +++
 include/linux/usb/gadget.h  |   9 +++
 include/linux/utf.h |  75 
 include/thor.h  |   2 +
 include/usbdevice.h |  15 
 28 files changed, 1001 insertions(+), 207 deletions(-)
 create mode 100644 drivers/usb/gadget/u_os_desc.h
 create mode 100644 include/bcb.h
 create mode 100644 include/linux/utf.h

[PULL] u-boot-sh/master

[Marek Vasut]

The following changes since commit 472a716b8fdfd88a27cb675e4ea8e12cb4f79fc3:

  configs: Resync with savedefconfig (2021-01-29 13:56:04 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-sh.git master

for you to fetch changes up to 8a73bef338d48095dfb8e805b643d7dd1f6b6d9b:

  mmc: tmio: sdhi: Configure internal DMA bus width (2021-01-31 
14:08:45 +0100)



Biju Das (1):
  arm: dts: rmobile: r8a774a1: Synchronize DTs with Linux 5.10

Marek Vasut (1):
  mmc: tmio: sdhi: Configure internal DMA bus width

 arch/arm/dts/hihope-common.dtsi   | 377 
+++
 arch/arm/dts/hihope-rev4.dtsi | 124 
+

 arch/arm/dts/hihope-rzg2-ex.dtsi  |  92 +
 arch/arm/dts/r8a774a1-hihope-rzg2m-ex.dts |  21 +
 arch/arm/dts/r8a774a1-hihope-rzg2m-u-boot.dts |  27 +++
 arch/arm/dts/r8a774a1-hihope-rzg2m.dts|  37 +
 arch/arm/dts/r8a774a1-u-boot.dtsi |  55 +
 drivers/mmc/renesas-sdhi.c|   3 +
 drivers/mmc/tmio-common.c |   3 +
 drivers/mmc/tmio-common.h |   2 +
 10 files changed, 741 insertions(+)
 create mode 100644 arch/arm/dts/hihope-common.dtsi
 create mode 100644 arch/arm/dts/hihope-rev4.dtsi
 create mode 100644 arch/arm/dts/hihope-rzg2-ex.dtsi
 create mode 100644 arch/arm/dts/r8a774a1-hihope-rzg2m-ex.dts
 create mode 100644 arch/arm/dts/r8a774a1-hihope-rzg2m-u-boot.dts
 create mode 100644 arch/arm/dts/r8a774a1-hihope-rzg2m.dts
 create mode 100644 arch/arm/dts/r8a774a1-u-boot.dtsi

[PATCH v2] test/py: fix runtest wrapper for pytest 6

[Stephen Warren]

The implementation of pytest_runtest_protocol() must call
pytest_runtest_logstart() and pytest_runtest_logfinish(). This appears to
be necessary even in pytest 5.2.1 judging by the default version of
pytest_runtest_protocol(), but evidently some form of code reorganization
in pytest only made this have a practical effect in the newer version. I'd
previously been under the impression that 100% of the required work of
pytest_runtest_protocol() was handled by the fact it called
runtestprotocol() as its implementation. However, it appears that custom
implementations do need to do a little more than this.

Reported-by: Heinrich Schuchardt 
Signed-off-by: Stephen Warren 
---
v2: Rebased on a marginally newer commit, hence removed the change to
test/py/test.py. Cleaned up return statement.
---
 test/py/conftest.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/test/py/conftest.py b/test/py/conftest.py
index dc92c0be32ee..9bfd9263455f 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -554,7 +554,10 @@ def pytest_runtest_protocol(item, nextitem):
 """
 
 log.get_and_reset_warning()
+ihook = item.ihook
+ihook.pytest_runtest_logstart(nodeid=item.nodeid, location=item.location)
 reports = runtestprotocol(item, nextitem=nextitem)
+ihook.pytest_runtest_logfinish(nodeid=item.nodeid, location=item.location)
 was_warning = log.get_and_reset_warning()
 
 # In pytest 3, runtestprotocol() may not call pytest_runtest_setup() if
@@ -623,4 +626,4 @@ def pytest_runtest_protocol(item, nextitem):
 if failure_cleanup:
 console.cleanup_spawn()
 
-return reports
+return True
-- 
2.25.1

Re: [PATCH 1/2] gitlab: Move the n900 test into its own section

[Tom Rini]

On Sun, Jan 31, 2021 at 01:15:20PM +0100, Pali Rohár wrote:
> On Saturday 30 January 2021 22:17:45 Simon Glass wrote:
> > This test is not reliable. Quite often (20%?) it makes the build fail and
> > a retry succeeds.
> 
> This test should work. Are there any logs with issues?

I don't see it failing any more often than other tests do, due to
network connectivity issues.  That may be helped by, now that we've
dropped Travis, having the container be pre-populated with more of the
downloaded files and pre-building the special QEMU.

-- 
Tom


signature.asc
Description: PGP signature

Re: Pull request for UEFI sub-system for efi-2021-04-rc1-4

[Tom Rini]

On Sat, Jan 30, 2021 at 08:30:46PM +0100, Heinrich Schuchardt wrote:

> The following changes since commit 472a716b8fdfd88a27cb675e4ea8e12cb4f79fc3:
> 
>   configs: Resync with savedefconfig (2021-01-29 13:56:04 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2021-04-rc1-4
> 
> for you to fetch changes up to 18dd984c56b339be74e390df80fd3dc21b7a9b58:
> 
>   efi_loader: add Linux magic to aarch64 crt0 (2021-01-29 20:22:40 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 00/10] Allow booting a 32-bit system with a top memory address beyond 4 GiB

[Bin Meng]

Hi Simon,

On Sun, Jan 31, 2021 at 8:36 PM Bin Meng  wrote:
>
> When testing QEMU RISC-V 'virt' machine with a 2 GiB memory
> configuration, it was discovered gd->ram_top is assigned to
> value zero in setup_dest_addr().
>
> While 2 GiB QEMU RISC-V 'virt' happens to work with U-Boot today,
> increasing more memory doesn't make a bootable system. There are
> various places in U-Boot that prevents such from working.
>
> While this is seen and tested on RISC-V, it's not RISC-V centric,
> but a generic issue that may affect all architectures.
>
> Changes in v2:
> - new patch: arm: rockchip: Explicitly cast gd->ram_top in 
> dram_init_banksize()
> - new patch: riscv: ax25-ae350: Cast addr with uintptr_t
> - new patch: net: ftmac100: Cast priv->iobase with uintptr_t
>

GitLab pass:
https://gitlab.denx.de/u-boot/custodians/u-boot-x86/-/pipelines/6148

Azure pass with the patch [1]:
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=312=results

[1] 
http://patchwork.ozlabs.org/project/uboot/patch/20210131083835.9916-1-bmeng...@gmail.com/

Regards,
Bin

Re: [PATCH 04/11] dm: Remove uses of device_bind_offset()

[Eugen.Hristev]

On 10.12.2020 02:26, Simon Glass wrote:
> This function is not needed since the standard device_bind() can be used
> instead.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>   arch/x86/cpu/apollolake/spl.c   |  2 +-
>   drivers/clk/at91/compat.c   | 20 
>   drivers/clk/clk.c   |  2 +-
>   drivers/gpio/mt7621_gpio.c  |  4 ++--
>   drivers/gpio/s5p_gpio.c |  4 ++--
>   drivers/gpio/sunxi_gpio.c   |  4 ++--
>   drivers/gpio/tegra186_gpio.c|  4 ++--
>   drivers/gpio/tegra_gpio.c   |  6 +++---
>   drivers/net/mvpp2.c |  4 ++--
>   drivers/pinctrl/broadcom/pinctrl-bcm283x.c  |  5 ++---
>   drivers/pinctrl/meson/pinctrl-meson.c   |  4 +++-
>   drivers/pinctrl/mscc/pinctrl-jr2.c  |  4 ++--
>   drivers/pinctrl/mscc/pinctrl-luton.c|  4 ++--
>   drivers/pinctrl/mscc/pinctrl-ocelot.c   |  4 ++--
>   drivers/pinctrl/mscc/pinctrl-serval.c   |  4 ++--
>   drivers/pinctrl/mscc/pinctrl-servalt.c  |  4 ++--
>   drivers/pinctrl/mvebu/pinctrl-armada-37xx.c |  8 
>   drivers/power/regulator/Kconfig |  2 +-
>   include/dm/device-internal.h|  4 ++--
>   include/power/regulator.h   |  2 +-
>   20 files changed, 46 insertions(+), 49 deletions(-)
> 
> Applied to u-boot-dm, thanks!
> 


Hi Simon,

I bisected the tree and this commit looks to break 
sama5d4_xplained_mmc_defconfig :


No serial driver found
Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Could not initialize timer (err -19)

Booting u-boot fails when adding this commit.

Could you please help or let me know how I can fix it ?

Thanks,
Eugen

a2703ce10cfcbe6a82ec8ed9ec10df2aeea08e64 is the first bad commit
commit a2703ce10cfcbe6a82ec8ed9ec10df2aeea08e64
Author: Simon Glass 
Date:   Sat Nov 28 17:50:03 2020 -0700

 dm: Remove uses of device_bind_offset()

 This function is not needed since the standard device_bind() can be 
used
 instead.

 Signed-off-by: Simon Glass 

[PATCH v2 10/10] bdinfo: Change to use bdinfo_print_num_ll() where the number could be 64-bit

[Bin Meng]

From: Bin Meng 

There are some calls to bdinfo_print_num_l() with parameters that
could be a 64-bit value on a 32-bit system. Change those calls to
use bdinfo_print_num_ll() instead.

Signed-off-by: Bin Meng 
---

(no changes since v1)

 arch/arm/lib/bdinfo.c | 8 
 cmd/bdinfo.c  | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/lib/bdinfo.c b/arch/arm/lib/bdinfo.c
index 4a98cb7ef5..c905783bdc 100644
--- a/arch/arm/lib/bdinfo.c
+++ b/arch/arm/lib/bdinfo.c
@@ -18,14 +18,14 @@ void arch_print_bdinfo(void)
bdinfo_print_num_l("arch_number", bd->bi_arch_number);
 #ifdef CONFIG_SYS_MEM_RESERVE_SECURE
if (gd->arch.secure_ram & MEM_RESERVE_SECURE_SECURED) {
-   bdinfo_print_num_l("Secure ram",
-  gd->arch.secure_ram &
-  MEM_RESERVE_SECURE_ADDR_MASK);
+   bdinfo_print_num_ll("Secure ram",
+   gd->arch.secure_ram &
+   MEM_RESERVE_SECURE_ADDR_MASK);
}
 #endif
 #ifdef CONFIG_RESV_RAM
if (gd->arch.resv_ram)
-   bdinfo_print_num_l("Reserved ram", gd->arch.resv_ram);
+   bdinfo_print_num_ll("Reserved ram", gd->arch.resv_ram);
 #endif
 #if !(CONFIG_IS_ENABLED(SYS_ICACHE_OFF) && CONFIG_IS_ENABLED(SYS_DCACHE_OFF))
bdinfo_print_num_l("TLB addr", gd->arch.tlb_addr);
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index 996546faf3..dfd50ae849 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -55,8 +55,8 @@ static void print_bi_dram(const struct bd_info *bd)
for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
if (bd->bi_dram[i].size) {
bdinfo_print_num_l("DRAM bank", i);
-   bdinfo_print_num_l("-> start",  bd->bi_dram[i].start);
-   bdinfo_print_num_l("-> size",   bd->bi_dram[i].size);
+   bdinfo_print_num_ll("-> start", bd->bi_dram[i].start);
+   bdinfo_print_num_ll("-> size",  bd->bi_dram[i].size);
}
}
 }
-- 
2.25.1

[PATCH v2 09/10] bdinfo: Rename function names to be clearer

[Bin Meng]

From: Bin Meng 

At present we have bdinfo_print_num() to print unsigned long numbers.
We also have print_phys_addr() which accept numbers that might be
64-bit on a 32-bit platform.

Rename these 2 functions to be clearer:

bdinfo_print_num() => bdinfo_print_num_l()
print_phys_addr()  => bdinfo_print_num_ll()

While we are here, make bdinfo_print_num_ll() public so that it can
be used outside cmd/bdinfo.c in the future.

Signed-off-by: Bin Meng 
---

(no changes since v1)

 arch/arm/lib/bdinfo.c | 16 ++--
 arch/m68k/lib/bdinfo.c|  2 +-
 arch/powerpc/lib/bdinfo.c |  4 +--
 cmd/bdinfo.c  | 52 +++
 include/init.h|  3 ++-
 5 files changed, 39 insertions(+), 38 deletions(-)

diff --git a/arch/arm/lib/bdinfo.c b/arch/arm/lib/bdinfo.c
index 25bc6e80f4..4a98cb7ef5 100644
--- a/arch/arm/lib/bdinfo.c
+++ b/arch/arm/lib/bdinfo.c
@@ -15,23 +15,23 @@ void arch_print_bdinfo(void)
 {
struct bd_info *bd = gd->bd;
 
-   bdinfo_print_num("arch_number", bd->bi_arch_number);
+   bdinfo_print_num_l("arch_number", bd->bi_arch_number);
 #ifdef CONFIG_SYS_MEM_RESERVE_SECURE
if (gd->arch.secure_ram & MEM_RESERVE_SECURE_SECURED) {
-   bdinfo_print_num("Secure ram",
-gd->arch.secure_ram &
-MEM_RESERVE_SECURE_ADDR_MASK);
+   bdinfo_print_num_l("Secure ram",
+  gd->arch.secure_ram &
+  MEM_RESERVE_SECURE_ADDR_MASK);
}
 #endif
 #ifdef CONFIG_RESV_RAM
if (gd->arch.resv_ram)
-   bdinfo_print_num("Reserved ram", gd->arch.resv_ram);
+   bdinfo_print_num_l("Reserved ram", gd->arch.resv_ram);
 #endif
 #if !(CONFIG_IS_ENABLED(SYS_ICACHE_OFF) && CONFIG_IS_ENABLED(SYS_DCACHE_OFF))
-   bdinfo_print_num("TLB addr", gd->arch.tlb_addr);
+   bdinfo_print_num_l("TLB addr", gd->arch.tlb_addr);
 #endif
-   bdinfo_print_num("irq_sp", gd->irq_sp); /* irq stack pointer */
-   bdinfo_print_num("sp start ", gd->start_addr_sp);
+   bdinfo_print_num_l("irq_sp", gd->irq_sp);   /* irq stack pointer */
+   bdinfo_print_num_l("sp start ", gd->start_addr_sp);
/*
 * TODO: Currently only support for davinci SOC's is added.
 * Remove this check once all the board implement this.
diff --git a/arch/m68k/lib/bdinfo.c b/arch/m68k/lib/bdinfo.c
index 404e5f19ed..92ea175202 100644
--- a/arch/m68k/lib/bdinfo.c
+++ b/arch/m68k/lib/bdinfo.c
@@ -38,7 +38,7 @@ void arch_print_bdinfo(void)
 
bdinfo_print_mhz("busfreq", bd->bi_busfreq);
 #if defined(CONFIG_SYS_MBAR)
-   bdinfo_print_num("mbar", bd->bi_mbar_base);
+   bdinfo_print_num_l("mbar", bd->bi_mbar_base);
 #endif
bdinfo_print_mhz("cpufreq", bd->bi_intfreq);
if (IS_ENABLED(CONFIG_PCI))
diff --git a/arch/powerpc/lib/bdinfo.c b/arch/powerpc/lib/bdinfo.c
index 36c9c99ee6..b14e75b68a 100644
--- a/arch/powerpc/lib/bdinfo.c
+++ b/arch/powerpc/lib/bdinfo.c
@@ -47,9 +47,9 @@ void arch_print_bdinfo(void)
 
bdinfo_print_mhz("busfreq", bd->bi_busfreq);
 #if defined(CONFIG_MPC8xx) || defined(CONFIG_E500)
-   bdinfo_print_num("immr_base", bd->bi_immr_base);
+   bdinfo_print_num_l("immr_base", bd->bi_immr_base);
 #endif
-   bdinfo_print_num("bootflags", bd->bi_bootflags);
+   bdinfo_print_num_l("bootflags", bd->bi_bootflags);
bdinfo_print_mhz("intfreq", bd->bi_intfreq);
 #ifdef CONFIG_ENABLE_36BIT_PHYS
if (IS_ENABLED(CONFIG_PHYS_64BIT))
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index 8d8daa6336..996546faf3 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -18,11 +18,16 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-void bdinfo_print_num(const char *name, ulong value)
+void bdinfo_print_num_l(const char *name, ulong value)
 {
printf("%-12s= 0x%0*lx\n", name, 2 * (int)sizeof(value), value);
 }
 
+void bdinfo_print_num_ll(const char *name, unsigned long long value)
+{
+   printf("%-12s= 0x%.*llx\n", name, 2 * (int)sizeof(ulong), value);
+}
+
 static void print_eth(int idx)
 {
char name[10], *val;
@@ -36,12 +41,6 @@ static void print_eth(int idx)
printf("%-12s= %s\n", name, val);
 }
 
-static void print_phys_addr(const char *name, phys_addr_t value)
-{
-   printf("%-12s= 0x%.*llx\n", name, 2 * (int)sizeof(ulong),
-  (unsigned long long)value);
-}
-
 void bdinfo_print_mhz(const char *name, unsigned long hz)
 {
char buf[32];
@@ -55,9 +54,9 @@ static void print_bi_dram(const struct bd_info *bd)
 
for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
if (bd->bi_dram[i].size) {
-   bdinfo_print_num("DRAM bank",   i);
-   bdinfo_print_num("-> start",bd->bi_dram[i].start);
-   bdinfo_print_num("-> size", bd->bi_dram[i].size);
+   bdinfo_print_num_l("DRAM bank", i);
+   

[PATCH v2 08/10] riscv: Change phys_addr_t and phys_size_t to 64-bit

[Bin Meng]

From: Bin Meng 

phys_addr_t and phys_size_t are currently defined as `unsigned long`,
but RV32 supports 34-bit physical address, hence both phys_addr_t and
phys_size_t should be defined to 64-bit using `unsigned long long`.

Signed-off-by: Bin Meng 
---

(no changes since v1)

 arch/riscv/include/asm/types.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/include/asm/types.h b/arch/riscv/include/asm/types.h
index b800b2d221..49f7a5d6b3 100644
--- a/arch/riscv/include/asm/types.h
+++ b/arch/riscv/include/asm/types.h
@@ -35,8 +35,8 @@ typedef u64 dma_addr_t;
 typedef u32 dma_addr_t;
 #endif
 
-typedef unsigned long phys_addr_t;
-typedef unsigned long phys_size_t;
+typedef unsigned long long phys_addr_t;
+typedef unsigned long long phys_size_t;
 
 #endif /* __KERNEL__ */
 
-- 
2.25.1

[PATCH v2 07/10] fdtdec: Cast prior_stage_fdt_address with uintptr_t

[Bin Meng]

From: Bin Meng 

At present prior_stage_fdt_address is declared as phys_addr_t. On
a 32-bit platform where phys_addr_t can be 64-bit, assigning its
value to gd->fdt_blob which is a pointer, can cause warnings.

Cast it to uintptr_t before the assignment.

Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 lib/fdtdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index a2d2fb4e1f..e048fd 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1572,7 +1572,7 @@ int fdtdec_setup(void)
return -1;
}
 # elif defined(CONFIG_OF_PRIOR_STAGE)
-   gd->fdt_blob = (void *)prior_stage_fdt_address;
+   gd->fdt_blob = (void *)(uintptr_t)prior_stage_fdt_address;
 # endif
 # ifndef CONFIG_SPL_BUILD
/* Allow the early environment to override the fdt address */
-- 
2.25.1

[PATCH v2 06/10] net: ftmac100: Cast priv->iobase with uintptr_t

[Bin Meng]

From: Bin Meng 

priv->iobase was declared as phys_addr_t which is now a 64-bit
address. In a 32-bit build, this causes the following warning
seen when building ftmac100.c:

  warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]

Cast priv->iobase with uintptr_t.

Signed-off-by: Bin Meng 
---

Changes in v2:
- new patch: net: ftmac100: Cast priv->iobase with uintptr_t

 drivers/net/ftmac100.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ftmac100.c b/drivers/net/ftmac100.c
index 0d672374fd..fc578b0375 100644
--- a/drivers/net/ftmac100.c
+++ b/drivers/net/ftmac100.c
@@ -35,7 +35,7 @@ struct ftmac100_data {
  */
 static void ftmac100_reset(struct ftmac100_data *priv)
 {
-   struct ftmac100 *ftmac100 = (struct ftmac100 *)priv->iobase;
+   struct ftmac100 *ftmac100 = (struct ftmac100 *)(uintptr_t)priv->iobase;
 
debug ("%s()\n", __func__);
 
@@ -56,7 +56,7 @@ static void ftmac100_reset(struct ftmac100_data *priv)
 static void ftmac100_set_mac(struct ftmac100_data *priv ,
const unsigned char *mac)
 {
-   struct ftmac100 *ftmac100 = (struct ftmac100 *)priv->iobase;
+   struct ftmac100 *ftmac100 = (struct ftmac100 *)(uintptr_t)priv->iobase;
unsigned int maddr = mac[0] << 8 | mac[1];
unsigned int laddr = mac[2] << 24 | mac[3] << 16 | mac[4] << 8 | mac[5];
 
@@ -71,7 +71,7 @@ static void ftmac100_set_mac(struct ftmac100_data *priv ,
  */
 static void _ftmac100_halt(struct ftmac100_data *priv)
 {
-   struct ftmac100 *ftmac100 = (struct ftmac100 *)priv->iobase;
+   struct ftmac100 *ftmac100 = (struct ftmac100 *)(uintptr_t)priv->iobase;
debug ("%s()\n", __func__);
writel (0, >maccr);
 }
@@ -81,7 +81,7 @@ static void _ftmac100_halt(struct ftmac100_data *priv)
  */
 static int _ftmac100_init(struct ftmac100_data *priv, unsigned char 
enetaddr[6])
 {
-   struct ftmac100 *ftmac100 = (struct ftmac100 *)priv->iobase;
+   struct ftmac100 *ftmac100 = (struct ftmac100 *)(uintptr_t)priv->iobase;
struct ftmac100_txdes *txdes = priv->txdes;
struct ftmac100_rxdes *rxdes = priv->rxdes;
unsigned int maccr;
@@ -186,7 +186,7 @@ static int __ftmac100_recv(struct ftmac100_data *priv)
  */
 static int _ftmac100_send(struct ftmac100_data *priv, void *packet, int length)
 {
-   struct ftmac100 *ftmac100 = (struct ftmac100 *)priv->iobase;
+   struct ftmac100 *ftmac100 = (struct ftmac100 *)(uintptr_t)priv->iobase;
struct ftmac100_txdes *curr_des = priv->txdes;
ulong start;
 
-- 
2.25.1

[PATCH v2 05/10] riscv: ax25-ae350: Cast addr with uintptr_t

[Bin Meng]

From: Bin Meng 

addr was delcared as fdt_addr_t which is now a 64-bit address.
In a 32-bit build, this causes the following warning seen when
building ax25-ae350.c:

  warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]

Cast addr with uintptr_t.

Signed-off-by: Bin Meng 
---

Changes in v2:
- new patch: riscv: ax25-ae350: Cast addr with uintptr_t

 board/AndesTech/ax25-ae350/ax25-ae350.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c 
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index 59a43e4dcc..3125233488 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -77,7 +77,7 @@ int smc_init(void)
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
 
-   regs = (struct ftsmc020_bank *)addr;
+   regs = (struct ftsmc020_bank *)(uintptr_t)addr;
regs->cr &= ~FTSMC020_BANK_WPROT;
 
return 0;
-- 
2.25.1

[PATCH v2 03/10] global_data.h: Change ram_top type to phys_addr_t

[Bin Meng]

From: Bin Meng 

It's possible to have ram_top above 4 GiB in a 32-bit system, hence
we need to declare ram_top as `phys_addr_t`.

Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 include/asm-generic/global_data.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/asm-generic/global_data.h 
b/include/asm-generic/global_data.h
index b6f707e97e..998beb0176 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -147,7 +147,7 @@ struct global_data {
/**
 * @ram_top: top address of RAM used by U-Boot
 */
-   unsigned long ram_top;
+   phys_addr_t ram_top;
/**
 * @relocaddr: start address of U-Boot in RAM
 *
-- 
2.25.1

[PATCH v2 04/10] serial: sifive: Cast dev_read_addr() with uintptr_t

[Bin Meng]

From: Bin Meng 

dev_read_addr() returns fdt_addr_t which is now a 64-bit address.
In a 32-bit build, this causes the following warning seen when
building serial_sifive.c:

  warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]

Cast the return value with uintptr_t.

Signed-off-by: Bin Meng 
---

(no changes since v1)

 drivers/serial/serial_sifive.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/serial/serial_sifive.c b/drivers/serial/serial_sifive.c
index d26fe7e770..97bf20c967 100644
--- a/drivers/serial/serial_sifive.c
+++ b/drivers/serial/serial_sifive.c
@@ -178,7 +178,7 @@ static int sifive_serial_of_to_plat(struct udevice *dev)
 {
struct sifive_uart_plat *plat = dev_get_plat(dev);
 
-   plat->regs = (struct uart_sifive *)dev_read_addr(dev);
+   plat->regs = (struct uart_sifive *)(uintptr_t)dev_read_addr(dev);
if (IS_ERR(plat->regs))
return PTR_ERR(plat->regs);
 
-- 
2.25.1

[PATCH v2 02/10] arm: rockchip: Explicitly cast gd->ram_top in dram_init_banksize()

[Bin Meng]

From: Bin Meng 

The min() macro used in dram_init_banksize() requires two elements
to compare have the same type. Let's explicitly cast gd->ram_top.

Signed-off-by: Bin Meng 
---

Changes in v2:
- new patch: arm: rockchip: Explicitly cast gd->ram_top in dram_init_banksize()

 arch/arm/mach-rockchip/sdram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/sdram.c b/arch/arm/mach-rockchip/sdram.c
index 4c637b7767..c3d5fed7db 100644
--- a/arch/arm/mach-rockchip/sdram.c
+++ b/arch/arm/mach-rockchip/sdram.c
@@ -37,7 +37,7 @@ struct tos_parameter_t {
 int dram_init_banksize(void)
 {
size_t top = min((unsigned long)(gd->ram_size + CONFIG_SYS_SDRAM_BASE),
-gd->ram_top);
+(unsigned long)(gd->ram_top));
 
 #ifdef CONFIG_ARM64
/* Reserve 0x20 for ATF bl31 */
-- 
2.25.1

[PATCH v2 01/10] riscv: Adjust board_get_usable_ram_top() for 32-bit

[Bin Meng]

From: Bin Meng 

When testing QEMU RISC-V 'virt' machine with a 2 GiB memory
configuration, it was discovered gd->ram_top is assigned to
value zero in setup_dest_addr().

While gd->ram_top should not be declared as type `unsigned long`,
which will be updated in a future patch, the current logic in
board_get_usable_ram_top() can be updated to cover both 64-bit
and 32-bit RISC-V.

Signed-off-by: Bin Meng 
---

(no changes since v1)

 arch/riscv/cpu/fu540/dram.c   | 7 +++
 arch/riscv/cpu/generic/dram.c | 7 +++
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/arch/riscv/cpu/fu540/dram.c b/arch/riscv/cpu/fu540/dram.c
index 1dc77efeca..259da65a54 100644
--- a/arch/riscv/cpu/fu540/dram.c
+++ b/arch/riscv/cpu/fu540/dram.c
@@ -22,7 +22,6 @@ int dram_init_banksize(void)
 
 ulong board_get_usable_ram_top(ulong total_size)
 {
-#ifdef CONFIG_64BIT
/*
 * Ensure that we run from first 4GB so that all
 * addresses used by U-Boot are 32bit addresses.
@@ -31,8 +30,8 @@ ulong board_get_usable_ram_top(ulong total_size)
 * devices work fine because DMA mapping APIs will
 * provide 32bit DMA addresses only.
 */
-   if (gd->ram_top > SZ_4G)
-   return SZ_4G;
-#endif
+   if (gd->ram_top >= SZ_4G)
+   return SZ_4G - 1;
+
return gd->ram_top;
 }
diff --git a/arch/riscv/cpu/generic/dram.c b/arch/riscv/cpu/generic/dram.c
index 1dc77efeca..259da65a54 100644
--- a/arch/riscv/cpu/generic/dram.c
+++ b/arch/riscv/cpu/generic/dram.c
@@ -22,7 +22,6 @@ int dram_init_banksize(void)
 
 ulong board_get_usable_ram_top(ulong total_size)
 {
-#ifdef CONFIG_64BIT
/*
 * Ensure that we run from first 4GB so that all
 * addresses used by U-Boot are 32bit addresses.
@@ -31,8 +30,8 @@ ulong board_get_usable_ram_top(ulong total_size)
 * devices work fine because DMA mapping APIs will
 * provide 32bit DMA addresses only.
 */
-   if (gd->ram_top > SZ_4G)
-   return SZ_4G;
-#endif
+   if (gd->ram_top >= SZ_4G)
+   return SZ_4G - 1;
+
return gd->ram_top;
 }
-- 
2.25.1