Re: [EXT] [PATCH] ARM: imx: romapi: Repair FlexSPI NOR boot offset

2022-03-28 Thread Ye Li

On Mon, 2022-03-28 at 16:54 +0200, Marek Vasut wrote:
> Caution: EXT Email
> 
> On 3/28/22 08:54, Ye Li wrote:
> > 
> > Hi Marek,
> Hi,
> 
> [...]
> 
> > 
> > > 
> > > > 
> > > > 2. Update the u-boot.itb offset in imx8mp-u-boot.dtsi, set the
> > > > offset
> > > > to 0x5f000.  The previous offset 0x58000 is for SD, calculated
> > > > by
> > > > 0x6 - 0x8000 (32KB image offset).
> > > > 
> > > >    uboot: blob-ext@2 {
> > > >    filename = "u-boot.itb";
> > > >    offset = <0x5f000>;
> > > >    };
> > > But that breaks booting from SD card for me ?
> > Do you want to use one flash.bin for both SD and flexspi?
> Yes, the board I use can boot from SD/eMMC/FlexSPI. I don't want to
> build multiple confusing "flash.bin" files, one for each boot media.
> 
> > 
> > When first introduced 8m support by imx8mimage.c, we expected the
> > u-
> > boot.itb at same device offset (0x6) on SD/emmc and flexspi.
> > The
> > imx8mimage will calculate the offset inside the flash.bin
> > automatically
> > according to different IVT offset. The ROMAPI driver also works
> > correspondingly.
> > After using binman, the u-boot.itb offset inside the flash.bin has
> > to
> > be manually set in this DTS node. To follow the original design,
> > this
> > offset should be different. That's why I asked to update this dts
> > node
> > for flexspi.
> This does imply that there are currently no users that boot from
> flexspi
> in upstream U-Boot, because such users would have to manually modify
> both arch/arm/dts/imx8m?-u-boot.dtsi and board/*/imximage.cfg to
> generate suitable flash.bin which can be started from FlexSPI.
> 
> Also, git grep confirms that there are no users:
> 
> u-boot$ git grep BOOT_FROM.*fspi
> doc/imx/mkimage/imx8image.txt:BOOT_FROM
> [sd|emmc_fastboot|fspi|nand_4k|nand_8k|nand_16k] [sector_size]
> 
> > 
> > If you change the ROM API driver, that will break our design. You
> > can
> > try to overwrite spl_romapi_get_uboot_base for your board only.
> Since there are no users which boot from flexspi upstream, this
> design
> can still be fixed such that it does not require different flash.bin
> for
> different boot media, but rather one flash.bin works on all boot
> media.
> I think that is much better.

Your flash.bin can work on flexspi because you manually program the
flexspi configurations header.  But once you want to upgrade the
flash.bin, flexspi configurations will also be erased due to the block
size. Then you have to reprogram the configurations with flash.bin.
So most of our customers add the flexspi configurations to flash.bin
head. They don't use so called one image for both SD and flexspi. 

As the spl_romapi_get_uboot_base is defined to weak. It is better to
overwrite this function for your particular usage.

Best regards,
Ye Li
> 
> [...]

[PATCH v5] pinctrl: nuvoton: Add NPCM8xx pinctrl driver

2022-03-28 Thread Stanley Chu
Add Nuvoton BMC NPCM845 Pinmux and Pinconf support.

Signed-off-by: Stanley Chu 
---
v5:
 - lower-case hex consistently
 - use uint type for pin list in the group_config struct
v4:
 - correct the pin flags, add slew rate control suuport for rgmii pins
v3:
 - separate group names and function names in different tables
   to allow for adding additional functions
v2:
 - drop the WDnRCRB/CORSTCB register access, it is not for
   GPIO modules reset control
---
 drivers/pinctrl/Kconfig   |1 +
 drivers/pinctrl/Makefile  |1 +
 drivers/pinctrl/nuvoton/Kconfig   |   12 +
 drivers/pinctrl/nuvoton/Makefile  |1 +
 drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c | 1185 +
 5 files changed, 1200 insertions(+)
 create mode 100644 drivers/pinctrl/nuvoton/Kconfig
 create mode 100644 drivers/pinctrl/nuvoton/Makefile
 create mode 100644 drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 03946245c7..076aff1a8d 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -329,6 +329,7 @@ source "drivers/pinctrl/mscc/Kconfig"
 source "drivers/pinctrl/mtmips/Kconfig"
 source "drivers/pinctrl/mvebu/Kconfig"
 source "drivers/pinctrl/nexell/Kconfig"
+source "drivers/pinctrl/nuvoton/Kconfig"
 source "drivers/pinctrl/nxp/Kconfig"
 source "drivers/pinctrl/renesas/Kconfig"
 source "drivers/pinctrl/rockchip/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index df37c32033..de84f8912b 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_ARCH_ASPEED) += aspeed/
 obj-$(CONFIG_ARCH_ATH79) += ath79/
 obj-$(CONFIG_PINCTRL_INTEL) += intel/
 obj-$(CONFIG_ARCH_MTMIPS) += mtmips/
+obj-$(CONFIG_ARCH_NPCM) += nuvoton/
 obj-$(CONFIG_ARCH_RMOBILE) += renesas/
 obj-$(CONFIG_PINCTRL_SANDBOX)  += pinctrl-sandbox.o
 
diff --git a/drivers/pinctrl/nuvoton/Kconfig b/drivers/pinctrl/nuvoton/Kconfig
new file mode 100644
index 00..519539d6ae
--- /dev/null
+++ b/drivers/pinctrl/nuvoton/Kconfig
@@ -0,0 +1,12 @@
+config PINCTRL_NPCM8XX
+   bool "Pinctrl driver for Nuvoton NPCM8XX"
+   depends on DM && PINCTRL_GENERIC && ARCH_NPCM8XX
+   help
+ Support pin muxing and pin configuration on
+ Nuvoton NPCM8XX SoC.
+
+ The NPCM8XX contains 256 GPIO pins. Most of them are
+ multiplexed with other system functions. These pins can
+ be configured as either GPIO pin or alternate function.
+ It also supports basic configurations such as pull up/down,
+ drive-strength, and slew rate control for some of the pins.
diff --git a/drivers/pinctrl/nuvoton/Makefile b/drivers/pinctrl/nuvoton/Makefile
new file mode 100644
index 00..a6dfdf3672
--- /dev/null
+++ b/drivers/pinctrl/nuvoton/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PINCTRL_NPCM8XX)  += pinctrl-npcm8xx.o
diff --git a/drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c 
b/drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c
new file mode 100644
index 00..ca6c5b9aa9
--- /dev/null
+++ b/drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c
@@ -0,0 +1,1185 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2022 Nuvoton Technology Corp.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* GCR register offsets */
+#define WD0RCR 0x38
+#define WD1RCR 0x3c
+#define WD2RCR 0x40
+#define SWRSTC10x44
+#define SWRSTC20x48
+#define SWRSTC30x4c
+#define SWRSTC40x50
+#define CORSTC 0x5c
+#define FLOCKR10x74
+#define INTCR4 0xc0
+#define I2CSEGSEL  0xe0
+#define MFSEL1 0x260
+#define MFSEL2 0x264
+#define MFSEL3 0x268
+#define MFSEL4 0x26c
+#define MFSEL5 0x270
+#define MFSEL6 0x274
+#define MFSEL7 0x278
+
+/* GPIO register offsets */
+#define GPIO_POL   0x08 /* Polarity */
+#define GPIO_DOUT  0x0c /* Data OUT */
+#define GPIO_OTYP  0x14 /* Output Type */
+#define GPIO_PU0x1c /* Pull-up */
+#define GPIO_PD0x20 /* Pull-down */
+#define GPIO_DBNC  0x24 /* Debounce */
+#define GPIO_EVEN  0x40 /* Event Enable */
+#define GPIO_EVST  0x4c /* Event Status */
+#define GPIO_IEM   0x58 /* Input Enable */
+#define GPIO_OSRC  0x5c /* Output Slew-Rate Control */
+#define GPIO_ODSC  0x60 /* Output Drive Strength Control */
+#define GPIO_OES   0x70 /* Output Enable Set */
+#define GPIO_OEC   0x74 /* Output Enable Clear */
+
+#define NPCM8XX_GPIO_PER_BANK  32
+#define GPIOX_OFFSET   16
+
+/* The lists contain alternate GPIO pins of the function */
+/* Serial Interfaces */
+static const uint hsi1a_pins[] = { 43, 63 };
+static const uint hsi1b_pins[] = { 44, 62 };
+static const uint hsi1c_pins[] = { 45, 46, 47, 61 };
+static const uint hsi2a_pins[] = { 48, 49 };
+static 

Re: [PATCH v4 00/33] Initial implementation of standard boot

2022-03-28 Thread Tom Rini
On Sat, Mar 26, 2022 at 02:51:05PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Sat, 26 Mar 2022 at 13:58, Tom Rini  wrote:
> >
> > On Sat, Mar 26, 2022 at 01:56:36PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 25 Mar 2022 at 08:50, Tom Rini  wrote:
> > > >
> > > > On Fri, Mar 25, 2022 at 03:36:24PM +0100, Michael Nazzareno Trimarchi 
> > > > wrote:
> > > > > Hi Tom
> > > > >
> > > > >
> > > > > On Wed, Mar 23, 2022 at 9:07 PM Tom Rini  wrote:
> > > > > >
> > > > > > On Wed, Mar 23, 2022 at 08:57:36PM +0100, Michael Nazzareno 
> > > > > > Trimarchi wrote:
> > > > > > > Hi Tom
> > > > > > >
> > > > > > > On Wed, Mar 23, 2022 at 8:30 PM Tom Rini  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Wed, Mar 23, 2022 at 08:21:22PM +0100, Michael Nazzareno 
> > > > > > > > Trimarchi wrote:
> > > > > > > > > Hi Tom
> > > > > > > > >
> > > > > > > > > On Wed, Mar 23, 2022 at 7:46 PM Simon Glass 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Wed, 23 Mar 2022 at 08:05, Tom Rini  
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Sun, Mar 06, 2022 at 05:49:43AM -0700, Simon Glass 
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > The bootflow feature provide a built-in way for U-Boot 
> > > > > > > > > > > > to automatically
> > > > > > > > > > > > boot an Operating System without custom scripting and 
> > > > > > > > > > > > other customisation.
> > > > > > > > > > > > This is called 'standard boot' since it provides a 
> > > > > > > > > > > > standard way for
> > > > > > > > > > > > U-Boot to boot a distro, without scripting.
> > > > > > > > > > > >
> > > > > > > > > > > > It introduces the following concepts:
> > > > > > > > > > > >
> > > > > > > > > > > >- bootdev - a device which can hold a distro
> > > > > > > > > > > >- bootmeth - a method to scan a bootdev to find 
> > > > > > > > > > > > bootflows (owned by
> > > > > > > > > > > > U-Boot)
> > > > > > > > > > > >- bootflow - a description of how to boot (owned by 
> > > > > > > > > > > > the distro)
> > > > > > > > > > > >
> > > > > > > > > > > > This series provides an implementation of these, 
> > > > > > > > > > > > enabled to scan for
> > > > > > > > > > > > bootflows from MMC, USB and Ethernet. It supports the 
> > > > > > > > > > > > existing distro
> > > > > > > > > > > > boot as well as the EFI loader flow (bootefi/bootmgr). 
> > > > > > > > > > > > It works
> > > > > > > > > > > > similiarly to the existing script-based approach, but 
> > > > > > > > > > > > is native to
> > > > > > > > > > > > U-Boot.
> > > > > > > > > > > >
> > > > > > > > > > > > With this we can boot on a Raspberry Pi 3 with just one 
> > > > > > > > > > > > command:
> > > > > > > > > > > >
> > > > > > > > > > > >bootflow scan -lb
> > > > > > > > > > > >
> > > > > > > > > > > > which means to scan, listing (-l) each bootflow and 
> > > > > > > > > > > > trying to boot each
> > > > > > > > > > > > one (-b). The final patch shows this.
> > > > > > > > > > > >
> > > > > > > > > > > > With a standard way to identify boot devices, booting 
> > > > > > > > > > > > become easier. It
> > > > > > > > > > > > also should be possible to support U-Boot scripts, for 
> > > > > > > > > > > > backwards
> > > > > > > > > > > > compatibility only.
> > > > > > > > > > > >
> > > > > > > > > > > > This series relies on the PXE clean-up series, posted 
> > > > > > > > > > > > here:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=267078
> > > > > > > > > > > >
> > > > > > > > > > > > For documentation, see the 'doc' patch.
> > > > > > > > > > > >
> > > > > > > > > > > > For version 2, a new naming scheme is used as above:
> > > > > > > > > > > >
> > > > > > > > > > > >- bootdev is used instead of bootdevice, because 
> > > > > > > > > > > > 'device' is overused,
> > > > > > > > > > > >is everywhere in U-Boot, can be confused with 
> > > > > > > > > > > > udevice
> > > > > > > > > > > >- bootmeth - because 'method' is too vanilla, 
> > > > > > > > > > > > appears 1300 times in
> > > > > > > > > > > >U-Boot
> > > > > > > > > > > >
> > > > > > > > > > > > Also in version 2, drivers are introduced for the boot 
> > > > > > > > > > > > methods, to make
> > > > > > > > > > > > it more extensible. Booting a custom OS is simply a 
> > > > > > > > > > > > matter of creating a
> > > > > > > > > > > > bootmeth for it and implementing the read_file() and 
> > > > > > > > > > > > boot() methods.
> > > > > > > > > > > >
> > > > > > > > > > > > Version 4 makes some minor improvements and leaves out 
> > > > > > > > > > > > the RFC patch for
> > > > > > > > > > > > rpi conversion, in the hope of getting the base support 
> > > > > > > > > > > > applied sooner
> > > > > > > > > > > > rather than later.
> > > > > > > > > > > >
> > > > > > > 

Re: [PATCH 1/2] net: dsa: fix phydev->speed being uninitialized for the CPU port fixed PHY

2022-03-28 Thread Vladimir Oltean
On Mon, Mar 28, 2022 at 03:23:02PM -0700, Tim Harvey wrote:
> On Mon, Mar 28, 2022 at 2:26 AM Vladimir Oltean  
> wrote:
> >
> > On Fri, Mar 25, 2022 at 02:03:56PM -0700, Tim Harvey wrote:
> > > On Fri, Mar 25, 2022 at 11:07 AM Vladimir Oltean
> > >  wrote:
> > > >
> > > > Hi Tim,
> > > >
> > > > On Fri, Mar 25, 2022 at 09:53:20AM -0700, Tim Harvey wrote:
> > > > > Vladimir,
> > > > >
> > > > > I came across this while looking for the best place to configure cpu
> > > > > port interface mode (ie rgmii id) for the mv88e61xx dsa driver I'm
> > > > > working on. Note that this patch causes port_probe to be called on the
> > > > > cpu port 'before' the master device has been probed. I'm not sure if
> > > > > this is intended or not?
> > > > >
> > > > > In my case I was looking to configure the cpu port interface mode when
> > > > > the port was probed but I can't do that because it happens before the
> > > > > switch is probed because of some things that need to happen there.
> > > > > Best Regards,
> > > > >
> > > > > Tim
> > > >
> > > > You're past the DM_MDIO probing issues now? Glad to hear that.
> > > > Probing the DSA CPU port before the master wasn't necessarily the
> > > > intention, but then again, I'm not sure that there's a strict ordering
> > > > guarantee between the two that needs to be satisfied?
> > > >
> > > > What do you need exactly? We could probably always reverse the
> > > > device_probe(master) call with the probing of the CPU port if the
> > > > ordering turns out to be a real problem. I can regression-test the
> > > > change on my boards, but I'd like to understand the need you have, maybe
> > > > even document it so that future changes are aware of it.
> > >
> > > Yes, I've got the mdio probing working now. The mv88e61xx driver
> > > supports several chips that have different register offsets that need
> > > to be known before indirect read/write and port read/write can be
> > > used. That detection happens early on so I have it in the dsa_probe. I
> > > would prefer to configure the cpu port interface mode (mac mode, link
> > > speed/duplex etc) once instead of doing it every time the cpu port
> > > gets enabled so I want to put that in the dsa_probe but at that time I
> > > don't have the phy_device to determine interface mode (I suppose I
> > > could get it from dt?). I noticed dsa_class calls ops->port_probe for
> > > the cpu port early so that seemed like a great place to do all that,
> > > but then I found my switch dsa_probe hadn't been called yet so I
> > > haven't identified the switch and set the register offsets yet.
> > >
> > > I have worked around the fact that the port_probe is called for the
> > > cpu port before the switch is probed I just wasn't sure if something
> > > in this patch should be changed in case others fall into this trap in
> > > the future. dsa_port_probe probes the master before calling
> > > ops->port_probe with the comment 'We depend on the master device for
> > > proper operation' so I just figured the same should be done for the
> > > pre_probe.
> >
> > Sorry, that was quite a blunder, we should definitely ensure that
> > U_BOOT_DRIVER :: probe gets called before dsa_ops :: port_probe.
> > I've made a change moving the port_probe call for the CPU port to
> > dsa_post_probe(), tested it in the sandbox, and it appears to work.
> >
> 
> Ok, sounds good - did you submit this someplace? I haven't seen it.

No, I didn't submit it anywhere. My thinking is that since the existing
DSA drivers aren't critically affected by the calling order, you could
include a change along those lines in your work for Marvell switches.

> > > I hope to send a series in the next few days but I do have a few items
> > > I still need to fix:
> > >
> > > 1. my board currently uses the mv88e61xx_hw_reset weak override to
> > > configure LEDs, GPIO's using direct register writes as I need one of
> > > the GPIO's to be configured as a 125MHz RGMII_RCLK and configure MAC
> > > interface mode(rgmii delays). I've moved the mac interface config into
> > > the driver based on the dt props (phy-mode and fixed-link subnode) but
> > > am still not sure how to go about dealing with the 'very custom' LED
> > > and GPIO config without the hassle of defining new dt bindings. I was
> > > hoping to use board_phy_config() but when that is called for the
> > > switch the phy_id is a generic PHY_FIXED_ID and when called for the
> > > ports the phydev->bus uses indirect register writes which can't be
> > > used to configure the gpios.
> >
> > How are these configs handled in Linux?
> 
> Each of the 14 GPIO's for MV88E61xx can be configured as GPIO,
> PTP_TRIG (PTP output trigger), PTP_EVREQ (PTP event request input),
> PTP_EXTCLK (PTP ext clock input), SE_RCLK0 (SyncE RX clock 0 output),
> SE_RCLK1 (SyncE RX clock 1 output), or CLK125 (125 MHz clock output).
> Currently the only config handled in Linux is PTP_EVREQ for PTP
> support.
> 
> Each port has 2 LED's which can be configured for 16 

Re: Please pull u-boot-video/next

2022-03-28 Thread Tom Rini
On Mon, Mar 28, 2022 at 10:37:52PM +0200, Anatolij Gustschin wrote:

> Hi Tom,
> 
> please pull video patches for next.
> 
> CI: https://source.denx.de/u-boot/custodians/u-boot-video/-/pipelines/11483
> 
> Thanks,
> Anatolij
> 
> The following changes since commit 34d2b7f20369d62c0f091d6572a8c0ea4655cf14:
> 
>   Merge tag 'v2022.04-rc5' into next (2022-03-28 12:36:49 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-video.git tags/next-20220328
> 
> for you to fetch changes up to 60cc4094485bf44b5ad455b51076f0e07f3f793a:
> 
>   video: Drop CONFIG_LCD_BMP_RLE8 (2022-03-28 20:30:33 +0200)
> 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] power-domain: Fix use of uninitialized value in dev_power_domain_ctrl

