Re: [PATCH 01/26] lib: rational: copy the rational fraction lib routines from Linux
On 10/11/2020 14:55, Tom Rini wrote: On Tue, Nov 10, 2020 at 11:05:37AM +0200, Tero Kristo wrote: Copy the best rational approximation calculation routines from Linux. Typical usecase for these routines is to calculate the M/N divider values for PLLs to reach a specific clock rate. Signed-off-by: Tero Kristo Please say what version of the Linux kernel this is from, for easier later re-syncing. Thanks. This is based on kernel commit: commit 323dd2c3ed0641f49e89b4e420f9eef5d3d5a881 Author: Trent Piepho Date: Wed Dec 4 16:51:57 2019 -0800 lib/math/rational.c: fix possible incorrect result from rational fractions helper -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 2/2] riscv: sifive/fu540: kconfig: Enable support for Opencores I2C controller
> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com] > Sent: Thursday, October 22, 2020 2:55 PM > To: u-boot@lists.denx.de > Cc: atish.pa...@wdc.com; palmerdabb...@google.com; bmeng...@gmail.com; > paul.walms...@sifive.com; anup.pa...@wdc.com; sagar.ka...@sifive.com; Rick > Jian-Zhi Chen(陳建志); pe...@korsgaard.com; Pragnesh Patel; Palmer Dabbelt; Bin > Meng; Jagan Teki; Sean Anderson > Subject: [PATCH v2 2/2] riscv: sifive/fu540: kconfig: Enable support for > Opencores I2C controller > > Enable support for SiFive FU540 Opencores I2C master controller. > > Signed-off-by: Pragnesh Patel > --- > > (no changes since v1) > > arch/riscv/cpu/fu540/Kconfig | 2 ++ > board/sifive/fu540/Kconfig | 1 + > 2 files changed, 3 insertions(+) > Reviewed-by: Rick Chen
Re: [PATCH v2 1/2] i2c: ocores: add i2c driver for OpenCores I2C controller
> From: Pragnesh Patel [mailto:pragnesh.pa...@sifive.com] > Sent: Thursday, October 22, 2020 2:55 PM > To: u-boot@lists.denx.de > Cc: atish.pa...@wdc.com; palmerdabb...@google.com; bmeng...@gmail.com; > paul.walms...@sifive.com; anup.pa...@wdc.com; sagar.ka...@sifive.com; Rick > Jian-Zhi Chen(陳建志); pe...@korsgaard.com; Pragnesh Patel; Heiko Schocher > Subject: [PATCH v2 1/2] i2c: ocores: add i2c driver for OpenCores I2C > controller > > Add support for the OpenCores I2C controller IP core > (See http://www.opencores.org/projects.cgi/web/i2c/overview). > > This driver implementation is inspired from the Linux OpenCores > I2C driver available. > > Thanks to Peter Korsgaard for writing Linux > OpenCores I2C driver. > > Signed-off-by: Pragnesh Patel > --- > > Changes in v2: > - Remove TYPE_SIFIVE_REV0 flag > - Update the Opencores I2C Controller Link > > drivers/i2c/Kconfig | 7 + > drivers/i2c/Makefile | 1 + > drivers/i2c/ocores_i2c.c | 636 +++ > 3 files changed, 644 insertions(+) > create mode 100644 drivers/i2c/ocores_i2c.c > Reviewed-by: Rick Chen
Re: [PATCH] binman: Handle tool paths containing '~' correctly
Hi Alper, On Tue, 10 Nov 2020 at 07:45, Alper Nebi Yasak wrote: > > On 09/11/2020 17:45, Simon Glass wrote: > > At present if CROSS_COMPILE contains a tilde, such as > > ~/.buildman-toolchains/gcc-7.3.0-nolibc/i386-linux/bin/i386-linux-gcc > > then binman gives a confusing error: > > > >binman: Error 255 running '~/..buildman-toolchains/gcc-7.3.0- ... > > > > Fix this by expanding it out before running the tool. > > > > Signed-off-by: Simon Glass > > Arguably, whatever is passing CROSS_COMPILE to binman should have > expanded that; how are you passing it? If that's from shell you could > use one of CROSS_COMPILE="$HOME/..." or ~/"..." (the "~/..." form isn't > expanded), if it's read from e.g. ~/.buildman then the config parser > should be expanding it at read-time. This is actually happening in my lab because tbot is set to use the home directory for the toolchains. It is set up in the 'lab.py' Python file and uses ~ to avoid hard-coding it to a particular machine. Regards, Simon
Re: [PATCH] rockchip: Move Bob specific bits to it's specific u-boot.dtsi
On 10/11/2020 20:18, Hugh Cole-Baker wrote:
> Hi,
>
>> On 10 Nov 2020, at 07:34, Kever Yang wrote:
>>
>> Hi Peter,
>>
>> On 2020/11/9 上午7:02, Peter Robinson wrote:
>>> Move the bits that are device specific to the -u-boot.dtsi as the
>>> bits may be different on other devices and hence breaks SPI on
>>> those devices such as the Pinebook Pro.
>>>
>>> Signed-off-by: Peter Robinson
>>> Fixes: c4cea2bbf995 ("rockchip: Enable building a SPI ROM image on bob")
>>> Cc: Simon Glass
>>> ---
>>> arch/arm/dts/rk3399-gru-u-boot.dtsi | 30 +
>>> arch/arm/dts/rk3399-u-boot.dtsi | 25
>>> 2 files changed, 30 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi
>>> b/arch/arm/dts/rk3399-gru-u-boot.dtsi
>>> index 390ac2bb5a..5e95cacfea 100644
>>> --- a/arch/arm/dts/rk3399-gru-u-boot.dtsi
>>> +++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi
>>> @@ -5,6 +5,36 @@
>>>#include "rk3399-u-boot.dtsi"
>>> +/ {
>>> + aliases {
>>> + spi1 =
>>> + };
>>> +};
>>
>> Does this still need to remove from common code after your another patch
>> applied? It look reasonable and
>>
>> not likely to break others.
>>
>> https://patchwork.ozlabs.org/project/uboot/patch/20201108140023.32501-1-sigma...@gmail.com/
>
> My patch linked above was aiming to fix SPI boot on the rockpro64 by
> adapting to the spi1 alias that's now in the rk3399-u-boot.dtsi rather
> than removing it (in fact, my patch wouldn't work correctly if the spi1
> alias was removed). This seemed like one good solution as the RK3399 does
> physically have SPI buses 0 to 5, and out of those the SPI flash is on
> bus 1, so I thought it'd be better to refer to it as bus 1 instead of
> aliasing it to bus 0.
It looks like something similar to your patch works on the Pinebook Pro,
see this other thread about rk3399 SPI breakage [1] and one recent mail
from it [2].
[1] https://lists.denx.de/pipermail/u-boot/2020-November/432046.html
[2] https://lists.denx.de/pipermail/u-boot/2020-November/432505.html
> I see now, though, that it's not just the rockpro64 that's affected, but
> also Pinebook Pro and it seems rk3399-roc-pc. If the consensus is that
> my patch is the right approach, I can send another series with the same
> type of fix for the PBP and rk3399-roc-pc. Otherwise this patch should
> be used and my patch shouldn't be applied as it relies on the spi1 alias
> that this patch removes.
Looks to me like the full list is (though I don't have those boards):
pinebook-pro-rk3399 rk3399-pinebook-pro-u-boot.dtsi
puma-rk3399 rk3399-puma-haikou-u-boot.dtsi
roc-pc-rk3399 rk3399-roc-pc-u-boot.dtsi
roc-pc-mezzanine-rk3399 ``
rockpro64-rk3399rk3399-rockpro64-u-boot.dtsi
> Regards,
> Hugh
>
>>
>>> +
>>> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
>>> + {
>>> + rom {
>>> + filename = "u-boot.rom";
>>> + size = <0x40>;
>>> + pad-byte = <0xff>;
>>> +
>>> + mkimage {
>>> + args = "-n rk3399 -T rkspi";
>>> + u-boot-spl {
>>> + };
>>> + };
>>> + u-boot-img {
>>> + offset = <0x4>;
>>> + };
>>> + u-boot {
>>> + offset = <0x30>;
>>> + };
>>> + fdtmap {
>>> + };
>>> + };
>>> +};
>>> +#endif
>>
>>
>> What's the image space mapping for Pinebook Pro do you using?
>>
>> I think there should be another binman config if this is not common .
>>
>>
>> Thanks,
>>
>> - Kever
>>
>>> +
>>> _flash {
>>> u-boot,dm-pre-reloc;
>>> };
>>> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi
>>> b/arch/arm/dts/rk3399-u-boot.dtsi
>>> index ecd230c720..26b0a34e64 100644
>>> --- a/arch/arm/dts/rk3399-u-boot.dtsi
>>> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
>>> @@ -11,7 +11,6 @@
>>> mmc0 =
>>> mmc1 =
>>> pci0 =
>>> - spi1 =
>>> };
>>> cic: syscon@ff62 {
>>> @@ -60,30 +59,6 @@
>>>};
>>> -#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
>>> - {
>>> - rom {
>>> - filename = "u-boot.rom";
>>> - size = <0x40>;
>>> - pad-byte = <0xff>;
>>> -
>>> - mkimage {
>>> - args = "-n rk3399 -T rkspi";
>>> - u-boot-spl {
>>> - };
>>> - };
>>> - u-boot-img {
>>> - offset = <0x4>;
>>> - };
>>> - u-boot {
>>> - offset = <0x30>;
>>> - };
>>> - fdtmap {
>>> - };
>>> - };
>>> -};
>>> -#endif
>>> -
>>> {
>>> u-boot,dm-pre-reloc;
>>> };
>
[PATCH v2 1/3] mmc: meson-gx: move arch header to local header
From: Neil Armstrong
Move the asm/arch-meson/sd_emmc.h to a local meson_gx_mmc.h,
remove the useless if/then and fix the meson_gx_mmc.c include.
Signed-off-by: Neil Armstrong
---
drivers/mmc/meson_gx_mmc.c | 2 +-
.../asm/arch-meson/sd_emmc.h => drivers/mmc/meson_gx_mmc.h | 7 ++-
2 files changed, 3 insertions(+), 6 deletions(-)
rename arch/arm/include/asm/arch-meson/sd_emmc.h => drivers/mmc/meson_gx_mmc.h
(97%)
diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
index 719dd1e5e570..eedebb317b5f 100644
--- a/drivers/mmc/meson_gx_mmc.c
+++ b/drivers/mmc/meson_gx_mmc.c
@@ -13,9 +13,9 @@
#include
#include
#include
-#include
#include
#include
+#include "meson_gx_mmc.h"
static inline void *get_regbase(const struct mmc *mmc)
{
diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h
b/drivers/mmc/meson_gx_mmc.h
similarity index 97%
rename from arch/arm/include/asm/arch-meson/sd_emmc.h
rename to drivers/mmc/meson_gx_mmc.h
index 1e9f8cf498b4..b4544b55628f 100644
--- a/arch/arm/include/asm/arch-meson/sd_emmc.h
+++ b/drivers/mmc/meson_gx_mmc.h
@@ -3,14 +3,11 @@
* (C) Copyright 2016 Carlo Caione
*/
-#ifndef __SD_EMMC_H__
-#define __SD_EMMC_H__
+#ifndef __MESON_GX_MMC_H__
+#define __MESON_GX_MMC_H__
#include
-#ifndef __ASSEMBLY__
#include
-#endif
-
#define SDIO_PORT_A0
#define SDIO_PORT_B1
--
2.29.0
[PATCH v2 3/3] ARM: dts: meson-sm1: add u-boot specific MMC controller compatible
From: Neil Armstrong
In order to enable the Amlogic SM1 MMC controller fix, we need to add a u-boot
specific
MMC controller compatible.
This adds a new meson-sm1-u-boot.dtsi and reworks the other -u-boot.dtsi
to use this for SM1 based boards.
Signed-off-by: Neil Armstrong
---
.../meson-g12b-a311d-khadas-vim3-u-boot.dtsi | 1 +
arch/arm/dts/meson-khadas-vim3-u-boot.dtsi| 2 --
.../dts/meson-sm1-khadas-vim3l-u-boot.dtsi| 1 +
arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi | 2 +-
arch/arm/dts/meson-sm1-sei610-u-boot.dtsi | 2 +-
arch/arm/dts/meson-sm1-u-boot.dtsi| 20 +++
6 files changed, 24 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/dts/meson-sm1-u-boot.dtsi
diff --git a/arch/arm/dts/meson-g12b-a311d-khadas-vim3-u-boot.dtsi
b/arch/arm/dts/meson-g12b-a311d-khadas-vim3-u-boot.dtsi
index f66eca14b12c..489efa150a6e 100644
--- a/arch/arm/dts/meson-g12b-a311d-khadas-vim3-u-boot.dtsi
+++ b/arch/arm/dts/meson-g12b-a311d-khadas-vim3-u-boot.dtsi
@@ -4,4 +4,5 @@
* Author: Neil Armstrong
*/
+#include "meson-g12-common-u-boot.dtsi"
#include "meson-khadas-vim3-u-boot.dtsi"
diff --git a/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
b/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
index b5da4fdfc3ee..81fd5be3783b 100644
--- a/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
+++ b/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
@@ -4,8 +4,6 @@
* Author: Neil Armstrong
*/
-#include "meson-g12-common-u-boot.dtsi"
-
/ {
aliases {
spi0 =
diff --git a/arch/arm/dts/meson-sm1-khadas-vim3l-u-boot.dtsi
b/arch/arm/dts/meson-sm1-khadas-vim3l-u-boot.dtsi
index f66eca14b12c..a591c0c9f230 100644
--- a/arch/arm/dts/meson-sm1-khadas-vim3l-u-boot.dtsi
+++ b/arch/arm/dts/meson-sm1-khadas-vim3l-u-boot.dtsi
@@ -4,4 +4,5 @@
* Author: Neil Armstrong
*/
+#include "meson-sm1-u-boot.dtsi"
#include "meson-khadas-vim3-u-boot.dtsi"
diff --git a/arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi
b/arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi
index 2a8f0545b1a3..c4319880759f 100644
--- a/arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi
+++ b/arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi
@@ -4,7 +4,7 @@
* Author: Neil Armstrong
*/
-#include "meson-g12-common-u-boot.dtsi"
+#include "meson-sm1-u-boot.dtsi"
{
snps,reset-gpio = < GPIOZ_15 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>;
diff --git a/arch/arm/dts/meson-sm1-sei610-u-boot.dtsi
b/arch/arm/dts/meson-sm1-sei610-u-boot.dtsi
index 236f2468dc20..8ebc1caa4a79 100644
--- a/arch/arm/dts/meson-sm1-sei610-u-boot.dtsi
+++ b/arch/arm/dts/meson-sm1-sei610-u-boot.dtsi
@@ -4,4 +4,4 @@
* Author: Neil Armstrong
*/
-#include "meson-g12-common-u-boot.dtsi"
+#include "meson-sm1-u-boot.dtsi"
diff --git a/arch/arm/dts/meson-sm1-u-boot.dtsi
b/arch/arm/dts/meson-sm1-u-boot.dtsi
new file mode 100644
index ..e05d4c369adc
--- /dev/null
+++ b/arch/arm/dts/meson-sm1-u-boot.dtsi
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2020 BayLibre, SAS.
+ * Author: Neil Armstrong
+ */
+
+#include "meson-g12-common-u-boot.dtsi"
+
+_emmc_a {
+ compatible = "amlogic,meson-sm1-mmc";
+};
+
+_emmc_b {
+ compatible = "amlogic,meson-sm1-mmc";
+};
+
+_emmc_c {
+ compatible = "amlogic,meson-sm1-mmc";
+};
+
--
2.29.0
[PATCH v2 0/3] mmc: meson-gx: fix mmc & sdcard failur on SM1 SoCs
Amlogic SM1 SoCs doesn't work over 50MHz. When phase sets to 270', it's working fine over 50MHz on Amlogic SM1 SoCs. To use a proper phase value adds an u-boot only sm1 compatible. In future, it needs to find what value is a proper about each SoCs. According to Neil's suggestion, applied code based on below patch. https://patchwork.ozlabs.org/project/uboot/patch/20201109031233.25320-1-jh80.ch...@samsung.com Tested on Odroid-C4/N2, VIM3. Changelog v2: - Rewrote "[2/3] mmc: meson-gx: limit max frequency on SM1 SoCs" - Applied "mmc: meson_gx_mmc: change a clock phase to stable value" - Add Jaehoon's Signed-off tag Neil Armstrong (3): mmc: meson-gx: move arch header to local header mmc: meson-gx: change clock phase value on SM1 SoCs ARM: dts: meson-sm1: add u-boot specific MMC controller compatible .../meson-g12b-a311d-khadas-vim3-u-boot.dtsi | 1 + arch/arm/dts/meson-khadas-vim3-u-boot.dtsi| 2 -- .../dts/meson-sm1-khadas-vim3l-u-boot.dtsi| 1 + arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi | 2 +- arch/arm/dts/meson-sm1-sei610-u-boot.dtsi | 2 +- arch/arm/dts/meson-sm1-u-boot.dtsi| 20 + drivers/mmc/meson_gx_mmc.c| 29 +++ .../sd_emmc.h => drivers/mmc/meson_gx_mmc.h | 10 --- 8 files changed, 54 insertions(+), 13 deletions(-) create mode 100644 arch/arm/dts/meson-sm1-u-boot.dtsi rename arch/arm/include/asm/arch-meson/sd_emmc.h => drivers/mmc/meson_gx_mmc.h (95%) -- 2.29.0
[PATCH v2 2/3] mmc: meson-gx: change clock phase value on SM1 SoCs
From: Neil Armstrong
Amlogic SM1 SoCs doesn't work over 50MHz. When phase sets to 270', it's
working fine over 50MHz on Amlogic SM1 SoCs.
Since Other Amlogic SoCs doens't report an issue, phase value is using
to 180' by default.
To distinguish which value is used adds an u-boot only sm1 compatible.
In future, it needs to find what value is a proper about each SoCs.
Signed-off-by: Neil Armstrong
Signed-off-by: Jaehoon Chung
---
drivers/mmc/meson_gx_mmc.c | 27 +++
drivers/mmc/meson_gx_mmc.h | 5 +
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
index eedebb317b5f..a5e9ac5637b9 100644
--- a/drivers/mmc/meson_gx_mmc.c
+++ b/drivers/mmc/meson_gx_mmc.c
@@ -17,6 +17,14 @@
#include
#include "meson_gx_mmc.h"
+bool meson_gx_mmc_is_compatible(struct udevice *dev,
+ enum meson_gx_mmc_compatible family)
+{
+ enum meson_gx_mmc_compatible compat = dev_get_driver_data(dev);
+
+ return compat == family;
+}
+
static inline void *get_regbase(const struct mmc *mmc)
{
struct meson_mmc_platdata *pdata = mmc->priv;
@@ -42,6 +50,8 @@ static void meson_mmc_config_clock(struct mmc *mmc)
if (!mmc->clock)
return;
+ /* TOFIX This should use the proper clock taken from DT */
+
/* 1GHz / CLK_MAX_DIV = 15,9 MHz */
if (mmc->clock > 1600) {
clk = SD_EMMC_CLKSRC_DIV2;
@@ -52,8 +62,16 @@ static void meson_mmc_config_clock(struct mmc *mmc)
}
clk_div = DIV_ROUND_UP(clk, mmc->clock);
- /* 180 phase core clock */
- meson_mmc_clk |= CLK_CO_PHASE_180;
+ /*
+* SM1 SoCs doesn't work fine over 50MHz with CLK_CO_PHASE_180
+* If CLK_CO_PHASE_270 is used, it's more stable than other.
+* Other SoCs use CLK_CO_PHASE_180 by default.
+* It needs to find what is a proper value about each SoCs.
+*/
+ if (meson_gx_mmc_is_compatible(mmc->dev, MMC_COMPATIBLE_SM1))
+ meson_mmc_clk |= CLK_CO_PHASE_270;
+ else
+ meson_mmc_clk |= CLK_CO_PHASE_180;
/* 180 phase tx clock */
meson_mmc_clk |= CLK_TX_PHASE_000;
@@ -308,8 +326,9 @@ int meson_mmc_bind(struct udevice *dev)
}
static const struct udevice_id meson_mmc_match[] = {
- { .compatible = "amlogic,meson-gx-mmc" },
- { .compatible = "amlogic,meson-axg-mmc" },
+ { .compatible = "amlogic,meson-gx-mmc", .data = MMC_COMPATIBLE_GX },
+ { .compatible = "amlogic,meson-axg-mmc", .data = MMC_COMPATIBLE_GX },
+ { .compatible = "amlogic,meson-sm1-mmc", .data = MMC_COMPATIBLE_SM1 },
{ /* sentinel */ }
};
diff --git a/drivers/mmc/meson_gx_mmc.h b/drivers/mmc/meson_gx_mmc.h
index b4544b55628f..92aec5329f6e 100644
--- a/drivers/mmc/meson_gx_mmc.h
+++ b/drivers/mmc/meson_gx_mmc.h
@@ -9,6 +9,11 @@
#include
#include
+enum meson_gx_mmc_compatible {
+ MMC_COMPATIBLE_GX,
+ MMC_COMPATIBLE_SM1,
+};
+
#define SDIO_PORT_A0
#define SDIO_PORT_B1
#define SDIO_PORT_C2
--
2.29.0
Re: [PATCH] sandbox: cros_ec: Basic support for EC_CMD_GET_NEXT_EVENT
On 10/11/2020 20:08, Heinrich Schuchardt wrote:
> On 10.11.20 15:00, Alper Nebi Yasak wrote:
>> Since commit 690079767803 ("cros_ec: Support keyboard scanning with
>> EC_CMD_GET_NEXT_EVENT") the cros-ec-keyb driver has started using this
>> command, but the sandbox EC emulator does not recognize it and
>> continuously prints:
>>
>> ** Unknown EC command 0x67
>>
>> This patch makes the sandbox driver send basic responses to the command,
>> but the response only supports keyboard scans for now.
>>
>> Fixes: 690079767803 ("cros_ec: Support keyboard scanning with
>> EC_CMD_GET_NEXT_EVENT")
>> Reported-by: Heinrich Schuchardt
>> Signed-off-by: Alper Nebi Yasak
>> ---
>> This doesn't test the -EC_RES_UNAVAILABLE part, which looks like an
>> event queue on the EC side. As far as I understand sandbox is getting a
>> single keyboard state from SDL after discarding pending events. I think
>> things would need to be hooked into sandbox_sdl_poll_events, looks
>> possible but harder.
>>
>> Also, now that this command would work, the fallback to the old one
>> would never trigger and wouldn't be tested.
>
> Should some of the comment above be merged into the commit message?
Yeah, probably. I just defaulted to the notes since I'd be writing in an
informal tone and was not sure if leaving those as future work is OK.
> Tested-by: Heinrich Schuchardt
Thanks.
>>
>> drivers/misc/cros_ec_sandbox.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/misc/cros_ec_sandbox.c b/drivers/misc/cros_ec_sandbox.c
>> index a191f061b898..d72db3eace98 100644
>> --- a/drivers/misc/cros_ec_sandbox.c
>> +++ b/drivers/misc/cros_ec_sandbox.c
>> @@ -460,6 +460,14 @@ static int process_cmd(struct ec_state *ec,
>> case EC_CMD_ENTERING_MODE:
>> len = 0;
>> break;
>> +case EC_CMD_GET_NEXT_EVENT: {
>> +struct ec_response_get_next_event *resp = resp_data;
>> +
>> +resp->event_type = EC_MKBP_EVENT_KEY_MATRIX;
>> +cros_ec_keyscan(ec, resp->data.key_matrix);
>> +len = sizeof(*resp);
>> +break;
>> +}
>> default:
>> printf(" ** Unknown EC command %#02x\n", req_hdr->command);
>> return -1;
>>
>
[PATCH 3/3] efi_selftest: implement exception test for sandbox
Provide a unit test that causes an illegal instruction to occur.
The test can be run with the following commands:
=> setenv efi_selftest exception
=> bootefi selftest
This might be the output:
Executing 'exception'
EFI application triggers exception.
Illegal instruction
pc = 0x1444d016, pc_reloc = 0xaa078e8dd016
UEFI image [0x:0x] '/\selftest'
UEFI image [0x1444b000:0x14451fff] pc=0x2016 '/bug.efi'
Resetting ...
It would tell us that the exception was triggered by an instruction
0x2016 bytes after the load address of the binary with filename /bug.efi.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/efi_selftest_miniapp_exception.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/efi_selftest/efi_selftest_miniapp_exception.c
b/lib/efi_selftest/efi_selftest_miniapp_exception.c
index 63c63d75f1..59b7e5100a 100644
--- a/lib/efi_selftest/efi_selftest_miniapp_exception.c
+++ b/lib/efi_selftest/efi_selftest_miniapp_exception.c
@@ -33,6 +33,8 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
asm volatile (".word 0xe7f7defb\n");
#elif defined(CONFIG_RISCV)
asm volatile (".word 0x\n");
+#elif defined(CONFIG_SANDBOX)
+ asm volatile (".word 0x\n");
#elif defined(CONFIG_X86)
asm volatile (".word 0x\n");
#endif
--
2.28.0
[PATCH 1/3] sandbox: add handler for exceptions
Add a handler for SIGILL, SIGBUS, SIGSEGV.
When an exception occurs print the program counter and the loaded
UEFI binaries and reset the system.
Signed-off-by: Heinrich Schuchardt
---
arch/sandbox/cpu/os.c | 31 +++
arch/sandbox/cpu/start.c | 4
arch/sandbox/lib/interrupts.c | 30 ++
include/os.h | 17 +
4 files changed, 82 insertions(+)
diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 0d8efd83f6..d1c2c9fddd 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -3,6 +3,8 @@
* Copyright (c) 2011 The Chromium OS Authors.
*/
+#define _GNU_SOURCE
+
#include
#include
#include
@@ -15,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -191,6 +194,34 @@ static void os_sigint_handler(int sig)
raise(SIGINT);
}
+static void os_signal_handler(int sig, siginfo_t *info, void *con)
+{
+ ucontext_t *context = con;
+ unsigned long pc = 0;
+
+#ifdef __x86_64__
+ pc = context->uc_mcontext.gregs[REG_RIP];
+#elif __aarch64__
+ pc = context->uc_mcontext.pc;
+#endif
+
+ os_signal_action(sig, pc);
+}
+
+int os_setup_signal_handlers(void)
+{
+ struct sigaction act;
+
+ act.sa_sigaction = os_signal_handler;
+ sigemptyset(_mask);
+ act.sa_flags = SA_SIGINFO;
+ if (sigaction(SIGILL, , NULL) ||
+ sigaction(SIGBUS, , NULL) ||
+ sigaction(SIGSEGV, , NULL))
+ return -1;
+ return 0;
+}
+
/* Put tty into raw mode so and work */
void os_tty_raw(int fd, bool allow_sigs)
{
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index a03e5aa0b3..f6c98545e0 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -451,6 +451,10 @@ int main(int argc, char *argv[])
if (ret)
goto err;
+ ret = os_setup_signal_handlers();
+ if (ret)
+ goto err;
+
#if CONFIG_VAL(SYS_MALLOC_F_LEN)
gd->malloc_base = CONFIG_MALLOC_F_ADDR;
#endif
diff --git a/arch/sandbox/lib/interrupts.c b/arch/sandbox/lib/interrupts.c
index 21f761ac3b..3c8f3df715 100644
--- a/arch/sandbox/lib/interrupts.c
+++ b/arch/sandbox/lib/interrupts.c
@@ -6,7 +6,13 @@
*/
#include
+#include
#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
int interrupt_init(void)
{
@@ -21,3 +27,27 @@ int disable_interrupts(void)
{
return 0;
}
+
+void os_signal_action(int sig, unsigned long pc)
+{
+ efi_restore_gd();
+
+ switch (sig) {
+ case SIGILL:
+ printf("Illegal instruction\n");
+ break;
+ case SIGBUS:
+ printf("Bus error\n");
+ break;
+ case SIGSEGV:
+ printf("Segmentation violation\n");
+ break;
+ default:
+ break;
+ }
+ printf("pc = 0x%lx, ", pc);
+ printf("pc_reloc = 0x%lx\n", pc - gd->reloc_off);
+ efi_print_image_infos((void *)pc);
+ printf("Resetting ...\n\n");
+ sandbox_reset();
+}
diff --git a/include/os.h b/include/os.h
index 1fe44f3510..0913b47b3a 100644
--- a/include/os.h
+++ b/include/os.h
@@ -407,4 +407,21 @@ void *os_find_text_base(void);
*/
void os_relaunch(char *argv[]);
+/**
+ * os_setup_signal_handlers() - setup signal handlers
+ *
+ * Install signal handlers for SIGBUS and SIGSEGV.
+ *
+ * Return: 0 for success
+ */
+int os_setup_signal_handlers(void);
+
+/**
+ * os_signal_action() - handle a signal
+ *
+ * @sig: signal
+ * @pc:program counter
+ */
+void os_signal_action(int sig, unsigned long pc);
+
#endif
--
2.28.0
[PATCH 2/3] cmd: sandbox: implement exception command
Implement the commands
* exception undefined - execute an illegal instruction
* exception sigsegv - cause a segment violation
Here is a possible output:
=> exception undefined
Illegal instruction
pc = 0x55eb8d0a7575, pc_reloc = 0x57575
Resetting ...
Signed-off-by: Heinrich Schuchardt
---
cmd/Kconfig | 2 +-
cmd/Makefile| 1 +
cmd/sandbox/Makefile| 3 +++
cmd/sandbox/exception.c | 41 +
4 files changed, 46 insertions(+), 1 deletion(-)
create mode 100644 cmd/sandbox/Makefile
create mode 100644 cmd/sandbox/exception.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 1595de999b..f9b72449c5 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1682,7 +1682,7 @@ config CMD_EFIDEBUG
config CMD_EXCEPTION
bool "exception - raise exception"
- depends on ARM || RISCV || X86
+ depends on ARM || RISCV || SANDBOX || X86
help
Enable the 'exception' command which allows to raise an exception.
diff --git a/cmd/Makefile b/cmd/Makefile
index dd86675bf2..5b3400a840 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -193,6 +193,7 @@ obj-$(CONFIG_CMD_AVB) += avb.o
obj-$(CONFIG_ARM) += arm/
obj-$(CONFIG_RISCV) += riscv/
+obj-$(CONFIG_SANDBOX) += sandbox/
obj-$(CONFIG_X86) += x86/
obj-$(CONFIG_ARCH_MVEBU) += mvebu/
diff --git a/cmd/sandbox/Makefile b/cmd/sandbox/Makefile
new file mode 100644
index 00..24df023ece
--- /dev/null
+++ b/cmd/sandbox/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_CMD_EXCEPTION) += exception.o
diff --git a/cmd/sandbox/exception.c b/cmd/sandbox/exception.c
new file mode 100644
index 00..1aa1d673ae
--- /dev/null
+++ b/cmd/sandbox/exception.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * The 'exception' command can be used for testing exception handling.
+ *
+ * Copyright (c) 2020, Heinrich Schuchardt
+ */
+
+#include
+#include
+
+static int do_sigsegv(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ u8 *ptr = NULL;
+
+ *ptr = 0;
+ return CMD_RET_FAILURE;
+}
+
+static int do_undefined(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ asm volatile (".word 0x\n");
+ return CMD_RET_FAILURE;
+}
+
+static struct cmd_tbl cmd_sub[] = {
+ U_BOOT_CMD_MKENT(sigsegv, CONFIG_SYS_MAXARGS, 1, do_sigsegv,
+"", ""),
+ U_BOOT_CMD_MKENT(undefined, CONFIG_SYS_MAXARGS, 1, do_undefined,
+"", ""),
+};
+
+static char exception_help_text[] =
+ "\n"
+ " The following exceptions are available:\n"
+ " undefined - undefined instruction\n"
+ " sigsegv- illegal memory access\n"
+ ;
+
+#include
--
2.28.0
[PATCH 0/3] sandbox: exception handling
Currently if an exception SIGILL, SIGBUS, SIGSEGV occurs the sandbox stops execution. This does not match the behavior on other architectures. Instead print the current program counter and if any the involved UEFI binaries. Then reset the system. When testing UEFI binaries like the Self Certification Test exceptions may occur. Without information about the UEFI binary where the exception was caused it is difficult to analyze the cause. The exception command is implemented for the sandbox. This command allows to trigger SIGILL or SIGSEGV. The UEFI exception unit test is implemented for the sandbox. Heinrich Schuchardt (3): sandbox: add handler for exceptions cmd: sandbox: implement exception command efi_selftest: implement exception test for sandbox arch/sandbox/cpu/os.c | 31 ++ arch/sandbox/cpu/start.c | 4 ++ arch/sandbox/lib/interrupts.c | 30 ++ cmd/Kconfig | 2 +- cmd/Makefile | 1 + cmd/sandbox/Makefile | 3 ++ cmd/sandbox/exception.c | 41 +++ include/os.h | 17 .../efi_selftest_miniapp_exception.c | 2 + 9 files changed, 130 insertions(+), 1 deletion(-) create mode 100644 cmd/sandbox/Makefile create mode 100644 cmd/sandbox/exception.c -- 2.28.0
[scan-ad...@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]
Sadly, when we eliminate defects it doesn't say which ones in an email.
-rc2 eliminated one defect and introduced these two new ones.
- Forwarded message from scan-ad...@coverity.com -
Date: Mon, 09 Nov 2020 22:31:55 + (UTC)
From: scan-ad...@coverity.com
To: tom.r...@gmail.com
Subject: New Defects reported by Coverity Scan for Das U-Boot
Hi,
Please find the latest report on new defect(s) introduced to Das U-Boot found
with Coverity Scan.
2 new defect(s) introduced to Das U-Boot found with Coverity Scan.
1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent
build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)
** CID 313047: Control flow issues (DEADCODE)
/drivers/core/lists.c: 106 in bind_drivers_pass()
*** CID 313047: Control flow issues (DEADCODE)
/drivers/core/lists.c: 106 in bind_drivers_pass()
100 dm_warn("No match for driver '%s'\n",
entry->name);
101 if (!result || ret != -ENOENT)
102 result = ret;
103 }
104 }
105
>>> CID 313047: Control flow issues (DEADCODE)
>>> Execution cannot reach the expression "-11" inside this statement:
>>> "return result ? result : (m...".
106 return result ? result : missing_parent ? -EAGAIN : 0;
107 }
108
109 int lists_bind_drivers(struct udevice *parent, bool pre_reloc_only)
110 {
111 int result = 0;
** CID 313046: Uninitialized variables (UNINIT)
/test/dm/test-main.c: 202 in dm_test_main()
*** CID 313046: Uninitialized variables (UNINIT)
/test/dm/test-main.c: 202 in dm_test_main()
196 */
197 if (!(test->flags & UT_TESTF_LIVE_TREE) &&
198 (!runs || dm_test_run_on_flattree(test))) {
199 ut_assertok(dm_do_test(uts, test, false));
200 runs++;
201 }
>>> CID 313046: Uninitialized variables (UNINIT)
>>> Using uninitialized value "found".
202 found++;
203 }
204
205 if (test_name && !found)
206 printf("Test '%s' not found\n", test_name);
207 else
To view the defects in Coverity Scan visit,
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yoA22WlOQ-2By3ieUvdbKmOyw68TMVT4Kip-2BBzfOGWXJ5yIiYplmPF9KAnKIja4Zd7tU-3Da1oJ_EEm8SbLgSDsaDZif-2Bv7ch8WqhKpLoKErHi4nXpwDNTsYOUgTY-2FyPoDZTSHwUzjSdopTJBj3nqeuoH6EmxKw4bdnFoAIzoVhtx0ddbDrK9rK3KXWgv-2Fr91EWwYn-2FbuIxmGoRCC1vVrTIiiS-2BeJSJN-2BAm6wStqFh31o-2B6yfb96-2FExHhDPXc860EDfuC4s6C3e7tpg2RzHHl-2BVIUN9ezOpqfmXzuXw-2FptMXHgCInxfd5Iw-3D
To manage Coverity Scan email notifications for "tom.r...@gmail.com", click
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yped04pjJnmXOsUBtKYNIXxWeIHzDeopm-2BEWQ6S6K-2FtUHv9ZTk8qZbuzkkz9sa-2BJFw4elYDyedRVZOC-2ButxjBZdouVmTGuWB6Aj6G7lm7t25-2Biv1B-2B9082pHzCCex2kqMs-3D62m6_EEm8SbLgSDsaDZif-2Bv7ch8WqhKpLoKErHi4nXpwDNTsYOUgTY-2FyPoDZTSHwUzjSd4GW73bOCxFmNia7zoK3Oa4qB9-2BOuJcFplp02CIL-2B7HRGMgBx-2F2-2FpfhSyRpqj-2FZxPwBQ27l3roadNVk85oAbxGhcAf6bMfXb4BGV6Z7EGpfLe-2BlLR9a0mH6FT79NVGEnUb524AuEBT1KpEATUtbdFb2CgkRtf3b0mTZ7Y4y71adI-3D
- End forwarded message -
--
Tom
signature.asc
Description: PGP signature
[PATCH] env: mmc: Correct partition comparison in mmc_offset_try_partition
The function mmc_offset_try_partition searches MMC partition to save the environment data by name. However, it only compares the first word-size bytes (size of 'const char *'), which may make the function to find unintended partition. Correct the function not to partially compare the partition name with config "u-boot,,mmc-env-partition". Signed-off-by: Hoyeonjiki Kim --- env/mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/env/mmc.c b/env/mmc.c index 4e67180b23..505f7aa2b8 100644 --- a/env/mmc.c +++ b/env/mmc.c @@ -42,7 +42,7 @@ static inline int mmc_offset_try_partition(const char *str, int copy, s64 *val) if (ret < 0) return ret; - if (!strncmp((const char *)info.name, str, sizeof(str))) + if (!strcmp((const char *)info.name, str)) break; } -- 2.25.1
Uboot SERDES configuration for PCIEx4 on mvebu 38x
Hi,
I am trying to create a pcie x4 interface using a standard SERDES map on a
Marvell 38x chip (MV88F6828) in Uboot 2019.01. However lane verification
prevents me from enabling the pcie x4 configuration.
The closest example I can find is this slm1363 board from this file:
https://github.com/u-boot/u-boot/blob/3d4825446e4258192e1f2302d691a8c0c82a0975/arch/arm/mach-mvebu/serdes/a38x/high_speed_topology_spec-38x.c
:
struct serdes_map db_config_slm1363_d[MAX_SERDES_LANES] = {
{PEX0, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X4, 0, 0},
{PEX1, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X4, 0, 0},
{PEX2, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X4, 0, 0},
{PEX3, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X4, 0, 0},
{USB3_HOST0, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
{USB3_HOST1, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0}
}
This is exactly the config I want. However that board was patched out in
this commit
https://github.com/u-boot/u-boot/commit/544acb07ecebc096c9449e675481ba280311fb0b
due to it being an unsupported topology?
If I configure uboot for my board using the example above, I get the
following output:
board SerDes lanes topology details:
| Lane # | Speed | Type |
| 0| 5 | PCIe0 |
| 1| 5 | PCIe1 |
| 2| 5 | PCIe2 |
| 3| 5 | PCIe3 |
| 4| 5 | USB3 HOST0 |
| 5| 5 | USB3 HOST1 |
hws_serdes_topology_verify: Warning: serdes lane 2 is set to type PCIe2.
hws_serdes_topology_verify: Maximum supported lanes are already set to this
type (limit = 4)
hws_update_serdes_phy_selectors: SerDes lane #2 is disabled
hws_serdes_topology_verify: Warning: serdes lane 3 is set to type PCIe3.
hws_serdes_topology_verify: Maximum supported lanes are already set to this
type (limit = 4)
hws_update_serdes_phy_selectors: SerDes lane #3 is disabled
board SerDes lanes topology details:
| Lane # | Speed | Type |
| 0| 5 | PCIe0 |
| 1| 5 | PCIe1 |
| 4| 5 | USB3 HOST0 |
| 5| 5 | USB3 HOST1 |
If I comment out the SERDES lane verification in
arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c, it seems I can
configure the x4 link successfully and recognize the drive that is
connected.
Can anyone shed some light on the proper way to configure the serdes map
for pcie x4?
Thanks!
Tyler
[PATCH 5/5] test: add tests for default environment
Signed-off-by: Rasmus Villemoes
---
configs/sandbox64_defconfig | 1 +
configs/sandbox_defconfig | 1 +
include/configs/sandbox.h | 8 ++-
test/env/Makefile | 1 +
test/env/default.c | 102
5 files changed, 112 insertions(+), 1 deletion(-)
create mode 100644 test/env/default.c
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index dc993cd13a..fa8f5190ed 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -91,6 +91,7 @@ CONFIG_ENV_IS_NOWHERE=y
CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_INTERFACE="host"
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:0"
+CONFIG_ENV_AMEND_DEFAULT_FROM_FDT=y
CONFIG_BOOTP_SEND_HOSTNAME=y
CONFIG_NETCONSOLE=y
CONFIG_IP_DEFRAG=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index f2a767a4cd..f1a4ecbf01 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -105,6 +105,7 @@ CONFIG_ENV_IS_NOWHERE=y
CONFIG_ENV_IS_IN_EXT4=y
CONFIG_ENV_EXT4_INTERFACE="host"
CONFIG_ENV_EXT4_DEVICE_AND_PART="0:0"
+CONFIG_ENV_AMEND_DEFAULT_FROM_FDT=y
CONFIG_BOOTP_SEND_HOSTNAME=y
CONFIG_NETCONSOLE=y
CONFIG_IP_DEFRAG=y
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index e0708fe573..928a80d872 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -106,11 +106,17 @@
"scriptaddr=0x1000\0" \
"pxefile_addr_r=0x2000\0"
+#define TEST_ENV_SETTINGS \
+ "test0=a\0" \
+ "test1=b\0" \
+ "test2=c\0"
+
#define CONFIG_EXTRA_ENV_SETTINGS \
SANDBOX_SERIAL_SETTINGS \
SANDBOX_ETH_SETTINGS \
BOOTENV \
- MEM_LAYOUT_ENV_SETTINGS
+ MEM_LAYOUT_ENV_SETTINGS \
+ TEST_ENV_SETTINGS
#ifndef CONFIG_SPL_BUILD
#define CONFIG_SYS_IDE_MAXBUS 1
diff --git a/test/env/Makefile b/test/env/Makefile
index 5c8eae31b0..740b9c522e 100644
--- a/test/env/Makefile
+++ b/test/env/Makefile
@@ -5,3 +5,4 @@
obj-y += cmd_ut_env.o
obj-y += attr.o
obj-y += hashtable.o
+obj-y += default.o
diff --git a/test/env/default.c b/test/env/default.c
new file mode 100644
index 00..36fae5d783
--- /dev/null
+++ b/test/env/default.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static char *testvars[] = {"test0", "test1", "test2", "test3"};
+
+static int test_amend_default_from_fdt(struct unit_test_state *uts)
+{
+ static const char def_env[] = "test1=x\0test2=\0test3=y";
+ void *blob = (void*)gd->fdt_blob;
+ const char *val;
+
+ ut_assert(fdt_find_or_add_subnode(blob, 0, "config") >= 0);
+ ut_assertok(fdt_find_and_setprop(blob, "/config", "default-environment",
+ def_env, sizeof(def_env), 1));
+
+ env_set("test0", NULL);
+ env_set_default_vars(ARRAY_SIZE(testvars), testvars, 0);
+
+ val = env_get("test0");
+ ut_assertnonnull(val);
+ ut_asserteq_str("a", val);
+
+ val = env_get("test1");
+ ut_assertnonnull(val);
+ ut_asserteq_str("x", val);
+
+ val = env_get("test2");
+ ut_assertnull(val);
+
+ val = env_get("test3");
+ ut_assertnonnull(val);
+ ut_asserteq_str("y", val);
+
+ return 0;
+}
+
+static int env_test_default(struct unit_test_state *uts)
+{
+ const char *val;
+ int ret = 0;
+ void *blob;
+ const void *orig_blob;
+ int blob_sz;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(testvars); ++i) {
+ ut_assertok(env_set(testvars[i], "ggg"));
+ val = env_get(testvars[i]);
+ ut_assertnonnull(val);
+ ut_asserteq_str(val, "ggg");
+ }
+
+ env_set_default_vars(ARRAY_SIZE(testvars), testvars, 0);
+
+ val = env_get("test0");
+ ut_assertnonnull(val);
+ ut_asserteq_str("a", val);
+
+ val = env_get("test1");
+ ut_assertnonnull(val);
+ ut_asserteq_str("b", val);
+
+ val = env_get("test2");
+ ut_assertnonnull(val);
+ ut_asserteq_str("c", val);
+
+ /*
+* env_set_default_vars() leaves existing variables alone that
+* are not defined in the default environment.
+*/
+ val = env_get("test3");
+ ut_assertnonnull(val);
+ ut_asserteq_str("ggg", val);
+
+ if (!IS_ENABLED(CONFIG_ENV_AMEND_DEFAULT_FROM_FDT))
+ return ret;
+
+ blob_sz = fdt_totalsize(gd->fdt_blob) + 256;
+ blob = malloc(blob_sz);
+ ut_assertnonnull(blob);
+
+ /* Make a writable copy of the fdt blob */
+ ut_assertok(fdt_open_into(gd->fdt_blob, blob, blob_sz));
+ orig_blob = gd->fdt_blob;
+ gd->fdt_blob = blob;
+
+ ret = test_amend_default_from_fdt(uts);
+
+ gd->fdt_blob = orig_blob;
+ free(blob);
+
+ return ret;
+}
+ENV_TEST(env_test_default, 0);
--
2.23.0
[PATCH 3/5] env: make env_set_default_vars() return void
Unlike most other functions declared in env.h, the return value of
this one also isn't documented. It only has a single caller, which
ignores the return value. And the companion, env_set_default(),
already has void as return type.
Signed-off-by: Rasmus Villemoes
---
env/common.c | 4 ++--
include/env.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/env/common.c b/env/common.c
index 6c32a9b479..7363da849b 100644
--- a/env/common.c
+++ b/env/common.c
@@ -94,14 +94,14 @@ void env_set_default(const char *s, int flags)
/* [re]set individual variables to their value in the default environment */
-int env_set_default_vars(int nvars, char * const vars[], int flags)
+void env_set_default_vars(int nvars, char * const vars[], int flags)
{
/*
* Special use-case: import from default environment
* (and use \0 as a separator)
*/
flags |= H_NOCLEAR | H_DEFAULT;
- return himport_r(_htab, (const char *)default_environment,
+ himport_r(_htab, (const char *)default_environment,
sizeof(default_environment), '\0',
flags, 0, nvars, vars);
}
diff --git a/include/env.h b/include/env.h
index c15339a93f..5bff6c4d72 100644
--- a/include/env.h
+++ b/include/env.h
@@ -256,7 +256,7 @@ void env_fix_drivers(void);
* @vars: List of variables to set/reset
* @flags: Flags controlling matching (H_... - see search.h)
*/
-int env_set_default_vars(int nvars, char *const vars[], int flags);
+void env_set_default_vars(int nvars, char *const vars[], int flags);
/**
* env_load() - Load the environment from storage
--
2.23.0
[PATCH 2/5] fdtdec: introduce fdtdec_get_config_property
Add a wrapper for retrieving a given property from the /config node as
a (blob, length) pair. A later patch will need the length of the
property and thus cannot just use fdtdec_get_config_string(). Rewrite
that to use the new wrapper.
Signed-off-by: Rasmus Villemoes
---
include/fdtdec.h | 14 ++
lib/fdtdec.c | 27 +--
2 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index a037f6ed9c..ff1453a100 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -747,6 +747,20 @@ int fdtdec_get_bool(const void *blob, int node, const char
*prop_name);
*/
int fdtdec_get_child_count(const void *blob, int node);
+/**
+ * Look in the FDT for a config item with the given name and a pointer
+ * to its value.
+ *
+ * @param blob FDT blob
+ * @param prop_name property name to look up
+ * @param lenp if non-NULL and the property is found, *lenp is
+ * set to the length of the property value
+ *
+ * @returns property value, NULL on error.
+ */
+const void *fdtdec_get_config_property(const void *blob, const char *prop_name,
+ int *lenp);
+
/**
* Look in the FDT for a config item with the given name and return its value
* as a 32-bit integer. The property must have at least 4 bytes of data. The
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 25a71bc8f9..2442470af8 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -853,6 +853,18 @@ const u8 *fdtdec_locate_byte_array(const void *blob, int
node,
return cell;
}
+const void *fdtdec_get_config_property(const void *blob, const char *prop_name,
+ int *len)
+{
+ int config_node;
+
+ debug("%s: %s\n", __func__, prop_name);
+ config_node = fdt_path_offset(blob, "/config");
+ if (config_node < 0)
+ return NULL;
+ return fdt_getprop(blob, config_node, prop_name, len);
+}
+
int fdtdec_get_config_int(const void *blob, const char *prop_name,
int default_val)
{
@@ -881,20 +893,7 @@ int fdtdec_get_config_bool(const void *blob, const char
*prop_name)
const char *fdtdec_get_config_string(const void *blob, const char *prop_name)
{
- const char *nodep;
- int nodeoffset;
- int len;
-
- debug("%s: %s\n", __func__, prop_name);
- nodeoffset = fdt_path_offset(blob, "/config");
- if (nodeoffset < 0)
- return NULL;
-
- nodep = fdt_getprop(blob, nodeoffset, prop_name, );
- if (!nodep)
- return NULL;
-
- return nodep;
+ return fdtdec_get_config_property(blob, prop_name, NULL);
}
u64 fdtdec_get_number(const fdt32_t *ptr, unsigned int cells)
--
2.23.0
[PATCH 4/5] env: allow default environment to be amended from control dtb
It can be useful to use the same U-Boot binary for multiple purposes,
say the normal one, one for developers that allow breaking into the
U-Boot shell, and one for use during bootstrapping which runs a
special-purpose bootcmd. To that end, allow the control dtb to contain
a /config/default-enviroment property, whose value will be used to
amend the default environment baked into the U-Boot binary itself.
Signed-off-by: Rasmus Villemoes
---
cmd/nvedit.c | 37 +
env/Kconfig | 21 +
env/common.c | 19 +++
3 files changed, 77 insertions(+)
diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 7fce723800..eda8b3b9d2 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -703,6 +703,39 @@ char *from_env(const char *envvar)
return ret;
}
+static int env_get_f_fdt(const char *name, char *buf, unsigned len)
+{
+ const char *env;
+ int plen, nlen, n;
+
+ if (!IS_ENABLED(CONFIG_ENV_AMEND_DEFAULT_FROM_FDT))
+ return 0;
+
+ env = fdtdec_get_config_property(gd->fdt_blob, "default-environment",
+);
+ if (!env)
+ return 0;
+
+ nlen = strlen(name);
+ while (plen > nlen) {
+ if (memcmp(name, env, nlen) == 0 && env[nlen] == '=') {
+ /* Found. Copy value. */
+ n = strlcpy(buf, [nlen + 1], len);
+ if (n < len)
+ return n;
+
+ printf("env_buf [%u bytes] too small for value of
\"%s\"\n",
+ len, name);
+ return len;
+ }
+ /* Skip this key=val pair. */
+ n = strlen(env) + 1;
+ plen -= n;
+ env += n;
+ }
+ return 0;
+}
+
/*
* Look up variable from environment for restricted C runtime env.
*/
@@ -710,6 +743,10 @@ int env_get_f(const char *name, char *buf, unsigned len)
{
int i, nxt, c;
+ i = env_get_f_fdt(name, buf, len);
+ if (i)
+ return i;
+
for (i = 0; env_get_char(i) != '\0'; i = nxt + 1) {
int val, n;
diff --git a/env/Kconfig b/env/Kconfig
index 67ce93061b..66bbac42c7 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -646,6 +646,27 @@ config DELAY_ENVIRONMENT
later by U-Boot code. With CONFIG_OF_CONTROL this is instead
controlled by the value of /config/load-environment.
+config ENV_AMEND_DEFAULT_FROM_FDT
+ bool "Amend default environment by /config/default-environment property"
+ depends on OF_CONTROL
+ help
+ The default environment built into the U-Boot binary is a
+ static array defined from various CONFIG_ options, or via
+ CONFIG_DEFAULT_ENV_FILE. Selecting this option means that
+ whenever that default environment is used (either for
+ populating the initial environment, or for resetting
+ specific variables to their default value), the device tree
+ property /config/default-environment is also consulted, and
+ values found there have precedence over those in the static
+ array. That property should be a series of "key=value"
+ pairs, e.g.
+
+ /config {
+ default-environment = "ipaddr=1.2.3.4",
+ "bootcmd=tftp $loadaddr foo.itb; bootm
$loadaddr",
+ "bootdelay=5";
+ }
+
config ENV_APPEND
bool "Always append the environment with new data"
default n
diff --git a/env/common.c b/env/common.c
index 7363da849b..8d0e45fde6 100644
--- a/env/common.c
+++ b/env/common.c
@@ -63,6 +63,22 @@ char *env_get_default(const char *name)
return ret_val;
}
+static void env_amend_default_from_fdt(int flags, int nvars, char *const
vars[])
+{
+ const void *val;
+ int len;
+
+ if (!IS_ENABLED(CONFIG_ENV_AMEND_DEFAULT_FROM_FDT))
+ return;
+
+ val = fdtdec_get_config_property(gd->fdt_blob, "default-environment",
+);
+ if (!val)
+ return;
+
+ himport_r(_htab, val, len, '\0', flags, 0, nvars, vars);
+}
+
void env_set_default(const char *s, int flags)
{
if (sizeof(default_environment) > ENV_SIZE) {
@@ -88,6 +104,8 @@ void env_set_default(const char *s, int flags)
pr_err("## Error: Environment import failed: errno = %d\n",
errno);
+ env_amend_default_from_fdt(flags | H_NOCLEAR, 0, NULL);
+
gd->flags |= GD_FLG_ENV_READY;
gd->flags |= GD_FLG_ENV_DEFAULT;
}
@@ -104,6 +122,7 @@ void env_set_default_vars(int nvars, char * const vars[],
int flags)
himport_r(_htab, (const char *)default_environment,
sizeof(default_environment), '\0',
flags, 0, nvars, vars);
+
[PATCH 0/5] allow default environment to be amended from dtb
These patches introduce the ability to amend the default environment baked into the U-Boot binary by a DT property under /config. This is useful to create a few different images based on the same U-Boot binary, e.g. one for normal use, one for development and one for bootstrapping the board. It's also useful when SPL loads U-Boot from a FIT image and decides between multiple possible control DTBs; those control DTBs can then contain tweaks of the default environment suitable for that particular board variant. There are already various /config/ properties one can use for some of this; e.g. /config/bootdelay overrides any bootdelay set in the environment. This is intended as a flexible way to achieve these kinds of tweaks instead of adding more /config/* properties. [It should be noted that adding "bootdelay=123" to /config/default-environment is not a drop-in replacement for setting /config/bootdelay to 123, as the latter takes effect whether the environment is the default one or one loaded from storage.] It does not affect the case where an environment is loaded from a storage device, nor is there any change if the new CONFIG_ option is not selected. Rasmus Villemoes (5): fdtdec: make fdtdec_get_config_string() return const char* fdtdec: introduce fdtdec_get_config_property env: make env_set_default_vars() return void env: allow default environment to be amended from control dtb test: add tests for default environment arch/arm/mach-exynos/include/mach/mipi_dsim.h | 2 +- arch/arm/mach-rockchip/rk3188/rk3188.c| 2 +- board/dhelectronics/dh_stm32mp1/board.c | 2 +- board/firefly/firefly-rk3288/firefly-rk3288.c | 2 +- board/st/stm32mp1/stm32mp1.c | 2 +- cmd/nvedit.c | 37 +++ common/cli.c | 2 +- configs/sandbox64_defconfig | 1 + configs/sandbox_defconfig | 1 + env/Kconfig | 21 env/common.c | 23 +++- include/configs/sandbox.h | 8 +- include/env.h | 2 +- include/fdtdec.h | 16 ++- lib/fdtdec.c | 29 +++-- test/env/Makefile | 1 + test/env/default.c| 102 ++ 17 files changed, 227 insertions(+), 26 deletions(-) create mode 100644 test/env/default.c -- 2.23.0
[PATCH 1/5] fdtdec: make fdtdec_get_config_string() return const char*
Nobody should modify the string returned by
fdtdec_get_config_string(), so make it return a const pointer.
Signed-off-by: Rasmus Villemoes
---
arch/arm/mach-exynos/include/mach/mipi_dsim.h | 2 +-
arch/arm/mach-rockchip/rk3188/rk3188.c| 2 +-
board/dhelectronics/dh_stm32mp1/board.c | 2 +-
board/firefly/firefly-rk3288/firefly-rk3288.c | 2 +-
board/st/stm32mp1/stm32mp1.c | 2 +-
common/cli.c | 2 +-
include/fdtdec.h | 2 +-
lib/fdtdec.c | 4 ++--
8 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/mipi_dsim.h
b/arch/arm/mach-exynos/include/mach/mipi_dsim.h
index 20e6ce7f72..1cdea29b78 100644
--- a/arch/arm/mach-exynos/include/mach/mipi_dsim.h
+++ b/arch/arm/mach-exynos/include/mach/mipi_dsim.h
@@ -313,7 +313,7 @@ struct mipi_dsim_master_ops {
* @platform_data: lcd panel specific platform data.
*/
struct mipi_dsim_lcd_device {
- char*name;
+ const char *name;
int id;
int bus_id;
int reverse_panel;
diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c
b/arch/arm/mach-rockchip/rk3188/rk3188.c
index 222953ab94..1f0adac62a 100644
--- a/arch/arm/mach-rockchip/rk3188/rk3188.c
+++ b/arch/arm/mach-rockchip/rk3188/rk3188.c
@@ -111,7 +111,7 @@ static int setup_led(void)
{
#ifdef CONFIG_SPL_LED
struct udevice *dev;
- char *led_name;
+ const char *led_name;
int ret;
led_name = fdtdec_get_config_string(gd->fdt_blob, "u-boot,boot-led");
diff --git a/board/dhelectronics/dh_stm32mp1/board.c
b/board/dhelectronics/dh_stm32mp1/board.c
index f42d395098..c59bf26223 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -372,7 +372,7 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev,
const char *name)
#ifdef CONFIG_LED
static int get_led(struct udevice **dev, char *led_string)
{
- char *led_name;
+ const char *led_name;
int ret;
led_name = fdtdec_get_config_string(gd->fdt_blob, led_string);
diff --git a/board/firefly/firefly-rk3288/firefly-rk3288.c
b/board/firefly/firefly-rk3288/firefly-rk3288.c
index bd8a32cf7b..a2bef1c928 100644
--- a/board/firefly/firefly-rk3288/firefly-rk3288.c
+++ b/board/firefly/firefly-rk3288/firefly-rk3288.c
@@ -14,7 +14,7 @@ static int setup_led(void)
{
#ifdef CONFIG_SPL_LED
struct udevice *dev;
- char *led_name;
+ const char *led_name;
int ret;
led_name = fdtdec_get_config_string(gd->fdt_blob, "u-boot,boot-led");
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 03a19af930..82798773f5 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -226,7 +226,7 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev,
const char *name)
static int get_led(struct udevice **dev, char *led_string)
{
- char *led_name;
+ const char *led_name;
int ret;
led_name = fdtdec_get_config_string(gd->fdt_blob, led_string);
diff --git a/common/cli.c b/common/cli.c
index 6635ab2bcf..f0e8f2880c 100644
--- a/common/cli.c
+++ b/common/cli.c
@@ -156,7 +156,7 @@ int do_run(struct cmd_tbl *cmdtp, int flag, int argc, char
*const argv[])
bool cli_process_fdt(const char **cmdp)
{
/* Allow the fdt to override the boot command */
- char *env = fdtdec_get_config_string(gd->fdt_blob, "bootcmd");
+ const char *env = fdtdec_get_config_string(gd->fdt_blob, "bootcmd");
if (env)
*cmdp = env;
/*
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 62d1660973..a037f6ed9c 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -778,7 +778,7 @@ int fdtdec_get_config_bool(const void *blob, const char
*prop_name);
* @param prop_name property name to look up
* @returns property string, NULL on error.
*/
-char *fdtdec_get_config_string(const void *blob, const char *prop_name);
+const char *fdtdec_get_config_string(const void *blob, const char *prop_name);
/*
* Look up a property in a node and return its contents in a byte
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index ee1bd41b08..25a71bc8f9 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -879,7 +879,7 @@ int fdtdec_get_config_bool(const void *blob, const char
*prop_name)
return prop != NULL;
}
-char *fdtdec_get_config_string(const void *blob, const char *prop_name)
+const char *fdtdec_get_config_string(const void *blob, const char *prop_name)
{
const char *nodep;
int nodeoffset;
@@ -894,7 +894,7 @@ char *fdtdec_get_config_string(const void *blob, const char
*prop_name)
if (!nodep)
return NULL;
- return (char *)nodep;
+ return nodep;
}
u64 fdtdec_get_number(const fdt32_t *ptr, unsigned int cells)
--
Re: [PATCH 1/2 v3] tpm: Add some headers from the spec
On 11/10/20 8:49 AM, Ilias Apalodimas wrote:
> A following patch introduces EFI_TCG2_PROTOCOL.
> Add the required TPMv2 headers to support it.
>
> Signed-off-by: Ilias Apalodimas
> ---
> changes since v2:
> - Added description and pointers to TCG specs
> - updated copyright info
> include/tpm-v2.h | 77
> 1 file changed, 77 insertions(+)
>
> diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> index f6c045d35480..c75cd5d8dfe8 100644
> --- a/include/tpm-v2.h
> +++ b/include/tpm-v2.h
> @@ -1,6 +1,13 @@
> /* SPDX-License-Identifier: GPL-2.0+ */
> /*
> + * Defines APIs and structures that allow software to interact with a
> + * TPM2 device
> + *
> + * Copyright (c) 2020 Linaro
> * Copyright (c) 2018 Bootlin
> + *
> + *
> https://trustedcomputinggroup.org/resource/tss-overview-common-structures-specification/
> + *
> * Author: Miquel Raynal
> */
>
> @@ -11,6 +18,74 @@
>
> #define TPM2_DIGEST_LEN 32
>
> +#define TPM2_MAX_PCRS 32
> +#define TPM2_PCR_SELECT_MAX ((TPM2_MAX_PCRS + 7) / 8)
> +#define TPM2_MAX_CAP_BUFFER 1024
> +#define TPM2_MAX_TPM_PROPERTIES ((TPM2_MAX_CAP_BUFFER - sizeof(u32) /*
> TPM2_CAP */ - \
> + sizeof(u32)) / sizeof(struct
> tpms_tagged_property))
> +
> +/*
> + * We deviate from this draft of the specification by increasing the value
> of
> + * TPM2_NUM_PCR_BANKS from 3 to 16 to ensure compatibility with TPM2
> + * implementations that have enabled a larger than typical number of PCR
> + * banks. This larger value for TPM2_NUM_PCR_BANKS is expected to be
> included
> + * in a future revision of the specification.
> + */
> +#define TPM2_NUM_PCR_BANKS 16
> +
> +/* Definition of (UINT32) TPM2_CAP Constants */
> +#define TPM2_CAP_PCRS 0x0005U
> +#define TPM2_CAP_TPM_PROPERTIES 0x0006U
> +
> +/* Definition of (UINT32) TPM2_PT Constants */
> +#define PT_GROUP (u32)(0x0100)
TPM2_PT_GROUP
Please, be consistent in using the TPM2 prefix.
> +#define PT_FIXED (u32)(PT_GROUP * 1)
TPM2_PT_FIXED
Otherwise
Reviewed-by: Heinrich Schuchardt
> +#define TPM2_PT_MANUFACTURER(u32)(PT_FIXED + 5)
> +#define TPM2_PT_PCR_COUNT (u32)(PT_FIXED + 18)
> +#define TPM2_PT_MAX_COMMAND_SIZE(u32)(PT_FIXED + 30)
> +#define TPM2_PT_MAX_RESPONSE_SIZE (u32)(PT_FIXED + 31)
> +
> +/* TPMS_TAGGED_PROPERTY Structure */
> +struct tpms_tagged_property {
> + u32 property;
> + u32 value;
> +} __packed;
> +
> +/* TPMS_PCR_SELECTION Structure */
> +struct tpms_pcr_selection {
> + u16 hash;
> + u8 size_of_select;
> + u8 pcr_select[TPM2_PCR_SELECT_MAX];
> +} __packed;
> +
> +/* TPML_PCR_SELECTION Structure */
> +struct tpml_pcr_selection {
> + u32 count;
> + struct tpms_pcr_selection selection[TPM2_NUM_PCR_BANKS];
> +} __packed;
> +
> +/* TPML_TAGGED_TPM_PROPERTY Structure */
> +struct tpml_tagged_tpm_property {
> + u32 count;
> + struct tpms_tagged_property tpm_property[TPM2_MAX_TPM_PROPERTIES];
> +} __packed;
> +
> +/* TPMU_CAPABILITIES Union */
> +union tpmu_capabilities {
> + /*
> + * Non exhaustive. Only added the structs needed for our
> + * current code
> + */
> + struct tpml_pcr_selection assigned_pcr;
> + struct tpml_tagged_tpm_property tpm_properties;
> +} __packed;
> +
> +/* TPMS_CAPABILITY_DATA Structure */
> +struct tpms_capability_data {
> + u32 capability;
> + union tpmu_capabilities data;
> +} __packed;
> +
> /**
> * TPM2 Structure Tags for command/response buffers.
> *
> @@ -123,11 +198,13 @@ enum tpm2_return_codes {
> * TPM2 algorithms.
> */
> enum tpm2_algorithms {
> + TPM2_ALG_SHA1 = 0x04,
> TPM2_ALG_XOR= 0x0A,
> TPM2_ALG_SHA256 = 0x0B,
> TPM2_ALG_SHA384 = 0x0C,
> TPM2_ALG_SHA512 = 0x0D,
> TPM2_ALG_NULL = 0x10,
> + TPM2_ALG_SM3_256= 0x12,
> };
>
> /* NV index attributes */
>
Re: [rockchip] broken SPI on RockPro64 and other RK3399 targets
Alper Nebi Yasak writes:
> Something else you can test:
> - Remove the aliases block from rk3399-rockpro64-u-boot.dtsi
> - Add "spi[0-5] = [0-5];" aliases to rk3399-u-boot.dtsi
> - Add CONFIG_SF_DEFAULT_BUS=1 to configs/rockpro64-rk3399_defconfig
This fixed for me the same issue on my Pinebook Pro, turning
Loading Environment from SPIFlash... Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environment
into
Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 256
Bytes, erase size 4 KiB, total 16 MiB
Patch attached, for clarity.
>From bda546ffdc5b0a25ee554d75f963d1c0570f3f7e Mon Sep 17 00:00:00 2001
From: Simon South
Date: Tue, 10 Nov 2020 12:49:27 -0500
Subject: [PATCH] rockchip: Pinebook Pro: Fix SPI flash
As per a suggestion by Alper Nebi Yasak.
---
arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 4
arch/arm/dts/rk3399-u-boot.dtsi | 5 +
configs/pinebook-pro-rk3399_defconfig| 1 +
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
index 76fc8c3825..1318e03b9a 100644
--- a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
@@ -7,10 +7,6 @@
#include "rk3399-sdram-lpddr4-100.dtsi"
/ {
- aliases {
- spi0 =
- };
-
chosen {
u-boot,spl-boot-order = "same-as-spl", , ,
};
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index ecd230c720..09916d633b 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -11,7 +11,12 @@
mmc0 =
mmc1 =
pci0 =
+ spi0 =
spi1 =
+ spi2 =
+ spi3 =
+ spi4 =
+ spi5 =
};
cic: syscon@ff62 {
diff --git a/configs/pinebook-pro-rk3399_defconfig b/configs/pinebook-pro-rk3399_defconfig
index 95a04bc0fb..865bfc72b1 100644
--- a/configs/pinebook-pro-rk3399_defconfig
+++ b/configs/pinebook-pro-rk3399_defconfig
@@ -45,6 +45,7 @@ CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_SF_DEFAULT_BUS=1
CONFIG_SF_DEFAULT_SPEED=2000
CONFIG_SPI_FLASH_GIGADEVICE=y
CONFIG_SPI_FLASH_WINBOND=y
--
2.29.2
--
Simon South
si...@simonsouth.net
Re: [PATCH] rockchip: Move Bob specific bits to it's specific u-boot.dtsi
Hi,
> On 10 Nov 2020, at 07:34, Kever Yang wrote:
>
> Hi Peter,
>
> On 2020/11/9 上午7:02, Peter Robinson wrote:
>> Move the bits that are device specific to the -u-boot.dtsi as the
>> bits may be different on other devices and hence breaks SPI on
>> those devices such as the Pinebook Pro.
>>
>> Signed-off-by: Peter Robinson
>> Fixes: c4cea2bbf995 ("rockchip: Enable building a SPI ROM image on bob")
>> Cc: Simon Glass
>> ---
>> arch/arm/dts/rk3399-gru-u-boot.dtsi | 30 +
>> arch/arm/dts/rk3399-u-boot.dtsi | 25
>> 2 files changed, 30 insertions(+), 25 deletions(-)
>>
>> diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi
>> b/arch/arm/dts/rk3399-gru-u-boot.dtsi
>> index 390ac2bb5a..5e95cacfea 100644
>> --- a/arch/arm/dts/rk3399-gru-u-boot.dtsi
>> +++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi
>> @@ -5,6 +5,36 @@
>>#include "rk3399-u-boot.dtsi"
>> +/ {
>> +aliases {
>> +spi1 =
>> +};
>> +};
>
> Does this still need to remove from common code after your another patch
> applied? It look reasonable and
>
> not likely to break others.
>
> https://patchwork.ozlabs.org/project/uboot/patch/20201108140023.32501-1-sigma...@gmail.com/
My patch linked above was aiming to fix SPI boot on the rockpro64 by
adapting to the spi1 alias that's now in the rk3399-u-boot.dtsi rather
than removing it (in fact, my patch wouldn't work correctly if the spi1
alias was removed). This seemed like one good solution as the RK3399 does
physically have SPI buses 0 to 5, and out of those the SPI flash is on
bus 1, so I thought it'd be better to refer to it as bus 1 instead of
aliasing it to bus 0.
I see now, though, that it's not just the rockpro64 that's affected, but
also Pinebook Pro and it seems rk3399-roc-pc. If the consensus is that
my patch is the right approach, I can send another series with the same
type of fix for the PBP and rk3399-roc-pc. Otherwise this patch should
be used and my patch shouldn't be applied as it relies on the spi1 alias
that this patch removes.
Regards,
Hugh
>
>> +
>> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
>> + {
>> +rom {
>> +filename = "u-boot.rom";
>> +size = <0x40>;
>> +pad-byte = <0xff>;
>> +
>> +mkimage {
>> +args = "-n rk3399 -T rkspi";
>> +u-boot-spl {
>> +};
>> +};
>> +u-boot-img {
>> +offset = <0x4>;
>> +};
>> +u-boot {
>> +offset = <0x30>;
>> +};
>> +fdtmap {
>> +};
>> +};
>> +};
>> +#endif
>
>
> What's the image space mapping for Pinebook Pro do you using?
>
> I think there should be another binman config if this is not common .
>
>
> Thanks,
>
> - Kever
>
>> +
>> _flash {
>> u-boot,dm-pre-reloc;
>> };
>> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi
>> b/arch/arm/dts/rk3399-u-boot.dtsi
>> index ecd230c720..26b0a34e64 100644
>> --- a/arch/arm/dts/rk3399-u-boot.dtsi
>> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
>> @@ -11,7 +11,6 @@
>> mmc0 =
>> mmc1 =
>> pci0 =
>> -spi1 =
>> };
>> cic: syscon@ff62 {
>> @@ -60,30 +59,6 @@
>>};
>> -#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
>> - {
>> -rom {
>> -filename = "u-boot.rom";
>> -size = <0x40>;
>> -pad-byte = <0xff>;
>> -
>> -mkimage {
>> -args = "-n rk3399 -T rkspi";
>> -u-boot-spl {
>> -};
>> -};
>> -u-boot-img {
>> -offset = <0x4>;
>> -};
>> -u-boot {
>> -offset = <0x30>;
>> -};
>> -fdtmap {
>> -};
>> -};
>> -};
>> -#endif
>> -
>> {
>> u-boot,dm-pre-reloc;
>> };
Re: [PATCH] sandbox: cros_ec: Basic support for EC_CMD_GET_NEXT_EVENT
On 10.11.20 15:00, Alper Nebi Yasak wrote:
> Since commit 690079767803 ("cros_ec: Support keyboard scanning with
> EC_CMD_GET_NEXT_EVENT") the cros-ec-keyb driver has started using this
> command, but the sandbox EC emulator does not recognize it and
> continuously prints:
>
> ** Unknown EC command 0x67
>
> This patch makes the sandbox driver send basic responses to the command,
> but the response only supports keyboard scans for now.
>
> Fixes: 690079767803 ("cros_ec: Support keyboard scanning with
> EC_CMD_GET_NEXT_EVENT")
> Reported-by: Heinrich Schuchardt
> Signed-off-by: Alper Nebi Yasak
> ---
> This doesn't test the -EC_RES_UNAVAILABLE part, which looks like an
> event queue on the EC side. As far as I understand sandbox is getting a
> single keyboard state from SDL after discarding pending events. I think
> things would need to be hooked into sandbox_sdl_poll_events, looks
> possible but harder.
>
> Also, now that this command would work, the fallback to the old one
> would never trigger and wouldn't be tested.
Should some of the comment above be merged into the commit message?
Tested-by: Heinrich Schuchardt
>
> drivers/misc/cros_ec_sandbox.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/misc/cros_ec_sandbox.c b/drivers/misc/cros_ec_sandbox.c
> index a191f061b898..d72db3eace98 100644
> --- a/drivers/misc/cros_ec_sandbox.c
> +++ b/drivers/misc/cros_ec_sandbox.c
> @@ -460,6 +460,14 @@ static int process_cmd(struct ec_state *ec,
> case EC_CMD_ENTERING_MODE:
> len = 0;
> break;
> + case EC_CMD_GET_NEXT_EVENT: {
> + struct ec_response_get_next_event *resp = resp_data;
> +
> + resp->event_type = EC_MKBP_EVENT_KEY_MATRIX;
> + cros_ec_keyscan(ec, resp->data.key_matrix);
> + len = sizeof(*resp);
> + break;
> + }
> default:
> printf(" ** Unknown EC command %#02x\n", req_hdr->command);
> return -1;
>
Re: RPi3: serial console
On 2020-11-04 15:05, Stefan Agner wrote: > On 2020-10-16 03:28, Ricardo Salveti wrote: >> On Tue, Oct 13, 2020 at 11:04 AM Peter Robinson wrote: >>> >>> > >> Hello Matthias, >>> > >> >>> > >> I have upgraded the Raspberry 3 firmware from raspi3-firmware >>> > >> (1.20190215-1+deb10u4) to raspi-firmware (1.20200601-3) >>> > >> [https://packages.debian.org/bullseye/raspi-firmware]. >>> > >> >>> > >> After the upgrade the output of U-Boot on the serial console is >>> > >> complete >>> > >> gibberish as if the baudrate were incorrect. The output from the Linux >>> > >> kernel is fine at 115200 baud. >>> > > >>> > > I've seen similar on all firmware since around mid April up until >>> > > recently, it seems to be fixed with releases in Oct (I'm using one >>> > > from Oct 8th), I'm not sure if it can be fixed in U-Boot but it seems >>> > > to be due to a change in the firmware. >>> > >>> > Thanks for confirming the problem. >>> >>> For reference I have found a number of other problems with recent >>> firmwares and 2020.10 release: >>> * U-Boot crashes on a RPi4 8Gb model if you don't have a display connected >>> [1] >>> * It doesn't boot, not sure if it's a crash or something else, you >>> just get the rainbow screen, if you don't have the uart enabled in >>> config.txt (ie just using a display for output). >> >> Noticed the same as well here (boots fine only with enable_uart=1). >> While playing over with the files I noticed it works fine with the >> latest firmware when using an older bcm2710-rpi-3-b-plus.dtb >> (placed together with the firmware). If I use the latest >> bcm2710-rpi-3-b-plus.dtb from the 5.4 downstream kernel, it doesn't >> work (only tested on rpi3-b-plus). >> >> This is with CONFIG_OF_BOARD=y, if I use CONFIG_OF_EMBED instead it >> works just fine (which gives me the impression that u-boot might not >> be happy with the dtb generated by the firmware when enable_uart is >> not set). > > What we noticed is adding brcm,bcm2835-pl011 compatible to the UARTs > makes U-Boot 2020.10 boot even *without* enable_uart=1. dm shows that > with this change CONFIG_BCM283X_PL011_SERIAL is in use... > > From what I understand, this driver checks if the UART is muxed, and if > not bails out. So I guess without that compatible string, when the > regular PL011 driver is used, it seems that U-Boot tries to initialize > UART and fails? I looked a bit more into this and I think I made some progress. This is with downstream Linux 5.4, but I don't think it is relevant as downstream uses now the same UART bindings as upstream. It seems when U-Boot is falling back to the Bluetooth (mini) UART and crashes when using it as serial console. I noticed when setting "enable_uart=0" and "dtoverlay=disable-bt" U-Boot does show a serial console on the GPIO pins 14/15. The console is running on UART0, the first PL011 UART: serial0 [ + ] serial_pl01x | |-- serial@7e201000 Another method which works using "dtparam=uart0=off" and "enable_uart=0", which essentially disables UART0 and UART1 in device tree. U-Boot won't show a serial console, but the system boots... I think the reason why adding "brcm,bcm2835-pl011" to compatible works is because it makes probing of uart0 (the PL011 UART) in U-Boot fail, and hence U-Boot won't fallback to this UARTs. Note that "enable_uart=0" is equal to *not* setting enable_uart at all according to documentation and confirmed in the discussion at https://github.com/raspberrypi/firmware/issues/1483 (on RPi 3/4 anyways). What I also noticed that uart2 makes trouble (which is also PL011 in RPi4): "dtparam=uart0=off", "enable_uart=0" and "dtoverlay=uart2" make sure that only uart2 is available to U-Boot. It makes the system crash well... Disabling CONFIG_PL01X_SERIAL (which is only possible with a Kconfig change in arch/arm/Kconfig) makes the system boot in all cases... -- Stefan
Re: [ANN] U-Boot v2021.01-rc2 released
On Tue, Nov 10, 2020 at 2:35 PM Tom Rini wrote: > On Tue, Nov 10, 2020 at 01:18:41PM +0100, Heinrich Schuchardt wrote: > > On 11/10/20 1:16 PM, Tom Rini wrote: > > > On Tue, Nov 10, 2020 at 01:00:06PM +0100, Heinrich Schuchardt wrote: > > > > On 11/10/20 11:41 AM, Andy Shevchenko wrote: > > > > > On Tue, Nov 10, 2020 at 12:40 PM Andy Shevchenko > > > > > wrote: > > > > > > On Tue, Nov 10, 2020 at 12:22 AM Tom Rini > > > > > > wrote: ... > > > > > > fdt.c is full of > > > > > > > > > > Correction: all of fdt*.c are full of this kind of compiler warnings > > > > > > > > > > > scripts/dtc/libfdt/fdt.c: In function ‘fdt_offset_ptr’: > > > > > > scripts/dtc/libfdt/fdt.c:137:18: warning: comparison of integer > > > > > > expressions of different signedness: ‘unsigned int’ and ‘int’ > > > > > > [-Wsign-compare] > > > > > >137 | if ((absoffset < offset) > > > > > >| ^ > > > > > > > > > > > > Is it known? Is a fix available? > > > > > > With what compiler version? > > > > GCC 10.2 > > Fun. Is that the only problem we see with GCC 10.2? I'm tempted to say > post v2021.01 is when we move to 10.2 being default, assuming the > kernel.org toolchains get upgraded by then. For now I guess I need to > grab > https://patchwork.ozlabs.org/project/uboot/patch/20201016144250.29106-1-andre.przyw...@arm.com/ > rather than do a full re-sync. Sounds like a good plan to me. Thanks! -- With Best Regards, Andy Shevchenko
[PATCH v3 6/7] riscv: Add Microchip MPFS Icicle Kit support
This patch adds Microchip MPFS Icicle Kit support. For now, only
NS16550 Serial, Microchip clock, Cadence eMMC and MACB drivers are
only enabled. The Microchip MPFS Icicle defconfig by default builds
U-Boot for S-Mode because U-Boot on Microchip PolarFire SoC will run
in S-Mode as payload of HSS + OpenSBI.
Signed-off-by: Padmarao Begari
Reviewed-by: Anup Patel
---
board/microchip/mpfs_icicle/Kconfig | 24 ++
board/microchip/mpfs_icicle/mpfs_icicle.c | 97 ++-
configs/microchip_mpfs_icicle_defconfig | 9 ++-
include/configs/microchip_mpfs_icicle.h | 60 +-
4 files changed, 145 insertions(+), 45 deletions(-)
diff --git a/board/microchip/mpfs_icicle/Kconfig
b/board/microchip/mpfs_icicle/Kconfig
index bf8e1a13ec..f4e705a07b 100644
--- a/board/microchip/mpfs_icicle/Kconfig
+++ b/board/microchip/mpfs_icicle/Kconfig
@@ -20,7 +20,31 @@ config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
select GENERIC_RISCV
select BOARD_EARLY_INIT_F
+ select BOARD_LATE_INIT
imply SMP
+ imply CLK_CCF
+ imply CLK_MPFS
imply SYS_NS16550
+ imply CMD_DHCP
+ imply CMD_EXT2
+ imply CMD_EXT4
+ imply CMD_FAT
+ imply CMD_FS_GENERIC
+ imply CMD_NET
+ imply CMD_PING
+ imply CMD_MMC
+ imply DOS_PARTITION
+ imply EFI_PARTITION
+ imply IP_DYN
+ imply ISO_PARTITION
+ imply MACB
+ imply MII
+ imply NET_RANDOM_ETHADDR
+ imply PHY_LIB
+ imply PHY_VITESSE
+ imply MMC
+ imply MMC_WRITE
+ imply MMC_SDHCI
+ imply MMC_SDHCI_CADENCE
endif
diff --git a/board/microchip/mpfs_icicle/mpfs_icicle.c
b/board/microchip/mpfs_icicle/mpfs_icicle.c
index 8381361ec3..420ea25ac2 100644
--- a/board/microchip/mpfs_icicle/mpfs_icicle.c
+++ b/board/microchip/mpfs_icicle/mpfs_icicle.c
@@ -6,10 +6,47 @@
#include
#include
+#include
#include
#include
-#define MPFS_SYSREG_SOFT_RESET ((unsigned int *)0x20002088)
+#define MPFS_SYSREG_SOFT_RESET ((unsigned int *)0x20002088)
+#define MPFS_SYS_SERVICE_CR((unsigned int *)0x37020050)
+#define MPFS_SYS_SERVICE_SR((unsigned int *)0x37020054)
+#define MPFS_SYS_SERVICE_MAILBOX ((unsigned char *)0x37020800)
+
+#define PERIPH_RESET_VALUE 0x1e8u
+#define SERVICE_CR_REQ 0x1u
+#define SERVICE_SR_BUSY0x2u
+
+static void read_device_serial_number(u8 *response, u8 response_size)
+{
+ u8 idx;
+ u8 *response_buf;
+ unsigned int val;
+
+ response_buf = (u8 *)response;
+
+ writel(SERVICE_CR_REQ, MPFS_SYS_SERVICE_CR);
+ /*
+* REQ bit will remain set till the system controller starts
+* processing.
+*/
+ do {
+ val = readl(MPFS_SYS_SERVICE_CR);
+ } while (SERVICE_CR_REQ == (val & SERVICE_CR_REQ));
+
+ /*
+* Once system controller starts processing the busy bit will
+* go high and service is completed when busy bit is gone low
+*/
+ do {
+ val = readl(MPFS_SYS_SERVICE_SR);
+ } while (SERVICE_SR_BUSY == (val & SERVICE_SR_BUSY));
+
+ for (idx = 0; idx < response_size; idx++)
+ response_buf[idx] = readb(MPFS_SYS_SERVICE_MAILBOX + idx);
+}
int board_init(void)
{
@@ -22,10 +59,64 @@ int board_early_init_f(void)
{
unsigned int val;
- /* Reset uart peripheral */
+ /* Reset uart, mmc peripheral */
val = readl(MPFS_SYSREG_SOFT_RESET);
- val = (val & ~(1u << 5u));
+ val = (val & ~(PERIPH_RESET_VALUE));
writel(val, MPFS_SYSREG_SOFT_RESET);
return 0;
}
+
+int board_late_init(void)
+{
+ u32 ret;
+ u32 node;
+ u8 idx;
+ u8 device_serial_number[16] = { 0 };
+ unsigned char mac_addr[6];
+ char icicle_mac_addr[20];
+ void *blob = (void *)gd->fdt_blob;
+
+ node = fdt_path_offset(blob, "ethernet0");
+ if (node < 0) {
+ printf("No ethernet0 path offset\n");
+ return -ENODEV;
+ }
+
+ ret = fdtdec_get_byte_array(blob, node, "local-mac-address", mac_addr,
6);
+ if (ret) {
+ printf("No local-mac-address property\n");
+ return -EINVAL;
+ }
+
+ read_device_serial_number(device_serial_number, 16);
+
+ /* Update MAC address with device serial number */
+ mac_addr[0] = 0x00;
+ mac_addr[1] = 0x04;
+ mac_addr[2] = 0xA3;
+ mac_addr[3] = device_serial_number[2];
+ mac_addr[4] = device_serial_number[1];
+ mac_addr[5] = device_serial_number[0];
+
+ ret = fdt_setprop(blob, node, "local-mac-address", mac_addr, 6);
+ if (ret) {
+ printf("Error setting local-mac-address property\n");
+ return -ENODEV;
+ }
+
+ icicle_mac_addr[0] = '[';
+
+ sprintf(_mac_addr[1], "%pM", mac_addr);
+
+
[PATCH v3 3/7] net: macb: Add phy address to read it from device tree
Read phy address from device tree and use it to find the phy device
if not found then search in the range of 0 to 31.
Signed-off-by: Padmarao Begari
---
drivers/net/macb.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 9ccbb7a166..81b1f1ba26 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -531,6 +531,12 @@ static int macb_phy_find(struct macb_device *macb, const
char *name)
int i;
u16 phy_id;
+ phy_id = macb_mdio_read(macb, macb->phy_addr, MII_PHYSID1);
+ if (phy_id != 0x) {
+ printf("%s: PHY present at %d\n", name, macb->phy_addr);
+ return 0;
+ }
+
/* Search for PHY... */
for (i = 0; i < 32; i++) {
macb->phy_addr = i;
@@ -1315,11 +1321,12 @@ static int macb_eth_probe(struct udevice *dev)
{
struct eth_pdata *pdata = dev_get_platdata(dev);
struct macb_device *macb = dev_get_priv(dev);
+ struct ofnode_phandle_args phandle_args;
const char *phy_mode;
int ret;
- 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)
macb->phy_interface = phy_get_interface_by_name(phy_mode);
if (macb->phy_interface == -1) {
@@ -1327,6 +1334,12 @@ static int macb_eth_probe(struct udevice *dev)
return -EINVAL;
}
+ /* Read phyaddr from DT */
+ if (!dev_read_phandle_with_args(dev, "phy-handle", NULL, 0, 0,
+ _args))
+ macb->phy_addr = ofnode_read_u32_default(phandle_args.node,
+"reg", -1);
+
macb->regs = (void *)pdata->iobase;
macb->is_big_endian = (cpu_to_be32(0x12345678) == 0x12345678);
--
2.17.1
[PATCH v3 4/7] clk: Add Microchip PolarFire SoC clock driver
Add clock driver code for the Microchip PolarFire SoC. This driver
handles reset and clock control of the Microchip PolarFire SoC device.
Signed-off-by: Padmarao Begari
Reviewed-by: Anup Patel
---
drivers/clk/Kconfig | 1 +
drivers/clk/Makefile | 1 +
drivers/clk/microchip/Kconfig | 5 +
drivers/clk/microchip/Makefile| 1 +
drivers/clk/microchip/clk_pfsoc.c | 127 +
drivers/clk/microchip/clk_pfsoc.h | 19 ++
drivers/clk/microchip/clk_pfsoc_cfg.c | 134 ++
drivers/clk/microchip/clk_pfsoc_periph.c | 173 ++
.../dt-bindings/clock/microchip,pfsoc-clock.h | 45 +
9 files changed, 506 insertions(+)
create mode 100644 drivers/clk/microchip/Kconfig
create mode 100644 drivers/clk/microchip/Makefile
create mode 100644 drivers/clk/microchip/clk_pfsoc.c
create mode 100644 drivers/clk/microchip/clk_pfsoc.h
create mode 100644 drivers/clk/microchip/clk_pfsoc_cfg.c
create mode 100644 drivers/clk/microchip/clk_pfsoc_periph.c
create mode 100644 include/dt-bindings/clock/microchip,pfsoc-clock.h
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 4dfbad7986..1161fe7b5a 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -173,6 +173,7 @@ source "drivers/clk/exynos/Kconfig"
source "drivers/clk/imx/Kconfig"
source "drivers/clk/kendryte/Kconfig"
source "drivers/clk/meson/Kconfig"
+source "drivers/clk/microchip/Kconfig"
source "drivers/clk/mvebu/Kconfig"
source "drivers/clk/owl/Kconfig"
source "drivers/clk/renesas/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d1e295ac7c..bd8a6eed88 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_CLK_EXYNOS) += exynos/
obj-$(CONFIG_$(SPL_TPL_)CLK_INTEL) += intel/
obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
obj-$(CONFIG_CLK_K210) += kendryte/
+obj-$(CONFIG_CLK_MPFS) += microchip/
obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
obj-$(CONFIG_CLK_OCTEON) += clk_octeon.o
obj-$(CONFIG_CLK_OWL) += owl/
diff --git a/drivers/clk/microchip/Kconfig b/drivers/clk/microchip/Kconfig
new file mode 100644
index 00..b70241559d
--- /dev/null
+++ b/drivers/clk/microchip/Kconfig
@@ -0,0 +1,5 @@
+config CLK_MPFS
+ bool "Clock support for Microchip PolarFire SoC"
+ depends on CLK && CLK_CCF
+ help
+ This enables support clock driver for Microchip PolarFire SoC
platform.
diff --git a/drivers/clk/microchip/Makefile b/drivers/clk/microchip/Makefile
new file mode 100644
index 00..c7f5ad21ae
--- /dev/null
+++ b/drivers/clk/microchip/Makefile
@@ -0,0 +1 @@
+obj-y += clk_pfsoc.o clk_pfsoc_cfg.o clk_pfsoc_periph.o
diff --git a/drivers/clk/microchip/clk_pfsoc.c
b/drivers/clk/microchip/clk_pfsoc.c
new file mode 100644
index 00..dd0e9cacb8
--- /dev/null
+++ b/drivers/clk/microchip/clk_pfsoc.c
@@ -0,0 +1,127 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Microchip Technology Inc.
+ * Padmarao Begari
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clk_pfsoc.h"
+
+/* All methods are delegated to CCF clocks */
+
+static ulong pfsoc_clk_get_rate(struct clk *clk)
+{
+ struct clk *c;
+ int err = clk_get_by_id(clk->id, );
+
+ if (err)
+ return err;
+ return clk_get_rate(c);
+}
+
+static ulong pfsoc_clk_set_rate(struct clk *clk, unsigned long rate)
+{
+ struct clk *c;
+ int err = clk_get_by_id(clk->id, );
+
+ if (err)
+ return err;
+ return clk_set_rate(c, rate);
+}
+
+static int pfsoc_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+ struct clk *c, *p;
+ int err = clk_get_by_id(clk->id, );
+
+ if (err)
+ return err;
+
+ err = clk_get_by_id(parent->id, );
+ if (err)
+ return err;
+
+ return clk_set_parent(c, p);
+}
+
+static int pfsoc_clk_endisable(struct clk *clk, bool enable)
+{
+ struct clk *c;
+ int err = clk_get_by_id(clk->id, );
+
+ if (err)
+ return err;
+ return enable ? clk_enable(c) : clk_disable(c);
+}
+
+static int pfsoc_clk_enable(struct clk *clk)
+{
+ return pfsoc_clk_endisable(clk, true);
+}
+
+static int pfsoc_clk_disable(struct clk *clk)
+{
+ return pfsoc_clk_endisable(clk, false);
+}
+
+static int pfsoc_clk_probe(struct udevice *dev)
+{
+ int ret;
+ void __iomem *base;
+ u32 clk_rate;
+ struct clk *clk;
+ const char *parent_clk_name;
+
+ base = dev_read_addr_ptr(dev);
+ if (!base)
+ return -ENODEV;
+
+ clk = kzalloc(sizeof(*clk), GFP_KERNEL);
+ if (!clk)
+ return -ENOMEM;
+
+ ret = clk_get_by_index(dev, 0, clk);
+ if (ret)
+ return ret;
+
+ dev_read_u32(clk->dev, "clock-frequency", _rate);
+
[PATCH v3 2/7] net: macb: Add DMA 64-bit address support for macb
Enable 32-bit or 64-bit DMA in the macb driver based on the design
config debug6 register of MACB hardware which supports 32-bit or
64-bit DMA.
Signed-off-by: Padmarao Begari
---
drivers/net/macb.c | 121 +++--
drivers/net/macb.h | 6 +++
2 files changed, 112 insertions(+), 15 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index b80a259ff7..9ccbb7a166 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -83,7 +83,16 @@ struct macb_dma_desc {
u32 ctrl;
};
-#define DMA_DESC_BYTES(n) (n * sizeof(struct macb_dma_desc))
+struct macb_dma_desc_64 {
+ u32 addrh;
+ u32 unused;
+};
+
+#define HW_DMA_CAP_32B 0
+#define HW_DMA_CAP_64B 1
+
+#define DMA_DESC_SIZE 16
+#define DMA_DESC_BYTES(n) ((n) * DMA_DESC_SIZE)
#define MACB_TX_DMA_DESC_SIZE (DMA_DESC_BYTES(MACB_TX_RING_SIZE))
#define MACB_RX_DMA_DESC_SIZE (DMA_DESC_BYTES(MACB_RX_RING_SIZE))
#define MACB_TX_DUMMY_DMA_DESC_SIZE(DMA_DESC_BYTES(1))
@@ -133,6 +142,7 @@ struct macb_device {
#endif
phy_interface_t phy_interface;
#endif
+ unsigned short hw_dma_cap;
};
struct macb_config {
@@ -307,6 +317,24 @@ static inline void macb_invalidate_rx_buffer(struct
macb_device *macb)
#if defined(CONFIG_CMD_NET)
+static struct macb_dma_desc_64 *macb_64b_desc(struct macb_dma_desc *desc)
+{
+ return (struct macb_dma_desc_64 *)((void *)desc
+ + sizeof(struct macb_dma_desc));
+}
+
+static void macb_set_addr(struct macb_device *macb, struct macb_dma_desc *desc,
+ ulong addr)
+{
+ struct macb_dma_desc_64 *desc_64;
+
+ if (macb->hw_dma_cap & HW_DMA_CAP_64B) {
+ desc_64 = macb_64b_desc(desc);
+ desc_64->addrh = upper_32_bits(addr);
+ }
+ desc->addr = lower_32_bits(addr);
+}
+
static int _macb_send(struct macb_device *macb, const char *name, void *packet,
int length)
{
@@ -325,8 +353,12 @@ static int _macb_send(struct macb_device *macb, const char
*name, void *packet,
macb->tx_head++;
}
+ if (macb->hw_dma_cap & HW_DMA_CAP_64B)
+ tx_head = tx_head * 2;
+
macb->tx_ring[tx_head].ctrl = ctrl;
- macb->tx_ring[tx_head].addr = paddr;
+ macb_set_addr(macb, >tx_ring[tx_head], paddr);
+
barrier();
macb_flush_ring_desc(macb, TX);
macb_writel(macb, NCR, MACB_BIT(TE) | MACB_BIT(RE) | MACB_BIT(TSTART));
@@ -363,19 +395,28 @@ static void reclaim_rx_buffers(struct macb_device *macb,
unsigned int new_tail)
{
unsigned int i;
+ unsigned int count;
i = macb->rx_tail;
macb_invalidate_ring_desc(macb, RX);
while (i > new_tail) {
- macb->rx_ring[i].addr &= ~MACB_BIT(RX_USED);
+ if (macb->hw_dma_cap & HW_DMA_CAP_64B)
+ count = i * 2;
+ else
+ count = i;
+ macb->rx_ring[count].addr &= ~MACB_BIT(RX_USED);
i++;
if (i > MACB_RX_RING_SIZE)
i = 0;
}
while (i < new_tail) {
- macb->rx_ring[i].addr &= ~MACB_BIT(RX_USED);
+ if (macb->hw_dma_cap & HW_DMA_CAP_64B)
+ count = i * 2;
+ else
+ count = i;
+ macb->rx_ring[count].addr &= ~MACB_BIT(RX_USED);
i++;
}
@@ -390,16 +431,25 @@ static int _macb_recv(struct macb_device *macb, uchar
**packetp)
void *buffer;
int length;
u32 status;
+ u8 flag = false;
macb->wrapped = false;
for (;;) {
macb_invalidate_ring_desc(macb, RX);
+ if (macb->hw_dma_cap & HW_DMA_CAP_64B)
+ next_rx_tail = next_rx_tail * 2;
+
if (!(macb->rx_ring[next_rx_tail].addr & MACB_BIT(RX_USED)))
return -EAGAIN;
status = macb->rx_ring[next_rx_tail].ctrl;
if (status & MACB_BIT(RX_SOF)) {
+ if (macb->hw_dma_cap & HW_DMA_CAP_64B) {
+ next_rx_tail = next_rx_tail / 2;
+ flag = true;
+ }
+
if (next_rx_tail != macb->rx_tail)
reclaim_rx_buffers(macb, next_rx_tail);
macb->wrapped = false;
@@ -426,11 +476,22 @@ static int _macb_recv(struct macb_device *macb, uchar
**packetp)
*packetp = buffer;
}
+ if (macb->hw_dma_cap & HW_DMA_CAP_64B) {
+ if (!flag)
+ next_rx_tail = next_rx_tail / 2;
+ }
+
if (++next_rx_tail >=
[PATCH v3 7/7] doc: board: Add Microchip MPFS Icicle Kit doc
This doc describes the procedure to build, flash and
boot Linux using U-boot on Microchip MPFS Icicle Kit.
Signed-off-by: Padmarao Begari
---
doc/board/index.rst | 1 +
doc/board/microchip/index.rst | 9 +
doc/board/microchip/mpfs_icicle.rst | 827
3 files changed, 837 insertions(+)
create mode 100644 doc/board/microchip/index.rst
create mode 100644 doc/board/microchip/mpfs_icicle.rst
diff --git a/doc/board/index.rst b/doc/board/index.rst
index 4b6a996eb1..e329e2744c 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -15,6 +15,7 @@ Board-specific doc
freescale/index
google/index
intel/index
+ microchip/index
kontron/index
renesas/index
rockchip/index
diff --git a/doc/board/microchip/index.rst b/doc/board/microchip/index.rst
new file mode 100644
index 00..b09e6788af
--- /dev/null
+++ b/doc/board/microchip/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Microchip
+==
+
+.. toctree::
+ :maxdepth: 2
+
+ mpfs_icicle
diff --git a/doc/board/microchip/mpfs_icicle.rst
b/doc/board/microchip/mpfs_icicle.rst
new file mode 100644
index 00..745e28a944
--- /dev/null
+++ b/doc/board/microchip/mpfs_icicle.rst
@@ -0,0 +1,827 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Microchip PolarFire SoC Icicle Kit
+==
+
+RISC-V PolarFire SoC
+-
+The PolarFire SoC is the 4+1 64-bit RISC-V SoC from Microchip.
+
+The Icicle Kit development platform is based on PolarFire SoC and capable
+of running Linux.
+
+Mainline support
+
+The support for following drivers are already enabled:
+
+1. NS16550 UART Driver.
+2. Microchip Clock Driver.
+3. Cadence MACB ethernet driver for networking support.
+4. Cadence MMC Driver for eMMC/SD support.
+
+Booting from eMMC using HSS
+---
+
+Building U-Boot
+---
+
+1. Add the RISC-V toolchain to your PATH.
+2. Setup ARCH & cross compilation environment variable:
+
+.. code-block:: none
+
+ export CROSS_COMPILE=
+
+3. make microchip_mpfs_icicle_defconfig
+4. make
+
+Flashing
+
+
+The current U-Boot port is supported in S-mode only and loaded from DRAM.
+
+A prior stage M-mode firmware/bootloader (e.g HSS with OpenSBI) is required to
+boot the u-boot.bin in S-mode.
+
+Currently, the u-boot.bin is used as a payload of the HSS firmware(Microchip
+boot-flow) and OpenSBI generic platform fw_payload.bin (with u-boot.bin
embedded)
+as HSS payload(Custom boot-flow)
+
+Microchip boot-flow
+---
+HSS with OpenSBI(M-Mode) -> U-Boot(S-Mode) -> Linux(S-Mode)
+
+Build the HSS((Hart Software Services) - Microchip boot-flow
+
+(Note: HSS git repo is at
+https://github.com/polarfire-soc/hart-software-services)
+
+1. Configure
+
+.. code-block:: none
+
+ make BOARD=icicle-kit-es config
+
+Alternatively, copy the default config for Microchip boot-flow.
+
+.. code-block:: none
+
+ cp boards/icicle-kit-es/def_config .config
+
+2. make BOARD=icicle-kit-es
+3. In the Default subdirectory, the standard build will create hss.elf and
+ various binary formats (hss.hex and hss.bin).
+
+The FPGA design will use the hss.hex or hss.bin.
+
+FPGA design with HSS programming file
+-
+https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/boards
+/mpfs-icicle-kit-es/updating-icicle-kit/updating-icicle-kit-design-and-linux.md
+
+The HSS firmware runs from the PolarFire SoC eNVM on reset.
+
+Creating the HSS payload - Microchip boot-flow
+--
+1. You will be creating a payload from `u-boot-dtb.bin`.
+ Copy this file to the HSS/tools/hss-payload-generator/test directory.
+2. Go to hss-payload-generator source directory.
+
+.. code-block:: none
+
+ cd hart-software-services/tools/hss-payload-generator
+
+3. Edit test/uboot.yaml file for hart entry points and correct name of the
binary file.
+
+ hart-entry-points: {u54_1: '0x8020', u54_2: '0x8020',
+ u54_3: '0x8020', u54_4: '0x8020'}
+
+ payloads:
+ test/u-boot-dtb.bin: {exec-addr: '0x8020', owner-hart: u54_1,
+ secondary-hart: u54_2, secondary-hart: u54_3, secondary-hart:
u54_4,
+ priv-mode: prv_s}
+
+4. Generate payload
+
+.. code-block:: none
+
+ ./hss-payload-generator -c test/uboot.yaml payload.bin
+
+Once the payload binary is generated, it should be copied to the eMMC.
+
+Please refer to HSS documenation to build the HSS firmware for payload.
+(Note: HSS git repo is at
+https://github.com/polarfire-soc/hart-software-services/blob/master
+/tools/hss-payload-generator/README.md)
+
+Custom boot-flow
+
+HSS without OpenSBI(M-Mode) -> OpenSBI(M-Mode) -> U-Boot(S-Mode) ->
Linux(S-Mode)
+
+Build OpenSBI
+-
+
+1. Get the OpenSBI source
+
+..
[PATCH v3 5/7] riscv: dts: Add device tree for Microchip Icicle Kit
Add device tree for Microchip PolarFire SoC Icicle Kit.
Signed-off-by: Padmarao Begari
Reviewed-by: Anup Patel
---
arch/riscv/dts/Makefile | 1 +
.../dts/microchip-mpfs-icicle-kit-u-boot.dtsi | 15 +
arch/riscv/dts/microchip-mpfs-icicle-kit.dts | 421 ++
3 files changed, 437 insertions(+)
create mode 100644 arch/riscv/dts/microchip-mpfs-icicle-kit-u-boot.dtsi
create mode 100644 arch/riscv/dts/microchip-mpfs-icicle-kit.dts
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 3a6f96c67d..01331b0aa1 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -3,6 +3,7 @@
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
dtb-$(CONFIG_TARGET_SIFIVE_FU540) += hifive-unleashed-a00.dtb
dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
+dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
targets += $(dtb-y)
diff --git a/arch/riscv/dts/microchip-mpfs-icicle-kit-u-boot.dtsi
b/arch/riscv/dts/microchip-mpfs-icicle-kit-u-boot.dtsi
new file mode 100644
index 00..f1738c8a24
--- /dev/null
+++ b/arch/riscv/dts/microchip-mpfs-icicle-kit-u-boot.dtsi
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2020 Microchip Technology Inc.
+ * Padmarao Begari
+ */
+
+/ {
+ aliases {
+ cpu1 =
+ cpu2 =
+ cpu3 =
+ cpu4 =
+ };
+};
+
diff --git a/arch/riscv/dts/microchip-mpfs-icicle-kit.dts
b/arch/riscv/dts/microchip-mpfs-icicle-kit.dts
new file mode 100644
index 00..67e797255b
--- /dev/null
+++ b/arch/riscv/dts/microchip-mpfs-icicle-kit.dts
@@ -0,0 +1,421 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (c) 2020 Microchip Technology Inc */
+
+/dts-v1/;
+#include "dt-bindings/clock/microchip,pfsoc-clock.h"
+
+/* Clock frequency (in Hz) of the rtcclk */
+#define RTCCLK_FREQ100
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ model = "Microchip PolarFire-SoC";
+ compatible = "microchip,polarfire-soc";
+
+ aliases {
+ serial0 =
+ ethernet0 =
+ };
+
+ chosen {
+ stdout-path = "serial0";
+ };
+
+ cpucomplex: cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = ;
+ cpu0: cpu@0 {
+ clocks = < CLK_CPU>;
+ compatible = "sifive,e51", "sifive,rocket0", "riscv";
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <128>;
+ i-cache-size = <16384>;
+ reg = <0>;
+ riscv,isa = "rv64imac";
+ status = "disabled";
+ operating-points = <
+ /* kHz uV */
+ 60 110
+ 30 95
+ 15 75
+ >;
+ cpu0intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+ cpu1: cpu@1 {
+ clocks = < CLK_CPU>;
+ compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
+ d-cache-block-size = <64>;
+ d-cache-sets = <64>;
+ d-cache-size = <32768>;
+ d-tlb-sets = <1>;
+ d-tlb-size = <32>;
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <64>;
+ i-cache-size = <32768>;
+ i-tlb-sets = <1>;
+ i-tlb-size = <32>;
+ mmu-type = "riscv,sv39";
+ reg = <1>;
+ riscv,isa = "rv64imafdc";
+ tlb-split;
+ status = "okay";
+ operating-points = <
+ /* kHz uV */
+ 60 110
+ 30 95
+ 15 75
+ >;
+ cpu1intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+ cpu2: cpu@2 {
+ clocks = < CLK_CPU>;
+ compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
+
[PATCH v3 1/7] riscv: Add DMA 64-bit address support
dma_addr_t holds any valid DMA address. If the DMA API only uses 32/64-bit addresses, dma_addr_t need only be 32/64 bits wide. Signed-off-by: Padmarao Begari Reviewed-by: Anup Patel --- arch/riscv/Kconfig | 4 arch/riscv/include/asm/types.h | 4 2 files changed, 8 insertions(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 30b05408b1..55eaee2da6 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -152,6 +152,10 @@ config 32BIT config 64BIT bool +config DMA_ADDR_T_64BIT + bool + default y if 64BIT + config SIFIVE_CLINT bool depends on RISCV_MMODE || SPL_RISCV_MMODE diff --git a/arch/riscv/include/asm/types.h b/arch/riscv/include/asm/types.h index 403cf9a48f..b800b2d221 100644 --- a/arch/riscv/include/asm/types.h +++ b/arch/riscv/include/asm/types.h @@ -29,7 +29,11 @@ typedef unsigned short umode_t; #include +#ifdef CONFIG_DMA_ADDR_T_64BIT +typedef u64 dma_addr_t; +#else typedef u32 dma_addr_t; +#endif typedef unsigned long phys_addr_t; typedef unsigned long phys_size_t; -- 2.17.1
[PATCH v3 0/7] Microchip PolarFire SoC support
This patch set adds Microchip PolarFire SoC Icicle Kit support to RISC-V U-Boot. The patches are based upon latest U-Boot tree (https://gitlab.denx.de/u-boot/u-boot.git) at commit id 1ae955e3a58f46918ef99b0b6c562967ba1bf39e All drivers namely: NS16550 Serial, Microchip clock, Cadence eMMC and Cadence MACB Ethernet work fine on actual Microchip PolarFire SoC Icicle Kit. Changes in v3: - Add 'default y if 64BIT' for config DMA_ADDR_T_64BIT - Update MACB driver for 32-bit/64-bit DMA based on design config register - Add phy-handle in MACB driver to read the phy address from device tree - Fix checkpatch warnings in the clock driver - Remove fu540 related compatible strings from soc device tree node - Move refclk device tree node under /soc device tree node - Use local-mac-address instead of mac-address in the device tree - Rename device tree to microchip-mpfs-icicle-kit.dts - Add U-Boot specific dts microchip-mpfs-icicle-kit-u-boot.dtsi file - Drop the imply DMA_ADDR_T_64BIT from board config - Fix some typos - Update doc with Microchip and Custom boot-flow Changes in v2: - Add clock frequency for the clint device tree node - Move peripheral device tree nodes under /soc device tree node - Device tree nodes are in order based on the address - Enable UART0 for U-Boot logs - Update doc for the U-Boot logs are on UART0 - Move clock and reset index source into patch4 - Remove "dma_addr_r" type in the macb driver - Add lower_32_bits() for 32-bit address in the macb driver - Add set_rate() returns the new clock rate in the clock driver Padmarao Begari (7): riscv: Add DMA 64-bit address support net: macb: Add DMA 64-bit address support for macb net: macb: Add phy address to read it from device tree clk: Add Microchip PolarFire SoC clock driver riscv: dts: Add device tree for Microchip Icicle Kit riscv: Add Microchip MPFS Icicle Kit support doc: board: Add Microchip MPFS Icicle Kit doc arch/riscv/Kconfig| 4 + arch/riscv/dts/Makefile | 1 + .../dts/microchip-mpfs-icicle-kit-u-boot.dtsi | 15 + arch/riscv/dts/microchip-mpfs-icicle-kit.dts | 421 + arch/riscv/include/asm/types.h| 4 + board/microchip/mpfs_icicle/Kconfig | 24 + board/microchip/mpfs_icicle/mpfs_icicle.c | 97 +- configs/microchip_mpfs_icicle_defconfig | 9 +- doc/board/index.rst | 1 + doc/board/microchip/index.rst | 9 + doc/board/microchip/mpfs_icicle.rst | 827 ++ drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 1 + drivers/clk/microchip/Kconfig | 5 + drivers/clk/microchip/Makefile| 1 + drivers/clk/microchip/clk_pfsoc.c | 127 +++ drivers/clk/microchip/clk_pfsoc.h | 19 + drivers/clk/microchip/clk_pfsoc_cfg.c | 134 +++ drivers/clk/microchip/clk_pfsoc_periph.c | 173 drivers/net/macb.c| 138 ++- drivers/net/macb.h| 6 + include/configs/microchip_mpfs_icicle.h | 60 +- .../dt-bindings/clock/microchip,pfsoc-clock.h | 45 + 23 files changed, 2060 insertions(+), 62 deletions(-) create mode 100644 arch/riscv/dts/microchip-mpfs-icicle-kit-u-boot.dtsi create mode 100644 arch/riscv/dts/microchip-mpfs-icicle-kit.dts create mode 100644 doc/board/microchip/index.rst create mode 100644 doc/board/microchip/mpfs_icicle.rst create mode 100644 drivers/clk/microchip/Kconfig create mode 100644 drivers/clk/microchip/Makefile create mode 100644 drivers/clk/microchip/clk_pfsoc.c create mode 100644 drivers/clk/microchip/clk_pfsoc.h create mode 100644 drivers/clk/microchip/clk_pfsoc_cfg.c create mode 100644 drivers/clk/microchip/clk_pfsoc_periph.c create mode 100644 include/dt-bindings/clock/microchip,pfsoc-clock.h -- 2.17.1
Re: [PATCH] binman: Handle tool paths containing '~' correctly
On 09/11/2020 17:45, Simon Glass wrote: > At present if CROSS_COMPILE contains a tilde, such as > ~/.buildman-toolchains/gcc-7.3.0-nolibc/i386-linux/bin/i386-linux-gcc > then binman gives a confusing error: > >binman: Error 255 running '~/..buildman-toolchains/gcc-7.3.0- ... > > Fix this by expanding it out before running the tool. > > Signed-off-by: Simon Glass Arguably, whatever is passing CROSS_COMPILE to binman should have expanded that; how are you passing it? If that's from shell you could use one of CROSS_COMPILE="$HOME/..." or ~/"..." (the "~/..." form isn't expanded), if it's read from e.g. ~/.buildman then the config parser should be expanding it at read-time.
[PATCH] sandbox: cros_ec: Basic support for EC_CMD_GET_NEXT_EVENT
Since commit 690079767803 ("cros_ec: Support keyboard scanning with
EC_CMD_GET_NEXT_EVENT") the cros-ec-keyb driver has started using this
command, but the sandbox EC emulator does not recognize it and
continuously prints:
** Unknown EC command 0x67
This patch makes the sandbox driver send basic responses to the command,
but the response only supports keyboard scans for now.
Fixes: 690079767803 ("cros_ec: Support keyboard scanning with
EC_CMD_GET_NEXT_EVENT")
Reported-by: Heinrich Schuchardt
Signed-off-by: Alper Nebi Yasak
---
This doesn't test the -EC_RES_UNAVAILABLE part, which looks like an
event queue on the EC side. As far as I understand sandbox is getting a
single keyboard state from SDL after discarding pending events. I think
things would need to be hooked into sandbox_sdl_poll_events, looks
possible but harder.
Also, now that this command would work, the fallback to the old one
would never trigger and wouldn't be tested.
drivers/misc/cros_ec_sandbox.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/misc/cros_ec_sandbox.c b/drivers/misc/cros_ec_sandbox.c
index a191f061b898..d72db3eace98 100644
--- a/drivers/misc/cros_ec_sandbox.c
+++ b/drivers/misc/cros_ec_sandbox.c
@@ -460,6 +460,14 @@ static int process_cmd(struct ec_state *ec,
case EC_CMD_ENTERING_MODE:
len = 0;
break;
+ case EC_CMD_GET_NEXT_EVENT: {
+ struct ec_response_get_next_event *resp = resp_data;
+
+ resp->event_type = EC_MKBP_EVENT_KEY_MATRIX;
+ cros_ec_keyscan(ec, resp->data.key_matrix);
+ len = sizeof(*resp);
+ break;
+ }
default:
printf(" ** Unknown EC command %#02x\n", req_hdr->command);
return -1;
--
2.29.2
Re: [PATCH v3 5/7] riscv: dts: Add device tree for Microchip Icicle Kit
On Tue, Nov 10, 2020 at 6:46 PM Padmarao Begari wrote: > > Add device tree for Microchip PolarFire SoC Icicle Kit. > > Signed-off-by: Padmarao Begari > Reviewed-by: Anup Patel > --- > arch/riscv/dts/Makefile | 1 + > .../dts/microchip-mpfs-icicle-kit-u-boot.dtsi | 15 + > arch/riscv/dts/microchip-mpfs-icicle-kit.dts | 421 ++ > 3 files changed, 437 insertions(+) > create mode 100644 arch/riscv/dts/microchip-mpfs-icicle-kit-u-boot.dtsi > create mode 100644 arch/riscv/dts/microchip-mpfs-icicle-kit.dts > I believe we will need to wait for Atish's Linux kernel patch to be reviewed upstream before we can merge U-Boot's ? Regards, Bin
Re: [PATCH v2 22/33] i2c: stm32f7_i2c: migrate trace to dev and log macro
Hello Patrick, Am 06.11.2020 um 19:01 schrieb Patrick Delaunay: Change debug to dev_dbg macro and define LOG_CATEGORY. Remove the "%s:" __func__ header as it is managed by dev macro (dev->name is displayed) or log macro (CONFIG_LOGF_FUNC). Signed-off-by: Patrick Delaunay Reviewed-by: Patrice Chotard --- (no changes since v1) drivers/i2c/stm32f7_i2c.c | 74 +++ 1 file changed, 37 insertions(+), 37 deletions(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH 0/5] sunxi: enable automatic eMMC boot partition support
On Tue, Nov 10, 2020 at 12:57:09PM +, André Przywara wrote: > On 10/11/2020 12:38, Tom Rini wrote: > > Hi Tom, > > > On Sun, Nov 08, 2020 at 03:48:23PM +, André Przywara wrote: > >> On 08/11/2020 14:59, Peter Robinson wrote: > >> > >> Hi, > >> > >>> On Sun, Nov 8, 2020 at 1:14 PM Andre Przywara > >>> wrote: > > The eMMC standard describes the concept of boot partitions, consisting > of two storage areas separate from the main user data partition. > The Allwinner BootROM supports loading SPL/Boot0 from such a boot > partition, if that is configured in the eMMC device [1]. > > To load U-Boot proper along with the SPL from there, currently this > requires to enable CONFIG_SUPPORT_EMMC_BOOT, and this means that this > build won't boot from the normal eMMC user partition anymore. > Also the raw MMC sector offset needs to be adjusted manually, preventing > a boot from an SD card. > > This series introduces automatic detection of eMMC boot partition boot. > Patch 3/5 automates the raw MMC sector offset decision, allowing such > a build to also boot from an SD card. > Unfortunately the BootROM does not mark an eMMC boot partition boot > differently from the normal eMMC user data partition boot, so patch 4/5 > introduces a function that repeats the BootROM algorithm, so that the SPL > comes to the same conclusion as the BootROM. This allows to build one > single image that boots from everywhere: eMMC user data, eMMC boot, > SD card, SPI flash. > Patch 1/5 contains a bugfix that's needed in a later patch, patch 2/5 > extends the generic spl_mmc_boot_mode() interface to make 4/5 feasible. > > Without enabling CONFIG_SUPPORT_EMMC_BOOT, the AArch64 SPL grows by > 92 bytes, ARMv7 grows by 36 bytes. With enabling the feature, the size > goes up by 444 bytes (AArch64) and 260 bytes (ARMv7). > Even for AArch64 this is still 4.5 KB below the SPL limit, so patch 5/5 > enables this new mechanism for some boards I could test this on. > > Please have a look and test this if you have a board with eMMC. > I put installation instructions into the linux-sunxi Wiki: > http://linux-sunxi.org/Bootable_eMMC > >>> > >>> It would probably be good to put that link in the local Allwinner docs > >>> so it's easier for people to find. > >> > >> Yeah, actually as you mention it: > >> There does not seem to be some generic README.sunxi file where this > >> would belong to. > >> > >> Jagan: would it make sense to create one, and describe how to get U-Boot > >> into the devices (SD card, eMMC, SPI flash, FEL)? That could move some > >> parts of README.sunxi64 out of there, since they apply to all Allwinner > >> devices. > >> > >> If people agree that this is the right thing to do, I would be happy to > >> send a patch. > > > > Well, rST file in doc/boards/ and all of that, but, yes please. > > Ah, thanks for the pointer, looks good. > Do we accept symlinks in the tree? There are quite some references to > board/sunxi/README.sunxi64 out there. Or shall I keep a stub instead? As there's external references to the README file, yes, please stub it out pointing people to the new rST file. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/5] sunxi: enable automatic eMMC boot partition support
On 10/11/2020 12:38, Tom Rini wrote: Hi Tom, > On Sun, Nov 08, 2020 at 03:48:23PM +, André Przywara wrote: >> On 08/11/2020 14:59, Peter Robinson wrote: >> >> Hi, >> >>> On Sun, Nov 8, 2020 at 1:14 PM Andre Przywara >>> wrote: The eMMC standard describes the concept of boot partitions, consisting of two storage areas separate from the main user data partition. The Allwinner BootROM supports loading SPL/Boot0 from such a boot partition, if that is configured in the eMMC device [1]. To load U-Boot proper along with the SPL from there, currently this requires to enable CONFIG_SUPPORT_EMMC_BOOT, and this means that this build won't boot from the normal eMMC user partition anymore. Also the raw MMC sector offset needs to be adjusted manually, preventing a boot from an SD card. This series introduces automatic detection of eMMC boot partition boot. Patch 3/5 automates the raw MMC sector offset decision, allowing such a build to also boot from an SD card. Unfortunately the BootROM does not mark an eMMC boot partition boot differently from the normal eMMC user data partition boot, so patch 4/5 introduces a function that repeats the BootROM algorithm, so that the SPL comes to the same conclusion as the BootROM. This allows to build one single image that boots from everywhere: eMMC user data, eMMC boot, SD card, SPI flash. Patch 1/5 contains a bugfix that's needed in a later patch, patch 2/5 extends the generic spl_mmc_boot_mode() interface to make 4/5 feasible. Without enabling CONFIG_SUPPORT_EMMC_BOOT, the AArch64 SPL grows by 92 bytes, ARMv7 grows by 36 bytes. With enabling the feature, the size goes up by 444 bytes (AArch64) and 260 bytes (ARMv7). Even for AArch64 this is still 4.5 KB below the SPL limit, so patch 5/5 enables this new mechanism for some boards I could test this on. Please have a look and test this if you have a board with eMMC. I put installation instructions into the linux-sunxi Wiki: http://linux-sunxi.org/Bootable_eMMC >>> >>> It would probably be good to put that link in the local Allwinner docs >>> so it's easier for people to find. >> >> Yeah, actually as you mention it: >> There does not seem to be some generic README.sunxi file where this >> would belong to. >> >> Jagan: would it make sense to create one, and describe how to get U-Boot >> into the devices (SD card, eMMC, SPI flash, FEL)? That could move some >> parts of README.sunxi64 out of there, since they apply to all Allwinner >> devices. >> >> If people agree that this is the right thing to do, I would be happy to >> send a patch. > > Well, rST file in doc/boards/ and all of that, but, yes please. Ah, thanks for the pointer, looks good. Do we accept symlinks in the tree? There are quite some references to board/sunxi/README.sunxi64 out there. Or shall I keep a stub instead? Cheers, Andre
Re: [PATCH 01/26] lib: rational: copy the rational fraction lib routines from Linux
On Tue, Nov 10, 2020 at 11:05:37AM +0200, Tero Kristo wrote: > Copy the best rational approximation calculation routines from Linux. > Typical usecase for these routines is to calculate the M/N divider > values for PLLs to reach a specific clock rate. > > Signed-off-by: Tero Kristo Please say what version of the Linux kernel this is from, for easier later re-syncing. Thanks. -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-x86
On Tue, Nov 10, 2020 at 11:38:58AM +0800, Bin Meng wrote: > Hi Tom, > > This PR includes the following x86 changes for v2021.01 release: > > - Avoid using hardcoded number of variable range MTRRs in mtrr_commit() > - coral: Correct max98357 file > - coral: Update smbios tables to latest definition > > Azure results: PASS > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=300=results > > The following changes since commit 1ae955e3a58f46918ef99b0b6c562967ba1bf39e: > > Prepare v2021.01-rc2 (2020-11-09 17:20:05 -0500) > > are available in the git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-x86 > > for you to fetch changes up to ca010674edb289b1f623e83b4529b6d9ae5e5c0d: > > x86: coral: Update smbios tables to latest definition (2020-11-10 > 09:44:20 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/5] sunxi: enable automatic eMMC boot partition support
On Sun, Nov 08, 2020 at 03:48:23PM +, André Przywara wrote: > On 08/11/2020 14:59, Peter Robinson wrote: > > Hi, > > > On Sun, Nov 8, 2020 at 1:14 PM Andre Przywara > > wrote: > >> > >> The eMMC standard describes the concept of boot partitions, consisting > >> of two storage areas separate from the main user data partition. > >> The Allwinner BootROM supports loading SPL/Boot0 from such a boot > >> partition, if that is configured in the eMMC device [1]. > >> > >> To load U-Boot proper along with the SPL from there, currently this > >> requires to enable CONFIG_SUPPORT_EMMC_BOOT, and this means that this > >> build won't boot from the normal eMMC user partition anymore. > >> Also the raw MMC sector offset needs to be adjusted manually, preventing > >> a boot from an SD card. > >> > >> This series introduces automatic detection of eMMC boot partition boot. > >> Patch 3/5 automates the raw MMC sector offset decision, allowing such > >> a build to also boot from an SD card. > >> Unfortunately the BootROM does not mark an eMMC boot partition boot > >> differently from the normal eMMC user data partition boot, so patch 4/5 > >> introduces a function that repeats the BootROM algorithm, so that the SPL > >> comes to the same conclusion as the BootROM. This allows to build one > >> single image that boots from everywhere: eMMC user data, eMMC boot, > >> SD card, SPI flash. > >> Patch 1/5 contains a bugfix that's needed in a later patch, patch 2/5 > >> extends the generic spl_mmc_boot_mode() interface to make 4/5 feasible. > >> > >> Without enabling CONFIG_SUPPORT_EMMC_BOOT, the AArch64 SPL grows by > >> 92 bytes, ARMv7 grows by 36 bytes. With enabling the feature, the size > >> goes up by 444 bytes (AArch64) and 260 bytes (ARMv7). > >> Even for AArch64 this is still 4.5 KB below the SPL limit, so patch 5/5 > >> enables this new mechanism for some boards I could test this on. > >> > >> Please have a look and test this if you have a board with eMMC. > >> I put installation instructions into the linux-sunxi Wiki: > >> http://linux-sunxi.org/Bootable_eMMC > > > > It would probably be good to put that link in the local Allwinner docs > > so it's easier for people to find. > > Yeah, actually as you mention it: > There does not seem to be some generic README.sunxi file where this > would belong to. > > Jagan: would it make sense to create one, and describe how to get U-Boot > into the devices (SD card, eMMC, SPI flash, FEL)? That could move some > parts of README.sunxi64 out of there, since they apply to all Allwinner > devices. > > If people agree that this is the right thing to do, I would be happy to > send a patch. Well, rST file in doc/boards/ and all of that, but, yes please. -- Tom signature.asc Description: PGP signature
Re: [ANN] U-Boot v2021.01-rc2 released
On Tue, Nov 10, 2020 at 01:18:41PM +0100, Heinrich Schuchardt wrote: > On 11/10/20 1:16 PM, Tom Rini wrote: > > On Tue, Nov 10, 2020 at 01:00:06PM +0100, Heinrich Schuchardt wrote: > > > On 11/10/20 11:41 AM, Andy Shevchenko wrote: > > > > On Tue, Nov 10, 2020 at 12:40 PM Andy Shevchenko > > > > wrote: > > > > > > > > > > On Tue, Nov 10, 2020 at 12:22 AM Tom Rini wrote: > > > > > > > > > > > > Hey all, > > > > > > > > > > > > It's regular release day and I'm back on schedule, so here's -rc2. > > > > > > > > > > > > There's a few small'ish things outstanding in my queue, and a queue > > > > > > of > > > > > > things building up for -next already. I'm going to try and make > > > > > > sure > > > > > > what I pull in, even when a clean-up, is as close as can be to the > > > > > > obviously correct side of things. Yes, this should always be the > > > > > > case, > > > > > > I'm just going to try and hold myself to expectations a bit harder. > > > > > > > > > > > > In terms of a changelog, > > > > > > git log --merges v2021.01-rc1..v2021.01-rc2 > > > > > > contains what I've pulled but as always, better PR messages and tags > > > > > > will provide better results here. > > > > > > > > > > > > I do have my reminders setup for doing -rc releases every other > > > > > > Monday > > > > > > from here on out and final release on January 11th, 2021. Thanks > > > > > > all! > > > > > > > > > > fdt.c is full of > > > > > > > > Correction: all of fdt*.c are full of this kind of compiler warnings > > > > > > > > > scripts/dtc/libfdt/fdt.c: In function ‘fdt_offset_ptr’: > > > > > scripts/dtc/libfdt/fdt.c:137:18: warning: comparison of integer > > > > > expressions of different signedness: ‘unsigned int’ and ‘int’ > > > > > [-Wsign-compare] > > > > >137 | if ((absoffset < offset) > > > > >| ^ > > > > > > > > > > Is it known? Is a fix available? > > > > With what compiler version? > > GCC 10.2 Fun. Is that the only problem we see with GCC 10.2? I'm tempted to say post v2021.01 is when we move to 10.2 being default, assuming the kernel.org toolchains get upgraded by then. For now I guess I need to grab https://patchwork.ozlabs.org/project/uboot/patch/20201016144250.29106-1-andre.przyw...@arm.com/ rather than do a full re-sync. -- Tom signature.asc Description: PGP signature
[PATCH 3/3] fru: common: Record pcie/uuid fields in custom board area
Add additional fields. They will be just recorded and filled but not shown.
Signed-off-by: Michal Simek
---
board/xilinx/common/fru.h | 4
1 file changed, 4 insertions(+)
diff --git a/board/xilinx/common/fru.h b/board/xilinx/common/fru.h
index e85dde45314f..e7284709ddea 100644
--- a/board/xilinx/common/fru.h
+++ b/board/xilinx/common/fru.h
@@ -50,6 +50,10 @@ struct fru_board_data {
/* Xilinx custom fields */
u8 rev_type_len;
u8 rev[FRU_BOARD_MAX_LEN];
+ u8 pcie_type_len;
+ u8 pcie[FRU_BOARD_MAX_LEN];
+ u8 uuid_type_len;
+ u8 uuid[FRU_BOARD_MAX_LEN];
};
struct fru_table {
--
2.29.2
[PATCH 1/3] fru: common: Switch capture variable with the rest
capture variable is bool which is just one byte and it is just causing
unaligned accesses. Better to have it as last entry in the structure.
It also simplify offset calculation for initial header copy.
Signed-off-by: Michal Simek
---
board/xilinx/common/fru.h | 2 +-
board/xilinx/common/fru_ops.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/xilinx/common/fru.h b/board/xilinx/common/fru.h
index a3e652025714..e85dde45314f 100644
--- a/board/xilinx/common/fru.h
+++ b/board/xilinx/common/fru.h
@@ -53,9 +53,9 @@ struct fru_board_data {
};
struct fru_table {
- bool captured;
struct fru_common_hdr hdr;
struct fru_board_data brd;
+ bool captured;
};
#define FRU_TYPELEN_CODE_MASK 0xC0
diff --git a/board/xilinx/common/fru_ops.c b/board/xilinx/common/fru_ops.c
index fc3add7d93da..affcb121aa9c 100644
--- a/board/xilinx/common/fru_ops.c
+++ b/board/xilinx/common/fru_ops.c
@@ -217,7 +217,7 @@ int fru_capture(unsigned long addr)
hdr = (struct fru_common_hdr *)addr;
- memcpy((void *)_data.hdr, (void *)hdr,
+ memcpy((void *)_data, (void *)hdr,
sizeof(struct fru_common_hdr));
fru_data.captured = true;
--
2.29.2
[PATCH 2/3] fru: ops: Do not let parser to write data to not allocated space
If customs fields in board area are used it will likely go over allocated
space in struct fru_board_data. That's why calculate limit of this
structure to make sure that different data is not rewritten by accident.
When limit is reached stop to record fields.
Signed-off-by: Michal Simek
---
board/xilinx/common/fru_ops.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/board/xilinx/common/fru_ops.c b/board/xilinx/common/fru_ops.c
index affcb121aa9c..b4cd3d499885 100644
--- a/board/xilinx/common/fru_ops.c
+++ b/board/xilinx/common/fru_ops.c
@@ -163,12 +163,15 @@ static int fru_parse_board(unsigned long addr)
{
u8 i, type;
int len;
- u8 *data, *term;
+ u8 *data, *term, *limit;
memcpy(_data.brd.ver, (void *)addr, 6);
addr += 6;
data = (u8 *)_data.brd.manufacturer_type_len;
+ /* Record max structure limit not to write data over allocated space */
+ limit = data + sizeof(struct fru_board_data);
+
for (i = 0; ; i++, data += FRU_BOARD_MAX_LEN) {
len = fru_check_type_len(*(u8 *)addr, fru_data.brd.lang_code,
);
@@ -178,6 +181,9 @@ static int fru_parse_board(unsigned long addr)
if (len == -EINVAL)
break;
+ /* Stop when amount of chars is more then fields to record */
+ if (data + len > limit)
+ break;
/* This record type/len field */
*data++ = *(u8 *)addr;
--
2.29.2
[PATCH 0/3] xilinx: fru: Small update and fixes
Hi, I am sending 3 more patches for fru code. Especially the second patch is important because it ensures that data in .data section is not overwritten based on parsed structures. Thanks, Michal Michal Simek (3): fru: common: Switch capture variable with the rest fru: ops: Do not let parser to write data to not allocated space fru: common: Record pcie/uuid fields in custom board area board/xilinx/common/fru.h | 6 +- board/xilinx/common/fru_ops.c | 10 -- 2 files changed, 13 insertions(+), 3 deletions(-) -- 2.29.2
Re: [ANN] U-Boot v2021.01-rc2 released
On 11/10/20 1:16 PM, Tom Rini wrote: On Tue, Nov 10, 2020 at 01:00:06PM +0100, Heinrich Schuchardt wrote: On 11/10/20 11:41 AM, Andy Shevchenko wrote: On Tue, Nov 10, 2020 at 12:40 PM Andy Shevchenko wrote: On Tue, Nov 10, 2020 at 12:22 AM Tom Rini wrote: Hey all, It's regular release day and I'm back on schedule, so here's -rc2. There's a few small'ish things outstanding in my queue, and a queue of things building up for -next already. I'm going to try and make sure what I pull in, even when a clean-up, is as close as can be to the obviously correct side of things. Yes, this should always be the case, I'm just going to try and hold myself to expectations a bit harder. In terms of a changelog, git log --merges v2021.01-rc1..v2021.01-rc2 contains what I've pulled but as always, better PR messages and tags will provide better results here. I do have my reminders setup for doing -rc releases every other Monday from here on out and final release on January 11th, 2021. Thanks all! fdt.c is full of Correction: all of fdt*.c are full of this kind of compiler warnings scripts/dtc/libfdt/fdt.c: In function ‘fdt_offset_ptr’: scripts/dtc/libfdt/fdt.c:137:18: warning: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Wsign-compare] 137 | if ((absoffset < offset) | ^ Is it known? Is a fix available? With what compiler version? GCC 10.2 Yes adjust the integer types. Pease, send patches upstream. This is probably what Andre posted patches for a few weeks ago, and in turn got me to try and work with upstream dtc to come up with a way to deal with the unaligned access safe default load functions that in turn ruin boot times.
[PATCH] arm64: zynqmp: Enable TPM for xilinx platforms
TPMs are becoming popular that's why enable drivers and command for it. Signed-off-by: Michal Simek --- configs/xilinx_zynqmp_virt_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index 0c816de707ac..bac8117c51db 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -57,6 +57,7 @@ CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_TIMER=y +CONFIG_CMD_TPM=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_MTDPARTS=y CONFIG_CMD_MTDPARTS_SPREAD=y @@ -137,6 +138,7 @@ CONFIG_ZYNQ_SERIAL=y CONFIG_SPI=y CONFIG_ZYNQ_SPI=y CONFIG_ZYNQMP_GQSPI=y +CONFIG_TPM2_TIS_SPI=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y @@ -156,5 +158,6 @@ CONFIG_USB_ETHER_ASIX=y CONFIG_WDT=y CONFIG_WDT_CDNS=y CONFIG_PANIC_HANG=y +CONFIG_TPM=y CONFIG_SPL_GZIP=y CONFIG_OF_LIBFDT_OVERLAY=y -- 2.29.2
Re: [ANN] U-Boot v2021.01-rc2 released
On Tue, Nov 10, 2020 at 01:00:06PM +0100, Heinrich Schuchardt wrote: > On 11/10/20 11:41 AM, Andy Shevchenko wrote: > > On Tue, Nov 10, 2020 at 12:40 PM Andy Shevchenko > > wrote: > > > > > > On Tue, Nov 10, 2020 at 12:22 AM Tom Rini wrote: > > > > > > > > Hey all, > > > > > > > > It's regular release day and I'm back on schedule, so here's -rc2. > > > > > > > > There's a few small'ish things outstanding in my queue, and a queue of > > > > things building up for -next already. I'm going to try and make sure > > > > what I pull in, even when a clean-up, is as close as can be to the > > > > obviously correct side of things. Yes, this should always be the case, > > > > I'm just going to try and hold myself to expectations a bit harder. > > > > > > > > In terms of a changelog, > > > > git log --merges v2021.01-rc1..v2021.01-rc2 > > > > contains what I've pulled but as always, better PR messages and tags > > > > will provide better results here. > > > > > > > > I do have my reminders setup for doing -rc releases every other Monday > > > > from here on out and final release on January 11th, 2021. Thanks all! > > > > > > fdt.c is full of > > > > Correction: all of fdt*.c are full of this kind of compiler warnings > > > > > scripts/dtc/libfdt/fdt.c: In function ‘fdt_offset_ptr’: > > > scripts/dtc/libfdt/fdt.c:137:18: warning: comparison of integer > > > expressions of different signedness: ‘unsigned int’ and ‘int’ > > > [-Wsign-compare] > > > 137 | if ((absoffset < offset) > > > | ^ > > > > > > Is it known? Is a fix available? With what compiler version? > Yes adjust the integer types. Pease, send patches upstream. This is probably what Andre posted patches for a few weeks ago, and in turn got me to try and work with upstream dtc to come up with a way to deal with the unaligned access safe default load functions that in turn ruin boot times. -- Tom signature.asc Description: PGP signature
[PATCH] arm64: zynqmp: Get rid of unused macros
There is no reason to have these macros. But record offsets of missing
register in the structure for future use.
Signed-off-by: Michal Simek
---
arch/arm/mach-zynqmp/include/mach/hardware.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-zynqmp/include/mach/hardware.h
b/arch/arm/mach-zynqmp/include/mach/hardware.h
index c5ba42124b04..b328837c694f 100644
--- a/arch/arm/mach-zynqmp/include/mach/hardware.h
+++ b/arch/arm/mach-zynqmp/include/mach/hardware.h
@@ -134,7 +134,8 @@ struct apu_regs {
struct csu_regs {
u32 reserved0[4];
u32 multi_boot;
- u32 reserved1[12];
+ u32 reserved1[11];
+ u32 idcode;
u32 version;
};
@@ -149,7 +150,4 @@ struct pmu_regs {
#define pmu_base ((struct pmu_regs *)ZYNQMP_PMU_BASEADDR)
-#define ZYNQMP_CSU_IDCODE_ADDR 0xFFCA0040
-#define ZYNQMP_CSU_VER_ADDR0xFFCA0044
-
#endif /* _ASM_ARCH_HARDWARE_H */
--
2.29.2
Re: [ANN] U-Boot v2021.01-rc2 released
On 11/10/20 11:41 AM, Andy Shevchenko wrote: On Tue, Nov 10, 2020 at 12:40 PM Andy Shevchenko wrote: On Tue, Nov 10, 2020 at 12:22 AM Tom Rini wrote: Hey all, It's regular release day and I'm back on schedule, so here's -rc2. There's a few small'ish things outstanding in my queue, and a queue of things building up for -next already. I'm going to try and make sure what I pull in, even when a clean-up, is as close as can be to the obviously correct side of things. Yes, this should always be the case, I'm just going to try and hold myself to expectations a bit harder. In terms of a changelog, git log --merges v2021.01-rc1..v2021.01-rc2 contains what I've pulled but as always, better PR messages and tags will provide better results here. I do have my reminders setup for doing -rc releases every other Monday from here on out and final release on January 11th, 2021. Thanks all! fdt.c is full of Correction: all of fdt*.c are full of this kind of compiler warnings scripts/dtc/libfdt/fdt.c: In function ‘fdt_offset_ptr’: scripts/dtc/libfdt/fdt.c:137:18: warning: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Wsign-compare] 137 | if ((absoffset < offset) | ^ Is it known? Is a fix available? Yes adjust the integer types. Pease, send patches upstream. Best regards Heinrich
[BUG] fat_write: crash in set_start_cluster()
I just fixed one bug in EFI_FILE_PROTOCOL.SetInfo(), cf.
[PATCH 1/1] efi_loader: incorrect buffer size in efi_file_setinfo()
https://lists.denx.de/pipermail/u-boot/2020-November/432480.html
With this patch applied when running the UEFI SCT test GetInfoFunction
on sandbox_defconfig on aarch64 a crash occurs in set_start_cluster()
because dentptr is NULL. This happens when trying to create a new file
with a long name in the root directory.
│ 697 /*
│ 698 * Set start cluster in directory entry
│ 699 */
│ 700 static void set_start_cluster(const fsdata *mydata, dir_entry
*dentptr,
│ 701 __u32 start_cluster)
│ 702 {
│ 703 if (mydata->fatsize == 32)
│ 704dentptr->starthi =
│ 705cpu_to_le16((start_cluster & 0x)
>> 16);
│ >706 dentptr->start = cpu_to_le16(start_cluster & 0x);
│ 707 }
Program received signal SIGSEGV, Segmentation fault.
0xaab83418 in fill_dentry (
mydata=,
start_cluster=0,
attr=32 ' ',
size=0,
filename=0x1553f421 "BBTestGetInfoBasicTestCheckpoint3_File_92",
dentptr=0x0)
at fs/fat/fat_write.c:706
(gdb) p dentptr
$1 = (dir_entry *) 0x0
called via
>1195 fill_dentry(itr->fsdata, itr->dent, filename, 0, size, 0x20);
>563 ret = info->write(filename, buf, offset, len, actwrite);
After running only the GetInfoFunctionTest up to the crash the file
system is already heavily corrupted:
Orphaned long file name part "Sct.log"
Orphaned long file name part "verbose.mode"
Orphaned long file name part "[abc123]][()].Aa [b"
Orphaned long file name part "[abc123]][()].Aa [b"
Orphaned long file name part "BBTestGetInfoBasicTestCheckpoint3_File_92"
/BBTestGetInfoBasicTestCheckpoint3_File_0
80 Duplicate directory entries
Orphaned long file name part "TestCase.ini"
Orphaned long file name part "Summary.log"
...
So there seem to be multiple bugs in our FAT file system related to long
file names.
Best regards
Heinrich
[PATCH 1/1] efi_loader: incorrect buffer size in efi_file_setinfo()
When copying a string with must allocate a byte for the terminating '\0' in
the target buffer.
Fixes: fbe4c7df0087 ("efi_loader: enable file SetInfo()")
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index 44fafae058..72b7ec1e63 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -723,7 +723,7 @@ static efi_status_t EFIAPI efi_file_setinfo(struct
efi_file_handle *file,
goto out;
}
/* Check for renaming */
- new_file_name = malloc(utf16_utf8_strlen(info->file_name));
+ new_file_name = malloc(utf16_utf8_strlen(info->file_name) + 1);
if (!new_file_name) {
ret = EFI_OUT_OF_RESOURCES;
goto out;
--
2.28.0
Re: [ANN] U-Boot v2021.01-rc2 released
On Tue, Nov 10, 2020 at 12:40 PM Andy Shevchenko wrote: > > On Tue, Nov 10, 2020 at 12:22 AM Tom Rini wrote: > > > > Hey all, > > > > It's regular release day and I'm back on schedule, so here's -rc2. > > > > There's a few small'ish things outstanding in my queue, and a queue of > > things building up for -next already. I'm going to try and make sure > > what I pull in, even when a clean-up, is as close as can be to the > > obviously correct side of things. Yes, this should always be the case, > > I'm just going to try and hold myself to expectations a bit harder. > > > > In terms of a changelog, > > git log --merges v2021.01-rc1..v2021.01-rc2 > > contains what I've pulled but as always, better PR messages and tags > > will provide better results here. > > > > I do have my reminders setup for doing -rc releases every other Monday > > from here on out and final release on January 11th, 2021. Thanks all! > > fdt.c is full of Correction: all of fdt*.c are full of this kind of compiler warnings > scripts/dtc/libfdt/fdt.c: In function ‘fdt_offset_ptr’: > scripts/dtc/libfdt/fdt.c:137:18: warning: comparison of integer > expressions of different signedness: ‘unsigned int’ and ‘int’ > [-Wsign-compare] > 137 | if ((absoffset < offset) > | ^ > > Is it known? Is a fix available? -- With Best Regards, Andy Shevchenko
Re: [ANN] U-Boot v2021.01-rc2 released
On Tue, Nov 10, 2020 at 12:22 AM Tom Rini wrote: > > Hey all, > > It's regular release day and I'm back on schedule, so here's -rc2. > > There's a few small'ish things outstanding in my queue, and a queue of > things building up for -next already. I'm going to try and make sure > what I pull in, even when a clean-up, is as close as can be to the > obviously correct side of things. Yes, this should always be the case, > I'm just going to try and hold myself to expectations a bit harder. > > In terms of a changelog, > git log --merges v2021.01-rc1..v2021.01-rc2 > contains what I've pulled but as always, better PR messages and tags > will provide better results here. > > I do have my reminders setup for doing -rc releases every other Monday > from here on out and final release on January 11th, 2021. Thanks all! fdt.c is full of scripts/dtc/libfdt/fdt.c: In function ‘fdt_offset_ptr’: scripts/dtc/libfdt/fdt.c:137:18: warning: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘int’ [-Wsign-compare] 137 | if ((absoffset < offset) | ^ Is it known? Is fix available? -- With Best Regards, Andy Shevchenko
[PATCH] rockchip: Pinebook Pro: Fix USB
Improve USB config so keyboard and USB-A ports work. Signed-off-by: Peter Robinson --- configs/pinebook-pro-rk3399_defconfig | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/configs/pinebook-pro-rk3399_defconfig b/configs/pinebook-pro-rk3399_defconfig index 1ed54ad0ed..8fbd7280ac 100644 --- a/configs/pinebook-pro-rk3399_defconfig +++ b/configs/pinebook-pro-rk3399_defconfig @@ -55,6 +55,8 @@ CONFIG_SPI_FLASH_WINBOND=y CONFIG_DM_ETH=y CONFIG_NVME=y CONFIG_PCI=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y +CONFIG_PHY_ROCKCHIP_TYPEC=y CONFIG_DM_PMIC_FAN53555=y CONFIG_PMIC_RK8XX=y CONFIG_REGULATOR_PWM=y @@ -76,8 +78,9 @@ CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_DWC3=y -CONFIG_ROCKCHIP_USB2_PHY=y +CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_KEYBOARD=y +CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_RTL8152=y -- 2.28.0
RE: [PATCH] usb: xhci: fix event trb handling missed
Hi Bin,
On Tuesday, November 10, 2020 5:47 PM Bin Meng wrote:
>
> Hi Ran,
>
> On Tue, Nov 10, 2020 at 5:41 PM Ran Wang wrote:
> >
> > Hi Bin,
> >
> > On Tuesday, November 10, 2020 5:03 PM Bin Meng wrote:
> > >
> > > Hi Ran,
> > >
> > > On Tue, Nov 10, 2020 at 4:31 PM Ran Wang
> wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > On Tuesday, November 10, 2020 4:06 PM Ran Wang wrote:
> > > > > Hi Bin,
> >
> >
> >
> > > >
> > >
> > > Based on your log, it matches what I suspected and we are getting
> > > close to the root cause.
> > >
> > > Could you please try the following simple test case to see if it can
> > > trigger the issue with a USB disk?
> > > After U-Boot boot on LS1028, with a USB flash disk attached, then
> > > type "usb start" to see if the USB disk can be recognized by U-Boot?
> > >
> > > commit 60e68ed667362870c20b36ae26dacc1af903e81e
> > > Author: Bin Meng
> > > Date: Tue Nov 10 16:19:06 2020 +0800
> > >
> > > WIP: usb: A simple test case to trigger the TRB 64K boundary
> > > issue with mass storage device
> > >
> > > This should not be applied as it aims to provide a simple test case to
> > > trigger the TRB 64K boundary issue as reported by Ran Wang @ NXP.
> > >
> > > Signed-off-by: Bin Meng
> > >
> > > diff --git a/common/usb_storage.c b/common/usb_storage.c index
> > > ff25441..c8aec2e 100644
> > > --- a/common/usb_storage.c
> > > +++ b/common/usb_storage.c
> > > @@ -710,7 +710,15 @@ static int usb_stor_BBB_transport(struct
> > > scsi_cmd *srb, struct us_data *us)
> > > int dir_in;
> > > int actlen, data_actlen;
> > > unsigned int pipe, pipein, pipeout;
> > > +#if 0
> > > ALLOC_CACHE_ALIGN_BUFFER(struct umass_bbb_csw, csw, 1);
> > > +#else
> > > + struct umass_bbb_csw *csw_org, *csw;
> > > + csw_org = malloc(0x1 + UMASS_BBB_CSW_SIZE);
> > > + csw = (struct umass_bbb_csw *)roundup((ulong)csw_org,
> 0x1);
> > > + csw = (struct umass_bbb_csw *)((ulong)csw - 2);
> > > + printf("csw org %p, adjusted to %p\n", csw_org, csw); #endif
> > > #ifdef BBB_XPORT_TRACE
> > > unsigned char *ptr;
> > > int index;
> > > @@ -824,6 +832,7 @@ again:
> > > return USB_STOR_TRANSPORT_FAILED;
> > > }
> > >
> > > + free(csw_org);
> > > return result;
> > > }
> > >
> >
> > Issue cannot be reproduced on mass storage device with above hacking:
>
> Thank you for the testing.
>
> > =>
> > resetting USB...
> > Bus usb3@310: Register 200017f NbrPorts 2 Starting the controller
> > USB XHCI 1.00 Bus usb3@311: Register 200017f NbrPorts 2 Starting
> > the controller USB XHCI 1.00 scanning bus usb3@310 for devices...
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 13
> > record_transfer_result():comp_code: 13
> > record_transfer_result():comp_code: 13
> > record_transfer_result():comp_code: 13
> > record_transfer_result():comp_code: 1
> > csw org fbb53010, adjusted to fbb5fffe
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > csw org fbb53010, adjusted to fbb5fffe
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > csw org fbb53010, adjusted to fbb5fffe
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > 2 USB Device(s) found
> > scanning bus usb3@311 for devices... 1 USB Device(s) found
> >scanning usb for storage devices... 1 Storage Device(s) found
> > =>
> >
> > One more thing I'd like to tell is that I found this issue would not
> > happened
> with 'usb start' (even with USB dongle).
> >
> > Below is the log I tested with ' usb read 0x8200 0 30', issue
> > could not be reproduced for at least 10 minutes ...
> > csw org fbb4ec90, adjusted to fbb4fffe
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > csw org fbb4ec90, adjusted to fbb4fffe
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > csw org fbb4ec90, adjusted to fbb4fffe
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > csw org fbb4ec90, adjusted to fbb4fffe
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > csw org fbb4ec90, adjusted to fbb4fffe
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > record_transfer_result():comp_code: 1
> > csw org fbb4ec90,
Re: [PATCH] usb: xhci: fix event trb handling missed
Hi Ran,
On Tue, Nov 10, 2020 at 5:41 PM Ran Wang wrote:
>
> Hi Bin,
>
> On Tuesday, November 10, 2020 5:03 PM Bin Meng wrote:
> >
> > Hi Ran,
> >
> > On Tue, Nov 10, 2020 at 4:31 PM Ran Wang wrote:
> > >
> > > Hi Bin,
> > >
> > > On Tuesday, November 10, 2020 4:06 PM Ran Wang wrote:
> > > > Hi Bin,
>
>
>
> > >
> >
> > Based on your log, it matches what I suspected and we are getting close to
> > the
> > root cause.
> >
> > Could you please try the following simple test case to see if it can
> > trigger the
> > issue with a USB disk?
> > After U-Boot boot on LS1028, with a USB flash disk attached, then type "usb
> > start" to see if the USB disk can be recognized by U-Boot?
> >
> > commit 60e68ed667362870c20b36ae26dacc1af903e81e
> > Author: Bin Meng
> > Date: Tue Nov 10 16:19:06 2020 +0800
> >
> > WIP: usb: A simple test case to trigger the TRB 64K boundary issue with
> > mass storage device
> >
> > This should not be applied as it aims to provide a simple test case to
> > trigger the TRB 64K boundary issue as reported by Ran Wang @ NXP.
> >
> > Signed-off-by: Bin Meng
> >
> > diff --git a/common/usb_storage.c b/common/usb_storage.c index
> > ff25441..c8aec2e 100644
> > --- a/common/usb_storage.c
> > +++ b/common/usb_storage.c
> > @@ -710,7 +710,15 @@ static int usb_stor_BBB_transport(struct scsi_cmd
> > *srb, struct us_data *us)
> > int dir_in;
> > int actlen, data_actlen;
> > unsigned int pipe, pipein, pipeout;
> > +#if 0
> > ALLOC_CACHE_ALIGN_BUFFER(struct umass_bbb_csw, csw, 1);
> > +#else
> > + struct umass_bbb_csw *csw_org, *csw;
> > + csw_org = malloc(0x1 + UMASS_BBB_CSW_SIZE);
> > + csw = (struct umass_bbb_csw *)roundup((ulong)csw_org, 0x1);
> > + csw = (struct umass_bbb_csw *)((ulong)csw - 2);
> > + printf("csw org %p, adjusted to %p\n", csw_org, csw); #endif
> > #ifdef BBB_XPORT_TRACE
> > unsigned char *ptr;
> > int index;
> > @@ -824,6 +832,7 @@ again:
> > return USB_STOR_TRANSPORT_FAILED;
> > }
> >
> > + free(csw_org);
> > return result;
> > }
> >
>
> Issue cannot be reproduced on mass storage device with above hacking:
Thank you for the testing.
> =>
> resetting USB...
> Bus usb3@310: Register 200017f NbrPorts 2
> Starting the controller
> USB XHCI 1.00
> Bus usb3@311: Register 200017f NbrPorts 2
> Starting the controller
> USB XHCI 1.00
> scanning bus usb3@310 for devices... record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 13
> record_transfer_result():comp_code: 13
> record_transfer_result():comp_code: 13
> record_transfer_result():comp_code: 13
> record_transfer_result():comp_code: 1
> csw org fbb53010, adjusted to fbb5fffe
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> csw org fbb53010, adjusted to fbb5fffe
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> csw org fbb53010, adjusted to fbb5fffe
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> 2 USB Device(s) found
> scanning bus usb3@311 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
> =>
>
> One more thing I'd like to tell is that I found this issue would not happened
> with 'usb start' (even with USB dongle).
>
> Below is the log I tested with ' usb read 0x8200 0 30', issue could
> not be reproduced for at least 10 minutes
> ...
> csw org fbb4ec90, adjusted to fbb4fffe
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> csw org fbb4ec90, adjusted to fbb4fffe
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> csw org fbb4ec90, adjusted to fbb4fffe
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> csw org fbb4ec90, adjusted to fbb4fffe
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> csw org fbb4ec90, adjusted to fbb4fffe
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> csw org fbb4ec90, adjusted to fbb4fffe
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
> csw org fbb4ec90, adjusted to fbb4fffe
> record_transfer_result():comp_code: 1
> record_transfer_result():comp_code: 1
>
RE: [PATCH] usb: xhci: fix event trb handling missed
Hi Bin,
On Tuesday, November 10, 2020 5:03 PM Bin Meng wrote:
>
> Hi Ran,
>
> On Tue, Nov 10, 2020 at 4:31 PM Ran Wang wrote:
> >
> > Hi Bin,
> >
> > On Tuesday, November 10, 2020 4:06 PM Ran Wang wrote:
> > > Hi Bin,
> >
>
> Based on your log, it matches what I suspected and we are getting close to the
> root cause.
>
> Could you please try the following simple test case to see if it can trigger
> the
> issue with a USB disk?
> After U-Boot boot on LS1028, with a USB flash disk attached, then type "usb
> start" to see if the USB disk can be recognized by U-Boot?
>
> commit 60e68ed667362870c20b36ae26dacc1af903e81e
> Author: Bin Meng
> Date: Tue Nov 10 16:19:06 2020 +0800
>
> WIP: usb: A simple test case to trigger the TRB 64K boundary issue with
> mass storage device
>
> This should not be applied as it aims to provide a simple test case to
> trigger the TRB 64K boundary issue as reported by Ran Wang @ NXP.
>
> Signed-off-by: Bin Meng
>
> diff --git a/common/usb_storage.c b/common/usb_storage.c index
> ff25441..c8aec2e 100644
> --- a/common/usb_storage.c
> +++ b/common/usb_storage.c
> @@ -710,7 +710,15 @@ static int usb_stor_BBB_transport(struct scsi_cmd
> *srb, struct us_data *us)
> int dir_in;
> int actlen, data_actlen;
> unsigned int pipe, pipein, pipeout;
> +#if 0
> ALLOC_CACHE_ALIGN_BUFFER(struct umass_bbb_csw, csw, 1);
> +#else
> + struct umass_bbb_csw *csw_org, *csw;
> + csw_org = malloc(0x1 + UMASS_BBB_CSW_SIZE);
> + csw = (struct umass_bbb_csw *)roundup((ulong)csw_org, 0x1);
> + csw = (struct umass_bbb_csw *)((ulong)csw - 2);
> + printf("csw org %p, adjusted to %p\n", csw_org, csw); #endif
> #ifdef BBB_XPORT_TRACE
> unsigned char *ptr;
> int index;
> @@ -824,6 +832,7 @@ again:
> return USB_STOR_TRANSPORT_FAILED;
> }
>
> + free(csw_org);
> return result;
> }
>
Issue cannot be reproduced on mass storage device with above hacking:
=>
resetting USB...
Bus usb3@310: Register 200017f NbrPorts 2
Starting the controller
USB XHCI 1.00
Bus usb3@311: Register 200017f NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus usb3@310 for devices... record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 13
record_transfer_result():comp_code: 13
record_transfer_result():comp_code: 13
record_transfer_result():comp_code: 13
record_transfer_result():comp_code: 1
csw org fbb53010, adjusted to fbb5fffe
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
csw org fbb53010, adjusted to fbb5fffe
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
csw org fbb53010, adjusted to fbb5fffe
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
2 USB Device(s) found
scanning bus usb3@311 for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
=>
One more thing I'd like to tell is that I found this issue would not happened
with 'usb start' (even with USB dongle).
Below is the log I tested with ' usb read 0x8200 0 30', issue could not
be reproduced for at least 10 minutes
...
csw org fbb4ec90, adjusted to fbb4fffe
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
csw org fbb4ec90, adjusted to fbb4fffe
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
csw org fbb4ec90, adjusted to fbb4fffe
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
csw org fbb4ec90, adjusted to fbb4fffe
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
csw org fbb4ec90, adjusted to fbb4fffe
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
csw org fbb4ec90, adjusted to fbb4fffe
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
csw org fbb4ec90, adjusted to fbb4fffe
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
csw org fbb4ec90, adjusted to fbb4fffe
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
csw org fbb4ec90, adjusted to fbb4fffe
record_transfer_result():comp_code: 1
record_transfer_result():comp_code: 1
record_transfer_result():comp_code:
Re: [PATCH] mmc: meson_gx_mmc: control ddr_mode bit
> From: Jaehoon Chung > Date: Tue, 10 Nov 2020 18:02:02 +0900 > > On 11/10/20 5:50 PM, Mark Kettenis wrote: > >> From: Neil Armstrong > >> Date: Tue, 10 Nov 2020 09:15:14 +0100 > >> > >> On 10/11/2020 08:50, Jaehoon Chung wrote: > >>> EMMC_CFG register has a cfg_ddr bit(BIT[2]). > >>> It needs to set when mmc is running to ddr mode. > >>> Otherwise, its bit should be cleared. > >>> CFG_DDR[2] - 1: DDR mode, 0: SDR mode > >>> > >>> Signed-off-by: Jaehoon Chung > >>> --- > >>> arch/arm/include/asm/arch-meson/sd_emmc.h | 1 + > >>> drivers/mmc/meson_gx_mmc.c| 5 + > >>> 2 files changed, 6 insertions(+) > >>> > >>> diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h > >>> b/arch/arm/include/asm/arch-meson/sd_emmc.h > >>> index 1e9f8cf498b4..c2f77c7308ec 100644 > >>> --- a/arch/arm/include/asm/arch-meson/sd_emmc.h > >>> +++ b/arch/arm/include/asm/arch-meson/sd_emmc.h > >>> @@ -38,6 +38,7 @@ > >>> #define CFG_BUS_WIDTH_10 > >>> #define CFG_BUS_WIDTH_41 > >>> #define CFG_BUS_WIDTH_82 > >>> +#define CFG_DDR_MODE BIT(2) > >>> #define CFG_BL_LEN_MASKGENMASK(7, 4) > >>> #define CFG_BL_LEN_SHIFT 4 > >>> #define CFG_BL_LEN_512 (9 << 4) > >>> diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c > >>> index 7c60e0566560..6fcf6c2ced27 100644 > >>> --- a/drivers/mmc/meson_gx_mmc.c > >>> +++ b/drivers/mmc/meson_gx_mmc.c > >>> @@ -90,6 +90,11 @@ static int meson_dm_mmc_set_ios(struct udevice *dev) > >>> else > >>> return -EINVAL; > >>> > >>> + if (mmc->ddr_mode) > >>> + meson_mmc_cfg |= CFG_DDR_MODE; > >>> + else > >>> + meson_mmc_cfg &= ~CFG_DDR_MODE; > >>> + > >>> /* 512 bytes block length */ > >>> meson_mmc_cfg &= ~CFG_BL_LEN_MASK; > >>> meson_mmc_cfg |= CFG_BL_LEN_512; > >>> > >> > >> Interesting, how did it work without this bit ? > > > > Well, in meson_mmc_probe() we have: > > > > cfg->host_caps = MMC_MODE_8BIT | MMC_MODE_4BIT | > > MMC_MODE_HS_52MHz | MMC_MODE_HS; > > > > So the driver doesn't advertise DDR support. > > Right. I added some patch in my local for testing. > > Actually, those is wrong. If want to follow linux driver, it needs to remove. > Instead, it has to use mmc_of_parse() for dt's property. > > I will send patch after more test. Note that you also need to double the clock frequency for DDR modes. This isn't done automatically like on other SoCs.
[PATCH 26/26] configs: j7200_evm_r5: Enable raw access power management features
From: Dave Gerlach Sysfw is not going to provide access to power management features in the new architecture, so SPL must implement these itself. Enable all the raw register access based clock + power domain drivers. Signed-off-by: Dave Gerlach --- configs/j7200_evm_r5_defconfig | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/configs/j7200_evm_r5_defconfig b/configs/j7200_evm_r5_defconfig index 3820fc508b..19ba12e89f 100644 --- a/configs/j7200_evm_r5_defconfig +++ b/configs/j7200_evm_r5_defconfig @@ -75,7 +75,7 @@ CONFIG_SPL_SYSCON=y CONFIG_SPL_OF_TRANSLATE=y CONFIG_CLK=y CONFIG_SPL_CLK=y -CONFIG_CLK_TI_SCI=y +# CONFIG_CLK_TI_SCI is not set CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y @@ -110,7 +110,7 @@ CONFIG_SPL_PINCTRL=y # CONFIG_SPL_PINCTRL_GENERIC is not set CONFIG_PINCTRL_SINGLE=y CONFIG_POWER_DOMAIN=y -CONFIG_TI_SCI_POWER_DOMAIN=y +# CONFIG_TI_SCI_POWER_DOMAIN is not set CONFIG_K3_SYSTEM_CONTROLLER=y CONFIG_REMOTEPROC_TI_K3_ARM64=y CONFIG_DM_RESET=y @@ -142,3 +142,12 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x6164 CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_FS_EXT4=y CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 +CONFIG_SOC_DEVICE=y +CONFIG_SOC_DEVICE_TI_K3=y +CONFIG_TI_POWER_DOMAIN=y +CONFIG_SPL_CLK_CCF=y +CONFIG_LIB_RATIONAL=y +CONFIG_SPL_LIB_RATIONAL=y +CONFIG_SPL_CLK_K3_PLL=y +CONFIG_SPL_CLK_K3=y +CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y -- 2.17.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 23/26] configs: j721e_evm_r5: Enable raw access power management features
Sysfw is not going to provide access to power management features in the new architecture, so SPL must implement these itself. Enable all the raw register access based clock + power domain drivers. Signed-off-by: Tero Kristo --- configs/j721e_evm_r5_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig index 4128548100..514867635c 100644 --- a/configs/j721e_evm_r5_defconfig +++ b/configs/j721e_evm_r5_defconfig @@ -140,3 +140,9 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x6163 CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_FS_EXT4=y CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 +CONFIG_TI_POWER_DOMAIN=y +CONFIG_SPL_CLK_CCF=y +CONFIG_LIB_RATIONAL=y +CONFIG_SPL_LIB_RATIONAL=y +CONFIG_SPL_CLK_K3_PLL=y +CONFIG_SPL_CLK_K3=y -- 2.17.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 22/26] arm: mach-k3: sysfw-loader: pass boardcfg to sciserver
Copy the contents of the board config loaded from sysfw.itb into an
EXTBOOT shared memory buffer that gets passed to sciserver. This only
needs to be done if EXTBOOT area has not been populated by ROM code yet.
Signed-off-by: Tero Kristo
---
arch/arm/mach-k3/sysfw-loader.c | 98 +
1 file changed, 98 insertions(+)
diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
index 154d2df049..c20b601848 100644
--- a/arch/arm/mach-k3/sysfw-loader.c
+++ b/arch/arm/mach-k3/sysfw-loader.c
@@ -39,6 +39,43 @@ DECLARE_GLOBAL_DATA_PTR;
*/
#define K3_SYSTEM_CONTROLLER_RPROC_ID 0
+#define BOARDCFG_ADDRESS 0x41c8
+
+#define COMP_TYPE_SBL_DATA 0x11
+#define DESC_TYPE_BOARDCFG_PM_INDEX0x2
+#define DESC_TYPE_BOARDCFG_RM_INDEX0x3
+
+#define BOARD_CONFIG_RM_DESC_TYPE 0x000c
+#define BOARD_CONFIG_PM_DESC_TYPE 0x000e
+
+struct extboot_comp {
+ u32 comp_type;
+ u32 boot_core;
+ u32 comp_opts;
+ u64 dest_addr;
+ u32 comp_size;
+} __packed;
+
+struct extboot_header {
+ u8 magic[8];
+ u32 num_comps;
+ struct extboot_comp comps[5];
+} __packed;
+
+struct bcfg_desc {
+ u16 type;
+ u16 offset;
+ u16 size;
+ u8 devgrp;
+ u8 reserved;
+} __packed;
+
+struct bcfg_header {
+ u8 num_elems;
+ u8 sw_rev;
+ struct bcfg_desc descs[4];
+} __packed;
+
static bool sysfw_loaded;
static void *sysfw_load_address;
@@ -130,6 +167,15 @@ static void k3_sysfw_configure_using_fit(void *fit,
const void *cfg_fragment_addr;
size_t cfg_fragment_size;
int ret;
+#ifndef CONFIG_CLK_TI_SCI
+ u8 *buf;
+ struct extboot_header *common_header;
+ struct bcfg_header *bcfg_header;
+ struct extboot_comp *comp;
+ struct bcfg_desc *desc;
+ u32 addr;
+ bool copy_bcfg = false;
+#endif
/* Find the node holding the images information */
images = fdt_path_offset(fit, FIT_IMAGES_PATH);
@@ -164,6 +210,46 @@ static void k3_sysfw_configure_using_fit(void *fit,
(u32)cfg_fragment_size);
if (ret)
panic("Failed to set board PM configuration (%d)\n", ret);
+#else
+ /* Initialize shared memory boardconfig buffer */
+ buf = (u8 *)BOARDCFG_ADDRESS;
+ common_header = (struct extboot_header *)buf;
+
+ /* Check if we have a struct populated by ROM in memory already */
+ if (strcmp((char *)common_header->magic, "EXTBOOT"))
+ copy_bcfg = true;
+
+ if (copy_bcfg) {
+ strcpy((char *)common_header->magic, "EXTBOOT");
+ common_header->num_comps = 1;
+
+ comp = _header->comps[0];
+
+ comp->comp_type = COMP_TYPE_SBL_DATA;
+ comp->boot_core = 0x10;
+ comp->comp_opts = 0;
+ addr = (u32)buf + sizeof(*common_header);
+ comp->dest_addr = addr;
+ comp->comp_size = sizeof(*bcfg_header);
+
+ bcfg_header = (struct bcfg_header *)addr;
+
+ bcfg_header->num_elems = 2;
+ bcfg_header->sw_rev = 0;
+
+ desc = _header->descs[0];
+
+ desc->type = BOARD_CONFIG_PM_DESC_TYPE;
+ desc->offset = sizeof(*bcfg_header);
+ desc->size = cfg_fragment_size;
+ comp->comp_size += desc->size;
+ desc->devgrp = 0;
+ desc->reserved = 0;
+ memcpy((u8 *)bcfg_header + desc->offset, cfg_fragment_addr,
+ cfg_fragment_size);
+
+ bcfg_header->descs[1].offset = desc->offset + desc->size;
+ }
#endif
/* Extract resource management (RM) specific configuration from FIT */
@@ -180,6 +266,18 @@ static void k3_sysfw_configure_using_fit(void *fit,
(u32)cfg_fragment_size);
if (ret)
panic("Failed to set board RM configuration (%d)\n", ret);
+#else
+ if (copy_bcfg) {
+ desc = _header->descs[1];
+
+ desc->type = BOARD_CONFIG_RM_DESC_TYPE;
+ desc->size = cfg_fragment_size;
+ comp->comp_size += desc->size;
+ desc->devgrp = 0;
+ desc->reserved = 0;
+ memcpy((u8 *)bcfg_header + desc->offset, cfg_fragment_addr,
+ cfg_fragment_size);
+ }
#endif
/* Extract security specific configuration from FIT */
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 25/26] configs: j721e_evm_r5: enable FIT image post processing
This is used to parse the images from FIT, and to determine image types. Signed-off-by: Tero Kristo --- configs/j721e_evm_r5_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig index 62586b2f3b..f2c047f8e8 100644 --- a/configs/j721e_evm_r5_defconfig +++ b/configs/j721e_evm_r5_defconfig @@ -146,3 +146,4 @@ CONFIG_LIB_RATIONAL=y CONFIG_SPL_LIB_RATIONAL=y CONFIG_SPL_CLK_K3_PLL=y CONFIG_SPL_CLK_K3=y +CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y -- 2.17.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 24/26] configs: j721e_evm_r5: disable SCI PM drivers
With the sysfw rearch, PM services are no longer available for R5 SPL to use. Instead, we will be using the raw PM register level access drivers for any PM. Thus, disable the SCI PM drivers to reflect this. Signed-off-by: Tero Kristo --- configs/j721e_evm_r5_defconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig index 514867635c..62586b2f3b 100644 --- a/configs/j721e_evm_r5_defconfig +++ b/configs/j721e_evm_r5_defconfig @@ -72,7 +72,7 @@ CONFIG_SPL_REGMAP=y CONFIG_SPL_OF_TRANSLATE=y CONFIG_CLK=y CONFIG_SPL_CLK=y -CONFIG_CLK_TI_SCI=y +# CONFIG_CLK_TI_SCI is not set CONFIG_DMA_CHANNELS=y CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y @@ -102,7 +102,7 @@ CONFIG_SPL_PINCTRL=y # CONFIG_SPL_PINCTRL_GENERIC is not set CONFIG_PINCTRL_SINGLE=y CONFIG_POWER_DOMAIN=y -CONFIG_TI_SCI_POWER_DOMAIN=y +# CONFIG_TI_SCI_POWER_DOMAIN is not set CONFIG_DM_PMIC=y CONFIG_PMIC_TPS65941=y CONFIG_DM_REGULATOR=y -- 2.17.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 17/26] arm: mach-k3: Add platform data for j721e and j7200
From: Dave Gerlach
Add platform clock and powerdomain data for J721e and J7200. This data
is used by the corresponding drivers to register all the required device
clocks and powerdomains.
Signed-off-by: Dave Gerlach
---
arch/arm/mach-k3/Makefile | 2 +-
arch/arm/mach-k3/j7200/Makefile | 5 +
arch/arm/mach-k3/j7200/clk-data.c | 232 ++
arch/arm/mach-k3/j7200/dev-data.c | 71
arch/arm/mach-k3/j721e/Makefile | 5 +
arch/arm/mach-k3/j721e/clk-data.c | 259 ++
arch/arm/mach-k3/j721e/dev-data.c | 67
7 files changed, 640 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-k3/j7200/Makefile
create mode 100644 arch/arm/mach-k3/j7200/clk-data.c
create mode 100644 arch/arm/mach-k3/j7200/dev-data.c
create mode 100644 arch/arm/mach-k3/j721e/Makefile
create mode 100644 arch/arm/mach-k3/j721e/clk-data.c
create mode 100644 arch/arm/mach-k3/j721e/dev-data.c
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 7572f56925..534ddfcd49 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -4,7 +4,7 @@
# Lokesh Vutla
obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
-obj-$(CONFIG_SOC_K3_J721E) += j721e_init.o
+obj-$(CONFIG_SOC_K3_J721E) += j721e_init.o j721e/ j7200/
obj-$(CONFIG_ARM64) += arm64-mmu.o
obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
diff --git a/arch/arm/mach-k3/j7200/Makefile b/arch/arm/mach-k3/j7200/Makefile
new file mode 100644
index 00..ff9abd78ea
--- /dev/null
+++ b/arch/arm/mach-k3/j7200/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+obj-y += clk-data.o
+obj-y += dev-data.o
diff --git a/arch/arm/mach-k3/j7200/clk-data.c
b/arch/arm/mach-k3/j7200/clk-data.c
new file mode 100644
index 00..f5bdbdd55e
--- /dev/null
+++ b/arch/arm/mach-k3/j7200/clk-data.c
@@ -0,0 +1,232 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * J7200 specific clock platform data
+ *
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+ */
+#include "k3-clk.h"
+
+static const char * const gluelogic_hfosc0_clkout_parents[] = {
+ "osc_19_2_mhz",
+ "osc_20_mhz",
+ "osc_24_mhz",
+ "osc_25_mhz",
+ "osc_26_mhz",
+ "osc_27_mhz",
+};
+
+static const char * const main_pll_hfosc_sel_out1_parents[] = {
+ "gluelogic_hfosc0_clkout",
+};
+
+static const char * const mcu_ospi0_iclk_sel_out0_parents[] = {
+ "fss_mcu_0_ospi_0_ospi_oclk_clk",
+};
+
+static const char * const wkup_fref_clksel_out0_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "j7vc_wakeup_16ff_wkup_0_wkup_rcosc_12p5m_clk",
+};
+
+static const char * const k3_pll_ctrl_wrap_wkup_0_sysclkout_clk_parents[] = {
+ "wkup_fref_clksel_out0",
+ "hsdiv1_16fft_mcu_0_hsdivout0_clk",
+};
+
+static const char * const mcu_ospi_ref_clk_sel_out0_parents[] = {
+ "hsdiv4_16fft_mcu_1_hsdivout4_clk",
+ "hsdiv4_16fft_mcu_2_hsdivout4_clk",
+};
+
+static const char * const mcuusart_clk_sel_out0_parents[] = {
+ "hsdiv4_16fft_mcu_1_hsdivout3_clk",
+ "postdiv2_16fft_main_1_hsdivout5_clk",
+};
+
+static const char * const wkup_i2c0_mcupll_bypass_clksel_out0_parents[] = {
+ "hsdiv4_16fft_mcu_1_hsdivout3_clk",
+ "gluelogic_hfosc0_clkout",
+};
+
+static const char * const main_pll_hfosc_sel_out0_parents[] = {
+ "gluelogic_hfosc0_clkout",
+};
+
+static const char * const main_pll_hfosc_sel_out12_parents[] = {
+ "gluelogic_hfosc0_clkout",
+};
+
+static const char * const main_pll_hfosc_sel_out3_parents[] = {
+ "gluelogic_hfosc0_clkout",
+};
+
+static const char * const main_pll_hfosc_sel_out7_parents[] = {
+ "gluelogic_hfosc0_clkout",
+};
+
+static const char * const main_pll_hfosc_sel_out8_parents[] = {
+ "gluelogic_hfosc0_clkout",
+};
+
+static const char * const k3_pll_ctrl_wrap_main_0_sysclkout_clk_parents[] = {
+ "main_pll_hfosc_sel_out0",
+ "hsdiv4_16fft_main_0_hsdivout0_clk",
+};
+
+static const char * const emmcsd_refclk_sel_out0_parents[] = {
+ "hsdiv4_16fft_main_0_hsdivout2_clk",
+ "hsdiv4_16fft_main_1_hsdivout2_clk",
+ "hsdiv4_16fft_main_3_hsdivout2_clk",
+ "hsdiv4_16fft_main_3_hsdivout2_clk",
+};
+
+static const char * const emmcsd_refclk_sel_out1_parents[] = {
+ "hsdiv4_16fft_main_0_hsdivout2_clk",
+ "hsdiv4_16fft_main_1_hsdivout2_clk",
+ "hsdiv4_16fft_main_3_hsdivout2_clk",
+ "hsdiv4_16fft_main_3_hsdivout2_clk",
+};
+
+static const char * const gtc_clk_mux_out0_parents[] = {
+ "hsdiv4_16fft_main_3_hsdivout1_clk",
+ "postdiv2_16fft_main_0_hsdivout6_clk",
+ "hsdiv4_16fft_mcu_2_hsdivout1_clk",
+ "k3_pll_ctrl_wrap_main_0_chip_div1_clk_clk",
+};
+
+static const struct clk_data clk_list[] = {
+ CLK_FIXED_RATE("osc_27_mhz", 2700, 0),
+
[PATCH 18/26] arm: mach-k3: add support for detecting firmware images from FIT
Add callback routines for parsing the firmware info from FIT image, and
use the data to boot up ATF and the MCU R5 firmware.
Signed-off-by: Tero Kristo
---
arch/arm/mach-k3/common.c | 80 +
arch/arm/mach-k3/common.h | 1 +
arch/arm/mach-k3/security.c | 3 +-
3 files changed, 75 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 8c903f14ff..418d053610 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -27,6 +27,27 @@
#include
#include
+#ifdef CONFIG_SYS_K3_SPL_ATF
+enum {
+ IMAGE_ID_ATF,
+ IMAGE_ID_OPTEE,
+ IMAGE_ID_SPL,
+ IMAGE_ID_DM_FW,
+ IMAGE_AMT,
+};
+
+#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
+static const char *image_os_match[IMAGE_AMT] = {
+ "arm-trusted-firmware",
+ "tee",
+ "U-Boot",
+ "DM",
+};
+#endif
+
+static struct image_info fit_image_info[IMAGE_AMT];
+#endif
+
struct ti_sci_handle *get_ti_sci_handle(void)
{
struct udevice *dev;
@@ -180,7 +201,7 @@ void __noreturn jump_to_image_no_args(struct spl_image_info
*spl_image)
typedef void __noreturn (*image_entry_noargs_t)(void);
struct ti_sci_handle *ti_sci = get_ti_sci_handle();
u32 loadaddr = 0;
- int ret, size;
+ int ret, size = 0;
/* Release all the exclusive devices held by SPL before starting ATF */
ti_sci->ops.dev_ops.release_exclusive_devices(ti_sci);
@@ -191,15 +212,20 @@ void __noreturn jump_to_image_no_args(struct
spl_image_info *spl_image)
init_env();
start_non_linux_remote_cores();
- size = load_firmware("name_mcur5f0_0fw", "addr_mcur5f0_0load",
-);
+ if (!fit_image_info[IMAGE_ID_DM_FW].image_start)
+ size = load_firmware("name_mcur5f0_0fw", "addr_mcur5f0_0load",
+);
/*
* It is assumed that remoteproc device 1 is the corresponding
* Cortex-A core which runs ATF. Make sure DT reflects the same.
*/
- ret = rproc_load(1, spl_image->entry_point, 0x200);
+ if (!fit_image_info[IMAGE_ID_ATF].image_start)
+ fit_image_info[IMAGE_ID_ATF].image_start =
+ spl_image->entry_point;
+
+ ret = rproc_load(1, fit_image_info[IMAGE_ID_ATF].image_start, 0x200);
if (ret)
panic("%s: ATF failed to load on rproc (%d)\n", __func__, ret);
@@ -209,7 +235,8 @@ void __noreturn jump_to_image_no_args(struct spl_image_info
*spl_image)
ret = rproc_start(1);
if (ret)
panic("%s: ATF failed to start on rproc (%d)\n", __func__, ret);
- if (!(size > 0 && valid_elf_image(loadaddr))) {
+ if (!fit_image_info[IMAGE_ID_DM_FW].image_len &&
+ !(size > 0 && valid_elf_image(loadaddr))) {
debug("Shutting down...\n");
release_resources_for_core_shutdown();
@@ -217,13 +244,52 @@ void __noreturn jump_to_image_no_args(struct
spl_image_info *spl_image)
asm volatile("wfe");
}
- image_entry_noargs_t image_entry =
- (image_entry_noargs_t)load_elf_image_phdr(loadaddr);
+ if (!fit_image_info[IMAGE_ID_DM_FW].image_start) {
+ loadaddr = load_elf_image_phdr(loadaddr);
+ } else {
+ loadaddr = fit_image_info[IMAGE_ID_DM_FW].image_start;
+ if (valid_elf_image(loadaddr))
+ loadaddr = load_elf_image_phdr(loadaddr);
+ }
+
+ debug("%s: jumping to address %x\n", __func__, loadaddr);
+
+ image_entry_noargs_t image_entry = (image_entry_noargs_t)loadaddr;
image_entry();
}
#endif
+#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
+void board_fit_image_post_process(const void *fit, int node, void **p_image,
+ size_t *p_size)
+{
+ int len;
+ int i;
+ const char *os;
+ u32 addr;
+
+ os = fdt_getprop(fit, node, "os", );
+ addr = fdt_getprop_u32_default_node(fit, node, 0, "entry", -1);
+
+ debug("%s: processing image: addr=%x, size=%d, os=%s\n", __func__,
+ addr, *p_size, os);
+
+ for (i = 0; i < IMAGE_AMT; i++) {
+ if (!strcmp(os, image_os_match[i])) {
+ fit_image_info[i].image_start = addr;
+ fit_image_info[i].image_len = *p_size;
+ debug("%s: matched image for ID %d\n", __func__, i);
+ break;
+ }
+ }
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+ ti_secure_image_post_process(p_image, p_size);
+#endif
+}
+#endif
+
#if defined(CONFIG_OF_LIBFDT)
int fdt_fixup_msmc_ram(void *blob, char *parent_path, char *node_name)
{
diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
index a6dbc7808b..f421ed1bb1 100644
--- a/arch/arm/mach-k3/common.h
+++ b/arch/arm/mach-k3/common.h
@@ -28,3 +28,4 @@
[PATCH 21/26] arm: mach-k3: common: Drop main r5 start
From: Dave Gerlach
Only start-up the non-linux remote cores if we are running in legacy
boot mode. HSM rearch is not yet supporting this.
Signed-off-by: Dave Gerlach
---
arch/arm/mach-k3/common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 418d053610..5582ea6d7e 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -211,7 +211,9 @@ void __noreturn jump_to_image_no_args(struct spl_image_info
*spl_image)
panic("rproc failed to be initialized (%d)\n", ret);
init_env();
+#ifdef CONFIG_CLK_TI_SCI
start_non_linux_remote_cores();
+#endif
if (!fit_image_info[IMAGE_ID_DM_FW].image_start)
size = load_firmware("name_mcur5f0_0fw", "addr_mcur5f0_0load",
);
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 11/26] clk: fix set_rate to clean up cached rates for the hierarchy
Clock rates are cached within the individual clock nodes, and right now
if one changes a clock rate somewhere in the middle of the tree, none
of its child clocks notice the change. To fix this, clear up all the
cached rates for us and our child clocks.
Signed-off-by: Tero Kristo
---
drivers/clk/clk-uclass.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 79d5af3d1f..9a5c061304 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -544,6 +544,22 @@ long long clk_get_parent_rate(struct clk *clk)
return pclk->rate;
}
+static void clk_clean_rate_cache(struct clk *clk)
+{
+ struct udevice *child_dev;
+ struct clk *clkp;
+
+ if (!clk)
+ return;
+
+ clk->rate = 0;
+
+ list_for_each_entry(child_dev, >dev->child_head, sibling_node) {
+ clkp = dev_get_clk_ptr(child_dev);
+ clk_clean_rate_cache(clkp);
+ }
+}
+
ulong clk_set_rate(struct clk *clk, ulong rate)
{
const struct clk_ops *ops;
@@ -556,6 +572,9 @@ ulong clk_set_rate(struct clk *clk, ulong rate)
if (!ops->set_rate)
return -ENOSYS;
+ /* Clean up cached rates for us and all child clocks */
+ clk_clean_rate_cache(clk);
+
return ops->set_rate(clk, rate);
}
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 19/26] arm: mach-k3: j721e: force enable A72 core 0 during spl shutdown
With the new raw register mode access PM drivers, A72 core is not
enabled via ti-sci services, leading into bad usecounts for the core.
This effectively shuts down the A72 core when SPL goes down. Prevent the
problem by force enabling the A72 core once, which increases the use
count.
Signed-off-by: Tero Kristo
---
arch/arm/mach-k3/j721e_init.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index a36e4ed603..d00a9477a2 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -306,6 +306,7 @@ u32 spl_boot_device(void)
#ifdef CONFIG_SYS_K3_SPL_ATF
+#define J721E_DEV_A72SS0_CORE0 202
#define J721E_DEV_MCU_RTI0 262
#define J721E_DEV_MCU_RTI1 263
#define J721E_DEV_MCU_ARMSS0_CPU0 250
@@ -324,10 +325,23 @@ void release_resources_for_core_shutdown(void)
J721E_DEV_MCU_RTI1,
};
+ const u32 get_device_ids[] = {
+ J721E_DEV_A72SS0_CORE0
+ };
+
ti_sci = get_ti_sci_handle();
dev_ops = _sci->ops.dev_ops;
proc_ops = _sci->ops.proc_ops;
+ /* Iterate through list of devices to get (enable) */
+ for (i = 0; i < ARRAY_SIZE(get_device_ids); i++) {
+ u32 id = get_device_ids[i];
+
+ ret = dev_ops->get_device(ti_sci, id);
+ if (ret)
+ panic("Failed to get device %u (%d)\n", id, ret);
+ }
+
/* Iterate through list of devices to put (shutdown) */
for (i = 0; i < ARRAY_SIZE(put_device_ids); i++) {
u32 id = put_device_ids[i];
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 20/26] arm: mach-k3: do board config for PM and RM only if supported
If the raw PM support is built in, we are operating in the split
firmware approach mode where RM and PM support is not available. In this
case, skip the board config for these two.
Signed-off-by: Tero Kristo
---
arch/arm/mach-k3/sysfw-loader.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
index 78c158c63f..154d2df049 100644
--- a/arch/arm/mach-k3/sysfw-loader.c
+++ b/arch/arm/mach-k3/sysfw-loader.c
@@ -158,11 +158,13 @@ static void k3_sysfw_configure_using_fit(void *fit,
ret);
/* Apply power/clock (PM) specific configuration to SYSFW */
+#ifdef CONFIG_CLK_TI_SCI
ret = board_ops->board_config_pm(ti_sci,
(u64)(u32)cfg_fragment_addr,
(u32)cfg_fragment_size);
if (ret)
panic("Failed to set board PM configuration (%d)\n", ret);
+#endif
/* Extract resource management (RM) specific configuration from FIT */
ret = fit_get_data_by_name(fit, images, SYSFW_CFG_RM,
@@ -171,12 +173,14 @@ static void k3_sysfw_configure_using_fit(void *fit,
panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_RM,
ret);
+#ifdef CONFIG_CLK_TI_SCI
/* Apply resource management (RM) configuration to SYSFW */
ret = board_ops->board_config_rm(ti_sci,
(u64)(u32)cfg_fragment_addr,
(u32)cfg_fragment_size);
if (ret)
panic("Failed to set board RM configuration (%d)\n", ret);
+#endif
/* Extract security specific configuration from FIT */
ret = fit_get_data_by_name(fit, images, SYSFW_CFG_SEC,
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 16/26] tools: k3_fit_atf: add DM binary to the FIT image
Add DM (device manager) firmware image to the fit image that is loaded by
R5 SPL. This is needed with the HSM rearch where the firmware allocation
has been changed slightly.
Signed-off-by: Tero Kristo
---
arch/arm/mach-k3/config.mk | 4
tools/k3_fit_atf.sh| 19 ++-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
index 41fee2b5a1..503ece4520 100644
--- a/arch/arm/mach-k3/config.mk
+++ b/arch/arm/mach-k3/config.mk
@@ -49,6 +49,10 @@ endif
ifdef CONFIG_ARM64
+ifeq ($(CONFIG_SOC_K3_J721E),)
+export DM := /dev/null
+endif
+
ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
SPL_ITS := u-boot-spl-k3_HS.its
$(SPL_ITS): export IS_HS=1
diff --git a/tools/k3_fit_atf.sh b/tools/k3_fit_atf.sh
index 4e9f69c087..c0940a2fcc 100755
--- a/tools/k3_fit_atf.sh
+++ b/tools/k3_fit_atf.sh
@@ -21,6 +21,13 @@ if [ ! -f $TEE ]; then
TEE=/dev/null
fi
+[ -z "$DM" ] && DM="dm.bin"
+
+if [ ! -e $DM ]; then
+ echo "WARNING DM file $DM NOT found, resulting might be non-functional"
>&2
+ DM=/dev/null
+fi
+
if [ ! -z "$IS_HS" ]; then
HS_APPEND=_HS
fi
@@ -53,6 +60,16 @@ cat << __HEADER_EOF
load = <0x9e80>;
entry = <0x9e80>;
};
+ dm {
+ description = "DM binary";
+ data = /incbin/("$DM");
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "DM";
+ load = <0xa000>;
+ entry = <0xa000>;
+ };
spl {
description = "SPL (64-bit)";
data = /incbin/("spl/u-boot-spl-nodtb.bin$HS_APPEND");
@@ -91,7 +108,7 @@ do
$(basename $dtname) {
description = "$(basename $dtname .dtb)";
firmware = "atf";
- loadables = "tee", "spl";
+ loadables = "tee", "dm", "spl";
fdt = "$(basename $dtname)";
};
__CONF_SECTION_EOF
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 14/26] power: domain: Introduce driver for raw TI K3 PDs
Normally, power domains are handled via TI-SCI in K3 SoCs. However,
SPL is not going to have access to sysfw resources, so it must control
them directly. Add driver for supporting this.
Signed-off-by: Tero Kristo
---
drivers/power/domain/Kconfig | 7 +
drivers/power/domain/Makefile | 1 +
drivers/power/domain/ti-power-domain.c | 377 +
include/k3-dev.h | 76 +
4 files changed, 461 insertions(+)
create mode 100644 drivers/power/domain/ti-power-domain.c
create mode 100644 include/k3-dev.h
diff --git a/drivers/power/domain/Kconfig b/drivers/power/domain/Kconfig
index a0fd980752..b03a82d82c 100644
--- a/drivers/power/domain/Kconfig
+++ b/drivers/power/domain/Kconfig
@@ -72,4 +72,11 @@ config TI_SCI_POWER_DOMAIN
help
Generic power domain implementation for TI devices implementing the
TI SCI protocol.
+
+config TI_POWER_DOMAIN
+ bool "Enable the TI K3 Power domain driver"
+ depends on POWER_DOMAIN
+ help
+ Generic power domain implementation for TI K3 devices.
+
endmenu
diff --git a/drivers/power/domain/Makefile b/drivers/power/domain/Makefile
index 45bf9f6383..3d1e5f073c 100644
--- a/drivers/power/domain/Makefile
+++ b/drivers/power/domain/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_SANDBOX_POWER_DOMAIN) += sandbox-power-domain.o
obj-$(CONFIG_SANDBOX_POWER_DOMAIN) += sandbox-power-domain-test.o
obj-$(CONFIG_TEGRA186_POWER_DOMAIN) += tegra186-power-domain.o
obj-$(CONFIG_TI_SCI_POWER_DOMAIN) += ti-sci-power-domain.o
+obj-$(CONFIG_TI_POWER_DOMAIN) += ti-power-domain.o
diff --git a/drivers/power/domain/ti-power-domain.c
b/drivers/power/domain/ti-power-domain.c
new file mode 100644
index 00..a2d8983540
--- /dev/null
+++ b/drivers/power/domain/ti-power-domain.c
@@ -0,0 +1,377 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments power domain driver
+ *
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+ * Tero Kristo
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PSC_PTCMD 0x120
+#define PSC_PTSTAT 0x128
+#define PSC_PDSTAT 0x200
+#define PSC_PDCTL 0x300
+#define PSC_MDSTAT 0x800
+#define PSC_MDCTL 0xa00
+
+#define PDCTL_STATE_MASK 0x1
+#define PDCTL_STATE_OFF0x0
+#define PDCTL_STATE_ON 0x1
+
+#define MDSTAT_STATE_MASK 0x3f
+#define MDSTAT_BUSY_MASK 0x30
+#define MDSTAT_STATE_SWRSTDISABLE 0x0
+#define MDSTAT_STATE_ENABLE0x3
+
+#define LPSC_TIMEOUT 10
+#define PD_TIMEOUT 10
+
+static u32 psc_read(struct ti_psc *psc, u32 reg)
+{
+ u32 val;
+
+ val = readl(psc->base + reg);
+ debug("%s: 0x%x from %p\n", __func__, val, psc->base + reg);
+ return val;
+}
+
+static void psc_write(u32 val, struct ti_psc *psc, u32 reg)
+{
+ debug("%s: 0x%x to %p\n", __func__, val, psc->base + reg);
+ writel(val, psc->base + reg);
+}
+
+static u32 pd_read(struct ti_pd *pd, u32 reg)
+{
+ return psc_read(pd->psc, reg + 4 * pd->id);
+}
+
+static void pd_write(u32 val, struct ti_pd *pd, u32 reg)
+{
+ psc_write(val, pd->psc, reg + 4 * pd->id);
+}
+
+static u32 lpsc_read(struct ti_lpsc *lpsc, u32 reg)
+{
+ return psc_read(lpsc->psc, reg + 4 * lpsc->id);
+}
+
+static void lpsc_write(u32 val, struct ti_lpsc *lpsc, u32 reg)
+{
+ psc_write(val, lpsc->psc, reg + 4 * lpsc->id);
+}
+
+static const struct soc_attr ti_k3_soc_pd_data[] = {
+#ifdef CONFIG_SOC_K3_J721E
+ {
+ .family = "J721E",
+ .data = _pd_platdata,
+ },
+ {
+ .family = "J7200",
+ .data = _pd_platdata,
+ },
+#endif
+ { /* sentinel */ }
+};
+
+static int ti_power_domain_probe(struct udevice *dev)
+{
+ struct ti_k3_pd_platdata *data = dev_get_priv(dev);
+ const struct soc_attr *soc_match_data;
+ const struct ti_k3_pd_platdata *pdata;
+
+ printf("%s(dev=%p)\n", __func__, dev);
+
+ if (!data)
+ return -ENOMEM;
+
+ soc_match_data = soc_device_match(ti_k3_soc_pd_data);
+ if (!soc_match_data)
+ return -ENODEV;
+
+ pdata = (const struct ti_k3_pd_platdata *)soc_match_data->data;
+
+ data->psc = pdata->psc;
+ data->pd = pdata->pd;
+ data->lpsc = pdata->lpsc;
+ data->devs = pdata->devs;
+ data->num_psc = pdata->num_psc;
+ data->num_pd = pdata->num_pd;
+ data->num_lpsc = pdata->num_lpsc;
+ data->num_devs = pdata->num_devs;
+
+ return 0;
+}
+
+static int ti_pd_wait(struct ti_pd *pd)
+{
+ u32 ptstat;
+ int i = PD_TIMEOUT;
+
+ while (i) {
+ ptstat = psc_read(pd->psc, PSC_PTSTAT);
+ if (!(ptstat & BIT(pd->id)))
+ return 0;
+
[PATCH 15/26] cmd: ti: pd: Add debug command for K3 power domains
Add support command for debugging K3 power domains. This is useful with
the HSM rearch setup, where power domains are directly controlled by SPL
instead of going through the TI SCI layer. The debugging support is only
available in the u-boot codebase though, so the raw register access
power domain layer must be enabled on u-boot side for this to work. By
default, u-boot side uses the TI SCI layer, and R5 SPL only uses the
direct access methods.
Signed-off-by: Tero Kristo
---
cmd/ti/Kconfig | 8 ++
cmd/ti/Makefile| 1 +
cmd/ti/pd.c| 185 +
drivers/power/domain/ti-power-domain.c | 6 +-
include/k3-dev.h | 9 ++
5 files changed, 206 insertions(+), 3 deletions(-)
create mode 100644 cmd/ti/pd.c
diff --git a/cmd/ti/Kconfig b/cmd/ti/Kconfig
index efeff0d482..db557445a8 100644
--- a/cmd/ti/Kconfig
+++ b/cmd/ti/Kconfig
@@ -7,4 +7,12 @@ config CMD_DDR3
supports memory verification, memory comapre and ecc
verification if supported.
+config CMD_PD
+ bool "command for verifying power domains"
+ depends on TI_POWER_DOMAIN
+ help
+ Debug command for K3 power domains. For this to work, the
+ K3 power domain driver must be enabled for the u-boot; by
+ default it is only enabled for SPL.
+
endmenu
diff --git a/cmd/ti/Makefile b/cmd/ti/Makefile
index 16fbade9ed..045593396b 100644
--- a/cmd/ti/Makefile
+++ b/cmd/ti/Makefile
@@ -5,4 +5,5 @@ obj- += dummy.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_CMD_DDR3) += ddr3.o
+obj-$(CONFIG_CMD_PD) += pd.o
endif
diff --git a/cmd/ti/pd.c b/cmd/ti/pd.c
new file mode 100644
index 00..a53ccdcc40
--- /dev/null
+++ b/cmd/ti/pd.c
@@ -0,0 +1,185 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Power Domain test commands
+ *
+ * Copyright (C) 2020 Texas Instruments Incorporated,
+ */
+
+#include
+#include
+#include
+#include
+
+static const struct udevice_id ti_pd_of_match[] = {
+ { .compatible = "ti,sci-pm-domain" },
+ { /* sentinel */ }
+};
+
+static struct ti_k3_pd_platdata *ti_pd_find_data(void)
+{
+ struct udevice *dev;
+ int i = 0;
+
+ while (1) {
+ uclass_get_device(UCLASS_POWER_DOMAIN, i++, );
+ if (!dev)
+ return NULL;
+
+ if (device_is_compatible(dev,
+ti_pd_of_match[0].compatible))
+ return dev_get_priv(dev);
+ }
+
+ return NULL;
+}
+
+static void dump_lpsc(struct ti_k3_pd_platdata *data, struct ti_pd *pd)
+{
+ int i;
+ struct ti_lpsc *lpsc;
+ u8 state;
+ static const char * const lpsc_states[] = {
+ "swrstdis", "syncrst", "disable", "enable", "autosleep",
+ "autowake", "unknown",
+ };
+
+ for (i = 0; i < data->num_lpsc; i++) {
+ lpsc = >lpsc[i];
+ if (lpsc->pd != pd)
+ continue;
+ state = lpsc_get_state(lpsc);
+ if (state > ARRAY_SIZE(lpsc_states))
+ state = ARRAY_SIZE(lpsc_states) - 1;
+ printf("LPSC%d: state=%s, usecount=%d\n",
+ lpsc->id, lpsc_states[state], lpsc->usecount);
+ }
+}
+
+static void dump_pd(struct ti_k3_pd_platdata *data, struct ti_psc *psc)
+{
+ int i;
+ struct ti_pd *pd;
+ u8 state;
+ static const char * const pd_states[] = {
+ "off", "on", "unknown"
+ };
+
+ for (i = 0; i < data->num_pd; i++) {
+ pd = >pd[i];
+ if (pd->psc != psc)
+ continue;
+ state = ti_pd_state(pd);
+ if (state > ARRAY_SIZE(pd_states))
+ state = ARRAY_SIZE(pd_states) - 1;
+ printf(" PD%d: state=%s, usecount=%d:\n",
+ pd->id, pd_states[state], pd->usecount);
+ dump_lpsc(data, pd);
+ }
+}
+
+static void dump_psc(struct ti_k3_pd_platdata *data)
+{
+ int i;
+ struct ti_psc *psc;
+
+ for (i = 0; i < data->num_psc; i++) {
+ psc = >psc[i];
+ printf("PSC%d [%p]:\n", psc->id, psc->base);
+ dump_pd(data, psc);
+ }
+}
+
+static int do_pd_dump(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct ti_k3_pd_platdata *data;
+
+ data = ti_pd_find_data();
+ if (!data)
+ return CMD_RET_FAILURE;
+
+ dump_psc(data);
+
+ return 0;
+}
+
+static int do_pd_endis(int argc, char *const argv[], u8 state)
+{
+ u32 psc_id;
+ u32 lpsc_id;
+ int i;
+ struct ti_k3_pd_platdata *data;
+ struct ti_lpsc *lpsc;
+ int ret;
+
+ if (argc < 3)
+ return CMD_RET_FAILURE;
+
+ data = ti_pd_find_data();
+ if (!data)
+
[PATCH 13/26] clk: add support for TI K3 SoC clocks
Add driver to support TI K3 generation SoC clocks. This driver registers
the clocks provided via platform data, and adds support for controlling
the clocks via DT handles.
Signed-off-by: Tero Kristo
---
drivers/clk/Kconfig | 10 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-k3.c | 340 +++
include/k3-clk.h | 162 +
4 files changed, 513 insertions(+)
create mode 100644 drivers/clk/clk-k3.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index b2e9458f85..003a28f7ac 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -106,6 +106,16 @@ config CLK_TI_SCI
available on some new TI's SoCs. If you wish to use clock resources
managed by the TI System Controller, say Y here. Otherwise, say N.
+config CLK_K3
+ bool "Clock support for K3 SoC family of devices"
+ depends on CLK
+ help
+ Enables the clock translation layer from DT to device clocks.
+
+config SPL_CLK_K3
+ bool "Clock support for K3 SoC family of devices"
+ depends on CLK && SPL
+
config CLK_K3_PLL
bool "PLL clock support for K3 SoC family of devices"
depends on CLK && LIB_RATIONAL
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 6009eab800..2f0cb80cb9 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -49,5 +49,6 @@ obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o
obj-$(CONFIG_STM32H7) += clk_stm32h7.o
obj-$(CONFIG_CLK_TI_SCI) += clk-ti-sci.o
obj-$(CONFIG_$(SPL_TPL_)CLK_K3_PLL) += clk-k3-pll.o
+obj-$(CONFIG_$(SPL_TPL_)CLK_K3) += clk-k3.o
obj-$(CONFIG_CLK_VERSAL) += clk_versal.o
obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o
diff --git a/drivers/clk/clk-k3.c b/drivers/clk/clk-k3.c
new file mode 100644
index 00..f0392aad5d
--- /dev/null
+++ b/drivers/clk/clk-k3.c
@@ -0,0 +1,340 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments K3 clock driver
+ *
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+ * Tero Kristo
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "k3-clk.h"
+
+#define PLL_MIN_FREQ 8
+#define PLL_MAX_FREQ 32UL
+
+/**
+ * struct clk_map - mapping from dev/clk id tuples towards physical clocks
+ * @dev_id: device ID for the clock
+ * @clk_id: clock ID for the clock
+ * @clk: pointer to the registered clock entry for the mapping
+ */
+struct clk_map {
+ u16 dev_id;
+ u32 clk_id;
+ struct clk *clk;
+};
+
+/**
+ * struct ti_clk_data - clock controller information structure
+ * @map: mapping from dev/clk id tuples to physical clock entries
+ * @size: number of entries in the map
+ */
+struct ti_clk_data {
+ struct clk_map *map;
+ int size;
+};
+
+static ulong osc_freq;
+
+static void clk_add_map(struct ti_clk_data *data, struct clk *clk,
+ u32 dev_id, u32 clk_id)
+{
+ struct clk_map *map;
+
+ debug("%s: added clk=%p, data=%p, dev=%d, clk=%d\n", __func__,
+ clk, data, dev_id, clk_id);
+ if (!clk)
+ return;
+
+ map = data->map + data->size++;
+
+ map->dev_id = dev_id;
+ map->clk_id = clk_id;
+ map->clk = clk;
+}
+
+static const struct soc_attr ti_k3_soc_clk_data[] = {
+#ifdef CONFIG_SOC_K3_J721E
+ {
+ .family = "J721E",
+ .data = _clk_platdata,
+ },
+ {
+ .family = "J7200",
+ .data = _clk_platdata,
+ },
+#endif
+ { /* sentinel */ }
+};
+
+static int ti_clk_probe(struct udevice *dev)
+{
+ struct ti_clk_data *data = dev_get_priv(dev);
+ struct clk *clk;
+ const char *name;
+ const struct clk_data *ti_clk_data;
+ int i, j;
+ const struct soc_attr *soc_match_data;
+ const struct ti_k3_clk_platdata *pdata;
+
+ debug("%s(dev=%p)\n", __func__, dev);
+
+ soc_match_data = soc_device_match(ti_k3_soc_clk_data);
+ if (!soc_match_data)
+ return -ENODEV;
+
+ pdata = (const struct ti_k3_clk_platdata *)soc_match_data->data;
+
+ data->map = kcalloc(pdata->soc_dev_clk_data_cnt, sizeof(*data->map),
+ GFP_KERNEL);
+ data->size = 0;
+
+ for (i = 0; i < pdata->clk_list_cnt; i++) {
+ ti_clk_data = >clk_list[i];
+
+ switch (ti_clk_data->type) {
+ case CLK_TYPE_FIXED_RATE:
+ name = ti_clk_data->clk.fixed_rate.name;
+ clk = clk_register_fixed_rate(NULL,
+ name,
+
ti_clk_data->clk.fixed_rate.rate);
+ break;
+ case CLK_TYPE_DIV:
+ name = ti_clk_data->clk.div.name;
+ clk = clk_register_divider(NULL, name,
+ ti_clk_data->clk.div.parent,
+
[PATCH 10/26] clk: fix assigned-clocks to pass with deferring provider
If a clock provider is not ready for assigning default rates/parents
during its probe, it may return -EPROBE_DEFER directly from xlate.
Handle this special case properly by skipping the entry and adjusting the
return value to pass. The defaults will be handled properly in post probe
phase then.
Signed-off-by: Tero Kristo
---
drivers/clk/clk-uclass.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index a4b24b98e6..79d5af3d1f 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -239,6 +239,15 @@ static int clk_set_default_parents(struct udevice *dev,
int stage)
ret = clk_get_by_indexed_prop(dev, "assigned-clocks",
index, );
+ /*
+* If the clock provider is not ready yet, let it handle
+* the re-programming later.
+*/
+ if (ret == -EPROBE_DEFER) {
+ ret = 0;
+ continue;
+ }
+
if (ret) {
debug("%s: could not get assigned clock %d for %s\n",
__func__, index, dev_read_name(dev));
@@ -307,6 +316,15 @@ static int clk_set_default_rates(struct udevice *dev, int
stage)
ret = clk_get_by_indexed_prop(dev, "assigned-clocks",
index, );
+ /*
+* If the clock provider is not ready yet, let it handle
+* the re-programming later.
+*/
+ if (ret == -EPROBE_DEFER) {
+ ret = 0;
+ continue;
+ }
+
if (ret) {
debug("%s: could not get assigned clock %d for %s\n",
__func__, index, dev_read_name(dev));
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 08/26] clk: add support for setting clk rate from cmdline
Add new clk subcommand "clk setfreq", for setting up a clock rate
directly from u-boot cmdline. This is handy for any debugging purposes
towards clocks.
Signed-off-by: Tero Kristo
---
cmd/clk.c | 49 +++--
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git a/cmd/clk.c b/cmd/clk.c
index 0245b97136..fd7944c02e 100644
--- a/cmd/clk.c
+++ b/cmd/clk.c
@@ -98,8 +98,52 @@ static int do_clk_dump(struct cmd_tbl *cmdtp, int flag, int
argc,
return ret;
}
+struct udevice *clk_lookup(const char *name)
+{
+ int i = 0;
+ struct udevice *dev;
+
+ do {
+ uclass_get_device(UCLASS_CLK, i++, );
+ if (!strcmp(name, dev->name))
+ return dev;
+ } while (dev);
+
+ return NULL;
+}
+
+static int do_clk_setfreq(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct clk *clk = NULL;
+ s32 freq;
+ struct udevice *dev;
+
+ freq = simple_strtoul(argv[2], NULL, 10);
+
+ dev = clk_lookup(argv[1]);
+
+ if (dev)
+ clk = dev_get_clk_ptr(dev);
+
+ if (!clk) {
+ printf("clock '%s' not found.\n", argv[1]);
+ return -EINVAL;
+ }
+
+ freq = clk_set_rate(clk, freq);
+ if (freq < 0) {
+ printf("set_rate failed: %d\n", freq);
+ return CMD_RET_FAILURE;
+ }
+
+ printf("set_rate returns %u\n", freq);
+ return 0;
+}
+
static struct cmd_tbl cmd_clk_sub[] = {
U_BOOT_CMD_MKENT(dump, 1, 1, do_clk_dump, "", ""),
+ U_BOOT_CMD_MKENT(setfreq, 3, 1, do_clk_setfreq, "", ""),
};
static int do_clk(struct cmd_tbl *cmdtp, int flag, int argc,
@@ -124,7 +168,8 @@ static int do_clk(struct cmd_tbl *cmdtp, int flag, int argc,
#ifdef CONFIG_SYS_LONGHELP
static char clk_help_text[] =
- "dump - Print clock frequencies";
+ "dump - Print clock frequencies\n"
+ "setfreq [clk] [freq] - Set clock frequency";
#endif
-U_BOOT_CMD(clk, 2, 1, do_clk, "CLK sub-system", clk_help_text);
+U_BOOT_CMD(clk, 4, 1, do_clk, "CLK sub-system", clk_help_text);
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 12/26] clk: add support for TI K3 SoC PLL
Add support for TI K3 SoC PLLs. This clock type supports
enabling/disabling/setting and querying the clock rate for the PLL. The
euclidean library routine is used to calculate divider/multiplier rates
for the PLLs.
Signed-off-by: Tero Kristo
---
drivers/clk/Kconfig | 12 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-k3-pll.c | 273 +++
include/k3-clk.h | 15 +++
4 files changed, 301 insertions(+)
create mode 100644 drivers/clk/clk-k3-pll.c
create mode 100644 include/k3-clk.h
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 4dfbad7986..b2e9458f85 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -106,6 +106,18 @@ config CLK_TI_SCI
available on some new TI's SoCs. If you wish to use clock resources
managed by the TI System Controller, say Y here. Otherwise, say N.
+config CLK_K3_PLL
+ bool "PLL clock support for K3 SoC family of devices"
+ depends on CLK && LIB_RATIONAL
+ help
+ Enables PLL clock support for K3 SoC family of devices.
+
+config SPL_CLK_K3_PLL
+ bool "PLL clock support for K3 SoC family of devices"
+ depends on CLK && LIB_RATIONAL && SPL
+ help
+ Enables PLL clock support for K3 SoC family of devices.
+
config CLK_HSDK
bool "Enable cgu clock driver for HSDK boards"
depends on CLK && TARGET_HSDK
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d1e295ac7c..6009eab800 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -48,5 +48,6 @@ obj-$(CONFIG_SANDBOX) += clk_sandbox_test.o
obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o
obj-$(CONFIG_STM32H7) += clk_stm32h7.o
obj-$(CONFIG_CLK_TI_SCI) += clk-ti-sci.o
+obj-$(CONFIG_$(SPL_TPL_)CLK_K3_PLL) += clk-k3-pll.o
obj-$(CONFIG_CLK_VERSAL) += clk_versal.o
obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o
diff --git a/drivers/clk/clk-k3-pll.c b/drivers/clk/clk-k3-pll.c
new file mode 100644
index 00..2240f13c7a
--- /dev/null
+++ b/drivers/clk/clk-k3-pll.c
@@ -0,0 +1,273 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments K3 SoC PLL clock driver
+ *
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+ * Tero Kristo
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "k3-clk.h"
+#include
+
+/* 16FFT register offsets */
+#define PLL_16FFT_CFG 0x08
+#define PLL_KICK0 0x10
+#define PLL_KICK1 0x14
+#define PLL_16FFT_CTRL 0x20
+#define PLL_16FFT_STAT 0x24
+#define PLL_16FFT_FREQ_CTRL0 0x30
+#define PLL_16FFT_FREQ_CTRL1 0x34
+#define PLL_16FFT_DIV_CTRL 0x38
+
+/* CTRL register bits */
+#define PLL_16FFT_CTRL_BYPASS_EN BIT(31)
+#define PLL_16FFT_CTRL_PLL_EN BIT(15)
+#define PLL_16FFT_CTRL_DSM_EN BIT(1)
+
+/* STAT register bits */
+#define PLL_16FFT_STAT_LOCKBIT(0)
+
+/* FREQ_CTRL0 bits */
+#define PLL_16FFT_FREQ_CTRL0_FB_DIV_INT_MASK 0xfff
+
+/* DIV CTRL register bits */
+#define PLL_16FFT_DIV_CTRL_REF_DIV_MASK0x3f
+
+#define PLL_16FFT_FREQ_CTRL1_FB_DIV_FRAC_BITS 24
+#define PLL_16FFT_HSDIV_CTRL_CLKOUT_EN BIT(15)
+
+/* KICK register magic values */
+#define PLL_KICK0_VALUE0x68ef3490
+#define PLL_KICK1_VALUE0xd172bc5a
+
+/**
+ * struct ti_pll_clk - TI PLL clock data info structure
+ * @clk: core clock structure
+ * @reg: memory address of the PLL controller
+ */
+struct ti_pll_clk {
+ struct clk clk;
+ void __iomem*reg;
+};
+
+#define to_clk_pll(_clk) container_of(_clk, struct ti_pll_clk, clk)
+
+static int ti_pll_wait_for_lock(struct clk *clk)
+{
+ struct ti_pll_clk *pll = to_clk_pll(clk);
+ u32 stat;
+ int i;
+
+ for (i = 0; i < 10; i++) {
+ stat = readl(pll->reg + PLL_16FFT_STAT);
+ if (stat & PLL_16FFT_STAT_LOCK)
+ return 0;
+ }
+
+ printf("%s: pll (%s) failed to lock\n", __func__,
+ clk->dev->name);
+
+ return -EBUSY;
+}
+
+static ulong ti_pll_clk_get_rate(struct clk *clk)
+{
+ struct ti_pll_clk *pll = to_clk_pll(clk);
+ u64 current_freq;
+ u64 parent_freq = clk_get_parent_rate(clk);
+ u32 pllm;
+ u32 plld;
+ u32 pllfm;
+ u32 ctrl;
+
+ /* Check if we are in bypass */
+ ctrl = readl(pll->reg + PLL_16FFT_CTRL);
+ if (ctrl & PLL_16FFT_CTRL_BYPASS_EN)
+ return parent_freq;
+
+ pllm = readl(pll->reg + PLL_16FFT_FREQ_CTRL0);
+ pllfm = readl(pll->reg + PLL_16FFT_FREQ_CTRL1);
+
+ plld = readl(pll->reg + PLL_16FFT_DIV_CTRL) &
+ PLL_16FFT_DIV_CTRL_REF_DIV_MASK;
+
+ current_freq = parent_freq * pllm / plld;
+
+ if (pllfm) {
+ u64 tmp;
+
+ tmp = parent_freq *
[PATCH 06/26] clk: fix clock tree dump to properly dump out every registered clock
Some clocks are not associated to a DM node, so just parsing the DM is not
enough. This is especially true for root clocks, which typically don't have
any parents. Instead, fetch every registered UCLASS_CLK instance, and dump
these out.
Signed-off-by: Tero Kristo
---
cmd/clk.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/cmd/clk.c b/cmd/clk.c
index e3c3d2f9bb..0245b97136 100644
--- a/cmd/clk.c
+++ b/cmd/clk.c
@@ -18,11 +18,14 @@ static void show_clks(struct udevice *dev, int depth, int
last_flag)
{
int i, is_last;
struct udevice *child;
- struct clk *clkp;
+ struct clk *clkp, *parent;
u32 rate;
clkp = dev_get_clk_ptr(dev);
if (device_get_uclass_id(dev) == UCLASS_CLK && clkp) {
+ parent = clk_get_parent(clkp);
+ if (!IS_ERR(parent) && depth == -1)
+ return;
depth++;
rate = clk_get_rate(clkp);
@@ -47,6 +50,9 @@ static void show_clks(struct udevice *dev, int depth, int
last_flag)
}
list_for_each_entry(child, >child_head, sibling_node) {
+ if (child == dev)
+ continue;
+
is_last = list_is_last(>sibling_node, >child_head);
show_clks(child, depth, (last_flag << 1) | is_last);
}
@@ -54,14 +60,19 @@ static void show_clks(struct udevice *dev, int depth, int
last_flag)
int __weak soc_clk_dump(void)
{
- struct udevice *root;
+ struct udevice *dev;
+ struct uclass *uc;
+ int ret;
- root = dm_root();
- if (root) {
- printf(" Rate Usecnt Name\n");
- printf("--\n");
- show_clks(root, -1, 0);
- }
+ ret = uclass_get(UCLASS_CLK, );
+ if (ret)
+ return ret;
+
+ printf(" Rate Usecnt Name\n");
+ printf("--\n");
+
+ uclass_foreach_dev(dev, uc)
+ show_clks(dev, -1, 0);
return 0;
}
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 09/26] clk: sci-clk: fix return value of set_rate
Set rate should return the new clock rate on success, and negative error
value on failure. Fix this, as currently set_rate returns 0 on success.
Signed-off-by: Tero Kristo
---
drivers/clk/clk-ti-sci.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-ti-sci.c b/drivers/clk/clk-ti-sci.c
index 7a9a645137..e2ad18e96b 100644
--- a/drivers/clk/clk-ti-sci.c
+++ b/drivers/clk/clk-ti-sci.c
@@ -111,10 +111,12 @@ static ulong ti_sci_clk_set_rate(struct clk *clk, ulong
rate)
#endif
ret = cops->set_freq(sci, clk->id, clk->data, 0, rate, ULONG_MAX);
- if (ret)
+ if (ret) {
dev_err(clk->dev, "%s: set_freq failed (%d)\n", __func__, ret);
+ return ret;
+ }
- return ret;
+ return rate;
}
static int ti_sci_clk_set_parent(struct clk *clk, struct clk *parent)
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 05/26] clk: fixed_rate: add API for directly registering fixed rate clocks
Current driver only supports registering fixed rate clocks from DT. Add
new API which makes it possible to register fixed rate clocks directly
from e.g. platform specific clock drivers.
Signed-off-by: Tero Kristo
---
drivers/clk/clk_fixed_rate.c | 45 +++-
include/linux/clk-provider.h | 3 +++
2 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk_fixed_rate.c b/drivers/clk/clk_fixed_rate.c
index 55e1f8caa5..5556acaf86 100644
--- a/drivers/clk/clk_fixed_rate.c
+++ b/drivers/clk/clk_fixed_rate.c
@@ -8,6 +8,9 @@
#include
#include
+#define UBOOT_DM_CLK_FIXED_RATE "fixed_rate_clock"
+#define UBOOT_DM_CLK_FIXED_RATE_RAW "fixed_rate_raw_clock"
+
static ulong clk_fixed_rate_get_rate(struct clk *clk)
{
return to_clk_fixed_rate(clk->dev)->fixed_rate;
@@ -24,6 +27,15 @@ const struct clk_ops clk_fixed_rate_ops = {
.enable = dummy_enable,
};
+static ulong clk_fixed_rate_raw_get_rate(struct clk *clk)
+{
+ return container_of(clk, struct clk_fixed_rate, clk)->fixed_rate;
+}
+
+const struct clk_ops clk_fixed_rate_raw_ops = {
+ .get_rate = clk_fixed_rate_raw_get_rate,
+};
+
static int clk_fixed_rate_ofdata_to_platdata(struct udevice *dev)
{
struct clk *clk = _clk_fixed_rate(dev)->clk;
@@ -39,6 +51,30 @@ static int clk_fixed_rate_ofdata_to_platdata(struct udevice
*dev)
return 0;
}
+struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
+ ulong rate)
+{
+ struct clk *clk;
+ struct clk_fixed_rate *fixed;
+ int ret;
+
+ fixed = kzalloc(sizeof(*fixed), GFP_KERNEL);
+ if (!fixed)
+ return ERR_PTR(-ENOMEM);
+
+ fixed->fixed_rate = rate;
+
+ clk = >clk;
+
+ ret = clk_register(clk, UBOOT_DM_CLK_FIXED_RATE_RAW, name, NULL);
+ if (ret) {
+ kfree(fixed);
+ return ERR_PTR(ret);
+ }
+
+ return clk;
+}
+
static const struct udevice_id clk_fixed_rate_match[] = {
{
.compatible = "fixed-clock",
@@ -47,7 +83,7 @@ static const struct udevice_id clk_fixed_rate_match[] = {
};
U_BOOT_DRIVER(clk_fixed_rate) = {
- .name = "fixed_rate_clock",
+ .name = UBOOT_DM_CLK_FIXED_RATE,
.id = UCLASS_CLK,
.of_match = clk_fixed_rate_match,
.ofdata_to_platdata = clk_fixed_rate_ofdata_to_platdata,
@@ -55,3 +91,10 @@ U_BOOT_DRIVER(clk_fixed_rate) = {
.ops = _fixed_rate_ops,
.flags = DM_FLAG_PRE_RELOC,
};
+
+U_BOOT_DRIVER(clk_fixed_rate_raw) = {
+ .name = UBOOT_DM_CLK_FIXED_RATE_RAW,
+ .id = UCLASS_CLK,
+ .ops = _fixed_rate_raw_ops,
+ .flags = DM_FLAG_PRE_RELOC,
+};
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 79dce8f0ad..6b50c42214 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -186,6 +186,9 @@ struct clk *clk_register_mux(struct device *dev, const char
*name,
void __iomem *reg, u8 shift, u8 width,
u8 clk_mux_flags);
+struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
+ ulong rate);
+
const char *clk_hw_get_name(const struct clk *hw);
ulong clk_generic_get_rate(struct clk *clk);
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 03/26] remoteproc: k3-r5: remove sysfw PM calls if not supported
With the sysfw rearch, sysfw PM calls are no longer available from SPL
level. To properly support this, remove the is_on checks and the reset
assertion from the R5 remoteproc driver as these are not supported.
Attempting to access unavailable services will cause the device to hang.
Signed-off-by: Tero Kristo
---
drivers/remoteproc/ti_k3_r5f_rproc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/remoteproc/ti_k3_r5f_rproc.c
b/drivers/remoteproc/ti_k3_r5f_rproc.c
index 9332a63d21..b2902e7fd3 100644
--- a/drivers/remoteproc/ti_k3_r5f_rproc.c
+++ b/drivers/remoteproc/ti_k3_r5f_rproc.c
@@ -781,7 +781,9 @@ static int k3_r5f_probe(struct udevice *dev)
{
struct k3_r5f_cluster *cluster = dev_get_priv(dev->parent);
struct k3_r5f_core *core = dev_get_priv(dev);
+#ifdef CONFIG_CLK_TI_SCI
bool r_state;
+#endif
int ret;
dev_dbg(dev, "%s\n", __func__);
@@ -804,6 +806,7 @@ static int k3_r5f_probe(struct udevice *dev)
return ret;
}
+#ifdef CONFIG_CLK_TI_SCI
ret = core->tsp.sci->ops.dev_ops.is_on(core->tsp.sci, core->tsp.dev_id,
_state, >in_use);
if (ret)
@@ -817,6 +820,7 @@ static int k3_r5f_probe(struct udevice *dev)
/* Make sure Local reset is asserted. Redundant? */
reset_assert(>reset);
+#endif
ret = k3_r5f_rproc_configure(core);
if (ret) {
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 07/26] clk: do not attempt to fetch clock pointer with null device
Bail out early if device returned for the parent clock is null. This avoids warning prints like this when doing clk dump: dev_get_uclass_priv: null device Signed-off-by: Tero Kristo --- drivers/clk/clk-uclass.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c index 31c5997aea..a4b24b98e6 100644 --- a/drivers/clk/clk-uclass.c +++ b/drivers/clk/clk-uclass.c @@ -493,6 +493,8 @@ struct clk *clk_get_parent(struct clk *clk) return NULL; pdev = dev_get_parent(clk->dev); + if (!pdev) + return ERR_PTR(-ENODEV); pclk = dev_get_clk_ptr(pdev); if (!pclk) return ERR_PTR(-ENODEV); -- 2.17.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 01/26] lib: rational: copy the rational fraction lib routines from Linux
Copy the best rational approximation calculation routines from Linux.
Typical usecase for these routines is to calculate the M/N divider
values for PLLs to reach a specific clock rate.
Signed-off-by: Tero Kristo
---
include/linux/rational.h | 20
lib/Kconfig | 7 +++
lib/Makefile | 2 +
lib/rational.c | 99
4 files changed, 128 insertions(+)
create mode 100644 include/linux/rational.h
create mode 100644 lib/rational.c
diff --git a/include/linux/rational.h b/include/linux/rational.h
new file mode 100644
index 00..33f5f5fc3e
--- /dev/null
+++ b/include/linux/rational.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * rational fractions
+ *
+ * Copyright (C) 2009 emlix GmbH, Oskar Schirmer
+ *
+ * helper functions when coping with rational numbers,
+ * e.g. when calculating optimum numerator/denominator pairs for
+ * pll configuration taking into account restricted register size
+ */
+
+#ifndef _LINUX_RATIONAL_H
+#define _LINUX_RATIONAL_H
+
+void rational_best_approximation(
+ unsigned long given_numerator, unsigned long given_denominator,
+ unsigned long max_numerator, unsigned long max_denominator,
+ unsigned long *best_numerator, unsigned long *best_denominator);
+
+#endif /* _LINUX_RATIONAL_H */
diff --git a/lib/Kconfig b/lib/Kconfig
index 37aae73a26..2c6021c486 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -660,6 +660,13 @@ config SMBIOS_PRODUCT_NAME
The product name to store in SMBIOS structures.
Change this to override the default one (CONFIG_SYS_BOARD).
+config LIB_RATIONAL
+ bool "enable continued fraction calculation routines"
+
+config SPL_LIB_RATIONAL
+ bool "enable continued fraction calculation routines for SPL"
+ depends on SPL
+
endmenu
config ASN1_COMPILER
diff --git a/lib/Makefile b/lib/Makefile
index 0cd7bea282..b921691169 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -70,6 +70,8 @@ obj-$(CONFIG_$(SPL_)LZO) += lzo/
obj-$(CONFIG_$(SPL_)LZMA) += lzma/
obj-$(CONFIG_$(SPL_)LZ4) += lz4_wrapper.o
+obj-$(CONFIG_$(SPL_)LIB_RATIONAL) += rational.o
+
obj-$(CONFIG_LIBAVB) += libavb/
obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += libfdt/
diff --git a/lib/rational.c b/lib/rational.c
new file mode 100644
index 00..316db3b590
--- /dev/null
+++ b/lib/rational.c
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * rational fractions
+ *
+ * Copyright (C) 2009 emlix GmbH, Oskar Schirmer
+ * Copyright (C) 2019 Trent Piepho
+ *
+ * helper functions when coping with rational numbers
+ */
+
+#include
+#include
+#include
+
+/*
+ * calculate best rational approximation for a given fraction
+ * taking into account restricted register size, e.g. to find
+ * appropriate values for a pll with 5 bit denominator and
+ * 8 bit numerator register fields, trying to set up with a
+ * frequency ratio of 3.1415, one would say:
+ *
+ * rational_best_approximation(31415, 1,
+ * (1 << 8) - 1, (1 << 5) - 1, , );
+ *
+ * you may look at given_numerator as a fixed point number,
+ * with the fractional part size described in given_denominator.
+ *
+ * for theoretical background, see:
+ * http://en.wikipedia.org/wiki/Continued_fraction
+ */
+
+void rational_best_approximation(
+ unsigned long given_numerator, unsigned long given_denominator,
+ unsigned long max_numerator, unsigned long max_denominator,
+ unsigned long *best_numerator, unsigned long *best_denominator)
+{
+ /* n/d is the starting rational, which is continually
+* decreased each iteration using the Euclidean algorithm.
+*
+* dp is the value of d from the prior iteration.
+*
+* n2/d2, n1/d1, and n0/d0 are our successively more accurate
+* approximations of the rational. They are, respectively,
+* the current, previous, and two prior iterations of it.
+*
+* a is current term of the continued fraction.
+*/
+ unsigned long n, d, n0, d0, n1, d1, n2, d2;
+ n = given_numerator;
+ d = given_denominator;
+ n0 = d1 = 0;
+ n1 = d0 = 1;
+
+ for (;;) {
+ unsigned long dp, a;
+
+ if (d == 0)
+ break;
+ /* Find next term in continued fraction, 'a', via
+* Euclidean algorithm.
+*/
+ dp = d;
+ a = n / d;
+ d = n % d;
+ n = dp;
+
+ /* Calculate the current rational approximation (aka
+* convergent), n2/d2, using the term just found and
+* the two prior approximations.
+*/
+ n2 = n0 + a * n1;
+ d2 = d0 + a * d1;
+
+ /* If the current convergent exceeds the maxes, then
+* return either the previous convergent or the
+* largest semi-convergent, the final
[PATCH 04/26] common: fit: Update board_fit_image_post_process() to pass fit and node_offset
From: Lokesh Vutla
board_fit_image_post_process() passes only start and size of the image,
but type of the image is not passed. So pass fit and node_offset, to
derive information about image to be processed.
Signed-off-by: Lokesh Vutla
---
arch/arm/mach-k3/security.c | 3 ++-
arch/arm/mach-keystone/mon.c | 3 ++-
board/ti/am335x/board.c | 3 ++-
board/ti/am43xx/board.c | 3 ++-
board/ti/am57xx/board.c | 3 ++-
board/ti/dra7xx/evm.c| 3 ++-
common/image-fit.c | 2 +-
common/spl/spl_fit.c | 2 +-
include/image.h | 7 +--
9 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-k3/security.c b/arch/arm/mach-k3/security.c
index 66f90a5a34..5b5ff9ba7b 100644
--- a/arch/arm/mach-k3/security.c
+++ b/arch/arm/mach-k3/security.c
@@ -18,7 +18,8 @@
#include
#include
-void board_fit_image_post_process(void **p_image, size_t *p_size)
+void board_fit_image_post_process(const void *fit, int node, void **p_image,
+ size_t *p_size)
{
struct ti_sci_handle *ti_sci = get_ti_sci_handle();
struct ti_sci_proc_ops *proc_ops = _sci->ops.proc_ops;
diff --git a/arch/arm/mach-keystone/mon.c b/arch/arm/mach-keystone/mon.c
index 58995d73ac..b863bab196 100644
--- a/arch/arm/mach-keystone/mon.c
+++ b/arch/arm/mach-keystone/mon.c
@@ -103,7 +103,8 @@ static int k2_hs_bm_auth(int cmd, void *arg1)
return result;
}
-void board_fit_image_post_process(void **p_image, size_t *p_size)
+void board_fit_image_post_process(const void *fit, int node, void **p_image,
+ size_t *p_size)
{
int result = 0;
void *image = *p_image;
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 984cc5e3ba..9a8cc6649c 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -956,7 +956,8 @@ int board_fit_config_name_match(const char *name)
#endif
#ifdef CONFIG_TI_SECURE_DEVICE
-void board_fit_image_post_process(void **p_image, size_t *p_size)
+void board_fit_image_post_process(const void *fit, int node, void **p_image,
+ size_t *p_size)
{
secure_boot_verify_image(p_image, p_size);
}
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index de49590031..d14355aacd 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -895,7 +895,8 @@ int embedded_dtb_select(void)
#endif
#ifdef CONFIG_TI_SECURE_DEVICE
-void board_fit_image_post_process(void **p_image, size_t *p_size)
+void board_fit_image_post_process(const void *fit, int node, void **p_image,
+ size_t *p_size)
{
secure_boot_verify_image(p_image, p_size);
}
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 7809875510..4fd452b050 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -1197,7 +1197,8 @@ static int board_bootmode_has_emmc(void)
#endif
#ifdef CONFIG_TI_SECURE_DEVICE
-void board_fit_image_post_process(void **p_image, size_t *p_size)
+void board_fit_image_post_process(const void *fit, int node, void **p_image,
+ size_t *p_size)
{
secure_boot_verify_image(p_image, p_size);
}
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index ca1976e16a..6364d06ea5 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -1064,7 +1064,8 @@ int fastboot_set_reboot_flag(enum fastboot_reboot_reason
reason)
#endif
#ifdef CONFIG_TI_SECURE_DEVICE
-void board_fit_image_post_process(void **p_image, size_t *p_size)
+void board_fit_image_post_process(const void *fit, int node, void **p_image,
+ size_t *p_size)
{
secure_boot_verify_image(p_image, p_size);
}
diff --git a/common/image-fit.c b/common/image-fit.c
index d54eff9033..093fe8164a 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -2042,7 +2042,7 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
#if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS)
/* perform any post-processing on the image data */
- board_fit_image_post_process(, );
+ board_fit_image_post_process(fit, noffset, , );
#endif
len = (ulong)size;
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index a90d821c82..90a0863057 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -316,7 +316,7 @@ static int spl_load_fit_image(struct spl_load_info *info,
ulong sector,
#endif
#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
- board_fit_image_post_process(, );
+ board_fit_image_post_process(fit, node, , );
#endif
if (IS_ENABLED(CONFIG_SPL_GZIP) && image_comp == IH_COMP_GZIP) {
diff --git a/include/image.h b/include/image.h
index 10995b8e24..5d03511f38 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1537,12 +1537,15 @@ int board_fit_config_name_match(const char *name);
* into the FIT creation (i.e. the binary blobs would have
[PATCH 02/26] ram: k3-j721e: fix clk_set_rate API usage
clk_set_rate returns the new clock rate for the clock, not 0 in success. Fix the error checks to reflect proper API usage. Signed-off-by: Tero Kristo --- drivers/ram/k3-j721e/k3-j721e-ddrss.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/ram/k3-j721e/k3-j721e-ddrss.c b/drivers/ram/k3-j721e/k3-j721e-ddrss.c index d647a8a209..247b9d5f16 100644 --- a/drivers/ram/k3-j721e/k3-j721e-ddrss.c +++ b/drivers/ram/k3-j721e/k3-j721e-ddrss.c @@ -195,8 +195,10 @@ static int j721e_ddrss_ofdata_to_priv(struct udevice *dev) /* Put DDR pll in bypass mode */ ret = clk_set_rate(>ddr_clk, clk_get_rate(>osc_clk)); - if (ret) - dev_err(dev, "ddr clk bypass failed\n"); + if (ret < 0) + dev_err(dev, "ddr clk bypass failed: %d\n", ret); + else + ret = 0; return ret; } -- 2.17.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 00/26] TI J7 SoC HSM Rearch support series
Hello, On TI J7 SoCs the device manager firmware is now split into two portions instead of the existing one which supported all services via a single firmware image running on DMSC core. Now, the existing DMSC core is dedicated for secure services only, and the PM and RM functionality is moved under a separate firmware image running on MCU R5 core. This is completely transparent for the firmware users, as the existing messaging mechanism (TI-SCI) routes everything to proper destination, except for anything that runs on MCU R5, and in our case it happens to be R5 SPL bootloader. To support the firmware split, R5 SPL implementation must be changed in a way that it implements its own PM features, as these are needed during boot time. This series thus implements a couple of new drivers, PLL clock driver for the SoCs, and also a generic clock provider driver which is used to attach device drivers to proper clock entries. Also implemented is a power domain driver to power up/down IP blocks. R5 SPL bootloader also now needs to load and start the new DM firmware image and this is handled in the series. There are also a number of fixes attached to the series for fixing issues noticed while implementing the new drivers, mostly on the generic clock drivers side. I decided to keep the series as a single chunk for now, as it probably makes it easier to see why certain things are done. Let me know if you want me to split this series somehow. -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] usb: xhci: fix event trb handling missed
Hi Ran, On Tue, Nov 10, 2020 at 4:31 PM Ran Wang wrote: > > Hi Bin, > > On Tuesday, November 10, 2020 4:06 PM Ran Wang wrote: > > Hi Bin, > > > > On Tuesday, November 10, 2020 3:47 PM Bin Meng wrote: > > > > > > Hi Ran, > > > > > > > > > send request in more than 1 Transfer TRB by chaining them, but > > > > > > > then handle only 1 event TRB to mark request completed. > > > > > > > > > > > > > > However, on Layerscape platforms (LS1028A, LS1088A, etc), we > > > > > > > observe xhci controller will generated more than 1 event TRB > > > > > > > sometimes, this cause that > > > > > > > > > > > > I am not sure if it's fair to say this is Layerscape specific > > > > > > behavior. Based on the xHCI spec, the spec indicates 1 event trb > > > > > > should be generated when IOC/ISP flag is set to 1 or an error > > > > > > occurs. > > > > > > > > > > Ah, ISP flag is set if the pipe is from an IN endpoint. Currently we > > > > > have: > > > > > > > > > > /* Only set interrupt on short packet for IN endpoints */ > > > > > if (usb_pipein(pipe)) > > > > > field |= TRB_ISP; > > > > > > > > > > Can you verify that if removing the above codes, and without your > > > > > changes in this patch, the original issue can be resolved on LS1028? > > > > > > > > Bingo, removing above codes can resolve my issue, too > > > > > > Thank you for your testing. > > > > > > > > > > > > > I will see if I can reproduce your issue on an x86 board. > > > > > > > > > > > > > > > > Note this patch does not apply on top of u-boot/master. Please rebase. > > > > > > > > Sure, I can rebase my patch, but I am nor sure my solution is still > > > > worth: > > > > xHCI says "The detection of a USB Short Packet (i.e. the actual > > > > number of bytes received was less than the expected number of bytes > > > > defined by the Transfer TRB) during a transfer does not necessarily > > > > generate > > an Event. > > > " > > > > > > > > > > Yes, that's what the spec says. So in your case, can you add some logs > > > to verify that there is a transfer event trb generated by the xHC and > > > the completion code is 13 (short packet)? You can add some debug > > > output in record_transfer_result(). > > > > Sure, let me try this can get back to you later. > > Confirm completion code is 13 when issue happen (please search ' > complete_code:13'): Thank you very much for your testing. > > dev=fbb4f3c0, pipe=c0010283, buffer=fbb4fd80, > length=2048buffer would cross 64KB boundary, so > we will send request in more than 1 TRB, this is the key issue trigger > condition > xhci_bulk_tx()#0.1.running_total:0x280 > xhci_bulk_tx()#0.2.trb_buff_len:0x280 > xhci_bulk_tx()#0.3.running_total:0x280 > xhci_bulk_tx()#0.4.num_trbs:0x2--2 Transfer TRB > xhci_bulk_tx()#0.5.running_total:0x10280 > xhci_bulk_tx()#0.start_trb:0xfbb47140 > --xhci_bulk_tx()#0.>enqueue->generic:0xfbb47140--Assemble > 1st Transfer TRB > xhci_bulk_tx()#0.addr:0xfbb4fd80 > xhci_bulk_tx()#0.trb_buff_len:0x280 > xhci_bulk_tx()#0.running_total:0x280 > xhci_bulk_tx()#0.length:0x800 > xhci_bulk_tx()#0.TRB_MAX_BUFF_SIZE:0x1 > --xhci_bulk_tx()#0.>enqueue->generic:0xfbb47150--Assemble > 2nd Transfer TRB > xhci_bulk_tx()#0.addr:0xfbb5 > xhci_bulk_tx()#0.trb_buff_len:0x580 > xhci_bulk_tx()#0.running_total:0x800 > xhci_bulk_tx()#0.length:0x800 > xhci_bulk_tx()#0.TRB_MAX_BUFF_SIZE:0x1 > xhci_bulk_tx()#0.event->trans_event.buffer:0xfbb47140handle > event TRB for 1st Transfer TRB > xhci_bulk_tx()#0.event->trans_event.transfer_len:0xd000180 > xhci_bulk_tx()#0.event->trans_event.flags:0x1058001 > xhci_bulk_tx()#0.event->len:384 > xhci_bulk_tx()#0.event->complete_code:13 > xhci_bulk_tx()#1.field:0x1058001 > xhci_bulk_tx()#2.TRB_TO_EP_ENDEX(field):0x4 > xhci_bulk_tx()#3.ep_index:0x4--xhci_bulk_tx() > return > > dev=fbb4f3c0, pipe=c0018203, buffer=fbb2f9c0, > length=110--an other call comming, and for different EP (ep_index = > 05) > xhci_bulk_tx()#0.1.running_total:0x640 > xhci_bulk_tx()#0.2.trb_buff_len:0x640 > xhci_bulk_tx()#0.3.running_total:0x640 > xhci_bulk_tx()#0.4.num_trbs:0x1 > xhci_bulk_tx()#0.5.running_total:0x640 > xhci_bulk_tx()#0.start_trb:0xfbb47610 > --xhci_bulk_tx()#0.>enqueue->generic:0xfbb47610-queue > 1st transfer TRB > xhci_bulk_tx()#0.addr:0xfbb2f9c0 > xhci_bulk_tx()#0.trb_buff_len:0x6e > xhci_bulk_tx()#0.running_total:0x6e > xhci_bulk_tx()#0.length:0x6e > xhci_bulk_tx()#0.TRB_MAX_BUFF_SIZE:0x1 > xhci_bulk_tx()#0.event->trans_event.buffer:0xfbb47150hand > event TRB, note that this buffer is for last Transfer TRB in last call (see > above '2nd Transfer TRB') > xhci_bulk_tx()#0.event->trans_event.transfer_len:0x100 >
Re: [PATCH] mmc: meson_gx_mmc: control ddr_mode bit
On 11/10/20 5:50 PM, Mark Kettenis wrote: >> From: Neil Armstrong >> Date: Tue, 10 Nov 2020 09:15:14 +0100 >> >> On 10/11/2020 08:50, Jaehoon Chung wrote: >>> EMMC_CFG register has a cfg_ddr bit(BIT[2]). >>> It needs to set when mmc is running to ddr mode. >>> Otherwise, its bit should be cleared. >>> CFG_DDR[2] - 1: DDR mode, 0: SDR mode >>> >>> Signed-off-by: Jaehoon Chung >>> --- >>> arch/arm/include/asm/arch-meson/sd_emmc.h | 1 + >>> drivers/mmc/meson_gx_mmc.c| 5 + >>> 2 files changed, 6 insertions(+) >>> >>> diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h >>> b/arch/arm/include/asm/arch-meson/sd_emmc.h >>> index 1e9f8cf498b4..c2f77c7308ec 100644 >>> --- a/arch/arm/include/asm/arch-meson/sd_emmc.h >>> +++ b/arch/arm/include/asm/arch-meson/sd_emmc.h >>> @@ -38,6 +38,7 @@ >>> #define CFG_BUS_WIDTH_1 0 >>> #define CFG_BUS_WIDTH_4 1 >>> #define CFG_BUS_WIDTH_8 2 >>> +#define CFG_DDR_MODE BIT(2) >>> #define CFG_BL_LEN_MASK GENMASK(7, 4) >>> #define CFG_BL_LEN_SHIFT 4 >>> #define CFG_BL_LEN_512 (9 << 4) >>> diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c >>> index 7c60e0566560..6fcf6c2ced27 100644 >>> --- a/drivers/mmc/meson_gx_mmc.c >>> +++ b/drivers/mmc/meson_gx_mmc.c >>> @@ -90,6 +90,11 @@ static int meson_dm_mmc_set_ios(struct udevice *dev) >>> else >>> return -EINVAL; >>> >>> + if (mmc->ddr_mode) >>> + meson_mmc_cfg |= CFG_DDR_MODE; >>> + else >>> + meson_mmc_cfg &= ~CFG_DDR_MODE; >>> + >>> /* 512 bytes block length */ >>> meson_mmc_cfg &= ~CFG_BL_LEN_MASK; >>> meson_mmc_cfg |= CFG_BL_LEN_512; >>> >> >> Interesting, how did it work without this bit ? > > Well, in meson_mmc_probe() we have: > > cfg->host_caps = MMC_MODE_8BIT | MMC_MODE_4BIT | > MMC_MODE_HS_52MHz | MMC_MODE_HS; > > So the driver doesn't advertise DDR support. Right. I added some patch in my local for testing. Actually, those is wrong. If want to follow linux driver, it needs to remove. Instead, it has to use mmc_of_parse() for dt's property. I will send patch after more test. Best Regards, Jaehoon Chung >
Re: [PATCH] mmc: meson_gx_mmc: change a clock phase to stable value
On 10/11/2020 09:36, Jaehoon Chung wrote: > On 11/10/20 5:05 PM, Neil Armstrong wrote: >> On 09/11/2020 23:19, Jaehoon Chung wrote: >>> On 11/9/20 11:23 PM, Neil Armstrong wrote: On 09/11/2020 15:10, Mark Kettenis wrote: >> From: Neil Armstrong >> Date: Mon, 9 Nov 2020 14:37:09 +0100 >> >> Hi, >> >> On 09/11/2020 04:12, Jaehoon Chung wrote: >>> Core clock phase value is changed from 180' to 270'. >>> It's more stable than before. >>> - Odroidn-N2/C4 : Working fine with 52MHz >>> - VIM3 : Working fine with 52MHz >>> >>> Before this patch, Odroid-C4 doesn't work fine with 52MHz. >>> >>> Signed-off-by: Jaehoon Chung >>> --- >>> drivers/mmc/meson_gx_mmc.c | 14 ++ >>> 1 file changed, 10 insertions(+), 4 deletions(-) >>> >>> diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c >>> index 719dd1e5e570..7c60e0566560 100644 >>> --- a/drivers/mmc/meson_gx_mmc.c >>> +++ b/drivers/mmc/meson_gx_mmc.c >>> @@ -52,10 +52,16 @@ static void meson_mmc_config_clock(struct mmc *mmc) >>> } >>> clk_div = DIV_ROUND_UP(clk, mmc->clock); >>> >>> - /* 180 phase core clock */ >>> - meson_mmc_clk |= CLK_CO_PHASE_180; >>> - >>> - /* 180 phase tx clock */ >>> + /* >>> +* Clock Phase needs to set a proper value. >>> +* It can be changed to other value. >>> +* Because CORE : 270' Phase and TX : 0' Phase are stable, >>> +* set to them by default. >>> +*/ >>> + /* Core Clock Phase */ >>> + meson_mmc_clk |= CLK_CO_PHASE_270; >>> + >>> + /* TX Clock Phase */ >>> meson_mmc_clk |= CLK_TX_PHASE_000; >>> >>> /* clock settings */ >>> >> >> The previous values were aligned on the Linux driver, which is >> functional. > > Actually the Linux driver isn't really functional; the 52 MHz > high-speed mode doesn't work. But since HS200 does work in Linux, > probably nobody noticed this. > > That said, I'm not confident a single clock phase setting will work > across all Amlogic SoCs and across different boards. Maybe we need > something in the device tree such that we can control the values on a > per-board level. > So this is specific to SM1 SoCs then, because others families doesn't have such issues at 52MHz. >>> >>> I don't have much knowledge of SM1 SoCs. But how did its phase value select >>> them on Linux driver? >>> So the Linux must be fixes, including the bindings to introduce a new compatible, then ported to U-Boot. So in the meantime, it's right to limit to 26MHz on SM1 in U-boot until we have all this clarified. >>> If you want to limit to 26MHz, I don't have any objection about your >>> opinion. >>> But I wonder how to clarify all. And I also wonder that values what is used >>> on Linux kernel are really right. >> >> OK, I'm not a MMC & SDCard expert on Amlogic, all the work was done in Linux. >> >> I just want to keep a working and stable SDCard & eMMC support for the 7 >> SoCs Families. >> >> Could you rewrite my "[PATCH 2/3] mmc: meson-gx: limit max frequency on SM1 >> SoCs" by instead changing the >> clock phase only for SM1 ? >> I'll then apply it with the 2 other patches and push then for the current >> development cycle. > > Ok. I will rewrite with you patch. Is it ok that i send the patch on Tomorrow? Agreed > >> >> The driver is functional for all the other SoCs, and I want to keep it >> stable unless extensively tested. > > Agreed. If i can test all Amlogic SoCs, I want to do that..But it's > impossible to me. > In future, i hope that it will be fixed with generic approach. Sure, thanks for your work & testing ! Neil > > Best Regards, > Jaehoon Chung > >> >> Neil >> >>> >>> Best Regards, >>> Jaehoon Chung >>> Neil >>> >> >> >
Re: [PATCH] mmc: meson_gx_mmc: control ddr_mode bit
> From: Neil Armstrong > Date: Tue, 10 Nov 2020 09:15:14 +0100 > > On 10/11/2020 08:50, Jaehoon Chung wrote: > > EMMC_CFG register has a cfg_ddr bit(BIT[2]). > > It needs to set when mmc is running to ddr mode. > > Otherwise, its bit should be cleared. > > CFG_DDR[2] - 1: DDR mode, 0: SDR mode > > > > Signed-off-by: Jaehoon Chung > > --- > > arch/arm/include/asm/arch-meson/sd_emmc.h | 1 + > > drivers/mmc/meson_gx_mmc.c| 5 + > > 2 files changed, 6 insertions(+) > > > > diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h > > b/arch/arm/include/asm/arch-meson/sd_emmc.h > > index 1e9f8cf498b4..c2f77c7308ec 100644 > > --- a/arch/arm/include/asm/arch-meson/sd_emmc.h > > +++ b/arch/arm/include/asm/arch-meson/sd_emmc.h > > @@ -38,6 +38,7 @@ > > #define CFG_BUS_WIDTH_1 0 > > #define CFG_BUS_WIDTH_4 1 > > #define CFG_BUS_WIDTH_8 2 > > +#define CFG_DDR_MODE BIT(2) > > #define CFG_BL_LEN_MASK GENMASK(7, 4) > > #define CFG_BL_LEN_SHIFT 4 > > #define CFG_BL_LEN_512 (9 << 4) > > diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c > > index 7c60e0566560..6fcf6c2ced27 100644 > > --- a/drivers/mmc/meson_gx_mmc.c > > +++ b/drivers/mmc/meson_gx_mmc.c > > @@ -90,6 +90,11 @@ static int meson_dm_mmc_set_ios(struct udevice *dev) > > else > > return -EINVAL; > > > > + if (mmc->ddr_mode) > > + meson_mmc_cfg |= CFG_DDR_MODE; > > + else > > + meson_mmc_cfg &= ~CFG_DDR_MODE; > > + > > /* 512 bytes block length */ > > meson_mmc_cfg &= ~CFG_BL_LEN_MASK; > > meson_mmc_cfg |= CFG_BL_LEN_512; > > > > Interesting, how did it work without this bit ? Well, in meson_mmc_probe() we have: cfg->host_caps = MMC_MODE_8BIT | MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS; So the driver doesn't advertise DDR support.
Re: [PATCH] mmc: meson_gx_mmc: control ddr_mode bit
On 11/10/20 5:15 PM, Neil Armstrong wrote: > On 10/11/2020 08:50, Jaehoon Chung wrote: >> EMMC_CFG register has a cfg_ddr bit(BIT[2]). >> It needs to set when mmc is running to ddr mode. >> Otherwise, its bit should be cleared. >> CFG_DDR[2] - 1: DDR mode, 0: SDR mode >> >> Signed-off-by: Jaehoon Chung >> --- >> arch/arm/include/asm/arch-meson/sd_emmc.h | 1 + >> drivers/mmc/meson_gx_mmc.c| 5 + >> 2 files changed, 6 insertions(+) >> >> diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h >> b/arch/arm/include/asm/arch-meson/sd_emmc.h >> index 1e9f8cf498b4..c2f77c7308ec 100644 >> --- a/arch/arm/include/asm/arch-meson/sd_emmc.h >> +++ b/arch/arm/include/asm/arch-meson/sd_emmc.h >> @@ -38,6 +38,7 @@ >> #define CFG_BUS_WIDTH_1 0 >> #define CFG_BUS_WIDTH_4 1 >> #define CFG_BUS_WIDTH_8 2 >> +#define CFG_DDR_MODE BIT(2) >> #define CFG_BL_LEN_MASK GENMASK(7, 4) >> #define CFG_BL_LEN_SHIFT 4 >> #define CFG_BL_LEN_512(9 << 4) >> diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c >> index 7c60e0566560..6fcf6c2ced27 100644 >> --- a/drivers/mmc/meson_gx_mmc.c >> +++ b/drivers/mmc/meson_gx_mmc.c >> @@ -90,6 +90,11 @@ static int meson_dm_mmc_set_ios(struct udevice *dev) >> else >> return -EINVAL; >> >> +if (mmc->ddr_mode) >> +meson_mmc_cfg |= CFG_DDR_MODE; >> +else >> +meson_mmc_cfg &= ~CFG_DDR_MODE; >> + >> /* 512 bytes block length */ >> meson_mmc_cfg &= ~CFG_BL_LEN_MASK; >> meson_mmc_cfg |= CFG_BL_LEN_512; >> > > Interesting, how did it work without this bit ? Without this bit, it's only work to Single Data rate. Linux driver is also controlling this bit. As you know, Amlogic SoCs supports DDR mode. If this bit is not set, this driver can't use DDR mode. When DDR mode is running without this bit, CRC error will be returned (In meson_gx_mmc's case, IO error is returned.) After applied more patch, it's working DDR mode. Device: mmc@ffe07000 Manufacturer ID: 15 OEM: 100 Name: BJTD4 Bus Speed: 5200 Mode: MMC DDR52 (52MHz) Rd Block Len: 512 MMC version 5.1 High Capacity: Yes Capacity: 29.1 GiB Bus Width: 8-bit DDR Erase Group Size: 512 KiB HC WP Group Size: 8 MiB User Capacity: 29.1 GiB WRREL Boot Capacity: 4 MiB ENH RPMB Capacity: 4 MiB ENH Boot area 0 is not write protected Boot area 1 is not write protected > > This driver seems to really be in a bad state... Right. This driver doesn't use any dt's property. It also needs to add mmc_of_parse() to use kernel property. I will do that. Best Regards, Jaehoon Chung > > Neil > >
Re: [PATCH] mmc: meson_gx_mmc: change a clock phase to stable value
On 11/10/20 5:05 PM, Neil Armstrong wrote: > On 09/11/2020 23:19, Jaehoon Chung wrote: >> On 11/9/20 11:23 PM, Neil Armstrong wrote: >>> On 09/11/2020 15:10, Mark Kettenis wrote: > From: Neil Armstrong > Date: Mon, 9 Nov 2020 14:37:09 +0100 > > Hi, > > On 09/11/2020 04:12, Jaehoon Chung wrote: >> Core clock phase value is changed from 180' to 270'. >> It's more stable than before. >> - Odroidn-N2/C4 : Working fine with 52MHz >> - VIM3 : Working fine with 52MHz >> >> Before this patch, Odroid-C4 doesn't work fine with 52MHz. >> >> Signed-off-by: Jaehoon Chung >> --- >> drivers/mmc/meson_gx_mmc.c | 14 ++ >> 1 file changed, 10 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c >> index 719dd1e5e570..7c60e0566560 100644 >> --- a/drivers/mmc/meson_gx_mmc.c >> +++ b/drivers/mmc/meson_gx_mmc.c >> @@ -52,10 +52,16 @@ static void meson_mmc_config_clock(struct mmc *mmc) >> } >> clk_div = DIV_ROUND_UP(clk, mmc->clock); >> >> -/* 180 phase core clock */ >> -meson_mmc_clk |= CLK_CO_PHASE_180; >> - >> -/* 180 phase tx clock */ >> +/* >> + * Clock Phase needs to set a proper value. >> + * It can be changed to other value. >> + * Because CORE : 270' Phase and TX : 0' Phase are stable, >> + * set to them by default. >> + */ >> +/* Core Clock Phase */ >> +meson_mmc_clk |= CLK_CO_PHASE_270; >> + >> +/* TX Clock Phase */ >> meson_mmc_clk |= CLK_TX_PHASE_000; >> >> /* clock settings */ >> > > The previous values were aligned on the Linux driver, which is functional. Actually the Linux driver isn't really functional; the 52 MHz high-speed mode doesn't work. But since HS200 does work in Linux, probably nobody noticed this. That said, I'm not confident a single clock phase setting will work across all Amlogic SoCs and across different boards. Maybe we need something in the device tree such that we can control the values on a per-board level. >>> >>> So this is specific to SM1 SoCs then, because others families doesn't have >>> such issues >>> at 52MHz. >> >> I don't have much knowledge of SM1 SoCs. But how did its phase value select >> them on Linux driver? >> >>> >>> So the Linux must be fixes, including the bindings to introduce a new >>> compatible, then >>> ported to U-Boot. >>> >>> So in the meantime, it's right to limit to 26MHz on SM1 in U-boot until we >>> have all this >>> clarified. >> If you want to limit to 26MHz, I don't have any objection about your opinion. >> But I wonder how to clarify all. And I also wonder that values what is used >> on Linux kernel are really right. > > OK, I'm not a MMC & SDCard expert on Amlogic, all the work was done in Linux. > > I just want to keep a working and stable SDCard & eMMC support for the 7 SoCs > Families. > > Could you rewrite my "[PATCH 2/3] mmc: meson-gx: limit max frequency on SM1 > SoCs" by instead changing the > clock phase only for SM1 ? > I'll then apply it with the 2 other patches and push then for the current > development cycle. Ok. I will rewrite with you patch. Is it ok that i send the patch on Tomorrow? > > The driver is functional for all the other SoCs, and I want to keep it stable > unless extensively tested. Agreed. If i can test all Amlogic SoCs, I want to do that..But it's impossible to me. In future, i hope that it will be fixed with generic approach. Best Regards, Jaehoon Chung > > Neil > >> >> Best Regards, >> Jaehoon Chung >> >>> >>> Neil >>> >> > >
RE: [PATCH] usb: xhci: fix event trb handling missed
Hi Bin, On Tuesday, November 10, 2020 4:06 PM Ran Wang wrote: > Hi Bin, > > On Tuesday, November 10, 2020 3:47 PM Bin Meng wrote: > > > > Hi Ran, > > > > > > > send request in more than 1 Transfer TRB by chaining them, but > > > > > > then handle only 1 event TRB to mark request completed. > > > > > > > > > > > > However, on Layerscape platforms (LS1028A, LS1088A, etc), we > > > > > > observe xhci controller will generated more than 1 event TRB > > > > > > sometimes, this cause that > > > > > > > > > > I am not sure if it's fair to say this is Layerscape specific > > > > > behavior. Based on the xHCI spec, the spec indicates 1 event trb > > > > > should be generated when IOC/ISP flag is set to 1 or an error occurs. > > > > > > > > Ah, ISP flag is set if the pipe is from an IN endpoint. Currently we > > > > have: > > > > > > > > /* Only set interrupt on short packet for IN endpoints */ > > > > if (usb_pipein(pipe)) > > > > field |= TRB_ISP; > > > > > > > > Can you verify that if removing the above codes, and without your > > > > changes in this patch, the original issue can be resolved on LS1028? > > > > > > Bingo, removing above codes can resolve my issue, too > > > > Thank you for your testing. > > > > > > > > > > I will see if I can reproduce your issue on an x86 board. > > > > > > > > > > > > > Note this patch does not apply on top of u-boot/master. Please rebase. > > > > > > Sure, I can rebase my patch, but I am nor sure my solution is still worth: > > > xHCI says "The detection of a USB Short Packet (i.e. the actual > > > number of bytes received was less than the expected number of bytes > > > defined by the Transfer TRB) during a transfer does not necessarily > > > generate > an Event. > > " > > > > > > > Yes, that's what the spec says. So in your case, can you add some logs > > to verify that there is a transfer event trb generated by the xHC and > > the completion code is 13 (short packet)? You can add some debug > > output in record_transfer_result(). > > Sure, let me try this can get back to you later. Confirm completion code is 13 when issue happen (please search ' complete_code:13'): dev=fbb4f3c0, pipe=c0010283, buffer=fbb4fd80, length=2048buffer would cross 64KB boundary, so we will send request in more than 1 TRB, this is the key issue trigger condition xhci_bulk_tx()#0.1.running_total:0x280 xhci_bulk_tx()#0.2.trb_buff_len:0x280 xhci_bulk_tx()#0.3.running_total:0x280 xhci_bulk_tx()#0.4.num_trbs:0x2--2 Transfer TRB xhci_bulk_tx()#0.5.running_total:0x10280 xhci_bulk_tx()#0.start_trb:0xfbb47140 --xhci_bulk_tx()#0.>enqueue->generic:0xfbb47140--Assemble 1st Transfer TRB xhci_bulk_tx()#0.addr:0xfbb4fd80 xhci_bulk_tx()#0.trb_buff_len:0x280 xhci_bulk_tx()#0.running_total:0x280 xhci_bulk_tx()#0.length:0x800 xhci_bulk_tx()#0.TRB_MAX_BUFF_SIZE:0x1 --xhci_bulk_tx()#0.>enqueue->generic:0xfbb47150--Assemble 2nd Transfer TRB xhci_bulk_tx()#0.addr:0xfbb5 xhci_bulk_tx()#0.trb_buff_len:0x580 xhci_bulk_tx()#0.running_total:0x800 xhci_bulk_tx()#0.length:0x800 xhci_bulk_tx()#0.TRB_MAX_BUFF_SIZE:0x1 xhci_bulk_tx()#0.event->trans_event.buffer:0xfbb47140handle event TRB for 1st Transfer TRB xhci_bulk_tx()#0.event->trans_event.transfer_len:0xd000180 xhci_bulk_tx()#0.event->trans_event.flags:0x1058001 xhci_bulk_tx()#0.event->len:384 xhci_bulk_tx()#0.event->complete_code:13 xhci_bulk_tx()#1.field:0x1058001 xhci_bulk_tx()#2.TRB_TO_EP_ENDEX(field):0x4 xhci_bulk_tx()#3.ep_index:0x4--xhci_bulk_tx() return dev=fbb4f3c0, pipe=c0018203, buffer=fbb2f9c0, length=110--an other call comming, and for different EP (ep_index = 05) xhci_bulk_tx()#0.1.running_total:0x640 xhci_bulk_tx()#0.2.trb_buff_len:0x640 xhci_bulk_tx()#0.3.running_total:0x640 xhci_bulk_tx()#0.4.num_trbs:0x1 xhci_bulk_tx()#0.5.running_total:0x640 xhci_bulk_tx()#0.start_trb:0xfbb47610 --xhci_bulk_tx()#0.>enqueue->generic:0xfbb47610-queue 1st transfer TRB xhci_bulk_tx()#0.addr:0xfbb2f9c0 xhci_bulk_tx()#0.trb_buff_len:0x6e xhci_bulk_tx()#0.running_total:0x6e xhci_bulk_tx()#0.length:0x6e xhci_bulk_tx()#0.TRB_MAX_BUFF_SIZE:0x1 xhci_bulk_tx()#0.event->trans_event.buffer:0xfbb47150hand event TRB, note that this buffer is for last Transfer TRB in last call (see above '2nd Transfer TRB') xhci_bulk_tx()#0.event->trans_event.transfer_len:0x100 xhci_bulk_tx()#0.event->trans_event.flags:0x1058000 xhci_bulk_tx()#0.event->len:0 xhci_bulk_tx()#0.event->complete_code:1 xhci_bulk_tx()#1.field:0x1058000 xhci_bulk_tx()#2.TRB_TO_EP_ENDEX(field):0x4ep_index is 4 rather than 5, then cause BUG() xhci_bulk_tx()#3.ep_index:0x5- ep_index mis-match wait for event
Re: [PATCH] mmc: meson_gx_mmc: control ddr_mode bit
On 10/11/2020 08:50, Jaehoon Chung wrote: > EMMC_CFG register has a cfg_ddr bit(BIT[2]). > It needs to set when mmc is running to ddr mode. > Otherwise, its bit should be cleared. > CFG_DDR[2] - 1: DDR mode, 0: SDR mode > > Signed-off-by: Jaehoon Chung > --- > arch/arm/include/asm/arch-meson/sd_emmc.h | 1 + > drivers/mmc/meson_gx_mmc.c| 5 + > 2 files changed, 6 insertions(+) > > diff --git a/arch/arm/include/asm/arch-meson/sd_emmc.h > b/arch/arm/include/asm/arch-meson/sd_emmc.h > index 1e9f8cf498b4..c2f77c7308ec 100644 > --- a/arch/arm/include/asm/arch-meson/sd_emmc.h > +++ b/arch/arm/include/asm/arch-meson/sd_emmc.h > @@ -38,6 +38,7 @@ > #define CFG_BUS_WIDTH_10 > #define CFG_BUS_WIDTH_41 > #define CFG_BUS_WIDTH_82 > +#define CFG_DDR_MODE BIT(2) > #define CFG_BL_LEN_MASKGENMASK(7, 4) > #define CFG_BL_LEN_SHIFT 4 > #define CFG_BL_LEN_512 (9 << 4) > diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c > index 7c60e0566560..6fcf6c2ced27 100644 > --- a/drivers/mmc/meson_gx_mmc.c > +++ b/drivers/mmc/meson_gx_mmc.c > @@ -90,6 +90,11 @@ static int meson_dm_mmc_set_ios(struct udevice *dev) > else > return -EINVAL; > > + if (mmc->ddr_mode) > + meson_mmc_cfg |= CFG_DDR_MODE; > + else > + meson_mmc_cfg &= ~CFG_DDR_MODE; > + > /* 512 bytes block length */ > meson_mmc_cfg &= ~CFG_BL_LEN_MASK; > meson_mmc_cfg |= CFG_BL_LEN_512; > Interesting, how did it work without this bit ? This driver seems to really be in a bad state... Neil
