Re: [PATCH 2/3] drivers: musb-new: add allwinner f1c100s

[Andre Przywara]

On Fri, 9 Jun 2023 14:11:53 +
路辉  wrote:

Hi,

> From fe7d48e84bb3c72d219f37eed51ea766f83b4bec Mon Sep 17 00:00:00 2001
> From: Lu Hui 
> Date: Fri, 9 Jun 2023 22:05:23 +0800
> Subject: [PATCH 2/3] drivers: musb-new: add allwinner f1c100s configuration

thanks for sending this. If this patch should be considered for
merging, you need a few lines of commit message, and more importantly
your Signed-off-by: line.

> ---
>  drivers/usb/musb-new/sunxi.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
> index dc4cfc2194..1c90739cea 100644
> --- a/drivers/usb/musb-new/sunxi.c
> +++ b/drivers/usb/musb-new/sunxi.c
> @@ -4,6 +4,7 @@
>   *
>   * Copyright © 2015 Hans de Goede 
>   * Copyright © 2013 Jussi Kivilinna 
> + * Copyright © 2023 Lu Hui 

This is not needed, only significant contributions require
adding a copyright line. The license is much more important.

>   *
>   * Based on the sw_usb "Allwinner OTG Dual Role Controller" code.
>   *  Copyright 2007-2012 (C) Allwinner Technology Co., Ltd.
> @@ -519,6 +520,10 @@ static const struct sunxi_musb_config sun8i_h3_cfg = {
>  .config = _config_h3,
>  };
> 
> +static const struct sunxi_musb_config suniv_f1c100s_cfg = {
> +.config = _config,
> +};

Since is not needed, as it's identical to the A10 structure ...

> +
>  static const struct udevice_id sunxi_musb_ids[] = {
>  { .compatible = "allwinner,sun4i-a10-musb",
>  .data = (ulong)_a10_cfg },
> @@ -528,6 +533,8 @@ static const struct udevice_id sunxi_musb_ids[] = {
>  .data = (ulong)_a31_cfg },
>  { .compatible = "allwinner,sun8i-h3-musb",
>  .data = (ulong)_h3_cfg },
> +{ .compatible = "allwinner,suniv-f1c100s-musb",
> +.data = (ulong)_f1c100s_cfg },

... which you can just reference here directly.

Otherwise this matches the patch I have prepared here as well, I just
wanted to test host mode before sending.

If you resend this one patch with your Signed-off-by: (instead of
Copyright), and using sun4i_a10_cfg, I am happy to take it.

Thanks,
Andre

Re: [PATCH 3/3] arm: dts: licheepi-nano: enable usb device mode

[Andre Przywara]

On Fri, 9 Jun 2023 14:12:31 +
路辉  wrote:

Hi,

> From fff53ba354c8eca33cb9901888778420db637073 Mon Sep 17 00:00:00 2001
> From: Lu Hui 
> Date: Fri, 9 Jun 2023 22:05:53 +0800
> Subject: [PATCH 3/3] arm: dts: licheepi-nano: enable usb device mode

thanks for sending this, but this snippet was merged into the
U-Boot tree just a few days ago:
https://source.denx.de/u-boot/u-boot/-/commit/57285737cbae4638112a96e4b3ee78eda6182b6e

Cheers,
Andre

> ---
>  arch/arm/dts/suniv-f1c100s-licheepi-nano.dts | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
> b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
> index 43896723a9..0ab6353727 100644
> --- a/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
> +++ b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
> @@ -5,6 +5,7 @@
> 
>  /dts-v1/;
>  #include "suniv-f1c100s.dtsi"
> +#include 
> 
>  #include 
> 
> @@ -71,3 +72,17 @@
>  usb0_id_det-gpios = < 4 2 GPIO_ACTIVE_HIGH>; /* PE2 */
>  status = "okay";
>  };
> +
> +_sram {
> +status = "okay";
> +};
> +
> +_otg {
> +dr_mode = "peripheral";
> +status = "okay";
> +};
> +
> + {
> +usb0_id_det-gpio = < 4 2 GPIO_ACTIVE_HIGH>; /* PE2 */
> +status = "okay";
> +};

Re: [PATCH v2 0/6] corstone1000: fwu metadata and GPT

[Tom Rini]

On Mon, May 29, 2023 at 03:02:23PM +0100, Rui Miguel Silva wrote:

> Now that the nvmxip block driver is merged we can add on top
> of it the platform code to use GPT and FWU metadata in the
> Corstone1000.
> 
> But first, push 2 fixes that are needed to make all this work:
>  - move nvmxip header to include
>  - setup fwu metadata structures as packed (we have a 32bit
>writer - Secure enclave Cortex-M0 and a 64bit reader host
>Cortex-A35)
> 
> Cheers,
>  Rui
> 
> v1 [0]-> v2:
> Ilias:
> - add Reviewed-by tag in patch 1/6
> 
> Heinrich:
> - fix test include nvmxip header after the move to include/
> in patch 2/6
> 
> [0]: 
> https://lore.kernel.org/u-boot/20230502131200.2551513-1-rui.si...@linaro.org/
> 
> Rui Miguel Silva (6):
>   fwu_metadata: make sure structures are packed

This patch leads to build failures now, please rebase on top of current
-next, thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v6 0/6] FWU: Add support for mtd backed feature on DeveloperBox

[Tom Rini]

On Wed, 31 May 2023 00:28:04 -0500, jaswinder.si...@linaro.org wrote:

> From: Jassi Brar 
> 
> Introduce support for mtd backed storage for FWU feature and enable it on
> Synquacer platform based DeveloperBox.
> 
> This revision is rebased onto patchset that trims the FWU api
>  
> https://lore.kernel.org/u-boot/20230306231747.1888513-1-jassisinghb...@gmail.com/
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom

Re: [PATCH v6 0/7] fwu: gpt: implement read_mdata and write_mdata callbacks

[Tom Rini]

On Mon, 06 Mar 2023 17:17:47 -0600, jassisinghb...@gmail.com wrote:

> From: Jassi Brar 
> 
> The patchset reduces ~400 lines of code, while keeping the functionality same 
> and making
> meta-data operations much faster (by using cached structures).
> 
> Issue:
>  meta-data copies (primary and secondary) are being handled by the 
> backend/storage layer
> instead of the common core in fwu.c (as also noted by Ilias)  that is, 
> gpt_blk.c manages
> meta-data and similarly raw_mtd.c will have to do the same when it arrives. 
> The code
> could by make smaller, cleaner and optimised.
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom

Re: [PATCH 1/3] phy: phy-sun4i-usb: add allwinner f1c100s configuration

[Andre Przywara]

On Fri, 9 Jun 2023 14:11:07 +
路辉  wrote:

Hi,

> From 09a85536f92cfd22f2a6feba8ea91fae4bc41ed8 Mon Sep 17 00:00:00 2001
> From: Lu Hui 
> Date: Fri, 9 Jun 2023 22:04:56 +0800
> Subject: [PATCH 1/3] phy: phy-sun4i-usb: add allwinner f1c100s configuration

I sent a similar patch literally just a few hours ago:
https://lore.kernel.org/u-boot/20230609105621.1410483-1-andre.przyw...@arm.com/T/

Can you please check whether this works for you as well? My series
missed the final MUSB enablement (because I wanted to test host mode
first), but at least the PHY part should work. 

In the future, please add a commit message, describing your patch, and
also your Signed-off-by: line, otherwise the patch cannot be merged.

Cheers,
Andre


> 
> ---
>  drivers/phy/allwinner/phy-sun4i-usb.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
> b/drivers/phy/allwinner/phy-sun4i-usb.c
> index 6428163c18..8425a83c84 100644
> --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> @@ -4,6 +4,7 @@
>   * Copyright (C) 2017 Jagan Teki 
>   * Copyright (C) 2015 Hans de Goede 
>   * Copyright (C) 2014 Roman Byshko 
> + * Copyright (C) 2023 Lu Hui 
>   *
>   * Modelled arch/arm/mach-sunxi/usb_phy.c to compatible with generic-phy.
>   *
> @@ -83,6 +84,7 @@ enum sun4i_usb_phy_type {
>  sun8i_v3s_phy,
>  sun50i_a64_phy,
>  sun50i_h6_phy,
> +suniv_f1c100s_phy,
>  };
> 
>  struct sun4i_usb_phy_cfg {
> @@ -372,8 +374,9 @@ static int sun4i_usb_phy_xlate(struct phy *phy,
>  {
>  struct sun4i_usb_phy_data *data = dev_get_priv(phy->dev);
> 
> -if (args->args_count >= data->cfg->num_phys)
> +if (args->args_count > data->cfg->num_phys) {
>  return -EINVAL;
> +}
> 
>  if (data->cfg->missing_phys & BIT(args->args[0]))
>  return -ENODEV;
> @@ -531,6 +534,14 @@ static int sun4i_usb_phy_probe(struct udevice *dev)
>  return 0;
>  }
> 
> +static const struct sun4i_usb_phy_cfg suniv_f1c100s_cfg = {
> +.num_phys = 1,
> +.type = suniv_f1c100s_phy,
> +.disc_thresh = 3,
> +.phyctl_offset = REG_PHYCTL_A10,
> +.dedicated_clocks = true,
> +};
> +
>  static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
>  .num_phys = 3,
>  .type = sun4i_a10_phy,
> @@ -659,6 +670,7 @@ static const struct udevice_id sun4i_usb_phy_ids[] = {
>  { .compatible = "allwinner,sun20i-d1-usb-phy", .data =
> (ulong)_d1_cfg },
>  { .compatible = "allwinner,sun50i-a64-usb-phy", .data =
> (ulong)_a64_cfg},
>  { .compatible = "allwinner,sun50i-h6-usb-phy", .data =
> (ulong)_h6_cfg},
> +{ .compatible = "allwinner,suniv-f1c100s-usb-phy", .data =
> (ulong)_f1c100s_cfg},
>  { }
>  };
> 

Re: [PATCH 3/5] sunxi: H616: dram: split struct dram_para

[Andre Przywara]

On Fri, 09 Jun 2023 22:26:21 +0200
Jernej Škrabec  wrote:

Hi,

> Dne sreda, 07. junij 2023 ob 02:07:43 CEST je Andre Przywara napisal(a):
> > Currently there is one DRAM parameter struct for the Allwinner H616 DRAM
> > "driver". It contains many fields that are compile time constants
> > (set by Kconfig variables), though there are also some fields that are
> > probed and changed over the runtime of the DRAM initialisation.
> > 
> > Because of this mixture, the compiler cannot properly optimise the code
> > for size, as it does not consider constant propagation in its full
> > potential.
> > 
> > Help the compiler out by splitting that structure into two: one that only
> > contains values known at compile time, and another one where the values
> > will actually change. The former can then be declared "const", which will
> > let the compiler fold its values directly into the code using it.
> > 
> > We also add "const" tags for some new "struct dram_config" pointers, to
> > further increase code optimisation.
> > To help the compiler optimise the code further, the definition of the
> > now "const struct dram_para" has to happen at a file-global level, so
> > move that part out of sunxi_dram_init().
> > 
> > That results in quite some code savings (almost 2KB), and helps to keep
> > the code small with the LPDDR3 support added later.
> > 
> > Signed-off-by: Andre Przywara   
> 
> Nice trick. It could be used also in other DRAM drivers.

You bet ;-)

I have a patch for the H6 already. It doesn't save as much there
(merely 500 bytes), I guess because we don't have as many build time
parameters, but the H6 SPL is very big, so every byte saved there is a
win. Will post this ASAP.

> Reviewed-by: Jernej Skrabec 

Many thanks for that!

Cheers,
Andre

Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support

[Sam Edwards]

Hi Andre,

On 12/5/22 17:45, Andre Przywara wrote:

Please let me know if you have any opinions!


I believe I promised you last month I'd let you know once I had a build 
I'm happy with, and I'm pleased to say that I think I've reached that 
point. I'm running quite rapidly out of sharp edges to sand down, too.


I have a build of U-Boot for my target, complete with:
- UART3 initialized correctly
- DRAM coming up correctly
- SPL sets configured boot clock correctly
- SPI-NAND support (SPL and U-Boot proper)
- MMC support (SPL and U-Boot proper)
- SPL boot from FEL
- USB gadget support
- Ethernet MAC+PHY support
- I²C support *
- GPIO support (LEDs, buttons, misc. board management)
- `reset` working (requries CONFIG_SYSRESET unset, WDT key)
- PSCI, nonsec
- Able to boot Linux ;)

* Requires nonzero `MVTWSI_CONTROL_CLEAR_IFLG` for NCAT2, and a patch to 
the pinctrl driver to configure the proper mux function for my necessary 
pins.


I figured I'd share this list as a sort of checklist for your own work, 
too. The remainder of my efforts now will probably be focused on 
mainlining this stuff (let me know how else I can be of help), and then 
I'm afraid I'll have to disappear back downstream to the Turing Pi 2 
development effort, but maybe our paths will cross again in the kernel 
lists. :)


Thank you greatly,
Sam

P.S. I figure the reason there aren't I²C function defs in the d1 
pinctrl table already is because Allwinner tends to kick around the I²C 
mux values a lot and we would need a per-pin lookup table that would eat 
up too much valuable image space?


In an entirely JUST FOR FUN exercise to give myself a break from staring 
at datasheets/patches and do a "pure CS" coding challenge for a change, 
I came up with a terse encoding scheme for this table. Here is the size 
(in bits) for a selection of D1's functions (pin assignments harvested 
from Linux):


 'emac': 50,
 'i2c0': 101,
 'i2c1': 64,
 'i2c2': 109,
 'i2c3': 91,
 'mmc0': 23,
 'mmc1': 23,
 'mmc2': 20,
 'spi0': 41,
 'spi1': 48,
 'uart0': 78,
 'uart1': 87,
 'uart2': 88,
 'uart3': 102,
 'uart4': 68,
 'uart5': 66,

...and yes, it also identifies invalid pin assignments! I'd be willing 
to contribute something like this if there's big interest, but I figure 
needing to compress this at build-time might be a bit too complicated 
for the U-Boot project's liking.

[PATCH v2 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization

[Sam Edwards]

This is largely a cosmetic change, with one functional distinction:
We are now only setting BIT(0), and no longer clearing BIT(1).

The A20 manual confirms the purpose and bitwidth of this field, and we
have also been doing it this way for a while in Linux-land: The prior
narrative about this initialization being about configuring a FIFO has
pretty much been debunked for years now.

This cleanup also adds a TODO comment about runtime discovery
of the SYSCON base, per discussion with Andre.

Signed-off-by: Sam Edwards 
Cc: Andre Przywara 
---
 drivers/usb/musb-new/sunxi.c | 38 +++-
 1 file changed, 29 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index a67eaf..be7faaa11e 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -171,15 +171,29 @@ static void USBC_ForceVbusValidToHigh(__iomem void *base)
musb_writel(base, USBC_REG_o_ISCR, reg_val);
 }
 
-static void USBC_ConfigFIFO_Base(void)
-{
-   u32 reg_value;
+/**
+ * Non-USBC register access needed for initialization
+ 
**/
 
-   /* config usb fifo, 8kb mode */
-   reg_value = readl(SUNXI_SRAMC_BASE + 0x04);
-   reg_value &= ~(0x03 << 0);
-   reg_value |= BIT(0);
-   writel(reg_value, SUNXI_SRAMC_BASE + 0x04);
+/*
+ * A10(s), A13, GR8, A20:
+ * switch ownership of SRAM block 'D' to the USB-OTG controller
+ */
+static void sunxi_musb_claim_sram(void)
+{
+   /*
+* TODO: Do not use hardcoded SUNXI_SRAMC_BASE; find the syscon base by
+* traversing this OTG device's `allwinner,sram` FDT property and
+* working upward to the system controller.
+*/
+   void *syscon_base = (void *)SUNXI_SRAMC_BASE;
+
+   /*
+* BIT(0) of SRAM_CTRL_REG1 (syscon+0x04) controls SRAM-D ownership:
+* '0' -> exclusive access by CPU
+* '1' -> exclusive access by USB0
+*/
+   setbits_le32(syscon_base + 0x04, BIT(0));
 }
 
 /**
@@ -313,7 +327,13 @@ static int sunxi_musb_init(struct musb *musb)
musb->isr = sunxi_musb_interrupt;
 
if (glue->cfg->has_sram) {
-   USBC_ConfigFIFO_Base();
+   /*
+* This is an older USB-OTG controller that Allwinner did not
+* endow with a dedicated SRAM block; it instead uses SRAM
+* block 'D', ownership of which needs to be handed over by
+* the CPU
+*/
+   sunxi_musb_claim_sram();
}
 
USBC_EnableDpDmPullUp(musb->mregs);
-- 
2.39.2

[PATCH v2 1/2] usb: musb-new: sunxi: only perform SRAM initialization when necessary

[Sam Edwards]

Only the older (ca. A10, A20) sunxis need this poke for the MUSB to
function. Mimic the Linux kernel and add a `has_sram` flag to the config
structure that is only set for the specific compatibles that require
this initialization.

Signed-off-by: Sam Edwards 
Reviewed-by: Andre Przywara 
Tested-by: Andre Przywara 
---
 drivers/usb/musb-new/sunxi.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index c5c63249aa..a67eaf 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -83,6 +83,7 @@
 
 struct sunxi_musb_config {
struct musb_hdrc_config *config;
+   bool has_sram;
 };
 
 struct sunxi_glue {
@@ -311,7 +312,10 @@ static int sunxi_musb_init(struct musb *musb)
 
musb->isr = sunxi_musb_interrupt;
 
-   USBC_ConfigFIFO_Base();
+   if (glue->cfg->has_sram) {
+   USBC_ConfigFIFO_Base();
+   }
+
USBC_EnableDpDmPullUp(musb->mregs);
USBC_EnableIdPullUp(musb->mregs);
 
@@ -517,6 +521,7 @@ static int musb_usb_remove(struct udevice *dev)
 
 static const struct sunxi_musb_config sun4i_a10_cfg = {
.config = _config,
+   .has_sram = true,
 };
 
 static const struct sunxi_musb_config sun6i_a31_cfg = {
-- 
2.39.2

[PATCH v2 0/2] sunxi, usb: Clean up SRAM initialization code

[Sam Edwards]

Hi list,

This is the second version of cleaning up the SRAM initialization code in the
musb-new variant for sunxis.

Patch 1 ("only perform ... when necessary") has not changed since v1.
Patch 2 has had the following changes:
- Remove one-off bit/reg #defines, per feedback from Andre.
- Switch to the Linux multiline comment style, per feedback from Andre.
- Reword the commit message, since this change isn't as "speculative" as I had
  originally thought.
- Perhaps controversially, introduce a `void *syscon_base;` under that TODO
  comment I mentioned before, to further invite somebody to "DO" it. :)

Thank you once again for your continued efforts,
Sam

Sam Edwards (2):
  usb: musb-new: sunxi: only perform SRAM initialization when necessary
  usb: musb-new: sunxi: clarify the purpose of SRAM initialization

 drivers/usb/musb-new/sunxi.c | 43 
 1 file changed, 34 insertions(+), 9 deletions(-)

-- 
2.39.2

Re: [PATCH 5/5] sunxi: H616: add LPDDR3 DRAM support

[Andre Przywara]

On Fri, 09 Jun 2023 22:38:38 +0200
Jernej Škrabec  wrote:

Hi,

> Dne sreda, 07. junij 2023 ob 02:07:45 CEST je Andre Przywara napisal(a):
> > From: iuncuim 
> > 
> > The H616 SoC has support for several types of DRAM: DDR3, LPDDR3,
> > DDR4 and LPDDR4.
> > At the moment, the driver only supports DDR3 memory.
> > Let's extend the driver to support the LPDDR3 memory. All "magic"
> > values obtained from the boot0.
> > ---
> >  arch/arm/mach-sunxi/Kconfig   |   8 +
> >  arch/arm/mach-sunxi/dram_sun50i_h616.c| 193 +-
> >  arch/arm/mach-sunxi/dram_timings/Makefile |   1 +
> >  .../arm/mach-sunxi/dram_timings/h616_lpddr3.c |  95 +
> >  4 files changed, 242 insertions(+), 55 deletions(-)
> >  create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_lpddr3.c
> > 
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index 197d77ea658..5ce82a955c6 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -487,6 +487,14 @@ config SUNXI_DRAM_H6_DDR3_1333
> > This option is the DDR3 timing used by the boot0 on H6 TV boxes
> > which use a DDR3-1333 timing.
> >  
> > +config SUNXI_DRAM_H616_LPDDR3
> > +   bool "LPDDR3 DRAM chips on the H616 DRAM controller"
> > +   select SUNXI_DRAM_LPDDR3
> > +   depends on DRAM_SUN50I_H616
> > +   ---help---
> > +   This option is the LPDDR3 timing used by the stock boot0 by
> > +   Allwinner.
> > +
> >  config SUNXI_DRAM_H616_DDR3_1333
> > bool "DDR3-1333 boot0 timings on the H616 DRAM controller"
> > select SUNXI_DRAM_DDR3
> > diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c 
> > b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > index 4e988cebf59..082746ea7f3 100644
> > --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> > @@ -228,10 +228,17 @@ static void mctl_set_addrmap(const struct dram_config 
> > *config)
> >  }
> >  
> >  static const u8 phy_init[] = {
> > +#ifdef CONFIG_SUNXI_DRAM_H616_DDR3_1333
> > 0x07, 0x0b, 0x02, 0x16, 0x0d, 0x0e, 0x14, 0x19,
> > 0x0a, 0x15, 0x03, 0x13, 0x04, 0x0c, 0x10, 0x06,
> > 0x0f, 0x11, 0x1a, 0x01, 0x12, 0x17, 0x00, 0x08,
> > 0x09, 0x05, 0x18
> > +#elif defined(CONFIG_SUNXI_DRAM_H616_LPDDR3)
> > +   0x18, 0x06, 0x00, 0x05, 0x04, 0x03, 0x09, 0x02,
> > +   0x08, 0x01, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
> > +   0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x07,
> > +   0x17, 0x19, 0x1a
> > +#endif
> >  };
> >  
> >  static void mctl_phy_configure_odt(const struct dram_para *para)
> > @@ -263,19 +270,31 @@ static void mctl_phy_configure_odt(const struct 
> > dram_para *para)
> > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x34c);
> >  
> > val = para->dx_odt & 0x1f;
> > -   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380);
> > +   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> > +   writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x380);
> > +   else
> > +   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380);
> > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x384);
> >  
> > val = (para->dx_odt >> 8) & 0x1f;
> > -   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> > +   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> > +   writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> > +   else
> > +   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c4);
> >  
> > val = (para->dx_odt >> 16) & 0x1f;
> > -   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400);
> > +   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> > +   writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x400);
> > +   else
> > +   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400);
> > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x404);
> >  
> > val = (para->dx_odt >> 24) & 0x1f;
> > -   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440);
> > +   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> > +   writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x440);
> > +   else
> > +   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440);
> > writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x444);  
> 
> Above dx_odt oriented changes are not needed. They depend on Kconfig symbol,
> which can simply be set to 0.