2022-03-28 Thread Jaehoon Chung
On 3/24/22 03:26, Sean Anderson wrote:
> If dev_count_phandle_with_args returns 0 or another error, then pd will never
> have been initialized by power_domain_get_by_index. Avoid comparing against
> pd.dev in this situation.
> 
> Fixes: 3e4fcfa4bc ("power-domain: fix hang in endless loop on i.MX8")
> Signed-off-by: Sean Anderson 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
> 
>  drivers/power/domain/power-domain-uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/domain/power-domain-uclass.c 
> b/drivers/power/domain/power-domain-uclass.c
> index 33f9206bd0..1a317a00aa 100644
> --- a/drivers/power/domain/power-domain-uclass.c
> +++ b/drivers/power/domain/power-domain-uclass.c
> @@ -137,7 +137,7 @@ static int dev_power_domain_ctrl(struct udevice *dev, 
> bool on)
>* off their power-domain parent. So we will get here again and
>* again and will be stuck in an endless loop.
>*/
> - if (!on && dev_get_parent(dev) == pd.dev &&
> + if (count > 0 && !on && dev_get_parent(dev) == pd.dev &&
>   device_get_uclass_id(dev) == UCLASS_POWER_DOMAIN)
>   return ret;
>  



Re: [PATCH] mmc: zynq_sdhci: Fix SDx_BASECLK configuration

2022-03-28 Thread Jaehoon Chung
On 3/25/22 21:11, Michal Simek wrote:
> From: Ashok Reddy Soma 
> 
> The DLL mode supported SD reference clocks are 50 MHz, 100 MHz and
> 200 MHz. When user select SD frequency as 200MHz in the design, the
> actual frequency is going to come around ~187MHz (<= 200MHz considering
> the parent clock and divisor selection). We need to set SDx_BASECLK as
> 200 in this case, setting 187 will result in tuning failures in mmc.
> 
> Set SDx_BASECLK to exact value of 200, 100 or 50 based on the frequency
> range.
> 
> Signed-off-by: Ashok Reddy Soma 
> Signed-off-by: Michal Simek 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
> 
>  drivers/mmc/zynq_sdhci.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
> index d96f5d543f54..a59d96c6bdad 100644
> --- a/drivers/mmc/zynq_sdhci.c
> +++ b/drivers/mmc/zynq_sdhci.c
> @@ -765,6 +765,15 @@ static int sdhci_zynqmp_set_dynamic_config(struct 
> arasan_sdhci_priv *priv,
>  
>   mhz = DIV64_U64_ROUND_UP(clock, 100);
>  
> + if (mhz > 100 && mhz <= 200)
> + mhz = 200;
> + else if (mhz > 50 && mhz <= 100)
> + mhz = 100;
> + else if (mhz > 25 && mhz <= 50)
> + mhz = 50;
> + else
> + mhz = 25;
> +
>   ret = zynqmp_pm_set_sd_config(node_id, SD_CONFIG_BASECLK, mhz);
>   if (ret) {
>   dev_err(dev, "SD_CONFIG_BASECLK failed\n");



Re: [PATCH 19/22] exynos: Drop CONFIG_CLK_*

2022-03-28 Thread Jaehoon Chung
On 3/24/22 06:20, Tom Rini wrote:
> We only set one of these values ever at this point, so remove dead code.
> 
> Cc: Minkyu Kang 
> Cc: Jaehoon Chung 
> Signed-off-by: Tom Rini 


Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
>  arch/arm/mach-exynos/exynos4_setup.h | 20 
>  include/configs/origen.h |  2 --
>  include/configs/smdkv310.h   |  2 --
>  3 files changed, 24 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/exynos4_setup.h 
> b/arch/arm/mach-exynos/exynos4_setup.h
> index 38735f002f10..a08d64a8e23e 100644
> --- a/arch/arm/mach-exynos/exynos4_setup.h
> +++ b/arch/arm/mach-exynos/exynos4_setup.h
> @@ -11,19 +11,6 @@
>  #include 
>  #include 
>  
> -#ifdef CONFIG_CLK_800_330_165
> -#define DRAM_CLK_330
> -#endif
> -#ifdef CONFIG_CLK_1000_200_200
> -#define DRAM_CLK_200
> -#endif
> -#ifdef CONFIG_CLK_1000_330_165
> -#define DRAM_CLK_330
> -#endif
> -#ifdef CONFIG_CLK_1000_400_200
> -#define DRAM_CLK_400
> -#endif
> -
>  /* Bus Configuration Register Address */
>  #define ASYNC_CONFIG 0x10010350
>  
> @@ -562,15 +549,8 @@ struct mem_timings {
>  #define  TIMINGPOWER_VAL 0x52000A3C
>  #else
>  #define TIMINGREF_VAL0x00BC
> -#ifdef DRAM_CLK_330
> -#define TIMINGROW_VAL0x3545548d
> -#define  TIMINGDATA_VAL  0x45430506
> -#define  TIMINGPOWER_VAL 0x4439033c
> -#endif
> -#ifdef DRAM_CLK_400
>  #define TIMINGROW_VAL0x45430506
>  #define  TIMINGDATA_VAL  0x56500506
>  #define  TIMINGPOWER_VAL 0x5444033d
>  #endif
>  #endif
> -#endif
> diff --git a/include/configs/origen.h b/include/configs/origen.h
> index 22325180ce0e..e8b54def9288 100644
> --- a/include/configs/origen.h
> +++ b/include/configs/origen.h
> @@ -46,8 +46,6 @@
>  "bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
>  "source ${loadaddr}\0"
>  
> -#define CONFIG_CLK_1000_400_200
> -
>  /* MIU (Memory Interleaving Unit) */
>  #define CONFIG_MIU_2BIT_21_7_INTERLEAVED
>  
> diff --git a/include/configs/smdkv310.h b/include/configs/smdkv310.h
> index 84b8537e54df..9ff05fcca789 100644
> --- a/include/configs/smdkv310.h
> +++ b/include/configs/smdkv310.h
> @@ -38,8 +38,6 @@
>  
>  /* FLASH and environment organization */
>  
> -#define CONFIG_CLK_1000_400_200
> -
>  /* MIU (Memory Interleaving Unit) */
>  #define CONFIG_MIU_2BIT_INTERLEAVED
>  



Re: [PATCH] mmc: rockchip_sdhci: Correct error checking

2022-03-28 Thread Jaehoon Chung
On 3/22/22 21:58, li.hao...@qq.com wrote:
> From: Haolin Li 
> 
> A pointer can not be negative. Use macro IS_ERR_OR_NULL() for checking.
> 
> Signed-off-by: Haolin Li 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
>  drivers/mmc/rockchip_sdhci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
> index f3f9d83ba3..a46895299d 100644
> --- a/drivers/mmc/rockchip_sdhci.c
> +++ b/drivers/mmc/rockchip_sdhci.c
> @@ -227,7 +227,7 @@ static int rk3399_emmc_get_phy(struct udevice *dev)
>   }
>  
>   grf_base = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
> - if (grf_base < 0) {
> + if (IS_ERR_OR_NULL(grf_base)) {
>   printf("%s Get syscon grf failed", __func__);
>   return -ENODEV;
>   }



Re: [PATCH 1/2] net: dsa: fix phydev->speed being uninitialized for the CPU port fixed PHY

2022-03-28 Thread Tim Harvey
On Mon, Mar 28, 2022 at 2:26 AM Vladimir Oltean  wrote:
>
> On Fri, Mar 25, 2022 at 02:03:56PM -0700, Tim Harvey wrote:
> > On Fri, Mar 25, 2022 at 11:07 AM Vladimir Oltean
> >  wrote:
> > >
> > > Hi Tim,
> > >
> > > On Fri, Mar 25, 2022 at 09:53:20AM -0700, Tim Harvey wrote:
> > > > Vladimir,
> > > >
> > > > I came across this while looking for the best place to configure cpu
> > > > port interface mode (ie rgmii id) for the mv88e61xx dsa driver I'm
> > > > working on. Note that this patch causes port_probe to be called on the
> > > > cpu port 'before' the master device has been probed. I'm not sure if
> > > > this is intended or not?
> > > >
> > > > In my case I was looking to configure the cpu port interface mode when
> > > > the port was probed but I can't do that because it happens before the
> > > > switch is probed because of some things that need to happen there.
> > > > Best Regards,
> > > >
> > > > Tim
> > >
> > > You're past the DM_MDIO probing issues now? Glad to hear that.
> > > Probing the DSA CPU port before the master wasn't necessarily the
> > > intention, but then again, I'm not sure that there's a strict ordering
> > > guarantee between the two that needs to be satisfied?
> > >
> > > What do you need exactly? We could probably always reverse the
> > > device_probe(master) call with the probing of the CPU port if the
> > > ordering turns out to be a real problem. I can regression-test the
> > > change on my boards, but I'd like to understand the need you have, maybe
> > > even document it so that future changes are aware of it.
> >
> > Yes, I've got the mdio probing working now. The mv88e61xx driver
> > supports several chips that have different register offsets that need
> > to be known before indirect read/write and port read/write can be
> > used. That detection happens early on so I have it in the dsa_probe. I
> > would prefer to configure the cpu port interface mode (mac mode, link
> > speed/duplex etc) once instead of doing it every time the cpu port
> > gets enabled so I want to put that in the dsa_probe but at that time I
> > don't have the phy_device to determine interface mode (I suppose I
> > could get it from dt?). I noticed dsa_class calls ops->port_probe for
> > the cpu port early so that seemed like a great place to do all that,
> > but then I found my switch dsa_probe hadn't been called yet so I
> > haven't identified the switch and set the register offsets yet.
> >
> > I have worked around the fact that the port_probe is called for the
> > cpu port before the switch is probed I just wasn't sure if something
> > in this patch should be changed in case others fall into this trap in
> > the future. dsa_port_probe probes the master before calling
> > ops->port_probe with the comment 'We depend on the master device for
> > proper operation' so I just figured the same should be done for the
> > pre_probe.
>
> Sorry, that was quite a blunder, we should definitely ensure that
> U_BOOT_DRIVER :: probe gets called before dsa_ops :: port_probe.
> I've made a change moving the port_probe call for the CPU port to
> dsa_post_probe(), tested it in the sandbox, and it appears to work.
>

Ok, sounds good - did you submit this someplace? I haven't seen it.

> > I hope to send a series in the next few days but I do have a few items
> > I still need to fix:
> >
> > 1. my board currently uses the mv88e61xx_hw_reset weak override to
> > configure LEDs, GPIO's using direct register writes as I need one of
> > the GPIO's to be configured as a 125MHz RGMII_RCLK and configure MAC
> > interface mode(rgmii delays). I've moved the mac interface config into
> > the driver based on the dt props (phy-mode and fixed-link subnode) but
> > am still not sure how to go about dealing with the 'very custom' LED
> > and GPIO config without the hassle of defining new dt bindings. I was
> > hoping to use board_phy_config() but when that is called for the
> > switch the phy_id is a generic PHY_FIXED_ID and when called for the
> > ports the phydev->bus uses indirect register writes which can't be
> > used to configure the gpios.
>
> How are these configs handled in Linux?

Each of the 14 GPIO's for MV88E61xx can be configured as GPIO,
PTP_TRIG (PTP output trigger), PTP_EVREQ (PTP event request input),
PTP_EXTCLK (PTP ext clock input), SE_RCLK0 (SyncE RX clock 0 output),
SE_RCLK1 (SyncE RX clock 1 output), or CLK125 (125 MHz clock output).
Currently the only config handled in Linux is PTP_EVREQ for PTP
support.

Each port has 2 LED's which can be configured for 16 different
functions. The LED config is not handled at all the the Linux driver
(PHY LED config is spotty in general).

I think it makes sense to handle this in board_config_phy() and I can
do and avoid the issue of direct register access with something like:

int board_phy_config(struct phy_device *phydev)
{
unsigned short val;

/* Fixed PHY: for GW5904/GW5909 this is Marvell 88E6176 GbE Switch */
if (phydev->phy_id == 0xa5a55a5a 

[PATCH] dm: core: Provide fallbacks for ofnode_conf_read_...

2022-03-28 Thread Sean Anderson
Because fdt_get_config_str et al. were moved/renamed to
ofnode_conf_read_str, they now depend on CONFIG_DM as well as
CONFIG_OF_CONTROL. Add some fallback implementations, preventing a
linker error when CONFIG_SPL_OF_CONTROL and CONFIG_SPL_ENV_IS_IN_MMC are
enabled and CONFIG_SPL_DM is disabled.

Fixes: 7de8bd03c3 ("treewide: fdt: Move fdt_get_config_... to 
ofnode_conf_read...")
Signed-off-by: Sean Anderson 
---

 include/dm/ofnode.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index 744dffe0a2..434696b2b6 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -1180,6 +1180,7 @@ int ofnode_write_string(ofnode node, const char 
*propname, const char *value);
  */
 int ofnode_set_enabled(ofnode node, bool value);
 
+#if CONFIG_IS_ENABLED(DM)
 /**
  * ofnode_conf_read_bool() - Read a boolean value from the U-Boot config
  *
@@ -1216,5 +1217,21 @@ int ofnode_conf_read_int(const char *prop_name, int 
default_val);
  * Return: string value, if found, or NULL if not
  */
 const char *ofnode_conf_read_str(const char *prop_name);
+#else /* CONFIG_DM */
+static inline bool ofnode_conf_read_bool(const char *prop_name)
+{
+   return false;
+}
+
+static inline int ofnode_conf_read_int(const char *prop_name, int default_val)
+{
+   return default_val;
+}
+
+static inline const char *ofnode_conf_read_str(const char *prop_name)
+{
+   return NULL;
+}
+#endif /* CONFIG_DM */
 
 #endif
-- 
2.35.1.1320.gc452695387.dirty



Re: [PATCH u-boot-net 03/14] net: introduce helpers to get PHY ofnode from MAC

2022-03-28 Thread Marek Behún
On Mon, 28 Mar 2022 00:35:00 -0600
Simon Glass  wrote:

> Hi Marek,
> 
> On Thu, 17 Mar 2022 at 06:50, Marek Behún  wrote:
> >
> > From: Marek Behún 
> >
> > Add helpers ofnode_get_phy_node() and dev_get_phy_node() and use it in
> > net/mdio-uclass.c function dm_eth_connect_phy_handle().
> >
> > This is useful because other part's of U-Boot may want to get PHY ofnode
> > without connecting a PHY.
> >
> > Signed-off-by: Marek Behún 
> > ---
> >  drivers/core/ofnode.c | 21 +
> >  drivers/core/read.c   |  5 +
> >  include/dm/ofnode.h   | 14 ++
> >  include/dm/read.h | 19 +++
> >  net/mdio-uclass.c | 24 ++--
> >  5 files changed, 65 insertions(+), 18 deletions(-)  
> 
> Please add a test for your new function. With that:
> 
> Reviewed-by: Simon Glass 

Dear Simon,

OK, I added test for ofnode_get_phy_node(). Should I also add one for
dev_get_phy_node() ? That one is implemented in drivers/core/read.c or
include/dm/read.h, and it just calls ofnode_get_phy_node()...

Also adding test for ofnode_get_phy_mode() (node -> mode) which is
implemented in patch 07/14. Can I add your reviewde-by for that patch
also? That patch is rather big, touches many files treewide...

Marek


Re: [PATCH v4 0/3] mtd: Support slc-mode for NTC CHIP

2022-03-28 Thread Chris Morgan
On Sat, Mar 12, 2022 at 01:02:16AM +0530, Jagan Teki wrote:
> On Thu, Mar 10, 2022 at 8:57 PM Chris Morgan  wrote:
> >
> > On Thu, Mar 10, 2022 at 05:30:17PM +0530, Jagan Teki wrote:
> > > Hi Chris,
> > >
> > > On Thu, Jan 20, 2022 at 6:44 PM Jagan Teki  
> > > wrote:
> > > >
> > > > On Fri, Dec 17, 2021 at 12:14 AM Chris Morgan  
> > > > wrote:
> > > > >
> > > > > From: Chris Morgan 
> > > > >
> > > > > Add support for slc-mode implemented in Linux for the Toshiba
> > > > > TC58TEG5DCLTA00 NAND and Hynix H27UCG8T2ETR NAND flash found on the 
> > > > > NTC
> > > > > CHIP. This requires the addition of a paired-pages scheme, a new
> > > > > parameter for MTD partitions of slc-mode, and setting the correct
> > > > > paired-pages scheme for the TC58TEG5DCLTA00  and H27UCG8T2ETR flash
> > > > > chips.
> > > > >
> > > > > Changes since V3:
> > > > >   - Rebased against master branch as of 2021-12-16.
> > > > >   - Added slc mode support for mtdparts command.
> > > > >
> > > > > Changes since V2:
> > > > >  - Copied upstream Linux implementation of mtd_erase to fix an issue
> > > > >with creating new ubi partitions.
> > > > >  - Implemented paired page scheme and added support for Hynix flash
> > > > >chip. Based on a cursory reading of the datasheet it appears to use
> > > > >the same pairing scheme as the Toshiba chip.
> > > > >
> > > > > Changes since V1:
> > > > >
> > > > >  - Updated mtd_read and mtd_write to match upstream Linux.
> > > > >  - Additional mtd_get_master to match upstream Linux.
> > > > >  - Removed notes about ubifs not working, because it is now.
> > > > >
> > > > > Signed-off-by: Chris Morgan 
> > > > >
> > > > > Chris Morgan (3):
> > > > >   mtd: Add support for Linux slc-mode for MLC NAND
> > > > >   mtd: Add pairing info for Toshiba TC58TEG5DCLTA00 NAND
> > > > >   mtd: Add pairing info for Hynix H27UCG8T2ETR NAND
> > >
> > > Do you have any updated version for this or it is final itself?
> >
> > Should be final, but I can rebase it again if need be. I've been
> > running this successfully for the better part of about 3 months
> > now with no more visible issues on my end. I never got fastboot
> > to talk to the mtd subsystem the way I was hoping, but in the end
> > was able to sidestep the issue with an swupdate based flash tool.
> 
> Please rebase and send.

I can confirm the patch series still applies, compiles and works on mainline
master as of today, so no rebasing should be necessary. Let me know if you
find issues on your end though.

Thank you.

> 
> Thanks,
> Jagan.


Re: [PATCH] arm: kirkwood: Add nas440 board, Marvell 88SE6121 AHCI

2022-03-28 Thread Pali Rohár
On Monday 28 March 2022 14:31:54 Tony Dinh wrote:
> Hi Hajo & Pali,
> 
> On Mon, Mar 28, 2022 at 2:28 AM Pali Rohár  wrote:
> >
> > Hello!
> >
> > On Monday 28 March 2022 10:36:36 Hajo Noerenberg wrote:
> > > Side note: as written in my first e-mail, I can access all hard disks and 
> > > load files within U-Boot. Under Linux there are 'failed to IDENTIFY' 
> > > errors.
> >
> > Ideally, send this issue to linux-ide mailing list and maintainers of
> > linux ahci driver. I hope that they would be able to help with it.
> 
> This "failed to IDENTIFY " problem might be related to the issue I've
> fixed for u-boot sata_mv driver previously. I have not looked in Linux
> sata_mv to see if it also needs to be patched.

Note that this is not about sata_mv but rather PCI AHCI driver.

But maybe Marvell AHCI based HW has same bug as that sata_mv based?

> See:
> https://lists.denx.de/pipermail/u-boot/2021-August/456705.html
> 
> Tony


Re: [PATCH] arm: kirkwood: Add nas440 board, Marvell 88SE6121 AHCI

2022-03-28 Thread Tony Dinh
Hi Hajo & Pali,

On Mon, Mar 28, 2022 at 2:28 AM Pali Rohár  wrote:
>
> Hello!
>
> On Monday 28 March 2022 10:36:36 Hajo Noerenberg wrote:
> > Hi Pali,
> >
> > Am 28.03.2022 um 10:04 schrieb Pali Rohár:
> > > On Monday 28 March 2022 09:57:41 Hajo Noerenberg wrote:
> > >> I wonder if it would be a good idea to submit adding the PCI-ids for the 
> > >> 88SE6121 controller (drivers/ata/ahci-pci.c) as a separate patch. The 
> > >> controller is not specific to the NAS440, to my knowledge it is also 
> > >> used on the Iomega ix4-200d for example.
> > >
> > > Why is this patch needed?
> >
> > Sorry, but that's beyond my knowledge. Without the PCI ids the controller 
> > is handled by the generic driver.
>
> So it does not work without that change?
>
> > >
> > > Could you please send 'lspci -nn -vv' output from Linux?
> >
> > Please find the logs below. For reference I have also attached the U-Boot 
> > logs (with / without PCI ids).
>
> Ok, seems that the issue is that this controller has class code 0x01018f
> (IDE interface [0101]; prog-if 8f) which does not match standard AHCI
> class code 0x010601 (PCI_CLASS_STORAGE_SATA_AHCI).
>
> Linux kernel has also PCI id bindings for Marvell devices 0x6145 and 0x6121:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/ahci.c?h=v5.17#n557
>
> So go ahead and send separate patch for ahci-pci.c driver to add
> bindings for those two PCI ids as for devices with wrong class code it
> is really needed.
>
> Btw, instead of 0x11ab use U-Boot macro: PCI_VENDOR_ID_MARVELL
>
> > Side note: as written in my first e-mail, I can access all hard disks and 
> > load files within U-Boot. Under Linux there are 'failed to IDENTIFY' errors.
>
> Ideally, send this issue to linux-ide mailing list and maintainers of
> linux ahci driver. I hope that they would be able to help with it.

This "failed to IDENTIFY " problem might be related to the issue I've
fixed for u-boot sata_mv driver previously. I have not looked in Linux
sata_mv to see if it also needs to be patched.

See:
https://lists.denx.de/pipermail/u-boot/2021-August/456705.html

Tony

>
> > Regards,
> > Hajo
> >
> >
> > root@nas440:~# lspci -nn -vv
> > 00:01.0 PCI bridge [0604]: Marvell Technology Group Ltd. 88F6281 [Kirkwood] 
> > ARM SoC [11ab:6281] (rev 03) (prog-if 00 [Normal decode])
> > Device tree node: 
> > /sys/firmware/devicetree/base/mbus@f100/pcie@8200/pcie@1,0
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ 
> > Stepping- SERR+ FastB2B- DisINTx-
> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> > SERR-  > Latency: 0, Cache Line Size: 64 bytes
> > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> > I/O behind bridge: 0001-00010fff [size=4K]
> > Memory behind bridge: e000-e00f [size=1M]
> > Prefetchable memory behind bridge: -000f [size=1M]
> > Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> >  > Expansion ROM at e010 [virtual] [disabled] [size=2K]
> > BridgeCtl: Parity+ SERR+ NoISA- VGA- VGA16- MAbort+ >Reset- FastB2B-
> > PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> > Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
> > DevCap: MaxPayload 128 bytes, PhantFunc 0
> > ExtTag- RBE+
> > DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
> > RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> > MaxPayload 128 bytes, MaxReadReq 512 bytes
> > DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- 
> > TransPend-
> > LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit 
> > Latency L0s <256ns, L1 unlimited
> > ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
> > LnkCtl: ASPM Disabled; RCB 128 bytes, Disabled- CommClk-
> > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
> > TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> > SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- 
> > Surprise-
> > Slot #0, PowerLimit 0.000W; Interlock- NoCompl-
> > SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- 
> > HPIrq- LinkChg-
> > Control: AttnInd Unknown, PwrInd Unknown, Power- 
> > Interlock-
> > SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ 
> > Interlock-
> > Changed: MRL- PresDet- LinkState-
> > RootCap: CRSVisible-
> > RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- 
> > CRSVisible-
> > RootSta: PME ReqID , PMEStatus- PMEPending-
> > DevCap2: Completion 

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

2022-03-28 Thread Tom Rini
On Mon, Mar 28, 2022 at 10:05:39PM +0200, Marek Vasut wrote:

> One-liner env fix below.
> 
> The following changes since commit e893e8ea6a5d3af312747d00f93587559193a426:
> 
>   Prepare v2022.04-rc5 (2022-03-28 10:14:51 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-socfpga.git master
> 
> for you to fetch changes up to 25cff0c1fa83e149e4693121f8b5e287659eed71:
> 
>   arm: socfpga: vining: Fix mtdparts for 2x256 MiB SF variant (2022-03-28
> 21:49:03 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v6 15/16] cmd: verify: initial import

2022-03-28 Thread Philippe REYNES

Hi Simon,


Le 28/03/2022 à 08:35, Simon Glass a écrit :

Hi Philippe,

On Thu, 10 Mar 2022 at 09:53, Philippe REYNES
 wrote:

Hi Simon,


Le 03/03/2022 à 04:37, Simon Glass a écrit :

Hi Philippe,

On Fri, 25 Feb 2022 at 07:58, Philippe Reynes
 wrote:

Add the command verify that check the signature of
an image with the pre-load header. If the check
succeed, the u-boot env variable 'loadaddr_verified'
is set to the address of the image (without the header).

It allows to run such commands:
tftp script.img && verify $loadaddr && source $loadaddr_verified

Signed-off-by: Philippe Reynes 
---
   cmd/Kconfig  |  7 +++
   cmd/Makefile |  1 +
   cmd/verify.c | 53 
   3 files changed, 61 insertions(+)
   create mode 100644 cmd/verify.c


Using the 'verify' command seems a bit vague. Could it be a
sub-command of bootm perhaps?


The command verify may be used with any binary (script, video firmware,
.).
So a lot of binaries that are not launched by bootm.
I think that it is not "logic" to used a bootm subcommand.
But we could use another name if you want.
For example : pre_load_verify ?

I see. Well, I suppose this is a boot loader, so 'verify' would be
expected to mean verifying an image or something to boot, so this
seems reasonable to me. But I do like the idea of putting pre_load in
there somewhere if you can, since we do most other verification as
part of the 'bootm' command. Up to you.



I have sent a v8 where I remove the command pre_load_verify,
and add the subcommand preload to bootm.



Reviewed-by: Simon Glass 

Regards,
Simon


Regards,

Philippe




Re: [PATCH v7 14/16] test: py: vboot: add test for global image signature

2022-03-28 Thread Philippe REYNES

Hi Tom,

Le 26/03/2022 à 00:02, Tom Rini a écrit :

On Fri, Mar 25, 2022 at 11:54:18PM +0100, Philippe REYNES wrote:

Hi Tom,


Le 25/03/2022 à 18:11, Tom Rini a écrit :

On Mon, Mar 14, 2022 at 03:57:43PM +0100, Philippe Reynes wrote:


Adds test units for the pre-load header signature.

Signed-off-by: Philippe Reynes 
---
   test/py/tests/test_vboot.py   | 145 --
   test/py/tests/vboot/sandbox-binman-pss.dts|  25 +++
   test/py/tests/vboot/sandbox-binman.dts|  24 +++
   .../tests/vboot/sandbox-u-boot-global-pss.dts |  28 
   test/py/tests/vboot/sandbox-u-boot-global.dts |  27 
   test/py/tests/vboot/simple-images.its |  36 +
   6 files changed, 269 insertions(+), 16 deletions(-)
   create mode 100644 test/py/tests/vboot/sandbox-binman-pss.dts
   create mode 100644 test/py/tests/vboot/sandbox-binman.dts
   create mode 100644 test/py/tests/vboot/sandbox-u-boot-global-pss.dts
   create mode 100644 test/py/tests/vboot/sandbox-u-boot-global.dts
   create mode 100644 test/py/tests/vboot/simple-images.its

This leads to CI failures such as:
https://source.denx.de/u-boot/u-boot/-/jobs/412046
and I guess maybe we need something new in test/py/requirements.txt
maybe?

I think that this issue should be fixed with this patch :

https://patchwork.ozlabs.org/project/uboot/patch/20220127140314.10264-2-philippe.rey...@softathome.com/

OK, but that's a rather specific hard-coded path to add, and won't work
in my setup for example since I use mktemp to make the base dir for all
my tests.


I have sent a v8 with a change in test_vboot to use PYTHONPATH, so the 
CI should be fixed.


And this patch is no longer needed.


Regards,

Philippe




[PATCH v8 14/15] test: py: vboot: add test for global image signature

2022-03-28 Thread Philippe Reynes
Adds test units for the pre-load header signature.

Signed-off-by: Philippe Reynes 
---
 test/py/tests/test_vboot.py   | 148 --
 test/py/tests/vboot/sandbox-binman-pss.dts|  25 +++
 test/py/tests/vboot/sandbox-binman.dts|  24 +++
 .../tests/vboot/sandbox-u-boot-global-pss.dts |  28 
 test/py/tests/vboot/sandbox-u-boot-global.dts |  27 
 test/py/tests/vboot/simple-images.its |  36 +
 6 files changed, 272 insertions(+), 16 deletions(-)
 create mode 100644 test/py/tests/vboot/sandbox-binman-pss.dts
 create mode 100644 test/py/tests/vboot/sandbox-binman.dts
 create mode 100644 test/py/tests/vboot/sandbox-u-boot-global-pss.dts
 create mode 100644 test/py/tests/vboot/sandbox-u-boot-global.dts
 create mode 100644 test/py/tests/vboot/simple-images.its

diff --git a/test/py/tests/test_vboot.py b/test/py/tests/test_vboot.py
index ac8ed9f114..040147d88b 100644
--- a/test/py/tests/test_vboot.py
+++ b/test/py/tests/test_vboot.py
@@ -21,6 +21,14 @@ For configuration verification:
 - Corrupt the signature
 - Check that image verification no-longer works
 
+For pre-load header verification:
+- Create FIT image with a pre-load header
+- Check that signature verification succeeds
+- Corrupt the FIT image
+- Check that signature verification fails
+- Launch an FIT image without a pre-load header
+- Check that image verification fails
+
 Tests run with both SHA1 and SHA256 hashing.
 """
 
@@ -35,19 +43,21 @@ import vboot_evil
 # Only run the full suite on a few combinations, since it doesn't add any more
 # test coverage.
 TESTDATA = [
-['sha1-basic', 'sha1', '', None, False, True, False],
-['sha1-pad', 'sha1', '', '-E -p 0x1', False, False, False],
-['sha1-pss', 'sha1', '-pss', None, False, False, False],
-['sha1-pss-pad', 'sha1', '-pss', '-E -p 0x1', False, False, False],
-['sha256-basic', 'sha256', '', None, False, False, False],
-['sha256-pad', 'sha256', '', '-E -p 0x1', False, False, False],
-['sha256-pss', 'sha256', '-pss', None, False, False, False],
-['sha256-pss-pad', 'sha256', '-pss', '-E -p 0x1', False, False, False],
-['sha256-pss-required', 'sha256', '-pss', None, True, False, False],
-['sha256-pss-pad-required', 'sha256', '-pss', '-E -p 0x1', True, True, 
False],
-['sha384-basic', 'sha384', '', None, False, False, False],
-['sha384-pad', 'sha384', '', '-E -p 0x1', False, False, False],
-['algo-arg', 'algo-arg', '', '-o sha256,rsa2048', False, False, True],
+['sha1-basic', 'sha1', '', None, False, True, False, False],
+['sha1-pad', 'sha1', '', '-E -p 0x1', False, False, False, False],
+['sha1-pss', 'sha1', '-pss', None, False, False, False, False],
+['sha1-pss-pad', 'sha1', '-pss', '-E -p 0x1', False, False, False, 
False],
+['sha256-basic', 'sha256', '', None, False, False, False, False],
+['sha256-pad', 'sha256', '', '-E -p 0x1', False, False, False, False],
+['sha256-pss', 'sha256', '-pss', None, False, False, False, False],
+['sha256-pss-pad', 'sha256', '-pss', '-E -p 0x1', False, False, False, 
False],
+['sha256-pss-required', 'sha256', '-pss', None, True, False, False, False],
+['sha256-pss-pad-required', 'sha256', '-pss', '-E -p 0x1', True, True, 
False, False],
+['sha384-basic', 'sha384', '', None, False, False, False, False],
+['sha384-pad', 'sha384', '', '-E -p 0x1', False, False, False, False],
+['algo-arg', 'algo-arg', '', '-o sha256,rsa2048', False, False, True, 
False],
+['sha256-global-sign', 'sha256', '', '', False, False, False, True],
+['sha256-global-sign-pss', 'sha256', '-pss', '', False, False, False, 
True],
 ]
 
 @pytest.mark.boardspec('sandbox')
@@ -56,10 +66,10 @@ TESTDATA = [
 @pytest.mark.requiredtool('fdtget')
 @pytest.mark.requiredtool('fdtput')
 @pytest.mark.requiredtool('openssl')
-@pytest.mark.parametrize("name,sha_algo,padding,sign_options,required,full_test,algo_arg",
+@pytest.mark.parametrize("name,sha_algo,padding,sign_options,required,full_test,algo_arg,global_sign",
  TESTDATA)
 def test_vboot(u_boot_console, name, sha_algo, padding, sign_options, required,
-   full_test, algo_arg):
+   full_test, algo_arg, global_sign):
 """Test verified boot signing with mkimage and verification with 'bootm'.
 
 This works using sandbox only as it needs to update the device tree used
@@ -81,6 +91,33 @@ def test_vboot(u_boot_console, name, sha_algo, padding, 
sign_options, required,
 util.run_and_log(cons, 'dtc %s %s%s -O dtb '
  '-o %s%s' % (dtc_args, datadir, dts, tmpdir, dtb))
 
+def dtc_options(dts, options):
+"""Run the device tree compiler to compile a .dts file
+
+The output file will be the same as the input file but with a .dtb
+extension.
+
+Args:
+dts: Device tree file to compile.
+options: Options provided to the 

[PATCH v8 12/15] tools: binman: add support for pre-load header

2022-03-28 Thread Philippe Reynes
Adds the support of the pre-load header with the image signature
to binman.

Reviewed-by: Simon Glass 
Signed-off-by: Philippe Reynes 
---
 tools/binman/entries.rst  |  38 
 tools/binman/etype/pre_load.py| 162 ++
 tools/binman/ftest.py |  51 ++
 tools/binman/test/225_dev.key |  28 +++
 tools/binman/test/225_pre_load.dts|  22 +++
 tools/binman/test/226_pre_load_pkcs.dts   |  23 +++
 tools/binman/test/227_pre_load_pss.dts|  23 +++
 .../test/228_pre_load_invalid_padding.dts |  23 +++
 .../binman/test/229_pre_load_invalid_sha.dts  |  23 +++
 .../binman/test/230_pre_load_invalid_algo.dts |  23 +++
 .../binman/test/231_pre_load_invalid_key.dts  |  23 +++
 11 files changed, 439 insertions(+)
 create mode 100644 tools/binman/etype/pre_load.py
 create mode 100644 tools/binman/test/225_dev.key
 create mode 100644 tools/binman/test/225_pre_load.dts
 create mode 100644 tools/binman/test/226_pre_load_pkcs.dts
 create mode 100644 tools/binman/test/227_pre_load_pss.dts
 create mode 100644 tools/binman/test/228_pre_load_invalid_padding.dts
 create mode 100644 tools/binman/test/229_pre_load_invalid_sha.dts
 create mode 100644 tools/binman/test/230_pre_load_invalid_algo.dts
 create mode 100644 tools/binman/test/231_pre_load_invalid_key.dts

diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index 484cde5c80..ef8351d969 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1009,6 +1009,44 @@ placed at offset 'RESET_VECTOR_ADDRESS - 0xffc'.
 
 
 
+Entry: pre-load: Pre load image header
+--
+
+Properties / Entry arguments:
+- key-path: Path of the directory that store key (provided by the 
environment variable KEY_PATH)
+- content: List of phandles to entries to sign
+- algo-name: Hash and signature algo to use for the signature
+- padding-name: Name of the padding (pkcs-1.5 or pss)
+- key-name: Filename of the private key to sign
+- header-size: Total size of the header
+- version: Version of the header
+
+This entry creates a pre-load header that contains a global
+image signature.
+
+For example, this creates an image with a pre-load header and a binary::
+
+binman {
+image2 {
+filename = "sandbox.bin";
+
+pre-load {
+content = <>;
+algo-name = "sha256,rsa2048";
+padding-name = "pss";
+key-name = "private.pem";
+header-size = <4096>;
+version = <1>;
+};
+
+image: blob-ext {
+filename = "sandbox.itb";
+};
+};
+};
+
+
+
 Entry: scp: System Control Processor (SCP) firmware blob
 
 
diff --git a/tools/binman/etype/pre_load.py b/tools/binman/etype/pre_load.py
new file mode 100644
index 00..245ee75525
--- /dev/null
+++ b/tools/binman/etype/pre_load.py
@@ -0,0 +1,162 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2022 Softathome
+# Written by Philippe Reynes 
+#
+# Entry-type for the global header
+#
+
+import os
+import struct
+from dtoc import fdt_util
+from patman import tools
+
+from binman.entry import Entry
+from binman.etype.collection import Entry_collection
+from binman.entry import EntryArg
+
+from Cryptodome.Hash import SHA256, SHA384, SHA512
+from Cryptodome.PublicKey import RSA
+from Cryptodome.Signature import pkcs1_15
+from Cryptodome.Signature import pss
+
+PRE_LOAD_MAGIC = b'UBSH'
+
+RSAS = {
+'rsa1024': 1024 / 8,
+'rsa2048': 2048 / 8,
+'rsa4096': 4096 / 8
+}
+
+SHAS = {
+'sha256': SHA256,
+'sha384': SHA384,
+'sha512': SHA512
+}
+
+class Entry_pre_load(Entry_collection):
+"""Pre load image header
+
+Properties / Entry arguments:
+- pre-load-key-path: Path of the directory that store key (provided by 
the environment variable PRE_LOAD_KEY_PATH)
+- content: List of phandles to entries to sign
+- algo-name: Hash and signature algo to use for the signature
+- padding-name: Name of the padding (pkcs-1.5 or pss)
+- key-name: Filename of the private key to sign
+- header-size: Total size of the header
+- version: Version of the header
+
+This entry creates a pre-load header that contains a global
+image signature.
+
+For example, this creates an image with a pre-load header and a binary::
+
+binman {
+image2 {
+filename = "sandbox.bin";
+
+pre-load {
+content = <>;
+algo-name = "sha256,rsa2048";
+padding-name = "pss";
+key-name = "private.pem";
+header-size = <4096>;
+version = <1>;
+};
+
+image: blob-ext {
+filename 

[PATCH v8 15/15] cmd: bootm: add subcommand preload

2022-03-28 Thread Philippe Reynes
Add a subcommand preload to bootm that execute the preload
stage on the image. Right now, it checks the signature
of the image with the pre-load header. If the check
succeed, the u-boot env variable 'loadaddr_verified'
is set to the address of the image (without the header).

It allows to run such commands:
tftp script.img && bootm preload $loadaddr && source $loadaddr_verified

Signed-off-by: Philippe Reynes 
---
 cmd/bootm.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/cmd/bootm.c b/cmd/bootm.c
index 87d40d494c..1f70ee9e91 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -44,6 +44,9 @@ static int do_imls(struct cmd_tbl *cmdtp, int flag, int argc,
 static struct cmd_tbl cmd_bootm_sub[] = {
U_BOOT_CMD_MKENT(start, 0, 1, (void *)BOOTM_STATE_START, "", ""),
U_BOOT_CMD_MKENT(loados, 0, 1, (void *)BOOTM_STATE_LOADOS, "", ""),
+#ifdef CONFIG_CMD_BOOTM_PRE_LOAD
+   U_BOOT_CMD_MKENT(preload, 0, 1, (void *)BOOTM_STATE_PRE_LOAD, "", ""),
+#endif
 #ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
U_BOOT_CMD_MKENT(ramdisk, 0, 1, (void *)BOOTM_STATE_RAMDISK, "", ""),
 #endif
@@ -57,6 +60,20 @@ static struct cmd_tbl cmd_bootm_sub[] = {
U_BOOT_CMD_MKENT(go, 0, 1, (void *)BOOTM_STATE_OS_GO, "", ""),
 };
 
+#if defined(CONFIG_CMD_BOOTM_PRE_LOAD)
+static ulong bootm_get_addr(int argc, char *const argv[])
+{
+   ulong addr;
+
+   if (argc > 0)
+   addr = hextoul(argv[0], NULL);
+   else
+   addr = image_load_addr;
+
+   return addr;
+}
+#endif
+
 static int do_bootm_subcommand(struct cmd_tbl *cmdtp, int flag, int argc,
   char *const argv[])
 {
@@ -72,6 +89,10 @@ static int do_bootm_subcommand(struct cmd_tbl *cmdtp, int 
flag, int argc,
if (state == BOOTM_STATE_START)
state |= BOOTM_STATE_PRE_LOAD | BOOTM_STATE_FINDOS |
 BOOTM_STATE_FINDOTHER;
+#if defined(CONFIG_CMD_BOOTM_PRE_LOAD)
+   if (state == BOOTM_STATE_PRE_LOAD)
+   state |= BOOTM_STATE_START;
+#endif
} else {
/* Unrecognized command */
return CMD_RET_USAGE;
@@ -85,6 +106,12 @@ static int do_bootm_subcommand(struct cmd_tbl *cmdtp, int 
flag, int argc,
 
ret = do_bootm_states(cmdtp, flag, argc, argv, state, , 0);
 
+#if defined(CONFIG_CMD_BOOTM_PRE_LOAD)
+   if (!ret && (state & BOOTM_STATE_PRE_LOAD))
+   env_set_hex("loadaddr_verified",
+   bootm_get_addr(argc, argv) + image_load_offset);
+#endif
+
return ret;
 }
 
@@ -177,6 +204,9 @@ static char bootm_help_text[] =
"must be\n"
"issued in the order below (it's ok to not issue all sub-commands):\n"
"\tstart [addr [arg ...]]\n"
+#if defined(CONFIG_CMD_BOOTM_PRE_LOAD)
+   "\tpreload [addr [arg ..]] - run only the preload stage\n"
+#endif
"\tloados  - load OS image\n"
 #if defined(CONFIG_SYS_BOOT_RAMDISK_HIGH)
"\tramdisk - relocate initrd, set env initrd_start/initrd_end\n"
-- 
2.25.1



[PATCH v8 13/15] configs: sandbox_defconfig: enable stage pre-load in bootm

2022-03-28 Thread Philippe Reynes
Enable the support of stage pre-load in bootm.
For the moment, this stage allow to verify the
signature of the full image with a header.

Reviewed-by: Simon Glass 
Signed-off-by: Philippe Reynes 
---
 configs/sandbox_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index ab0e2defee..a2bdd3f26a 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -27,6 +27,8 @@ CONFIG_AUTOBOOT_SHA256_FALLBACK=y
 CONFIG_AUTOBOOT_NEVER_TIMEOUT=y
 CONFIG_AUTOBOOT_STOP_STR_ENABLE=y
 
CONFIG_AUTOBOOT_STOP_STR_CRYPT="$5$rounds=64$HrpE65IkB8CM5nCL$BKT3QdF98Bo8fJpTr9tjZLZQyzqPASBY20xuK5Rent9"
+CONFIG_IMAGE_PRE_LOAD=y
+CONFIG_IMAGE_PRE_LOAD_SIG=y
 CONFIG_CONSOLE_RECORD=y
 CONFIG_CONSOLE_RECORD_OUT_SIZE=0x1000
 CONFIG_PRE_CONSOLE_BUFFER=y
@@ -37,6 +39,7 @@ CONFIG_STACKPROTECTOR=y
 CONFIG_ANDROID_AB=y
 CONFIG_CMD_CPU=y
 CONFIG_CMD_LICENSE=y
+CONFIG_CMD_BOOTM_PRE_LOAD=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_BOOTEFI_HELLO=y
 CONFIG_CMD_ABOOTIMG=y
-- 
2.25.1



[PATCH v8 11/15] Makefile: provide sah-key to binman

2022-03-28 Thread Philippe Reynes
Set the variable pre-load-key-path with the shell variable
PRE_LOAD_KEY_PATH that contain the keys path (used for signature).
This variable pre-load-key-path is provided to binman.

Reviewed-by: Simon Glass 
Signed-off-by: Philippe Reynes 
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 699834..da57315259 100644
--- a/Makefile
+++ b/Makefile
@@ -1335,6 +1335,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if 
$(BINMAN_DEBUG),-D) \
-a tpl-bss-pad=$(if $(CONFIG_TPL_SEPARATE_BSS),,1) \
-a spl-dtb=$(CONFIG_SPL_OF_REAL) \
-a tpl-dtb=$(CONFIG_TPL_OF_REAL) \
+   -a pre-load-key-path=${PRE_LOAD_KEY_PATH} \
$(BINMAN_$(@F))
 
 OBJCOPYFLAGS_u-boot.ldr.hex := -I binary -O ihex
-- 
2.25.1



[PATCH v8 07/15] boot: image: add a stage pre-load

2022-03-28 Thread Philippe Reynes
Add a stage pre-load that could
check or modify an image.

For the moment, only a header with a signature is
supported. This header has the following format:
- magic : 4 bytes
- version : 4 bytes
- header size : 4 bytes
- image size : 4 bytes
- offset image signature : 4 bytes
- flags : 4 bytes
- reserved0 : 4 bytes
- reserved1 : 4 bytes
- sha256 of the image signature : 32 bytes
- signature of the first 64 bytes : n bytes
- image signature : n bytes
- padding : up to header size

The stage uses a node /image/pre-load/sig to
get some informations:
- algo-name (mandatory) : name of the algo used to sign
- padding-name : name of padding used to sign
- signature-size : size of the signature (in the header)
- mandatory : set to yes if this sig is mandatory
- public-key (madatory) : value of the public key

Before running the image, the stage pre-load checks
the signature provided in the header.

This is an initial support, later we could add the
support of:
- ciphering
- uncompressing
- ...

Signed-off-by: Philippe Reynes 
---
 boot/Kconfig  |  55 ++
 boot/Makefile |   1 +
 boot/image-pre-load.c | 416 ++
 include/image.h   |  14 ++
 4 files changed, 486 insertions(+)
 create mode 100644 boot/image-pre-load.c

diff --git a/boot/Kconfig b/boot/Kconfig
index b83a4e8400..cb5f48dcf9 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -993,6 +993,61 @@ config AUTOBOOT_MENU_SHOW
 
 endmenu
 
+menu "Image support"
+
+config IMAGE_PRE_LOAD
+   bool "Image pre-load support"
+   help
+ Enable an image pre-load stage in the SPL.
+ This pre-load stage allows to do some manipulation
+ or check (for example signature check) on an image
+ before launching it.
+
+config SPL_IMAGE_PRE_LOAD
+   bool "Image pre-load support within SPL"
+   depends on SPL && IMAGE_PRE_LOAD
+   help
+ Enable an image pre-load stage in the SPL.
+ This pre-load stage allows to do some manipulation
+ or check (for example signature check) on an image
+ before launching it.
+
+config IMAGE_PRE_LOAD_SIG
+   bool "Image pre-load signature support"
+   depends on IMAGE_PRE_LOAD
+   select FIT_SIGNATURE
+   select RSA
+   select RSA_VERIFY_WITH_PKEY
+   help
+ Enable signature check support in the pre-load stage.
+ For this feature a very simple header is added before
+ the image with few fields:
+ - a magic
+ - the image size
+ - the signature
+ All other information (header size, type of signature,
+ ...) are provided in the node /image/pre-load/sig of
+ u-boot.
+
+config SPL_IMAGE_PRE_LOAD_SIG
+   bool "Image pre-load signature support witin SPL"
+   depends on SPL_IMAGE_PRE_LOAD && IMAGE_PRE_LOAD_SIG
+   select SPL_FIT_SIGNATURE
+   select SPL_RSA
+   select SPL_RSA_VERIFY_WITH_PKEY
+   help
+ Enable signature check support in the pre-load stage in the SPL.
+ For this feature a very simple header is added before
+ the image with few fields:
+ - a magic
+ - the image size
+ - the signature
+ All other information (header size, type of signature,
+ ...) are provided in the node /image/pre-load/sig of
+ u-boot.
+
+endmenu
+
 config USE_BOOTARGS
bool "Enable boot arguments"
help
diff --git a/boot/Makefile b/boot/Makefile
index 2938c3f145..59752c65ca 100644
--- a/boot/Makefile
+++ b/boot/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
 obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += fdt_region.o
 obj-$(CONFIG_$(SPL_TPL_)FIT) += image-fit.o
 obj-$(CONFIG_$(SPL_)MULTI_DTB_FIT) += boot_fit.o common_fit.o
+obj-$(CONFIG_$(SPL_TPL_)IMAGE_PRE_LOAD) += image-pre-load.o
 obj-$(CONFIG_$(SPL_TPL_)IMAGE_SIGN_INFO) += image-sig.o
 obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += image-fit-sig.o
 obj-$(CONFIG_$(SPL_TPL_)FIT_CIPHER) += image-cipher.o
diff --git a/boot/image-pre-load.c b/boot/image-pre-load.c
new file mode 100644
index 00..78d89069a9
--- /dev/null
+++ b/boot/image-pre-load.c
@@ -0,0 +1,416 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021 Philippe Reynes 
+ */
+
+#include 
+#include 
+DECLARE_GLOBAL_DATA_PTR;
+#include 
+#include 
+
+#include 
+
+#define IMAGE_PRE_LOAD_SIG_MAGIC   0x55425348
+#define IMAGE_PRE_LOAD_SIG_OFFSET_MAGIC0
+#define IMAGE_PRE_LOAD_SIG_OFFSET_IMG_LEN  4
+#define IMAGE_PRE_LOAD_SIG_OFFSET_SIG  8
+
+#define IMAGE_PRE_LOAD_PATH"/image/pre-load/sig"
+#define IMAGE_PRE_LOAD_PROP_ALGO_NAME  "algo-name"
+#define IMAGE_PRE_LOAD_PROP_PADDING_NAME   "padding-name"
+#define IMAGE_PRE_LOAD_PROP_SIG_SIZE   "signature-size"
+#define IMAGE_PRE_LOAD_PROP_PUBLIC_KEY "public-key"
+#define IMAGE_PRE_LOAD_PROP_MANDATORY  "mandatory"
+
+#ifndef CONFIG_SYS_BOOTM_LEN
+/* 

[PATCH v8 09/15] common: spl: fit_ram: allow to use image pre load

2022-03-28 Thread Philippe Reynes
Add the support of image pre load in spl or tpl
when loading an image from ram.

Reviewed-by: Simon Glass 
Signed-off-by: Philippe Reynes 
---
 common/spl/spl_ram.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c
index 3f7f7accc1..8296459257 100644
--- a/common/spl/spl_ram.c
+++ b/common/spl/spl_ram.c
@@ -24,9 +24,17 @@
 static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector,
   ulong count, void *buf)
 {
+   ulong addr;
+
debug("%s: sector %lx, count %lx, buf %lx\n",
  __func__, sector, count, (ulong)buf);
-   memcpy(buf, (void *)(CONFIG_SPL_LOAD_FIT_ADDRESS + sector), count);
+
+   addr = (ulong)CONFIG_SPL_LOAD_FIT_ADDRESS + sector;
+   if (CONFIG_IS_ENABLED(IMAGE_PRE_LOAD))
+   addr += image_load_offset;
+
+   memcpy(buf, (void *)addr, count);
+
return count;
 }
 
@@ -37,6 +45,17 @@ static int spl_ram_load_image(struct spl_image_info 
*spl_image,
 
header = (struct image_header *)CONFIG_SPL_LOAD_FIT_ADDRESS;
 
+   if (CONFIG_IS_ENABLED(IMAGE_PRE_LOAD)) {
+   unsigned long addr = (unsigned long)header;
+   int ret = image_pre_load(addr);
+
+   if (ret)
+   return ret;
+
+   addr += image_load_offset;
+   header = (struct image_header *)addr;
+   }
+
 #if CONFIG_IS_ENABLED(DFU)
if (bootdev->boot_device == BOOT_DEVICE_DFU)
spl_dfu_cmd(0, "dfu_alt_info_ram", "ram", "0");
-- 
2.25.1



[PATCH v8 10/15] mkimage: add public key for image pre-load stage

2022-03-28 Thread Philippe Reynes
This commit enhances mkimage to update the node
/image/pre-load/sig with the public key.

Reviewed-by: Simon Glass 
Signed-off-by: Philippe Reynes 
---
 include/image.h|  15 ++
 tools/fit_image.c  |   3 ++
 tools/image-host.c | 114 +
 3 files changed, 132 insertions(+)

diff --git a/include/image.h b/include/image.h
index 496b7af3f3..498eb7f2e3 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1019,6 +1019,21 @@ int fit_image_hash_get_value(const void *fit, int 
noffset, uint8_t **value,
 
 int fit_set_timestamp(void *fit, int noffset, time_t timestamp);
 
+/**
+ * fit_pre_load_data() - add public key to fdt blob
+ *
+ * Adds public key to the node pre load.
+ *
+ * @keydir:Directory containing keys
+ * @keydest:   FDT blob to write public key
+ * @fit:   Pointer to the FIT format image header
+ *
+ * returns:
+ * 0, on success
+ * < 0, on failure
+ */
+int fit_pre_load_data(const char *keydir, void *keydest, void *fit);
+
 int fit_cipher_data(const char *keydir, void *keydest, void *fit,
const char *comment, int require_keys,
const char *engine_id, const char *cmdname);
diff --git a/tools/fit_image.c b/tools/fit_image.c
index 15f7c82d61..1884a2eb0b 100644
--- a/tools/fit_image.c
+++ b/tools/fit_image.c
@@ -59,6 +59,9 @@ static int fit_add_file_data(struct image_tool_params 
*params, size_t size_inc,
ret = fit_set_timestamp(ptr, 0, time);
}
 
+   if (!ret)
+   ret = fit_pre_load_data(params->keydir, dest_blob, ptr);
+
if (!ret) {
ret = fit_cipher_data(params->keydir, dest_blob, ptr,
  params->comment,
diff --git a/tools/image-host.c b/tools/image-host.c
index eaeb76545c..ab6f756cf1 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -14,6 +14,11 @@
 #include 
 #include 
 
+#include 
+#include 
+
+#define IMAGE_PRE_LOAD_PATH "/image/pre-load/sig"
+
 /**
  * fit_set_hash_value - set hash value in requested has node
  * @fit: pointer to the FIT format image header
@@ -,6 +1116,115 @@ static int fit_config_add_verification_data(const char 
*keydir,
return 0;
 }
 
+/*
+ * 0) open file (open)
+ * 1) read certificate (PEM_read_X509)
+ * 2) get public key (X509_get_pubkey)
+ * 3) provide der format (d2i_RSAPublicKey)
+ */
+static int read_pub_key(const char *keydir, const void *name,
+   unsigned char **pubkey, int *pubkey_len)
+{
+   char path[1024];
+   EVP_PKEY *key = NULL;
+   X509 *cert;
+   FILE *f;
+   int ret;
+
+   memset(path, 0, 1024);
+   snprintf(path, sizeof(path), "%s/%s.crt", keydir, (char *)name);
+
+   /* Open certificate file */
+   f = fopen(path, "r");
+   if (!f) {
+   fprintf(stderr, "Couldn't open RSA certificate: '%s': %s\n",
+   path, strerror(errno));
+   return -EACCES;
+   }
+
+   /* Read the certificate */
+   cert = NULL;
+   if (!PEM_read_X509(f, , NULL, NULL)) {
+   printf("Couldn't read certificate");
+   ret = -EINVAL;
+   goto err_cert;
+   }
+
+   /* Get the public key from the certificate. */
+   key = X509_get_pubkey(cert);
+   if (!key) {
+   printf("Couldn't read public key\n");
+   ret = -EINVAL;
+   goto err_pubkey;
+   }
+
+   /* Get DER form */
+   ret = i2d_PublicKey(key, pubkey);
+   if (ret < 0) {
+   printf("Couldn't get DER form\n");
+   ret = -EINVAL;
+   goto err_pubkey;
+   }
+
+   *pubkey_len = ret;
+   ret = 0;
+
+err_pubkey:
+   X509_free(cert);
+err_cert:
+   fclose(f);
+   return ret;
+}
+
+int fit_pre_load_data(const char *keydir, void *keydest, void *fit)
+{
+   int pre_load_noffset;
+   const void *algo_name;
+   const void *key_name;
+   unsigned char *pubkey = NULL;
+   int ret, pubkey_len;
+
+   if (!keydir || !keydest || !fit)
+   return 0;
+
+   /* Search node pre-load sig */
+   pre_load_noffset = fdt_path_offset(keydest, IMAGE_PRE_LOAD_PATH);
+   if (pre_load_noffset < 0) {
+   ret = 0;
+   goto out;
+   }
+
+   algo_name = fdt_getprop(keydest, pre_load_noffset, "algo-name", NULL);
+   key_name  = fdt_getprop(keydest, pre_load_noffset, "key-name", NULL);
+
+   /* Check that all mandatory properties are present */
+   if (!algo_name || !key_name) {
+   if (!algo_name)
+   printf("The property algo-name is missing in the node 
%s\n",
+  IMAGE_PRE_LOAD_PATH);
+   if (!key_name)
+   printf("The property key-name is missing in the node 
%s\n",
+  IMAGE_PRE_LOAD_PATH);
+   ret = -ENODATA;
+ 

[PATCH v8 08/15] cmd: bootm: add a stage pre-load

2022-03-28 Thread Philippe Reynes
Add a stage pre-load to the command bootm.
Right now, this stage may be used to read a
header and check the signature of the full
image.

Reviewed-by: Simon Glass 
Signed-off-by: Philippe Reynes 
---
 boot/bootm.c| 33 +
 cmd/Kconfig | 10 ++
 cmd/bootm.c |  5 +++--
 include/image.h |  1 +
 4 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/boot/bootm.c b/boot/bootm.c
index 00c00aef84..714406ab66 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -87,6 +87,33 @@ static int bootm_start(struct cmd_tbl *cmdtp, int flag, int 
argc,
return 0;
 }
 
+static ulong bootm_data_addr(int argc, char *const argv[])
+{
+   ulong addr;
+
+   if (argc > 0)
+   addr = simple_strtoul(argv[0], NULL, 16);
+   else
+   addr = image_load_addr;
+
+   return addr;
+}
+
+static int bootm_pre_load(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+   ulong data_addr = bootm_data_addr(argc, argv);
+   int ret = 0;
+
+   if (CONFIG_IS_ENABLED(CMD_BOOTM_PRE_LOAD))
+   ret = image_pre_load(data_addr);
+
+   if (ret)
+   ret = CMD_RET_FAILURE;
+
+   return ret;
+}
+
 static int bootm_find_os(struct cmd_tbl *cmdtp, int flag, int argc,
 char *const argv[])
 {
@@ -677,6 +704,9 @@ int do_bootm_states(struct cmd_tbl *cmdtp, int flag, int 
argc,
if (states & BOOTM_STATE_START)
ret = bootm_start(cmdtp, flag, argc, argv);
 
+   if (!ret && (states & BOOTM_STATE_PRE_LOAD))
+   ret = bootm_pre_load(cmdtp, flag, argc, argv);
+
if (!ret && (states & BOOTM_STATE_FINDOS))
ret = bootm_find_os(cmdtp, flag, argc, argv);
 
@@ -866,6 +896,9 @@ static const void *boot_get_kernel(struct cmd_tbl *cmdtp, 
int flag, int argc,
  _uname_config,
  _uname_kernel);
 
+   if (CONFIG_IS_ENABLED(CMD_BOOTM_PRE_LOAD))
+   img_addr += image_load_offset;
+
bootstage_mark(BOOTSTAGE_ID_CHECK_MAGIC);
 
/* check image type, for FIT images get FIT kernel node */
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 5e25e45fd2..87aa3fb11a 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -194,6 +194,16 @@ config CMD_BOOTM
help
  Boot an application image from the memory.
 
+config CMD_BOOTM_PRE_LOAD
+   bool "enable pre-load on bootm"
+   depends on CMD_BOOTM
+   depends on IMAGE_PRE_LOAD
+   default n
+   help
+ Enable support of stage pre-load for the bootm command.
+This stage allow to check or modify the image provided
+to the bootm command.
+
 config BOOTM_EFI
bool "Support booting UEFI FIT images"
depends on CMD_BOOTEFI && CMD_BOOTM && FIT
diff --git a/cmd/bootm.c b/cmd/bootm.c
index e8b7066888..87d40d494c 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -70,7 +70,8 @@ static int do_bootm_subcommand(struct cmd_tbl *cmdtp, int 
flag, int argc,
if (c) {
state = (long)c->cmd;
if (state == BOOTM_STATE_START)
-   state |= BOOTM_STATE_FINDOS | BOOTM_STATE_FINDOTHER;
+   state |= BOOTM_STATE_PRE_LOAD | BOOTM_STATE_FINDOS |
+BOOTM_STATE_FINDOTHER;
} else {
/* Unrecognized command */
return CMD_RET_USAGE;
@@ -126,7 +127,7 @@ int do_bootm(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
}
 
return do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START |
-   BOOTM_STATE_FINDOS | BOOTM_STATE_FINDOTHER |
+   BOOTM_STATE_FINDOS | BOOTM_STATE_PRE_LOAD | 
BOOTM_STATE_FINDOTHER |
BOOTM_STATE_LOADOS |
 #ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
BOOTM_STATE_RAMDISK |
diff --git a/include/image.h b/include/image.h
index fbcf70f5e4..496b7af3f3 100644
--- a/include/image.h
+++ b/include/image.h
@@ -351,6 +351,7 @@ typedef struct bootm_headers {
 #defineBOOTM_STATE_OS_PREP (0x0100)
 #defineBOOTM_STATE_OS_FAKE_GO  (0x0200)/* 'Almost' run the OS 
*/
 #defineBOOTM_STATE_OS_GO   (0x0400)
+#defineBOOTM_STATE_PRE_LOAD0x0800
int state;
 
 #if defined(CONFIG_LMB) && !defined(USE_HOSTCC)
-- 
2.25.1



[PATCH v8 05/15] lib: crypto: allow to build crypyo in SPL

2022-03-28 Thread Philippe Reynes
This commit adds the options:
- SPL_ASYMMETRIC_KEY_TYPE
- SPL_ASYMMETRIC_PUBLIC_KEY_SUBTYPE
- SPL_RSA_PUBLIC_KEY_PARSER

Reviewed-by: Simon Glass 
Signed-off-by: Philippe Reynes 
---
 lib/Makefile|  3 ++-
 lib/crypto/Kconfig  | 29 +
 lib/crypto/Makefile | 19 +--
 3 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/lib/Makefile b/lib/Makefile
index 13e5d8f7a6..13fe5fb7a4 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -17,7 +17,6 @@ obj-$(CONFIG_OF_LIVE) += of_live.o
 obj-$(CONFIG_CMD_DHRYSTONE) += dhry/
 obj-$(CONFIG_ARCH_AT91) += at91/
 obj-$(CONFIG_OPTEE_LIB) += optee/
-obj-y += crypto/
 
 obj-$(CONFIG_AES) += aes.o
 obj-$(CONFIG_AES) += aes/
@@ -63,6 +62,8 @@ obj-$(CONFIG_TPM_V1) += tpm-v1.o
 obj-$(CONFIG_TPM_V2) += tpm-v2.o
 endif
 
+obj-y += crypto/
+
 obj-$(CONFIG_$(SPL_TPL_)GENERATE_ACPI_TABLE) += acpi/
 obj-$(CONFIG_$(SPL_)MD5) += md5.o
 obj-$(CONFIG_ECDSA) += ecdsa/
diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig
index 6369bafac0..509bc28311 100644
--- a/lib/crypto/Kconfig
+++ b/lib/crypto/Kconfig
@@ -8,6 +8,15 @@ menuconfig ASYMMETRIC_KEY_TYPE
 
 if ASYMMETRIC_KEY_TYPE
 
+config SPL_ASYMMETRIC_KEY_TYPE
+   bool "Asymmetric (public-key cryptographic) key Support within SPL"
+   depends on SPL
+   help
+ This option provides support for a key type that holds the data for
+ the asymmetric keys used for public key cryptographic operations such
+ as encryption, decryption, signature generation and signature
+ verification in the SPL.
+
 config ASYMMETRIC_PUBLIC_KEY_SUBTYPE
bool "Asymmetric public-key crypto algorithm subtype"
help
@@ -16,6 +25,15 @@ config ASYMMETRIC_PUBLIC_KEY_SUBTYPE
  appropriate hash algorithms (such as SHA-1) must be available.
  ENOPKG will be reported if the requisite algorithm is unavailable.
 
+config SPL_ASYMMETRIC_PUBLIC_KEY_SUBTYPE
+   bool "Asymmetric public-key crypto algorithm subtype within SPL"
+   depends on ASYMMETRIC_PUBLIC_KEY_SUBTYPE
+   help
+ This option provides support for asymmetric public key type handling 
in the SPL.
+ If signature generation and/or verification are to be used,
+ appropriate hash algorithms (such as SHA-1) must be available.
+ ENOPKG will be reported if the requisite algorithm is unavailable.
+
 config RSA_PUBLIC_KEY_PARSER
bool "RSA public key parser"
depends on ASYMMETRIC_PUBLIC_KEY_SUBTYPE
@@ -27,6 +45,17 @@ config RSA_PUBLIC_KEY_PARSER
  public key data and provides the ability to instantiate a public
  key.
 
+config SPL_RSA_PUBLIC_KEY_PARSER
+   bool "RSA public key parser within SPL"
+   depends on ASYMMETRIC_PUBLIC_KEY_SUBTYPE
+   select SPL_ASN1_DECODER
+   select ASN1_COMPILER
+   select SPL_OID_REGISTRY
+   help
+ This option provides support for parsing a blob containing RSA
+ public key data and provides the ability to instantiate a public
+ key in the SPL.
+
 config X509_CERTIFICATE_PARSER
bool "X.509 certificate parser"
depends on ASYMMETRIC_PUBLIC_KEY_SUBTYPE
diff --git a/lib/crypto/Makefile b/lib/crypto/Makefile
index f3a414525d..6792b1d4f0 100644
--- a/lib/crypto/Makefile
+++ b/lib/crypto/Makefile
@@ -3,27 +3,34 @@
 # Makefile for asymmetric cryptographic keys
 #
 
-obj-$(CONFIG_ASYMMETRIC_KEY_TYPE) += asymmetric_keys.o
+obj-$(CONFIG_$(SPL_)ASYMMETRIC_KEY_TYPE) += asymmetric_keys.o
 
 asymmetric_keys-y := asymmetric_type.o
 
-obj-$(CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE) += public_key.o
+obj-$(CONFIG_$(SPL_)ASYMMETRIC_PUBLIC_KEY_SUBTYPE) += public_key.o
 
 #
 # RSA public key parser
 #
-obj-$(CONFIG_RSA_PUBLIC_KEY_PARSER) += rsa_public_key.o
+obj-$(CONFIG_$(SPL_)RSA_PUBLIC_KEY_PARSER) += rsa_public_key.o
 rsa_public_key-y := \
rsapubkey.asn1.o \
rsa_helper.o
 
 $(obj)/rsapubkey.asn1.o: $(obj)/rsapubkey.asn1.c $(obj)/rsapubkey.asn1.h
+ifdef CONFIG_SPL_BUILD
+CFLAGS_rsapubkey.asn1.o += -I$(obj)
+endif
+
 $(obj)/rsa_helper.o: $(obj)/rsapubkey.asn1.h
+ifdef CONFIG_SPL_BUILD
+CFLAGS_rsa_helper.o += -I$(obj)
+endif
 
 #
 # X.509 Certificate handling
 #
-obj-$(CONFIG_X509_CERTIFICATE_PARSER) += x509_key_parser.o
+obj-$(CONFIG_$(SPL_)X509_CERTIFICATE_PARSER) += x509_key_parser.o
 x509_key_parser-y := \
x509.asn1.o \
x509_akid.asn1.o \
@@ -40,11 +47,11 @@ $(obj)/x509_akid.asn1.o: $(obj)/x509_akid.asn1.c 
$(obj)/x509_akid.asn1.h
 #
 # PKCS#7 message handling
 #
-obj-$(CONFIG_PKCS7_MESSAGE_PARSER) += pkcs7_message.o
+obj-$(CONFIG_$(SPL_)PKCS7_MESSAGE_PARSER) += pkcs7_message.o
 pkcs7_message-y := \
pkcs7.asn1.o \
pkcs7_parser.o
-obj-$(CONFIG_PKCS7_VERIFY) += pkcs7_verify.o
+obj-$(CONFIG_$(SPL_)PKCS7_VERIFY) += pkcs7_verify.o
 
 $(obj)/pkcs7_parser.o: $(obj)/pkcs7.asn1.h
 $(obj)/pkcs7.asn1.o: $(obj)/pkcs7.asn1.c $(obj)/pkcs7.asn1.h
-- 
2.25.1



[PATCH v8 06/15] lib: rsa: allow rsa verify with pkey in SPL

2022-03-28 Thread Philippe Reynes
This commit adds the option SPL_RSA_VERIFY_WITH_PKEY.

Reviewed-by: Simon Glass 
Signed-off-by: Philippe Reynes 
---
 lib/rsa/Kconfig | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
index be9775bcce..b773f17c26 100644
--- a/lib/rsa/Kconfig
+++ b/lib/rsa/Kconfig
@@ -47,6 +47,25 @@ config RSA_VERIFY_WITH_PKEY
  directly specified in image_sign_info, where all the necessary
  key properties will be calculated on the fly in verification code.
 
+config SPL_RSA_VERIFY_WITH_PKEY
+   bool "Execute RSA verification without key parameters from FDT within 
SPL"
+   depends on SPL
+   select SPL_RSA_VERIFY
+   select SPL_ASYMMETRIC_KEY_TYPE
+   select SPL_ASYMMETRIC_PUBLIC_KEY_SUBTYPE
+   select SPL_RSA_PUBLIC_KEY_PARSER
+   help
+ The standard RSA-signature verification code (FIT_SIGNATURE) uses
+ pre-calculated key properties, that are stored in fdt blob, in
+ decrypting a signature.
+ This does not suit the use case where there is no way defined to
+ provide such additional key properties in standardized form,
+ particularly UEFI secure boot.
+ This options enables RSA signature verification with a public key
+ directly specified in image_sign_info, where all the necessary
+ key properties will be calculated on the fly in verification code
+ in the SPL.
+
 config RSA_SOFTWARE_EXP
bool "Enable driver for RSA Modular Exponentiation in software"
depends on DM
-- 
2.25.1



[PATCH v8 04/15] lib: allow to build asn1 decoder and oid registry in SPL

2022-03-28 Thread Philippe Reynes
This commit adds the options:
- SPL_ASN1_DECODER
- SPL_OID_REGISTRY

Reviewed-by: Simon Glass 
Signed-off-by: Philippe Reynes 
---
 lib/Kconfig  | 19 +++
 lib/Makefile |  4 ++--
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig b/lib/Kconfig
index e749826f22..effe735365 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -809,6 +809,16 @@ config ASN1_DECODER
  and especially in cryptography (https://en.wikipedia.org/wiki/ASN.1).
  This option enables the support of the asn1 decoder.
 
+config SPL_ASN1_DECODER
+   bool
+   help
+ ASN.1 (Abstract Syntax Notation One) is a standard interface
+ description language for defining data structures that can be
+ serialized and deserialized in a cross-platform way. It is
+ broadly used in telecommunications and computer networking,
+ and especially in cryptography (https://en.wikipedia.org/wiki/ASN.1).
+ This option enables the support of the asn1 decoder in the SPL.
+
 config OID_REGISTRY
bool
help
@@ -818,6 +828,15 @@ config OID_REGISTRY
  unambiguous persistent name 
(https://en.wikipedia.org/wiki/Object_identifier).
  Enable fast lookup object identifier registry.
 
+config SPL_OID_REGISTRY
+   bool
+   help
+ In computing, object identifiers or OIDs are an identifier mechanism
+ standardized by the International Telecommunication Union (ITU) and
+ ISO/IEC for naming any object, concept, or "thing" with a globally
+ unambiguous persistent name 
(https://en.wikipedia.org/wiki/Object_identifier).
+ Enable fast lookup object identifier registry in the SPL.
+
 config SMBIOS_PARSER
bool "SMBIOS parser"
help
diff --git a/lib/Makefile b/lib/Makefile
index 11b03d1cbe..13e5d8f7a6 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -17,7 +17,6 @@ obj-$(CONFIG_OF_LIVE) += of_live.o
 obj-$(CONFIG_CMD_DHRYSTONE) += dhry/
 obj-$(CONFIG_ARCH_AT91) += at91/
 obj-$(CONFIG_OPTEE_LIB) += optee/
-obj-$(CONFIG_ASN1_DECODER) += asn1_decoder.o
 obj-y += crypto/
 
 obj-$(CONFIG_AES) += aes.o
@@ -74,6 +73,7 @@ obj-$(CONFIG_SHA1) += sha1.o
 obj-$(CONFIG_SHA256) += sha256.o
 obj-$(CONFIG_SHA512) += sha512.o
 obj-$(CONFIG_CRYPT_PW) += crypt/
+obj-$(CONFIG_$(SPL_)ASN1_DECODER) += asn1_decoder.o
 
 obj-$(CONFIG_$(SPL_)ZLIB) += zlib/
 obj-$(CONFIG_$(SPL_)ZSTD) += zstd/
@@ -135,9 +135,9 @@ obj-$(CONFIG_$(SPL_TPL_)STRTO) += strto.o
 else
 # Main U-Boot always uses the full printf support
 obj-y += vsprintf.o strto.o
-obj-$(CONFIG_OID_REGISTRY) += oid_registry.o
 obj-$(CONFIG_SSCANF) += sscanf.o
 endif
+obj-$(CONFIG_$(SPL_)OID_REGISTRY) += oid_registry.o
 
 obj-y += abuf.o
 obj-y += date.o
-- 
2.25.1



[PATCH v8 03/15] lib: Kconfig: enhance the help of OID_REGISTRY

2022-03-28 Thread Philippe Reynes
Enhance the help for the config OID_REGISTRY.

Reviewed-by: Simon Glass 
Signed-off-by: Philippe Reynes 
---
 lib/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/Kconfig b/lib/Kconfig
index b0e5d60b3d..e749826f22 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -812,6 +812,10 @@ config ASN1_DECODER
 config OID_REGISTRY
bool
help
+ In computing, object identifiers or OIDs are an identifier mechanism
+ standardized by the International Telecommunication Union (ITU) and
+ ISO/IEC for naming any object, concept, or "thing" with a globally
+ unambiguous persistent name 
(https://en.wikipedia.org/wiki/Object_identifier).
  Enable fast lookup object identifier registry.
 
 config SMBIOS_PARSER
-- 
2.25.1



[PATCH v8 01/15] arch: Kconfig: imply BINMAN for SANDBOX

2022-03-28 Thread Philippe Reynes
To be able to use the tool binman on sandbox,
the config SANDBOX should imply BINMAN.

Reviewed-by: Simon Glass 
Signed-off-by: Philippe Reynes 
---
 arch/Kconfig   | 1 +
 arch/sandbox/dts/sandbox.dtsi  | 3 +++
 arch/sandbox/dts/test.dts  | 3 +++
 test/py/tests/test_fit.py  | 3 +++
 test/py/tests/vboot/sandbox-u-boot.dts | 3 +++
 5 files changed, 13 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index e6191446a3..35624377ca 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -203,6 +203,7 @@ config SANDBOX
imply KEYBOARD
imply PHYSMEM
imply GENERATE_ACPI_TABLE
+   imply BINMAN
 
 config SH
bool "SuperH architecture"
diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index 66b813faad..826db26fc2 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -7,6 +7,9 @@
 #define USB_CLASS_HUB  9
 
 / {
+   binman {
+   };
+
chosen {
stdout-path = "/serial";
};
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 48ca3e1e47..c11ad8cb9f 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -61,6 +61,9 @@
osd0 = "/osd";
};
 
+   binman {
+   };
+
config {
testing-bool;
testing-int = <123>;
diff --git a/test/py/tests/test_fit.py b/test/py/tests/test_fit.py
index 6d5b43c3ba..5856960be2 100755
--- a/test/py/tests/test_fit.py
+++ b/test/py/tests/test_fit.py
@@ -89,6 +89,9 @@ base_fdt = '''
model = "Sandbox Verified Boot Test";
compatible = "sandbox";
 
+   binman {
+   };
+
reset@0 {
compatible = "sandbox,reset";
reg = <0>;
diff --git a/test/py/tests/vboot/sandbox-u-boot.dts 
b/test/py/tests/vboot/sandbox-u-boot.dts
index 63f8f401de..5809c62fc1 100644
--- a/test/py/tests/vboot/sandbox-u-boot.dts
+++ b/test/py/tests/vboot/sandbox-u-boot.dts
@@ -4,6 +4,9 @@
model = "Sandbox Verified Boot Test";
compatible = "sandbox";
 
+   binman {
+   };
+
reset@0 {
compatible = "sandbox,reset";
};
-- 
2.25.1



[PATCH v8 02/15] lib: Kconfig: enhance help for ASN1

2022-03-28 Thread Philippe Reynes
Enhance the help for configs ASN1_COMPILER
and ASN1_decoder.

Reviewed-by: Simon Glass 
Signed-off-by: Philippe Reynes 
---
 lib/Kconfig | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/lib/Kconfig b/lib/Kconfig
index 3c6fa99b1a..b0e5d60b3d 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -791,11 +791,23 @@ endmenu
 
 config ASN1_COMPILER
bool
+   help
+ ASN.1 (Abstract Syntax Notation One) is a standard interface
+ description language for defining data structures that can be
+ serialized and deserialized in a cross-platform way. It is
+ broadly used in telecommunications and computer networking,
+ and especially in cryptography (https://en.wikipedia.org/wiki/ASN.1).
+ This option enables the support of the asn1 compiler.
 
 config ASN1_DECODER
bool
help
- Enable asn1 decoder library.
+ ASN.1 (Abstract Syntax Notation One) is a standard interface
+ description language for defining data structures that can be
+ serialized and deserialized in a cross-platform way. It is
+ broadly used in telecommunications and computer networking,
+ and especially in cryptography (https://en.wikipedia.org/wiki/ASN.1).
+ This option enables the support of the asn1 decoder.
 
 config OID_REGISTRY
bool
-- 
2.25.1



[PATCH v8 00/15] image: add a stage pre-load

2022-03-28 Thread Philippe Reynes
This serie adds a stage pre-load before launching an image.
This stage is used to read a header before the image and
this header contains the signature of the full image.
So u-boot may check the full image before using any
data of the image.

The support of this header is added to binman, and
a command verify checks the signature of a blob and
set the u-boot env variable "loadaddr_verified" to 
the beginning of the "real" image.

The support of this header is only added to binman,
but it may also be added to mkimage. 


Changelog:
v8:
- remove command pre_load_verify
- add subcommand preload to bootm
- add stage pre_load in "bootm start"
- use PYTHONPATH to use binman in py test vboot
v7:
- rename command verify to pre_load_verify
- add usage doc for command pre_load_verify
- some cleanup in support of pre-load in binman
- rename variable key-path to pre-load-key-path
- some cleanup in test vboot for pre-load
v6:
- set values in big endian in the pre-load header
- binman: etypes: pre-load: read image from other entry
  instead of directly from a file
- binman: etypes: pre-load: add test unit
- lib: Makefile: no longer add -I$(obj) for SPL
   It was to fix build when oid is built on spl but not
   on u-boot. It is not longer possible.
v5:
- replace config SANDBOX_BINMAN by an imply
v4:
- add a config SANDBOX_BIN
- enhance help for asn1 and oid
- change the format of the pre-load header
- add the support of pre-load header in binman
- add py test for pre-load header
- add a command verify
v3:
- move image-pre-load.c to /boot
- update mkimage to add public key in u-boot device tree
- add script gen_pre_load_header.sh
v2:
- move the code to image-pre-load
- add support of stage pre-load for spl
- add support of stage pre-load on spl_ram

Philippe Reynes (15):
  arch: Kconfig: imply BINMAN for SANDBOX
  lib: Kconfig: enhance help for ASN1
  lib: Kconfig: enhance the help of OID_REGISTRY
  lib: allow to build asn1 decoder and oid registry in SPL
  lib: crypto: allow to build crypyo in SPL
  lib: rsa: allow rsa verify with pkey in SPL
  boot: image: add a stage pre-load
  cmd: bootm: add a stage pre-load
  common: spl: fit_ram: allow to use image pre load
  mkimage: add public key for image pre-load stage
  Makefile: provide sah-key to binman
  tools: binman: add support for pre-load header
  configs: sandbox_defconfig: enable stage pre-load in bootm
  test: py: vboot: add test for global image signature
  cmd: bootm: add subcommand preload

 Makefile  |   1 +
 arch/Kconfig  |   1 +
 arch/sandbox/dts/sandbox.dtsi |   3 +
 arch/sandbox/dts/test.dts |   3 +
 boot/Kconfig  |  55 +++
 boot/Makefile |   1 +
 boot/bootm.c  |  33 ++
 boot/image-pre-load.c | 416 ++
 cmd/Kconfig   |  10 +
 cmd/bootm.c   |  35 +-
 common/spl/spl_ram.c  |  21 +-
 configs/sandbox_defconfig |   3 +
 include/image.h   |  30 ++
 lib/Kconfig   |  37 +-
 lib/Makefile  |   7 +-
 lib/crypto/Kconfig|  29 ++
 lib/crypto/Makefile   |  19 +-
 lib/rsa/Kconfig   |  19 +
 test/py/tests/test_fit.py |   3 +
 test/py/tests/test_vboot.py   | 148 ++-
 test/py/tests/vboot/sandbox-binman-pss.dts|  25 ++
 test/py/tests/vboot/sandbox-binman.dts|  24 +
 .../tests/vboot/sandbox-u-boot-global-pss.dts |  28 ++
 test/py/tests/vboot/sandbox-u-boot-global.dts |  27 ++
 test/py/tests/vboot/sandbox-u-boot.dts|   3 +
 test/py/tests/vboot/simple-images.its |  36 ++
 tools/binman/entries.rst  |  38 ++
 tools/binman/etype/pre_load.py| 162 +++
 tools/binman/ftest.py |  51 +++
 tools/binman/test/225_dev.key |  28 ++
 tools/binman/test/225_pre_load.dts|  22 +
 tools/binman/test/226_pre_load_pkcs.dts   |  23 +
 tools/binman/test/227_pre_load_pss.dts|  23 +
 .../test/228_pre_load_invalid_padding.dts |  23 +
 .../binman/test/229_pre_load_invalid_sha.dts  |  23 +
 .../binman/test/230_pre_load_invalid_algo.dts |  23 +
 .../binman/test/231_pre_load_invalid_key.dts  |  23 +
 tools/fit_image.c |   3 +
 tools/image-host.c| 114 +
 39 files changed, 1544 insertions(+), 29 deletions(-)
 create mode 100644 boot/image-pre-load.c
 create mode 100644 test/py/tests/vboot/sandbox-binman-pss.dts
 create mode 100644 test/py/tests/vboot/sandbox-binman.dts
 create mode 100644 test/py/tests/vboot/sandbox-u-boot-global-pss.dts
 create 

Please pull u-boot-video/next

2022-03-28 Thread Anatolij Gustschin
Hi Tom,

please pull video patches for next.

CI: https://source.denx.de/u-boot/custodians/u-boot-video/-/pipelines/11483

Thanks,
Anatolij

The following changes since commit 34d2b7f20369d62c0f091d6572a8c0ea4655cf14:

  Merge tag 'v2022.04-rc5' into next (2022-03-28 12:36:49 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-video.git tags/next-20220328

for you to fetch changes up to 60cc4094485bf44b5ad455b51076f0e07f3f793a:

  video: Drop CONFIG_LCD_BMP_RLE8 (2022-03-28 20:30:33 +0200)


 - drop old CFB code
 - drop CONFIG_LCD_BMP_RLE8


Simon Glass (14):
  video: Drop cfg_console
  video: siemens: Drop unused video code
  video: nexell: Drop unused and invalid code
  video: Drop video_fb header
  video: Drop CONFIG_VIDEO_BMP_LOGO
  video: Drop references to CONFIG_VIDEO et al
  video: Clean up the uclass header
  video: Drop da8xx-fb
  video: fsl: colibri_vf: Drop FSL DCU driver
  video: Drop FSL DIU driver
  video: mxs: Drop old video code
  video: Convert CONFIG_VIDEO_BCM2835 to Kconfig
  video: Drop formike driver
  video: Drop CONFIG_LCD_BMP_RLE8

 README  |   22 -
 arch/arm/cpu/armv7/ls102xa/soc.c|4 -
 arch/arm/include/asm/arch-ls102xa/config.h  |1 -
 arch/arm/include/asm/mach-imx/mx5_video.h   |5 -
 arch/arm/mach-nexell/include/mach/display_dev.h |8 +-
 board/aristainetos/aristainetos.c   |1 -
 board/freescale/common/Makefile |4 -
 board/freescale/common/dcu_sii9022a.c   |  248 ---
 board/freescale/common/dcu_sii9022a.h   |   12 -
 board/freescale/common/diu_ch7301.c |  217 ---
 board/freescale/common/diu_ch7301.h |   12 -
 board/freescale/ls1021aiot/Makefile |1 -
 board/freescale/ls1021aiot/dcu.c|   48 -
 board/freescale/ls1021aqds/Makefile |1 -
 board/freescale/ls1021aqds/dcu.c|  110 --
 board/freescale/ls1021atwr/Makefile |1 -
 board/freescale/ls1021atwr/dcu.c|   48 -
 board/freescale/mx51evk/Makefile|1 -
 board/freescale/mx53loco/Makefile   |1 -
 board/freescale/t104xrdb/Makefile   |1 -
 board/freescale/t104xrdb/diu.c  |   84 -
 board/kosagi/novena/novena_spl.c|   23 -
 board/siemens/common/board.c|3 -
 board/siemens/common/factoryset.c   |7 -
 board/siemens/common/factoryset.h   |3 -
 board/siemens/pxm2/board.c  |  189 ---
 board/siemens/rut/board.c   |  247 ---
 board/socrates/socrates.c   |1 -
 board/toradex/colibri_vf/Makefile   |1 -
 board/toradex/colibri_vf/colibri_vf.c   |   62 -
 board/toradex/colibri_vf/dcu.c  |   38 -
 cmd/Kconfig |2 +-
 cmd/bdinfo.c|2 +-
 cmd/bmp.c   |4 +-
 cmd/cls.c   |2 -
 common/fdt_support.c|2 +-
 common/lcd.c|  142 --
 common/stdio.c  |4 +-
 configs/colibri_vf_defconfig|1 -
 configs/rpi_0_w_defconfig   |1 +
 configs/rpi_2_defconfig |1 +
 configs/rpi_3_32b_defconfig |1 +
 configs/rpi_3_b_plus_defconfig  |1 +
 configs/rpi_3_defconfig |1 +
 configs/rpi_4_32b_defconfig |1 +
 configs/rpi_4_defconfig |1 +
 configs/rpi_arm64_defconfig |1 +
 configs/rpi_defconfig   |1 +
 doc/usage/bootmenu.rst  |5 -
 drivers/pci/pci_rom.c   |1 -
 drivers/video/Kconfig   |  129 +-
 drivers/video/Makefile  |5 -
 drivers/video/cfb_console.c | 1865 ---
 drivers/video/da8xx-fb.c| 1048 -
 drivers/video/da8xx-fb.h|  115 --
 drivers/video/formike.c |  513 ---
 drivers/video/fsl_dcu_fb.c  |  549 ---
 drivers/video/fsl_diu_fb.c  |  416 -
 drivers/video/imx/mxc_ipuv3_fb.c|1 -
 drivers/video/mxsfb.c   |   90 --
 drivers/video/nexell_display.c  |   17 +-
 drivers/video/omap3_dss.c   |   29 -
 drivers/video/sunxi

Re: [PATCH] video: Do not show splash and U-Boot logo simultaneously

2022-03-28 Thread Tim Harvey
On Mon, Mar 28, 2022 at 12:40 PM Fabio Estevam  wrote:
>
> From: Fabio Estevam 
>
> Currently, on imx6sabresd and gwventana boards, the company logo
> and U-Boot logo are shown.
>
> The correct behavior is to show only the company logo, if available,
> and not both logos.
>
> Reported-by: Tim Harvey 
> Signed-off-by: Fabio Estevam 
> ---
>  drivers/video/video-uclass.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
> index 88797d4a21c2..42f9245ea8c5 100644
> --- a/drivers/video/video-uclass.c
> +++ b/drivers/video/video-uclass.c
> @@ -407,7 +407,8 @@ static int video_post_probe(struct udevice *dev)
> return ret;
> }
>
> -   if (IS_ENABLED(CONFIG_VIDEO_LOGO) && !plat->hide_logo) {
> +   if (IS_ENABLED(CONFIG_VIDEO_LOGO) &&
> +   !IS_ENABLED(CONFIG_SPLASH_SCREEN) && !plat->hide_logo) {
> ret = show_splash(dev);
> if (ret) {
> log_debug("Cannot show splash screen\n");
> --
> 2.25.1
>

Fabio,

Thanks for confirming this issue on imx6sabresd and submitting this fix!

Tested-by: Tim Harvey  #gw_ventana

Best regards,

Tim


[PULL] u-boot-socfpga/master

2022-03-28 Thread Marek Vasut

One-liner env fix below.

The following changes since commit e893e8ea6a5d3af312747d00f93587559193a426:

  Prepare v2022.04-rc5 (2022-03-28 10:14:51 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-socfpga.git master

for you to fetch changes up to 25cff0c1fa83e149e4693121f8b5e287659eed71:

  arm: socfpga: vining: Fix mtdparts for 2x256 MiB SF variant 
(2022-03-28 21:49:03 +0200)



Marek Vasut (1):
  arm: socfpga: vining: Fix mtdparts for 2x256 MiB SF variant

 include/configs/socfpga_vining_fpga.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


Re: [PATCH] board: gw_ventana: gsc: fix GSC read/write functions

2022-03-28 Thread Fabio Estevam
Hi Tim,

On Mon, Mar 28, 2022 at 4:24 PM Tim Harvey  wrote:

> Any other feedback on this? Regardless of if I2C drivers should return
> the same error code as Linux on a NAK, I would like to get this patch
> applied to fix the current regression for the upcoming v2022.04.

Agreed, let's fix the regression for the upcoming release:

Reviewed-by: Fabio Estevam 

The error code alignment between U-Boot and Linux can be discussed later.


Re: [PATCH] video: Do not show splash and U-Boot logo simultaneously

2022-03-28 Thread Tom Rini
On Mon, Mar 28, 2022 at 04:40:36PM -0300, Fabio Estevam wrote:

> From: Fabio Estevam 
> 
> Currently, on imx6sabresd and gwventana boards, the company logo
> and U-Boot logo are shown.
> 
> The correct behavior is to show only the company logo, if available,
> and not both logos.
> 
> Reported-by: Tim Harvey 
> Signed-off-by: Fabio Estevam 
> ---
>  drivers/video/video-uclass.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

This is probably good for the release, so I'll pick it up in a day or
two, to give time for testing and feedback.

But, why do we end up even having both logos in the binary?  That feels
like an odd regression itself.

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] video: Do not show splash and U-Boot logo simultaneously

2022-03-28 Thread Fabio Estevam
From: Fabio Estevam 

Currently, on imx6sabresd and gwventana boards, the company logo
and U-Boot logo are shown.

The correct behavior is to show only the company logo, if available,
and not both logos.

Reported-by: Tim Harvey 
Signed-off-by: Fabio Estevam 
---
 drivers/video/video-uclass.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 88797d4a21c2..42f9245ea8c5 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -407,7 +407,8 @@ static int video_post_probe(struct udevice *dev)
return ret;
}
 
-   if (IS_ENABLED(CONFIG_VIDEO_LOGO) && !plat->hide_logo) {
+   if (IS_ENABLED(CONFIG_VIDEO_LOGO) &&
+   !IS_ENABLED(CONFIG_SPLASH_SCREEN) && !plat->hide_logo) {
ret = show_splash(dev);
if (ret) {
log_debug("Cannot show splash screen\n");
-- 
2.25.1



Re: [PATCH] board: gw_ventana: gsc: fix GSC read/write functions

2022-03-28 Thread Tim Harvey
On Thu, Mar 24, 2022 at 9:04 AM Tim Harvey  wrote:
>
> On Thu, Mar 24, 2022 at 8:59 AM Fabio Estevam  wrote:
> >
> > Hi Tim,
> >
> > On Thu, Mar 24, 2022 at 12:32 PM Tim Harvey  wrote:
> > >
> > > commit 7c84319af9c7 ("dm: gpio: Correct use of -ENODEV in drivers")
> > > changed the return code for an I2C NAK from -ENODEV to -EREMOTEIO.
> >
> > I think we should be consistent with Linux and return -ENXIO for the NACK 
> > case:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/i2c/fault-codes.rst?h=v5.17#n88
> >
> > "ENXIO
> > Returned by I2C adapters to indicate that the address phase
> > of a transfer didn't get an ACK.  While it might just mean
> > an I2C device was temporarily not responding, usually it
> > means there's nothing listening at that address."
>
> Fabio,
>
> I share your sentiment however if I go and change this in
> drivers/i2c/mxc_i2c.c (or others) how do I know I don't cause the same
> breakage that Simon's patch did? I can't easily tell if anyone is
> depending on EREMOTEIO (or ENODEV as it was) to mean NAK.
>
> For reference there are about 48  i2c drivers in drivers/i2c and only
> 3 currently return -ENXIO
> (designware_i2c.c,i2c-microchip.c,sun8i_rsb.c)
>
> Honestly I would love to just implement retries on NAK in mxc_i2c.c
> but that approach was not accepted in the Linux driver when I
> attempted to do it there.
>

Any other feedback on this? Regardless of if I2C drivers should return
the same error code as Linux on a NAK, I would like to get this patch
applied to fix the current regression for the upcoming v2022.04.

Best Regards,

Tim


Re: [PATCH 19/23] video: Support showing the U-Boot logo

2022-03-28 Thread Fabio Estevam
Hi Tim,

On Mon, Mar 28, 2022 at 3:50 PM Tim Harvey  wrote:

> Fabio, do you have any imx6 boards that have defconfigs that enable
> SPLASH_SCREEN you can see if the same behavior occurs on?  The
> behavior is that VIDEO_LOGO got enabled by default so you see the
> custom splash along with the U-Boot logo and if you disable VIDEO_LOGO
> you also loose the custom splash.

Yes, I am able to reproduce the same behavior on an imx6sabresd
running top of head U-Boot:
I do see both the Freescale logo and the U-Boot logo.

If VIDEO_LOGO is disabled, nothing is seen on the LCD.


Re: [PATCH 19/23] video: Support showing the U-Boot logo

2022-03-28 Thread Tim Harvey
On Sun, Mar 27, 2022 at 11:36 PM Simon Glass  wrote:
>
> Hi Tim,
>
> On Tue, 15 Mar 2022 at 10:14, Tim Harvey  wrote:
> >
> > On Fri, Nov 19, 2021 at 12:28 PM Simon Glass  wrote:
> > >
> > > Show the U-Boot logo by default. This is only 7KB in size so seems like
> > > a useful default for boards that enable a display.
> > >
> > > If SPLASH_SCREEN is enabled, it is not enabled by default, so as not to
> > > conflict with that feature.
> > >
> > > Also disable it for tests, since we don't want to complicate the output.
> > >
> > > Signed-off-by: Simon Glass 
> > > ---
> > >
> > >  drivers/video/Kconfig |   1 +
> > >  drivers/video/Makefile|   3 +++
> > >  drivers/video/sandbox_sdl.c   |   2 ++
> > >  drivers/video/u_boot_logo.bmp | Bin 0 -> 6932 bytes
> > >  drivers/video/video-uclass.c  |  26 
> > >  include/video.h   |   2 ++
> > >  scripts/Makefile.lib  |  21 +
> > >  test/dm/video.c   |  43 +++---
> > >  8 files changed, 89 insertions(+), 9 deletions(-)
> > >  create mode 100644 drivers/video/u_boot_logo.bmp
> > >
> > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > index 7a73ecc1f40..e601b47806b 100644
> > > --- a/drivers/video/Kconfig
> > > +++ b/drivers/video/Kconfig
> > > @@ -17,6 +17,7 @@ config DM_VIDEO
> > >  config VIDEO_LOGO
> > > bool "Show the U-Boot logo on the display"
> > > depends on DM_VIDEO
> > > +   select VIDEO_BMP_RLE8
> > > help
> > >   This enables showing the U-Boot logo on the display when a video
> > >   device is probed. It appears at the top right. The logo itself 
> > > is at
> > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> > > index 8956b5f9b00..4038395b128 100644
> > > --- a/drivers/video/Makefile
> > > +++ b/drivers/video/Makefile
> > > @@ -17,6 +17,9 @@ obj-$(CONFIG_DM_VIDEO) += video_bmp.o
> > >  obj-$(CONFIG_PANEL) += panel-uclass.o
> > >  obj-$(CONFIG_DM_PANEL_HX8238D) += hx8238d.o
> > >  obj-$(CONFIG_SIMPLE_PANEL) += simple_panel.o
> > > +
> > > +obj-$(CONFIG_VIDEO_LOGO) += u_boot_logo.o
> > > +
> > >  endif
> > >
> > >  obj-${CONFIG_EXYNOS_FB} += exynos/
> > > diff --git a/drivers/video/sandbox_sdl.c b/drivers/video/sandbox_sdl.c
> > > index 2afe66fab1a..9081c7da62e 100644
> > > --- a/drivers/video/sandbox_sdl.c
> > > +++ b/drivers/video/sandbox_sdl.c
> > > @@ -82,12 +82,14 @@ static void set_bpp(struct udevice *dev, enum 
> > > video_log2_bpp l2bpp)
> > >
> > >  int sandbox_sdl_set_bpp(struct udevice *dev, enum video_log2_bpp l2bpp)
> > >  {
> > > +   struct video_uc_plat *uc_plat = dev_get_uclass_plat(dev);
> > > int ret;
> > >
> > > if (device_active(dev))
> > > return -EINVAL;
> > > sandbox_sdl_remove_display();
> > >
> > > +   uc_plat->hide_logo = true;
> > > set_bpp(dev, l2bpp);
> > >
> > > ret = device_probe(dev);
> > > diff --git a/drivers/video/u_boot_logo.bmp b/drivers/video/u_boot_logo.bmp
> > > new file mode 100644
> > > index 
> > > ..47f1e9b99789584d2f6dd71e954b51927b35d783
> > > GIT binary patch
> > > literal 6932
> > > zcmb7J3sjWXwf?sM%m9M}3aA(*B(X##snNz*U$IeRG>LimKpwtD@qvhnD4<9bH9<{c
> > > zuq4JwK}|`-nLKJMq^L > > z`OZH3?7h!E$7#<54T15u)dZ|(>zL;!@P@FRI}mW$dVc?6U;U=doSVeY|Ld>M|BzlY
> > > zU9fTnu=epjSoH)D$KUFieXwSh32UFUVBJ=1COl}`m>&9h#JdwL+&%nnBEvw>Lm
> > > zd|#}e>xWg(55mf4?nT1fepoYa2v*F!7i;GaMeMx$urA_mteig#@e4w+EMg?qN8W>k
> > > zsCy9`^+pkHE^vM-U$qj%Cq5!TLoHAYsvi*sx?2Vi!)v#-$G-e(6{{IQzmyg5p
> > > zrPHxt#ZQqKJ07viXJF~_S=h8{A`(_Vh83}MusC);HmsS7#I@6~aosd5i(7zA@sDHq
> > > z>L?_{(pIJj*SU(uxwo{HYd)*qWCx@ZQ|HXQCPZREjA`aW8sEP*qpo&
> > > zNn00T>E>i4rz}BC(l%^LU5-UbJFz)!1(LSMB06~(MAm > > z`;e5e3DK#qV9N`ek-RGj3%9?DZJEi~oVg8))3Xts{w7lQZo`(nsff > > za#t?4Wu+tKrA(ym--)!WJ&4(J9Lf7%#DdI|*m~e4MD8iTwu4znd3isg_BoLH$^pc@
> > > z_#V<;J&5gxUPeULhuHesAw=yjLdxN6q-MW?B?nI<`oKqsICvImKYtV3bB > > z^6!!U##=}|l85<+E+XyCV~BX|61E>bj`c@A#18ujL>?|f`de=!D*JQHJN!pvymbnx
> > > zx$k2B&;J7vIajg$*hwsSy$U<>-bebe4>9M63p > > z9Q_j_-uwa!j$X(1{4&1Au8_+>^%7qmgLnTqo5cu$Lq1{ > > zL<1JR-G~)$H(-bJW30)qMY`itEdFH^b~;P3B>yj1$zR5M7qRr6udwXhzasA4udwTb
> > > z%UFK08LLnJ6}vwy! > > z-;76Z`g49@7P=PCnWy*Yi#_@4ZQH%YuI$gjorny
> > > z*j#uMnP=;eRCEhlK5E0B^VgC5+ji_b_a*jy+<>jc9oTmEAK3kI3wHgk2`T3~k@?Br
> > > zkb3?$Qa)+No(q3R+Q{{CyEUFg8Rk{j6m`+wlYPu > > zu(MRho=fe>xY}IXaB%iVbK@;~un8OMC~UwG-WZe*7I3t9Z_`NO|3
> > > z69F=l`CuxfPl!xqYcht5^qI`o1pHVg@;eR>%TM`z7!$~On61&2{+WzsYZP14WfWTv
> > > zVwOC}Z#XGWiD=<$kHB+mjbLjy=E`t>??;4$@%tl0$$jy^rmCu|)3WHx!~R
> > > zmr%CuCfAGUFD!Cr_N!@gLjy!iGSNI8+LSRv;j1`{c4zNhJy!E!J9vIZcGl)87Pc+n
> > > z@q2eh`kRP+H*rGXB@!lQymdJ#!}^KL@zJ4OPY#4dBuL)z(?RHp%x+k8`9fxK
> > > z#5S`o*%k>Q!cc`UPTH-y+>-JBB5}UD+>~*gAyBUQ=< > > z5H%hjz%B0H;3HBp~#+kHIX&~jcjL<}KG#%#doaOOVAdga{#i?=c$Hkqa
> > > z)L71uN*Po8u~RwTq7IC~w3fHXMsnlCO!;Z@HOFRn@Dn& > > zl4;QfMcYi8CcD`>#S!oDJJ%+I4SXMwD)uvJt7rLb7R}b9dji+_oS}_bW|Q+d`(suA
> > > 

Re: [PATCH] imx: ventana: enable ONFI detection to fix NAND chip configuration

2022-03-28 Thread Tom Rini
On Tue, Mar 22, 2022 at 11:42:49AM -0700, Tim Harvey wrote:

> Enable ONFI detection to fix NAND chip configuration. Without this
> the NAND oobsize will be wrong which leads to invalid ECC strength and
> incompatibility with the previous configuration.
> 
> Fixes: 777f333c375a ("imx: ventana: enable dm for MTD and NAND")
> 
> Signed-off-by: Tim Harvey 
> Reviewed-by: Fabio Estevam 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 7/8] stm32mp: stm32prog: handle U-Boot script in flashlayout alternate

2022-03-28 Thread Patrick Delaunay
Update the stm32prog command to allow the reception of U-Boot script in
the FlashLayout alternate during the first USB enumeration.

This patch is aligned with the last TF-A behavior: the Flashlayout
is now loaded by U-Boot; it is no more present at STM32_DDR_BASE when
the stm32prog is launched after a serial boot, on UART or on USB.

The received script must be a U-Boot legacy image, no more need to add
a stm32image header.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c | 9 ++---
 arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 9 +
 arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h | 2 ++
 3 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index 3957e06e5d..f59414e716 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -76,13 +76,6 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, int 
argc,
stm32prog_header_check(addr, );
if (header.type == HEADER_STM32IMAGE) {
size = header.image_length + header.length;
-
-#if defined(CONFIG_LEGACY_IMAGE_FORMAT)
-   /* uImage detected in STM32IMAGE, execute the script */
-   if (IMAGE_FORMAT_LEGACY ==
-   genimg_get_format((void *)(addr + header.length)))
-   return image_source_script(addr + 
header.length, "script@1");
-#endif
}
}
 
@@ -160,6 +153,8 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, 
int argc,
else if (CONFIG_IS_ENABLED(CMD_BOOTZ))
do_bootz(cmdtp, 0, 4, bootm_argv);
}
+   if (data->script)
+   image_source_script(data->script, "script@stm32prog");
 
if (reset) {
puts("Reset...\n");
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index d3b3e1ed72..65655e25ca 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1697,6 +1698,14 @@ error:
 static void stm32prog_end_phase(struct stm32prog_data *data, u64 offset)
 {
if (data->phase == PHASE_FLASHLAYOUT) {
+#if defined(CONFIG_LEGACY_IMAGE_FORMAT)
+   if (genimg_get_format((void *)STM32_DDR_BASE) == 
IMAGE_FORMAT_LEGACY) {
+   data->script = STM32_DDR_BASE;
+   data->phase = PHASE_END;
+   log_notice("U-Boot script received\n");
+   return;
+   }
+#endif
if (parse_flash_layout(data, STM32_DDR_BASE, 0))
stm32prog_err("Layout: invalid FlashLayout");
return;
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h 
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
index b3e5c74810..ac300768ca 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h
@@ -170,6 +170,8 @@ struct stm32prog_data {
u32 initrd;
u32 initrd_size;
 
+   u32 script;
+
/* OPTEE PTA NVMEM */
struct udevice *tee;
u32 tee_session;
-- 
2.25.1



[PATCH 8/8] stm32mp: stm32prog: handle flashlayout without STM32 image header

2022-03-28 Thread Patrick Delaunay
Accept flashlayout without header in alternate 0, to simplify
the support of stm32prog command with dfu-util.

By default the flashlayout file size is the size of the received binary,
provided with the offset in the DFU alternate.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index 65655e25ca..b723ba 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -1706,7 +1706,8 @@ static void stm32prog_end_phase(struct stm32prog_data 
*data, u64 offset)
return;
}
 #endif
-   if (parse_flash_layout(data, STM32_DDR_BASE, 0))
+   log_notice("\nFlashLayout received, size = %lld\n", offset);
+   if (parse_flash_layout(data, STM32_DDR_BASE, offset))
stm32prog_err("Layout: invalid FlashLayout");
return;
}
-- 
2.25.1



[PATCH 5/8] stm32mp: stm32prog: add support of UUID for FIP partition

2022-03-28 Thread Patrick Delaunay
Add support of UUID for FIP parttion, required by Firmware update
support in TF-A:
- UUID TYPE for FIP partition: 19d5df83-11b0-457b-be2c-7559c13142a5
- "fip-a" partition UUID: 4fd84c93-54ef-463f-a7ef-ae25ff887087
- "fip-b" partition UUID: 09c54952-d5bf-45af-acee-335303766fb3

This check is done with a new partition type "FIP" associated
at the FIP UUID.

The A/B partition UUID is detected by the partition name:
"fip-a", "fip-b".

Signed-off-by: Patrick Delaunay 
---

 .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 76 ++-
 .../mach-stm32mp/cmd_stm32prog/stm32prog.h|  3 +-
 2 files changed, 59 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index 3e1fdee5b3..d3b3e1ed72 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -62,6 +62,28 @@ static const efi_guid_t uuid_mmc[3] = {
ROOTFS_MMC2_UUID
 };
 
+/* FIP type partition UUID used by TF-A*/
+#define FIP_TYPE_UUID "19D5DF83-11B0-457B-BE2C-7559C13142A5"
+
+/* unique partition guid (uuid) for FIP partitions A/B */
+#define FIP_A_UUID \
+   EFI_GUID(0x4FD84C93, 0x54EF, 0x463F, \
+0xA7, 0xEF, 0xAE, 0x25, 0xFF, 0x88, 0x70, 0x87)
+
+#define FIP_B_UUID \
+   EFI_GUID(0x09C54952, 0xD5BF, 0x45AF, \
+0xAC, 0xEE, 0x33, 0x53, 0x03, 0x76, 0x6F, 0xB3)
+
+static const char * const fip_part_name[] = {
+   "fip-a",
+   "fip-b"
+};
+
+static const efi_guid_t fip_part_uuid[] = {
+   FIP_A_UUID,
+   FIP_B_UUID
+};
+
 /* order of column in flash layout file */
 enum stm32prog_col_t {
COL_OPTION,
@@ -405,6 +427,8 @@ static int parse_type(struct stm32prog_data *data,
part->bin_nb =
dectoul([7], NULL);
}
+   } else if (!strcmp(p, "FIP")) {
+   part->part_type = PART_FIP;
} else if (!strcmp(p, "System")) {
part->part_type = PART_SYSTEM;
} else if (!strcmp(p, "FileSystem")) {
@@ -1056,9 +1080,10 @@ static int create_gpt_partitions(struct stm32prog_data 
*data)
char uuid[UUID_STR_LEN + 1];
unsigned char *uuid_bin;
unsigned int mmc_id;
-   int i;
+   int i, j;
bool rootfs_found;
struct stm32prog_part_t *part;
+   const char *type_str;
 
buf = malloc(buflen);
if (!buf)
@@ -1100,33 +1125,46 @@ static int create_gpt_partitions(struct stm32prog_data 
*data)
   part->addr,
   part->size);
 
-   if (part->part_type == PART_BINARY)
-   offset += snprintf(buf + offset,
-  buflen - offset,
-  ",type="
-  LINUX_RESERVED_UUID);
-   else
-   offset += snprintf(buf + offset,
-  buflen - offset,
-  ",type=linux");
+   switch (part->part_type) {
+   case PART_BINARY:
+   type_str = LINUX_RESERVED_UUID;
+   break;
+   case PART_FIP:
+   type_str = FIP_TYPE_UUID;
+   break;
+   default:
+   type_str = "linux";
+   break;
+   }
+   offset += snprintf(buf + offset,
+  buflen - offset,
+  ",type=%s", type_str);
 
if (part->part_type == PART_SYSTEM)
offset += snprintf(buf + offset,
   buflen - offset,
   ",bootable");
 
+   /* partition UUID */
+   uuid_bin = NULL;
if (!rootfs_found && !strcmp(part->name, "rootfs")) {
mmc_id = part->dev_id;
rootfs_found = true;
-   if (mmc_id < ARRAY_SIZE(uuid_mmc)) {
-   uuid_bin =
- (unsigned char *)uuid_mmc[mmc_id].b;
-   uuid_bin_to_str(uuid_bin, uuid,
-   UUID_STR_FORMAT_GUID);
-   offset += snprintf(buf + offset,
-  buflen - offset,
-  

[PATCH 6/8] stm32mp: stm32prog: handle interruption during the first enumeration

2022-03-28 Thread Patrick Delaunay
When an interruption is received during the first USB enumeration
used to received the FlashLayout, with handle ctrl-c, the second
enumeration is not needed and the result for stm32prog_usb_loop
is false (reset is not needed).

This patch avoids the need of a second ctrl to interrupt the command
stm32prog.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c
index 82b702f93b..a8b57c4d8f 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog_usb.c
@@ -206,9 +206,12 @@ bool stm32prog_usb_loop(struct stm32prog_data *data, int 
dev)
g_dnl_set_product(product);
 
if (stm32prog_data->phase == PHASE_FLASHLAYOUT) {
+   /* forget any previous Control C */
+   clear_ctrlc();
ret = run_usb_dnl_gadget(dev, "usb_dnl_dfu");
-   if (ret || stm32prog_data->phase != PHASE_FLASHLAYOUT)
-   return ret;
+   /* DFU reset received, no error or CtrlC */
+   if (ret || stm32prog_data->phase != PHASE_FLASHLAYOUT || 
had_ctrlc())
+   return ret; /* true = reset on DFU error */
/* prepare the second enumeration with the FlashLayout */
stm32prog_dfu_init(data);
}
-- 
2.25.1



[PATCH 4/8] stm32mp: stm32prog: add support of STM32IMAGE version 2

2022-03-28 Thread Patrick Delaunay
Add support of new header for the STM32IMAGE version V2
in command stm32prog command for STM32MP13x family.

Signed-off-by: Patrick Delaunay 
---

 .../cmd_stm32prog/cmd_stm32prog.c |   8 +-
 .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 119 --
 .../mach-stm32mp/cmd_stm32prog/stm32prog.h|  35 --
 3 files changed, 114 insertions(+), 48 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index 41452b5a29..3957e06e5d 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -73,15 +73,15 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, 
int argc,
 
/* check STM32IMAGE presence */
if (size == 0) {
-   stm32prog_header_check((struct raw_header_s *)addr, );
+   stm32prog_header_check(addr, );
if (header.type == HEADER_STM32IMAGE) {
-   size = header.image_length + BL_HEADER_SIZE;
+   size = header.image_length + header.length;
 
 #if defined(CONFIG_LEGACY_IMAGE_FORMAT)
/* uImage detected in STM32IMAGE, execute the script */
if (IMAGE_FORMAT_LEGACY ==
-   genimg_get_format((void *)(addr + BL_HEADER_SIZE)))
-   return image_source_script(addr + 
BL_HEADER_SIZE, "script@1");
+   genimg_get_format((void *)(addr + header.length)))
+   return image_source_script(addr + 
header.length, "script@1");
 #endif
}
}
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index 5d53e6146f..3e1fdee5b3 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -205,52 +205,98 @@ static bool stm32prog_is_fip_header(struct fip_toc_header 
*header)
return (header->name == FIP_TOC_HEADER_NAME) && header->serial_number;
 }
 
-void stm32prog_header_check(struct raw_header_s *raw_header,
-   struct image_header_s *header)
+static bool stm32prog_is_stm32_header_v1(struct stm32_header_v1 *header)
 {
unsigned int i;
 
-   if (!raw_header || !header) {
-   log_debug("%s:no header data\n", __func__);
-   return;
+   if (header->magic_number !=
+   (('S' << 0) | ('T' << 8) | ('M' << 16) | (0x32 << 24))) {
+   log_debug("%s:invalid magic number : 0x%x\n",
+ __func__, header->magic_number);
+   return false;
+   }
+   if (header->header_version != 0x0001) {
+   log_debug("%s:invalid header version : 0x%x\n",
+ __func__, header->header_version);
+   return false;
}
 
-   header->type = HEADER_NONE;
-   header->image_checksum = 0x0;
-   header->image_length = 0x0;
-
-   if (stm32prog_is_fip_header((struct fip_toc_header *)raw_header)) {
-   header->type = HEADER_FIP;
-   return;
+   if (header->reserved1 || header->reserved2) {
+   log_debug("%s:invalid reserved field\n", __func__);
+   return false;
+   }
+   for (i = 0; i < sizeof(header->padding); i++) {
+   if (header->padding[i] != 0) {
+   log_debug("%s:invalid padding field\n", __func__);
+   return false;
+   }
}
 
-   if (raw_header->magic_number !=
+   return true;
+}
+
+static bool stm32prog_is_stm32_header_v2(struct stm32_header_v2 *header)
+{
+   unsigned int i;
+
+   if (header->magic_number !=
(('S' << 0) | ('T' << 8) | ('M' << 16) | (0x32 << 24))) {
log_debug("%s:invalid magic number : 0x%x\n",
- __func__, raw_header->magic_number);
-   return;
+ __func__, header->magic_number);
+   return false;
}
-   /* only header v1.0 supported */
-   if (raw_header->header_version != 0x0001) {
+   if (header->header_version != 0x0002) {
log_debug("%s:invalid header version : 0x%x\n",
- __func__, raw_header->header_version);
+ __func__, header->header_version);
+   return false;
+   }
+   if (header->reserved1 || header->reserved2)
+   return false;
+
+   for (i = 0; i < sizeof(header->padding); i++) {
+   if (header->padding[i] != 0) {
+   log_debug("%s:invalid padding field\n", __func__);
+   return false;
+   }
+   }
+
+   return true;
+}
+
+void stm32prog_header_check(uintptr_t raw_header, struct image_header_s 
*header)
+{
+   struct stm32_header_v1 

[PATCH 3/8] stm32mp: stm32prog: add TEE support in stm32prog command

2022-03-28 Thread Patrick Delaunay
When OP-TEE is used, the SMC for BSEC management are not
available and the PTA provisioning for OTP must be used.

U-Boot opens the session to this PTA and use it for OTP
access.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig   |   2 +-
 .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 145 --
 .../mach-stm32mp/cmd_stm32prog/stm32prog.h|   7 +-
 .../cmd_stm32prog/stm32prog_usb.c |   2 +-
 4 files changed, 142 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig 
b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
index 81d2b87035..8f91db4b46 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
@@ -35,6 +35,6 @@ config CMD_STM32PROG_SERIAL
 config CMD_STM32PROG_OTP
bool "support stm32prog for OTP update"
depends on CMD_STM32PROG
-   default y if ARM_SMCCC
+   default y if ARM_SMCCC || OPTEE
help
Support the OTP update with the command "stm32prog" for STM32MP
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index 3e9354b51d..5d53e6146f 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -10,8 +10,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -79,8 +81,110 @@ struct fip_toc_header {
u64 flags;
 };
 
+#define TA_NVMEM_UUID { 0x1a8342cc, 0x81a5, 0x4512, \
+   { 0x99, 0xfe, 0x9e, 0x2b, 0x3e, 0x37, 0xd6, 0x26 } }
+
+/*
+ * Read NVMEM memory for STM32CubeProgrammer
+ *
+ * [in]value[0].a: Type (0 for OTP access)
+ * [out]   memref[1].bufferOutput buffer to return all read values
+ * [out]   memref[1].size  Size of buffer to be read
+ *
+ * Return codes:
+ * TEE_SUCCESS - Invoke command success
+ * TEE_ERROR_BAD_PARAMETERS - Incorrect input param
+ */
+#define TA_NVMEM_READ  0x0
+
+/*
+ * Write NVMEM memory for STM32CubeProgrammer
+ *
+ * [in] value[0].a Type (0 for OTP access)
+ * [in]  memref[1].buffer  Input buffer with the values to write
+ * [in]  memref[1].sizeSize of buffer to be written
+ *
+ * Return codes:
+ * TEE_SUCCESS - Invoke command success
+ * TEE_ERROR_BAD_PARAMETERS - Incorrect input param
+ */
+#define TA_NVMEM_WRITE 0x1
+
+/* value of TA_NVMEM type = value[in] a */
+#define NVMEM_OTP  0
+
 DECLARE_GLOBAL_DATA_PTR;
 
+/* OPTEE TA NVMEM open helper */
+static int optee_ta_open(struct stm32prog_data *data)
+{
+   const struct tee_optee_ta_uuid uuid = TA_NVMEM_UUID;
+   struct tee_open_session_arg arg;
+   struct udevice *tee = NULL;
+   int rc;
+
+   if (data->tee)
+   return 0;
+
+   tee = tee_find_device(NULL, NULL, NULL, NULL);
+   if (!tee)
+   return -ENODEV;
+
+   memset(, 0, sizeof(arg));
+   tee_optee_ta_uuid_to_octets(arg.uuid, );
+   rc = tee_open_session(tee, , 0, NULL);
+   if (rc < 0)
+   return -ENODEV;
+
+   data->tee = tee;
+   data->tee_session = arg.session;
+
+   return 0;
+}
+
+/* OPTEE TA NVMEM invoke helper */
+static int optee_ta_invoke(struct stm32prog_data *data, int cmd, int type,
+  void *buff, ulong size)
+{
+   struct tee_invoke_arg arg;
+   struct tee_param param[2];
+   struct tee_shm *buff_shm;
+   int rc;
+
+   rc = tee_shm_register(data->tee, buff, size, 0, _shm);
+   if (rc)
+   return rc;
+
+   memset(, 0, sizeof(arg));
+   arg.func = cmd;
+   arg.session = data->tee_session;
+
+   memset(param, 0, sizeof(param));
+   param[0].attr = TEE_PARAM_ATTR_TYPE_VALUE_INPUT;
+   param[0].u.value.a = type;
+
+   if (cmd == TA_NVMEM_WRITE)
+   param[1].attr = TEE_PARAM_ATTR_TYPE_MEMREF_INPUT;
+   else
+   param[1].attr = TEE_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
+
+   param[1].u.memref.shm = buff_shm;
+   param[1].u.memref.size = size;
+
+   rc = tee_invoke_func(data->tee, , 2, param);
+   if (rc < 0 || arg.ret != 0) {
+   dev_err(data->tee,
+   "TA_NVMEM invoke failed TEE err: %x, err:%x\n",
+   arg.ret, rc);
+   if (!rc)
+   rc = -EIO;
+   }
+
+   tee_shm_free(buff_shm);
+
+   return rc;
+}
+
 /* partition handling routines : CONFIG_CMD_MTDPARTS */
 int mtdparts_init(void);
 int find_dev_and_part(const char *id, struct mtd_device **dev,
@@ -1208,7 +1312,11 @@ static int dfu_init_entities(struct stm32prog_data *data)
ret = stm32prog_alt_add_virt(dfu, "virtual", PHASE_CMD, 
CMD_SIZE);
 
if (!ret && IS_ENABLED(CONFIG_CMD_STM32PROG_OTP)) {
-   ret = stm32prog_alt_add_virt(dfu, "OTP", PHASE_OTP, OTP_SIZE);

[PATCH 2/8] stm32mp: stm32prog: add CONFIG_CMD_STM32PROG_OTP

2022-03-28 Thread Patrick Delaunay
Add a configuration flag CONFIG_CMD_STM32PROG_OTP to enable the support of
OTP update in stm32prog command.

This new configuration allows to deactivate this feature for security reason
and it is a preliminary step for support of OPT update with the OP-TEE
provisioning TA.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig   |  7 ++
 .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 66 +++
 2 files changed, 46 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig 
b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
index dd166a1f91..81d2b87035 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig
@@ -31,3 +31,10 @@ config CMD_STM32PROG_SERIAL
activate the command "stm32prog serial" for STM32MP soc family
with the tools STM32CubeProgrammer using U-Boot serial device
and UART protocol.
+
+config CMD_STM32PROG_OTP
+   bool "support stm32prog for OTP update"
+   depends on CMD_STM32PROG
+   default y if ARM_SMCCC
+   help
+   Support the OTP update with the command "stm32prog" for STM32MP
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index d513a60efb..3e9354b51d 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -1154,7 +1154,9 @@ static int dfu_init_entities(struct stm32prog_data *data)
struct dfu_entity *dfu;
int alt_nb;
 
-   alt_nb = 2; /* number of virtual = CMD, OTP*/
+   alt_nb = 1; /* number of virtual = CMD*/
+   if (IS_ENABLED(CONFIG_CMD_STM32PROG_OTP))
+   alt_nb++; /* OTP*/
if (CONFIG_IS_ENABLED(DM_PMIC))
alt_nb++; /* PMIC NVMEM*/
 
@@ -1205,7 +1207,7 @@ static int dfu_init_entities(struct stm32prog_data *data)
if (!ret)
ret = stm32prog_alt_add_virt(dfu, "virtual", PHASE_CMD, 
CMD_SIZE);
 
-   if (!ret)
+   if (!ret && IS_ENABLED(CONFIG_CMD_STM32PROG_OTP)) {
ret = stm32prog_alt_add_virt(dfu, "OTP", PHASE_OTP, OTP_SIZE);
 
if (!ret && CONFIG_IS_ENABLED(DM_PMIC))
@@ -1226,6 +1228,11 @@ int stm32prog_otp_write(struct stm32prog_data *data, u32 
offset, u8 *buffer,
 {
log_debug("%s: %x %lx\n", __func__, offset, *size);
 
+   if (!IS_ENABLED(CONFIG_CMD_STM32PROG_OTP)) {
+   stm32prog_err("OTP update not supported");
+
+   return -EOPNOTSUPP;
+   }
if (!data->otp_part) {
data->otp_part = memalign(CONFIG_SYS_CACHELINE_SIZE, OTP_SIZE);
if (!data->otp_part)
@@ -1248,10 +1255,10 @@ int stm32prog_otp_read(struct stm32prog_data *data, u32 
offset, u8 *buffer,
 {
int result = 0;
 
-   if (!IS_ENABLED(CONFIG_ARM_SMCCC)) {
+   if (!IS_ENABLED(CONFIG_CMD_STM32PROG_OTP)) {
stm32prog_err("OTP update not supported");
 
-   return -1;
+   return -EOPNOTSUPP;
}
 
log_debug("%s: %x %lx\n", __func__, offset, *size);
@@ -1270,8 +1277,10 @@ int stm32prog_otp_read(struct stm32prog_data *data, u32 
offset, u8 *buffer,
memset(data->otp_part, 0, OTP_SIZE);
 
/* call the service */
-   result = stm32_smc_exec(STM32_SMC_BSEC, STM32_SMC_READ_ALL,
-   (u32)data->otp_part, 0);
+   result = -EOPNOTSUPP;
+   if (IS_ENABLED(CONFIG_ARM_SMCCC))
+   result = stm32_smc_exec(STM32_SMC_BSEC, 
STM32_SMC_READ_ALL,
+   (u32)data->otp_part, 0);
if (result)
goto end_otp_read;
}
@@ -1296,10 +1305,10 @@ int stm32prog_otp_start(struct stm32prog_data *data)
int result = 0;
struct arm_smccc_res res;
 
-   if (!IS_ENABLED(CONFIG_ARM_SMCCC)) {
+   if (!IS_ENABLED(CONFIG_CMD_STM32PROG_OTP)) {
stm32prog_err("OTP update not supported");
 
-   return -1;
+   return -EOPNOTSUPP;
}
 
if (!data->otp_part) {
@@ -1307,28 +1316,31 @@ int stm32prog_otp_start(struct stm32prog_data *data)
return -1;
}
 
-   arm_smccc_smc(STM32_SMC_BSEC, STM32_SMC_WRITE_ALL,
- (u32)data->otp_part, 0, 0, 0, 0, 0, );
+   result = -EOPNOTSUPP;
+   if (IS_ENABLED(CONFIG_ARM_SMCCC)) {
+   arm_smccc_smc(STM32_SMC_BSEC, STM32_SMC_WRITE_ALL,
+ (u32)data->otp_part, 0, 0, 0, 0, 0, );
 
-   if (!res.a0) {
-   switch (res.a1) {
-   case 0:
-   result = 0;
-   break;
-   case 1:
-   stm32prog_err("Provisioning");
-   result = 0;
-   break;
-   default:
-   

[PATCH 0/8] stm32mp: command stm32prog improvements

2022-03-28 Thread Patrick Delaunay
Several patches to improve the command stm32prog command.
This command is used to program the STMicroelectronics boards with the
tools STM32CubeProgrammer and flashlayout file.


Patrick Delaunay (8):
  stm32mp: stm32prog: fix comment
  stm32mp: stm32prog: add CONFIG_CMD_STM32PROG_OTP
  stm32mp: stm32prog: add TEE support in stm32prog command
  stm32mp: stm32prog: add support of STM32IMAGE version 2
  stm32mp: stm32prog: add support of UUID for FIP partition
  stm32mp: stm32prog: handle interruption during the first enumeration
  stm32mp: stm32prog: handle U-Boot script in flashlayout alternate
  stm32mp: stm32prog: handle flashlayout without STM32 image header

 arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig   |   7 +
 .../cmd_stm32prog/cmd_stm32prog.c |  13 +-
 .../mach-stm32mp/cmd_stm32prog/stm32prog.c| 418 ++
 .../mach-stm32mp/cmd_stm32prog/stm32prog.h|  47 +-
 .../cmd_stm32prog/stm32prog_usb.c |   9 +-
 5 files changed, 378 insertions(+), 116 deletions(-)

-- 
2.25.1



[PATCH 1/8] stm32mp: stm32prog: fix comment

2022-03-28 Thread Patrick Delaunay
Fix "partition" in comment.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c 
b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
index 61cba157fd..d513a60efb 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
@@ -46,7 +46,7 @@
EFI_GUID(0xFD58F1C7, 0xBE0D, 0x4338, \
 0x88, 0xE9, 0xAD, 0x8F, 0x05, 0x0A, 0xEB, 0x18)
 
-/* RAW parttion (binary / bootloader) used Linux - reserved UUID */
+/* RAW partition (binary / bootloader) used Linux - reserved UUID */
 #define LINUX_RESERVED_UUID "8DA63339-0007-60C0-C436-083AC8230908"
 
 /*
-- 
2.25.1



Re: [PATCH] usb_hub: Set DM_FLAG_DEFAULT_PD_CTRL_OFF to usb_hub driver

2022-03-28 Thread Marek Vasut

On 3/28/22 11:09, Ye Li wrote:

Because usb_hub uses same device tree node with USB controller device,
when probe and remove usb_hub, it will call the power domain control of
USB controller device.
This is not expected, because power domain control implmentation may not
have count when the power domain is dedicated for USB controller. So once
removed usb_hub, the power domain is power off before removing USB controller.

Signed-off-by: Ye Li 
---
  common/usb_hub.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/usb_hub.c b/common/usb_hub.c
index ba11a18..990993a 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -950,7 +950,7 @@ U_BOOT_DRIVER(usb_generic_hub) = {
.name   = "usb_hub",
.id = UCLASS_USB_HUB,
.of_match = usb_hub_ids,
-   .flags  = DM_FLAG_ALLOC_PRIV_DMA,
+   .flags  = DM_FLAG_ALLOC_PRIV_DMA | DM_FLAG_DEFAULT_PD_CTRL_OFF,
  };


+CC Simon.

Which device does trigger this behavior ?
Do you have a test case you can share ?


Re: [PATCH] imx: ventana: enable ONFI detection to fix NAND chip configuration

2022-03-28 Thread Tom Rini
On Mon, Mar 28, 2022 at 09:40:59AM -0700, Tim Harvey wrote:
> On Tue, Mar 22, 2022 at 5:32 PM Fabio Estevam  wrote:
> >
> > Hi Tim,
> >
> > On Tue, Mar 22, 2022 at 3:42 PM Tim Harvey  wrote:
> > >
> > > Enable ONFI detection to fix NAND chip configuration. Without this
> > > the NAND oobsize will be wrong which leads to invalid ECC strength and
> > > incompatibility with the previous configuration.
> > >
> > > Fixes: 777f333c375a ("imx: ventana: enable dm for MTD and NAND")
> > >
> > > Signed-off-by: Tim Harvey 
> >
> > Reviewed-by: Fabio Estevam 
> 
> Tom and Stefano,
> 
> With commit ed48490f8d3f ("mtd: gpmi: fix the bch setting backward
> compatible issue") now applied could this be applied for v2022.04 as
> well to fix NAND on the gw_ventana boards?

Yes, thanks.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] imx: ventana: enable ONFI detection to fix NAND chip configuration

2022-03-28 Thread Tim Harvey
On Tue, Mar 22, 2022 at 5:32 PM Fabio Estevam  wrote:
>
> Hi Tim,
>
> On Tue, Mar 22, 2022 at 3:42 PM Tim Harvey  wrote:
> >
> > Enable ONFI detection to fix NAND chip configuration. Without this
> > the NAND oobsize will be wrong which leads to invalid ECC strength and
> > incompatibility with the previous configuration.
> >
> > Fixes: 777f333c375a ("imx: ventana: enable dm for MTD and NAND")
> >
> > Signed-off-by: Tim Harvey 
>
> Reviewed-by: Fabio Estevam 

Tom and Stefano,

With commit ed48490f8d3f ("mtd: gpmi: fix the bch setting backward
compatible issue") now applied could this be applied for v2022.04 as
well to fix NAND on the gw_ventana boards?

Best Regards,

Tim


Re: [ANN] U-Boot v2022.04-rc5 released

2022-03-28 Thread Tom Rini
On Mon, Mar 28, 2022 at 04:38:36PM +, Peter Robinson wrote:
> On Mon, Mar 28, 2022 at 5:33 PM Tom Rini  wrote:
> >
> > On Mon, Mar 28, 2022 at 04:30:48PM +, Peter Robinson wrote:
> > > On Mon, Mar 28, 2022 at 3:17 PM Tom Rini  wrote:
> > > >
> > > > Hey all,
> > > >
> > > > It's release day and so here's v2022.04-rc5.  The release itself is next
> > > > week and the next branch is open.  I've merged all regression and
> > > > critical fixes I know of so if something else is missing please speak up
> > > > as soon as possible.
> > > >
> > > > In terms of a changelog,
> > > > git log --merges v2022.04-rc4..v2022.04-rc5
> > > > contains what I've pulled but as always, better PR messages and tags
> > > > will provide better results here.
> > > >
> > > > The next release will be the final one in this cycle, April 4th 2022.
> > > > Thanks all!
> > >
> > > The tar file is incorrectly named with the middle numbers in the year
> > > the wrong way about u-boot-2202.04-rc5.tar.bz2
> >
> > :headdesk: I caught the tag being wrong but forgot that part too.  I'll
> > re-upload shortly.
> 
> The directory is wrong too but I'm guessing you knew that already
> given the generation process.

Correct.  I've re-run that part of the process and uploaded.  It should
be live now.


-- 
Tom


signature.asc
Description: PGP signature


Re: [ANN] U-Boot v2022.04-rc5 released

2022-03-28 Thread Peter Robinson
On Mon, Mar 28, 2022 at 5:33 PM Tom Rini  wrote:
>
> On Mon, Mar 28, 2022 at 04:30:48PM +, Peter Robinson wrote:
> > On Mon, Mar 28, 2022 at 3:17 PM Tom Rini  wrote:
> > >
> > > Hey all,
> > >
> > > It's release day and so here's v2022.04-rc5.  The release itself is next
> > > week and the next branch is open.  I've merged all regression and
> > > critical fixes I know of so if something else is missing please speak up
> > > as soon as possible.
> > >
> > > In terms of a changelog,
> > > git log --merges v2022.04-rc4..v2022.04-rc5
> > > contains what I've pulled but as always, better PR messages and tags
> > > will provide better results here.
> > >
> > > The next release will be the final one in this cycle, April 4th 2022.
> > > Thanks all!
> >
> > The tar file is incorrectly named with the middle numbers in the year
> > the wrong way about u-boot-2202.04-rc5.tar.bz2
>
> :headdesk: I caught the tag being wrong but forgot that part too.  I'll
> re-upload shortly.

The directory is wrong too but I'm guessing you knew that already
given the generation process.


Re: [ANN] U-Boot v2022.04-rc5 released

2022-03-28 Thread Tom Rini
On Mon, Mar 28, 2022 at 04:30:48PM +, Peter Robinson wrote:
> On Mon, Mar 28, 2022 at 3:17 PM Tom Rini  wrote:
> >
> > Hey all,
> >
> > It's release day and so here's v2022.04-rc5.  The release itself is next
> > week and the next branch is open.  I've merged all regression and
> > critical fixes I know of so if something else is missing please speak up
> > as soon as possible.
> >
> > In terms of a changelog,
> > git log --merges v2022.04-rc4..v2022.04-rc5
> > contains what I've pulled but as always, better PR messages and tags
> > will provide better results here.
> >
> > The next release will be the final one in this cycle, April 4th 2022.
> > Thanks all!
> 
> The tar file is incorrectly named with the middle numbers in the year
> the wrong way about u-boot-2202.04-rc5.tar.bz2

:headdesk: I caught the tag being wrong but forgot that part too.  I'll
re-upload shortly.

-- 
Tom


signature.asc
Description: PGP signature


Re: [ANN] U-Boot v2022.04-rc5 released

2022-03-28 Thread Peter Robinson
On Mon, Mar 28, 2022 at 3:17 PM Tom Rini  wrote:
>
> Hey all,
>
> It's release day and so here's v2022.04-rc5.  The release itself is next
> week and the next branch is open.  I've merged all regression and
> critical fixes I know of so if something else is missing please speak up
> as soon as possible.
>
> In terms of a changelog,
> git log --merges v2022.04-rc4..v2022.04-rc5
> contains what I've pulled but as always, better PR messages and tags
> will provide better results here.
>
> The next release will be the final one in this cycle, April 4th 2022.
> Thanks all!

The tar file is incorrectly named with the middle numbers in the year
the wrong way about u-boot-2202.04-rc5.tar.bz2


Layerscape DM_SERIAL (Was: Re: [PATCH v3 16/29] serial: Add semihosting driver)

2022-03-28 Thread Sean Anderson
Hi Tom,

On 3/28/22 12:03 PM, Tom Rini wrote:
> On Mon, Mar 28, 2022 at 11:36:46AM -0400, Sean Anderson wrote:
>> On 3/28/22 2:35 AM, Simon Glass wrote:
>>  
>> > But please can we drop the non-DM support?
>> 
>> Unfortunately, Layerscape does not support DM serial. I tried converting
>> it, but I ran into some unusual aborts. At the moment, I don't have time
>> to debug things further. And I thought that non-DM serial was ok for
>> SPL?
> 
> It is OK for SPL, and it needs migration for non-SPL.  Can you make
> another thread with your conversion-that-fails for layerscape please?
> 

Unfortunately, I didn't save my attempt. I believe it's just

diff --git a/include/configs/ls1046a_common.h b/include/configs/ls1046a_common.h
index 7552610e03..f7aaddd98c 100644
--- a/include/configs/ls1046a_common.h
+++ b/include/configs/ls1046a_common.h
@@ -48,8 +48,10 @@
 #define COUNTER_FREQUENCY  2500/* 25MHz */
 
 /* Serial Port */
+#if !CONFIG_IS_ENABLED(DM_SERIAL)
 #define CONFIG_SYS_NS16550_SERIAL
 #define CONFIG_SYS_NS16550_REG_SIZE1
+#endif
 #define CONFIG_SYS_NS16550_CLK  (get_serial_clock())
 
 /* SD boot SPL */
--

plus enabling the appropriate configs. I think I was using CONFIG_DM_SERIAL
and possibly CONFIG_NS16550_DYNAMIC.

--Sean


Re: [PATCH v2 1/3] rng: add OP-TEE based Random Number Generator

2022-03-28 Thread Patrick DELAUNAY

Hi,

On 3/28/22 15:25, Heinrich Schuchardt wrote:

On 3/28/22 15:11, Patrick Delaunay wrote:

Add driver for OP-TEE based Random Number Generator on ARM SoCs
where hardware entropy sources are not accessible to normal world
and the RNG service is provided by a HWRNG Trusted Application (TA).

This driver is based on the linux driver: char/hw_random/optee-rng.c

Series_changes: 2
- change SPDX-License-Identifier, becausee "GPL-2.0+” is obsolete
   reference: https://spdx.dev/ids/
- update Kconfig long help message as proposed by Heinrich
- replace memset(.., 0, sizeof(..)) by struct initialisation (= {0};)
- add function descriptions

Signed-off-by: Patrick Delaunay 
---

(no changes since v1)

  MAINTAINERS |   1 +
  drivers/rng/Kconfig |   9 ++
  drivers/rng/Makefile    |   1 +
  drivers/rng/optee_rng.c | 180 
  4 files changed, 191 insertions(+)
  create mode 100644 drivers/rng/optee_rng.c

diff --git a/MAINTAINERS b/MAINTAINERS
index f25ca7cd00..3356c65dd0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -481,6 +481,7 @@ F:    drivers/power/regulator/stpmic1.c
  F:    drivers/ram/stm32mp1/
  F:    drivers/remoteproc/stm32_copro.c
  F:    drivers/reset/stm32-reset.c
+F:    drivers/rng/optee_rng.c
  F:    drivers/rng/stm32mp1_rng.c
  F:    drivers/rtc/stm32_rtc.c
  F:    drivers/serial/serial_stm32.*



(...)



+++ b/drivers/rng/optee_rng.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
+/*
+ * Copyright (C) 2022, STMicroelectronics - All Rights Reserved
+ */
+#define LOG_CATEGORY UCLASS_RNG
+



(...)



+
+/**
+ * optee_rng_probe() - probe function for OP-TEE RNG device
+ *
+ * @dev:    device
+ * Return:    0 if ok
+ */
+static int optee_rng_probe(struct udevice *dev)
+{
+    const struct tee_optee_ta_uuid uuid = TA_HWRNG_UUID;
+    struct optee_rng_priv *priv = dev_get_priv(dev);
+    struct tee_open_session_arg sess_arg = {0};
+    int ret;
+
+    /* Open session with hwrng Trusted App */
+    tee_optee_ta_uuid_to_octets(sess_arg.uuid, );
+    sess_arg.clnt_login = TEE_LOGIN_PUBLIC;
+
+    ret = tee_open_session(dev->parent, _arg, 0, NULL);
+    if (ret || sess_arg.ret) {
+    if (!ret)
+    ret = -EIO;
+    dev_err(dev, "can't open session: %d 0x%x\n", ret, 
sess_arg.ret);

+    return ret;
+    }
+    priv->session_id = sess_arg.session;


Is it really necessary to keep the session open?
Or should we reopen a session whenever a random number is requested?

Best regards

Heinrich



No, I don't think that it is necessary.

I just use the same mechanism than Linux driver

(drivers/char/hw_random/optee-rng.c:optee_rng_probe/optee_rng_remove)

or in other U-Boot driver = drivers/tpm/tpm2_ftpm_tee.c.


But I check with Etienne, which provide the SCMI over OP-TEE implementation,

It seens that manage the optee session in probe/remove function in U-Boot is

not recommended, because when the drivers are used before relocation the

remove function is not called (so the session is not freed)

and because the time of the session open procedure is not the largest part.


=> I will remove it to simplify this driver.


regards

Patrick



Re: [PATCH v3 16/29] serial: Add semihosting driver

2022-03-28 Thread Tom Rini
On Mon, Mar 28, 2022 at 11:36:46AM -0400, Sean Anderson wrote:
> 
> 
> On 3/28/22 2:35 AM, Simon Glass wrote:
> > Hi Sean,
> > 
> > On Tue, 22 Mar 2022 at 15:00, Sean Anderson  wrote:
> >>
> >> This adds a serial driver which uses semihosting calls to read and write
> >> to the host's console. For convenience, if CONFIG_DM_SERIAL is enabled,
> >> we will instantiate a serial driver. This allows users to enable this
> >> driver (which has no physical device) without modifying their device
> >> trees or board files. We also implement a non-DM driver for SPL, or for
> >> much faster output in U-Boot proper.
> >>
> >> There are three ways to print to the console:
> >>
> >> Method  Baud
> >> == =
> >> smh_putc in a loop   170
> >> smh_puts1600
> >> smh_write with :tt 2
> >> == =
> >>
> >> These speeds were measured using a 175 character message with a J-Link
> >> adapter. For reference, U-Boot typically prints around 2700 characters
> >> during boot on this board. There are two major factors affecting the
> >> speed of these functions. First, each breakpoint incurs a delay. Second,
> >> each debugger memory transaction incurs a delay. smh_putc has a
> >> breakpoint and memory transaction for every character. smh_puts has one
> >> breakpoint, but still has to use a transaction for every character. This
> >> is because we don't know the length up front, so OpenOCD has to check if
> >> each character is nul. smh_write has only one breakpoint and one memory
> >> transfer.
> >>
> >> DM serial drivers can only implement a putc interface, so we are stuck
> >> with the slowest API. Non-DM drivers can implement puts, which is vastly
> >> more efficient. When the driver starts up, we try to open :tt. Since
> >> this is an extension, this may fail. If it does, we fall back to
> >> smh_puts. We don't check :semihosting-features, since there are
> >> nonconforming implementations (OpenOCD) which don't implement it (but
> >> *do* implement :tt).
> >>
> >> Some semihosting implementations (QEMU) don't handle READC properly. To
> >> work around this, we try to use open/read (much like for stdin) if
> >> possible.
> >>
> >> There is no non-blocking I/O available, so we don't implement pending.
> >> This will cause __serial_tstc to always return true. If
> >> CONFIG_SERIAL_RX_BUFFER is enabled, _serial_tstc will try and read
> >> characters forever. To avoid this, we depend on this config being
> >> disabled.
> >>
> >> Signed-off-by: Sean Anderson 
> >> ---
> >>
> >> (no changes since v2)
> >>
> >> Changes in v2:
> >> - Fix baud numbers being off by 10
> >> - Fix typos in commit message
> >> - Rename non-DM driver struct to match format of other drivers
> >>
> >>  drivers/serial/Kconfig  |  22 +
> >>  drivers/serial/Makefile |   1 +
> >>  drivers/serial/serial.c |   2 +
> >>  drivers/serial/serial_semihosting.c | 147 
> >>  include/serial.h|   1 +
> >>  5 files changed, 173 insertions(+)
> >>  create mode 100644 drivers/serial/serial_semihosting.c
> >>
> > 
> > Reviewed-by: Simon Glass 
> > 
> > But please can we drop the non-DM support?
> 
> Unfortunately, Layerscape does not support DM serial. I tried converting
> it, but I ran into some unusual aborts. At the moment, I don't have time
> to debug things further. And I thought that non-DM serial was ok for
> SPL?

It is OK for SPL, and it needs migration for non-SPL.  Can you make
another thread with your conversion-that-fails for layerscape please?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 28/29] test: serial: Add test for putc/puts

2022-03-28 Thread Sean Anderson



On 3/28/22 2:35 AM, Simon Glass wrote:
> Hi Sean,
> 
> On Tue, 22 Mar 2022 at 15:00, Sean Anderson  wrote:
>>
>> This adds a test to ensure that puts is equivalent to putc called in a
>> loop. We don't verify the contents of the message to avoid having to
>> record console output a second time (though that could be added in the
>> future). The globals are initialized to non-zero values to avoid a
>> warning; in particular, the character count is off-by-one (but we always
>> make relative measurements).
>>
>> Signed-off-by: Sean Anderson 
>> ---
>>
>> Changes in v3:
>> - New
>>
>>  arch/sandbox/include/asm/serial.h |  6 ++
>>  drivers/serial/sandbox.c  | 23 +++
>>  test/dm/serial.c  | 19 +++
>>  3 files changed, 44 insertions(+), 4 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
> But please can you add functions to change sandbox_serial_enabled (and
> read from sandbox_serial_written) to asm/test.h since that is how
> these sorts of things are done in other drivers.
> 

Sure.

--Sean


Re: [PATCH v3 16/29] serial: Add semihosting driver

2022-03-28 Thread Sean Anderson



On 3/28/22 2:35 AM, Simon Glass wrote:
> Hi Sean,
> 
> On Tue, 22 Mar 2022 at 15:00, Sean Anderson  wrote:
>>
>> This adds a serial driver which uses semihosting calls to read and write
>> to the host's console. For convenience, if CONFIG_DM_SERIAL is enabled,
>> we will instantiate a serial driver. This allows users to enable this
>> driver (which has no physical device) without modifying their device
>> trees or board files. We also implement a non-DM driver for SPL, or for
>> much faster output in U-Boot proper.
>>
>> There are three ways to print to the console:
>>
>> Method  Baud
>> == =
>> smh_putc in a loop   170
>> smh_puts1600
>> smh_write with :tt 2
>> == =
>>
>> These speeds were measured using a 175 character message with a J-Link
>> adapter. For reference, U-Boot typically prints around 2700 characters
>> during boot on this board. There are two major factors affecting the
>> speed of these functions. First, each breakpoint incurs a delay. Second,
>> each debugger memory transaction incurs a delay. smh_putc has a
>> breakpoint and memory transaction for every character. smh_puts has one
>> breakpoint, but still has to use a transaction for every character. This
>> is because we don't know the length up front, so OpenOCD has to check if
>> each character is nul. smh_write has only one breakpoint and one memory
>> transfer.
>>
>> DM serial drivers can only implement a putc interface, so we are stuck
>> with the slowest API. Non-DM drivers can implement puts, which is vastly
>> more efficient. When the driver starts up, we try to open :tt. Since
>> this is an extension, this may fail. If it does, we fall back to
>> smh_puts. We don't check :semihosting-features, since there are
>> nonconforming implementations (OpenOCD) which don't implement it (but
>> *do* implement :tt).
>>
>> Some semihosting implementations (QEMU) don't handle READC properly. To
>> work around this, we try to use open/read (much like for stdin) if
>> possible.
>>
>> There is no non-blocking I/O available, so we don't implement pending.
>> This will cause __serial_tstc to always return true. If
>> CONFIG_SERIAL_RX_BUFFER is enabled, _serial_tstc will try and read
>> characters forever. To avoid this, we depend on this config being
>> disabled.
>>
>> Signed-off-by: Sean Anderson 
>> ---
>>
>> (no changes since v2)
>>
>> Changes in v2:
>> - Fix baud numbers being off by 10
>> - Fix typos in commit message
>> - Rename non-DM driver struct to match format of other drivers
>>
>>  drivers/serial/Kconfig  |  22 +
>>  drivers/serial/Makefile |   1 +
>>  drivers/serial/serial.c |   2 +
>>  drivers/serial/serial_semihosting.c | 147 
>>  include/serial.h|   1 +
>>  5 files changed, 173 insertions(+)
>>  create mode 100644 drivers/serial/serial_semihosting.c
>>
> 
> Reviewed-by: Simon Glass 
> 
> But please can we drop the non-DM support?

Unfortunately, Layerscape does not support DM serial. I tried converting
it, but I ran into some unusual aborts. At the moment, I don't have time
to debug things further. And I thought that non-DM serial was ok for
SPL?

--Sean


Re: [PATCH 2/6] image: fit: Add some helpers for getting data

2022-03-28 Thread Sean Anderson
Hi Simon,

On 3/28/22 2:35 AM, Simon Glass wrote:
> Hi Sean,
> 
> On Thu, 24 Mar 2022 at 12:23, Sean Anderson  wrote:
>>
>> Several different firmware users have repetitive code to extract the
>> firmware data from a FIT. Add some helper functions to reduce the amount
>> of repetition. fit_conf_get_prop_node (eventually) calls
>> fdt_check_node_offset_, so we can avoid an explicit if. In general, this
>> version avoids printing on error because the callers are typically
>> library functions, and because the FIT code generally has (debug)
>> prints of its own. One difference in these helpers is that they use
>> fit_image_get_data_and_size instead of fit_image_get_data, as the former
>> handles external data correctly.
>>
>> Signed-off-by: Sean Anderson 
>> ---
>>
>>  arch/arm/cpu/armv8/sec_firmware.c  | 39 ++---
>>  boot/image-fit.c   | 37 +++
>>  cmd/fpga.c | 24 +-
>>  drivers/net/fsl-mc/mc.c| 30 +++---
>>  drivers/net/pfe_eth/pfe_firmware.c | 40 +-
>>  include/image.h|  4 +++
>>  6 files changed, 53 insertions(+), 121 deletions(-)
> 
> It feels like this patch should be split up into generic / armv8 / fsp things.

OK, I will do that for V2.

(Actually, I think this series can be split into fs-loader and verified-boot).

>>
>> diff --git a/arch/arm/cpu/armv8/sec_firmware.c 
>> b/arch/arm/cpu/armv8/sec_firmware.c
>> index 41525a10d5..879eb6ec81 100644
>> --- a/arch/arm/cpu/armv8/sec_firmware.c
>> +++ b/arch/arm/cpu/armv8/sec_firmware.c
>> @@ -42,43 +42,8 @@ phys_addr_t sec_firmware_addr;
>>  static int sec_firmware_get_data(const void *sec_firmware_img,
>> const void **data, size_t *size)
>>  {
>> -   int conf_node_off, fw_node_off;
>> -   char *desc;
>> -   int ret;
>> -
>> -   conf_node_off = fit_conf_get_node(sec_firmware_img, NULL);
>> -   if (conf_node_off < 0) {
>> -   puts("SEC Firmware: no config\n");
>> -   return -ENOENT;
>> -   }
>> -
>> -   fw_node_off = fit_conf_get_prop_node(sec_firmware_img, conf_node_off,
>> -   SEC_FIRMWARE_FIT_IMAGE);
>> -   if (fw_node_off < 0) {
>> -   printf("SEC Firmware: No '%s' in config\n",
>> -  SEC_FIRMWARE_FIT_IMAGE);
>> -   return -ENOLINK;
>> -   }
>> -
>> -   /* Verify secure firmware image */
>> -   if (!(fit_image_verify(sec_firmware_img, fw_node_off))) {
>> -   printf("SEC Firmware: Bad firmware image (bad CRC)\n");
>> -   return -EINVAL;
>> -   }
>> -
>> -   if (fit_image_get_data(sec_firmware_img, fw_node_off, data, size)) {
>> -   printf("SEC Firmware: Can't get %s subimage data/size",
>> -  SEC_FIRMWARE_FIT_IMAGE);
>> -   return -ENOENT;
>> -   }
>> -
>> -   ret = fit_get_desc(sec_firmware_img, fw_node_off, );
>> -   if (ret)
>> -   printf("SEC Firmware: Can't get description\n");
>> -   else
>> -   printf("%s\n", desc);
>> -
>> -   return ret;
>> +   return fit_get_data_conf_prop(sec_firmware_img, 
>> SEC_FIRMWARE_FIT_IMAGE,
>> + data, size);
>>  }
>>
>>  /*
>> diff --git a/boot/image-fit.c b/boot/image-fit.c
>> index 6610035d0a..b87378cbf6 100644
>> --- a/boot/image-fit.c
>> +++ b/boot/image-fit.c
>> @@ -1919,6 +1919,43 @@ int fit_conf_get_prop_node(const void *fit, int 
>> noffset,
>> return fit_conf_get_prop_node_index(fit, noffset, prop_name, 0);
>>  }
>>
>> +static int fit_get_data_tail(const void *fit, int noffset,
>> +const void **data, size_t *size)
>> +{
>> +   char *desc;
>> +
>> +   if (noffset < 0)
>> +   return noffset;
>> +
>> +   if (!fit_image_verify(fit, noffset))
>> +   return -EINVAL;
>> +
>> +   if (fit_image_get_data_and_size(fit, noffset, data, size))
>> +   return -ENOENT;
>> +
>> +   if (!fit_get_desc(fit, noffset, ))
>> +   printf("%s\n", desc);
>> +
>> +   return 0;
>> +}
>> +
>> +int fit_get_data_node(const void *fit, const char *image_uname,
>> + const void **data, size_t *size)
>> +{
>> +   int noffset = fit_image_get_node(fit, image_uname);
>> +
>> +   return fit_get_data_tail(fit, noffset, data, size);
>> +}
>> +
>> +int fit_get_data_conf_prop(const void *fit, const char *prop_name,
>> +  const void **data, size_t *size)
>> +{
>> +   int noffset = fit_conf_get_node(fit, NULL);
>> +
>> +   noffset = fit_conf_get_prop_node(fit, noffset, prop_name);
>> +   return fit_get_data_tail(fit, noffset, data, size);
>> +}
>> +
>>  static int fit_image_select(const void *fit, int rd_noffset, int verify)
>>  {
>> fit_image_print(fit, rd_noffset, "   ");
>> diff 

Re: [EXT] [PATCH] ARM: imx: romapi: Repair FlexSPI NOR boot offset

2022-03-28 Thread Marek Vasut

On 3/28/22 08:54, Ye Li wrote:

Hi Marek,


Hi,

[...]


2. Update the u-boot.itb offset in imx8mp-u-boot.dtsi, set the
offset
to 0x5f000.  The previous offset 0x58000 is for SD, calculated by
0x6 - 0x8000 (32KB image offset).

   uboot: blob-ext@2 {
   filename = "u-boot.itb";
   offset = <0x5f000>;
   };

But that breaks booting from SD card for me ?


Do you want to use one flash.bin for both SD and flexspi?


Yes, the board I use can boot from SD/eMMC/FlexSPI. I don't want to 
build multiple confusing "flash.bin" files, one for each boot media.



When first introduced 8m support by imx8mimage.c, we expected the u-
boot.itb at same device offset (0x6) on SD/emmc and flexspi. The
imx8mimage will calculate the offset inside the flash.bin automatically
according to different IVT offset. The ROMAPI driver also works
correspondingly.
After using binman, the u-boot.itb offset inside the flash.bin has to
be manually set in this DTS node. To follow the original design, this
offset should be different. That's why I asked to update this dts node
for flexspi.


This does imply that there are currently no users that boot from flexspi 
in upstream U-Boot, because such users would have to manually modify 
both arch/arm/dts/imx8m?-u-boot.dtsi and board/*/imximage.cfg to 
generate suitable flash.bin which can be started from FlexSPI.


Also, git grep confirms that there are no users:

u-boot$ git grep BOOT_FROM.*fspi
doc/imx/mkimage/imx8image.txt:BOOT_FROM 
[sd|emmc_fastboot|fspi|nand_4k|nand_8k|nand_16k] [sector_size]



If you change the ROM API driver, that will break our design. You can
try to overwrite spl_romapi_get_uboot_base for your board only.


Since there are no users which boot from flexspi upstream, this design 
can still be fixed such that it does not require different flash.bin for 
different boot media, but rather one flash.bin works on all boot media. 
I think that is much better.


[...]


Re: [ANN] U-Boot v2022.04-rc5 released

2022-03-28 Thread Tom Rini
On Mon, Mar 28, 2022 at 04:29:41PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Mon, Mar 28, 2022 at 4:22 PM Tom Rini  wrote:
> >
> > On Mon, Mar 28, 2022 at 04:19:49PM +0200, Michael Nazzareno Trimarchi wrote:
> > > Hi Tom
> > >
> > > On Mon, Mar 28, 2022 at 4:17 PM Tom Rini  wrote:
> > > >
> > > > Hey all,
> > > >
> > > > It's release day and so here's v2022.04-rc5.  The release itself is next
> > > > week and the next branch is open.  I've merged all regression and
> > > > critical fixes I know of so if something else is missing please speak up
> > > > as soon as possible.
> > > >
> > > > In terms of a changelog,
> > > > git log --merges v2022.04-rc4..v2022.04-rc5
> > > > contains what I've pulled but as always, better PR messages and tags
> > > > will provide better results here.
> > > >
> > > > The next release will be the final one in this cycle, April 4th 2022.
> > > > Thanks all!
> > >
> > > We have the SystemMaster board sent some months ago. I would like to
> > > understand when someone can pick them up
> >
> > Patchwork or lore link please?
> 
> https://patchwork.ozlabs.org/project/uboot/list/?series==ariel
> 
> We sent a recent update adding more there. Hope this link help

Stefano?

-- 
Tom


signature.asc
Description: PGP signature


Re: [ANN] U-Boot v2022.04-rc5 released

2022-03-28 Thread Michael Nazzareno Trimarchi
Hi

On Mon, Mar 28, 2022 at 4:22 PM Tom Rini  wrote:
>
> On Mon, Mar 28, 2022 at 04:19:49PM +0200, Michael Nazzareno Trimarchi wrote:
> > Hi Tom
> >
> > On Mon, Mar 28, 2022 at 4:17 PM Tom Rini  wrote:
> > >
> > > Hey all,
> > >
> > > It's release day and so here's v2022.04-rc5.  The release itself is next
> > > week and the next branch is open.  I've merged all regression and
> > > critical fixes I know of so if something else is missing please speak up
> > > as soon as possible.
> > >
> > > In terms of a changelog,
> > > git log --merges v2022.04-rc4..v2022.04-rc5
> > > contains what I've pulled but as always, better PR messages and tags
> > > will provide better results here.
> > >
> > > The next release will be the final one in this cycle, April 4th 2022.
> > > Thanks all!
> >
> > We have the SystemMaster board sent some months ago. I would like to
> > understand when someone can pick them up
>
> Patchwork or lore link please?
>
> --
> Tom

https://patchwork.ozlabs.org/project/uboot/list/?series==ariel

We sent a recent update adding more there. Hope this link help

Michael



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com


Re: [PATCH v3 10/12] arm: dts: rockchip: sync rk3288 DT boards from Linux

2022-03-28 Thread Kever Yang



On 2022/3/4 07:52, Johan Jonker wrote:

Sync rk3288 DT boards that have support both in
Linux 5.17 as in U-boot.

Signed-off-by: Johan Jonker 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---

Change V3:
   update
   change reg size
   delete more files

Changed V2:
   update
   change led labels
---
  arch/arm/dts/rk3288-firefly-u-boot.dtsi |   4 +-
  arch/arm/dts/rk3288-firefly.dts |  17 +-
  arch/arm/dts/rk3288-firefly.dtsi| 161 +--
  arch/arm/dts/rk3288-miqi-u-boot.dtsi|   2 +-
  arch/arm/dts/rk3288-miqi.dts| 431 ++-
  arch/arm/dts/rk3288-miqi.dtsi   | 418 --
  arch/arm/dts/rk3288-phycore-rdk.dts | 109 +++--
  arch/arm/dts/rk3288-phycore-som.dtsi| 111 +
  arch/arm/dts/rk3288-popmetal.dts| 505 +-
  arch/arm/dts/rk3288-popmetal.dtsi   | 545 
  arch/arm/dts/rk3288-rock2-som.dtsi  |  91 ++--
  arch/arm/dts/rk3288-rock2-square.dts| 215 +++---
  arch/arm/dts/rk3288-tinker-s.dts|   9 +-
  arch/arm/dts/rk3288-tinker.dts  |  30 +-
  arch/arm/dts/rk3288-tinker.dtsi | 405 +-
  15 files changed, 1554 insertions(+), 1499 deletions(-)
  delete mode 100644 arch/arm/dts/rk3288-miqi.dtsi
  delete mode 100644 arch/arm/dts/rk3288-popmetal.dtsi

diff --git a/arch/arm/dts/rk3288-firefly-u-boot.dtsi 
b/arch/arm/dts/rk3288-firefly-u-boot.dtsi
index cc84d7c4..c43d3281 100644
--- a/arch/arm/dts/rk3288-firefly-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-firefly-u-boot.dtsi
@@ -14,11 +14,11 @@
leds {
u-boot,dm-pre-reloc;
  
-		work {

+   work_led: led-0 {
u-boot,dm-pre-reloc;
};
  
-		power {

+   power_led: led-1 {
u-boot,dm-pre-reloc;
};
};
diff --git a/arch/arm/dts/rk3288-firefly.dts b/arch/arm/dts/rk3288-firefly.dts
index 72982efd..313459da 100644
--- a/arch/arm/dts/rk3288-firefly.dts
+++ b/arch/arm/dts/rk3288-firefly.dts
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
  /*
   * Copyright (c) 2014, 2015 FUKAUMI Naoki 
   */
@@ -9,31 +9,22 @@
  / {
model = "Firefly-RK3288";
compatible = "firefly,firefly-rk3288", "rockchip,rk3288";
-
-   chosen {
-   stdout-path = 
-   };
  };
  
   {

-   gpios = < 0 GPIO_ACTIVE_LOW>;
+   gpios = < RK_PA0 GPIO_ACTIVE_LOW>;
  };
  
   {

act8846 {
pmic_vsel: pmic-vsel {
-   rockchip,pins = <7 14 RK_FUNC_GPIO _output_low>;
+   rockchip,pins = <7 RK_PB6 RK_FUNC_GPIO 
_output_low>;
};
};
  
  	ir {

ir_int: ir-int {
-   rockchip,pins = <7 0 RK_FUNC_GPIO _pull_up>;
-   };
-   };
-   usb_host {
-   host_vbus_drv: host-vbus-drv {
-   rockchip,pins = <0 14 RK_FUNC_GPIO _pull_none>;
+   rockchip,pins = <7 RK_PA0 RK_FUNC_GPIO _pull_up>;
};
};
  };
diff --git a/arch/arm/dts/rk3288-firefly.dtsi b/arch/arm/dts/rk3288-firefly.dtsi
index 1117d391..96d768ac 100644
--- a/arch/arm/dts/rk3288-firefly.dtsi
+++ b/arch/arm/dts/rk3288-firefly.dtsi
@@ -1,15 +1,38 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
  /*
   * Copyright (c) 2014, 2015 FUKAUMI Naoki 
   */
  
+#include 

  #include "rk3288.dtsi"
  
  / {

-   memory {
+   memory@0 {
+   device_type = "memory";
reg = <0 0x8000>;
};
  
+	adc-keys {

+   compatible = "adc-keys";
+   io-channels = < 1>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+
+   button-recovery {
+   label = "Recovery";
+   linux,code = ;
+   press-threshold-microvolt = <0>;
+   };
+   };
+
+   dovdd_1v8: dovdd-1v8-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "dovdd_1v8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <_dvp>;
+   };
+
ext_gmac: external-gmac-clock {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -26,11 +49,11 @@
keys: gpio-keys {
compatible = "gpio-keys";
  
-		button@0 {

-   gpio-key,wakeup = <1>;
-   gpios = < 5 GPIO_ACTIVE_LOW>;
+   power {
+   wakeup-source;
+   gpios = < RK_PA5 GPIO_ACTIVE_LOW>;
label = "GPIO Power";
-   linux,code = <116>;
+   linux,code = ;
pinctrl-names = 

Re: [ANN] U-Boot v2022.04-rc5 released

2022-03-28 Thread Tom Rini
On Mon, Mar 28, 2022 at 04:19:49PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi Tom
> 
> On Mon, Mar 28, 2022 at 4:17 PM Tom Rini  wrote:
> >
> > Hey all,
> >
> > It's release day and so here's v2022.04-rc5.  The release itself is next
> > week and the next branch is open.  I've merged all regression and
> > critical fixes I know of so if something else is missing please speak up
> > as soon as possible.
> >
> > In terms of a changelog,
> > git log --merges v2022.04-rc4..v2022.04-rc5
> > contains what I've pulled but as always, better PR messages and tags
> > will provide better results here.
> >
> > The next release will be the final one in this cycle, April 4th 2022.
> > Thanks all!
> 
> We have the SystemMaster board sent some months ago. I would like to
> understand when someone can pick them up

Patchwork or lore link please?

-- 
Tom


signature.asc
Description: PGP signature


Re: [ANN] U-Boot v2022.04-rc5 released

2022-03-28 Thread Michael Nazzareno Trimarchi
Hi Tom

On Mon, Mar 28, 2022 at 4:17 PM Tom Rini  wrote:
>
> Hey all,
>
> It's release day and so here's v2022.04-rc5.  The release itself is next
> week and the next branch is open.  I've merged all regression and
> critical fixes I know of so if something else is missing please speak up
> as soon as possible.
>
> In terms of a changelog,
> git log --merges v2022.04-rc4..v2022.04-rc5
> contains what I've pulled but as always, better PR messages and tags
> will provide better results here.
>
> The next release will be the final one in this cycle, April 4th 2022.
> Thanks all!
>
> --
> Tom

We have the SystemMaster board sent some months ago. I would like to
understand when someone can pick them up

Michael



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com


[ANN] U-Boot v2022.04-rc5 released

2022-03-28 Thread Tom Rini
Hey all,

It's release day and so here's v2022.04-rc5.  The release itself is next
week and the next branch is open.  I've merged all regression and
critical fixes I know of so if something else is missing please speak up
as soon as possible.

In terms of a changelog, 
git log --merges v2022.04-rc4..v2022.04-rc5
contains what I've pulled but as always, better PR messages and tags
will provide better results here.

The next release will be the final one in this cycle, April 4th 2022.
Thanks all!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] Fix URLs to old freescale git repos

2022-03-28 Thread Tom Rini
On Fri, Mar 25, 2022 at 10:51:46AM +0100, Pali Rohár wrote:

> Freescale git repos are now on source.codeaurora.org.
> 
> Signed-off-by: Pali Rohár 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] Makefile: add drivers/video/u_boot_logo.S to clean

2022-03-28 Thread Tom Rini
On Sat, Mar 19, 2022 at 01:33:25PM +0100, Heinrich Schuchardt wrote:

> make sandbox_defconfig
> make mrproper
> make tests
> 
> fails with
> 
> ../drivers/video/u_boot_logo.S: Assembler messages:
> ../drivers/video/u_boot_logo.S:5: Error: file not found: 
> drivers/video/u_boot_logo.bmp
> 
> We have to delete the generated file.
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v4] mtd: gpmi: fix the bch setting backward compatible issue

2022-03-28 Thread Tom Rini
On Fri, Mar 25, 2022 at 08:36:38AM -0500, Han Xu wrote:

> Previous u-boot code changed the default bch setting behavior and caused
> backward compatible issue. This fix choose the legacy bch geometry back
> again as the default option. If the minimum ecc strength that NAND chips
> required need to be chosen, it can be enabled by either adding DT flag
> "fsl,use-minimum-ecc" or CONFIG_NAND_MXS_USE_MINIMUM_ECC in configs. The
> unused flag "fsl,legacy-bch-geometry" get removed.
> 
> Fixes: 51cdf83eea (mtd: gpmi: provide the option to use legacy bch geometry)
> Fixes: 616f03daba (mtd: gpmi: change the BCH layout setting for large oob 
> NAND)
> Tested-by: Tim Harvey 
> Tested-by: Sean Nyekjaer 
> Signed-off-by: Han Xu 
> Reviewed-by: Miquel Raynal 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] arm: apple: Fix mem layout

2022-03-28 Thread Tom Rini
On Mon, Mar 21, 2022 at 10:41:18PM +0100, Mark Kettenis wrote:

> The current approach for setting the environment variables that
> describe the memory layout runs the risk of overlapping with
> reserved memory regions. Use the lmb code to derive the addresses
> for these variables instead.
> 
> Signed-off-by: Mark Kettenis 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] arm: apple: Increase RTKit timeout

2022-03-28 Thread Tom Rini
On Mon, Mar 21, 2022 at 10:36:05PM +0100, Mark Kettenis wrote:

> From: Hector Martin 
> 
> The firmware on larger NVMe drives needs more than 100ms to come up.
> Change the timeout to 1s.
> 
> Signed-off-by: Hector Martin 
> Signed-off-by: Mark Kettenis 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2] boot: image: fixup zstd decompression buffer initialization typo

2022-03-28 Thread Tom Rini
On Wed, Mar 16, 2022 at 03:35:36PM -0400, Jérôme Carretero wrote:

> The code was mistakenly initializing the input buffer twice.
> 
> Tested to be working on BeagleBone by adjusting CONFIG_SYS_BOOTM_LEN to
> 64MiB (probably works with less) and preparing uImage with:
> 
>  cat arch/arm/boot/Image \
>   | zstd --ultra -22 --zstd=windowLog=22 \
>   > linux.bin.zst
> 
>  mkimage -A arm -T kernel uImage -C zstd -d linux.bin.zst \
>   -a 0x80008000 -e 0x80008000
> 
> Without the windowLog restriction, bootm fails with a zstd decompression
> error 7 (window too large), which I haven't troubleshooted.
> 
> There should be a bit more documentation on the feature...
> 
> Reviewed-by: Simon Glass 
> Fixes: 458b30af66c image: Update image_decomp() to avoid ifdefs

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL

2022-03-28 Thread Tom Rini
On Mon, Mar 28, 2022 at 12:35:09AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 30 Jul 2021 at 16:08, Tom Rini  wrote:
> >
> > On Fri, Jul 30, 2021 at 03:48:15PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 30 Jul 2021 at 15:33, Tom Rini  wrote:
> > > >
> > > > On Fri, Jul 30, 2021 at 01:02:18PM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 29 Jul 2021 at 07:52, Tom Rini  wrote:
> > > > > >
> > > > > > On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Wed, 28 Jul 2021 at 17:55, Tom Rini  wrote:
> > > > > > > >
> > > > > > > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt 
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 7/27/21 12:07 AM, Tom Rini wrote:
> > > > > > > > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote:
> > > > > > > > > >
> > > > > > > > > > > This feature should never have been made available when 
> > > > > > > > > > > driver model
> > > > > > > > > > > or devicetree are disabled. Add these as conditions, so 
> > > > > > > > > > > that we don't
> > > > > > > > > > > create even more barriers to migration.
> > > > > > > > > > >
> > > > > > > > > > > Add a note about the substantial size increment 
> > > > > > > > > > > associated with this
> > > > > > > > > > > option.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Simon Glass 
> > > > > > > > > > > ---
> > > > > > > > > > >
> > > > > > > > > > > Changes in v2:
> > > > > > > > > > > - Split out new patch to make EFI_LOADER depend on DM and 
> > > > > > > > > > > OF_CONTROL
> > > > > > > > > > > - Note the approximate size of this feature in the help
> > > > > > > > > > >
> > > > > > > > > > >   lib/efi_loader/Kconfig | 4 +++-
> > > > > > > > > > >   1 file changed, 3 insertions(+), 1 deletion(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig 
> > > > > > > > > > > b/lib/efi_loader/Kconfig
> > > > > > > > > > > index 6242caceb7f..466abfed300 100644
> > > > > > > > > > > --- a/lib/efi_loader/Kconfig
> > > > > > > > > > > +++ b/lib/efi_loader/Kconfig
> > > > > > > > > > > @@ -1,6 +1,6 @@
> > > > > > > > > > >   config EFI_LOADER
> > > > > > > > > > >   bool "Support running UEFI applications"
> > > > > > > > > > > - depends on OF_LIBFDT && ( \
> > > > > > > > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \
> > > > > > > > >
> > > > > > > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't 
> > > > > > > > > we get rid
> > > > > > > > > of this symbol?
> > > > > > > >
> > > > > > > > No, but I did send out a message about that today as we're very 
> > > > > > > > close.
> > > > > > > > Much closer than I had expected us to be.
> > > > > > >
> > > > > > > Note we will still have SPL_DM, I think.
> > > > > >
> > > > > > Right.
> > > > > >
> > > > > > > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL 
> > > > > > > > > and not DM?
> > > > > > > >
> > > > > > > > Yes, a few.  It's vexpress_aemv8a_semi, warp (fixed by
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/
> > > > > > > > so false positive), cm_t335, devkit8000, armadillo-800eva, 
> > > > > > > > kzm9g and sniper.
> > > > > > > >
> > > > > > > > > Why are these separate symbols? Isn't this symbol to be 
> > > > > > > > > eliminated, too?
> > > > > > > >
> > > > > > > > Simon?
> > > > > > >
> > > > > > > If we do eliminate DM it will be in a separate series. Like Tom I 
> > > > > > > am
> > > > > > > pleasantly surprised at how close we are.
> > > > > > >
> > > > > > > But please let's consider patches on their merits. It is fine to 
> > > > > > > reply
> > > > > > > with a wishlist but even better to reply with a follow-up patch.
> > > > > >
> > > > > > OK.  So, build-wise, EFI_LOADER does not require OF_CONTROL.
> > > > >
> > > > > I strongly believe it should (and it should have 5 years ago too). New
> > > > > features should not be built on pre-migration stuff.
> > > >
> > > > Well, what legacy interfaces is it using?  That's something to figure
> > > > out and address as needed.
> > >
> > > It was built on non-DM and I believe it still has code for non-DM
> > > (e.g. look for DM_MMC). Without DM, OF_CONTROL has no purpose IMO.
> > >
> > > Perhaps Heinrich has cleaned a lot of that old cruft out now?
> >
> > Now that DM_MMC and DM_VIDEO are mandatory, there is some cruft that can
> > be removed, both there and probably tree-wide.  But that's not the same
> > as OF_CONTROL.  Not all DM_xxx requires OF_CONTROL support.
> >
> > > > > > > Somewhat related, I think we need to create a separate symbol 
> > > > > > > which
> > > > > > > means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing.
> > > > > > >
> > > > > > > Also I think we should push of-platdata, since otherwise we're 
> > > > > > > going
> > > > > > > to hit the same problem of migrating SPL boards to DM 

Re: [PATCH] ahci: add PCI bindings for Marvell 88SE6121/45 SATA controllers

2022-03-28 Thread Pali Rohár
On Monday 28 March 2022 15:49:08 Hajo Noerenberg wrote:
> Add AHCI PCI bindings for Marvell 88SE6121/45 SATA controllers.
> 
> The 88SE6121 controller is used, for example, in the Seagate Blackarmor 
> NAS440 or the Iomega ix4-200d NAS.
> 
> As Pali Rohár explained [1], these controllers do not match the standard AHCI 
> class code and therefore require an explizit PCI binding. The Linux kernel 
> also uses this approach [2].
> 
> [1] https://lists.denx.de/pipermail/u-boot/2022-March/479197.html
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/ahci.c?h=v5.17#n557
> 
> 
> Signed-off-by: Hajo Noerenberg 

Reviewed-by: Pali Rohár 

> ---
>  drivers/ata/ahci-pci.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/ata/ahci-pci.c b/drivers/ata/ahci-pci.c
> index b1d231e0f9..797e0d570e 100644
> --- a/drivers/ata/ahci-pci.c
> +++ b/drivers/ata/ahci-pci.c
> @@ -38,6 +38,8 @@ U_BOOT_DRIVER(ahci_pci) = {
>  static struct pci_device_id ahci_pci_supported[] = {
>   { PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, ~0) },
>   { PCI_DEVICE(0x1b21, 0x0611) },
> + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6121) },
> + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6145) },
>   {},
>  };
>  
> -- 
> 2.20.1
> 


Re: [PATCH v2] imx8m: Use a sane SYS_MALLOC_F_LEN default

2022-03-28 Thread Fabio Estevam
Hi Tom,

On Wed, Mar 23, 2022 at 1:27 PM Tom Rini  wrote:

> Well, this will be for -next, and we can get some more people on the
> patch list, and this seems to be an area where everyone is either:
> - Kicking the value up a bit for themselves
> - Having hard to figure out problems booting the platform because it's
>   too small a value until they see someone else picked a larger value.
>
> So lets raise these a bit and get some acks, please.

Sure, I sent a v3 as requested.


Re: [PATCH v11 01/14] crypto/fsl: Add support for CAAM Job ring driver model

2022-03-28 Thread Michael Nazzareno Trimarchi
Hi
On Mon, Mar 28, 2022 at 10:36 AM Gaurav Jain  wrote:
>
> Hello Stefano
>
> Michael Trimarchi has shared the patch to fix imx6dl_mamoj spl size error.
> I have also shared the v11 for caam driver model after adding the final 
> comments .
> Can you help to apply the series?
>

My patch is already reviewed by Fabio, Gaurav sorry for the
inconvenience and delay

Michael

> Regards
> Gaurav Jain
>
> > -Original Message-
> > From: Gaurav Jain 
> > Sent: Thursday, March 24, 2022 11:50 AM
> > To: u-boot@lists.denx.de; Stefano Babic 
> > Cc: Fabio Estevam ; Peng Fan ;
> > Simon Glass ; Michael Walle ;
> > Priyanka Jain ; Ye Li ; Horia
> > Geanta ; Ji Luo ; Franck
> > Lenormand ; Silvano Di Ninno
> > ; Sahil Malhotra ;
> > Pankaj Gupta ; Varun Sethi ;
> > dl-uboot-imx ; Shengzhou Liu
> > ; Mingkai Hu ; Rajesh
> > Bhagat ; Meenakshi Aggarwal
> > ; Wasim Khan ;
> > Alison Wang ; Pramod Kumar
> > ; Andy Tang ; Adrian
> > Alonso ; Vladimir Oltean ;
> > ZHIZHIKIN Andrey ; Michael
> > Trimarchi ; Gaurav Jain
> > 
> > Subject: [PATCH v11 01/14] crypto/fsl: Add support for CAAM Job ring driver
> > model
> >
> > added device tree support for job ring driver.
> > sec is initialized based on job ring information processed from device tree.
> >
> > Signed-off-by: Gaurav Jain 
> > Reviewed-by: Ye Li 
> > Reviewed-by: Simon Glass 
> > ---
> >  drivers/crypto/fsl/Kconfig |   1 +
> >  drivers/crypto/fsl/jr.c| 323 -
> >  drivers/crypto/fsl/jr.h|  31 +++-
> >  3 files changed, 241 insertions(+), 114 deletions(-)
> >
> > diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig index
> > 94ff540111..231eb00b5f 100644
> > --- a/drivers/crypto/fsl/Kconfig
> > +++ b/drivers/crypto/fsl/Kconfig
> > @@ -2,6 +2,7 @@ config FSL_CAAM
> >   bool "Freescale Crypto Driver Support"
> >   select SHA_HW_ACCEL
> >   # hw_sha1() under drivers/crypto, and needed with SHA_HW_ACCEL
> > + select MISC if DM
> >   imply SPL_CRYPTO if (ARM && SPL)
> >   imply CMD_HASH
> >   help
> > diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c index
> > 22b649219e..8103987425 100644
> > --- a/drivers/crypto/fsl/jr.c
> > +++ b/drivers/crypto/fsl/jr.c
> > @@ -1,7 +1,7 @@
> >  // SPDX-License-Identifier: GPL-2.0+
> >  /*
> >   * Copyright 2008-2014 Freescale Semiconductor, Inc.
> > - * Copyright 2018 NXP
> > + * Copyright 2018, 2021 NXP
> >   *
> >   * Based on CAAM driver in drivers/crypto/caam in Linux
> >   */
> > @@ -11,7 +11,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include "fsl_sec.h"
> >  #include "jr.h"
> >  #include "jobdesc.h"
> >  #include "desc_constr.h"
> > @@ -21,7 +20,10 @@
> >  #include 
> >  #include 
> >  #endif
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >
> >  #define CIRC_CNT(head, tail, size)   (((head) - (tail)) & (size - 1))
> > @@ -35,20 +37,29 @@ uint32_t
> > sec_offset[CONFIG_SYS_FSL_MAX_NUM_OF_SEC] = {  #endif  };
> >
> > +#if CONFIG_IS_ENABLED(DM)
> > +struct udevice *caam_dev;
> > +#else
> >  #define SEC_ADDR(idx)\
> >   (ulong)((CONFIG_SYS_FSL_SEC_ADDR + sec_offset[idx]))
> >
> >  #define SEC_JR0_ADDR(idx)\
> >   (ulong)(SEC_ADDR(idx) + \
> >(CONFIG_SYS_FSL_JR0_OFFSET - CONFIG_SYS_FSL_SEC_OFFSET))
> > +struct caam_regs caam_st;
> > +#endif
> >
> > -struct jobring jr0[CONFIG_SYS_FSL_MAX_NUM_OF_SEC];
> > +static inline u32 jr_start_reg(u8 jrid) {
> > + return (1 << jrid);
> > +}
> >
> > -static inline void start_jr0(uint8_t sec_idx)
> > +static inline void start_jr(struct caam_regs *caam)
> >  {
> > - ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
> > + ccsr_sec_t *sec = caam->sec;
> >   u32 ctpr_ms = sec_in32(>ctpr_ms);
> >   u32 scfgr = sec_in32(>scfgr);
> > + u32 jrstart = jr_start_reg(caam->jrid);
> >
> >   if (ctpr_ms & SEC_CTPR_MS_VIRT_EN_INCL) {
> >   /* VIRT_EN_INCL = 1 & VIRT_EN_POR = 1 or @@ -56,23
> > +67,16 @@ static inline void start_jr0(uint8_t sec_idx)
> >*/
> >   if ((ctpr_ms & SEC_CTPR_MS_VIRT_EN_POR) ||
> >   (scfgr & SEC_SCFGR_VIRT_EN))
> > - sec_out32(>jrstartr, CONFIG_JRSTARTR_JR0);
> > + sec_out32(>jrstartr, jrstart);
> >   } else {
> >   /* VIRT_EN_INCL = 0 && VIRT_EN_POR_VALUE = 1 */
> >   if (ctpr_ms & SEC_CTPR_MS_VIRT_EN_POR)
> > - sec_out32(>jrstartr, CONFIG_JRSTARTR_JR0);
> > + sec_out32(>jrstartr, jrstart);
> >   }
> >  }
> >
> > -static inline void jr_reset_liodn(uint8_t sec_idx)
> > +static inline void jr_disable_irq(struct jr_regs *regs)
> >  {
> > - ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
> > - sec_out32(>jrliodnr[0].ls, 0);
> > -}
> > -
> > -static inline void jr_disable_irq(uint8_t sec_idx) -{
> > - struct jr_regs *regs = (struct jr_regs *)SEC_JR0_ADDR(sec_idx);
> >   uint32_t jrcfg = sec_in32(>jrcfg1);
> >
> >   

[PATCH] ahci: add PCI bindings for Marvell 88SE6121/45 SATA controllers

2022-03-28 Thread Hajo Noerenberg
Add AHCI PCI bindings for Marvell 88SE6121/45 SATA controllers.

The 88SE6121 controller is used, for example, in the Seagate Blackarmor NAS440 
or the Iomega ix4-200d NAS.

As Pali Rohár explained [1], these controllers do not match the standard AHCI 
class code and therefore require an explizit PCI binding. The Linux kernel also 
uses this approach [2].

[1] https://lists.denx.de/pipermail/u-boot/2022-March/479197.html
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/ahci.c?h=v5.17#n557


Signed-off-by: Hajo Noerenberg 
---
 drivers/ata/ahci-pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/ata/ahci-pci.c b/drivers/ata/ahci-pci.c
index b1d231e0f9..797e0d570e 100644
--- a/drivers/ata/ahci-pci.c
+++ b/drivers/ata/ahci-pci.c
@@ -38,6 +38,8 @@ U_BOOT_DRIVER(ahci_pci) = {
 static struct pci_device_id ahci_pci_supported[] = {
{ PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, ~0) },
{ PCI_DEVICE(0x1b21, 0x0611) },
+   { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6121) },
+   { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6145) },
{},
 };
 
-- 
2.20.1



Re: [PATCH v2 1/3] rng: add OP-TEE based Random Number Generator

2022-03-28 Thread Heinrich Schuchardt

On 3/28/22 15:11, Patrick Delaunay wrote:

Add driver for OP-TEE based Random Number Generator on ARM SoCs
where hardware entropy sources are not accessible to normal world
and the RNG service is provided by a HWRNG Trusted Application (TA).

This driver is based on the linux driver: char/hw_random/optee-rng.c

Series_changes: 2
- change SPDX-License-Identifier, becausee "GPL-2.0+” is obsolete
   reference: https://spdx.dev/ids/
- update Kconfig long help message as proposed by Heinrich
- replace memset(.., 0, sizeof(..)) by struct initialisation (= {0};)
- add function descriptions

Signed-off-by: Patrick Delaunay 
---

(no changes since v1)

  MAINTAINERS |   1 +
  drivers/rng/Kconfig |   9 ++
  drivers/rng/Makefile|   1 +
  drivers/rng/optee_rng.c | 180 
  4 files changed, 191 insertions(+)
  create mode 100644 drivers/rng/optee_rng.c

diff --git a/MAINTAINERS b/MAINTAINERS
index f25ca7cd00..3356c65dd0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -481,6 +481,7 @@ F:  drivers/power/regulator/stpmic1.c
  F:drivers/ram/stm32mp1/
  F:drivers/remoteproc/stm32_copro.c
  F:drivers/reset/stm32-reset.c
+F: drivers/rng/optee_rng.c
  F:drivers/rng/stm32mp1_rng.c
  F:drivers/rtc/stm32_rtc.c
  F:drivers/serial/serial_stm32.*
diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
index b1c5ab93d1..c10f7d345b 100644
--- a/drivers/rng/Kconfig
+++ b/drivers/rng/Kconfig
@@ -31,6 +31,15 @@ config RNG_MSM
  This driver provides support for the Random Number
  Generator hardware found on Qualcomm SoCs.

+config RNG_OPTEE
+   bool "OP-TEE based Random Number Generator support"
+   depends on DM_RNG && OPTEE
+   help
+ This driver provides support for the OP-TEE based Random Number
+ Generator on ARM SoCs where hardware entropy sources are not
+ accessible to normal world but reserved and used by the OP-TEE
+ to avoid the weakness of a software PRNG.
+
  config RNG_STM32MP1
bool "Enable random number generator for STM32MP1"
depends on ARCH_STM32MP
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
index 39f7ee3f03..435b3b965a 100644
--- a/drivers/rng/Makefile
+++ b/drivers/rng/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_DM_RNG) += rng-uclass.o
  obj-$(CONFIG_RNG_MESON) += meson-rng.o
  obj-$(CONFIG_RNG_SANDBOX) += sandbox_rng.o
  obj-$(CONFIG_RNG_MSM) += msm_rng.o
+obj-$(CONFIG_RNG_OPTEE) += optee_rng.o
  obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
  obj-$(CONFIG_RNG_ROCKCHIP) += rockchip_rng.o
  obj-$(CONFIG_RNG_IPROC200) += iproc_rng200.o
diff --git a/drivers/rng/optee_rng.c b/drivers/rng/optee_rng.c
new file mode 100644
index 00..7be428ac91
--- /dev/null
+++ b/drivers/rng/optee_rng.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
+/*
+ * Copyright (C) 2022, STMicroelectronics - All Rights Reserved
+ */
+#define LOG_CATEGORY UCLASS_RNG
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TEE_ERROR_HEALTH_TEST_FAIL 0x0001
+
+/*
+ * TA_CMD_GET_ENTROPY - Get Entropy from RNG
+ *
+ * param[0] (inout memref) - Entropy buffer memory reference
+ * param[1] unused
+ * param[2] unused
+ * param[3] unused
+ *
+ * Result:
+ * TEE_SUCCESS - Invoke command success
+ * TEE_ERROR_BAD_PARAMETERS - Incorrect input param
+ * TEE_ERROR_NOT_SUPPORTED - Requested entropy size greater than size of pool
+ * TEE_ERROR_HEALTH_TEST_FAIL - Continuous health testing failed
+ */
+#define TA_CMD_GET_ENTROPY 0x0
+
+#define MAX_ENTROPY_REQ_SZ SZ_4K
+
+#define TA_HWRNG_UUID { 0xab7a617c, 0xb8e7, 0x4d8f, \
+   { 0x83, 0x01, 0xd0, 0x9b, 0x61, 0x03, 0x6b, 0x64 } }
+
+/**
+ * struct optee_rng_priv - OP-TEE Random Number Generator private data
+ * @session_id:RNG TA session identifier.
+ */
+struct optee_rng_priv {
+   u32 session_id;
+};
+
+/**
+ * get_optee_rng_data() - read RNG data from OP-TEE TA
+ *
+ * @dev:   device
+ * @entropy_shm_pool:  shared memory pool used for TEE message
+ * @buf:   buffer to receive data
+ * @size:  size of buffer, limited by entropy_shm_pool size
+ * Return: 0 if ok
+ */
+static int get_optee_rng_data(struct udevice *dev,
+ struct tee_shm *entropy_shm_pool,
+ void *buf, size_t *size)
+{
+   struct optee_rng_priv *priv = dev_get_priv(dev);
+   int ret = 0;
+   struct tee_invoke_arg arg = {0};
+   struct tee_param param = {0};
+
+   /* Invoke TA_CMD_GET_ENTROPY function of Trusted App */
+   arg.func = TA_CMD_GET_ENTROPY;
+   arg.session = priv->session_id;
+
+   /* Fill invoke cmd params */
+   param.attr = TEE_PARAM_ATTR_TYPE_MEMREF_INOUT;
+   param.u.memref.shm = entropy_shm_pool;
+   param.u.memref.size = *size;
+
+   ret = tee_invoke_func(dev->parent, , 1, );
+   if 

[PATCH v2 3/3] configs: add support of OPTEE RNG in stm32mp15 defconfig

2022-03-28 Thread Patrick Delaunay
When the RNG device is secured with OP-TEE, it is only accessible with
the HWRNG TA, the CONFIG_RNG_OPTEE is needed for STM32MP15 targets
with OP-TEE support.

The probe of this RNG driver fails when the TA is not available in OP-TEE
and the previous driver can be used, as CONFIG_RNG_STM32MP1 is activated
and when the associated node is activated in the device tree with:

 {
status = "okay";
};

When the RNG is used in OP-TEE, this node should be deactivated in
the Linux and U-Boot device tree.

Signed-off-by: Patrick Delaunay 
---

(no changes since v1)

 configs/stm32mp15_defconfig | 1 +
 configs/stm32mp15_trusted_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
index 2beb88e81d..3f48c677e6 100644
--- a/configs/stm32mp15_defconfig
+++ b/configs/stm32mp15_defconfig
@@ -119,6 +119,7 @@ CONFIG_DM_REGULATOR_STPMIC1=y
 CONFIG_REMOTEPROC_STM32_COPRO=y
 CONFIG_RESET_SCMI=y
 CONFIG_DM_RNG=y
+CONFIG_RNG_OPTEE=y
 CONFIG_RNG_STM32MP1=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_STM32=y
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index c6857d08ec..9f869aca36 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -120,6 +120,7 @@ CONFIG_DM_REGULATOR_STPMIC1=y
 CONFIG_REMOTEPROC_STM32_COPRO=y
 CONFIG_RESET_SCMI=y
 CONFIG_DM_RNG=y
+CONFIG_RNG_OPTEE=y
 CONFIG_RNG_STM32MP1=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_STM32=y
-- 
2.25.1



[PATCH v2 1/3] rng: add OP-TEE based Random Number Generator

2022-03-28 Thread Patrick Delaunay
Add driver for OP-TEE based Random Number Generator on ARM SoCs
where hardware entropy sources are not accessible to normal world
and the RNG service is provided by a HWRNG Trusted Application (TA).

This driver is based on the linux driver: char/hw_random/optee-rng.c

Series_changes: 2
- change SPDX-License-Identifier, becausee "GPL-2.0+” is obsolete
  reference: https://spdx.dev/ids/
- update Kconfig long help message as proposed by Heinrich
- replace memset(.., 0, sizeof(..)) by struct initialisation (= {0};)
- add function descriptions

Signed-off-by: Patrick Delaunay 
---

(no changes since v1)

 MAINTAINERS |   1 +
 drivers/rng/Kconfig |   9 ++
 drivers/rng/Makefile|   1 +
 drivers/rng/optee_rng.c | 180 
 4 files changed, 191 insertions(+)
 create mode 100644 drivers/rng/optee_rng.c

diff --git a/MAINTAINERS b/MAINTAINERS
index f25ca7cd00..3356c65dd0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -481,6 +481,7 @@ F:  drivers/power/regulator/stpmic1.c
 F: drivers/ram/stm32mp1/
 F: drivers/remoteproc/stm32_copro.c
 F: drivers/reset/stm32-reset.c
+F: drivers/rng/optee_rng.c
 F: drivers/rng/stm32mp1_rng.c
 F: drivers/rtc/stm32_rtc.c
 F: drivers/serial/serial_stm32.*
diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
index b1c5ab93d1..c10f7d345b 100644
--- a/drivers/rng/Kconfig
+++ b/drivers/rng/Kconfig
@@ -31,6 +31,15 @@ config RNG_MSM
  This driver provides support for the Random Number
  Generator hardware found on Qualcomm SoCs.
 
+config RNG_OPTEE
+   bool "OP-TEE based Random Number Generator support"
+   depends on DM_RNG && OPTEE
+   help
+ This driver provides support for the OP-TEE based Random Number
+ Generator on ARM SoCs where hardware entropy sources are not
+ accessible to normal world but reserved and used by the OP-TEE
+ to avoid the weakness of a software PRNG.
+
 config RNG_STM32MP1
bool "Enable random number generator for STM32MP1"
depends on ARCH_STM32MP
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
index 39f7ee3f03..435b3b965a 100644
--- a/drivers/rng/Makefile
+++ b/drivers/rng/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_DM_RNG) += rng-uclass.o
 obj-$(CONFIG_RNG_MESON) += meson-rng.o
 obj-$(CONFIG_RNG_SANDBOX) += sandbox_rng.o
 obj-$(CONFIG_RNG_MSM) += msm_rng.o
+obj-$(CONFIG_RNG_OPTEE) += optee_rng.o
 obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
 obj-$(CONFIG_RNG_ROCKCHIP) += rockchip_rng.o
 obj-$(CONFIG_RNG_IPROC200) += iproc_rng200.o
diff --git a/drivers/rng/optee_rng.c b/drivers/rng/optee_rng.c
new file mode 100644
index 00..7be428ac91
--- /dev/null
+++ b/drivers/rng/optee_rng.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
+/*
+ * Copyright (C) 2022, STMicroelectronics - All Rights Reserved
+ */
+#define LOG_CATEGORY UCLASS_RNG
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TEE_ERROR_HEALTH_TEST_FAIL 0x0001
+
+/*
+ * TA_CMD_GET_ENTROPY - Get Entropy from RNG
+ *
+ * param[0] (inout memref) - Entropy buffer memory reference
+ * param[1] unused
+ * param[2] unused
+ * param[3] unused
+ *
+ * Result:
+ * TEE_SUCCESS - Invoke command success
+ * TEE_ERROR_BAD_PARAMETERS - Incorrect input param
+ * TEE_ERROR_NOT_SUPPORTED - Requested entropy size greater than size of pool
+ * TEE_ERROR_HEALTH_TEST_FAIL - Continuous health testing failed
+ */
+#define TA_CMD_GET_ENTROPY 0x0
+
+#define MAX_ENTROPY_REQ_SZ SZ_4K
+
+#define TA_HWRNG_UUID { 0xab7a617c, 0xb8e7, 0x4d8f, \
+   { 0x83, 0x01, 0xd0, 0x9b, 0x61, 0x03, 0x6b, 0x64 } }
+
+/**
+ * struct optee_rng_priv - OP-TEE Random Number Generator private data
+ * @session_id:RNG TA session identifier.
+ */
+struct optee_rng_priv {
+   u32 session_id;
+};
+
+/**
+ * get_optee_rng_data() - read RNG data from OP-TEE TA
+ *
+ * @dev:   device
+ * @entropy_shm_pool:  shared memory pool used for TEE message
+ * @buf:   buffer to receive data
+ * @size:  size of buffer, limited by entropy_shm_pool size
+ * Return: 0 if ok
+ */
+static int get_optee_rng_data(struct udevice *dev,
+ struct tee_shm *entropy_shm_pool,
+ void *buf, size_t *size)
+{
+   struct optee_rng_priv *priv = dev_get_priv(dev);
+   int ret = 0;
+   struct tee_invoke_arg arg = {0};
+   struct tee_param param = {0};
+
+   /* Invoke TA_CMD_GET_ENTROPY function of Trusted App */
+   arg.func = TA_CMD_GET_ENTROPY;
+   arg.session = priv->session_id;
+
+   /* Fill invoke cmd params */
+   param.attr = TEE_PARAM_ATTR_TYPE_MEMREF_INOUT;
+   param.u.memref.shm = entropy_shm_pool;
+   param.u.memref.size = *size;
+
+   ret = tee_invoke_func(dev->parent, , 1, );
+   if (ret || arg.ret) {
+   if (!ret)
+  

[PATCH v2 2/3] tee: optee: bind rng optee driver

2022-03-28 Thread Patrick Delaunay
In U-Boot, the discovery of TA based on its UUID on the TEE bus is
not supported.

This patch only binds the driver associated to the new supported
OP-TEE TA = TA_HWRNG when this driver is enable.

Signed-off-by: Patrick Delaunay 
---

(no changes since v1)

 drivers/tee/optee/core.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index dad46aa388..a89d62aaf0 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -641,6 +642,8 @@ static int optee_probe(struct udevice *dev)
 {
struct optee_pdata *pdata = dev_get_plat(dev);
u32 sec_caps;
+   struct udevice *child;
+   int ret;
 
if (!is_optee_api(pdata->invoke_fn)) {
dev_err(dev, "OP-TEE api uid mismatch\n");
@@ -665,6 +668,16 @@ static int optee_probe(struct udevice *dev)
return -ENOENT;
}
 
+   /*
+* in U-Boot, the discovery of TA on the TEE bus is not supported:
+* only bind the drivers associated to the supported OP-TEE TA
+*/
+   if (IS_ENABLED(CONFIG_RNG_OPTEE)) {
+   ret = device_bind_driver(dev, "optee-rng", "optee-rng", );
+   if (ret)
+   return ret;
+   }
+
return 0;
 }
 
-- 
2.25.1



Re: [PATCH] mmc: rockchip_sdhci: Correct error checking

2022-03-28 Thread Kever Yang

Hi Haolin,

    Thanks for your patch.

On 2022/3/22 20:58, li.hao...@qq.com wrote:

From: Haolin Li 

A pointer can not be negative. Use macro IS_ERR_OR_NULL() for checking.

Signed-off-by: Haolin Li 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/mmc/rockchip_sdhci.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
index f3f9d83ba3..a46895299d 100644
--- a/drivers/mmc/rockchip_sdhci.c
+++ b/drivers/mmc/rockchip_sdhci.c
@@ -227,7 +227,7 @@ static int rk3399_emmc_get_phy(struct udevice *dev)
}
  
  	grf_base = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);

-   if (grf_base < 0) {
+   if (IS_ERR_OR_NULL(grf_base)) {
printf("%s Get syscon grf failed", __func__);
return -ENODEV;
}


Re: [PATCH v3 12/12] rockchip: fix boot_devices constants

2022-03-28 Thread Kever Yang



On 2022/3/4 07:52, Johan Jonker wrote:

The DT node name pattern in mmc-controller.yaml for mmc
is "^mmc(@.*)?$". The Rockchip mmc nodes have been synced
with Linux, so update the boot_devices constants as well.

Signed-off-by: Johan Jonker 
Reviewed-by: Simon Glass 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/mach-rockchip/rk3188/rk3188.c | 4 ++--
  arch/arm/mach-rockchip/rk322x/rk322x.c | 4 ++--
  arch/arm/mach-rockchip/rk3288/rk3288.c | 4 ++--
  arch/arm/mach-rockchip/rk3328/rk3328.c | 4 ++--
  arch/arm/mach-rockchip/rk3368/rk3368.c | 4 ++--
  5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c 
b/arch/arm/mach-rockchip/rk3188/rk3188.c
index 5a02914e..df8fa156 100644
--- a/arch/arm/mach-rockchip/rk3188/rk3188.c
+++ b/arch/arm/mach-rockchip/rk3188/rk3188.c
@@ -21,8 +21,8 @@
  #define GRF_BASE  0x20008000
  
  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {

-   [BROM_BOOTSOURCE_EMMC] = "/dwmmc@1021c000",
-   [BROM_BOOTSOURCE_SD] = "/dwmmc@10214000",
+   [BROM_BOOTSOURCE_EMMC] = "/mmc@1021c000",
+   [BROM_BOOTSOURCE_SD] = "/mmc@10214000",
  };
  
  #ifdef CONFIG_DEBUG_UART_BOARD_INIT

diff --git a/arch/arm/mach-rockchip/rk322x/rk322x.c 
b/arch/arm/mach-rockchip/rk322x/rk322x.c
index ad4ac62e..a304795f 100644
--- a/arch/arm/mach-rockchip/rk322x/rk322x.c
+++ b/arch/arm/mach-rockchip/rk322x/rk322x.c
@@ -9,8 +9,8 @@
  #include 
  
  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {

-   [BROM_BOOTSOURCE_EMMC] = "/dwmmc@3002",
-   [BROM_BOOTSOURCE_SD] = "/dwmmc@3000",
+   [BROM_BOOTSOURCE_EMMC] = "/mmc@3002",
+   [BROM_BOOTSOURCE_SD] = "/mmc@3000",
  };
  
  #ifdef CONFIG_DEBUG_UART_BOARD_INIT

diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c 
b/arch/arm/mach-rockchip/rk3288/rk3288.c
index bc20bc5a..3ad28875 100644
--- a/arch/arm/mach-rockchip/rk3288/rk3288.c
+++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
@@ -28,8 +28,8 @@ DECLARE_GLOBAL_DATA_PTR;
  #define GRF_BASE  0xff77
  
  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {

-   [BROM_BOOTSOURCE_EMMC] = "/dwmmc@ff0f",
-   [BROM_BOOTSOURCE_SD] = "/dwmmc@ff0c",
+   [BROM_BOOTSOURCE_EMMC] = "/mmc@ff0f",
+   [BROM_BOOTSOURCE_SD] = "/mmc@ff0c",
  };
  
  #ifdef CONFIG_SPL_BUILD

diff --git a/arch/arm/mach-rockchip/rk3328/rk3328.c 
b/arch/arm/mach-rockchip/rk3328/rk3328.c
index ec3336cb..de17b886 100644
--- a/arch/arm/mach-rockchip/rk3328/rk3328.c
+++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
@@ -21,8 +21,8 @@ DECLARE_GLOBAL_DATA_PTR;
  #define FW_DDR_CON_REG0xFF7C0040
  
  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {

-   [BROM_BOOTSOURCE_EMMC] = "/rksdmmc@ff52",
-   [BROM_BOOTSOURCE_SD] = "/rksdmmc@ff50",
+   [BROM_BOOTSOURCE_EMMC] = "/mmc@ff52",
+   [BROM_BOOTSOURCE_SD] = "/mmc@ff50",
  };
  
  static struct mm_region rk3328_mem_map[] = {

diff --git a/arch/arm/mach-rockchip/rk3368/rk3368.c 
b/arch/arm/mach-rockchip/rk3368/rk3368.c
index 9b7132d4..d0a6107e 100644
--- a/arch/arm/mach-rockchip/rk3368/rk3368.c
+++ b/arch/arm/mach-rockchip/rk3368/rk3368.c
@@ -58,8 +58,8 @@ static struct mm_region rk3368_mem_map[] = {
  struct mm_region *mem_map = rk3368_mem_map;
  
  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {

-   [BROM_BOOTSOURCE_EMMC] = "/dwmmc@ff0f",
-   [BROM_BOOTSOURCE_SD] = "/dwmmc@ff0c",
+   [BROM_BOOTSOURCE_EMMC] = "/mmc@ff0f",
+   [BROM_BOOTSOURCE_SD] = "/mmc@ff0c",
  };
  
  #ifdef CONFIG_ARCH_EARLY_INIT_R


Re: [PATCH v3 11/12] arm: dts: rockchip: sync rk3288-veyron DT from Linux

2022-03-28 Thread Kever Yang



On 2022/3/4 07:52, Johan Jonker wrote:

Sync rk3288-veyron DT from Linux version 5.17.

Signed-off-by: Johan Jonker 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---

Changed V3:
   update
   change reg size

Changed V2:
   update
   add label spi_flash veyron
---
  arch/arm/dts/rk3288-veyron-analog-audio.dtsi  |  99 +++
  .../dts/rk3288-veyron-broadcom-bluetooth.dtsi |  22 +
  arch/arm/dts/rk3288-veyron-chromebook.dtsi| 115 ++--
  arch/arm/dts/rk3288-veyron-edp.dtsi   | 141 
  arch/arm/dts/rk3288-veyron-jerry.dts  | 506 +++---
  arch/arm/dts/rk3288-veyron-mickey.dts | 343 +++---
  arch/arm/dts/rk3288-veyron-minnie.dts | 441 +++-
  arch/arm/dts/rk3288-veyron-sdmmc.dtsi |  89 +++
  arch/arm/dts/rk3288-veyron-speedy.dts | 303 ++--
  arch/arm/dts/rk3288-veyron.dtsi   | 645 ++
  10 files changed, 1799 insertions(+), 905 deletions(-)
  create mode 100644 arch/arm/dts/rk3288-veyron-analog-audio.dtsi
  create mode 100644 arch/arm/dts/rk3288-veyron-broadcom-bluetooth.dtsi
  create mode 100644 arch/arm/dts/rk3288-veyron-edp.dtsi
  create mode 100644 arch/arm/dts/rk3288-veyron-sdmmc.dtsi

diff --git a/arch/arm/dts/rk3288-veyron-analog-audio.dtsi 
b/arch/arm/dts/rk3288-veyron-analog-audio.dtsi
new file mode 100644
index ..51208d16
--- /dev/null
+++ b/arch/arm/dts/rk3288-veyron-analog-audio.dtsi
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Google Veyron (and derivatives) fragment for the  max98090 audio
+ * codec and analog headphone jack.
+ *
+ * Copyright 2016 Google, Inc
+ */
+
+/ {
+   sound {
+   compatible = "rockchip,rockchip-audio-max98090";
+   pinctrl-names = "default";
+   pinctrl-0 = <_det>, <_det>;
+   rockchip,model = "VEYRON-I2S";
+   rockchip,i2s-controller = <>;
+   rockchip,audio-codec = <>;
+   rockchip,hp-det-gpios = < RK_PA5 GPIO_ACTIVE_HIGH>;
+   rockchip,mic-det-gpios = < RK_PB3 GPIO_ACTIVE_LOW>;
+   rockchip,headset-codec = <>;
+   rockchip,hdmi-codec = <>;
+   };
+};
+
+ {
+   max98090: max98090@10 {
+   compatible = "maxim,max98090";
+   reg = <0x10>;
+   interrupt-parent = <>;
+   interrupts = ;
+   clock-names = "mclk";
+   clocks = < SCLK_I2S0_OUT>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_codec>;
+   };
+};
+
+ {
+   headsetcodec: ts3a227e@3b {
+   compatible = "ti,ts3a227e";
+   reg = <0x3b>;
+   interrupt-parent = <>;
+   interrupts = ;
+   pinctrl-names = "default";
+   pinctrl-0 = <_int_l>;
+   ti,micbias = <7>; /* MICBIAS = 2.8V */
+   };
+};
+
+ {
+   status = "okay";
+};
+
+_domains {
+   audio-supply = <_codec>;
+};
+
+ {
+   vcc10-supply = <_sys>;
+
+   regulators {
+   vcc18_codec: LDO_REG6 {
+   regulator-name = "vcc18_codec";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
+   };
+   };
+};
+
+ {
+   codec {
+   hp_det: hp-det {
+   rockchip,pins = <6 RK_PA5 RK_FUNC_GPIO _pull_up>;
+   };
+
+   /*
+* HACK: We're going to _pull down_ this _active low_ interrupt
+* so that it never fires.  We don't need this interrupt because
+* we've got a ts3a227e chip but the driver requires it.
+*/
+   int_codec: int-codec {
+   rockchip,pins = <6 RK_PA7 RK_FUNC_GPIO _pull_down>;
+   };
+
+   mic_det: mic-det {
+   rockchip,pins = <6 RK_PB3 RK_FUNC_GPIO _pull_up>;
+   };
+   };
+
+   headset {
+   ts3a227e_int_l: ts3a227e-int-l {
+   rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO _pull_up>;
+   };
+   };
+};
diff --git a/arch/arm/dts/rk3288-veyron-broadcom-bluetooth.dtsi 
b/arch/arm/dts/rk3288-veyron-broadcom-bluetooth.dtsi
new file mode 100644
index ..a10d25ac
--- /dev/null
+++ b/arch/arm/dts/rk3288-veyron-broadcom-bluetooth.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Veyron (and derivatives) fragment for the Broadcom 43450 bluetooth
+ * chip.
+ *
+ * Copyright 2019 Google, Inc
+ */
+
+ {
+   bluetooth {
+   pinctrl-names = "default";
+   pinctrl-0 = <_host_wake_l>, <_enable_l>,
+   <_dev_wake>;
+
+   

Re: [PATCH v3 09/12] arm: dts: rockchip: sync rk3288.dtsi from Linux

2022-03-28 Thread Kever Yang



On 2022/3/4 07:52, Johan Jonker wrote:

Sync rk3288.dtsi from Linux version 5.17.

Signed-off-by: Johan Jonker 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---

Changed V3:
   change reg size

Changed V2:
   rename mipi_dsi0 label
   move io_domains
   remove hdmi_audio veyron node
   change memory@0 reg size
---
  arch/arm/dts/rk3288-evb.dtsi |2 +-
  arch/arm/dts/rk3288-miqi.dtsi|   28 +-
  arch/arm/dts/rk3288-phycore-som.dtsi |   30 +-
  arch/arm/dts/rk3288-popmetal.dtsi|   30 +-
  arch/arm/dts/rk3288-thermal.dtsi |   87 --
  arch/arm/dts/rk3288-veyron-jerry.dts |6 -
  arch/arm/dts/rk3288-veyron.dtsi  |   33 +-
  arch/arm/dts/rk3288.dtsi | 1367 +-
  8 files changed, 970 insertions(+), 613 deletions(-)
  delete mode 100644 arch/arm/dts/rk3288-thermal.dtsi

diff --git a/arch/arm/dts/rk3288-evb.dtsi b/arch/arm/dts/rk3288-evb.dtsi
index 04902c0b..72da8847 100644
--- a/arch/arm/dts/rk3288-evb.dtsi
+++ b/arch/arm/dts/rk3288-evb.dtsi
@@ -448,7 +448,7 @@
status = "okay";
  };
  
-_dsi0 {

+_dsi {
status = "disabled";
rockchip,panel = <>;
display-timings {
diff --git a/arch/arm/dts/rk3288-miqi.dtsi b/arch/arm/dts/rk3288-miqi.dtsi
index cb80cbf2..b1c286c9 100644
--- a/arch/arm/dts/rk3288-miqi.dtsi
+++ b/arch/arm/dts/rk3288-miqi.dtsi
@@ -18,21 +18,6 @@
clock-output-names = "ext_gmac";
};
  
-	io_domains: io-domains {

-   compatible = "rockchip,rk3288-io-voltage-domain";
-   rockchip,grf = <>;
-
-   audio-supply = <_33>;
-   flash0-supply = <_flash>;
-   flash1-supply = <_lan>;
-   gpio30-supply = <_io>;
-   gpio1830-supply = <_io>;
-   lcdc-supply = <_io>;
-   sdcard-supply = <_sd>;
-   wifi-supply = <_18>;
-   };
-
-
leds {
compatible = "gpio-leds";
  
@@ -277,6 +262,19 @@

status = "okay";
  };
  
+_domains {

+   status = "okay";
+
+   audio-supply = <_33>;
+   flash0-supply = <_flash>;
+   flash1-supply = <_lan>;
+   gpio30-supply = <_io>;
+   gpio1830-supply = <_io>;
+   lcdc-supply = <_io>;
+   sdcard-supply = <_sd>;
+   wifi-supply = <_18>;
+};
+
   {
pcfg_output_high: pcfg-output-high {
output-high;
diff --git a/arch/arm/dts/rk3288-phycore-som.dtsi 
b/arch/arm/dts/rk3288-phycore-som.dtsi
index 821525f7..8ac695c8 100644
--- a/arch/arm/dts/rk3288-phycore-som.dtsi
+++ b/arch/arm/dts/rk3288-phycore-som.dtsi
@@ -71,22 +71,6 @@
clock-output-names = "ext_gmac";
};
  
-	io_domains: io_domains {

-   compatible = "rockchip,rk3288-io-voltage-domain";
-
-   status = "okay";
-   sdcard-supply = <_io_sd>;
-   flash0-supply = <_emmc_io>;
-   flash1-supply = <_misc_1v8>;
-   gpio1830-supply = <_3v3_io>;
-   gpio30-supply = <_3v3_io>;
-   bb-supply = <_3v3_io>;
-   dvp-supply = <_3v3_io>;
-   lcdc-supply = <_3v3_io>;
-   wifi-supply = <_3v3_io>;
-   audio-supply = <_3v3_io>;
-   };
-
leds: user-leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -197,6 +181,20 @@
ddc-i2c-bus = <>;
  };
  
+_domains {

+   status = "okay";
+   sdcard-supply = <_io_sd>;
+   flash0-supply = <_emmc_io>;
+   flash1-supply = <_misc_1v8>;
+   gpio1830-supply = <_3v3_io>;
+   gpio30-supply = <_3v3_io>;
+   bb-supply = <_3v3_io>;
+   dvp-supply = <_3v3_io>;
+   lcdc-supply = <_3v3_io>;
+   wifi-supply = <_3v3_io>;
+   audio-supply = <_3v3_io>;
+};
+
   {
status = "okay";
clock-frequency = <40>;
diff --git a/arch/arm/dts/rk3288-popmetal.dtsi 
b/arch/arm/dts/rk3288-popmetal.dtsi
index 63785eb5..bcd8fded 100644
--- a/arch/arm/dts/rk3288-popmetal.dtsi
+++ b/arch/arm/dts/rk3288-popmetal.dtsi
@@ -69,22 +69,6 @@
};
};
  
-	io_domains: io-domains {

-   compatible = "rockchip,rk3288-io-voltage-domain";
-   rockchip,grf = <>;
-
-   audio-supply = <_33>;
-   bb-supply = <_io>;
-   dvp-supply = <_dvp>;
-   flash0-supply = <_flash>;
-   flash1-supply = <_lan>;
-   gpio30-supply = <_io>;
-   gpio1830-supply = <_io>;
-   lcdc-supply = <_io>;
-   sdcard-supply = <_sd>;
-   wifi-supply = <_wl>;
-   };
-
ir: ir-receiver {
compatible = "gpio-ir-receiver";
gpios = < 6 GPIO_ACTIVE_LOW>;
@@ -441,6 +425,20 @@
status = "okay";
  };
  
+_domains {

+   status = "okay";
+   audio-supply = <_33>;
+   bb-supply = <_io>;
+   dvp-supply = <_dvp>;
+   flash0-supply = <_flash>;
+   flash1-supply = <_lan>;
+ 

Re: [PATCH v3 08/12] arm: dts: rockchip: move all rk3288 u-boot specific properties in separate dtsi files

2022-03-28 Thread Kever Yang



On 2022/3/4 07:52, Johan Jonker wrote:

In order to sync rk3288.dtsi from Linux it needed to
move all u-boot specific properties in separate dtsi files.

Signed-off-by: Johan Jonker 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---

Changed V3:
   add u-boot,dm-pre-reloc to noc node
   change reg size rk3288-u-boot.dtsi

Changed V2:
   combine U-boot specific changes
   add bus_intmem label
   use current led node name
---
  arch/arm/dts/rk3288-evb-u-boot.dtsi   | 11 +++
  arch/arm/dts/rk3288-evb.dts   | 11 ---
  arch/arm/dts/rk3288-firefly-u-boot.dtsi   | 31 +++
  arch/arm/dts/rk3288-firefly.dts   | 17 
  arch/arm/dts/rk3288-firefly.dtsi  |  3 -
  arch/arm/dts/rk3288-miqi-u-boot.dtsi  | 20 +
  arch/arm/dts/rk3288-miqi.dts  | 11 ---
  arch/arm/dts/rk3288-miqi.dtsi |  2 -
  arch/arm/dts/rk3288-phycore-rdk-u-boot.dtsi   | 44 ++
  arch/arm/dts/rk3288-phycore-rdk.dts   | 18 -
  arch/arm/dts/rk3288-phycore-som.dtsi  |  6 --
  arch/arm/dts/rk3288-popmetal-u-boot.dtsi  | 11 +++
  arch/arm/dts/rk3288-popmetal.dts  | 11 ---
  arch/arm/dts/rk3288-rock2-square-u-boot.dtsi  | 30 +++
  arch/arm/dts/rk3288-rock2-square.dts  | 18 -
  arch/arm/dts/rk3288-u-boot.dtsi   | 80 ---
  arch/arm/dts/rk3288-veyron-jerry-u-boot.dtsi  | 14 
  arch/arm/dts/rk3288-veyron-jerry.dts  | 11 ---
  arch/arm/dts/rk3288-veyron-mickey-u-boot.dtsi | 14 
  arch/arm/dts/rk3288-veyron-mickey.dts | 11 ---
  arch/arm/dts/rk3288-veyron-minnie-u-boot.dtsi | 14 
  arch/arm/dts/rk3288-veyron-minnie.dts | 11 ---
  arch/arm/dts/rk3288-veyron-u-boot.dtsi| 62 ++
  arch/arm/dts/rk3288-veyron.dtsi   | 39 -
  arch/arm/dts/rk3288.dtsi  | 49 +---
  25 files changed, 321 insertions(+), 228 deletions(-)
  create mode 100644 arch/arm/dts/rk3288-phycore-rdk-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3288-rock2-square-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3288-veyron-jerry-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3288-veyron-mickey-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3288-veyron-minnie-u-boot.dtsi

diff --git a/arch/arm/dts/rk3288-evb-u-boot.dtsi 
b/arch/arm/dts/rk3288-evb-u-boot.dtsi
index 8ac7840f..c8f51207 100644
--- a/arch/arm/dts/rk3288-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-evb-u-boot.dtsi
@@ -5,6 +5,17 @@
  
  #include "rk3288-u-boot.dtsi"
  
+ {

+   rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+   0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
+   0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
+   0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
+   0x8 0x1f4>;
+   rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
+   0x0 0xc3 0x6 0x2>;
+   rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
+};
+
   {
u-boot,dm-pre-reloc;
  };
diff --git a/arch/arm/dts/rk3288-evb.dts b/arch/arm/dts/rk3288-evb.dts
index eac91a87..bb24a96c 100644
--- a/arch/arm/dts/rk3288-evb.dts
+++ b/arch/arm/dts/rk3288-evb.dts
@@ -15,17 +15,6 @@
};
  };
  
- {

-   rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
-   0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
-   0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
-   0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
-   0x8 0x1f4>;
-   rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
-   0x0 0xc3 0x6 0x2>;
-   rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
-};
-
   {
status = "okay";
  };
diff --git a/arch/arm/dts/rk3288-firefly-u-boot.dtsi 
b/arch/arm/dts/rk3288-firefly-u-boot.dtsi
index 8b9c3831..cc84d7c4 100644
--- a/arch/arm/dts/rk3288-firefly-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-firefly-u-boot.dtsi
@@ -5,6 +5,37 @@
  
  #include "rk3288-u-boot.dtsi"
  
+/ {

+   config {
+   u-boot,dm-pre-reloc;
+   u-boot,boot-led = "firefly:green:power";
+   };
+
+   leds {
+   u-boot,dm-pre-reloc;
+
+   work {
+   u-boot,dm-pre-reloc;
+   };
+
+   power {
+   u-boot,dm-pre-reloc;
+   };
+   };
+};
+
+ {
+   rockchip,pctl-timing = <0x29a 0xc8 0x1f8 0x42 0x4e 0x4 0xea 0xa
+   0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
+   0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
+   0x1 0x7 0x7 0x4 0xc 0x43 0x100 0x0
+   0x5 0x0>;
+   rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
+   0xa60 0x40 0x10 0x0>;
+   /* Add a dummy value to cause of-platdata think this is bytes */
+   rockchip,sdram-params = <0x30B25564 0x627 3 66600 3 9 1>;
+};
+
   {
u-boot,dm-pre-reloc;
  };
diff --git a/arch/arm/dts/rk3288-firefly.dts b/arch/arm/dts/rk3288-firefly.dts
index 

Re: [PATCH v3 07/12] rockchip: rk3288-cru: sync the clock dt-binding header from Linux

2022-03-28 Thread Kever Yang



On 2022/3/4 07:52, Johan Jonker wrote:

In order to update the DT for rk3288
sync the clock dt-binding header.
This is the state as of v5.17 in Linux.
Keep SCLK_MAC_PLL in use for rk3288 clock driver.

Signed-off-by: Johan Jonker 
Reviewed-by: Simon Glass 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  include/dt-bindings/clock/rk3288-cru.h | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/include/dt-bindings/clock/rk3288-cru.h 
b/include/dt-bindings/clock/rk3288-cru.h
index e368d767..453f6671 100644
--- a/include/dt-bindings/clock/rk3288-cru.h
+++ b/include/dt-bindings/clock/rk3288-cru.h
@@ -1,9 +1,12 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
+/* SPDX-License-Identifier: GPL-2.0-or-later */
  /*
   * Copyright (c) 2014 MundoReader S.L.
   * Author: Heiko Stuebner 
   */
  
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3288_H

+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3288_H
+
  /* core clocks */
  #define PLL_APLL  1
  #define PLL_DPLL  2
@@ -74,6 +77,9 @@
  #define SCLK_USBPHY480M_SRC   122
  #define SCLK_PVTM_CORE123
  #define SCLK_PVTM_GPU 124
+#define SCLK_CRYPTO125
+#define SCLK_MIPIDSI_24M   126
+#define SCLK_VIP_OUT   127
  
  #define SCLK_MAC_PLL		150

  #define SCLK_MAC  151
@@ -153,6 +159,9 @@
  #define PCLK_DDRUPCTL1366
  #define PCLK_PUBL1367
  #define PCLK_WDT  368
+#define PCLK_EFUSE256  369
+#define PCLK_EFUSE1024 370
+#define PCLK_ISP_IN371
  
  /* hclk gates */

  #define HCLK_GPS  448
@@ -368,3 +377,5 @@
  #define SRST_TSP_CLKIN0   189
  #define SRST_TSP_CLKIN1   190
  #define SRST_TSP_27M  191
+
+#endif


Re: [PATCH v3 06/12] rockchip: rk3288-power: sync power domain dt-binding header from Linux

2022-03-28 Thread Kever Yang



On 2022/3/4 07:52, Johan Jonker wrote:

In order to update the DT for rk3288
sync the power domain dt-binding header.
This is the state as of v5.17 in Linux.
Change location to be more in line with other SoCs.

Signed-off-by: Johan Jonker 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---

Changed V2:
   changed include rk3288.dtsi
---
  arch/arm/dts/rk3288.dtsi  |  2 +-
  include/dt-bindings/power-domain/rk3288.h | 11 
  include/dt-bindings/power/rk3288-power.h  | 32 +++
  3 files changed, 33 insertions(+), 12 deletions(-)
  delete mode 100644 include/dt-bindings/power-domain/rk3288.h
  create mode 100644 include/dt-bindings/power/rk3288-power.h

diff --git a/arch/arm/dts/rk3288.dtsi b/arch/arm/dts/rk3288.dtsi
index 22bb06ce..2086dbfd 100644
--- a/arch/arm/dts/rk3288.dtsi
+++ b/arch/arm/dts/rk3288.dtsi
@@ -5,7 +5,7 @@
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
  #include 
  #include "skeleton.dtsi"
diff --git a/include/dt-bindings/power-domain/rk3288.h 
b/include/dt-bindings/power-domain/rk3288.h
deleted file mode 100644
index ca68c114..
--- a/include/dt-bindings/power-domain/rk3288.h
+++ /dev/null
@@ -1,11 +0,0 @@
-#ifndef __DT_BINDINGS_POWER_DOMAIN_RK3288_H__
-#define __DT_BINDINGS_POWER_DOMAIN_RK3288_H__
-
-/* RK3288 power domain index */
-#define RK3288_PD_GPU  0
-#define RK3288_PD_VIO  1
-#define RK3288_PD_VIDEO2
-#define RK3288_PD_HEVC 3
-#define RK3288_PD_PERI 4
-
-#endif
diff --git a/include/dt-bindings/power/rk3288-power.h 
b/include/dt-bindings/power/rk3288-power.h
new file mode 100644
index ..f710b56c
--- /dev/null
+++ b/include/dt-bindings/power/rk3288-power.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DT_BINDINGS_POWER_RK3288_POWER_H__
+#define __DT_BINDINGS_POWER_RK3288_POWER_H__
+
+/**
+ * RK3288 Power Domain and Voltage Domain Summary.
+ */
+
+/* VD_CORE */
+#define RK3288_PD_A17_00
+#define RK3288_PD_A17_11
+#define RK3288_PD_A17_22
+#define RK3288_PD_A17_33
+#define RK3288_PD_SCU  4
+#define RK3288_PD_DEBUG5
+#define RK3288_PD_MEM  6
+
+/* VD_LOGIC */
+#define RK3288_PD_BUS  7
+#define RK3288_PD_PERI 8
+#define RK3288_PD_VIO  9
+#define RK3288_PD_ALIVE10
+#define RK3288_PD_HEVC 11
+#define RK3288_PD_VIDEO12
+
+/* VD_GPU */
+#define RK3288_PD_GPU  13
+
+/* VD_PMU */
+#define RK3288_PD_PMU  14
+
+#endif


Re: [PATCH v3 05/12] arm: dts: rockchip: sync rk3229-evb.dts from Linux

2022-03-28 Thread Kever Yang



On 2022/3/4 07:52, Johan Jonker wrote:

Sync rk3229-evb.dts from Linux version 5.17.

Signed-off-by: Johan Jonker 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3229-evb.dts | 212 +---
  arch/arm/dts/rk3229.dtsi|  52 +
  2 files changed, 249 insertions(+), 15 deletions(-)
  create mode 100644 arch/arm/dts/rk3229.dtsi

diff --git a/arch/arm/dts/rk3229-evb.dts b/arch/arm/dts/rk3229-evb.dts
index d2681d1a..797476e8 100644
--- a/arch/arm/dts/rk3229-evb.dts
+++ b/arch/arm/dts/rk3229-evb.dts
@@ -1,21 +1,32 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
-/*
- * (C) Copyright 2017 Rockchip Electronics Co., Ltd.
- */
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
  
  /dts-v1/;
  
-#include "rk322x.dtsi"

+#include 
+#include "rk3229.dtsi"
  
  / {

model = "Rockchip RK3229 Evaluation board";
compatible = "rockchip,rk3229-evb", "rockchip,rk3229";
  
+	aliases {

+   mmc0 = 
+   };
+
memory@6000 {
device_type = "memory";
reg = <0x6000 0x4000>;
};
  
+	dc_12v: dc-12v-regulator {

+   compatible = "regulator-fixed";
+   regulator-name = "dc_12v";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
ext_gmac: ext_gmac {
compatible = "fixed-clock";
clock-frequency = <12500>;
@@ -23,6 +34,18 @@
#clock-cells = <0>;
};
  
+	vcc_host: vcc-host-regulator {

+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = < RK_PC4 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_vbus_drv>;
+   regulator-name = "vcc_host";
+   regulator-always-on;
+   regulator-boot-on;
+   vin-supply = <_sys>;
+   };
+
vcc_phy: vcc-phy-regulator {
compatible = "regulator-fixed";
enable-active-high;
@@ -31,7 +54,95 @@
regulator-max-microvolt = <180>;
regulator-always-on;
regulator-boot-on;
+   vin-supply = <_1v8>;
+   };
+
+   vcc_sys: vcc-sys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_12v>;
+   };
+
+   vccio_1v8: vccio-1v8-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vccio_1v8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   vin-supply = <_sys>;
+   };
+
+   vccio_3v3: vccio-3v3-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vccio_3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   vin-supply = <_sys>;
+   };
+
+   vdd_arm: vdd-arm-regulator {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 1>;
+   pwm-supply = <_sys>;
+   regulator-name = "vdd_arm";
+   regulator-min-microvolt = <95>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
};
+
+   vdd_log: vdd-log-regulator {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 1>;
+   pwm-supply = <_sys>;
+   regulator-name = "vdd_log";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <130>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   gpio_keys {
+   compatible = "gpio-keys";
+   autorepeat;
+   pinctrl-names = "default";
+   pinctrl-0 = <_key>;
+
+   power_key: power-key {
+   label = "GPIO Key Power";
+   gpios = < 23 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   debounce-interval = <100>;
+   wakeup-source;
+   };
+   };
+};
+
+ {
+   cpu-supply = <_arm>;
+};
+
+ {
+   cpu-supply = <_arm>;
+};
+
+ {
+   cpu-supply = <_arm>;
+};
+
+ {
+   cpu-supply = <_arm>;
+};
+
+ {
+   cap-mmc-highspeed;
+   non-removable;
+   status = "okay";
  };
  
   {

@@ -50,25 +161,96 @@
status = "okay";
  };
  
- {

+_domains {
status = "okay";
+
+   vccio1-supply = 

Re: [PATCH v3 04/12] arm: dts: rockchip: sync rk322x.dtsi from Linux

2022-03-28 Thread Kever Yang

Hi Johan,

On 2022/3/4 07:52, Johan Jonker wrote:

Sync rk322x.dtsi from Linux version 5.17.

Signed-off-by: Johan Jonker 
---

Changed V2:
   update
   rename usb20_otg label
---
  arch/arm/dts/rk3229-evb.dts |   2 +-
  arch/arm/dts/rk322x.dtsi| 846 +---
  2 files changed, 695 insertions(+), 153 deletions(-)

diff --git a/arch/arm/dts/rk3229-evb.dts b/arch/arm/dts/rk3229-evb.dts
index 66a3ba23..d2681d1a 100644
--- a/arch/arm/dts/rk3229-evb.dts
+++ b/arch/arm/dts/rk3229-evb.dts
@@ -69,6 +69,6 @@
status = "okay";
  };
  
-_otg {

+_otg {
 status = "okay";
  };
diff --git a/arch/arm/dts/rk322x.dtsi b/arch/arm/dts/rk322x.dtsi
index 3245da3c..8eed9e3a 100644
--- a/arch/arm/dts/rk322x.dtsi
+++ b/arch/arm/dts/rk322x.dtsi
@@ -1,7 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
- */
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
  
  #include 

  #include 
@@ -9,6 +6,7 @@
  #include 
  #include 
  #include 
+#include 
  
  / {

#address-cells = <1>;
@@ -20,8 +18,7 @@
serial0 = 
serial1 = 
serial2 = 
-   mmc0 = 
-   mmc1 = 



I think this part will need to move to -u-boot.dtsi for U-Boot will use 
this to decide the boot order,


and U-Boot use emmc as mmc0 and sdmmc as mmc1 before kernel decide to 
add alias for mmc module.



Thanks,

- Kever


+   spi0 = 
};
  
  	cpus {

@@ -33,13 +30,11 @@
compatible = "arm,cortex-a7";
reg = <0xf00>;
resets = < SRST_CORE0>;
-   operating-points = <
-   /* KHzuV */
-816000 100
-   >;
+   operating-points-v2 = <_opp_table>;
#cooling-cells = <2>; /* min followed by max */
clock-latency = <4>;
clocks = < ARMCLK>;
+   enable-method = "psci";
};
  
  		cpu1: cpu@f01 {

@@ -47,6 +42,9 @@
compatible = "arm,cortex-a7";
reg = <0xf01>;
resets = < SRST_CORE1>;
+   operating-points-v2 = <_opp_table>;
+   #cooling-cells = <2>; /* min followed by max */
+   enable-method = "psci";
};
  
  		cpu2: cpu@f02 {

@@ -54,6 +52,9 @@
compatible = "arm,cortex-a7";
reg = <0xf02>;
resets = < SRST_CORE2>;
+   operating-points-v2 = <_opp_table>;
+   #cooling-cells = <2>; /* min followed by max */
+   enable-method = "psci";
};
  
  		cpu3: cpu@f03 {

@@ -61,23 +62,37 @@
compatible = "arm,cortex-a7";
reg = <0xf03>;
resets = < SRST_CORE3>;
+   operating-points-v2 = <_opp_table>;
+   #cooling-cells = <2>; /* min followed by max */
+   enable-method = "psci";
};
};
  
-	amba {

-   compatible = "simple-bus";
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges;
+   cpu0_opp_table: opp-table-0 {
+   compatible = "operating-points-v2";
+   opp-shared;
  
-		pdma: pdma@110f {

-   compatible = "arm,pl330", "arm,primecell";
-   reg = <0x110f 0x4000>;
-   interrupts = ,
-;
-   #dma-cells = <1>;
-   clocks = < ACLK_DMAC>;
-   clock-names = "apb_pclk";
+   opp-40800 {
+   opp-hz = /bits/ 64 <40800>;
+   opp-microvolt = <95>;
+   clock-latency-ns = <4>;
+   opp-suspend;
+   };
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <975000>;
+   };
+   opp-81600 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <100>;
+   };
+   opp-100800 {
+   opp-hz = /bits/ 64 <100800>;
+   opp-microvolt = <1175000>;
+   };
+   opp-12 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <1275000>;
};
};
  
@@ -90,6 +105,11 @@

interrupt-affinity = <>, <>, <>, <>;
};
  
+	psci {

+   compatible = "arm,psci-1.0", "arm,psci-0.2";
+   method = 

Re: [PATCH v3 03/12] arm: dts: rockchip: move all rk322x u-boot specific properties in separate dtsi files

2022-03-28 Thread Kever Yang



On 2022/3/4 07:52, Johan Jonker wrote:

In order to sync rk322x.dtsi from Linux, move all
U-boot specific properties in separate dtsi files.

Signed-off-by: Johan Jonker 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---

Changed V3:
   add include "rockchip-u-boot.dtsi"
---
  arch/arm/dts/rk3229-evb-u-boot.dtsi | 28 +++
  arch/arm/dts/rk3229-evb.dts | 17 -
  arch/arm/dts/rk322x-u-boot.dtsi | 56 +
  arch/arm/dts/rk322x.dtsi| 37 ---
  4 files changed, 84 insertions(+), 54 deletions(-)
  create mode 100644 arch/arm/dts/rk3229-evb-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk322x-u-boot.dtsi

diff --git a/arch/arm/dts/rk3229-evb-u-boot.dtsi 
b/arch/arm/dts/rk3229-evb-u-boot.dtsi
new file mode 100644
index ..b65149c2
--- /dev/null
+++ b/arch/arm/dts/rk3229-evb-u-boot.dtsi
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk322x-u-boot.dtsi"
+
+/ {
+   chosen {
+   stdout-path = 
+   };
+};
+
+ {
+   rockchip,pctl-timing = <0x96 0xC8 0x1F3 0xF 0x804D 0x4 0x4E 0x6 0x3
+   0x0 0x6 0x5 0xC 0x10 0x6 0x4 0x4
+   0x5 0x4 0x200 0x3 0xA 0x40 0x0 0x1
+   0x5 0x5 0x3 0xC 0x1E 0x100 0x0 0x4
+   0x0 0x924>;
+   rockchip,phy-timing = <0x220 0x1 0x0 0x0 0x0 0x4 0x60>;
+   rockchip,sdram-params = <0x428B188 0x0 0x21 0x472 0x15
+   0 300 3 0 120>;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3229-evb.dts b/arch/arm/dts/rk3229-evb.dts
index 632cdc9b..66a3ba23 100644
--- a/arch/arm/dts/rk3229-evb.dts
+++ b/arch/arm/dts/rk3229-evb.dts
@@ -11,10 +11,6 @@
model = "Rockchip RK3229 Evaluation board";
compatible = "rockchip,rk3229-evb", "rockchip,rk3229";
  
-	chosen {

-   stdout-path = 
-   };
-
memory@6000 {
device_type = "memory";
reg = <0x6000 0x4000>;
@@ -38,17 +34,6 @@
};
  };
  
- {

-   rockchip,pctl-timing = <0x96 0xC8 0x1F3 0xF 0x804D 0x4 0x4E 0x6 0x3
-   0x0 0x6 0x5 0xC 0x10 0x6 0x4 0x4
-   0x5 0x4 0x200 0x3 0xA 0x40 0x0 0x1
-   0x5 0x5 0x3 0xC 0x1E 0x100 0x0 0x4
-   0x0 0x924>;
-   rockchip,phy-timing = <0x220 0x1 0x0 0x0 0x0 0x4 0x60>;
-   rockchip,sdram-params = <0x428B188 0x0 0x21 0x472 0x15
-   0 300 3 0 120>;
-};
-
   {
assigned-clocks = < SCLK_MAC_EXTCLK>, < SCLK_MAC>;
assigned-clock-parents = <_gmac>, < SCLK_MAC_EXTCLK>;
@@ -66,7 +51,6 @@
  };
  
   {

-   u-boot,dm-pre-reloc;
status = "okay";
  };
  
@@ -82,7 +66,6 @@

  };
  
   {

-   u-boot,dm-pre-reloc;
status = "okay";
  };
  
diff --git a/arch/arm/dts/rk322x-u-boot.dtsi b/arch/arm/dts/rk322x-u-boot.dtsi

new file mode 100644
index ..79c41e48
--- /dev/null
+++ b/arch/arm/dts/rk322x-u-boot.dtsi
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rockchip-u-boot.dtsi"
+
+/ {
+   bus_intmem@1008 {
+   compatible = "mmio-sram";
+   reg = <0x1008 0x9000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x1008 0x9000>;
+
+   smp-sram@0 {
+   compatible = "rockchip,rk322x-smp-sram";
+   reg = <0x00 0x10>;
+   };
+
+   ddr_sram: ddr-sram@1000 {
+   compatible = "rockchip,rk322x-ddr-sram";
+   reg = <0x1000 0x8000>;
+   };
+   };
+
+   dmc: dmc@1120 {
+   compatible = "rockchip,rk3228-dmc", "syscon";
+   reg = <0x1120 0x3fc
+  0x1200 0x400>;
+   rockchip,cru = <>;
+   rockchip,grf = <>;
+   rockchip,msch = <_msch>;
+   rockchip,sram = <_sram>;
+   u-boot,dm-pre-reloc;
+   };
+
+   service_msch: syscon@3109 {
+   compatible = "rockchip,rk3228-msch", "syscon";
+   reg = <0x3109 0x2000>;
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   max-frequency = <15000>;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   max-frequency = <15000>;
+};
diff --git a/arch/arm/dts/rk322x.dtsi b/arch/arm/dts/rk322x.dtsi
index 4a8be5da..3245da3c 100644
--- a/arch/arm/dts/rk322x.dtsi
+++ b/arch/arm/dts/rk322x.dtsi
@@ -107,22 +107,6 @@
#clock-cells = <0>;
};
  
-	bus_intmem@1008 {

-   compatible = "mmio-sram";
-   reg = <0x1008 0x9000>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0 0x1008 0x9000>;
-   smp-sram@0 {
-   compatible = "rockchip,rk322x-smp-sram";
-   reg = 

Re: [PATCH v3 01/12] rockchip: rk3228-power: sync power domain dt-binding header from Linux

2022-03-28 Thread Kever Yang



On 2022/3/4 07:52, Johan Jonker wrote:

In order to update the DT for rk3228
sync the power domain dt-binding header.
This is the state as of v5.17 in Linux.

Signed-off-by: Johan Jonker 
Reviewed-by: Simon Glass 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  include/dt-bindings/power/rk3228-power.h | 21 +
  1 file changed, 21 insertions(+)
  create mode 100644 include/dt-bindings/power/rk3228-power.h

diff --git a/include/dt-bindings/power/rk3228-power.h 
b/include/dt-bindings/power/rk3228-power.h
new file mode 100644
index ..6a8dc1bf
--- /dev/null
+++ b/include/dt-bindings/power/rk3228-power.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DT_BINDINGS_POWER_RK3228_POWER_H__
+#define __DT_BINDINGS_POWER_RK3228_POWER_H__
+
+/**
+ * RK3228 idle id Summary.
+ */
+
+#define RK3228_PD_CORE 0
+#define RK3228_PD_MSCH 1
+#define RK3228_PD_BUS  2
+#define RK3228_PD_SYS  3
+#define RK3228_PD_VIO  4
+#define RK3228_PD_VOP  5
+#define RK3228_PD_VPU  6
+#define RK3228_PD_RKVDEC   7
+#define RK3228_PD_GPU  8
+#define RK3228_PD_PERI 9
+#define RK3228_PD_GMAC 10
+
+#endif


Re: [PATCH v3 02/12] rockchip: rk3228-cru: sync the clock dt-binding header from Linux

2022-03-28 Thread Kever Yang



On 2022/3/4 07:52, Johan Jonker wrote:

In order to update the DT for rk3228
sync the clock dt-binding header.
This is the state as of v5.17 in Linux.

Signed-off-by: Johan Jonker 
Reviewed-by: Simon Glass 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  include/dt-bindings/clock/rk3228-cru.h | 54 +-
  1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/include/dt-bindings/clock/rk3228-cru.h 
b/include/dt-bindings/clock/rk3228-cru.h
index 1217d523..de550ea5 100644
--- a/include/dt-bindings/clock/rk3228-cru.h
+++ b/include/dt-bindings/clock/rk3228-cru.h
@@ -1,6 +1,7 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
+/* SPDX-License-Identifier: GPL-2.0-or-later */
  /*
- * (C) Copyright 2017 Rockchip Electronics Co., Ltd.
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Jeffy Chen 
   */
  
  #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3228_H

@@ -39,6 +40,7 @@
  #define SCLK_EMMC_DRV 117
  #define SCLK_SDMMC_SAMPLE 118
  #define SCLK_SDIO_SAMPLE  119
+#define SCLK_SDIO_SRC  120
  #define SCLK_EMMC_SAMPLE  121
  #define SCLK_VOP  122
  #define SCLK_HDMI_HDCP123
@@ -51,6 +53,18 @@
  #define SCLK_MAC_TX   130
  #define SCLK_MAC_PHY  131
  #define SCLK_MAC_OUT  132
+#define SCLK_VDEC_CABAC133
+#define SCLK_VDEC_CORE 134
+#define SCLK_RGA   135
+#define SCLK_HDCP  136
+#define SCLK_HDMI_CEC  137
+#define SCLK_CRYPTO138
+#define SCLK_TSP   139
+#define SCLK_HSADC 140
+#define SCLK_WIFI  141
+#define SCLK_OTGPHY0   142
+#define SCLK_OTGPHY1   143
+#define SCLK_HDMI_PHY  144
  
  /* dclk gates */

  #define DCLK_VOP  190
@@ -58,15 +72,32 @@
  
  /* aclk gates */

  #define ACLK_DMAC 194
+#define ACLK_CPU   195
+#define ACLK_VPU_PRE   196
+#define ACLK_RKVDEC_PRE197
+#define ACLK_RGA_PRE   198
+#define ACLK_IEP_PRE   199
+#define ACLK_HDCP_PRE  200
+#define ACLK_VOP_PRE   201
+#define ACLK_VPU   202
+#define ACLK_RKVDEC203
+#define ACLK_IEP   204
+#define ACLK_RGA   205
+#define ACLK_HDCP  206
  #define ACLK_PERI 210
  #define ACLK_VOP  211
  #define ACLK_GMAC 212
+#define ACLK_GPU   213
  
  /* pclk gates */

  #define PCLK_GPIO0320
  #define PCLK_GPIO1321
  #define PCLK_GPIO2322
  #define PCLK_GPIO3323
+#define PCLK_VIO_H2P   324
+#define PCLK_HDCP  325
+#define PCLK_EFUSE_1024326
+#define PCLK_EFUSE_256 327
  #define PCLK_GRF  329
  #define PCLK_I2C0 332
  #define PCLK_I2C1 333
@@ -79,6 +110,7 @@
  #define PCLK_TSADC344
  #define PCLK_PWM  350
  #define PCLK_TIMER353
+#define PCLK_CPU   354
  #define PCLK_PERI 363
  #define PCLK_HDMI_CTRL364
  #define PCLK_HDMI_PHY 365
@@ -94,6 +126,24 @@
  #define HCLK_SDMMC456
  #define HCLK_SDIO 457
  #define HCLK_EMMC 459
+#define HCLK_CPU   460
+#define HCLK_VPU_PRE   461
+#define HCLK_RKVDEC_PRE462
+#define HCLK_VIO_PRE   463
+#define HCLK_VPU   464
+#define HCLK_RKVDEC465
+#define HCLK_VIO   466
+#define HCLK_RGA   467
+#define HCLK_IEP   468
+#define HCLK_VIO_H2P   469
+#define HCLK_HDCP_MMU  470
+#define HCLK_HOST0 471
+#define HCLK_HOST1 472
+#define HCLK_HOST2 473
+#define HCLK_OTG   474
+#define HCLK_TSP   475
+#define HCLK_M_CRYPTO  476
+#define HCLK_S_CRYPTO  477
  #define HCLK_PERI 478
  
  #define CLK_NR_CLKS		(HCLK_PERI + 1)


  1   2   >