Re: [PATCH v3 6/6] board: add support for Schneider HMIBSC board

[Stephan Gerhold]

On Fri, Apr 05, 2024 at 02:37:42PM +0530, Sumit Garg wrote:
> Support for Schneider Electric HMIBSC. Features:
> - Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
> - 2GiB RAM
> - 64GiB eMMC, SD slot
> - WiFi and Bluetooth
> - 2x Host, 1x Device USB port
> - HDMI
> - Discrete TPM2 chip over SPI
> 
> Features enabled in U-Boot:
> - RAUC updates
> - Environment protection
> - USB based ethernet adaptors
> 
> Signed-off-by: Sumit Garg 

I don't think this is a big deal but this patch would be a bit easier to
skim over if you move the (unmodified?) import of the Linux
apq8016-schneider-hmibsc.dts to a separate patch with a clear note in
the commit message

 - where it comes from (link to Linux patch), and
 - that it can be removed again with a future update of the upstream DTs
   in U-Boot (once it is applied upstream at least).

You kind of have that information in the cover letter but I think it
would be good to have it in the commit message.

> ---
>  arch/arm/dts/apq8016-schneider-hmibsc.dts | 491 ++
>  board/schneider/hmibsc/MAINTAINERS|   6 +
>  configs/hmibsc_defconfig  |  86 
>  doc/board/index.rst   |   1 +
>  doc/board/schneider/hmibsc.rst|  45 ++
>  doc/board/schneider/index.rst |   9 +
>  include/configs/hmibsc.h  |  57 +++
>  7 files changed, 695 insertions(+)
>  create mode 100644 arch/arm/dts/apq8016-schneider-hmibsc.dts
>  create mode 100644 board/schneider/hmibsc/MAINTAINERS
>  create mode 100644 configs/hmibsc_defconfig
>  create mode 100644 doc/board/schneider/hmibsc.rst
>  create mode 100644 doc/board/schneider/index.rst
>  create mode 100644 include/configs/hmibsc.h
> 
> [...]
> diff --git a/include/configs/hmibsc.h b/include/configs/hmibsc.h
> new file mode 100644
> index 000..66dfa549ce1
> --- /dev/null
> +++ b/include/configs/hmibsc.h
> @@ -0,0 +1,57 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Board configuration file for HMIBSC
> + *
> + * (C) Copyright 2024 Sumit Garg 
> + */
> +
> +#ifndef __CONFIGS_HMIBSC_H
> +#define __CONFIGS_HMIBSC_H
> +
> +/* PHY needs a longer aneg time */
> +#define PHY_ANEG_TIMEOUT 8000
> +
> +#define HMIBSC_BOOTCOMMAND \
> + "setenv devtype mmc; setenv devnum 0; " \
> + "test -n \"${BOOT_ORDER}\" || setenv BOOT_ORDER \"A B\"; " \
> + "test -n \"${BOOT_A_LEFT}\" || setenv BOOT_A_LEFT 3; " \
> + "test -n \"${BOOT_B_LEFT}\" || setenv BOOT_B_LEFT 3; " \
> + "setenv raucslot; " \
> + "for BOOT_SLOT in \"${BOOT_ORDER}\"; do " \
> + "  if test \"x${raucslot}\" != \"x\"; then " \
> + "  echo \"skip remaining slots...\"; " \
> + "  elif test \"x${BOOT_SLOT}\" = \"xA\"; then " \
> + "if test ${BOOT_A_LEFT} -gt 0; then " \
> + "  setexpr BOOT_A_LEFT ${BOOT_A_LEFT} - 1; " \
> + "  echo \"Found valid RAUC slot A\"; " \
> + "  setenv raucslot \"rauc.slot=A\"; " \
> + "  setenv raucpart A; setenv distro_bootpart 6;" \
> + "fi; " \
> + "  elif test \"x${BOOT_SLOT}\" = \"xB\"; then " \
> + "if test ${BOOT_B_LEFT} -gt 0; then " \
> + "  setexpr BOOT_B_LEFT ${BOOT_B_LEFT} - 1; " \
> + "  echo \"Found valid RAUC slot B\"; " \
> + "  setenv raucslot \"rauc.slot=B\"; " \
> + "  setenv raucpart B; setenv distro_bootpart 7;" \
> + "fi; " \
> + "  fi; " \
> + "done; " \
> + "if test -n \"${raucslot}\"; then " \
> + "  setenv bootargs console=ttyMSM1 root=PARTLABEL=rootfs_${raucpart} rw 
> rootwait ${raucslot}; " \
> + "  saveenv; " \
> + "else " \
> + "  echo \"No valid RAUC slot found. Resetting tries to 3\"; " \
> + "  setenv BOOT_A_LEFT 3; " \
> + "  setenv BOOT_B_LEFT 3; " \
> + "  saveenv; " \
> + "  reset; " \
> + "fi; " \
> + "load ${devtype} ${devnum}:${distro_bootpart} ${loadaddr} 
> /boot/fitImage && bootm"
> +
> +#define CFG_EXTRA_ENV_SETTINGS \
> + "loadaddr=0x9000\0" \
> + "bootcmd="  HMIBSC_BOOTCOMMAND  "\0"
> +

The "text-based environment" [1] is preferred nowadays, i.e. defining
these inside board/schneider/hmibsc/hmibsc.env instead (similar to how
DB410c has its environment defined in
board/qualcomm/dragonboard410c/dragonboard410c.env). This should also
avoid all the crazy escaping to encode it as C string. :D

However, I suspect that right now it would attempt to load this file
from board/qualcomm/hmibsc/hmibsc.env since you do not seem to have
CONFIG_SYS_VENDOR set correctly. It looks like Caleb removed the option
to customize CONFIG_SYS_VENDOR in commit 059d526af312 ("mach-snapdragon:
generalise board support"). It might be easiest to add a prompt in
arch/arm/mach-snapdragon/Kconfig to allow changing it (similar to
CONFIG_SYS_BOARD).

Thanks,
Stephan

[1]: 
https://docs.u-boot.org/en/latest/usage/environment.html#text-based-environment

Re: [PATCH v2 5/5] board: add support for Schneider HMIBSC board

[Stephan Gerhold]

On Wed, Mar 13, 2024 at 12:08:58PM +0530, Sumit Garg wrote:
> On Mon, 11 Mar 2024 at 20:07, Stephan Gerhold  wrote:
> > On Mon, Mar 11, 2024 at 04:40:26PM +0530, Sumit Garg wrote:
> > > Support for Schneider Electric HMIBSC. Features:
> > > - Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
> > > - 2GiB RAM
> > > - 64GiB eMMC, SD slot
> > > - WiFi and Bluetooth
> > > - 2x Host, 1x Device USB port
> > > - HDMI
> > > - Discrete TPM2 chip over SPI
> > >
> > > Features enabled in U-Boot:
> > > - RAUC updates
> > > - Environment protection
> > > - USB based ethernet adaptors
> > >
> > > Signed-off-by: Sumit Garg 
> >
> [...]
> > > + gpio_rs232_high: gpio_rs232_high {
> >
> > Pretty sure DT schema checks would complain about this node name (need
> > -state suffix, no underscores).
> 
> We have the dtbs_check in U-Boot too. I will use that before posting
> the next version.
> 
> >
> > > + bootph-all;
> > > + pins = "gpio99";
> > > + function = "gpio";
> > > +
> > > + drive-strength = <16>;
> > > + bias-disable;
> > > + output-high;
> > > + };
> > > +
> > > + gpio_rs232_low: gpio_rs232_low {
> >
> > Same here.
> >
> > Also, since I'm looking at this a bit more closely now, are there maybe
> > more clear label/node names you could use here, or a comment you could
> > add what exactly these pins do? I guess this enables something about
> > RS232 but it's not clear what exactly.
> 
> Actually these GPIOs are a mux to select among different UART modes
> (RS232/422/485). This configuration allows you to select RS232 mode.
> How about following label/node names?
> 
> uart1_mux0_rs232_high: uart1-mux0-rs232-state
> 
> uart1_mux1_rs232_low: uart1-mux1-rs232-state
> 

Hm, is it a 2 bit mux selector like

gpio99  gpio100 UART mode
0   0   ?
0   1   ?
1   0   RS232
1   1   ?

and the others are RS422 and RS485? If yes, a comment with the table of
the function assignments would help a lot for clarity. With that,
precise naming would not be that important anymore. :-)

Thanks,
Stephan

Re: [PATCH v2 5/5] board: add support for Schneider HMIBSC board

[Stephan Gerhold]

On Mon, Mar 11, 2024 at 04:40:26PM +0530, Sumit Garg wrote:
> Support for Schneider Electric HMIBSC. Features:
> - Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
> - 2GiB RAM
> - 64GiB eMMC, SD slot
> - WiFi and Bluetooth
> - 2x Host, 1x Device USB port
> - HDMI
> - Discrete TPM2 chip over SPI
> 
> Features enabled in U-Boot:
> - RAUC updates
> - Environment protection
> - USB based ethernet adaptors
> 
> Signed-off-by: Sumit Garg 

I'm entirely sure which requirements or conventions we are following for
adding device trees directly to U-Boot instead of Linux. My understanding
is that the goal is to get U-Boot DTs as close as possible to the
upstream Linux DTs, so I effectively looked at this as if it were
submitted to linux-arm-msm. I think most of my comments should be
trivial to fix anyway without much effort. :-)

With the comments fixed it would be likely also easy to get it in
upstream in Linux, so I wonder if it's worth first adding it here in
U-Boot (I know you discussed this on v1 already a bit).

> ---
>  arch/arm/dts/apq8016-hmibsc.dts| 496 +
>  board/schneider/hmibsc/MAINTAINERS |   6 +
>  configs/hmibsc_defconfig   |  87 +
>  doc/board/index.rst|   1 +
>  doc/board/schneider/hmibsc.rst |  45 +++
>  doc/board/schneider/index.rst  |   9 +
>  include/configs/hmibsc.h   |  57 
>  7 files changed, 701 insertions(+)
>  create mode 100644 arch/arm/dts/apq8016-hmibsc.dts
>  create mode 100644 board/schneider/hmibsc/MAINTAINERS
>  create mode 100644 configs/hmibsc_defconfig
>  create mode 100644 doc/board/schneider/hmibsc.rst
>  create mode 100644 doc/board/schneider/index.rst
>  create mode 100644 include/configs/hmibsc.h
> 
> diff --git a/arch/arm/dts/apq8016-hmibsc.dts b/arch/arm/dts/apq8016-hmibsc.dts
> new file mode 100644
> index 000..490ab5fd2fa
> --- /dev/null
> +++ b/arch/arm/dts/apq8016-hmibsc.dts
> @@ -0,0 +1,496 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2024, Linaro Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "msm8916-pm8916.dtsi"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "Schneider Electric HMIBSC Board";
> + compatible = "qcom,apq8016-hmibsc", "qcom,apq8016";

A Schneider Electric specific compatible would be likely more accurate,
since I assume this board wasn't designed by Qualcomm?

I would personally also prefer to use the "apq8016--.dts"
naming convention that we typically use for smartphones/tablets
upstream, although you can also keep it as-is since e.g. apq8039-t2.dts
is also named without vendor.