Ha, I thought so as well, but if you look closely, it's only *one* of
the two writes which turn to zero, the other register stays at the
Kconfig value. Annoying, I know ;-)
I couldn't think of a shorter or even cleaner way to express this,
really, apart from a macro maybe, so I guess we have to live with it.

Cheers,
Andre


> I didn't do detailed check, but if it works, it should be ok. Were calculated
> values here compared to vendor driver?
> 
> Best regards,
> Jernej
> 
> >  
> > dmb();
> > @@ -794,31 +813,47 @@ static void mctl_phy_ca_bit_delay_compensation(const 
> > struct dram_para *para,
> > writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e0);
> > writel(val, SUNXI_DRAM_PHY0_BASE + 0x7f4);
> >  
> > -   /* 

Re: [PATCH 3/3] sunxi: Kconfig: rework PHY_USB_SUN4I selection

[Jernej Škrabec]

Dne petek, 09. junij 2023 ob 12:56:21 CEST je Andre Przywara napisal(a):
> At the moment we use "select" in each Allwinner SoC's Kconfig section to
> include the USB PHY driver in the build. This means it cannot be disabled
> via Kconfig, although USB is not really a strictly required core
> functionality, and a particular board might not even include USB ports.
> 
> Rework the Kconfig part by removing the "select" lines for each SoC's
> section, and instead letting it default to "y" in the PHY driver section
> itself. We use "depends on !" to exclude the few SoCs we don't support
> (yet). The Allwinner V3s does not enable USB (PHY) support at the moment,
> even though it should work: let the PHY default to "n" to keep the
> current behaviour.
> 
> Signed-off-by: Andre Przywara 

I stumbled on this issue before, but it didn't bother me enough to actually
do something about that. Thanks!

Reviewed-by: Jernej Skrabec 

Best regards,
Jernej

Re: [PATCH 2/3] phy: sun4i-usb: add Allwinner F1C100s support

[Jernej Škrabec]

Dne petek, 09. junij 2023 ob 12:56:20 CEST je Andre Przywara napisal(a):
> The Allwinner F1C100s implements a single USB PHY, connected to its MUSB
> OTG controller. The USB PHY is of the simpler, older type (like the A10),
> the only real difference is that it's indeed only one PHY.
> 
> Add a struct describing those F1C100s USB PHY properties, and connect it
> to the new compatible string.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Jernej Skrabec 

Best regards,
Jernej

Re: [PATCH 1/3] phy: sun4i-usb: Fix of_xlate() argument check

[Jernej Škrabec]

Dne petek, 09. junij 2023 ob 12:56:19 CEST je Andre Przywara napisal(a):
> In its of_xlate() function, the Allwinner USB PHY driver compares the
> args_count variable against the number of implemented USB PHYs, although
> this is the *number of arguments* to the DT phandle property. Per the DT
> binding for this PHY device, this number is always one, so this check
> will always fail if the particular SoC implements exactly one USB PHY.
> So far this affected only the V3s (which has USB support disabled), but
> the F1C100s also sports one PHY only.
> 
> Fix that check to compare args_count against exactly 1, and the args[0]
> content (requested PHY number) against the number of implemented PHYs.
> 
> This fixes USB operation on the Allwinner V3s and allows to enable USB
> on the Allwinner F1C100s SoC.
> 
> Signed-off-by: Andre Przywara 

Nice catch!

Reviewed-by: Jernej Skrabec 

Best regards,
Jernej

Re: [PATCH 5/5] sunxi: H616: add LPDDR3 DRAM support

[Jernej Škrabec]

Dne sreda, 07. junij 2023 ob 02:07:45 CEST je Andre Przywara napisal(a):
> From: iuncuim 
> 
> The H616 SoC has support for several types of DRAM: DDR3, LPDDR3,
> DDR4 and LPDDR4.
> At the moment, the driver only supports DDR3 memory.
> Let's extend the driver to support the LPDDR3 memory. All "magic"
> values obtained from the boot0.
> ---
>  arch/arm/mach-sunxi/Kconfig   |   8 +
>  arch/arm/mach-sunxi/dram_sun50i_h616.c| 193 +-
>  arch/arm/mach-sunxi/dram_timings/Makefile |   1 +
>  .../arm/mach-sunxi/dram_timings/h616_lpddr3.c |  95 +
>  4 files changed, 242 insertions(+), 55 deletions(-)
>  create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_lpddr3.c
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 197d77ea658..5ce82a955c6 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -487,6 +487,14 @@ config SUNXI_DRAM_H6_DDR3_1333
>   This option is the DDR3 timing used by the boot0 on H6 TV boxes
>   which use a DDR3-1333 timing.
>  
> +config SUNXI_DRAM_H616_LPDDR3
> + bool "LPDDR3 DRAM chips on the H616 DRAM controller"
> + select SUNXI_DRAM_LPDDR3
> + depends on DRAM_SUN50I_H616
> + ---help---
> + This option is the LPDDR3 timing used by the stock boot0 by
> + Allwinner.
> +
>  config SUNXI_DRAM_H616_DDR3_1333
>   bool "DDR3-1333 boot0 timings on the H616 DRAM controller"
>   select SUNXI_DRAM_DDR3
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c 
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index 4e988cebf59..082746ea7f3 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -228,10 +228,17 @@ static void mctl_set_addrmap(const struct dram_config 
> *config)
>  }
>  
>  static const u8 phy_init[] = {
> +#ifdef CONFIG_SUNXI_DRAM_H616_DDR3_1333
>   0x07, 0x0b, 0x02, 0x16, 0x0d, 0x0e, 0x14, 0x19,
>   0x0a, 0x15, 0x03, 0x13, 0x04, 0x0c, 0x10, 0x06,
>   0x0f, 0x11, 0x1a, 0x01, 0x12, 0x17, 0x00, 0x08,
>   0x09, 0x05, 0x18
> +#elif defined(CONFIG_SUNXI_DRAM_H616_LPDDR3)
> + 0x18, 0x06, 0x00, 0x05, 0x04, 0x03, 0x09, 0x02,
> + 0x08, 0x01, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
> + 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x07,
> + 0x17, 0x19, 0x1a
> +#endif
>  };
>  
>  static void mctl_phy_configure_odt(const struct dram_para *para)
> @@ -263,19 +270,31 @@ static void mctl_phy_configure_odt(const struct 
> dram_para *para)
>   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x34c);
>  
>   val = para->dx_odt & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380);
> + if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x380);
> + else
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380);
>   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x384);
>  
>   val = (para->dx_odt >> 8) & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> + if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> + else
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0);
>   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c4);
>  
>   val = (para->dx_odt >> 16) & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400);
> + if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x400);
> + else
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400);
>   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x404);
>  
>   val = (para->dx_odt >> 24) & 0x1f;
> - writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440);
> + if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> + writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x440);
> + else
> + writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440);
>   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x444);

Above dx_odt oriented changes are not needed. They depend on Kconfig symbol,
which can simply be set to 0.

I didn't do detailed check, but if it works, it should be ok. Were calculated
values here compared to vendor driver?

Best regards,
Jernej

>  
>   dmb();
> @@ -794,31 +813,47 @@ static void mctl_phy_ca_bit_delay_compensation(const 
> struct dram_para *para,
>   writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e0);
>   writel(val, SUNXI_DRAM_PHY0_BASE + 0x7f4);
>  
> - /* following configuration is DDR3 specific */
> - val = (para->tpr10 >> 7) & 0x1e;
> - if (para->tpr2 & 1) {
> - writel(val, SUNXI_DRAM_PHY0_BASE + 0x794);
> - if (config->ranks == 2) {
> - val = (para->tpr10 >> 11) & 0x1e;
> - writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e4);
> - }
> - if (para->tpr0 & BIT(31)) {
> - val = (para->tpr0 << 1) & 0x3e;
> - writel(val, 

Re: [PATCH 4/5] sunxi: H616: add DRAM type selection

[Jernej Škrabec]

Dne sreda, 07. junij 2023 ob 02:07:44 CEST je Andre Przywara napisal(a):
> From: iuncuim 
> 
> Allwinner H616 SoC supports several types of DRAM memory. To further
> integrate other types of memory, we need to add this delimitation.
> ---
>  arch/arm/mach-sunxi/Kconfig   | 10 +-
>  arch/arm/mach-sunxi/dram_timings/Makefile |  3 +--
>  configs/orangepi_zero2_defconfig  |  1 +
>  configs/x96_mate_defconfig|  1 +
>  4 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 6dcbb096f74..197d77ea658 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -442,7 +442,7 @@ config ARM_BOOT_HOOK_RMR
>   This allows both the SPL and the U-Boot proper to be entered in
>   either mode and switch to AArch64 if needed.
>  
> -if SUNXI_DRAM_DW || DRAM_SUN50I_H6
> +if SUNXI_DRAM_DW || DRAM_SUN50I_H6 || DRAM_SUN50I_H616
>  config SUNXI_DRAM_DDR3
>   bool
>  
> @@ -487,6 +487,14 @@ config SUNXI_DRAM_H6_DDR3_1333
>   This option is the DDR3 timing used by the boot0 on H6 TV boxes
>   which use a DDR3-1333 timing.
>  
> +config SUNXI_DRAM_H616_DDR3_1333
> + bool "DDR3-1333 boot0 timings on the H616 DRAM controller"
> + select SUNXI_DRAM_DDR3
> + depends on DRAM_SUN50I_H616
> + ---help---
> + This option is the DDR3 timing used by the boot0 on H616 TV boxes
> + which use a DDR3-1333 timing.

I'm always a bit unsure about help part. There is no need for "---", right?
I also usually ident help block with extra two spaces. Do we have any rules
for that?

Apart from that and SoB tag, it looks good.

Best regards,
Jernej

> +
>  config SUNXI_DRAM_DDR2_V3S
>   bool "DDR2 found in V3s chip"
>   select SUNXI_DRAM_DDR2
> diff --git a/arch/arm/mach-sunxi/dram_timings/Makefile 
> b/arch/arm/mach-sunxi/dram_timings/Makefile
> index 39a8756c297..4d78c04c9ae 100644
> --- a/arch/arm/mach-sunxi/dram_timings/Makefile
> +++ b/arch/arm/mach-sunxi/dram_timings/Makefile
> @@ -3,5 +3,4 @@ obj-$(CONFIG_SUNXI_DRAM_LPDDR3_STOCK) += lpddr3_stock.o
>  obj-$(CONFIG_SUNXI_DRAM_DDR2_V3S)+= ddr2_v3s.o
>  obj-$(CONFIG_SUNXI_DRAM_H6_LPDDR3)   += h6_lpddr3.o
>  obj-$(CONFIG_SUNXI_DRAM_H6_DDR3_1333)+= h6_ddr3_1333.o
> -# currently only DDR3 is supported on H616
> -obj-$(CONFIG_MACH_SUN50I_H616)   += h616_ddr3_1333.o
> +obj-$(CONFIG_SUNXI_DRAM_H616_DDR3_1333)  += h616_ddr3_1333.o
> diff --git a/configs/orangepi_zero2_defconfig 
> b/configs/orangepi_zero2_defconfig
> index 6cb942f511a..e38cc20ac72 100644
> --- a/configs/orangepi_zero2_defconfig
> +++ b/configs/orangepi_zero2_defconfig
> @@ -7,6 +7,7 @@ CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e
>  CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e
>  CONFIG_DRAM_SUN50I_H616_TPR10=0xf83438
>  CONFIG_MACH_SUN50I_H616=y
> +CONFIG_SUNXI_DRAM_H616_DDR3_1333=y
>  CONFIG_R_I2C_ENABLE=y
>  CONFIG_SPL_SPI_SUNXI=y
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> diff --git a/configs/x96_mate_defconfig b/configs/x96_mate_defconfig
> index 122c1a99e32..c86cf43771c 100644
> --- a/configs/x96_mate_defconfig
> +++ b/configs/x96_mate_defconfig
> @@ -10,6 +10,7 @@ CONFIG_DRAM_SUN50I_H616_TPR10=0x2f0007
>  CONFIG_DRAM_SUN50I_H616_TPR11=0x
>  CONFIG_DRAM_SUN50I_H616_TPR12=0xfedf7557
>  CONFIG_MACH_SUN50I_H616=y
> +CONFIG_SUNXI_DRAM_H616_DDR3_1333=y
>  CONFIG_R_I2C_ENABLE=y
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>  CONFIG_SPL_I2C=y
> 

Re: [PATCH 3/5] sunxi: H616: dram: split struct dram_para

[Jernej Škrabec]

Dne sreda, 07. junij 2023 ob 02:07:43 CEST je Andre Przywara napisal(a):
> Currently there is one DRAM parameter struct for the Allwinner H616 DRAM
> "driver". It contains many fields that are compile time constants
> (set by Kconfig variables), though there are also some fields that are
> probed and changed over the runtime of the DRAM initialisation.
> 
> Because of this mixture, the compiler cannot properly optimise the code
> for size, as it does not consider constant propagation in its full
> potential.
> 
> Help the compiler out by splitting that structure into two: one that only
> contains values known at compile time, and another one where the values
> will actually change. The former can then be declared "const", which will
> let the compiler fold its values directly into the code using it.
> 
> We also add "const" tags for some new "struct dram_config" pointers, to
> further increase code optimisation.
> To help the compiler optimise the code further, the definition of the
> now "const struct dram_para" has to happen at a file-global level, so
> move that part out of sunxi_dram_init().
> 
> That results in quite some code savings (almost 2KB), and helps to keep
> the code small with the LPDDR3 support added later.
> 
> Signed-off-by: Andre Przywara 

Nice trick. It could be used also in other DRAM drivers.

Reviewed-by: Jernej Skrabec 

Best regards,
Jernej

Re: [PATCH 2/5] sunxi: H616: dram: const-ify DRAM function parameters

[Jernej Škrabec]

Dne sreda, 07. junij 2023 ob 02:07:42 CEST je Andre Przywara napisal(a):
> There are quite some functions in the Allwinner H616 DRAM "driver", some
> of them actually change the parameters in the structure passed to them,
> but many are actually not.
> To increase the optimisation potential for the code, mark those functions
> that just read members of the passed dram_para struct as "const".
> This in itself does not decrease the code size, but lays the groundwork
> for future changes doing so.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Jernej Skrabec 

Best regards,
Jernej

Re: [PATCH 1/5] sunxi: dram: make MBUS configuration functions static

[Jernej Škrabec]

Dne sreda, 07. junij 2023 ob 02:07:41 CEST je Andre Przywara napisal(a):
> The usage of the C keyword "inline" seems to be a common
> misunderstanding: it's a *hint* only, and modern compilers will inline
> (or not) functions based on their own judgement and provided compiler
> options.
> So while marking functions as "inline" does not do much, missing the
> "static" keyword will force to compiler to spell out a version of the
> function for potential external callers, which actually increases the
> code size (though hopefully the linker will drop the function).
> 
> Change the "inline" attribute for the mbus_configure_port() functions in
> some Allwinner DRAM drivers to "static", so that the explicit version
> can actually be dropped from the object file, reducing the code size.
> 
> "static inline" has a use case in header files, where it avoids a warning
> if a .c file including this header does not use the particular function.
> In a .c file itself "static inline" is not useful otherwise, so just use
> static here as well.
> 
> Signed-off-by: Andre Przywara 

Nice catch! Could it be put into common functions? These functions look the
same. Anyway:

Reviewed-by: Jernej Skrabec 

Best regards,
Jernej

> ---
>  arch/arm/mach-sunxi/dram_sun50i_h6.c   |  3 ++-
>  arch/arm/mach-sunxi/dram_sun50i_h616.c |  2 +-
>  arch/arm/mach-sunxi/dram_sunxi_dw.c| 18 +-
>  3 files changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c 
> b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> index b332f3a3e4a..bff2e42513c 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> @@ -93,7 +93,8 @@ enum {
>   MBUS_QOS_HIGH,
>   MBUS_QOS_HIGHEST
>  };
> -inline void mbus_configure_port(u8 port,
> +
> +static void mbus_configure_port(u8 port,
>   bool bwlimit,
>   bool priority,
>   u8 qos,
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c 
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index 1f9416d6eaf..02f6b2a06d4 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -31,7 +31,7 @@ enum {
>   MBUS_QOS_HIGHEST
>  };
>  
> -inline void mbus_configure_port(u8 port,
> +static void mbus_configure_port(u8 port,
>   bool bwlimit,
>   bool priority,
>   u8 qos,
> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c 
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> index 4af5922f334..9382d3d0be8 100644
> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> @@ -81,15 +81,15 @@ enum {
>   MBUS_QOS_HIGHEST
>  };
>  
> -static inline void mbus_configure_port(u8 port,
> -bool bwlimit,
> -bool priority,
> -u8 qos, /* MBUS_QOS_LOWEST .. 
> MBUS_QOS_HIGEST */
> -u8 waittime,/* 0 .. 0xf */
> -u8 acs, /* 0 .. 0xff */
> -u16 bwl0,   /* 0 .. 0x, 
> bandwidth limit in MB/s */
> -u16 bwl1,
> -u16 bwl2)
> +static void mbus_configure_port(u8 port,
> + bool bwlimit,
> + bool priority,
> + u8 qos, /* MBUS_QOS_LOWEST .. 
> MBUS_QOS_HIGEST */
> + u8 waittime,/* 0 .. 0xf */
> + u8 acs, /* 0 .. 0xff */
> + u16 bwl0,   /* 0 .. 0x, bandwidth limit 
> in MB/s */
> + u16 bwl1,
> + u16 bwl2)
>  {
>   struct sunxi_mctl_com_reg * const mctl_com =
>   (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
> 

Re: [PATCH 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization

[Andre Przywara]

On Fri, 9 Jun 2023 13:16:00 -0600
Sam Edwards  wrote:

Hi Sam,

> I've applied most of this feedback (most of which comes as a relief; I 
> dislike inventing names for mystery bits) in preparation to send a v2, 
> but had two questions:
> 
> On 6/9/23 04:13, Andre Przywara wrote:
> >> The new comments and function name are not from any official source,
> >> but are updated to mirror how the Linux kernel sources treat this
> >> mystery magic bit. If we wanted to confirm that this speculation is
> >> correct, we could verify that SRAM-D is inaccessible whenever the
> >> bit is set, and then try clearing it again while the MUSB is in use
> >> to see what debris gets left behind in SRAM-D.
> >>
> >> This cleanup also adds a TODO comment about runtime discovery
> >> of the SYSCON base, per discussion with Andre.  
> > 
> > thanks for sending this, looks good. Some stylistic comments below.  
> 
> I take it that this (in combination with your review on 1/2) means you 
> concur with my speculated purpose of the mystery bit. If so, I'd like to 

Oh, but why mystery bit? The A20 manual [1] spells that out:
Offset: 0x4 | SRAM_CTRL_REG1
...
Bit 0: R/W, default 0x0: SRAMD_MAP: SRAM D Area Config:
 0: map to CPU/DMA
 1: map to USB0

So I am afraid you need to rephrase the commit message again ;-)

> rephrase the above paragraph in the commit message to:
> 
> """
> The new comments and function name are not from any official source,
> but are updated to mirror how the Linux kernel sources treat this
> mystery magic bit. This also reflects what's been observed on actual
> hardware: SRAM-D is inaccessible by the CPU when the bit is set, and
> the MUSB unit crashes when this bit is cleared while USB is in use,
> leaving behind debris in SRAM-D from its use as a "scratch space."
> """
> 
> Does this accurately reflect what you've seen, particularly (especially) 
> that last line, or should I end the commentary at "is in use."?

We mostly gave up on finding 100% proof for everything, especially in
U-Boot there is more pragmatic approach (check the DRAM controller init
code): it if works and the BSP code does it like this, it's good to go.

I confirmed that setting this bit before calling "ums" makes the
difference between the gadget appearing on the other end or not. I did
not turn it off while the gadget was in literal use - which is tricky
to pull off anyway, since you don't have a prompt while a gadget is
running.

So while it's honourable to make sure that this is correct, there is no
real need to provide mathematical proof for those bits, especially if
they have been working over years now ;-) 

> > I think we should use "non-net" commenting style, with the "/*" on a line
> > on its own.  
> 
> This seems to be an obscure term of art, and searching "non-net comment" 
> and "non-net style" on Google isn't finding me any style guide or set of 
> rules to check against. (Amusingly: if I search for the "net" style, I 
> get a lot of .NET suggestions.)

Ah, sorry, I somewhat made this term up, apparently in a non-Google
compatible way ;-) The Linux kernel recommends this "/* on a line of its
own" commenting style, but inside the net/ folder the rules are slightly
different:

https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting

Hope that helps!

Cheers,
Andre


> The main thing I'm trying to figure out is if it also demands */ on its 
> own line, which I would intuitively think makes sense (it does look 
> better to me that way), but I'm unsure if your lack of critique at the 
> closing side of my multiline comments means you would prefer:
> /*
>   * A block of text that's long enough to become a
>   * multiline comment and ends up looking like this */
> 
> Thanks for your quick and thorough feedback,
> Sam

Re: [PATCH 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization

[Sam Edwards]

Hi Andre,

I've applied most of this feedback (most of which comes as a relief; I 
dislike inventing names for mystery bits) in preparation to send a v2, 
but had two questions:


On 6/9/23 04:13, Andre Przywara wrote:

The new comments and function name are not from any official source,
but are updated to mirror how the Linux kernel sources treat this
mystery magic bit. If we wanted to confirm that this speculation is
correct, we could verify that SRAM-D is inaccessible whenever the
bit is set, and then try clearing it again while the MUSB is in use
to see what debris gets left behind in SRAM-D.

This cleanup also adds a TODO comment about runtime discovery
of the SYSCON base, per discussion with Andre.


thanks for sending this, looks good. Some stylistic comments below.


I take it that this (in combination with your review on 1/2) means you 
concur with my speculated purpose of the mystery bit. If so, I'd like to 
rephrase the above paragraph in the commit message to:


"""
The new comments and function name are not from any official source,
but are updated to mirror how the Linux kernel sources treat this
mystery magic bit. This also reflects what's been observed on actual
hardware: SRAM-D is inaccessible by the CPU when the bit is set, and
the MUSB unit crashes when this bit is cleared while USB is in use,
leaving behind debris in SRAM-D from its use as a "scratch space."
"""

Does this accurately reflect what you've seen, particularly (especially) 
that last line, or should I end the commentary at "is in use."?



I think we should use "non-net" commenting style, with the "/*" on a line
on its own.


This seems to be an obscure term of art, and searching "non-net comment" 
and "non-net style" on Google isn't finding me any style guide or set of 
rules to check against. (Amusingly: if I search for the "net" style, I 
get a lot of .NET suggestions.)


The main thing I'm trying to figure out is if it also demands */ on its 
own line, which I would intuitively think makes sense (it does look 
better to me that way), but I'm unsure if your lack of critique at the 
closing side of my multiline comments means you would prefer:

/*
 * A block of text that's long enough to become a
 * multiline comment and ends up looking like this */

Thanks for your quick and thorough feedback,
Sam

Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command

[Xavier Drudis Ferran]

Sorry, I replied to Marek only but meant to reply to all.

El Fri, Jun 09, 2023 at 03:20:33AM +0200, Marek Vasut deia:

> > No. Well, in some tests yes and some no, but I got the error in all cases.
> 
> This is doubtful. It is mandatory to run 'usb start' or 'usb reset' before
> you would get any meaningful result out of 'usb info'. Without either, you
> would get 'USB is stopped.' message. Could it be there are some extra
> scripts in your environment that manipulate the USB ?
>

I saw usb_boootdev_hunt() calls usb_init() in drivers/usb/host/usb_bootdev.c

But maybe I don't get that called and it's really something silly in
my setup as you say later... Maybe it doesn't get called unless it
finds nothing else useful to boot.

> 
> Can you test with stock U-Boot ?
>

I don't know. I'll see if I have time ...
I'd rather read the code to understand what's the condition for finding 
bootdevices...

> Can you test with another USB stick, i.e. is the issue specific to this USB
> stick ?
>

I could test this, yes.

> Is the issue specific to this partition layout of this USB stick, i.e. if
> you clone (dd if=... of=...) the content of the USB stick to another USB
> stick, does the error still occur.
>

I'll try to partition and flash a new USB.

> [...]
> 
> > Model: Radxa ROCK Pi 4B
> > Net:   eth0: ethernet@fe30
> > Hit any key to stop autoboot:  2  1  0
> > rockchip_pcie pcie@f800: PCIe link training gen1 timeout!
> > Bus usb@fe38: USB EHCI 1.00
> > Bus usb@fe3c: USB EHCI 1.00
> > Bus usb@fe80: Register 2000140 NbrPorts 2
> > Starting the controller
> > USB XHCI 1.10
> > Bus usb@fe90: Register 2000140 NbrPorts 2
> > Starting the controller
> > USB XHCI 1.10
> > scanning bus usb@fe38 for devices... 1 USB Device(s) found
> > scanning bus usb@fe3c for devices... 2 USB Device(s) found
> > scanning bus usb@fe80 for devices... 1 USB Device(s) found
> > scanning bus usb@fe90 for devices... 1 USB Device(s) found
> > rockchip_pcie pcie@f800: failed to find ep-gpios property
> > ethernet@fe30 Waiting for PHY auto negotiation to complete. 
> > TIMEOUT !
> > Could not initialize PHY ethernet@fe30
> > rockchip_pcie pcie@f800: failed to find ep-gpios property
> > ethernet@fe30 Waiting for PHY auto negotiation to complete. 
> > TIMEOUT !
> > Could not initialize PHY ethernet@fe30
> 
> Is this some $preboot script which initializes your hardware ?
>

Mmm... yes, I used to have it... I thought not in this test, but I'd better 
recheck

Anyway, one should be allowed to stop the boot, call usb start and usb tree
and don't get a reset, shouldn't one?

> => printenv preboot
>

I'll send this later when I repeat the test. I'd like to find a
minimal test case or something...

> > => usb tree
> > USB device tree:
> >1  Hub (480 Mb/s, 0mA)
> >   u-boot EHCI Host Controller
> >1  Hub (480 Mb/s, 0mA)
> >|  u-boot EHCI Host Controller
> >|
> > uclass_id=64
> >|+-2  Mass Storage (480 Mb/s, 200mA)
> > TDK LoR TF10 07032B6B1D0ACB96
> > uclass_id=22
> > uclass_id=25
> >   "Synchronous Abort" handler, esr 0x9610, far 0x948
> > elr: 002157d4 lr : 002157d4 (reloc)
> > elr: f3f4f7d4 lr : f3f4f7d4
> 
> Take the u-boot (unstripped elf) which matches this binary, and run
> aarch64-...objdump -lSD on it, then search for the $lr value, see
> doc/develop/crash_dumps.rst for details. That should tell you where exactly
> the crash occurred. Where did it occur ?
>

I didn't do it exactly so, but from u-boot.map I gathered that it was
in cmd/usb.c and the fact that my patch fixed it implies the problem
is the functions usb_show_tree_graph() or usb_show_info() get called
recursively with null as a first parameter.

Now I don't have that u-boot.map anymore and would have to repeat the
experiment, to find out exactly as you say, so I won't do it right
now. But thanks, understood.

The reason usb_show_tree_graph() gets called with a null usb_device *
is that the code in cmd/usb.c for usb info and usb tree assumes
everything a UCLASS_MASS_STORAGE device can have as children are
devices with some usb_device in their dev_get_parent_priv().  It
carves out exceptions to this general rule for UCLASS_USB_EMUL and
UCLASS_BLK, but not for UCLASS_BOOTDEV. When it finds a child that is
UCLASS_BOOTDEV it happily recurses on it passing its parent_priv as
usb_device, but the bootdev code did not put any usb_device there,
it's null. So the first access causes a null pointer dereference.

I would have to wrap my mind around more code to start understanding
if it's better to give that UCLASS_BOOTDEV some usb_device as parent
priv data, or it is better to give USB devices that can be enumerated
for listing (usb tree or usb info) some RECURSIBLE flag that indicates
their priv parent data is reliably a usb_device.

So checking that the alledged 

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

[Tom Rini]

On Fri, Jun 09, 2023 at 12:03:06AM +0200, Marek Vasut wrote:

> The following changes since commit 0a8a4b86422650d6955a2382796089735453902d:
> 
>   Merge tag 'u-boot-amlogic-20230607' of 
> https://source.denx.de/u-boot/custodians/u-boot-amlogic (2023-06-07 12:17:06 
> -0400)
> 
> are available in the Git repository at:
> 
>   git://source.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to e10f96414934edaca958e4323f82149a030e56a4:
> 
>   usb: musb-new: sunxi: remove unused define (2023-06-08 21:57:01 +0200)
> 

I see I replied to the SH one twice, oops.  This has been applied to
u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/2] sunxi: H616: add LPDDR3 DRAM support

[Iun Cuim]

Signed-off-by: Mikhail Kalashnikov 

From: iuncuim 
>
> The H616 SoC has support for several types of DRAM: DDR3, LPDDR3,
> DDR4 and LPDDR4.
> At the moment, the driver only supports DDR3 memory.
> Let's extend the driver to support the LPDDR3 memory. All "magic"
> values obtained from the boot0.
> ---
>  .../include/asm/arch-sunxi/dram_sun50i_h616.h |   1 +
>  arch/arm/mach-sunxi/Kconfig   |  10 +-
>  arch/arm/mach-sunxi/dram_sun50i_h616.c| 215 --
>  arch/arm/mach-sunxi/dram_timings/Makefile |   1 +
>  .../arm/mach-sunxi/dram_timings/h616_lpddr3.c |  95 
>  5 files changed, 255 insertions(+), 67 deletions(-)
>  create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_lpddr3.c
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> index 6db869c098..bf4188fa89 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> @@ -148,6 +148,7 @@ check_member(sunxi_mctl_ctl_reg, unk_0x4240, 0x4240);
>  struct dram_para {
> u32 clk;
> enum sunxi_dram_type type;
> +   u8 phy_init[27];
> u8 cols;
> u8 rows;
> u8 ranks;
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 3ad37ef6ba..5ce82a955c 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -487,6 +487,14 @@ config SUNXI_DRAM_H6_DDR3_1333
> This option is the DDR3 timing used by the boot0 on H6 TV boxes
> which use a DDR3-1333 timing.
>
> +config SUNXI_DRAM_H616_LPDDR3
> +   bool "LPDDR3 DRAM chips on the H616 DRAM controller"
> +   select SUNXI_DRAM_LPDDR3
> +   depends on DRAM_SUN50I_H616
> +   ---help---
> +   This option is the LPDDR3 timing used by the stock boot0 by
> +   Allwinner.
> +
>  config SUNXI_DRAM_H616_DDR3_1333
> bool "DDR3-1333 boot0 timings on the H616 DRAM controller"
> select SUNXI_DRAM_DDR3
> @@ -1083,4 +1091,4 @@ config CHIP_DIP_SCAN
> select W1_GPIO
> select W1_EEPROM
> select W1_EEPROM_DS24XXX
> -   select CMD_EXTENSION
> \ No newline at end of file
> +   select CMD_EXTENSION
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> index 1f9416d6ea..d34b218ee5 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -227,13 +227,6 @@ static void mctl_set_addrmap(struct dram_para *para)
> mctl_ctl->addrmap[8] = 0x3F3F;
>  }
>
> -static const u8 phy_init[] = {
> -   0x07, 0x0b, 0x02, 0x16, 0x0d, 0x0e, 0x14, 0x19,
> -   0x0a, 0x15, 0x03, 0x13, 0x04, 0x0c, 0x10, 0x06,
> -   0x0f, 0x11, 0x1a, 0x01, 0x12, 0x17, 0x00, 0x08,
> -   0x09, 0x05, 0x18
> -};
> -
>  static void mctl_phy_configure_odt(struct dram_para *para)
>  {
> unsigned int val;
> @@ -263,19 +256,31 @@ static void mctl_phy_configure_odt(struct dram_para
> *para)
> writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x34c);
>
> val = para->dx_odt & 0x1f;
> -   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380);
> +   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> +   writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x380);
> +   else
> +   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x380);
> writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x384);
>
> val = (para->dx_odt >> 8) & 0x1f;
> -   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> +   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> +   writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> +   else
> +   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c0);
> writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x3c4);
>
> val = (para->dx_odt >> 16) & 0x1f;
> -   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400);
> +   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> +   writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x400);
> +   else
> +   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x400);
> writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x404);
>
> val = (para->dx_odt >> 24) & 0x1f;
> -   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440);
> +   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> +   writel_relaxed(0, SUNXI_DRAM_PHY0_BASE + 0x440);
> +   else
> +   writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x440);
> writel_relaxed(val, SUNXI_DRAM_PHY0_BASE + 0x444);
>
> dmb();
> @@ -793,31 +798,47 @@ static void
> mctl_phy_ca_bit_delay_compensation(struct dram_para *para)
> writel(val, SUNXI_DRAM_PHY0_BASE + 0x7e0);
> writel(val, SUNXI_DRAM_PHY0_BASE + 0x7f4);
>
> -   /* following configuration is DDR3 specific */
> -   val = (para->tpr10 >> 7) & 0x1e;
> -   if (para->tpr2 & 1) {
> -   writel(val, SUNXI_DRAM_PHY0_BASE + 0x794);
> - 

Re: [PATCH 1/2] sunxi: H616: add DRAM type selection

[Iun Cuim]

Signed-off-by: Mikhail Kalashnikov 

сб, 3 июн. 2023 г. в 16:55, Mikhail Kalashnikov :

> From: iuncuim 
>
> Allwinner H616 SoC supports several types of DRAM memory. To further
> integrate other types of memory, we need to add this delimitation.
> ---
>  arch/arm/mach-sunxi/Kconfig   | 12 ++--
>  arch/arm/mach-sunxi/dram_timings/Makefile |  3 +--
>  configs/orangepi_zero2_defconfig  |  1 +
>  configs/x96_mate_defconfig|  1 +
>  4 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 6dcbb096f7..3ad37ef6ba 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -442,7 +442,7 @@ config ARM_BOOT_HOOK_RMR
> This allows both the SPL and the U-Boot proper to be entered in
> either mode and switch to AArch64 if needed.
>
> -if SUNXI_DRAM_DW || DRAM_SUN50I_H6
> +if SUNXI_DRAM_DW || DRAM_SUN50I_H6 || DRAM_SUN50I_H616
>  config SUNXI_DRAM_DDR3
> bool
>
> @@ -487,6 +487,14 @@ config SUNXI_DRAM_H6_DDR3_1333
> This option is the DDR3 timing used by the boot0 on H6 TV boxes
> which use a DDR3-1333 timing.
>
> +config SUNXI_DRAM_H616_DDR3_1333
> +   bool "DDR3-1333 boot0 timings on the H616 DRAM controller"
> +   select SUNXI_DRAM_DDR3
> +   depends on DRAM_SUN50I_H616
> +   ---help---
> +   This option is the DDR3 timing used by the boot0 on H616 TV boxes
> +   which use a DDR3-1333 timing.
> +
>  config SUNXI_DRAM_DDR2_V3S
> bool "DDR2 found in V3s chip"
> select SUNXI_DRAM_DDR2
> @@ -1075,4 +1083,4 @@ config CHIP_DIP_SCAN
> select W1_GPIO
> select W1_EEPROM
> select W1_EEPROM_DS24XXX
> -   select CMD_EXTENSION
> +   select CMD_EXTENSION
> \ No newline at end of file
> diff --git a/arch/arm/mach-sunxi/dram_timings/Makefile
> b/arch/arm/mach-sunxi/dram_timings/Makefile
> index 39a8756c29..4d78c04c9a 100644
> --- a/arch/arm/mach-sunxi/dram_timings/Makefile
> +++ b/arch/arm/mach-sunxi/dram_timings/Makefile
> @@ -3,5 +3,4 @@ obj-$(CONFIG_SUNXI_DRAM_LPDDR3_STOCK)   += lpddr3_stock.o
>  obj-$(CONFIG_SUNXI_DRAM_DDR2_V3S)  += ddr2_v3s.o
>  obj-$(CONFIG_SUNXI_DRAM_H6_LPDDR3) += h6_lpddr3.o
>  obj-$(CONFIG_SUNXI_DRAM_H6_DDR3_1333)  += h6_ddr3_1333.o
> -# currently only DDR3 is supported on H616
> -obj-$(CONFIG_MACH_SUN50I_H616) += h616_ddr3_1333.o
> +obj-$(CONFIG_SUNXI_DRAM_H616_DDR3_1333)+= h616_ddr3_1333.o
> diff --git a/configs/orangepi_zero2_defconfig
> b/configs/orangepi_zero2_defconfig
> index 6cb942f511..e38cc20ac7 100644
> --- a/configs/orangepi_zero2_defconfig
> +++ b/configs/orangepi_zero2_defconfig
> @@ -7,6 +7,7 @@ CONFIG_DRAM_SUN50I_H616_DX_DRI=0x0e0e0e0e
>  CONFIG_DRAM_SUN50I_H616_CA_DRI=0x0e0e
>  CONFIG_DRAM_SUN50I_H616_TPR10=0xf83438
>  CONFIG_MACH_SUN50I_H616=y
> +CONFIG_SUNXI_DRAM_H616_DDR3_1333=y
>  CONFIG_R_I2C_ENABLE=y
>  CONFIG_SPL_SPI_SUNXI=y
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> diff --git a/configs/x96_mate_defconfig b/configs/x96_mate_defconfig
> index aedb327702..2a326bf202 100644
> --- a/configs/x96_mate_defconfig
> +++ b/configs/x96_mate_defconfig
> @@ -11,6 +11,7 @@ CONFIG_DRAM_SUN50I_H616_TPR10=0x2f0007
>  CONFIG_DRAM_SUN50I_H616_TPR11=0x
>  CONFIG_DRAM_SUN50I_H616_TPR12=0xfedf7557
>  CONFIG_MACH_SUN50I_H616=y
> +CONFIG_SUNXI_DRAM_H616_DDR3_1333=y
>  CONFIG_R_I2C_ENABLE=y
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>  CONFIG_SPL_I2C=y
> --
> 2.40.1
>
>

[PATCH v2] phy: phy-imx8mq-usb: add vbus regulator support

[Tim Harvey]

Add support for enabling and disabling vbus-supply regulator found
on several imx8mp boards in the usb3_phy0 and usb3_phy1 nodes.

Signed-off-by: Tim Harvey 
Reviewed-by: Adam Ford 
---
v2:
 - protect ret with __maybe_unused in case CONFIG_CLK and
   CONFIG_DM_REGULATOR not defined
 - add error prints on failures
 - add Adam's rb tag
---
 drivers/phy/phy-imx8mq-usb.c | 32 ++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-imx8mq-usb.c b/drivers/phy/phy-imx8mq-usb.c
index 69f01de55538..53099436b04b 100644
--- a/drivers/phy/phy-imx8mq-usb.c
+++ b/drivers/phy/phy-imx8mq-usb.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define PHY_CTRL0  0x0
 #define PHY_CTRL0_REF_SSP_EN   BIT(2)
@@ -81,6 +82,7 @@ struct imx8mq_usb_phy {
 #endif
void __iomem *base;
enum imx8mpq_phy_type type;
+   struct udevice *vbus_supply;
 };
 
 static const struct udevice_id imx8mq_usb_phy_of_match[] = {
@@ -172,10 +174,10 @@ static int imx8mq_usb_phy_power_on(struct phy *usb_phy)
 {
struct udevice *dev = usb_phy->dev;
struct imx8mq_usb_phy *imx_phy = dev_get_priv(dev);
+   __maybe_unused int ret;
u32 value;
 
 #if CONFIG_IS_ENABLED(CLK)
-   int ret;
ret = clk_enable(_phy->phy_clk);
if (ret) {
printf("Failed to enable usb phy clock\n");
@@ -183,6 +185,14 @@ static int imx8mq_usb_phy_power_on(struct phy *usb_phy)
}
 #endif
 
+   if (CONFIG_IS_ENABLED(DM_REGULATOR) && imx_phy->vbus_supply) {
+   ret = regulator_set_enable(imx_phy->vbus_supply, true);
+   if (ret) {
+   pr_err("Failed to enable VBUS regulator: %d\n", ret);
+   return ret;
+   }
+   }
+
/* Disable rx term override */
value = readl(imx_phy->base + PHY_CTRL6);
value &= ~PHY_CTRL6_RXTERM_OVERRIDE_SEL;
@@ -195,6 +205,7 @@ static int imx8mq_usb_phy_power_off(struct phy *usb_phy)
 {
struct udevice *dev = usb_phy->dev;
struct imx8mq_usb_phy *imx_phy = dev_get_priv(dev);
+   __maybe_unused int ret;
u32 value;
 
/* Override rx term to be 0 */
@@ -206,6 +217,14 @@ static int imx8mq_usb_phy_power_off(struct phy *usb_phy)
clk_disable(_phy->phy_clk);
 #endif
 
+   if (CONFIG_IS_ENABLED(DM_REGULATOR) && imx_phy->vbus_supply) {
+   ret = regulator_set_enable(imx_phy->vbus_supply, false);
+   if (ret) {
+   pr_err("Failed to disable VBUS regulator: %d\n", ret);
+   return ret;
+   }
+   }
+
return 0;
 }
 
@@ -224,6 +243,7 @@ struct phy_ops imx8mq_usb_phy_ops = {
 int imx8mq_usb_phy_probe(struct udevice *dev)
 {
struct imx8mq_usb_phy *priv = dev_get_priv(dev);
+   __maybe_unused int ret;
 
priv->type = dev_get_driver_data(dev);
priv->base = dev_read_addr_ptr(dev);
@@ -232,7 +252,6 @@ int imx8mq_usb_phy_probe(struct udevice *dev)
return -EINVAL;
 
 #if CONFIG_IS_ENABLED(CLK)
-   int ret;
 
/* Assigned clock already set clock */
ret = clk_get_by_name(dev, "phy", >phy_clk);
@@ -242,6 +261,15 @@ int imx8mq_usb_phy_probe(struct udevice *dev)
}
 #endif
 
+   if (CONFIG_IS_ENABLED(DM_REGULATOR)) {
+   ret = device_get_supply_regulator(dev, "vbus-supply",
+ >vbus_supply);
+   if (ret && ret != -ENOENT) {
+   pr_err("Failed to get VBUS regulator: %d\n", ret);
+   return ret;
+   }
+   }
+
return 0;
 }
 
-- 
2.25.1

[PATCH] board: gateworks: venice: add imx8mp-gw7905-2x support

[Tim Harvey]

The Gateworks imx8mp-venice-gw7905-2x consists of a SOM + baseboard.

The GW702x SOM contains the following:
 - i.MX8M Plus SoC
 - LPDDR4 memory
 - eMMC Boot device
 - Gateworks System Controller (GSC) with integrated EEPROM, button
   controller, and ADC's
 - PMIC
 - SOM connector providing:
  - eQoS GbE MII
  - 1x SPI
  - 2x I2C
  - 4x UART
  - 2x USB 3.0
  - 1x PCI
  - 1x SDIO (4-bit 3.3V)
  - 1x SDIO (4-bit 3.3V/1.8V)
  - GPIO

The GW7905 Baseboard contains the following:
 - GPS
 - microSD
 - off-board I/O connector with I2C, SPI, GPIO
 - EERPOM
 - PCIe clock generator
 - 1x full-length miniPCIe socket with PCI/USB3 (via mux) and USB2.0
 - 1x half-length miniPCIe socket with USB2.0 and USB3.0
 - USB 3.0 HUB
 - USB Type-C with USB PD Sink capability and peripheral support
 - USB Type-C with USB 3.0 host support

Signed-off-by: Tim Harvey 
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/imx8mp-venice-gw702x-u-boot.dtsi |  12 +
 arch/arm/dts/imx8mp-venice-gw702x.dtsi| 587 ++
 .../dts/imx8mp-venice-gw7905-2x-u-boot.dtsi   |  51 ++
 arch/arm/dts/imx8mp-venice-gw7905-2x.dts  |  28 +
 arch/arm/dts/imx8mp-venice-gw7905.dtsi| 309 +
 board/gateworks/venice/eeprom.c   |   5 +
 board/gateworks/venice/lpddr4_timing.h|   1 +
 board/gateworks/venice/lpddr4_timing_imx8mp.c | 532 
 board/gateworks/venice/spl.c  |  19 +-
 configs/imx8mp_venice_defconfig   |   2 +-
 11 files changed, 1544 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/dts/imx8mp-venice-gw702x-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mp-venice-gw702x.dtsi
 create mode 100644 arch/arm/dts/imx8mp-venice-gw7905-2x-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mp-venice-gw7905-2x.dts
 create mode 100644 arch/arm/dts/imx8mp-venice-gw7905.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa6065..909a4d23f4a7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1016,6 +1016,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mp-phyboard-pollux-rdk.dtb \
imx8mp-venice.dtb \
imx8mp-venice-gw74xx.dtb \
+   imx8mp-venice-gw7905-2x.dtb \
imx8mp-verdin-wifi-dev.dtb \
imx8mq-pico-pi.dtb \
imx8mq-kontron-pitx-imx8m.dtb \
diff --git a/arch/arm/dts/imx8mp-venice-gw702x-u-boot.dtsi 
b/arch/arm/dts/imx8mp-venice-gw702x-u-boot.dtsi
new file mode 100644
index ..b9e3db7de937
--- /dev/null
+++ b/arch/arm/dts/imx8mp-venice-gw702x-u-boot.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2023 Gateworks Corporation
+ */
+
+#include "imx8mp-venice-u-boot.dtsi"
+
+ {
+   /delete-property/ assigned-clocks;
+   /delete-property/ assigned-clock-parents;
+   /delete-property/ assigned-clock-rates;
+};
diff --git a/arch/arm/dts/imx8mp-venice-gw702x.dtsi 
b/arch/arm/dts/imx8mp-venice-gw702x.dtsi
new file mode 100644
index ..560c68e4da6d
--- /dev/null
+++ b/arch/arm/dts/imx8mp-venice-gw702x.dtsi
@@ -0,0 +1,587 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2023 Gateworks Corporation
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   aliases {
+   ethernet0 = 
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0x0 0x4000 0 0x8000>;
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+
+   key-user-pb {
+   label = "user_pb";
+   gpios = < 2 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   key-user-pb1x {
+   label = "user_pb1x";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <0>;
+   };
+
+   key-erased {
+   label = "key_erased";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <1>;
+   };
+
+   key-eeprom-wp {
+   label = "eeprom_wp";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <2>;
+   };
+
+   key-tamper {
+   label = "tamper";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <5>;
+   };
+
+   switch-hold {
+   label = "switch_hold";
+   linux,code = ;
+   interrupt-parent = <>;
+   interrupts = <7>;
+   };
+   };
+};
+
+_0 {
+   cpu-supply = <_reg>;
+};
+
+_1 {
+   cpu-supply = <_reg>;
+};
+
+_2 {
+   cpu-supply = <_reg>;
+};
+
+_3 {
+   cpu-supply = <_reg>;
+};
+
+ {
+   pinctrl-names = 

[PATCH] board: gateworks: venice: display dram speed

[Tim Harvey]

Display dram speed during configuration.

Signed-off-by: Tim Harvey 
---
 board/gateworks/venice/spl.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c
index 50056da3ee0f..c81498e830d6 100644
--- a/board/gateworks/venice/spl.c
+++ b/board/gateworks/venice/spl.c
@@ -83,9 +83,12 @@ static void spl_dram_init(int size)
 
printf("DRAM: LPDDR4 ");
if (size > 512)
-   printf("%d GiB\n", size / 1024);
+   printf("%d GiB", size / 1024);
else
-   printf("%d MiB\n", size);
+   printf("%d MiB", size);
+   printf(" %dMT/s %dMHz\n",
+  dram_timing->fsp_msg[0].drate,
+  dram_timing->fsp_msg[0].drate / 2);
ddr_init(dram_timing);
 }
 
-- 
2.25.1

[PATCH] board: gateworks: venice: assume emmc device for USB boot

[Tim Harvey]

When booting from USB (SDP) setup firmware-update environment
for emmc device.

Signed-off-by: Tim Harvey 
---
 board/gateworks/venice/venice.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/gateworks/venice/venice.c b/board/gateworks/venice/venice.c
index 803582c55b99..3067480e6ac7 100644
--- a/board/gateworks/venice/venice.c
+++ b/board/gateworks/venice/venice.c
@@ -155,6 +155,7 @@ int board_late_init(void)
bootdev = 2;
break;
default:
+   bootdev = 2; /* assume SDHC3 (eMMC) if booting over SDP */
break;
}
if (bootdev != -1)
-- 
2.25.1

Re: [PULL] u-boot-sh/next_soc/v3x

[Tom Rini]

On Thu, Jun 08, 2023 at 11:32:22PM +0200, Marek Vasut wrote:

> The following changes since commit 3aa4fb12f4abd31bce7fe6294dd47fd0966a791a:
> 
>   Merge tag 'efi-next-20230608' of 
> https://source.denx.de/u-boot/custodians/u-boot-efi into next (2023-06-08 
> 11:19:27 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-sh.git next_soc/v3x
> 
> for you to fetch changes up to ed2f65f0105dacb98e5c4d2b435dd009de06c2d1:
> 
>   ARM: renesas: Add R8A77980 V3HSK board and CPLD code (2023-06-08 22:26:52 
> +0200)
> 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] phy: phy-imx8mq-usb: add vbus regulator support

[Tim Harvey]

On Thu, Jun 8, 2023 at 8:12 PM Adam Ford  wrote:
>
> On Thu, Jun 8, 2023 at 8:29 PM Tim Harvey  wrote:
> >
> > Add support for enabling and disabling vbus-supply regulator found
> > on several imx8mp boards in the usb3_phy0 and usb3_phy1 nodes.
> >
> > Without this I suspect U-Boot usb does not work on the following:
> >  - imx8mp-beacon-kit
>
> The Host-only port works on the Beacon board, but the dual-role, usb
> type-c port doesn't appear to have been impacted.  I am guessing it's
> due to the lack of a proper type-c driver. Despite that,  I think it's
> the right thing to do for this platform, and I'll give some feedback
> below.

Adam,

Is perhaps the pca6416 gpio0 pulled up externally or defaults to
driving high? If you put a print in regulator_set_enable() you'll see
that reg_usb1_host_vbus never gets called without this patch so I
don't see how a device on that host would work.

Right - the type-c doesn't work because there is no driver for the
ptn5110. Even if there were I'm not clear what the right mechanism is
for calling out from the dwc3 driver to see what role the usb
controller should be. I don't believe U-Boot already has any common
method for usb host controllers to ask for role other than reading the
dr_mode prop. Perhaps there needs to be a usb connector uclass added
with a global function to check the role that various typec controller
drivers could use. I have some imx8mp boards that have OTG connectors
where I need to check the USB_ID gpio for the role which can be
handled that way as well.

If you did want to default your type-c to host mode until such support
exists you can add 'dr_mode = "host"' to the usb_dwc3_0 node in your
imx8mp-beacon-kit-u-boot.dtsi:

>
> >  - imx8mp-msc-sm2s
> >  - imx8mp-verdin-wifi-dev
> >
>
> Reviewed-by: Adam Ford 
>
> > Signed-off-by: Tim Harvey 
> > ---
> >  drivers/phy/phy-imx8mq-usb.c | 24 ++--
> >  1 file changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/phy/phy-imx8mq-usb.c b/drivers/phy/phy-imx8mq-usb.c
> > index 69f01de55538..eed9c07848f4 100644
> > --- a/drivers/phy/phy-imx8mq-usb.c
> > +++ b/drivers/phy/phy-imx8mq-usb.c
> > @@ -14,6 +14,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #define PHY_CTRL0  0x0
> >  #define PHY_CTRL0_REF_SSP_EN   BIT(2)
> > @@ -81,6 +82,7 @@ struct imx8mq_usb_phy {
> >  #endif
> > void __iomem *base;
> > enum imx8mpq_phy_type type;
> > +   struct udevice *vbus_supply;
> >  };
> >
> >  static const struct udevice_id imx8mq_usb_phy_of_match[] = {
> > @@ -173,9 +175,9 @@ static int imx8mq_usb_phy_power_on(struct phy *usb_phy)
> > struct udevice *dev = usb_phy->dev;
> > struct imx8mq_usb_phy *imx_phy = dev_get_priv(dev);
> > u32 value;
> > +   int ret;
>
> In the unlikely event that neither CONFIG_CLK nor CONFIG_DM_REGULATOR
> is configured, will defining ret here throw a compiler warning that
> it's unused? I wonder if __maybe_unused attribute would be permissible
> here or if this should be inside an #if statement.
>

good point, I'll add for v2

> >
> >  #if CONFIG_IS_ENABLED(CLK)
> > -   int ret;
> > ret = clk_enable(_phy->phy_clk);
> > if (ret) {
> > printf("Failed to enable usb phy clock\n");
> > @@ -183,6 +185,12 @@ static int imx8mq_usb_phy_power_on(struct phy *usb_phy)
> > }
> >  #endif
> >
> > +   if (CONFIG_IS_ENABLED(DM_REGULATOR) && imx_phy->vbus_supply) {
> > +   ret = regulator_set_enable(imx_phy->vbus_supply, true);
> > +   if (ret)
>
> I am personally a fan of error messages.  There is an error message if
> the clock fails, so unless there is an objection, can we have one here
> too?  One was also added to the probe function.

ok, I'll add this for v2

>
> > +   return ret;
> > +   }
> > +
> > /* Disable rx term override */
> > value = readl(imx_phy->base + PHY_CTRL6);
> > value &= ~PHY_CTRL6_RXTERM_OVERRIDE_SEL;
> > @@ -206,6 +214,9 @@ static int imx8mq_usb_phy_power_off(struct phy *usb_phy)
> > clk_disable(_phy->phy_clk);
> >  #endif
> >
> > +   if (CONFIG_IS_ENABLED(DM_REGULATOR) && imx_phy->vbus_supply)
> > +   return regulator_set_enable(imx_phy->vbus_supply, false);
> > +
> > return 0;
> >  }
> >
> > @@ -224,6 +235,7 @@ struct phy_ops imx8mq_usb_phy_ops = {
> >  int imx8mq_usb_phy_probe(struct udevice *dev)
> >  {
> > struct imx8mq_usb_phy *priv = dev_get_priv(dev);
> > +   int ret;
>
> Same comment as above regarding whether or not this might be unused.

yep - will address.

Thanks for the review!

Tim

[PATCH 2/2] renesas: rcar3: Load the correct device tree

[Detlev Casanova]

The Renesas R-Car Gen3 H3e (Starter Kit Premier) uses a different
device tree than the default one.

This uses the sysinfo's board id to determine if the board needs a
specific device tree.

Signed-off-by: Detlev Casanova 
---
 board/renesas/ulcb/ulcb.c| 34 ++
 configs/rcar3_ulcb_defconfig |  1 +
 2 files changed, 35 insertions(+)

diff --git a/board/renesas/ulcb/ulcb.c b/board/renesas/ulcb/ulcb.c
index 1477750f921..3e2fe3a3ca9 100644
--- a/board/renesas/ulcb/ulcb.c
+++ b/board/renesas/ulcb/ulcb.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 
+#include "../../../drivers/sysinfo/rcar3.h"
+
 DECLARE_GLOBAL_DATA_PTR;
 
 #define DVFS_MSTP926   BIT(26)
@@ -65,6 +67,38 @@ int board_init(void)
return 0;
 }
 
+int misc_init_r(void)
+{
+   struct udevice *dev;
+   int board_id;
+   int ret = sysinfo_get();
+if (ret) {
+   debug("Cannot get sysinfo: %d\n", ret);
+   return 0;
+   }
+
+   ret = sysinfo_detect(dev);
+   if (ret) {
+   debug("Cannot detect sysinfo: %d\n", ret);
+   return 0;
+   }
+
+   ret = sysinfo_get_int(dev,
+   SYSINFO_ID_BOARD_MODEL,
+   _id);
+
+   if (ret) {
+   debug("Cannot get sysinfo int: %d\n", ret);
+   return 0;
+   }
+
+   if (board_id == BOARD_STARTER_KIT_PRE) {
+   env_set("fdtfile", "renesas/r8a779m1-ulcb.dtb");
+   }
+
+   return 0;
+}
+
 #ifdef CONFIG_MULTI_DTB_FIT
 int board_fit_config_name_match(const char *name)
 {
diff --git a/configs/rcar3_ulcb_defconfig b/configs/rcar3_ulcb_defconfig
index b8fdb5e3826..752d33d77ec 100644
--- a/configs/rcar3_ulcb_defconfig
+++ b/configs/rcar3_ulcb_defconfig
@@ -111,3 +111,4 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_STORAGE=y
+CONFIG_MISC_INIT_R=y
-- 
2.39.3

[PATCH 1/2] renesas: rcar3: Expose the board id in sysinfo

[Detlev Casanova]

This is a preparation commit for selecting the correct device tree name
to be loaded depending on the board id.

Signed-off-by: Detlev Casanova 
---
 drivers/sysinfo/rcar3.c | 31 ++-
 drivers/sysinfo/rcar3.h | 21 +
 2 files changed, 39 insertions(+), 13 deletions(-)
 create mode 100644 drivers/sysinfo/rcar3.h

diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c
index 7b127986da7..4252f8d452c 100644
--- a/drivers/sysinfo/rcar3.c
+++ b/drivers/sysinfo/rcar3.c
@@ -7,24 +7,12 @@
 #include 
 #include 
 #include 
-#include 
+#include "rcar3.h"
 
 #define BOARD_CODE_MASK0xF8
 #define BOARD_REV_MASK 0x07
 #define BOARD_CODE_SHIFT   0x03
 
-#define BOARD_SALVATOR_X   0x0
-#define BOARD_KRIEK0x1
-#define BOARD_STARTER_KIT  0x2
-#define BOARD_EAGLE0x3
-#define BOARD_SALVATOR_XS  0x4
-#define BOARD_CONDOR   0x6
-#define BOARD_DRAAK0x7
-#define BOARD_EBISU0x8
-#define BOARD_STARTER_KIT_PRE  0xB
-#define BOARD_EBISU_4D 0xD
-#define BOARD_CONDOR_I 0x10
-
 /**
  * struct sysinfo_rcar_priv - sysinfo private data
  * @boardname: board model and revision
@@ -32,6 +20,7 @@
  */
 struct sysinfo_rcar_priv {
charboardmodel[64];
+   u8  board_id;
u8  val;
 };
 
@@ -42,6 +31,19 @@ static int sysinfo_rcar_detect(struct udevice *dev)
return priv->val == 0xff;
 }
 
+static int sysinfo_rcar_get_int(struct udevice *dev, int id, int *val)
+{
+   struct sysinfo_rcar_priv *priv = dev_get_priv(dev);
+
+   switch (id) {
+   case SYSINFO_ID_BOARD_MODEL:
+   *val = priv->board_id;
+   return 0;
+   default:
+   return -EINVAL;
+   };
+}
+
 static int sysinfo_rcar_get_str(struct udevice *dev, int id, size_t size, char 
*val)
 {
struct sysinfo_rcar_priv *priv = dev_get_priv(dev);
@@ -59,6 +61,7 @@ static int sysinfo_rcar_get_str(struct udevice *dev, int id, 
size_t size, char *
 static const struct sysinfo_ops sysinfo_rcar_ops = {
.detect = sysinfo_rcar_detect,
.get_str = sysinfo_rcar_get_str,
+   .get_int = sysinfo_rcar_get_int,
 };
 
 static void sysinfo_rcar_parse(struct sysinfo_rcar_priv *priv)
@@ -68,6 +71,8 @@ static void sysinfo_rcar_parse(struct sysinfo_rcar_priv *priv)
bool salvator_xs = false;
bool ebisu_4d = false;
bool condor_i = false;
+
+   priv->board_id = board_id;
char rev_major = '?';
char rev_minor = '?';
 
diff --git a/drivers/sysinfo/rcar3.h b/drivers/sysinfo/rcar3.h
new file mode 100644
index 000..21ae918d9bb
--- /dev/null
+++ b/drivers/sysinfo/rcar3.h
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Detlev Casanova 
+ */
+
+#include 
+
+#define BOARD_SALVATOR_X   0x0
+#define BOARD_KRIEK0x1
+#define BOARD_STARTER_KIT  0x2
+#define BOARD_EAGLE0x3
+#define BOARD_SALVATOR_XS  0x4
+#define BOARD_CONDOR   0x6
+#define BOARD_DRAAK0x7
+#define BOARD_EBISU0x8
+#define BOARD_STARTER_KIT_PRE  0xB
+#define BOARD_EBISU_4D 0xD
+#define BOARD_CONDOR_I 0x10
+
+
+
-- 
2.39.3

[PATCH 0/2] rcar: Select the correct device tree

[Detlev Casanova]

The R-Car Starter Kit Premier(H3e WS3.0) uses the r8a779m1-ulcb.dtb.
As u-boot can detect the board id, let's use this to set the correct
device tree for that board when using pxe.

Detlev Casanova (2):
  renesas: rcar3: Expose the board id in sysinfo
  renesas: rcar3: Load the correct device tree

 board/renesas/ulcb/ulcb.c| 34 ++
 configs/rcar3_ulcb_defconfig |  1 +
 drivers/sysinfo/rcar3.c  | 31 ++-
 drivers/sysinfo/rcar3.h  | 21 +
 4 files changed, 74 insertions(+), 13 deletions(-)
 create mode 100644 drivers/sysinfo/rcar3.h

-- 
2.39.3

[PATCH] renesas: rcar: Apply ATF overlay for reserved-memory

[Detlev Casanova]

The function fdtdec_board_setup() is called early and adds the overlay
from ATF to the u-boot device tree. That is necessary so that u-boot
doesn't use reserved memory.

Linux also needs to know about that reserved memory so the overlay from
ATF needs to be aplied on the linux device tree as well.

This commit makes sure that the ATF overlay is applied to both device trees.

Signed-off-by: Detlev Casanova 
---
 board/renesas/rcar-common/common.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/board/renesas/rcar-common/common.c 
b/board/renesas/rcar-common/common.c
index f38453af82c..f976c99028a 100644
--- a/board/renesas/rcar-common/common.c
+++ b/board/renesas/rcar-common/common.c
@@ -25,12 +25,17 @@ extern u64 rcar_atf_boot_args[];
 
 #define FDT_RPC_PATH   "/soc/spi@ee20"
 
-int fdtdec_board_setup(const void *fdt_blob)
+static void apply_atf_overlay(void *fdt_blob)
 {
void *atf_fdt_blob = (void *)(rcar_atf_boot_args[1]);
 
if (fdt_magic(atf_fdt_blob) == FDT_MAGIC)
-   fdt_overlay_apply_node((void *)fdt_blob, 0, atf_fdt_blob, 0);
+   fdt_overlay_apply_node(fdt_blob, 0, atf_fdt_blob, 0);
+}
+
+int fdtdec_board_setup(const void *fdt_blob)
+{
+   apply_atf_overlay((void *)fdt_blob);
 
return 0;
 }
@@ -159,6 +164,7 @@ static void update_rpc_status(void *blob)
 
 int ft_board_setup(void *blob, struct bd_info *bd)
 {
+   apply_atf_overlay(blob);
scrub_duplicate_memory(blob);
update_rpc_status(blob);
 
-- 
2.39.3

[PATCH 3/3] arm: dts: licheepi-nano: enable usb device mode

[路辉]

>From fff53ba354c8eca33cb9901888778420db637073 Mon Sep 17 00:00:00 2001
From: Lu Hui 
Date: Fri, 9 Jun 2023 22:05:53 +0800
Subject: [PATCH 3/3] arm: dts: licheepi-nano: enable usb device mode

---
 arch/arm/dts/suniv-f1c100s-licheepi-nano.dts | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
index 43896723a9..0ab6353727 100644
--- a/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
+++ b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
@@ -5,6 +5,7 @@

 /dts-v1/;
 #include "suniv-f1c100s.dtsi"
+#include 

 #include 

@@ -71,3 +72,17 @@
 usb0_id_det-gpios = < 4 2 GPIO_ACTIVE_HIGH>; /* PE2 */
 status = "okay";
 };
+
+_sram {
+status = "okay";
+};
+
+_otg {
+dr_mode = "peripheral";
+status = "okay";
+};
+
+ {
+usb0_id_det-gpio = < 4 2 GPIO_ACTIVE_HIGH>; /* PE2 */
+status = "okay";
+};
-- 
2.40.1

[PATCH 2/3] drivers: musb-new: add allwinner f1c100s

[路辉]

>From fe7d48e84bb3c72d219f37eed51ea766f83b4bec Mon Sep 17 00:00:00 2001
From: Lu Hui 
Date: Fri, 9 Jun 2023 22:05:23 +0800
Subject: [PATCH 2/3] drivers: musb-new: add allwinner f1c100s configuration

---
 drivers/usb/musb-new/sunxi.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index dc4cfc2194..1c90739cea 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -4,6 +4,7 @@
  *
  * Copyright © 2015 Hans de Goede 
  * Copyright © 2013 Jussi Kivilinna 
+ * Copyright © 2023 Lu Hui 
  *
  * Based on the sw_usb "Allwinner OTG Dual Role Controller" code.
  *  Copyright 2007-2012 (C) Allwinner Technology Co., Ltd.
@@ -519,6 +520,10 @@ static const struct sunxi_musb_config sun8i_h3_cfg = {
 .config = _config_h3,
 };

+static const struct sunxi_musb_config suniv_f1c100s_cfg = {
+.config = _config,
+};
+
 static const struct udevice_id sunxi_musb_ids[] = {
 { .compatible = "allwinner,sun4i-a10-musb",
 .data = (ulong)_a10_cfg },
@@ -528,6 +533,8 @@ static const struct udevice_id sunxi_musb_ids[] = {
 .data = (ulong)_a31_cfg },
 { .compatible = "allwinner,sun8i-h3-musb",
 .data = (ulong)_h3_cfg },
+{ .compatible = "allwinner,suniv-f1c100s-musb",
+.data = (ulong)_f1c100s_cfg },
 { }
 };

-- 
2.40.1

[PATCH 1/3] phy: phy-sun4i-usb: add allwinner f1c100s configuration

[路辉]

>From 09a85536f92cfd22f2a6feba8ea91fae4bc41ed8 Mon Sep 17 00:00:00 2001
From: Lu Hui 
Date: Fri, 9 Jun 2023 22:04:56 +0800
Subject: [PATCH 1/3] phy: phy-sun4i-usb: add allwinner f1c100s configuration

---
 drivers/phy/allwinner/phy-sun4i-usb.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
b/drivers/phy/allwinner/phy-sun4i-usb.c
index 6428163c18..8425a83c84 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -4,6 +4,7 @@
  * Copyright (C) 2017 Jagan Teki 
  * Copyright (C) 2015 Hans de Goede 
  * Copyright (C) 2014 Roman Byshko 
+ * Copyright (C) 2023 Lu Hui 
  *
  * Modelled arch/arm/mach-sunxi/usb_phy.c to compatible with generic-phy.
  *
@@ -83,6 +84,7 @@ enum sun4i_usb_phy_type {
 sun8i_v3s_phy,
 sun50i_a64_phy,
 sun50i_h6_phy,
+suniv_f1c100s_phy,
 };

 struct sun4i_usb_phy_cfg {
@@ -372,8 +374,9 @@ static int sun4i_usb_phy_xlate(struct phy *phy,
 {
 struct sun4i_usb_phy_data *data = dev_get_priv(phy->dev);

-if (args->args_count >= data->cfg->num_phys)
+if (args->args_count > data->cfg->num_phys) {
 return -EINVAL;
+}

 if (data->cfg->missing_phys & BIT(args->args[0]))
 return -ENODEV;
@@ -531,6 +534,14 @@ static int sun4i_usb_phy_probe(struct udevice *dev)
 return 0;
 }

+static const struct sun4i_usb_phy_cfg suniv_f1c100s_cfg = {
+.num_phys = 1,
+.type = suniv_f1c100s_phy,
+.disc_thresh = 3,
+.phyctl_offset = REG_PHYCTL_A10,
+.dedicated_clocks = true,
+};
+
 static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
 .num_phys = 3,
 .type = sun4i_a10_phy,
@@ -659,6 +670,7 @@ static const struct udevice_id sun4i_usb_phy_ids[] = {
 { .compatible = "allwinner,sun20i-d1-usb-phy", .data =
(ulong)_d1_cfg },
 { .compatible = "allwinner,sun50i-a64-usb-phy", .data =
(ulong)_a64_cfg},
 { .compatible = "allwinner,sun50i-h6-usb-phy", .data =
(ulong)_h6_cfg},
+{ .compatible = "allwinner,suniv-f1c100s-usb-phy", .data =
(ulong)_f1c100s_cfg},
 { }
 };

-- 
2.40.1

[PATCH] drivers: pinctrl-sunxi: add suniv spi1 function

[路辉]

>From 570b40e19de75511d9ce066e1a28333ada04baf2 Mon Sep 17 00:00:00 2001
From: Lu Hui 
Date: Mon, 29 May 2023 22:26:25 +0800
Subject: [PATCH] drivers: pinctrl-sunxi: add suniv spi1 function

---
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index e510218090..c448e40ab0 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -240,6 +240,7 @@ static const struct sunxi_pinctrl_function
suniv_f1c100s_pinctrl_functions[] = {
 { "mmc0",2 },/* PF0-PF5 */
 { "mmc1",3 },/* PC0-PC2 */
 { "spi0",2 },/* PC0-PC3 */
+{ "spi1",6 },/* PA0-PA3 */
 #if IS_ENABLED(CONFIG_UART0_PORT_F)
 { "uart0",3 },/* PF2-PF4 */
 #else
-- 
2.40.1

Re: [PATCH V2 6/8] drivers: video: Kconfig: Add config remove video

[Tom Rini]

On Fri, Jun 09, 2023 at 05:21:20PM +0530, Nikhil M Jain wrote:
> This is required since user may want to either call the remove method
> of video driver and reset the display or not call the remove method
> to continue displaying until next stage.
> 
> Signed-off-by: Nikhil M Jain 
> Reviewed-by: Devarsh Thakkar 
> ---
> V2:
> - Add Reviewed-by tag.
> 
>  drivers/video/Kconfig | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index fcc0e85d2e..eca95dd28e 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -840,6 +840,13 @@ config IHS_VIDEO_OUT
> out On-screen Display (OSD) used on gdsys FPGAs to control dynamic
> textual overlays of the display outputs.
>  
> +config VIDEO_REMOVE
> + bool "Remove video driver"
> + help
> + Use this option to specify if user wants to call remove method 
> of
> + video driver in u-boot proper stage.

Please fix this spacing.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH V2 4/8] include: video: Reserve video using blob

[Tom Rini]

On Fri, Jun 09, 2023 at 05:21:18PM +0530, Nikhil M Jain wrote:

> Add method to reserve video framebuffer information using blob,
> recieved from previous stage.
> 
> Signed-off-by: Nikhil M Jain 
> ---
> V2:
> - Remove #if CONFIG_IS_ENABLED(VIDEO) in video_reserve_from_blob.
> 
>  drivers/video/video-uclass.c | 11 +++
>  include/video.h  |  9 +
>  2 files changed, 20 insertions(+)
> 
> diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
> index 8396bdfb11..68ce681bb9 100644
> --- a/drivers/video/video-uclass.c
> +++ b/drivers/video/video-uclass.c
> @@ -142,6 +142,17 @@ int video_reserve(ulong *addrp)
>   return 0;
>  }
>  
> +int video_reserve_from_bloblist(struct video_handoff *ho)
> +{
> + gd->video_bottom = ho->fb;
> + gd->fb_base = ho->fb;
> + gd->video_top = ho->fb + ho->size;
> + debug("Reserving %luk for video using blob at: %08x\n",
> +   ((unsigned long)ho->size) >> 10, (u32)ho->fb);
> +
> + return 0;
> +}
> +
>  int video_fill(struct udevice *dev, u32 colour)
>  {
>   struct video_priv *priv = dev_get_uclass_priv(dev);
> diff --git a/include/video.h b/include/video.h
> index 18ed159b8d..5f3010d641 100644
> --- a/include/video.h
> +++ b/include/video.h
> @@ -389,4 +389,13 @@ int bmp_display(ulong addr, int x, int y);
>   */
>  int bmp_info(ulong addr);
>  
> +/*
> + * video_reserve_from_bloblist()- Reserve frame-buffer memory for video 
> devices
> + * using blobs.
> + *
> + * @ho: video information passed from SPL
> + * Returns: 0 (always)
> + */
> +int video_reserve_from_bloblist(struct video_handoff *ho);
> +
>  #endif

Anatolij any thoughts?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH V2 1/8] common: spl: spl: Update stack pointer address

[Tom Rini]

On Fri, Jun 09, 2023 at 05:21:15PM +0530, Nikhil M Jain wrote:

> At SPL stage when stack is relocated, the stack pointer needs to be
> updated, the stack pointer may point to stack in on chip memory even
> though stack is relocated.
> 
> Signed-off-by: Nikhil M Jain 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] bootstd: Fix relative path use in extlinux bootmeth

[Jonas Karlman]

Using relative path in a /boot/extlinux/extlinux.conf file fails to load
linux kernel.

Using a /boot/extlinux/extlinux.conf file:

  LABEL test
LINUX ../linux/Image

Result in following error:

  Retrieving file: ../linux/Image
  Skipping test for failure retrieving kernel
  Boot failed (err=-14)

However, using sysboot cmd successfully load kernel using same file:

  sysboot mmc 1:1 any ${scriptaddr} /boot/extlinux/extlinux.conf

  Retrieving file: /boot/extlinux/../linux/Image

Fix relative path using bootmeth extlinux by supplying bootfile path
instead of subdir path in the call to pxe_setup_ctx, same as done in the
sysboot command.

Fixes: 31aefaf89a5b ("bootstd: Add an implementation of distro boot")
Signed-off-by: Jonas Karlman 
---
 boot/bootmeth_extlinux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/boot/bootmeth_extlinux.c b/boot/bootmeth_extlinux.c
index 24be0760229c..6b2b84003836 100644
--- a/boot/bootmeth_extlinux.c
+++ b/boot/bootmeth_extlinux.c
@@ -150,7 +150,7 @@ static int extlinux_boot(struct udevice *dev, struct 
bootflow *bflow)
info.dev = dev;
info.bflow = bflow;
ret = pxe_setup_ctx(, , extlinux_getfile, , true,
-   bflow->subdir, false);
+   bflow->fname, false);
if (ret)
return log_msg_ret("ctx", -EINVAL);
 
-- 
2.40.1

Re: [PATCH v2] dt-bindings: riscv: deprecate riscv,isa

[Conor Dooley]

On Fri, Jun 09, 2023 at 08:03:44AM -0600, Rob Herring wrote:

> Nope, vendor prefixes don't go in node names. That's not explicit
> anywhere, but goes against using generic node names.

Yeah, that makes sense.

> Also, note that looking at the DT spec, there's already prior art here
> with PPC. See "power-isa-*". Though that appears in .dts files, but no
> kernel code. Maybe you already saw that as your v1 is similar. There's
> not really much advantage to align with it, but also not much reason
> to deviate.

I went back and forth on riscv-isa- versus riscv,isa-, picking the , for
consistency with other properties in the file. I thought that doing it
like power would be frowned upon & that it might've been done like that
for historic reasons, especially given existing properties we have for
riscv ISA related things are vendor properties w/ the comma.

I don't have strong feelings either way though, so if you say s/,/-/
then that's good by me!

Cheers,
Conor.


signature.asc
Description: PGP signature

Re: [PATCH v2] dt-bindings: riscv: deprecate riscv,isa

[Rob Herring]

On Thu, Jun 8, 2023 at 12:05 PM Conor Dooley  wrote:
>
> On Thu, Jun 08, 2023 at 11:49:08AM -0600, Rob Herring wrote:
> > On Thu, 08 Jun 2023 17:54:05 +0100, Conor Dooley wrote:
>
> > > As a result of implementing Sean's suggestion, I believe I need to add
> > > riscv,isa-extensions as an exception to the rules preventing vendor
> > > properties being of object type, otherwise dt_binding_check is less than
> > > happy with me.
>
> > dtschema/dtc warnings/errors:
> > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/riscv/extensions.yaml:
> >  properties:riscv,isa-extensions: 'oneOf' conditional failed, one must be 
> > fixed:
> >   Additional properties are not allowed ('additionalProperties', 
> > 'properties' were unexpected)
> >   hint: A vendor boolean property can use "type: boolean"
> >   
> > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/riscv/extensions.yaml:
> >  properties:riscv,isa-extensions: 'oneOf' conditional failed, one must be 
> > fixed:
> >   'enum' is a required property
> >   'const' is a required property
> >   hint: A vendor string property with exact values has an 
> > implicit type
> >   from schema $id: 
> > http://devicetree.org/meta-schemas/vendor-props.yaml#
> >   Additional properties are not allowed ('additionalProperties', 
> > 'properties', 'type' were unexpected)
> >   hint: A vendor string property with exact values has an 
> > implicit type
> >   
> > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/riscv/extensions.yaml:
> >  properties:riscv,isa-extensions: 'oneOf' conditional failed, one must be 
> > fixed:
> >   '$ref' is a required property
> >   'allOf' is a required property
> >   hint: A vendor property needs a $ref to types.yaml
> >   from schema $id: 
> > http://devicetree.org/meta-schemas/vendor-props.yaml#
> >   'boolean' was expected
> >   hint: A vendor boolean property can use "type: boolean"
> >   hint: Vendor specific properties must have a type and description 
> > unless they have a defined, common suffix.
> >   from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
>
> Yeah, expected. I think I need an exception in vendor-props for this to
> pass the checks.

Nope, vendor prefixes don't go in node names. That's not explicit
anywhere, but goes against using generic node names.

Also, note that looking at the DT spec, there's already prior art here
with PPC. See "power-isa-*". Though that appears in .dts files, but no
kernel code. Maybe you already saw that as your v1 is similar. There's
not really much advantage to align with it, but also not much reason
to deviate.

Rob

Re: [PULL] u-boot-sh/master_soc/fixes

[Tom Rini]

On Thu, Jun 08, 2023 at 11:33:12PM +0200, Marek Vasut wrote:

> The following changes since commit 661332a0744dad6a1a4bfbbdea2a4e5ae9835e52:
> 
>   Merge https://source.denx.de/u-boot/custodians/u-boot-sunxi (2023-06-07 
> 22:05:16 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-sh.git master_soc/fixes
> 
> for you to fetch changes up to b597b6f9861c2d5531b0055249622ee0e663577c:
> 
>   pinctrl: renesas: r8a779a0: Remove incorrect AVB[01] pinmux configuration 
> (2023-06-08 22:22:38 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PULL] u-boot-sh/master_soc/fixes

[Tom Rini]

On Thu, Jun 08, 2023 at 11:33:12PM +0200, Marek Vasut wrote:

> The following changes since commit 661332a0744dad6a1a4bfbbdea2a4e5ae9835e52:
> 
>   Merge https://source.denx.de/u-boot/custodians/u-boot-sunxi (2023-06-07 
> 22:05:16 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-sh.git master_soc/fixes
> 
> for you to fetch changes up to b597b6f9861c2d5531b0055249622ee0e663577c:
> 
>   pinctrl: renesas: r8a779a0: Remove incorrect AVB[01] pinmux configuration 
> (2023-06-08 22:22:38 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH V2 8/8] configs: am62x_evm_a53: Add bloblist address

[Nishanth Menon]

On 17:21-20230609, Nikhil M Jain wrote:
> Define bloblist address.
> 
> Updated Memory map
>   0x8000┌─┐
>   │Empty 512 KB │
>   │ │
> 0x8008├─┤
>   │ Text Base   │
>   │   352 KB│
>   │ │
> 0x800D8000├─┤
>   │Empty 1.1MB  │
>   │ │
> 0x8020├─┤
>   │ │
>   │ │
>   │ │
>   │   BMP Image Load│
>   │ │
>   │   9.4 MB│
>   │ │
>   │ │
>   │ │
>   │ │
>   │ │
>   │ │
> 0x80B77660├─┤
>   │ Stack 2KB   │
> 0x80B77e60├─┤
>   │GD 416 Bytes │
> 0x80B78000├─┤
>   │ │
>   │Malloc 352KB │
> 0x80B8├─┤
>   │ │
>   │ Empty 1 MB  │
>   │ │
> 0x80C8├─┤
>   │ BSS 512 KB  │
>   │ │
> 0x80D0├─┤
>   │ Blobs 1KB   │
> 0x80D00400├─┤
>   │ │
>   │   Empty 2.999MB │
>   │ │
>   │ │
> 0x8100└─┘FIT Image load address

Document in rst please.

> 
> Signed-off-by: Nikhil M Jain 
> Reviewed-by: Devarsh Thakkar 
> ---
> V2:
> - Add Reviewed-by tag.
> 
>  configs/am62x_evm_a53_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
> index 7c3bc184cf..5c572dfb33 100644
> --- a/configs/am62x_evm_a53_defconfig
> +++ b/configs/am62x_evm_a53_defconfig
> @@ -102,3 +102,4 @@ CONFIG_SYSRESET=y
>  CONFIG_SPL_SYSRESET=y
>  CONFIG_SYSRESET_TI_SCI=y
>  CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
> +CONFIG_BLOBLIST_ADDR=0x80D0
> -- 
> 2.34.1
> 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

[PATCH V2 8/8] configs: am62x_evm_a53: Add bloblist address

[Nikhil M Jain]

Define bloblist address.

Updated Memory map
0x8000┌─┐
  │Empty 512 KB │
  │ │
0x8008├─┤
  │ Text Base   │
  │   352 KB│
  │ │
0x800D8000├─┤
  │Empty 1.1MB  │
  │ │
0x8020├─┤
  │ │
  │ │
  │ │
  │   BMP Image Load│
  │ │
  │   9.4 MB│
  │ │
  │ │
  │ │
  │ │
  │ │
  │ │
0x80B77660├─┤
  │ Stack 2KB   │
0x80B77e60├─┤
  │GD 416 Bytes │
0x80B78000├─┤
  │ │
  │Malloc 352KB │
0x80B8├─┤
  │ │
  │ Empty 1 MB  │
  │ │
0x80C8├─┤
  │ BSS 512 KB  │
  │ │
0x80D0├─┤
  │ Blobs 1KB   │
0x80D00400├─┤
  │ │
  │   Empty 2.999MB │
  │ │
  │ │
0x8100└─┘FIT Image load address

Signed-off-by: Nikhil M Jain 
Reviewed-by: Devarsh Thakkar 
---
V2:
- Add Reviewed-by tag.

 configs/am62x_evm_a53_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 7c3bc184cf..5c572dfb33 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -102,3 +102,4 @@ CONFIG_SYSRESET=y
 CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_TI_SCI=y
 CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
+CONFIG_BLOBLIST_ADDR=0x80D0
-- 
2.34.1

[PATCH V2 3/8] board: ti: am62x: evm: Update function calls for splash screen

[Nikhil M Jain]

Use spl_dcache_enable, in place of setup_dram, arch_reserve_mmu to set
up pagetable, initialise DRAM and enable Dcache.

Signed-off-by: Nikhil M Jain 
---
V2:
- Use CONFIG_SPL_VIDEO in place of CONFIG_SPL_VIDEO_TIDSS to reserve
  video and  call splash at SPL.
- Check SPL_SPLASH_SCREEN and SPL_BMP before calling splash display.

 arch/arm/mach-k3/am625_init.c |  1 +
 board/ti/am62x/evm.c  | 41 +--
 2 files changed, 16 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
index 787fe92295..0e5d44269e 100644
--- a/arch/arm/mach-k3/am625_init.c
+++ b/arch/arm/mach-k3/am625_init.c
@@ -214,6 +214,7 @@ void board_init_f(ulong dummy)
if (ret)
panic("DRAM init failed: %d\n", ret);
 #endif
+   spl_enable_dcache();
 }
 
 u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index 34830f445f..d3c1786cd9 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -59,42 +59,31 @@ int dram_init_banksize(void)
 }
 
 #if defined(CONFIG_SPL_BUILD)
-#ifdef CONFIG_SPL_VIDEO_TIDSS
-static int setup_dram(void)
-{
-   dram_init();
-   dram_init_banksize();
-   gd->ram_base = CFG_SYS_SDRAM_BASE;
-   gd->ram_top = gd->ram_base + gd->ram_size;
-   gd->relocaddr = gd->ram_top;
-   return 0;
-}
-
 static int video_setup(void)
 {
-   ulong addr;
-   int ret;
-   addr = gd->relocaddr;
+   if (CONFIG_IS_ENABLED(VIDEO)) {
+   ulong addr;
+   int ret;
+
+   addr = gd->relocaddr;
+   ret = video_reserve();
+   if (ret)
+   return ret;
+   debug("Reserving %luk for video at: %08lx\n",
+ ((unsigned long)gd->relocaddr - addr) >> 10, addr);
+   gd->relocaddr = addr;
+   }
 
-   ret = video_reserve();
-   if (ret)
-   return ret;
-   debug("Reserving %luk for video at: %08lx\n",
- ((unsigned long)gd->relocaddr - addr) >> 10, addr);
-   gd->relocaddr = addr;
return 0;
 }
 
-#endif
 void spl_board_init(void)
 {
-#if defined(CONFIG_SPL_VIDEO_TIDSS)
-   setup_dram();
-   arch_reserve_mmu();
video_setup();
enable_caches();
-   splash_display();
-#endif
+   if (IS_ENABLED(CONFIG_SPL_SPLASH_SCREEN) && IS_ENABLED(CONFIG_SPL_BMP))
+   splash_display();
+
 }
 
 #if defined(CONFIG_K3_AM64_DDRSS)
-- 
2.34.1

[PATCH V2 6/8] drivers: video: Kconfig: Add config remove video

[Nikhil M Jain]

This is required since user may want to either call the remove method
of video driver and reset the display or not call the remove method
to continue displaying until next stage.

Signed-off-by: Nikhil M Jain 
Reviewed-by: Devarsh Thakkar 
---
V2:
- Add Reviewed-by tag.

 drivers/video/Kconfig | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index fcc0e85d2e..eca95dd28e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -840,6 +840,13 @@ config IHS_VIDEO_OUT
  out On-screen Display (OSD) used on gdsys FPGAs to control dynamic
  textual overlays of the display outputs.
 
+config VIDEO_REMOVE
+   bool "Remove video driver"
+   help
+   Use this option to specify if user wants to call remove method 
of
+   video driver in u-boot proper stage.
+
+
 config SPLASH_SCREEN
bool "Show a splash-screen image"
help
@@ -1063,6 +1070,12 @@ config SPL_SYS_WHITE_ON_BLACK
 This can be better in low-light situations or to reduce eye strain in
 some cases.
 
+config SPL_VIDEO_REMOVE
+   bool "Remove video driver after SPL stage"
+   help
+if this  option is enabled video driver will be removed at the end of
+SPL stage, beforeloading the next stage.
+
 if SPL_SPLASH_SCREEN
 
 config SPL_SPLASH_SCREEN_ALIGN
-- 
2.34.1

[PATCH V2 5/8] common: board_f: Pass frame buffer info from SPL to u-boot

[Nikhil M Jain]

U-boot proper can use frame buffer address passed from SPL to reserve
the memory area used by framebuffer set in SPL so that splash image
set in SPL continues to get displayed while u-boot proper is running.

Put the framebuffer address and size in a bloblist to make them
available at u-boot proper, if in u-boot proper CONFIG_VIDEO is defined.

Signed-off-by: Nikhil M Jain 
---
V2:
- Fix commit message.
- Revert use of #if.

 common/board_f.c | 12 +++-
 drivers/video/video-uclass.c | 12 
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/common/board_f.c b/common/board_f.c
index 1688e27071..418aecc18f 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -411,7 +411,17 @@ __weak int arch_reserve_mmu(void)
 
 static int reserve_video(void)
 {
-   if (IS_ENABLED(CONFIG_VIDEO)) {
+
+   if (IS_ENABLED(CONFIG_SPL_VIDEO) && spl_phase() > PHASE_SPL &&
+   CONFIG_IS_ENABLED(BLOBLIST)) {
+   struct video_handoff *ho;
+
+   ho = bloblist_find(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho));
+   if (!ho)
+   return log_msg_ret("blf", -ENOENT);
+   video_reserve_from_bloblist(ho);
+   gd->relocaddr = ho->fb;
+   } else if(CONFIG_IS_ENABLED(VIDEO)){
ulong addr;
int ret;
 
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 68ce681bb9..f8f0dc0311 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -6,12 +6,14 @@
 #define LOG_CATEGORY UCLASS_VIDEO
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -139,6 +141,16 @@ int video_reserve(ulong *addrp)
debug("Video frame buffers from %lx to %lx\n", gd->video_bottom,
  gd->video_top);
 
+   if (spl_phase() == PHASE_SPL && CONFIG_IS_ENABLED(BLOBLIST)) {
+   struct video_handoff *ho;
+
+   ho = bloblist_add(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho), 0);
+   if (!ho)
+   return log_msg_ret("blf", -ENOENT);
+   ho->fb = *addrp;
+   ho->size = size;
+   }
+
return 0;
 }
 
-- 
2.34.1

[PATCH V2 7/8] common: spl: spl: Remove video driver

[Nikhil M Jain]

Use config SPL_VIDEO_REMOVE to remove video driver at SPL stage before
jumping to next stage, in place of CONFIG_SPL_VIDEO, to allow user to
remove video if required.

Signed-off-by: Nikhil M Jain 
Reviewed-by: Devarsh Thakkar 
---
v2:
- Add Reviewed-by tag.

 common/spl/spl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 13b55e9769..a65781002e 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -891,7 +891,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
debug("Failed to stash bootstage: err=%d\n", ret);
 #endif
 
-#if defined(CONFIG_SPL_VIDEO)
+#if defined(CONFIG_SPL_VIDEO_REMOVE)
struct udevice *dev;
int rc;
 
-- 
2.34.1

[PATCH V2 2/8] arch: arm: mach-k3: common: Return a pointer after setting page table

[Nikhil M Jain]

In spl_dcache_enable after setting up page table, set gd->relocaddr
pointer to tlb_addr, to get next location to reserve memory. Align
tlb_addr with 64KB address.

Signed-off-by: Nikhil M Jain 
---
V2:
- Perform 64KB alignment on tlb_addr.

 arch/arm/mach-k3/common.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 0e045919dd..9cd912c523 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -624,8 +624,10 @@ void spl_enable_dcache(void)
ram_top = (phys_addr_t) 0x1;
 
gd->arch.tlb_addr = ram_top - gd->arch.tlb_size;
+   gd->arch.tlb_addr &= ~(0x1 - 1);
debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
  gd->arch.tlb_addr + gd->arch.tlb_size);
