Pull request: u-boot-rockchip-20200820

[Kever Yang]

Hi Tom,

Please pull the rockchip updates/fixes:
- Fix rk3399 evb sdcard support
- Fix for SPL_LED support

Gitlab ci:
https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/4456

Thanks,
- Kever

The following changes since commit 2a4484a5c54cd64d5c4f8fd9aaa56f739d1b2b9d:

  Merge branch '2020-08-19-mediatek-updates' (2020-08-20 08:38:10 -0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git 
tags/u-boot-rockchip-20200820

for you to fetch changes up to b5b81f2490628650137c9fee3679c995f5fac757:

  rockchip: firefly-rk3288: Fix the code support for SPL_LED (2020-08-21 
19:56:19 +0800)


Kever Yang (4):
  rockchip: dts: rk3399-evb: add sdmmc node
  rockchip: config: evb-rk3399: Add rockchip dwmmc support
  rockchip: rk3188: Fix the code support for SPL_LED
  rockchip: firefly-rk3288: Fix the code support for SPL_LED

 arch/arm/dts/rk3399-evb-u-boot.dtsi   | 13 +
 arch/arm/mach-rockchip/rk3188/rk3188.c|  4 +++-
 board/firefly/firefly-rk3288/firefly-rk3288.c |  4 +++-
 configs/evb-rk3399_defconfig  |  1 +
 4 files changed, 20 insertions(+), 2 deletions(-)

[PATCH] MAINTAINERS: update clk entry git tree

[Baruch Siach]

Signed-off-by: Baruch Siach 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e35d5d4fcbf8..739bb1468350 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -609,7 +609,7 @@ F:  drivers/mtd/jedec_flash.c
 CLOCK
 M: Lukasz Majewski 
 S: Maintained
-T: git git://git.denx.de/u-boot-dfu.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-clk.git
 F: drivers/clk/
 F: drivers/clk/imx/
 
-- 
2.28.0

Re: [PATCH v5 00/17] efi_loader: add capsule update support

[AKASHI Takahiro]

Lukasz,

Could you take the time to review my patches, especially
patch#1 to #4 and #12, please?

They are crucial as UEFI capsule update support relies
on new features introduced by them.

# I don't think I would re-post this patch series as no changes
have been made yet.

Thanks,
-Takahiro Akashi

On Mon, Aug 03, 2020 at 02:43:38PM +0900, AKASHI Takahiro wrote:
> Summary
> ===
> 'UpdateCapsule' is one of runtime services defined in UEFI specification
> and its aim is to allow a caller (OS) to pass information to the firmware,
> i.e. U-Boot. This is mostly used to update firmware binary on devices by
> instructions from OS.
> 
> While 'UpdateCapsule' is a runtime services function, it is, at least
> initially, supported only before exiting boot services alike other runtime
> functions, [Get/]SetVariable. This is because modifying storage which may
> be shared with OS must be carefully designed and there is no general
> assumption that we can do it.
> 
> Therefore, we practically support only "capsule on disk"; any capsule can
> be handed over to UEFI subsystem as a file on a specific file system.
> 
> In this patch series, all the related definitions and structures are given
> as UEFI specification describes, and basic framework for capsule support
> is provided. Currently supported is
>  * firmware update (Firmware Management Protocol or simply FMP)
> 
> Most of functionality of firmware update is provided by FMP driver and
> it can be, by nature, system/platform-specific. So you can and should
> implement your own FMP driver(s) based on your system requirements.
> Under the current implementation, we provide two basic but generic
> drivers with two formats:
>   * FIT image format (as used in TFTP update and dfu)
>   * raw image format
> 
> It's totally up to users which one, or both, should be used on users'
> system depending on user requirements.
> 
> Quick usage
> ===
> 1. You can create a capsule file with the following host command:
> 
>   $ mkeficapsule [--fit  | --raw ] 
> 
> 2. Put the file under:
> 
>   /EFI/UpdateCapsule of UEFI system partition
> 
> 3. Specify firmware storage to be updated in "dfu_alt_info" variable
>(Please follow README.dfu for details.)
> 
>   ==> env set dfu_alt_info '...'
> 
> 4. After setting up UEFI's OsIndications variable, reboot U-Boot:
> 
>   OsIndications <= EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED
> 
> Patch structure
> ===
> Patch#1-#4,#12: preparatory patches
> Patch#5-#11,#13: main part of implementation
> Patch#14-#15: utilities
> Patch#16-#17: pytests
> 
> [1] https://git.linaro.org/people/takahiro.akashi/u-boot.git efi/capsule
> 
> Prerequisite patches
> 
> dfu change by Heinrich[2]
> 
> [2] https://lists.denx.de/pipermail/u-boot/2020-July/420950.html
> 
> Test
> 
> * passed all the pytests which are included in this patch series
>   on sandbox build locally.
> 
> Please note that the capsule pytest itself won't be run in the CI
> partly because some specific configuration for sandbox build is
> required and partly because there is a problem with virt-make-fs.
> See test_efi_capsule_firmware.py.
> 
> Issues
> ==
> * Timing of executing capsules-on-disk
>   Currently, processing a capsule is triggered only as part of
>   UEFI subsystem initialization. This means that, for example,
>   firmware update, may not take place at system booting time and
>   will potentially be delayed until a first call of any UEFI functions.
> => See patch#5 for my proposal
> * A bunch of warnings like
> WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef'
> where possible
>   I don't think that fixing those improves anything.
> * Add a document in uefi.rst
> 
> TODO's
> ==
> (Won't be addressed in this series.)
> * capsule authentication
> * capsule dependency (dependency expression instruction set)
> * loading drivers in a capsule
> * handling RESET flag in a capsule and QeuryCapsuleCaps
> * full semantics of ESRT (EFI System Resource Table)
> * enabling capsule API at runtime
> * json capsule
> * recovery from update failure
> 
> Changes
> ===
> v5 (August 3, 2020)
> * removed superfluous type conversion at dfu_write_from_mem_addr()
>   (Patch#2)
> * introduced a common helper function, efi_create_indexed_name()
>   (Patch#6,#7,#8)
> * use efi_[get|set]_variable_int(), if necessary, with READ_ONLY
>   (Patch#7,#8)
> * return EFI_UNSUPPORTED at Patch#7
> * changed the word, number, to 'index' (Patch#7,#8)
> * removed 'ifdef CONFIG_EFI_CAPSULE_ON_DISK' from a header (Patch#8)
> * initialize 'CapsuleLast' in efi_init_obj_list() (Patch#7,#8)
> * added 'const' qualifier for filename argument at
>   efi_capsule_[read|delete]_file() (Patch#8)
> 
> 
> 
> v4 (July 22, 2020)
> * rebased to Heinrich's current efi-2020-10
> * rework dfu-related code to align with Heinrich's change (Patch#1,#3)
> * change a type of 'addr' argument from int to 'void *' per Sughosh's
>   comment (Patch#2-#3,

Re: [PATCH] i2c: octeon_i2c: Misc fixes for ARM Octeon TX2 support

[Heiko Schocher]

Hello Stefan,

Am 23.07.2020 um 14:09 schrieb Stefan Roese:

This patch fixes a few issues noticed, when testing this new driver on
ARM Octeon TX2 again. Here the details:

- Remove "common.h" header inclusion
- Use correct THP define on Octeon TX2
- Octeon TX2 uses the same compatible as Octeon TX. We can't distinguish
   both platforms this way. Remove the unused "cavium,thunder2-99xx-twsi"
   compatible and add a check to the Octeon TX2 specific
   "cavium,thunderx-i2c" so that the correct driver data is selected.
- Removed "struct pci_device_id" definition and U_BOOT_PCI_DEVICE()
   as its not needed for the PCI based probing on Octeon TX2

Signed-off-by: Stefan Roese 
Cc: Heiko Schocher 
Cc: Daniel Schwierzeck 
Cc: Suneel Garapati 
Cc: Aaron Williams 
Cc: Chandrakala Chavva 
---
  drivers/i2c/octeon_i2c.c | 59 ++--
  1 file changed, 26 insertions(+), 33 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v3 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN

[Heinrich Schuchardt]

On 7/25/20 8:18 PM, Heinrich Schuchardt wrote:
> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any
> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before
> relocation.
>
> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image
> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC.
>
> CONFIG_LOG=Y is another setting requiring additional early malloc
> area, cf. log_init().
>
> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled
> we see as output in main U-Boot
>
> alloc_simple() alloc space exhausted
>
> With this patch the default values of SYS_MALLOC_F_LEN and
> SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000.
>
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Jagan Teki 

With current pine64-lts_defconfig we get a warning:

"alloc space exhausted"

So, please, merge the patch.

Best regards

Heinrich

Re: [PATCH 0/7] binman: Add support for generating more complex FITs

[Heinrich Schuchardt]

On 8/22/20 4:36 AM, Simon Glass wrote:
> This series allows binman to generate FITs that include multiple DTB
> images and the configuration to use them.
>
> It is then possible to remove the sunxi FIT generator script, so this
> series handles that also.
>
> With this, sunxi is fully converted to use binman.

I have applied this patch series and it does not work on my
pine64-lts_defconfig.

Environment variable BL31 points to my bl31.bin:

$ echo $BL31
../trusted-firmware-a/build/sun50i_a64/debug/bl31.bin

U-Boot SPL 2020.10-rc2-00147-g72293dc579 (Aug 25 2020 - 03:29:28 +)
DRAM: 2048 MiB
Trying to boot from MMC1
No matching DT out of these options:
   Configuration to load ATF before U-Boot
No matching DT out of these options:
   Configuration to load ATF before U-Boot
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Without your patches U-Boot works. But CONFIG_SYS_MALLOC_F_LEN=0x400 is
too small. This results in a warning "alloc space exhausted". Cf.
https://patchwork.ozlabs.org/project/uboot/patch/20200725181851.4339-1-xypron.g...@gmx.de/

U-Boot SPL 2020.10-rc2-00140-g1aa3966173 (Aug 25 2020 - 03:46:36 +)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.2():v2.2-1138-g78460ced4
NOTICE:  BL31: Built : 05:50:47, Apr  7 2020
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x4092cc8, model: Pine64 LTS
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
INFO:PMIC: Probing AXP803 on RSB
INFO:PMIC: dcdc1 voltage: 3.300V
INFO:PMIC: dcdc5 voltage: 1.200V
INFO:PMIC: dcdc6 voltage: 1.100V
INFO:PMIC: dldo1 voltage: 3.300V
INFO:PMIC: dldo2 voltage: 3.300V
INFO:PMIC: dldo4 voltage: 3.300V
INFO:PMIC: fldo1 voltage: 1.200V
INFO:PMIC: Enabling DC SW
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
NOTICE:  PSCI: System suspend is unavailable
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9
alloc space exhausted


U-Boot 2020.10-rc2-00140-g1aa3966173 (Aug 25 2020 - 03:46:36 +)
Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pine64 LTS
DRAM:  2 GiB
MMC:   mmc@1c0f000: 0, mmc@1c11000: 1
Loading Environment from FAT... Card did not respond to voltage select!
In:serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c3
Hit any key to stop autoboot:  0

Best regards

Heinrich

>
>
> Simon Glass (7):
>   binman: Allow entry args to be required
>   binman: Fix up a few missing comments
>   libfdt: Detected out-of-space with fdt_finish()
>   binman: Add support for ATF BL31
>   binman: Support generating FITs with multiple dtbs
>   sunxi: Convert 64-bit boards to use binman
>   sunxi: Drop the FIT-generator script
>
>  Kconfig |   3 +-
>  Makefile|  18 +---
>  arch/arm/dts/sunxi-u-boot.dtsi  |  60 +++-
>  board/sunxi/mksunxi_fit_atf.sh  |  87 -
>  scripts/dtc/pylibfdt/libfdt.i_shipped   |   3 +-
>  tools/binman/README.entries |  59 ++-
>  tools/binman/etype/atf_bl31.py  |  20 
>  tools/binman/etype/blob_named_by_arg.py |  10 +-
>  tools/binman/etype/cros_ec_rw.py|   3 +-
>  tools/binman/etype/fit.py   |  76 +--
>  tools/binman/ftest.py   | 124 ++--
>  tools/binman/test/165_atf_bl31.dts  |  16 +++
>  tools/binman/test/166_fit_fdt.dts   |  55 +++
>  13 files changed, 405 insertions(+), 129 deletions(-)
>  delete mode 100755 board/sunxi/mksunxi_fit_atf.sh
>  create mode 100644 tools/binman/etype/atf_bl31.py
>  create mode 100644 tools/binman/test/165_atf_bl31.dts
>  create mode 100644 tools/binman/test/166_fit_fdt.dts
>

Re: [PATCH 4/7] binman: Add support for ATF BL31

[Heinrich Schuchardt]

On 8/25/20 4:44 AM, Kever Yang wrote:
> Hi Simon,
>
> On 2020/8/22 上午10:36, Simon Glass wrote:
>> Add an entry for ARM Trusted Firmware's 'BL31' payload, which is the
>> device's main firmware. Typically this is U-Boot.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>>   tools/binman/README.entries    | 10 ++
>>   tools/binman/etype/atf_bl31.py | 20 
>>   tools/binman/ftest.py  |  9 +
>>   tools/binman/test/165_atf_bl31.dts | 16 
>>   4 files changed, 55 insertions(+)
>>   create mode 100644 tools/binman/etype/atf_bl31.py
>>   create mode 100644 tools/binman/test/165_atf_bl31.dts
>>
>> diff --git a/tools/binman/README.entries b/tools/binman/README.entries
>> index 97bfae16116..85b8ec9fa73 100644
>> --- a/tools/binman/README.entries
>> +++ b/tools/binman/README.entries
>> @@ -11,6 +11,16 @@ features to produce new behaviours.
>>       +Entry: atf-bl31: Entry containing an ARM Trusted Firmware (ATF)
>> BL31 blob
>> +-
>>
>> +
>> +Properties / Entry arguments:
>> +    - atf-bl31-path: Filename of file to read into entry
>> +
>> +This entry holds the run-time firmware started by ATF.
>> +
>> +
>> +
>>   Entry: blob: Entry containing an arbitrary binary blob
>>   --
>>   diff --git a/tools/binman/etype/atf_bl31.py
>> b/tools/binman/etype/atf_bl31.py
>> new file mode 100644
>> index 000..fd7223843b1
>> --- /dev/null
>> +++ b/tools/binman/etype/atf_bl31.py
>> @@ -0,0 +1,20 @@
>> +# SPDX-License-Identifier: GPL-2.0+
>> +# Copyright (c) 2016 Google, Inc
>> +# Written by Simon Glass 
>> +#
>> +# Entry-type module for Intel Management Engine binary blob
>> +#
>> +
>> +from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
>> +
>> +class Entry_atf_bl31(Entry_blob_named_by_arg):
>> +    """Entry containing an ARM Trusted Firmware (ATF) BL31 blob
>> +
>> +    Properties / Entry arguments:
>> +    - atf-bl31-path: Filename of file to read into entry
>> +
>> +    This entry holds the run-time firmware started by ATF.
>> +    """
>> +    def __init__(self, section, etype, node):
>> +    super().__init__(section, etype, node, 'atf-bl31')
>> +    self.external = True
>> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
>> index 8d687162185..30c9c764327 100644
>> --- a/tools/binman/ftest.py
>> +++ b/tools/binman/ftest.py
>> @@ -75,6 +75,7 @@ REFCODE_DATA  = b'refcode'
>>   FSP_M_DATA    = b'fsp_m'
>>   FSP_S_DATA    = b'fsp_s'
>>   FSP_T_DATA    = b'fsp_t'
>> +ATF_BL31_DATA = b'bl31'
>>     # The expected size for the device tree in some tests
>>   EXTRACT_DTB_SIZE = 0x3c9
>> @@ -168,6 +169,7 @@ class TestFunctional(unittest.TestCase):
>>   os.path.join(cls._indir, 'files'))
>>     TestFunctional._MakeInputFile('compress', COMPRESS_DATA)
>> +    TestFunctional._MakeInputFile('bl31.bin', ATF_BL31_DATA)
>
>
> Should this be 'bl31.elf' from ARM TF project instead of 'bl31.bin'?

The file that I need to include from the TF-A project is:

/build/sun50i_a64/debug/bl31.bin

Best regards

Heinrich

>
> Thanks,
>
> - Kever
>
>>     # Travis-CI may have an old lz4
>>   cls.have_lz4 = True
>> @@ -3505,5 +3507,12 @@ class TestFunctional(unittest.TestCase):
>>   self.assertIn("Missing required properties/entry args:
>> cros-ec-rw-path",
>>     str(e.exception))
>>   +    def testPackBl31(self):
>> +    """Test that an image with an ATF BL31 binary can be created"""
>> +    data = self._DoReadFile('165_atf_bl31.dts')
>> +    self.assertEqual(ATF_BL31_DATA, data[:len(ATF_BL31_DATA)])
>> +
>> +ATF_BL31_DATA
>> +
>>   if __name__ == "__main__":
>>   unittest.main()
>> diff --git a/tools/binman/test/165_atf_bl31.dts
>> b/tools/binman/test/165_atf_bl31.dts
>> new file mode 100644
>> index 000..2b7547d70f9
>> --- /dev/null
>> +++ b/tools/binman/test/165_atf_bl31.dts
>> @@ -0,0 +1,16 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +
>> +/dts-v1/;
>> +
>> +/ {
>> +    #address-cells = <1>;
>> +    #size-cells = <1>;
>> +
>> +    binman {
>> +    size = <16>;
>> +
>> +    atf-bl31 {
>> +    filename = "bl31.bin";
>> +    };
>> +    };
>> +};
>
>

RE: [v3, 06/11] mmc: add a mmc_hs400_prepare_ddr() interface

[Y.b. Lu]

Hi Jaehoon,

> -Original Message-
> From: Jaehoon Chung 
> Sent: Tuesday, August 25, 2020 6:54 AM
> To: Y.b. Lu ; u-boot@lists.denx.de; Peng Fan
> ; Priyanka Jain 
> Subject: Re: [v3, 06/11] mmc: add a mmc_hs400_prepare_ddr() interface
> 
> On 7/23/20 1:30 PM, Yangbo Lu wrote:
> > Add a mmc_hs400_prepare_ddr() interface for controllers
> > which needs preparation before switching to DDR mode for
> > HS400 mode.
> >
> > Signed-off-by: Yangbo Lu 
> > ---
> > Changes for v2:
> > - None.
> > Changes for v3:
> > - None.
> > ---
> >  drivers/mmc/mmc-uclass.c | 15 +++
> >  drivers/mmc/mmc.c|  2 ++
> >  include/mmc.h| 15 ++-
> >  3 files changed, 31 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> > index b9f0880..240b205 100644
> > --- a/drivers/mmc/mmc-uclass.c
> > +++ b/drivers/mmc/mmc-uclass.c
> > @@ -141,6 +141,21 @@ int mmc_set_enhanced_strobe(struct mmc *mmc)
> >  }
> >  #endif
> >
> > +int dm_mmc_hs400_prepare_ddr(struct udevice *dev)
> > +{
> > +   struct dm_mmc_ops *ops = mmc_get_ops(dev);
> > +
> > +   if (ops->hs400_prepare_ddr)
> > +   return ops->hs400_prepare_ddr(dev);
> > +
> > +   return 0;
> > +}
> > +
> > +int mmc_hs400_prepare_ddr(struct mmc *mmc)
> > +{
> > +   return dm_mmc_hs400_prepare_ddr(mmc->dev);
> > +}
> > +
> >  int dm_mmc_host_power_cycle(struct udevice *dev)
> >  {
> > struct dm_mmc_ops *ops = mmc_get_ops(dev);
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index f020a8e..935fa72 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -1992,6 +1992,8 @@ static int mmc_select_hs400(struct mmc *mmc)
> > /* Set back to HS */
> > mmc_set_card_speed(mmc, MMC_HS, true);
> >
> > +   mmc_hs400_prepare_ddr(mmc);
> 
> not need to get the return value? you have defined
> mmc_hs400_prepare_ddr() as int return type.

I will add returning checking.
Thanks!

> 
> Best Regards,
> Jaehoon Chung
> 
> > +
> > err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
> EXT_CSD_BUS_WIDTH,
> >  EXT_CSD_BUS_WIDTH_8 | EXT_CSD_DDR_FLAG);
> > if (err)
> > diff --git a/include/mmc.h b/include/mmc.h
> > index 2399cc2..659df75 100644
> > --- a/include/mmc.h
> > +++ b/include/mmc.h
> > @@ -513,6 +513,14 @@ struct dm_mmc_ops {
> >  * @return maximum number of blocks for this transfer
> >  */
> > int (*get_b_max)(struct udevice *dev, void *dst, lbaint_t blkcnt);
> > +
> > +   /**
> > +* hs400_prepare_ddr - prepare to switch to DDR mode
> > +*
> > +* @dev:Device to check
> > +* @return 0 if success, -ve on error
> > +*/
> > +   int (*hs400_prepare_ddr)(struct udevice *dev);
> >  };
> >
> >  #define mmc_get_ops(dev)((struct dm_mmc_ops
> *)(dev)->driver->ops)
> > @@ -540,7 +548,7 @@ int mmc_host_power_cycle(struct mmc *mmc);
> >  int mmc_deferred_probe(struct mmc *mmc);
> >  int mmc_reinit(struct mmc *mmc);
> >  int mmc_get_b_max(struct mmc *mmc, void *dst, lbaint_t blkcnt);
> > -
> > +int mmc_hs400_prepare_ddr(struct mmc *mmc);
> >  #else
> >  struct mmc_ops {
> > int (*send_cmd)(struct mmc *mmc,
> > @@ -552,6 +560,11 @@ struct mmc_ops {
> > int (*host_power_cycle)(struct mmc *mmc);
> > int (*get_b_max)(struct mmc *mmc, void *dst, lbaint_t blkcnt);
> >  };
> > +
> > +static inline int mmc_hs400_prepare_ddr(struct mmc *mmc)
> > +{
> > +   return 0;
> > +}
> >  #endif
> >
> >  struct mmc_config {
> >

RE: [v3, 05/11] mmc: add a hs400_tuning flag

[Y.b. Lu]

Hi Jaehoon,

> -Original Message-
> From: Jaehoon Chung 
> Sent: Tuesday, August 25, 2020 6:54 AM
> To: Y.b. Lu ; u-boot@lists.denx.de; Peng Fan
> ; Priyanka Jain 
> Subject: Re: [v3, 05/11] mmc: add a hs400_tuning flag
> 
> On 7/23/20 1:30 PM, Yangbo Lu wrote:
> > Some controllers may have difference between HS200 tuning
> > and HS400 tuning, such as different registers setting,
> > different procedure, or different errata.
> >
> > This patch is to add a hs400_tuning flag to identify the
> > tuning for HS400 mode.
> >
> > Signed-off-by: Yangbo Lu 
> > ---
> > Changes for v2:
> > - None.
> > Changes for v3:
> > - Explained more in commit messages.
> > ---
> >  drivers/mmc/mmc.c | 2 ++
> >  include/mmc.h | 1 +
> >  2 files changed, 3 insertions(+)
> >
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index a4c6153..f020a8e 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -1981,7 +1981,9 @@ static int mmc_select_hs400(struct mmc *mmc)
> > mmc_set_clock(mmc, mmc->tran_speed, false);
> >
> > /* execute tuning if needed */
> > +   mmc->hs400_tuning = 1;
> > err = mmc_execute_tuning(mmc,
> MMC_CMD_SEND_TUNING_BLOCK_HS200);
> > +   mmc->hs400_tuning = 0;
> 
> It seems that it's fsl_esdhc specific flag. Is it need to set to 0?

From mmc driver, both HS200 and HS400 tuning are through 
mmc_execute_tuning(mmc, MMC_CMD_SEND_TUNING_BLOCK_HS200).
But as I commented in commit message,
"Some controllers may have difference between HS200 tuning
and HS400 tuning, such as different registers setting,
different procedure, or different errata."
So we could use such flag to indicate the tuning in progress is for HS400. Set 
it before tuning and clean after tuning.
By now, only fsl_esdhc is using it. I can't predict whether there will be other 
controllers use it, but at least we need a method to identify HS400 tuning to 
support eSDHC HS400 currently.
There are also errata for eSDHC HS400 tuning. I will send patches in the future.
Thanks.

> 
> Best Regards,
> Jaehoon Chung
> 
> > if (err) {
> > debug("tuning failed\n");
> > return err;
> > diff --git a/include/mmc.h b/include/mmc.h
> > index 161b8bc..2399cc2 100644
> > --- a/include/mmc.h
> > +++ b/include/mmc.h
> > @@ -707,6 +707,7 @@ struct mmc {
> >   * accessing the boot partitions
> >   */
> > u32 quirks;
> > +   u8 hs400_tuning;
> >  };
> >
> >  struct mmc_hwpart_conf {
> >

[PATCH] serial: zynq: disable TX and RX while changing baud rate

[Norbert Braun]

According to the Zynq-7000 TRM (UG585), the UART transmitter and
receiver must be disabled while changing the baud rate. Change
_uart_zynq_serial_setbrg accordingly.
---
 drivers/serial/serial_zynq.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/serial_zynq.c b/drivers/serial/serial_zynq.c
index 0e71cada1b..4f7bab16fa 100644
--- a/drivers/serial/serial_zynq.c
+++ b/drivers/serial/serial_zynq.c
@@ -23,7 +23,9 @@
 #define ZYNQ_UART_SR_TXFULLBIT(4) /* TX FIFO full */
 #define ZYNQ_UART_SR_RXEMPTY   BIT(1) /* RX FIFO empty */
 
+#define ZYNQ_UART_CR_TX_DISBIT(5) /* TX disable */
 #define ZYNQ_UART_CR_TX_EN BIT(4) /* TX enabled */
+#define ZYNQ_UART_CR_RX_DISBIT(3) /* RX disable */
 #define ZYNQ_UART_CR_RX_EN BIT(2) /* RX enabled */
 #define ZYNQ_UART_CR_TXRST BIT(1) /* TX logic reset */
 #define ZYNQ_UART_CR_RXRST BIT(0) /* RX logic reset */
@@ -82,8 +84,26 @@ static void _uart_zynq_serial_setbrg(struct uart_zynq *regs,
break;
}
 
-   writel(bdiv, ®s->baud_rate_divider);
-   writel(bgen, ®s->baud_rate_gen);
+   /* Check if baud rate registers actually need to be changed. */
+   if(readl(®s->baud_rate_divider) != bdiv ||
+  readl(®s->baud_rate_gen) != bgen) {
+   /*
+* Configure the baud rate.
+*
+* This follows the procedure from the
+* Zynq-7000 SoC Technical Reference Manual,
+* UG585 (v1.12.2),
+* section 19.3.2, part 2.
+*/
+
+   writel(ZYNQ_UART_CR_RX_DIS, ®s->control);
+   writel(ZYNQ_UART_CR_TX_DIS, ®s->control);
+   writel(bgen, ®s->baud_rate_gen);
+   writel(bdiv, ®s->baud_rate_divider);
+   writel(ZYNQ_UART_CR_TXRST | ZYNQ_UART_CR_RXRST, ®s->control);
+   writel(ZYNQ_UART_CR_RX_EN, ®s->control);
+   writel(ZYNQ_UART_CR_TX_EN, ®s->control);
+   }
 }
 
 /* Initialize the UART, with...some settings. */
-- 
2.17.1

Re: [Xilinx Zynq]: spurious UART receive on startup

[Norbert Braun]

Hi,

On 17.08.20 12:07, Michal Simek wrote:

> Hi,
>
> ne 16. 8. 2020 v 13:43 odesílatel Norbert Braun  napsal:
>> Hi,
>>
>> I am running into a problem with U-Boot v2020.07 on Xilinx Zynq
>> (Zedboard). If I build U-Boot with the default config
>> (xilinx_zynq_virt_defconfig, DEVICE_TREE=zynq-zed), autoboot will abort,
>> even if no key is pressed. This happens regardless of whether the USB
>> UART is even connected to a PC.
>>
>> I am using boot.bin as generated by U-Boot as the SPL (plus u-boot.img
>> for U-Boot proper).
>>
>> While debugging this, I noticed two things:
>>
>> 1. The Zynq TRM [1] notes in section 19.2.3 ("Baud generator"):
>> IMPORTANT: It is essential to disable the transmitter and receiver
>> before writing to the Baud Rate Generator register
>> (uart.Baud_rate_gen_reg0), or the baud rate divider register
>> (uart.Baud_rate_divider_reg0). A soft reset must be issued to both
>> the transmitter and receiver before they are re-enabled.
>>
>> However, the code in _uart_zynq_serial_setbrg() (in
>> drivers/serial/serial_zynq.c) does not seem to do that.
> I have reported this internally at Xilinx to fix this but none has
> looked at it yet.
> But definitely feel free to send a patch to fix it. I expect the
> similar issue is when
> you change baudrate via prompt.

Ok, I will send a patch (see next mail).

The patch does not seem to make much of a difference for changing the baud rate
via prompt; it works for me with or without the patch. One thing I have noticed
is that on_baudrate prints a string ("## Switch baudrate to [...]") and then
waits for a fixed 50ms delay before changing the baud rate. If the original
baud rate is low (e.g. 4800 bps), this causes the string to be truncated, but
again, the patch makes no difference there.

>> 2. It seems that the Zynq BootROM actually touches the registers for
>> UART1. I have no idea why it does that, but table 6-22 ("BootROM
>> Modified Registers") in the TRM lists several UART1 registers that have
>> been modified from their reset value. In particular, the control
>> register at 0xE0001000 contains the value 0x0114 after the BootROM ran.
>>
>> As zynq_serial_probe() checks if TX is enabled (bit 4 in the control
>> register), and only writes to the control register if it is not, the end
>> result is that U-Boot never really initializes UART1 or resets its TX or
>> RX path.
> I have added this code because when reinitialization was happening there were
> random chars emitted. Not sure which flow you use. But I didn't see any issue
> in SPL boot flow.

Basically, I do the following:

git checkout v2020.07
export CROSS_COMPILE=arm-linux-gnueabihf-
export ARCH=arm
export DEVICE_TREE=zynq-zed
make xilinx_zynq_virt_defconfig
make

cp u-boot.img [ to SD card ]
cp spl/boot.bin [ to SD card ]

This is sufficient to demonstrate the problem on my Zedboard. (There are no
other files on the SD card.)

One thing I should have mentioned (sorry!) is that I have a Rev. C Zedboard
with an ES (engineering sample) Zynq SoC on it. Maybe there is some difference
that is causing the problem, and production silicon is unaffected.  Still,
following the recommendation in the TRM when changing the baud rate probably
cannot hurt.

>> If the debug UART functionality (CONFIG_DEBUG_UART_ZYNQ) is enabled,
>> _debug_uart_init() writes to the control register unconditionally and
>> resets the TX/RX path. Indeed, enabling the debug UART functionality
>> makes my problem disappear. The debug UART was enabled by default in
>> zynq_zed_defconfig (in v2019.10), but this changed when switching to a
>> single Zynq configuration (xilinx_zynq_virt_defconfig) for v2020.07.
>>
>> Note that the above workaround fixes the problem for me, but I wanted to
>> report it in case other people run into the same issue.
> Bootrom shouldn't touch these regs. It is code in ps7_init which does it.
> It means take a look at it. It should do full uart initialization.

I looked at board/xilinx/zynq/zynq-zed/ps7_init_gpl.c, but it does not seem to
touch the UART registers. It does set up pinmuxing and enables the UART
peripheral clock, but it does not access any register in the 0XE0001xxx range.

> Thanks,
> Michal

Thanks,

Norbert

Re: [PATCH 4/7] binman: Add support for ATF BL31

[Kever Yang]

Hi Simon,

On 2020/8/22 上午10:36, Simon Glass wrote:

Add an entry for ARM Trusted Firmware's 'BL31' payload, which is the
device's main firmware. Typically this is U-Boot.

Signed-off-by: Simon Glass 
---

  tools/binman/README.entries| 10 ++
  tools/binman/etype/atf_bl31.py | 20 
  tools/binman/ftest.py  |  9 +
  tools/binman/test/165_atf_bl31.dts | 16 
  4 files changed, 55 insertions(+)
  create mode 100644 tools/binman/etype/atf_bl31.py
  create mode 100644 tools/binman/test/165_atf_bl31.dts

diff --git a/tools/binman/README.entries b/tools/binman/README.entries
index 97bfae16116..85b8ec9fa73 100644
--- a/tools/binman/README.entries
+++ b/tools/binman/README.entries
@@ -11,6 +11,16 @@ features to produce new behaviours.
  
  
  
+Entry: atf-bl31: Entry containing an ARM Trusted Firmware (ATF) BL31 blob

+-
+
+Properties / Entry arguments:
+- atf-bl31-path: Filename of file to read into entry
+
+This entry holds the run-time firmware started by ATF.
+
+
+
  Entry: blob: Entry containing an arbitrary binary blob
  --
  
diff --git a/tools/binman/etype/atf_bl31.py b/tools/binman/etype/atf_bl31.py

new file mode 100644
index 000..fd7223843b1
--- /dev/null
+++ b/tools/binman/etype/atf_bl31.py
@@ -0,0 +1,20 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2016 Google, Inc
+# Written by Simon Glass 
+#
+# Entry-type module for Intel Management Engine binary blob
+#
+
+from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
+
+class Entry_atf_bl31(Entry_blob_named_by_arg):
+"""Entry containing an ARM Trusted Firmware (ATF) BL31 blob
+
+Properties / Entry arguments:
+- atf-bl31-path: Filename of file to read into entry
+
+This entry holds the run-time firmware started by ATF.
+"""
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node, 'atf-bl31')
+self.external = True
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 8d687162185..30c9c764327 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -75,6 +75,7 @@ REFCODE_DATA  = b'refcode'
  FSP_M_DATA= b'fsp_m'
  FSP_S_DATA= b'fsp_s'
  FSP_T_DATA= b'fsp_t'
+ATF_BL31_DATA = b'bl31'
  
  # The expected size for the device tree in some tests

  EXTRACT_DTB_SIZE = 0x3c9
@@ -168,6 +169,7 @@ class TestFunctional(unittest.TestCase):
  os.path.join(cls._indir, 'files'))
  
  TestFunctional._MakeInputFile('compress', COMPRESS_DATA)

+TestFunctional._MakeInputFile('bl31.bin', ATF_BL31_DATA)



Should this be 'bl31.elf' from ARM TF project instead of 'bl31.bin'?

Thanks,

- Kever

  
  # Travis-CI may have an old lz4

  cls.have_lz4 = True
@@ -3505,5 +3507,12 @@ class TestFunctional(unittest.TestCase):
  self.assertIn("Missing required properties/entry args: 
cros-ec-rw-path",
str(e.exception))
  
+def testPackBl31(self):

+"""Test that an image with an ATF BL31 binary can be created"""
+data = self._DoReadFile('165_atf_bl31.dts')
+self.assertEqual(ATF_BL31_DATA, data[:len(ATF_BL31_DATA)])
+
+ATF_BL31_DATA
+
  if __name__ == "__main__":
  unittest.main()
diff --git a/tools/binman/test/165_atf_bl31.dts 
b/tools/binman/test/165_atf_bl31.dts
new file mode 100644
index 000..2b7547d70f9
--- /dev/null
+++ b/tools/binman/test/165_atf_bl31.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   binman {
+   size = <16>;
+
+   atf-bl31 {
+   filename = "bl31.bin";
+   };
+   };
+};

Pull request: u-boot-riscv/master 20200825

[uboot]

Hi Tom,

Please pull some riscv updates:

- Sipeed Maix support S-mode.
- Provide command sbi.
- Use fdtdec_get_addr_size_auto_parent to get fu540 cache base address.
- Fix a compiler error with CONFIG_SPL_SMP=n.
- Fix sifive ram driver 32 compiler warnings.
- Fix kendryte/pll.h redefine nop() warning.

Thanks
Rick

https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/720564636

The following changes since commit 1aa3966173fe92fa3c46638ee8eb8b8491f521d6:

  Merge tag 'u-boot-clk-24Aug2020' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-clk (2020-08-24 09:06:02 -0400)

are available in the Git repository at:

  g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git

for you to fetch changes up to c92b50a44b95e706b9c0c97544bd7504fe6d36e9:

  cmd: provide command sbi (2020-08-25 09:34:47 +0800)


Bin Meng (2):
  riscv: fu540: Use correct API to get L2 cache controller base address
  ram: sifive: Fix compiler warnings for 32-bit

Heinrich Schuchardt (4):
  clk: kendryte/pll.h: do not redefine nop()
  riscv: fix building with CONFIG_SPL_SMP=n
  configs: defconfig for Sipeed Maix in S-mode
  cmd: provide command sbi

 arch/riscv/cpu/fu540/cache.c|  3 ++-
 arch/riscv/include/asm/sbi.h|  2 ++
 arch/riscv/lib/sbi.c| 36 
 arch/riscv/lib/spl.c|  2 +-
 board/sipeed/maix/MAINTAINERS   |  2 +-
 cmd/Kconfig |  6 ++
 cmd/riscv/Makefile  |  1 +
 cmd/riscv/sbi.c | 82 
++
 configs/sipeed_maix_smode_defconfig | 10 ++
 doc/board/sipeed/maix.rst   | 49 
+
 drivers/ram/sifive/fu540_ddr.c  |  4 ++--
 include/kendryte/pll.h  |  5 +
 12 files changed, 197 insertions(+), 5 deletions(-)
 create mode 100644 cmd/riscv/sbi.c
 create mode 100644 configs/sipeed_maix_smode_defconfig

[PATCH 3/3] net: tftp: Fix load_block offset calculation

[Ley Foon Tan]

When load the last block, the "len" might not be a block size. This cause
loading the incorrect last block data.

The fix change "len" to tftp_block_size and minus one tftp_block_size
for offset calculation.

Use same offset calculation formula as in store_block().

Signed-off-by: Ley Foon Tan 
---
 net/tftp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/tftp.c b/net/tftp.c
index 6e68a427d4cf..292e7b4cddcf 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -218,7 +218,8 @@ static void new_transfer(void)
 static int load_block(unsigned block, uchar *dst, unsigned len)
 {
/* We may want to get the final block from the previous set */
-   ulong offset = ((int)block - 1) * len + tftp_block_wrap_offset;
+   ulong offset = block * tftp_block_size + tftp_block_wrap_offset -
+  tftp_block_size;
ulong tosend = len;
 
tosend = min(net_boot_file_size - offset, tosend);
-- 
2.19.0

[PATCH 2/3] net: tftp: Fix store_block offset calculation

[Ley Foon Tan]

tftp_cur_block start with 1 for first block, but tftp_cur_block counter is
start with zero when block number is rollover. The existing code
"tftp_cur_block - 1" will cause the block number become -1 in store_block()
when tftp_cur_block is 0 when tftp_cur_block is rollover.

The fix pass in tftp_cur_block to store_block() and minus the
tftp_block_size when do the offset calculation.

Signed-off-by: Ley Foon Tan 
---
 net/tftp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/tftp.c b/net/tftp.c
index 9ca7db256112..6e68a427d4cf 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -143,7 +143,8 @@ static unsigned short tftp_block_size_option = 
CONFIG_TFTP_BLOCKSIZE;
 
 static inline int store_block(int block, uchar *src, unsigned int len)
 {
-   ulong offset = block * tftp_block_size + tftp_block_wrap_offset;
+   ulong offset = block * tftp_block_size + tftp_block_wrap_offset -
+   tftp_block_size;
ulong newsize = offset + len;
ulong store_addr = tftp_load_addr + offset;
 #ifdef CONFIG_SYS_DIRECT_FLASH_TFTP
@@ -597,7 +598,7 @@ static void tftp_handler(uchar *pkt, unsigned dest, struct 
in_addr sip,
timeout_count_max = tftp_timeout_count_max;
net_set_timeout_handler(timeout_ms, tftp_timeout_handler);
 
-   if (store_block(tftp_cur_block - 1, pkt + 2, len)) {
+   if (store_block(tftp_cur_block, pkt + 2, len)) {
eth_halt();
net_set_state(NETLOOP_FAIL);
break;
-- 
2.19.0

[PATCH 1/3] net: tftp: Fix tftp_prev_block counter update

[Ley Foon Tan]

Fixes missing update to tftp_prev_block counter before increase
tftp_cur_block counter when do the tftpput operation.

tftp_prev_block counter is used in update_block_number() function to
check whether block number (sequence number) is rollover. This bug
cause the tftpput command fail to upload a large file when block
number is greater than 16-bit (0x).

Signed-off-by: Ley Foon Tan 
---
 net/tftp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/tftp.c b/net/tftp.c
index c05b7b5532b9..9ca7db256112 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -478,6 +478,7 @@ static void tftp_handler(uchar *pkt, unsigned dest, struct 
in_addr sip,
int block = ntohs(*s);
int ack_ok = (tftp_cur_block == block);
 
+   tftp_prev_block = tftp_cur_block;
tftp_cur_block = (unsigned short)(block + 1);
update_block_number();
if (ack_ok)
-- 
2.19.0

[PATCH 0/3] net: tftp: Fixes for tftp rollover

[Ley Foon Tan]

This patch series fix the tftp block number rollover bugs
when sending and receiving large file (block number
greater than 16-bit).

Tested receiving and sending large file with block
number greater than 0x, verified content
is 100% matched. Tested file size 128MB and 256MB.

Ley Foon Tan (3):
  net: tftp: Fix tftp_prev_block counter update
  net: tftp: Fix store_block offset calculation
  net: tftp: Fix load_block offset calculation

 net/tftp.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

-- 
2.19.0

Re: [PATCH] mmc: pic32: PIC32MZDA SDHCI controller non-functional

[Jaehoon Chung]

Hi,

CC'd Peng.

On 8/22/20 11:37 AM, John Robertson wrote:
> Refresh driver code, remove obsolete DT props and set the max clock
> rate from the source clock 'base_clk'.
> 
> Card detect is also broken. The fix implemented for erratum #15
> documented in Microchip ref. DS8736D only needs to be done as
> in the current code (set CDSSEL, clear CDTLVL in SDHCCON1 to force
> 'detect') if the SDCD pin is not connected. If it is connected,
> card detect works fine. A vendor specific flag 'microchip,use-sdcd'
> has been added to enable real card detect functionality.
> 
> The card detect signal CDSLVL provided in the status register is
> inverted as described in erratum #16, but this does not apply to
> U-Boot because it uses the card inserted CARDINS flag. Therefore,
> 'cd-inverted' is not required.
> 
> Signed-off-by: John Robertson 
> ---
> 
>  arch/mips/dts/pic32mzda_sk.dts  |  1 +
>  drivers/mmc/pic32_sdhci.c   | 77 -
>  drivers/pinctrl/pinctrl_pic32.c | 28 
>  3 files changed, 77 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/mips/dts/pic32mzda_sk.dts b/arch/mips/dts/pic32mzda_sk.dts
> index b3c916a6db..fc86154e0a 100644
> --- a/arch/mips/dts/pic32mzda_sk.dts
> +++ b/arch/mips/dts/pic32mzda_sk.dts
> @@ -40,6 +40,7 @@
>  };
>  
>  &sdhci {
> + microchip,use-sdcd;
>   status = "okay";
>  };
>  
> diff --git a/drivers/mmc/pic32_sdhci.c b/drivers/mmc/pic32_sdhci.c
> index 029e0fbc2b..93f0532ad6 100644
> --- a/drivers/mmc/pic32_sdhci.c
> +++ b/drivers/mmc/pic32_sdhci.c
> @@ -9,62 +9,78 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> -static int pic32_sdhci_get_cd(struct sdhci_host *host)
> -{
> - /* PIC32 SDHCI CD errata:
> -  * - set CD_TEST and clear CD_TEST_INS bit
> -  */
> - sdhci_writeb(host, SDHCI_CTRL_CD_TEST, SDHCI_HOST_CONTROL);
> -
> - return 0;
> -}
> -
> -static const struct sdhci_ops pic32_sdhci_ops = {
> - .get_cd = pic32_sdhci_get_cd,
> +struct pic32_sdhci_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
>  };
>  
>  static int pic32_sdhci_probe(struct udevice *dev)
>  {
> + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct pic32_sdhci_plat *plat = dev_get_platdata(dev);
>   struct sdhci_host *host = dev_get_priv(dev);
> - const void *fdt = gd->fdt_blob;
> - u32 f_min_max[2];
> +
>   fdt_addr_t addr;
>   fdt_size_t size;
> + struct clk clk;
> + ulong clk_rate;
>   int ret;
>  
> - addr = fdtdec_get_addr_size(fdt, dev_of_offset(dev), "reg", &size);
> + addr = dev_read_addr_size(dev, "reg", &size);
>   if (addr == FDT_ADDR_T_NONE)
>   return -EINVAL;
>  
> + ret = clk_get_by_name(dev, "base_clk", &clk);
> + if (ret)
> + return ret;
> +
> + clk_rate = clk_get_rate(&clk);
> + clk_free(&clk);

There is no case about using clk? it doesn't need to free clk.

> +
> + if (IS_ERR_VALUE(clk_rate))
> + return clk_rate;
> +
>   host->ioaddr= ioremap(addr, size);
>   host->name  = dev->name;
>   host->quirks= SDHCI_QUIRK_NO_HISPD_BIT;
> - host->bus_width = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
> - "bus-width", 4);
> - host->ops = &pic32_sdhci_ops;
> -
> - ret = fdtdec_get_int_array(gd->fdt_blob, dev_of_offset(dev),
> -"clock-freq-min-max", f_min_max, 2);
> - if (ret) {
> - printf("sdhci: clock-freq-min-max not found\n");
> + host->bus_width = dev_read_u32_default(dev, "bus-width", 4);

if you can use mmc_of_parse(), then bus-width will be parsed.

> + host->max_clk   = clk_rate;
> +
> + host->mmc = &plat->mmc;
> + host->mmc->dev = dev;
> +
> + ret = sdhci_setup_cfg(&plat->cfg, host, 0, 0);
> + if (ret)
>   return ret;
> - }
>  
> - host->max_clk   = f_min_max[1];
> + host->mmc->priv = host;
> + upriv->mmc = host->mmc;
>  
> - ret = add_sdhci(host, 0, f_min_max[0]);
> + ret = sdhci_probe(dev);
>   if (ret)
>   return ret;
> - host->mmc->dev = dev;
> +
> + if (!dev_read_bool(dev, "microchip,use-sdcd")) {
> + // Use workaround 1 for erratum #15 by default

Explain workaround in more detail, plz.

> + u8 ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> + ctrl = (ctrl & ~SDHCI_CTRL_CD_TEST_INS) | SDHCI_CTRL_CD_TEST;
> + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> + }
>  
>   return 0;
>  }
>  
> +static int pic32_sdhci_bind(struct udevice *dev)
> +{
> + struct pic32_sdhci_plat *plat = dev_get_platdata(dev);
> +
> + return sdhci_bind(dev, &plat->mmc, &plat->cfg);
> +}
> +
>  static const struct udevice_id pic32_sdhci_ids[] = {
>   { .compatible = "microchip,pic32mzda-sdhci" },
>   { }
> @@ -74,6 +90,9 @@ U_BOOT_DRIVER(pic32_sdhci_drv)

Re: [v3, 06/11] mmc: add a mmc_hs400_prepare_ddr() interface

[Jaehoon Chung]

On 7/23/20 1:30 PM, Yangbo Lu wrote:
> Add a mmc_hs400_prepare_ddr() interface for controllers
> which needs preparation before switching to DDR mode for
> HS400 mode.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - None.
> Changes for v3:
>   - None.
> ---
>  drivers/mmc/mmc-uclass.c | 15 +++
>  drivers/mmc/mmc.c|  2 ++
>  include/mmc.h| 15 ++-
>  3 files changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index b9f0880..240b205 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -141,6 +141,21 @@ int mmc_set_enhanced_strobe(struct mmc *mmc)
>  }
>  #endif
>  
> +int dm_mmc_hs400_prepare_ddr(struct udevice *dev)
> +{
> + struct dm_mmc_ops *ops = mmc_get_ops(dev);
> +
> + if (ops->hs400_prepare_ddr)
> + return ops->hs400_prepare_ddr(dev);
> +
> + return 0;
> +}
> +
> +int mmc_hs400_prepare_ddr(struct mmc *mmc)
> +{
> + return dm_mmc_hs400_prepare_ddr(mmc->dev);
> +}
> +
>  int dm_mmc_host_power_cycle(struct udevice *dev)
>  {
>   struct dm_mmc_ops *ops = mmc_get_ops(dev);
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index f020a8e..935fa72 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1992,6 +1992,8 @@ static int mmc_select_hs400(struct mmc *mmc)
>   /* Set back to HS */
>   mmc_set_card_speed(mmc, MMC_HS, true);
>  
> + mmc_hs400_prepare_ddr(mmc);

not need to get the return value? you have defined  mmc_hs400_prepare_ddr() as 
int return type.

Best Regards,
Jaehoon Chung

> +
>   err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BUS_WIDTH,
>EXT_CSD_BUS_WIDTH_8 | EXT_CSD_DDR_FLAG);
>   if (err)
> diff --git a/include/mmc.h b/include/mmc.h
> index 2399cc2..659df75 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -513,6 +513,14 @@ struct dm_mmc_ops {
>* @return maximum number of blocks for this transfer
>*/
>   int (*get_b_max)(struct udevice *dev, void *dst, lbaint_t blkcnt);
> +
> + /**
> +  * hs400_prepare_ddr - prepare to switch to DDR mode
> +  *
> +  * @dev:Device to check
> +  * @return 0 if success, -ve on error
> +  */
> + int (*hs400_prepare_ddr)(struct udevice *dev);
>  };
>  
>  #define mmc_get_ops(dev)((struct dm_mmc_ops *)(dev)->driver->ops)
> @@ -540,7 +548,7 @@ int mmc_host_power_cycle(struct mmc *mmc);
>  int mmc_deferred_probe(struct mmc *mmc);
>  int mmc_reinit(struct mmc *mmc);
>  int mmc_get_b_max(struct mmc *mmc, void *dst, lbaint_t blkcnt);
> -
> +int mmc_hs400_prepare_ddr(struct mmc *mmc);
>  #else
>  struct mmc_ops {
>   int (*send_cmd)(struct mmc *mmc,
> @@ -552,6 +560,11 @@ struct mmc_ops {
>   int (*host_power_cycle)(struct mmc *mmc);
>   int (*get_b_max)(struct mmc *mmc, void *dst, lbaint_t blkcnt);
>  };
> +
> +static inline int mmc_hs400_prepare_ddr(struct mmc *mmc)
> +{
> + return 0;
> +}
>  #endif
>  
>  struct mmc_config {
> 

Re: [v3, 01/11] mmc: add a reinit() API

[Jaehoon Chung]

On 7/23/20 1:30 PM, Yangbo Lu wrote:
> For DM_MMC, the controller re-initialization is needed to
> clear old configuration for mmc rescan.
> 
> Signed-off-by: Yangbo Lu 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
> Changes for v2:
>   - None.
> Changes for v3:
>   - None.
> ---
>  drivers/mmc/mmc-uclass.c | 15 +++
>  drivers/mmc/mmc.c|  8 ++--
>  include/mmc.h| 10 ++
>  3 files changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index c5b7872..b9f0880 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -170,6 +170,21 @@ int mmc_deferred_probe(struct mmc *mmc)
>   return dm_mmc_deferred_probe(mmc->dev);
>  }
>  
> +int dm_mmc_reinit(struct udevice *dev)
> +{
> + struct dm_mmc_ops *ops = mmc_get_ops(dev);
> +
> + if (ops->reinit)
> + return ops->reinit(dev);
> +
> + return 0;
> +}
> +
> +int mmc_reinit(struct mmc *mmc)
> +{
> + return dm_mmc_reinit(mmc->dev);
> +}
> +
>  int mmc_of_parse(struct udevice *dev, struct mmc_config *cfg)
>  {
>   int val;
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index f36d11d..a4c6153 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2818,13 +2818,17 @@ int mmc_get_op_cond(struct mmc *mmc)
>   return err;
>  
>  #if CONFIG_IS_ENABLED(DM_MMC)
> - /* The device has already been probed ready for use */
> + /*
> +  * Re-initialization is needed to clear old configuration for
> +  * mmc rescan.
> +  */
> + err = mmc_reinit(mmc);
>  #else
>   /* made sure it's not NULL earlier */
>   err = mmc->cfg->ops->init(mmc);
> +#endif
>   if (err)
>   return err;
> -#endif
>   mmc->ddr_mode = 0;
>  
>  retry:
> diff --git a/include/mmc.h b/include/mmc.h
> index 8256219..161b8bc 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -422,6 +422,14 @@ struct dm_mmc_ops {
>*/
>   int (*deferred_probe)(struct udevice *dev);
>   /**
> +  * reinit() - Re-initialization to clear old configuration for
> +  * mmc rescan.
> +  *
> +  * @dev:Device to reinit
> +  * @return 0 if Ok, -ve if error
> +  */
> + int (*reinit)(struct udevice *dev);
> + /**
>* send_cmd() - Send a command to the MMC device
>*
>* @dev:Device to receive the command
> @@ -518,6 +526,7 @@ int dm_mmc_execute_tuning(struct udevice *dev, uint 
> opcode);
>  int dm_mmc_wait_dat0(struct udevice *dev, int state, int timeout_us);
>  int dm_mmc_host_power_cycle(struct udevice *dev);
>  int dm_mmc_deferred_probe(struct udevice *dev);
> +int dm_mmc_reinit(struct udevice *dev);
>  int dm_mmc_get_b_max(struct udevice *dev, void *dst, lbaint_t blkcnt);
>  
>  /* Transition functions for compatibility */
> @@ -529,6 +538,7 @@ int mmc_wait_dat0(struct mmc *mmc, int state, int 
> timeout_us);
>  int mmc_set_enhanced_strobe(struct mmc *mmc);
>  int mmc_host_power_cycle(struct mmc *mmc);
>  int mmc_deferred_probe(struct mmc *mmc);
> +int mmc_reinit(struct mmc *mmc);
>  int mmc_get_b_max(struct mmc *mmc, void *dst, lbaint_t blkcnt);
>  
>  #else
> 

Re: [v3, 05/11] mmc: add a hs400_tuning flag

[Jaehoon Chung]

On 7/23/20 1:30 PM, Yangbo Lu wrote:
> Some controllers may have difference between HS200 tuning
> and HS400 tuning, such as different registers setting,
> different procedure, or different errata.
> 
> This patch is to add a hs400_tuning flag to identify the
> tuning for HS400 mode.
> 
> Signed-off-by: Yangbo Lu 
> ---
> Changes for v2:
>   - None.
> Changes for v3:
>   - Explained more in commit messages.
> ---
>  drivers/mmc/mmc.c | 2 ++
>  include/mmc.h | 1 +
>  2 files changed, 3 insertions(+)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index a4c6153..f020a8e 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1981,7 +1981,9 @@ static int mmc_select_hs400(struct mmc *mmc)
>   mmc_set_clock(mmc, mmc->tran_speed, false);
>  
>   /* execute tuning if needed */
> + mmc->hs400_tuning = 1;
>   err = mmc_execute_tuning(mmc, MMC_CMD_SEND_TUNING_BLOCK_HS200);
> + mmc->hs400_tuning = 0;

It seems that it's fsl_esdhc specific flag. Is it need to set to 0?

Best Regards,
Jaehoon Chung

>   if (err) {
>   debug("tuning failed\n");
>   return err;
> diff --git a/include/mmc.h b/include/mmc.h
> index 161b8bc..2399cc2 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -707,6 +707,7 @@ struct mmc {
> * accessing the boot partitions
> */
>   u32 quirks;
> + u8 hs400_tuning;
>  };
>  
>  struct mmc_hwpart_conf {
> 

Re: [v3, 02/11] mmc: fsl_esdhc: add a reinit() callback

[Jaehoon Chung]

On 7/23/20 1:30 PM, Yangbo Lu wrote:
> Add a reinit() callback for mmc rescan.
> 
> Signed-off-by: Yangbo Lu 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
> Changes for v2:
>   - None.
> Changes for v3:
>   - None.
> ---
>  drivers/mmc/fsl_esdhc.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index f6e0d43..4fff7b5 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -946,6 +946,14 @@ static int fsl_esdhc_set_ios(struct udevice *dev)
>   return esdhc_set_ios_common(priv, &plat->mmc);
>  }
>  
> +static int fsl_esdhc_reinit(struct udevice *dev)
> +{
> + struct fsl_esdhc_plat *plat = dev_get_platdata(dev);
> + struct fsl_esdhc_priv *priv = dev_get_priv(dev);
> +
> + return esdhc_init_common(priv, &plat->mmc);
> +}
> +
>  static const struct dm_mmc_ops fsl_esdhc_ops = {
>   .get_cd = fsl_esdhc_get_cd,
>   .send_cmd   = fsl_esdhc_send_cmd,
> @@ -953,6 +961,7 @@ static const struct dm_mmc_ops fsl_esdhc_ops = {
>  #ifdef MMC_SUPPORTS_TUNING
>   .execute_tuning = fsl_esdhc_execute_tuning,
>  #endif
> + .reinit = fsl_esdhc_reinit,
>  };
>  
>  static const struct udevice_id fsl_esdhc_ids[] = {
> 

Re: Improvements to FIT ciphering

[Patrick Oppenlander]

On Tue, Aug 25, 2020 at 1:57 AM Philippe REYNES
 wrote:
>
> I agree that IV should be set in the FIT.
>
> So in the dts, we may have:
> cipher {
> algo = "aes256";
> key-name-hint = "aeskey";
> iv = "aesiv";
> };
> or (I propose) :
> cipher {
> algo = "aes256";
> key-name-hint = "aeskey";
> iv-name-hint = "aesiv";
> iv-in-fit;
> };
>
> I think that both solution should work ...
>
> Have you planned to implement this change/feature ?
> (otherwise I will try to found some time for it,
> it is a really nice improvement).

Hi Philippe,

here is what I had in mind, in the .its we would put:

cipher {
algo = "aes256";
key-name-hint = "aeskey";
};

when mkimage processes this it opens /dev/urandom to generate a unique
IV. It then uses this IV to perform the encryption and writes it IV to
the .fit image like so:

cipher {
algo = "aes256";
key-name-hint = "aeskey";
iv = <0xa16e090c 0x7e116bf8 0x75c44329 0x3278c74d>;
}

I don't think there is a need for a "iv-in-fit" property and
"iv-name-hint" can be deprecated.

> > However, if adding "hashed-nodes" and "hashed-strings" properties to
> > the image signature is acceptable we can still support signing
> > ciphered images with no problems.
>
> I think that everything should be added to the signature. I think it's
> simpler and more safe.
>
> Have you planned to implement this/propose a patch please ?
> (of course, if not, I will try to found some time)

Unfortunately right now it is crunch time at $DAYJOB to meet a
deadline by the end of September, so I don't have much (if any) time
to dedicate to working on U-Boot right now.

There are actually five issues on my list to address in U-Boot/mkimage:

* mkimage needs to generate encryption IV using /dev/urandom
* FIT image signatures need to include cipher node
* AES-GCM cipher support
* mkimage -B option doesn't zero padding bytes
* mkimage -B option unnecessarily pads the end of the image

I was planning on working through these when I get time, but I have
not started on any of them yet. So, if you have time (and energy),
please, go ahead :)

Best regards,

Patrick

Re: [PATCH] Fix data abort caused by mis-aligning fit data in

[Tom Rini]

On Mon, Aug 24, 2020 at 09:18:40PM +, Reuben Dowle wrote:

> I can see that arm64 requires 8 bytes. That is stated in section 2 of 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.rst.
> 
> I can't see a similar requirement for arm, although my search was not 
> exhaustive. More generally I can see that all device trees must be at least 4 
> byte aligned (from section II.2 of 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/booting-without-of.rst)
> 
> So it does seem that 8 bytes would work for at least both of these. I would 
> be happy with hard-coding that, as I doubt it would cause any problems with 
> other architectures.
> 
> I don’t have anything to add on the ability to relocate the device tree. In 
> my case the device tree is for the next stage u-boot, so won't need 
> relocating. This might become an issue if this was booting direct to linux 
> from the SPL perhaps.

For arm it's spelled out differently[1] as "64bit aligned address".  So
using 8 with a big annotated comment is probably best here.  And then
ah, yes, that's right, that's why we may end up in the case we're in.
Thanks!

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/booting.rst#n126

> 
> >
> 
> 
> [cid:4RFLogo(Custom)(2)_0f31a7de-6dd6-43cf-bc6a-a097a2b80b69.jpg]
> Reuben Dowle
> Software Architect
> 
> Phone:
> 
> Fax:
> E-Mail:
> Website:
> 
> 
> +64 4 499 6000
> 
> +64 4 473 4447
> reuben.do...@4rf.com
> Https://www.4rf.com
> 
> 
> 
> 
> [cid:Family_53c410b1-7227-4a5f-9acb-f09bd7617a39.png] 
> 
> 
> -Original Message-
> > From: Tom Rini 
> > Sent: Tuesday, 25 August 2020 8:40 am
> > To: Reuben Dowle 
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [PATCH] Fix data abort caused by mis-aligning fit data in
> >
> > On Mon, Aug 24, 2020 at 08:05:24PM +, Reuben Dowle wrote:
> >
> > > Should I submit a new patch with the alignment set to 8 bytes? I would
> > think a hard coded 8 bytes would not be the best solution, since not all
> > architectures will need that much alignment. I suspect some would work with
> > any alignment, and most 32-bit archs would be fine with 4-byte alignment.
> > >
> > > Our released software is actually using a patch to align to 4096 bytes, 
> > > but I
> > knew that was unnecessarily large. I was not really sure what would be an
> > appropriate value here, and took a guess at ARCH_DMA_MINALIGN when I
> > cleaned it up for submitting upstream. Is there a better define to use?
> > >
> > > I am also interested to know where the 8 byte alignment requirement is
> > documented.
> >
> > So we're talking about the device tree file, and only that, in this part
> > of the code, right?  In the Linux kernel documentation, both arm and
> > arm64 document that the device tree must be on an 8-byte aligned
> > address.  That is the bare minimum.  If we aren't further relocating it
> > (as fdt_high is set to 0x for example, which in general is wrong
> > and bad), that's still the best we can do.  It would be good to allow
> > for further relocation down the line as we aren't making sure it
> > wouldn't be overwritten by the kernel BSS, etc.
> >
> > --
> > Tom
> 
> The information in this email communication (inclusive of attachments) is 
> confidential to 4RF Limited and the intended recipient(s). If you are not the 
> intended recipient(s), please note that any use, disclosure, distribution or 
> copying of this information or any part thereof is strictly prohibited and 
> that the author accepts no liability for the consequences of any action taken 
> on the basis of the information provided. If you have received this email in 
> error, please notify the sender immediately by return email and then delete 
> all instances of this email from your system. 4RF Limited will not accept 
> responsibility for any consequences associated with the use of this email 
> (including, but not limited to, damages sustained as a result of any viruses 
> and/or any action or lack of action taken in reliance on it).




-- 
Tom


signature.asc
Description: PGP signature

RE: [PATCH] Fix data abort caused by mis-aligning fit data in

[Reuben Dowle]

I can see that arm64 requires 8 bytes. That is stated in section 2 of 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.rst.

I can't see a similar requirement for arm, although my search was not 
exhaustive. More generally I can see that all device trees must be at least 4 
byte aligned (from section II.2 of 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/booting-without-of.rst)

So it does seem that 8 bytes would work for at least both of these. I would be 
happy with hard-coding that, as I doubt it would cause any problems with other 
architectures.

I don't have anything to add on the ability to relocate the device tree. In my 
case the device tree is for the next stage u-boot, so won't need relocating. 
This might become an issue if this was booting direct to linux from the SPL 
perhaps.

> -Original Message-
> From: Tom Rini 
> Sent: Tuesday, 25 August 2020 8:40 am
> To: Reuben Dowle 
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH] Fix data abort caused by mis-aligning fit data in
> 
> On Mon, Aug 24, 2020 at 08:05:24PM +, Reuben Dowle wrote:
> 
> > Should I submit a new patch with the alignment set to 8 bytes? I would
> think a hard coded 8 bytes would not be the best solution, since not all
> architectures will need that much alignment. I suspect some would work with
> any alignment, and most 32-bit archs would be fine with 4-byte alignment.
> >
> > Our released software is actually using a patch to align to 4096 bytes, but 
> > I
> knew that was unnecessarily large. I was not really sure what would be an
> appropriate value here, and took a guess at ARCH_DMA_MINALIGN when I
> cleaned it up for submitting upstream. Is there a better define to use?
> >
> > I am also interested to know where the 8 byte alignment requirement is
> documented.
> 
> So we're talking about the device tree file, and only that, in this part
> of the code, right?  In the Linux kernel documentation, both arm and
> arm64 document that the device tree must be on an 8-byte aligned
> address.  That is the bare minimum.  If we aren't further relocating it
> (as fdt_high is set to 0x for example, which in general is wrong
> and bad), that's still the best we can do.  It would be good to allow
> for further relocation down the line as we aren't making sure it
> wouldn't be overwritten by the kernel BSS, etc.
> 
> --
> Tom

Re: [PATCH] Fix data abort caused by mis-aligning fit data in

[Tom Rini]

On Mon, Aug 24, 2020 at 08:05:24PM +, Reuben Dowle wrote:

> Should I submit a new patch with the alignment set to 8 bytes? I would think 
> a hard coded 8 bytes would not be the best solution, since not all 
> architectures will need that much alignment. I suspect some would work with 
> any alignment, and most 32-bit archs would be fine with 4-byte alignment.
> 
> Our released software is actually using a patch to align to 4096 bytes, but I 
> knew that was unnecessarily large. I was not really sure what would be an 
> appropriate value here, and took a guess at ARCH_DMA_MINALIGN when I cleaned 
> it up for submitting upstream. Is there a better define to use?
> 
> I am also interested to know where the 8 byte alignment requirement is 
> documented.

So we're talking about the device tree file, and only that, in this part
of the code, right?  In the Linux kernel documentation, both arm and
arm64 document that the device tree must be on an 8-byte aligned
address.  That is the bare minimum.  If we aren't further relocating it
(as fdt_high is set to 0x for example, which in general is wrong
and bad), that's still the best we can do.  It would be good to allow
for further relocation down the line as we aren't making sure it
wouldn't be overwritten by the kernel BSS, etc.

-- 
Tom


signature.asc
Description: PGP signature

RE: [PATCH] Fix data abort caused by mis-aligning fit data in

[Reuben Dowle]

Should I submit a new patch with the alignment set to 8 bytes? I would think a 
hard coded 8 bytes would not be the best solution, since not all architectures 
will need that much alignment. I suspect some would work with any alignment, 
and most 32-bit archs would be fine with 4-byte alignment.

Our released software is actually using a patch to align to 4096 bytes, but I 
knew that was unnecessarily large. I was not really sure what would be an 
appropriate value here, and took a guess at ARCH_DMA_MINALIGN when I cleaned it 
up for submitting upstream. Is there a better define to use?

I am also interested to know where the 8 byte alignment requirement is 
documented.

Reuben

> -Original Message-
> From: Tom Rini 
> Sent: Tuesday, 25 August 2020 2:27 am
> To: Reuben Dowle 
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH] Fix data abort caused by mis-aligning fit data in
> 
> On Fri, Jul 24, 2020 at 05:19:39AM +, Reuben Dowle wrote:
> 
> > Attempting to place device tree immediately after an image in memory
> > can lead to mis-aligned data accesses if that image size is not
> > divisible by the alignment requirements of the architecture.
> >
> > Data aborts caused by this were observed on a custom Marvel A388 based
> > system, where the image was a uboot FIT file. The total size varies
> > depending on the uboot device tree size, which does not always lead to
> correct alignment.
> >
> > Signed-off-by: Reuben Dowle 
> > ---
> >  common/spl/spl_fit.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c index
> > 365104f..d221075 100644
> > --- a/common/spl/spl_fit.c
> > +++ b/common/spl/spl_fit.c
> > @@ -349,9 +349,9 @@ static int spl_fit_append_fdt(struct
> > spl_image_info *spl_image,
> >
> > /*
> >  * Use the address following the image as target address for the
> > -* device tree.
> > +* device tree. Ensure that address is appropriately aligned.
> >  */
> > -   image_info.load_addr = spl_image->load_addr + spl_image->size;
> > +   image_info.load_addr = ALIGN(spl_image->load_addr + spl_image-
> >size,
> > +ARCH_DMA_MINALIGN);
> >
> > /* Figure out which device tree the board wants to use */
> > node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP,
> index++);
> 
> Sorry for the late reply here.  While we do need to ensure that the device
> tree is aligned, the documented alignment requirement for all platforms is 8
> byte, so we should document and use that here in case future platforms
> require a higher alignment.  Thanks!
> 
> --
> Tom

Pull request for UEFI sub-system for efi-2020-10-rc3 (3)

[Heinrich Schuchardt]

Dear Tom,

The following changes since commit d584648dad691caec3eccdbfa3f1936878e5:

  Merge tag 'dm-pull-22aug20' of
https://gitlab.denx.de/u-boot/custodians/u-boot-dm (2020-08-23 16:06:38
-0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2020-10-rc3-3

for you to fetch changes up to 2b3fbcb59f4174e455a6285eaddf1426ed3e76c5:

  efi_loader: use ':' as separator for setenv -i (2020-08-24 16:37:53 +0200)

No problems were reported by Gitlab CI and Travis CI:

https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/4485
https://travis-ci.org/github/xypron2/u-boot/builds/720671388


Pull request for UEFI sub-system for efi-2020-10-rc3 (3)

The following bug fixes are contained in this pull-request:

* ResetSystem() should no hang if not implemented.
* Device paths in Boot variables should be verified.
* Use ':' as separator for command setenv -e -i instead of ','.
* Correct comments for functions.
* Update UEFI documentation.


Heinrich Schuchardt (11):
  efi_loader: document parameters of do_bootefi_exec()
  efi_loader: remove empty comment line
  doc: update UEFI documentation
  efi_loader: ResetSystem() should not hang
  efi_selftest: add a test for ResetSystem()
  efi_selftest: substitute ResetSystem() by do_reset()
  include: kernel.h: define SSIZE_MAX
  efi_loader: efi_dp_check_length()
  test: unit test for efi_dp_check_length()
  efi_loader: validate device path length in boot manager
  efi_loader: use ':' as separator for setenv -i

 cmd/bootefi.c  |  4 ++
 cmd/nvedit_efi.c   |  2 +-
 doc/uefi/uefi.rst  | 18 ---
 include/efi_loader.h   |  2 +
 include/efi_variable.h |  1 -
 include/linux/kernel.h |  3 ++
 lib/efi_loader/efi_bootmgr.c   |  6 +--
 lib/efi_loader/efi_device_path.c   | 33 
 lib/efi_loader/efi_runtime.c   |  7 +--
 lib/efi_selftest/Makefile  |  1 +
 lib/efi_selftest/efi_selftest.c| 10 +++-
 lib/efi_selftest/efi_selftest_reset.c  | 58
+
 test/lib/Makefile  |  1 +
 test/lib/efi_device_path.c | 50 ++
 test/py/tests/test_efi_secboot/test_authvar.py | 60
+++---
 test/py/tests/test_efi_secboot/test_signed.py  | 46 -
 .../py/tests/test_efi_secboot/test_signed_intca.py | 24 -
 test/py/tests/test_efi_secboot/test_unsigned.py| 18 +++
 18 files changed, 252 insertions(+), 92 deletions(-)
 create mode 100644 lib/efi_selftest/efi_selftest_reset.c
 create mode 100644 test/lib/efi_device_path.c

Re: [GIT] Pull request: u-boot-clk (24.08.2020)

[Tom Rini]

On Mon, Aug 24, 2020 at 02:26:41PM +0200, Lukasz Majewski wrote:

> Dear Tom,
> 
> Please find a PR for u-boot-clk branch:
> https://gitlab.denx.de/u-boot/custodians/u-boot-clk/-/commits/master
> 
> The tag with PR description:
> https://gitlab.denx.de/u-boot/custodians/u-boot-clk/-/tags/u-boot-clk-24Aug2020
> 
> CI:
> https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=2&view=results

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 2/2] am335x_evm: Allow booting from usb-storage device

[Matwey V. Kornilov]

Signed-off-by: Matwey V. Kornilov 
---
 include/configs/am335x_evm.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 9c4ef369c5..103c046137 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -66,6 +66,12 @@
 #define BOOTENV_DEV_NAME_NAND(devtypeu, devtypel, instance) \
#devtypel #instance " "
 
+#if CONFIG_IS_ENABLED(CMD_USB)
+# define BOOT_TARGET_USB(func) func(USB, usb, 0)
+#else
+# define BOOT_TARGET_USB(func)
+#endif
+
 #if CONFIG_IS_ENABLED(CMD_PXE)
 # define BOOT_TARGET_PXE(func) func(PXE, pxe, na)
 #else
@@ -84,6 +90,7 @@
func(MMC, mmc, 1) \
func(LEGACY_MMC, legacy_mmc, 1) \
func(NAND, nand, 0) \
+   BOOT_TARGET_USB(func) \
BOOT_TARGET_PXE(func) \
BOOT_TARGET_DHCP(func)
 
-- 
2.26.2

[PATCH 1/2] ti: Use devtype=mmc instead of setenv devtype mmc

[Matwey V. Kornilov]

If devtype variable is setted via setenv, then the following devtype=X style is
ignored. Currently, many u-boot commands use devtype variable in the latter
manner:

mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run 
scan_dev_for_boot_part; fi

Use devtype=mmc instead of setenv devtype mmc to avoid bugs with booting from
another devtype.

Signed-off-by: Matwey V. Kornilov 
---
 include/environment/ti/mmc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/environment/ti/mmc.h b/include/environment/ti/mmc.h
index 1c8e49a8b3..b86c8dc7a4 100644
--- a/include/environment/ti/mmc.h
+++ b/include/environment/ti/mmc.h
@@ -57,7 +57,7 @@
"fi;\0" \
"mmcboot=mmc dev ${mmcdev}; " \
"devnum=${mmcdev}; " \
-   "setenv devtype mmc; " \
+   "devtype=mmc; " \
"if mmc rescan; then " \
"echo SD/MMC found on device ${mmcdev};" \
"if run loadimage; then " \
-- 
2.26.2

[PATCH] image: don't exceed gd->ram_top in bootm_size

[Baruch Siach]

When board_get_usable_ram_top() limits gd->ram_top, env_get_bootm_size()
must not exceed that limit. Otherwise, boot_relocate_fdt() might put fdt
out of the allowed RAM range.

The similar commit 8ce1f10cf2b1 ("ARM: bootm: take into account
gd->ram_top") exposed this bug.

This fixes boot on Armada 8040 based Clearfog GT-8K where ram_top is set
to 0x8000 (2GB), but bi_dram[0].size might be up to 0xc000
(3GB). Note the relocated fdt address (0xbfff4000) in the console output
listed below:

Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
62 bytes read in 21 ms (2 KiB/s)
1:  linux
Retrieving file: /extlinux/Image
13740544 bytes read in 1266 ms (10.4 MiB/s)
Retrieving file: /extlinux/armada-8040-clearfog-gt-8k.dtb
33368 bytes read in 31 ms (1 MiB/s)
   Booting using the fdt blob at 0x4f0
   Loading Device Tree to bfff4000, end b257 ... 
"Synchronous Abort" handler, esr 0x9645
elr: 0006e1cc lr : 00068fd8 (reloc)
elr: 7ffa91cc lr : 7ffa3fd8
x0 :  x1 : bfffc258
x2 :  x3 : 7da7
x4 : 04f08258 x5 : bfff4000
x6 : bfff4000 x7 : 000f
x8 : 7fb23bf8 x9 : 0008
x10: b257 x11: b257
x12:  x13: f000
x14: bfff4000 x15: 0021
x16: 7ff7bc38 x17: 
x18: 7fb2add0 x19: bfff4000
x20: 04f0 x21: b258
x22: 5882 x23: 0010
x24: 7ffe3c40 x25: 7fb23cb8
x26: c000 x27: 
x28: 7fc3fd50 x29: 7fb23bd0

Code: 5461 aa0603e0 d65f03c0 38606882 (38206822)
Resetting CPU ...

Thanks to Patrice CHOTARD who directed me to the right way.

Signed-off-by: Baruch Siach 
---
 common/image.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/common/image.c b/common/image.c
index 9d7d5c17d122..da8bccd400dd 100644
--- a/common/image.c
+++ b/common/image.c
@@ -694,6 +694,9 @@ phys_size_t env_get_bootm_size(void)
size = gd->bd->bi_memsize;
 #endif
 
+   if (start + size > gd->ram_top)
+   size = gd->ram_top - start;
+
s = env_get("bootm_low");
if (s)
tmp = (phys_size_t)simple_strtoull(s, NULL, 16);
-- 
2.28.0

Re: [PATCH v1 1/1] board: ns3: check bnxt chimp handshake status

[Rayagonda Kokatanur]

Hi Simon,

On Sat, Aug 22, 2020 at 8:39 PM Simon Glass  wrote:
>
> Hi Rayagonda,
>
> On Thu, 20 Aug 2020 at 11:42, Rayagonda Kokatanur
>  wrote:
> >
> > Chimp is a core in Broadcom netxtream controller (bnxt).
> > Add support to check bnxt's chimp component status.
> >
> > Signed-off-by: Rayagonda Kokatanur 
> > ---
> >  board/broadcom/bcmns3/ns3.c | 13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/board/broadcom/bcmns3/ns3.c b/board/broadcom/bcmns3/ns3.c
> > index 0357cd0e32..8540c99286 100644
> > --- a/board/broadcom/bcmns3/ns3.c
> > +++ b/board/broadcom/bcmns3/ns3.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  /* Default reset-level = 3 and strap-val = 0 */
> >  #define L3_RESET   30
> > @@ -210,8 +211,20 @@ void reset_cpu(ulong level)
> >  #ifdef CONFIG_OF_BOARD_SETUP
> >  int ft_board_setup(void *fdt, struct bd_info *bd)
> >  {
> > +   u32 chimp_hs = CHIMP_HANDSHAKE_WAIT_TIMEOUT;
> > +
> > gic_lpi_tables_init();
> >
> > +   /*
> > +* Check for chimp handshake status.
> > +* Zero timeout value will actually fall to default timeout.
> > +*/
> > +   chimp_handshake_status_optee(0, &chimp_hs);
> > +   if (chimp_hs == CHIMP_HANDSHAKE_SUCCESS)
> > +   printf("ChiMP handshake successful\n");
> > +   else
> > +   printf("ERROR: ChiMP handshake status 0x%x\n", chimp_hs);
>
> Where is this error handled? Don't you need to return the error from
> this function?

System boot is independent of chimp hand shake.
Chimp/bnxt handshake failure is not a catastrophic error.
We just want to warn the user that the chimp handshake has failed.

Best regards,
Rayagonda
>
> > +
> > return mem_info_parse_fixup(fdt);
> >  }
> >  #endif /* CONFIG_OF_BOARD_SETUP */
> > --
> > 2.17.1
> >
>
> Regards,
> Simon

Re: Improvements to FIT ciphering

[Philippe REYNES]

Hi Patrick,

>> 
>> Hi Patrick,
>> 
>> Sorry for this late anwser, I was very busy this week.
> 
> No problem!

Again, sorry I was off and then busy.

> Before I address your comments below, is there anything else I need to
> do with the previous patches I posted? I haven't contributed to U-Boot
> before and I'm not entirely sure of the correct process. Do I need to
> resubmit the patches with your reviewed-by tags included?

You have followed the correct process.
Your patches (and proposal) are fine.

>> > Hi Simon & Philippe,
>> > 
>> > I've been thinking about this some more and have added a few points
>> > below. I will need feedback before proposing any patches for the
>> > remaining issues.
>> > 
>> > On Fri, Jul 24, 2020 at 12:06 PM Patrick Oppenlander
>> >  wrote:
>> >> 
>> >> Issue #1
>> >> 
>> >> 
>> >> Currently, mkimage treats the IV in the same manner as the encryption
>> >> key. There is an iv-name-hint property which mkimage uses to read the
>> >> IV from a file in the keys directory. This can then be written to
>> >> u-boot.dtb along with the encryption key.
>> >> 
>> >> The problem with that is that u-boot.dtb is baked in at production
>> >> time and is generally not field upgradable. That means that the IV is
>> >> also baked in which is considered bad practice especially when using
>> >> CBC mode (see CBC IV attack). In general it is my understanding that
>> >> you should never use a key+IV twice regardless of cipher or mode.
>> >> 
>> >> In my opinion a better solution would have been to write the IV into
>> >> the FIT image instead of iv-name-hint (it's only 16 bytes!), and
>> >> regenerate it (/dev/random?) each and every time the data is ciphered.
>> >> 
>> > 
>> > If U-Boot needs to continue supporting AES-CBC I think the only option
>> > here is to deprecate the "iv-name-hint" property and replace it with
>> > an "iv" property. This should be possible in a backward-compatible
>> > manner.
>> 
>> I prefer to keep the support of aes-cbc, and I like the idea of storing
>> the IV in the FIT image.
>> 
>> But I don't really understand the issue with iv-name-hint. To stay
>> compatible, for example, we could simply add a propert "iv-store-in-fit"
>> in the device tree.
> 
> The IV must change each and every time the encryption is run. I am not
> sure how this can be achieved using "iv-name-hint" and storing the IV
> in the U-Boot FDT. Maybe I have missed something?
> 
> In the simplest case encrypting the same plaintext twice must not
> result in the same ciphertext as this leaks important information to
> an attacker (the plaintext payload is the same!). There are many
> examples of attacks against encryption where the IV is kept constant.
> 
> This is why I suggested replacing "iv-name-hint" with "iv". U-Boot can
> then search for "iv" first and (optionally?) fall back to
> "iv-name-hint" if "Iv" is not found. This should be a simple change.

I agree that IV should be set in the FIT.

So in the dts, we may have:
cipher {
algo = "aes256";
key-name-hint = "aeskey";
iv = "aesiv";
};
or (I propose) :
cipher {
algo = "aes256";
key-name-hint = "aeskey";
iv-name-hint = "aesiv";
iv-in-fit;
};

I think that both solution should work ...

Have you planned to implement this change/feature ?
(otherwise I will try to found some time for it,
it is a really nice improvement).

>> >> 
>> >> An even better solution is to use AES-GCM (or something similar) as
>> >> this includes the IV with the ciphertext, simplifying the above, and
>> >> also provides authentication addressing another issue (see below).
>> >> 
>> > 
>> > In my opinion it would be better to deprecate AES-CBC and replace it
>> > with AES-GCM. I can see no advantages to supporting both, and can see
>> > no reason to use AES-CBC over AES-GCM apart from a minor performance
>> > advantage.
>> 
>> I also think that AES-GCM is a really good idea.
>> 
>> But I prefer to keep aes-cbc support. And to go further, I think we may
>> support several algo (for example AES-CTR). The algo choice may change
>> depending on the project. The boot speed may be very important (or not).
> 
> That makes sense. There is also a code size advantage which may matter
> in some circumstances.
> 
> Perhaps we should add a "mode" property: "cbc", "ctr", "gcm", etc.
> 
>> >> Issue #2
>> >> ===
>> >> 
>> >> The current implementation uses encrypt-then-sign. I like this
>> >> approach as it means that the FIT image can be verified outside of
>> >> U-Boot without requiring encryption keys. It is also considered best
>> >> practise.
>> >> 
>> >> However, for this to be secure, the details of the cipher need to be
>> >> included in the signature, otherwise an attacker can change the cipher
>> >> or key/iv properties.
>> >> 
>> >> I do not believe that properties in the cipher node are currently
>> >> included when signin

Re: [PATCH] cmd: irq: disable CMD_IRQ for riscv arch

[Heinrich Schuchardt]

On 24.08.20 17:08, Pragnesh Patel wrote:
> For RISC-V arch, no need for CMD_IRQ so disable the same.
>
> Signed-off-by: Pragnesh Patel 

This avoids possible misconfiguration leading to

riscv64-linux-gnu-ld.bfd:
cmd/built-in.o:(.u_boot_list_2_cmd_2_irqinfo+0x18):
undefined reference to `do_irqinfo'
make: *** [Makefile:1753: u-boot] Error 1

Reviewed-by: Heinrich Schuchardt 

> ---
>  cmd/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 9ad511aa17..9709666261 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -2217,7 +2217,7 @@ config CMD_DIAG
>
>  config CMD_IRQ
>   bool "irq - Show information about interrupts"
> - depends on !ARM && !MIPS && !SH
> + depends on !ARM && !MIPS && !RISCV && !SH
>   help
> This enables two commands:
>
>

[PATCH] cmd: irq: disable CMD_IRQ for riscv arch

[Pragnesh Patel]

For RISC-V arch, no need for CMD_IRQ so disable the same.

Signed-off-by: Pragnesh Patel 
---
 cmd/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 9ad511aa17..9709666261 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2217,7 +2217,7 @@ config CMD_DIAG
 
 config CMD_IRQ
bool "irq - Show information about interrupts"
-   depends on !ARM && !MIPS && !SH
+   depends on !ARM && !MIPS && !RISCV && !SH
help
  This enables two commands:
 
-- 
2.17.1

[PATCH 3/3] riscv: Mark andes_plmt_get_count() with 'notrace'

[Pragnesh Patel]

For M-mode U-boot, andes_plmt_get_count() will provide timer counter.
Mark it as 'notrace' so that it doesn't cause infinite recursion.

Signed-off-by: Pragnesh Patel 
---
 arch/riscv/lib/andes_plmt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/lib/andes_plmt.c b/arch/riscv/lib/andes_plmt.c
index b0245d0b52..488a98406b 100644
--- a/arch/riscv/lib/andes_plmt.c
+++ b/arch/riscv/lib/andes_plmt.c
@@ -17,7 +17,7 @@
 /* mtime register */
 #define MTIME_REG(base)((ulong)(base))
 
-static int andes_plmt_get_count(struct udevice *dev, u64 *count)
+static int notrace andes_plmt_get_count(struct udevice *dev, u64 *count)
 {
*count = readq((void __iomem *)MTIME_REG(dev->priv));
 
-- 
2.17.1

[PATCH 0/3] RISC-V tracing support

[Pragnesh Patel]

This series add a support of tracing for RISC-V arch.

This series is also available here [1] for testing.
Series depends on [2].

[1] https://github.com/pragnesh26992/u-boot/tree/trace
[2] 
https://patchwork.ozlabs.org/project/uboot/cover/20200729095636.1077054-1-sean...@gmail.com/

How to test this patch:
1) Enable tracing in "configs/sifive_fu540_defconfig"
CONFIG_TRACE=y
CONFIG_TRACE_BUFFER_SIZE=0x0100
CONFIG_TRACE_CALL_DEPTH_LIMIT=15
CONFIG_CMD_TRACE=y

2) make FTRACE=1 sifive_fu540_defconfig
3) make FTRACE=1

Following are the boot messages on FU540 five cores SMP platform:

U-Boot 2020.10-rc1-02837-g8613dc2e66 (Aug 24 2020 - 20:03:47 +0530)

CPU:   rv64imac
Model: SiFive HiFive Unleashed A00
DRAM:  8 GiB
trace: enabled
MMC:   spi@1005:mmc@0: 0
Loading Environment from SPIFlash... SF: Detected is25wp256 with page size 256 
Bytes, erase size 4 KiB, total 32 MiB
OK
In:serial@1001
Out:   serial@1001
Err:   serial@1001
Board serial number should not be 0 !!
Net:
Warning: ethernet@1009 (eth0) using random MAC address - 92:a1:a7:02:5a:14
eth0: ethernet@1009
Hit any key to stop autoboot:  0
=> trace stats
177,722 function sites
 37,057,350 function calls
  1 untracked function calls
  1,279,612 traced function calls (36015585 dropped due to overflow)
 19 maximum observed call depth
 15 call depth limit
 37,055,565 calls not traced due to depth
=>


Pragnesh Patel (3):
  riscv: Add timer_get_us() for tracing
  riscv: Mark riscv_timer_get_count() and sifive_clint_get_count() with
'notrace'
  riscv: Mark andes_plmt_get_count() with 'notrace'

 arch/riscv/lib/Makefile   |  1 +
 arch/riscv/lib/andes_plmt.c   |  2 +-
 arch/riscv/lib/sifive_clint.c |  2 +-
 arch/riscv/lib/timer.c| 50 +++
 drivers/timer/riscv_timer.c   |  2 +-
 5 files changed, 54 insertions(+), 3 deletions(-)
 create mode 100644 arch/riscv/lib/timer.c

-- 
2.17.1

[PATCH 2/3] riscv: Mark riscv_timer_get_count() and sifive_clint_get_count() with 'notrace'

[Pragnesh Patel]

Mark them as 'notrace' so that it doesn't cause infinite recursion.

Signed-off-by: Pragnesh Patel 
---
 arch/riscv/lib/sifive_clint.c | 2 +-
 drivers/timer/riscv_timer.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/lib/sifive_clint.c b/arch/riscv/lib/sifive_clint.c
index 3345a17ad2..1cf74a6cf4 100644
--- a/arch/riscv/lib/sifive_clint.c
+++ b/arch/riscv/lib/sifive_clint.c
@@ -62,7 +62,7 @@ int riscv_get_ipi(int hart, int *pending)
return 0;
 }
 
-static int sifive_clint_get_count(struct udevice *dev, u64 *count)
+static int notrace sifive_clint_get_count(struct udevice *dev, u64 *count)
 {
*count = readq((void __iomem *)MTIME_REG(dev->priv));
 
diff --git a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c
index 449fcfcfd5..342e0354dc 100644
--- a/drivers/timer/riscv_timer.c
+++ b/drivers/timer/riscv_timer.c
@@ -16,7 +16,7 @@
 #include 
 #include 
 
-static int riscv_timer_get_count(struct udevice *dev, u64 *count)
+static int notrace riscv_timer_get_count(struct udevice *dev, u64 *count)
 {
if (IS_ENABLED(CONFIG_64BIT)) {
*count = csr_read(CSR_TIME);
-- 
2.17.1

[PATCH 1/3] riscv: Add timer_get_us() for tracing

[Pragnesh Patel]

timer_get_us() will use timer_ops->get_count() function for timer counter.
For S-mode U-Boot, CSR_TIMEH and CSR_TIME will provide a timer counter and
For M-mode U-Boot, mtime register will provide the same.

Signed-off-by: Pragnesh Patel 
---
 arch/riscv/lib/Makefile |  1 +
 arch/riscv/lib/timer.c  | 50 +
 2 files changed, 51 insertions(+)
 create mode 100644 arch/riscv/lib/timer.c

diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 10ac5b06d3..fbb68e583b 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -26,6 +26,7 @@ obj-y   += setjmp.o
 obj-$(CONFIG_$(SPL_)SMP) += smp.o
 obj-$(CONFIG_SPL_BUILD)+= spl.o
 obj-y   += fdt_fixup.o
+obj-$(CONFIG_TIMER) += timer.o
 
 # For building EFI apps
 CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
diff --git a/arch/riscv/lib/timer.c b/arch/riscv/lib/timer.c
new file mode 100644
index 00..3e423f2805
--- /dev/null
+++ b/arch/riscv/lib/timer.c
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 SiFive, Inc
+ *
+ * Authors:
+ *   Pragnesh Patel 
+ */
+
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static struct udevice *timer;
+
+ulong notrace timer_get_us(void)
+{
+   u64 count;
+   ulong rate;
+   int ret;
+
+   /**
+* gd->timer will become NULL in initr_dm(), so assign gd->timer
+* to other static global timer, so that timer_get_us() can use it.
+*/
+   if (!timer && gd->timer)
+   timer = (struct udevice *)gd->timer;
+
+   if (timer) {
+   ret = timer_get_count(timer, &count);
+   if (ret)
+   return ret;
+
+   rate = timer_get_rate(timer);
+   }
+
+   return (ulong)count / rate;
+}
+
+int timer_init(void)
+{
+   int ret;
+
+   ret = dm_timer_init();
+   if (ret)
+   return ret;
+
+   return 0;
+}
-- 
2.17.1

Re: [PATCH] Fix data abort caused by mis-aligning fit data in

[Tom Rini]

On Fri, Jul 24, 2020 at 05:19:39AM +, Reuben Dowle wrote:

> Attempting to place device tree immediately after an image in memory can lead
> to mis-aligned data accesses if that image size is not divisible by the
> alignment requirements of the architecture.
> 
> Data aborts caused by this were observed on a custom Marvel A388 based system,
> where the image was a uboot FIT file. The total size varies depending on the
> uboot device tree size, which does not always lead to correct alignment.
> 
> Signed-off-by: Reuben Dowle 
> ---
>  common/spl/spl_fit.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index 365104f..d221075 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -349,9 +349,9 @@ static int spl_fit_append_fdt(struct spl_image_info 
> *spl_image,
>  
>   /*
>* Use the address following the image as target address for the
> -  * device tree.
> +  * device tree. Ensure that address is appropriately aligned.
>*/
> - image_info.load_addr = spl_image->load_addr + spl_image->size;
> + image_info.load_addr = ALIGN(spl_image->load_addr + spl_image->size, 
> ARCH_DMA_MINALIGN);
>  
>   /* Figure out which device tree the board wants to use */
>   node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, index++);

Sorry for the late reply here.  While we do need to ensure that the
device tree is aligned, the documented alignment requirement for all
platforms is 8 byte, so we should document and use that here in case
future platforms require a higher alignment.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 4/5] arm: mvebu: Espressobin: Define console env

[Pali Rohár]

Some distribution bootscripts append console env into boot cmdline.
So define console env correctly to have early console access.

Signed-off-by: Pali Rohár 
---
 include/configs/mvebu_armada-37xx.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/mvebu_armada-37xx.h 
b/include/configs/mvebu_armada-37xx.h
index 6feceda757..b473072976 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -17,6 +17,7 @@
 
 #define CONFIG_SYS_BAUDRATE_TABLE  { 9600, 19200, 38400, 57600, \
  115200, 230400, 460800, 921600 }
+#define CONFIG_DEFAULT_CONSOLE "console=ttyMV0,115200 
earlycon=ar3700_uart,0xd0012000"
 
 /*
  * For booting Linux, the board info and command line data
@@ -99,6 +100,7 @@
"kernel_addr=0x700\0"   \
"kernel_addr_r=0x700\0" \
"ramdisk_addr_r=0x800\0"\
+   "console=" CONFIG_DEFAULT_CONSOLE "\0" \
BOOTENV
 
 #endif /* _CONFIG_MVEBU_ARMADA_37XX_H */
-- 
2.20.1

[PATCH 5/5] arm: mvebu: Espressobin: Update README.marvell file

[Pali Rohár]

Include information about permanent ethernet MAC address and add link how
to build ATF as U-Boot on Espressobin cannot be flashed without ATF.

Signed-off-by: Pali Rohár 
---
 doc/README.marvell | 40 +---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/doc/README.marvell b/doc/README.marvell
index 336461745c..da16316407 100644
--- a/doc/README.marvell
+++ b/doc/README.marvell
@@ -13,7 +13,8 @@ Build Procedure
 
 2. Set the cross compiler:
 
-   # export 
CROSS_COMPILE=/path/to/toolchain/aarch64-marvell-linux-gnu-
+   # sudo apt-get install gcc-aarch64-linux-gnu
+   # export CROSS_COMPILE=aarch64-linux-gnu-
 
 3. Clean-up old residuals:
 
@@ -30,7 +31,7 @@ Build Procedure
 
 5. Configure the device-tree and build the U-Boot image:
 
-   Compile u-boot and set the required device-tree using:
+   For the Armada-70x0/80x0 DB board compile u-boot and set the required 
device-tree using:
 
# make DEVICE_TREE=
 
@@ -42,12 +43,45 @@ Build Procedure
 In order to prevent this, the required device-tree MUST be set during 
compilation.
 All device-tree files are located in ./arch/arm/dts/ folder.
 
+   For other DB boards (MacchiatoBin, EsspressoBin and 3700 DB board) 
compile u-boot with
+   just default device-tree from defconfig using:
+
+   # make
+
NOTE:
The u-boot.bin should not be used as a stand-alone image.
The ARM Trusted Firmware (ATF) build process uses this image to 
generate the
-   flash image.
+   flash image. See TF-A Build Instructions for Marvell Platforms for more 
details at:
+   
https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html
 
 Configuration update
 -
To update the U-Boot configuration, please refer to doc/README.kconfig
 
+
+Permanent ethernet MAC address
+---
+   Prior flashing new U-Boot version (as part of ATF image) it is 
suggested to backup
+   permanent ethernet MAC address as it is stored only in U-Boot env 
storage (SPI or eMMC).
+   Some boards like EspressoBin have MAC address printed on sticker. To 
print current MAC
+   address run:
+
+   # echo $ethaddr
+
+   MAC addresses 00:51:82:11:22:00, 00:51:82:11:22:01, 00:51:82:11:22:02, 
00:51:82:11:22:03
+   and F0:AD:4E:03:64:7F are default hardcoded values found in Marvell's 
and Armbian U-Boot
+   forks and therefore *not* unique. Usage of static hardcoded MAC 
addresses should be avoided.
+   When original address is lost (e.g. erased by Armbian boot scripts for 
EspressoBin) it is
+   suggested to generate new random one.
+
+   After flashing new U-Boot version it is suggested to reset U-Boot env 
variables to default
+   and then set correct permanent ethernet MAC address.
+
+   # env default -a
+   # setenv ethaddr XX:XX:XX:XX:XX:XX
+   # saveenv
+
+   Where XX:XX:XX:XX:XX:XX is permanent ethernet MAC address.
+
+   Recent Linux kernel versions use correct permanent ethernet MAC address 
from U-Boot env as
+   U-Boot will inject it into kernel's device-tree.
-- 
2.20.1

[PATCH 2/5] arm: mvebu: Espressobin: Change default loadaddr

[Pali Rohár]

Current loadaddr is not writable on Espressobin and 'loadb' command cause
rebooting board. Marvell's U-Boot already set default loadaddr to value
0x0600 [1] and after this change 'loadb' is working fine.

[1] - 
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7

Signed-off-by: Pali Rohár 
---
 include/configs/mvebu_armada-37xx.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/mvebu_armada-37xx.h 
b/include/configs/mvebu_armada-37xx.h
index ac0998a2d4..c6b0e2573a 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -37,7 +37,7 @@
 /*
  * Other required minimal configurations
  */
-#define CONFIG_SYS_LOAD_ADDR   0x0080  /* default load adr- 8M */
+#define CONFIG_SYS_LOAD_ADDR   0x0600  /* default load adr */
 #define CONFIG_SYS_RESET_ADDRESS 0x/* Rst Vector Adr */
 #define CONFIG_SYS_MAXARGS 32  /* max number of command args */
 
-- 
2.20.1

[PATCH 3/5] arm: mvebu: Espressobin: Define fdt_addr and kernel_addr env aliases

[Pali Rohár]

Boot scripts for existing Espressobin Linux distributions, like OpenWRT,
expect that U-Boot set fdt_addr and kernel_addr envs. So add env aliases
from fdt_addr_r and kernel_addr_r values.

Signed-off-by: Pali Rohár 
---
 include/configs/mvebu_armada-37xx.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/configs/mvebu_armada-37xx.h 
b/include/configs/mvebu_armada-37xx.h
index c6b0e2573a..6feceda757 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -90,10 +90,13 @@
 
 #include 
 
+/* fdt_addr and kernel_addr are needed for existing distribution boot scripts 
*/
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"scriptaddr=0x6d0\0"\
"pxefile_addr_r=0x6e0\0"\
+   "fdt_addr=0x6f0\0"  \
"fdt_addr_r=0x6f0\0"\
+   "kernel_addr=0x700\0"   \
"kernel_addr_r=0x700\0" \
"ramdisk_addr_r=0x800\0"\
BOOTENV
-- 
2.20.1

[PATCH 1/5] arm: mvebu: Espressobin: Move env load addresses

[Pali Rohár]

According to Marvell's U-Boot description [1] current env load addresses
overlaps with ATF RT services region and TEE. Because the ATF RT service
and TEE region is going to be marked as secure and can't be overwritten,
use different different addresses for envs.

[1] - 
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/0a5b159806baa0746b6449920e450498bc269ba7

Signed-off-by: Pali Rohár 
---
 include/configs/mvebu_armada-37xx.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/configs/mvebu_armada-37xx.h 
b/include/configs/mvebu_armada-37xx.h
index ca662b0ce7..ac0998a2d4 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -91,10 +91,10 @@
 #include 
 
 #define CONFIG_EXTRA_ENV_SETTINGS  \
-   "scriptaddr=0x4d0\0"\
-   "pxefile_addr_r=0x4e0\0"\
-   "fdt_addr_r=0x4f0\0"\
-   "kernel_addr_r=0x500\0" \
+   "scriptaddr=0x6d0\0"\
+   "pxefile_addr_r=0x6e0\0"\
+   "fdt_addr_r=0x6f0\0"\
+   "kernel_addr_r=0x700\0" \
"ramdisk_addr_r=0x800\0"\
BOOTENV
 
-- 
2.20.1

Re: [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR

[Michal Simek]

Hi Simon,

On 22. 08. 20 17:08, Simon Glass wrote:
> Hi Michal,
> 
> On Mon, 17 Aug 2020 at 00:49, Michal Simek  wrote:
>>
>> Hi Simon,
>>
>> On 16. 08. 20 5:39, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On Fri, 14 Aug 2020 at 07:28, Michal Simek  wrote:

 Hi Simon,

 ne 19. 7. 2020 v 22:06 odesílatel Simon Glass  napsal:
>
> This option is used to run arch-specific shell scripts which produce .its
> files which are used to produce FIT images. We already have binman which
> is designed to produce firmware images. It is more powerful and has tests.
>
> So this option should be deprecated and not used. Existing uses should be
> migrated.
>
> Mentions of this in code reviews over the last year or so do not seem to
> have resulted in action, and things are getting worse.
>
> So let's add a warning.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> (no changes since v1)
>
>  Makefile | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index f1b5be1882..d73c10a973 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
> @echo >&2 "See doc/driver-model/migration.rst for more info."
> @echo >&2 ""
>  endif
> +endif
> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
> +   @echo >&2 "= WARNING =="
> +   @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please 
> migrate"
> +   @echo >&2 "to binman instead, to avoid the proliferation of"
> +   @echo >&2 "arch-specific scripts with no tests."
> +   @echo >&2 ""
>  endif
> @# Check that this build does not use CONFIG options that we do 
> not
> @# know about unless they are in Kconfig. All the existing CONFIG
> @@ -1345,6 +1352,8 @@ endif
>
>  # Boards with more complex image requirements can provide an .its source 
> file
>  # or a generator script
> +# NOTE: Please do not use this. We are migrating away from Makefile 
> rules to use
> +# binman instead.
>  ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
>  U_BOOT_ITS := u-boot.its
>  $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
> --
> 2.28.0.rc0.105.gf9edc3c819-goog
>

 I just got to this conversion and I am curious how that transition
 should look like.
 I found how FIT image is created which is fine but I didn't find any
 reference on how to generate images based on CONFIG_OF_LIST.
 If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
 that I loop over this entry and create multiple DT nodes and the same
 amount of configurations to cover it. Is this supported by binman?
 If yes, what's the syntax for it?
>>>
>>> The easiest way is probably to create a new entry type, like zynq-fit.
>>> Then you can generate the DT using the sequence writer functions. See
>>> _ReadSubNodes() in fit.py for an example.
>>>
>>> You can perhaps have a template subnode and use that in a for loop to
>>> generate the nodes.
>>>

 I tried several configurations and we can use that for generating qspi
 images and also images with different configurations to have them
 ready
 but first I need to be able to handle the case above.
>>>
>>> I was thinking of converting sunxi which has the same need, but it
>>> sounds like you are on the case. Let me know if you need help.
>>
>> Nope. I just saw that message and started to play with it to find out
>> what needs to be done and how this fits to bigger picture. If this
>> doesn't work directly then the work needs to be planned which will take
>> time especially when this utility is new for us and we could have issues
>> with writing code in python. Would be good if you can do the first shot
>> because you know this utility and I am more than happy to test it, try
>> and adopt if needed for our case.
>>
>> Sunxi is very similar case as is zynqmp. Difference is they hardcode
>> default configuration to config_1. ZynqMP is setting up default based on
>> default DT configured at that time.
>>
>> In connection to binman I see that there would be a need to generate
>> images with ATF and without ATF in configuration node and with different
>> default configuration. There could be also a need to add additional
>> loadable entry such as bitstreams.
>>
>> Back to zynq-fit new entry type. I don't think it should be zynq/zynqmp
>> type because as was state in commit message u-boot.itb generation is
>> very similar for all these boards that's why name for this new entry
>> should be generic.
>>
> 
> I sent an initial series to add this to binman. I've since found a few
> problems so will send a v2 at some point. You can try it out at
> u

Re: [PATCH] mips: dts: Fix PIC32MZDA GPIO register definitions and dtc warnings

[Daniel Schwierzeck]

Am Samstag, den 22.08.2020, 16:36 + schrieb John Robertson:
> Currently GPIO operations (e.g. gpio status -a) don't work at all.
> 
> Signed-off-by: John Robertson 
> ---
> 
>  arch/mips/dts/pic32mzda.dtsi | 58 +---
>  1 file changed, 34 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
> index 4c8b7a9a0b..71864d3fff 100644
> --- a/arch/mips/dts/pic32mzda.dtsi
> +++ b/arch/mips/dts/pic32mzda.dtsi
> @@ -26,8 +26,13 @@
>   };
>  
>   cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
>   cpu@0 {
>   compatible = "mips,mips14kc"; 
> + device-type = "cpu";
> + reg = <0>;
>   };
>   };
>  
> @@ -40,6 +45,7 @@
>   uart1: serial@1f822000 {
>   compatible = "microchip,pic32mzda-uart";
>   reg = <0x1f822000 0x50>;
> + interrupt-parent = <&evic>;

I guess that fixes the DTC warnings. Can you split this into a separate
commit?

>   interrupts = <112 IRQ_TYPE_LEVEL_HIGH>;
>   status = "disabled";
>   clocks = <&clock PB2CLK>;
> @@ -48,6 +54,7 @@
>   uart2: serial@1f822200 {
>   compatible = "microchip,pic32mzda-uart";
>   reg = <0x1f822200 0x50>;
> + interrupt-parent = <&evic>;
>   interrupts = <145 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = <&clock PB2CLK>;
>   status = "disabled";
> @@ -56,6 +63,7 @@
>   uart6: serial@1f822a00 {
>   compatible = "microchip,pic32mzda-uart";
>   reg = <0x1f822a00 0x50>;
> + interrupt-parent = <&evic>;
>   interrupts = <188 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = <&clock PB2CLK>;
>   status = "disabled";
> @@ -69,6 +77,8 @@
>   };
>  
>   pinctrl: pinctrl@1f801400 {
> + #address-cells = <1>;
> + #size-cells = <1>;
>   compatible = "microchip,pic32mzda-pinctrl";
>   reg = <0x1f801400 0x100>, /* in  */
> <0x1f801500 0x200>, /* out */
> @@ -76,75 +86,72 @@
>   reg-names = "ppsin","ppsout","port";
>   status = "disabled";
>  
> - ranges = <0 0x1f86 0xa00>;
> - #address-cells = <1>;
> - #size-cells = <1>;
> - gpioA: gpio0@0 {
> + gpioA: gpio0@1f86 {
>   compatible = "microchip,pic32mzda-gpio";
> - reg = <0x000 0x48>;
> + reg = <0x1f86 0xe0>;

I guess that's rather a regression or change in DM address translation
or maybe the GPIO driver misses some updates for DM core API. Changing
the device-tree is the wrong approach.

>   gpio-controller;
>   #gpio-cells = <2>;
>   };
>  
> - gpioB: gpio1@100 {
> + gpioB: gpio1@1f860100 {
>   compatible = "microchip,pic32mzda-gpio";
> - reg = <0x100 0x48>;
> + reg = <0x1f860100 0xe0>;
>   gpio-controller;
>   #gpio-cells = <2>;
>   };
>  
> - gpioC: gpio2@200 {
> + gpioC: gpio2@1f860200 {
>   compatible = "microchip,pic32mzda-gpio";
> - reg = <0x200 0x48>;
> + reg = <0x1f860200 0xe0>;
>   gpio-controller;
>   #gpio-cells = <2>;
>   };
>  
> - gpioD: gpio3@300 {
> + gpioD: gpio3@1f860300 {
>   compatible = "microchip,pic32mzda-gpio";
> - reg = <0x300 0x48>;
> + reg = <0x1f860300 0xe0>;
>   gpio-controller;
>   #gpio-cells = <2>;
>   };
>  
> - gpioE: gpio4@400 {
> + gpioE: gpio4@1f860400 {
>   compatible = "microchip,pic32mzda-gpio";
> - reg = <0x400 0x48>;
> + reg = <0x1f860400 0xe0>;
>   gpio-controller;
>   #gpio-cells = <2>;
>   };
>  
> - gpioF: gpio5@500 {
> + gpioF: gpio5@1f860500 {
>   compatible = "microchip,pic32mzda-gpio";
> - reg = <0x500 0x48>;
> + reg = <0x1f860500 0xe0>;
>   gpio-controller;
>   #gpio-cells = <2>;
>   };
>  
> - gpioG: gpio6@600 {
> + gpioG: gpio6@1f860600 {
>   compatible = "microchip,pic32mzda-gpio";
> - reg = <0x600 0x48>;
> + reg = <0x1f860600 0xe0>;
>   gpio-controller;
>   #gpio-cells = <2>;
>   };
>  
> -   

RE: [PATCH] riscv: Add do_irqinfo() for CONFIG_CMD_IRQ

[Pragnesh Patel]

Hi Heinrich,

>-Original Message-
>From: Heinrich Schuchardt 
>Sent: 24 August 2020 19:01
>To: Pragnesh Patel ; u-boot@lists.denx.de;
>atish.pa...@wdc.com; bmeng...@gmail.com; anup.pa...@wdc.com; Sagar
>Kadam ; r...@andestech.com
>Cc: Paul Walmsley ( Sifive) ; Simon Glass
>; Sean Anderson ; Bin Meng
>
>Subject: Re: [PATCH] riscv: Add do_irqinfo() for CONFIG_CMD_IRQ
>
>[External Email] Do not click links or attachments unless you recognize the
>sender and know the content is safe
>
>On 24.08.20 13:00, Pragnesh Patel wrote:
>> Right now, do_irqinfo() done nothing and return 0 for
>
>Nits:
>
>%s/done/does/
>
>> CONFIG_CMD_IRQ
>>
>> Signed-off-by: Pragnesh Patel 
>> ---
>>  arch/riscv/lib/interrupts.c | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
>> index cd47e64487..d6273606b5 100644
>> --- a/arch/riscv/lib/interrupts.c
>> +++ b/arch/riscv/lib/interrupts.c
>> @@ -145,3 +145,10 @@ __attribute__((weak)) void
>> external_interrupt(struct pt_regs *regs)
>>  __attribute__((weak)) void timer_interrupt(struct pt_regs *regs)  {
>> }
>> +
>> +#if defined(CONFIG_CMD_IRQ)
>> +int do_irqinfo(struct cmd_tbl *cmdtp, int flag, int argc, char *const
>> +argv[]) {
>> + return 0;
>> +}
>> +#endif
>
>Why do we allow CONFIG_CMD_IRQ for RISC-V if the command is not
>supported?
>
>How about:
>
>cmd/Kconfig:2224
>
> config CMD_IRQ
>bool "irq - Show information about interrupts"
>-   depends on !ARM && !MIPS && !SH
>+   depends on !ARM && !MIPS && !RISCV && !SH

Agreed, will send a new patch.

>
>Best regards
>
>Heinrich
>
>>

Re: [PATCH] riscv: Add do_irqinfo() for CONFIG_CMD_IRQ

[Heinrich Schuchardt]

On 24.08.20 13:00, Pragnesh Patel wrote:
> Right now, do_irqinfo() done nothing and return 0 for

Nits:

%s/done/does/

> CONFIG_CMD_IRQ
>
> Signed-off-by: Pragnesh Patel 
> ---
>  arch/riscv/lib/interrupts.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
> index cd47e64487..d6273606b5 100644
> --- a/arch/riscv/lib/interrupts.c
> +++ b/arch/riscv/lib/interrupts.c
> @@ -145,3 +145,10 @@ __attribute__((weak)) void external_interrupt(struct 
> pt_regs *regs)
>  __attribute__((weak)) void timer_interrupt(struct pt_regs *regs)
>  {
>  }
> +
> +#if defined(CONFIG_CMD_IRQ)
> +int do_irqinfo(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
> +{
> + return 0;
> +}
> +#endif

Why do we allow CONFIG_CMD_IRQ for RISC-V if the command is not supported?

How about:

cmd/Kconfig:2224

 config CMD_IRQ
    bool "irq - Show information about interrupts"
-   depends on !ARM && !MIPS && !SH
+   depends on !ARM && !MIPS && !RISCV && !SH

Best regards

Heinrich

>

Re: [PATCH v1 06/24] pci: pci-uclass: Add multi entry support for memory regions

[Tom Rini]

On Mon, Aug 24, 2020 at 09:36:13AM +0200, Stefan Roese wrote:
> Hi Tom,
> 
> On 23.08.20 16:03, Tom Rini wrote:
> > On Sun, Aug 23, 2020 at 11:41:41AM +0200, Stefan Roese wrote:
> > > Hi Simon,
> > > Hi Tom,
> > > 
> > > On 22.08.20 17:09, Simon Glass wrote:
> > > > Hi Stefan,
> > > > 
> > > > On Fri, 14 Aug 2020 at 05:40, Stefan Roese  wrote:
> > > > > 
> > > > > Hi Simon,
> > > > > 
> > > > > On 04.08.20 17:05, Simon Glass wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > > > > > > > Changes in v1:
> > > > > > > > > > > - Change patch subject
> > > > > > > > > > > - Enhance Kconfig help descrition
> > > > > > > > > > > - Use if() instead of #if
> > > > > > > > > > > 
> > > > > > > > > > >   drivers/pci/Kconfig  | 10 ++
> > > > > > > > > > >   drivers/pci/pci-uclass.c |  9 ++---
> > > > > > > > > > >   2 files changed, 16 insertions(+), 3 deletions(-)
> > > > > > > > > > 
> > > > > > > > > > This needs an update to a sandbox test to handle this 
> > > > > > > > > > behaviour.
> > > > > > > > > 
> > > > > > > > > Okay. But how should I handle all these defconfig changes 
> > > > > > > > > with regard
> > > > > > > > > to the other patches in this series, introducing multiple new 
> > > > > > > > > PCI
> > > > > > > > > related Kconfig options. With 3 new Kconfig options, all 
> > > > > > > > > permutations
> > > > > > > > > would lead to 8 (2 ^ 3) different defconfig files. This does 
> > > > > > > > > not
> > > > > > > > > scale.
> > > > > > > > > 
> > > > > > > > > I might be missing something here though - perhaps this is 
> > > > > > > > > easier to
> > > > > > > > > achieve.
> > > > > > > > 
> > > > > > > > For sandbox, turn on all options and then add a new PCI bus 
> > > > > > > > that uses
> > > > > > > > this functionality. If there are lots of combinations you could 
> > > > > > > > add 8
> > > > > > > > new buses, but I'm hoping that isn't necessary?
> > > > > > > 
> > > > > > > If I turn on all new options, sandbox will run with these new 
> > > > > > > options
> > > > > > > enabled. I don't know with with implications, as it usually runs 
> > > > > > > with
> > > > > > > the "normal" PCI related Kconfig options. Also the "normal" PCI
> > > > > > > defconfig (e.g. CONFIG_PCI_REGION_MULTI_ENTRY etc disabled) will 
> > > > > > > not
> > > > > > > be tested any more via the sandbox tests. So you get either a 
> > > > > > > test for
> > > > > > > the new Kconfig option enabled or disabled this way.
> > > > > > > 
> > > > > > > Do you really want me to do this?
> > > > > > 
> > > > > > So the Kconfig completely changes the implementation of PCI? That
> > > > > > doesn't make it very testable, as you say.
> > > > > > 
> > > > > > Instead, I think the Kconfig should enable the option, then use one 
> > > > > > of
> > > > > > three ways to select the option:
> > > > > > 
> > > > > > - a device tree property (on sandbox particularly)
> > > > > > - compatible string (where the property is not appropriate
> > > > > > - setting a flag in PCI bus (where a driver requires the option be 
> > > > > > selected)
> > > > > > 
> > > > > > That way you can write a test for the new feature in sandbox, 
> > > > > > without
> > > > > > deleting all the other tests.
> > > > > 
> > > > > Coming back to this issue after some time - sorry for the delay.
> > > > > 
> > > > > I'm not sure, if I understand this correctly. Do you suggest that the
> > > > > driver code (in this case pci-uclass.c) should be extended to support
> > > > > this (sandbox) testing support?
> > > > 
> > > > Not really. I see these things as features that drivers can enable /
> > > > disable depending on their needs. If that is correct, then sandbox is
> > > > no different form other drivers, except that perhaps it might support
> > > > all combinations rather than just one.
> > > > 
> > > > > 
> > > > > If yes, I really think that this is counterproductive. As we added (at
> > > > > least some of) the Kconfig options explicitly, to not add code to
> > > > > pci-uclass.c in the "normal case". So adding code to e.g. check a 
> > > > > device
> > > > > tree property or a compatible string would increase the code size 
> > > > > again.
> > > > 
> > > > How about some flags in struct pci_controller?
> > > > 
> > > > > 
> > > > > If not, I'm still unsure how you would like to test the "normal case",
> > > > > e.g. with CONFIG_PCI_REGION_MULTI_ENTRY disabled, and with it enabled
> > > > > without adding more sandbox build targets, with all the Kconfig 
> > > > > options
> > > > > permutations. As the extra code (in pci-uclass) is either included or
> > > > > not in the sandbox binary.
> > > > 
> > > > Kconfig enables and disables the feature by adding the code. But we
> > > > can still have a flag to determine whether it is used by a particular
> > > > driver. That way we can keep our test coverage.
> > > > 
> > > > > 
> > > > > But after adding one test for the first of these pci-uclass related
> > > > > patches, I do have a gen

Re: Please pull u-boot-dm

[Tom Rini]

On Sat, Aug 22, 2020 at 05:21:07PM -0600, Simon Glass wrote:

> Hi Tom,
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/4466
> 
> 
> The following changes since commit 2e6132d835631946b7a67dedd8f5bc902304b0f9:
> 
>   Merge tag 'xilinx-for-v2020.10-rc3' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze (2020-08-20
> 14:46:43 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-dm.git tags/dm-pull-22aug20
> 
> for you to fetch changes up to a4020350289c520e896fd6180e510be557ed3bf9:
> 
>   sandbox: u-boot.lds: Remove bogus __bss_start symbol (2020-08-22 08:54:51
> -0600)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] xilinx: kconfig: Change Kconfig dependencies for Xilinx drivers

[Michal Simek]

Zynq/ZynqMP/Versal IPs should be possible to called also from Microblaze in
PL and vice versa. That's why change dependencies and do not limit enabling
just for some platforms.

This is follow up patch based on commit 664e16ce99a0 ("xilinx: kconfig:
Change Kconfig dependencies for Xilinx drivers").

Signed-off-by: Michal Simek 
---

 drivers/serial/Kconfig   | 4 ++--
 drivers/spi/Kconfig  | 3 ---
 drivers/usb/host/Kconfig | 3 +--
 3 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index e344677f91f6..b4805a2e4ea4 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -734,7 +734,7 @@ config UNIPHIER_SERIAL
 
 config XILINX_UARTLITE
bool "Xilinx Uarlite support"
-   depends on DM_SERIAL && (MICROBLAZE || ARCH_ZYNQ || ARCH_ZYNQMP || 4xx)
+   depends on DM_SERIAL
help
  If you have a Xilinx based board and want to use the uartlite
  serial ports, say Y to this option. If unsure, say N.
@@ -802,7 +802,7 @@ config STM32_SERIAL
 
 config ZYNQ_SERIAL
bool "Cadence (Xilinx Zynq) UART support"
-   depends on DM_SERIAL && (MICROBLAZE || ARCH_ZYNQ || ARCH_ZYNQMP || 
ARCH_ZYNQMP_R5)
+   depends on DM_SERIAL
help
  This driver supports the Cadence UART. It is found e.g. in Xilinx
  Zynq/ZynqMP.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 3fc2d0674ae4..5df97c80fa51 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -407,7 +407,6 @@ config XILINX_SPI
 
 config ZYNQ_SPI
bool "Zynq SPI driver"
-   depends on ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL
help
  Enable the Zynq SPI driver. This driver can be used to
  access the SPI NOR flash on platforms embedding this Zynq
@@ -415,7 +414,6 @@ config ZYNQ_SPI
 
 config ZYNQ_QSPI
bool "Zynq QSPI driver"
-   depends on ARCH_ZYNQ
imply SPI_FLASH_BAR
help
  Enable the Zynq Quad-SPI (QSPI) driver. This driver can be
@@ -425,7 +423,6 @@ config ZYNQ_QSPI
 
 config ZYNQMP_GQSPI
bool "Configure ZynqMP Generic QSPI"
-   depends on ARCH_ZYNQMP || ARCH_VERSAL
help
  This option is used to enable ZynqMP QSPI controller driver which
  is used to communicate with qspi flash devices.
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 1c374a7bd809..4eb7b34e245f 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -200,8 +200,7 @@ config USB_EHCI_TEGRA
 
 config USB_EHCI_ZYNQ
bool "Support for Xilinx Zynq on-chip EHCI USB controller"
-   depends on ARCH_ZYNQ
-   default y
+   default y if ARCH_ZYNQ
---help---
  Enable support for Zynq on-chip EHCI USB controller
 
-- 
2.28.0

[GIT] Pull request: u-boot-clk (24.08.2020)

[Lukasz Majewski]

Dear Tom,

Please find a PR for u-boot-clk branch:
https://gitlab.denx.de/u-boot/custodians/u-boot-clk/-/commits/master

The tag with PR description:
https://gitlab.denx.de/u-boot/custodians/u-boot-clk/-/tags/u-boot-clk-24Aug2020

CI:
https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=2&view=results

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpnzCwgx8xJ4.pgp
Description: OpenPGP digital signature

[PATCH] xilinx: drivers: Use '_' instead of '-' in driver name

[Michal Simek]

The most of drivers are using '_' instead of '-' in driver name. That's why
sync up these names to be aligned. It looks quite bad to see both in use.
It is visible via dm tree command.

Signed-off-by: Michal Simek 
---

Simon: Not sure what's the standard here but I have done some greps and it
looks like that most of drivers are using _ instead of -.
---
 drivers/clk/clk_zynqmp.c   | 2 +-
 drivers/firmware/firmware-zynqmp.c | 2 +-
 drivers/i2c/i2c-cdns.c | 2 +-
 drivers/mailbox/zynqmp-ipi.c   | 2 +-
 drivers/mtd/nand/raw/arasan_nfc.c  | 2 +-
 drivers/mtd/nand/raw/zynq_nand.c   | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/clk_zynqmp.c b/drivers/clk/clk_zynqmp.c
index 2313ac0bc044..779511975662 100644
--- a/drivers/clk/clk_zynqmp.c
+++ b/drivers/clk/clk_zynqmp.c
@@ -710,7 +710,7 @@ static const struct udevice_id zynqmp_clk_ids[] = {
 };
 
 U_BOOT_DRIVER(zynqmp_clk) = {
-   .name = "zynqmp-clk",
+   .name = "zynqmp_clk",
.id = UCLASS_CLK,
.of_match = zynqmp_clk_ids,
.probe = zynqmp_clk_probe,
diff --git a/drivers/firmware/firmware-zynqmp.c 
b/drivers/firmware/firmware-zynqmp.c
index 903a8f587820..7583f24a200d 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -202,6 +202,6 @@ static const struct udevice_id zynqmp_firmware_ids[] = {
 
 U_BOOT_DRIVER(zynqmp_firmware) = {
.id = UCLASS_FIRMWARE,
-   .name = "zynqmp-firmware",
+   .name = "zynqmp_firmware",
.of_match = zynqmp_firmware_ids,
 };
diff --git a/drivers/i2c/i2c-cdns.c b/drivers/i2c/i2c-cdns.c
index 024c63c4eaed..7144d39984ec 100644
--- a/drivers/i2c/i2c-cdns.c
+++ b/drivers/i2c/i2c-cdns.c
@@ -500,7 +500,7 @@ static const struct udevice_id cdns_i2c_of_match[] = {
 };
 
 U_BOOT_DRIVER(cdns_i2c) = {
-   .name = "i2c-cdns",
+   .name = "i2c_cdns",
.id = UCLASS_I2C,
.of_match = cdns_i2c_of_match,
.ofdata_to_platdata = cdns_i2c_ofdata_to_platdata,
diff --git a/drivers/mailbox/zynqmp-ipi.c b/drivers/mailbox/zynqmp-ipi.c
index 746377e557cb..9483ed9cefcf 100644
--- a/drivers/mailbox/zynqmp-ipi.c
+++ b/drivers/mailbox/zynqmp-ipi.c
@@ -133,7 +133,7 @@ struct mbox_ops zynqmp_ipi_mbox_ops = {
 };
 
 U_BOOT_DRIVER(zynqmp_ipi) = {
-   .name = "zynqmp-ipi",
+   .name = "zynqmp_ipi",
.id = UCLASS_MAILBOX,
.of_match = zynqmp_ipi_ids,
.probe = zynqmp_ipi_probe,
diff --git a/drivers/mtd/nand/raw/arasan_nfc.c 
b/drivers/mtd/nand/raw/arasan_nfc.c
index 6c1d64054c64..0615e5037809 100644
--- a/drivers/mtd/nand/raw/arasan_nfc.c
+++ b/drivers/mtd/nand/raw/arasan_nfc.c
@@ -1306,7 +1306,7 @@ static const struct udevice_id arasan_nand_dt_ids[] = {
 };
 
 U_BOOT_DRIVER(arasan_nand) = {
-   .name = "arasan-nand",
+   .name = "arasan_nand",
.id = UCLASS_MTD,
.of_match = arasan_nand_dt_ids,
.probe = arasan_probe,
diff --git a/drivers/mtd/nand/raw/zynq_nand.c b/drivers/mtd/nand/raw/zynq_nand.c
index fa594552109d..92db2aa19c86 100644
--- a/drivers/mtd/nand/raw/zynq_nand.c
+++ b/drivers/mtd/nand/raw/zynq_nand.c
@@ -1282,7 +1282,7 @@ static const struct udevice_id zynq_nand_dt_ids[] = {
 };
 
 U_BOOT_DRIVER(zynq_nand) = {
-   .name = "zynq-nand",
+   .name = "zynq_nand",
.id = UCLASS_MTD,
.of_match = zynq_nand_dt_ids,
.probe = zynq_nand_probe,
-- 
2.28.0

Re: [PATCH] mmc: pic32: PIC32MZDA SDHCI controller non-functional

[Daniel Schwierzeck]

Am Samstag, den 22.08.2020, 02:37 + schrieb John Robertson:
> Refresh driver code, remove obsolete DT props and set the max clock
> rate from the source clock 'base_clk'.
> 
> Card detect is also broken. The fix implemented for erratum #15
> documented in Microchip ref. DS8736D only needs to be done as
> in the current code (set CDSSEL, clear CDTLVL in SDHCCON1 to force
> 'detect') if the SDCD pin is not connected. If it is connected,
> card detect works fine. A vendor specific flag 'microchip,use-sdcd'
> has been added to enable real card detect functionality.
> 
> The card detect signal CDSLVL provided in the status register is
> inverted as described in erratum #16, but this does not apply to
> U-Boot because it uses the card inserted CARDINS flag. Therefore,
> 'cd-inverted' is not required.
> 
> Signed-off-by: John Robertson 

could you split this into smaller patches? You are fixing multiple
issues at once which is hard to review and which breaks bisectability.

> ---
> 
>  arch/mips/dts/pic32mzda_sk.dts  |  1 +
>  drivers/mmc/pic32_sdhci.c   | 77 -
>  drivers/pinctrl/pinctrl_pic32.c | 28 
>  3 files changed, 77 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/mips/dts/pic32mzda_sk.dts b/arch/mips/dts/pic32mzda_sk.dts
> index b3c916a6db..fc86154e0a 100644
> --- a/arch/mips/dts/pic32mzda_sk.dts
> +++ b/arch/mips/dts/pic32mzda_sk.dts
> @@ -40,6 +40,7 @@
>  };
>  
>  &sdhci {
> + microchip,use-sdcd;
>   status = "okay";
>  };
>  
> diff --git a/drivers/mmc/pic32_sdhci.c b/drivers/mmc/pic32_sdhci.c
> index 029e0fbc2b..93f0532ad6 100644
> --- a/drivers/mmc/pic32_sdhci.c
> +++ b/drivers/mmc/pic32_sdhci.c
> @@ -9,62 +9,78 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> -static int pic32_sdhci_get_cd(struct sdhci_host *host)
> -{
> - /* PIC32 SDHCI CD errata:
> -  * - set CD_TEST and clear CD_TEST_INS bit
> -  */
> - sdhci_writeb(host, SDHCI_CTRL_CD_TEST, SDHCI_HOST_CONTROL);
> -
> - return 0;
> -}
> -
> -static const struct sdhci_ops pic32_sdhci_ops = {
> - .get_cd = pic32_sdhci_get_cd,
> +struct pic32_sdhci_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
>  };
>  
>  static int pic32_sdhci_probe(struct udevice *dev)
>  {
> + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct pic32_sdhci_plat *plat = dev_get_platdata(dev);
>   struct sdhci_host *host = dev_get_priv(dev);
> - const void *fdt = gd->fdt_blob;
> - u32 f_min_max[2];
> +
>   fdt_addr_t addr;
>   fdt_size_t size;
> + struct clk clk;
> + ulong clk_rate;
>   int ret;
>  
> - addr = fdtdec_get_addr_size(fdt, dev_of_offset(dev), "reg", &size);
> + addr = dev_read_addr_size(dev, "reg", &size);
>   if (addr == FDT_ADDR_T_NONE)
>   return -EINVAL;
>  
> + ret = clk_get_by_name(dev, "base_clk", &clk);
> + if (ret)
> + return ret;
> +
> + clk_rate = clk_get_rate(&clk);
> + clk_free(&clk);
> +
> + if (IS_ERR_VALUE(clk_rate))
> + return clk_rate;
> +
>   host->ioaddr= ioremap(addr, size);
>   host->name  = dev->name;
>   host->quirks= SDHCI_QUIRK_NO_HISPD_BIT;
> - host->bus_width = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
> - "bus-width", 4);
> - host->ops = &pic32_sdhci_ops;
> -
> - ret = fdtdec_get_int_array(gd->fdt_blob, dev_of_offset(dev),
> -"clock-freq-min-max", f_min_max, 2);
> - if (ret) {
> - printf("sdhci: clock-freq-min-max not found\n");
> + host->bus_width = dev_read_u32_default(dev, "bus-width", 4);
> + host->max_clk   = clk_rate;
> +
> + host->mmc = &plat->mmc;
> + host->mmc->dev = dev;
> +
> + ret = sdhci_setup_cfg(&plat->cfg, host, 0, 0);
> + if (ret)
>   return ret;
> - }
>  
> - host->max_clk   = f_min_max[1];
> + host->mmc->priv = host;
> + upriv->mmc = host->mmc;
>  
> - ret = add_sdhci(host, 0, f_min_max[0]);
> + ret = sdhci_probe(dev);
>   if (ret)
>   return ret;
> - host->mmc->dev = dev;
> +
> + if (!dev_read_bool(dev, "microchip,use-sdcd")) {
> + // Use workaround 1 for erratum #15 by default
> + u8 ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> + ctrl = (ctrl & ~SDHCI_CTRL_CD_TEST_INS) | SDHCI_CTRL_CD_TEST;
> + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> + }
>  
>   return 0;
>  }
>  
> +static int pic32_sdhci_bind(struct udevice *dev)
> +{
> + struct pic32_sdhci_plat *plat = dev_get_platdata(dev);
> +
> + return sdhci_bind(dev, &plat->mmc, &plat->cfg);
> +}
> +
>  static const struct udevice_id pic32_sdhci_ids[] = {
>   { .compatible = "microchip,pic32mzda-sdhci" },
>   { }
> @@ -74,6 +90,9 @@ U_BOOT_DRIVER(pic32_sdhci_drv) = {
>   .name 

[PATCH] net: gem: Add support for more PHYs on MDIO bus

[Michal Simek]

Find out MDIO bus and enable MDIO access to it if this is done via
different GEM controller. Only works across GEM instances.

Signed-off-by: Michal Simek 
---

 drivers/net/zynq_gem.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index da4b6fba9ff6..8afec8bbfcff 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -758,6 +758,9 @@ static int zynq_gem_ofdata_to_platdata(struct udevice *dev)
 
if (!dev_read_phandle_with_args(dev, "phy-handle", NULL, 0, 0,
&phandle_args)) {
+   fdt_addr_t addr;
+   ofnode parent;
+
debug("phy-handle does exist %s\n", dev->name);
priv->phyaddr = ofnode_read_u32_default(phandle_args.node,
"reg", -1);
@@ -765,6 +768,13 @@ static int zynq_gem_ofdata_to_platdata(struct udevice *dev)
priv->max_speed = ofnode_read_u32_default(phandle_args.node,
  "max-speed",
  SPEED_1000);
+
+   parent = ofnode_get_parent(phandle_args.node);
+   addr = ofnode_get_addr(parent);
+   if (addr != FDT_ADDR_T_NONE) {
+   debug("MDIO bus not found %s\n", dev->name);
+   priv->mdiobase = (struct zynq_gem_regs *)addr;
+   }
}
 
phy_mode = dev_read_prop(dev, "phy-mode", NULL);
-- 
2.28.0

[PATCH] env: kconfig: Add default option for ARCH_ZYNQ

[Michal Simek]

Zynq is similar to ZynqMP u-boot feature wise that's why also enable
default option for ENV_FAT_DEVICE_AND_PART Kconfig entry.

Signed-off-by: Michal Simek 
---

 env/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/env/Kconfig b/env/Kconfig
index b59ba310ec3d..f3a9925f58f4 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -422,7 +422,7 @@ config ENV_FAT_DEVICE_AND_PART
string "Device and partition for where to store the environemt in FAT"
depends on ENV_IS_IN_FAT
default "0:1" if TI_COMMON_CMD_OPTIONS
-   default "0:auto" if ARCH_ZYNQMP
+   default "0:auto" if ARCH_ZYNQ || ARCH_ZYNQMP
default "0:auto" if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA = -1
default "1:auto" if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA != -1
default "0" if ARCH_AT91
-- 
2.28.0

Re: Z-Turn board support on U-Boot 2020.10-rc2, got some errors.

[Michal Simek]

Hi,

On 24. 08. 20 13:21, Alexandre GRIVEAUX wrote:
> Hello,
> 
> 
> I've tried the u-boot 2020.10-rc2 and it's seem i've got some errors:
> 
> 
> U-Boot 2020.10-rc2-00204-gc84341f5ac (Aug 24 2020 - 09:49:25 +0200)
> 
> CPU:   Zynq 7z020
> Silicon: v3.1
> Model: Zynq Z-Turn MYIR Board
> DRAM:  ECC disabled 1 GiB
> Flash: 0 Bytes
> NAND:  0 MiB
> MMC:   mmc@e010: 0
> Loading Environment from SPIFlash... Invalid bus 0 (err=-19)
> *** Warning - spi_flash_probe_bus_cs() failed, using default environment
> 
> In:    serial@e0001000
> Out:   serial@e0001000
> Err:   serial@e0001000
> Net:  
> ZYNQ GEM: e000b000, mdio bus e000b000, phyaddr 0, interface rgmii-id
> Could not get PHY for eth0: addr 0
> No ethernet found.
> 
> Hit any key to stop autoboot:  0
> Zynq>
> 
> 
> According to [0] the board use a winbond W25Q128BVFIG but on the board
> it's seem to usea spansion FL128SAIF00.
> 
> I've checked if FL128SAIF00 is registered on drivers/mtd/spi/spi-nor-ids.c:
> 
> ({ INFO6("s25fl128s",  0x012018, 0x4d0180, 64 * 1024, 256,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },)
> 
> 
> I've checked if flash manufacturer was enabled on
> configs/xilinx_zynq_virt_defconfig:
> 
> CONFIG_SPI_FLASH_SPANSION=y
> 
> 
> I checked on [1] to see if the pinout is broken but not.
> 
> 
> I dont know how to correct this problem.
> 
> 
> 
> For the ethernet it's seem CONFIG_PHY_MICREL_KSZ90X1=y and
> CONFIG_PHY_MICREL=y was not on configs/xilinx_zynq_virt_defconfig
> 
> But adding it doesn't resolve it:
> 
> 
> ZYNQ GEM: e000b000, mdio bus e000b000, phyaddr 0, interface rgmii-id
> Could not get PHY for eth0: addr 0
> No ethernet found.
> 
> 
> I dont (again) know how to correct this problem.
> 
> 
> 
> Can you help me ?
> 
> 
> [0] http://www.myirtech.com/download/Zynq7000/Z-TURNBOARD_schematic.pdf
> 
> [1]
> https://www.xilinx.com/support/documentation/boards_and_kits/zc702_zvik/ug850-zc702-eval-bd.pdf
> 

It looks like that manufacturer created different versions where they
are not compatible to each other. Please take a look at this thread.
https://www.spinics.net/lists/arm-kernel/msg800078.html

I didn't accepted the patch because none else didn't test it on both
revisions.
Issue with spi flash can be also related.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs




signature.asc
Description: OpenPGP digital signature

Z-Turn board support on U-Boot 2020.10-rc2, got some errors.

[Alexandre GRIVEAUX]

Hello,


I've tried the u-boot 2020.10-rc2 and it's seem i've got some errors:


U-Boot 2020.10-rc2-00204-gc84341f5ac (Aug 24 2020 - 09:49:25 +0200)

CPU:   Zynq 7z020
Silicon: v3.1
Model: Zynq Z-Turn MYIR Board
DRAM:  ECC disabled 1 GiB
Flash: 0 Bytes
NAND:  0 MiB
MMC:   mmc@e010: 0
Loading Environment from SPIFlash... Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

In:    serial@e0001000
Out:   serial@e0001000
Err:   serial@e0001000
Net:  
ZYNQ GEM: e000b000, mdio bus e000b000, phyaddr 0, interface rgmii-id
Could not get PHY for eth0: addr 0
No ethernet found.

Hit any key to stop autoboot:  0
Zynq>


According to [0] the board use a winbond W25Q128BVFIG but on the board
it's seem to usea spansion FL128SAIF00.

I've checked if FL128SAIF00 is registered on drivers/mtd/spi/spi-nor-ids.c:

({ INFO6("s25fl128s",  0x012018, 0x4d0180, 64 * 1024, 256,
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },)


I've checked if flash manufacturer was enabled on
configs/xilinx_zynq_virt_defconfig:

CONFIG_SPI_FLASH_SPANSION=y


I checked on [1] to see if the pinout is broken but not.


I dont know how to correct this problem.



For the ethernet it's seem CONFIG_PHY_MICREL_KSZ90X1=y and
CONFIG_PHY_MICREL=y was not on configs/xilinx_zynq_virt_defconfig

But adding it doesn't resolve it:


ZYNQ GEM: e000b000, mdio bus e000b000, phyaddr 0, interface rgmii-id
Could not get PHY for eth0: addr 0
No ethernet found.


I dont (again) know how to correct this problem.



Can you help me ?


[0] http://www.myirtech.com/download/Zynq7000/Z-TURNBOARD_schematic.pdf

[1]
https://www.xilinx.com/support/documentation/boards_and_kits/zc702_zvik/ug850-zc702-eval-bd.pdf

[PATCH] cmd: mem: Remove already removed CONFIG_SYS_MEMTEST_SCRATCH

[Michal Simek]

The commit e519f03a1846 ("cmd: mem: Remove CONFIG_SYS_MEMTEST_SCRATCH
mapping") removed CONFIG_SYS_MEMTEST_SCRATCH but commit 091401131085
("command: Remove the cmd_tbl_t typedef") has added it back. That's why
symbol is still in the tree that's why remove it again.

Fixes: 091401131085 ("command: Remove the cmd_tbl_t typedef
Signed-off-by: Michal Simek 
---

 cmd/mem.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/cmd/mem.c b/cmd/mem.c
index 190e2b94a7d4..9df5eb068a79 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -30,10 +30,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#ifndef CONFIG_SYS_MEMTEST_SCRATCH
-#define CONFIG_SYS_MEMTEST_SCRATCH 0
-#endif
-
 /* Create a compile-time value */
 #ifdef MEM_SUPPORT_64BIT_DATA
 #define SUPPORT_64BIT_DATA 1
-- 
2.28.0

[PATCH v4 4/8] mips: octeon: cpu.c: Add table for selective swapping

[Stefan Roese]

Import octeon_should_swizzle_table[] which is needed for the area
specific swapping. It will be used by the platform specific
mangle-port.h header.

Imported from Linux v5.7.

Signed-off-by: Stefan Roese 
---

(no changes since v1)

 arch/mips/mach-octeon/cpu.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/mips/mach-octeon/cpu.c b/arch/mips/mach-octeon/cpu.c
index 2680a2e6ed..6f87a4ef8c 100644
--- a/arch/mips/mach-octeon/cpu.c
+++ b/arch/mips/mach-octeon/cpu.c
@@ -13,6 +13,27 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+/*
+ * TRUE for devices having registers with little-endian byte
+ * order, FALSE for registers with native-endian byte order.
+ * PCI mandates little-endian, USB and SATA are configurable,
+ * but we chose little-endian for these.
+ *
+ * This table will be referened in the Octeon platform specific
+ * mangle-port.h header.
+ */
+const bool octeon_should_swizzle_table[256] = {
+   [0x00] = true,  /* bootbus/CF */
+   [0x1b] = true,  /* PCI mmio window */
+   [0x1c] = true,  /* PCI mmio window */
+   [0x1d] = true,  /* PCI mmio window */
+   [0x1e] = true,  /* PCI mmio window */
+   [0x68] = true,  /* OCTEON III USB */
+   [0x69] = true,  /* OCTEON III USB */
+   [0x6c] = true,  /* OCTEON III SATA */
+   [0x6f] = true,  /* OCTEON II USB */
+};
+
 static int get_clocks(void)
 {
const u64 ref_clock = PLL_REF_CLK;
-- 
2.28.0

[PATCH v4 8/8] mips: octeon: octeon_ebb7304_defconfig: Enable USB support

[Stefan Roese]

This patch enables USB support with some helpful commands, like fs
support.

Signed-off-by: Stefan Roese 

---

(no changes since v1)

 configs/octeon_ebb7304_defconfig | 17 +
 1 file changed, 17 insertions(+)

diff --git a/configs/octeon_ebb7304_defconfig b/configs/octeon_ebb7304_defconfig
index 105fe5b00a..a98d73a268 100644
--- a/configs/octeon_ebb7304_defconfig
+++ b/configs/octeon_ebb7304_defconfig
@@ -15,12 +15,19 @@ CONFIG_HUSH_PARSER=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MTD=y
+CONFIG_CMD_PART=y
 CONFIG_CMD_PCI=y
+CONFIG_CMD_USB=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_TIME=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+# CONFIG_DOS_PARTITION is not set
 CONFIG_ENV_IS_IN_FLASH=y
 CONFIG_ENV_ADDR=0x1FBFE000
+CONFIG_BLK=y
 CONFIG_CLK=y
 # CONFIG_INPUT is not set
 CONFIG_MTD=y
@@ -48,4 +55,14 @@ CONFIG_SPI=y
 CONFIG_OCTEON_SPI=y
 CONFIG_SYSRESET=y
 CONFIG_SYSRESET_OCTEON=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
 CONFIG_HEXDUMP=y
-- 
2.28.0

[PATCH v4 7/8] mips: octeon: Add USB DT nodes

[Stefan Roese]

Add the USB device tree nodes to the Octeon dts/dtsi files.

Signed-off-by: Stefan Roese 
Reviewed-by: Bin Meng 

---

Changes in v4:
- Correct another missed multi-line comment style

Changes in v3:
- Add Reviewed-by tag from Bin
- Correct multi-line comment style

 arch/mips/dts/mrvl,cn73xx.dtsi| 60 +++
 arch/mips/dts/mrvl,octeon-ebb7304.dts | 24 +++
 2 files changed, 84 insertions(+)

diff --git a/arch/mips/dts/mrvl,cn73xx.dtsi b/arch/mips/dts/mrvl,cn73xx.dtsi
index 44a5a03014..40eb85ee0c 100644
--- a/arch/mips/dts/mrvl,cn73xx.dtsi
+++ b/arch/mips/dts/mrvl,cn73xx.dtsi
@@ -143,5 +143,65 @@
spi-max-frequency = <2500>;
clocks = <&clk OCTEON_CLK_IO>;
};
+
+   /* USB 0 */
+   usb0: uctl@118006800 {
+   compatible = "cavium,octeon-7130-usb-uctl";
+   reg = <0x11800 0x6800 0x0 0x100>;
+   ranges; /* Direct mapping */
+   #address-cells = <2>;
+   #size-cells = <2>;
+   /* Only 100MHz allowed */
+   refclk-frequency = <1>;
+   /* Only "dlmc_ref_clk0" is supported for 73xx */
+   refclk-type-ss = "dlmc_ref_clk0";
+   /* Only "dlmc_ref_clk0" is supported for 73xx */
+   refclk-type-hs = "dlmc_ref_clk0";
+
+   /*
+* Power is specified by three parts:
+* 1) GPIO handle (must be &gpio)
+* 2) GPIO pin number
+* 3) Active high (0) or active low (1)
+*/
+   xhci@16800 {
+   compatible = 
"cavium,octeon-7130-xhci","synopsys,dwc3","snps,dwc3";
+   reg = <0x16800 0x 0x10 0x0>;
+   interrupts = <0x68080 4>; /* UAHC_IMAN, level */
+   maximum-speed = "super-speed";
+   dr_mode = "host";
+   snps,dis_u3_susphy_quirk;
+   snps,dis_u2_susphy_quirk;
+   snps,dis_enblslpm_quirk;
+   };
+   };
+
+   /* USB 1 */
+   usb1: uctl@118006900 {
+   compatible = "cavium,octeon-7130-usb-uctl";
+   reg = <0x11800 0x6900 0x0 0x100>;
+   ranges; /* Direct mapping */
+   #address-cells = <2>;
+   #size-cells = <2>;
+   /* 50MHz, 100MHz and 125MHz allowed */
+   refclk-frequency = <1>;
+   /* Either "dlmc_ref_clk0" or "dlmc_ref_clk0" */
+   refclk-type-ss = "dlmc_ref_clk0";
+   /* Either "dlmc_ref_clk0" "dlmc_ref_clk1" or 
"pll_ref_clk" */
+   refclk-type-hs = "dlmc_ref_clk0";
+
+   /*
+* Power is specified by three parts:
+* 1) GPIO handle (must be &gpio)
+* 2) GPIO pin number
+* 3) Active high (0) or active low (1)
+*/
+   xhci@16900 {
+   compatible = 
"cavium,octeon-7130-xhci","synopsys,dwc3","snps,dwc3";
+   reg = <0x16900 0x 0x10 0x0>;
+   interrupts = <0x69080 4>; /* UAHC_IMAN, level */
+   dr_mode = "host";
+   };
+   };
};
 };
diff --git a/arch/mips/dts/mrvl,octeon-ebb7304.dts 
b/arch/mips/dts/mrvl,octeon-ebb7304.dts
index 6b2e5e84bc..993b4f6890 100644
--- a/arch/mips/dts/mrvl,octeon-ebb7304.dts
+++ b/arch/mips/dts/mrvl,octeon-ebb7304.dts
@@ -113,3 +113,27 @@
reg = <0>;
};
 };
+
+/* USB 0 */
+&usb0 {
+   status = "okay";
+   /*
+* Power is specified by three parts:
+* 1) GPIO handle (must be &gpio)
+* 2) GPIO pin number
+* 3) Active high (0) or active low (1)
+*/
+   power = <&gpio 20 0>;
+};
+
+/* USB 1 */
+&usb1 {
+   status = "okay";
+   /*
+* Power is specified by three parts:
+* 1) GPIO handle (must be &gpio)
+* 2) GPIO pin number
+* 3) Active high (0) or active low (1)
+*/
+   power = <&gpio 21 0>;
+};
-- 
2.28.0

[PATCH v4 5/8] mips: octeon: Add mangle-port.h

[Stefan Roese]

Import platform specific mangle-port.h header, allowing a area specific
swapping, which is needed on Octeon for USB & PCI areas.

Imported from Linux v5.7.

Signed-off-by: Stefan Roese 

---

(no changes since v2)

Changes in v2:
- Only use SPDX format for license info

 arch/mips/mach-octeon/include/mangle-port.h | 56 +
 1 file changed, 56 insertions(+)
 create mode 100644 arch/mips/mach-octeon/include/mangle-port.h

diff --git a/arch/mips/mach-octeon/include/mangle-port.h 
b/arch/mips/mach-octeon/include/mangle-port.h
new file mode 100644
index 00..7e95dcef5a
--- /dev/null
+++ b/arch/mips/mach-octeon/include/mangle-port.h
@@ -0,0 +1,56 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2003, 2004 Ralf Baechle
+ */
+
+#ifndef __ASM_MACH_GENERIC_MANGLE_PORT_H
+#define __ASM_MACH_GENERIC_MANGLE_PORT_H
+
+#include 
+
+#ifdef __BIG_ENDIAN
+
+static inline bool __should_swizzle_bits(volatile void *a)
+{
+   extern const bool octeon_should_swizzle_table[];
+   u64 did = ((u64)(uintptr_t)a >> 40) & 0xff;
+
+   return octeon_should_swizzle_table[did];
+}
+
+# define __swizzle_addr_b(port)(port)
+# define __swizzle_addr_w(port)(port)
+# define __swizzle_addr_l(port)(port)
+# define __swizzle_addr_q(port)(port)
+
+#else /* __LITTLE_ENDIAN */
+
+#define __should_swizzle_bits(a)   false
+
+static inline bool __should_swizzle_addr(u64 p)
+{
+   /* boot bus? */
+   return ((p >> 40) & 0xff) == 0;
+}
+
+# define __swizzle_addr_b(port)\
+   (__should_swizzle_addr(port) ? (port) ^ 7 : (port))
+# define __swizzle_addr_w(port)\
+   (__should_swizzle_addr(port) ? (port) ^ 6 : (port))
+# define __swizzle_addr_l(port)\
+   (__should_swizzle_addr(port) ? (port) ^ 4 : (port))
+# define __swizzle_addr_q(port)(port)
+
+#endif /* __BIG_ENDIAN */
+
+
+# define ioswabb(a, x) (x)
+# define __mem_ioswabb(a, x)   (x)
+# define ioswabw(a, x) (__should_swizzle_bits(a) ? le16_to_cpu(x) : x)
+# define __mem_ioswabw(a, x)   (x)
+# define ioswabl(a, x) (__should_swizzle_bits(a) ? le32_to_cpu(x) : x)
+# define __mem_ioswabl(a, x)   (x)
+# define ioswabq(a, x) (__should_swizzle_bits(a) ? le64_to_cpu(x) : x)
+# define __mem_ioswabq(a, x)   (x)
+
+#endif /* __ASM_MACH_GENERIC_MANGLE_PORT_H */
-- 
2.28.0

[PATCH v4 6/8] mips: octeon: cache.c: Flush all pending writes in flush_dcache_range()

[Stefan Roese]

As noticed while working on the USB xHCI support, Octeon needs to flush
all pending writes so that the values are present in the memory. Add
this "syncw" instruction (twice) to flush_dcache_range().

Signed-off-by: Stefan Roese 
---

(no changes since v1)

 arch/mips/mach-octeon/cache.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/mips/mach-octeon/cache.c b/arch/mips/mach-octeon/cache.c
index 9a88bb97c7..f293d65dae 100644
--- a/arch/mips/mach-octeon/cache.c
+++ b/arch/mips/mach-octeon/cache.c
@@ -5,14 +5,13 @@
 
 #include 
 
-/*
- * The Octeon platform is cache coherent and cache flushes and invalidates
- * are not needed. Define some platform specific empty flush_foo()
- * functions here to overwrite the _weak common function as a no-op.
- * This effectively disables all cache operations.
- */
+/* Octeon memory write barrier */
+#define CVMX_SYNCW asm volatile ("syncw\nsyncw\n" : : : "memory")
+
 void flush_dcache_range(ulong start_addr, ulong stop)
 {
+   /* Flush all pending writes */
+   CVMX_SYNCW;
 }
 
 void flush_cache(ulong start_addr, ulong size)
@@ -21,4 +20,5 @@ void flush_cache(ulong start_addr, ulong size)
 
 void invalidate_dcache_range(ulong start_addr, ulong stop)
 {
+   /* Don't need to do anything for OCTEON */
 }
-- 
2.28.0

[PATCH v4 2/8] usb: xhci: xhci_bulk_tx: Don't "BUG" when comparing addresses

[Stefan Roese]

Octeon uses mapped addresses for virtual and physical memory. It's not
that easy to calculate the resulting addresses here. So let's remove
this BUG_ON() completely, as it's not really helpful.

Please also note, that BUG_ON() is not recommended any more in the Linux
kernel.

Signed-off-by: Stefan Roese 
Reviewed-by: Bin Meng 
Cc: Bin Meng 
Cc: Marek Vasut 

---

Changes in v4:
- Add Reviewed-by tag from Bin

Changes in v3:
- Minor corrections to the commit text as suggested by Bin

Changes in v2:
- Completely remove BUG_ON() for this trans_event.buffer check
- Reword commit text

 drivers/usb/host/xhci-ring.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 092ed6eaf1..fd15f39906 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -726,8 +726,6 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long 
pipe,
 
BUG_ON(TRB_TO_SLOT_ID(field) != slot_id);
BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
-   BUG_ON(*(void **)(uintptr_t)le64_to_cpu(event->trans_event.buffer) -
-   buffer > (size_t)length);
 
record_transfer_result(udev, event, length);
xhci_acknowledge_event(ctrl);
-- 
2.28.0

[PATCH v4 1/8] usb: xhci: xhci-dwc3.c: Use dev_remap_addr() instead of dev_get_addr()

[Stefan Roese]

On MIPS platforms, mapping of the base address is needed. This patch
switches from dev_get_addr() to dev_remap_addr() to get the mapped base
address of the xHCI controller.

Signed-off-by: Stefan Roese 
Reviewed-by: Bin Meng 
Cc: Bin Meng 
Cc: Marek Vasut 

---

(no changes since v3)

Changes in v3:
- Add Reviewed-by tag from Bin

 drivers/usb/host/xhci-dwc3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
index 27f84102db..045de2ffde 100644
--- a/drivers/usb/host/xhci-dwc3.c
+++ b/drivers/usb/host/xhci-dwc3.c
@@ -122,7 +122,7 @@ static int xhci_dwc3_probe(struct udevice *dev)
u32 reg;
int ret;
 
-   hccr = (struct xhci_hccr *)((uintptr_t)dev_read_addr(dev));
+   hccr = (struct xhci_hccr *)((uintptr_t)dev_remap_addr(dev));
hcor = (struct xhci_hcor *)((uintptr_t)hccr +
HC_LENGTH(xhci_readl(&(hccr)->cr_capbase)));
 
-- 
2.28.0

[PATCH v4 0/8] mips/usb: Add Octeon xHCI USB support

[Stefan Roese]

This patchset adds xHCI USB support for MIPS Octeon. After the xHCI code
has been fixed to support mapped addresses (virt != phys), this patchset
now adds the missing code pieces to enable USB support on Octeon. This
is mainly the USB glue code for Octeon and the MIPS platform specific
changes (cache fixes, platform specific swapping based on address areas,
DT & defcopnfig changes).

Thanks,
Stefan

Changes in v4:
- Add Reviewed-by tag from Bin
- Add Reviewed-by tag from Bin
- Correct another missed multi-line comment style

Changes in v3:
- Add Reviewed-by tag from Bin
- Minor corrections to the commit text as suggested by Bin
- Minor corrections of the commit text as suggested by Bin
- Minor corrections in comments as suggested by Bin
- Removed empty driver remove() function
- Use macros for clock values instead of numbers
- Add Reviewed-by tag from Bin
- Correct multi-line comment style

Changes in v2:
- Completely remove BUG_ON() for this trans_event.buffer check
- Reword commit text
- Only use SPDX format for license info

Stefan Roese (8):
  usb: xhci: xhci-dwc3.c: Use dev_remap_addr() instead of dev_get_addr()
  usb: xhci: xhci_bulk_tx: Don't "BUG" when comparing addresses
  usb: xhci: octeon: Add DWC3 glue layer for Octeon
  mips: octeon: cpu.c: Add table for selective swapping
  mips: octeon: Add mangle-port.h
  mips: octeon: cache.c: Flush all pending writes in
flush_dcache_range()
  mips: octeon: Add USB DT nodes
  mips: octeon: octeon_ebb7304_defconfig: Enable USB support

 arch/mips/dts/mrvl,cn73xx.dtsi  |  60 +++
 arch/mips/dts/mrvl,octeon-ebb7304.dts   |  24 ++
 arch/mips/mach-octeon/cache.c   |  12 +-
 arch/mips/mach-octeon/cpu.c |  21 ++
 arch/mips/mach-octeon/include/mangle-port.h |  56 +++
 configs/octeon_ebb7304_defconfig|  17 +
 drivers/usb/host/Kconfig|   9 +
 drivers/usb/host/Makefile   |   1 +
 drivers/usb/host/dwc3-octeon-glue.c | 393 
 drivers/usb/host/xhci-dwc3.c|   2 +-
 drivers/usb/host/xhci-ring.c|   2 -
 11 files changed, 588 insertions(+), 9 deletions(-)
 create mode 100644 arch/mips/mach-octeon/include/mangle-port.h
 create mode 100644 drivers/usb/host/dwc3-octeon-glue.c

-- 
2.28.0

[PATCH v4 3/8] usb: xhci: octeon: Add DWC3 glue layer for Octeon

[Stefan Roese]

This patch adds the glue layer for the MIPS Octeon SoCs. It's ported
mainly from the Linux code.

Signed-off-by: Stefan Roese 
Reviewed-by: Bin Meng 
Cc: Bin Meng 
Cc: Marek Vasut 

---

Changes in v4:
- Add Reviewed-by tag from Bin

Changes in v3:
- Minor corrections of the commit text as suggested by Bin
- Minor corrections in comments as suggested by Bin
- Removed empty driver remove() function
- Use macros for clock values instead of numbers

 drivers/usb/host/Kconfig|   9 +
 drivers/usb/host/Makefile   |   1 +
 drivers/usb/host/dwc3-octeon-glue.c | 393 
 3 files changed, 403 insertions(+)
 create mode 100644 drivers/usb/host/dwc3-octeon-glue.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 1c374a7bd8..d71c12d888 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -46,6 +46,15 @@ config USB_XHCI_MVEBU
  SoCs, which includes Armada8K, Armada3700 and other Armada
  family SoCs.
 
+config USB_XHCI_OCTEON
+   bool "Support for Marvell Octeon family on-chip xHCI USB controller"
+   depends on ARCH_OCTEON
+   default y
+   help
+ Enables support for the on-chip xHCI controller on Marvell Octeon
+ family SoCs. This is a driver for the dwc3 to provide the glue logic
+ to configure the controller.
+
 config USB_XHCI_PCI
bool "Support for PCI-based xHCI USB controller"
depends on DM_USB
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 29d4f87e38..a12e8f2702 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o
 obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
 obj-$(CONFIG_USB_XHCI_RCAR) += xhci-rcar.o
 obj-$(CONFIG_USB_XHCI_STI) += dwc3-sti-glue.o
+obj-$(CONFIG_USB_XHCI_OCTEON) += dwc3-octeon-glue.o
 
 # designware
 obj-$(CONFIG_USB_DWC2) += dwc2.o
diff --git a/drivers/usb/host/dwc3-octeon-glue.c 
b/drivers/usb/host/dwc3-octeon-glue.c
new file mode 100644
index 00..39b3185616
--- /dev/null
+++ b/drivers/usb/host/dwc3-octeon-glue.c
@@ -0,0 +1,393 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Octeon family DWC3 specific glue layer
+ *
+ * Copyright (C) 2020 Stefan Roese 
+ *
+ * The low-level init code is based on the Linux driver octeon-usb.c by
+ * David Daney , which is:
+ * Copyright (C) 2010-2017 Cavium Networks
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define CVMX_GPIO_BIT_CFGX(i)  (0x000107000900ull + ((i) * 8))
+#define CVMX_GPIO_XBIT_CFGX(i) (0x000107000900ull + \
+((i) & 31) * 8 - 8 * 16)
+
+#define GPIO_BIT_CFG_TX_OE BIT_ULL(0)
+#define GPIO_BIT_CFG_OUTPUT_SELGENMASK_ULL(20, 16)
+
+#define UCTL_CTL_UCTL_RST  BIT_ULL(0)
+#define UCTL_CTL_UAHC_RST  BIT_ULL(1)
+#define UCTL_CTL_UPHY_RST  BIT_ULL(2)
+#define UCTL_CTL_DRD_MODE  BIT_ULL(3)
+#define UCTL_CTL_SCLK_EN   BIT_ULL(4)
+#define UCTL_CTL_HS_POWER_EN   BIT_ULL(12)
+#define UCTL_CTL_SS_POWER_EN   BIT_ULL(14)
+#define UCTL_CTL_H_CLKDIV_SEL  GENMASK_ULL(26, 24)
+#define UCTL_CTL_H_CLKDIV_RST  BIT_ULL(28)
+#define UCTL_CTL_H_CLK_EN  BIT_ULL(30)
+#define UCTL_CTL_REF_CLK_FSEL  GENMASK_ULL(37, 32)
+#define UCTL_CTL_REF_CLK_DIV2  BIT_ULL(38)
+#define UCTL_CTL_REF_SSP_ENBIT_ULL(39)
+#define UCTL_CTL_MPLL_MULTIPLIER   GENMASK_ULL(46, 40)
+#define UCTL_CTL_SSC_ENBIT_ULL(59)
+#define UCTL_CTL_REF_CLK_SEL   GENMASK_ULL(61, 60)
+
+#define UCTL_HOST_CFG  0xe0
+#define UCTL_HOST_CFG_PPC_ACTIVE_HIGH_EN BIT_ULL(24)
+#define UCTL_HOST_CFG_PPC_EN   BIT_ULL(25)
+
+#define UCTL_SHIM_CFG  0xe8
+#define UCTL_SHIM_CFG_CSR_ENDIAN_MODE  GENMASK_ULL(1, 0)
+#define UCTL_SHIM_CFG_DMA_ENDIAN_MODE  GENMASK_ULL(9, 8)
+
+#define OCTEON_H_CLKDIV_SEL8
+#define OCTEON_MIN_H_CLK_RATE  15000
+#define OCTEON_MAX_H_CLK_RATE  3
+
+#define CLOCK_50MHZ5000
+#define CLOCK_100MHZ   1
+#define CLOCK_125MHZ   12500
+
+static u8 clk_div[OCTEON_H_CLKDIV_SEL] = {1, 2, 4, 6, 8, 16, 24, 32};
+
+static int dwc3_octeon_config_power(struct udevice *dev, void __iomem *base)
+{
+   u64 uctl_host_cfg;
+   u64 gpio_bit;
+   u32 gpio_pwr[3];
+   int gpio, len, power_active_low;
+   const struct device_node *node = dev_np(dev);
+   int index = ((u64)base >> 24) & 1;
+   void __iomem *gpio_bit_cfg;
+
+   if (of_find_property(node, "power", &len)) {
+   if (len == 12) {
+   dev_read_u32_array(dev, "power", gpio_pwr, 3);
+   power_active_low = gpio_pwr[2

[PATCH v8 00/10] Remove CONFIG_NR_DRAM_BANKS option and bi_memstart/memsize from bd_info

[Stefan Roese]

This patchset is an extension of the previous single patch
"CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined".
With a split into separate patches, its hopefully easier to understand,
what is changed.

The earlier patch versions tried a simple search and replace of the
bi_memstart / bi_memsize values with bi_dram[].start/.size. This did
not work. This patchset now removes some of the assignments and changes
in most cases to gd->ram_base/ram_size instead, which seems a better
choice.

Successful Azure build report:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=39

Thanks,
Stefan

Changes in v8:
- Add Reviewed-by tag from Bin
- Rebased on latest TOT
- Add Reviewed-by tag from Simon
- Add Reviewed-by tag from Simon
- Add Reviewed-by tag from Simon
- Add Reviewed-by tag from Simon
- Add Reviewed-by tag from Simon

Changes in v7:
- Add Reviewe-by tag from Ovidiu
- Reword commit text as suggested by Wolfgang
- Add Reviewe-by tag from Ovidiu
- Add Reviewe-by tag from Ovidiu
- Add Reviewe-by tag from Ovidiu

Changes in v6:
- Simplify dram_init_banksize() even more as suggested by Daniel

Changes in v5:
- Add Reviewed-by tag from Pali & Andy
- Move "bd" assignment as suggested by Andy
- Use PHYSADDR() for xtensa, as the bi_memstart value was originally
  defined this way
- New patch to fix the failing "test.py xtfpga" CI test
- Add Tested-by tag from Oleksandr & Michael

Changes in v4:
- Only remove dead code with CONFIG_NR_DRAM_BANKS always defined
- New patch
- New patch
- New patch
- New patch
- New patch
- New patch
- New patch
- New patch

Stefan Roese (10):
  CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
  image: Use gd->ram_base/_size in env_get_bootm_size()
  board_f: Add default values for bi_dram[] in dram_init_banksize()
  global: Move from bi_memstart/memsize -> gd->ram_base/ram_size
  xtensa: Remove arch_setup_bdinfo()
  xtensa: Remove local no-op dram_init_banksize()
  video: cfb_console.c: Use bi_dram[] values on all platforms
  powerpc: Remove bi_memstart & bi_memsize assignments in spl.c
  cmd: bdinfo: Remove print of superseeded bi_memstart / bi_memsize
values
  asm-generic/u-boot.h: Remove bi_memstart & bi_memsize from bd_info

 api/api_platform-mips.c   |  3 +--
 api/api_platform-powerpc.c|  2 +-
 arch/mips/lib/boot.c  |  2 +-
 arch/mips/lib/bootm.c |  2 +-
 arch/powerpc/cpu/mpc83xx/fdt.c|  2 +-
 arch/powerpc/cpu/mpc83xx/traps.c  |  2 +-
 arch/powerpc/cpu/mpc85xx/fdt.c|  4 ++--
 arch/powerpc/cpu/mpc85xx/traps.c  |  2 +-
 arch/powerpc/cpu/mpc86xx/fdt.c|  4 +++-
 arch/powerpc/cpu/mpc86xx/traps.c  |  2 +-
 arch/powerpc/cpu/mpc8xx/fdt.c |  2 +-
 arch/powerpc/lib/bootm.c  |  4 ++--
 arch/x86/cpu/broadwell/cpu_from_spl.c |  2 --
 arch/xtensa/lib/Makefile  |  2 +-
 arch/xtensa/lib/bdinfo.c  | 22 --
 arch/xtensa/lib/bootm.c   |  5 ++--
 board/Arcturus/ucp1020/spl.c  |  2 --
 board/cadence/xtfpga/xtfpga.c |  5 
 board/freescale/p1010rdb/spl.c|  2 --
 board/freescale/p1_p2_rdb_pc/spl.c|  2 --
 board/freescale/t102xrdb/spl.c|  2 --
 board/freescale/t104xrdb/spl.c|  2 --
 board/freescale/t208xqds/spl.c|  2 --
 board/freescale/t208xrdb/spl.c|  2 --
 board/freescale/t4rdb/spl.c   |  2 --
 board/xilinx/zynqmp/zynqmp.c  |  2 --
 cmd/bdinfo.c  | 10 
 cmd/bedbug.c  |  2 +-
 common/board_f.c  | 12 +-
 common/image.c| 10 ++--
 common/init/handoff.c | 33 +++
 drivers/pci/pci-uclass.c  | 18 ++-
 drivers/video/cfb_console.c   |  8 +--
 include/asm-generic/u-boot.h  |  4 
 include/handoff.h |  2 --
 lib/fdtdec.c  |  5 
 lib/lmb.c |  9 ++--
 37 files changed, 41 insertions(+), 157 deletions(-)
 delete mode 100644 arch/xtensa/lib/bdinfo.c

-- 
2.28.0

[PATCH] riscv: Add do_irqinfo() for CONFIG_CMD_IRQ

[Pragnesh Patel]

Right now, do_irqinfo() done nothing and return 0 for
CONFIG_CMD_IRQ

Signed-off-by: Pragnesh Patel 
---
 arch/riscv/lib/interrupts.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
index cd47e64487..d6273606b5 100644
--- a/arch/riscv/lib/interrupts.c
+++ b/arch/riscv/lib/interrupts.c
@@ -145,3 +145,10 @@ __attribute__((weak)) void external_interrupt(struct 
pt_regs *regs)
 __attribute__((weak)) void timer_interrupt(struct pt_regs *regs)
 {
 }
+
+#if defined(CONFIG_CMD_IRQ)
+int do_irqinfo(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+{
+   return 0;
+}
+#endif
-- 
2.17.1

[PATCH v8 01/10] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined

[Stefan Roese]

Since commit 86cf1c82850f ("configs: Migrate CONFIG_NR_DRAM_BANKS") &
commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
CONFIG_NR_DRAM_BANKS is always defined with a value (4 is default).
It makes no sense to still carry code that is guarded with
"#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
all these unreferenced code paths.

Signed-off-by: Stefan Roese 
Reviewed-by: Pali Rohár 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Bin Meng 

---

Changes in v8:
- Add Reviewed-by tag from Bin
- Rebased on latest TOT

Changes in v5:
- Add Reviewed-by tag from Pali & Andy
- Move "bd" assignment as suggested by Andy

Changes in v4:
- Only remove dead code with CONFIG_NR_DRAM_BANKS always defined

 arch/x86/cpu/broadwell/cpu_from_spl.c |  2 --
 board/xilinx/zynqmp/zynqmp.c  |  2 --
 cmd/bdinfo.c  |  2 --
 common/board_f.c  |  7 +-
 common/image.c|  3 +--
 common/init/handoff.c | 33 +++
 drivers/pci/pci-uclass.c  | 18 ++-
 include/asm-generic/u-boot.h  |  2 --
 include/handoff.h |  2 --
 lib/fdtdec.c  |  5 
 lib/lmb.c |  9 ++--
 11 files changed, 19 insertions(+), 66 deletions(-)

diff --git a/arch/x86/cpu/broadwell/cpu_from_spl.c 
b/arch/x86/cpu/broadwell/cpu_from_spl.c
index 6567d50653..4d4cdafa2b 100644
--- a/arch/x86/cpu/broadwell/cpu_from_spl.c
+++ b/arch/x86/cpu/broadwell/cpu_from_spl.c
@@ -53,14 +53,12 @@ void board_debug_uart_init(void)
 
 int dram_init_banksize(void)
 {
-#ifdef CONFIG_NR_DRAM_BANKS
struct spl_handoff *ho;
 
ho = bloblist_find(BLOBLISTT_SPL_HANDOFF, sizeof(*ho));
if (!ho)
return log_msg_ret("Missing SPL hand-off info", -ENOENT);
handoff_load_dram_banks(ho);
-#endif
 
return 0;
 }
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index b4e7301d50..bcfd56a912 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -423,10 +423,8 @@ int dram_init(void)
 #else
 int dram_init_banksize(void)
 {
-#if defined(CONFIG_NR_DRAM_BANKS)
gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
gd->bd->bi_dram[0].size = get_effective_memsize();
-#endif
 
mem_map_fill();
 
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index 9593b345a3..9e230f23cb 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -49,7 +49,6 @@ void bdinfo_print_mhz(const char *name, unsigned long hz)
 
 static void print_bi_dram(const struct bd_info *bd)
 {
-#ifdef CONFIG_NR_DRAM_BANKS
int i;
 
for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
@@ -59,7 +58,6 @@ static void print_bi_dram(const struct bd_info *bd)
bdinfo_print_num("-> size", bd->bi_dram[i].size);
}
}
-#endif
 }
 
 __weak void arch_print_bdinfo(void)
diff --git a/common/board_f.c b/common/board_f.c
index 3932e0c69d..d1f0f9af08 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -215,8 +215,6 @@ static int announce_dram_init(void)
 static int show_dram_config(void)
 {
unsigned long long size;
-
-#ifdef CONFIG_NR_DRAM_BANKS
int i;
 
debug("\nRAM Configuration:\n");
@@ -229,9 +227,6 @@ static int show_dram_config(void)
 #endif
}
debug("\nDRAM:  ");
-#else
-   size = gd->ram_size;
-#endif
 
print_size(size, "");
board_add_ram_info(0);
@@ -242,7 +237,7 @@ static int show_dram_config(void)
 
 __weak int dram_init_banksize(void)
 {
-#if defined(CONFIG_NR_DRAM_BANKS) && defined(CONFIG_SYS_SDRAM_BASE)
+#if defined(CONFIG_SYS_SDRAM_BASE)
gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
gd->bd->bi_dram[0].size = get_effective_memsize();
 #endif
diff --git a/common/image.c b/common/image.c
index 9d7d5c17d1..2ed46f7685 100644
--- a/common/image.c
+++ b/common/image.c
@@ -685,8 +685,7 @@ phys_size_t env_get_bootm_size(void)
return tmp;
}
 
-#if (defined(CONFIG_ARM) || defined(CONFIG_MICROBLAZE)) && \
- defined(CONFIG_NR_DRAM_BANKS)
+#if defined(CONFIG_ARM) || defined(CONFIG_MICROBLAZE)
start = gd->bd->bi_dram[0].start;
size = gd->bd->bi_dram[0].size;
 #else
diff --git a/common/init/handoff.c b/common/init/handoff.c
index e00b43e6a7..62071bd017 100644
--- a/common/init/handoff.c
+++ b/common/init/handoff.c
@@ -12,18 +12,15 @@ DECLARE_GLOBAL_DATA_PTR;
 
 void handoff_save_dram(struct spl_handoff *ho)
 {
+   struct bd_info *bd = gd->bd;
+   int i;
+
ho->ram_size = gd->ram_size;
-#ifdef CONFIG_NR_DRAM_BANKS
-   {
-   struct bd_info *bd = gd->bd;
-   int i;
-
-   for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
-   ho->ram_bank[i].start = bd->bi_dram[i].start;
-   ho->ram_bank[i].size = bd->bi_dram[i].size;
-   }
+
+   for (i = 0; i < CONFIG

[PATCH v8 08/10] powerpc: Remove bi_memstart & bi_memsize assignments in spl.c

[Stefan Roese]

Most likely these deprecated (removed) variables are not needed. Lets
remove the assignments completely from all spl.c files.

Signed-off-by: Stefan Roese 
Tested-by: Oleksandr Zhadan and Michael Durrant
Reviewed-by: Simon Glass 

---

Changes in v8:
- Add Reviewed-by tag from Simon

Changes in v5:
- Add Tested-by tag from Oleksandr & Michael

Changes in v4:
- New patch

 board/Arcturus/ucp1020/spl.c   | 2 --
 board/freescale/p1010rdb/spl.c | 2 --
 board/freescale/p1_p2_rdb_pc/spl.c | 2 --
 board/freescale/t102xrdb/spl.c | 2 --
 board/freescale/t104xrdb/spl.c | 2 --
 board/freescale/t208xqds/spl.c | 2 --
 board/freescale/t208xrdb/spl.c | 2 --
 board/freescale/t4rdb/spl.c| 2 --
 8 files changed, 16 deletions(-)

diff --git a/board/Arcturus/ucp1020/spl.c b/board/Arcturus/ucp1020/spl.c
index 5416a5b663..0fd9532d74 100644
--- a/board/Arcturus/ucp1020/spl.c
+++ b/board/Arcturus/ucp1020/spl.c
@@ -83,8 +83,6 @@ void board_init_r(gd_t *gd, ulong dest_addr)
bd = (struct bd_info *)(CONFIG_SPL_GD_ADDR + sizeof(gd_t));
memset(bd, 0, sizeof(struct bd_info));
gd->bd = bd;
-   bd->bi_memstart = CONFIG_SYS_INIT_L2_ADDR;
-   bd->bi_memsize = CONFIG_SYS_L2_SIZE;
 
arch_cpu_init();
get_clocks();
diff --git a/board/freescale/p1010rdb/spl.c b/board/freescale/p1010rdb/spl.c
index 4ee4573d2b..fbaa6a6514 100644
--- a/board/freescale/p1010rdb/spl.c
+++ b/board/freescale/p1010rdb/spl.c
@@ -69,8 +69,6 @@ void board_init_r(gd_t *gd, ulong dest_addr)
bd = (struct bd_info *)(CONFIG_SPL_GD_ADDR + sizeof(gd_t));
memset(bd, 0, sizeof(struct bd_info));
gd->bd = bd;
-   bd->bi_memstart = CONFIG_SYS_INIT_L2_ADDR;
-   bd->bi_memsize = CONFIG_SYS_L2_SIZE;
 
arch_cpu_init();
get_clocks();
diff --git a/board/freescale/p1_p2_rdb_pc/spl.c 
b/board/freescale/p1_p2_rdb_pc/spl.c
index e76c3e82c3..8aceceb56a 100644
--- a/board/freescale/p1_p2_rdb_pc/spl.c
+++ b/board/freescale/p1_p2_rdb_pc/spl.c
@@ -75,8 +75,6 @@ void board_init_r(gd_t *gd, ulong dest_addr)
bd = (struct bd_info *)(CONFIG_SPL_GD_ADDR + sizeof(gd_t));
memset(bd, 0, sizeof(struct bd_info));
gd->bd = bd;
-   bd->bi_memstart = CONFIG_SYS_INIT_L2_ADDR;
-   bd->bi_memsize = CONFIG_SYS_L2_SIZE;
 
arch_cpu_init();
get_clocks();
diff --git a/board/freescale/t102xrdb/spl.c b/board/freescale/t102xrdb/spl.c
index da442fcc18..09dd88ac4e 100644
--- a/board/freescale/t102xrdb/spl.c
+++ b/board/freescale/t102xrdb/spl.c
@@ -103,8 +103,6 @@ void board_init_r(gd_t *gd, ulong dest_addr)
bd = (struct bd_info *)(gd + sizeof(gd_t));
memset(bd, 0, sizeof(struct bd_info));
gd->bd = bd;
-   bd->bi_memstart = CONFIG_SYS_INIT_L3_ADDR;
-   bd->bi_memsize = CONFIG_SYS_L3_SIZE;
 
arch_cpu_init();
get_clocks();
diff --git a/board/freescale/t104xrdb/spl.c b/board/freescale/t104xrdb/spl.c
index f83d69ba15..e7922954de 100644
--- a/board/freescale/t104xrdb/spl.c
+++ b/board/freescale/t104xrdb/spl.c
@@ -94,8 +94,6 @@ void board_init_r(gd_t *gd, ulong dest_addr)
bd = (struct bd_info *)(gd + sizeof(gd_t));
memset(bd, 0, sizeof(struct bd_info));
gd->bd = bd;
-   bd->bi_memstart = CONFIG_SYS_INIT_L3_ADDR;
-   bd->bi_memsize = CONFIG_SYS_L3_SIZE;
 
arch_cpu_init();
get_clocks();
diff --git a/board/freescale/t208xqds/spl.c b/board/freescale/t208xqds/spl.c
index c197884421..d8c2bbe28d 100644
--- a/board/freescale/t208xqds/spl.c
+++ b/board/freescale/t208xqds/spl.c
@@ -102,8 +102,6 @@ void board_init_r(gd_t *gd, ulong dest_addr)
bd = (struct bd_info *)(gd + sizeof(gd_t));
memset(bd, 0, sizeof(struct bd_info));
gd->bd = bd;
-   bd->bi_memstart = CONFIG_SYS_INIT_L3_ADDR;
-   bd->bi_memsize = CONFIG_SYS_L3_SIZE;
 
arch_cpu_init();
get_clocks();
diff --git a/board/freescale/t208xrdb/spl.c b/board/freescale/t208xrdb/spl.c
index 07aab6349c..c64bd87115 100644
--- a/board/freescale/t208xrdb/spl.c
+++ b/board/freescale/t208xrdb/spl.c
@@ -72,8 +72,6 @@ void board_init_r(gd_t *gd, ulong dest_addr)
bd = (struct bd_info *)(gd + sizeof(gd_t));
memset(bd, 0, sizeof(struct bd_info));
gd->bd = bd;
-   bd->bi_memstart = CONFIG_SYS_INIT_L3_ADDR;
-   bd->bi_memsize = CONFIG_SYS_L3_SIZE;
 
arch_cpu_init();
get_clocks();
diff --git a/board/freescale/t4rdb/spl.c b/board/freescale/t4rdb/spl.c
index 64d2753da8..9aa0a9b052 100644
--- a/board/freescale/t4rdb/spl.c
+++ b/board/freescale/t4rdb/spl.c
@@ -75,8 +75,6 @@ void board_init_r(gd_t *gd, ulong dest_addr)
bd = (struct bd_info *)(gd + sizeof(gd_t));
memset(bd, 0, sizeof(struct bd_info));
gd->bd = bd;
-   bd->bi_memstart = CONFIG_SYS_INIT_L3_ADDR;
-   bd->bi_memsize = CONFIG_SYS_L3_SIZE;
 
arch_cpu_init();
get_clocks();
-- 
2.28.0

[PATCH v8 09/10] cmd: bdinfo: Remove print of superseeded bi_memstart / bi_memsize values

[Stefan Roese]

Remove printing of the superseeded (by bi_dram[]) memory values from the
bdinfo command.

Signed-off-by: Stefan Roese 
Reviewed-by: Ovidiu Panait 

---

(no changes since v7)

Changes in v7:
- Add Reviewe-by tag from Ovidiu

Changes in v4:
- New patch

 cmd/bdinfo.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index 9e230f23cb..0229846d3e 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -34,12 +34,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];
@@ -73,8 +67,6 @@ int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, char 
*const argv[])
 #endif
bdinfo_print_num("boot_params", (ulong)bd->bi_boot_params);
print_bi_dram(bd);
-   bdinfo_print_num("memstart", (ulong)bd->bi_memstart);
-   print_phys_addr("memsize", bd->bi_memsize);
if (IS_ENABLED(CONFIG_SYS_HAS_SRAM)) {
bdinfo_print_num("sramstart", (ulong)bd->bi_sramstart);
bdinfo_print_num("sramsize", (ulong)bd->bi_sramsize);
-- 
2.28.0

[PATCH v8 06/10] xtensa: Remove local no-op dram_init_banksize()

[Stefan Roese]

When this no-op dram_init_banksize() is removed, the weak default will
be used instead, which correctly sets the bi_dram[] banksize values.

Signed-off-by: Stefan Roese 
Reviewed-by: Ovidiu Panait 

---

(no changes since v7)

Changes in v7:
- Add Reviewe-by tag from Ovidiu

Changes in v5:
- New patch to fix the failing "test.py xtfpga" CI test

 board/cadence/xtfpga/xtfpga.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/board/cadence/xtfpga/xtfpga.c b/board/cadence/xtfpga/xtfpga.c
index 4b49b6e5c8..5811c43142 100644
--- a/board/cadence/xtfpga/xtfpga.c
+++ b/board/cadence/xtfpga/xtfpga.c
@@ -49,11 +49,6 @@ int checkboard(void)
return 0;
 }
 
-int dram_init_banksize(void)
-{
-   return 0;
-}
-
 int board_postclk_init(void)
 {
/*
-- 
2.28.0

[PATCH v8 04/10] global: Move from bi_memstart/memsize -> gd->ram_base/ram_size

[Stefan Roese]

With the planned removal of bi_memstart & bi_memsize, this patch now
moves the references to the better suiting gd->ram_base/ram_size
variables.

Signed-off-by: Stefan Roese 
Reviewed-by: Simon Glass 

---

Changes in v8:
- Add Reviewed-by tag from Simon

Changes in v7:
- Reword commit text as suggested by Wolfgang

Changes in v5:
- Use PHYSADDR() for xtensa, as the bi_memstart value was originally
  defined this way

Changes in v4:
- New patch

 api/api_platform-mips.c  | 3 +--
 api/api_platform-powerpc.c   | 2 +-
 arch/mips/lib/boot.c | 2 +-
 arch/mips/lib/bootm.c| 2 +-
 arch/powerpc/cpu/mpc83xx/fdt.c   | 2 +-
 arch/powerpc/cpu/mpc83xx/traps.c | 2 +-
 arch/powerpc/cpu/mpc85xx/fdt.c   | 4 ++--
 arch/powerpc/cpu/mpc85xx/traps.c | 2 +-
 arch/powerpc/cpu/mpc86xx/fdt.c   | 4 +++-
 arch/powerpc/cpu/mpc86xx/traps.c | 2 +-
 arch/powerpc/cpu/mpc8xx/fdt.c| 2 +-
 arch/powerpc/lib/bootm.c | 4 ++--
 arch/xtensa/lib/bootm.c  | 5 ++---
 cmd/bedbug.c | 2 +-
 14 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/api/api_platform-mips.c b/api/api_platform-mips.c
index 51cd328b3d..e1509663af 100644
--- a/api/api_platform-mips.c
+++ b/api/api_platform-mips.c
@@ -24,8 +24,7 @@ DECLARE_GLOBAL_DATA_PTR;
 int platform_sys_info(struct sys_info *si)
 {
 
-   platform_set_mr(si, gd->bd->bi_memstart,
-   gd->bd->bi_memsize, MR_ATTR_DRAM);
+   platform_set_mr(si, gd->ram_base, gd->ram_size, MR_ATTR_DRAM);
 
return 1;
 }
diff --git a/api/api_platform-powerpc.c b/api/api_platform-powerpc.c
index 15930cfdb6..847a4a3015 100644
--- a/api/api_platform-powerpc.c
+++ b/api/api_platform-powerpc.c
@@ -42,7 +42,7 @@ int platform_sys_info(struct sys_info *si)
si->bar = 0;
 #endif
 
-   platform_set_mr(si, gd->bd->bi_memstart, gd->bd->bi_memsize, 
MR_ATTR_DRAM);
+   platform_set_mr(si, gd->ram_base, gd->ram_size, MR_ATTR_DRAM);
platform_set_mr(si, gd->bd->bi_flashstart, gd->bd->bi_flashsize, 
MR_ATTR_FLASH);
platform_set_mr(si, gd->bd->bi_sramstart, gd->bd->bi_sramsize, 
MR_ATTR_SRAM);
 
diff --git a/arch/mips/lib/boot.c b/arch/mips/lib/boot.c
index db862f6379..6ef9109022 100644
--- a/arch/mips/lib/boot.c
+++ b/arch/mips/lib/boot.c
@@ -17,7 +17,7 @@ unsigned long do_go_exec(ulong (*entry)(int, char * const []),
 * whole SDRAM area, since we don't know the size of the image
 * that was loaded.
 */
-   flush_cache(gd->bd->bi_memstart, gd->ram_top - gd->bd->bi_memstart);
+   flush_cache(gd->ram_base, gd->ram_top - gd->ram_base);
 
return entry(argc, argv);
 }
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index 0a13f6edb7..d5c99d891c 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -242,7 +242,7 @@ static int boot_reloc_fdt(bootm_headers_t *images)
 #if CONFIG_IS_ENABLED(MIPS_BOOT_FDT) && CONFIG_IS_ENABLED(OF_LIBFDT)
 int arch_fixup_fdt(void *blob)
 {
-   u64 mem_start = virt_to_phys((void *)gd->bd->bi_memstart);
+   u64 mem_start = virt_to_phys((void *)gd->ram_base);
u64 mem_size = gd->ram_size;
 
return fdt_fixup_memory_banks(blob, &mem_start, &mem_size, 1);
diff --git a/arch/powerpc/cpu/mpc83xx/fdt.c b/arch/powerpc/cpu/mpc83xx/fdt.c
index ebdedb2888..4ea7b27ef4 100644
--- a/arch/powerpc/cpu/mpc83xx/fdt.c
+++ b/arch/powerpc/cpu/mpc83xx/fdt.c
@@ -121,7 +121,7 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
 "clock-frequency", get_serial_clock(), 1);
 #endif
 
-   fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
+   fdt_fixup_memory(blob, (u64)gd->ram_base, (u64)gd->ram_size);
 
 #if defined(CONFIG_BOOTCOUNT_LIMIT) && \
(defined(CONFIG_QE) && !defined(CONFIG_ARCH_MPC831X))
diff --git a/arch/powerpc/cpu/mpc83xx/traps.c b/arch/powerpc/cpu/mpc83xx/traps.c
index c3cc119d65..ea8bc6c152 100644
--- a/arch/powerpc/cpu/mpc83xx/traps.c
+++ b/arch/powerpc/cpu/mpc83xx/traps.c
@@ -23,7 +23,7 @@ DECLARE_GLOBAL_DATA_PTR;
 /* Returns 0 if exception not found and fixup otherwise.  */
 extern unsigned long search_exception_table(unsigned long);
 
-#define END_OF_MEM (gd->bd->bi_memstart + gd->bd->bi_memsize)
+#define END_OF_MEM (gd->ram_base + gd->ram_size)
 
 /*
  * Trap & Exception support
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 9569c1a64b..0d8353ceb2 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -672,10 +672,10 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
"clock-frequency", get_bus_freq(0), 1);
 #endif
 
-   fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
+   fdt_fixup_memory(blob, (u64)gd->ram_base, (u64)gd->ram_size);
 
 #ifdef CONFIG_MP
-   ft_fixup_cpu(blob, (u64)bd->bi_memstart + (u64)bd->bi_memsize);
+   ft_fixup_cpu(blob, (u64)gd->ram_base + (u64)gd->ram_size);
ft_fixup_num_cores(blob);
 #endif
 
diff --g

[PATCH v8 03/10] board_f: Add default values for bi_dram[] in dram_init_banksize()

[Stefan Roese]

Remove the bi_memstart / bi_memsize assignment in setup_bdinfo() and
make sure, that bd_dram[] is always configured in the weak default
implementation of dram_init_banksize(), when CONFIG_SYS_SDRAM_BASE is
not set.

Signed-off-by: Stefan Roese 
Reviewed-by: Ovidiu Panait 

---

(no changes since v7)

Changes in v7:
- Add Reviewe-by tag from Ovidiu

Changes in v6:
- Simplify dram_init_banksize() even more as suggested by Daniel

Changes in v4:
- New patch

 common/board_f.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index d1f0f9af08..8a43df97e4 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -237,10 +237,8 @@ static int show_dram_config(void)
 
 __weak int dram_init_banksize(void)
 {
-#if defined(CONFIG_SYS_SDRAM_BASE)
-   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+   gd->bd->bi_dram[0].start = gd->ram_base;
gd->bd->bi_dram[0].size = get_effective_memsize();
-#endif
 
return 0;
 }
@@ -602,9 +600,6 @@ int setup_bdinfo(void)
 {
struct bd_info *bd = gd->bd;
 
-   bd->bi_memstart = gd->ram_base;  /* start of memory */
-   bd->bi_memsize = gd->ram_size;   /* size in bytes */
-
if (IS_ENABLED(CONFIG_SYS_HAS_SRAM)) {
bd->bi_sramstart = CONFIG_SYS_SRAM_BASE; /* start of SRAM */
bd->bi_sramsize = CONFIG_SYS_SRAM_SIZE;  /* size  of SRAM */
-- 
2.28.0

[PATCH v8 05/10] xtensa: Remove arch_setup_bdinfo()

[Stefan Roese]

arch_setup_bdinfo() only configures the deprecated bi_memstart &
bi_memsize values, which should not be needed any more. Lets remove
this file completely.

Signed-off-by: Stefan Roese 
Reviewed-by: Ovidiu Panait 

---

(no changes since v7)

Changes in v7:
- Add Reviewe-by tag from Ovidiu

Changes in v4:
- New patch

 arch/xtensa/lib/Makefile |  2 +-
 arch/xtensa/lib/bdinfo.c | 22 --
 2 files changed, 1 insertion(+), 23 deletions(-)
 delete mode 100644 arch/xtensa/lib/bdinfo.c

diff --git a/arch/xtensa/lib/Makefile b/arch/xtensa/lib/Makefile
index ceee59b9bd..c59df7d372 100644
--- a/arch/xtensa/lib/Makefile
+++ b/arch/xtensa/lib/Makefile
@@ -5,4 +5,4 @@
 
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
 
-obj-y  += cache.o misc.o relocate.o time.o bdinfo.o
+obj-y  += cache.o misc.o relocate.o time.o
diff --git a/arch/xtensa/lib/bdinfo.c b/arch/xtensa/lib/bdinfo.c
deleted file mode 100644
index 4ec8529521..00
--- a/arch/xtensa/lib/bdinfo.c
+++ /dev/null
@@ -1,22 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * XTENSA-specific information for the 'bd' command
- *
- * (C) Copyright 2003
- * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
- */
-
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
-
-int arch_setup_bdinfo(void)
-{
-   struct bd_info *bd = gd->bd;
-
-   bd->bi_memstart = PHYSADDR(CONFIG_SYS_SDRAM_BASE);
-   bd->bi_memsize = CONFIG_SYS_SDRAM_SIZE;
-
-   return 0;
-}
-- 
2.28.0

[PATCH v8 10/10] asm-generic/u-boot.h: Remove bi_memstart & bi_memsize from bd_info

[Stefan Roese]

bi_memstart & bi_memsize are now not referenced any more. This patch
removes their definitions from the bd_info struct.

Signed-off-by: Stefan Roese 
Reviewed-by: Simon Glass 

---

Changes in v8:
- Add Reviewed-by tag from Simon

Changes in v4:
- New patch

 include/asm-generic/u-boot.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/asm-generic/u-boot.h b/include/asm-generic/u-boot.h
index 99d3fe33ad..637de0c455 100644
--- a/include/asm-generic/u-boot.h
+++ b/include/asm-generic/u-boot.h
@@ -27,8 +27,6 @@
 #include 
 
 struct bd_info {
-   unsigned long   bi_memstart;/* start of DRAM memory */
-   phys_size_t bi_memsize; /* size  of DRAM memory in bytes */
unsigned long   bi_flashstart;  /* start of FLASH memory */
unsigned long   bi_flashsize;   /* size  of FLASH memory */
unsigned long   bi_flashoffset; /* reserved area for startup monitor */
-- 
2.28.0

[PATCH v8 02/10] image: Use gd->ram_base/_size in env_get_bootm_size()

[Stefan Roese]

Use only gd->ram_base/_size in env_get_bootm_size() instead of bi_dram[]
in some cases and bi_memstart in others.

Signed-off-by: Stefan Roese 
Reviewed-by: Simon Glass 

---

Changes in v8:
- Add Reviewed-by tag from Simon

Changes in v4:
- New patch

 common/image.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/common/image.c b/common/image.c
index 2ed46f7685..6f68b13fce 100644
--- a/common/image.c
+++ b/common/image.c
@@ -685,13 +685,8 @@ phys_size_t env_get_bootm_size(void)
return tmp;
}
 
-#if defined(CONFIG_ARM) || defined(CONFIG_MICROBLAZE)
-   start = gd->bd->bi_dram[0].start;
-   size = gd->bd->bi_dram[0].size;
-#else
-   start = gd->bd->bi_memstart;
-   size = gd->bd->bi_memsize;
-#endif
+   start = gd->ram_base;
+   size = gd->ram_size;
 
s = env_get("bootm_low");
if (s)
-- 
2.28.0

[PATCH v8 07/10] video: cfb_console.c: Use bi_dram[] values on all platforms

[Stefan Roese]

All platforms support bi_dram[] since quite some time. Lets remove the
and bi_memsize values completely.

Signed-off-by: Stefan Roese 
Reviewed-by: Simon Glass 

---

Changes in v8:
- Add Reviewed-by tag from Simon

Changes in v4:
- New patch

 drivers/video/cfb_console.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index badade353e..3f07f4eb29 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -1983,8 +1983,6 @@ static void *video_logo(void)
 static int cfb_fb_is_in_dram(void)
 {
struct bd_info *bd = gd->bd;
-#if defined(CONFIG_ARM) || defined(CONFIG_NDS32) || \
-defined(CONFIG_SANDBOX) || defined(CONFIG_X86)
ulong start, end;
int i;
 
@@ -1995,11 +1993,7 @@ defined(CONFIG_SANDBOX) || defined(CONFIG_X86)
(ulong)video_fb_address < end)
return 1;
}
-#else
-   if ((ulong)video_fb_address >= bd->bi_memstart &&
-   (ulong)video_fb_address < bd->bi_memstart + bd->bi_memsize)
-   return 1;
-#endif
+
return 0;
 }
 
-- 
2.28.0

[PATCH 1/1] efi_loader: use ':' as separator for setenv -i

[Heinrich Schuchardt]

setenv -e -i , can be used to set a UEFI variable
from memory.

For separating an address and a size we use ':' in most commands.
Let's do the same for setenv -e -i.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/nvedit_efi.c  |  2 +-
 doc/uefi/uefi.rst |  6 +-
 .../py/tests/test_efi_secboot/test_authvar.py | 60 +--
 test/py/tests/test_efi_secboot/test_signed.py | 46 +++---
 .../test_efi_secboot/test_signed_intca.py | 24 
 .../tests/test_efi_secboot/test_unsigned.py   | 18 +++---
 6 files changed, 78 insertions(+), 78 deletions(-)

diff --git a/cmd/nvedit_efi.c b/cmd/nvedit_efi.c
index 8e31f43e1f..094c0e8098 100644
--- a/cmd/nvedit_efi.c
+++ b/cmd/nvedit_efi.c
@@ -473,7 +473,7 @@ int do_env_set_efi(struct cmd_tbl *cmdtp, int flag, int 
argc,
argc--;
argv++;
addr = simple_strtoul(argv[0], &ep, 16);
-   if (*ep != ',')
+   if (*ep != ':')
return CMD_RET_USAGE;

/* 0 should be allowed for delete */
diff --git a/doc/uefi/uefi.rst b/doc/uefi/uefi.rst
index 728f7bf4e0..07eb3f01b4 100644
--- a/doc/uefi/uefi.rst
+++ b/doc/uefi/uefi.rst
@@ -173,11 +173,11 @@ Sign an image with one of the keys in "db" on your host
 Now in U-Boot install the keys on your board::

 fatload mmc 0:1  PK.auth
-setenv -e -nv -bs -rt -at -i ,$filesize PK
+setenv -e -nv -bs -rt -at -i :$filesize PK
 fatload mmc 0:1  KEK.auth
-setenv -e -nv -bs -rt -at -i ,$filesize KEK
+setenv -e -nv -bs -rt -at -i :$filesize KEK
 fatload mmc 0:1  db.auth
-setenv -e -nv -bs -rt -at -i ,$filesize db
+setenv -e -nv -bs -rt -at -i :$filesize db

 Set up boot parameters on your board::

diff --git a/test/py/tests/test_efi_secboot/test_authvar.py 
b/test/py/tests/test_efi_secboot/test_authvar.py
index d0c6b9035b..f99b8270a6 100644
--- a/test/py/tests/test_efi_secboot/test_authvar.py
+++ b/test/py/tests/test_efi_secboot/test_authvar.py
@@ -38,14 +38,14 @@ class TestEfiAuthVar(object):
 # Test Case 1b, PK without AUTHENTICATED_WRITE_ACCESS
 output = u_boot_console.run_command_list([
 'fatload host 0:1 400 PK.auth',
-'setenv -e -nv -bs -rt -i 400,$filesize PK'])
+'setenv -e -nv -bs -rt -i 400:$filesize PK'])
 assert 'Failed to set EFI variable' in ''.join(output)

 with u_boot_console.log.section('Test Case 1c'):
 # Test Case 1c, install PK
 output = u_boot_console.run_command_list([
 'fatload host 0:1 400 PK.auth',
-'setenv -e -nv -bs -rt -at -i 400,$filesize PK',
+'setenv -e -nv -bs -rt -at -i 400:$filesize PK',
 'printenv -e -n PK'])
 assert 'PK:' in ''.join(output)

@@ -60,24 +60,24 @@ class TestEfiAuthVar(object):
 # Test Case 1d, db/dbx without KEK
 output = u_boot_console.run_command_list([
 'fatload host 0:1 400 db.auth',
-'setenv -e -nv -bs -rt -at -i 400,$filesize db'])
+'setenv -e -nv -bs -rt -at -i 400:$filesize db'])
 assert 'Failed to set EFI variable' in ''.join(output)

 output = u_boot_console.run_command_list([
 'fatload host 0:1 400 db.auth',
-'setenv -e -nv -bs -rt -at -i 400,$filesize dbx'])
+'setenv -e -nv -bs -rt -at -i 400:$filesize dbx'])
 assert 'Failed to set EFI variable' in ''.join(output)

 with u_boot_console.log.section('Test Case 1e'):
 # Test Case 1e, install KEK
 output = u_boot_console.run_command_list([
 'fatload host 0:1 400 KEK.auth',
-'setenv -e -nv -bs -rt -i 400,$filesize KEK'])
+'setenv -e -nv -bs -rt -i 400:$filesize KEK'])
 assert 'Failed to set EFI variable' in ''.join(output)

 output = u_boot_console.run_command_list([
 'fatload host 0:1 400 KEK.auth',
-'setenv -e -nv -bs -rt -at -i 400,$filesize KEK',
+'setenv -e -nv -bs -rt -at -i 400:$filesize KEK',
 'printenv -e -n KEK'])
 assert 'KEK:' in ''.join(output)

@@ -89,12 +89,12 @@ class TestEfiAuthVar(object):
 # Test Case 1f, install db
 output = u_boot_console.run_command_list([
 'fatload host 0:1 400 db.auth',
-'setenv -e -nv -bs -rt -i 400,$filesize db'])
+'setenv -e -nv -bs -rt -i 400:$filesize db'])
 assert 'Failed to set EFI variable' in ''.join(output)

 output = u_boot_console.run_command_list([
 'fatload host 0:1 400 db.auth',
-'setenv -e -

[PATCH] arm64: dts: zynqmp: Fix leds subnode name for zcu100/ultra96 v1

[Michal Simek]

Fix the leds subnode names to match (^led-[0-9a-f]$|led).

Similar change has been also done by commit 08dc0e5dd9aa ("arm64: dts:
meson: fix leds subnodes name").

The patch is fixing this warning:
avnet-ultra96-rev1.dt.yaml: leds: 'ds2', 'ds3', 'ds4', 'ds5' do not match
any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+'

Signed-off-by: Michal Simek 
---

vbus-det led is not fixed because it is not LED. It should be likely
handled as gpio hog.
---
 arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts 
b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
index d60110ad8367..2352dc553ba7 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
@@ -56,27 +56,27 @@ sw4 {
 
leds {
compatible = "gpio-leds";
-   ds2 {
+   led-ds2 {
label = "ds2";
gpios = <&gpio 20 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "heartbeat";
};
 
-   ds3 {
+   led-ds3 {
label = "ds3";
gpios = <&gpio 19 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "phy0tx"; /* WLAN tx */
default-state = "off";
};
 
-   ds4 {
+   led-ds4 {
label = "ds4";
gpios = <&gpio 18 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "phy0rx"; /* WLAN rx */
default-state = "off";
};
 
-   ds5 {
+   led-ds5 {
label = "ds5";
gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "bluetooth-power";
-- 
2.28.0

Re: [PATCH 1/7] usb: ehci-mx6: Add powerup_fixup implementation

[Lukasz Majewski]

Hi Peng, Marek

> From: Ye Li 
> 
> When doing port reset, the PR bit of PORTSC1 will be automatically
> cleared by our IP, but standard EHCI needs explicit clear by
> software. The EHCI-HCD driver follow the EHCI specification, so after
> 50ms wait, it clear the PR bit by writting to the PORTSC1 register
> with value loaded before setting PR.
> 
> This sequence is ok for our IP when the delay time is exact. But when
> the timer is slower, some bits like PE, PSPD have been set by
> controller automatically after the PR is automatically cleared. So
> the writing to the PORTSC1 will overwrite these bits set by
> controller. And eventually the driver gets wrong status.
> 
> We implement the powerup_fixup operation which delays 50ms and will
> check the PR until it is cleared by controller. And will update the
> reg value which is written to PORTSC register by EHCI-HCD driver.
> This is much safer than depending on the delay time to be accurate
> and aligining with controller's behaiver.

Is there any plan for a follow up for this patch set?

On my imx6q - kp_tpc70 board I can observe that there are some issues
when trying to read data from USB [*]:

Booting update from usb ...
starting USB...
Bus usb@2184200: USB EHCI 1.00
scanning bus usb@2184200 for devices... 2 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
EHCI timed out on TD - token=0x1f8c80
EHCI timed out on TD - token=0x1f8c80


Peng do you see similar issue when you test it on your iMX8?

The test is very simple - just put on a pendrive a fitImage and
initramfs and try to boot with it. In my case it will hang at least
once per ten attempts.

Note:

[*] - this is a similar issue to one, which I had on the iMX53
controller. However, Marek's patch fixed it on imx53:

"usb: Keep async schedule running only across mass storage xfers"
SHA1: 31232de07ef2bd97ff67625976eecd97eeb1b



> 
> Signed-off-by: Ye Li 
> Signed-off-by: Peng Fan 
> ---
>  drivers/usb/host/ehci-mx6.c | 28 +++-
>  1 file changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> index 5f84c7b91d..e654595683 100644
> --- a/drivers/usb/host/ehci-mx6.c
> +++ b/drivers/usb/host/ehci-mx6.c
> @@ -267,6 +267,25 @@ int usb_phy_mode(int port)
>  }
>  #endif
>  
> +static void ehci_mx6_powerup_fixup(struct ehci_ctrl *ctrl, uint32_t
> *status_reg,
> +uint32_t *reg)
> +{
> + u32 result;
> + int usec = 2000;
> +
> + mdelay(50);
> +
> + do {
> + result = ehci_readl(status_reg);
> + udelay(5);
> + if (!(result & EHCI_PS_PR))
> + break;
> + usec--;
> + } while (usec > 0);
> +
> + *reg = ehci_readl(status_reg);
> +}
> +
>  static void usb_oc_config(int index)
>  {
>  #if defined(CONFIG_MX6)
> @@ -366,6 +385,10 @@ int ehci_mx6_common_init(struct usb_ehci *ehci,
> int index) }
>  
>  #if !CONFIG_IS_ENABLED(DM_USB)
> +static const struct ehci_ops mx6_ehci_ops = {
> + .powerup_fixup  = ehci_mx6_powerup_fixup,
> +};
> +
>  int ehci_hcd_init(int index, enum usb_init_type init,
>   struct ehci_hccr **hccr, struct ehci_hcor **hcor)
>  {
> @@ -394,6 +417,8 @@ int ehci_hcd_init(int index, enum usb_init_type
> init, if (ret)
>   return ret;
>  
> + ehci_set_controller_priv(index, NULL, &mx6_ehci_ops);
> +
>   type = board_usb_phy_mode(index);
>  
>   if (hccr && hcor) {
> @@ -467,7 +492,8 @@ static int mx6_init_after_reset(struct ehci_ctrl
> *dev) }
>  
>  static const struct ehci_ops mx6_ehci_ops = {
> - .init_after_reset = mx6_init_after_reset
> + .powerup_fixup  = ehci_mx6_powerup_fixup,
> + .init_after_reset   = mx6_init_after_reset
>  };
>  
>  static int ehci_usb_phy_mode(struct udevice *dev)




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgp5XWB2upMIf.pgp
Description: OpenPGP digital signature

[PATCH] clk: ccf: Add missing #include to clk-mux.c

[Lukasz Majewski]

After adding custom get_rate helper function it was necessary to include
 to avoid warnings about missing uclass_get_device_by_name.

Signed-off-by: Lukasz Majewski 
---

 drivers/clk/clk-mux.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index ec8017b7d2fc..7a5ee7a45fcc 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.20.1

Re: [PATCH 2/2] configs: odroid-c4: update for HDMI output background & USB keyboard

[Neil Armstrong]

On 14/08/2020 08:25, Anand Moon wrote:
> Enable options SYS_WHITE_ON_BLACK to permit HDMI background
> screen from white to back, also enable USB_KEYBOARD.
> 
> Signed-off-by: Anand Moon 
> ---
>  configs/odroid-c4_defconfig | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/configs/odroid-c4_defconfig b/configs/odroid-c4_defconfig
> index 4d112d3490..50653de638 100644
> --- a/configs/odroid-c4_defconfig
> +++ b/configs/odroid-c4_defconfig
> @@ -49,6 +49,7 @@ CONFIG_USB_XHCI_DWC3=y
>  CONFIG_USB_DWC3=y
>  # CONFIG_USB_DWC3_GADGET is not set
>  CONFIG_USB_DWC3_MESON_G12A=y
> +CONFIG_USB_KEYBOARD=y
>  CONFIG_USB_GADGET=y
>  CONFIG_USB_GADGET_VENDOR_NUM=0x1b8e
>  CONFIG_USB_GADGET_PRODUCT_NUM=0xfada
> @@ -56,6 +57,9 @@ CONFIG_USB_GADGET_DWC2_OTG=y
>  CONFIG_USB_GADGET_DWC2_OTG_PHY_BUS_WIDTH_8=y
>  CONFIG_USB_GADGET_DOWNLOAD=y
>  CONFIG_DM_VIDEO=y
> +# CONFIG_VIDEO_BPP8 is not set
> +# CONFIG_VIDEO_BPP16 is not set
> +CONFIG_SYS_WHITE_ON_BLACK=y
>  CONFIG_VIDEO_MESON=y
>  CONFIG_VIDEO_DT_SIMPLEFB=y
>  CONFIG_OF_LIBFDT_OVERLAY=y
> 

Acked-by: Neil Armstrong 


Applying to u-boot-amlogic

Neil

Re: [PATCH 1/2] configs: odroid-n2: update for HDMI output & USB keyboard

[Neil Armstrong]

On 14/08/2020 08:25, Anand Moon wrote:
> Enable options to permit HDMI output on Odroid-N2 G12B boards.
> Enable VPU Power Domain.
> Enable USB_KEYBOARD.
> 
> Signed-off-by: Anand Moon 
> ---
>  configs/odroid-n2_defconfig | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/configs/odroid-n2_defconfig b/configs/odroid-n2_defconfig
> index 358d1fc630..e8b8da9084 100644
> --- a/configs/odroid-n2_defconfig
> +++ b/configs/odroid-n2_defconfig
> @@ -34,6 +34,8 @@ CONFIG_ETH_DESIGNWARE=y
>  CONFIG_MESON_G12A_USB_PHY=y
>  CONFIG_PINCTRL=y
>  CONFIG_PINCTRL_MESON_G12A=y
> +CONFIG_POWER_DOMAIN=y
> +CONFIG_MESON_EE_POWER_DOMAIN=y
>  CONFIG_DM_REGULATOR=y
>  CONFIG_DM_REGULATOR_FIXED=y
>  CONFIG_DM_RESET=y
> @@ -47,10 +49,17 @@ CONFIG_USB_XHCI_DWC3=y
>  CONFIG_USB_DWC3=y
>  # CONFIG_USB_DWC3_GADGET is not set
>  CONFIG_USB_DWC3_MESON_G12A=y
> +CONFIG_USB_KEYBOARD=y
>  CONFIG_USB_GADGET=y
>  CONFIG_USB_GADGET_VENDOR_NUM=0x1b8e
>  CONFIG_USB_GADGET_PRODUCT_NUM=0xfada
>  CONFIG_USB_GADGET_DWC2_OTG=y
>  CONFIG_USB_GADGET_DWC2_OTG_PHY_BUS_WIDTH_8=y
>  CONFIG_USB_GADGET_DOWNLOAD=y
> +CONFIG_DM_VIDEO=y
> +# CONFIG_VIDEO_BPP8 is not set
> +# CONFIG_VIDEO_BPP16 is not set
> +CONFIG_SYS_WHITE_ON_BLACK=y
> +CONFIG_VIDEO_MESON=y
> +CONFIG_VIDEO_DT_SIMPLEFB=y
>  CONFIG_OF_LIBFDT_OVERLAY=y
> 

Acked-by: Neil Armstrong 


Applying to u-boot-amlogic

Neil

Re: [PATCH v1 06/24] pci: pci-uclass: Add multi entry support for memory regions

[Stefan Roese]

Hi Tom,

On 23.08.20 16:03, Tom Rini wrote:

On Sun, Aug 23, 2020 at 11:41:41AM +0200, Stefan Roese wrote:

Hi Simon,
Hi Tom,

On 22.08.20 17:09, Simon Glass wrote:

Hi Stefan,

On Fri, 14 Aug 2020 at 05:40, Stefan Roese  wrote:


Hi Simon,

On 04.08.20 17:05, Simon Glass wrote:




Changes in v1:
- Change patch subject
- Enhance Kconfig help descrition
- Use if() instead of #if

  drivers/pci/Kconfig  | 10 ++
  drivers/pci/pci-uclass.c |  9 ++---
  2 files changed, 16 insertions(+), 3 deletions(-)


This needs an update to a sandbox test to handle this behaviour.


Okay. But how should I handle all these defconfig changes with regard
to the other patches in this series, introducing multiple new PCI
related Kconfig options. With 3 new Kconfig options, all permutations
would lead to 8 (2 ^ 3) different defconfig files. This does not
scale.

I might be missing something here though - perhaps this is easier to
achieve.


For sandbox, turn on all options and then add a new PCI bus that uses
this functionality. If there are lots of combinations you could add 8
new buses, but I'm hoping that isn't necessary?


If I turn on all new options, sandbox will run with these new options
enabled. I don't know with with implications, as it usually runs with
the "normal" PCI related Kconfig options. Also the "normal" PCI
defconfig (e.g. CONFIG_PCI_REGION_MULTI_ENTRY etc disabled) will not
be tested any more via the sandbox tests. So you get either a test for
the new Kconfig option enabled or disabled this way.

Do you really want me to do this?


So the Kconfig completely changes the implementation of PCI? That
doesn't make it very testable, as you say.

Instead, I think the Kconfig should enable the option, then use one of
three ways to select the option:

- a device tree property (on sandbox particularly)
- compatible string (where the property is not appropriate
- setting a flag in PCI bus (where a driver requires the option be selected)

That way you can write a test for the new feature in sandbox, without
deleting all the other tests.


Coming back to this issue after some time - sorry for the delay.

I'm not sure, if I understand this correctly. Do you suggest that the
driver code (in this case pci-uclass.c) should be extended to support
this (sandbox) testing support?


Not really. I see these things as features that drivers can enable /
disable depending on their needs. If that is correct, then sandbox is
no different form other drivers, except that perhaps it might support
all combinations rather than just one.



If yes, I really think that this is counterproductive. As we added (at
least some of) the Kconfig options explicitly, to not add code to
pci-uclass.c in the "normal case". So adding code to e.g. check a device
tree property or a compatible string would increase the code size again.


How about some flags in struct pci_controller?



If not, I'm still unsure how you would like to test the "normal case",
e.g. with CONFIG_PCI_REGION_MULTI_ENTRY disabled, and with it enabled
without adding more sandbox build targets, with all the Kconfig options
permutations. As the extra code (in pci-uclass) is either included or
not in the sandbox binary.


Kconfig enables and disables the feature by adding the code. But we
can still have a flag to determine whether it is used by a particular
driver. That way we can keep our test coverage.



But after adding one test for the first of these pci-uclass related
patches, I do have a general comment on this. I find it quite complex
and time consuming to add these tests. Don't get me wrong, I agree in
general, that having tests in U-Boot is very good. But enforcing tests
for each and every new feature addition in drivers (layers) like PCI
seems a bit too much to me. For example new features like the "pci:
pci-uclass: Add support for Single-Root I/O Virtualization" would mean
AFAIU, that I need to write some emulation code for such a PCI device
and also some testing driver matching such a device, since we have no
real hardware like this in sandbox. This would result in much more
complex code for this test & emulation compared to the driver change /
extension.


Yes but it is not that hard. There are a few PCI emulation devices in
U-Boot and these form the basis of existing tests. Before this, we
really had no tests for PCI and even the behaviour was largely
undefined. Your ability to convert the regions[] array to a
dynamically allocated array is partly thanks to these tets.



To sum it up, I'm asking if you still think that adding tests for all
those PCI driver extensions is really necessary for upstream acceptance?
What's your opinion on this? Do you understand my position on this?


I don't want to be silly about it, but in general if we add new
features, particularly to core features, I think there should be
tests.


As mentioned before, I agree in general. But we should be not too
strict here IMHO, to enforce new tests for each and every U-Boot