> +
> + aliases {
> + serial0 = _uart1;
> + serial1 = _uart2;
> + usid0 = _0;
> + i2c1 = _i2c6;
> + i2c3 = _i2c4;
> + i2c4 = _i2c3;
> + spi0 = _spi5;

You might want to add mmcX aliases here to ensure consistent naming of
eMMC and SD card (this used to be in msm8916.dtsi but not anymore).

> [...]
> +_i2c6 {
> + status = "okay";
> + label = "I2C1";
> +
> + rtc1: s35390a@30 {

rtc@

> + compatible = "sii,s35390a";
> + reg = <0x30>;
> + };
> +
> + eeprom1: 24c256@50 {

eeprom@

> + compatible = "atmel,24c256";
> + reg = <0x50>;
> + };
> +};
> +
> +_i2c3 {

i2c3 should come before i2c6 (sorted alphabetically)

> + status = "okay";
> + label = "I2C4";
> +
> + eeprom: 24c32@50 {

eeprom@

> + compatible = "onsemi,24c32";
> + reg = <0x50>;
> + };
> +};
> +
> [...]
> +
> +_0 {
> + pon@800 {
> + pwrkey {
> + status = "okay";
> + interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;

This line would really benefit from a comment that explains what exactly
it does and why this is done. :)

It looks like you are redefining the pwrkey with the resin interrupt.
I guess your goal is to have KEY_POWER assigned to the resin pin?
In that case, I think it would be cleaner to describe this using:

_resin {
status = "okay";
linux,code = ;
};

and leave the pwrkey node alone (or perhaps disable it if it causes
trouble).

Aside from the confusion, I think overriding only the interrupt of the
pwrkey will also misbehave in unexpected ways since e.g. the Linux
pm8941-pwrkey driver will still write the configured debounce time and
pull up to the pwrkey registers, and not to the resin ones.

> + };
> + };
> +};
> +
> [...]
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_rs232_high _rs232_low>;
> +
> + sdc2_cd_default: sdc2-cd-default-state {
> + pins = "gpio38";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + usb_id_default: usb-id-default-state {
> +

Re: [PATCH v2 2/5] apq8016: Add support for UART1 clocks and pinmux

[Stephan Gerhold]

On Mon, Mar 11, 2024 at 12:27:11PM +, Caleb Connolly wrote:
> On 11/03/2024 11:10, Sumit Garg wrote:
> > SE HMIBSC board uses UART1 as the main debug console, so add
> > corresponding clocks and pinmux support. Along with that update
> > instructions to enable clocks for debug UART support.
> > 
> > Signed-off-by: Sumit Garg 
> > ---
> >  drivers/clk/qcom/clock-apq8016.c   | 50 +-
> >  drivers/pinctrl/qcom/pinctrl-apq8016.c |  1 +
> >  drivers/serial/serial_msm.c|  6 ++--
> >  3 files changed, 47 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/clk/qcom/clock-apq8016.c 
> > b/drivers/clk/qcom/clock-apq8016.c
> > index e6647f7c41d..a620a10a520 100644
> > --- a/drivers/clk/qcom/clock-apq8016.c
> > +++ b/drivers/clk/qcom/clock-apq8016.c
> > @@ -43,6 +43,14 @@
> >  #define BLSP1_UART2_APPS_N (0x3040)
> >  #define BLSP1_UART2_APPS_D (0x3044)
> >  
> > +#define BLSP1_UART1_BCR(0x2038)
> > +#define BLSP1_UART1_APPS_CBCR  (0x203C)
> > +#define BLSP1_UART1_APPS_CMD_RCGR  (0x2044)
> > +#define BLSP1_UART1_APPS_CFG_RCGR  (0x2048)
> > +#define BLSP1_UART1_APPS_M (0x204C)
> > +#define BLSP1_UART1_APPS_N (0x2050)
> > +#define BLSP1_UART1_APPS_D (0x2054)
> > +
> >  /* GPLL0 clock control registers */
> >  #define GPLL0_STATUS_ACTIVE BIT(17)
> >  
> > [...]
> > @@ -94,6 +102,33 @@ static int clk_init_sdc(struct msm_clk_priv *priv, int 
> > slot, uint rate)
> > return rate;
> >  }
> >  
> > +static const struct bcr_regs uart1_regs = {
> > +   .cfg_rcgr = BLSP1_UART1_APPS_CFG_RCGR,
> > +   .cmd_rcgr = BLSP1_UART1_APPS_CMD_RCGR,
> > +   .M = BLSP1_UART1_APPS_M,
> > +   .N = BLSP1_UART1_APPS_N,
> > +   .D = BLSP1_UART1_APPS_D,
> > +};
> > +
> > +/* UART: 115200 */
> > +static int apq8016_clk_init_uart1(phys_addr_t base)
> 
> I know we're still dealing with some tech debt here, but I'm not a big
> fan of this approach. I notice that the RCG and CBCR registers are all
> offset by exactly 0xff0 between UART1 and UART2, what about adding a
> second "index" parameter to apq8016_clk_init_uart() and then offsetting
> the addresses by (0xff0 * index)?
> 

This would work for MSM8916 where you have just two UARTs, but it might
be misleading since the UART blocks are actually separated in 4 KiB
(0x1000) blocks and not offset by 0xff0. UART2 is a special case that
has different offsets within the 4 KiB block, for some weird reason.

If you want to calculate the register offsets properly you would need
special handling for UART2, e.g. I have the following (admittedly rather
ugly) define in the TF-A port for MSM8916 and similar [1]:

#define GCC_BLSP1_UART_APPS_CBCR(n) (GCC_BASE + \
(((n) == 2) ? (0x0302c) : (0x0203c + (((n) - 1) * 0x1000

where n is the UART number (here 1 or 2). As a different example,
MDM9607 has 5 UARTs (1 to 5) and there only UART2 is special-cased,
while all others follow the standard offset with 0x1000 offset.

Thanks,
Stephan

[1]: 
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/qti/msm8916/msm8916_setup.c?h=v2.10#n40

Re: [PATCH 8/8] board: add support for Qualcomm SA8155P-ADP board

[Stephan Gerhold]

On Thu, Feb 29, 2024 at 02:21:09PM +, Volodymyr Babchuk wrote:
> SA8155P Automotive Development Platform is Qualcomm SA8155-based board
> for developers. The nice thing that it has unlocked loaders with test
> keys support, which means that U-Boot for this platform can be
> launched at earlier stages.
> 
> This patch adds basic board support with only serial port and
> networking operation. I am using U-Boot to ease up Xen porting onto
> this board, so I am mostly interesting in booting U-Boot in EL2. But
> more conventional setup with Android boot image is supported as well.
> 
> Signed-off-by: Volodymyr Babchuk 
> 
> ---
> 
>  arch/arm/dts/sa8155p-adp-u-boot.dtsi | 30 
>  arch/arm/mach-snapdragon/Kconfig | 14 
>  arch/arm/mach-snapdragon/Makefile|  2 +
>  arch/arm/mach-snapdragon/init_sa8155p.c  | 30 
>  arch/arm/mach-snapdragon/sysmap-sm8150.c | 31 
>  board/qualcomm/sa8155p-adp/Kconfig   | 12 +++
>  board/qualcomm/sa8155p-adp/MAINTAINERS   |  6 ++
>  configs/sa8155p_adp_defconfig| 33 +
>  doc/board/qualcomm/index.rst |  1 +
>  doc/board/qualcomm/sa8155p-adp.rst   | 94 
>  include/configs/sa8155p_adp.h| 25 +++
>  11 files changed, 278 insertions(+)
>  create mode 100644 arch/arm/dts/sa8155p-adp-u-boot.dtsi
>  create mode 100644 arch/arm/mach-snapdragon/init_sa8155p.c
>  create mode 100644 arch/arm/mach-snapdragon/sysmap-sm8150.c
>  create mode 100644 board/qualcomm/sa8155p-adp/Kconfig
>  create mode 100644 board/qualcomm/sa8155p-adp/MAINTAINERS
>  create mode 100644 configs/sa8155p_adp_defconfig
>  create mode 100644 doc/board/qualcomm/sa8155p-adp.rst
>  create mode 100644 include/configs/sa8155p_adp.h
> 
> [...]
> diff --git a/doc/board/qualcomm/sa8155p-adp.rst 
> b/doc/board/qualcomm/sa8155p-adp.rst
> new file mode 100644
> index 00..cff68cd55f
> --- /dev/null
> +++ b/doc/board/qualcomm/sa8155p-adp.rst
> @@ -0,0 +1,94 @@
> +.. SPDX-License-Identifier: BSD-3-Clause
> +.. sectionauthor:: Volodymyr Babchuk 
> +
> +SA8155P Automotive Development Platform
> +===
> +
> +About
> +-
> +This document describes the information about SA8155P Automotive
> +Development Platform aka SA8155P-ADP.
> +
> +Currently U-Boot can be booted either as Android boot image, or in EL2
> +mode, instead of hypervisor image. In the latter case it is possible
> +to use U-Boot to either boot Linux with KVM support or to boot Xen
> +Hypervisor on this board.
> +
> +Supported HW modules
> +
> +Port for this board is in early development state. Right now U-Boot
> +supports serial console and networking. No USB/fastboot or UFS support
> +yet. So it is not possible to save environment variables as
> +well. Nevertheless this is enough for development as user can download
> +all required images via TFTP.
> +
> +Installation
> +
> +Build
> +^
> +Setup ``CROSS_COMPILE`` for aarch64 and build U-Boot for your board::
> +
> + $ export CROSS_COMPILE=
> + $ make sa8155p_adp_defconfig
> + $ make
> +
> +This will build ``u-boot.bin`` in the configured output directory.
> +
> +Boot in EL1 mode instead of Android boot image
> +^^
> +
> +Create a dummy ramdisk image:::
> +
> + $ echo "This is not a ramdisk" > ramdisk.img
> +
> +Compress u-boot binary:::
> +
> + $ gzip -c u-boot.bin > u-boot.bin.gz
> +
> +Append DTB again (binary we use already have DTB embedded in, but
> +Android boot image format requires another DTB at the end of the
> +archive):::
> +
> + $ cat u-boot.bin.gz u-boot.dtb > u-boot.bin.gz-dtb
> +
> +Now we've got everything to build android boot image:::
> +
> + $ mkbootimg --kernel u-boot.bin.gz-dtb \
> + --ramdisk ramdisk.img --pagesize 4096 \
> + --base 0x8000 -o boot.img
> +
> +Finally you can flash new boot image with fastboot:::
> +
> + $ fastboot flash boot boot.img
> +
> +Or just boot U-Boot without flashing anything:::
> +
> + $ fastboot boot boot.img
> +
> +Boot in EL2 mode instead of Qualcomm's hypervisor stub
> +^^
> +This approach ensures that U-Boot is booted in EL2 and it is possible
> +to run virtualization software (like Xen or KVM) on the board. You
> +must understand that this approach breaks Qualcomm's boot chain. You
> +will not be able to call all subsequent loaders, so you will not be
> +able to use fastboot for example. Use this approach only if you want
> +to experiment with virtualization on SA8155P-ADP.
> +
> +We need to create ELF file from the u-boot binary. We can't use
> +existing U-Boot ELF, because it does not include appended DTB
> +file. Easiest way to do this is to use ``create_elf.py`` from the
> +following repository: `qtestsign(lorc)
> +`_: ::
> +
> + $ python ../qtestsign/create_elf.py 

Re: [PATCH 0/8] Add support for Qualcomm SA8155-ADP board

[Stephan Gerhold]

On Fri, Mar 01, 2024 at 06:25:39PM +, Volodymyr Babchuk wrote:
> Caleb Connolly  writes:
> > On 29/02/2024 14:21, Volodymyr Babchuk wrote:
> >> This patch series adds support for Qualcomm SA8155-ADP development
> >> board. Main motivation for this series is to allow running
> >> virtualization software on this board and U-Boot is a good way to
> >> break Qualcomm's boot chain at EL2 with more convenient ways for
> >> uploading and running the code. With this patches applied it is
> >> possible to upload and run Xen on this board. KVM probably should work
> >> too.
> >
> > This is really cool! I've experimented with this on SDM845 and SM8250
> > but never really did anything with it... I'd love to take a look at your
> > Xen branch?
> 
> Honestly, there is nothing to look at right now. I just implemented
> early printk serial driver for the qcom, made hacks to the device tree
> and trying to boot Dom0. I already expecting issues with the GPU,
> because it has own SMMU without virtualization support and Xen already
> complains about it. So I had to remove it from the DTS for a time being.
> 

Did you enable all the clocks/power domains/etc for the GPU SMMU? If I
remember correctly it is off by default and all registers read as
zeroes. The SMMU driver could easily get confused about the capabilities
of the SMMU (e.g. the stage 2/virtualization support) if all the ID
registers read as zeroes.

Thanks,
Stephan

Re: [PATCH 18/21] dts: msm8916: import DT from Linux

[Stephan Gerhold]

On Thu, Dec 07, 2023 at 07:11:02PM +, Caleb Connolly wrote:
> On 21/11/2023 19:21, Stephan Gerhold wrote:
> > On Tue, Nov 21, 2023 at 05:09:41PM +, Caleb Connolly wrote:
> >> Import the msm8916 devicetree from Linux and adjust the dragonboard410c
> >> devicetree to use it.
> >>
> > 
> > Can you add a note here from which Linux version you took the DT?
> > 
> > It seems quite old, the msm8916-pm8916.dtsi doesn't exist anymore
> > upstream since v6.5. Would be nice to bring it up to date (I don't have
> > any more cleanup planned at the moment, so the current state upstream
> > will probably stay mostly as-is).
> 
> That file still exists on 6.7-rc4, as far as I can tell?

Sorry, I meant msm8916-pins.dtsi :') That one doesn't exist anymore.

Thanks,
Stephan

Re: [PATCH 18/21] dts: msm8916: import DT from Linux

[Stephan Gerhold]

On Tue, Nov 21, 2023 at 05:09:41PM +, Caleb Connolly wrote:
> Import the msm8916 devicetree from Linux and adjust the dragonboard410c
> devicetree to use it.
> 

Can you add a note here from which Linux version you took the DT?

It seems quite old, the msm8916-pm8916.dtsi doesn't exist anymore
upstream since v6.5. Would be nice to bring it up to date (I don't have
any more cleanup planned at the moment, so the current state upstream
will probably stay mostly as-is).

>From a quick look I think U-Boot shouldn't be concerned much about the
changes, you might just need to do some trivial renames:

   -> 
  _uart2 -> _uart2

Thanks a lot for working on this!

Stephan

> Signed-off-by: Caleb Connolly 
> ---
>  arch/arm/dts/dragonboard410c-uboot.dtsi |   44 -
>  arch/arm/dts/dragonboard410c.dts|  198 +-
>  arch/arm/dts/msm8916-pins.dtsi  |  582 ++
>  arch/arm/dts/msm8916-pm8916.dtsi|   76 +
>  arch/arm/dts/msm8916.dtsi   | 2194 
> +++
>  arch/arm/dts/pm8916.dtsi|  183 ++
>  include/dt-bindings/arm/coresight-cti-dt.h  |   37 +
>  include/dt-bindings/clock/qcom,rpmcc.h  |  174 ++
>  include/dt-bindings/interconnect/qcom,msm8916.h |  100 ++
>  include/dt-bindings/reset/qcom,gcc-msm8916.h|  100 ++
>  10 files changed, 3484 insertions(+), 204 deletions(-)
> 
> diff --git a/arch/arm/dts/dragonboard410c-uboot.dtsi 
> b/arch/arm/dts/dragonboard410c-uboot.dtsi
> deleted file mode 100644
> index cec64bf80f99..
> --- a/arch/arm/dts/dragonboard410c-uboot.dtsi
> +++ /dev/null
> @@ -1,44 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * U-Boot addition to handle Dragonboard 410c pins
> - *
> - * (C) Copyright 2015 Mateusz Kulikowski 
> - */
> -
> -/ {
> -
> - smem {
> - bootph-all;
> - };
> -
> - soc {
> - bootph-all;
> -
> - pinctrl@100 {
> - bootph-all;
> -
> - uart {
> - bootph-all;
> - };
> - };
> -
> - qcom,gcc@180 {
> - bootph-all;
> - };
> -
> - serial@78b {
> - bootph-all;
> - };
> - };
> -};
> -
> -
> -_gpios {
> - usb_hub_reset_pm {
> - gpios = <_gpios 2 0>;
> - };
> -
> - usb_sw_sel_pm {
> - gpios = <_gpios 3 0>;
> - };
> -};
> diff --git a/arch/arm/dts/dragonboard410c.dts 
> b/arch/arm/dts/dragonboard410c.dts
> index a42b68fee8c0..8933c64e56e5 100644
> --- a/arch/arm/dts/dragonboard410c.dts
> +++ b/arch/arm/dts/dragonboard410c.dts
> @@ -7,193 +7,40 @@
>  
>  /dts-v1/;
>  
> -#include "skeleton64.dtsi"
>  #include 
>  
> +#include "msm8916-pm8916.dtsi"
> +
>  / {
>   model = "Qualcomm Technologies, Inc. Dragonboard 410c";
>   compatible = "qcom,apq8016-sbc", "qcom,apq8016";
>   qcom,msm-id = <0xce 0x0 0xf8 0x0 0xf9 0x0 0xfa 0x0 0xf7 0x0>;
>   qcom,board-id = <0x10018 0x0>;
> - #address-cells = <0x2>;
> - #size-cells = <0x2>;
>  
>   aliases {
>   usb0 = "/soc/ehci@78d9000";
> + serial0 = _uart2;
>   };
>  
> - memory {
> + memory@8000 {
>   device_type = "memory";
>   reg = <0 0x8000 0 0x3da0>;
>   };
>  
> - reserved-memory {
> - #address-cells = <2>;
> - #size-cells = <2>;
> - ranges;
> -
> - smem_mem: smem_region@8630 {
> - reg = <0x0 0x8630 0x0 0x10>;
> - no-map;
> - };
> - };
> -
>   chosen {
>   stdout-path = "/soc/serial@78b";
>   };
>  
> - smem {
> - compatible = "qcom,smem";
> - memory-region = <_mem>;
> - qcom,rpm-msg-ram = <_msg_ram>;
> - };
> -
> - soc {
> - #address-cells = <0x1>;
> - #size-cells = <0x1>;
> - ranges = <0x0 0x0 0x0 0x>;
> - compatible = "simple-bus";
> -
> - rpm_msg_ram: memory@6 {
> - compatible = "qcom,rpm-msg-ram";
> - reg = <0x6 0x8000>;
> - };
> -
> - soc_gpios: pinctrl@100 {
> - compatible = "qcom,msm8916-pinctrl";
> - reg = <0x100 0x40>;
> - gpio-controller;
> - gpio-count = <122>;
> - gpio-bank-name="soc";
> - #gpio-cells = <2>;
> -
> - blsp1_uart: uart {
> - function = "blsp1_uart";
> - pins = "GPIO_4", "GPIO_5";
> - drive-strength = <8>;
> - bias-disable;
> - };
> - };
> - clkc: qcom,gcc@180 

Re: [PATCH v2 3/5] gpio: qcom_pmic: fix support for upstream DT

[Stephan Gerhold]

On Wed, Nov 08, 2023 at 04:20:55PM +, Caleb Connolly wrote:
> Linux devicetrees use the "gpio-ranges" property, add support for
> parsing it instead of "gpio-count" so that upstream DTs can be used with
> U-Boot.
> 
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/gpio/qcom_pmic_gpio.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
> index 7b83c67fa464..647d4143ce14 100644
> --- a/drivers/gpio/qcom_pmic_gpio.c
> +++ b/drivers/gpio/qcom_pmic_gpio.c
> @@ -245,11 +245,37 @@ static int qcom_gpio_probe(struct udevice *dev)
>   return 0;
>  }
>  
> +/*
> + * Parse basic GPIO count specified via the gpio-ranges property
> + * as specified in Linux devicetrees
> + * Returns < 0 on error, otherwise gpio count
> + */
> +static int qcom_gpio_of_parse_ranges(struct udevice *dev)
> +{
> + int ret;
> + struct ofnode_phandle_args args;
> +
> + ret = ofnode_parse_phandle_with_args(dev_ofnode(dev), "gpio-ranges",
> +  NULL, 3, 0, );
> + if (ret)
> + return log_msg_ret("gpio-ranges", ret);
> +
> + return args.args[2];
> +}
> +
>  static int qcom_gpio_of_to_plat(struct udevice *dev)
>  {
>   struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> + int ret;
>  
>   uc_priv->gpio_count = dev_read_u32_default(dev, "gpio-count", 0);
> + if (!uc_priv->gpio_count) {
> + ret = qcom_gpio_of_parse_ranges(dev);
> + if (ret > 0)
> + uc_priv->gpio_count = ret;
> + else
> + printf("gpio-ranges error: %d\n", ret);
> + }

I would drop support for the non-standard gpio-count and instead adjust
the existing device trees to use gpio-ranges (copied from the upstream
DTs).

>   uc_priv->bank_name = dev_read_string(dev, "gpio-bank-name");
>   if (uc_priv->bank_name == NULL)
>   uc_priv->bank_name = "qcom_pmic";
> 

Maybe you can replace this property as well while you're at it. Perhaps
the default fallback name is sufficient. Alternatively one could
obtain the actual PMIC name from the compatible or similar.

Thanks,
Stephan

Re: [PATCH v2 2/5] gpio: qcom_pmic: rework pwrkey driver into a button driver

[Stephan Gerhold]

On Wed, Nov 08, 2023 at 04:20:54PM +, Caleb Connolly wrote:
> The power and resin keys were implemented as GPIOs here, but their only
> use would be as buttons. Avoid the additional layer of introspection and
> rework this driver into a button driver.
> 
> While we're here, replace the "qcom,pm8998-pwrkey" compatible with
> "qcom,pm8941-pwrkey" to match upstream (Linux).
> 
> The dragonboard410c and 820c boards are adjusted to benefit from this
> change too, simplify their custom board init code.
> 
> Signed-off-by: Caleb Connolly 
> ---
>  MAINTAINERS  |   1 +
>  arch/arm/dts/dragonboard410c-uboot.dtsi  |  14 +-
>  arch/arm/dts/dragonboard410c.dts |  22 ++-
>  arch/arm/dts/dragonboard820c-uboot.dtsi  |  15 +--
>  arch/arm/dts/dragonboard820c.dts |  23 +++-
>  arch/arm/dts/dragonboard845c-uboot.dtsi  |  11 --
>  arch/arm/dts/dragonboard845c.dts |   4 +
>  arch/arm/dts/sdm845.dtsi |  23 +++-
>  arch/arm/dts/starqltechn.dts |  20 +--
>  arch/arm/mach-snapdragon/Kconfig |   3 +
>  arch/arm/mach-snapdragon/init_sdm845.c   |  45 ++-
>  board/qualcomm/dragonboard410c/dragonboard410c.c |  31 ++---
>  board/qualcomm/dragonboard820c/dragonboard820c.c |  29 ++--
>  drivers/button/Kconfig   |   9 ++
>  drivers/button/Makefile  |   1 +
>  drivers/button/button-qcom-pmic.c| 165 
> +++
>  drivers/gpio/Kconfig |   3 +-
>  drivers/gpio/qcom_pmic_gpio.c| 104 --
>  18 files changed, 275 insertions(+), 248 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f6d63c8ab563..8cd102eaa070 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -572,6 +572,7 @@ M:Neil Armstrong 
>  R:   Sumit Garg 
>  S:   Maintained
>  F:   arch/arm/mach-snapdragon/
> +F:   drivers/button/button-qcom-pmic.c
>  F:   drivers/clk/qcom/
>  F:   drivers/gpio/msm_gpio.c
>  F:   drivers/mmc/msm_sdhci.c
> diff --git a/arch/arm/dts/dragonboard410c-uboot.dtsi 
> b/arch/arm/dts/dragonboard410c-uboot.dtsi
> index 3b0bd0ed0a1b..39b03a30702c 100644
> --- a/arch/arm/dts/dragonboard410c-uboot.dtsi
> +++ b/arch/arm/dts/dragonboard410c-uboot.dtsi
> @@ -5,6 +5,9 @@
>   * (C) Copyright 2015 Mateusz Kulikowski 
>   */
>  
> +#include 
> +#include 
> +

You can drop this again now I guess?

>  / {
>  
>   smem {
> @@ -42,14 +45,3 @@
>   gpios = <_gpios 3 0>;
>   };
>  };
> -
> -
> -_pon {
> - key_vol_down {
> - gpios = <_pon 1 0>;
> - };
> -
> - key_power {
> - gpios = <_pon 0 0>;
> - };
> -};
> [...]
> diff --git a/arch/arm/dts/dragonboard820c-uboot.dtsi 
> b/arch/arm/dts/dragonboard820c-uboot.dtsi
> index 457728a43ecb..693c0e5efcc4 100644
> --- a/arch/arm/dts/dragonboard820c-uboot.dtsi
> +++ b/arch/arm/dts/dragonboard820c-uboot.dtsi
> @@ -5,6 +5,9 @@
>   * (C) Copyright 2017 Jorge Ramirez-Ortiz 
>   */
>  
> +#include 
> +#include 
> +

Same here.

Thanks,
Stephan

Re: [PATCH 2/5] gpio: qcom_pmic: rework pwrkey driver into a button driver

[Stephan Gerhold]

On Mon, Nov 06, 2023 at 08:57:30PM +, Caleb Connolly wrote:
> The power and resin keys were implemented as GPIOs here, but their only
> use would be as buttons. Avoid the additional layer of introspection and
> rework this driver into a button driver.
> 
> While we're here, replace the "qcom,pm8998-pwrkey" compatible with
> "qcom,pm8941-pwrkey" to match upstream (Linux).
> 
> The dragonboard410c and 820c boards are adjusted to benefit from this
> change too, simplify their custom board init code.
> 
> Signed-off-by: Caleb Connolly 

Thanks a lot for working on bringing the Qualcomm DTs in U-Boot closer
to Linux upstream! I agree that modelling the pwr/resin keys is better
than exposing tham as GPIOs.

I'm a bit confused about the actual diff in this patch series though.
Did you perhaps forget to make some changes you had planned or sent the
wrong version?

In particular:

 - You talk about replacing the custom "qcom,pm8998-pwrkey" compatible
   with "qcom,pm8941-pwrkey" to match upstream, but don't seem to adjust
   the users (sdm845.dtsi)?

 - sdm845.dtsi also uses GPIOs for PON, but you only update DB410c and
   DB820c. Isn't SDM845 the platform you're testing on?

Some more comments below.

> ---
>  arch/arm/dts/dragonboard410c-uboot.dtsi  |  11 +-
>  arch/arm/dts/dragonboard820c-uboot.dtsi  |   9 +-
>  arch/arm/dts/dragonboard820c.dts |   3 -
>  board/qualcomm/dragonboard410c/dragonboard410c.c |  29 ++--
>  board/qualcomm/dragonboard820c/dragonboard820c.c |  29 ++--
>  drivers/gpio/Kconfig |   3 +-
>  drivers/gpio/qcom_pmic_gpio.c| 161 
> +++
>  7 files changed, 139 insertions(+), 106 deletions(-)
> 
> diff --git a/arch/arm/dts/dragonboard410c-uboot.dtsi 
> b/arch/arm/dts/dragonboard410c-uboot.dtsi
> index 3b0bd0ed0a1b..c96f1fcc8930 100644
> --- a/arch/arm/dts/dragonboard410c-uboot.dtsi
> +++ b/arch/arm/dts/dragonboard410c-uboot.dtsi
> @@ -5,6 +5,9 @@
>   * (C) Copyright 2015 Mateusz Kulikowski 
>   */
>  
> +#include 
> +#include 
> +
>  / {
>  
>   smem {
> @@ -46,10 +49,14 @@
>  
>  _pon {
>   key_vol_down {
> - gpios = <_pon 1 0>;
> + interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
> + linux,code = ;
> + label = "key_vol_down";
>   };
>  
>   key_power {
> - gpios = <_pon 0 0>;
> + interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
> + linux,code = ;
> + label = "key_power";
>   };
>  };

The upstream Linux DT looks like this:

pon@800 {
compatible = "qcom,pm8916-pon";
reg = <0x800>;
mode-bootloader = <0x2>;
mode-recovery = <0x1>;

pwrkey {
compatible = "qcom,pm8941-pwrkey";
interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
debounce = <15625>;
bias-pull-up;
linux,code = ;
};

pm8916_resin: resin {
compatible = "qcom,pm8941-resin";
interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
debounce = <15625>;
bias-pull-up;
linux,code = ;
};
};

The new version you add is closer to upstream, but you also add a new
custom property called "label". You could just derive a unique label
from the node name ("pwrkey" vs "resin").

For looking up the buttons in the DB410c/DB820c couldn't you just loop
over all buttons and find a suitable one based on button_get_code()?

I think having different *linux*,code values (KEY_POWER vs KEY_ENTER and
KEY_DOWN vs KEY_VOLUME_DOWN) is also a bit strange. If U-Boot wants
different key codes it's kind of not the Linux code anymore, might as
well call it "u-boot,code" then. :-)

If KEY_POWER => KEY_ENTER and KEY_VOLUME_DOWN => KEY_DOWN is more useful
for U-Boot maybe that mapping could be done automatically in the code,
without having to change the real hardware description in the DT.

> diff --git a/arch/arm/dts/dragonboard820c.dts 
> b/arch/arm/dts/dragonboard820c.dts
> index ad201d48749c..7db0cc9d64cc 100644
> --- a/arch/arm/dts/dragonboard820c.dts
> +++ b/arch/arm/dts/dragonboard820c.dts
> @@ -112,9 +112,6 @@
>   pm8994_pon: pm8994_pon@800 {
>   compatible = "qcom,pm8994-pwrkey";
>   reg = <0x800 0x96>;
> - #gpio-cells = <2>;
> - gpio-controller;
> - gpio-bank-name="pm8994_key.";
>   };

Shouldn't we do the same 

Re: [PATCH 13/14] i2c: Add support for Qualcomm I2C driver

[Stephan Gerhold]

On Fri, Jan 20, 2023 at 05:55:35PM +0530, Sumit Garg wrote:
> On Fri, 20 Jan 2023 at 14:16, Heiko Schocher  wrote:
> > On 20.01.23 08:17, Sumit Garg wrote:
> > > Add support for Qualcomm I2C QUP driver which is inspired from
> > > corresponding driver in Linux: drivers/i2c/busses/i2c-qup.c.
> > >
> > > Currently this driver only support FIFO polling mode which is sufficient
> > > to support devices like eeprom, rtc etc.
> > >
> > > Co-developed-by: Mike Worsfold 
> > > Signed-off-by: Mike Worsfold 
> > > Signed-off-by: Sumit Garg 
> > > ---
> > >  drivers/i2c/Kconfig   |   6 +
> > >  drivers/i2c/Makefile  |   1 +
> > >  drivers/i2c/qup_i2c.c | 592 ++
> > >  3 files changed, 599 insertions(+)
> > >  create mode 100644 drivers/i2c/qup_i2c.c
> > >
> > > diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
> > > index 76e19918aa..2a1d36f91a 100644
> > > --- a/drivers/i2c/Kconfig
> > > +++ b/drivers/i2c/Kconfig
> > > @@ -635,6 +635,12 @@ config SYS_I2C_TEGRA
> > >   help
> > > Support for NVIDIA I2C controller available in Tegra SoCs.
> > >
> > > +config SYS_I2C_QUP
> > > + bool "Qualcomm I2C controller"
> > > + depends on ARCH_SNAPDRAGON
> > > + help
> > > +   Support for Qualcomm I2C controller.
> [...]
> > and may you can ad here some more infos
> > like link to datasheet?
> >
> 
> I will try to put more info here. However, I don't think the datasheet
> is available publically. This driver is inspired from its Linux
> counterpart only.
> 

FWIW: The I2C/SPI QUP controller is publicly documented in the
Snapdragon 410E (APQ8016E) Technical Reference Manual [1],
chapter "6.1 Qualcomm Universal Peripherals Engine (QUP)".

Stephan

[1]: 
https://developer.qualcomm.com/download/sd410/snapdragon-410e-technical-reference-manual.pdf

Re: [PATCH] arm: dts: qcom: Sync pinctrl DT nodes with Linux bindings

[Stephan Gerhold]

On Fri, Jul 15, 2022 at 03:21:45PM +0530, Sumit Garg wrote:
> On Thu, 14 Jul 2022 at 23:45, Stephan Gerhold  wrote:
> > On Thu, Jul 14, 2022 at 01:03:37PM +0530, Sumit Garg wrote:
> > > This is based on top of mine other patch-set [1]. Although, I have
> > > tested it on db845c and qcs404-evb but I would like other board
> > > maintainers to test it as well.
> > >
> > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=309135
> >
> > If possible I would prefer to introduce the QCS404 platform with a clean
> > DT (i.e. qcs404.dtsi imported from the Linux kernel, instead of adding
> > the custom qcs404-evb.dts and then cleaning it up). This patch would
> > need to come before the QCS404 addition then.
> >
> 
> Sorry but it's unfair to block new SoCs/boards support until all the
> existing mess around DT is cleaned up in Qcom specific u-boot drivers.
> This patch is a good example to demonstrate that all corresponding
> boards DT need to be fixed as well which requires testing. And I don't
> even have access to starqltechn, ipq4019 based board and db820c.
> 

Sorry, I thought this is the only patch you need to use the Linux QCS404
DT as-is (maybe I misunderstood). I'm not expecting that you clean up
all existing boards first of course. :) I just thought it would be nice
to start clean for QCS404 immediately if this is the only patch you need.

This patch looks simple enough for me if we test it on a couple of
boards, the pinctrl setup is fairly similar across all of them. However,
I wrote this before the comments with the additional "reg"s below. If we
need to add handling for that as well the patch will need to become a
bit larger of course, maybe too large to prepend it to your QCS404
series.

> AFAIK, it's not a requirement yet but a recommendation at this stage
> to import DT directly from Linux kernel and work with it. But I would
> be very happy to work in this direction to make Qcom SoCs/boards DT
> compliant. So I would request the merge of new boards support and then
> we can follow up with patches like this one.
> 

Thanks! I'm not familiar with the requirements so I'll leave this up to
Tom to decide. :)

> [...]
> > > diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
> > > index 4f0ae20bdb..09687e1fd3 100644
> > > --- a/arch/arm/dts/qcs404-evb.dts
> > > +++ b/arch/arm/dts/qcs404-evb.dts
> > > @@ -38,7 +38,7 @@
> > >   compatible = "simple-bus";
> > >
> > >   pinctrl_north@130 {
> > > - compatible = "qcom,tlmm-qcs404";
> > > + compatible = "qcom,qcs404-pinctrl";
> > >   reg = <0x130 0x20>;
> >
> > The Linux node still looks a bit different (from qcs404.dtsi):
> >
> > tlmm: pinctrl@100 {
> > compatible = "qcom,qcs404-pinctrl";
> > reg = <0x0100 0x20>,
> >   <0x0130 0x20>,
> >   <0x07b0 0x20>;
> > reg-names = "south", "north", "east";
> >
> > I guess we'll need to fetch the "north" region from it (if that's what
> > you need)?
> 
> This is another example of a shortcut already used by the u-boot
> pinctrl driver (arch/arm/mach-snapdragon/pinctrl-snapdragon.c). You
> can find another user here (arch/arm/dts/sdm845.dtsi). So the pinctrl
> drivers need to be converted to a format supported by Linux kernel.
> Also, the pinctrl drivers need to be moved to "drivers/pinctrl/qcom/"
> dir instead.
> 

Right. FYI, there is started work on one possible solution for this
here: https://github.com/minlexx/u-boot-2nd/commits/660

Basically Alexey (now in Cc) and Michael ported parts of the Linux
pinctrl-msm driver to U-Boot, in a way that you can mostly just copy the
platform specific definitions as-is. The additional memory regions are
handled correctly there AFAICT.

The code size overall is quite a bit higher of course, but I think this
is not a problem for any of the Qualcomm boards in U-Boot. The ease of
porting and flexibility should outweigh the cost here, I think.

Thanks,
Stephan

Re: [PATCH v3 9/9] board: qualcomm: Add support for QCS404 EVB

[Stephan Gerhold]

On Thu, Jul 14, 2022 at 01:10:45PM +0530, Sumit Garg wrote:
> On Thu, 14 Jul 2022 at 01:02, Stephan Gerhold  wrote:
> > Can you check how hard it would be to reuse the upstream QCS404 DT?
> >
> 
> It turned out to be patch [1] on top of this patch-set. Please help me
> to test it on boards you have access to.
> 
> [1] 
> https://patchwork.ozlabs.org/project/uboot/patch/20220714073337.2298978-1-sumit.g...@linaro.org/
> 

Thanks! Do you happen to have time to check the other custom bindings in
SDM845 as well? I see two other differences there in addition to the
pinctrl:

  1. "qcom,msm-geni-uart": Linux has an additional "qcom,geni-se-qup"
 node around that.

  2. The "qcom,pm8998-pwrkey" should be in an additional
 "qcom,pm8998-pon" container node and then called
 "qcom,pm8941-pwrkey".

 Also, in U-Boot the keys are modelled as GPIOs which is a bit
 strange (I don't think they can be set to output mode for example).
 But it might be fine to keep that in the -u-boot.dtsi part for now.

I would be happy to investigate and test the remaining DB410c-specific
parts (e.g. USB there). Cleaning up the DT differences has been on my
TODO list for quite some time but I never got to it, sadly...

Thanks!
Stephan

Re: [PATCH] arm: dts: qcom: Sync pinctrl DT nodes with Linux bindings

[Stephan Gerhold]

On Thu, Jul 14, 2022 at 01:03:37PM +0530, Sumit Garg wrote:
> Currently for all Qcom SoCs/boards there are separate compatibles for
> GPIO and pinctrl. But this is inconsistent with official (upstream) Linux
> bindings which requires only a single compatible "qcom,-pinctrl"
> and there is no such compatible property as "qcom,tlmm-".
> 
> So fix this inconsistency for Qcom SoCs in order to comply with upstream
> DT bindings. This is done via removing compatibles from "msm_gpio" driver
> and via binding to "msm_gpio" driver from pinctrl driver in case
> "gpio-controller" property is specified for pinctrl node.
> 
> Suggested-by: Stephan Gerhold 
> Signed-off-by: Sumit Garg 

This is a great start, thank you!

> ---
> 
> This is based on top of mine other patch-set [1]. Although, I have
> tested it on db845c and qcs404-evb but I would like other board
> maintainers to test it as well.
>
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=309135

If possible I would prefer to introduce the QCS404 platform with a clean
DT (i.e. qcs404.dtsi imported from the Linux kernel, instead of adding
the custom qcs404-evb.dts and then cleaning it up). This patch would
need to come before the QCS404 addition then.

> 
>  arch/arm/dts/dragonboard410c-uboot.dtsi   |  2 +-
>  arch/arm/dts/dragonboard410c.dts  | 17 +++-
>  arch/arm/dts/dragonboard820c-uboot.dtsi   |  2 +-
>  arch/arm/dts/dragonboard820c.dts  |  4 +-
>  arch/arm/dts/qcom-ipq4019.dtsi| 18 +++--
>  arch/arm/dts/qcs404-evb.dts   |  2 +-
>  arch/arm/dts/sdm845.dtsi  |  2 +-
>  arch/arm/mach-ipq40xx/pinctrl-snapdragon.c| 31 ++-
>  arch/arm/mach-snapdragon/Makefile |  2 +-
>  arch/arm/mach-snapdragon/pinctrl-snapdragon.c | 39 ---
>  drivers/gpio/msm_gpio.c   | 10 +
>  11 files changed, 83 insertions(+), 46 deletions(-)
> 
> [...]
> diff --git a/arch/arm/dts/dragonboard410c.dts 
> b/arch/arm/dts/dragonboard410c.dts
> index 7e56140df2..e0452b270c 100644
> --- a/arch/arm/dts/dragonboard410c.dts
> +++ b/arch/arm/dts/dragonboard410c.dts
> @@ -60,9 +60,13 @@
>   reg = <0x6 0x8000>;
>   };
>  
> - pinctrl: qcom,tlmm@100 {
> - compatible = "qcom,tlmm-apq8016";
> + soc_gpios: pinctrl@100 {
> + compatible = "qcom,apq8016-pinctrl";

This should be "qcom,msm8916-pinctrl" (see msm8916.dtsi in Linux)

>   reg = <0x100 0x40>;
> + gpio-controller;
> + gpio-count = <122>;
> + gpio-bank-name="soc";
> + #gpio-cells = <2>;
>  
>   blsp1_uart: uart {
>   function = "blsp1_uart";
> @@ -86,15 +90,6 @@
>   pinctrl-0 = <_uart>;
>   };
>  
> - soc_gpios: pinctrl@100 {
> - compatible = "qcom,apq8016-pinctrl";
> - reg = <0x100 0x30>;
> - gpio-controller;
> - gpio-count = <122>;
> - gpio-bank-name="soc";
> - #gpio-cells = <2>;
> - };
> -
>   ehci@78d9000 {
>   compatible = "qcom,ehci-host";
>   reg = <0x78d9000 0x400>;
> [...]
> diff --git a/arch/arm/dts/dragonboard820c.dts 
> b/arch/arm/dts/dragonboard820c.dts
> index 1114ddd7d3..1a6e37887f 100644
> --- a/arch/arm/dts/dragonboard820c.dts
> +++ b/arch/arm/dts/dragonboard820c.dts
> @@ -64,8 +64,8 @@
>   reg = <0x30 0x9>;
>   };
>  
> - pinctrl: qcom,tlmm@101 {
> - compatible = "qcom,tlmm-apq8096";
> + pinctrl: pinctrl@101 {
> + compatible = "qcom,msm8916-pinctrl";

Huh, this should be "qcom,msm8996-pinctrl" :)

>   reg = <0x101 0x40>;
>  
>   blsp8_uart: uart {
> [...]
> diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
> index 4f0ae20bdb..09687e1fd3 100644
> --- a/arch/arm/dts/qcs404-evb.dts
> +++ b/arch/arm/dts/qcs404-evb.dts
> @@ -38,7 +38,7 @@
>   compatible = "simple-bus";
>  
>   pinctrl_north@130 {
> - compatible = "qcom,tlmm-

Re: [PATCH v3 9/9] board: qualcomm: Add support for QCS404 EVB

[Stephan Gerhold]

Hi Sumit,

On Tue, Jul 12, 2022 at 12:42:12PM +0530, Sumit Garg wrote:
> Add support for Qualcomm QCS404 SoC based evaluation board.
> 
> Features:
> - Qualcomm Snapdragon QCS404 SoC
> - 1GiB RAM
> - 8GiB eMMC, uSD slot
> 
> U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
> For detailed build and boot instructions, refer to
> doc/board/qualcomm/qcs404.rst.
> 
> Signed-off-by: Sumit Garg 
> ---
>  arch/arm/dts/Makefile|  1 +
>  arch/arm/dts/qcs404-evb-uboot.dtsi   | 24 +++
>  arch/arm/dts/qcs404-evb.dts  | 81 
>  arch/arm/mach-snapdragon/Kconfig | 11 
>  arch/arm/mach-snapdragon/Makefile|  2 +
>  arch/arm/mach-snapdragon/sysmap-qcs404.c | 31 +
>  board/qualcomm/qcs404-evb/Kconfig| 15 +
>  board/qualcomm/qcs404-evb/MAINTAINERS|  6 ++
>  board/qualcomm/qcs404-evb/Makefile   |  6 ++
>  board/qualcomm/qcs404-evb/qcs404-evb.c   | 33 ++
>  board/qualcomm/qcs404-evb/qcs404-evb.its | 64 +++
>  configs/qcs404evb_defconfig  | 39 
>  doc/board/qualcomm/index.rst |  1 +
>  doc/board/qualcomm/qcs404.rst| 79 +++
>  include/configs/qcs404-evb.h | 27 
>  15 files changed, 420 insertions(+)
>  create mode 100644 arch/arm/dts/qcs404-evb-uboot.dtsi
>  create mode 100644 arch/arm/dts/qcs404-evb.dts
>  create mode 100644 arch/arm/mach-snapdragon/sysmap-qcs404.c
>  create mode 100644 board/qualcomm/qcs404-evb/Kconfig
>  create mode 100644 board/qualcomm/qcs404-evb/MAINTAINERS
>  create mode 100644 board/qualcomm/qcs404-evb/Makefile
>  create mode 100644 board/qualcomm/qcs404-evb/qcs404-evb.c
>  create mode 100644 board/qualcomm/qcs404-evb/qcs404-evb.its
>  create mode 100644 configs/qcs404evb_defconfig
>  create mode 100644 doc/board/qualcomm/qcs404.rst
>  create mode 100644 include/configs/qcs404-evb.h
> 
> [...]
> diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
> new file mode 100644
> index 00..4f0ae20bdb
> --- /dev/null
> +++ b/arch/arm/dts/qcs404-evb.dts
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Qualcomm QCS404 based evaluation board device tree source
> + *
> + * (C) Copyright 2022 Sumit Garg 
> + */
> +
> +/dts-v1/;
> +
> +#include "skeleton64.dtsi"
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. QCS404 EVB";
> + compatible = "qcom,qcs404-evb", "qcom,qcs404";
> + #address-cells = <0x2>;
> + #size-cells = <0x2>;
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + aliases {
> + serial0 = _uart;
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0 0x8000 0 0x4000>;
> + };
> +
> + soc {
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> + ranges = <0x0 0x0 0x0 0x>;
> + compatible = "simple-bus";
> +
> + pinctrl_north@130 {
> + compatible = "qcom,tlmm-qcs404";
> + reg = <0x130 0x20>;
> +
> + blsp1_uart2: uart {
> + pins = "GPIO_17", "GPIO_18";
> + function = "blsp_uart2";
> + };
> + };
> +

I know you're just following the example of the existing Qualcomm boards
here but I think we should really avoid adding any more custom device
trees that are inconsistent with the official (upstream) Linux bindings.

Many other boards in U-Boot have moved to using the upstream Linux DTs
as-is (with some additions in -u-boot.dtsi) and I think we should do the
same for the Qualcomm boards. Judging from Tom's comments on other
patches (e.g. [1]), this might even be a requirement now?

The SPMI fix I just sent for DB410c/DB820c [2] is a good example why it
is important to have bindings consistent with Linux. Looking at your
patch reminded me that I never sent this fix (thanks!).

Can you check how hard it would be to reuse the upstream QCS404 DT?

Thanks!
Stephan

[1]: https://lore.kernel.org/u-boot/20220601152800.GJ25375@bill-the-cat/
[2]: https://lore.kernel.org/u-boot/20220713191711.4155-1-step...@gerhold.net/

[PATCH] arm: dts: db410c/db820c: Fix SPMI addresses

[Stephan Gerhold]

The Qualcomm device trees in U-Boot are currently not consistent with
the upstream DTs used in the Linux kernel. While some bindings are
similar to the official specification in the Linux kernel, several
nodes have subtle differences, e.g. the "compatible"s or the exact
specification of memory registers.

This means that some of the Qualcomm-related U-Boot drivers are not
compatible with the Linux DT (and vice versa).

The SPMI node is one such example: the "core" region starts at
0x0200f000 in the upstream Linux MSM8916 DT, but in U-Boot it starts at
0x0200f800. The end result is normally the same, since the Linux SPMI
driver simply adds the 0x800 internally.

However, commit f5a2d6b4b03a ("spmi: msm: add arbiter version 5
support") imported this behavior into the U-Boot driver, without
adjusting the DB410c/DB820c device trees. This means that the 0x800
offset is now added twice, breaking all SPMI read/write operations:

  Failed to find PMIC pon node. Check device tree
  Failed to find pm8916_gpios@c000 node.
  USB init failed: -6
  starting USB...
  Bus ehci@78d9000: Failed to find pm8916_gpios@c000 node.
  probe failed, error -6
  No working controllers found

While the mistake is strictly speaking in the spmi-msm driver, fix the
issue by making the SPMI nodes in the DB410c/DB820c consistent with the
upstream Linux DT instead.

Ideally we should even go a step further by fixing the remaining uses
of custom bindings in the U-Boot drivers and moving to using the Linux
DTs as-is. This would likely avoid such mistakes in the future and
would also make the porting process much easier.

Cc: Dzmitry Sankouski 
Fixes: f5a2d6b4b03a ("spmi: msm: add arbiter version 5 support")
Signed-off-by: Stephan Gerhold 
---
Sorry for sending this literally a few days after the U-Boot release.
This change has been sitting in my local U-Boot clone for a couple of
months already (it's broken at least since v2022.01) but I got caught
up in other work and completely forgot about it. I guess no one else
is actively testing U-Boot on DB410c/DB820c. :/
---
 arch/arm/dts/dragonboard410c.dts |  9 +++--
 arch/arm/dts/dragonboard820c.dts | 11 +++
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index 7e56140df2..50523712cb 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -137,9 +137,14 @@
};
};
 
-   spmi@200f000 {
+   spmi_bus: spmi@200f000 {
compatible = "qcom,spmi-pmic-arb";
-   reg = <0x200f800 0x200 0x240 0x40 0x2c0 
0x40>;
+   reg = <0x0200f000 0x001000>,
+ <0x0240 0x40>,
+ <0x02c0 0x40>,
+ <0x0380 0x20>,
+ <0x0200a000 0x002100>;
+   reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
#address-cells = <0x1>;
#size-cells = <0x1>;
pmic0: pm8916@0 {
diff --git a/arch/arm/dts/dragonboard820c.dts b/arch/arm/dts/dragonboard820c.dts
index 1114ddd7d3..b72a2471cf 100644
--- a/arch/arm/dts/dragonboard820c.dts
+++ b/arch/arm/dts/dragonboard820c.dts
@@ -93,11 +93,14 @@
clock-frequency = <2>;
 };
 
-   spmi@400f000 {
+   spmi_bus: spmi@400f000 {
compatible = "qcom,spmi-pmic-arb";
-   reg = <0x400f800 0x200>,
- <0x440 0x40>,
- <0x4c0 0x40>;
+   reg = <0x0400f000 0x1000>,
+ <0x0440 0x80>,
+ <0x04c0 0x80>,
+ <0x0580 0x20>,
+ <0x0400a000 0x002100>;
+   reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
#address-cells = <0x1>;
#size-cells = <0x1>;
 
-- 
2.37.0

Re: [PATCH v2] board: stemmy: Increase boot image to 64 MB

[Stephan Gerhold]

On Sat, Nov 20, 2021 at 11:55:42PM +0100, Linus Walleij wrote:
> When using a recent kernel with a bunch of compiled-in
> stuff the kernel image easily becomes bigger than 8 MB
> yielding this error:
> 
>   Loading Kernel Image
>   Image too large: increase CONFIG_SYS_BOOTM_LEN
>   Must RESET board to recover
> 
> Fix this by bumping to SZ_64MB.
> 
> Cc: Stephan Gerhold 
> Signed-off-by: Linus Walleij 

Great, thanks for changing it! :)

Reviewed-by: Stephan Gerhold 

> ---
> ChangeLog v1->v2:
> - Bump to 64MB instead of 16MB
> ---
>  include/configs/stemmy.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/stemmy.h b/include/configs/stemmy.h
> index ed79b1203901..4bba2a627259 100644
> --- a/include/configs/stemmy.h
> +++ b/include/configs/stemmy.h
> @@ -14,6 +14,7 @@
>   * bootloader. New images are loaded at the same address for compatibility.
>   */
>  #define CONFIG_SYS_INIT_SP_ADDR  CONFIG_SYS_TEXT_BASE
> +#define CONFIG_SYS_BOOTM_LEN SZ_64M
>  
>  /* FIXME: This should be loaded from device tree... */
>  #define CONFIG_SYS_L2_PL310
> -- 
> 2.31.1
> 

Re: [PATCH] board: stemmy: Increase boot image to 16 MB

[Stephan Gerhold]

On Fri, Nov 19, 2021 at 01:12:43PM -0500, Tom Rini wrote:
> On Fri, Nov 19, 2021 at 03:33:21PM +0100, Linus Walleij wrote:
> 
> > When using a recent kernel with a bunch of compiled-in
> > stuff the kernel image easily becomes bigger than 8 MB
> > yielding this error:
> > 
> >   Loading Kernel Image
> >   Image too large: increase CONFIG_SYS_BOOTM_LEN
> >   Must RESET board to recover
> > 
> > Fix this by bumping to SZ_16MB.
> > 
> > Cc: Stephan Gerhold 
> > Signed-off-by: Linus Walleij 
> > ---
> >  include/configs/stemmy.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/include/configs/stemmy.h b/include/configs/stemmy.h
> > index ed79b1203901..f4700a45daf5 100644
> > --- a/include/configs/stemmy.h
> > +++ b/include/configs/stemmy.h
> > @@ -14,6 +14,7 @@
> >   * bootloader. New images are loaded at the same address for compatibility.
> >   */
> >  #define CONFIG_SYS_INIT_SP_ADDRCONFIG_SYS_TEXT_BASE
> > +#define CONFIG_SYS_BOOTM_LEN   SZ_16M
> >  
> >  /* FIXME: This should be loaded from device tree... */
> >  #define CONFIG_SYS_L2_PL310
> 
> So, the default for CONFIG_SYS_BOOTM_LEN is clearly too small and should
> be addressed broadly.  And, ugh, I don't see a maximum size for the
> kernel itself in
> https://www.kernel.org/doc/Documentation/arm64/booting.rst but SZ_64M is
> the common "we hope this is always large enough" value used, so can we
> push stemmy there as well?  Thanks.
> 

I think there is usually less needed on ARM32 since Linux will
decompress itself, so the size here is actually for the *compressed*
kernel image, not the decompressed one. But it doesn't hurt to have it
larger I guess, so 64 MiB also sounds good to me.

Linus, can you send a v2 with SZ_64M? Also feel free to add my
Reviewed-by: Stephan Gerhold 

Thanks,
Stephan

Re: [PATCH 6/6 v3] board: samsung: add Samsung Galaxy S9/S9+(SM-G96x0) board

[Stephan Gerhold]

Hi,

On Fri, Sep 24, 2021 at 05:35:57PM +0300, Dzmitry Sankouski wrote:
> I haven't tried to install u-boot on the phone with Android boot image
> yet(though another guy in the community project I contribute, reported it
> works).
> I can only test u-boot with kexec, it's the only way to get debug uart for
> me, without disassembling the phone.
> 

Hmm, does Samsung not have UART via the USB connector anymore on newer
devices? This is quite sad, on the Samsung devices I have used
it was always quite comfortable. :)

> Also I have to track down the issues with booting linux.
> 
> So, once I'll got linux booted by u-boot, I will be able to pack and
> install it in Android boot partition, and write more detailed instructions.
> 

Ah okay, maybe just submit a follow-up patch later then once you have
proper installation instructions. :)

Thanks!
Stephan

Re: [PATCH 6/6 v3] board: samsung: add Samsung Galaxy S9/S9+(SM-G96x0) board

[Stephan Gerhold]

Hi,

On Thu, Sep 23, 2021 at 09:57:32PM +0300, dsankou...@gmail.com wrote:
> From: Dzmitry Sankouski 
> 
> Samsung S9 SM-G9600 - Snapdragon SDM845 version of the phone,
> for China \ Hong Kong markets.
> Has unlockable bootloader, unlike SM-G960U (American market version),
> which allows running u-boot as a chain-loaded bootloader.
> 
> Signed-off-by: Dzmitry Sankouski 
> Cc: Ramon Fried 
> Cc: Tom Rini 
> ---
> Changes for v2:
> - Create documentation file for SDM845 boards
> - Add starqltechn board documentation
> Changes for v3:
> - fix comment in starqltechn.c
> 
>  arch/arm/dts/Makefile   |  1 +
>  arch/arm/dts/starqltechn-uboot.dtsi | 39 ++
>  arch/arm/dts/starqltechn.dts| 53 +
>  arch/arm/mach-snapdragon/Kconfig| 13 ++
>  board/samsung/starqltechn/Kconfig   | 14 +++
>  board/samsung/starqltechn/MAINTAINERS   |  6 +++
>  board/samsung/starqltechn/Makefile  |  9 +
>  board/samsung/starqltechn/starqltechn.c | 10 +
>  configs/starqltechn_defconfig   | 33 +++
>  doc/board/qualcomm/index.rst|  1 +
>  doc/board/qualcomm/sdm845.rst   | 38 ++
>  include/configs/starqltechn.h   | 16 
>  12 files changed, 233 insertions(+)
>  create mode 100644 arch/arm/dts/starqltechn-uboot.dtsi
>  create mode 100644 arch/arm/dts/starqltechn.dts
>  create mode 100644 board/samsung/starqltechn/Kconfig
>  create mode 100644 board/samsung/starqltechn/MAINTAINERS
>  create mode 100644 board/samsung/starqltechn/Makefile
>  create mode 100644 board/samsung/starqltechn/starqltechn.c
>  create mode 100644 configs/starqltechn_defconfig
>  create mode 100644 doc/board/qualcomm/sdm845.rst
>  create mode 100644 include/configs/starqltechn.h
> 
> [...]
> diff --git a/doc/board/qualcomm/sdm845.rst b/doc/board/qualcomm/sdm845.rst
> new file mode 100644
> index 00..cd46cbe9cf
> --- /dev/null
> +++ b/doc/board/qualcomm/sdm845.rst
> @@ -0,0 +1,38 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +.. sectionauthor:: Dzmitry Sankouski 
> +
> +Snapdragon 845
> +
> +
> +About this
> +--
> +This document describes the information about Qualcomm Snapdragon 845
> +supported boards and it's usage steps.
> +
> +SDM845 - hi-end qualcomm chip, introduced in late 2017.
> +Mostly used in flagship phones and tablets of 2018.
> +
> +U-Boot can be used as a replacement for Qualcomm's original ABL (UEFI) 
> bootloader.
> +It is loaded as an Android boot image through ABL
> +
> +Installation
> +
> +First, setup ``CROSS_COMPILE`` for aarch64. Then, build U-Boot for your 
> board::
> +
> + $ export CROSS_COMPILE=
> + $ make _defconfig
> + $ make
> +
> +This will build ``u-boot.bin`` in the configured output directory.
> +
> +Boards
> +
> +starqlte
> +
> +
> +The starqltechn is a production board for Samsung S9 (SM-G9600) phone,
> +based on the Qualcomm SDM845 SoC.
> +
> +More information can be found on the `Samsung S9 page`_.
> +
> +.. _Samsung S9 page: https://en.wikipedia.org/wiki/Samsung_Galaxy_S9

Can you add a short explanation here how you would install the
u-boot.bin on the Samsung S9? You say that it is loaded through an
Android boot image, but how exactly is it built?

For example, do you use an empty ramdisk, does the bootloader expect
some dt.img etc? Something similar to the DB820c README:
https://source.denx.de/u-boot/u-boot/-/blob/master/board/qualcomm/dragonboard820c/readme.txt#L32-61

This would be helpful if someone wants to install U-Boot on that phone
I think :)

Thanks!
Stephan

Re: [PATCH 5/6] SoC: qcom: add support for SDM845

[Stephan Gerhold]

Hi,

On Thu, Sep 23, 2021 at 09:57:31PM +0300, dsankou...@gmail.com wrote:
> From: Dzmitry Sankouski 
> 
> Hi-end qualcomm chip, introduced in late 2017.
> Mostly used in flagship phones and tablets of 2018.
> Features:
> - arm64 arch
> - total of 8 Kryo 385 Gold / Silver cores
> - Hexagon 685 DSP
> - Adreno 630 GPU
> 
> Tested only as second-stage bootloader.
> 
> Signed-off-by: Dzmitry Sankouski 
> Cc: Ramon Fried 
> Cc: Tom Rini 
> ---
>  arch/arm/dts/sdm845.dtsi  | 118 ++
>  arch/arm/mach-snapdragon/Kconfig  |   4 +
>  arch/arm/mach-snapdragon/Makefile |   4 +
>  .../include/mach/sysmap-sdm845.h  |  42 +++
>  arch/arm/mach-snapdragon/init_sdm845.c|  82 
>  arch/arm/mach-snapdragon/sysmap-sdm845.c  |  31 +
>  include/configs/sdm845.h  |  33 +
>  7 files changed, 314 insertions(+)
>  create mode 100644 arch/arm/dts/sdm845.dtsi
>  create mode 100644 arch/arm/mach-snapdragon/include/mach/sysmap-sdm845.h
>  create mode 100644 arch/arm/mach-snapdragon/init_sdm845.c
>  create mode 100644 arch/arm/mach-snapdragon/sysmap-sdm845.c
>  create mode 100644 include/configs/sdm845.h
> 
> diff --git a/arch/arm/dts/sdm845.dtsi b/arch/arm/dts/sdm845.dtsi
> new file mode 100644
> index 00..bf32c6995d
> --- /dev/null
> +++ b/arch/arm/dts/sdm845.dtsi
> @@ -0,0 +1,118 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Qualcomm SDM845 chip device tree source
> + *
> + * (C) Copyright 2021 Dzmitry Sankouski 
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include "skeleton64.dtsi"
> +
> +/ {
> + soc: soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0 0 0x>;
> + compatible = "simple-bus";
> +
> + gcc: clock-controller@10 {
> + u-boot,dm-pre-reloc;
> + compatible = "qcom,gcc-sdm845";
> + reg = <0x0010 0x1f>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> + };
> +
> + gpio_north: gpio_north@390 {
> + u-boot,dm-pre-reloc;
> + #gpio-cells = <2>;
> + compatible = "qcom,sdm845-pinctrl";
> + reg = <0x390 0x40>;
> + gpio-count = <150>;
> + gpio-controller;
> + gpio-ranges = <_north 0 0 150>;
> + gpio-bank-name = "soc_north.";
> + };
> +
> + tlmm_north: pinctrl_north@390 {
> + u-boot,dm-pre-reloc;
> + compatible = "qcom,tlmm-sdm845";
> + reg = <0x0390 0x40>;

Can you consistently pad "reg" with zeroes or not?
"gcc" is padded with zeroes to 8 digits, gpio_north is not,
then this is suddenly again. This makes it look like gpio_north
and tlmm_north have a different address when it's actually the same.

> + gpio-count = <150>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = <_north 0 0 150>;
> +
> + /* DEBUG UART */
> + qup_uart9: qup-uart9-default {
> + pinmux {
> + pins = "GPIO_4", "GPIO_5";
> + function = "qup9";
> + };
> + };
> + };
> +
> + debug_uart: serial@0xa84000 {

The 0x should not be in the unit name (after @).

> + compatible = "qcom,msm-geni-uart";
> + reg = <0xa84000 0x4000>;
> + reg-names = "se_phys";
> + clock-names = "se-clk";
> + clocks = < 0x58>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart9>;
> + qcom,wrapper-core = <0x8a>;
> + status = "disabled";
> + };
> +
> + spmi@c44 {
> + compatible = "qcom,spmi-pmic-arb";
> + reg = <0xc44 0x1100>,
> +   <0xc60 0x200>,
> +   <0xe60 0x10>;
> + reg-names = "cnfg", "core", "obsrvr";
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> +
> + qcom,revid@100 {
> + compatible = "qcom,qpnp-revid";
> + reg = <0x100 0x100>;
> + linux,phandle = <0x3ac>;
> + phandle = <0x3ac>;
> + };
> +

What is this used for? With the linux,phandle this looks a bit like
something copied from a decompiled 

Re: [PATCH 3/6] pinctrl: qcom: add pinctrl and gpio drivers for SDM845 SoC

[Stephan Gerhold]

Hi,

On Thu, Sep 23, 2021 at 09:57:29PM +0300, dsankou...@gmail.com wrote:
> From: Dzmitry Sankouski 
> 
> Signed-off-by: Dzmitry Sankouski 
> Cc: Ramon Fried 
> Cc: Tom Rini 
> ---
>  arch/arm/mach-snapdragon/pinctrl-sdm845.c | 44 +++
>  arch/arm/mach-snapdragon/pinctrl-snapdragon.c |  1 +
>  arch/arm/mach-snapdragon/pinctrl-snapdragon.h |  1 +
>  drivers/gpio/msm_gpio.c   |  1 +
>  drivers/gpio/pm8916_gpio.c|  8 ++--
>  5 files changed, 52 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/mach-snapdragon/pinctrl-sdm845.c
> 
> diff --git a/arch/arm/mach-snapdragon/pinctrl-sdm845.c 
> b/arch/arm/mach-snapdragon/pinctrl-sdm845.c
> new file mode 100644
> index 00..6d66582aa6
> --- /dev/null
> +++ b/arch/arm/mach-snapdragon/pinctrl-sdm845.c
> @@ -0,0 +1,44 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Qualcomm SDM845 pinctrl
> + *
> + * (C) Copyright 2021 Dzmitry Sankouski 
> + *
> + */
> +
> +#include "pinctrl-snapdragon.h"
> +#include 
> +
> +#define MAX_PIN_NAME_LEN 32
> +static char pin_name[MAX_PIN_NAME_LEN];

Since this is used before relocation (when setting up pinctrl for
serial) you should really add __section(".data") here. I would expect
that you are currently corrupting some random part of your appended DTB
and are just lucky enough this does not cause any crashes. :)

See: 
https://source.denx.de/u-boot/u-boot/-/commit/548b89f8ad396d238d594f6f6fa1df902b74a303

Thanks,
Stephan

Re: [PATCH 3/5] arm: Disable ATAGs support

[Stephan Gerhold]

Hi Tom,

On Mon, Aug 30, 2021 at 09:16:30AM -0400, Tom Rini wrote:
> With the exception of nokia_rx51 and icnova-a20-swac, disable ATAG
> support.  A large number of platforms had enabled support but never
> supported a kernel so old as to require it.  Further, some platforms are
> old enough to support both, but are well supported by devicetree
> booting, and have been for a number of years.  This is because some of
> the ATAGs related functions have been re-used to provide the same kind
> of information, but for devicetree or just generally to inform the user.
> When needed still, rename these functions to get_board_revision()
> instead, to avoid conflicts.  In other cases, these functions were
> simply unused, so drop them.
> 
> Cc: Andre Przywara 
> Cc: Jagan Teki 
> Cc: Phil Sutter 
> Cc: Stefan Bosch 
> Signed-off-by: Tom Rini 
> [...]
> ---
>  include/configs/stemmy.h  |  3 --
> [...]
> +++ b/include/configs/stemmy.h
> @@ -23,7 +23,4 @@
>  #define CONFIG_SYS_L2_PL310
>  #define CONFIG_SYS_PL310_BASE0xa0412000
>  
> -/* Generate initrd atag for downstream kernel (others are copied in 
> stemmy.c) */
> -#define CONFIG_INITRD_TAG
> -
>  #endif

Please keep this option for the stemmy board. It's still used
occasionally to boot the original downstream/vendor kernel which is
currently still necessary to charge the battery on these devices.

See commit e2f82f93 ("board: stemmy: Copy atags for booting
downstream/vendor kernel") [1] for details.

Thanks!
Stephan

[1]: 
https://source.denx.de/u-boot/u-boot/-/commit/e2f82f93f885dd3dd3ad74e98182add8ccd863e7.patch

[PATCH 4/7] arm: dts: u8500: u-boot: Add fixed clock for eMMC

[Stephan Gerhold]

So far there is no need for a clock driver in U-Boot because the
previous boot stage leaves all the necessary clocks on. However,
some drivers in U-Boot (e.g. arm_pl180_mmci) depend on having a clock
driver to obtain the clock frequency.

Setting up the clock drivers properly is a bit tricky on U8500,
so for now add a simple fixed-clock for the eMMC that allows obtaining
the clock frequency. This should be replaced eventually if some board
actually requires enabling some of the clocks.

Signed-off-by: Stephan Gerhold 
---

 arch/arm/dts/ste-dbx5x0-u-boot.dtsi | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/ste-dbx5x0-u-boot.dtsi 
b/arch/arm/dts/ste-dbx5x0-u-boot.dtsi
index 4a99ee5a92..e350175305 100644
--- a/arch/arm/dts/ste-dbx5x0-u-boot.dtsi
+++ b/arch/arm/dts/ste-dbx5x0-u-boot.dtsi
@@ -4,8 +4,14 @@
 #include "ste-dbx5x0.dtsi"
 
 / {
+   /* FIXME: Remove this when clk driver is implemented */
+   sdmmcclk: sdmmcclk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1>;
+   };
+
soc {
-   /* FIXME: Remove this when clk driver is implemented */
mtu@a03c6000 {
clock-frequency = <13300>;
};
@@ -18,6 +24,9 @@
uart@80007000 {
clock = <3840>;
};
+   mmc@80005000 {
+   clocks = <>;
+   };
};
 
reboot {
-- 
2.32.0

[PATCH 7/7] arm: u8500: Prefer building in thumb mode by default

[Stephan Gerhold]

Enabling CONFIG_SYS_THUMB_BUILD produces a significantly smaller
U-Boot binary (250 KiB vs 320 KiB) that still seems to be fully
functional. Make use of that by default but keep it as "imply" so it
can be disabled for testing in case this causes trouble for someone.

Signed-off-by: Stephan Gerhold 
---

 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dd223ada57..28cd3c85d2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1050,6 +1050,7 @@ config ARCH_U8500
imply PL01X_SERIAL
imply PMIC_AB8500
imply RTC_PL031
+   imply SYS_THUMB_BUILD
imply SYSRESET_SYSCON
 
 config ARCH_VERSAL
-- 
2.32.0

[PATCH 6/7] board: stemmy: Update documentation

[Stephan Gerhold]

Over the time, the "stemmy" U-Boot board was tested on several other
Samsung smartphones based on ST-Ericsson NovaThor Ux500. Convert the
documentation to reStructuredText at doc/board/ste/stemmy.rst and
make the device list complete. Also note that the board now boots
into USB Fastboot instead of just ending up at the U-Boot prompt.

The device table is mostly taken from the postmarketOS wiki article
(https://wiki.postmarketos.org/wiki/ST-Ericsson_NovaThor_U8500).
All the newly added devices were tested by Linus Walleij.

Signed-off-by: Stephan Gerhold 
---

I tried to have a separate commit for conversion and additions first
but there are minor changes everywhere in the documentation (e.g.
changing the device list to a table) so the diff was not really any
more clear. The README is not _that_ long so I hope it's okay. :)
---
 arch/arm/mach-u8500/Kconfig  | 11 ++---
 board/ste/stemmy/MAINTAINERS |  3 +-
 board/ste/stemmy/README  | 50 --
 doc/board/index.rst  |  1 +
 doc/board/ste/index.rst  |  9 
 doc/board/ste/stemmy.rst | 81 
 6 files changed, 99 insertions(+), 56 deletions(-)
 delete mode 100644 board/ste/stemmy/README
 create mode 100644 doc/board/ste/index.rst
 create mode 100644 doc/board/ste/stemmy.rst

diff --git a/arch/arm/mach-u8500/Kconfig b/arch/arm/mach-u8500/Kconfig
index db7a29a54c..b067a719e7 100644
--- a/arch/arm/mach-u8500/Kconfig
+++ b/arch/arm/mach-u8500/Kconfig
@@ -13,14 +13,15 @@ config TARGET_STEMMY
  The Samsung "stemmy" board supports Samsung smartphones released with
  the ST-Ericsson NovaThor U8500 SoC, e.g.
 
- - Samsung Galaxy S III mini (GT-I8190)"golden"
+ - Samsung Galaxy Ace 2 (GT-I8160) "codina"
+ - Samsung Galaxy Amp (SGH-I407)   "kyle"
+ - Samsung Galaxy Beam (GT-I8530)  "gavini"
+ - Samsung Galaxy Exhibit (SGH-T599)   "codina" (TMO)
  - Samsung Galaxy S Advance (GT-I9070) "janice"
+ - Samsung Galaxy S III mini (GT-I8190)"golden"
  - Samsung Galaxy Xcover 2 (GT-S7710)  "skomer"
- - Samsung Galaxy Ace 2 (GT-I8160) "codina"
-
- and likely others as well (untested).
 
- See board/ste/stemmy/README for details.
+ See doc/board/ste/stemmy.rst for details.
 
 endchoice
 
diff --git a/board/ste/stemmy/MAINTAINERS b/board/ste/stemmy/MAINTAINERS
index 37daabea9c..fa06488284 100644
--- a/board/ste/stemmy/MAINTAINERS
+++ b/board/ste/stemmy/MAINTAINERS
@@ -2,5 +2,6 @@ STEMMY BOARD
 M: Stephan Gerhold 
 S: Maintained
 F: board/ste/stemmy/
-F: include/configs/stemmy.h
 F: configs/stemmy_defconfig
+F: doc/board/ste/stemmy.rst
+F: include/configs/stemmy.h
diff --git a/board/ste/stemmy/README b/board/ste/stemmy/README
deleted file mode 100644
index 1b83b833c0..00
--- a/board/ste/stemmy/README
+++ /dev/null
@@ -1,50 +0,0 @@
-ST-Ericsson U8500 Samsung "stemmy" board
-
-
-The "stemmy" board supports Samsung smartphones released with
-the ST-Ericsson NovaThor U8500 SoC, e.g.
-
-   - Samsung Galaxy S III mini (GT-I8190)  "golden"
-   - Samsung Galaxy S Advance (GT-I9070)   "janice"
-   - Samsung Galaxy Xcover 2 (GT-S7710)"skomer"
-   - Samsung Galaxy Ace 2 (GT-I8160)   "codina"
-
-and likely others as well (untested).
-
-At the moment, U-Boot is intended to be chain-loaded from
-the original Samsung bootloader, not replacing it entirely.
-
-Installation
-
-
-1. Setup cross compiler, e.g. export CROSS_COMPILE=arm-none-eabi-
-2. make stemmy_defconfig
-3. make
-
-For newer devices (golden and skomer), the U-Boot binary has to be packed into
-an Android boot image. janice boots the raw U-Boot binary from the boot 
partition.
-
-4. Obtain mkbootimg, e.g. 
https://android.googlesource.com/platform/system/core/+/refs/tags/android-7.1.2_r37/mkbootimg/mkbootimg
-5. mkbootimg \
---kernel=u-boot.bin \
---base=0x \
---kernel_offset=0x0010 \
---ramdisk_offset=0x0200 \
---tags_offset=0x0100 \
---output=u-boot.img
-
-6. Enter Samsung download mode (press Power + Home + Volume Down)
-7. Flash U-Boot image to Android boot partition using Heimdall:
- https://gitlab.com/BenjaminDobell/Heimdall
-
-   heimdall flash --Kernel u-boot.(bin|img)
-
-8. After reboot U-Boot prompt should appear via UART.
-
-UART
-
-
-UART is available through the micro USB port, similar to the Carkit standard.
-With a ~619kOhm resistor between ID and GND, 1.8V RX/TX is available at D+/D-.
-
-Make sure to connect the UART cable *before* turning on the phone.
diff --git a/doc/board/index.rst b/doc/board/index.rst
index 9e90978891..

[PATCH 3/7] arm: dts: u8500: Update from Linux ux500-dts-for-v5.15

[Stephan Gerhold]

Update ste-dbx5x0.dtsi, ste-ab8500.dtsi and ste-ab8505.dtsi with
the changes made in upstream Linux. They are taken from
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/
branch "ux500-dts-for-v5.15" (pending merge for Linux 5.15).

The only relevant change for U-Boot here is
"ARM: dts: ux500: ab8500: Link USB PHY to USB controller node" [1]
which links the USB PHY to the USB controller. This is necessary on
U-Boot because the PHY driver is implemented as part of the generic
PHY subsystem that makes use of these bindings.

[1]: 
https://lore.kernel.org/linux-arm-kernel/20210709182234.47232-1-step...@gerhold.net/

Signed-off-by: Stephan Gerhold 
---

 arch/arm/dts/ste-ab8500.dtsi | 116 +++
 arch/arm/dts/ste-ab8505.dtsi |  95 ++--
 arch/arm/dts/ste-dbx5x0.dtsi |  14 ++---
 3 files changed, 175 insertions(+), 50 deletions(-)

diff --git a/arch/arm/dts/ste-ab8500.dtsi b/arch/arm/dts/ste-ab8500.dtsi
index 14d4d8617d..dcc4a60c0c 100644
--- a/arch/arm/dts/ste-ab8500.dtsi
+++ b/arch/arm/dts/ste-ab8500.dtsi
@@ -42,15 +42,15 @@
 
ab8500-rtc {
compatible = "stericsson,ab8500-rtc";
-   interrupts = <17 IRQ_TYPE_LEVEL_HIGH
- 18 IRQ_TYPE_LEVEL_HIGH>;
+   interrupts = <17 IRQ_TYPE_LEVEL_HIGH>,
+<18 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "60S", "ALARM";
};
 
gpadc: ab8500-gpadc {
compatible = "stericsson,ab8500-gpadc";
-   interrupts = <32 IRQ_TYPE_LEVEL_HIGH
- 39 IRQ_TYPE_LEVEL_HIGH>;
+   interrupts = <32 IRQ_TYPE_LEVEL_HIGH>,
+<39 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "HW_CONV_END", 
"SW_CONV_END";
vddadc-supply = <_ldo_tvout_reg>;
#address-cells = <1>;
@@ -122,9 +122,11 @@
 
ab8500_temp {
compatible = "stericsson,abx500-temp";
+   interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "ABX500_TEMP_WARM";
io-channels = < 0x06>,
  < 0x07>;
-   io-channel-name = "aux1", "aux2";
+   io-channel-names = "aux1", "aux2";
};
 
ab8500_battery: ab8500_battery {
@@ -134,29 +136,77 @@
 
ab8500_fg {
compatible = "stericsson,ab8500-fg";
-   battery= <_battery>;
+   interrupts = <24 IRQ_TYPE_LEVEL_HIGH>,
+<8 IRQ_TYPE_LEVEL_HIGH>,
+<28 IRQ_TYPE_LEVEL_HIGH>,
+<27 IRQ_TYPE_LEVEL_HIGH>,
+<26 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "NCONV_ACCU",
+ "BATT_OVV",
+ "LOW_BAT_F",
+ "CC_INT_CALIB",
+ "CCEOC";
+   battery = <_battery>;
io-channels = < 0x08>;
-   io-channel-name = "main_bat_v";
+   io-channel-names = "main_bat_v";
};
 
ab8500_btemp {
compatible = "stericsson,ab8500-btemp";
-   battery= <_battery>;
+   interrupts = <20 IRQ_TYPE_LEVEL_HIGH>,
+   

[PATCH 5/7] board: stemmy: Add basic Fastboot support

[Stephan Gerhold]

Make use of the new drivers for ARM U8500 introduced in the U-Boot
2021.10 merge window by adding basic support for USB Fastboot with
the "stemmy" board. As a first step this will always boot directly
into USB Fastboot for now with the console displayed on the screen
to make that obvious.

Samsung uses quite strange GPT partition labels on these boards,
so also add a bunch of fastboot_partition_alias_* to make this more
easy to use.

Signed-off-by: Stephan Gerhold 
---

 arch/arm/dts/ste-ux500-samsung-stemmy.dts | 16 ++
 configs/stemmy_defconfig  | 14 
 include/configs/stemmy.h  | 27 +++
 3 files changed, 57 insertions(+)

diff --git a/arch/arm/dts/ste-ux500-samsung-stemmy.dts 
b/arch/arm/dts/ste-ux500-samsung-stemmy.dts
index 7e7f4c823a..14be86086b 100644
--- a/arch/arm/dts/ste-ux500-samsung-stemmy.dts
+++ b/arch/arm/dts/ste-ux500-samsung-stemmy.dts
@@ -12,9 +12,25 @@
};
 
soc {
+   /* eMMC */
+   mmc@80005000 {
+   status = "okay";
+
+   arm,primecell-periphid = <0x10480180>;
+   max-frequency = <1>;
+   bus-width = <8>;
+
+   non-removable;
+   cap-mmc-highspeed;
+   };
+
/* Debugging console UART */
uart@80007000 {
status = "okay";
};
+
+   mcde@a035 {
+   status = "okay";
+   };
};
 };
diff --git a/configs/stemmy_defconfig b/configs/stemmy_defconfig
index f31960b814..1dbec70f36 100644
--- a/configs/stemmy_defconfig
+++ b/configs/stemmy_defconfig
@@ -3,6 +3,8 @@ CONFIG_ARCH_U8500=y
 CONFIG_SYS_TEXT_BASE=0x10
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_DEFAULT_DEVICE_TREE="ste-ux500-samsung-stemmy"
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run fastbootcmd"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_CONFIG=y
@@ -14,5 +16,17 @@ CONFIG_CMD_PART=y
 CONFIG_CMD_GETTIME=y
 CONFIG_EFI_PARTITION=y
 # CONFIG_NET is not set
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_FASTBOOT_BUF_ADDR=0x1810
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=0
 # CONFIG_MMC_HW_PARTITIONING is not set
+CONFIG_USB=y
+CONFIG_USB_MUSB_GADGET=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_VENDOR_NUM=0x04e8
+CONFIG_USB_GADGET_PRODUCT_NUM=0x685d
+CONFIG_DM_VIDEO=y
+CONFIG_SYS_WHITE_ON_BLACK=y
+CONFIG_VIDEO_MCDE_SIMPLE=y
 # CONFIG_EFI_LOADER is not set
diff --git a/include/configs/stemmy.h b/include/configs/stemmy.h
index b94ef91c2b..9721c21d61 100644
--- a/include/configs/stemmy.h
+++ b/include/configs/stemmy.h
@@ -26,4 +26,31 @@
 /* Generate initrd atag for downstream kernel (others are copied in stemmy.c) 
*/
 #define CONFIG_INITRD_TAG
 
+/* Linux does not boot if FDT / initrd is loaded to end of RAM */
+#define BOOT_ENV \
+   "fdt_high=0x600\0" \
+   "initrd_high=0x600\0"
+
+#define CONSOLE_ENV \
+   "stdin=serial\0" \
+   "stdout=serial,vidconsole\0" \
+   "stderr=serial,vidconsole\0"
+
+#define FASTBOOT_ENV \
+   "fastboot_partition_alias_boot=Kernel\0" \
+   "fastboot_partition_alias_recovery=Kernel2\0" \
+   "fastboot_partition_alias_system=SYSTEM\0" \
+   "fastboot_partition_alias_cache=CACHEFS\0" \
+   "fastboot_partition_alias_hidden=HIDDEN\0" \
+   "fastboot_partition_alias_userdata=DATAFS\0"
+
+#define BOOTCMD_ENV \
+   "fastbootcmd=echo '*** FASTBOOT MODE ***'; fastboot usb 0\0"
+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+   BOOT_ENV \
+   CONSOLE_ENV \
+   FASTBOOT_ENV \
+   BOOTCMD_ENV
+
 #endif
-- 
2.32.0

[PATCH 2/7] arm: u8500: Imply options for new drivers

[Stephan Gerhold]

Imply the options for new drivers added for ARM U8500 during the
U-Boot 2021.10 merge window. Adding these as "imply" in the Kconfig
avoids having to add them to all the board defconfigs but still allows
disabling them if wanted.

Also select DM_USB_GADGET if DM_USB is selected because otherwise
the Ux500 MUSB glue driver does not show up in the configuration.

Signed-off-by: Stephan Gerhold 
---

 arch/arm/Kconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3a745ce126..dd223ada57 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1035,13 +1035,20 @@ config ARCH_U8500
select DM_GPIO
select DM_MMC if MMC
select DM_SERIAL
+   select DM_USB_GADGET if DM_USB
select OF_CONTROL
select SYSRESET
select TIMER
+   imply AB8500_USB_PHY
imply ARM_PL180_MMCI
+   imply CLK
+   imply DM_PMIC
imply DM_RTC
+   imply NOMADIK_GPIO
imply NOMADIK_MTU_TIMER
+   imply PHY
imply PL01X_SERIAL
+   imply PMIC_AB8500
imply RTC_PL031
imply SYSRESET_SYSCON
 
-- 
2.32.0

[PATCH 0/7] Enable new drivers added for U-Boot 2021.10 in "stemmy" board

[Stephan Gerhold]

This series finishes up the work done for ARM U8500 in the U-Boot
2021.10 merge window. The new drivers are added to MAINTAINERS,
then enabled in Kconfig and finally the "stemmy" board is updated
to make use of them.


Stephan Gerhold (7):
  MAINTAINERS: Add new drivers for ARM U8500
  arm: u8500: Imply options for new drivers
  arm: dts: u8500: Update from Linux ux500-dts-for-v5.15
  arm: dts: u8500: u-boot: Add fixed clock for eMMC
  board: stemmy: Add basic Fastboot support
  board: stemmy: Update documentation
  arm: u8500: Prefer building in thumb mode by default

 MAINTAINERS   |   5 +
 arch/arm/Kconfig  |   8 ++
 arch/arm/dts/ste-ab8500.dtsi  | 116 +-
 arch/arm/dts/ste-ab8505.dtsi  |  95 ++
 arch/arm/dts/ste-dbx5x0-u-boot.dtsi   |  11 +-
 arch/arm/dts/ste-dbx5x0.dtsi  |  14 +--
 arch/arm/dts/ste-ux500-samsung-stemmy.dts |  16 +++
 arch/arm/mach-u8500/Kconfig   |  11 +-
 board/ste/stemmy/MAINTAINERS  |   3 +-
 board/ste/stemmy/README   |  50 --
 configs/stemmy_defconfig  |  14 +++
 doc/board/index.rst   |   1 +
 doc/board/ste/index.rst   |   9 ++
 doc/board/ste/stemmy.rst  |  81 +++
 include/configs/stemmy.h  |  27 +
 15 files changed, 354 insertions(+), 107 deletions(-)
 delete mode 100644 board/ste/stemmy/README
 create mode 100644 doc/board/ste/index.rst
 create mode 100644 doc/board/ste/stemmy.rst

-- 
2.32.0

[PATCH 1/7] MAINTAINERS: Add new drivers for ARM U8500

[Stephan Gerhold]

Update MAINTAINERS with various drivers for ARM U8500 that were
added during the U-Boot 2021.10 merge window.

Signed-off-by: Stephan Gerhold 
---

 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 776ff703b9..d64dcfacad 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -532,7 +532,12 @@ R: Linus Walleij 
 S: Maintained
 F: arch/arm/dts/ste-*
 F: arch/arm/mach-u8500/
+F: drivers/gpio/nmk_gpio.c
+F: drivers/phy/phy-ab8500-usb.c
+F: drivers/power/pmic/ab8500.c
 F: drivers/timer/nomadik-mtu-timer.c
+F: drivers/usb/musb-new/ux500.c
+F: drivers/video/mcde_simple.c
 
 ARM UNIPHIER
 S: Orphan (Since 2020-09)
-- 
2.32.0

[PATCH v2 2/2] arm: mach-snapdrgon: misc: Simplify msm_generate_mac_addr()

[Stephan Gerhold]

The logic in msm_generate_mac_addr() was originally taken from the LK
bootloader where the serial number is a string and must be parsed first.
However, in U-Boot msm_board_serial() returns an u32 and
msm_generate_mac_addr() has quite complicated code that will first
print it as a hex string and then immediately parse it again.

What this function actually does at the end is to put the serial number
encoded as big endian (the order used for the hex string) into the u8 *mac.
Use put_unaligned_be32() to do that with bit shifts instead of going
through the string format.

This should be slightly more efficient and cleaner but does not result
in any functional difference.

Cc: Ramon Fried 
Signed-off-by: Stephan Gerhold 
---

Changes in v2:
  - Rebase on u-boot/master to fix conflict with recent changes
  - Add comment to clarify what put_unaligned_be32() does here

 arch/arm/mach-snapdragon/misc.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-snapdragon/misc.c b/arch/arm/mach-snapdragon/misc.c
index fbd5f4d051..7d452f4529 100644
--- a/arch/arm/mach-snapdragon/misc.c
+++ b/arch/arm/mach-snapdragon/misc.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* UNSTUFF_BITS macro taken from Linux Kernel: drivers/mmc/core/sd.c */
 #define UNSTUFF_BITS(resp, start, size) \
@@ -41,16 +42,14 @@ u32 msm_board_serial(void)
 
 void msm_generate_mac_addr(u8 *mac)
 {
-   int i;
-   char sn[9];
-
-   snprintf(sn, 9, "%08x", msm_board_serial());
-
-   /* fill in the mac with serialno, use locally adminstrated pool */
+   /* use locally adminstrated pool */
mac[0] = 0x02;
-   mac[1] = 00;
-   for (i = 3; i >= 0; i--) {
-   mac[i + 2] = hextoul([2 * i], NULL);
-   sn[2 * i] = 0;
-   }
+   mac[1] = 0x00;
+
+   /*
+* Put the 32-bit serial number in the last 32-bit of the MAC address.
+* Use big endian order so it is consistent with the serial number
+* written as a hexadecimal string, e.g. 0x1234abcd -> 02:00:12:34:ab:cd
+*/
+   put_unaligned_be32(msm_board_serial(), [2]);
 }
-- 
2.32.0

[PATCH v2 1/2] arm: mach-snapdragon: misc: Initialize eMMC if necessary

[Stephan Gerhold]

At the moment U-Boot produces an empty MAC address (02:00:00:00:00:00)
if the eMMC is not used by anything in U-Boot (e.g. with
CONFIG_ENV_IS_NOWHERE=y instead of having the environment on eMMC).
This happens because then there is nothing that actually initializes
the eMMC and reads the "cid" that is later accessed.

To fix this, call mmc_init() to ensure the eMMC is initialized.
There is no functional difference if the eMMC is already initialized
since then mmc_init() will just return without doing anything.

Reviewed-by: Ramon Fried 
Signed-off-by: Stephan Gerhold 
---

(no changes since v1)

 arch/arm/mach-snapdragon/misc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-snapdragon/misc.c b/arch/arm/mach-snapdragon/misc.c
index 985625a548..fbd5f4d051 100644
--- a/arch/arm/mach-snapdragon/misc.c
+++ b/arch/arm/mach-snapdragon/misc.c
@@ -33,6 +33,9 @@ u32 msm_board_serial(void)
if (!mmc_dev)
return 0;
 
+   if (mmc_init(mmc_dev))
+   return 0;
+
return UNSTUFF_BITS(mmc_dev->cid, 16, 32);
 }
 
-- 
2.32.0

[PATCH 1/2] arm: mach-snapdragon: misc: Initialize eMMC if necessary

[Stephan Gerhold]

At the moment U-Boot produces an empty MAC address (02:00:00:00:00:00)
if the eMMC is not used by anything in U-Boot (e.g. with
CONFIG_ENV_IS_NOWHERE=y instead of having the environment on eMMC).
This happens because then there is nothing that actually initializes
the eMMC and reads the "cid" that is later accessed.

To fix this, call mmc_init() to ensure the eMMC is initialized.
There is no functional difference if the eMMC is already initialized
since then mmc_init() will just return without doing anything.

Cc: Ramon Fried 
Signed-off-by: Stephan Gerhold 
---

 arch/arm/mach-snapdragon/misc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-snapdragon/misc.c b/arch/arm/mach-snapdragon/misc.c
index aaa561c2c6..5c062e9636 100644
--- a/arch/arm/mach-snapdragon/misc.c
+++ b/arch/arm/mach-snapdragon/misc.c
@@ -33,6 +33,9 @@ u32 msm_board_serial(void)
if (!mmc_dev)
return 0;
 
+   if (mmc_init(mmc_dev))
+   return 0;
+
return UNSTUFF_BITS(mmc_dev->cid, 16, 32);
 }
 
-- 
2.32.0

[PATCH 2/2] arm: mach-snapdrgon: misc: Simplify msm_generate_mac_addr()

[Stephan Gerhold]

The logic in msm_generate_mac_addr() was originally taken from the LK
bootloader where the serial number is a string and must be parsed first.
However, in U-Boot msm_board_serial() returns an u32 and
msm_generate_mac_addr() has quite complicated code that will first
print it as a hex string and then immediately parse it again.

What this function actually does at the end is to put the serial number
encoded as big endian (the order used for the hex string) into the u8 *mac.
Use put_unaligned_be32() to do that with bit shifts instead of going
through the string format.

This should be slightly more efficient and cleaner but does not result
in any functional difference.

Cc: Ramon Fried 
Signed-off-by: Stephan Gerhold 
---

 arch/arm/mach-snapdragon/misc.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-snapdragon/misc.c b/arch/arm/mach-snapdragon/misc.c
index 5c062e9636..02edfda5d6 100644
--- a/arch/arm/mach-snapdragon/misc.c
+++ b/arch/arm/mach-snapdragon/misc.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* UNSTUFF_BITS macro taken from Linux Kernel: drivers/mmc/core/sd.c */
 #define UNSTUFF_BITS(resp, start, size) \
@@ -41,16 +42,8 @@ u32 msm_board_serial(void)
 
 void msm_generate_mac_addr(u8 *mac)
 {
-   int i;
-   char sn[9];
-
-   snprintf(sn, 9, "%08x", msm_board_serial());
-
/* fill in the mac with serialno, use locally adminstrated pool */
mac[0] = 0x02;
-   mac[1] = 00;
-   for (i = 3; i >= 0; i--) {
-   mac[i + 2] = simple_strtoul([2 * i], NULL, 16);
-   sn[2 * i] = 0;
-   }
+   mac[1] = 0x00;
+   put_unaligned_be32(msm_board_serial(), [2]);
 }
-- 
2.32.0

Re: [PATCH 3/3] serial: serial_msm: Delay initialization to let pins stabilize

[Stephan Gerhold]

On Wed, Jul 14, 2021 at 11:39:34PM +0300, Ramon Fried wrote:
> On Wed, Jul 14, 2021 at 11:56 AM Stephan Gerhold  wrote:
> >
> > For some reason, the DragonBoard 410c aborts autoboot immediately if
> > U-Boot is started without LK. It looks like it picks up a single broken
> > character via serial and therefore believes a key was pressed to abort
> > autoboot.
> >
> > After some debugging, it seems like adding some delay after pinctrl
> > setup but before UART initialization fixes the issue. It's also worth
> > mentioning that unlike when booting from LK, the pinctrl setup is
> > actually necessary when booting U-Boot without LK since UART is broken
> > if the pinctrl line is removed.
> >
> > I suspect that reconfiguring the pins might take some time to stabilize
> > and if the UART controller is enabled too quickly it will pick up some
> > random noise. Adding a few milliseconds of delay fixes the issue and
> > shouldn't have any other negative side effects.
> >
> > 3ms seems to be the minimum delay required in my tests, use 5ms instead
> > just to be sure.
> >
> > Signed-off-by: Stephan Gerhold 
> > ---
> >
> >  drivers/serial/serial_msm.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c
> > index d8dd5c1104..ac4d0824b9 100644
> > --- a/drivers/serial/serial_msm.c
> > +++ b/drivers/serial/serial_msm.c
> > @@ -18,6 +18,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  /* Serial registers - this driver works in uartdm mode*/
> > @@ -193,6 +194,9 @@ static int msm_uart_clk_init(struct udevice *dev)
> >
> >  static void uart_dm_init(struct msm_serial_data *priv)
> >  {
> > +   /* Delay initialization for a bit to let pins stabilize if 
> > necessary */
> > +   mdelay(5);
> > +
> > writel(priv->clk_bit_rate, priv->base + UARTDM_CSR);
> > writel(0x0, priv->base + UARTDM_MR1);
> > writel(MSM_BOOT_UART_DM_8_N_1_MODE, priv->base + UARTDM_MR2);
> > --
> > 2.32.0
> >
> Eh...this is not a nice fix, perhaps just clearing the RX buffer after
> initialization will work better ?

I don't like it much either but this is the best I came up with even
after spending several hours trying to track down the problem. I also
tried porting more register initialization from LK, probably even
tried clearing the RX buffer again after initialization.

The problem is: In my tests there was no way to get rid of the delay,
because the character doesn't show up until a few milliseconds after
initialization. What you suggest would only work like this:

  
  mdelay(5); // Wait for the weird character to show up
  

Which is not much different (and in fact will take longer) than:

  mdelay(5);
  

So unfortunately I can't think of a way to get rid of the delay. :(

I'm not sure if this is some strange problem of my DB410c, I'd actually
be curious if the problem can also be reproduced on others.

Stephan

[PATCH 2/3] board: dragonboard410c: Fix fastboot

[Stephan Gerhold]

At the moment pressing the volume down key does not actually launch
fastboot. This is because setting "bootdelay" to "-1" actually
disables autoboot and drops to the U-Boot console. It does not execute
the "bootcmd".

The correct value for "bootdelay" here would be "-2", which disables
the delay and key checking and would immediately execute the "bootcmd".

However, even better in this case is using "preboot" to trigger Fastboot.
The advantage is that running "fastboot continue" will actually continue
the autoboot process instead of ending up in the U-Boot shell.

Also make sure to unset "preboot" again immediately in case the user
saves the environment after triggering fastboot.

Cc: Ramon Fried 
Fixes: aa043ee91a47 ("db410c: automatically launch fastboot")
Signed-off-by: Stephan Gerhold 
---

 board/qualcomm/dragonboard410c/dragonboard410c.c | 3 +--
 configs/dragonboard410c_defconfig| 1 +
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/qualcomm/dragonboard410c/dragonboard410c.c 
b/board/qualcomm/dragonboard410c/dragonboard410c.c
index 3b71881cac..371b3262f8 100644
--- a/board/qualcomm/dragonboard410c/dragonboard410c.c
+++ b/board/qualcomm/dragonboard410c/dragonboard410c.c
@@ -132,8 +132,7 @@ int misc_init_r(void)
}
 
if (dm_gpio_get_value()) {
-   env_set("bootdelay", "-1");
-   env_set("bootcmd", "fastboot 0");
+   env_set("preboot", "setenv preboot; fastboot 0");
printf("key_vol_down pressed - Starting fastboot.\n");
}
 
diff --git a/configs/dragonboard410c_defconfig 
b/configs/dragonboard410c_defconfig
index dc9d0d893c..a46283f980 100644
--- a/configs/dragonboard410c_defconfig
+++ b/configs/dragonboard410c_defconfig
@@ -10,6 +10,7 @@ CONFIG_DISTRO_DEFAULTS=y
 # CONFIG_ANDROID_BOOT_IMAGE is not set
 CONFIG_FIT=y
 CONFIG_OF_BOARD_SETUP=y
+CONFIG_USE_PREBOOT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_MISC_INIT_R=y
-- 
2.32.0

[PATCH 3/3] serial: serial_msm: Delay initialization to let pins stabilize

[Stephan Gerhold]

For some reason, the DragonBoard 410c aborts autoboot immediately if
U-Boot is started without LK. It looks like it picks up a single broken
character via serial and therefore believes a key was pressed to abort
autoboot.

After some debugging, it seems like adding some delay after pinctrl
setup but before UART initialization fixes the issue. It's also worth
mentioning that unlike when booting from LK, the pinctrl setup is
actually necessary when booting U-Boot without LK since UART is broken
if the pinctrl line is removed.

I suspect that reconfiguring the pins might take some time to stabilize
and if the UART controller is enabled too quickly it will pick up some
random noise. Adding a few milliseconds of delay fixes the issue and
shouldn't have any other negative side effects.

3ms seems to be the minimum delay required in my tests, use 5ms instead
just to be sure.

Signed-off-by: Stephan Gerhold 
---

 drivers/serial/serial_msm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c
index d8dd5c1104..ac4d0824b9 100644
--- a/drivers/serial/serial_msm.c
+++ b/drivers/serial/serial_msm.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* Serial registers - this driver works in uartdm mode*/
@@ -193,6 +194,9 @@ static int msm_uart_clk_init(struct udevice *dev)
 
 static void uart_dm_init(struct msm_serial_data *priv)
 {
+   /* Delay initialization for a bit to let pins stabilize if necessary */
+   mdelay(5);
+
writel(priv->clk_bit_rate, priv->base + UARTDM_CSR);
writel(0x0, priv->base + UARTDM_MR1);
writel(MSM_BOOT_UART_DM_8_N_1_MODE, priv->base + UARTDM_MR2);
-- 
2.32.0

[PATCH 0/3] board: dragonboard410c: Fix some minor issues

[Stephan Gerhold]

I spent some more time testing the "U-Boot without LK" changes [1] on DB410c
last week and noticed some minor issues that are fixed in this patch series.

Ideally they should be applied on top of [1]. However, actually PATCH 1/3
and PATCH 2/3 are completely unrelated to [1] and could be also applied
independently. PATCH 3/3 is likely directly related to [1].

[1]: https://lore.kernel.org/u-boot/20210707090602.32515-1-step...@gerhold.net/


Stephan Gerhold (3):
  board: dragonboard410c: Fix PHYS_SDRAM_1_SIZE
  board: dragonboard410c: Fix fastboot
  serial: serial_msm: Delay initialization to let pins stabilize

 board/qualcomm/dragonboard410c/dragonboard410c.c | 3 +--
 configs/dragonboard410c_defconfig| 1 +
 drivers/serial/serial_msm.c  | 4 
 include/configs/dragonboard410c.h| 4 ++--
 4 files changed, 8 insertions(+), 4 deletions(-)

-- 
2.32.0

[PATCH 1/3] board: dragonboard410c: Fix PHYS_SDRAM_1_SIZE

[Stephan Gerhold]

The DragonBoard 410c has proprietary firmware from Qualcomm that
reserves 8 MiB of memory for tz/smem/hyp/rmtfs/rfsa from 0x8600
to 0x8680. I'm not aware of any ATF (ARM Trusted Firmware) port
for DB410c that would reserve 30 MiB of memory at the end of RAM.
I suspect the comment might have been copied from hikey.h which has
a very similar comment (and which actually does have an ATF port).

Reducing the memory size just prevents U-Boot from using the end of
the RAM, not the reserved region inbetween. Therefore we might as well
display the correct DRAM size (1 GiB) instead of strange 986 MiB.

Fixes: 626f048bbc14 ("board: Add Qualcomm Dragonboard 410C support")
Signed-off-by: Stephan Gerhold 
---

 include/configs/dragonboard410c.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/dragonboard410c.h 
b/include/configs/dragonboard410c.h
index 1f08508c4d..6474e57b29 100644
--- a/include/configs/dragonboard410c.h
+++ b/include/configs/dragonboard410c.h
@@ -16,8 +16,8 @@
 
 /* Physical Memory Map */
 #define PHYS_SDRAM_1   0x8000
-/* 1008 MB (the last ~30Mb are secured for TrustZone by ATF*/
-#define PHYS_SDRAM_1_SIZE  0x3da0
+/* Note: 8 MiB (0x8600 - 0x8680) are reserved for 
tz/smem/hyp/rmtfs/rfsa */
+#define PHYS_SDRAM_1_SIZE  SZ_1G
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_1
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + 
0x7fff0)
 #define CONFIG_SYS_LOAD_ADDR   (CONFIG_SYS_SDRAM_BASE + 0x8)
-- 
2.32.0

Re: [PATCH] board: dragonboard410c: Load U-Boot directly without LK

[Stephan Gerhold]

On Sat, Jul 10, 2021 at 10:07:28PM +0300, Ramon Fried wrote:
> On Wed, Jul 7, 2021 at 12:06 PM Stephan Gerhold  wrote:
> >
> > At the moment the U-Boot port for the DragonBoard 410c is designed
> > to be loaded as an Android boot image after Qualcomm's Little Kernel (LK)
> > bootloader. This is simple to set up but LK is redundant in this case,
> > since everything done by LK can be also done directly by U-Boot.
> >
> > Dropping LK entirely has at least the following advantages:
> >   - Easier installation/board code (no need for Android boot images)
> >   - (Slightly) faster boot
> >   - Boot directly in 64-bit without a round trip to 32-bit for LK
> >
> > So far this was not possible yet because of unsolved problems:
> >
> >   1. Signing tool: The firmware expects a "signed" ELF image with extra
> >  (Qualcomm-specific) ELF headers, usually used for secure boot.
> >  The DragonBoard 410c does not have secure boot by default but the
> >  extra ELF headers are still required.
> >
> >   2. PSCI bug: There seems to be a bug in the PSCI implementation
> >  (part of the TrustZone/tz firmware) that causes all other CPU cores
> >  to be started in 32-bit mode if LK is missing in the boot chain.
> >  This causes Linux to hang early during boot.
> >
> > There is a solution for both problems now:
> >
> >   1. qtestsign (https://github.com/msm8916-mainline/qtestsign)
> >  can be used as a "signing" tool for U-Boot and other firmware.
> >
> >   2. A workaround for the "PSCI bug" is to execute the TZ syscall when
> >  entering U-Boot. That way PSCI is made aware of the 64-bit switch
> >  and starts all other CPU cores in 64-bit mode as well.
> >
> > Simplify the dragonboard410c board by removing all the extra code that
> > is only used to build an Android boot image that can be loaded by LK.
> > This allows dropping the custom linker script, special image magic,
> > as well as most of the special build/installation instructions.
> >
> > CONFIG_REMAKE_ELF is used to build a new ELF image that has both U-Boot
> > and the appended DTB combined. The resulting u-boot.elf can then be
> > passed to the "signing" tool (e.g. qtestsign).
> >
> > The PSCI workaround is placed in the "boot0" hook that is enabled
> > with CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK. The extra check for EL1 allows
> > compatibility with custom firmware that enters U-Boot in EL2 or EL3,
> > e.g. qhypstub (https://github.com/msm8916-mainline/qhypstub).
> >
> > As a first step these changes apply only to DragonBoard410c.
> > Similar changes could likely also work for the DragonBoard 820c.
> >
> > Note that removing LK wouldn't be possible that easily without a lot of
> > work already done three years ago by Ramon Fried. A lot of missing
> > initialization, pinctrl etc was already added back then even though
> > it was not strictly needed yet.
> >
> > Cc: Ramon Fried 
> > Signed-off-by: Stephan Gerhold 
> > ---
> >
> > Related RFC with even more detailed explanations:
> > https://lore.kernel.org/u-boot/yn2f1c926hff+...@gerhold.net/
> >
> > In my tests both U-Boot and Linux are fully functional with this patch.
> > However, I would appreciate further testing, since my testing does
> > likely not represent a typical usage scenario for the DragonBoard 410c.
> >
> > When testing, please pick the following pending patch additionally:
> >   https://lore.kernel.org/u-boot/20210705121847.48432-1-step...@gerhold.net/
> > on top of u-boot/master.
> >
> > ---
> > [...]
>
> Thanks Stephan, it looks very good.
> I started testing it, it builds correctly and I flashed and everything
> seems to work.
> I do have a problem with my TFTP setup, so I didn't boot Linux yet,
> but I will get to it, if it will boot successfully we can merge this
> one.
> 
> U-boot doesn't know how to boot qcom android kernel partitions, I'm
> not sure this is something I even want to start supporting in U-boot.

It's probably not too hard to support this (I actually boot the same
Android boot images on both LK and U-Boot via "fastboot boot", because
this is the workflow I'm used to). But I agree that anything else
(i.e. reading the images from partitions) is not worth the effort.

> Nico, do you think you can change the format of the BOOT partition to
> host a u-boot FIT image ?
> 

Is a "boot" partition with a binary image even useful at all?
I would expect that all typical Linux distributions except Android have
a separate boot partition with a file system, so setting something up
that works with the generic distro configuration (doc/README.distro)
would be probably best. This would also avoid having to re-build the
image just to change the cmdline for example.

Stephan

[PATCH v2 1/3] power: pmic: Add driver for ST-Ericsson AB8500 via PRCMU

[Stephan Gerhold]

All devices based on ST-Ericsson Ux500 use a PMIC similar to AB8500
(Analog Baseband). There is AB8500, AB8505, AB9540 and AB8540
although in practice only AB8500 and AB8505 are relevant since the
platforms with AB9540 and AB8540 were cancelled and never used in
production.

In general, the AB8500 PMIC uses I2C as control interface, where the
different register banks are represented as separate I2C devices.
However, in practice AB8500 is always connected to a special I2C bus
on the DB8500 SoC that is controlled by the power/reset/clock
management unit (PRCMU) firmware.

Add a simple driver that allows reading/writing registers of the
AB8500 PMIC. The driver directly accesses registers from the PRCMU
parent device (represented by syscon in U-Boot). Abstracting it
further (e.g. with the i2c uclass) would not provide any advantage
because the PRCMU I2C bus is always just connected to AB8500 and
vice-versa.

The ab8500.h header is mostly taken as-is from Linux (with some
minor adjustments) to allow using similar code in both Linux and
U-Boot.

Cc: Linus Walleij 
Signed-off-by: Stephan Gerhold 
---

Changes in v2:
- Add more error checking in prcmu_wait_i2c_mbx_ready()
- Clarify why error is not checked at end of ab8500_transfer()

 drivers/power/pmic/Kconfig  |  10 ++
 drivers/power/pmic/Makefile |   1 +
 drivers/power/pmic/ab8500.c | 268 
 include/power/ab8500.h  | 125 +
 4 files changed, 404 insertions(+)
 create mode 100644 drivers/power/pmic/ab8500.c
 create mode 100644 include/power/ab8500.h

diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index 583fd3ddcd..fd6648b313 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -31,6 +31,16 @@ config SPL_PMIC_CHILDREN
to call your regulator code (e.g. see rk8xx.c for direct functions
for use in SPL).
 
+config PMIC_AB8500
+   bool "Enable driver for ST-Ericsson AB8500 PMIC via PRCMU"
+   depends on DM_PMIC
+   select REGMAP
+   select SYSCON
+   help
+ Enable support for the ST-Ericsson AB8500 (Analog Baseband) PMIC.
+ It connects with the ST-Ericsson DB8500 SoC via an I2C bus managed by
+ the power/reset/clock management unit (PRCMU) firmware.
+
 config PMIC_ACT8846
bool "Enable support for the active-semi 8846 PMIC"
depends on DM_PMIC && DM_I2C
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 89099fde57..5d1a97e5f6 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
 obj-$(CONFIG_$(SPL_)DM_PMIC_PCA9450) += pca9450.o
 obj-$(CONFIG_PMIC_S2MPS11) += s2mps11.o
 obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
+obj-$(CONFIG_PMIC_AB8500) += ab8500.o
 obj-$(CONFIG_PMIC_ACT8846) += act8846.o
 obj-$(CONFIG_PMIC_AS3722) += as3722.o as3722_gpio.o
 obj-$(CONFIG_PMIC_MAX8997) += max8997.o
diff --git a/drivers/power/pmic/ab8500.c b/drivers/power/pmic/ab8500.c
new file mode 100644
index 00..1f64f217c3
--- /dev/null
+++ b/drivers/power/pmic/ab8500.c
@@ -0,0 +1,268 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Stephan Gerhold
+ *
+ * Adapted from old U-Boot and Linux kernel implementation:
+ * Copyright (C) STMicroelectronics 2009
+ * Copyright (C) ST-Ericsson SA 2010
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* CPU mailbox registers */
+#define PRCM_MBOX_CPU_VAL  0x0fc
+#define PRCM_MBOX_CPU_SET  0x100
+#define PRCM_MBOX_CPU_CLR  0x104
+
+#define PRCM_ARM_IT1_CLR   0x48C
+#define PRCM_ARM_IT1_VAL   0x494
+
+#define PRCM_TCDM_RANGE2
+#define PRCM_REQ_MB5   0xE44
+#define PRCM_ACK_MB5   0xDF4
+#define _PRCM_MBOX_HEADER  0xFE8
+#define PRCM_MBOX_HEADER_REQ_MB5   (_PRCM_MBOX_HEADER + 0x5)
+#define PRCMU_I2C_MBOX_BIT BIT(5)
+
+/* Mailbox 5 Requests */
+#define PRCM_REQ_MB5_I2C_SLAVE_OP  (PRCM_REQ_MB5 + 0x0)
+#define PRCM_REQ_MB5_I2C_HW_BITS   (PRCM_REQ_MB5 + 0x1)
+#define PRCM_REQ_MB5_I2C_REG   (PRCM_REQ_MB5 + 0x2)
+#define PRCM_REQ_MB5_I2C_VAL   (PRCM_REQ_MB5 + 0x3)
+#define PRCMU_I2C(bank)(((bank) << 1) | BIT(6))
+#define PRCMU_I2C_WRITE0
+#define PRCMU_I2C_READ 1
+#define PRCMU_I2C_STOP_EN  BIT(3)
+
+/* Mailbox 5 ACKs */
+#define PRCM_ACK_MB5_I2C_STATUS(PRCM_ACK_MB5 + 0x1)
+#define PRCM_ACK_MB5_I2C_VAL   (PRCM_ACK_MB5 + 0x3)
+#define PRCMU_I2C_WR_OK0x1
+#define PRCMU_I2C_RD_OK0x2
+
+/* AB8500 version registers */
+#define AB8500_MISC_REV_REGAB8500_MISC(0x80)
+#define AB8500_MISC_IC_NAME_REGAB8500_MISC(0x82)
+
+struct a

[PATCH v2 0/3] Add support for USB on ST-Ericsson Ux500

[Stephan Gerhold]

This patch series adds support for USB on ST-Ericsson Ux500 by:
  - Adding a driver to talk to the AB8500 PMIC
  - Adding a driver to enable the USB PHY
  - Adding a simple Ux500 glue driver for the musb-new driver

This was tested on the u8500 "stemmy" board that is already present
in U-Boot.

Changes in v2:
- Add more error checking in prcmu_wait_i2c_mbx_ready()
- Clarify why error is not checked at end of ab8500_transfer()
- Assign AB8500_BIT_PHY_CTRL_DEVICE_EN by default and only replace
  it with AB8500_BIT_PHY_CTRL_HOST_EN if needed (Jaehoon Chung)

Stephan Gerhold (3):
  power: pmic: Add driver for ST-Ericsson AB8500 via PRCMU
  phy: Add driver for ST-Ericsson AB8500 USB PHY
  usb: musb-new: Add glue driver for ST-Ericsson Ux500

 drivers/phy/Kconfig  |   6 +
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-ab8500-usb.c |  52 ++
 drivers/power/pmic/Kconfig   |  10 ++
 drivers/power/pmic/Makefile  |   1 +
 drivers/power/pmic/ab8500.c  | 268 +++
 drivers/usb/musb-new/Kconfig |  11 +-
 drivers/usb/musb-new/Makefile|   1 +
 drivers/usb/musb-new/musb_core.c |   2 +-
 drivers/usb/musb-new/ux500.c | 179 +
 include/power/ab8500.h   | 125 ++
 11 files changed, 654 insertions(+), 2 deletions(-)
 create mode 100644 drivers/phy/phy-ab8500-usb.c
 create mode 100644 drivers/power/pmic/ab8500.c
 create mode 100644 drivers/usb/musb-new/ux500.c
 create mode 100644 include/power/ab8500.h

-- 
2.32.0

[PATCH v2 3/3] usb: musb-new: Add glue driver for ST-Ericsson Ux500

[Stephan Gerhold]

The ST-Ericsson DB8500 SoC contains a MUSB OTG controller which
supports both host and gadget mode. For some reason there is
nothing special about it - add a simple glue driver for Ux500
that literally just sets up MUSB together with a generic PHY.
There are no SoC-specific registers etc needed to make USB work.

The new Ux500 glue driver is only tested to work with DM_USB
and DM_USB_GADGET. Both host and gadget mode work fine on
the u8500 "stemmy" board that is already present in U-Boot.

Reviewed-by: Linus Walleij 
Signed-off-by: Stephan Gerhold 
---

(no changes since v1)

This patch could be applied separately from the first two if
needed. There is a functional runtime dependency but not
a compile time dependency with the PMIC changes in the first
two patches.

---
 drivers/usb/musb-new/Kconfig |  11 +-
 drivers/usb/musb-new/Makefile|   1 +
 drivers/usb/musb-new/musb_core.c |   2 +-
 drivers/usb/musb-new/ux500.c | 179 +++
 4 files changed, 191 insertions(+), 2 deletions(-)
 create mode 100644 drivers/usb/musb-new/ux500.c

diff --git a/drivers/usb/musb-new/Kconfig b/drivers/usb/musb-new/Kconfig
index fd6f4109b0..81ceea9740 100644
--- a/drivers/usb/musb-new/Kconfig
+++ b/drivers/usb/musb-new/Kconfig
@@ -72,6 +72,15 @@ config USB_MUSB_SUNXI
Say y here to enable support for the sunxi OTG / DRC USB controller
used on almost all sunxi boards.
 
+config USB_MUSB_UX500
+   bool "Enable ST-Ericsson Ux500 USB controller"
+   depends on DM_USB && DM_USB_GADGET && ARCH_U8500
+   default y
+   help
+ Say y to enable support for the MUSB OTG USB controller used in
+ ST-Ericsson Ux500. The driver supports either gadget or host mode
+ based on the selection of CONFIG_USB_MUSB_HOST.
+
 config USB_MUSB_DISABLE_BULK_COMBINE_SPLIT
bool "Disable MUSB bulk split/combine"
default y
@@ -85,7 +94,7 @@ endif
 
 config USB_MUSB_PIO_ONLY
bool "Disable DMA (always use PIO)"
-   default y if USB_MUSB_AM35X || USB_MUSB_PIC32 || USB_MUSB_OMAP2PLUS || 
USB_MUSB_DSPS || USB_MUSB_SUNXI || USB_MUSB_MT85XX
+   default y if USB_MUSB_AM35X || USB_MUSB_PIC32 || USB_MUSB_OMAP2PLUS || 
USB_MUSB_DSPS || USB_MUSB_SUNXI || USB_MUSB_MT85XX || USB_MUSB_UX500
help
  All data is copied between memory and FIFO by the CPU.
  DMA controllers are ignored.
diff --git a/drivers/usb/musb-new/Makefile b/drivers/usb/musb-new/Makefile
index 6355eb12dd..396ff02654 100644
--- a/drivers/usb/musb-new/Makefile
+++ b/drivers/usb/musb-new/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_MUSB_OMAP2PLUS) += omap2430.o
 obj-$(CONFIG_USB_MUSB_PIC32) += pic32.o
 obj-$(CONFIG_USB_MUSB_SUNXI) += sunxi.o
 obj-$(CONFIG_USB_MUSB_TI) += ti-musb.o
+obj-$(CONFIG_USB_MUSB_UX500) += ux500.o
 
 ccflags-y := $(call cc-option,-Wno-unused-variable) \
$(call cc-option,-Wno-unused-but-set-variable) \
diff --git a/drivers/usb/musb-new/musb_core.c b/drivers/usb/musb-new/musb_core.c
index 22811a5efb..18d9bc805f 100644
--- a/drivers/usb/musb-new/musb_core.c
+++ b/drivers/usb/musb-new/musb_core.c
@@ -1526,7 +1526,7 @@ static int __devinit musb_core_init(u16 musb_type, struct 
musb *musb)
 /*-*/
 
 #if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430) || \
-   defined(CONFIG_ARCH_OMAP4)
+   defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500)
 
 static irqreturn_t generic_interrupt(int irq, void *__hci)
 {
diff --git a/drivers/usb/musb-new/ux500.c b/drivers/usb/musb-new/ux500.c
new file mode 100644
index 00..57c7d5630d
--- /dev/null
+++ b/drivers/usb/musb-new/ux500.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2019 Stephan Gerhold */
+
+#include 
+#include 
+#include 
+#include 
+#include "musb_uboot.h"
+
+static struct musb_hdrc_config ux500_musb_hdrc_config = {
+   .multipoint = true,
+   .dyn_fifo   = true,
+   .num_eps= 16,
+   .ram_bits   = 16,
+};
+
+struct ux500_glue {
+   struct musb_host_data mdata;
+   struct device dev;
+   struct phy phy;
+   bool enabled;
+};
+#define to_ux500_glue(d)   container_of(d, struct ux500_glue, dev)
+
+static int ux500_musb_enable(struct musb *musb)
+{
+   struct ux500_glue *glue = to_ux500_glue(musb->controller);
+   int ret;
+
+   if (glue->enabled)
+   return 0;
+
+   ret = generic_phy_power_on(>phy);
+   if (ret) {
+   printf("%s: failed to power on USB PHY\n", __func__);
+   return ret;
+   }
+
+   glue->enabled = true;
+   return 0;
+}
+
+static void ux500_musb_disable(struct musb *musb)
+{
+   struct ux500_glue *glue = to_ux500_glue(musb->controller);
+   int ret;
+
+   if (!glue->enabled)
+   return;
+
+   ret = g

[PATCH v2 2/3] phy: Add driver for ST-Ericsson AB8500 USB PHY

[Stephan Gerhold]

The AB8500 PMIC contains an USB PHY that needs to be set up in
device or host mode to make USB work properly. Add a simple driver
for the generic PHY uclass that allows enabling it.

The if (CONFIG_IS_ENABLED(USB_MUSB_HOST)) might be a bit strange.
The USB PHY must be configured in either host or device mode and
somehow the USB PHY driver must be made aware of the mode.

Actually, the MUSB driver used together with this PHY does not
support dynamic selection of host/device mode in U-Boot at the moment.
Therefore, one very simple approach that works fine is to select
the mode to configure at compile time. When the MUSB driver is
configured in host mode the PHY is configured in host mode, and
similarly when the MUSB driver is configured in device/gadget mode.

Reviewed-by: Linus Walleij 
Signed-off-by: Stephan Gerhold 
---

Changes in v2:
- Assign AB8500_BIT_PHY_CTRL_DEVICE_EN by default and only replace
  it with AB8500_BIT_PHY_CTRL_HOST_EN if needed (Jaehoon Chung)

Better suggestions to make the USB PHY driver aware of the mode
are very welcome. :) I'm not sure it's worth it though, the compile
time selection is not ideal but it does the job just fine for now.

---
 drivers/phy/Kconfig  |  6 +
 drivers/phy/Makefile |  1 +
 drivers/phy/phy-ab8500-usb.c | 52 
 3 files changed, 59 insertions(+)
 create mode 100644 drivers/phy/phy-ab8500-usb.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 008186a10d..92c74b9d0b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -64,6 +64,12 @@ config MIPI_DPHY_HELPERS
help
  Provides a number of helpers a core functions for MIPI D-PHY drivers.
 
+config AB8500_USB_PHY
+   bool "AB8500 USB PHY Driver"
+   depends on PHY && PMIC_AB8500
+   help
+ Support for the USB OTG PHY in ST-Ericsson AB8500.
+
 config BCM6318_USBH_PHY
bool "BCM6318 USBH PHY support"
depends on PHY && ARCH_BMIPS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 3c4a673a83..bf03d05d9b 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_$(SPL_)PHY) += phy-uclass.o
 obj-$(CONFIG_$(SPL_)NOP_PHY) += nop-phy.o
 obj-$(CONFIG_MIPI_DPHY_HELPERS) += phy-core-mipi-dphy.o
+obj-$(CONFIG_AB8500_USB_PHY) += phy-ab8500-usb.o
 obj-$(CONFIG_BCM6318_USBH_PHY) += bcm6318-usbh-phy.o
 obj-$(CONFIG_BCM6348_USBH_PHY) += bcm6348-usbh-phy.o
 obj-$(CONFIG_BCM6358_USBH_PHY) += bcm6358-usbh-phy.o
diff --git a/drivers/phy/phy-ab8500-usb.c b/drivers/phy/phy-ab8500-usb.c
new file mode 100644
index 00..0e04595717
--- /dev/null
+++ b/drivers/phy/phy-ab8500-usb.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2019 Stephan Gerhold */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AB8500_USB_PHY_CTRL_REGAB8500_USB(0x8A)
+#define AB8500_BIT_PHY_CTRL_HOST_ENBIT(0)
+#define AB8500_BIT_PHY_CTRL_DEVICE_EN  BIT(1)
+#define AB8500_USB_PHY_CTRL_MASK   (AB8500_BIT_PHY_CTRL_HOST_EN |\
+AB8500_BIT_PHY_CTRL_DEVICE_EN)
+
+static int ab8500_usb_phy_power_on(struct phy *phy)
+{
+   struct udevice *dev = phy->dev;
+   uint set = AB8500_BIT_PHY_CTRL_DEVICE_EN;
+
+   if (CONFIG_IS_ENABLED(USB_MUSB_HOST))
+   set = AB8500_BIT_PHY_CTRL_HOST_EN;
+
+   return pmic_clrsetbits(dev->parent, AB8500_USB_PHY_CTRL_REG,
+  AB8500_USB_PHY_CTRL_MASK, set);
+}
+
+static int ab8500_usb_phy_power_off(struct phy *phy)
+{
+   struct udevice *dev = phy->dev;
+
+   return pmic_clrsetbits(dev->parent, AB8500_USB_PHY_CTRL_REG,
+  AB8500_USB_PHY_CTRL_MASK, 0);
+}
+
+struct phy_ops ab8500_usb_phy_ops = {
+   .power_on = ab8500_usb_phy_power_on,
+   .power_off = ab8500_usb_phy_power_off,
+};
+
+static const struct udevice_id ab8500_usb_phy_ids[] = {
+   { .compatible = "stericsson,ab8500-usb" },
+   { }
+};
+
+U_BOOT_DRIVER(ab8500_usb_phy) = {
+   .name = "ab8500_usb_phy",
+   .id = UCLASS_PHY,
+   .of_match = ab8500_usb_phy_ids,
+   .ops = _usb_phy_ops,
+};
-- 
2.32.0

Re: [PATCH 1/3] power: pmic: Add driver for ST-Ericsson AB8500 via PRCMU

[Stephan Gerhold]

On Wed, Jul 07, 2021 at 06:25:37AM +0900, Jaehoon Chung wrote:
> On 7/6/21 5:52 PM, Stephan Gerhold wrote:
> > On Tue, Jul 06, 2021 at 10:08:03AM +0900, Jaehoon Chung wrote:
> >> On 7/6/21 1:28 AM, Stephan Gerhold wrote:
> >>> All devices based on ST-Ericsson Ux500 use a PMIC similar to AB8500
> >>> (Analog Baseband). There is AB8500, AB8505, AB9540 and AB8540
> >>> although in practice only AB8500 and AB8505 are relevant since the
> >>> platforms with AB9540 and AB8540 were cancelled and never used in
> >>> production.
> >>>
> >>> In general, the AB8500 PMIC uses I2C as control interface, where the
> >>> different register banks are represented as separate I2C devices.
> >>> However, in practice AB8500 is always connected to a special I2C bus
> >>> on the DB8500 SoC that is controlled by the power/reset/clock
> >>> management unit (PRCMU) firmware.
> >>>
> >>> Add a simple driver that allows reading/writing registers of the
> >>> AB8500 PMIC. The driver directly accesses registers from the PRCMU
> >>> parent device (represented by syscon in U-Boot). Abstracting it
> >>> further (e.g. with the i2c uclass) would not provide any advantage
> >>> because the PRCMU I2C bus is always just connected to AB8500 and
> >>> vice-versa.
> >>>
> >>> The ab8500.h header is mostly taken as-is from Linux (with some
> >>> minor adjustments) to allow using similar code in both Linux and
> >>> U-Boot.
> >>>
> >>> Cc: Linus Walleij 
> >>> Signed-off-by: Stephan Gerhold 
> >>> ---
> >>>
> >>>  drivers/power/pmic/Kconfig  |  10 ++
> >>>  drivers/power/pmic/Makefile |   1 +
> >>>  drivers/power/pmic/ab8500.c | 258 
> >>>  include/power/ab8500.h  | 125 +
> >>>  4 files changed, 394 insertions(+)
> >>>  create mode 100644 drivers/power/pmic/ab8500.c
> >>>  create mode 100644 include/power/ab8500.h
> >>>
> >>> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> >>> index 583fd3ddcd..fd6648b313 100644
> >>> --- a/drivers/power/pmic/Kconfig
> >>> +++ b/drivers/power/pmic/Kconfig
> >>> @@ -31,6 +31,16 @@ config SPL_PMIC_CHILDREN
> >>>   to call your regulator code (e.g. see rk8xx.c for direct functions
> >>>   for use in SPL).
> >>>  
> >>> +config PMIC_AB8500
> >>> + bool "Enable driver for ST-Ericsson AB8500 PMIC via PRCMU"
> >>> + depends on DM_PMIC
> >>> + select REGMAP
> >>> + select SYSCON
> >>> + help
> >>> +   Enable support for the ST-Ericsson AB8500 (Analog Baseband) PMIC.
> >>> +   It connects with the ST-Ericsson DB8500 SoC via an I2C bus managed by
> >>> +   the power/reset/clock management unit (PRCMU) firmware.
> >>> +
> >>>  config PMIC_ACT8846
> >>>   bool "Enable support for the active-semi 8846 PMIC"
> >>>   depends on DM_PMIC && DM_I2C
> >>> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> >>> index 89099fde57..5d1a97e5f6 100644
> >>> --- a/drivers/power/pmic/Makefile
> >>> +++ b/drivers/power/pmic/Makefile
> >>> @@ -15,6 +15,7 @@ obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
> >>>  obj-$(CONFIG_$(SPL_)DM_PMIC_PCA9450) += pca9450.o
> >>>  obj-$(CONFIG_PMIC_S2MPS11) += s2mps11.o
> >>>  obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
> >>> +obj-$(CONFIG_PMIC_AB8500) += ab8500.o
> >>>  obj-$(CONFIG_PMIC_ACT8846) += act8846.o
> >>>  obj-$(CONFIG_PMIC_AS3722) += as3722.o as3722_gpio.o
> >>>  obj-$(CONFIG_PMIC_MAX8997) += max8997.o
> >>> diff --git a/drivers/power/pmic/ab8500.c b/drivers/power/pmic/ab8500.c
> >>> new file mode 100644
> >>> index 00..a87a3b497c
> >>> --- /dev/null
> >>> +++ b/drivers/power/pmic/ab8500.c
> >>> @@ -0,0 +1,258 @@
> >>> +// SPDX-License-Identifier: GPL-2.0+
> >>> +/*
> >>> + * Copyright (C) 2019 Stephan Gerhold
> >>> + *
> >>> + * Adapted from old U-Boot and Linux kernel implementation:
> >>> + * Copyright (C) STMicroelectronics 2009
> >>> + * Copyright (C) ST-Ericsson SA 2010
> >>> + */
> >>> +
> >>> +#include 
> >>>

[PATCH 2/2] board: stemmy: Copy atags for booting downstream/vendor kernel

[Stephan Gerhold]

The U-Boot "stemmy" board is mainly intended to simplify booting
mainline Linux on various smartphones from Samsung based on ST-Ericsson
Ux500. While the mainline kernel is working great, there are still some
features missing there. In particular, it is currently not possible to
charge the battery when using the mainline kernel.

This means that it is still necessary to boot the downstream/vendor
kernel from Samsung sometimes to charge the device. That kernel is
ancient, still uses board files + ATAGS instead of device trees and
relies on a strange very long kernel command line hardcoded in the
Samsung bootloader.

Actually, since mainline is booted with device trees there is a very
simple way to make the old downstream kernel work as well: We can
simply take most of the ATAGS passed to U-Boot from the Samsung
bootloader and copy them as-is when booting a kernel without device
tree. That way the long command line and other needed ATAGS are copied
as-is without having to bother with them.

The only exception is the ATAG_INITRD - since the initrd is loaded
by U-Boot, the atag for that should be generated in U-Boot so it points
to the correct address. All other ATAGS are copied as-is and not
generated in U-Boot.

Also use the chance and provide a serial# for U-Boot by parsing the
ATAG_SERIAL that is also passed by the Samsung bootloader.

Signed-off-by: Stephan Gerhold 
---

 arch/arm/mach-u8500/Kconfig |  1 +
 board/ste/stemmy/stemmy.c   | 87 +
 include/configs/stemmy.h|  3 ++
 3 files changed, 91 insertions(+)

diff --git a/arch/arm/mach-u8500/Kconfig b/arch/arm/mach-u8500/Kconfig
index 372fbeb80f..db7a29a54c 100644
--- a/arch/arm/mach-u8500/Kconfig
+++ b/arch/arm/mach-u8500/Kconfig
@@ -8,6 +8,7 @@ choice
 
 config TARGET_STEMMY
bool "Samsung (stemmy) board"
+   select MISC_INIT_R
help
  The Samsung "stemmy" board supports Samsung smartphones released with
  the ST-Ericsson NovaThor U8500 SoC, e.g.
diff --git a/board/ste/stemmy/stemmy.c b/board/ste/stemmy/stemmy.c
index 9e6c8e208e..5f1150c0c7 100644
--- a/board/ste/stemmy/stemmy.c
+++ b/board/ste/stemmy/stemmy.c
@@ -3,8 +3,10 @@
  * Copyright (C) 2019 Stephan Gerhold 
  */
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -15,6 +17,9 @@ DECLARE_GLOBAL_DATA_PTR;
 static ulong fw_mach __section(".data");
 static ulong fw_atags __section(".data");
 
+static const struct tag *fw_atags_copy;
+static uint fw_atags_size;
+
 void save_boot_params(ulong r0, ulong r1, ulong r2, ulong r3)
 {
fw_mach = r1;
@@ -78,3 +83,85 @@ int board_init(void)
gd->bd->bi_boot_params = fw_atags;
return 0;
 }
+
+static void parse_serial(const struct tag_serialnr *serialnr)
+{
+   char serial[17];
+
+   if (env_get("serial#"))
+   return;
+
+   sprintf(serial, "%08x%08x", serialnr->high, serialnr->low);
+   env_set("serial#", serial);
+}
+
+/*
+ * The downstream/vendor kernel (provided by Samsung) uses ATAGS for booting.
+ * It also requires an extremely long cmdline provided by the primary 
bootloader
+ * that is not suitable for booting mainline.
+ *
+ * Since downstream is the only user of ATAGS, we emulate the behavior of the
+ * Samsung bootloader by generating only the initrd atag in U-Boot, and copying
+ * all other ATAGS as-is from the primary bootloader.
+ */
+static inline bool skip_atag(u32 tag)
+{
+   return (tag == ATAG_NONE || tag == ATAG_CORE ||
+   tag == ATAG_INITRD || tag == ATAG_INITRD2);
+}
+
+static void copy_atags(const struct tag *tags)
+{
+   const struct tag *t;
+   struct tag *copy;
+
+   if (!tags)
+   return;
+
+   /* Calculate necessary size for tags we want to copy */
+   for_each_tag(t, tags) {
+   if (skip_atag(t->hdr.tag))
+   continue;
+
+   if (t->hdr.tag == ATAG_SERIAL)
+   parse_serial(>u.serialnr);
+
+   fw_atags_size += t->hdr.size * sizeof(u32);
+   }
+
+   if (!fw_atags_size)
+   return;  /* No tags to copy */
+
+   copy = malloc(fw_atags_size);
+   if (!copy)
+   return;
+   fw_atags_copy = copy;
+
+   /* Copy tags */
+   for_each_tag(t, tags) {
+   if (skip_atag(t->hdr.tag))
+   continue;
+
+   memcpy(copy, t, t->hdr.size * sizeof(u32));
+   copy = tag_next(copy);
+   }
+}
+
+int misc_init_r(void)
+{
+   copy_atags(fw_atags_get());
+   return 0;
+}
+
+void setup_board_tags(struct tag **in_params)
+{
+   if (!fw_atags_copy)
+   return;
+
+   /*
+* fw_atags_copy contains only full "struct tag" (plus data)
+* so copying it bytewise here should be fine.
+*/
+   memcpy(*in_param

[PATCH 1/2] board: stemmy: Parse atags to get available memory

[Stephan Gerhold]

At the moment the "stemmy" board attempts to detect the RAM size with
a simple memory test (get_ram_size()). Unfortunately, this does not work
correctly for devices with 768 MiB RAM (e.g. Samsung Galaxy Ace 2
(GT-I8160), "codina"). Reading/writing memory after the 768 MiB RAM
succeeds but actually overwrites some earlier parts of the memory.

For U-Boot this does not result in any major problems, but on Linux
this will eventually lead to strange crashes because of the memory
corruption.

Since the "stemmy" U-Boot port is designed to be chainloaded from
the original Samsung bootloader, the most reliable way to get the
available amount of RAM is to look at the ATAGS passed by the Samsung
bootloader. Fortunately, the header used to generate ATAGS in U-Boot
(asm/setup.h) can also be easily used to parse them.

Also clarify and simplify stemmy.h a bit to make it more clear where
some of the magic values in there are actually coming from.

Signed-off-by: Stephan Gerhold 
---

 arch/arm/mach-u8500/Kconfig |  1 +
 board/ste/stemmy/README |  1 +
 board/ste/stemmy/stemmy.c   | 62 -
 configs/stemmy_defconfig|  2 +-
 include/configs/stemmy.h| 23 ++
 5 files changed, 74 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-u8500/Kconfig b/arch/arm/mach-u8500/Kconfig
index 7478deb25f..372fbeb80f 100644
--- a/arch/arm/mach-u8500/Kconfig
+++ b/arch/arm/mach-u8500/Kconfig
@@ -15,6 +15,7 @@ config TARGET_STEMMY
  - Samsung Galaxy S III mini (GT-I8190)"golden"
  - Samsung Galaxy S Advance (GT-I9070) "janice"
  - Samsung Galaxy Xcover 2 (GT-S7710)  "skomer"
+ - Samsung Galaxy Ace 2 (GT-I8160) "codina"
 
  and likely others as well (untested).
 
diff --git a/board/ste/stemmy/README b/board/ste/stemmy/README
index 81f72426f2..1b83b833c0 100644
--- a/board/ste/stemmy/README
+++ b/board/ste/stemmy/README
@@ -7,6 +7,7 @@ the ST-Ericsson NovaThor U8500 SoC, e.g.
- Samsung Galaxy S III mini (GT-I8190)  "golden"
- Samsung Galaxy S Advance (GT-I9070)   "janice"
- Samsung Galaxy Xcover 2 (GT-S7710)"skomer"
+   - Samsung Galaxy Ace 2 (GT-I8160)   "codina"
 
 and likely others as well (untested).
 
diff --git a/board/ste/stemmy/stemmy.c b/board/ste/stemmy/stemmy.c
index b9b2a6fddc..9e6c8e208e 100644
--- a/board/ste/stemmy/stemmy.c
+++ b/board/ste/stemmy/stemmy.c
@@ -4,17 +4,77 @@
  */
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
+/* Parse atags provided by Samsung bootloader to get available memory */
+static ulong fw_mach __section(".data");
+static ulong fw_atags __section(".data");
+
+void save_boot_params(ulong r0, ulong r1, ulong r2, ulong r3)
+{
+   fw_mach = r1;
+   fw_atags = r2;
+   save_boot_params_ret();
+}
+
+static const struct tag *fw_atags_get(void)
+{
+   const struct tag *tags = (const struct tag *)fw_atags;
+
+   if (tags->hdr.tag != ATAG_CORE) {
+   log_err("Invalid atags: tag 0x%x at %p\n", tags->hdr.tag, tags);
+   return NULL;
+   }
+
+   return tags;
+}
+
 int dram_init(void)
 {
-   gd->ram_size = get_ram_size(CONFIG_SYS_SDRAM_BASE, 
CONFIG_SYS_SDRAM_SIZE);
+   const struct tag *t, *tags = fw_atags_get();
+
+   if (!tags)
+   return -EINVAL;
+
+   for_each_tag(t, tags) {
+   if (t->hdr.tag != ATAG_MEM)
+   continue;
+
+   debug("Memory: %#x-%#x (size %#x)\n", t->u.mem.start,
+ t->u.mem.start + t->u.mem.size, t->u.mem.size);
+   gd->ram_size += t->u.mem.size;
+   }
+   return 0;
+}
+
+int dram_init_banksize(void)
+{
+   const struct tag *t, *tags = fw_atags_get();
+   unsigned int bank = 0;
+
+   if (!tags)
+   return -EINVAL;
+
+   for_each_tag(t, tags) {
+   if (t->hdr.tag != ATAG_MEM)
+   continue;
+
+   gd->bd->bi_dram[bank].start = t->u.mem.start;
+   gd->bd->bi_dram[bank].size = t->u.mem.size;
+   if (++bank == CONFIG_NR_DRAM_BANKS)
+   break;
+   }
return 0;
 }
 
 int board_init(void)
 {
+   gd->bd->bi_arch_number = fw_mach;
+   gd->bd->bi_boot_params = fw_atags;
return 0;
 }
diff --git a/configs/stemmy_defconfig b/configs/stemmy_defconfig
index 79c05acc6a..f31960b814 100644
--- a/configs/stemmy_defconfig
+++ b/configs/stemmy_defconfig
@@ -1,7 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_U8500=y
 CONFIG_SYS_TEXT_BASE=0x10
-CONFIG_NR_DRAM_BANKS=1
+CONFIG_NR_DRAM_BANKS=2
 CONFIG_DEFAULT_DEVICE_TREE="ste-ux500-samsung-stemmy"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CO

[PATCH] board: dragonboard410c: Load U-Boot directly without LK

[Stephan Gerhold]

At the moment the U-Boot port for the DragonBoard 410c is designed
to be loaded as an Android boot image after Qualcomm's Little Kernel (LK)
bootloader. This is simple to set up but LK is redundant in this case,
since everything done by LK can be also done directly by U-Boot.

Dropping LK entirely has at least the following advantages:
  - Easier installation/board code (no need for Android boot images)
  - (Slightly) faster boot
  - Boot directly in 64-bit without a round trip to 32-bit for LK

So far this was not possible yet because of unsolved problems:

  1. Signing tool: The firmware expects a "signed" ELF image with extra
 (Qualcomm-specific) ELF headers, usually used for secure boot.
 The DragonBoard 410c does not have secure boot by default but the
 extra ELF headers are still required.

  2. PSCI bug: There seems to be a bug in the PSCI implementation
 (part of the TrustZone/tz firmware) that causes all other CPU cores
 to be started in 32-bit mode if LK is missing in the boot chain.
 This causes Linux to hang early during boot.

There is a solution for both problems now:

  1. qtestsign (https://github.com/msm8916-mainline/qtestsign)
 can be used as a "signing" tool for U-Boot and other firmware.

  2. A workaround for the "PSCI bug" is to execute the TZ syscall when
 entering U-Boot. That way PSCI is made aware of the 64-bit switch
 and starts all other CPU cores in 64-bit mode as well.

Simplify the dragonboard410c board by removing all the extra code that
is only used to build an Android boot image that can be loaded by LK.
This allows dropping the custom linker script, special image magic,
as well as most of the special build/installation instructions.

CONFIG_REMAKE_ELF is used to build a new ELF image that has both U-Boot
and the appended DTB combined. The resulting u-boot.elf can then be
passed to the "signing" tool (e.g. qtestsign).

The PSCI workaround is placed in the "boot0" hook that is enabled
with CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK. The extra check for EL1 allows
compatibility with custom firmware that enters U-Boot in EL2 or EL3,
e.g. qhypstub (https://github.com/msm8916-mainline/qhypstub).

As a first step these changes apply only to DragonBoard410c.
Similar changes could likely also work for the DragonBoard 820c.

Note that removing LK wouldn't be possible that easily without a lot of
work already done three years ago by Ramon Fried. A lot of missing
initialization, pinctrl etc was already added back then even though
it was not strictly needed yet.

Cc: Ramon Fried 
Signed-off-by: Stephan Gerhold 
---

Related RFC with even more detailed explanations:
https://lore.kernel.org/u-boot/yn2f1c926hff+...@gerhold.net/

In my tests both U-Boot and Linux are fully functional with this patch.
However, I would appreciate further testing, since my testing does
likely not represent a typical usage scenario for the DragonBoard 410c.

When testing, please pick the following pending patch additionally:
  https://lore.kernel.org/u-boot/20210705121847.48432-1-step...@gerhold.net/
on top of u-boot/master.

---
 arch/arm/mach-snapdragon/Kconfig  |   1 +
 arch/arm/mach-snapdragon/include/mach/boot0.h |  54 
 board/qualcomm/dragonboard410c/MAINTAINERS|   1 +
 board/qualcomm/dragonboard410c/Makefile   |   2 -
 .../dragonboard410c/dragonboard410c.c |  13 --
 board/qualcomm/dragonboard410c/head.S |  33 -
 .../qualcomm/dragonboard410c/lowlevel_init.S  |  27 
 board/qualcomm/dragonboard410c/readme.txt |  73 +--
 board/qualcomm/dragonboard410c/u-boot.lds | 118 --
 configs/dragonboard410c_defconfig |   2 +-
 doc/board/index.rst   |   1 +
 doc/board/qualcomm/dragonboard410c.rst|  45 +++
 doc/board/qualcomm/index.rst  |   9 ++
 include/configs/dragonboard410c.h |   3 +
 14 files changed, 120 insertions(+), 262 deletions(-)
 create mode 100644 arch/arm/mach-snapdragon/include/mach/boot0.h
 delete mode 100644 board/qualcomm/dragonboard410c/head.S
 delete mode 100644 board/qualcomm/dragonboard410c/lowlevel_init.S
 delete mode 100644 board/qualcomm/dragonboard410c/u-boot.lds
 create mode 100644 doc/board/qualcomm/dragonboard410c.rst
 create mode 100644 doc/board/qualcomm/index.rst

diff --git a/arch/arm/mach-snapdragon/Kconfig b/arch/arm/mach-snapdragon/Kconfig
index e562d693c6..0ec74fa5d3 100644
--- a/arch/arm/mach-snapdragon/Kconfig
+++ b/arch/arm/mach-snapdragon/Kconfig
@@ -15,6 +15,7 @@ choice
 config TARGET_DRAGONBOARD410C
bool "96Boards Dragonboard 410C"
select BOARD_LATE_INIT
+   select ENABLE_ARM_SOC_BOOT0_HOOK
help
  Support for 96Boards Dragonboard 410C. This board complies with
  96Board Open Platform Specifications. Features:
diff --git a/arch/arm/mach-snapdragon/include/mach/boot0.h 
b/arch/arm/mac

[PATCH 3/4] mmc: arm_pl180_mmci: Simplify code using mmc_of_parse()

[Stephan Gerhold]

Simplify the code a bit by using the common mmc_of_parse() function
instead of duplicating the device tree parsing code. We can still get
a default value for cfg->f_max by assigning it before calling
mmc_of_parse().

Another advantage of this refactoring is that we parse more properties
now, e.g. "non-removable" can be used to disable CD entirely.

Signed-off-by: Stephan Gerhold 
---

 drivers/mmc/arm_pl180_mmci.c | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index e632eed03f..809b86570a 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -424,7 +424,6 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
struct pl180_mmc_host *host = dev_get_priv(dev);
struct mmc_config *cfg = >cfg;
struct clk clk;
-   u32 bus_width;
u32 periphid;
int ret;
 
@@ -457,24 +456,14 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
cfg->voltages = VOLTAGE_WINDOW_SD;
cfg->host_caps = 0;
cfg->f_min = host->clock_in / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
-   cfg->f_max = dev_read_u32_default(dev, "max-frequency", MMC_CLOCK_MAX);
+   cfg->f_max = MMC_CLOCK_MAX;
cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 
gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio, GPIOD_IS_IN);
 
-   bus_width = dev_read_u32_default(dev, "bus-width", 1);
-   switch (bus_width) {
-   case 8:
-   cfg->host_caps |= MMC_MODE_8BIT;
-   /* Hosts capable of 8-bit transfers can also do 4 bits */
-   case 4:
-   cfg->host_caps |= MMC_MODE_4BIT;
-   break;
-   case 1:
-   break;
-   default:
-   dev_err(dev, "Invalid bus-width value %u\n", bus_width);
-   }
+   ret = mmc_of_parse(dev, cfg);
+   if (ret)
+   return ret;
 
arm_pl180_mmc_init(host);
mmc->priv = host;
-- 
2.32.0

[PATCH 0/4] Add support for eMMC on ST-Ericsson Ux500(v2)

[Stephan Gerhold]

This patch series adds support for the eMMC on ST-Ericsson Ux500:

  1. Some minor fixes+cleanup for the arm_pl180_mmci driver.
  3. Add the necessary configuration for ST-Ericsson Ux500v2.

This was tested on the u8500 "stemmy" board that is already present
in U-Boot.


Stephan Gerhold (4):
  mmc: arm_pl180_mmci: Don't bind to all arm,primecell devices
  mmc: arm_pl180_mmci: Simplify code using dev_read_addr_ptr()
  mmc: arm_pl180_mmci: Simplify code using mmc_of_parse()
  mmc: arm_pl180_mmci: Add configuration for ST-Ericsson Ux500v2

 drivers/mmc/arm_pl180_mmci.c | 48 
 drivers/mmc/arm_pl180_mmci.h |  1 +
 2 files changed, 22 insertions(+), 27 deletions(-)

-- 
2.32.0

[PATCH 2/4] mmc: arm_pl180_mmci: Simplify code using dev_read_addr_ptr()

[Stephan Gerhold]

Simplify the code a bit by using dev_read_addr_ptr() instead of
dev_read_addr(). This avoids having to cast explicitly to void*.

Signed-off-by: Stephan Gerhold 
---

 drivers/mmc/arm_pl180_mmci.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index 5d1ee64356..e632eed03f 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -526,14 +526,11 @@ static const struct dm_mmc_ops arm_pl180_dm_mmc_ops = {
 static int arm_pl180_mmc_of_to_plat(struct udevice *dev)
 {
struct pl180_mmc_host *host = dev_get_priv(dev);
-   fdt_addr_t addr;
 
-   addr = dev_read_addr(dev);
-   if (addr == FDT_ADDR_T_NONE)
+   host->base = dev_read_addr_ptr(dev);
+   if (!host->base)
return -EINVAL;
 
-   host->base = (void *)addr;
-
return 0;
 }
 
-- 
2.32.0

[PATCH 4/4] mmc: arm_pl180_mmci: Add configuration for ST-Ericsson Ux500v2

[Stephan Gerhold]

For the eMMC on ST-Ericsson Ux500v2 we need slightly different
configuration values. Use the existing switch statement to match
the peripheral ID of Ux500v2 (0x10480180) and override the necessary
values to make the eMMC work on devices with ST-Ericsson Ux500.

Cc: Linus Walleij 
Signed-off-by: Stephan Gerhold 
---

 drivers/mmc/arm_pl180_mmci.c | 22 +++---
 drivers/mmc/arm_pl180_mmci.h |  1 +
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index 809b86570a..f99b5f997e 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -443,22 +443,30 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
SDI_CLKCR_HWFC_EN;
host->clock_in = clk_get_rate();
 
+   cfg->name = dev->name;
+   cfg->voltages = VOLTAGE_WINDOW_SD;
+   cfg->host_caps = 0;
+   cfg->f_min = host->clock_in / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
+   cfg->f_max = MMC_CLOCK_MAX;
+   cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
+
periphid = dev_read_u32_default(dev, "arm,primecell-periphid", 0);
switch (periphid) {
case STM32_MMCI_ID: /* stm32 variant */
host->version2 = false;
break;
+   case UX500V2_MMCI_ID:
+   host->pwr_init = SDI_PWR_OPD | SDI_PWR_PWRCTRL_ON;
+   host->clkdiv_init = SDI_CLKCR_CLKDIV_INIT_V2 | SDI_CLKCR_CLKEN |
+   SDI_CLKCR_HWFC_EN;
+   cfg->voltages = VOLTAGE_WINDOW_MMC;
+   cfg->f_min = host->clock_in / (2 + SDI_CLKCR_CLKDIV_INIT_V2);
+   host->version2 = true;
+   break;
default:
host->version2 = true;
}
 
-   cfg->name = dev->name;
-   cfg->voltages = VOLTAGE_WINDOW_SD;
-   cfg->host_caps = 0;
-   cfg->f_min = host->clock_in / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
-   cfg->f_max = MMC_CLOCK_MAX;
-   cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
-
gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio, GPIOD_IS_IN);
 
ret = mmc_of_parse(dev, cfg);
diff --git a/drivers/mmc/arm_pl180_mmci.h b/drivers/mmc/arm_pl180_mmci.h
index 61ee96a112..15c29beadb 100644
--- a/drivers/mmc/arm_pl180_mmci.h
+++ b/drivers/mmc/arm_pl180_mmci.h
@@ -142,6 +142,7 @@
 #define SDI_FIFO_BURST_SIZE8
 
 #define STM32_MMCI_ID  0x00880180
+#define UX500V2_MMCI_ID0x10480180
 
 struct sdi_registers {
u32 power;  /* 0x00*/
-- 
2.32.0

[PATCH 1/4] mmc: arm_pl180_mmci: Don't bind to all arm, primecell devices

[Stephan Gerhold]

The arm,primecell compatible is used for lots of different types
of devices, e.g. I2C, SPI, coresight, ... We really should not bind
the MMC driver to all of them.

Looking through the device trees in U-Boot there seems to be always
a second compatible string for the pl180 device, either arm,pl180
(already listed) or arm,pl18x. Add the "arm,pl18x" compatible to the
list but remove the generic "arm,primecell".

Note that on Linux these compatibles cannot be found in drivers
because AMBA/primecell devices are matched based on their peripheral ID
instead of the compatible.

This fixes the following error messages when booting the ST-Ericsson
U8500 "stemmy" board with the arm_pl180_mmci driver enabled:

  MMC:   ptm@801ae000 - probe failed: -38
  ptm@801af000 - probe failed: -38
  funnel@801a6000 - probe failed: -38
  tpiu@8019 - probe failed: -38
  etb@801a4000 - probe failed: -38

Cc: Patrice Chotard 
Fixes: 6f41d1a17e20 ("mmc: arm_pl180_mmci: Sync compatible with kernel")
Signed-off-by: Stephan Gerhold 
---

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

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index b2d1b4f9aa..5d1ee64356 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -539,7 +539,7 @@ static int arm_pl180_mmc_of_to_plat(struct udevice *dev)
 
 static const struct udevice_id arm_pl180_mmc_match[] = {
{ .compatible = "arm,pl180" },
-   { .compatible = "arm,primecell" },
+   { .compatible = "arm,pl18x" },
{ /* sentinel */ }
 };
 
-- 
2.32.0

Re: [PATCH 2/3] phy: Add driver for ST-Ericsson AB8500 USB PHY

[Stephan Gerhold]

On Tue, Jul 06, 2021 at 10:10:54AM +0900, Jaehoon Chung wrote:
> Hi Stephan,
> 
> On 7/6/21 1:28 AM, Stephan Gerhold wrote:
> > The AB8500 PMIC contains an USB PHY that needs to be set up in
> > device or host mode to make USB work properly. Add a simple driver
> > for the generic PHY uclass that allows enabling it.
> > 
> > The if (CONFIG_IS_ENABLED(USB_MUSB_HOST)) might be a bit strange.
> > The USB PHY must be configured in either host or device mode and
> > somehow the USB PHY driver must be made aware of the mode.
> > 
> > Actually, the MUSB driver used together with this PHY does not
> > support dynamic selection of host/device mode in U-Boot at the moment.
> > Therefore, one very simple approach that works fine is to select
> > the mode to configure at compile time. When the MUSB driver is
> > configured in host mode the PHY is configured in host mode, and
> > similarly when the MUSB driver is configured in device/gadget mode.
> > 
> > Cc: Linus Walleij 
> > Signed-off-by: Stephan Gerhold 
> > ---
> > 
> > Better suggestions to make the USB PHY driver aware of the mode
> > are very welcome. :) I'm not sure it's worth it though, the compile
> > time selection is not ideal but it does the job just fine for now.
> > ---
> >  drivers/phy/Kconfig  |  6 
> >  drivers/phy/Makefile |  1 +
> >  drivers/phy/phy-ab8500-usb.c | 54 
> >  3 files changed, 61 insertions(+)
> >  create mode 100644 drivers/phy/phy-ab8500-usb.c
> > 
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > index 008186a10d..92c74b9d0b 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -64,6 +64,12 @@ config MIPI_DPHY_HELPERS
> > help
> >   Provides a number of helpers a core functions for MIPI D-PHY drivers.
> >  
> > +config AB8500_USB_PHY
> > +   bool "AB8500 USB PHY Driver"
> > +   depends on PHY && PMIC_AB8500
> > +   help
> > + Support for the USB OTG PHY in ST-Ericsson AB8500.
> > +
> >  config BCM6318_USBH_PHY
> > bool "BCM6318 USBH PHY support"
> > depends on PHY && ARCH_BMIPS
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> > index 3c4a673a83..bf03d05d9b 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -6,6 +6,7 @@
> >  obj-$(CONFIG_$(SPL_)PHY) += phy-uclass.o
> >  obj-$(CONFIG_$(SPL_)NOP_PHY) += nop-phy.o
> >  obj-$(CONFIG_MIPI_DPHY_HELPERS) += phy-core-mipi-dphy.o
> > +obj-$(CONFIG_AB8500_USB_PHY) += phy-ab8500-usb.o
> >  obj-$(CONFIG_BCM6318_USBH_PHY) += bcm6318-usbh-phy.o
> >  obj-$(CONFIG_BCM6348_USBH_PHY) += bcm6348-usbh-phy.o
> >  obj-$(CONFIG_BCM6358_USBH_PHY) += bcm6358-usbh-phy.o
> > diff --git a/drivers/phy/phy-ab8500-usb.c b/drivers/phy/phy-ab8500-usb.c
> > new file mode 100644
> > index 00..4ecb03a9cb
> > --- /dev/null
> > +++ b/drivers/phy/phy-ab8500-usb.c
> > @@ -0,0 +1,54 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/* Copyright (C) 2019 Stephan Gerhold */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define AB8500_USB_PHY_CTRL_REGAB8500_USB(0x8A)
> > +#define AB8500_BIT_PHY_CTRL_HOST_ENBIT(0)
> > +#define AB8500_BIT_PHY_CTRL_DEVICE_EN  BIT(1)
> > +#define AB8500_USB_PHY_CTRL_MASK   (AB8500_BIT_PHY_CTRL_HOST_EN |\
> > +AB8500_BIT_PHY_CTRL_DEVICE_EN)
> > +
> > +static int ab8500_usb_phy_power_on(struct phy *phy)
> > +{
> > +   struct udevice *dev = phy->dev;
> > +   uint set;
> > +
> 
> unit set = AB8500_BIT_PHY_CTRL_DEVICE_EN;
> 
> if (CONFIG_IS_ENABLED(USB)MUSB_HOST))
>   set = ...;
> 
> how about that?
> 

Both looks fine to me, I can change it in v2.

> > +   if (CONFIG_IS_ENABLED(USB_MUSB_HOST))
> > +   set = AB8500_BIT_PHY_CTRL_HOST_EN;
> > +   else
> > +   set = AB8500_BIT_PHY_CTRL_DEVICE_EN;
> > +
> > +   return pmic_clrsetbits(dev->parent, AB8500_USB_PHY_CTRL_REG,
> > +  AB8500_USB_PHY_CTRL_MASK, set);
> > +}

Thanks for the review!
Stephan

Re: [PATCH 1/3] power: pmic: Add driver for ST-Ericsson AB8500 via PRCMU

[Stephan Gerhold]

On Tue, Jul 06, 2021 at 10:08:03AM +0900, Jaehoon Chung wrote:
> On 7/6/21 1:28 AM, Stephan Gerhold wrote:
> > All devices based on ST-Ericsson Ux500 use a PMIC similar to AB8500
> > (Analog Baseband). There is AB8500, AB8505, AB9540 and AB8540
> > although in practice only AB8500 and AB8505 are relevant since the
> > platforms with AB9540 and AB8540 were cancelled and never used in
> > production.
> > 
> > In general, the AB8500 PMIC uses I2C as control interface, where the
> > different register banks are represented as separate I2C devices.
> > However, in practice AB8500 is always connected to a special I2C bus
> > on the DB8500 SoC that is controlled by the power/reset/clock
> > management unit (PRCMU) firmware.
> > 
> > Add a simple driver that allows reading/writing registers of the
> > AB8500 PMIC. The driver directly accesses registers from the PRCMU
> > parent device (represented by syscon in U-Boot). Abstracting it
> > further (e.g. with the i2c uclass) would not provide any advantage
> > because the PRCMU I2C bus is always just connected to AB8500 and
> > vice-versa.
> > 
> > The ab8500.h header is mostly taken as-is from Linux (with some
> > minor adjustments) to allow using similar code in both Linux and
> > U-Boot.
> > 
> > Cc: Linus Walleij 
> > Signed-off-by: Stephan Gerhold 
> > ---
> > 
> >  drivers/power/pmic/Kconfig  |  10 ++
> >  drivers/power/pmic/Makefile |   1 +
> >  drivers/power/pmic/ab8500.c | 258 
> >  include/power/ab8500.h  | 125 +
> >  4 files changed, 394 insertions(+)
> >  create mode 100644 drivers/power/pmic/ab8500.c
> >  create mode 100644 include/power/ab8500.h
> > 
> > diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> > index 583fd3ddcd..fd6648b313 100644
> > --- a/drivers/power/pmic/Kconfig
> > +++ b/drivers/power/pmic/Kconfig
> > @@ -31,6 +31,16 @@ config SPL_PMIC_CHILDREN
> > to call your regulator code (e.g. see rk8xx.c for direct functions
> > for use in SPL).
> >  
> > +config PMIC_AB8500
> > +   bool "Enable driver for ST-Ericsson AB8500 PMIC via PRCMU"
> > +   depends on DM_PMIC
> > +   select REGMAP
> > +   select SYSCON
> > +   help
> > + Enable support for the ST-Ericsson AB8500 (Analog Baseband) PMIC.
> > + It connects with the ST-Ericsson DB8500 SoC via an I2C bus managed by
> > + the power/reset/clock management unit (PRCMU) firmware.
> > +
> >  config PMIC_ACT8846
> > bool "Enable support for the active-semi 8846 PMIC"
> > depends on DM_PMIC && DM_I2C
> > diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> > index 89099fde57..5d1a97e5f6 100644
> > --- a/drivers/power/pmic/Makefile
> > +++ b/drivers/power/pmic/Makefile
> > @@ -15,6 +15,7 @@ obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
> >  obj-$(CONFIG_$(SPL_)DM_PMIC_PCA9450) += pca9450.o
> >  obj-$(CONFIG_PMIC_S2MPS11) += s2mps11.o
> >  obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
> > +obj-$(CONFIG_PMIC_AB8500) += ab8500.o
> >  obj-$(CONFIG_PMIC_ACT8846) += act8846.o
> >  obj-$(CONFIG_PMIC_AS3722) += as3722.o as3722_gpio.o
> >  obj-$(CONFIG_PMIC_MAX8997) += max8997.o
> > diff --git a/drivers/power/pmic/ab8500.c b/drivers/power/pmic/ab8500.c
> > new file mode 100644
> > index 00..a87a3b497c
> > --- /dev/null
> > +++ b/drivers/power/pmic/ab8500.c
> > @@ -0,0 +1,258 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2019 Stephan Gerhold
> > + *
> > + * Adapted from old U-Boot and Linux kernel implementation:
> > + * Copyright (C) STMicroelectronics 2009
> > + * Copyright (C) ST-Ericsson SA 2010
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* CPU mailbox registers */
> > +#define PRCM_MBOX_CPU_VAL  0x0fc
> > +#define PRCM_MBOX_CPU_SET  0x100
> > +#define PRCM_MBOX_CPU_CLR  0x104
> > +
> > +#define PRCM_ARM_IT1_CLR   0x48C
> > +#define PRCM_ARM_IT1_VAL   0x494
> > +
> > +#define PRCM_TCDM_RANGE2
> > +#define PRCM_REQ_MB5   0xE44
> > +#define PRCM_ACK_MB5   0xDF4
> > +#define _PRCM_MBOX_HEADER  0xFE8
> > +#define PRCM_MBOX_HEADER_REQ_MB5   (_PRCM_MBOX_HEADER + 0x5)
&

[PATCH 2/3] phy: Add driver for ST-Ericsson AB8500 USB PHY

[Stephan Gerhold]

The AB8500 PMIC contains an USB PHY that needs to be set up in
device or host mode to make USB work properly. Add a simple driver
for the generic PHY uclass that allows enabling it.

The if (CONFIG_IS_ENABLED(USB_MUSB_HOST)) might be a bit strange.
The USB PHY must be configured in either host or device mode and
somehow the USB PHY driver must be made aware of the mode.

Actually, the MUSB driver used together with this PHY does not
support dynamic selection of host/device mode in U-Boot at the moment.
Therefore, one very simple approach that works fine is to select
the mode to configure at compile time. When the MUSB driver is
configured in host mode the PHY is configured in host mode, and
similarly when the MUSB driver is configured in device/gadget mode.

Cc: Linus Walleij 
Signed-off-by: Stephan Gerhold 
---

Better suggestions to make the USB PHY driver aware of the mode
are very welcome. :) I'm not sure it's worth it though, the compile
time selection is not ideal but it does the job just fine for now.
---
 drivers/phy/Kconfig  |  6 
 drivers/phy/Makefile |  1 +
 drivers/phy/phy-ab8500-usb.c | 54 
 3 files changed, 61 insertions(+)
 create mode 100644 drivers/phy/phy-ab8500-usb.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 008186a10d..92c74b9d0b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -64,6 +64,12 @@ config MIPI_DPHY_HELPERS
help
  Provides a number of helpers a core functions for MIPI D-PHY drivers.
 
+config AB8500_USB_PHY
+   bool "AB8500 USB PHY Driver"
+   depends on PHY && PMIC_AB8500
+   help
+ Support for the USB OTG PHY in ST-Ericsson AB8500.
+
 config BCM6318_USBH_PHY
bool "BCM6318 USBH PHY support"
depends on PHY && ARCH_BMIPS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 3c4a673a83..bf03d05d9b 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_$(SPL_)PHY) += phy-uclass.o
 obj-$(CONFIG_$(SPL_)NOP_PHY) += nop-phy.o
 obj-$(CONFIG_MIPI_DPHY_HELPERS) += phy-core-mipi-dphy.o
+obj-$(CONFIG_AB8500_USB_PHY) += phy-ab8500-usb.o
 obj-$(CONFIG_BCM6318_USBH_PHY) += bcm6318-usbh-phy.o
 obj-$(CONFIG_BCM6348_USBH_PHY) += bcm6348-usbh-phy.o
 obj-$(CONFIG_BCM6358_USBH_PHY) += bcm6358-usbh-phy.o
diff --git a/drivers/phy/phy-ab8500-usb.c b/drivers/phy/phy-ab8500-usb.c
new file mode 100644
index 00..4ecb03a9cb
--- /dev/null
+++ b/drivers/phy/phy-ab8500-usb.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2019 Stephan Gerhold */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AB8500_USB_PHY_CTRL_REGAB8500_USB(0x8A)
+#define AB8500_BIT_PHY_CTRL_HOST_ENBIT(0)
+#define AB8500_BIT_PHY_CTRL_DEVICE_EN  BIT(1)
+#define AB8500_USB_PHY_CTRL_MASK   (AB8500_BIT_PHY_CTRL_HOST_EN |\
+AB8500_BIT_PHY_CTRL_DEVICE_EN)
+
+static int ab8500_usb_phy_power_on(struct phy *phy)
+{
+   struct udevice *dev = phy->dev;
+   uint set;
+
+   if (CONFIG_IS_ENABLED(USB_MUSB_HOST))
+   set = AB8500_BIT_PHY_CTRL_HOST_EN;
+   else
+   set = AB8500_BIT_PHY_CTRL_DEVICE_EN;
+
+   return pmic_clrsetbits(dev->parent, AB8500_USB_PHY_CTRL_REG,
+  AB8500_USB_PHY_CTRL_MASK, set);
+}
+
+static int ab8500_usb_phy_power_off(struct phy *phy)
+{
+   struct udevice *dev = phy->dev;
+
+   return pmic_clrsetbits(dev->parent, AB8500_USB_PHY_CTRL_REG,
+  AB8500_USB_PHY_CTRL_MASK, 0);
+}
+
+struct phy_ops ab8500_usb_phy_ops = {
+   .power_on = ab8500_usb_phy_power_on,
+   .power_off = ab8500_usb_phy_power_off,
+};
+
+static const struct udevice_id ab8500_usb_phy_ids[] = {
+   { .compatible = "stericsson,ab8500-usb" },
+   { }
+};
+
+U_BOOT_DRIVER(ab8500_usb_phy) = {
+   .name = "ab8500_usb_phy",
+   .id = UCLASS_PHY,
+   .of_match = ab8500_usb_phy_ids,
+   .ops = _usb_phy_ops,
+};
-- 
2.32.0

[PATCH 3/3] usb: musb-new: Add glue driver for ST-Ericsson Ux500

[Stephan Gerhold]

The ST-Ericsson DB8500 SoC contains a MUSB OTG controller which
supports both host and gadget mode. For some reason there is
nothing special about it - add a simple glue driver for Ux500
that literally just sets up MUSB together with a generic PHY.
There are no SoC-specific registers etc needed to make USB work.

The new Ux500 glue driver is only tested to work with DM_USB
and DM_USB_GADGET. Both host and gadget mode work fine on
the u8500 "stemmy" board that is already present in U-Boot.

Cc: Linus Walleij 
Signed-off-by: Stephan Gerhold 
---

This patch could be applied separately from the first two if
needed. There is a functional runtime dependency but not
a compile time dependency with the PMIC changes in the first
two patches.

---
 drivers/usb/musb-new/Kconfig |  11 +-
 drivers/usb/musb-new/Makefile|   1 +
 drivers/usb/musb-new/musb_core.c |   2 +-
 drivers/usb/musb-new/ux500.c | 179 +++
 4 files changed, 191 insertions(+), 2 deletions(-)
 create mode 100644 drivers/usb/musb-new/ux500.c

diff --git a/drivers/usb/musb-new/Kconfig b/drivers/usb/musb-new/Kconfig
index fd6f4109b0..81ceea9740 100644
--- a/drivers/usb/musb-new/Kconfig
+++ b/drivers/usb/musb-new/Kconfig
@@ -72,6 +72,15 @@ config USB_MUSB_SUNXI
Say y here to enable support for the sunxi OTG / DRC USB controller
used on almost all sunxi boards.
 
+config USB_MUSB_UX500
+   bool "Enable ST-Ericsson Ux500 USB controller"
+   depends on DM_USB && DM_USB_GADGET && ARCH_U8500
+   default y
+   help
+ Say y to enable support for the MUSB OTG USB controller used in
+ ST-Ericsson Ux500. The driver supports either gadget or host mode
+ based on the selection of CONFIG_USB_MUSB_HOST.
+
 config USB_MUSB_DISABLE_BULK_COMBINE_SPLIT
bool "Disable MUSB bulk split/combine"
default y
@@ -85,7 +94,7 @@ endif
 
 config USB_MUSB_PIO_ONLY
bool "Disable DMA (always use PIO)"
-   default y if USB_MUSB_AM35X || USB_MUSB_PIC32 || USB_MUSB_OMAP2PLUS || 
USB_MUSB_DSPS || USB_MUSB_SUNXI || USB_MUSB_MT85XX
+   default y if USB_MUSB_AM35X || USB_MUSB_PIC32 || USB_MUSB_OMAP2PLUS || 
USB_MUSB_DSPS || USB_MUSB_SUNXI || USB_MUSB_MT85XX || USB_MUSB_UX500
help
  All data is copied between memory and FIFO by the CPU.
  DMA controllers are ignored.
diff --git a/drivers/usb/musb-new/Makefile b/drivers/usb/musb-new/Makefile
index 6355eb12dd..396ff02654 100644
--- a/drivers/usb/musb-new/Makefile
+++ b/drivers/usb/musb-new/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_MUSB_OMAP2PLUS) += omap2430.o
 obj-$(CONFIG_USB_MUSB_PIC32) += pic32.o
 obj-$(CONFIG_USB_MUSB_SUNXI) += sunxi.o
 obj-$(CONFIG_USB_MUSB_TI) += ti-musb.o
+obj-$(CONFIG_USB_MUSB_UX500) += ux500.o
 
 ccflags-y := $(call cc-option,-Wno-unused-variable) \
$(call cc-option,-Wno-unused-but-set-variable) \
diff --git a/drivers/usb/musb-new/musb_core.c b/drivers/usb/musb-new/musb_core.c
index 22811a5efb..18d9bc805f 100644
--- a/drivers/usb/musb-new/musb_core.c
+++ b/drivers/usb/musb-new/musb_core.c
@@ -1526,7 +1526,7 @@ static int __devinit musb_core_init(u16 musb_type, struct 
musb *musb)
 /*-*/
 
 #if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430) || \
-   defined(CONFIG_ARCH_OMAP4)
+   defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500)
 
 static irqreturn_t generic_interrupt(int irq, void *__hci)
 {
diff --git a/drivers/usb/musb-new/ux500.c b/drivers/usb/musb-new/ux500.c
new file mode 100644
index 00..57c7d5630d
--- /dev/null
+++ b/drivers/usb/musb-new/ux500.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2019 Stephan Gerhold */
+
+#include 
+#include 
+#include 
+#include 
+#include "musb_uboot.h"
+
+static struct musb_hdrc_config ux500_musb_hdrc_config = {
+   .multipoint = true,
+   .dyn_fifo   = true,
+   .num_eps= 16,
+   .ram_bits   = 16,
+};
+
+struct ux500_glue {
+   struct musb_host_data mdata;
+   struct device dev;
+   struct phy phy;
+   bool enabled;
+};
+#define to_ux500_glue(d)   container_of(d, struct ux500_glue, dev)
+
+static int ux500_musb_enable(struct musb *musb)
+{
+   struct ux500_glue *glue = to_ux500_glue(musb->controller);
+   int ret;
+
+   if (glue->enabled)
+   return 0;
+
+   ret = generic_phy_power_on(>phy);
+   if (ret) {
+   printf("%s: failed to power on USB PHY\n", __func__);
+   return ret;
+   }
+
+   glue->enabled = true;
+   return 0;
+}
+
+static void ux500_musb_disable(struct musb *musb)
+{
+   struct ux500_glue *glue = to_ux500_glue(musb->controller);
+   int ret;
+
+   if (!glue->enabled)
+   return;
+
+   ret = generic_phy_power_off(

[PATCH 1/3] power: pmic: Add driver for ST-Ericsson AB8500 via PRCMU

[Stephan Gerhold]

All devices based on ST-Ericsson Ux500 use a PMIC similar to AB8500
(Analog Baseband). There is AB8500, AB8505, AB9540 and AB8540
although in practice only AB8500 and AB8505 are relevant since the
platforms with AB9540 and AB8540 were cancelled and never used in
production.

In general, the AB8500 PMIC uses I2C as control interface, where the
different register banks are represented as separate I2C devices.
However, in practice AB8500 is always connected to a special I2C bus
on the DB8500 SoC that is controlled by the power/reset/clock
management unit (PRCMU) firmware.

Add a simple driver that allows reading/writing registers of the
AB8500 PMIC. The driver directly accesses registers from the PRCMU
parent device (represented by syscon in U-Boot). Abstracting it
further (e.g. with the i2c uclass) would not provide any advantage
because the PRCMU I2C bus is always just connected to AB8500 and
vice-versa.

The ab8500.h header is mostly taken as-is from Linux (with some
minor adjustments) to allow using similar code in both Linux and
U-Boot.

Cc: Linus Walleij 
Signed-off-by: Stephan Gerhold 
---

 drivers/power/pmic/Kconfig  |  10 ++
 drivers/power/pmic/Makefile |   1 +
 drivers/power/pmic/ab8500.c | 258 
 include/power/ab8500.h  | 125 +
 4 files changed, 394 insertions(+)
 create mode 100644 drivers/power/pmic/ab8500.c
 create mode 100644 include/power/ab8500.h

diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index 583fd3ddcd..fd6648b313 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -31,6 +31,16 @@ config SPL_PMIC_CHILDREN
to call your regulator code (e.g. see rk8xx.c for direct functions
for use in SPL).
 
+config PMIC_AB8500
+   bool "Enable driver for ST-Ericsson AB8500 PMIC via PRCMU"
+   depends on DM_PMIC
+   select REGMAP
+   select SYSCON
+   help
+ Enable support for the ST-Ericsson AB8500 (Analog Baseband) PMIC.
+ It connects with the ST-Ericsson DB8500 SoC via an I2C bus managed by
+ the power/reset/clock management unit (PRCMU) firmware.
+
 config PMIC_ACT8846
bool "Enable support for the active-semi 8846 PMIC"
depends on DM_PMIC && DM_I2C
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 89099fde57..5d1a97e5f6 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
 obj-$(CONFIG_$(SPL_)DM_PMIC_PCA9450) += pca9450.o
 obj-$(CONFIG_PMIC_S2MPS11) += s2mps11.o
 obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
+obj-$(CONFIG_PMIC_AB8500) += ab8500.o
 obj-$(CONFIG_PMIC_ACT8846) += act8846.o
 obj-$(CONFIG_PMIC_AS3722) += as3722.o as3722_gpio.o
 obj-$(CONFIG_PMIC_MAX8997) += max8997.o
diff --git a/drivers/power/pmic/ab8500.c b/drivers/power/pmic/ab8500.c
new file mode 100644
index 00..a87a3b497c
--- /dev/null
+++ b/drivers/power/pmic/ab8500.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Stephan Gerhold
+ *
+ * Adapted from old U-Boot and Linux kernel implementation:
+ * Copyright (C) STMicroelectronics 2009
+ * Copyright (C) ST-Ericsson SA 2010
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* CPU mailbox registers */
+#define PRCM_MBOX_CPU_VAL  0x0fc
+#define PRCM_MBOX_CPU_SET  0x100
+#define PRCM_MBOX_CPU_CLR  0x104
+
+#define PRCM_ARM_IT1_CLR   0x48C
+#define PRCM_ARM_IT1_VAL   0x494
+
+#define PRCM_TCDM_RANGE2
+#define PRCM_REQ_MB5   0xE44
+#define PRCM_ACK_MB5   0xDF4
+#define _PRCM_MBOX_HEADER  0xFE8
+#define PRCM_MBOX_HEADER_REQ_MB5   (_PRCM_MBOX_HEADER + 0x5)
+#define PRCMU_I2C_MBOX_BIT BIT(5)
+
+/* Mailbox 5 Requests */
+#define PRCM_REQ_MB5_I2C_SLAVE_OP  (PRCM_REQ_MB5 + 0x0)
+#define PRCM_REQ_MB5_I2C_HW_BITS   (PRCM_REQ_MB5 + 0x1)
+#define PRCM_REQ_MB5_I2C_REG   (PRCM_REQ_MB5 + 0x2)
+#define PRCM_REQ_MB5_I2C_VAL   (PRCM_REQ_MB5 + 0x3)
+#define PRCMU_I2C(bank)(((bank) << 1) | BIT(6))
+#define PRCMU_I2C_WRITE0
+#define PRCMU_I2C_READ 1
+#define PRCMU_I2C_STOP_EN  BIT(3)
+
+/* Mailbox 5 ACKs */
+#define PRCM_ACK_MB5_I2C_STATUS(PRCM_ACK_MB5 + 0x1)
+#define PRCM_ACK_MB5_I2C_VAL   (PRCM_ACK_MB5 + 0x3)
+#define PRCMU_I2C_WR_OK0x1
+#define PRCMU_I2C_RD_OK0x2
+
+/* AB8500 version registers */
+#define AB8500_MISC_REV_REGAB8500_MISC(0x80)
+#define AB8500_MISC_IC_NAME_REGAB8500_MISC(0x82)
+
+struct ab8500_priv {
+   struct ab8500 ab8500;
+   struct regmap *regmap;
+};
+
+static inline int prcmu_tcdm_readb(struct 

[PATCH 0/3] Add support for USB on ST-Ericsson Ux500

[Stephan Gerhold]

This patch series adds support for USB on ST-Ericsson Ux500 by:
  - Adding a driver to talk to the AB8500 PMIC
  - Adding a driver to enable the USB PHY
  - Adding a simple Ux500 glue driver for the musb-new driver

This was tested on the u8500 "stemmy" board that is already present
in U-Boot.


Stephan Gerhold (3):
  power: pmic: Add driver for ST-Ericsson AB8500 via PRCMU
  phy: Add driver for ST-Ericsson AB8500 USB PHY
  usb: musb-new: Add glue driver for ST-Ericsson Ux500

 drivers/phy/Kconfig  |   6 +
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-ab8500-usb.c |  54 +++
 drivers/power/pmic/Kconfig   |  10 ++
 drivers/power/pmic/Makefile  |   1 +
 drivers/power/pmic/ab8500.c  | 258 +++
 drivers/usb/musb-new/Kconfig |  11 +-
 drivers/usb/musb-new/Makefile|   1 +
 drivers/usb/musb-new/musb_core.c |   2 +-
 drivers/usb/musb-new/ux500.c | 179 +
 include/power/ab8500.h   | 125 +++
 11 files changed, 646 insertions(+), 2 deletions(-)
 create mode 100644 drivers/phy/phy-ab8500-usb.c
 create mode 100644 drivers/power/pmic/ab8500.c
 create mode 100644 drivers/usb/musb-new/ux500.c
 create mode 100644 include/power/ab8500.h

-- 
2.32.0

[PATCH] arm: mach-snapdragon: pinctrl: Place pin_name in .data section

[Stephan Gerhold]

According to arch/arm/lib/crt0_64.S, the BSS section is "UNAVAILABLE"
and uninitialized before relocation. Also, it overlaps with the
appended DTB before relocation, so writing data into a variable
in the BSS section might corrupt the appended DTB.

Unfortunately, pinctrl-apq8016.c and pinctrl-apq8096.c do place the
"pin_name" variable in the BSS section (since it's uninitialized).
It's also used before relocation, when setting up the pinctrl for
the serial driver.

On DB410c this causes "GPIO_5" to be written into some part of an
appended DTB, e.g.:

80111820: edfe0dd0 9f10 3800 c00e...8
80111830: 2800 1100 1000 ...(
80111840: 4f495047 8800355f  GPIO_5..
80111850:   0100 
80111860: 0300 0400  0200
80111870: 0300 0400 0f00 0200
80111880: 0300 2d00 1b00 6c617551...-Qual
80111890: 6d6d6f63 63655420 6c6f6e68 6569676fcomm Technologie

Depending on the part of the DTB that is corrupted this might not
cause any problems, but it can also result in strange reboots
without any serial output.

Fortunately, in practice this does not cause issues on DB410c yet
because board_fdt_blob_setup() in dragonboard410c.c currently
overrides the appended DTB with the one passed by the previous
bootloader (LK) (which does not get corrupted).

DB820c does not have board_fdt_blob_setup() so I would expect it to
be affected by this problem. Perhaps everyone was just fortunate to
not compile an U-Boot configuration where the pin_name corrupts an
important part of the DTB.

Make sure "pin_name" is explicitly placed in the .data section
instead of .bss to fix this.

Cc: Ramon Fried 
Signed-off-by: Stephan Gerhold 
---

 arch/arm/mach-snapdragon/pinctrl-apq8016.c | 3 +--
 arch/arm/mach-snapdragon/pinctrl-apq8096.c | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8016.c 
b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
index 1042b564c3..70c0be0bca 100644
--- a/arch/arm/mach-snapdragon/pinctrl-apq8016.c
+++ b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
@@ -10,7 +10,7 @@
 #include 
 
 #define MAX_PIN_NAME_LEN 32
-static char pin_name[MAX_PIN_NAME_LEN];
+static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
 static const char * const msm_pinctrl_pins[] = {
"SDC1_CLK",
"SDC1_CMD",
@@ -59,4 +59,3 @@ struct msm_pinctrl_data apq8016_data = {
.get_function_mux = apq8016_get_function_mux,
.get_pin_name = apq8016_get_pin_name,
 };
-
diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8096.c 
b/arch/arm/mach-snapdragon/pinctrl-apq8096.c
index 20a71c319b..45462f01c2 100644
--- a/arch/arm/mach-snapdragon/pinctrl-apq8096.c
+++ b/arch/arm/mach-snapdragon/pinctrl-apq8096.c
@@ -10,7 +10,7 @@
 #include 
 
 #define MAX_PIN_NAME_LEN 32
-static char pin_name[MAX_PIN_NAME_LEN];
+static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
 static const char * const msm_pinctrl_pins[] = {
"SDC1_CLK",
"SDC1_CMD",
-- 
2.32.0

Re: [RFC] Load U-Boot without LK on DragonBoard 410c (+ DB820c?)

[Stephan Gerhold]

On Sun, Jul 04, 2021 at 02:08:39PM +0300, Ramon Fried wrote:
> On Sun, Jul 4, 2021 at 12:42 AM Stephan Gerhold  wrote:
> >
> > On Thu, Jul 01, 2021 at 11:07:55AM +0200, Stephan Gerhold wrote:
> > > Hi!
> > >
> > > at the moment the U-Boot ports for both DragonBoard 410c and 820c are
> > > designed to be loaded as an Android boot image after Qualcomm's LK
> > > bootloader. This is simple to set up but LK is redundant in this case,
> > > since everything done by LK can be also done directly by U-Boot.
> > >
> > > Dropping LK entirely would have at least the following advantages:
> > >   - Easier installation/board code (no need for Android boot images)
> > >   - (Slightly) faster boot
> > >   - Boot directly in 64-bit without a round trip to 32-bit for LK
> > >
> > > [...]
> > >
> > > 3. Remaining open questions
> > > ===
> > >
> > > [...]
> > >
> > >   3. CONFIG_OF_EMBED: There is a big warning about this in the build log:
> > >  "This option should only be used for debugging purposes. Please use
> > >   CONFIG_OF_SEPARATE for boards in mainline."
> > >
> > >  The important part here is that we need an ELF image with both
> > >  U-Boot and the DTB. CONFIG_OF_EMBED is convenient for that because
> > >  we can just use the ELF image built by the linker and it already
> > >  contains the DTB.
> > >
> > >  If CONFIG_OF_EMBED is really so bad it might be possible to build
> > >  a new boot image based on "u-boot-dtb.bin" (which is U-Boot with
> > >  DTB appended). I'm not sure if this is really much better though.
> > >
> >
> > After looking some more I found "CONFIG_REMAKE_ELF" which seems to do
> > exactly this (build a new ELF image based on "u-boot-dtb.bin" with
> > appended DTB). So this avoids setting CONFIG_OF_EMBED and therefore the
> > build warning. Sounds like the solution I was looking for. :)
> >
> > Unfortunately it looks like appending the DTB to U-Boot currently
> > produces very strange behavior on DragonBoard 410c. It's either:
> >
> >   - Working fine, or
> >   - Rebooting continously without serial output from U-Boot, or
> >   - The following serial output:
> >
> >   Qualcomm-DragonBoard 410C
> >   DRAM:  986 MiB
> >   No serial driver found
> >   resetting ...
> >
> > It behaves consistently given a U-Boot binary but varies when
> > adding/removing random features from the U-Boot binary.
> >
> > After a couple of hours of debugging, I realized that the appended DTB
> > becomes corrupted. Specifically, there is a "GPIO_5" written into it, e.g.
> >
> > 8f6905b8: edfe0dd0 9f10 4f495047 c000355fGPIO_5..
> > 8f6905c8: 2800 1100 1000 ...(
> > 8f6905d8: df01 880e  
> > 8f6905e8:   0100 
> > 8f6905f8: 0300 0400  0200
> > 8f690608: 0300 0400 0f00 0200
> > 8f690618: 0300 2d00 1b00 6c617551...-Qual
> > 8f690628: 6d6d6f63 63655420 6c6f6e68 6569676fcomm Technologie
> >
> > Depending on enabled features in U-Boot the "GPIO_5" corrupts different
> > parts of the DTB, that's why it works somewhat sometimes.
> >
> > After staring at some drivers and the U-Boot linker script for a while
> > I realized that the BSS section overlaps with the appended DTB before
> > relocation. And indeed, mach-snapdragon/pinctrl-apq8016.c writes "GPIO_5"
> > into "static char pin_name[MAX_PIN_NAME_LEN];" (= BSS) before relocation.
> >
> > Actually, arch/arm/lib/crt0_64.S says that BSS should not be used at all
> > before relocation, because it's uninitialized and might corrupt other
> > memory. I found several other commits where similar problems happened
> > and it was usually fixed by moving the variables into the data section.
> >
> > So, I fixed the problem with the diff below and will include it together
> > with the changes to drop all the LK-related code. Now everything seems
> > fine. (I just wish this would have somehow been more obvious instead of
> > the strange behavior...)
> >
> > Stephan
> >
> > diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8016.c 
> > b/arch/arm/mach-snapdragon/pinctrl-apq8

Re: [RFC] Load U-Boot without LK on DragonBoard 410c (+ DB820c?)

[Stephan Gerhold]

On Thu, Jul 01, 2021 at 11:07:55AM +0200, Stephan Gerhold wrote:
> Hi!
> 
> at the moment the U-Boot ports for both DragonBoard 410c and 820c are
> designed to be loaded as an Android boot image after Qualcomm's LK
> bootloader. This is simple to set up but LK is redundant in this case,
> since everything done by LK can be also done directly by U-Boot.
> 
> Dropping LK entirely would have at least the following advantages:
>   - Easier installation/board code (no need for Android boot images)
>   - (Slightly) faster boot
>   - Boot directly in 64-bit without a round trip to 32-bit for LK
> 
> [...]
> 
> 3. Remaining open questions
> ===
> 
> [...]
> 
>   3. CONFIG_OF_EMBED: There is a big warning about this in the build log:
>  "This option should only be used for debugging purposes. Please use
>   CONFIG_OF_SEPARATE for boards in mainline."
> 
>  The important part here is that we need an ELF image with both
>  U-Boot and the DTB. CONFIG_OF_EMBED is convenient for that because
>  we can just use the ELF image built by the linker and it already
>  contains the DTB.
> 
>  If CONFIG_OF_EMBED is really so bad it might be possible to build
>  a new boot image based on "u-boot-dtb.bin" (which is U-Boot with
>  DTB appended). I'm not sure if this is really much better though.
> 

After looking some more I found "CONFIG_REMAKE_ELF" which seems to do
exactly this (build a new ELF image based on "u-boot-dtb.bin" with
appended DTB). So this avoids setting CONFIG_OF_EMBED and therefore the
build warning. Sounds like the solution I was looking for. :)

Unfortunately it looks like appending the DTB to U-Boot currently
produces very strange behavior on DragonBoard 410c. It's either:

  - Working fine, or
  - Rebooting continously without serial output from U-Boot, or
  - The following serial output:

  Qualcomm-DragonBoard 410C
  DRAM:  986 MiB
  No serial driver found  
  resetting ...

It behaves consistently given a U-Boot binary but varies when
adding/removing random features from the U-Boot binary.

After a couple of hours of debugging, I realized that the appended DTB
becomes corrupted. Specifically, there is a "GPIO_5" written into it, e.g.

8f6905b8: edfe0dd0 9f10 4f495047 c000355fGPIO_5..
8f6905c8: 2800 1100 1000 ...(
8f6905d8: df01 880e  
8f6905e8:   0100 
8f6905f8: 0300 0400  0200
8f690608: 0300 0400 0f00 0200
8f690618: 0300 2d00 1b00 6c617551...-Qual
8f690628: 6d6d6f63 63655420 6c6f6e68 6569676fcomm Technologie

Depending on enabled features in U-Boot the "GPIO_5" corrupts different
parts of the DTB, that's why it works somewhat sometimes.

After staring at some drivers and the U-Boot linker script for a while
I realized that the BSS section overlaps with the appended DTB before
relocation. And indeed, mach-snapdragon/pinctrl-apq8016.c writes "GPIO_5"
into "static char pin_name[MAX_PIN_NAME_LEN];" (= BSS) before relocation.

Actually, arch/arm/lib/crt0_64.S says that BSS should not be used at all
before relocation, because it's uninitialized and might corrupt other
memory. I found several other commits where similar problems happened
and it was usually fixed by moving the variables into the data section.

So, I fixed the problem with the diff below and will include it together
with the changes to drop all the LK-related code. Now everything seems
fine. (I just wish this would have somehow been more obvious instead of
the strange behavior...)

Stephan

diff --git a/arch/arm/mach-snapdragon/pinctrl-apq8016.c 
b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
index 1042b564c3..7940c74287 100644
--- a/arch/arm/mach-snapdragon/pinctrl-apq8016.c
+++ b/arch/arm/mach-snapdragon/pinctrl-apq8016.c
@@ -10,7 +10,7 @@
 #include 
 
 #define MAX_PIN_NAME_LEN 32
-static char pin_name[MAX_PIN_NAME_LEN];
+static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
 static const char * const msm_pinctrl_pins[] = {
"SDC1_CLK",
"SDC1_CMD",

[PATCH] video: Add simple driver for ST-Ericsson MCDE with pre-configured display

[Stephan Gerhold]

The U-Boot port for ST-Ericsson Ux500 is currently only used on the
"stemmy" board, where U-Boot runs after firmware that already sets up
a boot splash screen. This means that the display is already on
and we can just continue using it for U-Boot.

Add a simple driver that simplifies this by reading the display
configuration (e.g. screen size, bpp) from the hardware registers.

It also checks the configured "source synchronization" - for some
displays (usually DSI command mode displays) we need to explicitly
trigger a software sync. This is done through the video_sync()
callback that triggers the sync and wait for completion.

Cc: Linus Walleij 
Signed-off-by: Stephan Gerhold 
---

 drivers/video/Kconfig   |  12 +++
 drivers/video/Makefile  |   1 +
 drivers/video/mcde_simple.c | 141 
 3 files changed, 154 insertions(+)
 create mode 100644 drivers/video/mcde_simple.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index b69ffcae4b..e614a04aab 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -854,6 +854,18 @@ config VIDEO_DT_SIMPLEFB
  The video output is initialized by U-Boot, and kept by the
  kernel.
 
+config VIDEO_MCDE_SIMPLE
+   bool "Simple driver for ST-Ericsson MCDE with preconfigured display"
+   depends on DM_VIDEO
+   help
+ Enables a simple display driver for ST-Ericsson MCDE
+ (Multichannel Display Engine), which reads the configuration from
+ the MCDE registers.
+
+ This driver assumes that the display hardware has been initialized
+ before u-boot starts, and u-boot will simply render to the pre-
+ allocated frame buffer surface.
+
 config OSD
bool "Enable OSD support"
depends on DM
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 933f06e9d8..8a70c9deb5 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_VIDEO_LCD_ORISETECH_OTM8009A) += 
orisetech_otm8009a.o
 obj-$(CONFIG_VIDEO_LCD_RAYDIUM_RM68200) += raydium-rm68200.o
 obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o
 obj-$(CONFIG_VIDEO_LCD_TDO_TL070WSH30) += tdo-tl070wsh30.o
+obj-$(CONFIG_VIDEO_MCDE_SIMPLE) += mcde_simple.o
 obj-${CONFIG_VIDEO_MESON} += meson/
 obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_dsi.o
 obj-$(CONFIG_VIDEO_MVEBU) += mvebu_lcd.o
diff --git a/drivers/video/mcde_simple.c b/drivers/video/mcde_simple.c
new file mode 100644
index 00..0924ceee30
--- /dev/null
+++ b/drivers/video/mcde_simple.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2019 Stephan Gerhold */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MCDE_EXTSRC0A0 0x200
+#define MCDE_EXTSRC0CONF   0x20C
+#define MCDE_EXTSRC0CONF_BPP   GENMASK(11, 8)
+#define MCDE_OVL0CONF  0x404
+#define MCDE_OVL0CONF_PPL  GENMASK(10, 0)
+#define MCDE_OVL0CONF_LPF  GENMASK(26, 16)
+#define MCDE_CHNL0SYNCHMOD 0x608
+#define MCDE_CHNL0SYNCHMOD_SRC_SYNCH   GENMASK(1, 0)
+#define MCDE_CHNL0SYNCHSW  0x60C
+#define MCDE_CHNL0SYNCHSW_SW_TRIG  BIT(0)
+#define MCDE_CRA0  0x800
+#define MCDE_CRA0_FLOENBIT(0)
+
+#define MCDE_FLOW_COMPLETION_TIMEOUT   20  /* us */
+
+enum mcde_bpp {
+   MCDE_EXTSRC0CONF_BPP_1BPP_PAL,
+   MCDE_EXTSRC0CONF_BPP_2BPP_PAL,
+   MCDE_EXTSRC0CONF_BPP_4BPP_PAL,
+   MCDE_EXTSRC0CONF_BPP_8BPP_PAL,
+   MCDE_EXTSRC0CONF_BPP_RGB444,
+   MCDE_EXTSRC0CONF_BPP_ARGB,
+   MCDE_EXTSRC0CONF_BPP_IRGB1555,
+   MCDE_EXTSRC0CONF_BPP_RGB565,
+   MCDE_EXTSRC0CONF_BPP_RGB888,
+   MCDE_EXTSRC0CONF_BPP_XRGB,
+   MCDE_EXTSRC0CONF_BPP_ARGB,
+   MCDE_EXTSRC0CONF_BPP_YCBCR422,
+};
+
+enum mcde_src_synch {
+   MCDE_CHNL0SYNCHMOD_SRC_SYNCH_HARDWARE,
+   MCDE_CHNL0SYNCHMOD_SRC_SYNCH_NO_SYNCH,
+   MCDE_CHNL0SYNCHMOD_SRC_SYNCH_SOFTWARE,
+};
+
+struct mcde_simple_priv {
+   fdt_addr_t base;
+   enum mcde_src_synch src_synch;
+};
+
+static int mcde_simple_probe(struct udevice *dev)
+{
+   struct mcde_simple_priv *priv = dev_get_priv(dev);
+   struct video_uc_plat *plat = dev_get_uclass_plat(dev);
+   struct video_priv *uc_priv = dev_get_uclass_priv(dev);
+   u32 val;
+
+   priv->base = dev_read_addr(dev);
+   if (priv->base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   plat->base = readl(priv->base + MCDE_EXTSRC0A0);
+   if (!plat->base)
+   return -ENODEV;
+
+   val = readl(priv->base + MCDE_OVL0CONF);
+   uc_priv->xsize = FIELD_GET(MCDE_OVL0CONF_PPL, val);
+   uc_priv->ysize = FIELD_GET(MCDE_OVL0CONF_LPF, val);
+   uc_priv->rot = 0;
+
+   val = readl(priv->base + MCDE_EXTSRC0CONF);
+   switch (FIELD_GET(MCDE_EXTSRC0CONF_BPP, val)) {
+

[PATCH] timer: nomadik-mtu: Use dev_read_addr_ptr()

[Stephan Gerhold]

Simplify the code a bit by using dev_read_addr_ptr() instead of
dev_read_addr(). This avoids having to cast explicitly to the
struct nomadik_mtu_regs.

Signed-off-by: Stephan Gerhold 
---

 drivers/timer/nomadik-mtu-timer.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/timer/nomadik-mtu-timer.c 
b/drivers/timer/nomadik-mtu-timer.c
index 417b419d46..4d24de14ae 100644
--- a/drivers/timer/nomadik-mtu-timer.c
+++ b/drivers/timer/nomadik-mtu-timer.c
@@ -67,14 +67,11 @@ static int nomadik_mtu_probe(struct udevice *dev)
struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
struct nomadik_mtu_priv *priv = dev_get_priv(dev);
struct nomadik_mtu_regs *mtu;
-   fdt_addr_t addr;
u32 prescale;
 
-   addr = dev_read_addr(dev);
-   if (addr == FDT_ADDR_T_NONE)
+   mtu = dev_read_addr_ptr(dev);
+   if (!mtu)
return -EINVAL;
-
-   mtu = (struct nomadik_mtu_regs *)addr;
priv->timer = mtu->timers; /* Use first timer */
 
if (!uc_priv->clock_rate)
-- 
2.32.0

[PATCH 2/2] gpio: Add driver for Nomadik GPIO

[Stephan Gerhold]

Nomadik GPIO is a fairly simple GPIO module used in the ST-Ericsson
Ux500 SoCs (and some older Nomadik SoCs). It uses registers where
each GPIO is represented as a single bit, plus "set" and "clear"
registers that allow updating the state without having to read the
existing state.

The driver implements support for it for use together with DM_GPIO
and the existing ste-dbx5x0.dtsi device tree.

Cc: Linus Walleij 
Signed-off-by: Stephan Gerhold 
---

 drivers/gpio/Kconfig|   8 +++
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/nmk_gpio.c | 125 
 3 files changed, 134 insertions(+)
 create mode 100644 drivers/gpio/nmk_gpio.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index de4dc51d4b..0817b12c5f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -495,4 +495,12 @@ config NX_GPIO
  The GPIOs for a device are defined in the device tree with one node
  for each bank.
 
+config NOMADIK_GPIO
+   bool "Nomadik GPIO driver"
+   depends on DM_GPIO
+   help
+ Support GPIO access on ST-Ericsson Ux500 SoCs. The GPIOs are arranged
+ into a number of banks each with 32 GPIOs. The GPIOs for a device are
+ defined in the device tree with one node for each bank.
+
 endmenu
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 3da0d2eb33..3de9734724 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -68,3 +68,4 @@ obj-$(CONFIG_MT7621_GPIO) += mt7621_gpio.o
 obj-$(CONFIG_MSCC_SGPIO)   += mscc_sgpio.o
 obj-$(CONFIG_NX_GPIO)  += nx_gpio.o
 obj-$(CONFIG_SIFIVE_GPIO)  += sifive-gpio.o
+obj-$(CONFIG_NOMADIK_GPIO) += nmk_gpio.o
diff --git a/drivers/gpio/nmk_gpio.c b/drivers/gpio/nmk_gpio.c
new file mode 100644
index 00..e1bb41b196
--- /dev/null
+++ b/drivers/gpio/nmk_gpio.c
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2019 Stephan Gerhold */
+
+#include 
+#include 
+#include 
+#include 
+
+struct nmk_gpio_regs {
+   u32 dat;/* data */
+   u32 dats;   /* data set */
+   u32 datc;   /* data clear */
+   u32 pdis;   /* pull disable */
+   u32 dir;/* direction */
+   u32 dirs;   /* direction set */
+   u32 dirc;   /* direction clear */
+   u32 slpm;   /* sleep mode */
+   u32 afsla;  /* alternate function select A */
+   u32 afslb;  /* alternate function select B */
+   u32 lowemi; /* low EMI mode */
+};
+
+struct nmk_gpio {
+   struct nmk_gpio_regs *regs;
+};
+
+static int nmk_gpio_get_value(struct udevice *dev, unsigned offset)
+{
+   struct nmk_gpio *priv = dev_get_priv(dev);
+
+   return !!(readl(>regs->dat) & BIT(offset));
+}
+
+static int nmk_gpio_set_value(struct udevice *dev, unsigned offset, int value)
+{
+   struct nmk_gpio *priv = dev_get_priv(dev);
+
+   if (value)
+   writel(BIT(offset), >regs->dats);
+   else
+   writel(BIT(offset), >regs->datc);
+
+   return 0;
+}
+
+static int nmk_gpio_get_function(struct udevice *dev, unsigned offset)
+{
+   struct nmk_gpio *priv = dev_get_priv(dev);
+
+   if (readl(>regs->afsla) & BIT(offset) ||
+   readl(>regs->afslb) & BIT(offset))
+   return GPIOF_FUNC;
+
+   if (readl(>regs->dir) & BIT(offset))
+   return GPIOF_OUTPUT;
+   else
+   return GPIOF_INPUT;
+}
+
+static int nmk_gpio_direction_input(struct udevice *dev, unsigned offset)
+{
+   struct nmk_gpio *priv = dev_get_priv(dev);
+
+   writel(BIT(offset), >regs->dirc);
+   return 0;
+}
+
+static int nmk_gpio_direction_output(struct udevice *dev, unsigned offset,
+int value)
+{
+   struct nmk_gpio *priv = dev_get_priv(dev);
+
+   writel(BIT(offset), >regs->dirs);
+   return nmk_gpio_set_value(dev, offset, value);
+}
+
+static const struct dm_gpio_ops nmk_gpio_ops = {
+   .get_value  = nmk_gpio_get_value,
+   .set_value  = nmk_gpio_set_value,
+   .get_function   = nmk_gpio_get_function,
+   .direction_input= nmk_gpio_direction_input,
+   .direction_output   = nmk_gpio_direction_output,
+};
+
+static int nmk_gpio_probe(struct udevice *dev)
+{
+   struct nmk_gpio *priv = dev_get_priv(dev);
+   struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   char buf[20];
+   u32 bank;
+   int ret;
+
+   priv->regs = dev_read_addr_ptr(dev);
+   if (!priv->regs)
+   return -EINVAL;
+
+   ret = dev_read_u32(dev, "gpio-bank", );
+   if (ret < 0) {
+   printf("nmk_gpio(%s): Failed to read gpio-bank\n", dev->name);
+   return ret;
+   }
+
+   sprintf(buf, "nmk%u-gpio", bank);
+   uc_priv->bank_

[PATCH 1/2] gpio: Drop long unused DB8500 GPIO driver

[Stephan Gerhold]

The original U-Boot port for the ST-Ericsson U8500 SoC was dropped
in commit 68282f55b846 ("arm: Remove unused ST-Ericsson u8500 arch").
Most of the drivers related to the old port were removed, but the
db8500_gpio.c driver was forgotten for some reason. There is no way
to select it and it does not compile anymore because of missing
headers, so let's just remove it.

The new port for U8500 introduced in commit 689088f9dae8
("arm: Add support for ST-Ericsson U8500 SoC") fully embraces the
new Driver Model and device trees where possible, so this is
preparation to add a new, simplified GPIO driver based on DM_GPIO.

Signed-off-by: Stephan Gerhold 
---

 drivers/gpio/Makefile  |   1 -
 drivers/gpio/db8500_gpio.c | 221 -
 2 files changed, 222 deletions(-)
 delete mode 100644 drivers/gpio/db8500_gpio.c

diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 8541ba0b0a..3da0d2eb33 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -44,7 +44,6 @@ obj-$(CONFIG_MPC8XXX_GPIO)+= mpc8xxx_gpio.o
 obj-$(CONFIG_MPC83XX_SPISEL_BOOT)  += mpc83xx_spisel_boot.o
 obj-$(CONFIG_SH_GPIO_PFC)  += sh_pfc.o
 obj-$(CONFIG_OMAP_GPIO)+= omap_gpio.o
-obj-$(CONFIG_DB8500_GPIO)  += db8500_gpio.o
 obj-$(CONFIG_BCM2835_GPIO) += bcm2835_gpio.o
 obj-$(CONFIG_XILINX_GPIO)  += xilinx_gpio.o
 obj-$(CONFIG_ADI_GPIO2)+= adi_gpio2.o
diff --git a/drivers/gpio/db8500_gpio.c b/drivers/gpio/db8500_gpio.c
deleted file mode 100644
index eefb56d83f..00
--- a/drivers/gpio/db8500_gpio.c
+++ /dev/null
@@ -1,221 +0,0 @@
-/*
- * Code ported from Nomadik GPIO driver in ST-Ericsson Linux kernel code.
- * The purpose is that GPIO config found in kernel should work by simply
- * copy-paste it to U-Boot.
- *
- * Original Linux authors:
- * Copyright (C) 2008,2009 STMicroelectronics
- * Copyright (C) 2009 Alessandro Rubini 
- *   Rewritten based on work by Prafulla WADASKAR 
- *
- * Ported to U-Boot by:
- * Copyright (C) 2010 Joakim Axelsson 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include 
-#include 
-
-#include 
-#include 
-#include 
-
-#define IO_ADDR(x) (void *) (x)
-
-/*
- * The GPIO module in the db8500 Systems-on-Chip is an
- * AMBA device, managing 32 pins and alternate functions. The logic block
- * is currently only used in the db8500.
- */
-
-#define GPIO_TOTAL_PINS268
-#define GPIO_PINS_PER_BLOCK32
-#define GPIO_BLOCKS_COUNT  (GPIO_TOTAL_PINS/GPIO_PINS_PER_BLOCK + 1)
-#define GPIO_BLOCK(pin)(((pin + GPIO_PINS_PER_BLOCK) >> 5) - 1)
-#define GPIO_PIN_WITHIN_BLOCK(pin) ((pin)%(GPIO_PINS_PER_BLOCK))
-
-/* Register in the logic block */
-#define DB8500_GPIO_DAT0x00
-#define DB8500_GPIO_DATS   0x04
-#define DB8500_GPIO_DATC   0x08
-#define DB8500_GPIO_PDIS   0x0c
-#define DB8500_GPIO_DIR0x10
-#define DB8500_GPIO_DIRS   0x14
-#define DB8500_GPIO_DIRC   0x18
-#define DB8500_GPIO_SLPC   0x1c
-#define DB8500_GPIO_AFSLA  0x20
-#define DB8500_GPIO_AFSLB  0x24
-
-#define DB8500_GPIO_RIMSC  0x40
-#define DB8500_GPIO_FIMSC  0x44
-#define DB8500_GPIO_IS 0x48
-#define DB8500_GPIO_IC 0x4c
-#define DB8500_GPIO_RWIMSC 0x50
-#define DB8500_GPIO_FWIMSC 0x54
-#define DB8500_GPIO_WKS0x58
-
-static void __iomem *get_gpio_addr(unsigned gpio)
-{
-   /* Our list of GPIO chips */
-   static void __iomem *gpio_addrs[GPIO_BLOCKS_COUNT] = {
-   IO_ADDR(CFG_GPIO_0_BASE),
-   IO_ADDR(CFG_GPIO_1_BASE),
-   IO_ADDR(CFG_GPIO_2_BASE),
-   IO_ADDR(CFG_GPIO_3_BASE),
-   IO_ADDR(CFG_GPIO_4_BASE),
-   IO_ADDR(CFG_GPIO_5_BASE),
-   IO_ADDR(CFG_GPIO_6_BASE),
-   IO_ADDR(CFG_GPIO_7_BASE),
-   IO_ADDR(CFG_GPIO_8_BASE)
-   };
-
-   return gpio_addrs[GPIO_BLOCK(gpio)];
-}
-
-static unsigned get_gpio_offset(unsigned gpio)
-{
-   return GPIO_PIN_WITHIN_BLOCK(gpio);
-}
-
-/* Can only be called from config_pin. Don't configure alt-mode directly */
-static void gpio_set_mode(unsigned gpio, enum db8500_gpio_alt mode)
-{
-   void __iomem *addr = get_gpio_addr(gpio);
-   unsigned offset = get_gpio_offset(gpio);
-   u32 bit = 1 << offset;
-   u32 afunc, bfunc;
-
-   afunc = readl(addr + DB8500_GPIO_AFSLA) & ~bit;
-   bfunc = readl(addr + DB8500_GPIO_AFSLB) & ~bit;
-   if (mode & DB8500_GPIO_ALT_A)
-   afunc |= bit;
-   if (mode & DB8500_GPIO_ALT_B)
-   bfunc |= bit;
-   writel(afunc, addr + DB8500_GPIO_AFSLA);
-   writel(bfunc, addr + DB8500_GPIO_AFSLB);
-}
-
-/**
- * db8500_gpio_set_pull() - enable/disable pull up/down on a gpio
- * @gpio: pi

Re: [RFC] Load U-Boot without LK on DragonBoard 410c (+ DB820c?)

[Stephan Gerhold]

On Fri, Jul 02, 2021 at 01:04:42PM +0300, Ramon Fried wrote:
> On Thu, Jul 1, 2021 at 4:24 PM Stephan Gerhold  wrote:
> > On Thu, Jul 01, 2021 at 01:27:30PM +0200, Nicolas Dechesne wrote:
> > > On Thu, Jul 1, 2021 at 11:07 AM Stephan Gerhold  
> > > wrote:
> > > >
> > > > Hi!
> > > >
> > > > at the moment the U-Boot ports for both DragonBoard 410c and 820c are
> > > > designed to be loaded as an Android boot image after Qualcomm's LK
> > > > bootloader. This is simple to set up but LK is redundant in this case,
> > > > since everything done by LK can be also done directly by U-Boot.
> > > >
> > > > Dropping LK entirely would have at least the following advantages:
> > > >   - Easier installation/board code (no need for Android boot images)
> > > >   - (Slightly) faster boot
> > > >   - Boot directly in 64-bit without a round trip to 32-bit for LK
> > > >
> > > > This was not possible so far because of some unsolved problems.
> > > > For clarity I try to describe them together with some background here,
> > > > but I want to apologize for the long text. It's all quite complicated. 
> > > > :)
> > > >
> > > > 1. "Signing" 64-bit U-Boot
> > > > ==
> > > >
> > > > Ramon already tried to eliminate LK for DB410c 3 years ago [1].
> > > > One of the open problems back then was to have a proper "signing"
> > > > tool with 64-bit support. The firmware expects an ELF image with a few
> > > > Qualcomm-specific ELF headers. Normally this is used for secure boot
> > > > setups. This is not used on DragonBoards, but the firmware still insists
> > > > on having a dummy (self-signed) certificate chain in the ELF images.
> > >
> > > Yeah, the signing was the last step we missed. We were able to sign
> > > using internal / non open source tools.. but never finalized the boot
> > > process completely.. I am very happy you persisted with that!
> > >
> > > >
> > > > Linaro uses signlk [2] to sign their builds of LK. It looks like Nicolas
> > > > extended it with ELF64 support after Ramon's mail [3]. However, for some
> > > > reason signlk literally works only for LK for me. I tried to "sign"
> > > > U-Boot and some other firmware, but everything except LK is always
> > > > rejected with the following message on boot:
> > > >
> > > > B -   1031113 - Error code 302e at boot_config.c Line 296
> > > >
> > > > I tried to track down the issue in the source code for quite some time
> > > > but did not manage to find the problem. Perhaps it's some subtle mistake
> > > > with some of the ELF modifications, I'm not sure. (For some reason,
> > > > signlk makes subtle changes to all of the existing ELF headers...)
> > > >
> > > > After reading about the image format myself I decided to try to make my
> > > > own "signing" tool, qtestsign: 
> > > > https://github.com/msm8916-mainline/qtestsign
> > > > It's based on a mixture of the specification [4] and some missing bits
> > > > taken from signlk, put in a simple and clean Python tool. I still don't
> > > > know what exactly qtestsign does different, but unlike signlk it can
> > > > successfully "sign" U-Boot and all other firmware from DragonBoard 410c.
> > >
> > > There is no specific reason to restrict ourselves to using signlk.. if
> > > you have something better, which works, that's perfect!
> > >
> > > >
> > > > [1]: 
> > > > https://lore.kernel.org/u-boot/CA+Kvs9kS=dbjknaixk_3tz+3iwnrasp0gjdz8ekrzaskor6...@mail.gmail.com/
> > > > [2]: https://git.linaro.org/landing-teams/working/qualcomm/signlk.git/
> > > > [3]: 
> > > > https://git.linaro.org/landing-teams/working/qualcomm/signlk.git/commit/?id=1f61c03322c3728f35b3f0cd4ff04f73522f1e67
> > > > [4]: 
> > > > https://www.qualcomm.com/media/documents/files/secure-boot-and-image-authentication-technical-overview-v1-0.pdf
> > > >
> > > > My solution
> > > > ---
> > > >
> > > > Now we have all we need to install U-Boot without LK. For DragonBoard 
> > > > 410c
> > > > the following steps end up in the U-Boot prompt without going through 
> > > > LK:
> > > >
> > >

[PATCH] image: android: Automatically detect more compression types

[Stephan Gerhold]

At the moment android_image_get_kcomp() can automatically detect
LZ4 compressed kernels and the compression specified in uImages.
However, especially on ARM64 Linux is often compressed with GZIP.
Attempting to boot an Android image with a GZIP compressed kernel
image currently results in a very strange crash, e.g.

  Starting kernel ...
  "Synchronous Abort" handler, esr 0x0200
   ...
  Code: d555 5d55 555f 5d555d55 (00088b1f)

Note the 1f8b, which are the "magic" bytes for GZIP images.

U-Boot already has the image_decomp_type() function that checks for
the magic bytes of bzip2, gzip, lzma and lzo. It's easy to make use
of it here to increase the chance that we do the right thing and the
user does not become confused with strange crashes.

This allows booting Android boot images that contain GZIP-compressed
kernel images.

Signed-off-by: Stephan Gerhold 
---

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

diff --git a/common/image-android.c b/common/image-android.c
index d07b0e0f09..1fa1eb 100644
--- a/common/image-android.c
+++ b/common/image-android.c
@@ -164,7 +164,7 @@ ulong android_image_get_kcomp(const struct andr_img_hdr 
*hdr)
else if (get_unaligned_le32(p) == LZ4F_MAGIC)
return IH_COMP_LZ4;
else
-   return IH_COMP_NONE;
+   return image_decomp_type(p, sizeof(u32));
 }
 
 int android_image_get_ramdisk(const struct andr_img_hdr *hdr,
-- 
2.32.0

Re: [RFC] Load U-Boot without LK on DragonBoard 410c (+ DB820c?)

[Stephan Gerhold]

Hi Nicolas,

On Thu, Jul 01, 2021 at 01:27:30PM +0200, Nicolas Dechesne wrote:
> On Thu, Jul 1, 2021 at 11:07 AM Stephan Gerhold  wrote:
> >
> > Hi!
> >
> > at the moment the U-Boot ports for both DragonBoard 410c and 820c are
> > designed to be loaded as an Android boot image after Qualcomm's LK
> > bootloader. This is simple to set up but LK is redundant in this case,
> > since everything done by LK can be also done directly by U-Boot.
> >
> > Dropping LK entirely would have at least the following advantages:
> >   - Easier installation/board code (no need for Android boot images)
> >   - (Slightly) faster boot
> >   - Boot directly in 64-bit without a round trip to 32-bit for LK
> >
> > This was not possible so far because of some unsolved problems.
> > For clarity I try to describe them together with some background here,
> > but I want to apologize for the long text. It's all quite complicated. :)
> >
> > 1. "Signing" 64-bit U-Boot
> > ==
> >
> > Ramon already tried to eliminate LK for DB410c 3 years ago [1].
> > One of the open problems back then was to have a proper "signing"
> > tool with 64-bit support. The firmware expects an ELF image with a few
> > Qualcomm-specific ELF headers. Normally this is used for secure boot
> > setups. This is not used on DragonBoards, but the firmware still insists
> > on having a dummy (self-signed) certificate chain in the ELF images.
> 
> Yeah, the signing was the last step we missed. We were able to sign
> using internal / non open source tools.. but never finalized the boot
> process completely.. I am very happy you persisted with that!
> 
> >
> > Linaro uses signlk [2] to sign their builds of LK. It looks like Nicolas
> > extended it with ELF64 support after Ramon's mail [3]. However, for some
> > reason signlk literally works only for LK for me. I tried to "sign"
> > U-Boot and some other firmware, but everything except LK is always
> > rejected with the following message on boot:
> >
> > B -   1031113 - Error code 302e at boot_config.c Line 296
> >
> > I tried to track down the issue in the source code for quite some time
> > but did not manage to find the problem. Perhaps it's some subtle mistake
> > with some of the ELF modifications, I'm not sure. (For some reason,
> > signlk makes subtle changes to all of the existing ELF headers...)
> >
> > After reading about the image format myself I decided to try to make my
> > own "signing" tool, qtestsign: https://github.com/msm8916-mainline/qtestsign
> > It's based on a mixture of the specification [4] and some missing bits
> > taken from signlk, put in a simple and clean Python tool. I still don't
> > know what exactly qtestsign does different, but unlike signlk it can
> > successfully "sign" U-Boot and all other firmware from DragonBoard 410c.
> 
> There is no specific reason to restrict ourselves to using signlk.. if
> you have something better, which works, that's perfect!
> 
> >
> > [1]: 
> > https://lore.kernel.org/u-boot/CA+Kvs9kS=dbjknaixk_3tz+3iwnrasp0gjdz8ekrzaskor6...@mail.gmail.com/
> > [2]: https://git.linaro.org/landing-teams/working/qualcomm/signlk.git/
> > [3]: 
> > https://git.linaro.org/landing-teams/working/qualcomm/signlk.git/commit/?id=1f61c03322c3728f35b3f0cd4ff04f73522f1e67
> > [4]: 
> > https://www.qualcomm.com/media/documents/files/secure-boot-and-image-authentication-technical-overview-v1-0.pdf
> >
> > My solution
> > ---
> >
> > Now we have all we need to install U-Boot without LK. For DragonBoard 410c
> > the following steps end up in the U-Boot prompt without going through LK:
> >
> > 1. Change dragonboard410c_defconfig as follows:
> >
> >-CONFIG_SYS_TEXT_BASE=0x8008
> >+CONFIG_SYS_TEXT_BASE=0x8F60
> >+CONFIG_OF_EMBED=y (I discuss this at the end of the mail)
> >
> > 2. $ make
> > 3. Sign the ELF image: $ qtestsign.py aboot /u-boot [5]
> > 4. Flash "/u-boot-test-signed.mbn" to the "aboot" partition
> >
> > [5]: https://github.com/msm8916-mainline/qtestsign
> >
> > 2. Linux gets stuck when loaded by 64-bit U-Boot without LK
> > ===
> >
> > This should work well enough to get the U-Boot prompt on serial.
> > However, once you load Linux you will likely notice a problem:
> >
> > [0.059043] smp: Bringing up secondary CPUs ...
> > [5.120691] CPU1: failed to c

[RFC] Load U-Boot without LK on DragonBoard 410c (+ DB820c?)

[Stephan Gerhold]

Hi!

at the moment the U-Boot ports for both DragonBoard 410c and 820c are
designed to be loaded as an Android boot image after Qualcomm's LK
bootloader. This is simple to set up but LK is redundant in this case,
since everything done by LK can be also done directly by U-Boot.

Dropping LK entirely would have at least the following advantages:
  - Easier installation/board code (no need for Android boot images)
  - (Slightly) faster boot
  - Boot directly in 64-bit without a round trip to 32-bit for LK

This was not possible so far because of some unsolved problems.
For clarity I try to describe them together with some background here,
but I want to apologize for the long text. It's all quite complicated. :)

1. "Signing" 64-bit U-Boot
==

Ramon already tried to eliminate LK for DB410c 3 years ago [1].
One of the open problems back then was to have a proper "signing"
tool with 64-bit support. The firmware expects an ELF image with a few
Qualcomm-specific ELF headers. Normally this is used for secure boot
setups. This is not used on DragonBoards, but the firmware still insists
on having a dummy (self-signed) certificate chain in the ELF images.

Linaro uses signlk [2] to sign their builds of LK. It looks like Nicolas
extended it with ELF64 support after Ramon's mail [3]. However, for some
reason signlk literally works only for LK for me. I tried to "sign"
U-Boot and some other firmware, but everything except LK is always
rejected with the following message on boot:

B -   1031113 - Error code 302e at boot_config.c Line 296

I tried to track down the issue in the source code for quite some time
but did not manage to find the problem. Perhaps it's some subtle mistake
with some of the ELF modifications, I'm not sure. (For some reason,
signlk makes subtle changes to all of the existing ELF headers...)

After reading about the image format myself I decided to try to make my
own "signing" tool, qtestsign: https://github.com/msm8916-mainline/qtestsign
It's based on a mixture of the specification [4] and some missing bits
taken from signlk, put in a simple and clean Python tool. I still don't
know what exactly qtestsign does different, but unlike signlk it can
successfully "sign" U-Boot and all other firmware from DragonBoard 410c.

[1]: 
https://lore.kernel.org/u-boot/CA+Kvs9kS=dbjknaixk_3tz+3iwnrasp0gjdz8ekrzaskor6...@mail.gmail.com/
[2]: https://git.linaro.org/landing-teams/working/qualcomm/signlk.git/
[3]: 
https://git.linaro.org/landing-teams/working/qualcomm/signlk.git/commit/?id=1f61c03322c3728f35b3f0cd4ff04f73522f1e67
[4]: 
https://www.qualcomm.com/media/documents/files/secure-boot-and-image-authentication-technical-overview-v1-0.pdf

My solution
---

Now we have all we need to install U-Boot without LK. For DragonBoard 410c
the following steps end up in the U-Boot prompt without going through LK:

1. Change dragonboard410c_defconfig as follows:

   -CONFIG_SYS_TEXT_BASE=0x8008
   +CONFIG_SYS_TEXT_BASE=0x8F60
   +CONFIG_OF_EMBED=y (I discuss this at the end of the mail)

2. $ make
3. Sign the ELF image: $ qtestsign.py aboot /u-boot [5]
4. Flash "/u-boot-test-signed.mbn" to the "aboot" partition

[5]: https://github.com/msm8916-mainline/qtestsign

2. Linux gets stuck when loaded by 64-bit U-Boot without LK
===

This should work well enough to get the U-Boot prompt on serial.
However, once you load Linux you will likely notice a problem:

[0.059043] smp: Bringing up secondary CPUs ...
[5.120691] CPU1: failed to come online
[   10.246760] CPU2: failed to come online
[   15.372848] CPU3: failed to come online
[   15.406275] CPU: All CPU(s) started at EL1
 ...
[   16.185527] genirq: irq_chip msmgpio did not update eff. affinity mask 
of irq 79
 Board freezes forever. :(

My investigations have shown this is a bug in the PSCI implementation on
DB410c (part of the TrustZone/"tz" firmware). Shortly said, since we
have never done the 32-bit -> 64-bit switch in LK, the PSCI implementation
seems to believe we are still running in 32-bit mode and starts all
further CPUs in 32-bit mode. The other CPU cores crash immediately when
coming up and CPU 0 hangs once CPU idle suspends it for the first time.

I have described this problem together with a workaround in detail here:
https://github.com/msm8916-mainline/qhypstub#boot-flow

The idea is to execute the TZ syscall to switch from 32-bit -> 64-bit
even though we are already running in 64-bit mode. This will make the
PSCI implementation aware that we want all further CPU cores booted in
64-bit mode as well.

My solution
---

The workaround is applied automatically when using my open-source "hyp"
firmware replacement qhypstub: https://github.com/msm8916-mainline/qhypstub
As a bonus, both U-Boot and Linux start in EL2, making it possible to
use virtualization (e.g. KVM in Linux).

$ git clone 

Re: [PATCH] serial: serial_msm: Ensure BAM/single character mode are disabled

[Stephan Gerhold]

On Tue, Jun 29, 2021 at 08:16:09AM +0300, Ramon Fried wrote:
> On Mon, Jun 28, 2021 at 10:16 PM Stephan Gerhold  wrote:
> >
> > On Mon, Jun 28, 2021 at 10:04:29PM +0300, Ramon Fried wrote:
> > > On Mon, Jun 28, 2021 at 9:59 PM Stephan Gerhold  
> > > wrote:
> > > >
> > > > On Mon, Jun 28, 2021 at 08:15:28PM +0300, Ramon Fried wrote:
> > > > > On Mon, Jun 28, 2021 at 11:40 AM Stephan Gerhold 
> > > > >  wrote:
> > > > > >
> > > > > > At the moment, the U-Boot serial_msm driver does not initialize the
> > > > > > UART_DM_DMEN register with the required value. Usually this does not
> > > > > > cause any problems, because there is Qualcomm's LK bootloader 
> > > > > > running
> > > > > > before U-Boot which initializes the register with the correct value.
> > > > > >
> > > > > > It's important that this register is initialized correctly, because
> > > > > > the U-Boot driver does not make use of the BAM/DMA or single 
> > > > > > character
> > > > > > mode functionality of the UART controller. A different bootloader
> > > > > > before U-Boot might initialize the register differently.
> > > > > >
> > > > > > For example, on DragonBoard 410c U-Boot can also be installed to the
> > > > > > "aboot" partition (replacing LK entirely). In this case U-Boot is
> > > > > > loaded directly by SBL, which seems to use the single-character mode
> > > > > > for some reason. In single character mode there is always just one
> > > > > > char in the FIFO, instead of the 4 characters expected by
> > > > > > msm_serial_fetch(). It also causes issues with "earlycon" later in
> > > > > > the Linux kernel, which tries to output 4 chars at once,
> > > > > > but only the first char will be written.
> > > > > >
> > > > > > This causes early UART log in Linux to be corrupted like this:
> > > > > >
> > > > > > [ 00ano:ameoi .Q1B[ 00ac _idaM00080oo'ahani-lcle._20). 15NdNii 
> > > > > > 5 SPMSJ20:U2
> > > > > > [ 00rkoolmsamel
> > > > > > [ 00Fw ]elamletopsioble
> > > > > > [ 00ore
> > > > > >
> > > > > > instead of
> > > > > >
> > > > > > [0.00] Booting Linux on physical CPU 0x00 
> > > > > > [0x410fd030]
> > > > > > [0.00] Machine model: Qualcomm Technologies, Inc. APQ 
> > > > > > 8016 SBC
> > > > > > [0.00] earlycon: msm_serial_dm0 at MMIO 
> > > > > > 0x078b (options '')
> > > > > > [0.00] printk: bootconsole [msm_serial_dm0] enabled
> > > > > >
> > > > > > Make sure to initialize UART_DM_DMEN correctly to fix this issue
> > > > > > when loading U-Boot directly after SBL (instead of through LK).
> > > > > >
> > > > > > There is no functional difference when loading U-Boot through LK
> > > > > > since LK also initializes UART_DM_DMEN to 0x0. [1]
> > > > > >
> > > > > > [1]: 
> > > > > > https://git.linaro.org/landing-teams/working/qualcomm/lk.git/tree/platform/msm_shared/uart_dm.c?h=dragonboard410c-LA.BR.1.2.7-03810-8x16.0-linaro3#n203
> > > > > >
> > > > > > Cc: Ramon Fried 
> > > > > > Signed-off-by: Stephan Gerhold 
> > > > > > ---
> > > > > >
> > > > > >  drivers/serial/serial_msm.c | 4 
> > > > > >  1 file changed, 4 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/serial/serial_msm.c 
> > > > > > b/drivers/serial/serial_msm.c
> > > > > > index d8c6c2f6b5..d8dd5c1104 100644
> > > > > > --- a/drivers/serial/serial_msm.c
> > > > > > +++ b/drivers/serial/serial_msm.c
> > > > > > @@ -23,6 +23,7 @@
> > > > > >  /* Serial registers - this driver works in uartdm mode*/
> > > > > >
> > > > > >  #define UARTDM_DMRX 0x34 /* Max RX transfer length */
> > > > > > +#define UARTDM_DMEN 0x3C /* DMA/data-packing mode */
> > > > > >  #de

Re: [PATCH] serial: serial_msm: Ensure BAM/single character mode are disabled

[Stephan Gerhold]

On Mon, Jun 28, 2021 at 10:04:29PM +0300, Ramon Fried wrote:
> On Mon, Jun 28, 2021 at 9:59 PM Stephan Gerhold  wrote:
> >
> > On Mon, Jun 28, 2021 at 08:15:28PM +0300, Ramon Fried wrote:
> > > On Mon, Jun 28, 2021 at 11:40 AM Stephan Gerhold  
> > > wrote:
> > > >
> > > > At the moment, the U-Boot serial_msm driver does not initialize the
> > > > UART_DM_DMEN register with the required value. Usually this does not
> > > > cause any problems, because there is Qualcomm's LK bootloader running
> > > > before U-Boot which initializes the register with the correct value.
> > > >
> > > > It's important that this register is initialized correctly, because
> > > > the U-Boot driver does not make use of the BAM/DMA or single character
> > > > mode functionality of the UART controller. A different bootloader
> > > > before U-Boot might initialize the register differently.
> > > >
> > > > For example, on DragonBoard 410c U-Boot can also be installed to the
> > > > "aboot" partition (replacing LK entirely). In this case U-Boot is
> > > > loaded directly by SBL, which seems to use the single-character mode
> > > > for some reason. In single character mode there is always just one
> > > > char in the FIFO, instead of the 4 characters expected by
> > > > msm_serial_fetch(). It also causes issues with "earlycon" later in
> > > > the Linux kernel, which tries to output 4 chars at once,
> > > > but only the first char will be written.
> > > >
> > > > This causes early UART log in Linux to be corrupted like this:
> > > >
> > > > [ 00ano:ameoi .Q1B[ 00ac _idaM00080oo'ahani-lcle._20). 15NdNii 5 
> > > > SPMSJ20:U2
> > > > [ 00rkoolmsamel
> > > > [ 00Fw ]elamletopsioble
> > > > [ 00ore
> > > >
> > > > instead of
> > > >
> > > > [0.00] Booting Linux on physical CPU 0x00 
> > > > [0x410fd030]
> > > > [0.00] Machine model: Qualcomm Technologies, Inc. APQ 8016 
> > > > SBC
> > > > [0.00] earlycon: msm_serial_dm0 at MMIO 0x078b 
> > > > (options '')
> > > > [0.00] printk: bootconsole [msm_serial_dm0] enabled
> > > >
> > > > Make sure to initialize UART_DM_DMEN correctly to fix this issue
> > > > when loading U-Boot directly after SBL (instead of through LK).
> > > >
> > > > There is no functional difference when loading U-Boot through LK
> > > > since LK also initializes UART_DM_DMEN to 0x0. [1]
> > > >
> > > > [1]: 
> > > > https://git.linaro.org/landing-teams/working/qualcomm/lk.git/tree/platform/msm_shared/uart_dm.c?h=dragonboard410c-LA.BR.1.2.7-03810-8x16.0-linaro3#n203
> > > >
> > > > Cc: Ramon Fried 
> > > > Signed-off-by: Stephan Gerhold 
> > > > ---
> > > >
> > > >  drivers/serial/serial_msm.c | 4 
> > > >  1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c
> > > > index d8c6c2f6b5..d8dd5c1104 100644
> > > > --- a/drivers/serial/serial_msm.c
> > > > +++ b/drivers/serial/serial_msm.c
> > > > @@ -23,6 +23,7 @@
> > > >  /* Serial registers - this driver works in uartdm mode*/
> > > >
> > > >  #define UARTDM_DMRX 0x34 /* Max RX transfer length */
> > > > +#define UARTDM_DMEN 0x3C /* DMA/data-packing mode */
> > > >  #define UARTDM_NCF_TX   0x40 /* Number of chars to TX */
> > > >
> > > >  #define UARTDM_RXFS 0x50 /* RX channel status register */
> > > > @@ -197,6 +198,9 @@ static void uart_dm_init(struct msm_serial_data 
> > > > *priv)
> > > > writel(MSM_BOOT_UART_DM_8_N_1_MODE, priv->base + UARTDM_MR2);
> > > > writel(MSM_BOOT_UART_DM_CMD_RESET_RX, priv->base + UARTDM_CR);
> > > > writel(MSM_BOOT_UART_DM_CMD_RESET_TX, priv->base + UARTDM_CR);
> > > > +
> > > > +   /* Make sure BAM/single character mode is disabled */
> > > > +   writel(0x0, priv->base + UARTDM_DMEN);
> > > >  }
> > > >  static int msm_serial_probe(struct udevice *dev)
> > > >  {
> > > > --
> > > > 2.32.0
> > > >
> > >

Re: [PATCH] serial: serial_msm: Ensure BAM/single character mode are disabled

[Stephan Gerhold]

On Mon, Jun 28, 2021 at 08:15:28PM +0300, Ramon Fried wrote:
> On Mon, Jun 28, 2021 at 11:40 AM Stephan Gerhold  wrote:
> >
> > At the moment, the U-Boot serial_msm driver does not initialize the
> > UART_DM_DMEN register with the required value. Usually this does not
> > cause any problems, because there is Qualcomm's LK bootloader running
> > before U-Boot which initializes the register with the correct value.
> >
> > It's important that this register is initialized correctly, because
> > the U-Boot driver does not make use of the BAM/DMA or single character
> > mode functionality of the UART controller. A different bootloader
> > before U-Boot might initialize the register differently.
> >
> > For example, on DragonBoard 410c U-Boot can also be installed to the
> > "aboot" partition (replacing LK entirely). In this case U-Boot is
> > loaded directly by SBL, which seems to use the single-character mode
> > for some reason. In single character mode there is always just one
> > char in the FIFO, instead of the 4 characters expected by
> > msm_serial_fetch(). It also causes issues with "earlycon" later in
> > the Linux kernel, which tries to output 4 chars at once,
> > but only the first char will be written.
> >
> > This causes early UART log in Linux to be corrupted like this:
> >
> > [ 00ano:ameoi .Q1B[ 00ac _idaM00080oo'ahani-lcle._20). 15NdNii 5 
> > SPMSJ20:U2
> > [ 00rkoolmsamel
> > [ 00Fw ]elamletopsioble
> > [ 00ore
> >
> > instead of
> >
> > [0.00] Booting Linux on physical CPU 0x00 [0x410fd030]
> > [0.00] Machine model: Qualcomm Technologies, Inc. APQ 8016 SBC
> > [0.00] earlycon: msm_serial_dm0 at MMIO 0x078b 
> > (options '')
> > [0.00] printk: bootconsole [msm_serial_dm0] enabled
> >
> > Make sure to initialize UART_DM_DMEN correctly to fix this issue
> > when loading U-Boot directly after SBL (instead of through LK).
> >
> > There is no functional difference when loading U-Boot through LK
> > since LK also initializes UART_DM_DMEN to 0x0. [1]
> >
> > [1]: 
> > https://git.linaro.org/landing-teams/working/qualcomm/lk.git/tree/platform/msm_shared/uart_dm.c?h=dragonboard410c-LA.BR.1.2.7-03810-8x16.0-linaro3#n203
> >
> > Cc: Ramon Fried 
> > Signed-off-by: Stephan Gerhold 
> > ---
> >
> >  drivers/serial/serial_msm.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c
> > index d8c6c2f6b5..d8dd5c1104 100644
> > --- a/drivers/serial/serial_msm.c
> > +++ b/drivers/serial/serial_msm.c
> > @@ -23,6 +23,7 @@
> >  /* Serial registers - this driver works in uartdm mode*/
> >
> >  #define UARTDM_DMRX 0x34 /* Max RX transfer length */
> > +#define UARTDM_DMEN 0x3C /* DMA/data-packing mode */
> >  #define UARTDM_NCF_TX   0x40 /* Number of chars to TX */
> >
> >  #define UARTDM_RXFS 0x50 /* RX channel status register */
> > @@ -197,6 +198,9 @@ static void uart_dm_init(struct msm_serial_data *priv)
> > writel(MSM_BOOT_UART_DM_8_N_1_MODE, priv->base + UARTDM_MR2);
> > writel(MSM_BOOT_UART_DM_CMD_RESET_RX, priv->base + UARTDM_CR);
> > writel(MSM_BOOT_UART_DM_CMD_RESET_TX, priv->base + UARTDM_CR);
> > +
> > +   /* Make sure BAM/single character mode is disabled */
> > +   writel(0x0, priv->base + UARTDM_DMEN);
> >  }
> >  static int msm_serial_probe(struct udevice *dev)
> >  {
> > --
> > 2.32.0
> >
> Hi.
> This is strange, I never encountered the behaviour, and I did boot
> Linux after U-boot without LK in the way.

It happens for me if the boot flow is SBL -> U-Boot -> Linux instead of
SBL -> LK -> U-Boot -> Linux (The latter is the suggested setup
according to dragonboard410c_defconfig and the dragonboard410c
readme.txt, but I wanted to eliminate LK entirely).

If you tried the same, perhaps you didn't have earlycon enabled?
It also happens only during early boot with earlycon enabled
("earlycon" in kernel parameters). It stops happening later on boot
when the kernel fully re-initializes the UART controller. (The idea of
earlycon is to reuse the existing UART configuration to report errors
that occur very early during boot.)

Thanks,
Stephan

[PATCH] serial: serial_msm: Ensure BAM/single character mode are disabled

[Stephan Gerhold]

At the moment, the U-Boot serial_msm driver does not initialize the
UART_DM_DMEN register with the required value. Usually this does not
cause any problems, because there is Qualcomm's LK bootloader running
before U-Boot which initializes the register with the correct value.

It's important that this register is initialized correctly, because
the U-Boot driver does not make use of the BAM/DMA or single character
mode functionality of the UART controller. A different bootloader
before U-Boot might initialize the register differently.

For example, on DragonBoard 410c U-Boot can also be installed to the
"aboot" partition (replacing LK entirely). In this case U-Boot is
loaded directly by SBL, which seems to use the single-character mode
for some reason. In single character mode there is always just one
char in the FIFO, instead of the 4 characters expected by
msm_serial_fetch(). It also causes issues with "earlycon" later in
the Linux kernel, which tries to output 4 chars at once,
but only the first char will be written.

This causes early UART log in Linux to be corrupted like this:

[ 00ano:ameoi .Q1B[ 00ac _idaM00080oo'ahani-lcle._20). 15NdNii 5 SPMSJ20:U2
[ 00rkoolmsamel
[ 00Fw ]elamletopsioble
[ 00ore

instead of

[0.00] Booting Linux on physical CPU 0x00 [0x410fd030]
[0.00] Machine model: Qualcomm Technologies, Inc. APQ 8016 SBC
[0.00] earlycon: msm_serial_dm0 at MMIO 0x078b (options 
'')
[0.00] printk: bootconsole [msm_serial_dm0] enabled

Make sure to initialize UART_DM_DMEN correctly to fix this issue
when loading U-Boot directly after SBL (instead of through LK).

There is no functional difference when loading U-Boot through LK
since LK also initializes UART_DM_DMEN to 0x0. [1]

[1]: 
https://git.linaro.org/landing-teams/working/qualcomm/lk.git/tree/platform/msm_shared/uart_dm.c?h=dragonboard410c-LA.BR.1.2.7-03810-8x16.0-linaro3#n203

Cc: Ramon Fried 
Signed-off-by: Stephan Gerhold 
---

 drivers/serial/serial_msm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c
index d8c6c2f6b5..d8dd5c1104 100644
--- a/drivers/serial/serial_msm.c
+++ b/drivers/serial/serial_msm.c
@@ -23,6 +23,7 @@
 /* Serial registers - this driver works in uartdm mode*/
 
 #define UARTDM_DMRX 0x34 /* Max RX transfer length */
+#define UARTDM_DMEN 0x3C /* DMA/data-packing mode */
 #define UARTDM_NCF_TX   0x40 /* Number of chars to TX */
 
 #define UARTDM_RXFS 0x50 /* RX channel status register */
@@ -197,6 +198,9 @@ static void uart_dm_init(struct msm_serial_data *priv)
writel(MSM_BOOT_UART_DM_8_N_1_MODE, priv->base + UARTDM_MR2);
writel(MSM_BOOT_UART_DM_CMD_RESET_RX, priv->base + UARTDM_CR);
writel(MSM_BOOT_UART_DM_CMD_RESET_TX, priv->base + UARTDM_CR);
+
+   /* Make sure BAM/single character mode is disabled */
+   writel(0x0, priv->base + UARTDM_DMEN);
 }
 static int msm_serial_probe(struct udevice *dev)
 {
-- 
2.32.0

[PATCH] arm: dts: db410c: Add missing cd-gpios for SD card detection

[Stephan Gerhold]

It looks like SD card detection is broken at the moment for DB410c.
The eMMC is detected correctly, but the SD card is not.

This is probably similar to the issue fixed in commit 850514740358
("mmc: msm_sdhci: Use mmc_of_parse for setting host_caps") for eMMC,
except that the SD card does not have a property like "non-removable"
that skips the card detection.

The SDHCI on DB410c cannot detect itself if a SD card is inserted,
so add the necessary cd-gpios to make SD card detection work again.

While at it, fix the #gpio-cells for the soc_gpios to avoid DTC
warnings - the soc_gpios are actually already used with two cells
for the gpio-leds so this was just wrong all the time.

Cc: Ramon Fried 
Signed-off-by: Stephan Gerhold 
---

 arch/arm/dts/dragonboard410c.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index fa348bc621..7e56140df2 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -8,6 +8,7 @@
 /dts-v1/;
 
 #include "skeleton64.dtsi"
+#include 
 #include 
 
 / {
@@ -91,7 +92,7 @@
gpio-controller;
gpio-count = <122>;
gpio-bank-name="soc";
-   #gpio-cells = <1>;
+   #gpio-cells = <2>;
};
 
ehci@78d9000 {
@@ -123,6 +124,7 @@
bus-width = <0x4>;
clock = < 1>;
clock-frequency = <2>;
+   cd-gpios = <_gpios 38 GPIO_ACTIVE_LOW>;
};
 
wcnss {
-- 
2.32.0

Re: [RFC PATCH 0/5] arm: Restore minimal support for ST-Ericsson U8500 SoC

[Stephan Gerhold]

On Wed, Jan 22, 2020 at 01:03:50PM -0500, Tom Rini wrote:
> On Wed, Jan 22, 2020 at 05:47:07PM +0100, Stephan Gerhold wrote:
> > Hi Tom,
> > 
> > On Sat, Jan 04, 2020 at 06:45:14PM +0100, Stephan Gerhold wrote:
> > > This patch series restores minimal U-Boot support for
> > > the ST-Ericsson NovaThor U8500 SoC.
> > > 
> > > Previous support for U8500 was removed in
> > > commit 68282f55b846 ("arm: Remove unused ST-Ericsson u8500 arch")
> > > since none of the boards were converted to generic boards
> > > before the deadline.
> > > 
> > > The motivation for adding the SoC and board is explained in
> > >   - Patch 3 ("arm: Add support for ST-Ericsson U8500 SoC") and
> > >   - Patch 5 ("board: Add new Samsung "stemmy" board based on ST-Ericsson 
> > > U8500")
> > > 
> > > I have additional patches for MMC, USB, display and the "stemmy"
> > > board, that configure it to provide an Android fastboot interface
> > > with similar functionality as the original Samsung bootloader.
> > > Some of the patches require some additional work, so I thought
> > > it is easier to start with some minimal changes first (only UART).
> > > 
> > > I think this makes the patch series quite straightforward,
> > > with only ~225 new lines of C code, plus device tree and documentation.
> > > The only patch that stands out with ~1.8k lines is the device tree
> > > import, directly copied (without modification) from the Linux kernel.
> > > 
> > 
> > Since we are approaching the end of the merge window,
> > I was wondering if there is anything I can do to get this patch set
> > applied for v2020.04?
> 
> Since you had marked it as RFC, I had marked it as such in patchwork and
> overlooked it.  I'll take a look soon, thanks.

Thank you! I thought marking it as RFC is appropriate since I'm adding a
new SoC and this is my first U-Boot patch. But it is working fine,
so unless there are comments it should be good to go :)

Thanks,
Stephan

Re: [RFC PATCH 0/5] arm: Restore minimal support for ST-Ericsson U8500 SoC

[Stephan Gerhold]

Hi Tom,

On Sat, Jan 04, 2020 at 06:45:14PM +0100, Stephan Gerhold wrote:
> This patch series restores minimal U-Boot support for
> the ST-Ericsson NovaThor U8500 SoC.
> 
> Previous support for U8500 was removed in
> commit 68282f55b846 ("arm: Remove unused ST-Ericsson u8500 arch")
> since none of the boards were converted to generic boards
> before the deadline.
> 
> The motivation for adding the SoC and board is explained in
>   - Patch 3 ("arm: Add support for ST-Ericsson U8500 SoC") and
>   - Patch 5 ("board: Add new Samsung "stemmy" board based on ST-Ericsson 
> U8500")
> 
> I have additional patches for MMC, USB, display and the "stemmy"
> board, that configure it to provide an Android fastboot interface
> with similar functionality as the original Samsung bootloader.
> Some of the patches require some additional work, so I thought
> it is easier to start with some minimal changes first (only UART).
> 
> I think this makes the patch series quite straightforward,
> with only ~225 new lines of C code, plus device tree and documentation.
> The only patch that stands out with ~1.8k lines is the device tree
> import, directly copied (without modification) from the Linux kernel.
> 

Since we are approaching the end of the merge window,
I was wondering if there is anything I can do to get this patch set
applied for v2020.04?

Thanks,
Stephan

> 
> Stephan Gerhold (5):
>   timer: Add driver for Nomadik Multi Timer Unit (MTU)
>   arm: dts: Import device tree for ST-Ericsson Ux500
>   arm: Add support for ST-Ericsson U8500 SoC
>   MAINTAINERS: Add ARM U8500
>   board: Add new Samsung "stemmy" board based on ST-Ericsson U8500
> 
>  MAINTAINERS|8 +
>  arch/arm/Kconfig   |   20 +
>  arch/arm/Makefile  |1 +
>  arch/arm/dts/Makefile  |2 +
>  arch/arm/dts/ste-ab8500.dtsi   |  328 ++
>  arch/arm/dts/ste-ab8505.dtsi   |  275 +
>  arch/arm/dts/ste-dbx5x0-u-boot.dtsi|   29 +
>  arch/arm/dts/ste-dbx5x0.dtsi   | 1144 
>  arch/arm/dts/ste-ux500-samsung-stemmy.dts  |   20 +
>  arch/arm/include/asm/gpio.h|2 +-
>  arch/arm/mach-u8500/Kconfig|   27 +
>  arch/arm/mach-u8500/Makefile   |4 +
>  arch/arm/mach-u8500/cache.c|   37 +
>  arch/arm/mach-u8500/cpuinfo.c  |   25 +
>  board/ste/stemmy/Kconfig   |   12 +
>  board/ste/stemmy/MAINTAINERS   |6 +
>  board/ste/stemmy/Makefile  |2 +
>  board/ste/stemmy/README|   49 +
>  board/ste/stemmy/stemmy.c  |   18 +
>  configs/stemmy_defconfig   |   18 +
>  drivers/timer/Kconfig  |9 +
>  drivers/timer/Makefile |1 +
>  drivers/timer/nomadik-mtu-timer.c  |  114 ++
>  include/configs/stemmy.h   |   29 +
>  include/dt-bindings/arm/ux500_pm_domains.h |   15 +
>  include/dt-bindings/clock/ste-ab8500.h |   12 +
>  include/dt-bindings/mfd/dbx500-prcmu.h |   84 ++
>  27 files changed, 2290 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/ste-ab8500.dtsi
>  create mode 100644 arch/arm/dts/ste-ab8505.dtsi
>  create mode 100644 arch/arm/dts/ste-dbx5x0-u-boot.dtsi
>  create mode 100644 arch/arm/dts/ste-dbx5x0.dtsi
>  create mode 100644 arch/arm/dts/ste-ux500-samsung-stemmy.dts
>  create mode 100644 arch/arm/mach-u8500/Kconfig
>  create mode 100644 arch/arm/mach-u8500/Makefile
>  create mode 100644 arch/arm/mach-u8500/cache.c
>  create mode 100644 arch/arm/mach-u8500/cpuinfo.c
>  create mode 100644 board/ste/stemmy/Kconfig
>  create mode 100644 board/ste/stemmy/MAINTAINERS
>  create mode 100644 board/ste/stemmy/Makefile
>  create mode 100644 board/ste/stemmy/README
>  create mode 100644 board/ste/stemmy/stemmy.c
>  create mode 100644 configs/stemmy_defconfig
>  create mode 100644 drivers/timer/nomadik-mtu-timer.c
>  create mode 100644 include/configs/stemmy.h
>  create mode 100644 include/dt-bindings/arm/ux500_pm_domains.h
>  create mode 100644 include/dt-bindings/clock/ste-ab8500.h
>  create mode 100644 include/dt-bindings/mfd/dbx500-prcmu.h
> 
> -- 
> 2.24.1
> 

[RFC PATCH 5/5] board: Add new Samsung "stemmy" board based on ST-Ericsson U8500

[Stephan Gerhold]

The ST-Ericsson U8500 SoC has been used in mass-production for
some Android smartphones released around 2012.
In particular, Samsung has released more than 5 different
smartphones based on U8500, e.g.

  - Samsung Galaxy S III mini (GT-I8190) "golden"
  - Samsung Galaxy S Advance (GT-I9070)  "janice"
  - Samsung Galaxy Xcover 2 (GT-S7710)   "skomer"

and a few others.

Mainline Linux has great support for the Ux500 SoC, so these
smartphones can also run Linux mainline quite well.

Unfortunately, the original Samsung bootloader used on these devices
has limitations that prevent booting Linux mainline directly.
It keeps the L2 cache enabled, which causes Linux to crash very early,
shortly after decompressing the kernel.

Using U-Boot allows to circumvent these limitations. We can let the
Samsung bootloader chain-load U-Boot and U-Boot locks the L2 cache
before booting into Linux. U-Boot has several other advantages
- it supports device-trees directly and we are no longer limited to
flashing Android boot images through Samsung's proprietary download
mode.

The Samsung "stemmy" board covers all Samsung devices based on U8500.
Add minimal support for "stemmy". For now only UART is supported but
this will be extended later.

Signed-off-by: Stephan Gerhold 
---

 arch/arm/dts/Makefile |  2 +
 arch/arm/dts/ste-ux500-samsung-stemmy.dts | 20 +
 arch/arm/mach-u8500/Kconfig   | 21 ++
 board/ste/stemmy/Kconfig  | 12 ++
 board/ste/stemmy/MAINTAINERS  |  6 +++
 board/ste/stemmy/Makefile |  2 +
 board/ste/stemmy/README   | 49 +++
 board/ste/stemmy/stemmy.c | 18 +
 configs/stemmy_defconfig  | 18 +
 include/configs/stemmy.h  | 29 ++
 10 files changed, 177 insertions(+)
 create mode 100644 arch/arm/dts/ste-ux500-samsung-stemmy.dts
 create mode 100644 board/ste/stemmy/Kconfig
 create mode 100644 board/ste/stemmy/MAINTAINERS
 create mode 100644 board/ste/stemmy/Makefile
 create mode 100644 board/ste/stemmy/README
 create mode 100644 board/ste/stemmy/stemmy.c
 create mode 100644 configs/stemmy_defconfig
 create mode 100644 include/configs/stemmy.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0127a91a82..83aea3aa54 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -384,6 +384,8 @@ dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
 dtb-$(CONFIG_TARGET_DRAGONBOARD410C) += dragonboard410c.dtb
 dtb-$(CONFIG_TARGET_DRAGONBOARD820C) += dragonboard820c.dtb
 
+dtb-$(CONFIG_TARGET_STEMMY) += ste-ux500-samsung-stemmy.dtb
+
 dtb-$(CONFIG_STM32F4) += stm32f429-disco.dtb \
stm32429i-eval.dtb \
stm32f469-disco.dtb
diff --git a/arch/arm/dts/ste-ux500-samsung-stemmy.dts 
b/arch/arm/dts/ste-ux500-samsung-stemmy.dts
new file mode 100644
index 00..7e7f4c823a
--- /dev/null
+++ b/arch/arm/dts/ste-ux500-samsung-stemmy.dts
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/dts-v1/;
+
+#include "ste-dbx5x0-u-boot.dtsi"
+#include "ste-ab8500.dtsi"
+
+/ {
+   compatible = "samsung,stemmy", "st-ericsson,u8500";
+
+   chosen {
+   stdout-path = 
+   };
+
+   soc {
+   /* Debugging console UART */
+   uart@80007000 {
+   status = "okay";
+   };
+   };
+};
diff --git a/arch/arm/mach-u8500/Kconfig b/arch/arm/mach-u8500/Kconfig
index 3bc76295cb..7478deb25f 100644
--- a/arch/arm/mach-u8500/Kconfig
+++ b/arch/arm/mach-u8500/Kconfig
@@ -3,4 +3,25 @@ if ARCH_U8500
 config SYS_SOC
default "u8500"
 
+choice
+   prompt "U8500 board selection"
+
+config TARGET_STEMMY
+   bool "Samsung (stemmy) board"
+   help
+ The Samsung "stemmy" board supports Samsung smartphones released with
+ the ST-Ericsson NovaThor U8500 SoC, e.g.
+
+ - Samsung Galaxy S III mini (GT-I8190)"golden"
+ - Samsung Galaxy S Advance (GT-I9070) "janice"
+ - Samsung Galaxy Xcover 2 (GT-S7710)  "skomer"
+
+ and likely others as well (untested).
+
+ See board/ste/stemmy/README for details.
+
+endchoice
+
+source "board/ste/stemmy/Kconfig"
+
 endif
diff --git a/board/ste/stemmy/Kconfig b/board/ste/stemmy/Kconfig
new file mode 100644
index 00..b890ba51cb
--- /dev/null
+++ b/board/ste/stemmy/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_STEMMY
+
+config SYS_BOARD
+   default "stemmy"
+
+config SYS_VENDOR
+   default "ste"
+
+config SYS_CONFIG_NAME
+   default "stemmy"
+
+endif
diff --git a/board/ste/stemmy/MAINTAINERS b/board/ste/stemmy/MAINTAINERS
new file mode 100644
index 00..37daabea9c
--- /dev/null
+++ b/boa

[RFC PATCH 2/5] arm: dts: Import device tree for ST-Ericsson Ux500

[Stephan Gerhold]

from 
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git/
tag "ux500-armsoc-v5.6-2"
commit 224bf0fe7292 ("ARM: dts: ux500: samsung-golden: Add Bluetooth")

(queued for merge in Linux 5.6)

Signed-off-by: Stephan Gerhold 
---
I ignored all the checkpatch complaints in this patch,
since the files are copied without modification from the Linux kernel.

I will check if it makes sense to submit a patch to fix some of them...
(In particular the large amount of "WARNING: please, no space before tabs"
in one of the includes...)

 arch/arm/dts/ste-ab8500.dtsi   |  328 ++
 arch/arm/dts/ste-ab8505.dtsi   |  275 +
 arch/arm/dts/ste-dbx5x0.dtsi   | 1144 
 include/dt-bindings/arm/ux500_pm_domains.h |   15 +
 include/dt-bindings/clock/ste-ab8500.h |   12 +
 include/dt-bindings/mfd/dbx500-prcmu.h |   84 ++
 6 files changed, 1858 insertions(+)
 create mode 100644 arch/arm/dts/ste-ab8500.dtsi
 create mode 100644 arch/arm/dts/ste-ab8505.dtsi
 create mode 100644 arch/arm/dts/ste-dbx5x0.dtsi
 create mode 100644 include/dt-bindings/arm/ux500_pm_domains.h
 create mode 100644 include/dt-bindings/clock/ste-ab8500.h
 create mode 100644 include/dt-bindings/mfd/dbx500-prcmu.h

diff --git a/arch/arm/dts/ste-ab8500.dtsi b/arch/arm/dts/ste-ab8500.dtsi
new file mode 100644
index 00..14d4d8617d
--- /dev/null
+++ b/arch/arm/dts/ste-ab8500.dtsi
@@ -0,0 +1,328 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2012 Linaro Ltd
+ */
+
+#include 
+
+/ {
+   /* Essential housekeeping hardware monitors */
+   iio-hwmon {
+   compatible = "iio-hwmon";
+   io-channels = < 0x02>, /* Battery temperature */
+   < 0x03>, /* Main charger voltage */
+   < 0x08>, /* Main battery voltage */
+   < 0x09>, /* VBUS */
+   < 0x0a>, /* Main charger current */
+   < 0x0b>, /* USB charger current */
+   < 0x0c>, /* Backup battery voltage */
+   < 0x0d>, /* Die temperature */
+   < 0x12>; /* Crystal temperature */
+   };
+
+   soc {
+   prcmu@80157000 {
+   ab8500 {
+   compatible = "stericsson,ab8500";
+   interrupt-parent = <>;
+   interrupts = ;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   ab8500_clock: clock-controller {
+   compatible = "stericsson,ab8500-clk";
+   #clock-cells = <1>;
+   };
+
+   ab8500_gpio: ab8500-gpio {
+   compatible = "stericsson,ab8500-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   ab8500-rtc {
+   compatible = "stericsson,ab8500-rtc";
+   interrupts = <17 IRQ_TYPE_LEVEL_HIGH
+ 18 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "60S", "ALARM";
+   };
+
+   gpadc: ab8500-gpadc {
+   compatible = "stericsson,ab8500-gpadc";
+   interrupts = <32 IRQ_TYPE_LEVEL_HIGH
+ 39 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "HW_CONV_END", 
"SW_CONV_END";
+   vddadc-supply = <_ldo_tvout_reg>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #io-channel-cells = <1>;
+
+   /* GPADC channels */
+   bat_ctrl: channel@01 {
+   reg = <0x01>;
+   };
+   btemp_ball: channel@02 {
+   reg = <0x02>;
+   };
+   main_charger_v: channel@03 {
+   reg = <0x03>;
+  

[RFC PATCH 3/5] arm: Add support for ST-Ericsson U8500 SoC

[Stephan Gerhold]

The NovaThor U8500 SoC was released by ST-Ericsson in 2011.
It was used for some development boards like the CALAO Systems
Snowball SBC, but mass production was primarily for Android
smartphones like the Samsung Galaxy S III mini.

Previous support for U8500 was removed in
commit 68282f55b846 ("arm: Remove unused ST-Ericsson u8500 arch")
since none of the boards were converted to generic boards
before the deadline.

The new code does not have much in common with the previous code.
I have completely rewritten everything, embracing the Driver Model
and device trees wherever possible.

The U8500 support is a bit more minimal for now - my primary
use case is to use U-Boot as alternative bootloader for some of the
U8500 Samsung smartphones. At the moment U-Boot is chain-loaded from
the original Samsung bootloader. A side effect of this is that we
can (temporarily) get away without implementing some functionality
- e.g. all clocks are already enabled by the original bootloader.

More functionality will be added in future patches.

Cc: Mathieu Poirier 
Cc: John Rigby 
Signed-off-by: Stephan Gerhold 
---

 arch/arm/Kconfig| 20 
 arch/arm/Makefile   |  1 +
 arch/arm/dts/ste-dbx5x0-u-boot.dtsi | 29 ++
 arch/arm/include/asm/gpio.h |  2 +-
 arch/arm/mach-u8500/Kconfig |  6 +
 arch/arm/mach-u8500/Makefile|  4 
 arch/arm/mach-u8500/cache.c | 37 +
 arch/arm/mach-u8500/cpuinfo.c   | 25 +++
 8 files changed, 123 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/ste-dbx5x0-u-boot.dtsi
 create mode 100644 arch/arm/mach-u8500/Kconfig
 create mode 100644 arch/arm/mach-u8500/Makefile
 create mode 100644 arch/arm/mach-u8500/cache.c
 create mode 100644 arch/arm/mach-u8500/cpuinfo.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 36c9c2fecd..e4824832e3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -988,6 +988,24 @@ config ARCH_SUNXI
imply SPL_SERIAL_SUPPORT
imply USB_GADGET
 
+config ARCH_U8500
+   bool "ST-Ericsson U8500 Series"
+   select CPU_V7A
+   select DM
+   select DM_GPIO
+   select DM_MMC if MMC
+   select DM_SERIAL
+   select DM_USB if USB
+   select OF_CONTROL
+   select SYSRESET
+   select TIMER
+   imply ARM_PL180_MMCI
+   imply DM_RTC
+   imply NOMADIK_MTU_TIMER
+   imply PL01X_SERIAL
+   imply RTC_PL031
+   imply SYSRESET_SYSCON
+
 config ARCH_VERSAL
bool "Support Xilinx Versal Platform"
select ARM64
@@ -1756,6 +1774,8 @@ source "arch/arm/mach-sunxi/Kconfig"
 
 source "arch/arm/mach-tegra/Kconfig"
 
+source "arch/arm/mach-u8500/Kconfig"
+
 source "arch/arm/mach-uniphier/Kconfig"
 
 source "arch/arm/cpu/armv7/vf610/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 856f2d8608..ae40f39db7 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -79,6 +79,7 @@ machine-$(CONFIG_ARCH_ROCKCHIP)   += rockchip
 machine-$(CONFIG_STM32)+= stm32
 machine-$(CONFIG_ARCH_STM32MP) += stm32mp
 machine-$(CONFIG_TEGRA)+= tegra
+machine-$(CONFIG_ARCH_U8500)   += u8500
 machine-$(CONFIG_ARCH_UNIPHIER)+= uniphier
 machine-$(CONFIG_ARCH_ZYNQ)+= zynq
 machine-$(CONFIG_ARCH_ZYNQMP)  += zynqmp
diff --git a/arch/arm/dts/ste-dbx5x0-u-boot.dtsi 
b/arch/arm/dts/ste-dbx5x0-u-boot.dtsi
new file mode 100644
index 00..4a99ee5a92
--- /dev/null
+++ b/arch/arm/dts/ste-dbx5x0-u-boot.dtsi
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include "skeleton.dtsi"
+#include "ste-dbx5x0.dtsi"
+
+/ {
+   soc {
+   /* FIXME: Remove this when clk driver is implemented */
+   mtu@a03c6000 {
+   clock-frequency = <13300>;
+   };
+   uart@8012 {
+   clock = <3840>;
+   };
+   uart@80121000 {
+   clock = <3840>;
+   };
+   uart@80007000 {
+   clock = <3840>;
+   };
+   };
+
+   reboot {
+   compatible = "syscon-reboot";
+   regmap = <>;
+   offset = <0x228>; /* PRCM_APE_SOFTRST */
+   mask = <0x1>;
+   };
+};
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 6ff5f42424..7203ccbaeb 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -3,7 +3,7 @@
!defined(CONFIG_ARCH_BCM63158) && !defined(CONFIG_ARCH_ROCKCHIP) && \
!defined(CONFIG_ARCH_LX2160A) && !defined(CONFIG_ARCH_LS1028A) && \
!defined(CONFIG_ARCH_LS2080A)

[RFC PATCH 4/5] MAINTAINERS: Add ARM U8500

[Stephan Gerhold]

Add myself as maintainer for ST-Ericsson U8500 SoC to MAINTAINERS.
Linus Walleij usually reviews all Ux500 related patches,
so add him as a reviewer.

Cc: Linus Walleij 
Signed-off-by: Stephan Gerhold 
---

 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 438fb225ab..81b3bd2b7b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -403,6 +403,14 @@ F: arch/arm/mach-keystone/
 F: arch/arm/include/asm/arch-omap*/
 F: arch/arm/include/asm/ti-common/
 
+ARM U8500
+M: Stephan Gerhold 
+R: Linus Walleij 
+S: Maintained
+F: arch/arm/dts/ste-*
+F: arch/arm/mach-u8500/
+F: drivers/timer/nomadik-mtu-timer.c
+
 ARM UNIPHIER
 M: Masahiro Yamada 
 S: Maintained
-- 
2.24.1

[RFC PATCH 1/5] timer: Add driver for Nomadik Multi Timer Unit (MTU)

[Stephan Gerhold]

The Nomadik Multi Timer Unit (MTU) provides 4 decrementing
free-running timers. It is used in ST-Ericsson Ux500 SoCs.

The driver uses the first timer to implement UCLASS_TIMER.

Signed-off-by: Stephan Gerhold 
---

 drivers/timer/Kconfig |   9 +++
 drivers/timer/Makefile|   1 +
 drivers/timer/nomadik-mtu-timer.c | 114 ++
 3 files changed, 124 insertions(+)
 create mode 100644 drivers/timer/nomadik-mtu-timer.c

diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 5f4bc6edb6..89e3b5bc12 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -127,6 +127,15 @@ config X86_TSC_TIMER_EARLY_FREQ
  hardware ways, nor got from device tree at the time when device
  tree is not available yet.
 
+config NOMADIK_MTU_TIMER
+   bool "Nomadik MTU Timer"
+   depends on TIMER
+   help
+ Enables support for the Nomadik Multi Timer Unit (MTU),
+ used in ST-Ericsson Ux500 SoCs.
+ The MTU provides 4 decrementing free-running timers.
+ At the moment, only the first timer is used by the driver.
+
 config OMAP_TIMER
bool "Omap timer support"
depends on TIMER
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index fa35bea6c5..c22ffebcde 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_ATMEL_PIT_TIMER) += atmel_pit_timer.o
 obj-$(CONFIG_CADENCE_TTC_TIMER)+= cadence-ttc.o
 obj-$(CONFIG_DESIGNWARE_APB_TIMER) += dw-apb-timer.o
 obj-$(CONFIG_MPC83XX_TIMER) += mpc83xx_timer.o
+obj-$(CONFIG_NOMADIK_MTU_TIMER)+= nomadik-mtu-timer.o
 obj-$(CONFIG_OMAP_TIMER)   += omap-timer.o
 obj-$(CONFIG_RENESAS_OSTM_TIMER) += ostm_timer.o
 obj-$(CONFIG_RISCV_TIMER) += riscv_timer.o
diff --git a/drivers/timer/nomadik-mtu-timer.c 
b/drivers/timer/nomadik-mtu-timer.c
new file mode 100644
index 00..8648f1f1df
--- /dev/null
+++ b/drivers/timer/nomadik-mtu-timer.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2019 Stephan Gerhold 
+ *
+ * Based on arch/arm/cpu/armv7/u8500/timer.c:
+ * Copyright (C) 2010 Linaro Limited
+ * John Rigby 
+ *
+ * Based on Linux kernel source and internal ST-Ericsson U-Boot source:
+ * Copyright (C) 2009 Alessandro Rubini
+ * Copyright (C) 2010 ST-Ericsson
+ * Copyright (C) 2010 Linus Walleij for ST-Ericsson
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define MTU_NUM_TIMERS 4
+
+/* The timers */
+struct nomadik_mtu_timer_regs {
+   u32 lr; /* Load register */
+   u32 cv; /* Current value */
+   u32 cr; /* Control register */
+   u32 bglr;   /* Background load register */
+};
+
+/* The MTU that contains the timers */
+struct nomadik_mtu_regs {
+   u32 imsc;   /* Interrupt mask set/clear */
+   u32 ris;/* Raw interrupt status */
+   u32 mis;/* Masked interrupt status */
+   u32 icr;/* Interrupt clear register */
+
+   struct nomadik_mtu_timer_regs timers[MTU_NUM_TIMERS];
+};
+
+/* Bits for the control register */
+#define MTU_CR_ONESHOT BIT(0)  /* if 0 = wraps reloading from BGLR */
+#define MTU_CR_32BITS  BIT(1)  /* if 0 = 16-bit counter */
+
+#define MTU_CR_PRESCALE_SHIFT  2
+#define MTU_CR_PRESCALE_1  (0 << MTU_CR_PRESCALE_SHIFT)
+#define MTU_CR_PRESCALE_16 (1 << MTU_CR_PRESCALE_SHIFT)
+#define MTU_CR_PRESCALE_256(2 << MTU_CR_PRESCALE_SHIFT)
+
+#define MTU_CR_PERIODICBIT(6)  /* if 0 = free-running */
+#define MTU_CR_ENABLE  BIT(7)
+
+struct nomadik_mtu_priv {
+   struct nomadik_mtu_timer_regs *timer;
+};
+
+static int nomadik_mtu_get_count(struct udevice *dev, u64 *count)
+{
+   struct nomadik_mtu_priv *priv = dev_get_priv(dev);
+
+   /* Decrementing counter: invert the value */
+   *count = timer_conv_64(~readl(>timer->cv));
+
+   return 0;
+}
+
+static int nomadik_mtu_probe(struct udevice *dev)
+{
+   struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   struct nomadik_mtu_priv *priv = dev_get_priv(dev);
+   struct nomadik_mtu_regs *mtu;
+   fdt_addr_t addr;
+   u32 prescale;
+
+   addr = dev_read_addr(dev);
+   if (addr == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   mtu = (struct nomadik_mtu_regs *)addr;
+   priv->timer = mtu->timers; /* Use first timer */
+
+   if (!uc_priv->clock_rate)
+   return -EINVAL;
+
+   /* Use divide-by-16 counter if tick rate is more than 32 MHz */
+   if (uc_priv->clock_rate > 3200) {
+   uc_priv->clock_rate /= 16;
+   prescale = MTU_CR_PRESCALE_16;
+   } else {
+   prescale = MTU_CR_PRESCALE_1;
+   }
+
+   /* Configure a free-running, auto-wrap counter with selected prescale */
+   writel(MTU_CR_ENABLE | prescale | MTU_CR_32BITS, >ti

[RFC PATCH 0/5] arm: Restore minimal support for ST-Ericsson U8500 SoC

[Stephan Gerhold]

This patch series restores minimal U-Boot support for
the ST-Ericsson NovaThor U8500 SoC.

Previous support for U8500 was removed in
commit 68282f55b846 ("arm: Remove unused ST-Ericsson u8500 arch")
since none of the boards were converted to generic boards
before the deadline.

The motivation for adding the SoC and board is explained in
  - Patch 3 ("arm: Add support for ST-Ericsson U8500 SoC") and
  - Patch 5 ("board: Add new Samsung "stemmy" board based on ST-Ericsson U8500")

I have additional patches for MMC, USB, display and the "stemmy"
board, that configure it to provide an Android fastboot interface
with similar functionality as the original Samsung bootloader.
Some of the patches require some additional work, so I thought
it is easier to start with some minimal changes first (only UART).

I think this makes the patch series quite straightforward,
with only ~225 new lines of C code, plus device tree and documentation.
The only patch that stands out with ~1.8k lines is the device tree
import, directly copied (without modification) from the Linux kernel.


Stephan Gerhold (5):
  timer: Add driver for Nomadik Multi Timer Unit (MTU)
  arm: dts: Import device tree for ST-Ericsson Ux500
  arm: Add support for ST-Ericsson U8500 SoC
  MAINTAINERS: Add ARM U8500
  board: Add new Samsung "stemmy" board based on ST-Ericsson U8500

 MAINTAINERS|8 +
 arch/arm/Kconfig   |   20 +
 arch/arm/Makefile  |1 +
 arch/arm/dts/Makefile  |2 +
 arch/arm/dts/ste-ab8500.dtsi   |  328 ++
 arch/arm/dts/ste-ab8505.dtsi   |  275 +
 arch/arm/dts/ste-dbx5x0-u-boot.dtsi|   29 +
 arch/arm/dts/ste-dbx5x0.dtsi   | 1144 
 arch/arm/dts/ste-ux500-samsung-stemmy.dts  |   20 +
 arch/arm/include/asm/gpio.h|2 +-
 arch/arm/mach-u8500/Kconfig|   27 +
 arch/arm/mach-u8500/Makefile   |4 +
 arch/arm/mach-u8500/cache.c|   37 +
 arch/arm/mach-u8500/cpuinfo.c  |   25 +
 board/ste/stemmy/Kconfig   |   12 +
 board/ste/stemmy/MAINTAINERS   |6 +
 board/ste/stemmy/Makefile  |2 +
 board/ste/stemmy/README|   49 +
 board/ste/stemmy/stemmy.c  |   18 +
 configs/stemmy_defconfig   |   18 +
 drivers/timer/Kconfig  |9 +
 drivers/timer/Makefile |1 +
 drivers/timer/nomadik-mtu-timer.c  |  114 ++
 include/configs/stemmy.h   |   29 +
 include/dt-bindings/arm/ux500_pm_domains.h |   15 +
 include/dt-bindings/clock/ste-ab8500.h |   12 +
 include/dt-bindings/mfd/dbx500-prcmu.h |   84 ++
 27 files changed, 2290 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/ste-ab8500.dtsi
 create mode 100644 arch/arm/dts/ste-ab8505.dtsi
 create mode 100644 arch/arm/dts/ste-dbx5x0-u-boot.dtsi
 create mode 100644 arch/arm/dts/ste-dbx5x0.dtsi
 create mode 100644 arch/arm/dts/ste-ux500-samsung-stemmy.dts
 create mode 100644 arch/arm/mach-u8500/Kconfig
 create mode 100644 arch/arm/mach-u8500/Makefile
 create mode 100644 arch/arm/mach-u8500/cache.c
 create mode 100644 arch/arm/mach-u8500/cpuinfo.c
 create mode 100644 board/ste/stemmy/Kconfig
 create mode 100644 board/ste/stemmy/MAINTAINERS
 create mode 100644 board/ste/stemmy/Makefile
 create mode 100644 board/ste/stemmy/README
 create mode 100644 board/ste/stemmy/stemmy.c
 create mode 100644 configs/stemmy_defconfig
 create mode 100644 drivers/timer/nomadik-mtu-timer.c
 create mode 100644 include/configs/stemmy.h
 create mode 100644 include/dt-bindings/arm/ux500_pm_domains.h
 create mode 100644 include/dt-bindings/clock/ste-ab8500.h
 create mode 100644 include/dt-bindings/mfd/dbx500-prcmu.h

-- 
2.24.1