+   gd->relocaddr = gd->arch.tlb_addr;
 
dcache_enable();
 #endif
-- 
2.34.1

[PATCH V2 1/8] common: spl: spl: Update stack pointer address

[Nikhil M Jain]

At SPL stage when stack is relocated, the stack pointer needs to be
updated, the stack pointer may point to stack in on chip memory even
though stack is relocated.

Signed-off-by: Nikhil M Jain 
---
V2:
- No change.

 common/spl/spl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 801c4b507c..13b55e9769 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -992,6 +992,7 @@ ulong spl_relocate_stack_gd(void)
 #endif
/* Get stack position: use 8-byte alignment for ABI compliance */
ptr = CONFIG_SPL_STACK_R_ADDR - roundup(sizeof(gd_t),16);
+   gd->start_addr_sp = ptr;
new_gd = (gd_t *)ptr;
memcpy(new_gd, (void *)gd, sizeof(gd_t));
 #if CONFIG_IS_ENABLED(DM)
-- 
2.34.1

[PATCH V2 4/8] include: video: Reserve video using blob

[Nikhil M Jain]

Add method to reserve video framebuffer information using blob,
recieved from previous stage.

Signed-off-by: Nikhil M Jain 
---
V2:
- Remove #if CONFIG_IS_ENABLED(VIDEO) in video_reserve_from_blob.

 drivers/video/video-uclass.c | 11 +++
 include/video.h  |  9 +
 2 files changed, 20 insertions(+)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 8396bdfb11..68ce681bb9 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -142,6 +142,17 @@ int video_reserve(ulong *addrp)
