Re: [PATCH v2 04/10] mmc: sdhci: Expose sdhci_init() as non-static
Jaehoon,
On 18/02/20 4:54 am, Jaehoon Chung wrote:
> Hi Faiz,
>
> On 2/18/20 7:35 AM, Jaehoon Chung wrote:
>> Hi Faiz,
>>
>> On 2/17/20 9:42 PM, Faiz Abbas wrote:
>>> Jaehoon,
>>>
>>> On 17/02/20 5:47 pm, Jaehoon Chung wrote:
Hi,
On 2/5/20 4:33 PM, Faiz Abbas wrote:
> Hi Peng,
>
> On 05/02/20 12:58 pm, Peng Fan wrote:
>>> Subject: Re: [PATCH v2 04/10] mmc: sdhci: Expose sdhci_init() as
>>> non-static
>>>
...
>>
>> Well, if you want, i will make patch about callback function.
>
> How about below codes? Then you can just add am654_sdhci_deferred_probe { ...
> return sdhci_probe() .. }
>
>
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 0b90a97650..c75892a72c 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -138,6 +138,21 @@ int mmc_host_power_cycle(struct mmc *mmc)
> return dm_mmc_host_power_cycle(mmc->dev);
> }
>
> +int dm_mmc_deferred_probe(struct udevice *dev)
> +{
> + struct dm_mmc_ops *ops = mmc_get_ops(dev);
> +
> + if (ops->deferred_probe)
> + return ops->deferred_probe(dev);
> +
> + return 0;
> +}
> +
> +int mmc_deferred_probe(struct mmc *mmc)
> +{
> + return dm_mmc_deferred_probe(mmc->dev);
> +}
> +
> int mmc_of_parse(struct udevice *dev, struct mmc_config *cfg)
> {
> int val;
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index d43983d4a6..9eae538af4 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2790,6 +2790,7 @@ int mmc_get_op_cond(struct mmc *mmc)
>
> #if CONFIG_IS_ENABLED(DM_MMC)
> /* The device has already been probed ready for use */
> + mmc_deferred_probe(mmc);
> #else
> /* made sure it's not NULL earlier */
> err = mmc->cfg->ops->init(mmc);
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index 01fa5a9d4d..9ff37b888b 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -661,6 +661,20 @@ int sdhci_probe(struct udevice *dev)
> return sdhci_init(mmc);
> }
>
> +static int sdhci_deferred_probe(struct udevice *dev)
> +{
> + int err;
> + struct mmc *mmc = mmc_get_mmc_dev(dev);
> + struct sdhci_host *host = mmc->priv;
> +
> + if (host->ops && host->ops->deferred_probe) {
> + err = host->ops->deferred_probe(host);
> + if (err)
> + return err;
> + }
> + return 0;
> +}
> +
> static int sdhci_get_cd(struct udevice *dev)
> {
> struct mmc *mmc = mmc_get_mmc_dev(dev);
> @@ -695,6 +709,7 @@ const struct dm_mmc_ops sdhci_ops = {
> .send_cmd = sdhci_send_command,
> .set_ios= sdhci_set_ios,
> .get_cd = sdhci_get_cd,
> + .deferred_probe = sdhci_deferred_probe,
> #ifdef MMC_SUPPORTS_TUNING
> .execute_tuning = sdhci_execute_tuning,
> #endif
> diff --git a/include/mmc.h b/include/mmc.h
> index b5cb514f57..b362b7f4c7 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -477,6 +477,8 @@ struct dm_mmc_ops {
>* @return 0 if not present, 1 if present, -ve on error
>*/
> int (*host_power_cycle)(struct udevice *dev);
> +
> + int (*deferred_probe)(struct udevice *dev);
> };
>
> #define mmc_get_ops(dev)((struct dm_mmc_ops *)(dev)->driver->ops)
> @@ -489,6 +491,7 @@ int dm_mmc_get_wp(struct udevice *dev);
> int dm_mmc_execute_tuning(struct udevice *dev, uint opcode);
> int dm_mmc_wait_dat0(struct udevice *dev, int state, int timeout_us);
> int dm_mmc_host_power_cycle(struct udevice *dev);
> +int dm_mmc_deferred_probe(struct udevice *dev);
>
> /* Transition functions for compatibility */
> int mmc_set_ios(struct mmc *mmc);
> @@ -498,6 +501,7 @@ int mmc_execute_tuning(struct mmc *mmc, uint opcode);
> int mmc_wait_dat0(struct mmc *mmc, int state, int timeout_us);
> int mmc_set_enhanced_strobe(struct mmc *mmc);
> int mmc_host_power_cycle(struct mmc *mmc);
> +int mmc_deferred_probe(struct mmc *mmc);
>
> #else
> struct mmc_ops {
> diff --git a/include/sdhci.h b/include/sdhci.h
> index 01addb7a60..1276f43935 100644
> --- a/include/sdhci.h
> +++ b/include/sdhci.h
> @@ -267,6 +267,7 @@ struct sdhci_ops {
> void(*set_clock)(struct sdhci_host *host, u32 div);
> int (*platform_execute_tuning)(struct mmc *host, u8 opcode);
> void (*set_delay)(struct sdhci_host *host);
> + int (*deferred_probe)(struct sdhci_host *host);
> };
>
> #if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
>
>>
This does look like the cleanest solution. Will add in a v3.
Thanks,
Faiz
RE: [PATCH] ARM: socfpga: Add initial support for the ABB SECU board
Hi Marek and Wolfgang, > > In message <20200217173249.4805-1-ma...@denx.de> you wrote: > >> > >> board/keymile/Kconfig | 11 +- > >> board/keymile/common/ivm.c | 18 +- > >> board/keymile/secu1/Makefile| 7 + > >> board/keymile/secu1/qts/iocsr_config.h | 694 > >> board/keymile/secu1/qts/pinmux_config.h > | 218 > >> board/keymile/secu1/qts/pll_config.h| 83 +++ > >> board/keymile/secu1/qts/sdram_config.h | 327 +++ > >> board/keymile/secu1/socfpga.c | 67 +++ > > ... > >> +select VENDOR_KM > > > > Would it make sense to rename keymile -> abb (or abb-ch) here (ditto > > for KM in the config options / macro names) ? > > This is more of a question for Holger, but I agree the renaming should > eventually happen to align it with current state of things. yes I have it on my list to rename this folder to wcom (wiredcom) or wcom-abb. But this goes for all the boards in this folder and not only secu. But until know I didn't find the right time to do it as we have currently several activities ongoing for u-boot (re-aligning other boards and migrating PPC to DTS). I assume SECU goes for v2020.07 as we are too late for v2020.04 or? I think I can spend some time for the next merge window to tackle this folder issue for all boards and then we rebase and adapt this patch. Best regards Holger
Re: [PATCH] Revert "dm: fdt: scan for devices under /firmware too"
On 17. 02. 20 21:35, Thirupathaiah Annapureddy wrote:
> Subnodes under "/firmware" node are scanned twice in
> dm_scan_fdt_node() and dm_extended_scan_fdt().
> This patch removes the scanning in dm_scan_fdt_node() to
> avoid double scanning.
>
> This reverts commit 747558d014577526bf2e8d9fe9ca748fdbf75d8a.
>
> Signed-off-by: Thirupathaiah Annapureddy
> ---
> drivers/core/root.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/core/root.c b/drivers/core/root.c
> index e85643819e..cb695e933a 100644
> --- a/drivers/core/root.c
> +++ b/drivers/core/root.c
> @@ -254,15 +254,9 @@ static int dm_scan_fdt_node(struct udevice *parent,
> const void *blob,
> for (offset = fdt_first_subnode(blob, offset);
>offset > 0;
>offset = fdt_next_subnode(blob, offset)) {
> - const char *node_name = fdt_get_name(blob, offset, NULL);
> -
> - /*
> - * The "chosen" and "firmware" nodes aren't devices
> - * themselves but may contain some:
> - */
> - if (!strcmp(node_name, "chosen") ||
> - !strcmp(node_name, "firmware")) {
> - pr_debug("parsing subnodes of \"%s\"\n", node_name);
> + /* "chosen" node isn't a device itself but may contain some: */
> + if (!strcmp(fdt_get_name(blob, offset, NULL), "chosen")) {
> + pr_debug("parsing subnodes of \"chosen\"\n");
>
> err = dm_scan_fdt_node(parent, blob, offset,
> pre_reloc_only);
> @@ -279,7 +273,8 @@ static int dm_scan_fdt_node(struct udevice *parent, const
> void *blob,
>pre_reloc_only);
> if (err && !ret) {
> ret = err;
> - debug("%s: ret=%d\n", node_name, ret);
> + debug("%s: ret=%d\n", fdt_get_name(blob, offset, NULL),
> + ret);
> }
> }
This has come up several times. Please join this thread which is fixing
this issue.
https://lists.denx.de/pipermail/u-boot/2020-February/400165.html
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] i2c: designware_i2c: Correct the selection of speed mode
Hello Simon,
Am 13.02.2020 um 21:24 schrieb Simon Glass:
Unfortunately a recent change adjusted the order of the checks here such
that 400MHz now shows up as fast-plus speed (1Mbps). Fix it.
Signed-off-by: Simon Glass
Fixes: d96440d1e3 ("i2c: designware_i2c: Add support for fast-plus speed")
---
drivers/i2c/designware_i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Heiko Schocher
I started travis build, and if successful, I send pull request to Tom
soon, thanks for detecting this.
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 2/2] dm: i2c-gpio: add support for clock stretching
Hello Michael, Am 07.02.2020 um 17:55 schrieb Michael Auchter: This adds support for clock stretching to the i2c-gpio driver. This is accomplished by switching the GPIO used for the SCL line to an input when it should be driven high, and polling on the SCL line value until it goes high (indicating that the I2C slave is no longer pulling it low). This is enabled by default; for gpios which cannot be configured as inputs, the i2c-gpio,scl-output-only property can be used to fall back to the previous behavior. Signed-off-by: Michael Auchter Cc: Heiko Schocher --- doc/device-tree-bindings/i2c/i2c-gpio.txt | 2 ++ drivers/i2c/i2c-gpio.c| 23 ++- 2 files changed, 24 insertions(+), 1 deletion(-) 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 v4 03/17] clk: Unconditionally recursively en-/dis-able clocks
Hi Sean
> For clocks not in the CCF, their parents will not have UCLASS_CLK, so we
> just enable them as normal. The enable count is local to the struct clk,
> but this will never result in the actual en-/dis-able op being called
> (unless the same struct clk is enabled twice).
>
> For clocks in the CCF, we always traverse up the tree when enabling.
> Previously, CCF clocks without id set would be skipped, stopping the
> traversal too early.
>
> Signed-off-by: Sean Anderson
> Acked-by: Lukasz Majewski
> ---
>
> Changes in v4:
> - Lint
>
> Changes in v3:
> - New
>
> drivers/clk/clk-uclass.c | 59 ++--
> 1 file changed, 26 insertions(+), 33 deletions(-)
>
When I tried to apply this patch-set, there occur a conflict as below:
Applying: clk: Always use the supplied struct clk
Applying: clk: Check that ops of composite clock components exist before calling
Applying: clk: Unconditionally recursively en-/dis-able clocks
error: patch failed: drivers/clk/clk-uclass.c:491
error: drivers/clk/clk-uclass.c: patch does not apply
Patch failed at 0003 clk: Unconditionally recursively en-/dis-able clocks
Thanks
Rick
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index 246b9c0ab8..c5f87fee72 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -491,7 +491,6 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
> int clk_enable(struct clk *clk)
> {
> const struct clk_ops *ops;
> - struct clk *clkp = NULL;
> int ret;
>
> debug("%s(clk=%p \"%s\")\n", __func__, clk, clk->dev->name);
> @@ -500,32 +499,29 @@ int clk_enable(struct clk *clk)
> ops = clk_dev_ops(clk->dev);
>
> if (CONFIG_IS_ENABLED(CLK_CCF)) {
> - /* Take id 0 as a non-valid clk, such as dummy */
> - if (clk->id && !clk_get_by_id(clk->id, )) {
> - if (clkp->enable_count) {
> - clkp->enable_count++;
> - return 0;
> - }
> - if (clkp->dev->parent &&
> - device_get_uclass_id(clkp->dev) == UCLASS_CLK) {
> - ret =
> clk_enable(dev_get_clk_ptr(clkp->dev->parent));
> - if (ret) {
> - printf("Enable %s failed\n",
> - clkp->dev->parent->name);
> - return ret;
> - }
> + if (clk->enable_count) {
> + clk->enable_count++;
> + return 0;
> + }
> + if (clk->dev->parent &&
> + device_get_uclass_id(clk->dev->parent) == UCLASS_CLK) {
> + ret = clk_enable(dev_get_clk_ptr(clk->dev->parent));
> + if (ret) {
> + printf("Enable %s failed\n",
> + clk->dev->parent->name);
> + return ret;
> }
> }
>
> if (ops->enable) {
> ret = ops->enable(clk);
> if (ret) {
> - printf("Enable %s failed\n", clk->dev->name);
> + printf("Enable %s failed (error %d)\n",
> + clk->dev->name, ret);
> return ret;
> }
> }
> - if (clkp)
> - clkp->enable_count++;
> + clk->enable_count++;
> } else {
> if (!ops->enable)
> return -ENOSYS;
> @@ -551,7 +547,6 @@ int clk_enable_bulk(struct clk_bulk *bulk)
> int clk_disable(struct clk *clk)
> {
> const struct clk_ops *ops;
> - struct clk *clkp = NULL;
> int ret;
>
> debug("%s(clk=%p)\n", __func__, clk);
> @@ -560,29 +555,27 @@ int clk_disable(struct clk *clk)
> ops = clk_dev_ops(clk->dev);
>
> if (CONFIG_IS_ENABLED(CLK_CCF)) {
> - if (clk->id && !clk_get_by_id(clk->id, )) {
> - if (clkp->enable_count == 0) {
> - printf("clk %s already disabled\n",
> - clkp->dev->name);
> - return 0;
> - }
> -
> - if (--clkp->enable_count > 0)
> - return 0;
> + if (clk->enable_count == 0) {
> + printf("clk %s already disabled\n",
> + clk->dev->name);
> + return 0;
> }
>
> + if (--clk->enable_count > 0)
> + return 0;
> +
> if (ops->disable) {
>
Re: [PATCH 1/2] dm: i2c-gpio: rework gpio get/set functions
Hello Michael, Am 07.02.2020 um 17:55 schrieb Michael Auchter: This patch reworks i2c-gpio to make it easier to switch out the implementation of the sda/scl get/set functions. This is in preparation for a patch to conditionally implement clock stretching support. Signed-off-by: Michael Auchter Cc: Heiko Schocher --- drivers/i2c/i2c-gpio.c | 133 - 1 file changed, 64 insertions(+), 69 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 v4 12/17] riscv: Add a bypass clock for K210
Hi Sean > On 2/18/20 1:35 AM, Rick Chen wrote: > > Hi Sean > > > > This patch is relative about clock driver. > > It shall be named as clk instead of riscv > > Thanks > > Rick > > Should the other clock patches adding k210 clock support be prefixed > "clk:" as well? Sure, patch 11 and 13 as well Thanks Rick > > --Sean
Re: [PATCH 4/4] i2c: gpio: Run deblock sequence on probe
Hello Marek,
Am 07.02.2020 um 16:57 schrieb Marek Vasut:
Add deblock dequence for the I2C bus, needed on some devices. This sequence
is issued once, when probing the driver, and is controlled by DT property,
"i2c-gpio,deblock".
Signed-off-by: Marek Vasut
---
drivers/i2c/i2c-gpio.c | 15 +++
1 file changed, 15 insertions(+)
Nitpick: I see no entry in doc/device-tree-bindings/i2c/i2c-gpio.txt
for the new dts binding ... please send a follow up patch which adds it,
or a v2 for this one, thanks!
Reviewed-by: Heiko Schocher
bye,
Heiko
diff --git a/drivers/i2c/i2c-gpio.c b/drivers/i2c/i2c-gpio.c
index 4e8fa21473..b6b6ba9ee8 100644
--- a/drivers/i2c/i2c-gpio.c
+++ b/drivers/i2c/i2c-gpio.c
@@ -305,6 +305,20 @@ static int i2c_gpio_set_bus_speed(struct udevice *dev,
unsigned int speed_hz)
return 0;
}
+static int i2c_gpio_drv_probe(struct udevice *dev)
+{
+ if (dev_read_bool(dev, "i2c-gpio,deblock")) {
+ /* @200kHz 9 clocks = 44us, 62us is ok */
+ const unsigned int DELAY_ABORT_SEQ = 62;
+ struct i2c_gpio_bus *bus = dev_get_priv(dev);
+ return i2c_deblock_gpio_loop(>gpios[PIN_SDA],
+>gpios[PIN_SCL],
+16, 5, DELAY_ABORT_SEQ);
+ }
+
+ return 0;
+}
+
static int i2c_gpio_ofdata_to_platdata(struct udevice *dev)
{
struct i2c_gpio_bus *bus = dev_get_priv(dev);
@@ -341,6 +355,7 @@ U_BOOT_DRIVER(i2c_gpio) = {
.name = "i2c-gpio",
.id = UCLASS_I2C,
.of_match = i2c_gpio_ids,
+ .probe = i2c_gpio_drv_probe,
.ofdata_to_platdata = i2c_gpio_ofdata_to_platdata,
.priv_auto_alloc_size = sizeof(struct i2c_gpio_bus),
.ops= _gpio_ops,
--
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 3/4] i2c: Add option to send start condition after deblocking
Hello Marek,
Am 07.02.2020 um 16:57 schrieb Marek Vasut:
Add option to send start condition after deblocking SDA.
Signed-off-by: Marek Vasut
---
drivers/i2c/i2c-uclass.c | 23 ---
include/i2c.h| 4 +++-
2 files changed, 23 insertions(+), 4 deletions(-)
Reviewed-by: Heiko Schocher
diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
index 86f529241f..e9ec388576 100644
--- a/drivers/i2c/i2c-uclass.c
+++ b/drivers/i2c/i2c-uclass.c
@@ -504,9 +504,10 @@ static int i2c_gpio_get_pin(struct gpio_desc *pin)
int i2c_deblock_gpio_loop(struct gpio_desc *sda_pin,
struct gpio_desc *scl_pin,
unsigned int scl_count,
+ unsigned int start_count,
unsigned int delay)
{
- int ret = 0;
+ int i, ret = -EREMOTEIO;
i2c_gpio_set_pin(sda_pin, 1);
i2c_gpio_set_pin(scl_pin, 1);
@@ -518,8 +519,24 @@ int i2c_deblock_gpio_loop(struct gpio_desc *sda_pin,
udelay(delay);
i2c_gpio_set_pin(scl_pin, 0);
udelay(delay);
- if (i2c_gpio_get_pin(sda_pin))
+ if (i2c_gpio_get_pin(sda_pin)) {
+ ret = 0;
break;
+ }
+ }
+
+ if (!ret && start_count) {
+ for (i = 0; i < start_count; i++) {
+ /* Send start condition */
+ udelay(delay);
+ i2c_gpio_set_pin(sda_pin, 1);
+ udelay(delay);
+ i2c_gpio_set_pin(scl_pin, 1);
+ udelay(delay);
+ i2c_gpio_set_pin(sda_pin, 0);
+ udelay(delay);
+ i2c_gpio_set_pin(scl_pin, 0);
+ }
}
/* Then, send I2C stop */
@@ -562,7 +579,7 @@ static int i2c_deblock_gpio(struct udevice *bus)
goto out_no_pinctrl;
}
- ret0 = i2c_deblock_gpio_loop([PIN_SDA], [PIN_SCL], 9, 5);
+ ret0 = i2c_deblock_gpio_loop([PIN_SDA], [PIN_SCL], 9, 0, 5);
ret = pinctrl_select_state(bus, "default");
if (ret) {
diff --git a/include/i2c.h b/include/i2c.h
index 7c92042c58..059200115a 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -339,12 +339,14 @@ int i2c_deblock(struct udevice *bus);
* @sda_pin: SDA GPIO
* @scl_pin: SCL GPIO
* @scl_count:Number of SCL clock cycles generated to deblock SDA
+ * @start_count:Number of I2C start conditions sent after deblocking SDA
Is there a tab missing? If so I can add it, when applying this patch.
* @delay:Delay between SCL clock line changes
* @return 0 if OK, -ve on error
*/
struct gpio_desc;
int i2c_deblock_gpio_loop(struct gpio_desc *sda_pin, struct gpio_desc
*scl_pin,
- unsigned int scl_count, unsigned int delay);
+ unsigned int scl_count, unsigned int start_count,
+ unsigned int delay);
/**
* struct dm_i2c_ops - driver operations for I2C uclass
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 2/4] i2c: Export i2c_deblock_gpio_loop()
Hello Marek, Am 07.02.2020 um 16:57 schrieb Marek Vasut: Export the i2c_deblock_gpio_loop() so it can be used in other places in U-Boot. In particular, this is useful in the GPIO I2C driver, which claims the SDA/SCL GPIOs and thus prevents the i2c_deblock() implementation from claiming the pins as GPIOs again. Signed-off-by: Marek Vasut --- drivers/i2c/i2c-uclass.c | 8 include/i2c.h| 16 2 files changed, 20 insertions(+), 4 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 v4 12/17] riscv: Add a bypass clock for K210
On 2/18/20 1:35 AM, Rick Chen wrote: > Hi Sean > > This patch is relative about clock driver. > It shall be named as clk instead of riscv > Thanks > Rick Should the other clock patches adding k210 clock support be prefixed "clk:" as well? --Sean
Re: [PATCH 1/4] i2c: Make deblock delay and SCL clock configurable
Hello Marek, Am 07.02.2020 um 16:57 schrieb Marek Vasut: Make the delay between SCL line changes and the number of SCL clock changes configurable as a parameter of the deblock function. No functional change. Signed-off-by: Marek Vasut --- drivers/i2c/i2c-uclass.c | 21 +++-- 1 file changed, 11 insertions(+), 10 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
u-boot saveenv corrupted other MTD parttions
Hi, I have three MTD partitions, the mtd2 storage installed UBIFS volumes, first is dtb volume, second is kernel volume, third is rootfs volume. The saveenv was configured to save environment variables to NAND ubootenv. gpmi-nand:1m(boot),1m(ubootenv),-(storage) There was no issue to run NAND boot, but if I called saveenv in u-boot, then I run bootcmd again, it could not boot from NAND any more: Bad Linux ARM zImage magic! The saveenv does not take any parameters, how did it work to write to the NAND 1m(ubootenv)? => saveenv Saving Environment to NAND... Erasing NAND... Erasing at 0x5e -- 100% complete. Writing to NAND... OK It looks like that saveenv overwritten to the storage, is 0x5e RAM or NAND address? Where was that address defined? How do I know it was the NAND 1m(ubootenv) address? Thank you. Kind regards, - jh
Re: [PATCH v4 06/17] spi: dw: Add device tree properties for fields in CTRL1
On 2/18/20 1:05 AM, Rick Chen wrote: > Hi Sean > >> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Sean Anderson >> Sent: Tuesday, February 11, 2020 2:04 PM >> To: u-boot@lists.denx.de >> Cc: Rick Chen; Eugeniy Paltsev >> Subject: [PATCH v4 06/17] spi: dw: Add device tree properties for fields in >> CTRL1 >> >> Some devices have different layouts for the fields in CTRL1 (e.g. the >> Kendryte K210). Allow this layout to be configurable from the device tree. > > The description of CTRL1 here don't match with the below content of CTRL0. > Is it a typo ? Yes. I will fix the message in the next revision. --Sean
Re: [PATCH v4 12/17] riscv: Add a bypass clock for K210
Hi Sean
This patch is relative about clock driver.
It shall be named as clk instead of riscv
Thanks
Rick
> This is a small driver to do a software bypass of a clock if hardware
> bypass is not working. I have tried to write this in a generic fashion, so
> that it could be potentially broken out of the kendryte code at some future
> date. For the K210, it is used to have aclk bypass pll0 and use in0 instead
> so that the CPU keeps on working.
>
> Signed-off-by: Sean Anderson
> ---
>
> Changes in v4:
> - New
>
> drivers/clk/kendryte/Makefile | 2 +-
> drivers/clk/kendryte/bypass.c | 268 ++
> include/kendryte/bypass.h | 28
> 3 files changed, 297 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/kendryte/bypass.c
> create mode 100644 include/kendryte/bypass.h
>
> diff --git a/drivers/clk/kendryte/Makefile b/drivers/clk/kendryte/Makefile
> index c56d93ea1c..47f682fce3 100644
> --- a/drivers/clk/kendryte/Makefile
> +++ b/drivers/clk/kendryte/Makefile
> @@ -1 +1 @@
> -obj-y += pll.o
> +obj-y += bypass.o pll.o
> diff --git a/drivers/clk/kendryte/bypass.c b/drivers/clk/kendryte/bypass.c
> new file mode 100644
> index 00..5276591bfd
> --- /dev/null
> +++ b/drivers/clk/kendryte/bypass.c
> @@ -0,0 +1,268 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Sean Anderson
> + */
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#define LOG_CATEGORY UCLASS_CLK
> +#include
> +#include
> +
> +#define CLK_K210_BYPASS "k210_clk_bypass"
> +
> +/*
> + * This is a small driver to do a software bypass of a clock if hardware
> bypass
> + * is not working. I have tried to write this in a generic fashion, so that
> it
> + * could be potentially broken out of the kendryte code at some future date.
> + *
> + * Say you have the following clock configuration
> + *
> + * +---+ +---+
> + * |osc| |pll|
> + * +---+ +---+
> + * ^
> + */|
> + * / |
> + * / |
> + * / |
> + */|
> + * +---+ +---+
> + * |clk| |clk|
> + * +---+ +---+
> + *
> + * But the pll does not have a bypass, so when you configure the pll, the
> + * configuration needs to change to look like
> + *
> + * +---+ +---+
> + * |osc| |pll|
> + * +---+ +---+
> + * ^
> + * |\
> + * | \
> + * | \
> + * | \
> + * |\
> + * +---+ +---+
> + * |clk| |clk|
> + * +---+ +---+
> + *
> + * To set this up, create a bypass clock with bypassee=pll and alt=osc. When
> + * creating the child clocks, set their parent to the bypass clock. After
> + * creating all the children, call k210_bypass_setchildren().
> + */
> +
> +static int k210_bypass_dobypass(struct k210_bypass *bypass)
> +{
> + int ret, i;
> +
> + /*
> +* If we already have saved parents, then the children are already
> +* bypassed
> +*/
> + if (bypass->child_count && bypass->saved_parents[0])
> + return 0;
> +
> + for (i = 0; i < bypass->child_count; i++) {
> + struct clk *child = bypass->children[i];
> + struct clk *parent = clk_get_parent(child);
> +
> + if (IS_ERR(parent)) {
> + for (; i; i--)
> + bypass->saved_parents[i] = NULL;
> + return PTR_ERR(parent);
> + }
> + bypass->saved_parents[i] = parent;
> + }
> +
> + for (i = 0; i < bypass->child_count; i++) {
> + struct clk *child = bypass->children[i];
> +
> + ret = clk_set_parent(child, bypass->alt);
> + if (ret) {
> + for (; i; i--)
> + clk_set_parent(bypass->children[i],
> + bypass->saved_parents[i]);
> + for (i = 0; i < bypass->child_count; i++)
> + bypass->saved_parents[i] = NULL;
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int k210_bypass_unbypass(struct k210_bypass *bypass)
> +{
> + int err, ret, i;
> +
> + if (!bypass->child_count && !bypass->saved_parents[0]) {
> + log_warning("Cannot unbypass children; dobypass not called
> first\n");
> + return 0;
> + }
> +
> + ret = 0;
> + for (i = 0; i < bypass->child_count; i++) {
> + err = clk_set_parent(bypass->children[i],
> +bypass->saved_parents[i]);
> + if (err)
> + ret = err;
> + bypass->saved_parents[i] = NULL;
> + }
> + return ret;
> +}
> +
> +static ulong k210_bypass_get_rate(struct clk *clk)
> +{
> + struct k210_bypass *bypass = to_k210_bypass(clk);
> + const struct clk_ops *ops = bypass->bypassee_ops;
> +
> + if (ops->get_rate)
> + return ops->get_rate(bypass->bypassee);
> + else
> +
Re: [PATCH v4 06/17] spi: dw: Add device tree properties for fields in CTRL1
Hi Sean
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Sean Anderson
> Sent: Tuesday, February 11, 2020 2:04 PM
> To: u-boot@lists.denx.de
> Cc: Rick Chen; Eugeniy Paltsev
> Subject: [PATCH v4 06/17] spi: dw: Add device tree properties for fields in
> CTRL1
>
> Some devices have different layouts for the fields in CTRL1 (e.g. the
> Kendryte K210). Allow this layout to be configurable from the device tree.
The description of CTRL1 here don't match with the below content of CTRL0.
Is it a typo ?
Thanks
Rick
> The documentation has been taken from Linux.
>
> Signed-off-by: Sean Anderson
> ---
>
> Changes in v4:
> - New
>
> .../spi/snps,dw-apb-ssi.txt | 43 +++
> drivers/spi/designware_spi.c | 40 ++---
> 2 files changed, 68 insertions(+), 15 deletions(-) create mode 100644
> doc/device-tree-bindings/spi/snps,dw-apb-ssi.txt
>
> diff --git a/doc/device-tree-bindings/spi/snps,dw-apb-ssi.txt
> b/doc/device-tree-bindings/spi/snps,dw-apb-ssi.txt
> new file mode 100644
> index 00..4b6152f6b7
> --- /dev/null
> +++ b/doc/device-tree-bindings/spi/snps,dw-apb-ssi.txt
> @@ -0,0 +1,43 @@
> +Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface.
> +
> +Required properties:
> +- compatible : "snps,dw-apb-ssi"
> +- reg : The register base for the controller. For "mscc,-spi", a
> +second
> + register set is required (named ICPU_CFG:SPI_MST)
> +- #address-cells : <1>, as required by generic SPI binding.
> +- #size-cells : <0>, also as required by generic SPI binding.
> +- clocks : phandles for the clocks, see the description of clock-names below.
> + The phandle for the "ssi_clk" is required. The phandle for the "pclk"
> clock
> + is optional. If a single clock is specified but no clock-name, it is the
> + "ssi_clk" clock. If both clocks are listed, the "ssi_clk" must be first.
> +
> +Optional properties:
> +- clock-names : Contains the names of the clocks:
> +"ssi_clk", for the core clock used to generate the external SPI clock.
> +"pclk", the interface clock, required for register access.
> +- cs-gpios : Specifies the gpio pins to be used for chipselects.
> +- num-cs : The number of chipselects. If omitted, this will default to 4.
> +- reg-io-width : The I/O register width (in bytes) implemented by this
> + device. Supported values are 2 or 4 (the default).
> +- snps,dfs-offset The offset in bits of the DFS field in CTRL0,
> +defaulting to 0
> +- snps,frf-offset The offset in bits of the FRF field in CTRL0,
> +defaulting to 4
> +- snps,tmod-offset The offset in bits of the tmode field in CTRL0,
> +defaulting
> + to 6
> +- snps,mode-offset The offset in bits of the work mode field in CTRL0,
> + defaulting to 8
> +
> +Child nodes as per the generic SPI binding.
> +
> +Example:
> +
> + spi@fff0 {
> + compatible = "snps,dw-apb-ssi";
> + reg = <0xfff0 0x1000>;
> + interrupts = <0 154 4>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <_m_clk>;
> + num-cs = <2>;
> + cs-gpios = < 13 0>,
> + < 14 0>;
> + };
> diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
> index 66ff8eeccd..04cc873754 100644
> --- a/drivers/spi/designware_spi.c
> +++ b/drivers/spi/designware_spi.c
> @@ -3,6 +3,7 @@
> * Designware master SPI core controller driver
> *
> * Copyright (C) 2014 Stefan Roese
> + * Copyright (C) 2020 Sean Anderson
> *
> * Very loosely based on the Linux driver:
> * drivers/spi/spi-dw.c, which is:
> @@ -50,20 +51,14 @@
> #define DW_SPI_DR 0x60
>
> /* Bit fields in CTRLR0 */
> -#define SPI_DFS_OFFSET 0
> -
> -#define SPI_FRF_OFFSET 4
> #define SPI_FRF_SPI0x0
> #define SPI_FRF_SSP0x1
> #define SPI_FRF_MICROWIRE 0x2
> #define SPI_FRF_RESV 0x3
>
> -#define SPI_MODE_OFFSET6
> -#define SPI_SCPH_OFFSET6
> -#define SPI_SCOL_OFFSET7
> +#define SPI_MODE_SCPH 0x1
> +#define SPI_MODE_SCOL 0x2
>
> -#define SPI_TMOD_OFFSET8
> -#define SPI_TMOD_MASK (0x3 << SPI_TMOD_OFFSET)
> #defineSPI_TMOD_TR 0x0 /* xmit &
> recv */
> #define SPI_TMOD_TO0x1 /* xmit only */
> #define SPI_TMOD_RO0x2 /* recv only */
> @@ -88,6 +83,12 @@
> struct dw_spi_platdata {
> s32 frequency; /* Default clock frequency, -1 for none */
> void __iomem *regs;
> +
> + /* Offsets in CTRL0 */
> + u8 dfs_off;
> + u8 frf_off;
> + u8 tmod_off;
> + u8 mode_off;
> };
>
> struct dw_spi_priv {
> @@ -114,6 +115,15 @@ struct
Re: use invd instead of wbinvd in real mode start code
Hello Andy, Am 17.02.2020 um 17:04 schrieb Wolfgang Denk: Dear Andy, In message you wrote: On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wrote: In message you wrote: git bisect is the usual way to figure out the culprit. Too much work to do this way. If you find bisecting is too much work you probably still do it manually. Why don't you use tbot to automize such boring and time consuming tasks? Bisection time something about 10%, while 90% is flashing the board and, given the result, triggering either bad or good next cycle. Yes, and this is exactly what tbot was made for - automating such repeating, boring activities. It is wasted life time to do this manually. Yes, that is one benefit if you use tbot, see git bisect help: http://tbot.tools/modules/tc.html?highlight=bisect#tbot.tc.git.GitRepository.bisect You only have to pass to the function the good commit as string and a tbot python function which tests the current commit. This test function now can call other functions like run a complete build of current source, copy the resulting images let say to a tftp directory, install the new images on the device, reboot it and run tests on the U-Boot comamndline on the real board ... So using tbot for the complete development process makes a lot of sense, also as you have at the end a complete setup for testing your board (not only U-Boot also linux or other commandline based machines are possible to automate), it is easy to start a CI ... as tbot is a commandline tool a simple cron job is enough .. or you can integrate it easily into jenkins, buildbot, gitlab CI runner ... whatever CI you use... If you want to get help setting up tbot, feel free to ask me or Harald directly or on the tbot mailinglist: https://lists.denx.de/listinfo/tbot 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
[PATCH v2 09/10] arm64: dts: ti: am654-base-board: add ICSSG2 Ethernet support
ICSSG2 provide dual Gigabit Ethernet support.
Currently mdio clock is part of this node and also
the icssg2_rgmii_pins_default pinmux node has the
mdio pins as there is no davinci mdio driver.
Currently icssg2 instances are supported.
Either mii0 or mii1 can be enabled at a time.
Signed-off-by: Keerthy
---
Changes in v2:
* Removed a bunch of inconsistent white space in pins definition.
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 117 +++
1 file changed, 117 insertions(+)
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index a5aee02eb8..31038b7802 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -16,6 +16,64 @@
serial2 = _uart0;
ethernet0 = _port1;
};
+
+ /* Dual Ethernet application node on PRU-ICSSG2 */
+ pruss2_eth: pruss2_eth {
+ compatible = "ti,am654-icssg-prueth";
+ pinctrl-names = "default";
+ pinctrl-0 = <_rgmii_pins_default>;
+ sram = <_sram>;
+ clocks = <_clks 64 3>;
+ clock-names = "mdio_fck";
+ u-boot,dm-spl;
+
+ prus = <_0>, <_0>, <_1>, <_1>;
+ firmware-name = "ti-pruss/am65x-pru0-prueth-fw.elf",
+ "ti-pruss/am65x-rtu0-prueth-fw.elf",
+ "ti-pruss/am65x-pru1-prueth-fw.elf",
+ "ti-pruss/am65x-rtu1-prueth-fw.elf";
+ mii-g-rt = <_mii_g_rt>;
+ mii-rt = <_mii_rt>;
+ dma-coherent;
+ dmas = <_udmap 0 UDMA_DIR_TX>, /* egress slice
0 */
+ <_udmap 1 UDMA_DIR_TX>, /* egress slice 0 */
+ <_udmap 2 UDMA_DIR_TX>, /* egress slice 0 */
+ <_udmap 3 UDMA_DIR_TX>, /* mgmnt cmd slice 0
*/
+ <_udmap 4 UDMA_DIR_TX>, /* egress slice 1 */
+ <_udmap 5 UDMA_DIR_TX>, /* egress slice 1 */
+ <_udmap 6 UDMA_DIR_TX>, /* egress slice 1 */
+ <_udmap 7 UDMA_DIR_TX>, /* mgmnt cmd slice 1
*/
+
+ <_udmap 0 UDMA_DIR_RX>, /* ingress slice 0 */
+ <_udmap 1 UDMA_DIR_RX>, /* ingress slice 1 */
+ <_udmap 2 UDMA_DIR_RX>, /* mgmnt rsp slice 0
*/
+ <_udmap 3 UDMA_DIR_RX>; /* mgmnt rsp slice 1
*/
+ dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
+ "tx1-0", "tx1-1", "tx1-2", "tx1-3",
+ "rx0", "rx1",
+ "rxmgm0", "rxmgm1";
+
+ pruss2_emac0: ethernet-mii0 {
+ phy-handle = <_eth0_phy>;
+ phy-mode = "rgmii-rxid";
+ syscon-rgmii-delay = <_conf 0x4120>;
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+
+/*
+ * Commenting out the second mii interface as the framework
+ * supports one interface in a single probe
+ * So either mii1 or mii2 can be used. In case mii1 is needed
+ * uncomment mii1 and comment out mii0
+ pruss2_emac1: ethernet-mii1 {
+ phy-handle = <_eth1_phy>;
+ phy-mode = "rgmii-rxid";
+ syscon-rgmii-delay = <_conf 0x4124>;
+ local-mac-address = [00 00 00 00 00 00];
+ };
+*/
+ };
};
_main{
@@ -275,6 +333,47 @@
u-boot,dm-spl;
};
+ icssg2_rgmii_pins_default: icssg2_rgmii_pins_default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x00ac, PIN_INPUT, 2) /* (AH15)
PRG2_PRU1_GPO0.PRG2_RGMII2_RD0 */
+ AM65X_IOPAD(0x00b0, PIN_INPUT, 2) /* (AC16)
PRG2_PRU1_GPO1.PRG2_RGMII2_RD1 */
+ AM65X_IOPAD(0x00b4, PIN_INPUT, 2) /* (AD17)
PRG2_PRU1_GPO2.PRG2_RGMII2_RD2 */
+ AM65X_IOPAD(0x00b8, PIN_INPUT, 2) /* (AH14)
PRG2_PRU1_GPO3.PRG2_RGMII2_RD3 */
+ AM65X_IOPAD(0x00cc, PIN_OUTPUT, 2) /* (AD15)
PRG2_PRU1_GPO8.PRG2_RGMII2_TD0 */
+ AM65X_IOPAD(0x00d0, PIN_OUTPUT, 2) /* (AF14)
PRG2_PRU1_GPO9.PRG2_RGMII2_TD1 */
+ AM65X_IOPAD(0x00d4, PIN_OUTPUT, 2) /* (AC15)
PRG2_PRU1_GPO10.PRG2_RGMII2_TD2 */
+ AM65X_IOPAD(0x00d8, PIN_OUTPUT, 2) /* (AD14)
PRG2_PRU1_GPO11.PRG2_RGMII2_TD3 */
+ AM65X_IOPAD(0x00dc, PIN_INPUT, 2) /* (AE14)
PRG2_PRU1_GPO16.PRG2_RGMII2_TXC */
+ AM65X_IOPAD(0x00c4, PIN_OUTPUT, 2) /* (AC17)
PRG2_PRU1_GPO6.PRG2_RGMII2_TX_CTL */
+ AM65X_IOPAD(0x00c0, PIN_INPUT, 2) /* (AG15)
PRG2_PRU1_GPO5.PRG2_RGMII2_RXC */
+ AM65X_IOPAD(0x00bc, PIN_INPUT, 2) /* (AG14)
[PATCH v2 10/10] configs: am65x_evm_a53_defconfig: Enable CONFIG_TI_AM64_ICSSG_PRUETH
Enable ICSSG_PRUETH & related configs. This enables ethernet functionality on PRU. Signed-off-by: Keerthy --- configs/am65x_evm_a53_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index 079cd912ba..1b0bfe6444 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -84,6 +84,7 @@ CONFIG_DM_ETH=y CONFIG_E1000=y CONFIG_CMD_E1000=y CONFIG_TI_AM65_CPSW_NUSS=y +CONFIG_TI_AM64_ICSSG_PRUETH=y CONFIG_PCI=y CONFIG_DM_PCI=y CONFIG_PCI_KEYSTONE=y @@ -98,10 +99,12 @@ CONFIG_PINCTRL_SINGLE=y CONFIG_POWER_DOMAIN=y CONFIG_TI_SCI_POWER_DOMAIN=y CONFIG_REMOTEPROC_TI_K3_R5F=y +CONFIG_REMOTEPROC_TI_PRU=y CONFIG_DM_RESET=y CONFIG_RESET_TI_SCI=y CONFIG_DM_SERIAL=y CONFIG_SOC_TI=y +CONFIG_TI_PRUSS=y CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y CONFIG_SYSRESET_TI_SCI=y -- 2.17.1
[PATCH v2 07/10] arm: dts: k3-am65-main: Add scm_conf node
Add scm_conf node needed for prueth.
Signed-off-by: Keerthy
---
arch/arm/dts/k3-am65-main.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index 631134cd65..71a540376f 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -53,6 +53,14 @@
};
};
+ scm_conf: scm_conf@10 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0 0x0010 0 0x1c000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x0010 0x1c000>;
+ };
+
secure_proxy_main: mailbox@32c0 {
compatible = "ti,am654-secure-proxy";
#mbox-cells = <1>;
--
2.17.1
[PATCH v2 04/10] net: ti: icssg-prueth: Add ICSSG ethernet driver
This is the Ethernet driver for TI SoCs with the
ICSSG PRU Sub-system running EMAC firmware.
This driver caters to either of the slices(pru/rtu pair)
of the icssg subsystem.
Following are the firmwares needed to run cores:
am65x-pru0-prueth-fw.elf for pru0 of slice0
am65x-rtu0-prueth-fw.elf for rtu0 of slice0
am65x-pru1-prueth-fw.elf for pru1 of slice1
am65x-rtu1-prueth-fw.elf for rtu1 of slice1
One and exactly one of the slices is supported
as the u-boot ethernet supports probing one interface
at a time.
Signed-off-by: Keerthy
---
Changes in v2:
* Added guards defines for icssg.h
* returning errors which were missed in v1
* Removed unused prueth_print_buf function.
* Removed usage misc_of_init and used uclass_get_device_by_ofnode
in place of that.
* Introduced started variable to keep track of the status of the
prueth device.
drivers/net/ti/Kconfig| 8 +
drivers/net/ti/Makefile | 1 +
drivers/net/ti/icssg-prueth.c | 652 ++
drivers/net/ti/icssg.h| 36 ++
drivers/net/ti/icssg_classifier.c | 396 ++
5 files changed, 1093 insertions(+)
create mode 100644 drivers/net/ti/icssg-prueth.c
create mode 100644 drivers/net/ti/icssg.h
create mode 100644 drivers/net/ti/icssg_classifier.c
diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
index ecf642de10..1b6285709f 100644
--- a/drivers/net/ti/Kconfig
+++ b/drivers/net/ti/Kconfig
@@ -26,3 +26,11 @@ config TI_AM65_CPSW_NUSS
help
This driver supports TI K3 MCU CPSW Nuss Ethernet controller
in Texas Instruments K3 AM65x SoCs.
+
+config TI_AM64_ICSSG_PRUETH
+ bool "TI Gigabit PRU Ethernet driver"
+ depends on ARCH_K3
+ select PHYLIB
+ help
+ Support Gigabit Ethernet ports over the ICSSG PRU Subsystem
+ This subsystem is available starting with the AM65 platform.
diff --git a/drivers/net/ti/Makefile b/drivers/net/ti/Makefile
index 8d3808bb4b..b486498909 100644
--- a/drivers/net/ti/Makefile
+++ b/drivers/net/ti/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o cpsw_mdio.o
obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o cpsw_mdio.o
obj-$(CONFIG_TI_AM65_CPSW_NUSS) += am65-cpsw-nuss.o cpsw_mdio.o
+obj-$(CONFIG_TI_AM64_ICSSG_PRUETH) += icssg-prueth.o cpsw_mdio.o
icssg_classifier.o
diff --git a/drivers/net/ti/icssg-prueth.c b/drivers/net/ti/icssg-prueth.c
new file mode 100644
index 00..0a85ca3ab5
--- /dev/null
+++ b/drivers/net/ti/icssg-prueth.c
@@ -0,0 +1,652 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Texas Instruments PRU Ethernet Driver
+ *
+ * Copyright (C) 2020, Texas Instruments, Incorporated
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cpsw_mdio.h"
+#include "icssg.h"
+
+#define ICSS_SLICE0 0
+#define ICSS_SLICE1 1
+
+#ifdef PKTSIZE_ALIGN
+#define UDMA_RX_BUF_SIZE PKTSIZE_ALIGN
+#else
+#define UDMA_RX_BUF_SIZE ALIGN(1522, ARCH_DMA_MINALIGN)
+#endif
+
+#ifdef PKTBUFSRX
+#define UDMA_RX_DESC_NUM PKTBUFSRX
+#else
+#define UDMA_RX_DESC_NUM 4
+#endif
+
+enum prueth_mac {
+ PRUETH_MAC0 = 0,
+ PRUETH_MAC1,
+ PRUETH_NUM_MACS,
+};
+
+enum prueth_port {
+ PRUETH_PORT_HOST = 0, /* host side port */
+ PRUETH_PORT_MII0, /* physical port MII 0 */
+ PRUETH_PORT_MII1, /* physical port MII 1 */
+};
+
+/* Config region lies in shared RAM */
+#define ICSS_CONFIG_OFFSET_SLICE0 0
+#define ICSS_CONFIG_OFFSET_SLICE1 0x8000
+
+/* Firmware flags */
+#define ICSS_SET_RUN_FLAG_VLAN_ENABLE BIT(0) /* switch only */
+#define ICSS_SET_RUN_FLAG_FLOOD_UNICASTBIT(1) /* switch only
*/
+#define ICSS_SET_RUN_FLAG_PROMISC BIT(2) /* MAC only */
+#define ICSS_SET_RUN_FLAG_MULTICAST_PROMISCBIT(3) /* MAC only */
+
+/* CTRLMMR_ICSSG_RGMII_CTRL register bits */
+#define ICSSG_CTRL_RGMII_ID_MODE BIT(24)
+
+/**
+ * enum pruss_pru_id - PRU core identifiers
+ */
+enum pruss_pru_id {
+ PRUSS_PRU0 = 0,
+ PRUSS_PRU1,
+ PRUSS_NUM_PRUS,
+};
+
+struct prueth {
+ struct udevice *dev;
+ struct regmap *miig_rt;
+ struct regmap *mii_rt;
+ fdt_addr_t mdio_base;
+ phys_addr_t pruss_shrdram2;
+ phys_addr_t tmaddr;
+ struct mii_dev *bus;
+ u32 port_id;
+ u32 sram_pa;
+ struct phy_device *phydev;
+ boolhas_phy;
+ ofnode phy_node;
+ u32 phy_addr;
+ ofnode eth_node[PRUETH_NUM_MACS];
+ struct icssg_config
[PATCH v2 06/10] arm: dts: k3-am654-base-board-u-boot: Add icssg specific msmc_ram carveout nodes
Add icssg specific msmc_ram carveout nodes
Signed-off-by: Keerthy
---
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index a349edcfa5..a5aee02eb8 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -365,3 +365,15 @@
{
dr_mode = "peripheral";
};
+
+_ram {
+ icssg0_sram: icssg0-sram@4 {
+ reg = <0x4 0x1>;
+ };
+ icssg1_sram: icssg1-sram@5 {
+ reg = <0x5 0x1>;
+ };
+ icssg2_sram: icssg2-sram@6 {
+ reg = <0x6 0x1>;
+ };
+};
--
2.17.1
[PATCH v2 05/10] arm: dts: k3-am65-main: Add msmc_ram node
Add msmc_ram node needed for prueth
Signed-off-by: Keerthy
---
Changes in v2:
* Aligned trailing 0s for consistency.
arch/arm/dts/k3-am65-main.dtsi | 21 +
arch/arm/dts/k3-am65.dtsi | 4 +++-
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index ab40dafceb..631134cd65 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -9,6 +9,27 @@
#include
_main {
+ msmc_ram: sram@7000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x7000 0x0 0x20>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x7000 0x20>;
+ u-boot,dm-spl;
+
+ atf-sram@0 {
+ reg = <0x0 0x2>;
+ };
+
+ sysfw-sram@f {
+ reg = <0xf 0x1>;
+ };
+
+ l3cache-sram@10 {
+ reg = <0x10 0x10>;
+ };
+ };
+
gic500: interrupt-controller@180 {
compatible = "arm,gic-v3";
#address-cells = <2>;
diff --git a/arch/arm/dts/k3-am65.dtsi b/arch/arm/dts/k3-am65.dtsi
index 3ead944640..b2e967aaf7 100644
--- a/arch/arm/dts/k3-am65.dtsi
+++ b/arch/arm/dts/k3-am65.dtsi
@@ -79,7 +79,9 @@
<0x00 0x4204 0x00 0x4204 0x00 0x03ac2400>,
<0x00 0x4510 0x00 0x4510 0x00 0x00c24000>,
<0x00 0x4600 0x00 0x4600 0x00 0x0020>,
-<0x00 0x4700 0x00 0x4700 0x00 0x00068400>;
+<0x00 0x4700 0x00 0x4700 0x00 0x00068400>,
+<0x07 0x 0x07 0x 0x01 0x>,
+<0x00 0x7000 0x00 0x7000 0x00 0x0020>;
cbass_mcu: interconnect@2838 {
compatible = "simple-bus";
--
2.17.1
[PATCH v2 08/10] arm: dts: k3-am65-main: Add pruss nodes for ICSSG2
Add pruss nodes. This is based 4.19 DT with interrupt properties
removed from pur/rtu nodes.
Signed-off-by: Keerthy
---
arch/arm/dts/k3-am65-main.dtsi | 162 +
1 file changed, 162 insertions(+)
diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index 71a540376f..7499bab309 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -8,6 +8,8 @@
#include
#include
+#include
+
_main {
msmc_ram: sram@7000 {
compatible = "mmio-sram";
@@ -358,4 +360,164 @@
#phy-cells = <0>;
ti,dis-chg-det-quirk;
};
+
+ icssg2: icssg@b20 {
+ compatible = "ti,am654-icssg";
+ power-domains = <_pds 64 TI_SCI_PD_EXCLUSIVE>;
+ reg = <0xb20 0x8>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ dma-ranges;
+ ti,psil-base = <0x4300>;/* ICSSG2 PSIL thread start */
+
+ ti,psil-config0 {
+ linux,udma-mode = ;
+ statictr-type = ;
+ ti,needs-epib;
+ ti,psd-size = <16>;
+ };
+
+ ti,psil-config1 {
+ linux,udma-mode = ;
+ statictr-type = ;
+ ti,needs-epib;
+ ti,psd-size = <16>;
+ };
+
+ ti,psil-config2 {
+ linux,udma-mode = ;
+ statictr-type = ;
+ ti,needs-epib;
+ ti,psd-size = <16>;
+ };
+
+ ti,psil-config3 {
+ linux,udma-mode = ;
+ statictr-type = ;
+ ti,needs-epib;
+ ti,psd-size = <16>;
+ };
+
+ ti,psil-config4 {
+ linux,udma-mode = ;
+ statictr-type = ;
+ ti,needs-epib;
+ ti,psd-size = <16>;
+ };
+
+ ti,psil-config5 {
+ linux,udma-mode = ;
+ statictr-type = ;
+ ti,needs-epib;
+ ti,psd-size = <16>;
+ };
+
+ ti,psil-config6 {
+ linux,udma-mode = ;
+ statictr-type = ;
+ ti,needs-epib;
+ ti,psd-size = <16>;
+ };
+
+ ti,psil-config7 {
+ linux,udma-mode = ;
+ statictr-type = ;
+ ti,needs-epib;
+ ti,psd-size = <16>;
+ };
+
+ icssg2_mem: memories@b20 {
+ reg = <0xb20 0x2000>,
+ <0xb202000 0x2000>,
+ <0xb21 0x1>;
+ reg-names = "dram0", "dram1",
+ "shrdram2";
+ };
+
+ icssg2_cfg: cfg@b226000 {
+ compatible = "syscon";
+ reg = <0xb226000 0x200>;
+ };
+
+ icssg2_iep: iep@b22e000 {
+ compatible = "syscon";
+ reg = <0xb22e000 0x1000>;
+ };
+
+ icssg2_mii_rt: mii-rt@b232000 {
+ compatible = "syscon";
+ reg = <0xb232000 0x100>;
+ };
+
+ icssg2_mii_g_rt: mii-g-rt@b233000 {
+ compatible = "syscon";
+ reg = <0xb233000 0x1000>;
+ };
+
+ icssg2_intc: interrupt-controller@b22 {
+ compatible = "ti,am654-icssg-intc";
+ reg = <0xb22 0x2000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+;
+ interrupt-names = "host2", "host3", "host4",
+ "host5", "host6", "host7",
+ "host8", "host9";
+ };
+
+ pru2_0: pru@b234000 {
+ compatible = "ti,am654-pru";
+ reg = <0xb234000 0x4000>,
+ <0xb222000 0x100>,
+ <0xb222400 0x100>;
+ reg-names = "iram", "control", "debug";
+ firmware-name = "am65x-pru2_0-fw";
+ };
+
[PATCH v2 01/10] net: eth-uclass: eth_get_dev based on SEQ_ALIAS instead of probe order
In case of multiple eth interfaces currently eth_get_dev
fetches the device based on the probe order which can be
random hence try with the alias.
Signed-off-by: Keerthy
---
Changes in v2:
* Fixed comments from Tom & Lokesh as per:
https://patchwork.ozlabs.org/patch/1142697/
net/eth-uclass.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index ed81cbd537..93855e933b 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -68,9 +68,15 @@ struct udevice *eth_get_dev(void)
struct eth_uclass_priv *uc_priv;
uc_priv = eth_get_uclass_priv();
- if (!uc_priv->current)
- eth_errno = uclass_first_device(UCLASS_ETH,
- _priv->current);
+
+ if (!uc_priv->current) {
+ eth_errno = uclass_get_device_by_seq(UCLASS_ETH, 0,
+_priv->current);
+ if (eth_errno || !uc_priv->current)
+eth_errno = uclass_first_device(UCLASS_ETH,
+_priv->current);
+ }
+
return uc_priv->current;
}
--
2.17.1
[PATCH v2 03/10] remoteproc: pruss: add PRU remoteproc driver
The Programmable Real-Time Unit Subsystem (PRUSS) consists of
dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs)
for program execution. This patch adds a remoteproc platform
driver for managing the individual PRU RISC cores life cycle.
The driver currently supports the AM65xx SoC
Signed-off-by: Keerthy
---
drivers/remoteproc/Kconfig | 11 +
drivers/remoteproc/Makefile| 1 +
drivers/remoteproc/pru_rproc.c | 405 +
3 files changed, 417 insertions(+)
create mode 100644 drivers/remoteproc/pru_rproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 7c2e4804b5..24e536463b 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -81,4 +81,15 @@ config REMOTEPROC_TI_POWER
help
Say 'y' here to add support for TI power processors such as those
found on certain TI keystone and OMAP generation SoCs.
+
+config REMOTEPROC_TI_PRU
+ bool "Support for TI's K3 based PRU remoteproc driver"
+ select REMOTEPROC
+ depends on DM
+ depends on TI_PRUSS
+ depends on ARCH_K3
+ depends on OF_CONTROL
+ help
+ Say 'y' here to add support for TI' K3 remoteproc driver.
+
endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 69ae7bd1e8..f0e83451d6 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_REMOTEPROC_TI_K3_ARM64) += ti_k3_arm64_rproc.o
obj-$(CONFIG_REMOTEPROC_TI_K3_DSP) += ti_k3_dsp_rproc.o
obj-$(CONFIG_REMOTEPROC_TI_K3_R5F) += ti_k3_r5f_rproc.o
obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
+obj-$(CONFIG_REMOTEPROC_TI_PRU) += pru_rproc.o
diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
new file mode 100644
index 00..832cffb1a0
--- /dev/null
+++ b/drivers/remoteproc/pru_rproc.c
@@ -0,0 +1,405 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PRU-RTU remoteproc driver for various SoCs
+ *
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+ * Keerthy
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PRU_ICSS_PRU_CTRL registers */
+#define PRU_CTRL_CTRL 0x
+#define PRU_CTRL_STS 0x0004
+#define PRU_CTRL_WAKEUP_EN 0x0008
+#define PRU_CTRL_CYCLE 0x000C
+#define PRU_CTRL_STALL 0x0010
+#define PRU_CTRL_CTBIR00x0020
+#define PRU_CTRL_CTBIR10x0024
+#define PRU_CTRL_CTPPR00x0028
+#define PRU_CTRL_CTPPR10x002C
+
+/* CTRL register bit-fields */
+#define CTRL_CTRL_SOFT_RST_N BIT(0)
+#define CTRL_CTRL_EN BIT(1)
+#define CTRL_CTRL_SLEEPING BIT(2)
+#define CTRL_CTRL_CTR_EN BIT(3)
+#define CTRL_CTRL_SINGLE_STEP BIT(8)
+#define CTRL_CTRL_RUNSTATE BIT(15)
+
+#define RPROC_FLAGS_SHIFT 16
+#define RPROC_FLAGS_NONE 0
+#define RPROC_FLAGS_ELF_PHDR BIT(0 + RPROC_FLAGS_SHIFT)
+#define RPROC_FLAGS_ELF_SHDR BIT(1 + RPROC_FLAGS_SHIFT)
+
+/**
+ * enum pru_mem - PRU core memory range identifiers
+ */
+enum pru_mem {
+ PRU_MEM_IRAM = 0,
+ PRU_MEM_CTRL,
+ PRU_MEM_DEBUG,
+ PRU_MEM_MAX,
+};
+
+struct pru_privdata {
+ phys_addr_t pru_iram;
+ phys_addr_t pru_ctrl;
+ phys_addr_t pru_debug;
+ fdt_size_t pru_iramsz;
+ fdt_size_t pru_ctrlsz;
+ fdt_size_t pru_debugsz;
+ const char *fw_name;
+ u32 iram_da;
+ u32 pdram_da;
+ u32 sdram_da;
+ u32 shrdram_da;
+ u32 bootaddr;
+ int id;
+ struct pruss *prusspriv;
+};
+
+/**
+ * pru_start() - start the pru processor
+ * @dev: corresponding k3 remote processor device
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int pru_start(struct udevice *dev)
+{
+ struct pru_privdata *priv;
+ int val = 0;
+
+ priv = dev_get_priv(dev);
+
+ val = CTRL_CTRL_EN | ((priv->bootaddr >> 2) << 16);
+ writel(val, priv->pru_ctrl + PRU_CTRL_CTRL);
+
+ return 0;
+}
+
+/**
+ * pru_stop() - Stop pru processor
+ * @dev: corresponding k3 remote processor device
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int pru_stop(struct udevice *dev)
+{
+ struct pru_privdata *priv;
+ int val = 0;
+
+ priv = dev_get_priv(dev);
+
+ val = readl(priv->pru_ctrl + PRU_CTRL_CTRL);
+ val &= ~CTRL_CTRL_EN;
+ writel(val, priv->pru_ctrl + PRU_CTRL_CTRL);
+
+ return 0;
+}
+
+/**
+ * pru_init() - Initialize the remote processor
+ * @dev: rproc device pointer
+ *
+ * Return: 0 if all went ok, else return appropriate error
+ */
+static int pru_init(struct udevice *dev)
+{
+ return 0;
+}
+
+/*
+ * Convert PRU device address (data spaces only) to kernel virtual address
+ *
+ * Each PRU has access to all data
[PATCH v2 00/10] net: ti: icssg: Add prueth support
The series adds support for icssg_prueth functionality on u-boot. This series is based on top of master branch. rproc init needs to be done from uboot command prompt. The pru/rtu firmware loading is done by prueth driver soon after config paramters are setup. Currently only slice0/1 of icssg2 instance on am6-evm is supported. i.e Both slices of icssg2 instance are supported. Prebuilt firmware can be obtained from AM65 procSDK [1] rootfs at /lib/firmware/ti-pruss/am65x*.elf [1] http://software-dl.ti.com/processor-sdk-linux/esd/AM65X/latest/index_FDS.html This tests tftp on prueth. Note: Uboot ethernet driver architecture supports once instance per probe. So only one of the ports are supported per instance. So DT of prueth node should have either ethernet-mii0 or ethernet-mii1. Changes in v2: It has been a while since v1 was posted. Here are the changes: * Removed the usage of misc_init_by_ofnode instead used uclass_get_device_by_ofnode. * Introduced started variable to keep track of the status of the prueth device. * Build Tested on Travis: https://travis-ci.org/Keerthyj/u-boot/builds/651449684 Keerthy (10): net: eth-uclass: eth_get_dev based on SEQ_ALIAS instead of probe order soc: ti: pruss: add a misc driver for PRUSS in TI SoCs remoteproc: pruss: add PRU remoteproc driver net: ti: icssg-prueth: Add ICSSG ethernet driver arm: dts: k3-am65-main: Add msmc_ram node arm: dts: k3-am654-base-board-u-boot: Add icssg specific msmc_ram carveout nodes arm: dts: k3-am65-main: Add scm_conf node arm: dts: k3-am65-main: Add pruss nodes for ICSSG2 arm64: dts: ti: am654-base-board: add ICSSG2 Ethernet support configs: am65x_evm_a53_defconfig: Enable CONFIG_TI_AM64_ICSSG_PRUETH arch/arm/dts/k3-am65-main.dtsi | 191 ++ arch/arm/dts/k3-am65.dtsi| 4 +- arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 129 configs/am65x_evm_a53_defconfig | 3 + drivers/net/ti/Kconfig | 8 + drivers/net/ti/Makefile | 1 + drivers/net/ti/icssg-prueth.c| 652 +++ drivers/net/ti/icssg.h | 36 + drivers/net/ti/icssg_classifier.c| 396 +++ drivers/remoteproc/Kconfig | 11 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/pru_rproc.c | 405 drivers/soc/ti/Kconfig | 12 + drivers/soc/ti/Makefile | 1 + drivers/soc/ti/pruss.c | 152 + include/ti-pruss.h | 17 + net/eth-uclass.c | 12 +- 17 files changed, 2027 insertions(+), 4 deletions(-) create mode 100644 drivers/net/ti/icssg-prueth.c create mode 100644 drivers/net/ti/icssg.h create mode 100644 drivers/net/ti/icssg_classifier.c create mode 100644 drivers/remoteproc/pru_rproc.c create mode 100644 drivers/soc/ti/pruss.c create mode 100644 include/ti-pruss.h -- 2.17.1
[PATCH v2 02/10] soc: ti: pruss: add a misc driver for PRUSS in TI SoCs
The Programmable Real-Time Unit - Industrial Communication
Subsystem (PRU-ICSS) is present of various TI SoCs such as
AM335x or AM437x or the AM654x family. Each SoC can have
one or more PRUSS instances that may or may not be identical.
The PRUSS consists of dual 32-bit RISC cores called the
Programmable Real-Time Units (PRUs), some shared, data and
instruction memories, some internal peripheral modules, and
an interrupt controller. The programmable nature of the PRUs
provide flexibility to implement custom peripheral interfaces,
fast real-time responses, or specialized data handling.
Add support for pruss driver. Currently am654x family
is supported.
Signed-off-by: Keerthy
---
Changes in v2:
* Fixed multiple comments from Andreas w.r.t header file define guards
and Kconfig help typos.
drivers/soc/ti/Kconfig | 12
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/pruss.c | 152
include/ti-pruss.h | 17 +
4 files changed, 182 insertions(+)
create mode 100644 drivers/soc/ti/pruss.c
create mode 100644 include/ti-pruss.h
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index e4f8834448..19bce14c05 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -23,4 +23,16 @@ config TI_KEYSTONE_SERDES
SerDes driver for Keystone SoC used for ethernet support on TI
K2 platforms.
+config TI_PRUSS
+ bool "Support for TI's K3 based Pruss driver"
+ depends on DM
+ depends on ARCH_K3
+ depends on OF_CONTROL
+ depends on SYSCON
+ help
+ Support for TI PRU-ICSSG subsystem.
+
+ Currently supported on AM65xx SoCs. Say Y here to support the
+ Programmable Realtime Unit (PRU).
+
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index 4ec04ee125..34f80aad29 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_TI_K3_NAVSS_RINGACC) += k3-navss-ringacc.o
obj-$(CONFIG_TI_KEYSTONE_SERDES) += keystone_serdes.o
+obj-$(CONFIG_TI_PRUSS) += pruss.o
diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
new file mode 100644
index 00..059ae11805
--- /dev/null
+++ b/drivers/soc/ti/pruss.c
@@ -0,0 +1,152 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PRU-ICSS platform driver for various TI SoCs
+ *
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+ * Keerthy
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PRUSS_CFG_IEPCLK 0x30
+#define ICSSG_CFG_CORE_SYNC0x3c
+
+#define ICSSG_TASK_MGR_OFFSET 0x2a000
+
+/* PRUSS_IEPCLK register bits */
+#define PRUSS_IEPCLK_IEP_OCP_CLK_ENBIT(0)
+
+/* ICSSG CORE_SYNC register bits */
+#define ICSSG_CORE_VBUSP_SYNC_EN BIT(0)
+
+/**
+ * enum pruss_mem - PRUSS memory range identifiers
+ */
+enum pruss_mem {
+ PRUSS_MEM_DRAM0 = 0,
+ PRUSS_MEM_DRAM1,
+ PRUSS_MEM_SHRD_RAM2,
+ PRUSS_MEM_MAX,
+};
+
+/*
+ * pruss_request_tm_region() - Request pruss for task manager region
+ * @dev: corresponding k3 device
+ * @loc: the task manager physical address
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+int pruss_request_tm_region(struct udevice *dev, phys_addr_t *loc)
+{
+ struct pruss *priv;
+
+ priv = dev_get_priv(dev);
+ if (!priv || !priv->pruss_dram0)
+ return -EINVAL;
+
+ *loc = priv->pruss_dram0 + ICSSG_TASK_MGR_OFFSET;
+
+ return 0;
+}
+
+/*
+ * pruss_request_shrmem_region() - Request pruss for shared memory region
+ * @dev: corresponding k3 device
+ * @loc: the shared memory physical address
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+int pruss_request_shrmem_region(struct udevice *dev, phys_addr_t *loc)
+{
+ struct pruss *priv;
+
+ priv = dev_get_priv(dev);
+ if (!priv || !priv->pruss_shrdram2)
+ return -EINVAL;
+
+ *loc = priv->pruss_shrdram2;
+
+ return 0;
+}
+
+/**
+ * pruss_probe() - Basic probe
+ * @dev: corresponding k3 device
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+static int pruss_probe(struct udevice *dev)
+{
+ struct pruss *priv;
+ int ret, idx;
+ ofnode sub_node, node, memories;
+ struct regmap *regmap_cfg;
+ struct udevice *syscon;
+
+ priv = dev_get_priv(dev);
+ node = dev_ofnode(dev);
+ sub_node = ofnode_find_subnode(node, "cfg");
+ memories = ofnode_find_subnode(node, "memories");
+
+ idx = ofnode_stringlist_search(memories, "reg-names", "dram0");
+ priv->pruss_dram0 = ofnode_get_addr_size_index(memories, idx,
+ (u64
*)>pruss_dram0sz);
+ idx = ofnode_stringlist_search(memories, "reg-names", "dram1");
+
Re: [PATCH] am335x: evm: defconfig: disable spl tiny printf
On 17/02/20 9:16 am, Lokesh Vutla wrote: > > > On 13/02/20 7:04 PM, moseschristoph...@gmail.com wrote: >> From: Moses Christopher Bollavarapu >> >> - As tiny printf lib is further optimized, the ability to deal with >> ethaddr is lost. Hence, in order to handle usb-eth boot from SPL >> we need to disable tiny printf. >> >> - Tested on Beagle Bone Black >> >> Signed-off-by: Moses Christopher Bollavarapu > > This significantly increases the code size. Did you check how much is > increased? > SPL_TINY PRINTF is enabled on am335x_evm_defconfig to reduce the code size. > Wondering what allowed to be built even after disabling tiny printf. > I agree with Lokesh. Fix should be to revert the change that broke tiny printf as its breaks an already supported feature. Disabling SPL_TINY_PRINTF bloats AM335x SPL image size which is already at limit. Regards Vignesh
Re: [PATCH v5] Add support for SoM "VoCore2".
Hi Mauro, On Mon, Feb 17, 2020 at 2:22 PM Mauro Condarelli wrote: > > Hi Daniel, > a gentle reminder... > > I was unable to comply with a few of Your remarks (see below), > What should I do? > Submit v6 as is or do You have specific instructions? > > Thanks a lot > Mauro > sorry for the late response. Please only remove configs/vocore2_defconfig_ENV_IN_FAT and CONFIG_BAUDRATE and ignore my other comments. -- - Daniel
[PATCH] kbuild: fixdep: Resync this with v4.17
The previous kbuild resync of e91610da7c8a ("kconfig: re-sync with Linux
4.17-rc4") accidentally did not sync the fixdep program. This commit
brings fixdep in line with the rest of that previous resync.
This includes all of the following Linux kernel commits:
fbfa9be9904e kbuild: move include/config/ksym/* to include/ksym/*
5b8ad96d1a44 fixdep: remove some false CONFIG_ matches
14a596a7e6fd fixdep: remove stale references to uml-config.h
ab9ce9feed36 fixdep: use existing helper to check modular CONFIG options
87b95a81357d fixdep: refactor parse_dep_file()
5d1ef76f5a22 fixdep: move global variables to local variables of main()
ccfe78873c22 fixdep: remove unneeded memcpy() in parse_dep_file()
4003fd80cba9 fixdep: factor out common code for reading files
01b5cbe7012f fixdep: use malloc() and read() to load dep_file to buffer
41f92cffba19 fixdep: remove unnecessary inclusion
7c2ec43a2154 fixdep: exit with error code in error branches of do_config_file()
4e433fc4d1a9 fixdep: trivial: typo fix and correction
dee81e988674 fixdep: faster CONFIG_ search
c1a95fda2a40 kbuild: add fine grained build dependencies for exported symbols
d8329e35cc08 fixdep: accept extra dependencies on stdin
4c835b57b8de fixdep: constify strrcmp arguments
Of note is that when applying dee81e988674 above our logic in that area
required some careful consideration to continue to apply.
We specifically do not include:
638e69cf2230 fixdep: do not ignore kconfig.h
as this leads to build problems for us resulting in problems like:
dts/.dt.dtb.o.cmd:5: *** unterminated call to function 'wildcard': missing ')'.
Stop.
Cc: Masahiro Yamada '
Signed-off-by: Tom Rini
---
scripts/basic/fixdep.c | 352 ++---
1 file changed, 151 insertions(+), 201 deletions(-)
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index da7fb2cd4dde..8c21dd08d9f7 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -25,7 +25,7 @@
*
* So we play the same trick that "mkdep" played before. We replace
* the dependency on autoconf.h by a dependency on every config
- * option which is mentioned in any of the listed prequisites.
+ * option which is mentioned in any of the listed prerequisites.
*
* kconfig populates a tree in include/config/ with an empty file
* for each config symbol and when the configuration is updated
@@ -34,7 +34,7 @@
* the config symbols are rebuilt.
*
* So if the user changes his CONFIG_HIS_DRIVER option, only the objects
- * which depend on "include/linux/config/his/driver.h" will be rebuilt,
+ * which depend on "include/config/his/driver.h" will be rebuilt,
* so most likely only his driver ;-)
*
* The idea above dates, by the way, back to Michael E Chastain, AFAIK.
@@ -75,15 +75,14 @@
* and then basically copies the ..d file to stdout, in the
* process filtering out the dependency on autoconf.h and adding
* dependencies on include/config/my/option.h for every
- * CONFIG_MY_OPTION encountered in any of the prequisites.
+ * CONFIG_MY_OPTION encountered in any of the prerequisites.
*
* It will also filter out all the dependencies on *.ver. We need
* to make sure that the generated version checksum are globally up
* to date before even starting the recursive build, so it's too late
* at this point anyway.
*
- * The algorithm to grep for "CONFIG_..." is bit unusual, but should
- * be fast ;-) We don't even try to really parse the header files, but
+ * We don't even try to really parse the header files, but
* merely grep, i.e. if CONFIG_FOO is mentioned in a comment, it will
* be picked up as well. It's not a problem with respect to
* correctness, since that can only give too many dependencies, thus
@@ -94,49 +93,57 @@
* (Note: it'd be easy to port over the complete mkdep state machine,
* but I don't think the added complexity is worth it)
*/
-/*
- * Note 2: if somebody writes HELLO_CONFIG_BOOM in a file, it will depend onto
- * CONFIG_BOOM. This could seem a bug (not too hard to fix), but please do not
- * fix it! Some UserModeLinux files (look at arch/um/) call CONFIG_BOOM as
- * UML_CONFIG_BOOM, to avoid conflicts with /usr/include/linux/autoconf.h,
- * through arch/um/include/uml-config.h; this fixdep "bug" makes sure that
- * those files will have correct dependencies.
- */
#include
#include
-#include
#include
#include
#include
#include
#include
-#include
#include
-#include
-
-#define INT_CONF ntohl(0x434f4e46)
-#define INT_ONFI ntohl(0x4f4e4649)
-#define INT_NFIG ntohl(0x4e464947)
-#define INT_FIG_ ntohl(0x4649475f)
-char *target;
-char *depfile;
-char *cmdline;
int is_spl_build = 0; /* hack for U-Boot */
static void usage(void)
{
- fprintf(stderr, "Usage: fixdep \n");
+ fprintf(stderr, "Usage: fixdep [-e] \n");
+ fprintf(stderr, " -e insert extra dependencies given on stdin\n");
exit(1);
}
/*
- * Print out the commandline prefixed with cmd_ :=
+ * Print out a dependency
[RFC] fixdep: faster CONFIG_search
This is a port of dee81e988674 from Linux ("fixdep: faster CONFIG_
search") and posted by itself for ease of review.
To quote the kernel changelog:
"Do you think kernel build is 100% dominated by gcc? You are wrong!
One small utility called "fixdep" consistently manages to sneak into
profile's first page (unless you have small monitor of course).
The choke point is this clever code:
for (; m < end; m++) {
if (*m == INT_CONF) { p = (char *) m ; goto conf; }
if (*m == INT_ONFI) { p = (char *) m-1; goto conf; }
if (*m == INT_NFIG) { p = (char *) m-2; goto conf; }
if (*m == INT_FIG_) { p = (char *) m-3; goto conf; }
4 branches per 4 characters is not fast.
Use strstr(3), so that SSE2 etc can be used.
With this patch, fixdep is so deep at the bottom, it is hard to find
it."
Cc: Masahiro Yamada
Signed-off-by: Tom Rini
---
As part of working to re-sync our kbuild logic I see that fixdep.c
wasn't updated as part of the general resync with v4.17. As this
specific change required some thinking to adapt our logic that was added
in 8be60f06c258 I am posting this change stand-alone for review.
---
scripts/basic/fixdep.c | 100 ++---
1 file changed, 33 insertions(+), 67 deletions(-)
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index da7fb2cd4dde..6ab1780e4c02 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -82,8 +82,7 @@
* to date before even starting the recursive build, so it's too late
* at this point anyway.
*
- * The algorithm to grep for "CONFIG_..." is bit unusual, but should
- * be fast ;-) We don't even try to really parse the header files, but
+ * We don't even try to really parse the header files, but
* merely grep, i.e. if CONFIG_FOO is mentioned in a comment, it will
* be picked up as well. It's not a problem with respect to
* correctness, since that can only give too many dependencies, thus
@@ -115,11 +114,6 @@
#include
#include
-#define INT_CONF ntohl(0x434f4e46)
-#define INT_ONFI ntohl(0x4f4e4649)
-#define INT_NFIG ntohl(0x4e464947)
-#define INT_FIG_ ntohl(0x4649475f)
-
char *target;
char *depfile;
char *cmdline;
@@ -217,38 +211,20 @@ static void use_config(const char *m, int slen)
printf(".h) \\\n");
}
-static void parse_config_file(const char *map, size_t len)
+static void parse_config_file(const char *p)
{
- const int *end = (const int *) (map + len);
- /* start at +1, so that p can never be < map */
- const int *m = (const int *) map + 1;
- const char *p, *q;
+ const char *q, *r;
char tmp_buf[256] = "SPL_"; /* hack for U-Boot */
- for (; m < end; m++) {
- if (*m == INT_CONF) { p = (char *) m ; goto conf; }
- if (*m == INT_ONFI) { p = (char *) m-1; goto conf; }
- if (*m == INT_NFIG) { p = (char *) m-2; goto conf; }
- if (*m == INT_FIG_) { p = (char *) m-3; goto conf; }
- continue;
- conf:
- if (p > map + len - 7)
- continue;
- if (memcmp(p, "CONFIG_", 7))
- continue;
+ while ((p = strstr(p, "CONFIG_"))) {
p += 7;
- for (q = p; q < map + len; q++) {
- if (!(isalnum(*q) || *q == '_'))
- goto found;
- }
- continue;
-
- found:
- if (!memcmp(q - 7, "_MODULE", 7))
- q -= 7;
- if (q - p < 0)
- continue;
-
+ q = p;
+ while (*q && (isalnum(*q) || *q == '_'))
+ q++;
+ if (memcmp(q - 7, "_MODULE", 7) == 0)
+ r = q - 7;
+ else
+ r = q;
/*
* U-Boot also handles
* CONFIG_IS_ENABLED(...)
@@ -261,21 +237,20 @@ static void parse_config_file(const char *map, size_t len)
(q - p == 9 && !memcmp(p, "IS_MODULE(", 10)) ||
(q - p == 3 && !memcmp(p, "VAL(", 4))) {
p = q + 1;
- for (q = p; q < map + len; q++)
- if (*q == ')')
- goto found2;
- continue;
-
- found2:
- if (is_spl_build) {
- memcpy(tmp_buf + 4, p, q - p);
- q = tmp_buf + 4 + (q - p);
+ while (*q && *q != ')')
+ q++;
+ r = q;
+ if (r > p && is_spl_build) {
+ memcpy(tmp_buf + 4, p, r - p);
+ r = tmp_buf + 4 + (r - p);
p = tmp_buf;
}
}
Re: [PATCH v5] Add support for SoM "VoCore2".
On Mon, 2020-02-17 at 14:22 +0100, Mauro Condarelli wrote: > Hi Daniel, > a gentle reminder... > > I was unable to comply with a few of Your remarks (see below), > What should I do? > Submit v6 as is or do You have specific instructions? > > Thanks a lot > Mauro > > On 2/12/20 11:01 PM, Mauro Condarelli wrote: > > Thanks Daniel, > > > > On 2/12/20 5:58 PM, Daniel Schwierzeck wrote: > >> On Wed, Feb 12, 2020 at 4:30 PM Mauro Condarelli wrote: > >>> Small patch series to add support for VoCore/VoCore2 board. > >>> > >>> VoCore is open hardware and runs OpenWrt/LEDE. > >>> It has WIFI, USB, UART, 20+ GPIOs but is only one inch square. > >>> It will help you to make a smart house, study embedded system > >>> or even make the tiniest router in the world. > >>> > >>> ===8<--- > >>> diff --git a/board/vocore/vocore2/board.c b/board/vocore/vocore2/board.c > >>> new file mode 100644 > >>> index 00..27e42d1414 > >>> --- /dev/null > >>> +++ b/board/vocore/vocore2/board.c > >>> @@ -0,0 +1,6 @@ > >>> +// SPDX-License-Identifier: GPL-2.0+ > >>> +/* > >>> + * Copyright (C) 2019 Mauro Condarelli > >>> + * > >>> + * Nothing actually needed here > >>> + */ > >> if that file is empty, don't add it at all > > Ahem... > > > > I tried to remove it, but if I do I also have to remove entry > > in board/vocore/vocore2/Makefile (leaving it empty) and this > > leads (on a clean compile) to error: > > mipsel-linux-ld.bfd: cannot find board/vocore/vocore2/built-in.o: No > > such file or directory > > Completely removing both files bombs with: > > scripts/Makefile.build:57: board/vocore/vocore2/Makefile: No such file > > or directory > > It seems I should also remove board/vocore/vocore2/Kconfig, > > but I'm unsure this is the right thing to do. > > > > I have no idea about how to solve this, sorry. > > Can You point me in the right direction, please? > > > > > >>> ===8<--- > >>> diff --git a/include/configs/vocore2.h b/include/configs/vocore2.h > >>> new file mode 100644 > >>> index 00..6b43aa766e > >>> --- /dev/null > >>> +++ b/include/configs/vocore2.h > >>> @@ -0,0 +1,61 @@ > >>> +/* SPDX-License-Identifier: GPL-2.0+ */ > >>> +/* > >>> + * Copyright (C) 2019 Mauro Condarelli > >>> + */ > >>> + > >>> +#ifndef __VOCORE2_CONFIG_H__ > >>> +#define __VOCORE2_CONFIG_H__ > >>> + > >>> +/* CPU */ > >>> +#define CONFIG_SYS_MIPS_TIMER_FREQ 29000 > >> is this still necessary? Weijie implemented a custom CPU clock > >> handling which supports > >> dynamic timer clocks. > > This is referenced in arch/mips/cpu/time.c > > I don't know if it's still relevant, but removing it doesn't seem > > task for this patch. You have to keep this to make sure arch/mips/cpu/time.c can be compiled. > > > > > >>> + > >>> +/* RAM */ > >>> +#define CONFIG_SYS_SDRAM_BASE 0x8000 > >>> + > >>> +#define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE + 0x10 > >>> + > >>> +#define CONFIG_SYS_INIT_SP_OFFSET 0x40 > >>> + > >>> +/* SPL */ > >>> +#if defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD) > >>> +#define CONFIG_SKIP_LOWLEVEL_INIT > >>> +#endif > >> CONFIG_SPL_BUILD is only relevant in Makefiles and shouldn't be used > >> in config header files > > Removed, apparently without adverse consequences. > Appearence was misguiding. > Any change to this guard leads to code unable to boot from SPI NOR. > I'll have to leave it is as-is. > Someone more knowledgeable than me will have to understand why > they are needed and how to remove them, if that's a requirement. > After all the other boards with this SoC use the same code. CONFIG_SPL_BUILD is defined only when building the SPL binary. CONFIG_SPL is defined for both SPL and u-boot if SPL is enabled, and we can only use CONFIG_SPL_BUILD to distinguish whether we are building SPL or not. CONFIG_SKIP_LOWLEVEL_INIT apparently means do not do lowlevel_init. However lowlevel_init must be done once and only once for a SPI NOR bootable version. The following table describes whether lowlevel_init is needed: | SPL | u-boot -- SPL enabled | Y | N -- SPL disabled | | Y As you can see we only want to define CONFIG_SKIP_LOWLEVEL_INIT for just one case: SPL enabled and not building SPL, because lowlevel_init is done in SPL and u-boot is a ram boot binary. As a result this table produces the condition I used for other boards: #if defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD) If we use only "defined(CONFIG_SPL)", CONFIG_SKIP_LOWLEVEL_INIT will be defined for both parts, and this will finally lead to code unable to boot from SPI NOR. > > > >>> + > >>> +#define CONFIG_SYS_UBOOT_START CONFIG_SYS_TEXT_BASE > >>> +#define CONFIG_SPL_BSS_START_ADDR 0x8001 > >>> +#define CONFIG_SPL_BSS_MAX_SIZE0x1 > >>> +#define CONFIG_SPL_MAX_SIZE0x1 > >>> + > >>> +/* Dummy value */ > >>> +#define CONFIG_SYS_UBOOT_BASE 0 > >> where is that
Re: [PATCH v3 0/3] Ethernet support for Raspberry Pi 4
Hi LABBE, On 2/17/20 8:37 PM, Jaehoon Chung wrote: > On 2/3/20 6:48 PM, LABBE Corentin wrote: >> On Wed, Jan 29, 2020 at 07:21:09AM +0900, Jaehoon Chung wrote: >>> On 1/27/20 9:06 PM, Andre Przywara wrote: On Mon, 27 Jan 2020 12:50:16 +0100 LABBE Corentin wrote: Hi, > On Mon, Jan 27, 2020 at 04:27:03PM +0530, Amit Tomer wrote: >> Hi, >> >>> The kernel panic just after with "OF: reserved mem: failed to allocate >>> memory for node 'linux,cma'" but that's another story. >> >> But this comes even without having Ethernet patches and when one use >> booti instead of bootefi, right ? >> > > So booti is unsupported on rpi 4 ? It should be supported, but apparently there is some bug. I guess it's about not properly reserving memory used by the armstub/ATF. Do you use the embedded RPi foundation armstub or ATF (do you have an "armstub=..." line in config.txt)? I will try take a look at this later. >>> >>> I'm not sure, i had similar issue about failed to allocate memory cma. >>> I had enabled CONFIG_ARCH_FIXUP_OF_MEMORY. And i changed the loading >>> address (kernel/ramdisk/device-tree) in boot script for our environment. >>> Because sometime some address range is overwritten. >>> >> >> Hello >> >> I have searched both in uboot and linux sources and didnt found any >> CONFIG_ARCH_FIXUP_OF_MEMORY. > > Sorry. It's CONFIG_ARCH_FIXUP_FDT_MEMORY. In my case, disable CONFIG_ARCH_FIXUP_FDT_MEMORY. (RAM size is returned to 0.) [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.19.81-arm-rpi4-v7l (abuild@obspw03) (gcc version 9.2.0 (Tizen GCC 9.2.0 20190812 3.5)) #1 SMP Thu Feb 13 12:18:13 UTC 2020 [0.00] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] OF: fdt: Machine model: Raspberry Pi 4 Model B [0.00] earlycon: uart8250 at MMIO32 0xfe215040 (options '') [0.00] bootconsole [uart8250] enabled [0.00] INITRD: 0x0270+0x0080 is not a memory region - disabling initrd [0.00] cma: Size (0x1000) of region at 0x exceeds limit (0x) [0.00] cma: Failed to reserve 256 MiB After enabled CONFIG_ARCH_FIXUP_FDT_MEMORY. tarting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.19.81-arm-rpi4-v7l (abuild@obspw03) (gcc version 9.2.0 (Tizen GCC 9.2.0 20190812 3.5)) #1 SMP Thu Feb 13 12:18:13 UTC 2020 [0.00] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] OF: fdt: Machine model: Raspberry Pi 4 Model B [0.00] earlycon: uart8250 at MMIO32 0xfe215040 (options '') [0.00] bootconsole [uart8250] enabled [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 256 MiB at 0x1ec0 [0.00] random: get_random_bytes called from start_kernel+0xc0/0x4f0 with crng_init=0 [0.00] percpu: Embedded 16 pages/cpu s36812 r8192 d20532 u65536 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 1011008 Kernel is based on RPI vendor kernel. (32bit) And I have changed ramdisk/kernel/fdt loading address.(I think that it's not important.) I have checked 1G/2G/4G RPI4 target. Each board is displayed correct ram-size on Kernel side. Best Regards, Jaehoon Chung > > Best Regards, > Jaehoon Chung > >> Could you give what you did exactly ? >> >> Regards >> >> > > >
[PATCH v2 1/3] mmc: sdhci: use phys2bus macro when dma address is accessed
Use phys2bus macro when dma address is accessed.
Some targets need to use pyhs2bus macro. (e.g, RPI4)
After applied it, SDMA mode can be used.
Signed-off-by: Jaehoon Chung
Reviewed-by: Peng Fan
---
Changelog on V2
- None
drivers/mmc/sdhci.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 01fa5a9d4d..93c9049c5d 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#if defined(CONFIG_FIXED_SDHCI_ALIGNED_BUFFER)
void *aligned_buffer = (void *)CONFIG_FIXED_SDHCI_ALIGNED_BUFFER;
@@ -164,7 +165,8 @@ static void sdhci_prepare_dma(struct sdhci_host *host,
struct mmc_data *data,
if (data->flags != MMC_DATA_READ)
memcpy(aligned_buffer, data->src, trans_bytes);
#endif
- sdhci_writel(host, host->start_addr, SDHCI_DMA_ADDRESS);
+ sdhci_writel(host, phys_to_bus((ulong)host->start_addr),
+ SDHCI_DMA_ADDRESS);
} else if (host->flags & (USE_ADMA | USE_ADMA64)) {
sdhci_prepare_adma_table(host, data);
@@ -220,7 +222,7 @@ static int sdhci_transfer_data(struct sdhci_host *host,
struct mmc_data *data)
start_addr &=
~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1);
start_addr += SDHCI_DEFAULT_BOUNDARY_SIZE;
- sdhci_writel(host, start_addr,
+ sdhci_writel(host,
phys_to_bus((ulong)start_addr),
SDHCI_DMA_ADDRESS);
}
}
--
2.25.0
[PATCH v2 3/3] configs: rpi_4_32b_defconfig: enable SDHCI_SDMA config
Enable SDHCI_SDMA configuration. Signed-off-by: Jaehoon Chung Reviewed-by: Peng Fan --- Changelog on V2 - None configs/rpi_4_32b_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index 72cda5d949..7189914606 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -25,6 +25,7 @@ CONFIG_DFU_MMC=y CONFIG_DM_KEYBOARD=y CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_BCM2835=y CONFIG_DM_ETH=y CONFIG_BCMGENET=y -- 2.25.0
[PATCH v2 2/3] mmc: sdhci: not return error when SDMA is not supported
If Host controller doesn't support SDMA, it doesn't need to return
error. Because it can be worked with PIO mode.
Signed-off-by: Jaehoon Chung
Reviewed-by: Peng Fan
---
Changelog on V2
- Keep printf message instead of debug
drivers/mmc/sdhci.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 93c9049c5d..40bf2a5b2c 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -729,13 +729,12 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
sdhci_host *host,
debug("%s, caps: 0x%x\n", __func__, caps);
#ifdef CONFIG_MMC_SDHCI_SDMA
- if (!(caps & SDHCI_CAN_DO_SDMA)) {
+ if ((caps & SDHCI_CAN_DO_SDMA)) {
+ host->flags |= USE_SDMA;
+ } else {
printf("%s: Your controller doesn't support SDMA!!\n",
__func__);
- return -EINVAL;
}
-
- host->flags |= USE_SDMA;
#endif
#if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
if (!(caps & SDHCI_CAN_DO_ADMA2)) {
--
2.25.0
[PATCH v2 0/3] Support SDMA mode on RPI4 target - 32bit
RPI4's SDHCI controller is supported SDMA mode. (Checked on kernel side) But It doesn't use on u-boot side. Then it's too slow about read/write performance. This patchset is supported SDMA mode on RPI4 target(32bit). - I didn't test on RPI4 64bit. Read/write time about 8MB file Before - Read : 1.472 seconds - Write : 4.690 seconds After - Read : 0.359 seconds - Write : 0.574 seconds This patch is based on my RFC's patches.RPI4's SDHCI controller is supported SDMA mode. (Checked on kernel side) But It doesn't use on u-boot side. Then it's too slow about read/write performance. This patchset is supported SDMA mode on RPI4 target(32bit). - I didn't test on RPI4 64bit. Read/write time about 8MB file Before - Read : 1.472 seconds - Write : 4.690 seconds After - Read : 0.359 seconds - Write : 0.574 seconds This patch is based on my RFC's patches. Changelog on V2 - Keep printf message instead of debug - Add Peng's Reviewed-by tag Jaehoon Chung (3): mmc: sdhci: use phys2bus macro when dma address is accessed mmc: sdhci: not return error when SDMA is not supported configs: rpi_4_32b_defconfig: enable SDHCI_SDMA config configs/rpi_4_32b_defconfig | 1 + drivers/mmc/sdhci.c | 13 +++-- 2 files changed, 8 insertions(+), 6 deletions(-) -- 2.25.0
RE: imx8m: composite clock wrong clock parent ?
> Subject: imx8m: composite clock wrong clock parent ? > > Hi, > > I am working on a i.MX8MM based board and I got issue to make the > Ethernet phy work. > I noticed that the MDIO clock is not configured properly and the FEC outputs a > 26,6MHz MDIO clock. > That's because the clk_get_rate() call at line 1389 returns 24MHz whereas it > should returns 266MHz as it is set in the device tree and configured in the > SoC: > > BIOS> md.l 0x3030 1 > 3030: 1100 > > With some debug traces we can see that the enet_axi's parent is wrong: > > fecmxc_probe 1388 > clk_get_rate 447: clk clock-controller@3038 clk_get_rate 447: clk > enet1_root_clk clk_get_rate 447: clk enet_axi clk_get_parent_rate 489: clk > enet_axi parent clock-osc-24m clk_get_parent_rate 489: clk enet1_root_clk > parent enet_axi fecmxc_probe 1390 > > Is this a known issue ? There is an issue in current clk framework in U-Boot, it could not runtime set the parent of a clk, and I have not find time to work on this. I not check whether your issue is related the upper issue in CCF. Regards, Peng. > > Regards, > > -- > Sébastien Szymanski, Armadeus Systems > Software engineer
RE: [PATCH] ARM: socfpga: Add initial support for the ABB SECU board
> -Original Message-
> From: Marek Vasut
> Sent: Tuesday, February 18, 2020 1:33 AM
> To: u-boot@lists.denx.de
> Cc: Holger Brunck ; Tan, Ley Foon
> ; Simon Goldschmidt
>
> Subject: [PATCH] ARM: socfpga: Add initial support for the ABB SECU board
>
> From: Holger Brunck
>
> Add initial support for the ABB SECU board, which is an ArriaV-based
> SoCFPGA system with ethernet and booting from Denali NAND.
>
> Signed-off-by: Holger Brunck
> Cc: Ley Foon Tan
> Cc: Simon Goldschmidt
> ---
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/socfpga_arria5_secu1.dts | 130 +
> arch/arm/mach-socfpga/Kconfig | 10 +
> board/keymile/Kconfig | 11 +-
> board/keymile/common/ivm.c | 18 +-
> board/keymile/secu1/Makefile| 7 +
> board/keymile/secu1/qts/iocsr_config.h | 694
> board/keymile/secu1/qts/pinmux_config.h |
> 218
> board/keymile/secu1/qts/pll_config.h| 83 +++
> board/keymile/secu1/qts/sdram_config.h | 327 +++
> board/keymile/secu1/socfpga.c | 67 +++
> configs/socfpga_secu1_defconfig | 83 +++
> include/configs/socfpga_arria5_secu1.h | 131 +
> 13 files changed, 1776 insertions(+), 4 deletions(-) create mode 100644
> arch/arm/dts/socfpga_arria5_secu1.dts
> create mode 100644 board/keymile/secu1/Makefile create mode 100644
> board/keymile/secu1/qts/iocsr_config.h
> create mode 100644 board/keymile/secu1/qts/pinmux_config.h
> create mode 100644 board/keymile/secu1/qts/pll_config.h
> create mode 100644 board/keymile/secu1/qts/sdram_config.h
> create mode 100644 board/keymile/secu1/socfpga.c create mode 100644
> configs/socfpga_secu1_defconfig create mode 100644
> include/configs/socfpga_arria5_secu1.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> be4cf029d0..9c593b2c98 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -333,6 +333,7 @@ dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
>
> dtb-$(CONFIG_ARCH_SOCFPGA) +=\
> socfpga_agilex_socdk.dtb\
> + socfpga_arria5_secu1.dtb\
> socfpga_arria5_socdk.dtb\
> socfpga_arria10_socdk_sdmmc.dtb \
> socfpga_cyclone5_mcvevk.dtb \
> diff --git a/arch/arm/dts/socfpga_arria5_secu1.dts
> b/arch/arm/dts/socfpga_arria5_secu1.dts
> new file mode 100644
> index 00..dadf766682
> --- /dev/null
> +++ b/arch/arm/dts/socfpga_arria5_secu1.dts
> @@ -0,0 +1,130 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2016-2020 ABB
> + */
> +
> +#include "socfpga_arria5.dtsi"
> +#include "socfpga-common-u-boot.dtsi"
> +#include
> +
> +/ {
> + model = "ABB SoC SECU1 Board";
> + compatible = "altr,socfpga-secu1", "altr,socfpga";
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + bootargs = "console=ttyS0,115200";
> + };
> +
> + memory {
> + name = "memory";
> + device_type = "memory";
> + reg = <0x0 0x2000>; /* 512MB */
> + };
> +
> + aliases {
> + /*
> + * this allow the ethaddr uboot environment variable
> contents
> + * to be added to the gmac0 device tree blob.
> + */
> + ethernet0 =
> + spi0 =
> + };
> +
> + i2c_gpio: i2c@0 {
> + compatible = "i2c-gpio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + gpios = < 5 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)
> /* SDA */
> + 6
> (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; /* SCL */
> + i2c-gpio,delay-us = <5>;/* ~100 kHz */
> + i2c-gpio,deblock;
> +
> + temp_sensor@48 {
> + compatible = "national,lm75";
> + reg = <0x48>;
> + };
> +
> + eeprom@50 {
> + compatible = "at,24c08";
> + reg = <0x50>;
> + };
> +
> + rtc: rtc@68 {
> + compatible = "st,m41st87";
> + reg = <0x68>;
> + interrupt-parent = <>;
> + interrupts = <0 42 0x4>;
> + };
> + };
> +
> + regulator_3_3v: 3-3-v-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "3.3V";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +};
> +
> + {
> + status = "okay";
> + phy-mode = "rgmii";
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + vmmc-supply = <_3_3v>;
> +
Re: [PATCH v1] Revert "x86: use invd instead of wbinvd in real mode start code"
Hi Andy, On Tue, Feb 18, 2020 at 12:30 AM Andy Shevchenko wrote: > > This reverts commit 0d67fac29f3187e67f4fd3ef15f73e91be2fad12. > > As real hardware testing (*) shows the above mentioned commit > breaks U-Boot on it. Revert for the upcoming release. We may get > more information in the future and optimize the code accordingly. > > (*) om Intel Edison board. > > Signed-off-by: Andy Shevchenko > --- > arch/x86/cpu/start.S | 2 +- > arch/x86/cpu/start16.S | 2 +- Reverting arch/x86/cpu/start.S is enough, isn't it? arch/x86/cpu/start16.S is not compiled for the Edison board. start16.S is the start of the Real Mode, and we are sure no program was running before U-Boot. > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S > index 26cf995db2..01524635e9 100644 > --- a/arch/x86/cpu/start.S > +++ b/arch/x86/cpu/start.S > @@ -50,7 +50,7 @@ _x86boot_start: > movl%cr0, %eax > orl $(X86_CR0_NW | X86_CR0_CD), %eax > movl%eax, %cr0 > - invd > + wbinvd > > /* > * Zero the BIST (Built-In Self Test) value since we don't have it. > diff --git a/arch/x86/cpu/start16.S b/arch/x86/cpu/start16.S > index 292e750508..54f4ff6662 100644 > --- a/arch/x86/cpu/start16.S > +++ b/arch/x86/cpu/start16.S > @@ -28,7 +28,7 @@ start16: > movl%cr0, %eax > orl $(X86_CR0_NW | X86_CR0_CD), %eax > movl%eax, %cr0 > - invd > + wbinvd > > /* load the temporary Global Descriptor Table */ > data32 cs lidtidt_ptr > -- > 2.25.0 > -- Best Regards Masahiro Yamada
Re: imx8m: composite clock wrong clock parent ?
Hi Sébastien, On Mon, Feb 17, 2020 at 6:57 AM Sébastien Szymanski wrote: > > Hi, > > I am working on a i.MX8MM based board and I got issue to make the > Ethernet phy work. > I noticed that the MDIO clock is not configured properly and the FEC > outputs a 26,6MHz MDIO clock. > That's because the clk_get_rate() call at line 1389 returns 24MHz > whereas it should returns 266MHz as it is set in the device tree and > configured in the SoC: > > BIOS> md.l 0x3030 1 > 3030: 1100 > > With some debug traces we can see that the enet_axi's parent is wrong: > > fecmxc_probe 1388 > clk_get_rate 447: clk clock-controller@3038 > clk_get_rate 447: clk enet1_root_clk > clk_get_rate 447: clk enet_axi > clk_get_parent_rate 489: clk enet_axi parent clock-osc-24m > clk_get_parent_rate 489: clk enet1_root_clk parent enet_axi > fecmxc_probe 1390 > > Is this a known issue ? It seems someone needs to work on a drivers/clk/imx/clk-imx8mq.c driver. Regards, Fabio Estevam
RE: [PATCH V2 2/2] ARM: socfpga: Add missing Denali NAND config options
> -Original Message- > From: Marek Vasut > Sent: Tuesday, February 18, 2020 1:30 AM > To: u-boot@lists.denx.de > Cc: Marek Vasut ; Tan, Ley Foon > ; Simon Goldschmidt > > Subject: [PATCH V2 2/2] ARM: socfpga: Add missing Denali NAND config > options > > The Denali SPL shim won't build without these options set, set them > accordingly to fix the build error and let the SPL shim to work correctly. > > Signed-off-by: Marek Vasut > Cc: Ley Foon Tan > Cc: Simon Goldschmidt > --- > V2: No changes > --- > include/configs/socfpga_common.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/configs/socfpga_common.h > b/include/configs/socfpga_common.h > index 54a43569dc..29b0a5d69d 100644 > --- a/include/configs/socfpga_common.h > +++ b/include/configs/socfpga_common.h > @@ -121,6 +121,8 @@ > * NAND Support > */ > #ifdef CONFIG_NAND_DENALI > +#define CONFIG_SYS_NAND_USE_FLASH_BBT Didn't see Denali Nand driver use CONFIG_SYS_NAND_USE_FLASH_BBT. But, denali.c always set NAND_BBT_USE_FLASH flag. > +#define CONFIG_SYS_NAND_BAD_BLOCK_POS0 > #define CONFIG_SYS_MAX_NAND_DEVICE 1 > #define CONFIG_SYS_NAND_ONFI_DETECTION > #define CONFIG_SYS_NAND_REGS_BASE > SOCFPGA_NANDREGS_ADDRESS > -- Regards Ley Foon
Re: [PATCH v1] Revert "x86: use invd instead of wbinvd in real mode start code"
On Mon, Feb 17, 2020 at 11:30 PM Andy Shevchenko wrote: > > This reverts commit 0d67fac29f3187e67f4fd3ef15f73e91be2fad12. > > As real hardware testing (*) shows the above mentioned commit > breaks U-Boot on it. Revert for the upcoming release. We may get > more information in the future and optimize the code accordingly. > > (*) om Intel Edison board. on? > > Signed-off-by: Andy Shevchenko > --- > arch/x86/cpu/start.S | 2 +- > arch/x86/cpu/start16.S | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > Acked-by: Bin Meng
RE: [PATCH V2 1/2] ARM: socfpga: Permit overriding the default timer frequency
> -Original Message- > From: Marek Vasut > Sent: Tuesday, February 18, 2020 1:30 AM > To: u-boot@lists.denx.de > Cc: Marek Vasut ; Tan, Ley Foon > ; Simon Goldschmidt > > Subject: [PATCH V2 1/2] ARM: socfpga: Permit overriding the default timer > frequency > > The default timer rate may be different than 25 MHz, permit overriding the > default rate in board configuration file. Ultimatelly, this should be properly > handled by a clock driver, however that is not available on Gen5 yet. > > Signed-off-by: Marek Vasut > Cc: Ley Foon Tan > Cc: Simon Goldschmidt Reviewed-by: Ley Foon Tan > --- > V2: Drop misleading comment > --- > include/configs/socfpga_common.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/configs/socfpga_common.h > b/include/configs/socfpga_common.h > index 8d10469e7c..54a43569dc 100644 > --- a/include/configs/socfpga_common.h > +++ b/include/configs/socfpga_common.h > @@ -94,12 +94,13 @@ > * L4 OSC1 Timer 0 > */ > #ifndef CONFIG_TIMER > -/* This timer uses eosc1, whose clock frequency is fixed at any condition. */ > #define CONFIG_SYS_TIMERBASE > SOCFPGA_OSC1TIMER0_ADDRESS > #define CONFIG_SYS_TIMER_COUNTS_DOWN > #define CONFIG_SYS_TIMER_COUNTER (CONFIG_SYS_TIMERBASE + > 0x4) > +#ifndef CONFIG_SYS_TIMER_RATE > #define CONFIG_SYS_TIMER_RATE2500 > #endif > +#endif > > /* > * L4 Watchdog > -- > 2.24.1
Re: [PATCH v2 04/10] mmc: sdhci: Expose sdhci_init() as non-static
Hi Faiz,
On 2/18/20 7:35 AM, Jaehoon Chung wrote:
> Hi Faiz,
>
> On 2/17/20 9:42 PM, Faiz Abbas wrote:
>> Jaehoon,
>>
>> On 17/02/20 5:47 pm, Jaehoon Chung wrote:
>>> Hi,
>>>
>>> On 2/5/20 4:33 PM, Faiz Abbas wrote:
Hi Peng,
On 05/02/20 12:58 pm, Peng Fan wrote:
>> Subject: Re: [PATCH v2 04/10] mmc: sdhci: Expose sdhci_init() as
>> non-static
>>
>> Hi,
>>
>> On 31/01/20 3:55 am, Simon Goldschmidt wrote:
>>> Am 30.01.2020 um 23:21 schrieb Jaehoon Chung:
Hi Simon,
On 1/29/20 11:16 PM, Simon Goldschmidt wrote:
> On Wed, Jan 29, 2020 at 12:00 AM Jaehoon Chung
> wrote:
>>
>> On 1/24/20 8:52 PM, Faiz Abbas wrote:
>>> Expose sdhci_init() as non-static.
>>
>> Does it need to change to non-static?
>
> And even if it needs to, can we have a reason *why* in the commit
> message?
When i read entire your series, it seems that doesn't need to change
to non-static.
All of change that touched MMC code are only for your board.
I don't know Peng's opinion, but it's not my prefer.
>>>
>>> +1!
>>>
>>> We need to keep the core code clean of such hacks in order to keep the
>>> size small for constrained targets!
>>>
>>
>> Peng can you comment on this?
>
> Just one more question, does kernel has same issue, how resolved?
> Could U-Boot follow similar approach?
Kernel has interrupts enabled. So software just has to wait for the card
detect interrupt to arrive rather than poll on anything.
>
> Actually I am fine with platform specific approach , considering
> your platform issue.
>
> But since Simon and Jaehoon has concerns, not sure whether
> Simon and Jaehoon have good ideas.
>
Ok. Lets see if they have some better ideas.
>>>
>>> Well, Your code needs to call am654_sdhci_init() before sdhci_init(), right?
>>>
>>> ops->init() -> am654_sdhci_init -> sdhci_init().
>>> If am654_sdhci_init is called for preset, how about adding pre_init() or
>>> other ops callback.
>>> (pre_init is just example.)
>>>
>>> ops->pre_init = am654_sdhci_init; or ops->preset = am654_sdhci_preset;
>>>
>>> In mmc.
>>>
>>> ops->preset or ops->pre_init -> ops->init
>>>
>>> How about adding plotform specific init callback? Then someone can also use
>>> it for platform specific things in future.
>>>
>>
>> So we basically want an init() callback even in sdhci.c.
>>
>> I have to create one more wrapper sdhci_pltaform_init() API in the sdhci
>> driver that just calls a platform init function inside it. So its
>
> Yes, I checked wrong sequence. Sorry.
>
> When i have checked, some functions are needs.
>
>>
>> include/sdhci.h:
>>
>> struct sdhci_ops {
>> ..
>> + int (*platform_init)()
>>
>> and then drivers/mmc/sdhci.c:
>>
>>
>> +sdhci_platform_init()
>> +{
>> +...
>> + host->ops->platform_init();
>> +}
>>
>> const struct dm_mmc_ops sdhci_ops = {
>> ...
>> + .init = sdhci_platform_init,
>> };
>>
>> Right?
>
> Right. but not init. Just platform_init?
>
> Well, if you want, i will make patch about callback function.
How about below codes? Then you can just add am654_sdhci_deferred_probe { ...
return sdhci_probe() .. }
diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index 0b90a97650..c75892a72c 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -138,6 +138,21 @@ int mmc_host_power_cycle(struct mmc *mmc)
return dm_mmc_host_power_cycle(mmc->dev);
}
+int dm_mmc_deferred_probe(struct udevice *dev)
+{
+ struct dm_mmc_ops *ops = mmc_get_ops(dev);
+
+ if (ops->deferred_probe)
+ return ops->deferred_probe(dev);
+
+ return 0;
+}
+
+int mmc_deferred_probe(struct mmc *mmc)
+{
+ return dm_mmc_deferred_probe(mmc->dev);
+}
+
int mmc_of_parse(struct udevice *dev, struct mmc_config *cfg)
{
int val;
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index d43983d4a6..9eae538af4 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2790,6 +2790,7 @@ int mmc_get_op_cond(struct mmc *mmc)
#if CONFIG_IS_ENABLED(DM_MMC)
/* The device has already been probed ready for use */
+ mmc_deferred_probe(mmc);
#else
/* made sure it's not NULL earlier */
err = mmc->cfg->ops->init(mmc);
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 01fa5a9d4d..9ff37b888b 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -661,6 +661,20 @@ int sdhci_probe(struct udevice *dev)
return sdhci_init(mmc);
}
+static int sdhci_deferred_probe(struct udevice *dev)
+{
+ int err;
+ struct mmc *mmc = mmc_get_mmc_dev(dev);
+ struct sdhci_host *host = mmc->priv;
+
+ if (host->ops && host->ops->deferred_probe) {
+ err = host->ops->deferred_probe(host);
+ if (err)
+
Re: [PATCH v2 04/10] mmc: sdhci: Expose sdhci_init() as non-static
Hi Faiz,
On 2/17/20 9:42 PM, Faiz Abbas wrote:
> Jaehoon,
>
> On 17/02/20 5:47 pm, Jaehoon Chung wrote:
>> Hi,
>>
>> On 2/5/20 4:33 PM, Faiz Abbas wrote:
>>> Hi Peng,
>>>
>>> On 05/02/20 12:58 pm, Peng Fan wrote:
> Subject: Re: [PATCH v2 04/10] mmc: sdhci: Expose sdhci_init() as
> non-static
>
> Hi,
>
> On 31/01/20 3:55 am, Simon Goldschmidt wrote:
>> Am 30.01.2020 um 23:21 schrieb Jaehoon Chung:
>>> Hi Simon,
>>>
>>> On 1/29/20 11:16 PM, Simon Goldschmidt wrote:
On Wed, Jan 29, 2020 at 12:00 AM Jaehoon Chung
wrote:
>
> On 1/24/20 8:52 PM, Faiz Abbas wrote:
>> Expose sdhci_init() as non-static.
>
> Does it need to change to non-static?
And even if it needs to, can we have a reason *why* in the commit
message?
>>>
>>> When i read entire your series, it seems that doesn't need to change
>>> to non-static.
>>> All of change that touched MMC code are only for your board.
>>> I don't know Peng's opinion, but it's not my prefer.
>>
>> +1!
>>
>> We need to keep the core code clean of such hacks in order to keep the
>> size small for constrained targets!
>>
>
> Peng can you comment on this?
Just one more question, does kernel has same issue, how resolved?
Could U-Boot follow similar approach?
>>>
>>> Kernel has interrupts enabled. So software just has to wait for the card
>>> detect interrupt to arrive rather than poll on anything.
>>>
Actually I am fine with platform specific approach , considering
your platform issue.
But since Simon and Jaehoon has concerns, not sure whether
Simon and Jaehoon have good ideas.
>>>
>>> Ok. Lets see if they have some better ideas.
>>
>> Well, Your code needs to call am654_sdhci_init() before sdhci_init(), right?
>>
>> ops->init() -> am654_sdhci_init -> sdhci_init().
>> If am654_sdhci_init is called for preset, how about adding pre_init() or
>> other ops callback.
>> (pre_init is just example.)
>>
>> ops->pre_init = am654_sdhci_init; or ops->preset = am654_sdhci_preset;
>>
>> In mmc.
>>
>> ops->preset or ops->pre_init -> ops->init
>>
>> How about adding plotform specific init callback? Then someone can also use
>> it for platform specific things in future.
>>
>
> So we basically want an init() callback even in sdhci.c.
>
> I have to create one more wrapper sdhci_pltaform_init() API in the sdhci
> driver that just calls a platform init function inside it. So its
Yes, I checked wrong sequence. Sorry.
When i have checked, some functions are needs.
>
> include/sdhci.h:
>
> struct sdhci_ops {
> ..
> + int (*platform_init)()
>
> and then drivers/mmc/sdhci.c:
>
>
> +sdhci_platform_init()
> +{
> +...
> + host->ops->platform_init();
> +}
>
> const struct dm_mmc_ops sdhci_ops = {
> ...
> + .init = sdhci_platform_init,
> };
>
> Right?
Right. but not init. Just platform_init?
Well, if you want, i will make patch about callback function.
Best Regards,
Jaehoon Chung
>
> Thanks,
> Faiz
>
>
[PATCH] Revert "dm: fdt: scan for devices under /firmware too"
Subnodes under "/firmware" node are scanned twice in
dm_scan_fdt_node() and dm_extended_scan_fdt().
This patch removes the scanning in dm_scan_fdt_node() to
avoid double scanning.
This reverts commit 747558d014577526bf2e8d9fe9ca748fdbf75d8a.
Signed-off-by: Thirupathaiah Annapureddy
---
drivers/core/root.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/core/root.c b/drivers/core/root.c
index e85643819e..cb695e933a 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -254,15 +254,9 @@ static int dm_scan_fdt_node(struct udevice *parent, const
void *blob,
for (offset = fdt_first_subnode(blob, offset);
offset > 0;
offset = fdt_next_subnode(blob, offset)) {
- const char *node_name = fdt_get_name(blob, offset, NULL);
-
- /*
-* The "chosen" and "firmware" nodes aren't devices
-* themselves but may contain some:
-*/
- if (!strcmp(node_name, "chosen") ||
- !strcmp(node_name, "firmware")) {
- pr_debug("parsing subnodes of \"%s\"\n", node_name);
+ /* "chosen" node isn't a device itself but may contain some: */
+ if (!strcmp(fdt_get_name(blob, offset, NULL), "chosen")) {
+ pr_debug("parsing subnodes of \"chosen\"\n");
err = dm_scan_fdt_node(parent, blob, offset,
pre_reloc_only);
@@ -279,7 +273,8 @@ static int dm_scan_fdt_node(struct udevice *parent, const
void *blob,
pre_reloc_only);
if (err && !ret) {
ret = err;
- debug("%s: ret=%d\n", node_name, ret);
+ debug("%s: ret=%d\n", fdt_get_name(blob, offset, NULL),
+ ret);
}
}
--
2.24.1
Re: [PATCH V2 1/2] ARM: socfpga: Permit overriding the default timer frequency
Am 17.02.2020 um 18:30 schrieb Marek Vasut: > The default timer rate may be different than 25 MHz, permit overriding > the default rate in board configuration file. Ultimatelly, this should > be properly handled by a clock driver, however that is not available > on Gen5 yet. > > Signed-off-by: Marek Vasut > Cc: Ley Foon Tan > Cc: Simon Goldschmidt Reviewed-by: Simon Goldschmidt > --- > V2: Drop misleading comment > --- > include/configs/socfpga_common.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/configs/socfpga_common.h > b/include/configs/socfpga_common.h > index 8d10469e7c..54a43569dc 100644 > --- a/include/configs/socfpga_common.h > +++ b/include/configs/socfpga_common.h > @@ -94,12 +94,13 @@ > * L4 OSC1 Timer 0 > */ > #ifndef CONFIG_TIMER > -/* This timer uses eosc1, whose clock frequency is fixed at any condition. */ > #define CONFIG_SYS_TIMERBASE SOCFPGA_OSC1TIMER0_ADDRESS > #define CONFIG_SYS_TIMER_COUNTS_DOWN > #define CONFIG_SYS_TIMER_COUNTER (CONFIG_SYS_TIMERBASE + 0x4) > +#ifndef CONFIG_SYS_TIMER_RATE > #define CONFIG_SYS_TIMER_RATE2500 > #endif > +#endif > > /* > * L4 Watchdog >
[PATCH] arm: mvebu: clearfog: add scsi target to distro-boot
Support for sata devices via the scsi command is available and already enabled by default for the Clearfog Base and Pro. This change adds scsi to the list of boot targets used by distro-boot. Signed-off-by: Josua Mayer Cc: Stefan Roese --- include/configs/clearfog.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h index 633187d86f..33c71b3d51 100644 --- a/include/configs/clearfog.h +++ b/include/configs/clearfog.h @@ -104,6 +104,12 @@ #define BOOT_TARGET_DEVICES_MMC(func) #endif +#ifdef CONFIG_SCSI +#define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0) +#else +#define BOOT_TARGET_DEVICES_SCSI(func) +#endif + #ifdef CONFIG_USB_STORAGE #define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0) #else @@ -112,6 +118,7 @@ #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ + BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na) -- 2.25.0
Re: [PATCH v2] power-domain: fix hang in endless loop on i.MX8
On Mon, Feb 17, 2020 at 2:27 PM Fabio Estevam wrote:
> I also had to apply the following change in order to boot a i.MX8QXP MEK
> board:
>
> --- a/arch/arm/mach-imx/imx8/fdt.c
> +++ b/arch/arm/mach-imx/imx8/fdt.c
> @@ -280,6 +280,8 @@ int ft_system_setup(void *blob, bd_t *bd)
> {
> int ret;
>
> + return 0;
> +
> update_fdt_with_owned_resources(blob);
>
> if (is_imx8qm()) {
>
> With your patch and this change a 4.14.98 NXP kernel can boot, but not
> a 4.19.35 NXP nor a mainline kernel.
>
> Tested-by: Fabio Estevam
Correction: the above change is not needed now.
I saw an issue with the command line and I sent a fix.
This patch plus the one that fixes the command line are enough to get
i.MX8QXP MEK board booting a mainline kernel.
Thanks
[PATCH] imx8qxp_mek: Fix the console command line string
Currently the expansion of the console variable leads to
the following kernel command line:
console=ttyLP0,${baudrate} earlycon root=/dev/mmcblk1p2 rootwait rw
, which causes the console to not show characters after the LPUART driver
is probed as the 'baudrate' variable is not properly translated.
Fix it by splitting the console variable in two parts: one for the
ttyLP0 part and the other one for the baudrate, which matches the way
it is done on other i.MX targets.
Tested by successfully booting a mainline kernel on a i.MX8QXP MEK
board.
Signed-off-by: Fabio Estevam
---
Anatolij's patch is needed for booting:
https://lists.denx.de/pipermail/u-boot/2020-February/400417.html
include/configs/imx8qxp_mek.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/configs/imx8qxp_mek.h b/include/configs/imx8qxp_mek.h
index 81ac4b52f3..0aaca3325b 100644
--- a/include/configs/imx8qxp_mek.h
+++ b/include/configs/imx8qxp_mek.h
@@ -65,7 +65,7 @@
"script=boot.scr\0" \
"image=Image\0" \
"panel=NULL\0" \
- "console=ttyLP0,${baudrate} earlycon\0" \
+ "console=ttyLP0\0" \
"fdt_addr=0x8300\0" \
"fdt_high=0x\0" \
"boot_fdt=try\0" \
@@ -76,7 +76,7 @@
"mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
"mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \
"mmcautodetect=yes\0" \
- "mmcargs=setenv bootargs console=${console} root=${mmcroot}\0 " \
+ "mmcargs=setenv bootargs console=${console},${baudrate}
root=${mmcroot}\0 " \
"loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
"source\0" \
@@ -104,7 +104,7 @@
"echo wait for boot; " \
"fi;" \
"fi;\0" \
- "netargs=setenv bootargs console=${console} " \
+ "netargs=setenv bootargs console=${console},${baudrate} " \
"root=/dev/nfs " \
"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
"netboot=echo Booting from net ...; " \
--
2.17.1
Re: [PATCH] ARM: socfpga: Add initial support for the ABB SECU board
On 2/17/20 6:51 PM, Wolfgang Denk wrote: > Dear Marek, Hi, > In message <20200217173249.4805-1-ma...@denx.de> you wrote: >> >> board/keymile/Kconfig | 11 +- >> board/keymile/common/ivm.c | 18 +- >> board/keymile/secu1/Makefile| 7 + >> board/keymile/secu1/qts/iocsr_config.h | 694 >> board/keymile/secu1/qts/pinmux_config.h | 218 >> board/keymile/secu1/qts/pll_config.h| 83 +++ >> board/keymile/secu1/qts/sdram_config.h | 327 +++ >> board/keymile/secu1/socfpga.c | 67 +++ > ... >> +select VENDOR_KM > > Would it make sense to rename keymile -> abb (or abb-ch) here > (ditto for KM in the config options / macro names) ? This is more of a question for Holger, but I agree the renaming should eventually happen to align it with current state of things.
Re: [PATCH] ARM: socfpga: Add initial support for the ABB SECU board
Dear Marek, In message <20200217173249.4805-1-ma...@denx.de> you wrote: > > board/keymile/Kconfig | 11 +- > board/keymile/common/ivm.c | 18 +- > board/keymile/secu1/Makefile| 7 + > board/keymile/secu1/qts/iocsr_config.h | 694 > board/keymile/secu1/qts/pinmux_config.h | 218 > board/keymile/secu1/qts/pll_config.h| 83 +++ > board/keymile/secu1/qts/sdram_config.h | 327 +++ > board/keymile/secu1/socfpga.c | 67 +++ ... > + select VENDOR_KM Would it make sense to rename keymile -> abb (or abb-ch) here (ditto for KM in the config options / macro names) ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Time is an illusion perpetrated by the manufacturers of space.
Re: [PATCH] image.h: Change android_image_get_dtb* to use uint and not u32
On Mon, Feb 17, 2020 at 04:45:57PM +0900, Masahiro Yamada wrote:
> Hi Eugeniu, Tom,
>
>
> On Mon, Feb 17, 2020 at 7:05 AM Eugeniu Rosca wrote:
> >
> > Hi Tom,
> >
> > On Sun, Feb 16, 2020 at 11:53:23AM -0500, Tom Rini wrote:
> > > On Sun, Feb 16, 2020 at 05:23:14PM +0100, Eugeniu Rosca wrote:
> > > > On Fri, Feb 14, 2020 at 12:38:19PM -0500, Tom Rini wrote:
> > > > > The image.h header can be used fairly widely in U-Boot builds. We
> > > > > cannot use u32 here as it may be used in cases where we don't have
> > > > > that
> > > > > typedef available and don't want to expose it either. Use uint
> > > > > instead
> > > > > here.
> > > > >
> > > > > Cc: Eugeniu Rosca
> > > > > Cc: Sam Protsenko
> > > > > Signed-off-by: Tom Rini
> > > > > ---
> > > > > include/image.h | 6 +++---
> > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/include/image.h b/include/image.h
> > > > > index b316d167d8d7..1dc3b48d8689 100644
> > > > > --- a/include/image.h
> > > > > +++ b/include/image.h
> > > > > @@ -1425,9 +1425,9 @@ int android_image_get_ramdisk(const struct
> > > > > andr_img_hdr *hdr,
> > > > > ulong *rd_data, ulong *rd_len);
> > > > > int android_image_get_second(const struct andr_img_hdr *hdr,
> > > > > ulong *second_data, ulong *second_len);
> > > > > -bool android_image_get_dtbo(ulong hdr_addr, ulong *addr, u32 *size);
> > > > > -bool android_image_get_dtb_by_index(ulong hdr_addr, u32 index, ulong
> > > > > *addr,
> > > > > - u32 *size);
> > > > > +bool android_image_get_dtbo(ulong hdr_addr, ulong *addr, uint *size);
> > > > > +bool android_image_get_dtb_by_index(ulong hdr_addr, uint index,
> > > > > ulong *addr,
> > > > > + uint *size);
> > > >
> > > > While I think the change is harmless and brings some consistency and
> > > > visual comfort when reviewing the types employed in 'include/image.h',
> > > > I can hardly imagine a real-life breakage introduced by u32 in
> > > > 'include/image.h'.
> > >
> > > I ran in to this in practice with
> > > http://patchwork.ozlabs.org/project/uboot/list/?series=155410=*
> > > applied.
> >
> > Applying this series to u-boot/master, I am running into below build
> > failure [1], which I believe is something you try to fix in this patch.
> >
> > It looks to me that U-Boot's 'include/image.h' is used not only by
> > files which are compiled for the target device, but also by files
> > located in 'tools/', which are compiled for the host with -DUSE_HOSTCC.
> > After inspecting the 'tools/' path of U-Boot repository, it looks like
> > the definition of 'u32' is indeed missing there, so I believe that's
> > the root cause of the build failure.
>
>
> If you need a fixed-width type,
> you can use uint32_t if you like.
>
> It is already used. See line 183 of include/image.h
>
> typedef struct image_header {
> uint32_t ih_magic; /* Image Header Magic Number */
>
>
> include/compiler.h includes when USE_HOSTCC is defined.
>
>
>
> However, forbidding u32 for tools is questionable to me.
> u32 and uint32_t should be always interchangeable.
>
>
> Perhaps, does the following patch work? (untested)
> ->8
> diff --git a/include/compiler.h b/include/compiler.h
> index ed74c272b8c5..f2a4adfbc7e4 100644
> --- a/include/compiler.h
> +++ b/include/compiler.h
> @@ -61,6 +61,9 @@
>
> #include
>
> +typedef uint8_t u8;
> +typedef uint16_t u16;
> +typedef uint32_t u32;
> typedef uint8_t __u8;
> typedef uint16_t __u16;
> typedef uint32_t __u32;
> ->8
>
>
>
> BTW, I think include/compiler.h in U-Boot is ugly.
Yes, we should not further expand that file. We should indeed get rid
of it.
> Linux kernel uses
> tools/include/linux/types.h
> for defining {u8,u16,u32,u64} for the tools space.
>
>
> Barebox also adopted a similar approach.
>
> When compiling files for tools,
> actually includes
> scripts/include/linux/types.h
> instead of include/linux/types.h
>
>
> Perhaps, U-Boot could do similar,
> but I have never got around to it.
Yes, it's just another thing on the TODO list that's not been re-synced
in a while.
> > W.r.t. 'android_image_*' functions, I really doubt that they were
> > designed to be compiled with USE_HOSTCC. If so, then IMHO we shouldn't
> > try to make them compliant with USE_HOSTCC compilation, since this
> > will impose additional constraints/requirements to the development style
> > of those functions. IMHO we should just hide the android_image functions
> > on enabling -DUSE_HOSTCC, as shown in [2]. What's your view on that?
> > [1] Build error after applying to u-boot/master below series:
> >http://patchwork.ozlabs.org/project/uboot/list/?series=155410=*
> >
> > In file included from include/u-boot/rsa-mod-exp.h:10,
> > from ./tools/../lib/rsa/rsa-verify.c:22,
> >
[PATCH] ARM: socfpga: Add initial support for the ABB SECU board
From: Holger Brunck
Add initial support for the ABB SECU board, which is an ArriaV-based
SoCFPGA system with ethernet and booting from Denali NAND.
Signed-off-by: Holger Brunck
Cc: Ley Foon Tan
Cc: Simon Goldschmidt
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/socfpga_arria5_secu1.dts | 130 +
arch/arm/mach-socfpga/Kconfig | 10 +
board/keymile/Kconfig | 11 +-
board/keymile/common/ivm.c | 18 +-
board/keymile/secu1/Makefile| 7 +
board/keymile/secu1/qts/iocsr_config.h | 694
board/keymile/secu1/qts/pinmux_config.h | 218
board/keymile/secu1/qts/pll_config.h| 83 +++
board/keymile/secu1/qts/sdram_config.h | 327 +++
board/keymile/secu1/socfpga.c | 67 +++
configs/socfpga_secu1_defconfig | 83 +++
include/configs/socfpga_arria5_secu1.h | 131 +
13 files changed, 1776 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/dts/socfpga_arria5_secu1.dts
create mode 100644 board/keymile/secu1/Makefile
create mode 100644 board/keymile/secu1/qts/iocsr_config.h
create mode 100644 board/keymile/secu1/qts/pinmux_config.h
create mode 100644 board/keymile/secu1/qts/pll_config.h
create mode 100644 board/keymile/secu1/qts/sdram_config.h
create mode 100644 board/keymile/secu1/socfpga.c
create mode 100644 configs/socfpga_secu1_defconfig
create mode 100644 include/configs/socfpga_arria5_secu1.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index be4cf029d0..9c593b2c98 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -333,6 +333,7 @@ dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
dtb-$(CONFIG_ARCH_SOCFPGA) += \
socfpga_agilex_socdk.dtb\
+ socfpga_arria5_secu1.dtb\
socfpga_arria5_socdk.dtb\
socfpga_arria10_socdk_sdmmc.dtb \
socfpga_cyclone5_mcvevk.dtb \
diff --git a/arch/arm/dts/socfpga_arria5_secu1.dts
b/arch/arm/dts/socfpga_arria5_secu1.dts
new file mode 100644
index 00..dadf766682
--- /dev/null
+++ b/arch/arm/dts/socfpga_arria5_secu1.dts
@@ -0,0 +1,130 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016-2020 ABB
+ */
+
+#include "socfpga_arria5.dtsi"
+#include "socfpga-common-u-boot.dtsi"
+#include
+
+/ {
+ model = "ABB SoC SECU1 Board";
+ compatible = "altr,socfpga-secu1", "altr,socfpga";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ bootargs = "console=ttyS0,115200";
+ };
+
+ memory {
+ name = "memory";
+ device_type = "memory";
+ reg = <0x0 0x2000>; /* 512MB */
+ };
+
+ aliases {
+ /*
+* this allow the ethaddr uboot environment variable contents
+* to be added to the gmac0 device tree blob.
+*/
+ ethernet0 =
+ spi0 =
+ };
+
+ i2c_gpio: i2c@0 {
+ compatible = "i2c-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpios = < 5 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)/* SDA
*/
+ 6 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; /* SCL
*/
+ i2c-gpio,delay-us = <5>;/* ~100 kHz */
+ i2c-gpio,deblock;
+
+ temp_sensor@48 {
+ compatible = "national,lm75";
+ reg = <0x48>;
+ };
+
+ eeprom@50 {
+ compatible = "at,24c08";
+ reg = <0x50>;
+ };
+
+ rtc: rtc@68 {
+ compatible = "st,m41st87";
+ reg = <0x68>;
+ interrupt-parent = <>;
+ interrupts = <0 42 0x4>;
+ };
+ };
+
+ regulator_3_3v: 3-3-v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+};
+
+ {
+ status = "okay";
+ phy-mode = "rgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ vmmc-supply = <_3_3v>;
+ vqmmc-supply = <_3_3v>;
+ bus-width = <4>;
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ bank-name = "porta";
+};
+
+ {
+ bank-name = "portb";
+};
+
+ {
+ bank-name = "portc";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ clock-frequency = <1>;
+ u-boot,dm-pre-reloc;
+ status = "okay";
+};
+
+ {
+ clock-frequency = <1>;
+};
+
+ {
+
[PATCH V2 2/2] ARM: socfpga: Add missing Denali NAND config options
The Denali SPL shim won't build without these options set, set them accordingly to fix the build error and let the SPL shim to work correctly. Signed-off-by: Marek Vasut Cc: Ley Foon Tan Cc: Simon Goldschmidt --- V2: No changes --- include/configs/socfpga_common.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 54a43569dc..29b0a5d69d 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -121,6 +121,8 @@ * NAND Support */ #ifdef CONFIG_NAND_DENALI +#define CONFIG_SYS_NAND_USE_FLASH_BBT +#define CONFIG_SYS_NAND_BAD_BLOCK_POS 0 #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define CONFIG_SYS_NAND_ONFI_DETECTION #define CONFIG_SYS_NAND_REGS_BASE SOCFPGA_NANDREGS_ADDRESS -- 2.24.1
[PATCH V2 1/2] ARM: socfpga: Permit overriding the default timer frequency
The default timer rate may be different than 25 MHz, permit overriding the default rate in board configuration file. Ultimatelly, this should be properly handled by a clock driver, however that is not available on Gen5 yet. Signed-off-by: Marek Vasut Cc: Ley Foon Tan Cc: Simon Goldschmidt --- V2: Drop misleading comment --- include/configs/socfpga_common.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 8d10469e7c..54a43569dc 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -94,12 +94,13 @@ * L4 OSC1 Timer 0 */ #ifndef CONFIG_TIMER -/* This timer uses eosc1, whose clock frequency is fixed at any condition. */ #define CONFIG_SYS_TIMERBASE SOCFPGA_OSC1TIMER0_ADDRESS #define CONFIG_SYS_TIMER_COUNTS_DOWN #define CONFIG_SYS_TIMER_COUNTER (CONFIG_SYS_TIMERBASE + 0x4) +#ifndef CONFIG_SYS_TIMER_RATE #define CONFIG_SYS_TIMER_RATE 2500 #endif +#endif /* * L4 Watchdog -- 2.24.1
Re: [PATCH v2] power-domain: fix hang in endless loop on i.MX8
Hi Anatolij,
On Mon, Feb 17, 2020 at 5:42 AM Anatolij Gustschin wrote:
>
> Currently when booting the kernel on i.MX8 U-Boot hangs in an
> endless loop when switching off dma, connectivity or lsio power
> domains during device removal. It hapens first when removing
> gpio0 (gpio@5d08) device, here its power domain device
> 'lsio_gpio0' is obtained for switching off power. Since the
> obtained 'lsio_gpio0' device is removed afterwards, its power
> domain is also switched off and here the parent power domain
> device 'lsio_power_domain' is optained for switching off the
> power. Thereafter, when the obtained 'lsio_power_domain' is
> removed, device_remove() removes its first child 'lsio_gpio0'.
> During this child removal the 'lsio_power_domain' device is
> obtained again for switching and when removing it later,
> the same child removal is repeated, so we are stuck in an
> endless loop. Below is a snippet from dm tree on i.MX8QXP
> for better illustration of the DM devices relationship:
>
> Class Index Probed DriverName
> ---
> root 0 [ + ] root_driver root_driver
> ...
> simple_bus0 [ + ] generic_simple_bus|-- imx8qx-pm
> power_doma0 [ + ] imx8_power_domain | |-- lsio_power_domain
> power_doma1 [ + ] imx8_power_domain | | |-- lsio_gpio0
> power_doma2 [ + ] imx8_power_domain | | |-- lsio_gpio1
>
> Do not remove a power domain device if it is a parent of the
> currently controlled device.
>
> Fixes: 52edfed65de9 ("dm: core: device: switch off power domain after device
> removal")
> Signed-off-by: Anatolij Gustschin
I also had to apply the following change in order to boot a i.MX8QXP MEK board:
--- a/arch/arm/mach-imx/imx8/fdt.c
+++ b/arch/arm/mach-imx/imx8/fdt.c
@@ -280,6 +280,8 @@ int ft_system_setup(void *blob, bd_t *bd)
{
int ret;
+ return 0;
+
update_fdt_with_owned_resources(blob);
if (is_imx8qm()) {
With your patch and this change a 4.14.98 NXP kernel can boot, but not
a 4.19.35 NXP nor a mainline kernel.
Tested-by: Fabio Estevam
Re: [PATCH 1/2] dm: core: Add a flag for power domain control on device removal
On 17/02/2020 12:36, Anatolij Gustschin wrote:
> In various cases a power domain must stay enabled after device
> removal when booting OS (i.e. serial debug console or display).
> Add a flag to selectively skip switching off a power domain.
>
> Fixes: 52edfed65de9 ("dm: core: device: switch off power domain after device
> removal")
> Signed-off-by: Anatolij Gustschin
> ---
> drivers/core/device-remove.c | 5 +++--
> include/dm/device.h | 6 ++
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
> index 444e34b492..ff5b28cb6a 100644
> --- a/drivers/core/device-remove.c
> +++ b/drivers/core/device-remove.c
> @@ -194,8 +194,9 @@ int device_remove(struct udevice *dev, uint flags)
> }
> }
>
> - if (!(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF) &&
> - (dev != gd->cur_serial_dev))
> + if (!(drv->flags &
> + (DM_FLAG_DEFAULT_PD_CTRL_OFF | DM_FLAG_REMOVE_WITH_PD_ON)) &&
> + dev != gd->cur_serial_dev)
> dev_power_domain_off(dev);
>
> if (flags_remove(flags, drv->flags)) {
> diff --git a/include/dm/device.h b/include/dm/device.h
> index ab806d0b7e..a56164b19b 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -67,6 +67,12 @@ struct driver_info;
> /* Driver platdata has been read. Cleared when the device is removed */
> #define DM_FLAG_PLATDATA_VALID (1 << 12)
>
> +/*
> + * Device is removed without switching off its power domain. This might
> + * be required, i. e. for serial console (debug) output when booting OS.
> + */
> +#define DM_FLAG_REMOVE_WITH_PD_ON(1 << 13)
> +
> /*
> * One or multiple of these flags are passed to device_remove() so that
> * a selective device removal as specified by the remove-stage and the
>
Acked-by: Neil Armstrong
and
Tested-by: Guillaume La Roque
Thanks,
Neil
Re: [PATCH 2/2] video: meson: keep power domain up after booting
On 17/02/2020 12:36, Anatolij Gustschin wrote:
> Add driver flag to skip power domain disabling on device removal.
>
> Fixes: 52edfed65de9 ("dm: core: device: switch off power domain after device
> removal")
> Signed-off-by: Anatolij Gustschin
> ---
> drivers/video/meson/meson_vpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/meson/meson_vpu.c b/drivers/video/meson/meson_vpu.c
> index 4eb66398d0..aa8c0a962f 100644
> --- a/drivers/video/meson/meson_vpu.c
> +++ b/drivers/video/meson/meson_vpu.c
> @@ -210,5 +210,5 @@ U_BOOT_DRIVER(meson_vpu) = {
> .probe = meson_vpu_probe,
> .bind = meson_vpu_bind,
> .priv_auto_alloc_size = sizeof(struct meson_vpu_priv),
> - .flags = DM_FLAG_PRE_RELOC,
> + .flags = DM_FLAG_PRE_RELOC | DM_FLAG_REMOVE_WITH_PD_ON,
> };
>
Acked-by: Neil Armstrong
and
Tested-by: Guillaume La Roque
Thanks,
Neil
Re: [PATCH] Revert "dm: core: device: switch off power domain after device removal"
Hi Anatolij, On 17/02/2020 12:53, Anatolij Gustschin wrote: > On Mon, 17 Feb 2020 10:10:36 +0100 > Neil Armstrong narmstr...@baylibre.com wrote: > >> This commit breaks Linux boot on Amlogic libretech-cc, libretech-ac, sei510, >> sei610 board by automatically disabling the power domain after device >> removal. >> This because the power domain associated to the video driver must be kept >> enabled for linux to boot. >> >> The only way is to use the introduced flag DM_FLAG_DEFAULT_PD_CTRL_OFF, which >> removes automatic handling of power domain. >> This flag is not a complete solution since it will force reverting to >> manually >> enable the power domain from the driver probe. >> >> Instead a flag to keep the power domain enabled after removal should be >> introduced. >> >> In the meantime revert this commit until a proper solution is found. >> >> This reverts commit 52edfed65de967a86983a55c51ba0727090efc43. >> >> Signed-off-by: Neil Armstrong >> --- >> Hi Simon, Tom, >> >> This revert is the simplest fix to make the boards boot again on v2020.04, >> the goal is to make this behavior happen again with a proper flag to keep the >> power domain enabled on specific drivers. >> >> I can push it on my next PR on my branch, is it ok ? > Thanks for pushing these, they should do the trick. Let me test them and ack them. Neil > Please test if these two patches fix the problem: > http://patchwork.ozlabs.org/patch/1239143 > http://patchwork.ozlabs.org/patch/1239144 > > -- > Anatolij >
Re: use invd instead of wbinvd in real mode start code
On Mon, Feb 17, 2020 at 05:32:45PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wrote:
> > In message
> > you
> > wrote:
> > >
> > > > > git bisect is the usual way to figure out the culprit.
> > > >
> > > > Too much work to do this way.
> >
> > If you find bisecting is too much work you probably still do it
> > manually. Why don't you use tbot to automize such boring and time
> > consuming tasks?
>
> Bisection time something about 10%, while 90% is flashing the board
> and, given the result, triggering either bad or good next cycle.
In case our emails crossed, this is where 'git bisect run' comes in
handy if you can automate the flashing. It's why I have the follow
script locally:
#!/bin/bash
if [ $# -ne 1 -a $# -ne 2 ]; then
echo "Usage: $0 buildman-spec test.py-id"
exit 1
fi
if [ $# -eq 2 ]; then
ARGS="$1 --id $2"
else
ARGS="$1"
fi
# Build the board
virtualenv -p /usr/bin/python3 /tmp/venv
. /tmp/venv/bin/activate
pip install -r test/py/requirements.txt
set +e
./tools/buildman/buildman -o /tmp -P ^${1}$
set -e
# Run the tests
export PATH=${PATH}:/home/trini/work/u-boot/uboot-test-hooks/bin
export
PYTHONPATH=/home/trini/work/u-boot/uboot-test-hooks/py/bill-the-cat:${PYTHONPATH}
export UBOOT_TRAVIS_BUILD_DIR=/tmp/.bm-work/$1
./test/py/test.py --bd $ARGS --build-dir "$UBOOT_TRAVIS_BUILD_DIR" -k 'not
sleep'
To run test.py automatically for a board, and I have several boards
hooked up to the framework Stephen Warren has. When I need to bisect a
boot failure I change 'not sleep' to 'version' so it only runs that one
super quick test. Then 'git bisect run uboot-test.sh boardname' once I
have the first good/bad. And I'll do a 'git checkout' of a commit or
two if I have a hunch of what introduced the failure.
--
Tom
signature.asc
Description: PGP signature
Re: use invd instead of wbinvd in real mode start code
Dear Andy, In message you wrote: > On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wrote: > > In message > > you > > wrote: > > > > > > > > git bisect is the usual way to figure out the culprit. > > > > > > > > Too much work to do this way. > > > > If you find bisecting is too much work you probably still do it > > manually. Why don't you use tbot to automize such boring and time > > consuming tasks? > > Bisection time something about 10%, while 90% is flashing the board > and, given the result, triggering either bad or good next cycle. Yes, and this is exactly what tbot was made for - automating such repeating, boring activities. It is wasted life time to do this manually. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de GUIs are virtually useless. Learn tools. They're configurable, scriptable, automatable, cron-able, interoperable, etc. We don't need no brain-dead winslurping monolithic claptrap. -- Tom Christiansen in 371140df@csnews
Re: use invd instead of wbinvd in real mode start code
On Mon, Feb 17, 2020 at 05:33:59PM +0200, Andy Shevchenko wrote: > On Mon, Feb 17, 2020 at 5:32 PM Andy Shevchenko > wrote: > > On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wrote: > > > In message > > > you > > > wrote: > > > > > > > > > > git bisect is the usual way to figure out the culprit. > > > > > > > > > > Too much work to do this way. > > > > > > If you find bisecting is too much work you probably still do it > > > manually. Why don't you use tbot to automize such boring and time > > > consuming tasks? > > > > Bisection time something about 10%, while 90% is flashing the board > > and, given the result, triggering either bad or good next cycle. > > And btw, doing git bisect is not mandatory technique to follow as long > as I can guarantee the (reproducible) result, right? No, it's not. But personally 'git bisect run' and 'git stash' are the two features that put git far above any other SCM I've used. -- Tom signature.asc Description: PGP signature
Re: use invd instead of wbinvd in real mode start code
On Mon, Feb 17, 2020 at 5:32 PM Andy Shevchenko wrote: > On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wrote: > > In message > > you > > wrote: > > > > > > > > git bisect is the usual way to figure out the culprit. > > > > > > > > Too much work to do this way. > > > > If you find bisecting is too much work you probably still do it > > manually. Why don't you use tbot to automize such boring and time > > consuming tasks? > > Bisection time something about 10%, while 90% is flashing the board > and, given the result, triggering either bad or good next cycle. And btw, doing git bisect is not mandatory technique to follow as long as I can guarantee the (reproducible) result, right? -- With Best Regards, Andy Shevchenko
Re: use invd instead of wbinvd in real mode start code
On Mon, Feb 17, 2020 at 5:09 PM Wolfgang Denk wrote: > In message > you > wrote: > > > > > > git bisect is the usual way to figure out the culprit. > > > > > > Too much work to do this way. > > If you find bisecting is too much work you probably still do it > manually. Why don't you use tbot to automize such boring and time > consuming tasks? Bisection time something about 10%, while 90% is flashing the board and, given the result, triggering either bad or good next cycle. -- With Best Regards, Andy Shevchenko
Re: use invd instead of wbinvd in real mode start code
On Mon, Feb 17, 2020 at 4:49 PM Bin Meng wrote: > On Mon, Feb 17, 2020 at 10:00 PM Andy Shevchenko > wrote: ... > > > Is that because on Intel Edison U-Boot is not the first stage bootloader? > > > > I don't know for sure, but I may speculate that this is a prerequisite. > > anyway, for now please send a revert patch. Just sent, thanks! -- With Best Regards, Andy Shevchenko
[PATCH v1] Revert "x86: use invd instead of wbinvd in real mode start code"
This reverts commit 0d67fac29f3187e67f4fd3ef15f73e91be2fad12. As real hardware testing (*) shows the above mentioned commit breaks U-Boot on it. Revert for the upcoming release. We may get more information in the future and optimize the code accordingly. (*) om Intel Edison board. Signed-off-by: Andy Shevchenko --- arch/x86/cpu/start.S | 2 +- arch/x86/cpu/start16.S | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S index 26cf995db2..01524635e9 100644 --- a/arch/x86/cpu/start.S +++ b/arch/x86/cpu/start.S @@ -50,7 +50,7 @@ _x86boot_start: movl%cr0, %eax orl $(X86_CR0_NW | X86_CR0_CD), %eax movl%eax, %cr0 - invd + wbinvd /* * Zero the BIST (Built-In Self Test) value since we don't have it. diff --git a/arch/x86/cpu/start16.S b/arch/x86/cpu/start16.S index 292e750508..54f4ff6662 100644 --- a/arch/x86/cpu/start16.S +++ b/arch/x86/cpu/start16.S @@ -28,7 +28,7 @@ start16: movl%cr0, %eax orl $(X86_CR0_NW | X86_CR0_CD), %eax movl%eax, %cr0 - invd + wbinvd /* load the temporary Global Descriptor Table */ data32 cs lidtidt_ptr -- 2.25.0
Re: use invd instead of wbinvd in real mode start code
On Mon, Feb 17, 2020 at 04:09:29PM +0100, Wolfgang Denk wrote: > Dear Andy, > > In message > you > wrote: > > > > > > git bisect is the usual way to figure out the culprit. > > > > > > Too much work to do this way. > > If you find bisecting is too much work you probably still do it > manually. Why don't you use tbot to automize such boring and time > consuming tasks? The problem with bisect'ing problems like these is always "how do I wire up updating the board" and not so much "how do I bisect it quickly". If you can update the board automatically you can let 'git bisect run' go off on the problem with a simple script that updates + runs our test.py code and just the version check test. That's what I do anyhow :) While I think the programmer I have for my minnowboard could be wired up in such a way, I have not due to general fear of wearing out the SPI. -- Tom signature.asc Description: PGP signature
Re: use invd instead of wbinvd in real mode start code
Dear Andy, In message you wrote: > > > > git bisect is the usual way to figure out the culprit. > > > > Too much work to do this way. If you find bisecting is too much work you probably still do it manually. Why don't you use tbot to automize such boring and time consuming tasks? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de All he had was nothing, but that was something, and now it had been taken away. - Terry Pratchett, _Sourcery_
Re: use invd instead of wbinvd in real mode start code
On Mon, Feb 17, 2020 at 10:00 PM Andy Shevchenko wrote: > > On Mon, Feb 17, 2020 at 3:52 PM Bin Meng wrote: > > On Mon, Feb 17, 2020 at 9:47 PM Andy Shevchenko > > wrote: > > > On Mon, Feb 17, 2020 at 3:39 PM Andy Shevchenko > > > wrote: > > > > On Mon, Feb 17, 2020 at 2:41 PM Masahiro Yamada > > > > wrote: > > > > > On Mon, Feb 17, 2020 at 9:31 PM Andy Shevchenko > > > > > wrote: > > ... > > > > OK, as my intuition told me the problematic one is > > > > > > commit 0d67fac29f3187e67f4fd3ef15f73e91be2fad12 > > > Author: Masahiro Yamada > > > Date: Wed Jan 8 20:08:44 2020 +0900 > > > > > >x86: use invd instead of wbinvd in real mode start code > > > > > > > > > Please, revert or fix ASAP before v2020.04 release! > > > ^^^ > > > > > > > > > P.S. I dunno how it has been tested, so, if you have Intel Edison in > > > > > > possession, please, don't forget to test on it. It's not first time > > > > > > the Intel Edison behaviour is broken due to poor testing. > > > > > > > > > > > > > > > I tested my patches on qemu. > > > > > > > > Exactly my point of definition "poor". > > > > It's not first time (and not last) when QEmu sucks. > > > > > > > > > Sorry for the breakage on your board, but I do not > > > > > have Edison board. > > > > > It is not possible to test every board. > > > > > > > > No problem, it's rather to x86 maintainers to have at least one-two > > > > real hardware testing before applying this. > > > > QEMU is completely not enough! > > > Is that because on Intel Edison U-Boot is not the first stage bootloader? > > I don't know for sure, but I may speculate that this is a prerequisite. anyway, for now please send a revert patch. Regards, Bin
Re: use invd instead of wbinvd in real mode start code
On Mon, Feb 17, 2020 at 3:52 PM Bin Meng wrote: > On Mon, Feb 17, 2020 at 9:47 PM Andy Shevchenko > wrote: > > On Mon, Feb 17, 2020 at 3:39 PM Andy Shevchenko > > wrote: > > > On Mon, Feb 17, 2020 at 2:41 PM Masahiro Yamada > > > wrote: > > > > On Mon, Feb 17, 2020 at 9:31 PM Andy Shevchenko > > > > wrote: ... > > OK, as my intuition told me the problematic one is > > > > commit 0d67fac29f3187e67f4fd3ef15f73e91be2fad12 > > Author: Masahiro Yamada > > Date: Wed Jan 8 20:08:44 2020 +0900 > > > >x86: use invd instead of wbinvd in real mode start code > > > > > > Please, revert or fix ASAP before v2020.04 release! > > ^^^ > > > > > > > P.S. I dunno how it has been tested, so, if you have Intel Edison in > > > > > possession, please, don't forget to test on it. It's not first time > > > > > the Intel Edison behaviour is broken due to poor testing. > > > > > > > > > > > > I tested my patches on qemu. > > > > > > Exactly my point of definition "poor". > > > It's not first time (and not last) when QEmu sucks. > > > > > > > Sorry for the breakage on your board, but I do not > > > > have Edison board. > > > > It is not possible to test every board. > > > > > > No problem, it's rather to x86 maintainers to have at least one-two > > > real hardware testing before applying this. > > > QEMU is completely not enough! > Is that because on Intel Edison U-Boot is not the first stage bootloader? I don't know for sure, but I may speculate that this is a prerequisite. -- With Best Regards, Andy Shevchenko
Re: use invd instead of wbinvd in real mode start code
Hi Andy, On Mon, Feb 17, 2020 at 9:47 PM Andy Shevchenko wrote: > > (Cc'ing mailing list and Tom again, thus keep entire previous answer) > > On Mon, Feb 17, 2020 at 3:39 PM Andy Shevchenko > wrote: > > On Mon, Feb 17, 2020 at 2:41 PM Masahiro Yamada > > wrote: > > > On Mon, Feb 17, 2020 at 9:31 PM Andy Shevchenko > > > wrote: > > > > > > It seems Masahiro's patches (don't know yet which one out of two, > > > > probably invd one) broke the boot on Intel Edison. > > > > > > > > Reverting (both for now) helps. > > > > > > Why both? > > > > Because I did bisecting by intuition (much faster than usual one). > > > > > git bisect is the usual way to figure out the culprit. > > > > Too much work to do this way. > > > > And since I was about to have my lunch, I didn't continue > > investigating. Let me do it now. > > OK, as my intuition told me the problematic one is > > commit 0d67fac29f3187e67f4fd3ef15f73e91be2fad12 > Author: Masahiro Yamada > Date: Wed Jan 8 20:08:44 2020 +0900 > >x86: use invd instead of wbinvd in real mode start code > > > Please, revert or fix ASAP before v2020.04 release! > ^^^ > > > > > P.S. I dunno how it has been tested, so, if you have Intel Edison in > > > > possession, please, don't forget to test on it. It's not first time > > > > the Intel Edison behaviour is broken due to poor testing. > > > > > > > > > I tested my patches on qemu. > > > > Exactly my point of definition "poor". > > It's not first time (and not last) when QEmu sucks. > > > > > Sorry for the breakage on your board, but I do not > > > have Edison board. > > > It is not possible to test every board. > > > > No problem, it's rather to x86 maintainers to have at least one-two > > real hardware testing before applying this. > > QEMU is completely not enough! > Is that because on Intel Edison U-Boot is not the first stage bootloader? Regards, Bin
Re: use invd instead of wbinvd in real mode start code
(Cc'ing mailing list and Tom again, thus keep entire previous answer) On Mon, Feb 17, 2020 at 3:39 PM Andy Shevchenko wrote: > On Mon, Feb 17, 2020 at 2:41 PM Masahiro Yamada wrote: > > On Mon, Feb 17, 2020 at 9:31 PM Andy Shevchenko > > wrote: > > > > It seems Masahiro's patches (don't know yet which one out of two, > > > probably invd one) broke the boot on Intel Edison. > > > > > > Reverting (both for now) helps. > > > > Why both? > > Because I did bisecting by intuition (much faster than usual one). > > > git bisect is the usual way to figure out the culprit. > > Too much work to do this way. > > And since I was about to have my lunch, I didn't continue > investigating. Let me do it now. OK, as my intuition told me the problematic one is commit 0d67fac29f3187e67f4fd3ef15f73e91be2fad12 Author: Masahiro Yamada Date: Wed Jan 8 20:08:44 2020 +0900 x86: use invd instead of wbinvd in real mode start code Please, revert or fix ASAP before v2020.04 release! ^^^ > > > P.S. I dunno how it has been tested, so, if you have Intel Edison in > > > possession, please, don't forget to test on it. It's not first time > > > the Intel Edison behaviour is broken due to poor testing. > > > > > > I tested my patches on qemu. > > Exactly my point of definition "poor". > It's not first time (and not last) when QEmu sucks. > > > Sorry for the breakage on your board, but I do not > > have Edison board. > > It is not possible to test every board. > > No problem, it's rather to x86 maintainers to have at least one-two > real hardware testing before applying this. > QEMU is completely not enough! -- With Best Regards, Andy Shevchenko
Re: [RFC 2/2] Revert "dm: core: device: switch off power domain after device removal"
On 17/02/20 6:35 PM, Anatolij Gustschin wrote:
> On Thu, 13 Feb 2020 18:12:12 +0100
> Neil Armstrong narmstr...@baylibre.com wrote:
>
>> Hi,
>>
>> On 03/02/2020 14:59, Oliver Graute wrote:
>>> The conga-imx8 board isn't booting without this revert. Can someone tell me
>>> what I need to Do so that this revert is not necessary?
>>>
>>> This reverts commit 52edfed65de967a86983a55c51ba0727090efc43.
>>> ---
>>> drivers/core/device-remove.c | 5 -
>>> 1 file changed, 5 deletions(-)
>>>
>>> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
>>> index 5c8dc4ad70..586fadee0a 100644
>>> --- a/drivers/core/device-remove.c
>>> +++ b/drivers/core/device-remove.c
>>> @@ -16,7 +16,6 @@
>>> #include
>>> #include
>>> #include
>>> -#include
>>>
>>> int device_chld_unbind(struct udevice *dev, struct driver *drv)
>>> {
>>> @@ -193,10 +192,6 @@ int device_remove(struct udevice *dev, uint flags)
>>> }
>>> }
>>>
>>> - if (!(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF) &&
>>> - (dev != gd->cur_serial_dev))
>>> - dev_power_domain_off(dev);
>>> -
>>> if (flags_remove(flags, drv->flags)) {
>>> device_free(dev);
>>>
>>>
>>
>> It also breaks amlogic boards with video, since we can't tell we want
>> to keep the power domains up after boot, it cuts the power domains and
>> thus defeats all the goal of u-boot video...
>>
>> The problem is DM_FLAG_DEFAULT_PD_CTRL_OFF disables auto power domain on
>> aswell, reverting to manual power domain enable.
>
> Yes, in some special cases manual power domain enable is required,
> this is the reason why this flag has been introduced. This flag is
> not for controlling power off for auto-enabled domains.
>
> My original patch v3 [1] suggested another flag DM_FLAG_REMOVE_WITH_PD_ON,
> but in the subsequent patch (which was then merged) Lokesh replaced this
> with another flag DM_FLAG_DEFAULT_PD_CTRL_OFF for different purpose and
> dropped DM_FLAG_REMOVE_WITH_PD_ON.
May be you should see the patch that introduces the specific flag[0] :). Flag
DM_FLAG_REMOVE_WITH_PD_ON[1] does not have any users at that point. Why would we
introduce it without any users?. Even with the patch it would be breaking the
above driver unless explicitly enabled.
IMHO, it is dm core controlling the PD or not. Why will it control just the
enabling part. May be I am wrong, but anyways Ill let Simon and Tom to have a
decision on it.
[0] https://patchwork.ozlabs.org/patch/1168343/
[1] https://patchwork.ozlabs.org/patch/1140138/
Thanks and regards,
Lokesh
Re: [PATCH v5] Add support for SoM "VoCore2".
Hi Daniel, a gentle reminder... I was unable to comply with a few of Your remarks (see below), What should I do? Submit v6 as is or do You have specific instructions? Thanks a lot Mauro On 2/12/20 11:01 PM, Mauro Condarelli wrote: > Thanks Daniel, > > On 2/12/20 5:58 PM, Daniel Schwierzeck wrote: >> On Wed, Feb 12, 2020 at 4:30 PM Mauro Condarelli wrote: >>> Small patch series to add support for VoCore/VoCore2 board. >>> >>> VoCore is open hardware and runs OpenWrt/LEDE. >>> It has WIFI, USB, UART, 20+ GPIOs but is only one inch square. >>> It will help you to make a smart house, study embedded system >>> or even make the tiniest router in the world. >>> >>> ===8<--- >>> diff --git a/board/vocore/vocore2/board.c b/board/vocore/vocore2/board.c >>> new file mode 100644 >>> index 00..27e42d1414 >>> --- /dev/null >>> +++ b/board/vocore/vocore2/board.c >>> @@ -0,0 +1,6 @@ >>> +// SPDX-License-Identifier: GPL-2.0+ >>> +/* >>> + * Copyright (C) 2019 Mauro Condarelli >>> + * >>> + * Nothing actually needed here >>> + */ >> if that file is empty, don't add it at all > Ahem... > > I tried to remove it, but if I do I also have to remove entry > in board/vocore/vocore2/Makefile (leaving it empty) and this > leads (on a clean compile) to error: > Â mipsel-linux-ld.bfd: cannot find board/vocore/vocore2/built-in.o: No > such file or directory > Completely removing both files bombs with: > Â scripts/Makefile.build:57: board/vocore/vocore2/Makefile: No such file > or directory > It seems I should also remove board/vocore/vocore2/Kconfig, > but I'm unsure this is the right thing to do. > > I have no idea about how to solve this, sorry. > Can You point me in the right direction, please? > > >>> ===8<--- >>> diff --git a/include/configs/vocore2.h b/include/configs/vocore2.h >>> new file mode 100644 >>> index 00..6b43aa766e >>> --- /dev/null >>> +++ b/include/configs/vocore2.h >>> @@ -0,0 +1,61 @@ >>> +/* SPDX-License-Identifier: GPL-2.0+ */ >>> +/* >>> + * Copyright (C) 2019 Mauro Condarelli >>> + */ >>> + >>> +#ifndef __VOCORE2_CONFIG_H__ >>> +#define __VOCORE2_CONFIG_H__ >>> + >>> +/* CPU */ >>> +#define CONFIG_SYS_MIPS_TIMER_FREQ 29000 >> is this still necessary? Weijie implemented a custom CPU clock >> handling which supports >> dynamic timer clocks. > This is referenced in arch/mips/cpu/time.c > I don't know if it's still relevant, but removing it doesn't seem > task for this patch. > > >>> + >>> +/* RAM */ >>> +#define CONFIG_SYS_SDRAM_BASE 0x8000 >>> + >>> +#define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE + 0x10 >>> + >>> +#define CONFIG_SYS_INIT_SP_OFFSET 0x40 >>> + >>> +/* SPL */ >>> +#if defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD) >>> +#define CONFIG_SKIP_LOWLEVEL_INIT >>> +#endif >> CONFIG_SPL_BUILD is only relevant in Makefiles and shouldn't be used >> in config header files > Removed, apparently without adverse consequences. Appearence was misguiding. Any change to this guard leads to code unable to boot from SPI NOR. I'll have to leave it is as-is. Someone more knowledgeable than me will have to understand why they are needed and how to remove them, if that's a requirement. After all the other boards with this SoC use the same code. >>> + >>> +#define CONFIG_SYS_UBOOT_START CONFIG_SYS_TEXT_BASE >>> +#define CONFIG_SPL_BSS_START_ADDR 0x8001 >>> +#define CONFIG_SPL_BSS_MAX_SIZE0x1 >>> +#define CONFIG_SPL_MAX_SIZE0x1 >>> + >>> +/* Dummy value */ >>> +#define CONFIG_SYS_UBOOT_BASE 0 >> where is that needed? > This is referenced in common/spl/spl_nor.c > I don't know if it's still relevant, but removing it doesn't seem > task for this patch. > >>> ==8<--- >>> > I'll wait for input before submitting another iteration. > > Thanks a lot > Mauro
Re: [RFC 2/2] Revert "dm: core: device: switch off power domain after device removal"
On Fri, 14 Feb 2020 09:50:54 +0530
Lokesh Vutla lokeshvu...@ti.com wrote:
> On 13/02/20 10:42 PM, Neil Armstrong wrote:
> > Hi,
> >
> > On 03/02/2020 14:59, Oliver Graute wrote:
> >> The conga-imx8 board isn't booting without this revert. Can someone tell me
> >> what I need to Do so that this revert is not necessary?
>
> Can you give more details on where the failure is happening?(logs would really
> help).
>
> >>
> >> This reverts commit 52edfed65de967a86983a55c51ba0727090efc43.
> >> ---
> >> drivers/core/device-remove.c | 5 -
> >> 1 file changed, 5 deletions(-)
> >>
> >> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
> >> index 5c8dc4ad70..586fadee0a 100644
> >> --- a/drivers/core/device-remove.c
> >> +++ b/drivers/core/device-remove.c
> >> @@ -16,7 +16,6 @@
> >> #include
> >> #include
> >> #include
> >> -#include
> >>
> >> int device_chld_unbind(struct udevice *dev, struct driver *drv)
> >> {
> >> @@ -193,10 +192,6 @@ int device_remove(struct udevice *dev, uint flags)
> >>}
> >>}
> >>
> >> - if (!(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF) &&
> >> - (dev != gd->cur_serial_dev))
> >> - dev_power_domain_off(dev);
> >> -
> >>if (flags_remove(flags, drv->flags)) {
> >>device_free(dev);
> >>
> >>
> >
> > It also breaks amlogic boards with video, since we can't tell we want
> > to keep the power domains up after boot, it cuts the power domains and
> > thus defeats all the goal of u-boot video..
> > The problem is DM_FLAG_DEFAULT_PD_CTRL_OFF disables auto power domain on
> > aswell, reverting to manual power domain enable.
>
> This doesn't mean U-boot must leave the all power-domains un handled before
> jumping to kernel. Please use DM_FLAG_DEFAULT_PD_CTRL_OFF in you driver and
> enable power_domain in your probe.
No, DM_FLAG_DEFAULT_PD_CTRL_OFF is only for very special cases where
manual power domain handling is required.
> Your case is exactly the reason why
> DM_FLAG_DEFAULT_PD_CTRL_OFF is introduced.
No. For this case the flag DM_FLAG_REMOVE_WITH_PD_ON has been introduced
in my v3 patch, but it was dropped in the merged patch. I've submitted a
new patch for this: http://patchwork.ozlabs.org/patch/1239143
--
Anatolij
[PATCH 1/1] dm: pinctrl: include linux/errno.h in pinctrl.h
Otherwise the compilation fails with PINCTRL_GENERIC=n : In file included from drivers/pinctrl/nxp/pinctrl-imx8m.c:7:0: include/dm/pinctrl.h: In function ‘pinctrl_generic_set_state’: include/dm/pinctrl.h:319:10: error: ‘EINVAL’ undeclared (first use in this function) return -EINVAL; ^~ include/dm/pinctrl.h:319:10: note: each undeclared identifier is reported only once for each function it appears in Signed-off-by: Sébastien Szymanski --- include/dm/pinctrl.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/dm/pinctrl.h b/include/dm/pinctrl.h index 692e5fc8cb..2012bb941e 100644 --- a/include/dm/pinctrl.h +++ b/include/dm/pinctrl.h @@ -6,6 +6,8 @@ #ifndef __PINCTRL_H #define __PINCTRL_H +#include + #define PINNAME_SIZE 10 #define PINMUX_SIZE40 -- 2.24.1
Re: RPI4: fail too boot with an initrd
On 17/02/2020 13:53, LABBE Corentin wrote:
> On Mon, Feb 17, 2020 at 11:50:04AM +0100, Matthias Brugger wrote:
>>
>>
>> On 17/02/2020 11:37, LABBE Corentin wrote:
>>> On Fri, Feb 14, 2020 at 06:15:27PM +, James Morse wrote:
Hi Corentin,
On 14/02/2020 13:27, LABBE Corentin wrote:
> Since the inclusion of the "enable network support in RPi4 config" serie
> on uboot, I
> have started to work on adding the rpi4 in kernelCI.
> But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp.
>
> Using booti I hit:
> [0.00] Linux version 5.6.0-rc1-next-20200212
> (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213
> [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4]
> (LinaroGCC 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020
> [0.00] Machine model: Raspberry Pi 4 Model B
> [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
> [0.00] printk: bootconsole [uart0] enabled
> [0.00] efi: Getting EFI parameters from FDT:
> [0.00] efi: UEFI not found.
So no EFI,
> [0.00] OF: reserved mem: failed to allocate memory for node
> 'linux,cma'
Out of memory.
> [0.00] cma: Failed to reserve 32 MiB
> [0.00] Kernel panic - not syncing: Failed to allocate page table
> page
Out of memory...
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
> 5.6.0-rc1-next-20200212 #66
> [0.00] Hardware name: Raspberry Pi 4 Model B (DT)
> [0.00] Call trace:
> [0.00] dump_backtrace+0x0/0x1a0
> [0.00] show_stack+0x14/0x20
> [0.00] dump_stack+0xbc/0x104
> [0.00] panic+0x16c/0x37c
> [0.00] early_pgtable_alloc+0x30/0xa0
... really early!
> [0.00] __create_pgd_mapping+0x36c/0x588
> [0.00] map_kernel_segment+0x70/0xa4
> [0.00] paging_init+0xf4/0x528
> [0.00] setup_arch+0x250/0x5d8
> [0.00] start_kernel+0x90/0x6d8
>
>
> Since the same kernel boot with bootefi and that bootefi lack ramdisk
> address,
Booting with EFI will cause linux to use the EFI memory map.
Does your DT have a memory node? (or does it expect EFI to provide the
information)
> I tried to add the address in the dtb via:
> fdt addr 0x0240; fdt resize; fdt set /chosen linux,initrd-start
> 0x0270; fdt set /chosen linux,initrd-end 0x1000; bootefi
> 0x0008 0x0240
> But with that, I get:
> initrd not fully accessible via the linear mapping -- please check your
> bootloader ...
So this one is an EFI boot, but you can't find where to put the initramfs
such that the
kernel agrees its in memory.
If you boot with 'efi=debug', linux will print the EFI memory map. Could
you compare that
to where U-Boot thinks memory is?
(it sounds like your DT memory node is missing, and your EFI memory map is
surprisingly small)
>>>
>>> Hello
>>>
>>> Thanks for your advices.
>>>
>>> In the dtb of mainline linux:
>>> /* Will be filled by the bootloader */
>>> memory@0 {
>>> device_type = "memory";
>>> reg = <0 0 0>;
>>> };
>>>
>>> In uboot I have:
>>> static struct mm_region bcm2711_mem_map[] = {
>>> {
>>> .virt = 0xUL,
>>> .phys = 0xUL,
>>> .size = 0xfe00UL,
>>> .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>>> PTE_BLOCK_INNER_SHARE
>>> }, {
>>> .virt = 0xfc00UL,
>>> .phys = 0xfc00UL,
>>> .size = 0x0380UL,
>>> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>>> PTE_BLOCK_NON_SHARE |
>>> PTE_BLOCK_PXN | PTE_BLOCK_UXN
>>> }, {
>>> /* List terminator */
>>> 0,
>>> }
>>> };
>>> But I dont know if uboot use that for filling the memory node.
>>
>> No it doesn't. U-Boot uses the DT from the firmware and passes this to the
>> kernel. But it seems you pass instead your own device-tree to the kernel, so
>> you
>> will need to update the memory node to show the available memory on you
>> board.
>>
>
> I dont understand, in the Linux commit "ARM: dts: Add minimal Raspberry Pi 4
> support" I read:
> The RPi 4 is available in 3 different variants (1, 2 and 4 GB RAM), so leave
> the memory size to zero and let the bootloader take care of it.
> But if uboot dont fill that...
> So the DTB in mainline is wrong, right ?
>
How do you pass your DTB to the kernel? Does the FW uses your DTB by putting it
as bcm2711-rpi-4-b.dtb in the first FAT partition? Or do you load it from U-Boot
Re: [RFC 2/2] Revert "dm: core: device: switch off power domain after device removal"
On Thu, 13 Feb 2020 18:12:12 +0100
Neil Armstrong narmstr...@baylibre.com wrote:
> Hi,
>
> On 03/02/2020 14:59, Oliver Graute wrote:
> > The conga-imx8 board isn't booting without this revert. Can someone tell me
> > what I need to Do so that this revert is not necessary?
> >
> > This reverts commit 52edfed65de967a86983a55c51ba0727090efc43.
> > ---
> > drivers/core/device-remove.c | 5 -
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
> > index 5c8dc4ad70..586fadee0a 100644
> > --- a/drivers/core/device-remove.c
> > +++ b/drivers/core/device-remove.c
> > @@ -16,7 +16,6 @@
> > #include
> > #include
> > #include
> > -#include
> >
> > int device_chld_unbind(struct udevice *dev, struct driver *drv)
> > {
> > @@ -193,10 +192,6 @@ int device_remove(struct udevice *dev, uint flags)
> > }
> > }
> >
> > - if (!(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF) &&
> > - (dev != gd->cur_serial_dev))
> > - dev_power_domain_off(dev);
> > -
> > if (flags_remove(flags, drv->flags)) {
> > device_free(dev);
> >
> >
>
> It also breaks amlogic boards with video, since we can't tell we want
> to keep the power domains up after boot, it cuts the power domains and
> thus defeats all the goal of u-boot video...
>
> The problem is DM_FLAG_DEFAULT_PD_CTRL_OFF disables auto power domain on
> aswell, reverting to manual power domain enable.
Yes, in some special cases manual power domain enable is required,
this is the reason why this flag has been introduced. This flag is
not for controlling power off for auto-enabled domains.
My original patch v3 [1] suggested another flag DM_FLAG_REMOVE_WITH_PD_ON,
but in the subsequent patch (which was then merged) Lokesh replaced this
with another flag DM_FLAG_DEFAULT_PD_CTRL_OFF for different purpose and
dropped DM_FLAG_REMOVE_WITH_PD_ON.
Unfortunately Lokesh copied the commit message from my patch v3 to
the updated patch without modification and so this merged commit doesn't
correctly describe the code changes. Unfortunately I didn't have
time to properly review and test this merged patch back then.
[1] https://patchwork.ozlabs.org/patch/1140138
--
Anatolij
Re: RPI4: fail too boot with an initrd
On Mon, Feb 17, 2020 at 11:50:04AM +0100, Matthias Brugger wrote:
>
>
> On 17/02/2020 11:37, LABBE Corentin wrote:
> > On Fri, Feb 14, 2020 at 06:15:27PM +, James Morse wrote:
> >> Hi Corentin,
> >>
> >> On 14/02/2020 13:27, LABBE Corentin wrote:
> >>> Since the inclusion of the "enable network support in RPi4 config" serie
> >>> on uboot, I
> >>> have started to work on adding the rpi4 in kernelCI.
> >>> But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp.
> >>>
> >>> Using booti I hit:
> >>> [0.00] Linux version 5.6.0-rc1-next-20200212
> >>> (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213
> >>> [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4]
> >>> (LinaroGCC 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020
> >>> [0.00] Machine model: Raspberry Pi 4 Model B
> >>> [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
> >>> [0.00] printk: bootconsole [uart0] enabled
> >>> [0.00] efi: Getting EFI parameters from FDT:
> >>> [0.00] efi: UEFI not found.
> >>
> >> So no EFI,
> >>
> >>> [0.00] OF: reserved mem: failed to allocate memory for node
> >>> 'linux,cma'
> >>
> >> Out of memory.
> >>
> >>> [0.00] cma: Failed to reserve 32 MiB
> >>> [0.00] Kernel panic - not syncing: Failed to allocate page table
> >>> page
> >>
> >> Out of memory...
> >>
> >>> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
> >>> 5.6.0-rc1-next-20200212 #66
> >>> [0.00] Hardware name: Raspberry Pi 4 Model B (DT)
> >>> [0.00] Call trace:
> >>> [0.00] dump_backtrace+0x0/0x1a0
> >>> [0.00] show_stack+0x14/0x20
> >>> [0.00] dump_stack+0xbc/0x104
> >>> [0.00] panic+0x16c/0x37c
> >>> [0.00] early_pgtable_alloc+0x30/0xa0
> >>
> >> ... really early!
> >>
> >>> [0.00] __create_pgd_mapping+0x36c/0x588
> >>> [0.00] map_kernel_segment+0x70/0xa4
> >>> [0.00] paging_init+0xf4/0x528
> >>> [0.00] setup_arch+0x250/0x5d8
> >>> [0.00] start_kernel+0x90/0x6d8
> >>>
> >>>
> >>> Since the same kernel boot with bootefi and that bootefi lack ramdisk
> >>> address,
> >>
> >> Booting with EFI will cause linux to use the EFI memory map.
> >>
> >> Does your DT have a memory node? (or does it expect EFI to provide the
> >> information)
> >>
> >>
> >>> I tried to add the address in the dtb via:
> >>> fdt addr 0x0240; fdt resize; fdt set /chosen linux,initrd-start
> >>> 0x0270; fdt set /chosen linux,initrd-end 0x1000; bootefi
> >>> 0x0008 0x0240
> >>> But with that, I get:
> >>> initrd not fully accessible via the linear mapping -- please check your
> >>> bootloader ...
> >>
> >> So this one is an EFI boot, but you can't find where to put the initramfs
> >> such that the
> >> kernel agrees its in memory.
> >>
> >> If you boot with 'efi=debug', linux will print the EFI memory map. Could
> >> you compare that
> >> to where U-Boot thinks memory is?
> >>
> >> (it sounds like your DT memory node is missing, and your EFI memory map is
> >> surprisingly small)
> >
> > Hello
> >
> > Thanks for your advices.
> >
> > In the dtb of mainline linux:
> > /* Will be filled by the bootloader */
> > memory@0 {
> > device_type = "memory";
> > reg = <0 0 0>;
> > };
> >
> > In uboot I have:
> > static struct mm_region bcm2711_mem_map[] = {
> > {
> > .virt = 0xUL,
> > .phys = 0xUL,
> > .size = 0xfe00UL,
> > .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> > PTE_BLOCK_INNER_SHARE
> > }, {
> > .virt = 0xfc00UL,
> > .phys = 0xfc00UL,
> > .size = 0x0380UL,
> > .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> > PTE_BLOCK_NON_SHARE |
> > PTE_BLOCK_PXN | PTE_BLOCK_UXN
> > }, {
> > /* List terminator */
> > 0,
> > }
> > };
> > But I dont know if uboot use that for filling the memory node.
>
> No it doesn't. U-Boot uses the DT from the firmware and passes this to the
> kernel. But it seems you pass instead your own device-tree to the kernel, so
> you
> will need to update the memory node to show the available memory on you board.
>
I dont understand, in the Linux commit "ARM: dts: Add minimal Raspberry Pi 4
support" I read:
The RPi 4 is available in 3 different variants (1, 2 and 4 GB RAM), so leave
the memory size to zero and let the bootloader take care of it.
But if uboot dont fill that...
So the DTB in mainline is wrong, right ?
Regards
Re: [PATCH v2 10/13] arm: dts: am335x: add 'u-boot,dm-pre-reloc' to panel
> Il 17 febbraio 2020 alle 11.56 Felix Brack ha scritto:
>
>
>
>
> On 16.02.20 16:09, Dario Binacchi wrote:
> > Add the "u-boot,dm-pre-reloc" property to the "ti,tilcdc,panel"
> > compatible node. In this way the video-uclass module can allocate the
> > amount of memory needed to be assigned to the frame buffer.
> > In the case of the boards that support Linux, the addition of the
> > property in the *-u-boot.dtsi file still required changing its dts
> > file adding a label to the panel node in order to be referenced.
> >
> > Signed-off-by: Dario Binacchi
> >
> >
> > - Change subject line in: arm: dts: am335x:
> > - Move 'u-boot,dm-pre-reloc' property in *-u-boot.dtsi files for
> >boards tha support Linux
> > - Ran building tests with CONFIG_AM335X_LCD enabled and disabled for
> >following configurations:
> > - brxre1_defconfig --> success
> > - am335x_guardian_defconfig --> success
> > - am335x_evm_defconfig --> success
> > - da850evm_defconfig --> failure with CONFIG_AM335X_LCD enabled
> >
> >Enabling CONFIG_AM335X_LCD causes building errors even without applying
> >the patch. The driver has never been enabled on the da850 and must be
> >adapted for this platform.
> >
> > ---
> >
> > Changes in v2: None
> >
> > arch/arm/dts/am335x-brppt1-mmc.dts | 2 ++
> > arch/arm/dts/am335x-brppt1-nand.dts | 2 ++
> > arch/arm/dts/am335x-brppt1-spi.dts | 2 ++
> > arch/arm/dts/am335x-brsmarc1.dts | 1 +
> > arch/arm/dts/am335x-brxre1.dts | 2 ++
> > arch/arm/dts/am335x-evm-u-boot.dtsi | 4
> > arch/arm/dts/am335x-evm.dts | 2 +-
> > arch/arm/dts/am335x-evmsk-u-boot.dtsi| 10 ++
> > arch/arm/dts/am335x-evmsk.dts| 2 +-
> > arch/arm/dts/am335x-guardian-u-boot.dtsi | 4
> > arch/arm/dts/am335x-guardian.dts | 2 +-
> > arch/arm/dts/am335x-pdu001-u-boot.dtsi | 4
> > arch/arm/dts/am335x-pdu001.dts | 2 +-
> > arch/arm/dts/am335x-pxm50-u-boot.dtsi| 10 ++
> > arch/arm/dts/am335x-pxm50.dts| 2 +-
> > arch/arm/dts/am335x-rut-u-boot.dtsi | 10 ++
> > arch/arm/dts/am335x-rut.dts | 2 +-
> > arch/arm/dts/da850-evm-u-boot.dtsi | 4
> > arch/arm/dts/da850-evm.dts | 2 +-
> > 19 files changed, 62 insertions(+), 7 deletions(-)
> > create mode 100644 arch/arm/dts/am335x-evmsk-u-boot.dtsi
> > create mode 100644 arch/arm/dts/am335x-pxm50-u-boot.dtsi
> > create mode 100644 arch/arm/dts/am335x-rut-u-boot.dtsi
> >
> > diff --git a/arch/arm/dts/am335x-brppt1-mmc.dts
> > b/arch/arm/dts/am335x-brppt1-mmc.dts
> > index 9be34d9da0..6f919711f0 100644
> > --- a/arch/arm/dts/am335x-brppt1-mmc.dts
> > +++ b/arch/arm/dts/am335x-brppt1-mmc.dts
> > @@ -53,6 +53,8 @@
> > bkl-pwm = <>;
> > bkl-tps = <_bl>;
> >
> > + u-boot,dm-pre-reloc;
> > +
> > panel-info {
> > ac-bias = <255>;
> > ac-bias-intrpt = <0>;
> > diff --git a/arch/arm/dts/am335x-brppt1-nand.dts
> > b/arch/arm/dts/am335x-brppt1-nand.dts
> > index 11bd5c551c..9d4340f591 100644
> > --- a/arch/arm/dts/am335x-brppt1-nand.dts
> > +++ b/arch/arm/dts/am335x-brppt1-nand.dts
> > @@ -53,6 +53,8 @@
> > bkl-pwm = <>;
> > bkl-tps = <_bl>;
> >
> > + u-boot,dm-pre-reloc;
> > +
> > panel-info {
> > ac-bias = <255>;
> > ac-bias-intrpt = <0>;
> > diff --git a/arch/arm/dts/am335x-brppt1-spi.dts
> > b/arch/arm/dts/am335x-brppt1-spi.dts
> > index 01ab74be5e..c078af8fba 100644
> > --- a/arch/arm/dts/am335x-brppt1-spi.dts
> > +++ b/arch/arm/dts/am335x-brppt1-spi.dts
> > @@ -54,6 +54,8 @@
> > bkl-pwm = <>;
> > bkl-tps = <_bl>;
> >
> > + u-boot,dm-pre-reloc;
> > +
> > panel-info {
> > ac-bias = <255>;
> > ac-bias-intrpt = <0>;
> > diff --git a/arch/arm/dts/am335x-brsmarc1.dts
> > b/arch/arm/dts/am335x-brsmarc1.dts
> > index a63fc2da22..7e9516e8f8 100644
> > --- a/arch/arm/dts/am335x-brsmarc1.dts
> > +++ b/arch/arm/dts/am335x-brsmarc1.dts
> > @@ -59,6 +59,7 @@
> > /*backlight = <_bl>; */
> > compatible = "ti,tilcdc,panel";
> > status = "okay";
> > + u-boot,dm-pre-reloc;
> >
> > panel-info {
> > ac-bias = <255>;
> > diff --git a/arch/arm/dts/am335x-brxre1.dts b/arch/arm/dts/am335x-brxre1.dts
> > index 33d8ab78d8..6091a12fb7 100644
> > --- a/arch/arm/dts/am335x-brxre1.dts
> > +++ b/arch/arm/dts/am335x-brxre1.dts
> > @@ -79,6 +79,8 @@
> >
> > backlight = <_bl>;
> >
> > + u-boot,dm-pre-reloc;
> > +
> > panel-info {
> > ac-bias = <255>;
> > ac-bias-intrpt = <0>;
> > diff --git
Re: [PATCH v2 04/10] mmc: sdhci: Expose sdhci_init() as non-static
Jaehoon,
On 17/02/20 5:47 pm, Jaehoon Chung wrote:
> Hi,
>
> On 2/5/20 4:33 PM, Faiz Abbas wrote:
>> Hi Peng,
>>
>> On 05/02/20 12:58 pm, Peng Fan wrote:
Subject: Re: [PATCH v2 04/10] mmc: sdhci: Expose sdhci_init() as non-static
Hi,
On 31/01/20 3:55 am, Simon Goldschmidt wrote:
> Am 30.01.2020 um 23:21 schrieb Jaehoon Chung:
>> Hi Simon,
>>
>> On 1/29/20 11:16 PM, Simon Goldschmidt wrote:
>>> On Wed, Jan 29, 2020 at 12:00 AM Jaehoon Chung
>>> wrote:
On 1/24/20 8:52 PM, Faiz Abbas wrote:
> Expose sdhci_init() as non-static.
Does it need to change to non-static?
>>>
>>> And even if it needs to, can we have a reason *why* in the commit
>>> message?
>>
>> When i read entire your series, it seems that doesn't need to change
>> to non-static.
>> All of change that touched MMC code are only for your board.
>> I don't know Peng's opinion, but it's not my prefer.
>
> +1!
>
> We need to keep the core code clean of such hacks in order to keep the
> size small for constrained targets!
>
Peng can you comment on this?
>>>
>>> Just one more question, does kernel has same issue, how resolved?
>>> Could U-Boot follow similar approach?
>>
>> Kernel has interrupts enabled. So software just has to wait for the card
>> detect interrupt to arrive rather than poll on anything.
>>
>>>
>>> Actually I am fine with platform specific approach , considering
>>> your platform issue.
>>>
>>> But since Simon and Jaehoon has concerns, not sure whether
>>> Simon and Jaehoon have good ideas.
>>>
>>
>> Ok. Lets see if they have some better ideas.
>
> Well, Your code needs to call am654_sdhci_init() before sdhci_init(), right?
>
> ops->init() -> am654_sdhci_init -> sdhci_init().
> If am654_sdhci_init is called for preset, how about adding pre_init() or
> other ops callback.
> (pre_init is just example.)
>
> ops->pre_init = am654_sdhci_init; or ops->preset = am654_sdhci_preset;
>
> In mmc.
>
> ops->preset or ops->pre_init -> ops->init
>
> How about adding plotform specific init callback? Then someone can also use
> it for platform specific things in future.
>
So we basically want an init() callback even in sdhci.c.
I have to create one more wrapper sdhci_pltaform_init() API in the sdhci
driver that just calls a platform init function inside it. So its
include/sdhci.h:
struct sdhci_ops {
..
+ int (*platform_init)()
and then drivers/mmc/sdhci.c:
+sdhci_platform_init()
+{
+...
+ host->ops->platform_init();
+}
const struct dm_mmc_ops sdhci_ops = {
...
+ .init = sdhci_platform_init,
};
Right?
Thanks,
Faiz
Re: use invd instead of wbinvd in real mode start code
On Mon, Feb 17, 2020 at 2:31 PM Andy Shevchenko wrote: > > -- Forwarded message - > From: Andy Shevchenko > Date: Mon, Feb 17, 2020 at 2:31 PM > Subject: use invd instead of wbinvd in real mode start code > To: Masahiro Yamada , Simon Glass > , Bin Meng > > > Hi! > > It seems Masahiro's patches (don't know yet which one out of two, > probably invd one) broke the boot on Intel Edison. Before patches: ... DRAM: 980.6 MiB WDT: Started with servicing (60s timeout) MMC: mmc@ff3fc000: 0, mmc@ff3fa000: 1 Loading Environment from MMC... OK In:serial Out: serial Err: serial Saving Environment to MMC... Writing to redundant MMC(0)... OK Saving Environment to MMC... Writing to MMC(0)... OK Net: No ethernet found. Hit any key to stop autoboot: 0 After them (v2020.04-rc2): ... DRAM: sfi: failed to locate SYST table sfi: failed to locate SYST table 16 EiB > > Reverting (both for now) helps. > > Please, revert or fix ASAP before v2020.04 release! > > P.S. I dunno how it has been tested, so, if you have Intel Edison in > possession, please, don't forget to test on it. It's not first time > the Intel Edison behaviour is broken due to poor testing. > > -- > With Best Regards, > Andy Shevchenko > > > -- > With Best Regards, > Andy Shevchenko -- With Best Regards, Andy Shevchenko
Fwd: use invd instead of wbinvd in real mode start code
-- Forwarded message - From: Andy Shevchenko Date: Mon, Feb 17, 2020 at 2:31 PM Subject: use invd instead of wbinvd in real mode start code To: Masahiro Yamada , Simon Glass , Bin Meng Hi! It seems Masahiro's patches (don't know yet which one out of two, probably invd one) broke the boot on Intel Edison. Reverting (both for now) helps. Please, revert or fix ASAP before v2020.04 release! P.S. I dunno how it has been tested, so, if you have Intel Edison in possession, please, don't forget to test on it. It's not first time the Intel Edison behaviour is broken due to poor testing. -- With Best Regards, Andy Shevchenko -- With Best Regards, Andy Shevchenko
Re: [PATCH v2 04/10] mmc: sdhci: Expose sdhci_init() as non-static
Hi, On 2/5/20 4:33 PM, Faiz Abbas wrote: > Hi Peng, > > On 05/02/20 12:58 pm, Peng Fan wrote: >>> Subject: Re: [PATCH v2 04/10] mmc: sdhci: Expose sdhci_init() as non-static >>> >>> Hi, >>> >>> On 31/01/20 3:55 am, Simon Goldschmidt wrote: Am 30.01.2020 um 23:21 schrieb Jaehoon Chung: > Hi Simon, > > On 1/29/20 11:16 PM, Simon Goldschmidt wrote: >> On Wed, Jan 29, 2020 at 12:00 AM Jaehoon Chung >> wrote: >>> >>> On 1/24/20 8:52 PM, Faiz Abbas wrote: Expose sdhci_init() as non-static. >>> >>> Does it need to change to non-static? >> >> And even if it needs to, can we have a reason *why* in the commit >> message? > > When i read entire your series, it seems that doesn't need to change > to non-static. > All of change that touched MMC code are only for your board. > I don't know Peng's opinion, but it's not my prefer. +1! We need to keep the core code clean of such hacks in order to keep the size small for constrained targets! >>> >>> Peng can you comment on this? >> >> Just one more question, does kernel has same issue, how resolved? >> Could U-Boot follow similar approach? > > Kernel has interrupts enabled. So software just has to wait for the card > detect interrupt to arrive rather than poll on anything. > >> >> Actually I am fine with platform specific approach , considering >> your platform issue. >> >> But since Simon and Jaehoon has concerns, not sure whether >> Simon and Jaehoon have good ideas. >> > > Ok. Lets see if they have some better ideas. Well, Your code needs to call am654_sdhci_init() before sdhci_init(), right? ops->init() -> am654_sdhci_init -> sdhci_init(). If am654_sdhci_init is called for preset, how about adding pre_init() or other ops callback. (pre_init is just example.) ops->pre_init = am654_sdhci_init; or ops->preset = am654_sdhci_preset; In mmc. ops->preset or ops->pre_init -> ops->init How about adding plotform specific init callback? Then someone can also use it for platform specific things in future. Best Regards, Jaehoon Chung > > Thanks, > Faiz > > >
Re: [PATCH] Revert "dm: core: device: switch off power domain after device removal"
On Mon, 17 Feb 2020 10:10:36 +0100 Neil Armstrong narmstr...@baylibre.com wrote: > This commit breaks Linux boot on Amlogic libretech-cc, libretech-ac, sei510, > sei610 board by automatically disabling the power domain after device removal. > This because the power domain associated to the video driver must be kept > enabled for linux to boot. > > The only way is to use the introduced flag DM_FLAG_DEFAULT_PD_CTRL_OFF, which > removes automatic handling of power domain. > This flag is not a complete solution since it will force reverting to manually > enable the power domain from the driver probe. > > Instead a flag to keep the power domain enabled after removal should be > introduced. > > In the meantime revert this commit until a proper solution is found. > > This reverts commit 52edfed65de967a86983a55c51ba0727090efc43. > > Signed-off-by: Neil Armstrong > --- > Hi Simon, Tom, > > This revert is the simplest fix to make the boards boot again on v2020.04, > the goal is to make this behavior happen again with a proper flag to keep the > power domain enabled on specific drivers. > > I can push it on my next PR on my branch, is it ok ? Please test if these two patches fix the problem: http://patchwork.ozlabs.org/patch/1239143 http://patchwork.ozlabs.org/patch/1239144 -- Anatolij
Antwort: Re: dm: core: Board failing to boot since commit 82de42fa1468 (parent data/probe)
Hi Bin, Simon,
-"Bin Meng" schrieb: -
> Hi Wolfgang,
>
> On Wed, Feb 12, 2020 at 1:14 AM Simon Glass wrote:
> >
> > +Bin
> >
> > Hi Wolfgang,
> >
> > On Tue, 11 Feb 2020 at 06:59, Wolfgang Wallner
> > wrote:
> > >
> > > Hello Simon,
> > >
> > > Since commit 82de42fa1468 ("dm: core: Allocate parent data separate from
> > > probing parent") I have trouble booting my board (a custom Apollo Lake
> > > design
> > > booted via Coreboot + U-Boot).
> > >
> > > I think this is because the function ns16550_serial_ofdata_to_platdata()
> > > of
> > > the UART driver noew tries to access the PCI bus before it is probed.
> > > I'm aware of the comment which you have added to pci-uclass.c [1].
> > >
> > > So the correct way to fix this would be to adapt the uart driver in
> > > ns16550.c?
> >
> > Why is the UART being used so early?
board_init_f() calls serial_init(), because it is part of init_sequence_f.
This leads to device_probe() being called for my UART.
The detailed call stack looks as follows:
FileFunction
-
board_f.c board_init_f()
serial-uclass.c serial_init()
serial_find_console_or_panic()
serial_check_stdout()
// stdout-path is set to serial0:115200n8
// serial0 is an alias for the device pciuart2,
// which is called uart@18,2 in my device tree
// This device is similar to what is called
// serial@18,2 in chromebook_coral.dts
uclass.cuclass_get_device_by_of_offset()
uclass_get_device_tail()
device.cdevice_probe()
// device_probe calls drv->ofdata_to_platdata(),
// which points to
// ns16550_serial_ofdata_to_platdata in my case
ns16550.c ns16550_serial_ofdata_to_platdata()
// This is where the PCI access to the
// uninitialized bus 'pci' happens
> > Also, if you are booting from
> > coreboot you really shouldn't need to auto-config PCI at all, so
> > perhaps just disable CONFIG_PCI_PNP?
CONFIG_PCI_PNP is already disabled in my configuration.
> > But I understand that that
> > changes the build.
> >
> > The way I fixed it is to allow the UART to stay at a fixed PCI address:
> >
> > 9e11293319 dm: pci: Allow disabling auto-config for a device
I think commit 9e11293319 would be a solution if the problem would be
CONFIG_PCI_PNP, but that is not the case here.
Just to be sure I have cherry-picked 9e11293319 and added "pci,no-autoconfig;"
to my UART, but that does not solve my issue.
> Please suggest whether I should get the above patch applied to fix the
> issue you saw on your board.
I think the issue I see is something different.
And I can't provide a proper review for commit 9e11293319 as I don't
know the PCI subsystem in U-Boot well enough.
> >
> > That's in u-boot-dm/coral-working
> >
> > >
> > > regards, Wolfgang
> > >
> > > Detail information:
> > >
> > > As far as I understand the situation the following things happen:
> > > * My debug UART is probed
> > > * This triggers a call to ns16550_serial_ofdata_to_platdata()
> > > * This function tries to read BAR0 from the PCI devices
> > > * Reading BAR0 returns 0x, as the PCI bus has not been probed yet
> > > * The serial driver tries to read from a non-existing register based on
> > > this
> > >invalid BAR0 value and hangs indefinitely.
> > >
> > > This is confirmed by the warning which you have introduced a few commits
> > > ealier
> > > in commit 4886287ee4f9 ("pci: Print a warning if the bus is accessed
> > > before
> > > probing"):
> > >
> > > "dm_pci_get_bdf() PCI: Device 'uart@18,2' on unprobed bus 'pci'"
> > >
> > > [1] "A common cause of this problem is that this function is called in the
> > > ofdata_to_platdata() method of @dev. Accessing the PCI bus in that
> > > method is not allowed, since it has not yet been probed. To fix this,
> > > move that access to the probe() method of @dev instead."
>
> Regards,
> Bin
regards, Wolfgang
[PATCH 1/2] dm: core: Add a flag for power domain control on device removal
In various cases a power domain must stay enabled after device
removal when booting OS (i.e. serial debug console or display).
Add a flag to selectively skip switching off a power domain.
Fixes: 52edfed65de9 ("dm: core: device: switch off power domain after device
removal")
Signed-off-by: Anatolij Gustschin
---
drivers/core/device-remove.c | 5 +++--
include/dm/device.h | 6 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
index 444e34b492..ff5b28cb6a 100644
--- a/drivers/core/device-remove.c
+++ b/drivers/core/device-remove.c
@@ -194,8 +194,9 @@ int device_remove(struct udevice *dev, uint flags)
}
}
- if (!(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF) &&
- (dev != gd->cur_serial_dev))
+ if (!(drv->flags &
+ (DM_FLAG_DEFAULT_PD_CTRL_OFF | DM_FLAG_REMOVE_WITH_PD_ON)) &&
+ dev != gd->cur_serial_dev)
dev_power_domain_off(dev);
if (flags_remove(flags, drv->flags)) {
diff --git a/include/dm/device.h b/include/dm/device.h
index ab806d0b7e..a56164b19b 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -67,6 +67,12 @@ struct driver_info;
/* Driver platdata has been read. Cleared when the device is removed */
#define DM_FLAG_PLATDATA_VALID (1 << 12)
+/*
+ * Device is removed without switching off its power domain. This might
+ * be required, i. e. for serial console (debug) output when booting OS.
+ */
+#define DM_FLAG_REMOVE_WITH_PD_ON (1 << 13)
+
/*
* One or multiple of these flags are passed to device_remove() so that
* a selective device removal as specified by the remove-stage and the
--
2.17.1
[PATCH 2/2] video: meson: keep power domain up after booting
Add driver flag to skip power domain disabling on device removal.
Fixes: 52edfed65de9 ("dm: core: device: switch off power domain after device
removal")
Signed-off-by: Anatolij Gustschin
---
drivers/video/meson/meson_vpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/meson/meson_vpu.c b/drivers/video/meson/meson_vpu.c
index 4eb66398d0..aa8c0a962f 100644
--- a/drivers/video/meson/meson_vpu.c
+++ b/drivers/video/meson/meson_vpu.c
@@ -210,5 +210,5 @@ U_BOOT_DRIVER(meson_vpu) = {
.probe = meson_vpu_probe,
.bind = meson_vpu_bind,
.priv_auto_alloc_size = sizeof(struct meson_vpu_priv),
- .flags = DM_FLAG_PRE_RELOC,
+ .flags = DM_FLAG_PRE_RELOC | DM_FLAG_REMOVE_WITH_PD_ON,
};
--
2.17.1
Re: [PATCH v3 0/3] Ethernet support for Raspberry Pi 4
On 2/3/20 6:48 PM, LABBE Corentin wrote: > On Wed, Jan 29, 2020 at 07:21:09AM +0900, Jaehoon Chung wrote: >> On 1/27/20 9:06 PM, Andre Przywara wrote: >>> On Mon, 27 Jan 2020 12:50:16 +0100 >>> LABBE Corentin wrote: >>> >>> Hi, >>> On Mon, Jan 27, 2020 at 04:27:03PM +0530, Amit Tomer wrote: > Hi, > >> The kernel panic just after with "OF: reserved mem: failed to allocate >> memory for node 'linux,cma'" but that's another story. > > But this comes even without having Ethernet patches and when one use > booti instead of bootefi, right ? > So booti is unsupported on rpi 4 ? >>> >>> It should be supported, but apparently there is some bug. I guess it's >>> about not properly reserving memory used by the armstub/ATF. Do you use the >>> embedded RPi foundation armstub or ATF (do you have an "armstub=..." line >>> in config.txt)? >>> >>> I will try take a look at this later. >> >> I'm not sure, i had similar issue about failed to allocate memory cma. >> I had enabled CONFIG_ARCH_FIXUP_OF_MEMORY. And i changed the loading address >> (kernel/ramdisk/device-tree) in boot script for our environment. >> Because sometime some address range is overwritten. >> > > Hello > > I have searched both in uboot and linux sources and didnt found any > CONFIG_ARCH_FIXUP_OF_MEMORY. Sorry. It's CONFIG_ARCH_FIXUP_FDT_MEMORY. Best Regards, Jaehoon Chung > Could you give what you did exactly ? > > Regards > >
Re: [OE-core] [yocto] Support UBI u-boot
Hi JH, On Sun, Feb 09, 2020 at 08:01:15PM +1100, JH wrote: > Changed to https://source.codeaurora.org/external/imx/uboot-imx.git > branch imx_v2018.03_4.14.98_2.0.0_ga, it can now support > CONFIG_CMD_MTDPARTS ind defconfg, all MTDPARTS error gone, but then > 2018.03-r0/git/cmd/ubi.c missed dependencies of del_mtd_partitions, > add_mtd_partitions, mtd_get_device_size all in mtdpart.c which can > only be enabled by CONFIG_MTD_PARTITIONS: > > obj-$(CONFIG_MTD_PARTITIONS) += mtdpart.o > > But that CONFIG_MTD_PARTITIONS is not supported in defconfig. > > Could anyone advise which branch works for UBI? > FYI, U-boot was still slowly migrating to Kconfig only back then (maybe still is). There was for a long time a mix between Kconfig options and options in what I call board header files (include/configs/.h). Most likely CONFIG_MTD_PARTITIONS had to be defined there. Biased recommendation: https://www.youtube.com/watch?v=5E0sdYkvq-Q BR, Quentin
[PATCH] arm64: zynqmp: Enable cache command for mini mtest configuration
Enable cache commands by default for mtest configuration. It is good to be able to enable/disable caches when you test memory. Signed-off-by: Michal Simek --- configs/xilinx_zynqmp_mini_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/xilinx_zynqmp_mini_defconfig b/configs/xilinx_zynqmp_mini_defconfig index d953c91a66ed..2d9a3b3a5f3a 100644 --- a/configs/xilinx_zynqmp_mini_defconfig +++ b/configs/xilinx_zynqmp_mini_defconfig @@ -40,6 +40,7 @@ CONFIG_SYS_ALT_MEMTEST=y # CONFIG_CMD_ITEST is not set # CONFIG_CMD_SOURCE is not set # CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_CACHE=y # CONFIG_CMD_MISC is not set # CONFIG_PARTITIONS is not set CONFIG_OF_EMBED=y -- 2.25.0
Re: [PATCH v2 10/13] arm: dts: am335x: add 'u-boot,dm-pre-reloc' to panel
On 16.02.20 16:09, Dario Binacchi wrote:
> Add the "u-boot,dm-pre-reloc" property to the "ti,tilcdc,panel"
> compatible node. In this way the video-uclass module can allocate the
> amount of memory needed to be assigned to the frame buffer.
> In the case of the boards that support Linux, the addition of the
> property in the *-u-boot.dtsi file still required changing its dts
> file adding a label to the panel node in order to be referenced.
>
> Signed-off-by: Dario Binacchi
>
>
> - Change subject line in: arm: dts: am335x:
> - Move 'u-boot,dm-pre-reloc' property in *-u-boot.dtsi files for
>boards tha support Linux
> - Ran building tests with CONFIG_AM335X_LCD enabled and disabled for
>following configurations:
> - brxre1_defconfig --> success
> - am335x_guardian_defconfig --> success
> - am335x_evm_defconfig --> success
> - da850evm_defconfig --> failure with CONFIG_AM335X_LCD enabled
>
>Enabling CONFIG_AM335X_LCD causes building errors even without applying
>the patch. The driver has never been enabled on the da850 and must be
>adapted for this platform.
>
> ---
>
> Changes in v2: None
>
> arch/arm/dts/am335x-brppt1-mmc.dts | 2 ++
> arch/arm/dts/am335x-brppt1-nand.dts | 2 ++
> arch/arm/dts/am335x-brppt1-spi.dts | 2 ++
> arch/arm/dts/am335x-brsmarc1.dts | 1 +
> arch/arm/dts/am335x-brxre1.dts | 2 ++
> arch/arm/dts/am335x-evm-u-boot.dtsi | 4
> arch/arm/dts/am335x-evm.dts | 2 +-
> arch/arm/dts/am335x-evmsk-u-boot.dtsi| 10 ++
> arch/arm/dts/am335x-evmsk.dts| 2 +-
> arch/arm/dts/am335x-guardian-u-boot.dtsi | 4
> arch/arm/dts/am335x-guardian.dts | 2 +-
> arch/arm/dts/am335x-pdu001-u-boot.dtsi | 4
> arch/arm/dts/am335x-pdu001.dts | 2 +-
> arch/arm/dts/am335x-pxm50-u-boot.dtsi| 10 ++
> arch/arm/dts/am335x-pxm50.dts| 2 +-
> arch/arm/dts/am335x-rut-u-boot.dtsi | 10 ++
> arch/arm/dts/am335x-rut.dts | 2 +-
> arch/arm/dts/da850-evm-u-boot.dtsi | 4
> arch/arm/dts/da850-evm.dts | 2 +-
> 19 files changed, 62 insertions(+), 7 deletions(-)
> create mode 100644 arch/arm/dts/am335x-evmsk-u-boot.dtsi
> create mode 100644 arch/arm/dts/am335x-pxm50-u-boot.dtsi
> create mode 100644 arch/arm/dts/am335x-rut-u-boot.dtsi
>
> diff --git a/arch/arm/dts/am335x-brppt1-mmc.dts
> b/arch/arm/dts/am335x-brppt1-mmc.dts
> index 9be34d9da0..6f919711f0 100644
> --- a/arch/arm/dts/am335x-brppt1-mmc.dts
> +++ b/arch/arm/dts/am335x-brppt1-mmc.dts
> @@ -53,6 +53,8 @@
> bkl-pwm = <>;
> bkl-tps = <_bl>;
>
> + u-boot,dm-pre-reloc;
> +
> panel-info {
> ac-bias = <255>;
> ac-bias-intrpt = <0>;
> diff --git a/arch/arm/dts/am335x-brppt1-nand.dts
> b/arch/arm/dts/am335x-brppt1-nand.dts
> index 11bd5c551c..9d4340f591 100644
> --- a/arch/arm/dts/am335x-brppt1-nand.dts
> +++ b/arch/arm/dts/am335x-brppt1-nand.dts
> @@ -53,6 +53,8 @@
> bkl-pwm = <>;
> bkl-tps = <_bl>;
>
> + u-boot,dm-pre-reloc;
> +
> panel-info {
> ac-bias = <255>;
> ac-bias-intrpt = <0>;
> diff --git a/arch/arm/dts/am335x-brppt1-spi.dts
> b/arch/arm/dts/am335x-brppt1-spi.dts
> index 01ab74be5e..c078af8fba 100644
> --- a/arch/arm/dts/am335x-brppt1-spi.dts
> +++ b/arch/arm/dts/am335x-brppt1-spi.dts
> @@ -54,6 +54,8 @@
> bkl-pwm = <>;
> bkl-tps = <_bl>;
>
> + u-boot,dm-pre-reloc;
> +
> panel-info {
> ac-bias = <255>;
> ac-bias-intrpt = <0>;
> diff --git a/arch/arm/dts/am335x-brsmarc1.dts
> b/arch/arm/dts/am335x-brsmarc1.dts
> index a63fc2da22..7e9516e8f8 100644
> --- a/arch/arm/dts/am335x-brsmarc1.dts
> +++ b/arch/arm/dts/am335x-brsmarc1.dts
> @@ -59,6 +59,7 @@
> /*backlight = <_bl>; */
> compatible = "ti,tilcdc,panel";
> status = "okay";
> + u-boot,dm-pre-reloc;
>
> panel-info {
> ac-bias = <255>;
> diff --git a/arch/arm/dts/am335x-brxre1.dts b/arch/arm/dts/am335x-brxre1.dts
> index 33d8ab78d8..6091a12fb7 100644
> --- a/arch/arm/dts/am335x-brxre1.dts
> +++ b/arch/arm/dts/am335x-brxre1.dts
> @@ -79,6 +79,8 @@
>
> backlight = <_bl>;
>
> + u-boot,dm-pre-reloc;
> +
> panel-info {
> ac-bias = <255>;
> ac-bias-intrpt = <0>;
> diff --git a/arch/arm/dts/am335x-evm-u-boot.dtsi
> b/arch/arm/dts/am335x-evm-u-boot.dtsi
> index b6b97ed16d..fc0250bd24 100644
> --- a/arch/arm/dts/am335x-evm-u-boot.dtsi
> +++ b/arch/arm/dts/am335x-evm-u-boot.dtsi
> @@ -8,6 +8,10 @@
> status = "disabled";
>
Re: RPI4: fail too boot with an initrd
On 17/02/2020 11:37, LABBE Corentin wrote:
> On Fri, Feb 14, 2020 at 06:15:27PM +, James Morse wrote:
>> Hi Corentin,
>>
>> On 14/02/2020 13:27, LABBE Corentin wrote:
>>> Since the inclusion of the "enable network support in RPi4 config" serie on
>>> uboot, I
>>> have started to work on adding the rpi4 in kernelCI.
>>> But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp.
>>>
>>> Using booti I hit:
>>> [0.00] Linux version 5.6.0-rc1-next-20200212
>>> (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02
>>> revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (LinaroGCC
>>> 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020
>>> [0.00] Machine model: Raspberry Pi 4 Model B
>>> [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
>>> [0.00] printk: bootconsole [uart0] enabled
>>> [0.00] efi: Getting EFI parameters from FDT:
>>> [0.00] efi: UEFI not found.
>>
>> So no EFI,
>>
>>> [0.00] OF: reserved mem: failed to allocate memory for node
>>> 'linux,cma'
>>
>> Out of memory.
>>
>>> [0.00] cma: Failed to reserve 32 MiB
>>> [0.00] Kernel panic - not syncing: Failed to allocate page table
>>> page
>>
>> Out of memory...
>>
>>> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
>>> 5.6.0-rc1-next-20200212 #66
>>> [0.00] Hardware name: Raspberry Pi 4 Model B (DT)
>>> [0.00] Call trace:
>>> [0.00] dump_backtrace+0x0/0x1a0
>>> [0.00] show_stack+0x14/0x20
>>> [0.00] dump_stack+0xbc/0x104
>>> [0.00] panic+0x16c/0x37c
>>> [0.00] early_pgtable_alloc+0x30/0xa0
>>
>> ... really early!
>>
>>> [0.00] __create_pgd_mapping+0x36c/0x588
>>> [0.00] map_kernel_segment+0x70/0xa4
>>> [0.00] paging_init+0xf4/0x528
>>> [0.00] setup_arch+0x250/0x5d8
>>> [0.00] start_kernel+0x90/0x6d8
>>>
>>>
>>> Since the same kernel boot with bootefi and that bootefi lack ramdisk
>>> address,
>>
>> Booting with EFI will cause linux to use the EFI memory map.
>>
>> Does your DT have a memory node? (or does it expect EFI to provide the
>> information)
>>
>>
>>> I tried to add the address in the dtb via:
>>> fdt addr 0x0240; fdt resize; fdt set /chosen linux,initrd-start
>>> 0x0270; fdt set /chosen linux,initrd-end 0x1000; bootefi 0x0008
>>> 0x0240
>>> But with that, I get:
>>> initrd not fully accessible via the linear mapping -- please check your
>>> bootloader ...
>>
>> So this one is an EFI boot, but you can't find where to put the initramfs
>> such that the
>> kernel agrees its in memory.
>>
>> If you boot with 'efi=debug', linux will print the EFI memory map. Could you
>> compare that
>> to where U-Boot thinks memory is?
>>
>> (it sounds like your DT memory node is missing, and your EFI memory map is
>> surprisingly small)
>
> Hello
>
> Thanks for your advices.
>
> In the dtb of mainline linux:
> /* Will be filled by the bootloader */
> memory@0 {
> device_type = "memory";
> reg = <0 0 0>;
> };
>
> In uboot I have:
> static struct mm_region bcm2711_mem_map[] = {
> {
> .virt = 0xUL,
> .phys = 0xUL,
> .size = 0xfe00UL,
> .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> PTE_BLOCK_INNER_SHARE
> }, {
> .virt = 0xfc00UL,
> .phys = 0xfc00UL,
> .size = 0x0380UL,
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> PTE_BLOCK_NON_SHARE |
> PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* List terminator */
> 0,
> }
> };
> But I dont know if uboot use that for filling the memory node.
No it doesn't. U-Boot uses the DT from the firmware and passes this to the
kernel. But it seems you pass instead your own device-tree to the kernel, so you
will need to update the memory node to show the available memory on you board.
Regards,
Matthias
>
>
> Booting the rpi4 with efi=debug give:
> EFI stub: Booting Linux Kernel...
> EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> [0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
> [0.00] Linux version 5.6.0-rc1-next-20200214
> (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02
> revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02))
> #70 SMP PREEMPT Fri Feb 14 10:54:54 UTC 2020
> [0.00] Machine model: Raspberry Pi 4 Model B
> [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
> [0.00] printk: bootconsole [uart0] enabled
> [0.00] efi: Getting EFI
Re: [PATCH] image.h: Change android_image_get_dtb* to use uint and not u32
Hello Yamada-san,
Thank you for your precious thoughts!
On Mon, Feb 17, 2020 at 04:45:57PM +0900, Masahiro Yamada wrote:
> If you need a fixed-width type,
> you can use uint32_t if you like.
>
> It is already used. See line 183 of include/image.h
>
> typedef struct image_header {
> uint32_t ih_magic; /* Image Header Magic Number */
>
> include/compiler.h includes when USE_HOSTCC is defined.
I think this is a safe, simple and non-intrusive solution,
so I have pushed https://patchwork.ozlabs.org/patch/1239098/.
> However, forbidding u32 for tools is questionable to me.
Since Linux has never restricted 'u32' in its in-tree tooling, I
totally support this statement.
> u32 and uint32_t should be always interchangeable.
>
> Perhaps, does the following patch work? (untested)
> ->8
> diff --git a/include/compiler.h b/include/compiler.h
> index ed74c272b8c5..f2a4adfbc7e4 100644
> --- a/include/compiler.h
> +++ b/include/compiler.h
> @@ -61,6 +61,9 @@
>
> #include
>
> +typedef uint8_t u8;
> +typedef uint16_t u16;
> +typedef uint32_t u32;
> typedef uint8_t __u8;
> typedef uint16_t __u16;
> typedef uint32_t __u32;
> ->8
>
Since this has greater impact compared to s/u32/uint32_t/, I leave
up to Tom to decide on the most suitable approach.
>
> BTW, I think include/compiler.h in U-Boot is ugly.
>
> Linux kernel uses
> tools/include/linux/types.h
> for defining {u8,u16,u32,u64} for the tools space.
>
Agreed, since below v3.16 commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d944c4eebcf4c0
>
> Barebox also adopted a similar approach.
>
> When compiling files for tools,
> actually includes
> scripts/include/linux/types.h
> instead of include/linux/types.h
>
>
> Perhaps, U-Boot could do similar,
> but I have never got around to it.
>
> Maybe U-Boot shares too much code
> between U-Boot space and tooling space?
>
> include/image.h of U-Boot is 1520 lines.
> include/image.h of Barebox is 258 lines.
>
> But, I am not tracking how they diverged.
>
> Shrinking the interface between U-Boot space and
> tooling space will provide a better maintainability.
>
> ifdef would work. Perhaps, splitting the header might be even better.
The above sounds like food for thought on how to mitigate the problem
long-term.
>
> That's my random thought.
Many thanks!
--
Best Regards
Eugeniu Rosca
Re: RPI4: fail too boot with an initrd
On Fri, Feb 14, 2020 at 06:15:27PM +, James Morse wrote:
> Hi Corentin,
>
> On 14/02/2020 13:27, LABBE Corentin wrote:
> > Since the inclusion of the "enable network support in RPi4 config" serie on
> > uboot, I
> > have started to work on adding the rpi4 in kernelCI.
> > But I fail to succeed in using a kernel/dtb/ramdisk downloaded via tftp.
> >
> > Using booti I hit:
> > [0.00] Linux version 5.6.0-rc1-next-20200212
> > (clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02
> > revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (LinaroGCC
> > 7.4-2019.02)) #66 SMP PREEMPT Wed Feb 12 10:14:20 UTC 2020
> > [0.00] Machine model: Raspberry Pi 4 Model B
> > [0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
> > [0.00] printk: bootconsole [uart0] enabled
> > [0.00] efi: Getting EFI parameters from FDT:
> > [0.00] efi: UEFI not found.
>
> So no EFI,
>
> > [0.00] OF: reserved mem: failed to allocate memory for node
> > 'linux,cma'
>
> Out of memory.
>
> > [0.00] cma: Failed to reserve 32 MiB
> > [0.00] Kernel panic - not syncing: Failed to allocate page table
> > page
>
> Out of memory...
>
> > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
> > 5.6.0-rc1-next-20200212 #66
> > [0.00] Hardware name: Raspberry Pi 4 Model B (DT)
> > [0.00] Call trace:
> > [0.00] dump_backtrace+0x0/0x1a0
> > [0.00] show_stack+0x14/0x20
> > [0.00] dump_stack+0xbc/0x104
> > [0.00] panic+0x16c/0x37c
> > [0.00] early_pgtable_alloc+0x30/0xa0
>
> ... really early!
>
> > [0.00] __create_pgd_mapping+0x36c/0x588
> > [0.00] map_kernel_segment+0x70/0xa4
> > [0.00] paging_init+0xf4/0x528
> > [0.00] setup_arch+0x250/0x5d8
> > [0.00] start_kernel+0x90/0x6d8
> >
> >
> > Since the same kernel boot with bootefi and that bootefi lack ramdisk
> > address,
>
> Booting with EFI will cause linux to use the EFI memory map.
>
> Does your DT have a memory node? (or does it expect EFI to provide the
> information)
>
>
> > I tried to add the address in the dtb via:
> > fdt addr 0x0240; fdt resize; fdt set /chosen linux,initrd-start
> > 0x0270; fdt set /chosen linux,initrd-end 0x1000; bootefi 0x0008
> > 0x0240
> > But with that, I get:
> > initrd not fully accessible via the linear mapping -- please check your
> > bootloader ...
>
> So this one is an EFI boot, but you can't find where to put the initramfs
> such that the
> kernel agrees its in memory.
>
> If you boot with 'efi=debug', linux will print the EFI memory map. Could you
> compare that
> to where U-Boot thinks memory is?
>
> (it sounds like your DT memory node is missing, and your EFI memory map is
> surprisingly small)
Hello
Thanks for your advices.
In the dtb of mainline linux:
/* Will be filled by the bootloader */
memory@0 {
device_type = "memory";
reg = <0 0 0>;
};
In uboot I have:
static struct mm_region bcm2711_mem_map[] = {
{
.virt = 0xUL,
.phys = 0xUL,
.size = 0xfe00UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
.virt = 0xfc00UL,
.phys = 0xfc00UL,
.size = 0x0380UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
PTE_BLOCK_NON_SHARE |
PTE_BLOCK_PXN | PTE_BLOCK_UXN
}, {
/* List terminator */
0,
}
};
But I dont know if uboot use that for filling the memory node.
Booting the rpi4 with efi=debug give:
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
[0.00] Linux version 5.6.0-rc1-next-20200214
(clabbe@build2-bionic-1804) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02
revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02))
#70 SMP PREEMPT Fri Feb 14 10:54:54 UTC 2020
[0.00] Machine model: Raspberry Pi 4 Model B
[0.00] earlycon: uart0 at MMIO32 0xfe215040 (options '')
[0.00] printk: bootconsole [uart0] enabled
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: System Table: 0x3b365590
[0.00] efi: MemMap Address: 0x38484040
[0.00] efi: MemMap Size: 0x0410
[0.00] efi: MemMap Desc. Size: 0x0028
[0.00] efi: MemMap Desc. Version: 0x0001
[0.00] efi: EFI v2.80 by Das U-Boot
[0.00] efi: SMBIOS=0x39f46000 MEMRESERVE=0x38487040
[0.00] efi:
[PATCH] image.h: use uint32_t instead of u32 in android_image_get_dtb*
Replace 'u32' by 'uint32_t' in image.h, since the former may lead to
build failures in U-Boot tooling (see [1]).
Avoid using 'uint', since it is not a fixed-width type [2], potentially
leading to a dangerous mismatch between the prototypes and definitions
of the android_image_get_dtb* functions.
This should be the quickest way to overcome the tooling build failure,
with more future-proof solutions being proposed by Yamada-san in [1].
[1] https://patchwork.ozlabs.org/patch/1238245/
[2] Excerpt from https://en.cppreference.com/w/cpp/language/types
---8<
Type specifierWidth in bits by data model
LP32 ILP32 LLP64 LP64
unsigned int 1632 32 32
---8<
Cc: Tom Rini
Cc: Sam Protsenko
Fixes: 7f2531502c74c0 ("image: android: Add routine to get dtbo params")
Fixes: c3bfad825a71ea ("image: android: Add functions for handling dtb field")
Suggested-by: Masahiro Yamada
Signed-off-by: Eugeniu Rosca
---
include/image.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/image.h b/include/image.h
index b316d167d8d7..1341fbed62ba 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1425,9 +1425,9 @@ int android_image_get_ramdisk(const struct andr_img_hdr
*hdr,
ulong *rd_data, ulong *rd_len);
int android_image_get_second(const struct andr_img_hdr *hdr,
ulong *second_data, ulong *second_len);
-bool android_image_get_dtbo(ulong hdr_addr, ulong *addr, u32 *size);
-bool android_image_get_dtb_by_index(ulong hdr_addr, u32 index, ulong *addr,
- u32 *size);
+bool android_image_get_dtbo(ulong hdr_addr, ulong *addr, uint32_t *size);
+bool android_image_get_dtb_by_index(ulong hdr_addr, uint32_t index, ulong
*addr,
+ uint32_t *size);
ulong android_image_get_end(const struct andr_img_hdr *hdr);
ulong android_image_get_kload(const struct andr_img_hdr *hdr);
ulong android_image_get_kcomp(const struct andr_img_hdr *hdr);
--
2.25.0
