Re: [PATCH] arm: gic-v3-its: Add irq UCLASS_DRIVER
Hi Stefan,
On Thu, Sep 10, 2020 at 10:53 AM Stefan Roese wrote:
>
> Hi Rayagonda,
>
> On 09.09.20 19:15, Rayagonda Kokatanur wrote:
> > Hi Stefan,
> >
> > On Wed, Sep 9, 2020 at 1:57 PM Stefan Roese wrote:
> >>
> >> On 09.09.20 10:14, Priyanka Jain wrote:
> >>> This is required to fix
> >>> "Error binding driver 'gic-v3': -96"
> >>> on lx2160a platforms.
> >>>
> >>> Signed-off-by: Priyanka Jain
> >>> ---
> >>>arch/arm/lib/gic-v3-its.c | 5 +
> >>>1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/arch/arm/lib/gic-v3-its.c b/arch/arm/lib/gic-v3-its.c
> >>> index a1657e3853..6c6b7c430c 100644
> >>> --- a/arch/arm/lib/gic-v3-its.c
> >>> +++ b/arch/arm/lib/gic-v3-its.c
> >>> @@ -208,3 +208,8 @@ U_BOOT_DRIVER(gic_lpi_syscon) = {
> >>>.id = UCLASS_SYSCON,
> >>>.of_match = gic_lpi_syscon_ids,
> >>>};
> >>> +
> >>> +UCLASS_DRIVER(irq) = {
> >>> + .id = UCLASS_IRQ,
> >>> + .name = "irq",
> >>> +};
> >>
> >> I tested this on LX2160 and get this error when booting into Linux:
> >>
> >> Loading Device Tree to 9fff6000, end 9f3e ... OK
> >> gic_v3_its_get_gic_lpi_addr: failed to get gic-lpi-base syscon device
> >>
> >> Starting kernel ...
> >>
> >> [0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
> >>
> >> I did not look closely yet. Any idea whats going wrong here?
> >
> > I added the following patch to use UCLASS_SYSCON to get gic lpi details.
> >
> > commit id - 2ae7adc659f7fca9ea65df4318e5bca2b8274310
> >
> > because the above commit is failing, hence we need this patch.
> > When I tested this I didn't face any issue hence didn't push the above
> > change.
> > In my case it was failing only in the lower uboot version without this
> > patch.
>
> What's the "lower uboot version"?
U-Boot 2020.01 version.
>
> In any case, it's failing now on the lx2160, since no SYSCON device is
> found:
>
> $ git grep "gic-lpi-base"
> arch/arm/lib/gic-v3-its.c: { .compatible = "gic-lpi-base" },
> arch/arm/lib/gic-v3-its.c: .name = "gic-lpi-base",
>
> So no device is providing this compatible in the dts anywhere. Or am I
> missing something?
If you apply this patch it will work.
Please let me know if anything more is required or if this patch is
the not right way to address the issue.
Thank,
Rayagonda
>
> Thanks,
> Stefan
Re: [v4, 00/11] mmc: fsl_esdhc: support eMMC HS200/HS400 modes
Hi, On 9/1/20 5:57 PM, Yangbo Lu wrote: > This patch-set is to support eMMC HS200 and HS400 speed modes for > eSDHC, and enable them on LX2160ARDB board. looks good to me. Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > > CI build link > https://travis-ci.org/github/yangbolu1991/u-boot-test/builds/720875619 > > Changes for v2: > - Added two patches to fix stability issue. > Changes for v3: > - Explained more in commit messages. > - Added HS400 exit code for downgrade. > Changes for v4: > - Checked returning of mmc_hs400_prepare_ddr(). > - Added Reviewed-by. > - Rebased. > > Yangbo Lu (11): > mmc: add a reinit() API > mmc: fsl_esdhc: add a reinit() callback > mmc: fsl_esdhc: support tuning for eMMC HS200 > mmc: fsl_esdhc: clean TBCTL[TB_EN] manually during init > mmc: add a hs400_tuning flag > mmc: add a mmc_hs400_prepare_ddr() interface > mmc: fsl_esdhc: support eMMC HS400 mode > mmc: fsl_esdhc: fix mmc->clock with actual clock > mmc: fsl_esdhc: fix eMMC HS400 stability issue > arm: dts: lx2160ardb: support eMMC HS400 mode > configs: lx2160ardb: enable eMMC HS400 mode support > > arch/arm/dts/fsl-lx2160a-rdb.dts | 2 + > configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 1 + > configs/lx2160ardb_tfa_defconfig | 1 + > configs/lx2160ardb_tfa_stmm_defconfig| 1 + > drivers/mmc/fsl_esdhc.c | 176 > ++- > drivers/mmc/mmc-uclass.c | 30 + > drivers/mmc/mmc.c| 14 ++- > include/fsl_esdhc.h | 29 - > include/mmc.h| 26 +++- > 9 files changed, 270 insertions(+), 10 deletions(-) >
Re: [PATCH] arm: gic-v3-its: Add irq UCLASS_DRIVER
Hi Rayagonda,
On 09.09.20 19:15, Rayagonda Kokatanur wrote:
Hi Stefan,
On Wed, Sep 9, 2020 at 1:57 PM Stefan Roese wrote:
On 09.09.20 10:14, Priyanka Jain wrote:
This is required to fix
"Error binding driver 'gic-v3': -96"
on lx2160a platforms.
Signed-off-by: Priyanka Jain
---
arch/arm/lib/gic-v3-its.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/lib/gic-v3-its.c b/arch/arm/lib/gic-v3-its.c
index a1657e3853..6c6b7c430c 100644
--- a/arch/arm/lib/gic-v3-its.c
+++ b/arch/arm/lib/gic-v3-its.c
@@ -208,3 +208,8 @@ U_BOOT_DRIVER(gic_lpi_syscon) = {
.id = UCLASS_SYSCON,
.of_match = gic_lpi_syscon_ids,
};
+
+UCLASS_DRIVER(irq) = {
+ .id = UCLASS_IRQ,
+ .name = "irq",
+};
I tested this on LX2160 and get this error when booting into Linux:
Loading Device Tree to 9fff6000, end 9f3e ... OK
gic_v3_its_get_gic_lpi_addr: failed to get gic-lpi-base syscon device
Starting kernel ...
[0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
I did not look closely yet. Any idea whats going wrong here?
I added the following patch to use UCLASS_SYSCON to get gic lpi details.
commit id - 2ae7adc659f7fca9ea65df4318e5bca2b8274310
because the above commit is failing, hence we need this patch.
When I tested this I didn't face any issue hence didn't push the above change.
In my case it was failing only in the lower uboot version without this patch.
What's the "lower uboot version"?
In any case, it's failing now on the lx2160, since no SYSCON device is
found:
$ git grep "gic-lpi-base"
arch/arm/lib/gic-v3-its.c: { .compatible = "gic-lpi-base" },
arch/arm/lib/gic-v3-its.c: .name = "gic-lpi-base",
So no device is providing this compatible in the dts anywhere. Or am I
missing something?
Thanks,
Stefan
Re: [PATCH v5] cmd: mem: fix range of bitflip test
On 09.09.20 18:10, Ralph Siemsen wrote:
The bitflip test uses two equal sized memory buffers. This is achieved
by splitting the range of memory into two pieces. The address of the
second buffer, as well as the length of each buffer, were not correctly
calculated. This caused bitflip test to access beyond the end of range.
This patch fixes the pointer arithmetic problem.
A second problem arises because u-boot "mtest" command expects the
ending address to be inclusive. When computing (end - start) this
results in missing 1 byte of the requested length. The bitflip test
expects a count rather than an "ending" address. Thus it fails to test
the last word of the requested range. Fixed by using (end - start + 1).
Added Kconfig option to optionally disable the bitflip test, since it
does add significantly to the time taken for "mtest".
Fixes: 8e434cb705d463bc8cff935160e4fb4c77cb99ab ("cmd: mem: Add bitflip
memory test to alternate mtest")
Signed-off-by: Ralph Siemsen
Reviewed-by: Stefan Roese
Thanks,
Stefan
--
Changes in v5:
- Correct logic for updating error count
Changes in v4:
- Avoid #ifdef in the code
Change-Id: Ie641d04e731fc5bc6a3bbef914bf7fad136cdc94
---
cmd/Kconfig | 12
cmd/mem.c | 21 -
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index d54acf2cfd..275bf7fbfe 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -779,6 +779,18 @@ config SYS_ALT_MEMTEST
help
Use a more complete alternative memory test.
+if SYS_ALT_MEMTEST
+
+config SYS_ALT_MEMTEST_BITFLIP
+ bool "Bitflip test"
+ default y
+ help
+ The alternative memory test includes bitflip test since 2020.07.
+ The bitflip test significantly increases the overall test time.
+ Bitflip test can optionally be disabled here.
+
+endif
+
config SYS_MEMTEST_START
hex "default start address for mtest"
default 0
diff --git a/cmd/mem.c b/cmd/mem.c
index 9b97f7bf69..dc4a0ffab3 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -867,6 +867,18 @@ static ulong test_bitflip_comparison(volatile unsigned
long *bufa,
return errs;
}
+static ulong mem_test_bitflip(vu_long *buf, ulong start, ulong end)
+{
+ /*
+* Split the specified range into two halves.
+* Note that mtest range is inclusive of start,end.
+* Bitflip test instead uses a count (of 32-bit words).
+*/
+ ulong half_size = (end - start + 1) / 2 / sizeof(unsigned long);
+
+ return test_bitflip_comparison(buf, buf + half_size, half_size);
+}
+
static ulong mem_test_quick(vu_long *buf, ulong start_addr, ulong end_addr,
vu_long pattern, int iteration)
{
@@ -986,11 +998,10 @@ static int do_mem_mtest(struct cmd_tbl *cmdtp, int flag,
int argc,
errs = mem_test_alt(buf, start, end, dummy);
if (errs == -1UL)
break;
- count += errs;
- errs = test_bitflip_comparison(buf,
- buf + (end - start) / 2,
- (end - start) /
- sizeof(unsigned long));
+ if (IS_ENABLED(CONFIG_SYS_ALT_MEMTEST_BITFLIP)) {
+ count += errs;
+ errs = mem_test_bitflip(buf, start, end);
+ }
} else {
errs = mem_test_quick(buf, start, end, pattern,
iteration);
Re: [PATCH] ARM: mvebu: clearfog: don't override set fdtfile env
On 09/09/2020 14:14, Baruch Siach wrote:
Only set the fdtfile environment variable when not already set.
Fixes: 867572f09ebe6 ("ARM: mvebu: clearfog: run-time selection of DT file")
Cc: Joel Johnson
Reported-by: Andre Heider
Signed-off-by: Baruch Siach
Reviewed-by: Andre Heider
Re: [PATCH 5/7] riscv: Add fence to available_harts_lock
Hi Sean > Without these fences, it is perfectly valid for an out-of-order core to > re-order memory accesses to outside of the available_harts_lock critical > section. > > Signed-off-by: Sean Anderson > --- > > arch/riscv/cpu/start.S | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S > index e3222b1ea7..ad18e746b6 100644 > --- a/arch/riscv/cpu/start.S > +++ b/arch/riscv/cpu/start.S > @@ -126,12 +126,12 @@ call_board_init_f_0: > #ifndef CONFIG_XIP > la t0, available_harts_lock > fence rw, w > - amoswap.w zero, zero, 0(t0) > + amoswap.w.rl zero, zero, 0(t0) fence rw, w can also be removed. > > wait_for_gd_init: > la t0, available_harts_lock > li t1, 1 > -1: amoswap.w t1, t1, 0(t0) > +1: amoswap.w.aq t1, t1, 0(t0) > fence r, rw fence r, rw can also be removed. > bnezt1, 1b > > @@ -143,7 +143,7 @@ wait_for_gd_init: > SREGt2, GD_AVAILABLE_HARTS(gp) > > fence rw, w fence rw, w can also be removed. Thanks, Rick > - amoswap.w zero, zero, 0(t0) > + amoswap.w.rl zero, zero, 0(t0) > > /* > * Continue on hart lottery winner, others branch to > -- > 2.28.0 >
Re: [PATCH v6 00/17] efi_loader: add capsule update support
On Thu, Sep 10, 2020 at 11:52:37AM +0900, AKASHI Takahiro wrote: > On Wed, Sep 09, 2020 at 12:56:28PM -0400, Tom Rini wrote: > > On Wed, Sep 09, 2020 at 04:48:30PM +0200, Heinrich Schuchardt wrote: > > > On 07.09.20 07:34, AKASHI Takahiro wrote: > > [snip] > > > > required and partly because there is a problem with virt-make-fs. > > > > > > What problem with virt-make-fs exists? How will this be solved? > > > > This I suspect is related to the difficulty of getting tests to run in > > all of our CI environments, where at least in one case they run and > > pass, rather than skip. This will require that the series get run > > through at least Travis and Azure before re-posting, at this point. > > Thanks. > > I think that we discussed this issue several times before. > > https://lists.denx.de/pipermail/u-boot/2020-July/419430.html > https://lists.denx.de/pipermail/u-boot/2020-July/420712.html > > I have not implemented a fallback handling in case of virt-make-fs failure > as Heinrich doesn't like it (even dropped the code from my patches.) > > The only solution is Heinrich's patch: > https://lists.denx.de/pipermail/u-boot/2020-July/419976.html The problem is that Heinrich's patch breaks things. A complete solution is required. That patch might be part of the solution, along with perhaps a rework of the logic to try and gracefully catch and re-try when we have a problem with one of the possible tools. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/17] efi_loader: add capsule update support
On Wed, Sep 09, 2020 at 12:56:28PM -0400, Tom Rini wrote: > On Wed, Sep 09, 2020 at 04:48:30PM +0200, Heinrich Schuchardt wrote: > > On 07.09.20 07:34, AKASHI Takahiro wrote: > [snip] > > > required and partly because there is a problem with virt-make-fs. > > > > What problem with virt-make-fs exists? How will this be solved? > > This I suspect is related to the difficulty of getting tests to run in > all of our CI environments, where at least in one case they run and > pass, rather than skip. This will require that the series get run > through at least Travis and Azure before re-posting, at this point. > Thanks. I think that we discussed this issue several times before. https://lists.denx.de/pipermail/u-boot/2020-July/419430.html https://lists.denx.de/pipermail/u-boot/2020-July/420712.html I have not implemented a fallback handling in case of virt-make-fs failure as Heinrich doesn't like it (even dropped the code from my patches.) The only solution is Heinrich's patch: https://lists.denx.de/pipermail/u-boot/2020-July/419976.html -Takahiro Akashi > -- > Tom
Re: [PATCH v6 00/17] efi_loader: add capsule update support
On Wed, Sep 09, 2020 at 04:48:30PM +0200, Heinrich Schuchardt wrote: > On 07.09.20 07:34, 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 > > > > In this version, the DFU change by Heinrich[2] is, at least temporarily, > > not a prerequisite due to the discussions[3]. > > > > [2] https://lists.denx.de/pipermail/u-boot/2020-July/420950.html > > [3] https://lists.denx.de/pipermail/u-boot/2020-August/424716.html > > The end of the discussion was that the patch is postponed to v2021.01 > like your series. My understanding was that the patch will be deferred until v2021.01 and we need more discussions. Right? > > > > 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 > > Shouldn't the sandbox_defconfig changes be added to your series? I won't hesitate to add them if Simon agrees. Since the current test removed the dependency on ENV_IS_IN_SPI_FLASH which was required in v3 or early, it would be more acceptable. > Is this the correct change: It would be fine. > diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig > index 6e9f029cc9..da82afaa01 100644 > --- a/configs/sandbox_defconfig > +++ b/configs/sandbox_defconfig > @@ -129,6 +129,7 @@ CONFIG_DM_DEMO_SIMPLE=y > CONFIG_DM_DEMO_SHAPE=y > CONFIG_BOARD=y > CONFIG_BOARD_SANDBOX=y > +CONFIG_DFU_SF=y > CONFIG_DMA=y > CONFIG_DMA_CHANNELS=y > CONFIG_SANDBOX_DMA=y > @@ -261,6 +262,10 @@ CONFIG_CMD_DHRYSTONE=y > CONFIG_TPM=y > CONFIG_LZ4=y > CONFIG_ERRNO_STR=y > +CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y > +CONFIG_EFI_CAPSULE_ON_DISK=y > +CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y > +CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y > CONFIG_EFI_SECURE_BOOT=y > CONFIG_TEST_FDTDEC=y > CONFIG_UNIT_TEST=y > > > required and partly because there is a problem with virt-make-fs. > > What problem with virt-make-fs exists? How will this be solved? See my reply to Tom. -Takahiro Akashi > > 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
Re: [PATCH v6 01/17] dfu: rename dfu_tftp_write() to dfu_write_by_name()
On Thu, Sep 10, 2020 at 10:54:18AM +0900, AKASHI Takahiro wrote:
> On Wed, Sep 09, 2020 at 02:30:53PM +0200, Heinrich Schuchardt wrote:
> > On 07.09.20 07:34, AKASHI Takahiro wrote:
> > > This function is essentially independent from tftp, and will also be
> > > utilised in implementing UEFI capsule update in a later commit.
> > > So just give it a more generic name.
> > > In addition, a new configuration option, CONFIG_DFU_ALT, was introduced
> > > so that the file will be compiled with different options, particularly
> > > one added in a later commit.
> > >
> > > Signed-off-by: AKASHI Takahiro
> > > ---
> > > common/update.c | 5 +++--
> > > drivers/dfu/Kconfig | 5 +
> > > drivers/dfu/Makefile | 2 +-
> > > drivers/dfu/{dfu_tftp.c => dfu_alt.c} | 17 --
> > > include/dfu.h | 32 +--
> > > 5 files changed, 40 insertions(+), 21 deletions(-)
> > > rename drivers/dfu/{dfu_tftp.c => dfu_alt.c} (67%)
> > >
> > > diff --git a/common/update.c b/common/update.c
> > > index 36b6b7523d50..39946776d74f 100644
> > > --- a/common/update.c
> > > +++ b/common/update.c
> > > @@ -324,8 +324,9 @@ got_update_file:
> > > }
> > > } else if (fit_image_check_type(fit, noffset,
> > > IH_TYPE_FIRMWARE)) {
> > > - ret = dfu_tftp_write(fit_image_name, update_addr,
> > > - update_size, interface, devstring);
> > > + ret = dfu_write_by_name(fit_image_name, update_addr,
> > > + update_size, interface,
> > > + devstring);
> > > if (ret)
> > > return ret;
> > > }
> > > diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig
> > > index 0eec00ba734d..78f901ff348a 100644
> > > --- a/drivers/dfu/Kconfig
> > > +++ b/drivers/dfu/Kconfig
> > > @@ -14,8 +14,13 @@ config DFU_OVER_TFTP
> > > depends on NET
> > >
> > > if DFU
> > > +config DFU_ALT
> > > + bool
> >
> > You cannot define CONFIG_DFU_ALT as bool. This symbol already exists as
> > string in include/configs/odroid.h, include/configs/s5p_goni.h, et.al.
> > It is used to initialize environment variable dfu_alt_info. Your patch
> > leads to an error on Travis:
> >
> >arm: + odroid
>
> Okay, will fix it.
> DFU_WRITE_ALT? Or, as Heinrich suggested, move them
> to dfu.c if Lukasz agrees.
>
> # I haven't seen any comments from him yet though.
I think what you're introducing as "CONFIG_DFU_ALT" and renaming
"drivers/dfu/dfu_tftp.c" to "drivers/dfu/dfu_alt.c" is what's confusing.
That I think needs a different name than "alt" to convey that it's a
generic "from DRAM to flash/etc" hook.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v6 01/17] dfu: rename dfu_tftp_write() to dfu_write_by_name()
On Wed, Sep 09, 2020 at 02:30:53PM +0200, Heinrich Schuchardt wrote:
> On 07.09.20 07:34, AKASHI Takahiro wrote:
> > This function is essentially independent from tftp, and will also be
> > utilised in implementing UEFI capsule update in a later commit.
> > So just give it a more generic name.
> > In addition, a new configuration option, CONFIG_DFU_ALT, was introduced
> > so that the file will be compiled with different options, particularly
> > one added in a later commit.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > common/update.c | 5 +++--
> > drivers/dfu/Kconfig | 5 +
> > drivers/dfu/Makefile | 2 +-
> > drivers/dfu/{dfu_tftp.c => dfu_alt.c} | 17 --
> > include/dfu.h | 32 +--
> > 5 files changed, 40 insertions(+), 21 deletions(-)
> > rename drivers/dfu/{dfu_tftp.c => dfu_alt.c} (67%)
> >
> > diff --git a/common/update.c b/common/update.c
> > index 36b6b7523d50..39946776d74f 100644
> > --- a/common/update.c
> > +++ b/common/update.c
> > @@ -324,8 +324,9 @@ got_update_file:
> > }
> > } else if (fit_image_check_type(fit, noffset,
> > IH_TYPE_FIRMWARE)) {
> > - ret = dfu_tftp_write(fit_image_name, update_addr,
> > -update_size, interface, devstring);
> > + ret = dfu_write_by_name(fit_image_name, update_addr,
> > + update_size, interface,
> > + devstring);
> > if (ret)
> > return ret;
> > }
> > diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig
> > index 0eec00ba734d..78f901ff348a 100644
> > --- a/drivers/dfu/Kconfig
> > +++ b/drivers/dfu/Kconfig
> > @@ -14,8 +14,13 @@ config DFU_OVER_TFTP
> > depends on NET
> >
> > if DFU
> > +config DFU_ALT
> > + bool
>
> You cannot define CONFIG_DFU_ALT as bool. This symbol already exists as
> string in include/configs/odroid.h, include/configs/s5p_goni.h, et.al.
> It is used to initialize environment variable dfu_alt_info. Your patch
> leads to an error on Travis:
>
>arm: + odroid
Okay, will fix it.
DFU_WRITE_ALT? Or, as Heinrich suggested, move them
to dfu.c if Lukasz agrees.
# I haven't seen any comments from him yet though.
-Takahiro Akashi
> +In file included from :
>
> +include/linux/kconfig.h:21:49: error: pasting "__ARG_PLACEHOLDER_" and
> ""uImage fat 0 1;"" does not give a valid preprocessing token
>
> + 21 | #define _config_enabled(value)
> __config_enabled(__ARG_PLACEHOLDER_##value)
>
> Best regards
>
> Heinrich
>
> > + default n
> > +
> > config DFU_TFTP
> > bool "DFU via TFTP"
> > + select DFU_ALT
> > select DFU_OVER_TFTP
> > help
> > This option allows performing update of DFU-managed medium with data
> > diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
> > index 0d7925c083ef..cc7de1d3ed9b 100644
> > --- a/drivers/dfu/Makefile
> > +++ b/drivers/dfu/Makefile
> > @@ -9,5 +9,5 @@ obj-$(CONFIG_$(SPL_)DFU_MTD) += dfu_mtd.o
> > obj-$(CONFIG_$(SPL_)DFU_NAND) += dfu_nand.o
> > obj-$(CONFIG_$(SPL_)DFU_RAM) += dfu_ram.o
> > obj-$(CONFIG_$(SPL_)DFU_SF) += dfu_sf.o
> > -obj-$(CONFIG_$(SPL_)DFU_TFTP) += dfu_tftp.o
> > +obj-$(CONFIG_$(SPL_)DFU_ALT) += dfu_alt.o
> > obj-$(CONFIG_$(SPL_)DFU_VIRT) += dfu_virt.o
> > diff --git a/drivers/dfu/dfu_tftp.c b/drivers/dfu/dfu_alt.c
> > similarity index 67%
> > rename from drivers/dfu/dfu_tftp.c
> > rename to drivers/dfu/dfu_alt.c
> > index ffae4bb54f80..5b1b13d7170d 100644
> > --- a/drivers/dfu/dfu_tftp.c
> > +++ b/drivers/dfu/dfu_alt.c
> > @@ -10,8 +10,21 @@
> > #include
> > #include
> >
> > -int dfu_tftp_write(char *dfu_entity_name, unsigned int addr, unsigned int
> > len,
> > - char *interface, char *devstring)
> > +/**
> > + * dfu_write_by_name() - write data to DFU medium
> > + * @dfu_entity_name:Name of DFU entity to write
> > + * @addr: Address of data buffer to write
> > + * @len:Number of bytes
> > + * @interface: Destination DFU medium (e.g. "mmc")
> > + * @devstring: Instance number of destination DFU medium (e.g.
> > "1")
> > + *
> > + * This function is storing data received on DFU supported medium which
> > + * is specified by @dfu_entity_name.
> > + *
> > + * Return: 0 - on success, error code - otherwise
> > + */
> > +int dfu_write_by_name(char *dfu_entity_name, unsigned int addr,
> > + unsigned int len, char *interface, char *devstring)
> > {
> > char *s, *sb;
> > int alt_setting_num, ret;
> > diff --git a/include/dfu.h b/include/dfu.h
> > index 84abdc79acd1..cecfbd76597b 100644
> > --- a/include/dfu.h
> > +++ b/include/dfu.h
> > @@ -494,27 +494,27 @@ static inline int dfu_fill_entity_virt(struct
> >
[PATCH] mmc: stm32_sdmmc2: Use mmc_of_parse() to read host capabilities
mmc_of_parse() can populate the 'f_max' and 'host_caps' fields of
struct mmc_config from devicetree.
The same logic is duplicated in stm32_sdmmc2_probe(). Use
mmc_of_parse(), which is more generic.
Signed-off-by: Alexandru Gagniuc
---
drivers/mmc/stm32_sdmmc2.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
index 6d50356217..77871d5afc 100644
--- a/drivers/mmc/stm32_sdmmc2.c
+++ b/drivers/mmc/stm32_sdmmc2.c
@@ -676,27 +676,13 @@ static int stm32_sdmmc2_probe(struct udevice *dev)
GPIOD_IS_IN);
cfg->f_min = 40;
- cfg->f_max = dev_read_u32_default(dev, "max-frequency", 5200);
cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
cfg->name = "STM32 SD/MMC";
cfg->host_caps = 0;
- if (cfg->f_max > 2500)
- cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
-
- switch (dev_read_u32_default(dev, "bus-width", 1)) {
- case 8:
- cfg->host_caps |= MMC_MODE_8BIT;
- /* fall through */
- case 4:
- cfg->host_caps |= MMC_MODE_4BIT;
- break;
- case 1:
- break;
- default:
- pr_err("invalid \"bus-width\" property, force to 1\n");
- }
+ cfg->f_max = 5200;
+ mmc_of_parse(dev, cfg);
upriv->mmc = >mmc;
--
2.25.4
Re: [PATCH 1/1] lib: rsa: fix data abort in br_i32_decode()
On Tue, Sep 08, 2020 at 05:56:06PM -0600, Simon Glass wrote:
> HI Heinrich,
>
> On Tue, 8 Sep 2020 at 04:29, Heinrich Schuchardt wrote:
> >
> > After removing leading zeros the RSA modulus may be unaligned. On
> > architectures like ARM 32bit unaligned access may lead to a data abort,
> > e.g. when executing 'ut lib lib_asn1_pkcs7'.
> >
> > Use memcpy() to transfer from unaligned to aligned memory.
> >
> > Signed-off-by: Heinrich Schuchardt
> > ---
> > lib/rsa/rsa-keyprop.c | 22 ++
> > 1 file changed, 14 insertions(+), 8 deletions(-)
>
> Reviewed-by: Simon Glass
>
> >
> > diff --git a/lib/rsa/rsa-keyprop.c b/lib/rsa/rsa-keyprop.c
> > index 1e83eedc82..6153cb00b3 100644
> > --- a/lib/rsa/rsa-keyprop.c
> > +++ b/lib/rsa/rsa-keyprop.c
> > @@ -17,23 +17,29 @@
> > #include
> >
> > /**
> > - * br_dec16be() - Convert 16-bit big-endian integer to native
> > - * @src: Pointer to data
> > - * Return: Native-endian integer
> > + * br_dec16be() - convert unaligned 16-bit big-endian integer to native
> > + * @src: unaligned pointer to data
> > + * Return: native-endian 16-bit integer
> > */
> > static unsigned br_dec16be(const void *src)
> > {
> > - return be16_to_cpup(src);
> > + u16 buf;
> > +
> > + memcpy(, src, sizeof(buf));
> > + return be16_to_cpu(buf);
>
> Is it possible to use __get_unaligned_be() ?
Robert has sent the fix here:
https://lists.denx.de/pipermail/u-boot/2020-September/425949.html
I think it's better.
-Takahiro Akashi
> Regards,
> Simon
[PATCH v4 6/7] riscv: Add watchdog bindings for the k210
This adds the necessary bindings. Most of them are already there.
Signed-off-by: Sean Anderson
Acked-by: Rick Chen
---
(no changes since v2)
Changes in v2:
- Move watchdog enable to k210.dtsi as it does not depend on anything
board-specific.
arch/riscv/dts/k210.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
index 84cff51c36..81ac417dde 100644
--- a/arch/riscv/dts/k210.dtsi
+++ b/arch/riscv/dts/k210.dtsi
@@ -426,7 +426,6 @@
interrupts = <21>;
clocks = < K210_CLK_WDT0>;
resets = < K210_RST_WDT0>;
- status = "disabled";
};
wdt1: watchdog@5041 {
--
2.28.0
[PATCH v4 7/7] riscv: Enable watchdog for the k210
This enables the necessary config options. Signed-off-by: Sean Anderson Reviewed-by: Simon Glass --- (no changes since v3) Changes in v3: - Note dependency on "time: Fix get_ticks being non-monotonic" - Add a few signed-off-bys which were sent for version 1 board/sipeed/maix/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/sipeed/maix/Kconfig b/board/sipeed/maix/Kconfig index 0cdcd32adc..b9dac5a64e 100644 --- a/board/sipeed/maix/Kconfig +++ b/board/sipeed/maix/Kconfig @@ -44,4 +44,6 @@ config BOARD_SPECIFIC_OPTIONS imply RESET_SYSCON imply SYSRESET imply SYSRESET_SYSCON + imply WDT + imply DESIGNWARE_WATCHDOG endif -- 2.28.0
[PATCH v4 5/7] wdt: dw: Free the clock on error
The clock subsystem requires that clk_free be called on clocks obtained via
clk_get_*.
Signed-off-by: Sean Anderson
Reviewed-by: Simon Glass
---
Changes in v4:
- Fix build error without CONFIG_CLK
drivers/watchdog/designware_wdt.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/designware_wdt.c
b/drivers/watchdog/designware_wdt.c
index e6f5437056..b952737fb4 100644
--- a/drivers/watchdog/designware_wdt.c
+++ b/drivers/watchdog/designware_wdt.c
@@ -131,11 +131,13 @@ static int designware_wdt_probe(struct udevice *dev)
ret = clk_enable();
if (ret)
- return ret;
+ goto err;
priv->clk_khz = clk_get_rate() / 1000;
- if (!priv->clk_khz)
- return -EINVAL;
+ if (!priv->clk_khz) {
+ ret = -EINVAL;
+ goto err;
+ }
#else
priv->clk_khz = CONFIG_DW_WDT_CLOCK_KHZ;
#endif
@@ -145,15 +147,21 @@ static int designware_wdt_probe(struct udevice *dev)
ret = reset_get_bulk(dev, );
if (ret)
- return ret;
+ goto err;
ret = reset_deassert_bulk();
if (ret)
- return ret;
+ goto err;
}
/* reset to disable the watchdog */
return designware_wdt_stop(dev);
+
+err:
+#if CONFIG_IS_ENABLED(CLK)
+ clk_free();
+#endif
+ return ret;
}
static const struct wdt_ops designware_wdt_ops = {
--
2.28.0
[PATCH v4 4/7] wdt: dw: Enable the clock before using it
The watchdog won't work if the clock isn't enabled. Fixes: cf89ef8d10f240554541c20b2e1bdcdd58d1d7e6 Signed-off-by: Sean Anderson Reviewed-by: Simon Glass --- (no changes since v1) drivers/watchdog/designware_wdt.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/watchdog/designware_wdt.c b/drivers/watchdog/designware_wdt.c index 41866fa01b..e6f5437056 100644 --- a/drivers/watchdog/designware_wdt.c +++ b/drivers/watchdog/designware_wdt.c @@ -129,6 +129,10 @@ static int designware_wdt_probe(struct udevice *dev) if (ret) return ret; + ret = clk_enable(); + if (ret) + return ret; + priv->clk_khz = clk_get_rate() / 1000; if (!priv->clk_khz) return -EINVAL; -- 2.28.0
[PATCH v4 3/7] wdt: dw: Fix clock rate being off by 1000
The clock subsystem returns clock rates in Hz. We need to divide by 1000 so the rate is in kHz. Fixes: cf89ef8d10f240554541c20b2e1bdcdd58d1d7e6 Signed-off-by: Sean Anderson Reviewed-by: Simon Glass --- (no changes since v1) drivers/watchdog/designware_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/designware_wdt.c b/drivers/watchdog/designware_wdt.c index 49cf861d46..41866fa01b 100644 --- a/drivers/watchdog/designware_wdt.c +++ b/drivers/watchdog/designware_wdt.c @@ -129,7 +129,7 @@ static int designware_wdt_probe(struct udevice *dev) if (ret) return ret; - priv->clk_khz = clk_get_rate(); + priv->clk_khz = clk_get_rate() / 1000; if (!priv->clk_khz) return -EINVAL; #else -- 2.28.0
[PATCH v4 1/7] wdt: dw: Switch to using fls for log2
log_2_n_round_up is only found in arm. fls performs the same job and is generic. Signed-off-by: Sean Anderson Reviewed-by: Simon Glass --- (no changes since v2) Changes in v2: - Fix fls being off-by-one when compared to log_2_n_round_up drivers/watchdog/designware_wdt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/watchdog/designware_wdt.c b/drivers/watchdog/designware_wdt.c index 12f09a7a39..f25c8d9ab3 100644 --- a/drivers/watchdog/designware_wdt.c +++ b/drivers/watchdog/designware_wdt.c @@ -9,7 +9,6 @@ #include #include #include -#include #include #define DW_WDT_CR 0x00 @@ -35,7 +34,7 @@ static int designware_wdt_settimeout(void __iomem *base, unsigned int clk_khz, signed int i; /* calculate the timeout range value */ - i = log_2_n_round_up(timeout * clk_khz) - 16; + i = fls(timeout * clk_khz - 1) - 16; i = clamp(i, 0, 15); writel(i | (i << 4), base + DW_WDT_TORR); -- 2.28.0
[PATCH v4 2/7] wdt: dw: Switch to if(CONFIG()) instead of using #if
This is preferred over #if because the compiler can check syntax even if
the feature is disabled. This cannot be used for CONFIG_CLK because
CONFIG_DW_WDT_CLOCK_KHZ is not defined on all platforms.
Signed-off-by: Sean Anderson
Reviewed-by: Heinrich Schuchardt
---
(no changes since v1)
drivers/watchdog/designware_wdt.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/watchdog/designware_wdt.c
b/drivers/watchdog/designware_wdt.c
index f25c8d9ab3..49cf861d46 100644
--- a/drivers/watchdog/designware_wdt.c
+++ b/drivers/watchdog/designware_wdt.c
@@ -136,17 +136,17 @@ static int designware_wdt_probe(struct udevice *dev)
priv->clk_khz = CONFIG_DW_WDT_CLOCK_KHZ;
#endif
-#if CONFIG_IS_ENABLED(DM_RESET)
- struct reset_ctl_bulk resets;
+ if (CONFIG_IS_ENABLED(DM_RESET)) {
+ struct reset_ctl_bulk resets;
- ret = reset_get_bulk(dev, );
- if (ret)
- return ret;
+ ret = reset_get_bulk(dev, );
+ if (ret)
+ return ret;
- ret = reset_deassert_bulk();
- if (ret)
- return ret;
-#endif
+ ret = reset_deassert_bulk();
+ if (ret)
+ return ret;
+ }
/* reset to disable the watchdog */
return designware_wdt_stop(dev);
--
2.28.0
[PATCH v4 0/7] wdt: Add support for watchdogs on Kendryte K210
This series depends on https://patchwork.ozlabs.org/project/uboot/list/?series=200642 Changes in v4: - Fix build error without CONFIG_CLK Changes in v3: - Note dependency on "time: Fix get_ticks being non-monotonic" - Add a few signed-off-bys which were sent for version 1 Changes in v2: - Fix fls being off-by-one when compared to log_2_n_round_up - Move watchdog enable to k210.dtsi as it does not depend on anything board-specific. Sean Anderson (7): wdt: dw: Switch to using fls for log2 wdt: dw: Switch to if(CONFIG()) instead of using #if wdt: dw: Fix clock rate being off by 1000 wdt: dw: Enable the clock before using it wdt: dw: Free the clock on error riscv: Add watchdog bindings for the k210 riscv: Enable watchdog for the k210 arch/riscv/dts/k210.dtsi | 1 - board/sipeed/maix/Kconfig | 2 ++ drivers/watchdog/designware_wdt.c | 39 --- 3 files changed, 27 insertions(+), 15 deletions(-) -- 2.28.0
Re: [PATCH v3 5/7] wdt: dw: Free the clock on error
On 9/1/20 4:07 PM, Sean Anderson wrote:
> The clock subsystem requires that clk_free be called on clocks obtained via
> clk_get_*.
>
> Signed-off-by: Sean Anderson
> Reviewed-by: Simon Glass
> ---
>
> (no changes since v1)
>
> drivers/watchdog/designware_wdt.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/watchdog/designware_wdt.c
> b/drivers/watchdog/designware_wdt.c
> index e6f5437056..189d555f29 100644
> --- a/drivers/watchdog/designware_wdt.c
> +++ b/drivers/watchdog/designware_wdt.c
> @@ -131,11 +131,13 @@ static int designware_wdt_probe(struct udevice *dev)
>
> ret = clk_enable();
> if (ret)
> - return ret;
> + goto err;
>
> priv->clk_khz = clk_get_rate() / 1000;
> - if (!priv->clk_khz)
> - return -EINVAL;
> + if (!priv->clk_khz) {
> + ret = -EINVAL;
> + goto err;
> + }
> #else
> priv->clk_khz = CONFIG_DW_WDT_CLOCK_KHZ;
> #endif
> @@ -145,15 +147,20 @@ static int designware_wdt_probe(struct udevice *dev)
>
> ret = reset_get_bulk(dev, );
> if (ret)
> - return ret;
> + goto err;
>
> ret = reset_deassert_bulk();
> if (ret)
> - return ret;
> + goto err;
> }
>
> /* reset to disable the watchdog */
> return designware_wdt_stop(dev);
> +
> +err:
> + if (CONFIG_IS_ENABLED(CLK))
This should be an #if. Found by running CI at
https://dev.azure.com/seanga2/u-boot/_build/results?buildId=26=logs=673723c4-497f-506b-4750-995fcb7877b8=673723c4-497f-506b-4750-995fcb7877b8=b5278753-2bf3-55ba-a142-eaf3481f5b3e
Will be fixed in v4.
--Sean
> + clk_free();
> + return ret;
> }
>
> static const struct wdt_ops designware_wdt_ops = {
>
Re: [PATCH] clk: Unconditionally recursively en-/dis-able clocks
On 6/24/20 6:47 AM, Sean Anderson wrote: > For clocks not in the CCF, their parents will not have UCLASS_CLK, so we > just enable them as normal. The enable count is local to the struct clk, > but this will never result in the actual en-/dis-able op being called > (unless the same struct clk is enabled twice). > > For clocks in the CCF, we always traverse up the tree when enabling. > Previously, CCF clocks without id set would be skipped, stopping the > traversal too early. > > Signed-off-by: Sean Anderson > --- > This patch was previously part of [1] > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=178480 > > drivers/clk/clk-uclass.c | 60 ++-- > 1 file changed, 27 insertions(+), 33 deletions(-) Hi Lukas, can you have a look at this? --Sean
Re: [PATCH] clk: Add more information to debug messages
On 6/30/20 5:55 AM, Sean Anderson wrote:
> On 3/20/20 3:10 AM, Lukasz Majewski wrote:
>> On Fri, 20 Mar 2020 01:53:16 -0400
>> Sean Anderson wrote:
>>
>>> Some of the debug messages in the clock subsystem can be made more
>>> informative by adding the clock name or adding the explicit error.
>>>
>>> Signed-off-by: Sean Anderson
>>> ---
>>>
>>> drivers/clk/clk-uclass.c | 24 +---
>>> 1 file changed, 13 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
>>> index 71878474eb..d44df05680 100644
>>> --- a/drivers/clk/clk-uclass.c
>>> +++ b/drivers/clk/clk-uclass.c
>>> @@ -237,8 +237,8 @@ static int clk_set_default_parents(struct udevice
>>> *dev, int stage) continue;
>>>
>>> if (ret < 0) {
>>> - debug("%s: failed to reparent clock %d for
>>> %s\n",
>>> - __func__, index, dev_read_name(dev));
>>> + debug("%s: failed to reparent clock %d for
>>> %s (err = %d)\n",
>>> + __func__, index, dev_read_name(dev),
>>> ret); return ret;
>>> }
>>> }
>>> @@ -295,8 +295,8 @@ static int clk_set_default_rates(struct udevice
>>> *dev, int stage) ret = clk_set_rate(, rates[index]);
>>>
>>> if (ret < 0) {
>>> - debug("%s: failed to set rate on clock index
>>> %d (%ld) for %s\n",
>>> - __func__, index, clk.id,
>>> dev_read_name(dev));
>>> + debug("%s: failed to set rate on clock index
>>> %d (%ld) for %s (err = %d)\n",
>>> + __func__, index, clk.id,
>>> dev_read_name(dev), ret); break;
>>> }
>>> }
>>> @@ -436,7 +436,7 @@ ulong clk_get_rate(struct clk *clk)
>>> {
>>> const struct clk_ops *ops;
>>>
>>> - debug("%s(clk=%p)\n", __func__, clk);
>>> + debug("%s(clk=%p \"%s\")\n", __func__, clk, clk->dev->name);
>>> if (!clk_valid(clk))
>>> return 0;
>>> ops = clk_dev_ops(clk->dev);
>>> @@ -452,7 +452,7 @@ struct clk *clk_get_parent(struct clk *clk)
>>> struct udevice *pdev;
>>> struct clk *pclk;
>>>
>>> - debug("%s(clk=%p)\n", __func__, clk);
>>> + debug("%s(clk=%p) \"%s\"\n", __func__, clk, clk->dev->name);
>>> if (!clk_valid(clk))
>>> return NULL;
>>>
>>> @@ -469,7 +469,7 @@ long long clk_get_parent_rate(struct clk *clk)
>>> const struct clk_ops *ops;
>>> struct clk *pclk;
>>>
>>> - debug("%s(clk=%p)\n", __func__, clk);
>>> + debug("%s(clk=%p \"%s\")\n", __func__, clk, clk->dev->name);
>>> if (!clk_valid(clk))
>>> return 0;
>>>
>>> @@ -492,7 +492,8 @@ ulong clk_set_rate(struct clk *clk, ulong rate)
>>> {
>>> const struct clk_ops *ops;
>>>
>>> - debug("%s(clk=%p, rate=%lu)\n", __func__, clk, rate);
>>> + debug("%s(clk=%p \"%s\", rate=%lu)\n", __func__, clk,
>>> clk->dev->name,
>>> + rate);
>>> if (!clk_valid(clk))
>>> return 0;
>>> ops = clk_dev_ops(clk->dev);
>>> @@ -507,7 +508,8 @@ int clk_set_parent(struct clk *clk, struct clk
>>> *parent) {
>>> const struct clk_ops *ops;
>>>
>>> - debug("%s(clk=%p, parent=%p)\n", __func__, clk, parent);
>>> + debug("%s(clk=%p \"%s\", parent=%p \"%s\")\n", __func__, clk,
>>> + clk->dev->name, parent, parent->dev->name);
>>> if (!clk_valid(clk))
>>> return 0;
>>> ops = clk_dev_ops(clk->dev);
>>> @@ -524,7 +526,7 @@ int clk_enable(struct clk *clk)
>>> struct clk *clkp = NULL;
>>> int ret;
>>>
>>> - debug("%s(clk=%p)\n", __func__, clk);
>>> + debug("%s(clk=%p \"%s\")\n", __func__, clk, clk->dev->name);
>>> if (!clk_valid(clk))
>>> return 0;
>>> ops = clk_dev_ops(clk->dev);
>>> @@ -584,7 +586,7 @@ int clk_disable(struct clk *clk)
>>> struct clk *clkp = NULL;
>>> int ret;
>>>
>>> - debug("%s(clk=%p)\n", __func__, clk);
>>> + debug("%s(clk=%p) \"%s\"\n", __func__, clk, clk->dev->name);
>>> if (!clk_valid(clk))
>>> return 0;
>>> ops = clk_dev_ops(clk->dev);
>>
>> Acked-by: Lukasz Majewski
>>
>>
>> Best regards,
>>
>> Lukasz Majewski
>
> *bump*
>
> Is anything going to come of this?
Second *bump*. It looks like this is not going to end up in the clock
tree. Can anyone else pick this up? Thanks.
--Sean
Re: [PATCH v3 0/7] wdt: Add support for watchdogs on Kendryte K210
On 9/1/20 4:07 PM, Sean Anderson wrote: > This series depends on > https://patchwork.ozlabs.org/project/uboot/patch/20200901195548.542737-1-sean...@gmail.com/ A note for those following along at home: after further investigation, this series depends on [1]. It works with v1 of the above patch (as linked), but if one applies v2 [2], it will panic without [1]. [1] https://patchwork.ozlabs.org/project/uboot/list/?series=200642 [2] https://patchwork.ozlabs.org/project/uboot/list/?series=200645 > > Changes in v3: > - Note dependency on "time: Fix get_ticks being non-monotonic" > - Add a few signed-off-bys which were sent for version 1 > > Changes in v2: > - Fix fls being off-by-one when compared to log_2_n_round_up > - Move watchdog enable to k210.dtsi as it does not depend on anything > board-specific. > > Sean Anderson (7): > wdt: dw: Switch to using fls for log2 > wdt: dw: Switch to if(CONFIG()) instead of using #if > wdt: dw: Fix clock rate being off by 1000 > wdt: dw: Enable the clock before using it > wdt: dw: Free the clock on error > riscv: Add watchdog bindings for the k210 > riscv: Enable watchdog for the k210 > > arch/riscv/dts/k210.dtsi | 1 - > board/sipeed/maix/Kconfig | 2 ++ > drivers/watchdog/designware_wdt.c | 38 +++ > 3 files changed, 26 insertions(+), 15 deletions(-) >
Re: [PATCH v4 2/3] binman: Support help messages for missing blobs
On 09/09/2020 02:56, Simon Glass wrote:
> On Tue, 8 Sep 2020 at 10:37, Alper Nebi Yasak
> wrote:
>>
>> result = {}
>> tag = None
>> for line in my_data.decode('utf-8').splitlines():
>> m_tag = re_tag.match(line)
>> if line.startswith('#'):
>> continue
>> elif m_tag:
>> tag = m_tag.group(1)
>> result[tag] = []
>> elif tag:
>> result[tag].append(line)
>> for tag, lines in result.items():
>> result[tag] = "".join(lines).rstrip()
>> return result
>>
>
> Yes that is easier, thank you. I'll use this in v4 and perhaps you can
> reply with your sign-off.
The code fragment above is:
Signed-off-by: Alper Nebi Yasak
Re: [PATCH v4 1/3] binman: Allow selecting default FIT configuration
On 09/09/2020 02:56, Simon Glass wrote:
> On Tue, 8 Sep 2020 at 11:33, Alper Nebi Yasak
> wrote:
>> I might be too late to say this but the SEQ thing looks ugly to me.
>> Maybe there could be some generic control-flow-like nodes that could
>> generate and insert things in their own place. If it makes sense, I'm
>> imagining something like:
>>
>> fit {
>> images {
>> __for__ {
>> for,variable = "name";
>> for,in-args = "of-list";
>>
>> fdt-#name {
>> description = "fdt-$name.dtb";
>> type = "flat_dt";
>> compression = "none";
>> };
>> };
>> };
>>
>> configurations {
>> __for__ {
>> for,variable = "name"
>> for,in-args = "of-list";
>>
>> __if__ {
>> if,arg-equals = "default-dt", "$name";
>> default = "config-#name";
>> };
>>
>> config-#name {
>> description = "conf-$name.dtb";
>> fdt = "fdt-#name";
>> };
>> };
>> };
>> };
>
> I certainly like the flexibility of this and I fiddled with something
> similar (without the __if__ as I didn't have 'default support) before
> going with a hard-coded approach. I agree what I have is ugly and I'm
> pleased to get some feedback.
>
> I think we could use _for instead of __for__.
That works too, I just wanted it to feel very out-of-place as a node
name and that was the first thing to pop into my mind.
> For $name I avoided that because it only works if there is a
> non-character afterwards, e.g. $namex is ambiguous. I briefly played
> with ${name} and {name} but ended up with the ugly capitals.
I was thinking that it'd only substitute the thing in "for,variable" so
it wouldn't be ambiguous, but indeed ${name} is better.
> The biggest question in my mind is whether we want our device-tree
> templates to be turing-complete. It seems nice but I feel that what
> you have above is much harder to understand and get right.
That's true. At least, better to put it off until it's needed in other
places and then attempt a proper design. I'm not sure that something
like this has to be turing-complete to be useful, though it could easily
end up turing-complete by accident.
[PATCH v2] time: Fix get_ticks being non-monotonic
get_ticks does not always succeed. Sometimes it can be called before the
timer has been initialized. If it does, it returns a negative errno.
This causes the timer to appear non-monotonic, because the value will
become much smaller after the timer is initialized.
No users of get_ticks which I checked handle errors of this kind. Further,
functions like tick_to_time mangle the result of get_ticks, making it very
unlikely that one could check for an error without suggesting a patch such
as this one.
This patch panics if we ever get an error. There are two cases in which
this can occur. The first is if we couldn't find/probe the timer for some
reason. One reason for this is if the timer is not available so early. This
likely indicates misconfiguration. Another reason is that the timer has an
invalid/missing device tree binding. In this case, panicing is also
correct. The second case covers errors calling get_count. This can only
occur if the timer is missing a get_count function (or on RISC-V, but that
should be fixed soon).
Fixes: c8a7ba9e6a5
Signed-off-by: Sean Anderson
---
Changes in v2:
- Panic on error
lib/time.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/time.c b/lib/time.c
index 47f8c84327..88bc50405f 100644
--- a/lib/time.c
+++ b/lib/time.c
@@ -91,13 +91,13 @@ uint64_t notrace get_ticks(void)
ret = dm_timer_init();
if (ret)
- return ret;
+ panic("Could not initialize timer (err %d)\n", ret);
#endif
}
ret = timer_get_count(gd->timer, );
if (ret)
- return ret;
+ panic("Could not read count from timer (err %d)\n", ret);
return count;
}
--
2.28.0
[PATCH v4 7/8] riscv: Update Kendryte device tree for new CLINT driver
The interrupt controller property is removed from the clint binding because
the clint is not an interrupt-controller. That is, no other devices have an
interrupt which is controlled by the clint.
Signed-off-by: Sean Anderson
---
Changes in v4:
- Remove clock-frequency property from k210 clint binding because we fall
back on timebase-frequency
Changes in v2:
- New
arch/riscv/dts/k210.dtsi | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
index 2546c7d4e0..84cff51c36 100644
--- a/arch/riscv/dts/k210.dtsi
+++ b/arch/riscv/dts/k210.dtsi
@@ -17,6 +17,8 @@
compatible = "kendryte,k210";
aliases {
+ cpu0 =
+ cpu1 =
dma0 =
gpio0 =
gpio1 = _0;
@@ -126,14 +128,13 @@
read-only;
};
- clint0: interrupt-controller@200 {
+ clint0: clint@200 {
#interrupt-cells = <1>;
compatible = "kendryte,k210-clint", "riscv,clint0";
reg = <0x200 0xC000>;
- interrupt-controller;
interrupts-extended = <_intc 3>, <_intc 7>,
<_intc 3>, <_intc 7>;
- clocks = < K210_CLK_CPU>;
+ clocks = < K210_CLK_CLINT>;
};
plic0: interrupt-controller@C00 {
--
2.28.0
[PATCH v4 8/8] riscv: Update SiFive device tree for new CLINT driver
We currently do this in a u-boot specific dts, but hopefully we can get
these bindings added in Linux in the future.
Signed-off-by: Sean Anderson
Reviewed-by: Pragnesh Patel
---
This patch builds but has NOT been tested.
Changes in v4:
- Both the Andes PMLT and Sifive CLINT now fall back on timebase-frequency,
per discussion with Anup Patel
- Rebase
Changes in v3:
- Rebase
Changes in v2:
- Fix SiFive CLINT not getting tick-rate from rtcclk
arch/riscv/dts/fu540-c000-u-boot.dtsi | 8 ++--
arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 4
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
b/arch/riscv/dts/fu540-c000-u-boot.dtsi
index 5302677ee4..a06e1b11c6 100644
--- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
+++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
@@ -55,9 +55,13 @@
reg = <0x0 0x1007 0x0 0x1000>;
fuse-count = <0x1000>;
};
- clint@200 {
+ clint: clint@200 {
compatible = "riscv,clint0";
- interrupts-extended = <_intc 3 _intc 7
_intc 3 _intc 7 _intc 3 _intc 7 _intc 3 _intc 7
_intc 3 _intc 7>;
+ interrupts-extended = <_intc 3 _intc 7
+ _intc 3 _intc 7
+ _intc 3 _intc 7
+ _intc 3 _intc 7
+ _intc 3 _intc 7>;
reg = <0x0 0x200 0x0 0xc>;
u-boot,dm-spl;
};
diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
index 5d0c928b29..1996149c95 100644
--- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
+++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
@@ -34,6 +34,10 @@
};
+ {
+ clocks = <>;
+};
+
{
u-boot,dm-spl;
--
2.28.0
[PATCH v4 1/8] riscv: Rework riscv timer driver to only support S-mode
The riscv-timer driver currently serves as a shim for several riscv timer
drivers. This is not too desirable because it bypasses the usual timer
selection via the driver model. There is no easy way to specify an
alternate timing driver, or have the tick rate depend on the cpu's
configured frequency. The timer drivers also do not have device structs,
and so have to rely on storing parameters in gd_t. Lastly, there is no
initialization call, so driver init is done in the same function which
reads the time. This can result in confusing error messages. To a user, it
looks like the driver failed when trying to read the time, whereas it may
have failed while initializing.
This patch removes the shim functionality from the riscv-timer driver, and
has it instead implement the former rdtime.c timer driver. This is because
existing u-boot users who pass in a device tree (e.g. qemu) do not create a
timer device for S-mode u-boot. The existing behavior of creating the
riscv-timer device in the riscv cpu driver must be kept. The actual reading
of the CSRs has been redone in the style of Linux's get_cycles64.
Signed-off-by: Sean Anderson
Reviewed-by: Bin Meng
---
Changes in v4:
- Modify RISCV_TIMER KConfig
- Now depends on RISCV
- Implied by S-Mode (with or without SPL)
Changes in v2:
- Remove RISCV_RDTIME KConfig option
arch/riscv/Kconfig | 8 ---
arch/riscv/cpu/ax25/Kconfig| 2 +-
arch/riscv/cpu/fu540/Kconfig | 2 +-
arch/riscv/cpu/generic/Kconfig | 2 +-
arch/riscv/lib/Makefile| 1 -
arch/riscv/lib/rdtime.c| 38 -
drivers/timer/Kconfig | 4 ++--
drivers/timer/riscv_timer.c| 39 +-
8 files changed, 25 insertions(+), 71 deletions(-)
delete mode 100644 arch/riscv/lib/rdtime.c
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 009a545fcf..21e6690f4d 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -185,14 +185,6 @@ config ANDES_PLMT
The Andes PLMT block holds memory-mapped mtime register
associated with timer tick.
-config RISCV_RDTIME
- bool
- default y if RISCV_SMODE || SPL_RISCV_SMODE
- help
- The provides the riscv_get_time() API that is implemented using the
- standard rdtime instruction. This is the case for S-mode U-Boot, and
- is useful for processors that support rdtime in M-mode too.
-
config SYS_MALLOC_F_LEN
default 0x1000
diff --git a/arch/riscv/cpu/ax25/Kconfig b/arch/riscv/cpu/ax25/Kconfig
index 8d8d71dcbf..5cb5bb51eb 100644
--- a/arch/riscv/cpu/ax25/Kconfig
+++ b/arch/riscv/cpu/ax25/Kconfig
@@ -3,7 +3,7 @@ config RISCV_NDS
select ARCH_EARLY_INIT_R
imply CPU
imply CPU_RISCV
- imply RISCV_TIMER
+ imply RISCV_TIMER if (RISCV_SMODE || SPL_RISCV_SMODE)
imply ANDES_PLIC if (RISCV_MMODE || SPL_RISCV_MMODE)
imply ANDES_PLMT if (RISCV_MMODE || SPL_RISCV_MMODE)
imply SPL_CPU_SUPPORT
diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig
index 53e19635c8..ac3f183342 100644
--- a/arch/riscv/cpu/fu540/Kconfig
+++ b/arch/riscv/cpu/fu540/Kconfig
@@ -10,7 +10,7 @@ config SIFIVE_FU540
select SPL_RAM if SPL
imply CPU
imply CPU_RISCV
- imply RISCV_TIMER
+ imply RISCV_TIMER if (RISCV_SMODE || SPL_RISCV_SMODE)
imply SIFIVE_CLINT if (RISCV_MMODE || SPL_RISCV_MMODE)
imply CMD_CPU
imply SPL_CPU_SUPPORT
diff --git a/arch/riscv/cpu/generic/Kconfig b/arch/riscv/cpu/generic/Kconfig
index b2cb155d6d..f4c2e2643c 100644
--- a/arch/riscv/cpu/generic/Kconfig
+++ b/arch/riscv/cpu/generic/Kconfig
@@ -7,7 +7,7 @@ config GENERIC_RISCV
select ARCH_EARLY_INIT_R
imply CPU
imply CPU_RISCV
- imply RISCV_TIMER
+ imply RISCV_TIMER if (RISCV_SMODE || SPL_RISCV_SMODE)
imply SIFIVE_CLINT if (RISCV_MMODE || SPL_RISCV_MMODE)
imply CMD_CPU
imply SPL_CPU_SUPPORT
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 6c503ff2b2..10ac5b06d3 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -15,7 +15,6 @@ obj-$(CONFIG_SIFIVE_CLINT) += sifive_clint.o
obj-$(CONFIG_ANDES_PLIC) += andes_plic.o
obj-$(CONFIG_ANDES_PLMT) += andes_plmt.o
else
-obj-$(CONFIG_RISCV_RDTIME) += rdtime.o
obj-$(CONFIG_SBI) += sbi.o
obj-$(CONFIG_SBI_IPI) += sbi_ipi.o
endif
diff --git a/arch/riscv/lib/rdtime.c b/arch/riscv/lib/rdtime.c
deleted file mode 100644
index e128d7fce6..00
--- a/arch/riscv/lib/rdtime.c
+++ /dev/null
@@ -1,38 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2018, Anup Patel
- * Copyright (C) 2018, Bin Meng
- *
- * The riscv_get_time() API implementation that is using the
- * standard rdtime instruction.
- */
-
-#include
-
-/* Implement the API required by RISC-V timer driver */
-int riscv_get_time(u64 *time)
-{
-#ifdef CONFIG_64BIT
- u64 n;
-
- __asm__ __volatile__ (
-
[PATCH v4 3/8] riscv: Rework Andes PLMT as a UCLASS_TIMER driver
This converts the PLMT driver from the riscv-specific timer interface to be
a DM-based UCLASS_TIMER driver.
The clock-frequency/clocks properties are preferred over timebase-frequency
for two reasons. First, properties which affect a device should be located
near its binding in the device tree. Using timebase-frequency only really
makes sense when the cpu itself is the timer device. This is the case when
we read the time from a CSR, but not when there is a separate device.
Second, it lets the device use the clock subsystem which adds flexibility.
If the device is configured for a different clock speed, the timer can
adjust itself.
Signed-off-by: Sean Anderson
Reviewed-by: Rick Chen
---
This patch builds but has NOT been tested.
Changes in v4:
- Use timer_timebase_fallback
arch/riscv/Kconfig | 4 ---
arch/riscv/dts/ae350_32.dts | 1 +
arch/riscv/dts/ae350_64.dts | 1 +
arch/riscv/include/asm/global_data.h | 3 --
arch/riscv/lib/andes_plmt.c | 44 +---
5 files changed, 23 insertions(+), 30 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 21e6690f4d..d9155b9bab 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -177,10 +177,6 @@ config ANDES_PLIC
config ANDES_PLMT
bool
depends on RISCV_MMODE || SPL_RISCV_MMODE
- select REGMAP
- select SYSCON
- select SPL_REGMAP if SPL
- select SPL_SYSCON if SPL
help
The Andes PLMT block holds memory-mapped mtime register
associated with timer tick.
diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
index 3f8525fe56..afcb9cfbbf 100644
--- a/arch/riscv/dts/ae350_32.dts
+++ b/arch/riscv/dts/ae350_32.dts
@@ -162,6 +162,7 @@
_intc 7
_intc 7>;
reg = <0xe600 0x10>;
+ clock-frequency = <6000>;
};
};
diff --git a/arch/riscv/dts/ae350_64.dts b/arch/riscv/dts/ae350_64.dts
index 482c707503..1c37879049 100644
--- a/arch/riscv/dts/ae350_64.dts
+++ b/arch/riscv/dts/ae350_64.dts
@@ -162,6 +162,7 @@
_intc 7
_intc 7>;
reg = <0x0 0xe600 0x0 0x10>;
+ clock-frequency = <6000>;
};
};
diff --git a/arch/riscv/include/asm/global_data.h
b/arch/riscv/include/asm/global_data.h
index 2eb14815bc..0dec5e669e 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -24,9 +24,6 @@ struct arch_global_data {
#ifdef CONFIG_ANDES_PLIC
void __iomem *plic; /* plic base address */
#endif
-#ifdef CONFIG_ANDES_PLMT
- void __iomem *plmt; /* plmt base address */
-#endif
#if CONFIG_IS_ENABLED(SMP)
struct ipi_data ipi[CONFIG_NR_CPUS];
#endif
diff --git a/arch/riscv/lib/andes_plmt.c b/arch/riscv/lib/andes_plmt.c
index a7e90ca992..a28c14c1eb 100644
--- a/arch/riscv/lib/andes_plmt.c
+++ b/arch/riscv/lib/andes_plmt.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (C) 2019, Rick Chen
+ * Copyright (C) 2020, Sean Anderson
*
* U-Boot syscon driver for Andes's Platform Level Machine Timer (PLMT).
* The PLMT block holds memory-mapped mtime register
@@ -9,46 +10,43 @@
#include
#include
-#include
-#include
+#include
#include
-#include
#include
/* mtime register */
#define MTIME_REG(base)((ulong)(base))
-DECLARE_GLOBAL_DATA_PTR;
-
-#define PLMT_BASE_GET(void)\
- do {\
- long *ret; \
- \
- if (!gd->arch.plmt) { \
- ret = syscon_get_first_range(RISCV_SYSCON_PLMT); \
- if (IS_ERR(ret))\
- return PTR_ERR(ret);\
- gd->arch.plmt = ret;\
- } \
- } while (0)
-
-int riscv_get_time(u64 *time)
+static int andes_plmt_get_count(struct udevice *dev, u64 *count)
{
- PLMT_BASE_GET();
-
- *time = readq((void __iomem *)MTIME_REG(gd->arch.plmt));
+ *count = readq((void __iomem *)MTIME_REG(dev->priv));
return 0;
}
+static const struct timer_ops andes_plmt_ops = {
+ .get_count = andes_plmt_get_count,
+};
+
+static int andes_plmt_probe(struct udevice *dev)
+{
+ dev->priv = dev_read_addr_ptr(dev);
+ if (!dev->priv)
+ return -EINVAL;
+
+ return timer_timebase_fallback(dev);
+}
+
static const struct udevice_id
[PATCH v4 2/8] timer: Add helper for drivers using timebase fallback
This function is designed to be used when a timer used to be initialized by
the cpu (e.g. RISC-V timers), but now is initialized by dm_timer_init. In
such a case, the timer may prefer to use the clocks and clock-frequency
properties, but should be able to fall back on using the cpu's
timebase-frequency.
Signed-off-by: Sean Anderson
---
Changes in v4:
- New
drivers/timer/timer-uclass.c | 25 +
include/timer.h | 15 +++
2 files changed, 40 insertions(+)
diff --git a/drivers/timer/timer-uclass.c b/drivers/timer/timer-uclass.c
index 14dde950a1..fb2f4c351a 100644
--- a/drivers/timer/timer-uclass.c
+++ b/drivers/timer/timer-uclass.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -79,6 +80,30 @@ static int timer_post_probe(struct udevice *dev)
return 0;
}
+int timer_timebase_fallback(struct udevice *dev)
+{
+ struct udevice *cpu;
+ struct cpu_platdata *cpu_plat;
+ struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+
+ /* Did we get our clock rate from the device tree? */
+ if (uc_priv->clock_rate)
+ return 0;
+
+ /* Fall back to timebase-frequency */
+ dev_dbg(dev, "missing clocks or clock-frequency property; falling back
on timebase-frequency\n");
+ cpu = cpu_get_current_dev();
+ if (!cpu)
+ return -ENODEV;
+
+ cpu_plat = dev_get_parent_platdata(cpu);
+ if (!cpu_plat)
+ return -ENODEV;
+
+ uc_priv->clock_rate = cpu_plat->timebase_freq;
+ return 0;
+}
+
u64 timer_conv_64(u32 count)
{
/* increment tbh if tbl has rolled over */
diff --git a/include/timer.h b/include/timer.h
index a49b500ce3..8b9fa51c53 100644
--- a/include/timer.h
+++ b/include/timer.h
@@ -15,6 +15,21 @@
*/
int dm_timer_init(void);
+/**
+ * timer_timebase_fallback() - Helper for timers using timebase fallback
+ * @dev: A timer partially-probed timer device
+ *
+ * This is a helper function designed for timers which need to fall back on the
+ * cpu's timebase. This function is designed to be called during the driver's
+ * probe(). If there is a clocks or clock-frequency property in the timer's
+ * binding, then it will be used. Otherwise, the timebase of the current cpu
+ * will be used. This is initialized by the cpu driver, and usually gotten from
+ * ``/cpus/timebase-frequency`` or ``/cpus/cpu@X/timebase-frequency``.
+ *
+ * Return: 0 if OK, or negative error code on failure
+ */
+int timer_timebase_fallback(struct udevice *dev);
+
/*
* timer_conv_64 - convert 32-bit counter value to 64-bit
*
--
2.28.0
[PATCH v4 6/8] riscv: clk: Add CLINT clock to kendryte clock driver
Another "virtual" clock (in the sense that it isn't configurable). This could possibly be done as a clock in the device tree, but I think this is a bit cleaner. Signed-off-by: Sean Anderson --- checkpatch still complains about this one, but I don't see any reason to break it up even further. It doesn't make sense to me to split the header file change from everything else. (no changes since v2) Changes in v2: - Split Kendryte binding changes into their own commit drivers/clk/kendryte/clk.c | 4 include/dt-bindings/clock/k210-sysctl.h | 1 + 2 files changed, 5 insertions(+) diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c index 981b3b7699..bb196961af 100644 --- a/drivers/clk/kendryte/clk.c +++ b/drivers/clk/kendryte/clk.c @@ -646,6 +646,10 @@ static int k210_clk_probe(struct udevice *dev) REGISTER_GATE(K210_CLK_RTC, "rtc", in0); #undef REGISTER_GATE + /* The MTIME register in CLINT runs at one 50th the CPU clock speed */ + clk_dm(K210_CLK_CLINT, + clk_register_fixed_factor(NULL, "clint", "cpu", 0, 1, 50)); + return 0; } diff --git a/include/dt-bindings/clock/k210-sysctl.h b/include/dt-bindings/clock/k210-sysctl.h index 0e3ed3fb9f..fe852bbd92 100644 --- a/include/dt-bindings/clock/k210-sysctl.h +++ b/include/dt-bindings/clock/k210-sysctl.h @@ -55,5 +55,6 @@ #define K210_CLK_OTP43 #define K210_CLK_RTC44 #define K210_CLK_ACLK 45 +#define K210_CLK_CLINT 46 #endif /* CLOCK_K210_SYSCTL_H */ -- 2.28.0
[PATCH v4 5/8] riscv: Rework Sifive CLINT as UCLASS_TIMER driver
This converts the clint driver from the riscv-specific interface to be a
DM-based UCLASS_TIMER driver. In addition, the SiFive DDR driver previously
implicitly depended on the CLINT to select REGMAP.
Unlike Andes's PLMT/PLIC (which AFAIK never have anything pass it a dtb),
the SiFive CLINT is part of the device tree passed in by qemu. This device
tree doesn't have a clocks or clock-frequency property on clint, so we need
to fall back on the timebase-frequency property. Perhaps in the future we
can get a clock-frequency property added to the qemu dtb.
Unlike with the Andes PLMT, the Sifive CLINT is also an IPI controller.
RISCV_SYSCON_CLINT is retained for this purpose.
Signed-off-by: Sean Anderson
Reviewed-by: Pragnesh Patel
---
This patch builds but has only been tested on the K210 and QEMU. It has NOT
been tested on a HiFive.
Changes in v4:
- Use timer_timebase_fallback
Changes in v3:
- Don't initialize the IPI in spl_invoke_opensbi. Further testing has
revealed it to be unnecessary.
arch/riscv/Kconfig| 4 ---
arch/riscv/lib/sifive_clint.c | 66 +++
drivers/ram/sifive/Kconfig| 2 ++
3 files changed, 38 insertions(+), 34 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index d9155b9bab..aaa3b833a5 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -155,10 +155,6 @@ config 64BIT
config SIFIVE_CLINT
bool
depends on RISCV_MMODE || SPL_RISCV_MMODE
- select REGMAP
- select SYSCON
- select SPL_REGMAP if SPL
- select SPL_SYSCON if SPL
help
The SiFive CLINT block holds memory-mapped control and status
registers
associated with software and timer interrupts.
diff --git a/arch/riscv/lib/sifive_clint.c b/arch/riscv/lib/sifive_clint.c
index b9a2c649cc..c9704c596f 100644
--- a/arch/riscv/lib/sifive_clint.c
+++ b/arch/riscv/lib/sifive_clint.c
@@ -8,9 +8,9 @@
*/
#include
+#include
#include
-#include
-#include
+#include
#include
#include
#include
@@ -24,35 +24,19 @@
DECLARE_GLOBAL_DATA_PTR;
-int riscv_get_time(u64 *time)
-{
- /* ensure timer register base has a sane value */
- riscv_init_ipi();
-
- *time = readq((void __iomem *)MTIME_REG(gd->arch.clint));
-
- return 0;
-}
-
-int riscv_set_timecmp(int hart, u64 cmp)
-{
- /* ensure timer register base has a sane value */
- riscv_init_ipi();
-
- writeq(cmp, (void __iomem *)MTIMECMP_REG(gd->arch.clint, hart));
-
- return 0;
-}
-
int riscv_init_ipi(void)
{
- if (!gd->arch.clint) {
- long *ret = syscon_get_first_range(RISCV_SYSCON_CLINT);
+ int ret;
+ struct udevice *dev;
- if (IS_ERR(ret))
- return PTR_ERR(ret);
- gd->arch.clint = ret;
- }
+ ret = uclass_get_device_by_driver(UCLASS_TIMER,
+ DM_GET_DRIVER(sifive_clint), );
+ if (ret)
+ return ret;
+
+ gd->arch.clint = dev_read_addr_ptr(dev);
+ if (!gd->arch.clint)
+ return -EINVAL;
return 0;
}
@@ -78,14 +62,36 @@ int riscv_get_ipi(int hart, int *pending)
return 0;
}
+static int sifive_clint_get_count(struct udevice *dev, u64 *count)
+{
+ *count = readq((void __iomem *)MTIME_REG(dev->priv));
+
+ return 0;
+}
+
+static const struct timer_ops sifive_clint_ops = {
+ .get_count = sifive_clint_get_count,
+};
+
+static int sifive_clint_probe(struct udevice *dev)
+{
+ dev->priv = dev_read_addr_ptr(dev);
+ if (!dev->priv)
+ return -EINVAL;
+
+ return timer_timebase_fallback(dev);
+}
+
static const struct udevice_id sifive_clint_ids[] = {
- { .compatible = "riscv,clint0", .data = RISCV_SYSCON_CLINT },
+ { .compatible = "riscv,clint0" },
{ }
};
U_BOOT_DRIVER(sifive_clint) = {
.name = "sifive_clint",
- .id = UCLASS_SYSCON,
+ .id = UCLASS_TIMER,
.of_match = sifive_clint_ids,
+ .probe = sifive_clint_probe,
+ .ops= _clint_ops,
.flags = DM_FLAG_PRE_RELOC,
};
diff --git a/drivers/ram/sifive/Kconfig b/drivers/ram/sifive/Kconfig
index 6aca22ab2a..31ad0a7e45 100644
--- a/drivers/ram/sifive/Kconfig
+++ b/drivers/ram/sifive/Kconfig
@@ -9,5 +9,7 @@ config SIFIVE_FU540_DDR
bool "SiFive FU540 DDR driver"
depends on RAM_SIFIVE
default y if TARGET_SIFIVE_FU540
+ select REGMAP
+ select SPL_REGMAP if SPL
help
This enables DDR support for the platforms based on SiFive FU540 SoC.
--
2.28.0
[PATCH v4 0/8] riscv: Clean up timer drivers
This series cleans up the timer drivers in RISC-V and converts them to DM. This series needs to be tested! I have only tested it on QEMU and the K210. Notably, this means that the HiFive and anything Andes is completely untested. Changes in v4: - Both the Andes PMLT and Sifive CLINT now fall back on timebase-frequency, per discussion with Anup Patel - Introduce helper function for falling back on timebase-frequency - Modify RISCV_TIMER KConfig - Now depends on RISCV - Implied by S-Mode (with or without SPL) - Rebase - Remove clock-frequency property from k210 clint binding because we fall back on timebase-frequency Changes in v3: - Don't initialize the IPI in spl_invoke_opensbi. Further testing has revealed it to be unnecessary. - Rebase Changes in v2: - Fix SiFive CLINT not getting tick-rate from rtcclk - Remove RISCV_RDTIME KConfig option - Split Kendryte binding changes into their own commit Sean Anderson (8): riscv: Rework riscv timer driver to only support S-mode timer: Add helper for drivers using timebase fallback riscv: Rework Andes PLMT as a UCLASS_TIMER driver riscv: Clean up initialization in Andes PLIC riscv: Rework Sifive CLINT as UCLASS_TIMER driver riscv: clk: Add CLINT clock to kendryte clock driver riscv: Update Kendryte device tree for new CLINT driver riscv: Update SiFive device tree for new CLINT driver arch/riscv/Kconfig| 16 - arch/riscv/cpu/ax25/Kconfig | 2 +- arch/riscv/cpu/fu540/Kconfig | 2 +- arch/riscv/cpu/generic/Kconfig| 2 +- arch/riscv/dts/ae350_32.dts | 1 + arch/riscv/dts/ae350_64.dts | 1 + arch/riscv/dts/fu540-c000-u-boot.dtsi | 8 ++- .../dts/hifive-unleashed-a00-u-boot.dtsi | 4 ++ arch/riscv/dts/k210.dtsi | 7 +- arch/riscv/include/asm/global_data.h | 3 - arch/riscv/lib/Makefile | 1 - arch/riscv/lib/andes_plic.c | 58 +++- arch/riscv/lib/andes_plmt.c | 44 ++--- arch/riscv/lib/rdtime.c | 38 --- arch/riscv/lib/sifive_clint.c | 66 ++- drivers/clk/kendryte/clk.c| 4 ++ drivers/ram/sifive/Kconfig| 2 + drivers/timer/Kconfig | 4 +- drivers/timer/riscv_timer.c | 39 +-- drivers/timer/timer-uclass.c | 25 +++ include/dt-bindings/clock/k210-sysctl.h | 1 + include/timer.h | 15 + 22 files changed, 170 insertions(+), 173 deletions(-) delete mode 100644 arch/riscv/lib/rdtime.c -- 2.28.0
[PATCH v4 4/8] riscv: Clean up initialization in Andes PLIC
This merges the PLIC initialization code from two functions into one.
Signed-off-by: Sean Anderson
Reviewed-by: Bin Meng
---
This patch builds but has NOT been tested.
(no changes since v1)
arch/riscv/lib/andes_plic.c | 58 -
1 file changed, 25 insertions(+), 33 deletions(-)
diff --git a/arch/riscv/lib/andes_plic.c b/arch/riscv/lib/andes_plic.c
index c2a8fe4d9e..267d6a191b 100644
--- a/arch/riscv/lib/andes_plic.c
+++ b/arch/riscv/lib/andes_plic.c
@@ -41,53 +41,45 @@ static int enable_ipi(int hart)
return 0;
}
-static int init_plic(void)
+int riscv_init_ipi(void)
{
- struct udevice *dev;
- ofnode node;
int ret;
+ long *base = syscon_get_first_range(RISCV_SYSCON_PLIC);
+ ofnode node;
+ struct udevice *dev;
u32 reg;
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+ gd->arch.plic = base;
+
ret = uclass_find_first_device(UCLASS_CPU, );
if (ret)
return ret;
+ else if (!dev)
+ return -ENODEV;
- if (dev) {
- ofnode_for_each_subnode(node, dev_ofnode(dev->parent)) {
- const char *device_type;
+ ofnode_for_each_subnode(node, dev_ofnode(dev->parent)) {
+ const char *device_type;
- device_type = ofnode_read_string(node, "device_type");
- if (!device_type)
- continue;
+ device_type = ofnode_read_string(node, "device_type");
+ if (!device_type)
+ continue;
- if (strcmp(device_type, "cpu"))
- continue;
+ if (strcmp(device_type, "cpu"))
+ continue;
- /* skip if hart is marked as not available */
- if (!ofnode_is_available(node))
- continue;
+ /* skip if hart is marked as not available */
+ if (!ofnode_is_available(node))
+ continue;
- /* read hart ID of CPU */
- ret = ofnode_read_u32(node, "reg", );
- if (ret == 0)
- enable_ipi(reg);
- }
-
- return 0;
+ /* read hart ID of CPU */
+ ret = ofnode_read_u32(node, "reg", );
+ if (ret == 0)
+ enable_ipi(reg);
}
- return -ENODEV;
-}
-
-int riscv_init_ipi(void)
-{
- long *ret = syscon_get_first_range(RISCV_SYSCON_PLIC);
-
- if (IS_ERR(ret))
- return PTR_ERR(ret);
- gd->arch.plic = ret;
-
- return init_plic();
+ return 0;
}
int riscv_send_ipi(int hart)
--
2.28.0
Re: [PULL] Pull request: u-boot-stm32 for v2020.10= u-boot-stm32-20200909
On Wed, Sep 09, 2020 at 03:20:27PM +, Patrick DELAUNAY wrote: > Hi Tom, > > Please pull the STM32 related patches for v2020.10: u-boot-stm32-20200528 > > With the following changes: > - fixes on AV96 board: pull up on UART4 RX and adjust PLL4 > > CI status: > https://gitlab.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/4631 > > Thanks, > Patrick > > git request-pull origin/master > https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git u-boot-stm32-20200909 > > The following changes since commit 96d66a9b8ce11aae9f8bef5244b83b4740b37644: > > Prepare v2020.10-rc4 (2020-09-07 14:17:33 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git > tags/u-boot-stm32-20200909 > > for you to fetch changes up to b6055945d66d0f4e3b1ecb82af476232067a4ee4: > > ARM: dts: stm32: Adjust PLL4 settings on AV96 again (2020-09-09 15:02:23 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] rpi: second round for v2020.10
On Wed, 9 Sep 2020 10:13:50 +0200 Matthias Brugger wrote: > Hi Tom, > > Please have a look at the second round of patches for the RPi. Two patches > fixes > the network driver of the RPi4 which didn't work reliable. Another patch > enables > USB keyboard for 32 bit RPi4. > > Petr tested the network patches, but his mail with the Tested-by tag didn't > come > through. I added it anyway. What do you mean by "didn't come through"? I can see it in the mailing list archive: http://u-boot.10912.n7.nabble.com/PATCH-bcmgenet-fix-DMA-buffer-management-td419536.html#a424854 Did I send my answer to the wrong thread? Petr T > As always you can find the CI outcome here: > https://travis-ci.org/github/mbgg/u-boot/builds/725262009 > https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/4622 > > I ran the CI against the rpi-next branch and not the tag, but you can > verify that this is basically the same commit id. > > Thanks for having a look! > Regards, > Matthias > > -- > > The following changes since commit > 96d66a9b8ce11aae9f8bef5244b83b4740b37644: > >Prepare v2020.10-rc4 (2020-09-07 14:17:33 -0400) > > are available in the Git repository at: > >https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git/ > tags/rpi-next-2020.10.2 > > for you to fetch changes up to > 40877a1a949edf7066b3e4ed16101153624bb314: > >config: Enable USB Keyboard suuport on RPi4 32 bit (2020-09-08 > 16:45:01 +0200) > > > - fixes for bcmgenet > - enable USB keyboard for RPi4 32 bit > > > Jason Wessel (2): >bcmgenet: fix DMA buffer management >bcmgenet: Add support for rgmii-rxid > > Matthias Brugger (1): >config: Enable USB Keyboard suuport on RPi4 32 bit > > configs/rpi_4_32b_defconfig | 1 + > drivers/net/bcmgenet.c | 20 +++- > 2 files changed, 12 insertions(+), 9 deletions(-) > pgpVZTmmQN6NN.pgp Description: Digitální podpis OpenPGP
Re: [PATCH v3 0/4] arm64: Large PIE fixes
On 9/9/20 11:07 AM, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > This fixes some build issues with large (> 1MB) PIE U-Boot setups. > We also document the 4K aligned load address requirement and > add an early run-time check for it. > > As requested by reviewers, I've also added a runtime check for > non-PIE builds to trap the startup sequence early if the start > address doesn't match between run-time and link-time. The series, Reviewed-by: Stephen Warren
Re: command documentation
Hi Jasper, On Wed, Sep 09, 2020 at 07:03:58PM +0200, Jasper van Santen wrote: I am sorry to ask such a basic question, but i really can't find any documentation on the commands possible in scripting. Documentation of Hush and its commands i can't find. The hush shell gives you the ability to do loops/conditionals. It uses the same syntax as most Linux/unix shells, such as ash/bash/dash. You will find many tutorials/documents online for these. Some examples: https://www.xilinx.com/video/soc/u-boot-hush-shell-scripting.html https://www.man7.org/linux/man-pages/man1/dash.1.html Keep in mind that some more fancy features may not be supported in the u-boot hush shell. As far as official documentation, I am only aware of brief mention in https://github.com/u-boot/u-boot/blob/master/README#L3530 The other aspect is the commands which can be run. This depends on how you configure your u-boot, eg. the CONFIG_CMD_* parameters. You can get a brief overview of commands by typing "help" at the u-boot prompt. And somewhat more help by typing "help ". Hope this helps, Ralph
Re: [PATCH] arm: gic-v3-its: Add irq UCLASS_DRIVER
Hi Stefan,
On Wed, Sep 9, 2020 at 1:57 PM Stefan Roese wrote:
>
> On 09.09.20 10:14, Priyanka Jain wrote:
> > This is required to fix
> > "Error binding driver 'gic-v3': -96"
> > on lx2160a platforms.
> >
> > Signed-off-by: Priyanka Jain
> > ---
> > arch/arm/lib/gic-v3-its.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/lib/gic-v3-its.c b/arch/arm/lib/gic-v3-its.c
> > index a1657e3853..6c6b7c430c 100644
> > --- a/arch/arm/lib/gic-v3-its.c
> > +++ b/arch/arm/lib/gic-v3-its.c
> > @@ -208,3 +208,8 @@ U_BOOT_DRIVER(gic_lpi_syscon) = {
> > .id = UCLASS_SYSCON,
> > .of_match = gic_lpi_syscon_ids,
> > };
> > +
> > +UCLASS_DRIVER(irq) = {
> > + .id = UCLASS_IRQ,
> > + .name = "irq",
> > +};
>
> I tested this on LX2160 and get this error when booting into Linux:
>
> Loading Device Tree to 9fff6000, end 9f3e ... OK
> gic_v3_its_get_gic_lpi_addr: failed to get gic-lpi-base syscon device
>
> Starting kernel ...
>
> [0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
>
> I did not look closely yet. Any idea whats going wrong here?
I added the following patch to use UCLASS_SYSCON to get gic lpi details.
commit id - 2ae7adc659f7fca9ea65df4318e5bca2b8274310
because the above commit is failing, hence we need this patch.
When I tested this I didn't face any issue hence didn't push the above change.
In my case it was failing only in the lower uboot version without this patch.
Best regards,
Rayagonda
>
> Thanks,
> Stefan
command documentation
Hi,
I am sorry to ask such a basic question, but i really can't find any
documentation on the commands possible in scripting.
Documentation of Hush and its commands i can't find.
I am working with the script in u-boot env below.
I can read it, but just because i am guessing.
Any help is appreciated
arch=arm
board=tinker_rk3288
board_name=tinker_rk3288
scriptaddr=0x
soc=rockchip
vendor=rockchip
devnums=0 1
devtype=mmc
bootdelay=-2
fdt_addr_r=0x01f0
fdt_high=0x0fff
fdtcontroladdr=7df5c620
ramdisk_addr_r=0x0400
kernel_addr_r=0x0200
bootargs=console=tty2 quiet vt.global_cursor_default=0 rootwait
consoleblank=0 loglevel=0
scan_dev_for_boot_part= \
part list mmc ${devnum} -bootable devplist; \
env exists devplist || setenv devplist 1; \
for distro_bootpart in ${devplist}; do \
if fstype mmc ${devnum}:${distro_bootpart} bootfstype; then \
run scan_dev_for_boot; \
fi; \
done
scan_dev_for_boot= \
if test -e mmc ${devnum}:${distro_bootpart} /boot/extlinux/extlinux.conf;
then \
setenv bootargs ${bootargs} root=/dev/mmcblk${devnum}p${distro_bootpart}; \
echo Booting with args: ${bootargs}; \
sysboot mmc ${devnum}:${distro_bootpart} any ${scriptaddr}
/boot/extlinux/extlinux.conf; \
fi
bootcmd= \
for devnum in ${devnums}; do \
if mmc dev ${devnum}; then \
run scan_dev_for_boot_part; \
fi; \
done
--
*Kind regards,Jasper van Santen*
[PATCH v3 4/4] arm64: Trap non-PIE builds early if starting from wrong address
From: "Edgar E. Iglesias" Trap non-PIE builds early if the start address doesn't match between run-time and link-time. This will trap the startup sequence rather than letting it run into obscure errors. Signed-off-by: Edgar E. Iglesias --- arch/arm/cpu/armv8/start.S | 13 + 1 file changed, 13 insertions(+) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index e5c2856cf5..39e1b842c4 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -101,6 +101,19 @@ pie_skip_reloc: cmp x2, x3 b.lopie_fix_loop pie_fixup_done: +#else + adr x0, _start + ldr x1, _TEXT_BASE + cmp x0, x1 + beq 1f +0: + /* +* FATAL, can't continue. +* U-Boot needs to start executing at CONFIG_SYS_TEXT_BASE. +*/ + wfi + b 0b +1: #endif #ifdef CONFIG_SYS_RESET_SCTRL -- 2.25.1
[PATCH v3 2/4] arm64: Trap PIE builds early if load address is not 4K aligned
From: "Edgar E. Iglesias" PIE requires a 4K aligned load address. If this is not met, trap the startup sequence in a WFI loop rather than running into obscure failures. Tested-by: Michal Simek Suggested-by: André Przywara Signed-off-by: Edgar E. Iglesias --- arch/arm/cpu/armv8/start.S | 17 + 1 file changed, 17 insertions(+) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 002698b501..85baebc5f7 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -59,6 +59,23 @@ reset: save_boot_params_ret: #if CONFIG_POSITION_INDEPENDENT + /* Verify that we're 4K aligned. */ + adr x0, _start + andsx0, x0, #0xfff + b.eq1f +0: + /* +* FATAL, can't continue. +* U-Boot needs to be loaded at a 4K aligned address. +* +* We use ADRP and ADD to load some symbol addresses during startup. +* The ADD uses an absolute (non pc-relative) lo12 relocation +* thus requiring 4K alignment. +*/ + wfi + b 0b +1: + /* * Fix .rela.dyn relocations. This allows U-Boot to be loaded to and * executed at a different address than it was linked at. -- 2.25.1
[PATCH v3 3/4] arm64: Add support for larger PIE U-Boot
From: "Edgar E. Iglesias" Linking a U-Boot larger than 1MB fails with PIE enabled: u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end' defined in .bss_start section in u-boot. This extends the supported range by using adrp & add to load symbols early while starting up. Signed-off-by: Edgar E. Iglesias --- arch/arm/cpu/armv8/start.S | 6 -- arch/arm/lib/crt0_64.S | 8 +++- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 85baebc5f7..e5c2856cf5 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -84,8 +84,10 @@ pie_fixup: adr x0, _start /* x0 <- Runtime value of _start */ ldr x1, _TEXT_BASE /* x1 <- Linked value of _start */ sub x9, x0, x1 /* x9 <- Run-vs-link offset */ - adr x2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ - adr x3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ + adrpx2, __rel_dyn_start /* x2 <- Runtime &__rel_dyn_start */ + add x2, x2, #:lo12:__rel_dyn_start + adrpx3, __rel_dyn_end /* x3 <- Runtime &__rel_dyn_end */ + add x3, x3, #:lo12:__rel_dyn_end pie_fix_loop: ldp x0, x1, [x2], #16 /* (x0, x1) <- (Link location, fixup) */ ldr x4, [x2], #8/* x4 <- addend */ diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index 04afa518ac..9d2319c0e8 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -73,7 +73,12 @@ ENTRY(_main) #elif defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) ldr x0, =(CONFIG_SPL_STACK) #elif defined(CONFIG_INIT_SP_RELATIVE) +#if CONFIG_POSITION_INDEPENDENT + adrpx0, __bss_start /* x0 <- Runtime &__bss_start */ + add x0, x0, #:lo12:__bss_start +#else adr x0, __bss_start +#endif add x0, x0, #CONFIG_SYS_INIT_SP_BSS_OFFSET #else ldr x0, =(CONFIG_SYS_INIT_SP_ADDR) @@ -102,7 +107,8 @@ ENTRY(_main) adr lr, relocation_return #if CONFIG_POSITION_INDEPENDENT /* Add in link-vs-runtime offset */ - adr x0, _start /* x0 <- Runtime value of _start */ + adrpx0, _start /* x0 <- Runtime value of _start */ + add x0, x0, #:lo12:_start ldr x9, _TEXT_BASE /* x9 <- Linked value of _start */ sub x9, x9, x0 /* x9 <- Run-vs-link offset */ add lr, lr, x9 -- 2.25.1
[PATCH v3 1/4] arm64: Mention 4K aligned load addresses in the PIE Kconfig help
From: "Edgar E. Iglesias" Mention the requirement of 4K aligned load addresses in the help section for the POSITION_INDEPENDENT option. Suggested-by: Michal Simek Signed-off-by: Edgar E. Iglesias --- arch/arm/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 80702c23d3..67286e8b5d 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -16,8 +16,8 @@ config POSITION_INDEPENDENT help U-Boot expects to be linked to a specific hard-coded address, and to be loaded to and run from that address. This option lifts that - restriction, thus allowing the code to be loaded to and executed - from almost any address. This logic relies on the relocation + restriction, thus allowing the code to be loaded to and executed from + almost any 4K aligned address. This logic relies on the relocation information that is embedded in the binary to support U-Boot relocating itself to the top-of-RAM later during execution. -- 2.25.1
[PATCH v3 0/4] arm64: Large PIE fixes
From: "Edgar E. Iglesias" This fixes some build issues with large (> 1MB) PIE U-Boot setups. We also document the 4K aligned load address requirement and add an early run-time check for it. As requested by reviewers, I've also added a runtime check for non-PIE builds to trap the startup sequence early if the start address doesn't match between run-time and link-time. Cheers, Edgar ChangeLog: v2 -> v3: * Add non-PIE start address (run vs link-time) check * Move 4K aligment Kconfig help description * Fix load of __bss_start * Use x0 rather than x1 in PIE load-address check * Add missing tabs * Add load-address check for non-PIE * U-boot -> U-Boot in a few places * Tweak commit messages v1 -> v2: * Fix adr of _start in arch/arm/lib/crt0_64.S * Add early check and bail out into a WFI loop when not 4K aligned * Document the 4K alignement requirement in Kconfig Edgar E. Iglesias (4): arm64: Mention 4K aligned load addresses in the PIE Kconfig help arm64: Trap PIE builds early if load address is not 4K aligned arm64: Add support for larger PIE U-Boot arm64: Trap non-PIE builds early if starting from wrong address arch/arm/Kconfig | 4 ++-- arch/arm/cpu/armv8/start.S | 36 ++-- arch/arm/lib/crt0_64.S | 8 +++- 3 files changed, 43 insertions(+), 5 deletions(-) -- 2.25.1
Re: [PATCH v6 00/17] efi_loader: add capsule update support
On Wed, Sep 09, 2020 at 04:48:30PM +0200, Heinrich Schuchardt wrote: > On 07.09.20 07:34, AKASHI Takahiro wrote: [snip] > > required and partly because there is a problem with virt-make-fs. > > What problem with virt-make-fs exists? How will this be solved? This I suspect is related to the difficulty of getting tests to run in all of our CI environments, where at least in one case they run and pass, rather than skip. This will require that the series get run through at least Travis and Azure before re-posting, at this point. Thanks. -- Tom signature.asc Description: PGP signature
[PATCH v4 8/8] firmware: smci: sandbox test for SCMI reset controllers
Add tests for SCMI reset controllers. A test device driver
sandbox-scmi_devices.c is used to get reset resources, allowing further
resets manipulation.
Change sandbox-smci_agent to emulate 1 reset controller exposed through
an agent. Add DM test scmi_resets to test this reset controller.
Signed-off-by: Etienne Carriere
Cc: Simon Glass
Cc: Peng Fan
Cc: Sudeep Holla
---
Changes in v4:
- Rebase in the series without major conflict.
- Rename test/dm/scmi.c local variables rc to ret for consistency.
Changes in v3:
- New commit in the series, addresses review comments on test support.
ut_dm_scmi_resets() tests SCMI resources are found and behave as
expected for the implemented reset uclass methods.
---
arch/sandbox/dts/test.dts| 6 +
arch/sandbox/include/asm/scmi_test.h | 17 +++
configs/sandbox_defconfig| 1 +
drivers/firmware/scmi/sandbox-scmi_agent.c | 117 ++-
drivers/firmware/scmi/sandbox-scmi_devices.c | 40 ++-
test/dm/scmi.c | 36 ++
6 files changed, 211 insertions(+), 6 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 61acd8d79f..7023f33a67 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -366,6 +366,11 @@
reg = <0x14>;
#clock-cells = <1>;
};
+
+ reset_scmi0: protocol@16 {
+ reg = <0x16>;
+ #reset-cells = <1>;
+ };
};
sandbox-scmi-agent@1 {
@@ -1065,6 +1070,7 @@
sandbox_scmi {
compatible = "sandbox,scmi-devices";
clocks = <_scmi0 7>, <_scmi0 3>, <_scmi1 1>;
+ resets = <_scmi0 3>;
};
pinctrl {
diff --git a/arch/sandbox/include/asm/scmi_test.h
b/arch/sandbox/include/asm/scmi_test.h
index 63093fdb4d..3e8b0068fd 100644
--- a/arch/sandbox/include/asm/scmi_test.h
+++ b/arch/sandbox/include/asm/scmi_test.h
@@ -22,16 +22,29 @@ struct sandbox_scmi_clk {
ulong rate;
};
+/**
+ * struct sandbox_scmi_reset - Simulated reset controller exposed by SCMI
+ * @asserted: Reset control state: true if asserted, false if desasserted
+ */
+struct sandbox_scmi_reset {
+ uint id;
+ bool asserted;
+};
+
/**
* struct sandbox_scmi_agent - Simulated SCMI service seen by SCMI agent
* @idx: Identifier for the SCMI agent, its index
* @clk: Simulated clocks
* @clk_count: Simulated clocks array size
+ * @clk: Simulated reset domains
+ * @clk_count: Simulated reset domains array size
*/
struct sandbox_scmi_agent {
uint idx;
struct sandbox_scmi_clk *clk;
size_t clk_count;
+ struct sandbox_scmi_reset *reset;
+ size_t reset_count;
};
/**
@@ -48,10 +61,14 @@ struct sandbox_scmi_service {
* struct sandbox_scmi_devices - Reference to devices probed through SCMI
* @clk: Array the clock devices
* @clk_count: Number of clock devices probed
+ * @reset: Array the reset controller devices
+ * @reset_count: Number of reset controller devices probed
*/
struct sandbox_scmi_devices {
struct clk *clk;
size_t clk_count;
+ struct reset_ctl *reset;
+ size_t reset_count;
};
#ifdef CONFIG_SCMI_FIRMWARE
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 7d71c805dc..a2ebb3c971 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -220,6 +220,7 @@ CONFIG_REMOTEPROC_SANDBOX=y
CONFIG_DM_RESET=y
CONFIG_SANDBOX_RESET=y
CONFIG_RESET_SYSCON=y
+CONFIG_RESET_SCMI=y
CONFIG_DM_RNG=y
CONFIG_DM_RTC=y
CONFIG_RTC_RV8803=y
diff --git a/drivers/firmware/scmi/sandbox-scmi_agent.c
b/drivers/firmware/scmi/sandbox-scmi_agent.c
index ff590988a6..5b6a4232af 100644
--- a/drivers/firmware/scmi/sandbox-scmi_agent.c
+++ b/drivers/firmware/scmi/sandbox-scmi_agent.c
@@ -18,19 +18,20 @@
* processing. It simulates few of the SCMI services for some of the
* SCMI protocols embedded in U-Boot. Currently:
* - SCMI clock protocol: emulate 2 agents each exposing few clocks
+ * - SCMI reset protocol: emulate 1 agents each exposing a reset
*
- * Agent #0 simulates 2 clocks.
- * See IDs in scmi0_clk[] and "sandbox-scmi-agent@0" in test.dts.
+ * Agent #0 simulates 2 clocks and 1 reset domain.
+ * See IDs in scmi0_clk[]/scmi0_reset[] and "sandbox-scmi-agent@0" in test.dts.
*
* Agent #1 simulates 1 clock.
* See IDs in scmi1_clk[] and "sandbox-scmi-agent@1" in test.dts.
*
- * All clocks are default disabled.
+ * All clocks are default disabled and reset levels down.
*
* This Driver exports sandbox_scmi_service_ct() for the test sequence to
* get the state of the simulated services (clock state, rate, ...) and
* check back-end device state reflects the request send through the
- *
[PATCH v4 7/8] reset: add reset controller driver for SCMI agents
This change introduces a reset controller driver for SCMI agent devices.
When SCMI agent and SCMI reset domain drivers are enabled, SCMI agent
binds a reset controller device for each SCMI reset domain protocol
devices enabled in the FDT.
SCMI reset driver is embedded upon CONFIG_RESET_SCMI=y. If enabled,
CONFIG_SCMI_AGENT is also enabled.
SCMI Reset Domain protocol is defined in the SCMI specification [1].
Links: [1]
https://developer.arm.com/architectures/system-architectures/software-standards/scmi
Signed-off-by: Etienne Carriere
Cc: Simon Glass
Cc: Peng Fan
Cc: Sudeep Holla
---
Changes in v4:
- Condition DM_GET_DRIVER(scmi_reset_domain) to
IS_ENABLED(CONFIG_RESET_SCMI) to prevent a build error (linker) when
CONFIG_RESET_SCMI is disabled.
Changes in v3:
- Upgrade to rename into devm_scmi_process_msg() and scmi.h split
into scmi_*.h.
- Fix message ID used in scmi_reset_request().
Changes in v2:
- Change reset request() method to at least check the reset domain
exists by sending a SCMI RESET_DOMAIN_ATTRIBUTE message.
- Add inline description for the several structures.
- Patch v1 R-b tag not applied since the above changes in this v2.
BACKPORTED FROM v2020.10-rc2 to V2020.04
---
drivers/firmware/scmi/scmi_agent-uclass.c | 4 ++
drivers/reset/Kconfig | 8 +++
drivers/reset/Makefile| 1 +
drivers/reset/reset-scmi.c| 81 +++
include/scmi_protocols.h | 60 +
5 files changed, 154 insertions(+)
create mode 100644 drivers/reset/reset-scmi.c
diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c
b/drivers/firmware/scmi/scmi_agent-uclass.c
index 1f36f23b6d..77160b1999 100644
--- a/drivers/firmware/scmi/scmi_agent-uclass.c
+++ b/drivers/firmware/scmi/scmi_agent-uclass.c
@@ -74,6 +74,10 @@ static int scmi_bind_protocols(struct udevice *dev)
if (IS_ENABLED(CONFIG_CLK_SCMI))
drv = DM_GET_DRIVER(scmi_clock);
break;
+ case SCMI_PROTOCOL_ID_RESET_DOMAIN:
+ if (IS_ENABLED(CONFIG_RESET_SCMI))
+ drv = DM_GET_DRIVER(scmi_reset_domain);
+ break;
default:
break;
}
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 253902ff57..ee5be0bc2f 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -173,4 +173,12 @@ config RESET_RASPBERRYPI
relevant. This driver provides a reset controller capable of
interfacing with RPi4's co-processor and model these firmware
initialization routines as reset lines.
+
+config RESET_SCMI
+ bool "Enable SCMI reset domain driver"
+ select SCMI_FIRMWARE
+ help
+ Enable this option if you want to support reset controller
+ devices exposed by a SCMI agent based on SCMI reset domain
+ protocol communication with a SCMI server.
endmenu
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 3c7f066ae3..625ec7168e 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -26,3 +26,4 @@ obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
obj-$(CONFIG_RESET_SIFIVE) += reset-sifive.o
obj-$(CONFIG_RESET_SYSCON) += reset-syscon.o
obj-$(CONFIG_RESET_RASPBERRYPI) += reset-raspberrypi.o
+obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
diff --git a/drivers/reset/reset-scmi.c b/drivers/reset/reset-scmi.c
new file mode 100644
index 00..1bff8075ee
--- /dev/null
+++ b/drivers/reset/reset-scmi.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-2020 Linaro Limited
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int scmi_reset_set_level(struct reset_ctl *rst, bool
assert_not_deassert)
+{
+ struct scmi_rd_reset_in in = {
+ .domain_id = rst->id,
+ .flags = assert_not_deassert ? SCMI_RD_RESET_FLAG_ASSERT : 0,
+ .reset_state = 0,
+ };
+ struct scmi_rd_reset_out out;
+ struct scmi_msg msg = SCMI_MSG_IN(SCMI_PROTOCOL_ID_RESET_DOMAIN,
+ SCMI_RESET_DOMAIN_RESET,
+ in, out);
+ int ret;
+
+ ret = devm_scmi_process_msg(rst->dev->parent, );
+ if (ret)
+ return ret;
+
+ return scmi_to_linux_errno(out.status);
+}
+
+static int scmi_reset_assert(struct reset_ctl *rst)
+{
+ return scmi_reset_set_level(rst, true);
+}
+
+static int scmi_reset_deassert(struct reset_ctl *rst)
+{
+ return scmi_reset_set_level(rst, false);
+}
+
+static int scmi_reset_request(struct reset_ctl *rst)
+{
+ struct scmi_rd_attr_in in = {
+ .domain_id = rst->id,
+ };
+ struct scmi_rd_attr_out out;
+ struct scmi_msg msg = SCMI_MSG_IN(SCMI_PROTOCOL_ID_RESET_DOMAIN,
+
[PATCH v4 6/8] firmware: scmi: sandbox test for SCMI clocks
Add tests for SCMI clocks. A test device driver sandbox-scmi_devices.c
is used to get clock resources, allowing further clock manipulation.
Change sandbox-smci_agent to emulate 3 clocks exposed through 2 agents.
Add DM test scmi_clocks to test these 3 clocks.
Update DM test sandbox_scmi_agent with load/remove test sequences
factorized by {load|remove}_sandbox_scmi_test_devices() helper functions.
Signed-off-by: Etienne Carriere
Cc: Simon Glass
Cc: Peng Fan
Cc: Sudeep Holla
---
Changes in v4:
- Move SCMI test devices instances from BSS to test device private data
and update test/dm/scmi.c accordingly.
- Update sandbox_scmi_devices_ctx() helper to add device reference arg.
- Fix spelling issues in inline comments.
- Rename local variables rc to ret for consistency.
Changes in v3:
- New commit in the series, addresses review comments on test support.
ut_dm_scmi_clocks test SCMI are found and behave as expected for the
implemented clk uclass methods.
---
arch/sandbox/dts/test.dts| 15 ++
arch/sandbox/include/asm/scmi_test.h | 39 +
configs/sandbox_defconfig| 1 +
drivers/firmware/scmi/Makefile | 2 +-
drivers/firmware/scmi/sandbox-scmi_agent.c | 169 ++-
drivers/firmware/scmi/sandbox-scmi_devices.c | 75
test/dm/scmi.c | 141 +++-
7 files changed, 431 insertions(+), 11 deletions(-)
create mode 100644 drivers/firmware/scmi/sandbox-scmi_devices.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index dd3b43885e..61acd8d79f 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -361,6 +361,11 @@
compatible = "sandbox,scmi-agent";
#address-cells = <1>;
#size-cells = <0>;
+
+ clk_scmi0: protocol@14 {
+ reg = <0x14>;
+ #clock-cells = <1>;
+ };
};
sandbox-scmi-agent@1 {
@@ -368,6 +373,11 @@
#address-cells = <1>;
#size-cells = <0>;
+ clk_scmi1: protocol@14 {
+ reg = <0x14>;
+ #clock-cells = <1>;
+ };
+
protocol@10 {
reg = <0x10>;
};
@@ -1052,6 +1062,11 @@
compatible = "sandbox,virtio2";
};
+ sandbox_scmi {
+ compatible = "sandbox,scmi-devices";
+ clocks = <_scmi0 7>, <_scmi0 3>, <_scmi1 1>;
+ };
+
pinctrl {
compatible = "sandbox,pinctrl";
diff --git a/arch/sandbox/include/asm/scmi_test.h
b/arch/sandbox/include/asm/scmi_test.h
index a811fe19c3..63093fdb4d 100644
--- a/arch/sandbox/include/asm/scmi_test.h
+++ b/arch/sandbox/include/asm/scmi_test.h
@@ -10,12 +10,28 @@ struct udevice;
struct sandbox_scmi_agent;
struct sandbox_scmi_service;
+/**
+ * struct sandbox_scmi_clk - Simulated clock exposed by SCMI
+ * @id:Identifier of the clock used in the SCMI protocol
+ * @enabled: Clock state: true if enabled, false if disabled
+ * @rate: Clock rate in Hertz
+ */
+struct sandbox_scmi_clk {
+ uint id;
+ bool enabled;
+ ulong rate;
+};
+
/**
* struct sandbox_scmi_agent - Simulated SCMI service seen by SCMI agent
* @idx: Identifier for the SCMI agent, its index
+ * @clk: Simulated clocks
+ * @clk_count: Simulated clocks array size
*/
struct sandbox_scmi_agent {
uint idx;
+ struct sandbox_scmi_clk *clk;
+ size_t clk_count;
};
/**
@@ -28,16 +44,39 @@ struct sandbox_scmi_service {
size_t agent_count;
};
+/**
+ * struct sandbox_scmi_devices - Reference to devices probed through SCMI
+ * @clk: Array the clock devices
+ * @clk_count: Number of clock devices probed
+ */
+struct sandbox_scmi_devices {
+ struct clk *clk;
+ size_t clk_count;
+};
+
#ifdef CONFIG_SCMI_FIRMWARE
/**
* sandbox_scmi_service_context - Get the simulated SCMI services context
* @return:Reference to backend simulated resources state
*/
struct sandbox_scmi_service *sandbox_scmi_service_ctx(void);
+
+/**
+ * sandbox_scmi_devices_get_ref - Get references to devices accessed through
SCMI
+ * @dev: Reference to the test device used get test resources
+ * @return:Reference to the devices probed by the SCMI test
+ */
+struct sandbox_scmi_devices *sandbox_scmi_devices_ctx(struct udevice *dev);
#else
static inline struct sandbox_scmi_service *sandbox_scmi_service_ctx(void)
{
return NULL;
}
+
+static inline
+struct sandbox_scmi_devices *sandbox_scmi_devices_ctx(struct udevice *dev)
+{
+ return NULL;
+}
#endif /* CONFIG_SCMI_FIRMWARE */
#endif /* __SANDBOX_SCMI_TEST_H */
diff --git
[PATCH v4 5/8] clk: add clock driver for SCMI agents
This change introduces a clock driver for SCMI agent devices. When
SCMI agent and SCMI clock drivers are enabled, SCMI agent binds a
clock device for each SCMI clock protocol devices enabled in the FDT.
SCMI clock driver is embedded upon CONFIG_CLK_SCMI=y. If enabled,
CONFIG_SCMI_AGENT is also enabled.
SCMI Clock protocol is defined in the SCMI specification [1].
Links: [1]
https://developer.arm.com/architectures/system-architectures/software-standards/scmi
Signed-off-by: Etienne Carriere
Cc: Lukasz Majewski
Cc: Simon Glass
Cc: Peng Fan
Cc: Sudeep Holla
---
Changes in v4:
- Condition DM_GET_DRIVER(scmi_clock) to IS_ENABLED(CONFIG_CLK_SCMI)
to prevent a build error (linker) when CONFIG_CLK_SCMI is disabled.
Changes in v3:
- Rebased in the series without major conflict.
Changes in v2:
- CONFIG_CLK_SCMI depends on CONFIG_SCMI_FIRMWARE instead of
selecting CONFIG_SCMI_FIRMWARE.
- Add inline comment description for structures and moves them to
source file top. Add/fixup some functions inline description comments.
- Replace rc with ret as return value local variable label.
- Fix scmi_clk_get_rate() return value to propagate error number.
- Fix scmi_clk_set_rate() to request synchronous rate set operation:
drop flag SCMI_CLK_RATE_ASYNC_NORESP in the SCMI message payload.
- Fix scmi_clk_set_rate() return value to return clock effective rate
on success.
---
drivers/clk/Kconfig | 8 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk_scmi.c| 99 +++
drivers/firmware/scmi/scmi_agent-uclass.c | 14 +++-
include/scmi_protocols.h | 78 ++
5 files changed, 197 insertions(+), 3 deletions(-)
create mode 100644 drivers/clk/clk_scmi.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 6003e140b5..4dfbad7986 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -159,6 +159,14 @@ config CLK_CDCE9XX
Enable the clock synthesizer driver for CDCE913/925/937/949
series of chips.
+config CLK_SCMI
+ bool "Enable SCMI clock driver"
+ depends on SCMI_FIRMWARE
+ help
+ Enable this option if you want to support clock devices exposed
+ by a SCMI agent based on SCMI clock protocol communication
+ with a SCMI server.
+
source "drivers/clk/analogbits/Kconfig"
source "drivers/clk/at91/Kconfig"
source "drivers/clk/exynos/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index cda4b4b605..d1e295ac7c 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
obj-$(CONFIG_CLK_OCTEON) += clk_octeon.o
obj-$(CONFIG_CLK_OWL) += owl/
obj-$(CONFIG_CLK_RENESAS) += renesas/
+obj-$(CONFIG_CLK_SCMI) += clk_scmi.o
obj-$(CONFIG_CLK_SIFIVE) += sifive/
obj-$(CONFIG_ARCH_SUNXI) += sunxi/
obj-$(CONFIG_CLK_STM32F) += clk_stm32f.o
diff --git a/drivers/clk/clk_scmi.c b/drivers/clk/clk_scmi.c
new file mode 100644
index 00..93a4819501
--- /dev/null
+++ b/drivers/clk/clk_scmi.c
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-2020 Linaro Limited
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int scmi_clk_gate(struct clk *clk, int enable)
+{
+ struct scmi_clk_state_in in = {
+ .clock_id = clk->id,
+ .attributes = enable,
+ };
+ struct scmi_clk_state_out out;
+ struct scmi_msg msg = SCMI_MSG_IN(SCMI_PROTOCOL_ID_CLOCK,
+ SCMI_CLOCK_CONFIG_SET,
+ in, out);
+ int ret;
+
+ ret = devm_scmi_process_msg(clk->dev->parent, );
+ if (ret)
+ return ret;
+
+ return scmi_to_linux_errno(out.status);
+}
+
+static int scmi_clk_enable(struct clk *clk)
+{
+ return scmi_clk_gate(clk, 1);
+}
+
+static int scmi_clk_disable(struct clk *clk)
+{
+ return scmi_clk_gate(clk, 0);
+}
+
+static ulong scmi_clk_get_rate(struct clk *clk)
+{
+ struct scmi_clk_rate_get_in in = {
+ .clock_id = clk->id,
+ };
+ struct scmi_clk_rate_get_out out;
+ struct scmi_msg msg = SCMI_MSG_IN(SCMI_PROTOCOL_ID_CLOCK,
+ SCMI_CLOCK_RATE_GET,
+ in, out);
+ int ret;
+
+ ret = devm_scmi_process_msg(clk->dev->parent, );
+ if (ret < 0)
+ return ret;
+
+ ret = scmi_to_linux_errno(out.status);
+ if (ret < 0)
+ return ret;
+
+ return (ulong)(((u64)out.rate_msb << 32) | out.rate_lsb);
+}
+
+static ulong scmi_clk_set_rate(struct clk *clk, ulong rate)
+{
+ struct scmi_clk_rate_set_in in = {
+ .clock_id = clk->id,
+ .flags = SCMI_CLK_RATE_ROUND_CLOSEST,
+ .rate_lsb = (u32)rate,
+ .rate_msb = (u32)((u64)rate >> 32),
+ };
+
[PATCH v4 4/8] dt-bindings: arm: SCMI bindings documentation
Dump SCMI DT bindings documentation from Linux kernel source
tree v5.8-rc1.
Signed-off-by: Etienne Carriere
Reviewed-by: Simon Glass
---
No change in v4.
No change in v3.
Changes in v2:
- No change but added R-b tag.
- Yet a question: do we need to add this binding doc in U-Boot
since already existing in Linux DT bindings docs? Related to review
comment https://www.mail-archive.com/u-boot@lists.denx.de/msg377725.html
---
doc/device-tree-bindings/arm/arm,scmi.txt | 197 ++
1 file changed, 197 insertions(+)
create mode 100644 doc/device-tree-bindings/arm/arm,scmi.txt
diff --git a/doc/device-tree-bindings/arm/arm,scmi.txt
b/doc/device-tree-bindings/arm/arm,scmi.txt
new file mode 100644
index 00..1f293ea24c
--- /dev/null
+++ b/doc/device-tree-bindings/arm/arm,scmi.txt
@@ -0,0 +1,197 @@
+System Control and Management Interface (SCMI) Message Protocol
+--
+
+The SCMI is intended to allow agents such as OSPM to manage various functions
+that are provided by the hardware platform it is running on, including power
+and performance functions.
+
+This binding is intended to define the interface the firmware implementing
+the SCMI as described in ARM document number ARM DEN 0056A ("ARM System Control
+and Management Interface Platform Design Document")[0] provide for OSPM in
+the device tree.
+
+Required properties:
+
+The scmi node with the following properties shall be under the /firmware/ node.
+
+- compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports
+- mboxes: List of phandle and mailbox channel specifiers. It should contain
+ exactly one or two mailboxes, one for transmitting messages("tx")
+ and another optional for receiving the notifications("rx") if
+ supported.
+- shmem : List of phandle pointing to the shared memory(SHM) area as per
+ generic mailbox client binding.
+- #address-cells : should be '1' if the device has sub-nodes, maps to
+ protocol identifier for a given sub-node.
+- #size-cells : should be '0' as 'reg' property doesn't have any size
+ associated with it.
+- arm,smc-id : SMC id required when using smc or hvc transports
+
+Optional properties:
+
+- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
+
+See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
+about the generic mailbox controller and client driver bindings.
+
+The mailbox is the only permitted method of calling the SCMI firmware.
+Mailbox doorbell is used as a mechanism to alert the presence of a
+messages and/or notification.
+
+Each protocol supported shall have a sub-node with corresponding compatible
+as described in the following sections. If the platform supports dedicated
+communication channel for a particular protocol, the 3 properties namely:
+mboxes, mbox-names and shmem shall be present in the sub-node corresponding
+to that protocol.
+
+Clock/Performance bindings for the clocks/OPPs based on SCMI Message Protocol
+
+
+This binding uses the common clock binding[1].
+
+Required properties:
+- #clock-cells : Should be 1. Contains the Clock ID value used by SCMI
commands.
+
+Power domain bindings for the power domains based on SCMI Message Protocol
+
+
+This binding for the SCMI power domain providers uses the generic power
+domain binding[2].
+
+Required properties:
+ - #power-domain-cells : Should be 1. Contains the device or the power
+domain ID value used by SCMI commands.
+
+Sensor bindings for the sensors based on SCMI Message Protocol
+--
+SCMI provides an API to access the various sensors on the SoC.
+
+Required properties:
+- #thermal-sensor-cells: should be set to 1. This property follows the
+thermal device tree bindings[3].
+
+Valid cell values are raw identifiers (Sensor ID)
+as used by the firmware. Refer to platform details
+for your implementation for the IDs to use.
+
+Reset signal bindings for the reset domains based on SCMI Message Protocol
+
+
+This binding for the SCMI reset domain providers uses the generic reset
+signal binding[5].
+
+Required properties:
+ - #reset-cells : Should be 1. Contains the reset domain ID value used
+ by SCMI commands.
+
+SRAM and Shared Memory for SCMI
+---
+
+A small area of SRAM is reserved for SCMI communication between application
+processors and SCP.
+
+The properties should follow the generic mmio-sram description found in [4]
+
+Each sub-node represents the reserved area for SCMI.
+
+Required sub-node properties:
+- reg : The base offset and size of the reserved area
[PATCH v4 3/8] firmware: scmi: support Arm SMCCC transport
This change implements a SMCCC transport for SCMI exchanges. This
implementation follows the Linux kernel as references implementation
for SCMI message processing, using the SMT format for communication
channel meta-data.
Use of SMCCC transport in SCMI FDT bindings are defined in the Linux
kernel DT bindings since v5.8. SMCCC with SMT is implemented in OP-TEE
from tag 3.9.0 [2].
Links: [2] https://github.com/OP-TEE/optee_os/commit/a58c4d706d23
Signed-off-by: Etienne Carriere
Cc: Simon Glass
Cc: Peng Fan
Cc: Sudeep Holla
---
Changes in v4:
- Update CONFIG_SCMI_FIRMWARE dependencies regarding CONFIG_ARM_SMCCC.
- Remove useless cast hence remove helper dev2agent() to get dev private.
- Fix header file inclusion ordering.
Changes in v3:
- This is a followup of the SCMI agent patches posted in
https://patchwork.ozlabs.org/project/uboot/list/?series=196253
The v3 splits commits and introduces a new uclass as requested.
- This patch implements the same Arm SMCCC SCMI agent as presented
in v2 but in its own source file smccc_agent.c, and based in smt.h.
---
drivers/firmware/scmi/Kconfig | 6 +-
drivers/firmware/scmi/Makefile | 1 +
drivers/firmware/scmi/smccc_agent.c | 89 +
3 files changed, 93 insertions(+), 3 deletions(-)
create mode 100644 drivers/firmware/scmi/smccc_agent.c
diff --git a/drivers/firmware/scmi/Kconfig b/drivers/firmware/scmi/Kconfig
index c501bf4943..c3a109beac 100644
--- a/drivers/firmware/scmi/Kconfig
+++ b/drivers/firmware/scmi/Kconfig
@@ -2,7 +2,7 @@ config SCMI_FIRMWARE
bool "Enable SCMI support"
select FIRMWARE
select OF_TRANSLATE
- depends on SANDBOX || DM_MAILBOX
+ depends on SANDBOX || DM_MAILBOX || ARM_SMCCC
help
System Control and Management Interface (SCMI) is a communication
protocol that defines standard interfaces for power, performance
@@ -15,5 +15,5 @@ config SCMI_FIRMWARE
Communications between agent (client) and the SCMI server are
based on message exchange. Messages can be exchange over tranport
- channels as a mailbox device with some piece of identified shared
- memory.
+ channels as a mailbox device or an Arm SMCCC service with some
+ piece of identified shared memory.
diff --git a/drivers/firmware/scmi/Makefile b/drivers/firmware/scmi/Makefile
index d22f53efe7..2f782bbd55 100644
--- a/drivers/firmware/scmi/Makefile
+++ b/drivers/firmware/scmi/Makefile
@@ -1,4 +1,5 @@
obj-y += scmi_agent-uclass.o
obj-y += smt.o
+obj-$(CONFIG_ARM_SMCCC)+= smccc_agent.o
obj-$(CONFIG_DM_MAILBOX) += mailbox_agent.o
obj-$(CONFIG_SANDBOX) += sandbox-scmi_agent.o
diff --git a/drivers/firmware/scmi/smccc_agent.c
b/drivers/firmware/scmi/smccc_agent.c
new file mode 100644
index 00..85dbf9195e
--- /dev/null
+++ b/drivers/firmware/scmi/smccc_agent.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Limited.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "smt.h"
+
+#define SMCCC_RET_NOT_SUPPORTED ((unsigned long)-1)
+
+/**
+ * struct scmi_smccc_channel - Description of an SCMI SMCCC transport
+ * @func_id: SMCCC function ID used by the SCMI transport
+ * @smt: Shared memory buffer
+ */
+struct scmi_smccc_channel {
+ ulong func_id;
+ struct scmi_smt smt;
+};
+
+static int scmi_smccc_process_msg(struct udevice *dev, struct scmi_msg *msg)
+{
+ struct scmi_smccc_channel *chan = dev_get_priv(dev);
+ struct arm_smccc_res res;
+ int ret;
+
+ ret = scmi_write_msg_to_smt(dev, >smt, msg);
+ if (ret)
+ return ret;
+
+ arm_smccc_smc(chan->func_id, 0, 0, 0, 0, 0, 0, 0, );
+ if (res.a0 == SMCCC_RET_NOT_SUPPORTED)
+ ret = -ENXIO;
+ else
+ ret = scmi_read_resp_from_smt(dev, >smt, msg);
+
+ scmi_clear_smt_channel(>smt);
+
+ return ret;
+}
+
+static int scmi_smccc_probe(struct udevice *dev)
+{
+ struct scmi_smccc_channel *chan = dev_get_priv(dev);
+ u32 func_id;
+ int ret;
+
+ if (dev_read_u32(dev, "arm,smc-id", _id)) {
+ dev_err(dev, "Missing property func-id\n");
+ return -EINVAL;
+ }
+
+ chan->func_id = func_id;
+
+ ret = scmi_dt_get_smt_buffer(dev, >smt);
+ if (ret) {
+ dev_err(dev, "Failed to get smt resources: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct udevice_id scmi_smccc_ids[] = {
+ { .compatible = "arm,scmi-smc" },
+ { }
+};
+
+static const struct scmi_agent_ops scmi_smccc_ops = {
+ .process_msg = scmi_smccc_process_msg,
+};
+
+U_BOOT_DRIVER(scmi_smccc) = {
+ .name = "scmi-over-smccc",
+ .id = UCLASS_SCMI_AGENT,
+ .of_match = scmi_smccc_ids,
+
[PATCH v4 2/8] firmware: scmi: mailbox/smt agent device
This change implements a mailbox transport using SMT format for SCMI
exchanges. This implementation follows the Linux kernel and
SCP-firmware [1] as references implementation for SCMI message
processing using SMT format for communication channel meta-data.
Use of mailboxes in SCMI FDT bindings are defined in the Linux kernel
DT bindings since v4.17.
Links: [1] https://github.com/ARM-software/SCP-firmware
Signed-off-by: Etienne Carriere
Cc: Simon Glass
Cc: Peng Fan
Cc: Sudeep Holla
---
Changes in v4:
- Replace __arm__ with CONFIG_ARM.
- Remove cast for priv reference hence remove helper scmi_mbox_get_priv().
Changes in v3:
- This is a followup of the SCMI agent patches posted in
https://patchwork.ozlabs.org/project/uboot/list/?series=196253
The v3 splits commits and introduces a new uclass as requested.
- This patch implements the same mailbox SCMI agent proposed in v2
but split over few source files.
---
drivers/firmware/scmi/Kconfig | 6 +-
drivers/firmware/scmi/Makefile| 2 +
drivers/firmware/scmi/mailbox_agent.c | 102 +++
drivers/firmware/scmi/smt.c | 139 ++
drivers/firmware/scmi/smt.h | 86
5 files changed, 333 insertions(+), 2 deletions(-)
create mode 100644 drivers/firmware/scmi/mailbox_agent.c
create mode 100644 drivers/firmware/scmi/smt.c
create mode 100644 drivers/firmware/scmi/smt.h
diff --git a/drivers/firmware/scmi/Kconfig b/drivers/firmware/scmi/Kconfig
index 57e2ebbe42..c501bf4943 100644
--- a/drivers/firmware/scmi/Kconfig
+++ b/drivers/firmware/scmi/Kconfig
@@ -2,7 +2,7 @@ config SCMI_FIRMWARE
bool "Enable SCMI support"
select FIRMWARE
select OF_TRANSLATE
- depends on SANDBOX
+ depends on SANDBOX || DM_MAILBOX
help
System Control and Management Interface (SCMI) is a communication
protocol that defines standard interfaces for power, performance
@@ -14,4 +14,6 @@ config SCMI_FIRMWARE
or a companion host in the CPU system.
Communications between agent (client) and the SCMI server are
- based on message exchange.
+ based on message exchange. Messages can be exchange over tranport
+ channels as a mailbox device with some piece of identified shared
+ memory.
diff --git a/drivers/firmware/scmi/Makefile b/drivers/firmware/scmi/Makefile
index 336ea1f2a3..d22f53efe7 100644
--- a/drivers/firmware/scmi/Makefile
+++ b/drivers/firmware/scmi/Makefile
@@ -1,2 +1,4 @@
obj-y += scmi_agent-uclass.o
+obj-y += smt.o
+obj-$(CONFIG_DM_MAILBOX) += mailbox_agent.o
obj-$(CONFIG_SANDBOX) += sandbox-scmi_agent.o
diff --git a/drivers/firmware/scmi/mailbox_agent.c
b/drivers/firmware/scmi/mailbox_agent.c
new file mode 100644
index 00..7d9fb3622e
--- /dev/null
+++ b/drivers/firmware/scmi/mailbox_agent.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Limited.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "smt.h"
+
+#define TIMEOUT_US_10MS1
+
+/**
+ * struct scmi_mbox_channel - Description of an SCMI mailbox transport
+ * @smt: Shared memory buffer
+ * @mbox: Mailbox channel description
+ * @timeout_us:Timeout in microseconds for the mailbox transfer
+ */
+struct scmi_mbox_channel {
+ struct scmi_smt smt;
+ struct mbox_chan mbox;
+ ulong timeout_us;
+};
+
+static int scmi_mbox_process_msg(struct udevice *dev, struct scmi_msg *msg)
+{
+ struct scmi_mbox_channel *chan = dev_get_priv(dev);
+ int ret;
+
+ ret = scmi_write_msg_to_smt(dev, >smt, msg);
+ if (ret)
+ return ret;
+
+ /* Give shm addr to mbox in case it is meaningful */
+ ret = mbox_send(>mbox, chan->smt.buf);
+ if (ret) {
+ dev_err(dev, "Message send failed: %d\n", ret);
+ goto out;
+ }
+
+ /* Receive the response */
+ ret = mbox_recv(>mbox, chan->smt.buf, chan->timeout_us);
+ if (ret) {
+ dev_err(dev, "Response failed: %d, abort\n", ret);
+ goto out;
+ }
+
+ ret = scmi_read_resp_from_smt(dev, >smt, msg);
+
+out:
+ scmi_clear_smt_channel(>smt);
+
+ return ret;
+}
+
+int scmi_mbox_probe(struct udevice *dev)
+{
+ struct scmi_mbox_channel *chan = dev_get_priv(dev);
+ int ret;
+
+ chan->timeout_us = TIMEOUT_US_10MS;
+
+ ret = mbox_get_by_index(dev, 0, >mbox);
+ if (ret) {
+ dev_err(dev, "Failed to find mailbox: %d\n", ret);
+ goto out;
+ }
+
+ ret = scmi_dt_get_smt_buffer(dev, >smt);
+ if (ret)
+ dev_err(dev, "Failed to get shm resources: %d\n", ret);
+
+out:
+ if (ret)
+ devm_kfree(dev, chan);
+
+ return ret;
+}
+
+static const struct udevice_id scmi_mbox_ids[] = {
+
[PATCH v4 1/8] firmware: add SCMI agent uclass
This change introduces SCMI agent uclass to interact with a firmware
using the SCMI protocols [1].
SCMI agent uclass currently supports a single method to request
processing of the SCMI message by an identified server. A SCMI message
is made of a byte payload associated to a protocol ID and a message ID,
all defined by the SCMI specification [1]. On return from process_msg()
method, the caller gets the service response.
SCMI agent uclass defines a post bind generic sequence for all devices.
The sequence binds all the SCMI protocols listed in the FDT for that
SCMI agent device. Currently none, but later change will introduce
protocols.
This change implements a simple sandbox device for the SCMI agent uclass.
The sandbox nicely answers SCMI_NOT_SUPPORTED to SCMI messages.
To prepare for further test support, the sandbox exposes a architecture
function for test application to read the sandbox emulated devices state.
Currently supports 2 SCMI agents, identified by an ID in the FDT device
name. The simplistic DM test does nothing yet.
SCMI agent uclass is designed for platforms that embed a SCMI server in
a firmware hosted somewhere, for example in a companion co-processor or
in the secure world of the executing processor. SCMI protocols allow an
SCMI agent to discover and access external resources as clock, reset
controllers and more. SCMI agent and server communicate following the
SCMI specification [1]. This SCMI agent implementation complies with
the DT bindings defined in the Linux kernel source tree regarding
SCMI agent description since v5.8.
Links: [1]
https://developer.arm.com/architectures/system-architectures/software-standards/scmi
Signed-off-by: Etienne Carriere
Cc: Simon Glass
Cc: Peng Fan
Cc: Sudeep Holla
Reviewed-by: Simon Glass
---
Changes in v4:
- Remove local helper function dev2agent() used to hide a useless cast.
Changes in v3:
- Address comments about adding a new uclass and some sandbox test from
v2 in https://patchwork.ozlabs.org/project/uboot/list/?series=196253
- New directory drivers/firmware/scmi/. The path mimics Linux kernel
source tree for the equivalent driver.
- Split scmi.h (patch v2) into scmi_protocols.h, scmi_agent.h and
scmi_agent-uclass.h.
- Create new uclass UCLASS_SCMI_AGENT.
- Introduce a simple sandbox on that agent. Mailbox and smccc agents are
moved to specific commits in the series.
Changes in v2:
- Fix CONFIG_SCMI_FIRMWARE description with explicit SCMI reference.
- Move struct, enum and macro definitions at source file top and
add inline comment description for the structures and local functions.
- Replace rc with ret as return value local variable label.
- Use explicit return 0 on successful return paths.
- Replace EINVAL with more accurate error numbers.
- Use dev_read_u32() instead of ofnode_read_u32(dev_ofnode(), ...).
- Use memcpy_toio()/memcpy_fromio() when copying message payload
to/from IO memory.
- Embed mailbox transport resources upon CONFIG_DM_MAILBOX and
SMCCC transport resources upon CONFIG_ARM_SMCCC.
Note: review comments on defining a uclass and sandbox for SCMI
transport drivers are NOT addressed in this v2. Main issue is that
there is no driver/device defined for SCMI transport layer as well as
and no defined compatible ID in the SCMI DT bindings documentation.
---
arch/sandbox/dts/test.dts | 16 +++
arch/sandbox/include/asm/scmi_test.h | 43 +++
configs/sandbox_defconfig | 2 +
drivers/firmware/Kconfig | 2 +
drivers/firmware/Makefile | 1 +
drivers/firmware/scmi/Kconfig | 17 +++
drivers/firmware/scmi/Makefile | 2 +
drivers/firmware/scmi/sandbox-scmi_agent.c | 142 +
drivers/firmware/scmi/scmi_agent-uclass.c | 107
include/dm/uclass-id.h | 1 +
include/scmi_agent-uclass.h| 24
include/scmi_agent.h | 68 ++
include/scmi_protocols.h | 41 ++
test/dm/Makefile | 1 +
test/dm/scmi.c | 38 ++
15 files changed, 505 insertions(+)
create mode 100644 arch/sandbox/include/asm/scmi_test.h
create mode 100644 drivers/firmware/scmi/Kconfig
create mode 100644 drivers/firmware/scmi/Makefile
create mode 100644 drivers/firmware/scmi/sandbox-scmi_agent.c
create mode 100644 drivers/firmware/scmi/scmi_agent-uclass.c
create mode 100644 include/scmi_agent-uclass.h
create mode 100644 include/scmi_agent.h
create mode 100644 include/scmi_protocols.h
create mode 100644 test/dm/scmi.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 9f45c48e4e..dd3b43885e 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -356,6 +356,22 @@
sandbox_firmware: sandbox-firmware {
compatible = "sandbox,firmware";
};
+
+
[PATCH] net: dwc_eth_qos: Convert to use APIs which support live DT
Use ofnode_ or dev_ APIs instead of fdt_ and fdtdec_ APIs so that the
driver can support live DT.
Signed-off-by: Patrick Delaunay
---
drivers/net/dwc_eth_qos.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 810a2b95b1..db1102562f 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -26,6 +26,7 @@
*supports a single RGMII PHY. This configuration also has SW control over
*all clock and reset signals to the HW block.
*/
+
#include
#include
#include
@@ -1893,8 +1894,7 @@ static phy_interface_t eqos_get_interface_stm32(struct
udevice *dev)
debug("%s(dev=%p):\n", __func__, dev);
- phy_mode = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), "phy-mode",
- NULL);
+ phy_mode = dev_read_prop(dev, "phy-mode", NULL);
if (phy_mode)
interface = phy_get_interface_by_name(phy_mode);
@@ -1931,8 +1931,7 @@ static phy_interface_t eqos_get_interface_imx(struct
udevice *dev)
debug("%s(dev=%p):\n", __func__, dev);
- phy_mode = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), "phy-mode",
- NULL);
+ phy_mode = dev_read_prop(dev, "phy-mode", NULL);
if (phy_mode)
interface = phy_get_interface_by_name(phy_mode);
--
2.17.1
[PATCH 1/2] gpio: stm32: cosmetic: cleanup gpio_stm32_probe
Move the variables definition at the beggining of the function
gpio_stm32_probe().
Signed-off-by: Patrick Delaunay
---
drivers/gpio/stm32_gpio.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c
index 5bff27f75b..aa70b1d2a9 100644
--- a/drivers/gpio/stm32_gpio.c
+++ b/drivers/gpio/stm32_gpio.c
@@ -273,9 +273,12 @@ static const struct dm_gpio_ops gpio_stm32_ops = {
static int gpio_stm32_probe(struct udevice *dev)
{
struct stm32_gpio_priv *priv = dev_get_priv(dev);
+ struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+ struct ofnode_phandle_args args;
+ const char *name;
struct clk clk;
fdt_addr_t addr;
- int ret;
+ int ret, i;
addr = dev_read_addr(dev);
if (addr == FDT_ADDR_T_NONE)
@@ -283,11 +286,6 @@ static int gpio_stm32_probe(struct udevice *dev)
priv->regs = (struct stm32_gpio_regs *)addr;
- struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
- struct ofnode_phandle_args args;
- const char *name;
- int i;
-
name = dev_read_string(dev, "st,bank-name");
if (!name)
return -EINVAL;
--
2.17.1
[PATCH 2/2] gpio: stm32: check result of ofnode_phandle_args
Add test on the size of ofnode_phandle_args result to avoid access
to uninitialized elements in args[] field.
This patch avoids the issue when gpio-ranges cell size is not 3 as
expected, for example:
gpio-ranges = < 0>;
instead of
gpio-ranges = < 0 112 16>;
Signed-off-by: Patrick Delaunay
---
drivers/gpio/stm32_gpio.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c
index aa70b1d2a9..473e364796 100644
--- a/drivers/gpio/stm32_gpio.c
+++ b/drivers/gpio/stm32_gpio.c
@@ -295,6 +295,9 @@ static int gpio_stm32_probe(struct udevice *dev)
ret = dev_read_phandle_with_args(dev, "gpio-ranges",
NULL, 3, i, );
+ if (!ret && args.args_count < 3)
+ return -EINVAL;
+
if (ret == -ENOENT) {
uc_priv->gpio_count = STM32_GPIOS_PER_BANK;
priv->gpio_range = GENMASK(STM32_GPIOS_PER_BANK - 1, 0);
@@ -308,6 +311,8 @@ static int gpio_stm32_probe(struct udevice *dev)
ret = dev_read_phandle_with_args(dev, "gpio-ranges", NULL, 3,
++i, );
+ if (!ret && args.args_count < 3)
+ return -EINVAL;
}
dev_dbg(dev, "addr = 0x%p bank_name = %s gpio_count = %d gpio_range =
0x%x\n",
--
2.17.1
[PATCH] gpio: Convert to use APIs which support live DT
Use ofnode_ or dev_ APIs instead of fdt_ and fdtdec_ APIs so that the
driver can support live DT.
Signed-off-by: Patrick Delaunay
---
drivers/gpio/gpio-uclass.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 9c53299b6a..1d3255ca60 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -1098,9 +1098,8 @@ int gpio_get_list_count(struct udevice *dev, const char
*list_name)
{
int ret;
- ret = fdtdec_parse_phandle_with_args(gd->fdt_blob, dev_of_offset(dev),
-list_name, "#gpio-cells", 0, -1,
-NULL);
+ ret = dev_read_phandle_with_args(dev, list_name, "#gpio-cells", 0, -1,
+NULL);
if (ret) {
debug("%s: Node '%s', property '%s', GPIO count failed: %d\n",
__func__, dev->name, list_name, ret);
--
2.17.1
[PATCH v5] cmd: mem: fix range of bitflip test
The bitflip test uses two equal sized memory buffers. This is achieved
by splitting the range of memory into two pieces. The address of the
second buffer, as well as the length of each buffer, were not correctly
calculated. This caused bitflip test to access beyond the end of range.
This patch fixes the pointer arithmetic problem.
A second problem arises because u-boot "mtest" command expects the
ending address to be inclusive. When computing (end - start) this
results in missing 1 byte of the requested length. The bitflip test
expects a count rather than an "ending" address. Thus it fails to test
the last word of the requested range. Fixed by using (end - start + 1).
Added Kconfig option to optionally disable the bitflip test, since it
does add significantly to the time taken for "mtest".
Fixes: 8e434cb705d463bc8cff935160e4fb4c77cb99ab ("cmd: mem: Add bitflip
memory test to alternate mtest")
Signed-off-by: Ralph Siemsen
--
Changes in v5:
- Correct logic for updating error count
Changes in v4:
- Avoid #ifdef in the code
Change-Id: Ie641d04e731fc5bc6a3bbef914bf7fad136cdc94
---
cmd/Kconfig | 12
cmd/mem.c | 21 -
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index d54acf2cfd..275bf7fbfe 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -779,6 +779,18 @@ config SYS_ALT_MEMTEST
help
Use a more complete alternative memory test.
+if SYS_ALT_MEMTEST
+
+config SYS_ALT_MEMTEST_BITFLIP
+ bool "Bitflip test"
+ default y
+ help
+ The alternative memory test includes bitflip test since 2020.07.
+ The bitflip test significantly increases the overall test time.
+ Bitflip test can optionally be disabled here.
+
+endif
+
config SYS_MEMTEST_START
hex "default start address for mtest"
default 0
diff --git a/cmd/mem.c b/cmd/mem.c
index 9b97f7bf69..dc4a0ffab3 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -867,6 +867,18 @@ static ulong test_bitflip_comparison(volatile unsigned
long *bufa,
return errs;
}
+static ulong mem_test_bitflip(vu_long *buf, ulong start, ulong end)
+{
+ /*
+* Split the specified range into two halves.
+* Note that mtest range is inclusive of start,end.
+* Bitflip test instead uses a count (of 32-bit words).
+*/
+ ulong half_size = (end - start + 1) / 2 / sizeof(unsigned long);
+
+ return test_bitflip_comparison(buf, buf + half_size, half_size);
+}
+
static ulong mem_test_quick(vu_long *buf, ulong start_addr, ulong end_addr,
vu_long pattern, int iteration)
{
@@ -986,11 +998,10 @@ static int do_mem_mtest(struct cmd_tbl *cmdtp, int flag,
int argc,
errs = mem_test_alt(buf, start, end, dummy);
if (errs == -1UL)
break;
- count += errs;
- errs = test_bitflip_comparison(buf,
- buf + (end - start) / 2,
- (end - start) /
- sizeof(unsigned long));
+ if (IS_ENABLED(CONFIG_SYS_ALT_MEMTEST_BITFLIP)) {
+ count += errs;
+ errs = mem_test_bitflip(buf, start, end);
+ }
} else {
errs = mem_test_quick(buf, start, end, pattern,
iteration);
--
2.17.1
[PATCH 2/2] pinctrl: stm32: Add header with SPDX licence
Cosmetics: Add header with SPDX licence Signed-off-by: Patrick Delaunay --- drivers/pinctrl/pinctrl_stm32.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/pinctrl/pinctrl_stm32.c b/drivers/pinctrl/pinctrl_stm32.c index 24ed83dd46..dbea99532c 100644 --- a/drivers/pinctrl/pinctrl_stm32.c +++ b/drivers/pinctrl/pinctrl_stm32.c @@ -1,3 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2017-2020 STMicroelectronics - All Rights Reserved + */ + #include #include #include -- 2.17.1
[PATCH 1/2] pinctrl: stm32: Convert to use APIs which support live DT
Use ofnode_ or dev_ APIs instead of fdt_ and fdtdec_ APIs so that the
driver can support live DT.
Signed-off-by: Patrick Delaunay
---
drivers/pinctrl/pinctrl_stm32.c | 43 ++---
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/pinctrl/pinctrl_stm32.c b/drivers/pinctrl/pinctrl_stm32.c
index 71fa29a389..24ed83dd46 100644
--- a/drivers/pinctrl/pinctrl_stm32.c
+++ b/drivers/pinctrl/pinctrl_stm32.c
@@ -13,8 +13,6 @@
#include
#include
-DECLARE_GLOBAL_DATA_PTR;
-
#define MAX_PINS_ONE_IP70
#define MODE_BITS_MASK 3
#define OSPEED_MASK3
@@ -308,7 +306,8 @@ static int prep_gpio_dsc(struct stm32_gpio_dsc *gpio_dsc,
u32 port_pin)
return 0;
}
-static int prep_gpio_ctl(struct stm32_gpio_ctl *gpio_ctl, u32 gpio_fn, int
node)
+static int prep_gpio_ctl(struct stm32_gpio_ctl *gpio_ctl, u32 gpio_fn,
+ofnode node)
{
gpio_fn &= 0x00FF;
gpio_ctl->af = 0;
@@ -329,16 +328,16 @@ static int prep_gpio_ctl(struct stm32_gpio_ctl *gpio_ctl,
u32 gpio_fn, int node)
break;
}
- gpio_ctl->speed = fdtdec_get_int(gd->fdt_blob, node, "slew-rate", 0);
+ gpio_ctl->speed = ofnode_read_u32_default(node, "slew-rate", 0);
- if (fdtdec_get_bool(gd->fdt_blob, node, "drive-open-drain"))
+ if (ofnode_read_bool(node, "drive-open-drain"))
gpio_ctl->otype = STM32_GPIO_OTYPE_OD;
else
gpio_ctl->otype = STM32_GPIO_OTYPE_PP;
- if (fdtdec_get_bool(gd->fdt_blob, node, "bias-pull-up"))
+ if (ofnode_read_bool(node, "bias-pull-up"))
gpio_ctl->pupd = STM32_GPIO_PUPD_UP;
- else if (fdtdec_get_bool(gd->fdt_blob, node, "bias-pull-down"))
+ else if (ofnode_read_bool(node, "bias-pull-down"))
gpio_ctl->pupd = STM32_GPIO_PUPD_DOWN;
else
gpio_ctl->pupd = STM32_GPIO_PUPD_NO;
@@ -350,32 +349,37 @@ static int prep_gpio_ctl(struct stm32_gpio_ctl *gpio_ctl,
u32 gpio_fn, int node)
return 0;
}
-static int stm32_pinctrl_config(int offset)
+static int stm32_pinctrl_config(ofnode node)
{
u32 pin_mux[MAX_PINS_ONE_IP];
int rv, len;
+ ofnode subnode;
/*
* check for "pinmux" property in each subnode (e.g. pins1 and pins2 for
* usart1) of pin controller phandle "pinctrl-0"
* */
- fdt_for_each_subnode(offset, gd->fdt_blob, offset) {
+ ofnode_for_each_subnode(subnode, node) {
struct stm32_gpio_dsc gpio_dsc;
struct stm32_gpio_ctl gpio_ctl;
int i;
- len = fdtdec_get_int_array_count(gd->fdt_blob, offset,
-"pinmux", pin_mux,
-ARRAY_SIZE(pin_mux));
+ rv = ofnode_read_size(subnode, "pinmux");
+ if (rv < 0)
+ return rv;
+ len = rv / sizeof(pin_mux[0]);
debug("%s: no of pinmux entries= %d\n", __func__, len);
- if (len < 0)
+ if (len > MAX_PINS_ONE_IP)
return -EINVAL;
+ rv = ofnode_read_u32_array(subnode, "pinmux", pin_mux, len);
+ if (rv < 0)
+ return rv;
for (i = 0; i < len; i++) {
struct gpio_desc desc;
debug("%s: pinmux = %x\n", __func__, *(pin_mux + i));
prep_gpio_dsc(_dsc, *(pin_mux + i));
- prep_gpio_ctl(_ctl, *(pin_mux + i), offset);
+ prep_gpio_ctl(_ctl, *(pin_mux + i), subnode);
rv = uclass_get_device_by_seq(UCLASS_GPIO,
gpio_dsc.port,
);
@@ -424,19 +428,18 @@ static int stm32_pinctrl_bind(struct udevice *dev)
#if CONFIG_IS_ENABLED(PINCTRL_FULL)
static int stm32_pinctrl_set_state(struct udevice *dev, struct udevice *config)
{
- return stm32_pinctrl_config(dev_of_offset(config));
+ return stm32_pinctrl_config(dev_ofnode(config));
}
#else /* PINCTRL_FULL */
static int stm32_pinctrl_set_state_simple(struct udevice *dev,
struct udevice *periph)
{
- const void *fdt = gd->fdt_blob;
const fdt32_t *list;
uint32_t phandle;
- int config_node;
+ ofnode config_node;
int size, i, ret;
- list = fdt_getprop(fdt, dev_of_offset(periph), "pinctrl-0", );
+ list = ofnode_get_property(dev_ofnode(periph), "pinctrl-0", );
if (!list)
return -EINVAL;
@@ -446,8 +449,8 @@ static int stm32_pinctrl_set_state_simple(struct udevice
*dev,
for (i = 0; i < size; i++) {
phandle = fdt32_to_cpu(*list++);
- config_node =
[PATCH] mailbox: stm32_ipcc: Convert to use APIs which support live DT
Use ofnode_ or dev_ APIs instead of fdt_ and fdtdec_ APIs so that the
driver can support live DT.
Signed-off-by: Patrick Delaunay
---
drivers/mailbox/stm32-ipcc.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/mailbox/stm32-ipcc.c b/drivers/mailbox/stm32-ipcc.c
index b8bf356b4a..81a4115986 100644
--- a/drivers/mailbox/stm32-ipcc.c
+++ b/drivers/mailbox/stm32-ipcc.c
@@ -101,9 +101,8 @@ static int stm32_ipcc_probe(struct udevice *dev)
{
struct stm32_ipcc *ipcc = dev_get_priv(dev);
fdt_addr_t addr;
- const fdt32_t *cell;
struct clk clk;
- int len, ret;
+ int ret;
debug("%s(dev=%p)\n", __func__, dev);
@@ -114,14 +113,12 @@ static int stm32_ipcc_probe(struct udevice *dev)
ipcc->reg_base = (void __iomem *)addr;
/* proc_id */
- cell = dev_read_prop(dev, "st,proc_id", );
- if (len < sizeof(fdt32_t)) {
+ ret = dev_read_u32_index(dev, "st,proc_id", 1, >proc_id);
+ if (ret) {
dev_dbg(dev, "Missing st,proc_id\n");
return -EINVAL;
}
- ipcc->proc_id = fdtdec_get_number(cell, 1);
-
if (ipcc->proc_id >= STM32_MAX_PROCS) {
dev_err(dev, "Invalid proc_id (%d)\n", ipcc->proc_id);
return -EINVAL;
--
2.17.1
[PATCH 1/2] video: stm32_ltdc: Convert to use APIs which support live DT
Use ofnode_ or dev_ APIs instead of fdt_ and fdtdec_ APIs so that the
driver can support live DT.
Signed-off-by: Patrick Delaunay
---
drivers/video/stm32/stm32_ltdc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/stm32/stm32_ltdc.c b/drivers/video/stm32/stm32_ltdc.c
index 2f3427a32e..7fff735930 100644
--- a/drivers/video/stm32/stm32_ltdc.c
+++ b/drivers/video/stm32/stm32_ltdc.c
@@ -366,8 +366,7 @@ static int stm32_ltdc_probe(struct udevice *dev)
ret = panel_get_display_timing(panel, );
if (ret) {
- ret = fdtdec_decode_display_timing(gd->fdt_blob,
- dev_of_offset(panel),
+ ret = ofnode_decode_display_timing(dev_ofnode(panel),
0, );
if (ret) {
dev_err(dev, "decode display timing error %d\n", ret);
--
2.17.1
[PATCH 2/2] video: stm32_dsi: Convert to use APIs which support live DT
Use ofnode_ or dev_ APIs instead of fdt_ and fdtdec_ APIs so that the
driver can support live DT.
Signed-off-by: Patrick Delaunay
---
drivers/video/stm32/stm32_dsi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/stm32/stm32_dsi.c b/drivers/video/stm32/stm32_dsi.c
index 283151398b..9d5abacc2b 100644
--- a/drivers/video/stm32/stm32_dsi.c
+++ b/drivers/video/stm32/stm32_dsi.c
@@ -359,8 +359,7 @@ static int stm32_dsi_attach(struct udevice *dev)
ret = panel_get_display_timing(priv->panel, );
if (ret) {
- ret = fdtdec_decode_display_timing(gd->fdt_blob,
- dev_of_offset(priv->panel),
+ ret = ofnode_decode_display_timing(dev_ofnode(priv->panel),
0, );
if (ret) {
dev_err(dev, "decode display timing error %d\n", ret);
--
2.17.1
[PATCH v4] cmd: mem: fix range of bitflip test
The bitflip test uses two equal sized memory buffers. This is achieved
by splitting the range of memory into two pieces. The address of the
second buffer, as well as the length of each buffer, were not correctly
calculated. This caused bitflip test to access beyond the end of range.
This patch fixes the pointer arithmetic problem.
A second problem arises because u-boot "mtest" command expects the
ending address to be inclusive. When computing (end - start) this
results in missing 1 byte of the requested length. The bitflip test
expects a count rather than an "ending" address. Thus it fails to test
the last word of the requested range. Fixed by using (end - start + 1).
Added Kconfig option to optionally disable the bitflip test, since it
does add significantly to the time taken for "mtest".
Fixes: 8e434cb705d463bc8cff935160e4fb4c77cb99ab ("cmd: mem: Add bitflip
memory test to alternate mtest")
Signed-off-by: Ralph Siemsen
--
Changes in v4:
- Avoid #ifdef in the code
Change-Id: Ie641d04e731fc5bc6a3bbef914bf7fad136cdc94
---
cmd/Kconfig | 12
cmd/mem.c | 18 ++
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index d54acf2cfd..275bf7fbfe 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -779,6 +779,18 @@ config SYS_ALT_MEMTEST
help
Use a more complete alternative memory test.
+if SYS_ALT_MEMTEST
+
+config SYS_ALT_MEMTEST_BITFLIP
+ bool "Bitflip test"
+ default y
+ help
+ The alternative memory test includes bitflip test since 2020.07.
+ The bitflip test significantly increases the overall test time.
+ Bitflip test can optionally be disabled here.
+
+endif
+
config SYS_MEMTEST_START
hex "default start address for mtest"
default 0
diff --git a/cmd/mem.c b/cmd/mem.c
index 9b97f7bf69..63d69ce632 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -867,6 +867,18 @@ static ulong test_bitflip_comparison(volatile unsigned
long *bufa,
return errs;
}
+static ulong mem_test_bitflip(vu_long *buf, ulong start, ulong end)
+{
+ /*
+* Split the specified range into two halves.
+* Note that mtest range is inclusive of start,end.
+* Bitflip test instead uses a count (of 32-bit words).
+*/
+ ulong half_size = (end - start + 1) / 2 / sizeof(unsigned long);
+
+ return test_bitflip_comparison(buf, buf + half_size, half_size);
+}
+
static ulong mem_test_quick(vu_long *buf, ulong start_addr, ulong end_addr,
vu_long pattern, int iteration)
{
@@ -987,10 +999,8 @@ static int do_mem_mtest(struct cmd_tbl *cmdtp, int flag,
int argc,
if (errs == -1UL)
break;
count += errs;
- errs = test_bitflip_comparison(buf,
- buf + (end - start) / 2,
- (end - start) /
- sizeof(unsigned long));
+ if (IS_ENABLED(CONFIG_SYS_ALT_MEMTEST_BITFLIP))
+ errs = mem_test_bitflip(buf, start, end);
} else {
errs = mem_test_quick(buf, start, end, pattern,
iteration);
--
2.17.1
Re: [PATCH v3] cmd: mem: fix range of bitflip test
On 09.09.20 17:21, Ralph Siemsen wrote:
The bitflip test uses two equal sized memory buffers. This is achieved
by splitting the range of memory into two pieces. The address of the
second buffer, as well as the length of each buffer, were not correctly
calculated. This caused bitflip test to access beyond the end of range.
This patch fixes the pointer arithmetic problem.
A second problem arises because u-boot "mtest" command expects the
ending address to be inclusive. When computing (end - start) this
results in missing 1 byte of the requested length. The bitflip test
expects a count rather than an "ending" address. Thus it fails to test
the last word of the requested range. Fixed by using (end - start + 1).
Added Kconfig option to optionally disable the bitflip test, since it
does add significantly to the time taken for "mtest".
Fixes: 8e434cb705d463bc8cff935160e4fb4c77cb99ab ("cmd: mem: Add bitflip
memory test to alternate mtest")
Signed-off-by: Ralph Siemsen
--
Changes in v3:
- Add Kconfig option to disable bitflip test
- Refactor the fix into a helper function
Change-Id: Ie641d04e731fc5bc6a3bbef914bf7fad136cdc94
---
cmd/Kconfig | 12
cmd/mem.c | 24
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index d54acf2cfd..275bf7fbfe 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -779,6 +779,18 @@ config SYS_ALT_MEMTEST
help
Use a more complete alternative memory test.
+if SYS_ALT_MEMTEST
+
+config SYS_ALT_MEMTEST_BITFLIP
+ bool "Bitflip test"
+ default y
+ help
+ The alternative memory test includes bitflip test since 2020.07.
+ The bitflip test significantly increases the overall test time.
+ Bitflip test can optionally be disabled here.
+
+endif
+
config SYS_MEMTEST_START
hex "default start address for mtest"
default 0
diff --git a/cmd/mem.c b/cmd/mem.c
index 9b97f7bf69..63c4bedf24 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -814,6 +814,7 @@ static ulong mem_test_alt(vu_long *buf, ulong start_addr,
ulong end_addr,
return errs;
}
+#ifdef CONFIG_SYS_ALT_MEMTEST_BITFLIP
static int compare_regions(volatile unsigned long *bufa,
volatile unsigned long *bufb, size_t count)
{
@@ -867,6 +868,24 @@ static ulong test_bitflip_comparison(volatile unsigned
long *bufa,
return errs;
}
+static ulong mem_test_bitflip(vu_long *buf, ulong start, ulong end)
+{
+ /*
+* Split the specified range into two halves.
+* Note that mtest range is inclusive of start,end.
+* Bitflip test instead uses a count (of 32-bit words).
+*/
+ ulong half_size = (end - start + 1) / 2 / sizeof(unsigned long);
+
+ return test_bitflip_comparison(buf, buf + half_size, half_size);
+}
+#else
+static ulong mem_test_bitflip(vu_long *buf, ulong start, ulong end)
+{
+ return 0;
+}
+#endif
We don't want to add #ifdef's to the code if possible. How about this
change:
Add this function without #ifdef and drop the empty implementation
and ...
+
static ulong mem_test_quick(vu_long *buf, ulong start_addr, ulong end_addr,
vu_long pattern, int iteration)
{
@@ -987,10 +1006,7 @@ static int do_mem_mtest(struct cmd_tbl *cmdtp, int flag,
int argc,
if (errs == -1UL)
break;
count += errs;
- errs = test_bitflip_comparison(buf,
- buf + (end - start) / 2,
- (end - start) /
- sizeof(unsigned long));
+ errs = mem_test_bitflip(buf, start, end);
Use this here:
if (IS_ENABLED(CONFIG_SYS_ALT_MEMTEST_BITFLIP))
errs = mem_test_bitflip(buf, start, end);
Does this work?
Thanks,
Stefan
[PATCH v3] cmd: mem: fix range of bitflip test
The bitflip test uses two equal sized memory buffers. This is achieved
by splitting the range of memory into two pieces. The address of the
second buffer, as well as the length of each buffer, were not correctly
calculated. This caused bitflip test to access beyond the end of range.
This patch fixes the pointer arithmetic problem.
A second problem arises because u-boot "mtest" command expects the
ending address to be inclusive. When computing (end - start) this
results in missing 1 byte of the requested length. The bitflip test
expects a count rather than an "ending" address. Thus it fails to test
the last word of the requested range. Fixed by using (end - start + 1).
Added Kconfig option to optionally disable the bitflip test, since it
does add significantly to the time taken for "mtest".
Fixes: 8e434cb705d463bc8cff935160e4fb4c77cb99ab ("cmd: mem: Add bitflip
memory test to alternate mtest")
Signed-off-by: Ralph Siemsen
--
Changes in v3:
- Add Kconfig option to disable bitflip test
- Refactor the fix into a helper function
Change-Id: Ie641d04e731fc5bc6a3bbef914bf7fad136cdc94
---
cmd/Kconfig | 12
cmd/mem.c | 24
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index d54acf2cfd..275bf7fbfe 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -779,6 +779,18 @@ config SYS_ALT_MEMTEST
help
Use a more complete alternative memory test.
+if SYS_ALT_MEMTEST
+
+config SYS_ALT_MEMTEST_BITFLIP
+ bool "Bitflip test"
+ default y
+ help
+ The alternative memory test includes bitflip test since 2020.07.
+ The bitflip test significantly increases the overall test time.
+ Bitflip test can optionally be disabled here.
+
+endif
+
config SYS_MEMTEST_START
hex "default start address for mtest"
default 0
diff --git a/cmd/mem.c b/cmd/mem.c
index 9b97f7bf69..63c4bedf24 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -814,6 +814,7 @@ static ulong mem_test_alt(vu_long *buf, ulong start_addr,
ulong end_addr,
return errs;
}
+#ifdef CONFIG_SYS_ALT_MEMTEST_BITFLIP
static int compare_regions(volatile unsigned long *bufa,
volatile unsigned long *bufb, size_t count)
{
@@ -867,6 +868,24 @@ static ulong test_bitflip_comparison(volatile unsigned
long *bufa,
return errs;
}
+static ulong mem_test_bitflip(vu_long *buf, ulong start, ulong end)
+{
+ /*
+* Split the specified range into two halves.
+* Note that mtest range is inclusive of start,end.
+* Bitflip test instead uses a count (of 32-bit words).
+*/
+ ulong half_size = (end - start + 1) / 2 / sizeof(unsigned long);
+
+ return test_bitflip_comparison(buf, buf + half_size, half_size);
+}
+#else
+static ulong mem_test_bitflip(vu_long *buf, ulong start, ulong end)
+{
+ return 0;
+}
+#endif
+
static ulong mem_test_quick(vu_long *buf, ulong start_addr, ulong end_addr,
vu_long pattern, int iteration)
{
@@ -987,10 +1006,7 @@ static int do_mem_mtest(struct cmd_tbl *cmdtp, int flag,
int argc,
if (errs == -1UL)
break;
count += errs;
- errs = test_bitflip_comparison(buf,
- buf + (end - start) / 2,
- (end - start) /
- sizeof(unsigned long));
+ errs = mem_test_bitflip(buf, start, end);
} else {
errs = mem_test_quick(buf, start, end, pattern,
iteration);
--
2.17.1
[PULL] Pull request: u-boot-stm32 for v2020.10= u-boot-stm32-20200909
Hi Tom, Please pull the STM32 related patches for v2020.10: u-boot-stm32-20200528 With the following changes: - fixes on AV96 board: pull up on UART4 RX and adjust PLL4 CI status: https://gitlab.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/4631 Thanks, Patrick git request-pull origin/master https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git u-boot-stm32-20200909 The following changes since commit 96d66a9b8ce11aae9f8bef5244b83b4740b37644: Prepare v2020.10-rc4 (2020-09-07 14:17:33 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git tags/u-boot-stm32-20200909 for you to fetch changes up to b6055945d66d0f4e3b1ecb82af476232067a4ee4: ARM: dts: stm32: Adjust PLL4 settings on AV96 again (2020-09-09 15:02:23 +0200) - fixes on AV96 board: pull up on UART4 RX and adjust PLL4 Marek Vasut (2): ARM: dts: stm32: Pull UART4 RX high on AV96 ARM: dts: stm32: Adjust PLL4 settings on AV96 again Patrick Delaunay (1): arm: stm32mp: cleanup test on eth_env_set_enetaddr result arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi | 2 ++ arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 4 ++-- arch/arm/mach-stm32mp/cpu.c | 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-)
Re: [PATCH] cmd: mem: fix range of bitflip test
Hi Stefan, On Wed, Sep 09, 2020 at 05:13:49PM +0200, Stefan Roese wrote: Usually the RB is only added, when not too many further changes are made by the committer. There is no strict rule here AFAIK. In that case I'll omit your RB on v3 as the change is somewhat larger, and includes the "unrelated" Kconfig change also. Seems somebody beat me to it, v1 is now marked as superseded. Tom is quite active here. ;) He is not the only one ;) Ralph
Re: [PATCH] cmd: mem: fix range of bitflip test
Hi Ralph, On 09.09.20 17:07, Ralph Siemsen wrote: Hi Stefan, On Wed, Sep 09, 2020 at 03:53:08PM +0200, Stefan Roese wrote: Hi Ralph, On 09.09.20 15:49, Ralph Siemsen wrote: Very good, I will send a separate patch that adds a Kconfig option. As it turns out, doing a separate patch for this gets messy, and also would introduce a dependency between the patches. Will do v3 instead. Okay. Small procedural question: Patchwork is showing state=new for both versions of the mtest fix [1]. Is this normal, or did I miss some step when posting the v2 patch? The only thing you missed, was adding my RB tag to v2. I did send a new RB again to this mail, so patchwork will collect it automatically. Thanks, I was not entirely clear what the policy was for this. Presumably there is a way for a reviewer to 'revoke' the RB in case they disagree with subsequent changes? Usually the RB is only added, when not too many further changes are made by the committer. There is no strict rule here AFAIK. You could mark your v1 as superseded in patchwork though. Seems somebody beat me to it, v1 is now marked as superseded. Tom is quite active here. ;) Thanks, Stefan
Re: [PATCH] cmd: mem: fix range of bitflip test
Hi Stefan, On Wed, Sep 09, 2020 at 03:53:08PM +0200, Stefan Roese wrote: Hi Ralph, On 09.09.20 15:49, Ralph Siemsen wrote: Very good, I will send a separate patch that adds a Kconfig option. As it turns out, doing a separate patch for this gets messy, and also would introduce a dependency between the patches. Will do v3 instead. Small procedural question: Patchwork is showing state=new for both versions of the mtest fix [1]. Is this normal, or did I miss some step when posting the v2 patch? The only thing you missed, was adding my RB tag to v2. I did send a new RB again to this mail, so patchwork will collect it automatically. Thanks, I was not entirely clear what the policy was for this. Presumably there is a way for a reviewer to 'revoke' the RB in case they disagree with subsequent changes? You could mark your v1 as superseded in patchwork though. Seems somebody beat me to it, v1 is now marked as superseded. Ralph
Recall: [PULL] Pull request: u-boot-stm32 for v2020.10= u-boot-stm32-20200909
Patrick DELAUNAY would like to recall the message, "[PULL] Pull request: u-boot-stm32 for v2020.10= u-boot-stm32-20200909".
[PULL] Pull request: u-boot-stm32 for v2020.10= u-boot-stm32-20200909
Hi Tom, Please pull the STM32 related patches for v2020.10: u-boot-stm32-20200528 With the following changes: - fixes on AV96 board: pull up on UART4 RX and adjust PLL4 CI status: https://gitlab.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/4631 Thanks, Patrick git request-pull origin/master https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git u-boot-stm32-20200909 The following changes since commit 96d66a9b8ce11aae9f8bef5244b83b4740b37644: Prepare v2020.10-rc4 (2020-09-07 14:17:33 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git tags/u-boot-stm32-20200909 for you to fetch changes up to b6055945d66d0f4e3b1ecb82af476232067a4ee4: ARM: dts: stm32: Adjust PLL4 settings on AV96 again (2020-09-09 15:02:23 +0200) - fixes on AV96 board: pull up on UART4 RX and adjust PLL4 Marek Vasut (2): ARM: dts: stm32: Pull UART4 RX high on AV96 ARM: dts: stm32: Adjust PLL4 settings on AV96 again Patrick Delaunay (1): arm: stm32mp: cleanup test on eth_env_set_enetaddr result arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi | 2 ++ arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 4 ++-- arch/arm/mach-stm32mp/cpu.c | 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-)
Re: [PATCH v3 6/8] firmware: scmi: sandbox test for SCMI clocks
On Wed, 9 Sep 2020 at 16:35, Simon Glass wrote:
>
> Hi Etienne,
>
> On Wed, 9 Sep 2020 at 03:58, Etienne Carriere
> wrote:
> >
> > On Tue, 8 Sep 2020 at 17:21, Simon Glass wrote:
> > >
> > > Hi Etienne,
> > >
> > > On Mon, 7 Sep 2020 at 08:50, Etienne Carriere
> > > wrote:
> > > >
> > > > Add tests for SCMI clocks. A test device driver sandbox-scmi_devices.c
> > > > is used to get clock resources, allowing further clock manipulation.
> > > >
> > > > Change sandbox-smci_agent to emulate 3 clocks exposed through 2 agents.
> > > > Add DM test scmi_clocks to test these 3 clocks.
> > > > Update DM test sandbox_scmi_agent with load/remove test sequences
> > > > factorized by {load|remove}_sandbox_scmi_test_devices() helper
> > > > functions.
> > > >
> > > > Signed-off-by: Etienne Carriere
> > > > Cc: Simon Glass
> > > > Cc: Peng Fan
> > > > Cc: Sudeep Holla
> > > > ---
> > > >
> > > > Changes in v3:
> > > > - New commit in the series, addresses review comments on test support.
> > > > ut_dm_scmi_clocks test SCMI are found and behave as expected for the
> > > > implemented clk uclass methods.
> > > > ---
> > > > arch/sandbox/dts/test.dts| 15 ++
> > > > arch/sandbox/include/asm/scmi_test.h | 37
> > > > configs/sandbox_defconfig| 1 +
> > > > drivers/firmware/scmi/Makefile | 2 +-
> > > > drivers/firmware/scmi/sandbox-scmi_agent.c | 169 ++-
> > > > drivers/firmware/scmi/sandbox-scmi_devices.c | 86 ++
> > > > test/dm/scmi.c | 139 ++-
> > > > 7 files changed, 438 insertions(+), 11 deletions(-)
> > > > create mode 100644 drivers/firmware/scmi/sandbox-scmi_devices.c
> > >
> > > Reviewed-by: Simon Glass
> > >
> > > Nits below
> > >
> > > [..]
>
> > > > + * memory allocation to ease sharing with test sequence implementation.
> > > > + */
> > > > +static struct clk sandbox_scmi_clk_device[SCMI_TEST_DEVICES_CLK_COUNT];
> > > > +static struct sandbox_scmi_devices sandbox_scmi_devhld;
> > >
> > > This should really be in a struct, I think, pointed to by
> > > dev_get_priv() on this device. I do try to avoid BSS with driver
> > > model, although it is not a hard rule with test code.
> >
> > I used a static structure here to ease sharing context reference with
> > the test sequence implementation.
>
> Is that in a different file?
I made the helper function sandbox_scmi_devices_ctx() exported by
sandbox-scmi_devices.c that references probed devices.
The function is called from test/dm/scmi.c to run the test (actions &
verifications).
>
> > Context reference returned by sandbox_scmi_devices_ctx() is always
> > reliable for the sequence.
> > (not possibly dereference in which case the test may segfault).
> >
> > I can go this way if you prefer no BSS in drivers (Note this is a
> > sandbox driver). I'll update the test accordingly.
>
> If you have a reason to use BSS for a sandbox driver that is OK. I
> don't quite understand the problem you are solving though. If private
> data is allocated too late, you can allocate the info as platdata
> which happens when the device is bound, and then use
> dev_get_platdata().
>
> But ultimately it is up to you, as this is a test driver. It just
> helps to avoid people copying a pattern to their own driver.
Ok.
I'll try to keep it simple.
Regards,
etienne
>
> [..]
>
> Regards,
> Simon
Re: [PATCH v6 00/17] efi_loader: add capsule update support
On 07.09.20 07:34, 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 > > In this version, the DFU change by Heinrich[2] is, at least temporarily, > not a prerequisite due to the discussions[3]. > > [2] https://lists.denx.de/pipermail/u-boot/2020-July/420950.html > [3] https://lists.denx.de/pipermail/u-boot/2020-August/424716.html The end of the discussion was that the patch is postponed to v2021.01 like your series. > > 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 Shouldn't the sandbox_defconfig changes be added to your series? Is this the correct change: diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 6e9f029cc9..da82afaa01 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -129,6 +129,7 @@ CONFIG_DM_DEMO_SIMPLE=y CONFIG_DM_DEMO_SHAPE=y CONFIG_BOARD=y CONFIG_BOARD_SANDBOX=y +CONFIG_DFU_SF=y CONFIG_DMA=y CONFIG_DMA_CHANNELS=y CONFIG_SANDBOX_DMA=y @@ -261,6 +262,10 @@ CONFIG_CMD_DHRYSTONE=y CONFIG_TPM=y CONFIG_LZ4=y CONFIG_ERRNO_STR=y +CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y +CONFIG_EFI_CAPSULE_ON_DISK=y +CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y +CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y CONFIG_EFI_SECURE_BOOT=y CONFIG_TEST_FDTDEC=y CONFIG_UNIT_TEST=y > required and partly because there is a problem with virt-make-fs. What problem with virt-make-fs exists? How will this be solved? > 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. Please, use 'if' instead of '#if' where possible so that the compiler checks the code syntax even if the configuration is not set. Like with '#if' the compiler will eliminate unused code. Best regards Heinrich > * Add a document in uefi.rst > > TODO's > == > (Won't be addressed in this series.) > * capsule authentication > * capsule dependency (dependency expression instruction set, or depex) > * loading drivers in a capsule > * handling RESET flag in a capsule and QeuryCapsuleCaps > * full semantics of ESRT (EFI System Resource Table) > * enabling
Re: [PATCH 1/2] x86: acpi: Fix calculation of DSDT length
On Wed, 9 Sep 2020 at 06:33, Wolfgang Wallner wrote: > > Currently, the calculation for the length of the DSDT table includes any > bytes that are added for alignment, but those bytes are not initialized. > > This is because the DSDT length is calculated after a call to > acpi_inc_align(). Split this up into the following sequence: > > * acpi_inc() > * Calculate DSDT length > * acpi_align() > > Signed-off-by: Wolfgang Wallner > > --- > > arch/x86/lib/acpi_table.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH v4 2/2] test: gpio: Add tests for the managed API
Hi Pratyush, On Tue, 8 Sep 2020 at 21:53, Pratyush Yadav wrote: > > On 08/09/20 05:56PM, Simon Glass wrote: > > On Mon, 7 Sep 2020 at 23:40, Pratyush Yadav wrote: > > > > > > From: Jean-Jacques Hiblot > > > > > > Add a test to verify that GPIOs can be acquired/released using the managed > > > API. Also check that the GPIOs are released when the consumer device is > > > removed. > > > > > > Signed-off-by: Jean-Jacques Hiblot > > > Signed-off-by: Pratyush Yadav > > > --- > > > arch/sandbox/dts/test.dts | 10 > > > test/dm/bus.c | 2 +- > > > test/dm/gpio.c| 102 ++ > > > test/dm/test-fdt.c| 6 +-- > > > 4 files changed, 116 insertions(+), 4 deletions(-) > > > > Reviewed-by: Simon Glass > > Thanks. > > > Although I don't see a change log, so this is a bit blind. > > The changelog is in the cover letter [0]. Copy-pasing the parts relevant > to this patch: > > - Move "another-test" node down the order to make sure > dm_test_fdt_uclass_seq() continues to work. > - Bump num_devices to 9 in dm_test_bus_children(), dm_test_fdt(), and > dm_test_uclass_foreach() to fix broken tests. > - s/DM_TESTF/UT_TESTF/g OK ta. I don't see it if it is in the cover letter. It's nice to have it in both places. > > [0] I haven't figured out a workflow that lets me easily record the > changelog on a per-patch basis. Maybe I can write some scripts around > git-notes for that? Dunno. You can use patman which is conveniently in the U-Boot tree and does this along with automation of various other steps for emailing patches. Regards, Simon
Re: [PATCH v3 6/8] firmware: scmi: sandbox test for SCMI clocks
Hi Etienne,
On Wed, 9 Sep 2020 at 03:58, Etienne Carriere
wrote:
>
> On Tue, 8 Sep 2020 at 17:21, Simon Glass wrote:
> >
> > Hi Etienne,
> >
> > On Mon, 7 Sep 2020 at 08:50, Etienne Carriere
> > wrote:
> > >
> > > Add tests for SCMI clocks. A test device driver sandbox-scmi_devices.c
> > > is used to get clock resources, allowing further clock manipulation.
> > >
> > > Change sandbox-smci_agent to emulate 3 clocks exposed through 2 agents.
> > > Add DM test scmi_clocks to test these 3 clocks.
> > > Update DM test sandbox_scmi_agent with load/remove test sequences
> > > factorized by {load|remove}_sandbox_scmi_test_devices() helper functions.
> > >
> > > Signed-off-by: Etienne Carriere
> > > Cc: Simon Glass
> > > Cc: Peng Fan
> > > Cc: Sudeep Holla
> > > ---
> > >
> > > Changes in v3:
> > > - New commit in the series, addresses review comments on test support.
> > > ut_dm_scmi_clocks test SCMI are found and behave as expected for the
> > > implemented clk uclass methods.
> > > ---
> > > arch/sandbox/dts/test.dts| 15 ++
> > > arch/sandbox/include/asm/scmi_test.h | 37
> > > configs/sandbox_defconfig| 1 +
> > > drivers/firmware/scmi/Makefile | 2 +-
> > > drivers/firmware/scmi/sandbox-scmi_agent.c | 169 ++-
> > > drivers/firmware/scmi/sandbox-scmi_devices.c | 86 ++
> > > test/dm/scmi.c | 139 ++-
> > > 7 files changed, 438 insertions(+), 11 deletions(-)
> > > create mode 100644 drivers/firmware/scmi/sandbox-scmi_devices.c
> >
> > Reviewed-by: Simon Glass
> >
> > Nits below
> >
> > [..]
> > > + * memory allocation to ease sharing with test sequence implementation.
> > > + */
> > > +static struct clk sandbox_scmi_clk_device[SCMI_TEST_DEVICES_CLK_COUNT];
> > > +static struct sandbox_scmi_devices sandbox_scmi_devhld;
> >
> > This should really be in a struct, I think, pointed to by
> > dev_get_priv() on this device. I do try to avoid BSS with driver
> > model, although it is not a hard rule with test code.
>
> I used a static structure here to ease sharing context reference with
> the test sequence implementation.
Is that in a different file?
> Context reference returned by sandbox_scmi_devices_ctx() is always
> reliable for the sequence.
> (not possibly dereference in which case the test may segfault).
>
> I can go this way if you prefer no BSS in drivers (Note this is a
> sandbox driver). I'll update the test accordingly.
If you have a reason to use BSS for a sandbox driver that is OK. I
don't quite understand the problem you are solving though. If private
data is allocated too late, you can allocate the info as platdata
which happens when the device is bound, and then use
dev_get_platdata().
But ultimately it is up to you, as this is a test driver. It just
helps to avoid people copying a pattern to their own driver.
[..]
Regards,
Simon
Re: [PATCH v3 3/8] firmware: scmi: support Arm SMCCC transport
Hi Etienne,
On Wed, 9 Sep 2020 at 03:41, Etienne Carriere
wrote:
>
> On Tue, 8 Sep 2020 at 17:21, Simon Glass wrote:
> >
> > Hi Etienne,
> >
> > On Mon, 7 Sep 2020 at 08:50, Etienne Carriere
> > wrote:
> > >
> > > This change implements a SMCCC transport for SCMI exchanges. This
> > > implementation follows the Linux kernel as references implementation
> > > for SCMI message processing, using the SMT format for communication
> > > channel meta-data.
> > >
> > > Use of SMCCC transport in SCMI FDT bindings are defined in the Linux
> > > kernel DT bindings since v5.8. SMCCC with SMT is implemented in OP-TEE
> > > from tag 3.9.0 [2].
> > >
> > > Links: [2] https://github.com/OP-TEE/optee_os/commit/a58c4d706d23
> > > Signed-off-by: Etienne Carriere
> > > Cc: Simon Glass
> > > Cc: Peng Fan
> > > Cc: Sudeep Holla
> > > ---
> > >
> > > Changes in v3:
> > > - This is a followup of the SCMI agent patches posted in
> > > https://patchwork.ozlabs.org/project/uboot/list/?series=196253
> > > The v3 splits commits and introduces a new uclass as requested.
> > > - This patch implements the same Arm SMCCC SCMI agent as presented
> > > in v2 but in its own source file smccc_agent.c, and based in smt.h.
> > > ---
> > > drivers/firmware/scmi/Kconfig | 4 +-
> > > drivers/firmware/scmi/Makefile | 1 +
> > > drivers/firmware/scmi/smccc_agent.c | 95 +
> > > 3 files changed, 98 insertions(+), 2 deletions(-)
> > > create mode 100644 drivers/firmware/scmi/smccc_agent.c
> > >
> >
> > Reviewed-by: Simon Glass
> >
> > nits below
> >
> > > diff --git a/drivers/firmware/scmi/Kconfig b/drivers/firmware/scmi/Kconfig
> > > index c501bf4943..335d09c821 100644
> > > --- a/drivers/firmware/scmi/Kconfig
> > > +++ b/drivers/firmware/scmi/Kconfig
> > > @@ -15,5 +15,5 @@ config SCMI_FIRMWARE
> > >
> > > Communications between agent (client) and the SCMI server are
> > > based on message exchange. Messages can be exchange over
> > > tranport
> > > - channels as a mailbox device with some piece of identified
> > > shared
> > > - memory.
> > > + channels as a mailbox device or an Arm SMCCC service with some
> > > + piece of identified shared memory.
> > > diff --git a/drivers/firmware/scmi/Makefile
> > > b/drivers/firmware/scmi/Makefile
> > > index d22f53efe7..2f782bbd55 100644
> > > --- a/drivers/firmware/scmi/Makefile
> > > +++ b/drivers/firmware/scmi/Makefile
> > > @@ -1,4 +1,5 @@
> > > obj-y += scmi_agent-uclass.o
> > > obj-y += smt.o
> > > +obj-$(CONFIG_ARM_SMCCC)+= smccc_agent.o
> > > obj-$(CONFIG_DM_MAILBOX) += mailbox_agent.o
> > > obj-$(CONFIG_SANDBOX) += sandbox-scmi_agent.o
> > > diff --git a/drivers/firmware/scmi/smccc_agent.c
> > > b/drivers/firmware/scmi/smccc_agent.c
> > > new file mode 100644
> > > index 00..90707710e2
> > > --- /dev/null
> > > +++ b/drivers/firmware/scmi/smccc_agent.c
> > > @@ -0,0 +1,95 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright (C) 2020 Linaro Limited.
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > That should go below the next one.
>
> acked.
>
> > > +
> > > +#include
> > > +#include
> > > +
> > > +#include "smt.h"
> > > +
> > > +#define SMCCC_RET_NOT_SUPPORTED ((unsigned long)-1)
> > > +
> > > +/**
> > > + * struct scmi_smccc_channel - Description of an SCMI SMCCC transport
> > > + * @func_id: SMCCC function ID used by the SCMI transport
> > > + * @smt: Shared memory buffer
> > > + */
> > > +struct scmi_smccc_channel {
> > > + ulong func_id;
> > > + struct scmi_smt smt;
> > > +};
> > > +
> > > +static struct scmi_smccc_channel *scmi_smccc_get_priv(struct udevice
> > > *dev)
> > > +{
> > > + return (struct scmi_smccc_channel *)dev_get_priv(dev);
> >
> > You shouldn't need that cast
>
> acked. So no need for helper scmi_smccc_get_priv(),
> caller can call dev_get_priv() straight.
Actually I think your function is OK if you want it. I was just
talking about the cast.
But yes, a lot of drivers just declare something like this in each function:
struct something_priv *priv = dev_get_priv(dev)
Regards,
Simon
Re: [PATCH 2/2] x86: acpi: Add memset to initialize SPCR table
On Wed, 9 Sep 2020 at 06:33, Wolfgang Wallner wrote: > > Add a missing memset to acpi_create_spcr(). > > The other acpi_create_() functions perform a memset on their > structures, acpi_create_spcr() does not and as a result the contents of > this table are partly uninitialized (and thus random after every reset). > > Signed-off-by: Wolfgang Wallner > --- > > arch/x86/lib/acpi_table.c | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Simon Glass For further thought, I do wonder if acpi_fill_header() should do the memset, if sizeof() could be passed as a parameter?
Re: [GIT PULL] rpi: second round for v2020.10
On Wed, Sep 09, 2020 at 10:13:50AM +0200, Matthias Brugger wrote: > Hi Tom, > > Please have a look at the second round of patches for the RPi. Two patches > fixes the network driver of the RPi4 which didn't work reliable. Another > patch enables USB keyboard for 32 bit RPi4. > > Petr tested the network patches, but his mail with the Tested-by tag didn't > come through. I added it anyway. > > As always you can find the CI outcome here: > https://travis-ci.org/github/mbgg/u-boot/builds/725262009 > https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi/-/pipelines/4622 > > I ran the CI against the rpi-next branch and not the tag, but you can verify > that this is basically the same commit id. > > Thanks for having a look! > Regards, > Matthias > > -- > > The following changes since commit 96d66a9b8ce11aae9f8bef5244b83b4740b37644: > > Prepare v2020.10-rc4 (2020-09-07 14:17:33 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-raspberrypi.git/ > tags/rpi-next-2020.10.2 > > for you to fetch changes up to 40877a1a949edf7066b3e4ed16101153624bb314: > > config: Enable USB Keyboard suuport on RPi4 32 bit (2020-09-08 16:45:01 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 9/9] usb: xhci: convert to readx_poll_sleep_timeout()
On 9/9/20 4:05 PM, Bin Meng wrote: > On Wed, Sep 9, 2020 at 10:02 PM Marek Vasut wrote: >> >> On 9/9/20 3:46 PM, Bin Meng wrote: >>> On Wed, Sep 9, 2020 at 7:05 PM Marek Vasut wrote: On 9/9/20 3:55 AM, Bin Meng wrote: > Hi Marek, Hi, > On Wed, Sep 9, 2020 at 12:15 AM Marek Vasut wrote: >> >> On 9/8/20 5:45 PM, Bin Meng wrote: >>> Hi Marek, >> >> Hi, >> >>> On Tue, Sep 8, 2020 at 7:13 PM Marek Vasut wrote: On 9/8/20 3:44 AM, Bin Meng wrote: > On Mon, Sep 7, 2020 at 3:14 PM Chunfeng Yun > wrote: >> >> Use readx_poll_sleep_timeout() to poll the register status >> >> Signed-off-by: Chunfeng Yun >> --- >> v3: no changes >> >> v2: fix typo of title suggested by Frank >> --- >> drivers/usb/host/xhci.c | 25 +++-- >> 1 file changed, 11 insertions(+), 14 deletions(-) >> > > Reviewed-by: Bin Meng Thanks. So now I have half of a RESEND patchset with RB tags, and another half of just RB tags without patchset. Can someone of you please collect the tags and resend the patchset once more with the collected tags, so it's all in one place ? >>> >>> I believe the latest version has all the RB tags. >> >> Thank you, I cannot apply a patchset which only has "Re:" in my mailbox, >> because the original patches are just not there. > > You can use patchwork to help the custodian work. I found it very > helpful to download the patches from patchwork and apply. Can you also comment on patches via patchwork ? I mean, really, can we please just stick to the usual workflow ? That's all I am asking for , nothing else, nothing new. >>> >>> I don't understand the question about "usual workflow". You asked "I >>> cannot apply a patchset which only has "Re:" in my mailbox" and I >>> recommended patchwork which will satisfy the requirement of what you >>> asked. >> >> Right, I can, but if there is more I want to say about the patch, I >> cannot do it with patchwork. Then I need the patch, which I don't have. >> Hence my remark about the usual email-based workflow. > > Yes, that's true. If we need to post comments about patches, we will > have to use email. The problem here is that for whatever reason, I didn't receive the original patches, Frank had to resend them, then I got RBs on some of each and it was a mess. I'd just like to get back to the usual. I think we agree, don't we ? Anyway, thanks for the RBs, that really helped.
Re: [PATCH v3 9/9] usb: xhci: convert to readx_poll_sleep_timeout()
On Wed, Sep 09, 2020 at 10:05:42PM +0800, Bin Meng wrote: > On Wed, Sep 9, 2020 at 10:02 PM Marek Vasut wrote: > > > > On 9/9/20 3:46 PM, Bin Meng wrote: > > > On Wed, Sep 9, 2020 at 7:05 PM Marek Vasut wrote: > > >> > > >> On 9/9/20 3:55 AM, Bin Meng wrote: > > >>> Hi Marek, > > >> > > >> Hi, > > >> > > >>> On Wed, Sep 9, 2020 at 12:15 AM Marek Vasut wrote: > > > > On 9/8/20 5:45 PM, Bin Meng wrote: > > > Hi Marek, > > > > Hi, > > > > > On Tue, Sep 8, 2020 at 7:13 PM Marek Vasut wrote: > > >> > > >> On 9/8/20 3:44 AM, Bin Meng wrote: > > >>> On Mon, Sep 7, 2020 at 3:14 PM Chunfeng Yun > > >>> wrote: > > > > Use readx_poll_sleep_timeout() to poll the register status > > > > Signed-off-by: Chunfeng Yun > > --- > > v3: no changes > > > > v2: fix typo of title suggested by Frank > > --- > > drivers/usb/host/xhci.c | 25 +++-- > > 1 file changed, 11 insertions(+), 14 deletions(-) > > > > >>> > > >>> Reviewed-by: Bin Meng > > >> > > >> Thanks. So now I have half of a RESEND patchset with RB tags, and > > >> another half of just RB tags without patchset. Can someone of you > > >> please > > >> collect the tags and resend the patchset once more with the collected > > >> tags, so it's all in one place ? > > >> > > > > > > I believe the latest version has all the RB tags. > > > > Thank you, I cannot apply a patchset which only has "Re:" in my > > mailbox, > > because the original patches are just not there. > > >>> > > >>> You can use patchwork to help the custodian work. I found it very > > >>> helpful to download the patches from patchwork and apply. > > >> > > >> Can you also comment on patches via patchwork ? > > >> > > >> I mean, really, can we please just stick to the usual workflow ? That's > > >> all I am asking for , nothing else, nothing new. > > > > > > I don't understand the question about "usual workflow". You asked "I > > > cannot apply a patchset which only has "Re:" in my mailbox" and I > > > recommended patchwork which will satisfy the requirement of what you > > > asked. > > > > Right, I can, but if there is more I want to say about the patch, I > > cannot do it with patchwork. Then I need the patch, which I don't have. > > Hence my remark about the usual email-based workflow. > > Yes, that's true. If we need to post comments about patches, we will > have to use email. Which, to close the loop, is trivial with patchwork, if you're making a new comment, and hard if you are trying to join an ongoing conversation. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 9/9] usb: xhci: convert to readx_poll_sleep_timeout()
On Wed, Sep 9, 2020 at 10:02 PM Marek Vasut wrote: > > On 9/9/20 3:46 PM, Bin Meng wrote: > > On Wed, Sep 9, 2020 at 7:05 PM Marek Vasut wrote: > >> > >> On 9/9/20 3:55 AM, Bin Meng wrote: > >>> Hi Marek, > >> > >> Hi, > >> > >>> On Wed, Sep 9, 2020 at 12:15 AM Marek Vasut wrote: > > On 9/8/20 5:45 PM, Bin Meng wrote: > > Hi Marek, > > Hi, > > > On Tue, Sep 8, 2020 at 7:13 PM Marek Vasut wrote: > >> > >> On 9/8/20 3:44 AM, Bin Meng wrote: > >>> On Mon, Sep 7, 2020 at 3:14 PM Chunfeng Yun > >>> wrote: > > Use readx_poll_sleep_timeout() to poll the register status > > Signed-off-by: Chunfeng Yun > --- > v3: no changes > > v2: fix typo of title suggested by Frank > --- > drivers/usb/host/xhci.c | 25 +++-- > 1 file changed, 11 insertions(+), 14 deletions(-) > > >>> > >>> Reviewed-by: Bin Meng > >> > >> Thanks. So now I have half of a RESEND patchset with RB tags, and > >> another half of just RB tags without patchset. Can someone of you > >> please > >> collect the tags and resend the patchset once more with the collected > >> tags, so it's all in one place ? > >> > > > > I believe the latest version has all the RB tags. > > Thank you, I cannot apply a patchset which only has "Re:" in my mailbox, > because the original patches are just not there. > >>> > >>> You can use patchwork to help the custodian work. I found it very > >>> helpful to download the patches from patchwork and apply. > >> > >> Can you also comment on patches via patchwork ? > >> > >> I mean, really, can we please just stick to the usual workflow ? That's > >> all I am asking for , nothing else, nothing new. > > > > I don't understand the question about "usual workflow". You asked "I > > cannot apply a patchset which only has "Re:" in my mailbox" and I > > recommended patchwork which will satisfy the requirement of what you > > asked. > > Right, I can, but if there is more I want to say about the patch, I > cannot do it with patchwork. Then I need the patch, which I don't have. > Hence my remark about the usual email-based workflow. Yes, that's true. If we need to post comments about patches, we will have to use email. Regards, Bin
Re: [PATCH v3 9/9] usb: xhci: convert to readx_poll_sleep_timeout()
On 9/9/20 3:46 PM, Bin Meng wrote: > On Wed, Sep 9, 2020 at 7:05 PM Marek Vasut wrote: >> >> On 9/9/20 3:55 AM, Bin Meng wrote: >>> Hi Marek, >> >> Hi, >> >>> On Wed, Sep 9, 2020 at 12:15 AM Marek Vasut wrote: On 9/8/20 5:45 PM, Bin Meng wrote: > Hi Marek, Hi, > On Tue, Sep 8, 2020 at 7:13 PM Marek Vasut wrote: >> >> On 9/8/20 3:44 AM, Bin Meng wrote: >>> On Mon, Sep 7, 2020 at 3:14 PM Chunfeng Yun >>> wrote: Use readx_poll_sleep_timeout() to poll the register status Signed-off-by: Chunfeng Yun --- v3: no changes v2: fix typo of title suggested by Frank --- drivers/usb/host/xhci.c | 25 +++-- 1 file changed, 11 insertions(+), 14 deletions(-) >>> >>> Reviewed-by: Bin Meng >> >> Thanks. So now I have half of a RESEND patchset with RB tags, and >> another half of just RB tags without patchset. Can someone of you please >> collect the tags and resend the patchset once more with the collected >> tags, so it's all in one place ? >> > > I believe the latest version has all the RB tags. Thank you, I cannot apply a patchset which only has "Re:" in my mailbox, because the original patches are just not there. >>> >>> You can use patchwork to help the custodian work. I found it very >>> helpful to download the patches from patchwork and apply. >> >> Can you also comment on patches via patchwork ? >> >> I mean, really, can we please just stick to the usual workflow ? That's >> all I am asking for , nothing else, nothing new. > > I don't understand the question about "usual workflow". You asked "I > cannot apply a patchset which only has "Re:" in my mailbox" and I > recommended patchwork which will satisfy the requirement of what you > asked. Right, I can, but if there is more I want to say about the patch, I cannot do it with patchwork. Then I need the patch, which I don't have. Hence my remark about the usual email-based workflow.
Re: [PATCH] cmd: mem: fix range of bitflip test
Hi Ralph, On 09.09.20 15:49, Ralph Siemsen wrote: Hi Stefan, On Wed, Sep 09, 2020 at 03:34:35PM +0200, Stefan Roese wrote: I agree that it's too time consuming (usually) for a manufacturing test. Either you are okay with disabling CONFIG_SYS_ALT_MEMTEST on your board, which will also disable this bitflip test. Or please continue adding a new Kconfig option for it - which is probable the better option. Very good, I will send a separate patch that adds a Kconfig option. Small procedural question: Patchwork is showing state=new for both versions of the mtest fix [1]. Is this normal, or did I miss some step when posting the v2 patch? The only thing you missed, was adding my RB tag to v2. I did send a new RB again to this mail, so patchwork will collect it automatically. You could mark your v1 as superseded in patchwork though. Thanks, Stefan
Re: U-boot command prompt failed to load in Raspberry pi 4
Hi, I found that there is a change in building U-Boot for Raspberry pi 4. 1. Kernel address space is increased. 2. Need to add respective *.dtb files to the /boot. 3. boot.src and boot.txt files were added to the /boot. Please refer to the following links for more information. https://github.com/SatishKumarReddyPokala/RPI4/tree/master/U-Boot/Build_U-Boot https://archlinuxarm.org/packages/armv7h/uboot-raspberrypi/files/PKGBUILD Regards, Satish kumar reddy. On Sun, Sep 6, 2020 at 6:29 PM satish reddy wrote: > Hi, > > I'm porting u-boot for raspberry pi 4. I cross compiled u-boot for > Raspberry pi 4 and copied u-boot.bin and latest firmware files start4.elf > and fixup4.dat from git into a SD card. My configuration file contains > enable_uart=1 > arm_64bit=1 > uart_2ndstage=1 > kernel=u-boot.bin > > Inserted SD card into pi and started monitoring logs from serial port. > it got stuck at starting start3.elf @ 0xfec00200 > I am not able to find the solution for this issue. Please kindly help to > resolve this u-boot bug in raspberry pi 4. > > Regards, > Satish > -- *Thanks & Regards,* P.Satish Kumar Reddy. +91-9666796840
Re: [PATCH RESEND v4 2/9] usb: xhci: create one unified function to calculate TRB TD remainder
On 9/8/20 6:59 PM, Frank Wunderlich wrote:
[...]
> +static u32 xhci_td_remainder(struct xhci_ctrl *ctrl, int transferred,
> + int trb_buff_len, unsigned int td_total_len,
> + int maxp, bool more_trbs_coming)
> {
> - int packets_transferred;
> + u32 total_packet_count;
> +
> + if (ctrl->hci_version < 0x100)
> + return ((td_total_len - transferred) >> 10);
Here and ...
> /* One TRB with a zero-length data packet. */
> - if (num_trbs_left == 0 || (running_total == 0 && trb_buff_len == 0))
> + if (!more_trbs_coming || (transferred == 0 && trb_buff_len == 0) ||
> + trb_buff_len == td_total_len)
> return 0;
>
> - /*
> - * All the TRB queueing functions don't count the current TRB in
> - * running_total.
> - */
> - packets_transferred = (running_total + trb_buff_len) / maxpacketsize;
> + total_packet_count = DIV_ROUND_UP(td_total_len, maxp);
>
> - if ((total_packet_count - packets_transferred) > 31)
> - return 31 << 17;
> - return (total_packet_count - packets_transferred) << 17;
> + /* Queueing functions don't count the current TRB into transferred */
> + return (total_packet_count - ((transferred + trb_buff_len) / maxp));
... here. The outer parenthesis are not needed, can you check them in
other functions too and send a subsequent cleanup patch ?
I applied the patcheset to u-boot-usb/next , thanks.
Re: [PATCH] cmd: mem: fix range of bitflip test
Hi Stefan, On Wed, Sep 09, 2020 at 03:34:35PM +0200, Stefan Roese wrote: I agree that it's too time consuming (usually) for a manufacturing test. Either you are okay with disabling CONFIG_SYS_ALT_MEMTEST on your board, which will also disable this bitflip test. Or please continue adding a new Kconfig option for it - which is probable the better option. Very good, I will send a separate patch that adds a Kconfig option. Small procedural question: Patchwork is showing state=new for both versions of the mtest fix [1]. Is this normal, or did I miss some step when posting the v2 patch? Thanks, Ralph [1] http://patchwork.ozlabs.org/project/uboot/list/?submitter=76946
Re: [PATCH v3 9/9] usb: xhci: convert to readx_poll_sleep_timeout()
On Wed, Sep 9, 2020 at 7:05 PM Marek Vasut wrote: > > On 9/9/20 3:55 AM, Bin Meng wrote: > > Hi Marek, > > Hi, > > > On Wed, Sep 9, 2020 at 12:15 AM Marek Vasut wrote: > >> > >> On 9/8/20 5:45 PM, Bin Meng wrote: > >>> Hi Marek, > >> > >> Hi, > >> > >>> On Tue, Sep 8, 2020 at 7:13 PM Marek Vasut wrote: > > On 9/8/20 3:44 AM, Bin Meng wrote: > > On Mon, Sep 7, 2020 at 3:14 PM Chunfeng Yun > > wrote: > >> > >> Use readx_poll_sleep_timeout() to poll the register status > >> > >> Signed-off-by: Chunfeng Yun > >> --- > >> v3: no changes > >> > >> v2: fix typo of title suggested by Frank > >> --- > >> drivers/usb/host/xhci.c | 25 +++-- > >> 1 file changed, 11 insertions(+), 14 deletions(-) > >> > > > > Reviewed-by: Bin Meng > > Thanks. So now I have half of a RESEND patchset with RB tags, and > another half of just RB tags without patchset. Can someone of you please > collect the tags and resend the patchset once more with the collected > tags, so it's all in one place ? > > >>> > >>> I believe the latest version has all the RB tags. > >> > >> Thank you, I cannot apply a patchset which only has "Re:" in my mailbox, > >> because the original patches are just not there. > > > > You can use patchwork to help the custodian work. I found it very > > helpful to download the patches from patchwork and apply. > > Can you also comment on patches via patchwork ? > > I mean, really, can we please just stick to the usual workflow ? That's > all I am asking for , nothing else, nothing new. I don't understand the question about "usual workflow". You asked "I cannot apply a patchset which only has "Re:" in my mailbox" and I recommended patchwork which will satisfy the requirement of what you asked. Regards, Bin
Re: [PATCH v2] cmd: mem: fix range of bitflip test
On 09.09.20 15:02, Ralph Siemsen wrote:
The bitflip test uses two equal sized memory buffers. This is achieved
by splitting the range of memory into two pieces. The address of the
second buffer, as well as the length of each buffer, were not correctly
calculated. This caused bitflip test to access beyond the end of range.
This patch fixes the pointer arithmetic problem.
A second problem arises because u-boot "mtest" command expects the
ending address to be inclusive. When computing (end - start) this
results in missing 1 byte of the requested length. The bitflip test
expects a count rather than an "ending" address. Thus it fails to test
the last word of the requested range. Fixed by using (end - start + 1).
Fixes: 8e434cb705d463bc8cff935160e4fb4c77cb99ab ("cmd: mem: Add bitflip
memory test to alternate mtest")
Signed-off-by: Ralph Siemsen
Reviewed-by: Stefan Roese
Thanks,
Stefan
--
Changes in v2:
- Minor refactor to reduce line length
- Spellcheck and cleanup commit message
Change-Id: Ie641d04e731fc5bc6a3bbef914bf7fad136cdc94
---
cmd/mem.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/cmd/mem.c b/cmd/mem.c
index 9b97f7bf69..7bfa93d2a0 100644
--- a/cmd/mem.c
+++ b/cmd/mem.c
@@ -934,7 +934,7 @@ static ulong mem_test_quick(vu_long *buf, ulong start_addr,
ulong end_addr,
static int do_mem_mtest(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
- ulong start, end;
+ ulong start, end, half_size;
vu_long scratch_space;
vu_long *buf, *dummy = _space;
ulong iteration_limit = 0;
@@ -987,10 +987,11 @@ static int do_mem_mtest(struct cmd_tbl *cmdtp, int flag,
int argc,
if (errs == -1UL)
break;
count += errs;
+ half_size = (end - start + 1) / 2 /
+ sizeof(unsigned long);
errs = test_bitflip_comparison(buf,
- buf + (end - start) / 2,
- (end - start) /
- sizeof(unsigned long));
+ buf + half_size,
+ half_size);
} else {
errs = mem_test_quick(buf, start, end, pattern,
iteration);
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] cmd: mem: fix range of bitflip test
Hi Ralph, On 09.09.20 15:06, Ralph Siemsen wrote: Hi Stefan, On Wed, Sep 09, 2020 at 10:49:29AM +0200, Stefan Roese wrote: Hi Ralph, Thanks for finding and fixing this: I've sent a v2 with the suggested changes. Yes, thanks. Have also noticed that mtest takes considerably longer when doing the bitflip test. To the point where using it for manufacturing test is not really feasible anymore. Do you think it makes sense to add a Kconfig option for enabling the bitflip test? I agree that it's too time consuming (usually) for a manufacturing test. Either you are okay with disabling CONFIG_SYS_ALT_MEMTEST on your board, which will also disable this bitflip test. Or please continue adding a new Kconfig option for it - which is probable the better option. Thanks, Stefan
[PATCH 2/4] configs: stm32mp1: enable the fastboot oem command format
From: Jean-Philippe ROMAIN Enable the fastboot oem command format and set the variable "partitions" with default eMMC partitions list. Signed-off-by: Patrick Delaunay Signed-off-by: Jean-Philippe ROMAIN --- configs/stm32mp15_basic_defconfig | 1 + configs/stm32mp15_trusted_defconfig | 1 + include/configs/stm32mp1.h | 14 ++ 3 files changed, 16 insertions(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index fc3d2cc4fb..0f705eccb2 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -85,6 +85,7 @@ CONFIG_FASTBOOT_MMC_BOOT1_NAME="mmc1boot0" CONFIG_FASTBOOT_MMC_BOOT2_NAME="mmc1boot1" CONFIG_FASTBOOT_MMC_USER_SUPPORT=y CONFIG_FASTBOOT_MMC_USER_NAME="mmc1" +CONFIG_FASTBOOT_CMD_OEM_FORMAT=y CONFIG_DM_HWSPINLOCK=y CONFIG_HWSPINLOCK_STM32=y CONFIG_DM_I2C=y diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index bfe9e6b06c..3e9cca6a1e 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -65,6 +65,7 @@ CONFIG_FASTBOOT_MMC_BOOT1_NAME="mmc1boot0" CONFIG_FASTBOOT_MMC_BOOT2_NAME="mmc1boot1" CONFIG_FASTBOOT_MMC_USER_SUPPORT=y CONFIG_FASTBOOT_MMC_USER_NAME="mmc1" +CONFIG_FASTBOOT_CMD_OEM_FORMAT=y CONFIG_DM_HWSPINLOCK=y CONFIG_HWSPINLOCK_STM32=y CONFIG_DM_I2C=y diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h index b937233797..e3cbca9713 100644 --- a/include/configs/stm32mp1.h +++ b/include/configs/stm32mp1.h @@ -140,6 +140,19 @@ "run distro_bootcmd;" \ "fi;\0" +#ifdef CONFIG_FASTBOOT_CMD_OEM_FORMAT +/* eMMC default partitions for fastboot command: oem format */ +#define PARTS_DEFAULT \ + "partitions=" \ + "name=ssbl,size=2M;" \ + "name=bootfs,size=64MB,bootable;" \ + "name=vendorfs,size=16M;" \ + "name=rootfs,size=746M;" \ + "name=userfs,size=-\0" +#else +#define PARTS_DEFAULT +#endif + #include /* @@ -158,6 +171,7 @@ "altbootcmd=run bootcmd\0" \ "env_check=if env info -p -d -q; then env save; fi\0" \ STM32MP_BOOTCMD \ + PARTS_DEFAULT \ BOOTENV \ "boot_net_usb_start=true\0" -- 2.17.1
[PATCH 4/4] configs: stm32mp1: enable the fastboot oem command bootbus
Enable the fastboot oem command bootbus, used to configure the eMMC boot behavior, with same format than 'mmc bootbus' and with parameter: boot_bus_width reset_boot_bus_width boot_mode On stm32mp1 boards the expected command is $> fastboot oem partconf:0 0 0 Signed-off-by: Patrick Delaunay --- configs/stm32mp15_basic_defconfig | 1 + configs/stm32mp15_trusted_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index 6cbfbe5274..0115c9b891 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -87,6 +87,7 @@ CONFIG_FASTBOOT_MMC_USER_SUPPORT=y CONFIG_FASTBOOT_MMC_USER_NAME="mmc1" CONFIG_FASTBOOT_CMD_OEM_FORMAT=y CONFIG_FASTBOOT_CMD_OEM_PARTCONF=y +CONFIG_FASTBOOT_CMD_OEM_BOOTBUS=y CONFIG_DM_HWSPINLOCK=y CONFIG_HWSPINLOCK_STM32=y CONFIG_DM_I2C=y diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index cc114896df..470a2f4c35 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -67,6 +67,7 @@ CONFIG_FASTBOOT_MMC_USER_SUPPORT=y CONFIG_FASTBOOT_MMC_USER_NAME="mmc1" CONFIG_FASTBOOT_CMD_OEM_FORMAT=y CONFIG_FASTBOOT_CMD_OEM_PARTCONF=y +CONFIG_FASTBOOT_CMD_OEM_BOOTBUS=y CONFIG_DM_HWSPINLOCK=y CONFIG_HWSPINLOCK_STM32=y CONFIG_DM_I2C=y -- 2.17.1
[PATCH 1/4] configs: stm32mp1: enable fastboot support of eMMC boot partition
From: Jean-Philippe ROMAIN Activate fastboot support on boot partition for eMMC, mmc1 device on STMicroelectronics board (EV1). Signed-off-by: Jean-Philippe ROMAIN Signed-off-by: Patrick Delaunay --- configs/stm32mp15_basic_defconfig | 5 + configs/stm32mp15_trusted_defconfig | 5 + 2 files changed, 10 insertions(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index a8c4112dbe..fc3d2cc4fb 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -80,6 +80,11 @@ CONFIG_FASTBOOT_USB_DEV=1 CONFIG_FASTBOOT_FLASH=y CONFIG_FASTBOOT_FLASH_MMC_DEV=1 CONFIG_GPIO_HOG=y +CONFIG_FASTBOOT_MMC_BOOT_SUPPORT=y +CONFIG_FASTBOOT_MMC_BOOT1_NAME="mmc1boot0" +CONFIG_FASTBOOT_MMC_BOOT2_NAME="mmc1boot1" +CONFIG_FASTBOOT_MMC_USER_SUPPORT=y +CONFIG_FASTBOOT_MMC_USER_NAME="mmc1" CONFIG_DM_HWSPINLOCK=y CONFIG_HWSPINLOCK_STM32=y CONFIG_DM_I2C=y diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index 0792884a9d..bfe9e6b06c 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -60,6 +60,11 @@ CONFIG_FASTBOOT_USB_DEV=1 CONFIG_FASTBOOT_FLASH=y CONFIG_FASTBOOT_FLASH_MMC_DEV=1 CONFIG_GPIO_HOG=y +CONFIG_FASTBOOT_MMC_BOOT_SUPPORT=y +CONFIG_FASTBOOT_MMC_BOOT1_NAME="mmc1boot0" +CONFIG_FASTBOOT_MMC_BOOT2_NAME="mmc1boot1" +CONFIG_FASTBOOT_MMC_USER_SUPPORT=y +CONFIG_FASTBOOT_MMC_USER_NAME="mmc1" CONFIG_DM_HWSPINLOCK=y CONFIG_HWSPINLOCK_STM32=y CONFIG_DM_I2C=y -- 2.17.1
[PATCH 3/4] configs: stm32mp1: enable the fastboot oem command partconf
Enable the fastboot oem command partconf, used to select the correct eMMC boot partition, with same format than 'mmc partconf' with parameter: boot_ack boot_partition On stm32mp1 family: - boot_ack = 1 (Boot Acknowledge is needed by ROM code) - boot_partition = 1 or 2 (Boot partition 1 / 2 enabled for boot) So on EV1 board the expected commands to select boot partition 1 or 2 $> fastboot oem partconf:1 1 $> fastboot oem partconf:1 2 Signed-off-by: Patrick Delaunay --- configs/stm32mp15_basic_defconfig | 1 + configs/stm32mp15_trusted_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index 0f705eccb2..6cbfbe5274 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -86,6 +86,7 @@ CONFIG_FASTBOOT_MMC_BOOT2_NAME="mmc1boot1" CONFIG_FASTBOOT_MMC_USER_SUPPORT=y CONFIG_FASTBOOT_MMC_USER_NAME="mmc1" CONFIG_FASTBOOT_CMD_OEM_FORMAT=y +CONFIG_FASTBOOT_CMD_OEM_PARTCONF=y CONFIG_DM_HWSPINLOCK=y CONFIG_HWSPINLOCK_STM32=y CONFIG_DM_I2C=y diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index 3e9cca6a1e..cc114896df 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -66,6 +66,7 @@ CONFIG_FASTBOOT_MMC_BOOT2_NAME="mmc1boot1" CONFIG_FASTBOOT_MMC_USER_SUPPORT=y CONFIG_FASTBOOT_MMC_USER_NAME="mmc1" CONFIG_FASTBOOT_CMD_OEM_FORMAT=y +CONFIG_FASTBOOT_CMD_OEM_PARTCONF=y CONFIG_DM_HWSPINLOCK=y CONFIG_HWSPINLOCK_STM32=y CONFIG_DM_I2C=y -- 2.17.1
[PATCH 4/4] fastboot: add command to select the eMMC boot configuration
Add command oem bootbus which executes the command
``mmc bootbus `` on the current fastboot mmc device
( = CONFIG_FASTBOOT_FLASH_MMC_DEV) to set the eMMC boot
configuration on first update, with
= boot_bus_width reset_boot_bus_width boot_mode
$> fastboot oem bootbus:
Signed-off-by: Patrick Delaunay
---
doc/android/fastboot.rst | 1 +
drivers/fastboot/Kconfig | 7 +++
drivers/fastboot/fb_command.c | 36 +++
include/fastboot.h| 3 +++
4 files changed, 47 insertions(+)
diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
index 7d69372753..6aa725fcd8 100644
--- a/doc/android/fastboot.rst
+++ b/doc/android/fastboot.rst
@@ -25,6 +25,7 @@ The following OEM commands are supported (if enabled):
- ``oem format`` - this executes ``gpt write mmc %x $partitions``
- ``oem partconf`` - this executes ``mmc partconf %x 0`` to configure
eMMC
with = boot_ack boot_partition
+- ``oem bootbus`` - this executes ``mmc bootbus %x %s`` to configure eMMC
Support for both eMMC and NAND devices is included.
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index 1bcc8d4ab9..a17e488714 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -196,6 +196,13 @@ config FASTBOOT_CMD_OEM_PARTCONF
Add support for the "oem partconf" command from a client. This set
the mmc boot-partition for the selecting eMMC device.
+config FASTBOOT_CMD_OEM_BOOTBUS
+ bool "Enable the 'oem bootbus' command"
+ depends on FASTBOOT_FLASH_MMC && SUPPORT_EMMC_BOOT
+ help
+ Add support for the "oem bootbus" command from a client. This set
+ the mmc boot configuration for the selecting eMMC device.
+
endif # FASTBOOT
endmenu
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index e42c018348..00efd477db 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -43,6 +43,9 @@ static void oem_format(char *, char *);
#if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_PARTCONF)
static void oem_partconf(char *, char *);
#endif
+#if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_BOOTBUS)
+static void oem_bootbus(char *, char *);
+#endif
static const struct {
const char *command;
@@ -98,6 +101,12 @@ static const struct {
.dispatch = oem_partconf,
},
#endif
+#if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_BOOTBUS)
+ [FASTBOOT_COMMAND_OEM_BOOTBUS] = {
+ .command = "oem bootbus",
+ .dispatch = oem_bootbus,
+ },
+#endif
};
/**
@@ -372,3 +381,30 @@ static void oem_partconf(char *cmd_parameter, char
*response)
fastboot_okay(NULL, response);
}
#endif
+
+#if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_BOOTBUS)
+/**
+ * oem_bootbus() - Execute the OEM bootbus command
+ *
+ * @cmd_parameter: Pointer to command parameter
+ * @response: Pointer to fastboot response buffer
+ */
+static void oem_bootbus(char *cmd_parameter, char *response)
+{
+ char cmdbuf[32];
+
+ if (!cmd_parameter) {
+ fastboot_fail("Expected command parameter", response);
+ return;
+ }
+
+ /* execute 'mmc bootbus' command with cmd_parameter arguments*/
+ snprintf(cmdbuf, sizeof(cmdbuf), "mmc bootbus %x %s",
+CONFIG_FASTBOOT_FLASH_MMC_DEV, cmd_parameter);
+ printf("Execute: %s\n", cmdbuf);
+ if (run_command(cmdbuf, 0))
+ fastboot_fail("Cannot set oem bootbus", response);
+ else
+ fastboot_okay(NULL, response);
+}
+#endif
diff --git a/include/fastboot.h b/include/fastboot.h
index 3e68852e9a..966ffc6d94 100644
--- a/include/fastboot.h
+++ b/include/fastboot.h
@@ -39,6 +39,9 @@ enum {
#if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_PARTCONF)
FASTBOOT_COMMAND_OEM_PARTCONF,
#endif
+#if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_BOOTBUS)
+ FASTBOOT_COMMAND_OEM_BOOTBUS,
+#endif
FASTBOOT_COMMAND_COUNT
};
--
2.17.1