return 0;
 }
 
+int video_reserve_from_bloblist(struct video_handoff *ho)
+{
+   gd->video_bottom = ho->fb;
+   gd->fb_base = ho->fb;
+   gd->video_top = ho->fb + ho->size;
+   debug("Reserving %luk for video using blob at: %08x\n",
+ ((unsigned long)ho->size) >> 10, (u32)ho->fb);
+
+   return 0;
+}
+
 int video_fill(struct udevice *dev, u32 colour)
 {
struct video_priv *priv = dev_get_uclass_priv(dev);
diff --git a/include/video.h b/include/video.h
index 18ed159b8d..5f3010d641 100644
--- a/include/video.h
+++ b/include/video.h
@@ -389,4 +389,13 @@ int bmp_display(ulong addr, int x, int y);
  */
 int bmp_info(ulong addr);
 
+/*
+ * video_reserve_from_bloblist()- Reserve frame-buffer memory for video devices
+ * using blobs.
+ *
+ * @ho: video information passed from SPL
+ * Returns: 0 (always)
+ */
+int video_reserve_from_bloblist(struct video_handoff *ho);
+
 #endif
-- 
2.34.1

[PATCH V2 0/8] Update SPL splashscreen framework for AM62x

[Nikhil M Jain]

This patch series aims at updating SPL splashscreen framework for AM62x.

This patch series depends on
https://lore.kernel.org/u-boot/20230504225829.2537050-1-...@chromium.org/

This series:
- Fixes compilation issues in case splash related configs are not
  defined in SPL.
- Does page table setup, dram initialisation and dcache enabling in
  one function call spl_enable_dcache.
- Allows passing of framebuffer from spl to u-boot, eliminating flicker.

V2:
- Update cover letter.
- Fix commit message.

Nikhil M Jain (8):
  common: spl: spl: Update stack pointer address
  arch: arm: mach-k3: common: Return a pointer after setting page table
  board: ti: am62x: evm: Update function calls for splash screen
  include: video: Reserve video using blob
  common: board_f: Pass frame buffer info from SPL to u-boot
  drivers: video: Kconfig: Add config remove video
  common: spl: spl: Remove video driver
  configs: am62x_evm_a53: Add bloblist address

 arch/arm/mach-k3/am625_init.c   |  1 +
 arch/arm/mach-k3/common.c   |  2 ++
 board/ti/am62x/evm.c| 41 -
 common/board_f.c| 12 +-
 common/spl/spl.c|  3 ++-
 configs/am62x_evm_a53_defconfig |  1 +
 drivers/video/Kconfig   | 13 +++
 drivers/video/video-uclass.c| 23 ++
 include/video.h |  9 
 9 files changed, 77 insertions(+), 28 deletions(-)

-- 
2.34.1

[PATCH 3/3] sunxi: Kconfig: rework PHY_USB_SUN4I selection

[Andre Przywara]

At the moment we use "select" in each Allwinner SoC's Kconfig section to
include the USB PHY driver in the build. This means it cannot be disabled
via Kconfig, although USB is not really a strictly required core
functionality, and a particular board might not even include USB ports.

Rework the Kconfig part by removing the "select" lines for each SoC's
section, and instead letting it default to "y" in the PHY driver section
itself. We use "depends on !" to exclude the few SoCs we don't support
(yet). The Allwinner V3s does not enable USB (PHY) support at the moment,
even though it should work: let the PHY default to "n" to keep the
current behaviour.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/Kconfig   | 11 ---
 drivers/phy/allwinner/Kconfig |  6 +-
 2 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 6dcbb096f74..e0b1bde35a9 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -207,7 +207,6 @@ endif
 
 config MACH_SUNXI_H3_H5
bool
-   select PHY_SUN4I_USB
select SUNXI_DE2
select SUNXI_DRAM_DW
select SUNXI_DRAM_DW_32BIT
@@ -236,7 +235,6 @@ config MACH_SUNIV
 config MACH_SUN4I
bool "sun4i (Allwinner A10)"
select CPU_V7A
-   select PHY_SUN4I_USB
select DRAM_SUN4I
select SUNXI_GEN_SUN4I
select SUPPORT_SPL
@@ -247,7 +245,6 @@ config MACH_SUN5I
bool "sun5i (Allwinner A13)"
select CPU_V7A
select DRAM_SUN4I
-   select PHY_SUN4I_USB
select SUNXI_GEN_SUN4I
select SUPPORT_SPL
imply SPL_SYS_I2C_LEGACY
@@ -261,7 +258,6 @@ config MACH_SUN6I
select ARCH_SUPPORT_PSCI
select SPL_ARMV7_SET_CORTEX_SMPEN
select DRAM_SUN6I
-   select PHY_SUN4I_USB
select SPL_I2C
select SUN6I_PRCM
select SUNXI_GEN_SUN6I
@@ -277,7 +273,6 @@ config MACH_SUN7I
select ARCH_SUPPORT_PSCI
select SPL_ARMV7_SET_CORTEX_SMPEN
select DRAM_SUN4I
-   select PHY_SUN4I_USB
select SUNXI_GEN_SUN4I
select SUPPORT_SPL
select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT
@@ -291,7 +286,6 @@ config MACH_SUN8I_A23
select CPU_V7_HAS_VIRT
select ARCH_SUPPORT_PSCI
select DRAM_SUN8I_A23
-   select PHY_SUN4I_USB
select SPL_I2C
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
@@ -305,7 +299,6 @@ config MACH_SUN8I_A33
select CPU_V7_HAS_VIRT
select ARCH_SUPPORT_PSCI
select DRAM_SUN8I_A33
-   select PHY_SUN4I_USB
select SPL_I2C
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
@@ -316,7 +309,6 @@ config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7A
select DRAM_SUN8I_A83T
-   select PHY_SUN4I_USB
select SPL_I2C
select SUNXI_GEN_SUN6I
select MMC_SUNXI_HAS_NEW_MODE
@@ -344,7 +336,6 @@ config MACH_SUN8I_R40
select SUPPORT_SPL
select SUNXI_DRAM_DW
select SUNXI_DRAM_DW_32BIT
-   select PHY_SUN4I_USB
imply SPL_SYS_I2C_LEGACY
 
 config MACH_SUN8I_V3S
@@ -372,7 +363,6 @@ config MACH_SUN9I
 config MACH_SUN50I
bool "sun50i (Allwinner A64)"
select ARM64
-   select PHY_SUN4I_USB
select SUN6I_PRCM
select SUNXI_DE2
select SUNXI_GEN_SUN6I
@@ -395,7 +385,6 @@ config MACH_SUN50I_H5
 config MACH_SUN50I_H6
bool "sun50i (Allwinner H6)"
select ARM64
-   select PHY_SUN4I_USB
select DRAM_SUN50I_H6
select SUN50I_GEN_H6
 
diff --git a/drivers/phy/allwinner/Kconfig b/drivers/phy/allwinner/Kconfig
index f8f1e99c4f5..565b4617b01 100644
--- a/drivers/phy/allwinner/Kconfig
+++ b/drivers/phy/allwinner/Kconfig
@@ -4,6 +4,10 @@
 config PHY_SUN4I_USB
bool "Allwinner Sun4I USB PHY driver"
depends on ARCH_SUNXI
+   depends on !MACH_SUN9I
+   depends on !MACH_SUN50I_H616
+   default n if MACH_SUN8I_V3S
+   default y
select DM_REGULATOR
select PHY
help
@@ -11,7 +15,7 @@ config PHY_SUN4I_USB
  sunxi SoCs.
 
  This driver controls the entire USB PHY block, both the USB OTG
- parts, as well as the 2 regular USB 2 host PHYs.
+ parts, as well as the regular USB HCI host PHYs.
 
 config INITIAL_USB_SCAN_DELAY
int "Delay initial USB scan by x ms to allow builtin devices to init"
-- 
2.25.1

[PATCH 2/3] phy: sun4i-usb: add Allwinner F1C100s support

[Andre Przywara]

The Allwinner F1C100s implements a single USB PHY, connected to its MUSB
OTG controller. The USB PHY is of the simpler, older type (like the A10),
the only real difference is that it's indeed only one PHY.

Add a struct describing those F1C100s USB PHY properties, and connect it
to the new compatible string.

Signed-off-by: Andre Przywara 
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index dbea70f9a5e..2bf47fc36a7 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -648,6 +648,14 @@ static const struct sun4i_usb_phy_cfg sun50i_h6_cfg = {
.missing_phys = BIT(1) | BIT(2),
 };
 
+static const struct sun4i_usb_phy_cfg suniv_f1c100s_cfg = {
+   .num_phys = 1,
+   .type = sun4i_a10_phy,
+   .disc_thresh = 3,
+   .phyctl_offset = REG_PHYCTL_A10,
+   .dedicated_clocks = true,
+};
+
 static const struct udevice_id sun4i_usb_phy_ids[] = {
{ .compatible = "allwinner,sun4i-a10-usb-phy", .data = 
(ulong)_a10_cfg },
{ .compatible = "allwinner,sun5i-a13-usb-phy", .data = 
(ulong)_a13_cfg },
@@ -662,6 +670,7 @@ static const struct udevice_id sun4i_usb_phy_ids[] = {
{ .compatible = "allwinner,sun20i-d1-usb-phy", .data = 
(ulong)_d1_cfg },
{ .compatible = "allwinner,sun50i-a64-usb-phy", .data = 
(ulong)_a64_cfg},
{ .compatible = "allwinner,sun50i-h6-usb-phy", .data = 
(ulong)_h6_cfg},
+   { .compatible = "allwinner,suniv-f1c100s-usb-phy", .data = 
(ulong)_f1c100s_cfg },
{ }
 };
 
-- 
2.25.1

[PATCH 1/3] phy: sun4i-usb: Fix of_xlate() argument check

[Andre Przywara]

In its of_xlate() function, the Allwinner USB PHY driver compares the
args_count variable against the number of implemented USB PHYs, although
this is the *number of arguments* to the DT phandle property. Per the DT
binding for this PHY device, this number is always one, so this check
will always fail if the particular SoC implements exactly one USB PHY.
So far this affected only the V3s (which has USB support disabled), but
the F1C100s also sports one PHY only.

Fix that check to compare args_count against exactly 1, and the args[0]
content (requested PHY number) against the number of implemented PHYs.

This fixes USB operation on the Allwinner V3s and allows to enable USB
on the Allwinner F1C100s SoC.

Signed-off-by: Andre Przywara 
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index 6428163c188..dbea70f9a5e 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -372,7 +372,10 @@ static int sun4i_usb_phy_xlate(struct phy *phy,
 {
struct sun4i_usb_phy_data *data = dev_get_priv(phy->dev);
 
-   if (args->args_count >= data->cfg->num_phys)
+   if (args->args_count != 1)
+   return -EINVAL;
+
+   if (args->args[0] >= data->cfg->num_phys)
return -EINVAL;
 
if (data->cfg->missing_phys & BIT(args->args[0]))
-- 
2.25.1

[PATCH 0/3] phy: sun4i: Allwinner F1C100s support and cleanup

[Andre Przywara]

This mini series adds support for the Allwinner F1C100s USB PHY. There
is really not much to it, we just need to connect the compatible string
to a description that says we have one "old-style" PHY (patch 2/3).
Doing this revealed a bug, which is fixed in patch 1/3.

Also use the opportunity to fix a long-standing annoyance: we were
"select"ing the USB PHY driver from each SoC's Kconfig stanza, which does
not only look questionable, but also prevents USB support from being
deliberately disabled, for boards without USB sockets or to save
memory and boot time.

The fix in patch 1/3 is not urgent, since we were not hitting this
condition before, so this would all be 2023.10 material.

Cheers,
Andre

Andre Przywara (3):
  phy: sun4i-usb: Fix of_xlate() argument check
  phy: sun4i-usb: add Allwinner F1C100s support
  sunxi: Kconfig: rework PHY_USB_SUN4I selection

 arch/arm/mach-sunxi/Kconfig   | 11 ---
 drivers/phy/allwinner/Kconfig |  6 +-
 drivers/phy/allwinner/phy-sun4i-usb.c | 14 +-
 3 files changed, 18 insertions(+), 13 deletions(-)

-- 
2.25.1

Re: [PATCH 2/2] usb: musb-new: sunxi: clarify the purpose of SRAM initialization

[Andre Przywara]

On Wed,  7 Jun 2023 17:16:44 -0600
Sam Edwards  wrote:

Hi Sam,

> This is largely a cosmetic change, with one functional distinction:
> We are now only setting BIT(0), and no longer clearing BIT(1).
> 
> The new comments and function name are not from any official source,
> but are updated to mirror how the Linux kernel sources treat this
> mystery magic bit. If we wanted to confirm that this speculation is
> correct, we could verify that SRAM-D is inaccessible whenever the
> bit is set, and then try clearing it again while the MUSB is in use
> to see what debris gets left behind in SRAM-D.
> 
> This cleanup also adds a TODO comment about runtime discovery
> of the SYSCON base, per discussion with Andre.

thanks for sending this, looks good. Some stylistic comments below.

> 
> Signed-off-by: Sam Edwards 
> Cc: Andre Przywara 
> ---
>  drivers/usb/musb-new/sunxi.c | 28 
>  1 file changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
> index c05c0d5561..2b954601a0 100644
> --- a/drivers/usb/musb-new/sunxi.c
> +++ b/drivers/usb/musb-new/sunxi.c
> @@ -173,15 +173,23 @@ static void USBC_ForceVbusValidToHigh(__iomem void 
> *base)
>   musb_writel(base, USBC_REG_o_ISCR, reg_val);
>  }
>  
> -static void USBC_ConfigFIFO_Base(void)
> +/**
> + * Non-USBC register access needed for initialization
> + 
> **/
> +
> +/* A10(s), A13, GR8, A20:
> + * switch ownership of SRAM block 'D' to the USB-OTG controller */
> +#define OFF_SUNXI_SRAMCTRL_D (0x04)
> +#define SUNXI_SRAMCTRL_D_FLAG_USBOTG BIT(0)

I am regularly not convinced that adding longish single-use macro names
for simple bit flips is really easier to read, because you always have to
lookup the definition first. If you decide to stick with it anyway, please
lose the parentheses around the 0x04, and use OFS_ instead of OFF_. Or
better use the name from the manual: SRAM_CTRL_REG1.

> +
> +static void sunxi_musb_claim_sram(void)
>  {
> - u32 reg_value;
> + /* TODO: Do not use hardcoded SUNXI_SRAMC_BASE; find the syscon base by

I think we should use "non-net" commenting style, with the "/*" on a line
on its own.

> +  * traversing this OTG device's `allwinner,sram` FDT property and
> +  * working upward to the system controller. */
>  
> - /* config usb fifo, 8kb mode */
> - reg_value = readl(SUNXI_SRAMC_BASE + 0x04);
> - reg_value &= ~(0x03 << 0);
> - reg_value |= BIT(0);
> - writel(reg_value, SUNXI_SRAMC_BASE + 0x04);
> + setbits_le32(SUNXI_SRAMC_BASE + OFF_SUNXI_SRAMCTRL_D,
> +  SUNXI_SRAMCTRL_D_FLAG_USBOTG);

So this is the harder to understand part, IMO. If you stick something like
"Bit 0 in SRAM_CTRL_REG (offset 0x4) controls the SRAM D ownership." in the
comment above, then a simple:
setbits_le32(SUNXI_SRAMC_BASE + 0x04, BIT(0));
becomes much easier to parse and relate to the manual, at least to my eyes.

>  }
>  
>  
> /**
> @@ -315,7 +323,11 @@ static int sunxi_musb_init(struct musb *musb)
>   musb->isr = sunxi_musb_interrupt;
>  
>   if (glue->cfg->has_sram) {
> - USBC_ConfigFIFO_Base();
> + /* This is an older USB-OTG controller that Allwinner did not

Same commenting style issue like above.

Otherwise thanks for clearing this up, also for the future readers!

Cheers,
Andre

> +  * endow with a dedicated SRAM block; it instead uses SRAM
> +  * block 'D', ownership of which needs to be handed over by
> +  * the CPU */
> + sunxi_musb_claim_sram();
>   }
>  
>   USBC_EnableDpDmPullUp(musb->mregs);

Re: [PATCH 1/2] usb: musb-new: sunxi: only perform SRAM initialization when necessary

[Andre Przywara]

On Wed,  7 Jun 2023 17:16:43 -0600
Sam Edwards  wrote:

Hi,

> Only the older (ca. A10, A20) sunxis need this poke for the MUSB to
> function. Mimic the Linux kernel and add a `has_sram` flag to the config
> structure that is only set for the specific compatibles that require
> this initialization.

So I grabbed a BananaPi (A20) and played with it a little. Gadgets still
work with this patch, also I can confirm that this bit is necessary
(turned it off with mw.l, and the gadget stopped working), and also
that the bit flip works (set "has_sram = false;" and it didn't work anymore).

Also tested on an OrangePi Zero (H3), which doesn't need the SRAM switch.
It worked with both the bit set and cleared, also before and after the
patch, so it's all fine.

> Signed-off-by: Sam Edwards 

Reviewed-by: Andre Przywara 
Tested-by: Andre Przywara 

Thanks,
Andre

> ---
>  drivers/usb/musb-new/sunxi.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
> index ab55d68620..c05c0d5561 100644
> --- a/drivers/usb/musb-new/sunxi.c
> +++ b/drivers/usb/musb-new/sunxi.c
> @@ -85,6 +85,7 @@
>  
>  struct sunxi_musb_config {
>   struct musb_hdrc_config *config;
> + bool has_sram;
>  };
>  
>  struct sunxi_glue {
> @@ -313,7 +314,10 @@ static int sunxi_musb_init(struct musb *musb)
>  
>   musb->isr = sunxi_musb_interrupt;
>  
> - USBC_ConfigFIFO_Base();
> + if (glue->cfg->has_sram) {
> + USBC_ConfigFIFO_Base();
> + }
> +
>   USBC_EnableDpDmPullUp(musb->mregs);
>   USBC_EnableIdPullUp(musb->mregs);
>  
> @@ -525,6 +529,7 @@ static int musb_usb_remove(struct udevice *dev)
>  
>  static const struct sunxi_musb_config sun4i_a10_cfg = {
>   .config = _config,
> + .has_sram = true,
>  };
>  
>  static const struct sunxi_musb_config sun6i_a31_cfg = {

Re: [PATCH 0/1] virtio: add driver for virtio_console devices

[Bin Meng]

Hi,

On Tue, Jun 6, 2023 at 9:26 PM Ying-Chun Liu (PaulLiu)
 wrote:
>
> This is an implementation of single-character virtio-console. Part of the
> patch is based on barebox implementations.
>
> To test the patch, we can build qemu_arm64_defconfig target. Enable
> CONFIG_VIRTIO_CONSOLE. And run qemu-system-aarch64 with
>  -device virtio-serial-pci,id=virtio-serial0 \
>  -chardev file,id=charconsole0,path=/tmp/serialconsolelog \
>  -device virtconsole,chardev=charconsole0,id=console0 \
>

With this command, it still uses the on-board UART but not
virtio-console. Would you please post test instructions on using
virtio-console as the U-Boot serial console? Thanks!

> When in U-boot console, type "dm tree" and we should be able to see the
> virtio-console device.
>
> A. Cody Schuffelen (1):
>   virtio: add driver for virtio_console devices
>
>  drivers/virtio/Kconfig  |   8 ++
>  drivers/virtio/Makefile |   1 +
>  drivers/virtio/virtio-uclass.c  |   1 +
>  drivers/virtio/virtio_console.c | 158 
>  include/virtio.h|   2 +
>  5 files changed, 170 insertions(+)
>  create mode 100644 drivers/virtio/virtio_console.c
>
> --

Regards,
Bin

[PATCH 6/6] xilinx: zynq: Add the missing function prototypes

[Ashok Reddy Soma]

From: Algapally Santosh Sagar 

Add the missing prototypes for the functions pointed by the below
sparse warnings
warning: no previous prototype for 'set_dfu_alt_info'
[-Wmissing-prototypes]
warning: no previous prototype for 'board_debug_uart_init'
[-Wmissing-prototypes]

Signed-off-by: Algapally Santosh Sagar 
Signed-off-by: Ashok Reddy Soma 
---

 board/xilinx/zynq/board.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 9a59445b44..3b6581e304 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -5,6 +5,8 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.17.1

[PATCH 5/6] arm: zynq: Pass the missing argument type in function definition

[Ashok Reddy Soma]

From: Algapally Santosh Sagar 

Pass missing argument type in the function definition to fix the
sparse warning, warning: old-style function definition
[-Wold-style-definition]

Signed-off-by: Algapally Santosh Sagar 
Signed-off-by: Ashok Reddy Soma 
---

 board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c 
b/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c
index 796e5b0c5f..6b153aa379 100644
--- a/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c
+++ b/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c
@@ -12648,7 +12648,7 @@ unsigned long *ps7_ddr_init_data = 
ps7_ddr_init_data_3_0;
 unsigned long *ps7_peripherals_init_data = ps7_peripherals_init_data_3_0;
 
 int
-ps7_post_config()
+ps7_post_config(void)
 {
   // Get the PS_VERSION on run time
   unsigned long si_ver = ps7GetSiliconVersion ();
@@ -12667,7 +12667,7 @@ ps7_post_config()
 }
 
 int
-ps7_init()
+ps7_init(void)
 {
   // Get the PS_VERSION on run time
   unsigned long si_ver = ps7GetSiliconVersion ();
-- 
2.17.1

[PATCH 4/6] mtd: nand: zynq_nand: Change datatype of status and ecc_status to int

[Ashok Reddy Soma]

From: Algapally Santosh Sagar 

status and ecc_status are of unsigned type where they are compared for
negative value. This is pointed by below sparse warning. Change datatype
to int to fix this.
warning: comparison of unsigned expression in '< 0' is always false
[-Wtype-limits]

Signed-off-by: Algapally Santosh Sagar 
Signed-off-by: Ashok Reddy Soma 
---

 drivers/mtd/nand/raw/zynq_nand.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/raw/zynq_nand.c b/drivers/mtd/nand/raw/zynq_nand.c
index 9e3ee7412d..545fdd7b69 100644
--- a/drivers/mtd/nand/raw/zynq_nand.c
+++ b/drivers/mtd/nand/raw/zynq_nand.c
@@ -285,7 +285,7 @@ static int zynq_nand_init_nand_flash(struct mtd_info *mtd, 
int option)
 {
struct nand_chip *nand_chip = mtd_to_nand(mtd);
struct nand_drv *smc = nand_get_controller_data(nand_chip);
-   u32 status;
+   int status;
 
/* disable interrupts */
writel(ZYNQ_NAND_CLR_CONFIG, >reg->cfr);
@@ -332,7 +332,7 @@ static int zynq_nand_calculate_hwecc(struct mtd_info *mtd, 
const u8 *data,
struct nand_drv *smc = nand_get_controller_data(nand_chip);
u32 ecc_value = 0;
u8 ecc_reg, ecc_byte;
-   u32 ecc_status;
+   int ecc_status;
 
/* Wait till the ECC operation is complete */
ecc_status = zynq_nand_waitfor_ecc_completion(mtd);
-- 
2.17.1

[PATCH 3/6] spi: zynq_qspi: Add missing prototype for zynq_qspi_mem_exec_op

[Ashok Reddy Soma]

From: Algapally Santosh Sagar 

Add missing prototype to fix the sparse warning, warning: no
previous prototype for 'zynq_qspi_mem_exec_op' [-Wmissing-prototypes].

Signed-off-by: Algapally Santosh Sagar 
Signed-off-by: Ashok Reddy Soma 
---

 drivers/spi/zynq_qspi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/zynq_qspi.c b/drivers/spi/zynq_qspi.c
index d1d4048966..cb52c0f307 100644
--- a/drivers/spi/zynq_qspi.c
+++ b/drivers/spi/zynq_qspi.c
@@ -747,8 +747,8 @@ static int zynq_qspi_check_buswidth(struct spi_slave 
*slave, u8 width)
return -EOPNOTSUPP;
 }
 
-bool zynq_qspi_mem_exec_op(struct spi_slave *slave,
-  const struct spi_mem_op *op)
+static bool zynq_qspi_mem_exec_op(struct spi_slave *slave,
+ const struct spi_mem_op *op)
 {
if (zynq_qspi_check_buswidth(slave, op->cmd.buswidth))
return false;
-- 
2.17.1

[PATCH 2/6] xilinx: zynq: Add missing prototype for zynqmp_mmio_write

[Ashok Reddy Soma]

From: Algapally Santosh Sagar 

Add missing prototype to fix the sparse warning, warning: no
previous prototype for 'zynqmp_mmio_write' [-Wmissing-prototypes].

Signed-off-by: Algapally Santosh Sagar 
Signed-off-by: Ashok Reddy Soma 
---

 arch/arm/mach-zynq/include/mach/sys_proto.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-zynq/include/mach/sys_proto.h 
b/arch/arm/mach-zynq/include/mach/sys_proto.h
index 268ec50ad8..74f9665fbb 100644
--- a/arch/arm/mach-zynq/include/mach/sys_proto.h
+++ b/arch/arm/mach-zynq/include/mach/sys_proto.h
@@ -16,5 +16,6 @@ extern u32 zynq_slcr_get_idcode(void);
 extern int zynq_slcr_get_mio_pin_status(const char *periph);
 extern void zynq_ddrc_init(void);
 extern unsigned int zynq_get_silicon_version(void);
+int zynqmp_mmio_write(const u32 address, const u32 mask, const u32 value);
 
 #endif /* _SYS_PROTO_H_ */
-- 
2.17.1

[PATCH 1/6] spi: xilinx_spi: Add missing prototype for xilinx_qspi_mem_exec_op

[Ashok Reddy Soma]

From: Algapally Santosh Sagar 

Add missing prototype to fix the below sparse warning
warning: no previous prototype for 'xilinx_qspi_mem_exec_op'
[-Wmissing-prototypes]

Signed-off-by: Algapally Santosh Sagar 
Signed-off-by: Ashok Reddy Soma 
---

 drivers/spi/xilinx_spi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index 33575fe757..b58a3f632a 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -363,8 +363,8 @@ static int xilinx_qspi_check_buswidth(struct spi_slave 
*slave, u8 width)
return -EOPNOTSUPP;
 }
 
-bool xilinx_qspi_mem_exec_op(struct spi_slave *slave,
-const struct spi_mem_op *op)
+static bool xilinx_qspi_mem_exec_op(struct spi_slave *slave,
+   const struct spi_mem_op *op)
 {
if (xilinx_qspi_check_buswidth(slave, op->cmd.buswidth))
return false;
-- 
2.17.1

[PATCH 0/6] Fix sparse warnings in zynq platform

[Ashok Reddy Soma]

Fix below sparse warnings
 - Add missing prototype for zynqmp_mmio_write
 - Add missing prototype for zynq_qspi_mem_exec_op
 - Change datatype of status and ecc_status from u32 to int
 - Pass the missing argument type in function definition
 - Add the missing function prototypes
 - Add missing prototype for xilinx_qspi_mem_exec_op



Algapally Santosh Sagar (6):
  spi: xilinx_spi: Add missing prototype for xilinx_qspi_mem_exec_op
  xilinx: zynq: Add missing prototype for zynqmp_mmio_write
  spi: zynq_qspi: Add missing prototype for zynq_qspi_mem_exec_op
  mtd: nand: zynq_nand: Change datatype of status and ecc_status to int
  arm: zynq: Pass the missing argument type in function definition
  xilinx: zynq: Add the missing function prototypes

 arch/arm/mach-zynq/include/mach/sys_proto.h | 1 +
 board/xilinx/zynq/board.c   | 2 ++
 board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c | 4 ++--
 drivers/mtd/nand/raw/zynq_nand.c| 4 ++--
 drivers/spi/xilinx_spi.c| 4 ++--
 drivers/spi/zynq_qspi.c | 4 ++--
 6 files changed, 11 insertions(+), 8 deletions(-)

-- 
2.17.1

[PATCH 2/2] arm64: versal: Add missing prototypes

[Ashok Reddy Soma]

From: Algapally Santosh Sagar 

Add missing prototypes to fix the below sparse warnings
1. warning: no previous prototype for 'set_r5_halt_mode'
[-Wmissing-prototypes]
2. warning: no previous prototype for 'set_r5_tcm_mode'
[-Wmissing-prototypes]
3. warning: no previous prototype for 'release_r5_reset'
[-Wmissing-prototypes]
4.warning: no previous prototype for 'enable_clock_r5'
[-Wmissing-prototypes]

Signed-off-by: Algapally Santosh Sagar 
Signed-off-by: Ashok Reddy Soma 
---

 arch/arm/mach-versal/mp.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-versal/mp.c b/arch/arm/mach-versal/mp.c
index 9b0518d6a2..5b850f3f89 100644
--- a/arch/arm/mach-versal/mp.c
+++ b/arch/arm/mach-versal/mp.c
@@ -23,7 +23,7 @@
 #define VERSAL_CRL_RST_CPU_R5_RESET_PGE_MASK   0x10
 #define VERSAL_CRLAPB_CPU_R5_CTRL_CLKACT_MASK  0x100
 
-void set_r5_halt_mode(u8 halt, u8 mode)
+static void set_r5_halt_mode(u8 halt, u8 mode)
 {
u32 tmp;
 
@@ -44,7 +44,7 @@ void set_r5_halt_mode(u8 halt, u8 mode)
}
 }
 
-void set_r5_tcm_mode(u8 mode)
+static void set_r5_tcm_mode(u8 mode)
 {
u32 tmp;
 
@@ -62,7 +62,7 @@ void set_r5_tcm_mode(u8 mode)
writel(tmp, _base->rpu_glbl_ctrl);
 }
 
-void release_r5_reset(u8 mode)
+static void release_r5_reset(u8 mode)
 {
u32 tmp;
 
@@ -77,7 +77,7 @@ void release_r5_reset(u8 mode)
writel(tmp, _base->rst_cpu_r5);
 }
 
-void enable_clock_r5(void)
+static void enable_clock_r5(void)
 {
u32 tmp;
 
-- 
2.17.1

[PATCH 1/2] arm64: versal: Add missing prototype for initialize_tcm

[Ashok Reddy Soma]

From: Algapally Santosh Sagar 

Add the missing prototype pointed by below sparse warning
warning: no previous prototype for 'initialize_tcm'
[-Wmissing-prototypes]

Signed-off-by: Algapally Santosh Sagar 
Signed-off-by: Ashok Reddy Soma 
---

 arch/arm/mach-versal/include/mach/sys_proto.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-versal/include/mach/sys_proto.h 
b/arch/arm/mach-versal/include/mach/sys_proto.h
index 3f01508ecb..433f9ba07c 100644
--- a/arch/arm/mach-versal/include/mach/sys_proto.h
+++ b/arch/arm/mach-versal/include/mach/sys_proto.h
@@ -10,6 +10,7 @@ enum {
TCM_SPLIT,
 };
 
+void initialize_tcm(bool mode);
 void tcm_init(u8 mode);
 void mem_map_fill(void);
 
-- 
2.17.1

[PATCH 0/2] Fix sparse warnings

[Ashok Reddy Soma]

In this patch series, fix sparse warnings in below files
 - arch/arm/mach-versal/mp.c
 - arch/arm/mach-versal/include/mach/sys_proto.h



Algapally Santosh Sagar (2):
  arm64: versal: Add missing prototype for initialize_tcm
  arm64: versal: Add missing prototypes

 arch/arm/mach-versal/include/mach/sys_proto.h | 1 +
 arch/arm/mach-versal/mp.c | 8 
 2 files changed, 5 insertions(+), 4 deletions(-)

-- 
2.17.1

Re: rk3328 efuse return just 0

[Belisko Marek]

Hi Jonas,

On Fri, Jun 9, 2023 at 1:06 AM Jonas Karlman  wrote:

> Hi Marek,
>
> On 2023-06-08 15:06, Belisko Marek wrote:
> > Hi,
> >
> > I'm using tip of actual master and with this small patches:
> > --- a/configs/rock-pi-e-rk3328_defconfig
> > +++ b/configs/rock-pi-e-rk3328_defconfig
> > @@ -73,6 +73,8 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
> >  CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
> >  CONFIG_ROCKCHIP_GPIO=y
> >  CONFIG_SYS_I2C_ROCKCHIP=y
> > +CONFIG_MISC=y
> > +CONFIG_ROCKCHIP_EFUSE=y
> >  CONFIG_MMC_DW=y
> >  CONFIG_MMC_DW_ROCKCHIP=y
> >  CONFIG_ETH_DESIGNWARE=y
> >
> > --- a/configs/rock-pi-e-rk3328_defconfig
> > +++ b/configs/rock-pi-e-rk3328_defconfig
> > @@@ -45,8 -34,6 +45,7 @@@ CONFIG_SPL_I2C=
> >   CONFIG_SPL_POWER=y
> >   CONFIG_SPL_ATF=y
> >   CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
> >  +CONFIG_TPL_SYS_MALLOC_SIMPLE=y
> > - CONFIG_TPL_DRIVERS_MISC=y
> >   CONFIG_CMD_BOOTZ=y
> >   CONFIG_CMD_GPT=y
> >   CONFIG_CMD_MMC=y
> >
> > as for the following issue:
> >
> /home/marek/data/projects/u-boot/drivers/misc/rockchip-efuse.c:273:(.text.rockchip_efuse_of_to_plat+0x1c):
> > relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> > `dev_read_addr_ptr'
>
How about this issue? I can send a patch to fix that.

> >
> > I'm trying to enable proper ethaddr handling (as in this case cpuid# is
> > used for ethaddr generation).
> >
> > With those enabled options I'm still getting an cpuid# variable set to
> all
> > '0'. Is there some other fix necessary maybe?
>
> I was able to reproduce this issue on my Rock Pi E using plain mainline
> arm-trusted-firmware. To use efuse on RK3328 the efuse block needs to be
> initialized, u-boot does not do this.
>
Thanks for the info. I've applied a patch from armbian and it started
working!

>
> Two options to work around this can be:
> 1. Use vendor bl31 blob from [1]
> 2. Patch mainline atf with a patch from [2]
>
> [1]
> https://github.com/rockchip-linux/rkbin/blob/master/bin/rk33/rk322xh_bl31_v1.49.elf
> [2]
> https://github.com/armbian/build/blob/main/patch/atf/atf-rockchip64/rk3328-efuse-init.patch
>
> Regards,
> Jonas
>
> >
> > Thanks and BR,
> >
> > marek
>
> Cheers,

marek

Re: [PATCH] spl: spl_fit: add weak prototype for fpga_load

[Eugen Hristev]

On 2/27/23 12:27, Eugen Hristev wrote:

In case OPTIMIZE_DEBUG is set, unused code will not be optimized out, hence
the reference to fpga_load will be compiled.
if DM_FPGA and SPL_FPGA are not set, the build will fail with :

aarch64-none-linux-gnu-ld.bfd: common/spl/spl_fit.o: in function 
`spl_fit_upload_fpga':
u-boot/common/spl/spl_fit.c:595: undefined reference to `fpga_load'

By adding a weak prototype, build is successful.

Signed-off-by: Eugen Hristev 
---
  common/spl/spl_fit.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index c51482b3b659..ca2e337b1ec4 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -570,6 +570,12 @@ static void warn_deprecated(const char *msg)
printf("\tSee doc/uImage.FIT/source_file_format.txt\n");
  }
  
+__weak int fpga_load(int devnum, const void *buf, size_t bsize,

+bitstream_type bstype, int flags)
+{
+   return 0;
+}
+
  static int spl_fit_upload_fpga(struct spl_fit_info *ctx, int node,
   struct spl_image_info *fpga_image)
  {


Gentle ping

Re: [PATCH v6 1/7] dt/bindings: fwu-mdata-mtd: drop changes outside FWU

[Ilias Apalodimas]

On Mon, Mar 06, 2023 at 05:18:14PM -0600, jassisinghb...@gmail.com wrote:
> From: Jassi Brar 
> 
> Any requirement of FWU should not require changes to bindings
> of other subsystems. For example, for mtd-backed storage we
> can do without requiring 'fixed-partitions' children to also
> carry 'uuid', a property which is non-standard and not in the
> bindings.
> 


The existing bindings were constructed like that in case we wanted to
upstream the dt-bindings.  But I think we are fine keeping it as an
internal ABI for now.  Note here that we will need to strip this eventually
before we hand over the dtb into linux, but that's a different story.  In
any case as long as the DT comes from u-boot I don't think we will have a
risk of introducing compatibility issues if we ever upstream this and go
back to the old format. 

Acked-by: Ilias Apalodimas 

>  There exists no code yet, so we can change the fwu-mtd bindings
> to contain all properties within the fwu-mdata node.
> 
> Signed-off-by: Jassi Brar 
> ---
>  .../firmware/fwu-mdata-mtd.yaml   | 105 +++---
>  1 file changed, 91 insertions(+), 14 deletions(-)
> 
> diff --git a/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml 
> b/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml
> index 4f5404f999..6a22aeea30 100644
> --- a/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml
> +++ b/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml
> @@ -1,13 +1,13 @@
>  # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>  %YAML 1.2
>  ---
> -$id: http://devicetree.org/schemas/firmware/u-boot,fwu-mdata-sf.yaml#
> -$schema: http://devicetree.org/meta-schemas/core.yaml#
> +$id: http://devicetree.org/schemas/firmware/u-boot,fwu-mdata-mtd.yaml#
> +$schema: http://devicetree.org/meta-schemas/base.yaml#
>  
>  title: FWU metadata on MTD device without GPT
>  
>  maintainers:
> - - Masami Hiramatsu 
> + - Jassi Brar 
>  
>  properties:
>compatible:
> @@ -15,24 +15,101 @@ properties:
>- const: u-boot,fwu-mdata-mtd
>  
>fwu-mdata-store:
> -maxItems: 1
> -description: Phandle of the MTD device which contains the FWU medatata.
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description: Phandle of the MTD device which contains the FWU MetaData 
> and Banks.
>  
> -  mdata-offsets:
> +  mdata-parts:
> +$ref: /schemas/types.yaml#/definitions/non-unique-string-array
>  minItems: 2
> -description: Offsets of the primary and secondary FWU metadata in the 
> NOR flash.
> +maxItems: 2
> +description: labels of the primary and secondary FWU metadata partitions 
> in the 'fixed-partitions' subnode of the 'jedec,spi-nor' flash device node.
> +
> +  patternProperties:
> +"fwu-bank[0-9]":
> +type: object
> +description: List of FWU mtd-backed banks. Typically two banks.
> +
> +properties:
> +  id:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: Index of the bank.
> +
> +  label:
> +$ref: /schemas/types.yaml#/definitions/non-unique-string-array
> +minItems: 1
> +maxItems: 1
> +description: label of the partition, in the 'fixed-partitions' 
> subnode of the 'jedec,spi-nor' flash device node, that holds this bank.
> +
> +  patternProperties:
> +"fwu-image[0-9]":
> +type: object
> +description: List of images in the FWU mtd-backed bank.
> +
> +properties:
> +  id:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: Index of the bank.
> +
> +  offset:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: Offset, from start of the bank, where the image is 
> located.
> +
> +  size:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: Size reserved for the image.
> +
> +  uuid:
> +$ref: /schemas/types.yaml#/definitions/non-unique-string-array
> +minItems: 1
> +maxItems: 1
> +description: UUID of the image.
> +
> +required:
> +  - id
> +  - offset
> +  - size
> +  - uuid
> +additionalProperties: false
> +
> +required:
> +  - id
> +  - label
> +  - fwu-images
> +additionalProperties: false
>  
>  required:
>- compatible
>- fwu-mdata-store
> -  - mdata-offsets
> -
> +  - mdata-parts
> +  - fwu-banks
>  additionalProperties: false
>  
>  examples:
>- |
> -fwu-mdata {
> -compatible = "u-boot,fwu-mdata-mtd";
> -fwu-mdata-store = <>;
> -mdata-offsets = <0x50 0x53>;
> -};
> + fwu-mdata {
> + compatible = "u-boot,fwu-mdata-mtd";
> + fwu-mdata-store = <>;
> + mdata-parts = "MDATA-Pri", "MDATA-Sec";
> +
> + fwu-bank0 {
> + id = <0>;
> + label = "FIP-Bank0";
> + fwu-image0 {
> +   

Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration

[Peter Robinson]

On Thu, Jun 8, 2023 at 6:56 PM Ilias Apalodimas
 wrote:
>
> Thanks Maxim,
>
> On Thu, 8 Jun 2023 at 13:14, Maxim Uvarov  wrote:
> >
> > Ilias asked to make more clear results to compare the original stack and 
> > LWIP stack. So the difference between the current U-boot stack and the LWIP 
> > stack with 3 network commands is:
> > a) 18Kb  - ls -lh size
> > b) 15Kb - bloat-o-meter script total line report.
> >
> > BOM=linux/scripts/bloat-o-meter (script)
> >
> > 1. 893K - U-boot CMD_NET=n
> > 2. 928K - U-boot CMD_NET=y TFTP=y PING=y WGET=y
> > BOM 1-2: Total: Before=692286, After=722283, chg +4.33%
> > 3. 940K - U-boot CMD_NET=n, LWIP_TFTP=y LWIP_PING=y LWIP_PING=y
> > BOM 1-3: Total: Before=692286, After=738425, chg +6.66%
>
> That's much more readable! I discussed this with Tom over IRC and the
> size difference is certainly a reasonable trade-off for the extra
> functionality.

Yes, this looks great! I'm also sure with a closer look there could be
further optimisations here in time as well. I feel having a widely
used IP stack that's also widely audited is a big win here, it will
also provide things like HTTP, DNS and IPv6 without having to reinvent
the wheel.

> Can you tidy up the series and include DHCP and PXE done through LWIP?

I'll look forward to this.

> Thanks
> /Ilias
> >
> > BOM 2-3:
> >
> > add/remove: 287/203 grow/shrink: 3/11 up/down: 43459/-27317 (16142)
> > Function old new   delta
> > tcp_input  -3588   +3588
> > tcp_receive-2884   +2884
> > ip4_reass  -1760   +1760
> > tcp_output -1400   +1400
> > tcp_write  -1300   +1300
> > tcp_slowtmr-1172   +1172
> > httpc_tcp_recv -1044   +1044
> > tftp_recv  - 888+888
> > ip4_input  - 700+700
> > ip4_frag   - 632+632
> > icmp_input - 604+604
> > udp_input  - 596+596
> > etharp_input   - 512+512
> > tcp_split_unsent_seg   - 500+500
> > ip4addr_aton   - 492+492
> > tcp_alloc  - 484+484
> > ip4_output_if_src  - 476+476
> > tcp_close_shutdown - 448+448
> > etharp_query   - 436+436
> > httpc_init_connection_common.constprop - 416+416
> > udp_sendto_if_src  - 408+408
> > etharp_output  - 404+404
> > arp_table  - 400+400
> > tcp_connect- 396+396
> > pbuf_alloc - 376+376
> > etharp_find_entry  - 372+372
> > tcp_abandon- 368+368
> > tcp_zero_window_probe  - 356+356
> > raw_sendto_if_src  - 328+328
> > pbuf_copy_partial_pbuf - 328+328
> > ip_reass_free_complete_datagram- 328+328
> > tcp_create_segment - 300+300
> > raw_input  - 292+292
> > uboot_lwip_init- 284+284
> > ethernet_input - 284+284
> > etharp_raw - 284+284
> > tcp_output_alloc_header_common.constprop   - 280+280
> > cmds   - 280+280
> > udp_bind   - 276+276
> > tcp_oos_insert_segment - 276+276
> > ip_reass_remove_oldest_datagram- 272+272
> > icmp_send_response - 268+268
> > netif_add  - 260+260
> > ping_send  - 244+244
> > tcp_rexmit - 232+232
> > tcp_parseopt   - 220+220
> > tcp_free_acked_segments.constprop  - 220+220
> > send_request   - 220+220
> > inet_chksum_pseudo - 216+216
> > ip4addr_ntoa_r - 212+212
> > do_lwip_ping   - 212+212
> >